Sunteți pe pagina 1din 56

SG6 Verification Test Cases

SG6 Verification Test Cases

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

1

The information in this document is subject to change wi thout notice and describes only
The information in this document is subject to change wi thout notice and describes only
The information in this document is subject to change wi thout notice and describes only

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia Networks' customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia Networks. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia Networks and the customer. However, Nokia Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Networks will, if necessary, explain issues which may not be covered by the document.

Nokia Networks' liability for any errors in the document is limited to the documentary correction of errors. Nokia Networks WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright according to the applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only.

Copyright © Nokia Oyj 2008. All rights reserved.

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

2

CONTENTS 1 Introduction 6 2 SG6 Test Cases 7 2.1 SGSN system administration 7 2.1.1
CONTENTS 1 Introduction 6 2 SG6 Test Cases 7 2.1 SGSN system administration 7 2.1.1
CONTENTS 1 Introduction 6 2 SG6 Test Cases 7 2.1 SGSN system administration 7 2.1.1

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

Document Number

© 2008 Nokia Networks Oy

Pages

GPR33801.doc/0.1

3

2.16.5 DL packet transfer, cell change , RA change during data flow 27 2.16.6 Simultaneous
2.16.5 DL packet transfer, cell change , RA change during data flow 27 2.16.6 Simultaneous
2.16.5 DL packet transfer, cell change , RA change during data flow 27 2.16.6 Simultaneous

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

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

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

Document Number

© 2008 Nokia Networks Oy

Pages

GPR33801.doc/0.1

4

2.21 Statistics 49 2.21.1 GPRS mobility management measurements 49 2.21.2 GPRS session management
2.21 Statistics 49 2.21.1 GPRS mobility management measurements 49 2.21.2 GPRS session management
2.21 Statistics 49 2.21.1 GPRS mobility management measurements 49 2.21.2 GPRS session management

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

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

5

Introduction
Introduction
Introduction

Introduction

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.

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

6

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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.

 

1. Display all the software package( ZWQO;).

2. Display all the created software (ZWQO:CR;)

3. Display a particular file in MO disk (ZIWX).

Guides for execution:

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:

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

7

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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:

 

1. The ready and standby time is set to 44 sec.

OK

 

NOK

Expected results:

 

2. The detach timer is set to 30 mins.

OK

 

NOK

Comments:

 

2.2.2 Display Subscriber Data

Description:

Required test environment:

Required environment settings:

Guides for execution:

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

Working GPRS network

1. Network elements accepted.

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

Check subscriber data in SGSN (ZMMS)

Result:

Expected results:

Comments:

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

OK

NOK

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.

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

8

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

settings:

2.

Site configured according to customer's network plan.

 
 

1.

Create user profile (ZIAA)

2.

Create user ID (ZIAH)

3.

Change password (ZIAG)

Guides for execution:

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.

Required test environment:

Working GPRS network

Required environment settings:

1. Network elements accepted.

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

 

1. Display, create, modify delete N7 route (ZNVI), (ZNRC),(ZNRB),(ZNRD)

 

2. Display, create, modify delete N7 link set (ZNES),(ZNSC),(ZNSN)(ZNSD),

Guides for execution:

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.

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

9

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

settings:

2.

Site configured according to customer's network plan.

 

1. Display GT results (ZNAI)

 

Guides for execution:

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.

Required test environment:

Working GPRS network

Required environment settings:

1. Network elements accepted.

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

 

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)

Guides for execution:

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

Required test environment:

Working GPRS network

Required environment settings:

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

 

1. Show all the alarms currently ‘ON’. (ZAHO)

Guides for execution:

2. Show alarm history (ZAHP)

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

10

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

Result:

Expected results:

Comments:

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

OK

NOK

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

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:

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.

Required test environment:

Working GPRS network

Required environment settings:

1. Network elements accepted.

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

 

1. Check the log files settings (ZDVI), set it as required

2. Check the logs (ZDVP)

Guides for execution:

3. Clear sub log files (ZDVF)

   

Result:

 

Expected results:

Log files can be displayed

OK

 

NOK

   
 

Comments:

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

11

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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.

 

Required test environment:

Working GPRS network

Required environment settings:

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.

Guides for execution:

5. Start sending UL data packets from the MS to the server.

6. Make restart for SP-EX SMMU (ZUSU:SMMU…,C=DSK;)

Monitor Gb-interface and check that no deactivate PDP context message or detach-messages are sent.

7.

