GSM Basics_1

Microcellular Engineering Book

MicrocellularEngineering

Book

Jan, 1999

Revision 0.4

Motorola Confidential Proprietary ANDC


Abstract: This document contains all the key topics related to the Microcellular technology and its applications.

CONTENTS

SIGN-OFF FORM 5

1. INTRODUCTION 6

2. WHAT IS A MICROCELLULAR SYSTEM? 6

2.1 Limitations of Macrocellular 6

2.2 Microcells 7

2.3 Motorola Microcellular System : Benefits 8

3. NETWORK DESIGN & IMPLEMENTATION 9

3.1 Deployment Strategies 9

3.2 Antenna location & types 103.2.1 Microcell location 103.2.2 Antenna Height & Types 11

3.3 Capacity 133.3.1 System Capacity: City Centre Example 14

3.4. Traffic 153.4.1 Classification of microcells 163.4.2 Types of traffic on microcells 163.4.3 Practical Case: Traffic in a large deployment 17

3.5 RF Planning 19

3.6 PERFORMANCE MONITORING 21

4. MOBILITY IN MULTILAYER NETWORKS 23

4.1 Handover Process 234.1.1 Description 234.1.2 Handover Types 244.1.3 Handover Priority 24

4.2 Motorola PBGT Algorithm 254.2.1 Standard Configuration (Type 1). 264.2.2 Line of Sight Configuration (Type 4) 274.2.3 Around-the-Corner Configuration (Type 3). 274.2.4 Qualified Neighbour Configuration (Type 5). 284.2.5 Dynamic Handover Margin Configuration (Type 6). 294.2.6 Adjacent channel neighbours (Type 7). 30

4.2.6.1 Interference avoidance test 30

4.3 Imperative Handovers & Type 2 Neighbours 30

4.4 Candidate Ordering 31



4.5 Missing Reports & Missing Neighbours 33

4.6 Motorola Multilayered System Philosophy 33

5. OPTIMISATION 35

5.1 HANDOVER STRUCTURE 355.1.1 INTER-LAYER HANDOVERS 35

5.1.1.1 HANDING DOWN 365.1.1.2 HANDING UP 365.1.1.3 MAINTAINING THE CALL IN THE MICRO LAYER 38

5.2 IDLE MODE BEHAVIOUR 39

5.3 Site integration 40

6. ADDITIONAL MULTI-LAYER FEATURES 42

6.1 Directed Retry & Congestion Relief 426.1.1 Directed Retry 426.1.2 Congestion Relief 446.1.3 Application & Parameters 45

6.2 Fast Initial MS Power Down 496.2.1 Description 496.2.2 Application & Parameters 50

6.3 Different neighbour lists in BCCH (idle) and SACCH (dedicated) 506.3.1 Description 506.3.2 Application 52

6.4 Speed Handover Defined per-neighbour (hreqave). 526.4.1 Description 526.4.2 Application 52

6.5 Prefer Different Carrier for Intracell Handover 536.5.1 Description 536.5.2 Application 53

6.6 Limited Number of Intracell Handovers 556.6.1 Description 556.6.2 Application & Parameters 55

6.7 Handover Margin per Cause 566.7.1 Description 566.7.2 Application 57

6.8 Timed Offset upon RXQUAL Handover 57

6.9 Micro – Micro Quality Handover 606.9.1 Description 606.9.2 Application 61

6.10 Handover based on path loss calculation 626.10.1 Application 63

6.11 All channels at full power 63



6.12 Advanced handover statistics 63

7. UNDERLAYING OTHER VENDORS 64

7.1 Ericsson 64

7.2 Alcatel 65

7.3 Siemens 66

7.4 Nokia 66Umbrella handovers. 66

APPENDIX A 67

PBGT Configurations Description 67

APPENDIX B 70

Averaging Settings 70

APPENDIX C 76

Power Control Settings 76



SIGN-OFF FORM

Author: Javier Escamilla Signature: Date: September 98

Revised: Roberto García Signature: Date: September 98

Contributions: Gabriel Nagy Signature: Date:

Revised: Fernando Sancho Signature: Date: December 98

Revised: Signature: Date:



1. IntroductionThe purpose of this document is to explain how layered cell structures are

implemented by the Motorola BSS software features. Motorola has designed the layered technology over several years and since 1994 it has been tested in real systems in multiple field trials. This development has allowed Motorola to lead this technology and gain a broad experience. The original BSS software product has been modelled and optimised through this experience and several new features have been added.

In 1996, operators started to deploy layered technology as a solution for their capacity problems. Motorola was chosen as a vendor and provided technical support for a number of multi-layer projects world-wide, including several very large Microcellular deployments in Europe currently being carried out (over 400 microcells in single cities). The wealth of experience collected in these projects has allowed Motorola to identify the real needs and wishes of the operators; the Motorola Layered Technology has addressed these needs.

Motorola Technology provides the operator with flexibility to cope with specific problems and is designed to be easy to implement and optimise. A range of specific Motorola tools are available for the planning, optimisation and control of multi-layer environments.

2. What is a Microcellular System?2.1 Limitations of Macrocellular

In the initial steps of a conventional cellular network, deployments are implemented to provide coverage over a wide geographical area. It is advantageous for the operator to make these cells as large as possible in order to keep infrastructure costs to a minimum. As the mobile usage increase, operators look to provide more specific coverage and capacity focused on subscriber requirements.

The density of subscribers supported is a function of frequency allocation, frequency re-use patterns and propagation distances. As the number of subscribers, and subsequently the traffic requirements increase, operators are required to reduce cell size to increase capacity. This is a typical situation in a large urban area. Initially the capacity increase is achieved through sectorisation and then through 'cell splitting' (sites with reduced coverage). This restriction of propagation is achieved using 'downtilted' antenna systems. These methods still require the use of expensive rooftop locations and suffer from interference problems as a consequence of the difficulties to predict the propagation patterns. Macrocells cannot provide the coverage and capacity performance required by the future cellular networks.

As capacity requirements increase within digital cellular networks, cell sizes are reduced at a rapid rate. The number of cells required increases until a saturation point is reached when the available frequency resource and the physical location of equipment limits what can be achieved with traditional cell planning techniques.

Additional cells are also deployed to meet increased coverage needs, particularly as the use of handportables increases the expectation of the subscriber and extends the areas of cellular operations to within buildings. Although macrocells can be used to provide in-building coverage, the quality of coverage achieved does not meet subscribers expectations.



Smaller cells also begin to stretch frequency re-use rules and the ability of locating carriers in close proximity to each other. Adjacent channel and co-channel criteria are stretched in the small cell environment, the ability to meet GSM specified levels are severely tested and restrict what can be achieved without significant degradation of network performance.

These operational limitations restrict the minimum radius of a macrocell to about 500m, which is not small enough to meet the capacity and coverage requirements of dense urban networks.

2.2 Microcells

A “microcell' is defined as “a cell in which the base station antenna is generally mounted below rooftop level. Radio wave propagation is determined by diffraction and scattering around buildings, the main rays propagating within street canyons.”

RF Signal

Figure 1: Street Canyon propagation effect

Microcells typically have a radius of 150-300 metres and exhibit transmission behaviour, which differs from conventional large or small cells. Propagation is primarily “line of sight” and radio path loss increases sharply as the receiver moves out of sight of the transmitter (i.e. as you turn a street corner).

Microcells differ greatly from the conventional macrocell, which provides 'umbrella' coverage over a wide area, by providing focused coverage and capacity over all or part of the



macrocell coverage area. Microcells offer improved propagation properties, experience less severe fading and effectively provide increased logical bandwidth resulting in a lower level of error transmission at high bit rates. Microcells also require lower transmision powers than conventional macrocells.

In the Motorola multi-layer network approach, a complete microcellular network is deplyed under the existing macrocell network. Cells of different sizes are overlaid, and base stations with different transmit power levels co-exist in close proximity.

The wide coverage area with high powered macrocells is considered as the Overlay network. The macrocells will provide wide coverage and act as a "safety net" for mobiles moving between microcellular areas. The low powered microcells that are installed within the high traffic areas of the network can be considered as the Underlay network.

Through the right choice of the microcell site locations, an improved and flexible coverage may be provided, increasing the capacity through tighter frequency re-use and smaller cell sizes. This is possible due to the street canyon effect dominating the RF propagation. With a proper location of the antennae (6 metres to 2/3 the height of the building) the coverage provided is constrained by the surrounding buildings and the re-use pattern can be much tighter as the inter-micro interference can be controlled.

Re-use patterns of 3 x 1 (three frequency sets for the whole two carriers system) have been implemented in some systems over the entire microcellular portion of the network, by making use of the flexibility Motorola’s software provides. Capacity figures over 300 erlangs/km2 have been achieved without any degradation in the quality of service offered.

2.3 Motorola Microcellular System: Benefits

The main goal of a Layered System is to solve the capacity problems of a network through a much more flexible and tighter re-use of the available frequencies in the lower layers. The location of the low-level (underlay) sites will be determined by the capacity and traffic requirements, providing the capacity where it is needed. The way Motorola has implemented its Layered System is extremely flexible as multiple layers can be defined in the system such as umbrella, macrocell, microcell, minicell, concentric cell or picocell layers.

The main reason operators have decided to implement a Microcellular Layered System is to solve their capacity requirements, thereby increasing the quality of service offered to their customers. In addition, there are other benefits gained with the deployment of a Microcellular Network:

Controlled Coverage

Controlled coverage is inherent to a microcellular system, therefore the interference generated is also controlled. Further, the flexibility of locating microcells in areas of high traffic permits capacity to be tailored to non-homogenous traffic distributions.

In-building coverage

Improved in-building coverage is provided even if the antennas are externally located.



Apart from the high signal levels provided outdoors, the penetration loss to in-building areas will be less when the incidence angle is close to perpendicular. The smaller the coverage area of the microcells, the more perpendicular the incidence angles will be and, therefore, the smaller the penetration loss.

Immunity to fading

In a microcellular system the subscribers located in the streets will be in the line-of-sight (LOS) from the antenna. In this scenario, the fading experienced in the received signal will approximate a Rician distribution. This is much smoother than the Rayleigh distribution, which governs the fading in a standard Macrocellular System. Further, when the incidence angle of a microcell in an in-building area is close to perpendicular, the fading will be also being smoother.

Reduction in mobile tx power

As the received signal levels will typically be high in a microcellular network, the mobile will be transmitting with low power values. This has two immediate effects: less interference radiated in the uplink and extended battery life of the subscriber’s mobiles.

Introduction of Picocellular concept

If total in-building coverage is essential (e.g. strategic buildings), internal antennas may be located within the building itself. These ‘picocells’ may use the same microcellular software as it has been designed to facilitate this scenario.

3. Network Design & Implementation3.1 Deployment Strategies

After many systems deployed, it has been easy to identify in which situations we implement microcells and what are the configurations to cope with them. There are typical situations where microcells are deployed:

Capacity relief in hot-spot locations. Traffic is concentrated and produces blocking in certain cells. In this situation microcells are planned to put the capacity where needed. At the same time, coverage and quality are improved to the high number of subscribers generating the traffic, without introducing interference to the rest of the system, as it would be done by adding new radios to the macrocells (assuming this would be possible).

Capacity relief in saturated areas (business areas, commercial centres, etc.). Macrocellular expansions are difficult to plan there as the system has reached its minimum cell size. There are not frequencies available for adding new radios in macro stations and even if that would be possible, they would not provide the erlang density required.

Easy capacity expansion system wide as the number of subscribers increases. The system is mature, and the cell radius is minimum. High capacity solutions must be used. Other solutions are short term, as they do not provide the same capacity and quality. Sometimes they are difficult to implement , more expensive, and do not have extra values added as the quality and coverage improvement, the better in building penetration, the lower interference added, the longer mobile battery life, etc.

In a Macro-Micro Layered System three are the typical configurations implemented to



cope with the situations exposed above:

Isolated microcells deployed in hotspot locations coping with specific capacity requirements in a certain area. These microcells would re-use frequencies from the macro layer, and microcellular algorithms are only used to go down from the macro layer.

Sparsely connected microcells. These are loosely interconnected microcells. This is the natural system growth from hot-spot configuration. This configuration covers capacity problems in a certain area. In this configuration microcellular algorithms are used not only to go down from the macro layer but also to perform handovers between microcells.

Contiguous microcellular network underlaying the standard macrocellular system. In this case a dedicated part of spectrum for the microcellular network is desired, even if not entirely necessary. Microcellular algorithms will be needed to maintain the call in the micro layer and to address specific scenarios that appear in the new propagation environment (antennas bellow roof level and street canyon propagation effect).

