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
© Nokia Siemens Networks 3 (143)
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
4 (143) © Nokia Siemens Networks Issue 1.0-0
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
© Nokia Siemens Networks 5 (143)
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
6 (143) © Nokia Siemens Networks Issue 1.0-0
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
© Nokia Siemens Networks 7 (143)
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
8 (143) © Nokia Siemens Networks Issue 1.0-0
1 Purpose This document includes all the BSC release test cases.
Test cases
Issue 1.0-0
© Nokia Siemens Networks 9 (143)
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
10 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000AB00002
Test case version: 1.2.0
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
-GPRS feature (licence 673) activated and used in one cell at least (ZW7I to check the licence)
- 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
© Nokia Siemens Networks 11 (143)
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)
7) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results - BTS deletion done successfully
- No alarms occurred
- No log writings to Computer logs
Related documents None
1.1.3 Abis: PCM Break
Test case ID: RT000AB00003
Test case version: 1.4.0
Test Purpose Purpose of this test case is to verify that BSC recovers from Abis PCM break
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 cases
12 (143) © Nokia Siemens Networks Issue 1.0-0
Test Execution 1) Verify CS/PS traffic handling capability before PCM break
2) Activate PDP context in three or more mobiles
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
10) Check that there are no abnormal alarms and log writings in MCMU and BCSU
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 case ID: RT000AB00004
Test case version: 1.5.0
Test Purpose Purpose of this test case is to verify the modification of Base Transceiver Station
Pre-requirements
Test cases
Issue 1.0-0
© Nokia Siemens Networks 13 (143)
-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
-Licence for Packet Abis is activated (1535)
-ETPE functional unit created with plug-in unit successfully (unit in WO-EX state)
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
-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)
13) Activate PDP context in three or more mobiles
14) Start downloading data from FTP address (Use FTP command from DOS prompt)
15) Wait until file is downloaded
16) Repeat downloading several times
17) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results - Modified BTS is able to handle CS/PS traffic
Test cases
14 (143) © Nokia Siemens Networks Issue 1.0-0
- PDP context activation succeeds
- Download succeeds
- Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)
- No alarms occurred
- No log writings to Computer logs
Related documents NED – Integrate – BSS Integration – Creating the Abis Interface
1.1.5 Abis: Creation of BTS using Packet Abis over TDM (ETPT)
Test case ID: RT000AB00005
Test case version: 1.0.0
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)
-GPRS connection parameters of PCs are correctly configured
Test cases
Issue 1.0-0
© Nokia Siemens Networks 15 (143)
-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)
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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?)
13) Attach software package to BCF (ZEWA)
Test cases
16 (143) © Nokia Siemens Networks Issue 1.0-0
14) Activate GPRS (ZEQV)
15) Unlock objects: TRX’s, BTS’s and BCF (ZERS, ZEQS, ZEFS)
16) Make MS to MS call
17) Activate PDP context in three or more mobiles
18) Start downloading data from FTP address (Use FTP command from DOS prompt)
19) Wait until file is downloaded
20) 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
NED – BSC Site IP Connectivity Guidelines
1.1.6 Abis: Creation of BTS using Packet Abis over IP (ETPE)
Test case ID: RT000AB00005
Test case version: 1.0.0
Test Purpose Purpose of this test case is to verify the creation of Base Transceiver Station using Packet Abis over Ethernet.
Pre-requirements -Working BSC
-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
© Nokia Siemens Networks 17 (143)
• 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)
-GPRS connection parameters of PCs are correctly configured
-Licence for PA over Ethernet (1533), AoverIP (1753) needed
-ETPE functional unit with plug-in unit is created successfully (unit in WO-EX state)
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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
18 (143) © Nokia Siemens Networks Issue 1.0-0
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).
11) Attach software package to BCF (ZEWA)
12) Activate GPRS (ZEQV)
13) Unlock objects: TRX’s, BTS’s and BCF (ZERS, ZEQS, ZEFS)
14) Make MS to MS call
15) Activate PDP context in three or more mobiles
16) Start downloading data from FTP address (Use FTP command from DOS prompt)
17) Wait until file is downloaded
18) 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
NED – BSC Site IP Connectivity Guidelines
1.2 A-interface
1.2.1 A if: Creation of A interface with TCSM2
Test case ID: RT000AI00001
Test case version: 1.0.0
Test Purpose
Issue 1.0-0
© Nokia Siemens Networks 19 (143)
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
20 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000AI00002
Test case version: 1.3.0
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
© Nokia Siemens Networks 21 (143)
-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)
Expected Results Created a-interface is able to handle CS traffic
No alarms occurred
No log writings to Computer logs
Related documents Corresponding BSC3i upgrade for Combined BSC3i/TCSM3i Procedure.
1.2.3 A if: Creation of A interface with stand-alone TCSM3i
Test case ID: RT000AI00003
Test case version: 1.2.0
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.
2) Call from subscriber A to subscriber B
-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
Test cases
22 (143) © Nokia Siemens Networks Issue 1.0-0
7) Repeat the test several times with different mobiles if possible (write down brand and model of used mobiles)
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.4 A if: Creation of A interface through CombiTCSM3i evolution TCSA
Test case ID: RT000AI00004
Test case version: 1.2.0
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.
2) Call from subscriber A to subscriber B
-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)
Expected Results
Issue 1.0-0
© Nokia Siemens Networks 23 (143)
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.5 A-if: Creation of A interface over IP (ETPC)
Test case ID: RT000AI00005
Test case version: 1.0.0
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).
Pre-requirements -Working BSC
-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
24 (143) © Nokia Siemens Networks Issue 1.0-0
- 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)
2) Call from subscriber A to subscriber B
-Make the call with different types of MS(s) 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)
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 via IP
NED – BSC Site IP Connectivity Guidelines
NED - SIGTRAN Configuration for the A Interface
1.2.6 A-if: Creation of A interface over IP (ETPA)
Test case ID: RT000AI00006
Issue 1.0-0
© Nokia Siemens Networks 25 (143)
Test case version: 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).
Pre-requirements -Working BSC
-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:;
2) Call from subscriber A to subscriber B
-Make the call with different types of MS(s) 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)
Test cases
26 (143) © Nokia Siemens Networks Issue 1.0-0
Expected Results Created A-interface is able to handle CS traffic
No alarms occurred
No log writings to Computer logs
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 case version: 4.4.0
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
© Nokia Siemens Networks 27 (143)
-Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.3.2 Memory consumption per computer unit
Test case ID: RT000TC00003
Test case version: 1.0.0
Test purpose To check memory consumption per computer unit in BSC
Pre-requirements None
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
Related documents None
1.3.3 Checking HW version of BSC and TCSM
Test case ID: RT000TC00004
Test case version: 1.1.0
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
Pre-requirements None
Test cases
28 (143) © Nokia Siemens Networks Issue 1.0-0
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 case version: 4.1.0
Test purpose To verify that all accepted and mandatory Change Deliveries have been installed in the BSC before this upgrade
Pre-requirements None
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
© Nokia Siemens Networks 29 (143)
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 case ID: RT000SW00008
Test case version: 2.1.0
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
30 (143) © Nokia Siemens Networks Issue 1.0-0
OMU 0000 WO-EX TRIA NEWP
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
OMU 0000 WO-EX TRIA NEWP
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
WORKING STATE OF UNITS
UNIT PHYS STATE LOCATION INFO
OMU 0000 WO-EX TRIA NEWP
MCMU-1 0005 WO-EX TRIA NEWP
BCSU-1 0031 WO-EX TRIA NEWP NOSW
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
WORKING STATE OF UNITS
UNIT PHYS STATE LOCATION INFO
Issue 1.0-0
© Nokia Siemens Networks 31 (143)
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
BCSU-5 0035 SE-NH NEWP
BCSU-6 0036 SE-NH NEWP
BCSU-7 0037 SE-NH NEWP
BCSU-8 0038 SE-NH NEWP
6) Return to the situation before the CUTOVER
ZWRO;
7) Wait for the OMU, MCMU and BCSU returning back to TRIAL
WORKING STATE OF UNITS
UNIT PHYS STATE LOCATION INFO
OMU 0000 WO-EX TRIA NEWP
MCMU-1 0005 WO-EX TRIA NEWP
BCSU-1 0031 WO-EX TRIA NEWP NOSW
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
32 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000SW00009
Test case version: 1.0.0
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
© Nokia Siemens Networks 33 (143)
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
Corresponding Safecopy in BSC
1.4.4 SW: Check Preconditions
Test case ID: RT000SW000010
Test case version: 1.0.0
Test purpose Checking preconditions of current configuration of an old software
Pre-requirements None
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
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.5 SW: Firmware change and memory upgrade
Test case ID: RT000SW000011
Test case version: 1.0.0
Test purpose Test the firmware and memory upgrade script
Pre-requirements Needed amount of memory and eproms in hand
Test cases
34 (143) © Nokia Siemens Networks Issue 1.0-0
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
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.6 SW: Copy SW from DAT/MO
Test case ID: RT000SW000012
Test case version: 1.0.0
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
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.7 SW: Copy SW from compressed download
Test case ID: RT000SW000013
Issue 1.0-0
© Nokia Siemens Networks 35 (143)
Test case version: 1.1.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
Test Execution 1) Run the copy SW script according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')
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
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.8 SW: Actual upgrade
Test case ID: RT000SW000015
Test case version: 1.0.0
Test purpose To test the software upgrade of BSC
Pre-requirements None
Test Execution Perform the software upgrade according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')
Expected results
Test cases
36 (143) © Nokia Siemens Networks Issue 1.0-0
-Software upgrade is successful, no new alarms or computer log writings compared to the old release.
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.9 SW: check postconditions
Test case ID: RT000SW000016
Test case version: 1.0.0
Test purpose Checking current configuration of a new software
Pre-requirements None
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
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.10 CD installation during upgrade
Test case ID: RT000SW000018
Test case version: 1.0.0
Test purpose To verify that CD(s) can be installed during (in TRIAL configuration) SW implementation procedure
Issue 1.0-0
© Nokia Siemens Networks 37 (143)
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
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.11 SW Copy via NetAct
Test case ID: RT000SW000019
Test case version: 1.0.0
Test purpose To verify that software can be copied via NetAct according SW Implementation procedure
Pre-requirements Package exists in NetAct server
Test Execution 1) Run the copy SW script according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')
2) Remote NetAct mode for SW copying is selected
Test cases
38 (143) © Nokia Siemens Networks Issue 1.0-0
Expected results Copying via NetAct is successful, no errors during the macro is running
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.12 SW: Copy SW from USB
Test case ID: RT000SW000020
Test case version: 1.0.0
Test purpose To verify that software can be copied from USB according SW Implementation procedure
Pre-requirements Package exists in USB
Test Execution 1) Run the copy SW script according to the document corresponding implementation procedure (e.g. 'BSC Software Implementation Procedure')
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
Related documents Corresponding BSC Software Implementation Procedure (ANSI/ETSI)
1.4.13 Local SW loading to TCSM2
Test case ID: RT000SW000021
Test case version: 1.0.0
Issue 1.0-0
© Nokia Siemens Networks 39 (143)
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
40 (143) © Nokia Siemens Networks Issue 1.0-0
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
© Nokia Siemens Networks 41 (143)
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 case ID: RT000SW000022
Test case version: 1.0.0
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.
Test cases
42 (143) © Nokia Siemens Networks Issue 1.0-0
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
© Nokia Siemens Networks 43 (143)
/* 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
44 (143) © Nokia Siemens Networks Issue 1.0-0
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 case version: 1.0.0
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)>;
Issue 1.0-0
© Nokia Siemens Networks 45 (143)
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 case ID: RT000FE00009
Test case version: 1.0.0
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
46 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000FE000016
Test case version: 1.0.0
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
© Nokia Siemens Networks 47 (143)
1.5.4 BSC3i extension from 1000 to 2000
Test case ID: RT000FE000017
Test case version: 1.1.0
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 case ID: RT000FE000018
Test case version: 1.1.0
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
48 (143) © Nokia Siemens Networks Issue 1.0-0
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 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 case ID: RT000FE000019
Test case version: 1.1.0
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
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 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
© Nokia Siemens Networks 49 (143)
1.5.7 BSC/PCU HW upgrade for PS traffic (GPRS/EDGE)
Test case ID: RT000FE000020
Test case version: 1.1.0
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 case ID: RT000FE000021
Test case version: 1.1.0
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
50 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000FE000022
Test case version: 1.1.0
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
© Nokia Siemens Networks 51 (143)
Corresponding BSC3i/TCSM3i HW implementation for combined installation procedure
1.5.10 TCSM3i cabinet extension for combined BSC3i/TCSM3i procedure
Test case ID: RT000FE000023
Test case version: 1.1.0
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 case ID: RT000FE000024
Test case version: 1.1.0
Test purpose To verify the BSC3i upgrade from 660 to 3000 (Offline implementation) procedure
Test cases
52 (143) © Nokia Siemens Networks Issue 1.0-0
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
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 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 case ID: RT000FE000025
Test case version: 1.1.0
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
© Nokia Siemens Networks 53 (143)
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 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 case ID: RT000FE000026
Test case version: 1.1.0
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
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 660 upgrade from AS7-B to AS7-C for signalling capacity procedure is successful and no new alarms found
Related documents
Test cases
54 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000FE000027
Test case version: 1.1.0
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 case ID: RT000FE000028
Test case version: 1.1.0
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
© Nokia Siemens Networks 55 (143)
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 case ID: RT000FE000029
Test case version: 1.0.0
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
3) Attach zipped implementation log to the TestMan Test Execution Report
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
56 (143) © Nokia Siemens Networks Issue 1.0-0
1.5.17 BSC3i upgrade from 1000 to Flexi BSC (Offline procedure)
Test case ID: RT000FE000030
Test case version: 1.1.0
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)
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 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)
1.5.18 BSC3i upgrade from 2000 to Flexi BSC (Offline procedure)
Test case ID: RT000FE000031
Test case version: 1.1.0
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
© Nokia Siemens Networks 57 (143)
Test execution 1) Perform the feature implementation according to the corresponding document of BSC3i upgrade from 2000 to 3000 (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
3) Attach zipped implementation log to the TestMan Test Execution Report
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 case ID: RT000FE000032
Test case version: 1.0.0
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
58 (143) © Nokia Siemens Networks Issue 1.0-0
Related documents Corresponding BSC ETIP1-A implementation for IP/PWE procedure
1.5.20 BSC upgrade for SDH/Sonet equipment protection
Test case ID: RT000FE000033
Test case version: 1.0.0
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
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 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)
Test case ID: RT000FE000034
Test case version: 1.0.0
Issue 1.0-0
© Nokia Siemens Networks 59 (143)
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
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 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
1.5.22 BSC upgrade from 1000 to Flexi BSC 4200 (Offline procedure)
Test case ID: RT000FE000035
Test case version: 1.0.0
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
60 (143) © Nokia Siemens Networks Issue 1.0-0
1) Perform the feature implementation according to the corresponding document of BSC upgrade from 1000 to Flexi BSC 4200 (Offline 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 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)
1.5.23 BSC upgrade from 2000 to Flexi BSC 4200 (Offline procedure)
Test case ID: RT000FE000036
Test case version: 1.0.0
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)
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 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
© Nokia Siemens Networks 61 (143)
1.5.24 BSC upgrade from Flexi BSC 3000 to Flexi BSC 4200
Test case ID: RT000FE000037
Test case version: 1.0.0
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
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 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 case ID: RT000FE000038
Test case version: 1.0.0
Test purpose To verify the BSC implementation for ETP/ETP-A procedure
Test cases
62 (143) © Nokia Siemens Networks Issue 1.0-0
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
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 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 case ID: RT000FE000039
Test case version: 1.0.0
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
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
Issue 1.0-0
© Nokia Siemens Networks 63 (143)
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 case ID: RT000FE000040
Test case version: 1.0.0
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
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 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 case ID: RT000FE000041
Test case version: 1.0.0
Test cases
64 (143) © Nokia Siemens Networks Issue 1.0-0
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
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 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 case ID: RT000FE000042
Test case version: 1.0.0
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
© Nokia Siemens Networks 65 (143)
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 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 case version: 2.1.0
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
66 (143) © Nokia Siemens Networks Issue 1.0-0
None
1.6.2 MS to MS call
Test case ID: RT000CC00002
Test case version: 3.2.0
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
-Check current alarms in the system
Test execution 1) Call from subscriber A to subscriber B
-Make the call with different types of MSs
2) Answer the call at the B’s MS
3) Verify the speech quality
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 (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
© Nokia Siemens Networks 67 (143)
1.6.3 Emergency call
Test case ID: RT000CC00005
Test case version: 2.2.0
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
5) Repeat the test several times with different mobiles (write down brand and model of used mobiles)
6) Repeat steps 2-5 with the SM without SIM card
Expected results Emergency call is established successfully
Related documents None
1.6.4 Data call
Test case ID: RT000CC00006
Test case version: 3.2.0
Test purpose To verify the basic Circuit Switched data call
Pre-requirements PC and MS or data terminal
Test cases
68 (143) © Nokia Siemens Networks Issue 1.0-0
Test execution 1) Make a basic data call
2) Repeat the test several times with different mobiles (write down brand and model of used mobiles)
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 case ID: RT000CC00007
Test case version: 1.2.0
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
3) Repeat the test several times with different mobiles (write down brand and model of used mobiles)
Expected results The message is sent from MS 1 and received successfully by MS 2
Related documents None
Issue 1.0-0
© Nokia Siemens Networks 69 (143)
1.6.6 Data Call HSCSD
Test case ID: RT000CC00008
Test case version: 3.2.0
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 case ID: RT000CC00009
Test cases
70 (143) © Nokia Siemens Networks Issue 1.0-0
Test case version: 2.1.0
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
Related documents None
Issue 1.0-0
© Nokia Siemens Networks 71 (143)
1.6.8 MS to MS call using TTY devices
Test case ID: RT000CC00010
Test case version: 1.2.0
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
-Check current alarms in the system
Test execution 1) Call from subscriber A to subscriber B
2) Answer the call at the B’s MS
3) Check that communication between TTY equipment works correctly to both directions
4) Clear the call from the subscriber A's MS
5) Check for new alarms in the system and computer logs
6) Repeat the test several times with different mobiles (write down brand and model of used mobiles)
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
Related documents None
1.6.9 Dynamic Frequency Channel Allocation (DFCA)
Test case ID: RT000DF00001
Test case version: 1.0.0
Test cases
72 (143) © Nokia Siemens Networks Issue 1.0-0
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
© Nokia Siemens Networks 73 (143)
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
74 (143) © Nokia Siemens Networks Issue 1.0-0
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.
Related documents None
1.7 Handovers
1.7.1 Inter Cell Handover
Test case ID: RT000HO00001
Test case version: 3.2.0
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 current alarms in the system
-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
3) Answer the call at the B’s MS
4) Verify speech quality
5) Check for new alarms in the system
Issue 1.0-0
© Nokia Siemens Networks 75 (143)
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
Related documents None
1.7.2 Inter System Handover (ISHO)
Test case ID: RT000HO000010
Test case version: 1.3.0
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
76 (143) © Nokia Siemens Networks Issue 1.0-0
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
Related documents None
Issue 1.0-0
© Nokia Siemens Networks 77 (143)
1.7.3 Inter BSC Handover S14 SW release – S15 SW release
Test case ID: RT000HO00008
Test case version: 2.2.0
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)
-Check the status of the signalling network with BSC MML
-Check current alarms in the system
-Check that there are free TCHs on the BTS
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
3) Answer the call at the B’s MS
4) Verify speech quality
5) Check for new alarms in the system
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
Related documents None
Test cases
78 (143) © Nokia Siemens Networks Issue 1.0-0
1.7.4 Inter BSC Handover
Test case ID: RT000HO00009
Test case version: 2.2.0
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)
-Check the status of the signalling network with BSC MML
-Check current alarms in the system
-Check that there are free TCHs on the BTS
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
3) Answer the call at the B’s MS
4) Verify speech quality
5) Check for new alarms in the system
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
Related documents None
Issue 1.0-0
© Nokia Siemens Networks 79 (143)
1.8 GPRS Call
1.8.1 GPRS: Attach & PDP Context
Test case ID: RT000GP0001
Test case version: 1.2.0
Test purpose To verify the mobile phone attach to cell and PDP context activation
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)
- 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) Mobile is not attached to cell or it has not PDP context activated
2) Activate PDP context
3) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results -PDP context activation succeeds
Related documents None
1.8.2 GPRS: FTP download
Test case ID: RT000GP0002
Test case version: 1.2.0
Test cases
80 (143) © Nokia Siemens Networks Issue 1.0-0
Test purpose 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)
-Check status of PCU/PCU2 licence (ZW7I)
-GPRS connection parameters of PCs are correctly configured
-Throughput monitoring application installed to PCs
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
Test Execution 1) Activate PDP context
2) Start downloading packages from FTP address (Use FTP command from DOS prompt), get
3) Wait until file is downloaded
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
- Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)
Related documents None
1.8.3 GPRS: Several mobiles at the same cell
Test case ID: RT000GP0004
Test case version: 1.2.0
Test purpose
Issue 1.0-0
© Nokia Siemens Networks 81 (143)
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)
- Check status of PCU/PCU2 licence (ZW7I)
- GPRS connection parameters of PCs are correctly configured
- Throughput monitoring application installed to PCs
- Check that there are no abnormal alarms and log writings in MCMU and BCSU
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
4) Check that there is no abnormal alarms and log writings in MCMU and BCSU
Expected Results Download succeeds
Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)
Related documents None
1.8.4 GPRS: Data transfer after GENA Y/N
Test case ID: RT000GP0005
Test case version: 1.2.0
Test purpose To verify that the GPRS download succeeds
Test cases
82 (143) © Nokia Siemens Networks Issue 1.0-0
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)
-Check status of PCU/PCU2 licence (ZW7I)
-GPRS connection parameters of PCs are correctly configured
-Throughput monitoring application installed to PCs
-Check that there is no abnormal alarm or log writings in MCMU and BCSU
Test Execution 1) Activate PDP context
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
6) Activate PDP context
7) Start downloading packages again
8) Check that there is no abnormal alarms and log writings in MCMU and BCSU
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)
Related documents None
1.8.5 GPRS: FTP upload
Test case ID: RT000GP0007
Test case version: 1.1.0
Test purpose To verify that the GPRS upload succeeds
Issue 1.0-0
© Nokia Siemens Networks 83 (143)
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)
-Check status of PCU/PCU2 licence (ZW7I)
-GPRS connection parameters of PCs are correctly configured
-Throughput monitoring application installed to PCs
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
Test Execution 1) Activate PDP context
2) Start uploading packages (approximately 3-5MB) to FTP address (Use FTP command from DOS prompt)
3) Wait until file is uploaded
4) Repeat 2 and 3 several times
5) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results -Uploading succeeds without abnormal alarms or log writings
-Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)
Related documents None
1.8.6 GB: Frame Relay Creation
Test case ID: RT000GP0008
Test case version: 1.1.0
Test Purpose Creating and activating the Gb interface when Frame relay is used
Test cases
84 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000GP0009
Test case version: 1.4.0
Test Purpose Creating and activating the Gb interface when IP is used.
Issue 1.0-0
© Nokia Siemens Networks 85 (143)
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.
Pre-requirements -Working BSC and GPRS capable BTS
-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.
-GPRS connection parameters of PCs are correctly configured
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
-Throughput monitoring application installed to PCs
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
86 (143) © Nokia Siemens Networks Issue 1.0-0
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
© Nokia Siemens Networks 87 (143)
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)
8) Activate PDP context in three or more mobiles
9) Start downloading data from FTP address (Use FTP command from DOS prompt)
10) Wait until file is downloaded
11) Repeat downloading several times
12) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results -Configurations and GPRS activation in a cell(s) are successful
- Download succeeds
- PDP context activation succeeds
- Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)
- No alarms occurred
- No log writings to Computer logs
Related documents NED – Integrate – Gb Interface – Enabling GPRS in BSC
1.8.8 GB: Gb over IP Modification (static/dynamic)
Test case ID: RT000GP00024
Test case version: 1.3.0
Test Purpose The purpose of the test is verify the modification of Gb over IP configuration
Pre-requirements -Working BSC and GPRS capable BTS
Test cases
88 (143) © Nokia Siemens Networks Issue 1.0-0
-Gb over IP Licence activated
-Gb over IP configured
-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
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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
3) Activate PDP context in three or more mobiles
4) Start downloading data from FTP address (Use FTP command from DOS prompt)
5) Wait until file is downloaded
6) Repeat downloading several times
7) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results - Modification done successfully
- BSC is able to handle CS/PS traffic
- FTP download succeeds
- PDP context activation succeeds
- No alarms occurred
- No log writings to Computer logs
Related documents NED – Integrate – Gb Interface – Enabling GPRS in BSC
1.8.9 GB: Gb over IP LAN break
Test case ID: RT000GP00026
Issue 1.0-0
© Nokia Siemens Networks 89 (143)
Test case version: 1.2.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
-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
-Throughput monitoring application installed to PCs
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
8) Check that there are no abnormal alarms and log writings in MCMU and BCSU
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
90 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000GP00008
Test case version: 1.3.0
Test purpose To verify that HSCSD call can be allocated into GPRS territory
Pre-requirements -Working BSC and GPRS capable BTS
-GPRS feature (licence 673) activated and used in one cell at least (ZW7I to check the licence)
-Check status of PCU/PCU2 licence (ZW7I)
-HSCSD feature activated (ZWOI:10,48; and ZWOI:10,47;)
-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) 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
4) Activate PDP context in three or more mobiles
5) Start downloading data from FTP address (Use FTP command from DOS prompt)
6) Repeat downloading several times.
7) Activate PDP context in three or more mobiles
8) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results - HSCSD call successful
Issue 1.0-0
© Nokia Siemens Networks 91 (143)
- GPRS territory upgraded successfully after HSCSD call
- FTP download succeeds
- PDP context activation succeeds
- No alarms occurred
- No log writings to Computer logs
Related documents NED – Descriptions – Feature Descriptions – Data – (E)GPRS in BSC
1.8.11 GPRS/EDGE: NCCR
Test case ID: RT000GP000010
Test case version: 2.1.0
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
-GPRS feature (licence 673) activated and used in one cell at least (ZW7I to check the licence)
-Check status of PCU/PCU2 licence (ZW7I)
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
92 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000GP000011
Test case version: 2.1.0
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
© Nokia Siemens Networks 93 (143)
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 case ID: RT000GP000012
Test case version: 1.2.0
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
94 (143) © Nokia Siemens Networks Issue 1.0-0
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
-No log writings to Computer logs
Related documents NED – Descriptions – Feature Descriptions – Data – (E)GPRS in BSC
1.8.14 GPRS/EDGE: CS SMS during data transfer
Test case ID: RT000GP00013
Test case version: 1.1.0
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
-Check licences of GPRS/EDGE and PCU/PCU2
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
© Nokia Siemens Networks 95 (143)
-No alarms occurred
-No log writings to Computer logs
Related documents NED – Descriptions – Feature Descriptions – Data – (E)GPRS in BSC
1.8.15 GPRS/EDGE: Cell change during data transfer
Test case ID: RT000GP000014
Test case version: 1.1.0
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
-Check licences of GPRS/EDGE and PCU/PCU2
-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
96 (143) © Nokia Siemens Networks Issue 1.0-0
-No log writings to Computer logs
Related documents NED – Descriptions – Feature Descriptions – Data – (E)GPRS in BSC
1.8.16 GPRS/EDGE: Extended UL TBF
Test case ID: RT000GP000019
Test case version: 1.1.0
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
-No log writings to Computer logs
Issue 1.0-0
© Nokia Siemens Networks 97 (143)
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 case ID: RT000GP000020
Test case version: 1.5.0
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;
-GPRS connection parameters of PCs are correctly configured
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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
98 (143) © Nokia Siemens Networks Issue 1.0-0
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
- PDP context activation succeeds
- Check with Throughput monitoring application that data transfer throughput is steady (no remarkable fluctuation)
- No alarms occurred
- No log writings to Computer logs
Related documents NED – Descriptions – Feature Descriptions – Data – (E)GPRS in BSC
1.8.18 Gb: Frame Relay Modification
Test case ID: RT000GP00022
Test case version: 2.3.0
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
-GPRS feature (licence 673) activated and used in one cell at least (ZW7I to check the licence)
-Check status of PCU/PCU2 licence (ZW7I)
Issue 1.0-0
© Nokia Siemens Networks 99 (143)
-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) 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)
7) Activate PDP context in three or more mobiles
8) Start downloading data from FTP address (Use FTP command from DOS prompt)
9) Wait until file is downloaded
10) Repeat downloading several times
11) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results -Frame Relay modified successfully
-BSC is able to handle CS/PS traffic
- Download succeeds
- PDP context activation succeeds
- No alarms occurred
- No log writings to Computer logs
Related documents NED – Integrate – Gb Interface – Enabling GPRS in BSC
1.8.19 Gb: PCM break on Gb interface
Test case ID: RT000GP00023
Test case version: 1.3.0
Test cases
100 (143) © Nokia Siemens Networks Issue 1.0-0
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
-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) 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
4) Call from subscriber A to subscriber B
-Make the call with different types of MSs
5) Answer the call at the B’s MS
6) Check that the call is going through the right BTS with command ZEEI;
7) Clear the call from the subscriber A's MS
8) Check for new alarms in the system
9) Repeat the CS call several times with different mobiles (write down brand and model of used mobiles)
10) Activate PDP context in three or more mobiles
11) Start downloading data from FTP address (Use FTP command from DOS prompt)
12) Wait until file is downloaded
13) Repeat downloading several times
14) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results
Issue 1.0-0
© Nokia Siemens Networks 101 (143)
-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
Related documents NED – Integrate – Gb Interface – Enabling GPRS in BSC
1.8.20 GPRS/EDGE: Territory upgrades and downgrades
Test case ID: RT000GP00027
Test case version: 1.2.0
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,;
-GPRS connection parameters of PCs are correctly configured
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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
CDED=1, CDEF=90, CMAX=100
CDED=1, CDEF=1, CMAX=20
1) Check the GPRS territory size
2) Start HTTP/FTP data transfer
Test cases
102 (143) © Nokia Siemens Networks Issue 1.0-0
3) Check the GPRS/EDGE territory size
4) Activate PDP context in three or more mobiles
5) Check the GPRS/EDGE territory size
6) Wait until file is downloaded
7) Repeat downloading several times
8) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results -GPRS/EDGE territory upgraded after starting data transfer and downgraded successfully after data transfer finished
- PDP context activation succeeds
- No alarms occurred
- No log writings to Computer logs
Related documents NED – Descriptions – Feature Descriptions – Data – (E)GPRS in BSC
1.8.21 GPRS: DTM and EDA&HMC interworking
Test case ID: RT000GP000030
Test case version: 1.1.0
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)
- Nokia BTS SW release in UltraSite CX5
- 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
© Nokia Siemens Networks 103 (143)
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
Related documents None
1.8.22 GPRS: Dual Transfer Mode (DTM)
Test case ID: RT000GP000031
Test case version: 1.1.0
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
- Nokia BTS SW release in UltraSite CX5
Test cases
104 (143) © Nokia Siemens Networks Issue 1.0-0
-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
Related documents None
1.9 EGPRS Call
1.9.1 EGPRS: Data transfer after GENA Y/N
Test case ID: RT000ED0005
Test case version: 1.4.0
Test Purpose To verify that the EDGE download succeeds
Pre-requirements
Issue 1.0-0
© Nokia Siemens Networks 105 (143)
-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)
-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) Activate PDP context
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
6) Activate PDP context
7) Start downloading packages again
8) Check that there is no abnormal alarms and log writings in MCMU and BCSU
Expected Results -Download succeeds after EDGE and GPRS are activated to the BTS
Related Documents None
1.9.2 EGPRS: Create DAP pool
Test case ID: RT000ED0007
Test case version: 1.7.0
Test purpose To verify that the DAP pool can be created.
Pre-requirements -EDGE capable GPRS mobiles
-Gb-if is created
Test cases
106 (143) © Nokia Siemens Networks Issue 1.0-0
-GPRS/EDGE and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)
-Dynamic Abis feature is active in the BSC (ZWOA:2,644,A;)
-EDGE capable BTS
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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)
7) Activate PDP context in three or more mobiles
8) Start downloading data from FTP address (Use FTP command from DOS prompt)
9) Wait until file is downloaded
10) Repeat downloading several times
11) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results - DAP creation successful
- Download succeeds
- PDP context activation succeeds
Related documents None
1.9.3 EGPRS: Delete DAP
Test case ID: RT000ED0008
Test case version: 1.5.0
Test purpose To verify that the DAP pool can delete
Issue 1.0-0
© Nokia Siemens Networks 107 (143)
Pre-requirements -EDGE capable GPRS mobiles
-Gb-if is created
-Dynamic Abis feature actived (ZWOA:2,644,A;)
-EDGE capable BTS
-Working EDAP configuration
-GPRS/EDGE and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
-GPRS connection parameters of PCs are correctly configured
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)
8) Activate PDP context in three or more mobiles
9) Start downloading data from FTP address (Use FTP command from DOS prompt)
10) Wait until file is downloaded
11) Repeat downloading several times
12) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results - DAP deleted successfully
- Download succeeds
- PDP context activation succeeds
Related documents None
Test cases
108 (143) © Nokia Siemens Networks Issue 1.0-0
1.9.4 EGPRS: FTP upload
Test case ID: RT000ED0009
Test case version: 1.1.0
Test purpose To verify that the EDGE GPRS upload succeeds
Pre-requirements -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)
-Dynamic Abis feature actived (ZWOA:2,644,A;)
-GPRS connection parameters of PCs are correctly configured
-Throughput monitoring application installed to PCs
-Check that there is no abnormal alarms and log writings in MCMU and BCSU
Test Execution 1) Activate PDP context
2) Start uploading packages (approximately 3-5MB) to FTP address (Use FTP command from DOS prompt)
3) Wait until file is uploaded
4) Repeat 2 and 3 several times
5) Check that there is no abnormal alarm and log writings in MCMU and BCSU
Expected Results Uploading succeeds
Related documents None
1.9.5 EGPRS: DAP modification, Controlling BCSU
Test case ID: RT000ED00011
Test case version: 1.3.0
Issue 1.0-0
© Nokia Siemens Networks 109 (143)
Test Purpose To verify that DAP pool controlled by BCSU can be modified
Pre-requirements -EDGE capable GPRS mobiles
-GPRS/EDGE and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)
-Dynamic Abis feature actived (ZWOA:2,644,A;)
-EDGE capable BTS
-Working EDAP configuration
-Gb-interface created
-GPRS connection parameters of PCs are correctly configured
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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>:;
3) Output current configuration by command:
ZESI:ID=<index>:;
ZRCI:SEA=3:NCGR=<dap pool circuit group name>:PRINT=5:;
ZERO:BTS=<index>:;
4) Activate PDP context in three or more mobiles
5) Start downloading data from FTP address (Use FTP command from DOS prompt)
6) Wait until file is downloaded
Test cases
110 (143) © Nokia Siemens Networks Issue 1.0-0
7) Repeat downloading several times
8) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results - Controlling BCSU can be changed
- Modified DAP carries traffic
- Download succeeds
- PDP context activation succeeds
- No alarms occurred
- No log writings to Computer logs
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 – (E)GPRS in BSC
NED – Descriptions – Feature descriptions – Data – Dynamic Abis
NED - Test and Activate – Data – BSS10083: EGPRS
1.9.6 EGPRS: DAP modification, Controlling PCU
Test case ID: RT000ED00012
Test case version: 1.3.0
Test Purpose To verify that the controlling PCU of the DAP pool can be changed
Pre-requirements -EDGE capable GPRS mobiles
-Gb-interface created
-GPRS/EDGE and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)
-Dynamic Abis feature actived (ZWOA:2,644,A;)
-EDGE capable BTS
-Working EDAP configuration
-GPRS connection parameters of PCs are correctly configured
Issue 1.0-0
© Nokia Siemens Networks 111 (143)
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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 PCU by command:
ZESM:ID=<index>,PCU=<index>:;
3) Output current configuration by command:
ZESI:ID=<index>:;
ZRCI:SEA=3:NCGR=<dap pool circuit group name>:PRINT=5:;
ZERO:BTS=<index>:;
4) Activate PDP context in three or more mobiles
5) Start downloading data from FTP address (Use FTP command from DOS prompt)
6) Wait until file is downloaded
7) Repeat downloading several times
8) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results - Controlling PCU can be changed
- Modified DAP carries traffic
- Download succeeds
- PDP context activation succeeds
- No alarms occurred
- No log writings to Computer logs
Test cases
112 (143) © Nokia Siemens Networks Issue 1.0-0
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
NED - Test and Activate – Data – BSS10083: EGPRS
1.9.7 EGPRS: DAP modification, First and last timeslot
Test case ID: RT000ED00013
Test case version: 1.3.0
Test Purpose To verify that the DAP pool can be modified
Pre-requirements -EDGE capable GPRS mobiles
-Gb-interface created
-GPRS/EDGE and PCU/PCU2 licences activated and used in one cell at least (ZW7I to check the licence)
-Dynamic Abis feature actived (ZWOA:2,644,A;)
-EDGE capable BTS
-Working EDAP configuration
-GPRS connection parameters of PCs are correctly configured
-Check that there are no abnormal alarms and log writings in MCMU and BCSU
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>:;
Issue 1.0-0
© Nokia Siemens Networks 113 (143)
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>:;
3) Output current configuration by command:
ZESI:ID=<index>:;
ZRCI:SEA=3:NCGR=<dap pool circuit group name>:PRINT=5:;
ZERO:BTS=<index>:;
4) Activate PDP context in three or more mobiles
5) Start downloading data from FTP address (Use FTP command from DOS prompt)
6) Wait until file is downloaded
7) Repeat downloading several times
8) Check that there are no abnormal alarms and log writings in MCMU and BCSU
Expected Results -DAP pool size can be modified.
-New or modified DAP carries traffic
- Download succeeds
- PDP context activation succeeds
- No alarms occurred
- No log writings to Computer logs
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
NED - Test and Activate – Data – BSS10083: EGPRS
Test cases
114 (143) © Nokia Siemens Networks Issue 1.0-0
1.10 Q3-interface functionality
1.10.1 NetAct (Q3) functionality: Alarms
Test case ID: RT000NM00001
Test case version: 1.0.0
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.
Related documents None
1.10.2 NetAct (Q3) functionality: Measurement
Test case ID: RT000NM00002
Test case version: 1.1.0
Test purpose To verify the NetAct functionality of measurements
Pre-requirements Check that the BSC and Net Act connection is working
Test Execution
Issue 1.0-0
© Nokia Siemens Networks 115 (143)
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
Related documents None
1.10.3 NetAct (Q3) functionality: Remote MMI
Test case ID: RT000NM00003
Test case version: 1.0.0
Test purpose To verify the NetAct functionality of remote MMI connection
Pre-requirements Check that the BSC and Net Act connection is working
Test Execution Start remote MMI connection from NetAct to the BSC.
Expected Results The NetAct functionality of remote MMI connection is working correctly
Related documents None
Test cases
116 (143) © Nokia Siemens Networks Issue 1.0-0
1.10.4 NetAct (Q3) functionality: Fast 2G upload
Test case ID: RT000NM00004
Test case version: 1.0.0
Test purpose To verify the NetAct functionality of fast 2G upload
Pre-requirements Check that the BSC and Net Act connection is working
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.
Related documents None
1.11 LAN Device Integration (LDI)
Issue 1.0-0
© Nokia Siemens Networks 117 (143)
1.11.1 LDI: Creation of internal LAN
Test case ID: RT000IP00001
Test case version: 1.0.0
Test purpose Purpose of this test case is to verify the creation of internal LAN
Pre-requirements -Working BSC
-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
- No alarms occurred
- No log writings to Computer logs
Related documents
Test cases
118 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000IP00002
Test case version: 1.0.0
Test purpose Purpose of this test case is to verify the copying of LAN switch configuration file
Pre-requirements -Working BSC
-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
- No alarms occurred
- No log writings to Computer logs
Related documents NED – Product Documentation – Plan - Network Element – Integrated LAN Administration
NED – Product Documentation – Plan - Site – BSC Site IP Connectivity Guidlines
1.11.3 LDI: LAN supervision
Test case ID: RT000IP00003
Issue 1.0-0
© Nokia Siemens Networks 119 (143)
Test case version: 1.0.0
Test purpose Purpose of this test case is to verify the supervision of LAN devices
Pre-requirements -Working BSC
-Internal LAN configured
-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
Related documents NED – Product Documentation – Plan - Network Element – Integrated LAN Administration
NED – Product Documentation – Plan - Site – BSC Site IP Connectivity Guidlines
Test cases
120 (143) © Nokia Siemens Networks Issue 1.0-0
1.11.4 LDI: Diagnostic of LAN switch
Test case ID: RT000IP00004
Test case version: 1.0.0
Test purpose Purpose of this test case is to verify the diagnosis of LAN device
Pre-requirements -Working BSC
-Internal LAN configured
-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
Related documents NED – Product Documentation – Plan - Network Element – Integrated LAN Administration
NED – Product Documentation – Plan - Site – BSC Site IP Connectivity Guidlines
1.11.5 LDI: LAN statistics
Test case ID: RT000IP00005
Test case version: 1.0.0
Test purpose Purpose of this test case is to verify the statistics of LAN device
Pre-requirements
Issue 1.0-0
© Nokia Siemens Networks 121 (143)
-Working BSC
-Internal LAN configured
-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
NED – Product Documentation – Plan - Site – BSC Site IP Connectivity Guidlines
1.12 State transitions and restarts
Test cases
122 (143) © Nokia Siemens Networks Issue 1.0-0
1.12.1 BSC system restart
Test case ID: RT000SD00001
Test case version: 3.3.0
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
-Check current alarms in the system
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
© Nokia Siemens Networks 123 (143)
-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 case ID: RT000SD00002
Test case version: 3.1.0
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
-Check current alarms in the system
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
124 (143) © Nokia Siemens Networks Issue 1.0-0
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 case ID: RT000SD00003
Test case version: 3.1.0
Test purpose To verify state changes and diagnostics of OMU-unit
Pre-requirements 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 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
© Nokia Siemens Networks 125 (143)
Related documents None
1.12.4 BCSU State Change and Diagnostics
Test case ID: RT000SD00004
Test case version: 3.1.0
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
Expected results State changes are successful and diagnostic ends up to 'UNIT OK' printout
Related documents None
1.12.5 MCMU State Change and Diagnostics
Test case ID: RT000SD00005
Test case version: 3.1.0
Test cases
126 (143) © Nokia Siemens Networks Issue 1.0-0
Test purpose To verify state changes and diagnostics of MCMU-unit
Pre-requirements None
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
Expected results State changes are successful and diagnostic ends up to 'UNIT OK' printout
Related documents None
1.12.6 MB State Change and Diagnostics
Test case ID: RT000SD0006
Test case version: 2.2.0
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
© Nokia Siemens Networks 127 (143)
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
Expected results State changes are successful and diagnostic ends up to 'UNIT OK' printout
Related documents None
1.12.7 OMU Partial Diagnostics
Test case ID: RT000SD00007
Test case version: 1.1.0
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
Expected results State changes are successful and diagnostic ends up to 'UNIT OK' printout
Test cases
128 (143) © Nokia Siemens Networks Issue 1.0-0
Related documents None
1.12.8 MCMU Partial Diagnostics
Test case ID: RT000SD00008
Test case version: 1.1.0
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
-Run partial diagnostics one by one
4) Change the state back to SP and make a switchover
Expected results State changes are successful and diagnostic ends up to 'UNIT OK' printout
Related documents None
1.12.9 BCSU Partial Diagnostics
Test case ID: RT000SD00009
Test case version: 1.1.0
Test cases
Issue 1.0-0
© Nokia Siemens Networks 129 (143)
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
-Run partial diagnostics one by one
4) Change the state of BCSU to SP or WO
Expected results State changes are successful and diagnostic ends up to 'UNIT OK' printout
Related documents None
1.12.10 MCMU power break while data transfer on
Test case ID: RT000SD0010
Test case version: 1.3.0
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
130 (143) © Nokia Siemens Networks Issue 1.0-0
-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
Related documents None
1.12.11 BCSU power break while (E)GPRS data transfer is on
Test case ID: RT000SD0012
Test case version: 1.3.0
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;
-Clear all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGC
Test cases
Issue 1.0-0
© Nokia Siemens Networks 131 (143)
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
Related documents None
1.12.12 Switchover: BCSU handle BTS/TRX
Test case ID: RT000SD000013
Test case version: 1.3.0
Test purpose To verify the switchover of BCSU
Pre-requirements -Check current alarms in the system: ZAHO; and ZEOL;
-Clear all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGC
-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
132 (143) © Nokia Siemens Networks Issue 1.0-0
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
5) Make a switchover to working BCSU by command
ZUSC:BCSU,<wo_ex>:SP,;
6) Check the PS call status
7) Make a new PS call
8) Check for any new alarms in system ZAHO and ZEOL;
9) Check all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGSC
Expected Results The switchover of BCSU is successful and CS call wasn't dropped in a switchover.
PS call is successful after switchover.
Related documents None
1.12.13 Switchover: BCSU handle A-interface
Test case ID: RT000SD000014
Test case version: 1.3.0
Test purpose To verify the switchover of BCSU
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
© Nokia Siemens Networks 133 (143)
Test Execution 1) Make a CS call
2) Make a switchover to working BCSU by command
ZUSC:BCSU,<wo_ex>:SP,;
3) Check the CS call status
4) Create new CS call and verify that call establishment is OK
5) Check for any new alarms in system ZAHO and ZEOL;
6) Check all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGSC
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.
Related documents None
1.12.14 Switchover: BCSU handle Gb-interface
Test case ID: RT000SD000015
Test case version: 1.4.0
Test purpose To verify the switchover of BCSU
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;
Clear all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGC
Test cases
134 (143) © Nokia Siemens Networks Issue 1.0-0
Test Execution 1) Make a PS call
2) Make a switchover to working BCSU by command
ZUSC:BCSU,<wo_ex>:SP,;
3) Check the PS call status
4) Make new PS call
5) Check for any new alarms in system ZAHO and ZEOL;
6) Check all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGSC
Expected Results The switchover of BCSU is successful and PS call is working correctly after switchover.
Related documents None
1.12.15 Switchover: MCMU
Test case ID: RT000SD000016
Test case version: 1.3.0
Test purpose To verify the switchover of MCMU
Pre-requirements Check current alarms in the system: ZAHO; and ZEOL;
Clear all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGC
Test Execution 1) Make a CS call
2) Make a switchover to working MCMU by command
Test cases
Issue 1.0-0
© Nokia Siemens Networks 135 (143)
ZUSC:MCMU,<wo_ex>:SP,;
3) Check the CS call status
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,;
6) Check the PS call status
7) Make new PS call
8) Check for any new alarms in system ZAHO and ZEOL;
9) Check all log writings from BCSUs, MCMUs and OMU with service terminal command: ZGSC
Expected Results The switchover of MCMU is successful and CS call wasn't dropped in a switchover.
PS call is working correctly after switchover.
Related documents None
1.12.16 Switchover: SGSN PAPU unit
Test case ID: RT000SD000019
Test case version: 1.1.0
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
136 (143) © Nokia Siemens Networks Issue 1.0-0
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,;
3) Check the PS call status
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
Related documents None
1.12.17 Switchover: MSC BSU unit
Test case ID: RT000SD000020
Test case version: 1.1.0
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
© Nokia Siemens Networks 137 (143)
Test Execution 1) Make a CS call
2) Make a switchover to the handling BSU unit by command
ZUSC:BSU,<wo_ex>:SP,;
3) Check the CS call status
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
Related documents None
1.12.18 TCSM restart
Test case ID: RT000SD000021
Test case version: 1.1.0
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
138 (143) © Nokia Siemens Networks Issue 1.0-0
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
Related documents None
1.12.19 Call scenarios after interface modifications (set1)
Test case ID: RT000SD000023
Test case version: 2.1.0
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
© Nokia Siemens Networks 139 (143)
Related documents Corresponding RT PLAN
1.12.20 Call scenarios after interface modifications (set2)
Test case ID: RT000SD000034
Test case version: 1.0.0
Test Purpose Purpose of this test case is to verify 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: 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
Expected Results All the defined Call cases executed successfully after interface modifications
Related documents Corresponding RT PLAN
Test cases
140 (143) © Nokia Siemens Networks Issue 1.0-0
1.12.21 Call scenarios after interface modifications (set3)
Test case ID: RT000SD000035
Test case version: 1.0.0
Test Purpose Purpose of this test case is to verify CS traffic handling capability after interface/configuration modifications
Pre-requirements Interface modifications done according to RT Plan
Test Execution Name of the case: ID number: Version: Location updating RT000CC00001 2.1.0
MS to MS call RT000CC00002 3.1.0
Expected Results All the defined Call cases executed successfully after interface modifications
Related documents Corresponding RT PLAN
1.12.22 STMU: Transmission protection
Test case ID: RT000SD000040
Test case version: 1.0.0
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
© Nokia Siemens Networks 141 (143)
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.
Related documents Corresponding BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection procedure
1.12.23 STMU unit restart
Test case ID: RT000SD000041
Test case version: 1.0.0
Test Purpose
Test cases
142 (143) © Nokia Siemens Networks Issue 1.0-0
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.
No irrelevant logs or alarms occur.
Related documents Corresponding BSC3i/TCSM3i upgrade for SDH/Sonet equipment protection procedure
1.12.24 HW protection verification in case of ETIP/STMU
Test case ID: RT000SD000042
Test cases
Issue 1.0-0
© Nokia Siemens Networks 143 (143)
Test case version: 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.
No irrelevant logs or alarms occur.
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.
Recommended