RESOURCE ALLOCATION

DIFFUSION
FRANCE TELECOM

MOTOROLA

Authors :

Reviewed by :

Responsible :

Version 1.0

Resource Allocation V1.0

INTRODUCTION.......................................................................................................... 4 1.1 1.2 SCOPE OF THE DOCUMENT ......................................................................................... 4 GSM MESSAGES FOR SUCCESSFUL ESTABLISHMENTS ............................................... 5

FEATURES .................................................................................................................... 6 2.1 INTERFERENCE BANDS ................................................................................................ 6 2.1.1 Description ......................................................................................................... 6 2.1.2 Database Configuration ..................................................................................... 6
2.1.2.1 2.1.2.2 interfer_bands parameter .......................................................................................................................... 6 Intave parameter ......................................................................................................................................... 6

2.1.3
2.1.3.1

Database Timers ................................................................................................. 7

rf_res_ind_period timer ............................................................................................................................ 7

2.2 SDCCH AND TCH ALLOCATION 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 SDCCH ASSIGNMENT ................................................................................ 9 2.3.1 Description ......................................................................................................... 9 2.3.2 Database Configuration ..................................................................................... 9
2.3.2.1 2.3.2.2 sd_load parameter ...................................................................................................................................... 9 sd_priority parameter ................................................................................................................................ 9

2.3.3 Implementation of Improved SDCCH and TCH control .................................. 10 2.4 SDCCH AND TCH CHANNEL RECONFIGURATION ................................................... 11 2.4.1 Description ....................................................................................................... 11 2.4.2 Database Configuration ................................................................................... 11
2.4.2.1 2.4.2.2 2.4.2.3 2.4.2.4 2.4.2.5 2.4.2.6 channel_reconfiguration_switch parameter .......................................................................................... 11 number_sdcchs_preferred parameter .................................................................................................... 11 sdcch_need_low_water_mark parameter............................................................................................... 12 sdcch_need_high_water_mark parameter ............................................................................................. 12 tch_full_need_low_water_mark parameter ........................................................................................... 12 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 ................................................................................... 15
2.5.2.1 2.5.2.2 2.5.2.3 queue_management_information parameter ....................................................................................... 15 max_q_length_full_rate_chan parameter .............................................................................................. 16 max_q_length_sdcch parameter .............................................................................................................. 16

2.5.3 Database Timer ................................................................................................ 16 2.6 DIRECTED RETRY ..................................................................................................... 17 2.6.1 Description ....................................................................................................... 17 2.6.2 Database Configuration ................................................................................... 18
2.6.2.1 2.6.2.2 2.6.2.3 2.6.2.4 2.6.2.5 2.6.2.6 dr_preference parameter .......................................................................................................................... 18 dr_standard_congest parameter.............................................................................................................. 18 dr_ho_during_assign parameter ............................................................................................................. 18 dr_chan_mode_modify parameter .......................................................................................................... 18 dr_allowed parameter ............................................................................................................................... 18 congest_ho_margin parameter ................................................................................................................ 18

2.7 CONGESTION RELIEF AND CONGESTION RELIEF ENHANCED .................................... 19 2.7.1 Description ....................................................................................................... 19
2.7.1.1 2.7.1.2 Congestion Relief ...................................................................................................................................... 19 Enhanced Congestion Relief ..................................................................................................................... 20

2.7.2

Database Configuration ................................................................................... 20

Motorola Confidential Proprietary

Page 2/39

07/11/2011

Resource Allocation V1.0

2.7.2.1 2.7.2.2 2.7.2.3 2.7.2.4 2.7.2.5 2.7.2.6 HO_exist_congest parameter ................................................................................................................... 20 Congest_HO_Margin parameter ............................................................................................................. 20 tch_congest_prevent_thres parameter................................................................................................... 21 congest_at_source parameter................................................................................................................... 21 congest_at_target parameter ................................................................................................................... 21 mb_tch_congest_thres parameter ........................................................................................................... 21

2.7.3
2.7.3.1 2.7.3.2 2.7.3.3

Database Timer ................................................................................................ 21

valid_candidate_ period timer ................................................................................................................ 21 ext_rtry_cand_prd timer ......................................................................................................................... 22 rtry_cand_prd timer ............................................................................................................................... 22