HotspotsHotspots MicrocellularMicrocellularContiguous SystemContiguous System

MacrocellMacrocell

Figure 2: Microcellular Configurations

3.2 Antenna location & types

3.2.1 Microcell locationOnce microcellular deployment has been decided, the most appropriate location for

microcells must be chosen. The antenna location will be critical or not depending on the goals of the deployment.

If microcells are installed in a hot spot or in a dense area, antenna position will be very important, as it is required to take maximum traffic and to relieve as much as possible certain congested cells in the macro layer.

A first approach to choose micro location would be to use macro traffic stats in the hot



spot area. If more accuracy is needed, hot spot detection would be required. This means to put a base station transmitting where the microcell would be located. This station would be previously defined as a macrocell neighbour in that area. Collecting MRA or trace_call data from the macrocells, it is possible to know at which levels the base station under test is reported as neighbour. There is a software made inside Motorola to analyse MRA data. CTP (Call Trace Product) has an option for hot spot detection trough trace call data analysis as well. With these programs it can be seen the amount of measurements that report the test base station with a higher level than the server. This would roughly give us an indication about what would be the amount of traffic sucked from a macrocell if the microcell would be placed in that position.

If the purpose is to deploy a big amount of microcells in order to build a continuos layer, they should be located where the maximum amount of traffic is taken, as these subscribers will have better quality. New micro stations will be cost effective then. In this case, the knowledge of the area is an advantage. General rules should be applied: antennas giving coverage to more than one street (in corners, squares, crosses etc.), distance between micros short enough to go from one micro to another without going up to the macro layer because of quality degradation, etc. With good level in the streets, indoor coverage is improved and then, new traffic is generated.

3.2.2 Antenna Height & TypesOne key parameter that is going to determine the size of the microcell is the antenna

height. Usually antennas are located 6-10 m high and always bellow roof level. This could be higher in order to have bigger cells ( i.e. in systems where signal is guided trough the streets and at any time we have controlled the cell coverage) or lower to have smaller cells (i.e. systems where the signal propagation and then, the interference we introduce to the system, is not controlled – isolated buildings in open spaces, hilly terrain, etc.- ).

Antenna types widely used are:

Omnidirectional: Pipe mounted. The gain is usually between 0 and 5 dBi. This is one of the most commonly used for general purposes, but specially indicated in open areas (squares, crosses, etc.) and cities where streets are guiding our signal and determine the cell coverage pattern.

Figure 3: Omni Antenna



Directional: Wall mounted. This antenna has a gain between 6.5 and 12.5 dBi, with a wide vertical beam. It is used to focus the radiation to one desired area without introducing interference in all directions. Different sector antennas are found in the market 60º, 90º, 120º, etc

Figure 4: Sector Antenna

Bidirectional: Wall mounted. Around 7 dBi gain. Specially useful to be located in the middle of the street that is intended to be covered.

Figure 5:Bilobular Antenna



3.3 CapacityProbably the best justification for introducing a microcellular architecture is for

spectrum efficiency and high capacity reasons. This is particularly true in densely populated urban environments, where the use of a microcell base station with a low transmit power allows small frequency re-use distances, a high number of channels per unit area, and hence a greatly increased traffic density.

The use of dedicated microcell coverage areas allows more efficient utilisation of the allocated spectrum whilst maintaining the performance. As capacity requirements increase, microcells can be reduced in size and effectively split to increase the traffic density of any particular region/area. This gives the flexibility to meet the needs of a non-uniform traffic environment that will include the use of dedicated in-building ‘pico’ cells.

Within such a network, macrocells can be deployed as a safety net. In this case, the number of channels per unit area could be optimised in accordance with the demand. By splitting the radio spectrum allocation and deploying a mixture of macrocells and microcells with sets of carriers allocated to each type of cell (normally 2 carriers for micros), the trade-off between the user capacity of a system and the network infrastructure investment is optimised.

As an example of the potential increase in capacity which can be achieved by upgrading a macrocellular network to multi-layer, consider the systems in the panels below.

In each case the area considered is 3.5 km2 which is covered by 4 sites (12 cells). Each 2-carrier cell supports 9.01 Erlangs of traffic. The total number of carriers in the macrocellular system is 24 - which can be used to support a total of 4325 subscribers and a traffic density of 30.89 Erlangs/km2.



Figure 6:Example Macrocellular System

In order to upgrade the macrocellular network to a multi-layer system, 24, 2-carrier microcells are added to the network. In this system 12974 subscribers can be supported and the traffic density increases to 92.67 Erlangs/km2. Over the 3.5km2 of the example system, the multi-layer architecture can support 216.24 Erlangs of traffic in addition to that which can be supported by the original macrocellular system.

3.3.1 System Capacity: City Centre Example

In - building microcells are excluded from the following calculations, taken from a real system covering a city centre.

The mean capacity per square Km given by the macrocells serving in the area of 3.5 km2 is going to be considered as the current capacity of the system. As shown, the total carried traffic of the macro layer is 122.67 Erlangs, giving a total capacity of 35.04 Erl/ km2 . The capacity increase factor is 1.

Macrocell Carriers BDBH Traffic carried Max. Capacity (GOS 2%)

Total 41 122,67 194.38

There are 32 microcells underlaying in this area.

The calculated total carried traffic values for the microcells covering approximately 80 % of the area in question, i.e. 2.8 km2 is as follows:

Total number of microcells 32

Total carried traffic in busy hour (Erl) 176.9

Max. traffic ,GOS 2% , 2 carriers , (Erl) 262.4

The traffic capacity offered by the micro layer is 63.20 Erl/ km2. The combined system (microcell + macrocells) has the following capacity :

35.04 Erl/ km2 (macro) + 63.20 Erl/ km2 (micro) = 98.24 Erl/ km2

This data means that the capacity increase factor achieved in this case is 2.80 with the inclusion of a micro layer.



Figure 7 : Traffic carried in the system in busy hour and the maximum capacity of fully utilised cells in the centre

Figure 8: Traffic Capacity increase (Erl/ km2 ) in the combined system

3.4. Traffic

Apart of the future capacity expansion pursued when deploying microcells, it is intended to take as much traffic as possible, as this means better quality for this traffic and less interference introduced to the system.

Microcells are going to carry traffic from three different sources: The dedicated improved coverage and high density capacity provided to specific small areas, the reduction of the loading on macrocells and the generation of their own traffic by reaching to places, where macrocell cannot. In fact, practical experience shows that, in most part of the cases, as soon as a microcell is put into service the traffic carried makes it necessary to put both carriers on air.



TRAFFIC CARRIED BY MICRO LAYER

NEW TRAFFIC GENERATED

MICROCELLS TAKE TRAFFIC FROM MACROCELLS

BETTER IN-BUILDING COVERAGECOVERAGE IMPROVEMENTS

MACRO LAYER CONGESTED

Figure 9: Microcellular traffic sources

3.4.1 Classification of microcells Microcells could be clasified according to the purpose each one was planned for:

Hot Spot cells: These microcells are deployed in locations with traffic peaks (non-uniform traffic distribution) leaving extra capacity on the macrocell. They are present in any microcellular deployment and generally, they are the first ones to be implemented.

Contiguous coverage: capacity enhancement through efficient utilisation of spectrum while maintaining network quality. These are micros found in continous layer deployments and their purpose is to make continous underlay to meet a certain capacity and quality target.

In-building coverage: improved in-building coverage within the existing coverage area of the macrocell. They are found in any microcellular deloyment, deployed either for taking a peak of traffic inside a building (in building hot spot) or as an indoor plan included in big microcellular deployments.

Improved quality and coverage: providing better coverage and service quality in areas of poor coverage from macrocells. When deploying big microcellular systems, we implement some of them to fill holes in the macrocellular network as they are easy to implement. Although these microcells can be seen in big systems, it is advisable to have a good macrocellular overlay first. Macrocells will be the umbrella and will give coverage to places where microcells can not reach.

3.4.2 Types of traffic on microcells

In-building MS. This is the indoor traffic taken either with in building micros or with micros giving indoor coverage from outside.



Slow moving vehicular or stationary MS. This is the traffic coming from subscribers in pedestrian areas or slow mobiles in dense traffic areas (i.e. city centres)

Fast moving vehicle MS. This is the traffic coming from fast mobiles in roads or fast streets.

3.4.3 Practical Case: Traffic in a large deployment

Figure 10 and Figure 11 outline the distribution of microcells in a real deployment in terms of categories mentioned above. The diagrams clearly illustrate that except for the 26 indoor cells (12%) and the few hot spot cells (6%),the micro layer represents a network with contiguous coverage spread all over the city with non uniform traffic distribution (Figure 12). 5% of cells (included in the number of contiguous coverage cells) are deployed to provide better coverage in black spots.

Figure 10: Classification of microcells according to the main purpose of use



Figure 11: Clasification of microcells in the city by the type of traffic carried

Figure 12: Non cumulative distribution of traffic on microcells with 1 Erl scale size

BDBH - carried traffic during busy day busy hour ( Metrica ) BDBH 3 day AVG - 3 day average of carried traffic at BDBH ( Metrica )



3.5 RF Planning

As it was introduced in the previous paragraphs, there are two possibilities for microcellular frequency planning: reuse frequencies from the macro layer or have a separate band for micros. Between the two options, a mixed schema is a valid solution and will be explained later in this section.

Hot spot micros or sparsely connected micros do no justify in terms of efficiency, to have separate spectrum dedicated for them, so frequencies from the macrocell layer will be reused. On the other hand, to deploy a continuous microcellular layer, it is better to dedicate a separate frequency band for microcells, as it becomes complex to reuse frequencies in dense traffic areas.

Between the two solutions, and always depending on the size of the microcellular layer, we could adopt a mixed solution: Dedicate a small separate band for micros and use it whenever it is not possible to reuse frequencies from the macro layer. Bellow is shown the selection algorithm.

NEW FREQUENCY SELECTION:

Scan Spectrum Available

Any channel below -90 dBm ?

Macro Freq. Reuse

Use Micro Freq.

YES

NO

Figure 13: New Frequency selection procedure

As micros have typically two carriers, it is interesting when having separate band, to plan the BCCH´s with the dedicated frequencies and to reuse frequencies in the TCH´s if necessary. This will permit to have cleaner frequencies in the BCCH´s leading to better handover performance on the microcells.

When reusing frequencies from the macros, unless frequency hopping is used in them, frequencies from BCCH´s or TCH´s can be reused. If frequency hopping was used, the possible interference coming from the macro layer will be fully identified if coming from a BCCH (reuse patterns in hopping carriers are very tight), so it is advisable to reuse from them.

A tool layer called AFS -automatic frequency selector- has been developed (for internal use only) to select frequencies for the micro. With this tool ARFCN-BSIC combinations with their levels are identified and associated to stations, so, at the same time, we identify the strongest interfering signals belonging to prospective neighbours and the weakest ones that will be the suitable frequencies to reuse.



Figure 14: Frequency Planning Techniques

Figure 15 shows a real frequency plan implemented in a complex environment with 39 frequencies available and a large number of microcells:

Macro Layer:

15 frequencies are used as BCCH channels with a 5x3 reuse. Additional 15 channels are used for hopping carriers with a reuse 1x3x5 (hopping over 5 frequencies) in the city centre. Outside this area the macrocells are hopping over 6 frequencies, giving a total of 18 frequencies used for hopping on the macrocells.

Micro Layer

There are 9 channels available for use on the microcells within the city centre: 6 are dedicated frequencies and 3 frequencies are stolen from the macro hopping channels.

This number is reduced to 6 (only the dedicated channels can be used) outside the city centre.

In case of more frequency requirements for microcells, macrocell BCCH frequencies are reused, taking into account the macro interference, based on signal strength.


MACROS FFPOLD FREQUENCY PLAN TECHNIQUE

MACROS SFHNEW FREQUENCY PLAN TECHNIQUE

4x3

1x3

BCCH TCH

t channelsb channels

micros

m channels

BCCH TCH hop

t channelsb channels

micros

m channels


CITY CENTRE

OUTSIDE CITY CENTRE

15 BCCH (5 X3) 15 TCH (1X3) 9 micro

15 BCCH (5 X3) 18 TCH (1X3) 6 micro

Figure 15: Planning example

3.6 PERFORMANCE MONITORINGWhen deploying a large number of microcells, differences in performance among

