b9 edge ion guide ed1

ED 1 RELEASED 011

NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 1/2

Y

3DF 01900 0000 PTZZA – DIAMS

All rights reserved. Passing on and copying of this document,

use and communication of its contents not perm

itted without

written authorization from Alcatel-Lucent.

Domain : NETWORK OPTIMISATION

Product : 2G B9

Division : METHODS

Rubric : EDGE

Type : GUIDELINE

Distrib. codes Internal: External:

PREDISTRIBUTION

NE J. ANDRES NE/Quality & Partnership LF.GONNOT

NE/Romania S. BODEA NE/GSM F. Colin

NE/Egypt N. GEORGE NE/GSM/Egypt S. Abdel-Wahab

NE/GSM/Romania C. Inta

ABSTRACT

This document presents the EDGE optimisation methodologies, for B9 release.

KEYWORDS

GSM, EDGE, EGPRS, B9, Optimisation

Approvals

NE J. ANDRES NE/GSM F. Colin

Date:

Signature:

Date:

Signature:

Date:

Signature:

Date:

Signature:

Site

CASCAIS

WIRELESS BUSINESS GROUP

NETWORK ENGINEERING

Originator

Pedro Henriques B9 EDGE Optimisation Guide

ED 1 RELEASED 011

NE B9_EDGE_Optimisation_Guide_ed1.doc 20070629 3DF XXXX XXXX PTZZA 2/2

Y

3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin

g on and copying of th

is document,

use and communicatio

n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

HISTORY

Edition Status Date Comments

01 Draft May. 23rd, 2007 Draft Creation

1 Release June, 29th, 2007 First edition

DISTRIBUTION LIST

NE

END OF DOCUMENT

TABLE OF CONTENTS

1 INTRODUCTION ....................................................................................................... 5

2 ALGORITHMS AND PARAMETERS ................................................................................. 6 2.1 MAIN EDGE CONCEPTS......................................................................................................................... 6 2.2 HARDWARE AND POWER ASPECTS ......................................................................................................... 7 2.3 ENHANCED TRANSMISSION RESOURCE MANAGEMENT ............................................................................. 8 2.3.1 M-EGCH STATISTICAL MULTIPLEXING....................................................................................................................... 8 2.3.2 DYNAMIC ABIS ALLOCATION .................................................................................................................................. 10 2.3.3 ATER RESOURCE MANAGEMENT ............................................................................................................................ 12 2.3.4 DL RETRANSMISSION IN THE BTS .......................................................................................................................... 13 2.4 AUTONOMOUS PACKET RESOURCE ALLOCATION (RAE4) ........................................................................ 13 2.5 M-EGCH LINK MANAGEMENT .............................................................................................................. 22 2.5.1 DEFINITIONS........................................................................................................................................................ 22 2.5.2 ABIS SELECTION IN M-EGCH LINK.......................................................................................................................... 22 2.5.3 M-EGCH LINK SIZE ............................................................................................................................................... 23 2.5.4 PERIODICAL GCH ESTABLISHMENT PROCESS .......................................................................................................... 23 2.5.5 FAST INITIAL PS ACCESS ....................................................................................................................................... 24 2.5.6 HANDLING OF UNUSED GCH ................................................................................................................................. 24 2.5.7 M-EGCH LINK CAPACITY DECREASE ....................................................................................................................... 25 2.6 TBF RESOURCE ALLOCATION/REALLOCATION ...................................................................................... 25 2.6.1 TBF RESOURCE ESTABLISHMENT PROCESS............................................................................................................. 25 2.6.2 RADIO RESOURCE ALLOCATION PRINCIPLES........................................................................................................... 26 2.6.3 TRANSMISSION RESOURCE AVAILABILITY STEP ....................................................................................................... 28 2.6.4 TRX LIST COMPUTING .......................................................................................................................................... 28 2.6.5 BEST CANDIDATE ALLOCATION COMPUTATION ....................................................................................................... 28 2.6.6 PDCH CAPACITY ALLOCATION ............................................................................................................................... 31 2.6.7 TBF REALLOCATION CASES ................................................................................................................................... 32 2.7 ENHANCED SUPPORT OF EGPRS IN UL................................................................................................. 34 2.7.1 SUPPORT OF 8-PSK IN UPLINK .............................................................................................................................. 35 2.7.2 SUPPORT OF INCREMENTAL REDUNDANCY AND RESEGMENTATION IN UPLINK.......................................................... 36 2.8 EXTENDED UL TBF MODE ................................................................................................................... 37 2.9 ENHANCED PACKET CELL RESELECTION............................................................................................... 39 2.9.1 NETWORK ASSISTED CELL CHANGE PROCEDURES (NACC) ...................................................................................... 39 2.9.2 PACKET (P)SI STATUS PROCEDURE ........................................................................................................................ 42


ED 1 RELEASED 011




itted without


2.9.3 NC2 IMPROVEMENT ..............................................................................................................................................44 2.9.4 DL LLC PDU REROUTING.......................................................................................................................................46 2.10 TELECOM PARAMETERS .....................................................................................................................47

3 NETWORK DIMENSIONING........................................................................................54 3.1 ABIS ..................................................................................................................................................55 3.2 ATER .................................................................................................................................................57 3.2.1 METHOD 1 ...........................................................................................................................................................57 3.2.2 METHOD 2 ...........................................................................................................................................................58 3.2.3 NUMBER OF GCH NEEDED.....................................................................................................................................59 3.2.4 HSDS IMPACT .......................................................................................................................................................59 3.3 GPU/GP ............................................................................................................................................62

4 NETWORK PRIORITIES.............................................................................................64 4.1 PHASE 1 ............................................................................................................................................64 4.2 PHASE 2 ............................................................................................................................................64 4.3 PHASE 3 ............................................................................................................................................65

5 QOS FOLLOW-UP....................................................................................................66 5.1 TBF LIFE TIME ...................................................................................................................................66 5.1.1 TBF ESTABLISHMENT ............................................................................................................................................66 5.1.2 TBF DATA TRANSFER.............................................................................................................................................67 5.1.3 TBF REALLOCATION .............................................................................................................................................70 5.2 RLC STATISTICS..................................................................................................................................71 5.2.1 (M)CS DISTRIBUTION ............................................................................................................................................71 5.2.2 LLC/RLC TRAFFIC AND RETRANSMISSION...............................................................................................................74 5.3 RADIO RESOURCES .............................................................................................................................76 5.4 TRANSMISSION RESOURCES.................................................................................................................77 5.5 RNO REPORTS....................................................................................................................................77 5.6 END-USER STATISTICS.........................................................................................................................79

6 OPTIMISATION METHODS AND CONSTRAINTS .............................................................81 6.1 LOW DL THROUGHPUT OBSERVED .......................................................................................................81 6.1.1 END-TO-END ANALYSIS..........................................................................................................................................81 6.2 DL MCS FLUCTUATION ........................................................................................................................88 6.2.1 RADIO CONDITIONS ..............................................................................................................................................88 6.2.2 UNCONTINUOUS LLC TRAFFIC ..............................................................................................................................90 6.3 UL PERFORMANCE..............................................................................................................................90 6.3.1 RESEGMENTATION VS IR .......................................................................................................................................90 6.3.2 EXTENDED UL TBF MODE ......................................................................................................................................90 6.4 ACCESS TIME OPTIMIZATION ...............................................................................................................91 6.5 EDGE PERFORMANCE VERSUS FREQUENCY PLANNING...........................................................................91 6.6 ABIS CONGESTION..............................................................................................................................91 6.7 ATER CONGESTION.............................................................................................................................92 6.8 GSS OPTIMISATION FOR GMM/SM SIGNALLING......................................................................................95

A TABLE OF FIGURES .................................................................................................97

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

REFERENCED DOCUMENTS

Table 1: Referenced Documents

[1] EDGE Field Trial Guideline, ed4 3DF 01902 2015 VAZZA

[2] B9 MR1 Features Review, Methodology and Field Feedback 3DF 01906 2913 VAZZA

[3] 3GPP TS 05.08, Radio subsystem link control

RELATED DOCUMENTS

Table 2: Related Documents

[i1] (E)GPRS Radio Interface - RLC sub-layer 3BK 11202 0392 DSZZA

[i2] (E)GPRS Radio Interface - RRM sub-layer (PRH) 3BK 11202 0390 DSZZA

[i3] (E)GPRS Radio Interface - RRM sub-layer (PCC) 3BK 11202 0391 DSZZA

SCOPE

PURPOSE OF THE DOCUMENT

This document is a guideline of EDGE optimisation methods, for B9 release. It gives the direction for the

optimisation process and it tries to focus in the main topics and issues.

AREA OF APPLICATION

This template should be used within NE and RSC for all ALCATEL-LUCENT, it is an internal document.


ED 1 RELEASED 011




itted without


1 INTRODUCTION This document is a guideline for EDGE optimization for B9 MR1. It does not include the B9MR4 software

features (PS in extended cell, QoS handling) and the B9MR4 hardware features (Twin module). It has a

theoretical introduction of the PS features, follow by a chapter of network dimensioning and QoS follow-up.

To finalize there is a chapter explaining possible optimisation methods.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

2 ALGORITHMS AND PARAMETERS

2.1 MAIN EDGE CONCEPTS

EDGE introduces some new aspects that fatally distinguish it from the “classical” GPRS service:

o New coding schemes are introduced – EDGE uses MCS1 to MCS9 (MCS meaning Modulation and

Coding Scheme).

o New modulation – besides the GMSK modulation, which is still used in MCS1 to MCS4, EDGE uses 8-

PSK modulation. This modulation has a variable envelope, which impacts the available output

power.

o New LLC PDU segmentation – while in GPRS the LLC PDU is segmented in RLC blocks taking into

account the used coding scheme, in EDGE the LLC PDU is segmented in payload blocks (new concept

in EDGE) taking into account the used MCS family – in EDGE the RLC block can carry one or two

payload blocks.

o The coding scheme family concept, referred just above is also new in EDGE. Besides what was

already referred, this new concept changes the way retransmission is done. Table 1 presents the

different coding scheme families available (currently missing in the table below), as well as its

theoretical throughput.

o Puncturing Schemes – new concept in EDGE also used in the retransmission mechanisms.

Table 3: Coding Schemes

Coding scheme Coding scheme Family Modulation Theoretical throughput per PDCH (kbit/s)

CS1 GMSK 8

CS2 GMSK 12

CS3 GMSK 14.4

CS4

-

GMSK 20

MCS1 Family C GMSK 8.8

MCS2 Family B GMSK 11.2

MCS3 Family A/

Family A padding GMSK 14.8 / 13.6

MCS4 Family C GMSK 17.6

MCS5 Family B 8-PSK 22.4

MCS6 Family A/

Family A padding 8-PSK 29.6 / 27.2

MCS7 Family B 8-PSK 44.8

MCS8 Family A padding 8-PSK 54.4

MCS9 Family A 8-PSK 59.2

Retransmission mechanism, or ARQ (Automatic Repeat request), has been greatly modified in EDGE.

The first modification comes from the introduction of the payload concept. In an EGPRS TBF the RLC block

can be retransmitted either by using the same MCS or by using a MCS from the same coding scheme family.

A side effect from this is that even if Link Adaptation (algorithm that changes the coding scheme according

to radio conditions) is disabled, we can observe RLC blocks with different coding schemes (although always

with the same family).

Still in the ARQ mechanism, EDGE introduces a new type of ARQ. Now we have:

o Type 1 ARQ – the decoding of a re-transmitted RLC block does not take into account the previously

transmitted versions of this same RLC block. It is always used in GPRS.

o Type 2 hybrid ARQ (used only in EGPRS) – also known as Incremental Redundancy (IR), it is always

used in downlink EGPRS and for uplink, in B9, it can be activated by a flag. This mechanism works

as follows:


ED 1 RELEASED 011




itted without


o The first emission of the RLC block is done with a first puncturing scheme (PS1).

o If the RLC block needs to be retransmitted, the same MCS or a MCS from the same family

will be used. The block may or may not be re-segmented (depending on parameterisation).

The transmitter will also select the Puncturing Scheme to use.

o The receiver will use the information in all versions of the received block to increase its

decoding probability.

Note that 3GPP states that:

o IR is mandatory in MS’s receiver;

o There is no way to activate/de-activate IR in the MS receiver by signalling over the air-interface – IR

can only be de-activated in the case of insufficient memory in the mobile;

o The soft combining can be done between MCSx and MCSx blocks (same MCS used), a MCS9 and a

MCS6 block (RLC data blocks with the same number of payload units) or between a MCS7 block and

a MCS5 block (RLC data blocks with the same number of payload units).

The RLC Window management also changes in EDGE. While in GPRS the RLC window size is fixed at 64

blocks, in EDGE:

o It is variable and determined for each TBF depending on the MS multi-slot class;

o It varies between 64 and 1024 blocks (512 blocks in Alcatel-Lucent implementation);

o It is increased following an increase on the number of PDCH’s, but not decreased in the case of a

reduction.

2.2 HARDWARE AND POWER ASPECTS

In terms of HW compatibility, EDGE is available (i.e. 8-PSK is supported) in all TRE from G4 (also called TRA)

onward.

In all cases the output power available in GMSK is always greater than in 8-PSK – this is due to design issues

concerning the fact that GMSK is a constant envelope modulation, while 8-PSK is not. Table 2 presents the

output powers of the different EDGE capable TRE’s available.

Table 4: Power characteristics from the different available TRA (EDGE capable TRE’s).

TRA GMSK output power 8-PSK output power 8-PSK output power

(EDGE+ TRA)

900 Medium power 45 W / 46.5 dBm 15 W / 41.8 dBm 30 W / 44.8 dBm

900 High power 60 W / 47.8 dBm 25 W / 44 dBm 30 W / 44.8 dBm

1800 Medium power 35 W / 45.4 dBm 12 W / 40.8 dBm 30 W / 44.8 dBm

1800 High power 60 W / 47.8 dBm 25 W / 44 dBm 30 W / 44.8 dBm

Because GMSK output power is often different from 8-PSK output power, there is a new concept introduced

with EDGE – the Average Power Decrease (APD).

According to the 3GPP specs, there are some constraints on this parameter when the TRE responsible for

the EDGE service is also carrying the BCCH. [3] it states that:

“Furthermore, 8-PSK modulated timeslots on the BCCH carrier may use a mean power which is at most 4 dB

lower than the mean power used for GMSK modulated timeslots, with the exception of the timeslot

preceding a slot used for BCCH/CCCH where at most 2 dB lower mean power is allowed.” (3GPP 45.008

5.i.0, section 7.1)

3GPP also predicts some specific problems for fast moving mobiles, in [3]:

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

“In the case that 8-PSK modulation is allowed on the BCCH carrier and frequency hopping including the

BCCH carrier is used, the reception quality in connected mode for some fast moving MS (meaning MS

experiencing Doppler frequencies of 100 Hz or more) may be degraded. This may be seen as a backwards

compatibility problem for some existing MS, most likely occurring if the used APD is larger than 2 dB.

”(3GPP 45.008 5.i.0, section 7.1)

The field tests performed didn’t show any negative impact, which just confirms that only older mobiles are

prone to have problems, we can say that:

It is possible to use normally the BCCH TRX for EDGE without any re-configuration or output power

modification.

2.3 ENHANCED TRANSMISSION RESOURCE MANAGEMENT

The Enhanced Transmission Resource Management is a feature which assembles 4 sub-features. These sub-

features fit together to create the new transmission concepts brought by B9.

2.3.1 M-EGCH STATISTICAL MULTIPLEXING

The definition of an M-EGCH link (Multiplexed Enhanced GPRS CHannel) is a bi-directional link defined per

TRX and established between the MFS and the BTS. The M-EGCH link is a set of 16kbits/s GCH and its size is

dynamic depending of the GCH established number. The algorithms to dynamically decrease or increase the

size of an M-EGCH link correspond to the Dynamic Abis allocation.

The M-EGCH link of a TRX is necessary:

o To carry TBF traffic and PACCH signalling when TBFs are established on some PDCHs of the TRX,

o To carry signalling messages when MPDCHs are defined on the TRX,

o To carry UL signalling messages after one-UL-block allocation (UL two-phase access),

o To carry some BTS-MFS signalling.

The next figure explains the evolution between B8 and B9 release. The EGCH defined per RTS (PDCH) is

swapped by the new concept of the M-EGCH link per TRX, defined in B9. This enhancement allows the

dynamic of the GCHs among the PDCHs of a TRX. With the change, it is possible to have better reuse of the

existing resources.

Figure 2–1: B8 release EGCH vs B9 release M-EGCH

B8: one EGCH per RTS B9: one M-EGCH link for the whole TRX

0 1 7 6 2 3 4 5

EGCH

0 1 7 6 2 3 4 5 TRX

M-EGCH link

1 to 36 GCHs

composed of

GCH

EGCH

EGCH

EGCH

EGCH

EGCH

EGCH

EGCH

GCH

GCH

GCH

GCH

1 to 5 GCHs depending on the TRX class

GCH

composed of

GCH

GCH

GCH

GCH

TRX


ED 1 RELEASED 011




itted without


The location of the M-EGCH and L1-GCH layers is show in the figure below. The M-EGCH layer offer a service

of data transport to the upper layer the RLC/MAC layer.

Figure 2–2: M-EGCH and L1-GCH layers location

The way the RLC/MAC PDU are filling an M-EGCH link is explained by the next figure.

Figure 2–3: GCH filling with RLC/MAC PDUs

In this example 2 RLC/MAC PDUs are not enough to fill the 5 GCH, therefore the M-EGCH fills it with

padding bits or with a dummy message. Important to mention is the dynamic of the process which lead to a

RLC header

MEGCH header (next segments)

MEGCH header (first segment)

SYNC pattern + Z bit indicator

Padding bits

CRC + Tail bits

MEGCH header (/NHP and addr byte)

Dummy Filling PDU

LEGEND

320 bits 320 bits 320 bits

320 bits

20 ms 20 ms 20 ms

GCH1

GCH2

GCH3

GCH4

RLC/MAC PDU 1 for DBN=x

320 bits

GCH5 Dummy Filling PDU

Dummy Filling

Dummy Filling

Dummy Filling

RLC/MAC PDU 2 for DBN=x

DBN=x+1DBN=x DBN=x+2

MEGCH layer segmentation

sub-layer

RLC/MAC layer

MEGCH layer

framing sub-layer

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

better bandwidth usage. The RLC/MAC PDU is segmented through several M-EGCH frames and one M-EGCH

can transport segments from different RLC/MAC PDUs.

In B8, due to the static approach the number of GCHs needed per PDCH was higher than in B9, see next two

tables.

Table 5: Number of GCH per GPRS coding scheme.

Max_GPRS_CS Nb_GCH in

B8 Nb_GCH in

B9

CS-1 1 0,73

CS-2 1 1,00

CS-3 2 1,25

CS-4 2 1,64

Table 6: Number of GCH per EGPRS coding scheme.

Max_EGPRS_MCS Nb_GCH in

B8 Nb_GCH in

B9

MCS-1 1 0,89

MCS-2 1 1,00

MCS-3 2 1,33

MCS-4 2 1,50

MCS-5 2 1,86

MCS-6 3 2,36

MCS-7 4 3,49

MCS-8 4 4,14

MCS-9 5 4,49

The dynamic transportation of the RLC/MAC PDU brings a more efficient resource usage also due to:

o Instantaneous reaction to radio variations (MCS variations).

o The resources not used by delayed DL TBFs, extended UL TBFs, … are used by other TBFs.

2.3.2 DYNAMIC ABIS ALLOCATION

In B8, the Abis interface has a static allocation of the Abis nibbles (basic + extra) into the RTS. They can

only be used in the EGCH of this RTS, several Abis nibbles are wasted due to the static allocation.

The 64 kbit/s extra Abis TS are mapped per TRX creating the TRX class concept.

As example of the waste of Abis nibbles in B8, for a TRX class 2, there is the next figure:


ED 1 RELEASED 011




itted without


Figure 2–4: Abis resources concept in B8

In this B8 release example, 50% of the Abis resources are wasted, in B9 all the Abis nibbles can be used, as

explained after.

In B9, the following Abis nibbles are usable for PS traffic:

o The basic Abis nibbles mapped to a RTS currently available for PS traffic (see “Autonomous Packet

Resource Allocation" feature to know the list of those RTSs) or mapped to a RTS used as MPDCH.

o The “bonus” basic Abis nibbles are the ones not used by the BCCH or static SDCCH channels, these

channels are mapped in the RSL TS. Depending on the cell configuration more or less “bonus” Abis

nibbles are available.

o All the extra Abis nibbles of the BTS, can be used by the PS. A number of 64k extra Abis TSs

(4x16kbit/s extra Abis nibbles) is defined for each BTS by O&M (N_EXTRA_ABIS_TS). The list of extra

Abis TSs of a BTS is provided by the BSC to the MFS.

To have a better view of the B9 dynamic Abis concept, see the follow example applied in B9:

Figure 2–5: Abis resources concept in B9

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

The 16kbit/s Abis nibbles can be used/shared between M-EGCH link, the share follows specific rules

depending the Abis nibble type:

o The basic Abis nibbles mapped on a RTS allocated to MFS can be used in the M-EGCH link of any TRX

of the CELL.

o The extra Abis nibbles can be used in the M-EGCH link of any TRX of the BTS.

o The “bonus” Abis nibbles can be used in the M-EGCH link of any TRX of the BTS.

This new algorithm/concept leads into a modification of the GCH establishment and release. Two new

scenarios to distribute GCH resources are created:

o Intra-cell GCH pre-emption : between TRXs of a cell

o Inter-cell GCH pre-emption : between cells of a BTS

To be able to implement the dynamic Abis algorithm new signalling messages were created, they are sent to

the BTS via GSL and RSL interface to notify each TRE which Abis nibbles are associated.

2.3.3 ATER RESOURCE MANAGEMENT

In this sub-chapter is resumed the Ater resource management in load situation, anticipation and defence

mechanism. A strong requirement, in B9 implementation, is to ensure GPRS access in all the cells of the

GPU (no cell shall be blocked due to Ater congestion).

In a given GPU the resource management is based on two complementary algorithms:

o GPU Ater TS margin

o “High Ater usage” handling.

GPU 64KBIT/S ATER TS MARGIN

The aim of the GPU Ater TS Margin, managed in each GPU, is to ensure that priority requests can never be

blocked in a cell due to a lack of Ater resources in the GPU.

The priority requests are the GCH establishment requests for the “first PS traffic in a cell” (first TBF to

establish in a cell). E.g when the first One-UL-Block or best-effort TBF has to be established in a cell.

The GPU Ater TS Margin mechanism is trigger to release some GCHs when the remaining number of free 64k

Ater TSs in the GPU becomes lower than a threshold defined by the parameter N_ATER_TS_MARGIN_GPU.

The parameter N_ATER_TS_MARGIN_GPU is defined in the O&M and can be tunable.

HIGH ATER USAGE HANDLING

The Ater usage of a GPU represents the consumption of Ater nibbles (by GCH channels) among the PCM links

connected to the GPU. The state of the Ater usage can be either “normal” or “high”.

The decision to evaluate the Ater usage state is based on the comparison of the Ater nibble consumption

with a threshold. This threshold is the O&M parameter Ater_Usage_Threshold.

If Ater usage is “high”, there is an impact in the packet switch transmission resources. The Target_Nb_GCH

values associated to TRXs of the GPU supporting some PS traffic will be reduced, taking in account the

parameter GCH_RED_FACTOR_HIGH_ATER_USAGE.

The reduction factor is only applied on PDCHs newly open, e.g. no radio resources were previously

allocated on this PDCH.


ED 1 RELEASED 011




itted without


In the next example the reduction method is presented:

1)Hypothesis:

o Max_EGPRS_MCS = MCS-9,

o GCH_RED_FACTOR_HIGH_ATER_USAGE = 0,5

2) Ater usage = “normal”

3) Establishment of an EGPRS DL TBF on RTS0-3

o Target_Nb_GCH = 4 * Nb_GCH(Max_EGPRS_MCS) = 4 * 4,49 = 18

4) Ater usage = “high”

5) Establishment of an EGPRS DL TBF on RST4-7

(Ater usage high and newly open PDCH => reduction will be applied)

o Target_Nb_GCH =

• = 4 * Nb_GCH(Max_EGPRS_MCS) + 0,5 * 4 * Nb_GCH(Max_EGPRS_MCS) =

• = 4 * 4,49 + 4 * 0,5 * 4,49 = 27 (< 36)

2.3.4 DL RETRANSMISSION IN THE BTS

The feature DL Retransmission in the BTS was developed with the aim to avoid consuming transmission

resources (Abis + Ater) in case of DL RLC data block retransmissions.

The principles of the feature is simple, the DL RLC data blocks, received from the MFS to a MS, are store in

a buffer. These blocks are keeped in the memory of the TRE involved in the packet transfer mode with the

MS, during a pre-define period. Then, if Dl retransmission is needed, the RLC/MAC layer (in the MFS) ask

the TRE (in the BTS) to retransmit the specific DL RLC data blocks.

This mechanism is enabled / disabled at TRX/TRE level, however respecting the following constrains

specified in the next table:

Table 7: DL retransmission constrains.

HW generation of the TRE

CS-2 CS-4 CS-4+MCS-9 EN_DL_RETRANS_BTS Round_Trip_Delay

