telecommunication traffic load management

Lucent Technologies -- Proprietary This document contains proprietary information of

Lucent and is not to be disclosed or used except in accordance with applicable agreements.

GSM Traffic Load Management

Engineering Guideline

EG: GSMTRM

401-380-362 Issue 1.0 July 1999

GSM Traffic Load Management Engineering Guideline

Lucent Technologies - PROPRIETARY Use pursuant to Company instructions

ii Issue 1.0 - July 1999

Copyright © 1999 Lucent Technologies Unpublished and Not for Publication

All Rights Reserved

This material is protected by the copyright and trade secret laws of the United States and 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 the Customer 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 -- Proprietary This document contains proprietary information of

Lucent 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 6 Benefits for PTOs 6 Benefits for subscribers 6 Benefits for regulatory authorities 6

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

3. TRAFFIC LOAD MANAGEMENT DESIGN 27

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

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

3.3. Pre-emption design 52


Contents


iv Issue 1.0 - July 1999

Network elements and interfaces 53 Dependencies 55 Limitations 55

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

APPENDIX A. PARAMETER VALUES 61

Queuing parameters 62 BTS object 62 BSC object 62 MSC software 62 PRIORITY information element (GSM 08.08) 63

Directed re-try parameters 64 OMC software 64 BSC object 64 Handover object 65 BTS object 65 MSC software 66

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

Handover Regarding Traffic Load parameters 68 BTS object 68

APPENDIX B. FUTURE DEVELOPMENTS 69

Handover due to Traffic Load overview 69

LIST OF ACRONYMS 73

COMMENTS FORM 77


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 of traffic load management techniques in GSM networks. It discusses load management techniques 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 are used, and the differing operating priorities of each network operator, the choice of any particular implementation technique is likely to be both network and customer specific. Thus this document is intended only as a general reference guide to traffic load management techniques, and is not a 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 network call 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 of each technique on the main GSM network elements and in particular on the number of air interface channels required. Also highlights any dependencies and limitations associated with 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 allowable and 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 are used efficiently, and subscribers receive the best available grade of service appropriate to the priority of their call.

Unless specifically stated to the contrary, this document describes features and facilities that are available 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



Issue 1.0 - July 1999 3

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

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.0 Lucent 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 Load Management

2


Issue 1.0 - July 1999 5

2. Introduction to Traffic Load Management

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

2.1. Background

