S15 Release Test Cases

Issue 1.0-0

© Nokia Siemens Networks 1 (143)

Nokia Siemens Networks BSC and TCSM Rel. S15, Release Documentation

BSC S15 Release Testing Test Cases (ANSI/ETSI)

2 (143) © Nokia Siemens Networks Issue 1.0-0

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 2011. All rights reserved.

Contents

Issue 1.0-0


Contents

1 Purpose...................................................................................................8

1 Test cases...............................................................................................9 1.1 Abis interface ...........................................................................................9 1.1.1 Abis: Creation of BTS...............................................................................9 1.1.2 Abis: Deletions of BTS ...........................................................................10 1.1.3 Abis: PCM Break....................................................................................11 1.1.4 Abis: Modification of BTS .......................................................................12 1.1.5 Abis: Creation of BTS using Packet Abis over TDM (ETPT)..................14 1.1.6 Abis: Creation of BTS using Packet Abis over IP (ETPE) ......................16 1.2 A-interface..............................................................................................18 1.2.1 A if: Creation of A interface with TCSM2................................................18 1.2.2 A if: Creation of A interface with CombiTCSM3i.....................................20 1.2.3 A if: Creation of A interface with stand-alone TCSM3i ...........................21 1.2.4 A if: Creation of A interface through CombiTCSM3i evolution

TCSA......................................................................................................22 1.2.5 A-if: Creation of A interface over IP (ETPC)...........................................23 1.2.6 A-if: Creation of A interface over IP (ETPA) ...........................................24 1.3 Checking required HW and SW versions ...............................................26 1.3.1 Checking SW levels of network elements ..............................................26 1.3.2 Memory consumption per computer unit ................................................27 1.3.3 Checking HW version of BSC and TCSM ..............................................27 1.4 S14 software implementation.................................................................28 1.4.1 Checking Installed Change Notes ..........................................................28 1.4.2 BSC SW downgrade ..............................................................................29 1.4.3 SW: Safecopy of current package..........................................................32 1.4.4 SW: Check Preconditions.......................................................................33 1.4.5 SW: Firmware change and memory upgrade.........................................33 1.4.6 SW: Copy SW from DAT/MO .................................................................34 1.4.7 SW: Copy SW from compressed download ...........................................34 1.4.8 SW: Actual upgrade ...............................................................................35 1.4.9 SW: check postconditions ......................................................................36 1.4.10 CD installation during upgrade...............................................................36 1.4.11 SW Copy via NetAct...............................................................................37 1.4.12 SW: Copy SW from USB........................................................................38 1.4.13 Local SW loading to TCSM2 ..................................................................38 1.4.14 Local SW loading to TCSM3i .................................................................41 1.5 Feature implementation..........................................................................44 1.5.1 Licence: Installation................................................................................44 1.5.2 Licence: Unsuccessful installation..........................................................45 1.5.3 BSC3i upgrade from 660 to 1000...........................................................46 1.5.4 BSC3i extension from 1000 to 2000.......................................................47 1.5.5 BSC3i 660 upgrade from GSWB to GSW1kB for ET4 ...........................47 1.5.6 BSC3i upgrade from 1000 to Flexi BSC.................................................48 1.5.7 BSC/PCU HW upgrade for PS traffic (GPRS/EDGE).............................49

Contents


1.5.8 BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection ............. 49 1.5.9 BSC3i/TCSM3i HW implementation for combined installation .............. 50 1.5.10 TCSM3i cabinet extension for combined BSC3i/TCSM3i

procedure .............................................................................................. 51 1.5.11 BSC3i upgrade from 660 to Flexi BSC (Offline procedure) ................... 51 1.5.12 BSC3i upgrade from 2000 to Flexi BSC ................................................ 52 1.5.13 BSC3i 660 upgrade from AS7-B to AS7-C for signalling

capacity ................................................................................................. 53 1.5.14 BSC3i/TCSM3i ETIP1-A implementation for IP/PWE............................ 54 1.5.15 BSC3i ET cabinet extension for Flexi BSC............................................ 54 1.5.16 BSC3i upgrade from 660 to 1000 (Offline procedure) ........................... 55 1.5.17 BSC3i upgrade from 1000 to Flexi BSC (Offline procedure) ................. 56 1.5.18 BSC3i upgrade from 2000 to Flexi BSC (Offline procedure) ................. 56 1.5.19 BSC ETIP1-A implementation for IP/PWE ............................................ 57 1.5.20 BSC upgrade for SDH/Sonet equipment protection .............................. 58 1.5.21 BSC upgrade from 660 to Flexi BSC 4200 (Offline procedure)............. 58 1.5.22 BSC upgrade from 1000 to Flexi BSC 4200 (Offline procedure)........... 59 1.5.23 BSC upgrade from 2000 to Flexi BSC 4200 (Offline procedure)........... 60 1.5.24 BSC upgrade from Flexi BSC 3000 to Flexi BSC 4200......................... 61 1.5.25 BSC implementation for ETP/ETP-A ..................................................... 61 1.5.26 TCSM implementation for ETP-A .......................................................... 62 1.5.27 Standalone TCSM3i implementation for ETP-A .................................... 63 1.5.28 Standalone TCSM3i ETIP1-A implementation for IP/PWE.................... 63 1.5.29 L3 BSC IP Site Connectivity upgrade.................................................... 64 1.6 Call Cases ............................................................................................. 65 1.6.1 Location Updating.................................................................................. 65 1.6.2 MS to MS call ........................................................................................ 66 1.6.3 Emergency call ...................................................................................... 67 1.6.4 Data call................................................................................................. 67 1.6.5 SMS from MS to MS.............................................................................. 68 1.6.6 Data Call HSCSD .................................................................................. 69 1.6.7 SMS from MS to MS over GPRS........................................................... 69 1.6.8 MS to MS call using TTY devices.......................................................... 71 1.6.9 Dynamic Frequency Channel Allocation (DFCA) .................................. 71 1.7 Handovers ............................................................................................. 74 1.7.1 Inter Cell Handover................................................................................ 74 1.7.2 Inter System Handover (ISHO).............................................................. 75 1.7.3 Inter BSC Handover S14 SW release – S15 SW release ..................... 77 1.7.4 Inter BSC Handover .............................................................................. 78 1.8 GPRS Call ............................................................................................. 79 1.8.1 GPRS: Attach & PDP Context ............................................................... 79 1.8.2 GPRS: FTP download ........................................................................... 79 1.8.3 GPRS: Several mobiles at the same cell............................................... 80 1.8.4 GPRS: Data transfer after GENA Y/N ................................................... 81 1.8.5 GPRS: FTP upload................................................................................ 82 1.8.6 GB: Frame Relay Creation .................................................................... 83 1.8.7 GB: Gb over IP Creation (static/dynamic) ............................................. 84 1.8.8 GB: Gb over IP Modification (static/dynamic)........................................ 87

Contents

Issue 1.0-0


1.8.9 GB: Gb over IP LAN break.....................................................................88 1.8.10 GPRS/EDGE: HSCSD call allocation in GPRS territory.........................90 1.8.11 GPRS/EDGE: NCCR..............................................................................91 1.8.12 GPRS/EDGE: NACC..............................................................................92 1.8.13 GPRS/EDGE: MT CS call during data transfer ......................................93 1.8.14 GPRS/EDGE: CS SMS during data transfer ..........................................94 1.8.15 GPRS/EDGE: Cell change during data transfer.....................................95 1.8.16 GPRS/EDGE: Extended UL TBF ...........................................................96 1.8.17 GPRS/EDGE: CS3&CS4........................................................................97 1.8.18 Gb: Frame Relay Modification................................................................98 1.8.19 Gb: PCM break on Gb interface.............................................................99 1.8.20 GPRS/EDGE: Territory upgrades and downgrades .............................101 1.8.21 GPRS: DTM and EDA&HMC interworking ...........................................102 1.8.22 GPRS: Dual Transfer Mode (DTM) ......................................................103 1.9 EGPRS Call .........................................................................................104 1.9.1 EGPRS: Data transfer after GENA Y/N................................................104 1.9.2 EGPRS: Create DAP pool....................................................................105 1.9.3 EGPRS: Delete DAP............................................................................106 1.9.4 EGPRS: FTP upload ............................................................................108 1.9.5 EGPRS: DAP modification, Controlling BCSU.....................................108 1.9.6 EGPRS: DAP modification, Controlling PCU .......................................110 1.9.7 EGPRS: DAP modification, First and last timeslot ...............................112 1.10 Q3-interface functionality......................................................................114 1.10.1 NetAct (Q3) functionality: Alarms .........................................................114 1.10.2 NetAct (Q3) functionality: Measurement ..............................................114 1.10.3 NetAct (Q3) functionality: Remote MMI................................................115 1.10.4 NetAct (Q3) functionality: Fast 2G upload............................................116 1.11 LAN Device Integration (LDI) ...............................................................116 1.11.1 LDI: Creation of internal LAN ...............................................................117 1.11.2 LDI: Copying LAN switch configuration file ..........................................118 1.11.3 LDI: LAN supervision............................................................................118 1.11.4 LDI: Diagnostic of LAN switch ..............................................................120 1.11.5 LDI: LAN statistics ................................................................................120 1.12 State transitions and restarts................................................................121 1.12.1 BSC system restart ..............................................................................122 1.12.2 Power break in the system...................................................................123 1.12.3 OMU State Change and Diagnostics ...................................................124 1.12.4 BCSU State Change and Diagnostics..................................................125 1.12.5 MCMU State Change and Diagnostics.................................................125 1.12.6 MB State Change and Diagnostics ......................................................126 1.12.7 OMU Partial Diagnostics ......................................................................127 1.12.8 MCMU Partial Diagnostics ...................................................................128 1.12.9 BCSU Partial Diagnostics.....................................................................128 1.12.10 MCMU power break while data transfer on ..........................................129 1.12.11 BCSU power break while (E)GPRS data transfer is on........................130 1.12.12 Switchover: BCSU handle BTS/TRX....................................................131 1.12.13 Switchover: BCSU handle A-interface..................................................132 1.12.14 Switchover: BCSU handle Gb-interface ...............................................133

Contents


1.12.15 Switchover: MCMU.............................................................................. 134 1.12.16 Switchover: SGSN PAPU unit ............................................................. 135 1.12.17 Switchover: MSC BSU unit.................................................................. 136 1.12.18 TCSM restart ....................................................................................... 137 1.12.19 Call scenarios after interface modifications (set1)............................... 138 1.12.20 Call scenarios after interface modifications (set2)............................... 139 1.12.21 Call scenarios after interface modifications (set3)............................... 140 1.12.22 STMU: Transmission protection .......................................................... 140 1.12.23 STMU unit restart ................................................................................ 141 1.12.24 HW protection verification in case of ETIP/STMU ............................... 142

Purpose

Issue 1.0-0


Summary of changes

Issue: Date: Summary of changes:

0.1-0 5.5.2010 First draft document

1.0-0 18.8.2010 Approved version. Review comments updated

Purpose


1 Purpose This document includes all the BSC release test cases.

Test cases

Issue 1.0-0


1 Test cases

This document includes all the BSC release test cases.

1.1 Abis interface

1.1.1 Abis: Creation of BTS

Test case ID: RT000AB00001

Test case version: 1.3.0

Test Purpose Purpose of this test case is to verify the creation of Base Transceiver Station

Pre-requirements -Working BSC and GPRS capable BTS

-Gb-if is created

-GPRS feature (licence 673) activated and used in one cell at least (ZW7I to check the licence)

-Check status of PCU/PCU2 licence (ZW7I)

-GPRS connection parameters of PCs are correctly configured

-Check that there are no abnormal alarms and log writings in MCMU and BCSU

Test Execution 1) Connect the ET unit to Abis interface (ZWUC)

2) Create D-channel link sets (ZDSE)

3) Create BCF, BTS’s and TRX’s (ZEFC, ZEQC, ZERC)

4) Create HO and power control parameters (ZEHC, ZEUC)

5) Attach software package to BCF (ZEWA)

6) Change D-channel link states to WO-EX (ZDTC)

Test cases


7) Activate GPRS (ZEQV)

8) Unlock TRX’s, BTS’s and BCF (ZERS, ZEQS, ZEFS)

9) Activate PDP context in three or more mobiles

10) Start downloading data from FTP address (Use FTP command from DOS prompt)

11) Wait until file is downloaded

12) Repeat downloading at least two times

13) Check that there are no abnormal alarms and log writings in MCMU and BCSU

Expected Results - Created BTS is able to handle CS/PS traffic

- PDP context activation succeeds

- Download succeeds

- No alarms occurred

- No log writings to Computer logs

Related documents NED – Integrate – BSS Integration – Creating the Abis Interface

1.1.2 Abis: Deletions of BTS



Test Purpose Purpose of this test case is to verify the deletion of Base Transceiver Station

Pre-requirements - Working BSC and GPRS capable BTS

- BTS creation test case already executed

- Gb-if is created


- Check status of PCU/PCU2 licence (ZW7I)

- Check that there are no abnormal alarms and log writings in MCMU and BCSU

Test cases

Issue 1.0-0


Test Execution 1) Lock TRX’s, BTS’s and BCF (ZERS, ZEQS, ZEFS)

2) Deactivate GPRS/EDGE, GENA=N, EGENA=N, (ZEQV)

3) Change D-channel working state to UA-AD. (ZDTC)

4) Delete TRX’s, BTS’s and BCF (ZERD, ZEQD, ZEFD)

5) Delete D-channel link sets (ZDSD)

6) Disconnect ET unit (ZWUD)


Expected Results - BTS deletion done successfully



Related documents None

1.1.3 Abis: PCM Break



Test Purpose Purpose of this test case is to verify that BSC recovers from Abis PCM break


-Gb-if is created





Test cases


Test Execution 1) Verify CS/PS traffic handling capability before PCM break


3) Start downloading data from FTP address (Use FTP command from DOS prompt) and leave CS call on

4) Make PCM break (by disconnecting and connecting PCM) over 4s while ongoing CS and PS calls

PCM Break over 4s (T111_T27 + 1s)

5) Wait until file is downloaded or download data from FTP address again.

6) Repeat downloading at least two times

7) Make a CS call to phone in HTTP/FTP data transfer

8) Maintain CS call for 15 seconds.

9) Release CS call


Expected Results - BSC is able to handle CS/PS traffic

- Alarms indicating PCM break cancelled after recovery

- When CS call made during data transfer check following:

FTP data transfer is suspended

CS call is successful

FTP data transfer continues after CS call is released

Related documents NED – Reference – Parameters – SS7 Signalling network parameters – MTP level 3 parameters

1.1.4 Abis: Modification of BTS



Test Purpose Purpose of this test case is to verify the modification of Base Transceiver Station

Pre-requirements

Test cases

Issue 1.0-0


-Working BSC and GPRS capable BTS

-Gb-if is created




-Licence for Packet Abis is activated (1535)

-ETPE functional unit created with plug-in unit successfully (unit in WO-EX state)


-Throughput monitoring application installed to PCs

Test Execution 1) Change the BCF state to Locked (ZEFS)

2) Lock the BTS (ZEQS) and TRX's (ZERS)

3) Change the GENA=N and EGENA=N (ZEQV)

4) Delete the TRX’s

5) Change lapD channel states to UA-AD (ZDTC)

6) Delete the TRx’s LapD channels (ZDSD)

7) Create the LapD channels again

-Use different bitrate than earlier (used bitrate needs to be modified with BTS Manager to HW database)

8) Change the LapD channel states to WO (ZDTC)

9) Create the TRXs (attach also exiting DAP)

10) Unlock the BCF (ZEFS)

11) Change the GENA=Y and EGENA=Y (ZEQV)

12) Unlock the BTS (ZEQS) and TRX's (ZERS)




16) Repeat downloading several times


Expected Results - Modified BTS is able to handle CS/PS traffic

Test cases



- Download succeeds

- Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)




1.1.5 Abis: Creation of BTS using Packet Abis over TDM (ETPT)



Test Purpose Purpose of this test case is to verify the creation of Base Transceiver Station using Packet Abis over TDM.

Pre-requirements -Working BSC

-IP-BTS configured to Packet Abis over TDM use. FlexiEDGE BTS SW release required for Packet Abis is Flexi EDGE or Flexi Multiradio BCF which supports Packet Abis is SW version 04.00.00 or higher.

-Configure the IP addresses at both ends of the Packet Abis interface.

• At BCF side, there is one IP address for M-plane and another IP address for C/U-plane.