(DRFU) (G3 or M4M) (G4 or M5M)

Enabled < 500 ms Disabled Disabled Enabled

Enabled ≥ 500 ms Disabled Disabled Disabled

Disabled - Disabled Disabled Disabled

2.4 AUTONOMOUS PACKET RESOURCE ALLOCATION (RAE4)

Before the explanation of the new B9 resource allocation a brief review of the B8 resource allocation is

done.

In B8, the BSC evaluates the maximum number of timeslots (load indication) that the MFS could use to carry

PS traffic (Max_SPDCH_Dyn). This value is sent periodically to the MFS, however the MFS does not have the

information of which timeslots are usable for PS traffic, it just knows the number. To serve a new TBF, MFS

needs to request new timeslots mapping to the BSC. This “Event-triggered” mechanism creates delays in

the PS access time.

With the introduction of the Enhanced Transmission Resource Management feature in B9, a new resource

allocation was developed. This new algorithm is named Autonomous Packet Resource Allocation (RAE4) and

allows taking all the benefit of the new B9 concepts.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

The development took in consideration the following new needs:

o Need to know the list of basic Abis nibbles which are currently available to establish GCHs,

o Need to know which basic Abis nibbles are preemptable / not-preemptable for CS traffic by the

BSC. This information is useful:

• For the QoS feature (in order to be able to ensure a given GBR for an RT PFC).

• To define some priorities in the Abis nibble selection (preference is given to the non-

preemptable basic Abis nibbles in order to limit the interaction of CS over PS traffic).

o Need to accelerate TBF establishment times (the B8 round trip delay between MFS and BSC to

allocate some PDCHs can be avoided).

In the Autonomous Packet Resource Allocation (RAE4) algorithm the BSC evaluates the CS and PS load at cell

level and calculates a number of timeslots that the MFS can use to carry PS traffic (Max_SPDCH_Limit). The

resources sharing between the CS and the PS is then based on the evaluation of Max_SPDCH_Limit.

The Max_SPDCH_Limit value is a comprised value between the Min_SPDCH and the Max_SPDCH and takes in

account the O&M parameters (Max_PDCH, Min_PDCH, Max_PDCH_HIGH_LOAD, HIGH_TRAFFIC_LOAD_GPRS,

THR_MARGIN_PRIO_PS).

Exists a periodical exchange of messages between the BSC and the MFS, with the aim to inform the MFS

which timeslots can be used to serve a new TBF and to inform the BSC of the present status of PS allocated

resources.

The periodical exchange of messages has the following information:

o RR Allocation Indication message from BSC to MFS: provide to the MFS the mapping of the allocated

SPDCHs, the periodicity of this message is TCH_INFO_PERIOD * RR_ALLOC_PERIOD.

o RR Usage Indication message from MFS to BSC: With a periodicity of TCH_INFO_PERIOD or in

response of the previous message RR Allocation Indication message, informs the BSC with the

current usage of the allocated SPDCHs.

CELL LOAD EVALUATION

The BSC evaluates for each cell the CS and PS load, the process starts with the calculation of the current

usage of the resources, e.g a sample of the current usage on TCH, TCH/SDCCH and TCH/SPDCH TS. This

cyclic process is done every TCH_INFO_PERIOD.

Figure 2–6: Cyclic calculation of the usage of the cell resources

The TCH usage samples calculate by the BSC every TCH_INFO_PERIOD are map in the internal parameters:

o NB_USED_CS_TS(k) - SPDCH State is deallocated

o NB_USED_PS_TS(k) - SPDCH State is allocated or de-allocating

o NB_USED_TS(k) = NB_USED_CS_TS(k) + NB_USED_PS_TS(k)

o NB_UNUSED_TS(k)

TCH_INFO_PERIOD = 5s NB_USED_CS_TS(k) NB_USED_PS_TS(k) NB_USED_TS(k)

NB_UNUSED_TS(k)


ED 1 RELEASED 011




itted without


Every RR_ALLOC_PERIOD * TCH_INFO_PERIOD, the BSC computes three averaged values through a sliding

window of size LOAD_EV_PERIOD_GPRS (default value = 3), these averages of the previous internal

parameter give the following internal parameters, used to calculate Max_SPDCH_Limit:

o AV_USED_CS_TS(k)

o AV_USED_PS_TS(k)

o AV_UNUSED_TS(k)

Figure 2–7: Cyclic calculation of the average usage of the cell resources

MAX_SPDCH_LIMIT CALCULATION

The calculation of the Max_SPDCH_Limit follows the diagram below:

Figure 2–8: General diagram of the Max_SPDCH_Limit calculation

TCH_INFO_PERIOD = 5s

AV_USED_CS_TS(k) AV_USED_PS_TS(k) AV_UNUSED_TS(k)

NB_USED_CS_TS(k) NB_USED_PS_TS(k) NB_USED_TS(k) NB_UNUSED_TS(k)

k k-k-

LOAD_EV_PERIOD_GPRS = 3

k+ k+

AV_USED_CS_TS(k+2) AV_USED_PS_TS(k+2) AV_UNUSED_TS(k+2)

RR_ALLOC_PERIOD * TCH_INFO_PERIOD

MAX_SPDCH_HIGH_LOAD

Computation of CS/PSMargin

AV_USED_CS_TSAV_USED_PS_TSAV_UNUSED_TSNB_TS_DEFINED

NB_TS_SPDCH

Computation ofThresholds

THR_MARGIN_PRIORITY_CSTHR_MARGIN_PRIORITY_PS

NB_TS

MARGIN_PRIORITY_CSMARGIN_PRIORITY_PS

Computation ofMAX_SPDCH_LIMIT

MAX_PDCH_HIGH_LOADMAX_PDCHMIN_PDCH

NB_TS_MPDCH

MAX_SPDCH_LIMIT

MIN_SPDCHMAX_SPDCH

O&M parameters

O&M parameter

= 100 – HIGH_TRAFFIC_LOAD_GPRS

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

1) Computation of thresholds

The calculation of MIN_SPDCH, MAX_SPDCH and MAX_SPDCH_HIGH_LOAD is done every RR_ALLOC_PERIOD *

TCH_INFO_PERIOD to take into account possible TRX failures. The O&M parameters (MIN_PDCH, MAX_PDCH

and MAX_PDCH_HIGH_LOAD) are multiply by the ratio:

o AVAILABILITY_TS_RATIO(k) = NB_TS(k) / NB_TS_DEFINED

Where:

NB_TS: Total number of TCH/VGCH, TCH/SDCCH, or TCH/SPDCH/VGCH timeslots available in the cell. This

parameter is re-computed every RR_ALLOC_PERIOD * TCH_INFO_PERIOD to take into account possible TRX

failure.

NB_TS_DEFINED: total number of TCH, TCH/SDCCH or TCH/SPDCH timeslots available in the cell if there is

no TRX failure. This parameter is retrieved from the O&M configuration of the cell.

In case there isn’t master channel (NB_TS_MPDCH=0) and there is no TRX failure

(AVAILABILITY_TS_RATIO=100%) then there is simply:

o MAX_SPDCH_HIGH_LOAD = MAX_PDCH_HIGH_LOAD

o MIN_SPDCH = MIN_PDCH

o MAX_SPDCH= MAX_PDCH

2) Computation of CS/PS Margin

Two new margins, one for CS traffic and one for PS traffic are introduced to guarantee that a certain

number of timeslots are kept available for the arrival of new calls between two transmissions of the RR

Allocation Indication message:

o the first margin, named MARGIN_PRIORITY_CS (k), is dedicated to CS traffic

• = (THR_MARGIN_PRIO_CS * (NB_TS(k) – MAX_SPDCH_HIGH_LOAD(k)) / 100

o the second margin, named MARGIN_PRIORITY_PS(k), is dedicated to PS traffic

• = (THR_MARGIN_PRIO_PS * MAX_SPDCH_HIGH_LOAD(k)) / 100

Where:

THR_MARGIN_PRIO_PS is O&M parameter, It is the margin of radio timeslots reserved for PS traffic between

two sendings of the BSCGP RR Allocation Indication messages. The threshold is expressed in percentage of

radio timeslots. This margin only applies in case of high CS load and low PS load.

THR_MARGIN_PRIO_CS is equal to the 1- High_Traffic_ Load_GPRS.

High_Traffic_ Load_GPRS: Load threshold used to determine a certain margin of radio timeslots reserved for

CS traffic between two sending of the BSCGP RR Allocation Indication messages. The threshold is expressed

in percentage of the radio timeslots available in the cell.

These two margins are re-evaluated every RR_ALLOC_PERIOD * TCH_INFO_PERIOD, before the computation

of MAX_SPDCH_LIMIT

3) Computation of MAX_SPDCH_LIMIT

The basic idea to evaluate MAX_SPDCH_LIMIT is to estimate the number of unused TS and to share them

between CS and PS traffic, taking into account both margins (for CS and PS traffics) defined to guarantee a

certain number of TS available to serve incoming calls.


ED 1 RELEASED 011




itted without


Figure 2–9: Detailed diagram of the Max_SPDCH_Limit calculation

3.1) Computation of MAX_SPDCH_LIMIT_CS

The MAX_SPDCH_LIMIT_CS determines the maximum number of SPDCHs that can be allocated to the MFS in

order to ensure that a certain number of timeslots (margin) is kept in the BSC to serve possible incoming CS

requests, received between two sends of the RR Allocation Indication message. It is given by:

o MAX_SPDCH_LIMIT_CS(k) = RoundDown [ NB_TS(k) – AV_USED_CS(k) - MARGIN_CS(k) ]

Where:

o MARGIN_CS(k) = max(MARGIN_PRIORITY_CS(k), AV_UNUSED_TS(k) / 2)

3.2) Computation of MAX_SPDCH_LIMIT_PS

The MAX_SPDCH_LIMIT_PS determines the minimum number of SPDCHs that should be allocated to the MFS

in order to ensure that a certain number of timeslots (margin) is kept in the MFS to possibly serve incoming

PS requests.

If AV_USED_PS_TS(k) ≤ MIN_SPDCH then

o MAX_SPDCH_LIMIT_PS(k) = MIN_SPDCH(k)

else

o MAX_SPDCH_LIMIT_PS(k) = RoundUp (AV_USED_PS_TS(k) + MARGIN_PRIORITY_PS(k))

3.1) Computation of MAX_SPDCH_LIMIT

The MAX_SPDCH_LIMIT calculation can be in the range of [MIN_SPDCH, MAX_SPDCH] and its value can be

either MAX_SPDCH_LIMIT_CS or MAX_SPDCH_LIMIT_PS.

Computation ofMAX_SPDCH_LIMIT_CS

MARGIN_PRIORITY_CS

AV_USED_CS_TS(k)AV_UNUSED_TS(k)

MAX_SPDCH_LIMIT_CS(k)

Computation ofMAX_SPDCH_LIMIT_PSAV_USED_PS_TS(k)

MAX_SPDCH_LIMIT_PS(k)

MIN_SPDCHMARGIN_PRIORITY_PS

Computation ofMAX_SPDCH_LIMIT

MAX_SPDCHMAX_SPDCH_HIGH_LOAD

MAX_SPDCH_LIMIT(k)

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Figure 2–10: Max_SPDCH_Limit CS and PS zones

MAX_SPDCH_LIMIT TS SELECTION

Every TCH_INFO_PERIOD * RR_ALLOC_PERIOD, the BSC sent to MFS the Radio Resource Allocation Indication

message. This message contains the SPDCHs Allocation bitmap, e.g the information whether a timeslot is

allocated to the MFS or not. In response to the RR Allocation Indication message or every

TCH_INFO_PERIOD, the MFS sent to BSC the Radio Resource Usage Indication message.

The RR Usage Indication message contains 3 different bitmaps, the analysis of the bitmaps gives the present

status of the timeslots:

o The SPDCHs_Confirmation bitmap is used to update the SPDCH allocation state of each timeslot.

o The SPDCHs_Usage and SPDCHs_Radio_Usage bitmaps allow to update the occupancy state of the

timeslot at “unused” or “used” (from radio and/or transmission point of view for the SPDCHs_Usage

bitmap and from radio point of view only for the SPDCHs_Radio_Usage bitmap).

The TS selection, e.g the Radio TCH allocation, uses the TRX ranking table. This table takes in account both

HW capability and design O&M parameters. The way to set the priority of the PS capable TRX

(TRX_PREF_MARK = 0) is slightly modified in B9 release with the introduction of a frequency band criterion:

o PS_PREF_BCCH_TRX

o HW TRE capability (G4 HP -> G4 MP -> G3)

o DR TRE capability (FR TRX -> DR TRX)

o E-GSM TRX preference (new in B9, E-GSM TRX -> P-GSM/GSM850/DCS TRX)

o TRX having the maximum number of consecutive SPDCHs

o TRX identity (low TRX id -> high TRX id)

With the PS capable TRX list performed, the next step consists in ordering the PS timeslots and the PS

capable TRX, to obtain an ordered list of TCH/SPDCH timeslots. The selection of the TRX is done, selecting

first the TRX having the lowest rank in the TRX ranking table. Once the TRX has been selected, the

Zone where MAX_SPDCH_LIMIT = MIN( MAX_SPDCH,

MAX_SPDCH_LIMIT_CS)

Zone where MAX_SPDCH_LIMIT = MIN (MAX_SPDCH_LIMIT_PS,

MAX_SPDCH_HIGH_LOAD)

0

MAX_SPDCH

MAX_SPDCH_HIGH_LOAD

MIN_SPDCH

MIN_SPDCH

MAX_SPDCH_LIMIT_CS

MAX_SPDCH_HIGH_LOAD MAX_SPDCH

MAX_SPDCH_LIMIT_PS


ED 1 RELEASED 011




itted without


TCH/SPDCH timeslots is selected preferentially to the lowest timeslot index, i.e. the one located at the

most left side of the TRX is selected first.

The SPDCHs are allocated according to the different PS TS zones, the zones definitions are:

o MAX_SPDCH_HIGH_LOAD zone: this zone corresponds to the MAX_SPDCH_HIGH_LOAD consecutive PS

capable TS that are preferred for PS allocation. In this zone, allocated TBFs cannot be pre-empted

o Non pre-emptable PS zone: this zone is always inside the MAX_SPDCH_HIGH_LOAD zone, in this

latter zone, we search for the right most TS allocated to the MFS and used, then all the TS located

at its left define the non pre-emptable PS zone. Inside this zone, a TS:

• remains allocated to the MFS if already allocated to the MFS

• is allocated to the MFS if previously allocated to the BSC and unused

• remains allocated to the BSC if already allocated to the BSC and used

o MAX_SPDCH_LIMIT zone: this zone corresponds to the MAX_SPDCH_LIMIT consecutive PS capable TS

that are preferred for PS allocation. Inside this zone, a TS:

• remains allocated to the MFS if already allocated to the MFS

• is allocated to the MFS if previously allocated to the BSC and unused

• remains allocated to the BSC if already allocated to the BSC and used

o PS traffic zone: this zone corresponds to the larger zone between the non pre-emptable PS zone

and the MAX_SPDCH_LIMIT zone

As examples of the PS TS zones follows the next two:

Example 1: MAX_SPDCH_HIGH_LOAD = 8, MAX_SPDCH_LIMIT = 10

Figure 2–11: PS TS zones – example 1

This feature should be enhanced, so that the number of allocated PDCH corresponds to MAX_SPDCH_LIMIT

Example 2: MAX_SPDCH_HIGH_LOAD = 8, MAX_SPDCH_LIMIT = 3

Figure 2–12: PS TS zones – example 2

TRX2 TRX11 3 42 5 6 7 8 9 10 1211 13 14 15 16

MAX_SPDCH_LIMIT zone

PS CSPS CS CSCS CS

MAX_SPDCH_HIGH_LOAD zone

PS PS PS PS

Non pre-emptable PS zone

PS traffic zone

TRX2 TRX11 3 42 5 6 7 8 9 10 1211 13 14 15 16

MAX_SPDCH_LIMIT zone

PS CSPS CS CSCS CS

MAX_SPDCH_HIGH_LOAD zone

PS CS CS

Non pre-emptable PS zone

PS traffic zone

CS

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

The selection of the TCH/SPDCH TS begins with the non pre-emptable PS zone. All the TS in this zone, that

can be or are allocated to the MFS, will be allocated to the MFS. The verification in terms of number of TS

allocated to the MFS is done only when all the TS inside this zone have been handled. If at the end of the

non pre-emptable PS zone, the number of selected TS for the MFS is strictly lower than MAX_SPDCH_LIMIT

then the process of selection continues in the MAX_SPDCH_LIMIT zone

If at the end of the MAX_SPDCH_LIMIT zone, the number of selected TS for the MFS is still lower than

MAX_SPDCH_LIMIT, the process continues outside this zone until this number reaches MAX_SPDCH_LIMIT.

Once MAX_SPDCH_LIMIT TS have been selected, all the remaining TCH/SPDCH TS are now allocated to the

BSC, even if they were previously allocated to the MFS. This means that a TS with a SPDCH allocation state

set to “allocated” has its SPDCH allocation state set to “de-allocating”.

To improve the SPDCH allocation, two parallel algorithms to PS TS selection exist:

1) Pre-reservation mechanism in the PS traffic zone:

In order to increase the PS capacity and limit the occurrence of holes in the SPDCHs_Allocation bitmap,

each TCH/SPDCH capable TS carrying CS traffic and located inside the PS traffic zone, has its pre-

reservation state set to “pre-reserved for PS”. No new incoming CS call can be served on this TS, if it

becomes unused once it is “pre-reserved for PS”. This is valid until the TS becomes “not pre-reserved for

PS” again and of course still handled by the BSC. The modification of the value of the pre-reservation state

can only occur when the SPDCHs_Allocation bitmap is built, every TCH_INFO_PERIOD * RR_ALLOC_PERIOD

seconds.

2) CS calls in the Non pre-emptable PS zone:

To speed up the release of TS carrying a CS call inside both the non pre-emptable PS zone and the

MAX_SPDCH_LIMIT zone, it is proposed to reallocate the concerned CS call in the CS zone using an intra-cell

handover.

If EN_RETURN_CS_ZONE_HO = enabled, each time MAX_SPDCH_LIMIT is calculated, the BSC shall check

whether TCHs are allocated in both the MAX_SPDCH_LIMIT zone and the non pre-emptable PS zone. In this

case, it shall send a ‘Start HO (cause 30)” message to the HO Preparation entity, to trigger an intracell

handover, to move these TCHs into the CS zone

If for any reason, the handover fails, the TCH will remain in the PS zone, until the next calculation of

MAX_SPDCH_LIMIT, where a new HO could be triggered, if still needed.

The TS will be considered as unused only once the handover will have been successfully performed. As the

pre-reservation state of such TS is set to “pre-reserved for PS”, no new incoming CS call can be allocated

on it.

CS PREEMPTION PROCESS

The CS pre-emption process is triggered when some radio TS are reported by the BSC as no longer allocated

to the MFS. The principle can be explained by 5 steps:

1. MFS receives a RR Allocation Indication message from the BSC, and uses the SPDCHs_Allocation

bitmap to determine which SPDCHs shall be given back to the BSC

2. then, MFS shall immediately send a RR Usage Indication message to the BSC with the

SPDCHs_Confirmation bitmap

• SPDCHs not used are immediately given back to the BSC (Note : SPDCHs are considered not

used if no TBF resources are allocated on those SPDCHs and their basic Abis nibbles are

free). The associated basic Abis nibbles are also given back and others TBFs using these

basic Abis nibbles can be impacted (see below).

3. After RR Usage Indication, TCH_INFO_PERIOD timer is restarted. Remaining impacted SPDCHs,

which are in use (at least one TBF is established on those SPDCHs or the basic Abis nibbles of those


ED 1 RELEASED 011




itted without


SPDCHs are used by a GCH channel), are marked as “de-allocating”.

4. The CS pre-emption process shall be completed before the TCH_INFO_PERIOD expiry, in order to

confirm the deallocation of all the remaining pre-empted SPDCHs in the next RR Usage Indication

message to be sent to the BSC. For that purpose, the internal T_PDCH_Preemption timer is set to

TCH_INFO_PERIOD - 1s

5. When T_PDCH_Preemption expires, the fast preemption is launched.

Then, once the impacted best-effort TBFs have been determined, the following steps shall be played in

sequence:

1) TBF release in case of too high number of TBFs

If, due to the CS preemption, the number of best-effort TBFs established on a TRX will become too high

according to the remaining number of GCHs in the M-EGCH link of the TRX, then some best-effort TBFs shall

be released (in order to guarantee that the T_MAX_FOR_TBF_SCHEDULING constraints / the PACCH

signalling traffic constraints will still be possible to fulfil for all the remaining best-effort TBFs established

on the TRX).

On a given TRX, the number of TBFs to be released in the XL direction is called Nb_TBFs_To_Release_XL.

The Nb_TBFs_To_Release_XL TBFs which shall be released are selected as follows:

o Release preferentially the best-effort XL TBFs which are impacted by the CS preemption (i.e. the

best-effort TBFs established in the XL direction and whose PACCH is impacted or whose on-going

max allowed (M)CS is no longer possible to serve).

o Then, release preferentially the best-effort XL TBFs which were established (or reallocated) on the

TRX the most recently (i.e. the “newest” best-effort TBFs established in the XL direction on the

TRX).

2) T1 TBF reallocation

The not released TBFs are attempted to be T1 reallocated (soft-preemption process).

Figure 2–13: T1 reallocation

The TBFs impacted by the CS preemption are managed by the soft preemption process, the impacted best-

effort TBFs are:

o The best-effort TBFs having their PACCH impacted, i.e. their PACCH is supported by a preempted

RTS (that case is valid for both Evolium and DRFU BTSs),

o The best-effort TBFs for which it will no longer be possible to serve their on-going max allowed

(M)CS because of the subsequent reduction of the M-EGCH link size of their TRX. Note: the M-EGCH

DL

0 1 2 3 4 5 6 7

UL

0 1 2 3 4 5 6 7

No T1 candidate

T1 candidate

M-EGCH EGPRS TBF

TRX

2 preempted GCHs Max_EGPRS_MCS = MCS9 ⇒ 5 GCHs needed

4 GCHs

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

links whose size will be reduced can be on the TRX containing the preempted RTSs or on any of the

other TRXs of the cell (because basic Abis nibbles are shareable among all the TRXs of the cell).

2.5 M-EGCH LINK MANAGEMENT

2.5.1 DEFINITIONS

The following concepts are used in the M-EGCH link management:

o TRX capabilities for GPRS (maximum CS) and for EGPRS (EGPRS possible or not, maximum MCS) are

defined at MFS side using:

• HW PS capability for each TRX,

• Max_GPRS_CS O&M parameter,

• En_EGPRS O&M parameter,

• Max_EGPRS_MCS O&M parameter.

Table 8: HW PS capability

TRE generation HW PS capability of the TRX

G2 (TRE in a DRFU BTS) CS-1/2

G3 (TRE in an Evolium BTS) CS-1/4

G4 (TRE in an Evolium BTS) CS-1/4 + MCS-1/9

o TRX is said “established” if there is an M-EGCH link associated to this TRX with GCHs.

o Non CS Preemptable GCH: GCH, whose Abis nibble is not CS preemptable:

• Extra Abis nibble,

• “Bonus” Abis nibble,

• Basic Abis nibble mapped on a RTS inside the “Max_SPDCH_High_Load” zone.

o CS Preemptable GCH: GCH, whose Abis nibble is CS preemptable:

• Basic Abis nibble mapped on a RTS outside the “Max_SPDCH_High_Load” zone.

2.5.2 ABIS SELECTION IN M-EGCH LINK

When establishing new GCHs in the M-EGCH link of a given TRX, the free Abis nibbles are selected with the

following priorities:

1. Free basic Abis nibbles mapped to RTSs currently available for PS traffic and within the

Max_SPDCH_High_Load zone of the cell,

2. Free extra Abis nibbles and free bonus Abis nibbles,

3. Free basic Abis nibbles mapped to RTSs currently available for PS traffic and out of the

Max_SPDCH_High_Load zone of the cell.

If there aren’t enough free Abis nibbles, or free Ater nibbles, then GCH preemption will be used:

o The inter-cell GCH preemptions for PS traffic (the “source TRX” and the “target TRX” belong to two

different cells of the same BTS).

o The intra-cell GCH preemptions for PS traffic (the “source TRX” and the “target TRX” belong to the

same cell)


ED 1 RELEASED 011




itted without


2.5.3 M-EGCH LINK SIZE

As mention in the chapter 2.3.1 the M-EGCH link is defined per TRX, its size in the TRX is expressed in

number of GCHs. For each TRX, the following variables are defined:

o Established_Nb_GCH: Number of GCHs that are activated in the M-EGCH link.

o Established_Non_CS_Preemptable_Nb_GCH: Established_Nb_GCH when only GCHs using extra Abis

nibbles, bonus basic Abis nibbles and basic Abis nibbles mapped to RTSs within the non preemptable

PS zone of the cell are considered.

o Target_Nb_GCH: An estimation of the number of GCHs necessary in a given M-EGCH link to carry the

signalling and data PS traffic. A target number of GCHs, which may of course not be reached in

transmission resource (Abis and/or Ater) congestion situations.

• Target_Nb_GCH is a function of:

� Number of PDCHs on the TRX, on which radio resources have been allocated for BE

