resources allocat

8/3/2019 Resources Allocat

1/39

RESOURCE ALLOCATION

DIFFUSIONFRANCE TELECOM

MOTOROLA

Authors : Reviewed by : Responsible :

Version 1.0


2/39

Resource Allocation V1.0

Motorola Confidential Proprietary Page 2/39 07/11/2011 2

1 INTRODUCTION .......................................................................................................... 4

1.1 SCOPE OF THE DOCUMENT ......................................................................................... 4

1.2 GSMMESSAGES FOR SUCCESSFUL ESTABLISHMENTS ............................................... 5

2 FEATURES .................................................................................................................... 6

2.1 INTERFERENCE BANDS................................................................................................ 6

2.1.1 Description ......................................................................................................... 6

2.1.2 Database Configuration ..................................................................................... 62.1.2.1 interfer_bands parameter .......................................................................................................................... 6

2.1.2.2 Intave parameter ......................................................................................................................................... 6

2.1.3 Database Timers ................................................................................................. 72.1.3.1 rf_res_ind_period timer ............................................................................................................................ 7

2.2 SDCCH AND TCHALLOCATION BASED ON BASED ON CHANNEL PRIORITY .............. 8

2.2.1 Description ......................................................................................................... 8

2.2.2 Database Configuration, .................................................................................... 8

2.2.2.1 chan_alloc_priority parameter .................................................................................................................. 8

2.3 EXPLICIT SDCCHASSIGNMENT ................................................................................ 9

2.3.1 Description ......................................................................................................... 9

2.3.2 Database Configuration ..................................................................................... 92.3.2.1 sd_load parameter ...................................................................................................................................... 9

2.3.2.2 sd_priority parameter ................................................................................................................................ 9

2.3.3 Implementation of Improved SDCCH and TCH control .................................. 10

2.4 SDCCH AND TCHCHANNEL RECONFIGURATION ................................................... 11

2.4.1 Description ....................................................................................................... 11

2.4.2 Database Configuration ................................................................................... 112.4.2.1 channel_reconfiguration_switchparameter .......................................................................................... 11

2.4.2.2 number_sdcchs_preferredparameter .................................................................................................... 11

2.4.2.3 sdcch_need_low_water_markparameter............................................................................................... 122.4.2.4 sdcch_need_high_water_mark parameter ............................................................................................. 122.4.2.5 tch_full_need_low_water_markparameter ........................................................................................... 12

2.4.2.6 max_number_of_sdcch parameter .......................................................................................................... 12

2.4.3 Implementation of Channel Reconfiguration ................................................... 13

2.4.4 Example ............................................................................................................ 14

2.5 CALL QUEUING ........................................................................................................ 15

2.5.1 Description ....................................................................................................... 15

2.5.2 Database Configuration ................................................................................... 152.5.2.1 queue_management_information parameter ....................................................................................... 15

2.5.2.2 max_q_length_full_rate_chan parameter .............................................................................................. 16

2.5.2.3 max_q_length_sdcch parameter .............................................................................................................. 16

2.5.3 Database Timer ................................................................................................ 162.6 DIRECTED RETRY ..................................................................................................... 17

2.6.1 Description ....................................................................................................... 17

2.6.2 Database Configuration ................................................................................... 182.6.2.1 dr_preference parameter .......................................................................................................................... 18

2.6.2.2 dr_standard_congest parameter.............................................................................................................. 18

2.6.2.3 dr_ho_during_assign parameter ............................................................................................................. 18

2.6.2.4 dr_chan_mode_modify parameter .......................................................................................................... 18

2.6.2.5 dr_allowed parameter ............................................................................................................................... 18

2.6.2.6 congest_ho_margin parameter ................................................................................................................ 18

2.7 CONGESTION RELIEF AND CONGESTION RELIEF ENHANCED .................................... 19

2.7.1 Description ....................................................................................................... 192.7.1.1 Congestion Relief ...................................................................................................................................... 19

2.7.1.2 Enhanced Congestion Relief ..................................................................................................................... 202.7.2 Database Configuration ................................................................................... 20


3/39



2.7.2.1 HO_exist_congest parameter ................................................................................................................... 20

2.7.2.2 Congest_HO_Margin parameter ............................................................................................................. 20

2.7.2.3 tch_congest_prevent_thres parameter................................................................................................... 21

2.7.2.4 congest_at_source parameter................................................................................................................... 21

2.7.2.5 congest_at_target parameter ................................................................................................................... 21

2.7.2.6 mb_tch_congest_thres parameter ........................................................................................................... 21

2.7.3 Database Timer ................................................................................................ 212.7.3.1 valid_candidate_ period timer ................................................................................................................ 21

2.7.3.2 ext_rtry_cand_prd timer ......................................................................................................................... 22

2.7.3.3 rtry_cand_prd timer ............................................................................................................................... 22

2.8 FLOW CONTROL ....................................................................................................... 23

2.8.1 RACH flow control Description ....................................................................... 23

2.8.2 Database Configuration ................................................................................... 242.8.2.1 TCH Flow Control Parameters ................................................................................................................ 242.8.2.2 RACCH Flow Control Parameters .......................................................................................................... 24

2.8.2.3 SSM Flow Control Parameters ................................................................................................................ 25

2.9 MULTIBAND ENVIRONMENT ..................................................................................... 26

2.9.1 Description ....................................................................................................... 26

2.9.2 Database Parameters ....................................................................................... 26

3 COMPATIBILITY AND DEPENDENCY OF THE RESOURCE ALLOCATION

FEATURES ......................................................................................................................... 28

3.1 INTERFERENCE BAND AND IMPROVED SDCCH/TCH CONTROL............................... 28

3.2 DIRECTED RETRY AND CONGESTION RELIEF............................................................ 28

3.3 DIRECTED RETRY/(ENHANCED )CONGESTION RELIEF AND TCHFLOW CONTROL... 30

3.4 DIRECTED RETRY/(ENHANCED)CONGESTION RELIEF AND QUEUING..................... 30

ANNEXE 1:STATISTICS RELATIVE TO THE RESOURCE ALLOCATION................................... 31Idle interference monitoring ........................................................................................................................................ 31

Channel establishment ................................................................................................................................................. 31TCH assignment .......................................................................................................................................................... 32

Band re-assignment ..................................................................................................................................................... 34

ANNEXE 2:EXTRA PARAMETERS AND TIMERS RELATIVE TO THE CHANNEL ALLOCATION35ANNEXE 3:GPRSFEATURE AND RESOURCE ALLOCATION ................................................. 37

CONFIGURATION OF PDCH ................................................................................................ 37

ALLOCATION OF RESOURCES ON THE AIR INTERFACE ......................................................... 38

RESOURCE MAPPING BETWEEN BSC AND PCU .................................................................. 38


4/39



1Introduction1.1 Scope of the DocumentThe purpose of this document is to present the different Motorola features on the

SDCCH/TCH resource allocation gathered in one document.

Motorola proposed a wide range of processes involved in the resource allocation as