• At BSC side, there is one IP address for M-plane, a separate IP address reserved for the C-plane at each BCSU and one IP address for the U-plane (U-plane terminates at ETPT). This IP definition is already done when ETPT is configured to BSC.

The IP interfaces and IP addresses at BSC are configured with the QRA and QRN MML commands.

On Abis interface user has to create ETPT’s IL0/1 ETPSIG-C IP address as a GW address for BCSU OMUSIG and TRXSIG interfaces. This is to be done with the QKC command.

-Gb-if is created, check that used PCU units are created for PCUPAB mode

-GPRS feature (licence 673) activated and check also status of PCU/PCU2 licence (ZW7I)


Test cases

Issue 1.0-0


-Licence for Packet Abis over TDM is activated (1535)

-ETPT and related STMU functional units created with plug-in unit successfully (unit in WO-EX state)


Test Execution 1) First plan the value for the Minimum SCTP port value (used in BTS SCF file) of the FlexiEDGE BTS, and then use the same value for BTS end OMUSIG SCTP port, and based on that calculate the SCTP port values to be used for different TRXs

The SCTP ports for TRX signaling are the following TrxSigPort(carrier1) = Minimum SCTP port + 1 TrxSigPort(carrierX) = Minimum SCTP port + X

2) Create SCTP associations (IUA) for OMUSIG and TRXSIG, e.g

ZOYX:OMUSIG:IUA:S:BCSU,1:SS7::;

3) Configure the IP address to the association (OYP). Source IP address is ETPE plug-in unit’s IP and destination BTS’s IP. e.g

ZOYP:IUA:OMUSIG:"10.125.77.70",:"10.125.76.163",22,:;

4) Configure DCSP value as “0” for the default SCTP port 9900 (IUA):

ZQ8N:132::9900:0;

5) Create the D-channels with parameters SAPI and TEI. eg.

OMUSIG : ZDWP:OM205:BCSU,1:62,0:OMUSIG,:;

TRXSIG : ZDWP:TR206:BCSU,1:0,4:TRXSIG,:;

6) Activate SCTP (IUA) association (OYS).

7) Create Abis HDLC link and unlock it (EXS, ESS)

ZESX: HNBR=21,HNAME=HDLC21,HPCM=30,HTSL=0,HBAND=5;

ZESS:HNBR=21:STATE=U;

8) Create BCF. Note that Connection type (AICT) must indicate Packet Abis over TDM (EFC), e.g

ZEFC:231,E:AICT=1,DNBR=2,::::::BHIDL=231,HNBR=21,;

9) Create BTS for BCF (EQC)

10) Create HO and power control parameters (ZEHC, ZEUC, ZEUG)

11) Create TRX(s) to BTS by giving Packet Abis D-channel (ZERC)

12) Activate D-channel of OMUSIG/TRXSIG (DWS?)


Test cases



15) Unlock objects: TRX’s, BTS’s and BCF (ZERS, ZEQS, ZEFS)

16) Make MS to MS call







- Download succeeds




NED – BSC Site IP Connectivity Guidelines

1.1.6 Abis: Creation of BTS using Packet Abis over IP (ETPE)



Test Purpose Purpose of this test case is to verify the creation of Base Transceiver Station using Packet Abis over Ethernet.


-IP-BTS configured to Packet Abis over Ethernet use. FlexiEDGE BTS SW release required for Packet Abis is Flexi EDGE or Flexi Multiradio BCF which supports Packet Abis is SW version 04.00.00 or higher.

-Configure the IP addresses at both ends of the Packet Abis interface.

Test cases

Issue 1.0-0


• At BCF side, there is one IP address for M-plane and another IP address for C/U-plane.

• At BSC side, there is one IP address for M-plane, a separate IP address reserved for the C-plane at each BCSU and one IP address for the U-plane (U-plane terminates at ETPE). This IP definition is already done when ETPE is configured to BSC.

-Activate SIGTRAN for the A interface

-Gb-if is created, check that used PCU units are created for PCUPAB mode

-GPRS feature (licence 673) activated and verify also status of PCU/PCU2 licence (ZW7I)


-Licence for PA over Ethernet (1533), AoverIP (1753) needed

-ETPE functional unit with plug-in unit is created successfully (unit in WO-EX state)


Test Execution 1) First plan the value for the Minimum SCTP port value (used in BTS SCF file) of the FlexiEDGE BTS, and then use the same value for BTS end OMUSIG SCTP port, and based on that calculate the SCTP port values to be used for different TRXs

The SCTP ports for TRX signalling are the following TrxSigPort(carrier1) = Minimum SCTP port + 1 TrxSigPort(carrierX) = Minimum SCTP port + X

2) Create SCTP associations (IUA) for OMUSIG and TRXSIG, e.g

ZOYX:OMUSIG:IUA:S:BCSU,1:SS7::;

3) Configure the IP address to the association (OYP). Use as source IP address ETPE plug-in unit’s IP address and as destination BTS’s IP. e.g

ZOYP:IUA:OMUSIG:"10.125.77.70",:"10.125.76.163",22,:;

4) Configure DCSP value as “0” for the default SCTP port 9900 (IUA):

ZQ8N:132::9900:0;

5) Create the D-channels with parameters SAPI and TEI. eg.

OMUSIG : ZDWP:OM205:BCSU,1:62,0:OMUSIG,:;

TRXSIG : ZDWP:TR206:BCSU,1:0,4:TRXSIG,:;

6) Activate SCTP (IUA) association (OYS). Note that D-channel activation is not needed. Once the association is activated, the D-channel becomes active.

7) Create BCF. Note that Connection type (AICT) must indicate Packet Abis over Ethernet (EFC), e.g

Test cases


ZEFC:231,E:AICT=2,ETPGID=<ETP Group ID>,:::::::;

8) Create BTS for BCF (EQC)

9) Create HO and power control parameters (ZEHC, ZEUC, ZEUG)

10) Create TRX(s) to BTS by giving Packet Abis D-channel (ZERC).



13) Unlock objects: TRX’s, BTS’s and BCF (ZERS, ZEQS, ZEFS)

14) Make MS to MS call







- Download succeeds





1.2 A-interface

1.2.1 A if: Creation of A interface with TCSM2

Test case ID: RT000AI00001


Test Purpose

Issue 1.0-0


Purpose of this test case is to verify the creation of A interface

Pre-requirements -Working TCSM2

-Working MSC

Test Execution 1) Connect the ET unit to A-interface (ZWUC)

2) Output the functional modes of the ETs (ETSI: ZYEI, ANSI:ZYEH)

3) Change the functional mode of the ETs if needed (ETSI: ZYEC, ANSI: ZYEG)

4) Create a rack for TCSM2 (ZWTJ)

5) Create a cartridge for the TC1C (ZWTC)

6) Create the TCSM unit (ZWTU)

7) Create the transcoder controller plug-in unit, TRCO (ZWTP)

8) Create TR16/TR12 plug-in units (ZWTP)

9) Create the ET1TC cartridge (ZWTC)

10) Create the unit ET1TC cartridge (ZWTU)

11) Create ET plug-in units (ZWTP)

12) Set the number of through connected channels (ZWGS)

13) Connect the transcoder ETs (ZWGC)

14) Connect the TRCO to the BSC (ZWUC)

15) Change the state of the TCSM2 to WO-EX (ZUSC)

16) Check the state of the TCSM2 LAPD link (ZDTF)

17) Create the signalling links (ZNCC)

18) Create the signalling point code (ZNRP)

19) Create the signalling link set (ZNSC)

20) Add links to the signalling link set (ZNSA)

21) Create the signalling route set (ZNRC)

22) Allow activation of the signalling route (ZNVA)

23) Change signalling link states (ZNLC)

24) Change route set state (ZNVC)

25) Create service (ZNPC)

26) Define SCCP for the BSC’s own signalling point (ZNFD)

27) Define SCCP for the MSC’s signalling point (ZNFD)

28) Modify broadcast status of SCCP signalling points (ZOBM)

Test cases


29) Modify the local broadcast status of SCCP subsystems (ZOBC)

30) Change the SCCP state at BSC side (ZNCG)

31) Change the SCCP state at MSC side (ZNCG)

32) Change subsystem state at BSC side (ZNHC)

33) Change subsystem state at MSC side (ZNHC)

34) Create a circuit group (ZRCC)

35) Add circuits to the circuit group (ZRCA)

36) Change the state of the speech circuits (ZCEC)

37) Check from TCSM PCM functional modes (ZEI:ALL)

38) Make a CS call

Expected Results Created a-interface is able to handle CS traffic

No alarms occurred

No log writings to Computer logs

Related Documents: NED – Integrate – BSS Integration – Creating the A Interface

1.2.2 A if: Creation of A interface with CombiTCSM3i



Test Purpose Purpose of this test case is to verify the creation of A interface

Pre-requirements -Working BSC with CombiTCSM3i

-Working MSC

Test Execution

1) Create A interface according to corresponding BSC/TCSM HW implementation for combined installation procedure.

2) Call from subscriber A to subscriber B

Issue 1.0-0


-Make the call with different types of MSs if possible

3) Answer the call at the B’s MS

4) Check that the call is going through the right BTS with command ZEEI;

5) Clear the call from the subscriber A's MS

6) Check for new alarms in the system

7) Repeat the test several times with different mobiles if possible (write down brand and model of used mobiles)


No alarms occurred


Related documents Corresponding BSC3i upgrade for Combined BSC3i/TCSM3i Procedure.

1.2.3 A if: Creation of A interface with stand-alone TCSM3i



Test Purpose Purpose of this test case is to verify the creation of A interface

Pre-requirements -Working BSC and stand-alone TCSM3i

-Working MSC

Test Execution 1) Create A intercase according to latest BSS Integration Manual.







Test cases




No alarms occurred


Related documents NED – Integrate – BSS Integration – Creating the A Interface

1.2.4 A if: Creation of A interface through CombiTCSM3i evolution TCSA



Test Purpose Purpose of this test case is to verify the creation of A interface through combined BSC with capacity evolution TCSA

Pre-requirements -Working combined BSC with capacity evolution TCSA cabinet(s)

-Working MSC

Test Execution

1) Create A intercase according to latest BSS Integration Manual.








Expected Results

Issue 1.0-0


Created a-interface is able to handle CS traffic

No alarms occurred


Related documents NED – Integrate – BSS Integration – Creating the A Interface

1.2.5 A-if: Creation of A interface over IP (ETPC)



Test Purpose Purpose of this test case is to verify the creation of A interface over IP using ETPC functional unit (Combined or Standalone TCSM3i).


-Working combined or stand-alone TCSM3i

-Working MGW

-Licence AoIP (1753) activated

-ETPC functional unit with plug-in unit (ETP-A) created and unit is in WO-EX state (use Combined TCSM3i implementation for ETP-A or Standalone TCSM3i implementation for ETP-A procedure).

Test Execution 1) Create A interface by executing following steps (according to latest BSS Integration Manual).

- Create TCSM unit and TR3T plug-in unit and connect TCSM unit to BCSU, e.g

ZWTU:TCSM,904:1D2-0:;

ZWTP:TCSM,904:TR3T,0,1::GENERAL,2,904,TSL,1::;

ZWTP:TCSM,904:ET16,1,17:::; (only in case of standalone TCSM)

ZWUC:TCSM,904:TR3E,0:ETPSIGC=1,ETPCPCM=0:BCSU,0;

- Create CGR for speech circuits ZRCC:TYPE=SPE,NCGR=ETPC88,CGR=88:FORMAT=2,HUNTED=Y;

Test cases


- Add CGR to route ZRRC:INT,GSW:ROU=88,NCGR=ETPC88;

- Create TC_PCM(s) to TCSM ZWGC:904:POOL=88:BCSU,0;

- Add speech timeslots to CGR and change timeslots to WO-EX state ZRCA:CGR=88:ETPCM=904,CRCT=1-2&&-31:;

ZCEC:904,CRCT=1-2&&-31:<STATE>;

- Change TCSM to WO-EX state ZUSC:TCSM,904:SE-OU;

ZUSC:TCSM,904:TE-EX; ZUSC:TCSM,904:WO-EX;

- Create SIGTRAN A-interface signalling link (according to latest SIGTRAN Configuration for the A Interface)


-Make the call with different types of MS(s) if possible






Expected Results Created A-interface is able to handle CS traffic

No alarms occurred


Related documents NED – Integrate – BSS Integration – Creating the A Interface via IP


NED - SIGTRAN Configuration for the A Interface

1.2.6 A-if: Creation of A interface over IP (ETPA)


Issue 1.0-0



Test Purpose Purpose of this test case is to verify the creation of A interface over IP using ETPA functional unit (via TC in MGW).


-No TCSM hardware equipped to A-if and MGW connection exists

-Licence AoIP (1753) activated

-ETPA functional unit with plug-in unit (ETP-A) created to BSC and unit is in WO-EX state (use BSC implementation for ETP/ETP-A procedure).

Test Execution 1) Create A interface by executing following steps (according to latest BSS Integration Manual)

- Create SIGTRAN A-interface signalling link (according to latest SIGTRAN Configuration for the A Interface)

- Create connection to MGW – create EEP interface from ETPE/ETPT to ETPA, for example

ZQRA:ETPE,0,0::VLAN21,21,BOND0,;

ZQRN:ETPE,0,0::VLAN21,:"10.0.1.65",26,L,I::;

ZQRN:ETPE,0,0::VLAN21,:"10.0.1.65",26,P,VI::;

ZQRP:ETPE,0,0::VLAN21:"10.0.1.65":TAG,"EEP":;

ZQRA:ETPA,0::VLAN21,21,BOND0,;

ZQRN:ETPA,0::VLAN21,:"10.0.1.71",26,L,I::;

ZQRN:ETPA,0::VLAN21,:"10.0.1.71",26,P,I::;

ZQRP:ETPA,0::VLAN21:"10.0.1.71":TAG,"EEP":;

ZQKC:ETPA,0::"10.125.113.22",32:"10.0.1.65":LOG:;


-Make the call with different types of MS(s) if possible






Test cases


Expected Results Created A-interface is able to handle CS traffic

No alarms occurred


Related documents NED – BSC Site IP Connectivity Guidelines

NED - SIGTRAN Configuration for the A Interface

1.3 Checking required HW and SW versions

1.3.1 Checking SW levels of network elements

Test case ID: RT000TC00002


Test purpose To verify that SW levels of other network elements and firmware versions of BSC are correct

Pre-requirements None

Test Execution 1) Check the versions of other network elements from the latest BSC Release Test Plan. Write down versions of network elements SWs and installed Correction Deliverys (including BTSs)

2) Write down version of used documents

Expected results SW levels of other network elements and firmware versions of BSC are correct

Related documents -Corresponding Release Test Plan

-Corresponding Pre-processor Programs BSC SW

Issue 1.0-0


-Corresponding BSC Software Implementation Procedure (ANSI/ETSI)

1.3.2 Memory consumption per computer unit



Test purpose To check memory consumption per computer unit in BSC


Test Execution 1) Run the HIT macro (B11_mem_ver2.tel) of memory consumption

2) Check new logs of memory consumption

Expected results Memory usage and consumption are in normal level


1.3.3 Checking HW version of BSC and TCSM



Test purpose To check that BSC and TCSM HW versions are according to the latest document of

-Release test plan

-Network Element HW (BSCi, BSC2i, BSC3i, TCSM2, TCSM3i) Revision Lists


Test cases


Test Execution 1) Check the acceptable HW versions from the latest document version available

2) Write down version of used document

Expected results BSC and TCSM HW versions are correct

Related documents Corresponding documents as follows:

-Release test plan

-Network Element HW Revision Lists in NOLS

1.4 S14 software implementation

1.4.1 Checking Installed Change Notes

Test case ID: RT000SW00001


Test purpose To verify that all accepted and mandatory Change Deliveries have been installed in the BSC before this upgrade


Test Execution

1) List the Change Delivery history by using the command ZWNH:NAME=<sw_package_name>::;

2) Compare the information to the requirement mentioned in corresponding BSC Software Implementation Procedure and Release Test Plan

Expected results

Issue 1.0-0


All accepted and mandatory Change Deliveries have been installed in the BSC

Related documents -Corresponding BSC Software Implementation Procedure (ANSI/ETSI)

-Corresponding Release Test Plan

1.4.2 BSC SW downgrade



Test purpose To verify that return from different trial and cut over configurations of the new software to the old software is possible

Pre-requirements -Local upgrade

-Corresponding upgrade is run to the step "MOVE_OMU_TO_TRIAL"

Test Execution Case 1. Remove OMU from TRIAL

