GSM Traffic Load Eg

GSM Traffic Load Management
Engineering Guideline
EG: GSMTRM 401-380-362 Issue 1.0 July 1999
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
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)
Lucent Technologies - PROPRIETARY

Use pursuant to Company instructions
ii
Issue 1.0 - July 1999
Contents
1. ABOUT THIS GUIDE

1.1. 1.2. 1.3. 1.4. 1.5. Purpose Contents Scope Intended audience Further reference
1
1 2 2
2 3
2. INTRODUCTION TO TRAFFIC LOAD MANAGEMENT

2.1. Background
5
5 6 6 6 6
2.2. Key benefits Benefits for PTOs Benefits for subscribers Benefits for regulatory authorities 2.3. Traffic load management methods Queuing Directed re-try Pre-emption Handover Regarding Traffic Load
7 7 13 20 22
3. TRAFFIC LOAD MANAGEMENT DESIGN

3.1. Queuing design Network elements and interfaces Dependencies Effect of implementation 3.2. Directed re-try design Mobile support Network elements and interfaces Timers in MSC / BSC-controlled handover Dependencies Effect of implementation Expected effect of activating directed re-try 3.3. Pre-emption design
Lucent Technologies -- Proprietary This document contains proprietary information of Lucent and is not to be disclosed or used except in accordance with applicable agreements.
27
28 28 32 32 34 34 35 44 45 47 50 51
iii
Contents
Network elements and interfaces Dependencies Limitations 3.4. Handover Regarding Traffic Load design Network elements and interfaces Dependencies Limitations Effect of implementation 52 54 54 55 55 57 57 57
APPENDIX A. PARAMETER VALUES

Queuing parameters BTS object BSC object MSC software PRIORITY information element (GSM 08.08) Directed re-try parameters OMC software BSC object Handover object BTS object MSC software Pre-emption parameters PRIORITY information element (GSM 08.08) Handover Regarding Traffic Load parameters BTS object
59
60 60 60 60 61 62 62 62 63 63 64
65 65
66 66
APPENDIX B. FUTURE DEVELOPMENTS

Handover due to Traffic Load overview
67
67
LIST OF ACRONYMS COMMENTS FORM
71 75

iv
About this Guide
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.

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 redistributing 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 Managers or administrative staff who need an overview of the technical design process Lucent Technologies - PROPRIETARY
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.

This page is intentionally left blank

Introduction to Traffic Load Management
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

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 PTOs 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

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:

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

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.

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

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

11
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

12
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:

13
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
Note: For a description of the Tn and TRRn timers mentioned in Figure 3, refer to Appendix A.

14
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
Note: For a description of the Tn and TRRn timers mentioned in Figure 4, refer to Appendix A. 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.

15
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 useradjustable 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 from the number of measurement values that have been shifted into the

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

17
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 BSCcontrolled 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.

18
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 Greater use of installed equipment 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

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

20
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

21
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

22
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

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

24
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 Greater use of installed equipment
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

25

26
Traffic Load Management Design
3. Traffic Load Management Design

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

27
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 subscribers 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 Software Hardware OMC MSC STF BSC BTS Mobile
Yes No
Yes No
No No
Yes 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 Hardware
Yes No
No No
Yes No
No No
No No
No No
Queuing is available with GSM software version 8.x.

28
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

29
HANDOVER_FAILURE
message respectively (i.e. the HANDOVER_REQUEST is removed from the
queue). 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. For more details about these settings, refer to Appendix A. 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.

30
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. For more details about these settings, refer to Appendix A.
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.

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

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

33
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 subscribers 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 redirected 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.

34

Implementation of directed re-try affects the network elements and interfaces listed below: Network element
Yes No
Yes No
No No
Yes No
No No
No No
Network interface
Software Hardware
Yes No
Yes No
Yes No
No No
No 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 R4.0
MSC 10.1 lpr8.0
BCE LM4.0
BCF 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.
T7
Handover Required Guard Timer

35
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. Lucent Technologies - PROPRIETARY
36
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
T_qho
Handover Resource Allocation Queue Guard Timer

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

37
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. 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. For more details about these settings, refer to Appendix A. 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.

38
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. For more details about these settings, refer to Appendix A. 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)

39
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. 1. SDCCH TCH handover is not permitted (directed re-try is disabled). Directed re-try is only supported during queuing if the mandatory handover criteria are fulfilled. Directed re-try is fully supported.
2.
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 / is being queued, and a mandatory handover occurs owing to radio link reasons
HANDOVER_REQUEST
(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 is being queued, and a mandatory handover occurs owing to radio link reasons
REQUEST
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. Lucent Technologies - PROPRIETARY
40
The effect of the BSC Local Configuration Area values associated with directed re-try are as follows:
LCA Flag DIRRETC1 DIRRETC2 QUEPROV
Effect
Set to enable directed re-try during handover Set to enable directed re-try during traffic channel assignment 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 BCE BCE
BSC Software
LM4.0 LM5.0
OPTION
Several 1
DIRRETC1
DIRRETC2
QUEPROV
True
True
True
BCF BCF
R1 R2
I 1
True True
True True
True True

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

42
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). For more details about these settings, refer to Appendix A.