TBFs.

� Max_GPRS_CS and Max_EGPRS_MCS O&M parameter values.

� Number of GCH needed per PDCH for Max_GPRS_CS / Max_EGPRS_MCS

(Nb_GCH(Max_GPRS_CS / Max_EGPRS_MCS)).

� Whether Ater Usage in the GPU is high or not. If it is high, the value of

Target_Nb_GCH is reduced so as to decrease the global Ater resource consumption

in the GPU.

• The following example explains the Target_Nb_GCH evaluation for a EGPRS TBF and for

GPRS TBF (In this example, it is supposed that the Ater usage of the GPU is not “high”):

� M–EGCH link of a TRX supporting one 4-TS EGPRS TBF (Max_EGPRS_MCS = MCS-9)

• Target_Nb_GCH = 4 * 4.49 = 18 GCHs

� M-EGCH link of a TRX supporting one 4-TS GPRS TBF (Max_GPRS_CS = CS-4)

• Target_Nb_GCH = 4 * 1.64 = 7 GCHs

o Min_Nb_GCH: An estimation of the minimum number of GCHs, necessary in a given M-EGCH link, is

used as threshold when GCH preemption is performed. It ensures that all the TBFs established on

the TRX will always be able, on at least one PDCH, to send a Radio Block with their

Max_Allowed_(M)CS.

The Target_Nb_GCH and Min_Nb_GCH are updated at TBF allocation / reallocation and at TBF release.

A new M-EGCH link is established each time there is new PS traffic in a TRX without a M-EGCH link

established. It can also be due to the “Fast Initial PS Access” feature.

Some GCHs are added to an existing M-EGCH link, when new TBF is allocated on the TRX and

Target_Nb_GCH becomes strictly higher than Established_Nb_GCH. Also it can be due to the “Fast Initial PS

Access” feature or when performing the “Periodical GCH establishment” process.

2.5.4 PERIODICAL GCH ESTABLISHMENT PROCESS

A periodical GCH establishment process aims at periodically attempt to increase the M-EGCH link size of

TRXs, which have not yet reached their Target_Nb_GCH. It is defined in each cell of a BTS.

The “periodical GCH establishment process” allows:

o The usage of the recently freed Abis/Ater transmission resources in the BTS/GPU due to GCH

releases.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

o The usage of the free basic Abis nibbles mapped to RTSs out of the “non preemptable PS zone” of

the cell.

o To guarantee that, following some abnormal GCH releases, new GCHs will be established in the

impacted M-EGCH links.

o To guarantee a balance between the M-EGCH link sizes of the TRXs of a given cell after some TBFs

(established on those TRXs) have been released.

o To guarantee that some GCHs are inter-cell preempted towards the M-EGCH links of the cell. This

can be useful for example following the release of an RT PFC in another cell of the same BTS.

o To guarantee that some GCHs are always established for the “Fast Initial PS Access” feature

2.5.5 FAST INITIAL PS ACCESS

The aim of the feature Fast Initial PS Access is to speed up the TBF establishment time in a cell. It ensures

that one M-EGCH link is always established on the first TRX of the cell having some allocated TSs, i.e. for

the most PS-prioritary TRX of the cell having some TSs available for PS traffic. The feature is enabled at

cell-level with the EN_FAST_INITIAL_GPRS_ACCESS O&M parameter and the number of GCHs to establish on

this M-EGCH link is tunable by the N_GCH_FAST_PS_ACCESS system parameter.

2.5.6 HANDLING OF UNUSED GCH

When a TBF is released and Target_Nb_GCH of M-EGCH link becomes strictly lower than

Established_Nb_GCH, there is in the M-EGCH link (Established_Nb_GCH- Target_Nb_GCH) unused GCHs, e.g

established GCHs that are considered to be no more needed in the M-EGCH link.

Each time the previous condition happens, the T_GCH_Inactivity timer of the M-EGCH link is started. This

timer is useful to:

o “Anticipate” the arrival of new PS traffic on a given TRX.

o Provide some time for the “radio defragmentation” process to be completed in the cell (cf. T3 TBF

reallocations).

o Optimize ping times.

o Make the Ater nibbles of the released GCHs (on T_GCH_Inactivity timer expiry) usable by other

BTSs, or by other DSPs (if all the 4 nibbles of the 64k Ater TS are freed).

o If there is some PS traffic on another TRX in the cell while the T_GCH_inactivity timer is running,

then the “unused GCHs” can be intra-cell preempted to meet the GCH needs (if any) of that other

TRX. That avoids an Abis-Ater deswitching operation followed by a reswitching operation in the BSC.

This principle is only applicable to intra-cell GCH preemptions, not to inter-cell GCH preemptions.

At timer expiry, if Target_Nb_GCH is still strictly lower than Established_Nb_GCH, the unused GCHs are

released, the choice of GCHs to release is the reverse order than the one used for GCH establishment.

If the last TBF in the cell is released, a number of GCHs shall be kept established during the

T_GCH_Inactivity_Last time. The number of GCHs is defined at O&M by the parameter

N_GCH_Fast_PS_Access_GCH. Those GCHs will be useful in case of (E)GPRS traffic resumption in the cell

(when the “Fast Initial PS Access” feature is not enabled).


ED 1 RELEASED 011




itted without


Figure 2–14: Handling of unused GCHs

2.5.7 M-EGCH LINK CAPACITY DECREASE

There can be four reasons to have a M-EGH link capacity decrease, e.g a number of GCH is removed from an

M-EGCH link of a TRX:

o When a TBF is released and Target_Nb_GCH becomes strictly lower than Established_Nb_GCH

(unused GCHs and inactivity timer mechanism).

o GCH preemption: inter-cell and intra-cell.

o CS preemption: a basic Abis nibble used in the M-EGCH link is mapped on a RTS that must be given

back to the BSC (“CS preempted” RTS).

o Abnormal GCH release.

2.6 TBF RESOURCE ALLOCATION/REALLOCATION

In this chapter only Best-effort TBF (Non Real Time) resource allocation is considered.

2.6.1 TBF RESOURCE ESTABLISHMENT PROCESS

The TBF resource establishment process operates in two steps:

1. Radio Resource Allocation Algorithm: the objective of this algorithm is to find the best candidate

timeslot allocation and verify if enough transmission resource are available. This topic is discussed in

the next sub-chapter

2. TBF Establishment: if the RR allocation is performed then the TBF establishment is possible according

to the following conditions:

o TBF allocation policy:

• ASAP: used for BE (Best Effort) TBF establishment, T1, T2 and T4 reallocation. Its goal is to

serve the request as soon as possible.

� If it is possible, an ASAP request is served immediately on a TRX having already

Nb_GCH_For_TBF_Estab established GCHs. Otherwise, the establishment of

M-EGCH link

7 “used” GCHs

GCH1 B ≤ HL

GCH2 B ≤ HL

GCH3 B ≤ HL

GCH5 Extra

GCH4 Extra

GCH7 B > HL

GCH6 B > HL

Established_Nb_GCH = 10

3 “unused” GCHsGCH9 B > HL

GCH8 B > HL

GCH10 B > HL


Target_Nb_GCH = 7

M-EGCH link

7 “used” GCHs

GCH1 B ≤ HL

GCH2 B ≤ HL

GCH3 B ≤ HL

GCH5 Extra

GCH4 Extra

GCH7 B > HL

GCH6 B > HL

GCH1 B ≤ HL

GCH2 B ≤ HL

GCH3 B ≤ HL

GCH5 Extra

GCH4 Extra

GCH7 B > HL

GCH6 B > HL



GCH8 B > HL

GCH10 B > HL



GCH8 B > HL

GCH10 B > HL

GCH9 B > HL

GCH8 B > HL

GCH10 B > HL


Target_Nb_GCH = 7“B > HL”: GCH uses a basic Abisnibble mapped on a RTS out of the “non preemptable PS zone” of the cell.“Extra”: GCH uses an extra Abisnibble or a “bonus” basic Abis nibble.“B ≤ HL”: GCH uses a basic Abisnibble mapped on a RTS within the “non preemptable PS zone” of the cell.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Nb_GCH_For_TBF_Estab GCHs on a TRX of the cell will be necessary to serve the

request.

• OPTIMAL: used for T3 reallocation. Its goal is to ensure that a significant bandwidth will be

offered to the MS upon T3 reallocation, even if it takes some time to establish all the

necessary GCHs

� All the possible GCHs (Target_Nb_GCH) are systematically requested to be

established before serving the request, and an “Optimal” request will only be

served if the total number of GCHs successfully established on the TRX is greater

than Nb_GCH_For_TBF_Estab (see below).

o Max allowed (M)CS determination of a TBF depends on the type of TBF (GPRS / EGPRS) and of the

direction of the TBF (UL / DL). It is limited by the:

The number of established GCHs: Nb_GCH

Table 9: Maximun allowed CS.

Nb_GCH Max_Allowed_CS

1 CS-2 (UL) / CS-1 (DL)

2 ≥ CS-4

Table 10: Maximun allowed MCS.

Nb_GCH Max_Allowed_MCS

1 MCS-2 (UL) / MCS-1 (DL)

2 MCS-5

3 MCS-6

4 MCS-7

5 ≥ MCS-9

• GPRS / EGPRS TRX capability

• Max_GPRS_CS and Max_EGPRS_MCS (O&M parameters)

Nb_GCH_For_TBF_Estab is the minimum number of GCHs which are required on the TRX (M-EGCH) to serve

the request.

Table 11: Number of GCH required on the TRX.

Type of request Policy Nb_GCH_For_Estab

TBF establishment (without concurrent) ASAP 1

TBF establishment (with concurrent) ASAP 1 to 5 (Max_Allowed_(M)CS of concurrent TBF)

T1 TBF reallocation ASAP 1

T4 TBF reallocation ASAP 1 to 2 (Max_Allowed_CS of concurrent TBF)

T3 TBF reallocation Optimal 1 to 5 (Max_Allowed_(M)CS of concurrent TBF)

2.6.2 RADIO RESOURCE ALLOCATION PRINCIPLES

The Radio Resource Allocation Algorithm is used to find the radio and transmission resources in the Evolium

BTS case for (E)GPRS best-effort TBF establishment and in the case of TBF reallocation.

The Radio Resource Allocation Algorithm aims to:


ED 1 RELEASED 011




itted without


o Find the best candidate timeslot allocation, depending on:

• Type of request (GPRS / EGPRS)

• Multislot class

• Bias

• Traffic type

o Compute the number of GCHs which can be established:

• With free Abis and Ater resources,

• With inter-cell GCH preemptions,

• With intra-cell GCH preemptions.

The next figure summarizes the radio resource allocation algorithm.

Figure 2–15: RAE4 diagram

The description can be done by four steps:

o Find the best candidate timeslot allocation (steps 2, 3 and 4)

o Verify if there are enough transmission resources (steps 1, 5 and 6)

TRX list sorted by BSC

DSP congestion state

candidate TS allocation

- rejected request - or L4 queuing - or L5/L6 queuing - or L7 queuing (11) - or try to change TBF mode EGPRS case (12)

Type of the TBF request

n_MS_requested n_MS_requested_concurrent

TRX list

MS class, Bias, Traffic type

Best-effort TBF allocation/reallocation request

Number of radio TSs determination

(3)

TRX list computing

(2)

Best candidate TBF allocation computation (4)

no candidate TS allocation

Cell Transmission Equity (5)

Available_Nb_GCH_With_Equity

Test if enough GCHs (6)

“Enough GCHs “

“ALLOC OK” case “ALLOC FAILED” case

Transmission Resource

Availability (1)

TFI/TAI/USF allocation (7)

Available_Nb_GCH

Transmission resource reservation (8)

“Not enough GCHs “

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

o Allocate the radio resources (step 7)

o Reserve the transmission resources (step 8)

2.6.3 TRANSMISSION RESOURCE AVAILABILITY STEP

The goal of the Transmission resource availability is to compute the total number of new GCHs which are

possible to be established in a given cell. That number is called Available_Nb_GCH. The process is done by

two steps:

1. Compute the number of free Abis and Ater resources:

o Nb_Free_GCH = Min( Nb_Free_Basic + Nb_Free_Extra, Nb_Free_Ater, 25)

• Where “25” is the maximum number of GCHs allowed in the Transmission-Allocation-

Request message on BSCGP interface for G2 BSC

2. Compute the number of possible inter-cell GCH preemptions. The principles of this algorithm are:

o “Source” TRX and “Target” TRX on different cells of the same BTS,

o Only the GCHs using extra or “bonus” Abis nibbles are considered.

o Only cells using more extra or “bonus” basic Abis nibbles are considered.

o On “source” TRX, the following constraints shall be respected:

• Established_Nb_GCH ≥ Min_Nb_GCH

o The iterative process stops when:

• No more GCH to preempt

• Or Available_Nb_GCH = Nb_Free_GCH + Nb_Preempted ≥ 36

2.6.4 TRX LIST COMPUTING

The goal of the TRX list computing step is to determine the TRX list on which the TBF or one UL block

candidate allocations will be searched.

The conditions for a TRX to be inserted into the TRX list are:

o The TRX shall be PS capable.

o If the TRX is not already mapped to a DSP and no DSP can be associated to the TRX, then the TRX

shall not be considered.

Opposite to B8, in B9 there is no longer some “restricted EGPRS capable TRX lists” (i.e. selection of the

EGPRS TRX of highest class (that is which offer the highest throughput) as long as the maximum number of

EGPRS TBF per PDCH on these TRX is not higher than a threshold). Indeed, all the EGPRS capable TRXs can

offer the same potential throughput: they are all mapped on G4 TRE, and the B8 concept of “TRX pool

type” has disappeared.

2.6.5 BEST CANDIDATE ALLOCATION COMPUTATION

In the radio resource allocation/reallocation algorithm, the computing of the best candidate TBF allocation

consists in searching which are the best PDCHs onto which to establish (or reallocate) the TBF, according to

various radio related criteria.

Once all the usable PDCHs are determined, the different candidate timeslot allocations are sorted

according to their respective “available throughput”, in order to choose the one offering the highest

throughput to serve the considered request. This is a complete change compared to the previous BSS

releases (B6, B7 and B8).


ED 1 RELEASED 011




itted without


The input data for the best candidate TBF allocation computation are:

o A sorted list of TRXs,

o n_MS_requested and n_MS_requested_concurrent,

o Type of the radio resources allocation request.

The output of the best candidate TBF allocation computation is a candidate TS allocation on a given TRX, as

it is defined in the next sub-sections.

Definition: PDCH states

The PDCH states are:

o Allocated:

• new in B9: the PDCH is a SPDCH indicated as usable for PS traffic by the BSC.

• B8 definition: radio resource allocated to the MFS, but associated transmission resources

are not allocated.

o Active:

• new definition in B9: an allocated PDCH is active if it supports at least one radio resource

allocated for a TBF.

• the B8 definition was considering the parameter N_TBF_PER_SPDCH which is removed in B9

release.

o Full:

• As in B8 release

� For GPRS Best Effort TBFs:

• An allocated PDCH is full in a given direction (XL: UL or DL) if and only if:

o Nb_BE_TBF_XL ≥ MAX_XL_TBF_SPDCH.

� For EGPRS Best Effort TBFs:

• An allocated PDCH is full in a given direction (XL: UL or DL) if and only if:

o Nb_BE_EGPRS_TBF_XL ≥ MAX_XL_TBF_SPDCH.

o EGPRS:

• An allocated PDCH is in the “EGPRS” state if some radio resources are allocated in DL, for

an EGPRS TBF. Only used when running the radio resource (re)allocation algorithm in GPRS

mode and when considering the UL direction of the candidate TBF allocations.

Remark: the “busy” PDCH state (number of established TBF on the PDCH higher than N_TBF_PER_SPDCH) is

no more used by the allocation algorithm.

Candidate timeslot allocation:

A candidate timeslot allocation is a double list of contiguous PDCH in a TRX (one list for the direction of the

request, one list for the opposite direction), which verifies the concurrent constraints as defined by the MS

multislot class.

To be included in a candidate timeslot allocation in order to serve a best effort TBF, a PDCH on a given TRX

must verify the following conditions:

o The PDCH shall be allocated in the MFS. This condition is new in B9 release and comes from the fact

that the MFS does not request PDCH to the BSC

o The PDCH shall not be in the “Full” state in the considered direction

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

o The PDCH shall not be “locked” due to a CS pre-emption process

Available throughput of a candidate timeslot allocation:

This is a completely new metric introduced in B9 release and with high impact in the timeslot allocation. In

the past releases the idea was already to give the highest possible throughput to a TBF (allocating the

highest number of TS not busy, if possible) but there was no explicit metric evaluating the available

throughput provided by a candidate TS allocation. The available throughput of a given candidate timeslot

allocation (available_throughput_candidate_XL) is the overall throughput provided by its PDCHs. It depends

on the potential throughput of its PDCHs (potential_throughput_PDCH) and on the available capacity on

each of its PDCHs (available_capacity_PDCH_XL).

The potential throughput of a PDCH (potential_throughput_PDCH) is calculated as follows according to O&M

parameters for the Evolium BTS case:

o GPRS best effort TBF: R_AVERAGE_GPRS ( default = 12kbit/s )

o EGPRS best effort TBF: R_AVERAGE_EGPRS ( default = 30kbit/s )

This “potential throughput” and its associated parameters are only used in the computation of the best

allocation.

The available capacity on a given PDCH (available_capacity_PDCH_XL) is calculated as follows:

o For a GPRS TBF (XL corresponds to either UL or DL) :

• 1 / Nb_BE_TBF_SAME_PRIOR_XL

o For an EGPRS TBF (XL corresponds to either UL or DL) :

• 1 / Nb_BE_EGPRS_ TBF_SAME_PRIOR_XL

Where:

o Nb_BE_TBF_SAME_PRIOR_XL indicates the total number of Best Effort TBFs (GPRS or EGPRS) which

have some radio resources allocated on the considered PDCH in the XL direction

o Nb_BE_EGPRS_TBF_SAME_PRIOR_XL only take into account EGPRS TBF (the best effort GPRS TBF are

not taken into account)

The available capacity of a given candidate timeslot allocation for n PDCH (n≥1) is computed as follows, for

each direction (XL corresponds to either UL or DL):

o ∑=

=n

1i

DCHi_XLcapacity_Pavailable_ Landidate_Xcapacity_cavailable_

Finally, the available throughput of a candidate timeslot allocation is computed as follow, for each

direction (XL corresponds to either UL or DL):

o available_throughput_candidate_XL =

potential_throughput_PDCH * available_capacity_candidate_XL

Candidate time slot allocations sorting

A candidate timeslot allocation, to be valid, needs to ensure enough resources for PDCH capacity, TFI, TAI

and USF in the direction(s) in which the TBF has to be established. If no candidate timeslot allocation is

found, the best effort TBF (re)allocation request is failed and the process is aborted. Otherwise, all the

valid candidate timeslot allocations are sorted according to the following list of ordered criteria (from the

highest priority to the lowest). This list of criteria is valid in all cases: for GPRS or EGPRS service (contrary

to the B8 release case where two lists were used), and in a cell belonging to an Evolium BTS or to a DRFU

BTS:


ED 1 RELEASED 011




itted without


o [ALPHA]: For “ASAP” policy only: the candidate timeslot allocations, which are on some TRXs for

which (Established_Nb_GCH - Nb_MPDCH) is greater than Nb_GCH_For_TBF_Estab” are preferred.

o [A]: For UL GPRS TBF establishment / reallocation only: the candidate timeslot allocations, which

have the lowest number of PDCHs in the “EGPRS” state are preferred.

o [B]: the candidate timeslot allocations, which have the highest available throughput in the

direction of the bias are preferred.

o [C]: the candidate timeslot allocations, which have the highest available throughput in the

direction opposite to the bias are preferred.

o [D]: the candidate timeslot allocations, which are on the TRX with the highest priority, are

preferred.

o [E]: for EGPRS TBFs establishments only: the candidate timeslot allocations, which have the lowest

number of GPRS TBFs in the direction of the bias, are preferred.

o [F]: combinations with the PDCHs that have the lowest index are preferred.

Remarks:

o The A criterion is only relevant for an UL GPRS TBF establishment / reallocation (i.e. when

considering the UL direction of a candidate TS allocation in GPRS mode)

o When evaluating criterion F, the concurrent constraints imposed by the MS multislot class (if it is

known) or by the default multislot class (if the MS multislot class is not known) shall be taken into

account

2.6.6 PDCH CAPACITY ALLOCATION

Once a candidate TS allocation has been found (in the “best candidate allocation computation” step), the

following radio resources are allocated to the MS in the directions in which a TBF has to be established:

o PDCH capacity

o TFI

o PDTCH / PACCH

o TAI

o USF (only in the UL direction)

This first step is new in B9 release, the PDCH capacity allocation is performed on the best candidate TS

allocation, it has to guarantee a minimum bandwidth for the corresponding TBF(s) (data throughput and

throughput generated on PACCH channels in DL and in UL). The PDCH capacity allocation should always

succeed, because the candidate TS allocations for which the PDCH capacity allocation cannot be performed

have been excluded during the “best candidate allocation computation” step.

PDCH capacity needed for a TBF:

In a given direction (UL or DL) and on a given PDCH, the minimum capacity (in terms of radio block

scheduling in MAC layer) that is required for a best effort TBF is called needed_capacity_Best_Effort_XL (XL

corresponds to either UL or DL). This capacity corresponds to a minimum bandwidth that shall be

guaranteed for the best effort TBF and it is computed as follows:

o needed_capacity_Best_Effort_XL = 20 / T_MAX_FOR_TBF_SCHEDULING

with T_MAX_FOR_TBF_SCHEDULING an O&M parameter in ms

This calculation of needed_capacity_Best_Effort_XL approximates the minimum load which can be

generated by the data traffic and the signalling traffic of the TBF (signalling traffic on the PACCH in the

direction of the TBF). To simplify, it is considered that:

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

o needed_capacity_Best_Effort_DL = needed_capacity_Best_Effort_UL

Algorithm to allocate the PDCH capacity needed for a TBF:

In a given direction (XL corresponds to either UL or DL) and on a given PDCH, the maximum PDCH capacity

which can be allocated is equal to:

o 1 - USED_CAPACITY_BEST_EFFORT_XL

Where:

USED_CAPACITY_BEST_EFFORT_XL indicates the total PDCH capacity that has already been allocated to best

effort TBFs (both GPRS and EGPRS) on the PDCH in the XL direction in order to ensure a minimum

bandwidth for those best effort TBFs.

In the direction(s) in which a TBF has to be established, a PDCH capacity equal to

needed_capacity_Best_Effort_XL shall be allocated on each PDCH included in the best candidate TS

allocation. Then, on each of these PDCH, the value of USED_CAPACITY_BEST_EFFORT_XL shall be increased

accordingly (incrementation by needed_capacity_Best_Effort_XL).

2.6.7 TBF REALLOCATION CASES

Four different TBF reallocations exist:

o T1: reallocation to maintain a TBF alive despite the CS preemption of some RTSs or of some GCHs in

the cell.

o T2: reallocation of an on-going TBF when establishing a concurrent TBF.

o T3: reallocation useful to

• Provide a higher throughput, if it is possible, to a TBF,

• Establish a new M-EGCH link for one of the TRXs of the cell,

• Perform a “radio de-fragmentation” process.

o T4: reallocation to move an UL GPRS TBF sharing one PDCH with a DL EGPRS TBF onto PDCHs which

do not support a DL EGPRS TBF. It concerns only GPRS TBFs.

In particular, it is presented the T3 and T4 reallocation cases.

T3 TBF reallocation Cases

The BSS systematically requests a T3 reallocation for any MS which has an established TBF in the direction

of the bias verifying the following conditions:

o More than N_CANDIDATE_FOR_REALLOC bytes have been sent on the DL TBF or received on the UL

TBF since their establishment

o T3192 is not running

A T3 TBF reallocation is based on the following principles:

o Computing of a THROUGHPUT_RATIO (= Allocated_Throughput / Optimal_Throughput) to know “how

sub-optimal a TBF allocation is”.

o A T3 TBF reallocation will only be allowed if a significant THROUGHPUT_RATIO gain is reached. The

minimal gain is set by the system parameter: MIN_THROUGHPUT_GAIN (= 40%).


ED 1 RELEASED 011




itted without


T3 reallocation attempts occur at each expiry of the T_CANDIDATE_TBF_REALLOC timer and up to

N_MAX_PERIODIC_REALLOC_T3. T3 reallocation attempts can take place at each

T_CANDIDATE_TBF_REALLOC timer expiry.

In case of successful T3 reallocation attempt, no new attempt takes place until the next

T_CANDIDATE_TBF_REALLOC timer expiries. Even if less than N_MAX_PERIODIC_REALLOC_T3 attempts have

occurred and up to two T3 TBF reallocations can be successfully played at each T_CANDIDATE_TBF_REALLOC

timer expiry.

A specific case of T3 reallocation is explained in the next example:

Initial situation:

o 3 MSs (MSa, MSb, and MSc), all GPRS and (4+1),

Figure 2–16: T3 reallocation - initial MSs allocation.

o MSc is the most impacted by the multiplexing in terms of throughput.

In B8:

o MSc is not candidate for T3 reallocation because its allocation is optimal (4 TS in DL),

In B9:

o MSc is candidate for T3 reallocation,

o A new TRX will be established (cf. “Optimal” policy) and MSc will then be reallocated on this new

TRX.

Figure 2–17: T3 reallocation - final MSs allocation for B9.

A second example is a T3 TBF reallocation trigger due to radio defragmentation purpose, as shown in the

next figure:

0 1 2 3 4 5 6 7

DL

UL

MSa MSa MSa MSa MSb MSb MSb MSb

MSc MSc MSc MSc

MSc MSb MSa

0 1 2 3 4 5 6 7

DL

UL

0 1 2 3 4 5 6 7

DL

UL

MSa MSa MSa MSa MSb MSb MSb MSb

MSb MSa

0 1 2 3 4 5 6 7

DL

UL

MSc MSc MSc MSc

MSc

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Figure 2–18: T3 reallocation - defragmentation purpose.

T4 TBF reallocation cases

The goal of the T4 reallocation is to avoid the “UL GPRS - DL EGPRS” TBF multiplexing situations, e.g. some

dummy DL GPRS TBF(s) may have to be managed by MAC in order to schedule the USFs of the UL GPRS

TBF(s), which can induce a throughput reduction for the DL EGPRS TBFs

A GPRS MS becomes candidate for a T4 reallocation as soon as its UL GPRS TBF shares at least one PDCH

with a DL EGPRS TBF

The MS remains candidate for a T4 reallocation, after an UL TBF release, if a DL TBF is still ongoing. This

means that a DL TBF can be T4 reallocated even if it has currently no UL concurrent TBF

In the best candidate allocation computation algorithm:

o The candidate timeslot allocations do not require having the same number of PDCHs than the

current allocation.

o In the UL direction, the candidate timeslot allocations cannot contain PDCHs in the “EGPRS” state.

o The radio resource allocation algorithm is run with the ASAP policy. Thanks to the allocation

criterion ALPHA, the candidate TS allocations located on the TRXs having already

Nb_GCH_For_TBF_Estab established GCHs are favored.

Upon T_CANDIDATE_TBF_REALLOC timer expiry it shall be attempted to reallocate a maximum of

N_MAX_PERIODIC_REALLOC_T4 candidate MSs queued within a list. If a reallocation succeeds, the next

request within the list shall be played (up to the N_MAX_PERIODIC_REALLOC_T4 limit).

2.7 ENHANCED SUPPORT OF EGPRS IN UL

This feature is part of EGPRS package, for more details see [2]. It is divided into two sub features:

o Support of 8-PSK in Uplink

• The "8-PSK in UL" feature proposes to introduce the 8-PSK modulation in UL, which permits

to use the MCS-5 to MCS-9 coding schemes in the BSS (in B8 only the MCS-1 to MCS-4 are

supported in UL).

o Support of Incremental Redundancy and resegmentation in Uplink

TBF

TBF

Initial

Final situation


ED 1 RELEASED 011




itted without


• The "Incremental Redundancy in UL" feature proposes to introduce the incremental

redundancy in UL which permits to improve the decoding performances of the BTS with

EGPRS. This is particularly useful when mobiles are at the border of the cells where a gain

up to 15 % of throughput can be expected according to simulations.

2.7.1 SUPPORT OF 8-PSK IN UPLINK

The feature introduces 8-PSK modulation supported in UL, for more details see [2] The 8-PSK is a

modulation technique that compare to GMSK allows up to 3 times more data to be transmitted over the

GSM air interface. The 8-PSK modulation supports MCS-5 to MCS-9 coding schemes, which permit to achieve

higher throughput when the radio conditions are good enough.

Table 12: Theoretical throughput per UL MCS.

Modulation Coding Scheme

Throughput (kbits/sec)

GMSK MCS-1 8.4

GMSK MCS-2 11.2

GMSK MCS-3 14.8

GMSK MCS-4 17.6

8-PSK MCS-5 22.4

8-PSK MCS-6 29.6

8-PSK MCS-7 44.8

8-PSK MCS-8 54.4

8-PSK MCS-9 59.2

If an EGPRS mobile station wants to initiate the UL EGPRS TBF establishment and if the mobile supports the

8PSK in uplink, then it shall send an EGPRS Packet Channel Request using TS1 alternative training sequences

to request the resources in EGPRS mode. The EGPRS capability is indicated using alternative training

sequences (see 3GPP TS 45.002), as presented in the next table.

Table 13: Training sequence.

Training sequence

Packet Channel Access

TS1 EGPRS with 8PSK capability in uplink

TS2 EGPRS without 8PSK capability in uplink

The MCS-5 to MCS-9 coding schemes will be used both in RLC acknowledged and unacknowledged mode. The

link adaptation mechanism in uplink is based on measurements (MEAN_BEP, CV_BEP) done by the BTS on the

radio blocks received from the mobile. To take into account MCS-5 to MCS-9 in uplink, the B9 BSS algorithm

for link adaptation has new link adaptation MEAN_BEP/CV_BEP tables, which are the same as the ones

already used for downlink. Then, the MCS selected by the BSS is indicated in the "EGPRS modulation and

coding" IE included in the PACKET UPLINK ACK/NACK message. The TRX shall transmit the MEAN_BEP and

CV_BEP of the RLC data block which is received with a correctly decoded RLC/MAC header, whether the

payload is correctly decoded or not. The TRX will discard the RLC/MAC blocks when the header has not

been successfully decoded.

The Link Adaptation tables depend on the APD (Average Power Decrease) of the mobile station, the APD of a

mobile station is the difference between the maximum output power in GMSK and the maximum output

power in 8-PSK and the maximum output powers are known by "GMSK Power Class" and "8-PSK Power Class"

fields of the MS Radio Access capability IE. The Link Adaptation tables also depend of the Incremental

Redundancy if it is activated or not.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

As examples of APD in case of GSM 900 and GSM 850, there is the following table:

Table 14: Average Power Decrease.

8-PSK: Power Class E1



Max. output

power = 33 dBm Max. output

power = 27 dBm Max. output

power = 23 dBm

GMSK: Power Class 2

Max. output power = 39 dBm APD = 6 APD = 10 APD = 10

GMSK: Power Class 3


GMSK: Power Class 4


GMSK: Power Class 5


2.7.2 SUPPORT OF INCREMENTAL REDUNDANCY AND RESEGMENTATION IN UPLINK

The incremental redundancy (type II hybrid ARQ) is used with EGPRS data blocks sent on RLC acknowledged

mode using MCS-1 to MCS-9. The incremental redundancy is based on reception of RLC data blocks coded

with different puncturing schemes, so that the BTS may enhance the decoding of the RLC data block with

soft combining. By taking into account the erroneous RLC data blocks and combining them with the

retransmitted RLC data blocks, the BTS receiver increases the probability of decoding them correctly and

reduces the number of times it uses a slower coding scheme compared to the situation where incremental

redundancy is not used and therefore the average throughput is increased.

The RLC data block re-segmentation in UL is a new B9 feature, which can be activated in the O&M. As in DL

the re-segmentation of radio block is only possible inside the same coding scheme family, as presented in

the next figure. The objective of this algorithm is to retransmit a RLC block in a lower and more robust

coding scheme.

Figure 2–19: Coding scheme families.

MCS5 MCS6 MCS7 MCS8 MCS9MCS1 MCS2 MCS3 MCS4

FamilyC

FamilyB

FamilyA

padding

FamilyA

28

22

34+3

22 22

28 28

34+3 34+3

28 28

28 28

34 34

34 34

37 37 37 37 37

37 37

GMSK 8PSK

28RLC data block unit of payload (in bytes)


ED 1 RELEASED 011




itted without


The incremental redundancy cannot be applied when the RLC datablocks are re-segmented with a different

number of payloads

For more details see [2].

2.8 EXTENDED UL TBF MODE

The aim of this feature is to extend the duration of the UL TBF in order to quickly restart data transmission

in UL if higher layers in the MS deliver new data, without having to re-establish a new UL TBF, after the

countdown procedure has started. E.g. to maintain the UL TBF established, some time after the last block

(CV=0) has been acknowledged by the network. During inactivity period the BSS should keep the USF

scheduling and the reception of uplink RLC data block as long as the uplink TBF is in extended phase.

This feature allows improving access time to the GPRS network. It also improves the throughput in cases

where the traffic is discontinuous. The extended UL TBF mode (EUTM) is supported by mobiles which are

indicating support of 3GPP “GERAN Feature Package 1”. The GERAN Package 1 is mandatory for Rel-4 MS

and optional for Rel-99 MS (so, there can be also MS Rel-99 that supports EUTM), for more details see [2].

The BSS shall indicate to the MS that the network supports the extended uplink TBF mode. The MS is aware

of the BSS capability by the NW_EXT_UTBF parameter that is broadcast on either BCCH (SI13)or PBCCH

(PSI1). So the MS is always aware of the BSS capability before establishing an Uplink TBF. On the contrary

the BSS does not always know the MS radio access capability when the first Uplink TBF is established at the

beginning of a session. The detection whether or not a given MS supports the Extended Uplink TBF Mode is

received at downlink TBF establishment in the first downlink PDU. In case of cell reselection for an uplink

transfer and if the MS radio access capability stays unknown the “Radio Access Capability Update”

procedure is used to obtain the information.

If the MS does not support the Extended Uplink TBF Mode or if the BSS does not know MS capability, the

network will apply the Normal release mode (with delayed final PUAN).

During an UL transfer in a MS having MS context without the support of the Extended Uplink TBF Mode, if a

Radio Access Capability update message is received allowing the Extended Uplink TBF Mode, then the MS

context is overwrite and update.

The Extended uplink TBF mode is activated through an O&M parameter, EN_EXTENDED_UL_TBF and an

inactivity period duration of extended uplink TBF mode is configured T_MAX_EXTENDED_UL by the

parameter.

The release of the uplink TBF is trigger upon the expiry of the timer T_max_extended_UL.

The Radio Access Capability Update on the Gb is activated by the flag EN_RA_CAP _UPDATE. If the

EN_EXTENDED_UL_TBF is enabled and the Radio Access Capability update is supported by SGSN, it is

recommended to enable the flag EN_RA_CAP _UPDATE.

At UL TBF establishment, immediately after the “contention resolution” procedure, the “radio access

capability update” procedure is triggered in the BSS. The BSS request an MS’s current Radio Access

capability and/or its IMSI by sending to an SGSN a RA_CAPABILITY_UPDATE, which includes the TLLI of the

MS and a Tag. Then it starts timer T5_RA_CAPABILITY_UPDATE. In case of the timer expiry, BSS shall repeat

the request up to RA_CAPABILITY_UPDATE_RETRIES times (value = 3). The SGSN shall respond by sending a

RA_CAPABILITY_UPDATE_ACK, which includes the TLLI of the MS, the Tag received in the corresponding

RA_CAPABILITY_UPDATE. When the SGSN answers, the MS Radio Access capability is updated and the

Extended UL feature can be used if the “GERAN Feature Package 1” bit is set. Otherwise, the MS does not

support the extended uplink feature.

If MS supports Extended UL TBF mode and when entering the extended uplink phase the MS begins to run

out of LLC data, it begins the countdown normally. When the BSS receives the last RLC block (CV =0), and if

all the previous blocks have been correctly received, the BSS sends a Packet Uplink Ack/Nack with

Final_Ack_Indicator set to 0, with the SSN incremented like for an active TBF (SSN = last received BSN +1).

All RLC numbering variables are kept as TBF was still active. The uplink TBF is now extended and will not be

released by the mobile. The BSS starts the timer T_max_extended_UL to monitor the maximum duration of

the extended phase.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Figure 2–20: Trigger of the timer T_max_extended_UL.

The BSS continues to schedule USF, so that the MS is able to resume an uplink transfer when required. While

the UL TBF is in extended phase, the reception of an uplink dummy block from the MS, shall not cause the

N3101 counter to be incremented in the BSS. Only the reception of an invalid block increment N3101. While

the UL TBF is in extended phase, the reception of an uplink dummy block from the MS shall not cause the

N_UL_dummy counter to be incremented.

Figure 2–21: Schedule USF.

After the expiry of the timer T_max_extended_UL the network ends the TBF permanently by sending a

Packet Uplink Ack/Nack with FAI = 1 and polling. When receiving PUAN with FAI=1 and polling, the MS sends

the Packet Control Ack in response to polling, and then aborts the uplink TBF. When the timer

T_max_extended_UL expires, the BSS shall wait for all the radio blocks corresponding to already

transmitted USF, before transmitting FAI =1.

Figure 2–22: Expiry of the timer T_max_extended_UL.

RLC block, BSN=n, CV=0

MS BSS

PUAN, SSN=n+1, FAI=0 Enter TBF extended phase.Start T_max_extended_UL

RLC block, BSN=n, CV=0

MS BSS

PUAN, SSN=n+1, FAI=0 Start T_max_extended_UL

USF

USF

Dummy block

USF

Dummy block

MS BSS

T_max_extended_UL expiry

USF

Dummy block

PUAN, FAI=1, S/P=1

PCA

TBF is releaseNominal case


ED 1 RELEASED 011




itted without


If the radio blocks corresponding to the last scheduled USF carry RLC data block, then the BSS shall restart

the uplink TBF.

Figure 2–23: Restart the uplink TBF.

The USF for extended mode are scheduled only on the PDCH, which carries PACCH.

IF the PDCH supports uplink TBF, which all are in extended mode and the flag EN_FAST_USF_UL_EXTENDED

is enable then the throughput in radio blocks is equally shared between MS (round robin of one RLC block

per MS). So USF are scheduled as follows:

o One MS in extended mode on PACCH: USF scheduled every 20ms

o Two MS in extended mode on PACCH: USF scheduled every 40ms

o n MS in extended mode on PACCH: USF scheduled every n x 20m

Otherwise, a polling period T_extended_UL_TBF_POL is used for all MS in extended phase with a default

value of 200ms and the remaining bandwidth is used for MS in transfer.

2.9 ENHANCED PACKET CELL RESELECTION

The “Enhanced Packet Cell Reselection” feature includes two sub-features allowing to reduce cell

reselection duration and to avoid (NC2 mode) to direct MS towards high loaded cells.

The sub features to reduce the service outage during packet cell reselection (NC0 and NC2 modes) are:

o Network Assisted Cell Change Procedures (NACC): MS acquires target cell (P)SI in the serving cell.

Only for R4 MS.

o Packet (P)SI Status procedure : access to a new cell without having previously acquired the full set

of P(SI). Mainly for R4 MS.

In NC2 mode, the algorithm was improve to take in consideration the cell ranking with load criteria, to

prevent MSs to be directed towards high loaded cells, where the MS can be served with non-optimum

resources, or even worse, rejected due to congestion.

For details see [2].

2.9.1 NETWORK ASSISTED CELL CHANGE PROCEDURES (NACC)

The NACC takes place in serving cell and consists of 2 independent procedures:

o CCN mode procedure (Cell Change Notification): Procedure in MS to notifies the network when the

cell reselection is decided in Packet Transfer Mode and delays the cell reselection to let the

network act on need, eventually through the Cell System Information distribution procedure.

o Cell System Information distribution: Procedure to assist an MS in Packet Transfer Mode with target

cell system information required for initial packet access after a cell change. This information is

sent to the MS in the serving cell and before the cell change is performed.

MS BSS

T_max_extended_UL expiry

USF

Radio block, BSN=n+1

USF

Radio block, BSN=n+2, etc…

TBF is active again

Transfer resumption after timer expiry

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Figure 2–24: NACC.

Network Assisted Cell Change - NC0

When EN_NACC is enable, the CCN mode is ordered through System Information to all R4 MSs supporting

GERAN feature package 1 in the cell. The next scenario describes the NACC procedure in NC0 mode:

Figure 2–25: NACC procedure in NC0 mode.

(1) T3206 monitors the sending of the Packet Cell Change Notification.

(2) At receipt of the PACKET CELL CHANGE NOTIFICATION message, the MFS checks whether the proposed

cell belongs to the same BSS as the serving cell. If the proposed cell does not belong to the same BSS

(BSC_ID(n) (target cell) <> BSC_ID (serving cell)), a PACKET CELL CHANGE CONTINUE (PCCC) message is sent

to the mobile station without sending any neighbor cell system information.

(3) In the case, the neighbor cell belongs to the same BSS, RRM starts the timer T3208n (T3208 – RTD) that

monitors the sending of the PCCC and retrieves the SI13 / SI1 / SI3 or PSI14 / PSI1 / PSI2 instances currently

broadcast in the neighbor cell and requests MAC to send the relevant (P)SI to the MS

o if the target cell supports a PBCCH channel, RRM encodes the PSI14, PSI1 and PSI2 instances of that

cell in one or multiple instances of the PACKET NEIGHBOR CELL DATA message which are sent to the

MS, followed by a PACKET CELL CHANGE CONTINUE message .

CCCeeellllll AAA CCCeeellllll BBB Partial Sys Info. of Cell

Cell BMS Cell A

Ongoing data transfer

Target cell choice (1)

T3206

RLC data block polling

Packet Cell Change Notification (2)

Packet Neighbor Cell Data (PSI14)

Packet Neighbor Cell Data (PSI1)

Packet Neighbor Cell Data(PSI2-first instances)

Packet Neighbor Cell Data(PSI2-intermediate instances)

Packet Neighbor Cell Data(PSI2-last instances)

Packet Cell Change continue (4)

T3210

T3208

T3208n

Retrieval PSI instancesof the chosen cell (3)


ED 1 RELEASED 011




itted without


o if the target cell does not support a PBCCH channel, RRM encodes the SI13, SI1 and SI3 instances of

that cell in one or multiple instances of the PACKET NEIGHBOR CELL DATA message.

o When the MS sends the Packet Cell Change Notification message, the MS activates the timer T3210

to wait for a response from the BSS, if timer expiry, the Packet Cell Change Notification is

retransmitted. The MS also activates the timer T3208 to wait for PACKET CELL CHANGE CONTINUE

from the BSS (at timer expiry, the MS will continue the cell reselection in NC0 mode).

(4) When RLC has sent all the instances of the PACKET NEIGHBOUR CELL DATA message, the PACKET CELL

CHANGE CONTINUE (PCCC) message is sent on the PACCH of the MS and the timer T3208n is stopped. It is to

be noted that no PCA is requested to acknowledge the PCCC (No T_Ack_Wait timer is launched by the BSS

when sending the PCCC because at the timer expiry, the mobile station has already left the CCN mode

either because it has received the PCCC or because T3208 has already expired and it is not necessary to

send the PCCC again).

When the mobile station receives the PACKET CELL CHANGE CONTINUE message, it shall leave CCN mode

and continue cell reselection in NC0 mode.

Note: The figure above covers the case where there is a PBCCH in the target cell. When there is no PBCCH

channel in the target cell, the same scenario takes place with BSS sends the SI13, SI1 and SI3 messages

instead of the PSI14, PSI1 and PSI2 messages.

Network Assisted Cell Change - NC2

NC2 cell reselection execution with Cell System Information Distribution is described in the next figure:

Figure 2–26: NACC procedure in NC2 mode.

(1) An UL or DL TBF is assumed on-going.

(2) The MS sends a Packet Measurement Report message on one of the allocated UL block on PACCH

(3) Upon receipt of the Packet Measurement Report message, the BSS detects that a cell reselection must

be triggered. It finds out that the target cell, belongs to the same BSS, and the MS supports the acquisition

of neighbor cell (P)SI.

(4) The BSS sends the PNCDs to the MS, on all the PDCHs of the TBF, to transmit the (Packet) System

Information for the target cell:

o SI13, SI1 and SI3 for a target cell without PBCCH

o or PSI14 (containing the same information as SI13), PSI1 and a consistent set of PSI2 for a target cell

with a PBCCH.

In case both a UL and a DL TBF exist, PNCDs are sent on the DL TBF.

MS BSS Serving cell BSS Target cell

Ongoing UL or DL TBF (1)

Packet Measurement Report / PACCH (2)

Packet Neighbor Cell Data / PDCHs (4)

Packet Neighbor Cell Data / PDCHs

Packet Cell Change Order / PACCH (5)

Packet Control Acknowledgement / PACCH (7)T_ACK_WAIT

(3)

(6)

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

(5) When all the PNCDs have been sent, the BSS orders the MS to reselect a new cell by sending a Packet

Cell Change Order message on the PACCH of the DL or UL TBF. If both an UL and a DL TBFs are on-going, the

message is preferentially addressed by a DL TFI.

The Packet Cell Change Order message is sent in acknowledged mode and contains the ARFCN and the BSIC

of the target cell.

When sending the Packet Cell Change Order message, the BSS starts the timer T_ACK_WAIT to monitor the

receipt of the Packet Control Acknowledgement message.

(6)-(7) Upon receipt of the Packet Cell Change Order message, the MS aborts its on-going TBF in the serving

cell and sends the Packet Control Acknowledgement message, then switches to the new cell.

2.9.2 PACKET (P)SI STATUS PROCEDURE

Packet (P)SI status feature allows MS to make an access to a new cell without having previously acquired

the full set of SYSTEM INFORMATION (resp. PACKET SYSTEM INFORMATION if PBCCH is present in the target

cell) messages sent on the BCCH channel (resp. PBCCH) of the target cell.

The Packet (P)SI Status procedure takes place in the target cell if in this cell, EN_PSI_STATUS = Enable.

o Packet PSI Status procedure is a feature standardized from Release 97 onwards, optional for Release

97, Release 98 and Release 99 MS, and mandatory for Release 4 onwards MS supporting GERAN

Feature Package 1.

o Packet SI Status procedure is a new feature standardized in Release 4, mandatory for Release 4

onwards mobile stations supporting GERAN Feature Package 1.

Figure 2–27: Packet (P)SI status.

Packet SI Status

The scenario of the Packet SI Status procedure is described in the next figure:

Figure 2–28: Packet SI Status procedure.

CCCeeellllll AAA CCCeeellllll BBB

Partial Sys Info.

Remaining

Sys Info.

Cell BMS Cell A

RLC data block (1)

Packet SI status (SI2, SI2bis, SI2ter message type missing) (2)

Scheduling of the serving cell SI message to MS

Packet serving cell data (SI2 message) (4)

Packet serving cell data (SI2bis message)

Packet serving cell data (SI2ter message)

Completion of UL LLC PDU transfer

RLC data block

Packet Uplink ACK/NACK

T_P

SC

D_S

CH

ED

ULE

_AC

K (3)


ED 1 RELEASED 011




itted without


(1) When reselecting a new cell without a PBCCH channel and supporting the PACKET SI STATUS procedure

(EN_PSI_STATUS = enable), the MS can immediately request the establishment of an uplink TBF provided it

has acquired the SI13, SI3 and SI1 message (if present) of this new cell. It can then send a cell update or

restarts its on-going data transfer.

(2) The MS asks BSS to provide the missing system information by sending a PACKET SI STATUS message on

PACCH.

(3) When receiving the MS request, if a downlink TBF is already established, or if a downlink TBF is being

established, or if a downlink TBF will soon be established (DL LLC PDU are being rerouted to the new cell),

then the BSS shall wait until full establishment of the DL TBF to send requested SIs on all the downlink

PDCHs allocated to the MS. Otherwise, SIs are sent on all the PDCHs of the uplink TBF.

A supervision timer (T_PSCD_SCHEDULE_ACK) is started to monitor the sending of the SI messages to the

mobile.

(4) The SI instances are encapsulated in one or multiple instances of a PACKET SERVING CELL DATA message

and sent individually to the mobile station.

When the last SI is sent to the mobile, T_PSCD_SCHEDULE_ACK is stopped (RLC indicates to RRM that all SIs

have been sent).

Packet PSI Status

The scenario of the Packet PSI Status procedure is in the next figure:

Figure 2–29: Packet PSI Status procedure.

(1) When reselecting a new cell with a PBCCH channel and supporting the PACKET PSI STATUS procedure

(EN_PSI_STATUS = enable), the MS can immediately request the establishment of an UL TBF, provided it has

acquired the PSI14, PSI1 and PSI2 messages of this new cell. It can then send a cell update or restarts its

on-going data transfer.

(2) The MS asks the BSS to provide the missing system information by sending a PACKET PSI STATUS message

on a PACCH block.

(3) When receiving the MS request, if a DL TBF is already established, or is being established, or will soon

be established (DL LLC PDU are being rerouted to the new cell), then the BSS shall wait until full

establishment of the DL TBF to send requested PSIs on all the downlink PDCHs allocated to the MS.

Cell BMS Cell A

RLC data block (1)

Packet PSI status (PSI3, PSI3bis missing) (2)

Scheduling of the serving cell PSI messages to MS

Packet serving cell data (PSI3bis message) - first instance

Packet serving cell data (PSI3bis message) - intermediate instance

Packet serving cell data (PSI3bis message) - last instance

Completion of UL LLC PDU transfer

RLC data block

Packet Uplink ACK/NACK

T_P

SC

D_S

CH

ED

ULE

_A

CK

(3)

Packet serving cell data (PSI3 message)

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Otherwise, PSIs are sent on all the PDCHs of the uplink TBF. A supervision timer (T_PSCD_SCHEDULE_ACK) is

started to monitor the sending of the PSI messages to the mobile.

(4) When the last PSI is sent to the mobile, T_PSCD_SCHEDULE_ACK is stopped.

2.9.3 NC2 IMPROVEMENT

Cell load evaluation