follows:

- The Interference Bands

- Improved SDCCH and TCH control feature split into- SDCCH and TCH allocation based on channel priority

- Explicit SDCCH assignment- SDCCH/TCH Reconfiguration

- Queue Management- Directed Retry- Congestion Relief and the GSR4 Enhanced Congestion Relief- SDCCH/TCH management in a Multiband Environment.

The first two features concerned the choice of the channel to be used for the resource. The

next four manage the availability of resource regarding to the demand. The last concerns

the particular management of resources for a multiband network.

This document will focus on these functionalities in relation to resource allocation,

especially for the vast feature of enhanced congestion relief. It will also discuss their

implementation in a network for certain features.

This document also presents the compatibility and interdependency of the different

features, how they work together, and their relative priorities.

In the annexe 2, Motorola answers some questions about its procedures of resources

allocation concerning the GPRS.


5/39



1.2 GSM Messages for Successful EstablishmentsThe diagram below resumes the main messages during a successful call. In Annexe 1 is

presented the major statistics relative to SDCCH/TCH allocation.

Figure 1: main GSM Messages involved in Successful Assignment.

MS BSSMSC

Channel Request

(RACH)

Immediate assignment

(AGCH)

SABM + Initial Layer

3 Message (SDCCH)

SDCCH signalling transaction :Authentification and Ciphering

Assignment Request

Assignment Command

(SDCCH)

Assignment Complete

(TCH)

Assignment Complete


6/39



2Features2.1 Interference bands2.1.1 Description

As described in GSM 08.08 the available channels (timeslots) should be divided into five

interference categories whose limits O-X5 are adjusted by O&M command.

They describe the level of potential uplink interference. For hand over and call set up the

allocation of channels should be from the category with the lowest interference level.

The TCU switches on in uplink frame of every idle slot and measures ambient noise (104

times per sacch frame), 104 measurements are averaged to produce one figure; they are

further processed by the HDPC on a per slot basis.

Each sacch frame period will result in a computed average by idle slot. The HDPC

periodically updates the CRM (Cell Resource Manager).

2.1.2 Database Configuration

2.1.2.1 interfer_bands parameter

This parameter sets the limits for the interference categories (bands) whose limit 0 to X5

shall be adjusted by Operations and Maintenance (O & M). The bands are:

Band 1 0 to X1

Band 2 X1 to X2

Band 3 X2 to X3

Band 4 X3 to X4

Band 5 X4 to X5

The BSS averages the interference level in unallocated timeslots as defined by the intave

parameter. The averaged results are then mapped into five interference categories whose

limits are adjusted.

Interfer_band, 0 corresponds to Band 1, (from 0 to (110+X1)dBm) and Interfer_band,1

to Band 2 etc

The values are ranged between 0 (represents 110 dBm) and 63 (represents 47dBm).

Default Value: 63 (corresponds to disable the feature)

2.1.2.2 Intave parameter

This parameter is used to change the algorithm data needed for performing interference

band averaging and classification during idle channel interference processing.

The value represents the number of sacch period needed for the interference band

averaging, (a step = 2 sacch multiframes).

Valid Range: 0 to 31 Default Value: 8


7/39



2.1.3 Database Timers

2.1.3.1 rf_res_ind_period timer

This parameter sets the RF resource indication period to indicate the interval over which

the idle channel will be categorized (idle channel categories: X1, X2, X3, X4 and X5) The

idle channel categories will be reported to the CRM by the RSS.

(1 step =1 SACCH multiframe).



8/39



2.2 SDCCH and TCH Allocation based on based on Channel PriorityThis is the first part feature of the Improved SDCCH and TCH control feature.

2.2.1 Description

This feature implements a radio channel (SDCCH/TCH) allocation algorithm based on the

operator assigned per-carrier priority.

2.2.2 Database Configuration,

2.2.2.1 chan_alloc_priority parameter

It is used to specify the priority of a carrier when utilising the radio channel (SDCCH/TCH)

allocation algorithm.

The value of this parameter concerns a particular RTF.


The chan_alloc_priority element specifies the carrier order from which TCHs are

allocated. This ordering is followed for all requests in a particular carrier group, be it a

request for assignment or handover.

These feature is considered when allocating TCHs for normal calls, PGSM->DCS1800

Multiband reassignments, DCS1800->PGSM Multiband handovers.

It must be noted that the interference bands are considered BEFORE any carrier priority,

i.e. the BSS channel allocation will always consider uplink interference first (see chapter

3.1).


9/39



2.3 Explicit SDCCH AssignmentThis is the second part of the Improved SDCCH and TCH Control feature.

Prior to the availability of this feature, the SDCCH are distributed equally across all

carriers, on the same TS of each carrier depending on the number of FU installed.

2.3.1 Description

During initial configuration, SDCCHs are placed on the highest priority carriers first. Once

the SDCCH assignment on these carriers has been maximised, the next highest priority

carriers are used. After initial configuration, if a carrier is brought back into service with a

different SDCCH priority or with a different SDCCH load, SDCCHs are distributed

(moved) so that they are always on the highest priority carriers.

If Dynamic Channel Reconfiguration, (that is Traffic Channels to SDCCHs or SDCCHs toTraffic Channels) is in operation, then the following is undertaken:

TCH/F to SDCCH configuration is performed on a TCH/F which is on the highestpriority carrier.

SDCCH to TCH/F configuration is performed on an SDCCH/8 which is on thelowest priority carrier


2.3.2.1 sd_load parameter

It is a per RTF element, is used to specify the maximum number of SDCCH/8 timeslots

configurable per carrier.

Valid Range: 0 to 2

2.3.2.2 sd_priority parameter

The per RTF element sd_priority specifies the priority of the SDCCH channels. They will

be placed on the carriers with the highest SDCCH placement priority.

When carriers are taken in or out of service the SDCCHs will always migrate to the

carrier(s) with the highest priority.

When multiple carriers have the same sd_priority, then the SDCCH channels will be

distributed evenly throughout the carriers.

Valid Range: 0 to 250 Default Value : 0 non-BCCH,

0 BCCH


10/39



2.3.3 Implementation of Improved SDCCH and TCH control

This combined feature provides the operator with the flexibility of prioritising the selection

of Traffic Channels (TCHs) and Standalone Dedicated Control Channels (SDCCHs) in

order to minimise the overall interference level in a GSM network.

With Frequency Hopping SFH

The typical application for these features is synthesised frequency hopping (SFH). In the

case of a network using SFH, a lot of attention is paid to obtaining a clean BCCH

frequency plan. The BCCH frequencies do not hop and the Power Control is not enabled.

Accordingly the BCCH carriers are given 0 priority (highest) to carry SDCCH and TCH

channels first; all the other hopping carriers are given lower priority. (For instance all the

same since they will have the same hopping frequency).

Without Frequency Hopping

This combined feature can be used for single cell improvements by giving highest priorityto the carrier with the best frequency (after analysing CTP results).

Individual cell wise setting of these features involves tracking every change in the