1) During the upgrade when it is asked by macro "In this step OMU is moved to trial configuration" press OK

2) Wait for the OMU recovery to the new software

OMU 0000 WO-EX TRIA NEWP

3) Stop the macro when moving to BASE configuration is suggested "In this step, spare MCMU and BCSU are added to trial configuration", press CANCEL

4) Return the OMU to old software by command

ZWRR:OMU;

5) Wait for the OMU recovery to the old software and confirm a successful restart: no abnormal alarms or computer log writings

Case 2. Remove BASE configuration from TRIAL

1) Continue from case 1, move OMU back to TRIAL

ZWRA:OMU;

2) Wait for the OMU recovery to the new software

Test cases



3) Continue running macro "In this step, spare MCMU and BCSU are added to trial configuration", press OK

4) Wait for the MCMU and BCSU recoveries to the new software

WORKING STATE OF UNITS

UNIT PHYS STATE LOCATION INFO


MCMU-1 0005 WO-EX TRIA NEWP

BCSU-1 0031 WO-EX TRIA NEWP NOSW

5) Stop the macro when installing the licences is suggested "In this step licences are installed and activated manually with command group ZW7 commands", press OK

6) Return the BCSU and MCMU one by one to old software by command

ZWRR:BCSU;

ZWRR:MCMU;

7) Wait for the MCMU and BCSU recoveries to the old software and confirm a successful restart: no abnormal alarms or computer log writings

Case 3. Remove CUTOVER configuration

1) Continue from case 2, move BASE back to TRIAL

ZWRA:BASE;

2) Wait for the MCMU and BCSU recoveries to the new software






3) Install the licences as earlier (Case 2) suggested by the macro "In this step licences are installed and activated manually with command group ZW7 commands"

4) Continue running the macro until the step "In this step all the units load the new software", press CANCEL

Note! CUTOVER should be done by now

5) Verify the configuration, one MCMU and BCSU remains with old software



Issue 1.0-0


OMU 0000 WO-EX NEWP

MCMU-1 0005 WO-EX NEWP

BCSU-1 0031 WO-EX NEWP NOSW

BCSU-2 0032 WO-EX NEWP

BCSU-3 0033 WO-EX NEWP

BCSU-4 0034 SE-NH NEWP





6) Return to the situation before the CUTOVER

ZWRO;

7) Wait for the OMU, MCMU and BCSU returning back to TRIAL






8) Verify the functionality of the old software, make a test call, for example.

Case 4. Remove the all TRIAL configuration

1) Remove units from trial configuration by following commands

WRR:BCSU;

ZWRR:MCMU;

ZWRR:OMU;

2) Wait for the MCMU, BCSU and OMU recoveries to the old software and confirm successful restarts: no abnormal alarms or computer log writings

3) Make a switchover for the MCMU and BCSU, verify successful switchover

4) Check the CMISE application names with following command:

ZQDI;

5) Start of the upgrade procedure the CMISE applications are blocked. Unlock all locked CMISE applications with following command:

ZQDG:<application_name>,UNL;

Test cases


6) Command calendar tasks that were stopped before the actual upgrade can be restarted with following command:

ZICB:<id>:UNBLOCK;

7)Deny the automatic return of software package with following command:

ZWSB;

8) Start the scheduled BTS and TRX tests that were stopped before the actual upgrade. All the tests must be started from the NetAct site.

9) Start the GSM measurements, which were active before the software upgrade. All the measurements must be started from the NetAct.

Expected results Downgrade to old SW is successful in every case

Related documents Corresponding Software Implementation Procedure (ANSI/ETSI)

1.4.3 SW: Safecopy of current package



Test purpose To make a safecopy of the running software package

Pre-requirements The safecopy can be made by using the corresponding HIT script or the safecopy can be made manually by following the Safecopying in BSC document

Test Execution 1) Follow the corresponding HIT script or see the document of Safecopy in BSC from NED

2) Safecopy scripts for both old and new software should be tested by using relevant HIT scripts for corresponding sw level

Expected Results The safecopy of the running software package is succeeds

Issue 1.0-0


Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)

Corresponding Safecopy in BSC

1.4.4 SW: Check Preconditions



Test purpose Checking preconditions of current configuration of an old software


Test Execution Run the precheck script according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')

Expected results Precheck is successful, no errors during the macro is running


1.4.5 SW: Firmware change and memory upgrade



Test purpose Test the firmware and memory upgrade script

Pre-requirements Needed amount of memory and eproms in hand

Test cases


Test Execution Run the firmware script according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')

Expected results Firmware and memory upgrades are successful, no errors during the macro is running

Computer units work normally


1.4.6 SW: Copy SW from DAT/MO



Test purpose To test the copy software script for SW package in the DAT and MO

Pre-requirements Package in DAT and MO

Test Execution 1) Run the copy SW script according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')

2) Local mode for SW copying is selected

Expected results Copying from both media is successful, no errors during the macro is running


1.4.7 SW: Copy SW from compressed download


Issue 1.0-0



Test purpose To test the copy software script for compressed package file

Pre-requirements Package zip file is downloaded to the WDUs of BSC


2) Use connection method which is specified in test plan (meaning local, telnet or SSH).

Expected results Uncompressing and copying are successful, no errors during the macro is running


1.4.8 SW: Actual upgrade



Test purpose To test the software upgrade of BSC


Test Execution Perform the software upgrade according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')

Expected results

Test cases


-Software upgrade is successful, no new alarms or computer log writings compared to the old release.


1.4.9 SW: check postconditions



Test purpose Checking current configuration of a new software


Test Execution Run the postcheck script according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')

Expected results Postcheck is successful, no errors during the macro is running


1.4.10 CD installation during upgrade



Test purpose To verify that CD(s) can be installed during (in TRIAL configuration) SW implementation procedure

Issue 1.0-0


Pre-requirements CD’s exists in NOLS or PC (from where software can be uploaded to BSC disks CDTEMP directory

Test Execution 1) Run the SW upgrade script according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')

2) Select Local mode and loading through TRIAL configuration

3) Install CD’s during upgrade (in TRIAL configuration LICENCE_INSTALLATION step)

4) Finish the SW implementation procedure

Expected results CD installation during upgrade is successful, no errors during the macro is running

After finishing upgrade procedure the wanted licences are in correct state and working correctly


1.4.11 SW Copy via NetAct



Test purpose To verify that software can be copied via NetAct according SW Implementation procedure

Pre-requirements Package exists in NetAct server


2) Remote NetAct mode for SW copying is selected

Test cases


Expected results Copying via NetAct is successful, no errors during the macro is running


1.4.12 SW: Copy SW from USB



Test purpose To verify that software can be copied from USB according SW Implementation procedure

Pre-requirements Package exists in USB


2) Use connection method which is specified in test plan (meaning local, telnet or SSH).

Expected results Copying from both media is successful, no errors during the macro is running


1.4.13 Local SW loading to TCSM2



Issue 1.0-0


Test purpose To verify that SW loading locally from PC to TCSM2i is successful

- TRCO (TC1_PXMX)

- TR12 / TR16 ( TD1…TD6 or TDL, depends on used pool)

- ET ET SW (ET2RAMQA or ET2RAMQK or ET5RAMQK or EA2TCSM2)

Pre-requirements

Test Execution

1. The loading of the TCSM software is carried out via TRCO service terminal interface as follows. Module type can be: TRCO, TR, ET 2. To start file transfer, enter command

TRCO: ZGU:<module type>; PLEASE CONFIRM (Y/N) Y PROCESSOR 80186EB POPCOM OK TESTING RAM: OK PROGRAM MODCOUNT CHECK LUC 13 OK PCL 06 OK PEC 0B OK POP 02 OK PEE 04 OK PEL 0D OK PET 08 OK PET 08 OK LPR 02 OK LP6 05 OK BAN 09 OK CHL 00 OK ERP 00 OK FAP 00 OK FIL 00 OK STARTING TCSM UNIT FROM PROM WAITING FOR BSC CONNECTION...FAILED. TCSM SET FOR LOCAL USE. TRCO SOFTWARE CORRUPTED. THERE IS NO PROGRAM CODE ON TRCO UNIT. TRCO IS READY TO RECEIVE PROGRAM CODE. START KERMIT FILE TRANSFER FROM YOUR COMPUTER.

ET: ZGU:ET PLEASE CONFIRM (Y/N) Y SELECT ECHANGE TERMINAL SOFTWARE : NBR ET TYPE ID STRING 1. ET2E ET2RAMQA.PAC 5.1-0 04/12/16 2. ET2A ET5RAMQK.PAC 5.2-0 05/02/21 3. ET2E/A-T EA2TCSM2.PAC 2.13-0 06/12/21

Test cases


ENTER NUMBER : <number> TRCO IS READY TO RECEIVE PROGRAM CODE. START KERMIT FILE TRANSFER FROM YOUR COMPUTER.

TR: LOCAL:GCC> ZGU:TR PLEASE CONFIRM (Y/N) Y TRANSCODER SOFTWARE : NBR ADDRESS PCM_LINE(S) USED_SW ID STRING 1. 4000.0000: 1 * PID: TD1_PXMX.PRM 3.11-0 05/02/23 2. 6000.0000: PID: TD1_PXMX.PRM 1.17-0 02/02/20 3. 5000.0000: 2 * PID: TD2_PXMX.PRM 1.9-0 02/02/20 ENTER NUMBER : <number> TRCO IS READY TO RECEIVE PROGRAM CODE. START KERMIT FILE TRANSFER FROM YOUR COMPUTER.

3. Instructions for file transfer: - Start the file transfer from the tool bar [Transfer File] in Reflection

2. The file transfer dialog window of Reflection 2 opens. Take the following settings Kermit, Binary, Ask user

- Select the software-level-specific subdirectory C:\XXX from the directory.

- Select the file to be transferred. - Start file transfer by pressing the right-hand button of the

Transfer buttons. - To start the file transfer, press the Transfer File button.

4. After file is transferred information is shown: TRCO:

/*** PROGRAM TRANSFER SUCCESSFULLY COMPLETED ***/ RESTARTING TCSM UNIT ... PROCESSOR 80186EB POPCOM OK TESTING RAM: OK PROGRAM MODCOUNT CHECK PEC 0B OK POP 02 OK PEE 04 OK PEL 0D OK PET 08 OK PET 08 OK LPR 02 OK LP6 09 OK PSA 05 OK T2L 06 OK T2F 03 OK LUC 1D OK DIS 0A OK PR1 05 OK PPA 0A OK TC2 09 OK TC3 09 OK TC4 08 OK BAN 09 OK CHL 00 OK ERP 00 OK FAP 00 OK FIL 00 OK MUF 00 OK STARTING TCSM UNIT FROM FLASH NO LINK TO BSC - TCSE SET FOR LOCAL USE. TCSM LOCAL TERMINAL INTERFACE READY

Issue 1.0-0


ET & TR /* PROGRAM TRANSFER SUCCESSFULLY COMPLETED */

5. Check that the TRCO is coming up to WO-EX with : ZGT 6. Manually restart the TRCO has been updated: ZUU 7. Restart the ET16 plug-in units if the ET software is updated:

ZUP:ET,X 8. After the TCSM is again up check the loaded module information

with: ZGI:<module type>;

Expected results Correct TCSM TRCO, TR and ET software can be loaded locally from PC to TCSM (TRCO unit). After software loading TCSM unit is in working state without irrelevant error logs or alarms.

Related documents

1.4.14 Local SW loading to TCSM3i



Test purpose

To verify that SW loading locally from PC to TCSM3i is successful

TR3 TR3E/A O&M SW (TR3_PXSX)

FPGA TR3E/A FPGA code (TRZ_PXSX)

ET ET SW (E16*)

DSP DSP SW (T56_PXSX and T57_PXSX)

There may be several versions of the transcoder software in the Flash memory. When updating the transcoder software, after entering the command, details of those versions are displayed and the user selects one of them. This selected version of the software is replaced by a new version. A message is displayed when the TCSM3i unit is ready to start receiving the program code. After the message, data transfer is started from the PC according to Kermit protocol. Parameters relating to the protocol are set as fixed at the receiving end and must be selected correspondingly at the transmission end before starting data transfer.

http://127.0.0.1:43231/NED/NED?action=retrieve&library=bsc_tcsm_rel_s13_v3_2008_09_25&identifier=mmlup&edition=0&language=en&coverage=global&encoding=xhtml_1_0&component=data&item=data&pointer=cmdup#cmdup

Test cases


On completion of data transfer a transfer successful message is displayed.

Pre-requirements

Test Execution The loading of the TCSM software is carried out via TR3A/E service terminal interface as follows. Module type can be: TR3, FPGA, DSP, ET

1. File loading order:

• TR3

• FPGA

• DSP

• ET

2. To start file transfer to TR3 card ZGU:TR3; PLEASE CONFIRM (Y/N) Y

/* PREPARING PROGRAM TRANSFER... SUCCESS */

TCSM3i IS READY TO RECEIVE PROGRAM CODE.

START KERMIT FILE TRANSFER FROM YOUR COMPUTER.

3.Instructions for file transfer:

- Start the file transfer from the tool bar [Transfer File] in Reflection 2. The file transfer dialog window of Reflection 2 opens. Take the following settings Kermit, Binary, Ask user

- Select the software-level-specific subdirectory C:\XXX from the directory.

- Select the file to be transferred.

- Start file transfer by pressing the right-hand button of the Transfer buttons.

- To start the file transfer, press the Transfer File button.

4. After file is transferred information is shown:

/* VERIFYING PROGRAM CHECKSUM... SUCCESS */

/* PREPARING PRIMARY PROGRAM LOCATION... SUCCESS */

/* MOVING PROGRAM TO PRIMARY LOCATION... SUCCESS */

/* VERIFYING PROGRAM CHECKSUM... SUCCESS */

Issue 1.0-0


/* PROGRAM TRANSFER SUCCESSFULLY COMPLETED */

/* COMMAND EXECUTED */

5. When the connection is up , restart the TR3E/TR3A : ZUU and after loading is finish wait until the unit is up with ZGT and verify the module version ZGI:TR3 6. Load next FPGA module ZGU:FPGA; , after loading is finish wait until the unit is up with ZGT and verify the module version ZGI:FPGA

7. Load next DSP modules ZGU:DSP; and choose 1 to T56_PXSX module. ZGU:DSP

PLEASE CONFIRM (Y/N) Y

SELECT DSP PROGRAM TO UPDATE:

NBR TYPE PAGE USED_SW ID STRING

1. PRI 58 * PID: T56_PXSX.PAC 1.9-0 09/05/19

2. COM 60 PID: T57_PXSX.PAC 1.9-0 09/05/19

3. COM 68 PID NOT FOUND

4. EXT 50 PID: T55_PXSX.PAC 1.28-0 08/02/13

ENTER NUMBER : 1

After loading is finish wait until the unit is up with ZGT. Update T57_PXSX to the unit choose 2 ZGU:DSP

PLEASE CONFIRM (Y/N) Y

SELECT DSP PROGRAM TO UPDATE:

NBR TYPE PAGE USED_SW ID STRING

1. PRI 58 * PID: T56_PXSX.PAC 1.9-0 09/05/19

2. COM 60 PID: T57_PXSX.PAC 1.9-0 09/05/19

3. COM 68 PID NOT FOUND

4. EXT 50 PID: T55_PXSX.PAC 1.28-0 08/02/13

ENTER NUMBER : 2

After loading is finish wait until the unit is up with ZGT. Verify the module versions with ZGI:DSP and ZGW

8. Load next ET SW module ZGU:ET; and after loading is finish wait until the unit is up with ZGT and verify the module version ZGI:ET;

Test cases


9. Restart the ET16 plug-in units if the ET software is updated: ZUP:ET,X;

Expected results Software is loaded correctly to the units. After software loading TCSM unit is in working state without irrelevant error logs or alarms.

Related documents

1.5 Feature implementation

1.5.1 Licence: Installation

Test case ID: RT000FE00005


Test purpose To verify the licence installation procedure

Pre-requirements Check the NED document: Licence Management in BSC

Test Execution 1) Transfer the licence files to the network element’s hard disks in to the LICENCE directory under root directory

2) Install the licences: MML command W7L. Licence file name is given in the command without extension (.xml). If no name is given, all licences found in the LICENCE directory are installed.

Syntax: ZW7L:<licence file name(s)>,<initial state>;

3) Set licence expiration warning date. If not given, then default 30 days, is used.

Syntax: ZW7E:<licence code(s)>:WPLEN=<warning period length>;

4) Check that installation was successful

