FTMDUALB

FTM Dual Band Field Trial
Test Report
France Telecom Mobiles DUAL BAND FIELD TRIAL
GSM900 Macrocells
Emergency HO Forced DR Capture HO Cause 21
Dual-band mobile Capture HO Cause 14
Mono-band mobile Emergency HO Forced DR
Dual-band mobile
GSM1800 Macrocells unbarred
PBGT HO GSM1800 Macrocell from a mono-band BSS Emergency HO Forced DR
Forced DR Capture HO Cause 14
This arrow indicates the possibility of : PBGT HO Emergency HO Forced DR between cells of same layer
GSM900 Microcell
Dual-band Mono-band mobile mobile Arrows with more thickness indicate highest priorities for the associated handovers
TEST REPORT
Toulouse - May 1998
Alcatel CIT Mobile Communication Division
File FTMDUALB.DOC
Reference Date 3DF 00973 0001 QZZZA 24/07/98
Edition 1.0
Page 1
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization.
Test Report
CHANGE HISTORY Version 1.0 Date 30/07/98 Nature of Change Creation
Approval Name Signatur e Name Signatur e H Derrey C Guetin
Authors Name P Pelouas CO/OC Name F Colin TD/SAS F Jarreau CO/OC J Mac Nab CO/OC
File FTMDUALB.DOC
Edition 1.0
Page 2
Test Report
TABLE OF CONTENTS
REFERENCES ...................................................................................................................... 7 ...................................................................................................................... SCOPE ............................................................................................................................... 8 ............................................................................................................................... 1 FIELD TRIAL PROJECT PRESENTATION ............................................................................. 9 PROJECT .............................................................................
1.1 CONTENT ........................................................................................................................................ 9 1.2 FTM FIELD TRIAL OBJECTIVES .......................................................................................................... 9 1.2.1 Paris 2000............................................................................................................................... 9 1.3 ALCATEL PROJECT PRESENTATION ................................................................................................ 10 1.3.1 Organisation ......................................................................................................................... 10 1.3.2 Main preparation tasks.......................................................................................................... 11 1.3.3 Resources.............................................................................................................................. 13 1.3.4 Planning ................................................................................................................................ 13 2 NETWORK DESCRIPTION .............................................................................................. 15 DESCRIPTION ..............................................................................................
1.2.2 Planning and resources ........................................................................................................... 9
2.1 CONTENT ...................................................................................................................................... 15 2.2 DUAL BAND NETWORK CONTEXT .................................................................................................. 15 2.3 DUAL BAND NETWORK DESCRIPTION............................................................................................. 16 2.3.1 Sites location......................................................................................................................... 16 2.3.2 Radio configuration............................................................................................................... 17 TEST CONFIGURATIONS AND SCENARIOS ..................................................................... 21 CONFIGURATIONS ..................................................................... 2.3.3 BSS architecture .................................................................................................................... 18 3
3.1 CONTENT ...................................................................................................................................... 21 3.2 NETWORK CONFIGURATIONS ........................................................................................................ 21 3.2.1 Introduction .......................................................................................................................... 21 3.2.2 Configurations description.................................................................................................... 22 3.2.3 Tested configurations ........................................................................................................... 23 3.3 TEST PLAN..................................................................................................................................... 23 3.3.1 Deterministic tests ................................................................................................................ 23
3.3.2 Statistic tests......................................................................................................................... 27 DUAL BAND RADIO PARAMETERS ................................................................................. 29 PARAMETERS .................................................................................
3.4 NETWORK PERFORMANCE MONITORING ....................................................................................... 27 4
4.1 CONTENT ...................................................................................................................................... 29 4.2 B5.0 RADIO DEFAULT PARAMETERS............................................................................................... 29 4.3 DUAL BAND PARAMETERS DETAILED DESCRIPTION ....................................................................... 29 4.3.1 Neighbour cells description and monitoring ......................................................................... 29
4.3.2 Classmark handling parameters ............................................................................................ 30 4.3.3 Idle mode algorithms parameters.......................................................................................... 31
File FTMDUALB.DOC Reference Date 3DF 00973 0001 QZZZA 24/07/98 Edition 1.0 Page 3
Test Report
4.3.4 Connected mode algorithms parameters............................................................................... 32 4.4 PARAMETERS SUMMARY ................................................................................................................ 41 4.4.1 Scenario independent............................................................................................................ 41 4.4.2 Scenario dependent............................................................................................................... 42 4.5 INPUTS FOR FINE TUNING.............................................................................................................. 42 4.5.1 Idle mode .............................................................................................................................. 42 5 TEST AND MONITORING TOOLS ................................................................................... 46 MONITORING ...................................................................................
4.5.2 Connected mode ................................................................................................................... 43
5.1 CONTENT ...................................................................................................................................... 46 5.2 COMMERCIAL MS........................................................................................................................... 46 5.2.1 Motorola 8900 ...................................................................................................................... 46
5.2.2 Other mobiles ....................................................................................................................... 47
5.3 TRACE MOBILES............................................................................................................................. 47 5.3.1 Current solutions .................................................................................................................. 47 5.3.2 Possible improvements ......................................................................................................... 49 5.4 ABIS INTERFACE ............................................................................................................................ 50 5.5 A INTERFACE ................................................................................................................................. 52 5.6 OMC-R COUNTERS ........................................................................................................................ 56 5.7 CALL TRACE .................................................................................................................................. 60 5.8 BSC INTERNAL TRACE.................................................................................................................... 61 6 RESULTS: RADIO COVERAGE ........................................................................................ 63 COVERAGE ........................................................................................
6.1 CONTENT ...................................................................................................................................... 63 6.2 POWER BUDGET COMPUTATION .................................................................................................... 63 6.2.1 Reminder of radio configuration ........................................................................................... 63 6.2.2 Power budget computation ................................................................................................... 63 6.3.1 1800 MHz ............................................................................................................................. 64 6.3.2 900 MHz ............................................................................................................................... 65 6.3.3 Indoor penetration losses...................................................................................................... 66 6.4 RADIO COVERAGE (ABIS INTERFACE RESULTS)............................................................................... 66 7 RESULTS: DETERMINISTIC TESTS .................................................................................. 68 DETERMINISTIC .................................................................................. 6.3 RADIO COVERAGE (AIR INTERFACE RESULTS) ................................................................................ 64
7.1 CONTENT ...................................................................................................................................... 68 7.2 TESTS METHOD ............................................................................................................................. 68 7.3 DETERMINISTIC TESTS: DETAILED DESCRIPTION............................................................................ 68 7.3.1 Scenario micro 900 > macro 1800 > macro 900.................................................................. 69
7.3.2 Scenario macro 1800 > micro 900 > macro 900.................................................................. 70 7.3.3 Extra tests............................................................................................................................. 72 RESULTS: STATISTIC TESTS ......................................................................................... 73 .........................................................................................
8.1 TESTS DESCRIPTION ...................................................................................................................... 73
File FTMDUALB.DOC
Edition 1.0
Page 4
Test Report
8.1.1 Test method.......................................................................................................................... 73
8.1.2 Collected results ................................................................................................................... 73
8.1.3 Test routes............................................................................................................................ 74
8.2 SCENARIO 1 (PRIORITY MICRO) RESULTS ANALYSIS ....................................................................... 75 8.2.1 Evaluator results ................................................................................................................... 75 8.2.2 Call set-up statistics ............................................................................................................. 77 8.2.3 Traffic statistics .................................................................................................................... 78 8.2.4 Handover statistics................................................................................................................ 79 8.2.5 OMC-R counters statistics .................................................................................................... 81 8.3 SCENARIO 2 (PRIORITY MACRO 1800) RESULTS ANALYSIS ........................................................... 82 8.3.1 Evaluator results ................................................................................................................... 82 8.3.2 Call set-up statistics ............................................................................................................. 83 8.3.3 Traffic statistics .................................................................................................................... 84 8.3.4 Handover statistics................................................................................................................ 85 8.3.5 OMC-R counters statistics .................................................................................................... 86 8.4 CONCLUSION................................................................................................................................. 86 9 RESULTS: BSS OPERATION AND STABILITY .................................................................... 88 OPERATION ....................................................................
9.1 CONTENT ...................................................................................................................................... 88 9.2 NETWORK STABILITY ..................................................................................................................... 88 9.2.1 BTS and BSC stability............................................................................................................. 88
9.2.2 OMC-R stability..................................................................................................................... 88
9.3 O&M OPERATION........................................................................................................................... 88 9.3.1 Radio parameters handling ................................................................................................... 89
9.3.2 Alarm handling...................................................................................................................... 89 9.3.3 OMC-R counters handling.................................................................................................... 90 9.3.4 IMSI trace handling............................................................................................................... 90
10 EVOLUTION OF DUAL BAND SOLUTION ......................................................................... 91 ......................................................................... 10.1 CONTENT................................................................................................................................ 91
10.2 MULTIBAND CELL OR SINGLE BCCH CONCEPT (B6)................................................................ 91 10.2.1 Introduction .......................................................................................................................... 91
10.2.2 Short description................................................................................................................... 91 10.2.3 Technical description ............................................................................................................ 92 10.2.4 Conclusion ............................................................................................................................ 95
10.3 PRIORITY MANAGEMENT IN MULTIBAND/MULTILAYER NETWORKS (B6) .................................. 96 10.3.1 Introduction .......................................................................................................................... 96 10.3.2 Short description................................................................................................................... 97 10.3.3 Technical description ............................................................................................................ 97 10.3.4 Conclusion ............................................................................................................................ 99 10.4 TRAFFIC MANAGEMENT IN MULTI LAYER AND SINGLE LAYER (B6).........................................100 10.4.1 Introduction ........................................................................................................................100
10.4.2 Short description.................................................................................................................100

Test Report
10.4.3 Technical description ..........................................................................................................101
10.4.4 Conclusion ..........................................................................................................................103
10.5 PUBLIC AND CORPORATE MICROCELLS WITHIN THE SAME NETWORK (B6) ............................103 10.5.1 Introduction ........................................................................................................................103
10.5.2 Short description.................................................................................................................103 10.5.3 Technical description ..........................................................................................................104 10.5.4 Conclusion ..........................................................................................................................104
10.6 DIRECTED RETRY WITHOUT CONGESTION (B7) .....................................................................104 10.6.1 Introduction ........................................................................................................................104
10.6.3 Conclusion ..........................................................................................................................105
10.7 ANTI PING-PONG MECHANISM IN MULTILAYER NETWORKS (B7)............................................105 10.7.1 Introduction ........................................................................................................................105
10.7.3 Conclusion ..........................................................................................................................105
11 GUIDELINES FOR DUAL BAND FIELD TRIAL .................................................................. 106 DUAL .................................................................. 11.1 CONTENT..............................................................................................................................106
11.2 SKILLS AND RESOURCES........................................................................................................106 11.2.1 Skills ...................................................................................................................................106 11.3
11.2.2 Resources............................................................................................................................107 TOOLS ..................................................................................................................................107
11.4 CONFIGURATIONS.................................................................................................................108 11.4.1 Network context .................................................................................................................108 11.4.2 Existing network : possible configurations..........................................................................108 11.4.3 Existing network : use of various suppliers .........................................................................109 11.5 TESTS....................................................................................................................................110 11.5.1 Radio coverage....................................................................................................................110 11.5.2 Behaviour of the handover algorithms.................................................................................110 11.5.3 Behaviour of the network without congestion .....................................................................110 11.5.4 Behaviour of the network in case of high traffic load ..........................................................110 11.5.5 Interworking tests ...............................................................................................................110 11.6 EQUIPMENTS .........................................................................................................................111 11.6.1 BTS......................................................................................................................................111 11.6.2 Radio equipments ...............................................................................................................111
File FTMDUALB.DOC
Edition 1.0
Page 6
Test Report
REFERENCES
FTM test plan (requirements) Plan de test de lexprimentation bi-bande REX2, Version 2.0 FTM/DOD/DEV/TCE/98.061/CP-JV Alcatel test plan (answer to FTM requirements) 3DF 00973 0001 QTZZA 3DF 00973 0002 QTZZA 3BK 13022 0323 TQZZA 3DF 00973 0003 QTZZA 3DF 00973 0004 QTZZA 3DF 00973 0005 QTZZA 3DF 00973 0006 QTZZA 3DF 00973 0007 QTZZA 3DF 00973 0008 QTZZA 3DF 00973 0009 QTZZA 3DF 00973 0010 QTZZA 3DF 00973 0011 QTZZA 3DF 00973 0012 QTZZA 3DF 00973 0013 QTZZA General Description Experimental Network Description BSS Parameters for France Telecom Release B5 B5 Radio algorithms presentation O&M follow-up method Quality of service follow-up method Algorithms evolution presentation Regression tests Selection and reselection tests Handover and mobility tests Call set-up tests Commercial network simulation tests Interworking tests B5 Multiband operation presentation
File FTMDUALB.DOC
Edition 1.0
Page 7
Test Report
SCOPE
This document contains overall report of dual band field trial that did take place with France Telecom Mobiles in May 1998 in Toulouse. The objectives of this report, which is an internal document, are: - Presentation dual band project, network and test objectives, - Describe test configurations (parameters) and provide first input for network fine tuning, - Analysis of results collected during field trial: coverage, protocol, traffic - Tools and methods outcome with proposals for improvements after field feedback, - Provide guidelines for further dual band experimentation. It will be divided in following sections: - Field trial project presentation: FTM objectives, Alcatel organization and preparation steps, - Network description: network, sites and cells architecture description, - Test configurations and scenarios: tests planned by FTM with various priority settings, - Dual band radio parameters: B5 network radio configuration to fulfil FTM scenarios, - Test and monitoring tools: tools which have been used and proposals for improvements, - Results - Radio coverage: analysis of Toulouse network radio conditions, - Results - Deterministic tests: results of unitary protocol tests, - Results - Statistic tests: analysis of traffic and HO indicators collected these tests, - Results - BSS operation and stability: analysis of O&M events and multiband operation, - Evolution of BSS multiband solution versus FTM requirements and field trial issues, - Guidelines for a dual band experimentation. In order to make a complete view of field trial and avoid necessary reading of other documents, some of these sections will sum-up FTM test plan, and Alcatel test plan. Nevertheless, reading of test plans may be necessary to get complementary information.
File FTMDUALB.DOC
Edition 1.0
Page 8
Test Report
FIELD TRIAL PROJECT PRESENTATION
1.1 CONTENT
This section gives an overall presentation of dual band field trial that did take place in Toulouse with France Telecom mobiles. It will deal mainly with project aspects, and especially: - France Telecom Mobiles objectives, - Alcatel project presentation: organisation, tasks, and planning.
1.2 FTM FIELD TRIAL OBJECTIVES