43
Timers in MSC / BSC-controlled handover

Different timers are used according to whether the directed re-try is BSC-controlled or MSCcontrolled. 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 T8
Handover Required Guard Timer 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 Lucent Technologies - PROPRIETARY
44
connection. The corresponding entry for the traffic channel request is discarded from the BSS queue. 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.

45
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:
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.

46
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:

47
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

48
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

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

50
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
ASSIGNMENT_REQUEST
If the above criteria are met, the pre-empted call is released, and the new traffic channel 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.

51

Pre-emption is available with GSM software 8.x. When pre-emption is deployed, the following network elements are affected: Network elements
Yes No
Yes No
No No
Yes No
No No
No No
Network interfaces
Software Hardware
Yes No
No No
Yes No
No No
No 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

52
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 reassigned 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
For more details about these settings, refer to Appendix A. 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

53
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

54
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
Yes No
No No
No No
Yes No
No No
No No
Network interfaces
Software Hardware
Yes No
No No
No No
No No
No No
No No

55
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. For more details about these settings, refer to Appendix A.

56
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

57

58
Appendices
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

59
Queuing parameters
This section describes the parameters used to implement and configure the queuing facility.
BTS object
Name
TOTAL_NUM_Q_ PLACE_AVAIL
Description Defines maximum BSS queue entries for channel assignments and HO requests
Allowable values 0 to 100 (0 disables queuing)
Default 5 (if queuing is enabled) 0 (if queuing is disabled) 80%
Q_THRESHOLD_VAL
Defines a performance measurement threshold as a percentage of maximum queue entries
0% to 100%
BTS parameters are set using the OMC terminal.
BSC object
Name
T11
Description Queuing timer
Allowable values 1s to 5min
Default value 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
Name
BSS_QUEUING_ ALLOWED QUEUING (for 5ESS) ASSIGN (for 5ESS) or Trr1 (for T-Mobil)
Description Enables/disables BSS queuing
Allowable values True (enabled) False (disabled) Value must be > T11 timer Value must be > T11 + max (T10, T3107)
Default value Customer specific 27s
Specifies the maximum queuing time Assignment guard timer used during dedicated assignment
30s
MSC parameters are set using the MSC maintenance PC (via the Recent Changes Manual menu, MSC pages WBOPM 61.2 and 61.3). Lucent Technologies - PROPRIETARY
60

Name
PCI
Description Indicates whether a traffic channel request can pre-empt an established call
Allowable values 1 (True) - enables pre-emption 0 (False) disables preemption
Default value
PVI
Indicates whether a traffic channel request can be pre-empted by another assignment
1 (True) - enables pre-emption 0 (False) disables preemption
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).

61
Directed re-try parameters

This section describes the parameters used to implement and configure the directed re-try facility.
OMC software
Name
EN_SDCCH_TCH_HO
Description Enables/disables directed re-try in the BSS
Allowable values True (enabled) False (disabled)
Default 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
Name
T7
Description HO required guard timer
Allowable values 5s to 60s Value must be > T7_IHO
Default 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 HO resource allocation queue guard timer
1s to 5mins
4s
T_qho
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.

62
Handover object
Name
EN_SDCCH_TCH_HO
Description Enables/disables directed re-try
Allowable values 0 (no/false) 1 (yes/true)
Default value 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). Enables/disables BSC-controlled (internal) handover for HO requests that originate in a specific cell of a BSS
0 (no/false) 1 (yes/true)
EN_BSS_HO
0 (no/false) 1 (yes/true)
Handover object parameters are set using the OMC terminal.
BTS object
Name
TOTAL_NUM_Q_ PLACE_AVAIL
Description Defines maximum length of the BSS queue for TCH assignments and HO requests
Allowable values 0 to 100
Default value 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.

63
MSC software
Name
BSS_QUEUING_ ALLOWED QUEUING (for 5ESS) ASSIGN (for 5ESS) or Trr1 (for T-Mobil)
Description Enables/disables BSS queuing Specifies the maximum queuing time Assignment guard timer
Allowable values True (enabled) False (disabled) Value must be > T11 timer Value must be > T11 + max (T10, T3107) If above is obeyed Trr1 > T11 + T10
Default value Customer specific 27s 30s
HO_ACK_T101 (5ESS) or Trr2 (for T-Mobil) HO_CMPLT_CON_ T102
HO resource allocation guard timer for intra-MSC HO HO resource allocation guard timer in anchor MSC for inter-MSC HO HO execution guard timer
Time needed to activate TCH in target cell <Trr2<T7 Value must be greater than time needed for mobile to revert to old cell and send
HANDOVER_ FAILURE message
4s
28s
(approx. 10s) Trr3 must be <=

