system verification dn0691365x1x0xen

Nokia MetroSite EDGE Base Station

System Verification Regression Specification for Validating BTS SW Release CXM5

DN0691365 Issue 1-0 en

© Nokia Corporation Nokia Proprietary and Confidential

1 (107)


The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia's customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia and the customer. However, Nokia has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia will, if necessary, explain issues which may not be covered by the document.

Nokia's liability for any errors in the document is limited to the documentary correction of errors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright according to the applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2007. All rights reserved.

Hereby, Nokia Corporation declares that this Nokia Base Station is in compliance with the essential requirements and other relevant provisions of Directive: 1999/5/EC. The product is marked with the CE marking and Notified Body number according to the Directive 1999/5/EC.

2 (107) © Nokia Corporation Nokia Proprietary and Confidential

DN0691365Issue 1-0 en

Contents

Contents

1 Vocabulary..............................................................................................6

2 About this document .............................................................................8 2.1 Scope .......................................................................................................8 2.2 Prerequisites ............................................................................................8 2.3 Hardware requirements............................................................................8 2.4 Software requirements ...........................................................................10 2.5 Specialist test equipment requirements .................................................10 2.6 Common notes.......................................................................................11

3 Object control and radio network management................................15 3.1 Common BCCH on simple MetroSite configuration ...............................15 3.2 Common BCCH on chained MetroSite configuration .............................17 3.3 Recovery after power breakdown...........................................................20 3.3.1 Simple MetroSite configuration ..............................................................20 3.3.2 Chained MetroSite Configuration ...........................................................21 3.4 BSS restart .............................................................................................22 3.5 Background radio network update..........................................................22 3.6 Backup of system data ...........................................................................23 3.7 Repeated BCF Reset .............................................................................24

4 Alarm handling .....................................................................................27 4.1 TRX failures ...........................................................................................27 4.1.1 TRX removed from Simple Configuration...............................................27 4.1.2 TRX removed from Chained Configuration ............................................29 4.1.3 Slave TRX installed with incorrect Frequency Band ..............................31 4.1.4 All slave TRXs and the Antenna Cable of the Master TRX

removed .................................................................................................31 4.2 Unit failures ............................................................................................32 4.2.1 VIFA removed from cabinet....................................................................32 4.2.2 Fan unit removed from chained MetroSite .............................................32 4.2.3 Cabinet cover removed from BTS cabinet .............................................33 4.2.4 Extension cable removed from chained MetroSite.................................34 4.3 Antenna cable detection.........................................................................34 4.3.1 Antenna cable removed from the master BCCH TRX............................35 4.3.2 Antenna cable removed from all TRXs...................................................36 4.3.3 Antenna cable removed from the slave TCH TRX .................................36 4.3.4 Antenna cable removed from the master of slave cabinets ...................37 4.4 LAPD failure ...........................................................................................38 4.4.1 LAPD blocked with MML command .......................................................38

4.4.3 Repeated LAPD Block/Unblock..............................................................40 4.4.2 BER introduced ......................................................................................40

4.5 RX antenna supervision by comparing RSSI value................................41 4.6 Alarm correlation for simple MetroSite configuration..............................42 4.7 Alarm correlation for chained MetroSite configuration ...........................44



3 (107)


5 BTS Manager functionality ................................................................. 50 5.1 External Devices and Filter Alarms Commands .................................... 50 5.2 BTS Configurations and Site Information .............................................. 52 5.3 Abnormal TRX in the configuration........................................................ 53 5.3.1 TRX not commissioned ......................................................................... 53 5.3.2 TRX not defined at the BSC .................................................................. 54 5.3.3 TRX does not exist in the cabinet.......................................................... 54 5.4 External alarms and controls ................................................................. 55 5.5 TRX Test during BB Hopping ................................................................ 56 5.6 TRX Test during TRX in configuring mode............................................ 57

6 Remote BTS Manager ......................................................................... 60 6.1 Multiple Remote BTS Manager sessions for different BTSs ................. 60 6.2 Remote Transmission Manager traffic................................................... 60 6.3 Remote BTS link failures ....................................................................... 61 6.3.1 Link between BTS and BTS Manager removed .................................... 61 6.3.2 BER introduced ..................................................................................... 62 6.3.3 Delay introduced.................................................................................... 62 6.4 Re-establishing the BCF connection ..................................................... 63 6.5 Dynamic Abis EDAP pools update on Multiple remote BTS

Managers............................................................................................... 65 6.6 Alarm handling....................................................................................... 66 6.6.1 Slave TCH TRX removed ...................................................................... 66 6.6.2 Antenna cable of Master TRX removed ................................................ 67 6.7 Transmission menu commands............................................................. 68 6.8 Stability test for Remote BTS Manager ................................................. 69 6.9 Multiple instances of Remote BTS Manager using the Node

Manager ................................................................................................ 69 6.10 Adjusting the DAC Word........................................................................ 70

7 Intelligent Shutdown for MetroSite .................................................... 72 7.1 Repetitive intelligent shutdown testing .................................................. 74 7.2 TRX test................................................................................................. 75 7.3 Abis loop test from BSC ........................................................................ 76 7.4 BTS Manager connected to site in shutdown mode .............................. 76 7.5 Alarm handling during the BCCH shutdown mode ................................ 77 7.6 Intelligent shutdown while alarms present............................................. 79

8 Recovery for BSS and Site Synchronisation .................................... 80 8.1 Site Synchronisation: BCF reset............................................................ 80 8.1.1 Clock Source – Talk .............................................................................. 80 8.1.2 Clock Source - LMU .............................................................................. 84 8.2 Recovery from sync failures on initialisation.......................................... 86 8.3 Sync recovery when GPS fix never achieved on initialisation ............... 88 8.4 Sync recovery - missing GPS signal ..................................................... 90 8.4.1 GPS signal lost for less than LMU timer period..................................... 91 8.4.2 GPS signal lost for more than LMU timer period ................................... 93 8.5 Sync recovery – missing clock cable for slave MetroSite...................... 96



Contents

9 Multi-BCF for MetroSite .......................................................................99 9.1 Multi-BCF Functionality ..........................................................................99 9.2 Multi-BCF start-up order.......................................................................104

References ..........................................................................................................107 \



5 (107)


1 Vocabulary The following abbreviations are specific to this document.

BBU Battery Backup Unit

BCF Base Control Function

BSC Base Station Controller

BTS Base Transceiver Station

FR Full Rate

EFR Enhanced Full rate

HR Half Rate

GMSK Gaussian Minimum Shift Keying

GSM Global System for Mobile Communication

GPRS General Packet Radio Switching

EGPRS Enhanced GPRS

EDGE Enhanced Data Rates for GSM Evolution

HW Hardware

ICE+ Intelligent Coverage Enhancement Plus

ITN Integrated Transmission Node

IUO Intelligent Underlay Overlay

MMI Man Machine interface

PSK Phase Shift Keying

SW Software

TCH Traffic Channel

TRX Transceiver

LMU Location Management Unit



Vocabulary

FTP File Transfer Protocol

UDP User Datagram Protocol

MCS Modulation Coding Scheme

UALC User Access Level Control

RF TA Radio Frequency Timing Advance Rigs

NEE Network Element Emulator

IR/LA Incremental Redundancy/Link Adaptation.

DFCA Dynamic Frequency and Channel Allocation

RSSI Received Signal Strength Indication

HO Handover



7 (107)


2 About this document 2.1 Scope

This document defines the system test phase and defines the test cases for verifying the regression features of the BTS software release CXM5 for the MetroSite base station. In general the features and test cases described herein are intended for Nokia GSM 800, 900, 1800 and 1900 band environments.

2.2 Prerequisites

Before the release testing can begin, there must not be any open fatal or major faults found from the ongoing SW integration testing phases.

2.3 Hardware requirements

Base Stations One of the following BTS configurations will be used for the test cases covered in this document.

• 2+2 GSM/EDGE

• 2+2 EDGE

• 2+2 GSM

• Omni GSM/EDGE

• Omni EDGE

• Multi TRX EDGE



About this document

• Multi TRX GSM

• 2+2 GSM+EDGE

• 1+1+1+1

• 2 GSM

• 1 TRX

• 4 Omni GSM

• Multi TRX GSM/EDGE

• 4+4+4 EDGE Chained Configuration

• 4+4+4 GSM+EDGE+GSM/EDGE Chained Configuration

• 4+4+4 GSM Chained Configuration

• Talk + MetroSite

• LMU + MetroSite + MetroSite

• Talk + MetroSite + MetroSite

• LMU + Talk + MetroSite

Other Network Elements • BSC

• Core Network with GPRS and EDGE capabilities.

Mobile Stations

Feature Specific options

Speech channels FR, HR, EFR

Single data channels 9600, 14400 non-transparent

Multi-slot data channels 9600 or 14400 non-transparent using 1+1, 2+2 or 3+1 timeslots

GPRS Class B and Class C, multi, PBCCH support

EGPRS Class B and Class C, multi, PBCCH support

EGPRS channel request on PBCCH and BCCH

Adaptive Multi-Rate AMP FR and HR

General SMS Mobile Originating (MO) and Mobile Terminating (MT)

Enhanced Measurement Reports

EMR Capable



9 (107)


2.4 Software requirements

• SiteWizard 5.0

• GCS R5.0

• Latest available Test Packet or Pre-Release of CXM5

• BTS Manager PC (running Windows 2000, Windows XP or Windows 98), Win2000 / Win2003 Node Manager Server.

• SW versions of the other network elements are detailed in [Table 2].

Table 1. SW versions of other network elements

Network Element SW Version

BSC S11, S11.5, S12

Nokia NetAct OSS 3.1 ED3, OSS4

LMU LMU 4.4, LMUB 1.0

SGSN SG3.1, SG4.0

Transmission (FXC E1, FXC E1/T1, FXC RRI, FC STM-1)

ITN C1.0, ITN C2.1-2, ITN C2.2, ITN C3.0

Transmission (FC E1/T1) ITN C1.0

Transmission (MetroHub) MHB C2.1, C2.2, C3.0

BTS Manager PC Windows 98, Windows 2000, Windows XP, Windows NT

PC Applications • Internet browser

• FTP, UDP software

• Terminal Emulator

2.5 Specialist test equipment requirements

The following test equipment is required in some test cases:

• Traffic Generator, preferably Load Tester

• 8PSK & GMSK capable RF TA Rigs



About this document

• IR/LA Rig

• Assortment of combiners

• Attenuators

• Terminators

• Signal Generator

• Spectrum Analyser

• GSM Protocol Analyser

• Data Channel Simulator

• D-Bus Analyser

• Q1 Monitor/NEE

• Abis Breaker

2.6 Common notes

Note 1. The BSC version to be used is S12, SiteWizard version to be used is SiteWizard5.0, and GCS version to be used is R5.0, unless otherwise specified.

Note 2. The BSC default values are to be used, unless otherwise stated.

Note 3. At the BSC, Base Transceiver Stations (sites) are seen as BCFs. Sectors are referred to as BTS. This principle is followed in the test descriptions in this document.

Note 4. The master TRX operates with BTS O&M and Telecom functions. The slave TRX operates with the Telecom functions only.

The master TRX is always located in slot 1 and the slave TRXs in slots 2 − 4.

Both the master and the slave TRX can be the BCCH TRX or NON-BCCH TRX.

In Nokia MetroSite BTS, the master TRX is by default not a BCCH TRX unless it is defined as the preferred BCCH TRX.



11 (107)


Note 5. A multi-TRX configuration is a site having several TRXs, for example, 2+2 TRXs, 4 TRXs, and so on.

A 1-TRX configuration is a site having one TRX unit (master TRX).

Note 6. Unless otherwise specifically stated, the signalling speed mentioned is for TRXSIG. Such test cases will be distributed among the O&M signalling speeds of 16, 32 and 64 kbps.

Note 7.

• VTxA: CATS, 1 W TRX for GSM 900, 1800 and 1900 bands

• HVTx: HPCATS, 5W TRX for GSM 900, 1800 and 1900 bands

• WTxA: ECATS, 5W TRX for EDGE 800 and 1900 bands

• CTxA: XPCATS, 10 W EDGE TRX for GSM 900, and 1800 bands

• VSxx: Low Power Supply unit

• HVSx/CVSx: High Power Supply unit

• HVMF: High Power Fan unit

• VMFA: Low Power Fan unit

Note 8. The following HW configurations are used during testing:

• GSM (VTxA, HVTx)

• EDGE (WTxA, CTxA)

• GSM/EDGE (HVTx + WTxA or HVTx + CTxA in the same cabinet)

A cabinet can be configured as a dual band BCF, which can use GSM 800 + 1900 bands, or GSM 900 + 1800 bands. Each sector has to be configured with the same band TRXs.

Note 9. The maximum number of MetroSite cabinets combined.

