Common Telecom Regression Test Specification © Nokia Siemens Networks

DN0694168 Issue 1-0

© Nokia Siemens Networks

1 (252)

CX(M)6 Common Telecom Regression Test Specification

CX(M) 6 Common Telecom Regression Test Specification

2 (252) © Nokia Siemens Networks Confidential

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given “as is” and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT. This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright © Nokia Siemens Networks 2008. All rights reserved.

Contents

DN0694168 Issue 1-0

© Nokia Siemens Networks Confidential

3 (252)

Contents

1 Vocabulary............................................................................ 8

2 Introduction ........................................................................ 12 2.1 Scope ................................................................................... 12 2.2 Hardware Requirements ...................................................... 13 2.3 Software Requirements........................................................ 14 2.4 Specialist Test Equipment Requirements ............................ 15

3 Speech call setup............................................................... 17 3.1 Speech and Emergency call Setup via SDCCH .................. 17 3.2 Dynamic SDCCH Reservation ............................................. 19 3.3 Rx Diversity testing during speech call ................................ 20 3.4 Speech Call and Emergancy Call Setup via FACCH........... 21 3.5 Support for Different Ciphering Algorithms .......................... 22

4 Single Timeslot Data Call Setup ....................................... 24 4.1 Non-Transparent Data via SDCCH...................................... 24 4.2 Non-Transparent Data via FACCH ...................................... 26 4.3 Transparent Data via SDCCH.............................................. 27 4.4 Transparent Data via FACCH .............................................. 28 4.5 Group 3 Fax via SDCCH...................................................... 29

5 Multislot Data Call Setup................................................... 31 5.1 Non-Transparent Data via SDCCH...................................... 31

6 Short Message Service...................................................... 33 6.1 Originating & Terminating SMS on SDCCH......................... 33 6.2 Terminating SMS in Dedicated Mode .................................. 34

7 GPRS Operation in BTS..................................................... 36 7.1 GPRS Synchronization in BTS ............................................ 36 7.2 Paging Modes ...................................................................... 39 7.3 Data Transfer ....................................................................... 40 7.4 Data Transfer with Radio Link Failure.................................. 43 7.5 SMS via Packet Data ........................................................... 44 7.6 Cell Reselection and Timing Advance ................................. 45

8 Adaptive Multi Rate Codec................................................ 46



8.1 AMR Call Setup via SDCCH and Link Adaptation (LA) ....... 48 8.2 AMR Call Setup with Mobiles Moving .................................. 50 8.3 Packing/Unpacking of AMR Calls with Fast LA/Slow LA ..... 51 8.4 Slow Link Adaptation with Uplink DTX ON .......................... 54 8.5 Intercell Handover from AMR Cell to Non-AMR Cell ........... 55

9 BTS Idle Mode Functions .................................................. 56 9.1 SMS Cell Broadcast............................................................. 56 9.2 RACH and PRACH Success Rate under C/I Conditions ..... 57

10 Dedicated Mode Functions ............................................... 59 10.1 SDCCH Handovers.............................................................. 59 10.2 Intra Cell Handover .............................................................. 59 10.3 Inter cell Asynchronous Handover ....................................... 61 10.4 Inter Cell Synchronous Handover ........................................ 63 10.5 Intra-Cell Handovers within a Multi-BCF Segment .............. 66 10.6 Inter-Cell Handovers between Multi-BCF Segments ........... 69 10.7 Automatic Link Adaptation ................................................... 80 10.8 Multislot Upgrade / Downgrade............................................ 81 10.9 DTX Applied to Speech & Data calls ................................... 82 10.10 DTX Applied to Speech Calls without handovers ................ 85 10.11 Measurement Pre-processing.............................................. 86 10.12 Interference with HR channel when high traffic ................... 86 10.13 Mobile Speed Handling........................................................ 88 10.14 BTS Power Control .............................................................. 89

11 Recovery from Fault Conditions ...................................... 92 11.1 TRAU Frame Breaks............................................................ 92

12 Separate RLT Parameter for AMR and EFR..................... 94 12.1 Radio link timeout with speech call ...................................... 95 12.2 Radio link timeout on TCH for EFR/FR with change of

ARLT.................................................................................... 97 12.3 Radio link timeout on TCH for AMR with change of RLT..... 98 12.4 Radio link timeout on TCH for AMR with different values of

ARLT.................................................................................. 100 12.5 Radio link timeout on TCH for AMR with change of ARLT 102 12.6 Radio link timeout on TCH for AMR and GP recovery....... 103 12.7 Radio link timeout with Handover ...................................... 104 12.8 Object control and Radio link timeout ................................ 106 12.9 AMR packing/unpacking and Radio link timeout................ 108

Contents

DN0694168 Issue 1-0


5 (252)

12.10 Multiple speech calls and Radio link timeout ..................... 109 12.11 Multiple speech calls with change in RLT/ARLT................ 110 12.12 Multiple Breaks at Air interface .......................................... 111 12.13 T200 Expiry ........................................................................ 112

13 Dynamic A-bis Allocation................................................ 114 13.1 Downlink Resource Allocation Loading.............................. 114 13.2 Uplink Resource Allocation Loading .................................. 115 13.3 Maximum Dynamic Pool Size ............................................ 116

14 Enhanced Data Rates for Global Evolution, EDGE....... 117 14.1 EGPRS MCS 1-9 & Incremental Redundancy................... 118 14.2 Link Adaptation in Unack Mode (Changing Air Interface

Conditions) ......................................................................... 120 14.3 Link Adaptation in Ack Mode (Changing Air Interface

Conditions) ......................................................................... 122 14.4 GPRS Data transfer when EGPRS is enabled .................. 125 14.5 GPRS & EGPRS TBFs on One Timeslot........................... 126 14.6 GPRS Link Adaptation ....................................................... 127 14.7 EGPRS/GPRS Territory Upgrade/Downgrade................... 129 14.8 Multiple TBFs on One Timeslot at Different Distances ...... 130 14.9 Cell Reselection & Timing Advance with EGPRS.............. 131 14.10 EGPRS Reliability at Various MS Speeds ......................... 132 14.11 EGPRS Reliability at Various Distances ............................ 134 14.12 GPRS transfer when EGENA is OFF................................. 135 14.13 EDAP mismatch between BSC and the BTS Manager...... 136 14.14 RF Performance & Power Control ..................................... 137 14.15 Break (Air Interface and A-bis) in EGPRS ......................... 139

15 EGPRS Channel Requirement on CCCH ....................... 141 15.1 EPCR Capability Reporting................................................ 141 15.2 PRACH Types on CCCH and PCCCH .............................. 142

16 Enhanced Measurement Reports (EMR)........................ 145 16.1 EMR sending in response to Measurement Information

Message............................................................................. 146 16.1.1 (E)MR sending in response to Measurement Information

Message............................................................................. 148 16.2 Invalid_BSIC_Reporting Response ................................... 151 16.3 SCALE_ORD Response .................................................... 152 16.4 Reporting Priority of Neighbouring Cells............................ 153



16.5 Uplink RX Quality Measurement........................................ 155 16.6 Downlink Frame Erasure Rate (FER) Measurement ......... 158 16.7 Averaging of Enhanced Measurement Report (EMR) ....... 159 16.8 Reporting of correct TA value under high interference and

load conditions ................................................................... 160 16.9 Bad UL SACCH Frames .................................................... 161

17 Ecell................................................................................... 163 17.1 ECell ERACH Success Rate.............................................. 163 17.2 ECell Emergency Call ........................................................ 165 17.3 ECell Signalling.................................................................. 166 17.4 ECell Handovers ................................................................ 170 17.5 ECell HO during data call................................................... 172 17.6 ECell EMR.......................................................................... 175 17.7 ECell Packet Switched Data .............................................. 178 17.8 ECell simultaneous GPRS and EGPRS transfer ............... 180 17.9 ECell Circuit Switched Data ............................................... 182

18 DFCA ................................................................................. 186 18.1 Speech Call Set-up via FACCH with DFCA....................... 186 18.2 AMR with DFCA................................................................. 186 18.3 Synchronous & Asynchronous Handover with DFCA........ 188 18.4 EGPRS with DFCA ............................................................ 189

19 IMSI Based Handover ...................................................... 190 19.1 IBHO Feature Activation, GSM to GSM............................. 190 19.2 GSM to GSM IBHO, call setup 2 MS with different PLMN,

EMR/MR and multi-band.................................................... 191

20 CS3&4................................................................................ 193 20.1 GPRS Attach and PDP Context......................................... 193 20.2 Data Transfer using CS3-CS4 ........................................... 195 20.2.1 Downlink Data transfer with CS-3 ...................................... 195 20.2.2 Uplink Data transfer with CS-3........................................... 196 20.2.3 Downlink Data transfer with CS-4 ...................................... 197 20.2.4 Uplink Data transfer with CS-4........................................... 198 20.3 CS3 and CS4 GPRS Data transfer .................................... 199 20.4 Paging Mode...................................................................... 203 20.5 MT SMS ............................................................................. 204 20.6 GPRS and EGPRS TBF’s on one time slot ....................... 205

Contents

DN0694168 Issue 1-0


7 (252)

20.7 CS-3 & CS-4 Data transfer with IDD/4UD & IDD BBH configuration....................................................................... 207

20.8 GPRS Link Adaptation ....................................................... 208 20.9 Data Transfer with A-bis Failure ........................................ 209 20.10 Data Transfer with Air Interface Failure ............................. 210 20.11 Cell Reselection & Timing Advance with GPRS CS-3&4... 211 20.12 Cell re-selection ................................................................. 213 20.13 GPRS CS3&4 Reliability at Various MS Speeds ............... 215 20.14 GPRS CS-3&4 Reliability at Various Distances................. 216 20.15 GPRS Territory Upgrade/Downgrade with CS3&4 ............ 217 20.16 TRX Loop Test with CS3&4 ............................................... 219 20.17 Dynamic Abis Allocation with CS3&4................................. 221 20.18 BTS Tests with CS3&4 enabled......................................... 224 20.19 Intelligent Shutdown with CS3&4 enabled ......................... 225 20.20 Extended Cell with CS3&4 enabled ................................... 227 20.21 LAPD Failure...................................................................... 228

21 Ghost RACH and PRACH testing ................................... 230 21.1 Ghost RACH and PRACH Absolute Test........................... 230 21.2 Ghost RACH and PRACH Relative Test............................ 237 21.3 TRX Load Test ................................................................... 241

22 Modification of Timer values from BSC......................... 244 22.1 Modification of LAPDm Timer value from BSC.................. 244 22.2 Modified LAPDm T200 with Multi BCF............................... 245 22.3 Verification of SDCCH T200 timer value............................ 247 22.4 Verification of FACCH T200 timer value ............................ 249

23 SACCH Messages during speech Call........................... 251



1 Vocabulary Acronym Explanation of Acronym

4UD 4-way Uplink Diversity

ABIS A-bis Interface, BSC to BTS interface

ACS AMR Coding Scheme

AFS AMR Full Rate Speech

AH Antenna Hopping

AHS AMR Half Rate Speech

AG Access Grant

AMR Adaptive Multi Rate

ARFCN Absolute Radio Frequency Number

BB Base Band

BA BCCH Allocation

BCCH Broadcast Control Channel

BER Bit Error Ratio

BSC Base Station Controller

BSIC Base Station Identity Code

BTS Base Transceiver Station

BTIM BCCH TIMER

BSS Base Station Subsystem

CB Cell Broadcast

C/I Carrier to Interference Ratio

CDMA Code Division Multiple Access

CS Coding Scheme

CS data Circuit Switched Data

DL Downlink

DIV Diversity

DTX Discontinuous Transmission

Vocabulary

DN0694168 Issue 1-0


9 (252)

EDGE Enhanced Data Rates for GSM Evolution

EDAP Enhanced Dynamic ABIS Pool

EFR Enhanced Full Rate

EGPRS Enhanced GPRS

EMR Enhanced Measurement Reporting

EPCR EGPRS Packet Channel Request

FACCH Fast Associated Control Channel

FER Frame Error Rate

FR Full Rate

GGSN Gateway GPRS Support Node

GMSK Gaussian Minimum Shift Keying

GPRS General Packet Radio Service

GSM Global System for Mobile communications

HW Hardware

HR Half Rate

IDD Intelligent Downlink Diversity

IR Incremental Redundancy

IMSI International Mobile Subscriber Identity

LA Link Adaptation

LAPD Link Access Protocol on D Channel

LAPDm Link Access Protocol on D Channel Modified MA (or MA-list) Mobile Allocation (Mobile Allocation List)

MAC Medium Access Control

MBCCB Combined BCCH Channel with Cell Broadcast Channel

MBCCH BCCH Channel (Configuration)

MBCCHC Combined BCCH Channel (MBCCH + SDCCH/4 configuration)

MCS Modulation and Coding Scheme

MEAS Measurement

MO Mobile Originated

MS Mobile Station

MT Mobile Terminated

NAH Normal Antenna Hopping (no other hopping apart from AH)

NT Non Transparent



O&M Operations & Maintenance

PCM Pulse Code Modulation

PCU Packet Control Unit

PDP Packet Data Protocol

PDTCH Packet Data Traffic Channel

PRACH Packet Random Access Channel

PSTN Public Switch Telephone Network

PSK Phase Shift Keying

RA Routing Area

RACH Random Access Channel

RAH RF & Antenna Hopping

RDIV Receive Diversity

RF Radio Frequency

RLC Radio Link Control

RX Receive

SACCH Slow Associated Control Channel

SDCCH Standalone Dedicated Control Channel

SDCCB Standalone Dedicated Control and Broadcast Channel

SGSN Serving GPRS Support Node

SI System Information

SIM Subscriber Identity Module

SMS Short Message Service

SW Software

TA Timing Advance

TBF Temporary Block Flow

TCH Traffic Channel

TCHD Traffic Channel Dual Rate

TCHF Traffic Channel Full Rate

TCHH Traffic Channel Half Rate

TCP Transmission Control Protocol

TRAU Transcoding and Rate Adaptation Unit

TRX Transceiver

TS Time Slot

UDP User Datagram Protocol

Vocabulary

DN0694168 Issue 1-0


11 (252)

UL Uplink

WCDMA Wideband CDMA



2 Introduction

2.1 Scope This document incorporates the regression test phase and defines the test cases for verifying the telecom features of BTS SW CX(M)6 using BSC SW S13. This document is meant for both the UltraSite and the MetroSite base stations.

In general, the features and test cases described are intended for Nokia GSM 800, 900, 1800 and 1900 environments. However, due to specific GSM environments, or customer’s configurations, or requirements or peculiarities, some features and test cases might not apply to all environments. In those test cases where not all bands are valid, the band to which they apply is noted.

Note 1. Test cases have to be performed on both UltraSite and MetroSite base stations unless specifically mentioned.

Section 17 Ecell is to be tested for UltraSite only.

Note 2. Antenna Hopping (AH) and RF+ Antenna Hopping (RAH) is used only when Test case is executed on UltraSite.

Note 3. Enable CS3&4, only when specified. CS3&4 can be enable from BSC using the command: EQV: BTS=<x>: CS34=Y;

DAP is mandatory with GPRS. Enable TRXs when CS3&4 is enabled.

Note 4. Use GPRS capable MS only for GPRS data transfer, when EGENA=Y.

Note 5. With a 16 Kbps TRX signalling link only 12 SDCCH channels/TRX are possible.

Introduction

DN0694168 Issue 1-0


13 (252)

2.2 Hardware Requirements Base stations UltraSite base stations with the following transceiver units are required to perform the test cases in this document:

TSGB 900 EDGE

TSDB 1800 EDGE

TSTB 800 EDGE

TSPB 1900 EDGE

TSGA 900 GSM

TSDA 1800 GSM

TSPA 1900 GSM

The BB2A, BB2E and BB2F base band cards will be required for any UltraSite configuration. For GSM TRX configuration any of these base band cards can be used while for EDGE and Mixed configuration BB2E or BB2F base band cards are needed.

MetroSite base stations with the following transceiver units are required to perform the tests in this document:

CTGA 900 EDGE

CTDA 1800 EDGE

WTFA 800 EDGE

WTPA 1900 EDGE

HVTG/VTGA 900 GSM

HVTD/VTDA 1800 GSM

HVTP/VTPA 1900 GSM



Other Network ElementsBSC

Core Network with GPRS and EDGE capabilities.

In addition to the BTS under test, the network elements listed in [Table 2] are required.

GSM mobile handsets supporting the features are defined in [Table 1].

Table 1 GSM Mobile Handsets

Feature Specific options Speech channels FR, HR, EFR

Single data channels 9600, 14400 Non-Transparent

Multislot data channels

9600 or 14400 Non-Transparent using 1+1, 2+2 or 3+1 timeslots

GPRS Class B & Class C

EGPRS Class B & Class C

Location Service E-OTD Capable

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

Enhanced Measurement Reports

EMR Capable

2.3 Software Requirements BTS SW CX6 and Site Wizard 6 releases are required for the testing. SW versions of the other network elements are detailed in [Table 2]. The latest Change Deliveries (CD) should be installed into the network elements and recorded in the test log.

Table 2 SW Versions of Other Network Elements

Network Element SW Version BSC S12, S13

MSC/HLR M13

NMS/2000 T12

Nokia NetAct OSS 4.2

Introduction

DN0694168 Issue 1-0


15 (252)

Network Element SW Version LMU 4.4

LMUB 1.0 CD1.0, 1.0 CD2.0

SGSN SG5

GCS R5.0

Transmission (FXC E1, FXC E1/T1, FXC RRI)

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

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

ITN C1.0, ITN C3.0

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

BTS Manager PC Windows 98, Windows 2000, Windows XP

PC Applications - Internet browser

- FTP, UDP software

- Terminal Emulator

2.4 Specialist Test Equipment Requirements

The following test equipment is required in some test cases:

- Traffic Generator, preferably Load Tester

- IR/LA Rig

- Assortment of combiners

- Attenuators

- Terminators

- 8 PSK & GMSK capable signal generator

- Spectrum analyser

- GSM Analyser for the A-bis, Gb and A interfaces

- Air Interface Monitoring MS and software

- Frequency Counter

- 8PSK & GMSK capable Fading Simulator



- Abis Breaker

- Location Management Unit

- CMU

Speech call setup

DN0694168 Issue 1-0


17 (252)

3 Speech call setup

3.1 Speech and Emergency call Setup via SDCCH

Purpose:

The purpose of these tests is to prove that speech and emergency calls can be activated from SDCCH channels, that EFR, FR & AFS are supported on TCHF, that EFR, FR, HR, AFS & AHR are supported on TCHD, and that all paging groups available in the configuration are used.

Input Expected Output Calls are made from MS to MS in the same test BTS using minimum call repetition criteria. Each call must be held for at least 60 seconds. Different IMSI are used during a test case to verify all paging groups possible in the configuration. For test cases involving more than one speech Codec (i.e. FR and AMR), two types of MS must be used and while making calls using minimum repetition criteria, each speech Codec specified in the test case must be used at least once.

All calls are established and held until user terminates the call. The received audio quality shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.



For the TCHD configuration, each tested timeslot is reused in sequence of FR, HR#0, FR, HR#1 and then FR again. The A-bis TRX signalling links are followed during the test.

In A-bis Measurement Result values for RX Qual in both uplink and downlink, and the UL FER shall be’0’ in laboratory conditions. In A-bis Measurement Result value of MS Speed shall be reported reliably when frequency hopping is not active. (In cases where speed can not be detected the value is reported as ‘not valid’) A-bis RF RES IND message for a reserved TCH timeslot shall include the active interference measurement. In CCCH LOAD IND message (uplink), BTS should report non-zero values for RACH access count.

Calls are made to the emergency service number (112) where specified. A timeslot on each TRX in the configuration is used at least once. Each call must be held for at least 30 seconds.

All emergency calls are established and held until user terminates the call.

The A-bis TRX signalling links are followed during the test.

On A-bis Channel Required message will contain ‘Emergency Call’ for field Request reference.

Case Ref.

Channel configuration

Codec No. Of TRX in sector

AG blocks in BCCH

Hopping Mode

Emergency Call

1. Non-combined BCCH + TCHF1

AFS 4 3 BB hopping

Yes

2. Non-combined BCCH + TCHF2

AFS 4 3 RAH hopping

Yes

3. Non-combined BCCH + TCHD3

HR/FR/AHR 2 0 RF-hopping

No


HR/FR/AHS 2 0 RF-hopping

No


HR /EFR/AHR 4-12 1 BB-hopping

Yes

Speech call setup

DN0694168 Issue 1-0


19 (252)

Case Ref.


Codec Configuration used

Hopping Emergency Call

6. Combined BCCH+TCHF

FR/AFS Common BCCH (2+2 configuration) 3

RF-Hopping (BTS1), BB-Hopping (BTS2)

Yes

7. Combined BCCH+TCHD

HR/FR 2 sectors each with 2 TRX (BB2F with TSxA+TSxB)

BB-hopping Yes

8. Non-Combined BCCH +TCHF

EFR/AFS 4 TRX Sector (2 BB2F with 2 TSxA and 2 TSxB)

BB-hopping No

1 For Metro Site use EDGE configuration 2For UltraSite use EDGE configuration with BB2F 3 For UltraSite use Hybrid configuration 4 Use EDGE configuration with BB2F when executed with UltraSite and open just two TCHD

timeslots to make the call 5 MS does not have valid SIM card.

3.2 Dynamic SDCCH Reservation Purpose:

The purpose of these test cases is to prove that dynamic SDCCH channels can be reserved and released correctly from any TS configured as either TCHF or TCHD, and that TCH TS can be reused as TCH after dynamic activation.



Input Expected Output Dynamic SDCCH feature is active in BSC. SDCCH reservations are made by IMSI Attach and / or sending and receiving of SMS at the same time. The number of mobiles used for test must be at least the same as the number of static SDCCH channels plus 8 additional mobiles. When the case is complete, a speech call is established on the same TCH as used for dynamic SDCCH. In case of TCHD HR & FR call is established. The A-bis TRX signalling links are followed during the test. Calls are made using the minimum call repetition criteria to ensure dynamic SDCCH/8 can be configured on different TCH.

A TCH is assigned to SDCCH/8 when static SDCCH is all reserved. Every location update and SMS sending / receiving are successful. The timeslot can be re-used as TCH after all dynamic SDCCH/8 have all been released. When a TCH is dynamically made SDCCH/8 the A-bis RF RES IND message shall include interference values for all un-reserved sub timeslots. After all dynamic SDCCH have been released from TS, the RF RES IND shall report the values for the original TS configuration again. In CCCH LOAD IND message (uplink), BTS should report non-zero values for RACH access count.

Case Ref.

Channel Configuration Number of TRX in sector

Hopping Mode

AG blocks in BCCH

1. MBCCB + 7*TCHF 4 Omni RAH-Hopping

1

2. (MBCCH + SDCCH + 6*TCHD)(SDCCH + 7*TCHF)

4 TRX Sector (2 BB2F with 2 TSxA and 2 TSxB)

BB-Hopping 3

3.3 Rx Diversity testing during speech call

Purpose:

The purpose of these test cases is to check that the Rx diversity feature works properly during speech calls.

Speech call setup

DN0694168 Issue 1-0


21 (252)

Input Expected Output RX DIV feature is set ON for the BTS.

MS to MS call is made on same test BTS. Call must be held for the entire test duration

Call is established and held until user terminates the call. The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.

A-bis TRX signalling links are followed during the test.

In laboratory conditions, values of RX Qual (uplink and downlink) and UL FER should be reported as ‘0’.

Now block the specified Rx path of the TRX on which call is active so that it can receive Rx signal through only one Rx path A-bis TRX signalling links are followed during the test.

The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods. On A-bis, Measurement Result message values for RX Qual in both uplink and downlink, and the UL FER are reported as ‘0’.

Case Ref.

BTS Configuration RX Path blocked

1. One Omni UltraSite DIV RX 2. Two Omni MetroSite DIV RX 3. One Omni UltraSite Main RX 4. Two Omni MetroSite Main RX

3.4 Speech Call and Emergancy Call Setup via FACCH

Purpose:

The purpose of these test cases is to prove that a TCH channel can be first used for signalling (speech call & emergency call establishment) and then be modified to a speech channel.

Input Expected Output Dynamic SDCCH feature is deactivated and Call_Setup_ON_FACCH is active on BSC. Static SDCCH channels are reserved in sector



Calls are made from MS to MS on same BTS using minimum call repetition criteria. Each call must be held for at least 60 seconds. For test cases involving more than one speech Codec (i.e. FR and AMR) two types of MS must be used and while making calls using minimum repetition criteria, each speech Codec specified in test case must be used at least once.

All calls are established via FACCH on TCH TS. After signalling is complete the TS is changed to appropriate Codec via Mode Modify message and calls are held until terminated. The received audio quality is good and without distortion.

For the TCHD configuration, each tested timeslot is reused in sequence of FR, HR#0, FR, HR#1 and then FR again. The A-bis TRX signalling links are followed during the test.

A-bis RF RES IND message for a reserved TCH timeslot shall include the active interference measurement when defined as signalling and speech activation.

Case Ref.


Codec No. Of TRX in sector

Hopping Mode

Emergency Call

1. Combined BCCH + TCHD

HR/FR/AHS 4 RAH-hopping

Yes1


HR/EFR/AHS 4-12 BB-hopping Yes

3. Non-combined BCCH + TCHF

FR/EFR/AFS 4-12 RF-hopping Yes2

4. Non-Combined BCCH+TCHD

HR/FR/AFS Nokia UltraSite having 6 sectors each with 2 TRX (BB2F with TSxA+TSxB)

BB-hopping Yes

1 MS does not have valid SIM card 2 Use FXC E1 with ITN C3.0 Clock Source = Internal

3.5 Support for Different Ciphering Algorithms

Purpose: The purpose of these tests is to verify that different ciphering algorithms are supported.

Speech call setup

DN0694168 Issue 1-0


23 (252)

Input Expected Output BTS SW packages that supports ciphering algorithm as specified in test case is used.

The ciphering algorithm of each call is checked on the Abis. MSs which supports A5/1 and A5/2 are used (the A5/1 MS supports A5/0 and A5/1 modes and the A5/2 MS supports A5/0, A5/1 and A5/2 modes).

Location updates and calls are made after the SW package is activated at the BTS. International mobile subscriber identity (IMSI) ciphering level at the MSC is set according to the table below.

If the BTS accepts the ciphering algorithm used, the call is successful. If the BTS does not accept the ciphering algorithm, error report can be seen at the Abis.

Case Ref. Configuration

SW Packages Used in BTS

IMSI Ciphering Level at MSC

Location update

Call set-up

1. Any A5/0 A5/0 Accepted Accepted

2. Any A5/0 A5/1 Not accepted Not accepted

3. Any A5/0 A5/2 Accepted* Not accepted




7. Any A5/2 A5/1 Not accepted Not accepted

8. Any A5/2 A5/2 Accepted Accepted * No ciphering is requested during location update for A5/2 IMSIs



4 Single Timeslot Data Call Setup

4.1 Non-Transparent Data via SDCCH Purpose:

The purpose of these cases is to prove that single timeslot non-Transparent data channels can be activated from SDCCH channels, different user data rates are supported, and that 7 & 8 bit data can be transferred at the expected data rate.

Note 6. HLR settings need to be done for making a 4.8K Non Transparent data call From PSTN to MS

Test Tools Required: PSTN Setup

Input Expected Output Each test case is made using a mixture of originating / terminating sources (MS – MS, MS – PSTN & PSTN –MS). Calls are established using minimum call repetition criteria.

All calls are established and held until user terminates the call.

When data call is established, a data packet of at least 100kb is transferred from A to B and then again from B to A. (A file of 1Mb is transferred at least once for each test case) Data packet type is specified in each case and transferred using 7-bit ASCII via raw ASCII protocol and 8-bit data file by Z-modem protocol.

Data can be sent and received in both directions and the user data rate is achieved on transfers. In lab condition there shall be no bit errors on user data.

Single Timeslot Data Call Setup

DN0694168 Issue 1-0


25 (252)


A-bis Measurement Result message values for RX Qual in both uplink and downlink, and uplink FER shall in laboratory conditions is predominantly of value 0. (The FER measurement value can be seen in the ‘suppl. Info’ field of the A-bis trace) A-bis RF RES IND message for a reserved TCH timeslot shall include the active interference measurement when defined as non-transparent data activation.

Case Ref.

Channel Configuration

No. Of TRX in sector

User Rate

User Data Hopping Mode

1. TCHF 1 Minimum of 2 TRX used

300 7 bit ASCII BB-hopping

2. TCHF1 Minimum of 2 TRX used

1200 8 bit data file RAH-hopping


2400 7 bit ASCII Non-hopping


4800 8 bit data file RF-hopping

5. TCHD Minimum of 4 TRX used

9600 8 bit data file BB-hopping

6. TCHD2 Common BCCH 2+2 configuration3

9600 7 bit ASCII BTS1 (non-hopping), BTS2 (RAH-hopping)

7. TCHD5 Use configuration as in Figure 3

14400 7 bit ASCII Use as specified in figure

8. TCHF4 Use configuration as in Figure 1

14400 7 bit ASCII Use as specified in figure

1 No need to make PSTN-MS Calls 2 EDAP is configured for all TRX. 3 Data transfer is done both in BCCH and non BCCH BTS of common BCCH segment 4 Data transfer is done both in master and slave BTS of multi BCF segment. BCCH is on Talk Family BTS. 5 Transfer 8 bit data file



4.2 Non-Transparent Data via FACCH Purpose:

The purpose of these test cases is to prove that a TCH channel can be first used for signalling (call establishment) and then be modified to a data channel.


Input Expected Output Dynamic SDCCH feature is deactivated and Call_Setup_ON_FACCH is active on BSC. Static SDCCH channels are reserved in sector. Each test case is executed using a mixture of originating / terminating sources (MS – MS, PSTN-MS & MS – PSTN). Calls are established using minimum call repetition criteria.

All calls are established via FACCH on TCH TS. After signalling is completed, the TS is automatically changed to appropriate Codec via Mode Modify message and held until user terminates the call.

When call is established, a data packet of at least 100kb is transferred from A to B and then again from B to A. (A file of 1Mb is transferred at least once for each test case) Data packet type is specified in each test case and transferred using 7-bit ASCII via raw ASCII protocol and 8-bit data file by Z-modem protocol.

Data can be sent and received in both directions and the user data rate is achieved on transfers in lab conditions. There shall be no bit errors on user data.

The A-bis TRX signalling links are followed during the test

A-bis Measurement Result message values for RX Qual in both uplink and downlink, and uplink FER shall in laboratory conditions is predominantly of value 0. (The FER measurement value can be seen in the ‘suppl. Info’ field of the A-bis trace) A-bis RF RES IND message for a reserved TCH timeslot shall include the active interference measurement when defined as non-transparent data activation

Case Ref. Channel configuration


User Rate User Data Hopping Mode

1 TCHF 4 9600 7 bit ASCII BB-hopping

2 TCHD 4 14400 8 bit data file

RAH-hopping


DN0694168 Issue 1-0


27 (252)

Input Expected Output 3 TCHD 4 4800 8 bit data

file NAH-hopping

1 EDAP is configured for all TRX

4.3 Transparent Data via SDCCH Purpose:

The purpose of these test cases is to prove that single timeslot transparent data channels can be activated from SDCCH channels, different user data rates are supported, and that 7 & 8 bit data can be transferred at the expected data rate.


Input Expected Output Each test case is performed using a mixture of originating / terminating sources (MS – MS, MS – PSTN & PSTN-MS). Calls are established using minimum call repetition criteria.


When data call is established, a data packet of at least 100kb is transferred from A to B and then again from B to A. (A file of 1Mb is transferred at least once for each test case) Data packet type is specified in each case and transferred using 7-bit ASCII via Raw ASCII protocol and 8 bits data file by Z-modem protocol.

Data can be sent and received in both directions and the user data rate is achieved on transfers. There shall be no bit errors on user data.


A-bis Measurement Result message values for RX Qual in both uplink and downlink and uplink FER, shall in laboratory conditions is predominantly of value 0.

Case Ref.


No. of TRX in sector


1. TCHF Minimum of 4 TRX used

300 8 bit data file

BB-hopping



Input Expected Output Case Ref.





1200 7 bit ASCII No-hopping


2400 8 bit data file

NAH-hopping


4800 7 bit ASCII RAH-hopping

5. TCHD Minimum of 4 TRX used

9600 7 bit ASCII BB-hopping

6. TCHF Minimum of 4 TRX used

14400 8 bit data file

RAH-hopping

1 No need to make PSTN-MS Calls.

4.4 Transparent Data via FACCH Purpose:

The purpose of these test cases is to prove that a TCH channel can be first used for signalling (call establishment) and then be modified to a data channel.

Test Tools Required:PSTN Setup

Input Expected Output Dynamic SDCCH feature is deactivated and Call_Setup_ON_FACCH is active on BSC. Static SDCCH channels are reserved in sector.

Each test case is executed using a mixture of originating / terminating sources (MS – MS, PSTN-MS, MS – PSTN). Calls are established using minimum call repetition criteria.

All calls are established via FACCH on TCH TS. After signalling is completed, the TS is automatically changed to appropriate Codec via Mode Modify message and held until user terminates the call.


DN0694168 Issue 1-0


29 (252)

When call is established, a data packet of at least 100kb is transferred from A to B and then again from B to A. Data packet type is specified in each case and transferred using 7-bit ASCII via Raw ASCII protocol and 8-bit data file by Z-modem protocol.


Case Ref.



User Rate

User Data

Hopping Mode

1. TCHF 4 9600 8 bit data file

RF-hopping

2. TCHD 4 14400 7 bit ASCII

BB-hopping

3. TCHD 4 14400 8 bit data file

RAH-hopping

4.5 Group 3 Fax via SDCCH Purpose:

The purpose of these test cases is to prove that single timeslot transparent data channels for Group 3 fax can be activated from SDCCH channels, different user data rates are supported, on air data rate can be changed due to fax protocol speed reductions, and that multi page images can be transferred.

Test Tools Required: FAX Setup,PSTN Setup

Input Expected Output Each test case is performed using a mixture of originating / terminating sources (MS – MS, PSTN-MS, MS – PSTN). The maximum receive rate is set as defined for the terminating sources. Calls are established using minimum call repetition criteria.

All calls are established. Where the originating user rate is greater than terminating max RX rate, fax protocol negotiates the speed down. This can be seen in the Mode Modify message of the A-bis trace.

When call is established, a multi page test fax image is transmitted.

The received image is compared to the original for correctness



Case Ref.



Originating user rate

Terminating Max RX rate

Hopping Mode

1. TCHD 4-12 9600 9600 BB-hopping

2. TCHF 4 9600 2400 RAH-hopping

3. TCHF 4 9600 4800 RAH-hopping

Multislot Data Call Setup

DN0694168 Issue 1-0


31 (252)

5 Multislot Data Call Setup

5.1 Non-Transparent Data via SDCCH Purpose:

The purpose of these test cases is to prove that Multislot Non-Transparent data channels at 9600 & 14400 rates can be activated from SDCCH channels, that different user data rates are supported, and that 7 & 8 bit data can be transferred at the expected data rate.

Test Tools Required:PSTN Setup

Input Expected Output Each test case is performed using a mixture of originating / terminating sources (MS – PSTN, MS – MS, PSTN-MS). Calls are established using minimum call repetition criteria.


When data call is established, a data packet of at least 200kb is transferred from originating to terminating MS and vice-versa. (A file of 1Mb is transferred as least once during in each case) Data packet type is specified in each case and transferred using 7-bit ASCII via Raw ASCII protocol and 8-bit data file by Z-modem protocol.


The A-bis TRX signalling links are recorded during the test.

A-bis Measurement Result message values for RX Qual in both uplink and downlink and uplink FER, shall in laboratory conditions is predominantly of value 0. For Multislot call, measurement reports shall be sent for all the time slots used in uplink data transfer. A-bis RF RES IND message for a reserved TCH timeslot shall include the active interference measurement when defined as non-transparent data activation



Repeat test case 5 with CX(M)5 CD2 BTS S/W release and compare the Rx Qual both in downlink and uplink direction.

Rx quality should be better or at least same as the previous release.

Case Ref.


Configuration used

TS used / User rate

User Data Hopping Mode

1. TCHF Any configuration

2 TS / 14400

8 bit data file

No-hopping

2. TCHF Any configuration

2 TS/9600 8 bit data file

RAH-hopping

3. TCHD EDGE Metro Site

3+1 TS / 9600

7 bit ASCII

BB-hopping

4. TCHD 4 TRX Sector (2 BB2F with 2 TSxA and 2 TSxB)

3+1 TS / 9600

7 bit ASCII

BB-hopping

5. TCHF1 Common BCCH 2+2 configuration

3+1 TS / 14400

8 bit data file

RAH-hopping (BTS1), non-hopping (BTS2)


3+1 TS / 14400

7 bit ASCII

Use as specified in figure


3+1 TS / 14400

7 bit ASCII

Use as specified in figure

1 Data Transfer is done both in BCCH and non BCCH BTS of common BCCH segment. BCCH is on UltraSite. 2 Data transfer is done both in master and slave BTS of multi BCF segment. BCCH is on Talk Family BTS

Short Message Service

DN0694168 Issue 1-0


33 (252)

6 Short Message Service

6.1 Originating & Terminating SMS on SDCCH

Purpose:

The purpose of these test cases is to prove that SMSs of various lengths can be originated and terminated using SDCCH channels.

Test Tools Required: Fading Simulator,

Input Expected Output SMS text message is sent from one MS to another with both MS in idle mode.

One message of zero length, one with few characters and one with 160 characters sent one by one

All SMS message can be sent and accurately received via SDCCH.

Case Ref

Configuration Used Hopping Mode

1. 4 TRX Sector (2 BB2F with 2 TSxA and 2 TSxB)

BB Hopping

2. Any configuration with MO mobile moving towards BTS at 200 km/hr

RAH Hopping



6.2 Terminating SMS in Dedicated Mode Purpose:

The purpose of these test cases is to prove that SMS messages can be terminated using SACCH channels associated with different TCH configurations.

Test Tools Required: Fading Simulator

Input Expected Output SMS text message is sent from an MS in idle mode to a second MS that is in dedicated mode as defined in the test case. The length of the message is defined in the test case.

During the reception of the SMS in speech call, the audio path shall be monitored. For data calls the received data shall be checked at the receiving end.