Syntax: W7I:LIC,LIM; and ZW7I:FEA,FULL:FEA=<feature code(s)>;

http://127.0.0.1:43231/NED/NED?action=retrieve&library=bsc_tcsm_rel_s13_v3_2008_09_25&identifier=mmlup&edition=0&language=en&coverage=global&encoding=xhtml_1_0&component=data&item=data&pointer=cmdup#cmdup

Issue 1.0-0


5) Configure features that require configuration before activation. See 'feature activation manual'

6) Activate configured features

Syntax: ZW7M:FEA=<feature code(s)>:ON;

7) Check that activation was successful

Syntax: ZW7I:FEA,FULL:FEA=<feature code(s)>;

8) Verify necessary features functionality state

Expected Results The licence installation was succesfull and all necessary features are working correctly

Related documents Corresponding of following documents:

- NED document: Licence Management in BSC

-Licence-Based Feature Implementation

-feature activation manual

1.5.2 Licence: Unsuccessful installation



Test purpose To verify the licence installation procedure

Pre-requirements NED document: Licence Management in BSC

Test Execution 1) Transfer licence file to the network element’s hard disks in to the LICENCE directory under root directory

2) Install the licences: MML command W7L. Licence file name is given in the command without extension (.xml). If no name is given, all licences found in the LICENCE directory are installed.

Syntax: ZW7L:<licence file name(s)>,<initial state>;

Test cases


Expected Results Installation of the licence file fails.

Related documents Corresponding of following documents:

-NED document: Licence Management in BSC

-Licence-Based Feature Implementation

-feature activation manual

1.5.3 BSC3i upgrade from 660 to 1000



Test purpose To verify the BSC3i upgrade from 660 to 1000 procedure

Pre-requirements See pre-requirements of BSC3i upgrade from 660 to 1000 procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i upgrade from 660 to 1000 procedure

2) Write down to the TestMan Test Execution Report the document version as well as the HIT upgrade tool and script versions used in implementation

3) Attach zipped implementation log to the TestMan Test Execution Report

Expected results The BSC3i upgrade from 660 to 1000 procedure is successful and no new alarms found

Related documents Corresponding BSC3i upgrade from 660 to 1000 procedure

Issue 1.0-0


1.5.4 BSC3i extension from 1000 to 2000



Test purpose To verify the BSC3i extension from 1000 to 2000 procedure

Pre-requirements See pre-requirements of BSC3i extension from 1000 to 2000 procedure

Test execution Perform the feature implementation according to the corresponding BSC3i extension from 1000 to 2000 procedure document

Expected results The BSC3i extension from 1000 to 2000 procedure is successful without irrelevant alarms

Related documents Corresponding BSC3i extension from 1000 to 2000 procedure

1.5.5 BSC3i 660 upgrade from GSWB to GSW1kB for ET4



Test purpose To verify the BSC3i 660 upgrade from GSWB to GSW1kB for ET4 procedure

Pre-requirements See pre-requirements of BSC3i 660 upgrade from GSWB to GSW1kB for ET4 procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i 660 upgrade from GSWB to GSW1kB for ET4 procedure

Test cases


2) Write down to the Testman Test Execution Report the document version as well as the HIT upgrade tool and script versions used in implementation


Expected results The BSC3i 660 upgrade from GSWB to GSW1kB for ET4 procedure is successful and no new alarms found

Related documents Corresponding BSC3i 660 upgrade from GSWB to GSW1kB for ET4 procedure

1.5.6 BSC3i upgrade from 1000 to Flexi BSC



Test purpose To verify the BSC3i upgrade from 1000 to Flexi BSC procedure

Pre-requirements See pre-requirements of BSC3i upgrade from 1000 to Flexi BSC procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i upgrade from 1000 to Flexi BSC procedure



Expected results The BSC3i upgrade from 1000 to Flexi BSC procedure is successful and no new alarms found

Related documents Corresponding BSC3i upgrade from 1000 to Flexi BSC

Issue 1.0-0


1.5.7 BSC/PCU HW upgrade for PS traffic (GPRS/EDGE)



Test purpose To verify the BSC/PCU HW upgrade for PS traffic (GPRS/EDGE) procedure

Pre-requirements See pre-requirements of BSC/PCU HW upgrade for PS traffic (GPRS/EDGE) procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC/PCU HW upgrade for PS traffic (GPRS/EDGE) procedure

Expected results The BSC/PCU HW upgrade for PS traffic (GPRS/EDGE) procedure is successful and no new alarms found

Related documents Corresponding BSC/PCU HW upgrade for PS traffic (GPRS/EDGE)

1.5.8 BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection



Test purpose To verify the BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection procedure

Pre-requirements See pre-requirements of BSC/PCU HW upgrade for PS traffic (GPRS/EDGE) procedure

Test cases


Test execution Perform the feature implementation according to the corresponding document of BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection procedure

Expected results The BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection procedure is successful and no new alarms found

Related documents Corresponding BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection procedure

1.5.9 BSC3i/TCSM3i HW implementation for combined installation



Test purpose To verify the BSC3i/TCSM3i HW implementation for combined installation procedure

Pre-requirements See pre-requirements of BSC3i/TCSM3i HW implementation for combined installation procedure

Test execution Perform the feature implementation according to the corresponding document of BSC3i/TCSM3i HW implementation for combined installation procedure

Expected results The BSC3i/TCSM3i HW implementation for combined installation procedure is successful and no new alarms found

Related documents

Issue 1.0-0


Corresponding BSC3i/TCSM3i HW implementation for combined installation procedure

1.5.10 TCSM3i cabinet extension for combined BSC3i/TCSM3i procedure



Test purpose To verify the TCSM3i cabinet extension for combined BSC3i/TCSM3i procedure

Pre-requirements See pre-requirements of TCSM3i cabinet extension for combined BSC3i/TCSM3i procedure

Test execution Perform the feature implementation according to the corresponding document of TCSM3i cabinet extension for combined BSC3i/TCSM3i procedure

Expected results The TCSM3i cabinet extension for combined BSC3i/TCSM3i procedure is successful and no new alarms found

Related documents Corresponding TCSM3i cabinet extension for combined BSC3i/TCSM3i procedure

1.5.11 BSC3i upgrade from 660 to Flexi BSC (Offline procedure)



Test purpose To verify the BSC3i upgrade from 660 to 3000 (Offline implementation) procedure

Test cases


Pre-requirements See pre-requirements of BSC3i upgrade from 660 to 3000 (Offline implementation) procedure

Test execution 1) Perform the feature implementation according to the corresponding document of TCSM3i BSC3i upgrade from 660 to 3000 (Offline implementation) procedure



Expected results The BSC3i upgrade from 660 to 3000 (Offline implementation) procedure is successful and no new alarms found

Related documents Corresponding BSC3i upgrade from 660 to 3000 (Offline implementation) procedure

1.5.12 BSC3i upgrade from 2000 to Flexi BSC



Test purpose To verify the BSC3i upgrade from 2000 to 3000 procedure

Pre-requirements See pre-requirements of BSC3i upgrade from 2000 to 3000 procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i upgrade from 2000 to 3000 procedure

Issue 1.0-0




Expected results The BSC3i upgrade from 2000 to 3000 procedure is successful and no new alarms found

Related documents Corresponding BSC3i upgrade from 2000 to 3000 procedure

1.5.13 BSC3i 660 upgrade from AS7-B to AS7-C for signalling capacity



Test purpose To verify the BSC3i 660 upgrade from AS7-B to AS7-C for signalling capacity procedure

Pre-requirements See pre-requirements of BSC3i 660 upgrade from AS7-B to AS7-C for signalling capacity procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i 660 upgrade from AS7-B to AS7-C for signalling capacity procedure



Expected results The BSC3i 660 upgrade from AS7-B to AS7-C for signalling capacity procedure is successful and no new alarms found

Related documents

Test cases


Corresponding BSC3i 660 upgrade from AS7-B to AS7-C for signalling capacity procedure

1.5.14 BSC3i/TCSM3i ETIP1-A implementation for IP/PWE



Test purpose To verify the BSC3i/TCSM3i ETIP1-A implementation for IP/PWE procedure

Pre-requirements See pre-requirements of BSC3i/TCSM3i ETIP1-A implementation for IP/PWE procedure

Test execution Perform the feature implementation according to the corresponding document of BSC3i/TCSM3i ETIP1-A implementation for IP/PWE procedure

Expected results The BSC3i/TCSM3i ETIP1-A implementation for IP/PWE procedure is successful and no new alarms found

Related documents Corresponding BSC3i/TCSM3i ETIP1-A implementation for IP/PWE procedure

1.5.15 BSC3i ET cabinet extension for Flexi BSC



Test purpose To verify the BSC3i ET cabinet extension for Flexi BSC procedure

Pre-requirements See pre-requirements of BSC3i ET cabinet extension for Flexi BSC procedure

Test execution

Issue 1.0-0


Perform the feature implementation according to the corresponding document of BSC3i ET cabinet extension for Flexi BSC procedure

Expected results The BSC3i ET cabinet extension for Flexi BSC procedure is successful and no new alarms found

Related documents Corresponding BSC3i ET cabinet extension for Flexi BSC procedure

1.5.16 BSC3i upgrade from 660 to 1000 (Offline procedure)



Test purpose To verify the BSC3i upgrade from 660 to 1000 (Offline procedure)

Pre-requirements See pre-requirements of BSC3i upgrade from 660 to 1000 (Offline procedure)

Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i upgrade from 660 to 1000 (Offline procedure)

2) Write down to the TestMan Test Execution Report the document version as well as the HIT upgrade tool and script versions used in implementation


Expected results The BSC3i upgrade from 660 to 1000 (Offline procedure) is successful and no new alarms found

Related documents Corresponding BSC3i upgrade from 660 to 1000 (Offline procedure)

Test cases





Test purpose To verify the BSC3i upgrade from 1000 to Flexi BSC (Offline procedure)

Pre-requirements See pre-requirements of BSC3i upgrade from 1000 to Flexi BSC (Offline procedure)

Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i upgrade from 1000 to Flexi BSC (Offline procedure)



Expected results The BSC3i upgrade from 1000 to Flexi BSC (Offline procedure) is successful and no new alarms found

Related documents Corresponding BSC3i upgrade from 1000 to Flexi BSC (Offline procedure)




Test purpose To verify the BSC3i upgrade from 2000 to 3000 (Offline procedure)

Pre-requirements See pre-requirements of BSC3i upgrade from 2000 to 3000 (Offline procedure)

Issue 1.0-0


Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i upgrade from 2000 to 3000 (Offline procedure)



Expected results The BSC3i upgrade from 2000 to 3000 (Offline procedure) is successful and no new alarms found

Related documents Corresponding BSC3i upgrade from 2000 to 3000 (Offline procedure)

1.5.19 BSC ETIP1-A implementation for IP/PWE



Test purpose To verify the BSC ETIP1-A implementation for IP/PWE procedure

Pre-requirements See pre-requirements of BSC ETIP1-A implementation for IP/PWE procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC ETIP1-A implementation for IP/PWE procedure

2) Write down to the Quality Center (QC) Test Execution Report the document version as well as the HIT upgrade tool and script versions used in implementation

Expected results The BSC ETIP1-A implementation for IP/PWE procedure is successful and no new alarms found

Test cases


Related documents Corresponding BSC ETIP1-A implementation for IP/PWE procedure

1.5.20 BSC upgrade for SDH/Sonet equipment protection



Test purpose To verify the BSC upgrade for SDH/Sonet equipment protection procedure

Pre-requirements See pre-requirements of BSC upgrade for SDH/Sonet equipment protection procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC upgrade for SDH/Sonet equipment protection procedure


Expected results The BSC upgrade for SDH/Sonet equipment protection procedure is successful and no new alarms found

Related documents Corresponding BSC upgrade for SDH/Sonet equipment protection procedure

1.5.21 BSC upgrade from 660 to Flexi BSC 4200 (Offline procedure)



Issue 1.0-0


Test purpose To verify the BSC upgrade from 660 to Flexi BSC 4200 (Offline implementation) procedure

Pre-requirements See pre-requirements of BSC upgrade from 660 to Flexi BSC 4200 (Offline implementation) procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC upgrade from 660 to Flexi BSC 4200 (Offline implementation) procedure


Expected results The BSC upgrade from 660 to Flexi BSC 4200 (Offline implementation) procedure is successful and no new alarms found

Related documents Corresponding BSC upgrade from 660 to Flexi BSC 4200 (Offline implementation) procedure




Test purpose To verify the BSC upgrade from 1000 to Flexi BSC 4200 (Offline procedure)

Pre-requirements See pre-requirements of BSC upgrade from 1000 to Flexi BSC 4200 (Offline procedure)

Test execution

Test cases


1) Perform the feature implementation according to the corresponding document of BSC upgrade from 1000 to Flexi BSC 4200 (Offline procedure)


Expected results The BSC upgrade from 1000 to Flexi BSC 4200 (Offline procedure) is successful and no new alarms found

Related documents Corresponding BSC upgrade from 1000 to Flexi BSC 4200 (Offline procedure)




Test purpose To verify the BSC upgrade from 2000 to Flexi BSC 4200 (Offline procedure)

Pre-requirements See pre-requirements of BSC upgrade from 2000 to Flexi BSC 4200 (Offline procedure)

Test execution 1) Perform the feature implementation according to the corresponding document of BSC upgrade from 2000 to Flexi BSC 4200 (Offline procedure)


Expected results The BSC upgrade from 2000 to Flexi BSC 4200 (Offline procedure) is successful and no new alarms found

Related documents Corresponding BSC upgrade from 2000 to Flexi BSC 4200 (Offline procedure)

Issue 1.0-0


1.5.24 BSC upgrade from Flexi BSC 3000 to Flexi BSC 4200



Test purpose To verify the BSC upgrade from Flexi BSC 3000 to Flexi BSC 4200 procedure

Pre-requirements See pre-requirements of BSC upgrade from Flexi BSC 3000 to Flexi BSC 4200 procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC upgrade from Flexi BSC 3000 to Flexi BSC 4200 procedure


Expected results The BSC upgrade from Flexi BSC 3000 to Flexi BSC 4200 procedure is successful and no new alarms found

Related documents Corresponding BSC upgrade from Flexi BSC 3000 to Flexi BSC 4200 procedure

1.5.25 BSC implementation for ETP/ETP-A



Test purpose To verify the BSC implementation for ETP/ETP-A procedure

Test cases


Pre-requirements See pre-requirements of BSC implementation for ETP/ETP-A procedure

Test execution 1) Perform the feature implementation according to the corresponding document of BSC implementation for ETP/ETP-A procedure


Expected results The BSC implementation for ETP/ETP-A procedure is successful and no new alarms found

Related documents Corresponding BSC implementation for ETP/ETP-A procedure

1.5.26 TCSM implementation for ETP-A



Test purpose To verify the TCSM implementation for ETP-A procedure

Pre-requirements See pre-requirements of TCSM implementation for ETP-A procedure

Test execution 1) Perform the feature implementation according to the corresponding document of TCSM implementation for ETP-A procedure


Issue 1.0-0


Expected results The TCSM implementation for ETP-A procedure is successful and no new alarms found

Related documents Corresponding TCSM implementation for ETP-A procedure

1.5.27 Standalone TCSM3i implementation for ETP-A



Test purpose To verify the Standalone TCSM3i implementation for ETP-A procedure

Pre-requirements See pre-requirements of Standalone TCSM3i implementation for ETP-A procedure

Test execution 1) Perform the feature implementation according to the corresponding document of Standalone TCSM3i implementation for ETP-A procedure


Expected results The Standalone TCSM3i implementation for ETP-A procedure is successful and no new alarms found

Related documents Corresponding Standalone TCSM3i implementation for ETP-A procedure

1.5.28 Standalone TCSM3i ETIP1-A implementation for IP/PWE



Test cases


Test purpose To verify the Standalone TCSM3i ETIP1-A implementation for IP/PWE procedure

Pre-requirements See pre-requirements of Standalone TCSM3i ETIP1-A implementation for IP/PWE procedure

Test execution 1) Perform the feature implementation according to the corresponding document of Standalone TCSM3i ETIP1-A implementation for IP/PWE procedure


Expected results The Standalone TCSM3i ETIP1-A implementation for IP/PWE procedure is successful and no new alarms found

Related documents Corresponding Standalone TCSM3i ETIP1-A implementation for IP/PWE procedure

1.5.29 L3 BSC IP Site Connectivity upgrade