The Chain Master TRX must be HVTx/CTxA located in position 1 at the first cabinet in line called the Master cabinet. The Cabinet Master TRXs are the HVTx/CTxA located in position 1 (logical TRX # 5 and 9) at the second and third cabinets in line called slave cabinets.

Nokia Site Manager connection can be established at any one of the cabinets; however, it is recommended to connect only to the Chain Master cabinet. Only one Nokia Site Manager can be connected at the same time.



About this document

Note 10. An invalid BB Hopping configuration exists in a sector having TRXs of different power types in the same hopping group; that is, GSM/EDGE HVTx (5W) + CTxA (10W) in the same BTS.

Note 11. All test cases must be performed with RX diversity enabled at the BSC, unless otherwise stated.

Note 12. EGPRS cannot be used without Dynamic Abis being configured.

Note 13. A TRX test can be configured to test one or more radio time slots that are configured for GPRS. If started, such a test will be allowed to proceed by the BTS SW, and this is likely to cause the following behaviour for the radio time slots:

• PCU-Synchronisation failure (and then re-synchronisation),

• Adverse effects to GPRS data call active on GPRS-configured radio time slots.

Therefore, it is recommended that GPRS-configured radio time slots are not selected for the TRX test.

Note 14. During the installation and commissioning of sites, help provided by ‘Help Menu’ commands in the BTS Manager should be used.

Note 15. It should be made a testing practice to use help provided in the BTS Manager from the Help menu or using the help button (F1).

Note 16. While testing the Multi-BCF with DF 6.0-3 at the S11 BSC, the SENA for master BCF should be ‘F’, while for DF7 it should be ‘T’.

Note 17. TRXs need to be set to PMAX of 0dB or 2 dB in order to generate the “Antenna connection faulty” alarm.

Note 18. GTRX=N for GSM TRXs in an EDGE/GSM configuration, if EGENA need to be enabled.

Note 19. Pronto Description and Pronto correction document available in WebPronto Database are referred to for creating the test cases.



13 (107)

Object control and radio network management

3 Object control and radio network management

3.1 Common BCCH on simple MetroSite configuration

The purpose is to check that a MetroSite base station can be configured with segments and brought into working order.

Input Expected Output

Create a 2+2 MetroSite at the BSC. Create a TRX with the bands and ARFN shown in the table. Create both BTSs in the same Segment.

Physically create the base station. Commission the site.

Check the status at the BSC using the MML command:

ZEEI:BCF=<bcf number>;

The BCF, BTS and TRX are all in WO.

Check for alarms at the BSC using the MML command:

ZEOL:<bcf number>;

There are no alarms for the BCF.

A call is established on each TRX and speech is maintained.

All calls are successful and speech quality is good. The MS displays the expected ARFN for each TRX used.

Reset the site using the MML command:

ZEFR:<bcf number>;

Check for alarms at the BSC using MML command:

ZEOL:<bcf number>;

The site resets.

Alarm 7767 BCCH MISSING is reported at the BSC.



15 (107)







ZEOL:<bcf number>;

There are no unexpected alarms.

Lock the non-BCCH BTS using the MML command:

ZEQS:BTS=<bts number>:L;



The BCCH BTS is unlocked. The non-BCCH BTS is locked.

Make speech calls as before. All calls are successful and assigned to TRXs in the BCCH BTS.

Unlock the non-BCCH BTS using the MML command:

ZEQS:BTS=<bts number>:U;

The non-BCCH BTS resets.


ZEEI: BCF=<bcf number>;

All objects are unlocked and in WO.

Lock the BCCH BTS using the MML command:


Check the status of the LEDs on the front of the TRX units.

The LED of the locked BCCH TRX shows orange.



The BCCH BTS is locked. The non-BCCH BTS is unlocked.

Check the status of BCCH transmission using Spectrum Analyser.

There is no BCCH signal present.

Unlock the BCCH BTS using the MML command:



ZEOL:<bcf number>;

The BCCH BTS resets.









Monitor the Abis. Monitor the base station using BTS Manager. Check the status of BCCH transmission using Spectrum Analyser.

Use BTS Manager to block the BCCH TRX.

The BCCH signal is no longer present. The BCCH TRX is blocked successfully. The BSC re-configures another TRX in the BTS to be the BCCH.

BCCH transmission is restored successfully.

Unblock the blocked TRX. The TRX is unblocked successfully.

Check the status at the BSC using MML command:





Case Ref.

BTS 1 BTS 2

TRX 1 TRX 2 TRX 3 TRX 4

1. EDGE, P-900 ARFN EDGE, P-900 ARFN

EDGE, P-900 ARFN EDGE, P-900 ARFN

2. EDGE, E-900 ARFN EDGE, ARFN = 0 GSM, P-900 ARFN GSM, P-900 ARFN

3. EDGE, 1800 ARFN above 636

EDGE, 1800 ARFN GSM, P-900 ARFN GSM, P-900 ARFN

4. EDGE, 1900 ARFN above 700

EDGE, 1900 ARFN above 700

GSM, 1900 ARFN above 700

GSM, 1900 ARFN above 700

3.2 Common BCCH on chained MetroSite configuration

The purpose is to check that a chained MetroSite base station can be configured with segments and brought into working order. To check that a site reset, a BTS lock/unlock and an auto-reconfiguration operate correctly.



17 (107)



Create a chained configuration at the BSC. Use the TRX type shown in the table.

Physically create the base station. Commission the site.



The BCF, BTS and TRX are all in WO state.


ZEOL: <bcf number>;




Reset the site using the MML command:

ZEFR:<bcf number>;


ZEOL:<bcf number>;

The site resets.




The BCF, BTS and TRX are all in WO state.


ZEOL:<bcf number>;


Lock BTS 1 using the MML command:



The LEDs of the locked TRXs show orange.



The BTS 2 and 3 are unlocked. BTS 1 is locked.

Make speech calls as before. All calls are successful and assigned to TRXs in BTS 2 and 3. The speech quality is good.

Unlock BTS 1 using the MML command:


BTS 1 resets.



All objects are unlocked and in WO state.





Lock BTS 3 using the MML command:






The BTS 1 and 2 are unlocked. BTS 3 is locked.

Make speech calls as before. All calls are successful and assigned to TRXs in BTS 1 and 2. The speech quality is good.

Unlock BTS 3 using the MML command:


BTS 3 resets.




Lock the BCCH BTS using the MML command:






The BCCH BTS is locked. The non-BCCH BTSs are unlocked.

Check the status of BCCH transmission using Spectrum Analyzer.

There is no BCCH signal present.

Unlock the BCCH BTS using the MML command:






Make speech calls as before. The calls are assigned to a TRX in all BTSs. The speech in both directions can be heard clearly.

Monitor the Abis. Monitor the base station using the BTS Manager. Check the status of BCCH transmission using Spectrum Analyzer.

Use the BTS Manager to block the BTS 2.

The BCCH signal is no longer present. The BSC blocks BTS 2.

Unblock the BTS 2. BTS 2 is unblocked successfully.



19 (107)



Check the status of BCCH transmission using Spectrum Analyser.

The BCCH signal has been restored.



All TRXs are in WO except the original BCCH TRX that was blocked.



All TRX are in WO except the original BCCH TRX that was blocked.


All calls are successful and the speech quality is good. The MS displays the expected ARFN for each TRX used.

Case Ref. TRX Type BTS 1 BTS 2 BTS 3

1. WTxx 1900

2 TRX, Non-Hopping

800

6TRX, BB Hopping,

BCCH BTS, BCCH TRX – Slave TRX

1900

2 TRX, RF Hopping

2. CTxx 1800

2 TRX, Non-Hopping

900

6TRX, BB Hopping,


1800

2 TRX, RF Hopping

3. HVTx 1800

2 TRX, Non-Hopping

900

6TRX, BB Hopping,


1800

2 TRX, RF Hopping

3.3 Recovery after power breakdown

The purpose of these tests is to verify that the BCF starts up automatically after a power breakdown.

3.3.1 Simple MetroSite configuration


BCF is operational. Calls are made via every TRX.

All calls are successful.





The whole BCF is powered OFF (Disconnect the input power applied to the PSU). Power is restored after the delay (as specified in the Test case).

No alarm is generated at the BSC regarding the power failure if the power supply used is DC. In case of AC power supply, a power failure alarm is generated.

The BCF is initialised. The state of the BCF is checked with the MML command ZEEI.

No unexpected alarm exists. The BCF starts up automatically after the power is restored. All BTSs and TRXs return to working state within 3 to 5 minutes.

Calls are made via every TRX. All calls are successful.

Case Ref. Configuration Power restoration delay Power Supply unit

1. Multi TRX GSM/EDGE

Several short power breaks (1-2s) HVSx [1x]

2. 2+2EDGE (CTxA),

RF Hopping+BB Hopping

30 Minutes CVSx

3.3.2 Chained MetroSite Configuration


The BCF is operational. No alarms are present.

Calls are made on the all cabinets in the chain. Calls are successful.

The second Slave cabinet is powered off. The power shutdown has no impact on the other cabinets in the chain. Calls remain on-going in the other cabinets while this Slave cabinet is powered off.

Alarms 7606 TRX Faulty and 7603 BTS Faulty are reported to the BSC and BTS Manager for all TRXs and BTS that belong to the Slave cabinet.

The first Slave cabinet is powered off. The power shutdown has no impact on the master cabinet. Calls remain on going in the master cabinet while this Slave cabinet is powered off.

Alarms 7606 TRX Faulty and 7603 BTS Faulty are reported to the BSC and BTS Manager for all TRXs and BTS that belong to the Slave cabinet.

The Master cabinet is powered off. Alarms 7706 BTS O&M LINK FAILURE, 7704 PCM FAILURES are reported to the BSC.



21 (107)



The Master cabinet in the chain is powered on. The Master TRX of the master cabinet performed clock synchronization and returned to operational state.

The first Slave cabinet is powered on. The Master TRX of the first Slave cabinet performed synchronization by the chain Master TRX and returned to operational state.

The second Slave cabinet is powered on. The Master TRX of the second Slave automatically detects the Slave TRXs and performed synchronization. All cabinets returned to operational state.

Calls are made on each BTS. The calls are successful. No unexpected alarms are observed.

Case Ref. Configuration Power Supply unit

1. Chain configuration with 3 MetroSites, Multi TRX EDGE/GSM+EDGE+GSM, None+RF Hopping+BB Hopping

CVSx+CVSx+HVSx

3.4 BSS restart

The purpose of the test is to verify that the BCF starts up automatically after a BSS restart.


The BSS is restarted with the MML command ZUSS.

All BCFs start up automatically after the BSS restart.

Check the status of the BCFs. All BCFs are in supervisory state.

Alarms are checked and calls are made via every BCF.

No unexpected alarms occur and all calls are successful.

Case Ref.

Configuration

1. Various configurations including at least 3 cabinet chain configurations, Multi-TRX GSM, 2+2 EDGE with Dynamic Abis, 2 EDGE+2GSM with PBCCH, EGPRS are defined.

3.5 Background radio network update

The purpose of the test is to verify that the radio network can be background updated.





The background radio network data is cleared with the MML command ZEER.

The desired background modification is performed.

The modification of the parameter at the BSC is successful.

The background data is activated with the MML command ZEEG.

The background data activation is successful. No unexpected alarms occur.

Calls are made via every TRX, and an Abis loop test is performed to ensure the site is working correctly.

The calls and loop tests are performed successfully.

Case Ref.

Configuration O&M and TRXSIG

Background modification required Repetition

1. 2EDGE+2GSM Combined Background TRX frequencies with the MML command: ZERM:BTS=...,BFREQ=...

Background hopping modes, MAIO offsets and hopping sequences with commands ZEQE and ZEQA.

Repeat 5 times

3.6 Backup of system data

The purpose of this test is to verify that the system data is transferred from the master TRX to the slave TRXs. The D-bus is monitored during the tests.

Test Tool: D-bus Analyser.


The BCF is in an operational state and master TRX is set as the preferred BCCH TRX.

The master TRX is removed from slot 1. When the Master TRX is removed, the alarms 7767 BCCH MISSING and 7705 LAPD FAILURE for TRXs, and 7706 BTS O&M LINK FALURE are active. Reconfiguration cannot take place because the O&M link is not in working state.

The slave TRX is removed from slot 2 and installed into slot 1. After this operation, one TRX is missing. The D-bus is monitored.

The slave TRX has a backup of the system data. When it is installed into the position of the master TRX, it starts to work as the master TRX. The BTS starts up automatically. Alarm 7606 TRX FAULTY is active.



23 (107)



A slave TRX from an un-commissioned BTS is installed into slot 2. The D-bus is monitored.

The system data is sent from the new master TRX to the new slave TRX. The new slave TRX is initialised correctly and the alarms are cancelled at the BSC.

The new master TRX from slot 1 is removed. When the master TRX is removed, alarms 7767 BCCH MISSING, 7705 LAPD FAILURE for TRXs, and 7706 BTS O&M LINK FALURE are active. Reconfiguration cannot take place because the O&M link is not in a working state. The alarms from Nokia MetroSite BTS are not sent to the BSC.

The slave TRX is installed from slot 2 into slot 1. After this operation one TRX is missing. The D-bus is monitored.

The slave TRX has a backup of the system data. When it is installed into the position of the master TRX, it starts to work as the master TRX and the BTS starts up automatically. Alarm 7606 TRX FAULTY is active.

The TRX that was first removed from slot 1 at the beginning of this procedure is installed into slot 2. The D-bus is monitored.

The system data from the master TRX is sent to the slave TRX in slot 2. The TRX is initialised correctly and the alarms are cancelled at the BSC.

Case Ref. Configuration BCCH TRX

1. 2 Omni, TRXs in slot 1 and 2. Master

3.7 Repeated BCF Reset

Purpose:

To check that BCF can be reset from BSC and recover successfully after each reset.

Equipment Spectrum Analyser



An MML macro, which repeatedly resets the BCF, is started and run for 12 hours.

BCCH transmission is checked.

The BCF is reset. Calls are released. BCCH transmission is stopped. Notice that alarm 7701 BCF INITIALISATION is sent during site initialisation. The BCF returns to the WO state along with all of the BTSs and TRXs under the BCF.





The alarm history is checked after the macro is complete.

Alarm 7767 BCCH MISSING is active when the BTSs are initialised. Notice 7701 BCF INITIALIZATION is sent when the BCF is initialised. The BTSs and TRXs under the BCF return to the WO state. Unexpected alarms do not occur.


Case Ref. Site Type/Configuration Hopping Mode

1. Nokia MetroSite

Chained Configuration 3+6+3, EDGE+GSM/EDGE+GSM

None+RF Hopping+BB Hopping



25 (107)

Alarm handling

4 Alarm handling 4.1 TRX failures

The purpose of these tests is to verify that TRX failures are handled correctly and alarms are sent to the BSC and BTS Manager.

Note 20. Neighbours are defined for each BTS.

Note 21. Alarms are checked from the BSC and BTS Manager after every test step. The state of the BCF is checked from the BSC with the MML command ‘ZEEI’.

4.1.1 TRX removed from Simple Configuration


Calls are made in every TRX. Calls are successful.

The master TRX is removed. When the master TRX is removed, alarms 7767 BCCH MISSING and 7705 LAPD LINK FAILURE alarms for all TRXs, and 7706 BTS O&M LINK FAILURE are active. Alarms from Nokia MetroSite BTS are sent to the BSC. The connection between BTS Manager and the BTS is lost.

Reconfiguration is not possible because the O&M link is not in a working state. All calls from the BTS(s) are released due to a loss of frame clock from the master TRX, and new calls cannot be established.



27 (107)



The master TRX is reinstalled. All TRXs are initialised and returned to the working state. Alarms are cancelled.

The BTS Manager connection is re-established.

Calls are made via every TRX. All calls are made successfully.

The slave TRX is removed.

(In case of a sectored configuration, remove the slave TRX from each sector.)

When the slave TRX is removed, alarms 7606 TRX FAULTY (the Master TRX detected that the connection to the Slave is lost) and 7705 LAPD LINK FAILURE alarms are active. Calls from the slave TRX are released. If the removed TRX was a BCCH TRX, calls from non-BCCH TRX to be reconfigured as BCCH TRX are handed over to the neighbouring BTS/working TRX in same BTS.

In case of a BB hopping sector, calls of other TRXs are handed over to the neighbour.

New calls are made through the remaining working TRXs.

New calls are successful.

Removed TRX(s) are locked from the BSC. (Not valid in the case of a BB hopping sector.)

The TRX(s) are locked and the active alarms are cleared at the BSC.

TRX(s) are unlocked from the BSC. The TRX(s) are unlocked and the alarms are reactivated. Alarm 7606 TRX FAULTY is active.

The BTS is locked with Forced HO and then unlocked from the BSC.

(In case of a sectored configuration, repeat this step for all BTSs.)

The BTS can be locked. When the BTS is in the locked state, BCCH transmission is stopped. All calls are handed over to the neighbour BTS. When the BTS is unlocked, the BCCH TRX returns to the working state.

Alarm 7606 TRX FAULTY is first cancelled and then reported again for the removed TRXs.

The BCF is locked and unlocked from the BSC. The BCF can be locked. When the BCF is in locked state, BCCH transmission is stopped. When the BCF is unlocked, the BTS and BCCH TRX return to the working state.

All alarms restarted.

The TRX(s) are reinstalled. Alarms 7606 TRX FAULTY and 7705 LAPD LINK FAILURE are cancelled. The TRX(s) return to working state.

Calls are made via every TRX. Calls are successful via every TRX.

Above steps are repeated with RDIV=N.

Case Ref. Configuration BCCH TRX Hopping Mode



Alarm handling


1. 2+2 GSM/EDGE 900 Band

Master in first sector

1st sector - RF Hopping

2. 4 Omni 1800 Band1

Slave BB Hopping

1 Use BCF with extended BTS ID

4.1.2 TRX removed from Chained Configuration


Calls are made via every TRXs. Calls are successful.

The master TRX of the master cabinet is removed. When the master TRX is removed, alarms 7767 BCCH MISSING and 7705 LAPD LINK FAILURE alarms for all TRXs, and 7706 BTS O&M LINK FAILURE are active. Alarms from Nokia MetroSite BTS are sent to the BSC. Connection between BTS Manager and the BTS is lost.

Reconfiguration is not possible because the O&M link is not in working state. All calls from the BTS(s) are released due to the loss of frame clock from the master TRX and new calls cannot be established.

The master TRX of the master cabinet is reinstalled.

All TRXs are initialised and returned to working state. Alarms are cancelled.

The BTS Manager connection is re-established.

Calls are made via every TRX. All calls are made successfully.

Remove the slave TRX from each cabinet. When the slave TRX is removed, alarm 7606 TRX FAULTY (the master TRX of master cabinet detected that the connection to the slave TRXs is lost) and 7705 LAPD LINK FAILURE alarms are active. Calls from the slave TRX are released. If the removed TRX was a BCCH TRX, calls from non-BCCH TRX to be reconfigured as BCCH TRX are handed over to the neighbouring BTS/working TRX in the same BTS.

In case of BB hopping sector, calls of other TRXs are handed over to the neighbour.

New calls are made through the remaining working TRXs.

New calls are successful.



29 (107)



Remove the master TRX of the second slave cabinet.

Alarms 7606 TRX FAULTY (the master TRX of the master cabinet detected that the connection to the TRXs of second slave cabinet is lost) and 7705 LAPD LINK FAILURE, 7767 BCCH MISSING alarm for that BTS are active. Calls from the second slave cabinet are released.

Remove the master TRX of the first slave cabinet. Alarms 7606 TRX FAULTY (the master TRX of the master cabinet detected that the connection to the TRXs of the first slave cabinet is lost) and 7705 LAPD LINK FAILURE for all TRXs of the first slave cabinet, 7767 BCCH MISSING alarm for that BTS are active. Calls from the first slave cabinet are released.

Removed TRX(s) are locked from the BSC. The TRX(s) are locked and the active alarms (7606 TRX FAULTY and 7705 LAPD LINK FAILURE) are cleared at the BSC.

TRX(s) are unlocked from the BSC. The TRX(s) are unlocked. Alarm 7606 TRX FAULTY is active for the removed TRXs.

The BTSs (belonging to the first slave and the second cabinet) are locked and then unlocked from the BSC.

The BTSs can be locked and unlocked successfully.

Alarm 7606 TRX FAULTY is first cancelled and then reported again for the removed TRXs.

The BCF is locked and unlocked from the BSC. The BCF can be locked. When the BCF is in locked state, BCCH transmission is stopped. When the BCF is unlocked, the BTS belonging to the master cabinet returns to the working state. All alarms are restarted.

The TRX(s) are reinstalled. Alarms 7606 TRX FAULTY, 7705 LAPD LINK FAILURE and 7767 BCCH MISSING are cancelled. The TRX(s) return to working state.

In case of a BB hopping sector the BTS lock/unlock is required in order to bring reinstalled TRX into working order.

Calls are made via every TRX. Calls are successful via every TRX.


1. Chain Configuration with 3 MetroSite Multi-TRX EDGE+EDGE/GSM+GSM

Slave + Master+Slave RF Hopping + None + BB Hopping



Alarm handling

4.1.3 Slave TRX installed with incorrect Frequency Band


A slave TRX with an incorrect frequency band is installed and the BTS is started up.

The configuration alarm 7606 TRX FAULTY (failure detected during BTS configuring) is active at the BSC and BTS Manager. The BTS starts up, but the TRX with the incorrect frequency remains blocked.

Calls are made. The calls are successful via the TRXs with correct frequencies.

The TRX with the incorrect band is removed and replaced with a TRX with a correct frequency band.

The BSC sends a new BB configuration to the BTS. The BTS comes up with all TRXs in working order.

The alarm 7606 TRX FAULTY gets cancelled.

No unexpected alarms present.

Calls are made via every TRX. The calls are successful via every TRX.


1. 4 Omni EDGE Master BB hopping

4.1.4 All slave TRXs and the Antenna Cable of the Master TRX removed


Calls are made via every TRX.

All slave TCH TRXs are removed. When the TCH TRXs are removed, alarm 7606 TRX FAULTY (master TRX detected that connection to slave is lost) is active at the BSC and BTS Manager. The TRXs are blocked at the BSC, and the sector resets due to BB reconfiguration. All calls are released.

The antenna cable from the master TRX is removed.

When the antenna cable is removed, alarm 7600 BCF FAULTY (antenna connection faulty) is active at the BSC and BTS Manager.

The BCF is locked from the BSC. All alarms are cancelled.

All faults are removed by reinstalling the units and cables. The BCF is unlocked.

The BCF is initialised and returned to the working state. No alarms occur.

Calls are made via every TRX. The calls are successful.

Case Ref. Configuration TRX HW BCCH TRX Hopping Mode

1. 4 Omni EDGE/GSM Master Cyclic BB hopping



31 (107)


4.2 Unit failures

The purpose of these tests is to verify that unit faults are handled correctly, alarms are sent to the BSC and BTS Manager, and that the equipment view is properly displayed at BTS Manager.


Note 23. Alarms are checked from the BSC and BTS Manager after every test step. The state of the BCF is checked from the BSC with the MML command ZEEI.

Test Tool: Frequency counter.

4.2.1 VIFA removed from cabinet


Calls are made via every TRX. All the calls are successful.

A 13-MHz frequency is measured from VIFA with a frequency counter.

The frequency is 13 MHz ± 0.65 Hz.

The VIFA is removed from the BTS after switching off the cabinet power supply. Switch on the cabinet power.

BTS Manager is disconnected. Calls are released. Alarms 7767 BCCH MISSING and 7706 BTS O&M link failure are reported at the BSC.

The VIFA is reinstalled after switching off the cabinet power supply. Switch on the cabinet power. Calls are made via the BCF, and the 13-MHz frequency is measured again with the frequency counter from the VIFA.

The BCF is initialised and returns to the working state. Alarms are cancelled. The calls are successful. The frequency is 13 MHz ± 0.65 Hz.

Case Ref. Configuration

1. Multi-TRX GSM/EDGE

4.2.2 Fan unit removed from chained MetroSite


Several calls are made on all TRXs. The calls are ongoing.



Alarm handling


The power of the last slave cabinet is switched off. A fan unit is removed from the last slave cabinet in the chain following [2]. The cabinet power is switched ON.

An alarm for the faulty fan unit, 7605 BTS NOTIFICATION, is reported to the master BCF in the chain and at the MMI. Calls are dropped from the switched off cabinet.

The power of the last slave cabinet is switched off. The fan unit is reinserted. The cabinet power is switched ON. Calls are placed on the last slave cabinet BTSs.

The last slave cabinet is restored successfully. Alarms cancelled at the BSC and BTS Manager. All calls are successful.

The power of the middle slave cabinet is switched off. A fan unit is removed from the middle slave cabinet. The cabinet power is switched ON.

Alarm for the faulty fan unit, 7605 BTS NOTIFICATION is reported to the master BCF in the chain and at the MMI. Calls are dropped from the switched off cabinet.

The power of the middle slave cabinet is switched off. The fan unit is reinserted. The cabinet power is switched on. Calls are placed.

Alarms are cancelled at the BSC and BTS Manager. All calls are successful.

The power of the master cabinet is switched off. A fan unit is removed from the master cabinet. The cabinet power is switched on.

Alarm for the faulty unit, 7605 BTS NOTIFICATION is reported to the master BCF in the chain and at the MMI. Calls are dropped from all the cabinets.

The power of the master cabinet is switched off. The fan unit is reinserted. The power of the master cabinet is switched on. Calls are placed in all the cabinets.

Alarms are cancelled at the BSC and BTS Manager. All calls are successful.


1. 3 MetroSites in chain, each 2+2 EDGE

4.2.3 Cabinet cover removed from BTS cabinet


The BTS is set to maximum TX power. Calls are made via every TRX (maximum call load).

Check the alarms at the BSC using MML command:

ZEOL:<bcf number>;


No unexpected alarms are reported to the BSC.

The BTS cabinet cover is removed. Alarm 7622 CABINET OPEN (cabinet cover is open) is active at the BSC and BTS Manager.

Cabinet power is switched off. Alarm 7767 BCCH MISSING and alarm 7706 LAPD FAILURE for O&M, and alarm 7704 PCM FAILURE are active. Calls are released. BTS Manager is disconnected.



33 (107)



Cabinet power is switched on. The BCF is initialised and returned to the working state. Alarms are cancelled. The BTS Manager connection is re-established.

New calls are made. The calls are successful.

The case is repeated at least 5 times. The BCF initialises and returns to the working state successfully each time.

The cabinet cover is attached. Alarm 7622 CABINET OPEN is cancelled.


1. 2+2 EDGE

4.2.4 Extension cable removed from chained MetroSite

Test Tool: D-bus Analyser.


All BCFs are operational.

Lock the BCF from the BSC. The extension (chaining) cable is disconnected from the slave BTS after shutting down the cabinet’s power.

The power is switched on and the BCF is unlocked. The D-bus is monitored.

All TRXs in the slave cabinet send 7606 alarms.

The master TRX no longer polls the slave TRXs.

Lock the BCF from the BSC. The extension cable is reconnected to the slave BTS in the chain after shutting down the cabinet power.

The power is switched on and the BCF is unlocked. The D-bus is monitored.

Cabinets perform a D1-bus dumb recovery. The chain configuration returns to operational state. Alarms are cancelled.

Calls are made on all the TRXs in that BCF. The calls are successful.


1. 3 MetroSite in chain, each 4 TRX EDGE/GSM

4.3 Antenna cable detection

The purpose of these tests is to verify that faults in the antenna cable connection are detected correctly and alarms are sent correctly from Nokia MetroSite BTS to the BSC.



Alarm handling

Note 24. Alarms are checked at the BSC and BTS Manager after every test step. The state of the BCF is checked from the BSC with the MML command ZEEI.


Note 26. The attenuator should also be removed from the TRX while performing the antenna alarm cases.

4.3.1 Antenna cable removed from the master BCCH TRX


Calls are made via the BTS. All calls are successful.

The antenna cable is removed from the BCCH TRX.

Calls via the BCCH TRX are released. When the antenna fault is detected, alarm 7606 TRX FAULTY (antenna connection faulty) is sent to the BSC. The TRX is blocked and BCCH reconfiguration is performed. Calls on TRX to be configured as BCCH in the sector are handed over before reconfiguration.

In case of a BB hopping sector, calls from the all TRXs are released.

The BCF is locked from the BSC.

Skip this step if BB hopping is being used.

The TRX returns to the working state and the alarm is cancelled. The diagnostics is executed again and alarm 7606 TRX FAULTY is active. The TRX is blocked.

The BTS with blocked TRX is locked and unlocked from the BSC.

Calls are made via faulty TRX.

The TRX returns to the working state and the alarm is cancelled. The diagnostics is executed again and alarm 7606 TRX FAULTY is active.

Calls via the faulty TRX are not successful.

The BCF is locked and unlocked from the BSC. Calls are made via the faulty TRX.

The TRX returns to the working state and the alarm is cancelled. The diagnostics are executed again and alarm 7606 TRX FAULTY is active. Calls via the faulty TRX are not successful.

The antenna is reconnected. The alarm is not cancelled automatically.



35 (107)



Lock/unlock the TRX.

If BB Hopping is used, perform the BTS lock/unlock instead.

The TRX returns to working state. The alarm is now cancelled.

Calls are made via all TRXs. Calls are successful.


1. 4 Omni EDGE Master BB Hopping

2. 2+2, EDGE+GSM Master+Slave RF Hopping in the first sector

4.3.2 Antenna cable removed from all TRXs


Calls are made via all TRXs. The calls are successful.

The antenna cable is removed from all the TRXs one by one.

The calls on the faulty TRX are released. The diagnostics are executed. When the antenna fault is detected, alarm 7603 BTS FAULTY (antenna connection faulty) is sent to the BSC. The BTS is blocked. When the last antenna under the BCF is removed, alarm 7600 BCF FAULTY is sent to the BSC. The BCF is blocked.

The blocked BCF is locked and unlocked. The BCF can be locked and unlocked. Alarms 7603 and 7600 get cancelled. When the antenna fault from all the BTSs is detected, alarms 7603 BTS FAULTY and 7600 BCF FAULTY are sent again to the BSC and the BCF is blocked.

All antennas are reconnected. The BCF is locked and unlocked from the BSC.

The TRX returns to the working state.

Calls are made via all TRXs. All calls are successful.

Case Ref. Configuration Signalling

1. 1+1+1+1 Combined O&M and TRX signalling

4.3.3 Antenna cable removed from the slave TCH TRX


Calls are made via all TRXs. All calls are successful.



Alarm handling


The antenna cable is removed from the slave TCH TRX.

The diagnostics are executed. When the antenna fault is detected, alarm 7606 TRX FAULTY (antenna connection faulty) is active. The calls via the slave TCH TRX are released. All other calls remain active.

The antenna is reconnected. The alarm is not cancelled automatically.

The TRX is locked and unlocked from the BSC. The TRX returns to the working state after locking and unlocking. The alarm is cancelled.

Calls are made via the slave TCH TRX. The calls are successful.


1. 2+2 EDGE+GSM Master

4.3.4 Antenna cable removed from the master of slave cabinets


The BCF is operational.

The master of slave cabinets is BCCH TRX (TRX in position 5 or 9).


Remove the antenna connection of the BCCH TRX in the slave cabinets.

Alarm 7606 TRX FAULTY (antenna connection faulty) is generated for the TRX with the removed antenna. The slave TRXs in the slave cabinets continue their operation. After the alarms are sent to the BSC, the BCCH reconfiguration is executed. Calls via the BCCH TRX are dropped and the remaining calls are continued. Calls on the TRX to be configured as the BCCH in the sector are handed over before reconfiguration.

The antenna is reconnected to the slave cabinet master TRX. The TRX is reset.

Alarms are cancelled. The slave cabinet master TRX is returned to the operational state.

Calls are made through the tested TRX. The calls are successful.

The case is repeated with any slave TRX of slave cabinets as BCCH TRX.


1. 4+4+4, 3 MetroSite chain configuration



37 (107)


4.4 LAPD failure

The purpose of these tests is to verify that LAPD link failures are handled correctly.

Note 27. When the Abis is switched off between the BSC and BTS, alarm 7704 PCM FAILURE is generated instead of alarm 7705 LAPD FAILURE.

Note 28. For the period of each test case, the 13 MHz clock is monitored from the clock output located on the VIFA unit. Neighbour BTSs are defined.

Note 29. The time of the link break varies between 1 and 20 minutes in the different cases.

Note 30. These test cases are equally shared between different transmission units: FC E1/T1, FXC E1/T1, and FXC RRI. When the FXC type card is used, transmission is chained to the following MetroSites, and the calls are also taken via the BCFs following in the same transmission chain.

4.4.1 LAPD blocked with MML command

Test Tool: Spectrum Analyser.


Alarms are checked after every test step at the BSC and BTS Manager.

Calls are made via TRXs. The calls are successful.

The O&M signalling link is blocked with the MML command ‘ZDTC’.

When the O&M signalling link is blocked, alarm 7706 BTS O&M LINK FAILURE is activated at the BSC. The calls are not released.



Alarm handling


The status of the LAPD link is requested with the LAPD Link Status command from BTS Manager.

The state of the OMUSIG link is Off in the Link Status window. The state of the TRXSIG link is On in the Link Status window.

The status bar at the bottom of the Supervision window indicates: ‘O&M disabled’ and ‘Telecom not working’.

An alarm is generated by removing a slave TCH TRX. The O&M signalling link is unblocked from the BSC. Alarms are checked at the BSC. The time between establishing the O&M LAPD link and sending the alarms to the BSC is checked from the Abis.

The O&M signalling link is established, alarm 7706 is cancelled and alarm 7606 TRX FAULTY for the missing TRX is active. If the BSC does not acknowledge the alarm, the BCF re-sends it after ten seconds.

The TRX is reinstalled. The TRX is initialised correctly and alarm 7606 is cancelled.

The BCCH TRX signalling link in the first BTS is blocked with the MML command ‘ZDTC’. The status of the LAPD link is requested with the LAPD Link Status command from BTS Manager.

When the BCCH TRX signalling link is blocked, alarm 7705 LAPD FAILURE is activated and the TRX is blocked from the BSC. BCCH reconfiguration is performed. All calls via TCH TRXs are handed over before the reconfiguration occurs. The state of the OMUSIG link is On in the Link Status window. The TRXSIG link of the blocked BCCH TRX Signalling is reported to be in the 'Off' state. The state of the TRXSIG link for the rest of the TRXs is On in the Link Status window.

The status bar at the bottom of the Supervision window indicates: ‘O&M enabled’ and ‘Telecom partially working’ (multiple TRX configuration).

The TRX signalling link is unblocked. The TRX signalling link is re-established and the TRX returns to the working state as a TCH TRX.

The status of the LAPD link for the unblocked BCCH TRX signalling is requested with the LAPD Link Status command from BTS Manager.

The states of the OMUSIG and TRXSIG links are reported correctly in the Link Status window. The TRXSIG link of the unblocked BCCH TRX signalling is reported to be in the 'On' state.

The status bar at the bottom of the Supervision window indicates: ‘Abis enabled’ and ‘Telecom working’.

More calls are made via the TRX. The calls are successful.


1. Multi-TRX EDGE/GSM



39 (107)


4.4.2 BER introduced

Test tool: Data Channel Simulator


A multi-TRX, 16 Kbits/s (TRX signalling speed) configuration is in use.

Calls are made in every timeslot. The calls are successful.

All but one call is cleared. The remaining call is left ongoing throughout the test cases.

The BER (Bit Error Ratio) is set with a Data Channel Simulator to the desired BER level. The BER is generated in the downlink direction, then in uplink direction, and then simultaneously in both directions. Alarms are checked at the BSC and BTS Manager.

When the alarm limits are reached, alarms occur at the BSC and BTS Manager. For BER greater than 1E-3, alarm 8099 BIT ERROR RATE (BER) > 1E-3 is raised. For BER greater than 1E-6 and less than 1E-3, alarm 8102 BIT ERROR RATE (BER) > 1E-6 is raised.

When the BER is greater than 1E-3, calls may be cut off.

Calls are made in every timeslot after the test. The calls are successful.

Case Ref. BER

1. 1E-3

2. 1E-6

4.4.3 Repeated LAPD Block/Unblock

The purpose of this test is to check that LAPD can be blocked/unblocked from the BSC and recover successfully after each unblock.

Note 31. The waiting time after a block is 10 seconds and after an unblock 2 minutes.



An MML macro, which repeatedly blocks/unblocks the LAPD link of all TRXs, is started and run for 12 hours.

The TRX Signalling link is blocked, alarm 7705 LAPD FAILURE is activated and the TRX is blocked from the BSC.

BCCH reconfiguration is performed when the LAPD link of BCCH TRX is blocked.



Alarm handling


The status of the LAPD link is requested with the LAPD Link Status command from BTS Manager.

(Run this step for the first 30 minutes and the last 30 minutes of the whole test case duration.)

The TRXSIG link of the blocked TRX Signalling is reported to be in ‘Off' state. The state of the TRXSIG link for rest of the TRXs is On in the Link Status window.

The Status bar at the bottom of the Supervision window indicates: ‘O&M enabled’ and ‘Telecom partially working’ (Multiple TRX configuration).

The alarm history is checked after the macro is complete.

Alarm 7705 LAPD FAILURE is active when LAPD link is blocked. No other unexpected alarms reported.


Case Ref. Site Type/Configuration

1. Nokia MetroSite - 4 Omni EDGE/GSM

4.5 RX antenna supervision by comparing RSSI value

The purpose of this test is to check that the RX antenna condition can be monitored by comparing RSSI value.

Note 32. The antenna can only be supervised reliably if the BCCH power level is within the acceptable range of power levels 0 to 6.


Create a BTS with the configuration mentioned in the test case.

The BTS is in WO state.

Set RXDL (RX difference limit) from BSC using MML command ZEFM.

The RXDL value set successfully.

Insert attenuation greater than the set RXDL in the main RX antenna line.

Record the Abis trace and monitor.

Calls are made via the BTS so that a high traffic situation is realised.

The calls are successful. After one hour, the alarm 7607 “TRX OPERATION DEGRADED: Difference in RX levels of Main and Diverse antenna” is reported at the BSC and BTS Manager.



41 (107)


Results are checked from BTS Manager. Results can be requested from BTS Manager. Main and Diversity RX levels, TRX branch difference and RX Relative difference values are displayed for TRXs that have high traffic. The text “n/a” is displayed for TRXs that have low traffic.

Stop the Abis recording and analyse the trace.

Transactions between the BTS and the BSC for the RSSI can be followed: RX Difference limit and RX Diversity both appear in BTS_CONF_DATA message. The alarm is set with BTS_ALARM message.

Case Ref. BTS Type/Configuration

1. Nokia MetroSite - Any

4.6 Alarm correlation for simple MetroSite configuration

The purpose of these tests is to check that the different level of alarms are reported and cancelled correctly from BTS Manager and the BSC.

Note 33. The expected range of TX power levels from a TRX test is transmitted power level – PMAX value ± 4 dBm.

Therefore, for MetroSite, if the transmitted power level is 37 and PMAX is 30, then expected power level from TRX test is 37-30±4 i.e. 3dBm to 11 dBm range.

When the test case calls for a failure to occur during the test or a failure to start the test then the failure reason is included in the TRX test report.

Note 34. When the test is started from BTS Manager, the alarm 7615 RTS IS IN TEST USE for the used TS is started. When BTS Manager finishes the test, the alarm 7615 RTS IS IN TEST USE for the used TS is cancelled. The alarm may persist if the TRXs are in Configuring mode.

Note 35. This alarm may not be included in the alarm history at the BSC as the BSC uses time-window based filtering for alarm reporting. That is, if an alarm is started and cancelled within 10-seconds.



Alarm handling

Note 36. The PMAX value should be set as Maximum (that is, 0) and RDIV=Y.


The BCF is in Supervisory state.

Remove the antenna of TRX1 (Non-BCCH) and run the TRX test on TRX1 from BTS Manager.

The TRX test fails.

Alarm 7606 TRX FAULTY with description “TRX test result Antenna Connection faulty” is reported for TRX1.

Remove TRX2 from the cabinet. Alarm 7603 BTS FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for Sector 1.

Remove the antenna of TRX3 and run the TRX test on TRX3 from BTS Manager.

The TRX test fails.

Alarm 7603 BTS FAULTY with description “Antenna Connection faulty” is reported for the Sector 2.

Remove the antenna of TRX4. Alarm 7600 BCF FAULTY with description “Antenna Connection faulty” is reported for the BCF.

Perform an action as defined in the test case below.

Behaviour is per Expected Result defined in the corresponding test case.

Note

When Alarm 7600 BCF FAULTY is cancelled, the BCF will be restarted and diagnostics is executed again.

Run the TRX test on the restored TRX from BTS Manager.

The test is successful and the test results are acceptable.

When the test is started, the alarm RTS IS IN TEST USE for used TS is started.

When the test is finished, the alarm RTS IS IN TEST USE for the used TS is cancelled.

The test is not started for control channels or channels with an active call.

Make calls via restored TRX. All calls are successful.


Action Expected Result



43 (107)



01 Nokia MetroSite

2+1+1

EDGE+GSM+EDGE

Insert TRX2 back into the cabinet.

Alarm 7600 BCF FAULTY is cancelled.

Alarm 7603 BTS FAULTY for Sector 1 is cancelled.

Alarm 7603 BTS FAULTY with the description “Antenna Connection faulty” is reported for Sector 3.

TRX2 is restored.

02 Nokia MetroSite

2+1+1

EDGE+GSM+EDGE

Restore the antenna for TRX1 and reset TRX1.


Alarm 7603BTS FAULTY for Sector 1 is cancelled.

Alarm 7606 TRX FAULTY for TRX1 is cancelled.

Alarm 7606 TRX FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for TRX2.


TRX1 restored.

03 Nokia MetroSite

2+1+1

EDGE+GSM+EDGE





TRX3 restored.

4.7 Alarm correlation for chained MetroSite configuration

The purpose of these tests is to check that the different level of alarms are reported and cancelled correctly from BTS Manager and the BSC.



Alarm handling


Therefore, for MetroSite, if the transmitted power level is 37 and PMAX is 30, then expected power level from TRX test is 37-30±4 i.e. 3dBm to 11 dBm range.


Note 38. This alarm may not be included in the alarm history at the BSC as the BSC uses time-window based filtering for alarm reporting. That is, if an alarm is started and cancelled within 10 seconds.

Note 39. The Receive Diversity value should be set as RDIV=Y.

Note 40. Sometimes the “Autonomous TRX” test fails due to a timing issue. Thus, the required alarm is not reported to the BSC or BTS Manager. However, when the TRX test is started again automatically (either a call is made or the TRX test is run manually), the proper alarm is reported.

Test Set-Up: See Figure 1 below for the configuration.


The BCF is in Supervisory state.


The TRX test fails.


Remove TRX2 (BCCH) from the cabinet. Alarm 7603 BTS FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for Sector 1.



45 (107)




The TRX test fails.

Alarm 7606 TRX FAULTY with description “TRX test result Antenna Connection faulty” is reported for the TRX3.


The TRX test fails.

Alarm 7606 TRX FAULTY with description “TRX test result Antenna Connection faulty” is reported for the TRX5.

Remove TRX6 (Non-BCCH) from the cabinet. Alarm 7606 TRX FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for TRX6.


Remove the antenna of TRX4 (BCCH) and run the TRX test on TRX4 from BTS Manager.

Remove TRX8 (Non-BCCH) from the cabinet before BCCH reconfiguration.

The TRX test fails.

Alarm 7606 TRX FAULTY with description “Antenna Connection faulty” is reported for the TRX4.

Alarm 7603 BTS FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for the Sector 2.


The TRX test fails.


Remove the RX diversity cable from TRX10.

Run the TRX Test on TRX10 from BTS Manager.

The TRX test fails with reason “RX cabling is faulty or missing” at BTS Manager.

Alarm “7607 TRX OPERATION DEGRADED: TRX test result antenna connection faulty” is also raised at BTS Manager and the BSC.

Configure the RX diversity cable from TRX10.

Run TRX Test on TRX10 from BTS Manager.


Alarm “7607 TRX OPERATION DEGRADED:

TRX test result antenna connection faulty” is cancelled.


Remove TRX11 (BCCH) from the cabinet. Alarm 7600 BCF FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for BCF.



Alarm handling


Action taken as defined in the test case. Behaviour is per Expected Result defined in the test case.

Note

When alarm 7600 BCF FAULTY is cancelled, the BCF will be restarted, diagnostics is executed again, and alarm 7601 BCF OPERATION DEGRADED is reported as the restored TRX has no diversity.

Run the TRX test on the restored TRX from BTS Manager.


When the test is started, the alarm RTS IS IN TEST USE for used TS is started.

When the test is done finished, the alarm RTS IS IN TEST USE for the used TS is cancelled.


Make calls via the restored TRX. All calls are successful.

Case Ref. Site Type/Configuration Action Expected Result

01 Nokia MetroSite

2+6+3

None+ RF Hopping + BB Hopping

Insert the TRX2 back into the cabinet.



Alarm 7603 BTS FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for Sector 3.

TRX2 is restored.

02 Nokia MetroSite

2+6+3

None + RF Hopping + BB Hopping




Alarm 7606 TRX FAULTY for TRX5 is cancelled.

Alarm 7606 TRX FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for TRX8.

Alarm 7603 BTS FAULTY with description “Master TRX detected that connection to slave TRX is lost” is reported for Sector 3.

TRX5 is restored.



47 (107)



03 Nokia MetroSite

2+6+3

None + RF Hopping + BB Hopping

Insert the TRX11 back into the cabinet and reset the BTS3.


TRX11 is restored.

Figure 1 MetroSite Chained Configuration



Alarm handling



49 (107)


5 BTS Manager functionality 5.1 External Devices and Filter Alarms Commands

The purpose of the test cases included in this section is to verify that the Supervision Menu command options operate as desired and to verify that the BTS external devices are shown correctly.


BTS Manager is locally connected to the BCF.

The Supervision External Devices command is selected.

No external devices are shown.

Make the BCF operational. The Supervision External Devices command is selected.

The BCF is operational. Local connection to the BCF is established. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Local MMI connected’ is started at both the BSC and BTS Manager.

The External Devices report is displayed. No external device is shown.

The BCF is configured with external transmission units.



The External Devices report is displayed.

The Q1 equipment type and its Q1 address are correctly shown in the window.

The External Devices report is printed to a printer. The report format is readable and information is printed as shown in the dialog box.

The External Devices report is saved into to a file. The file report format is readable and the information is as shown in the dialog box.

The Undo Commissioning command is selected from the Commissioning Wizard.

The BCF is reset and not commissioned.



BTS Manager functionality


The BTS is commissioned with the Commissioning Wizard.

The BTS Commissioning Report contains the correct information about the External Devices.

The BCF is operational. The BTS has no external transmission units configured, that is, remove the earlier defined external transmission units.

The BCF is operational. Local connection to BCF is established. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Local MMI connected’ is started at both the BSC and BTS Manager.


The external devices report informs that there are no external devices.


1. Any




The local connection to the BCF is established. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Local MMI connected’ is started at both the BSC and BTS Manager.

A number of alarms of all categories are made active (also Transmission alarms are activated).

The alarms are shown in the Alarms window of BTS Manager.

The Supervision Filter alarms command is selected.

The test is repeated for the following filter types:

• a/: Sector

• b/: TRX

• c/: Critical

• d/: Major

• e/: Minor

• f/: Warning.

Only non-filtered alarms are seen in the Alarms window.

A number of new alarms are made active. Only the new non-filtered alarms are seen in the Alarms window.

The alarm filter is de–selected with the Supervision Filter alarms command.

All alarms are seen in the Alarms window, including the ones that were previously filtered.

The test is repeated by activated and deactivated the FILTER column in the status bar of the Alarms window.


1. Any



51 (107)


5.2 BTS Configurations and Site Information

The purpose of these tests is to verify that BTS Configurations and Site Information are displayed correctly.


The BCF is operational and calls are made. The calls are successful.


The Equipment view is activated from the Supervision menu.

Local connection to BCF is established. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Local MMI connected’ is started at both the BSC and BTS Manager.

The Supervision window is opened with the Equipment view, which displays the physical configuration of the BTS and the correct Unit Type.

The mouse pointer is moved over the cabinet(s), the BCF, TRX(s), TRE and other objects.

The information given in the status bar at the bottom of the window is updated when the mouse is moved from one object to another.

The information is correct.

Select any of the objects (Power supply unit, TRX(s)). Right-click it and select HW versions.

Unit Type, Version and Serial Number are verified.

HW Versions Report is opened successfully.

Unit Type, Version and Serial Number are shown correctly.

The Logical Objects view is activated from the Supervision menu.

The logical objects (BCF, Sector, TRX, and TRE) configuration view is displayed in graphical hierarchical format in the Supervision window.

The mouse pointer is moved over the logical objects.

The information given in the status bar at the bottom of the window is updated when the mouse is moved from one object to another.

The information is correct.

From the logical view, BCF Information is saved into a file.

The report format is readable and the information is as in the dialog box.

Reset the BCF and repeat the above test steps.

Case Ref. Configuration HW Unit

1. 1+1+1+1 VTGx+HVTx+HVTD+VTDA, HVSx

2. 3 MetroSite Chained configuration (CTGx+CTDx)+VTxx+HVxx, CVSG+VSxx+HVSA

3. 2+2 VTPA+HVTP, HVSx

4. 2+2 WTPA+WTFA, HVSx





BTS Manager is locally connected to the BCF. Local connection to the BCF is established. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Local MMI connected’ is started at both the BSC and BTS Manager.

The Supervision Site Information command is selected.

The SW Versions, HW Versions, LAPD status, Alarms, Object Data, Clock Control Settings and Abis State are shown correctly in the Site Information dialog box.

The Options command is selected. As a default, all options are selected.

Different combinations of the options are selected.

The Site Information contains information only about the selected options.

The Site Information is saved into a file with the Save As command.

The Site Information file contents are correct and the report format is readable.

The test is repeated with an operational BCF.


1. Any

5.3 Abnormal TRX in the configuration

The purpose of these tests is to ensure that an abnormal TRX in the configuration is handled correctly.

5.3.1 TRX not commissioned



For one TRX in the cabinet, the Abis TS allocation has not been given during commissioning.

Local connection to the BCF is established. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Local MMI connected’ is started at both the BSC and BTS Manager.

The not commissioned TRX is in the 'Configuring' state.

The Object Properties for the TRX is checked. The TRX is not commissioned.

The TRX Test command is selected. The TRX Test for the not commissioned TRX is started.

The TRX Test cannot be executed.

The Send BCCH Carrier command is selected. Sending the BCCH carrier for the not commissioned TRX is attempted.

The sending BCCH carrier cannot be started.



53 (107)




1. Any

5.3.2 TRX not defined at the BSC


The BCF is operational. One of the TRXs is not configured into the BSC, but it exists in the cabinet and the Abis TS allocation has been given.



The un-configured TRX is in the 'Configuring' state.

The Logical Objects view is activated. The not configured TRX is not shown in the Logical Objects view.

The TRX Test command is selected. The extra TRX (which was not configured) in the configuration is selected. The ARFN number and Radio Timeslot are given and the test is started.

The TRX Test can be executed.

The test results are checked. The test results are reasonable.

The Send BCCH Carrier command is selected. The command is not executed because the Abis is connected and this is properly indicated for the user.


1. Multi TRX

5.3.3 TRX does not exist in the cabinet


The BCF is operational. One of the TRXs is configured to the BSC, but it does not exist in the cabinet.



The TRX is missing from the Equipment view.

The Logical Objects view is activated. The TRX that is configured to the BSC is shown in the view as a missing TRX.

The TRX pop-up menu for the missing TRX is activated.

The pop-up menu cannot be activated.





The Object Properties for the missing TRX are selected from the Objects menu.

The properties for missing TRX are shown as Missing from configuration.


1. Any

5.4 External alarms and controls


At the BSC, some EAC inputs are defined as not activated and some inputs are defined as activated with different polarities (MML command ZEFX). The alarm text is defined to all user definable alarms at the BSC.

The BCF is commissioned with the EAC inputs set in use.


Alarms can be defined at the BSC. Alarm definitions are sent to the BCF in the BTS_CONF_DATA message.


Some EAC inputs are closed (that is connected to GND) and some are in the open state. The Supervision EAC States command is selected.

All EAC inputs are shown with the correct states. Alarms are activated at the BSC and BTS Manager according to activity and polarity definitions.

The states of the EAC inputs are changed one by one by using an EAC switch box.

The change in EAC input state is reflected correctly in EAC States dialog box. Alarms are activated and cancelled at the BSC and on BTS Manager according to activity and polarity definitions.

The BCF is reset from BTS Manager. After BCF reset, all external alarms, which were active before reset, are again active in BTS Manager and at the BSC.


Alarms are activated one-by-one and checked from the BSC. The BCF is restarted.

External alarms 7401–7410 are sent to the BSC. The BCF is initialised with the active alarms.

Alarms are cancelled and checked from the BSC. Alarms get cancelled.


1. Any



55 (107)


5.5 TRX Test during BB Hopping

The purpose of this test is to check that the TRX test can be started for a TRX in a BB Hopping mode.


Therefore, for MetroSite, if the transmitted power level is 37 and PMAX is 30, then expected power level from TRX test is 37-30±4 (that is, 3dBm to 11 dBm range).


Note 42. When the test is started from BTS Manager, the alarm 7615 RTS IS IN TEST USE' for used TS is started. When BTS Manager finishes the test, the alarm 7615 RTS IS IN TEST USE' for the used TS is cancelled. The alarm may persist if TRXs are in the Configuring mode.




Start the BTS Manager application. BTS Manager starts successfully.

Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Local MMI connected’ is started at both the BSC and BTS Manager.

Click on the menu item Tests TRX Test.

Select all TRXs one by one and check the ARFN text field.

The TRX Test dialog box opens successfully with the ARFN text field for all the TRXs as disabled.

Click on the Close button of the TRX Test dialog box.

The TRX Test dialog box closes successfully.





Click on Tests TRX Tests.

Select a TRX and TS. Click the Start button.

The TRX Test dialog box opens.

The TRX test is started successfully.

Click the OK button in the message box. The ARFN text box is disabled and ARFN is not editable.

Case Ref. Site Type/Configuration Hopping Mode

1. Nokia MetroSite

4 Omni EDGE

BB Hopping

5.6 TRX Test during TRX in configuring mode

The purpose of this test is to check that the TRX test can be started for a TRX in a configuring mode.


Therefore for MetroSite, if the transmitted power level is 37 and PMAX is 30, then expected power level from TRX test is 37-30±4 (that is, 3dBm to 11 dBm range).


Note 46. When the test is started from BTS Manager, the alarm 7615 RTS IS IN TEST USE' for used TS is started. When BTS Manager finishes the test, the alarm 7615 RTS IS IN TEST USE' for the used TS is cancelled. The alarm may persist if TRXs are in Configuring mode.





57 (107)


Equipment Spectrum Analyser.


Start the BTS Manager application. BTS Manager starts successfully.

Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Local MMI connected’ is started at both the BSC and BTS Manager.

Block the sector from BTS Manager. The sector is blocked successfully.

Reset any TRX from BTS Manager. The TRX resets and finally goes into the Configuring state.

Click on the menu item Tests TRX Test.

Select all the TRXs one by one and check the ARFN text field.

The TRX Test dialog box opens successfully. ARFN text field for all the TRXs appears as disabled.

Start the TRX test (which is in Configuring state).

Monitor the downlink signal to verify the used ARFN for the TRX test.



The TRX test runs on the ARFN configured for the TRX at the BSC and BTS manager.


1. Nokia MetroSite - 4 Omni EDGE






59 (107)


6 Remote BTS Manager 6.1 Multiple Remote BTS Manager sessions for

different BTSs

The purpose of these tests is to verify that several Remote BTS Manager sessions for different BTSs can exist simultaneously on a single PC.

Note 49. The maximum of six Remote connections per BSC can be established.


More than seven different BCFs are used on several BSCs. Remote BTS Manager connections are established from a single PC.

All the remote sessions operate simultaneously on a single PC. Alarm 7801 MMI CONNECTED TO BASE STATION is started at the BSC for all BCFs and the alarm is also visible at the separate BTS Managers.

The Remote BTS Manager session to BCF1 is disconnected and then reconnected.

The remote BTS Manager sessions to the remaining BCFs stay operational and BCF1 is reconnected.

The process is repeated for all the Remote BTS sessions.

All sessions remain operational other than the session disconnected.


1. Any

6.2 Remote Transmission Manager traffic

The purpose of this test is to verify that transmission equipment management traffic does not interrupt a Remote BTS Manager connection.



Remote BTS Manager

Input Expected OutputBTS Manager is started from a remote PC via NetAct and the BSC using the GCS connection tool.

The remote connection to the BCF is established. Alarm 7801 MMI CONNECTED TO BASE STATION is started at both the BSC and BTS Manager.

Transmission Equipment Management traffic is generated on the Abis by sending alarm request messages from the Remote Transmission Manager to the BTS. This is done by refreshing transmission alarms.

The test is left ongoing for 2 hours.

The Transmission Equipment Management traffic continues on the Abis and does not interrupt the Remote BTS Manager session.


1. Any

6.3 Remote BTS link failures

The purpose of these tests is to ensure that a Remote BTS Manager session terminates correctly when some link between the BTS and the BTS Manager fails.

6.3.1 Link between BTS and BTS Manager removed


BTS Manager is started from a remote PC via NetAct and the BSC using the Nokia GCS connection tool.


The Abis link is removed at the site. The remote BTS timer expires and the session is closed. BTS Manager states not connected. A PCM failure appears and alarm 7801 MMI CONNECTED TO BASE STATION is also present at the BSC.

The link removed earlier is reconnected at the site.

The PCM failure alarm gets cancelled.

Alarm 7801 MMI CONNECTED TO BASE STATION is present.

The Remote BTS Manager is reconnected. The Remote BTS Manager is reconnected and the session is restarted. Alarm 7801 is restarted at the BSC and then at the Remote BTS Manager.



61 (107)



The above steps are repeated by removing the physical link between the PC and the NetAct or the NetAct and the BSC.


1. Any

6.3.2 BER introduced

Test tool: Data Channel Simulator.


The BCF is operational and in a supervisory state. The BER (Bit Error Rate) is set with a data channel simulator to 1E-6.

A Remote BTS Manager session is started. A TRX test is started from the Remote BTS Manager menu command by selecting Tests TRX Test. The BER is generated in the uplink direction, in the downlink direction and simultaneously in both directions.

The remote BTS Manager gets connected and alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is started at both the BSC and BTS Manager.

The executed commands are successful.

The test is repeated with the BER value 1E-9 and 1E-3.

The Remote BTS Manager does not get connected with the BER value 1E-3.


1. Any

6.3.3 Delay introduced


The BCF is commissioned with Satellite Abis settings. The BCF is operational and in a supervisory state. A delay of 240 ms is added into the Abis using the Data Channel Simulator.

A Remote BTS Manager session is started. A TRX test is started from the Remote BTS Manager menu command by selecting Tests TRX Test.

The remote BTS Manager gets connected and alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is started at both the BSC and BTS Manager.

The executed commands are successful.



Remote BTS Manager


The delay is increased in steps of 10 ms to 280 ms and the test is repeated for each change.

The Remote BTS Manager stays connected and the commands are successful.


1. Any

6.4 Re-establishing the BCF connection

The purpose of this test is to ensure that the communication with BTS Manager can be re-established if the BCF connection is reset.


The BCF is operational and the Remote BTS Manager is running.

Remote connection to BCF is established. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is started at both the BSC and BTS Manager.

Calls are made via TRX(s) and maintained during background downloading.

CXM3.3-1 is active and is latest in flash. CXM3.3 is oldest in flash.


Using the MML command ‘ZEWA’, start CXM4.1 BTS SW background downloading.

The SW can be background downloaded from the BSC to the BCF. The calls are not released during the background downloading. The Remote BTS Manager session stays operational.



63 (107)



After the background downloading is complete, the BTS SW package is activated by entering the MML command ‘ZEWV’.

The software is not downloaded from the BSC. When the SW is loaded to the BCF, saved in the non-volatile memory, and activated, the BCF is initialised with the SW. All calls are released. When the BCF is reset, an Abis down situation is reported at the Remote BTS Manager and it stops polling. The connection between the BCF and the Remote BTS Manager is terminated. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is cancelled at the BSC.

The only available menus are File, Tools, Window, Connection and Help menu. All toolbar icons are disabled, except the icon that activates a command from the Help menu and connects a command from the connections menu.

The Supervision and Alarms windows disappear and the only visible window is the BTS Events window.

'No connection to BTS’ is displayed in the BTS Events window.

The BCF is operational and the Remote BTS Manager connection is established again successfully. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is reported at the BSC and BTS Manager.

Block/unblock the OMU from the BSC using MML command ZDTC. Attempt to re-connect the Remote BTS Manager after the first ‘No connection to BTS’ message.

The connection is not made because the ‘Connect’ option is disabled in the connection menu.

The connection is re-established automatically, the Equipment view reappears showing the correct information. The Alarm window reappears.

Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is active at the BSC and Remote BTS Manager.



Remote BTS Manager


BCF reset is performed using MML command ZEFR. Attempt to re-connect the Remote BTS Manager after the first ‘No connection to BTS’ message.

The connection is not made because the ‘Connect’ option is disables in the connection menu.

The connection is re-established automatically, the Equipment view reappears showing the correct information. The Alarm window reappears.

Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is active at the BSC and Remote BTS Manager.

The BCF becomes operational.



1. Any

6.5 Dynamic Abis EDAP pools update on Multiple remote BTS Managers

The purpose of this test is to verify that the dynamic Abis EDAP pools from multiple remote BTS Manager applications can be updated.


Two different BCFs are used.

The sites are operational.

An EGPRS call is made in both BCFs using MCS-9. The Abis is monitored during the calls.

The calls are successful.

The Master Data Frame points to the Slave data frames at the EDAP TS.

Remote BTS Manager connections are made to both BCFs from the same PC.

Both BTS Managers are started successfully.

The Transmission Traffic Manager command is selected from BTS Manager for the BCFs. The EDAP pool in both BCFs is increased by adding one TS at the beginning of the EDAP pool at the Traffic Manager.

The EDAP pools are modified successfully and the new Abis allocations are sent to the transmission cards.



65 (107)



EGPRS is disabled.

Using the MML command ZESM, the EDAP pool in both BCFs is increased by adding one TS at the beginning of the EDAP pool.

EGPRS is enabled.

The pools are modified at the BSC successfully.

The BCFs are reset at the BSC to take the new EDAP into use.

EGPRS calls are made using MCS-9. The calls are successful. The Abis are monitored during the calls. The Master Data Frame points to the Slave data frames at the new EDAP TS.

Case Ref. Configuration EDAP Pool used

1. Multi TRX EDGE 1 TS per BCF

6.6 Alarm handling

The purpose of these tests is to verify that a Remote BTS Manager can handle alarms correctly.

Note 50. TRXs need to be set to the PMAX of 0 dB in order to generate the ‘Antenna connection faulty’ alarm.


6.6.1 Slave TCH TRX removed




The remote connection to the BCF is established. Alarm 7801 MMI CONNECTED TO BASE STATION is started at both the BSC and the Remote BTS Manager.



Remote BTS Manager


The slave TCH TRX is removed. When the slave TRX is removed, alarm 7606 TRX FAULTY (Master TRX detected that connection to the slave is lost) is reported at the BSC and the Remote BTS Manager.

The calls via the removed TRX are released.

The removed TRX is locked and unlocked from the BSC.

The alarm is cancelled from the BSC with the Lock action and then sent again with the Unlock action.

The slave TRX is reinstalled. Calls are made via every TRX.

The slave TRX is initialised. The TRX returns to the working state and alarm 7606 TRX FAULTY is cancelled at both the BSC and the Remote BTS Manager. The calls are successful via every TRX.

Repeat with all slave TRXs.

Case Ref. Configuration O&M and TRXSIG BCCH TRX

1. 2+2 Combined Master

6.6.2 Antenna cable of Master TRX removed





The antenna cable from the master TRX is removed.

When the antenna cable is removed, alarm 7606 TRX FAULTY (Antenna connection faulty) is active at the BSC and the Remote BTS Manager.

Calls are dropped from the BCCH TRX and BCCH reconfiguration is performed. Calls on the TRX to be configured as BCCH in the sector are handed over before reconfiguration.



67 (107)



The antenna cable is connected to the master TRX and reset to the master TRX.

The BCF is initialised and returns to the working state. The connection is re-established and the Equipment view reappears showing the correct information. The Alarms window reappears and alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ can be seen on BSC and BTS Manager.

The alarm 7606 TRX FAULTY (Antenna connection faulty) is cancelled at both the BSC and the Remote BTS Manager.


Case Ref. Configuration O&M and TRXSIG BCCH TRX

1. 4 Omni Separate Master

6.7 Transmission menu commands

The purpose of these tests is to ensure that the commands in the Transmission menu work correctly when the FC E1/T1, FXC E1/T1, FXC E1 or FXC RRI transmission card is installed into the BTS.


The Remote BTS Manager session is started. The Remote BTS Manager session can be started successfully. Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is started at both the BSC and BTS Manager.

All commands (Identifications, Service Interface, Q1 Maintenance, LIF Settings, Synchronisation, Traffic Manager, Alarms, Statistics, Measurements, About E1/T1 Manager, Unit Settings) are tried from the Transmission menu. Various values are also verified.

The command selected can be executed successfully with the correct window displayed.

Case Ref. Configuration Transmission unit Transmission SW

1. Any FC E1/T1 ITN C1.0

2. Any FXC E1/T1 ITN C3.0

3. Any FXC E1 ITN C2.2

4. Any FXC RRI ITN C3.0



Remote BTS Manager

6.8 Stability test for Remote BTS Manager

The purpose of this test is to verify that after a long session, the Remote BTS Manager is still functioning successfully.


The BCF is operational and in a supervisory state. An LMU is connected to the site.

Start the Remote BTS Manager session.

The remote session is started successfully.

Alarm 7801 ‘MMI CONNECTED TO BASE STATION: Remote MMI connected’ is started at the BSC and the Remote BTS Manager.

Read the amount of memory used by Remote BTS Manager by selecting the Processes tab of the PC’s Task Manager.

By selecting Tests TRX test, a TRX test is started from the Remote BTS Manager menu command.

The command is executed successfully.

The Remote BTS Manager is left connected for 24 hours.

The Remote BTS Manager stays operational. No unexpected events occur (that is, unwanted alarms, or units missing from the display).

A TRX test is started from the Remote BTS Manager menu after the completion of 24 hours.

The command is executed successfully.

Read the amount of memory used by Remote BTS Manager by selecting the Processes tab of the PC’s Task Manager.

The Remote BTS Manager session is closed.

The used memory blocks by the Remote BTS Manager are the same as before the test was started.

The Remote BTS Manager session closed successfully.


1. Any

6.9 Multiple instances of Remote BTS Manager using the Node Manager

The purpose of this test is to verify that several Remote BTS Manager sessions for different BTSs can exist simultaneously on different BSCs using the Node Manager.

Input Expected OutputLog onto UNIX GUI NetAct, select the UNIX CITRIX Metaframe program to log onto the Node Manager Server (Windows 2000).



69 (107)


Input Expected OutputA Remote BTS Manager connection is made to BCF1 using the Node Manager. A Remote BTS Manager connection is made to BCF2 using the Node Manager, followed by a connection made to BCF3.

All three remote sessions operate simultaneously. Alarm 7801 MMI CONNECTED TO BASE STATION is started at the BSC for both BTSs, and the alarm is also visible at the separate BTS Managers.


The Remote BTS Manager session to BCF2 and BCF3 stays operational.


The Remote BTS Manager session to BCF1 and BCF3 stays operational.

UNIX GUI NetAct is logged onto and the Top Level User Interface (TLUI) is loaded. The icon to BCF4 is right-clicked. The Remote BTS Manager session is selected.

The Remote BTS Manager session uses the previously predefined values for BCF4 to successfully start the remote session.

Such additional sessions are started that one BSC has six different BCFs set up with successful Remote BTS Manager connections and the second BSC has four different BCFs set up with successful Remote BTS Manager connections. Each connection is set up to verify all ten sessions may be set up successfully. All Remote BTS Manager sessions are set up via the Node Manager. The Node Manager is logged onto using a PC and CITRIX.

The sessions are left running for 15 minutes.

All the remote sessions operate simultaneously. Alarm 7801 MMI CONNECTED TO BASE STATION is started at the BSC for the BCFs and the alarm is also visible at the separate BTS Managers.


1. Any. The total of 10 BCFs operational, 6 BCFs on one BSC and the remaining 4 BCFs on another BSC.

6.10 Adjusting the DAC Word

The purpose of this test is to check that the DAC word can be adjusted correctly from the Remote BTS Manager while User Access Level Control (UALC) is disabled.

Note 52. To disable the UALC feature, set the value of Registry Key ‘Access Levels’ under HKEY_LOCAL_MACHINE/SOFTWARE/NOKIA/2G_MANAGERS to ‘Off’.



Remote BTS Manager


The User Access Level Control feature is disabled.

Launch BTS Manager and establish a remote connection to the BTS.

BTS Manager is launched successfully.

The Remote BTS gets connected and BTS Manager shows the Equipment view, Alarms view and Events Window.

The Objects Clock Control command is selected. The DAC word is adjusted and ‘Set As Current’ is chosen.

The change in frequency can be seen from the frequency counter. The DAC word can be adjusted.

‘Use Fine Scale’ is chosen. The DAC word is adjusted and ‘Save Current Permanently’ is chosen. The window is closed and then opened again.

The DAC word can be adjusted and saved correctly.

The Objects Clock Control command is selected. ‘Disable BTS adjustment’ is selected. The DAC word is adjusted. The new DAC value is set as current value by choosing ‘Set as Current’. Now ‘Save Current Permanently’ is chosen.

The DAC word can be adjusted and saved correctly.

The BCF is left running for at least 20 minutes. The frequency stays constant.

The site is reset. The BTS comes up into the working state. The BTS will automatically adjust the frequency to synchronise with the Abis.

Case Ref. BTS Type/Configuration

1. Nokia MetroSite - Any



71 (107)


7 Intelligent Shutdown for MetroSite Note 53.

For all the Intelligent Shutdown test cases, neighbours are defined for the BTS under test. The neighbours defined shall not be involved within the testing of the feature except to handle the calls once handed over by the BSC unless otherwise stated.

Note 54. During Intelligent Shutdown, the shutdown TRXs shall get powered off. The TRXs shall no longer report to the BTS Manager and therefore shall not be visible on the Equipment view of the BTS Manager. The administrative state of the TRXs for the shutdown TRXs shall not be possible to be verified.

The exception to this rule shall be the Master TRX. This shall remain powered even in the shutdown mode. The Master TRX of the Master Cabinet shall also power off the Master TRX of the Slave cabinets, if all the TRXs in the Slave cabinet are in the Shutdown mode. The Master TRX, when left powered during the shutdown mode, shall be visible on the Equipment view and could be verified as shutdown.

The TRXs not in the shutdown mode shall be shown as supervisory.

The TRXs could be verified as being in the shutdown or supervisory mode on the BTS Manager using the objects/properties command.

Note 55. For the Intelligent Shutdown test cases, receiver diversity should be disabled.



Intelligent Shutdown for MetroSite

Note 56. For all the Intelligent Shutdown test cases, it is assumed that the testing shall be completed using an external BBU (EAC inputs) unless otherwise stated. The EAC input shall need to be set as detailed below. The predefined external input for MetroSite for the mains fail is EAC 01. ZEFX:<bcf_id>:INBR=1:ROU=MAINS:POL=<OPEN - active or CLOSED - inactive>,SEV=AL3;

Note 57. When a BTS_CONF_DATA message is received during intelligent shutdown, any units in the configuration message that are in the shutdown mode are unaffected. It is to be verified that a BTS_CONF_COMPL message is sent for the BCF in which the shutdown TRXs reside, even if the actual configuration is skipped for these.

Note 58. The feature consists of three BTS battery backup procedures that may be applied on a mains failure, these are:

• All shutdown mode - maintain full service,

• BCCH shutdown mode - maintain the BCCH TRXs, or

• None shutdown mode - maintain only the transmission equipment.

Note 59. It is possible to activate the Intelligent Shutdown with Timer Control with the MML command ‘EFM’: ZEFM:<bcf_id>:BBU=<BTS battery backup procedure>,NTIM=1,BTIM=3;

Where:

ZEFM:<BCF identification>:BBU<BTS battery backup procedure>, NTIM<TRX shutdown timer>, BTIM<BCCH TRX shutdown timer> where <TRX shutdown timer> and <BCCH TRX shutdown timer> are given as a decimal number.

NTIM=1 means that after a mains failure, there is full service on the BTS site for one minute before the service level is changed. This can be any value from 1 to 600 minutes.

BTIM=3 means that the BCCH TRXs will be maintained for three minutes after the non-BCCH TRXs are shut down, that is, until the BTIM timer expires. This can be any value from 1 to 600 minutes.



73 (107)


Timer 1 Timer 2 Timer 3 Timer 4 Timer 5TRX type Power State Power State Power State Power State Power State

TRX 1 – BCCH

ON WO ON WO ON WO ON BL-SHD

OFF BL-PWR

TRX 2 - TCH

ON WO ON BL-SHD

OFF BL-PWR

OFF BL-PWR

OFF BL-PWR

TRX 3 - TCH

ON WO ON BL-SHD

OFF BL-PWR

OFF BL-PWR

OFF BL-PWR

Figure 2. TRX’s powers and operational states during shutdown procedure, when only transmission equipment is left alive

7.1 Repetitive intelligent shutdown testing

The purpose is to test the stability of the intelligent shutdown when continuously triggered.

Note 60. A spectrum analyser is connected to the BCCH TRX to monitor the BCCH transmission.





A script, which simulates a mains failure with calls made before the mains failure, after different shutdown levels, and after the mains recovery is used.

The test is left ongoing for 24 h.


When the mains breakdown failure is triggered, the intelligent shutdown is started successfully. All levels are triggered as requested by the script and the site recovers fully after the mains recovery and BTS_CONF_DATA is sent successfully.

The TRXs to be shut down are being sent a shutdown request in the correct order.

The BSC and BTS Manager alarms history is viewed for the period of the test case.

No unwanted alarms are raised (for example, 76xx alarms) or unexpected object restarts occur (for example, TRX resetting).


1. Any multi-TRX

2. 4+4+4 chain configuration

7.2 TRX test

The purpose is to verify that TRX tests cannot be performed during the intelligent shutdown procedure from the BSC and BTS Manager.



A TRX test is started from the BSC for the modulation and TRX stated in the test cases, using the MML command ZUBS before a mains failure alarm, after each shutdown level and after the mains recovery.

The TRX test is successful except when the TRX is in the shutdown mode during intelligent shutdown.

The TRX Test command ZUBS will not execute from the BSC when the TRX is shutdown mode during intelligent shutdown.

The Tests TRX Test command is selected before a mains failure alarm, after each shutdown level and after the mains recovery. The TRX and modulation stated in the test cases is chosen as well as the relevant ARFN and radio TS for the TRX to be tested.

The TRX test is not possible on TRXs in the shutdown mode. The TRX test is successful in all other scenarios.


TRX tested Modulation

1. 2+21 EDGE Slave BCCH/Non-BCCH 8PSK/GMSK



75 (107)



2. 4+4+4 chain EDGE1 Master BCCH 8PSK 1 EGPRS enabled.

7.3 Abis loop test from BSC

The purpose is to verify that Abis loop tests cannot be performed during the intelligent shutdown procedure from the BSC.



An Abis loop test is started from the BSC for the TRX stated in the test cases, using the MML command ‘ZUBK’ before a mains failure alarm, after each shutdown level and after the mains recovery.

The Abis loop test is successful except when the TRX is in the shutdown mode.

The results are viewed for the Abis loop test. For the TRX before and after the mains failure, the results are acceptable. For the TRX in the shutdown mode, the result is stated as ‘Inconclusive’ with the remark ‘Test radio channel cannot be allocated’.

Case Ref. Configuration BCCH TRX TRX tested Tested configuration

1. 4+4+4 chain Slave Non-BCCH One TS in each cabinet

2. Multi-TRX Master BCCH One TS

7.4 BTS Manager connected to site in shutdown mode

The purpose is to verify that the BTS Manager can establish a successful connection to a site in the shutdown mode.

The site is set up with the None shutdown mode.





BTS Manager is not connected to the BTS.

The site is in the ‘None shutdown mode’ state.

BTS Manager is connected to the BTS.

The site status is checked at the Equipment view, Alarm window, Objects/Properties.

BTS Manager establishes a connection to the BTS successfully.

Only the Master TRX is shown in the Equipment view. The TRX is in the shutdown mode. All other TRXs are in the shutdown mode and are therefore not visible in the Equipment view.

Alarms 7801 MMI CONNECTED TO BTS and 7995 MAINS BREAKDOWN WITH BATTERY BACKUP are shown in the Alarms window of BTS Manager.

At the BSC, all units are in ‘BL-PWR. At the BTS Manager, the status can only be checked for the Master TRX. This is shown as SHUTDOWN (objects/properties).

The mains breakdown alarm is cancelled while the site is in the ‘None shutdown mode’ state.

Alarm 7995:MAINS BREAKDOWN WITH BATTERY BACKUP is cancelled at the BSC and BTS Manager. The BSC sends a BTS_PWR_SUPPLY_CONTROL (switch on each TRX) message to the BCF for each BTS.

All TRXs are powered and restarted. The TRXs once powered are visible at BTS Manager. The TRXs re-initialise successfully and are in WO at the BSC and supervisory state (objects/properties) in BTS Manager.


1. Multi-TRX EDGE/TRX

7.5 Alarm handling during the BCCH shutdown mode

The purpose is to verify alarm handling while the site is going through the intelligent shutdown process.


The site is in an operational state with calls ongoing on all TRXs.




77 (107)



A mains breakdown alarm is generated. Alarm 7995:MAINS BREAKDOWN WITH BATTERY BACKUP is reported at the BSC and BTS Manager. The site starts the shutdown procedure and enters the ‘BCCH shutdown mode’ state.

The TRX stated in the test case is removed from the BTS while the site is in the ‘BCCH shutdown mode’.

BCCH TRX: The TRX is removed and alarm 7606 TRX FAULTY: ‘Master TRX detected that connection to slave TRX is lost’ is sent to the BSC and BTS Manager. The calls on the BCCH TRX are dropped.

Non-BCCH TRX: As the TRX is in the shutdown state, alarm 7606 TRX FAULTY: ‘There is disturbance in the serial DL serial bus or bus is broken’ is not sent to the BSC.

The state of the TRXs is checked at BTS Manager (objects/properties).

The removed TRX disappears from the Equipment view and is not available to provide a description in the object/properties window.

BCCH TRX: Only the Master TRX is available to provide the status information. The Master TRX is identified as ‘shutdown’, and the state of BCCH TRX is identified as ‘missing from configuration’.

Non-BCCH TRX: Only the BCCH and Master TRX are available to provide the status information. The Master TRX is identified as ‘shutdown’, and the BCCH TRX is identified as supervisory.

The TRX is re-installed. BCCH TRX: The TRX is re-installed and alarm 7606 TRX FAULTY: ‘Master TRX detected that connection to slave TRX is lost’ is cancelled at the BSC and at BTS Manager. The TRX initialises successfully and is in WO.

Non-BCCH TRX: As the TRX was in the shutdown state, the TRX returns to the shutdown state and is not powered up.

New calls are made on the BCCH TRX. The calls are successful.

Case ref. Configuration TRX removed BCCH TRX

1. 4+4+4 chain configuration Non-BCCH Slave

2. Multi-TRX BCCH Slave




7.6 Intelligent shutdown while alarms present

The purpose is to verify that the intelligent shutdown operates successfully while other alarms exist on the BTS.


A CS call is established on every TRX.

The Intelligent Shutdown is activated for the NONE shutdown mode.

ZEFM:<bcf_id>:BBU=NONE;

All the calls are successful.

The site is fully operational. A TRX working as a non-BCCH TRX is removed. The removed TRX cannot be the Master TRX.

When the TSxx is removed, alarm 7606 TRX FAULTY (There is a disturbance in the serial DL bus or bus is broken) is sent to the BSC. The TRX is blocked at the BSC. The calls via the removed TRX are released. An alarm from the missing TRX can be seen via BTS Manager and at the BSC.

A mains breakdown alarm is generated. The site starts the shutdown procedure and enters the ‘NONE shutdown mode’.

Alarm 7606 TRX FAULTY (Master TRX detected that connection to slave is lost) is cancelled and the BCCH and Non-BCCH TRXs are shut down. Transmission units remain active.

The mains breakdown alarm is cancelled. The BCCH and Non-BCCH TRXs are initialised and in WO state. Alarm 7606 TRX FAULTY (Master TRX detected that connection to slave is lost) is re-sent to the BSC and BTS Manager for the removed TRX.

New CS calls are established. All the calls are successful.

The TRX is re-installed. Alarm 7606 TRX FAULTY is cancelled. The TRX is initialised and is in WO state.

A new CS call is started on the re-inserted TRX. The call is successful.

The test is repeated three times.

Case ref. Configuration 1. Multi-TRX GSM/EDGE



79 (107)


8 Recovery for BSS and Site Synchronisation

Note 61. Prior to S11 it was not possible for MetroSite to be synchronised from an external LMU or a base station. (Talk base stations used the jumper settings on the BCFB to determine the sync mode when connected to a BSC running S10.)

In order for the network to recover automatically from a loss of synchronisation,greater control is exercised by the BSC. So in S11 onwards, the base station is told by the BSC in the BTS_CLOCK_REQ message which synchronisation mode it should be in.

8.1 Site Synchronisation: BCF reset

The purpose of these tests is to verify that the base station initialises into the correct synchronisation mode.

8.1.1 Clock Source – Talk




Recovery for BSS and Site Synchronisation


Create the sites at the BSC depending upon the configuration indicated in the table and in the diagrams below.

Define the synchronisation chain in the BSC using the MML command:

ZEFM:<mm>:CS=BCF,SENA=T,ADD=<s1>&<s2>;

<mm> = master BCF number

<s1> = slave 1 BCF number


Lock all the TCH channels except timeslot 4 on each TRX in the multi-BCF segment.

Physically create and commission the sites.

Monitor the BTS Events window in BTS Manager, or the Messages and Alarms window in the BTS MMI.

Monitor the Abis.

Reset the Master BCF using the MML command:

ZEFR:<BCF No>;

The BSC sends the Master BCF a BTS_RESET REQ with the object identity = BCF.

The Master BCF resets and sends a BTS_OMU STARTED message with the synchronisation mode = master.

The Slave BCFs raise a loss of synchronisation alarms but continue to operate.

The Master BCF sends a BTS_CONF_REQ to the BSC. The BSC sends a BTS_CLOCK_REQ to the BTS with the Clock sync = PCM_External.

The Clock output = enabled.

The BSC sends the configuration of the Master BCF in the BTS_CONF_DATA. The BCF comes into working order. The BTS Events window shows that the BCF is in the Master mode.



81 (107)



Once the Master BCF has come into working order, the BSC sends the Slave BCFs a BTS_RESET_REQ with the object identity = BCF. The slaves reset and send a BTS_OMU_STARTED message with the synchronisation mode = as per table.

The Slave BCFs send a BTS_CONF_REQ to the BSC.

The BSC sends a BTS_CLOCK_REQ to the BTS with:

the Clock sync = BTS_External

the Clock output = disabled

The BSC sends the configuration of each site in the BTS_CONF_DATA. The BCFs come into working order. The BTS Events window shows that the BCFs are in the Slave mode. No indication of which device is the clock master should be given.

Lock 6 MSs to the segment. Make 3 pairs of speech calls. Speech is maintained.


Repeat the reset/call sequence a total of 5 times. The site’s behaviour is repeatable.

Case Ref. Chain Configuration BTS Software Sync Mode in BTS_OMU_STARTED

1. Figure 3 DF7, CXM5, CXM5 Independent




Figure 3 Talk – MetroSite – MetroSite



83 (107)


8.1.2 Clock Source - LMU



ZEFM:<s1>:CS=LMU,SENA=T,ADD=<s2>;






Monitor the Abis.

Reset the Slave BCF(s) using the MML command:

ZEFR:<BCF No>;

The BSC sends each Slave BCF a BTS_RESET REQ with the object identity = BCF.

The BCF resets and sends a BTS_OMU STARTED message with the synchronisation mode = as per table.

Each BCF sends a BTS_CONF_REQ to the BSC. The BSC sends a BTS_LMU_FN_OFFSET COMMAND to the BCF next to the LMU. The BTS returns a BTS_LMU_FN_OFFSET_ANSWER with the success-failure = success (assuming the LMU is operating correctly).

The BSC sends a BTS_CLOCK_REQ to all the BCFs with:


the Clock output = disabled

The BSC sends the configuration of the sites in the BTS_CONF_DATA messages. The BCFs come into working order. The BCFs send a BTS_CONF_COMPLETE. The BTS Events/MMI window shows that the BCFs are in the Slave mode and that the LMU is Master.



Repeat the reset/call sequence a total of 5 times.

The site’s behaviour is repeatable.




Case Ref. Configuration DF SW LMU SW Sync Mode in BTS_OMU_STARTED

1. Figure 5 - 4.1 Independent

2. Figure 4 7.0 4.1 Talk = Slave, Metro = Independent

Set up hopping in the same way as in Figure 5 below.

Figure 4. LMU – Talk – MetroSite



85 (107)


Figure 5 LMU – MetroSite – MetroSite

8.2 Recovery from sync failures on initialisation

The purpose is to check that a fault with a synchronisation cable does not cause a failure beyond the site concerned. To check that once the fault has been corrected, the site can be recovered.





Create the sites at the BSC depending upon the configuration indicated in the table and in the diagrams below. Lock all the TCH channels except timeslot 7 on each TRX in the multi-BCF segment.

Define the synchronisation chain in the BSC using the MML command BSS synchronised chain:




Physically create and commission the sites, so that they are in working order, synchronised to the LMU.

For Talk-family, use DF7.

Power off the sites.

Disconnect the LMU cable at the connector indicated in the table.

Monitor the Messages and Alarms window in the BTS MMI or the BTS Events window in BTS Manager.

Monitor the Abis. Record a trace.

Power on the BCF next to the LMU.

The BCF does not initialise and synchronise to the LMU.

It is clear from the status at BTS Manager/MMI that there is a fault.

Record the status at the BSC using the MML commands:

ZEOL:<BCF number>;

ZEEI:BCF=<BCF number>;

Continue recording the Abis trace.

Re-connect the cable.

Make a note of changes in the alarm status.

The LMU clock output is switched on.

Use LMU Manager Commissioning Wizard to ensure that.

Reset the first BCF using the MML command:

ZEFR:<BCF number>;

The BCF comes into working order synchronised to the LMU.

All alarms caused by the fault are cancelled.

Check the sync mode at BTS Manager. The Sync mode = slave.

Power up the remaining BCFs. The BCFs come into working order synchronised to the LMU.





87 (107)



Repeat the whole power on failure sequence a second time.

The site’s behaviour is repeatable.

Case Ref. Configuration SW versions Connector to Disconnect

1. Figure 5 LMUB 1.0 EXT

2. Figure 5 LMU 4.4 Q1

3. Figure 4 LMU 4.4 BTS/Q1 IF

4. Figure 4 LMUB 1.0 48V

5. Figure 4 LMUB 1.0 FN/FCLK

6. Figure 4 LMU 4.4 SBCK/TCLK

7. Figure 4 LMU 4.4 Q1

8.3 Sync recovery when GPS fix never achieved on initialisation

The purpose is to check that the recovery process executes correctly if the LMU has no GPS fix when the BCF initialises.






For DF6.0-3: No command


At LMU Manager, select View → Advanced. Select Maintenance. Open the ‘Clock Out Time Settings…’ dialogue box. Set the Time from fix lost to clocks out alarm to 60 seconds. Set the Time from clocks out alarm to clock disable to 60 seconds.


Power off all the BCFs.

Disconnect the LMU’s GPS signal. Wait 4 minutes.





Monitor the Abis and the Q1 bus.

Power on the BCFs.

The first BCF resets. After the BCF has sent the BTS_CONF_REQ message, the BSC responds with the BTS_LMU_FN_OFFSET_COMMAND.

The BCF forwards the FN_OFFSET to the LMU via the Q1 bus.

The LMU responds with a GPS Fix Lost alarm on the Q1 bus.

The BCF sends a BTS_LMU_FN_OFFSET_ANSWER with the success/failure = fail.

The BSC sends a BTS_CLOCK_REQ message to the BCF with

the Clock out = Enabled

the Clock sync = PCM_External

The first BCF comes into working order in the Master mode, synchronised to the Abis PCM. The second BCF comes into working order synchronised to the new Master BCF.



For DF7:

The status for all BCFs = WO.

Check the sync status using the MML command:

ZEFL;

The Sync Enabled = T, Sync Mode = UnSynch for the synchronisation chain.

Check the sync mode of each BCF in BTS Manager/BTS MMI.

First BCF sync mode = Master.

Second BCF sync mode = Slave.



Monitor the Q1 bus and the Abis.

Re-establish the GPS signal to the LMU.

The LMU cancels alarm 48 on the Q1 bus and this is forwarded by the BCF as a cancellation of alarm 8048 on the Abis.

All calls drop because there is no neighbour to hand over to.

Check the status of the BCFs using the MML command:


Immediately the calls drop, the BCFs show as BL-BCF or BL-SYS at the BSC.



89 (107)



Monitor the MMI and Abis for all of the BCFs. The BSC resets the first BCF in the chain. The BSC sends a BTS_CLOCK_REQ message on the Abis, with:


the Clock output = Disabled

The first BCF comes into working order in the slave mode synchronised to the restored clock from the LMU.

After the first BCF has sent the BTS_CONF_COMPL message, the BSC resets the second BCF. The BSC sends a BTS_CLOCK_REQ message on the Abis, with:

the Clock sync value = BTS_External


The BCF comes into working order in the slave mode.

Check the sync status at the BSC for all BCFs, using the MML command:

ZEFL;

The Sync Enabled = T, Sync Mode = Sync for all BCFs in the chain.



Case Ref. Chain configuration Software

1. Figure 4 LMU SW Version: LMU 4.4 / DF SW: 7

2. Figure 5 LMU SW Version: LMUB 1.0

8.4 Sync recovery - missing GPS signal

The purpose is to check that a previously synchronised chain behaves correctly when the LMU’s GPS signal is lost and then returns. To check that recovery actions are not triggered if the GPS outage time is less than the LMU timer period. To check that the base station responds correctly to the BSC’s control when the recovery actions are triggered by an outage longer than the LMU timer period.




Note 62. With BSC releases S11 onwards, the LMU has an internal timer. If the GPS fix is lost for less than the timer period, the LMU continues to send its clock signal. The synchronisation chain of the BCFs continues to be synchronised by the LMU as if nothing had happened.

After the LMU’s timer has expired, it sends alarm 1001 clock out disabled, which triggers the recovery procedure when it is received at the BSC.

Note 63. It is necessary to perform this test either in a screen room, or by fully cabling the Mobile Stations to the base stations. This is because the MS must be able to see, and hand over to, a neighbouring cell, and cannot therefore be locked into the segment being used for test.

8.4.1 GPS signal lost for less than LMU timer period



Also, unlock timeslot 7 on TRX4 in each BTS in the segment. Make this a dedicated GP timeslot.

Ensure there is a neighbouring BTS, to which calls on the synchronised BCFs may be handed over. Set the BTS power level of the neighbouring BTS much lower than the segment so that the MSs prefer the segment.

At LMU Manager, select View → Advanced. Select Maintenance. Open the ‘Clock Out Time Settings…’ dialog box. Set the Time from fix lost to clocks out alarm to 240 seconds. Set the Time from clocks out alarm to clock disable to 60seconds.


When The BCF resets, it sends a BTS_OMU STARTED message with the synchronisation mode = slave, regardless of the setting in the HW configuration file.



91 (107)



Camp 8 MSs on to the segment. Make sure they can also see the neighbouring BTS. That is, it will not be possible to use the MS field test software to lock them to the segment. Make 4 pairs of speech calls. Speech is maintained. These calls will be left up during the test case.

Also establish a further 2 MSs, each with a GPRS transfer ongoing.


Monitor the Q1 bus. Monitor the Abis for O&M messages.


Disconnect the GPS antenna from the LMU, or block the antenna’s view of the satellite. At the same time, start a stop-clock to monitor the length of time the GPS signal is missing.

The LMU sends a GPS fix lost alarm 48 on the Q1 bus. The BCF sends this up the Abis as an 8048 alarm. However, the LMU does not send a 1001 clock disable alarm. The BCFs continue to be synchronised by the clock signal from the LMU.

Check the status of the calls and transfers.

Check the sync status at BTS Manager/MMI.

Check the sync status at the BSC using the MML command: ZEFL;

All calls remain up. Both GPRS transfers remain ongoing.

The BCFs still show as being in the slave mode.

The Sync Enabled = T, Sync Mode = Sync for the synchronisation chain.

At 3 minutes on the stop-clock, re-establish the GPS signal to the LMU.

The LMU sends an alarm 48 cancel on the Q1 bus. The BCF forwards this as an 8048 cancel on the Abis. The BSC does not begin any further recovery actions when it receives this alarm.

All calls/transfers remain up. The BCFs continue to be synchronised by the clock signal from the LMU.

At 4 minutes, monitor the Q1 bus. The LMU does not send any alarms, that is, the LMU timer was successfully reset.

Case Ref. Configuration Software

1. Figure 6 LMU SW Version: LMU 4.4




8.4.2 GPS signal lost for more than LMU timer period


Create the sites at the BSC, depending upon the configuration indicated in this table and in the diagrams below. Lock all TCH channels except timeslot 2 on each TRX in the Multi-BCF segment.

Also, unlock timeslot 7 on TRX4 in each BTS in the segment. Make this a dedicated GP timeslot.

Make sure there is a neighbouring BTS to which calls on the synchronised BCFs may be handed over. Set the BTS power level of the neighbouring BTS much lower than the segment so that MSs prefer the segment.

At LMU Manager, select View → Advanced. Select Maintenance. Open the “Clock Out Time Settings…” dialog box. Set the Time from fix lost to clocks out alarm to 240 seconds. Set the Time from clocks out alarm to clock disable to 60 seconds.


When the BCF resets, it sends a BTS_OMU STARTED message with synchronisation mode = Slave, regardless of the setting in the HW configuration file.

Camp 8 MS on to the segment. Make sure they can also see the neighbouring BTS. That is, it will not be possible to use the MS field test software to lock them to the segment. Make 4 pairs of speech calls. Speech is maintained.

These calls will be left up during the test case.

Also establish a further 2 MSs, each with a GPRS transfer ongoing.


Monitor the Q1 bus. Monitor the Abis for O&M messages.


Disconnect the GPS antenna from the LMU, or block the antenna’s view of the satellite. At the same time, start a stop-clock to monitor the length of time the GPS signal is missing.

The LMU sends a GPS fix lost alarm 48 on the Q1 bus. The BCF sends this up the Abis as an 8048 alarm. However, the LMU does not send a 1001 clock disable alarm. The BCFs continue to be synchronised by the clock signal from the LMU.



93 (107)



Check the status of the calls.

Check the sync status at BTS Manager/MMI.

Check the sync status at BSC using the MML command: ZEFL;

All calls remain up.

The BCFs still show as being in the slave mode.

The Sync Enabled = T, Sync Mode = Synch for the synchronisation chain.

At 4 minutes on the stop clock, monitor the Q1 bus and Abis.

The LMU sends alarm 1001 clocks out disabled. The first BCF forwards this alarm up the Abis to the BSC as:

Talk: 7876 LMU. External synchronisation signals disabled.

MetroSite: 7602 BCF NOTIFICATION. External synchronisation signals disabled. (Alarm detail = 28.)

All calls hand over successfully to the neighbouring BTS. Both GPRS transfers successfully reselect the neighbouring BTS.


ZEEI:BCF = <BCF number>;

Immediately following the handover of calls, the BCFs show as BL-BCF or BL-SYS at the BSC.

Monitor the MMI and Abis for all the BCFs. The BSC resets the first BCF in the chain. The BSC sends a BTS_CLOCK_REQ message on the Abis, with:

the Clock sync = PCM_External

the Clock output = Enabled

The first BCF comes into working order in the master mode.





Check the MS carrying the GPRS transfers. The MSs reselect the BTS in the segment again.

Check the sync status at the BSC for all BCFs, using the MML command:

ZEFL;

The Sync Enabled = T, Sync Mode = Unsync for all BCFs in the chain.





Check for 8048 GPS fix lost alarm at the BSC using the MML command:

ZEOL:<first slave BCF number>;

Alarm 8048 is still active.

Disconnect the calls now on the neighbour. Re-establish 4 pairs of calls in the segment. Speech is maintained.


Monitor the Q1 bus and the Abis.

Re-establish the GPS signal to the LMU.

The LMU cancels alarm 48 on the Q1 bus and this is forwarded by the BCF as a cancellation of alarm 8048 on the Abis.

All calls hand over successfully to the neighbouring BTS. The GPRS transfers reselect the neighbouring BTS.



Immediately following the handover of calls, the BCFs show as BL-BCF or BL-SYS at the BSC.

Monitor the MMI and Abis for all the BCFs. The BSC resets the first BCF in the chain. The BSC sends a BTS_CLOCK_REQ message on the Abis, with:



The first BCF comes into working order in the slave mode synchronised to the restored clock from the LMU.





Check the MS carrying the GPRS transfers. The MSs reselect the BTS in the segment again.

Check the sync status at the BSC for all BCFs using the MML command:

ZEFL;

The Sync Enabled = T, Sync Mode = Sync for all BCFs in the chain.

Disconnect the calls now on the neighbour. Re-establish 4 pairs of calls in the segment. Speech is maintained.




95 (107)


Case Ref. Configuration Software1. Figure 6 LMU SW Version: LUMB 1.0

Set up hopping in the same way as in Figure 5 above.

Figure 6 LMU – MetroSite – MetroSite + Neighbour

8.5 Sync recovery – missing clock cable for slave MetroSite

The purpose is to check that a previously synchronised chain behaves correctly when the clock cable is disconnected from the master cabinet.

Note 64. It is necessary to perform this test either in a screen room, or by fully cabling the Mobile Stations to the base stations. This is because the MS must be able to see, and hand over to, a neighbouring cell, and cannot therefore be locked into the segment being used for test.






Ensure there is a neighbouring BTS, to which calls on the synchronised BCFs may be handed over. Set the BTS power level of the neighbouring BTS much lower than the segment so that the MSs prefer the segment.


ZEFM:<mm>:CS=BCF,SENA=T,ADD=<s1>&<s2>;




Physically create and commission the sites, so that they are in working order, synchronised to the master BCF.

Lock 6 MSs to the segment. Make 3 pairs of speech calls. Speech is maintained. These calls will be left up during the test case.


Monitor the Abis.

Disconnect the FCLK cable from the master cabinet.

The first slave BCF sends alarm: 7602. BCF NOTIFICATION: Base station synchronisation failed.

Check the status of the MS. The BSC initiates forced handovers from the slave BCFs to the neighbouring BTS.

2 pairs of calls hand over successfully.

The calls on the Master BCF remain on that BCF without dropping.



Immediately following the handover of calls, the slave BCFs show as BL-BCF at the BSC.

The Master BCF remains in working order.

Check the sync status at the BSC using the MML command:

ZEFL;

The Sync Enabled = T, Sync Mode = Unsync for the slave BCFs in the synchronisation chain.



97 (107)



Monitor the Abis for O&M messages. Reconnect the clock cable to the Master BCF.

The slave BCFs send an alarm 7602 cancel to the BSC on the Abis.

The BSC resets the slave BCFs in the chain. The BSC sends a BTS_CLOCK_REQ message on the Abis, with:



The slave BCFs come into working order in the slave mode synchronised to the clock from the Master BCF.

Two pairs of calls are handed over to the slave BCFs from the neighbouring BTSs.

Check the status of the remaining pair of calls on the Master BCF.

The calls remain connected.

Disconnect all the calls. Re-establish a total of 3 pairs of calls on the segment. Speech is maintained.


Case Ref. Chain Configuration Software1. Figure 7 DF7

Set up hopping in the same way as in . Figure 5

Figure 7 Talk – MetroSite – MetroSite -+ Neighbour



Multi-BCF for MetroSite

9 Multi-BCF for MetroSite 9.1 Multi-BCF Functionality

The purpose of this test is to check that Site reset, BTS lock/unlock works correctly, and that basic speech calls, GPRS and EGPRS transfers can be made.


Create the sites at the BSC depending upon the type of TRX and hopping mode indicated in the table and the diagrams below. Configure the BCCH in the BTS shown in the test case.

Note that it will be necessary to create and attach a suitable EDAP to the TRXs in BTS 4.

Define the synchronization chain in the BSC using the MML command:

ZEFM:<mm>:CS=BCF,SENA=<T/F>,ADD=<s1>;

<mm> = Master BCF number (Talk)

<s1> = Slave BCF number (MetroSite)

<T/F> = F for DF6

= T for DF7.0 onwards

Set the jumper in the BCFB to the Master position.

Physically create and commission the sites. Note that it will be necessary to attach the TRXs in BTS 4 to the EDAP when allocating the Abis timeslots using Traffic Manager.

Monitor the BTS Events window in BTS Manager connected to the MetroSite.

The MetroSite reports its sync mode = Slave, and indicates that Talk is Master.






99 (107)




ZEOL:<bcf number>;


Check the sync status at the BSC using the MML command:

ZEFL;

DF6.0 Sync Enabled = F

DF7.0 onwards Sync Enabled = T, Sync Mode = Sync for the synchronisation chain

Reset BCF 1 using MML command:

ZEFR:<bcf number>;

BCF 1 resets and comes into supervisory state.

DF7.0 onwards: The BSC then resets BCF 2.

DF6.0- : the Slave BCF needs to be reset from the BSC.



The BCFs, BTSs and TRXs are all in WO.

Lock a pair of MS onto each BCCH frequency. Make sufficient speech calls so that each TRX in each segment is used. Speak in both directions while each TRX is used.

The calls do not drop. The MS displays the expected ARFN for each TRX used. The speech in each direction can be heard clearly. All TRX in the segment are used.

Lock a Non-BCCH BTS using MML command:




The correct BTS shows as being locked.

Make speech calls as before on the segment that contains the locked BTS. Leave one call ongoing.

All calls are assigned to TRX in the BCCH BTS.

Unlock the BTS using MML command:




The BTS resets. The ongoing call is unaffected.

All objects are Unlocked and in WO.

Repeat the lock/unlock process for each Non-BCCH BTS in turn.

Lock a BCCH BTS using MML command:



If the BCCH TRX is MetroSite, its LED will change to orange.



The correct BTS shows as being locked.

Check the status on the MS displays. There is no BCCH signal present on the display of the MS locked to the BTS that has been locked. The other two MS still have good BCCH signals.





Unlock the BCCH BTS using MML command:





All objects are Unlocked and in WO.

Repeat the lock/unlock process for each BCCH BTS in turn.

Lock a pair of MS onto each BCCH frequency. Make sufficient speech calls so that each TRX in each segment is used. Speak in both directions while each TRX is used.

The calls do not drop. The MS displays the expected ARFN for each TRX used. The speech in each direction can be heard clearly. All TRX in the segment are used.

Allocate most radio timeslots to GPRS on BTS 1 using MML command:

ZEQV:BTS=<bts number>:CDED=100,CDEF=100,CMAX=100;

Allocate only 1 GPRS timeslot on BTS 4 using MML command:


Enable GPRS for Segment 1 using MML command:

ZEQV:SEG=<seg number>:GENA=Y;

Check the allocation of GP timeslots at the BSC using MML command:

ZERO:BTS=<bts number>;

All timeslots (or nearly all) on BTS 1are allocated as GP. Only one timeslot is allocated to GP on BTS 4.

Attach a GPRS MS to Segment 1. The MS attaches successfully.

Activate a PDP Context. The PDP Context activates successfully (MS dials up and connects to server).

FTP transfers a 1Mbyte file from the server (downlink transfer).

The transfer completes successfully. The file transferred is error-free.

FTP transfers a 1Mbyte file to the server (uplink transfer).

The transfer completes successfully. The file transferred is error-free.

End the FTP session. De-activate the PDP Context (disconnect), and switch OFF the GPRS MS.

Increase the number of GP timeslots allocated on BTS 4 using MML command:


Enable EGPRS on BTS 4 using MML command:

ZEQV:BTS=<bts number>:EGENA=Y;



101 (107)



Check the allocation of GP timeslots at the BSC using MML command:

ZERO:BTS=<bts number>;

Half the timeslots on BTS 4 are now allocated as GP. The allocation on BTS 1 is unaffected.

Attach an EGPRS MS to Segment 1. The MS attaches successfully.

Activate a PDP Context. The PDP Context activates successfully (MS dials up and connects to server).

FTP transfers a 1Mbyte file from the server (downlink transfer).

The transfer completes successfully using BTS 4. The file transferred is error-free.

FTP transfers a 1Mbyte file to the server (uplink transfer).

The transfer completes successfully using BTS 4. The file transferred is error-free.

End the FTP session. De-activate the PDP Context (disconnect), and switch off the GPRS MS.

Case Ref.

Configuration BTS 1 BTS 2 BTS 3 BTS 4 BTS 5 BTS 6

1. Figure 8

Talk SW DF7.0

TRXD or

TRXA

Non-hop

BCCH

TRXD or

TRXA

Non-hop

BCCH

TRXD or

TRXA

Non-hop

BCCH

CTDA or

CTGA

Non-hop

CTDA or

CTGA

Non-hop

CTDA or

CTGA

Non-hop

2. Figure 9

Chained MetroSite.

Talk SW DF 6.0-3

1900 Band

RF-hop

1900 Band

RF-hop

1900 Band

RF-hop

800 Band EDGE

Non-hop BCCH

800 Band EDGE

RF-hop

Same MA as BTS 2 BCCH

800 Band EDGE

Non-hop BCCH




Figure 8 Talk – Single MetroSite Multi-BCF



103 (107)


Figure 9 Talk – Chained MetroSite Multi-BCF configuration

9.2 Multi-BCF start-up order

The purpose is to check that the multi-BCF sites come into working order regardless of the order in which they are powered up.


Create the synchronisation chain at the BSC using the MML command:

ZEFM:<mm>:CS=BCF,SENA=T,ADD=<s1>;




Make calls on all TRXs. All calls are successful.







Power on the Master BCF.

The Master BCF comes into working order without raising any synchronisation alarms.

The BTS Events window shows that the BCF is in the Master mode.

Power on the chained MetroSites. The slave BCFs come into working order without raising any synchronisation alarms.

The BTS Events window shows that the BCFs are in the slave mode.



Power on the chained MetroSites.

During initialisation, the Slave BCFs raise alarm 7600 BCF FAULTY: Base station synchronisation failed. The sites are blocked BCF at the BSC.

Power on the Master BCF. The Master BCF initialises. When it synchronises to the PCM, the clock signal becomes available to the Slave BCFs and their alarms are cancelled.

All three sites come up into working order. The BTS Events window shows that each BCF is in the correct sync mode.

Make calls on all TRXs. All calls are successful.

Case Ref. Configuration BTS SW1. Figure 3 DF7, CXM5, CXM5



105 (107)

References

References 1. Software Design Manual, SW Releasing Procedure, B6I 041888AE

2. Functional Regression Test Specification for BTS SW CXM5, DN0691353 (Issue 1-0)

3. Regression Test Specification for Validating BTS SW CXM4.1 CD1.0, DN0615803 (Issue 1-0)

4. Feature Descriptions (BTS SW CXM5), DN04196267 (Issue 3-0)

5. Nokia MetroSite EDGE BTS, CXM5, Product Documentation

6. Nokia Electronic Documentation for MSC

7. Nokia Electronic Documentation for BSC



107 (107)

system verification dn0691365x1x0xen

Documents

nokia logo

copyright nokia corporation

nokia base station

software requirements

hardware requirements

mentioned hardware

product names

free of material errors