SGSN 6.0 Acceptance Test Procedure

Document Number GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

1

SG6 Verification Test Cases



Pages

2

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.



Pages

3

CONTENTS

1 Introduction ................................................................................................6

2 SG6 Test Cases ...........................................................................................7 2.1 SGSN system administration............................................................................7 2.1.1 Device Handling (MO Disk)..............................................................................7 2.2 SGSN parameter and data ..............................................................................8 2.2.1 Display SGSN Configuration Data .....................................................................8 2.2.2 Display Subscriber Data..................................................................................8 2.3 User Profile and Password Management ............................................................8 2.4 Routing and N7 Administration .........................................................................9 2.4.1 Handle N7 ...................................................................................................9 2.4.2 Handle Global Title ........................................................................................9 2.5 Handle Gb Interface .....................................................................................10 2.6 Display Active Alarm ....................................................................................10 2.7 Display All SGSN Timer ................................................................................11 2.8 Log files Administration .................................................................................11 2.9 O&M.........................................................................................................12 2.9.1 GPRS SP-EX SMMU restart ..........................................................................12 2.9.2 GPRS MCHU switchover...............................................................................12 2.9.3 GPRS WO-EX SMMU restart .........................................................................13 2.9.4 GPRS SP-EX OMU restart ............................................................................13 2.9.5 GPRS WO-EX OMU restart ...........................................................................14 2.9.6 GPRS SP-EX PAPU restart ...........................................................................14 2.9.7 GPRS PAPU switchover ...............................................................................15 2.9.8 GPRS WO-EX PAPU restart ..........................................................................16 2.9.9 GPRS SMMU switchover ..............................................................................16 2.9.10 GPRS SP-EX MCHU restart ..........................................................................17 2.9.11 GPRS WO-EX MCHU restart .........................................................................18 2.10 GPRS Attach..............................................................................................18 2.11 GPRS Detach.............................................................................................19 2.12 PDP Context ..............................................................................................19 2.13 PDP Context Deactivation .............................................................................20 2.14 Cell Changes, RA & LA Updates (Mobility Management) ......................................20 2.14.1 Intra SGSN RA update .................................................................................20 2.14.2 Inter SGSN RA update during data transfer .......................................................21 2.14.3 Cell change, same RA, MS in STANDBY state ...................................................21 2.14.4 Cell change, same RA, MS in READY state.......................................................22 2.14.5 Cell change, different RA, MS in STANDBY state ...............................................22 2.14.6 Cell change, different RA, MS in READY state ...................................................23 2.15 Periodic RA Updates ....................................................................................24 2.15.1 Periodic RA update, PTMSI not allocated..........................................................24 2.16 Packet Routing And Data Transfer ..................................................................25 2.16.1 UL packet transfer .......................................................................................25 2.16.2 UL packet transfer, cell change during data flow .................................................25 2.16.3 DL packet transfer, cell change during data flow .................................................26 2.16.4 UL packet transfer, cell change, RA change during data flow.................................26



Pages

4

2.16.5 DL packet transfer, cell change, RA change during data flow ................................ 27 2.16.6 Simultaneous UL/DL packet transfer ............................................................... 27 2.17 PAGING ................................................................................................... 28 2.17.1 GPRS paging, MS in STANDBY mode, Network mode I ...................... 28 2.18 Ciphering .................................................................................................. 29 2.18.1 UL/DL Packet Transfer, Ciphering on .............................................................. 29 2.19 Charging................................................................................................... 29 2.19.1 CDR check (M-, S- CDRs) ............................................................................ 29 2.19.2 Intermediate charging .................................................................................. 30 2.19.3 Tariff change during daytime ......................................................................... 31 2.19.4 S-CDRs in case of PAPU switchover............................................................... 31 2.19.5 GPRS Duplicated CDR prevention, CG wakes up after a while.............................. 32 2.19.6 GPRS Duplicate CDR prevention, CG does not wake up. .................................... 33 2.19.7 GPRS CDR collection from multiple GSNs ....................................................... 34 2.19.8 GPRS CDR, Minimum/maximum threshold check, CDR is sent when time limit

is exceeded. .............................................................................................. 34 2.19.9 GPRS Minimum/maximum threshold check, CDR is not sent before minimum

volume threshold is exceeded........................................................................ 35 2.19.10 GPRS Redundancy test ............................................................................... 35 2.19.11 GPRS S-CDR includes MSISDN (also G-CDR) and Cell-ID .................................. 36 2.19.12 GPRS CDR creation, tariff change during data transfer........................................ 36 2.19.13 GPRS Intermediate CDRs ............................................................................ 37 2.19.14 GPRS CDR collected manually ...................................................................... 37 2.19.15 GPRS Charging, S-CDR closing according to data volume................................... 38 2.19.16 GPRS Charging, closing S-CDR when time limit is exceeded................................ 39 2.19.17 GPRS Charging, Closing M-CDR according to time limit ...................................... 39 2.20 Redundancy .............................................................................................. 40 2.20.1 GPRS Redundancy: Initializing redundant LAN backbone connection in