For speech calls the received audio quality is good and without distortion of the original speech during reception of SMS, and there shall be no additional disturbing sounds heard at the receiving end. For data calls the data sent during the SMS receiving shall be accurate and without errors to user data. (In the case of transparent data there will be a period of corrupted data during the SMS receiving due to frame stealing)

Case Ref.

Call type Message Length (characters)

Hopping

1. AHS1 50 RAH-hopping

2. AMR/EFR4 50 RAH-hopping

3. HR#0 and HR#1 100 BB-hopping

4. AMR2 100 BB-hopping

5. HR#0 and HR#1/AMR3 100 BB-hopping

Short Message Service

DN0694168 Issue 1-0


35 (252)

6. Single TS 9600 NT 50 NAH-hopping 1Common BCCH 2+2 configuration, Call is in non-BCCH BTS./ASI is OFF 2 Use release6 Mobiles 3 Use Release6 mobiles and BSC S12 4.. MS is moving away from BTS @ 200km/hr



7 GPRS Operation in BTS Different states of a GPRS MS Idle State: The subscriber is not reachable by the GPRS network. The MS is capable of receiving only Point to Multipoint Multicast (PTM-M) data. The network elements hold no valid context for the subscriber and the subscriber is not attached to the mobility management. To change state to the ready state, the MS must perform a GPRS Attach procedure.

Standby State: The subscriber is attached to the mobility management and the location of MS is known on a routing area level. The MS is capable of receiving Point to Multipoint (PTM) data and pages for Point-to-Point (PTP) data. The network holds a valid mobility management context for the subscriber. If the STANDBY timer expires, the MS move to IDLE state and the mobility management context is removed. If the MS sends data, the MS moves to the READY state. The MS can use the Discontinuous Reception (DRX) to save the battery.

Ready State: The subscriber is attached to the mobility management and the location of MS is known on a cell level. The MS is capable of receiving PTM and PTP data. The SGSN can send data to the MS without paging at any time and the MS can send data to the SGSN at any time. The network holds a valid mobility management context for the subscriber. If the READY timer expires, the MS moves to STANDBY state. If the subscriber performs a GPRS Detach procedure, the MS moves to IDLE state and the mobility management context is removed. MS in READY state does not necessarily have radio resources reserved. The MS can use the DRX to save the battery.

Note 7. The GPRS feature is set active for the tested BTS with default GPRS capacity, if not otherwise stated. Also set UL DTX ON if not stated otherwise.

7.1 GPRS Synchronization in BTS Purpose:

The purpose of these test cases is to prove that all GPRS configured timeslots can be activated and synchronised, and that System Information 13 is scheduled on BCCH.

Test Tools Required: Abis Breaker

GPRS Operation in BTS

DN0694168 Issue 1-0


37 (252)

Input Expected Output GPRS is activated for BTS. Check activation first on BCCH and then on non-BCCH TRX by using the BFG parameter of command ZEQV.

GPRS functionality can be enabled for both BCCH and non-BCCH TRX. When enabled, System Info 13 is scheduled on BCCH transmission.

A GPRS Attach and PDP context activation and then packet data transfer is done to confirm operation for BTS. This is done for BCCH and non-BCCH TRX.

GPRS packet data can be sent successfully on BCCH and non-BCCH TRX.

Repeat these steps for all the three BTS.

Case Ref. BTS Configuration 1. 4+4+4 (For MetroSite this will be chaining configuration)

Sector 1-Non Hopping, Sector 2- RAH-Hopping, Sector 3- BB Hopping

Action Expected Output With GPRS function enabled in BTS and GP timeslot on BCCH TRX, a BCCH reconfiguration is made to occur which includes GPRS enabled TRX. Data transfer is done when GP timeslot moves to new TRX.

BCCH reconfiguration occurs and the GPRS synchronisation procedure operates correctly each time.

The case is repeated 5 times. GPRS packet data can be sent successfully.

Case Ref BTS Configuration 2 Any configuration (EDGE TRX)

Action Expected Output With GPRS function enabled in BTS, the A-bis is disrupted with random short (<0.5 s) breaks for a period of 10 seconds. The link is then left connected until the link recovers. GPRS data transfer is made. This case is repeated 5 times.

After the link recovers, GPRS resynchronises and data packet transfers successfully.

Case Ref BTS Configuration 3 Any configuration

RF -Hopping



Action Expected Output With GPRS function enabled in BTS, A-bis link is broken for 10 seconds before reconnection. The link is left to recover and a GPRS data transfer is made afterward. The case is repeated 5 times.

After the link recovers, GPRS resynchronises and data packet transfers successfully.

Case Ref BTS Configuration 4 Any configuration (GSM TRX)

BB-Hopping

Action Expected Output With GPRS function enabled for both BCCH and non-BCCH BTS, a reset is given for BCCH and non-BCCH BTS by BSC MML command. The BTS is allowed to become operational before reset is given to second BTS.

The site returns to working state. GPRS synchronisation procedure operates correctly each time.

A GPRS Attach performed and packet data transferred before and after reset.

GPRS packet data can be sent successfully

The case is repeated 5 times by giving resets from BTS manager and BSC MML command.

Case Ref BTS Configuration 5 Common BCCH 2+2 configuration

BCCH BTS-RF Hopping, Non-BCCH BTS- BB Hopping

Action Expected Output With GPRS function enabled in BTS such that GP timeslot is on BCCH TRX, a BCCH reconfiguration is made to occur by breaking PCM1 (ABIS BREAK), which includes GPRS, enabled TRX.

BCCH reconfiguration occurs and the GPRS synchronisation procedure operates correctly each time.

Data transfer is done when GP timeslot moves to new TRX.

GPRS packet data can be sent successfully

The case is repeated 5 times.

Case Ref BTS Configuration 6 12 TRX omni, 2 PCM are used, OMU (64 kbps) on

PCM2 and BCCH on PCM1


DN0694168 Issue 1-0


39 (252)

Action Expected Output With GPRS enabled at BTS such that GP is on non-BCCH TRX (GP-no preference), simulate intelligent shutdown in BCCH shutdown mode. The GP timeslot moves to BCCH TRX. After expiry of NTIM, site enters non-shutdown mode. On restoration of power site becomes operational

GPRS synchronisation procedure operates correctly each time.

A GPRS Attach performed and packet data transferred during BCCH shutdown mode and when whole site becomes operational.

GPRS packet data can be sent successfully during BCCH shutdown mode and when whole site becomes operational.

Case Ref BTS Configuration 7 Any configuration (EDGE TRX)

RAH-Hopping

7.2 Paging Modes Purpose:

The purpose of these test cases is to prove that all GPRS mobile in the Standby state can be paged via CCCH, and that a GPRS mobile in Ready state can be paged for circuit switched connection via SGSN.

Input Expected Output GPRS mobile is in the Standby state.

A single 'ping' data packet is sent to mobile's IP address from Internet.

A Ping response is received from the mobile.

The A-bis PCU frames and TRX signalling links are monitored. The test is repeated with mobiles having different IMSI.

The mobile was paged via CCCH. On A-bis link ‘PS-PAGING COMMAND’ message is seen.

Case Ref. Configuration Used Hopping Mode

1. 4 Omni RAH Hopping



Input Expected Output GPRS mobile is in the Ready state .The network mode is Mode1/Mode2 and MS is Class A/Class B.

(a) MS is in Packet Idle mode. (No Data transfer is being done)

A terminating speech call is made to the mobile. The Gb interface and TRX signalling links at A-bis interface are monitored.

Paging command message is seen for the test mobile in Gb interface traces. At A-bis interface ‘CS-PAGING COMMAND’ is seen. The speech call is established as normal.

(b) MS is in Packet transfer mode. (Data transfer is being done)


The speech call is established as normal. After speech call is terminated, the data transfer resumes and transfer is successful. Paging command message is seen for the test mobile in Gb interface traces. At A-bis interface ‘Packet Paging Command ’ is seen.

The test is repeated with mobiles having different IMSI.

Case Ref. Configuration Used Hopping Mode

2. 2+2 Common BCCH BTS1-RF, BTS 2-BB

7.3 Data Transfer Purpose:

The purpose of these test cases is to prove that GPRS capable mobiles can perform the attach/detach procedure successfully, that PDP context can be established, that data can be transferred using coding scheme 1 and 2, reliably in both uplink & downlink on PDTCH, and that a given TS can be used alternatively for circuit switched and packet data.



DN0694168 Issue 1-0


41 (252)

Input Expected Output GPRS is enabled in BTS using default GPRS capacity.

A Circuit switched speech call is established and checked in the timeslot to be tested. The call is released.

The circuit switched call is successful. After releasing the call the timeslot regains synchronisation.

Packet data transfer is started using UDP/IP in tested timeslot with coding scheme and direction as defined in the case. The user data rate is monitored. At least 3 times transfer should be made to get a reliable figure on throughput.

The data is transferred with BER of 0%. The expected data rates for the coding scheme are achieved. (CS-1 approx. 9kbit/s per timeslot used and CS-2 is approx. 13.4kbit/s per timeslot). In the PCU data frame the values for Coding scheme & RX level are verified to be reliable.

When the data transfer is complete a circuit switched speech call is again established and verified in the same tested timeslot.

The circuit switch call is successful. After releasing the call the timeslot regains synchronisation.

Case Ref.

BCCH Configuration/ TCH configuration / CS Call type

GPRS Enabled TRX

Coding Scheme / number of timeslots available

Data transfer direction

Hopping

1. MBCCH/TCHF / FR1

BCCH TRX

CS-1 / 1 TS Downlink 1Mb file and uplink 500kb file

BB-hopping

2. MBCCH/TCHD / FR

Non-BCCH TRX

CS-1 / 2 TS Downlink 1Mb file and uplink 500 kb file

No hopping

3. MBCCHC/TCHD / FR

BCCH TRX

CS-2 / 1 TS Downlink 1Mb file

BB hopping

4. MBCCH /TCHF / FR

BCCH TRX

CS-2 / 2 TS Downlink 1Mb file and uplink 500 kb file

RAH-hopping



5. MBCCH/TCHF / FR1

Non-BCCH TRX

CS-2 / 2 TS Five separate uplink and downlink data transfers of 1 MB each are made during the same session.

RF-hopping

1 EDAP is configured for all TRX GPRS Data Transfer with changing Time Advance Value.

Input Expected Output GPRS is enabled in BTS using default GPRS capacity.

Packet data transfer is started using UDP/IP in tested timeslot with coding scheme and direction as defined in the case. The user data rate is monitored. At least 3 times transfer should be made to get a reliable figure on throughput

The data is transferred with BER of 0%. The expected data rates for the coding scheme are achieved. (CS-1 approx. 9kbit/s per timeslot used and CS-2 is approx. 13.4kbit/s per timeslot).

On Abis PCU frames are monitored As the transfer of one file completes, promptly begin the transfer of a new file. Repeat this process until the MS reaches a distance of 0 Km (If MS is moving towards the BTS) / 35 Km (if MS is moving away from BTS).

In the PCU data frame the values for Coding scheme & RX level are verified to be reliable. Correct TA value is shown in PCU RANDOM ACCESS FRAME and IMMEDIATE ASSIGNMENT COMMAND.

Case Ref.

BCCH Configuration/ TCH configuration

GPRS enabled TRX

Coding Scheme / number of timeslots available

Start Dist./Speed

Travel Data transfer direction

6. MBCCHC/TCHF

BCCH TRX

CS-1 / 1 TS

35 Km/ 200 km/hr

Towards BTS

Downlink 1Mb file

7. MBCCH/TCHD

Non-BCCH TRX

CS-1 / 2 TS

0 km/ 150 km/hr

Away from BTS

Uplink 500kb file

8. MBCCH/ TCHD

BCCH TRX

CS-2 / 1 TS

0 Km / 100km/hr

Away from BTS

Downlink 1Mb file


DN0694168 Issue 1-0


43 (252)

9. MBCCHC/TCHF

Non-BCCH TRX

CS-2 / 2 TS

35 Km/ 200 km/hr

Towards BTS

Downlink 1Mb file and uplink 500 Kb file

7.4 Data Transfer with Radio Link Failure Purpose: The purpose of these test cases is to prove that radio link failures are handled correctly during packet data transfer.

Test Tools Required: ABIS Breaker

Note 8. Very occasionally the A-bis may be broken while the BSC is polling the BTS. This will cause the LAPD to drop and the air interface to be disabled. It may take over 30 sec to recover the site once the A-bis is reconnected. During this time the TCP/IP connection will probably be dropped. It may also be necessary to re-activate the PDP Context.

Input Expected Output All BCCH TRX timeslots are configured to be GPRS enabled.

Start packet data transfer (e.g. FTP) as defined in test case that remains active during break in interface.

The data transfer is interrupted when there are breaks in air or A-bis interface. Resources are released correctly and PCU SYNCHRONISATION Frames are sent after restoration in A-bis'. After the break the data transfer is restarted by the TCP protocol requesting retransmission of data.

Each case is repeated 5 times

Case Ref.

Data transfer direction Break in interface

1. Downlink transfer Air interface broken (attenuated for less than 5 s)

2. Downlink transfer 1 A-bis link is broken for 1 second and then restored



3. Uplink transfer Air interface broken (attenuated for less than 5 s)

4. Uplink transfer A-bis link is broken for 1 second and then restored

1 EDAP is configured for all TRX

7.5 SMS via Packet Data Purpose:

The purpose of these test cases is to prove that SMS messages can be sent and received via packet data when the MS is in the ready state.

Input Expected Output GPRS mobile is in Ready state. Different lengths of SMS messages are sent from GPRS mobile to normal mobile and vice versa (a setting needs to be made in the mobile for receiving SMS in Ready state).

The SMS messages to and from the GPRS mobile are routed via the GPRS network, rather than through the MSC to the SMSC.

At A-bis link both GSM A-bis signalling and PCU frames are monitored.

SMS shouldn’t get routed on SDCCH channel but through LLC layer on SAPI 7. (Can be seen in LLC layer traces)

Case Ref.

Hopping Mode GPRS enabled TRX

1. BB-hopping BCCH TRX only

Input Expected Output GPRS mobile is in Ready state.

Start packet data transfer (in downlink direction) with a GPRS mobile. When data transfer is ongoing, send an MT-SMS to this mobile from another MS (a setting needs to be made in the mobile for receiving SMS in Ready state)

The SMS messages to the GPRS mobile are routed via the GPRS network, (not through MSC). SMS shouldn’t get routed on SDCCH channel but through LLC layer on SAPI 7. (Can be seen in LLC layer traces). Data transfer should continue.

Case Ref. Hopping Mode GPRS enabled TRX 2. RAH-hopping Non-BCCH TRX only


DN0694168 Issue 1-0


45 (252)

7.6 Cell Reselection and Timing Advance Purpose:

The purpose of these test cases is to prove that during data transfer the mobile can make a cell reselection with various timing advance values.


Input Expected Output Source and Target cells are defined as neighbours.

An adjustable attenuator is connected to the downlink direction of the BTS

A packet data uplink and downlink transfer is established between MS and Internet on source cell as defined in the test case. The air interface is manipulated by adjusting the attenuator so cell reselection takes place to the target cell during data transfer.

The transfer can be established in the source cell. Data transmission continues after cell reselection and received data is accurate. The user data rate does not degrade after reselection procedure

The A-bis TRX links and PCU RANDOM ACCESS FRAME frames are monitored on source and target cells. The reselection between cells is made at least 10 times for each test case. Test Case 4 to be done with source cell and target cell having different RA values.

Actual TA value can be seen in the IMMEDIATE ASSIGNMENT message & PCU RANDOM ACCESS FRAME (UL).

Case Ref.

Source: Band / Hopping / distance / speed/coding scheme

Target: Band / Hopping / distance / speed / coding scheme

1. 900/ BB-hopping / - / CS-1 1800/ RAH-hopping / - /- / CS-1

2. 900 / NAH-hopping / - / CS-2 1800 / BB-hopping / - / -/ CS-2

3. - / Non-hopping / 5km / CS-2 - / / 2km / -/ CS-2

4. 800/ Non-hopping / 5km / CS-2 1900 / RAH-hopping / 2km / 20 Kmph/ CS-2



8 Adaptive Multi Rate Codec Purpose: The purpose of these test cases is to ensure the functionality of the Adaptive Multi Rate (AMR) Codec feature.

Note 9. Nokia UltraSite and Nokia MetroSite EDGE BTSs support FR modes of 12.2, 10.2, 7.95, 7.4, 6.7, 5.9, 5.15 and 4.75 and HR modes of 7.4, 6.7, 5.9, 5.15, and 4.75.

The AMR set includes AMR Codecs, their threshold and hysteresis values and the Initial Codec mode used to start the speech coding at call Setup and after handover.

Note 10. Basic AMR set for FR channel on BSC

Codec Mode

Threshold (C/I)

Hysteresis (C/I)

Lower threshold

(C/I)

Upper threshold

(C/I)

BER (%)

FER (%)

12.2 11 1 11 - 2.97 0.08

7.4 7 1 7 12 6.72 0.15

5.9 4 1 4 8 10.83 0.98

4.75 - 5

Note 11. Basic AMR set for HR channel on BSC

Codec Mode

Threshold (C/I)

Hysteresis (C/I)

Lower threshold

(C/I)

Upper threshold

(C/I)

BER (%)

FER (%)

7.4 14 1 14 - 0.62

5.9 11 1 11 15 1.08

4.75 - 12

Adaptive Multi Rate Codec

DN0694168 Issue 1-0


47 (252)

Lower threshold in the tables above means a more robust Codec (more correction, lower bit rate) and upper threshold means a less robust Codec (less correction, higher bit rate).

Note 12. Slow LA can be changed at the BSC using the MML command ZEEM. If Fast LA is in use, the Codec mode change is allowed in every second TCH frame (~ 40 ms). With Slow LA, Codec mode changes are allowed on SACCH frame interval (480 ms). (CMI and CMR values are seen on Abis).

Note 13. Channel allocation depends on the parameter Initial AMR Channel Rate. If the value Any Rate is chosen, the channel rate matches according to the currently used information for channel allocation. If the value AMR FR is chosen, full rate channel is allocated (if available) despite what information is currently being used. Any Rate is the default rate.

Parameter is valid in call Setup (except FACCH call Setup) and handovers.

Note 14. Initial Codec mode is used to start the speech coding at call Setup and after handover. If the Initial Codec mode is not defined, it is governed by the following rule:

1 Codec mode, it is the Initial Codec mode

2-3 Codec modes, the Initial Codec mode is the most robust mode of the set with lowest bit rate.

4 Codec modes, the Initial Codec mode is the second most robust mode of the set with second lowest bit rate.

Note 15. Cases are shared between 16 Kbit/s, 32/s & 64/s TRX signalling links.

Note 16. Default AMR Codec Sets (ACS) is used unless otherwise stated.

Note 17. Default Codecs are:

• FR modes - 12.2, 7.4, 5.9, and 4.75 • HR modes - 7.4, 5.9, and 4.75.



Note 18. In order to change the value of HRI from 0 to 1, the values for HRT3 > HRT 2 > HRT 1 and HRH 3 >= HRH 2 >= HRH 1

Note 19. BTS commands the MS to apply a particular speech Codec mode in the uplink. The MS can only request BTS to apply a particular speech Codec mode in the downlink because the BTS has an option to override the MS’s request.

8.1 AMR Call Setup via SDCCH and Link Adaptation (LA)

Purpose:

The purpose of these test cases is to prove that correct channel and Codec modes are selected when an AMR call is established via SDCCH, and the AMR is capable of adapting its operation according to the prevailing channel conditions, and to ensure that the AMR Codec mode can be changed correctly during the active call.

Test Tools Required: Variable Attenuator, Signal Generator, and Spectrum Analyser

Input Expected Output A call is made via every TS of TRXs. Each call must be held for at least 30 seconds.

Calls are initiated according to parameters defined for the BTS. The quality of the call is good. No disturbing sounds are heard during the speech or silent periods. A-bis CHANNEL ACTIVATION message includes the used AMR speech Codec and the set of Codec modes. A-bis MEASUREMENT RESULT: When DTX is not used, .the value of RX Qual Full should be monitored and its value varies between 0-7 according the interference. When DTX is used the value of RX Qual Sub should be monitored and its value varies between 0-7 according the interference.

The A-bis is monitored during the test

MS speed value shall be reported when frequency hopping and uplink DTX are not active; otherwise the value shall be 'Not Valid'.


DN0694168 Issue 1-0


49 (252)

When DTX is ON, invalid FER will be displayed.

During the AMR call, C/I conditions are changed step by step to manipulating the air interface so that the Codec mode is changed. (Can be done by generating a constant interference signal using signal generator and then applying variable attenuation) The quality of call is checked during the link adaptation.

When the downlink is degraded, MS requests BTS to apply a new Codec (CMR is seen in the A-bis). When the uplink is degraded, BSC commands MS to apply a new Codec. When the uplink/downlink is attenuated, the Codec mode is changed towards the most robust Codec mode (more correction, lower bit rate). No disturbing sounds are heard when Codec mode change occurs.

The attenuation is decreased step by step When uplink/downlink attenuation is decreased, the Codec mode is changed towards the least robust Codec mode (less Correction, higher bit rate). If Fast LA is in use, the Codec mode change is allowed in every second TCH frame (~ 40 ms). With Slow LA, Codec mode changes are allowed on SACCH frame interval (480 ms). (CMI and CMR values are seen on A-bis)

Case Ref.

Channel Configuration / Speech Codec

Codec Mode in ACS

Initial Codec Mode

Initial AMR Channel Rate

Hopping Mode

DTX LA

1. TCHD / AFS2 12.2, 7.95, 6.7, 4.75

Not defined

FR RAH-hopping

Only Uplink DTX ON

Fast

2. TCHD / AFS 12.2, 7.95, 6.7, 4.75

Not defined

FR RAH-hopping

Only Uplink DTX ON

Fast

3. TCHD / AFS 12.2, 7.95, 6.7, 4.75

Not defined

FR Non-hopping

Only Uplink DTX ON

Fast

4. TCHD / AFS1 10.2, 7.4, 5.9, 4.75

The most robust mode

Any Rate

RF-Hopping

Both Uplink & Downlink DTX ON

Fast

5. TCHD / AHS 7.4, 6.7, 5.9

Not defined

Any Rate

No-hopping

Off Slow



6. TCHD / AHS 7.4, 6.7, 5.9

Not defined

Any Rate

BB-hopping

Uplink DTX on

Slow

1 Do this test case with release 6 MS

2 Do this case with different uplink and downlink thresholds defined at the BSC

8.2 AMR Call Setup with Mobiles Moving Purpose:

The purpose of these test cases is to prove that correct channel and Codec modes are selected when the mobile is moving during an AMR call and that the voice quality is good.

Test Tools Required: Fading Simulator, Spectrum Analyser

Input Expected Output A multi TRX EDGE sector is used as defined in the channel configuration and hopping mode on a mobile travelling at speeds of 250km/h, 300km/h and 330km/h in each case.

An AMR call is made, and each held for at least 5 minutes with the MS moving from the BTS starting with 0km and then coming back towards the BTS when distance is 10km.

The call can be established on SDCCH and held until terminated. The received audio quality is good and without distortion.

Measurement Result message values for RX Qual in both uplink and downlink, and the UL FER shall in laboratory conditions are predominantly of value 0.

The A-bis Measurement Result message shows the correct MS speed value when frequency hopping is not active. In cases where the speed cannot be detected the value is reported as 'Not Valid'. The A-bis also indicated the AMR speech Codec in use correctly.

The A-bis Measurement reports are monitored during each case.

The maximum reliable speed detection is approximately 60 km/h (36 miles/h) in GSM 900 and 35 km/h (21 miles/h) in GSM 1800 & GSM 1900.


DN0694168 Issue 1-0


51 (252)

Input Expected Output

Case Ref.

Channel Configuration / Speech Codec

No. Of Codec Mode in ACS

Initial Codec Mode

Hopping Mode

LA

1. TCHD / AFS 4 Not Defined NAH -hopping

Fast

2. TCHH / AHS2 3 Highest Robust mode

RAH -hopping

Slow

3. TCHD / AHS 3 Highest Robust mode

RAH -hopping

Slow

4. TCHD / AHS 2 Highest Robust mode

BB -hopping

Fast

5. TCHD / AHS1 2 Highest Robust mode

BB -hopping

Fast

6. TCHD / AHS3 2 Highest Robust mode

Any hopping

Fast

7. TCHD / AFS 1 Not Defined No hopping

Fast

1 Use Release 6 mobiles 2 Use BB2Fand Lock all the timeslots except one on one TRX and make two AHS Calls 3 Use BB2E with TSxB and Lock all the timeslots except one on single TRX and make two AHS Calls

8.3 Packing/Unpacking of AMR Calls with Fast LA/Slow LA

Purpose:

The purpose of these test cases is to prove that packing of FR AMR calls to HR AMR calls due to cell load and unpacking of HR AMR calls to FR AMR calls due to call quality works properly.



Note 20. Packing and unpacking the FR and HR calls are performed via intra cell handovers.

Note 21. BTS parameters ‘Lower limit for FR TCH resources’ and ‘Upper limit for FR TCH resources’ are set at the BSC with the MML command ZEQM.

Input Expected Output FR AMR calls are made on the BTS (non-hopping) until the number of free full rate resources reduces below the lower limit value.

FR AMR calls are packed to HR AMR calls until the free FR resource increases above the upper limit value. The packing takes place only when the quality of FR AMR calls is above the parameter ‘intra HO threshold Rx Qual for AMR FR’ and the least robust Codec mode is in use.

A conversation is held. During the handovers, both directions of the call are observed for unexpected audio disturbances.

The quality of call is good and there is no additional audio signals noticed (e.g. clicks).

Case Ref

BTS Configuration/ TCH Type

LA Type

UL DTX

DL DTX Hopping Mode

1. Multi sector configuration with TCHD

Fast LA

ON OFF Non-hopping

Input Expected Output HR AMR calls are made. Vary the C/I so that the quality of the HR AMR call degrades under the BTS parameter ‘intra HO threshold Rx Qual for AMR HR’.

HR AMR calls are unpacked to FR AMR calls.


The quality of the call is good and there is no additional audio signals noticed (e.g. clicks).

Case Ref


LA Type

UL DTX

DL DTX Hopping Mode

2. Multi TRX/ TCHD Fast ON ON BB-hopping


DN0694168 Issue 1-0


53 (252)

Input Expected Output FR AMR calls are made via the BTS until the number of free full rate resources reduces below the lower limit value.




Case Ref


LA Type

UL DTX

DL DTX Hopping Mode

3. Multi Sector /TCHD

Slow ON RAH Hopping

4. Multi Sector /TCHD1

Slow ON RAH Hopping

1 Do this test case with Release6 MS

Input Expected Output FR AMR calls are made via the BTS until the number of free full rate resources reduces below the lower limit value.




Case Ref BTS Configuration/ TCH Type

LA Type

UL DTX

DL DTX Hopping Mode

5. 4Multi Sector /TCHD

Slow ON ON RAH Hopping



8.4 Slow Link Adaptation with Uplink DTX ON

Purpose: To verify that the codec value does not change more than once within a SACCH frame with slow link adaption. Note 22.

Test cases in this section should be done with the following settings: Number of Codecs in ACS – Any 3 half rate codec modes Initial Codec Mode- Not defined Initial AMR Channel Rate- AnyDTX - Uplink DTX OnLink Adaptation – Slow

Note 23.

Slow LA can be changed at the BSC using the MML command ZEEM. If Fast LA is in use, the Codec mode change is allowed in every second TCH frame (~ 40 ms). With Slow LA, Codec mode changes are allowed on SACCH frame interval (480 ms). The codec value should not change more than once within a SACCH frame with slow link adaption (CMI and CMR values are seen on Abis).

Input Expected Output Setup the BCF as given in configuration There is no unexpected alarm on the site. AHS calls are made via every the TRXs. Calls are initiated according to parameters

defined to the BTS. The quality of the call is good. No disturbing sounds are heard during the speech or silent periods.

C/I conditions are changed step by step in uplink direction using Signal generator to manipulate the air interface so that the Codec mode is changed. The quality of call is checked during the link adaptation.

When C/I is decreased the Codec mode is changed gradually towards the most robust Codec mode. When C/I is increased the Codec mode is changed gradually towards the least robust Codec mode. No disturbing sounds are heard when Codec mode change occurs.

Case Ref. Configuration Hopping Mode 1 2 OMNI TSxB with BB2F [Note 85] BB-hopping

2 2 OMNI TSxA+TSxB with BB2E. 4 half-rate codec modes are defined, Uplink DTX ON and Enable Slow link adaptation.

No

3 2 OMNI TSxA+TSxB with BB2E. 4 half-rate codec modes are defined, Uplink DTX ON and Enable Fast link adaptation.

No

4 2 OMNI EDGE MetroSite with Uplink DTX OFF [Not 85]

No


DN0694168 Issue 1-0


55 (252)

5 2 OMNI EDGE MetroSite with Uplink DTX ON [Note 85]

No

8.5 Intercell Handover from AMR Cell to Non-AMR Cell

Purpose:

The purpose of these test cases is to verify that Intercell Handover from AMR cell to Non-AMR cell works properly.


Input Expected Output 2 sectors of different BCFs are made neighbours. Sector 1 of BCF1: FRC=12.2,10.2 kbps Sector 2 of BCF2: Non-AMR (FRC&HRC=0) Test case without distance and speed parameters can be executed with zero values.

An AMR call is established and handovers after every 30 seconds are performed between the sectors. Perform at least 20 handovers. A-bis TRXSIG traces are analysed for quality parameter reported in measurement reports.

Handovers are successful; speech quality is good there is no click sound heard during the handover. The handover from non-AMR cell to AMR cell will result in an AMR call. Reported quality should be of ‘0’ level in lab condition, there shouldn’t be instances of ‘5-6’ quality level in measurement reports.

Case Ref.

Source Cell Hopping/distance/speed

Target Cell Hopping/distance/speed

1. BB-Hopping /- /- Non-Hopping /- /-

2. RAH-Hopping /10Km /40Kmph

BB- Hopping /5Km /40Kmph

3. RAH-Hopping /10Km /40Kmph

Non-Hopping /5Km /40Kmph



9 BTS Idle Mode Functions

9.1 SMS Cell Broadcast Purpose:

The purpose of these test cases is to prove that SMS-CB messages of various lengths are sent on combined and non-combined SDCCH channels, and that SMCB restarts sending again after a break in BCCH transmission.

Note 24. The SMS_CBC_USD_IN_BSC (10:44) feature is set to not active at the BSC.

Input Expected Output SMS_CB_DRX_USD_IN_BSC feature is set to OFF at the BSC.

CB is active to BTS with several CB messages with different repetition rates. Use MML command ZEQM:<bts no>:CB=Y; to enable CB in BTS.

When CB messages are active in the BSC, SMS BROADCAST messages are sent at regular intervals on the A-bis to TRX.

For each test case the sending of Cell broadcasts on SDCCH sub-channel 2 is monitored on the Air interface or suitable mobile handset . In each case the disturbance / reset is repeated 10 times

The messages are sent from the BTS to the air interface at defined intervals, and restart after each disturbance / reset type

Case Ref.

Channel configuration Hopping Mode

Disturbance / Reset Type

1. MBCCB No hopping BCF reset from BTS Manager

2. MBCCB RAH-hopping

BTS reset from BSC

BTS Idle Mode Functions

DN0694168 Issue 1-0


57 (252)

3. MBCCHC + SDCCB BB-hopping BCCH Reconfiguration

9.2 RACH and PRACH Success Rate under C/I Conditions

Purpose:

To check that the base station can consistently detect RACH and PRACH bursts from the MS in the presence of interference.

Test Tools Required: Signal Generator, Spectrum Analyser

Input Expected Output Use a site of any configuration. Configure MBCCH or MBCCHC on timeslot 0,as shown in the test case. Configure at least one EGPRS timeslot in the sector. Enable EGPRS in the sector. Bring the site into working order.

Use appropriate MS for the type of RACH as indicated in the table: RACH – Circuit Switched capable only GPRS PRACH – GPRS capable EGPRS PRACH – EGPRS capable. Lock the MS to the BCCH frequency.



Use the following steps to attempt to prevent the MS power from changing during the test: For the circuit switched tests, fix the MS power using the MML command: ZEQM:BTS=<bts num>: PMAX1=21,PMAX2=20,PMIN=20; Limit the MS power for accessing common control and packet control channels using MML command: ZEQG:BTS=<bts num>:TXP1=21,TXP2=20, GTXP1=21,GTXP2=20; Adjust the power control quality and signal strength parameters using MML commands: ZEUQ:BTS=<bts num>:UUR=0,LUR=7; ZEUS:BTS=<bts num>:UUR=-47,LUR=-110;

Ensure that the RX signal level seen by the base station is between –70 and –80 dBm. Set up a continuous GMSK co-channel interferer in the uplink so that C/I = 8 dB.

Monitor the A-bis. Use the method of generating RACHs as indicated in the table.

1. RACH – Use a Load Generator/MAD server to send CHAN REQ for location update.

2. PRACH – Send pings in UL direction to IP server.

3. PRACH – Send pings in DL direction from the IP server to the MS.

Send one location update/ping every 6 seconds.

The expected message indicated in the table is seen on the Abis every 6 seconds.

Record an A-bis trace for 1 hour. Analyse the recorded A-bis trace. Count the number of (P) RACH attempts that did not result in a valid message on the A-bis. Calculate the failure rate as a percentage of the total number of (P) RACH attempts.

Failure rate =(location update/Ping attempts)*100 (P)RACH Messages seen on Abis Failure rate <15%

Case Ref.

BCCH type

Send Method

RACH type

Expected Message A-bis Channel

1. MBCCH UL ping EGPRS P-CHANNEL REQUIRED TRX SIG of BCCH TRX

2. MBCCHC UL ping EGPRS P-CHANNEL REQUIRED TRX SIG of BCCH TRX

3. MBCCHC Load Generator

RACH CHANNEL REQUIRED TRX SIG of BCCH TRX

4. MBCCH UL ping PRACH P-CHANNEL REQUIRED TRX SIG of BCCH TRX

Dedicated Mode Functions

DN0694168 Issue 1-0


59 (252)

10 Dedicated Mode Functions

10.1 SDCCH Handovers Purpose:

The purpose of these test cases is to verify that SDCCH handovers can be performed successfully.

Input Expected Output A call is established in the source cell. A handover is made during SDCCH signalling.

Handovers are performed successfully.

Case Ref.

Configuration Hopping Mode

1. MBCCHC + SDCCH + TCHx RAH-Hopping

2. (MBCCHC + TCHx) (SDCCH + TCHx) 1

BB-hopping

3. (MBCCHC + SDCCH + TCHx) (SDCCH + TCHx)2

RF-hopping

1 Call uses SDCCH in second TRX 2Call uses SDCCH defined separately in first TRX

10.2 Intra Cell Handover Purpose:

The purpose of these test cases is to prove that intra cell handovers can be performed, and that during the handover procedure there is no perceived effect to the end user.



Input Expected Output Use a multi TRX sector. A call is established in the cell as specified in test case. Intra cell handover is triggered in cell at least 50 times during the same call.

Handovers can be performed from one timeslot to another in the same cell. If there are assignment failures then the call is not released and failure is recovered by GSM signalling. (There should not be more than 2 assignment failures seen)

A conversation is held, during the handovers; both directions of the calls are observed for unexpected audio disturbances. Each case is repeated at least 10 times

The perceived speech is unaffected by the handover procedure and there are no additional audio signals noticed.

Case Ref.

Call type / Codec or user rate

Hopping Mode

1. Speech / HR#0 & HR#1

Non-hopping

2. Speech / EFR 1 Non-hopping

3. Common BCCH 2+2/FR1, 2

RAH-hopping

Input Expected Output Use a multi TRX sector. A call is established in the cell as specified in test case. Intra cell handover is triggered in cell at least 50 times during the same call.

Handovers can be performed from one timeslot to another in the same cell. If there are assignment failures then the call is not released and failure is recovered by GSM signalling. (There should not be more than 2 assignment failures seen)

Data call: During the handover procedures a 200 Kb data file is transferred in alternative directions. The transferred data is compared with the original. Each case is repeated at least 10 times.

Data can be sent and received in both directions with the user data rate is achieved on transfers.

Case Ref.


Hopping Mode

4. Single TS Data, NT / 9600

BB-hopping

5. Multislot (2+1), NT 144001

RAH-hopping

1 TSC is different to BCC for non-BCCH TRX. 2 EDAP is configured for all TRX.


DN0694168 Issue 1-0


61 (252)

10.3 Inter cell Asynchronous Handover Purpose:

The purpose of these cases is to prove that inter cell asynchronous handovers can be performed, that during the handover procedure there is no perceived effect to the end user, and that neighbour cells can be reported to a mobile using adjacent cells or BA lists.


Input Expected Output For each target / source cells there shall be at least 6 valid neighbours available. Cases with out specific Band, distance or speed are made with zero values of distance and speed and with any band.

A speech call is established in the source cell as defined in test case and terminated in a separate test cell with same call type Codec or user rate. Inter cell handover are triggered to target cell at least 50 times during the same call. On Abis TRXSIG is monitored

Handovers can be performed from target to source cell and back. If there are assignment failures, then the call is not released and failure is recovered by GSM signalling. On A-bis, Handover Detected message has correct value for timing advance and MS speed does not affect call establishment. (Total number of assignment failure or handover failure should not be more than 2.)

A conversation is held; during the handovers both directions of the calls are observed for unexpected audio disturbances.

The perceived speech is unaffected by the handover procedure and there are no additional audio signals noticed. (E.g. clicks). In HR calls there may be a period of silence during handover due to frame stealing.

Case Ref.


Neighbour Definition

Source: Band / Hopping / distance / speed

Target: Band / Hopping / distance / speed

1. Speech / FR1 BA list 900 / BB-Hopping / 5Km / 50 Km/h

1800 / RF- Hopping / 7 Km / 60 Km/h

2. Speech / EFR3 Adjacent 1900 / Non-hopping / - / -

800 / RF- Hopping / - / -

3. Speech / EFR7 Adjacent 1900 / Non-hopping / - / -

800 / BB- Hopping / - / -



4. Speech / HR#0 & HR#13

BA list - / NAH-hopping / - / -

- / RAH-hopping / - / -

5. Speech AMR 5 BA list - / NAH-hopping / - / -


6. Speech AMR BA list - / NAH-hopping / - / -


7. Speech AMR 6 BA list - / NAH-hopping / - / -