8. Check alarms, logs and system logs for SGSN.

   

Result:

 

1. SMMU is recovered (restarted SMMU back in SP-EX state)

OK

 

NOK

   

Expected results:

2. PDP-context and data transfer are still active

Expected results: 2. PDP-context and data transfer are still active
Expected results: 2. PDP-context and data transfer are still active

3. No unnecessary alarms, logs or system logs generated to

OK

NOK

SGSN.

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.

Guides for execution:

5. Start sending UL data packets from the MS to the server.

6. Make controlled switchover for MCHU

Monitor Gb-interface and check that no deactivate PDP context message or detach-messages are sent.

7.

8.

Check alarms, logs and system logs for SGSN.

 

Result:

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

12

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

 

1.

Switchover is successful (both MCHU's in correct working

OK

 

NOK

 

state)

   
 

Expected results:

2. PDP-context and data transfer are still active

OK

NOKExpected results: 2. PDP-context and data transfer are still active OK

Expected results: 2. PDP-context and data transfer are still active OK NOK

3. No unnecessary alarms, logs or system logs generated to

NOK3. No unnecessary alarms, logs or system logs generated to

3. No unnecessary alarms, logs or system logs generated to NOK
   

SGSN.

OK

4.

Charging is working properly, no extra CDRs etc.

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.

Guides for execution:

5. Start sending UL data packets from the MS to the server.

6. Make restart for WO-EX SMMU (ZUSU:SMMU…,C=DSK;)

Attach subscriber, reactivate PDP context and data transfer after SGSN is back up and running.

7.

 

8.

Check alarms, logs and system logs for SGSN.

   

Result:

 

1. All units are recovered.

OK

 

NOK

 

Expected results:

2. Attaching subscriber, PDP-context and data transfer is successful immediately after system is recovered.

OK

NOKresults: 2. Attaching subscriber, PDP-context and data transfer is successful immediately after system is recovered. OK

2. Attaching subscriber, PDP-context and data transfer is successful immediately after system is recovered. OK NOK

3.

No unnecessary alarms, logs or system logs generated to

NOK3. No unnecessary alarms, logs or system logs generated to

3. No unnecessary alarms, logs or system logs generated to NOK

SGSN.

OK

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.

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. One MS, One PC laptop with dial up.

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

13

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

 

1. Empty alarms and logs for SGSN.

2. Attach the subscriber.

3. Activate PDP context from MS (dial *99***128#).

4. Create FTP connection to FTP-server.

Guides for execution:

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:

 

1. OMU is recovered (restarted OMU back in SP-EX state).

OK

 

NOK

 

Expected results:

2. PDP-context and data transfer are still active

 

3. No unnecessary alarms, logs or system logs generated to

OK

3. No unnecessary alarms, logs or system logs generated to OK NOK

NOK

3. No unnecessary alarms, logs or system logs generated to OK NOK
 

SGSN.

OK

 

NOK

 

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.

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

Guides for execution:

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:

 

1. OMU is recovered (restarted OMU back in WO-EX state).

OK

 

NOK

   

Expected results:

2. PDP-context and data transfer are still active

 

3. No unnecessary alarms, logs or system logs generated to

OK

3. No unnecessary alarms, logs or system logs generated to OK NOK

NOK

3. No unnecessary alarms, logs or system logs generated to OK NOK
 

SGSN.

OK

 

NOK

   

Comments:

 

2.9.6 GPRS SP-EX PAPU restart

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

14

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

Description:

The purpose of the test case is to verify that SP-EX PAPU 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. 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.

Guides for execution:

5. Start sending UL data packets from the MS to the server.

6. Make restart for SP-EX (ZUSU:PAPU… ,C=DSK)

7. Monitor Gb-interface and check that no deactivate PDP context message or detach-messages are

sent.

8. Check alarms, logs and system logs for SGSN.

   

Result:

 
 

1. PAPU is recovered (restarted PAPU back in SP-EX state)

OK

 

NOK

   

2. PDP-context and data transfer are still active

OK

NOK2. PDP-context and data transfer are still active OK

2. PDP-context and data transfer are still active OK NOK

Expected results:

3. No unnecessary alarms, logs or system logs generated to SGSN.

 

4. Charging is working properly, no extra CDRs etc.

OK

NOK4. Charging is working pr operly, no extra CDRs etc. OK

4. Charging is working pr operly, no extra CDRs etc. OK NOK

OK

 

NOK

   

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.

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

Guides for execution:

7. Make controlled switchover for PAPU.

8. Monitor Gb-interface and check that no deactivate PDP context message or detach-messages are

sent.

9.

Check alarms, logs and system logs for SGSN.

10. Activate PDP context again for the subscriber.

 

11. Create FTP connection to FTP-server.

12. Start sending UL data packets from the MS to the server

   

Result:

 
 

1. Data packets should be sent and received correctly.

OK

 

NOK

   

Expected results:

2. Switchover is successful (both PAPU's are in correct working

 
 

state).

OK

  state). OK NOK

