SGSN 6.0 Acceptance Test Procedure

SG6 Verification Test Cases
Document Number
2008 Nokia Networks Oy
Pages
GPR33801.doc/0.1
The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia Networks' customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia Networks. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia Networks and the customer. However, Nokia 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 Networks will, if necessary, explain issues which may not be covered by the document. Nokia Networks' liability for any errors in the document is limited to the documentary correction of errors. Nokia Networks WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this document or the information in it. This document and the product it describes are considered protected by copyright according to the applicable laws. NOKIA logo is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only.
Copyright Nokia Oyj 2008. All rights reserved.
Document Number
Pages
GPR33801.doc/0.1
CONTENTS
1 2 2.1 2.1.1 2.2 2.2.1 2.2.2 2.3 2.4 2.4.1 2.4.2 2.5 2.6 2.7 2.8 2.9 2.9.1 2.9.2 2.9.3 2.9.4 2.9.5 2.9.6 2.9.7 2.9.8 2.9.9 2.9.10 2.9.11 2.10 2.11 2.12 2.13 2.14 2.14.1 2.14.2 2.14.3 2.14.4 2.14.5 2.14.6 2.15 2.15.1 2.16 2.16.1 2.16.2 2.16.3 2.16.4 Introduction ................................................................................................6 SG6 Test Cases ...........................................................................................7 SGSN system administration............................................................................7 Device Handling (MO Disk)..............................................................................7 SGSN parameter and data ..............................................................................8 Display SGSN Configuration Data .....................................................................8 Display Subscriber Data..................................................................................8 User Profile and Password Management ............................................................8 Routing and N7 Administration .........................................................................9 Handle N7 ...................................................................................................9 Handle Global Title ........................................................................................9 Handle Gb Interface .....................................................................................10 Display Active Alarm ....................................................................................10 Display All SGSN Timer ................................................................................11 Log files Administration.................................................................................11 O&M.........................................................................................................12 GPRS SP-EX SMMU restart ..........................................................................12 GPRS MCHU switchover...............................................................................12 GPRS WO-EX SMMU restart .........................................................................13 GPRS SP-EX OMU restart ............................................................................13 GPRS WO-EX OMU restart ...........................................................................14 GPRS SP-EX PAPU restart ...........................................................................14 GPRS PAPU switchover ...............................................................................15 GPRS WO-EX PAPU restart ..........................................................................16 GPRS SMMU switchover ..............................................................................16 GPRS SP-EX MCHU restart ..........................................................................17 GPRS WO-EX MCHU restart .........................................................................18 GPRS Attach..............................................................................................18 GPRS Detach.............................................................................................19 PDP Context ..............................................................................................19 PDP Context Deactivation .............................................................................20 Cell Changes, RA & LA Updates (Mobility Management) ......................................20 Intra SGSN RA update .................................................................................20 Inter SGSN RA update during data transfer .......................................................21 Cell change, same RA, MS in STANDBY state...................................................21 Cell change, same RA, MS in READY state.......................................................22 Cell change, different RA, MS in STANDBY state ...............................................22 Cell change, different RA, MS in READY state ...................................................23 Periodic RA Updates ....................................................................................24 Periodic RA update, PTMSI not allocated..........................................................24 Packet Routing And Data Transfer ..................................................................25 UL packet transfer .......................................................................................25 UL packet transfer, cell change during data flow .................................................25 DL packet transfer, cell change during data flow .................................................26 UL packet transfer, cell change, RA change during data flow.................................26
Document Number
Pages
GPR33801.doc/0.1
2.16.5 2.16.6 2.17 2.17.1 2.18 2.18.1 2.19 2.19.1 2.19.2 2.19.3 2.19.4 2.19.5 2.19.6 2.19.7 2.19.8 2.19.9 2.19.10 2.19.11 2.19.12 2.19.13 2.19.14 2.19.15 2.19.16 2.19.17 2.20 2.20.1 2.20.2 2.20.3 2.20.4 2.20.5 2.20.6 2.20.7 2.20.8 2.20.9 2.20.10 2.20.11
DL packet transfer, cell change, RA change during data flow ................................ 27 Simultaneous UL/DL packet transfer ............................................................... 27 PAGING ................................................................................................... 28 GPRS paging, MS in STANDBY mode, Network mode I ...................... 28 Ciphering .................................................................................................. 29 UL/DL Packet Transfer, Ciphering on .............................................................. 29 Charging................................................................................................... 29 CDR check (M-, S- CDRs) ............................................................................ 29 Intermediate charging .................................................................................. 30 Tariff change during daytime ......................................................................... 31 S-CDRs in case of PAPU switchover............................................................... 31 GPRS Duplicated CDR prevention, CG wakes up after a while.............................. 32 GPRS Duplicate CDR prevention, CG does not wake up. .................................... 33 GPRS CDR collection from multiple GSNs ....................................................... 34 GPRS CDR, Minimum/maximum threshold check, CDR is sent when time limit is exceeded. .............................................................................................. 34 GPRS Minimum/maximum threshold check, CDR is not sent before minimum volume threshold is exceeded........................................................................ 35 GPRS Redundancy test ............................................................................... 35 GPRS S-CDR includes MSISDN (also G-CDR) and Cell-ID .................................. 36 GPRS CDR creation, tariff change during data transfer........................................ 36 GPRS Intermediate CDRs ............................................................................ 37 GPRS CDR collected manually ...................................................................... 37 GPRS Charging, S-CDR closing according to data volume................................... 38 GPRS Charging, closing S-CDR when time limit is exceeded................................ 39 GPRS Charging, Closing M-CDR according to time limit ...................................... 39 Redundancy .............................................................................................. 40 GPRS Redundancy: Initializing redundant LAN backbone connection in SMMU...................................................................................................... 40 GPRS Redundancy: Initializing redundant LAN backbone connection in MCHU...................................................................................................... 41 GPRS Redundancy: Deactivating the feature from MCHU while GTP traffic, data sender makes intra-SGSN update............................................................ 41 GPRS Redundancy: Deactivating the feature from MCHU and PAPU while GTP traffic, subscriber makes inter BSC location update ..................................... 42 GPRS Redundancy: Deactivating the feature from PAPU and MCHU while GTP traffic, subscriber makes intra BSC location update ..................................... 44 GPRS Redundancy: Working router goes down, GTP traffic ................................. 45 GPRS Redundancy: Switchover between LAN interfaces within same PAPU with no GTP traffic ...................................................................................... 45 GPRS Redundancy: Switchover between WO-EX and SP-EX MCHUs while GTP traffic is ongoing .................................................................................. 46 GPRS Redundancy: Switchover between LAN interfaces within same MCHU with traffic ................................................................................................. 47 GPRS Redundancy: Switchover between LAN interfaces within same PAPU with GTP traffic .......................................................................................... 48 GPRS Redundancy: Switchover between WO-EX and SP-EX PAPUs while GTP traffic is ongoing .................................................................................. 49
Document Number
Pages
GPR33801.doc/0.1
2.21 2.21.1 2.21.2 2.21.3 2.21.4 2.22 2.22.1 2.23 2.24
Statistics ...................................................................................................49 GPRS mobility management measurements......................................................49 GPRS session management measurements......................................................50 Data measurements.....................................................................................51 CDR measurements.....................................................................................51 Overriding MS requested READY timer ............................................................52 Overriding MS requested READY timer ............................................................52 Operator configurable DSCP..........................................................................53 Online ciphering mode change .......................................................................55
Document Number
Pages
GPR33801.doc/0.1
Introduction
Introduction
This document describes the SGSN Release 6 (SG6) test cases. Some test cases require analyzer (e.g. Nethawk, PC with dial up, test terminals) and/or SGSN message monitoring skills.
Document Number
Pages
GPR33801.doc/0.1
SG6 Test Cases
SG6 Test Cases

SG6 related test cases are covering the following functions: O&M, GPRS Attach, GPRS Detach, PDP Context, Ready-Timer Expiry, Mobility Management, Periodic RA & LA Updates, Packet Routing And Data Transfer, PAGING, Short Message Service, Ciphering, Charging, Redundancy, Statistics, Controlled roaming, Overriding MS requested READY timer, SMS routing analysis, Operator configurable DSCP and Online ciphering mode change.
2.1
SGSN system administration
2.1.1
Device Handling (MO Disk)
Description: Required test environment: Required environment settings:
The purpose of the test case is to verify the procedure of handling such command: display file, copy file, delete file, modify/rename file. Commissioned SGSN 1. SGSN Commissioned. 2. Serial MML session to SGSN available. 1. Display all the software package( ZWQO;). 2. Display all the created software (ZWQO:CR;) 3. Display a particular file in MO disk (ZIWX). 4. Display the contents of a file.(ZWQL) . 5. Delete a file from MO disk (ZIWD). 6. Copy a file to MO disk (ZIPS) 7. Rename a file in MO disk (ZIWN) Result:
Guides for execution:
Expected results: Comments:
1. The file can be displayed, copied, deleted and modified
OK
NOK
Document Number
Pages
GPR33801.doc/0.1
SG6 Test Cases
2.2
SGSN parameter and data
2.2.1
Display SGSN Configuration Data
Description: Required test environment: Required environment settings: Guides for execution:
The purpose of the test case is to ensure the procedure of displaying SGSN data configuration such as Ready State Time and Detach Time. Commissioned SGSN 1. SGSN Commissioned. 2. Serial MML session to SGSN available. 1. Check the SGSN parameters (ZEJH) 2. Check the Ready, Standby and Detach state time. Result:
Expected results:
1. 2.
The ready and standby time is set to 44 sec. The detach timer is set to 30 mins.
OK OK
NOK NOK
Comments:
2.2.2
Description:
Display Subscriber Data

The purpose of the test case is to ensure the procedure of displaying subscriber data in the SGSN which are provided by the HLR Working GPRS network 1. Network elements accepted. 2. Site configured according to customer's network plan. Check subscriber data in SGSN (ZMMS) Result:
Required test environment: Required environment settings: Guides for execution:
The subscriber data in the SGSN is as provided by the HLR
OK
NOK
2.3
Description:
User Profile and Password Management