SMMU...................................................................................................... 40 2.20.2 GPRS Redundancy: Initializing redundant LAN backbone connection in

MCHU...................................................................................................... 41 2.20.3 GPRS Redundancy: Deactivating the feature from MCHU while GTP traffic,

data sender makes intra-SGSN update............................................................ 41 2.20.4 GPRS Redundancy: Deactivating the feature from MCHU and PAPU while

GTP traffic, subscriber makes inter BSC location update ..................................... 42 2.20.5 GPRS Redundancy: Deactivating the feature from PAPU and MCHU while

GTP traffic, subscriber makes intra BSC location update ..................................... 44 2.20.6 GPRS Redundancy: Working router goes down, GTP traffic ................................. 45 2.20.7 GPRS Redundancy: Switchover between LAN interfaces within same PAPU

with no GTP traffic ...................................................................................... 45 2.20.8 GPRS Redundancy: Switchover between WO-EX and SP-EX MCHU’s while

GTP traffic is ongoing .................................................................................. 46 2.20.9 GPRS Redundancy: Switchover between LAN interfaces within same MCHU

with traffic ................................................................................................. 47 2.20.10 GPRS Redundancy: Switchover between LAN interfaces within same PAPU

with GTP traffic .......................................................................................... 48 2.20.11 GPRS Redundancy: Switchover between WO-EX and SP-EX PAPU’s while

GTP traffic is ongoing .................................................................................. 49



Pages

5

2.21 Statistics ...................................................................................................49 2.21.1 GPRS mobility management measurements ......................................................49 2.21.2 GPRS session management measurements......................................................50 2.21.3 Data measurements.....................................................................................51 2.21.4 CDR measurements.....................................................................................51 2.22 Overriding MS requested READY timer ............................................................52 2.22.1 Overriding MS requested READY timer ............................................................52 2.23 Operator configurable DSCP..........................................................................53 2.24 Online ciphering mode change .......................................................................55

Introduction



Pages

6

1 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.

SG6 Test Cases



Pages

7

2 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: The purpose of the test case is to verify the procedure of handling such command: display file, copy file, delete file, modify/rename file.

Required test environment: Commissioned SGSN Required environment settings:

1. SGSN Commissioned. 2. Serial MML session to SGSN available.

Guides for execution:

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:

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

OK NOK

Comments:

SG6 Test Cases



Pages

8

2.2 SGSN parameter and data

2.2.1 Display SGSN Configuration Data

Description: The purpose of the test case is to ensure the procedure of displaying SGSN data configuration such as Ready State Time and Detach Time.

Required test environment: Commissioned SGSN Required environment settings:

1. SGSN Commissioned. 2. Serial MML session to SGSN available.

Guides for execution: 1. Check the SGSN parameters (ZEJH) 2. Check the Ready, Standby and Detach state time.

Result:

Expected results: 1. The ready and standby time is set to 44 sec. 2. The detach timer is set to 30 mins.

OK NOK OK NOK

Comments:

2.2.2 Display Subscriber Data

Description: The purpose of the test case is to ensure the procedure of displaying subscriber data in the SGSN which are provided by the HLR

Required test environment: Working GPRS network Required environment settings:

1. Network elements accepted. 2. Site configured according to customer's network plan.

Guides for execution: Check subscriber data in SGSN (ZMMS)

Result:

Expected results: The subscriber data in the SGSN is as provided by the HLR OK NOK

Comments:

2.3 User Profile and Password Management

Description: The purpose of the test case is to verify the procedure of displaying, creating, modifying and deleting User Profile and Password.

Required test environment: Working GPRS network Required environment 1. Network elements accepted.

SG6 Test Cases



Pages

9

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:

Expected results: Display, creation, modification and deletion of user profile possible.

OK NOK

Comments:

2.4 Routing and N7 Administration

2.4.1 Handle N7

Description: The purpose of the test case is to verify the procedure of displaying, creating, modifying and deleting N7 Route, N7 Linkset and N7 Link.



Guides for execution: 1. Display, create, modify delete N7 route (ZNVI), (ZNRC),(ZNRB),(ZNRD) 2. Display, create, modify delete N7 link set (ZNES),(ZNSC),(ZNSN)(ZNSD), 3. Display, create, modify delete N7 link (ZNLI),(ZNCC),(ZNCM),(ZNCD)