Input Expected Output A data call is established in the source cell as defined in test case and terminated in a separate test cell with same call type Codec or user rate. Inter cell handover are triggered to target cell at least 50 times during the same call. On Abis TRXSIG is monitored

Handovers can be performed from target to source cell and back. If there are assignment failures, then the call is not released and failure is recovered by GSM signalling. On A-bis, Handover Detected message has correct value for timing advance and MS speed does not affect call establishment. (Total number of assignment failure or handover failure should not be more than 2.)

During the handover procedures a 200Kb data file is transferred in alternative directions. The transferred data is compared with the original.

Data can be sent and received in both directions with the user data rate is achieved on transfers and no bit errors. In the case of Transparent data there will be a period of corrupted data during the handover (due to frame stealing for FACCH)

Case Ref.


Neighbour Definition

Source: Band / Hopping / distance / speed

Target: Band / Hopping / distance / speed


BA list 900 / Non-hopping / - / -

EGSM 900 (excluding ARFCN 0) / NAH- Hopping / 0km / -


Adjacent - / RF-hopping / - / 250km/h

- / BB-hopping / - / 250km/h

10. Multislot (2+2), NT / 9600

Adjacent 1800/ NAH / - / - 900/ BB-hopping / - / -

11. Multislot (3+1), NT / 144004

BA list 800/ BB-hopping / 10Km / 80 kmph

1900/ RAH-hopping / 10Km / 100 kmph


DN0694168 Issue 1-0


63 (252)

1Source has EDGE HW and target has GSM HW, 2 Source has GSM HW and target has EDGE HW. 3 Non-BCCH TRX of the source and target cell should have TSC value different from BCC 4 Source Hybrid and target GSM when executed 5 Do this case with BSC SW S12 6 Do this case with AMR call and BSC SW S12 ED 3.1 release 7 Source has US EDGE, Target has US Hybrid

10.4 Inter Cell Synchronous Handover Purpose:

The purpose of these test cases is to prove that inter cell synchronous handovers can be performed (with the same channel configuration), that the BTS can correctly use the timing advance of the target cell, and that during the handover procedure there is no perceived effect to the end user.



A speech call is established in the source cell as defined in test case and terminated in a separate test cell with identical call type / Codec or user rate. Inter cell handover are triggered to target cell at least 50 times during the same call.

Handovers can be performed from target to source cell and back. If there are assignment failures then the call is not released and failure is recovered by GSM signalling. (Total number of assignment failure or handover failure should not be more than 2.)


The perceived speech is unaffected by the handover procedure and there are no additional audio signals noticed(e.g. clicks). In HR calls there may be a period of silence during handover due to frame stealing.

Case Ref.


Distance / Speed

Source Cell

Target Cell




A speech call is established in the source cell as defined in test case and terminated in a separate test cell with identical call type / Codec or user rate. Inter cell handover are triggered to target cell at least 50 times during the same call.



The perceived speech is unaffected by the handover procedure and there are no additional audio signals noticed(e.g. clicks). In HR calls there may be a period of silence during handover due to frame stealing.

Case Ref.


Distance / Speed

Source Cell

Target Cell

1. Speech / EFR1 5km / 150km/h

900 1800


A data call is established in the source cell as defined in test case and terminated in a separate test cell with identical call type / Codec or user rate. Inter cell handover are triggered to target cell at least 50 times during the same call.



Data can be sent and received in both directions with the user data rate is achieved on transfers and no bit errors

Case Ref.


Distance / Speed

Source Cell

Target Cell


DN0694168 Issue 1-0


65 (252)


A data call is established in the source cell as defined in test case and terminated in a separate test cell with identical call type / Codec or user rate. Inter cell handover are triggered to target cell at least 50 times during the same call.



Data can be sent and received in both directions with the user data rate is achieved on transfers and no bit errors

Case Ref.


Distance / Speed

Source Cell

Target Cell


- / -

900 EGSM 900 (excluding ARFCN 0)


330 Km/h Any band Different from source band

4. Multi TS Data (3+1), NT / 14400

- / - Any band Same as source

1 Non-BCCH TRXs of the source and target cell should have TSC value different from BCC



10.5 Intra-Cell Handovers within a Multi-BCF Segment

Purpose:

The purpose of these test cases is to check that circuit switched calls handover within the same segment, within the same BTS, from BTS to BTS, and from one BCF to another BCF when the synchronisation is either site or BSS synchronisation, is successful.

Test Tools Required: Variable attenuator

Input Expected Output Create the sites at the BSC as shown in the table and the diagrams below. Make the traffic channels full rate channels (TCHF). Make the default software package DF7.0 on Talk base stations.

Define the synchronization chain in the BSC using the MML command: ZEFM:<mm>:CS=BCF,SENA=T,ADD=<s1>; <mm> = Master BCF number <s1> = Slave BCF number For BSS Sync, since LMU is master, so the above command will be modified as ZEFM:<mm>:CS=LMU,SENA=T,ADD=<s1>; <mm> = Master BCF number <s1> = Slave BCF number Physically create and commission the sites.


DN0694168 Issue 1-0


67 (252)

Enable intra-cell handovers using the MML command: ZEHG:SEG=<seg num>:EIC=Y,EIH=Y; Set the interval between handovers to 15 seconds using the MML command: ZEHG:SEG=<seg num>:MIH=15,MIU=15; Set the interference threshold very low so that even a small interference signal triggers intra-cell handovers: ZEHI:SEG=<seg num>:IDR=-110,IUR=-110; Set the quality threshold very low so that even a small quality variance triggers intra-cell handovers: ZEHQ:SEG=<seg num>:QUR=1,QDR=1;

Ensure there is a very low level of interference on each frequency used by Segment 1 by using another base station set to adjacent channels, transmitting at minimum power with sufficient attenuation.

Lock a pair of MS to Segment 1. Establish a speech call between them.

The call sets up successfully.

Monitor the MS displays for the ARFCN used. Every 15 seconds the MS handover to a new ARFCN within the same Segment. All ARFCN within the segment are used.

Monitor the A-bis for ASSIGNMENT COMMANDs and ASSIGNMENT COMPLETE messages. Pay particular attention to handovers from ARFCN in the MetroSite to ARFCN in the Talk base station and visa-versa.

The ASSIGNMENT COMMANDS can be seen on the A-bis. For each ASSIGNMENT COMMAND there is a corresponding ASSIGNMENT COMPLETE indicating that all the intra-cell handovers are successful (including those between BCFs).

Speak in both directions while intra-cell handovers are taking place.

The speech can be heard clearly in both directions. There are no noticeable clicks, silent periods or other disturbances as the handovers occur.

Disconnect the call.

Repeat the test on Segments 2 and 3. Segments 2 and 3 behave in the same way as described for Segment 1.

Case Ref.

Config. BTS 1 BTS 2

BTS 3 BTS 4 BTS 5 BTS 6

Synchronisation

1. Figure 1 1 TRXD (1800)

TRXD TRXD CTGA (PGSM900)

CTGA (EGSM 900)

CTGA Site Sync

2. Figure 1 TRXE (1900)

TRXE TRXE WTFA (800)

WTFA WTFA Site Sync

3. Figure 2 TSTB (800)

TSTB TSTB TSPB (1900)

TSPB TSPB Site Sync

4. Figure 3 TRXD (1800)

TRXD TRXD TSGB (PGSM900)

TSGB (EGSM900)

TSGB

Site Sync


TRXE TRXE TSTB (800)

TSTB TSTB

Site Sync





WTFA WTFA BSS Sync

7. Figure 5 TSGA (900)

TSGA TSGA TSDB (1800)

TSDB TSDB BSS Sync with SSI


TRXD TRXD TSGB (PGSM900)

TSGB (EGSM900)

TSGB

BSS Sync with SSI

9. Figure 1

1, TRXD (1800)


CTGA (PGSM 900)

CTGA Site Sync



TSTB TSTB

BSS Sync

1 Make FR AMR calls for these test cases.


DN0694168 Issue 1-0


69 (252)

10.6 Inter-Cell Handovers between Multi-BCF Segments

Purpose:

The purpose of these test cases is to check that circuit switched calls successfully perform synchronous handovers from one segment to another within the same synchronised chain, that circuit switched calls successfully perform non-synchronous handovers to and from cells outside the synchronised chain, and that calls do not drop when the handovers fail.

Test Tools Required: Variable Attenuator

Input Expected Output Create the sites at the BSC as shown in the table and the diagrams below.

Make the traffic channels full rate channels (TCHF).

Make the default software package DF7.0 on talk base stations.

Define the synchronization chain in the BSC using the MML command: ZEFM:<mm>:CS=BCF,SENA=T,ADD=<s1>; <mm> = Master BCF number <s1> = Slave BCF number

For BSS Sync, since LMU is master, so the above command will be modified as ZEFM:<mm>:CS=LMU,SENA=T,ADD=<s1>; <mm> = Master BCF number <s1> = Slave BCF number

Physically create and commission the sites.



Disable intra-cell handovers using the MML command: ZEHG:SEG=<seg num>:EIC=N,EIH=N; Set the interval between handovers to 3 seconds using the MML command: ZEHG:SEG=<seg num>:MIH=3,MIU=3; Set the RX signal level threshold so that a moderate drop in signal level triggers handovers: ZEHS:SEG=<seg num>:LDR=-80,LUR=-80;

Create the Segments as neighbours in a ring as shown in Figure 7 using MML command: ZEAC:SEG=<seg num>:INDEX=<adjacent cell index>:ASEG=<adjacent seg number>:SYNC=Y; Create the one additional BTS as a neighbour as shown in Figure 7 using MML command: ZEAC:BTS=<bts num>:INDEX=<adjacent cell index>:ABTS=<adjacent bts number>;

Cable each segment to an MS via variable attenuators.

Lock all radio timeslots in BTS 3 and 5 (except the BCCH timeslot).

Camp one MS to one of the Segments in the ring. Do not lock the MS using the field test software because it will not be able to see the neighbour.

Make a call from the MS to a PSTN (land-line) telephone.

The call sets up successfully.

Monitor the A-bis for HANDOVER COMMANDS and HANDOVER COMPLETE messages. Monitor the MS display for the ARFCN being used. Slowly increase the attenuation from the serving cell until a handover is triggered. Return the attenuation to its original value after the handover has occurred.

A HANDOVER COMMAND is seen on the A-bis from the BSC to MS via the source cell. The ARFCN shown on the MS changes to the destination cell and a HANDOVER COMPLETE message is sent from the MS via the destination cell to the BSC.

Repeat the process on each cell to hand the call around the ring twice. [Figure 7]

All handovers complete successfully.

Speak in both directions whilst handovers are taking place.

The speech can be heard clearly in both directions. There are no noticeable clicks, silent periods or other disturbances as the handovers occur.


Case Ref.

Config. BTS 1 BTS 2 BTS 3 BTS 4 BTS 5 BTS 6

Synchronisation


DN0694168 Issue 1-0


71 (252)



WTFA WTFA Site Sync

2. Figure 2 TSTB (800)


TSPB TSPB Site Sync



TSTB TSTB Site Sync


TRXD TRXD TSGB (PGSM 900)

TSGB (EGSM900)

TSGB

Site Sync



CTGA (EGSM 900)

CTGA BSS Sync

6. Figure 5 TSGA (900)


TSDB TSDB BSS Sync with SSI

Case Ref.

Config. BTS 1 BTS 2 BTS 3 BTS 4 BTS 5 BTS 6

Synchronisation



TSTB TSTB BSS Sync



CTGA (EGSM 900)

CTGA Site Sync

1 Make AMR calls for these test cases.

Unsuccessful Handovers

Input Expected Output Continuing from the test case above, increase the attenuation in SEGment 3 to the mobile so that the RX level seen by the BTS is approx. –110dBm. It may be necessary to introduce duplexers so that the attenuation is applied in the uplink direction only, so that the MS can still see the target cell.

Begin a call from the MS to a landline telephone in a different part of the ring and hand the call round to SEGment 2.

Monitor the A-bis for HANDOVER COMMANDS and HANDOVER FAILURE and RF CHANNEL RELEASE messages. Monitor the MS display for the ARFCN being used. Listen to the speech in both directions. Slowly increase the attenuation from the serving cell until a handover is triggered.

The BSC sends a HANDOVER COMMAND to the MS via the source cell. The MS retunes to the new ARFCN, but the target cell cannot hear the MS. There is a brief “dead period” in the speech. The MS returns to the source cell and sends a HANDOVER FAILURE message to the BSC. The target cell sends an RF CHANNEL RELEASE message to the BSC. The call does not drop.

Repeat the handover failure process between each of the cells in the ring in turn.

The behaviour described above is repeated.




Case Ref. Config.

BTS 1 BTS 2 BTS 3

BTS 4 BTS 5 BTS 6 Synchronisation

9. Figure 1

TRXD (1800)

TRXD TRXD CTGA (PGSM 900)

CTGA (PGSM 900)

CTGA Site Sync

10. Figure 2

TSGA (900)


TSDB TSDB Site Sync

11. Figure 3

TRXD (1800)


TSGB (EGSM900)

TSGB

Site Sync

12. Figure 4

TRXE (1900)


WTPA WTFA BSS Sync

13. Figure 5

TSTB (800)


TSPB TSPB BSS Sync with SSI

14. Figure 6

TRXE (1900)


TSTB TSTB BSS Sync

15. Figure 6

TRXD (1800)


TSGB (EGSM900)

TSGB

BSS Sync


DN0694168 Issue 1-0


73 (252)

Figure 1

BTS1

BTS2

2

3 4 2

3 4

1

BTS4 BB hop

BTS3

BCF 1 BCF

SLAVE MetroSite

EDGE

SEGMENT 2

5 6

1

SEGMENT 1

SEGMENT 3

B

TRX colour indicates the SEGment it

Talk – Chained MetroSite Multi-BCF

6

7 8

5

B10

11 12

9

B

B =

BTS5 RF hop

BTS6 No hop



Figure 2

SEGMENT 2

SEGMENT 1

SEGMENT 3

1

2

3

4

5

6

BTS1

BTS2

BTS3

MASTER UltraSite

GSM

1

2

3

4

5

6 BTS6 AH hop

SLAVE UltraSite EDGE

BTS5 BB hop

BTS4 RF hop

BCF 1 BCF 2


UltraSite - UltraSite Multi-BCF

B =

B

B

B


DN0694168 Issue 1-0


75 (252)

Figure 3

BTS1

BTS2

2

3 4

BTS3

BCF 1

MASTER Talk GSM

SEGMENT 2

5 6

1 SEGMENT 1

SEGMENT 3

1

2

3

4

5

6 BTS6 AH hop


BTS5 RF hop

BTS4 BB hop

BCF 2

B

B

B


Talk - UltraSite Multi-BCF

B =



Figure 4

BTS1

BTS

2

3 4 2

3 4

1

BTS4 RF hop

BTS3

BCF 1 BCF

SLAVE Talk GSM

SLAVE MetroSite

EDGE

SEGMENT 2

5 6

1

SEGMENT 1

SEGMENT 3

B


LMU Talk Chained MetroSite

6

7 8

5

B10

11 12

9

B

B =

BTS5 No hop

BTS6 BB hop

LMU MASTER


DN0694168 Issue 1-0


77 (252)

Figure 5

SEGMENT 2

SEGMENT 1

SEGMENT 3

1

2

3

4

5

6

BTS1

BTS2

BTS3

SLAVE UltraSite

GSM

1

2

3

4

5

6 BTS6 BB hop


BTS5 RF hop

BTS4 AH hop

BCF 1 BCF 2


LMU UltraSite - UltraSite Multi-BCF

B =

B

B

B

MASTER



Figure 6

BTS1

BTS2

2

3 4

BTS3

BCF 1

SLAVE Talk GSM

SEGMENT 2

5 6

1 SEGMENT 1

SEGMENT 3

1

2

3

4

5

6 BTS6 RF hop


BTS5 BB hop

BTS4 No hop

BCF 2

B

B

B


LMU Talk - UltraSite Multi-BCF

B =

MASTER


DN0694168 Issue 1-0


79 (252)

Figure 7

BTS3

BTS1

BTS6

BTS5

BTS2

BTS4

TS l k d

TS l k d

BTS7

SEGMENT 1

SEGMENT 2

SEGMENT 3

Extra BTS, separate from synchronised chain. Neighbour of SEG 1

Neighbour of BTS 7

Neighbour of SEG 2

Neighbour of SEG 3

Ring of Adjacent Cells / Segments



10.7 Automatic Link Adaptation Purpose:

The purpose of these test cases is to prove that during a single timeslot or Multislot call the rate of each channel can be modified as commanded from BSC and there are no errors on user data during adaptation.

Test Tools Required: Signal generator

Input Expected Output Use a multi TRX configuration. Data Call is established between MS and PSTN in source cell as specified in test case. [Calls are not established MS to MS as user data rate will be capped at the lowest Link rate]

The call can be established in source cell as specified in test case

A data file is transferred first from A to B and then B to A for each test case. At the receiving end of the data packet the transfer data rate is monitored.

The achieved CS data transfer rate of user data reflects the channel type used at the time of the CS data transfer

By using BSC parameters and degrading the air interface conditions, the link adaptation takes place to the target data rate. The air interface conditions are changed to return to the source cell user rate. Use command ZEUG to enable ALA This change between data rates is made at least 10 times during the file transfer. The test case is repeated for 3 different TS.

When link adaptation occurs there are no errors in the received data and the achieved user data rate changes to the new rate. For Single-slot data connection, a CHANNEL MODE MODIFY msg and for Multislot connection, a CONFIGURATION CHANGE COMMAND msg is seen on the A-bis indicating the new data rate. The same timeslot(s) are used through the Automatic Link adaptation procedure.

Case Ref.

Source Cell Call type / data rate

Target Call type / data rate

Hopping

1. Single TS, NT 14400 Single TS, NT 9600 RAH-hopping

2. Single TS, NT 14400 Single TS, NT 9600 Non-hopping

3 Multislot (2+2), NT 14400 Multislot (2+2), NT 9600

BB-hopping


DN0694168 Issue 1-0


81 (252)

10.8 Multislot Upgrade / Downgrade Purpose:

The purpose of these test cases is to prove that during a single timeslot or Multislot call the rate of each channel can be modified as commanded from the BSC and there are no errors on user data during upgrade/downgrade.

Input Expected Output Use a muti TRX configuration.

Data Call is established between MS and PSTN in source cell as specified in test case.

The call can be established in source cell as specified in test case

A data file is transferred first from A to B and then B to A for each test case. At the receiving end of the data packet the transfer data rate is monitored.

The achieved CS data transfer rate of user data reflects the channel type used at the time of the CS data transfer.

By using BSC parameters and controlling the traffic loading on the TRX resource upgrading / downgrading take place. Use command ZEQX to modify parameters HCL/HCU for upgrade/downgrade. Resource upgrade and downgrade is done at least 10 times during file transfer.

When resource upgrade (from source to target call) / downgrade (from target to source) occurs there are no errors in the received data.

Case Ref.

Source Cell Call type / data rate

Target Call type / data rate

1. Single-slot (1+1), NT 9600 Multislot (2+2), NT 9600

2. Single-slot (1+1), NT 14400

Multislot (2+2), NT 14400

3. Multislot (2+2), NT 14400 Multislot (3+1), NT 14400



10.9 DTX Applied to Speech & Data calls Purpose:

The purpose of these test cases is to prove that DTX (UL & DL) can be applied to speech & data calls, that the A-bis messages Measurement Reports and RF RES IND indicate the appropriate values during DTX usage, and there is no audio disturbances heard or loss of speech or data loss during DTX operation transition.

Test Tools Required: FAX Setup

Input Expected Output Test cases are performed with the B-subscriber on a different cell as A-subscriber, but same Codec or a PSTN connection.

A voice call is made between A and B, the A-subscriber is made to perform asynchronous inter cell handovers every 15 seconds. The test case last for at least 10 minutes.

The call can be established and held for the duration of the test case.

The A and B subscribers cycle between conversation & periods of silence. The received audio in monitored for speech intelligibility, comfort noise when DTX is applied, missing speech at start of conversation following DTX usage & any disturbing audio disturbances.

During the test there are no audio disturbances heard at either A or B subscriber during transition periods of DTX usage or during handover.

A-bis Measurement Result message values when DTX is not used for RX Qual Full & Sub in both uplink and downlink shall in laboratory conditions is predominantly of value 0. When DTX is applied then values of RX Qual Full should be 7 & RX Lev Full tends to be -110dB, The RX qual Sub shall in laboratory conditions be predominantly of value 0. MS Speed value shall be reported when frequency hopping and Uplink DTX are not active; otherwise the value shall be 'Not Valid'. A-bis RF RES IND message shall include the interference measurement for a reserved TCH (FR /EFR) timeslot.

The A-bis TRX signalling link is followed during the test.

In HR speech channel the interference estimation can be done only of those burst where MS hasn’t send anything i.e. MS is in DTX state


DN0694168 Issue 1-0


83 (252)

When Downlink DTX applied, the BTS shall only stop RF transmission on a non-BCCH timeslot.

Case Ref.

Codec/Data Type

DTX Mode Hopping Mode

B subscriber

1. FR UL & DL BB-hopping PSTN

2. AMR1 UL & DL BB-hopping PSTN

3. EFR UL NAH-hopping MS

4. HR#0 & HR#1

UL & DL RAH-hopping PSTN

5. HR#0 & HR#12


6. HR#0 & HR#13


1 Do this test case with Release6 Mobiles 2 Use BSC S12, 3 Do this case with BSC SW S12 ED 3.1 release

Input Expected Output A data call is made between A and B, the A-subscriber is made to perform asynchronous inter cell handovers every 15 seconds. Data file to be transferred at least 5 times for each test case.

The call can be established and held for the duration of the test case.

A 50kb data file is repeatedly sent from A to B and then B to A during the test case. For Group 3 fax call, a multi page document is sent and received.

The data is received accurately. DTX can be seen to be used during periods when no data was sent / received. DTX cannot be applied to a transparent data / fax call even when set active in the MS & BTS. The DTX flag in the Measurement Report not used and RF transmission is made in all GSM frames.



A-bis Measurement Result message values when DTX is not used for RX Qual Full & Sub in both uplink and downlink shall in laboratory conditions is predominantly of value 0. When DTX is applied then values of RX Qual Full should be 7 & RX Lev Full tends to be -110dB, The RX qual Sub shall in laboratory conditions be predominantly of value 0. MS Speed value shall be reported when frequency hopping and Uplink DTX are not active; otherwise the value shall be 'Not Valid'. A-bis RF RES IND message shall include the interference measurement for a reserved TCH (FR /EFR) timeslot.

The A-bis TRX signalling link is followed during the test.

When Downlink DTX applied, the BTS shall only stop RF transmission on a non-BCCH timeslot.

Case Ref.

Codec/Data Type

DTX Mode Hopping Mode

B subscriber

7. Single, NT 14400

UL & DL Non-hopping PSTN

8. Group 3, Fax 9600

UL & DL Non-hopping MS


DN0694168 Issue 1-0


85 (252)

10.10 DTX Applied to Speech Calls without handovers

Input Expected Output Test cases are made with the B-subscriber on a different cell as A-subscriber, but same codec or a PSTN connection. Call is made via BCCH TRX.(ASI feature is kept on) The A and B subscribers cycle between conversation & periods of silence. The received audio in monitored for speech intelligibility, comfort noise when DTX is applied, missing speech at start of conversion following DTX usage & any disturbing audio disturbances. The A-bis TRX signalling link is followed during the test.

The call can be established and held for the duration of the test case. During the test there are no audio disturbances heard at either A or B subscriber during transition periods of DTX usage .There shall not be handovers during transition of DTX usage. A-bis Measurement Result message values when DTX is not used for RX Qual Full & Sub in both uplink and downlink shall in laboratory conditions is predominately of value 0. When DTX is applied then values of RX Qual Full should be 7 & RX qual Sub shall in laboratory conditions be predominately of value 0. A-bis RF RES IND message shall include the interference measurement for a reserved TCH(FR /EFR) timeslot. In HR speech channel the interference estimation can be done only of those burst where MS hasn’t send anything i.e. MS is in DTX state When Downlink DTX applied, the BTS shall only stop RF transmission on a non-BCCH timeslot.

Case Ref.

Codec DTX Mode Hopping Mode

B subscriber

1. AMR DL Non-hopping GSM mobile



10.11 Measurement Pre-processing Purpose:

The purpose of these test cases is to prove that BTS can pre-process the measurement reports as defined by BSC parameter, and that the numbering sequence of the A-bis Measurement Reports are always consecutive.

For each measurement period, UL_FER is reported, when pre-processing is used. I.e. if pre-processing =3 then there will be 3 values of UL_FER.

Input Expected Output Each test case is repeated with the BSC parameter BMA set to 1, 2, 3 & 4.

A call is established and the A-bis Measurement Report numbers are observed. Calls are held until the Measurement report values recycle back to 0. The UL FER values are also monitored.

The measurement report number are always consecutively reported (i.e. 0, 1, 2, 3…254, 255, 0…) and the interval of sending on the A-bis is 480mS * BMA value. The UL FER values are not averaged for each measurement period. For AMR calls first and last Codecs used, seen correctly.

Case Ref.

Call type

1. FR

2. HR#0 & HR#1

3. AMR (AFS with 4 Codecs)

4. AMR (AFS with 4 Codecs)1

5. Multislot data (2+2), NT 14400 1..Do the test case with BSC S12

10.12 Interference with HR channel when high traffic

Purpose: The purpose of the test cases is to verify that interference values are reported correctly for half rate/full rate traffic channels.


DN0694168 Issue 1-0


87 (252)

Note 25. A signal generator is needed to introduce interference in the uplink frequency.

Note 26. Uplink DTX is switched off/on using ZEQM:<bts no>: DTX=1(ON) or 2 (OFF)

Note 27. Ensure that no ‘real’ interference is present on the frequency used.

Note 28. Configure TS0 as MBCCH, TS1 as SDCCH, TS2-7 as TCHD

Input Output Configure the BCF as given in the table. The base station is in Supervisory with no

unexpected alarms High traffic is generated through short duration calls for 2 Hours using a MCG or 10-12 phones. All these calls are HR.

Calls are successful.

Monitor the interference (I LEV) on the Traffic channels using MML command ZERO Monitor the RF Resource Ind messages on the Nethawk Alternatively interference can be checked by using the BSC Radio Measurement Monitoring Service Terminal command

No interference is present in the uplink path. In RF Resource Ind message no Interference is reported.

A signal generator is used to introduce interference in the uplink frequency path. Monitor the interference level as in step above.

Interference value greater than ‘0’ is reported on the MML (ZERO Command) and in the RF Resource Ind message, depending on the level of the interference introduced.

Case Ref. BCF Configuration Uplink DTX 1 1 Omni EDGE UltraSite. OFF

2 1 TRX EDGE MetroSite OFF Note 29. Configure TS0 as MBCCHC TS1 as SDCCB, TS2-7 as TCHH for TRX1

TS0-7 as TCHH for TRX2 for test cases 1-288444521.04 and 1-288444521.05.

Configure TS0 as MBCCHC TS1 as SDCCB, TS2-7 as TCHD for TRX1

TS0-7 as TCHD for TRX2 for test cases 1-288444521.06 and 1-288444521.07.

Input to Verify the Correction Expected Output Configure the BCF as given in the table. The base station is in Supervisory with no

unexpected alarms



Input to Verify the Correction Expected Output High traffic is generated through short duration calls for 1 Hour using a MCG or 14-16 phones and 10 continuous calls during the whole test.

Calls are successful.

Monitor the interference (I LEV) on the Traffic channels using MML command ZERO Monitor the RF Resource Ind messages on the Nethawk Alternatively interference can be checked by using the BSC Radio Measurement Monitoring Service Terminal command

No interference is present in the uplink path. In RF Resource Ind message no Interference is reported.

A signal generator is used to introduce interference in the uplink frequency path. Monitor the interference level as in step above.

Interference value greater than ‘0’ is reported on the MML (ZERO Command) and in the RF Resource Ind message, depending on the level of the interference introduced.

Stop the interference in the uplink frequency path. Monitor the interference level as in step above.

No Interference is reported on the MML (ZERO Command) and in the RF Resource Ind message, depending on the level of the interference introduced.

Case Ref. BCF Configuration Uplink DTX Call Type 3 2 Omni GSM UltraSite OFF AHS 4 2 Omni GSM MetroSite OFF AHS 5 2 Omni Hybrid UltraSite ON AFS, FR EFR, HR,

AHS 6 2 Omni GSM/EDGE MetroSite ON AFS, FR EFR, HR,

AHS 7 2 Omni Hybrid UltraSite ON AFS, FR EFR, HR,

AHS1 8 2 Omni GSM/EDGE MetroSite ON AFS, FR EFR, HR,

AHS1 1 Do test case with release6 Mobiles

10.13 Mobile Speed Handling Purpose:

The purpose of these test cases is to verify that the Mobile Speed Detection works correctly.



DN0694168 Issue 1-0


89 (252)

Note 30. Mobile Speed Detection can only be seen on A-bis Trace when uplink DTX and hopping is not in use.

Input Expected Output A multi TRX sector is used with channel configuration and hopping mode, specified as per test case.

The call can be established on SDCCH and held until terminated.

Mobile travelling at speeds of 5km/h, 30km/h, 80km/h and 200km/h in each test case.

A call is made as mentioned in the test case and each call held for at least 5 minutes with the MS moving to / from the BTS starting with TA values of 0 & 15km.

For speech calls received audio quality is good and without distortion. In case of data calls, data can be sent and received in both directions with the user data rate is achieved on transfers.

On A-bis TRX signalling are monitored during each test case. Note: For test case 1& 4, Setup call while MS is travelling at 330Km/h. Only EDGE h/w to be used for these test cases.

The A-bis Measurement Result message shows the correct MS speed value when frequency hopping is not active. In cases where the speed cannot be detected the value is reported as 'Not Valid'. The maximum reliable speed detection is approximately 60 km/h (36 miles/h) in GSM 900 and 35 km/h (21 miles/h) in GSM 1800 & GSM 1900.

Case Ref.

Channel Configuration / Speech Codec Hopping Mode

1. MBCCH+SDCCH+TCHF/EFR Non-Hopping

2. MBCCH+SDCCH+TCHF/EFR1 Non-Hopping

3. MBCCHC+TCHD/ Single-slot data T 9600 BB- Hopping

4. MBCCH+TCHF/ Single-slot data, NT 9600 RF-Hopping

5. MBCCH+TCHF/ Multislot data (2+2), NT 14400 Non-hopping 1..Use UltraSite EDGE configuration

10.14 BTS Power Control Purpose: To Check that 8PSK timeslot has no adverse affect on adjacent GMSK timeslots.



Test Tools Required: Data cart, Spectrum Analyzer