frequency plan, and an extra load of maintenance work. It could be used and maintained as

a temporary workaround until a frequency change is implemented.

=> The two features of channel allocation priority and explicit SDCCH assignment have

been used already and implemented with SFH (or without) successfully in different

networks.


11/39



2.4 SDCCH and TCH Channel ReconfigurationThis feature allows in a certain limit, the dynamic reconfiguration of the number of

available time slots to support 8 SDCCH or 1 TCH as the current demand of the resource

SDCCH requires.

2.4.1 Description

On initialisation, the Cell Resource Manager (CRM) ensures that each air interface timeslot

is configured in accordance with fields set in the database.

Once the BSS is call processing, the CRM is capable of dynamic channel reconfiguration,

that is, the CRM is capable of changing the mix of channel configuration. If a high

proportion of SDCCHs is in use and more SDCCH requests are received, the CRM is able

to reconfigure a TCH timeslot into SDCCHs.

For example, if timeslot 0 (TS0) is configured as ccch_conf=1, then four SDCCHs are

allocated, and for this configuration the number of SDCCH may be 4,12,20, et(4+8n)otherwise the number of SDCCH may go from 8,16,to 8n.

Conditions for TCH to SDCCH reconfiguration to occur:

Number of SDCCHs after reconfiguration must not exceedmax_number_of_sdcch.

Idle number of free SDCCHs must be lower than sdcch_need_high_water_mark.

Current number of idle TCHs must be greater thantch_full_need_low_water_mark.

Conditions for SDCCH to TCH reconfiguration to occur: Total number of SDCCHs after the reconfiguration must not be lower than

number_sdcch_preferred.

Present number of free SDCCHs must be greater thansdcch_need_low_water_mark.


All the feature are configured on a per cell basis.

2.4.2.1 channel_reconfiguration_switch parameterPermits dynamic channel reconfiguration (reassignment) of traffic channels to SDCCHs.

Set to 1 to enable it, or to 0 to disable it

Valid Range: 0 and 1 Default Value: 0

2.4.2.2 number_sdcchs_preferred parameterDefines the preferred number of SDCCHs that the channel reconfiguration algorithm tries

to maintain. The number of SDCCHs will never fall below this value. If set to a high value

the dynamic reconfiguration will never takes place.

Valid Range: 4 to 44 (combined) Default Value: 0

8 to 48 (ifccch_conf= 1)


12/39



2.4.2.3 sdcch_need_low_water_mark parameterSets the number of idle SDCCHs that trigger reconfiguration back to TCHs from SDCCHs.

A dependency written in this feature is:

sdcch_need_low_water_mark >= number_sdcch_preferred


2.4.2.4 sdcch_need_high_water_mark parameterSets the number of idle SDCCHs that trigger reconfiguration to SDCCHs.


If =1 means wait that there is no sdcch available

2.4.2.5 tch_full_need_low_water_mark parameterSets the low need threshold to determine the need for full rate traffic channel

reconfiguration to SDCCHs.


2.4.2.6 max_number_of_sdcch parameterSets the number of SDCCHs after reconfiguration. Currently, this is limited by the number

of carriers * 2 * 8 (because the maximum number of SDCCH timeslot is 2 per carrier) and

for a BCCH-SDCCH/4, the limitation is 20 + 2 *8. Ifccch_conf = 1, the value must be a

multiple of 8, with an offset of 4 (0,4, ..44), otherwise there is no offset to take into

account.



13/39



2.4.3 Implementation of Channel Reconfiguration

Interest

It is primarily meant for acquiring SDCCH resources during the operation of the systemwhen needed. There can be instances in the system when there is a high need of SDCCHs

and there are not enough SDCCHs present in the system to satisfy this need. This could

happen in certain geographical areas where the demand of signalisation is high (border of

LAC) or when a large number of people come out of the airport or a cinema and everybody

turns their mobile on, for handling the location updates. Some of these people might

continue to make calls. At this point there might be enough TCH resources to satisfy the

calls, but not enough SDCCH resources to satisfy the signalling channel requirements. If

enabled, Dynamic Reconfiguration kicks in and reconfigures unneeded TCH resources to

SDCCHs. Later on when this high need abates the dynamic reconfiguration procedure

reconfigures the extra SDCCH resources back to the TCHs.

It may be useful to activate it not necessary network wise but for some specific andparticular cells.

Parameter Setting up and tests

To avoid a disturbing occurance of channel reconfiguration, the difference between

sdcch_need_high_water_mark and sdcch_need_low_water_mark must be greater or

equal to 9. See BSS command reference release 3, chap 5-315 and chap 5-316.

It is recommended to forecast a minimum and sufficient dimensioning in SDCCH resources

regarding to the number of TRXs. The dynamic channel reconfiguration should take place

during the peak time of SDCCH resource and must not be dramatic (for instance for a 3

TRX cell to set the number_of _sdcch_prefered to 8 and to allow SDCCH to climb up to

28). The implementation of these recommendations has been tested in real life network

(GSR3 equipment and soft) and it has been noticed the improvement of network

performance indicators concerning SDCCH (as the decrease of the sdcch_congestion,

immediate_assignement_success) without degrading the TCH performance indicators.

It must be noticed that this feature has no impact with frequency hopping; both may work

together.


14/39



2.4.4 Example

Let assume that the value of the different parameters are:

channel_reconfiguration_switch = 1

max_number_of_sdcch = 24 one more TRX can be configured

number_sddchs_preferred = 16sdcch_need_high_water_mark = 2 tch to sddch if only 1 sdcch remaining

sdcch_ need_low_water_mark = 18

tch_full_need__low_water_mark (doesnt appear in this example)

In step 1) only two channels are reserved for SDCCH, (the configuration with the minimum

number of SDCCH s). In step 2), 15 channels are used as SDCCH channels, which is over

the High Water Mark in SDCCH. This situation triggers an alarm to reconfigure

dynamically an available timeslot into 8 SDCCHs, (step 3) the configuration with the

maximum number of SDCCHs dedicated). As long as there are more than 6 (24-18)

SDCCH s in use, the configuration remains the configuration shown on step 3). Otherwise,

in step 4) the low load of SDCCHs reconfigure the distribution of SDCCH,TCH back tostep1).

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24BACK to the same configuration as in the case 1)

SDCCHs in use

MAX=24

SDDCH PREFERED = 16

MAX=24

LWM = 18 HWM = 2

4)Too

Low avalaible SDCCHs before reconfiguration - from 4) to 1) -

MAX=24

LWM = 18 HWM = 2

3) avalaible SDCCHs after

reconfiguration -from 2) to 3)-

HWM = 2

2) SDCCH

neededTCH before reconfiguration

1)TCH before reconfiguration

MAX=24

Time Slot = 8 SDCCH Time Slot = 8 SDCCH or 1 TCH Time Slot = 8 SDCCH or 1 TCH

HWM = 2


15/39



2.5 Call QueuingIt must be noted that the feature Call Queuing embraces not only TCH queue management