them will be noticed. Through field experience some of the reasons for having different behaviour have been identified.

Among the reasons for having good performance are:

Installation of microcells to meet the increased traffic capacity exactly where it is needed, in other words, cells are deployed in locations with extremely high peaks in traffic demand (dense urban environment, city centre with pedestrian and shopping areas).

Cells with large coverage areas due to high and well positioned omni site antennas or because of covering very wide open areas e.g. squares and big cross-roads.

Cells in the middle of the extensive contiguous coverage area in a very dense microcell environment. All cells have high number of surrounding micro neighbours and thus with handovers mainly between microcells and call origination on the micro layer.

Good frequency plan using mainly dedicated micro channels without interference as in the case of reusing BCCH frequencies from the macro layer.

There are several reasons for having bad performance:

Cells implemented in areas with lower traffic demand and subscriber density.

Cells with small coverage areas due to low or shadowed antenna locations.

Cells covering roads with fast vehicular mobiles or cells on the edge of the microcell network with contiguous coverage and with few microcell neighbours and mainly with delayed handovers (type 5) from the macro layer and origination on macrocells.

Interference arising from reusing not clean macro BCCH channels.

Cells providing improved coverage and service quality substituting macrocells.

A useful schema for network implementation and continuos performance monitoring when the network becomes complex is shown in the following figure:



Initial DatabaseSettings

SiteImplementation

+ Integration

SystemOptimization

NetworkMonitoring

PerformanceAnalysis

Data Evaluation

New SolutionsFindings

DataAcquisition

OMC StatisticsDrive Tests

Inputs + Outputs

Procedures

CTP, CAT 2, ECT

Field Investigation

Optimisation Criteria

Figure 16: Schema for network implementation and continuos performance monitoring



4. Mobility in Multilayer Networks4.1 Handover Process

4.1.1 Description


UL/DL Measurement CollectionUL/DL Measurement Collection

Averages CalculationAverages Calculation

Threshold Comparison + VotingThreshold Comparison + Voting

HO Procedure triggeredHO Procedure triggered

Candidate OrderingCandidate Ordering


Figure 17: Handover process structure

The handover process starts with the measurement collection for both Uplink and Downlink every SACCH multiframe (480 msec).

When enough measurements have been collected, the averaging of this data is performed. The length of the averaging window (hreqve) will determine the speed of the handover as it defines the reaction time of the system to the signal variation.

Some of these averaged results are compared with thresholds, and voting (p out of n) is carried out for the imperative handovers.

When the voting succeeds or PBGT(n) exceeds its associated ho_margin(n), a handover is triggered with the appropriate cause. After this we have to go trough exclusion (including rxlev_min for that neighbour) and sorting procedures that will be different depending on the handover cause and the features enabled in the database.

Once the candidates list is produced the handover will be performed to the best cell with resources available according to the sorting criteria. Details about the averaging process are in APENDIX B, and exclusion and sorting procedures will be discussed later in this and following sections.

For PBGT based handovers, the length of the averaging window may be defined on a per-neighbour basis allowing handovers to certain neighbours to be configured as fast handovers and others as slow.

4.1.2 Handover Types

There are two different kind of handovers:

Imperative Handovers. These handovers are triggered based on the serving cell status (quality, level, interference - quality + level - or distance). Voting and threshold comparison are carried out for them.

PBGT. These handovers are triggered based on the reported neighbour level. Neighbour associated ho_margin(n) must be exceeded, and sometimes aditional requirements as levels, timers, etc.(in microcellular algorithms) must be acomplished as well.



ul_rxqualul_rxqua l

dl_rxlevdl_rxlevms_distancems_distance

dl_rxqualdl_rxqualul_rxlevul_rxlev

ul_rxqualdl_interferenceul_rxqualul_interference

IMPERATIVE

PBGT

HANDOVERS