The purpose of the test case is to verify the procedure of displaying, creating, modifying and deleting User Profile and Password. Working GPRS network 1. Network elements accepted.
Required test environment: Required environment

Document Number
Pages
GPR33801.doc/0.1
SG6 Test Cases
settings:
2. Site configured according to customer's network plan. 1. Create user profile (ZIAA) 2. Create user ID (ZIAH) 3. Change password (ZIAG) 3. Delete user profile (ZIAR). 4. Delete user ID(ZIRD). 5. Modify user profile (ZIAA) Result:
Display, creation, modification and deletion of user profile possible.
OK
NOK
2.4
Routing and N7 Administration
2.4.1
Handle N7
The purpose of the test case is to verify the procedure of displaying, creating, modifying and deleting N7 Route, N7 Linkset and N7 Link. Working GPRS network 1. Network elements accepted. 2. Site configured according to customer's network plan. 1. 2. 3. Display, create, modify delete N7 route (ZNVI), (ZNRC),(ZNRB),(ZNRD) Display, create, modify delete N7 link set (ZNES),(ZNSC),(ZNSN)(ZNSD), Display, create, modify delete N7 link (ZNLI),(ZNCC),(ZNCM),(ZNCD) Result:
Display, Creation, Modification and deletion of N7 Route, link set and link is possible.
OK
NOK
2.4.2
Handle Global Title
Description: Required test environment: Required environment

Document Number
The purpose of the test case is to verify the procedure of displaying, creating, modifying and deleting the translation of Global Title in N7 Destinations. A Global Title can be defined according the numbering plan E164 (ISDN Directory Number) or E214 (Mobile Global Title out of IMSI translation). Working GPRS network 1. Network elements accepted.
Pages
GPR33801.doc/0.1
SG6 Test Cases
settings:
2. Site configured according to customer's network plan. 1. 2. 3. 4. Display GT results (ZNAI) Create translation result (ZNAC) Modify traslation result (ZNAM) Delete translation result (ZNAD). Result:
Display, creation, modification and deletion of GT are possible.
OK
NOK
2.5
Description:
Handle Gb Interface
The purpose of the test case to verify the procedure of displaying, creating, modifying and deleting the data of Gb interface. Working GPRS network 1. Network elements accepted. 2. Site configured according to customer's network plan. 1. 2. 3. 4. 5. 6. 7. 8. 9. Display Gb interface frame relay (ZFUI) Display Gb interface NSVC (ZFWO) Create Gb interface frame relay (ZFUC) Create Gb interface NSVC (ZFWC) Modify Gb interface frame relay (ZFUM) Modify Gb interface NSVC (ZFWM) Delete Gb interface frame relay (ZFUD) Change state of Gb interface NSVC (AFWS) Delete Gb interface NSVC (ZFWD) Result:
Required test environment: Required environment settings:
Display, creation, modification and deletion of Gb interface are possible
OK
NOK
2.6
Description:
Display Active Alarm

The purpose of the test case to ensure the procedure of displaying all active alarms, such as trunk alarm, N7 alarm, charging alarm, etc.. Working GPRS network 1. Network elements accepted. 2. Site configured according to customer's network plan.
1. 2.
Show all the alarms currently ON. (ZAHO) Show alarm history (ZAHP)
Document Number
Pages
GPR33801.doc/0.1
10
SG6 Test Cases
Result:
The alarms currently ON and the alarms history can be displayed.
OK
NOK
2.7
Description:
Display All SGSN Timer

The purpose of the test case is to verify the procedure of displaying and modifying all SGSN Timers Working GPRS network 1. Network elements accepted. 2. Site configured according to customer's network plan. 1. 2. Display all the timers (ZEJH) Modify timers (ZEJF) Result:
All the timers can be displayed and modified
OK
NOK
2.8
Description:
Log files Administration