Result:

Expected results: Display, Creation, Modification and deletion of N7 Route, link set and link is possible.

OK NOK

Comments:

2.4.2 Handle Global Title

Description:

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).

Required test environment: Working GPRS network Required environment 1. Network elements accepted.

SG6 Test Cases



Pages

10

settings: 2. Site configured according to customer's network plan.

Guides for execution: 1. Display GT results (ZNAI) 2. Create translation result (ZNAC) 3. Modify traslation result (ZNAM) 4. Delete translation result (ZNAD).

Result:

Expected results: Display, creation, modification and deletion of GT are possible. OK NOK

Comments:

2.5 Handle Gb Interface

Description: The purpose of the test case to verify the procedure of displaying, creating, modifying and deleting the data of Gb interface.




1. Display Gb interface frame relay (ZFUI) 2. Display Gb interface NSVC (ZFWO) 3. Create Gb interface frame relay (ZFUC) 4. Create Gb interface NSVC (ZFWC) 5. Modify Gb interface frame relay (ZFUM) 6. Modify Gb interface NSVC (ZFWM) 7. Delete Gb interface frame relay (ZFUD) 8. Change state of Gb interface NSVC (AFWS) 9. Delete Gb interface NSVC (ZFWD)

Result:

Expected results: Display, creation, modification and deletion of Gb interface are possible

OK NOK

Comments:

2.6 Display Active Alarm

Description: The purpose of the test case to ensure the procedure of displaying all active alarms, such as trunk alarm, N7 alarm, charging alarm, etc..




1. Show all the alarms currently ‘ON’. (ZAHO) 2. Show alarm history (ZAHP)

SG6 Test Cases



Pages

11

Result:

Expected results: The alarms currently ‘ON’ and the alarms history can be displayed.

OK NOK

Comments:

2.7 Display All SGSN Timer

Description: The purpose of the test case is to verify the procedure of displaying and modifying all SGSN Timers



Guides for execution: 1. Display all the timers (ZEJH) 2. Modify timers (ZEJF)

Result:

Expected results: All the timers can be displayed and modified OK NOK

Comments:

2.8 Log files Administration

Description: 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.



Guides for execution: 1. Check the log files settings (ZDVI), set it as required 2. Check the logs (ZDVP) 3. Clear sub log files (ZDVF)

Result:

Expected results: Log files can be displayed OK NOK

Comments:

SG6 Test Cases



Pages

12

2.9 O&M

2.9.1 GPRS SP-EX SMMU restart

Description: The purpose of the test case is to verify that SP-EX SMMU is recovered after restart and data transfer is not deactivated.


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:

Expected results:

1. SMMU is recovered (restarted SMMU back in SP-EX state) 2. PDP-context and data transfer are still active 3. No unnecessary alarms, logs or system logs generated to SGSN.

OK NOK OK NOK OK NOK

Comments:

2.9.2 GPRS MCHU switchover

Description: 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.

Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR

Required environment settings:

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:

SG6 Test Cases



Pages

13

Expected results:

1. Switchover is successful (both MCHU's in correct working state) 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.

OK NOK OK NOK OK NOK OK NOK

Comments

2.9.3 GPRS WO-EX SMMU restart

Description: The purpose of the test case is to verify that WO-EX SMMU is recovered after restart and data transfer is not deactivated.

Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR Required environment settings:

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:

Expected results:

1. All units are recovered. 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

Description: The purpose of the test case is to verify that SP-EX OMU is recovered after restart and data transfer is not deactivated.



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.

SG6 Test Cases



Pages

14


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 detach-messages are sent. 8. Check alarms, logs and system logs for SGSN.

Result:

Expected results:

1. OMU is recovered (restarted OMU back in SP-EX state). 2. PDP-context and data transfer are still active 3. No unnecessary alarms, logs or system logs generated to SGSN.


Comments:

2.9.5 GPRS WO-EX OMU restart

Description: The purpose of the test case is to verify that WO-EX OMU is recovered after restart and data transfer is not deactivated.





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 detach-messages are sent. 8. Check alarms, logs and system logs for SGSN.

Result:

Expected results:

1. OMU is recovered (restarted OMU back in WO-EX state). 2. PDP-context and data transfer are still active 3. No unnecessary alarms, logs or system logs generated to SGSN.


Comments:

2.9.6 GPRS SP-EX PAPU restart

SG6 Test Cases



Pages

15

Description: The purpose of the test case is to verify that SP-EX PAPU is recovered after restart and data transfer is not deactivated.





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:

Expected results:

1. PAPU is recovered (restarted PAPU back in SP-EX state) 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.7 GPRS PAPU switchover

Description: 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.



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:

Expected results:

1. Data packets should be sent and received correctly. 2. Switchover is successful (both PAPU's are in correct working state). 3. Both MS's are detched. Data transfer and PDP context is

OK NOK

OK NOK

SG6 Test Cases



Pages

16

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. 6. Charging is working properly, no extra CDRs etc.

OK NOK

OK NOK

OK NOK

OK NOK

Comments:

2.9.8 GPRS WO-EX PAPU restart

Description: 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.




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:

Expected results:

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. 3. No unnecessary alarms, logs or system logs generated to SGSN. 4. Charging is working properly, no extra CDRs etc.


Comments:

2.9.9 GPRS SMMU switchover

Description: 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.


SG6 Test Cases



Pages

17




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 detach-messages are sent. 8. Check alarms, logs and system logs for SGSN.

Result:

Expected results:

1. Switchover is successful (both SMMUs in correct working state) 2. PDP-context and data transfer are still active 3. No unnecessary alarms, logs or system logs generated to SGSN.


Comments:

2.9.10 GPRS SP-EX MCHU restart

Description: The purpose of the test case is to verify that SP-EX MCHU is recovered after restart and data transfer is not deactivated.


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 restart for SP-EX MCHU (ZUSU:MCHU…,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:

Expected results:

1. MCHU is recovered (restarted MCHU back in SP-EX state) 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:

SG6 Test Cases



Pages

18

2.9.11 GPRS WO-EX MCHU restart

Description: The purpose of the test case is to verify that WO-EX MCHU is recovered after restart and data transfer is not deactivated.




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:

Expected results:

1. All units are recovered. 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. 4. Charging is working properly, no extra CDRs etc.


Comments: CDR loss during restart.

2.10 GPRS Attach

PURPOSE: 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.

PREREQUISITES:

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.

TEST EXECUTION: 1. Attach the subscriber.

Result:

EXPECTED RESULTS: 1. Check from SGSN that the status of subscriber is 'attach'. ZMMO:IMSI=xxxxxxxx; detach flag = OFF

OK NOK

Comments:

SG6 Test Cases



Pages

19

2.11 GPRS Detach

PURPOSE: 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.

PREREQUISITES: 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).

TEST EXECUTION: 1. Make GPRS detach for the subscriber. Result:

EXPECTED RESULTS:

1. DETACH is successful. 2. Check from SGSN the status of subscriber and detach time. ZMMO:IMSI=xxxxxxxxxxxxxxx;

OK NOK OK NOK

Comments:

2.12 PDP Context

PURPOSE: This case is to prove GGSN-DHCP communication functionality and PDP-context activation

PREREQUISITES:

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".

TEST EXECUTION: 1. Create PDP context. Result:

EXPECTED RESULTS:

1. PDP context activation is successful. 2. DHCP server reserves the address for the MS. 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


Comments:

SG6 Test Cases



Pages

20

2.13 PDP Context Deactivation

PURPOSE: This case is to prove GGSN-DHCP communication functionality and PDP-context deactivation PREREQUISITES: 1. Active PDP-context according to the test case: "Dynamic IP-address allocation, allocated by DHCP". TEST EXECUTION: 1. Deactivate PDP-context. Result:

EXPECTED RESULTS:

1. PDP-context deactivation is successful. 2. After deactivation, IP-address is released.. 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


Comments:

2.14 Cell Changes, RA & LA Updates (Mobility Management)

2.14.1 Intra SGSN RA update

Description: The purpose of the test case is to check that intra SGSN RA update is successful during DL data transfer with both network modes.

Required test environment: GGSN, SGSN, LIG, BSC, BTS, CG, MSC/VLR, HLR Required environment settings:

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 NOK OK NOK

SG6 Test Cases



Pages

21

3. Intra SGSN RA update works with. OK NOK

Unexpected results: 1. File transfer doesn't work 2. Intra SGSN RA update doesn't work

Comments:

2.14.2 Inter SGSN RA update during data transfer

Description: The purpose of the test case is to check that inter SGSN RA update is successful during DL data transfer with both network modes.

Required test environment: GGSN, SGSN, LIG, BSC, BTS, CG, MSC/VLR, HLR Required environment settings:

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:

Expected results:

1. Attach and PDP context activation works

2. Files are transferred OK with both NW types. 3. Inter SGSN RA update works with both NW modes.


Unexpected results: 1. File transfer doesn't work 2. Inter SGSN RA update doesn't work

Comments:

2.14.3 Cell change, same RA, MS in STANDBY state

PURPOSE: 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 network-monitoring functionality from the MS.

PREREQUISITES: 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS available in the same RA.

TEST EXECUTION:

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.

SG6 Test Cases



Pages

22

Result:

EXPECTED RESULTS:

1. Attach is successful. 2. MS state is STANDBY 3. Cell change works. 4. MS is still in STANDBY state.

OK NOK

OK NOK

OK NOK

OK NOK

Comments:

2.14.4 Cell change, same RA, MS in READY state

PURPOSE: 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.

PREREQUISITES: 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS available in the same RA.

TEST EXECUTION:

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:

EXPECTED RESULTS:

1. Attach is successful. 2. MS state is READY 3. Cell change works. 4. MS is still in READY state.

OK NOK

OK NOK

OK NOK

OK NOK

Comments:

2.14.5 Cell change, different RA, MS in STANDBY state

PURPOSE: 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

PREREQUISITES: 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS available in different RA.

TEST EXECUTION:

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

SG6 Test Cases



Pages

23

Result:

EXPECTED RESULTS:

1. Attach is successful. 2. MS state is STANDBY 3. Cell change works. 4. MS is still in STANDBY->READY->STANDBY state.

OK NOK

OK NOK

OK NOK

OK NOK

Comments:

2.14.6 Cell change, different RA, MS in READY state

PURPOSE: 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.

PREREQUISITES: 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. More than one BTS available in different RA.

TEST EXECUTION:

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:

EXPECTED RESULTS:

1. Attach is successful. 2. MS state is READY 3. Cell change works. 4. MS is still in READY state.

OK NOK

OK NOK

OK NOK

OK NOK

Comments:

SG6 Test Cases



Pages

24

2.15 Periodic RA Updates

2.15.1 Periodic RA update, PTMSI not allocated

PURPOSE: 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.

PREREQUISITES:

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

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 NOK OK NOK

Comments:

SG6 Test Cases



Pages

25

2.16 Packet Routing And Data Transfer

2.16.1 UL packet transfer

PURPOSE: To verify that the data packets are correctly sent and received during UL packet transfer.

PREREQUISITES: 1. Network elements accepted. 2. Site configured according to customer's network plan. 3. MS with laptop PC and Dial-Up software.

TEST EXECUTION: 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 NOK OK NOK

Comments:

2.16.2 UL packet transfer, cell change during data flow

PURPOSE: 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.

PREREQUISITES: 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.

TEST EXECUTION:

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:

EXPECTED RESULTS: 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

OK NOK

Comments:

SG6 Test Cases



Pages

26

2.16.3 DL packet transfer, cell change during data flow

.

PURPOSE: 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.

PREREQUISITES: 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.

TEST EXECUTION:

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:

EXPECTED RESULTS: 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 OK NOK

Comments:

2.16.4 UL packet transfer, cell change, RA change during data flow

PURPOSE: 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.

PREREQUISITES: 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.

TEST EXECUTION:

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:

EXPECTED RESULTS: 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 OK NOK

Comments:

SG6 Test Cases



Pages

27

2.16.5 DL packet transfer, cell change, RA change during data flow

PURPOSE: 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.

PREREQUISITES: 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.

TEST EXECUTION:

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:

EXPECTED RESULTS: 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 OK NOK

Comments:

2.16.6 Simultaneous UL/DL packet transfer

PURPOSE: To verify that the simultaneous up- and downlink packet transfer works.

PREREQUISITES: 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.

TEST EXECUTION:

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 NOK OK NOK

Comments:

SG6 Test Cases



Pages

28

2.17 PAGING

2.17.1 GPRS paging, MS in STANDBY mode, Network mode I

Description: To verify that packet switched paging function works via GPRS network. Network mode I.

Prerequisites:

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:

Expected results:

4. Paging is successful.

Mobile replies to ping. 5. No unclear alarms/logs are generated on SGSN


SG6 Test Cases



Pages

29

2.18 Ciphering

2.18.1 UL/DL Packet Transfer, Ciphering on

PURPOSE: To verify that the Up- and Downlink packet transfer works with ciphering.

PREREQUISITES: 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.

TEST EXECUTION:

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:

EXPECTED RESULTS: 1. Ciphering works. 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)

Description: The purpose of the test case is to check that all CDR types are created by SGSN. Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG Required environment settings:

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.)