2.8 FLOW CONTROL ....................................................................................................... 23 2.8.1 RACH flow control Description ....................................................................... 23 2.8.2 Database Configuration ................................................................................... 24
2.8.2.1 2.8.2.2 2.8.2.3 TCH Flow Control Parameters ................................................................................................................ 24 RACCH Flow Control Parameters .......................................................................................................... 24 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 TCH FLOW CONTROL... 30 3.4 DIRECTED RETRY / (ENHANCED) CONGESTION RELIEF AND QUEUING..................... 30 ANNEXE 1: STATISTICS RELATIVE TO THE RESOURCE ALLOCATION................................... 31
Idle interference monitoring ........................................................................................................................................ 31 Channel establishment ................................................................................................................................................. 31 TCH assignment .......................................................................................................................................................... 32 Band re-assignment ..................................................................................................................................................... 34

ANNEXE 2: EXTRA PARAMETERS AND TIMERS RELATIVE TO THE CHANNEL ALLOCATION 35 ANNEXE 3: GPRS FEATURE AND RESOURCE ALLOCATION ................................................. 37 CONFIGURATION OF PDCH ................................................................................................ 37 ALLOCATION OF RESOURCES ON THE AIR INTERFACE ......................................................... 38 RESOURCE MAPPING BETWEEN BSC AND PCU .................................................................. 38

Motorola Confidential Proprietary

Page 3/39

07/11/2011

Resource Allocation V1.0

1 Introduction
1.1 Scope of the Document The 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.

Motorola Confidential Proprietary

Page 4/39

07/11/2011

Resource Allocation V1.0 1.2 GSM Messages for Successful Establishments

The diagram below resumes the main messages during a successful call. In Annexe 1 is presented the major statistics relative to SDCCH/TCH allocation.

MS

BSS

MSC

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

Figure 1: main GSM Messages involved in Successful Assignment.

Motorola Confidential Proprietary

Page 5/39

07/11/2011

Resource Allocation V1.0

2 Features
2.1 2.1.1 Interference bands 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

Motorola Confidential Proprietary

Page 6/39

07/11/2011

Resource Allocation V1.0 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). Valid Range: 1 to 127 Default Value: 10

Motorola Confidential Proprietary

Page 7/39

07/11/2011

Resource Allocation V1.0

2.2

SDCCH and TCH Allocation based on based on Channel Priority

This 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. Valid Range: 0 to 250 Default Value: 0 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).

Motorola Confidential Proprietary

Page 8/39

07/11/2011

Resource Allocation V1.0 2.3 Explicit SDCCH Assignment

This 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 to Traffic Channels) is in operation, then the following is undertaken: TCH/F to SDCCH configuration is performed on a TCH/F which is on the highest priority carrier. SDCCH to TCH/F configuration is performed on an SDCCH/8 which is on the lowest priority carrier

2.3.2

Database Configuration

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

Motorola Confidential Proprietary

Page 9/39

07/11/2011

Resource Allocation V1.0 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 priority to 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.

Motorola Confidential Proprietary

Page 10/39

07/11/2011

10

Resource Allocation V1.0 2.4 SDCCH and TCH Channel Reconfiguration

This 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 exceed max_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 than tch_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 than sdcch_need_low_water_mark.

2.4.2

Database Configuration

All the feature are configured on a per cell basis. 2.4.2.1 channel_reconfiguration_switch parameter Permits 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 parameter Defines 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 (if ccch_conf = 1) Motorola Confidential Proprietary Page 11/39 07/11/2011 11

Resource Allocation V1.0 2.4.2.3 sdcch_need_low_water_mark parameter Sets 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 Valid Range: 10 to 48 Default Value: 12

2.4.2.4 sdcch_need_high_water_mark parameter Sets the number of idle SDCCHs that trigger reconfiguration to SDCCHs. Valid Range: 1 to 39 Default Value: 2 If =1 means wait that there is no sdcch available 2.4.2.5 tch_full_need_low_water_mark parameter Sets the low need threshold to determine the need for full rate traffic channel reconfiguration to SDCCHs. Valid Range: 0 to 255 Default Value: 0

2.4.2.6 max_number_of_sdcch parameter Sets 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. If ccch_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. Valid Range: 0 to 48 Default Value: 12

Motorola Confidential Proprietary