The NC2 load is sampled every T_NC2_LOAD_RANKING seconds by dividing the used bandwidth by the total

bandwidth available in the cell

with:

UL_PS_used_Bandwidth: the bandwidth used by PS traffic in the UL direction,

DL_PS_Used_Bandwidth: the bandwidth used by PS traffic in the DL direction,

CS_Used_Bandwidth: the bandwidth used by CS traffic,

Total_PS_Bandwidth: the total bandwidth available in the cell.

The UL PS used bandwidth is defined as the sum of the bandwidth used by the UL TBFs over all the PDCHs

allocated to the MFS.

Where the bandwidth per PDCH calculation is given by:

With:

nULTBF,i: defines the number of UL TBFs on the allocated PDCH i.

NULTBF: is the maximum number of UL TBFs that can be pilled up on the PDCHs (defined by the parameter

MAX_UL_TBF_SPDCH).

In the DL direction, the DL_PS_Used_Bandwidth is computed in a similar way as the UL direction.

The bandwidth used by the CS traffic (CS_Used_Bandwidth) is defined by the difference between the

maximum number of slave PDCHs that can be allocated in the cell (number of slave PDCHs = MAX_PDCH -

NB_TS_MPDCH) and the number of slave PDCHs currently allocated to the MFS in the cell

Next, it is a example of the Cell load evaluation. It is assumed, he following repartition of the DL TBFs is

used:

o The UL_PS_Used_Bandwidth is lower than the DL_PS_Used_Bandwidth. Thus, it is not computed.

o Number of PDCH allocated = 7;

o MAX_DL_TBF_SPDCH = 3;

o MAX_SPDCH = 8.

( )∑=

=OCATEDN_PDCH_ALL

1ii , ULUL BB

Nn

BT B F U L

i , T B F U Li , U L =


ED 1 RELEASED 011




itted without


Time Slot 0 1 2 3 4 5 6 7

3

2 DL TBF3

1 DL TBF1 DL TBF2

CS

BDL , i 1/3+1/3=

2/3 1/3+1/3=

2/3 1/3+1/3=

2/3 1/3 1/3 1/3 1/3 0

Figure 2–30: PS used bandwidth.

In this example, the total bandwidth is equal to 8, the DL_PS_used_bandwidth is equal to 4x1/3 + 3x2/3 =

10/3.

Therefore, the NC2_load is equal to [(10/3)+ 1]x100/8 = 13x100/24 = 54.16 %

The NC2 load samples are further averaged using a sliding window. The size of the sliding window is defined

by the parameter NC2_LOAD_EV_PERIOD.

The load evaluation of internal BSS cells is calculated every T_NC2_LOAD_RANKING, the BSS compares the

computed NC2 load of the cell to the threshold THR_NC2_LOAD_RANKING:

o If the NC2 load average is lower than or equal to the threshold, the cell is considered in a low load

situation.

o If the NC2 load average is higher than the threshold, the cell is considered in a high load situation.

The MFS shares the NC2 load situation information among the different cells of the BSS (or at least between

the cells having a cell reselection link to the serving cell), i.e. low/high load. That exchange of information

is taking place every MULTI_GPU_INFO_BROADCAST_PERIOD.

All external cells to the BSS will always be considered as in low load situation, because of the threshold

THR_NC2_LOAD_RANKING of an external cell is unknown for the BSS.

NC cell reselection ranking

The NC2 cell ranking process consists of 2 cases.

o Case 1: there is a PBCCH in the serving cell

• Cells with C31NC2 > 0

� NC2_Load situation [low => high PS load];

� Cell PRIORITY_CLASS [high => low];

� C32NC2 [high => low]

• Cells with C31NC2 < 0


Figure 2–31: NC2 cell ranking process – case 1.

NC2_load

PRIORITY_CLASS

C32NC2

high

low

priority

C31NC2

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

o Case 2: there is no PBCCH in the serving cell

• Cells with C31NC2 > 0

� NC2_Load situation [low => high PS load];


• Cells with C31NC2 < 0


Figure 2–32: NC2 cell ranking process – case 2.

2.9.4 DL LLC PDU REROUTING

The DL LLC PDU rerouting feature process is explained in the next message flow:

Figure 2–33: DL LLC PDU rerouting feature process.

(1) The MS is in packet idle mode in the serving cell (the old cell).

(2) The MS starts it own cell reselection towards the new cell.

(3) The MS acquires the SI or PSI of the new cell.

(4) While the MS acquires the system information, a DL LLC PDU is received in the old cell for the related

MS.

(5) RRM initiates the DL TBF establishment procedure upon receipt of the DL LLC PDU.

(6) When the MS has finished the system information acquisition in the new cell, it performs an uplink data

transfer in the cell in order to inform the SGSN of its new cell location.

(7) The BSS forwards the new cell identity to the SGSN.

(8) The SGSN analyses the uplink PDU and deduces that the MS has changed of cell.

C31NC2

NC2_load

C2NC2

high

low

priority


ED 1 RELEASED 011




itted without


(9) The SGSN sends a Flush message to the old cell.

(10) RRM re-routes the MS context and then all the stored DL LLC PDU’s according to the conditions defined

above. Otherwise RRM discards the DL LLC PDUs.

(11) RRm sends FLUSH-LL-ACk to SGSN.

If the flag EN_DL_LLC_PDU_Rerouting is set to enable the MFS behaviour follows the conditions of the next

table:

Table 15: MFS behaviour with activation of DL LLC PDU rerouting

Old and New Cell

SGSN INR En_Autonomous_Rerouting FLUSH-LL information MFS behaviour

Old BVCI and New BVCI MS Context rerouted DL LLC PDU rerouted Same RA

Same NSE NA NA

Old BVCI DL LLC PDU deleted

Old BVCI, New BVCI and New NSEI

MS Context rerouted DL LLC PDU rerouted Yes NA

Old BVCI DL LLC PDU deleted

Enable Old BVCI

MS Context autonomous rerouted DL LLC PDU autonomous rerouted

Same RA Different NSE

No

Disable Old BVCI DL LLC PDU deleted

If the DL LLC PDU rerouting feature is disabled the DL LLC PDU in the old cell will be deleted.

2.10 TELECOM PARAMETERS

The telecom parameters associated to the previous description are aggregated in the next table, the

optimised values are the ones were an optimisation is recommended, the optimised values should be

analysed before widely implementation in a network:

Table 16: Telecom parameters

GPRS/EGPRS configuration

Logical name Definition Instance Type Range Default value

Optimised value

TRX_PREF_MARK Preference mark assigned to a TRX to favour or disfavour CS radio resource allocations on a TRX.

TRX Number 0 to 7 1 0

Resource allocation/reallocation


Optimised value

EN_RES_REALLOCATION Enabling / disabling of the resource reallocation feature.

BSS Number 0 to 15 NA

T_PDCH_PREEMPTION

Timer to limit the duration of the soft pre-emption process (at its expiry, a fast pre-emption is undertaken).

Cell Number 0 to 240

NA

MAX_DL_TBF_SPDCH Maximum number of DownLink (E)GPRS connections per Slave PDCH.

Cell Number 1 to 10 8 5

MAX_UL_TBF_SPDCH Maximum number of UpLink (E)GPRS connections per slave PDCH.

Cell Number 1 to 6 5

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

EN_RETURN_CS_ZONE_HO

Flag enabling the intracell handovers allowing to move TCH from the PS zone to the CS zone of PDCH/TCH allocation

Cell Flag Enable

/ Disable

Enable

R_AVERAGE_GPRS average bitrate per PDCH for non-Edge capable terminals in this cell


12000

R_AVERAGE_EGPRS average bitrate per PDCH for Edge capable terminals in this cell


30000

GPRS/EGPRS radio resources


Optimised value

MAX_PDCH Maximum number of slave and master PDCHs that can be established in the cell.


0

MIN_PDCH Minimum number of master and slave PDCHs that are always allocated to the MFS.


0 1

MAX_PDCH_HIGH_LOAD

Maximum number of slave and master PDCHs that can be allocated to the MFS when the CS traffic is high.


0 1

MAX_PDCH_PER_TBF Maximum number of PDCH allocated to a single (E)GPRS connection

Cell Number 1 to 5 5

MAX_PDCH_PER_TBF_High_Ater_Usage

Maximum number of PDCH allocated to a single (E)GPRS connection, when the Ater usage is “high”.

Cell Number 1 to 5 NA

EGPRS activation / TBF handling


Optimised value

ACCESS_BURST_TYPE Format of the access burst used by MS

cell Flag 8 bits or

11 bits 8 bits

BEP_PERIOD Filter constant for EGPRS channel quality measurements.

cell Number 1 to 25 10

EN_EGPRS Enables/Disables EGPRS traffic in the cell.

cell Flag Enable

/ Disable

Disable Enable

MAX_EGPRS_MCS Maximum Modulation and Coding Scheme used for EGPRS traffic in the cell.

cell Number MCS1 to

MCS9 9

MAX_GPRS_CS Maximum coding scheme used for GPRS traffic in the cell.


NB_EXTRA_ABIS_TS

Number of all extra Abis (64k) timeslots of all the pools defined on the 2 possible sectors on which the cell is mapped.(virtual changeable)

cell Number 0 to 96 NA

N_EXTRA_ABIS_TS Number of extra Abis (64k) timeslots configured for a BTS.

BTS Number 0 to 60 0

NB_TS_MPDCH (BSC) Number of radio timeslots reserved for the primary and secondary master PDCHs defined in the cell.


PS_PREF_BCCH_TRX

Indicates whether or not the PS requests shall be preferentially served with PDCH(s) of the BCCH TRX

cell Flag Enable

/ Disable

Disable

T_DL_EGPRS_MeasReport Time period to request for an EGPRS Packet Downlink Ack/Nack with measurements.

cell Timer 60 to 3000m

s 200ms

TBF_DL_INIT_CS

Value of the downlink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise.

cell Number CS1 to CS4

CS-2

TBF_UL_INIT_CS

Value of the uplink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise.

cell Number CS1 to CS4

CS-2


ED 1 RELEASED 011




itted without


TBF_DL_INIT_MCS

Value of the downlink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise.

cell Number MCS1 to

MCS9 MCS-3

TBF_UL_INIT_MCS

Value of the uplink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise.

cell Number MCS1 to

MCS9 MCS-3

NETWORK_CONTROL_ORDER(n) This parameter defines whether the MS or the BSS controls the cell reselections.


TX_EFFICIENCY_ACK_THR

Threshold below which the TBF is released because of a bad transmission efficiency in acknowledged mode.

cell Percentage 0 to 100

10

TX_EFFICIENCY_NACK_THR

Threshold below which the TBF is released because of a bad transmission efficiency in unacknowledged mode.

cell Percentage 0 to 100

15

EN_EXTENDED_UL_TBF Flag to disable/enable the extended TBF mode feature on the uplink

cell Flag Enable

/ Disable

DISABLE

Enable

T_MAX_EXTENDED_UL Maximum duration of the extended uplink TBF phase

cell Timer [100, 4000]

2000

EN_FAST_USF_UL_EXTENDED Flag to disable/enable the transmission of USF every 20ms in extended mode

BSS Flag Enable

/ Disable

ENABLE Enable

EN_RA_CAP_UPDATE Flag to enable/disable the Radio Access Capability update on Gb

BSS Flag Enable

/ Disable

DISABLE

DRX_TIMER_MAX Maximum value allowed for the MS to request for non-DRX mode after packet transfer mode.

BSS sec 0 to 4 2

BS_CV_MAX

Number of remaining RLC data blocks sent (per assigned PDCH) by the MS, below which the Count Down procedure is entered. One third of the number of RLC data blocks per assigned PDCH before the MS checks if the resolution contention has failed.

cell Number to 15 9

Coding scheme and radio link control


Optimised value

CS_QUAL_UL_2_3_FH_ACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the uplink direction when the RLC mode is acknowledged and the TBF is established on a hopping TRX.

BSS Threshold 0 to 7 4

CS_QUAL_DL_2_3_FH_ACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a hopping TRX.


CS_QUAL_UL_2_3_FH_NACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the uplink direction when the RLC mode is unacknowledged and the TBF is established on a hopping TRX.


CS_QUAL_DL_2_3_FH_NACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a hopping TRX.


ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

CS_QUAL_UL_2_3_NFH_ACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the uplink direction when the RLC mode is acknowledged and the TBF is established on a non-hopping TRX.

BSS Theshold 0 to 7 3.5

CS_QUAL_DL_2_3_NFH_ACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a non-hopping TRX.

BSS Theshold 0 to 7 3.5

CS_QUAL_UL_2_3_NFH_NACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the uplink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX.


CS_QUAL_DL_2_3_NFH_NACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX.


CS_QUAL_UL_3_4_FH_ACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the uplink direction when the RLC mode is acknowledged and the TBF is established on a hopping TRX.

BSS Threshold 0 to 7 0.5

CS_QUAL_DL_3_4_FH_ACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a hopping TRX.


CS_QUAL_UL_3_4_FH_NACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the uplink direction when the RLC mode is unacknowledged and the TBF is established on a hopping TRX.


CS_QUAL_DL_3_4_FH_NACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a hopping TRX.


CS_QUAL_UL_3_4_NFH_ACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the uplink direction when the RLC mode is acknowledged and the TBF is established on a non-hopping TRX.


CS_QUAL_DL_3_4_NFH_ACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a non-hopping TRX.



ED 1 RELEASED 011




itted without


CS_QUAL_UL_3_4_NFH_NACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the uplink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX.


CS_QUAL_DL_3_4_NFH_NACK

Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX.


CS_SIR_DL_3_4_FH_ACK

Signal to Interference Ratio threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a hopping TRX.

BSS Threshold 0 to 15 14 10

CS_SIR_DL_3_4_FH_NACK

Signal to Interference Ratio threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a hopping TRX.


CS_SIR_DL_3_4_NFH_ACK

Signal to Interference Ratio threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a non-hopping TRX.


CS_SIR_DL_3_4_NFH_NACK

Signal to Interference Ratio threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX.


CS_SIR_HST_DL

Signal to Interference Ratio hysteresis used in the link adaptation algorithms to change the Coding Scheme from CS4 to CS3 in the downlink direction.

BSS Number 0 to 15 1

CS_BLER_DL_3_4

CS3 BLER threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the SIR measurements are not reported by the MS.

BSS Percentage 0 to 100

5

CS_BLER_DL_4_3

CS4 BLER threshold used in the link adaptation algorithms to change the Coding Scheme from CS4 to CS3 in the downlink direction when the SIR measurements are not reported by the MS.


15

TBF_CS3_BLER_PERIOD

Defines the window size required to estimate the CS3 BLER. The window size is expressed as a number of DL RLC data blocks

BSS Number 1 to 512

32

TBF_CS4_BLER_PERIOD

Defines the window size required to estimate the CS4 BLER. The window size is expressed as a number of DL RLC data blocks

BSS Number 1 to 512

32

EN_FULL_IR_DL Enables/Disables Incremental redundancy for the downlink TBF in the cell.

BSS Flag Enable

/ Disable

DISABLE

Enable

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

EN_IR_UL Enables/Disables Incremental redundancy for the uplink TBF in the BSS.

BSS Flag Enable

/ Disable

DISABLE

Enable

EN_RESEGMENTATION_UL Enables/Disables the re-segmentation for the uplink TBF in the BSS

BSS Flag Enable

/ Disable

DISABLE

Disable

E_TX_EFFICIENCY_PERIOD Number of received radio blocks for an EGPRS TBF after which E_TX_EFFICIENCY is computed.

BSS Number 0 to 500

200

EN_CS_ADAPTATION_ACK Enables / disables the link adaptation in RLC acknowledged mode.

Cell Flag Enable

/ Disable

Enable

EN_CS_ADAPTATION_NACK Enables / disables the link adaptation in RLC unacknowledged

Cell Flag Enable

/ Disable

Enable

TBF_CS_DL

For a monoslot TBF alone on its PDCH, threshold defining the number of consecutive Packet Downlink Ack/Nack not received above which the coding scheme of a downlink acknowledged or unacknowledged TBF is changed to CS1 (only in downlink). For a multi-slot TBF or a TBF which shares its PDCH(s), the limit is proportional to the instantaneous bandwidth allocated to the TBF.


TBF_CS_UL

Threshold defining the maximum number of consecutive times the network receives an invalid UL RLC data block or nothing from the MS having a monoslot GPRS TBF before changing the coding scheme to CS1. For a multislot GPRS TBF, TBF_CS_UL_limit := TBF_CS_UL x n_allocated


TBF_MCS_DL

For a monoslot TBF alone on its PDCH, threshold defining the number of consecutive EGPRS Packet Downlink Ack/Nack not received above which the coding scheme of a downlink acknowledged or unacknowledged TBF is changed to MCS1 (only in downlink). For a multi-slot TBF or a TBF which shares its PDCH, the limit is proportional to the allocated bandwidth at the TBF establisment.


TBF_MCS_UL

Threshold defining the maximum number of consecutive times the network receives an invalid UL RLC data block or nothing from the MS having a monoslot EGPRS TBF before changing the coding scheme to MCS1. For a multislot EGPRS TBF, TBF_MCS_UL_limit := TBF_MCS_UL x n_allocated_timeslots.

BSS Threshold 1 to 192

32

GPRS/EGPRS Transmission


Optimised value

EN_FAST_INITIAL_GPRS_ACCESS

This flag indicates whether or not one Slave PDCH for (E)GPRS traffic usage will be statically established in the cell.

cell Flag Enable

/ Disable

Disable


ED 1 RELEASED 011




itted without


T_GCH_INACTIVITY

- For Non Evolium BTS : Timer to postpone the release of one slave PDCH, when it does not support any (E)GPRS traffic. - For Evolium BTS : Timer to postpone the release of the "unused" GCHs of the M-EGCH link of a TRX (the condition for some GCHs of the M-EGCH link of a TRX to become "unused" is that some TBFs

BSS Number 1 to 100

3 2

T_GCH_INACTIVITY_LAST

- For Non Evolium BTS : Timer to postpone the release of the last established slave PDCH of a cell, when it does not support GPRS traffic anymore. - For Evolium BTS : Timer to postpone the release of the last N_GCH_FAST_PS_ACCESS GCHs established in a cell, when the last TBF has been released in the cell.

BSS Number 1 to 200

20 8

N_GCH_FAST_PS_ACCESS

Two definitions are possible : - If EN_FAST_INITIAL_GPRS_ACCESS = “enabled” : number of GCHs required to be established due to the “Fast Initial PS Access” feature, - If EN_FAST_INITIAL_GPRS_ACCESS = "disabled” : number of GCHs to keep established when there is no more (E)GPRS traffic in a cell (while the T_GCH_INACTIVITY_LAST timer is running). Those GCHs will be useful in case of (E)GPRS traffic resumption in the cell.

MFS Number 1 to 5 1

GPRS_MULTISLOT_CLASS_DEF_VALUE

Default value of the (E)GPRS multislot class assumed at TBF establishment when the actual MS (E)GPRS multislot class is unknown.

BSS Number 1 to 8 8

ATER_USAGE_THRESHOLD Threshold (percentage of used Ater nibbles, in a GPU) above which the Ater usage is said “high”.


70

N_ATER_TS_MARGIN_GPU

Number of free 64k Ater TSs that are kept “in reserve” in order to be able to serve some prioritary requests in cells managed by the GPU. The prioritary requests are the GCH establishment requests launched when the first TBF has to be established in a cell.


GCH_RED_FACTOR_HIGH_ATER_USAGE Reduction factor of the number of GCHs targeted per PDCH, when the Ater usage is “high”.

cell Number 0 to 1 0.75

Enhanced Packet Cell Reselection


Optimised value

EN_NACC Enables the Network Assisted Cell Change feature.

cell Flag Enable

/ Disable

Disable 1

EN_PSI_STATUS

Enables the Packet SI Status feature in cells w/o PBCCH or the Packet PSI Status feature in cells with a PBCCH.

cell Flag Enable

/ Disable

Disable 1

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

3 NETWORK DIMENSIONING

The BSS network architecture and dimension had a high improvement with B9 release. Dynamic Abis and the

new Ater resources usage, along with the M-EGCH, allowed the dynamically of the transmission resources

and prepared the Alcatel-Lucent BSS to the future.

The BSS architecture in B9 can be summarize in the next figure:

Figure 3–1: BSS Architecture in B9 release.

And with the introduction of the Mx platform and TWIN TRA:

Figure 3–2: BSS Architecture in B9 release with Mx platform.

The BSS dimensioning explained in this chapter is only an overview and the document of the reference

should be used for a deeper understanding.

The traffic profile and the operator objectives are external variables, impacting the network dimensioning.

Simple cases will be considered in the examples.

The dimensioning will be focus in the 3 main interfaces/equipments:

o Abis

o Ater

o GPU/GP

BSC Abis TSU

Ater TSU

Abis TSU

Ater TSU

Abis TSU

Ater TSU

speech

data

A-ter mux

Gb

A

CS

CS+ PS

PS

CS A-bis

Air

MFS

GPU board

DSP DSP DSP DSP

GPU board

DSP DSP DSP DSP

TC

MT120

SMU TRCU TRCU

TRCU

MT120

SMU TRCU

TRCU

TRCU

TRX 2 M-EGCH link 1

PS traffic

TRX 3 M-EGCH link 2

M-EGCH link n

BTS

Dynamic Abis

allocation GCH Extra

GCH Basic

GCH Basic

GCH Extra

GCH Bonus

TCH

TCH TRX 1 CS

traffic

TRX n

TCUC

Up to 12 TRXs per BTS

speech

data

A-ter mux

Gb

A

CS

CS+ PS

PS

CS A-bis

Air

TC

MT120

SMU TRCU TRCU

TRCU

MT120

SMU TRCU

TRCU

TRCU

TRX 2 M-EGCH link 1

PS traffic

TRX 3 M-EGCH link 2

M-EGCH link n

BTS

Dynamic Abis

allocation GCH Extra

GCH Basic

GCH Basic

GCH Extra

GCH Bonus

TCH

TCH TRX 1 CS

traffic

TRX n

MxBSC CCP board

CCP board

SSW board

TP board

LIU board

LIU board

VTCU

MxMFS

GP board

DSP DSP DSP DSP

GP board

DSP DSP DSP DSP

Up to 24 TRXs per BTS with Twin Modules

Capacity 1 GP = 4xGPU

(B9 MR4)


ED 1 RELEASED 011




itted without


3.1 ABIS

The Abis dimensioning in B9 is at BTS level, as explained in chapter 2.3.2, this is due to the fact that the

bonus and extra Abis nibbles are shared by all TRXs of the BTS.

The bonus Abis nibbles are mainly depended of the BTS configuration, number of cells and number of

SDCCH configured. The extra Abis nibbles are depended of the Abis resources “load” and they can be

mapped by the parameter N_extra_Abis_TS.

For Abis dimensioning three examples are proposed, the first one is applied to Abis dimensioning

computation based on operator requirements; the second presents an impact of the defined dimensioning

and the third example is an easy explanation how to dimension an Abis interface based in statistical data.

Example 1

The proposal of this example is to determine the number of extra Abis TS required in a BTS to accomplish

the operator objectives.

Operator objectives:

o 2 users with Class 10 MS simultaneous in a BTS

o DL data transfer in MCS9

BTS configuration:

o 3 cells with 2 TRX and 1 SDCCH per cell.

o No limitations of radio resources allocation (Max_SPDCH_Limit)

Based on the operator objectives the number of GCH required is:

o 4.5 GCH per radio TS in MCS9 x 4 PDCH per user x 2 users = 36 GCH (16 kbit/s Abis nibbles)

The present number of available GCH in the cell is:

o 6 bonus nibbles available for PS (from the 3 BCCH and the 3 SDCCH)

o 4 PDCH per user x 2 users x 1 GCH from basic nibbles = 8 GCH

o 6 nibbles + 8 basic = 14 GCH

The number of GCHs in deficit is:

o number of GCH required - number of available GCH in the cell = 36 – 14 = 22 GCH

The number of required extra Abis TS is given by the number of GCHs in deficit:

o 22 GCH in deficit (16 kbit/s Abis nibbles) / 4 Abis nibles per Abis TS = 5.5 Extra Abis TS

o As a conclusion: The N_EXTRA_ABIS_TS should be set to 6 to fulfil the requirement

Example 2:

For the previous configuration including the N_extra_Abis_TS = 6, the impact in the DL throughput

performance of a third user with MS class 10 will be explained in the example:

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Assumption:

o Each user is alone in one of the cells.

o Cell transmission equity is not possible, since the users are served by different cells

o Max_SPDCH_limit = 4 per cell.

The total number of GCHs available in the BTS is:

o Total number of GCHs - The number GCH already in use by the 2 users = 42 -36 = 6 GCH

Where the:

o Total number of GCHs = 6 nibbles + 12 basic + 6*4 extra Abis nibbles = 42 GCH

o 12 basic = 4 PDCH per user x 3 users x 1 GCH from basic nibbles = 12 GCH

The required number of GCH for the third user is:

o 4.5 GCH per radio TS in MCS9 x 4 PDCH per user x 1 users = 18 GCH

The 6 GCH available to be established in the M-EGCH will allowed a maximum MCS of MCS9.

The expected DL RLC throughput should be around 6 / 18 = 33.3% of the maximum DL RLC throughout

without transmission constrains.

Example 3:

This example explains the method to calculate the number of extra Abis nibbles needed for a cell. It is an

easy method, however it is only applied for PS dimensioning of the Abis. The method is applied when

congestion in the Abis is observed, it takes in consideration that the traffic not allowed due to the

congestion should be carry by the extra Abis nibbles.

The input variables are indicators from O&M counters.

Figure 3–3: Calculation of the Number of Extra Abis TS.

Where:

o %)30,__(%1

__&___&_Re

CongAbisTBFMin

TrafficAbisBonusExtraMeasuredTrafficAbisBonusExtraquired

−=

o GoS = Grade of Service

With:


ED 1 RELEASED 011




itted without


o 3600

466__&_

PTrafficAbisBonusExtraMeasured =

o )___,%___(%__% CongAbisTBFULCongAbisTBFDLMaxCongABISTBF =

o %100919191919191

105___% ×

+++++=

fPePdPcPbPaP

iPCongAbisTBFDL

o %100438626262

105___% ×

−++=

cPcPbPaP

jPCongAbisTBFUL

After the calculation of the number of required extra & Bonus Abis nibbles using the Erlang C formula, it is

needed to remove the bonus Abis nibbles and dividing per four the total number of extra Abis TSs needed

are found.

3.2 ATER

In the computation of the number of needed AterMux links the capacity of 112 GCH per link is taken in

order to be able to support GSL carrying

The goal of the AterMux interface dimensioning assessment is to estimate the needed number of GCH

resources in order to be able to support the estimated Required_GCH_traffic (the traffic in Erlang that

AterMux interface should handle for not having congestion).

Figure 3–4: Calculation of the needed GCHs in the Atermux interface.

The proposal methods for Atermux dimensioning take as input variables the real data. 2 different methods

can be used for dimensioning estimation:

o Method 1: driven by the estimation of the required traffic as a function of the measured GCH traffic

and of Ater/GPU congestion

o Method 2: driven by the estimation of the required traffic as a function of the measured GCH and

radio PS traffic

3.2.1 METHOD 1

The method 1 is a function of existing GCH traffic and Ater/GPU congestion and it is only valid if the GCH

congestion is lower than 30%. The measured GCH traffic is given by the counter P100c and the Ater/GPU

congestion is given by the counters P383a, P384, P201, P202 and P404, these counters are explained in the

chapter 5.4.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Figure 3–5: Calculation of the Required_GCH_Traffic by Method 1.

The Required_GCH_Traffic is calculated by the formula:

Congestion

TrafficGCHMeasuredTrafficGCHquired

−=

1

____Re

Where:

o Measured_GCH_Traffic = P100c / 3600

o Congestion = Max(Ater_or_GPU_limitation, 30%)=Max(Max(P383a,P384,P202,P201,P402) / 3600; 30%)

3.2.2 METHOD 2

The method 2 is function of the relation between the GCH traffic and the PDCH traffic, if a saturation of

the GCH resources is observed a new Ater dimensioning should be performed.

Figure 3–6: Measured GCH traffic vs Measured PDCH traffic.


ED 1 RELEASED 011




itted without


The Required_GCH_Traffic is quasi linear relationship of the PDCH traffic, before there is congestion or

reduction due to High Ater load. If saturation is observed with n Atermux link some extra links should be

added, up to 5 Atermux per GPU. The Required_GCH_traffic can be found doing an extrapolation of the

linear relationship between GCH and PDCH traffic and taking the GCH traffic value corresponding to the

maximum observed PDCH traffic.

The formula is given by the:

Figure 3–7: Calculation of the Required_GCH_Traffic by Method 2.

With P38b as the PDCH traffic.

3.2.3 NUMBER OF GCH NEEDED

After the Required_GCH_Traffic is calculated, the Erlang C formula should be used to calculate the number

of GCHs needed and by association the number of Atermux to add.

3.2.4 HSDS IMPACT

With the activation of HSHS (EDGE and CS3/CS4) the consumption of AterMux transmission resources (GCH)

per radio resource (PDCH) increases.

The calculation of the Required_GCH_Traffic is impacted by an increase factor if HSDS is activated; the

process is in the next figure:

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Figure 3–8: Increase factor

The increase factor will be a function of:

o The transition type

o The target service penetration (i.e. %EDGE with respect to GPRS)

o The traffic profile

A transition type is explained by the following figure, depending on the path (a, b, c, d and e) different

increase factor is applied:

Figure 3–9: Transition type

If no reference BSC exists the increase factor is calculated taking in account assumption of the EGPRS

penetration at cell level. The increase factor is given by the relation between the number of GCHs per

PDCH before and after the service activation:

o initial

final

r_PDCH_nb_GCH_peAvg_target

r_PDCH_nb_GCH_peAvg_targetactorIncrease_f =

CS1 / CS2

CS3 / CS4

EDGE

CS3 / CS4 And EDGE

a

b

c

d

e

Increase_factor estimated on the basis of the Avg_target_nb_GCH_per_PDCH (depending on the target service

penetration)

Increase_factor =

Avg_target_nb_GCH_per_PDCHfinal /

Avg_target_nb_GCH_per_PDCHinitial

Increase_factor =

increase_factor (reference BSCs)

Execute transition

Dimensioning assessment for

fine tuning

Update reference BSCs set

Does a (set of) reference

BSC(s) Exist?

No

Yes


ED 1 RELEASED 011




itted without


Where:

o _PDCH_MCSynb_GCH_per S%_PDCH_GPR_PDCH_MCSxnb_GCH_per RS%_PDCH_EGP

r_PDCH_nb_GCH_peAvg_target

×+×==

o %_PDCH_EGPRS: % of Radio Resources (PDCH) supporting at least one TBF established in EGPRS

mode on a cell with MAX_EGPRS = MCSx

o %_ PDCH_GPRS: % of Radio Resources (PDCH) supporting only TBF established in GPRS mode on a

cell with MAX_GPRS = CSy

o Nb_GCH_per_PDCH_MCSx: given by table 6

o Nb_GCH_per_PDCH_CSy: given by table 5

For the different transition type the increase factor is given by:

Table 17: Increase_factor

Transition Type Increase_factor

a [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64)]/1