Test purpose To verify the L3 BSC IP Site Connectivity upgrade procedure

Pre-requirements See pre-requirements of L3 BSC IP Site Connectivity upgrade procedure

Test execution 1) Perform the feature implementation according to the corresponding document of L3 BSC IP Site Connectivity upgrade procedure

Issue 1.0-0



Expected results The L3 BSC IP Site Connectivity upgrade procedure is successful and no new alarms found

Related documents Corresponding L3 BSC IP Site Connectivity upgrade procedure

1.6 Call Cases

1.6.1 Location Updating

Test case ID: RT000CC00001


Test purpose To verify that BSC is working correctly in case of location updating

Pre-requirements -Check the status of the signalling network with BSC MML

-Check current alarms in the system

Test execution 1) Supply the PIN to the Mobile Station

2) Switch the mobile on

3) Check for any new alarms in system

4) Check computer logs for unexpected log writings

Expected results Mobile Station finds the network and ends in service state

Related documents

Test cases


None

1.6.2 MS to MS call



Test purpose To verify mobile phones correct working of the BSC in case of basic call

Pre-requirements -See frequency band used in the test from corresponding BSC Release Test Plan, ANSI/ETSI

-Check the status of the signalling network


Test execution 1) Call from subscriber A to subscriber B

-Make the call with different types of MSs


3) Verify the speech quality




7) Repeat the test several times with different mobiles (write down brand and model of used mobiles)

Note! It's highly recommendate to do this release test case with different speech codecs as FR, HR, AMR, etc.

Expected results -Call is successful with all used mobile phones

-Speech quality is good

Related Documents Corresponding BSC Release Test Plan, ANSI/ETSI

Issue 1.0-0


1.6.3 Emergency call



Test purpose To verify that emergency calls are set up correctly

Pre-requirements

MS with SIM card

Test execution 1) Make an emergency call with the MS when SIM card is inserted

2) Clear the call

3) Make an emergency call with the MS when SIM card is NOT inserted (applicable only if frequency of the mobile is locked)

4) Clear the call


6) Repeat steps 2-5 with the SM without SIM card

Expected results Emergency call is established successfully


1.6.4 Data call



Test purpose To verify the basic Circuit Switched data call

Pre-requirements PC and MS or data terminal

Test cases


Test execution 1) Make a basic data call


Expected results The call is established successfully and data transferred (9,6kB/s)

Related documents

C:\Documents and Settings\tkoppine\Des

1.6.5 SMS from MS to MS



Test purpose To verify the basic SMS functionality

Pre-requirements Two Mobile Stations supporting SMS

Test execution 1) Write an SMS message with MS 1

2) Send the message to MS 2


Expected results The message is sent from MS 1 and received successfully by MS 2


Issue 1.0-0


1.6.6 Data Call HSCSD



Test purpose To verify the HSCSD data call

Pre-requirements -PC and MS or data terminal

-pool 22 used in BSC (ZWGO)

-PRFILE feature HSCSD usage parameter value is 00FF (ZWOI:10,47)

-PRFILE feature DATA 144 usage parameter value is 00FF (ZWOI:10,48)

-Basic service B17and B1Fmust be on in HLR (ZMBO)

-Check (ZEDB:NAME=<BSC name>;) that following MSC parameters are enabled (YES):

MAX 2 TRAFFIC CHANNELS CAN BE USED IN HSCSD SERVICE

MAX 4 TRAFFIC CHANNELS CAN BE USED IN HSCSD SERVICE

14.4 KB RADIO INTERFACE DATA RATE SUPPORTED

If needs to be modified use ZEDT:VER=<BSSAP_version>:F,42,1; command (42 -> feature number).

Test execution 1) Make a HSCSD data call

2) Repeat the test several times with different at-commands (bit rates)

Expected results The call is established successfully and data transferred (14.4 kB/s)

Related documents

C:\Documents and Settings\tkoppine\Des

1.6.7 SMS from MS to MS over GPRS


Test cases



Test purpose To verify the basic SMS functionality over GPRS

Pre-requirements -Two Mobile Stations supporting SMS over GPRS

-Gs-interface configured

-NMO parameter value is 00 (ZEGO:PAR)

-SMS over GPRS activated in SGSN (ZW7I, licence nbr 335)

-Subscriber IMSI configured to HLR’s GPRS profile as following:

< MNO:IMSI=520181021511574; LOADING PROGRAM VERSION 6.5-0 HLRi DX220-LAB 2008-01-23 16:24:15 GPRS DATA PARAMETERS IMSI ........................ 520181021511574 SGSN ADDRESS ................ 49520606 MT-SMS VIA SGSN ............. Y CELL UPDATE INFORMATION ..... N NETWORK ACCESS .............. BOTH CHARGING CHARACTERISTIC ..... GPRS ROAMING PROFILE ........ N GPRS SERVICE AREA ........... ALL

Test execution 1) Write an SMS message with MS 1

2) Send the message to MS 2 over GPRS

3) Repeat the test at least two times with different mobiles (write down brand and model of used mobiles)

Expected results The message was sent from MS 1 over GPRS and received successfully to MS 2


Issue 1.0-0


1.6.8 MS to MS call using TTY devices



Test purpose To verify the correct working of the BSC in case of basic call with TTY-devices

Pre-requirements -Two TTY capable mobiles (example Nokia 3590)

-Two TTY equipments

-Check the status of the signaling network


Test execution 1) Call from subscriber A to subscriber B


3) Check that communication between TTY equipment works correctly to both directions


5) Check for new alarms in the system and computer logs


Expected results -Call was successful

-Text is properly sent and received by TTY equipments for both directions

-BSC Level Clear Code (SERLEV) measurement counter 057055 was updated


1.6.9 Dynamic Frequency Channel Allocation (DFCA)

Test case ID: RT000DF00001


Test cases


Test purpose To verify DFCA feature enabling and that calls succeed with DFCA hopping mode with defined MA-list frequencies. Also BIM table information shall be verified.

Pre-requirements - Activate DOUBLE_BA_LIST with command ZWOA:2,93,A;

- Activate DFCA licence (3).

- Site synchronization is used (LMU master). ZQWL; ZQWR:BCF=<bcf_id>:TRE=2: ZQWA:BCF=<bcf_id>:TRE=2:131:; ZQWL:BCF=<bcf_id>:; ZQUF:ALL:START:; ZEXI:; ZEXA:LMUA=<id>:BCF=<id>,TRE=2,:FNO=3,LTO=4,:; ZEFS:<bcf_id>:L; ZEFM:<bcf_id>:CS=LMU,SENA=T,; ZEFL; ZEFS:<bcf_id>:U;

- Nokia BTS SW release in UltraSite CX5

- Use eg. following kind of BTS configuration:

BCF

BTS-1

TRX-1 BCCH 1900

TRX-2 (DFCA)

BTS-2

TRX-3 BCCH 1900

TRX-4 (DFCA)

Same frequency band needs to be used.

Note! Nokia 6230i mobile doesn't show the frequencies. Use eg. N80 model.

Test execution 1) Set DFCA mode of all BTSs to STANDBY.

ZEQM:BTS=<bts_id>::::DMOD=1,;

2) Define the DFCA TRXs of the BTS

Issue 1.0-0


ZERM:BTS=1,TRX=2:DFCA=Y,;

3) Create adjacencies between BTSs (both directions)

ZEAC:BTS=1::ABTS=2:; ZEAC:BTS=2::ABTS=1:; . .

4) Create DFCA MA-lists and change list status to "DFCA in use". Attach lists to BTSs. MA-lists includes frequencies which are used only in DFCA TRXs. DFCA list must have equal length to any existing DFCA MA-list that has adjacent frequencies in it.

For example commands can be like this:

ZEBE:2001,1900:FREQ=788&789&796&797; ZEBE:2002,800:FREQ=188&189:; ZEBT:2001,C:MALS=IN:; ZEBT:2002,C:MALS=IN:; ZEQA:BTS=1:DMAL=2001,OPE=A,:; ZEQA:BTS=2:DMAL=2001,OPE=A,:;

5) Create also normal MA-list for unsynchronized use

ZEBE:1,1900:FREQ=788&790&798&799; ZEBE:2,800:FREQ=188&190:; ZEQA:BTS=1:DUMAL=1,; ZEQA:BTS=2:DUMAL=1,;

6) Modify DFCA parameters: Change BIM update period to 10 minutes and BIM guard time to 63

ZEEH:BUP=10,BUGT=63:;

7) Make few calls in every BTS and leave them on for 20 minutes. This is for collecting enough measurements to build up DFCA BIM tables. You can printout BIM tables with ZEQI-command. Do not lock frequencies in MS. You can modify power control parameters to get calls attached each BTS (ZEUG).

8) Change DFCA mode to DFCA HOPPING

ZEQM:BTS=1::::DMOD=2,;

9) Make call again and check that DFCA MA-list frequencies are used in MS. Check BIM tables.

ZEQI:BTS=<bts_id>:ALL;

Expected results Calls are successful in DFCA hopping mode using DFCA MA-lists.

Test cases


With above BTS examples:

From BTS1 in and outgoing BIM-table includes BTS2 and BTS3 frequencies. From BTS2 in and outgoing BIM-table includes BTS1 and BTS3 frequencies.


1.7 Handovers

1.7.1 Inter Cell Handover

Test case ID: RT000HO00001


Test purpose To verify the BSC will function correctly in case of internal inter cell handover

Pre-requirements -The adjacent cell list includes only one cell (BTS2), which belongs to the same BSC as the source cell. Check with ZEAO and create with ZEAC commands.

-Check the status of the signalling network with BSC MML


-Check that there are free TCHs on the BTS

Test execution 1) Make a handover to subscriber A. Parameters are set into database so that inter cell handover will be a result of algorithm. (dl qual < 0.2 %, BTSs are defined as adjacent cells to each others: ho_margin = -24dB)

ZEHQ:BTS=<index>,.. QDR = 0, QDP = 1, QDN = 1

ZEAM:BTS=<index>,...QMRG=-24, MRGS=Y;

2) Call from subscriber A to B


4) Verify speech quality


Issue 1.0-0


Note! It's highly recommondate the release test configuration include the 2nd, 3rd and 4th generation BTSs.

Expected results -The handover succeeds and speech quality is good the whole time

-The TCH of BTS1 is released


1.7.2 Inter System Handover (ISHO)



Test purpose The purpose of the GSM-WCDMA Inter-System Handover feature is to enable the mobile to re-select a WCDMA RAN cell while camping on the GSM cell and to enable the BSC to initiate a handover from a GSM cell to a WCDMA RAN cell.

Pre-requirements -Make sure that all interfaces between BTS, BSC, 3G MSC, RNC and WBTS and also network elements are configured and working properly.

-Also make sure that both the optional features and software packets, which are required for enabling GSM-WCDMA interworking functionality, are activated and in use in each participating network element.

-MS Dual mode GSM/WCDMA mobile which support UMTS

-BTS Nokia BTS SW release, which support sending of new information elements

-WBTS Nokia WCDMA BTS

-3G MSC that support Iu and A-int

Test execution 1) Define an adjacent cell under a RNC for the BTS

2) Set the threshold for MSs to measure WCDMA RAN cells while camping on a GSM cell

3) Define the threshold for non-GPRS capable MSs

Test cases


4) ZEQM:BTS=<BTS identification>:::QSRI=7;

5) ZEHN:BTS=<BTS identification>:QSRC=7;

6) ZEHN:BTS=<BTS identification>: LTSC =35;

7) ZEAH:BTS=<BTS identification>:INDEX=<adjacent cell index>:MET=18;

8) ZEHN:BTS=<BTS identification>:UAWS=1;

9) ZEHN:BTS=<BTS identification>:UNOZ=0;

10) ZEHN:BTS=<BTS identification>:UAAC=Y;

11) Create/modify BSC level clear code measurement by command TPM:MEASUR,CC_PM:ALL,0-0-24-0,15:;

12) Start created measurement (ZTPS)

13) Wait until the measurement is unlocked enabled state (ZTPI)

14) Set up two calls to source BTS. No handovers will be made

15) Setup a third call to source BTS

16) The minimum traffic load for a speech call of the source BTS is exceeded and based on the radio link measurements HO is triggered

17) Wait for one minute

18) Disconnect the call

19) Verify handover

20) Verify that the counter number 051152: ext_out_isho or 051151 ext_in_isho is updated

21) Check the next possible measurement number which is written to OMU disk (BSCSTA directory) by command ZIFI:OMU:MEASUR:S:;

22) Verify that counter number 051152: ext_out_isho or 051151 ext_in_isho is updated

For example first copy the measurement file from OMU BSCSTA directory to PC. Then convert file to .TXT format (with MEFICO) and check the needed information from file.

Note! It's highly recommondate the release test configuration include the 2nd, 3rd and 4th generation BTSs.

Expected results -MS is handing over and speech quality is good the whole time


Issue 1.0-0


1.7.3 Inter BSC Handover S14 SW release – S15 SW release



Test purpose To verify the BSC will function correctly in case of inter cell handover, cells connected to the BSCs with old and new SW release

Pre-requirements -The adjacent cell list includes only one cell (BTS2), which belongs to the BSC with previous SW release level. Check with (ZEAO) and create with (ZEAC)




Test execution 1) Set up HO parameters causing both MSs handing over from BTS1 to BTS2 and vice versa continously:

(dl qual < 0.2 %, BTSs are defined as adjacent cells to each others: ho_margin = -24dB)

ZEHQ:BTS=<index>,QDR=0, QDP=1,QDN=1;

ZEAM:BTS=<index>,...QMRG=-24,MRGS=Y;

2) Call from subscriber A to B, both are connected to either BTS1 or BTS2




Note! It's highly recommended the release test configuration include the 2nd, 3rd and 4th generation BTSs.

Expected results -Both MSs are handing over all the time and speech quality is good the whole time


Test cases


1.7.4 Inter BSC Handover



Test purpose To verify the BSC will function correctly in case of inter BSC handover, cells connected to the two BSCs with new SW release

Pre-requirements -The adjacent cell list includes only one cell (BTS2), which belongs to the other BSC with the same new SW release level. Check with (ZEAO) and create with (ZEAC)




Test execution 1) Set up HO parameters causing both MSs handing over from BTS1 to BTS2 and vice versa continuously: (dl qual < 0.2 %, BTSs are defined as adjacent cells to each others: ho_margin = -24dB)

ZEHQ:BTS=<index>,QDR=0,QDP=1,QDN=1;

ZEAM:BTS=<index>,...QMRG=-24,MRGS=Y;

2) Call from subscriber A to B, both are connected to either BTS1 or BTS2




Note! It's highly recommondate the release test configuration include the 3rd and 4th generation BTSs.

Expected results -Both MSs are handing over all the time and speech quality is good the whole time


Issue 1.0-0


1.8 GPRS Call

1.8.1 GPRS: Attach & PDP Context

Test case ID: RT000GP0001


Test purpose To verify the mobile phone attach to cell and PDP context activation

Pre-requirements - GPRS mobiles

- Gb-if is created



- GPRS connection parameters of PCs are correctly configured


Test Execution 1) Mobile is not attached to cell or it has not PDP context activated

2) Activate PDP context


Expected Results -PDP context activation succeeds


1.8.2 GPRS: FTP download



Test cases


Test purpose To verify that the GPRS download succeeds

Pre-requirements -GPRS mobiles

-Gb-if is created






Test Execution 1) Activate PDP context

2) Start downloading packages from FTP address (Use FTP command from DOS prompt), get


4) Repeat 2 and 3 several times

5) Check that there is no abnormal alarms and log writings in MCMU and BCSU

Expected Results - Downloading succeeds



1.8.3 GPRS: Several mobiles at the same cell



Test purpose

Issue 1.0-0


To verify that the GPRS download succeeds

Pre-requirements - GPRS mobiles

- Gb-if is created

- GPRS feature (licence 673) activated and used in one cell at least (ZW7I to check the licence)


- GPRS connection parameters of PCs are correctly configured

- Throughput monitoring application installed to PCs


Test Execution 1) Activate PDP contexts in three or more mobiles

2) Start downloading data simultaneously from FTP address (Use FTP command from DOS prompt)

3) Wait until files are downloaded


Expected Results Download succeeds

Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)


1.8.4 GPRS: Data transfer after GENA Y/N



Test purpose To verify that the GPRS download succeeds

Test cases



-Gb-if is created





-Check that there is no abnormal alarm or log writings in MCMU and BCSU


2) Start downloading packages from FTP or HTTP address

3) Change GENA parameter in the cell to N with command ZEQV:BTS=<BTS_id>:GENA=N;