Traffic management schemes are continuing to grow in popularity as network operators deploy them 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 Telecommunications Operator), the subscriber, and the regulatory authority (which usually represents the public interest). 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 in equipment 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 improved competitiveness 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 the subscribers (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 GSM system. 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 the Handover 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. Instead of applying a ‘busy’ tone, the call is queued for a predefined time in the BSC in case a traffic channel 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 possible if the appropriate handover conditions are met.

Operation

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

When all radio channels available at a cell are busy, incoming traffic channel requests are queued within the serving BSC for a predefined period of time. During this time, if a traffic channel with parameters matching one of the queued requests becomes free, the queued traffic channel 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 a directed re-try may be attempted.

Both traffic channel assignment requests and external MSC-controlled handover requests can be queued. When an internal BSC-controlled handover is required, traffic channel assignment requests cannot be queued directly. Under these circumstances, the BSC requests an external handover 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 the following 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 requires Lucent 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 OMC on a per BTS (Base Transceiver Station) basis. A queue length of zero disables queuing for a given cell.

The queuing values for the network can be set from the OMC terminal. Note that if the value for the queuing timer is changed, then the new value is only applied to new entries in the queuing table (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 requests that cannot be immediately served (owing to lack of free traffic channels with matching parameters) are either served or exceed the maximum queuing time.

Each cell has only one queue. All traffic channels requests are entered in that queue, regardless of 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 on the priority levels defined in GSM Recommendation 08.08.

The information element PRIORITY in the received message ASSIGNMENT_REQUEST or HANDOVER_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) basis according to their time of arrival

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

• When all queue places are occupied, the entry in the last queue position is replaced if a higher 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 set for 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 entry is 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 or HANDOVER_REQUEST message, then if no suitable traffic channels are available, and queuing is enabled, the BSC sends a QUEUING_INDICATION message to the serving MSC.

When a queued traffic channel request is served, an ASSIGNMENT_COMPLETE or a HANDOVER_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 higher priority request, an ASSIGNMENT_FAILURE or HANDOVER_FAILURE message (according to the request 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 message followed by a HANDOVER_REQUIRED message, both with cause DIRECTED_RETRY, are sent to the serving MSC.

Effect

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

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

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

It is generally considered that the increased traffic load capacity of a cell using queuing can be calculated 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 solution within 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 the number, 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 be used when a call is requested in a cell that has no free traffic channels. Instead of releasing the subscriber, an alternative cell with free traffic channels can be chosen and the mobile call handed over to a traffic channel in that cell.

Directed re-try is designed to alleviate temporary cell overload situations. It is not a means to increase 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. If queuing is not used, then directed re-try may be attempted before an accurate list of alternative neighbour target cells for the re-try has been compiled. Directed re-try may fail if insufficient neighbour 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 at another 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 the following 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 the same MSC.

This is a MSC-controlled directed re-try. The signalling flow (with queuing) is shown in the following 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 a different 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, the ASSIGNMENT_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 message with cause DIRECTED_RETRY and a HANDOVER_REQUIRED with cause DIRECTED_RETRY to the serving 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 SDCCH to TCH handover can be enabled or disabled for each cell controlled by the BSC. This is done via 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 (for example, the queuing time has expired), the averaging period for the neighbour cell measurements is changed as follows:

• Provided that the neighbour cell averaging window is not completely filled with new reported measurement results, the averaged measurement results (AV_RXLEV_NCELL_S(i)) are calculated



Issue 1.0 - July 1999 17

from the number of measurement values that have been shifted into the measurement window. Thus, the currently received and the preceding measurements are used

• Leading zeros (pre-loaded) in the averaging window are not used in the calculation, unless the 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 radio resources are available in the target cell. Thus directed re-try is not allowed if there is traffic channel congestion in the target cell.

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

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

The length of this list is set by the value assigned to n(N_TARGET_CELL) which defines the maximum 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 not recommend using a value greater than 6 (the default). This is because the mobile only makes up to 6 measurements from the strongest neighbour cells, so the probability of having measurement results from more than 6 neighbours is low.

Entry conditions

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

For handover caused by directed re-try, the bookkeeping list is searched for all registered neighbour 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, averaged according 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 be greater 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 neighbouring cells (i).



18 Issue 1.0 - July 1999

Ranking

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

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

The target cell with the highest priority determines whether a BSC-controlled handover or a MSC-controlled handover takes place. If the target cell with the highest priority is controlled by the 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, then an attempt is made to the second priority target cell. If this attempt is also unsuccessful, then the process 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 with a 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 is sent to the MSC.

The MSC sends a handover request to the BSC responsible for the next highest priority cell in the Target Cell List. If this BSC rejects the handover request, the MSC can repeat the request to the BSC serving the next highest priority cell in the Preferred Target Cell List. This procedure can 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, the directed 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 than presenting a busy signal to the subscriber. This facility can be particularly useful when the distribution of traffic is mobile and unevenly loaded (that is, one cell is heavily loaded but its neighbour cells are not).

The signalling traffic and load carried by the network will increase, as will utilisation of the existing 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 network implementation and grade of service offered. However, research indicates that for a network designed to offer a 2% grade of service, with 2 transceivers per cell, and provided sufficient candidate 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 (so only 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. Even for 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 may cause:

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

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

− Increased ‘ping-pong’ (unnecessary handover events). This can be minimised by setting 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 traffic channels in the serving cell are busy. This is achieved by pre-empting an existing call in service in order to allow a pre-empting call to be served.

This facility only applies to traffic channels that are allocated by means of the ASSIGNMENT_REQUEST command. Traffic channel requests owing to a handover by means of the HANDOVER_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, it should not be confused with the GSM Teleservice 12 Emergency Calls facility which is a separate facility.

Operation

When a new call is to be established and a traffic channel is required, the MSC issues the serving BSC an ASSIGNMENT_REQUEST message which informs the BSC of the pre-emption attributes. 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 in order to serve the new assignment request.

If the PCI flag is set, and the serving cell has no free traffic channels, the BSC searches the existing traffic channel assignments for one that can be pre-empted (that is, its Pre-emption Vulnerability Indicator (PVI) flag is set). If the BSC finds such an assignment, it terminates the existing 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 traffic channel assignment requests.

If the BSC cannot find an existing assignment that can be pre-empted, the new assignment request 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 TCH request and is no longer able to pre-empt an existing assignment, even though it has the PCI flag set.

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

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 and cannot be changed subsequently.

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

Effect

The pre-emption facility can be used to improve the chance that high priority calls are successfully established, even under conditions of high traffic load (provided that the priority calls are 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 of pre-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 traffic handling 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 neighbouring cells when ranking neighbour target cells for handover.

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

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

Operation

All neighbour cells have to fulfil certain entry conditions to be considered as candidates for handover (that is, to be placed in the Preferred Target Cell List). The specific conditions depend on 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 the value 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 the value of ORDER_TC(i) the lower the priority of the respective neighbour cell (i) in the Handover Target Cell List

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

Note: Setting the power budget handover enable flag EN_PBGT_HO (which enables power budget evaluation in the handover threshold comparison process) does not affect generation of 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 OMC terminal via the EN_LOAD_REGARD flag.

When Handover Regarding Traffic Load is enabled, the list of preferred target cells is evaluated based on the Power Budget calculation (described in the previous section), and is extended according 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 loaded cells.

Five FREEfactor_X(n) values, (‘X’ takes the range 1 to 5), are assigned to each neighbour cell according to the number of free channels it can have, (by reference to five bands of possible free channels called FREElevel_X(n)). According to the number of free channels it has 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 (for example, the server and neighbour cell is not controlled by the same BSC) then the default 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 the offset. For simplicity, instead of applying a different offset for every number of free channels, a maximum of five different values of offset is used, based on five bands of free channels. Channel bands and power budget offset values are described in the Handover Regarding Traffic Load section in Chapter 3, and in Appendix A.

To apply the correct power budget offset to each neighbour cell when ranking the neighbour cell handover target cell list, the BSC is advised in which band of free channels each BTS is operating. 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 is used (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 version 8.x.

Note: This option must be registered in the BSS Software Local Configuration area when the BSS software is compiled. Accordingly, customers need to decide when they order the BSS software, 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 is not 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 to FREEfactor_5). One of these is applied according to which of the free channel bands cover the actual 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 (which could otherwise overload a particular cell) amongst surrounding cells that are less heavily loaded.



Issue 1.0 - July 1999 25

This allows more calls to be carried within a given section of the network, thereby improving the grade 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 overlapping interference-free coverage. Any overall network capacity gain will be significantly less than the 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 may cause:

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

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

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



26 Issue 1.0 - July 1999



Traffic Load Management Design

3


Issue 1.0 - July 1999 27

3. Traffic Load Management Design

This chapter describes each traffic management feature and highlights the major design implications 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 of service.

If queuing was not available, and the subscriber’s call was blocked, it is likely that they would attempt to make the call later, thereby unnecessarily using a dedicated signalling channel and associated 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 briefly outlined below.

TOTAL_NUM_Q_PLACE_AVAIL

Traffic channel assignments and handover requests may be queued in the BSS. The same queue is used for both, and the value assigned to TOTAL_NUM_Q_PLACE_AVAIL defines the maximum 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 queue entries. 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 briefly outlined below.

T11 Queuing Timer

When the MSC issues an ASSIGNMENT_REQUEST message, and the serving cell has no available traffic channels, the ASSIGNMENT_REQUEST message is put into a queue, timer T11 is started, and a 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 or ASSIGNMENT_FAILURE message from the BSS to the MSC (i.e. the ASSIGNMENT_REQUEST is removed from the queue).

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

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, the HANDOVER_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 of the required traffic channel by sending to the MSC a HANDOVER_REQUEST_ACKNOWLEDGE or a HANDOVER_FAILURE message respectively (i.e. the HANDOVER_REQUEST is removed from the queue).



30 Issue 1.0 - July 1999

If the value for T_qho is set too low, the opportunity to serve handover requests within a short queue time is lost. If the value is too high, calls may be dropped as alternative handover candidates 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 Miscellaneous Parameters’ sub-menu of the ‘Recent Changes Manual’ menu of the MSC maintenance PC software.

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 is received from the BSC and stops after receiving an ASSIGNMENT_COMPLETE or ASSIGNMENT_FAILURE message from the BSC. On time-out, the MSC issues a CLEAR_COMMAND to the BSC.

If the QUEUING value is set too small, calls will be dropped owing to MSC pre-emption. If the value is too large, unnecessary resources will be used if the mobile fails to seize the ‘new’ traffic channel 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.

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




Issue 1.0 - July 1999 31

PRIORITY information element (GSM 08.08)

GSM allows 14 priority levels allowed during traffic channel assignment. The assigned priority level is passed to the BSS in the information element PRIORITY, and is used to determine how the call request is queued. Use of the PRIORITY information element is described in section 3.2.2.18 of 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 another assignment.

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

• Priority Level Assigns 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 above parameters (depending on the BSS features that are activated).

The MSC populates the PRIORITY information element based on data entered by the user in the MSC configuration. The PRIORITY information element is then included in the ASSIGNMENT_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 the QUEUING_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 be monitored on a cell-by-cell basis, both within the deployment area, and in surrounding cells. This information can be used to compare the results obtained with queuing under different network traffic 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 order to 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. This both 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 they would attempt to make the call later, thereby unnecessarily using a dedicated signalling channel and network transmission and processing resources.

Successful use of directed re-try requires interference-free overlapping cell coverage areas between 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 in the neighbourhood

Mobile support

Some Phase 1 mobiles do not support handover from a SDCCH on one cell to a TCH on a different 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 allocation of SDCCH to frequency hopping timeslots should be avoided.

Therefore, some Phase 1 mobiles do not support directed re-try. However, it is unlikely that many 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 the following 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 to true. 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, by setting 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 are briefly outlined below.



36 Issue 1.0 - July 1999

T7 Handover Required Guard Timer

When the BSC detects that a handover is required, it issues a HANDOVER_REQUIRED message to the 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 Handover Resource Allocation in a second target cell, if the first target cell fails. Timer values below 4s are impractical, as the MSC is not able to complete the Handover Resource Allocation in the first target cell.

If this timer value is set too low, the MSC load and ‘A’ interface message rate increases unnecessarily. If the value is too high, calls may be dropped owing to increased delay in handover 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 over the BSSMAP link to the ‘old’ serving BSC, which has the existing link to the mobile. At the old BSS, timer T8 is started on receipt of the BSSMAP_HANDOVER_COMMAND message. The old BSS then sends a HANDOVER_COMMAND message over the air interface to the mobile, containing the handover reference data for the ‘new’ BSS.

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

If the value of T8 is too small, the resource in the originating cell will be released even if the mobile 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 the originating cell will be used unnecessarily, when (for example), the mobile neither seizes the target cell nor reverts to the old cell, Trr3 in the target cell has not expired, and Trr7 in the MSC has also not expired.

T10 Assignment guard Timer for ‘old’ channel

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



Issue 1.0 - July 1999 37

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

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

T11 Queuing Timer

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

The queuing of the ASSIGNMENT_REQUEST can be terminated by either a successful, or unsuccessful, 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 is removed from the queue).

If timer T11 expires before a successful assignment has been made, and directed re-try is disabled, 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 is enabled, 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 their ASSIGNMENT_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 unnecessary signalling.

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, the HANDOVER_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 of the required traffic channel by sending to the MSC a HANDOVER_REQUEST_ACKNOWLEDGE or a HANDOVER_FAILURE message respectively (i.e. the HANDOVER_REQUEST is removed from the queue).

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



38 Issue 1.0 - July 1999

If timer T_qho expires before a successful handover has been made, and directed re-try is enabled, 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 short queue time is lost. If the value is too high, calls may be dropped as alternative handover candidates 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, and halted 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 is too long, unnecessary radio resources may be used in the target cell, for example, if the mobile does not either seize the ‘new’ channel or revert to the old channel, and T8 in the originating BSS and Trr7 in the MSC not expiring.


Handover Object

The BSS Handover Object flags used by the directed re-try process are set via the OMC terminal, 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 if inter-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 may be necessary to execute a handover at the call establishment stage, or during the communication 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 handover can 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 is used to enable or disable BSC-controlled handover, for handover requests that originate in a specific 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 of requests for inter-cell handover in the individual cells of a BSS.

Disabling BSS-controlled inter-cell handover gives the MSC full decision authority on handover requests, 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 the OMC terminal.

TOTAL_NUM_Q_PLACE_AVAIL

Traffic channel assignments and handover requests may be queued in the BSS. The same queue is used for both, and the value assigned to TOTAL_NUM_Q_PLACE_AVAIL defines the maximum 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 assigned 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 flag to be effective, directed re-try must also be individually activated for each BSC concerned by setting the appropriate elements in their Local Configuration Areas.

This setting can only be made when the BSC software is compiled. The user cannot subsequently change it. To switch on directed re-try at a BSC that does not have its Local Configuration Area already programmed to support it, requires a new version of BSC software to be 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 are fulfilled.

2. Directed re-try is fully supported.

Depending on the directed re-try level settings for DIRRETC1and DIRRET2, directed re-try for traffic channel 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 link reasons

(Level 1 directed re-try facility was implemented for a specific customer and has not been adopted 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 initiates an intra-BSC (BSC-controlled internal) handover. After completing the internal handover, the BSC informs the serving MSC of the identity of the new serving cell, and removes the traffic channel request from the queue. If such a target cell is found, but the target cell does not belong to the same BSS, the BSC requests the MSC to perform an inter-BSC (MSC-controlled external) handover. The queue entry 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 respective connection will be released, and the traffic channel request is removed from the queue.



Issue 1.0 - July 1999 41



42 Issue 1.0 - July 1999

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

LCA Flag

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 of directed re-try)

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

BSC Model

BSC Software

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



Issue 1.0 - July 1999 43

MSC software

The MSC-related flags and timers associated with directed re-try are outlined below. These settings 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 BSC fails 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 after receiving 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 the value is too large, unnecessary resources will be used if the mobile fails to seize the ‘new’ traffic channel 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®, the timer is re-started when a QUEUING_INDICATION message is received during Handover Resource Allocation. The timer stops after receiving a HANDOVER_REQUEST_ACKNOWLEDGE message from the target BSC.



44 Issue 1.0 - July 1999

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

On the last time-out, the MSC sends a HANDOVER_REQUIRED_REJECT to the cell originating the handover 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 the MSC, 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 the MSC). 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 after HANDOVER_COMPLETE is received from the target BSS or HANDOVER_FAILURE is received from the originating 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 increase during handover execution as the MSC prevents the mobile from completing the handover, and from reverting to the old cell. If the value is too large, unnecessary resources will be used in the case 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 System Maintenance message generated. If the value is too large, unnecessary resources will be used in the case of mobile failure (e.g. ALERT or CONNECT not received from the mobile).




Issue 1.0 - July 1999 45

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-MSC Handover

− (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 support both directed re-try and queuing.

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

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-BSC handover procedure. When the BSC internal handover is completed, the BSC informs the serving 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 an ASSIGNMENT_FAILURE message to the MSC, which leads to the release of the respective connection. The corresponding entry for the traffic channel request is discarded from the BSS queue.



46 Issue 1.0 - July 1999

If the serving MSC does not support queuing then it is not possible to provide even a limited directed 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 queuing feature is also used.

If queuing is not used, then the directed re-try may be attempted before sufficient Neighbour Cell measurement reports have been received for an accurate Preferred Target Cell List to be 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. With directed re-try, calls will be re-directed from the best cell when it has no spare channels, to a neighbouring 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 that the 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 value assigned to RXLEV_MIN(i) should be used to set the minimum acceptable handover signal level for neighbour cells (i).

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

Directed re-try should be implemented after network optimisation and definition of the cell boundaries, and subsequent performance should be measured. After activating directed re-try, it may be necessary to make further adjustments to the cell boundaries and handover levels, in order 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.

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



Issue 1.0 - July 1999 47

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-try handover requests are made to the cells on the Target Cell List, the mobile is occupying a SDCCH 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.



48 Issue 1.0 - July 1999


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 designed to 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 to serve mobiles on neighbouring cells

Traffic data

To assess the effect of activating directed re-try, the following performance indicators should be monitored on a cell-by-cell basis, both within the deployment area, and in surrounding cells. This information can be used to compare the results obtained with the use of directed re-try under different 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 order to monitor long-term performance.

Quality data

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



Issue 1.0 - July 1999 49

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



50 Issue 1.0 - July 1999

• Inter-BSC handover success number

Received quality statistics

• An Abis protocol analyser can be used to record RXQUAL data relayed by mobiles in their measurement 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



Issue 1.0 - July 1999 51

Expected effect of activating directed re-try

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

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

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



52 Issue 1.0 - July 1999

3.3. Pre-emption design

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

Pre-emption only takes place during traffic channel ASSIGNMENT_REQUESTS. It does not take place 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 channel ASSIGNMENT_REQUEST will be served.

In all other circumstances, the ‘new’ ASSIGNMENT_REQUEST will be handled as normal, which may result 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 serving and neighbouring cells, PRIORITY assigned to the call, and the features available in the network.



Issue 1.0 - July 1999 53


Pre-emption is available with GSM software 8.x. When pre-emption is deployed, the following network 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’ assignment procedure is followed, which may involve queuing and/or directed re-try when there are no free traffic channels available at the serving cell.

In order to use pre-emption the PREEMPTION_PROVIDED flag must be set ‘True’. In this case, the BSC checks the PVI flag contained in the PRIORITY Information Element of the ASSIGNMENT_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 prevailing network conditions and capabilities. Under these circumstances:

• If free traffic channels exist, the assignment proceeds



54 Issue 1.0 - July 1999

• If no free traffic channels exist, and queuing and directed re-try are not enabled, the request is 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 take place:

• 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 information element in the ASSIGNMENT_REQUEST message.

The PRIORITY information element contains:

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

• Pre-emption Capability Indicator (PCI), which defines whether or not the assignment may pre-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 the PRIORITY information element is not contained within the ASSIGNMENT_REQUEST or HANDOVER_REQUEST messages, both the PVI and PCI flags are set to 0 (False). That is, the assignment cannot itself be pre-empted nor can it pre-empt others



Issue 1.0 - July 1999 55

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 Local Configuration Area. By default this flag is set to 0, (False). This flag is not adjustable via the OMC 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 not take place

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



56 Issue 1.0 - July 1999

3.4. Handover Regarding Traffic Load design

Handover Regarding Traffic Load (HORTL) is a Lucent BSC-controlled facility, and requires no specific support from the MSC. When this facility is operating, the BSC takes the traffic load of the 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 is assigned an offset value, which is applied to the power budget calculation when the handover target ‘best cell’ is determined. The fewer free channels that a cell has available, the higher the weighting applied against handover to that cell.

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


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




Issue 1.0 - July 1999 57

OMC - BSC software configuration

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

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_1 FREElevel_2 FREElevel_3 FREElevel_4

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

FREEfactor_1 FREEfactor_2 FREEfactor_3 FREEfactor_4 FREEfactor_5

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

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




58 Issue 1.0 - July 1999

Dependencies

Introduction of HORTL is dependent on the following:

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

Note that this is fixed at software compilation, and cannot be retrospectively changed without generating 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 of free 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 traffic channels

• 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



Issue 1.0 - July 1999 59



Appendices


Issue 1.0 - July 1999 61

Appendix A. Parameter Values

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

• Queuing

• Directed re-try

• Pre-emption

• Handover regarding traffic load



62 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

TOTAL_NUM_Q_ PLACE_AVAIL

Defines maximum BSS queue entries for channel assignments and HO requests

0 to 100

(0 disables queuing)

5 (if queuing is enabled)

0 (if queuing is disabled)

Q_THRESHOLD_VAL Defines a performance measurement threshold as a percentage of maximum queue 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 guard timer (defines maximum time a HO request 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)

Customer specific

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

27s

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

Assignment guard timer used during dedicated assignment

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

30s



Issue 1.0 - July 1999 63

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



PCI Indicates whether a traffic channel request can pre-empt an established call

1 (True) - enables pre-emption 0 (False) - disables pre-emption

PVI Indicates whether a traffic channel request can be pre-empted by another assignment


QA Queuing allowed indicator 1 (True) queuing allowed 0 (False) queuing not allowed

Priority level Assigns a priority level to an assignment request

1 (highest priority) to 14 (lowest priority)

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



64 Issue 1.0 - July 1999

Directed re-try parameters

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

OMC software


EN_SDCCH_TCH_HO Enables/disables directed re-try in the BSS

True (enabled) False (disabled)

False

Note: For this parameter to be effective, directed re-try must also be activated for each BSC concerned (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 dedicated assignment

1s to 5mins 4s

T_qho HO resource allocation queue guard timer

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 65

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 SDCCH HO is permitted. Only meaningful if inter-cell HO is enabled (controlled by flag EN_INTER_HO).

0 (no/false) 1 (yes/true)

1

EN_BSS_HO Enables/disables BSC-controlled (internal) handover for HO requests that originate 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


TOTAL_NUM_Q_ PLACE_AVAIL

Defines maximum length of the BSS queue for TCH assignments and HO requests

0 to 100

0 (if queuing disabled) 5 (if queuing enabled)

Q_THRESHOLD_VAL Defines a threshold (used for performance measurement) as a percentage of maximum queue entries

0% to 100% 80%

BTS parameters are set using the OMC terminal.



66 Issue 1.0 - July 1999

MSC software


BSS_QUEUING_ ALLOWED

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

Customer specific

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

27s

ASSIGN (for 5ESS®) or Trr1 (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®) or Trr2 (for T-Mobil)

HO resource allocation guard timer for intra-MSC HO HO resource allocation guard timer in anchor MSC for inter-MSC HO

Time needed to activate TCH in target cell <Trr2<T7

4s

HO_CMPLT_CON_ T102

HO execution guard timer Value must be greater than time needed for mobile to revert to ‘old’ cell and send HANDOVER_ FAILURE message (approx. 10s) Trr3 must be <= HO_CMPLT_CON_T102 <=T8

28s

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

12s

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



Issue 1.0 - July 1999 67

Pre-emption parameters



PCI Indicates whether a traffic channel request can pre-empt an established call


PVI Indicates whether a traffic channel request can be pre-empted by another assignment


QA Queuing allowed indicator 1 (True) - queuing allowed 0 (False) - queuing not allowed

Priority level Assigns a priority level to an assignment request

1 (highest priority) to 14 (lowest priority)

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



68 Issue 1.0 - July 1999

Handover Regarding Traffic Load parameters

BTS object


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

0

FREELEVEL_1 FREELEVEL_2 FREELEVEL_3 FREELEVEL_4

Specifies boundary values for free channel bands

0 to 255 (resolution of 1)

1 2 3 4

FREE_FACTOR_1 FREE_FACTOR_2 FREE_FACTOR_3 FREE_FACTOR_4 FREE_FACTOR_5

Specifies offset values applied to the power budget calculation, according to the number of free channels the cell has when the HO target cell list is ranked

0 to 32 (resolution of 1 - representing 1dB) 0 represents -16dB 1 represents -15dB … 32 represents +16dB

FREE_FACTOR_1=14 representing -2dB FREE_FACTOR_2=15 representing -1dB FREE_FACTOR_3=16 representing -0dB FREE_FACTOR_4=17 representing +1dB FREE_FACTOR_5=18 representing +2dB



Issue 1.0 - July 1999 69

Appendix B. Future Developments

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

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

Handover due to Traffic Load overview

The HODTL feature will improve the peak traffic handling capacity of a group of cells which have some 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 handover from overloaded cells to those with greater spare capacity (provided that adequate radio link quality can be maintained by the cell with spare capacity).

HODTL is intended to assist with temporary cell overloads, and not as a means to increase general 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 up to 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 the region of 10 to 15%

• Reduced blocking levels owing to less queuing and directed retry activity. This is due to a reduction 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 processing load, together with an increase in the chance of dropped calls

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

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

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



70 Issue 1.0 - July 1999

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

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

The LINKfactor(0,i) may be used to fix the power budget handover to certain cells. This may be used to control handover of dual band mobiles, or to prevent handover of fast moving mobiles from 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 software Local Configuration Area.

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

HODTL will be used between cells operating on different bands, provided that they are linked to the same BSC. So for co-located 900 and 1800 band cells (subject to an adequate proportion of dual band mobiles) the traffic load can be redistributed between the different bands if one of the cells 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 cell evaluation process (primarily for mandatory handover), in which the traffic load in both the serving 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 the HORTL 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 budget handover reduces the chance of unnecessary repeated handover

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



Issue 1.0 - July 1999 71

Implementation

When the BSC software flag EN_TL_HO is set as ‘True’, HODTL will be enabled and will use a modified 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



72 Issue 1.0 - July 1999



List of Acronyms


Issue 1.0 - July 1999 73

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



74 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 75

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



76 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. Your comments 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 Applicable Ease of use Clarity Completeness Accuracy Organisation Appearance Examples Illustrations Overall 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

telecommunication traffic load management

Documents

traffic load design

traffic load management

traffic load parameters

traffic load overview

handover object

bts object

bsc object

network elements