SG6 Test Cases



Pages

30

Result:

Expected results: 1. SGSN produces M- and S-CDRs normally and they include correct information. OK NOK

Unexpected results: 1. SGSN doesn't send any CDRs to CG or CDRs don't include correct information.

Comments:

2.19.2 Intermediate charging

Description: The purpose of the test case is to verify that intermediate charging works on SGSN. Required test environment: 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:

Expected results: 1. Intermediate charging works. OK NOK

Unexpected results: 1. SGSN doesn't send any intermediate charging CDR.

Comments:

SG6 Test Cases



Pages

31

2.19.3 Tariff change during daytime

Description: 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.

Required test environment: 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:

Expected results:

1. CDRs should be generated during file transfer correctly. 2. Data packets should be sent and received correctly. 3. No unnecessary alarms, logs or system logs generated to SGSN

OK NOK

OK NOK

OK NOK

Unexpected results: 1. SGSN doesn't send any CDRs to CG or CDRs don't include correct information.

Comments:

2.19.4 S-CDRs in case of PAPU switchover

Description: The purpose of the test case is to check S-CDR producing in case of PAPU switchover. Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG



SG6 Test Cases



Pages

32


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:

Expected results:

1. CDRs should be generated during file transfer correctly. 2. Data packets should be sent and received correctly. 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