Use any configuration. Dynamic A-bis is enabled. Non-BCCH TRX is used for test Set BTS to use MCS-9 (Disable link adaptation: ZEQV:BTS=##:ELA=0; Set initial coding scheme: ZEQV:BTS=##:MCA=#,MCU=#;) Set up CS speech calls on timeslots 6 & 0 Set up EGRPS data transfer in the specified direction on timeslot 7 Using spectrum analyser monitor power level of EGPRS & CS speech call timeslots Attenuate UL & DL of CS speech call. Monitor A-bis. Terminate calls

CS calls are setup Data transfer begins. CS calls are unaffected by EGPRS EGPRS power level is equal to BCCH (i.e. PMAX parameter). Speech call power level is dependent on signal strength. EGPRS power level remains equal to BCCH. Speech call power level increases with attenuation. Power control message is seen on A-bis.

Purpose:

The purpose of these cases is to prove that BTS power control commands from the BSC is used on BCCH and non-BCCH TRX configurations.


DN0694168 Issue 1-0


91 (252)

Input Expected Output BTS Power control settings in BSC are that BCCH power level is set to maximum, and the whole of the dynamic power control range is available. A timeslot is used as defined in the channel type, hopping mode and TRX type. (Keep ASI feature “On” for test case 2) The BTS to MS RF path is not attenuated; forcing the BSC to decreases BS power over the dynamic control range. The BTS to MS RF path is then attenuated so the BSC increases the BS power over the dynamic control range. Use spectrum analyser to measure BCCH output power. The A-bis BS POWER CNTL & Measurement Report messages and RF power level of TX Transmission of BTS are monitored during the whole test case.

The call can be established and held until terminated. For speech the audio quality is good and without distortion, and for multislot calls the data is received accurately. The BCCH transmitted RF power will be BSC PMAX value for all timeslots. If baseband hopping is being used in the BTS, the BSC sends the BS POWER CNTL commands also to the BCCH transceiver For non-BCCH channel activation the BS RF Power reflect the last BS POWER CNTL from the BSC. For Multislot data all used TS in call shall use the same BS power level. The BTS reports in the Measurement report the last used BS Power level.

Case Ref.

Channel type Hopping Mode / TRX Type

1. AMR Non-hopping / BCCH & non-BCCH TRX

2 FR or EFR1 BB-hopping / BCCH & non-BCCH TRX

3 FR or EFR RAH-hopping /Non-BCCH TRX 1. enable .ASI feature



11 Recovery from Fault Conditions

11.1 TRAU Frame Breaks Purpose:

The purpose of these cases is to prove that TRX can detect the TRAU frame synchronisation loss and can report it to BSC with A-bis message 'Error Ind'. Also check that on removal of fault, speech calls are possible.

Input Expected Output The BSC parameter 'number of ignored transcoder failures' (ITCF) is set value 0. To modify ITCF use MML Command: ZEEQ:ITCF=0;

A call is established. Then on the A-bis interface the TRAU frame link of active call is broken as defined in the test case. A-bis TRX link is monitored. A Talk Family BTS can be used to break the TRAU frames.

When the TRX detects frame synchronisation lost, the A-bis message 'Connection Fail' with reasons 'Remote Transcoder Failure' is sent to BSC. The call is released by BSC after receiving this message.

A call is re-established on the same timeslot after the link has been restored.

The call can be re-established on the previously failed timeslot

Case Ref.

Call Type A-bis TRAU frame link broken

1. FR Both directions

2. HR#0 & HR#1 Downlink direction only

3. Single-slot data, NT 9600 Uplink direction only

Recovery from Fault Conditions

DN0694168 Issue 1-0


93 (252)

4. Multislot data (3+1), NT 14400

Both used TS in both directions

5. AMR (AFS, with four Codecs)

Both directions



12 Separate RLT Parameter for AMR and EFR

BTS and MS use the Radio Link Timeout –value received in SI6 –message to supervise the radio link. The value sets the limit for the amount of unsuccessfully decoded SACCH frames. Once the limit is reached the channel is released.

Separate radio link timeout parameters for AMR and EFR –feature enables the BSS to use a different RLT value for AMR calls. RLT for AMR calls can be set to a higher value than the RLT for other connections. The feature name also refers to EFR – however, BSC implementation will not support setting a separate RLT for EFR calls. BTS implementation must not take into account the connection type. It shall always assume that BSC is sending a connection specific RLT if connection specific SI6 is received. So, in BSC there will be a separate parameter (ARLT) where user can set RLT value to be used with AMR calls. For all other channels BSC will use the existing RLT parameter value.

Note 31. Both EDGE and GSM TRXs will support this feature. Note 32.

Radio link timeout value can be checked using EQO:BTS=bts_no:RAD; command for non-AMR calls.

Note 33.

For AMR calls a new parameter ARLT (AMR radio link timeout is added in BSC 11.5). It can be viewed using following command

ZEQO: BTS=bts_no: AMR;

To modify the value of ARLT use following command

ZEQY: BTS= bts_no: ARLT=xx;

Note 34. Range of RLT and ARLT is from 4 to 64. Note 35. Radio Link timeout is simply the incapacity to decode the SACCH RLT/ARLT times on Layer 1. This definition applies to both uplink and downlink. For SACCH messages that cannot be read, the channel decoder sets the BFI flag to 1. When a radio link failure on Layer 1 is detected on a dedicated channel (TCH and SDCCH), the BTS sends a CONN_FAIL message with cause 1 = radio link failure to the BSC.

Separate RLT Parameter for AMR and EFR

DN0694168 Issue 1-0


95 (252)

Note 36. During call establishment Radio Link Timeout value is received in SI6 message in CHANNEL ACTIVATION message to supervise the radio link as defined in BSC. Note 37. If SI6 is not received in CHANNEL ACTIVATION then TRX specific RLT value is used as a default value received during TRX initialisation. Note 38. The term “High Interference” used in Test cases means that MS/BTS is not able to decode the SACCH messages in DL/UL direction e.g. Interference greater than Signal level. Note 39. For IBHO MSC version M12 is required. Note 40. All AMR test cases to be done with fast LA enabled unless otherwise stated. Fast LA can be changed at the BSC using MML command ZEEM.

Note 41. Default AMR Codec Sets (ACS) as defined in BSC is used unless otherwise stated. Default Codecs are:

• FR Codec modes - 12.2, 7.4, 5.9, and 4.75 • HR Codec modes - 7.4, 5.9, and 4.75.

12.1 Radio link timeout with speech call Purpose: The purpose of this test is to prove that Radio link timeout occurs as defined by ARLT/RLT parameter in BSC with speech call(s) during active phase.

Test Tools Required:

Signal Generator, Spectrum Analyser, Screened Box and Fading Simulator



Input Expected Output Check the RLT and ARLT parameter at BSC [Note 32and Note 33]. Define RLT=20, ARLT=24 Use command ZEHG to disable intracell HO by setting EIC=N, and EIH=N

Calls are made from MS to MS as defined in the test case.

During call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to RLT (for EFR call)/ARLT (for AMR call) value defined in BSC. All calls are established successfully. The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.

With active call High interference [Note 38] is introduced in UL direction. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT (for EFR/FR/HR call) or ARLT (for AFS/AHS call) parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It can be verified from the A-bis traces that radio link timeout occur after (480*RLT) ms for non-AMR call and (480*ARLT) ms for AMR call once High interference [Note 38] is introduced. Calls are released.

Calls are made again from MS to MS. High interference [Note 38] is introduced in DL direction.

Call establishment is successful. MS starts sending Measurement Report (with RX QUAL=7) till Radio link timeout occurs. Number of Measurement Reports (with RX QUAL=7) send by Mobile will be equal to RLT (for EFR/FR/HR call) or ARLT (for AFS/AHS call). After radio link timeout MS stops sending Measurement Report i.e. SACCH messages.

The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT (for EFR/FR/HR call) or ARLT (for AFS/AHS call) parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. Calls are released.

Case Ref.

Configuration Channel configuration

Call Type Hopping


DN0694168 Issue 1-0


97 (252)

Input Expected Output 1 2 omni

(EDGE+EDGE) MBCCHC + TCHD

AHS RAH

2 2 omni (EDGE) MBCCHC + TCHF

EFR and AFS on same TRX (BCCH TRX)

BB

3. 2 omni (EDGE)1

MBCCHC + TCHF

EFR and AFS on same TRX (BCCH TRX)

BB

4. 4 Omni, Ecell Config (Ultra Site)

MBCCHC + TCHF

FR and AFS on same TRX (E-cell TRX)

None

1..Do with Release6 Mobiles

12.2 Radio link timeout on TCH for EFR/FR with change of ARLT

Purpose:

The purpose of this test is to prove that Radio link timeout occurs as defined by RLT parameter in BSC with EFR/FR call during active phase and change of ARLT does not impact it.


Signal generator, Spectrum Analyser, Screened Box

Input Expected Output Check the RLT and ARLT parameter at BSC. Define RLT=16 and ARLT=16

Establish MS to MS Call as defined in the test case.

During call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to RLT value defined in BSC. Call is established successfully. The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.



Input Expected Output With active call High interference is introduced in UL direction such that Radio link timeout occurs for (E)FR call. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It can be verified from the A-bis traces that radio link timeout occur after (480*RLT) ms for (E)FR call once High interference is introduced. Call is released.

Change ARLT=32. Establish MS to MS Call as defined in the test case.

Call establishment is successful. Change in ARLT does not have any impact on (E)FR call. During call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to RLT value defined in BSC.

With active call High interference is introduced in UL direction such that Radio link timeout occurs for EFR call.. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It can be verified from the A-bis traces that radio link timeout occur after (480*RLT) ms for (E)FR call once High interference is introduced. Call is released.

Case Ref.

Configuration


DTX used Call type

1. Any MBCCHC + TCHF

UL and DL both (Calls are on BCCH TRX)

EFR


No (Calls are on Non BCCH TRX)

FR

12.3 Radio link timeout on TCH for AMR with change of RLT

Purpose:

The purpose of this test is to prove that Radio link timeout occurs as defined by ARLT parameter in BSC with AMR call during active phase and change of RLT does not impact it.


DN0694168 Issue 1-0


99 (252)



Input Expected Output Check the RLT and ARLT parameter at BSC. Define RLT=16 and ARLT=16 Use any configuration. Define Codec mode in ACS as given in test case using MML command ZEQY.

Establish MS to MS AMR Call as defined in the test case.

During call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to ARLT value defined in BSC. Call is established successfully. The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.

With active call High interference is introduced in direction specified in the test case such that Radio link timeout occurs for AMR call. The A-bis TRX signalling links are recorded during the test. TRAU frames are also monitored during the call.

With interference applied Codec mode is changed towards the most robust Codec mode. Codecs observed are same as defined in the test case. It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by ARLT parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It can be verified from the A-bis traces that radio link timeout occur after (480*ARLT) ms for AMR call once High interference is introduced. Call is released.

Change RLT=32. Establish MS to MS AMR Call as defined in the test case.

Change in RLT does not have any impact on AMR call. During call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to ARLT value defined in BSC.



Input Expected Output With active call High interference is introduced in direction specified in the test case such that Radio link timeout occurs for AMR call. The A-bis TRX signalling links are recorded during the test. TRAU frames are also monitored during the call.

With interference applied Codec mode is changed towards the most robust Codec mode. Codecs observed are same as defined in the test case. It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by ARLT parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It can be verified from the A-bis traces that radio link timeout occur after (480*ARLT) ms for AMR call once High interference is introduced. Call is released.

Case Ref.

Codec Mode in ACS


DTX used Interference

Call Type

1. 10.2, 7.4, 5.9, 4.75

MBCCHC+ TCHF


In UL AFS

2. 7.4, 6.7, 5.9 MBCCHC+ TCHD


In UL AHS

12.4 Radio link timeout on TCH for AMR with different values of ARLT

Purpose:

The purpose of this test is to prove that Radio link timeout occurs as defined by ARLT parameter in BSC with AMR call during active phase.



Input Expected Output Check the RLT and ARLT parameter at BSC. Define ARLT as given in the test case.


DN0694168 Issue 1-0


101 (252)

Input Expected Output Establish MS to MS AMR Call.


With active call High interference is introduced in UL direction such that Radio link timeout occurs for AMR call. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by ARLT parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It can be verified from the A-bis traces that radio link timeout occur after (480*RLT) ms for EFR call and (480*ARLT) ms for AMR call. Call is released.

Case Ref.

Configuration


DTX used ARLT

1. 2 omni (EDGE)

MBCCHC + TCHF


4

2. 2 omni (GSM+EDGE)

MBCCHC + TCHF


32

3. 2 omni (GSM)

MBCCHC + TCHF


64

4. 2 omni (GSM)

MBCCHC + TCHF


Invalid value1

1 If invalid values of ARLT parameter is defined i.e. < 4 or > 64 using MML command ZEQY then for value less than 4 error “VALUE TOO LOW” and for value > 64 errors “ VALUE TOO HIGH” will be observed on MML. For this test case further test steps as given above will not be valid.



12.5 Radio link timeout on TCH for AMR with change of ARLT

Purpose:

The purpose of this test is to check the impact of change in ARLT value on already established AMR call.




Establish MS to MS AMR Call as specified in the test case. Change ARLT=32 Another pair of AMR Call is made from MS to MS as specified in the test case.

During call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to ARLT value defined in BSC. During call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to new ARLT value defined in BSC. New ARLT value has no impact on the call made at the start of test case. All calls are established successfully. The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.

With active calls High interference is introduced in UL direction such that Radio link timeout occurs for AMR calls. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as received from BSC with respective calls, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It is clear from the A-bis trace that call made at the start of test case is released first as its ARLT value is lower than ARLT value of new call. Calls are released.


DN0694168 Issue 1-0


103 (252)


Configuration


DTX used Call Type



AFS

2. Any MBCCHC + TCHD


AHS

12.6 Radio link timeout on TCH for AMR and GP recovery

Purpose:

The purpose of this test is to check the impact of radio link timeout on GP timeslot.

Note 42. The Customer configuration for the Trial is defined as 1 N-TRX + 1 E-TRX,combinerless, in a BTS. All TRXs are EDGE capable. MHAs may be used, in which case all TRXs should have one. Exception is test case 202817.07, where MHAs must be used.



Input Expected Output Check the RLT and ARLT parameter at BSC [Note 32and Note 33]. Define ARLT=24 Define CDED=0, CDEF=100,CMAX=100 using ZEQV command and activate EGPRS in cell.

All TCH timeslots change to GP timeslot except one.

Establish MS to MS AMR Call.




Input Expected Output With active calls High interference [Note 38] is introduced in UL direction such that Radio link timeout occurs for AMR calls. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as received from BSC with respective calls, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. Call is released.

Monitor the GP timeslot on the Abis. GP timeslot resynchronises and PCU Master data frames are seen on the timeslot on which radio link timeout occurred earlier.

Transfer 1 MB file in DL direction using the GP timeslots used earlier for AMR call.

Data transfer is successful.

Case Ref. Configuration Channel configuration 1. One omni MBCCHC+ TCHF

2 Customer Ecell conf (EGENA enabled for N-Area)

MBCCH+SDCCH+TCHD

12.7 Radio link timeout with Handover Purpose: The purpose of this test is to prove that Radio link timeout occurs as defined by ARLT/RLT parameter in BSC with AMR/EFR call(s) after Handover has been performed successfully.

Note 43.

ACH-> with this parameter you define the preference between the currently used Multirate configuration and the one defined for the target BTS during internal and external handovers. Use MML command ZEEM to modify the ACH command. ACH=2 means that the Multirate configuration of the target BTS is preferred in further channel allocations.




DN0694168 Issue 1-0


105 (252)

Input Expected Output Check the RLT and ARLT parameter at BSC. Define RLT=20, ARLT=24 for Source cell. Define RLT=16, ARLT=28 for Target cell. Check that ACH=2 are defined at BSC. See Note 43. HO type is defined as SYNC with ZEAC for Synchronous handovers.

Calls are made from MS to MS in source cell as defined in the test case.


Level of Source cell is degraded using variable attenuator in DL direction so that Handover is triggered.

Handover to Target cell is successful. MS receives new Radio Link Timeout value as defined for Target cell.

With active call High interference is introduced in UL direction in target cell. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT (for EFR call) or ARLT (for AMR call) parameter on BSC for target BTS, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. Calls are released.

Calls are made again from MS to MS as defined in the test case.

Call establishment is successful.

Level of Source cell is degraded using variable attenuator in DL direction so that Handover is triggered.

Handover to Target cell is successful. MS receives new Radio Link Timeout value as defined for Target cell.

High interference is introduced in DL direction. The A-bis TRX signalling links are recorded during the test

MS starts sending Measurement Report (with RX QUAL=7) till Radio link timeout occurs. Number of Measurement Reports (with RX QUAL=7) send by Mobile will be equal to RLT (for EFR/FR/HR call) or ARLT (for AFS/AHS call). After radio link timeout MS stops sending Measurement Report i.e. SACCH messages. It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT (for EFR/FR/HR call) or ARLT (for AFS/AHS call) parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. Calls are released.




Configuration

Source cell call type

Target Cell call type

DTX used Handover Type

1. Any AFS EFR Both UL & DL

Synchronous

2. Any EFR AFS UL only Synchronous

3. Multi BCF configuration

AHS (Master BCF)

AHS (Slave BCF)

DL only Synchronous

4. 4+4+4 Simultaneous AFS and EFR

AFS and EFR1

Both UL & DL

Asynchronous

5. Any AFS (GSM cell) AFS2 (GSM cell)

Both UL & DL

Asynchronous

1 InterBSC Handover is performed. 2 IMSI Based Handover is performed.

12.8 Object control and Radio link timeout Purpose:

The purpose of this test is to prove that Radio link timeout occurs as defined by ARLT/RLT parameter in BSC with AMR/EFR call(s) after object is locked/unlocked/blocked/unblocked.



Input Expected Output Check the RLT and ARLT parameter at BSC. Define RLT=20, ARLT=24

Calls are made from MS to MS as defined in the test case.



DN0694168 Issue 1-0


107 (252)

Input Expected Output With active call High interference is introduced in UL direction. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT (for EFR call) or ARLT (for AMR call) parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. Calls are released.

Action is performed on object specified in the test case. Define RLT=16, ARLT=20 Action is undone.

Object comes in WO state.

Calls are made from MS to MS as defined in the test case on the object the action is performed.


With active call High interference is introduced in UL direction. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT (for EFR call) or ARLT (for AMR call) parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. Calls are released.

Case Ref.

Configuration


Call Type Object Type

Action

1. 6 omni with IDD/4UD

MBCCHC + TCHF

AFS & EFR both

BCF1 Lock

2. Any MBCCHC + TCHD

AHS & EFR both

TRX Lock


AFS (with EMR on)

BTS Lock

1Do not change RLT and ARLT values for this test case.



12.9 AMR packing/unpacking and Radio link timeout

Purpose:

The purpose of this test is to prove that Radio link timeout occurs as defined by ARLT parameter in BSC with AMR call once AMR unpacking has been performed and Unpacking has no impact on RLT.

Note 44.

Packing of FR AMR calls to HR AMR calls due to cell load

Spontaneous packing of FR AMR calls to HR AMR calls is triggered when the cell load is high enough; the number of free full rate resources reduces below the value of the parameter Lower limit for FR TCH resources. Spontaneous packing is triggered by any new channel allocation.

Unpacking of HR AMR calls to FR AMR calls due to call quality

Spontaneous unpacking of HR AMR calls to FR AMR calls is triggered when the quality of a HR AMR call degrades below the intraHOthresholdRxqual For AMRHR. Cell load does not have an effect.



Input Expected Output Check the ARLT parameter at BSC. Define ARLT=24 Use default AMR parameters as defined in the BSC.

Establish MS to MS AHS Call.



DN0694168 Issue 1-0


109 (252)

With active call, interference is introduced in UL direction and increased slowly so that the quality of the HR AMR call degrades under the BTS parameter ‘intra HO threshold Rx Qual for AMR HR’. The A-bis TRX signalling links are recorded during the test

HR AMR call is unpacked to FR AMR call. It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT (for EFR call) or ARLT (for AMR call) parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It is clear that AMR Unpacking has no impact on ARLT functionality. Call is released.

Case Ref. Configuration Channel configuration 1. (4+4) common BCCH+4 MBCCHC+ TCHD

Calls are non BCCH BTS.

2 (4+4) common BCCH+4 MBCCHC+ TCHD Calls are non BCCH BTS.1

1 Perform the test case with BSC SW S12 ED3.1 release

12.10 Multiple speech calls and Radio link timeout

Purpose:

The purpose of this test is to prove that Radio link timeout occurs as defined by ARLT/RLT parameter in BSC with AMR/EFR call(s) only for interfered call.



Input Expected Output Check the ARLT parameter at BSC. Define ARLT=24 Use default AMR parameters as defined in the BSC. All TCH timeslots of Non BCCH TRXs are locked.



Input Expected Output Make 2 pairs of EFR to EFR speech call and 2 pairs of AMR to AMR speech call.


With active call, High interference [Note 38] is introduced in DL direction of one pair of call each of AMR and EFR (i.e. one pair of AMR to AMR and one pair of EFR to EFR). The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as defined by RLT (for EFR call) or ARLT (for AMR call) parameter on BSC, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. Calls with no interference remain active and their quality remains good. Interfered Calls are released from BSC.

Case Ref. Configuration Channel configuration 1. 6+6 with RTC MBCCHC+ TCHF

12.11 Multiple speech calls with change in RLT/ARLT

Purpose:

The purpose of this test is to check the impact of change in RLT and ARLT value on already established EFR and AMR calls.

Test Tools Required: Signal generator, Spectrum Analyser, Screened Box



DN0694168 Issue 1-0


111 (252)

Input Expected Output Make an EFR to EFR speech call and an AMR to AMR speech call. Change RLT=24 and ARLT=32 Make another EFR to EFR speech call and another AMR to AMR speech call.

During call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to RLT (for EFR call)/ARLT (for AMR call) value defined in BSC. All calls are established successfully. All calls are established successfully. New calls receive new RLT/ARLT values. The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.

With active calls High interference is introduced in UL direction such that Radio link timeout occurs for calls. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as received from BSC for respective calls, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. It is clear from the A-bis trace that calls made at the start of test case are released first as there (A)RLT value are lower than (A)RLT value of new calls. Calls are released.

Case Ref.

Configuration Channel configuration

DTX used

1. 4+4+4 MBCCHC + TCHF


12.12 Multiple Breaks at Air interface Purpose:

The purpose of this test is to check that counter for SACCH frame is working correctly with multiple breaks at air interface with active AMR call.





Input Expected Output Establish MS to MS AMR Call.

During AMR call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to ARLT value defined in BSC. The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.

With active calls interference is slowly increased in UL direction such that Radio link quality becomes bad and SACCH messages are not correctly decoded at the receiving side.

It is observed that as soon as BTS is not able to decode SACCH messages receiving side start decrementing the counter.1

Once receiving side starts counter1 but its value remains > 0, remove the interference. Call remains active. Wait for 30 sec.

Call remains active, quality becomes good and speech is without any disturbance. Counter is incremented to MAX value (ARLT).1

Now above 2 steps are repeated 5 times. Call remains active.

Wait for 5 minutes. With active calls High interference [Note 38] is introduced in UL direction such that Radio link timeout occurs for calls. The A-bis TRX signalling links are recorded during the test

Call is active and received audio shall be good and without distortion of the original speech. It is observed that as soon as BTS is not able to decode number of SACCH messages as received from BSC for respective calls, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. Calls are released.

Case Ref.

Configuration


DTX used



1This counter cannot be observed on Abis interface, its value will be equal to ARLT for AMR call, so it is indirectly being tested here. If counter will not be incremented to its MAX value (=ARLT for AMR call) once interference is removed then in few iterations (interference on and off) radio link timeout will occur as soon as Interference is introduced.

12.13 T200 Expiry Purpose: The purpose of this test is to check that due to radio link failure at air interface timer T200 expires correctly with different values of ARLT.


DN0694168 Issue 1-0


113 (252)



Establish MS to MS AMR Call. During AMR call establishment Radio Link Timeout –value received in SI6 –message to supervise the radio link is equal to ARLT value defined in BSC. The received audio shall be good and without distortion of the original speech, and there shall be no additional disturbing sounds heard at the receiving end during speech or silence periods.

With active call High interference is introduced in UL direction. The A-bis TRX signalling links are recorded during the test

It is observed that as soon as BTS is not able to decode number of SACCH messages as received from BSC for respective calls, the BTS sends CONN_FAIL message(s) with cause 1 = radio link failure to the BSC. BSC sends CHANNEL RELEASE (RR message) to BTS.

Timer T200 expires N200+1 times at layer 2 on the BTS.

BTS sends ERROR IND to BSC wit cause “timer T200 expired (N200 + 1) times”. BSC sends RF CHANNEL REL to BTS. Call is released.

Case Ref. Configuration Channel configuration 1. 4+4+4 MBCCHC+ TCHF



13 Dynamic A-bis Allocation

13.1 Downlink Resource Allocation Loading

Purpose:

The purpose of these test cases is to check that EGPRS DL resource allocation functions correctly when EDAP resources are lacking.

Input

Expected Output

Use any EDGE or mixed configuration. Use site with only 2 PCM timeslots allocated to EDAP Any transmission unit may be used. LA is set as specified (ZEQV:BTS=##:ELA=#;) Ensure there are at least 6 radio timeslots available for (E) GPRS. Set initial coding scheme to MCS-9: (ZEQV:BTS=##:MCA=9,MCU=9;)

Setup EGPRS data transfer in downlink direction (on 2 radio timeslots). Monitor A-bis Continue to setup additional EGPRS data transfers until there are 3 in total

Data transfer begins. A-bis shows MCS-9 in use. Transfer maintains an end-user data rate of at least 48Kbps per timeslot. All data transfers are setup. Lower MCS's are used(when LA is ON) instead of the specified MCS-9 due to the lack of EDAP TS's. Therefore data rates are reduced. When LA is OFF data is transferred on MCS9 on basis of scheduling.

Terminate all calls All the calls are successfully terminated

Dynamic A-bis Allocation

DN0694168 Issue 1-0


115 (252)

Case Ref.

LA Mode Hopping GP Timeslot Location

1. ON NAH-hopping BCCH TRX

2 OFF RF-hopping Non-BCCH TRX

3. OFF RAH-hopping Non-BCCH TRX

13.2 Uplink Resource Allocation Loading Purpose:

The purpose of these test cases is to check that EGPRS UL resource allocation functions correctly when EDAP resources are lacking.

Input Expected Output Use any configuration. Use site with only 1 TS allocated to EDAP. MS priority is set to be the same for all MS’s used. Any transmission unit may be used. LA is set as specified. (ZEQV:BTS=##:ELA=#;) Ensure there are at least 5 radio timeslots available for (E) GPRS. Set initial coding scheme to MCS-9: (ZEQV:BTS=##:MCA=9,MCU=9;)

Setup EGPRS data transfer using TCP/IP in uplink direction (one timeslot). Monitor A-bis. Continue to setup additional EGPRS data transfers until there are 5 in total. Terminate all calls

Data transfer begins. A-bis shows MCS-9 in use. Transfer maintains an end-user data rate of at least 48Kbps. All data transfers are setup. MCS-9 is predominantly used for all transfers. The data rates are reduced to due to uplink scheduling. Each transfer achieves at least 9Kbps user rate.

Case Ref. LA Mode Hopping GP Timeslot Location

1. ON Non-hopping Non-BCCH TRX

2. OFF BB-hopping BCCH TRX

3. OFF RAH-hopping Non-BCCH TRX



13.3 Maximum Dynamic Pool Size Purpose:

The purpose of these test cases is to check that maximum sized EDAP functions correctly.

Input Expected Output Use a 3 TRX omni.

Configure Dynamic A-bis for this test case. No error messages are seen at the BSC or at the BTS Manager when configuring the EDAP.

Use the MML command ZEQV to set the following: CDED=10,CDEF=100,CMAX=100 and enable EGPRS. Set GPRS coding scheme as CS2 and EGPRS coding scheme as MCS-9. Set Link Adaptation = on.

Begin TCP/IP data transfers in the direction shown in the table. Begin the number of EGPRS and GPRS transfers shown in the table so that the data transfers occur at the same time.

All data transfers continue successfully. EGPRS TBFs use MCS9; GPRS TBFs use CS2, nearly all of the time. Lower coding schemes may be seen, but only occasionally.

Monitor the A-bis for PCU MASTER DATA FRAMES and PCU SLAVE DATA FRAMES. Set Link Adaptation = off. Set initial coding scheme = MCS-9 Use enough EGPRS transfers in the direction shown to use all the EDAP subTS simultaneously. Monitor the A-bis.

The Master Data Frame for each TBF points to the correct Slave Frames. All SubTS in the EDAP are allocated at some point during the transfer of data (although not necessarily simultaneously). 4 SubTS are allocated to each MCS9. 1 SubTS is allocated to each CS2. All transfers proceed successfully. At some point in the transfer all the subTS are used simultaneously.

Case Ref. Direction GPRS transfers EGPRS transfers 1. Uplink (1 RTSL) 4 11

2. 2 +1 RTSLs(DL+UL) 0 5 in DL 2 in UL

3. Uplink (1 RTSL) 0 12

Enhanced Data Rates for Global Evolution, EDGE

DN0694168 Issue 1-0


117 (252)

14 Enhanced Data Rates for Global Evolution, EDGE

Note 45. The data throughput rates expected in this test specification is based upon simulations. Customers must not consider these figures to be a commitment to actual performance in a live network. If IR port is used for connecting phone to PC, it will be bottleneck for throughput, so cable connection (Phone-PC) is recommended for better data throughput.

Note 46. EGPRS cannot be used without Dynamic A-bis being configured.

The protocol layer between the MS and the PCU is the RLC/MAC layer. There are two modes for the RLC protocol:

Acknowledged RLC Mode

Unacknowledged RLC Mode

In Acknowledged RLC Mode, the receiver acknowledges the data sent. If data is not correctly received the data is retransmitted. In this mode Incremental Redundancy is automatically enabled.

In Unacknowledged RLC Mode the data is not acknowledged. Incremental Redundancy does not take place. The system relies upon error correction using the redundancy incorporated in the coding scheme. Any data blocks that are not successfully error corrected remain corrupt.

Note 47. The Link Adaptation algorithm is also influenced by the amount of space left in the EDAP. If the space in the EDAP runs out, Link Adaptation will restrict the MCS used in the downlink accordingly. In the uplink the PCU scheduling function will prevent the MS from sending data for one block period, until space again becomes available in the EDAP. The data rate will not be as high as anticipated. For this reason, the EDAP must be of a sufficient size for the number of radio timeslots configured as EGPRS.

Note 48. To enable/disable Link Adaptation use the MML commands:

ZEQV:BTS=##:ELA=1; Link Adaptation = on

ZEQV:BTS=##:ELA=0; Link Adaptation = off



To set the initial MCS use the MML command: ZEQV:BTS=##:MCA=#,MCU=#;

Where:

MCA = initial coding scheme in acknowledged RLC mode.

MCU = initial coding scheme in unacknowledged RLC mode.

Note 49. The behaviour of the Link Adaptation algorithm, and hence the resulting MCS used and data rate achieved, can be manipulated by an offset applied to the Bit Error Probability (BEP) measurements sent to the PCU. The offsets are applied using the parameters MBP (for 8PSK) and MBG (for GMSK). In order to see the expected data rates it is important that these offsets are set to zero.

This is done using the MML command: ZEQV: BTS=#: MBP=0, MBG=0;

14.1 EGPRS MCS 1-9 & Incremental Redundancy

Purpose:

The purpose of these test cases is to check that all EGPRS coding schemes are supported; Incremental Redundancy is supported in uplink & downlink, and on all EGPRS coding schemes. Also verify that 8PSK modulation has no adverse effect upon the interference indications.


Note 50. Timeslot 7 must always be left unlocked for synchronisation purposes. (E) GPRS transfers are loaded from timeslot 7 forward. In order to test other timeslots it is necessary to first occupy timeslot 7 with another transfer, then begin the transfer under test. Lock up all timeslots except timeslot 7 and the timeslot under test. To test timeslot 6 in the downlink, it is acceptable to have a downlink transfer on two timeslots, one of which is timeslot 6.

Note 51. When more than 1 Multislots EGPRS class 2 mobiles are used and if there are only contiguous GP TSs available, then MS shall get 2+1 TS for data transfer and UL TS will be shared by the phones. This may result to a lower rate of data transfer in UL direction


DN0694168 Issue 1-0


119 (252)

Input Expected Output Use any configuration. Dynamic A-bis is enabled.

Set BTS to use specified MCS (Disable link adaptation: ZEQV: BTS=##: ELA=0;

Set initial coding scheme: ZEQV: BTS=##: MCA=#, MCU=#;)

Lock up timeslots to force transfer on timeslot Under test as shown in the table. Establish extra transfer on timeslot 7 if necessary.

Setup EGPRS data transfer of file (size as mentioned in the table below) in specified direction using TCP/IP.

File transfer begins.

Monitor A-bis for PCU frames. PCU MASTER DATA FRAME shows data is sent using correct MCS. No retransmissions are seen.

Change C/I gradually to value as specified in test case. Monitor A-bis for PCU fames Data transfer is repeated 3/4 times and average data rate is calculated

Retransmissions are observed on MCS 4 to 9. RF RESOURCE INDICATION messages show expected level of interference (as specified by the boundary limits ZEQK) Data rate is equal to or better than expected.

Case Ref.

MCS UL/DL File Size

TS Data Rate @ C/I=30dB

Data Rate @ C/I

1. 1 UL 1MB 0 8.5 Kbps 8.5 Kbps 5 dB

2. 2 DL 500 Kb 1 10.7 Kbps 10.7 Kbps

5 dB

3. 3 UL 500 Kb 2 14.3 Kbps 14.2 Kbps

5 dB

4. 41 DL 500 Kb 3 16.6 Kbps 9.1 Kbps 5 dB

5 44 DL 500 Kb 3 16.6 Kbps 9.1 Kbps 5 dB

6 5 UL 500 Kb 4 21.7 Kbps 10.2 Kbps

5 dB

7. 62 DL 1MB 5 27.6 Kbps 11.0 Kbps

5 dB



8 75 UL+DL 500 Kb 3 43.4 Kbps 23.0 Kbps

10 dB

9 8 DL 1MB 1 50.3 Kbps 26.0 Kbps

10 dB

10 93 DL 1MB 3 54.7 Kbps 28.1 Kbps

10 dB

1…Do with BSCS12 PCU1 2.. Do with BSCS12 PCU2 3 Use common BCCH 2+2 configuration. Data Transfer is done both in BCCH and non BCCH BTS of common BCCH segment. 4 Execute the case with BSC SW S12 ED3.1 release 5 channel configuration: MBCCH+SDCCH+TCHF

14.2 Link Adaptation in Unack Mode (Changing Air Interface Conditions)

Purpose:

When in Unacknowledged RLC Mode, to check that Link Adaptation occurs dynamically as prevailing radio conditions change.

Test Tools Required: Signal Generator, Spectrum Analyser Note 52. In Unacknowledged RLC Mode Link Adaptation chooses the highest MCS that keeps the raw block error rate below the limit set by the operator using the BLU parameter. Because there are no retransmissions the user rate for the MCS chosen should remain constant and close to the expected user rate. The data at the receiving end can be expected to be corrupted, but no more than the upper limit set by the operator. This limit is expressed as the maximum number of block errors per 1000 allowed. Setting BLU to its lowest value of 10 will cause Link Adaptation to select a more robust MCS sooner when radio conditions deteriorate.

Table 1.

Coding Scheme

Number of Slave Frames

MCS 1 0


DN0694168 Issue 1-0


121 (252)

MCS 2 1

MCS 3 1

MCS 4 1

MCS 5 1

MCS 6 2

MCS 7 3

MCS 8 4

MCS 9 4

Input Expected Output Choose an MS so that RLC Mode = Unacknowledged RLC Mode.

Use a 2 TRX sector. TRX 2, TS0 = BCCH

Use the MML command ZERM: BTS=##, TRX=##: GTRX=Y or N; To enable EGPRS on the BCCH or non-BCCH TRX as indicated in the table below. Use CDED, CDEF and CMAX to enable 2 radio timeslots as EGPRS.

Set Link Adaptation = on. Use the MML command ZEQV: BTS=##: BLU=10; To set the max. Limit for block error rate to 10 per 1000. Check that no offsets are applied to the BEP values. Set up equipment to adjust Carrier / Interference (C/I) conditions in the air interface in the direction shown in the table. Initially set C/I > 30dB. Transfer a 500KB file using UDP/IP protocol in the direction shown in the table below. Use one timeslot for uplink transfer. Use two timeslots for downlink transfer.



On Abis PCU frames are monitored. Slowly change the C/I from 30dB to 0dB and back to 30dB. Carry out 2 times. Rate of change = 1 dB/sec approx.

The coding scheme used steps down through the coding schemes from the least robust (MCS9) to the most robust (MCS1) and back again to match the changing air interface conditions. MCS 4 may be skipped as Link Adaptation switches from 8PSK to GMSK and vice versa. The data rate changes to reflect the changing MCS.

Stop recording. Check the A-bis trace for the MCS used, and the allocation of PCU Slave Data Frames.

Dynamic A-bis allocates PCU SLAVE DATA FRAMES correctly as the MCS changes.

Case Ref.

Type of TRX Direction

1. BCCH1 Uplink

2. Non – BCCH Downlink 1…Do the test case with BSC S13 PCU1

14.3 Link Adaptation in Ack Mode (Changing Air Interface Conditions)

Purpose:

To check that retransmissions are made using MCS within the same family as the initial transmission. To check that retransmissions in a different MCS can be successfully combined (Incremental Redundancy). When in Acknowledged RLC Mode, to check that Link Adaptation occurs dynamically as the prevailing air interface conditions change. Also check that Dynamic A-bis can adjust dynamically in-step with the changes in MCS.

Test Tools Required: Signal Generator, Spectrum Analyser Note 53. In order to track retransmissions of the same RLC data block it is necessary to identify the block using the Temporary Flow Identifier (TFI) and the Block Sequence Number (BSN). This information is contained within the header of the RLC radio block. On the A-bis this is part of the PCU data block within the PCU MASTER DATA FRAME.


DN0694168 Issue 1-0


123 (252)

Table 2.

Initial transmission,

prior to transition

MCS transition Subsequent transmission, after transition

Air Interface conditions deteriorating MCS 9 MCS 9 → 8 MCS 6

MCS 8 MCS 8 → 7 MCS 6 padded

MCS 7 MCS 7 → 6 MCS 5






Air Interface conditions improving MCS 1 MCS 1 → 2 MCS 1








Input Expected Output Use a 2 TRX sector with two dynamic A-bis connections. TRX 2, TS0 = BCCH

Use the MML command ZERM:BTS=##, TRX=##:GTRX=Y or N; To enable EGPRS on the BCCH or non-BCCH TRX as indicated in the table below. Use CDED, CDEF and CMAX to enable 2 radio timeslots as EGPRS.



Set Link Adaptation = on. Use the MML command ZEQV:BTS=##:BLA=100; To set the maximum limit for block error rate to 100%. Check that no offsets are applied to the BEP values.

Set up equipment to adjust Carrier / Interference (C/I) conditions in the air interface in the direction shown in the table. Initially set C/I > 30dB.

Transfer a 500KB file using FTP in the direction shown in the table below. Use one timeslot for uplink transfer on TRX using A-bis. Use two timeslots for downlink transfer on TRX using the other A-bis.

Record an A-bis trace for PCU frames Slowly change the C/I from 30dB to 0dB and back to 30dB. Carry out 2 times. Rate of change = 1 dB/sec approx. Stop recording.

The coding scheme used for initial transmissions steps down through the coding schemes from the least robust (MCS9) to the most robust (MCS1) and back again to match the changing air interface conditions. MCS 4 may be skipped as Link Adaptation switches from 8PSK to GMSK and vice versa.

In the A-bis trace track the MCS used for the initial transmissions of RLC data blocks. Track the retransmission of RLC data blocks either side of each MCS transition.

Retransmissions of the same RLC data block occur in the coding scheme shown in Table 2

Check the A-bis trace for the allocation of PCU Slave Data Frames.

Dynamic A-bis allocates PCU SLAVE DATA FRAMES correctly as the MCS changes see Table 1

Compare the received file with the sent file. The file received is identical to the file sent.

Case Ref. Type of TRX Direction 2-way RX Diversity

1. BCCH Uplink On

2 BCCH Uplink+Downlink On

3 BCCH Uplink Off

4 Non–BCCH Downlink On

5 Non–BCCH Downlink+Uplink On


DN0694168 Issue 1-0


125 (252)

14.4 GPRS Data transfer when EGPRS is enabled

Purpose:

The purpose of these test cases is to check that data can be transferred using coding scheme 1 and 2 when EGPRS is enabled that data can be transferred reliably in both uplink & downlink on PDTCH.

Input Expected Output Use any multi TRX EDGE sector. EGPRS must be enabled. Using a non-EDGE GPRS MS, Perform Attach and then activate a PDP Context.

Transfer a file of specified size and in the direction shown in the table below.

The data is transferred with BER of 0%. The expected data rates for the coding scheme are achieved. (CS-1 approx. 9kbit/s per timeslot used and CS-2 is approx. 13.4kbit/s per timeslot).

Monitor the A-bis for PCU frames, user data rate is also monitored At least 3 times transfer should be made to get a reliable figure on throughput

In the PCU data frame the values for Coding scheme & RX level are verified to be reliable.

Case Ref.

BCCH Configuration/ TCH configuration / CS Call type

Coding Scheme

No of Time Slots

Data transfer direction

1. MBCCH/TCHF / FR

CS-1 1 TS on non-BCCH TRX

Downlink 1Mb file

2 MBCCHC/TCHD / FR

CS-2 1 TS on BCCH TRX

Downlink 1Mb file + uplink 100kb file

3 (MBCCH + SDCCH + TCHF

CS-2 1 TS on BCCH TRX


4. BCCH/TCHF / FR CS-2 2 TS on non-BCCH TRX




14.5 GPRS & EGPRS TBFs on One Timeslot

Purpose:

The purpose of these test cases is to check that both GPRS and EGPRS TBFs can exist on the same radio timeslot.

Note 54. The PCU sends a PACKET UPLINK (or DOWNLINK) ASSIGNMENT for each MS. These messages assign a different TFI to each MS. The uplink assignment also assigns a USF to each MS. The USF in the header of the downlink RLC Data Blocks indicate which TBF may transmit in the uplink

The PCU restricts the MCS used for a downlink EGPRS TBF to a GMSK coding scheme when an uplink GPRS TBF shares the same radio timeslot. It does this so that the uplink GPRS MS can read the USF information in the downlink TBF’s header.

Note 55. The priority of the subscriber affects the number of blocks scheduled to the MS when it shares a timeslot and therefore the throughput it achieves. It is handled differently in M10 and M11.

M10: The priority is determined by the precedence class in the subscriber parameters set at the HLR .It can be changed by establishing an MML session with the HLR and using the ZMNM command.

M11: The priority is determined by the Traffic Handling Priority in the QoS Profile attached to the subscriber parameters in the HLR.

The priority agreed by the Network for an MS can be seen in the ACTIVATE PDP CONTEXT ACCEPT message on the A-bis, and the DL-UNIDATA frames on The Gb interface.

Input Expected Output Chose three MS so that the RLC Mode = Acknowledged. The MS must have the same priority set at the HLR. MS1 = EGPRS MS2 = EGPRS MS3 = GPRS.

Use BTS configuration as defined in test case.


DN0694168 Issue 1-0


127 (252)

Enable EGPRS on only one TRX. Lock all traffic timeslot so that only one (E) GPRS timeslot remains available for use.

Set Link Adaptation = on for both GPRS and EGPRS. (To do this for GPRS: Use the MML command ZEQV to set the following parameters to the values shown: DLA = 5%, ULA = 5% DLB = 10%, ULB = 10%, DLBH = 10%, ULBH = 10% COD = 0, CODH = 0 (GPRS link adaptation used).)

(E) GPRS attach each MS in turn to the sector. Activate a PDP Context for each MS in turn.

All the MS attach successfully. All MS activate a PDP Context successfully.

Monitor the A-bis for PCU frames and record a trace

Begin UDP data transfer of 2MB files in the direction shown for each MS: MS1 = uplink MS2 = downlink Begin UDP data transfer of a 2MB file with MS3 = uplink.

Both MS begin transfer successfully using predominantly MCS-9. The TBFs for all three MS are successfully shared on the one timeslot. The coding scheme used for the downlink transfer (MS2) will alternate between GMSK and 8PSK.

Case Ref. Configuration Hopping mode 1. 2 sectors each with 2 TRX (BB2F with

TSxA+TSxB) No-Hopping

2 Metro Site EDGE configuration RF-Hopping

14.6 GPRS Link Adaptation Purpose:

To check that GPRS link adaptation selects the coding scheme (CS1, CS2) appropriate for the air interface conditions. To check that Dynamic A-bis allocates a slave subTS when CS2 is selected by GPRS link adaptation.




Note 56. In the uplink direction, the coding scheme used can be found in the uplink MCS indicator in the PCU Master Data Frame. In the downlink direction, the coding scheme to be used can be found in the downlink idle/header type.

Input Expected Output Use the MML command ZEQV to set the following parameters to the values shown: DLA = 5%, ULA = 5% DLB = 10%, ULB = 10%, DLBH = 10%, ULBH = 10% COD = 0, CODH = 0 (GPRS link adaptation used).

Use any multi TRX EDGE sector. EGPRS must be enabled. Set the hopping mode as shown in the table below.

Establish a Carrier / Interference (C/I) ratio > 30dB in the air interface, in the direction shown in the table.

Use a non-EDGE GPRS MS, and RLC Mode = Acknowledged. Attach the MS to the sector and activate a PDP Context.

Transfer a 500K file in the direction shown in the table below. Monitor the A-bis for the coding scheme used.

The PCU MASTER DATA FRAME indicates that CS2 is used. Dynamic A-bis allocates one slave frame.

Deteriorate the radio conditions gradually to C/I = 0dB.

The PCU MASTER DATA FRAME indicates that CS1 is used. No slave frames are allocated.

Improve the radio conditions gradually to C/I > 30dB.

The PCU MASTER DATA FRAME indicates that CS2 is used again. Dynamic A-bis allocates one slave frame.

Repeat the C/I cycle a further 2 times.. The coding scheme switches as expected.

Case Ref. Hopping Mode Direction 1 Non – hopping Downlink

2 BB-hopping Downlink

3 RAH hopping1 Downlink


DN0694168 Issue 1-0


129 (252)

4 Non – hopping2 Uplink 1 Test cases to be done with GPRS enabled only, i.e. EGPRS should

be disabled. Slave channels are not used with EGENA=NTest cases

2 to be done with GPRS enabled only, i.e. EGPRS should be disabled. Slave channels are not used with EGENA=N, BSC S13 PCU2

14.7 EGPRS/GPRS Territory Upgrade/Downgrade

Purpose:

To check that EGPRS/GPRS territory upgrade/downgrade works properly and that one RTSL can support more than one TBF.

Note 57. When more than 1 Multislots EGPRS class 2 mobiles are used and if there are only contiguous GP TSs available, then MS shall get 2+1 TS for data transfer and UL TS will be shared by the phones. This may result to a lower rate of data transfer in UL direction

Note 58. CSU and CSD parameters at the BSC (command: ZEEM) may need changing in order to cause GPRS upgrade/downgrade.

Input Expected Output Configuration is used as defined in test case. Lock all but one TRX.Through ZEQV command set the values of CDED and CDEF such that one dedicated TS and one default TS is configured.

Set up CS speech calls until only one timeslot remains idle

Set up data transfers as specified in Test case

Both data transfers begin (two TBF's on one timeslot).

Terminate CS speech calls one by one, until EGPRS territory upgrade is performed.

Existing data calls no longer share one RTSL

Set up CS speech calls one by one, until EGPRS territory downgrade is performed.

Data calls return to sharing one timeslot.

Terminate all calls. Calls are terminated successfully.



Case Ref.

Data Transfer Type

Transfer 1 Direction


Configuration used

1. EGPRS Uplink Uplink 2+2 BB-hopping

2. EGPRS Downlink Uplink 4 Omni, RAH hopping

3 EGPRS Downlink Downlink Standard Ecell configuration,Data transfer in N-Area

4 GPRS Uplink Downlink 4 Omni, No-hopping

14.8 Multiple TBFs on One Timeslot at Different Distances

Purpose:

The purpose of these cases is to check that the MS at different distances from the base station can share the same radio timeslot.


Input Expected Output Choose two EGPRS MS so that the RLC Mode = Acknowledged. The MS must have the same Precedence Class set at the HLR.

Use base station configuration as defined in test case.

Enable EGPRS on only one TRX. Lock all traffic timeslot so that only one (E) GPRS timeslot remains available for use.

Set Link Adaptation = on.

Use a fading simulator to simulate delay and attenuation but not fading, for one of the MS. Simulate the distance shown in the table.

EGPRS attach each MS in turn to the sector. Activate a PDP Context for each MS in turn.

All the MS attach successfully. All MS activate a PDP Context successfully.


DN0694168 Issue 1-0


131 (252)

Begin FTP data transfer of 300KB files in the direction shown in the table for both MS. Monitor the A-bis for PCU frames and record a trace.

The PCU sends a PACKET UPLINK (or DOWNLINK) ASSIGNMENT for each MS. These messages assign a different TFI to each MS. Each MS successfully establishes a TBF on the same radio timeslot.

Monitor the end-user data rate for each TBF.

The end-user rate is shared equally between each TBF and is no less than 24 Kb/s for each TBF. MCS 9 is used for both TBFs.

Compare the files received with the files sent. The files are received error free.

Case Ref.

Direction Distance Configuration Used Hopping mode

1. Uplink 5 Km 2 sectors each with 2 TRX (BB2F with TSxA+TSxB)

None

2 Simultaneous in Uplink and Downlink

5 Km 2 sectors each with 2 TRX (BB2F with TSxA+TSxB)

None

3 Downlink 35 Km Multi TRX RAH

14.9 Cell Reselection & Timing Advance with EGPRS

Purpose:

The purpose of these test cases is to check that cell reselection functions correctly with EGPRS data transfer and timing advance. Also check that combined IMSI/GPRS attach can be performed with timing advance.


Input Expected Output Use any configuration for BTS1 & BTS2 .

Link adaptation is enabled (ZEQV: BTS=##: ELA=1;)

Hopping mode is set as specified. Timing advance is applied to BTS1 only.



BA list is created containing BTS1 & BTS2 BCCH frequencies. RA and LA of BTSs should be as specified in test case.

Turn on EGPRS mobile and attach to the specified BTS

Mobile performs combined IMSI/GPRS attach

Setup EGPRS data transfer in specified direction. MCS used uses at least one slave frame from EDAP.

The transfer can be established on the source cell.

Use an adjustable attenuator to cause cell reselection during the data transfer.

Data transfer continues after cell reselection onto target cell.

The A-bis TRX links and PCU MASTER DATA frames are monitored on source and target cells. A-bis traces are recorded.

In the Packet Channel Request message, access delay represents the actual TA value. Post analysis of Abis trace shows MCS used slave frame in both source and target cells

The reselection between cells is made at least 10 times for each test case.

Case Ref.

Direction Hopping Mode (BTS1 / BTS2)

RA/LA Source Cell

Timing Advance

1 Uplink RAH-hopping / Non-Hopping

RA & LA are same for both BTS

BTS1 0 Km

2 Downlink RF-hopping / NAH-hopping

RA is different for both BTS

BTS1 10 Km

3. Downlink RF-hopping / NAH-hopping1

RA is different for both BTS

BTS1 10 Km

4. Downlink BB-hopping / RF-hopping

LA is different for both BTS

BTS2 30 Km

5. Uplink RAH-hopping / Non-Hopping

RA & LA are same for both BTS

BTS2 10 Km

1 Use EDGE configuration of MetroSite

14.10 EGPRS Reliability at Various MS Speeds

Purpose:

To check that data transfer does not fail when the MS speed increases.


DN0694168 Issue 1-0


133 (252)


Note 59. 8-PSK modulations are more susceptible to MS speed than GMSK. Link Adaptation and Incremental Redundancy should cope with this without data transfer failing completely.

Input Expected Output Use configuration as defined in test case.

Choose an EGPRS MS so that RLC Mode = Acknowledged RLC Mode.

Set Link Adaptation = on Use the MML command ZEQV: BTS=##: BLA=50; To set the maximum limit for block error rate to 50%.

Check that no offsets are applied to the BEP values.

Transfer a file using the UDP/IP protocol in the direction shown below.

Slowly increase the MS speed from stationary to 200Km/h and back to stationary. Perform 3 times. Monitor the A-bis for BEP values and MCS used.

As MS speed increases the reported BEP increases. Link Adaptation responds accordingly and Incremental Redundancy recovers blocks successfully.

Case Ref. Direction Configuration used Hopping Mode

File Size

1 Uplink 2 sectors each with 2 TRX (BB2F with TSxA+TSxB)

None 1 MB

2 Uplink+Downlink 2 sectors each with 2 TRX (BB2F with TSxA+TSxB)

None 1 MB

3 Downlink Multi TRX RAH 1 MB

4 Downlink Multi TRX,Speed more than 60 kmph,Distance-35 km

RAH 6 MB



14.11 EGPRS Reliability at Various Distances

Purpose:

To check that data transfer does not fail when the MS distance varies over the full range (0 to 35Km).


Input Expected Output Use base station configuration as defined in test case

Choose an EGPRS MS so that RLC Mode = Acknowledged RLC Mode.

Set Link Adaptation = On.

Use the MML command ZEQV: BTS=##: BLA=90; To set the maximum limit for block error rate to 90% (this is the default value).

Check that no offsets are applied to the BEP values.

Monitor the A-bis interface for TRX signalling and PCU frames

Attach the MS to the sector. Attach is successful.

Promptly begin the transfer of a file using the FTP in the direction shown below. Initiate the transfer from the terminal equipment at the MS end. Use the number of timeslots shown in the table.

An EGPRS PACKET CHANNEL REQUEST is seen on the A-bis which reports the timing advance corresponding to the distance of the MS. Data transfer begins, and continues, successfully.

As the transfer of one file completes, promptly begin the transfer of a new file. Repeat this process until the MS reaches a distance of 0Km (if MS is moving towards BTS) and the final file completes its transfer. This should take half and hour in total.

Each new file transfer begins successfully. The correct timing advance is shown in the RANDOM ACCESS FRAME. The numbers of files shown in the table are required to fill the time that it takes for the MS to reach the base station.

Compare the files received with the files sent. Repeat the data transfer at least 4 times.

The received files are identical to the sent files.

Case Ref.

Direction No. Timeslots

Start Dist

Travel Configuration Used

File Size


DN0694168 Issue 1-0


135 (252)

1 Uplink 1 35Km Towards BTS with speed 120Km/hr

2 sectors each with 2 TRX (BB2F with TSxA+TSxB)

5 MB

2 Uplink 1 35Km Towards BTS with speed 70Km/hr

2 sectors each with 2 TRX (BB2F with TSxA+TSxB)

10 MB

14.12 GPRS transfer when EGENA is OFF Purpose:

To check that GPRS attach is possible after EGENA is disabled from the BSC

Input Expected Output Create the site as per given in the configuration with GPRS and EGPRS enabled in the BTS.

Site is in supervisory state.

Disable EGENA and DAP using following MML commands: ZEQS:BTS=<BTS ID>:L; ZEQV:BTS=<BTS ID>:EGENA=N; ZERS:BTS=<BTS ID>,TRX=<TRX ID>:L; ZERM:BTS=<BTS ID>,TRX=1:DAP=N; ZERS:BTS=<BTS ID>,TRX=<TRX ID>:U; ZEQS:BTS=<BTS ID>:U;

Sector resets and reaches supervisory state.

Switch ON test mobile Mobile latches on to the BCCH frequency and GPRS attach is performed successfully.

Check the alarms on the BSC No unexpected alarms appear. A Packet data transfer is started. Packet data transfer is successful. Monitor the Abis and also the user data rate. In the PCU data frame the values for Coding

scheme & RX level are verified to be reliable The expected data rates for the coding scheme are achieved. (CS-1 approx. 9kbit/s per timeslot used and CS-2 is approx. 13.4kbit/s per timeslot).

Case Ref. Configuration 1 1 OMNI EDGE Metro Site

2 1 OMNI EDGES12 Metro Site



14.13 EDAP mismatch between BSC and the BTS Manager

Purpose: To check that EDAP mismatch between BSC and BTS Manager does not affect the GPRS functionality.

Note 60. While defining the EDAP timeslots, the starting timeslots must be kept the same at both BSC & the BTS Manager.

Input Expected Output Create the site in the BSC as given in the configuration.

Site is created .

Enable GPRS & EGPRS using the MML command ZEQV.

GPRs/EGPRS are enabled successfully.

Define the number of EDAP TSs in the BSC as given .

EDAP timeslots are defined.

Commission the site wherein define the number of EDAP TSs in the Traffic Manager as given .

Site is commissioned successfully and is in supervisory state. No unexpected alarm is observed on the BTS Manager and the BSC.

Start an EGPRS Packet data transfer. EGPRS Packet data transfer is successful. Monitor the Abis and also the user data rate. In the PCU data frame the values for Coding

scheme & RX level are verified to be reliable. The expected data rates for the coding scheme are achieved.

Number of EDAP TS Case Ref. Configuration BSC Traffic

Manager 1 1 OMNI EDGE Metro Site 3 4


DN0694168 Issue 1-0


137 (252)

14.14 RF Performance & Power Control Purpose:

To check that EGPRS power level is equal to BCCH and speech power level varies on signal strength.

Test Tools Required: Spectrum Analyser

Input Expected Output Use a Base Station with at least one 2 TRX sector with BCCH on TRX 1. Dynamic A-bis is enabled. Set BTS to use specified MCS (Disable link adaptation: ZEQV: BTS=##: ELA=0; Set initial coding scheme: ZEQV: BTS=##: MCA=#, MCU=#;) Setup EGRPS data transfer on TRX 1 of Sector 1 using the time slot as specified in test case. Setup CS speech call on TRX 2 of Sector 1 using time slot as specified in test case. Setup another speech call on TRX1 on any time slot. Using spectrum analyser monitor power level of EGPRS & CS speech call timeslots. Attenuate UL & DL of CS speech call. Monitor A-bis. Terminate both calls

Data begins transfer. CS call is successful & unaffected by EGPRS EGPRS power level is equal to BCCH (i.e. PMAX parameter). Speech call power level is dependent on signal strength. EGPRS power level remains equal to BCCH. Speech call power level increases with attenuation. Power control message is seen on A-bis. Calls terminated successfully.

Case Ref. MCS CS speech Call Time Slot

EGPRS Data Time Slot Download Direction

1. 9 7 7 Downlink



2. 2 5 51 Uplink 1 One additional Data transfer must be done on TS 7


Use any configuration. Dynamic A-bis is enabled. Non-BCCH TRX is used for test Set BTS to use MCS-9 (Disable link adaptation: ZEQV:BTS=##:ELA=0; Set initial coding scheme: ZEQV:BTS=##:MCA=#,MCU=#;) Set up CS speech calls on timeslots 6 & 0 Set up EGRPS data transfer in the specified direction on timeslot 7 Using spectrum analyser monitor power level of EGPRS & CS speech call timeslots Attenuate UL & DL of CS speech call. Monitor A-bis. Terminate calls

CS calls are setup Data transfer begins. CS calls are unaffected by EGPRS EGPRS power level is equal to BCCH (i.e. PMAX parameter). Speech call power level is dependent on signal strength. EGPRS power level remains equal to BCCH. Speech call power level increases with attenuation. Power control message is seen on A-bis.


DN0694168 Issue 1-0


139 (252)

14.15 Break (Air Interface and A-bis) in EGPRS

Purpose:

To check EGPRS data transmission is able to recover after a short break in the air interface / A-bis interface.


Input Expected Output Use any configuration.

Disable link adaptation (ZEQV: BTS=##: ELA=0;)

Set C/I = 15dB Setup EGPRS data transfer using MCS-9 in the downlink direction using TCP/IP. Monitor A-bis interface

Data transfer begins

Break air interface (UL/DL) for a period of 7 sec (based on counter N3101 and timer T3169 values). Terminate data transfer Repeat 5 times

TBF is released When air interface is re-established the TCP protocol will request data retransmission, a new TBF is established (P-CHANNEL REQUIRED message is seen on the A-bis) and data transfer continues

Case Ref.

BTS Configuration

1. Any Configuration (EDGE TRX Only)


Disable link adaptation (ZEQV: BTS=##: ELA=0;)



Set C/I = 15dB Setup EGPRS data transfer using MCS-9 in the downlink direction using TCP/IP. Monitor A-bis interface


Break air interface (UL/DL) for a period of 55 sec (based on counter N3101 and timer T3169 values). Repeat 5 times

TBF is released In case of UDP data transfer new TBF will not be established

Case Ref.

BTS Configuration

2. Any Configuration (EDGE TRX Only)

A-bis break


Dynamic A-bis is enabled Setup EGPRS data transfer using TCP/IP and using MCS-9 in direction specified in test case.


For a period of 10 seconds the whole A-bis is disrupted with random short (<0.5 s) breaks The link is then left connected until the link recovers. Terminate data transfer Repeat test 5 times.

After the link recovers, PCU frame resynchronises. Data continues to transfer. Very occasionally the A-bis may be broken while the BSC is polling the BTS. This will cause the LAPD to drop and the air interface to be disabled. It may take over 30 sec to recover the site once the A-bis is reconnected. During this time the TCP/IP connection will probably be dropped. It may also be necessary to re-activate the PDP Context.

Case Ref.

BTS Configuration Direction

3. Any Uplink

4. Multi TRX Downlink

EGPRS Channel Requirement on CCCH

DN0694168 Issue 1-0


141 (252)

15 EGPRS Channel Requirement on CCCH

15.1 EPCR Capability Reporting Purpose:

The purpose of these cases is to check that the base station reports its ability to receive EGPRS Packet Channel Requests (EPCR) correctly to the BSC. Also check that the BSC informs the cell’s EPCR capability correctly to the MS.

Note 61. When a base station resets it can report its EPCR capability in the BTS_OMU_STARTED message. The information element can be found as follows:

BTS_OMU_STARTED -> TRX HW Capability -> EPCR Capability

The EPCR is reported for each TRX present. From CX4.0 onwards, EDGE TRX should report as supporting EPCR on CCCH. GSM TRX should report as not supporting EPCR.

Note 62. The BSC informs the MS for the cell’s capability in the (PACKET) SYSTEM INFORMATION 13 message.

Input Expected Output Create and commission the site as per the mentioned configuration. Ensure that any EDGE TRX are attached to an EDAP, that GP timeslots are configured and that EGPRS is enabled.



Monitor the A-bis for BTS_OMU_STARTED messages. Monitor the TRX SIG timeslot of the BCCH TRX’s on the Abis for SYSTEM INFORMATION 13 messages. Monitor the air interface for the SI13 or Packet SI13 messages transmitted by the base station.

Reset the site.

The TRX’s in the sectors indicated in the table below report the expected EPCR Capability in the BTS_OMU_STARTED message. The BSC sends the expected instruction in the SI13 / PSI13 message to the BCCH TRX’s. The BCCH TRX’s transmit the expected instruction on the air interface to the MS.

Case Ref.

Config. Sector TRX Type

Channel Reported EPCR Capability

EPCR instruction to mobile

1 GSM BCCH CCCH + PCCCH Do not use EPCR

2 EDGE BCCH CCCH + PCCCH Use EPCR

1. 4+4+4

3 EDGE BCCH CCCH + PCCCH Use EPCR

1 EDGE BCCH CCCH + PCCCH Use EPCR 2. 2+2

2 GSM BCCH CCCH + PCCCH Do not use EPCR

15.2 PRACH Types on CCCH and PCCCH Purpose:

To check that EGPRS Packet Channel Request types initiated by EGPRS capable MS are received by the base station and passed on to the PCU correctly. Also check that this occurs correctly from MS at different distances and under different fading conditions.


EGPRS Channel Requirement on CCCH

DN0694168 Issue 1-0


143 (252)

Note 63. The EGPRS Packet Channel Request is passed up to the A-bis as a P-Channel required message containing an EGPRS PCR information element.

Note 64. The Access Burst Type parameter sent in the GPRS options in System Information 1 & 13 messages must be = 1 (11 bit access type). Currently, this is fixed at 1 in the BSC.

Input Expected Output Use a site of any configuration. Configure signalling as shown in test case. Configure at least one EGPRS timeslot in the sector. Enable EGPRS in the sector. Set 2 way diversity to ON using MML command: ZEQM: BTS=<bts num>: RDIV=Y; Bring the site into working order. Monitor the A-bis. Use an EGPRS MS with uplink capability shown in the table. Use an MS, which will use the RLC Mode shown in test case (See Note 46).

Use a fading simulator to apply the distance and fading profile shown in the table. When fading is used, allow the signal to pass to the RX port shown in the table. Block the other port using terminators.

Attach an EGPRS MS to the sector. Activate a PDP Context.

A P-CHANNEL REQUIRED message is seen on the A-bis containing an EGPRS PCR information element. The Uplink TRS Indicator corresponds to the type of MS used (TRS1=8PSK, TRS2=GMSK). The access burst type = Signalling or One Phase Access

Send one "ping" message to the IP server.

A P-CHANNEL REQUIRED message is seen on the A-bis containing an EGPRS PCR information element. The Uplink TRS Indicator corresponds to the type of MS used (TRS1=8PSK, TRS2=GMSK). The access burst type = Short Access Request or One Phase Access



Input Expected Output Transfer a 1Mb file in the uplink direction. During the transfer cause a cell reselection to take place. Look for the RACH on the new cell, as the transfer is re-established.

A P-CHANNEL REQUIRED message is seen on the A-bis containing an EGPRS PCR information element. The Uplink TRS Indicator corresponds to the type of MS used (TRS1=8PSK, TRS2=GMSK). The access burst type = One Phase Access

While the MS is still in Ready mode (i.e. before the Ready timer has expired), send a "ping" message from the ftp server to the IP address assigned to the MS.

A PACKET CONTROL ACKNOWLEDGEMENT message is seen on the A-bis in a PCU RANDOM ACCESS FRAME on the PDCH assigned to the downlink TBF.

Case Ref.

Timeslot configuratio

n

MS uplink

capability

RLC Mode

Distance (Km)

Fading Profile

RX port

1. Ts0 = MBCCH Ts1 = SDCCH

8PSK Ack 0 HT100 Main

2. Ts0 = MBCCHC 8PSK Ack 0 HT100 Main

Enhanced Measurement Reports (EMR)

DN0694168 Issue 1-0


145 (252)

16 Enhanced Measurement Reports (EMR)

Note 65. The FIFILE parameter EMR_SUPPORT_IN _BSC is enabled and activated at the BSC to allow Enhanced Measurement Reporting.

Note 66. The INVALID_BSIC_REPORTING parameter is set to 0 (cells that are not neighbours but have correct NCC are not reported) unless otherwise stated.

Note 67. The following setup is used for the EMR test cases unless otherwise stated.

• A 2+1+1 site is in use. Each BTS has the same NCC but a different BCC. The calls are made on BTS 1 (having 2 TRX) and the other sectors are the neighbours.

• BTS power levels are set as follows: This is to cause the MS to camp onto BTS 1. − BTS 1, PMAX = 16 − BTS 2, PMAX = 30 − BTS 3, PMAX = 30

• The test is performed either in a screened room, or a cabled environment, so that the MS can only see the three BTS.

• A MS that supports Enhanced Measurement Reporting is selected. The MS is switched on and it is verified In the Field Test software that BTS TEST = OFF, so that the MS can see the neighbouring cells. The MS is therefore not locked to the BTS.



Note 68. The SACCH FILLING contains the MEASUREMENT INFORMATION message. The following parameters are present:

• Report Type • Reporting Rate • Invalid BSIC Reporting • BSIC description • Real Time Difference description (RTD) • Report Priority description • Measurement Parameters description • 3G Neighbour Cell description • 3G Measurement Parameters description

The 3G related parameters in EMR message would be present only when 3G neighbours are defined and RTD parameter will be present only when LMU is configured to be used for Position Based Service (PBS).

Note 69. The MEASUREMENT INFORMATION message is sent to the TRX when it resets in the SACCH FILLING message on the BTSM layer. In the CHANNEL ACTIVATION message the TRX is told which System Information messages (including the Measurement Information message) must be transmitted on the SACCH.

Note 70. Enhanced Measurement Reports are not supported on the SDCCH (i.e. during call Setup). Once a call has been established on a TCH the mobile at first sends ordinary Measurement Reports. The base station is required to send higher priority System Information messages on the SACCH before it sends the Measurement Information message. Only after the MS receives the Measurement Information message on the SACCH can it begin to send Enhanced Measurement Reports.

16.1 EMR sending in response to Measurement Information Message

Purpose:

The purpose is to verify that the Enhanced Measurement Reports or Measurement Reports messages are being correctly sent when requested by the Measurement Information message.


DN0694168 Issue 1-0


147 (252)


Input Expected Output The configuration is setup as defined in Note 67. The hopping mode is only for BTS1.

The serving cell has IDLE and MEAS BA lists attached as defined in the test cases.

Reset the BTS. Monitor the Abis for SACCH FILLING messages within the SI BEGIN or SI END messages.

The SACCH FILLING contains the MEASUREMENT INFORMATION message. The Invalid BSIC Reporting is set to 0 and the Report type is shown as listed below. NO IDLE and MEAS BA Lists attached: The report type is set to 0 (This means The MS shall use the Enhanced Measurement Report message for reporting if at least one BSIC is allocated to each BA (list) frequency. Otherwise, the Measurement Report message shall be used.) IDLE and MEAS BA Lists attached: The report type is set to 1 (This means The MS shall use the Measurement Report message for reporting.)

Make a speech call to a PSTN number or an MS locked to a completely separate BTS. Monitor the TRXsig for BTS 1 on the Abis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages. End the call.

NO IDLE and MEAS BA Lists attached: Enhanced Measurement Reports (Layer 3) are sent up the Abis. IDLE and MEAS BA Lists attached: Measurement Reports (Layer 3) are sent up the Abis. Calls are terminated successfully.

Case Ref.

IDLE and MEAS BA Lists attached

Hopping

1. No RAH-hopping

Input Expected Output The hopping mode is only for BTS1. Make a speech call to a PSTN number or an MS locked to a completely separate BTS with call held for at least 5 minutes with the originating MS moving from the BTS starting with TA values of 0km and then coming back towards the BTS when TA value is 10km. The speed is 200 km/hr.

Enhanced Measurement Reports (Layer 3) are sent up the Abis. The speed and TA value is correctly displayed in EMR report.



Case Ref. IDLE and MEAS BA Lists attached

Hopping

2. No BB-hopping

16.1.1 (E)MR sending in response to Measurement Information Message

Purpose:

To check that the base station forwards the Measurement Information message correctly to the MS. The test does this by changing parameters at the BSC, which are included in the Measurement Information message and checking for the response from the MS.

To check that the base station correctly includes the (layer 3) Enhanced Measurement Report information element in the Measurement Results message.

Note 71. The purpose of Measured BA list which is used to switch EMRs on and off, is outlined in feature BSS11085, section 3.5.2 of BSS11/BSS11.5 FUD. This mentions the interaction with the use of Enhanced Measurement Reports. The REPORT TYPE information element in the Measurement Information message is affected depending upon whether IDLE BA is attached and MEAS BA is enabled or not.

Note 72. Two other information elements within the Measurement Information message are toggled during this test. These are INVALID_BSIC_REPORTING and SCALE_ORD.

INVALID_BSIC_REPORTING allows or prohibits the MS from reporting neighbouring cells which are not valid (i.e. have not been defined as adjacent, or included on the BA list), but have the same Network Colour Code (NCC) as the serving cell.

SCALE_ORD enables the MS to report RX levels between –37dBm and –47dBm. It does this by offsetting the reported RX level by 10dB (described as “scaled by 10dB). When the measurements are “scaled”, an RX level of

63 means –37dBm

0 means –100 dBm.

Note 73. MEASUREMENT INFORMATION message (with Report Type equal to 1) could be sent by the BSC if the ISHO feature is activated at the BSC even when the BA list is attached to the sector as an IDLE BA list and MEAS BA LIST is enabled.

Equipment and BTS Set-Up For Talk Family and MetroSite, one sector with at least 2 TRX in any base station configuration may be used. For MetroSite use a sector with the EDGE/non-EDGE capability specified in the test case.

For UltraSite use a 2TRX sector with the following combinations:


DN0694168 Issue 1-0


149 (252)

Config BB2 TRX 1 TRX 2

non – EDGE BB2A TSxA TSxA

EDGE BB2F TSxB TSxB

mixed BB2F TSxA TSxB

The sector being used for this test must have 2 neighbours, which are transmitting, so that the MS can report the RX level for each. Only one of the neighbours is defined as an adjacent cell to the sector being used for this test. The other neighbour available is not defined as an adjacent cell but has the same NCC value as the sector being used for the test. This neighbour needs to be defined with a different BCC to the sector being used for the test.

In order for the MS to see the neighbours it will not be possible to lock the MS to the serving cell using the field test software. For this reason it may be necessary to perform the test in a screened room, or using a cabled RF environment.

Use a mobile station which supports Enhanced Measurement Reports.

Input Expected Output Use a BSC running S11 or later. Create a BA list, which includes the neighbours of the sector plus 2 or 3 other frequencies. Use MML command: ZEBC:<id>,<band>:<f1>&<f2>&<fn>;

Lock the sector at the BSC.

Lock TCH timeslots to force calls onto the BCCH / non-BCCH TRX indicated in the test case table. Also set the hopping mode as indicated.

Attach the BA list to the sector as an IDLE BA list. Also enable MEAS BA LIST. Use MML command:ZEQB:BTS=<bts num>:MEAS=Y,IDLE=<id>, ACT=IDLE;

Whilst monitoring the A-bis for SACCH FILLING messages within the SI BEGIN or SI END messages, unlock the sector.

The BSC does not send any MEASUREMENT INFORMATION messages (thus indicating that the MS shall use Measurement Reports) [Note 73].

Make a speech call (of the type shown in the test case table below) to a PSTN number or an MS locked to a completely separate BTS. Monitor the TRXsig of the sector on the A-bis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages.

The BTSM layer MEAS. RES. Message contains the MEASUREMENT REPORT message. The message contains the RX measurements for the current cell and RX level measurements for the frequencies in the BA list.

End the call.

Lock the sector.



Detatch the IDLE BA and the MEAS BA lists using MML command: ZEQB:BTS=<bts num>:MEAS=N,IDLE=0, ACT=ADJ;

Set INVALID_BSIC_REPORTING to 0 (cells that are not adjacent but have correct NCC are not reported). Use the MML command: ZEHN:BTS=<bts num>::IBR=0;

Set SCALE_ORD to 0 (not scaled) using MML command: ZEQM:BTS=<bts num>:SCO=0;

Whilst monitoring the A-bis for SACCH FILLING messages within the SI BEGIN or SI END messages , unlock the sector.

The SACCH FILLING contains the MEASUREMENT INFORMATION message. The REPORT TYPE = 0, INVALID_BSIC_REPORTING = 0, SCALE_ORD = 00.

Make a speech call to a PSTN number or an MS locked to a completely separate BTS. Monitor the TRXsig of the sector on the A-bis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages.

The BTSM layer MEAS. RES. message contains the ENHANCED MEASUREMENT REPORT message. The message contains the RX measurements for the current cell and RX level measurements for the one adjacent cell. The REPEATED_INVALID_BSIC_INFORMATION section is not present. The parameter SCALE = 0 (not scaled)

End the call.

Lock the sector

Set INVALID_BSIC_REPORTING to 1 (cells that are not adjacent but have correct NCC are reported). Use the MML command: ZEHN:BTS=<bts num>::IBR=1;

Set SCALE_ORD to 1 (scaled by 10dB) using MML command: ZEQM:BTS=<bts num>:SCO=1;

Whilst monitoring the A-bis for SACCH FILLING messages within the SI BEGIN or SI END messages , unlock the sector.

The SACCH FILLING contains the MEASUREMENT INFORMATION message. The REPORT TYPE = 0, INVALID_BSIC_REPORTING = 1, SCALE_ORD = 01.

Make a speech call to a PSTN number or an MS locked to a completely separate BTS. Monitor the TRXsig of the sector on the A-bis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages.

The BTSM layer MEAS. RES. message contains the ENHANCED MEASUREMENT REPORT message. The message contains the RX measurements for the current cell and RX level measurements for the one adjacent cell. The REPEATED_INVALID_BSIC_INFORMATION section is present. It reports the RX level of the cell which was not defined as adjacent. The parameter SCALE = 1 (scaled by 10dB)


DN0694168 Issue 1-0


151 (252)

End the call.

Case Ref. Config BCCH / non-BCCH Hopping Call Type 202252.01 non - EDGE BCCH non – hopping EFR 202252.02 non - EDGE non-BCCH non – hopping AHS 202252.03 EDGE BCCH non – hopping AHS 202252.04 EDGE non-BCCH non – hopping EFR 202252.05 Mixed BCCH non – hopping AHS 202252.06 Mixed non-BCCH non – hopping EFR 202252.07 Mixed BCCH BB – hopping EFR 202252.08 Mixed non-BCCH BB – hopping AHS 202252.09 2+2 common

BCCH, EDGE non-BCCH non – hopping EFR

202252.10 Mixed non-BCCH RF-Hopping AHS

16.2 Invalid_BSIC_Reporting Response Purpose:

The purpose of these cases is to verify that the Measurement Information messages have been correctly sent by checking that the resulting Enhanced Measurement Reports from the MS correctly reflect the format specified by the Measurement Information messages.

Input Expected Output The configuration is setup as defined in Note 67. The hopping mode is only for BTS1. Lock up traffic channels to force calls to be made on the TRX shown in the table of test cases below. Create a invalid neighbour BTS3 by ZEAC command using a BTS which is defined at different BSC (put all its parameter correctly e.g. freq, MCC, MNC, LAC except BCC)

Use ZEHN to set INVALID_BSIC REPORTING to 0 (cells that are not neighbours but have correct NCC are not reported)



Reset the BTS. Monitor the Abis for SACCH FILLING messages within the SI BEGIN or SI END messages. Check both the BCCH and non-BCCH TRX.

The SACCH FILLING contains the MEASUREMENT INFORMATION message. The parameters present are as shown in Note 68. The Report type and the Invalid BSIC Reporting are both set to 0.

Make a call as specified in test case to a PSTN number or an MS locked to a completely separate BTS. Monitor the TRXsig for BTS 1 on the Abis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages. End the call.

Enhanced Measurement Reports (Layer 3) are sent up the Abis (taking Note 70 into account). They only contain RX level information for BTS 2 (in the REPORTING_QUANTITY bit map). They do not contain RX level information for BTS 3 (no REPEATED_INVALID_BSIC_INFORMATION present).

Monitor the Abis for SACCH FILLING messages. Use ZEHN to change INVALID_BSIC_REPORTING to 1 (cells that are not neighbours, but have the correct NCC are reported).

A SACCH FILLING containing a MEASUREMENT INFORMATION message is sent down the Abis. This time the Invalid BSIC Reporting parameter is set to 1.


Enhanced Measurement Reports (Layer 3) are sent up the Abis. This time, they also contain RX level information for BTS 3 (REPEATED_INVALID_BSIC_INFORMATION is present).

Case Ref.

TCH Configuration

Call Type TRX Hopping

1 TCHF EFR Non-BCCH BB-hopping

2 TCHF AFS BCCH Non-hopping

3 TCHH AHS Non-BCCH RAH-hopping

4 TCHD 2+2 TS, 9600 NT, Data call

BCCH RF-hopping

16.3 SCALE_ORD Response Purpose:

The purpose is to verify that the MS is requesting the SCALE value set by the user in the EMR message.

Input Expected Output The configuration is setup as defined in Note 67. Lock up traffic channels to force calls to be made on the TRX shown in the table of test cases below.


DN0694168 Issue 1-0


153 (252)

Input Expected Output The SCALE_ORD (ZEQM) parameter is set to that specified in the test case. This parameter defines an offset that shall be added to the reported downlink signal level before using it for handover and power control decisions and in the updating of statistics.

Reset the BTS. Monitor the Abis for SACCH FILLING messages within the SI BEGIN or SI END messages. Check both the BCCH and non-BCCH TRX.

The SACCH FILLING contains the MEASUREMENT INFORMATION message. The parameters present are as shown in Note 68. The Report type and the Invalid BSIC Reporting are both set to 0. The Measurement Parameters description shows the correct SCALE_ORD value.


Enhanced Measurement Reports (Layer 3) are sent up the Abis (taking into account Note 70). The SCALE information represents the SCALE_ORD value set. Call terminated successfully.

Case Ref.

TRX Configuration

Call Type TRX SCALE value

1 TCHF EFR BCCH 0 (NO)

2 TCHF AFS Non-BCCH 1 (scaled by 10dB)

16.4 Reporting Priority of Neighbouring Cells

Purpose:

The purpose is to verify that the EMR reports the correct amount of Neighbours as well as reporting WCDMA neighbours.



Input Expected Output A site is in use that has six neighbours Setup, which consist of the same band to that of the serving cell. A further 15 GSM neighbours are Setup, which consist of a different band to that of the serving cell. The BCF containing the serving cell is synchronised using the LMU. This shall force the measurement Information message to be transmitted in 2 instances. BTS power levels are set so that the MS shall lock onto the serving BTS. The test is performed either in a screened room, or a cabled environment.

A MS that supports Enhanced Measurement Reportingis selected. The MS is switched on and it is verified In the Field Test software that BTS TEST = OFF, so that the MS can see the neighbouring cells.

The MS locks onto BTS 1.

The Measurement Parameters are Setup as defined in the Test cases.

Reset the BTS. Monitor the Abis for SACCH FILLING messages within the SI BEGIN or SI END messages.

The SACCH FILLING contains the MEASUREMENT INFORMATION message. The parameters present are as shown in Note 68.


Enhanced Measurement Reports (Layer 3) are sent up the Abis (taking into account Note 70). The number of neighbours being reported and the priority in which these are reported are as requested in the measurement information message. Call terminated successfully.

REPORTING Parameter type Priority values Case Ref. SERVING

_ BAND

MULTIBAND

FDD_ MULTIRAT

INVALID_ BSIC

Call Type

1. 3 0 01 0 EFR

2. 0 3 0 0 AFS

3. 0 0 3 0 AHS


DN0694168 Issue 1-0


155 (252)

16.5 Uplink RX Quality Measurement Purpose:

The purpose is to verify that the quality of the uplink radio signal is accurately reflected in the measurements reported by the base station to the BSC.

Test Tools Required: Variable Attenuator, Signal Generator, Spectrum Analyser Note 74. The RX level, RX quality, Mean BEP, CV BEP and UL FER are part of Meas Results message and not part of the Enhanced Measurement Report Layer 3 message.

The Mean BEP, CV BEP and UL FER are coded in Suppl Info field in the Measurement Result in the BTSM layer.

When DTX is on the RxQual Full will always be reported as 7 and may be ignored. The RxQual Sub should reflect the true radio conditions.

Input Expected Output Use any configuration that allows 2-way diversity. For the BB hopping cases use a sector with 2 TRX. Set uplink DTX and hopping mode as shown in the table. The hopping mode is for BTS1.

Set 2-way diversity on. The main and diverse receiver paths must each be tested separately. IMPORTANT NOTE! Ensure that there is no direct path from the MS to the base station through the air. The mobile must be in a screened box. All cable connections must be correctly tightened.

Fix the transmit power of the MS to near its minimum using the following MML command: ZEQM:BTS=##:PMAX1=7,PMAX2=6,PMIN=7; This stops the carrier power from varying during the test, and minimises the chances of a leakage signal via the air reaching the base station.

Make a speech call of the call type shown in the table to a PSTN number or an MS locked to a completely separate BTS. Monitor the TRXsig for BTS 1 on the A-bis for MEASUREMENT RESULTS messages. Adjust the variable attenuator so that the signal level seen at the base station is reported as –84 to –85dBm.



Input Expected Output With the interferer switched off, measure the power of the uplink bursts. Calculate the input power at the receiver taking into account the coupler, any attenuators and any duplexers in the path.

The input power to the receiver is between –83 and –88 dBm.

Disconnect the call. Setup the signal generator to provide a continuous interferer, with digital modulation = GSM standard. Set the reference level to 10dB below the uplink carrier power measured above. (i.e. C/I = 10dB). Switch off the interferer.

Make a speech call to a PSTN number or an MS locked to a completely separate BTS. Check that the carrier power is the same as previously measured. Switch on the interferer (make any slight adjustments to the level if carrier power has changed). Monitor the A-bis for MEASUREMENT RESULT messages. Record a trace for 1 minute at C/I = 10dB. Reduce the C/I in 1dB steps from 10 to 0dB, recording a 1minute trace for each. Disconnect the call, and switch off the interferer.

Analyse the traces for UL mean BEP, UL FER and… DTX off - RxQual Full DTX on - RxQual Sub UL mean BEP remains zero for NT Data Call.

The UL mean BEP, UL FER and RxQual are within the limits shown below.

Case Ref.

Call Type Hopping Mode UL DTX activation

Limits

1. EFR NAH-hopping ON See Table 3 and Table 4

2. AFS BB-hopping ON See Table 3 and Table 4

3. AHS Non-hopping OFF See Table 3 and Table 4

4. 2+2 TS NT 9600 Data call

RAH-hopping OFF See Table 3 and Table 4.

5. FR RF-hopping OFF See Table 3 and Table 4

6. AHS Non-hopping ON See Table 3 and Table 4

Table 3. RxQual and UL BEP Rx Qual level reported UL mean BEP level reported C/I dB

Max Min Max Min


DN0694168 Issue 1-0


157 (252)

10 0 0 31 31

9 0 0 31 31

8 0 0 31 25

7 1 0 31 19

6 3 0 24 15

5 4 1 19 11

4 5 3 14 8

3 6 4 11 5

2 6 5 8 4

1 7 6 6 3

0 7 6 4 1

Table 4. UL FER UL FER reported C/I dB

Max Min

10 0 0

9 0 0

8 0 0

7 0 0

6 0 0

5 0 0

4 0 0

3 3 0

2 11 0

1 17 0

0 20 1



16.6 Downlink Frame Erasure Rate (FER) Measurement

Purpose:

The purpose is to verify that the Downlink Frame Erasure Rate (FER) is calculated and reported correctly when DL DTX is off and is not being calculated/ reported when DL/UL DTX is on.

Test Tools Required: Variable Attenuator, Signal Generator, Spectrum Analyser

Input Expected Output Any configuration is in use.

A MS that supports Enhanced Measurement Reportingis selected.

.

The attenuation at the TX path is adjusted until the BTS power level seen by the MS is 50dBm.

Make a speech call to a PSTN number or an MS locked to a completely separate BTS. The call is held for 30 minutes. Monitor the TRXsig for BTS 1 on the Abis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages. The RX level, RX quality, Mean BEP, CV BEP. The ‘Supplementary Information Field’ within the Enhanced Measurement Report is also decoded and the FER is calculated to verify that it is being reported correctly. End the call.

Enhanced Measurement Reports (Layer 3) are sent up the Abis (taking into account Note 70). The RX level, RX quality, Mean BEP, CV BEP and FER accurately reflect actual input signals. The DL FER is showing zero interference when DL DTX-OFF. When the UL/DL DTX is ON and there is speech in the DL / UL, DTX is shown as ‘off’ and the DL / UL FER is sent. When there is silence, DTX is shown as ‘on’ and the DL and UL FER is not sent. Call terminated successfully.

The signal generator is switched on and the level is adjusted to produce enough interference i.e. C/I is set to 5dB.

Make a speech call to a PSTN number or an MS locked to a completely separate BTS. The call is held for 30 minutes.

Enhanced Measurement Reports (Layer 3) are sent up the Abis.


DN0694168 Issue 1-0


159 (252)

Input Expected Output Monitor the TRXsig for BTS 1 on the Abis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages. The RX level, RX quality, Mean BEP, CV BEP. The ‘Supplementary Information Field’ within the Enhanced Measurement Report is also decoded and the FER is calculated to verify that it is being reported correctly.

The RX level, RX quality, Mean BEP, CV BEP and UL FER accurately reflect actual input signals. When DL DTX-OFF, then the DL FER reflects the interference being introduced. When UL/DL DTX-ON, then DL or UL FER is not sent depending on the DTX on

End the call. Call terminated successfully

Case Ref.

Call Type DTX MODE

1. EFR UL DTX-OFF, DL DTX-OFF

2. EFR1 UL DTX-ON, DL DTX-ON

3 EFR UL DTX-ON, DL DTX-OFF

4 AFS/Fast LA UL DTX-OFF, DL DTX-ON

5 AHS/Slow LA UL DTX-ON, DL DTX-ON 1 Do with Release6 MS

16.7 Averaging of Enhanced Measurement Report (EMR)

Purpose:

The purpose is to verify that the EMR is reporting correctly when averaging is active.

Test Tools Required: Variable Attenuator, Signal Generator, Spectrum Analyser Note 75. A single averaging period is 480ms. The maximum value for this parameter is 4, which means that four reports are averaged into one report and there is 1920ms interval between the measurement reports.

Input Expected Output The configuration is setup as defined in Note 67. The hopping mode is for BTS1.



Input Expected Output The signal path stated in the test case is attenuated using a variable attenuator. The attenuation is varied so that different signal levels are being received during the averaging period.

Make call to a PSTN number or an MS locked to a completely separate BTS as specified in test case. The call is held for 10 minutes. Monitor the TRXsig for BTS 1 on the Abis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages. The RX level, RX quality, Mean BEP, CV BEP and UL FER are checked for accuracy. End the call.

Enhanced Measurement Reports (Layer 3) are sent up the Abis (taking into account Note 70) with the intervals specified by the averaging period. . All the fields in the EMR are being reported correctly and the fields for RX level, RX Quality, Mean BEP, CV BEP are being averaged. The supplementary information contains more information the longer the averaging period as it is representing the measurement reports over the averaging period and not the single measurement report. Call terminated successfully,

Case Ref.

Call Type Hopping Mode

Cell(s) attenuated

Path attenuated

Averaging Period

1 EFR1 NAH-hopping Serving UL 3

2 AFS2 RF-hopping Neighbour DL 4

3 AHS RAH-hopping Serving DL 2

4 2+2 9600 NT

Non-hopping Serving UL 3

1Do the Testcase with Release6 Mobiles 2Use BSC SW S12

16.8 Reporting of correct TA value under high interference and load conditions

Purpose:

To check that the TA value is correctly reported under high interference and load conditions.

Note 76. The test cases must be performed with Rx diversity enabled at the BSC unless otherwise stated.

Note 77. The test cases must be performed on BSC S12 software unless stated otherwise.


DN0694168 Issue 1-0


161 (252)

Equipment and BTS Set-Up Fading Simulator, signal generator

The BCF is in commissioned state.

Input Expected Output The site is up and working as per the configuration defined in the test case.

Set up the fading simulator to simulate the TA according to the distance and speed mentioned in the test case.

Start the simulation of the TA via the fading simulator.

Make 10 calls covering each call type namely (AFS, AHS, EFR, FR, HR).

The calls are successful.

Generate interference using a signal generator and vary the interference such that C/I varies between 27db and 5 db throughout the test case.

Capture the TRX signalling link traces for each TRX via the Abis trace analyser.

The quality of the call will vary as interference is varied.

Observe the Abis Traces for the reported TA values.

The TA should be reported correctly for every call.

This test case is run for 1hr.

Case Ref. Site Type Configuration Speed/distance

437955.01 UltraSite Any configuration using GSM hardware

60km/hr, 0-30Kms and back

16.9 Bad UL SACCH Frames Purpose:

The purpose is to verify that the Enhanced Measurement Report message is discarded and nothing is done for it if the received SACCH block is bad but however the BTS uplink Measurements are handled normally.

Test Tools Required: Variable Attenuator, Spectrum Analyser, and Signal Generator

Input Expected Output Make a site with configuration and hopping as described in test case.



Input Expected Output A MS that supports Enhanced Measurement Reportingis selected. The MS is switched on and it is verified in the Field Test software that BTS TEST = On, so that the MS cannot hand over to any neighbouring cells.

The MS locks onto the BTS.

Make a speech call to a PSTN number or an MS locked to a completely separate BTS. Monitor the TRXsig for BTS 1 on the Abis for MEASUREMENT RESULTS / MEASUREMENT REPORT messages.

Enhanced Measurement Reports (Layer 3) are sent up the Abis (taking into account Note 70).

Interference is added in the uplink until Enhanced measurement reports cannot be decoded. Important: Interference should be with in RLT/ARLT time limits

The Enhanced measurement reports cannot be decoded and therefore are no longer reported. The UL measurement message results are still being reported.

Interference is reduced in the uplink until Enhanced measurement reports can be decoded.

The Enhanced measurement reports can be decoded and therefore are reported. The UL measurement message results are still being reported.

End the Call. Call terminated successfully.

Case Ref.

Configuration

Call Type Hopping Mode

1. 2+2 EFR BB-hopping

2. 2+2 AFS Non-hopping

3. 2+2 AHS RAH-hopping

Ecell

DN0694168 Issue 1-0


163 (252)

17 Ecell

17.1 ECell ERACH Success Rate Purpose: To check that the ERACH success rate is consistently detected across the range of the E-Area with maximum Extended Radius.

Note 78. The standard Ecell configuration is defined as 2 N-TRX + 2 E-TRX, combinerless, in a BTS. All TRXs are EDGE capable, unless otherwise stated. MHAs may be used, in which case all TRXs should have one. Exception is test case 202817.21 where MHAs must be used.

Note 79. The Customer configuration for the Trial is defined as 1 N-TRX + 1 E-TRX, combinerless, in a BTS. All TRXs are EDGE capable. MHAs may be used, in which case all TRXs should have one. Exception is test case 202817.07, where MHAs must be used.

Note 80. RF TA rig is a set up of equipment that allows signal delay on the air interface so that distance can be simulated.

Note 81. This test case must be performed in a screened environment.

Equipment and BTS Set-Up Site: as per test case

BSC: as per test case

PC: MML connection, SiteWizard 5.0, GSM Protocol Analyser

Test equipment: RF TA rig, attenuators, combiners, traffic generator with at least 16 MS



Input Expected Output Set up a site as per test case. Set the radius extension to 35 km. Note that BTS and TRXs must be in locked administrative state in order to activate the ECell feature. ZEQM:BTS=<nr>:EXT=35; ZERM:BTS=<bts nr>,TRX=<bcch trx nr>:CH0=MBCCH,CH1=NOTUSED,CH2=SDCCH; ZERM:BTS=<bts nr>,TRX=<trx nr>:ETRX=E,CH0=ERACH,CH1=SDCCH;

Site comes up to working state. Listing with command ZEEI:BCF=<bcf nr>; displays that site, BTS and TRXs in WO state. The E-TRXs are shown as such and one of them has ERACH configured to it.

Set up the RF TA rig so that the distance varies throughout the range of the extended radius.

RF TA rig is working.

Configure the traffic generator. Latch the phones to the BCCH frequency of the BTS under test. Connect 15 of the phones to the RF TA rig and perform a location update by resetting them. Keep the last phone in the N-Area

The RF TA rig should be configured so that the MSs start off in the N-Area. NetMonitor screen 01.01 displays the BCCH and the TA value. These should correspond to all phones being located in the N-Area, at 35 km, TA is 63.

Monitor OMUSIG and TRXSIGs on the Abis trace, start traffic generator.

Call success rate >99%

Over a period of at least 8 h, change the MSs distance to the BTS. The following distances should be tested: 35, 40, 45, 50, 55, 60, 65, 70, 75 (km).

When distance is 35, the phones should be handed over to E-Area. Call success rate within E-Area >99%. When distance is above 70 km, phones will be out of range and calls should fail. In a lab environment, this may not be the case and the calls may succeed even outside the E-Area at 75 km.

Stop Abis monitoring and analyse the trace. Analyse the Abis trace, to see the success rate of ERACH.

Check active alarms and alarm history. No unexpected alarms should have been generated during test execution.

Case Ref. Heading Configuration

202258.01 ERACH Success Rate Customer ECell configuration. BSC S11.

202258.02 ERACH Success Rate Standard ECell configuration. BSC S11.

202258.03 ERACH Success Rate in S10.5 Standard ECell configuration. BSC S10.5.

202258.04 ERACH Success Rate in S11.5 Standard ECell configuration. BSC S11.5.

202258.05 ERACH Success Rate in S12 Standard ECell configuration. BSC S12.

202258.06 ERACH Success Rate in S13 6 TRX(3N-TRX+3E-TRX) configuration with RTC Use BSC SW S13

Ecell

DN0694168 Issue 1-0


165 (252)

17.2 ECell Emergency Call Purpose: To check that Emergency Calls can be made from E-Area of an extended cell.

Note 82. The standard Ecell configuration is defined as 2 N-TRX + 2 E-TRX, combinerless, in a BTS. All TRXs are EDGE capable, unless otherwise stated. MHAs may be used, in which case all TRXs should be equipped with an MHA.

Note 83. The Customer configuration for the Trial is defined as 1 N-TRX + 1 E-TRX, combinerless, in a BTS. All TRXs are EDGE capable. MHAs may be used, in which case all TRXs should be equipped with an MHA.

Note 84. Tests will be performed with BB2F unless otherwise stated.





MS: phone with FR, EFR, HR, AMR FR&HR, SMS MO&MT capabilities

Test equipment: RF TA rig, attenuators, combiners

Input Expected Output Set up a site as per test case. Set the radius extention to 19 km. ZEQM:BTS=<nr>:EXT=19; ZERM:BTS=<bts nr>,TRX=<bcch trx nr>:CH0=MBCCH,CH1=NOTUSED,CH2=SDCCH; ZERM:BTS=<bts nr>,TRX=<trx nr>:ETRX=E,CH0=ERACH,CH1=SDCCH;

Site is in WO state. Listing with command ZEEI:BCF=<bcf nr>; displays that site, BTS and TRXs in WO state. The E-TRXs are shown as such and one of them has ERACH configured to it.

Emergency call services should already be set up in the Core Network.



Input Expected Output Latch the MS to the BCCH frequency of the BTS under test.

The NetMonitor screen 01.01 shows the BCCH frequency in the top left hand corner.

Set up the RF TA rig so that the distance 30 km can be simulated. Connect the MS to the RF TA rig and perform a location update by resetting it.

On NetMonitor screen 01.01, check that the correct TA value is displayed for the MS. At a distance of 30 km, TA is 21. A value between 19 and 23 is acceptable.

Check active alarms and alarm history. No unexpected alarms are present. Trace the TRXSIGs on the Abis interface and make an emergency call.

Call is successful.

Check active alarms and alarm history. No unexpected alarms should have been generated during test execution.

Analyse the Abis trace. In CHAN RQD message, the call is indicated as an Emergency Call.


200917.01 Emergency call setup via SDCCH in E-Area

Standard ECell configuration. BSC S11.


Customer ECell configuration. BSC S11.



17.3 ECell Signalling Purpose: To check that the ECell feature works with different signalling configurations.


Note 87. The Customer configuration for the Trial is defined as 1 N-TRX + 1 E-TRX, combinerless, in a BTS, combinerless. All TRXs are EDGE capable. MHAs may be used, in which case all TRXs should be equipped with an MHA.


Ecell

DN0694168 Issue 1-0


167 (252)

Note 89.

Signalling RTSL0 RTSL1 RTSL2 RTSL3-RTSL7

Combined BCCH/SDCCH in N-Area

MBCCHC NOTUSED TCH TCH

Separate BCCH/SDCCH in N-Area

MBCCH NOTUSED SDCCH TCH

ERACH E-TRX

ERACH SDCCH TCH TCH

E-TRX SDCCH/TCH TCH TCH TCH





MS: 2 phones with FR, EFR, HR, AMR FR&HR, SMS MO&MT capabilities


Input Expected Output Create a site as per test case. Set the radius extention to 24 km. Note that BTS and TRXs must be in locked administrative state in order to activate the ECell feature.

ZEQM:BTS=<nr>:EXT=24; ZERM:BTS=<bts nr>,TRX=<bcch trx nr>:CH0=MBCCH,CH1=NOTUSED,CH2=SDCCH; or ZERM:BTS=<bts nr>,TRX=<bcch trx nr>:CH0=MBCCHC,CH1=NOTUSED; ZERM:BTS=<bts nr>,TRX=<trx nr>:ETRX=E,CH0=ERACH,CH1=SDCCH;

Site in WO state. Listing with command

ZEEI:BCF=<bcf nr>; displays that site, BTS and TRXs in WO state. The E-TRXs are shown as such and one of them has ERACH configured to it.



Input Expected Output Activate the feature under test at the BSC.

FACCH call setup: ZWOC:10,15,<0=off,FF=on>; ZEEM:EEF=Y,EPF=Y,EOF=Y,ERF=Y; Dynamic SDCCH: ZWOC:10,42,<0=off,FF=on>;

Make sure that only one of these is on at a time. Note that this affects all base stations controlled by the BSC.

Latch the phones to the BCCH frequency of the BTS under test.

NetMonitor screen 01.01 shows the BCCH frequency in the top left hand corner.

Set up the RF TA rig so that the distance 45 km can be simulated. Connect at least one of the MSs to the RF TA rig so that it is in the E-Area. Perform a location update by resetting the phones.

On NetMonitor screen 01.01, check that the correct TA value is displayed for both MSs. A distance of 45 km corresponds to TA=38. Values between 36 and 40 are acceptable.

Make a phone call to make sure that everything is set up correctly.

Call successful The allocated SDCCH is displayed on the MS display shortly during call setup: screen 01.01, second row, left most value shows the RTSL, bottom row, right most value shows used channel. Check also in the BSC: ZERO:BTS=<nr>; The last column indicates the status of each RTSL. It should correspond to the allocated SDCCH seen on the MS display. This will be difficult to see, due to the short duration of the dynamically configured SDCCH.

Check active alarms and alarm history. No unexpected alarms are present. Monitor the TRXSIGs on the Abis interface.

Reserve all pre-configured SDCCH in E-Area

Check that the static SDCCH resources have been blocked.

Ecell

DN0694168 Issue 1-0


169 (252)

Input Expected Output Make a phone call. Call is successful.

The allocated SDCCH is displayed on the MS display: screen 01.01 during call set up, i. e. when channel type is SDCC. Check also in the BSC:

ZERO:BTS=<nr>; The last column indicates the status of each RTSL. It should correspond to the dynamically allocated SDCCH seen on the MS display. This will be difficult to see, due to the short duration of the dynamically configured SDCCH. In the case of FACCH call setup, the following sequence is seen on the MS display, screen 01.01: AGCH, FA, TFR The RTSL for FA is the same as for TFR.

Repeat the previous step until all TCH RTSLs on the available E-TRXs have been used at least once.

Same result as for step above. Dynamic allocation of SDCCH takes place on all available TCHs on the E-TRXs.

Free the reserved SDCCH channels. Channels are released OK. Make one last phone call. Call is successful

The pre-configured SDCCH channels are used. See MS display, screen 01.01

Stop Abis trace and analyse it In the BTSM layer, message CHAN. ACT. the used RTSL for SDCCH can be seen.

Check active alarms and alarm history. No unexpected alarms should be generated during test execution.


200702.01 Dynamic SDCCH allocation in E-Area and combined BCCH/SDCCH in N-Area


200702.02 Dynamic SDCCH allocation in E-Area and combined BCCH/SDCCH in N-Area, BB2E

Standard ECell configuration with BB2E. BSC S11.

200702.03 Dynamic SDCCH allocation in combined BCCH/SDCCH configuration


200702.04 Dynamic SDCCH allocation in separate BCCH/SDCCH configuration


200702.05 Dynamic SDCCH allocation in separate BCCH/SDCCH configuration, BB2E

Standard ECell configuraiton. BSC S11.




200702.06 Dynamic SDCCH allocation in separate BCCH/SDCCH configuration


200702.07 Dynamic SDCCH allocation in separate BCCH/SDCCH configuration, BB2E

Customer ECell configuration with BB2E. BSC S11.

200702.08 FACCH call setup in E-Area Standard ECell configuration, separate BCCH/SDCCH configuration. BSC S11.

200702.09 FACCH call setup in E-Area Customer ECell configuration, separate BCCH/SDCCH configuration. BSC S11.

200702.10 FACCH call setup in E-Area Standard ECell configuration, separate BCCH/SDCCH configuration. BSC S12.

17.4 ECell Handovers Purpose:

To check that handovers work reliably together with ECell.

Note 91. The standard Ecell configuration is defined as 2 N-TRX + 2 E-TRX, combinerless, in a BTS. All TRXs are EDGE capable, unless otherwise stated. MHAs may be used, in which case all TRXs should have one. Exception is test case 202817.21 where MHAs must be used.

Note 92. The Customer configuration for the Trial is defined as 1 N-TRX + 1 E-TRX, combinerless, in a BTS. All TRXs are EDGE capable. MHAs may be used, in which case all TRXs should have one. Exception is test case 202817.07, where MHAs must be used.




Ecell

DN0694168 Issue 1-0


171 (252)


PC: MML connection,SiteWizard 4.1, GSM Protocol Analyser

Test equipment: RF TA rig, attenuators, combiners, traffic generator

Input Expected Output Set up a sites as per test case. Set the radius extention to 35 km. Note that BTS and TRXs must be in locked administrative state in order to activate the ECell feature.

ZEQM:BTS=<nr>:EXT=35; ZERM:BTS=<bts nr>,TRX=<bcch trx nr>:CH0=MBCCH,CH1=NOTUSED,CH2=SDCCH; ZERM:BTS=<bts nr>,TRX=<trx nr>:ETRX=E,CH0=ERACH,CH1=SDCCH;

Set the HO parameters for continuous handovers as per test case, command groups ZEA and ZEH.

Site comes up to working state. Listing with command


Set up the RF TA rig so that the so that the HO type under test can be simulated.

RF TA rig is in working state.

Configure the traffic generator and connect it to the RF TA rig. Latch the MSs to the BCCH frequency of the BTS under test, then turn BTS Test off and reset the MS.

Net Monitor screen 01-01 displays the TA value. For the configured distance, it should be 63. Net Monitor screen 01-03 displays the BCCH frequencies of the active cell and its adjacent cells. The correct neighbours are displayed.

Check active alarms and alarm history. No unexpected alarms are present. Monitor the TRXSIGs on the Abis interface and start the traffic generator. It must be configured to long enough calls so that at least one HO takes place. Let run for at least 4 h.

Calls are successful. HOs are successful, no HANDOVER FAILURE messages are sent on the Abis. Check NetMonitor on the phone display that BCCH frequencies change correctly

Stop the traffic generator and the Abis monitoring. All calls end normally. Check active alarms and alarm history. No unexpected alarms should have been

generated during test execution. Analyse Abis trace HO procedure takes place correctly each time

and as per test case. UL and DL Rx Quality, both should be mainly 0, but no worse than 3. UL FER should be 0.


202320.01 Reliability of intracell HOs in E-Area


202320.02 Reliability of HOs between E-Area and N-Area


202320.03 Reliability of HOs between E-Area and N-Area, MS at high speed





202320.04 Reliability of intraBSC HOs between two E-Areas

2 Customer ECell configurations. BSC S11.

202320.05 Reliability of intraBSC HOs between E-Area of one sector and N-Area of another sector

2 Customer ECell configurations. BSC S11.

202320.06 Reliability of HOs between E-Area of UltraSite and E-Area of Talk

Customer ECell configuration + Talk ECell configuration (1 N-TRX + 1 E-TRX). BSC S11.

202320.07 Reliability of intersystem HOs between E-Area and 3G cell

Customer ECell configuration + 1 3G “cell”. BSC S11.

202320.08 Reliability of intracell HO in E-Area Standard ECell configuration. BSC S11.

202320.09 Reliability of HOs between E- and N-Areas of the same BTS


202320.10 Reliability of intraBSC HO between two E-Areas

2 Standard ECell configurations. BSC S11.

202320.11 Reliability of intraBSC HO between E-Area of one BTS and N-Area of another BTS

2 Standard ECell configurations. BSC S11.

202320.12 HO reliability between E-Area of UltraSite (Extended Range Cell) and E-Area of Talk (Extended Cell)

Standard ECell configuration. Talk with Extended Cell. BSC S11.

202320.13 Reliability of HOs between E- and N-Areas of the same BTS


The TA value for the E-Area can be calculated by subtracting the Extention Radius from the Distance between BTS and MS. Then dividing the result by 0.553 and rounding up to nearest integer.

17.5 ECell HO during data call Purpose: To check that data calls are handed over correctly in an ECell.

Ecell

DN0694168 Issue 1-0


173 (252)

Note 95. The standard ECell configuration is defined as 2 N-TRX + 2 E-TRX, combinerless, in a BTS. All TRXs are EDGE capable, unless otherwise stated. MHAs may be used, in which case all TRXs should be equipped with an MHA.



Note 98. (HS)CSD rig is a set up of laptops and phones to enable testing of these features.



PC: MML connectionSiteWizard 5.0, GSM Protocol Analyser

MS: 2 phones with FR, EFR, HR, SMS MO&MT capabilities

Test equipment: RF TA rig, (HS)CSD rig, attenuators, combiners

Input Expected Output Set up a site as per test case. Set the radius extention to 29 km.




Latch the MSs to the BCCH frequency of the BTS under test.

NetMonitor screen 01.01 displays the BCCH frequency.

Set up the RF TA rig so that the distance 40 km can be simulated.

RF TA rig is working

Set up the (HS)CSD rig. Connect one of the data phones to the RF TA rig, so that it is in the E-Area and perform a location update by resetting it. Leave the second phone in the N-Area.

On NetMonitor screen 01.01, check that the correct TA value is displayed for all MSs.At a distance of 40 km, TA=20. Values between 18 and 22 are acceptable.

Check active alarms and alarm history No unexpected alarms are present.



Input Expected Output Monitor the TRXSIGs on the Abis interface and make a circuit switched data call as per test case. Transfer 1MB file in both directions. During transmission, move the phone in the E-Area closer so that the call is handed over to the N-Area.Then move it away, so that a second HO takes place and the phone is back in the E-Area.

File transfer is successful, HOs are successful, check the speed and RTSLs used from the NetMonitor display. The sent and the received file should be identical. The data throughput is as expected.

Stop monitoring and check active alarms and alarm history.

No unexpected alarms should have been generated during test execution.

Analyse the Abis trace. Check that the used speed and RTSLs are the same as displayed on the phones. Check also that there are no corrections or CRC during the transfers. HO commands can be seen.


220012.01 HO between E-Area and N-Area of same cell during 14.4 k non-transparent CSD call


220012.02 HO between E-Area and N-Area of same cell during 3+1 non-transparent HSCSD call


220012.03 HO between E-Area and N-Area of same cell during 14.4 k non-transparent CSD call





6 TRX Ecell configuration with RTC (3N-TRX+3E-TRX). Use BSC SW S13

Expected throughput for (HS)CSD:

Data Rate

bps

Minimum transfer time for 1Mb (seconds)

Maximum transfer time for 1Mb (seconds)

2400 3495 4194

4800 1748 2098

9600 874 1049

14400 583 700

19200 437 524

28800 291 349

Ecell

DN0694168 Issue 1-0


175 (252)

38400 218 262

43200 194 233

57600 146 175

17.6 ECell EMR Purpose: To check that Enhanced Measurement Reports are received from the E-Area of an Ecell.







MS: 2 phones with FR, EFR, HR, SMS MO&MT and EMR capabilities




Input Expected Output Set up a site as per test case. Set the radius extention to 25 km.




Configure the adjacent cells: Neighbour 1 is the second sector in the ECell cabinet and has a valid BSIC. Neighbour 2 must be a site controlled by another BSC, whose BSIC has the same NCC part, but a different BCC part.

ZEAC:BTS=<ecell>::ABTS=<neighbour1>; ZEAC:BTS=<neighbour1>::ABTS=<ecell>; ZEAC:BTS=<ecell>::LAC=<neighbour2 lac>,CI=<neighbour2 ci>:NCC=<neighbour2 ncc>,BCC=<neighbour2 BCC>FREQ=<neighbour2 bcch>;

And in the BSC of the second site

ZEAC:BTS=<neighbour2>::LAC=<ecell lac>,CI=<ecell ci>:NCC=<ecell ncc>, BCC=<ecell bcc>,FREQ=<ecell bcch>;

Neighbours are created and can be listed with

ZEAO:BTS=<ecell>;

Ecell

DN0694168 Issue 1-0


177 (252)

Input Expected Output Set up for EMR: Turn off DL DTX. Note that this is on by default at the BSC and affects all BTSs. It can be switched of at the MSC for individual BTSs

ZEPR:NO=<bts ci nr>:DTX=ON; The MSC feature is called “DL DTX disabled by MSC”, so DTX=ON in the command above activates it and disables DL DTX. Disable averaging

ZEQM:BTS=<nr>:BMA=1; Enable reporting of invalid BSICs

ZEHN:BTS=<nr>::IBR=1;

Latch the MSs to the BCCH frequency of the BTS under test. Then turn off BTS Test and reset the phones.

NetMonitor screen 01.03 displays the BCCH frequency and the frequencies of the two neighbouring cells.



Connect one of the phones to the RF TA rig, so that it is in the E-Area and perform a location update by resetting it.Leave the other phone in the N-Area.

On NetMonitor screen 01.01, check that the correct TA value is displayed for the MSs. For a distance of 30 km, TA=10. Values between 8 and 12 are acceptable. On screen 01.03 check that the neighbours can be seen.

Check active alarms and alarm history. No unexpected alarms are present. Monitor the OMUSIG and TRXSIGs on the Abis interface and reset the site. After it comes back up, make FR/EFR and HR phone calls between the two areas and speak in both directions. The calls should last a few minutes so that several EMRs are received for each call.

Site comes up to WO state after reset. Calls are successful. There are no disturbing click and noises.


Stop monitoring the Abis and analyse the trace. During site reset: The SACCH FILLING message (within the SI BEGIN and SI END messages) contains the MEASUREMENT INFORMATION element containing the parameter Report_Type, which says that EMR will be used if supported by the MS. During calls: Enhanced Measurement Reports are reported from BTS to BSC after a call has been established. Check that the following parameters in the EMR have correct values: BSIC Seen: 01 Reporting Quantity: <ecell bts nr> Reporting Quantity: <neighbour 1 bts nr>





220009.01 EMR from E-Area, no averaging Cabinet 1: 1 standard ECell configuration, 1 normal sector.

Cabinet 2: any configuration

BSC S11

220009.01 EMR from E-Area, no averaging Cabinet 1: 1 standard ECell configuration, 1 normal sector.

Cabinet 2: any configuration

BSC S12

17.7 ECell Packet Switched Data Purpose: To check that GPRS and EGPRS still works in N-Area of a cell configured with ECell.






PC: MML connection, SiteWizard 4.1, GSM Protocol Analyser, file transfer application e. g. FTP

MS: 1 phone with GPRS capability and 1 phone with EGPRS capability

Test equipment: GPRS/EGPRS laptop, attenuators, terminators

Ecell

DN0694168 Issue 1-0


179 (252)

Input Expected Output Set up a site and activate packet switched data as per test case. Set the radius extention to 31 km. Note that BTS and TRXs must be in locked administrative state in order to activate the ECell feature.


If a 2PCM Abis connection is required, configure PCM1 for the N-Area and PCM2 for the E-Area.


ZEEI:BCF=<bcf nr>; displays that site, BTS and TRXs in WO state. The E-TRXs are shown as such and one of them has ERACH configured to it. Check also that the Gp RTSL has been configured to an N-TRX.

Latch the MS to BCCH frequency of the BTS under test.

NetMonitor screen 01.01 displays the BCCH.

Set up laptop and phone for file transfer.

GPRS/EGPRS setup works.

Check active alarms and alarm history. No unexpected alarms are present. Monitor OMUSIG, TRXSIG and GP RTSL for PCU Data Frame on the Abis interface and transfer a 1 M file in both directions. Note the throughput for the data transfer. Use e. g. a picture file, so it is easy to confirm that transfer went OK.

File transfers are OK. Throughput is as specified for the CS/MCS used.

Stop Abis trace and analyse it. Correct CS/MCS is used. Rx Quality should be mostly 0 and no worse than 3.



199522.01 File transfer in N-Area, GPRS only, CS1


199522.02 File transfer in N-Area, GPRS only, CS2


199522.03 File transfer in N-Area, GPRS only, CS1, BB2E


199522.04 File transfer in N-Area, GPRS only, CS2, BB2E


199522.05 GPRS only in N-Area Customer ECell configuration. BSC S11.

199522.06 File transfer in N-Area, GPRS with EGPRS switched on, CS1


199522.07 File transger in N-Area, GPRS with EGPRS switched on, CS2




199522.08 GPRS with EGPRS active in N-Area


199522.09 File transfer in N-Area, EGPRS, modulation coding scheme selected from each header type.


199522.10 File transfer in N-Area, EGPRS, one modulation coding scheme from each header type


199522.11 GPRS only in N-Area Customer ECell configuration. BSC S12.

199522.12 GPRS with EGPRS active in N-Area


199522.13 File transfer in N-Area, EGPRS, one modulation coding scheme from each header type


17.8 ECell simultaneous GPRS and EGPRS transfer

Purpose: To check that an ECell can handle a simultaneous GPRS and EGPRS file transfer in N-Area.



Note 107. Packet switched services should be configured so that only 1 TSL is used for the GPRS transfer and 1 TSL is used for the EGPRS transfer.



PC: MML connection, SiteWizard 4.1, GSM Protocol Analyser, file transfer application e. g. FTP

Ecell

DN0694168 Issue 1-0


181 (252)

MS: 2 phones with GPRS and EGPRS capabilities

Test equipment: GPRS/EGPRS laptops, attenuators, terminators

Input Expected Output Set up a site and activate GPRS and EGPRS as per test case. Set the radius extention to 10 km.



ZEEI:BCF=<bcf nr>; displays that site, BTS and TRXs in WO state. The E-TRXs are shown as such and one of them has ERACH configured to it. Check also that the Gp RTSL has been configured to an N-TRX.

Latch the MSs to BCCH frequency of the BTS under test.

NetMonitor screen 01.01 displays the BCCH.

Set up laptops and phones for file transfer. Transfer

GPRS/EGPRS setups work.

Check active alarms and alarm history. No unexpected alarms are present. Monitor OMUSIG, TRXSIG and GP RTSLs for PCU Data Frame on the Abis interface and transfer a 1 M file in both directions. Note the throughput for the data transfer. Use e. g. a picture file, so it is easy to confirm that transfer went OK.

File transfers are OK. Throughput is as specified for the CS/MCS used.

Stop Abis trace and analyse it Correct CS/MCS is used. Rx Quality should be mostly 0 and no worse than 3.



220013.01 Simultaneous GPRS and EGPRS file transfers in N-Area


220013.01 Simultaneous GPRS and EGPRS file transfers in N-Area


GPRS and EGPRS throughput should lie between 85% and 100% of the maximum theoretical value. Convert from kbyte/s to kbit/s by multiplying by 8.47.

CS or MCS Max theoretical Data Rate

(kbit/s)

85% of theoretical max

(kbit/s) CS1 8 6.8



CS2 12 10.2

MCS1 8.8 7.48

MCS2 11.2 9.52

MCS3 14.8 12.58

MCS4 17.6 14.96

MCS5 22.4 19.04

MCS6 29.6 25.16

MCS7 44.8 38.08

MCS8 54.4 46.24

MCS9 59.2 50.32

The above throughput values are based on 1 GP RTSL.

17.9 ECell Circuit Switched Data Purpose: To check that CSD and HSCSD work in the E-Area of a cell configured with ECell.








Ecell

DN0694168 Issue 1-0


183 (252)

MS: 2 phones with FR, EFR, HR, AMR FR&HR, SMS MO&MT capabilities

Test equipment: RF TA rig, attenuators, combiners, (HS)CSD laptops, screened room (optional).

Input Expected Output Set up a site as per test case. Set the radius extention to 29 km. Note that BTS and TRXs must be in locked administrative state in order to activate the ECell feature.




Latch the MSs to the BCCH frequency of the BTS under test.

NetMonitor screen 01.01 displays the BCCH frequency.



Set up one (HS)CSD laptop in the E-Area and the other in the N-Area. Connect a phone to each laptop. Perform a location update on the E-Area phone by resetting it.

On NetMonitor screen 01.01, check that the correct TA value is displayed for all MSs. At a distance of 40 km, TA=20. Values between 18 and 22 are acceptable.

Check active alarms and alarm history. No unexpected alarms are present. Monitor the TRXSIGs on the Abis interface and make a circuit switched data call as per test case. Transfer 1M file in both directions.

File transfer is successful, check the speed and RTSLs used from the NetMonitor display. The sent and the received file should be identical.

Stop monitoring and check active alarms and alarm history.

No unexpected alarms should have been generated during test execution.

Analyse the Abis trace. Check that the used speed and RTSLs are the same as displayed on the phones. Check also that there are no corrections or CRC during the transfers.


199740.01 9.6k CSD non-transparent file transfer on ERACH E-TRX.


199740.02 9.6 CSD non-transparent file transfer on non-ERACH E-TRX.


199740.03 9.6k CSD non-transparent file transfer in E-Area.

Customer ECell configuration, BSC S11.






199740.05 14.4k CSD non-transparent file transfer on non-ERACH E-TRX.




199740.07 14.4k 2+2 HSCSD non-transparent file transfer on ERACH E-TRX.


199740.08 14.4k 2+2 HSCSD non-transparent file transfer on non-ERACH E-TRX.


199740.09 14.4k 2+2 HSCSD non-transparent file transfer in E-Area.


199740.10 14.4 3+1 HSCSD non-transparent file transfer on ERACH E-TRX.


199740.11 14.4 3+1 HSCSD non-transparent file transfer on non-ERACH E-TRX.


199740.12 14.4 3+1 HSCSD non-transparent file transfer in E-Area.






199740.15 14.4k 2+2 HSCSD non-transparent file transfer in E-Area.



6 TRX Ecell configuration with RTC (3N-TRX+3E-TRX). Use BSC SW S13.

199740.17 14.4k 2+2 HSCSD non-transparent file transfer on non-ERACH E-TRX.

6 TRX Ecell configuration with RTC (3N-TRX+3E-TRX). Use BSC SW S13.

Expected throughput for (HS)CSD:

Data Rate

bps

Minimum transfer time for 1MB (seconds)

Maximum transfer time for 1MB (seconds)

2400 3495 4194

4800 1748 2098

9600 874 1049

14400 583 700

Ecell

DN0694168 Issue 1-0


185 (252)

19200 437 524

28800 291 349

38400 218 262

43200 194 233

57600 146 175



18 DFCA

18.1 Speech Call Set-up via FACCH with DFCA

Purpose: The purpose of the following test cases is to ensure that a TCH channel can be first used for signalling (call establishment) & modified to a speech channel on a non DFCA TRX.

Input Expected Output A DFCA Configuration (specified in relevant Nokia UlraSite/MetroSite Schedule) is used. Dynamic SDCCH feature is not active in BSC. The static SDCCH channels are reserved in the DFCA segment. Make a CS voice call from MS to MS. Monitor the a-bis Repeat 5 times.

Call is established via FACCH on non DCFA TRX TS. After signalling is complete the TS is changed to appropriate codec via Mode Modify message and calls are held until terminated. The received audio quality is good and without distortion.

Case Ref. Codec .01 FR .02 EFR

18.2 AMR with DFCA Purpose: To ensure that AMR call setup, fast link adaptation & slow link adaptation operate correctly with DFCA active.

DFCA

DN0694168 Issue 1-0


187 (252)

Input Expected Output A DFCA Configuration is used that includes GSM (non EDGE) and EDGE DFCA TRX. ACS and Initial Codec are default values in the BSC. DTX is enabled A call is made via every TRX. Each call must be held for at least 30 seconds. The a-bis is monitored during the test During the AMR call, C/I conditions are changed step by step by manipulating air interface so that the codec mode is changed.(can be done by attenuation and generating an interference signal from signal generator) The quality of call is checked during the link adaptation. The attenuation is decreased step by step

Calls are initiated according to parameters defined to the BTS. The quality of the call is good. No disturbing sounds are heard during the speech or silent periods. A-bis CHANNEL ACTIVATION message includes the used AMR speech codec and the set of codec modes. Abis MEASUREMENT RESULT message show values when DTX is not used. RX Qual Full & Sub in both uplink and downlink vary between 0-7 according the interference. When DTX is applied, values of RX Lev Full & RX Qual Full are –110 dB & 7 respectively. The RX qual Sub is 0 in laboratory conditions. Interference applied is also represented by the FER measurements When the downlink is degraded, MS requests BTS to apply a new codec (CMR is seen in the Abis). When the uplink is degraded, BSC commands MS to apply a new codec. When the uplink/downlink is attenuated, the codec mode is changed towards the most robust codec mode (more correction, lower bit rate). No disturbing sounds are heard when codec mode change occurs. When uplink/downlink attenuation is decreased, the codec mode is changed towards the least robust codec mode (less correction, higher bit rate). If Fast LA is in use, the codec mode change is allowed in every second TCH frame (~ 40 ms). With Slow LA, codec mode changes are allowed on SACCH frame interval (480 ms). (CMI and CMR values are seen on Abis)

Case Ref. Link Adaptation .01 Fast .02 Slow



18.3 Synchronous & Asynchronous Handover with DFCA

Purpose: The purpose of the following test cases is to verify that Synchronous and Asynchronous handovers operate correctly with DFCA

Note 112. Test cases 3 and 4 shall be performed causing handovers between a DFCA BTS and a normal (non-DFCA) BTS

Input Expected Output Use any Multi-TRX configuration with type of TRX as specified in test case. Neighbour definition is by adjacency and BA list for all cases

A call is established in the source cell and terminated in a separate test cell with same call type Codec or user rate. Inter cell handover are triggered to target cell at least 20 times during the same call.

Handovers can be performed from target to source cell and back. If there are assignment failures, then the call is not released and failure is recovered by GSM signalling.

Speech call: A conversation is held. During the handovers speech quality at both ends of the calls are observed for unexpected audio disturbances.

The perceived speech is unaffected by the handover procedure and there are no additional audio signals noticed. (E.g. clicks). In HR calls there may be a period of silence during handover due to frame stealing.

Data call: Data call is single TS. During the handover procedures a 200Kb data file is transferred in alternative directions. The transferred data is compared with the original file.

Data call is set up on the DFCA TRX. Data can be sent and received in both directions with the user data rate as defined in test case. Data is transferred with zero error.

Case Ref. Call type / Codec or user rate

Handover Type

TRX

1. AMR / FR Synchronous EDGE 2. NT data / 9600 Synchronous EDGE 3. AMR / HR Asynchronous GSM 4. NT data / 14400 Asynchronous GSM

DFCA

DN0694168 Issue 1-0


189 (252)

18.4 EGPRS with DFCA Purpose: The purpose of the following test cases is to ensure that the BTS will select non DFCA TRX to process packet switched data

Input Expected Output Use any Multi-TRX configuration with type of TRX as specified in test case. All non DFCA TRX timeslots are configured to be GPRS enabled and using default GPRS capacity BCCH TRX and non-DFCA TRX are set as GTRX=Y and DFCA TRX are as GTRX=N (ZERM:BTS=#,TRX=#:GTRX=Y/N) EGPRS is set as specified Packet data transfer is started using the coding scheme and direction as defined in the test case. The user data rate is monitored. When the data transfer is complete a CS speech call is made on the same TS

The expected data rates for the coding scheme are achieved. In the PCU data frame the values for Coding scheme & RX level are verified to be reliable. The circuit switch call is successful. After releasing the call the timeslot regains synchronisation.

Case Ref. Coding Scheme

Direction

EGPRS Data Rate/TS

TRX

1. CS-1 Uplink Disabled 9Kbit/s GSM

2. MCS-9 Downlink

Enabled 48Kbit/s EDGE



19 IMSI Based Handover

19.1 IBHO Feature Activation, GSM to GSM Purpose: To verify that when IMSI based handover is enabled for the BTS, the feature information is sent in the SI_BEGIN message, and that the site performs basic functions normally with the BTS SW.

Equipment and BTS Set-Up Description and diagrams of BTS set-up.

Input Expected Output Lock the BTS.

Monitor Abis

Set IBHO_GSM_ENABLED (ZEQM) to YES for the BTS.

Unlock the BTS

DF6.0-3 Message BTS SW does not support IBHO appears on MML, and sector stays locked. DF7 and CX(M)5.0 SI_BEGIN is sent to the BTS, containing the IBHO feature information which indicates that IBHO feature is enabled

All units are in working order, there are no unexpected alarms at the BSC or MMI, and calls can be made on all TRX.

Case Ref. Configuration SW

197188.01 Any DF6.0-3

197188.02 Any DF7

Case Ref. Configuration SW

197188.03 Multi TRX CX(M)5.0

IMSI Based Handover

DN0694168 Issue 1-0


191 (252)

19.2 GSM to GSM IBHO, call setup 2 MS with different PLMN, EMR/MR and multi-band

Purpose: To check that SI messages are sent separately for each call and handover takes place to the PLMN listed in the ANE.

Equipment and BTS Set-Up Description and diagrams of BTS set-up.

Input Expected Output Use 2 MS with different PLMN values. For test case 197192.06 call setup should use FACCH. Dynamic SDCCH feature should be set to not active in BSC, & the static SDCCH channels reserved in the sector.

Monitor Abis for messages sent to BTS, and measurement reports from MS.

Establish a voice call with the first MS CHANNEL ACTIVATION message for the TCH is sent on the Abis to the BTS, with SI5 and SI6 messages (and SI5bis or SI5ter, depending on the bands being tested) containing neighbour cell information from the AN associated with the PLMN of the phone.

The neighbour ARFN being measured by the MS should correspond with the values sent in the SI messages (for EMR measurements only, this is not true for the period before EMR reports start when standard MR are used)

Establish a voice call with the second MS.

CHANNEL ACTIVATION message for the TCH is sent on the Abis to the BTS, with SI5 and SI6 messages (and SI5bis or SI5ter, depending on the bands being tested) containing neighbour cell information from the AN associated with the PLMN of the phone.

The neighbour ARFN being measured by the MS should correspond with the values sent in the SI messages

Handovers can be performed successfully, at least 2 times, from target to source cell and back for both MS.



Case Ref. MR/EMR Source: Band/Target: Band

197192.01 MR 900/900

197192.02 EMR 900 /E-900

197192.03 MR 900/1800

197192.04 EMR 1800/1800

197192.05 MR 1900/1900

197192.06 MR 900/900 FACCH call setup

197192.07 MR 900/900 MultiBCF configuration

197192.08 MR 900/900 Primesite only

CS3&4

DN0694168 Issue 1-0


193 (252)

20 CS3&4

20.1 GPRS Attach and PDP Context Purpose:

The purpose of these cases is to prove that GPRS CS1 - CS4 capable mobiles can perform successful Attach and Detach to the GPRS network and that a PDP context can be established

Test Tools Required: None

Input Expected Output A Multi TRX with Single Sector (BTS) Configuration is in use. Set the Coding Scheme as shown in the table. An MS is switched on to perform combined IMSI & GPRS attach, and then PDP context establishment is done. Gb Interface is monitored to verify the behaviour. GPRS data transfer is made using a 500Kb file in Downlink direction to verify that the defined Coding Scheme is being used.

Gb Interface indicates GPRS attach and PDP context establishment should be successful. Data packet transfers successfully and in the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable.

A BTS reset is given by BSC MML command. A GPRS Attach is performed and then PDP context establishment is done. GPRS data transfer is made using a 500Kb file in uplink direction to verify that the defined Coding Scheme is being used.

After Reset the site returns to working state. GPRS synchronisation procedure operates correctly. GPRS attach and PDP context should be successful. Data packet transfers successfully and in the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable.



Input Expected Output This step is only performed with Case Ref 2. A BCCH reconfiguration is made to occur such that BCCH moves on to the GPRS Enabled TRX. A GPRS Attach is performed and then PDP context establishment is done. GPRS data transfer is made using a 500Kb file in Downlink direction to verify that the defined Coding Scheme is being used.

BCCH reconfiguration occurs and the GPRS synchronisation procedure operates correctly. GPRS attach and PDP context is successful. Data packet transfers successfully and in the PCU MASTER DATA FRAME the values for Coding scheme & RX level is verified to be reliable and same as defined in the case.

GPRS is Disabled for the Sector using command “ ZEQV “ and then it is Enabled again. A GPRS Attach is performed and then PDP context establishment is done. GPRS data transfer is made using a 500Kb file in Downlink direction to verify that the defined Coding Scheme is being used.

GPRS attach and PDP context should be successful. Data packet transfers successfully and in the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable.

Case Ref.

BCCH/TCH Configuration

GPRS Enabled TRX

Coding Scheme in use

1 MBCCH+SDCCH / TCHFs / - BCCH TRX CS-3

2 MBCCHC / TCHDs Non BCCH TRX CS-4

CS3&4

DN0694168 Issue 1-0


195 (252)

20.2 Data Transfer using CS3-CS4

20.2.1 Downlink Data transfer with CS-3

Purpose:

The purpose of these cases is to verify that data can be transferred reliably using coding scheme 3 in downlink direction on PDTCH with BER of 0%, and that the expected data rates for the coding scheme-3 is achieved and the given TS can be used alternatively for circuit switched and packet data.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled. GPRS with Coding Scheme 3 is Enabled for the BTS under test. A Circuit switched speech call is established and checked in the GP timeslot to be tested. The call is released.

The circuit switched call is successful. After releasing the call the timeslot regains GPRS synchronisation.

Packet data transfer in Downlink direction is started on the tested timeslot using transfer protocol type as defined for the test. The user data rate, Coding Scheme used and RX level is monitored. Monitor the A-bis for BEP values

The data is transferred with BER of 0%. The expected data rates shown below for the coding scheme are achieved. In the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable. BEP values (CV_BEP & MEAN_BEP) are verified to be reliable.

When the data transfer is complete a circuit switched speech call is again established and verified on the same tested timeslot.

The circuit switch call is successful. After releasing the call the timeslot regains GPRS synchronisation.

Case Ref.

BCCH Configuration/ TCH Configuration/ CS Call type

Transport

Type/ File size

GPRS Enabled TRX/ Number of timeslots available

Expected Data Rate

1 MBCCH+SDCCH/TCHFs/ EFR

UDP/ 500KB

BCCH / 1 TS 15.6 kbps



Input Expected Output 2 MBCCHC /TCHDs/AMR

HR1 - / 1MB Non BCCH / 2 TS 31.2 kbps

1 Use RF hopping

20.2.2 Uplink Data transfer with CS-3

Purpose:

The purpose of these cases is to verify that data can be transferred reliably using coding scheme 3 in Uplink direction on PDTCH with BER of 0%, and that the expected data rates for the coding scheme-3 is achieved and the given TS can be used alternatively for circuit switched and packet data.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled. GPRS with Coding Scheme 3 is Enabled for the BTS under test. A Circuit switched speech call is established and checked in the GP timeslot to be tested. The call is released.


Packet data transfer in Uplink direction is started in tested timeslot using transfer protocol type as defined in the case. The user data rate, Coding Scheme used and RX level is monitored. Monitor the A-bis for BEP values

The data is transferred with BER of 0%. The expected data rate shown in the table for the coding scheme is achieved. In the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable. BEP values (CV_BEP & MEAN_BEP) are verified to be reliable.



Case Ref.

BCCH Configuration/ TCH Configuration/ CS Call type/hopping

Transport

Type/ File size


Expected Data Rate

1 MBCCH +SDCCH/TCHFs/EFR/BB

UDP/ 500 KB

Non BCCH/1 TS 15.6 kbps

2 MBCCHC /TCHFs/TFR/None

- / 1MB

BCCH/2 TS 31.2 kbps

CS3&4

DN0694168 Issue 1-0


197 (252)

20.2.3 Downlink Data transfer with CS-4 Purpose:

The purpose of these cases is to verify that data can be transferred reliably using coding scheme 4 in downlink direction on PDTCH with BER of 0%, and that the expected data rates for the coding scheme 4 is achieved and the given TS can be used alternatively for circuit switched and packet data.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled. GPRS with Coding Scheme 4 is Enabled for the BTS under test. A Circuit switched speech call is established and checked in the timeslot to be tested. The call is released.


Packet data transfer in Downlink direction is started in tested timeslot using transfer protocol type as defined in the case. The user data rate, Coding Scheme used and RX level is monitored. Monitor the A-bis for BEP values

The data is transferred with BER of 0%. The expected data rate as shown below for the coding scheme is achieved. In the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable. BEP values (CV_BEP & MEAN_BEP) are verified to be reliable.



Case Ref.

BCCH Configuration/ TCH Configuration/ CS Call type

Transport Type/File size


Expected Data Rate

1 MBCCH + SDCCH/TCHDs/AHS1

- / 1MB BCCH/2 TS 42.8 kbps

2 MBCCHC /TCHFs/EFR2 - / 5MB Non BCCH/3 TS 64.2 kbps 1 Use UDP protocol for data transfer 2 Use RAH hopping when executed with UltraSite



20.2.4 Uplink Data transfer with CS-4 Purpose:

The purpose of these cases is to verify that data can be transferred reliably using coding scheme 4 in Uplink direction on PDTCH with BER of 0%, and that the expected data rates for the coding scheme 4 is achieved and the given TS can be used alternatively for circuit switched and packet data.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled. GPRS with Coding Scheme 4 is Enabled for the BTS under test. A Circuit switched speech call is established and checked in the timeslot to be tested. The call is released.


Packet data transfer is started in tested timeslot using transfer type as defined in the case. The user data rate, Coding Scheme used and RX level is monitored. Monitor the A-bis for BEP values

The data is transferred with BER of 0%. The expected data rate as shown below for the coding scheme is achieved. In the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable. BEP values (CV_BEP & MEAN_BEP) are verified to be reliable.



Case Ref.

BCCH Configuration/ TCH Configuration/ CS Call type/Hopping mode

Transport Type/File size


Expected Data Rate

1 MBCCHC/TCHDs/AMR HR/None

- /1 MB BCCH/1 TS 21.4 kbps

2 MBCCH+SDCCH/TCHFs/HR1/RF

UDP/500 KB

Non BCCH/2 TS 42.8 kbps

CS3&4

DN0694168 Issue 1-0


199 (252)

20.3 CS3 and CS4 GPRS Data transfer

Purpose: The purpose of these cases is to verify that data can be transferred using coding scheme 3 and 4, that data can be transferred reliably in both uplink & downlink on PDTCH, and that a given TS can be used alternatively for circuit switched and packet data.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled. Set BTS to use specified coding scheme as defined in the case.

A Circuit switched speech call is established and checked in the GP timeslot to be tested. The call is released.


Packet data transfer is started using TCP/IP in tested timeslot with coding scheme as defined in the case in both UL and DL directions. The user data rate is monitored. Date Transfer should be made 3 times to get a reliable throughput File Size: 1 Mb in DL, 100 Kb in UL

The data is transferred with BER of 0%. The expected data rates for the coding scheme are achieved. (CS-3 approx. 15.6kbit/s per timeslot used and CS-4 is approx. 21.4kbit/s per timeslot). In the PCU Master data frame the values for Coding scheme & RX level are verified to be reliable.

When the data transfer is complete, a circuit switched speech call is again established and verified in the same tested timeslot.


Object administration is performed from BSC as defined in the case.

The GP timeslot regains synchronisation after object administration commands are run successfully.

Packet data transfer is again started using TCP/IP in tested timeslot with coding scheme and direction as defined in the case.

The data transfer is successful.

Case Ref.

BTS/Channel Configuration

GP TRX Coding Scheme /TS

Hopping Object Administration Command

1 6+6, EDGE HW, BB2E, RTxx / MBCCHC + TCHF

Non BCCH

CS3/(3+1) BB- Hopping

BTS Lock/Unlock



Input Expected Output 2 4+4+4,

GSM/EDGE HW, BB2A/BB2E, DVxx / MBCCHC + TCHF

BCCH CS4/(2+2) RF- Hopping

BCF Lock/Unlock

Purpose: The purpose of these cases is to verify that data can be transferred using coding scheme 3 and 4 along with EGPRS data calls, that data can be transferred reliably in both uplink & downlink on PDTCH, and that a given TS can be used alternatively for circuit switched and packet data.


Input Expected Output Use configuration as defined in the case. Configure 4 A-bis timeslots to the EDAP. Use CDED, CDEF and CMAX to enable 4 radio timeslots as GP TS. A Circuit switched speech call is established and checked in the GP timeslot to be tested.

Packet data transfer is started using TCP/IP in tested timeslot with coding scheme CS3 (2TS DL + 2TS UL) in the case in both UL and DL directions along with EGPRS data transfer (2TS DL + 2TS UL). The user data rate is monitored. Data transfer is repeated with coding scheme CS4 in both UL and DL directions along with EGPRS data transfer. File Size: 1 Mb in DL, 100 Kb in UL

The data is transferred with BER of 0%. The expected data rates for the coding scheme are achieved. (CS-3 approx. 15.6kbit/s per timeslot used and CS-4 is approx. 21.4kbit/s per timeslot). For EGPRS data transfer A-bis shows MCS-9 is in use and transfer maintains an end-user data rate of at least 48Kbps per timeslot. In the PCU Master data frame the values for Coding scheme & RX level are verified to be reliable.

When the data transfer is complete ,a circuit switched speech call is again established and verified in the same tested timeslot.




Packet data transfer is again started using TCP/IP in tested timeslot with coding scheme and direction as defined above.


CS3&4

DN0694168 Issue 1-0


201 (252)


BTS Channel Configuration

Hopping

Object Administration Command

3 2+2+2 IDD/4UD, BB2F

MBCCHC + TCHF BB --Sector Lock/Unlock from BSC

Purpose: The purpose of these cases is to verify that GPRS data transfer using CS3 and CS4 coding scheme cannot be done when EDAP is not in Use but Data transfer using CS1&2 coding scheme is successful.


Input Expected Output Use configuration as defined in the case. EDAP is not defined. Using ZEQV MML command check the GPRS coding schemes.

GPRS coding schemes CS3 and CS4 is not available for selection.

Packet data transfer is started using TCP/IP in tested timeslot with coding scheme CS1 in both UL and DL directions. The user data rate is monitored. Data transfer is repeated with coding scheme CS2 in both UL and DL directions. File Size: 1 Mb in DL, 100 Kb in UL

The data is transferred with BER of 0%. The expected data rates for the coding scheme are achieved. (CS-1 approx. 9.05kbit/s per timeslot used and CS-2 is approx. 13.4kbit/s per timeslot). In the PCU data frame the values for Coding scheme & RX level are verified to be reliable.

Case Ref.


4 Multi TRX EDGE HW, BB2F

MBCCH+SDCCH+ TCHF

Purpose: The purpose of these cases is to verify that GPRS data transfer using CS3 and CS4 coding scheme is successful . Verify that speech call can be made before and after data transfer on same GP timeslot.





A Circuit switched speech call is established and checked in the GP timeslot to be tested. The call is released.


Packet data transfer is started using TCP/IP in tested timeslot with coding scheme as defined in the case in both UL and DL directions. The user data rate is monitored. At least 3 times transfer should be made to get a reliable figure on throughput. File Size: 1 Mb in DL, 100 Kb in UL








Case Ref.

BTS/Channel Configuration

GP TRX Coding Scheme /TS

Hopping Object Administration Command

5 2+2+2 TSxB11/TSxB12, BB2E/BB2F / MBCCH+SDCCH +TCHF

BCCH CS3&4 BB Sector Lock/Unlock

Purpose: The purpose of these cases is to prove that GPRS data transfer using CS3 and CS4 coding scheme is successful with or without EGPRS data transfer in both UL and DL direction on Single GP Time slot.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled. Use CDED, CDEF and CMAX to enable 1 radio timeslots as GP TS.

CS3&4

DN0694168 Issue 1-0


203 (252)

Input Expected Output Packet data transfer is started using TCP/IP in tested timeslot with coding scheme CS3 in the case in both UL and DL directions with or without EGPRS data transfer as indicated in the test case. The user data rate is monitored. Data transfer is repeated with coding scheme CS4 in both UL and DL directions along with EGPRS data transfer. File Size: 1 Mb in DL, 100 Kb in UL

The data is transferred with BER of 0%. The data transfers are successful. The expected data rates for the coding scheme are achieved. (CS-3 approx. 15.6kbit/s per timeslot used and CS-4 is approx. 21.4kbit/s per timeslot) if GP time slot is not shared. In the PCU Master data frame the values for Coding scheme & RX level are verified to be reliable.

Case Ref.


Hopping mode EGPRS on same GP TS

6 4+4+4, BB2F MBCCH+SDCCH +TCHF

BB Hopping YES

7 Multi TRX EDGE

MBCCH+SDCCH+TCHF

Non Hopping NO

20.4 Paging Mode Purpose: The purpose of these cases is to prove that during GPRS data transfer using CS3 and CS4 coding scheme, mobile can be paged for MT voice call successfully. Also verify that data transfer resumes once call ends.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled.

Packet data transfer is started using TCP/IP in tested timeslot with coding scheme specified in the case in both UL and DL directions.

The data is being transferred with BER of 0%.


Paging command message is seen for the test mobile in Gb interface traces. At A-bis interface ‘Packet Paging Command ’ is seen. The speech call is established as normal.



Input Expected Output Speech call is terminated. MS is in Packet transfer mode and data transfer

resumes. Data transfer is successful.

Case Ref.


Hopping mode

Coding Scheme

1 Multi TRX EDGE HW

MBCCHC + TCHF BB Hopping CS3

2 Multi TRX EDGE HW

MBCCHC + TCHD AH Hopping CS4

20.5 MT SMS Purpose: The purpose of these cases is to prove that during GPRS data transfer, SMS can be sent to mobile successfully, also verify that data transfer continues successfully.



Packet data transfer is started using TCP/IP in tested timeslot with coding scheme specified in the case in DL direction.

The data is being transferred with BER of 0%.

Different lengths (including maximum character length 160)of SMS messages are sent to mobile. At A-bis link both GSM A-bis signalling and PCU frames are monitored..

The SMS messages to and from the mobile are routed via the GPRS network, rather than through the MSC to the SMSC. SMS shouldn’t get routed on SDCCH channel but through LLC layer on SAPI 7. (Can be seen in LLC layer traces) Data transfer is not affected and is successful.

Case Ref.


Hopping Coding Scheme

CS3&4

DN0694168 Issue 1-0


205 (252)

Input Expected Output 1 Multi TRX

EDGE HW MBCCHC + TCHF, GP is on BCCH TRX

BB CS3

2 Multi TRX , EDGE HW

MBCCHC + TCHF, GP is on Non BCCH TRX

Non CS4

20.6 GPRS and EGPRS TBF’s on one time slot

Purpose:

The purpose of these tests is to check that GPRS and EGPRS TBFs can exist on the same radio timeslot. To check that the correct CS & MCS is used when this happens.

Note 113. The PCU sends a PACKET UPLINK (or DOWNLINK) ASSIGNMENT for each MS. These messages assign a different TFI to each MS. The uplink assignment also assigns a USF to each MS. The USF in the header of the downlink RLC Data Blocks indicate which TBF may transmit in the uplink

The PCU restricts the MCS used for a downlink EGPRS TBF to a GMSK coding scheme when an uplink GPRS TBF shares the same radio timeslot. It does this so that the uplink GPRS MS can read the USF information in the downlink TBF’s header.

Test Tools Required: Signal Generator, spectrum Analyser



Input Expected Output This test case must be performed with SGSN ciphering off or on, as shown in the table. Choose three MS so that the RLC Mode = Acknowledged. The MS must have the same priority set at the HLR. MS1 = EGPRS MS2 = EGPRS MS3 = GPRS. Use any base station configuration. EDAP Pool with 3 TS is configured and attached to the GPRS Enabled TRX. EGPRS on only one TRX is enabled. Lock all traffic timeslot so that only one (E) GPRS timeslot remains available for use. Set Link Adaptation = on for both GPRS and EGPRS. (To do this for GPRS: Use the MML command ZEQV to set the following parameters to the values shown: DLA = 5%, ULA = 5% DLB = 10%, ULB = 10%, DLBH = 10%, ULBH = 10% COD = 0, CODH = 0 (GPRS link adaptation used). ELA=1(EGPRS link adaptation used).) Set up Carrier / Interference (C/I) conditions in the air interface for all MS. Set C/I > 27 dB. (Setup is shown in Appendix B)

CS3&4

DN0694168 Issue 1-0


207 (252)

Input Expected Output (E) GPRS attach each MS in turn to the sector. Activate a PDP Context for each MS in turn. Monitor the A-bis and record a trace Begin UDP data transfer of 2MB files in the direction shown for each MS: MS1 = uplink MS2 = downlink Begin UDP data transfer of a 2MB file with MS3 = uplink.

All the MS attach successfully. All MS activate a PDP Context successfully. Both MS begin transfer successfully using predominantly MCS-9. The TBFs for all three MS are successfully shared on the one timeslot. The coding scheme used for the downlink transfer (MS2) will alternate between GMSK and 8PSK. In the uplink the following coding schemes are predominantly used: MS1 = MCS9 MS3 = CS4

Case. Ref

BCCH/TCH Configuration SGSN Ciphering

(E) GPRS Enabled TRX

1 MBCCH+SDCCH/TCHDs ON Non BCCH

20.7 CS-3 & CS-4 Data transfer with IDD/4UD & IDD BBH configuration

Purpose:

The purpose of these tests is to check that GPRS data transfer can be performed correctly when IDD/4UD & IDD BBH Configuration is in use.

Note 114. The 4-way diversity parameter is set from BTS Manager during commissioning and diversity is ON at BSC. There are no parameters or definitions at the BSC, only IDD main TRXs and normal non-IDD TRXs are defined to the BSC. When defining TRXs to the BSC, the IDD configuration at the BTS site has to be known by the operator in order to define correct TRXs to BSC.

Test Tools Required: Spectrum Analyser



Input Expected Output Use configuration as defined in the case. At least 12 timeslots are configured to be GPRS enabled. EDAP Pool with 4 TS is configured and attached to the GPRS Enabled TRXs. Set the Coding Scheme as shown in the table below. A circuit switched speech call is established (Any call type can be used i.e EFR) and checked on all the GPRS timeslot. The calls are then released.

The circuit switched call is successful. After releasing the call, the timeslot regains synchronisation.

8 different Packet data transfer is started using 8 different MS in both uplink & downlink direction using Coding scheme as defined in the test. Atleast 1 Mb file is transferred for reliable results. The user data rate is monitored on each MS. Both TX and RX paths are checked from IDD main and auxiliary TRXs with a spectrum analyser.

The data is transferred with BER of 0%. The expected data rates for the coding schemes are achieved for each transfer. (CS-3 approx. 15.6kbit/s per timeslot used and CS-4 is approx. 21.4kbit/s per timeslot). In the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable. The spectrum analyser indicates that mobile uses TX path from both main and auxiliary TRX. For RX paths (4-way diversity), that any path single or combination of RX paths can be used.



Case Ref.

HW Configuration Hopping Mode


1 2+2, IDD with 4UD Not used CS-3

2 4 Omni with IDD only / BB2F BB Hopping CS-4

20.8 GPRS Link Adaptation

Purpose:

To check that GPRS link adaptation selects the coding scheme (CS1, CS2, CS3, CS4) appropriate for the air interface conditions. To check that Dynamic A-bis allocates a slave subTS when CS4, CS3, CS2 is selected by GPRS link adaptation.

Test Tools Required: Spectrum Analyser, Signal generator

CS3&4

DN0694168 Issue 1-0


209 (252)

Input Expected Output Dynamic A-bis is enabled. Set Link Adaptation = on for both GPRS and EGPRS. (To do this for GPRS: Use the MML command ZEQV to set the following parameters to the values shown: DCSA=7,UCSA=7(GPRS link adaptation used) , ELA=1(EGPRS link adaptation used).) Use any EDGE sector with 3 or more TRX. EGPRS must be enabled in the Sector. Establish a Carrier / Interference (C/I) ratio > 27dB in the air interface, in the direction shown in the table. Use a GPRS MS and set RLC Mode = Acknowledged for this MS.

Attach the MS to the sector and activate a PDP Context. Transfer a 500K file in the direction shown in the table below. Monitor the A-bis for the coding scheme used. Deteriorate the radio conditions to C/I = 0dB. Improve the radio conditions to C/I > 27dB. Repeat the C/I cycle a further 2 times.

MS attach and PDP Context activation is successful. The PCU MASTER DATA FRAME indicates that CS4 is used. Dynamic A-bis allocates one slave frame. As the radio conditions deteriorate the CS being used should change from CS4 to CS3 to CS2 and finally to CS1 (For CS2 & 3 one slave frame will be allocated). No slave frames are allocated when CS1 is in use. The PCU MASTER DATA FRAME indicates that CS4 is used again. Dynamic A-bis allocates one slave frame. The coding scheme switches as expected.

When the data transfer is complete a circuit switched speech call is established and verified in the same tested timeslot.



Case. Ref Direction Hopping Mode 1 Downlink Not used

2 Uplink BB Hopping

20.9 Data Transfer with A-bis Failure Purpose:

The purpose of these cases is to prove that multiple short duration A-bis link failures are handled correctly during CS-3 & CS-4 data transfer.



Test Tools Required: Abis Breaker

Input Expected Output Use Any configuration. Dynamic A-bis is enabled. Set the Coding Scheme as shown in the table.

All BCCH TRX timeslots are configured to be GPRS enabled, using default GPRS capacity on BCCH TRX. Setup GPRS data transfer using TCP/IP protocol in specified direction. At least a file size of 5 MB is transferred for reliable results. For a period of 10 seconds the whole A-bis is disrupted with random short (<0.5 s) breaks The link is then left connected until the link recovers. Repeat the above atleast 3 – 5 times during the transfer Terminate data transfer

The data transfer is started. The data transfer is interrupted when there are breaks in A-bis interface. After the link recovers, PCU frame resynchronises. Data continues to transfer. Data Transfer is interrupted but resumes when the link is connected again. Data transfer is completed successfully. (Very occasionally the A-bis may be broken while the BSC is polling the BTS. This will cause the LAPD to drop and the air interface to be disabled. It may take over 30 sec to recover the site once the A-bis is reconnected. During this time the TCP/IP connection will probably be dropped. It may also be necessary to re-activate the PDP Context)

Case Ref.

Direction Coding Scheme in use

1 Uplink & Downlink simultaneously CS-3


20.10 Data Transfer with Air Interface Failure

Purpose:

The purpose of these cases is to prove that multiple short duration Air Interface failures are handled correctly during CS-3 & CS-4 packet data transfer.

CS3&4

DN0694168 Issue 1-0


211 (252)


Input Expected Output Use Any configuration. Dynamic A-bis is enabled. Set the Coding Scheme as shown in the table.

Setup GPRS data transfer using TCP/IP protocol in specified direction. At least a file size of 5 MB is transferred for reliable results. Monitor A-bis interface

The data transfer is started. In the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable.

Break air interface (UL/DL) for a period of 7 sec (based on counter N3101 and timer T3169 values). Repeat this above at least 2 – 3 times during data transfer

TBF will release and when re-established the TCP protocol will request data retransmission, a new TBF is established P-CHANNEL REQUIRED or PACKET CHANNEL REQUEST message is seen on the A-bis) and data transfer continues.

For Case Ref. 1, UDP/IP protocol type shall be used for transferring data.

Resources are released, a new TBF is not established.

Case Ref.

Direction Coding Scheme in use



20.11 Cell Reselection & Timing Advance with GPRS CS-3&4

Purpose:

Check cell reselection functions correctly with GPRS CS-3&4 data transfer and timing advance. Check that combined IMSI/GPRS attach can be performed with timing advance. Check cell reselection can be performed from one routing area & location area to another.



Test Tools Required: Fading Simulator, Spectrum Analyser, and Signal Generator

Input Expected Output Use any configuration for BTS1 & as mentioned in the table below. Set the Coding Scheme as shown specified. Dynamic A-bis is enabled. Hopping mode is set as specified. Timing advance is applied to BTS 1 only. BA list is created containing BTS1 & BTS2 BCCH frequencies. The 2 BTS’s have a different Routing Area (RA) or Location Area (LA) when specified.

Turn on GPRS mobile and attach to the specified BTS. Set up GPRS data transfer in specified direction-using data file big enough for 10 cell reselections

Mobile performs combined IMSI/GPRS attach. The transfer can be established on the source cell. MS uses one slave frame from EDAP Pool during data transfer.

Use an adjustable attenuator to cause cell reselection during the data transfer. The A-bis TRX links and PCU MASTER DATA FRAMEs are monitored on source and target cells. A-bis traces are recorded. The reselection between cells is made at least 10 times for each case.

The Reported TA value is correct in both Source cell and Target cell. Post analysis of Abis trace shows coding scheme used in both source and target cells as specified. The TA value can be observed from the PCU Random Access Frame and Immediate Assignment command The user data rate does not degrade after reselection procedure.

For case ref 2, an interference is to be applied in target cell such that C/I is set to 15 dBm

Case Ref.

Direction Hopping Mode (BTS1 / BTS2)

RA/LA Attach To Timing Advance(BTS Only)

Coding Scheme

CS3&4

DN0694168 Issue 1-0


213 (252)

Input Expected Output 1 Uplink Non-

Hop / Non-Hop

BTS1 20 Km CS-3

2 Downlink BB Hop / RF Hop

LA BTS2 30 Km CS-4

20.12 Cell re-selection Purpose: To check that cell reselection functions correctly with CS3 and CS4 data transfer and timing advance.

To check that cell reselection can be performed from one routing area to another.

Test Tools Required: Fading Simulator, Spectrum Analyser, and Signal Generator

Input Expected Output Use configurations for Source cell & Target Cell as defined in the test case. Dynamic A-bis is enabled. Enable GPRS Link Adaption Timing advance is applied as specified. BA list is created containing Source cell & Target Cell BCCH frequencies. The 2 Cell’s have a different Routing Area (RA) when specified.

Turn on GPRS mobile and attach to the specified BTS. Set up GPRS data transfer in specified direction- using data file big enough for 10 cell reselections..

Mobile performs combined IMSI/GPRS attach The transfer can be established on the source cell.



Use an adjustable attenuator to cause cell reselection during the data transfer. The A-bis TRX links and PCU MASTER DATA frames are monitored on source and target cells. A-bis traces are recorded. The reselection between cells is made at least 10 times for each case.

For test case 2.2.5 , an interference is to be applied in target cell.

Data transfer continues after cell reselection onto target cell. The Reported TA value is correct in both Source cell and Target cell. Post analysis of Abis trace shows coding scheme used in both source and target cells as specified. The TA value can be observed from the PCU Random Access Frame and Immediate Assignment command.

Case Ref. Direction of data transfers

Configuration


Source Cell (Hopping/TA/ Coding Scheme)

Target Cell (Hopping/TA/ Coding Scheme)

1 Uplink Multi TRX, EDGE HW

MBCCHC + TCHF

Non-hopping / 0km / CS-3

RF-hopping / 0km / (CS3 & CS4 is enabled) (LA enabled)

2 Uplink Standard E-Cell

MBCCHC + TCHF

Non-hopping / 0km / CS-3

RF-hopping / 0km / (CS3 & CS4 is enabled) (LA enabled)

3 Downlink Multi TRX EDGE HW MBCCHC +

TCHF, AH-hopping1 / 15km / CS-4

Non-hopping / 10km / (CS-3 & CS4 is enabled)(RA is different) (LA enabled, CS3 is selected due to interference)

1 Use ARFCN 0 in source cell.

CS3&4

DN0694168 Issue 1-0


215 (252)

20.13 GPRS CS3&4 Reliability at Various MS Speeds

Purpose: The purpose of these cases is to prove that GPRS data transfer with CS3&CS4 does not fail when the MS speed increases up to 200Km/h. Link Adaptation and Incremental Redundancy should cope with this without data transfer failing completely.

Test Tools Required: Fading Simulator, Signal Generator and Spectrum Analyser

Input Expected Output Use any configuration. Dynamic A-bis is enabled. Choose a GPRS MS such that RLC Mode should be Acknowledged RLC Mode. Set the Coding Scheme as shown in the table. Use the MML command ZEQV: BTS=##: BLA=50; (To set the max. Limit for block error rate to 50%.) Establish C/I conditions in the air interface so that C/I > 27dB.

Packet data transfer is started with coding scheme and direction as specified in the case with GPRS mobile travelling at speeds of 5km/h, 30km/h, 80km/h and 200km/h in each case. GPRS data call is held for at least 5 minutes with the MS moving to / from the BTS starting with TA values of 0 & 35km. The user data rate is monitored File Size: 1 Mb in DL, 100 Kb in UL (Re-start sending the files till the test case is complete)

The data transfer is started successfully. As MS speed increases the reported BEP increases. Link Adaptation responds accordingly and Incremental Redundancy recovers blocks successfully. In the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable. Data transfer is successful. The expected data rates at the end of the transfer for the coding schemes are achieved for each transfer. (CS-3 approx. 15.6kbit/s per timeslot used and CS-4 is approx. 21.4kbit/s per timeslot).

Compare the received file(s) with the sent file(s).

The file(s) received is identical to the file(s) sent.



Input Expected Output Case Ref. Direction Protocol

used GPRS Enabled TRX


1 Uplink & Downlink

TCP/IP Non BCCH CS-3

2 Uplink & Downlink

UDP/IP Non BCCH CS-4

20.14 GPRS CS-3&4 Reliability at Various Distances

Purpose: To check that data transfer does not fail when the MS distance varies over the full range (0 to 35 Km). To check that random access bursts are successfully received over the full range of timing advance values.

Test Tools Required: Fading Simulator, Signal Generator and Spectrum Analyser

Input Expected Output Use any configuration. Dynamic A-bis is enabled. Choose a GPRS MS such that RLC Mode should be Acknowledged RLC Mode. Set the Coding Scheme as shown in the table. Use the MML command ZEQV: BTS=##: BLA=90; To set the max. Limit for block error rate to 90% (this is the default value). Establish C/I conditions in the air interface so that C/I > 27dB.

CS3&4

DN0694168 Issue 1-0


217 (252)

Input Expected Output Promptly begin the transfer of a 5 MB file using the transfer protocol and direction as mentioned for the test. Use number of timeslots as shown in the table. During the data transfer, start varying the distance from 0-35km or 35-0 km depending upon the case requirement. Monitor the A-bis interface. As the transfer of one file completes, promptly begin the transfer of a new 5 MB file. Repeat this process until the MS reaches a distance of 0 Km (if MS is moving towards BTS) or 35 Km (if MS is moving away from BTS) . (Re-start sending the files till the test case is complete)

Data transfer begins successfully and continues without breaks. Timing Advance value is verified from the Abis Traces and should be corresponding to the distance of the MS. In the PCU MASTER DATA FRAME the values for Coding scheme & RX level are verified to be reliable. Each new file transfer begins successfully. The correct timing advance is shown at the A-bis.

The user data rate is monitored

The expected data rates at the end of the transfer for the coding schemes are achieved for each transfer. (CS-3 approx. 15.6kbit/s per timeslot used and CS-4 is approx. 21.4kbit/s per timeslot).

Compare the received file(s) with the sent file(s).

The file(s) received is identical to the file(s) sent.

Case Ref.

Direction

No. of Timeslots

Start Dist Travel Protocol used


1 Uplink 1 35Km Towards BTS

TCP/IP CS-4

2 Downlink

1 0Km Away from BTS

UDP/IP CS-4

20.15 GPRS Territory Upgrade/Downgrade with CS3&4

Purpose: To check that GPRS territory upgrade/downgrade is operational with GPRS To Check that one RTSL can support more than one TBF



Note 115. CSU and CSD parameters at the BSC (command: ZEEM) may need changing in order to cause GPRS upgrade/downgrade

The parameter free TSL for CS downgrade (CSD) defines a margin of radio time slots that the BSC tries to preserve idle for circuit switched traffic by downgrading the GPRS territory when necessary.

Free TSL for CS upgrade (CSU) defines the number of radio time slots that has to remain idle in the circuit switched territory after the planned GPRS territory upgrade has been performed.


Input

Expected Output

Any configuration is used. Lock RTSL of all the TRX but except for one TRX having GP timeslots (which is under test). GPRS Coding Scheme as mentioned in the test is configured for the BTS under test. Enable EGPRS for testcase3.

Set up CS speech calls until only one timeslot (GP TS) remains idle (Any call type can be used i.e. EFR, FR, AFS, AHS). GPRS Attach the two MS to the Sector and PDP Context is created. Set up two GPRS TCP/IP data transfers. (File Size 1Mb).

GPRS Attach & PDP Context is successful. Both data transfers begin successfully (two TBF's on one timeslot).

Terminate CS speech calls one by one, until (E) GPRS territory upgrade is performed. Set up CS speech calls one by one, until GPRS territory downgrade is performed.

Existing GPRS data calls no longer share one RTSL GPRS data calls return to sharing one timeslot. Data transfers are successful.


Case Ref.



GPRS Enabled TRX


1 Uplink Uplink BCCH CS-3

2 Downlink Downlink BCCH CS-4

3 Downlink Downlink Any CS3/CS41

CS3&4

DN0694168 Issue 1-0


219 (252)

1 Standard Ecell conf,Data transfer in N-Area,

20.16 TRX Loop Test with CS3&4

Purpose: To check that following TRX loop test runs with modulation scheme CS3/CS4:

ABIS1/AIR1, ABIS3/AIR1, ABIS1/AIR3, ABIS1/AIR4, ABIS3/AIR4

Note 116. Acceptable test results are: BER<0.1%, FER<0.1%

Test Tools Required: Spectrum Analyser, CMU

Input

Expected Output

Use Any Multi TRX configuration. BTS is in Supervisory State with all the TRXs up and working. An MS-MS call is made using the TRX to be tested (Any call type can be used i.e. EFR, FR, AFS, AHS). Select from the TRX Loop Test Option from the BTS Manager, loop test type & coding scheme as defined in the test. Loop Test is started for the TS (Non control channel/traffic TS).

The loop test result indicates success. The test results are acceptable. TS carrying control channels and traffic are not tested. The calls are not affected.

The test is repeated for every TSs in the BTS in both BCCH and non-BCCH TRXs except those on which Calls are established. The colour of unit LED’s is verified at the BTS and the BTS manager equipment view.

The test is started for idle channels. TS carrying control channels and traffic are not tested. The calls are not affected. The colour of TSxx and BB2x units LED’s at the BTS and BTS manager are red during the test and return back to original colour when test finishes. The test results are acceptable. For AIR4 Loop Test CMD device is used as the results of the loop test are not displayed on the BTS Manager

Case Ref.

Channel Configuration/Cabinet type

Coding Scheme Selected

Loop test

1 ANY/UltraSite CS-3 ABIS1/AIR4

2 ANY/Any UltraSite CS-4 ABIS1/AIR4



3 ANY/Metro Site CS-3 ABIS1/AIR4

4 ANY/Metro Site CS-4 ABIS1/AIR4

CS3&4

DN0694168 Issue 1-0


221 (252)

20.17 Dynamic Abis Allocation with CS3&4 Purpose: The purpose of these cases is to prove that (E)GPRS DL resource allocation functions correctly when EDAP resources are lacking.


Input Expected Output Use configuration as defined in the case. Configure EDAP as mentioned in the test case below. Use CDED, CDEF and CMAX to enable radio timeslots as GP TS as specified in the test case. (E)GPRS link adaptation is enabled.

Set up (E)GPRS data transfer(s) in downlink direction (on 2 radio timeslots) as specified in test case. Monitor A-bis Continue to set up additional (E)GPRS data transfers as specified in the test case.

Data transfer begins. A-bis shows CS-4 in use for GPRS data transfer and MCS 9 for EGPRS data transfer. All data transfers are set up. Lower (M)CS's are used instead of the CS-4 and MCS-9 due to the lack of EDAP TS's. Therefore data rates are reduced.

Case Ref.


Data transfer

Additional data transfer

No. of A bis TS in EDAP

No. of GP RTSL

1 Multi TRX EDGE HW

MBCCHC + TCHF

GPRS only

Three GPRS –

1 8

2 Multi TRX EDGE HW

MBCCHC +TCHF

GPRS and EGPRS

Three -GPRS, Two-EGPRS

3 14



Purpose: The purpose of these cases is to prove that (E)GPRS UL resource allocation functions correctly when EDAP resources are lacking.


Input Expected Output Use configuration as defined in the case. Configure EDAP as mentioned in the test case below. Use CDED, CDEF and CMAX to enable radio timeslots as GP TS as specified in the test case. (E)GPRS link adaptation is enabled.

Set up (E)GPRS data transfer(s) in uplink direction (on one radio timeslot) as specified in test case. Monitor A-bis Continue to set up additional (E)GPRS data transfers as specified in the test case.

Data transfer begins. A-bis shows CS-4 in use for GPRS data transfer and MCS 9 for EGPRS data transfer. All data transfers are set up. A-bis shows CS-4 in use for GPRS data transfer and MCS 9 for EGPRS data transfer. The data rates are reduced to due to uplink scheduling

Case Ref.


Data transfer

Additional data transfer

No. of TS in EDAP

No. of GP RTSL

3 Multi TRX EDGE HW

MBCCHC + TCHF

GPRS only GPRS -7 1 8

4 Multi TRX EDGE HW

MBCCHC + TCHF

GPRS and EGPRS

GPRS-7, EGPRS - 2

3 11

CS3&4

DN0694168 Issue 1-0


223 (252)

Purpose: The purpose of these cases is to prove that the maximum sized EDAP functions correctly with (E)GPRS data transfers.


None

Input Expected Output Use configuration as defined in the case.

Configure 12 A-bis timeslots to the EDAP

Use the MML command ZEQV to set the following: CDED=10,CDEF=100,CMAX=100

(E)GPRS link adaptation is enabled.

Begin TCP/IP data transfers as specified in the test case. Begin the number of EGPRS and GPRS transfers shown in the test case so that the data transfers occur at the same time.

Monitor the A-bis for PCU MASTER DATA FRAMES and PCU SLAVE DATA FRAMES.

All data transfers continue successfully. EGPRS TBFs use MCS9, GPRS TBFs use CS4, nearly all of the time. Lower coding schemes may be seen, but only occasionally.

The Master Data Frame for each TBF points to the correct Slave Frames. All SubTS in the EDAP are allocated at some point during the transfer of data (although not necessarily simultaneously).

4 SubTS are allocated to each MCS9.

1 SubTS is allocated to each CS4.

All transfers proceed successfully. At some point in the transfer all the subTS are used simultaneously.

Case Ref. BTS Channel Configuration

Data transfer

No. of DL data transfer



Input Expected Output 5 4+4,

EDGE HW

MBCCHC + TCHF

GPRS (3RTSL)

GPRS-16

20.18 BTS Tests with CS3&4 enabled

Purpose: The purpose of this case is to have TRX test on GP time slot using GMSK while CS3/CS4 data transfer is on same timeslot and verify that it works correctly.


Input Expected Output Use configuration as defined in the case with coding scheme CS3 only. . Dynamic A-bis is enabled.

Packet data transfer is started using TCP/IP in GP radio timeslot with coding scheme CS3 in DL direction


The Tests | TRX Test command is selected from BTS manager. The TCH TRX, ARFCN number, and GP Radio Timeslot are selected and the test is started using GMSK modulation.

TRX test is not started on timeslot in use by GPRS data transfer. Data transfer is successful.

Now TRX test is started on a TCH TS which doesn’t have any Control channel or GP TS as its partner.

TRX test is successful.

Repeat the test case with CS4 coding scheme

Case Ref.


1 Multi TRX with EDGE HW MBCCHC +TCHF

Purpose: The purpose of this case is to prove that user can select any combination of the Loop test and the coding scheme but Invalid modulation schemes cannot be started.

CS3&4

DN0694168 Issue 1-0


225 (252)



The Tests | TRX loop Test command is selected from BTS manager. The TCH TRX, Timeslot and GMSK CS3 modulation method are selected. Execute the TRX loop test using Invalid loopback points (e.g. ABIS 2 \ AIR 1).

The O&M SW returns an error message that the test is not supported with this modulation scheme (e.g. ABIS 2 \ AIR 1).

Repeat the test case with GMSK CS4 modulation method.

Case Ref.


2 Multi TRX EDGE HW MBCCHC+TCHF

20.19 Intelligent Shutdown with CS3&4 enabled

Purpose: To verify that Data transfer with CS3 coding schemes continues before and after the site enters in BCCH shutdown mode.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled. Use BCCH Shut down mode.

Packet data transfer is started using TCP/IP in GP radio timeslot with coding scheme CS3 in DL direction.




Input Expected Output The mains breakdown alarm is generated. The BSC starts the NTIM Timer. The set time for the NTIM timer expires.

Alarm ‘7995:MAINS BREAKDOWN WITH BATTERY BACK-UP’ is reported at the BSC and BTS Manager. Site enters in BCCH shutdown mode. As GP time slot is on BCCH TRX, GPRS data transfer continues and there is no break in GPRS services.

The mains breakdown alarm is cancelled Packet data transfer is started using TCP/IP in GP radio timeslot with coding scheme CS3 in DL direction.

The ‘7995:MAINS BREAKDOWN WITH BATTERY BACK-UP’ is cancelled at the BSC and BTS Manager. The BSC sends BTS_PWR_SUPPLY_CONTROL (switch on Non BCCH TRX) message to the BCF for each BTS. There is no service break for GPRS data transfer. All non BCCH TRXs comes up in working state. Data transfer is successful.

Case Ref.


1 Multi TRX EDGE HW MBCCHC + TCHF, GP is on BCCH TRX

Purpose: To verify that PCU synchronises and Data transfer using coding schemes CS4 is successful after site recovers from NONE shutdown mode.


Input Expected Output Use configuration as defined in the case. Dynamic A-bis is enabled. Use NONE shutdown mode.



CS3&4

DN0694168 Issue 1-0


227 (252)

Input Expected Output The mains breakdown alarm is generated. The BSC starts the NTIM Timer. The set time for the NTIM timer expires.

Alarm ‘7995:MAINS BREAKDOWN WITH BATTERY BACK-UP’ is reported at the BSC and BTS Manager. Site enters in BCCH shutdown mode. , BSC reconfigures GP Time Slot(s) on BCCH TRX. PCU FRAME SYNCHRONISATION Messages will be seen for new GP Time Slot(s) and GPRS data transfer will continue after PCU Frame Synchronisation is done

The BSC starts the BTIM Timer. The set time for the BTIM timer expires.

Site enters in None shutdown mode and all TRXs go in BL-PWR state. GPRS data call is dropped.

The mains breakdown alarm is cancelled The ‘7995:MAINS BREAKDOWN WITH BATTERY BACK-UP’ is cancelled at the BSC and BTS Manager. The BSC sends BTS_PWR_SUPPLY_CONTROL (switch on each TRX) message to the BCF for each BTS. Site recovers successfully and PCU synchronises.


Data transfer successful.

Case Ref.


2 Multi TRX EDGE HW MBCCHC + TCHF, GP is on non BCCH TRX

20.20 Extended Cell with CS3&4 enabled

Purpose: The purpose of these cases is to verify that Data transfer with CS3&4 coding schemes is successful in N-Area of E-Cell configuration.

Test Tools Required: None.




Using N-TRX a Circuit switched speech call is established on the GP timeslot to be tested. The call is released.


Packet data transfer is started using TCP/IP in tested timeslot with coding scheme as defined in the case in both UL and DL directions. The user data rate is monitored. At least 3 times transfer should be made to get a reliable figure on throughput. File Size: 1 Mb in DL, 100 Kb in UL


When the data transfer is complete, a circuit switched speech call is again established and verified in the same tested timeslot.






Case Ref.

BTS Channel Configuration Coding Scheme

Object Administration

1 4 Omni EDGE(2N-TRX and 2 E-TRX)

MBCCHC + TCHF , GP is on BCCH TRX

CS3 TRX Lock/Unlock

2 4 Omni EDGE(2N-TRX and 2 E-TRX)

MBCCHC + TCHF , GP is on BCCH TRX

CS4 TRX Block/Unblock from BTS manager

20.21 LAPD Failure Purpose: To verify that Data transfer with CS4 coding schemes is successful after the BCCH and GP is reconfigured to different TRX due to LAPD failure.


CS3&4

DN0694168 Issue 1-0


229 (252)




The BCCH TRX is marked as preferred GPRS TRX in the cell. The BCCH TRX signalling link is blocked with the MML command ZDTC.

Alarm 7705 LAPD FAILURE is activated at the BSC. The TRX is blocked at the BSC. A BCCH and GP Time slot reconfiguration is performed.



Case Ref.


1 4+4+4 EDGE HW MBCCHC + TCHF, GP is on BCCH TRX



21 Ghost RACH and PRACH testing

21.1 Ghost RACH and PRACH Absolute Test

Purpose: To check that the rate at which the base station generates ghost (P)RACH messages is below an acceptable level.

Note 117. During the lifetime of a software release a small sub-set of the tests below should be periodically performed to monitor the number of ghosts that are being generated. This is because improvements in the receiver performance during the release will affect the ghost performance as well. Towards the end of release testing, once the final fine tuning of the EQDSP has been carried out, a comprehensive set of tests must be performed.

Note 118. The process of detecting RACHs and PRACH burst is the same for non-combined and combined BCCH configurations. Because there are more TDMA frames within the multiframe available to listen for RACHs in the non-combined BCCH the number of ghost generated will always be greater. In other words, an acceptable result for MBCCH will inevitably mean an acceptable result for MBCCHC. For this reason MBCCHC is not tested on its own.

Note 119. Because the antennas in this test are terminated with loads in this test, the base station should not detect any real (P)RACHs. Only internally generated noise that is detected as having a valid training sequence should result in a low level of ghost (P)RACHs.

Note 120. Because the generation of ghost (P)RACHs is essentially a random process, and because the number of ghosts expected is a very small proportion of all frames that the receiver listens for, it is important to monitor a sufficient number of BCCH channels for a long enough period in order to obtain a meaningful result.

Ghost RACH and PRACH testing

DN0694168 Issue 1-0


231 (252)

Input Expected Output Create the configuration indicated in the table and shown in the diagrams below. Ensure all RF cables are correctly torqued. Configure the BCCH as indicated in the table and the remaining timeslots as shown in Table 5. Set the ARFCN as shown in Table 6, Table 7, Table 8 or Table 8 depending on the config indicated.

Set Cell Bar = Y using MML command: ZEQF:BTS=<bts number>:BAR=Y;

Create an EDAP and enable GPRS and EGPRS. Set diversity as shown in the table using MML command: ZEQM:BTS=<bts number>:RDIV=<Y or N>; Commission the site and bring it into working order.

Maximise the number of paging blocks in the multiframe, and reduce number of multiframes before paging group is repeated using the MML command: ZEQJ:BTS=<bts number>:AG=1,MFR=2; Use a script to generate paging on each paging block on the CCCH.

50 ohm, 50W terminating loads must be put on each antenna. Firmly close the door of the cabinet.

Set up an A-bis monitor to trace the channels indicated in Table 10.

Record traces every 24 hours for a total of 72 hours.

Analyse the traces and count the messages indicated in Table 10 for each type of BCCH. Calculate the number of ghosts per BCCH channel per 24 hour period in the following way: total num messages in elapsed time for all BCCH channels of same type Ghosts = ------------------------------------ Num 24hr periods x num BCCH channels

The number of Ghosts/BCCH/24 hours is below the acceptance limit indicated in the table.



Case Ref. Config Band BCCH type RDIV Acceptance Limit Ghosts per channel per 24 hours

1 Figure 8 800 MBCCH only Y 50

2 Figure 8 800 MBCCH only1 Y 50

3 Figure 8 1800 MBCCH only N 20

4 Figure 9 900 MBCCH only Y 50

5 Figure 9 900 MBCCH only1 Y 50

6 Figure 10

1900 MBCCH only Y 50

7 Figure 11

800 MBCCH only N 20

8 Figure 11

900 MBCCH only Y 50

9 Figure 11

900 MBCCH only1 Y 50

10 Figure 11

1800 MBCCH only Y 50

11 Figure 11

1900 MBCCH only N 20

1 Enable STIRC

Table 5. Timeslot Configuration for Each BCCH Type

MBCCH only MBCCHC 0 MBCCH MBCCHC 1 SDCCH SDCCH 2 TCHF TCHF 3 TCHF TCHF 4 TCHF TCHF 5 Gp Gp 6 Gp Gp 7 Gp Gp

Table 6. ARFCN to Set for DVxx Config (Figure 8)

Sector 800 900 1800 1900

1 128 1 512 512

2 153 25 587 572

3 177 50 662 632

4 202 75 737 692

5 226 100 812 752

6 251 124 885 810


DN0694168 Issue 1-0


233 (252)

Table 7. ARFCN to Set for RTC Config (Figure 9

Sector 800 900 1800 1900

1 128 1 512 512

2 251 124 885 810

Table 8. ARFCN to Set for 4UD Config (Figure 10)

Sector TRX 800 900 1800 1900

1 153 25 587 572 1

3 177 50 662 632

5 202 75 737 692 2

7 226 100 812 752

Table 9. ARFCN to Set for MetroSite (Figure 11)

Sector 800 900 1800 1900

1 153 25 587 572

2 177 50 662 632

3 202 75 737 692

4 226 100 812 752

Table 10. Messages and Channels to Monitor on A-bis

BCCH

Channels Messages

MBCCH TRXsig A-bis TS for each BCCH TRX Stack = GSM A-bis

CHANNEL REQ P-CHANNEL REQ EGPRS PACKET CHANNEL REQUEST

MBCCHC TRXsig A-bis TS for each BCCH TRX Stack = GSM A-bis




Figure 8

50 ohm, 30Watt load fitted to each antenna

Door Closed

1+1+1+1+1+1 Bypass configuration, but cabled in pairs for 2 way diversity. All TRX in the same band.

UltraSite with DVxx


DN0694168 Issue 1-0


235 (252)

1. Figure 9

2.


1+1 RTC configuration, cabled for 2 way diversity. All TRX in the same band. Put 50 ohm terminators on unused RF ports.

UltraSite with RTC

Door Closed



Figure 10


Door Closed

2 + 2 4UD Bypass configuration. All TRX in the same band.

UltraSite with 4UD


DN0694168 Issue 1-0


237 (252)

Figure 11

21.2 Ghost RACH and PRACH Relative Test

Purpose: To check that the rate at which the base station generates ghost (P)RACHs has not significantly increased compared to the previous software release.

Note 121. Because the generation of ghost (P)RACHs is essentially a random process, and because the number of ghosts expected is a very small proportion of all frames that the receiver listens for, it is important to monitor a sufficient number of BCCH channels for a long enough period in order to obtain a meaningful result.

Note 122. In these tests two identical base station configurations run different software packages. Because the antennas are shared in these tests the base stations should be listening to the same noise. By swapping the software packages half way through the test, the affects of hardware differences should be removed.


1+1+1+1 configuration, but cabled for 2 way diversity. All TRX in the same band.

MetroSite Config for Absolute Ghost Test



Input Expected Output Create the configurations indicated in the table and shown in the diagrams below. Choose either 1800 or 1900 band. Configure the BCCH as indicated in the table and the remaining timeslots as shown in Table 11. Set the on both BCF to the ARFCN as shown in Table 12. Set Cell Bar = Y using MML command: ZEQF:BTS=<bts number>:BAR=Y;

Create an EDAP and enable GPRS and EGPRS. Enable diversity using MML command: ZEQM:BTS=<bts number>:RDIV=Y; Set the BTS power to minimum using MML command: ZEUG:BTS=<bts num>:PMAX1=30,PMAX=30, PMIN=30; Make the default package on the first BCF the most recent released version of the software under test. Make the default package on the 2nd BCF the latest pre-release of the release under test.

Ensure that the hardware for each base station is as identical as possible (units, cable lengths and types, splitter types, attenuator types etc.). Ensure all RF cables are correctly torqued. Commission the sites and bring them into working order

Switch off all mobile stations within 20 metres of the base stations.

Set up an A-bis monitor to trace the channels indicated in Table 13.

Record traces for 24 hours. Swap the software packages over so that the previous release is on the 2nd BCF and the new release is on the 1st BCF.

Record traces for a further 24 hours.


DN0694168 Issue 1-0


239 (252)

Analyse the traces and count the number of messages indicated in Table 13. Do NOT count those (P)RACHs that lead to successful channel activations (i.e. real Location Updates etc.) Calculate the number of ghosts per BCCH channel per 24 hour period in the following way: total num messages in elapsed time for all BCCH channels of same type Ghosts = ------------------------------------ Num 24hr periods x num BCCH channels

Compare the results for the two software packages.

The Ghosts/BCCH/24hr must not have increased by more than 10%.i.e. New SW ≤ 1.1 x Previous released package

Case Ref. Config. BCCH Type 1 Figure 12 MBCCH only

2 Figure 12 MBCCHC

3 Figure 13 MBCCH only

4 Figure 13 MBCCHC

Table 11. Timeslot Configuration for Each BCCH Type

MBCCH only MBCCHC 0 MBCCH MBCCHC 1 SDCCH SDCCH 2 TCHF TCHF 3 TCHF TCHF 4 TCHF TCHF 5 Gp Gp 6 Gp Gp 7 Gp Gp

Table 12. ARFCN to Set

Sector 1800 1900

1 512 512

2 636 611

3 760 710

4 885 810



Table 13. Messages and Channels to Monitor on A-bis

BCCH

Channels Messages

MBCCH TRXsig A-bis TS for each BCCH TRX Stack = GSM A-bis


MBCCHC TRXsig A-bis TS for each BCCH TRX Stack = GSM A-bis


Figure 12

1+1+1+1 Bypass configuration, but cabled in pairs for 2 way diversity. All TRX in the same band. Previous release software.

1+1+1+1 Bypass configuration, but cabled in pairs for 2 way diversity. All TRX in the same band. New software under test.

50 ohm, 30dB attenuators

Splitter/combiners

BCF 1 BCF 2

UltraSite Config for Relative Ghost Test


DN0694168 Issue 1-0


241 (252)

3. Figure 13

21.3 TRX Load Test Purpose: To check that the BTS remains stable when the TRX is in heavy load and under continuous traffic. To also verify that the traffic is handled successfully when the BTS is in heavy load.

1+1+1+1 configuration, but cabled for 2 way diversity. All TRX in the same band.

MetroSite Config for Relative Ghost Test

BCF 1 BCF 2

50 ohm, 30dB attenuators

Previous software release New software release



Input Expected Output Memory block reservations are checked before and after the test.

After the test, there are as many memory blocks reserved as there were before the test.

Ciphering is used. GPRS is enabled.

60% of the CS (AFS, AHS, EFR, FR, or HR) calls are set-up and left ongoing during the test case (Constant) unless otherwise stated in the test case. 40% of the CS (AFS, AHS, EFR, FR, or HR) calls defined in the test case are made using PC controlled MSs (Cyclic). Call duration is approximately 60 seconds unless otherwise stated in the test case. The calls are started and remain ongoing through out the test case. No. of short calls using PC controlled MS’s are started for these two test cases.

The static calls remain on during the whole testing. The call success rate is better than 99%. The data is transferred with BER of 0%. The expected data rates for the coding scheme are achieved.

Test duration is 4 hours.

Case Ref.

Site Type

Sector Configuration


TRX Sig. Speed

Hopping Mode in All Sector

Call Types

1 Nokia MetroSite 2+2

Sector 1: EDGE Sector 2: GSM

(MBCCHC, SDCCH, 3*TCHD, 3 TS reserved for (E)GPRS) + (8*TCHD)

16kbit/s BB-Hopping

4 HR (2 TSs), 6 FR (6 TSs), 1 HSCSD (3 TSs), 3 GPRS (3 TSs) data calls (14.4 kbit/s) with file transmission larger than 10 MB. 3*Data transfer from a (E)GPRS phone (2*download a file larger than 10 Mb, 1*upload a file larger than 10Mb. Downloading/Uploading to be repeated during test period) Sector 1: EGPRS Sector 2: GPRS

2 Nokia MetroSite 2+2

GSM for all sectors, F-Bus Master TRX (Non-BCCH).

(MBCCHC, SDCCH, 3*TCHD, 3 TS reserved for GPRS) + (8*TCHD)

64kbit/s Non-Hopping

4 HR (2 TSs), 6 FR (6 TSs), 1 HSCSD (3 TSs), 3 GPRS (3 TSs) with file transmission larger than 10 MB. 3*Data transfer from a GPRS phone (2*download a file larger than 10 Mb, 1*upload a file larger than 10Mb. Downloading/Uploading to be repeated during test period)

Note 123.

Keep ASI feature “OFF” on BSC for sections 22, 23


DN0694168 Issue 1-0


243 (252)

Note 124.

Use latest release of CX6 BTS software for sections 22, 23



22 Modification of Timer values from BSC

22.1 Modification of LAPDm Timer value from BSC

Purpose: To check that LAPDm timer value can be modified from the BSC Equipment and BTS Set-Up As per the test case

Input Expected Output The Site is in Supervisory state

Modify the T200F and T200S values from the BSC as defined in the test case

Values can be modified from the BSC. From the Abis traces it can be verified that BTS_CONF_DATA is sent with new ‘IE’ BTS_LAPD_T200_VALUES containing the modified values. BTS_ACK should be sent to the BSC

Lock the BCF from the BSC and Unlock it after 2 minutes.

The BTS_LAPD_T200_VALUES shows the changed values.

Case Ref. Configuration T200F and T200S values

13-393993.01

2+2+2, DVxx, RAH Both ‘0’

13-393993.02

6 Omni, RTC, BB Hopping ‘200’ and ‘220’

Modification of Timer values from BSC

DN0694168 Issue 1-0


245 (252)

13-393993.03

2+2, IDD with 4UD ‘400’ and ‘500’

22.2 Modified LAPDm T200 with Multi BCF Purpose: To check that the Multi-BCF sites come into working order regardless of the LAPDm timer values for different BCFs

Equipment and BTS Set-Up As per Figure UltraSite-UltraSite.

Input Expected Output The site is configured as shown in the diagram below Create the synchronisation chain at the BSC using the MML command: ZEFM: <mm>: CS=BCF, SENA=T, ADD=<s1>; <mm> = master BCF number <s1> = slave BCF number Physically create and commission the sites.

The site comes up in WO state

Set T200F and T200S=0 for Master BCF on the BSC. Set T200F and T200S=1260 for Slave BCF on the BSC. Power off the BCFs

Modification at the BSC is successful. The BTS Manager gets disconnected. BCCH missing and PCM failure alarm is raised on the BSC.

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 Master mode. From the Abis traces it can be verified that BTS_CONF_DATA is sent with ‘IE’ BTS_LAPD_T200_VALUES containing the T200 values as defined for the Master BCF BTS_ACK should be sent to the BSC



Power on the Slave BCF.

The slave BCF comes into working order without raising any synchronisation alarms. The BTS Events window shows that the BCF is in slave mode. From the Abis traces it can be verified that BTS_CONF_DATA is sent with ‘IE’ BTS_LAPD_T200_VALUES containing the T200 values as defined for the Slave BCF BTS_ACK should be sent to the BSC

Calls are established in all the BTSs Calls are successful


13-394060.01 BTS1&3 (EDGE) RF Hopping, BTS2&4 (GSM)

1 UltraSite-UltraSite

BTS 3 Hop = RF MA = same as BTS 1HSN1 = same as BTS 1 BTS 4 Non-hopping

SEGMENT

BTS1

BTS2

BTS3

BTS4

BCF

BCCH

MASTER SLAVE BCF 2

BTS 1 Hop = RF MA = xx (5 ARFN) HSN1 = yy BTS 2 Non-hopping

1

22

33

44


DN0694168 Issue 1-0


247 (252)

22.3 Verification of SDCCH T200 timer value

Purpose:

The purpose is to verify that SDCCH T200 timer expires as defined at the BSC irrespective of the SAPI

Note 125. TEMS set-up to be used for Air Interface monitoring

Note 126. One may find some delay in the retransmissions (e.g. T200S is set as 400 mS and retransmissions are occurring at 470 mS) due to the long block occurrence of SDCCH. UC needs to wait that the next SDCCH block occurs and only then the UC can send the DL SDCCH message again.

Note 127. ERROR_ IND message may not be seen in the Abis as other BSC timers may get expired before the time period of the product of [ T200*(N200+1) ]. For e.g. Timer T3107 supervises the Assignment procedures and it max value is 7sec.

Equipment and BTS Set-Up As per the test case

Input Expected Output Define SDCCH T200 = 400 FACCH call set-up is disabled in the BSC Define RLT=64 and ARLT=64 Disable SDCCH handover for the BTS Dynamic SDCCH feature is disabled from the BSC

MS A tries to call MS B latched on a different BTS. During the signalling phase of the call setup introduce very high interference in the UL direction

Call is not successful. Verify from the TEMS set-up that the retransmission of the layer2 frames occurs after every 400 ms (T200) It is observed that as soon as the BTS is not able to decode the UL messages BTS sends ERROR_ IND message with cause 1 = T200 expired with N200+1 times.



Change SDCCH T200 to 600 MS A tries to call MS B. During the signalling phase of the call setup introduce very high interference in the UL direction

Call is not successful. Verify from the TEMS set-up that the retransmission of the layer2 frames occurs after every 600 ms (T200) It is observed that as soon as the BTS is not able to decode the UL messages BTS sends ERROR_ IND message with cause 1 = T200 expired with N200+1 times. It is clear from the Abis trace that ERROR_IND message is delayed by almost [200*(N200+1)] ms in the second scenario.


13-394071.01 Any

Input Expected Output Define SDCCH T200 = 400 Disable SDCCH handover for the BTS Dynamic SDCCH feature is disabled from the BSC

MS A tries send an SMS to MS B latched on a different BTS. During the signalling phase introduce very high interference in the UL direction

SMS sending failed is displayed on MS A Verify from the TEMS set-up that the retransmission of the layer2 frames occurs after every 400 ms (T200) It is observed that as soon as the BTS is not able to decode the UL messages BTS sends ERROR_ IND message with cause 1 = T200 expired with N200+1 times.

Change SDCCH T200 to 600 MS A tries send a SMS to MS B During the signalling phase introduce very high interference in the UL direction

SMS sending failed is displayed on MS A Verify from the TEMS set-up that the retransmission of the layer2 frames occurs after every T200ms It is observed that as soon as the BTS is not able to decode the UL messages BTS sends ERROR_ IND message with cause 1 = T200 expired with N200+1 times. It is clear from the Abis trace that ERROR_IND message is delayed by almost [200*(N200+1)] ms in the second scenario.


13-394071.02 Any


DN0694168 Issue 1-0


249 (252)

22.4 Verification of FACCH T200 timer value

Purpose: The purpose is to verify that FACCH T200 timer expires as defined at the BSC.

Note 128. TEMS set-up to be used for Air Interface monitoring

Note 129. First retransmission may take more time than the defined value of T200F due to intracell handover when MS try to access the new traffic channel.

Note 130. ERROR_ IND message may not be seen in the Abis as other BSC timers may get expired before the time period of the product of [ T200*(N200+1) ]. For e.g. Timer T3107 supervises the Assignment procedures and it max value is 7sec.

Equipment and BTS Set-Up As per the test case

Input Expected Output Define FACCH T200 = 400 Define RLT=64 and ARLT=64 Enable Intra cell handover for the BTS

MS A calls to MS B latched on a different BTS. Introduce very high interference in the UL direction to initiate Intra Cell handover.

Call is successful. BSC sends ASSIGNMENT COMMAND to the MS as seen on the Abis trace as well as on the layer3 window of the TEMS ASSIGNMENT COMPLETE message sent on the UL cannot be decoded Verify from the TEMS set-up that the retransmission of the layer2 frames occurs after every 400 ms (T200) It is observed that as soon as the BTS is not able to decode the UL messages BTS sends ERROR_ IND message with cause 1 = T200 expired with N200+1 times. RF Channel gets released.



Change FACCH T200 to 600 MS A calls to MS B latched on a different BTS. Introduce very high interference in the UL direction to initiate Intra Cell handover.

Call is successful. BSC sends ASSIGNMENT COMMAND to the MS as seen on the Abis trace as well as on the layer3 window of the TEMS ASSIGNMENT COMPLETE message sent on the UL cannot be decoded Verify from the TEMS set-up that the retransmission of the layer2 frames occurs after every 600 ms (T200) It is observed that as soon as the BTS is not able to decode the UL messages BTS sends ERROR_ IND message with cause 1 = T200 expired with N200+1 times. RF Channel gets released. It is clear from the Abis trace that ERROR_IND message is delayed by almost [200*(N200+1)] ms in the second scenario.


13-394074.01 One Omni


DN0694168 Issue 1-0


251 (252)

23 SACCH Messages during speech Call

Purpose: To check that the SACCH messages are exchanged correctly between the MS and the BTS during Speech call.

Equipment and BTS Set-Up BTS site as mentioned in the configuration, Air interface monitoring tool

Input Expected Output The site is in supervisory state. Connect the air interface analyser and latch its MS onto the BTS under test

The MS gets latched on successfully.

Make a call to another MS from the air interface analyser phone and keep the call held for about 60 seconds.

The call is successful.

Observe the messages on air Interface analyser. Once the call has been established SI messages for SI5 and SI6 are seen being scheduled alternately every SACCH period on the air interface in the DL direction. In uplink direction Measurement reports are sent in every SACCH period.

Disconnect the call. Define more than 18 neighbours of the same band for the Sector under test. The neighbours need not be in working state.

The call is disconnected. The neighbours can be defined successfully.



Observe the messages on air Interface analyser. Once the call has been established SI messages for SI5, SI 5bis and SI6 are seen being scheduled on the air interface in the DL direction. The sequence of repetition is SI5, SI6, SI 5bis, SI6 each one 480ms after the other In uplink direction Measurement reports are sent in every SACCH period i.e. 480ms.



Input Expected Output Disconnect the call. Delete all the neighbours. Define a neighbour of different band for this BTS

The call is disconnected. The neighbours are successfully deleted. The different band neighbour can be successfully defined.



Observe the messages on air Interface analyser. Once the call has been established SI messages for SI5, SI 5bis(ter) and SI6 are seen being scheduled on the air interface in the DL direction. The sequence of repetition is SI5, SI6, SI5, SI6, SI5bis(ter), SI 6each one 480ms after the other In uplink direction Measurement reports are sent in every SACCH period i.e. 480ms.

Disconnect the call. The call is disconnected.

Case Ref. BTS configuration/Band Call Type

511603.01 4 TRX omni/EGSM AFS/EFR

511603.02 4 TRX omni/EGSM AHS/HR

Common Telecom Regression Test Specification © Nokia Siemens Networks

Documents

Transcript of Common Telecom Regression Test Specification © Nokia Siemens Networks