1.2.1 Paris 2000 France Telecom Mobiles Dual Band field trial has been done in context of Paris 2000 for Itinris. Paris 2000 project concerns densification of Paris: replacement of all equipment and multiplication by 4 of sites number, with further implementation of dual band once 1800 license is available (currently planned in 1999. In order to prepare this implementation, FTM has decided to evaluate dual band solutions of several suppliers: Ericsson, Nortel, Motorola, Nokia and Alcatel. A common reference document provided by FTM contained complete requirements and detailed test plan that had to be run by FTM. First version was available in January 1998, which was also the date for project start-up on Alcatel side. This field trial was one issue taken into account by Paris 2000 project team, for tender made for densification of Paris. It was therefore a critical project for Alcatel that had to be there in time for evaluation (experimental release), with a satisfying dual band solution. 1.2.2 Planning and resources 1.2.2.1 Planning
The schedule of overall suppliers evaluation (field test period) is the following: Month Motorola (REX2) Nortel (REX1) Alcatel (REX2) Nokia (REX2) Ericsson (REX2) April May June July August
Except for Nortel, field trial of all suppliers will be done one same network (called REX2). Between January and May, this planning has shifted of three weeks, for following reasons: - One week delay because of move from Paris to Toulouse, - One week delay because of unexpected frequency plan change in Toulouse, preventing from using frequencies allocated to experimental network,
Alcatel CIT Mobile Communication Division File FTMDUALB.DOC Reference Date 3DF 00973 0001 QZZZA 24/07/98 Edition 1.0 Page 9
Test Report
One week delay because of difficulties in experimentation start-up with former supplier.
Concerning Alcatel, some steps have been done in parallel with Motorola (end of Motorola tests with Alcatel installation). Moreover, a former step, called CNET evaluation had been requested by FTM to evaluate B5 BSS before authorizing its introduction on the field. Please refer to next section for a detailed overview of tasks to be managed by Alcatel side. 1.2.2.2 Resources
Preparation phase On FTM side and during preparation phase, the project was managed as follows: - Operations and Development Direction (DOD) for dual band technical aspects: test plan, network configuration definition, field tests preparation (tools, methods) - Paris 2000 project team for overall organisation and project management: logistics aspects, planning Moreover, CNET did also participate to test plan definition and was responsible for Alcatel B5 solution lab evaluation. All these people did participate to periodic preparation meetings with Alcatel. Field trial During field trial, permanent FTM resources were: - DOD engineer for local project management, deterministic tests execution, statistic tests control and results analysis, - CNET expert who did partially participate to former CNET evaluation. His task was support to FTM engineer (good knowledge of Alcatel system), and overall BSS stability control, - GSN (Groupe de Soutien National) people for exploitation support. Requirements from FTM in terms of resources supplied by Alcatel was: - One parameters engineer, with good knowledge of Alcatel solution and parameters sets, to help analysis of deterministic and statistic tests, - One operation engineer, for support in BSS operation and maintenance (faults management, logical parameters configuration, and OMC-R counters activation).
1.3 ALCATEL PROJECT PRESENTATION

1.3.1 Organisation In January 1998, when this field trial has been launched by FTM, Alcatel decided to create a project organisation in order to succeed this trial in context of Paris 2000. It has been organised as follows: - A project team (max. 5 people) leaded by CO/OC (Customer Services) with the following skills: network engineering, densification, quality of service tools and methods, operation, system specifications. Its main tasks was test plan and tools preparation, lab tests, interface with FTM and overall project control.
File FTMDUALB.DOC
Edition 1.0
Page 10
Test Report
IIV (BSS integration and validation) teams in charge of B5 integration and CNET evaluation, CO/OT (Technical Support) teams in charge of all installation aspects and also technical support on field. A major issue in preparation has been to set-up a platform similar to Toulouse BSS, in order to secure installation in Toulouse (from both hardware and software point of views), and prepare field tests. CO/OT has been in charge of preparing this BSS and did participate to lab tests. - FTM region of CO department for logistics and purchasing. Except for CNET evaluation which has been managed between IIV (one of its usual task) and CNET, this organisation allowed to have a single interface between Alcatel and FTM. Weekly meetings (with project progress report) did take place with representative of all these entities. 1.3.2 Main preparation tasks 1.3.2.1 B5 integration follow-up
B5.0 integration started in January 1998. Due to short timeframe before installation on the field (3 months), only experimental release could be available in time. A common definition of critical areas to be tested has been made with technical department. These critical areas were: - BSS radio algorithms: handovers causes detection and cell selection algorithms, - OMC-R B4 and dual band counters, - Modification of logical parameters (especially multiband ones and cell reselection), - IMSI Trace and Trace Invocation. A permanent follow-up was necessary to get a reliable B5.0 product and have an accurate view of its restrictions before starting field trial. 1.3.2.2 CNET evaluation
This task has been completely managed by integration center of technical department. Its objective from FTM point of view has changed during preparation period: - Initial objective was to ensure that B5.0 experimental BSS would not disturb commercial NSS, - After experience of first supplier (Motorola), FTM wished to enforce tests by covering the aspects mentioned in 1.3.2.1. Preparation phase of CNET evaluation consisted in the following tasks: definition of test plan, issue documents containing technical state, restriction list, known problems During three weeks test period, two minor problems have been found by CNET, which have been corrected before field tests. This evaluation has therfore been successful, with green light of FTM. 1.3.2.3 Test plan preparation
FTM had written a complete test plan describing objectives of field tests, expected configurations, planned tests, and requested QoS indicators This test plan was not dedicated to Alcatel but to all suppliers. Thus, it contained features that were not supported by Alcatel. In order to give Alcatel position versus Alcatel requirements, a complete test plan has been written containing: - Experimental Network Description: hardware and logical configuration,
File FTMDUALB.DOC
Edition 1.0
Page 11
Test Report
B5.0 Radio algorithms presentation: multiband handover and improved cell evaluation algorithms, - B5 Multiband operation presentation: parameters and OMC-R counters, - Algorithms evolution presentation: multiband B6 algorithms, - O&M follow-up method: system stability monitoring tools, - Quality of service follow-up method: QoS monitoring tools, - Regression, (re)selection, handover, call set-up, commercial network simulation, interworking tests. Moreover, during periodic meetings with FTM project team (about every month), Alcatel did present its progress in test plan preparation: B5/B6 presentations and selected configurations This preparation job has really been appreciated by FTM (especially by comparison with Motorola). 1.3.2.4 Tools preparation
Dual band is a new feature implying new tools (dual band MS), with important interface changes. Therefore all existing tools and methods had to be adapted accordingly. Main prototypes available in Toulouse were (please refer to section 5 for more detailed description): - AGLAE with ability to make separate handover and traffic statistics on dual and single band MS, - DAFNE (Abis) adapted to support dual band feature, - Dual band trace mobile rented to FOREM (based on Motorola 8900). Thanks to this preparation job, all interesting post-processing requested by FTM could be made on field. 1.3.2.5 Lab tests on clone platform
This was the most important task in field trial preparation. A platform similar to Toulouse network has been installed in lab, in order to prepare field tests. Main interests were: - Prepare equipment installation team (both hardware right technical status - and software), - Stabilize BSC database before installing a copy on Toulouse BSS, - Prepare default parameters sets, - Run tests corresponding to protocol cases foreseen to be triggered during field trial, - Detect any software problem linked to these protocol cases or specific BSS configuration, - Get a copy of Toulouse BSS during field trial to investigate / anticipate problems, - Train people on B5 algorithms and test plan before going to field, - Prepare test and monitoring tools. This quite costly strategy (duplication of BSS equipment need) has nevertheless been very efficient, because of very short installation duration and tuning time allocated to Alcatel (less than one week between BSS commissioning and field tests start-up with a very tight planning). It was also necessary to provide support during field tests. 1.3.2.6 Toulouse equipment installation
FTM supplied with complete radio installation for this field trial, from BTS output up to antennas. Alcatel was in charge of providing and installing all BSS equipment for experimentation in FTM sites.
File FTMDUALB.DOC
Edition 1.0
Page 12
Test Report
This installation has been coordinated by Technical Support of operations department and realized by teams used to work with FTM. It has to be synchronized with Motorola tests and desinstallation. Note that a special care has been taken to follow last software and hardware technical state (ETMB), with a control of MCD quality department. 1.3.2.7 Field tests
Field tests were under FTM control. Alcatel decided to provide more resources than requested by FTM (2 people for support). Main tasks realised by Alcatel during field trial were: - Support for dual band radio algorithms (B5, but also B6) and parameters: explanations of selected configurations, presentations during several meeting with FTM project team, - Extra tests routes thanks to Surveyor tool and Alcatel measurer, - Participation to deterministic tests and results analysis, - System operation: OMC-R configuration, OMC-R counters collection - Statistic tests results post-processing and analysis, - Interface with Alcatel support in Paris for problems investigations. In addition to these tasks realized by local project team (5 people), technical support has been ensured during first week of field trial. 1.3.3 Resources This section deals only with resources needed for tasks related to field tests preparation and execution. The objective of this section is only to list skills needed for each task. 1.3.3.1 Field test preparation
The following skills were involved in test plan preparation: - BSS system specification (Technical Department), especially BSS radio algorithms, - Marketing and products to describe B6 features and Alcatel dual band strategy, - Radio network engineering (from FTM region), - Densification and radio parameters, - Quality of service tools and methods for adaptation to dual band needs, - BSS System operation and maintenance. Concerning preparation lab tests on clone BSS, involved skills were: - BSS B5 telecom integration (people trained in integration center), - Radio network engineering. 1.3.3.2 Field tests execution
The following skills were involved in test field execution: - Radio network engineering and measurements, - Quality of service, - BSS operation and maintenance. 1.3.4 Planning Here is the overall and final planning of Alcatel field trial. It contains all the tasks described in previous section. Note that black cells reflect milestones requested by France Telecom.
File FTMDUALB.DOC
Edition 1.0
Page 13
Test Report
Feb CNET B5 evaluation Preparation BSS Install Tests with CNET Experimentation preparation Test plan Tools development Tools lab integration Platform installation Tests + plan tuning Field tests lab support Experimentation Sites installation Field tests Internal report
March
April
May
June
File FTMDUALB.DOC
Edition 1.0
Page 14
Test Report
2 NETWORK DESCRIPTION
2.1 CONTENT
This part of dual band experimentation report describes the network that has been used in Toulouse. It covers the following aspects: Dual band network context: interworking / connection with other networks, Dual band network description: sites and radio connection, BSS architecture: topology, cell description, and BSS software.
2.2 DUAL BAND NETWORK CONTEXT

Initial objective of FTM was to make this field trial in Paris 2000 conditions, i.e.: - Dual band network with tested supplier (Alcatel), - Interworking with an external single band macro layer supplied by Alcatel (GSM 900), - Management of micro cells belonging to Motorola (i.e. external), - Usage of a dual band E10 Alcatel NSS. But this strategy could not be applied, because ART (telecommunications regulation authority) refused usage of 1800 frequencies. FTM has therefore transferred field test in Toulouse (where it has a commercial 1800 network called Olla), and adapted interworking conditions: - Dual band network with tested supplier (Alcatel), - Interworking with an external mono band macro layer supplied by Nortel (GSM 1800), - Interworking with an external dual band macro layer supplied by Nortel (REX1), - Management of micro cells belonging to Alcatel and attached to dual band BSS, - Usage of a dual band MET Ericsson NSS. These new conditions reduced scope of interworking tests (no more real conditions, but quite same protocol situations). On the other hand, configuration of an internal microcell has increased flexibility in microcellular radio algorithms. This scheme sums-up dual band network position:
Ericsson Dual Band NSS Olla
Nortel Dual Band BSS REX1
Alcatel Dual Band BSS REX2
Nortel Single Band BSS Olla
File FTMDUALB.DOC
Edition 1.0
Page 15
Test Report
Experimental network was isolated from other networks with the following method: - No handover relationships between REX2 and Olla/REX1, except when needed for specific interworking tests. - Configuration of all REX2 cells in cell test mode (specified by GSM), i.e.: CELL BAR ACCESS = FALSE (barred) and AC1 to AC14=0 (not barred), AC15 = 1 (barred) - Usage of special Olla SIM cards to access cells in cell test mode, i.e. modified with EFAD = 04FFFF. Thanks to this method, special SIM cards allowed MS to access both Olla and REX, while commercial ones allowed only access to commercial Olla network. Nevertheless, a lot of problems have been encountered with MS which did not support such a configuration (please refer to section 5).
2.3 DUAL BAND NETWORK DESCRIPTION

2.3.1 Sites location The following map of Toulouse center shows various sites location.
CAPITOL
ST ROME
MALARET
The experimental was made of three sites located in a dense urban area, with a distance of about 500 meters between sites. Following comments can be made on antennas configuration: - Macro cell antennas had usual location and configuration, - Micro cell antenna was located on building roof, and provided rather a macro coverage.
File FTMDUALB.DOC
Edition 1.0
Page 16
Test Report
The experimental area was a dense urban area : narrow streets, high density of buildings. Notice that the height of buildings was homogeneous. 2.3.2 Radio configuration Each cell was made of a single TRX, without hopping. Antennas configurations can be summarized as follows: - Each site contained three sectorized antennas, - Each antenna support one 900 and one 1800 cell, - In Capitole site, a micro cellular antenna has been used for one 900 cell. Both 900 and 1800 bands of dual band network, and in some cases 1800 (Olla) and 900 (Itinris) commercial networks shared same antennas. Radio connection is described below. 2.3.2.1 Saint-Rome
This site was initially a dual band site, as it did support both Olla and Itinris. With field trial, it contained: - 1 tri-sectorized 900 BTS and 1 tri-sectorized 1800 BTS belonging to dual Band BSS - 1 tri-sectorized BTS belonging to 900 Itinris network - 1 tri-sectorized BTS belonging to 1800 Olla network. Connection has been made as follows: - First stage with combining of 900 (resp. 1800) Alcatel BTS and 900 Itinris (resp. 1800 Olla). Note that this combing was done in such a way that of transmission power was dedicated to commercial network (- 1.25 dB) and to experimental network (- 6dB). Indeed, one requirement of people operating Itinris and Olla networks was to not be disturb in term of coverage by the experimental network. This was not very important for the 900 Mhz layer but a big problem for the 1800 MHz layer. - Second stage with one diplexer (mixing 900 and 1800 signals), in order to have only one cable to reach building roof. These were Celwave diplexers. - Then connection to dual band Celwave antenna: vertical polarization without diversity. 2.3.2.2 Malaret
This site was initially a dual band site, as it did support both Olla and Itinris. With field trial, it contained: - 1 tri-sectorized 900 BTS and 1 tri-sectored 1800 BTS belonging to dual Band BSS - 1 tri-sectorized BTS belonging to 900 Itinris network - 1 tri-sectorized BTS belonging to 1800 Olla network. The difference with Malaret is that commercial BTS were located in a shelf on the roof, while our BTS were located in BSC room at ground level. Connection has been made as follows: - First stage with two diplexers mixing Alcatel 900 and 1800 sectors (diversity is used), in order to have only two cables to reach combining stage. These were Sofrer or Filtronic diplexers. - Second stage with combining (1/4 3/4) of 900 (resp. 1800) Alcatel BTS and 900 Itinris (resp. 1800 Olla). - Then connection to dual band DAPA antenna: cross-polar with diversity.
Test Report
2.3.2.3
Capitole
Macro sectors This site was initially an Olla site only. With field trial, it contained: - 1 bi-sectorized 900 BTS and 1 tri-sectorized 1800 BTS belonging to dual Band BSS. - 1 tri-sectorized BTS belonging to 1800 Olla network. The difference with other sites is that no combining with Itinris was necessary. Connection has been made as follows: - First stage with combining (1/4 3/4) of 1800 dual band BTS and 1800 Olla. - Second stage with two diplexers (mixing 900 and 1800 signals diversity is used), in order to have only cables cable to reach building roof. These were Sofrer or Filtronic diplexers. - Then connection to dual band DAPA antenna: cross-polar with diversity. No combining stage was used for 900 sector. Therefore, in order to balance transmission power with other sites, BTS transmission power was decreased of 6dB. Micro sectors This sector was directly connected to a Suhner panel antenna. An Evolium BTS was used for micro cell. Therefore, in order to balance transmission power and get a real micro coverage, BTS transmission power was decreased of 8 dB. 2.3.3 BSS architecture The network was composed of the following equipment: - one BSC G2 32TCU/24DTC (config 2) - one TC G2 6 TRCU 3:1 - three EVOLIUM BTS 900 S3 111 - three G2 BTS 1800 3X1 equipped with DRFU for EFR support - one host OMC-R E450 connected to one IPX. The Abis topology was composed of: - 3 multidrops containing each an EVOLIUM 900 BTS and a co-localized G2 1800 BTS, - each BTS containing 3 sectors, - each sector is equipped with one TRX, - a fourth multidrop (Abis TSU 4) is used to connect a micro BTS M2M (2 TRX) for test purpose. The N7 was mapped on the first DTC of first Atrunk.
File FTMDUALB.DOC
Edition 1.0
Page 18
Test Report
2.3.3.1
Topology
This figure gives a complete the whole BSS topology used for dual band field trial: TC/SM G2 BSC G2 Ater Abis BTS G3 S3 MEDI 900 MALARET TSU TSU OML 1 FU1 FU2 FU3 1 BTS1 DTC 1 MSC DTC 2 DTC 3 2 DTC 5 DTC 6 DTC 7 St ROME CAPITOLE BTS G3 S3 MEDI 900 OML FU1 BTS5 BTS G2 3X1 1800 OML1 OML2 OML3 FU1 FU3 FU5 BTS6 BTS7 BTS8
BTS G2 3X1 1800 OML1 OML2 OML3 FU1 FU3 FU5 BTS2 BTS3 BTS4
N7
FU2
FU3
BTS G3 S3 MEDI 900 OML FU1 BTS9
BTS G2 3X1 1800 OML1 OML2 OML3 FU1 FU3 FU5 BTS10 BTS11 BTS12
FU2
FU3
MALARET
BTS M2M 900 (test) OML FU1 FU2 BTS13
4 COMMON TSU 1 2 3 4 MALARET OMC-R E450 IPX 1 BSC Terminal
File FTMDUALB.DOC
Edition 1.0
Page 19
Test Report
2.3.3.2
Cells configuration
Each cell was mapped on a given sector and contained one TRX (BCCH combined configuration). The basic cell configuration was a single macro cell for each cell except the 900 micro cell mapped on the second sector of the G3 900 BTS in CAPITOLE site. The following table gives the mapping between BTS/TCUC index and LAC, CI, ARFCN: TSU TCUC BTS Cell Cell Name ARFCN BSIC Abis index index Index (octal) 1 1 2 1 REX2_Malaret1_900 61 00 1 1 2 2 REX2_Malaret2_900 53 00 1 1 2 3 REX2_Malaret3_900 45 01 2 1 2 1 REX2_Malaret1_1800 856 40 3 1 4 1 REX2_Malaret2_1800 854 44 4 1 4 1 REX2_Malaret3_1800 885 41 5 2 9 1 REX2_Capitole_micro_900 57 01 5 2 9 2 REX2_Capitole2_900 40 01 5 2 9 3 REX2_Capitole3_900 51 00 6 2 9 1 REX2_Capitole1_1800 875 43 7 2 11 1 REX2_Capitole2_1800 868 44 8 2 11 1 REX2_Capitole3_1800 877 45 9 3 17 1 REX2_StRome1_900 34 00 9 3 17 2 REX2_StRome2_900 27 04 9 3 17 3 REX2_StRome3_900 58 00 10 3 17 1 REX2_StRome1_1800 849 07 11 3 19 1 REX2_StRome2_1800 870 46 12 3 19 1 REX2_StRome3_1800 878 47 LAC 38144 38144 38144 38145 38145 38145 38144 38144 38144 38144 38144 38144 38144 38144 38144 38144 38144 38144 CI 1701 1702 1703 1501 1502 1503 1711 1712 1713 1511 1512 1513 1721 1722 1723 1521 1522 1523
In order to simulate dual band introduction (and especially check MS behaviour) in Paris area, France Telecom Mobiles considered that 32 neighbour cells had to be declared for each cell of the network. Therefore, every cell has the following neighbourhood: - 17 real cells belonging to experimental network, - 15 virtual cells (900 and 1800). Please refer to section 4, for more detailed description of BSS parameters. 2.3.3.3 BSS Software
An experimental version of B5.0 BSS release has been used.
File FTMDUALB.DOC
Edition 1.0
Page 20
Test Report
3 TEST CONFIGURATIONS AND SCENARIOS

3.1 CONTENT
This part of dual band experimentation report describes the tests requirements made by France Telecom. As stated in FTM test plan, FTM main objectives for field trial were: Evaluate global behaviour of a dual band network with several evolution steps, Check its implementation with existing infrastructure (hierarchical network), Evaluate and test solutions of various suppliers, and especially radio algorithms and part of traffic which can be captured by 1800 layer, Test efficiency of GSM mechanisms like reselection to manage traffic between bands, Ensure proper working of both single and dual band MS in a dual band network.
The following aspects will therefore be described: Type of configurations, i.e. different steps of network architecture, List of tests initially planned, Requirements in terms of network performance monitoring. As this field trial was not only applicable to Alcatel, some configurations or tests could not be run. This document will therefore contain Alcatel limitations versus FTM requirements. One other major element of field trial was to describe evolutions in product. Two kinds of evolutions can be defined: - those already foreseen in B6 or B7 and improving BSS dual band implementation, - those collected from field trial preparation with FTM and results. They will be described in section 10.
3.2 NETWORK CONFIGURATIONS

3.2.1 Introduction FTM test plan principle is to define several network architectures, with various priority schemes between layers, and repeat similar tests, in order to observe and compare MS behaviours and traffic management. In order to simulate future introduction of dual band in Paris network, most interesting scenarios were those with three layers: macro 900, macro 1800 and microcell. Test configurations have been defined accordingly. Alcatel task was to define suitable parameters sets based on B5.0 solution, in order to follow FTM priority mechanisms. These radio parameters are defined in section 4. They concern only configurations that have really been tested.
File FTMDUALB.DOC
Edition 1.0
Page 21
Test Report
3.2.2
Configurations description 3.2.2.1 Configuration 0 (Current Itinris)
This configuration has been defined for test purposes only. It does not correspond to a commercial network configuration. Its objective is to test dual band network behaviour when it is only controlled by radio criteria, i.e. when no capture mechanism is configured to move MS from 900 to 1800 layer (configuration without preferred band). 3.2.2.2 Configuration 1 (Short term Itinris)
This configuration could be the first introduction of dual band network, when some dual band BSS interwork with mono band BSS. Indeed, because of interworking problem, 1800 layer of dual band network need to be barred. Preferred band algorithms are active and priority mechanism that is implemented gives priority to 1800 layer, before microcell layer and macro 900 layer. It is what FTM calls Public microcell scenario, i.e.: - Single band MS follow usual behaviour in a micro cellular network (with speed discrimination), and not be disturbed by addition of 1800 layer, - Dual Band MS are sent to 1800 layer in order not to load microcell layer. 3.2.2.3 Configuration 1 bis (Short term Itinris)
This configuration is a variant of configuration 1, with changes in priority order. Preferred band algorithms are active and priority mechanism that is implemented gives priority to microcell layer, before macro 1800 layer and macro 900 layer. It is what FTM call Corporate microcell scenario, i.e.: - Single band MS follow usual behaviour in a micro cellular network (with speed discrimination), and not be disturbed by addition of 1800 layer, - Dual Band MS are sent to microcell layer in order to generate traffic on corporate microcell. 3.2.2.4 Configuration 2 (Medium term Itinris)
This configuration is the definitive introduction of dual band network with multiband BSC solution, when only dual band BSS are installed in the network. Interworking problem has disappeared. Preferred band algorithms are active and priority mechanism which is implemented gives priority to 1800 layer, before microcell layer and macro 900 layer (Public microcell scenario see above). 3.2.2.5 Configuration 2 bis (Medium term Itinris)
This configuration is a variant of configuration 2, with changes in priority order. Preferred band algorithms are active and priority mechanism which is implemented gives priority to microcell layer, before macro 1800 layer and macro 900 layer (Corporate microcell scenario see above).
File FTMDUALB.DOC
Edition 1.0
Page 22
Test Report
3.2.2.6
Configuration 3 (Long term Itinris)
This configuration is the one preferred by FTM in long term. It is based on Multiband Cell feature (also called single BCCH). This solution avoids management on 1800 BCCH. Priority mechanisms that are implemented must be very flexible and efficient to manage autonomously traffic repartition between 900 and 1800 TRXs. This solution which is not in B5 is fully described in section 10. 3.2.3 Tested configurations Not all these configurations have been tested in Toulouse, for different reasons: - Configuration not supported by Alcatel, - Configuration with low priorities and skipped because of planning contraints. FTM has selected the most representative configurations, which correspond to definitive implementation of Multiband BSC solution (B5.0) on a microcellular network. This table sums up configurations and test status: Number 0 1 1bis 2 2bis 3 Description Multiband BSC: No preferred band Multiband BSC: 1800 preferred band. Priority to 1800 cells. 1800 barred. Multiband BSC: 1800 preferred band. Priority to microcells. 1800 barred. Multiband BSC: 1800 preferred band. Priority to 1800 cells. Multiband BSC: 1800 preferred band. Priority to microcells. Multiband cell Tested NO NO NO YES YES NO Reason VERY LOW PRIORITY LOW PRIORITY LOW PRIORITY HIGH PRIORITY HIGH PRIORITY NOT SUPPORTED
Nevertheless, Alcatel did provide a complete test plan with all configurations including: - Parameters sets to be applied to get expected priority mechanism, - Dynamic BSS behaviour description for both single and dual band MS, - Next releases improvements and impact on this dynamic behaviour, - Methods to move from one configuration to the other. Please refer to this test plan for more information.
3.3 TEST PLAN

3.3.1 Deterministic tests Deterministic tests are unitary protocol and radio algorithms tests, with possible tuning of BSS radio parameters. This section deals with test domains covered by deterministic tests and Alcatel positioning. Detailed results will be included in section 7.
File FTMDUALB.DOC
Edition 1.0
Page 23
Test Report
3.3.1.1
Regression tests
The objective is to check that dual band BSS works properly on both 1800 and 900 layers, thanks to call set-up, localization, SMS tests. They were under Alcatel responsibility, but results were not requested by FTM. 3.3.1.2 Reselection tests
The objective is rather to check MS behaviour than testing BSS. Indeed, BSS is only responsible for broadcasting appropriate SYSTEM INFORMATION parameters. This table gives list of test situations and Alcatel B5.0 support. MS speed disc. mention means that speed discrimination is applied in reselection mechanism. FTM test domain B5.0 Priority order: 1800 macro (MS speed disc.) > micro (MS speed disc.) > 900 Supported macro Priority order: 900 macro > 1800 macro > 900 micro Supported Priority order: 1800 macrocell microcell (MS speed disc.) - 900 macrocells Supported Priority order: microcell 1800 macrocell - 900 macrocell (MS speed disc.) Supported 3.3.1.3 Call set-up tests
The objective is to simulate: - directed retry when cell is completely or partially congested, - with forced (i.e. capture), better cell and emergency handover causes. for both step 2 and 2bis and every couple of cell type (micro, 1800, 900). This table gives list of test situations and Alcatel B5.0 support: FTM test domain Congestion in serving cell 100% Congestion in serving cell 70% Radio problems in serving cell without congestion Radio problems and congestion (100%) in serving cell Capture (better radio conditions in neighbour cell) without congestion Better radio conditions in neighbour cell and congestion (100%) in serving cell B5.0 Supported Not supported Not supported Supported Not supported Supported
Comments: Up to B5, SDCCH to TCH handovers are possible only in case of TCH congestion in the serving cell by means of Directed Retry or Forced Directed Retry.
File FTMDUALB.DOC
Edition 1.0
Page 24
Test Report
3.3.1.4
Handover
Better condition causes and priorities The objective is to simulate better cell conditions between any layer, as summarized in the following table: FTM test domain macro 900 macro 900 macro 900 macro 1800 macro 900 900 macro 1800 macro 1800 macro 1800 macro 900 macro 1800 900 900 macro 900 900 macro 1800 900 900 B5.0 Better cell Capture Capture Better cell Not supported Capture Better cell (fast MS) Better cell (fast MS) Better cell
Comments: Capture handover is a special better cell case much less restrictive than usual PBGT in order to manage traffic. It is possible between cells of different layers, or different bands. Better cell outgoing from microcell could not be tested in REX2, because only one cell was available. The only impossible case is handover 1800 to 900 layers that can only be achieved through emergency handover. It makes necessary a specific parameters set for zone exit case (see below).
Speed discrimination tests The objective is to check Alcatel microcellular algorithms related to speed discrimination. FTM test domain Possibility to prevent fast mobile from going into the microcell layer Possibility to handle variable speed Congestion tests The objective is check BSS ability to take into account load of serving and neighbour cells in HO decision. B5.0 Supported Supported
File FTMDUALB.DOC
Edition 1.0
Page 25
Test Report
FTM test domain Possibility to take into account the traffic load of the serving cell Possibility to take into account the traffic load of the neighbour cells in order to give a higher priority to a given layer (micro 900 or macro 1800) Handover alarm on traffic cause
B5.0 Supported Not supported
Not supported
Comments : Concerning second topic, BSS is able to take into account load of candidate cells to order them (load or free factors), but after ordering by band or layer. Third topic is ability to trigger a handover to free some channels on serving cell.
Interference tests The objective is to check priority management for emergency handover. Addition of improved cell evaluation process in B5 has provided a lot of flexibility. FTM test domain Possibility to tune the priority order of the candidate cells when an emergency alarm is triggered Zone exit tests FTM wanted to check how BSS behaves when MS station connected on 1800 layer leaves an area with both bands and enters an area with only 900 band. FTM test domain Possibility to rescue a call when leaving a GSM1800 zone Possibility to anticipate the zone exit by better cell handover B5.0 Supported Not supported B5.0 Supported
Comment: Second topic is not supported through PBGT handover (FTM request). Another solution based on usage of PBGT filtering process could be demonstrated (please refer to section 4.5.2.3). Interworking
3.3.1.5
The objective is to demonstrate proper interworking with dual band BSS belonging to another supplier (i.e. Nortel) and to highlight interworking problem occurring with single band BSS.
File FTMDUALB.DOC
Edition 1.0
Page 26
Test Report
FTM test domain Nortel Single band 1800 Alcatel Dual Band Nortel Dual Band Alcatel Dual Band Alcatel Dual Band Nortel Single band Alcatel Dual Band Nortel Dual Band Alcatel Dual Band 1800 Alcatel Dual Band 900 Nortel Single band 1800 Alcatel Dual Band 1800 Nortel Single band 1800
B5.0 Supported (1) Supported Supported (3) Supported Supported (2) Supported
Comments :
(1) Classmark enquiry will be triggered by Alcatel target BSS to allow dual band capacity. (2) In that case, no problem occurs, as initial layer on dual band BSS and target layer are the same. (3) This configuration must be forbidden in a commercial network (GSM1800 cell barred), while interworking with GSM900 network. Indeed, power capability in MS and BSC are inconsistent and will prevent dual band MS from making further handover. 3.3.2 Statistic tests Statistic tests are a systematic coverage of REX2 area in idle and connected mode, with a stabilized parameters set. The objective of these tests is to follow layer the MS in located on, with various situations: - In idle and connected modes, - In outdoor and indoor conditions. The objective is to check that Alcatel solution and parameters set are pertinent to manage single and dual band flows between different layers and according priorities, and also to measure part of traffic which can be captured by 1800 layer. Statistic tests results are available in section 8.
3.4 NETWORK PERFORMANCE MONITORING

The following table sums up main indicators requested by FTM and solution brought with current OMC-R counters and tools. FTM Requirement Indicators Call Drop RxQual - RxLev distribution in UL and DL % of Traffic handled Rate of HO Cause x per couple of layer Rate of DR cause x per couple of layer Rate of HO failures with drop per couple of layer Rate of HO failures without drop per couple of layer Rate of DR failures per couple of layer Number of Location Update per layer Alcatel Solution
Global Per MS Per Layer AGLAE DAFNE OMC IMSI Trace
X X X X X X X X X
X X X (X) X X (X) X X (X) X
(X) (X)
(X)
Between brackets are mentioned supports with restrictions. Main restrictions are due to nonsupport of statistics per mobile type in DAFNE and OMC-R counters.
Test Report
A complete report on test and monitoring tools is available in section 5 and explains/describes limitations of tools or OMC-R counters/trace. It will therefore not been described in detail in this section.
File FTMDUALB.DOC
Edition 1.0
Page 28
Test Report
4 DUAL BAND RADIO PARAMETERS

4.1 CONTENT
This document describes sets of parameters used to operate dual band experimental network, according FTM test configurations and test requirements. It applies only to configurations that have really been tested on the field, i.e.: - Scenario with priority: micro 900 > macro 1800 > macro 900, - Scenario with priority: macro 1800 > micro 900 > macro 900, It applies to Multiband BSC solution (i.e. 900 MHz cells and 1800 MHz cells connected to the same BSC) of B5.0, which has been tested in Toulouse.
4.2 B5.0 RADIO DEFAULT PARAMETERS

Following FTM requirements, all parameters that were not impacted by dual band feature and field trial had to be compliant with default BSS parameters used by FTM. A specific document has been written containing this set of parameters and reviewed by CNET. Please refer to this document (3BK 13022 0323 TQZZA) for complete description of parameters which are not described in following section.
4.3 DUAL BAND PARAMETERS DETAILED DESCRIPTION

4.3.1 Neighbour cells description and monitoring 4.3.1.1 Neighbour cells list
Parameters description Because the network is built with cells belonging to different frequency bands, it is necessary to send to dual band mobiles the list of neighbour cells in each frequency band in order to allow monitoring, re-selection and handover. In idle mode, neighbour cells BCCH frequencies are included in System Information 2, 2bis and 2ter on the BCCH: Serving cell/neighbour cells 900 1800 900 SI 2 SI 2ter 1800 SI 2ter and 2bis SI 2 and 2bis
In dedicated mode, neighbour cells BCCH frequencies are included in System Information 5, 5bis and 5ter and sent on the SACCH: Serving cell/neighbour cells
Alcatel CIT Mobile Communication Division File FTMDUALB.DOC
900
1800
Edition 1.0
Page 29
Test Report
900 1800
SI 5 SI 5ter
SI 5ter and 5bis SI 5 and 5bis
BSS parameter EN_INTERBAND_NEIGH enables or disables sending of SI 2bis/2ter and SI 5bis/5ter. If EN_INTERBAND_NEIGH is set to disable, sending of SI 2bis/5bis is disabled for 900 MHz cells only. Field trial setting EN_INTERBAND_NEIGH has been set to ENABLE. 4.3.1.2 Monitoring
Parameters description It is necessary to tell to a dual band mobile how to report neighbour cells (only 6 neighbour cells are reported) using the parameter (set on a per cell basis) MULTIBAND_REPORTING. MULTIBAND_REPORTING There are four values: - 0: 6 strongest cells irrespective of the frequency band - 1: strongest cell (frequency band different of serving cell frequency band) + 5 strongest cells (serving cell frequency band) + strongest cells (irrespective of the frequency band) - 2: 2 strongest cells (frequency band different of serving cell frequency band) + 4 strongest cells (serving cell frequency band) + strongest cells (irrespective of the frequency band) - 3: 3 strongest cells (frequency band different of serving cell frequency band) + 3 strongest cells (serving cell frequency band) + strongest cells (irrespective of the frequency band). Field trial setting For the field trial, default value of MULTIBAND_REPORTING was 3. 4.3.2 Classmark handling parameters 4.3.2.1 Parameters description
MS stations send a Classmark 1 (CM1) or Classmark 2 (CM2) information in the first message sent to the network. In case of LOCATION UPDATING procedure (CM1 sent only), the BSC has to request the CM2 parameter to get complete ciphering capabilities (parameter BSS_SEND_CM_ENQUIRY). When the MS is a dual band one, and it supports early classmark BSS_SEND_CM_ENQUIRY sending, this request do not need to be done. Moreover, dual band capability information is contained in CM3 field with Power Capabilities of both bands. Only when the NSS support dual band feature (i.e. is able to process that field), the BSS has to forward this field as it is (parameters STRIP_O5_CM2 and EN_SEND_CM3). EN_SEND_CM3 4.3.2.2 Field trial setting
For field trial, the following values have to be used: - BSS_SEND_CM_ENQUIRY = 1 (always send CM ENQUIRY if LOCATION UPDATE and ES_IND=0), - EN_SEND_CM3 = 1 (enabled, no field removal), - STRIP_O5_CM2 = 0 (no processing on classmark information).
File FTMDUALB.DOC
Edition 1.0
Page 30
Test Report
With this parameter set, BSS is considered as a dual band BSS and is configured to interwork with a dual band NSS. 4.3.3 Idle mode algorithms parameters It is very important to direct mobiles to the desired layer not only in dedicated mode but also in idle mode in order to take full advantage of each layer. Because dual band mobiles are phase 2 mobiles it is possible to use the parameter CELL_BAR_QUALIFY and the C2 criterion. 4.3.3.1 Selection
Parameters description The parameter CELL_BAR_QUALIFY is set on a per cell basis. It is understood only by phase 2 mobiles (single and dual band) and is broadcast on the BCCH. There are two values: 0 in order to give a normal priority and 1 for a lower priority. A phase 2 mobile selects the cell with the highest C1 (C1 > 0) belonging to the list of highest priority. Typical dual band configuration would be to set CELL_BAR_QUALIFY to 0 for 1800 MHz cells and to 1 for 900 MHz cells in order to give a higher priority to 1800 MHz cells. CELL_BAR_QUALIFY interacts with the parameter CELL_BAR_ACCESS (see rec. GSM 05.08) and is only relevant when CELL_BAR_ACCESS is set to TRUE (cell not barred). Field trial setting For the field trial, because cells were barred, parameter CELL_BAR_QUALIFY value was meaningless. 4.3.3.2 Re-selection
Parameters description Using the C2 criterion, it is possible to have different level of priority in the network. This criterion is only used by phase 2 mobiles. According to the parameter PENALTY_TIME there are two formulas: - if PENALTY_TIME <> 31 C2 = C1 + CELL_RESELECT_OFFSET -TEMPORARY_OFFSET*H(PENALTY_TIME - T) - if PENALTY_TIME = 31 C2 = C1 - CELL_RESELECT_OFFSET - with H(x) = 0 if x < 0 and H(x) = 1 otherwise. H(x) = 0 for the serving cell. T is a timer incremented from 0 when the neighbour cell enters in the list of the 6 strongest neighbour cells. T is put back to 0 when the neighbour cell doesnt belong to this list any longer. Thanks to this timer, it is possible to take into account the speed of a mobile.
File FTMDUALB.DOC
Edition 1.0
Page 31
Test Report
CELL_RESELECT_OFFSET (0 to 126 dB, 2 dB steps), TEMPORARY_OFFSET (0, 10, 20, 30, 40, 50, 60, infinite dB) and PENALTY_TIME (0 to 620 s, 20 s steps) are broadcasted on the BCCH if CELL_RESELECT_PARAM_IND = 1. Otherwise, C2 = C1. Field trial setting For the field trial, two sets of re-selection parameters have been successfully used: - scenario micro 900 > macro 1800 > macro 900: Cell CELL_RESELECT_OFFSE TEMPORARY_OFFSE T T Macro 900 0 0 Macro 1800 40 0 Micro 900 60 60 - scenario macro 1800 > micro 900 > macro 900: Cell CELL_RESELECT_OFFSE TEMPORARY_OFFSE T T Macro 900 0 0 Macro 1800 60 0 Micro 900 30 60 CELL_RESELECT_PARAM_IND has been set to 1 for each cell. Moreover, the following values of RXLEV_ACCESS_MIN have been used: - -110 dBm for macro 900 cells, - -99 dBm for macro 1800 cells - -97 dBm for the micro 900 cell. These values were dedicated to the case of the experimental network of Toulouse (same PLMN than the Olla 1800 MHz commercial network) to ease MS reselection. 4.3.4 Connected mode algorithms parameters 4.3.4.1 Call set-up
PENALTY_TIM E 20 20 20
PENALTY_TIM E 20 20 20
Parameters description For remind, Directed Retry may be performed: - either on handover alarms: if a handover alarm is detected during queuing then the BSS will perform a Directed Retry. - or on Forced Directed Retry alarm: if during queuing, a neighbour cell is reported with a sufficient level and has a sufficient number of free TCH, then the BSS will perform a Forced Directed Retry. Directed Retry may be disabled on a per cell basis with the parameter EN_DR. Forced Directed EN_DR Retry may be disabled on a per cell basis with the parameter EN_FORCED_DR, which is EN_FORCED_DR relevant only if EN_DR = ENABLE.
File FTMDUALB.DOC
Edition 1.0
Page 32
Test Report
Directed Retry All handover alarms are available, except causes 10, 11 and 13 (concentric cells) and causes 15 and 16 (intracell HO). For instance, a Directed Retry on cause 4 is possible in case of bad downlink quality. The candidate cell evaluation process is the one described for TCHTCH handovers. Forced Directed Retry If during queuing, a neighbour cell is reported with a sufficient level, cause 20 is triggered: AV_RXLEV_NCELL_DR(n) > L_RXLEV_NCELL_DR(n) and EN_FORCED_DR = ENABLE. Remarks: - cause 20 has the lowest priority of all handover causes but is triggered before other better condition handover causes as it applies a shorter averaging window size (A_PBGT_DR) than other better condition handover causes. - if less than A_PBGT_DR samples are available, AV_RXLEV_NCELL_DR(n) is calculated with the available samples and the averaging window is filled in with 0 (- 110 dBm). Thus, if a neighbour cell is received with a very good level, cause 20 could be triggered before the availability of A_PBGT_DR samples. The candidate cell evaluation process is the one described for TCHTCH handovers: PREF_LAYER, PRIORITY(0,n) and frequency. There are only two differences because the filtering process does not take place and neighbour cells are sorted according to their PBGT_DR(n): - AV_RXLEV_NCELL_DR(n) > RXLEVmin(n) + max(0, MS_TXPWR_MAX(n)-P) - t(n) > FREElevel_DR(n) (with t(n) the absolute number of free TCH in neighbour cell n) - PBGT_DR(n) = AV_RXLEV_NCELL_DR(n) - AV_RXLEV_PBGT_DR - (BS_TXPWR_MAX - BS_TXPWR) - (MS_TXPWR_MAX(n) - MS_TXPWR_MAX) Field trial setting The following scheme describes values used for each of these parameters, applied to 3 network layers. These parameters are common to both scenarios (priority micro or macro 1800).
File FTMDUALB.DOC
Edition 1.0
Page 33
Test Report
EN_DR = ENABLE EN_FORCED_DR = ENABLE L_RXLEV_NCELL_DR(n) = -85 dBm FREElevel_DR(n) = 4 A_PBGT_DR = 4
Cause 20
macro 900 Cell dimension type = macro Cell layer type = upper
EN_DR = ENABLE EN_FORCED_DR = ENABLE L_RXLEV_NCELL_DR(n) = -85 dBm FREElevel_DR(n) = 2 A_PBGT_DR = 4 Cause 20
Cause 20 macro 1800 Cell dimension type = macro Cell layer type = upper
EN_DR = ENABLE EN_FORCED_DR = ENABLE L_RXLEV_NCELL_DR(n) = -85 dBm FREElevel_DR(n) = 8 A_PBGT_DR = 4
micro 900 Cell dimension type = micro Cell layer type = lower
Remark: FREElevel_DR(n) = 8 for the micro 900 cell in order to avoid Forced DR towards this cell for fast mobiles. 4.3.4.2 Better cell and capture handovers
Parameters description Better condition handover causes There are five better condition handover causes: cause 21, cause 14, cause 12, cause 13 and cause 20. Cause 13 is used in a concentric cell and is not described hereafter. Cause 20 (Forced directed Retry) is described in part 4.3.4.1. Each time a measurement result is received, better condition handover causes are checked with the following priority order: cause 21, cause 14, and cause 12. If a handover cause is triggered, handover causes with lower priority are not checked. For example, if cause 21 is triggered, cause 14 is not checked. Cause 21 This cause is used for handovers from cells not working in the preferred band to cells working in the preferred band. The preferred band is indicated on a per BSS basis by the parameter PREFERRED_BAND. PREFERRED_BAND There is a handover alarm when: - the load of the serving cell exceeds a threshold: AV_LOAD(0) > MULTIBAND_LOAD_LEVEL with AV_LOAD(0) the average percentage of non-free TCH (generally over a period of one minute) - a neighbour cell working in the preferred band is received with a level higher than a threshold: AV_RXLEV_NCELL(n) > L_RXLEV_CPT_HO(n) + max(0, MS_TXPWR_MAX(n)-P) with MS_TXPWR_MAX(n) and P powers in the preferred band
Test Report
- cause 21 is not disabled: EN_PREFERRED_BAND_HO = ENABLE. Remarks: - AV_RXLEV_NCELL(n) is calculated with the averaging window A_PBGT_HO. - if less than A_PBGT_HO samples are available, AV_RXLEV_NCELL(n) is calculated with the available samples and the averaging window is filled in with 0 (- 110 dBm). Thus, if a neighbour cell working in the preferred band is received with a very good level, cause 21 could be triggered before the availability of A_PBGT_HO samples. - the load of the serving cell is calculated independently. AV_LOAD(0) is calculated every D_BRO_TIM*LOAD_EV_PERIOD seconds. Imagine the case where AV_LOAD(0) = 0 at the D_BRO_TIM LOAD_EV_PERIOD beginning of the call on the non-preferred band cell and MULTIBAND_LOAD_LEVEL = 0%. It is necessary to wait up to D_BRO_TIM*LOAD_EV_PERIOD seconds in order to have a new value of AV_LOAD(0) and to fulfil the condition AV_LOAD(0) > MULTIBAND_LOAD_LEVEL. Cause 14 This cause is used in a hierarchical network to go from a cell of the upper layer to a cell of a lower layer. It is thus possible to go from an umbrella cell (CELL_DIMENSION_TYPE = macro, CELL_LAYER_TYPE = upper) to a micro cell (CELL_DIMENSION_TYPE = micro, CELL_LAYER_TYPE = lower) or a mini cell (CELL_DIMENSION_TYPE = macro, CELL_LAYER_TYPE = lower). There is a handover alarm when: - a neighbour cell of a lower layer is received with a level higher than a threshold: AV_RXLEV_NCELL(n) > L_RXLEV_CPT_HO(n) - the mobile is a slow mobile: MS_SPEED = slow - cause 14 is not disabled: EN_MCHO_NCELL = ENABLE. Remarks: - AV_RXLEV_NCELL(n) is calculated with the averaging window A_PBGT_HO. - if less than A_PBGT_HO samples are available, AV_RXLEV_NCELL(n) is calculated with the available samples and the averaging window is filled in with 0 (- 110 dBm). Thus, if a lower layer neighbour cell is received with a very good level, the condition AV_RXLEV_NCELL(n) > L_RXLEV_CPT_HO(n) could be verified before the availability of A_PBGT_HO samples. - the speed of a mobile is determined independently by the MS speed discrimination process (see below). MS speed discrimination: For each call on the upper layer and for each neighbour lower layer cell n, a counter C_DWELL(n) measures the number of SACCH periods of monitoring the neighbour cell n over a threshold L_RXLEV_CPT_HO(n). Each time cell n is monitored C_DWELL(n) is compared to the threshold (variable according to the load of the serving umbrella cell) 2*MIN_DWELL_TIME in order to determine MS speed. If for one neighbour lower layer cell n C_DWELL(n) >= 2*MIN_DWELL_TIME then MS_SPEED is set to slow. If EN_SPEED_DISC = DISABLE, C_DWELL(n) is initialized with the value 2*(MIN_DWELL_TIME L_MIN_DWELL_TIME). In this case, there is no regulation according to the load of the serving L_MIN_DWELL_TIME umbrella cell. Thus if 2*L_MIN_DWELL_TIME consecutive samples of the received level from a lower layer neighbour cell are higher than L_RXLEV_CPT_HO(n) MS_SPEED is set to slow.
File FTMDUALB.DOC
Edition 1.0
Page 35
Test Report
Cause 12 It is the classical Power Budget cause only possible between cells belonging to the same layer and working in the same band. There is a handover alarm when: - the power budget between the serving cell and a neighbour cell exceeds a threshold: PBGT(n) > HO_MARGIN(0,n) - cause 12 is not disabled: EN_PBGT_HO = ENABLE. PBGT(n) = AV_RXLEV_NCELL(n) - AV_RXLEV_PBGT_HO - (BS_TXPWR_MAX - BS_TXPWR) - (MS_TXPWR_MAX(n) - MS_TXPWR_MAX) - PING_PONG_MARGIN(n, call_ref) Anti ping-pong mechanism: PING_PONG_MARGIN(n, call_ref) is a penalty put on the neighbour cell n if: - it is the immediately precedent cell on which the call has been - this cell belongs to the same BSC as the serving cell - the call has not performed a Forced Directed Retry towards the serving cell - less than T_HCP seconds have elapsed since the last handover. In this case PING_PONG_MARGIN(n, call_ref) = PING_PONG_HCP otherwise PING_PONG_MARGIN(n, call_ref) = 0. Remark: this penalty is also used in the formula of PBGT(n) in the filtering process (see below) and the ORDER or GRADE evaluation processes. Remarks: - AV_RXLEV_NCELL(n) and AV_RXLEV_PBGT_HO are calculated with the averaging window A_PBGT_HO - cause 12 is not triggered before the availability of A_PBGT_HO samples. Field trial setting The following schemes describes values used for each of these parameters, applied to 3 network layers.
File FTMDUALB.DOC
Edition 1.0
Page 36
Test Report
- Scenario micro 900 > macro 1800 > macro 900:

Cause 12 MULTIBAND_LOAD_LEVEL = 0% EN_SPEED_DISC = DISABLE A_PBGT_HO = 12
HO_MARGIN(0,n) = 5 dB
macro 900 Cell dimension type = macro Cell layer type = upper
Cause 21 Cause 12 L_RXLEV_CPT_HO(n) = -85 dBm EN_SPEED_DISC = DISABLE A_PBGT_HO = 10
HO_MARGIN(0,n) = 5 dB macro 1800 Cell dimension type = macro Cell layer type = upper
Cause 14 L_RXLEV_CPT_HO(n) = -85 dBm EN_SPEED_DISC = DISABLE A_PBGT_HO = 6
BSS parameters : PREFERRED_BAND = 1800 D_BRO_TIM = 5s LOAD_EV_PERIOD = 12 samples L_MIN_DWELL_TIME = 8s
- Scenario macro 1800 > micro 900 > macro 900:

Cause 12
MULTIBAND_LOAD_LEVEL = 0% EN_SPEED_DISC = DISABLE A_PBGT_HO = 12 HO_MARGIN(0,n) = 5 dB Cause 21 Cause 12 L_RXLEV_CPT_HO(n) = -85 dBm A_PBGT_HO = 10 HO_MARGIN(0,n) = 5 dB Cause 14 MULTIBAND_LOAD_LEVEL = 0% L_RXLEV_CPT_HO(n) = -85 dBm A_PBGT_HO = 6 Cause 21 macro 1800 Cell dimension type = macro Cell layer type = upper macro 900 Cell dimension type = macro Cell layer type = upper
BSS parameters : PREFERRED_BAND = 1800 D_BRO_TIM = 5s LOAD_EV_PERIOD = 12 samples L_MIN_DWELL_TIME = 10s
File FTMDUALB.DOC
Edition 1.0
Page 37
Test Report
4.3.4.3
Emergency handovers causes
Parameters description There are 12 emergency handover causes: - cause 7 consecutive bad SACCH frames (micro cells only) - causes 17 and 18 level UL/DL high threshold (micro cells only) - causes 2 and 4 quality UL/DL - causes 3 and 5 level UL/DL - cause 6 distance - causes 10 and 11 inner zone level UL/DL (concentric cells only) - causes 15 and 16 intracell UL/DL Emergency handover causes are checked before better condition handover causes and with the following priority order: 7, 17, 18, 2, 4, 3, 5, 6, 10, 11, 15 and 16. Following averaging windows are used: - causes 2, 3, 4 and 5 A_LEV_HO and A_QUAL_HO - cause 6 A_RANGE_HO - causes 17 and 18 A_LEV_MCHO An emergency handover cause is not triggered before the averaging window size is not filled in. Field trial setting For REX2 network, only causes 7, 17, 18, 2, 4, 3, 5 and 6 were used. This table contains values of thresholds to be used for the field trial:
Cell L_RXLEV_DL_H L_RXLEV_UL_H L_RXQUAL_DL_H L_RXQUAL_UL_H A_LEV_HO A_QUAL_HO
Macro 900 Macro 1800 Micro 900 4.3.4.4
- 95 dBm - 95 dBm - 95 dBm
- 98 dBm - 98 dBm - 98 dBm
3 3 3
3 3 3
8 6 4
8 6 4
Candidate cell evaluation process
Parameters description The handover detection process gives to the HO candidate cell evaluation process the following information: - the handover cause value, - the preferred layer for the target cell indicated by the variable PREF_LAYER, - the list of potential candidates. List of candidates In a non hierarchical network (= only one layer), this list contains: - all neighbour cells in case of emergency alarm, - the neighbour cells that verify the cause in case of better condition alarm. In a hierarchical network, this list contains: - all neighbour cells in case of emergency alarm,
File FTMDUALB.DOC
Edition 1.0
Page 38
Test Report
- the neighbour cells that verify the cause in case of better condition alarm. If the serving CELL_LAYER_TYPE = lower, the handover cause = 12 and MS_SPEED = fast, the list must also contain the whole set of internal neighbour umbrella cells which averaged load AV_LOAD(n) < L_LOAD_OBJ(n). Preferred layer In a non hierarchical network: - PREF_LAYER = upper+single. In a hierarchical network: - in case of emergency alarm, PREF_LAYER is: upper if CELL_LAYER_TYPE = lower and EN_RESCUE_UM = ENABLE (used generally for micro cells), lower if CELL_LAYER_TYPE = lower and EN_RESCUE_UM = DISABLE (used generally for mini cells), none if CELL_LAYER_TYPE = lower and EN_RESCUE_UM = INDEFINITE, upper + single if CELL_LAYER_TYPE = upper. - in case of better condition alarm, PREF_LAYER is: upper if the serving CELL_LAYER_TYPE = lower, the handover cause = 12 and MS_SPEED = fast, none otherwise. Ordering of candidate cells The ordering of candidate cells (from the highest priority to the lowest one) is performed according to the following scheme: Layer Preferred Preferred Preferred Preferred non-preferred non-preferred non-preferred non-preferred PRIORITY(0,n) lowest * lowest * next lowest * next lowest * lowest * lowest * next lowest * next lowest * Frequency band same than the serving cell different from the serving band same than the serving cell different from the serving band same than the serving cell different from the serving band same than the serving cell different from the serving band Cell ev. process ORDER or GRADE cell frequency ORDER or GRADE ORDER or GRADE cell frequency ORDER or GRADE ORDER or GRADE cell frequency ORDER or GRADE ORDER or GRADE cell frequency ORDER or GRADE
1 2 3 4 5 6 7 8
(*): the priority of each neighbour cell n is defined by the parameter PRIORITY(0,n). This PRIORITY(0,n) parameter is on line changeable from the OMC-R. There are four values: 0 = highest priority, 3 = lowest priority. Candidate cells are sorted from the lowest value (= highest priority) to the highest value (= lowest priority). Thanks to this parameter, it is possible to modify the standard priority order (which takes into account the frequency band of the serving cell) between candidate cells.
File FTMDUALB.DOC
Edition 1.0
Page 39
Test Report
A filtering process is possible before the ORDER or GRADE evaluation process. This filtering process can be enabled or disabled on a per cell basis by the flag EN_PBGT_FILTERING (on line changeable from the OMC-R). If EN_PBGT_FILTERING is set to Enable, all neighbour cells n which do not fulfil the following condition are rejected from the list sent to the ORDER or GRADE evaluation process: PBGT(n) > HO_MARGIN_XX(0,n) + Cause_Margin_P_X with HO_MARGIN_XX(0,n) = HO_MARGIN_QUAL(0,n) if cause = 2, 4 or 7 = HO_MARGIN_LEV(0,n) if cause = 3, 5, 6, 17 or 18 = HO_MARGIN(0,n) if cause = 12, 14 or 21 Field trial setting
PRIORITY(0,n) = 0 HO_MARGIN(0,n) = 5 dB HO_MARGIN_LEV(0,n) = 5 dB HO_MARGIN_QUAL(0,n) = 5 dB EN_PBGT_FILTERING = ENABLE CELL_EV = GRADE RXLEV_min(n) = -100 dBm PRIORITY(0,n) = 1 HO_MARGIN(0,n) = 5 dB HO_MARGIN_LEV(0,n) = 5 dB HO_MARGIN_QUAL(0,n) = 5 dB PRIORITY(0,n) = 0 HO_MARGIN(0,n) = -127 dB HO_MARGIN_LEV(0,n) = -127 dB HO_MARGIN_QUAL(0,n) = -127 dB macro 900 Cell dimension type = macro Cell layer type = upper
EN_PBGT_FILTERING = ENABLE CELL_EV = GRADE RXLEV_min(n) = -100 dBm PRIORITY(0,n) = 0 HO_MARGIN(0,n) = 5 dB HO_MARGIN_LEV(0,n) = 5 dB HO_MARGIN_QUAL(0,n) = 5 dB
macro 1800 Cell dimension type = macro Cell layer type = upper PRIORITY(0,n) = 0 HO_MARGIN(0,n) = 5 dB HO_MARGIN_LEV(0,n) = 5 dB HO_MARGIN_QUAL(0,n) = 5 dB
EN_RESCUE_UM = ENABLE EN_PBGT_FILTERING = DISABLE CELL_EV = ORDER RXLEV_min(n) = -100 dBm
Remarks: - PRIORITY(0,n) = 0 between the micro 900 cell and all macro 1800 neighbour cells, = 1 between the micro 900 cell and all macro 900 neighbour cells. This was a requirement of France Telecom Mobiles in order to give a higher priority to macro 1800 cells in case of Forced DR and emergency alarm. - EN_PBGT_FILTERING = disable for the micro 900 cell because neighbour cells of a micro cell must not be filtered. - the values of HO_MARGIN(0,n), HO_MARGIN_LEV(0,n), HO_MARGIN_QUAL(0,n) were chosen with FTM with the following idea: filtering of neighbour cells belonging to the same layer (macro 900/1800 cells for a macro 900/1800 cell) and to a "lower" layer (macro 1800 and micro 900 cells for a macro 900 cell; micro 900 cell for a macro 1800 cell) and no filtering of neighbour cells belonging to a "upper" layer (macro 900 cells for a macro 1800 cell).
File FTMDUALB.DOC
Edition 1.0
Page 40
Test Report
4.4 PARAMETERS SUMMARY

4.4.1 Scenario independent
Parameter EN_INTERBAND_NEIGH MULTIBAND_REPORTING BSS_SEND_CM_ENQUIRY EN_SEND_CM3 STRIP_O5_CM2 Typ e BSS cell BSS BSS BSS Usage enables/disables sending of SI 2bis/2ter and SI 5bis/5ter reporting of neighbour cells BSC sending of CM_ENQUIRY CM3 forwarding to NSS Strip octet 5 of CM2 before sending to MSC selection enables/disables sending of C2 parameters C2 parameter C2 parameter C2 parameter enables/disables Directed Retry enables/disables Forced Directed Retry Forced DR parameter Forced DR parameter enables/disables cause 14 enables/disables cause 21 capture threshold of causes 14 and 21 parameter of speed discrimination process parameter of speed discrimination process traffic load threshold of cause 21 indication of preferred band for cause 21 choice of preferred layer in case of emergency alarm Enables/disables PBGT filtering Field trial setting ENABLE 3 1 1 0
CELL_BAR_QUALIFY CELL_RESELECT_PARAM_IN D CELL_RESELECT_OFFSET TEMPORARY_OFFSET PENALTY_TIME EN_DR EN_FORCED_DR L_RXLEV_NCELL_DR(n) FREElevel_DR(n) EN_MCHO_NCELL EN_PREFERRED_BAND_HO L_RXLEV_CPT_HO(n) L_MIN_DWELL_TIME EN_SPEED_DISC MULTIBAND_LOAD_LEVEL PREFERRED_BAND
cell cell cell cell cell cell cell cell cell cell cell cell BSS cell cell BSS
NOT USABLE IN REX2 1 Scenario dependent Scenario dependent Scenario dependent Scenario dependent Scenario dependent Scenario dependent Scenario dependent Scenario dependent Scenario dependent Scenario dependent 8 or 10 s Scenario dependent Scenario dependent 1800
EN_RESCUE_UM EN_PBGT_FILTERING
cell cell
Scenario dependent Scenario dependent
File FTMDUALB.DOC
Edition 1.0
Page 41
Test Report
4.4.2
Scenario dependent
900 > macro 1800 > macro 900 0 / 40 / 60 0 / 0 / 60 20 / 20 / 20 E / E /E E/E/E - 85 dBm / - 85 dBm / - 85 dBm 4/2/8 E/E/D E/D/D NA / - 85 dBm / - 85 dBm D/D/D 0 % / NA / NA NA / NA / E E/E/D macro 1800 > 900 > macro 900 0 / 60 / 30 0 / 0 / 60 20 / 20 / 20 E/E/E E/E/E - 85 dBm / - 85 dBm / - 85 dBm 4/2/8 E/D/D E/D/E NA / - 85 dBm / - 85 dBm D/D/D 0 % / NA / 0 % NA / NA / E E/E/D
M 900 / M 1800 / 900 CELL_RESELECT_OFFSET TEMPORARY_OFFSET PENALTY_TIME EN_DR EN_FORCED_DR L_RXLEV_NCELL_DR(n) FREElevel_DR(n) EN_MCHO_NCELL EN_PREFERRED_BAND_HO L_RXLEV_CPT_HO(n) EN_SPEED_DISC MULTIBAND_LOAD_LEVEL EN_RESCUE_UM EN_PBGT_FILTERING
This table demonstrates easiness to move from one scenario to the other. Indeed, only parameters values with bold font need to be changed (5 parameters).
4.5 INPUTS FOR FINE TUNING

This section provides first inputs for dual band network tuning. It contains: - parameters that may be tuned in a dual band network, - impact of such a tuning on network management. 4.5.1 Idle mode 4.5.1.1 Selection
In the case of a commercial network, if cells are not barred, it is recommended to use the parameter CELL_BAR_QUALIFY in order to give a higher priority for selection to 1800 MHz cells for example. 4.5.1.2 Re-selection
CELL_RESELECT_OFFSET and TEMPORARY_OFFSET (in dB) must be tuned according to the received signal level from the cells of the different layers (macro 900, macro 1800, micro 900, ...). Remarks: - if 900 cells and 1800 cells are co-located, it is necessary to take into account the difference of propagation losses between 900 MHz and 1800 MHz (10-12 dB). - it is necessary to take into account the value of RXLEV_ACCESS_MIN if this parameter is not the same for all the cells.
File FTMDUALB.DOC
Edition 1.0
Page 42
Test Report
Moreover, proper balance must be ensured between reselection and handover parameters, in order to avoid unexpected emergency handovers, once call is initiated. Typical settings to take care are : - Difference between the value of RXLEV_ACCESS_MIN (-99 dBm for M1800) and L_RXLEV_DL_H (-95 dBm for M1800). MS connected to a macro 1800 cell in idle mode in extreme conditions will trigger a handover alarm at the beginning of the call. - Difference between the value of CELL_RESELECT_OFFSET for M900 (0 dB -> C2 = C1) and M1800 (60 dB -> C2 = C1 + 60) cells. Example is the case where RXLEV = -80 dBm for M900 and -94 dBm for M1800. With such values, C1 >0 for both cells and C2(M1800) > C2(M900). A MS will re-select the macro 1800 cell and a handover alarm will certainly be triggered quickly. While it would have been better to re-select on GSM900 cell. Thus, it is necessary to take care of the values of C2 parameters in order to reduce handover alarms on level. 4.5.2 Connected mode 4.5.2.1 Call set-up
If Forced Directed Retry is used, it is necessary to tune the parameter L_RXLEV_NCELL_DR(n) which is a capture threshold. If this threshold is too low, cause 20 is triggered more easily but a problem of quality is possible in the target cell. In order to give a higher priority to a given layer, it is possible to tune this parameter but it is better to use the parameter PRIORITY(0,n). Example: imagine the case of a mobile connected to a micro 900 cell. If cause 20 is triggered by a macro 900 neighbour cell and a macro 1800 neighbour cell, using the parameter PRIORITY(0,n) it makes possible sending the mobile to the macro 1800 cell. 4.5.2.2 Better cell and capture handovers
MULTIBAND_LOAD_LEVEL: It may be useful to use this parameter (traffic load threshold used in cause 21 and corresponding to the average percentage of non-free TCH in the cell) in order to trigger cause 21 only when the 900 MHz (we assume that PREFERRED_BAND = 1800) cell has a high traffic load. Using a value different from 0% leads to a decreased number of handovers and thus to an improved quality of service. Remark: obviously, if a value different from 0% is used, the path for dual band mobiles is completely modified. For example, with the scenario micro 900 > macro 1800 > macro 900, a dual band mobile connected to a macro 900 cell will go directly to the micro 900 cell whereas two handovers are necessary to reach the micro 900 cell with MULTIBAND_LOAD_LEVEL = 0 %. L_RXLEV_CPT_HO(n): It is also necessary to tune the capture threshold L_RXLEV_CPT_HO(n) used in causes 14 and 21 in order to avoid ping-pong handovers because of quality problems in the target cell (macro 1800 cell or micro 900 cell for example). 4.5.2.3 Candidate cell evaluation process very useful in a dual band network: PRIORITY(0,n) and
Two parameters are HO_MARGIN_LEV(0,n).
File FTMDUALB.DOC
Edition 1.0
Page 43
Test Report
PRIORITY(0,n): This parameter is useful in case of Forced Directed Retry alarm and in case of emergency alarm in order to direct a dual band mobile to the desired layer. This parameter is very easy to use (only four values: 0, 1, 2 and 3) and is set on a per couple of cells basis. HO_MARGIN_LEV(0,n): This parameter is very useful in order to manage the exit of a 1800 MHz zone on preventive handover. The principle is to anticipate the 1800 MHz zone exit by triggering earlier an emergency alarm on level and executing this handover only towards specific 900 MHz neighbour cells. The early triggering of the emergency alarm on level is possible by tuning the threshold L_RXLEV_DL_H (or L_RXLEV_UL_H) to a stronger value so as to anticipate the need of handover. 10 dB above the normal value of this threshold should be sufficient to provide a good anticipation. The execution of such anticipated handover towards specific 900 MHz neighbour cells is provided by the PBGT filtering (allowed by the flag EN_PBGT_FILTERING) applied to the candidate cells for handover. This filtering consists in (in case of emergency alarm on level): PBGT(0,n) > HO_MARGIN_LEV(0,n) + Cause_Margin_P_x where x is the cause number, x = 3 or 5 for emergency handover on level. This condition can prevent from executing the anticipated handover towards some neighbour cells. As the handover will be detected earlier in the cell, the filtering must be more restricting than usual to ensure the same handover limit. It is proposed to consider in this case, the handover limit related to power budget handover. It thus consists in tuning HO_MARGIN_LEV(0,n) between the serving 1800 MHz cell on the zone frontier and its 1800 MHz neighbour cells in the following way: HO_MARGIN_LEV(0,n) + Cause_Margin_P_x = HO_MARGIN(0,n) = 5 dB (default value) Considering Cause_Margin_P_x = - 3 dB, this gives HO_MARGIN_LEV(0,n) = 8 dB On the contrary, while tuning HO_MARGIN_LEV(0,n) with a less restricting value towards specific 900 MHz neighbour cells, it allows to trigger earlier handover towards these cells and thus, to ensure a safe zone exit. This requires to modify the default value of HO_MARGIN_LEV(0,n) between 1800 MHz cells and 900 MHz cells (the default value is -127 dB so as to inhibit the filtering in this case). In the context of zone exit, the following values could be used: HO_MARGIN_LEV(0,n) = 20 dB (providing Cause_Margin_P_x = - 3 dB) towards 900 MHz cells which are not involved in the zone exit. This value of 20 dB takes into account the difference of level (12 dB) between 900 and 1800 bands. HO_MARGIN_LEV(0,n) = X dB (providing Cause_Margin_P_x = - 3 dB) towards 900 MHz cells which are involved in the zone exit.
File FTMDUALB.DOC
Edition 1.0
Page 44
Test Report
X should be tuned so as to set the border of the 1800 MHz zone. X = -127 dB is the default value and it means that this border is fixed by the triggering of the handover alarm and so by the threshold L_RXLEV_DL_H (or L_RXLEV_UL_H).
File FTMDUALB.DOC
Edition 1.0
Page 45
Test Report
5 TEST AND MONITORING TOOLS

5.1 CONTENT
This volume describes the tools used on the field to test and monitor dual band network. It covers the following aspects for each tool: - Sum-up of features which have been implemented for this field trial, - Actual usage of these features problems encountered, - List of indicators used to monitor dual band traffic and quality of service issues, - Proposals for improvements in tools and methods.
5.2 COMMERCIAL MS
5.2.1 Motorola 8900 During the week before and the 3 weeks of experimentation, France Telecom did supply Alcatel with ten Dual Band Motorola 8900 with trace facility. 5.2.1.1 Trace facility
This MS contains interesting trace facilities, which provides mainly: - In idle mode: level of serving and neighbour cells, current values of C1 (selection) and C2 (reselection) and system information parameters. - In dedicated mode: level and quality of serving cell, level of neighbour cells and system information parameters (as MULTIBAND REPORTING). This mobile has been very helpful during field trial to make real time monitoring and to know serving cell frequency and current RX level. It was mainly used during pedestrian routes: - To check access to experimental network (PLMN was shared with Olla commercial network) - To monitor C1 and C2 and check reselection mechanism, - To follow connected mode and especially handovers (capture and emergency). This trace facility is unfortunately not available with commercial mobiles. Motorola who also did a field trial with FTM supplied them with it. This facility is nevertheless quite limited because of MS HMI. It is not possible to follow simultaneously several cells in real time (typically serving and neighbour cells). Move in menus is necessary to get this information. 5.2.1.2 MS reliability
This mobile seems to be currently the most reliable dual band MS. First of all, it was able to handle properly cell test mode used on experimental network. Concerning reselection, a problem has been detected with this mobile. It does not support TEMPORARY_OFFSET with infinite value. Set of parameters has been changed accordingly. Note that this mobile does not support EFR that was also used in Toulouse.
File FTMDUALB.DOC
Edition 1.0
Page 46
Test Report
5.2.2
Other mobiles 5.2.2.1 Dual Band MS
In addition to TEMS and Motorola 8900, some other mobiles were used during field trial: - BOSCH Dual Com 738, - A Mitsubishi prototype. Since they have no trace facility, they were only used to check their proper interworking with BSS, and for BOSCH to check BSS EFR capability. Problems to access the network (cell test mode) have been encountered with these mobiles. They could only access in the following conditions: - BOSCH: Access class 15 debarred. It has been observed that when 900 layer was debarred (cell + AC 15) and 1800 cells were barred (cell + AC 15), MS was able to access 900 cells and make a handover to 1800 cells, but was not able to recover the 1800 cells after call release (switch off/on needed). - Mitsubishi: Each time cell bar access and AC15 were in opposite states (barred/debarred). These problems did prevent from using these MS in normal test conditions. Nevertheless, if we except this problem linked to Toulouse network configuration, their compatibility with Alcatel BSS dual band could be demonstrated. 5.2.2.2 Single Band MS
Single band mobiles has been used to: - generate single band MS traffic during statistic tests - make specific BSS / MS interworking tests. Statistic tests Phase 2 single 900 band mobiles from SIEMENS were used. They also did not support Access Class 15 barring. It did not prevent from performing statistic tests, as 900 layer could be completely debarred. Interworking tests Dual band implementation has been modified in GSM recommendations because of Phase 1 mobile incompatibilities: modification of SYSTEM INFORMATION xter (L2 PSEUDO LENGTH set to 0). Some tests have been made with Alcatel BSS that does implement these changes. Tested mobiles were a MITSUBISHI MS, and HC 600 and HC 800 from Alcatel. Test has been OK for all MS, except HC 600. Unfortunately, we could not go further in investigations.
5.3 TRACE MOBILES

5.3.1 Current solutions 5.3.1.1 Surveyor
Surveyor (supplied by FOREM) is a trace mobile, supporting Motorola GSM900, GSM1800 and dual band MS (8900) stations. Alcatel has supplied it during field trial period.
File FTMDUALB.DOC
Edition 1.0
Page 47
Test Report
This trace mobile has only been used with a dual band MS (8900). It was a good complement to Motorola 8900 trace application. Indeed, real time monitoring of serving cell and neighbour cells was possible in connected mode. Its main usage has therefore been for real-time parameters tuning and BSS test, rather than usual usage of such application. Indeed, no postprocessing has been made. This limited usage was due to several problems: - Frequent loss of GPS (and recording), which did prevent to associate measurements and map, - No possible usage of markers for indoor routes, - Software problems in idle mode prevent from getting neighbour cells measurements. Nevertheless, Surveyor is the only commercial solution at the moment with dual band capacity. Once these problems are corrected, it shall be a really helpful tool. 5.3.1.2 A954
A954 is an Alcatel trace mobile application, supporting GSM900 and GSM1800 SAGEM MS stations. As no dual band solution was available, it was initially foreseen to use it to make coverage map of 900 and 1800 layers. But access to experimental network could not be possible with cell test mode (SIM card and BSS configuration), even by debarring access class 15. Complete cell debarring was also needed. Consequently, coverage maps could only be done on 900 layer (debarring allowed). 5.3.1.3 TEMS
This was the trace mobile used by FTM. Ericsson (who will also make a field trial during summer 98) supplied a prototype of dual band version (also supporting EFR). TEMS is a test mobile (one MS directly connected to a PC). Its main functions are: - Monitor neighbour and serving cells (frequency, downlink radio measurements), - Monitor layer 2 or layer 3 signaling protocols, - Test facilities like uplink messages modifications (protocol or radio measurements). This MS has been the reference tool used by FTM for both: - Deterministic tests: thanks to a detailed analysis of all protocol messages and radio measurements. - Statistic tests: thanks to a post-processing application written by FTM (Evaluator). A few problems were detected on this TEMS version: - High rate of reversion to old channel (up to 50%!): it was detected by FTM during previous field trial with Motorola. It can be observed in QoS results of statistic tests. - Impossibility to access the network when cell was barred and AC 15 debarred. It did prevent from usage of mobiles that needed such a configuration to access the network.
File FTMDUALB.DOC
Edition 1.0
Page 48
Test Report
5.3.2
Possible improvements First of all, Alcatel should be able to supply with a dual band trace mobile application in the future, either based on SAGEM (current 1954 solution) or BOSCH or Alcatel MS. Implementation is foreseen by end of 1998 in A954, once dual band SAGEM mobile is available. As an intermediate solution, Surveyor has been purchased. It will be used in next field trials (China). Nevertheless, this experience allowed us to define some interesting features to be implemented in such an application. They are described below. Equipment First necessity is to get multi-mobile application, in order to follow both single and dual band on the same route. Typical configuration would be a single band 900 MS, a single band 1800 MS and a dual band MS. Moreover, discrimination between Phase 1 and Phase 2 MS is also an interesting issue in idle mode, because second one is able to handle reselection.
Real-time monitoring A major issue of field trial was efficiency of reselection mechanisms. A trace mobile application should provide real time monitoring of C1 and C2 parameters. Phase 1 mobile will reselect on better C1, while Phase 2 mobiles will select on better C2. Typical implementation would be to monitor the 6 better C1 and the 6 better C2. Monitoring SYSTEM INFORMATION parameters is also needed to get reselection parameters in idle mode and MULTIBAND REPORTING in connected mode. Indeed, these parameters are cell dependent and have a great influence on dual band MS behaviour.
Post-processing First list of improvements is production of new maps, introducing reselection effect and heterogeneous set of MS (single band 1800, single band 900, dual band MS, phase 1 and phase 2 MS): - Separate coverage maps (as usually done today in A954) for 1800, 900, 1800+900 layer. - Idle best-server maps for 1800, 900, 1800+900 layers. Such a map would display cell with best C2 parameter (cell the MS is selected on). - Best server maps (as usually done today in A954) for 1800, 900, 1800+900 layers. Such a map displays the cell the MS is established on (serving cell). - Best RXLEV maps for 1800, 900, 1800+900 layers. Such a map would display cell with best RXLEV, even if it is not the serving one. Difference with previous one highlights impact of BSC radio algorithms. Two possibilities exist to produce separate maps on the same route: - Multi-mobile application availability which is of course the best one in medium term, - In a short term, taking into account best cell of concerned layer in cells list, even if not the serving one. Second set of features is related to dual band only:
File FTMDUALB.DOC
Edition 1.0
Page 49
Test Report
Comparison of RXLEV measurement on 900 and 1800 cells managed by same site. Each time both cells are received, a map displays difference between 1800 and 900 signals. It implies to process cases where one cell is serving and the other neighbour, and cases where both cells are neighbours. In addition to this map, an array with all sites with averaged difference and standard deviation could be produced. Map giving indication of frequency band used for call and available neighbour frequency bands. 6 cases can be displayed: call on 900 and only 900 cells reported, call on 900 and only 1800 reported, call on 900 and both bands reported, the same for 1800. Such a map would be helpful to highlight mate frequency band monitoring problems (by correlation with signalling), and also MULTIBAND_REPORTING parameter appropriate setting.
Test features TEMS had a real added value during field trial, thanks to its test features. Interesting features are radio measurements modification (to trigger handovers for example), or protocol messages patches (to trigger specific protocol cases). It should be taken into account when specifying new trace MS applications.
5.4 ABIS INTERFACE

5.4.1.1 New features
FTM required RXLEV and RXQUAL statistics. Since this feature is not available at OMC-R (radio measurement statistics forecast in B6/B7), post-processing of Abis interface traces with DAFNE tool is the only way to get these results. DAFNE takes as input K1103 traces and produces expected level and quality statistics (average and distribution) per cell and per TRX, in uplink and downlink directions. DAFNE has been adapted to support dual band, i.e. manage GSM 1800 frequencies. Extra features have been developed: Call Trace and interfacing with IMSI trace interfacing. Even if it was foreseen to develop it (due to FTM request), discrimination of results per mobile type is not available. It is quite impossible to develop it, as it would require DAFNE to work on a call basis, while it works on channel basis. When a TCH channel is activated, no information is providing giving the MS type (single or dual band). However, DAFNE is able to trace mobile by IMSI, called number or TMSI and to compute statistics over these measurements. 5.4.1.2 Usage
DAFNE usage has been really reduced for the following reasons: - FTM was rather interested by statistics per mobile type (to detect possible differences between MS behaviors), which was not available. - Taking Abis traces and post-processing is very heavy and must be used with a reduced scope. It is not adapted to produce statistics on a complete network. Nevertheless, RXLEV and RXQUAL distribution and average could be produced and highlight propagation differences between 900 and 1800, and also quality problems seen on the network. Other features that have been implemented have not been used in Toulouse:
File FTMDUALB.DOC
Edition 1.0
Page 50
Test Report
Call trace support: It would have been helpful to make investigations in case of radio or protocol problem. It has not been used in Toulouse because of systematic usage of TEMS by FTM for protocol analysis, and no radio investigation need (purpose of field trial was not radio optimisation). Interfacing with IMSI trace: Because of problems observed on IMSI trace (see section 5.7), this feature has not been used as well. Indicators
5.4.1.3
RXLEV distribution Computation method DAFNE sorts RXLEV values received in MEASUREMENT RESULTS messages for uplink and downlink path of a given TRX. For each RXLEV value, number of samples is counted. Statistics They have only been done for Capitole site, which is the most representative in terms of samples. TRXs belonging to 1800 or 900 band have be gathered to provide separate RXLEV distribution. Radio measurements statistics Computation method The following information is computed from MEASUREMENT RESULTS received for each TRX: - Sample: Number of MEASUREMENT RESULTS messages received for concerned TRX. - AV_Lev_UL(DL): RXLEV (FULL or SUB) values for serving cell are averaged. - AV_QUAL_UL(DL): RXQUAL (FULL or SUB) values for serving cell are averaged. - MS(BS)_Pwr: MSTXPWR and BSTXPWR included in MEASUREMENT RESULTS are averaged. - Path loss: The following values are computed: - Uplink path loss: PL_UL = MSPwr - AV_RXLEV_UL - Downlink path loss: PL_DL = BSPwr - AV_RXLEV_DL - Delta path loss: delta_pl = PL_UL - PL_DL - Delta quality: delta_qual = AV_QUAL_UL - AV_QUAL_DL - Quality distribution: The rate of samples of each RXQUAL values are provided. BQ stands for bad quality, which sums values 5, 6 and 7. Statistics All above values are provided for each TRX (cell) belonging to spied site. Please refer to section 6 for presentation and analysis of these results. 5.4.1.4 Possible improvements
Further developments should be foreseen in DAFNE to improve follow-up of dual band network. Main blocking point at the moment is ability to recognise dual band mobiles and cells frequency bands:
File FTMDUALB.DOC
Edition 1.0
Page 51
Test Report
Dual band MS capacity recognition : Dual band capacity is only available at call set-up. For calls which enter in trace area (by handover), there is no mean to know that MS is dual band. A workaround would be to force all handovers in external, and force sending of CLASSMARK ENQUIRY by inhibiting Classmark 3 sending to MSC. But it can only be done as temporary solution, and parameters to set this configuration will be changeable in B6 only! Another possibility would be to consider that a MS is dual band when it reports cells of different bands (see next point). - Frequency bands decoding in BA list : A useful feature would be to decode BCCH frequency in BA list. It cannot be done with protocol and a configuration file (neighbour cells per TRX) is necessary. These two features will be studied in order to extend DAFNE capacities in a dual band network. Once this technical problem is solved, extra features would be helpful: - Production of current DAFNE statistics per mobile type (dual or single band). - Implementation of propagation differences statistics DAFNE has to compute difference between RXLEV of two cells in BA list. It is of course interesting in case of co-site cells. This difference (average, standard variation, distribution) has to be computed each time both cells are contained in same radio measurements (either serving / neighbour or neighbour / neighbour). - Implementation of statistics to help MULTIBAND_REPORTING setting MULTIBAND_REPORTING is a cell dependant parameter, which defines how many cells of different bands have to be reported. Statistics could be produced to give averaged number (+ standard variation) of cells of each band reported in MEASUREMENT RESULTS. An iterative process should be applied to tune value of MULTIBAND_REPORTING parameter.
5.5 A INTERFACE
FTM required quality of service statistics (traffic, handover) per mobile type. Since this feature is not available in OMC-R counters, post-processing of A interface traces with AGLAE tool is the only way to get these results. AGLAE takes as input K1103 traces and main results used during field trial are handover statistics (causes distribution, success rate) and messages statistics for further postprocessing: - agrpt tool dedicated to traffic repartition (TCH seizure time) - Excel post-processing dedicated to reselection statistics. Thanks to extra development made for this field trial, all these statistics can be done for single and dual band mobiles (using classmark information). It is important to notice that such an implementation was not available in FTM tool (CIGALE). 5.5.1.2 Usage
Due to limitations of all other methods, all the interesting statistics are resulting from AGLAE and post-processing tools (agrpt). On FTM request, all handovers were forced to external: it allowed getting more statistics on handover (success rate, congestion).
File FTMDUALB.DOC
Edition 1.0
Page 52
Test Report
Some problems or limitations have been detected in AGLAE: - Directed retry statistics: they were requested by FTM, but could not be produced. Computation method in AGLAE is wrong (problem under investigation). It has not been a major problem, as number of directed retry during statistic tests was unsignificant. - Classmark sort method (to produce statistics per mobile type): in current prototype version, AGLAE is not able to include in statistics the messages that were received before the MS is seen as a dual band mobile. By default they are included in single band mobiles results. Care must therefore be taken to only use statistics computed with messages received after CLASSMARK UPDATE (i.e. once SDCCH assignment). - AGLAE is not able to handle follow-on calls (SDCCH and TCH assignments with same SCCP connection, i.e. CM SERVICE REQUEST not included in SCCP CONNECTION REQUEST) properly. Motorola MS generated few some. This kind of call has low probability of occurrence (low impact on overall results), but it will be implemented in next versions of AGLAE. 5.5.1.3 Indicators
Traffic statistics For remind, traffic statistics are obtained as follows: - AGLAE post processing of K1103 trace file resulting in a list of all messages (.RPT file) - agrpt resulting for a given mobile type in TCH seizures: seizure and release time, serving cell. - Excel post processing to provide specific pie charts, cumulating total TCH seizures (i.e. traffic) duration per layer (micro, macro 1800, macro 900). Computation method TCH seizure duration is computed by subtracting TCH seizure time from TCH release time. A TCH is considered as seized on target cell in the following events (all handovers are external): - ASSIGNMENT COMPLETE for call set-up (originated or terminated) - HANDOVER COMPLETE for incoming external handovers, A TCH is considered as released on target cell in the following events: - CLEAR COMMAND for call release or external handover, These values are only approximations, as real TCH seizure should be counted inside the BSC or on Abis interface. Nevertheless, this computation is pessimistic for TCH seizure (reflects rather MS connection than TCH seizure) and optimistic for TCH release (TCH is already freed once counted message appears). With a significant averaged TCH seizure duration (case on REX2), result is considered as good. A comparison with OMC-R counters, taken on same measurement period, confirmed it. Statistics Mobiles repartition between single and dual band: Single =
REX,SB MS ( TCH seizure duration) / REX,ALL MS ( TCH seizure duration). Dual = REX,DB MS ( TCH seizure duration) / REX,ALL MS ( TCH seizure duration). MICRO, MS TYPE ( TCH seizure duration) / REX, MS TYPE ( TCH seizure duration)
Traffic repartition between various layers for different MS types (all, single band, dual band): Micro =
Test Report
Macro 1800 = duration) Macro 900=
MACRO1800,
MS TYPE
( TCH seizure duration) /
REX,
MS TYP4E
( TCH seizure
MCRO900, MS TYPE ( TCH seizure duration) / REX, MS TYPE ( TCH seizure duration)
Call set-up statistics Call set-up statistics (to get efficiency of reselection) are obtained as follows: - AGLAE post processing of K1103 trace file resulting in counting messages (.CCN file) per mobile type. - Excel post processing to provide specific pie charts, cumulating total call set-up initiations per layer (micro, macro 1800, and macro 900). Computation method To compute call set-up initiation, ASSIGNMENT REQUEST is reference for call set-up initiation, because: - It allows to AGLAE to recognize dual band MS (CLASSMARK UPDATE already sent) - It does not count cell change during directed retry. Statistics Call set-up repartition between various layers for different MS types (all, single band, dual band): Micro =
MICRO, MS TYPE ( Call set-up initiation) / REX, MS TYPE ( Call set-up initiation) Macro 1800 = MACRO1800, MS TYPE ( Call set-up initiation) / REX, MS TYPE ( Call set-up initiation) Macro 900= MCRO900, MS TYPE ( Call set-up initiation) / REX, MS TYPE ( Call set-up initiation)
Handover Statistics These statistics are resulting of handovers statistics produced by AGLAE per mobile type (.CTH file). AGLAE statistics are produced by couples of cells. An Excel post processing allows to produced the same results by couple of layers (micro, macro 1800, and macro 900). Outgoing handovers
Computation method
Handover causes are classified in three categories: emergency, capture, PBGT handovers. These statistics are only based on handover alarms and not actual attempts made by the MS: - Emergency handovers counts HANDOVER REQUIRED messages containing causes: uplink strength, downlink strength, uplink quality, downlink quality. - PBGT handovers counts HANDOVER REQUIRED messages containing cause: better cell when target and serving cells belong to same cell layer (micro, macro 1800, macro 900). - Capture handovers counts HANDOVER REQUIRED messages containing cause: better cell when target and serving cells belong to different cell layers.
Statistics
For each layer and for each MS type (all MS, Dual band MS, Single band MS), an excel table provides repartition (% among all outgoing handovers) of above mentioned handovers causes towards different layers. Since all combinations are not possible, only relevant cases are given.
File FTMDUALB.DOC
Edition 1.0
Page 54
Test Report
Incoming handovers These statistics contain the same results, but seen from a target cell point of view. Emergency causes distribution
Computation method
These statistics are only based on handover alarms: - Emergency handovers counts HANDOVER REQUIRED messages containing causes: uplink strength, downlink strength, uplink quality, downlink quality.
Statistics
For each layer and for each MS type (all MS, Dual band MS, Single band MS), an excel table provides repartition (% among all outgoing emergency handovers) between the 4 usual causes reported on A interface. HO efficiency
Computation method
The following events are counted on A interface: - HO OUTGOING SUCCESS: Reception of CLEAR COMMAND (handover successful) once handover is initiated (HANDOVER COMMAND). - HO OUTGOING FAILURE: Reception of CLEAR REQUEST on serving cell (for example radio interface message failure) once handover is initiated (HANDOVER COMMAND). - FAILURE REVERSION: Reception of HANDOVER FAILURE (reversion to old channel) once handover is initiated (HANDOVER COMMAND).
Statistics
For each layer and for each MS type (all MS, Dual band MS, Single band MS), an excel table provides repartition (% among all initiated handovers) between the 3 possible results (success, failure with reversion and call drop). 5.5.1.4 Possible improvements
If we exclude resolution of current problems (follow-on call, directed retry) that are already foreseen, some improvements can be foreseen in AGLAE, to provide new statistics and decrease extra post-processing with Excel: - Improve filtering by mobile type: current split between single and dual band starts when MS is recognized as dual band. AGLAE should be able to extend these statistics to messages received before. Other improvements in file management are also expected. Both are planned in AGLAE V3. - Include statistics related to time elapsed between two messages. It is also planned for V3 and will avoid usage of agrpt. - Cumulating of statistics per cell type: Important Excel processing had to be done to produce statistics for all macro 900, macro 1800 and micro 900, as only cells or couple of cells are available. This implementation has also been requested for V3 of AGLAE. - Ping-Pong statistics: a mechanism to detect Ping-Pong between cells (i.e. short call duration on target cell before being to ex-serving cell) can be implemented to highlight such a situation. This is not specific to dual band, but some capture-emergency pingpong could be detected with such a method.
File FTMDUALB.DOC
Edition 1.0
Page 55
Test Report
5.6 OMC-R COUNTERS

Quite few new raw counters are available for dual band feature: - C150: counting number of CLASSMARK CHANGE messages with 2 bands supported, - C79, C119: Number of handover alarms cause 21 (resp. on TCH and SDCCH channels). DICO tool has been adapted to support B5 and these new counters. With this implementation, it is impossible to follow separately single and dual band mobiles. This feature is requested by FTM especially because of low dual band MS penetration rate at the beginning. 5.6.1.2 Usage
Activation Counters with types 1 - 6 and 28, and 26 27 (for micro cell) have been activated permanently with one-hour collection period. This was Alcatel recommended method. Nevertheless, FTM (CNET) did also request to be able to get results at any time. To fulfill this requirement, same jobs were activated with 12 hours period (REPORTING PERIOD to 0 in restriction for our B5 version). Results processing Part of data collected has not been processed: - Types 26-27 (couples of cells) counters are not incremented when handover is external. Forcing handover to external (FTM request) was not foreseen in test plan. - Measurements on demand have never been done by FTM. 12 hours period collection was useless. - Type 28 counters were not incremented because SDCCH handover was not activated. Only types 1 to 6 collected with 1-hour period and cumulated by OBSYNT have been processed. Post-processing method DICO usage for post-processing was initially planned. It has not been used for following reasons: - Low and heterogeneous traffic generated on the network: DICO is rather adapted to large networks and brings interesting features like evolutions graphics, top ten cells that were meaningless with field trial test method. - Very few statistics had an added value to those produced by AGLAE. A simple Excel sheet was enough to compute interesting statistics. Nevertheless, this implementation will be useful for B5 introduction and results collected in Toulouse shall be used to validate this DICO version. Results reliability No problem has been detected in counter values. Moreover, traffic statistics (for all MS) could be successfully compared to those computed with AGLAE/agrpt.
File FTMDUALB.DOC
Edition 1.0
Page 56
Test Report
Nevertheless, field trial has shown that computation method of counter C150 (any CLASSMARK CHANGE messages with CM3 with two bands supported) is not adapted to further indicator computation. Its objective is to count dual band MS accesses (and deduce penetration rate = C150/(C01+C02)). It is incremented at any SDCCH seizure with appropriate CM3, including for LOCATION UPDATING. But, it has been observed that in case of periodic updating, SDCCH transaction duration is too short and CLASSMARK CHANGE from MS is not processed. We observed for example, that on 1800 layer where only dual band MS could access, resulting penetration rate was 80% instead of 100%! 5.6.1.3 Indicators
These statistics are computed by using OMC-R counters produced every hour and cumulated every day by OBSYNT tool. An Excel post processing is made to produce statistics per layer (micro, macro 1800, and macro 900). Care must be taken when comparing A interface results and OMC-R results because measurements periods are not the same. Call and TCH drop Input counters C136 C21 C14c C139 C17 C18 Radio link failure or LapDm disconnection detected by BSS BSS timer expiry on serving cell: neither HO FAIL, nor HO COMPLETE (T8) Drop due to BSS internal event (LapD disconnect, operator intervention...) Drop due to TRAU path cut (remote transcoder alarm) TCH channel seizure for handover (HANDOVER COMPLETE) TCH seizure for normal assignment (ASSIGNMENT COMPLETE)
Statistics For each layer, an excel table provides these TCH and call drop statistics: -
layer C136 / layer (C17+C18) TCH Drop handover layer C21 / layer (C17+C18) TCH Drop BSS layer (C14c + c139) / layer (C17+C18) TCH Drop global layer (C14c + C21 + C136 + c139) / layer (C17+C18) Number of TCH per call layer (C17 + C18) / layer (C18)
TCH Drop radio Call drop Number of TCH per call * TCH Drop Global
Traffic repartition Input counters C380a C150 C02a C01 C02d Time elapsed between CHANNEL ACTIVATE and RF CH. REL. ACK (TCH) CLASSMARK CHANGE received with CM3 stating that two bands are supported ESTABLISH INDICATION including LOCATION UPDATING REQUEST message ESTABLISH INDICATION with PAGING RESPONSE ESTABLISH INDICATION with LOCATION UPD. REQUEST and follow-on bit set
File FTMDUALB.DOC
Edition 1.0
Page 57
Test Report
C02h
ESTABLISH INDICATION with CM SERVICE REQ. indicating Mobile Originated Call
Statistics The principle is the same for all these counters. The repartition between layers is provided. TCH seizure DB MS access LU attempt Call attempt DB MS penetration
layer C380a / REX C380a layer C150 / REX C150 layer C02a / REX C02a layer (C01+C02h+C02d) / REX (C01+C02h+C02d) REX C150 / REX C02
HO efficiency Input counters
Incoming inter BSC handovers: C41a C41b C42 C43 C44 HANDOVER FAILURE no radio resource available to NSS. HANDOVER FAILURE due to impossible CIC allocation to NSS. HANDOVER COMPLETE from MS. BSS handover protocol timer expiry on target cell (T3105*Ny1). Internal BSS event (LapD, O&M) aborting current HO
Outgoing inter BSC handovers: C46 C47 C48 C49 C50 CLEAR COMMAND with handover successful from NSS. HANDOVER FAILURE reversion to old channel from MS. BSS timer expiry (T8) meaning neither success, nor reversion received. Internal BSS event (LapD, O&M) aborting current HO. HANDOVER COMMAND to MS
Directed retry: C142 C143 C144 C145 ASSIGNMENT COMPLETE for a forced directed retry. Failure of forced DR once attempted (reversion or BSS timer expiry). ASSIGNMENT COMPLETE for a normal directed retry. Failure of normal DR once attempted (reversion or BSS timer expiry).
Statistics
Incoming inter BSC handovers:
Indicators which are provided are congestion rate based on all handover alarms, and success and failure rates based on all handover attempts (HANDOVER COMMAND sent): Congestion Success Failure radio BSS problem
layer (C41a) / layer (C41a+C41b+C42+C43+C44) layer (C42) / layer (C41b+C42+C43+C44) layer (C43) / layer (C41b+C42+C43+C44) layer (C41b+C44) / layer (C41b+C42+C43+C44)
Test Report
Outgoing inter BSC handovers:
Indicators which are provided are success and failure rates based on all handover attempts (HANDOVER COMMAND sent). Difference with incoming handover is layers repartition. Success Drop Reversion Directed retry:
layer (C46) / layer (C50) layer (C48+C49) / layer (C50) layer (C47) / layer (C50)
Indicators which are provided are repartition between forced and normal successful directed retry and success rate of all directed retry. Forced rate Success
layer (C142) / layer (C142 + C144) layer (C142+C144) / layer (C142+C143+C144+C145)
HO causes distribution Input counters C70 C71 C72 C73 C78 C79 C185a C185d C185e C185f Handover alarm cause uplink quality too low Handover alarm cause uplink level too low Handover alarm cause downlink quality too low Handover alarm cause downlink level too low Handover alarm cause better cell Handover alarm cause preferred band Handover alarm cause consecutive bad SACCH frames Handover alarm cause level UL microcell - high threshold Handover alarm cause level DL microcell - high threshold Handover alarm cause high level in overlaid with slow MS
Statistics All handover causes can be split in emergency causes and PBGT causes: Emergency causes PBGT causes
(C70+C71+C72+C73+C185a+C185d+185e) (C78+C79+C185f)
First set of indicators which are provided are rate of emergency handovers among all handovers and rate of each emergency cause among all emergency handovers. They are computed for each layer. Rate UL Quality DL Quality UL level DL level Rescue micro UL level micro
layer (emergency) / layer (emergency + PBGT) layer (C70) / layer (emergency) layer (C72) / layer (emergency) layer (C71) / layer (emergency) layer (C73) / layer (emergency) layer (185a) / layer (emergency) layer (185d) / layer (emergency)
Test Report
DL level micro
layer (185e) / layer (emergency)
Second set of indicators which are provided are rate of PBGT handovers among all handovers and rate of each PBGT cause among all PBGT handovers. They are computed for each layer. Rate PBGT Capture 21 Capture 14
layer (PBGT) / layer (emergency + PBGT) layer (C78 / layer (PBGT) layer (C79 / layer (PBGT) layer (C185f) / layer (PBGT)
5.6.1.4
Possible improvements
A major issue reported by FTM is that our OMC-R counters are not adapted to follow dual band network, mainly because it does not allow to follow separately dual band MS. Indeed, most of the interesting statistics had to be produced with AGLAE on A interface. Requests For Improvements will be made to technical department related to: - Statistics per mobile type: It is unrealistic to duplicate all PM counters for single and dual band MS. Nevertheless, some specific counters should be added to follow dual band MS traffic and handover (types 5 and 6), traffic being the most important one. - Improvement of C150 counter: as mentioned before, the way it is incremented makes difficult computation of dual band MS penetration rate by comparison to C02. Its scope could be reduced to call establishment phase to get reliable reference or solution has to be found to increment it in any case of SDCCH seizure. - Handover cause by couple of cells: these statistics are really interesting to understand handover problems between two cells. Handover causes statistics are available for outgoing handovers only. A proposal shall be made to include them in type 26 or 27. Moreover, radio measurement statistics which were also requested by FTM, should be introduced as early as possible in the BSS product (B7 today). Split between MS types (also FTM request) seems not realistic.
5.7 CALL TRACE

5.7.1.1 Description
Call trace was requested by FTM as a mean to check accurately protocol and radio algorithms. Two activation means exist: - Call path trace: trigger condition is seizure of a specific TCH channel, - IMSI trace: trigger condition is a message sent by MSC on current SCCP connection. Both features do not fulfil FTM requirements: no radio measurements for IMSI trace, high sampling is applied on radio measurements, and current BSC averages are reported (instead of real reported values). These features have nevertheless been validated to anticipate possible usage by FTM. 5.7.1.2 Usage
MET NSS at least version used in Toulouse - does not send phase 2 message to activate IMSI trace (MSC TRACE INVOKE), but phase 1 message (TRACE INVOCATION). In that case, BSS generates call trace records and not IMSI trace records. Thus, radio measurements could be collected with IMSI trace invocation and call trace has not been used.
Test Report
But, forcing external handover did prevent from real usage of trace records. Indeed, with this operating mode, one new file is generated for each new SCCP connection, i.e. handover. This problem added to high sampling of radio measurements (20) did prevent from its usage for detailed protocol and radio measurements analysis. Moreover, FTM checked results of deterministic tests with TEMS traces only (downlink only for radio measurements). 5.7.1.3 Indicators
No post-processing has been done based on Call Trace. 5.7.1.4 Possible improvements
Evolutions of this feature must be foreseen to make it useful in an operational network. Requests For Improvements will be made to technical department related to: - Radio statistics implementation in IMSI trace: Traces could be collected because MET sent phase 1 message. With phase 2 message, only basic records (i.e. no radio measurements) are reported. Radio measurements should be implemented in IMSI trace, because its usage is much more interesting that the call trace. - Sampling rate decrease: one radio measurement record is reported every 20 reporting period (10 seconds). Which such a period, no reliable analysis can be made. Sampling 2 (every second) should rather be used. - Real measurements reporting: Reported values are BSC internal averages. Trace records should rather report real radio measurements. - Forced external handover management: This is a usual configuration for field trials. BSS should be able to generate only one trace record per call, even if MSC makes several requests (one per SCCP connection attempt). - Output file format: It must be designed so that post-processing can easily be made.
5.8 BSC INTERNAL TRACE

5.8.1.1 Description
BSC monitoring (accessible from BSC terminal on X25 link) is based on trace and debug facility (TRADEB). Interesting function for such a field trial is BSC inter-tasks traces, especially to provide on-line handover causes follow-up. 5.8.1.2 Usage
This method has only been used during deterministic tests for on-line checking of BSC handover alarms, and not during statistic tests as initially planned. Development of a postprocessing tool making statistics on handover causes per couple of cells has been started but finally stopped. Interest of such a development is to bring extra information compared to interfaces post-processing, i.e.: - when handover causes with same A interface mapping have to be discriminated, - when congestion situation occurs in case of internal handover.
File FTMDUALB.DOC
Edition 1.0
Page 61
Test Report
The first case is only necessary in micro cellular network, which was not the objective of this field trial, as cause 21 (mapped as better cell like cause 14 or 12) handover can be discriminated by target cell type (1800). The second case was no longer useful when FTM decided to force all handovers to be external.
File FTMDUALB.DOC
Edition 1.0
Page 62
Test Report
6 RESULTS: RADIO COVERAGE

6.1 CONTENT
This document describes the radio aspects of the dual band experimental network : - power budget, - radio coverage thanks to Air / Abis traces analysis.
6.2 POWER BUDGET COMPUTATION

6.2.1 Reminder of radio configuration The radio configuration was very unusual because experimental sites were also commecial sites (Itinris 900 MHz and Olla 1800 MHz networks) leading to important losses between BTS and antenna because of the use of non-symmetrical couplers (1/4-3/4 : 1.2 dB losses for the commercial network and 6 dB losses for the experimental network) in order to use the same antenna for all networks. Obviously, in a commercial configuration, coverage (especially in the 1800 MHz frequency band) would be really improved. For two sites cross-polar dual-band antennas were used. For the third one a dual band antenna with vertical polarization was used. The antenna of the microcell was a real microcellular antenna (Suhner panel) but was located above the roofs. 6.2.2 Power budget computation Assumptions : - BTS sensitivity (sBTS) : G3 900 = -111 dBm, G2 1800 = -107 dBm - mobile sensitivity (sm) : 900 = -102 dBm, 1800 = -100 dBm - diversity gain (Gdiv) = 3 dB - ANX losses (PeANX; G3 BTS) = 1.8 dB - ANY losses (PeANY; G3 BTS) = 3.7 dB - combiner losses (PeCOUP, G2 BTS) = 4.2 dB - external duplexer losses (PeDUP; G2 BTS) = 1 dB - TRX maximum output power (PTRX) G2 and G3 BTS = 45 dBm With these assumptions, in order to balance UL and DL, following BS_TXPWR_MAX and MS_TXPWR_MAX must be used :
File FTMDUALB.DOC
Edition 1.0
Page 63
FTM Dual Band Field Trial SiteCondition for a balanced power budget PTRX Gdiv PTRX Gdiv PTRX Gdiv PTRX = Pm + PeANX + PeANY + sm - sBTS + = Pm + PeCOUP + PeDUP + sm - sBTS + = Pm + PeANX + PeANY + sm - sBTS + = Pm + PeANX + PeANY + sm - sBTS BS_TXPWR_MA X (dBm) 45 coded 0 45 coded 0 45 coded 0 37 coded -8 45 coded 0 45 coded 0 43 coded -2
Test Report MS_TXPWR_MAX (dBm) 27 30 27 23 30 31 30
Malaret 900 Malaret 1800 Capitole 900 Capitole 900 micro Capitole 1800 St Rome 900 St Rome 1800
PTRX = Pm + PeCOUP + PeDUP + sm - sBTS + Gdiv PTRX = Pm + PeANX + PeANY + sm - sBTS PTRX = Pm + PeCOUP + PeDUP + sm - sBTS
These theoretical values were not used during the field trial for different reasons : - MS_TXPWR_MAX was always set to the maximum value because UL Power control was activated - Capitole was not an Itinris site (only an Olla site) : no 6dB coupling losses for 900 MHz experimental sectors. It was necessary to reduce by 6 dB BS_TWPWR_MAX for these sectors in order to put 900 MHZ and 1800 MHz experimental sectors at the same level - BS_TXPWR_MAX was not reduced for St Rome 1800 in order to improve the 1800 MHz coverage. Finally following values were used, where DL-UL is resulting power budget balance : Site Malaret 900 Malaret 1800 Capitole 900 Capitole 900 micro Capitole 1800 St Rome 900 St Rome 1800 BS_TXPWR_MAX (dBm) 45 coded 0 45 coded 0 39 coded -6 37 coded -8 45 coded 0 45 coded 0 45 coded 0 MS_TXPWR_MAX (dBm) 33 30 33 33 30 33 30 DL-UL (dB) -6 0 -12 -10 0 -2 +2
6.3 RADIO COVERAGE (AIR INTERFACE RESULTS)

6.3.1 1800 MHz Unfortunately it was not possible to obtain the coverage of the 1800 MHz layer because: - there was a bug with the GPS of the Surveyor (tool built around Motorola 8900) - A954 with Sagem 1800 MHz was unable to select the cells of the experimental network (cell test mode). Please refer to section 5 for more details on trace mobile applications used in Toulouse.
File FTMDUALB.DOC
Edition 1.0
Page 64
Test Report
Nevertheless, we can say that the 1800 MHz coverage was not very good in indoor (because of couplers). When entering in a building (ground floor) we lost 1800 MHz coverage after 2 or 3 meters. This problem is visible when looking at statistical tests results. 6.3.2 900 MHz The map below has been obtained with A954 in connected mode (serving cell). Be careful that because of handover algorithms (HO_MARGIN between macro cells, capture and emergency thresholds with the micro cell), the serving cell may not be the best server cell. The table below corresponds to the frequency plan used during the field trial.
Cell Capitole 1 micro Capitole 2 Capitole 3 40 51 St Rome 2 St Rome 3 27 58 Malaret 2 Malaret 3 53 45 Frequency 57 Cell St Rome 1 Frequency 34 Cell Malaret 1 Frequency 61
nCAPITOLE
nMALARET
nSt ROME
File FTMDUALB.DOC
Edition 1.0
Page 65
Test Report
Main issue is that the coverage (can be seen when colors are available!) of the micro cell is very good. Remember that the antenna was above the roof. This observation will influence statistic test results. 6.3.3 Indoor penetration losses Following table comes from FTM dual band field trial report. It has been obtained thanks to Air traces during statistical tests (TEMS) and gives the indoor penetration losses for different kinds of Indoor : - window : MS near the window - light : MS in a room with a window - deep : MS inside the building in a room without window.
Frequency band GSM900 INDOOR WINDOW LIGHT DEEP WINDOW GSM1800 LIGHT DEEP Mean value 6 dB 12 dB 15 dB 8 dB 13 dB 16 dB
6.4 RADIO COVERAGE (ABIS INTERFACE RESULTS)

During statistical tests, Abis traces were made and post-processed with DAFNE. Only Abis traces made during the scenario 1 (decreasing priority order : micro 900 > macro 1800 > macro 900) are presented here, as observations that can be made will apply for both scenarios. The results for the microcellular area (most interesting area for this scenario) are given below. For this area, indoor and outdoor measurements are available, with a quite large sample. 6.4.1.1 Outdoor measurements in the microcellular area
The following tables provide radio statistics resulting from DAFNE post-processing :
Cell Capitole 3 Capitole 2 Capitole 1 Capitole 1 micro Capitole 2 Capitole 3 40 51 34787 12897 Frequency Sample 877 868 875 57 3028 4323 1 27427 UNSIGNIFICANT
File FTMDUALB.DOC
Edition 1.0
Page 66
Test Report
Averages Av_Lev_UL AvLev_DL Av_Qual_UL Av_Qual_DL PL_UL PL_DL delta_pl delta_qual MS_pwr BS_pwr 877 868 57 40 51 -88,6 -90,3 -79,7 -84,5 -81,7 -79,5 -80,4 -70,1 -80,1 -77,0 0,5 0,4 0,1 0,4 0,2 2,1 0,7 0,5 1,1 0,8 117,7 118,8 102,1 113,5 108,7 119,4 120,4 102,1 114,1 111,0 -1,7 -1,6 0,0 -0,6 -2,4 -1,6 -0,3 -0,4 -0,7 -0,6 BQ 5,4% 3,9% 0,5% 4,6% 2,4% BQ 14,6% 5,1% 1,2% 7,4% 5,8% 29,1 28,4 22,4 29,0 26,9 40,0 40,0 32,0 34,0 34,0
Uplink Quality Qual0 877 868 57 40 51 88,4% 88,0% 98,8% 88,7% 94,1%
Qual1 Qual2 Qual3 Qual4 Qual5 Qual6 Qual7 2,3% 2,1% 0,3% 2,4% 1,1% 1,1% 1,9% 0,1% 1,7% 0,9% Qual2 14,8% 6,3% 6,2% 7,9% 7,2% 1,5% 2,2% 0,1% 1,5% 0,8% 1,3% 2,0% 0,1% 1,1% 0,8% 1,7% 1,7% 0,1% 1,2% 0,7% 1,1% 1,2% 0,2% 1,4% 0,8% 2,6% 1,1% 0,2% 2,0% 0,9%
Downlink Quality Qual0 Qual1 877 868 57 40 51 35,8% 74,7% 79,6% 64,3% 71,9% 12,5% 6,4% 5,7% 7,3% 7,4%
Qual3 Qual4 Qual5 Qual6 Qual7 13,9% 4,1% 4,9% 7,5% 4,8% 8,5% 3,4% 2,4% 5,7% 2,9% 5,5% 3,2% 0,9% 3,7% 2,2% 3,1% 1,3% 0,1% 2,5% 1,9% 6,0% 0,7% 0,2% 1,3% 1,7%
Comments : - For all cells with significant sample, uplink and downlink are well balanced. - Averaged signal levels from the micro 900 cell are very good (remember that the antenna was above the roof of the building) - Downlink signal levels for the micro 900 cell are much higher (15dB) than the capture threshold (-85 dBm), while downlink signal levels from macro 1800 cells are just higher (5 dB) than the capture threshold (-85 dBm). - Signal levels from 900 cells are obviously higher than signal levels from 1800 cells (6 or 7 dB for co-site cells). - No real quality problems are observed inside microcell area. Problems will rather be observed at REX area limit (see statistics tests). 6.4.1.2 Indoor measurements in the microcellular area
Tables are not provided, as same observations can be made, amplified by indoor conditions. Indeed, in indoor conditions, averaged level of micro cell remains 10dB above capture threshold, while level for macro 1800 is at the threshold limit.
File FTMDUALB.DOC
Edition 1.0
Page 67
Test Report
7 RESULTS: DETERMINISTIC TESTS

7.1 CONTENT
This document describes the results of deterministic tests made during the field trial. The aim of these tests was to validate (thanks to unitary tests) the good behaviour of the BSS for these specific procedures: handover algorithms (detection and candidate cell evaluation process), interworking with another BSS... It applies only to configurations that have really been tested on the field, i.e.: - scenario with priority: micro 900 > macro 1800 > macro 900, - scenario with priority: macro 1800 > micro 900 > macro 900. The main issue is that all tests requested by FTM (those possible with release B5) were successful.
7.2 TESTS METHOD

According to FTM test plan, deterministic tests were divided between several areas: regression, re-selection, call set-up, handover and mobility, interworking. Please refer to section 3 for a more complete description of these test areas. As for the method, deterministic tests were performed using: - TEMS (Ericsson's tool for Air interface traces), - Motorola 8900 dual band mobiles with trace facility, - Siemens single band phase 2 900 mobiles for congestion tests (congestion of the micro 900 cell). In order to simulate a problem of quality, measurement reports with bad quality (RXQUAL = 7) were built by the TEMS (special test feature). Finally TEMS traces were deeply analysed in order to verify the good behaviour of protocol and algorithms (threshold, averaging windows, ...). Due to lack of time (planning not in line with test method), only part of them have been made during the field trial.
7.3 DETERMINISTIC TESTS: DETAILED DESCRIPTION

For the two scenarios, configurations for Directed and Forced Directed Retry, better condition handovers and for the candidate cell evaluation process are presented in section 4.
File FTMDUALB.DOC
Edition 1.0
Page 68
Test Report
7.3.1
Scenario micro 900 > macro 1800 > macro 900 7.3.1.1 Regression
Regression tests described in FTM test plan were not performed. They were replaced at the beginning of the field trial with a walk test in order to verify the good behaviour of the system by making handovers between the cells of the experimental network (better condition and emergency, intra and inter layer). 7.3.1.2 Re-selection
No deterministic tests for re-selection were made. The good use of C2 criterion by MS has been tested during statistical tests and also during deterministic tests but in a non-formal way. These trials allowed to detect a problem in Alcatel implementation. Indeed, BSS implementation of SYSTEM INFORMATION 2ter was initially wrong. L2 PSEUDO LENGTH was not correct: consequence is that for some MS (TEMS typically), this message was discarded and dual band could not work in idle mode. 7.3.1.3 Call set-up
One requirement of FTM was the ability to make SDCCH -> TCH handovers (intercell HO) without congestion. Because such handovers are not possible in release B5, tests related to this kind of handovers were replaced with following handover tests: SDCCH cell A -> TCH cell A -> TCH cell B. The table below (extracted from FTM report) shows the tests that have been performed successfully:
Test SDCCH M900 -> TCH M1800 SDCCH M900 -> TCH micro900 Cells not available micro900 SDCCH M900 -> TCH M900 -> TCH M1800 (HO cause 21) SDCCH M900 -> TCH M900 -> TCH M1800 (HO cause 21) -> TCH micro900 (HO cause 14) SDCCH M1800 -> TCH M1800 (neighbour cell) " " SDCCH M1800 -> TCH M900 " " SDCCH M1800 -> TCH micro900 SDCCH micro900 -> TCH M1800 Bad quality micro900 micro 900 micro 900 macro 1800 micro 900 macro 1800 micro 900 macro 1800 Bad quality and congestion (100 %) Congestion = 100 % Congestion = 100 %**** Bad quality and congestion (100 %) Bad quality micro900 Bad quality SDCCH M1800 -> TCH M1800 -> TCH M1800 (HO cause 4 = DL quality) SDCCH M1800 -> TCH M1800 (HO cause 20 = Forced Directed Retry) SDCCH M1800 -> TCH M1800 (HO cause 20*) SDCCH M1800 -> TCH M1800 -> TCH M900 (HO cause 4) SDCCH M1800 -> TCH M900 (HO cause 20) SDCCH M1800 -> TCH M900 (HO cause 20) SDCCH M1800 -> TCH M1800 -> TCH micro 900 (HO cause 14) SDCCH micro900 -> TCH micro900 -> TCH M1800 (HO cause 4**) Conditions Expected behaviour of Alcatel BSS
File FTMDUALB.DOC
Edition 1.0
Page 69

" SDCCH micro900 -> TCH M900 " macro 1800 Congestion = 100 %*** Bad quality Congestion = 100 %
Test Report
SDCCH micro900 -> TCH M1800 (HO cause 20) SDCCH micro900 -> TCH micro900 -> TCH M900 (HO cause 4) SDCCH micro900 -> TCH M900 (HO cause 20)
Notes: * ** *** **** 7.3.1.4
A_QUAL_HO = 6, A_PBGT_DR = 4: cause 20 is triggered before cause 4 use of PRIORITY(0,n) to direct MS towards M1800 use of Siemens mono band 900 mobiles Time Slots of G2 1800 blocked Handover and mobility
These tests were divided for this scenario between several areas: speed discrimination, congestion and traffic handover, bad quality. Congestion and traffic handover could not been test because traffic handover is not available in B5. Speed discrimination The table below shows the test that has been performed successfully:
Test Verify that cause 14 between M900 or M1800 and micro900 is triggered after L_MIN_DWELL_TIME seconds Conditions Micro900 is always received with a level higher than L_RXLEV_CPT_HO(n)
Remarks: - For remind, L_MIN_DWELL_TIME = 8 s, L_RXLEV_CPT_HO(n) = -85 dBm for the micro 900 cell and EN_SPEED_DISC = DISABLE for macro 900 and 1800 cells. - No drive test was planned : it could not be checked that fast MS do not go on microcell. Bad quality The table below shows the tests that have been performed successfully (during the call set-up tests).
Test Bad quality on micro900 Bad quality on M1800 Expected behaviour of Alcatel BSS TCH micro 900 -> TCH macro 1800 (HO cause 4 + use of PRIORITY(0,n)) TCH M1800 -> TCH M1800 (HO cause 4)
7.3.2
Scenario macro 1800 > micro 900 > macro 900 7.3.2.1 Call set-up
The table below shows the tests that have been performed successfully:
Test SDCCH M900 -> TCH M1800 SDCCH M900 -> TCH micro900 macro 1800 Cells not available SDCCH M900 -> TCH M900 -> TCH M1800 (HO cause 21) SDCCH M900 -> TCH M900 -> TCH micro900 (HO cause 14) Conditions Expected behaviour of Alcatel BSS
File FTMDUALB.DOC
Edition 1.0
Page 70

SDCCH M1800 -> TCH M1800 (neighbour cell) " SDCCH M1800 -> TCH M900 " SDCCH micro900 -> TCH M1800 SDCCH micro900 -> TCH M900 " macro 1800 macro 1800 Bad quality Congestion = 100 % micro 900, macro 1800 micro 900, macro 1800 Congestion = 100 % Congestion = 100 %* Bad quality Bad quality
Test Report
SDCCH M1800 -> TCH M1800 -> TCH M1800 (HO cause 4 = DL quality) SDCCH M1800 -> TCH M1800 (HO cause 20 = Forced Directed Retry) SDCCH M1800 -> TCH M1800 -> TCH M900 (HO cause 4) SDCCH M1800 -> TCH M900 (HO cause 20) SDCCH micro900 -> TCH micro900 -> TCH M1800 (HO cause 21) SDCCH micro900 -> TCH micro900 -> TCH M900 (HO cause 4) SDCCH micro900 -> TCH M900 (HO cause 20)
Note : * mode. 7.3.2.2
Time Slots of G2 1800 were blocked (configured in idle mode) to ease test operating Handover and mobility
These tests were divided for this scenario between several fields: congestion and traffic handover, bad quality, 1800 MHz zone exit. Congestion and traffic handover could not been tested because traffic handover is not available in B5. Bad quality The table below shows the tests that have been performed successfully (during the call set-up tests).
Test Bad quality on micro900 Bad quality on M1800 Expected behaviour of Alcatel BSS TCH micro 900 -> TCH macro 1800 (HO cause 4 + use of PRIORITY(0,n)) TCH M1800 -> TCH M1800 (HO cause 4)
1800 MHz zone exit Two tests have been successfully performed: - 1800 MHz zone exit on emergency alarm (level), - anticipated 1800 MHz zone exit on "PBGT". The configuration for the second test is described in section 4.5.2.3. It is very interesting and shows how useful is the PBGT filtering mechanism. 7.3.2.3 Interworking
Interworking tests with Nortel mono (1800 MHz commercial network) and dual band (experimental network) BSS have been successfully performed. Obviously, new neighbour cells have been added for these tests. Results that could be observed were: - After the handover with the dual band BSS, there is no problem for the call. - When call is initiated on the other band, interband handover with the single band BSS is possible but the single band BSS is unable to obtain the actual power capability of the incoming dual band MS. In that case, no handover is possible on target BSS, and call will be drop in case of radio degradation.
Test Report
7.3.3
Extra tests Extra tests not described in FTM test plan have been suggested by Alcatel to demonstrate extra features: - anti ping-pong mechanism introduced in B4, - use of FREEfactor, - classmark enquiry for external handovers incoming with no classmark 3 available. Results were : - The first one demonstrated successfully the possibility to avoid ping-pong handover on cause 12 between two macrocells using PING_PONG_HCP and T_HCP parameters. - The aim of the second test was to demonstrate the possibility to take into account the traffic load of target cells during the candidate cell evaluation process in order to send the MS preferably towards non-loaded cells. Unfortunately a bug in FREEfactor management was found during test preparation that did prevent from performing the test. - This test has been done thanks to TEMS test feature (removal of CLASSMARK CHANGE message). Once incoming external handover occurs with ES_IND flag set, BSS triggers CM ENQUIRY procedure to get dual band capacity.
File FTMDUALB.DOC
Edition 1.0
Page 72
Test Report
8 RESULTS: STATISTIC TESTS

8.1 TESTS DESCRIPTION
8.1.1 Test method This test method has been defined by FTM. REX2 area has been split in grids 100x100 meters outside microcell area and 25x25 meters inside microcell area. In as many grids as possible, some measurement routes have been made in various test conditions: - From deep indoor to outdoor conditions, - With single (Siemens) and dual band (Motorola and TEMS) mobiles, - In both idle and dedicated modes. 8.1.2 Collected results 8.1.2.1 FTM evaluation method
A tool called Evaluator and written by FTM, performs some post-processing on TEMS traces collected during statistic test routes, and gives notes, traffic and propagation statistics, graphical display of results.
Notes
Taking into account RXLEV of serving and neighbour cells, Alcatel parameters (reselection and handover thresholds) and expected priorities between layers, a note is given on each measurement route of dual band MS: - 1 means that most of time spent on serving cell has been spent on best (preferred) cell, - 0,5 means that best cell is only in second position in averaged time, - 0,33 means that best cell is only in third position, - 0 otherwise (typically MS has never gone on best cell).
Traffic statistics
Percentage of time elapsed on each layer (micro, macro 1800, macro 900) is computed for dual band MS. It can be done inside and outside micro area, for outdoor, indoor window, indoor light and deep indoor.
Graphical display
Post-processing tool allows also displaying grid per grid, the layer on which the MS has spent most of time. Successive maps have been produced to take into account second and third cell, when preferred cell was not the serving one.
Propagation statistics
This tool has also produced statistics related to propagation differences between co-sites 900 and 1800 cells (after correction of EIRP differences). Due to its computation method, Evaluator is only able to produce statistics for dual band mobiles and take into account on downlink levels in serving cell evaluation.
File FTMDUALB.DOC
Edition 1.0
Page 73
Test Report
8.1.2.2
Alcatel collected statistics
In parallel to TEMS traces, Alcatel did some extra monitoring and post-processing: - A interface monitoring and post-processing (AGLAE) : traffic and handover statistics per mobile type, - OMC-R counters collection: general QoS statistics for all mobile types. - Abis monitoring for specific needs. Please refer to section 5 for complete description of tools, methods and indicators used by Alcatel during this field trial. Moreover, Abis results are analysed in section 6. 8.1.2.3 Comments on both methods
The advantages of Evaluator method are: - It gives to possibility to correlate results and geographical area, which is not possible with A interface traces. For A traces, the split outdoor / indoor could be done by making separate test sessions and traces. - It also provides downlink radio statistics (like propagation difference), which is available neither on A interface, nor with OMC-R counters. - It allows to get statistics in idle mode (time elapsed on each layer), which cannot be collected on A interface or with counters, since reselection do not trigger any signalling when location area is not changed. But : - Evaluator is only based on downlink level measurements and does not take into account (mainly for notation) problems which can occur on uplink path (typically quality problems due to interference with Olla commercial network) and prevent from staying on cell declared as best on downlink level criteria. - Evaluator is based on TEMS results. Therefore, only statistics related to this dual band MS are available through this method. It does also include problems encountered with this MS : - High rate of handover failure (MS may stay for a long time on serving cell while it should leave) - Slow neighbour cells monitoring (up to 10 seconds to monitor cells of the other band). 8.1.3 Test routes Next table summarizes all test routes that have been done during the three weeks of experimentation. This table contains : - REC file : It is the reference of A interface trace file, which is then post-processed by AGLAE or agrpt tool. These trace files were usually collected on a day / half day or statistic tests session basis. - Tests : States whether reference tests are reference route, deterministic tests and statistic tests. - Scenario : Refers to scenario 1 (priority order micro > macro 1800 > macro 900) or to scenario 2 (priority macro 1800 > micro > macro 900). - Test type : It states whether tests have been done in outdoor or indoor conditions. As mentioned above, more detailed split (various indoor steps) was not available. - Test area : It states whether tests have been done over micro area (i.e. with significant micro coverage), or macro area (i.e. outside micro coverage), or over all REX network.
File FTMDUALB.DOC
Edition 1.0
Page 74
Test Report
Cumulated In : This column contains cumulating rule used to gather various test routes. For each scenario, three different types of tests have been gathered : micro indoor (pedestrian tests), macro indoor (pedestrian tests) and REX Outdoor (drive tests).
Only the results of cumulating will be analysed in this document, as they contain the representative and interesting data. REC file Tests Scenario Test type Test area Cumulated in 1105_1 Reference 1 Outdoor REX 1205_1 Determinist 1 Outdoor MACRO 1305_1 Determinist 1 Outdoor MICRO 1405_2 Statistic 1 Outdoor REX REX 1505_1 Statistic 1 Indoor MICRO 1505_2 Statistic 1 Indoor MICRO 1805_1 Statistic 1 Indoor MICRO MICRO 1805_2 Statistic 1 Indoor MACRO MACRO 1905_1 Statistic 1 Indoor MACRO MACRO 2005_1 Statistic 1 Indoor MICRO MICRO 2005_2 Statistic 1 Outdoor REX REX 2105_1 Reference 2 Outdoor REX 2205_1 Reference 2 Outdoor REX 2305_1 Alcatel 2 In/Outdoor REX 2505_1 Deterministic 2 Outdoor MACRO 2605_1 Statistic 2 Indoor MICRO MICRO 2605_2 Statistic 2 Indoor MICRO MICRO 2705_1 Statistic 2 Indoor MICRO MICRO 2705_2 Statistic 2 Indoor MACRO MACRO 2705_3 Statistic 2 Indoor MACRO MACRO 2805_1 Statistic 2 Indoor MACRO MACRO 2905_1 Statistic 2 Outcar REX REX
8.2 SCENARIO 1 (PRIORITY MICRO) RESULTS ANALYSIS

8.2.1 Evaluator results This section summarizes main results computed by FTM with Evaluator tool for scenario 1 (priority micro), and especially traffic repartition between different layers and in various test conditions.
Notes
FTM states in its report that good notes demonstrate that Alcatel BSS behaves properly according priority requested by FTM, i.e. serving cell is always the preferred one according expected priority mechanisms.
Idle mode
These two tables (source : FTM report) sum-up time elapsed on each layer in idle mode, either inside microcell area or outside micro cell area.
File FTMDUALB.DOC
Edition 1.0
Page 75
Test Report
INDOOR INDOOR DEEP Layer OUTDOOR WINDOW LIGHT INDOOR Micro 900 86% 81% 61% 53% Macro 1800 6% 14% 11% 9% Macro 900 8% 5% 28% 39% Table1.2.1.2-1 : % of time in idle mode inside micro area INDOOR INDOOR DEEP Layer OUTDOOR WINDOW LIGHT INDOOR Micro 900 0% 0% 2% 0% Macro 1800 70% 65% 54% 43% Macro 900 30% 35% 44% 57% Table1.2.1.2-2 : % of time in idle mode outside micro area The following comments can be made : - Priority mechanisms are fully respected and reselection is quite efficient. In microcell area, MS camp between 50 and 90% of the time on the microcell. MS will therefore start directly their call set-up on expected layer. It is important to note that time has only been measured once speed discrimination time is over (about 25 seconds after selection). - In indoor conditions, time elapsed on microcell decreases and is progressively reported on macro cells. 1800 cells are selected first, then 900 cells. Inside microcell area, part of traffic taken by 1800 layer is not that good because of low 1800 covergae and high microcell coverage (probable direct reselection from micro 900 to macro 900 in numerous cases). - Outside microcell area, time elapsed on 1800 layer is quite low (should be close to 100% in outdoor conditions). It reflects again problems of coverage on 1800 layer. Nevertheless, priority mechanisms are respected and time elapsed on 1800 decreases progressively in indoor conditions.
Dedicated mode
These two tables (source : FTM report) sum-up time elapsed on each layer in connected mode, either inside microcell area or outside micro cell area. INDOOR INDOOR DEEP Layer OUTDOOR WINDOW LIGHT INDOOR Micro 900 80% 68% 52% 30% Macro 1800 17% 6% 9% 16% Macro 900 3% 26% 38% 54% Table1.2.1.2-3 : % of time in connected mode inside micro area INDOOR INDOOR DEEP Layer OUTDOOR WINDOW LIGHT INDOOR Micro 900 0% 5% 3% 20% Macro 1800 69% 39% 45% 0% Macro 900 31% 55% 52% 80% Table1.2.1.2-4 : % of time in connected mode outside micro area
File FTMDUALB.DOC
Edition 1.0
Page 76
Test Report
The following comments can be made : - Priorities are properly respected. Communications stay most of the time on preferred layer and progressively move to lower priority layer when entering in indoor conditions. Part of traffic supported by 1800 layer in micro cell area is quite important (knowing coverage) because of priority set to this layer when leaving microcell on emergency. - Parameters set for reselection give much more priority than those used in idle mode. Indeed, traffic supported by each priority layer in connected mode is lower than time elapsed in idle mode (between 6% and 23% difference). Two explanations can be given : - Difference between the value of RXLEV_ACCESS_MIN (-99 dBm for M1800) and L_RXLEV_DL_H (-95 dBm for M1800). For some MS connected to a macro 1800 cell in idle mode a handover alarm on level may be triggered at the beginning of the call. - Difference between the value of CELL_RESELECT_OFFSET for M900 (0 dB -> C2 = C1) and M1800 (60 dB -> C2 = C1 + 60) cells. A strong advantage is given to M1800 for re-selection. Lets consider the case where RXLEV = -80 dBm for M900 and -94 dBm for M1800. With such values, C1 >0 for both cells and C2(M1800) > C2(M900). A MS will re-select the macro 1800 cell and a handover alarm will certainly be triggered quickly. The impact of such an unbalance can be an increase of number of handovers, i.e call initiated on layer with high priority may it leave quickly on emergency. 8.2.2 Call set-up statistics This table provides repartition of call attempts for dual band MS (for remind, layer on which ASSIGNMENT REQUEST has been sent) for scenario giving highest priority to microcell layer. These statistics could have been done as well for single band MS (which were phase 2, and therefore did support reselection). They are not described, as they do not bring extra information. Micro Macro 1800 Macro 900 61% 15% 24% 4% 47% 49% 12% 81% 7% Table1.2.2 : Repartition of calls attempts
sample 100 163 147
Indoor Micro Indoor Macro Outdoor REX
First of all, this table confirms through a different computation method FTM reselection results given in section 1.2.1.2. Indeed, correlation with FTM results can be done with following assumptions : - Indoor macro equivalent to Indoor light for outside microcell area tests, - Indoor micro equivalent to Indoor light for inside microcell area tests, - Outdoor REX cannot be correlated as it covers inside and outside microcell area. It demonstrates that we are able to monitor reselection efficiency per mobile type thanks to AGLAE post-processing. Same comments can be made for results collected from TEMS traces analysis : - Reselection is an efficient mechanism to set-up a call on the right layer, - Call is initiated at 60% on microcell in microcell area and indoor conditions, and at 80% on macro1800 in outdoor conditions over all network, - Bad indoor results in macro area (only 50% on macro1800) are due to bad 1800 coverage.
Test Report
8.2.3
Traffic statistics The following results could be computed with A interface post-processing : - Rate of traffic generated by dual band and single band MS, - Repartition of each MS type traffic between micro, macro 1800 and macro 900. 8.2.3.1 Traffic description
Traffic generated by FTM measurers was as follows : - 40% with dual band MS (TEMS + Motorola) and 60% with single band MS (Siemens). - Traffic not representative of a commercial network traffic (between 2 and 10 Erlang 18 TRX) : most of the case, calls were concentrated on cells under test (quite all TCH seized, but congestion situation avoided). The only information that can be collected from these results is ability to measure split of traffic between single band MS and dual band MS. It will be useful to measure actual dual band MS penetration rate. Unfortunately, no reliable result can be expected by this field trial in terms of capacity increase brought by dual band introduction. 8.2.3.2 Repartition for single band MS
These statistics are not available with FTM results that only apply to dual band MS, and with OMC-R counters that apply to all MS. This table provides traffic repartition between layers for different test conditions : Tests \ Layer Indoor Micro Indoor Macro Outdoor REX Micro 61% 3% 18% Macro 1800 Macro 900 0% 39% 0% 97% 0% 82% Total 11:49:47 1:19:57 14:59:22
Comments : - 60% of traffic is supported by microcell in indoor conditions in microcell area. - Obviously, as single band MS were GSM900 MS, no traffic is observed on 1800 layer. - Rate of traffic supported on microcell is quite important over all REX (just remind that there was only one micro and 18 macro cells), which is explained by unusual microcell coverage. 8.2.3.3 Repartition for dual band MS
This table provides traffic repartition between layers for different test conditions : Tests \ Layer Indoor Micro Indoor Macro Outdoor REX Micro 60% 5% 14% Macro 1800 Macro 900 12% 28% 43% 51% 51% 35% Total 6:05:43 14:23:33 20:41:34
Comments : - Priority given to micro is confirmed, as rate of traffic supported by this layer is the same that for single band MS. Extra traffic offered by 1800 layer is taken from macro 900. - Part of traffic captured by 1800 layer from macro 900 layer is quite low (50% in outdoor conditions) because of low 1800 coverage.
Test Report
8.2.4
Handover statistics These statistics are quite interesting to follow handover flows between layers and quality of service issues (handover causes distribution, success and failure rates). It is important to remind that these statistics could be produced for both MS types because handover was forced to be external. In order not to provide two much information, only a subset of results will be commented hereafter : indoor tests in microcell area for dual band MS. MS Outdoor tests will be commented with scenario 2 parameters set. 8.2.4.1 Outgoing handovers
These tables provides for each layer repartition of outgoing handover attempts between target layers : Micro Dual Band MS Macro 1800 Dual Band MS Macro 900 Dual Band MS Sample Emerg. 1800 78 48.7% Sample Emerg. Micro 5.4% 74 Sample Emerg. micro 84 28.6% Emerg. 900 51.3% Emerg. 1800 2.7% Emerg. 1800 13.1% Emerg. 900 70.3% Emerg. 900 9.5% Capture micro 21.6% Capture micro 11.9% PBGT 1800 0.0% Capture 1800 35.7% PBGT 900 1.2%
Comments : - Micro: Due to priority scheme and the fact that there was only one microcell, call can only leave microcell on emergency. Rate of emergency to 1800 layer (50% for a lower coverage) demonstrate efficiency of PRIORITY(0,n) mechanism to order candidate cells, as default priority mechanism would prefer layer of same band (i.e. 900 MHz). - Macro 1800: Most of outgoing handovers go to macro 900 on emergency. No PBGT handover is performed due to test conditions (indoor and located in a small area), but also probably because of bad/uncontinuous coverage (exit on emergency to 1800 layer are observed!). Some emergencies on microcell also illustrate abnormal radio conditions (bad 1800 coverage and high micro coverage). Rate of capture to micro is quite low, which is due to reselection efficiency (calls go directly to micro). Captures occur after call set-up for MS not selected on microcell and also after emergency handovers (ping-pong capture on level emergency on quality). - Macro 900 : First observation is that 50% of handovers are due to capture. Captures that are made to micro are due to lack of 1800 candidate. A lot of emergency must be noticed, they are certainly linked to the fact that macro 900 is used in deep indoor conditions. Again, in most cases, microcell is stronger than 1800 cell. 8.2.4.2 Incoming handovers
These tables provides for each layer repartition of incoming handover attempts:
File FTMDUALB.DOC
Edition 1.0
Page 79
Test Report
Micro Dual Band MS Macro 1800 Dual Band MS Macro 900 Dual Band MS
Sample Emerg. 1800 54 7.4% Sample Emerg. micro 81 46.9% Sample Emerg. Micro 39.6% 101
Emerg. 900 44.4% Emerg. 1800 2.5% Emerg. 1800 51.5%
Capture 1800 29.6% Emerg. 900 13.6% Emerg. 900 7.9%
Capture 900 18.5% PBGT 1800 0.0% PBGT 900 1.0% Capture 900 37.0%
Comment : - Micro : High rate of incoming handover is capture (for calls not initiated on microcell), but rate of emergency is abnormal for such a layer that should not be a rescue layer. - Macro 1800: It is intermediate layer that collects emergency from micro and capture from macro 900. - Macro 900 : It is rescue layer that collects all emergencies from lower layers. 8.2.4.3 Distribution of emergency handovers
These tables provides for each layer repartition of outgoing emergency handover causes : Micro Dual Band MS Macro 1800 Dual Band MS Macro 900 Dual Band MS Sample UL Quality 78 14.1% DL Quality 11.5% DL Quality 10.3% DL Quality 20.9% UL Strength 26.9% UL Strength 65.5% UL Strength 0.0% DL Strength 47.4% DL Strength 5.2% DL Strength 62.8%
Sample UL Quality 58 19.0%
Sample UL Quality 43 16.3%
Comments : - For each layer, repartition between quality and level emergency handovers is 40-60. It is quite difficult to make any comment on this repartition. - Repartition between uplink and downlink differs from one layer to the other one. It is always unbalanced for 1800 cells (UL rate very high) and 900 cells (DL rate very high). It can be explained by theoretical transmission link unbalance for Capitole 900 cells (-10/12db for DL-UL). Concerning macro 1800, explanation is probably transmission link unbalance (lower sensibility or higher output power than initially expected).
File FTMDUALB.DOC
Edition 1.0
Page 80
Test Report
8.2.4.4
HO efficiency
These tables provides for each layer statistics on handover success rate : Dual Band MS Micro Macro 1800 Macro 900 Sample Success 78 74 84 82.1% 90.5% 91.7% Drop 0.0% 0.0% 2.4% Reversion 17.9% 9.5% 6.0%
Comments : - First, TEMS bug explains high reversion to old channel. Not such a rate is observed for single band MS. Consequence is that no reliable data can be collected during field trial on this topic. - Call drop on handover is very low. Moreover, it should have been amplified by TEMS bug (radio degradation after several handover attempts). 8.2.5 OMC-R counters statistics It is not possible with these statistics to make difference between single and dual band mobiles. Therefore, in most cases results from interfaces have been preferred. Nevertheless, the following results will be commented : traffic repartition, call and TCH drop statistics. All handover statistics have also been issued, but will not be described, as they bring the same results than A interface. Reference day used in following section is 19/05, with indoor statistic tests outside microcell area. 8.2.5.1 Call and TCH drop
This table provides for whole network and each layer statistics on call and TCH drop : Call and TCH drop TCH Drop Rate Sample Global 1133 REX 2 4.68% 49 0.00% Micro Macro 1800 Macro 900
407 677
BSS 0.09% 0.00% 0.00% 0.15%
Radio 4.41% 0.00% 2.46% 5.91%
HO 0.18% 0.00% 0.49% 0.00%
Call Drop Rate TCH/Call Global 5.15 24.1%
2.95% 6.06%
Comments : - Call drop rate is very high, but it can easily be explained. Indeed, tests were done in conditions that do not reflect usual conditions : long calls (with a lot of handovers) and many calls in deep indoor conditions (loss of service). In outdoor conditions, statistics were much better. 8.2.5.2 Traffic repartition
This table provides for whole network and each layer statistics on traffic :
File FTMDUALB.DOC
Edition 1.0
Page 81
Test Report
Traffic repartition REX 2 Micro Macro 1800 Macro 900

Sample
TCH seizure 100% 5% 24% 71%

92853
DB MS rep. DB MS pen. LU attempt Call attempt 100% 2% 54% 44%

335
16% 10% 91% 8%

335
100% 4% 7% 90%
1833
100% 6% 31% 64%

248
Comments : - TCH seizure represents repartition for all MS types. Correlation has been made with A results by adding single and dual band MS results and gave similar results. - DB MS rep. gives the repartition of C150 counters (CLASSMARK CHANGE including dual band capacity) between layers. It can be a good indicator to monitor reselection efficiency, but care must be taken because it includes both LOCATION UPDATING and call set-up. DB MS pen. was initially foreseen to count dual band penetration rate. We can see on this table that this rate in not 100% on 1800 layer as it should be. It is explained by periodic updating of dual band MS which is too fast and does not allow CLASSMARK CHANGE processing. Please refer to section 5 for more information on this topic. - LU attempt repartition is unsignificant because of numerous LOCATION UPDATE messages (rejected afterwards wrong PLMN) made on 900 layer (debarred) by commercial MS. Its objective would be to monitor selection/reselection. - Call attempts reflects reselection impact, as it count call establishment attempts. It applies to all mobiles and confirms results collected from A interface.
8.3 SCENARIO 2 (PRIORITY MACRO 1800) RESULTS ANALYSIS

8.3.1 Evaluator results This section summarizes main results computed by FTM with Evaluator tool for scenario 2 (priority micro), and especially traffic repartition between different layers and in various test conditions. Difference between scenario 1 and scenario 2 is only priority order in microcell area. Thus, only results in this area will be given.
Notes
Again, FTM states in its report that good notes demonstrate that Alcatel BSS behaves properly according priority requested by FTM, i.e. serving cell is always the preferred one according expected priority mechanisms.
File FTMDUALB.DOC
Edition 1.0
Page 82
Test Report
Idle mode
This table (source: FTM report) sums up time elapsed on each layer in idle mode inside microcell area. INDOOR INDOOR DEEP Layer OUTDOOR WINDOW LIGHT INDOOR Micro 900 0% 19% 12% 13% Macro 1800 100% 74% 54% 41% Macro 900 0% 7% 34% 46% Table1.3.1.2-1 : % of time in idle mode inside micro area The following comments can be made : - Priority mechanisms are fully respected and reselection is quite efficient. In microcell area, MS camp between 40 and 100% of the time on the macro 1800. Important decrease between outdoor and indoor is due to low 1800 coverage. Lost MS move on micro 900 (which has a better coverage in this area) or macro 900.
Dedicated mode
This table (source : FTM report) sums up time elapsed on each layer in idle mode inside microcell area. INDOOR INDOOR DEEP Layer OUTDOOR WINDOW LIGHT INDOOR Micro 900 2% 16% 25% 16% Macro 1800 87% 53% 25% 16% Macro 900 11% 31% 49% 67% Table1.3.1.2-2 : % of time in connected mode inside micro area The following comments can be made : - Priority is properly respected. Communications stay most of the time on preferred layer and progressively move to lower priority layer when entering in indoor conditions. Most of the traffic is transferred to macro 900 (which has higher priority for emergency handovers on 1800 cells). - Again, parameters set for reselection give much more priority than those used in idle mode. Indeed, traffic supported by each priority layer in connected mode is lower than time elapsed in connected mode (between 13% and 25% difference). Explanations given for scenario 1 remain available. 8.3.2 Call set-up statistics This table provides repartition of call attempts for dual band MS (for remind, layer on which ASSIGNMENT REQUEST has been sent) for scenario giving highest priority to macro 1800 layer.
File FTMDUALB.DOC
Edition 1.0
Page 83
Test Report
Tests \ Layer Indoor Micro Indoor Macro Outdoor REX
Micro Macro 1800 Macro 900 12% 69% 20% 0% 60% 40% 0% 70% 30% Table1.3.2 : Repartition of call attempts
Sample 86 111 30
The following comments can be made that for results collected from TEMS traces analysis : - Call is initiated at 70% on macro 1800 in any area and indoor conditions : all calls which were established on micro layer in scenario 1 are now established on macro 1800 (exception is due to better microcell coverage in indoor conditions). - All these results are impacted by bad 1800 coverage : an important rate of dual band MS have established their call on 900 layer, even in outdoor conditions. 8.3.3 Traffic statistics 8.3.3.1 Traffic description
Traffic generated for scenario 2 is the same than for scenario 1. Therefore, comments made for scenario 1 are still applicable. 8.3.3.2 Repartition for single band MS
Comments : - Again, 60% of traffic is supported by microcell in indoor conditions in microcell area. It demonstrates that multiband operation (change priority of macro 1800) has no impact at all on single band MS behaviour. - Comments made for scenario 1 are still applicable : no traffic on 1800 layer, important rate of traffic on microcell over whole REX network. 8.3.3.3 Repartition for dual band MS
Comments : - If we compare to scenario 1, traffic supported by macro 900 remains unchanged and most of traffic supported by micro layer has been moved on 1800 layer. It demonstrates efficiency of parameters change to cope with new priority scheme.
File FTMDUALB.DOC
Edition 1.0
Page 84
Test Report
8.3.4
Handover statistics In order to complete analysis made for scenario 1, only a subset of results will be commented hereafter : outdoor tests in all REX area for dual band MS. 8.3.4.1 Outgoing handovers
These tables provides for each layer repartition of handover attempts between target layers : Micro Dual Band MS Macro 1800 Dual Band MS Macro 900 Dual Band MS Sample Emerg. 1800 25.0% 12 Sample Emerg. micro 0.3% 394 Sample Emerg. micro 318 0.0% Emerg. 900 0.0% Emerg. 1800 9.6% Emerg. 1800 1.9% Capture 1800 75.0% Emerg. 900 42.9% Emerg. 900 23.9% PBGT 1800 47.2% Capture micro 2.5% Capture 1800 54.4% PBGT 900 17.3%
Comments : - Micro: Priority mechanism is fully respected. Highest priority of the network is macro 1800, which is observed for both emergency and capture handovers (for MS still selected on microcell). As we are in outdoor conditions, 1800 coverage is sufficient to receive all outgoing handovers. - Macro 1800: In outdoor conditions, rate of PBGT become important (compared to scenario 1), even with REX 1800 coverage. Other outgoing handovers are emergencies to macro 900 that is the preferred layer for such cases. - Macro 900 : As we have seen that reselection was very efficient in these conditions, capture handovers occur certainly after an emergency handover from 1800 layer. All handovers that are not capture are PBGT or emergency to macro 900 layer. 8.3.4.2 Incoming handovers
These tables provides for each layer repartition of incoming handover attempts: Micro Dual Band MS Macro 1800 Dual Band MS Macro 900 Dual Band MS Sample Emerg. 1800 11.1% 9 Sample Emerg. micro 0.7% 415 Sample Emerg. micro 0.0% 300 Emerg. 900 0.0% Emerg. 1800 9.2% Emerg. 1800 56.3% Capture 900 88.9% Emerg. 900 1.4% Emerg. 900 25.3% Capture micro 2.2% PBGT 900 18.3% PBGT 1800 44.8% Capture 900 42%
File FTMDUALB.DOC
Edition 1.0
Page 85
Test Report
Comment : - Micro : The objective of such a scenario is to forbid usage of micro to dual band MS. It is checked here (only 9 handovers). Incoming handovers are due to lack of 1800 cells to capture calls on macro 900 or to rescue emergencies from other layers. - Macro 1800: It confirms that macro 1800 has the highest priority : in any condition (capture, PBGT, emergency), we try to reach this layer. - Macro 900 : It illustrates again bad coverage of 1800 layer : rate of emergencies from 1800 is too high for outdoor conditions. 8.3.4.3 Distribution of emergency handovers
These tables provides for each layer repartition of outgoing emergency handover causes : Dual Band MS Micro Macro 1800 Macro 900 Sample UL Quality 3 208 82 33.3% 4.3% 7.3% DL Quality 66.7% 71.2% 43.9% UL Strength 0.0% 23.1% 45.1% DL Strength 0.0% 1.4% 3.7%
Comments : - Statistics of macro 1800 layer give an explanation of too high number of emergencies mentioned above : 75% of emergencies are due to quality. In outdoor conditions, most of tests were done at REX limit (especially MALARET), with low coverage and high risk of interference with 1800 commercial network. 8.3.4.4 HO efficiency
Statistics will not be provided here but they confirm TEMS problem and its impact handover success rate. 8.3.5 OMC-R counters statistics Analysis of OMC-R counters do not bring any extra information compared to A interface statistics of scenario 2 and comments made for scenario 1.
8.4 CONCLUSION
Major limitation encountered during Toulouse field trial is low coverage ensured by 1800 cells, due to quite complex radio connection with a lot of losses. Thus, results in terms of traffic are quite disappointing. France Telecom has made estimations with a typical Paris 2000 configuration, with following characteristics (by comparison with REX of Toulouse) : - Same GSM900 EIRP (47dBm), - Same intersite distance (500m), - +11 dB for GSM1800 EIRP (56dBm). This table summarizes gain reflected with this increased EIRP outside microcell area : Outdoor Paris Indoor window REX Paris Deep Indoor Paris
REX
REX
File FTMDUALB.DOC
Edition 1.0
Page 86
Test Report
Macro 900 Macro 1800
30% 70%
2% 98%
60% 40%
20% 80%
80% 20%
30% 70%
The main issue is that up to 98% of dual band MS traffic will be supported by 1800 layer in outdoor conditions, up to 70% in deep indoor, with an average of 80%.
File FTMDUALB.DOC
Edition 1.0
Page 87
Test Report
9 RESULTS: BSS OPERATION AND STABILITY

9.1 CONTENT
This part of dual band experimentation report describes the stability and O&M aspects of the BSS during the trial period. It will cover the following aspects: Stability of BTS and BSC, Stability of OMC-R, O&M operation on OMC-R counters, call trace and logical parameters.
9.2 NETWORK STABILITY

General issue is that BSS stability was quite good and problems did never disturbed tests execution or results availability. 9.2.1 BTS and BSC stability In term of hardware instability on BTS, the following failures have occurs on BTS equipment: - 3 CU failures on the same CU of a G2 1800 BTS: the alarm observed was a TX POWER ALARM [6,10]. These failures occurred during night hours and CU goes to FOS: an INIT on the CU was necessary to recover the CU into traffic. - 5 TRE failures on the same Evolium BTS. The problem was observed on the same TRE 900 (HW failure TRGM cause 3) and appears to be a connection problem (bad screwing of the RX antenna on the front panel). - 1 DRFU replacement (after 2 restarts) on a G2 1800. Indeed the restart cause (13) was defined as a HW problem in the alarm dictionary. It is important to notice that the 3 CU alarms occurred always during non-busy hours (zero traffic during night hours): the impacted CU seems to become unstable when it carries no traffic during a long time. Concerning BSC instability, nothing has been detected except one OSI CPRA restart that occurred spontaneously following to a blockage during many hours of the trace invocation process. Trace jobs spontaneously started again following to this restart. TD referenced this problem as software BSC instability. 9.2.2 OMC-R stability General stability of OMC-R was good during all field trial; a problem of "sleeping OSI sleeping process" during night has been detected twice during the 4 weeks: when the problem process occurred, the PM and alarm upload where blocked at OMC-R till an OMC-R action is triggered toward the BSC.
9.3 O&M OPERATION

It is important that this O&M assessment does not include any "network modification" part since CMA and the cell handling functionality's of OMC-R (creation/deletion/template) were not tested by FTM neither by us.
Test Report
No trouble appears when modifying radio parameters except the following point due to know troubles: - TCU reset when creating the 33d HO relationship on a cell (action in restriction at the time being), - Shift in load_factor and free_factor display. 9.3.1 Radio parameters handling When shifting from one step to another, a small set of parameter was to be modified and checked for most of the 18 cells; these radio parameters are described in section 4. However all this radio parameter handling from OMC-R has not been performed neither evaluated by FT but by Alcatel. 9.3.1.1 Cell parameter modification
Cell parameters were easily modified using the "massive parameters download" feature with an appropriate naming of the cells: site-name_sector-number_900 for 900 cells and sitename_sector-number_1800 for 1800 cells. With such a naming, the same parameter can be changed in a one shot command on all the cell of the same frequency band using the '*900' or '*1800' naming for the target cell name in the cell edit-list box. 9.3.1.2 Cell parameter check and comparison
Checking the same parameter between each cell was a regular task that Alcatel had to perform in order to detect or prevent any radio parameter trouble after each parameter step change. Printing and comparing cell parameters are two aspects very uneasy and heavy to handle from OMC-R: - Printing all cell parameters is not possible in a one shot command: four print commands in different windows are necessary to get a paper copy of all cell parameters family: CELL_FACTOR_AND_THRESOLD_HO_DECISION, CELL_POWER_CONTROL_AND_HO_DECISION, CELL_HO_RELATIONSHIPS, and CELL_INFO_ELEMENTS. GND allows to display all these parameters in a single window but printing or dumping these parameters is not possible (!) - No comparison tool exists at OMC-R in order to have a global view of the value of a single cell parameter for all cells of an OMC-R. In order to perform these comparisons between cells we had to use the 'cmd' utility (that allow to use OMC-R expert mode from UNIX - but not delivered to customer) and develop several scripts that dump cell parameter into file in order to compare/print parameter list. 9.3.1.3 Cell handover relationships handling:
A high number of HO relationships was needed for the field trial: 32 relations per cell; this mean that we had to create 576 relations; several parameters linked to HO relationships (priority_0_n, HO_margin_lev, HO_margin_qual) had to be modified for many cells; Since HO relations ships are only modified/created one by one, we used the same 'cmd' utility to perform a massive creation and modification of HO relationships. 9.3.2 Alarm handling ALMSYNT and CPTAL were running without any trouble during the 4 weeks:
File FTMDUALB.DOC
Edition 1.0
Page 89
Test Report
- Daily report produced every night by ALMSYNT and CPTAL, - Weekly report produced every week (Sunday) by CPTAL, These reports were neither analyzed by nor requested by FTM. Indeed, a daily message retrieval was perfomed by FTM people. 9.3.3 OMC-R counters handling OMC-R counters results were not analyzed on a day to day basis by FTM but by Alcatel (please refer to section 5.6). For remind, the following jobs were running: - Raw types 1 to 6 running on all cells from 0h00 to 23h00 with a one hour reporting period, - Raw type 26 and 27 running on micro cell from 0h00 to 23h00 with a one hour reporting period, - Raw type 1 to 6 running from on all cells from 0h00 to 24h00 with a 12 hour period, - Raw type 26 and 27 running on micro cell from 0h00 to 24h00 with a 12 hour period, - OBSTRT and OBSYNT running every night. No trouble occurred during the 4 week except the "sleeping OSI process" trouble (cf. chapter 9.2.2) that blocked PM upload during one day. Consequence was that part of OMC-R counters results were lost due to a result cumulating limited to several hours in the OSI CPR. No other PM jobs (mediated, snapshots...) were launched during the field trial. FTM uploaded all PM counters at the end of the field trial, and used a tool in order to detect counter having a null value on the trial period: result was positive for type 26 and 27 (always at 0) which is normal once the "forced external HO" is set on the impacted cell. 9.3.4 IMSI trace handling IMSI trace results were not analyzed by FTM during the trial. However many IMSI trace were permanently launched from the MSC during the trial. In order to use the IMSI trace, the MET MSC was sending the phase 1 message "TRACE_INVOKATION" instead of "MSC INVOKE TRACE" which trigger generation in the BSC of a call trace file format instead of IMSI trace file format; the result is that IMSI trace result could be handled with the tool TI under UNIX (like a normal call trace result). All handovers have been forced to external on FTM requirement, which means that we had as much trace results files as handovers during each call: due to this, results were uneasy to use: more than 700 result files tracing 6 different IMSI were produced during the field trial.
File FTMDUALB.DOC
Edition 1.0
Page 90
Test Report
10 EVOLUTION OF DUAL BAND SOLUTION

10.1 CONTENT
This document gives the list of the new features in the BSS which are related to the multiband experimentation, whether : - they answer to B5 limitations versus FTM test plan (see section 4), - they answer to FTM requests made following field trial results, - they contain internal improvements suggested following field trial results. For each of these new features, the following aspects will be described : - To what problems or lacks it corresponds in the field (it is described in the Introduction). - A short description of the solution provided by Alcatel. - A technical description of this solution (only for solution implemented in Release B6). - What it brings to operators and in particular to France Tlcom (it is described in the Conclusion). Note that this section deals only with handover algorithms. Other possible improvements have been detected in OMC-R counters area, which are described in section 5.
10.2 MULTIBAND CELL OR SINGLE BCCH CONCEPT (B6)

10.2.1 Introduction Operators are currently looking for solutions allowing to increase the density of their network without increasing the interference level. The best way to increase significantly the traffic capacity of a saturated network is to introduce new frequency channels. A GSM900 operator can introduce GSM1800 frequencies in his network by two ways : - create new GSM1800 cells, using the multiband feature. - introduce new GSM1800 TRXs in existing GSM900 cells, using multiband cell feature. First solution is the one tested in Toulouse, but the second one is preferred by FTM, who intends to implement it in long term. 10.2.2 Short description The solution is provided in Release B6. The easiest way to introduce a pool of TRXs in another frequency band in the same cell is to use the concentric cell feature : - the outer zone, that includes the BCCH, the SDCCH channels and several TCH, will all use frequencies from the original band. - the inner zone, that includes only TCH, will all use frequencies from the new band. Using concentric cell for a multiband cell brings : - TRXs management,
File FTMDUALB.DOC
Edition 1.0
Page 91
Test Report
BCCH and SDCCH recovery management, TCHs assignment by zone, FHS on separate set of TRXs, Interzone handover algorithms,
A mobile in idle mode in the multiband cell will monitor its BCCH in the original band. No BCCH is transmitted in the new band for that multiband cell. At call establishment, the BSS will allocate an SDCCH in the original band (all SDCCHs are in this band). Then, depending on the classmark information sent by the mobile, the level of the radio path and the cell configuration, the BSS will either allocate a TCH in the original band (outer zone), or allocate a TCH in the new band (inner zone). The classmark information is needed to get the multiband capabilities of the mobile. During handover procedure, the specificity of inner and outer zone of the multiband cell (mainly the difference of propagation between the zones) will be taken into account in order to ensure that dual-bands mobiles are in the most adequate frequency band anytime. A multiband cell can be a lower layer cell, a single cell or an upper layer cell. Indeed, the multiband cell is not a cell logical configuration itself (as concentric cell) and thus, it can be applied to any of the existing cell configurations (except the concentric cell). 10.2.3 Technical description 10.2.3.1 Normal assignment in a multiband cell The BSC must check handover cause 13 (see below) while on SDCCH. If cause 13 is fulfilled, if there are free TCH in the inner zone and if the MS is multiband, then the BSC must allocate a TCH in the inner zone. Otherwise, the outer zone is chosen. The cause 13 must take into account the propagation difference between GSM900 and GSM1800. Moreover, it must take into account the maximum transmit power of the BTS and the MS in the two frequency bands. Therefore, two parameters will be used to take these differences into account : ZONE_HO_HYST_DL and ZONE_HO_HYST_UL : CAUSE = 13 (Too high level on the uplink and the downlink, outer zone) AV_RXLEV_UL_HO > RXLEV_UL_ZONE + ZONE_HO_HYST_UL + (MS_TXPWR - MS_TXPWR_MAX_INNER) + PING_PONG_MARGIN(0, call_ref) AV_RXLEV_DL_HO > RXLEV_DL_ZONE + ZONE_HO_HYST_DL + BS_TXPWR - BS_TXPWR_MAX_INNER + PING_PONG_MARGIN(0, call_ref) AV_RXLEV_NCELL_BIS(n) NEIGHBOUR_RXLEV(0,n) EN_BETTER_ZONE_HO = ENABLE
and
and and
These new parameters replace ZONE_HO_HYST. The values for these new parameters will be : ZONE_HO_HYST_DL +/- 10 dB (*)+Pn(outer zone) -Pn(inner zone) (**)+old value of ZONE_HO_HYST
File FTMDUALB.DOC
Edition 1.0
Page 92
Test Report
ZONE_HO_HYST_UL +/- 10 dB (*)+old value of ZONE_HO_HYST (*) : +10 dB if outer zone is GSM900, -10 dB if outer zone is GSM1800 (**) : "Pn(outer zone) - Pn(inner zone)" is added to take into account the difference of the output power of the BTS in the two bands for the evaluation of the downlink power budget. If a TCH in the inner zone is assigned, the CHANNEL ACTIVATION and the ASSIGNMENT COMMAND messages will set the BS power and the MS power to their maximum : BS_TXPWR_MAX_INNER and min(Pinner, MS_TXPWR_MAX_INNER), with Pinner = power capability of the mobile in the inner zone frequency band. 10.2.3.2 Intracell handover in a multiband cell The intracell handover due to high level of interferences (causes 15 and 16), are not impacted : in case of non-hopping channels, the target channel is always on a different TRX than the serving TRX. The target TRX can belong to the same zone as the serving TRX or not. The frequency band of the target TRX must match with the frequency capabilities of the mobile.
Outer zone to Inner zone handover
Cause 13 (see above) is checked while the mobile is in the outer zone. Cause 13 includes ZONE_HO_HYST_DL and ZONE_HO_HYST_UL. If cause 13 is fulfilled, if there are free TCH in the inner zone and if the MS is multiband, then an interzone handover is triggered. The CHANNEL ACTIVATION and the ASSIGNMENT COMMAND messages will set the BS power and the MS power to their maximum : BS_TXPWR_MAX_INNER and min(Pinner, MS_TXPWR_MAX_INNER), with Pinner = power capability of the mobile in the inner zone frequency band.
Inner zone to Outer zone handover
Cause 10 and cause 11 are used, without any change : if the signal decreases in the inner zone, then an emergency handover is triggered towards the outer zone of the cell. Cause 15 and cause 16 (high interference) can also be used to trigger an interzone handover, for example if the inner zone has only one TRX. In case of outgoing intercell emergency handover from the inner zone (ref. Section 3.3.3.1), an handover to the outer zone can occur if the emergency handover is triggered with no neighbour cell available. The CHANNEL ACTIVATION and the ASSIGNMENT COMMAND messages will set the BS power and the MS power to their maximum : BS_TXPWR_MAX and min(Pouter, MS_TXPWR_MAX), with Pouter = power capability of the mobile in the outer zone frequency band. 10.2.3.3 Intercell handover from a multiband cell
Outgoing emergency handover
If the level, the quality or the timing advance get critical while the MS is in the inner zone or outer zone, then an inter-cell handover is triggered towards the best neighbour cell (causes 2, 3, 4, 5, 6 and 7, 17, 18 in a microcell).
File FTMDUALB.DOC
Edition 1.0
Page 93
Test Report
Cell filtering process is changed to take into account the difference of radio propagation when the mobile is in the inner zone : MS in the inner zone : PBGT(n) > HO_MARGIN_XX(0,n) + OFFSET_HO_MARGIN_INNER Else : PBGT(n) > HO_MARGIN_XX(0,n)
In addition, when the mobile is in the inner zone, the serving cell will be added at the end of the target cell list, with an indication to use only channels of the outer zone. This is done to trigger an interzone handover when an emergency handover is triggered with no neighbour cell available. Cell evaluation is not impacted.
Outgoing better cell handover
The better cell handover causes are the following (the new ones are written in Italic, for more information about them, Ref. to Section 10.4) : Power budget handover (cause 12) High level in neighbour lower layer cell for slow mobile handover (cause 14) High level in neighbour cell in the preferred band handover (cause 21) Traffic handover (cause 23) General capture handover (cause 24)
When the MS in the outer zone, these handover causes are not impacted : they are managed as in usual cells. When the MS is in the inner zone, the better cell handover causes, except cause 21, are calculated only towards other cells of same frequency band (as the one of the inner zone) or which have the flag EN_BI-BAND_MS set to enable. This allows to ensure the continuity in the same frequency band and to filter the dual-band mobiles on the other frequency band according to the service type attached to the target cell (corporate or public). Note : the flexibility provided by EN_BI-BAND_MS can also be used in the context of multiband network, without multiband cells. The cause 21 (High level in neighbour cell in the preferred band handover) is managed as usual in the inner zone of a multiband cell. When the MS is in the inner zone, the PBGT must take into account the propagation differences between GSM900 and GSM1800. This will be done by adding an offset OFFSET_HO_MARGIN_INNER, settable by OMC-R, to the usual HO_MARGIN(0,n) when the MS is in the inner zone : Cause 12 (power budget) MS in the inner zone : PBGT(n) > HO_MARGIN(0,n) + OFFSET_HO_MARGIN_INNER and AV_RXLEV_PBGT_HO RXLEV_LIMIT_PBGT_HO and EN_PBGT_HO = ENABLE
File FTMDUALB.DOC
Edition 1.0
Page 94
Test Report
10.2.3.4 Intercell handover to a multiband cell After an incoming handover to a multiband cell, it must be possible to allocate directly the dual-band mobiles in the inner zone, if the radio conditions allow it. For that purpose, the handover cause 13 is checked for downlink level (the only measurement available in case of handover) before allocating a channel in the target multiband cell. The handover detection function will check the cause outer zone too high (cause 13) using the average of the RXLEV_NCELL measurements already received from the target cell (this average will have a maximum window size of A_LEV_HO measurements). It will be taken as the average on downlink level of the serving cell, AV_RXLEV_DL_HO, and the computation will be : If AV_RXLEV_DL_HO > RXLEV_DL_ZONE + ZONE_HO_HYST_DL + (BS_TXPWR_MAX - BS_TXPWR_MAX_INNER) The mobile is supposed to be in the inner zone However, the direct allocation in the inner zone of a multiband cell after incoming handover is possible only in case of BSS internal handover. Indeed, in case of BSS external handover, an incoming HANDOVER REQUEST does not contain the level of the target cell as measured by the mobile (AV_RXLEV_DL_HO). As the target cell cant know if the mobile is in the inner zone or not, any incoming external handover will be sent on the outer zone of the cell. Often, an interzone (interband) handover will be triggered immediately after, to send the mobile to the inner zone. A change to the GSM standard has been proposed by Alcatel to avoid this situation. This modification consists in carrying the target cell level, as measured by the MS, in the HANDOVER REQUIRED and the HANDOVER REQUEST messages. When present, this information will be used by the target BSC as AV_RXLEV_DL_HO. Thus, the target BSC will be able to evaluate if the mobile is in the inner zone or not, and will possibly allocate directly a channel in the inner zone. 10.2.3.5 Evolution of multiband cell The evolutions which are foreseen in the future Releases (after B6) will concern the traffic distribution between different bands of multiband cells. 10.2.4 Conclusion The advantages of the multiband cell feature are : - Easiness of frequency planning, as traffic channels can accommodate a larger level of interference, compared to BCCH channels. Only one strict frequency planning has to be done for the BCCH channels, all frequencies in the new band can have a lighter frequency planning.
File FTMDUALB.DOC
Edition 1.0
Page 95
Test Report
Limit the number of BCCHs. This is important in terms of handover efficiency, because the MS will have less neighbour BCCHs to monitor, so each BCCH will be measured more often. Especially with fast mobiles, a neighbour cell can become the best cell in a very short time. To detect it, the MS should not loose time by measuring numerous frequencies corresponding to all the BCCHs (up to 32 frequencies are allowed to be defined). Easiness of O&M : only one cell is considered instead of two at OMC-R level. Little impact on signalling. For example, the new system information messages SI 2ter is not sent on the air. When coverage of the network has to be increased by installing new BTS sites, the coverage is assured for the old single band mobiles (BCCH frequency) and additional radio resources can be taken in the new band (and will be used by multiband mobiles).
10.3 PRIORITY MANAGEMENT IN MULTIBAND/MULTILAYER NETWORKS (B6)

10.3.1 Introduction During the handover detection process, handover causes are tested following a predefined rank of priority. When one handover cause is triggered, the handover causes with lower priority are never tested, even when the handover with the highest priority cause can not be realised because the target cell is congested. This problem mainly concerns the better cell causes. This problem can prevent better cell causes and cause a bad traffic distribution. It becomes critical in multilayer/multiband network. In the figure below, a mobile in the umbrella cell can be handed over into the microcell or into the 1800 cell. As the handover high level in neighbour cell in the preferred band cause 21 has a higher priority, it is checked first. The 1800 cell is congested, so a handover towards the 900 micro cell is not possible. The mobile stays in the umbrella cell, even if there are free resources in the micro cell. Moreover, in this case, power budget handover between umbrella cells 900 is impossible: only emergency handover can be applied in the umbrella layer.
File FTMDUALB.DOC
Edition 1.0
Page 96
Test Report
GSM900 umbrella cells
3 1
Bi-band mobile
2 1 1
Handover to DCS 1800 cell Handover to microcell Power budget handover
1 2 1 3 1
Saturated GSM1800 Macrocell
GSM900 Microcell
Besides this problem, more flexibility must be provided in the choice of candidate cells when better cell handovers are triggered : first, all the candidate cells for better cell handover must be collected, whatever the cause of better cell handover. These candidate cells must be ordered according to different criteria as their rank of priority, their load and additional weighting factor. 10.3.2 Short description The solution is provided in Release B6. It consists in giving the same priority to the better cell causes (causes 12, 14, 21 and 23) during the handover detection process. Furthermore, a new cause, called the general capture cause (cause 24) is introduced in order to have a general capture mechanism applicable towards any kind of cell. This new cause allows the triggering of capture handover towards as many cells as possible in the same time, because they will all react on the same criteria. The candidate cells obtained by these new processes are ordered according to several criteria, in the same way as they would be triggered by the same handover cause. 10.3.3 Technical description At the Handover preparation level, the handover detection and the handover candidate cell evaluation functions are impacted.
File FTMDUALB.DOC
Edition 1.0
Page 97
Test Report
Handover detection function
The handover detection function will check the cause according to their priority. The better cell causes 12, 14, 21 and 23 will have the same priority. When these causes are checked, all the neighbour cells verifying one of these causes are put in the possible candidate cell list with the corresponding handover cause. The handover causes are checked with the following priority order : Emergency causes : Consecutive bad SACCH frames Level uplink microcell - high threshold Level downlink microcell - high threshold Too low quality Uplink Too low quality Downlink Too low level Uplink Too low level Downlink Too long MS-BS distance Too short MS-BS distance Inner zone too low level Uplink Inner zone too low level Downlink Cause = 7 Cause = 17 Cause = 18 Cause = 2 Cause = 4 Cause = 3 Cause = 5 Cause = 6 Cause = 22 Cause = 10 Cause = 11 Cause = 15 Cause = 16
- Too high interference intracell Uplink - Too high interference intracell Downlink Better condition causes : - high level in neighbour cell in the preferred band - high level in neighbour lower layer cell for slow mobile - Power budget - Traffic handover - General capture handover - Outer zone level Uplink & Downlink - Forced Directed Retry Cause 21, 14, 12, 23 and 24 have the same priority.
Cause = 21 Cause = 14 Cause Cause Cause Cause = = = = 12 23 24 13
Cause = 20
The indication of raw cell list and preferred layer is unchanged. In case of better cell causes, the list of possible candidate cells contains the cells which verify the cause 12, the cause 14, the cause 21, the cause 23 or the cause 24. At the end of the handover detection the list of possible candidate cells with their respective cause and the preferred layer are sent to the handover candidate cell evaluation function.
Handover candidate cell evaluation function
The handover candidate cell evaluation function is not changed in case of emergency handovers or for the cause 20 Forced directed retry. In case of better cell causes 12, 14, 21, 23 and 24, the candidate cell evaluation function shall allow more flexibility to the operators to distribute the traffic between the cells.
Test Report
The ordering of the target cell list (from the higher priority to the lower one) is performed according to the following scheme: Candidate cells whose CELL_LAYER_TYPE = PREF_LAYER { Candidate cells which have the lowest PRIORITY(0,n) { cell ordering according to cell evaluation function } Candidate cells which have the next lowest PRIORITY(0,n) { cell ordering according to cell evaluation function } } Candidate cells whose CELL_LAYER_TYPE <> PREF_LAYER { Candidate cells which have the lowest PRIORITY(0,n) { cell ordering according to cell evaluation function } Candidate cells which have the next lowest PRIORITY(0,n) { cell ordering according to cell evaluation function } } In case of better cell handover causes, PREF_LAYER is almost always set to NONE (it is only used in case of handover of fast mobiles from micro to macrocells). So, the cell ordering is only dependant on the PRIORITY(0,n) and on the cell evaluation function (ORDER or GRADE) which includes load factors, taking into account the load of the serving and neighbour cells and a linkfactor, taking into account the weight of the cell relationship. 10.3.4 Conclusion The better cell handovers are totally flexible in their triggering and execution : every half second, all the cells which are potential candidate cells for a better cell handover are evaluated. Different priorities are applied to favor certain cells. Among cells with the same rank of priority, cells will be ordered by considering together their received level, their load and an additional weighting factor to give a second order of priority. All the priority factors are based on a per couple basis (Priority (0,n) or Link_Factor(0,n)). This brings a complete flexibility in the target cell evaluation. This can be illustrated in the following figure : coming from the 900 macrocell called A, the 1800 cell B has a higher priority than the other neighbour cells. As long there is room in the cell B, it is chosen as a target cell. When cell B becomes saturated, all the other cells with a lower priority are evaluated. Cells with the same priority (in the example below 1800 cell C and microcell D) are ranked depending on their respective level and their load, with Link_factor being used as a weighting factor to favor one or the other cell.
Test Report
900 umbrella cell
A
1 1800 cell
D
900 micro cells
10.4 TRAFFIC MANAGEMENT IN MULTI LAYER AND SINGLE LAYER (B6)

10.4.1 Introduction Release B5 has been designed in order to allow cellular operators to introduce quickly and simply the multiband operation in their networks. In this Release it is considered that the share of Multiband Mobiles in the network is quite low. That is the reason why the main strategy consists in allocating most multiband mobiles in the 1800 cells. In the following Releases, the share of Multiband mobiles in the network may significantly increase. Thus these Releases must bring improvements in the capture handover in order not to saturate the cells of preferred band. Moreover, new algorithms have been developed in order to ensure traffic distribution in each layer. 10.4.2 Short description The solution is provided in Release B6. Main modifications concern : - the load in the 1800 cells : the load in the 1800 cells which are candidate cells for capture handover is taken into account. An 1800 cell which is very highly loaded will not be a suitable target cell for a capture handover. - A new handover cause (cause 23) is defined in order to trigger traffic handover within one layer. The traffic handover is based on the observation that it is a frequent situation, in dense areas, to observe several cells which are completely saturated when their neighbour are still almost empty. The aim of the intelligent traffic handover is to distribute the traffic among the neighbour cells. An important issue in the traffic management is to obtain very reliable estimations of the load in the cells. That is the reason why the Alcatel algorithm detects long peaks (about 10 minutes of high traffic), rather than instantaneous peaks.
Test Report
10.4.3 Technical description In order to detect long peaks situations, the decision process shall give long term estimations : It means that the decisions will be taken from a specific averaging, giving reliable decisions but requiring long evaluation period. The final decision will be represented by a variable called Traffic_load which can have the following values : high, low and indefinite. Starting from these decisions, the algorithms are expected to be triggered (or to have their behaviour changed) for a continuous and noticeable period, until a new decision is taken. The decision process proposed to perform such a task is described in the following diagram.
Thresholds
Load Samples
Averaging according to A_TRAFFIC_LOAD
AV_TRAFFIC _LOAD
Threshold comparison with N_TRAFFIC_LOAD averages
Traffic_load
This decision process is divided into two steps : the first one corresponds to what is currently implemented : load samples (corresponding to the number of busy traffic channels divided by the total number of traffic channels) are received regularly (with a periodicity of 5 seconds). The load samples are averaged with a non-sliding window whose size is equal to a parameter called A_TRAFFIC_LOAD. This parameter is changeable on a per cell basis. The obtained average is recorded in the variable AV_TRAFFIC_LOAD. The second step is new and it allows the definition of Traffic_load. Its principle is to consider N_TRAFFIC_LOAD consecutive averages AV_TRAFFIC_LOAD and to compare each of them to load thresholds. The information Traffic_load will be set to its possible value (high, low and indefinite) according to this threshold comparison.
There are three load thresholds, each of them defining the different states of Traffic_load : - One called HIGH_TRAFFIC_LOAD, which corresponds to the decision Traffic_load = high - Another called LOW_TRAFFIC_LOAD, which corresponds to the decision Traffic_load = low - A last one, called IND_TRAFFIC_LOAD, which corresponds to the decision Traffic_load = indefinite. IND_TRAFFIC_LOAD is between HIGH_TRAFFIC_LOAD and LOW_TRAFFIC_LOAD. It can be disabled by tuning it to 0%. The information Traffic_load is applied in the capture handover cause 21 and for the traffic handover cause 23 in the following way :
For the cause 21 : CAUSE = 21 (high level in neighbour cell in the preferred band) Traffic_load(0) = MULTIBAND_TRAFFIC_CONDITION
File FTMDUALB.DOC
Edition 1.0
Page 101
Test Report
and Traffic_load(n) <> HIGH and AV_RXLEV_NCELL(n) > max(0,[MS_TXPWR_MAX(n)-P]) and EN_MULTIBAND_HO = ENABLE
L_RXLEV_CPT_HO(n)
MULTIBAND_TRAFFIC_CONDITION is a parameter changeable on a per cell basis. It can have three different values : ANY_LOAD : the condition on traffic load is always fulfilled NOT_LOW : the condition on traffic load is fulfilled only if traffic_load <> low HIGH : the condition on traffic load is fulfilled only if traffic_load = high
For the Traffic handover :
The management of traffic handover is performed through three aspects : Modification of the cause Power Budget only for handovers from TCH to TCH and directed retry from SDCCH to TCH (the cause 12 is unchanged for handover from SDCCH to SDCCH)
CAUSE = 12 (Power budget evaluation) IF EN_TRAFFIC_HO(n,0) = ENABLE PBGT(n) > HO_MARGIN(0,n) +max(0, DELTA_HO_MARGIN(0,n)) ELSE PBGT(n) > HO_MARGIN(0,n) and EN_PBGT_HO = ENABLE with PBGT(n) = AV_RXLEV_NCELL(n) - AV_RXLEV_PBGT_HO - (BS_TXPWR_MAX - BS_TXPWR) - (MS_TXPWR_MAX(n) - MS_TXPWR_MAX) - PING_PONG_MARGIN(n,call_ref)
(n=1...BTSnum)
Creation of the cause Traffic handover
CAUSE 23 : Traffic HO DELTA_HO_MARGIN(0,n) < 0 dB and PBGT(n) > HO_MARGIN(0,n) + DELTA_HO_MARGIN(0,n) and EN_TRAFFIC_HO(0,n) = ENABLE
(n=1...BTSnum)
- Definition of the value of DELTA_HO_MARGIN(0,n) according to the traffic situation of the serving cell and the neighbour cell n. If traffic_load(0) = high and traffic_load(n) = low, DELTA_HO_MARGIN(0,n) = - DELTA_DEC_HO_margin If traffic_load(0) = low and traffic_load(n) = high, DELTA_HO_MARGIN(0,n) = DELTA_INC_HO_margin else DELTA_HO_MARGIN(0,n) = 0.
File FTMDUALB.DOC
Edition 1.0
Page 102
Test Report
10.4.4 Conclusion New algorithms allow better distribution of traffic in multilayer and single layer network in order to avoid saturation of preferred band cell and local saturation due to traffic heterogeneity. These algorithms are based on reliable traffic estimations which prevent pingpong handovers.
10.5 PUBLIC AND CORPORATE MICROCELLS WITHIN THE SAME NETWORK (B6)
10.5.1 Introduction In a multiband network, FTM foresees to have different types of microcells : Corporate microcell where all dual-band mobiles would have automatically access and public microcell where the acces would be restricted to the case where the GSM1800 cell are no longer available. 10.5.2 Short description The solution is provided in Release B6. In fact, there are two solutions which are the followings : In case of multiband network, the capture handover from a macro 1800 cell and a microcell can be enabled/disabled by the use of the parameter L_RXLEV_CPT_HO(0,n) : Towards a corporate microcell, this parameter can be set to a normal value, so as to capture dual-band mobiles when possible. Towards a public microcell, this parameter shall be set to an inhibiting value (typically, 47 dBm), so as to prevent dual-band mobiles from leaving the macro 1800 cell. In case of multiband cells network, it is not possible to use L_RXLEV_CPT_HO(0,n) because it is on a per cell basis and not on a per frequency band basis in the multiband cell. In this case, another parameter called EN_BI-BAND_MS is used to allow on a per microcell basis the capture of dual band mobiles from the 1800 part of the multiband cell : Towards a corporate microcell, EN_BI-BAND_MS = TRUE, the dual-band mobiles are captured from the 1800 part of the multiband cell, according to the capture threshold L_RXLEV_CPT_HO(0,n). Towards a public microcell, EN_BI-BAND_MS = FALSE, the dual-band mobiles cannot be captured by the microcell when they are on the 1800 part of the multiband cell. Note : Of course, EN_BI-BAND_MS can be used in a multiband network, towards macro 1800 cell. In this case, it can simplify the declaration of a microcell as a corporate microcell (no need to change all the adjacencies between this microcell and the macro 1800 cells above).
File FTMDUALB.DOC
Edition 1.0
Page 103
Test Report
10.5.3 Technical description In the checking of the cause 14, the possibility for a dual-band mobile to be handed over to a microcell from preferred band can be enabled/disabled through a flag per microcell. If the MS is in the inner zone of a multiband cell with CELL_LAYER_TYPE = upper, the cause 14 is checked over all the neighbour cells with CELL_LAYER_TYPE(n) = lower except the ones with EN_BI-BAND_MS(n) = DISABLE and CELL_BAND_TYPE(n)=CELL_BAND_TYPE of the multiband cell. If the MS is in a cell with CELL_BAND_TYPE = PREFERRED_BAND and CELL_LAYER_TYPE = upper, the cause 14 is checked over all the neighbour cells with CELL_LAYER_TYPE(n) = lower except the ones with EN_BI-BAND_MS(n) = DISABLE and CELL_BAND_TYPE(n) <> PREFERRED_BAND. In all the other cases if CELL_LAYER_TYPE = upper, the cause 14 is checked over all the neighbour cells with CELL_LAYER_TYPE(n) = lower. CAUSE = 14 (high level in neighbour lower layer cell for slow mobile) and and AV_RXLEV_NCELL(n) > L_RXLEV_CPT_HO(0,n) MS_SPEED = slow EN_MCHO_NCELL = ENABLE n = (1...BTSnum)
10.5.4 Conclusion The handover algorithms give all the flexibility in release B6 to define both public and corporate microcells in a multiband network or a multiband cell network. In the future release, Alcatel handover algorithms will evolve in this direction of handling different types of users (public users vs. private users) with different access rights.
10.6 DIRECTED RETRY WITHOUT CONGESTION (B7)

10.6.1 Introduction In multilayer/multiband network, it can be interesting to perform traffic distribution before TCH allocation, i.e. when the MS is performing the assignment procedure on SDCCH. This can be achieved through directed retry procedure. In this case, it should be applied even when no congestion occurs in the serving cell and it should consider all the traffic handover algorithms available during communication. 10.6.2 Short description The solution is proposed for B7. The solution is provided through a new feature called Traffic load management. This feature has two purposes : - Accept more easily incoming emergency TCH handovers in loaded cell - Distribute the traffic with incoming TCH assignments.
File FTMDUALB.DOC
Edition 1.0
Page 104
Test Report
It consists in preventively queuing the incoming assignments when the cell load has reached a specific threshold. This allows to temporarily reserve some free resources for incoming emergency TCH handovers and to check if the incoming assignments could not be handled by another cell, in terms of traffic distribution. Some simulations show some very good results for the first item as it has been proved that 50% of the handover failures (all handover types are considered) can be avoided while queuing only 15% more of assignments. Moreover, the traffic load management feature is also linked to the service management in the sense that incoming assignments are preventively queuing differently whether they are Mobile Originating or Mobile Terminating and whether they have a high priority or not. 10.6.3 Conclusion The traffic load management feature is a good answer to the request from France Tlcom as it not only allows better and earlier traffic distribution but it also improves in a strong way the management of emergency handovers in loaded networks.
10.7 ANTI PING-PONG MECHANISM IN MULTILAYER NETWORKS (B7)

10.7.1 Introduction In multilayer/multiband network, capture handovers should take into account the history of calls, that is to say if the call has just performed an emergency handover from the cells where it should be captured, the capture handover should no longer be triggered. This will prevent ping-pong handovers between capture handover and emergency handover. It is quite important because thats precisely the calls which are in emergency situations which should be handled with care. 10.7.2 Short description The solution is proposed in B7. The solution consists in blocking all capture handovers for calls whose last handover was a emergency handover on too low quality. This allows to ensure good quality for calls which had problems about it. Moreover, this solution can be applied also in case of inter-BSS handover, while taking into account the A interface cause contained in the HANDOVER REQUEST received by the target BSS. 10.7.3 Conclusion A simple and flexible solution will be provided to apply anti ping-pong mechanism in multilayer networks. This solution will be applicable in the whole network, within BSSs and between BSSs.
File FTMDUALB.DOC
Edition 1.0
Page 105
Test Report
11 GUIDELINES FOR DUAL BAND FIELD TRIAL

11.1 CONTENT
The aim of this section is to give guidelines for a dual band field trial. It has been requested by operations management : main idea is to be able to reproduce quickly a successful field trial using the experience of FTM field trial. It will cover the following aspects : Resources and skills, Test and monitoring tools, Possible network configuration (adapted to existing network), Equipment (BSS and radio), Test domains with inputs for planning.
11.2 SKILLS AND RESOURCES

11.2.1 Skills Field trial team shall be made of following skills : - parameters and radio - It requests good knowledge of radio algorithms (handover, power control, ...), and especially those concerning dual band (B5). He must obviously have a good knowledge of the radio configurations used, and a experience in radio fine tuning and radio engineering (power budget, antennas, ...). - quality of service and protocol - It requests a good knowledge of GSM protocols in order to analyse the different interfaces, if any problem occurs. It also requests a good knowledge of quality of service follow-up tools and methods, in order to collect and analyse QoS results. Common work with parameters and radio expert is necessary to analyse results and get inputs for fine tuning. - BSS technical support - Such an expertise is needed to support BSS start-up and make link between installation teams and people who will make field trial. B5 expertise is a must but is not absolutely necessary, as it is quite close to release B5 in terms of equipment and configuration. - NSS interworking - This is an important issue, especially if BSS is connected to a commercial NSS. Many problems occurred in this area in Toulouse, and presence of such an expert (CNET) has been helpful. This people shall be able to discriminate BSS from NSS problems and manage interface with NSS people. - OMC-R exploitation - He is in charge of BSS exploitation : fault management, logical configuration modifications, and also of PM counters activation and collection. - Radio measurers - They are in charge of making radio coverage tests (with trace mobile application), and generating traffic on experimental network.
File FTMDUALB.DOC
Edition 1.0
Page 106
Test Report
This list does not contain people involved in installation and commisionning tasks. 11.2.2 Resources This table resources involved in field trial on these skills (only during field tests) : Skill parameters and radio quality of service and protocol BSS technical support NSS interworking OMC-R exploitation Radio measurers Alcatel 1 1,5 1 1 1 FTM 1 1 2
Resources allocated shall depend on local teams knowledge. Indeed, radio measurers, BSS technical support and OMC-R exploitation could be people of local support. With such case, 2 specific resources are necessary for such a field trial.
11.3 TOOLS
It is necessary to have following tools : Set of single (phase 1, phase 2) and dual band mobiles (Motorola 8900, Bosch, Ericsson), Trace dual band mobiles like Motorola 8900, Air interface tool like TEMS (Ericsson tool) or Surveyor, DAFNE, AGLAE, DICO.
Usage of these tools will depend of type of tests : - Commercial mobiles are used to generate traffic. The number of mobiles depends on the kind of tests (high traffic load or not). For instance, in Toulouse, about 7 single band (Siemens 900 MHz) and 10 dual band mobiles were available. For tests with important traffic conditions, much more mobiles must be available (which are quite expensive at the moment). - Commercial dual band mobiles with trace facility were available and supplied by FTM. Getting such MS is very helpful for check quickly MS/Network behaviour (especially know serving cell). Such MS are unfortunately not available for Alcatel : getting them may be possible for an operator. - Trace mobiles are useful for radio coverage tests. At the end of 1998, a version of A954 with dual band capabilities will be available. There is perhaps a solution with SAFCO. Another possibility may be to buy the TEMS tool when it will be available (TEMS used in Toulouse was a prototype). - DAFNE is useful for radio fine tuning if there is enough traffic. This was not the case in Toulouse. - AGLAE is the most useful post-processing tool, thanks to split between single and dual band MS which has been implemented. Handovers shall be forced to external to get more information.
File FTMDUALB.DOC
Edition 1.0
Page 107
Test Report
DICO is not useful if there is not enough traffic. If enough traffic is generated by dual band mobiles only (it is not possible to distinguish single band mobiles from dual band mobiles) DICO can bring interesting data.
11.4 CONFIGURATIONS
11.4.1 Network context Taking into account network context is first input to define configuration for field trial. There are two cases to consider for dual band networks: - existing single band network with introduction of a new frequency band, - new dual band license. Only the first case will be detailed for configuration definition approach, but resulting configuration could be used for second one. There are two possibilities as for the layer corresponding to the new frequency band : - introduction of macro cells (antennas above the roofs) - introduction of micro cells (antennas under the roofs). Moreover, there are two possibilities as for the supplier : - use of the same supplier for all the layers of the network - use of a new supplier for the new frequency band leading possibly to interworking problems. 11.4.2 Existing network : possible configurations It is sensible to think that before the introduction of a new frequency band the operator has worked a lot in order to take full advantage of the old frequency band. In dense areas, the network is normally made up of two layers : macro cells and micro cells. At this point the operator may decide to introduce a third layer working in the new frequency band. There are mainly two possibilities : - introduction of macro cells - introduction of micro cells. In order to reduce the costs (site acquisition and equipments (BTS, Abis links)) and deployment duration it is sensible to choose the co-site installation solution. 11.4.2.1 Introduction of macro cells This solution has been used in Toulouse. For a field trial, 9 macro cells (old frequency band, 3 sites), 9 macro cells (new frequency band, 3 sites), and 1 micro cell (old frequency band) are sufficient. When micro layer is in test scope, it is recommended to rather use 3 micro cells in order to study the speed discrimination process and test intra micro layer handover. In any case, parameters sets which has been used in Toulouse can be re-used. Please, refer to section 4.
File FTMDUALB.DOC
Edition 1.0
Page 108
Test Report
Note that the case with no micro layer is available is obviously a special case of the case with 3 layers and same parameters can be used. 11.4.2.2 Introduction of micro cells The figure below gives the configuration of the cells for the introduction of a micro 1800 layer in a network made up of a macro 900 and a micro 900 layer. It also shows better condition handover causes.
Cause 12 Cause 12
m a cro 900 Cell dimension type = macro Cell layer type = upper
Cause 14 micro 900 Cell dimension type = micro Cell layer type = lower L_RXLEV_CPT_H O (n) = -85 dBm
Cause 12
Cause 12
Cause 21 micro 1800 Cell dimension type = micro Cell layer type = lower L_RXLEV_CPT_H O (n) = -85 dBm Cause 12
Remarks : - cause 14 must be used between macro 900 and micro 1800 cells to take into account the MS speed, - PRIORITY(0,n) gives a higher priority to micro 1800 cells than to micro 900 cells. The case with one micro layer is obviously a special case of the case with 2 micro layers and same parameters can be used. As for the number of cells, it is recommended to have at least 3 (in order to be able to test the speed discrimination process) micro 900 cells, 3 micro 1800 cells and all the umbrella cells (macro 900) of these micro cells. 11.4.3 Existing network : use of various suppliers We can imagine the case of a network built with macro cells of a supplier A working in frequency band 1. In order to improve the capacity of the network, the operator may introduce macro cells (certainly co-located with macro cells A) of a supplier B working in frequency band 2 (new frequency band).
File FTMDUALB.DOC
Edition 1.0
Page 109
Test Report
In such a case an inter-band handover is an inter-BSC handover and it is impossible to take full advantage of handover algorithms. For example, it is not possible to take into account the traffic load of target cells in the candidate cell evaluation process. In such a situation it is also absolutely necessary to make interworking tests between the two BSS. Indeed, an important problem in a dual band network is the ability to know the capabilities of a mobile (frequency bands and power class in each frequency band). Normally a dual band BSS is able to understand the Classmark 3 information when it receives it. It is also able to ask a mobile to send this information with the Classmark enquiry process.
11.5 TESTS
Whatever the case, it is very interesting to consider these five test domains : - the radio coverage in each frequency band - the behaviour of handover algorithms thanks to deterministic test - the behaviour of the network without congestion thanks to statistical tests - the behaviour of the network in case of high traffic load thanks to statistical tests - interworking. These test domains may be tested for the two basic scenarios identified by FTM (corporate or public microcells). 11.5.1 Radio coverage First test domain is to study the coverage in each frequency band, the difference of signal strength between the different frequency bands and indoor penetration losses. Indeed, the efficiency of a dual band network is obviously linked to the overlapping between the two frequency bands. 11.5.2 Behaviour of the handover algorithms Second test domain is to demonstrate thanks to deterministic tests the good behaviour of handover algorithms (for instance, demonstration of the possibility to give a higher priority to a given layer using the parameter PRIORITY(0,n)), for various cases : idle mode (selection, reselection), connected mode (call set-up, handover). 11.5.3 Behaviour of the network without congestion The aim of this part is to obtain the distribution of mobiles when there is no congestion (there are always free resources in the target cell). Here the distribution of mobiles between the different layers is only due to radio coverage and radio algorithms parameters. 11.5.4 Behaviour of the network in case of high traffic load This advanced test domain, which will be costly, is interesting in order to : - simulate a network with a high rate of dual band mobile, - study the behaviour of handover algorithms in case of congestion, - collect inputs for QoS follow-up and radio fine tuning in such networks. 11.5.5 Interworking tests Interworking is an important issue of dual band field trial. Such tests must be foreseen to demonstrate proper interworking with specific cautions for single band network.
Test Report
Following table gives a first estimate of the time necessary for each family of tests. For tests done in Toulouse, test duration has been validated on field. Tests family Radio coverage Algorithms and protocol Statistical tests without congestion High traffic tests Interworking Toulouse No Yes Yes No Yes Scenario Dependent No Yes Yes Yes No Duration per Scenario (days) 2 3 3 5 1
11.6 EQUIPMENTS
11.6.1 BTS During FTM field trial, Evolium BTS were used for 900 MHz cells and G2 BTS for 1800 MHz cells. It was due to non availability of Evolium 1800 in field trial timeframe. New equipments shall be foreseen as soon as they are available : - Evolium 1800 BTS (available now). - Multiband BTS (planned for B5.1), i.e. with 900 and 1800 sectors. Typical configuration for tri-sectorized sites would be 6x2. 11.6.2 Radio equipments In the case of an existing network and when the operator chooses the co-site installation solution, it is very useful to use diplexers in order to re-use existing feeders for 900 MHz and 1800 MHz cells. Sofrer, Filtronic and Celwave provide such equipment. Antennas : in order to reduce the number of antennas, it is very interesting to replace existing antennas by dual band antennas (DAPA, Celwave, Kathrein). There are also dual band crosspolar antennas (DAPA).
END OF DOCUMENT
File FTMDUALB.DOC
Edition 1.0
Page 111

FTMDUALB

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FTMDUALB

Uploaded by

Copyright:

Available Formats

FTM Dual Band Field Trial

France Telecom Mobiles DUAL BAND FIELD TRIAL

Emergency HO Forced DR Capture HO Cause 21

Dual-band mobile Capture HO Cause 14

Mono-band mobile Emergency HO Forced DR

GSM1800 Macrocells unbarred

PBGT HO GSM1800 Macrocell from a mono-band BSS Emergency HO Forced DR

Forced DR Capture HO Cause 14

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98

FTM Dual Band Field Trial

CHANGE HISTORY Version 1.0 Date 30/07/98 Nature of Change Creation

Approval Name Signatur e Name Signatur e H Derrey C Guetin

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98

FTM Dual Band Field Trial

1.2.2 Planning and resources ........................................................................................................... 9

3.4 NETWORK PERFORMANCE MONITORING ....................................................................................... 27 4

Alcatel CIT Mobile Communication Division

FTM Dual Band Field Trial

4.5.2 Connected mode ................................................................................................................... 43

5.2.2 Other mobiles ....................................................................................................................... 47

8.1 TESTS DESCRIPTION ...................................................................................................................... 73

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98

FTM Dual Band Field Trial

8.1.1 Test method.......................................................................................................................... 73

8.1.2 Collected results ................................................................................................................... 73

8.1.3 Test routes............................................................................................................................ 74

9.2.2 OMC-R stability..................................................................................................................... 88

9.3 O&M OPERATION........................................................................................................................... 88 9.3.1 Radio parameters handling ................................................................................................... 89

10.4.2 Short description.................................................................................................................100

Alcatel CIT Mobile Communication Division

FTM Dual Band Field Trial

10.4.3 Technical description ..........................................................................................................101

10.4.4 Conclusion ..........................................................................................................................103

10.6.2 Short description.................................................................................................................104

10.6.3 Conclusion ..........................................................................................................................105

10.7.2 Short description.................................................................................................................105

10.7.3 Conclusion ..........................................................................................................................105

11.2 SKILLS AND RESOURCES........................................................................................................106 11.2.1 Skills ...................................................................................................................................106 11.3

11.2.2 Resources............................................................................................................................107 TOOLS ..................................................................................................................................107

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98

FTM Dual Band Field Trial

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98

FTM Dual Band Field Trial

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98

FTM Dual Band Field Trial

FIELD TRIAL PROJECT PRESENTATION

1.2 FTM FIELD TRIAL OBJECTIVES

FTM Dual Band Field Trial

1.3 ALCATEL PROJECT PRESENTATION

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98

FTM Dual Band Field Trial

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98

FTM Dual Band Field Trial

Alcatel CIT Mobile Communication Division

Reference Date 3DF 00973 0001 QZZZA 24/07/98