Page 12/39

07/11/2011

12

Resource Allocation V1.0 2.4.3 Implementation of Channel Reconfiguration

Interest It is primarily meant for acquiring SDCCH resources during the operation of the system when 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 and particular 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.

Motorola Confidential Proprietary

Page 13/39

07/11/2011

13

Resource Allocation V1.0 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 = 16 sdcch_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)

Time Slot = 8 SDCCH 2 3 4 5 6

Time Slot = 8 SDCCH or 1 TCH 9 10 11 12 13 14 15 HWM = 2

16

Time Slot = 8 SDCCH or 1 TCH 17 18 19 20 21 22 23

24

1)

TCH before reconfiguration

MAX=24 SDDCH PREFERED = 16 HWM = 2

2)

SDCCH needed

TCH before reconfiguration

MAX=24 LWM = 18 HWM = 2

3)

avalaible SDCCHs after reconfiguration -from 2) to 3)-

MAX=24 LWM = 18 HWM = 2

4)

Too Low

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

10 11 12 13 14 15 16 17 18 19 BACK to the same configuration as in the case 1)

20

21

22

MAX=24 23 24

SDCCHs in use

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 to step1).

Motorola Confidential Proprietary

Page 14/39

07/11/2011

14

Resource Allocation V1.0 2.5 Call Queuing

It 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 the assignment 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

Database Configuration

2.5.2.1 queue_management_information parameter Displays 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 Valid Range: 0 to 50 Default Value: 50

Motorola Confidential Proprietary

Page 15/39

07/11/2011

15

Resource Allocation V1.0 2.5.2.2 max_q_length_full_rate_chan parameter Sets 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 MSC Valid Range: 0 to 50 Default Value: 0 2.5.2.3 max_q_length_sdcch parameter Sets the maximum length of the queue for SDCCH requests Valid Range: 0 to 50 Default Value: None 2.5.3 Database Timer Bssmap_t11 (see annexe 2)

Motorola Confidential Proprietary

Page 16/39

07/11/2011

16

Resource Allocation V1.0 2.6 Directed Retry

The 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).

Motorola Confidential Proprietary

Page 17/39

07/11/2011

17

Resource Allocation V1.0 2.6.2 Database Configuration

2.6.2.1 dr_preference parameter This 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 parameter This 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. Valid Range: 0 (disabled), 1 (enabled) Default Value: 0

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. Valid Range: 0 (disabled), 1 (enabled) Default Value: 0

2.6.2.4 dr_chan_mode_modify parameter This 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. Valid Range: 0 (disabled), 1 (enabled) Default Value: 0

2.6.2.5 dr_allowed parameter This parameter enables the Directed Retry option, if set to 1, otherwise set to 0. This is a per neighbour attribute for external neighbours only. Valid Range: 0 (disabled), 1 (enabled) Default Value: 1 2.6.2.6 congest_ho_margin parameter This per neighbour 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 +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

Motorola Confidential Proprietary

Page 18/39

07/11/2011

18

Resource Allocation V1.0 2.7 Congestion Relief and Congestion Relief Enhanced

They 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 on the 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 congested cell. 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. Motorola Confidential Proprietary Page 19/39 07/11/2011 19

Resource Allocation V1.0 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 accept a 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.

2.7.2

Database Configuration

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 Retry feature.

2.7.2.1 HO_exist_congest parameter This 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 parameter This 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

Motorola Confidential Proprietary

Page 20/39

07/11/2011

20

Resource Allocation V1.0 2.7.2.3 tch_congest_prevent_thres parameter This 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. Valid Range: 0 to 101 Default Value: 100 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 parameter Used 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 parameter Used 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 parameter Used to control the percentage point at which Multiband Mobile Stations will start to be redirected to the preferred band. Valid Range: 1 to 101 Default Value: 100 If set to 101, there are no resources left to allocate.

2.7.3

Database Timer

2.7.3.1 valid_candidate_ period timer The 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

Motorola Confidential Proprietary

Page 21/39

07/11/2011

21

Resource Allocation V1.0 The last 2 timers concern the Enhanced Congestion Relief 2.7.3.2 ext_rtry_cand_prd timer Used 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 timer Used 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

Motorola Confidential Proprietary

Page 22/39

07/11/2011

22