but also the control of the queuing for SDCCH handover requests from the MSC.

Channel requests cannot be queued: a SDCCH is either available or not available.However, MSC originating SDCCH handover requests, although not common, can be

queued. The parameter max_q_length_sdcch controls the length of that queue.

Furthermore, SDCCH queuing may cause possible delays in attempting SDCCH to

SDCCH handovers. This section will focus ONLY on the TCH queue management. This

feature is known as well as the call queuing priority without pre_emption".

2.5.1 Description

An MS (Mobile System) requests radio resources via the Random Access Channel (RACH)by sending an access burst containing a channel request message. Assuming resources are

available, the MS is assigned one of a number of Standalone Dedicated Control Channels

(SDCCHs) where the remainder of call set-up procedures take place prior to being allocated

a traffic channel (TCH).

It may occur that that once the MS has finished on the SDCCH there may not be a TCH

available at that particular moment. The system is able to place the MS in a queue along

with other MSs awaiting assignment of a TCH. Only ASSIGNMENT REQUESTs and HO

REQUESTs received from the MSC can be queued. Intra BSS HOs are not queued.

The length of the queue is dependent upon the value set in the

queue_management_information field of the BSS database. The range of this field

represents the arithmetic sum of the number of mobiles that can wait in a queue for theassignment of a TCH. A mobile could obviously not wait for an indefinite time in this

queue, bssmap_t11 controls the maximum time the MS waits in the queue before the

request is dropped.

Calls arriving, when all positions in the queue are occupied are cleared by the network,

indicating that no circuits/channels are available.


2.5.2.1 queue_management_information parameterDisplays the number of subscribers that may wait in a queue for channel assignment.

A value of 0 must be entered if queuing is not permitted.

queue_management_information >= max_q _length_full_rate_chan

+ max_q_length_sdcch



16/39



2.5.2.2 max_q_length_full_rate_chan parameterSets the maximum number of MSs that may wait in a queue for a full rate channel

assignment.

The TCH queuing parameters are used by the Cell Resource Manager (CRM), and must be

aligned to the value entered in the MSCValid Range: 0 to 50 Default Value: 0

2.5.2.3 max_q_length_sdcch parameterSets the maximum length of the queue for SDCCH requests

Valid Range: 0 to 50 Default Value: None

2.5.3 Database TimerBssmap_t11 (see annexe 2)


17/39



2.6 Directed RetryThe feature is meant to improve the accessibility of the network and prevent blocked calls.

2.6.1 Description

Directed retry is an optional feature which re-directs new traffic when a Cell is congested

resulting in the new call to be moved to the next most suitable Cell. It allows for the

handover of a Mobile Station (MS) from an SDCCH of one Cell directly to a traffic

channel (TCH) of another Cell.

Figure 2: Directed Retry procedure applied when original Cell congested

The Directed Retry algorithm will be activated only during call set up, when a mobile is

already on SDCCH, requires a TCH and all TCH on the cell are busy.

The mobile is then put on the TCH queue.

-If TCH is getting available on the cell by the end of the DR process, then the DR

process is aborted and is allocated the TCH available.

-Otherwise, the mobile will be move onto a TCH of a neighbour cell, for which the

2 criteria about handover on congestion (see the next feature Directed Retry Alternative)are valid.

1. Rxlev (neighbour X) > rxlev_min_ncell

rxlev_min_ncell is defined in the Data Base for this neighbour X.

2. PBGT (neighbour X) - congest_ho_margin > 0

If all attempts at directed retry fail or no valid neighbour are reported then the TCH request

remains queued for the remainder of the relevant queuing timer (bssmap_t11).


18/39




2.6.2.1 dr_preference parameterThis parameter determines whether the directed retry procedures are disabled or enabled.

This action of this parameter concerns a BSS.

Valid Range: 0 (disabled), 1 (enabled) Default Value: 0

2.6.2.2 dr_standard_congest parameterThis parameter determines if the standard directed retry congestion procedure is enabled in

the cell. The procedure initiates a handover if possible for a call needing a TCH in the case

of congestion.


2.6.2.3 dr_ho_during_assign parameter

This parameter determines if a handover will be handled during an assignment procedure(set to 1) or whether the HO will occur at the end of the assignment procedure.

This refers to the need for a HO due to Radio Frequency reasons when a call is being

queued. If the call is queued and RF conditions change such that a normal HO is required

e.g. better cell or RxQual or RxLev then a HO is carried out.

This parameter concerns the cell where DR is activated.


2.6.2.4 dr_chan_mode_modify parameterThis parameter determines if the channel mode modify procedure will follow a successful

handover of a Phase 1 MS in which the channel mode changed to full rate speech.

This action of this parameter concerns a BSS.


2.6.2.5 dr_allowed parameterThis parameter enables the Directed Retry option, if set to 1, otherwise set to 0.

This is a per neighbour attribute for external neighbours only.


2.6.2.6 congest_ho_margin parameterThis per neighbour parameter is used in the case of a congestion handover. To make iteasier to handover to this neighbour in the case of congestion in the current cell, this

parameter value should be less that the value of the handover margin(s)

To disable congestion handovers to this neighbour, set the congestion handover margin to

the maximum value +63.

In addition as the congest_ho_margin is usually set to negative values or 0 to facilitate DR

handovers to neighbours with free resources. A positive congest_ho_margin would mean

that the chances of finding a suitable neighbour would be minimal and the congestion

situation on the serving cell couldn't be resolved effectively.

congest_ho_margin is a per neighbour parameter.

Valid Range: 63dB to 63dB Default Value: None


19/39



2.7 Congestion Relief and Congestion Relief EnhancedThey are two different types of Congestion relief. The standard one called Congestion relief

(which is called sometime Directed Retry Alternative) and the latest one available from

GSR4, the Enhanced Congestion Relief. The section will give only an overview of these

features.

2.7.1 Description

2.7.1.1 Congestion Relief

Congestion relief is an optional feature which is available as an alternative to Directed

retry for the case of a congested cell. This feature differs in that it chooses the best

candidate from all existing calls in the cell to be moved to the alternate cell thus freeing

TCHs in the congested cell. This can result in better overall system quality compared to

Directed retry because the best handover candidate is chosen instead of the candidate

requesting a TCH.

Figure 3: Alternative congestion relief procedure applied when original Cell congested

If a call (MSa on the figure) needing a TCH has not had the chance to report a neighbour

that is a good handover candidate, it may be better to handover an established call (MSb onthe figure). This frees up TCHs in the congested cell (cell 1 on the figure). The maximum

number of calls handed over can be either of the following:

The number of queued requests in the congested cell.

The number of calls meeting the congestion handover criteria in the congestedcell. This has the potential to relieve congestion on a bigger scale than the

previous option.

The hand over criteria are as for Directed Retry feature:

1. Rxlev (neighbour X) > rxlev_min_ncell

rxlev_min_ncell is defined in the Data Base for this neighbour X.


20/39



2. PBGT (neighbour X) - cr_ho_margin > 0