OK NOK

OK NOK

OK NOK

OK NOK

Unexpected results: SGSN doesn't send any CDRs to CG or CDRs don't include correct information.

Comments:

2.19.5 GPRS Duplicated CDR prevention, CG wakes up after a while

Description: This case tests if the duplicated CDR prevention works properly when SGSN - CG connection breaks before a successful CDR reception.

Required test environment: 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

Guides for execution: 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:

Expected results:

1. SGSN sends CDR(s) in a packet to CG1.

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.

N/A

N/A

N/A

SG6 Test Cases



Pages

33

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

N/A

N/A

N/A

N/A

N/A

Comments: Cannot test this case because this will effect with live Network.

2.19.6 GPRS Duplicate CDR prevention, CG does not wake up.

Description: This case tests if the duplicated CDR prevention works properly when SGSN - CG connection breaks before a successful CDR reception.

Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, 2 x CG Rel2.

Required environment settings: 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.

Guides for execution: 1. Make CG1 inactive (e.g. shut it down). 2. Make some attaches and PDP context activation and make some data transfer.

Result:

Expected results:

1. SGSN sends CDR(s) in a packet to CG1.

2. No response from CG1 3. The same package is sent to CG2. 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

N/A

N/A

N/A

SG6 Test Cases



Pages

34


2.19.7 GPRS CDR collection from multiple GSNs

Description: 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).



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.

Guides for execution: 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:

Expected results:

1. Methods start without any error notifications and stay up

2. Verify from cg/arm/output that there is CDRs from different GSNs. 3. The CG methods and collection of CDRs will stop.

OK NOK

OK NOK

N/A

Comments:

2.19.8 GPRS CDR, Minimum/maximum threshold check, CDR is sent when time limit is exceeded.

Description: Minimum/Maximum threshold check. Check that CDR is not sent before a certain threshold is exceeded.




Guides for execution: 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.

SG6 Test Cases



Pages

35

Result:

Expected results: 1. Data should not be sent before the Maximum S-CDR duration is exceeded (minimum data volume threshold is not exceeded). OK NOK

Comments:

2.19.9 GPRS Minimum/maximum threshold check, CDR is not sent before minimum volume threshold is exceeded

Description: Minimum/Maximum threshold check. Check that CDR is not sent before the minimum volume threshold is exceeded.




Guides for execution: 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:

Expected results: 1. Data should not be sent before the minimum data transfer value is exceeded. OK NOK

Comments:

2.19.10 GPRS Redundancy test

Description:

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.


Required environment settings: 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:

SG6 Test Cases



Pages

36

Expected results:

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. 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.

N/A

N/A

N/A

N/A


2.19.11 GPRS S-CDR includes MSISDN (also G-CDR) and Cell-ID

Description: To check that S-CDR are stored with the right information. Cell-ID and MS-ISDN. G-CDR should also include MSISDN.



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 NOK OK NOK

Comments:

2.19.12 GPRS CDR creation, tariff change during data transfer.

Description: To verify that tariff class change works simultaneously with data transfer and check what is effect to generation of CDRs.


SG6 Test Cases



Pages

37




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:

Expected results:

1. CDRs should be generated during file transfer correctly 2. Data packets should be sent and received correctly. 3. No unnecessary alarms, logs or system logs generated to SGSN

OK NOK

OK NOK

OK NOK

Comments:

2.19.13 GPRS Intermediate CDRs

Description: This test case verifies that intermediate CDRs are generated. Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG



Guides for execution: 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:

Expected results: 1. Intermediate CDR is generated OK NOK

Comments:

2.19.14 GPRS CDR collected manually

Description: This test case verifies that CDRs can be generated manually.

SG6 Test Cases



Pages

38




Guides for execution: 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:

Expected results: 1. CDR is generated OK NOK

Comments:

2.19.15 GPRS Charging, S-CDR closing according to data volume

Description: To check that S-CDR is closed after data limit is exceeded. Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG




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:

Expected results: 1. S-CDR is closed after data limit is exceeded and a new one is opened. OK NOK

Comments:

SG6 Test Cases



Pages

39

2.19.16 GPRS Charging, closing S-CDR when time limit is exceeded

Description: To check that S-CDR is closed after time limit is exceeded. Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG




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

Description: To check that closing of M-CDR works OK. Required test environment: SGSN, GGSN, BTS, BSC, MSC/VLR, HLR, CG




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

SG6 Test Cases



Pages

40

Comments:

2.20 Redundancy

2.20.1 GPRS Redundancy: Initializing redundant LAN backbone connection in SMMU

Description: The purpose of the test case is to verify that initializing the redundant LAN interface for SMMU succeeds with packet data traffic and SMSs.

Required test environment: 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. PAPU’s 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:

Expected results:

1. Initializing the new LAN interface should not disturb existing data connections and SMS sending/receiving. 2. Initialization succeeds. 3. No unexpected CPU logs writing or alarms concerned to initializing.

OK NOK

OK NOK

OK NOK

Unexpected results: 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.

Comments: No available IP addresses for SMMU

SG6 Test Cases



Pages

41

2.20.2 GPRS Redundancy: Initializing redundant LAN backbone connection in MCHU

Description: The purpose of the test case is to verify that initializing the redundant LAN interface for MCHU succeeds with packet data traffic and SMSs.

Required test environment: 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. MCHU’s 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. PAPU’s 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:

Expected results:

1. Initializing the new LAN interface should not disturb existing data connections and SMS sending/receiving. 2. Initialization succeeds. 3. No unexpected CPU logs writing or alarms concerned to initializing.

OK NOK

OK NOK

OK NOK

Unexpected results: 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.

Comments:

2.20.3 GPRS Redundancy: Deactivating the feature from MCHU while GTP traffic, data sender makes intra-SGSN update

SG6 Test Cases



Pages

42

Description:

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. 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.

Required test environment: 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. MCHU’s 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:

Expected results:

1. Deactivating the redundant MCHU LAN interface should not disturb existing data connections. 2. Deactivation succeeds. 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 compared to the original.

OK NOK

OK NOK OK NOK

OK NOK OK NOK

Unexpected results: 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.

Comments:

2.20.4 GPRS Redundancy: Deactivating the feature from MCHU and PAPU while GTP traffic, subscriber makes inter BSC location update

SG6 Test Cases



Pages

43

Description:

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.

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. 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. MCHU’s and PAPU’s 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:

Expected results:

1. Deactivating the redundant MCHU and PAPU LAN interfaces should not disturb existing data connections. 2. Deactivation succeeds.. 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 compared to the original.

OK NOK

OK NOK

OK NOK

OK NOK OK NOK

Unexpected results:

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:

SG6 Test Cases



Pages

44

2.20.5 GPRS Redundancy: Deactivating the feature from PAPU and MCHU while GTP traffic, subscriber makes intra BSC location update

Description:

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.

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. 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. MCHU’s and PAPU’s 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:

Expected results:

1. Deactivating the redundant MCHU and PAPU LAN interfaces should not disturb existing data connections. 2. Deactivation succeeds. 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 compared to the original.

OK NOK


Unexpected results: 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:

SG6 Test Cases



Pages

45

2.20.6 GPRS Redundancy: Working router goes down, GTP traffic

Description: 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. 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. MCHU’s and PAPU’s 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

Guides for execution: 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:

Expected results:

1. Powering off the working router doesn't have effect ongoing GTP traffic. 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. 4. Data packet content remains the same after sending compared to the original.

OK NOK


Unexpected results: 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.

Comments:

2.20.7 GPRS Redundancy: Switchover between LAN interfaces within same PAPU with no GTP traffic

Description: 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.

Required test environment: 1. SGSN, GGSN, BTS, BSC, MSC/VLR, HLR

SG6 Test Cases



Pages

46


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:

Expected results:

1. Switchover between master and backup LAN connections between PAPU and switches should succeed. 2. No unexpected alarms or CPU log writings.

OK NOK OK NOK

Unexpected results: 1. Switchover between master and backup LAN connections between PAPU and switches doesn't succeed. 2. Unexpected alarms or CPU log writings.

Comments:

2.20.8 GPRS Redundancy: Switchover between WO-EX and SP-EX MCHU’s while GTP traffic is ongoing

Description: 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.

Required test environment: 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 MCHU’s 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

SG6 Test Cases



Pages

47

2. No unexpected alarms or CPU log writings. 3. Charging should not been lost.

OK NOK OK NOK

Unexpected results: 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

Comments:

2.20.9 GPRS Redundancy: Switchover between LAN interfaces within same MCHU with traffic