Resource Allocation V1.0 2.8 Flow Control

Its 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, too many 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.

Motorola Confidential Proprietary

Page 23/39

07/11/2011

23

Resource Allocation V1.0 The denominator is the number of available RACH slots in 4 * 51 frame multiframes. This changes depending on the value of ccch_conf. The resulting percentage is the rach_load_threshold, with a granularity of 0.01%. Config A B Carrier 3 3 SDCCH 16 16 TCH 21 20 CCCH 1 2 Combined RACH_load_threshold NO 18,14% NO 8,82%

2.8.2

Database Configuration

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. Valid Range: 81 to 100 Default Value: 100 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. Valid Range: 0 to 100 Default Value: 100 . 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. Valid Range: 1 to 1020 Default Value: 40 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: None If set to 0: The method is based on percentage of RACH opportunities used.

Motorola Confidential Proprietary

Page 24/39

07/11/2011

24

Resource Allocation V1.0 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. Valid Range: 0 to 100 Default Value: 70 ssm_critical_overload_threshold. Indicates the usage of call information blocks. Valid Range: 0 to 100 Default Value: 80

Motorola Confidential Proprietary

Page 25/39

07/11/2011

25

Resource Allocation V1.0 2.9 2.9.1 Multiband environment 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 <element_value> <location> <cell_number>

Where : <element_ value> 1 2 4 8 <location> <cell_number> GSM900 EGSM900 GSM1800 DCS2000 PCS1900) Location ID Cell ID (also known as

The way the multiband mobile could be directed is defined by the per cell parameter band_preference_mode :
Band_preference_mode <element_value> <location> <cell_number>

Where : <element_ value> 0 1 2 3 4 5 6 <location> <cell_number> Default. No preference Multiband Handover on SDCCH to TCH assignment Multiband handover to preferred band Combination of value 1 and 2 Constantly attempt to do multiband handover Combination of value 1,2, and 4 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

Motorola Confidential Proprietary

Page 26/39

07/11/2011

26

Resource Allocation V1.0 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 preferred band neighbours ahead of non-preferred band neighbours.

Motorola Confidential Proprietary

Page 27/39

07/11/2011

27

Resource Allocation V1.0

3 Compatibility and Dependency of the Resource Allocation Features

3.1 Interference Band and Improved SDCCH/TCH control The 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 nonhopping 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 Relief

Directed 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.

Motorola Confidential Proprietary

Page 28/39

07/11/2011

28

Resource Allocation V1.0

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).

Motorola Confidential Proprietary

Page 29/39

07/11/2011

29

Resource Allocation V1.0

3.3

Directed Retry/(Enhanced )Congestion Relief and TCH Flow Control

Both 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 is possible 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 Queuing

In all cases of directed relief and directed relief versions, the TCH request is held in the TCH 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 of queue_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 queuing procedure 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.

Motorola Confidential Proprietary

Page 30/39

07/11/2011

30

Resource Allocation V1.0

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 the value 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 service dialed 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", Motorola Confidential Proprietary Page 31/39 07/11/2011 31

Resource Allocation V1.0 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 due to 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. Motorola Confidential Proprietary Page 32/39 07/11/2011 32

Resource Allocation V1.0 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 and external 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 normal radio 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.

Motorola Confidential Proprietary

Page 33/39

07/11/2011

33

Resource Allocation V1.0

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.

Motorola Confidential Proprietary

Page 34/39

07/11/2011

34

Resource Allocation V1.0

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 timer This 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. Valid Range: 0 to 1000000 Default Value: 5000 (milliseconds) 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. Valid Range: 0 to 1000000 Default Value: 30000 (milliseconds) 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

Motorola Confidential Proprietary

Page 35/39

07/11/2011

35

Resource Allocation V1.0

Motorola Confidential Proprietary

Page 36/39

07/11/2011

36

Resource Allocation V1.0

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.
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7 TCH TCH TCH SW SW RES RES RES

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.

Motorola Confidential Proprietary

Page 37/39

07/11/2011

37

Resource Allocation V1.0 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 the MS 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 PCU can 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.

BSC

PCU

RTF
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.

Motorola Confidential Proprietary

Page 38/39

07/11/2011

38

Resource Allocation V1.0 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.

Motorola Confidential Proprietary

Page 39/39

07/11/2011

39