NOK

  state). OK NOK

3.

Both MS's are detched. Data transfer and PDP context is

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

15

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

 

allowed to deactivate.

 

4.

No unnecessary alarms, logs or system logs generated to

OK

NOK4. No unnecessary alarms, logs or system logs generated to OK

4. No unnecessary alarms, logs or system logs generated to OK NOK

SGSN.

 

5.

Reattach & Reactivation of PDP context and data transfer are

OK

NOK5. Reattach & Reactivation of PDP context and data transfer are OK

5. Reattach & Reactivation of PDP context and data transfer are OK NOK

successful.

 

OK

NOKOK

OK NOK

6.

Charging is working properly, no extra CDRs etc.

OK

NOK6. Charging is working pr operly, no extra CDRs etc. OK

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

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.

Guides for execution:

5. Start sending UL data packets from the MS to the server.

6. Make restart for WO-EX PAPU where is active bearer channel configured

 

(ZUSU:PAPU…,C=DSK;).

 

7. Attach subscriber, reactivate PDP context and data transfer after unit recovered.

 

8. Check alarms, logs and system logs for SGSN.

 
   

Result:

 

1. PAPU is recovered (restarted PAPU back in WO-EX state)

OK

 

NOK

 

2. Attaching subscriber, PDP-context and data transfer is

NOK2. Attaching subscriber, PDP-context and data transfer is

2. Attaching subscriber, PDP-context and data transfer is NOK

Expected results:

successful immediately after PAPU is recovered.

OK

3.

No unnecessary alarms, logs or system logs generated to

 

SGSN.

OK

NOKSGSN. OK

SGSN. OK NOK

4.

Charging is working properly, no extra CDRs etc.

 
 

OK

 

NOK

 

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.

Required test environment:

SGSN, GGSN, BTS, BSC, MSC/VLR, HLR

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

16

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

Required environment settings:

1. Network elements accepted.

   

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

3. Analyzer (Nethawk)

 

4. One MS, One PC laptop with dial up.

 

1. Empty alarms and logs for SGSN.

2. Attach the subscriber.