HO_CMPLT_CON_ T102 <=T8 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).

64
Pre-emption parameters
Name
PCI
Description Indicates whether a traffic channel request can pre-empt an established call
Allowable values 1 (True) - enables pre-emption 0 (False) disables preemption
Default value
PVI
Indicates whether a traffic channel request can be pre-empted by another assignment
1 (True) - enables pre-emption 0 (False) disables preemption
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).

65
Handover Regarding Traffic Load parameters BTS object

Name
EN_LOAD_REGARD
Description Enables/disables HORTL
Allowable values 1 (enables) 0 (disables)
Default value 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=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
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

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

67
These effects can be mitigated to some extent by the values used for the HO_MARGIN(0,i), FREEfactor_X (where X takes values 1 to 5), and LINKfactor(0,i) . The HO_MARGIN(0,i) value may be used to avoid unnecessary repeated handover between cells 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.

68
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

69

70
List of Acronyms
List of Acronyms
The following acronyms are used in this document: BCCH BCE BCF BER BSC BSS BSSAP BTS CCCH CHN CIR Broadcast Control Channel BSS Controller Equipment Base Station Controller Frame Bit Error Rate Base Station Controller Base Station System Base Station System Application Part Base Transceiver Station Common Control Channel Channel Carrier to Interference Ratio

71
EAC EGSM EIR FCCH FH GSM HODTL HORTL HLR IMSI ISUP LAN MAP MNC MSC NPMS ODD OMC PCI PGSM PLMN PSTN PTO PVI RF
Emergency Authority Cell of Origin Extended GSM (900MHz band extension) Equipment Identity Register Frequency Correction Channel Frequency Hopping Global System for Mobile Communications Handover Due to Traffic Load Handover Regarding Traffic Load Home Location Register International Mobile Subscriber Identity Integrated Services Digital Network User Part Local Area Network Mobile Application Part Mobile Network Code Mobile Switching Centre Network Performance Monitoring System Office Dependent Data Lucent Technologies Operations and Maintenance Centre 2000 Pre-emption Capability Indicator Primary GSM (public 900MHz basic GSM band) Public Land Mobile Network Public Switched Telephone Network Public Telephone Operator Pre-emption Vulnerability Indicator Radio Frequency

72
RT RXLEV RXQUAL SACCH SCH SDCCH SIM STF TCH TMSI TRX VLR
Radio Terminal Received Signal Level Received Signal Quality Slow Associated Control Channel Synchronisation Channel Standalone Dedicated Control Channel Subscriber Identity Module Speech Transcoder Frame Traffic Channel Temporary Mobile Station Identifier Transceiver Visitor Location Register

73

74
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 Ease of use Clarity Completeness Accuracy Organisation Appearance Examples Illustrations Overall Satisfaction Good Fair Poor Not Applicable
2. Please place a tick against any improvement that could be made to this Information Product:
Improve the overview/introduction Improve the table of contents Improve the organisation Include more figures Add more examples Add more detail Make it more concise/brief Add more step-by-step procedures/tutorials Add more troubleshooting information Make it less technical Add more/better quick reference aids Improve the index
3. Please provide details for the suggested improvement in the box below:

Comments Form
4. What did you like most about this Information Product:
5. Any additional comments:
6. If we may contact you concerning your comments, please complete the following:
Date: Name: Company/Organisation: Address: Job Title: Telephone No:
When you have completed this form, please fax a copy to: The Technical Manager, CTIP-UK, Fax Number (+44) 1666 824515


GSM Traffic Load Eg

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GSM Traffic Load Eg

Uploaded by

Copyright:

Available Formats

GSM Traffic Load Management

GSM Traffic Load Management Engineering Guideline

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

1. ABOUT THIS GUIDE

2. INTRODUCTION TO TRAFFIC LOAD MANAGEMENT

3. TRAFFIC LOAD MANAGEMENT DESIGN

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

APPENDIX A. PARAMETER VALUES

APPENDIX B. FUTURE DEVELOPMENTS

LIST OF ACRONYMS COMMENTS FORM

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

About this Guide

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

The following documents are recommended for additional reference information:

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

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

This page is intentionally left blank

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

Introduction to Traffic Load Management

2. Introduction to Traffic Load Management

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

Benefits for PTOs

Benefits for subscribers

Benefits for regulatory authorities

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

Traffic load management methods

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

Figure 1 Signal flow during assignment request queuing

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

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

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999

GSM Traffic Load Management Engineering Guideline

Lucent Technologies - PROPRIETARY

Issue 1.0 - July 1999