b [1,64]/1

c [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1)]/1

d [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64)]/ 1,64

e (%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64)/(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1)

For method 1 the application of the increase factor is by the simple formula:

o actorIncrease_f_trafficquired_GCH_trafficquired_GCH currentfinal ×= ReRe

For method 2 the impact of the increase factor is applied in the slope, as explained in the next graphic:

Figure 3–10: Method 2 – increase_factor

Where

o a2= a1 * Increase_Factor and b2 = b1 (approximation !)

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

3.3 GPU/GP

The number of GPU/GP boards can be estimated thanks to the computed Needed GCH and to the computed

GPU_GCH_Capacity.

The GPU_GCH_Capacity is the number of GCH that a GPU/GP can handle. It is given by the minimum of

three variables:

{ }CapabilitySWHWGPUperGCHULMaxGPUperGCHDLMaxMin

CapacityGCHGPGPU

_/,____,____

__/

∑∑

=

The variables are defined by:

o HW/SW capability - Maximum number of GCH per GPU is:

• B9MR1:

� 480 – N_ATER_TS_MARGIN_GPU*4

• B9MR4:

� Legacy MFS: 480 – N_ATER_TS_MARGIN_GPU*4

� MxMFS: 1560 – N_ATER_TS_MARGIN_GPU*4

o Max_DL_GCH_per_GPU and Max_DL_GCH_per_GPU – The maximum number of GCHs that the GPU

will be able to handle can be obtained knowing the (M)CS distribution of the analyzed network:

• ( )( ) ...H_MCS1 max_DL_GCMCS1 max_PDCH_%MCS1

...H_CS1 max_DL_GCCS1 max_PDCH_%CS1

_GPUMax_DL_GCH

+××++××

=

• ( )( ) ...H_MCS1 max_UL_GCMCS1 max_PDCH_%MCS1

...H_CS1 max_UL_GCCS1 max_PDCH_%CS1

_GPUMax_UL_GCH

+××++××

=

• Where

� Max_DL/UL_GCH_CSy is defined in table 5.

� Max_DL/UL_GCH_MCSxP57x is defined in table 6

� The maximum number of PDCH per GPU/GP is dynamic depending on the used

coding schemes and on the HW/SW capability:


ED 1 RELEASED 011




itted without


Table 18: max_PDCH_CSy per GPU/GP determination for GPRS

GPRS max_PDCH_CSy: Max nb of PDCH per GPU/GP

Max CS GPU (A9135) & GP (A9130) up

to B9MR1

GP (A9130) from B9MR4 Case 12 E1 links per GP



CS1 240 960 960 896

CS2 240 960 960 896

CS3 224 892 892 716

CS4 200 684 804 544

Table 19: max_PDCH_MCSx per GPU/GP determination for EGPRS

EGPRS max_PDCH_MCSx: Max nb of PDCH per GPU/GP

Max MCS GPU (A9135) & GP (A9130) up

to B9MR1




MCS1 224 860 860 860

MCS2 224 836 836 836

MCS3 208 796 796 672

MCS4 200 748 776 596

MCS5 184 604 704 480

MCS6 172 476 664 380

MCS7 136 320 452 256

MCS8 116 272 380 216

MCS9 108 252 352 200

The number of GPU/GP needed is then given by dividing the needed GCH per the GPU_GCH_Capacity.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

4 NETWORK PRIORITIES

With the introduction of the packet switch, in GSM networks, the radio and transmission resources available

have to be shared between the circuit and packet switch, it is a compromise between different variables:

the CS accessibility, PS accessibility, PS performance and most important with the operator network

capacity.

Normally, when PS is activated in a network, the traffic is mainly due to signalling (GMM/SM), with the time

and with the new services arriving, the end user customers begin to use these services as a daily routine

and the PS traffic starts to have more weight in the network. Two major reasons are associated to a rapidly

increase of PS traffic in a network, flat rates and short data traffic (e.g. chat, MMS, etc). With the increase

of PS traffic the network architecture and dimensioning have to be reviewed, parameters values

implemented during the EDGE activation have to be optimised to the new reality. The increase of capacity

in a network, either radio or transmission, impacts the costs and due to that the operators are quite

sensitive to this issue. That’s why, a consistent and rigorous approach has to be considered on this topic.

Three different main phases exist for the PS dimensioning and optimisation:

o Phase 1 - PS implementation/activation, the network is dimensioning for low PS traffic, mainly

signalling traffic.

o Phase 2 - Increase of PS traffic without enough radio and transmission resources – parameters

optimization needed to minimize the impact

o Phase 3 – Re-dimensioning of the network architecture.

In all the three phases the CS is the service with more priority, it is only considered the CS accessibility

since the performance is not impacted by PS access and traffic.

4.1 PHASE 1

For the phase 1, the network is carrying the first data traffic, it is mainly signalling (GMM/SM). The few

customers using user data service are spread in time and location. The traffic load created by them is low.

In this way the operators define their network priorities as:

1. Circuit Switch accessibility

2. Packet Switch performance

3. Packet Switch accessibility

The operators want to give to the few users the best performance as possible, not only throughput but also

small establishment time. Due to this, the configuration and parameterization is optimized to achieve the

better performance as possible. In order to reduce the GPRS signalling traffic and their impact in the radio

and transmission resources load some GSS optimisations are possible, for more information see sub-chapter

6.8

In this phase the parameters are in their default value, for best performance. For the default parameters

values see sub-chapter 2.10.

4.2 PHASE 2

The PS traffic increases with the new services, the capacity dimensioned during the PS implementation is

not enough. Congestion problems appear in the transmission and degradation of the PS accessibility and

performance begins due to the under dimensioned radio resources. The operator should react and it should


ED 1 RELEASED 011




itted without


optimize the network in accordance. This phase is a transition phase; it should be used for only a short

time.

The PS performance is no longer a major priority, important is to give PS access to all users and the

priorities are redefined as:




The BSS parameters should be optimised to able the implementation of the new network priorities. This

phase is when the PS traffic had increase to a critical situation; the major problem observed is congestion

at transmission level Ater and Abis and at DSP side. The parameter tuning proposed for this situation is

explained in chapters 6.6 and 6.7.

4.3 PHASE 3

With the upgrade of the transmission and radio resources, the network priorities are again reordered to

similar to phase 1:




The PS performance is again an operator priority, the user want to have his service with a good quality. The

BSS parameters should be optimised to allow a better throughput, e.g. more bandwidth in radio and

transmission resources. It is proposed to get back the parameter values to the default ones. For the default

parameters values see sub-chapter 2.10

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

5 QOS FOLLOW-UP In this chapter is presented the main RNO indicators for QoS follow-up, they are grouped in three specific

RNO reports called dashboards:

o Alc_Mono_DashBoard_(E)GPRS_QoS

o Alc_Mono_DashBoard_(E)GPRS_Traffic_1

o Alc_Mono_DashBoard_(E)GPRS_Traffic_2

The Main RNO indicators are also included in several RNO reports and in this way it is also presented in this

chapter the main RNO reports to analyse.

An overview of end-user statistics is described in the sub-chapter 5.6.

5.1 TBF LIFE TIME

5.1.1 TBF ESTABLISHMENT

The next indicators allows to follow the success of the TBF establishment and the possible existing failures,

this ones can be due to radio, transmission interface, BSS internal failures or to congestion. It is not

possible in the current BSS release to distinguish the TBF establishments between GPRS and EDGE TBFs, this

lack of information can hide problems related to only one technology.

For DL:

Table 20: DL TBF Establishment RNO indicator Description Unit Comments

GPRS_DL_TBF_success_rate Rate of DL TBF establishment -successes (seized by the mobile)

%

GPRS_DL_TBF_request Number of DL TBF establishment -requests. nb

The absolute number of requests is important to validate the statistics

GPRS_DL_TBF_estab_allocated_rate Rate of DL TBF allocated per cell. % This indicator measure the impact of the congestion

GPRS_DL_TBF_estab_fail_BSS_rate Rate of DL TBF estab - failures due to BSS problem per cell. Reference: number of DL TBF estab -requests

%

GPRS_DL_TBF_estab_fail_GB_rate Rate of DL TBF estab -failures due to Gb interface problem per cell. Reference: number of DL TBF estab -requests

%

GPRS_DL_TBF_estab_fail_radio_rate Rate of DL TBF estab -failures due to radio problem per cell. Reference: number of DL TBF estab -requests

%

GPRS_DL_TBF_estab_fail_cong_rate

Rate of DL TBF establishment failures due to congestion per cell. Reference: number of DL TBF establishment requests.

%

Split of failures during DL TBF establishment

GPRS_DL_TBF_estab_fail_abis_cong Number of DL establishment failures due to congestion of Abis.

nb

GPRS_DL_TBF_estab_fail_ater_cong Number of DL establishment failures due to congestion of Ater(Mux).

nb

GPRS_DL_TBF_estab_fail_cpu_cong Number of DL establishment failures due to CPU processing power limitations of the GPU.

nb

GPRS_DL_TBF_estab_fail_dsp_cong Number of DL establishment failures due to congestion of DSP.

nb

GPRS_DL_TBF_estab_fail_radio_cong Number of DL TBF establishment failure due to radio congestion per cell.

nb

Split of the congestion failures, this information is important for BSS dimensioning


ED 1 RELEASED 011




itted without


For UL:

Table 21: UL TBF Establishment RNO indicator Description Unit Comments

GPRS_UL_TBF_success_rate Rate of UL TBF estab success. Reference: number of UL TBF estab -requests

%

GPRS_UL_TBF_request Number of UL TBF establishment -requests per cell.

nb The absolute number of requests is important to validate the statistics

GPRS_UL_TBF_estab_allocated_rate Rate of UL TBF allocated per cell. % This indicator measure the impact of the congestion

GPRS_UL_TBF_estab_fail_BSS_rate Rate of UL TBF estab -failures due to BSS problem per cell. Reference: number of UL TBF estab -requests

%

GPRS_UL_TBF_estab_fail_GB_rate Rate of UL TBF estab -failures due to Gb interface problem per cell. Reference: number of UL TBF estab -requests

%

GPRS_UL_TBF_estab_fail_radio_rate Rate of UL TBF estab -failures due to radio problem per cell. Reference: number of UL TBF estab -requests

%

GPRS_UL_TBF_estab_fail_cong_rate

Rate of UL TBF establishment failures due to congestion per cell. Reference: number of UL TBF establishment requests.

%

Split of failures during UL TBF establishment

GPRS_UL_TBF_estab_fail_abis_cong Number of UL establishment failures due to congestion of Abis.

nb

GPRS_UL_TBF_estab_fail_ater_cong Number of UL establishment failures due to congestion of Ater(Mux).

nb

GPRS_UL_TBF_estab_fail_cpu_cong Number of UL establishment failures due to CPU processing power limitations of the GPU..

nb

GPRS_UL_TBF_estab_fail_dsp_cong Number of UL establishment failures due to congestion of DSP.

nb

GPRS_UL_TBF_estab_fail_radio_cong Number of UL TBF establishment failure due to radio congestion per cell.

nb

Split of the congestion failures, this information is important for BSS dimensioning

When performing an investigation in the TBF establishment performance, a typical threshold to consider is

for DL is 95%, however for UL the threshold is lower 92% mainly due to signalling impact.

These values are high depended of the network configuration and overall performance. The different

failure causes should be analysed:

o Failures due to Gb – this might indicate problems at Gb link side (no BVC available, which would

affect the cell – this implies that the cell’s operational state is “disabled”);

o Failures due to BSS – this might indicate a system problem (e.g.: faulty board at MFS side). Verify

also if CS traffic is being affected due to BSS causes (e.g. TCH assign failures due to BSS);

o Failures due to congestion: these can also be divided in other sub-causes:

• Radio congestion – this might be due to badly functioning resources (like a TRE not working,

with unavailable TS or even 0 available TS), from too much CS traffic, or even from too

much PS traffic.

• Abis congestion, Ater congestion, DSP congestion and CPU congestion – either due to lack of

GCHs resources or not enough DSP and/or CPU processing power.

o Failures due to radio – might indicate radio problems (e.g. bad frequency plan, bad coverage

planning)

5.1.2 TBF DATA TRANSFER

These indicators evaluate the release of a TBF, they reflect possible failures during data transfer and TBF

releases due to reselection for moving MS.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

For DL:

Table 22: DL TBF Data Transfer RNO indicator Description Unit Comments

GPRS_DL_TBF_normal_release_rate Rate of DL TBF normal release. Reference: number of DL TBF establishment - successes

%

Rate of DL TBF not impacted by failures or reselection during data transfer

GPRS_DL_TBF_acceptable_release_rate

Rate of DL TBF release due to: - DL TBF release due to radio preemption - DL TBF release due to suspend resume procedure - DL TBF release due to cell reselection. Reference : number of DL TBF successes

%

Rate of DL TBF impacted during data transfer due to features to favour CS or cell reselection.

GPRS_DL_TBF_drop_rate Rate of DL TBF drops. Reference: number of DL TBF establishment - successes

%

GPRS_DL_TBF_normal_release Number of DL TBF normal release. nb

GPRS_DL_TBF_acceptable_release

Number of DL TBF release due to : - DL TBF release due to radio preemption - DL TBF release due to suspend resume procedure - DL TBF release due to cell reselection

nb

GPRS_DL_TBF_drop Total number of DL TBF drops. nb

GPRS_DL_TBF_radio_preemption_release_rate

Rate of DL TBF releases due to fast preemption in case of need of radio resources. Reference: number of DL TBF establishment successes.

%

GPRS_DL_TBF_release_suspend_rate

Rate of suspend messages for a DL TBF received from MS (via BSC). Reference: number of DL TBF establishment successes.

%

GPRS_DL_TBF_release_NC2_reselect_rate

Rate of DL TBF releases due to NC2 cell reselection Reference: total number of DL TBF establishment success

%

GPRS_DL_TBF_release_NC0_reselect_rate

Rate of DL TBF releases due to NC0 cell reselection Reference: total number of DL TBF establishment success

%

Split of acceptable release causes

GPRS_DL_TBF_drop_BSS_rate Rate of DL TBF drops due to BSS problems. Reference: number of DL TBF establishment - successes

%

GPRS_DL_TBF_drop_GB_rate

Rate of DL TBF drops due to Gb interface problems. Reference: number of DL TBF establishment - successes

%

GPRS_DL_TBF_drop_blocking_rate

Rate of DL TBF drops due to blocking situation at the beginning or at the end of DL TBF ( including blocking situation following NC2 cell reselection) . Reference: number of DL TBF establishment successes.

%

GPRS_DL_TBF_drop_N_stagnatingWindow_rate

Rate of DL TBF drops due to N_StagnatingWindow (including N_StagnatingWindow following cell reselection in transfer mode). Reference: number of DL TBF establishment successes

%

Split of TBF drop causes


ED 1 RELEASED 011




itted without


GPRS_DL_TBF_realloc_execution_fail_radio_rate

Rate of DL TBF drops due to radio failures during radio resource reallocation execution. Reference: number of DL TBF establishment successes.

%

GPRS_DL_TBF_drop_radio_rate Rate of DL TBF drops due to radio problems. Reference: number of DL TBF establishment - successes

%

For UL:

Table 23: UL TBF Data Transfer RNO indicator Description Unit Comments

GPRS_UL_TBF_normal_release_rate Rate of UL TBF normal releases. Reference: number of UL TBF establishment - successes

%

Rate of UL TBF not impacted by failures or reselection during data transfer

GPRS_UL_TBF_acceptable_release_rate

Rate of UL TBF releases due to: - TBF release due to radio preemption - TBF release due to suspend resume procedure - TBF release due to cell reselection. Reference : number of UL TBF success.

%

Rate of UL TBF impacted during data transfer due to features to favour CS or cell reselection.

GPRS_UL_TBF_drop_rate Rate of UL TBF drops. Reference: number of UL TBF establishment - successes

%

GPRS_UL_TBF_normal_release Number of UL TBF normal releases. nb

GPRS_UL_TBF_acceptable_release

Number of UL TBF releases due to : - UL TBF release due to radio preemption - UL TBF release due to suspend resume procedure - UL TBF release due to cell reselection

nb

GPRS_UL_TBF_drop Number of UL TBF drop. nb

GPRS_UL_TBF_radio_preemption_release_rate

Rate of UL TBF releases due to fast preemption in case of need of radio resources. Reference: number of UL TBF establishment successes.

%

GPRS_UL_TBF_release_suspend_rate

Rate of suspend messages for an UL TBF received from MS (via BSC). Reference: number of UL TBF establishment successes.

%

GPRS_UL_TBF_release_NC2_reselect_rate

Rate of UL TBF releases due to NC2 cell reselection Reference: number of UL TBF establishment successes

%

GPRS_UL_TBF_release_NC0_reselect_rate

Rate of UL TBF releases due to NC0 cell reselection Reference: number of UL TBF establishment successes

%

Split of acceptable release causes

GPRS_UL_TBF_drop_BSS_rate Rate of UL TBF drops due to BSS problems. Reference: number of UL TBF establishment - successes

%

GPRS_UL_TBF_drop_GB_rate

Rate of UL TBF drops due to GB interface problems. Reference: number of UL TBF establishment - successes

%

GPRS_UL_TBF_drop_blocking_rate

Rate of UL TBF drops due to blocking situation at the beginning or at the end of UL TBF (including blocking situation following NC2 cell reselection). Reference: number of UL TBF establishment successes.

%

Split of TBF drop causes

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

GPRS_UL_TBF_drop_N_stagnatingWindow_rate

Rate of UL TBF drops due to N_StagnatingWindow (including N_StagnatingWindow following cell reselection in transfer mode). Reference: number of UL TBF establishment successes

%

GPRS_UL_TBF_realloc_execution_fail_radio_rate

Rate of UL TBF drops due to radio problems during radio resource reallocation execution Reference: number of UL TBF establishment successes.

%

GPRS_UL_TBF_drop_radio_rate Rate of UL TBF drops due to radio problems Reference: number of UL TBF establishment - successes

%

It is acceptable to have as lower as 95% for DL/UL TBF normal release rate, in case of DL/UL TBF drop rate

is expected to have value up to 4%.These value can change with the network design and interference noise

level in the network.

To perform an investigation in the data transfer, verify how TBF’s are being abnormally released. The

following causes are possible:

o RLC blocks are being lost during the GPRS connection

o RLC blocks are being retransmitted too many times – check the TBF Retransmission Ratio KPI;

o Connection drop is high – this might be due to 3 other sub-causes:

• System drop – indicating a system problem. Verify other KPI (GSM included);

• Gb drop – indicating problem on Gb interface;

o Radio drop – this might be due either to real radio drops or to acceptable releases (due to cell

reselection; suspend/resume procedure; PDCH pre-emption).

5.1.3 TBF REALLOCATION

To understand the TBF reallocation indicators is important to read the subchapter 2.6. The B9 release

brought new triggers to the reallocation comparing to B8, not only the PDCH allocation and soft pre-empted

are considered but also in B9 the GCHs reallocation and pre-emption.

Table 24: TBF Reallocation RNO indicator Description Unit Comments

GPRS_DL_TBF_realloc_T1_success_rate Rate of DL TBF reallocation Trigger 1 success over the number of DL TBF trigger 1 requests

%


%


%

GPRS_DL_TBF_realloc_T4_success_rate DL T4 reallocation success rate. %

