Gsm Traffic Load Eg

Lucent Technologies -- ProprietaryThis document contains proprietary information ofLucent and is not to be disclosed or used except in

accordance with applicable agreements.

GSM Traffic LoadManagement

Engineering Guideline

EG: GSMTRM

401-380-362Issue 1.0July 1999

GSM Traffic Load Management Engineering Guideline

Lucent Technologies - PROPRIETARYUse pursuant to Company instructions

ii Issue 1.0 - July 1999

Copyright © 1999 Lucent TechnologiesUnpublished and Not for Publication

All Rights Reserved

This material is protected by the copyright and trade secret laws of the United Statesand other countries. It may not be reproduced, distributed, or altered in any fashion

by any entity, (either internal or external to Lucent Technologies),except in accordance with applicable agreements, contracts or licensing,

without the express written consent of theCustomer Training and Information Products organisation

and the business management owner of the material.

For permission to reproduce or distribute, please contact:

The Manager, RF Systems & Capacity Engineering Group

01793 883275 (domestic)(44) 1793 883275 (international)


Contents

Lucent Technologies -- ProprietaryThis document contains proprietary information ofLucent and is not to be disclosed or used except in

accordance with applicable agreements.

Issue 1.0 - July 1999 iii

1. ABOUT THIS GUIDE 1

1.1. Purpose 1

1.2. Contents 2

1.3. Scope 2

1.4. Intended audience 2

1.5. Further reference 3

2. INTRODUCTION TO TRAFFIC LOAD MANAGEMENT 5

2.1. Background 5

2.2. Key benefits 6Benefits for PTOs 6Benefits for subscribers 6Benefits for regulatory authorities 6

2.3. Traffic load management methods 7Queuing 7Directed re-try 13Pre-emption 20Handover Regarding Traffic Load 22

3. TRAFFIC LOAD MANAGEMENT DESIGN 27

3.1. Queuing design 28Network elements and interfaces 28Dependencies 32Effect of implementation 32

3.2. Directed re-try design 34Mobile support 34Network elements and interfaces 35Timers in MSC / BSC-controlled handover 44Dependencies 45Effect of implementation 47Expected effect of activating directed re-try 50

3.3. Pre-emption design 5151

50474544353434

32322828

27

22201377

6666

5

5

3

2

2

2

1

1


Contents


iv Issue 1.0 - July 1999

Network elements and interfaces 52Dependencies 54Limitations 54

3.4. Handover Regarding Traffic Load design 55Network elements and interfaces 55Dependencies 57Limitations 57Effect of implementation 57

APPENDIX A. PARAMETER VALUES 59

Queuing parameters 60BTS object 60BSC object 60MSC software 60PRIORITY information element (GSM 08.08) 61

Directed re-try parameters 62OMC software 62BSC object 62Handover object 63BTS object 63MSC software 64

Pre-emption parameters 65PRIORITY information element (GSM 08.08) 65

Handover Regarding Traffic Load parameters 66BTS object 66

APPENDIX B. FUTURE DEVELOPMENTS 67

Handover due to Traffic Load overview 67

LIST OF ACRONYMS 71

COMMENTS FORM 75

71

67

67

6666

6565

646363626262

6160606060

59

5757575555

545452


About this Guide

1


Issue 1.0 - July 1999 1

1. About this Guide

1.1. Purpose

This document describes the principal engineering implications of the design and deployment oftraffic load management techniques in GSM networks. It discusses load managementtechniques in relation to the following areas:

• Queuing

• Directed re-try

• Pre-emption

• Handover regarding traffic load

Because of the wide range of environments in which traffic load management techniques areused, and the differing operating priorities of each network operator, the choice of any particularimplementation technique is likely to be both network and customer specific. Thus this documentis intended only as a general reference guide to traffic load management techniques, and is nota substitute for the in-depth design process required for each specific implementation.



2 Issue 1.0 - July 1999

1.2. Contents

This document contains the following further chapters:

• Chapter 2 Introduction to Traffic Load Management

Provides an overview of the traffic management features available, their effect on networkcall handling, activation methods, and the benefits and drawbacks of each approach.

• Chapter 3 Traffic Load Management Design

Discusses design of the various available load management techniques and the impact ofeach technique on the main GSM network elements and in particular on the number of airinterface channels required. Also highlights any dependencies and limitations associatedwith a particular method, and describes the attribute settings that control each method.

• Appendix A Parameter Values

Describes the network parameters used to enable and configure traffic load management -how the parameters are set, the network elements to which they relate, and the allowableand default values for each one.

• Appendix B Future Developments

Summarises planned new developments that may be available in future releases.

1.3. Scope

For the purposes of this document, GSM traffic load management is defined as a method of re-distributing traffic (calls) made by subscribers to the GSM network so that network resources areused efficiently, and subscribers receive the best available grade of service appropriate to thepriority of their call.

Unless specifically stated to the contrary, this document describes features and facilities that areavailable to networks deployed using Lucent Network Release 8.x software.

1.4. Intended audience

This document is intended for use by the following groups:

• Engineers undertaking first-time design of traffic load management schemes

• Technicians seeking an appreciation of traffic load management design issues

• Sales or support staff

• Managers or administrative staff who need an overview of the technical design process



Issue 1.0 - July 1999 3

No prior knowledge of the following topics is required:

• GSM

• Advanced level mathematics

• RF design

1.5. Further reference

The following documents are recommended for additional reference information:

• GSM Recommendation 08.08 MSC - BSS Interface version 5.10.0

• Mobility Related Algorithms for GSM (Network Release 8.0)Lucent document no. qms.v50.20.800.101, Issue 01, dated 7/21/98

• MSC - BSC Timer for GSM Network Release 8.0Lucent document no. qms.v50.20.800.201, Issue 00, dated 12/11/97

• GSM Parameter Catalogue (PARCAT) Network Release 8.0

• BSS-2000 Network release 8.0 Network configuration guidelines

Note: Some of these documents are available only to Lucent personnel.



4 Issue 1.0 - July 1999

This page is intentionally left blank


Introduction to Traffic LoadManagement

2


Issue 1.0 - July 1999 5

2. Introduction to Traffic LoadManagement

This chapter describes the main concepts of traffic load management techniques and theirimplementation in GSM.

2.1. Background

Traffic management schemes are continuing to grow in popularity as network operators deploythem to:

• Increase usage of their existing network infrastructure

• Provide a temporary increase in network capacity when localised overload occurs

• Ensure that high priority and emergency service calls are served as rapidly as possible

• Improve the general grade of service offered to subscribers

• Enhance spectrum efficiency, and minimise associated channel rental costs

• Improve network resilience



6 Issue 1.0 - July 1999

2.2. Key benefits

Traffic load management yields a number of benefits for the PTO (Public TelecommunicationsOperator), the subscriber, and the regulatory authority (which usually represents the publicinterest). The key benefits are listed below:

Benefits for PTOs

• Reduced number of radio channels required to serve given traffic, resulting in:

− Reduced RF channel rental cost

− Reduced base station equipment requirements with associated reduction inequipment room space, power, and maintenance costs

• Improved control of network performance and stability when overloaded

• For existing networks, improved grade of service offered and hence improvedcompetitiveness in the market

• Improved subscriber satisfaction

• Ability to offer different grades of service

• Premium pricing for high grades of service

Benefits for subscribers

• Improved service and choice

• Improved emergency call access

• Potential reductions in call costs if some of the PTO’s efficiency gains are passed on to thesubscribers (this will usually depend on the regulatory authority)

Benefits for regulatory authorities

• Improved efficiency of RF spectrum use

• RF spectrum capacity for more PTOs

• Greater choice for subscribers

• Increased PTO efficiency and/or competition allows more scope for reducing call costs



Issue 1.0 - July 1999 7

2.3. Traffic load management methods

This section outlines the principal methods by which the traffic load can be managed in a GSMsystem. Most of these methods are generally available on GSM equipment:

• Queuing

• Directed re-try

• Pre-emption

In addition, Lucent equipment can also handover calls according to traffic load, by means of theHandover Regarding Traffic Load feature.

Each traffic management method is described in the following sections.

Queuing

Queuing can be used when a call is requested in a cell that has no free traffic channels. Insteadof applying a ‘busy’ tone, the call is queued for a predefined time in the BSC in case a trafficchannel becomes available.

Queuing is a network feature that requires support from both the BSC (Base Station Controller)and the MSC (Mobile Switching Centre).

Mandatory and power budget handovers of queued TCH (Traffic Channel) requests are possibleif the appropriate handover conditions are met.

Operation

Each cell is fitted with a fixed number of radio transceivers, which in turn support a finite numberof traffic channels.

When all radio channels available at a cell are busy, incoming traffic channel requests arequeued within the serving BSC for a predefined period of time. During this time, if a trafficchannel with parameters matching one of the queued requests becomes free, the queued trafficchannel request will be served.

The basic signal flow during the assignment queuing process is shown in the following figure:



8 Issue 1.0 - July 1999

Figure 1 Signal flow during assignment request queuing

Note: For a description of the Tn and TRRn timers mentioned in Figure 1, refer to Appendix A.

Queuing can be used in conjunction with directed re-try, as once the queuing time has expired adirected re-try may be attempted.

Both traffic channel assignment requests and external MSC-controlled handover requests can bequeued. When an internal BSC-controlled handover is required, traffic channel assignmentrequests cannot be queued directly. Under these circumstances, the BSC requests an externalhandover from the serving MSC (these handover requests can be queued).



Issue 1.0 - July 1999 9

The signal flow associated with inter-BSC / intra-MSC handover request queuing is shown in thefollowing figure:

Figure 2 Signal flow during inter-BSC / intra-MSC handover request queuing

Notes:

For a description of the Tn and TRRn timers mentioned in Figure 2, refer to Appendix A.

Queuing can be used with existing Lucent hardware without any modification, and requiresLucent network software version 8.x.



10 Issue 1.0 - July 1999

Impact on network elements

This section describes the effect of queuing on the following network elements:

• OMC (Lucent Technologies Operations and Maintenance Centre 2000)

• BSC

• MSC

OMC

The queuing feature is a sales option for the OMC. Queue lengths can be adjusted via the OMCon a per BTS (Base Transceiver Station) basis. A queue length of zero disables queuing for agiven cell.

The queuing values for the network can be set from the OMC terminal. Note that if the value forthe queuing timer is changed, then the new value is only applied to new entries in the queuingtable (mobiles already in the queue are not affected).

BSC

Once queuing is activated by the BSC for a cell, it remains active until all traffic channel requeststhat cannot be immediately served (owing to lack of free traffic channels with matchingparameters) are either served or exceed the maximum queuing time.

Each cell has only one queue. All traffic channels requests are entered in that queue, regardlessof whether the requested traffic channel is for an assignment or for handover.

For any traffic channel request, queuing is explicitly either allowed or forbidden, and is based onthe priority levels defined in GSM Recommendation 08.08.

The information element PRIORITY in the received message ASSIGNMENT_REQUEST orHANDOVER_REQUEST indicates the priority and the allowed queuing for the call.

Queue entries are executed in the following sequence:

• Traffic channel requests with higher priority are served first

• Traffic channel requests with the same priority are served on a FIFO (first-in-first-out) basisaccording to their time of arrival

• When a queued traffic channel request is served, the corresponding entry is removed fromthe queue

• When all queue places are occupied, the entry in the last queue position is replaced if ahigher priority traffic channel request is received. If possible a directed re-try is performed,otherwise the “dequeued” entry is deleted



Issue 1.0 - July 1999 11

The time that any traffic channel request is held in the queue is limited by the maximum value setfor either of the following timers:

• Timer T11 defines the maximum time an incoming assignment request is queued

• Timer T_qho defines the maximum time an incoming handover request is queued

If the relevant timer expires for a particular queue entry, it is removed from the queue. The entryis either discarded, or a directed re-try handover is requested.

For more information about the T11 and T_qho timers, refer to Appendix A.

MSC

If the BSC initiates a traffic channel request in response to an ASSIGNMENT_REQUEST orHANDOVER_REQUEST message, then if no suitable traffic channels are available, and queuing isenabled, the BSC sends a QUEUING_INDICATION message to the serving MSC.

When a queued traffic channel request is served, an ASSIGNMENT_COMPLETE or aHANDOVER_REQUEST_ACK message (according to the request type) is sent to the MSC.

If queuing is not allowed for any reason, or a queue entry is deleted owing to receipt of a higherpriority request, an ASSIGNMENT_FAILURE or HANDOVER_FAILURE message (according to therequest type) with cause NO RADIO RESOURCES AVAILABLE is sent to the MSC.

If a traffic channel request is deleted because it times out on the queue, an ASSIGNMENT_FAILURE

or HANDOVER_FAILURE message (according to the request type) with cause NO RADIO RESOURCES

AVAILABLE is sent to the MSC.

If invocation of MSC-controlled directed re-try is possible, an ASSIGNMENT_FAILURE messagefollowed by a HANDOVER_REQUIRED message, both with cause DIRECTED_RETRY, are sent to theserving MSC.

Effect

Traffic channel requests occur in the later stages of the call establishment procedure. So if notraffic channels are free at the instant the request is issued, significant network resources arewasted when the call attempt is terminated.

The queuing feature allows the traffic channel request to be placed in a queue, from which it canbe served when a traffic channel becomes available, instead of immediately abandoning the callattempt. From the customers’ viewpoint, it allows calls to be connected when a network isnearing saturation rather than presenting busy signals.

The queuing facility can be particularly useful when traffic load is rapidly changing, and where acell has few traffic channels available.

It is generally considered that the increased traffic load capacity of a cell using queuing can becalculated from the ‘Erlang-C’ formula.



12 Issue 1.0 - July 1999

Advantages

• No new base stations or hardware required (queuing is a purely software-based solutionwithin the BSC and does not impact the BTSs)

• Greater use of installed equipment

• Subscribers receive fewer busy signals (which would otherwise require them to re-dial thenumber, thus increasing the signalling load)

• Does not depend on the location of the mobiles

• Interference-free overlapping cells are not required

• Available for sale as an optional additional feature

Disadvantages

• Greater length of time required for the call setup phase

• Requires software support from the BSC and MSC



Issue 1.0 - July 1999 13

Directed re-try

Directed re-try (SDCCH - Standalone Dedicated Control Channel - to TCH handover) can beused when a call is requested in a cell that has no free traffic channels. Instead of releasing thesubscriber, an alternative cell with free traffic channels can be chosen and the mobile callhanded over to a traffic channel in that cell.

Directed re-try is designed to alleviate temporary cell overload situations. It is not a means toincrease general wide area network traffic capacity.

In order to implement full directed re-try functionality, both the BSC and the MSC must support it.

Important: Directed re-try should be implemented in conjunction with the queuing feature. Ifqueuing is not used, then directed re-try may be attempted before an accurate list of alternativeneighbour target cells for the re-try has been compiled. Directed re-try may fail if insufficientneighbour cell measurements have been made.

Operation

As directed re-try uses existing handover mechanisms, it can be used in the following scenarios:

• BSC-controlled (intra-BSC / intra-MSC) directed re-try

• Inter-BSC / intra-MSC directed re-try

• Inter-BSC / inter-MSC directed re-try

Each scenario is described in the following sections:



14 Issue 1.0 - July 1999

BSC-controlled (intra-BSC / intra-MSC)

This allows handover of a mobile from a SDCCH at a congested cell to a free traffic channel atanother cell, when both cells are controlled from the same BSC linked to the same MSC.

This is a BSC-controlled directed re-try. The signalling flow for this (with queuing) is shown in thefollowing figure:

Figure 3 Signal flow - BSC-controlled directed re-try with queuing




Issue 1.0 - July 1999 15

Inter-BSC / intra-MSC

This allows the handover of a mobile from a SDCCH at a congested cell controlled by one BSC,to a free traffic channel at cell controlled from a second BSC, when both BSCs are served by thesame MSC.

This is a MSC-controlled directed re-try. The signalling flow (with queuing) is shown in thefollowing figure:

Figure 4 Signal flow - MSC-controlled directed re-try with queuing


Inter-BSC / inter-MSC

This allows the handover of a mobile from a SDCCH at a congested cell controlled by one BSC,to a free traffic channel at a cell controlled from another BSC which is in turn controlled by adifferent MSC.

This is also an MSC-controlled directed re-try.



16 Issue 1.0 - July 1999

Directed re-try handover conditions

The basis of directed re-try is the special handover case from an SDCCH to a TCH.

The MSC issues an ASSIGNMENT_REQUEST to assign a TCH. Under the following conditions, theASSIGNMENT_REQUEST triggers an SDCCH to TCH inter-cell handover (directed re-try):

1. SDCCH to TCH handover is enabled by the EN_SDCCH_TCH_HO flag

and all serving cell TCHs are busy

and queuing of TCH assignment requests is allowed

2. A TCH request is being queued (queuing indicator set to ‘true’)

and any of the following conditions exist:

− mandatory or power budget handover is required

− maximum permitted queuing time has expired

− the relevant TCH ASSIGNMENT_REQUEST is displaced by a higher priority request

In the case of MSC-controlled directed re-try, the BSC sends an ASSIGNMENT_FAILURE messagewith cause DIRECTED_RETRY and a HANDOVER_REQUIRED with cause DIRECTED_RETRY to theserving MSC.

Following a successful BSS-controlled directed re-try, the BSS sends an ASSIGNMENT_COMPLETE

message back to the MSC.

Activating directed re-try

Support of the SDCCH to TCH handover is controlled as a sales option (DIR_RETRY_CONTROL

attribute). The value is set in the Local Configuration Area of the BSC. (This is not a user-adjustable value, and cannot be set via the OMC terminal.)

If the DIR_RETRY_CONTROL setting permits SDCCH to TCH handover within the BSC, the SDCCHto TCH handover can be enabled or disabled for each cell controlled by the BSC. This is donevia the EN_SDCCH_TCH_HO flag, which can be set at the OMC terminal on a cell-by-cell basis.

Directed re-try averaging

If a SDCCH to TCH handover is requested for reasons other than radio link conditions (forexample, the queuing time has expired), the averaging period for the neighbour cellmeasurements is changed as follows:

• Provided that the neighbour cell averaging window is not completely filled with new reportedmeasurement results, the averaged measurement results (AV_RXLEV_NCELL_S(i)) arecalculated from the number of measurement values that have been shifted into the



Issue 1.0 - July 1999 17

measurement window. Thus, the currently received and the preceding measurements areused

• Leading zeros (pre-loaded) in the averaging window are not used in the calculation, unlessthe averaging window has already been filled once

Directed re-try execution and target cell selection

Directed re-try (whether MSC-controlled or BSC-controlled) is only performed when radioresources are available in the target cell. Thus directed re-try is not allowed if there is trafficchannel congestion in the target cell.

When a SDCCH to TCH handover is requested, the following execution and target cell selectionprocedure is followed.

Each time a handover is required, a list of preferred target cells (Preferred Target Cell List) is setup for the handover.

The length of this list is set by the value assigned to n(N_TARGET_CELL) which defines themaximum number of preferred target cells which may be included in the HANDOVER_REQUIRED

message sent from the BSC to the MSC. Values from 0 to 16 may be used, but we do notrecommend using a value greater than 6 (the default). This is because the mobile only makes upto 6 measurements from the strongest neighbour cells, so the probability of having measurementresults from more than 6 neighbours is low.

Entry conditions

All neighbour cells have to fulfil certain entry conditions to be considered as candidates forhandover (that is, to be placed in the Preferred Target Cell List). The specific conditions dependon the cause of the handover.

For handover caused by directed re-try, the bookkeeping list is searched for all registeredneighbour cells (i) which meet the following condition:

AV_RXLEV_NCELL_S(i) > RXLEV_MIN(i) + 2 * [(Max (0, P - MS_TXPWR_MAX(i))]

Where:

AV_RXLEV_NCELL_S(i) is the received signal level from the neighbour cells, averagedaccording to the general averaging technique, over the averaging period A_LEV_NC.

RXLEV_MIN(i) defines the minimum received BCCH signal levels from the neighbour cells(i), which must be reached before a mobile will be allowed to handover to the cell.

The average received signal level in neighbour cells (i), AV_RXLEV_NCELL(i) must begreater than RXLEV_MIN(i) plus the difference (if the value is > 0) between the power class‘P’ of the mobile, and the maximum allowed mobile transmit power in the neighbouringcells (i).



18 Issue 1.0 - July 1999

Ranking

Once neighbour cells have qualified as potential handover target cells, they must be ranked inorder of priority for selection as the handover cell. Potential target cells are first ranked by celllayer. Within the same layer, they are then ranked according to power budget and finally (if theHandover Regarding Traffic Load Feature is enabled) by traffic load.

For more information about cell selection entry conditions and ranking criteria, refer to theHandover Regarding Traffic Load section.

The target cell with the highest priority determines whether a BSC-controlled handover or aMSC-controlled handover takes place. If the target cell with the highest priority is controlled bythe same BSC as the serving cell, a BSC-controlled handover is initiated.

If a BSC-controlled directed re-try attempt to the highest priority target cell is unsuccessful, thenan attempt is made to the second priority target cell. If this attempt is also unsuccessful, then theprocess is repeated through the Preferred Target Cell List.

As the BSC knows which internal BSS cells have free traffic channels, it only attempts a BSC-controlled directed re-try handover to internal BSS cells with free traffic channels.

If the BSC-controlled SDCCH to TCH handover request is rejected by all BSS internal cells witha higher priority in the Preferred Target Cell List than the first target cell of a neighbouring BSS,the MSC becomes responsible for the handover. In this case the Preferred Target Cell List issent to the MSC.

The MSC sends a handover request to the BSC responsible for the next highest priority cell inthe Target Cell List. If this BSC rejects the handover request, the MSC can repeat the request tothe BSC serving the next highest priority cell in the Preferred Target Cell List. This procedurecan be repeated until all the Preferred Target Cells have been tried.

If no free traffic channels can be found in any of the cells in the Preferred Target Cell List, thedirected re-try handover request is rejected, resulting in the subscriber receiving a busy signal.

Effect

Directed re-try allows call setups to be served when a network is nearing saturation, rather thanpresenting a busy signal to the subscriber. This facility can be particularly useful when thedistribution of traffic is mobile and unevenly loaded (that is, one cell is heavily loaded but itsneighbour cells are not).

The signalling traffic and load carried by the network will increase, as will utilisation of theexisting network infrastructure, and subscribers will receive an improved grade of service.

The improvement in traffic carried is difficult to quantify, as it depends on the specific networkimplementation and grade of service offered. However, research indicates that for a networkdesigned to offer a 2% grade of service, with 2 transceivers per cell, and provided sufficientcandidate cells with spare channels are available, blocking may be reduced by approximately 2%for traffic moving at slow and medium speeds.



Issue 1.0 - July 1999 19

Advantages

• Capacity gain of approximately 2% (for slow and medium speed traffic)

• No new base stations or hardware required

• Improved spectrum efficiency through increased use of available frequencies


• Subscribers receive fewer busy signals, and perceive a reduction in blocking

• Available for sale as an optional additional feature

Disadvantages

• Cells with free channels in interference-free overlapping coverage areas are required (soonly slow moving mobiles will benefit)

• Length of neighbour cell lists is increased

• Only applicable to areas of uneven traffic distribution

• Cannot be selectively supplied to subscribers or user groups

• Inter-BSS directed re-try requires support for queuing and directed re-try in the MSC. Evenfor intra-BSS directed re-try, support for queuing in the MSC is required

• Careful selection and investigation of ‘hot spots’ is required

• Higher handover rate

• Increased risk of lost calls

• For any particular call, the best (most appropriate) server cell may not be used. This maycause:

− Reduced radio link quality (for example, increased bit error rates)

− Increased co-channel interference, as a higher transmit power may be necessaryto maintain the connection

− Increased ‘ping-pong’ (unnecessary handover events). This can be minimised bysetting higher parameter values for handover margin areas



20 Issue 1.0 - July 1999

Pre-emption

The pre-emption facility can be used to allocate a traffic channel even when all available trafficchannels in the serving cell are busy. This is achieved by pre-empting an existing call in servicein order to allow a pre-empting call to be served.

This facility only applies to traffic channels that are allocated by means of theASSIGNMENT_REQUEST command. Traffic channel requests owing to a handover by means of theHANDOVER_REQUEST command do not invoke the pre-emption facility.

The pre-emption facility is often used to improve the chance that high priority calls (for example,to emergency services) are successfully established, even under high traffic load conditions.

Note that although the pre-emption facility is normally used for emergency services calls, itshould not be confused with the GSM Teleservice 12 Emergency Calls facility which is aseparate facility.

Operation

When a new call is to be established and a traffic channel is required, the MSC issues theserving BSC an ASSIGNMENT_REQUEST message which informs the BSC of the pre-emptionattributes. These determine whether the new call:

• May pre-empt an existing call (PCI)

• May itself be pre-empted (PVI)

On receipt of the ASSIGNMENT_REQUEST the BSC reads the Pre-emption Capability Indicator(PCI) flag. If this flag is set, the BSC may pre-empt an existing traffic channel assignment inorder to serve the new assignment request.

If the PCI flag is set, and the serving cell has no free traffic channels, the BSC searches theexisting traffic channel assignments for one that can be pre-empted (that is, its Pre-emptionVulnerability Indicator (PVI) flag is set). If the BSC finds such an assignment, it terminates theexisting assignment and reassigns the relinquished traffic channel to the pre-empting call.

A traffic channel assignment request with the PCI flag set will bypass any existing queued trafficchannel assignment requests.

If the BSC cannot find an existing assignment that can be pre-empted, the new assignmentrequest will be queued according to the priority level specified in the ASSIGNMENT_REQUEST

message. Once an assignment request is entered into the queue, it is treated as a normal TCHrequest and is no longer able to pre-empt an existing assignment, even though it has the PCIflag set.

If the serving cell has free traffic channels available, the normal channel assignment process isfollowed.

Note: When a SDCCH is requested, pre-emption is not performed.



Issue 1.0 - July 1999 21

Activation

The pre-emption facility is a sales option, which is enabled by setting the PREEMTION_PROVIDED

flag in the BSC software Local Configuration Area. This flag can only be set by Lucent andcannot be changed subsequently.

A new version of BSC software must be loaded in order to switch pre-emption on at a BSC thatdoes not already have it enabled.

Effect

The pre-emption facility can be used to improve the chance that high priority calls aresuccessfully established, even under conditions of high traffic load (provided that the priority callsare deemed sufficiently important to allow existing calls to be dropped).

Advantages

• Top priority calls are given priority over existing calls

• Possibility of levying premium charging rates for pre-emption service

Disadvantages

• Existing calls are terminated when pre-emption is invoked. The numbers of calls capable ofpre-emption should be minimised to avoid unacceptable service levels to other users

• Long term management of calls capable of pre-emption is required



22 Issue 1.0 - July 1999

Handover Regarding Traffic Load

The Handover Regarding Traffic Load (HORTL) feature is designed to improve the peak traffichandling capability of a group of cells which have some interference-free overlapping coverage,and are all linked to the same BSC. This is achieved by assessing traffic loads in neighbouringcells when ranking neighbour target cells for handover.

HORTL is intended to assist with temporary cell overload situations - it is not a means toincrease general wide area network traffic capacity.

Note: The HORTL facility is only used when a handover is requested for radio resourcemanagement reasons; it can not actually invoke a handover itself.

Operation

All neighbour cells have to fulfil certain entry conditions to be considered as candidates forhandover (that is, to be placed in the Preferred Target Cell List). The specific conditions dependon the cause of the handover.

The Preferred Target Cell List is ranked according to:

• Cell Layer

The Serving Cell Type algorithm in use determines the target cell layer

• Power Budget

The Preferred Target Cell List is arranged in decreasing order of priority according to thevalue of ORDER_TC(i). This is calculated as follows:

ORDER_TC(i) = AV_RXLEV_NC(S(i) + [MS_TXPWR_MAX(i) – MS_TXPWR_MAX] * 2 – HO_MARGIN(0,i)

The higher the value of ORDER_TC(i) the higher the priority of the target cell. The lower thevalue of ORDER_TC(i) the lower the priority of the respective neighbour cell (i) in the HandoverTarget Cell List

When Handover Regarding Traffic Load is enabled, the expression ORDER_TC(i) is replacedby the ORDER(i) calculation, which is used to determine the priority of the respective cell (i) inthe Preferred Target Cell List.

Note: Setting the power budget handover enable flag EN_PBGT_HO (which enables powerbudget evaluation in the handover threshold comparison process) does not affect generationof the Preferred Target Cell List.

• Traffic Load

Traffic load is only taken into account if all the following circumstances apply:

− The neighbour and serving cell are controlled by the same BSC



Issue 1.0 - July 1999 23

− Handover Regarding Traffic Load is enabled

− A SDCCH to TCH, or TCH to TCH handover is required

Handover Regarding Traffic Load can be enabled or disabled for each cell from the OMCterminal via the EN_LOAD_REGARD flag.

When Handover Regarding Traffic Load is enabled, the list of preferred target cells is evaluatedbased on the Power Budget calculation (described in the previous section), and is extendedaccording to the following expression:

ORDER(n) = ORDER_TC(i) + LINKfactor(o,n) + FREEfactor_X(n)

Where:

FREEfactor_X(n) is a value added to the ORDER_TC(i) to encourage the use of lightly loadedcells.

Five FREEfactor_X(n) values, (‘X’ takes the range 1 to 5), are assigned to each neighbourcell according to the number of free channels it can have, (by reference to five bands ofpossible free channels called FREElevel_X(n)). According to the number of free channels ithas at any instant, one of the five FREEfactor_X(n) values is used for the ORDER(n)

calculation.

If traffic load information for a neighbour cell is not available in the serving cell (forexample, the server and neighbour cell is not controlled by the same BSC) then thedefault value of FREEfactor(n) = 0 is used.

LINKfactor(o,n) is used to influence traffic flow to the neighbour cells.

Figure 5 Relation between FREElevels and FREEfactors for traffic load ranking



24 Issue 1.0 - July 1999

The optimal ORDER(n) calculation is given by the expression:

ORDER(n) = ORDER_TC(i) + LINKfactor(o,n) + [FREEfactor_X(n)]

The traffic load sort criterion is based on adding an offset to the power budget calculation.

The number of free traffic channels for each neighbour cell determines the magnitude of theoffset. For simplicity, instead of applying a different offset for every number of free channels, amaximum of five different values of offset is used, based on five bands of free channels. Channelbands and power budget offset values are described in the Handover Regarding Traffic Loadsection in Chapter 3, and in Appendix A.

To apply the correct power budget offset to each neighbour cell when ranking the neighbour cellhandover target cell list, the BSC is advised in which band of free channels each BTS isoperating. This traffic load information is sent from each BTS to the controlling BSC periodically,at an update interval set by the value assigned to TL_UPDATE_INT.

If traffic load information is not available for a particular neighbour cell, a default value of zero isused (this cannot be changed via the OMC terminal).

Activation

HORTL is a BSS-controlled facility, and is available as a sales option with GSM software version8.x.

Note: This option must be registered in the BSS Software Local Configuration area when theBSS software is compiled. Accordingly, customers need to decide when they order the BSSsoftware, whether they want the HORTL facility to be available.

HORTL may be enabled on a per-BSS basis, either in part or in all of the PLMN. However, it isnot supported between cells connected to different BSCs.

HORTL is activated by:

• Setting the flag EN_LOAD_REGARD

• Assigning values to each of the free channel bands (FREElevel_1 to FREElevel_4)

• Assigning values to each of the power budget calculation offsets (FREEfactor_1 toFREEfactor_5). One of these is applied according to which of the free channel bands cover theactual number of free channels of the neighbour cell

These settings are described in more detail in Appendix A.

Effect

The HORTL facility attempts to share the load resulting from temporary traffic peaks (whichcould otherwise overload a particular cell) amongst surrounding cells that are less heavilyloaded.



Issue 1.0 - July 1999 25

This allows more calls to be carried within a given section of the network, thereby improving thegrade of service available to subscribers and optimising use of radio resources.

Advantages

• Capacity gains will depend on traffic distribution in relation to the area of overlappinginterference-free coverage. Any overall network capacity gain will be significantly less thanthe local capacity gain

• Reduction in network blocking - subscribers receive fewer busy signals

• Effect depends on the location of the mobiles

• No new base stations or hardware required

• Improved spectrum efficiency through increased use of available frequencies


Disadvantages

• Cells with interference-free overlapping coverage areas are required

• Length of neighbour cell lists is increased

• Only applicable to areas of uneven traffic distribution

• Higher rates of handover

• For any particular call, the best (most appropriate) server cell may not be used. This maycause:

− Reduced radio link quality (for example, increased bit error rates)

− Increased co-channel interference, as a higher transmit power may be necessaryto maintain the connection

− Increased ping-pong (unnecessary handover events). This can be minimised bysetting higher parameter values for handover margin areas



26 Issue 1.0 - July 1999



Traffic Load ManagementDesign

3


Issue 1.0 - July 1999 27

3. Traffic Load Management Design

This chapter describes each traffic management feature and highlights the major designimplications associated with each one.



28 Issue 1.0 - July 1999

3.1. Queuing design

The use of queuing increases the proportion of initiated calls that are successfully connected.This both improves network efficiency and provides subscribers with an improved grade ofservice.

If queuing was not available, and the subscriber’s call was blocked, it is likely that they wouldattempt to make the call later, thereby unnecessarily using a dedicated signalling channel andassociated network transmission and processing resources.

Network elements and interfaces

Implementation of queuing affects the network elements and interfaces listed below:

Network elements

Element OMC MSC STF BSC BTS Mobile

Software Yes Yes No Yes No No

Hardware No No No No No No

Network interfaces

Interface OMC-BSC MSC-MSC(E)

MSC-BSC(A)

STF-BSC(M)

BSC-BTS(Abis)

Air(Um)

Software Yes No Yes No No No


Queuing is available with GSM software version 8.x.



Issue 1.0 - July 1999 29

BTS Object

The BTS object values used by the queuing facility are set via the OMC terminal, and are brieflyoutlined below.

TOTAL_NUM_Q_PLACE_AVAIL

Traffic channel assignments and handover requests may be queued in the BSS. The samequeue is used for both, and the value assigned to TOTAL_NUM_Q_PLACE_AVAIL defines themaximum length of the queue. When this value is set to 0, queuing is disabled.

Q_THRESHOLD_VAL

Traffic channel assignments and handover requests may be queued in the BSS.

The value Q_THRESHOLD_VAL defines a threshold in terms of the percentage of maximum queueentries. This threshold is used for performance measurement purposes.

For more details about these settings, refer to Appendix A.

BSC Object

The BSS MAP timers used by the queuing process are set via the OMC terminal, and are brieflyoutlined below.

T11 Queuing Timer

When the MSC issues an ASSIGNMENT_REQUEST message, and the serving cell has no availabletraffic channels, the ASSIGNMENT_REQUEST message is put into a queue, timer T11 is started, anda QUEUING_INDICATION message is returned to the MSC.

The ASSIGNMENT_REQUEST queuing can be terminated by either a successful, or unsuccessful,assignment of the requested traffic channel, resulting in either an ASSIGNMENT_COMPLETE orASSIGNMENT_FAILURE message from the BSS to the MSC (i.e. the ASSIGNMENT_REQUEST isremoved from the queue).

If T11 is set too low, the possibility to serve mobiles even within a short time of receiving theirASSIGNMENT_REQUEST is lost, resulting in a degradation of the grade of service. If T11 is set toohigh, the subscriber may tire of waiting and repeat the call, causing dissatisfaction andunnecessary signalling.

T_qho Handover Resource Allocation Queue Guard Timer

T_qho defines the maximum time for which a handover request is queued. If aHANDOVER_REQUEST message is received and there are no free traffic channels available, theHANDOVER_REQUEST is put into a queue, timer T_qho is started, and a QUEUING_INDICATION

message returned to the MSC.

The handover queuing procedure is ended by either a successful or unsuccessful reservation ofthe required traffic channel by sending to the MSC a HANDOVER_REQUEST_ACKNOWLEDGE or a



30 Issue 1.0 - July 1999

HANDOVER_FAILURE message respectively (i.e. the HANDOVER_REQUEST is removed from thequeue).

If the value for T_qho is set too low, the opportunity to serve handover requests within a shortqueue time is lost. If the value is too high, calls may be dropped as alternative handovercandidates cannot be tried.


Queuing based on call type

Queuing requires support from both the MSC and BSC software.

The call types which the network should queue are specified via the ‘Wireless MiscellaneousParameters’ sub-menu of the ‘Recent Changes Manual’ menu of the MSC maintenance PCsoftware.

MSC software

The MSC-related flags and timers associated with directed re-try are outlined below.

BSS_QUEUING_ALLOWED

This flag is used to enable BSS queuing.

QUEUING (for 5ESS®)

This specifies the BSS queuing timer. The timer starts when a QUEUING_INDICATION message isreceived from the BSC and stops after receiving an ASSIGNMENT_COMPLETE orASSIGNMENT_FAILURE message from the BSC. On time-out, the MSC issues a CLEAR_COMMAND tothe BSC.

If the QUEUING value is set too small, calls will be dropped owing to MSC pre-emption. If thevalue is too large, unnecessary resources will be used if the mobile fails to seize the ‘new’ trafficchannel and does not revert to the ‘old’ channel, and the BSS fails to send the CLEAR_REQUEST.

ASSIGN (for 5ESS®) or Trr1 (for T-Mobil) Assignment Guard Timer

This timer starts after sending ASSIGNMENT_REQUEST to the BSC and stops after:

• receiving ASSIGNMENT_COMPLETE from the BSC, or

• receiving CLEAR_REQUEST from the BSC, or

• receiving QUEUING_INDICATION from the BSS (MSC starts queuing timer).

On time-out, the call is released by issuing a CLEAR_COMMAND.



Issue 1.0 - July 1999 31

If the value set for ASSIGN is too small, the call success rate will fall. If the value set for ASSIGN istoo large, unnecessary resources will be used if the mobile fails to seize the traffic channel, andthe BSC fails to send the CLEAR_REQUEST.


PRIORITY information element (GSM 08.08)

GSM allows 14 priority levels allowed during traffic channel assignment. The assigned prioritylevel is passed to the BSS in the information element PRIORITY, and is used to determine how thecall request is queued. Use of the PRIORITY information element is described in section 3.2.2.18of GSM Technical Specification 08.08.

The PRIORITY information element has the following fields:

• Pre-emption Capability Indicator (PCI)A flag that indicates whether a traffic channel request can pre-empt an established call.

• Pre-emption Vulnerability Indicator (PVI)A flag that indicates whether a traffic channel request can be pre-empted by anotherassignment.

• Queuing Allowed Indicator (QA)A flag that indicates whether queuing is allowed for a traffic channel request.

• Priority LevelAssigns 14 levels of priority to the assignment request.

In the process of a traffic channel assignment, a BSS may possess all, or a sub-set, of the aboveparameters (depending on the BSS features that are activated).

The MSC populates the PRIORITY information element based on data entered by the user in theMSC configuration. The PRIORITY information element is then included in theASSIGNMENT_REQUEST and HANDOVER_REQUIRED messages initiated by the MSC.

When the BSS places the traffic channel request into the queue it informs the MSC via theQUEUING_INDICATION message.

For more details about PRIORITY settings, refer to Appendix A.



32 Issue 1.0 - July 1999

Dependencies

To implement queuing satisfactorily, the following dependencies should be observed:

• BSC support for queuing is a necessary but insufficient condition for queuing

• The network operator must assign appropriate priorities

• MSC software support is also necessary (the Lucent switch supports queuing)

• ASSIGN (MSC ‘Assignment Guard’ Timer) > T10 (BSC Assignment Guard Timer for ‘Old’Channel)

• QUEUING (MSC ‘BSS Queuing’ Timer) > T11 (BSC ‘Queuing Guard’ Timer)

Effect of implementation

When considering the deployment of queuing the following factors should be analysed:

• Congestion performance indicators

• Cell size and number of TRXs may help to indicate the appropriate queue length

Traffic data

To assess the impact of activating queuing, the performance indicators listed below should bemonitored on a cell-by-cell basis, both within the deployment area, and in surrounding cells. Thisinformation can be used to compare the results obtained with queuing under different networktraffic loads:

• Busy hour (the hour with the largest value for traffic channel use)

• Traffic channel seizure attempts

• Traffic channel seizures

• Traffic channel seizure blocks

• Traffic channel blocking (percentage)

• Traffic channel traffic (Erlang)

• Traffic channel mean holding time

• SDCCH seizures

• SDCCH seizure blocks

• SDCCH blocking (percentage)



Issue 1.0 - July 1999 33

• SDCCH traffic (Erlang)

• SDCCH mean holding time (approximate call queuing time)

The above data should be recorded during the busy hour, and repeated on a daily basis in orderto monitor long term satisfactory performance.



34 Issue 1.0 - July 1999

3.2. Directed re-try design

Directed re-try increases the proportion of initiated calls that are successfully connected. Thisboth improves network efficiency, and provides subscribers with an improved grade of service.

If directed re-try was not available, and the subscriber’s call was blocked, it is likely that theywould attempt to make the call later, thereby unnecessarily using a dedicated signalling channeland network transmission and processing resources.

Successful use of directed re-try requires interference-free overlapping cell coverage areasbetween the overloaded cell and the next neighbour cell with free resources. If a call is re-directed to a cell that does not meet this criterion, then the following may occur:

• The re-directed subscriber may experience unsatisfactory call quality

• General co-channel interference levels will rise, compromising call quality for subscribers inthe neighbourhood

Mobile support

Some Phase 1 mobiles do not support handover from a SDCCH on one cell to a TCH on adifferent cell, as the CHANNEL_MODIFY command within a handover is not available. Additionally,some mobiles do not support frequency hopping SDCCH channels, and therefore the allocationof SDCCH to frequency hopping timeslots should be avoided.

Therefore, some Phase 1 mobiles do not support directed re-try. However, it is unlikely thatmany of these mobiles are still in use.

Phase 2 mobiles do support directed re-try.



Issue 1.0 - July 1999 35


Implementation of directed re-try affects the network elements and interfaces listed below:

Network element




Network interface


MSC-BSC(A)

STF-BSC(M)

BSC-BTS(Abis)

Air(Um)

Software Yes Yes Yes No No No


Complete directed re-try functionality is available with GSM software version 8.x, and with thefollowing element software versions (or higher):

OMC MSC BCE BCF

R4.0 10.1 lpr8.0 LM4.0 R1.0

When directed re-try is deployed, the following network elements are affected:

OMC software

Directed re-try is enabled (and disabled) via the OMC by setting the EN_SDCCH_TCH_HO flag totrue. This is a necessary, but not sufficient, condition.

For this flag to be effective, directed re-try must also be activated for each BSC concerned, bysetting the appropriate values in their Local Configuration Areas (refer to the following section).

BSC Object

The BSS MAP timers used by the directed re-try process are set via the OMC terminal, and arebriefly outlined below.

T7 Handover Required Guard Timer



36 Issue 1.0 - July 1999

When the BSC detects that a handover is required, it issues a HANDOVER_REQUIRED message tothe MSC.

This message is repeated from the BSC to MSC, with the periodicity of T7, until:

• A HANDOVER_COMMAND message is received

• A reset message is received

• The reason for the handover disappears

• Communication with the mobile is lost

• The call is cleared

Timer values below 9s should be avoided, as the MSC is unable to perform a HandoverResource Allocation in a second target cell, if the first target cell fails. Timer values below 4s areimpractical, as the MSC is not able to complete the Handover Resource Allocation in the firsttarget cell.

If this timer value is set too low, the MSC load and ‘A’ interface message rate increasesunnecessarily. If the value is too high, calls may be dropped owing to increased delay inhandover when the MSC cannot allocate resources in a potential target cell.

T8 Handover Guard Timer in originating cell

When the MSC executes a handover, it issues a BSSMAP_HANDOVER_COMMAND message overthe BSSMAP link to the ‘old’ serving BSC, which has the existing link to the mobile. At the oldBSS, timer T8 is started on receipt of the BSSMAP_HANDOVER_COMMAND message. The old BSSthen sends a HANDOVER_COMMAND message over the air interface to the mobile, containing thehandover reference data for the ‘new’ BSS.

If a CLEAR_COMMAND (with cause Handover Complete) message from the MSC, or aHANDOVER_FAILURE from the mobile, is not received by the old BSS before T8 expires, the oldBSS requests the release of the dedicated radio resources with a CLEAR_REQUEST message tothe MSC.

If the value of T8 is too small, the resource in the originating cell will be released even if themobile has not completed the handover. In this case the mobile would not be able to revert to the‘old’ cell, and the handover call drop rate will rise. If T8 is too long, radio resources in theoriginating cell will be used unnecessarily, when (for example), the mobile neither seizes thetarget cell nor reverts to the old cell, Trr3 in the target cell has not expired, and Trr7 in the MSChas also not expired.

T10 Assignment guard Timer for ‘old’ channel

This timer begins when the BSS issues the ASSIGNMENT_COMMAND message (dedicatedassignment, old channel), and is normally stopped when the mobile has correctly seized the newchannel, (i.e. the ASSIGNMENT_COMPLETE message is received on the new channel from themobile.



Issue 1.0 - July 1999 37

The timer may also be stopped if an ASSIGNMENT_FAILURE is received on the old channel from themobile. The old channel is not released until either an ASSIGNMENT_COMPLETE message isreceived, or T10 expires. Thus the old channel is retained sufficiently long to enable the mobile toreturn to it if necessary (owing to handover failure). If the value assigned to T10 is too low, callsuccess rates will fall. Values less than 10s are not practical.

Excessively high values cause unnecessary use of SDCCH or originating traffic channels, whichcan increase blocking.

T11 Queuing Timer

When the MSC issues an ASSIGNMENT_REQUEST message, and the serving cell has no availabletraffic channels, the ASSIGNMENT_REQUEST message is put into a queue, timer T11 is started, anda QUEUING_INDICATION message is returned to the MSC.

The queuing of the ASSIGNMENT_REQUEST can be terminated by either a successful, orunsuccessful, assignment of the requested traffic channel, resulting in an ASSIGNMENT_COMPLETE

or ASSIGNMENT_FAILURE message from the BSS to the MSC (i.e. the ASSIGNMENT_REQUEST isremoved from the queue).

If timer T11 expires before a successful assignment has been made, and directed re-try isdisabled, the ASSIGNMENT_REQUEST message is removed from the queue, and a CLEAR_REQUEST

message is sent to the MSC, with cause ‘No Radio Resources Available’.

If timer T11 expires before a successful assignment has been made, and directed re-try isenabled, the directed re-try procedure is invoked by the BSS sending a HANDOVER_REQUIRED

message to the MSC with cause ‘Directed Re-try’.

Thus it should be noted that T11 must expire before a directed re-try can be attempted.

If T11 is set too low, the possibility to serve mobiles even within a short time of receiving theirASSIGNMENT_REQUEST is lost, resulting in a degradation of the grade of service. If T11 is too long,the subscriber may tire of waiting, and repeat the call, causing dissatisfaction and unnecessarysignalling.

T_qho Handover Resource Allocation Queue Guard Timer

T_qho defines the maximum time for which a handover request is queued.

If a HANDOVER_REQUEST message is received and there are no free traffic channels available, theHANDOVER_REQUEST is put into a queue, timer T_qho is started, and a QUEUING_INDICATION

message returned to the MSC.

The handover queuing procedure is ended by either a successful or unsuccessful reservation ofthe required traffic channel by sending to the MSC a HANDOVER_REQUEST_ACKNOWLEDGE or aHANDOVER_FAILURE message respectively (i.e. the HANDOVER_REQUEST is removed from thequeue).



38 Issue 1.0 - July 1999

If timer T_qho expires before a successful handover has been made, and directed re-try isdisabled, the HANDOVER_REQUEST message is removed from the queue, and aHANDOVER_FAILURE message is sent to the MSC, with cause ‘No Radio Resources Available’.

If timer T_qho expires before a successful handover has been made, and directed re-try isenabled, the directed re-try procedure is invoked by the BSS sending a HANDOVER_REQUIRED

message to the MSC with cause ‘Directed Re-try’.

So it should be noted that T_qho must expire before a directed re-try can be attempted.

If the value for T_qho is set too low, the opportunity to serve handover requests within a shortqueue time is lost. If the value is too high, calls may be dropped as alternative handovercandidates cannot be tried.

Trr3 Handover Guard Timer in the target cell

This determines the maximum time for which a HANDOVER_COMPLETE message is awaited,following the successful activation of a new channel. Trr3 is started on channel activation, andhalted on receipt of the HANDOVER_COMPLETE message.

When Trr3 expires, a CLEAR_REQUEST message is sent to the MSC.

If Trr3 is set too low, the number of calls that are dropped during handover will increase. If Trr3 istoo long, unnecessary radio resources may be used in the target cell, for example, if the mobiledoes not either seize the ‘new’ channel or revert to the old channel, and T8 in the originating BSSand Trr7 in the MSC not expiring.


Handover Object

The BSS Handover Object flags used by the directed re-try process are set via the OMCterminal, and are briefly outlined below.

EN_SDCCH_TCH_HO

When set to 1, this flag allows directed re-try.

EN_SDCCH_HO

This flag determines whether SDCCH to SDCCH handover is permitted. It is only meaningful ifinter-cell handover is enabled (controlled by flag EN_INTER_HO).

Handover usually takes place while the mobile is operating on a traffic channel. However, it maybe necessary to execute a handover at the call establishment stage, or during thecommunication of SMS data, when the mobile is still operating on the SDCCH.

It is not necessary to set this flag to operate directed re-try. However, using SDCCH handovercan reduce congestion and improve network performance.



Issue 1.0 - July 1999 39

EN_BSS_HO

Inter-cell handover from traffic channels and SDCCH may be performed by either the MSC(MSC-controlled / external) or by the BSC (BSC-controlled / internal). The EN_BSS_HO flag isused to enable or disable BSC-controlled handover, for handover requests that originate in aspecific cell of a BSS. The EN_BSS_HO flag is only meaningful if inter-cell handover is enabled.

Note that this flag is independent of the EN_INTER_HO flag, which enables the generation ofrequests for inter-cell handover in the individual cells of a BSS.

Disabling BSS-controlled inter-cell handover gives the MSC full decision authority on handoverrequests, and consequently increases its handover processing load.

For more details about these flags, refer to Appendix A.

BTS Object

The following BTS object values are used by the directed re-try process. They are set via theOMC terminal.


Traffic channel assignments and handover requests may be queued in the BSS. The samequeue is used for both, and the value assigned to TOTAL_NUM_Q_PLACE_AVAIL defines themaximum length of the queue.

When this value is set to 0, queuing is disabled.

Q_THRESHOLD_VAL

Traffic channel assignments and handover requests may be queued in the BSS. The valueassigned to Q_THRESHOLD_VAL defines a threshold as a percentage of maximum queue entries.The threshold is used for performance measurement purposes.


BSC Local Configuration Area software

Directed re-try is enabled via the OMC by setting the EN_SDCCH_TCH_HO flag to true. For this flagto be effective, directed re-try must also be individually activated for each BSC concerned bysetting the appropriate elements in their Local Configuration Areas.

This setting can only be made when the BSC software is compiled. The user cannotsubsequently change it. To switch on directed re-try at a BSC that does not have its LocalConfiguration Area already programmed to support it, requires a new version of BSC software tobe loaded.

There are two means of loading the BSC software:

• From the OMC terminal via an X. 25 link to the BSC(s)



40 Issue 1.0 - July 1999

• From the BSC Local Maintenance PC (IMW)

Note: The IMW method is not available for BCE software.

There are three levels of directed re-try, which can be enabled as sales options (level 0-2):

0. SDCCH – TCH handover is not permitted (directed re-try is disabled).

1. Directed re-try is only supported during queuing if the mandatory handover criteria arefulfilled.

2. Directed re-try is fully supported.

Depending on the directed re-try level settings for DIRRETC1and DIRRET2, directed re-try for trafficchannel assignment requests will be performed under the following conditions:

Level 1 Directed re-try

• If all traffic channels in the serving cell are busy, the ASSIGNMENT_REQUEST /HANDOVER_REQUEST is being queued, and a mandatory handover occurs owing to radio linkreasons

(Level 1 directed re-try facility was implemented for a specific customer and has not beenadopted elsewhere.)

Level 2 Directed re-try

• If all traffic channels in the serving cell are busy, the ASSIGNMENT_REQUEST / HANDOVER

REQUEST is being queued, and a mandatory handover occurs owing to radio link reasons

• If all traffic channels in the serving cell are busy, the ASSIGNMENT_REQUEST

/HANDOVER_REQUEST is being queued, and the maximum permitted queuing time is reached

Note: Queuing is required to support complete directed re-try functionality.

When directed re-try is invoked, the following occurs:

1. The BSC searches for an appropriate handover target cell.

2. If such a target cell is found, and the target cell belongs to the same BSS, the BSC initiatesan intra-BSC (BSC-controlled internal) handover. After completing the internal handover, theBSC informs the serving MSC of the identity of the new serving cell, and removes the trafficchannel request from the queue.

If such a target cell is found, but the target cell does not belong to the same BSS, the BSCrequests the MSC to perform an inter-BSC (MSC-controlled external) handover. The queueentry of the TCH request is removed from the queue in the BSC.

3. If such a target cell cannot be found, the BSC informs the MSC that the respectiveconnection will be released, and the traffic channel request is removed from the queue.



Issue 1.0 - July 1999 41

The effect of the BSC Local Configuration Area values associated with directed re-try are asfollows:

LCAFlag

Effect

DIRRETC1 Set to enable directed re-try during handover

DIRRETC2 Set to enable directed re-try during traffic channel assignment

QUEPROV Set to enable queuing (required for satisfactory operation ofdirected re-try)

The BSC Local Configuration Area values associated with directed re-try for the available BSCsoftware options are summarised below:

BSCModel

BSCSoftware

OPTION DIRRETC1 DIRRETC2 QUEPROV

BCE LM4.0 Several

BCE LM5.0 1 True True True

BCF R1 I True True True

BCF R2 1 True True True



42 Issue 1.0 - July 1999

MSC software

The MSC-related flags and timers associated with directed re-try are outlined below. Thesesettings are configured via the MSC Maintenance PC.

BSS_QUEUING_ALLOWED

This flag enables BSS queuing.

ASSIGN (for 5ESS®) or Trr1 (for T-Mobil) Assignment Guard Timer

This timer starts after sending an ASSIGNMENT_REQUEST to the BSC. It stops after:

• receiving ASSIGNMENT_COMPLETE from the BSC, or

• receiving CLEAR_REQUEST from the BSC, or

• receiving QUEUING_INDICATION from the BSS (MSC starts Queuing Timer).

On time-out the call is released, by issuing a CLEAR_COMMAND.

If the value set for ASSIGN is too small, the call success rate will fall. If the value is too large,unnecessary resources will be used if the mobile fails to seize the traffic channel, and the BSCfails to send the CLEAR_REQUEST.

QUEUING (for 5ESS®) BSS Queuing Timer

This timer starts after a QUEUING_INDICATION message is received from the BSC. It stops afterreceiving an ASSIGNMENT_COMPLETE or ASSIGNMENT_FAILURE message from the BSC.

On time-out the MSC issues a CLEAR_COMMAND to the BSC.

If the value set for QUEUING is too small, call will be dropped owing to MSC pre-emption. If thevalue is too large, unnecessary resources will be used if the mobile fails to seize the ‘new’ trafficchannel and does not revert to the old channel, and the BSS fails to send the CLEAR_REQUEST.

HO_ACK_T101 (for 5ESS®) or Trr2 (for T-Mobil)

This specifies two timers:

• Handover Resource Allocation Guard Timer for Intra-MSC Handover

• Handover Resource Allocation Guard Timer in Anchor MSC for Inter-MSC Handover

The timer starts after sending HANDOVER_REQUEST message to the target cell. In the 5ESS®, thetimer is re-started when a QUEUING_INDICATION message is received during Handover ResourceAllocation. The timer stops after receiving a HANDOVER_REQUEST_ACKNOWLEDGE message fromthe target BSC.



Issue 1.0 - July 1999 43

On time-out, the connection to the current cell is released. The MSC issues aHANDOVER_REQUEST to the next cell in the target cell list, if available. Timer HO_ACK_T101 is thenre-started, but Trr2 is not re-started.

On the last time-out, the MSC sends a HANDOVER_REQUIRED_REJECT to the cell originating thehandover attempt, and Trr2 is not re-started.

If the value set for HO_ACK_T101 is too small, handover resource allocation is pre-empted by theMSC, resulting in calls not being handed-over, and eventually dropping. If the value is too large,follow-up handover resource allocations may be started too late in the case of BSS double fault(e.g. BSS not allocating ‘new’ channel and not sending a HANDOVER_FAILURE message to theMSC). This can result in call handover being delayed, or not handed-over and finally dropped.

HO_CMPLT_CON_T102 (for 5ESS®)

This setting specifies the Handover Execution Guard Timer.

The timer starts after sending HANDOVER_COMMAND message to the target BSS. It stops afterHANDOVER_COMPLETE is received from the target BSS or HANDOVER_FAILURE is received from theoriginating BSC.

On first time-out, all legs of the call (i.e. originating cell, target cell, and other party) are released.

If the value set for HO_CMPLT_CON_T102 is too small, the number of dropped calls will increaseduring handover execution as the MSC prevents the mobile from completing the handover, andfrom reverting to the old cell. If the value is too large, unnecessary resources will be used in thecase of a triple fault (e.g. mobile not seizing target cell and not reverting to the old cell, and Trr3

not expiring in the target cell).

T310

This setting specifies the Call Confirm Guard Timer. The timer starts when CALL_CONFIRMED

message is received and stops after ALERT, CONNECT, or DISCONNECT is received.

On first time-out, the call is cleared and DISCONNECT is issued. The timer is not re-started.

If the value set for T310 is too small, calls will be disconnected improperly, and a SystemMaintenance message generated. If the value is too large, unnecessary resources will be usedin the case of mobile failure (e.g. ALERT or CONNECT not received from the mobile).




44 Issue 1.0 - July 1999

Timers in MSC / BSC-controlled handover

Different timers are used according to whether the directed re-try is BSC-controlled or MSC-controlled.

MSC-controlled handover

The following timers are used at the MSC:

• HO_ACK_T101:

− Handover Resource Allocation Guard Timer for Intra-MSC Handover

− Handover Resource Allocation Guard Timer in Anchor MSC for Inter-MSCHandover

− (HO_ACK_T101 is known as Trr2 for T-Mobil switches)

• HO_CMPLT_CON_T102:

− Handover Execution Guard Timer

The following timers are used at the BSC:

• T7 Handover Required Guard Timer

• T8 Handover Guard Timer in Originating Cell

BSC-controlled handover

All other timers are used for both MSC-controlled and BSC-controlled directed re-try.

MSC support for directed re-try

To provide a complete directed re-try service within the network, the serving MSC must supportboth directed re-try and queuing.

If the MSC supports queuing but not directed re-try, then directed re-try is only available withinthe serving BSS. The following process occurs when directed re-try is invoked under theseconditions:

1. The BSC searches for an appropriate target cell for the SDDCH to TCH handover.

2. If such a target cell exists and belongs to the same BSS, the BSC begins the intra-BSChandover procedure. When the BSC internal handover is completed, the BSC informs theserving MSC of the ‘new’ serving cell identity within an ASSIGNMENT_COMPLETE message.The traffic channel request entry is then removed from the BSS queue.

3. If no appropriate target cell exists in the serving BSS, the BSC sends anASSIGNMENT_FAILURE message to the MSC, which leads to the release of the respective



Issue 1.0 - July 1999 45

connection. The corresponding entry for the traffic channel request is discarded from theBSS queue.

If the serving MSC does not support queuing then it is not possible to provide even a limiteddirected re-try service within the network.

Dependencies

Directed re-try in Lucent networks has the following dependencies:

• In order for directed re-try to operate satisfactorily, it is recommended that the queuingfeature is also used.

If queuing is not used, then the directed re-try may be attempted before sufficient NeighbourCell measurement reports have been received for an accurate Preferred Target Cell List tobe compiled

• Inter-BSS directed re-try requires support for queuing and directed re-try in the MSC

• Intra-BSS directed re-try requires at least support for queuing in the MSC

• Inter-MSC directed re-try requires support for queuing and directed re-try from the MSC

Directed re-try to poor target cell

It should be assumed that a mobile is normally served by the ‘best’ (most appropriate) cell. Withdirected re-try, calls will be re-directed from the best cell when it has no spare channels, to aneighbouring cell, which may be able to offer an adequate (but non-ideal) service. Consequently,if a directed re-try has been performed to a non-ideal cell, in some conditions it is possible thatthe call quality will be degraded (or the call lost), and co-channel interference increased.

To avoid unacceptable degradation in call quality (and increased dropped call rates), the valueassigned to RXLEV_MIN(i) should be used to set the minimum acceptable handover signal level forneighbour cells (i).

As the effect of directed re-try is that a mobile is not served by the best cell, it is likely that afurther handover to the best cell will be attempted later. Thus additional handovers may betriggered.

Directed re-try should be implemented after network optimisation and definition of the cellboundaries, and subsequent performance should be measured. After activating directed re-try, itmay be necessary to make further adjustments to the cell boundaries and handover levels, inorder to optimise performance.

Directed re-try and queuing timers

As noted previously, it is recommended that queuing is enabled when activating directed re-try,to ensure that sufficient Neighbour Cell measurement reports are received.



46 Issue 1.0 - July 1999

Note: Although increasing the maximum queuing time can reduce network blocking; it alsoincreases the time before a directed re-try can be invoked (except for mandatory or powerbudget handover). This is illustrated below:

Figure 6 Effect of queuing timers on directed re-try invocation (MSC-controlled)

SDCCH congestion

When a call is queued, either prior to activation of directed re-try, or while directed re-tryhandover requests are made to the cells on the Target Cell List, the mobile is occupying aSDCCH channel. This may cause SDCCH blocking.

Use of SDCCH_HO with directed re-try

The SDCCH handover and directed re-try (SDCCH to TCH handover) features are independent.

Both can be used either separately, or together, to reduce congestion.



Issue 1.0 - July 1999 47


When considering the deployment of directed re-try the following factors should be considered:

• Analysis of the performance indicators relating to congestion (directed re-try is not designedto combat permanent traffic overload in a cell)

• The extent to which the cells neighbouring the congested cells have spare capacity

• Improved network resilience to failed carriers, and the capability to use directed re-try toserve mobiles on neighbouring cells

Traffic data

To assess the effect of activating directed re-try, the following performance indicators should bemonitored on a cell-by-cell basis, both within the deployment area, and in surrounding cells. Thisinformation can be used to compare the results obtained with the use of directed re-try underdifferent network traffic loads:

• Busy hour (the hour which has the largest value for traffic channel use)

• Traffic channel seizure attempts

• Traffic channel seizures

• Traffic channel seizure blocks

• Traffic channel blocking (percentage)

• Traffic channel traffic (Erlang)

• Traffic channel mean holding time

• SDCCH seizures

• SDCCH seizure blocks

• SDCCH blocking (percentage)

• SDCCH traffic (Erlang)

• SDCCH mean holding time (the approximate call queuing time)

The above data should be recorded during the busy hour, and repeated on a daily basis in orderto monitor long-term performance.

Quality data

The following network quality related information should be measured and recorded:



48 Issue 1.0 - July 1999

Dropped call performance

• Traffic channel seizures that are dropped for radio reasons

• Proportion of traffic channels dropped (percentage)

• Traffic carried (Erlang) per dropped call

• SDCCH seizures dropped for radio reasons

• Proportion of SDCCH dropped (percentage)

• SDCCH traffic (Erlang) per dropped call

Handover performance

• Total number of handover attempts

• Intra-cell handover attempts

• Intra-cell handover failures

• Proportion of intra-cell handover that fail (percentage)

• Inter-cell handover attempts

• Inter-cell handover failures

• Proportion of inter-cell handover that fail (percentage)

• Uplink quality handovers

• Proportion of uplink quality handovers (percentage)

• Uplink level handovers

• Proportion of uplink level handovers (percentage)

• Downlink quality handovers

• Proportion of downlink quality handovers (percentage)

• Downlink level handovers

• Proportion of downlink level handovers (percentage)

• Inter-BSC handover number by cause

• Inter-BSC handover failure number



Issue 1.0 - July 1999 49

• Inter-BSC handover success number

Received quality statistics

• An Abis protocol analyser can be used to record RXQUAL data relayed by mobiles in theirmeasurement reports.

Survey data

A number of test drive routes can be defined in the area where directed re-try is implemented,and the following data recorded during the busy hour, in order to determine its effect:

Recorded data

• BSIC, BCCH and TCH frequency for the serving cell

• BSIC, BCCH frequency and RXLEV for the neighbouring cells

• Downlink RXLEV and RXQUAL data

• Downlink co-channel and adjacent channel CIR

• Voice quality

• Handover and dropped call events and their cause

Data analysis

The above survey data can be analysed to provide:

• General information per base station:

− Number of dropped calls (absolute number and per Erlang) in the busy hour

− Number of handovers (absolute number and per Erlang) and cause

− Failed handovers (absolute number and per Erlang) and cause

− Uplink and downlink RXQUAL statistics

• Survey measurement data

− Voice quality / frame erasure rate against RXLEV / RXQUAL / CIR

− Handovers, dropped calls, and their cause



50 Issue 1.0 - July 1999

Expected effect of activating directed re-try

The precise effect of directed re-try will vary from network to network. However, changes in thefollowing areas should be examined (as a minimum) in determining its effect:

• Traffic carried before and after implementation (other network and traffic load conditionsidentical)

• Number of handovers

• Blocking rate (SDCCH, TCH)

• Traffic in the cell (SDCCH, TCH)

• Number of dropped calls (SDCCH, TCH)

• Number of failed handovers

• Queuing time

• CIR (Carrier to Interference Ratio)

• BER (Bit Error Rate)



Issue 1.0 - July 1999 51

3.3. Pre-emption design

Pre-emption is a network facility that must be supported by both the MSC and the BSC in orderto operate. The MSC determines when pre-emption is invoked, according to user specificationagainst dialled digit analysis, call type and so on.

Pre-emption only takes place during traffic channel ASSIGNMENT_REQUESTS. It does not takeplace during handover requests (including internal BSC handover).

Pre-emption occurs if:

• No free traffic channels exist at the serving cell, and

• The PCI (Pre-emption Capability Indicator) flag is set in the ‘new’ ASSIGNMENT_REQUEST, and

• A suitable traffic channel assignment exists, which has its PVI flag set

If the above criteria are met, the pre-empted call is released, and the ‘new’ traffic channelASSIGNMENT_REQUEST will be served.

In all other circumstances, the ‘new’ ASSIGNMENT_REQUEST will be handled as normal, which mayresult in:

• Allocation of a traffic channel, or

• Issue of an ASSIGNMENT_FAILURE message, or

• Entering the ASSIGNMENT_REQUEST into a queue, or

• Invocation of directed re-try

For any particular ASSIGNMENT_REQUEST the result will depend on the traffic load in the servingand neighbouring cells, PRIORITY assigned to the call, and the features available in the network.



52 Issue 1.0 - July 1999


Pre-emption is available with GSM software 8.x. When pre-emption is deployed, the followingnetwork elements are affected:

Network elements




Network interfaces


MSC-BSC(A)

STF-BSC(M)

BSC-BTS(Abis)

Air(Um)

Software Yes No Yes No No No


BSC Local Configuration Area software

The PREMPTION_PROVIDED flag is set ‘False’ by default. In this state the ‘normal’ assignmentprocedure is followed, which may involve queuing and/or directed re-try when there are no freetraffic channels available at the serving cell.

In order to use pre-emption the PREEMPTION_PROVIDED flag must be set ‘True’. In this case, theBSC checks the PVI flag contained in the PRIORITY Information Element of theASSIGNMENT_REQUEST message. If the PVI element is not present, then PVI is set to ‘False’(zero).

If an ASSIGNMENT_REQUEST is received with either:

• The pre-emption Capability Indicator (PCI) flag set to zero (False), or

• Missing PRIORITY information element

Then the request is handled as a ‘normal’ assignment procedure, according to the prevailingnetwork conditions and capabilities. Under these circumstances:

• If free traffic channels exist, the assignment proceeds



Issue 1.0 - July 1999 53

• If no free traffic channels exist, and queuing and directed re-try are not enabled, the requestis rejected with cause ‘No Radio Resources Available’

• If no free traffic channels exist, and queuing and directed re-try is enabled, then queuing and(if necessary) directed re-try is performed

If an ASSIGNMENT_REQUEST is received with the PCI flag set to 1 (True), the following actions takeplace:

• If free traffic channels exist, the assignment proceeds

• If no free traffic channels exist, a suitable existing assignment with its PVI flag set to 1 (True)is sought.

If such an assignment exists, the call is released and the relinquished traffic channel is re-assigned to the pre-empting ASSIGNMENT_REQUEST.

If no such assignment exists, then one of the following occurs:

− Queuing takes place, or

− Directed re-try is attempted, or

− The request is rejected with cause ‘No Radio Resources Available’


MSC software

For every call, the pre-emption function is controlled by the MSC via the PRIORITY informationelement in the ASSIGNMENT_REQUEST message.

The PRIORITY information element contains:

• Pre-emption Vulnerability Indicator (PVI), which defines whether or not the assignment maybe pre-empted by another ASSIGNMENT_REQUEST

• Pre-emption Capability Indicator (PCI), which defines whether or not the assignment maypre-empt an existing assignment

• Queuing Allowed Indicator (QA)

• Priority Level (1 to 14)

The BSC retains the received PVI flag for the duration of the connection served by it. If thePRIORITY information element is not contained within the ASSIGNMENT_REQUEST orHANDOVER_REQUEST messages, both the PVI and PCI flags are set to 0 (False). That is, theassignment cannot itself be pre-empted nor can it pre-empt others



54 Issue 1.0 - July 1999

Dependencies

The pre-emption facility is dependent on the following:

• The BSC PREEMPTION_PROVIDED flag must be set to 1, (True), in the BCS software LocalConfiguration Area. By default this flag is set to 0, (False). This flag is not adjustable via theOMC and must be set by Lucent, and the new software loaded onto the appropriate BSC

• Support for the pre-emption facility in the MSC

Limitations

The major limitations of the pre-emption facility are listed below:

• If a SDCCH is requested by a call capable of pre-emption (PCI=1), pre-emption does nottake place

• If a handover is requested by a call capable of pre-emption (PCI=1), pre-emption does nottake place



Issue 1.0 - July 1999 55

3.4. Handover Regarding Traffic Load design

Handover Regarding Traffic Load (HORTL) is a Lucent BSC-controlled facility, and requires nospecific support from the MSC. When this facility is operating, the BSC takes the traffic load ofthe neighbouring cells into account when it selects a handover target cell.

The BSC maps the number of free traffic channels in each cell into five bands. Each band isassigned an offset value, which is applied to the power budget calculation when the handovertarget ‘best cell’ is determined. The fewer free channels that a cell has available, the higher theweighting applied against handover to that cell.

HORTL does not initiate a handover, but merely influences the choice of cell when a handover isinvoked.


HORTL implementation affects the network elements and interfaces listed below:

Network elements


Software Yes No No Yes No No


Network interfaces


MSC-BSC(A)

STF-BSC(M)

BSC-BTS(Abis)

Air(Um)

Software Yes No No No No No




56 Issue 1.0 - July 1999

OMC - BSC software configuration

The BSC configuration for HORTL is performed via the OMC terminal and involves the followingobject:

BTS Object

The BTS object values used by the HORTL process are as follows:

EN_LOAD_REGARD

This flag is used to enable HORTL.

FREElevel_1FREElevel_2FREElevel_3FREElevel_4

These parameters specify the boundary values by which the number of free channels in eachcell is divided, to yield five bands of free channels.

FREEfactor_1FREEfactor_2FREEfactor_3FREEfactor_4FREEfactor_5

These parameters specify the offset (weighting) values to be applied to the power budgetcalculation, according to the number of free channels that the cell has when the handover targetcell list is ranked.

Implementation of the HORTL facility requires no software configuration change to other OMC –BTS objects.




Issue 1.0 - July 1999 57

Dependencies

Introduction of HORTL is dependent on the following:

• The customer being authorised to use HORTL, by Lucent registering this in each BSCsoftware Local Configuration Area

Note that this is fixed at software compilation, and cannot be retrospectively changed withoutgenerating and loading new software onto the BSC concerned

• The flag EN_LOAD_REGARD must be set ‘True’ in the OMC software BTS object

• The FREElevel and FREEfactor values must be set appropriately

• The maximum number of free channels in each cell sets the upper limit on the fifth band offree channels

Limitations

• HORTL only operates between cells controlled by the same BSC

• The facility is only used for handover between traffic channels, and from SDCCH to trafficchannels

• When a layer-down handover takes place, (for example, from an umbrella cell to a microcell)traffic load is not considered


On activation, the following areas should be monitored to assess the effect of HORTL:

• Improvement in grade of service (that is, reduced blocking)

• Increase in traffic handled

• Increase in the number of handover events

• Change in average voice quality

• Increase in co-channel interference



58 Issue 1.0 - July 1999



Appendices


Issue 1.0 - July 1999 59

Appendix A. Parameter Values

This appendix details the network parameters used to implement each of the available trafficload management facilities:

• Queuing

• Directed re-try

• Pre-emption

• Handover regarding traffic load



60 Issue 1.0 - July 1999

Queuing parameters

This section describes the parameters used to implement and configure the queuing facility.

BTS object

Name Description Allowable values Default


Defines maximum BSS queue entriesfor channel assignments and HOrequests

0 to 100

(0 disablesqueuing)

5 (if queuing isenabled)

0 (if queuing isdisabled)

Q_THRESHOLD_VAL Defines a performance measurementthreshold as a percentage of maximumqueue entries

0% to 100% 80%

BTS parameters are set using the OMC terminal.

BSC object

Name Description Allowable values Default value

T11 Queuing timer 1s to 5min 4s

T_qho HO resource allocation queue guardtimer (defines maximum time a HOrequest is queued)

1s to 30s

Value must be< Trr2 timer

2s

BSC parameters are set using the OMC terminal.

MSC software


BSS_QUEUING_ALLOWED

Enables/disables BSS queuing True (enabled)False (disabled)

Customerspecific

QUEUING (for 5ESS®) Specifies the maximum queuing time Value must be > T11 timer

27s

ASSIGN (for 5ESS®)orTrr1 (for T-Mobil)

Assignment guard timer used duringdedicated assignment

Value must be> T11 + max (T10,T3107)

30s

MSC parameters are set using the MSC maintenance PC (via the Recent Changes Manualmenu, MSC pages WBOPM 61.2 and 61.3).



Issue 1.0 - July 1999 61



PCI Indicates whether a traffic channelrequest can pre-empt an establishedcall

1 (True) - enablespre-emption

0 (False) -disables pre-emption

PVI Indicates whether a traffic channelrequest can be pre-empted by anotherassignment



QA Queuing allowed indicator 1 (True)queuing allowed

0 (False)queuing notallowed

Priority level Assigns a priority level to anassignment request

1 (highest priority)to14 (lowest priority)

PRIORITY information element parameters are set using the MSC maintenance PC (via theRecent Changes Manual menu/ Wireless Miscellaneous Parameters sub-menu).



62 Issue 1.0 - July 1999

Directed re-try parameters

This section describes the parameters used to implement and configure the directed re-tryfacility.

OMC software


EN_SDCCH_TCH_HO Enables/disables directed re-try in theBSS

True (enabled)

False (disabled)

False

Note: For this parameter to be effective, directed re-try must also be activated for each BSCconcerned (see the BSC object table below).

BSC object


T7 HO required guard timer 5s to 60s

Value must be> T7_IHO

10s

T8 HO guard timer in originating cell 1s to 60s

Trr3 must be <=Trr7 <= T8

32s

T10 Assignment guard timer for ‘old’channel

1s to 30s

T10 > T3107

23s

T11 Queuing timer used during dedicatedassignment

1s to 5mins 4s

T_qho HO resource allocation queue guardtimer

1s to 30s

Value must be<Trr2

2s

Trr3 HO guard timer in the target cell 1s to 60s

Value must be<= Trr7 <= T3

24s

BSC parameters are set using the OMC terminal.



Issue 1.0 - July 1999 63

Handover object


EN_SDCCH_TCH_HO Enables/disables directed re-try 0 (no/false)

1 (yes/true)

0

EN_SDCCH_HO Determines whether SDCCH to SDCCHHO is permitted. Only meaningful ifinter-cell HO is enabled (controlled byflag EN_INTER_HO).

0 (no/false)

1 (yes/true)

1

EN_BSS_HO Enables/disables BSC-controlled(internal) handover for HO requests thatoriginate in a specific cell of a BSS

0 (no/false)

1 (yes/true)

1

Handover object parameters are set using the OMC terminal.

BTS object



Defines maximum length of the BSSqueue for TCH assignments and HOrequests

0 to 100 0 (if queuingdisabled)

5 (if queuingenabled)

Q_THRESHOLD_VAL Defines a threshold (used forperformance measurement) as apercentage of maximum queue entries

0% to 100% 80%

BTS parameters are set using the OMC terminal.



64 Issue 1.0 - July 1999

MSC software


BSS_QUEUING_ALLOWED

Enables/disables BSS queuing True (enabled)False (disabled)

Customerspecific

QUEUING (for 5ESS®) Specifies the maximum queuing time Value must be > T11 timer

27s

ASSIGN (for 5ESS®)orTrr1 (for T-Mobil)

Assignment guard timer Value must be> T11 + max (T10,T3107)

If above is obeyed

Trr1 > T11 + T10

30s

HO_ACK_T101(5ESS®)orTrr2 (for T-Mobil)

HO resource allocation guard timer forintra-MSC HOHO resource allocation guard timer inanchor MSC for inter-MSC HO

Time needed toactivate TCH intarget cell<Trr2<T7

4s

HO_CMPLT_CON_T102

HO execution guard timer Value must begreater than timeneeded for mobileto revert to ‘old’cell and sendHANDOVER_FAILURE message(approx. 10s)

Trr3 must be <=HO_CMPLT_CON_T102 <=T8

28s

T310 Call confirm guard timer Value must be> (worst case txtime on SDCCH)

12s

MSC parameters are set using the MSC maintenance PC (via the Recent Changes Manualmenu, MSC pages WBOPM 61.2 and 61.3).



Issue 1.0 - July 1999 65

Pre-emption parameters



PCI Indicates whether a traffic channelrequest can pre-empt an establishedcall



PVI Indicates whether a traffic channelrequest can be pre-empted by anotherassignment



QA Queuing allowed indicator 1 (True) -queuing allowed

0 (False) -queuing notallowed

Priority level Assigns a priority level to anassignment request

1 (highest priority)to14 (lowest priority)

PRIORITY information element parameters are set using the MSC maintenance PC (via theRecent Changes Manual menu/ Wireless Miscellaneous Parameters sub-menu).



66 Issue 1.0 - July 1999

Handover Regarding Traffic Load parameters

BTS object


EN_LOAD_REGARD Enables/disables HORTL 1 (enables)0 (disables)

0

FREELEVEL_1FREELEVEL_2FREELEVEL_3FREELEVEL_4

Specifies boundary values forfree channel bands

0 to 255 (resolution of 1) 1234

FREE_FACTOR_1FREE_FACTOR_2FREE_FACTOR_3FREE_FACTOR_4FREE_FACTOR_5

Specifies offset valuesapplied to the power budgetcalculation, according to thenumber of free channels thecell has when the HO targetcell list is ranked

0 to 32 (resolution of 1 -representing 1dB)

0 represents -16dB1 represents -15dB…32 represents +16dB

FREE_FACTOR_1=14representing -2dB



FREE_FACTOR_4=17representing +1dB

FREE_FACTOR_5=18representing +2dB



Issue 1.0 - July 1999 67

Appendix B. Future Developments

Lucent plans to optimise future traffic management techniques by adding the Handover due toTraffic Load (HODTL) feature.

This will extend the existing Handover Regarding Traffic Load (HORTL) feature (whichinfluences the choice of target cell only if a handover is requested for radio resourcemanagement reasons) and allow it to initiate a handover owing to increasing congestion in theserving cell.

Handover due to Traffic Load overview

The HODTL feature will improve the peak traffic handling capacity of a group of cells which havesome interference-free overlapping coverage, and are all connected to the same BSC.

This will be achieved by means of transferring traffic between cells, forcing mobiles to handoverfrom overloaded cells to those with greater spare capacity (provided that adequate radio linkquality can be maintained by the cell with spare capacity).

HODTL is intended to assist with temporary cell overloads, and not as a means to increasegeneral wide area network capacity.

Advantages

HODTL will have the following benefits:

• Localised gain in capacity within a group of cells fitted with one transceiver is likely to be upto 25%, depending on the distribution of traffic with respect to overlapping cell areas.However; the capacity of the network as a whole will increase to a lesser extent - in theregion of 10 to 15%

• Reduced blocking levels owing to less queuing and directed retry activity. This is due to areduction in the extent to which all channels within a cell will be in use

Disadvantages

Under certain conditions a number of problems may arise:

• Increased number of handover events, resulting in greater signalling traffic and processingload, together with an increase in the chance of dropped calls

• Increased back-haul link traffic and BSC processing associated with the calculation anddistribution of traffic load indication messages

• Decrease in the radio link quality (for example, increased bit error rates)



68 Issue 1.0 - July 1999

These effects can be mitigated to some extent by the values used for the HO_MARGIN(0,i),FREEfactor_X (where X takes values 1 to 5), and LINKfactor(0,i) .

The HO_MARGIN(0,i) value may be used to avoid unnecessary repeated handover between cells ofthe same hierarchical layer.

The FREEfactor_X (where X takes values 1 to 5) value may be used to adjust a penalty accordingto the traffic load experienced.

The LINKfactor(0,i) may be used to fix the power budget handover to certain cells. This may beused to control handover of dual band mobiles, or to prevent handover of fast moving mobilesfrom a large cell to a smaller neighbour cell (when both are ‘standard’ layer cells).

Availability

HODTL will be available as a sales option, and if chosen, will be registered in the BSC softwareLocal Configuration Area.

It will be enabled on a per BSS basis, but is restricted to cells contained within the BSS. Thustraffic cannot be transferred from one overloaded cell to another lightly loaded cell (even if theyare overlapping neighbouring cells) if different BSCs control them.

HODTL will be used between cells operating on different bands, provided that they are linked tothe same BSC. So for co-located 900 and 1800 band cells (subject to an adequate proportion ofdual band mobiles) the traffic load can be redistributed between the different bands if one of thecells becomes overloaded and its co-located neighbour is underused.

Effect on Handover Regarding Traffic Load feature

The Handover Regarding Traffic Load (HORTL) facility is part of the handover target cellevaluation process (primarily for mandatory handover), in which the traffic load in both theserving cell and the neighbouring cells, is considered during the evaluation.

When HODTL is selected as a sales option, and enabled on a BSS, it will be merged with theHORTL feature. This is because:

• Both features use the same input parameters FREElevel_X and FREEfactor_X

• Use of the same neighbour cell borders for mandatory handover and power budgethandover reduces the chance of unnecessary repeated handover

The merger will be implemented by the HODTL using the HORTL target cell prioritisationprocedure, when target neighbour cells are evaluated for handover.



Issue 1.0 - July 1999 69

Implementation

When the BSC software flag EN_TL_HO is set as ‘True’, HODTL will be enabled and will use amodified version of the power budget handover. When the BSC software flag EN_TL_HO is set as‘False’, HODTL will be disabled and the standard power budget handover will be performed.

The HODTL feature will be enabled in two modes:

• Triggered in case of cell overload

• Triggered whenever a neighbour cell has a lower load than the serving cell



70 Issue 1.0 - July 1999



List of Acronyms


Issue 1.0 - July 1999 71

List of Acronyms

The following acronyms are used in this document:

BCCH Broadcast Control Channel

BCE BSS Controller Equipment

BCF Base Station Controller Frame

BER Bit Error Rate

BSC Base Station Controller

BSS Base Station System

BSSAP Base Station System Application Part

BTS Base Transceiver Station

CCCH Common Control Channel

CHN Channel

CIR Carrier to Interference Ratio



72 Issue 1.0 - July 1999

EAC Emergency Authority Cell of Origin

EGSM Extended GSM (900MHz band extension)

EIR Equipment Identity Register

FCCH Frequency Correction Channel

FH Frequency Hopping

GSM Global System for Mobile Communications

HODTL Handover Due to Traffic Load

HORTL Handover Regarding Traffic Load

HLR Home Location Register

IMSI International Mobile Subscriber Identity

ISUP Integrated Services Digital Network User Part

LAN Local Area Network

MAP Mobile Application Part

MNC Mobile Network Code

MSC Mobile Switching Centre

NPMS Network Performance Monitoring System

ODD Office Dependent Data

OMC Lucent Technologies Operations and Maintenance Centre 2000

PCI Pre-emption Capability Indicator

PGSM Primary GSM (public 900MHz basic GSM band)

PLMN Public Land Mobile Network

PSTN Public Switched Telephone Network

PTO Public Telephone Operator

PVI Pre-emption Vulnerability Indicator

RF Radio Frequency



Issue 1.0 - July 1999 73

RT Radio Terminal

RXLEV Received Signal Level

RXQUAL Received Signal Quality

SACCH Slow Associated Control Channel

SCH Synchronisation Channel

SDCCH Standalone Dedicated Control Channel

SIM Subscriber Identity Module

STF Speech Transcoder Frame

TCH Traffic Channel

TMSI Temporary Mobile Station Identifier

TRX Transceiver

VLR Visitor Location Register



74 Issue 1.0 - July 1999


Comments Form


Comments Form

Identification no: 401-380-362 Issue No: 1.0 Date: July 1999

Title: GSM Traffic Load Management Engineering Guideline

Lucent Technologies welcomes feedback on this customer Information Product. Yourcomments can be of great value in assisting us to improve our Information Products.

1. Please rate (tick the box) the effectiveness of this Information product in the following areas:

Excellent Good Fair Poor Not ApplicableEase of useClarityCompletenessAccuracyOrganisationAppearanceExamplesIllustrationsOverall Satisfaction

2. Please place a tick against any improvement that could be made to this Information Product:

Improve the overview/introduction Make it more concise/brief

Improve the table of contents Add more step-by-step procedures/tutorials

Improve the organisation Add more troubleshooting information

Include more figures Make it less technical

Add more examples Add more/better quick reference aids

Add more detail Improve the index

3. Please provide details for the suggested improvement in the box below:

Comments Form


4. What did you like most about this Information Product:

5. Any additional comments:

6. If we may contact you concerning your comments, please complete the following:

Date:

Name:

Company/Organisation:

Address:

Job Title:

Telephone No:

When you have completed this form, please fax a copy to:

The Technical Manager, CTIP-UK, Fax Number (+44) 1666 824515

Gsm Traffic Load Eg

Documents