The purpose of the test case is To check all log files in the exchange concerning all active alarms, all execute commands, all measurement, etc.
Working GPRS network 1. Network elements accepted. 2. Site configured according to customer's network plan. 1. 2. 3. Check the log files settings (ZDVI), set it as required Check the logs (ZDVP) Clear sub log files (ZDVF) Result:
Log files can be displayed
OK
NOK
Document Number
Pages
GPR33801.doc/0.1
11
SG6 Test Cases
2.9
O&M
2.9.1
GPRS SP-EX SMMU restart
The purpose of the test case is to verify that SP-EX SMMU is recovered after restart and data transfer is not deactivated. Working GPRS network 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make restart for SP-EX SMMU (ZUSU:SMMU,C=DSK;) 7. Monitor Gb-interface and check that no deactivate PDP context message or detach-messages are sent. 8. Check alarms, logs and system logs for SGSN. Result: 1. SMMU is recovered (restarted SMMU back in SP-EX state) OK OK OK NOK NOK NOK
Expected results:
2. PDP-context and data transfer are still active 3. No unnecessary alarms, logs or system logs generated to SGSN.
Comments:
2.9.2
GPRS MCHU switchover
The purpose of the test case is to verify that MCHU switchover works ok and MS is still attached and PDP context / data transfer is not deactivated during MCHU switchover. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 4. Two MSs, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make controlled switchover for MCHU 7. Monitor Gb-interface and check that no deactivate PDP context message or detach-messages are sent. 8. Check alarms, logs and system logs for SGSN. Result:
Document Number
Pages
GPR33801.doc/0.1
12
SG6 Test Cases
1. Switchover is successful (both MCHU's in correct working state)
OK OK OK OK
NOK NOK NOK NOK
Expected results:
2. PDP-context and data transfer are still active 3. No unnecessary alarms, logs or system logs generated to SGSN. 4. Charging is working properly, no extra CDRs etc.
Comments
2.9.3
GPRS WO-EX SMMU restart
The purpose of the test case is to verify that WO-EX SMMU is recovered after restart and data transfer is not deactivated. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. One MS, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make restart for WO-EX SMMU (ZUSU:SMMU,C=DSK;) 7. Attach subscriber, reactivate PDP context and data transfer after SGSN is back up and running. 8. Check alarms, logs and system logs for SGSN. Result: 1. All units are recovered. OK OK OK NOK NOK NOK
Expected results:
2. Attaching subscriber, PDP-context and data transfer is successful immediately after system is recovered. 3. No unnecessary alarms, logs or system logs generated to SGSN.
Comments:
System does not restart when restart WO-EX SMMU.
2.9.4
GPRS SP-EX OMU restart
The purpose of the test case is to verify that SP-EX OMU is recovered after restart and data transfer is not deactivated. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 4. One MS, One PC laptop with dial up.
Document Number
Pages
GPR33801.doc/0.1
13
SG6 Test Cases
1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make restart for SP-EX OMU (ZUSU:OMU,C=DSK;) 7. Monitor Gb-interface and check that no deactivate PDP context message or detachmessages are sent. 8. Check alarms, logs and system logs for SGSN. Result: 1. OMU is recovered (restarted OMU back in SP-EX state). OK OK OK NOK NOK NOK
Expected results:
Comments:
2.9.5
GPRS WO-EX OMU restart
The purpose of the test case is to verify that WO-EX OMU is recovered after restart and data transfer is not deactivated. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 4. One MS, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make restart for WO-EX OMU (ZUSU:OMU,C=DSK;) 7. Monitor Gb-interface and check that no deactivate PDP context message or detachmessages are sent. 8. Check alarms, logs and system logs for SGSN. Result: 1. OMU is recovered (restarted OMU back in WO-EX state). OK OK OK NOK NOK NOK
Expected results:
Comments:
2.9.6
GPRS SP-EX PAPU restart
Document Number
Pages
GPR33801.doc/0.1
14
SG6 Test Cases
The purpose of the test case is to verify that SP-EX PAPU is recovered after restart and data transfer is not deactivated. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 4. One MS, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make restart for SP-EX (ZUSU:PAPU..,C=DSK) 7. Monitor Gb-interface and check that no deactivate PDP context message or detach-messages are sent. 8. Check alarms, logs and system logs for SGSN. Result: 1. PAPU is recovered (restarted PAPU back in SP-EX state) 2. PDP-context and data transfer are still active OK OK OK OK NOK NOK NOK NOK
Expected results:
3. No unnecessary alarms, logs or system logs generated to SGSN. 4. Charging is working properly, no extra CDRs etc.
Comments:
2.9.7
Description:
GPRS PAPU switchover

The purpose of the test case is to verify that PAPU switchover works ok and MS can reattach and PDP context / data transfer is possible to reactivate after PAPU switchover. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 4. Two MSs, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Attach second MS. 4. Activate PDP context from MS (dial *99***128#). 5. Create FTP connection to FTP-server. 6. Start sending UL data packets from the MS to the server. 7. Make controlled switchover for PAPU. 8. Monitor Gb-interface and check that no deactivate PDP context message or detach-messages are sent. 9. Check alarms, logs and system logs for SGSN. 10. Activate PDP context again for the subscriber. 11. Create FTP connection to FTP-server. 12. Start sending UL data packets from the MS to the server Result: 1. Data packets should be sent and received correctly. OK OK NOK NOK
Expected results:
2. Switchover is successful (both PAPU's are in correct working state). 3. Both MS's are detched. Data transfer and PDP context is
Document Number
Pages
GPR33801.doc/0.1
15
SG6 Test Cases
allowed to deactivate. 4. No unnecessary alarms, logs or system logs generated to SGSN. 5. Reattach & Reactivation of PDP context and data transfer are successful. OK OK OK 6. Charging is working properly, no extra CDRs etc. OK NOK NOK NOK NOK
Comments:
2.9.8
GPRS WO-EX PAPU restart
The purpose of the test case is to verify that WO-EX PAPU is recovered after restart and data transfer and it is possible to reactivate data transfer after restart. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. One MS, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make restart for WO-EX PAPU where is active bearer channel configured (ZUSU:PAPU,C=DSK;). 7. Attach subscriber, reactivate PDP context and data transfer after unit recovered. 8. Check alarms, logs and system logs for SGSN. Result: 1. PAPU is recovered (restarted PAPU back in WO-EX state) 2. Attaching subscriber, PDP-context and data transfer is successful immediately after PAPU is recovered. OK OK NOK NOK
Expected results:
OK OK
NOK NOK
Comments:
2.9.9
Description:
GPRS SMMU switchover

The purpose of the test case is to verify that SMMU switchover works ok and MS is still attached and PDP context / data transfer is not deactivated during SMMU switchover. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR
Required test environment:
Document Number
Pages
GPR33801.doc/0.1
16
SG6 Test Cases
Required environment settings:
1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 4. One MS, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make controlled switchover for SMMU. 7. Monitor Gb-interface and check that no deactivate PDP context message or detachmessages are sent. 8. Check alarms, logs and system logs for SGSN. Result: 1. Switchover is successful (both SMMUs in correct working state) OK OK OK NOK NOK NOK
Expected results:
Comments:
2.9.10
GPRS SP-EX MCHU restart
The purpose of the test case is to verify that SP-EX MCHU is recovered after restart and data transfer is not deactivated. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 4. One MS, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make restart for SP-EX MCHU (ZUSU:MCHU,C=DSK;) 7. Monitor Gb-interface and check that no deactivate PDP context message or detachmessages are sent. 8. Check alarms, logs and system logs for SGSN. Result: 1. MCHU is recovered (restarted MCHU back in SP-EX state) 2. PDP-context and data transfer are still active OK OK OK OK NOK NOK NOK NOK
Expected results:
Comments:
Document Number
Pages
GPR33801.doc/0.1
17
SG6 Test Cases
2.9.11
GPRS WO-EX MCHU restart
The purpose of the test case is to verify that WO-EX MCHU is recovered after restart and data transfer is not deactivated. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. One MS, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Attach the subscriber. 3. Activate PDP context from MS (dial *99***128#). 4. Create FTP connection to FTP-server. 5. Start sending UL data packets from the MS to the server. 6. Make restart for WO-EX MCHU (ZUSU:MCHU,C=DSK;) NOTE! : CAUSES SYSTEM RESET 7. Attach subscriber, reactivate PDP context and data transfer after SGSN is back up and running. 8. Check alarms, logs and system logs for SGSN. Result: 1. All units are recovered. 2. Attaching subscriber, PDP-context and data transfer is successful immediately after system is recovered. OK OK NOK NOK
Expected results:
OK OK
NOK NOK
Comments:
CDR loss during restart.
2.10
PURPOSE:
GPRS Attach
The purpose of the test case is to verify, that GPRS attach can be performed and the subscriber is attached in the GPRS mobility management. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Subscribers detach flag is ON in SGSN or subscriber is unknown in SGSN. ZMMO:IMSI=xxxxxxxx; 4. PTMSI field is empty in the SIM card. 1. Attach the subscriber. Result:
PREREQUISITES:
TEST EXECUTION:
EXPECTED RESULTS:
1. Check from SGSN that the status of subscriber is 'attach'. ZMMO:IMSI=xxxxxxxx; detach flag = OFF
OK
NOK
Comments:
Document Number
Pages
GPR33801.doc/0.1
18
SG6 Test Cases
2.11
GPRS Detach
The purpose of the test case is to verify, that GPRS detach can be performed and the subscriber is detached in the GPRS mobility management. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. No active PDP context. 4. Subscribers detach flag is OFF in SGSN (MMO-command class). 1. Make GPRS detach for the subscriber. Result: 1. DETACH is successful. OK NOK
PURPOSE: PREREQUISITES: TEST EXECUTION:
EXPECTED RESULTS:
2. Check from SGSN the status of subscriber and detach time. ZMMO:IMSI=xxxxxxxxxxxxxxx; OK NOK
Comments:
2.12
PDP Context
This case is to prove GGSN-DHCP communication functionality and PDP-context activation 1. DHCP server available. 2. Configure the IP-parameters for the DHCP-server according to the network plan. 3. Configure the Access Point to use the configured DHCP-server for dynamic IP-address allocation. 4. Verify that the DHCP server's address pool is from the network range of the Access Point's "dynamic IP address" field. 5. The user authentication method of the Access Point should be "none". 1. Create PDP context. Result: 1. PDP context activation is successful. 2. DHCP server reserves the address for the MS. OK OK NOK NOK
PURPOSE:
PREREQUISITES:
TEST EXECUTION:
EXPECTED RESULTS:
3. PDP Context is created into APN in question: GGSN UI: Config -> Configuration per an Access Point -> Statistics per an Access Point -> Select the Access Point -> PDP Statistics: Active PDP Contexts: 1
OK
NOK
Comments:
Document Number
Pages
GPR33801.doc/0.1
19
SG6 Test Cases
2.13
PDP Context Deactivation

This case is to prove GGSN-DHCP communication functionality and PDP-context deactivation 1. Active PDP-context according to the test case: "Dynamic IP-address allocation, allocated by DHCP". 1. Deactivate PDP-context. Result: 1. PDP-context deactivation is successful. 2. After deactivation, IP-address is released.. OK OK NOK NOK
PURPOSE: PREREQUISITES: TEST EXECUTION:
EXPECTED RESULTS:
3. PDP context is cleared from the GGSN GGSN UI: Config -> Configuration per an Access Point -> Statistics per an Access Point -> Select the Access Point -> PDP Statistics: Active PDP Contexts: 0
OK
NOK
Comments:
2.14
Cell Changes, RA & LA Updates (Mobility Management)
2.14.1
Description:
Intra SGSN RA update

The purpose of the test case is to check that intra SGSN RA update is successful during DL data transfer with both network modes. GGSN, SGSN, LIG, BSC, BTS, CG, MSC/VLR, HLR 1. SG3 software up and running. GPRS attach, 2. PDP-context activation and data transfer can be done successfully. 3. One PAPU takes care RA1 and other handles RA2 1. Attach the subscriber. 2. Activate PDP context. 3. Create FTP connection to FTP server and transfer data files DL direction or do web browsing. 4. Change RA during DL data transfer. 5. Deactivate PDP context. Result:
Expected results:
1. Attach and PDP context activation works 2. Files are transferred OK.
OK OK
NOK NOK
Document Number
Pages
GPR33801.doc/0.1
20
SG6 Test Cases
3. Intra SGSN RA update works with.
OK
NOK
Unexpected results: Comments:
1. File transfer doesn't work 2. Intra SGSN RA update doesn't work
2.14.2
Inter SGSN RA update during data transfer
The purpose of the test case is to check that inter SGSN RA update is successful during DL data transfer with both network modes. GGSN, SGSN, LIG, BSC, BTS, CG, MSC/VLR, HLR 1. SG3 software up and running. GPRS attach, 2. PDP-context activation and data transfer can be done successfully. 3. One SGSN takes care RA1 and other handles RA2 1. Attach the subscriber. 2. Activate PDP context. 3. Create FTP connection to FTP server and transfer data files DL direction or do web browsing. 4. Change RA1 to RA2 during DL data transfer. 5. Deactivate PDP context. Result: 1. Attach and PDP context activation works OK OK OK NOK NOK NOK
Expected results:
2. Files are transferred OK with both NW types. 3. Inter SGSN RA update works with both NW modes.
1. File transfer doesn't work 2. Inter SGSN RA update doesn't work
2.14.3
Cell change, same RA, MS in STANDBY state
PURPOSE: PREREQUISITES:
TEST EXECUTION:
Purpose of this test case is to verify that cell change is successful when MS is in STANDBY state and both cells are under the same Routing Area. This test case requires networkmonitoring functionality from the MS. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS available in the same RA. 1. Check the READY STATE timer value from the SGSN (ZEJH; command). 2. Attach the subscriber. 3. Wait till READY STATE timer has been expired and MS is in STANDBY state. 4. Change cell under the same RA. 5. Check cell change from the MS.
Document Number
Pages
GPR33801.doc/0.1
21
SG6 Test Cases
Result: 1. Attach is successful. OK OK OK OK NOK NOK NOK NOK
EXPECTED RESULTS:
2. MS state is STANDBY 3. Cell change works. 4. MS is still in STANDBY state.
Comments:
2.14.4
PURPOSE:
Cell change, same RA, MS in READY state

Purpose of this test case is to verify that cell change is successful when MS is in READY state and both cells are under the same Routing Area. This test case requires network monitoring functionality from the MS. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS available in the same RA. 1. Check the READY STATE timer value from the SGSN (ZEJH; command). 2. Attach the subscriber. 3. Change cell under the same RA before the READY timer has been expired (default value 44 sec.). Value can also be changed bigger if needed. 4. Check cell change from the MS Result: 1. Attach is successful. OK OK OK OK NOK NOK NOK NOK
PREREQUISITES:
TEST EXECUTION:
EXPECTED RESULTS:
2. MS state is READY 3. Cell change works. 4. MS is still in READY state.
Comments:
2.14.5
Cell change, different RA, MS in STANDBY state
TEST EXECUTION:
Purpose of this test case is to verify that cell change is successful when MS is in STANDBY state and cells belong to different Routing Areas. This test case requires network monitoring functionality from the MS 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS available in different RA. 1. Attach the subscriber. 2. Wait till READY timer has been expired and MS is in STANDBY state (default timer value 44 sec.). 3. Change cell to the different RA. 4. Check cell change from the MS
Document Number
Pages
GPR33801.doc/0.1
22
SG6 Test Cases
Result: 1. Attach is successful. OK OK OK OK NOK NOK NOK NOK
EXPECTED RESULTS:
2. MS state is STANDBY 3. Cell change works. 4. MS is still in STANDBY->READY->STANDBY state.
Comments:
2.14.6
Cell change, different RA, MS in READY state
Purpose of this test case is to verify that cell change is successful when MS is in READY state and cells belong to the different Routing Areas. This test case requires network monitoring functionality from the MS. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS available in different RA. 1. Attach the subscriber. 2. Change cell to the different RA before the READY timer has been expired (default value 44 sec.). 3. Check cell change from the MS Result: 1. Attach is successful. OK OK OK OK NOK NOK NOK NOK
TEST EXECUTION:
EXPECTED RESULTS:
2. MS state is READY 3. Cell change works. 4. MS is still in READY state.
Comments:
Document Number
Pages
GPR33801.doc/0.1
23
SG6 Test Cases
2.15
Periodic RA Updates
2.15.1
PURPOSE:
Periodic RA update, PTMSI not allocated

The purpose of the test case is to verify the correct behavior of the GPRS system in a case of periodic RA update. New PTMSI is not allocated during periodic RA update. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Analyzer (Nethawk) 4. PTMSI is not allocated during periodic RA update
MXP:<PLMN_NAME>,ALL:; PTMSI SIG. REP.RATE FOR GPRS ATTACH.....................(PGPRS) 1 PTMSI SIG. REP.RATE FOR NORMAL RA UPDATE.........(PNRA) 1 PTMSI SIG. REP.RATE FOR NORMAL RA UP. NEW VISITOR.(PNRAVIS) 1 PTMSI SIG. REP.RATE FOR PERIODIC RA UPDATE.......(PPRA) 0 PTMSI ALLOC. REP.RATE FOR PERIODIC RA UPDATE.....(PPARA) 0
PREREQUISITES:
5. Timers in SGSN (example)

SGSN PARAMETERS: IMEI CHECK MODE........ .................(ICHM) OFF AUTHENTICATION MODE......................(AUM) OFF PTMSI SIGNATURE MODE.....................(PSMO) ON CIPHERING MODE IN USE....................(CIPINUSE) OFF CIPHERING MODE AFTER SYSTEM RES..........(CIP) OFF READY STATE TIMER........................(RDY) 000-44 mm-s MS REACHABLE TIMER.......................(MSRT) 005-00 mm-s PERIODIC RA UPDATE TIMER.................(PRAU) 003-00 mm-s
TEST EXECUTION:
1. Attach the subscriber. 2. Monitor Gb interface and check that MS sends periodic RA update message to SGSN. 3. Remove battery from the MS. 4. Wait till subscriber is detached in SGSN. Subscriber shall be detached in SGSN latest after MSRT+PRAU timers. Result:
EXPECTED RESULTS:
1. Attach is successful. 2. MS sends periodic RA update message to SGSN

ROUTING AREA UPDATE REQUEST (GPRS MM)
OK OK
NOK NOK
Comments:
Document Number
Pages
GPR33801.doc/0.1
24
SG6 Test Cases
2.16
Packet Routing And Data Transfer
2.16.1
UL packet transfer
TEST EXECUTION:
To verify that the data packets are correctly sent and received during UL packet transfer. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. MS with laptop PC and Dial-Up software. 1. Activate PDP context from MS (dial *99***128#). 2. Create FTP connection to FTP-server. 3. Start sending UL data packets from the MS to the server. 4. Check the contents of transferred file after sending. Result:
EXPECTED RESULTS:
1. Data packets should be sent and received correctly. 2. Contents of the file should not be corrupted.
OK OK
NOK NOK
Comments:
2.16.2
UL packet transfer, cell change during data flow
TEST EXECUTION:
To verify that the data packets are correctly received before and after the cell change (UL packet transfer works). This test case requires network monitoring functionality from the MS. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS. 4. MS with laptop PC and Dial-Up software. 1. Activate PDP context from MS (dial *99***128#). 2. Create FTP connection to FTP-server. 3. Start sending UL data packets from the MS to the server. 4. Change cell during packet transfer. 5. MS still sends packets after cell change. 6. Check the contents of transferred file after sending. Result: 1. Data packets should be sent and received correctly even if the mobile station has changed the cell during the data packet flow. 2. Contents of the file should not be corrupted. OK OK NOK NOK
EXPECTED RESULTS:
Comments:
Document Number
Pages
GPR33801.doc/0.1
25
SG6 Test Cases
2.16.3
.
DL packet transfer, cell change during data flow
TEST EXECUTION:
To verify that the data packets are correctly received before and after the cell change (DL packet transfer works). This test case requires network monitoring functionality from the MS. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS. 4. MS with laptop PC and Dial-Up software. 1. Activate PDP context from MS (dial *99***128#). 2. Create FTP connection to FTP-server. 3. Start sending DL data packets from the server to the MS. 4. Change cell during packet transfer. 5. MS still receives packets after cell change. 6. Check the contents of transferred file. Result: 1. Data packets should be sent and received correctly even if the mobile station has changed the cell during the data packet flow. 2. Contents of the file should not be corrupted. OK NOK
EXPECTED RESULTS:
OK
NOK
Comments:
2.16.4
UL packet transfer, cell change, RA change during data flow
PURPOSE:
PREREQUISITES:
TEST EXECUTION:
To verify that the data packets are correctly received before and after the cell change (UL packet transfer works). Cells in different Routing Area. This test case requires network monitoring functionality from the MS. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS in different RA. 4. MS with laptop PC and Dial-Up software. 1. Activate PDP context from MS (dial *99***128#). 2. Create FTP connection to FTP-server. 3. Start sending UL data packets from the MS to the server. 4. Change cell and RA during packet transfer. 5. MS still sends packets after cell change. 6. Check the contents of transferred file after sending. Result: 1. Data packets should be sent and received correctly even if the mobile station has changed the RA during the data packet flow. 2. Contents of the file should not be corrupted. OK NOK
EXPECTED RESULTS:
OK
NOK
Comments:
Document Number
Pages
GPR33801.doc/0.1
26
SG6 Test Cases
2.16.5
DL packet transfer, cell change, RA change during data flow
PURPOSE:
PREREQUISITES:
TEST EXECUTION:
To verify that the data packets are correctly received before and after the cell change (DL packet transfer works). Cells in different Routing Area. This test case requires network monitoring functionality from the MS. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS in different RA. 4. MS with laptop PC and Dial-Up software. 1. Activate PDP context from MS (dial *99***128#). 2. Create FTP connection to FTP-server. 3. Start sending DL data packets from the server to the MS. 4. Change cell and RA during packet transfer. 5. MS still receives packets after cell change. 6. Check the contents of transferred file. Result: 1. Data packets should be sent and received correctly even if the mobile station has changed the RA during the data packet flow. 2. Contents of the file should not be corrupted. OK NOK
EXPECTED RESULTS:
OK
NOK
Comments:
2.16.6
Simultaneous UL/DL packet transfer
TEST EXECUTION:
To verify that the simultaneous up- and downlink packet transfer works. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. MS with laptop PC and Dial-Up software. 4. FTP server software also in laptop PC. 1. Activate PDP context from MS (dial *99***128#). 2. Create FTP connection to FTP-server. 3. Start sending UL data packets from MS to server and DL data packets from server to MS 4. MS receives/sends packets. 5. Check the contents of transferred files. Result:
EXPECTED RESULTS:
1. Data packets should be sent and received correctly. 2. Contents of the file should not be corrupted.
OK OK
NOK NOK
Comments:
Document Number
Pages
GPR33801.doc/0.1
27
SG6 Test Cases
2.17
PAGING
2.17.1
Description:
GPRS paging, MS in STANDBY mode, Network mode I

To verify that packet switched paging function works via GPRS network. Network mode I. 1. Network Operation Mode I used. BSC MML: ZEGO:PAR -> NMO=0 SGSN MML: ZEJH; -> GS MODE=ON 2. Use analyzer (Gb interface). 3. Empty alarms and logs for SGSN. 1. Attach the subscriber and activate PDP context 2. Wait till the mobile subscriber is in STAND BY-state (READY-timer expired). 3. Ping the mobile from network. 4. Monitor Gb-interface and check that SGSN sends paging message to BSC. 5. Check alarms, logs and system logs for SGSN. Result: OK OK OK NOK NOK NOK
Prerequisites:
4. Paging is successful.
Expected results:
Mobile replies to ping. 5. No unclear alarms/logs are generated on SGSN
Document Number
Pages
GPR33801.doc/0.1
28
SG6 Test Cases
2.18
Ciphering
2.18.1
UL/DL Packet Transfer, Ciphering on
TEST EXECUTION:
To verify that the Up- and Downlink packet transfer works with ciphering. 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. Ciphering in use. 3. One GPRS MS, One PC laptop with dial up. 1. Activate PDP context 2. Create FTP connection from MS to FTP server. 3. Start sending UL data packets from MS to server and DL data packets from server to MS. 4. MS receives/sends packets. 5. Check the contents of the transferred file. Result: 1. Ciphering works. OK OK OK NOK NOK NOK
EXPECTED RESULTS:
2. Data packets should be sent and received correctly. 3. Contents of the transferred file are not corrupted.
Comments:
2.19
Charging
2.19.1
CDR check (M-, S- CDRs)
The purpose of the test case is to check that all CDR types are created by SGSN. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successful 1. Attach the subscriber. 2. Activate PDP context from MS (dial *99***128#). 3. Create FTP connection to FTP server and transfer some data (1 MB). 4. Do RA update/cell change during the data transfer 5. Check that SGSN sends CDRs to CG or detach-messages are sent. 6. Check from the CG that CDRs includes all needed information (IMSI, data amount, RA changes etc.)
Document Number
Pages
GPR33801.doc/0.1
29
SG6 Test Cases
Result:
Expected results: Unexpected results: Comments:
1. SGSN produces M- and S-CDRs normally and they include correct information.
OK
NOK
1. SGSN doesn't send any CDRs to CG or CDRs don't include correct information.
2.19.2
Intermediate charging
The purpose of the test case is to verify that intermediate charging works on SGSN. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS. 1. Define that SGSN will produce intermediate CDR after 500 kB data transfer. 2. Attach the subscriber. 3. Create FTP connection to FTP server and transfer at least 1 MB data file 4. Monitor the messages GCH (3FE) sent from SGSN active MCHU. When message with number EAC1 comes, an intermediate CDR is generated. This CDR is created after 500 kB data transfer. Result:
1. Intermediate charging works. 1. SGSN doesn't send any intermediate charging CDR.
OK
NOK
Document Number
Pages
GPR33801.doc/0.1
30
SG6 Test Cases
2.19.3
Tariff change during daytime
The purpose of the test case is to verify that tariff class change works simultaneously with data transfer and check what is effect to generation of CDRs. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1. Attach the subscriber. 2. Empty alarms and logs for SGSN. 3. Start S-CDR and M-CDR collection (ZGHS:S; ZGHS:M;). 4 Create tariff classes (ZGDC:<special day>,<class>;). 5. Activate PDP context. 6. Create FTP connection from MS to FTP server. 7. Check that there is open M-CDR and S-CDR for this subscriber (ZGHP;). 8. Start sending UL data packets from MS to server so that packet transfer and tariff class change will be happened simultaneously. 9. MS receives/sends packets. 10. Deactivate PDP context. 11. Check that CDRs are closed (ZGHP). 12. Check alarms, logs and system logs for SGSN. Result: 1. CDRs should be generated during file transfer correctly. OK OK OK NOK NOK NOK
Expected results:
2. Data packets should be sent and received correctly. 3. No unnecessary alarms, logs or system logs generated to SGSN
1. SGSN doesn't send any CDRs to CG or CDRs don't include correct information.
2.19.4
S-CDRs in case of PAPU switchover
The purpose of the test case is to check S-CDR producing in case of PAPU switchover. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up.
Document Number
Pages
GPR33801.doc/0.1
31
SG6 Test Cases
1. Attach the subscriber. 2. Empty alarms and logs for SGSN. 3. Start S-CDR and M-CDR collection (ZGHS:S; ZGHS:M;). 4. Activate PDP context. 5. Create FTP connection from MS to FTP server. 6. Check that there is open M-CDR and S-CDR for this subscriber (ZGHP;). 7. Start downloading data packets from server to MS. 8. MS receives packets. 9. Execute PAPU switchover. 10. Check that data transfer discontinues. 11. Check that CDRs are closed (ZGHP). 12. Check alarms, logs and system logs for SGSN. Result: OK 1. CDRs should be generated during file transfer correctly. 2. Data packets should be sent and received correctly. OK OK OK NOK NOK NOK NOK
Expected results:
3. After PAPU switchover new PAPU has the same IP-address than old PAPU. 4. No unnecessary alarms, logs or system logs generated to SGSN
SGSN doesn't send any CDRs to CG or CDRs don't include correct information.
2.19.5
GPRS Duplicated CDR prevention, CG wakes up after a while
This case tests if the duplicated CDR prevention works properly when SGSN - CG connection breaks before a successful CDR reception. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, 2 x CG Rel2. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 3 Connection to the CGs 1. Make CG1 inactive (e.g. shut it down). 2. Make some attaches and PDP context activation and make some data transfer 3. Activate CG1 after a while 4.Make some attaches and PDP context activation and make some data transfer. Result: 1. SGSN sends CDR(s) in a packet to CG1. N/A N/A N/A
Expected results:
2. SGSN is not able to get a response. 3. Then the SGSN sends the same CDR packet that could not be sent to CG1 to the next CG using the Data Record Transfer Request message.
Document Number
Pages
GPR33801.doc/0.1
32
SG6 Test Cases
4. As the connection to the CG2 is working, the CG2 is able to process the CDR packet. Since the packet was marked by the sending SGSN to be potentially duplicated, it is stored into the CG2, but not yet sent forward towards the Billing System. 5. The CG2 sends confirmation of the successful packet reception to the SGSN. The confirmation is performed by using the Data Record Transfer Response message, with the Cause value being Request Accepted. 6. SGSN now deletes the successfully sent (potentially duplicated) CDRs from its CDR buffer. 7. After that the CG1 is active again, it should take care of the CDRs again 8. Check from CG that there is no duplicated CDRs Cannot test this case because this will effect with live Network.
N/A
N/A
N/A N/A N/A
Comments:
2.19.6
GPRS Duplicate CDR prevention, CG does not wake up.
This case tests if the duplicated CDR prevention works properly when SGSN - CG connection breaks before a successful CDR reception. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, 2 x CG Rel2. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 3 Connection to the CGs. 1. Make CG1 inactive (e.g. shut it down). 2. Make some attaches and PDP context activation and make some data transfer. Result:
1. SGSN sends CDR(s) in a packet to CG1. 2. No response from CG1 3. The same package is sent to CG2.
N/A N/A N/A
Expected results:
4. The CG2 sends confirmation of the successful packet reception to the SGSN. The confirmation is performed by using the Data Record Transfer Response message, with the Cause value being Request Accepted 5. The CG1 does not wake up within certain time, because it is jammed, collapsed or CG1 is physically removed by operator. 6. The CDR is sent to Billing system.
N/A
N/A
N/A
Document Number
Pages
GPR33801.doc/0.1
33
SG6 Test Cases
Comments:
Cannot test this case because this will effect with live Network.
2.19.7
GPRS CDR collection from multiple GSNs
Collection of CDR records from multiple GSNs. Test case verifies that CDR records from multiple GSNs can be collected concurrently and independently. Before the test you should configure from ~cg/arm/config/arm.rc file that partials are not combined (parameter bypass_cm = 1). SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 3 Connection to the CG. 1.Start the cg_method from FTM Method Startup to start CG CDR collection. Start in the Unix shell hbgnscp program with correct parameters. 2. Create CDRs from at least two different GSNs. 3. Abort the CG methods. Result: 1. Methods start without any error notifications and stay up OK OK NOK NOK N/A
Expected results:
2. Verify from cg/arm/output that there is CDRs from different GSNs. 3. The CG methods and collection of CDRs will stop.
Comments:
2.19.8
GPRS CDR, Minimum/maximum threshold check, CDR is sent when time limit is exceeded.
Minimum/Maximum threshold check. Check that CDR is not sent before a certain threshold is exceeded. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1. Start the CG. Note ! Start hbgsncp startup method with debug parameter 99 from UI. 2. Set the minimum data volume threshold to a big count in SGSN (MML command ZGHM). 3. Set the maximum S-CDR duration to a low limit (ZGHM). 4. Make data transfer.
Document Number
Pages
GPR33801.doc/0.1
34
SG6 Test Cases
Result:
1. Data should not be sent before the Maximum S-CDR duration is exceeded (minimum data volume threshold is not exceeded).
OK
NOK
2.19.9
GPRS Minimum/maximum threshold check, CDR is not sent before minimum volume threshold is exceeded
Minimum/Maximum threshold check. Check that CDR is not sent before the minimum volume threshold is exceeded. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1. Start the CG. Note ! Start hbgsncp startup method with debug parameter 99 from UI. 2.Set the minimum data volume threshold to a certain value (MML command ZGHM). 3. Set the maximum S-CDR duration to 24h (MML command ZGHM). 4. Make data transfer. Result:
1. Data should not be sent before the minimum data transfer value is exceeded.
OK
NOK
2.19.10
GPRS Redundancy test
Test case verifies that the incoming CDR (from SGSN and GGSN) traffic shall be redirected from primary CG to secondary CG due to primary CG soon stopping service. And again redirected back when primary CG is started up. Before the test you should verify from ~cg/arm/config/arm.rc file (parameter bypass_cm to value 1) that partials are not combined, this makes easier to follow the test. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1. Start from the both CGs CG methods. 2. Start a PDP context and wait a couple of CDRs and verify that CDRs are going to primary CG. 3. Abort from primary CG the Hbgnscp startup method from the FTM Method Log and leave other methods running. 4. Restart Hbgnscp startup method from the primary CG. Result:
Document Number
Pages
GPR33801.doc/0.1
35
SG6 Test Cases
1. On both CGs methods starts correctly without any error codes. Node Alive Request message is sent to the GSNs. 2. CDRs are going to primary CG.
N/A N/A N/A N/A
Expected results:
3. Verify that CDRs are redirected to secondary CG and there is also right CDRs at directory ~cg/arm/output at secondary CG. 4. On tcpdump is seen that CDRs are redirected to primary CG and there is also right CDRs at directory ~cg/arm/output at primary CG.
Comments:
Cannot test this case because this will effect with live Network.
2.19.11
GPRS S-CDR includes MSISDN (also G-CDR) and Cell-ID
To check that S-CDR are stored with the right information. Cell-ID and MS-ISDN. G-CDR should also include MSISDN. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 3. Connection to CG 1. Interrogate status of CDR collection (ZGHH;) and check that S-CDR collection is not active (OFF). 2. Start collecting S-CDRs (ZGHS:S;). 3. Interrogate status of CDR collection (ZGHH;) and check that S-CDR collection is active (ON). 4. Make some S-CDRs. 5. Make the same test case but make cell change during context and check that the CDRs cell-ID is correct. Result:
Expected results:
1. S-CDRs should include MS-ISDN and cell-ID, even in cell change. 2. G-CDRs should include MS-ISDN.
OK OK
NOK NOK
Comments:
2.19.12
GPRS CDR creation, tariff change during data transfer.
Description: Required test environment:
To verify that tariff class change works simultaneously with data transfer and check what is effect to generation of CDRs. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG
Document Number
Pages
GPR33801.doc/0.1
36
SG6 Test Cases
1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1. Empty alarms and logs for SGSN. 2. Start S-CDR and M-CDR collection (ZGHS:S; ZGHS:M;). 3. Create tariff classes (ZGDC:<special day>,<class>;). 4. Activate PDP context. 5. Create FTP connection from MS to FTP server. 6. Check that there is open M-CDR and S-CDR for this subscriber (ZGHP;). 7. Start sending UL data packets from MS to server so that packet transfer and tariff class change will be happened simultaneously. 8. MS receives/sends packets. 9. Deactivate PDP context. 10. Check that CDRs are closed (ZGHP). 11. Check alarms, logs and system logs for SGSN. Result: 1. CDRs should be generated during file transfer correctly OK OK OK NOK NOK NOK
Expected results:
2. Data packets should be sent and received correctly. 3. No unnecessary alarms, logs or system logs generated to SGSN
Comments:
2.19.13
GPRS Intermediate CDRs
This test case verifies that intermediate CDRs are generated. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1. Attach the subscriber 2. Make some traffic (context activation, data transfer etc) 3. Monitor the messages GCH (3FE) sent from SGSNs active MCHU. Result:
1. Intermediate CDR is generated
OK
NOK
2.19.14
GPRS CDR collected manually
Description:
This test case verifies that CDRs can be generated manually.
Document Number
Pages
GPR33801.doc/0.1
37
SG6 Test Cases
SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1. Attach the subscriber 2. Make some traffic (context activation, data transfer etc) 3. Generate the CDRs manually by giving MML command ZGHA:Y; to SGSN. Result:
1. CDR is generated
OK
NOK
2.19.15
GPRS Charging, S-CDR closing according to data volume
To check that S-CDR is closed after data limit is exceeded. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1.Check disk saving settings from GCPARA (ZDFD:MCHU,<active MCHU index>:9B0,0,;) (Bytes 0 and 1 for S-CDR and bytes E and F for M-CDR) see gcpara_t from datatype definitions in j1env 2. Disable S-CDR online sending and enable disk saving (ZDFS:MCHU,1:9B0,0,0,B:; byte 0 to 00 and byte 1 to 01) 3. Set storing time interval to 15 minutes (ZGEV:0:INT=15:;). 4. Start S-CDR collection (ZGHS:S;). 5. Attach subscriber A to GPRS network. 6. Activate PDP context for subscriber A. 7. Check status of S-CDR (ON) and number of open S-CDRs for this subscriber (ZGHH; ZGHP;). 8. Download data packet sized over 1 MB. 9. After downloading has reached 1 MB, S-CDR should be closed and a new one opened. 10. Deactivate PDP context and detach subscriber A. 11. Wait till CDRs are saved to disk. To check this give command ZIFO:MCHU,SGCHAR:1&&10 (Numbers of disk files depend on which is the current file number in ring file system). 12. Check log writings from OMU, MCHU(active) and related PAPU-unit. Result:
1. S-CDR is closed after data limit is exceeded and a new one is opened.
OK
NOK
Document Number
Pages
GPR33801.doc/0.1
38
SG6 Test Cases
2.19.16
GPRS Charging, closing S-CDR when time limit is exceeded
To check that S-CDR is closed after time limit is exceeded. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1.Interrogate CDR collection status (ZGHH;). 2. Interrogate number of open CDRs (ZGHP;). 3. Set time limit for S-CDR closing to 3 minutes from GCPARA (scdr_time_trigger, time in 10 ms) 4.Start S-CDR collection (ZGHS:S;). 5. Interrogate CDR collection status (ZGHH;). S-CDR status should be ON.. 6. Interrogate number of open CDRs (ZGHP;). 7. Attach subscriber A to network. 8. Activate PDP context for subscriber A. 9. Check that S-CDR is opened (ZGHP;). 10. Keep PDP context active over 3 minutes. 11. After timer has expired check that GCHPRB creates an intermediate CDR. 12. Read logs and alarms. Result:
Expected results:
1. S-CDR is closed after time limit is exceeded and a new one is opened.
OK
NOK
Comments:
One thing that need to be highlighted and concerned is that decreasing the timer to three minutes would properly have impact to the MCHU CPU load. With enhancement of capacity in SG6, it may have this impact while SG5 has less capacity, this impact is not much. So this has to be monitired carefully!!
2.19.17
GPRS Charging, Closing M-CDR according to time limit
To check that closing of M-CDR works OK. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One MS, One PC laptop with dial up. 1. Interrogate M-CDR collection status (ZGHH;). 2. Interrogate number of open CDRs (ZGHP;). 3. Start M-CDR collection (ZGHS:M;). 4. Interrogate M-CDR collection status (ZGHH;). Status of M-CDR should be ON. 5. Interrogate number of open M-CDRs (ZGHP;) 6. Transfer GPRS MS to READY-mode. 7. Check timer values for M-CDR closing from GCPARA. 8. Check that M-CDR is opened (ZGHP;). 9. Wait till MS is transferred to STANDBY-mode. 10.Check that related M-CDR is closed after time out. 11. Read logs and alarms Result:
Expected results:
1. M-CDR closed
OK
NOK
Document Number
Pages
GPR33801.doc/0.1
39
SG6 Test Cases
Comments:
2.20
Redundancy
2.20.1
GPRS Redundancy: Initializing redundant LAN backbone connection in SMMU
The purpose of the test case is to verify that initializing the redundant LAN interface for SMMU succeeds with packet data traffic and SMSs. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR Traffic generator in use. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. Two or more MSs, One PC laptop with dial up. 3. SMMUs in SGSN have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 4. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Activate PDP context from MSs (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Alternatively to steps 1.-3. PAPUs are loaded with some packet data traffic generated by traffic generator. 5.Two or more MS sends SMS to each other. deactivation is aimed. 6. New LAN interfaces for SMMU units are initialized with MML class QR. Result: 1. Initializing the new LAN interface should not disturb existing data connections and SMS sending/receiving. OK NOK
Expected results:
2. Initialization succeeds. 3. No unexpected CPU logs writing or alarms concerned to initializing.
OK
NOK
NOK OK 1. Data connections are disconnected while NEW LAN-interface is initialized and/or SMSs sending/receiving fails. 2. Initializing fails or initializing produces unexpected CPU log writing or alarms. No available IP addresses for SMMU
Document Number
Pages
GPR33801.doc/0.1
40
SG6 Test Cases
2.20.2
GPRS Redundancy: Initializing redundant LAN backbone connection in MCHU
The purpose of the test case is to verify that initializing the redundant LAN interface for MCHU succeeds with packet data traffic and SMSs. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR Traffic generator in use. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. Two or more MSs, One PC laptop with dial up. 3. MCHUs in SGSN have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 4. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 5. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Activate PDP context from MSs (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Alternatively to steps 1.-3. PAPUs are loaded with some packet data traffic generated by traffic generator. 5.Two or more MS sends SMS to each other. deactivation is aimed. 6. New LAN interfaces for MCHU units are initialized with MML class QR. Result: 1. Initializing the new LAN interface should not disturb existing data connections and SMS sending/receiving. OK OK NOK NOK
Expected results:
2. Initialization succeeds. 3. No unexpected CPU logs writing or alarms concerned to initializing.
OK NOK 1. Data connections are disconnected while NEW LAN-interface is initialized and/or SMSs sending/receiving fails. 2. Initializing fails or initializing produces unexpected CPU log writing or alarms.
2.20.3
GPRS Redundancy: Deactivating the feature from MCHU while GTP traffic, data sender makes intra-SGSN update
Document Number
Pages
GPR33801.doc/0.1
41
SG6 Test Cases
The purpose of the test case is to verify that deactivating the redundant LAN interface from MCHU succeeds with packet data. Deactivation should not have any effects on charging i.e. all charging information is collected normally.
Description:
GPRS subscriber makes LA update while sending data packets. Deactivating this feature means that IP-addresses are deleted from redundant LAN interfaces, no other deactivation commands are needed. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 2. Traffic generator in use. 3. NetHawk for monitoring Abis interfaces. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One or more MSs, One PC laptop with dial up. 3. MCHUs in SGSN have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 4. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 5. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Activate PDP context from MSs (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Subscriber proceeds intra-SGSN update. Verify from Abis and network monitoring that MS performs cell update to new cell and MS is still sending packets. 5. Unless the deactivation of redundant interfaces don't concern all MCHU units make sure that traffic flow is controlled by the MCHU to which deactivation is aimed.. 6. Redundant LAN interfaces for MCHU units are deleted with MML command QRW. Result: 1. Deactivating the redundant MCHU LAN interface should not disturb existing data connections. 2. Deactivation succeeds. OK OK OK OK NOK NOK NOK NOK
Expected results:
3. No unexpected CPU logs writing or alarms concerned to initializing. 4. No effects on charging.
5. Data packet content remains the same after sending OK NOK compared to the original. 1. Data connections are disconnected while redundant MCHU LAN-interface is deactivated. 2. Deactivation fails or initializing produces unexpected CPU log writing or alarms. 3. Deactivation disturbs charging. 4. Data packet content doesn't remain the same after sending compared to the original.
2.20.4
GPRS Redundancy: Deactivating the feature from MCHU and PAPU while GTP traffic, subscriber makes inter BSC location update
Document Number
Pages
GPR33801.doc/0.1
42
SG6 Test Cases
The purpose of the test case is to verify that deactivating the redundant LAN interface from MCHU and PAPU succeed with packet data. Deactivation should not have any effects on charging i.e. all charging information is collected normally.
Description:
GPRS subscriber makes inter-BSC update between two SGSNs while sending data packets. Deactivating this feature means that IP-addresses are deleted from redundant LAN interfaces, no other deactivation commands are needed. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 2. Traffic generator in use. 3. NetHawk for monitoring Abis interfaces. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One or more MSs, One PC laptop with dial up. 3. MCHUs and PAPUs in SGSN have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 4. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 5. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 6. Two LAs with different Routing Area Codes (RAC) controlled by different BSCs are needed. BSCs are controlled by the different SGSN (ZEBP;). 1. Activate PDP context from MSs (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Subscriber proceeds inter-BSC update. Verify from Abis and network monitoring that MS performs cell update to new cell and MS is still sending packets. 5. Unless the deactivation of redundant interfaces don't concern all MCHU and PAPU units make sure that traffic flow is controlled by the MCHU and PAPU to which deactivation is aimed. 6. Redundant LAN interfaces for MCHU and PAPU units are deleted with MML command QRW. Result: 1. Deactivating the redundant MCHU and PAPU LAN interfaces should not disturb existing data connections. 2. Deactivation succeeds.. OK OK OK NOK NOK NOK
Expected results:
Unexpected results:
OK NOK 5. Data packet content remains the same after sending compared to the original. OK NOK 1. Data connections are disconnected while redundant PAPU and MCHU LAN-interface is deactivated. 2. Deactivation fails or initializing produces unexpected CPU log writing or alarms. 3. Deactivation disturbs charging. 4. Data packet content doesn't remain the same after sending compared to the original.
Comments:
Document Number
Pages
GPR33801.doc/0.1
43
SG6 Test Cases
2.20.5
GPRS Redundancy: Deactivating the feature from PAPU and MCHU while GTP traffic, subscriber makes intra BSC location update
The purpose of the test case is to verify that deactivating the redundant LAN interface from MCHU and PAPU succeed with packet data. Deactivation should not have any effects on charging i.e. all charging information is collected normally.
Description:
GPRS subscriber makes intra-BSC update while sending data packets. Deactivating this feature means that IP-addresses are deleted from redundant LAN interfaces, no other deactivation commands are needed. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 2. Traffic generator in use. 3. NetHawk for monitoring Abis interfaces. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One or more MSs, One PC laptop with dial up. 3. MCHUs and PAPUs in SGSN have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 4. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 5. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 6. Two LAs with different Routing Area Codes (RAC) controlled by the same BSC are needed. 1. Activate PDP context from MSs (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Subscriber proceeds intra-BSC update. Verify from Abis and network monitoring that MS performs cell update to new cell and MS is still sending packets. 5. Unless the deactivation of redundant interfaces don't concern all MCHU and PAPU units make sure that traffic flow is controlled by the MCHU and PAPU to which deactivation is aimed. 6. Redundant LAN interfaces for MCHU and PAPU units are deleted with MML command QRW. Result: 1. Deactivating the redundant MCHU and PAPU LAN interfaces should not disturb existing data connections. 2. Deactivation succeeds. OK OK OK NOK NOK NOK
Expected results:
NOK OK 5. Data packet content remains the same after sending OK NOK compared to the original. 1. Data connections are disconnected while redundant PAPU and MCHU LAN-interface is deactivated. 2. Deactivation fails or initializing produces unexpected CPU log writing or alarms. 3. Deactivation disturbs charging. 4. Data packet content doesn't remain the same after sending compared to the original.
Document Number
Pages
GPR33801.doc/0.1
44
SG6 Test Cases
2.20.6
GPRS Redundancy: Working router goes down, GTP traffic
The purpose of the test case is to verify that when working (master) router goes down GTP traffic is still plied between MS and backbone. Router's state change should not have any effect on charging. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 2. Traffic generator in use. 3. NetHawk for monitoring Abis interfaces. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One or more MSs, One PC laptop with dial up. 3. MCHUs and PAPUs in SGSN have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 4. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 5. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Activate PDP context from MSs (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Switch off the power from router which in routing the traffic. Result: 1. Powering off the working router doesn't have effect ongoing GTP traffic. OK OK NOK NOK
Expected results:
2. Working LAN switch takes in use redundant connection to the backup router when it lost the connection to the master router. 3. No effects on charging.
OK
NOK
4. Data packet content remains the same after sending compared to the original. OK NOK 1. Data connections are disconnected while connection to the master router is lost. 2. Master router's state changes produce unexpected CPU log writing or alarms. 3. Master router's state changes disturb charging. 4. Data packet content doesn't remain the same after sending compared to the original.
2.20.7
GPRS Redundancy: Switchover between LAN interfaces within same PAPU with no GTP traffic
The purpose of the test case is verify that when working (master) LAN switch goes down PAPU takes redundant connection to the backup switch in use. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR
Document Number
Pages
GPR33801.doc/0.1
45
SG6 Test Cases
1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. PAPU units have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 3. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 4. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Switch off the power from master LAN switch connected to PAPU. 2.Check with QR command that switchover have been proceeded between master and backup LAN connections, i.e. former backup connection is now master. 3. Start sending UL data packets from the MSs to the FTP server. 4. Switch off the power from router which in routing the traffic. Result: 1. Switchover between master and backup LAN connections between PAPU and switches should succeed. OK NOK
Expected results:
OK NOK 2. No unexpected alarms or CPU log writings. 1. Switchover between master and backup LAN connections between PAPU and switches doesn't succeed. 2. Unexpected alarms or CPU log writings.
2.20.8
GPRS Redundancy: Switchover between WO-EX and SP-EX MCHUs while GTP traffic is ongoing
The purpose of the test case is to verify that working (master) LAN connection to the master switch stays in use when MCHU makes switchover. There is GTP traffic going through SGSN. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 2. Traffic generator in use. 3. One GPRS MS and laptop with dial-up software. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. MCHU units have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 3. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 4. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Activate PDP context from MS (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Make switchover to the MCHUs with MML command (USC). 5. Check with QR command that when MCHU switch over have been proceeded master LAN connection have stayed in same interface and IP address. Result:
Expected results:
1. Master and backup LAN connections stays the same unless PAPU units makes switchover. succeed.
OK
NOK
Document Number
Pages
GPR33801.doc/0.1
46
SG6 Test Cases
2. No unexpected alarms or CPU log writings. 3. Charging should not been lost.
OK OK
NOK NOK
1. Master and backup LAN connections make also switchover when MCHU units make switchover. 2. Charging is partly or totally lost. 3. Unexpected alarms or CPU log writings
2.20.9
GPRS Redundancy: Switchover between LAN interfaces within same MCHU with traffic
The purpose of the test case is to verify that when working (master) LAN switch goes MCHU takes redundant connection to the backup switch in use. There is GTP traffic going through SGSN. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 2. Traffic generator in use. 3. One GPRS MS and laptop with dial-up software. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. MCHU units have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 3. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 4. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Activate PDP context from MS (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Switch off the power from master LAN switch connected to MCHU. 5. Check with QR command that switchover have been proceeded between master and backup LAN connections, i.e. former backup connection is now master. Result: OK NOK
1. Switchover between master and backup LAN connections between MCHU and switches should succeed.. 2. No unexpected alarms or CPU log writings.
OK
NOK
Expected results:
3. LAN interface switchover has no effect on ongoing GTP traffic. 4. LAN interface switchover has no effect on charging or mobility management.
OK
NOK
Unexpected results:
NOK OK 1. Switchover between master and backup LAN connections between MCHU and switches doesn't succeed. 2. LAN interface switchover disturbs ongoing GTP traffic, charging or mobility management. 3. Unexpected alarms or CPU log writings
Document Number
Pages
GPR33801.doc/0.1
47
SG6 Test Cases
Comments:
2.20.10
GPRS Redundancy: Switchover between LAN interfaces within same PAPU with GTP traffic
The purpose of the test case is to verify that when working (master) LAN switch goes PAPU takes redundant connection to the backup switch in use. There is GTP traffic going through SGSN. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 2. Traffic generator in use. 3. One GPRS MS and laptop with dial-up software. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. PAPU units have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 3. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 4. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Activate PDP context from MS (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Switch off the power from master LAN switch connected to PAPU.. 5. Check with QR command that switchover have been proceeded between master and backup LAN connections, i.e. former backup connection is now master. Result: 1. Switchover between master and backup LAN connections between PAPU and switches should succeed.. 2. No unexpected alarms or CPU log writings. OK NOK
Expected results:
OK OK
NOK NOK
3. LAN interface switchover has no effect on ongoing GTP traffic. 4. LAN interface switchover has no effect on charging or mobility management.
NOK OK 1. Switchover between master and backup LAN connections between PAPU and switches doesn't succeed. 2. LAN interface switchover disturbs ongoing GTP traffic or charging. 3. Unexpected alarms or CPU log writings
Document Number
Pages
GPR33801.doc/0.1
48
SG6 Test Cases
2.20.11
GPRS Redundancy: Switchover between WO-EX and SP-EX PAPUs while GTP traffic is ongoing
The purpose of the test case is verify that working (master) LAN connection to the master switch stays in use when PAPU makes switchover. There is GTP traffic going through SGSN. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 2. Traffic generator in use. 3. One GPRS MS and laptop with dial-up software. 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. PAPU units have been equipped with CPU plug-in units (e.g. CP550-B or P6MX) incorporating two LAN interfaces. Redundant LAN interfaces have been defined (QRN command). 3. Redundant CPU LAN interfaces have connections to different switches, i.e. these switches are redundant to each other. 4. At least two LAN switches (e.g. Cisco Catalyst 2900) and two routers supporting VRRP 1. Activate PDP context from MS (with laptop Dial-Up *99***128#). 2. Create FTP connections from each MS to FTP-server. 3. Start sending UL data packets from the MSs to the FTP server. 4. Make switchover to the PAPU units with MML command (USC). 5. Check with QR command that switchover have been proceeded between master and backup LAN connections, i.e. former backup connection is now master. Result: 1. Master and backup LAN connections stays the same unless PAPU units makes switchover. OK NOK
Expected results:
NOK OK 2. No unexpected alarms or CPU log writings. 1. Master and backup LAN connections make also switchover when PAPU units make switchover. 2. Unexpected alarms or CPU log writings
2.21
Statistics
2.21.1
GPRS mobility management measurements
The purpose of the test case is to verify SGSN statistics works. GPRS mobility management measurement provides information on, for example, successful and failed GPRS attaches, and PAPU and SGSN area updates. Counters are collected on cell level. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One GPRS MS and laptop with dial-up software.
Document Number
Pages
GPR33801.doc/0.1
49
SG6 Test Cases
1. Check that alarm 3003 INCORRECT MEASUREMENT DATA is not active 2. Check if measurement is already activated: ZTPI:; 3. Modify SGSN measurement characteristics: ZTPM:GMMT,ALL,00-00-24-00,15:;. 4. Start measurement: ZTPS:GMMT,:; 5. Attach the subscriber. 6. Transfer some data and do RA/LA updates. 7. Stop measurement: ZTPE:GMMT,:; 8. Check that SMS measurement counters have been updated correctly. (Copy files from MCHU's disk /SGSTAT directory and decode files with SGMEAS program) Result: 1. Attach and PDP context activation works. 2. Mobility management statistics are correct. 1. Mobility management statistics are not correct 2. Alarm 3003 INCORRECT MEASUREMENT DATA is active OK OK NOK NOK
2.21.2
GPRS session management measurements
The purpose of the test case is to verify SGSN statistics works. GPRS session management measurement provides information on, for example, different PDP context activations and deactivations. Counters are collected on cell level. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One GPRS MS and laptop with dial-up software. 1. Check that alarm 3003 INCORRECT MEASUREMENT DATA is not active 2. Check if measurement is already activated: ZTPI:; 3. Modify SGSN measurement characteristics: ZTPM:SMTM,ALL,00-00-24-00,15:;. 4. Start measurement: ZTPS:SMTM,:; 5. Attach the subscriber. 6. Transfer some data and do RA/LA updates. 7. Stop measurement: ZTPE:SMTM,:; 8. Check that SMS measurement counters have been updated correctly. (Copy files from MCHU's disk /SGSTAT directory and decode files with SGMEAS program) Result: 1. Attach and PDP context activation works. 2. Session management statistics are correct 1. Session management statistics are not correct 2. Alarm 3003 INCORRECT MEASUREMENT DATA is active
Pages
Expected results: Unexpected results:
OK OK
NOK NOK
Document Number
GPR33801.doc/0.1
50
SG6 Test Cases
Comments:
2.21.3
Data measurements
The purpose of the test case is to verify SGSN statistics works. Data measurement provides information on, for example, the number of GTP packets sent in uplink and downlink direction. Counters are collected on PAPU level. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One GPRS MS and laptop with dial-up software. 1. Check that alarm 3003 INCORRECT MEASUREMENT DATA is not active 2. Check if measurement is already activated: ZTPI:; 3. Modify SGSN measurement characteristics: ZTPM:DATA,ALL,00-00-24-00,15:; 4. Start measurement: ZTPS:DATA,:; 5. Attach the subscriber. 6. Transfer some data and do RA/LA updates. 7. Stop measurement: ZTPE:DATA,:; 8. Check that SMS measurement counters have been updated correctly. (Copy files from MCHU's disk /SGSTAT directory and decode files with SGMEAS program) Result: 1. Attach and PDP context activation works. 2. Data measurement statistics are correct 1. Data measurement statistics are not correct 2. Alarm 3003 INCORRECT MEASUREMENT DATA is active OK OK NOK NOK
2.21.4
CDR measurements
The purpose of the test case is to verify SGSN statistics works. CDR measurement provides information on, for example, received S-CDRs and M-CDRs. Counters are collected on SGSN level. 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR 1. SG2 software up and running. GPRS attach, PDP-context activation and data transfer can be done successfully. 2. One GPRS MS and laptop with dial-up software.
Document Number
Pages
GPR33801.doc/0.1
51
SG6 Test Cases
1. Check that alarm 3003 INCORRECT MEASUREMENT DATA is not active 2. Check if measurement is already activated: ZTPI:; 3. Modify SGSN measurement characteristics: ZTPM:CDRM,ALL,00-00-24-00,15:; 4. Start measurement: ZTPS:CDRM,:; 5. Attach the subscriber. 6. Transfer some data and do RA/LA updates. 7. Stop measurement: ZTPE:CDRM,:; 8. Check that SMS measurement counters have been updated correctly. (Copy files from MCHU's disk /SGSTAT directory and decode files with SGMEAS program) Result: 1. Attach and PDP context activation works. 2. CDR measurement statistics are correct. 1. CDR measurement statistics are not correct. 2. Alarm 3003 INCORRECT MEASUREMENT DATA is active OK OK NOK NOK
2.22
Overriding MS requested READY timer
2.22.1
Overriding MS requested READY timer

The value of the READY timer is to be negotiated between the MS and the network using the GPRS Attach RAU procedure.
Description:
If Override the MS ready state timer value (ORDY) parameter value is TRUE, the operator overrides the value of the READY timer requested by the MS by using the configurable parameter value (RDY) for the READY timer. SGSN, GGSN, MCS HLR, BSS 1. Subscribers is missing or detached (detach flag is ON) in SGSN ZMMO:IMSI=234222222122000; 1. Check alarms and clear unit logs for SGSN. 2. Set Overwrite MS Ready Timer to YES. (EJF:MM:ORDY) 3. Set Ready State Timer to e.g. 20sec. (EJF:MM:RDY)
4. Start monitoring of Gb interface with Nethawk 5. Make attach and check that MS sends the value for Ready Timer but the value for Ready State Timer (20s) 6. Check alarms, logs and system logs.
Result:
Expected results:
1. Command succeeds
OK
NOK
Document Number
Pages
GPR33801.doc/0.1
52
SG6 Test Cases
2. Signalling sequence shall be as follows. attach request----------------------------> SGSN
OK
NOK
ready_timer_value = (20s) attach accept <--------------------------------- SGSN
Check that no unspecified alarms, unit logs or system logs generated to SGSN
2.23
Description:
Operator configurable DSCP

This test case verifies the user modified DSCP values have been used on IP traffic on Gn and Gb interfaces (Gb over IP feature has to be used). SGSN, GGSN, MSC/HLR, BSS Subscriber is attached in SGSN (detach flag=OFF, MML-command ZMMO:IMSI=23422..;).
Document Number
Pages
GPR33801.doc/0.1
53
SG6 Test Cases
1. Check alarms and clear unit logs for SGSN. 2. Start monitoring of Gb interface with Nethawk (if Gb over IP is used) 3. Start monitoring of Gn interface with gtpdump on GGSN. 4. Activate PDP context 5. Set Traffic class 1 DSCP mapping value to other than default Possible DSCP values are (as in IETF standards): Best Effort AF Class 1, Low Drop Precedence AF Class 1, Medium Drop Precedence AF Class 1, High Drop Precedence AF Class 2, Low Drop Precedence AF Class 2, Medium Drop Precedence AF Class 2, High Drop Precedence AF Class 3, Low Drop Precedence AF Class 3, Medium Drop Precedence AF Class 3, High Drop Precedence Guides for execution: AF Class 4, Low Drop Precedence AF Class 4, Medium Drop Precedence AF Class 4, High Drop Precedence Expedited Forwarding 101110 000000 001010 001100 001110 010010 010100 010110 011010 011100 011110 100010 100100 100110
DSCP values could be modified by :ZEJF:QOS:DSCPM=TC1:DSCP=<>; 6. Check that values are updated ZEJH:QOS; 7. Activate PDP context and transfer data between SGSN and GGSN, and SGSN and BSC 8. Attach new subscriber, activate PDP context and transfer data between SGSN and GGSN, and SGSN and BSC 9. Deactivate PDP contexts. 10. Check alarms, logs and system logs for SGSN. 11. Set DC values back to default. ZEJF:QOS:DSCPM=TC1:DSCP:DEF;
Result: OK OK NOK NOK
1. Command succeeds
Expected results:
2. PDP context activation is successful 3. Check that new values are used on second PDP context. Check that the signalling messages sent to Gn and Gb
OK
NOK
Document Number
Pages
GPR33801.doc/0.1
54
SG6 Test Cases
interface has DSCP value Expedited Forwarding (using e.g. Ethereal).

No Gb over IP has been implemented during acceptance test.
2.24
Online ciphering mode change

This test case verifies online ciphering mode modifications during attach and RAU procedures. SGSN, GGSN, MSC/HLR, BSS 1.The ciphering has been set OFF in SGSN (ZEJH:SEC; command). 1. Check active alarms and clear unit logs 2. Start monitoring of Gb interface 3. Attach the subscriber. 4. Activate PDP context. 5. Set ciphering ON (ZEJF:SEC:..; also authentication has to be ON) 6. Perform Intra PAPU RAU 7. Perform INTRA PAPU RAU
8. Perform INTER SGSN RAU 9. Set ciphering mode off (ZEJF) 10. Perform INTER SGSN RAU 11. Perform INTRA PAPU RAU 12. Perform INTER SGSN RAU 13. Deactivate PDP context 13.Perform detach to MS 14. Check active alarms and clear unit logs Result: 1. Check that ciphering is used on attach & RAU cases when ciphering is activated. OK NOK
Expected results:
2. No unclear alarms, unit logs or system logs generated to SGSN OK NOK
Unexpected results:
Document Number
Pages
GPR33801.doc/0.1
55
SG6 Test Cases
Comments:
Document Number
Pages
GPR33801.doc/0.1
56

SGSN 6.0 Acceptance Test Procedure

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SGSN 6.0 Acceptance Test Procedure

Caricato da

Copyright:

Formati disponibili

SG6 Verification Test Cases

2008 Nokia Networks Oy

Copyright Nokia Oyj 2008. All rights reserved.

2008 Nokia Networks Oy

2008 Nokia Networks Oy

2008 Nokia Networks Oy

2.21 2.21.1 2.21.2 2.21.3 2.21.4 2.22 2.22.1 2.23 2.24

2008 Nokia Networks Oy

2008 Nokia Networks Oy

SG6 Test Cases

SG6 Test Cases

SGSN system administration

Device Handling (MO Disk)

Description: Required test environment: Required environment settings:

Guides for execution:

Expected results: Comments:

1. The file can be displayed, copied, deleted and modified

2008 Nokia Networks Oy

SG6 Test Cases

SGSN parameter and data

Display SGSN Configuration Data

Display Subscriber Data

Required test environment: Required environment settings: Guides for execution:

Expected results: Comments:

The subscriber data in the SGSN is as provided by the HLR

User Profile and Password Management

Required test environment: Required environment

2008 Nokia Networks Oy

SG6 Test Cases

Guides for execution:

Expected results: Comments:

Display, creation, modification and deletion of user profile possible.

Routing and N7 Administration

Description: Required test environment: Required environment settings:

Guides for execution:

Expected results: Comments:

Handle Global Title

Description: Required test environment: Required environment

2008 Nokia Networks Oy

SG6 Test Cases

Guides for execution:

Expected results: Comments:

Display, creation, modification and deletion of GT are possible.

Required test environment: Required environment settings:

Guides for execution:

Expected results: Comments:

Display, creation, modification and deletion of Gb interface are possible

Display Active Alarm

Required test environment: Required environment settings:

Guides for execution:

2008 Nokia Networks Oy

SG6 Test Cases

Expected results: Comments:

The alarms currently ON and the alarms history can be displayed.

Display All SGSN Timer

Required test environment: Required environment settings: Guides for execution:

Expected results: Comments:

All the timers can be displayed and modified

Log files Administration

Required test environment: Required environment settings:

Guides for execution:

Expected results: Comments:

Log files can be displayed