GPRS_DL_TBF_realloc_T1_request Number of DL TBFs candidate for resource reallocation (trigger T1).

nb

GPRS_DL_TBF_realloc_T2_request Number of DL TBFs candidate for resource reallocation (trigger T2).

nb

GPRS_DL_TBF_realloc_T3_request Number of DL TBF candidate for resource reallocation (trigger T3).

nb

GPRS_DL_TBF_realloc_T4_request Number of DL TBF candidate for resource reallocation (trigger T4).

nb


GPRS_UL_TBF_realloc_T1_success_rate Rate of UL TBF reallocation Trigger 1 success over the number of UL TBF trigger 1 requests

%


%


%


ED 1 RELEASED 011




itted without


GPRS_UL_TBF_realloc_T4_success_rate

Rate of UL TBF resource reallocation successes for trigger T4. Reference: number of UL TBF candidate for resource reallocation for trigger T4.

%

GPRS_UL_TBF_realloc_T1_request Number of UL TBF candidate for resource reallocation (trigger T1).

nb

GPRS_UL_TBF_realloc_T2_request Number of UL TBFs candidate for resource reallocation (trigger T2).

nb


nb


nb


The investigation of the reallocation indicators is complex due to the high number of variables impacting

the reallocation algorithm performance. Depending on the trigger of each reallocation there is impact of

the PS traffic type and load, CS traffic load, network architecture, telecom parameters and MS type. For

one reallocation the trigger can also be due to two different reasons radio resources or transmission

resources, as possible analyses:

o High frequency of occurrence of T1 might indicate that the cell is sub-dimensioned to

accommodate all CS and PS traffic;

o The high number of T2 requests can be a consequence of the value of the parameter

GPRS_Multislot_Class_Def_Value and the traffic type (user data or GMM /SM).

For the reallocation indicators is not possible to define global thresholds since the performance of these

indicators will change from network to network.

5.2 RLC STATISTICS

5.2.1 (M)CS DISTRIBUTION

There are large possibilities to calculate/present the distribution of CS and/or MCS blocks. But all

ratios/rates/useful throughput/etc. indicators will be based on the number of useful blocks received per

(M)CS. Here we propose the MCS distribution statistics given its ratio, e.g. the number of transmitted useful

RLC blocks by overall useful RLC blocks, for DL and for UL.

The throughput indicators calculated using the (M)CS distribution are important for stability, since it

doesn’t represent the available maximum or average throughput in the cell, The throughput indicators are

impacted by small amount of data transfer

For DL:

Table 25: DL (M)CS Distribution RNO indicator Description Unit Comments

GPRS_DL_useful_RLC_blocks_CS1_ack_ratio

Ratio of useful DL RLC blocks sent on PDTCH encoded in CS-1, in RLC acknowledged mode (the retransmitted blocks are not counted). Overall number of useful RLC data blocks encoded in CS1-2-3-4

%



%

Split of the CS distribution

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.



%



%

GPRS_DL_useful_RLC_blocks_MCS1_ack_ratio

Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-1, in RLC acknowledged mode (the retransmitted blocks are not counted).

%



%



%



%



%



%



%



%



%

Split of the MCS distribution

GPRS_DL_useful_throughput_radio_EGPRS_TBF_avg

Average DL useful throughput (in kbit/s) in RLC acknowledged mode. The DL retransmissions are not counted. Reference Time: Cumulated time duration of all active DL TBFs established in EGPRS mode.

kbit/s

GPRS_DL_useful_throughput_radio_GPRS_TBF_avg

Average DL useful throughput (in kbit/s) in RLC acknowledged mode. The DL retransmissions are not counted. Reference Time : Cumulated time duration of all active DL TBFs established in GPRS mode.

kbit/s

High impacted by the small data transfer, such as GMM and SM.

For UL:


ED 1 RELEASED 011




itted without


Table 26: UL (M)CS Distribution RNO indicator Description Unit Comments

GPRS_UL_useful_RLC_blocks_CS1_ack_ratio

Ratio of useful UL RLC blocks sent on PDTCH encoded in CS-1, in RLC acknowledged mode (the retransmitted blocks are not counted). Overall number of useful RLC data blocks encoded in CS1-2-3-4

%



%



%



%

Split of the CS distribution

GPRS_UL_useful_RLC_blocks_MCS1_ack_ratio

Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-1, in RLC acknowledged mode (the retransmitted blocks are not counted).

%



%



%



%



%



%



%



%



%

Split of the MCS distribution

GPRS_UL_useful_throughput_radio_EGPRS_TBF_avg

Average UL useful throughput (in kbit/s) in RLC acknowledged mode. The UL retransmissions are not counted. Reference: Cumulated time duration of all UL TBFs established in EGPRS mode.

kbit/s

High impacted by the small data transfer,

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

GPRS_UL_useful_throughput_radio_GPRS_TBF_avg

Average UL useful throughput (in kbit/s) in RLC acknowledged mode. The UL retransmissions are not counted. Reference Time: Cumulated time duration of all UL TBFs established in GPRS mode.

kbit/s

such as GMM and SM.

The (M)CS distribution may be impacted by the radio conditions, telecom parameters but they are almost

not impacted by the transmission resources in B9 release.

It is normal to have the major sample in the (M)CS corresponding to the TBF_DL/UL_INIT_(M)CS, default for

GPRS is CS2 and for EDGE is MCS3. The impact of the initial (M)CS is high due to the high number of TBFs

with small data transferred, GMM/SM and MMS,…

A high number of MCS1 or CS1 can be due to the existing radio conditions or due to limit transmission

resources.

In B9 and in cells covering an area with good radio conditions, the MCS9 should have weight in the overall

distribution.

5.2.2 LLC/RLC TRAFFIC AND RETRANSMISSION

The overall user traffic in a cell should be measured by the next 2 indicators one for DL another for UL.

Table 27: LLC traffic

RNO indicator Description Unit Comments

GPRS_DL_LLC_bytes Number of DL LLC bytes received from the SGSN at BSSGP level per cell.

nb Overall DL LLC traffic

GPRS_UL_LLC_bytes Number of UL LLC bytes sent to the SGSN at BSSGP level per cell.

nb Overall UL LCC traffic

The split of LCC traffic by the Radio Access Capabilities are in the next 2 tables.

For DL:

Table 28: DL LLC traffic

RNO indicator Description Unit

GPRS_DL_LLC_bytes_EGPRS_ack_mode Number of DL LLC bytes transmitted and acknowledge on established DL TBF in EGPRS mode and RLC acknowledged mode

nb

GPRS_DL_LLC_bytes_EGPRS_unack_mode Number of DL LLC bytes transmitted and acknowledge on established DL TBF in EGPRS mode and RLC unacknowledged mode

nb

GPRS_DL_LLC_bytes_GPRS_ack_mode Number of DL LLC bytes transmitted and acknowledge on established DL TBF in GPRS mode and RLC acknowledged mode

nb

GPRS_DL_LLC_bytes_GPRS_unack_mode Number of DL LLC bytes transmitted and acknowledge on established DL TBF in GPRS mode and RLC unacknowledged mode

nb

For UL:


ED 1 RELEASED 011




itted without


Table 29: UL LLC traffic

RNO indicator Description Unit

GPRS_UL_LLC_bytes_EGPRS_ack_mode Number of UL LLC bytes received on UL TBFs established in EGPRS mode and RLC ackowledged mode

nb

GPRS_UL_LLC_bytes_EGPRS_unack_mode Number of UL LLC bytes received on UL TBFs established in EGPRS mode and RLC unackowledged mode

nb

GPRS_UL_LLC_bytes_GPRS_ack_mode Number of UL LLC bytes received on UL TBFs established in GPRS mode and RLC ack mode

nb

GPRS_UL_LLC_bytes_GPRS_unack_mode Number of UL LLC bytes received on UL TBFs established in GPRS mode and RLC unackowledged mode

nb

The indicators for RLC traffic are the next tables

For DL:

Table 30: DL RLC traffic RNO indicator Description Unit Comments

GPRS_DL_useful_bytes_CSx_ack Number of useful RLC data bytes sent on PDTCH, in GPRS and RLC ack modes.

nb

GPRS_DL_useful_bytes_MCSx_ack Number of useful RLC data bytes sent on PDTCH, in EGPRS and RLC ack modes.

nb

GPRS_DL_RLC_bytes_PDTCH_CSx_retransmission_ratio

In RLC ack mode, ratio of downlink RLC retransmitted data bytes sent on PDTCH and encoded in CS-x. Reference : overall number of DL RLC data bytes transmitted in GPRS mode

%

This indicator is an overall indication, however some CS may be more retransmitted than others.

GPRS_DL_RLC_bytes_PDTCH_MCSx_retrans_ack_ratio

In RLC acknowledged mode, ratio of DL RLC data bytes encoded in MCS-x and retransmitted due to unacknowledgement of the MS. RLC blocks containing LLC dummy UI commands are not counted. Reference: overall number of DL RLC data bytes transmitted in EGPRS mode.

% This indicator is an overall indication, however some CS may be more retransmitted than others.

For UL:

Table 31: UL RLC traffic


GPRS_UL_useful_bytes_CSx_ack Number of useful RLC bytes sent on PDTCH in GPRS and RLC ack modes

nb

GPRS_UL_useful_bytes_MCSx_ack Number of useful RLC bytes sent on PDTCH in EGPRS and RLC ack modes

nb

GPRS_UL_RLC_bytes_CSx_retransmissing_ack_ratio

In RLC ack mode, ratio of uplink RLC bytes retransmitted on PDTCH and encoded in CS-x. Reference : total number of UL RLC data bytes sent on PDTCH in RLC ack mode

%


GPRS_UL_RLC_bytes_PDTCH_MCSx_retrans_ack_rate

In acknowledged mode, ratio of UL RLC data bytes encoded in MCS-x and retransmitted due to unacknowledgement of the MFS. Reference : overall number of UL RLC data bytes sent on PDTCH encoded in MCSx in RLC ack mode

%


ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

For both DL and UL the MCS retransmission rate can be up to 10%, this value is due to the fact of the higher

MCS being less robust and so more sensible to interference.

5.3 RADIO RESOURCES

One main reason for the existence of the radio resources indicators is to allow a good PS radio dimensioning

in a cell. It is possible to monitor the use of the PDCH not only the time they are established but also the

number of pilled TBF per PDCH.

Table 32: Radio Resources RNO indicator Description Unit Comments

GPRS_PDCH_EGPRS_traffic_time Cumulative time during which the slave PDCHs are established and carry at least one UL or DL TBF.(established in EGPRS mode)

s

GPRS_PDCH_traffic_time Cumulative time during which the slave PDCHs are established and carry at least one UL or DL TBF.(established in GPRS mode or EGPRS mode).

s

GPRS_PDCH_active_avg

For B8: average number of established slave PDCHs. For B9: average number of slave PDCHs carrying at least one UL or DL TBF.(established in GPRS mode or EGPRS mode). Reference: observation period

nb

GPRS_PDCH_used_max

Maximum number of PDCHs used in the cell Note: B8: It count the established PDCHs. An established PDCH is a PDCH to which one (several) transmission resource(s) is (are) connected. B9: It count the used (active) PDCH. An used PDCH is a PDCH that carries at least one UL or DL TBF. Consolidated in Day/Week/Month with the MAX value.

nb

These indicators are important for radio dimensioning

GPRS_DL_connection_time_avg Average connection time of established DL TBF (active and delayed). Reference : Number of DL TBF successes.

s

GPRS_UL_connection_time_avg Average connection time of established UL TBF. Reference : Number of UL TBF successes.

s

GPRS_DL_TBF_Pilled_avg

Average number of DL TBF on PDCHs active with DL transfers (TBF active and delayed phases are taken into account). An active PDCH with DL transfer is a PDCH carrying at least one DL TBF.

nb

GPRS_UL_TBF_Pilled_avg

Average number of UL TBF on PDCHs active with UL transfers (TBF active and delayed phases are taken into account). This indicator gives a measure of the number of UL TBFs piled up on a PDCH for all the PDCH. An active PDCH with UL transfer is a PDCH carrying at least one UL TBF.

nb


GPRS_DL_TBF_estab_avg Average number of DL TBF simultaneously established over the granularity period. Consolidated in Day/Week/Month with the MAX value.

nb

GPRS_UL_TBF_estab_avg Average number of UL TBF simultaneously estab over the Granularity period. COnsolidated in day-week-month with the MAX value.

nb

GPRS_PDCH_per_DL_TBF_avg

Average number PDCHs (active with DL transfers) per DL TBF (TBF active and delayed phases are taken into account). An active PDCH with DL transfer is a PDCH carrying at least one DL TBF.

nb

GPRS_PDCH_per_UL_TBF_avg

Average number PDCHs (active with UL transfers) per UL TBF (TBF active and delayed phases are taken into account). An active PDCH with UL transfer is a PDCH carrying at least one UL TBF.

nb



ED 1 RELEASED 011




itted without


GPRS_PDCH_used_DL_TBF_GMM_signalling_time_ratio

Ratio of time during which a DL TBF established for GMM signaling purposes uses a PDCH, compared with all DL PDCH established, for all PDCHs and for all the TBFs of the cell.

%

GPRS_DL_biased_and_DL_optimal_alloc_percent

Percentage of time during which downlink TBFs are granted the maximum number of PDCHs they support and the corresponding MSs are engaged in downlink-biased transfers. Reference: time during which MSs are engaged in downlink-biased transfers and served by DL TBFs.

%

GPRS_UL_biased_and_UL_optimal_alloc_percent

Percentage of time during which uplink TBFs are granted the maximum number of PDCHs they support and the corresponding MSs are engaged in uplink-biased transfers. Reference: time during which MSs are engaged in uplink-biased transfers and served by UL TBFs.

%

GPRS_BSC_high_load_percent Percentage of time during which the BSC is in high load situation in the cell. Reference: Granularity period

%

GPRS_MAX_PDCH_nb_avg

Maximum number of PDCHs that can be allocated in the cell. This indicator is consolidated in Day/Week/Month with the average of Hour/Day/Week values.

nb

This indicator is a function of the parameter Max_PDCH

GPRS_MIN_PDCH_nb_avg

Minimum number of PDCHs that can be preferentially allocated in the cell. This indicator is consolidated in Day/Week/Month with the average of Hour/Day/Week values.

nb

This indicator is a function of the parameter Min_PDCH

The pilled indicators are in restriction up to B9 MR4 ed6.

5.4 TRANSMISSION RESOURCES

The main indicators for transmission resource are impacted by Abis and Ater interface.

Table 33: Transmission Resources


GPRS_transmission_GCH_busy_average Average number of GIC 16k busy (i.e. operational and used).

nb

GPRS_transmission_GCH_deficit_average Average number of GCH resources in deficit in the cell.

nb

Monitor the lack of transmission resources, Abis and Ater interface

GPRS_transmission_GCH_excess_average Average number of GCH resources in excess in the cell.

nb

GPRS_transmission_GCH_use_bonus_and_extra_average

Average number of extra and bonus Abis nibbles used in the cell.

nb

GPRS_transmission_GCH_use_bonus_and_extra_avg_max

Average number of extra and bonus Abis nibbles used in the cell. This indicator is consolidated in Day/Week/Month with the MAX value.

nb

These transmission indicators are very wide and for a deeper investigation there is in RNO a few number of

indicators for CELL, BSS and GPU. It is also recommended to read sub-chapters 6.6 and 6.7.

5.5 RNO REPORTS

The RNO reports for (E)GPRS QoS follow up are presented below:

o Alc_Mono_GPRS_telecom: This report provides details about main GPRS Telecom procedures.

• DL TBF establishment

• UL TBF establishment

• DL TBF Release

• UL TBF Release

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

• DL TBF Acceptable Release causes

• UL TBF Acceptable Release causes

• DL TBF Drop Causes

• UL TBF Drop Causes

• DL TBF state

• UL TBF state

• DL session

• UL session

o Alc_Mono_GPRS_Throughput: This report provides details of GPRS/EGPRS throughputs.

• Radio throughput per cell

• DL GPRS radio throughput

• UL GPRS radio throughput

• DL EGPRS radio throughput

• UL EGPRS radio throughput

o Alc_Mono_GPRS_Resource_Reallocation_DL: This report provides details about the procedures

related to the DL resource reallocation feature

• DL resource realloc

• DL resource realloc T1




o Alc_Mono_GPRS_Resource_Reallocation_UL: This report provides details about the procedures

related to the UL resource reallocation feature

• UL resource realloc

• UL resource realloc T1




o Alc_Mono_GPRS_RLC_Ack_Traffic_Coding_Schemes: This report provides all the views related to RLC

traffic and efficiency in RLC acknowledged mode.

• RLC traffic in Acknowledge Mode

• DL EGPRS useful RLC traffic

• UL EGPRS useful RLC traffic

• GPRS DL useful RLC traffic

• GPRS UL useful RLC traffic

• DL RLC Ack retransmitted traffic per CS

• UL RLC Ack retransmitted traffic per CS

o Alc_Mono_GPRS_PDCH_Use_B9: This report provides all views related to PDCH allocation B9.

• Load Report

• Traffic time and Active number of PDCHs


ED 1 RELEASED 011




itted without


• DL TBF Pilled

• UL TBF Pilled

• PDCH per DL TBF

• PDCH per UL TBF

• DL TBF establishment per MS type

• UL TBF establishment per MS type

• GMM Signaling

• PDCH Preemption

o Alc_Mono_GPRS_Transmission_Resources: This report provides details about main GPRS transmission

resources.

• GPRS GCH resources

• Extra and Bonus Abis nibbles

• GCH in deficit

• GCH in excess

5.6 END-USER STATISTICS

The majority of the EDGE analyses go through the end user tests and their results. Three indicators are

considered as the main ones for QoS follow-up, they are from FTP and Ping test:

o DL FTP Application Throughput

o UL FTP Application Throughput

o Ping Application time

The EDGE protocol for end-user tests is detailed in reference [1]. The recommended protocol by NE should

be followed to allow the proper support from NE team. A deviation from the protocol may lead to results

different from the ones expected.

The expected values for these indicators are presented in this subchapter, they are the processed data

collected from different field trials. The analysis is based in statistical values and due to that it is highly

dependent of samples quality. A method was considered to validate in a first step the samples and then the

final results.

During an end-user field trial several external variables can impact the results:

o Upper layers (TCP/IP and FTP) performance

o Radio conditions (good, normal, radio)

o RF load (high CS traffic, high PS traffic)

o Radio resources allocation (number of PDCHs allocated, number of TBFs per PDCH)

o Transmission resources allocation (number of GCH)

Three different radio conditions are considered and they are based in the indicators RxLev and Mean_BEP.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Table 34: Radio Conditions

Radio Conditions RxLev Mean_BEP

Good [-55 dBm, -65 dBm] [31, 25]

Normal [-65 dBm, -85 dBm] [25, 15]

Poor [-85 dBm, -100 dBm] [15, 0]

In the expected results is considered that no impact exist from the radio and transmission resources.

Table 35: Expected Application Throughput

Radio Conditions Expected DL Applic Throughput

per PDCH interval (kbit/s) Expected UL Applic Throughput

per PDCH interval (kbit/s)

Good 40.0 - 53.5 28.9 - 40.0

Normal 35.7 - 43.6 26.5 - 38.1

Poor 28.2 - 38.0 14.9 – 22.8


ED 1 RELEASED 011




itted without


6 OPTIMISATION METHODS AND CONSTRAINTS

6.1 LOW DL THROUGHPUT OBSERVED

The main “complain”, during end-to-end tests, is the observation of low DL throughput at application layer

and at RLC layer. In 80% of the cases this issue is not associated with BSS network, the major problems

observed are in the PDP context negotiation and in the FTP server configuration. This complains comes

when non prepared end user tests are done, in services such as FTP download.

FTP is the best option to measure the throughput in a network.

6.1.1 END-TO-END ANALYSIS

In end-to-end analysis all parts of a network are analysed and their performance evaluated. The analysis

can be split in two, the impact of the radio layers and the impact of the upper layers (LLC layer up to

Application layer).

Test preparation

The correct use of tools and test preparation is necessary to have a reliable analysis of the results. When a

low DL throughput is observed, the tests should be repeated several times to give as much as possible

statistical consistency of the results.

A set of tools is proposed:

o Deutrip: Generates application traffic automatically (FTP, WEB, Streaming, etc.) and records

statistics (application throughput, access time, etc.)

o Ethereal: Protocol analysis (TCP/IP but also many others), developed by the Open-source

community (GNU license) and works on top of a capture library (WinPcap, for Windows)

o Agilent E6474A (Nitro): Tool to collect and process air interface trace

o K12/K15: they are used to collect data from different interfaces, one important for PS analysis is

the Gb.

o Compass: tool used mainly to post-process the data from Gb traces, two possible usages : global

analysis of user traffic and deep analysis of traffic generated during tests.

The layer where these tools are used is explained by the figure below.

Figure 6–1: Network Architecture.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

When performing the test, first it is important to eliminate possible impact of the radio conditions and

network load (radio and transmission), a way to do it is to perform the test in good coverage cells, well

dimensioned and in low traffic hours. Second, the FTP server configuration and location should be verified.

With these previous constrains removed, the test is performed and the results can easily be analysed.

First step: Ethereal trace analysis

The Ethereal gives a global view of the transfer, the light investigation performs in this first step will give a

direction to a deeper analysis:

a) Pollution traffic

Check possible pollution traffic, e.g. packet traffic generated by windows update, anti-virus update, etc.

This extra traffic can have an impact in the end-user application throughput, by “stealing” bandwidth.

Check in the message transfer window the IP Source address and the IP destination address, it should be

only from your PC and from the FTP server.

If polluted traffic is observed, before repeating the test, remove all possible source of background packet

switch traffic. For example disable the windows update.

b) Main TCP parameters

To go deeper in the TCP/IP analyses check the main TCP parameters (MTU, RWIN):

o MTU recommended value is 1500 Bytes = MSS + 40 Bytes => MSS = 1460 Bytes.

• To check the used MSS see as example the figure below (note: MSS is only available in SYN,

ACK/SYN messages):

Figure 6–2: Ethereal example - MSS.


ED 1 RELEASED 011




itted without


o RWIN is recommended to be set to 64kBytes (64520 Bytes)

• Also this TCP parameter can be checked in the message layer.

Figure 6–3: Ethereal example - RWIN.

If the TCP parameters are not correct checked and if the limitation is in the drive test PC, you can use

Dr.TCP (it is freeware tool that can be found in http://www.dslreports.com) to correct the TCP parameters.

The setting should be similar to the ones presented in the figure below.

Figure 6–4: Dr. TCP example – TCP parameters

If the TCP parameters are not correct in the PC you can use the same tool to implement the right values.

After, it is recommended to repeat the tests.

c) FTP transfer - data flow

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

The next step in the investigation is to analyse the overall data flow during FTP transfer. The process is to

filter one of the bad FTP download transfer by using the function “Follow TCP Stream”. These enables 3

main functions which give graphic representation of the round trip time, TCP throughput and packet flow

(data and ack).

The importance of a graphic representation is to have a better global view of the data transfer and a fast

identification of the bottlenecks and problems. The graphic time-sequence as the major information and

existing problems can be split in two, the next examples are representative of the most reported issues:

o BSS/Radio layers impact, for example due to bad radio conditions or cell-reselections.

Figure 6–5: Ethereal example – Time/Sequence graphic 1


Expected slope with throughput = 200kbit/s

Good throughput with small perturbations

(high MCS with BLER ?)

throughput is decreasing (MS going towards the edge of the cell, and MCS are decreasing ?)

2-3 seconds hole, with TCP losses (radio drop and LLC-FLUSH due

to reselection ?)

Retransmission of lost data


ED 1 RELEASED 011




itted without


o Upper layers impact, observed by TCP losses and retransmissions.



ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

Second step: in-depth analysis

In this step the investigation can follow two different ways, analysis of possible radio impact and analysis of

upper layers impact.

a) For the radio impact the process is to analyse the traces collected in the air interface, for example using

Nitro. The key indicators to investigate are:

o Radio conditions, given by Rx Level, mean_BEP and CV_BEP, define the radio conditions during the

test.

o MCS distribution, typical cases:

• High usage of MCS3, normally associated to TBF_DL_INIT_MCS

o Block Error Rate, high BLER can be due to bad radio conditions or equipment problems.

o DL RLC throughput per TS, the value of this indicator is dependent of the previous indicators values

and should be compared with the expected throughput per radio conditions presented in the

previous chapter.

b) The upper layer investigation is performed by analysing traces from different points, mainly they are

from TCP/IP trace at client side, Gb traces and TCP/IP at FTP server side.

During a FTP DL, see in Ethereal on the client side that some TCP segments are lost, and retransmitted.

This causes a big impact on the throughput. Most often the TCP segments are not lost by the BSS, but by

some other elements above it (Frame relay of the Gb interface, SGSN, IP backbone, etc.).

The principle of the analysis is to take an Ethereal trace on the PC client side, simultaneously with a Gb

trace (with K12/K15) and preference collect also Ethereal trace at FTP server side

First identify the TCP segment lost at client side.

Then try to see if they were already lost on Gb interface or not.

-> at client side, it should be seen something like this in DL :

A - B - [previous segment lost] - D - E - F - G - H - I - J - K - C - L - M - N - O...

-> at Gb side, either you have:

A - B - C - D - E - F - G - H - I - J - K - C - L - M - N - O... (segment not missing, so was lost after Gb)

Or:

A - B - D - E - F - G - H - I - J - K - C - L - M - N - O... (segment missing, so was lost before Gb).

TCP segments numbers have a unique identifier, which can be seen in both traces.

Beware that in Ethereal, it should be set the option to see the absolute value, not the relative one:

-> Menu Edit -> Preferences -> Protocols -> TCP -> Unselect "Relative sequence numbers and window scaling"

The steps of the analysis are:

a) In Ethereal, click on any DL frame with FTP-DATA.

b) Menu Statistics -> TCP Stream graph -> Time-sequence graph (tcptrace)

c) Identify in the trace a TCP segment lost and retransmitted. Click hold CTRL and click a segment in the

graph to go to the position in the trace.


ED 1 RELEASED 011




itted without


d) Identify the segment number of the retransmitted (lost) segment. (which was called "C" in the example

earlier).

e) Identify also the segment numbers "B" and "D"

NB: There should be: B = C - MSS, and D = C + MSS, with MSS=Max segment size, often 1380 or 1460.

f) Open the Gb trace for example with K12 record viewer and look for the TCP segments number B, C, D.

NB: in K12 record viewer, once the correct decoding stack is used, it should be possible to see the decoding

of TCP layer, and the TCP segments number. Find the TCP segment number (be careful to choose a DL one,

and to select the Segment number, not the ACK number). Then right mouse button click -> Add column.

That way you get the TCP segment number as a new column in the synthetic view.

g) check if there is :

A - B - C - D - E - F - G - H - I - J - K - C - L - M - N - O... (segment not missing, so was lost after Gb)

A - B - D - E - F - G - H - I - J - K - C - L - M - N - O... (segment missing, so was lost before Gb).

If the problem is before Gb, e.g. in the CN or IP network, forward the problem to the GSS team. If the

problem is after Gb it can be associated with the LLC layer parameterization and configuration.

Typical cases and solutions

a) BSS Network:

o Case: Less number of the DL PDCH allocated than the MS capability, due to the impact of load in

the cell

• Solution: Check cell configuration and radio dimensioning:

� Cell configuration and parameters such as:

• Number of TRX

• Number of TRA - EDGE capable

• Max_PDCH

• MAX_PDCH_High_Load

• Min_PDCH

• High_Traffic_Load_GPRS

� Check number of T1 reallocation

� GSM indicators, traffic load and congestion

� GPRS Radio resources allocation indicators, see sub-chapter 5.3

o Case: Gb Congestion noticed by NSE (UL congestion control), pre-emption of one PDCH per each

T_UL_Congestion seconds until the end of the Gb congestion.

• Solution: Check BVC parameters

o Case: Lifetime parameter is changing during DL LLC PDU transfer in the Gb.

• Solution. With Ericsson SGSN

� Set PDU_Lifetime_Order to disable

o Case: Low throughput observed due to lack of transmission resources.

• Solution: Perform BSS architecture and dimensioning, see chapter 3.

b) GSS Network

o Case: Wrong QoS parameters in the HLR and/or in the client side:

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

• Solution: The QoS parameters are negotiated during the PDP context activation; they are

defined by the minimum of the client or the network. Check in the PDP context negotiation

L3 messages the QoS parameters:

� RLC: ack

� LLC: unack

� Mean Throughput: Best-effort

� Peak throughput: Up to 256 000 octets/s (2 048 kbit/s).

• In the client side the QoS parameters can be tuning by the AT command:

� +CGDCONT=1,"IP","APN";+CGQREQ=1,3,4,3,0,0

c) IP Network

o Case: Wrong TCP/IP parameters, client side and FTP side.

• Solution: Using Dr. TCP correct the parameters values

� MTU = MSS + 40 = 1460 + 40 = 1500 Bytes

� RWIN > RTT * Bandwidth, recommended RWIN = 64520 Bytes

o Case: MTU bottleneck in IP network

• Solution: Find the largest non-fragment MTU in the network. Test the network by pinging

the server:

� “ping –l MSS –f target_name”

� Find the largest possible non-fragmented packet

• to compensate the difference between ICMP and TCP headers,

o add 28 Bytes (ICMP 8 Bytes & IP 20 Bytes headers) to the MSS to get

the MTU

o the MSS for TCP/IP to be configured for FTP DL or UL is MTU – 40

Bytes for headers (TCP 20 Bytes & IP 20 Bytes).

o Case: FTP server misconfigured:

• Solution: Check buffer size

• Solution: TCP parameters

• Solution: Check the FTP server load, number of clients connected, etc.

6.2 DL MCS FLUCTUATION

One common complain and also associated with the low throughput is the DL MCS fluctuation, normally

observed between MCS9 and MCS6.

This fluctuation could be due to the radio conditions or to uncontinuous LLC traffic.

6.2.1 RADIO CONDITIONS

The interference/bad quality in the network will generate some not well decode blocks leading to a need

of block retransmissions.

As example, it is considered that MCS9 is used in a DL data transfer. There is 2 RLC blocks per radio blocks

with the same number of payload as MCS6, see following table and figure:


ED 1 RELEASED 011




itted without


Table 36: MCSx structure

Figure 6–9: Radio Block structure

In case of RLC block is not well decoded from the MCS9 radio block, only this block will be retransmitted

and using MCS6. In the next example, it is considered that RLC block 1 is not well decoded and so it will be

retransmitted.

Figure 6–10: RLC block not well decoded

37 Bytes 37 Bytes 37 Bytes 37 Bytes

RLC Block 1 RLC Block 2

Radio Block

MCS9

37 Bytes 37 Bytes MCS6

RLC Block 1 - Retransmitted

Radio Block

37 Bytes 37 Bytes 37 Bytes 37 Bytes

RLC Block RLC Block

Radio Block

MCS3

MCS6

MCS9

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

To confirm the DL MCS fluctuation is due to radio conditions the BLER should be check.

6.2.2 UNCONTINUOUS LLC TRAFFIC

A second possible hypothesis for the DL MCS fluctuation is due to an uncontinuous LLC traffic. If the LLC

PDU traffic coming from the SGSN by the Gb is not continuous, the BSS is able to adapt the MCS according

the data size to be sent in the RLC/MAC data block. If there is no more DL LLC PDUs stored for the MS, RLC

sends the last segment of the last useful RLC data block. This radio block contains the last segment of the

last useful DL LLC PDU, completed by an LLC UI Dummy command in order to maintain the DL TBF alive.

If the radio block consists of two RLC data blocks (i.e. if the current MCS is MCS-7 or MCS-8 or MCS-9) and

the last segment of the last useful DL LLC PDU fits into the first part of the radio block, then the MCS shall

be decreased from MCS-9, 8 or 7 to MCS-6 or 5. Indeed, the first LLC UI Dummy command has already been

inserted into the end of the LLC queue in order to be send as last useful LLC PDU segment.

6.3 UL PERFORMANCE

As explained in sub-chapters 2.7 and 2.8, in B9 there was an improvement in the UL performance due to

three new features:

o Support of 8-PSK in uplink.

o Support of incremental redundancy and resegmentation.

o Extended UL TBF mode.

The feature “support of 8-PSK in uplink” is subject to optimisation as for DL, in terms of usage of highest

MCS.

6.3.1 RESEGMENTATION VS IR

With the introduction of 8-PSK modulation in uplink, two sub-features were introduced the incremental

redundancy and resegmentation, the first one is activated by the flag En_IR_UL and the second by the flag

En_Resegmentation_UL.

The default values for these parameters are:

o En_IR_UL = Disable

o En_Resegmentation_UL= Disable

Based in results from field trials, a NE recommendation is proposed:

o En_IR_UL = Enable

o En_Resegmentation_UL= Disable

This parameter set provides the best performances, whatever the radio conditions. The significant gain is

observed in medium and bad radio conditions. In good radio conditions the performance impact of the

parameter setting is neglected.

6.3.2 EXTENDED UL TBF MODE

The benefit of the feature extended UL TBF mode is measured by accessibility tests, e.g. pings. With small

interval between iteration the gain brought by the feature could be up to 60% of the time to ping a server.

The gain is depended of the ping size and the iteration interval. This achieve is possible due to keeping the

UL TBF established and to maintain the higher MCS between iteration. For more details see [2].


ED 1 RELEASED 011




itted without


6.4 ACCESS TIME OPTIMIZATION

The access time of a network is measured by the application service “ping”, a few parameter optimizations

are possible to improve ping performance, however all the parameter proposals have impact in the

transmission resources and there will be increase of load if applied:

o For all pings:

• TBF_DL/UL_Init_MCS - Increase the initial MCS from MCS3 to MCS6.

� Better throughput in the first blocks and lower ping time.

� Ping test are to be performed in good radio condition, so no impact in the tests are

expected due to radio conditions, for example retransmission due to a not well

decoded RLC block.

o Mainly for ping with small interval between iteration:

• EN_EXTENDED_UL_TBF – Enable the Extended UL TBF mode feature to maintain the UL TBF

alive

• T_MAX_EXTENDED_UL – The default is 2s, but can be increase if need for better ping

performance.

o Mainly for ping with medium and large interval between iteration:

• EN_FAST_INITIAL_GPRS_ACCESS – The feature will guarantee transmission resources are

keep established for the cell, along with the next parameter it will be possible to optimize

the transmission for the cell having ping test. It consume transmission resource even

without PS traffic in the cell

• N_GCH_FAST_PS_ACCESS – The increase of the parameter value from 1 to 5 will guarantee

enough resources in the cell for allowing good ping performances.

6.5 EDGE PERFORMANCE VERSUS FREQUENCY PLANNING

Since EDGE was launched in Alcatel Networks, there were several field trials and drive test campaigns, the

results retrieved from those measurements were analysed and processed.

From the analysis performed the Frequency Hopping can degraded EDGE performance in average less than

5%.

When an operator plans to implement EDGE several dimensioning decisions has to be done, such as the

radio resources and transmission resources, these major decisions have higher impact in the EDGE

performance than the frequency type. For example, 2 TBFs sharing the same PDCHs degraded 50% in the

EDGE performance, 3 PDCHs allocated in DL instead of 4 PDCHs have 25% of impact.

To conclude the design and the parameterization in a network have higher importance in the EDGE

performance, than the frequency hopping and so this last one can be neglected, if it is not too aggressive.

6.6 ABIS CONGESTION

As explained in chapters 2.3.2 and 3.1 in B9 Abis TS have a dynamic allocation for PS. Being dynamic, it has

associated a probability of congestion, that increases with the increase of load in the cell. To provide high

EDGE performance, in B9 less extra Abis nibbles are configured for a BTS than in B8.

To detect possible Abis congestion, check first the global transmission indicators and after the Abis specific

indicators.

At transmission (Abis/Ater) level:

o GPRS_transmission_GCH_deficit_time - Cumulated time during which there is a deficit of GCH

resources in the cell.

o GPRS_transmission_GCH_deficit_average - Average number of GCH resources in deficit in the cell.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

At Abis level:

o GPRS_transmission_deficit_extra_and_bonus_time - Cumulated time during which there are extra

and bonus Abis nibbles in deficit in the BTS.

o GPRS_transmission_deficit_extra_and_bonus_average - Average number of extra and bonus Abis

nibbles in deficit in the BTS.

As remark the deficit given by the counter P470, used in the previous indicators, is a "relative" deficit

because it depends on the configuration of two parameters R_AVERAGE_GPRS and R_AVERAGE_EGPRS. The

counter P470 is in the restriction list with the FR 3BKA13FBR181686, the correction was done in MR4 Ed02 - Patch 30CP_00E.

In a critical situation the impact of the Abis congestion should be observed in the TBF establishment

indicators:

o For DL:

• GPRS_DL_TBF_estab_fail_abis_cong - Number of DL establishment failures due to

congestion of Abis.

o For UL:

• GPRS_UL_TBF_estab_fail_abis_cong - Number of UL establishment failures due to

congestion of Abis.

Few parameters can be optimized to decrease congestion in the Abis, however they have end-user

performance impact. For a permanent solution consider a new dimensioning study in the network.

o T_GCH_Inactivity - Timer to postpone the release of the “unused” GCHs of a TRX after TBF

release(s).

• Changeable by operator at BSS level - Min = 1s, Def = 3s, Max = 100s.

• Recommendation for congestion situation:

� Decrease the parameter value for 2s to save transmission resources.

o T_GCH_Inactivity_Last - Timer to postpone the release of the last N_GCH_FAST_PS_ACCESS

“unused” GCHs in a cell, when the last TBF has been released in the cell (launched after

T_GCH_Inactivity).




6.7 ATER CONGESTION

The Ater congestion or in “high load” situation may impact the end-user performance. The GCHs in deficit

will in first step decrease the TBF throughput and in a second step it may originate TBF establishment

failure.

This degradation can be observed and analyzed by RNO indicators.

At Ater/GPU level:

o GPRS_GPU_Ater_cong_time - Time during which AterMux interface (GICs) for this GPU is congested

(at least one PDCH group impacted). By congestion, in this case is defined as the time during which

the number of used AterMux nibbles is greater than (available Atermux nibbles -

N_ATER_TS_MARGIN_GPU).


ED 1 RELEASED 011




itted without


o GPRS_GPU_Ater_cong_percent - Percentage of time during which AterMux interface (GICs) for this

GPU is congested (at least one PDCH group impacted).

o GPRS_transmission_GCH_deficit_ater_nibbles_time - Cumulated time during which there are Ater

nibbles in deficit in the GPU.

o GPRS_transmission_GCH_deficit_ater_nibbles_average - Average number of Ater nibbles which are

in deficit in the GPU.

At DSP level:

o GPRS_DSP_CPU_overload_time - Time during which at least a DSP is in CPU overload state. A DSP is

said overloaded when its CPU load is > =DSP_LOAD_THR2.

o GPRS_DSP_CPU_overload_percent - Percentage of time during which a DSP is in CPU overload state.

o GPRS_GPU_DSP_cong_time - Time during which a DSP enters the congestion state.

o GPRS_GPU_DSP_cong_percent - Percentage of time during which a DSP enters the congestion state.

At transmission (Abis/Ater) level:

o GPRS_transmission_GCH_deficit_time - Cumulated time during which there is a deficit of GCH

resources in the cell.

o GPRS_transmission_GCH_deficit_average - Average number of GCH resources in deficit in the cell.

In a critical situation the impact of the Ater/GPU(GP)/DSP congestion should be observed in the TBF

establishment indicators:

o For DL:

• GPRS_DL_TBF_estab_fail_ater_cong - Number of DL establishment failures due to

congestion of Ater(Mux).

• GPRS_DL_TBF_estab_fail_cpu_cong - Number of DL establishment failures due to CPU

processing power limitations of the GPU.

• GPRS_DL_TBF_estab_fail_dsp_cong - Number of DL establishment failures due to congestion

of DSP.

o For UL:

• GPRS_UL_TBF_estab_fail_ater_cong - Number of DL establishment failures due to

congestion of Ater(Mux).

• GPRS_UL_TBF_estab_fail_cpu_cong - Number of DL establishment failures due to CPU

processing power limitations of the GPU.

• GPRS_UL_TBF_estab_fail_dsp_cong - Number of DL establishment failures due to congestion

of DSP.

If relevant congestion is found in the previous indicators a set of NE recommendation are proposed. In a

first phase, e.g. the congestion is relevant but not critical a few parameter optimizations are proposed,

otherwise a new dimensioning is needed.

The Ater parameter optimizations recommended are:

o N_ATER_TS_MARGIN_GPU - Number of free 64k Ater TSs that are kept “in reserve” in order to be

able to serve some priority requests (first PS traffic) in the cells of the GPU.

• Changeable by operator at BSS level - Min = 0 TS, Def = 2 TS, Max = 10 TS.

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

• Parameter impact:

� Increasing the value of this parameter can increase the average number of unused

Ater nibbles in the GPU (only first PS accesses will benefit from the margin, not the

on-going TBF traffic). Remark: if the value is increased there will be more

GPRS_GPU_Ater_Cong_Time, due to the definition of GPRS_GPU_Ater_Cong_Time.

� But on the other hand, a high value will increase the probability of not serving

priority requests in the GPU (cases where several priority requests have to be

served in a short period of time in different cells).

� Setting N_ATER_TS_MARGIN_GPU to 0 can lead to situations where priority requests

cannot be served at all.


� The parameter value should be kept at least equal to 2 TS

o Ater_Usage_Threshold - Threshold (percentage of used Ater nibbles, in a GPU) above which the Ater

usage is said “high”.

• Changeable by operator at BSS level - Min = 1%, Def = 70%, Max = 100%.


� Decrease the threshold for a more reactive algorithm in case of critical situations.

� Available atermux nibbles - (Available Atermux nibbles * Ater_Usage_Threshold) >

N_ATER_TS_MARGIN_GPU in order to enter in "high load" condition before entering

in congestion.

o GCH_RED_FACTOR_HIGH_ATER_USAGE - Reduction factor of the number of GCHs targeted per PDCH,

when the Ater usage is “high”.

• Changeable by operator at cell level - Min = 0.1, Def = 0.75, Max = 1.


� A low value of GCH_RED_Factor_High_Ater_Usage can be coherent with a high value

of Ater_Usage_Threshold (it will avoid reaching the saturation point of 100% of the

Ater resources used at the same moment in the GPU).

� Reciprocally, a high value of GCH_RED_Factor_High_Ater_Usage can be coherent

with a low value of Ater_Usage_Threshold (it will limit the risks of wasting, i.e. of

not using, Ater resources in the GPU).


� In critical situations where the transmission resources are always congested,

decrease the value to reduce the impact of congestion and save resources for new

PS access.

The global transmission parameter optimizations are:

o T_GCH_Inactivity - Timer to postpone the release of the “unused” GCHs of a TRX after TBF

release(s).



� The lower, the faster Ater nibbles are freed when unused (Ater congestion is

reduced).


ED 1 RELEASED 011




itted without


� A too low timer value will increase GSL/CPU loads due to numerous GCH releases &

reestablishments. It may also not anticipate traffic resumption on TRXs in an

optimal way (only MSC2 usable at TBF resumption).



o T_GCH_Inactivity_Last - Timer to postpone the release of the last N_GCH_FAST_PS_ACCESS

“unused” GCHs in a cell, when the last TBF has been released in the cell (launched after

T_GCH_Inactivity).



� The lower the T_GCH_Inactivity_Last vaule will be, the faster Ater nibbles are freed

when unused (Ater congestion is reduced). A too low timer value will however

poorly anticipate traffic resumption on TRXs (higher average duration of TBF

establishments) and increase GSL/CPU loads due to numerous GCH releases &

reestablishments.



o “Fast initial PS access” feature.

• EN_FAST_INITIAL_GPRS_ACCESS: Changeable by operator at cell level – Def = off.

• N_GCH_FAST_PS_ACCESS: Customizable at MFS level – Min = Def = 1 GCH, Max = 5 GCHs.


� No "fast initial PS access" avoids Ater resource consumption and wastes.

� But "fast initial PS access" guarantees PS traffic in all the cells in which it is

activated (at radio & Abis/Ater levels).

6.8 GSS OPTIMISATION FOR GMM/SM SIGNALLING

From the activation of the PS in a network, the GMM/SM signalling traffic has a high weight in the radio and

transmission resources load. Several optimisations at GSS level are possible, their aim is to reduce both the

RAU and the GPRS Attach procedure.

a) Optimisation by the procedure Suspend/Resume:

The procedure suspend/resume should be activated at BSS (it is activated in default) and at GSS level in

order to avoid that mobiles trigger a RA update procedure at the end of each CS connections, in order to

warn SGSN that they are re-available for PS services.

With Suspend/Resume, this is done directly by the BSS at the end of each CS connections.

b) Optimisation of the procedure GPRS attach:

GPRS attach on demand:

2 modes of Attach at GSS level are possible:

- attach sent at "switch on" of the mobile

- attach "on demand" when the user wants to activate a PDP context

ED 1 RELEASED 011


3DF 0

1900 0000 PTZZA – D

IAMS

All rig

hts re

served. P

assin


is document,


n of its c

ontents n

ot p

erm

itted with

out

writte

n authoriz

atio

n fro

m Alcatel-L

ucent.

It is preferable to "force" the configuration of the mobiles towards the second mode in order to avoid all

the GPRS attach procedure not useful as they are not followed by user traffic.

GPRS attach repetitions:

A strong number of GPRS attach can be followed by GPRS attach reject because they are generated by users

having GPRS mobiles but no GPRS subscription. The failure cause "GPRS service not allowed" sent by the GSS

in the GPRS attach reject message should prevent from repeating GPRS attach attempts in such case.

c) Optimisation of the procedure RA update:

The timer T3312 within SGSN manages the periodicity of the sending of RA update request.

In order to avoid a too strong load coming from this procedure, it is preferable to increase the value of this

timer. However, no value can be recommended as it can depend on the GSS vendor implementation.

It has been seen in several networks that this values is set to 54 min, although this value can be increase up

to 3 hours, reducing number of periodic RAU.


ED 1 RELEASED 011




itted without


A TABLE OF FIGURES

Figure 2–1: B8 release EGCH vs B9 release M-EGCH........................................................................................ 8 Figure 2–2: M-EGCH and L1-GCH layers location ............................................................................................ 9 Figure 2–3: GCH filling with RLC/MAC PDUs ................................................................................................... 9 Figure 2–4: Abis resources concept in B8...................................................................................................... 11 Figure 2–5: Abis resources concept in B9...................................................................................................... 11 Figure 2–6: Cyclic calculation of the usage of the cell resources ................................................................. 14 Figure 2–7: Cyclic calculation of the average usage of the cell resources .................................................... 15 Figure 2–8: General diagram of the Max_SPDCH_Limit calculation............................................................... 15 Figure 2–9: Detailed diagram of the Max_SPDCH_Limit calculation .............................................................. 17 Figure 2–10: Max_SPDCH_Limit CS and PS zones .......................................................................................... 18 Figure 2–11: PS TS zones – example 1........................................................................................................... 19 Figure 2–12: PS TS zones – example 2........................................................................................................... 19 Figure 2–13: T1 reallocation......................................................................................................................... 21 Figure 2–14: Handling of unused GCHs ......................................................................................................... 25 Figure 2–15: RAE4 diagram........................................................................................................................... 27 Figure 2–16: T3 reallocation - initial MSs allocation. .................................................................................... 33 Figure 2–17: T3 reallocation - final MSs allocation for B9............................................................................. 33 Figure 2–18: T3 reallocation - defragmentation purpose.............................................................................. 34 Figure 2–19: Coding scheme families. .......................................................................................................... 36 Figure 2–20: Trigger of the timer T_max_extended_UL................................................................................ 38 Figure 2–21: Schedule USF............................................................................................................................ 38 Figure 2–22: Expiry of the timer T_max_extended_UL. ................................................................................ 38 Figure 2–23: Restart the uplink TBF. ............................................................................................................. 39 Figure 2–24: NACC. ...................................................................................................................................... 40 Figure 2–25: NACC procedure in NC0 mode.................................................................................................. 40 Figure 2–26: NACC procedure in NC2 mode.................................................................................................. 41 Figure 2–27: Packet (P)SI status. .................................................................................................................. 42 Figure 2–28: Packet SI Status procedure. ..................................................................................................... 42 Figure 2–29: Packet PSI Status procedure. ................................................................................................... 43 Figure 2–30: PS used bandwidth................................................................................................................... 45 Figure 2–31: NC2 cell ranking process – case 1............................................................................................. 45 Figure 2–32: NC2 cell ranking process – case 2............................................................................................. 46 Figure 2–33: DL LLC PDU rerouting feature process. .................................................................................... 46 Figure 3–1: BSS Architecture in B9 release. .................................................................................................. 54 Figure 3–2: BSS Architecture in B9 release with Mx platform. ...................................................................... 54 Figure 3–3: Calculation of the Number of Extra Abis TS. .............................................................................. 56 Figure 3–4: Calculation of the needed GCHs in the Atermux interface......................................................... 57 Figure 3–5: Calculation of the Required_GCH_Traffic by Method 1. ............................................................. 58 Figure 3–6: Measured GCH traffic vs Measured PDCH traffic. ....................................................................... 58 Figure 3–7: Calculation of the Required_GCH_Traffic by Method 2. ............................................................. 59 Figure 3–8: Increase factor........................................................................................................................... 60 Figure 3–9: Transition type........................................................................................................................... 60 Figure 3–10: Method 2 – increase_factor ...................................................................................................... 61 Figure 6–1: Network Architecture. ............................................................................................................... 81 Figure 6–2: Ethereal example - MSS. ............................................................................................................ 82 Figure 6–3: Ethereal example - RWIN. .......................................................................................................... 83 Figure 6–4: Dr. TCP example – TCP parameters ............................................................................................ 83 Figure 6–5: Ethereal example – Time/Sequence graphic 1............................................................................ 84 Figure 6–6: Ethereal example – Time/Sequence graphic 2............................................................................ 84 Figure 6–7: Ethereal example – Time/Sequence graphic 3............................................................................ 85 Figure 6–8: Ethereal example – Time/Sequence graphic 4............................................................................ 85 Figure 6–9: Radio Block structure................................................................................................................. 89 Figure 6–10: RLC block not well decoded ..................................................................................................... 89

END OF DOCUMENT