4) Downloading is interrupted

5) After it fails, change GENA parameter again to Y


7) Start downloading packages again


Expected Results -Download succeeds after GPRS is activated to the BTS

-Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)


1.8.5 GPRS: FTP upload



Test purpose To verify that the GPRS upload succeeds

Issue 1.0-0



-Gb-if is created







2) Start uploading packages (approximately 3-5MB) to FTP address (Use FTP command from DOS prompt)

3) Wait until file is uploaded



Expected Results -Uploading succeeds without abnormal alarms or log writings

-Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)


1.8.6 GB: Frame Relay Creation



Test Purpose Creating and activating the Gb interface when Frame relay is used

Test cases


Pre-requirements BSC with required hardware and SGSN

Test Execution 1) Create a bearer channel to the PCU by command:

ZFUC:<bearer channel id>,<bearer channel name>:<access rate>:<external PCM>,<first external tsl>:<unit type>,<unit index>,<piu index>;

2) Create NSVC to the bearer channel by command:

ZFXC:NSVCI=<nsvc id>,NAME=<nsvc name>,NSEI=<nsei>:DLCI=<data link connection identifier>,CIR=<committed information rate>:BCI=<bearer channel identification>,;

NSVCI, NSEI, CIR and DLCV must be created to SGSN with identical values.

3) Change state of the NSVCI by command:

ZFXS:NAME=<network service virtual connection identifier>:<state>;

Or

ZFXS:NSVCI=<network service virtual connection name>:<state>;

4) Check the creation and state by command: ZFUI;

ZFXO:NSVCI=<network service virtual connection identifier>;

5) To enable GPRS in BSC, next you must activate GPRS on a cell level.

Expected Results -Configurations and GPRS activation in a cell(s) are successful

-BSC is able to handle CS/PS traffic

-No alarms occurred

-No log writings to Computer logs

Related documents NED – Integrate – Gb Interface – Enabling GPRS in BSC

1.8.7 GB: Gb over IP Creation (static/dynamic)



Test Purpose Creating and activating the Gb interface when IP is used.

Issue 1.0-0


The Gb interface between the BSC and SGSN is established in three phases: first you configure the IP address, then you configure the network service (NS) layer and finally, you enable GPRS. The system builds the base station system GPRS protocol (BSSGP) virtual connections automatically when GPRS is enabled on a cell level.


-You must have the Gb over IP licence installed and activated. The licence is based on capacity, that is, the number of PCUs.

-In the static IP configuration it does not matter which end of the interface you configure first.

-In the dynamic IP configuration, you should first configure the SGSN end of the interface. This is because the BSC will attempt to run the size and configuration procedures immediately after creating the IP NS-VC.

-Both IPv4 and IPv6 are supported in the Nokia implementation of Gb over IP. Configuration of the PCU IP stack is handled with the commands of command group QR when IPv4 is used and with the commands of the command group Q6 when IPv6 is used.

-If you want to use the DNS name parameter instead of IP address with either configuration, you must first configure the DNS server address to the BSC with the MML command QRK or Q6K , and the DNS server must be properly configured.




Test Execution 1) Check that the Gb over IP licence is active (ZW7I) by command:

ZW7I:FEA,FULL:FEA=7;

For more information on activating licences, see Licence-based Feature Management

2) Create network interfaces (ZQRA). Interfaces must be created to all BCSUs/PCUs (also spare units).

ZQRA:<unit type>,<unit index>:<plug-in unit type>,<plug-in unit index>:<interface name>::UP;

3) Configure IP addresses (QRN). Use logical IP addresses in both dynamic and static configuration.

ZQRN:<unit type>,<unit index>:<plug-in unit type>,<plug-in unit

index>:<interface name>:<IP address>,<netmask lenght>,L;

4) Create static route(s) (ZQKC) (optional) by command:

Test cases


ZQKC:<unit type>,<unit index>:<plug-in unit type>,<plug-in unit index>:<destination IP address>,<netmask length>:<gateway IP address>:<route type>;

5) Check the IP configuration (QRI) (optional) by command:

ZQRI:<unit type>,<unit index>:<plug-in unit type>,<plug-in unit index>:<interface name>:<display unit's attached interfaces>;

6) Create a packet service entity (PSE) (FXA) by command:

ZFXA:PSEI=<packet service entity identifier>,BCSU=<base station controller signalling unit>,PCU=<packet control unit>;

7) To implement this step, choose one of the following alternatives:

7.1) Create the network service virtual link (NS-VL) using dynamic IP configuration (FXK).

Note especially that the network service entity identifier (NSEI) must be the same at both ends of the Gb interface. Also remote end parameters (NSEI and IP address) in the BSC Gb interface configuration must match the corresponding local parameters of the SGSN. In the dynamic configuration, UDP port is preconfigured in the SGSN BSS interface parameters. This parameter must also match with the parameter in the BSC.

ZFXK:NSVLI=<network service virtual link identifier>,NAME=<network service virtual link name>,NSEI=<network service entity identifier>,PSEI=<packet service entity identifier>:LPNBR=<local UDP port number>,PRE=Y:RIP=<remote IP address>,RPNBR=<remote UDP port number>;

You can only create one NS-VL per NSE in the BSC. The maximum number of local endpoints is one. The maximum number of remote endpoints is four with PCU1, and 16 with PCU2. Note that the remote IP address (RIP) parameter determines whether the local IP address that is used is of the IPv4 or IPv6 type. The remote and local ends of the NS-VL must use the same address type. Both address types can be simultaneously configured to the PCU.

If you use the remote host name (RHOST) parameter instead of the remote IP address (RIP) parameter, the PCU will use whichever address type is configured to it. If both types are configured, IPv4 is the default type.

7.2) Create the network service virtual link (NS-VL) using a static IP configuration (FXK).

Especially note that the NSEI must be the same at both ends of the Gb interface. Also remote end parameters (NSEI, IP address, and UDP port) in the BSC Gb interface configuration must match the corresponding local parameters of the SGSN.

ZFXK:NSVLI=<network service virtual link identifier>,NAME=<network service virtual link name>,NSEI=<network service entity identifier>,PSEI=<packet service entity identifier>:LPNBR=<local UDP port number>,PRE=N:RIP=<remote IP address>,RPNBR=<remote UDP port number>,RDW=<remote data weight>,RSW=<remote signalling weight>;

If you want to use load balancing between remote IP endpoints (NS-VLs), or if you want to use different IP endpoints for signalling and data traffic, create

Issue 1.0-0


more remote IP endpoints (NS-VLs) with the FXK command. The maximum number of local end points is one. The maximum number of remote endpoints is four with PCU1, and 16 with PCU2.

8) Check the creation and state (FXI)

ZFXI:NSVCI=<network service virtual link identifier>;

9) Take the just created Gb over IP connection in use for cell in BTS (ZEQV)






Expected Results -Configurations and GPRS activation in a cell(s) are successful

- Download succeeds






1.8.8 GB: Gb over IP Modification (static/dynamic)



Test Purpose The purpose of the test is verify the modification of Gb over IP configuration


Test cases


-Gb over IP Licence activated

-Gb over IP configured




Test Execution 1) Deactivate GPRS (GENA=N)

2) Modify the NSVC's (ZFXJ)

-Modify also NSVC in SGSN

-If static, modify RDW and/or RSW parameters

-If dynamic, only the name can be modified






Expected Results - Modification done successfully

- BSC is able to handle CS/PS traffic

- FTP download succeeds





1.8.9 GB: Gb over IP LAN break


Issue 1.0-0



Test Purpose Purpose of this test case is to verify that BSC recovers from Gb over IP LAN break

Pre-requirements -BSC with required hardware and SGSN

-Gb over IP interface created and Gb channels used in one cell at least





Test Execution 1) Verify PS traffic handling capability

2) Disconnect Gb over IP LAN while ongoing PS calls

-LAN Break over 4s

3) Output the Gb over IP link (by command ZFXI) and wait until the state of Gb over IP link is WO-EX.

4) Test that Gb over IP link carries PS traffic normally

5) Disconnect Gb over IP LAN while ongoing PS calls

-Short LAN Break under 1s

6) Output the Gb over IP link (by command ZFXI) and wait until the state of Gb over IP link is WO-EX.

7) Activate PDP context in three or more mobiles and start sending ping


Expected Results - Gb over IP interface recovered after physical connection corrected

- BSC is able to handle PS traffic after Gb over IP interface recovered

- PDP context activation succeeds and sending ping is successful

- Alarms indicating LAN break and interrupt on GPRS service

- After Gb over IP link breaks while FTP downloads tested no log writings should appear to Computer logs

Test cases


Related documents NED – Integrate – Gb Interface – Enabling GPRS in BSC – Creating and activating the Gb interface when IP is used

1.8.10 GPRS/EDGE: HSCSD call allocation in GPRS territory



Test purpose To verify that HSCSD call can be allocated into GPRS territory




-HSCSD feature activated (ZWOI:10,48; and ZWOI:10,47;)



Test Execution 1) Set the GPRS default territory size so that 1 tsl left CS traffic channel by command: ZEQV:BTS=<index>:CDED=1,CDEF=80,CMAX=100;

2) Start HSCSD call ( 3+1 ), GPRS territory upgrade

3) Stop HSCSD call



6) Repeat downloading several times.



Expected Results - HSCSD call successful

Issue 1.0-0


- GPRS territory upgraded successfully after HSCSD call

- FTP download succeeds




Related documents NED – Descriptions – Feature Descriptions – Data – (E)GPRS in BSC

1.8.11 GPRS/EDGE: NCCR



Test Purpose To verify NCCR feature enabling and Network Controlled Cell Reselection procedure and Measurement report parameter can be modified

Pre-requirements -Parameter NCCR Control mode = 0 (ZEEO:GEN:;)

-No adjacency between cell1 and cell2

-Gb interface created



Test execution 1) Modify and start PCU and CRS measurements

2) Attach and execute PDP context activation to cell1

3) Change Parameter NCCR Control mode = 4 (ZEEM::NCM=4;)

4) Change PRFILE parameter NCCR measurement report type from PEMR to PMR (ZWOC…)

5) Create adjacency between cell1 and cell2 (Report type modification solely doesn’t change SI-messages)

6) Establish EGPRS PSW-call and start FTP data transfer in cell1

7) Increase the power of cell2 and decrease the power of cell1

Test cases


Expected Results -PDP context activation succeed

-NCCR measurement report type change succeed

-EGPRS PSW-call successfully established and FTP data transfer started in cell1

-Network controlled cell reselection is done for MS to cell2 (Data transfer continues in new cell)

-MS sends cell update to SGSN

-Check from service terminal (RENFST) that no TBF in cell1

-NCCR counters are updated (095012/095013/095014/095015)

Related documents NED – Test and Activate – Data – BSS11112: NCCR, BSS20394: ISNCCR, and BSS115006: NACC

NED – Descriptions – Feature Descriptions – Data – NetworkControlled Cell Re-selection

1.8.12 GPRS/EDGE: NACC



Test Purpose Enable NACC feature and verify NACC assists cell change between two cells within the same BSC

Pre-requirements - Abis-interface is created for BCSU 1

-A-interface is created for BCSU 2

-One BCSU is spare unit

-Two cells are created in the BSC. Cell1 (EGPRS enabled) and cell2 (GPRS enabled)

-GPRS MS

-Check licence status of NACC, NCCR and PCU/PCU2 (ZW7I)

-NACC disabled (ZEEM:NACC=N,;)

-Network control mode is set to NC0 (ZEEM::NCM=0,;)

Issue 1.0-0


Test Execution 1) Modify and start PCU and CRS measurements

2) Attach and execute PDP ctx activation to cell1

3) Change NACC enabled (ZEEM:NACC=Y,;)

4) Establish EGPRS PSW-call and start FTP uplink data transfer in cell1

5) Increase the power of cell2 and decrease the power of cell1

Expected Results - PDP ctx activation succeed

- EGPRS PSW-call successfully established and FTP data transfer started in cell1

-Cell reselection is done for MS to cell2 (Verify from service terminal that no TBF in cell1)

-Measurements come at correct intervals at correct times. NACC is activated if counter 095017 NACC WITH NC0 (among others). NACC is activated if counter 095018 NACC WITH NC2 (among others). PCU2 counter NACC WITH NC0/NC2 was updated (PCU2 command: dscaw 95).

Related documents NED – Test and Activate – Data – BSS11112: NCCR, BSS20394: ISNCCR, and BSS115006: NACC

NED – Descriptions – Feature Descriptions – Data – NetworkControlled Cell Re-selection

1.8.13 GPRS/EDGE: MT CS call during data transfer



Test Purpose Purpose of this test case is to verify that GPRS call is suspended when CS MT call is started and then resumed after CS call is released

Pre-requirements -One BCF with one BTS / 1 TRX, (E)GPRS enabled, GPRS/EDGE capable mobile

-Check licences of GPRS/EDGE and PCU/PCU2

Test Execution

Test cases


1) Start HTTP/FTP data transfer with GPRS/EDGE phone

2) Make a CS call to phone in HTTP/FTP data transfer

3) Maintain CS call for 15 seconds.

4) Release CS call

Expected Results -FTP data transfer is suspended

-CS call is successful

-FTP data transfer continues after CS call is released

-No alarms occurred



1.8.14 GPRS/EDGE: CS SMS during data transfer



Test Purpose Purpose of this test case is to verify that GPRS/EDGE data transfer continues without interrupts during CS SMS

Pre-requirements -Network Operation Mode II (No Gs interface between MSC - SGSN)

-One BCF with one BTS / 1 TRX, GPRS/EDGE enabled , GPRS/EDGE capable mobile


Test Execution 1) Start HTTP/FTP data transfer with GPRS/EDGE phone

2) Send SMS to phone in HTTP/FTP data transfer

Expected Results -SMS received successfully and data transfer continues without interruptions while receiving SMS

Issue 1.0-0


-No alarms occurred



1.8.15 GPRS/EDGE: Cell change during data transfer



Test Purpose Purpose of this test case is to verify cell change procedure during data transfer

Pre-requirements -Two BCF with one BTS / 1 TRX, (E)GPRS enabled , GPRS/EDGE capable mobile


-Create adjacency between Cells

-Define BTS1 PMAX parameter to its highest by command: ZEUG:BTS=<bts_id>:PMAX=30;

-Define BTS2 PMAX parameter to its lowest by command: ZEUG:BTS=<bts_id>:PMAX=0;

-Define maximum amount of Dedicated GPRS channels to BTSs ZEQV:BTS=<bts_id>:CDEF=100,CDED=100;

-Enable GPRS in both BTSs by command: ZEQV:BTS=<bts_id>:GENA=Y;

-Enable EGPRS in BTS1 by command: ZEQV:BTS=<bts_id>:EGENA=Y;

-Unlock both BTSs by command: ZEQS:BTS=<bts_id>:U;

Test Execution 1) Start HTTP/FTP data transfer with GPRS/EDGE phone

2) Adjust power control parameters in both BTSs so that Cell Change is possible by command: ZEUG:BTS=<bts_id>:PMAX=<X dB>;

Expected Results -File transfer completed successfully after cell change

-No alarms occurred

Test cases




1.8.16 GPRS/EDGE: Extended UL TBF



Test Purpose To verify it is possible to continue data transfer with the old TBF when the releasing of uplink TBF is delayed

Pre-requirements -Check licences of GPRS/EDGE and PCU/PCU2

-Working GPRS/EGPRS environment with PBCCH/without PBCCH

-PCU Measurements started ( ZTPM, ZTPS )

-1 BTS with CCCH, 1 EDGE-TRX and at least 2 TSLs

-Extended UL TBF feature activated EXT_UTBF_USAGE (ZWOS:2,899;)

-Modify value of parameter UL_TBF_REL_DELAY_EXTENDED to 3 s (BB8h) ZWOC:46,71,BB8;

Test execution 1) Start ftp data transfer to uplink

2) Have a break shorter than extended state delay timer (3s), and continue data transfer with a new BSN

3) Check operation when mobile supports and doesn't support extended mode

-Even if the MS doesn't support Extended UL TBF Mode, the PCU may delay the UL TBF release by 0.5s by default (046:0068 UL_TBF_RELEASE_DELAY)

Expected Results -Data transfer continued after break

-The counters 72115 UL DATA CONT AFTER COUNTDOWN and 72116 EXTENDED UL TBFs updated

-No alarms occurred


Issue 1.0-0


Related documents -NED – Descriptions – Feature Descriptions – Data – (E)GPRS in BSC