{

Figure 18: Handover types

4.1.3 Handover Priority

For all calls in progress, every SACCH multiframe (480 msec) a software process will check each handover condition in the order shown bellow in Figure 19. Imperative handovers have the highest priority; PBGT based handovers will only be triggered when no imperative cause is present.



Figure 19: Handover Cause Priority

The key innovations introduced in the handover structures of the Motorola Layered Product are the flexibility provided to configure the PBGT algorithm as required on a per-neighbour basis and the modification of the candidate ordering dependent on the handover cause.

4.2 Motorola PBGT Algorithm

The Motorola PBGT algorithm has integrated several features to offer an intelligent product able to recognise the needs of the system and direct the traffic according to the resources and conditions of the network.


ul_rxqualul_rxqual

dl_rxqualdl_rxqual

ul_rxlevul_rxlev

dl_rxlevdl_rxlev

ms_distancems_distance

pwr_bgtpwr_bgt


PBGT Algorithm

NeighbourNeighbourConfiguredConfigured

Flexibility Flexibility SimplicitySimplicity

ScenarioScenarioRecognitionRecognition

MicrocellularMicrocellularRequirementsRequirements

EffectivenessEffectiveness

Figure 20: Motorola PBGT Design

To achieve this intelligent functionality, the PBGT algorithm may be configured on a per-neighbour basis, allowing each neighbour to be processed following different criteria. What is actually configured is not the PBGT formula itself, but its surrounding conditions to trigger a handover. Seven different configurations are available. Suitable parameters for them are explained in the Optimisation part The design of the algorithms is detailed in APENDIX A through pseudocode.

4.2.1 Standard Configuration (Type 1).

This is the standard configuration used in the macrocellular system. It is typically used between macro neighbours. The standard PBGT equation is used in this configuration. Whenever the PBGT calculation exceeds the ho_margin a handover will be triggered with better cell cause. In order to invoke this algorithm between two cells, a neighbour type-1 is defined in the database.

pbgt(n) = Min ( MS_TXPWR , P ) - rxlev_dl_sc - PWR_C_D -

Min ( MS_TXPWR_MAX (n) , P ) + rxlev_ncell (n)



4.2.2 Line of Sight Configuration (Type 4)

This configuration is typically used between micro neighbours which are LOS related. The algorithm incorporates a delay timer to limit the handover rate (ping-pong handovers) and to force fast moving mobiles to hand up to the macro layer before quality of service is degraded. This configuration is identified as type-4 in the database definition.

System behaviour is dependent upon mobile speed. If the speed is low enough the microcellular system will take the call, but if the speed increases the call will be handed up to the macrocellular layer. In Figure 21 below, a mobile located in a car handed into the microcellular system (Micro 1) when it was stopped at a traffic light: the system considered it was a slow moving mobile. If the vehicle speed subsequently increases such that the mobile is considered fast moving by the system, the timer of the serving microcell will prevent the handover to Micro 2 and this mobile will be forced to hand up to the macro layer through an imperative handover (rxqual / rxlev).

Figure 21: Fast Moving Mobile - not desired on microcells

4.2.3 Around-the-Corner Configuration (Type 3).

In this configuration, the signal level of the server is monitored and handovers will be prevented to the neighbour microcell unless the server level goes below a threshold. This is extremely useful when the topology of the streets can create problems such as the rapid drop in signal level when turning a corner. This configuration avoid unnecessary handovers, as shown in the scenario explained below. This algorithm is defined in the database as type-3.


Micro 1Micro 1 Micro 2Micro 2


In Figure 22, a mobile is using Micro 1. When it reaches the area A, the signal level of Micro 2 will be higher but if the mobile does not turn the corner it is not necessary to hand-over to Micro 2 as this cell would experience a high drop in rxlev around the corner 4. This scenario could lead to drop calls when the speed of the mobiles is high. Using the type-3 configuration with this neighbour will avoid the potential problems by maintaining the call on micro 1.

Figure 22: Around the Corner Situation

Another feature implemented in this configuration is an alternative ordering in the handover candidate list. When a handover is generated for an around-the-corner type-3 neighbour but the microcell is blocked as the corner is turned, all macro neighbours will be considered as candidates, ordered by PBGT. In the figure above, this will avoid problems in the scenario where the mobile turns the corner 3, as the server signal level is expected to drop abruptly and a handover to the macro layer is triggered.

4.2.4 Qualified Neighbour Configuration (Type 5).

In this case the trend of the neighbour signal level is monitored. To allow a handover to a neighbour defined to use this configuration, its level has to exceed a threshold for a defined period of time. This configuration may be used to hand down from the macro to the micro layer when a microcell neighbour is deemed to have a high signal level continuously for a period of time. The period and threshold may be configured to control the handover rate between layers and to identify the mobiles whose speed is over the desired limit and therefore should remain in the macro layer. Defined as type-5 in the database.

In Figure 23 below, a fast moving mobile is identified by the serving macrocell and is never handed down to the micro layer. It did not report the microcell signal level as exceeding the required threshold for long enough.


Micro 1Micro 1

Micro 2Micro 2

AA1 2

3 4


MacrocellMacrocell

MicrocellMicrocell

Figure 23: Fast moving mobile recognised

This configuration may also be used between micro neighbours when it is desired to hand over the calls to a neighbour microcell as soon as it meets the design requirements. This may be useful in some situations to modify the cell boundaries and control C/I ratio.

4.2.5 Dynamic Handover Margin Configuration (Type 6).

This configuration is designed to penalise the handover margin for a defined period of time. When the PBGT calculation exceeds the ho_margin, the penalty will be applied and when a timer expires a different value will be subtracted from the Ho margin. Effectively it attempts to limit the handover rate and may be used to hand down to the microcellular layer as fast mobiles may be identified via this mechanism as well. It may also be used between microcells to force the fast mobiles to hand up to the macro layer.

In addition, the algorithm has the flexibility to allow the handovers during the penalty time in the scenario where rxlevs of the cells change very fast and the PBGT calculation exceeds the ho_margin requirements. This configuration is defined as type-6 in the database.

Figure 24: Dynamic Handover Margin Functionality


PBGT > ho_margin(Timer starts)

ho_margin = a

ho_margin = a + penalty(Timer expires)

ho_margin = a + penalty - gain

ServerServer

ServerServer

NeighbNeighb

NeighbNeighb


4.2.6 Adjacent channel neighbours (Type 7).

In large microcellular deployments where frequency spectrum for micros is limited, there are situations where it is impossible to avoid deploying adjacent microcells with adjacent BCCH frequencies. As a mobile being served by one of these cells approaches the interfering neighbour cell, the quality of the call degrades perhaps to the point of dropping altogether. Assuming that both cells have only a single carrier, neither an intra-cell handover nor a handover to the interfering neighbour improve the situation.

This algorithm allows a third Cell, which is not on an adjacent channel, to be the preferred target for handover even though an interfering neighbor may have the strongest signal. A new parameter is included to detect the risk coming from neighbours in adjacent frequencies, when defined as type 7, this is pbgt_adj_chan_ho_margin and it is tipically set to negative values.

When Power budget – pbgt_adj_chan_ho_margin >=0

a handover will be generated before the neighbour signal strength (and thus interference) becomes too strong to drop the call. The handover is performed to a cell different from this neighbour. This is managed because we delete the neighbour that activated this condition from the candidate list as it will be explained in the candidate list generation section.

4.2.6.1 Interference avoidance test

Another problematic situation could appear when calls are handed over to a cell which has a neighbour with adjacent (BCCH) frequency. It is possible to enable the BSS to perform an interference avoidance test on the neighbor candidate before handing it over a call. This test can be done regardless of which of the seven types is used for this neighbour.

If adj_chan_intf_test enabled in NEIG1and any other valid neighbour NEIG2 (of the current cell) has an adjacent channel frequency with the candidate neighbour (NEIG1) then perform following check:

NEIG2rxlev – NEIG1rxlev < adj_chan_rxlev_diff

If check fails then delete neighbor N1 from candidate list.

4.3 Imperative Handovers & Type 2 Neighbours

Motorola’s implementation of Imperative Handovers allows the microcellular layer to retain a call provided that no quality and / or level degradation is experienced.

The possible causes for triggering an imperative handover are

- ul / dl quality

- ul / dl interference

- ul / dl level

- ms_distance



After the imperative handover is triggered GSM criteria 1 and 2 have to be evaluated (rxlev_min_cell and PBGT criterias) for all the candidates. After this, a sorting procedure will be applied to the successful candidates as explained below. Modifications to exclusion and sorting procedures because of enabling other features will be addressed as the features are described.

Figure 25: Imperative Handover Candidate Ordering

If a neighbour is defined as a type-2 in the database, that means that a handover to that cell will only be performed through imperative causes. Normally used to defined macro neighbours in microcells.

4.4 Candidate Ordering

Depending on the handover cause and the PBGT configuration involved, different ordering procedures will be followed. The database types associated to each PBGT configuration are:

Type-1 - Standard Configuration

Type-2 - Macro Neighbour of a Micro cell. Handover via imperative cause

Type-3 - Around the Corner Configuration

Type-4 - Line of Sight Configuration

Type-5 - Qualified Neighbour Configuration

Type-6 - Dynamic Handover Margin Configuration

Type-7 - Adjacent channel neighbours

The sorting procedure applied, just considering the seven types available is shown in the graph bellow. The alterations produced as a result of particular features being enabled have not been considered (i.e. Micro – Micro quality ho). For seeing the effects of enabling each one of the features, refer to the particular feature section.


Type 1 & 2 Neighbours

Type 3, 4, 5, 6 Neighbours

PBGT ordering


IN

OUT

Handover triggered by type 3 neighbors?

Handover triggered by type 4, 5 or 6 neighbors?

Handover triggered by imperative handovers or

adjacent channel interference?

Neighbor candidate list:- Remove any algorithm 7 neighbors which fail test: Power budget -pbgt_adj_chan_ho_margin >=0- All algorithm 1 and 2 neighbors- Any other neighbors.

Neighbor candidate list:- Remove algorithm 2 neighbors from the list- Any algorithm 4,5 and 6 neighbors- Any algorithm 1 neighbors.

Neighbor candidate list:- All algorithm 3 neighbors - All algorithm 1 and 2 neighbors- Any algorithm 4,5 and 6 neighbors

yes

yes

yes

no

no

no

Remove any neighbor which does not satisfy additional requirementsof its algorithm, except for type 1 and 2

Remove any neighbor that fails the Interf. Avoidance Test

Figure 26 .- Handover Candidate Ordering



4.5 Missing Reports & Missing Neighbours

The BSS deals with missing neighbours depending on the setting of the parameter ncell_proc (add_cell):

If ncell_proc = 0,

This is the usual setting for the parameter. If a neighbour is not reported in a particular sacch period then it is simply not considered as a handover candidate. So if a handover was triggered in that period only the six neighbours (up to six) the mobile has just reported are considered.

What happens if a neighbour is reported in that sacch period but not in the previous one?, how will the averaging be affected?, what figures will be used to calculate the hreqt? The previous good report (could be some time back) is simply repeated, this will provide a hreqt average. The repeating could go on for 8 SACCH periods.

If ncell proc=1,

In this case, a neighbour does not have to be reported in the last sacch period to be considered a valid neighbour for handover. If reports have been missed, the previous good one is not repeated, like mentioned above, in fact a figure of 0 (-110) is used in the averaging mechanism for that period.

It is neccessary to be very careful using this configuration.

In case of a mobile missing reports, attention should be paid to the parameter missing_rpt in the add_cell:

If missing_rpt=0

The last measurement value is repeated and the averaging, voting and handover decisions will still be done. One limiting factor in time to go on repeating measurements is link_fail, when this counter expires then the link will be broken down under control of T3109.

If missing_rpt=1

No averaging or handover will happen and this measurement report will be forgotten. No dl handover or power control decisions will be made. The uplink ones will continue as normal.

4.6 Motorola Multilayered System Philosophy

The principle of a Layered Philosophy is to direct the traffic to the correct layer depending on the different conditions and resources available. The handovers must be intelligent enough to control the traffic properly and follow the main principle in a standard Layered System :



maintain mobiles on the lower layer (higher capacity)

provided that no quality degradation occurs

As the handover process lasts a certain period of time, the smaller the ratio between the size of the cell and the speed of the mobile, the more the environmental conditions will change and potential problems will arise when the handover is performed. In a Microcellular System this principle implies the capability to decide which mobiles are too fast to be served by the microcellular layer and should, therefore, be kept in the macro level.

Two main strategies are deduced from this principle, these are shown in the figure bellow:

Hand-down the call to the micro layer as soon as good performance is guaranteed in this layer for the particular mobile. Depending on the size of the microcells, the maximum mobile speed at which the system can function will be defined. Mobiles over this threshold will not be allowed to hand down to the microcellular layer.

Retain the particular mobile on the microcellular layer until the quality cannot be maintained, then hand up as soon as possible to the macro layer.

Rxlev > Threshold

BadQuality

GoodQuality

OutgoingOutgoingBoundaryBoundary

MicrocellMicrocell

IncomingIncomingBoundaryBoundary

Figure 27: Incoming and outgoing microcell boundaries

To achieve the objectives for managing traffic in the Layered System, Motorola has developed very powerful software algorithms which are able to deal with all the possible situations. Like standard GSM macrocellular systems, handover are based on better cell and imperative conditions. The standard GSM better cell criteria, is based on PBGT calculation, using the relative signal levels from the serving and neighbour cells. In a Layered System, the concept of better cell takes on the new dimension of layer preference for traffic. To support this objective, Motorola has modified the standard PBGT algorithm, allowing this to be



reconfigured to take into account the needs of the system. What has been achieved through this reconfiguration is a simple but extremely powerful tool able to provide the systems engineers with all the flexibility they demand.

5. OPTIMISATION5.1 HANDOVER STRUCTURE

In Figure 28 the general structure of handovers used for intra and inter layer situations are displayed.

Standard PBGTStandard PBGTOROR

Imperative HOImperative HO

Customised PBGTCustomised PBGTOROR

Imperative HOImperative HO

ImperativeImperativeHOHO

Qualified Neig.Qualified Neig.PBGT ConfigPBGT Config

HandoverHandoverStructureStructure

MACROCELL MACROCELL

microcell microcell

Figure 28: General HO Structure

This schema does not include all the possible options offered by the flexibility of the system. For example, it is known that in some special situations it is beneficial to hand-up the call through customised PBGT handovers.

5.1.1 INTER-LAYER HANDOVERS

These are the handovers controlling the flow of mobiles between layers. Its implementation follows the philosophy explained before.

It is important to note that the Motorola approach has proven ability to interact with other vendor’s equipment on a per BSC basis. This interaction has been tested in different projects with all significant GSM vendors in the market. All the functionality offered by Motorola can be implemented in the Microcellular Network using another vendor for the macrocellular equipment.


TELCEL, 03/01/-1,


5.1.1.1 HANDING DOWN

In a microcellular scenario where the environmental conditions are well known, to ensure that a microcell is going to provide good performance to a particular mobile, its level will be measured and when it exceeds a certain value (rxlev_Ncell) for a given period (delay time), and PBGT conditions are met, this mobile is allowed to go down. This period must be long enough to ensure that this mobile is not a fast mobile. This is managed by one of the Motorola handover algorithms: type 5 (Qualified neighbour). The values for the neighbour threshold to go down, the timer the micro has to be over the threshold and the handover margin (usually set to the lowest negative value allowed, to make the PBGT condition irrelevant) have to be set. The number of reports that are going to be averaged (hreqave value) has to be defined as in all handovers.

Typical values for these parameters are:

rxlev_Ncell = 30 - 40

delay time = 6 - 10

ho_margin = -63

hrqave = 3 - 6

5.1.1.2 HANDING UP

The requirement to keep the call as long as possible in the microcellular layer effectively disables the use of better cell considerations to trigger the handover to the macro layer. In these handovers, PBGT is still calculated for candidate ordering purposes. Hand-up handovers will be performed through imperative conditions such as Rxqual and/or Rxlev.

If a neighbour is defined as a type-2 in the database, that means that a handover to that cell will only be performed through imperative causes. Macrocells are usually defined as type-2 neighbours in microcells.

If there is not risk for the call, enabling just quality handovers should be enough. In this way, we can guarantee that the call is going to remain in the micro layer till it experiences bad quality. At the same time, in building coverage will be improved as the size of the cell will not be limited by level handovers.

The parameters for quality handovers are:

- Quality threshold. It is the quality value on a per cell basis over which the handover will be triggered.

- Hrqave. Number of measurements to average.

- Hreqt, n and p. Hreqt is the buffer size of the averaged measurements. p is the number of averaged measurements out of n that should exceed the threshold. These parameters should be set to fit the worst situation. This is where the quickest quality handover is needed to avoid dropped calls in one way out of the cell.

The same parameters and behaviour are observed for level handovers. A level



threshold will be considered. When being below it, the handover will be triggered. It is usual to enable it just in the downlink.

When a handover is triggered because of imperative reasons, the highest priority is given to neighbours type 1 and 2.

Typical values of this parameters for quality are:

l_rxqual_dl_h= 150- 225

l_rxqual_ul_h= 150 - 225 or just higher than l_rxqual_dl_h

n for quality = 4 - 5

p for quality = 3 - 4 (3 is quicker than 4 for the same n)

hreqave= 1 (no averaging) for easier understanding of the behaviour while optimising

Typical value of this parameters for level are:

l_rxlev_dl_h: 15-20

n for level = 3 - 4

p for level = 2 - 3 (2 is quicker than 3 for the same n)

hreqave= 1 (no averaging) for easier understanding of the behaviour while optimising

Although this is the standard procedure to hand-up the call, it is known that in some special situations it is beneficial to hand-up the call through customised PBGT handovers.

This arrangement is useful to hand up the call in the border of the microcellular system. When bad quality arrives suddenly, while leaving microcell area in a certain direction, it could not be worth to set the quality handovers to fit this extreme situation (as they would be valid for the whole cell). It could be worth handing over to that macro neighbour before this really quick bad quality starts.

In Figure 29, a mobile connected in dedicated mode to microcell 6 and heading south would start having poor quality in the area marked. To overcome this, the macrocell B, sector 2, could be defined as a type 3 neighbour using for the threshold, the level of micro 6 in the defined limit marked in the figure. With this design, a “clean” PBGT based handover would be performed between the defined limit and the bad quality area.



6

B

Bad QualityBad QualityAreaArea

Defined LimitDefined LimitRxlevRxlev66=35=35

Figure 29: Special use of Around the Corner Configuration

5.1.1.3 MAINTAINING THE CALL IN THE MICRO LAYER

While possible, the call will be maintained in the micro-layer in order to release the congestion in the macro neighbours. To handle the calls among micros, a handover set was developed by Motorola to cope with all possible scenarios. Among the six PBGT algorithms available, three can be seen in almost all microcellular systems, these are algorithms 3, 4 and 5 . Algorithm 1 is a normal power budget for macros and algorithm 6 and 7 are microcellular algorithms for specific situations rarely used. As alg. 5 is the appropiate one to go down and the hand up is done through imperative handovers (defining macros as type 2 neighbours), the new relevant algorithm parameters to explain are those related to alg. 3 and 4.

Alg. 3 and 4, as all PBGT algorithms, have hrqt = n = p = 1 (no voting is implemented). The remaining parameters and reference values to be set in both are:

Type 4:

hreqave= 3-6

handover margin= 4-6

timer = 0 indicate the time that the neighbour should be reported before performing the handover to it. This is used to avoid handovers to sporadic neighbours or fast mobiles going to the micro.

Type 3:

hreqave= 3-6

handover margin= 4-6

server level depends on the situation. The level should be under this value to perform the handover (appart of meeting the handover margin).



Although alg. 5 is the typical algorithm to go down, it is used as well to maintain the call in the micro layer, as can be seen in the example explained in the following paragraph.

If microcells 4 and 5 of are using the same frequencies due to tight frequency re-use, the definition of microcell 7 as a qualified neighbour configured with a certain negative handover margin could make possible such a tight re-use. There are some areas where the C/I ratio between microcells 4 and 5 are unacceptable, with one of these microcells as the server. Using this PBGT configuration and defining rxlev_ncell and ho_margin properly would allow microcell 7 to provide service in these areas, even if this was not the best server.

4

7

5BadC/I

Ratio

Figure 30: Qualified Neighbour Configuration for Maintaining the Call in Micro Layer

5.2 IDLE MODE BEHAVIOUR

The possibility of broadcasting different BA lists in idle/dedicated mode (BA BCCH and BA SACCH) permits to control the mobile behaviour on idle mode.

Two different strategies can be chosen :

- Maximising capacity with freely allowed originations on the best server (micro or macro cell), resulting in increased number of originations and traffic on microcells

- Best performance for fast mobiles with originations only on the macro layer and large amount of idle mode traffic on macrocells

Figure 31: Different list: BCCH & SACCH

The problem that can occur, if the microcells are put on both lists of the macrocells in an environment with fast mobiles is that the slow reselection process and interference on


Macrocell

Microcell 1 Microcell 2

Cell with prevailing slow MS Cell with prevailing fast MS

Monitored only in dedicated mode( SACCH list )

Monitored in idle and dedicatedmode ( BCCH and SACCH list )


downlink can cause loss of service on the CCCH - lost pages.

Field experience shows that except for streets with the fastest traffic and cells with small coverage areas, the microcells can be defined on BOTH lists without service degradation.

5.3 Site integration

Once the RF Planning is done (frequency + neighbours definition), the site can be integrated and the handovers designed for each neighbour can be optimised. The steps to follow are:

1. The starting point is to put on air the microcell barred, with incoming handovers to it disabled. This is managed trough two database parameters, which are:

en_incoming_ho = 1

cell_bar_access_switch = 1

The objective of this step is to check if we can leave the cell in all possible directions without risking the call.

2. Incoming handovers are enabled and it is checked if the calls enter to the micro from all possible directions as soon as good quality is guaranteed (going down from macros) or it is necessary (handing over from micros).

3. The microcell is unbarred and originations in the cell are tried.

The handover parameters to check during this process are:

Macros:

- Speed of handovers from micro to macro: It can be modified trough several parameters defined in the micro (“add_cell” definition). Assuming that macros are defined as type 2 neighbours of the microcell and only quality and level handovers are enabled, the different alternatives are described next.

Action Effect

Quality Threshold (quality handovers)

Increase Reduce speed, qual. degradation, more traffic

Quality Threshold (quality handovers)

Decrease Increase speed, less traffic, qual improvement in micro

Level Threshold (level handovers)

Increase Increase speed, less traffic, less indoor coverage

Level Threshold (level handovers)

Decrease Reduce speed, more traffic, more indoor coverage



n (level or quality) Increase Increase speed (for the same p)

n (level or quality) Decrease Decrease speed (for the same p)

p (level or quality) Increase Decrease speed (for the same n)

p (level or quality) Decrease Increase speed (for the same n)

Hreqave (level or quality) Increase Decrease speed (for the same n,p)

Hreqave (level or quality) Decrease Increase speed (for the same n,p)

- Speed of handovers from macro to micro: It can be modified trough several parameters defined in the macro “add_neighbour” definition of the microcell. Assuming that micros are defined as type 5 neighbours of the macrocells, the parameters involved in this algorithm and their effects are:

Parameter Action Effect

Neighbour level (micro level)

Increase Decrease speed, loose traffic, assure quality in micro?

Neighbour level (micro level)

Decrease Increase speed, win traffic, degrade quality in micro?

Timer Increase Decrease speed

Timer Decrease Increase speed

Hreqave Increase Decrease speed

Hreqave Decrease Increase speed

Micros:

- For each micro neighbour, each parameter related to the handover type should be checked. Usually, it is not necessary to change the default parameters. Only in type 3 alg. The server level must be chosen with field measurements. Anyway, handover speed can be changed once we have designed the topology.

Parameter Action Effect

Neighbour ho_margin

Increase Decrease ho_speed to the neighbour

Neighbour ho_margin

Decrease Increase ho_speed to the neighbour



Hreqave Increase Decrease ho_speed to the neighbour

Hreqave Decrease Increase ho_speed to the neighbour

After doing all necessary changes, the site will be put into service and monitored trough stats.

6. Additional Multi-layer FeaturesMotorola has implemented a set of special features to improve the performance of

multi-layered environments.

Two of these features have been designed to distribute the traffic load of the system avoiding blocking situations due to congestion. These are Directed Retry and Congestion Relief. These features can be designed to share the traffic load of the system optimally, using all the resources available. They can be enabled independently or together. This flexibility allows the operator to configure the system according to its needs.

The rest of the features are designed to improve the system performance, specially in microcellular environments, although also applicable in standard macrocellular scenarios.

6.1 Directed Retry & Congestion Relief

6.1.1 Directed Retry

This feature provides the facility to perform a handover from the SDCCH of a congested cell (no TCH’s available) to a TCH of a neighbour cell.

SDCCHSDCCHconnectionconnection

DR HODR HO

DR HODR HO

CongestedMicrocell

DR HO'sDR HO's(SDCCH-TCH)(SDCCH-TCH)

Macrocell

Figure 32: Directed Retry HO when blocking is detected

Two different scenarios are possible:

A mobile assigned to an SDCCH requires a TCH at a time when all TCHs in the



same cell are busy.

Handover needed during the assigment procedure (before being assigned to a TCH)

In both cases this feature could be set up to work internal to the BSS (dr_preference=1) or internal/external to it (dr_preference=2). When the feature works external to the BSS, A-interface signalling is impacted and MSC implementation should be considered and checked.

If dr_standard_congest is enabled, the standard Directed Retry congestion procedure can be applied. When the BSS receives an Assigment Request without TCHs available in the cell, the neighbour list reported by the mobile is used to select the cell in which to search for a TCH. The call is queued (internal or normal) while attempting the procedure. If a TCH in the source cell becomes available, the normal queuing procedure is followed and Diredted Retry aborted.

The handover will be iniciated only if strong neigbours have been reported fulfiling their congest_ho_margin and rxlev_min . These calculations are based on the single last measurement report.

The mobile can report any new neighbour before handover_recognized_period elapses, at this time, the mobile will report all current candidates.

The other possible scenario is when dr_ho_during_assign is enabled. In this case, handovers during the assignment procedure are allowed (this can only happen if the assignment request is queued waiting for a TCH). The alternative actions are:

Intra-Cell Handover. sdcch_ho must be enabled to permit this action.

Internal Inter-Cell Handover

External Inter-Cell Handover. In this case dr_preference must be set to allow Directed retry across A-interface, and dr_msc_preference determines message sequences and contents across it.

The parameters involved in this feature are:

PER BSS

dr_preference: Directed Retry internal to the BSS (dr_preference=1) or both ( internal and external, dr_preference=2). Direct Retry can be also disabled with this parameter (dr_preference=0).

dr_chan_mode_modify: It determines if the channel mode modify procedure follows a succesful handover of a Phase 1 MS in which the channel mode changed to full rate speech.

handover_required_curr_ch: It determines if the current channel is included in the Handover Required message to the MSC.



PER CELL

dr_standard_congest: It determines if the standard Directed Retry congestion procedure is enabled in the cell.

dr_ho_during_assign: It determines if the handover shall be handled during an assignament procedure. In this case the operator should set the MSC timer waiting for the Assignament Complete message from the BSS to 30 sec.

- dr_msc_preference: determines the message sequence and contents across the A-interface during Directed Retry procedures requiring an external handover, this parameter must be consistent with a dr_preference=2.

0: BSS only sends the Handover Required message with cause Direct Retry to the MSC.

1: BSS only sends the Handover Required message with the handover cause to the MSC.

2: BSS sends an Assignment Failure message with cause, Direct Retry, before sending a Handover Required with cause, Directed Retry, to the MSC.

3: BSS sends an Assignment Failure message with cause, Direct Retry, before sending a Handover Required with handover cause to the MSC.

4: BSS sends an Assignment Failure message with cause, Direct Retry, after sending a Handover Required with cause, Directed Retry, to the MSC.

5: BSS sends an Assignment Failure message with cause, Direct Retry, after sending a Handover Required with handover cause to the MSC.

PER NEIGHBOUR

dr_allowed: Allows Directed Retry Handovers to this external cell.

congest_ho_margin: This is the congestion handover margin and its value should be less than the ho_margin_cell of the neighbor cell, to make the handover easier.

6.1.2 Congestion Relief

This feature is an alternative to Directed Retry for congested cells and both can work together or independently. This feature differs in that it chooses the best candidate from all existing calls in the cell to be moved to the alternate cell thus freeing TCHs in the congested cell. This can result in better overall system quality compared to Directed retry because the best handover candidate is chosen instead of the candidate requesting a TCH, so the power budget calculation is based on the longer history of measurement reports instead of a single one. This feature has no impact on existing A-interface signalling.



Figure 33: Handover on congestion

The maximum number of calls handed over can be any of the following alternatives:

The number of queued requests in the congested cell.

The number of calls meeting the congestion handover criteria in the congested cell.

If the BSS receives an Assignment Request and there are no available TCHs in that cell, the BSS searches for candidate calls on a TCH to handover to another cell. The call is queued while attempting to handover existing calls on a TCH. If a resource becomes available in the meantime to fulfil the TCH request, the queuing procedure is followed.

CR could also be activated based on percentage of busy TCH channels.

Depending on the ho_exist_congest database setting, the number of handovers initiated either matches the number of requests queued if the number of handover candidates allows it, or matches the number of handover candidates found. Existing calls designated as candidates for handovers due to congestion are valid during valid_candidate_period. The BSS updates the candidate list as calls either terminate or leave the cell.

The congestion handover margin used is the same as used by Directed retry, using the new per neighbour parameter, congest_ho_margin. This parameter should be less than the value of ho_margin_cell of the neighbour, to make it easier to handover to this neighbour in the case of congestion in the current Cell. Additional timers, levels, etc. involved in microcellular algorithms are not observed in a congestion situation for handing calls to a certain neighbour.

6.1.3 Application & ParametersThese two features can be useful in different scenarios including:

Macrocells experiencing blocking, to hand their traffic to other macro



neighbours with spare capacity. In this way Capacity can increase because cells can have higher the 2% blocking probabilities.

Microcells experiencing blocking in a multilayer network, to hand their traffic up to their umbrella neighbours or even to their micro neighbours, although it is going to be easier to find macro neighbours fitting the congestion criterias as they work as umbrella. In this way we take maximun profit of our microcellular investment as we make micros carry as much traffic as possible.

In concentric cells, to make inner cells carry maximum traffic and make this solution more effective.

Although both features can work together or independently, with only CR enabled we get almost the same performance than with both features enabled at the same time as it can be seen in the figure bellow. This is due to the fact CR can choose among more calls to hand over, while DR only one. Appart from this, in CR well stablish calls are relief to a neighbor cell (and based the decision on a longer history) without impacting in the signalling.

APPLICATION EXAMPLE

Parameters

Multilayer network, with continous microcellular layer. The current configurations of this feature on microcells is as follows :

Congestion Relief type : 2 (Attempt to handover as many calls as meet the congestion


15

14

13

12

11

10

BothCongestion ReliefDirected Retry

0 0.4 0.8 1.2 1.6 2 2.4

Traf

fic s

erve

d pe

r cel

l (15

TC

Hs)

for ~

2% b

lock

ing

Average # of Handover targets per mobile

Capacity of a system with Directed Retry and Congestion Relief

9


handover criteria)

CR handover margin : -10 for macrocell neighbors (the lower the easier)

0 for microcell neighbors (we do not want to risk the call to micros unless they have the same level)

At 100% TCH busy condition on specified cell (no matter how many carriers are equipped), the CR will be activated. This could be changed by activating CR based on percentage of busy TCH channels.

Effects in traffic when enabling the feature

With the previous settings of CR handover margins, 99% of calls are handed up to the macro layer. The effects in traffic and blocking in one single micro are shown bellow.

0

2

4

6

8

10

12

9:00

9:30

10:0

0

10:3

0

11:0

0

11:3

0

12:0

0

12:3

0

13:0

0

13:3

0

14:0

0

14:3

0

15:0

0

15:3

0

16:0

0

16:3

0

17:0

0

17:3

0

18:0

0

18:3

0

19:0

0

19:3

0

20:0

0

Traf

fic (E

lang

s)

8-IV-979-IV-97

Figure 34: Effects in traffic (Erlangs). CR was enabled on April 9th at 9:30 a.m.



0

5

10

15

20

25

30

9:00

9:30

10:0

0

10:3

0

11:0

0

11:3

0

12:0

0

12:3

0

13:0

0

13:3

0

14:0

0

14:3

0

15:0

0

15:3

0

16:0

0

16:3

0

17:0

0

17:3

0

18:0

0

18:3

0

19:0

0

19:3

0

20:0

0

Blo

ckin

g (%

)

8-IV-979-IV-97

Figure 35: Effects in Blocking. CR was enabled on April 9th at 9:30 a.m.

Effect of changing congest_ho_margin to micros

In order to evaluate the effect of HO margin change and to try to increase the probability of handing over the calls to the microcell neighbours, the HO margin for macrocell neighbours is changed to -5 on 3 congested microcells. All 3 microcells are in the contiguous coverage area and have 4-5 microcell neighbours.

The number of handovers to the macro layer is still around 99%, which can be explained by the fact, that if a CR handover is needed, there is always a suitable macrocell with enough signal level for the handover to happen, even if the MS stays close to the microcell. 70% - 80% of all calls are handed over to the most dominant macrocell neighbor.

On the other hand, the probability of a microcell neighbor meeting the criteria and having a suitable level is quite low, since this can only happen on the border of the coverage area between the microcells.

Further decrease of the CR HO margin for macrocell neighbors would make the feature ineffective and cause blocking on the microcell. Decreasing the CR HO margin for microcell neighbors could adversely affect the performance.

Effect of changing CR type

The effect of the type of CR used on microcells is also investigated using 2 different settings :

- type 1 - number of handovers initiated is the number of queued requests

- type 2 - number of handovers initiated is the number of calls meeeting the CR HO criteria

The test is carried out on one micro, which carries 11 Erl of traffic with 2 carriers in



service and activated CR.

The results are as follows :

Congestion Relief Type Number of CR HO attempts TCH Congestion in ms

1 848 6801945

2 1193 3187155

Number of CR HO attempts and CR for the period of 6.00am - 22.00pm

TCH Congestion - indicates the amount of time in ms when all TCH of the cell were busy

The results indicate that with CR type set to 1, there are fewer handover attempts (mostly up to the macro layer)and the time when the cell is fully utilized increased by 200%.

6.2 Fast Initial MS Power Down

6.2.1 Description

Fast initial power down is a standard feature configurable on a per cell basis, which allows the initial power down of the Mobile Station to be set so that the MS power is reduced quicker than the standard ramp down time. This helps alleviate problems with intermodulation and receiver blocking which can occur if the power level of the Mobile Station (MS) is too high, particularly in parts of the network where fibre optic distribution of the RF is deployed, given the smaller dynamic range provided.

Its activation is extremely important in order to reduce the interference level, specially in systems where uplink interference is critical due to the network topology characteristics. Apart of that, it should be mentioned the longer battery life provided enabling this feature in the whole network.

When uplink_rxlev meets or exceeds the rpd_trigger, the MS will be commandde to a power level which has been calculated to put the uplink rxlev equal to the rpd_trigger – rpd_offset, we must remember that every increase in power level is an additional decrease of 2 dBm in output power. The procedure to detect the need for a rapid power down will not begin until enough measurements have been received to satisfy rpd_period monitor period.

Power level (ordered) = Power level (current) + (UL_RXLEV – rpd_trigger + rpd_offset)/2

Per Cell database elements are:

- rapid_pwr_down Enables the feature.

- rpd_trigger: specifies (in rxlev value) the threshold used to trigger the procedure. This parameter must always be greater than the settings of the rpd_offset and l_rxlev_ul_p and the default value is 45 (65 dBm).

- rpd_offset: Defines (in dB) the offset below the trigger threshold used by the



procedure to calculate the new power level. The setting of this parameter must always be less than the rpd trigger and the default value is 8.

- rpd_period: specifies the number of power level measurements which will be averaged before applying the rapid power down procedure. The default setting is 2.

6.2.2 Application & ParametersIt is recommended to enable this feature in all kind of networks, as it is very important

to have the power of both the mobile and the base station in the minimum required level for having good quality in the system.

Usually, uplink interference problems are found. These are difficult to control as uplink path is more difficult to monitor and the uplink interference comes from handsets that are moving throughout the network. This is why this feature is specially important as permits to reduce the uplink interference.

The recommended parameters for this feature are:

- rapid_pwr_down: Always enabled.

- rpd_trigger: It can be set equal to the top of the rxlev power window (u_rxlev_ul_p) or a little bit higher in order to be more conservative.

- rpd_offset: It can be set to take the mobile to the middle of the rxlev power (rpd_trigger - (u_rxlev_ul_p - l_rxlev_ul_p)/2) window (or a little bit lower in order to be more conservative).

- rpd_period: The default value is OK.

6.3 Different neighbour lists in BCCH (idle) and SACCH (dedicated)

6.3.1 Description

Idle mode performance may be significantly affected by the reduced size of the microcells. The re-selection process of the mobiles is usually very slow, so a mobile may be still camped on a certain cell when it is outside of its effective coverage area. If the mobile tries to originate a call before the re-selection is made obvious problems will arise. This is specially noticeable for fast moving mobiles as shown in Figure 36.



Figure 36: Fast Moving Mobile still camped in M1 and located outside its coverage area

To solve this problem, Motorola has implemented a feature to differentiate the neighbour list in idle mode to the one in dedicated mode. A cell may report to the mobiles different neighbour topologies dependent upon whether they are camped on the cell in idle mode (System Type-2 messages) or they are in dedicated mode (System Type-5 messages). In cells where fast moving mobiles may experience degraded quality of service, microcells may be defined as neighbours in dedicated mode but not in idle mode.

In Figure 37, a mobile observes a different neighbour topology depending on whether it is in idle or dedicated mode.

DedicatedMode

IdleMode

Micro Neighbours DefinedMicro Neighbours Defined

No Micro NeighboursNo Micro NeighboursDefinedDefined

MacrocellMacrocellMacrocellMacrocell

Figure 37: Different Neighbour Lists in Idle and Dedicated Mode


Micro 1Micro 1 Micro 2Micro 2

Micro 1Area

Micro 2Area IDLE

MODE

Macrocell


6.3.2 Application As said before, this feature is specifically thought for microcells having fast mobiles in

their serving areas. If this is the case, microcell neighbours will be defined just in one list (SACCH list) of the macrocells avoiding mobiles camping in micros in idle mode.

It is difficult to see if it is going to be a problem to have microcells in both lists when having fast mobiles in one area. Field experience has demonstrated that the additional losses experienced when having microcells in both list are not too much in the worst case, but the traffic generated allowing origination in micros is significant. It is recommended then, to put micros in both lists and monitor them for a short period. Only if the losses were important should be excluded from the BCCH list of their macro neighbours, if not, the traffic carried in the micro layer increase significantly.

6.4 Speed Handover Defined per-neighbour (hreqave).

6.4.1 Description

All the parameters associated with the handover procedures can be defined on a per-neighbour basis, such as PBGT configuration to be used, handover margins and hreqave averaging window used for PBGT calculation. Combining these parameters, the speed of the handover trigger may be tailored as needed.

6.4.2 Application

In Figure 38, the speed of the handover for each neighbour is controlled through the period of the averaging window . If different neighbours of the same cell have different needs in terms of handover speed, this window may be configured with different values for each case. For using per neighbour hreqave, the database parameter use_neighbour_hreqave must be set to 1.

Figure 38: Per-neighbour Averaging dependant on system demand

Another possible application for the per neighbour parameters is to leave a microcell because of imperative reasons. Defining different ho_margin to different neighbours, the ordering criteria of the macro neighbours can be altered for not going just to the best server,


TELCEL, 03/01/-1,


but going to the macro with good level and low occupancy. In this way, it can be avoided going to macro neighbours that are congested and macros having spare capacity are loaded.

6.5 Prefer Different Carrier for Intracell Handover

6.5.1 Description

The criteria to select the target channel for an intracell handover has been modified. When either an uplink or downlink interference handover are triggered, the new channel will be selected based in the following criteria:

Generate list A with anychannels in the bestinterference band

Generate list B: from list A selectany channels in a different carrier &in a different hopping system (ifapplicable)

Select best channel inlist A

N

Hopping cell?Select best channel in BCCH ifnot posssible, select best channelin list B

N

Select best channel in nonBCCH if not posssible, selectbest channel in list B

List B created?

Figure 39: Channel Selection Criteria for Intracell Handovers

6.5.2 ApplicationAs soon as a handover for quality is needed, the server signal strength is checked. If it

is over a certain level, an interference handover is triggered. If the intracell handover is enabled, the handover is performed within the same cell. The change of carrier is prioritised in this kind of handover. The change of carrier is useful in either a fixed plan or a hopping one. This could avoid a handover to a worse cell, and there is not risk at all for the call.

In the graph bellow, it can be seen an example. Although there is bad quality in a certain area for freq. 60 (while served by microcell with freq. 54,60), because of the canyon propagation effect for frequencies (58,60), that freq. has been reused in the microcell TCH. At



that particular spot, if interference is experienced while using freq 60, an intracell handover to another carrier will avoid the situation. In this way, a tighter reuse pattern in these microcells can be implemented.

B

Bad QualityArea

Bad QualityArea for freq 60

freq 54, 60

freq 58, 60

freq 56, 62 freq 52, 64

Figure 40: Change of Carrier Application Example

In a hopping environment, as there is not a constant interferer but a probability of interference, if the server is clearly the dominant cell, it is worth trying to change the carrier (as this usually means changing the MAIO and the timeslot) before performing a quality handover to a much worse cell.



6.6 Limited Number of Intracell Handovers

6.6.1 Description

This feature limits the number of intracell interference handovers due to interference that can occur in a specified amount of time.

If hop_cnt number of handovers occur within hop_cnt_tmr, the handover will be escalated to be a RXQUAL handover to another cell.

A value of 0 for hop_cnt_tmr disables the functionality that will result in no limit to the number of intracell handovers.

The RXQUAL handover that results from this escalation will be subjected to the re-ordering described for “Micro – Micro Quality Handover” and “Timed Offset upon Rxqual Handover”.

The two new database elements required for the control of this functionality are:

hop_cnt 0: Results in effectively disabling intracell interference handovers

1 to 255 : Number of interference handovers allowed within hop_cnt_tmr period

hop_cnt_tmr 0: Effectively disables functionality (no limit to intracell handovers)

1 to 255: Number of SACCH periods before hop_cnt value is reset

6.6.2 Application & ParametersWhen an intracell handover is performed due to an interference situation, it is not

advisable to keep on performing handovers inside the cell if the bad quality situation is still present. Trough this feature activation, a maximum number of attemps during a certain time will be tried. If more handovers are triggered during that time, the handover is scalated to rxqual handover.

Possible parameter values are:

hop_count: 2

hop_count_timer: 5



6.7 Handover Margin per Cause

6.7.1 Description

Two handover margins have been configured per neighbour, specific to the cause of the handover being performed. This cause specific handover margin will always be used in determinig if the neighbour should be excluded from the candidate list.

ho_margin_rxqual[n]: The value to be applied to the PBGT calculation when handover cause is RXQUAL.

If PBGT - ho_margin_rxqual[n] < 0, the neighbour will be excluded.

ho_margin_rxlev[n]: The value to be applied to the PBGT calculation when handover cause is RXLEV.

If PBGT - ho_margin_rxlev[n] < 0, the neighbour will be excluded.

A per cell flag is used to determine if the cause specific margin should be used in the candidate ordering procedure.

ho_margin_usage_flag = 0 ho_margin[n] value (standard handover margin) will be used for sorting the candidate list for RXLEV and RXQUAL handovers.

ho_margin_usage_flag = 1 ho_margin_rxqual[n] or ho_margin_rxlev[n] will be used for sorting the candidate list for RXQUAL or RXLEV handovers.

Individual neighbors can be guaranteed to not be the target of a particular type of handover by setting the cause specific margin to the highest value. The margin can be set to control the level at which the neighbor must be at before considering it as a candidate for a specific handover cause.



Figure 41: Exclusion and Sorting Procedures when Handover Margin per Cause is applied

6.7.2 Application With this feature, there is more flexibility since it gives the possibility to:

- Avoid the handover to unwanted neighbours where the call would be in risk.

- Sort the neighbours in the desired order, for going to the less congested cells or to the less interfered neighbours.

- Handover the calls only to good neighbours. For some of them this condition will be satisfied even with negative PBGT to the server and for others, it will be neccessary to have possitive PBGT.

6.8 Timed Offset upon RXQUAL Handover

This feature addresses a particular situation that normally happens in the systems: it is possible for the serving cell to have a much better RXLEV than a neighbor when a call is handed over to the neighbor for RXQUAL reasons. This situation would likely result in a power budget handover back to the original serving cell. If the poor RXQUAL condition still exists, the call may experience a continuous bouncing between cells.

The ping pong protection mechanism is implemented to help in this situation.



- When a channel is activated as the target channel of a RXQUAL handover, the bounce_back_qual_tmr is started. Its value is the number of SACCH periods during which bounce_protect_margin is applied.

- When a channel is activated as the target channel of a congestion handover, the bounce_back_cong_tmr is started. Its value is the number of SACCH periods during which bounce_protect_margin is applied.

- bounce_protect_margin: additional value added to the configured ho_margin of the source cell

Quality HO(Timer starts)

ho_margincell1 = a

ho_margincell1 = a + penalty(Timer expires)

Cell 1Cell 1

Cell 1Cell 1

Cell 2Cell 2

Cell 2Cell 2ho_margincell1 = a

Figure 42.- Ping-Pong Protection Mechanism in a Rxqual Handover

The tables below show how the candidate exclusion and ordering procedures are carried out for different conditions. An interference handover cause which results in an intercell handover due to lack of resources on the serving cell will be treated in the same way as a RXQUAL handover.

The criteria for excluding neighbors from the candidate list is PBGT(n) - MARGIN(n) < 0, where MARGIN(n) is shown bellow.

EXCLUSION CRITERIA

HANDOVER TYPE TIMER TYPE MARGIN(n)

BETTER CELL CONG ho_margin[n] + bounce_protect_mar

BETTER CELL QUAL ho_margin[n] + bounce_protect_mar

BETTER CELL NONE ho_margin[n]

UL/DL RXQUAL CONG ho_margin_rxqual[n]

UL/DL RXQUAL QUAL ho_margin_rxqual[n] + bounce_protect_mar

UL/DL RXQUAL NONE ho_margin_rxqual[n]



UL/DL RXLEV CONG ho_margin_rxlev[n]

UL/DL RXLEV QUAL ho_margin_rxlev[n] + bounce_protect_mar

UL/DL RXLEV NONE ho_margin_rxlev[n]

The sorting of neighbors in the candidate list is performed according to the value of PBGT(n) - MARGIN(n). The highest value being first in the list, and others included in decreasing order. The value for MARGIN(n) is determined as shown in the following tables:

SORTING CRITERIA

HANDOVER TYPE TIMER TYPE Ho_margin_usage_flag MARGIN(n)

BETTER CELL CONG 1 ho_margin[n] + bounce_protect_mar

BETTER CELL CONG 0 ho_margin[n] + bounce_protect_mar

BETTER CELL QUAL 1 ho_margin[n] + bounce_protect_mar

BETTER CELL QUAL 0 ho_margin[n] + bounce_protect_mar

BETTER CELL NONE 1 ho_margin[n]

BETTER CELL NONE 0 ho_margin[n]

UL/DL RXQUAL CONG 1 ho_margin_rxqual[n] + bounce_protect_mar

UL/DL RXQUAL CONG 0 ho_margin[n] + bounce_protect_mar

UL/DL RXQUAL QUAL 1 ho_margin_rxqual[n] + bounce_protect_mar

UL/DL RXQUAL QUAL 0 ho_margin[n] + bounce_protect_mar

UL/DL RXQUAL NONE 1 ho_margin_rxqual[n]

UL/DL RXQUAL NONE 0 ho_margin[n]

UL/DL RXLEV CONG 1 ho_margin_rxlev[n] + bounce_protect_mar

UL/DL RXLEV CONG 0 ho_margin[n] + bounce_protect_mar



UL/DL RXLEV QUAL 1 ho_margin_rxlev[n] + bounce_protect_mar

UL/DL RXLEV QUAL 0 ho_margin[n] + bounce_protect_mar

UL/DL RXLEV NONE 1 ho_margin_rxlev[n]

UL/DL RXLEV NONE 0 Ho_margin[n]

6.9 Micro – Micro Quality Handover

6.9.1 Description

When a RXQUAL handover condition exists, an attempt will be made to handover a call which is in the microcell layer to another cell in the micro layer. A layer indication for the serving cell and the neighbor type of the neighbors is used to prioritize the microcell neighbors. The lower the number for the layer indication, the larger the layer. Currently, this means that cell level 0 = macro layer, cell level 1 = micro layer. The parameters used to implement this are:

cell_level_indicator 0: macrocell

1: microcell

prioritize_microcell 0: Layer of serving cell will not impact sorting of candidate list

1: Layer of serving cell will impact sorting of candidate list

MacrocellMacrocell

ServerServerMicrocellMicrocell

ServerServerMicrocellMicrocell

ImperativeHandover

Figure 43: Micro – Micro Quality Handover



RXQUAL Handovers can effectively be disabled to a specific neighbor by setting the ho_margin_rxqual[n] for that neighbor to the highest value. Handover candidates will be prioritized as described next.

The following ordering will only be performed if the functionality is enabled via the prioritize_microcell flag, and the bounce_protect_qual_tmr (Timed Offset upon RXQUAL Handover) is not active. The dependency on bounce_protect_qual_tmr is to prevent a call from ping ponging between two microcells if bad RXQUAL exists in both.

ORDERING

RXQUAL condition with call in microcell layer:

1. All neighbors which exceed rxlev_min[n] + Max (0,Pa)

2. All neighbors remaining after exclusion procedure considering handover margin per cause

3. Neighbor types prioritized :

(a) 4,5,6 sorted by PBGT - margin followed in the list by

(b) 3 sorted by PBGT - margin followed in the list by

(c) 1,2 sorted by PBGT - margin

RXQUAL condition with call in macrocell layer:

1. All neighbors which exceed rxlev_min[n] + Max (0,Pa)

2. All neighbors remaining after exclusion procedure considering handover margin per cause

3. Neighbor types prioritized :

(a) 1 sorted by PBGT - margin followed in the list by

(b) 2,3,4,5,6 sorted by PBGT – margin

6.9.2 Application The purpose of this feature is to maintain the call in the micro layer even when the

handover cause is imperative. There is no reason to handover the call to the macrocellular layer if we could find a suitable micro for retaining the traffic in the lower layers.



6.10 Handover based on path loss calculation

With this feature, the BSS uses measurement information to derive the power level to be included in the Handover Command for inter-cell, intra-BSS handovers if the flag use_derived_ho_power is enabled within the database.

This functionality can only be provided for intra-BSS handovers because the target cell needs the power level information to be included in the initial downlink SACCH. Therefore, the target cell must have access to the handover power level that is included in the Handover Command. GSM Recommendations TS GSM 08.08 does not provide a means to convey power information to the target cell for an external handover. Therefore, the target cell is unable to compute the power level for external handovers since it does not know the received level strength reported by the Mobile Station.

The power level is calculated for intra-BSS handovers as follows:

Handover power level (Intra-BSS) = MIN (C + (A - B), D, P)

Where:

A max_tx_bts of the target cell

B RxLEV reported by the MS for the target cell

C middle of the power box of the target cell:

(u_rxlev_ul_p + l_rxlev_ul_p)/2

D max_tx_ms of the target cell

P maximum power capability of the MS

It is easy to realise in the formula above that A-B is the path loss between the mobile and the target cell, and C is the centre of the target cell's uplink power control window. So to achieve an rxlev_ul in the centre of this window, the mobile needs to transmit this level (C) plus the path loss (A-B), hence C+(A-B).

This is the desired handover power level, but of course it cannot be used if it is greater than either max_tx_ms (D) or the mobile's physical capability to produce power (P), therefore the lowest of the three terms is used (min).

Apparently the formula above would work OK, but the actual radiated DL transmit power (e.g. signal loss from levels of combining, calibration from site commissioning, etc.) cannot be attained from the database. The path loss calculation will initially result in the MS not accessing exactly in the middle of the power box. To compensate for the transmit power discrepancy, a power adjustment mechanism is needed. This is where the gamma factor comes in. A weighted average is maintained by CP as to how much deviation from the middle of the power box after each handover. Initially, the power adjustment used is zero. The gamma factor is maintained internally.

The corrected formula should be:

handover power level = min (C + [(A-gamma) - B], D, P)

For incoming external handovers, the BSS always instructs the Mobile Station to use



the value of handover_power_level as defined within the database of the target cell. Additionally, if the flag use_derived_ho_power is disabled in the database, the BSS uses the value of handover_power_level at the target cell for incoming intra-BSS handovers.

6.10.1 Application As “fast initial power down”, it is recommended to enable this feature in all kind of

networks, as it is very important to have the power of both the mobile and the base station in the minimum required level for having good quality in the system.

6.11 All channels at full power

All channels at full power sets all the channels in the Cell to broadcast at a constant power being the power level configured as the maximum transmit power allowed in the Cell. This can be necessary for worst case interference monitoring during network optimization. The full power mode can be terminated manually at any time, or automatically stoppped by the BSS on expiration of a timer that we set when the full power mode is activated. Activation of the full power mode will not affect the availability of channels used for the normal processing of calls in the Cell, idle channels will transmit dummy bursts at the power level set by max_tx_bts, the channels are still available for use.

When full power mode is switched on, active channels are affected as follows:

Downlink power will be changed to max_tx_bts.

Downlink DTX will be disabled.

Dynamic downlink power control will be disabled.

The parameters that support the activation or deactivation of full power mode for a particular Cell or Site are:

- set_full_power <site> or <gsm_cell_id> on <minutes>

where <minutes> specifies the number of minutes the cell remain in full power mode, with

- set_full_power <site> or <gsm_cell_id> off

switches off full power mode for the Cell or Site.

6.12 Advanced handover statistics

Statistics containing the number of successful handovers, handover failures, and the type of handover cause are produced on a per-neighbour basis. This helps to monitor the performance of the system and to detect specific handover and network problems.



7. UNDERLAYING OTHER VENDORSMotorola has proved its capability to underly other vendors trough the deployment of

large microcellular networks under ERICSSON, NOKIA, ALCATEL or SIEMENS macrocells.

When a microcellular underlay is going to be deployed with a different macrocellular verdor, there are two things to consider:

The hand-down (macro to micro) is vendor dependant, so each vendor has a different implementation for this purpose.

The hand-up is Motorola dependant, so all Motorola capabilities for triggering the handover can be used.

A quick view of the interface between other vendor macros and Motorola micros is presented in the next paragraphs.

7.1 Ericsson

The required information about the handover process definition in Ericcson systems is summarised next.

The parameters to define in the Ericsson system are:

- level: This is the type of cell:

1 = microcell

2 = standard cell

3 = umbrella cell

In this case it should be set to 1 (microcell)

- ptimtemp (0-600 sec.):

This is the time during which a penalty level (defined by the psstem parameter) is applied to the level reported by the micro. This timer triggers when the micro is reported as a neighbor. It is the same than Motorola penalty time and typical values are from 10 to 15 seconds.

If ptimtemp = 10, this means that during 10 seconds the level reported from the micro is decreased by the number of dB's defined in psstem.

- psstem (0-63):

This is the level (in dB) by which the level reported from the micro is decreased during the time defined in ptimtemp. It is the same than Motorola penalty level and a typical value is 63 (max value).

If psstem = 63 and ptimtemp = 10, during 10 seconds the level reported from the



micro is artificially considered to be 63 dB worse than in reality.

In fact, with this value of psstem (63), this means no handover will be performed to the micro during ptimtemp seconds.

- levthr (0-150): This represents the level (in dBm, changed to positive) above which the mobile should receive from the micro to perform a handover to it. For example, levthr = 90 means that if the level from the micro is above -90 dBm the handover is performed from the macro to the micro. A typical value is 70 (-70 dBm).

Other parameters that may also have influence on this handovers, are:

aw (on, off):

Flag to allow handover to a worse cell (equivalent to a PBGT handover with negative ho_margin).

This parameter should be set to ON, to permit divert higher amount of traffic to the micros.

awoffset:

Margin in dB bellow the server for a worse cell to receive a handover.

If awoffset = 20, a handover to a cell with PBGT -20 is allowed.

With the parameters explained above, the way the handover to microcells works is as follows (applicable to either internal or external neighbours):

The Motorola microcell is defined as an external neighbour to the Ericsson macro.When the micro starts to be reported by the mobile as a neighbor candidate, the timer defined by ptimtemp is triggered and the value defined by psstem is subtracted from the RXLEV reported from the micro.

In the normal case, it is set psstem=63 what effectively makes no possible handover to the micro during ptimtemp seconds, and when the timer expires, if the microcell is reported above the level defined by levthr (-dBm), the handover is triggered to the micro.

7.2 Alcatel

Alcatel mechanism is similar to Ericsson´s, the handover relied only upon a pre-determined level of the neighbor cell.

The Penalty time and Penalty level must be similar to Ericsson values:

- Penalty level = 63 (max value)

- Penalty timer = 10-15 seconds

- Threshold level = -70 or -75 dBm



7.3 Siemens

They use two different mechanisms to go down in layerd networks:

- One mechanism similar to our type six handover.

- Normal PBGT .

7.4 Nokia

Two mechanisms are available:

- Umbrella handovers

- PBGT + minimum micro received level

Umbrella handovers.

The hadheld phones will be directed to microcells and the car/portable phones to macrocells. The target cell selection is based on the MS power class and on the macro/micro cell definition parameters.

Equation:

If (adj_cell_rxlev > ho_level_umbrella)

&& (ms_pwr_capability < microcell_threshold)

&& (ms_txpwr_max < microcell_threshold)

do Umbrella_Handover

Where:

microcell_threshold: the mobiles under this threshold are considered low power MS

ho_level_umbrella: required adjacent cell signal strength in microcell

ms_txpwr_max (in microcell): maximum allowed MS transmitting power in microcell

ms_pwr_capability: the maximum possible transmitting power of an MS

adj_cell_rxlev (in microcell): measured signal strength of adjacent microcell



Appendix APBGT Configurations Description

In this appendix the different PBGT configurations are described in detail.

Standard Configuration

Initial conditions:

- at least HREQAVE_NCELL(n) measurements have been received

Procedure:

For every SACCH multiframe period,



IF ( pbgt (n) > HO_MARGIN (n) )

handover cause is generated pertaining to cell N

Line of Sight Configuration.

Initial conditions:


- qualify_count = 0 (number of measurements reports on that channel)

Procedure:




qualify_count = qualify_count + 1

IF ( qualify_count = QUALIFY_TIME (n) )



IF ( pbgt(n) > HO_MARGIN(n) )


Around the Corner Configuration.

Initial conditions:


Procedure:




IF ((rxlev_dl_sc<RXLEV_SERV_L(n))AND(rxlev_ul_sc<RXLEV_SERV_L(n)))

IF (pbgt(n) > HO_MARGIN(n))


Qualified Neighbour Configuration.

Initial conditions:


- qualify_count(n) = QUALIFY_DELAY(n)

Procedure:




IF ((rxlev_ncell(n) > RXLEV_NCELL_H (n)) AND (qualify_count(n) > 0))

qualify_count(n) = qualify_count(n)-1

IF (rxlev_ncell(n) = RXLEV_NCELL_H (n))



qualify_count(n) = QUALIFY_DELAY(n)

IF (qualify_count(n) = 0)

IF (pbgt(n) > HO_MARGIN(n) )


Dynamic Handover Margin Configuration.

Initial conditions:


- qualify_count (n) = DELAY_TIME (n)

Procedure:




IF ((rxlev_ncell(n) > RXLEV_MIN(n) + Max(0 , Pa))AND(pbgt(n) >HO_MARGIN(n)))

IF (qualify_count (n) > 0)

qualify_count(n) = qualify_count - 1

ELSE (qualify_count(n) = DELAY_TIME(n))

IF (qualify_count(n) = 0)

handover_margin_dyn = HO_MARGIN(n) + HO_STATIC_OFFSET(n)-HO_DYNAMIC_OFFSET(n)

ELSE (handover_margin_dyn = HO_MARGIN(n) + HO_STATIC_OFFSET(n))

IF (pbgt(n)>handover_margin_dyn(n))




APPENDIX BAveraging Settings

In the BTS, there is a process called Handover Detection and Power Control, included in the RSS, which is in charge of all decisions related to handover and power issues. While in dedicated mode, a number of averages are produced simultaneously and a decision is taken based on these values. There is one averaging mechanism for each kind of measurement reported. There is a different set of averaging mechanisms for either Handover and Power Control decisions, as shown bellow.

ul_level

ul_qual

dl_qual

dl_level

rxqual_ul_ho

rxqual_dl_ho

rxlev_dl_ho

rxlev_ul_ho

MEASUREMENTS AVERAGING MECHANISMS FOR HO

neigh_level surround_cell

timing_advance rel_tim_adv

Figure 44: Measurement types and their asociated averaging mechanisms for ho



MEASUREMENTS AVERAGING MECHANISMS FOR PC

ul_level

ul_qual

dl_qual

dl_level

rxqual_ul_pc

rxqual_dl_pc

rxlev_dl_pc

rxlev_ul_pc

Figure 45: Measurement types and their asociated averaging mechanisms for pc

In this way, each average produced with dl_level measurements will be produced by rxlev_dl_ho (if it is for handover purposes) or rxlev_dl_pc (if it is for power control). The same would be applied to the other measurement types.

Till now it has been shown that there is one averaging mechanism producing averages for each kind of measurement. The process becomes more complex if we consider that one kind of measurement can be used to take more than one decision (i.e. dl_level measurements are used for PBGT handovers, GSM criteria 2, interference handovers and downlink level handovers). In this way, the same averaging mechanism could be producing averages for more than one decision process.

ul_qual_pc

dl_qual_pc

dl_level_pc

ul_level_pc

DECISION PROCESSES

rxqual_ul_pc

rxqual_dl_pc

rxlev_dl_pc

rxlev_ul_pc

AVERAGING MECHANISMS FOR PC

Figure 46: Av. mechanisms and the decision processes they will generate averages for



PBGT_ho_neig_levelneigh_level_criteria2neigh_level_criteria1

ul_qual_ho

dl_qual_ho

dl_level_hodl_interf_hoPBGT_ho_server_levelserver_level_criteria2

ul_level_houl_interf_ho

timing_advance_ho

DECISION PROCESSES

rxqual_ul_ho

rxqual_dl_ho

rxlev_dl_ho

rxlev_ul_ho

surround_cell

rel_tim_adv

AVERAGING MECHANISMS FOR HO

Figure 47: Av. mechanisms and the decision processes they will generate averages for

It is clear then that for each decision process we could have chosen a different averaging schema (hreqave and hreqt). We have to indicate to the averaging mechanism which hreqave and hreqt to use according to the decision process they are going to be used for.

Each averaging mechanism has four 32-position array associated. In the first two positions of each array we can store hreqave and hreqt for one decision process. One averaging mechanism can produce then averages for a maximum of four decision processes.

There is a database pointer associated to each one of the decision processes (although there are some pointers associated to more than one decission process). We will give a value to each pointer that represents in which one of the 32 position arrays (4 possible for each averaging mechanism) we are going to store the hreqve and hreqt for the decission process the particular pointer is associated with. This is summarized in the following graph.



DATABASE POINTERS

rxqual_ul_ho

rxqual_dl_ho

rxlev_dl_ho

rxlev_ul_ho

surround_cell

rel_tim_adv

AVERAGING

MECHANISMS FOR HO

PBGT_ho_neig_levelneigh_level_criteria2neigh_level_criteria1

ul_qual_ho

dl_qual_ho

dl_level_hodl_interf_hoPBGT_ho_server_levelserver_level_criteria2

ul_level_houl_interf_ho

timing_advance_ho

decision_1_p_bgt_rxlev_av_hdecision_1_ncell_rxlev_av_calcdecision_1_ncell_rxlev_av_calc

decision_1_ul_rxqual_av_h

decision_1_dl_rxqual_av_h

decision_1_dl_rxlev_av_h decision_1_dl_rxlev_av_ih decision_1_p_bgt_rxlev_av_hdecision_1_dl_rxlev_av_h

decision_1_ul_rxlev_av_h decision_1_ul_rxlev_av_ih

timing_advance_ho

DECISION PROCESSES

Figure 48: Av. Mechanisms, decision processes and their database pointers for ho

In this way, if we have enabled in one cell uplink level and uplink interference handovers, the way for giving to rxlev_ul_ho averaging mechanism two hreqave´s and hreqt´s (one set for uplink level ho and another for uplink interference, as this averaging mechanism produces averages for both handover types) is to store values for hreqave and hreqt in different arrays of this averaging mechanism, so we have to indicate in which arrays we are going to store the values with the database pointers as shown bellow.



rxlev_ul_ho

hreqthreqave

[a00 a01 a02 ......,a030, a031]

[4, 5,a12, ......,a130, a131]

[1,3,a22 ......,a230, a231]

[a30 a31 a32 ......,a330, a331]

{ decision_1_ul_rxlev_av_h =1

decision_1_ul_rxlev_av_ih=2

chg_act_alg_data rxlev_ul_ho <cell_id> 1 0 4,0chg_act_alg_data rxlev_ul_ho <cell_id> 1 0 5,1chg_act_alg_data rxlev_ul_ho <cell_id> 2 0 1,0chg_act_alg_data rxlev_ul_ho <cell_id> 2 0 3,1

Figure 49: Example: Different averaging schemas for the same av. mechanism

Important things to notice in Figure 48 above are:

decision_1_p_bgt_rxlev_av_h is used for averaging server and neighbour levels for PBGT handovers (although through different averaging mechanisms), so we can introduce one hreqave and hreqt for the server and another one for the neighbour, because we points at the same array number but belonging to different averaging mechanism, this is considering that we are not using hreqave per neighbour but per cell to trigger PBGT handovers. If we use hreqave per neighbour, we do not use the per cell value.

decision_1_ncell_rxlev_av_calc is used for averaging neighbour received level trough surround_cell averaging mechanism for both criteria 1 and criteria 2. This means than the same hreqave and hreqt values will be used for averaging neighbour samples for those two purposes.

decision_1_dl_rxlev_av_h is used for averaging server received level trough rxlev_dl_ho averaging mechanism for both rxlev_dl_ho and server_level_criteria2. This means than the same hreqave and hreqt values will be used for averaging neighbour samples in these two situations.

The settings for power control would be:



DATABASE POINTERS AVERAGING

MECHANISMS FOR PC

rxqual_ul_pc

rxqual_dl_pc

rxlev_dl_pc

rxlev_ul_pc

ul_qual_pc

dl_qual_pc

dl_level_pc

ul_level_pc

decision_1_ul_rxqual_av_p

decision_1_dl_rxqual_av_p

decision_1_dl_rxlev_av_p

decision_1_ul_rxlev_av_p

DECISION PROCESSES

Figure 50: Av. Mechanisms, decision processes and their database pointers for pc



APPENDIX CPower Control Settings

Changes to de BTS and MS transmit power levels are determined by the Handover Detection and Power Control process at the BTS.

Uplink and downlink measurements are transferred to the HDPC at the end of every SACCH period. In order to assure that the uplink and downlink measurements are from the same period, uplink measurements are stored during one period, to compensate the delay from the transmission of the downlink data from de MS to the BTS.

Uplink timing:

If the criteria for a change in MS is managed in time 0, HDPC receive the information one period later. After the processing delays the power order is transmitted at the beginning of period 2 and the MS starts to transmit at this power at time 3. BTS will receive this new power between times 3 and 4 and will report to the HDPC in time 5. This shows that we can not use samples in times 2, 3 or 4 for further uplink power control decisions as they do not reflect the previously ordered power control change.

Downlink timing:

If the criteria for a change in the BTS is managed in time 0, HDPC receive the information one period later. After the processing delays the new power is transmitted between periods 2 and 3 but this new measured power will not be avilable to HDPC till period 4, so measurements in periods 2 and 3 are useless.

From the timing schema exposed it can be seen that it is neccessary a delay mechanism for preventing power control decisions being taken based in measurements not reflecting the power control ordered. This could be managed in two ways:

decision_alg_num=0

After a power control order, another power order can not be made till a timer expires. The following parameters must be set properly:

- ms_p_con_interval = 4 + (hreqave*(n-p+1)) SACCH periods This is the delay for transmiting the new power + filling the averaging window with enough samples with the new power.

- bts_p_con_interval = 2 + (hreqave*(n-p+1)) SACCH periods This is delay for transmiting the new power + filling the averaging window with enough samples with the new power-.

In this case if we need a power up because of quality and a power down because of level, nothing is done.

decision_alg_num=1

In this case, if we need a power up because of quality, it is done regardless the level.



Another difference is introduced, this is that the timer does not start till the power ordered is acknowledged or a second timer expires, so we have not got to estimate how long does it take a power order to take effect. In this situation we have to set the xx_p_con_interval to (hreqave*(n-p+1)) SACCH periods (time to fill the averaging window with enough samples with the new power).

In case there is not acknowledge from the mobile, a new parameter is introduced, the xx_p_con_ack. This timer starts when a power change is ordered and stopped when it is acknowledged. If it expires before the ack. arrives, xx_p_con_interval will run. A safe value for ms_p_con_ack is 4 SACCH periods and for bts_p_con_ack 2 or 3 SACCH periods. To summarize:

xx_power_control_allowed=1

decision_alg_num=1

ms_p_con_ack = 4 SACCH periods

bts_p_con_ack = 2 or 3 SACCH periods

xx_p_con_interval=hreqave*(n-p+1) SACCH periods


GSM Basics_1

Documents

Transcript of GSM Basics_1