2.7.1.2 Enhanced Congestion Relief

Once a cell reaches its operator-defined congestion threshold, existing traffic is optimally

handed over to non-congested cells, thereby relieving the condition and clearing capacity

for new calls or originations. By way of comparison, Directed Retry forces originations in

congested cells to be `directed' immediately to other cells which, on many occasions, can

result in poor cell assignments and poor call quality (see chapter 3.3).

Advanced Congestion Relief defines new handover procedures to select active calls to be

handed over to relieve congestion in the cell.

These new procedures take the form of expanding the decision process for handover to

include the state of congestion at the target cell and incorporate the added dimension of

time over which the decision is to be implemented. For example, target cells will not accepta congestion relief handover that puts itself into a congested state, resulting in further

congestion procedures being invoked. Excessive handovers are therefore eliminated.

A source cell will not attempt a congestion relief handover, for a period of time, to a target

cell that had rejected a previous handover attempt. The time period may be specified by the

operator or as a default, may be set to the time between the onset and completion of a

congestion relief procedure. This protects the system from experiencing excessive handover

attempts, as well as resulting in a reduction in signalling.


The main O&M impacts of this feature are to the BSS database with several BSS, Cell and

Neighbour parameters, some of which are shared with the Directed Retryfeature.

2.7.2.1 HO_exist_congest parameterThis parameter determines if attempts to handover existing calls on a TCH will be initiated

in the case of an MS needing a TCH when there are none available in that cell. This

parameter indicates either to attempt to handover as many calls as the number of queued

assignment requests (if set to 1) or attempt to handover as many calls as meet the

congestion handover criteria (if set to 2). It concerns a cell.Valid Range: 0,1 or 2 Default Value: 0

If set to 0, the functionality is disabled.

2.7.2.2 Congest_HO_Margin parameterThis parameter is used in the case of a congestion handover. To make it easier to handover

to this neighbour in the case of congestion in the current cell, this parameter value should

be less that the value of the handover margin(s).

To disable congestion handovers to this neighbour, set the congestion handover margin to

the maximum value.

Valid Range: 63dB to 63dB Default Value: None


21/39



2.7.2.3 tch_congest_prevent_thres parameterThis per cell parameter specifies the level of overall TCH utilisation by any MS in a given

Cell, at which the Congestion Relief procedure is initiated. The parameter is expressed as a

percentage.


If set to 0, the congestion relief is disabled. If set to 101, the congestion relief process starts

when all available TCHs are in use, and at least one more TCH is requested.

The last 3 parameters concern the Enhanced Congestion Relief :

2.7.2.4 congest_at_source parameterUsed to control how a given cell behaves should it be unable to force a given imperative

handover

Valid Range: 0,1 Default Value: 1

If set to 0: The system takes no actions if a given candidate rejects a handover.

If set to 1: if an imperative handover is needed, the source Cell retries candidates which

were previously unable to serve the handover request.

2.7.2.5 congest_at_target parameterUsed to control how a given cell behaves should it reject a handover request (either an

imperative or congestion relief attempt).

Valid Range: 0,1 Default Value: 1

If set to 0: The system will take no action if the Cell reject a handover request.

If set to 1: The system will invoke Congestion Relief procedures if this cell rejects a

handover request.

A parameter about redirecting extra load traffic onto the multiband :

2.7.2.6 mb_tch_congest_thres parameterUsed to control the percentage point at which Multiband Mobile Stations will start to be

redirected to the preferred band.


If set to 101, there are no resources left to allocate.

2.7.3 Database Timer

2.7.3.1 valid_candidate_ period timerThe BTS (RRSM) timer valid_candidate_period specifies the duration for which

candidate channels for handover due to congestion are kept, before querying again for new

ones.

Valid Range: 0 to 1000000 Default Value: 4000 milliseconds


22/39



The last 2 timers concern the Enhanced Congestion Relief

2.7.3.2 ext_rtry_cand_prd timerUsed to control the time between successive attempts to handover to a particular inter-BSS

target cell which had previously rejected a handover attempt (either an imperative or

congestion relief attempt).Valid Range: 0 to 1000000 Default Value: 4000 milliseconds

2.7.3.3 rtry_cand_prd timerUsed to control the time between successive attempts to handover to a particular intra-BSS

target cell which had previously rejected a handover attempt (either an imperative or

congestion relief attempt).

Valid Range: 0 to 1000000 Default Value: 4000 milliseconds


23/39



2.8 Flow ControlIts purpose is to reduce the number of access bursts sent to a site according to the traffic

loading by barring the access to some mobile belonging to a class chosen randomly.

This feature is known as well as the automatic barring. It is split in 3 sub features

depending on the cause (TCH congestion, overload of Racch from the the air interface, toomany SSM blocks) leading to an overload. Only the Racch flow control will be described

in this note, the 2 remaining one are quite similar and less used (for information see Manual

Reference 01W36).

2.8.1 RACH flow control Description

Racch_load_period, ccch_load_period and rach_period parameters provide traffic flow

control by allowing the RSS to monitor the number of channel requests received in a given

period. If this number exceeds the rach_load_threshold then the RSS transmits a load

indication message to call processing.

On receipt of this message, call processing bars one random access class (0-9).Simultaneously, CP starts timers T1 & T2 (flow_control_t1 and flow_control_t2). When

T1 expires, CP bars one more access class in receipt of another load indication message

from RSS. If period T2 elapses without CP receiving another load indication message from

RSS, then an access class is unbarred. T2 must be greater than T1.

Figure 4: RACH flow control

The decision of which access class is to be barred first is decided at random by CP and

further access classes are barred on a cyclic basis, low to high. All access classes that

subsequently become unbarred will not be barred again until all other access classes have

also been barred. The first class to be unbarred is the class which has been barred longest.

Both the rach_load_period and ccch_load_period are in multiples of 235.5mS (1 x 51

frame). The rach_load_period determines the period over which the RACH load is

monitored. The ccch_load_period is in operation only when an overload condition has

been triggered in the previous period (RACH or CCCH).

The recommended method of calculating rach_load_threshold is:

rach_load_threshold = Total number of channels(TCH/SDCCH) x100 /

No of RACHs in period x No of RACH timeslots

Where:The numerator is the number of SDCCH sub-slots and TCHs configured for the cell.


24/39



The denominator is the number of available RACH slots in 4 * 51 frame multiframes. This

changes depending on the value ofccch_conf.

The resulting percentage is the rach_load_threshold, with a granularity of 0.01%.

Config Carrier SDCCH TCH CCCH Combined RACH_load_threshold

A 3 16 21 1 NO 18,14%B 3 16 20 2 NO 8,82%


2.8.2.1 TCH Flow Control Parameters

tch_flow_control.Enables (set to 1) or disables (set to 1) the TCH flow control option.

Valid Range: 0 or 1 Default Value: 0

tch_busy_critical_threshold.Sets the threshold for initiating the flow control procedure barring two of the access

classes 0 through 9 from making calls due to TCH congestion.


tch_busy_norm_threshold.It sets the threshold for initiating the flow control procedure to bar a single access class

0 through 9 from making a call due to TCH congestion.


.

2.8.2.2 RACCH Flow Control Parameters

ccch_load_period.Indicates the number of TDMA multiframes between successive calculations of the

RACH load during overload conditions.


rach_load_period.Indicates the number of TDMA multiframes between successive calculations of the

RACH load during non-overload conditions.Valid Range: 1 to 1020 Default Value: 16

rach_load_threshold.Specifies the threshold level for RACH load.

Valid Range: 0 to 1000 Default Value: 1000 (disables the flow

control)

rach_load_type.This parameter selects the RACH loading time calculation method to be used.

Valid Range: 0 or 1 Default Value: NoneIf set to 0: The method is based on percentage of RACH opportunities used.


25/39



If set to 1: The method is based on percentage of total RACHs which are incorrect

(collisions).

2.8.2.3 SSM Flow Control Parameters

ssm_normal_overload_threshold.Indicates the usage of call information blocks.


ssm_critical_overload_threshold.Indicates the usage of call information blocks.



26/39



2.9 Multiband environment2.9.1 Description

In a multiband environment, a mobile should be directed to the preferred band during the

TCH assignment.

2.9.2 Database Parameters

The preferred band can be set in the BSS database on a per cell basis by the parameter

band_preference.

Band_preference

Where :

1 GSM900

2 EGSM900

4 GSM1800

8 DCS2000 (also known as

PCS1900)

Location ID

Cell ID

The way the multiband mobile could be directed is defined by the per cell parameter

band_preference_mode :

Band_preference_mode

Where :

0 Default. No preference

1 Multiband Handover on SDCCH to

TCH assignment

2 Multiband handover to preferred band

3 Combination of value 1 and 2

4 Constantly attempt to do multibandhandover

5 Combination of value 1,2, and 4

6 Identical to value 5, but triggered

when the cell is congested

Location ID

Cell ID

The values 1,3,5 and 6 for the band_preference_mode can allow a multiband mobile

which is not on the preferred band at the time of SDCCH to TCH assignment, to be


27/39



assigned by the BSS to the strongest neighbour cell with available resource from the

preferred band.

If unsuccessful the BSS will not attempt to direct this MS to the preferred band again for

the life of the current call connection. The BSS will always hand over this MS to the

strongest MS reported neighbour when required for normal radio resource reasons.Preferred band neighbours dont have preference on this handover.

The number of MR in the call setup phase is time dependent and it is most likely to be

between zero and two. The decision is made as soon as the BTS is aware that it has an

originating multiband mobile, so no definite number of MR is given. The BSS considers

any preferred band neighbours regardless of type that beats rxlev_min_cell. The ho_cause

in this mode is BAND RE-ASSIGNMENT. (see annexe statistics)

With a band_preference_mode set to 2, The BSS attempts to assign a multiband mobile to

the strongest preferred band MS reported neighbour when a handover is required for

normal radio resource reasons (or congestion relief reasons). The BSS places preferredband neighbours ahead of non-preferred band neighbours.


28/39



3Compatibility andDependency of theResource Allocation

Features

3.1 Interference Band and Improved SDCCH/TCH controlThe interference band allocated to a channel is still the first criterion in the channel

allocation algorithms. A channel from the highest priority carrier matching the requested

interference band is allocated to a channel request. Moreover, the channel allocation

priority is also a secondary criterion after the existing criteria of channel selection in a

Multiband, Concentric Cell, and Extended Range Cell environment. Also the channel

allocation priority may not be followed for an emergency call if a channel is allocated from

the emergency reserved channel pool. The only way for the carrier priority to have a greater

influence, it is to open up the interference band 0 further.

For interference-based intracell handovers, the channel selection algorithm for a non-hopping cell has been modified to consider the channel allocation priority as follows:

1. Compile a list A with any channels in the best interference band.2. From list A, select any channels on a carrier other than the current carrier and

compile a list B. If none are available, select the best channel from list A.

3. From list B, select a channel with the best available channel allocation priority.

3.2 Directed Retry and Congestion ReliefDirected retry and Congestion relief are two features which are designed to offload traffic

from congested cells by moving calls to suitable neighbours. A summary of the difference

between these features is provided in Figure 5.


29/39



Figure 5: Summary Flowchart showing the difference between DR and Congestion Relief

These features can work together or independently of each other. Basically, the Directed

Retry increases the availability and the call origination blocking rate and the Congestion

Relief is aimed at increasing the maintanibility performance by distributing the traffic

among nearby cells. If both features are enabled (DR+CR), with one mobile being on the

SDCCH and no TCH available in the serving cell, the SW will try to assign a TCH to the

MS requesting resources by using any of the methods, whichever satisfies the necessary

criteria FIRST.

Some test have been carried out some years ago when Congestion Relief was available,which showed that combining both features would only give a marginal advantage over

Congestion Relief in reducing TCH blocking.

In the case of congestion relief, the calls to be handed over are already established, so the

power budget calculation is based on their longer history of measurement reports and the

MS get to the audio state either faster or on a stronger cell (rather than Directed Retry

where one Measurement Report is available).


30/39



3.3 Directed Retry/(Enhanced )Congestion Relief and TCH Flow ControlBoth of them try to deal with the same issue, congestion in 2 different ways. If both feature

are triggered, then depending on what threshold percentages are set for each feature, either

one or the other feature may be the only one that is triggered. On the other hand, it ispossible with the right thresholds that both features would trigger at times, creating a

random series of either access class barring or hand over to other cells.

So, for maximum benefit of directed retry or congestion relief, TCH flow control should be

disabled. Because this feature supports more calls in the network through handovers to less

congested cells, it is not advantageous to bar any access classes due to TCH usage as in the

case of TCH flow control.

3.4 Directed Retry / (Enhanced) Congestion Relief and QueuingIn all cases of directed relief and directed relief versions, the TCH request is held in theTCH queue. If a TCH becomes available then the process is aborted and the TCH is

allocated.

For the DR and (Enhanced) Congestion Relief, the Assignment Request is queued

regardless of whether queuing is enabled. It must be noted that there is no binary flag

dedicated to this functionality, but if the value ofqueue_management_information value

is non zero then the queuing is allowed. From the version 16042, the queuing procedure is

as follows:

- If queuing is enabled, normal queuing is performed.

- If queuing is disabled in the BSS, the BSS performs an internal queuingprocedure but no Queuing Indication message is sent to the MSC, and the length of the

queue info blocks is 25. The timer bssmap_t11 is still valid.


31/39



Annexe 1: Statistics relative to the

Resource Allocation

This annex presents briefly some statistics incremented during the channel establishment,

TCH assignment and band re-assignment.

Idle interference monitoring

IDLE_TCH_INTF_BANDn (n=0 to 4) : This statistic per carrier measures the maximum

and mean number of idle traffic channels per interference band. Idle TCHs are allocated to

five interference bands. This statistic measures the number of idle TCHs in interference

band n. An idle TCH will fall into band 0 if its average interference band is less than thevalue of the element interfer_bands, n.

Channel establishment

ALLOC_SDCCH : This statistic is the sum of the number of times a SDCCH sub-slot is

successfully seized. If a TCH is reconfigured as an SDCCH, only the SDCCH statistics will

be configured.

A Channel Request message is used by the MS to request allocation of a dedicated channel

(to be used as an SDCCH) by the network, in response to a paging message (incoming call)

from the network or as a result of an outgoing call/supplementary short message servicedialed from the MS. It is also used as part of the call re-establishment procedure.

SDCCH seizure is caused by immediate assignment, handover, and channel assignment

procedures. Congestion is signalled by the Immediate Assignment Reject or the

Assignment/Handover Failure message.

ALLOC_SDCCH_FAIL : This statistic is pegged each time the Cell Resource Manager

tries to allocate a SDCCH but is prevented because they are all busy. This statistic is also

incremented in the target cell when rejecting an SDCCH handover through lack of

resources.

If a TCH is reconfigured as an SDCCH, only the SDCCH statistics will be incremented.

SDCCH_CONGESTION : This is a durational statistic indicating the total time within a

period that no SDCCH was available. When the last SDCCH available is allocated then the

CRM will start the sdcch_congestion timer, this timer will only be stopped when at least

one SDCCH becomes idle.

BUSY_SDCCH : This statistic is a weighted distribution and will produce a mean value

indicating the average number of SDCCH in use per interval. It is incremented each time

the CRM allocates a SDCCH.

AVAILABLE_SDCCH : This is a gauge statistic indicating the average number of

available SDCCHs that are in use or available for use. The SDCCH is available when its

administrative state is "unlocked" or "shutting down" and the operational state is "enabled",


32/39



and is unavailable when its administrative state is "locked" and an operational state of

"disabled". This statistic is pegged when a change in SDCCH availability is detected.

TCH assignment

ALLOC_TCH : This statistic provides the number of successful TCH allocations within a

cell for both call origination and hand ins.

This statistic is pegged for successful TCH allocations within a cell as a result of a call

establishment or hand in attempt:

Successful allocation due to call establishment including successful allocations dueto directed retries.

Successful allocation due to intra-cell hand in.

Successful allocation due to inter-cell/intra-cell hand in.

Successful allocation due to inter-BSS hand in.This statistic is pegged prior to the transmission of the assignment/handover command to

the MS and, therefore, does not take into account the success or failure of the

assignment/hand in from an RF perspective.

ALLOC_TCH_FAIL : This statistic provides the number of unsuccessful allocations of a

TCH within a cell for both call origination and hand in. Cases involving Immediate

Assignment Reject are also included in the peg count.

This statistic is pegged when an attempt to allocate a TCH in a cell fails due to a lack of

resources:

Unsuccessful allocation due to call establishment including unsuccessful allocations

due to directed retries. Successful allocation due to intra-cell hand in.

Unsuccessful allocation due to inter-cell/intra cell hand in.

Unsuccessful allocation due to inter-BSS hand in.

BUSY_TCH : This statistic is a weighted distribution and will produce a mean value

indicating the average number of TCH in use per interval. It is incremented each time the

CRM allocates a TCH upon assignment, immediate assignment (in case of emergency call)

and handover.

MAX_BUSY_TCH : This statistic is the maximum number of TCHs simultaneously busy

during an interval.

TCH_USAGE : This statistic gives an indication of the total amount of traffic carried by

the cell. Active means connected (capable of transmitting circuit mode user data) and

Activated, for example, used as a DCCH. This statistic will be used only for outer zone

resources when TCH usage is being measured for Concentric Cells and will only measure

the usage of normal range channels in Extended Range Cells.

AVAILABLE_TCH : This is a gauge statistic indicating the average number of available

TCHs that are in use or available for use. The TCH is available when its administrative

state is "unlocked" or "shutting down" and the operational state is "enabled", and is

unavailable when its administrative state is "locked" and an operational state of "disabled".This statistic is pegged when a change in TCH availability is detected.


33/39



TCH_CONGESTION : This is a duration statistic indicating the total time within a period

that no TCH was available. When the last TCH available is allocated then the CRM will

start the tch_congestion timer, this timer will only be stopped when at least one TCH

becomes idle.

TCH_DELAY : This statistic records the mean delay and the statistical distribution of the

delay between an assignment request or handover request and a TCH being allocated for

each cell on the BSS.

This statistic is not incremented upon BSSMAP_T11 expiry or if the call is cleared before

assignment.

TCH_Q_LENGTH : This statistic provides the arithmetic mean of the number of queued

TCH assignment procedures. Queueing is done due to the Call Queueing feature,

Emergency Call Pre-emption, EGSM, and Directed Retry.

This measurement is obtained by sampling the TCH queue length and reporting the current

length. The mean TCH queue length includes the number of queued assignment andexternal handover requests.

CALLS_QUEUED : This statistic counts only the Assignment Requests that are queued

during an interval, not handovers. If queuing has been allowed and no resources exist, the

CRM queues an assignment request and informs the RRSM with a force queue message.

CONGEST_STAND_HO_ATMPT : This statistic measures the number of attempted

handovers of a MS due to standard directed retry procedure caused by TCH congestion

from the source cell. These inter-cell handovers (internal or external to the BSS) involve

changing the channel mode during the handover. This statistic is pegged each time a

directed retry handover procedure is attempted, for both inter-cell and external handovers.

CONGEST_EXIST_HO_ATMPT : This statistic measures the number of attempted

inter-cell handovers (internal or external to the BSS) of calls on a TCH due to TCH

congestion from the source cell. This statistic is pegged each time a congestion relief

handover is attempted. This statistic is pegged for both internal inter-cell and external

handovers.

CONGEST_ASSIGN_HO_SUC : This statistic counts the number of successful internal

and external handovers that were executed as the result of standard directed retry. This

statistic also tracks the handovers that occurred during the assignment procedure for normalradio reasons. This statistic is pegged after a successfully completed directed retry

handover procedure or a successfully completed handover during assignment procedure.

FLOW_CONTROL_BARRED : This statistic measures the duration for which access

classes are barred as a result of flow control. This statistic gives an indication when flow

control actions have been taken to prevent overload.


34/39



Band re-assignment

OUT_HO_CAUSE_ATMPT[BAND_RE_ASSIGN]: This statistic monitors the number

of times an outgoing inter-cell handover is attempted due to band reassignment in source

cell. This is a per cell cause.

OUT_HO_NC_CAUSE_ATMPT[BAND_RE_ASSIGN] : This statistic monitors the

number of handovers due to band reassignment per neighbour per cause. This statistic can

be enabled for a maximum of 16 cells. For each cell where the statistic is enabled, a

maximum of 32 target cells can be tracked.


35/39



Annexe 2: Extra Parameters and Timers

Relative to the Channel Allocation

emerg_reserved timer

This parameter determines how long a TCH is reserved for an emergency call access. The

TCH becomes reserved after an existing call is torn down due to the lack of TCHs at the

time of an emergency call access.

If emergency call preemption is enabled, and emergency calls are waiting on SDCCHs,

traffic channels would be reserved for emergency calls. These TCHs could be idle

channels, if available. If not, existing normal calls could be torn down to make TCHs

available for the emergency calls.

Valid Range: 0 to 1000000 Default Value: 120000 (milliseconds)

rr_t3101 timerThis parameter sets the time that the BSS waits for the Mobile Station (MS) to establish on

a Standalone Dedicated Control Channel (SDCCH) after sending an immediate assignment

message.


bssmap_t11 timer

This parameter controls how long a request is queued when waiting for a resource.

This timer starts when the BTS attempts to queue an Assignment Request.

This timer should be less than the assign_succeful timer, the call will be queued for the

length of time specified by the assign_successful timer.

If the timer expires the call terminates.Valid Range: 0 to 1000000 Default Value: 28000 (milliseconds)

It concerns both internal and external queuing.

Bssmap_tqho timer

This parameter sets the maximum allowed queuing time for a handover request.

This timer starts when the BSC queues the Handover Request.

If this timer expires, the system starts the MTB1 timer to wait for another handover request.


It concerns both internal and external queuing.

Immediate_assign_mode parameter

This parameter determines action to be taken when no Standalone Dedicated Control

Channels (SDCCHs) are available. This parameter also determines the type of channel that

is assigned to immediate channel requests for emergency calls.

If this parameter is set to ASSIGN_SDCCH_ONLY (equal to 0), immediate channel

requests are either rejected or discarded if there is no SDCCH available for both normal and

emergency calls.

If this parameter is set to ASSIGN_SDCCH_TCH (equal to 1), idle TCH is searched and

allocated for immediate channel requests after all SDCCHs are busy for normal calls. For

emergency calls, a TCH is allocated if one is idle. If all TCHs are busy, an SDCCH is

allocated for the emergency call.Valid Range: 0 to 255 Default Value: 0


36/39




37/39



Annexe 3: GPRS Feature and resource

allocation

The purpose of this section is to illustrate some of the features involved in the resource

allocation for the General Packet Radio Service (GPRS) network. These include the

dynamic configuration of GPRS Packet Data Channels (PDCH) on the air interface, the

allocation of PDCH and the mapping of GPRS timeslots between the Base Station

Controller (BSC) and the Packet Control Unit (PCU).

Configuration of PDCH

With the current release, PDCH can be configured on a single carrier/RTF per cell. There

are two types of PDCH: switcheable and reserved. Reserved PDCH can only be used for

GPRS data transfers, whereas switcheable TS may switch between circuit and packet

switched modes. Reserved TS could also be used by GSM Emergency Calls. The number

and type of PDCH are set when equipping an RTF, or can be modified using the

res_gprs_pdch and max_gprs_pdch parameters. The example of Figure 6 illustrates the

case where res_gprs_pdch=3 and max_gprs_pdch=5.

Figure 6: Example of configuration of a GPRS carrier

The configuration of PDCH always starts from TS 7 (i.e. if there is only 1 PDCH

configured in the cell, it will be TS 7).

Switcheable TS are normally used for GPRS data transfers. However, circuit switched

always has the priority over packet switched data. So when the number of idle TCH in the

cell falls to 0 and there is a new incoming call, the lowest switcheable TS will be

immediately reconfigured as a TCH and allocated to the incoming call. In the previous

example, TS3 would be allocated.

If there were no reserved GPRS TS in the cell, all the switcheable TS could be possibly

used by circuit switched calls. Only TS7 would wait for all the packet transfers to finish

before being reconfigured.

Reconfiguration of circuit switched TS back to PDCH starts as soon as the number of idle

TCH in the cell exceeds the idle_tch_gprs_reconfig_thresh parameter. This

reconfiguration always starts from TS7 downwards. The number of PDCH will never

exceed max_grps_pdch. If TS7 is busy, then setting the gprs_intraho_allowed parameter

to 1 forces the MS on TS7 to be handed over (intra-cell) to another idle TS.

This feature has no impact on the existing directed retry, congestion relief and dynamic

SDCCH configuration features.

TS 0

TCH

TS 1

TCH

TS 2

TCH

TS 3

SW

TS 4

SW

TS 5

RES

TS 6

RES

TS 7

RES


38/39



Allocation of resources on the air interface

The allocation of GPRS resources on the air interface is entirely managed by the PCU and

is a specific Motorola feature.

When all resources are Idle, PDCH are allocated from TS7 downwards. The number of TS

allocated to a GPRS MS depends on the multislot capability of the MS. For instance, if theMS is a Multislot Class 1, it can only use 1 TS on the UL and 1 TS on the DL, so the PCU

won't allocate more than that. This number also depends on the QoS negotiated by the MS

during the access and, of course, on the number of available PDCH in the cell.

The other factor related to the allocation of resources will be the Coding Scheme used on

the air interface (CS-1 or CS-2). CS-1 gives an overall data rate of 9.06 kbits/s on 1 TS, and

CS-2 gives 13.4 kbits/s. This means that with CS-2, less resources can be used to achieve

the same data rate, if the quality of the link is good enough. These algorithms are internal

to the PCU software and cannot be modified by the operator.

Resource mapping between BSC and PCU

The interface between the BSC and the PCU is called the Generic Data Stream (GDS) and

is Motorola proprietary. This interface is carried over standard E1 links.

The GDS can carry either signalling (GDS LAPD) or data (GDS TRAU). The GSL is

terminated by a Packet Interface Control Processor (PICP) at the PCU, and the GDS

TRAU by a Packet Resource Processor (PRP). Currently, 6 GDS LAPD channels are

supported by PCU.

A PRP supports only one GDS TRAU link, which corresponds to a total number of 120

TS (at 16 kbits/s). However only 30 TS may be active at the same time, the other 90 should

be in standby. There can be up to 9 PRP boards in a double-side PCU cage, so that the PCUcan handle a maximum of 270 active GPRS timeslots.

The PCU shares all the GPRS cells it manages between all the PRP boards that are present

and equipped in its cage. This is performed in a round-robin fashion, that is if the PCU

handles 100 cells hand has 5 PRP boards, each PRP will handle a total of 20 cells.

Figure 7 Timeslot mapping between BSC/PCU

The E1 link will carry the GPRS timeslots (called GPRS Channel Identifiers GCI) of the

cells managed by each PRP boards. The connection between the GCI and the GPRS air

interface timeslots is performed inside the BSC. There is a 1:1 static mapping between the

GPRS timeslots carried by the RTFs and the GCIs on the GDS TRAU.

BSC PCU

RTF


39/39


Nevertheless, this mapping can be modified after:

PRP failure

GDS TRAU link failure

PCU reset

These situations clearly involve a redistribution of the resources across the in-service PRP

boards inside the PCU. This is managed by the Packet System Processor (PSP) and is not

configurable by the operator.

resources allocat

Documents