-NED – Reference – Parameters – PRFILE and FIFILE – Parameter Class 046 – Parameter 046:0071 UL_TBF_REL_DELAY_EXT

1.8.17 GPRS/EDGE: CS3&CS4



Test purpose To verify that coding schemes CS3 and CS4 works correctly

Pre-requirements -Dynamic Abis feature activated ZWOS:2;

-Check licences of GPRS/EDGE, CS3&CS4 and PCU2 ZW7I:FEA,FULL:FEA=2&4&7&12&13;

-PCU2 plug-in units installed ZWTI:P:BCSU,<unit index>:<correct pcu2 plug in unit type>;

-Create network configuration that has one BTS with EGPRS capable TRX

-Configurate the BTS as an EGPRS-CS1-CS4 territory

-Define maximum amount of Dedicated GPRS channels to TRX’s ZEQV:BTS=<bts_id>:CDEF=100,CDED=100;

-Define initial CS for ack mode to be 4 by command: ZEQV:BTS=<bts_id>:UCSA=3,DCSA=3;

-Enable GPRS by command: ZEQV:BTS=<bts_id>:GENA=Y,EGENA=N;

-Unlock BTS by command: ZEQS:BTS=<bts_id>:U;



Test Execution -Execute attach and activate PDP context with EGPRS MS

-Start data transfer downlink through MS (Select large file > 50MB)

1) Lock BTS and set CS3 or CS4 enabled by command:

Test cases


ZEQS:BTS=1:L;

ZEQV:BTS=1:GENA=Y,EGENA=N,CS34=Y,ALA=N;

2) Change coding scheme parameter by command:

ZEQV:BTS=1,DCSA=2,UCSA=2;

3) Unlock BTS

4) Make ACK RLC data transfer

5) Change coding sceme parameter by command:

ZEQV:BTS=1,DCSA=3,UCSA=3;

6) Make ACK RLC data transfer

Expected results - MS use coding scheme CS3 or CS4, check by command: dtrxtbf <bts id> <trx id> (PCU2 command)

- Download succeeds






1.8.18 Gb: Frame Relay Modification



Test Purpose The purpose of the test is verify the modification of frame relay channel

Pre-requirements -BSC with GPRS capable BTS, required hardware and SGSN

-Gb interface with Frame Relay channel



Issue 1.0-0




Test Execution 1) Deactivate GPRS (GENA=N)

2) Change state of the NSVCI to LOCKED (ZFXS)

3) Delete NSVCI (ZFXD)

4) Modify the the bearer channel (ZFUM)

-Modify the access rate and timeslots

-Modify also bearer channel in SGSN

5) Create NSVCI (ZFXC)

6) Change state of the NSVCI to UNLOCKED (ZFXS)






Expected Results -Frame Relay modified successfully

-BSC is able to handle CS/PS traffic

- Download succeeds





1.8.19 Gb: PCM break on Gb interface



Test cases


Test Purpose Purpose of this test case is to verify that BSC recovers from Gb PCM break

Pre-requirements -BSC with GPRS capable BTS, required hardware and SGSN

-Gb interface with Frame Relay channel





Test Execution 1) Verify CS/PS traffic handling capability

2) Make break for PCM which is controlling Gb interface (by disconnecting and connecting PCM) while ongoing CS and PS calls

-PCM Break over 4s

3) Make break for PCM which is controlling Gb interface (by disconnecting and connecting PCM) while ongoing CS and PS calls

-Short PCM Break under


-Make the call with different types of MSs





9) Repeat the CS call several times with different mobiles (write down brand and model of used mobiles)






Expected Results

Issue 1.0-0


-Call is successful with all used mobile phones

-Gb interface recovered after physical connection corrected

-BSC is able to handle CS traffic during PCM break

-BSC is able to handle PS traffic after Gb interface recovered

-Alarms indicating PCM break and interrupt on GPRS service

- PDP context activation succeeds after PCM break


1.8.20 GPRS/EDGE: Territory upgrades and downgrades



Test Purpose Purpose of this test case is to verify GPRS/EDGE territory upgrade/downgrade procedures

Pre-requirements -GPRS/EDGE and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)

-Set GPRS territory update guard time is set to 1 s (GTUGT) and safety margins to 0 by command: ZEEN:GTUGT=1,: and ZEEM:CSD=0,CSU=0,;



Test Execution Execute following steps 1-10 three times. Before each test sequence modify with ZEQV command GPRS parameters CDED/CDEF/CMAX (values are counted when 1 TRX used) to have following values:

CDED=40, CDEF=1, CMAX=100



1) Check the GPRS territory size

2) Start HTTP/FTP data transfer

Test cases


3) Check the GPRS/EDGE territory size


5) Check the GPRS/EDGE territory size




Expected Results -GPRS/EDGE territory upgraded after starting data transfer and downgraded successfully after data transfer finished





1.8.21 GPRS: DTM and EDA&HMC interworking



Test purpose To verify DTM feature enabling and CS&PS traffic continuing in DTM-mode when EDA&HMC features are enabled.

Pre-requirements - Gs-Interface

- NMO mode 0 (ZEGO:PAR)

- PCU2 is controlling Gb-if

- DTM capable MS (eg. N80)


- GPRS and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)

- EDA and HMC licences ON

- CDED=0 and CDEF=1

Issue 1.0-0


Test execution 1) Change DTM-mode enabled (ZEQV:BTS=X::::DENA=Y;)

2) Make CS-call

3) Attach and execute PDP context activation to cell which already handles CS call

4) Start Data transfer

5) Disconnect PS-call

6) Verify that CS call is still on

Expected results - DTM enabled successfully

- CS call is successfully established, MS in DTM-mode

- PDP contex activation succeed

- Data transfer started

In ZEEI-command, CH6 marked DT, CH5&7 is GP ddimsi all (PCU2 command)

- CS-call is continuing In ZEEI-command, no DT marked RTSL's


1.8.22 GPRS: Dual Transfer Mode (DTM)



Test purpose To verify DTM feature enabling and CS&PS traffic continues in DTM-mode.

Pre-requirements - Gs-Interface

- NMO mode 0 (ZEGO:PAR)

- PCU2 is controlling Gb-if

- DTM capable MS


Test cases


-GPRS and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)

Test execution 1) Change DTM-mode enabled (ZEQV:BTS=X::::DENA=Y;)

2) Make CS-call

2) Attach and execute PDP context activation to cell which already handles CS call

3) Start Data transfer

5) Disconnect PS-call

6) Verify that CS call is still on

Expected results - DTM enabled succesfully

- CS call is succefully established

- PDP ctx activation succeed

- Data transfer started

-> In ZEEI-command, CH7 marked DT

- CS-call is continuing

-> In ZEEI-command, no DT marked RTSL's


1.9 EGPRS Call

1.9.1 EGPRS: Data transfer after GENA Y/N

Test case ID: RT000ED0005


Test Purpose To verify that the EDGE download succeeds

Pre-requirements

Issue 1.0-0


-EDGE capable GPRS mobiles

-Gb-if is created

-GPRS/EDGE and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)




2) Start downloading packages from FTP or HTTP address

3) Change GENA parameter in the cell to N with command ZEQV:BTS=<BTS_id>:GENA=N;

4) Downloading is interrupted

5) After it fails, change GENA parameter again to Y


7) Start downloading packages again


Expected Results -Download succeeds after EDGE and GPRS are activated to the BTS

Related Documents None

1.9.2 EGPRS: Create DAP pool



Test purpose To verify that the DAP pool can be created.

Pre-requirements -EDGE capable GPRS mobiles

-Gb-if is created

Test cases



-Dynamic Abis feature is active in the BSC (ZWOA:2,644,A;)

-EDGE capable BTS


Test Execution 1) Lock the BTS and change GENA=N, EGENA=N (ZEQS) (ZEQV)

2) Create a DAP to BSC (ZESE)

3) Attach DAP to the TRX (ZERC)

4) Unlock the TRX (ZERS)

5) Activate GENA=Y and EGENA=Y parameters for BTS (ZEQV)

6) Unlock the BTS (ZEQS)






Expected Results - DAP creation successful

- Download succeeds



1.9.3 EGPRS: Delete DAP



Test purpose To verify that the DAP pool can delete

Issue 1.0-0



-Gb-if is created

-Dynamic Abis feature actived (ZWOA:2,644,A;)

-EDGE capable BTS

-Working EDAP configuration




Test Execution 1) Lock the BTS and change GENA=N, EGENA=N (ZEQS) (ZEQV)

2) Lock the TRX (ZERS)

3) Delete TRX (ZERD)

4) Delete DAP pool (ZESG)

5) Create the TRX (ZERC)

6) Unlock the TRX (ZERS)

7) Change GENA=Y and unlock the BTS (ZEQV) (ZEQS)






Expected Results - DAP deleted successfully

- Download succeeds



Test cases


1.9.4 EGPRS: FTP upload



Test purpose To verify that the EDGE GPRS upload succeeds


-Gb-if is created





-Check that there is no abnormal alarms and log writings in MCMU and BCSU


2) Start uploading packages (approximately 3-5MB) to FTP address (Use FTP command from DOS prompt)

3) Wait until file is uploaded


5) Check that there is no abnormal alarm and log writings in MCMU and BCSU

Expected Results Uploading succeeds


1.9.5 EGPRS: DAP modification, Controlling BCSU



Issue 1.0-0


Test Purpose To verify that DAP pool controlled by BCSU can be modified




-EDGE capable BTS


-Gb-interface created



Test Execution The actual MML commands depends on the used configuration, MML commands listed as an example.

1) Output current configuration by command:

ZESI:ID=<index>:;

ZRCI:SEA=3:NCGR=<dap pool circuit group name>:PRINT=5:;

ZERO:BTS=<index>:;

2) Modify the controlling BCSU by command:

ZESM:ID=<index>,PCU=<index>:;


ZESI:ID=<index>:;


ZERO:BTS=<index>:;




Test cases




Expected Results - Controlling BCSU can be changed

- Modified DAP carries traffic

- Download succeeds




NOTE: TRX signalling link, TCHs and DAP must locate on the same ET-PCM, if those aren’t DAP cannot be created.


NED – Descriptions – Feature descriptions – Data – Dynamic Abis

NED - Test and Activate – Data – BSS10083: EGPRS

1.9.6 EGPRS: DAP modification, Controlling PCU



Test Purpose To verify that the controlling PCU of the DAP pool can be changed





-EDGE capable BTS



Issue 1.0-0





ZESI:ID=<index>:;


ZERO:BTS=<index>:;

2) Modify the controlling PCU by command:

ZESM:ID=<index>,PCU=<index>:;


ZESI:ID=<index>:;


ZERO:BTS=<index>:;






Expected Results - Controlling PCU can be changed

- Modified DAP carries traffic

- Download succeeds




Test cases


NOTE: TRX signaling link, TCHs and DAP must locate on the same ET-PCM, if those aren’t DAP cannot be created.

Related documents NED - Descriptions – Feature descriptions – Data – Dynamic Abis


1.9.7 EGPRS: DAP modification, First and last timeslot



Test Purpose To verify that the DAP pool can be modified





-EDGE capable BTS






ZESI:ID=<index>:;


ZERO:BTS=<index>:;

Issue 1.0-0


2) Modify first/last timeslot of the DAP by command:

ZESM:ID=<index>,NLT=<last_timeslot>,BCSU=<index>,PCU=<index>:;

or

ZESM:ID=<index>, NFT =<first_timeslot>,BCSU=<index>,PCU=<index>:;


ZESI:ID=<index>:;


ZERO:BTS=<index>:;






Expected Results -DAP pool size can be modified.

-New or modified DAP carries traffic

- Download succeeds




NOTE: TRX signalling link, TCHs and DAP must locate on the same ET-PCM, if those aren’t DAP cannot be created.

Related documents NED - Descriptions – Feature descriptions – Data – Dynamic Abis


Test cases


1.10 Q3-interface functionality

1.10.1 NetAct (Q3) functionality: Alarms

Test case ID: RT000NM00001


Test purpose To verify the NetAct functionality of alarms

Pre-requirements Check that the BSC and Net Act connection is working

Test Execution Check BSC alarms from Net Act's Alarm monitoring and verify the correctness of the alarms.

Expected Results Same alarms are seen in Alarm monitoring of Net Act as in ZAHO print of BSC.


1.10.2 NetAct (Q3) functionality: Measurement



Test purpose To verify the NetAct functionality of measurements


Test Execution

Issue 1.0-0


Activate few measurements of BSC and start measurements.

Check that measurement data is transferring to the Net Act.

After transfer has finished check that measurement logs are transferred successfully to NetAct.

Logs from measurements which have arrived in certain day are saved in mecman_yyyymmdd.log in NetAct directory: cd /var/opt/nokiaoss/uma/umagco/cs_pm/pm/log The log can be checked with following commands: tail -n mecman_20070904.log or grep xxxxx mecman_20070907.log, where xxxxx is the C-number of the BSC.

Expected Results Measurement data is coming correctly to the Net Act


1.10.3 NetAct (Q3) functionality: Remote MMI



Test purpose To verify the NetAct functionality of remote MMI connection


Test Execution Start remote MMI connection from NetAct to the BSC.

Expected Results The NetAct functionality of remote MMI connection is working correctly


Test cases


1.10.4 NetAct (Q3) functionality: Fast 2G upload



Test purpose To verify the NetAct functionality of fast 2G upload


Radio network exists

Check that BSC “NetcAct face” is correct. Check this with ZDFD:OMU:88E; command. During testing period the release id goes one behind (e.g. in S13 release the face is S12 NetAct OSS4.2).

Test Execution If upload is done already earlier make some changes to radio network configuration (eg. parameter change).

1) Actions in NetAct:

-Start CM Op. Manager, choose Upload -> New upload

-Select wanted BSC from the list

-Select level of Feedback -> Parameter in this case

-Select Start

2) Check that radio network configuration is transferring to the NetAct.

Expected Results The NetAct functionality of fast 2G upload is working correctly.

Radio network configuration transferred correctly to NetAct.


1.11 LAN Device Integration (LDI)

Issue 1.0-0


1.11.1 LDI: Creation of internal LAN

Test case ID: RT000IP00001


Test purpose Purpose of this test case is to verify the creation of internal LAN


-Needed LAN switches (ESB plug-in units)

Test Execution -Create the hardware configuration of LAN switches (ESB) by commands ZWTC, ZWTU and ZWTP.

-creation of LANU cartridges and units

-creation of SWU units and plug-in units

-Create internal LAN (subnet) by command ZWYB.

-Define the controlling unit for internal LANs by command ZWYC.

-Change SWU and CNW states to WO (ZUSC).

-Update switch password to BSC (ZW6M).

-Allow automatic configuration transfer from switch to BSC by command ZYFM.

-Preconfigure LAN switches if needed (see instructions in Integrated LAN Administration document).

-Activate LAN topology (ZW6E).

-Check LAN supervision information (ZYFF:INQ).

-When all the LAN switches are active, make the required configuration.

Expected Results - Internal LAN creation succeeds



Related documents

Test cases


NED – Product Documentation – Plan - Network Element – Integrated LAN Administration

NED – Product Documentation – Plan - Site – BSC Site IP Connectivity Guidlines

1.11.2 LDI: Copying LAN switch configuration file



Test purpose Purpose of this test case is to verify the copying of LAN switch configuration file


-Internal LAN configured

Test Execution -Check that source configuration file contains right information (ZW6R).

-Copy source LAN switch’s configuration file (ZW6S).

-Upload the configuration to the destination switch (ZYFM).

Expected Results - Copying and loading of LAN switch configuration file succeeds



Related documents NED – Product Documentation – Plan - Network Element – Integrated LAN Administration


1.11.3 LDI: LAN supervision


Issue 1.0-0



Test purpose Purpose of this test case is to verify the supervision of LAN devices



-LAN switches in activated state

Test Execution -Check the supervision status of LAN switches. (ZYFF:INQ)

-Enable supervision of the units. (ZYFF:ENA)

-Set the supervision cycle of the units (ZYFF:CYC) if needed.

-Check the data of supervision (ZYFF:INQ).

-Disconnect one switch’s cable.

-Check if there is any faulty links (ZYFE:IFL;)

-Restore cable connection and check supervision data again.

-Supervision logs can be checked by command ZYFL.

Tip! You can use the MML command DDE to check whether the LAN administration data collection process is finished or not. Enter the command ZDDE::"ZGDC"; to access the OMU log file. If the process is finished, the log file will contain the following line: ZYDMAS:ILDATA database has been filled .This means that supervision data is now available.