Description: 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. 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:

Expected results:

1. Switchover between master and backup LAN connections between MCHU and switches should succeed.. 2. No unexpected alarms or CPU log writings. 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

OK NOK

OK NOK

OK NOK

Unexpected results: 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

SG6 Test Cases



Pages

48

Comments:

2.20.10 GPRS Redundancy: Switchover between LAN interfaces within same PAPU with GTP traffic

Description: 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. 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:

Expected results:

1. Switchover between master and backup LAN connections between PAPU and switches should succeed.. 2. No unexpected alarms or CPU log writings. 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

OK NOK OK NOK

OK NOK

Unexpected results: 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

Comments:

SG6 Test Cases



Pages

49

2.20.11 GPRS Redundancy: Switchover between WO-EX and SP-EX PAPU’s while GTP traffic is ongoing

Description: 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. 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:

Expected results: 1. Master and backup LAN connections stays the same unless PAPU units makes switchover. 2. No unexpected alarms or CPU log writings.

OK NOK

OK NOK

Unexpected results: 1. Master and backup LAN connections make also switchover when PAPU units make switchover. 2. Unexpected alarms or CPU log writings

Comments:

2.21 Statistics

2.21.1 GPRS mobility management measurements

Description: 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. 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.

SG6 Test Cases



Pages

50


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:

Expected results: 1. Attach and PDP context activation works. 2. Mobility management statistics are correct.

OK NOK

OK NOK

Unexpected results: 1. Mobility management statistics are not correct 2. Alarm 3003 INCORRECT MEASUREMENT DATA is active

Comments:

2.21.2 GPRS session management measurements

Description: 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. 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:

Expected results: 1. Attach and PDP context activation works. 2. Session management statistics are correct

OK NOK

OK NOK

Unexpected results: 1. Session management statistics are not correct 2. Alarm 3003 INCORRECT MEASUREMENT DATA is active

SG6 Test Cases



Pages

51

Comments:

2.21.3 Data measurements

Description: 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. 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:

Expected results: 1. Attach and PDP context activation works. 2. Data measurement statistics are correct

OK NOK

OK NOK

Unexpected results: 1. Data measurement statistics are not correct 2. Alarm 3003 INCORRECT MEASUREMENT DATA is active

Comments:

2.21.4 CDR measurements

Description: 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.




SG6 Test Cases



Pages

52


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:

Expected results: 1. Attach and PDP context activation works. 2. CDR measurement statistics are correct.

OK NOK

OK NOK

Unexpected results: 1. CDR measurement statistics are not correct. 2. Alarm 3003 INCORRECT MEASUREMENT DATA is active

Comments:

2.22 Overriding MS requested READY timer

2.22.1 Overriding MS requested READY timer

Description:

The value of the READY timer is to be negotiated between the MS and the network using the GPRS Attach RAU procedure.

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.

Required test environment: SGSN, GGSN, MCS HLR, BSS Required environment settings:

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

SG6 Test Cases



Pages

53

2. Signalling sequence shall be as follows.

attach request----------------------------> SGSN

ready_timer_value = (20s)

attach accept <--------------------------------- SGSN

OK NOK

Unexpected results:

Check that no unspecified alarms, unit logs or system logs generated to SGSN

Comments:

2.23 Operator configurable DSCP

Description: 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).

Required test environment: SGSN, GGSN, MSC/HLR, BSS Required environment settings: Subscriber is attached in SGSN (detach flag=OFF, MML-command ZMMO:IMSI=23422..;).

SG6 Test Cases



Pages

54


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 000000

AF Class 1, Low Drop Precedence 001010

AF Class 1, Medium Drop Precedence 001100

AF Class 1, High Drop Precedence 001110










Expedited Forwarding 101110

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:

Expected results:

1. Command succeeds

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

OK NOK

OK NOK

SG6 Test Cases



Pages

55

interface has DSCP value Expedited Forwarding (using e.g. Ethereal).

Unexpected results:

Comments: No Gb over IP has been implemented during acceptance test.

2.24 Online ciphering mode change

Description: This test case verifies online ciphering mode modifications during attach and RAU procedures. Required test environment: SGSN, GGSN, MSC/HLR, BSS Required environment settings: 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)


11. Perform INTRA PAPU RAU


13. Deactivate PDP context

13.Perform detach to MS

14. Check active alarms and clear unit logs

Result:

Expected results:

1. Check that ciphering is used on attach & RAU cases when ciphering is activated. 2. No unclear alarms, unit logs or system logs generated to SGSN

OK NOK

OK NOK

Unexpected results:

SG6 Test Cases



Pages

56

Comments:

Documents

SGSN 6.0 Acceptance Test Procedure