3. Activate PDP context from MS (dial *99***128#).

4. Create FTP connection to FTP-server.

Guides for execution:

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:

 

1. Switchover is successful (both SMMUs in correct working

state)

OK

 

NOK

 
 

Expected results:

2. PDP-context and data transfer are still active

OK

NOKExpected results: 2. PDP-context and data transfer are still active OK

Expected results: 2. PDP-context and data transfer are still active OK NOK

3. No unnecessary alarms, logs or system logs generated to

NOK3. No unnecessary alarms, logs or system logs generated to

3. No unnecessary alarms, logs or system logs generated to NOK

SGSN.

OK

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

SGSN, GGSN, BTS, BSC, MSC/VLR, HLR

 
 

1. Network elements accepted.

 

Required environment settings:

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.

Guides for execution:

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:

 

1. MCHU is recovered (restarted MCHU back in SP-EX state)

OK

 

NOK

 

2. PDP-context and data transfer are still active

OK

NOK2. PDP-context and data transfer are still active OK

2. PDP-context and data transfer are still active OK NOK

Expected results:

3. No unnecessary alarms, logs or system logs generated to

 
 

SGSN.

OK

NOK  SGSN. OK

  SGSN. OK NOK

4.

Charging is working properly, no extra CDRs etc.

 
 

OK

 

NOK

 

Comments:

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

17

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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.

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.

Guides for execution:

5. Start sending UL data packets from the MS to the server.

6. Make restart for WO-EX MCHU (ZUSU:MCHU…,C=DSK;)

NOTE! : CAUSES SYSTEM RESET

7. Attach subscriber, reactivate PDP context and data transfer after SGSN is back up and running.

8. Check alarms, logs and system logs for SGSN.

 
   

Result:

 
 

1. All units are recovered.

OK

 

NOK

   

2. Attaching subscriber, PDP-context and data transfer is

NOK2. Attaching subscriber, PDP-context and data transfer is

2. Attaching subscriber, PDP-context and data transfer is NOK

Expected results:

successful immediately after system is recovered.

OK

3.

No unnecessary alarms, logs or system logs generated to

 

SGSN.

OK

NOKSGSN. OK

SGSN. OK NOK

4.

Charging is working properly, no extra CDRs etc.

 
 

OK

 

NOK

   

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.

 

1. Network elements accepted.

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

 

PREREQUISITES:

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:

 

1. Check from SGSN that the status of subscriber is 'attach'.

   

EXPECTED RESULTS:

ZMMO:IMSI=xxxxxxxx;

detach flag = OFF

OK

EXPECTED RESULTS: ZMMO:IMSI=xxxxxxxx; detach flag = OFF OK NOK

NOK

EXPECTED RESULTS: ZMMO:IMSI=xxxxxxxx; detach flag = OFF OK NOK

Comments:

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

18

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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.

 

1. Network elements accepted.

PREREQUISITES:

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:

 

1. DETACH is successful.

OK

 

NOK

 

EXPECTED RESULTS:

2. Check from SGSN the status of subscriber and detach time.

 

ZMMO:IMSI=xxxxxxxxxxxxxxx;

OK

ZMMO:IMSI=xxxxxxxxxxxxxxx; OK NOK

NOK

ZMMO:IMSI=xxxxxxxxxxxxxxx; OK NOK

Comments:

 

2.12 PDP Context

PURPOSE:

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

 

1. DHCP server available.

2. Configure the IP-parameters for the DHCP-server according to the network plan.

 

3. Configure the Access Point to use the configured DHCP-server for dynamic IP-address

PREREQUISITES:

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:

 

1. PDP context activation is successful.

OK

 

NOK

   

2. DHCP server reserves the address for the MS.

OK

NOK2. DHCP server reserves the address for the MS. OK

2. DHCP server reserves the address for the MS. OK NOK

EXPECTED RESULTS:

3. PDP Context is created into APN in question:

 

GGSN UI:

   

Config -> Configuration per an Access Point -> Statistics per an Access Point -> Select the Access Point -> PDP Statistics: Active PDP Contexts: 1

OK

NOK-> Statistics per an Access Point -> Select the Access Point -> PDP Statistics: Acti ve

Statistics per an Access Point -> Select the Access Point -> PDP Statistics: Acti ve PDP

Comments:

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

19

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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:

 
 

1. PDP-context deactivation is successful.

OK

 

NOK

   

2. After deactivation, IP-address is released

OK

NOK2. After deactivation, IP-address is released OK

2. After deactivation, IP-address is released OK NOK

EXPECTED RESULTS:

3. PDP context is cleared from the GGSN

 

GGSN UI:

   

Config -> Configuration per an Access Point -> Statistics per an Access Point -> Select the Access Point -> PDP Statistics: Active PDP Contexts: 0

OK

NOK-> Statistics per an Access Point -> Select the Access Point -> PD P Statistics: Active

Statistics per an Access Point -> Select the Access Point -> PD P Statistics: Active PDP

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.

Guides for execution:

3. Create FTP connection to FTP server and transfer data files DL browsing.

direction or do web

4. Change RA during DL data transfer.

5. Deactivate PDP context.

   

Result:

 

1. Attach and PDP context activation works

OK

 

NOK

 

Expected results:

2. Files are transferred OK.

OK

Expected results: 2. Files are transferred OK. OK NOK

NOK

Expected results: 2. Files are transferred OK. OK NOK

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

20

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

 

3. Intra SGSN RA update works with.

OK

NOK

 

1. File transfer doesn't work

Unexpected results:

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.

Guides for execution:

3. Create FTP connection to FTP server and transfer data files DL browsing.

direction or do web

 

4. Change RA1 to RA2 during DL data transfer.

5. Deactivate PDP context.

   

Result:

 

1. Attach and PDP context activation works

OK

 

NOK

   

Expected results:

2. Files are transferred OK with both NW types.

OK

Expected results: 2. Files are transferred OK with both NW types. OK NOK

NOK

Expected results: 2. Files are transferred OK with both NW types. OK NOK

3. Inter SGSN RA update works with both NW modes.

OK

 

NOK

 
 

1. File transfer doesn't work

Unexpected results:

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.

 

1. Network elements accepted.

PREREQUISITES:

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

3. More than one BTS available in the same RA.

 

1. Check the READY STATE timer value from the SGSN (ZEJH; command).

2. Attach the subscriber.

3. Wait till READY STATE timer has been expired and MS is in STANDBY state.

TEST EXECUTION:

4. Change cell under the same RA.

5. Check cell change from the MS.

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

21

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

   

Result:

 

1. Attach is successful.

OK

NOK  1. Attach is successful. OK

  1. Attach is successful. OK NOK

2. MS state is STANDBY

OK

NOK2. MS state is STANDBY OK

2. MS state is STANDBY OK NOK

EXPECTED RESULTS:

3. Cell change works.

OK

NOKEXPECTED RESULTS: 3. Cell change works. OK

EXPECTED RESULTS: 3. Cell change works. OK NOK

4. MS is still in STANDBY state.

OK

NOK4. MS is still in STANDBY state. OK

4. MS is still in STANDBY state. 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.

 

1. Network elements accepted.

PREREQUISITES:

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

3. More than one BTS available in the same RA.

 

1. Check the READY STATE timer value from the SGSN (ZEJH; command).

 

2. Attach the subscriber.

TEST EXECUTION:

3. Change cell under the same RA before the READY timer has been expired (default value

44 sec.). Value can also be changed bigger if needed.

4. Check cell change from the MS

   

Result:

 

1. Attach is successful.

OK

NOK  1. Attach is successful. OK

  1. Attach is successful. OK NOK

2. MS state is READY

OK

NOK2. MS state is READY OK

2. MS state is READY OK NOK

EXPECTED RESULTS:

3. Cell change works.

OK

NOKEXPECTED RESULTS: 3. Cell change works. OK

EXPECTED RESULTS: 3. Cell change works. OK NOK

4. MS is still in READY state.

OK

NOK4. MS is still in READY state. OK

4. MS is still in READY state. 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

 

1. Network elements accepted.

PREREQUISITES:

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

3. More than one BTS available in different RA.

 

1. Attach the subscriber.

2. Wait till READY timer has been expired and MS is in STANDBY state (default timer value

44 sec.).

TEST EXECUTION:

3. Change cell to the different RA.

4. Check cell change from the MS

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

22

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

   

Result:

 

1. Attach is successful.

OK

NOK  1. Attach is successful. OK

  1. Attach is successful. OK NOK

2. MS state is STANDBY

OK

NOK2. MS state is STANDBY OK

2. MS state is STANDBY OK NOK

EXPECTED RESULTS:

3. Cell change works.

OK

NOKEXPECTED RESULTS: 3. Cell change works. OK

EXPECTED RESULTS: 3. Cell change works. OK NOK

4. MS is still in STANDBY->READY->STANDBY state.

OK

NOK4. MS is still in STANDBY->READY->STANDBY state. OK

4. MS is still in STANDBY->READY->STANDBY state. 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.

 

1. Network elements accepted.

PREREQUISITES:

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

3. More than one BTS available in different RA.

 

1. Attach the subscriber.

TEST EXECUTION:

2. Change cell to the different RA before the READY timer has been expired (default value

44 sec.).

3. Check cell change from the MS

   

Result:

 

1. Attach is successful.

OK

NOK  1. Attach is successful. OK

  1. Attach is successful. OK NOK

2. MS state is READY

OK

NOK2. MS state is READY OK

2. MS state is READY OK NOK

EXPECTED RESULTS:

3. Cell change works.

OK

NOKEXPECTED RESULTS: 3. Cell change works. OK

EXPECTED RESULTS: 3. Cell change works. OK NOK

4. MS is still in READY state.

OK

NOK4. MS is still in READY state. OK

4. MS is still in READY state. OK NOK

Comments:

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

23

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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
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.
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
PTMSI SIG. REP.RATE FOR NORMAL RA UPDATE
(PGPRS)
1
(PNRA)
1
PTMSI SIG. REP.RATE FOR NORMAL RA UP. NEW VISITOR.(PNRAVIS)
1
PTMSI SIG. REP.RATE FOR PERIODIC RA UPDATE
PTMSI ALLOC. REP.RATE FOR PERIODIC RA UPDATE
(PPRA)
0
(PPARA)
0
PREREQUISITES:
5.
Timers in SGSN (example)
SGSN PARAMETERS:
IMEI CHECK MODE
AUTHENTICATION MODE
PTMSI SIGNATURE MODE
CIPHERING MODE IN USE
(ICHM)
OFF
(AUM)
OFF
(PSMO)
ON
(CIPINUSE)
OFF
CIPHERING MODE AFTER SYSTEM RES
(CIP)
OFF
READY STATE TIMER
MS REACHABLE TIMER
PERIODIC RA UPDATE TIMER
(RDY)
000-44 mm-s
(MSRT)
005-00 mm-s
(PRAU)
003-00 mm-s
1. Attach the subscriber.
2. Monitor Gb interface and check that MS sends periodic RA update message to SGSN.
TEST EXECUTION:
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:
1. Attach is successful.
OK
NOK
EXPECTED RESULTS:
2. MS sends periodic RA update message to SGSN
OK
NOK
ROUTING AREA UPDATE REQUEST (GPRS MM)
Comments:

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

24

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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.

 

1. Network elements accepted.

PREREQUISITES:

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

3. MS with laptop PC and Dial-Up software.

 

1. Activate PDP context from MS (dial *99***128#).

2. Create FTP connection to FTP-server.

TEST EXECUTION:

3. Start sending UL data packets from the MS to the server.

4. Check the contents of transferred file after sending.

   

Result:

 

1. Data packets should be sent and received correctly.

OK

  1. Data packets should be sent and received correctly. OK NOK

NOK

  1. Data packets should be sent and received correctly. OK NOK

EXPECTED RESULTS:

2. Contents of the file should not be corrupted.

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.

 

1. Network elements accepted.

 

PREREQUISITES:

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

3. More than one BTS.

 

4. MS with laptop PC and Dial-Up software.

 

1. Activate PDP context from MS (dial *99***128#).

 

2. Create FTP connection to FTP-server.

TEST EXECUTION:

3. Start sending UL data packets from the MS to the server.

4. Change cell during packet transfer.

 

5. MS still sends packets after cell change.

6. Check the contents of transferred file after sending.

   

Result:

 

1. Data packets should be sent and received correctly even if

OK

NOK  1. Data packets should be sent and received correctly even if OK

  1. Data packets should be sent and received correctly even if OK NOK

EXPECTED RESULTS:

the mobile station has changed the cell during the data packet flow.

2.

Contents of the file should not be corrupted.

OK

NOK2. Contents of the file should not be corrupted. OK

2. Contents of the file should not be corrupted. OK NOK

Comments:

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

25

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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.

 

1. Network elements accepted.

 

PREREQUISITES:

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

3. More than one BTS.

 

4. MS with laptop PC and Dial-Up software.

 

1. Activate PDP context from MS (dial *99***128#).

 

2. Create FTP connection to FTP-server.

TEST EXECUTION:

3. Start sending DL data packets from the server to the MS.

4. Change cell during packet transfer.

 

5. MS still receives packets after cell change.

6. Check the contents of transferred file.

   

Result:

 

1. Data packets should be sent and received correctly even if

OK

  1. Data packets should be sent and received correctly even if OK NOK

NOK

  1. Data packets should be sent and received correctly even if OK NOK

EXPECTED RESULTS:

the mobile station has changed the cell during the data packet flow.

 

2.

Contents of the file should not be corrupted.

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.

 

1. Network elements accepted.

 

PREREQUISITES:

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

3. More than one BTS in different RA.

 

4. MS with laptop PC and Dial-Up software.

 

1. Activate PDP context from MS (dial *99***128#).

 

2. Create FTP connection to FTP-server.

TEST EXECUTION:

3. Start sending UL data packets from the MS to the server.

4. Change cell and RA during packet transfer.

 

5. MS still sends packets after cell change.

6. Check the contents of transferred file after sending.

   

Result:

 

1. Data packets should be sent and received correctly even if

OK

  1. Data packets should be sent and received correctly even if OK NOK

NOK

  1. Data packets should be sent and received correctly even if OK NOK

EXPECTED RESULTS:

the mobile station has changed the RA during the data packet flow.

 

2.

Contents of the file should not be corrupted.

OK

 

NOK

 

Comments:

 

Document Number

GPR33801.doc/0.1

© 2008 Nokia Networks Oy

Pages

26

SG6 Test Cases
SG6 Test Cases
SG6 Test Cases

SG6 Test Cases

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.

 

1. Network elements accepted.

 

PREREQUISITES:

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

3. More than one BTS in different RA.

 

4. MS with laptop PC and Dial-Up software.

 

1. Activate PDP context from MS (dial *99***128#).

 

2. Create FTP connection to FTP-server.

TEST EXECUTION:

3. Start sending DL data packets from the server to the MS.