Expected Results - LAN switch can be supervised and faulty links can be noticed.

- No abnormal alarms or log writings



Test cases


1.11.4 LDI: Diagnostic of LAN switch



Test purpose Purpose of this test case is to verify the diagnosis of LAN device



-LAN switches activated and in WO or TE state

Test Execution -Start diagnostics of internal LAN switch (ZUDU).

-Check and wait until the diagnostic is finished (ZUDQ).

-Display the results of diagnostics (ZUDH).

Expected Results - LAN switch diagnostic succeeds.

- No abnormal alarms or log writings



1.11.5 LDI: LAN statistics



Test purpose Purpose of this test case is to verify the statistics of LAN device

Pre-requirements

Issue 1.0-0


-Working BSC


-LAN switches activated and in WO state

-No topology changes should be made in the LAN during the measurement period

Test Execution -Create measurement(s) for internal LAN switch (ZT2C).

-Check the measurement parameters if needed (ZT2I) -Start the created measurement(s) (ZT2S).

-Stop the measurement after measurement has been started if needed (ZT2E).

Expected Results - LAN switch measurement succeeds and measurement data created successfully.

- No abnormal alarms or log writings.

Related documents Notice!

There are three different types of measurements:

- Traffic measurements

- Error measurements

- Availability measurements

NED – Product Documentation – Plan - Network Element – Integrated LAN Administration


1.12 State transitions and restarts

Test cases


1.12.1 BSC system restart

Test case ID: RT000SD00001


Test purpose To verify that BSC works correctly in case of a system restart, to see that the system and radio network recovers correctly, calls succeed and that the alarm situation in BSC corresponds to that of NetAct.

Pre-requirements -Before restarting the system is highly recommend to check actions before a system restart from the Technical note No. 640

-Check the status of the radio network with BSC MML


Test Execution 1) Make a call from subscriber A to subscriber B

2) Make a (E)GPRS call

3) Execute the system restart with command ZUSS:SYM;

4) Make a new call from subscriber A to subscriber B after the system restart

6) Make a new (E)GPRS call

7) Clear the call from the subscriber A's MS.

8) Check for any new alarms in BSC and BTS alarm history

9) Check computer logs from all units for unexpected log writings

10) Check that the same alarms have been directed to the line printer or/and NetAct workstation

Expected results -All signaling links, TRXs, BTSs and BCFs are in the operational state WORKING

-The current alarm situation is correct

-Call succeeds after system restart

Test cases

Issue 1.0-0


-No unexpected log writings in computer logs

-NetAct connection (Q3) is working correctly

Related documents Technical note No. 640

1.12.2 Power break in the system



Test purpose To verify that the BSC works correctly in case of a power break, to see that the system and radio network recovers correctly, calls succeed and alarm situation in BSC corresponds to that of NetAct.

Pre-requisites -Check the status of the radio network with BSC MML

-Check that the system is stable


Test execution 1) Check that BSC has got external synchronization or loop used synchronization input(s)

2) Disconnect power at first from the BCEE/BSCC system, then from the BCBE/BSCD system

3) Reconnect power at first to the BCBE/BSCC system, then to BCEE/BSCD system

4) Check that the system has started and that it begins to load from the disks

5) Monitor that every computer unit starts in the state it was in prior to the power break

6) Doubled preprocessor units (i.e. CLSs) will independently determine which unit is passive and which is active after the power break

7) Output the states of all the units and check that they are in the correct working states

Test cases


8) Output alarm history and verify that there is not unexpected alarms

9) Verify computer logs from unexpected log writings

-Computer starts are supervised by the service terminal connected to the lower console connector of the central processing unit.

-Follow the phase print-outs from the BSC Commissioning Manual.

Expected results -All units are in correct working state

-Call succeeds after system restart and speech quality is good

Related documents BSC Commissioning Manual

1.12.3 OMU State Change and Diagnostics



Test purpose To verify state changes and diagnostics of OMU-unit


Test execution 1) Check the working state of OMU (WO-EX)

2) Change the state of OMU to TE, SE and back to TE

3) Run the total diagnostics for OMU

4) Change the state of OMU to WO

Expected results State changes are successful and diagnostic ends up to 'UNIT OK' printout

Test cases

Issue 1.0-0



1.12.4 BCSU State Change and Diagnostics



Test purpose To verify that state changes and diagnostics of BCSU-unit are OK

Pre-requisites None

Test execution 1) Check the working states of all BCSUs

2) Change the state of WO or SP BCSU to TE, SE and back to TE

3) Run the total diagnostics for BCSU

4) Change the state of BCSU to SP or WO



1.12.5 MCMU State Change and Diagnostics



Test cases


Test purpose To verify state changes and diagnostics of MCMU-unit


Test execution 1) Check the working states of MCMUs

2) Change the state of WO or SP MCMU to TE, SE and back to TE

3) Run the total diagnostics for MCMU

4) Change the state back to SP and make a switchover



1.12.6 MB State Change and Diagnostics



Test purpose To verify state changes and diagnostics of MB/EMB

Pre-requisites None

Test execution 1) Check the status of Message Buses

2.) Change the state SP (E)MB to TE, SE and back to TE

Test cases

Issue 1.0-0


3.) Run the diagnostics

4.) Change the (E)MB state back to SP

5) Make the switchover and repeat the test for the other (E)MB



1.12.7 OMU Partial Diagnostics



Test purpose To verify OMU partial diagnostics

Pre-requisites None

Test execution 1) Check the working state of OMU (WO-EX)

2) Change the state of OMU to TE, SE and back to TE

3) Run the all-partial diagnostics for OMU

-Use command UDU:OMU: to see all available partial diagnostics

-Run partial diagnostics one by one

4) Change the state of OMU to WO


Test cases



1.12.8 MCMU Partial Diagnostics



Test purpose To verify the MCMU partial diagnostics

Pre-requisites None

Test execution 1) Check the working states of MCMUs

2) Change the state of SP MCMU to TE, SE and back to TE

3) Run the all-partial diagnostics for MCMU

-Use command UDU:MCMU,0: to see all available partial diagnostics


4) Change the state back to SP and make a switchover



1.12.9 BCSU Partial Diagnostics



Test cases

Issue 1.0-0


Test purpose To check BCSU partial diagnostics

Pre-requisites None

Test execution 1) Check the working states of all BCSUs

2) Change the state of SP BCSU to TE, SE and back to TE

3) Run the all partial diagnostics for BCSU

-Use command UDU:BCSU,0: to see all available partial diagnostics


4) Change the state of BCSU to SP or WO



1.12.10 MCMU power break while data transfer on



Test purpose To verify (E) GPRS data transfer after MCMU (WO-EX) power break

Pre-requisites -Check the BCSUs handling the GB interface with MML command: ZFXO:BCSU=<id>:BTS;

-Check current alarms in the system: ZAHO; and ZEOL;

Test cases


-Clear all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGC

Test execution 1) Start (E)GPRS data transfer in BTS under the affected BCSU

2) Switch the power off from PSC6 card in MCMU ( WO-EX)

3) Start (E)GPRS data transfer in BTS after State of MCMUs are stabilized

4) Check for any new alarms in system ZAHO; and ZEOL;

5) Check computer logs for unexpected log writings with service terminal command ZGSC

Expected results Data transfer is successful after power break. No unusual log writings in BCSU or MCMUs


1.12.11 BCSU power break while (E)GPRS data transfer is on



Test purpose To verify (E) GPRS data transfer after BCSU power break when the affected BCSU is handling GB interface

Pre-requisites -Check the BCSUs handling the GB interface with MML command:

ZFXO:BCSU=<id>:BTS;

-Check current alarms in the system: ZAHO; and ZEOL;


Test cases

Issue 1.0-0


Test execution 1) Start (E)GPRS data transfer in BTS under the affected BCSU

2) Switch the power off from PSC6 card in BCSU

3) Start (E)GPRS data transfer in BTS under the new BCSU

4) Check for any new alarms in system ZAHO and ZEOL;

5) Check all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGSC

Expected results Data transfer is successful after power break. No unusual log writings in BCSUs


1.12.12 Switchover: BCSU handle BTS/TRX



Test purpose To verify the switchover of BCSU

Pre-requirements -Check current alarms in the system: ZAHO; and ZEOL;


-Check the controlling BCSU of BTS/TRX

ZEEI:BTS=XX;

Test Execution 1) Make a CS call

2) Make a switchover to working BCSU by command

ZUSC:BCSU,<wo_ex>:SP,;

Test cases


3) Check the CS call status

Execute steps from 4 to 7 if GPRS/EDGE feature is installed to the BSC

4) Make a PS call



6) Check the PS call status

7) Make a new PS call



Expected Results The switchover of BCSU is successful and CS call wasn't dropped in a switchover.

PS call is successful after switchover.


1.12.13 Switchover: BCSU handle A-interface




Pre-requirements Check the BCSUs handling the A interface with MML command: ZNLI;

Check current alarms in the system: ZAHO; and ZEOL;

Clear all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGC

Test cases

Issue 1.0-0






4) Create new CS call and verify that call establishment is OK



Expected Results The switchover of BCSU is successful and CS call wasn't dropped in a switchover.

If only one A-interface in use the call will drop. If only one A-interface in use, check that after the BCSU switchover is complete, the A-interface is up and running and recovery succeeded. Calls are successful after switchover.


1.12.14 Switchover: BCSU handle Gb-interface




Pre-requirements Check the BCSUs handling the GB interface with MML command: ZFXO:BCSU=<ind>:BTS;

Check current alarms in the system: ZAHO; and ZEOL;


Test cases


Test Execution 1) Make a PS call




4) Make new PS call



Expected Results The switchover of BCSU is successful and PS call is working correctly after switchover.


1.12.15 Switchover: MCMU



Test purpose To verify the switchover of MCMU

Pre-requirements Check current alarms in the system: ZAHO; and ZEOL;



2) Make a switchover to working MCMU by command

Test cases

Issue 1.0-0


ZUSC:MCMU,<wo_ex>:SP,;


Execute steps from 4 to 6 if GPRS/EDGE feature is installed to the BSC

4) Make a PS call

5) Make a switchover to working MCMU by command

ZUSC:MCMU,<wo_ex>:SP,;


7) Make new PS call



Expected Results The switchover of MCMU is successful and CS call wasn't dropped in a switchover.

PS call is working correctly after switchover.


1.12.16 Switchover: SGSN PAPU unit



Test purpose To verify the handling PAPU unit switchover of Gb-link

Pre-requirements Check current alarms in the SGSN by command: ZAHO;

Check which PAPU unit is handling the used Gb-link by command: ZFUI;

Test cases


Check the state of used Gb-link by command: ZFWO:PAPU,<unit index>;

Test Execution 1) Make a PS call

2) Make a switchover to the handling PAPU unit by command

ZUSC:PAPU,<unit index>:SP,;


4) Check for any new alarms in system ZAHO:PAPU,<unit index>;

5) Make a new PS call

Expected Results The switchover of PAPU unit is successful, PS call is working correctly after switchover and any alarms shouldn't found


1.12.17 Switchover: MSC BSU unit



Test purpose To verify the handling BSU unit switchover of A-interface

Pre-requirements Check that there are at least two A-interface links created and those links are handled by different BSU-units

Check current alarms in the MSC by command: ZAHO;

Check which BSU unit is handling the used A-interface link by command: ZNLI;

Test cases

Issue 1.0-0



2) Make a switchover to the handling BSU unit by command

ZUSC:BSU,<wo_ex>:SP,;


4) Check for any new alarms in system ZAHO;

5) Make a new CS call

Expected Results The switchover of BSU unit is successful, CS call is working correctly after switchover and any alarms shouldn't found


1.12.18 TCSM restart



Test purpose To verify the TCSM restart

Pre-requirements Check current alarms in the system by command: ZAHO:TCSM;

Check the state of used TCSM unit by command: ZUSI:TCSM;

Test Execution 1) Make a restart to the TCSM unit by command:

ZUSU:TCSM,<unit index>;

2) Check the state of used TCSM unit by command: ZUSI:TCSM; and wait until the TCSM is in WO-EX state

3) Check for any new alarms in system: ZAHO:TCSM,<unit index>;

Test cases


4) Make a CS call

Expected Results The restart of TCSM unit is successful, CS call is working correctly after TSCM restart and any alarms shouldn't found


1.12.19 Call scenarios after interface modifications (set1)



Test Purpose Purpose of this test case is to verify CS/PS traffic handling capability after interface/configuration modifications

Pre-requirements Interface modifications done according to RT Plan

Test Execution Name of the case: ID number: Location updating RT000CC00001

MS to MS call RT000CC00002

GPRS/EDGE: Attach & PDP Context RT000GP00001

GPRS/EDGE: FTP Download RT000GP00002

GPRS/EDGE: Several mobiles at the same cell RT000GP00004

GPRS/EDGE: Data transfer after GENA Y/N RT000GP00005

Expected Results All the defined Call cases executed successfully after interface modifications

Test cases

Issue 1.0-0


Related documents Corresponding RT PLAN




Test Purpose Purpose of this test case is to verify PS traffic handling capability after interface/configuration modifications


Test Execution Name of the case: ID number: Version: GPRS/EDGE: Attach & PDP Context RT000GP00001 1.1.0

GPRS/EDGE: FTP Download RT000GP00002 1.1.0

GPRS/EDGE: Several mobiles at the same cell RT000GP00004 1.1.0



Test cases





Test Purpose Purpose of this test case is to verify CS traffic handling capability after interface/configuration modifications


Test Execution Name of the case: ID number: Version: Location updating RT000CC00001 2.1.0

MS to MS call RT000CC00002 3.1.0



1.12.22 STMU: Transmission protection



Test Purpose Purpose of this test case is to verify transmission protection in STMU which has HW protection in use.

Test cases

Issue 1.0-0


Pre-requirements STMU HW protection has been implemented according to BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection procedure

TCSM or RNW is created to STMU ET(s)

STMU is in WO-EX state

Test Execution 1) Make a CS call through SDH connection

2) Disconnect the optical cable (fibre) from the STMU unit that selector points to (active STMU). Selector positions can be checked with ZYWI command.

3) End call and reconnect the cable back to ETS2.

4) Make a new call through SDH connection.

5) Check the alarms and computer unit logs.

Expected Results CS call is successful. During cable disconnection CS call stays on, HW protection switch is done successfully and alarm 0101 SDH PROTECTION SWITCHING EXECUTED is set. After the cable disconnection, the new CS call is also successful.

No irrelevant logs or alarms occur.


1.12.23 STMU unit restart



Test Purpose

Test cases


Purpose of this test case is to verify that STMU and its child units (SETs, ETs) will recover correctly from SYSTEM/OMU/MCMU/BCSU/STMU unit restarts. Also it is verified that object states are set correctly during restarts.

Pre-requirements Working BSC

STMU with HW redundancy unit created according to BSC3i/TCSM3i upgrade for SDH(Sonet equipment protection procedure

Some TCSM(s) or radionetwork created to STMU ET(s).

STMU(s) are in WO-EX state.

Test Execution 1) Restart the following units one at a time and check STMU/SET/ET

states after each restart:

- active STMU

- spare STMU

- both HW pair STMU(s)

- equipment protecting STMU

- BCSU unit which is controlling the active STMU

2) Check alarms and computer unit logs

Expected Results STMU and it’s child units recover correctly after each restart.



1.12.24 HW protection verification in case of ETIP/STMU


Test cases

Issue 1.0-0



Test Purpose Purpose of this test case is to verify that equipment protection works correctly in case of ETIP or STMU unit pairs.

Pre-requirements STMU or ETIP HW protection has been implemented

TCSM (A-interface) or RNW (Abis interface) is created to STMU/ETIP ET(s)

STMU/ETIP is in WO-EX state

Test Execution 1) Make a CS call through STMU or ETIP connection

2) Disconnect the optical cable (fibre) from the STMU/ETIP unit that selector points to (active STMU/ETIP). Selector positions can be checked with ZYWI command.

3) End call and reconnect the cable back to ETS2/ETIP.

4) Make a new call through STMU/ETIP.

5) Check the alarms and computer unit logs.

Expected Results CS call is successful. During cable disconnection CS call stays on, HW protection switch is done successfully and e.g in case of STMU alarm 0101 SDH PROTECTION SWITCHING EXECUTED is set. After the cable disconnection, the new CS call is also successful.


Related documents Corresponding BSC (or BSC/TCSM) upgrade for SDH/Sonet equipment protection procedure or BSC (or BSC/TCSM) ETIP1-A implementation for IP/PWE.