Gprs

411-5221-050

GPRS

SGSN Monitoring Guide

GPRS5.0 Standard 02.01 October 2003 411-5221-050.02.01

What’s inside...

IntroductionExternal Interface ViewSGSN Functional ComponentsServicesSummary of OAM IndicatorsGlossary

Todd Lamond

ATTENTION: This document will be periodically updated and a newer version MAY be available. Please check www.nortelnetworks.com for a more recent version.

test

GPRS


Document number: 411-5221-050Product release: GPRS5.0Document version: Standard 02.01 Date: October 2003

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright 2003 Nortel Networks, All Rights Reserved

Originated in the United States of America

NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein.

Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant.

* Nortel Networks, the Nortel Networks logo, the Globemark, Unified Networks, Passport, and DMS-HLR are trademarks of Nortel Networks. GSM is a trademark of GSM MOU Association.

iiNortel Networks Confidential Copyright 2003 Nortel Networks

411-5221-050 Standard 02.01 October 2003

iiiNortel Networks Confidential Copyright 2003 Nortel Networks

Publication historyOctober 2003

GPRS5.0, 02.01. Uprelease with no technical changes. The version.issue numbering has been corrected to remove possible confusion with the GPRS 4.0 release of the same version.issue number.

June 2003

GPRS5.0, 01.02. This Standard version for the GPRS5.0 release contains technical updates.

February 2003

Product release GPRS 4.0, Draft 01.01.

Initial release of this document, which is the original design document with standard NTP front and rear covers added with no modification of the information contained within.

GPRS SGSN Monitoring Guide GPRS5.0

iv Publication historyNortel Networks Confidential Copyright 2003 Nortel Networks

411-5221-050 Standard 02.01 October 2003

SGSN Monitoring Guide Nortel Networks Confidential GPRS5.0

411-5221-050 Standard 02.01 ii October 2003

Table of Contents

1 Introduction ...........................................................................................1

1.1 Purpose.............................................................................................1

1.2 Audience ..........................................................................................1

1.3 Organization of This Document.......................................................1

1.4 Software Release Applicability........................................................2

1.5 Assumptions.....................................................................................3

1.6 OAM Graphical User Interfaces ......................................................3

1.7 MDM Alarm Injection Script...........................................................4

1.8 Related Documents ..........................................................................4

1.9 References........................................................................................7

1.10 GPRS Network Overview................................................................8

2 External Interface View .....................................................................12

2.1 Ga Interface....................................................................................12

2.1.1 Ga Connectivity Monitoring ..........................................................12

2.1.2 Ga Monitoring for Activity............................................................13

2.1.3 Ga Monitoring for Congestion.......................................................13

2.2 Gb Interface ...................................................................................14

2.2.1 Gb Connectivity Monitoring..........................................................15

2.2.2 Gb Activity Monitoring .................................................................16

2.2.3 Gb Congestion Monitoring ............................................................17

2.3 Gd Interface ...................................................................................18

2.3.1 Gd Connectivity Monitoring..........................................................18

2.3.2 Gd Monitoring For Activity...........................................................19


411-5221-050 Standard 02.01 iii October 2003

2.3.3 Gd Monitoring For Congestion......................................................20

2.4 Ge Interface....................................................................................20

2.4.1 Ge Connectivity Monitoring ..........................................................20

2.4.2 Ge Activity Monitoring..................................................................21

2.4.3 Ge Congestion Monitoring ............................................................21

2.5 Gn Interface ...................................................................................21

2.5.1 Gn Connectivity Monitoring..........................................................23

2.5.2 Gn Activity Monitoring .................................................................24

2.5.3 Gn Congestion Monitoring ............................................................24

2.6 Gr Interface ....................................................................................25

2.6.1 Gr Monitoring For Connectivity....................................................25

2.6.2 Gr Monitoring for Congestion .......................................................26

2.7 Gs Interface....................................................................................27

2.7.1 Gs Connectivity Monitoring ..........................................................27

2.7.2 Gs Activity Monitoring..................................................................28

2.7.3 Gs Congestion Monitoring.............................................................28

2.8 LICP Interface................................................................................29

2.8.1 LICP Connectivity Monitoring ......................................................29

2.8.2 LICP Activity Monitoring..............................................................29

2.8.3 LICP Congestion Monitoring ........................................................29

3 Functional Components .....................................................................31

3.1 GPRS IP Server (GIPS) Monitoring ..............................................31

3.1.1 GIPS Connectivity Monitoring ......................................................31

3.1.2 GIPS Activity Monitoring..............................................................32

3.1.3 GIPS Congestion Monitoring ........................................................32

3.2 GSC Monitoring.............................................................................32


411-5221-050 Standard 02.01 iv October 2003

3.2.1 GSC Instance Monitoring ..............................................................32

3.2.2 GSC Connectivity Monitoring.......................................................32

3.2.3 GSC Congestion.............................................................................33

3.2.4 GSC Out of Resources ...................................................................33

3.2.5 Map Client Monitoring ..................................................................33

3.2.6 Overload Control Monitoring ........................................................35

3.3 GSD Monitoring ............................................................................35

3.3.1 GSD Instance Monitoring ..............................................................36

3.3.2 GSD Connectivity Monitoring.......................................................36

3.3.3 Congestion on GSD .......................................................................36

3.4 GTL Monitoring.............................................................................37

3.4.1 GTL Instance Monitoring ..............................................................37

3.5 DNS Agent Monitoring..................................................................38

3.5.1 DNS Agent Connectivity Monitoring............................................38

3.5.2 DNS Agent Activity Monitoring ...................................................39

3.5.3 DNS Agent Congestion Monitoring ..............................................39

3.6 Inter-shelf Communication Monitoring.........................................39

3.6.1 Inter-shelf Connectivity Monitoring ..............................................40

3.6.2 Inter-shelf Activity Monitoring......................................................41

3.6.3 Inter-shelf Congestion Monitoring ................................................41

3.7 LIAF Monitoring ...........................................................................42

3.7.1 LIAF Instance Monitoring .............................................................42

3.7.2 LIAF Connectivity Monitoring......................................................42

3.7.3 LIAF Activity Monitoring .............................................................42

3.7.4 LIAF Congestion Monitoring ........................................................42

3.8 Logical Processor (LP) Monitoring ...............................................43


411-5221-050 Standard 02.01 v October 2003

3.8.1 LP Activity Monitoring..................................................................43

3.8.2 LP Congestion Monitoring ............................................................43

3.9 SAS Monitoring.............................................................................43

3.9.1 SAS Instance Monitoring...............................................................43

3.9.2 SAS Hard Disk Alarms..................................................................44

3.9.3 Monitoring SAS Activity...............................................................44

3.9.4 Affects of Node Failures on SAS...................................................46

3.9.5 SAS Failure....................................................................................47

3.10 Tcap and Map Stack Monitoring ...................................................47

3.10.1 Tcap/Map Instance Monitoring......................................................47

3.10.2 Monitoring For Connectivity .........................................................48

3.10.3 Monitoring For Activity.................................................................49

3.10.4 Monitoring For Congestion............................................................49

3.11 SIG Monitoring..............................................................................51

3.11.1 SCIP Messages...............................................................................53

3.11.2 High availability.............................................................................56

3.11.3 Monitoring SIG Platform...............................................................57

3.11.4 Monitoring SIG Interfaces .............................................................62

3.11.5 Log Monitoring..............................................................................65

3.11.6 OAMS Command for SIG .............................................................68

4 Services..................................................................................................73

4.1 Mobile Attach ................................................................................73

4.1.1 Monitoring Attach Activity............................................................74

4.1.2 Identifying Reason for Attach Failure ...........................................75

4.1.3 CPU Utilization..............................................................................76

4.1.4 Max Subscribers Reached..............................................................76


411-5221-050 Standard 02.01 vi October 2003

4.1.5 Other Things to Monitor ................................................................76

4.1.6 Overload Conditions ......................................................................76

4.2 Billing ............................................................................................76

4.3 RAU/ IRAU ...................................................................................77

4.3.1 Interfaces to Monitor......................................................................78

4.4 Activation and Deactivation ..........................................................81


4.4.2 GSD Failure on Sessions ...............................................................83

4.4.3 DNS Failure on PDP Context Activation ......................................83

4.4.4 Gn Connection Failures .................................................................83

4.4.5 GSD Resource Constraint on Activation .......................................84

4.4.6 GSC Resource Constraint on Activation .......................................84

4.4.7 Activation Reject Due to Timeout .................................................84

4.4.8 SGSN Initiated Deactivations ........................................................85

4.4.9 Overload Conditions ......................................................................85

4.5 CAMEL Activations ......................................................................85

4.6 SGSN and MS-Initiated PDP Context Modification .....................86


4.6.2 Congestion During PDP Context Modification .............................87

4.7 Short Message Service (SMS) .......................................................88

4.8 Prepaid Short Message Service (PSMS)........................................90

4.8.1 Monitoring Connectivity to SCP ...................................................91

4.8.2 Monitoring Activity between the SGSN and SCP.........................91

4.8.3 Monitoring For Congestion on Link to SCP..................................92

4.9 Packet Flow Management (PFM) ..................................................92

4.9.1 Monitoring for Connectivity to the BSS for PFM .........................92


411-5221-050 Standard 02.01 vii October 2003

4.9.2 Monitoring for Activity to the BSS for PFM.................................92

4.9.3 Monitoring for Congestion to the BSS for PFM............................92

5 Summary of OAM Indicators ...........................................................93

6 Glossary ..............................................................................................102


411-5221-050 Standard 02.01 viii October 2003

List of Figures

Figure 1 Nortel Networks GPRS Network Architecture .........................9

Figure 2Gb Protocol Stack ..................................................................15

Figure 3Gn Control Plane Protocol Hierarchy .....................................22

Figure 4 Gn Data Plane Protocol Hierarchy ........................................23

Figure 5 Multi shelf VSS configuration ................................................40

Figure 6 SIG Inter-working ..................................................................52

Figure 7 SCIP Message Stack ............................................................53

Figure 8 SCIP Registration..................................................................54

Figure 9 SCIP Deregistration .............................................................55

Figure 10 SCIP DATA Message (UDT)..............................................56

Figure 11 SCIP DATA Message (UDT Indication)..............................56

Figure 12 SCIP UDTS message (Notice Indication)...........................56

Figure 13 Monitoring IP Port status with netstat command .................62

Figure 14 SS7 Monitoring Tool............................................................63

Figure 15 Monitoring MTP links.........................................................64

Figure 16 Monitoring SCCP subsystems ..........................................65

Figure 17 Example SC Notice Indication log with return reason equal to SC No Translation Nature....................................................................68

Figure 18 Oams command help ..........................................................68

Figure 19 SCIP logging using Oams command .................................69

Figure 20 Example Registration Request/Response logs ...................70

Figure 21 Example SGSN subsystem de-registration logs .................72

Figure 22 Network view Mobile Attach ................................................73

Figure 23 Network view IRAU .............................................................77


411-5221-050 Standard 02.01 ix October 2003

Figure 24 Network view Activation and Deactivation...........................82

Figure 25 Network view for CAMEL ....................................................86

Figure 26 Network view for SMS.........................................................88

Figure 27 Network view PSMS............................................................90


411-5221-050 Standard 02.01 1 October 2003

1 Introduction 1.1 Purpose

This guide describes how to monitor the operation and stability of SGSN and SIG elements of Nortel Networks GPRS packet core network.

1.2 Audience This publication is intended for persons involved in operation, administration and maintenance of Nortel Networks GPRS packet core networks and their elements. It is assumed that the reader has a general familiarity with GPRS networks and standards, and a similar familiarity with the core network nodes and their respective platforms: 2G SGSN: 15000-VSS Passport GGSN: Shasta 5000 BSN SIG: Hewlett Packard rp7400 or rp5470 Nortel Networks DMS-HLR Note 1: The SGSN is supported on the Passport 15000-Variable Speed Switch (15000-VSS) platform functioning as an SGSN. The SGSN is not supported on the Passport 20000.

1.3 Organization of This Document This guide is divided into three main parts; each corresponds to a different view of the SGSN. These views are: External Interface view, Functional Component view, and Services view. The External Interface view (2) covers system monitoring form the perspective of the interfaces defined in the GPRS standards documents. The Functional Component view (3) provides monitoring information from the perspective of the primary building blocks that comprise the SGSN product. This view is closely aligned along application/card boundaries on the Passport shelves and also includes the SIG. The Services view (4) provides monitoring information from the perspective of main services the SGSN provides to the mobile subscribers of the network. There is a close inter-relationship between the different views. They overlap with each other. For example PDP Context Activation falls under the Services view. However, in order to provide PDP Context Activation it is necessary to have Gb and Gn interfaces which are described under the External Interface view. In addition GTL, GSC, and GSD functional components are also required. To reflect the reality of this overlapping, the document provides cross references (hyper links) to the relevant sections in the other



views. The reader can approach the document from the perspective of any of the views, and navigate the cross references to understand the monitoring information in the other related views that contribute to the current view. Information in this document is organized as follows: Chapter 2: External Interface View � The specification defined interfaces that exist between the SGSN and SIG and the external components that make-up the GPRS system are described here. Chapter 3: Functional Components � The software components that compose the SGSN are described here. Chapter 4: Services � Functions provided by the SGSN are described here. Chapter 5: Summary of OAM Indicators � Table summary of counters and alarms listed in this document.

1.4 Software Release Applicability Information in this document applies to GPRS5.0, unless otherwise stated. While it is intended to be current with the latest GPRS software release, monitoring information becomes more readily available and complete as the software is used in the field. Information in this document pertaining to GPRS5.0 is based on lab experience, and will be updated in future versions. The following table lists the applicable software for each platform in this release. Platform Applicable software

2G SGSN GPRS5.0, base PCR 4.2

SIG SIG4.0, HP-UX 11, HPOC 2.0.1

Shasta GGSN GPRS5.0, base 2.2.5



1.5 Assumptions This guide assumes the SGSN and SIG are provisioned correctly. It does not provide information on monitoring for problems caused by incorrect provisioning. Also, it does not focus on problems that can occur at software initialization time. This guide assumes the system has been up and running and provides guidance on monitoring for problems that cause the SGSN or SIG to deviate from a healthy state. This document assumes the reader has knowledge of SGSN and SIG elements. It is also assumed that the reader is familiar with Nortel�s GPRS 5.0 OAM platforms. This document is not meant to be a troubleshooting guide.

1.6 OAM Graphical User Interfaces In GPRS 5.0 fault management is provided through the Preside for Wireless Internet (PWI) Main Server. The PWI NSP (Network Service Provider) and PWI Historical Fault Browser applications on the Main Server provide fault management capability. Also provided for fault management is Nortel�s MDM (Multiservice Data Manager) element management system. MDM is used for managing Passport devices such as SGSN and mediating fault information to higher layers of the OAM solution such as NSP and HFB. MDM also provides fault management and mediation for the SIG. The alarms generated by the Passport applications that are listed in this document can be viewed through the MDM Alarm Display GUI and MDM Component Information Viewer GUI. Refer to NTP 241-6001-011 Preside Multiservice Data Manager Fault Management User Guide for information on how to use these tools. A subset of the Alarms can also be displayed through the NSP Alarm Browser GUI. Information on how to use this GUI is provided in NTP 450-3101-011 PCN Network Service Provider Overview and Procedures. In particular only the Set alarms are visible through NSP Alarm Browser. Message alarms are not visible, unless they have been converted to SET alarms using the Alarm Injection script (1.7). The NSP Alarm Browser provides in-context help that can be used to display the detailed NTP descriptions for alarms selected by the operator in the NSP Alarm Browser. Alarm descriptions are also documented in NTP 241-5701-500 Passport 6400, 7400, 15000, 20000 Alarms. Alarm history can be viewed at the MDM level using the NTP 241-6001-011 Alarm Display in Log Mode. Alarm history can be viewed at the NSP level through Historical Fault Browser (HFB). Information on HFB can be found in NTP 450-3101-010 PCN Historical Fault Browser Overview and Procedures.



Component Operational attributes, including the OSI State attributes, mentioned in this document can be displayed using the following MDM tools: Component Information Viewer, Remote Access Tool, and Command Console. For information on Remote Access and Command Console utilities refer to Command Console section in NTP 241-6001-804 Preside MDM Workstation Utilities User Guide. The performance related Operational attributes/counters are also viewable through these tools. In addition the MDM Data Viewer GUI can be used to view these attributes/counters as a function of time. Refer to NTP 241-6001-031 Preside Multiservice Data Manager Performance Management User Guide for information on how to use Data Viewer. In GPRS 5.0 Performance Management capability is provided through the PWI Performance Server and its applications. Refer to document NTP 411-5221-305 PWI OAM Administrator Guide for information regarding PWI Performance Server applications. The Collected counters mentioned in this guide are delivered from the Passport SGSN through the Management Data Provider (see NTP 241-6001-309 Preside MDP User Guide) to the PWI Performance Server applications above MDP. These collected statistics are converted to 3GPP XML file format and are available for OSS post processing. Note the 3GPP mapped names provided in the XML files are different from the names listed in this document. The names used in this document are those defined on the Passport SGSN itself. For a mapping between the Passport defined names used in this document and the 3GPP names present in the XML files, refer to NTP 411-8111-401 PWI Core Networks Observation Counters. Reports can be generated from the XML data using Micom International�s NIMS-PrOptima. For information of NIMS-PrOptima refer to the Mycom NIMS-PrOptima documentation.

1.7 MDM Alarm Injection Script The MDM platform may have an alarm injections script installed. This script is used to convert a copy of selected Message alarms into Set alarms. The script then injects the newly created Set alarm into the MDM GMDR server so that it can be seen through the MDM Alarm browser and NSP Alarm Browser. Refer to document NTP 241-6001-310 Preside MDM Server Reference Guide for information on GMDR application.

1.8 Related Documents GPRS SGSN and GPRS network



For information about the GPRS SGSN and other GPRS documents, refer to the following Nortel Networks Technical Publications (NTPs):

� 411-5221-060, SGSN Components � 411-5221-199, GPRS 5.0 Delta Document � 411-5221-201, GSM Specifications for NSS Components of GPRS System Conformance Guide � 411-5221-204, SGSN Call Detail Records (CDRs) � 411-5221-303, GPRS5.0/UMTS3.0 Packet Core Network Upgrade Manual � 411-5221-500, SGSN Alarms Reference Manual � 411-5221-955, GPRS Passport 15000-VSS with SGSN Functionality User Guide

SIG For information about the SIG, refer to the following to the following NTPs:

� 411-5221-975, GPRS SS7/IP Gateway User�s Guide � 411-8111-930, Preside SS7/IP Gateway (SIG) Fault Cartridge User Guide

Shasta GGSN For information about the Shasta GGSN, refer to the following to the following

NTPs: � 411-5221-926, GPRS/UMTS Shasta GGSN User Guide � 411-5221-927, GPRS/UMTS Shasta GGSN Procedures Reference Manual

Base Passport NTPs for 2G SGSN Refer to the following NTPs in the Passport suite (PCR 4.2) for additional information relative to the Passport platform:

� 241-1501-200, Passport 15000, 20000 Hardware Description � 241-1501-205, Passport 15000, 20000 Site Requirements and Preparation Guide � 241-1501-210, Passport 15000, 20000 Hardware Installation Guide � 241-1501-215, Passport 15000, 20000 Hardware Maintenance Guide � 241-5701-001, Passport 7400, 15000, 20000 Documentation Guide � 241-5701-005, Passport 7400, 15000, 20000 List of Terms � 241-5701-030, Passport 7400, 15000, 20000 Overview � 241-5701-045, Passport 7400, 15000, 20000 Management System User Interface Guide � 241-5701-050, Passport 7400, 15000, 20000 Commands � 241-5701-053, Passport 7400, 15000, 20000 Command Summary Card � 241-5701-060, Passport 7400, 15000, 20000 Components



� 241-5701-270, Passport 7400, 15000, 20000 Software Installation Guide � 241-5701-275, Passport 7400, 15000, 20000 Commissioning Guide � 241-5701-500, Passport 6400, 7400, 15000, 20000 Alarms � 241-5701-510, Passport 7400, 15000, 20000 Trace Guide � 241-5701-520, Passport 7400, 15000, 20000 Troubleshooting Guide � 241-5701-600, Passport 7400, 15000, 20000 Configuration Guide � 241-5701-605, Passport 7400, 15000, 20000 User Access Guide � 241-5701-611, Passport 7400, 15000, 20000 Data Collection Guide � 241-5701-615, Passport 7400, 15000, 20000 FP Configuration Reference � 241-5701-700, Passport 7400, 15000, 20000 ATM Overview � 241-5701-702, Passport 7400, 15000, 20000 ATM Routing and Signaling Fundamentals � 241-5701-705, Passport 7400, 15000, 20000 ATM Traffic Management Fundamentals � 241-5701-706, Passport 7400, 15000, 20000 ATM Traffic Shaping and Policing � 241-5701-707, Passport 7400, 15000, 20000 ATM Queuing and Scheduling � 241-5701-710, Passport 7400, 15000, 20000 ATM Configuration Guide � 241-5701-715, Passport 7400, 15000, 20000 ATM Monitoring and Troubleshooting Guide � 241-5701-805, Passport 7400, 15000, 20000 Understanding IP � 241-5701-810, Passport 7400, 15000, 20000 Configuring IP � 241-5701-900, Passport 7400, 15000, 20000 Frame Relay UNI Guide � 241-5701-910, Passport 7400, 15000, 20000 Frame Relay NNI Guide � 241-5701-920, Passport 7400, 15000, 20000 Frame Relay to ATM Interworking Guide � 241-7401-200, Passport 7400 Hardware Description � 241-7401-210, Passport 7400 Hardware Installation Guide � 241-7401-215, Passport 7400 Hardware Maintenance Guide

GPRS/UMTS OAM Solution documentation: Refer to the following NTPs for additional information on GPRS OAM platforms:

• 411-8111-907, About the UMTS OAM Main and Performance Servers • 411-8111-504, UMTS Packet Core Network OAM Module Overview • 411-8111-502, UMTS Global OAM Overview • 411-8111-538, System Management for the OAM Platform • 450-3101-011, Network Services Platform Overview and Procedures • 411-8111-505, Preside for Wireless Internet OAM Operators Guide

Preside Multiservice Data Manager (MDM) release 13.3 documentation



Refer to the following NTPs in the Preside MDM suite for additional information about Passport OA&M:

� 241-6001-011, Preside MDM Fault Management User Guide � 241-6001-023, Preside MDM Configuration Management for Passport User Guide � 241-6001-303, Preside MDM Administrator Guide � 241-6001-301, Preside MDM Customization Administrator Guide � 241-6001-309, Preside MDM Management Data Provider User Guide � 241-6001-801, Preside MDM Overview � 241-6001-804, Preside MDM Workstation Utilities User Guide � 241-6001-806, Preside MDM MDP Data Formats Reference Guide

1.9 References For more information about the GPRS interfaces and protocols referred to in this document, refer to the following specifications:

• GSM 03.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 2 (GSM 03.60 version 6.7.0 Release 1997)

• GSM 04.08, Digital cellular telecommunications system (Phase 2+);Mobile radio interface layer 3 specification (GSM 04.08 version 6.9.0 Release 1997)

• GSM 04.07, Digital cellular telecommunications system (Phase 2+); Mobile radio interface signaling layer 3; General aspects (GSM 04.07 version 6.5.1 Release 1997)

• GSM 04.64, Digital cellular telecommunications system (Phase 2+); General Packet Radio Services (GPRS); Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) layer specification (GSM 04.64 version 6.7.0 Release 1997)

• GSM 04.65, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Mobile Station (MS) � Serving GPRS Support Node (SGSN); Sub Network Dependent Convergence Protocol (SNDCP) (GSM 04.65 version 6.7.0 Release 1997)

• GSM 09.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp Interface; (GSM 09,60 version 6.7.0 Release 1997)

• GSM 08.16: �Digital cellular telecommunications system (Phase 2+) (GSM); General Packet Radio Service (GPRS); Base Station System (BSS) - Serving



GPRS Support Node (SGSN) interface; Network Service�, version 6.3.0, Release 1997.

• 08.18: �Digital cellular telecommunications system (Phase 2+) (GSM);General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)�, version 6.4.0, Release 1997)

• 3GPP TS 32.015, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging and billing; 3G call and event data for the Packet Switched (PS) domain, version 3.7.0

• 3G TS 32.015, GSM call and event data for the packet switched domain (3G TS 32.015 version 3.6.0 Release 1999)

• 3G TS 22.078 v3.8.0 Camel Service Description, Stage 1 (Release �99) • 3G TS 23.078 v3.9.0 Camel Phase 3, Stage 2 (Release �99) • 3G TS 29.078 v3.8.0 Camel Phase 3, CAP Specification, (Release �99)

1.10 GPRS Network Overview General Packet Radio Service is a wireless packet data service that is an extension to Global System for Mobile communications (GSM) network. General Packet Radio Service provides an efficient method to transfer data by optimizing the use of network resources. General Packet Radio Service enables high spectrum efficiency by sharing time slots between different users, supporting data rates up to 170 kbit/s and providing very low call set-up time. Additionally, GPRS offers direct Internet Protocol (IP) connectivity in a point-to-point or a point-to-multipoint mode and provides packet radio access to external packet data networks (PDN). The Nortel Networks GPRS network architecture is implemented on the existing wireless infrastructure with the inclusion of the following new network entities:

• Serving GPRS Support Node (SGSN) • Gateway GPRS Support Node (GGSN) • SS7/IP Gateway (SIG) • Packet Control Unit Support Node (PCUSN)



Figure 1 Nortel Networks GPRS Network Architecture

Figure 1 illustrates the Nortel Networks GPRS network architecture and interfaces within a wireless network and the public data network. This diagram is intended to provide a point of reference and is not a complete description of the Nortel Networks GPRS core network architecture. Only primary network nodes and signaling interfaces are shown. The primary network nodes are: • GPRS Support Node (GSN) - A GSN contains functionality required to support

GPRS. The GPRS Support Nodes include two elements: the Gateway GSN (GGSN) and the Serving GSN (SGSN). These elements may be co-located or separate. The SGSN and GGSN contain IP routing functionality and may be interconnected with IP routers.



• Serving GPRS Support Node (SGSN) - The SGSN performs mobility management, implements authentication procedures and routes packet data. The SGSN requests location information from the Home Location Register (HLR) through the Gr interface. These messages are routed through the SS7/IP Gateway (SIG), which provides interworking between GPRS nodes in an IP network and GSM nodes in a signaling system 7 (SS7) network.

• Gateway GPRS Support Node (GGSN) - The GGSN provides the point of

interconnection with external PDNs for Public Land Mobile Networks (PLMN) supporting GPRS. This interconnection utilizes the Gi interface. The GGSN stores routing information for attached GPRS users. The routing information is used to tunnel Protocol Data Units (PDU) to the current point of attachment of the MS; for example, the SGSN.

• SS7/IP Gateway (SIG) - The SIG provides a relay function between the SGSN and the SS7 nodes. In this release, the SIG supports the Gd interface between the SGSN and Gateway MSC for Short Message Services/Interworking MSC for Short Message Services (SMS-GMSC/ SMS-IWMSC), the Ge interface between the SGSN and the Service Control Point (SCP), the Gr interface between the SGSN and HLR, and the Gs interface between the SGSN and the MSC/VLR. Multiple SGSNs exist in the GPRS network, making the SIG responsible for routing messages from the GSM HLR or MSC to the correct SGSN.

• Home Location Register (HLR) - The HLR is a network database used for

permanent management of mobile subscribers within a PLMN. It is accessible from the SGSN through the Gr interface. The HLR has been enhanced to include GPRS subscription data and routing information.

• Base-station Subsystem (BSS) - The BSS provides the air interface resources and is

composed of the Base Transceiver Station (BTS) and the Base Station Controller (BSC). The BSS also includes the Packet Control Unit Support Node (PCUSN).

• Packet Control Unit Support Node (PCUSN) - The PCUSN is a node in the BSS

which interacts either directly or indirectly with all the BSS nodes, except the Transcoder Unit (TCU), such as the BSC, the BTS and the Operation and Maintenance Center - Radio (OMC-R). The main function of the PCUSN is to manage channel and radio link control.

• Mobile Switching Center (MSC) - The MSC is responsible for call processing and

circuit-switched data. The MSC does not perform functions for the GPRS network.



The primary supported interfaces are: • Ga - The interface between the SGSN and the Charging Gateway Function (CGF). • Gb - The interface between the SGSN and the BSS. This interface is frame relay. • Gd - The interface between the SGSN and the Gateway MSC for Short Message

Services or Interworking MSC for Short Message Services (SMS-GMSC or SMS-IWMSC).

• Ge - The interface between the SGSN and the SCP. The Ge interface is used for Customized Application for Mobile network Enhanced Logic (CAMEL) phase 3 services.

• Gi - An external interface between the GGSN and another type (non-GPRS) of packet network.

• Gn - The interface based on IP that is between the SGSN and the GGSN. • Gp - The interface based on IP that is between the SGSN and the GGSN in different

PLMNs. • Gr - The interface between the SGSN and the HLR. • Gs - The interface between the SGSN and MSC/VLR. The Gs interface provides

mobiles the ability to communicate with the MSC/VLR for circuit switch services while they are attached to the packet network.

• Gr', Gs', Gd' Ge'- The interface between the SGSN and the SIG. These are Nortel Networks proprietary messaging interfaces.



2 External Interface View The external interfaces covered in this document are: Ga, Gb, Gd, Ge, Gn, Gr, and Gs. The diagram in Figure 1 shows where the interfaces belong in the logical view of the network. Refer to GSM 03.60 (1.9) for more information on these interfaces. • A - The interface between the MSC/VLR and BSS • Ga - The interface between the SGSN and the Charging Gateway Function (CGF) • Gb - The interface between the SGSN and the BSS. This interface is frame relay. • Gd - The interface between the SGSN and the SMS-GMSC/SMSIWMSC. • Ge - The interface between the SGSN and the Service Control Point (SCP). • Gn - The interface based on IP that is between the SGSN and the GGSN. • Gp - The interface based on IP that is between the SGSN and the GGSN in different

PLMNs. • Gr - The interface between the SGSN and the HLR. • Gs - The interface between the SGSN and MSC/VLR. • LICP � Lawful Intercept Common Protocol

2.1 Ga Interface The Ga interface is the charging data collection interface between the SGSN and the CGF. The Ga interface is instrumented through the following functional components: SAS (3.9), GIPS (3.1). See referenced sections for information on monitoring these components. The Ga interface is implemented by the Billing (4.2) service.

2.1.1 Ga Connectivity Monitoring Communication link problems are detected by the SAS component when a GTP protocol message is not acknowledged by the CGF or if the CGF fails to respond to an Echo Request message from the SAS component. If the SAS application detects a failure between itself and the CGF, a Set alarm (CGF Link Failure Alarm: 7068 1003) is raised against Sas/ to notify the operator. If the severity of the alarm is Critical, this means there is no connectivity at all to any CGF. If the severity is Minor, this indicates connectivity to one CGF is lost, but there is still



connectivity to the redundant CGF. When communication link is determined to be available once again the Set alarm is cleared. If redundant CGFs are provisioned on SAS and a failure occurs on a link that was in use, those CDRs are transferred to the other CGF without any service impact. If there is no CGF connectivity at all, then it is not possible to transmit CDRs from the SGSN. The Ga Interface is out of service. If the Ga interface is out of service, CDRs will continue to spool to disk until a link becomes available again. Once communication is restored, the CDRs stored on disk are transferred to the CGF. The age of the CDRs and delay in transmission of the CDRs depends upon the outage time and outage frequency of the CGF and the traffic load on the SGSN. Please refer to NTP 411-5221-500 SGSN Alarm Reference Manual for more details.

2.1.2 Ga Monitoring for Activity Verifying activity on Ga can be accomplished by monitoring Sas/ cdrsXferCgf1, Sas/ cdrsXferCgf2, Sas/ gtpMsgXferCgf1, and Sas/ gtpMsgXferCgf2 counters.

2.1.3 Ga Monitoring for Congestion If there are excessive delays on the link to the CGF or frequent CGF failures then CDRs can build up on the SAS disk over time and eventually fill up the disk causing the processing of billing records to stop. If the amount of closed CDRs is significantly higher than the amount of CDRs transferred there�s likely a backlog of CDRs on the disk. Eventually there will be a disk full alarm indicating the need for corrective action. The SAS card has a hard coded limit on the number of open CDRS at one time. The Sas/ openScdrs and Sas/ openMcdrs can be monitored against the values of 800,000 and 400,000 respectively to indicate resource exhaustion on the card. The following SAS counters indicate failure in transferring CDRs or GTP messages from SAS to primary and secondary CGF nodes. Therefore, a rapid increase of these counters can indicate Ga congestion due to CGF or link failures.

• cdrXferCgf1Fail • cdrXferCgf2Fail • gtpMsgXferCgf1fail • gtpMsgXferCgf2fail



Please refer to NTP 411-5221-060 SGSN Components Reference Manual and 411-5221-501 UMTS/GPRS Core Network Troubleshooting Guide for more details.

2.2 Gb Interface The Gb interface provides connectivity between the BSS and the SGSN, allowing the exchange of signaling information and user data. The Gb interface link layer is based on Frame Relay as defined in GSM 08.16. Frame Relay virtual circuits are established between SGSN and BSS. LLC PDUs from many users are multiplexed on these virtual circuits. The Gb interface is used by the following services: Mobile Attach (4.1), RAU/IRAU(4.3), Activation and Deactivation(4.4), SMS (4.7) and Prepaid SMS (4.8). The Gb interface is implemented through the Gtl (3.4) and Gsd (3.3) functional components. An NSE (Network Service Entity) represents a group of cells. The NSE manages all the physical and logical connections used to route packets between the SGSN and the mobile, via the BSS. An NSE is comprised of BVC and NS-VCs. Each BVC represents a single cell site. Each NS-VC has a one-to-one relationship with a DLCI in the Frame Relay layer (L1). NS-VCs across an SGSN work in a load shared fashion to provide multiple access routes between SGSN and BSS. Load sharing functions at the BSS and the SGSN are independent. Therefore, uplink and downlink packets for a subscriber may be transferred over different NS-VCs. Within an NSE, an NS-VC can carry traffic for any BVC. For a BVC, when there is no unblocked NS-VC left between a BSS and a SGSN, the NS at the source discards the corresponding traffic. The protocol stack for the Gb interface is shown in Figure 2 .



Gb BSS

Network Service

RLC

MAC

BSSGP

L1

Relay BSSGP

L1

SGSN

Network Service

Figure 2Gb Protocol Stack

2.2.1 Gb Connectivity Monitoring The GTL software detects if the number of unavailable BVC�s within an NSE exceeds a provisioned threshold value. A BVC is unavailable if for an extended period of time, it is blocked or flow control is preventing it from sending traffic. When the threshold is crossed a Major Set alarm (The Number of Unavailable BVCs Has Exceeded the Threshold Alarm: 7068 1023) is raised against the Gtl/ Nse/ component. The OSI State of the Gtl/ Nse/ component remains enabled while this alarm is set. The alarm is cleared by the GTL software, when the number of unavailable BVCs, drops blow a provisioned clear threshold. The operator can display the Gtl/ Nse/ Bvc/ availabilityStatus attribute to determine which Bvc�s are bvcAvailable. If a BVC is not in the bvcAvailable state then the cell site logically related to the BVC is affected. Because the NSVCs within an NSE provide the transport mechanism between the SGSN and PCU, it is mandatory that at least one of these NSVCs be able to carry traffic (i.e., Not blocked and not flow controlled) in order for the BVCs in that NSE to be usable. If this condition is not met then traffic will be discarded at the Network Service layer. A Gb link failure can be detected by displaying the NSVC ( Sggtl/ Nse/ Nsvc/ state) and DLCI ( Fratm/ Dlci/ operationalState) states. If the NSVC state is blocked look at the ATMCON state (Ggtl/ Nse/ Nsvc/ atmconState) to verify that an ATM connection is established for the NSVC. If the DLCI operationalState is disabled the associated NSVC will remain dead, and no traffic will flow on the Gb link. If a specific DLCI is disabled,



check for physical connectivity issues (see below). A DLCI could go into disabled state if there is not enough bandwidth available on the FRATM interface. A minor Set alarm (Frame Relay Service Alarm: 7007 0000) under Fratm/ indicates this problem. Problems on the LMI component could also cause DLCI to go disabled. Check the operationalState of the LMI (Fratm/ Lmi operationalState) A DLCI error is also indicated by a Critical Set alarm (Frame Relay Service Alarm: 7007 1000) under Fratm/ Lmi and is generated when the number of LMI related errors exceed the provisioned threshold. Alarms (Frame Relay Service Alarm: 7007 2000) and (Frame Relay Service Alarm: 7007 2020) indicate that the PVC connection to the PCU is inactive. The operator should check the PVC connection associated with the DLCI. In case if the DLCI operationalState is enabled make sure that the number of frames received is rising (Fratm/ Dlci/ frmFromIf). Physical connectivity issues such as a bad port can be detected by monitoring the operation state of the LP component �Lp/ E1/ operationalState�. An on value for lofAlarm, losAlarm, and multifrmRaiAlarm attributes is an indication of connectivity issues. Any of the following Set alarms can be generated: (Port Management System Alarm: 7011 2000, 7011 5000, 7011 5002, 7011 5004, and 7011 5010). Note that when the physical link is down BVCs remain in their existing state. A blocked NSVC can indicate a BSS equipment failure, link failure, or failure in the transit network [see GSM 08.16]. A rapid increase in counter Sggtl/ Nse/ Nsvc/ blocksFromPcu can indicate this type of failure. In addition to the above guidelines for monitoring Gb connectivity, there is a counter on the Gsc/ Sms called cpResponseExhaust. If this counter is pegging, it means SMS is not getting responses back from the MS for messages sent. This counter is pegged for both Mobile Originated and Mobile Terminated messages. The rpResponseTimeouts counter is incremented when the SGSN does not receive an acknowledgement to an SMS CP-DATA (RP-DATA) message. This counter depicts communication issues between the MS and SGSN. This is typically an issue local to a single mobile; however, if this counter is incrementing rapidly for a prolonged period of time, it may be a symptom of a Gb interface problem.

2.2.2 Gb Activity Monitoring Once an NSVC is in the enabled state, check Sggtl/ Nse/ Nsvc/ alivesFromPcu, alivesToPcu, aliveAcksFromPcu & aliveAcksToPcu attributes under the component to monitor activity. For a specific NSVC the counter values for alivesFromPcu & aliveAcksToPcu and the values for alivesToPcu & aliveAcksFromPcu should be the



same. If they are not, it could imply that either side did not respond back to the ping. This could happen because the message was discarded because of congestion (2.2.3) or connectivity (2.2.1) sections. A Sggtl/ Nse/ Ptpbvc/ component in a blocked state could signify equipment failure at the BSS, operations and maintenance intervention of a cell, cell equipment failure at the BSS, or other BSS specific issues see GSM 08.18 document (1.9). If the counter Sggtl/ Nse/ Ptpbvc/ blocksFromPcu is increasing, check the BSS for possible problems. If the number of BVC per NSE reaches the Sgsn/ maxBvcsPerNse provisioned limit, the SGSN raises a Warning Message alarm (Maximum Number of BVCs per NSE Exceeded Alarm: 7068 1020) and sends a status message to the PCU for every BVC create request message received. If the Sggtl/ Nse/ Ptpbvc/ statusToPcu counter is increasing, the Sgsn/ maxBvcsPerNse provisioned value should be increased. No additional BVCs will be created above the provisioned limit.

2.2.3 Gb Congestion Monitoring When the SGSN is congested, messages may be discarded silently; a failure to respond to requests from the PCU may cause BVC state mismatches. In case of a state mismatch either node may initiate a Bvc Reset. If the counter Sggtl/ Nse/ Ptpbvc/ resetsFromPcu is high, check the state of each Bvc ( Sggtl/ Nse/ Ptpbvc/ state) and validate it against the state on the PCU. Point-to-point BVC state mismatches can be remedied by initiating reset messages at the PCU. The GTL or CP cards may discard messages bound for the GSD when either is congested. If a message is discarded before reaching the GSD, an unblocked BVC will not be used. The BVC may be considered blocked on the GSD if the value of counter Sggt/ Nse/ Ptpbvc/ pdusToPcu is not increasing. If Sggtl/ Nse/ Ptpbvc/ pduFromPcu is incrementing and Sggtl/ Nse/ Ptpbvc/ pduToPcu is not, the BVC on the PDU should be checked for proper operation. The SGSN may receive many BVC reset messages for an A-gprs link reset or FrAtm activation or removal. A storm of BVC reset messages received on the SGSN could cause congestion and messages to be discard resulting in state mismatches. A rapidly increasing Sggtl/ Nse/ Ptpbvc/ resetsFromPcu counter could indicate a A-gprs link or FrAtm setup activity. The SGSN discards LLC-PDUs in accordance with the specification defined BVC flow control. The discarded PDUs on the SGSN are counted by the Sggtl/ Nse/ Ptpbvc/ flowCntrlPdusDiscarded counter.



2.3 Gd Interface The Gd interface is a signaling link that provides point-to-point Short Message Service message transfers between the SGSN and SMS-GMSC/ SMS-IWMSC. Refer to section (4.7) for a description SMS.

The Gd interface is instrumented through the following functional components: Gsc MapClient (3.2.5), Gsc Sms (3.2.5.2), and Map/Tcap (3.10). The Map Client and Map Stack provide the connectivity to the SIG (3.11). Refer to the corresponding sections in this document for information on monitoring these functional components.

2.3.1 Gd Connectivity Monitoring

2.3.1.1 Connectivity to SMS-GMSC/ SMS-IWMSC The SGSN implements the Gd interface by utilizing the Gsc Map Client (3.2.5), Tcap/Map (3.10), and the SIG (3.11) components. The Gsc/ Sms component does not provide an assessment of the state of connectivity to the SIG. The Map Client component on the GSC and the TCAP card will indicate the operability of this interface. The Gsc/ Sms iwmscResponseTimouts counter can be displayed to determine if the GSC is timing out while waiting for response messages from the SMS-GMSC/SMS-IWMSC. If this counter is actively increasing then there may be congestion or a connectivity problem between the SGSN and the SMS-GMSC/SMS-IWMSC. A stable Tcap/ Map moFsmTimeouts counter, while the Gsc/ Sms iwmscResponseTimouts counter increases, indicates a communication issue between Gsc/ Sms and Map Stack. The Tcap/ Map mofsmTimeouts counter is incremented when a mobile originated Forward Short Message Acknowledge message is not received from the GMSC or SC in response to a Forward Short Message Request message. A rapidly increasing counter could be a symptom of a communication problem with the GMSC or SC, or congestion on the Gd interface. SMS Mobile Terminated connectivity issues between the SGSN and GMSC can be identified by displaying the Tcap/ Map mtFsmTimeouts counter. This counter is incremented when a Mobile Terminated Forward Short Message Acknowledge is not received by the MAP Stack on the SGSN in response to a Mobile Terminated Forward Short Message Request message. A communication problem between the GSC and the TCAP card can be identified by a large disparity in the rate of increase between the Tcap/ Map mtFsmTimeouts counter and the Gsc/ Sms rpResponseTimeouts counter.



Refer to section (3.10) for more information on monitoring Tcap/Map functional component.

2.3.1.2 Map Client Registration with SIG The MapClient component can use the same registration with the SIG for both Gr and Gd interfaces. However, if the mscEmulationMode attribute under Sgsn Gsc is set to on, MapClient will send a separate registration to the SIG just for the Gd interface. If MapClient is not able to register successfully with the SIG for the Gd interface, the Gsc/ Mc operationalState is not affected; it remains enabled but all Gd dialogues will fail. There is no alarm generated by GSC for Gd registration failures. The Gd monitoring section (2.3‎) explains how to monitor activity on the Gd and could be used to help identify a failed Gd registration.

2.3.2 Gd Monitoring For Activity The operator can check the success rate of mobile originated short message delivery to SMS-GMSC/SMS-IWMSC by observing moAttempts vs moFail* counters on the Gsc/ Sms, where moFail* represents all counters prefixed by moFail. If these counters are incrementing at the same rate, then short messages originated by the MS are not being delivered successfully to the SMS-GMSC/SMS-IWMSC. The following attributes on the Gsc/ Sms component indicate the various reasons for failed message deliveries and should be analyzed for specific network problems: moFailNetworkFailures, moFailUnidentifiedSubscriber, moFailFacilityNotSupp, moFailCongestion, moFailUnknownServiceCenter, moFailInvalidSmeAddress, moFailMissingSmsSubscription, moFailOdbSubscriber and moFailOthers. Mobile originated SMS messages increment both the Gsc/ Sms moAttempts counter and the on the Gsc/ Mc ofSmMsgs counter and they should increment in step. Mobile originated SMS problems counted on the Gsc/ Sms moFailNetworkFailures counter can be attributed to either a network problem (gd I/F), a prepaid SCP not responding, an iwmscResponseTimer expiring, or an equipment protocol error. The Gsc/ Sms moFailUnidentifedSubscriber counter counts mobile originated SMS procedures failure that can be attributed to an MS not registered in the PLMN, an MS not subscribed to Service Center, or a MS Prepaid Mobile Originated SMS account balance depleted. The Gsc/ Sms moFailFacilityNotSupp counter increments when the network is unable to provide the requested SMS service. Mobile Terminated SMS operability can be monitored much like the Mobile Originated monitoring discussed above. For Mobile Terminated SMS the Gsc/ Sms mtAttempts counts the number of Mobile Terminated Forward Short Message received from the



Service Center, while the sum of Gsc/ Sms mtFail* counters counts the total failures. When these two counters increment at a similar rate, the Gd interface could have a connectivity problem and the following Gsc/ Sms counters should be analyzed for the proper Gd operation: mtFailUnidentifiedSubscriber, mtFailSubscriberAbsent, mtFailSubscriberBusy, mtFailSubscriberNotSmEquipped, mtFailNetworkFailures, mtFailMemCapExceeded and mtFailOthers. Mobile Terminated SMS messages increment the Gsc/ Sms mtAttempts counter and the Gsc/ Mc tfsmMsgs counter and they should increment in step.

2.3.3 Gd Monitoring For Congestion Congestion on the Service Center is indicated on the SGSN by the Gsc/ Sms moFailCongestion counter. The Service Center responds to the SGSN on a Mobile Originated SMS with a congestion cause value when congested. Examine the Service Center for capacity issues when this counter increases rapidly or often.

2.4 Ge Interface The Ge interface makes Camel functionality, more specifically prepaid activations, possible on the SGSN. The Ge interface originates on the GSC (3.2) card and uses the TCAP (3.10) card and the SIG (3.11) to access the external SCP.

2.4.1 Ge Connectivity Monitoring The loss of the Ge connection may disallow CAMEL activations and the activation of sessions on the SGSN for Inter SGSN RAUs. Whenever the Ge link is not registered with the TCAP Stack, the operationalState attribute of the Gsc/ Ssf component is set to disabled. The PDP context can be provisioned in the HLR to allow the activation or session transfer to succeed even on a Ge interface failure. When provisioning indicates that the activation shall fail, the activation success rate for the Gsc/ Sm is impacted. Consequently, Ge problems may be accompanied by the presence of threshold alarm (PDP Activations Requests Rejected or Not Received Alarm: 7068 1532) raised on the Gsc/ Sm component. When no response is received over the Ge for any CAP messaging, the Gsc/ Ssf totalTssfTimeouts counter is incremented. A connection failure or an SCP failure can be deduced from a rapidly increasing totalTssfTimeouts counter. The general health of the Ge interface can be monitored by the number of unsuccessful dialogues compared to the total number of attempted dialogues that occurred. The specific counters to monitor are Gsc/ Ssf attemptedCamelDialogues and Gsc/ Ssf



unsuccessfulCamelDialogues counters. Excessive unsuccessful dialogues can indicate an SCP failure or other connection issues.

2.4.2 Ge Activity Monitoring Verifying activity on the Ge interface can be accomplished through a number of components. External to this section, the TCAP card section (3.10) and SIG section (3.11) of this document will indicate that signaling is flowing through those components. On the GSC card, the Gsc/ Ssf pdpContextsRedirected counter will indicate how many successful camel activations or RAU activations have occurred. This counter should increase. The Gsc/ Ssf currentCamelDialogues counter should stay relatively constant during stable operation. When the SCPs are responding in a reasonable time interval, no accumulation of dialogues waiting for a response should be seen; however, a rapidly growing Gsc/ Ssf currentCamelDialogues counter could indicate either a spike in camel activations or an impending failure on the Ge interface.

2.4.3 Ge Congestion Monitoring Congestion can occur on the Ge interface either, when responses are slow in returning from the SCP, the TCAP or SIG components are congestion or the GSC itself is experiencing heavy traffic and is slow in processing incoming events. Congestion on the Ge connection can be measured in the number of dialogues used to do CAMEL communication. The usageState attribute of the Gsc/ Ssf component is set to busy when 95% of the CAMEL dialogues are used. The OSI state is returned back to active when the less than 90% of the provisioned dialogues are in use. If, however, all of the CAMEL Dialogues are used, a Major Set alarm (SSF Max Camel Dialogues Exceeded Alarm: 7068 1519) is set; the alarm is cleared when the percentage of dialogues used is reduced to below 90%. Congestion in the network can cause an increase in message timeouts between the Gsc/ Ssf and SCP. If message timeouts are occurring this is tracked by the totalTssfTimeouts attribute.

2.5 Gn Interface The SGSN uses the Gn interface for communications with the GGSN for tunnel creation, update and deletion and with another SGSN for transferring mobiles and sessions during inter routing area update. The protocol used by Gn is the GPRS Tunneling Protocol (GTP). The description of this interface and the exact message formats is presented in the GSM 9.60 specification (1.9) and 29.060. The GPRS 5.0 release of the SGSN added the version 1 of the GTP protocol to its functionality. The new version of the protocol decouples the IMSI from the data and



messaging header and allows for more features. All Gn interaction across a new path will default to the version 1 of the GTP protocol. If a version not supported cause value or no response is received across Gn, the SGSN will fallback to the Version 0 of the GTP protocol. Once the version of the path is determined, the SGSN will use that version for all additional messaging until that path is no longer used. The Gn interface is employed on the control plane and the user plane for signaling between the SGSN and the GGSN and for data packet transfer between the SGSN and the GGSN and for Inter SGSN-RAU between two SGSNs. The control plane also employs active connection management called path management through an echo request and response mechanism across individual paths that are defined by IP address between the SGSN and the GGSN. The protocol stack for the signaling plane is presented below in Figure 3:

UDP

L2

L1

IP

L2

L1

IP

UDP

Gn or Gp GSN GSN

GTP-C GTP-C

Figure 3Gn Control Plane Protocol Hierarchy

The protocol stack for the data plane is presented below in Figure 4:



UDP

L2

L1

IP

L2

L1

IP

UDP

Gn or Gp GSN GSN

GTP-U GTP-U

Figure 4 Gn Data Plane Protocol Hierarchy

2.5.1 Gn Connectivity Monitoring The Gn Interface is connected to GGSN and SGSN by both a physical connection and intangible connections defined by an IP address between GSNs. This concept extends to both the data plane and the signaling plane. Verification of Gn connectivity can be indicated on the GGSN on the other end of the interface. The GPRS Tunnelling Protocol (GTP) used on the Gn interface uses active path management to indicate failed paths between GSNs. The path management scheme employes an echo request/ echo response message pair as a keep alive for each path. When a path is indicated as failed, a minor set alarm (Gsc GtpM Keep-Alive Alarm: 7068 1540) is set. The alarm is cleared when either the path has recovered or the path is removed by the path aging timer. A path failure will deactivate each session on that path; each session is deactivated once activity is indicated by the mobile containing the session. Passport Base will generate a generic Critical Set alarm (Common Alarm: 0000 1000) for a failed LAN card. The deactivation of sessions due to a path failure can be inferred from the rapidly increasing Gsc/ Sm sgsnInitDeacts counter paired with an increasing Gsc/ Sm networkFailures counter. If the physical link is removed, or the SGSN LAN card is faulty, or a node between the SGSN and the terminating GSN is not available, an alarm should be seen as defined by the Ethernet card. Each time a path failure is detected, the Gsc/ GtpM pathFailures attribute gets incremented if strict path supervision is turned on through provisioning. Therefore this can be a good indicator of path problems between SGSN and GGSN. Inter-RAU and PDP Context Modifications require the Gn interface to update the tunnel information on the GGSN. The update PDP context Request messaging between the new SGSN and the GGSN accomplish this task. The Gsc/ GtpM updatePdpReqAttempts



counter records how many times this messaging has been attempted and the Gsc/ GtpM updatePdpReqExhausted counter indicates how many times the GGSN did not respond to the request. An increasing Gsc/ GtpM updatePdpReqExhausted counter could be an indication of a Gn connectivity problem for a specific path on Gn. Verification of the Gn connectivity can be made by verifying the GTP connection on the GGSN.

2.5.2 Gn Activity Monitoring Activity across the Gn interface includes paths and transactions. A path is defined as an IP address terminated at a GGSN. Activity across this interface can be monitored by the amount of paths currently active and the number of outstanding transactions in GTP. Although the number of current paths is not currently displayed, the peak number of paths is recorded in the Gsc/ GtpM peakGgsnPaths counter. Many paths can be an indication that a context could not be established on a GGSN represented by an IP address and the SGSN established the context on another GGSN. The current number of outstanding transactions is monitored by the Gsc/ GtpM currentTransactions counter. Activity across the Data Path can be monitored by the number of packets that flow through the GTP Data component. The number of packets is presented in the Gsd/ Gtp pdusToNetwork counter and the Gsd/ Gtp pdusFromNetwork counter. If these counters are increasing, the GTP data component is receiving both uplink and downlink data packets. If only Gsd/ Gtp pdusToNetwork counter is increasing, a Gn interface may be the cause. No active path management is performed on the data path for Gn. The data path can receive error indications from GSNs in response to packets sent to a GSN that does not have a session established for it. When this occurs, the session is deactivated and the following counters pegged: Gsc/ Sm sgsnInitDeacts counter and Gsc/ Sm networkFailures counter. An example of what could cause this in a large scale is a failed GGSN where the session has not been deactivated yet on the SGSN. The uplink data packet will be forwarded to the GGSN that would respond with an error indication triggering the deactivation on the SGSN.

2.5.3 Gn Congestion Monitoring Congestion on the Gn interface is limited to the control plane and to the amount of resources required to create a new transaction. The attribute that defines the maximum number of transactions is Gsc/ GtpM maxTransactions. When resources are exhausted for the GTP function on the control plane, the card automatically allocates more resources to handle the increased traffic. An indication of congestion would be the Gsc/



GtpM currentTransactions counter is equal to the Gsc/ GtpM maxTransactions counter, the interface is congested. The Gsc Gtp software that supports the Gn interface can handle up to a provisioned maximum number of simultaneous incoming requests internally and from GGSNs and other SGSNs. These requests include Delete PDP Context, Update PDP Context, Identification requests and SGSN Context requests. If the current number of requests reaches the maximum allowed, any subsequent requests are rejected until there is capacity once again with the Gsc Gtp. Each time a request is rejected, the Gsc/ GtpM incomingRequestsRejected attribute is incremented. Therefore if this counter is pegging it indicates the SGSN is congested. The number of simultaneous incoming request handled can be changed through the Gsc/ GtpM maxIncomingRequests Provisionable attribute; however, a card reset will occur. The data path indicates congestion on the Gn interface on the GSD card. Congestion can be indicated on the GSD if the Gsd/ Gtp discPdusFromNetwork counter increases rapidly in relation with the Gsd/ Gtp pdusFromNetwork counter. Refer to the LP section (3.8) for Data Plane Gn congestion monitoring.

2.6 Gr Interface The Gr interface provides data exchange between the SGSN and the HLR. The SGSN receives authentication and subscription information from the HLR and returns mobility information back to the HLR. This link is accomplished with the GSC (3.2) and TCAP (3.10) cards as well as the SIG (3.11).

2.6.1 Gr Monitoring For Connectivity

2.6.1.1 MapClient Registration with SIG When the GSC card enables and is not able to successfully register with the SIG, the Gsc/ Mc operationalState attribute will remain disabled; a disabled Gsc/ Mc cannot send any message through the SIG. The GSC will continue to register with the SIG sending request at the expiry of the Gsc/ Mc sccpServiceRequestTimer. The Gsc/ Mc sccpServiceRequestTimeouts counter will, if increasing, indicate a failed connection. A TCP Link failure between the SIG and the Map Stack is indicated on the SIG (3.10) and the MAP card (Tcap/ Ss7IpIf/), but it is not indicated at the Gsc/ Mc. Monitoring message activity at the GIPS level can also indicate connectivity. Refer to the GIPS (3.1) section of this document for port monitoring details. When the TCP link fails between the



MAP card (3.2.5) and the SIG (3.11), the MAP card will try to reestablish the TCP connection. Once the connection is reestablished, SIG re-registers all clients with the MAP card without notifying the clients. If the TCP link is not re-established, all Attach (4.1) and IRAU (4.3) procedures will fail. The following checks can be done to verify the operation of the TCP link:

• Check the SGSN Table in the SIG to verify successful registration of MapClient with the SIG.

• The TCP link is established if the operationalState attribute of the Tcap Ss7IpIf component is enabled; otherwise it is disabled.

2.6.1.2 HLR Reset Indication The Gr interface is considered disconnected when the HLR resets. Once the connection is reestablished and the HLR again operating, the SGSN must update the HLR with an Update GPRS Location (UGL) transaction for each mobile attached to the SGSN. An HLR reset raises a warning message (HLR Reset Received Alarm: 7068 1535) on the Gsc/ Hlrc component. The SGSN will try to recover all attached contexts automatically. When the rate of UGL messaging initiated by an HLR reset exceeds its provisioned rate or the map client transactions are exhausted, a major message alarm (HLR Reset Triggered UGL Overload Alarm: 7068 1032) is raised against the Gsc/ Gmm component to indicate excessive HLR reset UGLs.

2.6.2 Gr Monitoring for Congestion General link congestion can be contributed to the GSC (3.2), TCAP (3.10) card, SIG (3.11), or HLR that compose the Gr interface. The first indication of congestion on the interface is a rapidly increasing Gsc/ Mc saiMsgs, a slower incrementing Gsc/ Mc uglMsgs, and an even slower Gsc/ Mc isdMsgs counter. These messages are required for attachments and are sent in the order presented.

2.6.2.1 Gr Map Client Congestion Under congestion, the Map Client will reject MAP dialogues. The Gsc/ Mc transLimitDiscards counter is incremented for each dialogue rejected. A burst of mobile activity can overwhelm the TCAP card. When the TCAP card is overwhelmed and doesn�t respond to request, Map Client dialogues will be exhausted causing congestion on the Gr link. An example of this could be many GSC cards resetting at the same time causing many mobiles to reattach simultaneously. Refer to section Monitoring Map Client Congestion (3.2.5.3) for details on congestion.



2.6.2.2 Gr Congestion due to HLR Reset The Gsc/ Mc rstMsgs counter increments each time a reset message is received from HLR. Each receipt of such a message indicates the HLR has reset. If this number is incrementing, the HLR should be investigated. Each mobile attached that is on that HLR will require an Update GPRS Location message to be sent to the HLR causing the Gsc/ Hlrc recordsdToBeReset counter to rapidly increase.

2.6.2.3 Gr HLRC Congestion The Gsc/ HlrC recordsWaitingForHlrConf counter can give an indication increased response times between the SGSN and the HLR. A rapidly increasing counter can indicate either congestion on the link or increased mobile activity.

2.6.2.4 Gr SMS Congestion Monitoring The Tcap/ Map rfSmTimeouts counter is incremented when a �Ready For Short Message Acknowledge� is not received from the HLR. A rapidly increasing counter can indicate either congestion on the link or a communication failure.

2.7 Gs Interface The Gs interface enables an association to be made between the MSC/VLR and SGSN. It is used to co-ordinate the location information of MSs that are IMSI attached to both GPRS and non-GPRS services. This association is required for providing combined GPRS and Circuit Switch capability in the network. Support for Gs is facilitated by the following network elements: MS, BSS, SGSN, SIG, and MSC/VLR. The Gs interface is instrumented through the following functional components: Gsd/ Llc (3.3), Gsc/ Gmm (3.2), Gsc/ Bssap (3.2), and Gips (3.1). The guidelines in the following sub-sections can be used to monitor the Gs Connection to SIG (3.11) issues.

2.7.1 Gs Connectivity Monitoring A combined attach will succeed partially without the Gs interface although GMM will try to used the failed connection; however, the mobile will be only packet attached. The Gsc/ Imsi/ Bssap gsState attribute will indicate the MSC/VLR that the mobile is attached to if combined attach succeeded.



2.7.1.1 Connectivity to SIG The SGSN Passport obtains access to the SS7 network via the SIG. The health of TCP/IP connection between the Gsc/ Bssap and the SIG can be monitored by looking at the Gsc/ Bssap component�s operationalState attribute. An Operational State of Enabled indicates the TCP/IP socket connection to the SIG exists. The OsiState of the Gsc/ Bssap Ss7ipIf component also becomes Disabled when there is no TCP connectivity to the SIG. This is accompanied by a Critical Set (Loss of Connection with SIG Alarm: 7068 1523) alarm raised against the Gsc/ Bssap Ss7IpIf/ component. Refer to the GIPS (3.1) section of this document for Monitoring GIPS. In addition to TCP/IP socket connectivity, the Gsc/ Bssap must be successfully registered with the SIG. A rapidly increasing Gsc/ Bssap sigRegisterFailures attribute indicates that the GSC can not register; the SIG (3.11.1.1.1) or TCAP (3.10) should be investigated.

2.7.1.2 Connectivity to MSC/VLR Whenever the MSC/VLR resets, the MSC/VLRsends a �Reset Indication� message to the SGSN. This Reset message is counted by the Gsc/ Bssap vlrFailures counter. Consequently, if this counter is pegging then it indicates problems exist with the MSC/VLR and the MSC/VLR should be investigated. This counter is incremented if MSC side has come back up. If MSC went down and stayed down this counter would not increment.

2.7.2 Gs Activity Monitoring The Gsc/ Bssap gsAssociatedCurrent attribute displays the number of mobiles currently in a combined attach per MSC/VLR. The Gsc/ Bssap counters -- gprsDetachMaxAttempts, explicitImsiDetachMaxAttempts, implicitImsiDetachMaxAttempts, sgsnResetMaxAttempts -- increment each time the SGSN has exhausted retried on a message transaction. When these counters rapidly increase, either congestion or connectivity can be the cause.

2.7.3 Gs Congestion Monitoring The Gsc/ Bssap component has many timeout counters that can be used to indicate congestion. The timers associated with these counters are used by the Bssap layer when it sends messages to the MSC/VLR via the SIG. The timeouts will occur if the Bssap does not receive the expected response messages from the MSC within the expected timeframe. This situation could be the result of congestion in the network. The following



timeout counters on Gsc/ Bssap can increase due to congestion: T8Timeouts, t9Timeouts, t10Timeouts, t12Timeouts.

2.8 LICP Interface The Lawful Intercept Common Protocol (LICP) is used to interface between the Lawful Intercept Access Function (LIAF) application on the SGSN and the external Lawful Intercept Gateway (LIG). The LIAF receives administrative function (ADMF) commands through this interface, instructing the LIAF to collect information about one or more targeted subscriber�s activities. This interface is also used to transfer the intercepted subscriber data to the LIG delivery function (DF). The LICP interface is TCP/IP based, with the LIAF application on the SGSN acting as the client while the LIG acts as the server. The ADMF and DF share the same IP address on the LIG, however they use different ports. The LIAF application communicates to the LIG through the Ethernet port on the SAS/LI card. TCP/IP functionality is provided by GIPS on the SAS/LI card.

2.8.1 LICP Connectivity Monitoring If connectivity to the ADMF of the LIG is lost, a Major Set alarm (Loss of Communication with LIG ADMF Alarm: 7068 1527) is raised against the Liaf/ component. In addition the Liaf/ operationalState attribute transitions to disabled. When the LIAF re-establishes TCP/IP communication with the LIG, this alarm is cleared and the operationalState transitions back to enabled. If connectivity to a DF is lost, a Major Message alarm (Loss of Communication with LIG DF Server Alarm: 7068 1528) is raised to denote the problem. The Liaf/ operationalState attribute remains enabled when DF communication loss is detected.

2.8.2 LICP Activity Monitoring Refer to the GIPS Functional Component section (3.1.2) for information on monitoring packet activity on the TCP/IP interface. Refer to the LIAF Functional Component section (3.7) for information on monitoring LIAF application activity.

2.8.3 LICP Congestion Monitoring The Liaf/ bufferOverFlows counter is incremented each time a TCP buffer overflow is detected. If this counter is incrementing frequently, then it is an indicator of ongoing congestion.



Congestion can be monitored by observing the CPU usage on the card where GIPS is provisioned. Refer to (3.1.3) section for more detail.



3 Functional Components 3.1 GPRS IP Server (GIPS) Monitoring

GPRS IP Server (GIPS) provides host TCP/IP and UDP/IP services for the SGSN node. It allows applications to exchange data frames through a TCP/IP or UDP/IP stack with its peer entity on an IP network. The IP Server component relies on the Passport Virtual Router software. There is no state attribute for the GIPS component therefore no alarms can be initiated by it.

3.1.1 GIPS Connectivity Monitoring The GIPS component does not provide information for monitoring connection loss but the VirtualRouter (VR) component provides enough information to indicate the connectivity of GIPS. The Vr/ Pp/ operationalState in the enabled state, indicates an operational GIPS component. GIPS registers with the VR at initialization at which time it registers for a port. A failed port registration for port/n is indicated by absence of the port/n subcomponent instance on either the Gips/ Ip/ Tcp or the Gips/ Ip/ Udp component. An increasing Vr/ Ip tcp attemptFails or inErrs counter for a TCP connection or an increasing Vr/ Ip Udp inErrors for a UDP connection could indicate a failed GIPS connection. The more obvious monitoring of GIPS connectivity is on the applications using GIPS. Without a GIPS connection, all incoming and outgoing datagrams will fail. The first indication of a GIPS connection failure will first be indicated on the following applications: GSC (3.2), GSD (3.3), DNS Agent (3.5), SAS (3.9), and Map/Tcap (3.10). The impact to each component is described below. The GSC (3.2) application will fail to establish any sessions through PDP Context Activations (4.4) due to the failure of the GTP protocol used to communicate with the GGSN across the Gn (2.5) interface. The IRAU (4.2) procedure, also serviced by the GSC, will fail for the same reason as the Context Activation. Combined attaches (4.1) and CAMEL activations (4.5) will also fail because of the failure of the Gs (2.7) and Ge (2.4) interfaces respectively. The DNS Agent (3.5), provisioned on the GSC card, will fail to resolve Access Point Names (APNs) and Routing Areas (RAs) when GIPS fails unless the resolution has been saved in static or dynamic cache.



The GSD (3.3) application will fail to transfer data for a single session. Data transfer in one direction but not in the other direction can also be a problem with the GIPS or Virtual Router. The TCAP/MAP (3.10) card will fail to communicate over Ge (2.4), Gr (2.6), and Gd (2.3) interfaces. CAMEL activations (4.5), attaches (4.1), and SMS (4.7) services will fail due to the lost connectivity. An application must be successfully registered with GIPS in order to use it. Applications are associated with GIPS through provisioning. At initialization time GIPS attempts to register each application�s protocol port with the VR software. If this registration fails, it can be detected by listing the Gips/ Ip/ Tcp Port/ components and Gips/ Ip/ Udp Port/ components. The absence of a Port/ instance indicates the registration failed for that port.

3.1.2 GIPS Activity Monitoring The GIPS component indicates the number of packets that are passed through the component. Incrementing Gips/ Ip/ inDelivers and outRequests counters indicate activity on the GIPS.

3.1.3 GIPS Congestion Monitoring Congestion on the GIPS component can best be indicated through the applications that use it as stated in the connectivity section above. Congestion can also be monitored by the CPU usage on the card where GIPS is provisioned. Refer to LP (3.8) section for more detail.

3.2 GSC Monitoring

3.2.1 GSC Instance Monitoring In order to have a functional SGSN it is mandatory to have at least one instance of a GSC application registered with the Nodal Manager. If this criteria is not met, a Critical Set alarm (Nodal Manager Critical Component Missing Alarm: 7068 1025) is raised against the Sgsn component. This alarm is cleared when at least one GSC registers with the nodal manager. Nodal Manager Registration takes place at GSC initialization time.

3.2.2 GSC Connectivity Monitoring The GSC is responsible for establishing ATM SVC connections between itself and the GTD, MAP and SAS applications. If the GSC is unable to establish an SVC connection or the SVC connection goes down a Major Set alarm (GSC/GSD SVC Audit Failed Alarm: 7068 1024) is raised against the Gsc/ component. The GSC continuously retries



establishing the SVC connection until it is successful. When the Svc connection is re-established the outstanding Set alarm is cleared.

3.2.3 GSC Congestion GSC congestion is best monitored from a service perspective; refer to Services section (4) for more detail. For card related congestion monitoring, refer to the LP section (3.8).

3.2.4 GSC Out of Resources The GSC card has a finite amount of memory allocated for processing. When these resources are exhausted, a Major Message alarm (GSC Memory Exhausted Alarm: 7068 1005) is raised. The engineered provisioning values may need to be increased or additional GSC cards inserted into the shelf. The GSC monitors the availability of its finite number of Context resources. These include Primary Context, Attach Context, RAU Context, User Requested Security Context, Security Context, Suspend Resume Context, Reset context, Paging Context and Assignment Context. When the number of Contexts in use exceeds 80% of the maximum, the GSC raises a Major Set alarm (GMM Context Resources Low Alarm: 7068 1996) against the Gsc/ component. This alarm is cleared when usage falls below 75%. If this alarm is active it indicates the GSC is approaching its resource limits. The GSC also monitors the CPU usage on the GSC card to determine if the limits of this resource are being reached. If the GSC determines that CPU usage exceeds 80%, a Minor Set alarm (GSC CPU Overloaded Alarm: 7068 1521) is raised against the Gsc/ component. If usage exceeds 85% the severity is increased to Major. If the 90% threshold is crossed the alarm severity becomes Critical. The alarm severity is reduced to Major, Minor and Cleared when usage falls below 88%, 83% and 78% respectively.

3.2.5 Map Client Monitoring

3.2.5.1 Monitoring for SIG Registration The Map Client must be registered with the SIG before it can provide access through the Gd and Gr interfaces. If the Gsc/ Mc sccpServiceRequestTimeouts counter is rapidly increasing, it means MapClient is unable to register with SIG due to either SIG or TCAP problems. This can have an affect on Mobile Attaches (4.1) completing. If the MapClient has registered with the SIG and the connection between the TCAP/MAP card and SIG goes down, the Gsc/ Mc operationalState attribute



remains enabled. However, the Tcap/ Map operationalState will become disabled, until the MAP card is able to successfully re-register with the SIG. Refer to the TCAP/MAP Card (3.10) section for information on how to monitor that card.

3.2.5.2 Monitoring Map Client Message Delivery An activeGsc/ Mc systemFailureRespSent counter, can be an indication of message handling problems caused by issues on the Map Client side. Message handling problems on the HLR or SMSC side or routing problems in SS7 network will cause the Gsc/ Mc systemFailureRespRecv and Tcap/ noticeRecieved counters to rapidly increase. Both Gr and Gd interfaces can be affected by this type of problem. A Minor Message alarm (Map Notice Indication Display Alarm: 7068 1520), sent every 60 minutes, gives the count of all MAP messages destined for the SS7 network. The Gsc/ Mc raises a Warning Message alarm (Invalid PDP Context Received Alarm: 7068 1529) whenever it receives an Insert Subscriber Data message from the HLR and upon passing the data to the HLR Cache, is told that the data is in error. This is indicative of a PDP Context provisioning problem on the HLR.

3.2.5.3 Monitoring Map Client Congestion An active Gsc/ Mc uAbortMsgRecv counter can be an indication of HLR congestion due to resource exhaustion. If the Gsc/ Mc uglMsgs and Gsc/ Mc uglResponseMsgs counters are not increasing in an approximately parallel fashion, then messages are being sent to HLR but no response is being received in return. An active Gsc/ Mc uAbortMsgSent counter indicates SGSN congestion due to resource exhaustion. The resources allocated for Map Client transactions are monitored by the Gsc/ Mc currentTransactions counter. When all allocated resources are exhausted, a Critical Set alarm (Map Client out of Resources Alarm: 7068 1511) is displayed. The alarm is an indication of a high level of Gr and Gd activity. Refer to Gr Congestion due to HLR Reset (2.6.2.2) for additional congestion monitoring.



3.2.5.4 SMS Specific Monitoring on Map Client The Map Client has a few SMS specific counters. These are used to track how many SMS related messages are sent and received between the GSC and IWMSC via the SIG. These can be monitored in the following way:

o The Gsc/ Mc ofSmMsgs and the Gsc/ Mc ofSmResMsgs counter not

incrementing at the same rate, means GSC is sending messages to MSC but it is not receiving responses in return. This can be an indication of a Gd link failure.

o The Gsc/ Mc rsmMsgs and the Gsc/ Mc rsmResMsgs counters not incrementing at the same rate, means GSC is sending messages to HLR but it is not receiving responses in return. This can be a indication of a Gr link failure

3.2.6 Overload Control Monitoring The GSC has the ability to shed attach, IRAUs and activation request when the card determines that it is overloaded. When any procedure is being discarded, a Major Message alarm (GSC Overload Alarm: 7068 1496) is activated. For CPU overload conditions the Gsc cpuOvldAttachesDiscarded attribute is incremented for each attach request that is discarded while the Gsc cpuOvldActivationsDiscarded is incremented for each activate request that is discarded. For memory overload conditions the Gsc subCountOvldAttachesDiscarded attribute is incremented for each attach request that is discarded.

3.3 GSD Monitoring The Major Message alarm (Maximum Subscribers Reached Alarm: 7068 1009) on a GSD, where other GSDs are not in �Maximum Subscribers Reached� overload condition, can be an indication to a GSD application or load balancing problem amongst the GSDs. The Major Message alarm (GSD Maximum Allocated LLEs Reached Alarm: 7068 1012) is raised when maximum allocated Logical Link Entities (LLE) limit is reached. This impacts PDP Context Activation (4.4) and SMS (4.7). GSD application uses the GIPS application for Gn interface (2.5) connectivity; refer to GIPS (3.1) sections.



3.3.1 GSD Instance Monitoring In order to have a functional SGSN it is mandatory to have at least one instance of a GSD application registered with the Nodal Manager. If this criteria is not met, a Critical Set alarm (Nodal Manager Critical Component Missing Alarm: 7068 1025) is raised against the Sgsn component. This alarm is cleared when at least one GSD registers with the nodal manager. Nodal Manager Registration takes place at GSD initialization time.

3.3.2 GSD Connectivity Monitoring The GSD is responsible for establishing an ATM SVC connection between itself and the GTL applications. If the GSD is unable to establish the SVC connection or the SVC connection goes down a Major Set alarm (GSC/GSD SVC Audit Failed Alarm: 7068 1024) is raised against the Gsd/ component. The GSD continuously retries establishing the SVC connection until it is successful. When the Svc connection is re-established the outstanding Set alarm is cleared.

3.3.3 Congestion on GSD If GSD Downlink Buffering is not active then Gsd/ DBuff component is not present and Message alarm (GSD Downlink Buffer Component Add Failed Alarm: 7068 1021) is raised against the Gsd/ component. With downlink buffering absent, downlink packets are not buffered when GTL is congested and can�t support additional packets. The packets are discarded by the GSD application. The presence of a Gsd/ DBuff component indicates downlink buffering is active for the GSD. The operator can display the totalDiscardsDueToMaxBytes and totalDiscardsDueToMaxPackets, totalDiscardsDueToBucketFull and totalDiscardsDueToBvcBlocked to determine if the buffers have reached their maximum capacity. These counters are incremented each time the GSD must throw away packet data because of full buffers. If these counters are incrementing it is a sign of congestion. If GSD Hardware Ciphering function is down, then software ciphering is used. A Major Message alarm (GSD PDA Failed Alarm: 7068 1022) is raised to indicate the switch back. Congestion on the GSD data path can be indicated by Gsd/ Sndcp discardedNpdusFromMS counter. However, this counter also indicates packets being discarded due to lost fragments when reassembled by GSD. The Major Message alarm (Maximum Active Subscribers Reached Alarm: 7068 1009) indicates GSD memory resources are exhausted and no more subscriber attaches can be performed by this card.



GSD congestion should also be monitored from a service perspective, refer to Services section (4). For card related congestion monitoring, refer to the LP section (3.8).

3.4 GTL Monitoring The GTL card hosts the Frame Relay base Passport layer, NS Layer and BSSGP layer applications (see Figure 2). NS Layer is based on GSM 08.16 (1.9) and the BSSGP layer based on GSM08.18 (1.9). Please refer to the respective sections under the Gb section (2.2). The GTL application supports NSE redundancy which provides the ability for a single NSE to exist across multiple GTLs. This provides extra protection as the redundant GTL can take over if the other GTL fails. An internal audit/recovery facility exists to maintain the sanity of the system. These audits ensure the NSVC, BVC and flow control information at the GSD matches that of the GTL. It also checks that the associated GTLs are synchronized with the same information. Thirdly, it attempts to detect and rectify BVC state mismatches between GTL and PCU.

3.4.1 GTL Instance Monitoring In order to have a functional SGSN it is mandatory to have at least one instance of a GTL application registered with the Nodal Manager. If this criteria is not met, a Critical Set alarm (Nodal Manager Critical Component Missing Alarm: 7068 1025) is raised against the Sgsn component. This alarm is cleared when at least one GTL registers with the nodal manager. Nodal Manager Registration takes place at GTL initialization time.



3.5 DNS Agent Monitoring

Query 2

SGSN

Cache

Name Server

DB

Query 1

Response1

Application DNS Agent

Response2

DNS Agent acts as a client to the DNS Name Server. It acts as a service provider to applications (Session Management) on the SGSN and provides the GGSN IP addresses. For example, SGSN SM needs a GGSN IP address based on the user provided or SGSN selected APN (Access Point Name). The DNS Agent provides the IP addresses to SM via APN-IP mapping. The APN-IP mappings can be provisioned statically on the DNS Agent or they can be dynamically looked up by querying an external Name Server. Dynamic lookups are cached locally on the DNS Agent.

3.5.1 DNS Agent Connectivity Monitoring A Set alarm (Loss of Communication with the DnsAgent Servers Alarm: 7068 1522) is raised against the DnsAgent/ if it is unable to communicate with at least one provisioned Name Server. The severity of the alarm is Major if the DNS Agent supports static queries. Otherwise the severity is Critical. The DnsAg/ operationalState is set to disabled if the severity is Critical. In the Major alarm case the component state remains enabled. The DNS Agent decides it is unable to perform dynamic lookups if queries to all the name servers either resulted in timeouts and/or Server Failure responses, or GIPS (3.1) is unavailable or ICMP errors are detected. It is important to keep in mind that the



DNS Agent makes its assessment on a client query basis. It does not monitor Name Server availability in real-time. In other words, the DNS Agent must be requested by GSC to do an APN-IP mapping, and in the process of carrying out this request if the DNS Agent determines it cannot perform the dynamic lookup, it sets the alarm. This same latency characteristic also applies to the alarm clearing process. If the DNS Agent has multiple Name Servers provisioned and determines that it has lost Name Server redundancy, a Minor Set alarm (Loss of Redundancy with the DnsAgent Servers Alarm: 7068 1530) is raised against the DnsAg/ to denote the problem. A rapid increase in DnsAg/ serverQueryTimeouts, or DnsAg/ serverQueryFailures counter can be an indication of a connectivity problem. DNS Agent connectivity problems impact PDP Context Activation (4.4.3) and IRAU activations (4.3) if the required IP address is not already stored in Static and Dynamic memory cash. An active Gsc/ Sm missingOrUnknownApn counter will typically accompany the dynamic lookup problems. This counter is pegged when the GSC receives a failure response from the DNS Agent.

3.5.2 DNS Agent Activity Monitoring A good indication for stable activity is if the DnsAg/ clientQueries counter is equal to the sum of DnsAg/ cacheHits and DnsAg/ serverQueries. This calculation is based on the presupposition that when an application makes a request, the DNS Agent either satisfies the request from its cache or sends a request to the Name Server.

3.5.3 DNS Agent Congestion Monitoring The counter DnsAg/ serverPendingQueries indicates the number of queries that the DNS Agent has made to the Name Server for which it has not yet received a reply back, or it has received a reply but can not process it due resource exhaustion. A high value or a rapidly increasing counter value can indicate congestion problems either on the network or on SGSN.

3.6 Inter-shelf Communication Monitoring An OC3 card on the 7K shelf and a 4pOC3 card on the 15K shelf physically connect the two shelves for inter-shelf communication. Nodal manager uses ATM point-to-point Switched Virtual Circuits (SVCs) to communicate with other applications. An ATM Private-Network-to-Network-Interface (PNNI) must be provisioned to provide dynamic routing and signaling for SVC establishment.



P P 8 K P P 15 K

CP -NM

MSA (GTL)

MSA (GTL)

GSD

GSD

GSD

GSD

GSD

GSD

OC3

OC3

LAN

LAN

CP - NM

CP3 - NM

CP3 - NM

Empty 4pOC3 GSC (2pGpDsk)

GSC (2pGpDsk)

4pOC3 Empty

Empty

Empty Empty Empty SAS (2pGpDsk)

SAS (2pGpDsk)

Empty Empty

Figure 5 Multi shelf VSS configuration

3.6.1 Inter-shelf Connectivity Monitoring The connection between the shelves is represented by the Lp/ Sonet/ Sts/ provisionable component on the Passport 15k shelf and Lp/ Sonet/ Path/ provisionable component on the Passport 7k shelf. If either component indicates a disabled operationalState, the physical connection may be the cause and should be checked. A disabled operationalState on any of the Atmif/ Vcc/ component instances indicates that the associated application is not receiving data. The Minor Set alarm (ATM Alarm: 7039 1000) under Fratm/ indicates that there is a problem on one of the connections. Bandwidth problems on a particular Vcc are indicated by the Minor Set alarm (ATM Alarm: 7039 2000). Re-configure the bandwidth until the total provisioned bandwidth of all connections on this interface falls within the maximum bandwidth limit that the interface can support. The ATM connection does not send data if the operationalState of the Atmif/ component is disabled. A Major Set alarm (ATM Networking Alarm: 7041 0150) under the Atmif/ Pnni component indicates that the signaling channel or the Rcc connection is down. The operationalState of Atmif/ Pnni rcc should be in the enabled state for proper operation.



A Major Message alarm (ATM Networking Alarm: 7041 0251) under the Atmif/ Pnni rcc component indicates that the Vcc used for the Rcc channel has failed. The operationalState of the Atmif/ Vcc/ should be in the enabled state for proper operation. Raconn is a component that links applications across shelves. The applications requiring the Raconn component are GSC (3.2) and GSD (3.3). An enabled operationalState indicates connectivity between the applications.

3.6.2 Inter-shelf Activity Monitoring Activity on the ATM connection can be checked for received and transmitted directions. Received packets are indicated by an increasing Atmif/ Vcc/ rxCell counter; transmitted packets are indicated by an increasing Atmif/ Vcc/ txCell counter. If for a particular Vcc/ traffic is being transmitted but not received, we can deduce that the other end is not receiving the data. The Minor Message alarm (ATM Alarm: 7039 4000) under Atmif/ indicates an LRC error during frame transmission. LRC errors may be caused either by defective hardware somewhere in the network, or by transient network conditions, such as the removal or insertion of a card, resetting of a card, enabling or disabling of a bus, running of a bus test, or enabling or disabling of an ATM connection. Check to see if any such transient condition occurred around the time of the alarm; if so, correct the destabilizing condition. Continue to monitor the situation to see if additional LRC error alarms occur; if this alarm continues to appear, or if Major alarm (ATM Alarm: 7039 4001) is raised, apply the Diagnosing LRC Errors procedure documented in NTP 241-5701-715 Passport 7400,15000, 20000 ATM Monitoring and Troubleshooting Guide.

3.6.3 Inter-shelf Congestion Monitoring When congested, the OC3 and 4POC3 cards will discard ATM cells. Discarded cells during transmission are indicated on the Atmif/ Vcc/ component specifically the txCellDiscard, txCellDiscardClp, txFrameDiscard, & txFrameDiscardClp attributes. Discarded cells during reception are indicated on the Atmif/ Vcc/ component specifically the rxCellDiscard, rxCellDiscardClp, rxFrameDiscard, & rxFrameDiscardClp attributes. The Minor Message alarm (ATM Alarm: 7039 2001) under Atmif/ Vcc/ indicates a possible memory exhaustion problem. Deleting one or more connections may clear this alarm. A Critical Set alarm (ATM Alarm: 7039 5000) is raised if the link utilization has exceeded the capacity threshold.



3.7 LIAF Monitoring The Lawful Intercept Access Function (LIAF) provides the ability to monitor subscriber activity and communicate this information to an external Lawful Intercept Gateway. The LIAF communicates with the LIG over the LICP interface. Refer to section (2.8) for information on monitoring the health of the LICP interface. The LIG Administrative Function (ADMIF) sends provisioning instructions to the LIAF identifying targeted subscribers. The LIAF monitors these subscribers activity when they are attached to the network and passes the relevant information on to the LIG Delivery Function (DF).

3.7.1 LIAF Instance Monitoring The LIAF is an optional SGSN component, in the sense that the SGSN can still function and process calls without this application being provisioned. However, in practice it is quite likely that the LIAF is present on the SGSN. Therefore, if the SGSN detects that no LIAF applications have registered with Nodal Manager, a Minor Set alarm (Nodal Manager Non-critical Component Missing Alarm: 7068 1026) is raised against the Sgsn component. This alarm is cleared when at least one instance of LIAF has registered with the Nodal Manager. Nodal Manager Registration takes place at LIAF initialization time.

3.7.2 LIAF Connectivity Monitoring Refer to the LICP Interfaces section (2.8.1) for information on monitoring connectivity to LIG.

3.7.3 LIAF Activity Monitoring The operator can determine if the LIAF is currently monitoring subscribers by displaying the Liaf/ usageState attribute. If the value of this attribute is idle, this indicates there are no subscribers currently attached that are being monitored. If the value is active, this indicates there is at least one attached subscriber that is being monitored. If the value is busy, then the maximum number of subscribers is being monitored. Refer to section (2.8.2) for information on monitoring activity on the LICP interface between the LIAF and LIG.

3.7.4 LIAF Congestion Monitoring The maximum number of subscribers the LIAF can monitor simultaneously is specified through provisioning. If the LIAF reaches this provisioned maximum, a Major Set alarm (LIAF Maximum Subscribers Reached Alarm: 7068 1525) is raised against the Liaf/ component to denote the capacity limit has been reached and the Liaf/ usageState attribute is set to busy.



Refer to section (2.8.3) for information on monitoring congestion on the LICP interface between the LIAF and LIG.

3.8 Logical Processor (LP) Monitoring All cards, no matter their function or software load, contain basic information about the health and operation of the hardware. For the passport equipment the LP, with a parameter referring to the card to be queried, displays this basic operating information. The fields most relevant to the stability of each card are operational state of the card, CPU utilization and memory usage on each card.

3.8.1 LP Activity Monitoring The operationalState attribute indicates the ability of the card to process messages. If the operational state is other than enabled, the card is not processing calls or receiving messages. The provisioning should be checked and the card scrutinized for the outage reason. A reset, as a last resort, may solve this problem.

3.8.2 LP Congestion Monitoring The ability for a card to process incoming and outgoing messages can be inferred from the CPU utilization fields. The card gets congested when incoming messages are received faster than the card can process them. Link congestion may cause LP congestion by causing higher back-plane traffic (due to retry attempts) and active retry timers. Congestion may be inferred if the cpuUtil attribute value increases significantly above the cpuUtilAvg attribute value. A Minor Set alarm (Traffic Management Alarm: 7013 0022) indicates that the card is in congestion due to local message block congestion. Congestion may cause some pre-allocated memory to be exhausted; however, some memory pools are allowed to grow as congestion occurs. When congestion causes memory usage to increase, the memoryUsage normalRam attribute value will increase.

3.9 SAS Monitoring

3.9.1 SAS Instance Monitoring The SAS is an optional SGSN component, in the sense that the SGSN can still function and process calls without this application being provisioned. However, in practice it is quite likely that the SAS is present on the SGSN. Therefore, if the SGSN detects that no



SAS applications have registered with Nodal Manger, a Minor Set alarm (Nodal Manager Non-critical Component Missing Alarm: 7068 1026) is raised against the Sgsn component. This alarm is cleared when at least one instance of SAS has registered with the Nodal Manager. Nodal Manager Registration takes place at SAS initialization time.

3.9.2 SAS Hard Disk Alarms The following alarms occur if there are problems with the SAS hard disk. CDRs are stored on the hard disk first, then transferred to the CGF, and finally deleted from the disk. If alarms occur on the hard disk it is possible that CDRs are affected depending on the type of alarm. Please refer to the NTP 411-5221-501 UMTS/GPRS Core Network Troubleshooting Guide for more information on these alarms and possible corrective action. The SAS Disk Usage Set Alarm (SAS Disk High Usage Alarm: 7068 1001) is raised to notify that the disk is filling up with CDRs. The severity of this alarm is Minor, Major or Critical depending upon whether the 85%, 90% or 99% threshold has been crossed respectively. The alarm is cleared when disk space falls below 75%. If the disk is almost full, it is an indication that there is a problem with transferring CDRs to the CGF. When CDRs are not being transferred in a timely manner, the disk can fill up. However, it typically takes several days of busy hour traffic to fill up the disk. If the Critical threshold is reached there is a serious risk of not being able to store any more CDRs. Corrective action must be taken immediately to either clear files from the disk or switch over to the redundant SAS card. Sas/ raises a Critical Set alarm (SAS Disk Failure Alarm: 7068 1002) if it detects a disk access error. A disk failure alarm constitutes a critical failure and prevents CDRs from being stored and transferred to the CGF. This alarm can only be cleared by reinitializing the Sas application. Above alarms can be an indication of file transfer problems to CGF which would result in a backlog of CDR build up on the disk. Please refer to NTP 411-5221-500 SGSN Alarm Reference Manual for more details.

3.9.3 Monitoring SAS Activity The SAS CDR statistics can be used to monitor if the SAS application is actively processing CDRs or if a problem is causing the CDR processing to be interrupted.



3.9.3.1 Open CDR counts The following counters on Sas/ component increment for each event that triggers a CDR to be opened:

• openScdrs - count of CDRs opened resulting from a PDP context activation • openMcdrs - count of CDRs opened resulting from a mobile attach

These counters represent the number of CDRs that are opened and resident in SAS memory until an event occurs that results in closure. The counts are historical and increment when each CDR is opened. If the system is actively processing attaches and activates, these counts should always be increasing; otherwise there is likely a problem with the SAS application. This assumes that both M-CDRs and S-CDRs are enabled.

3.9.3.2 Closed CDR counts The following counters on Sas/ component increment for each event that triggers a CDR to be closed:

• closedScdrs - count of CDRs closed resulting from a PDP context deactivation • closedMcdrs - count of CDRs closed resulting from a mobile detach • smoCdrs - count of mobile originated CDRS for SMS • smtCdrs � count of the mobile terminated CDRS for SMS

These counters represent the number of CDRs that are closed and written to disk. When a transfer cycle occurs, the CDRs are transmitted to the CGF and, after an acknowledgment is received, are removed from the disk. If the system is actively processing detaches and deactivates then these counts should always be increasing. Otherwise there is likely a problem with the SAS application. This assumes that both M-CDRs and S-CDRs are enabled. Please refer to NTP 411-5221-060 SGSN Components Reference Manual and NTP 411-5221-501 UMTS/GPRS Core Network Troubleshooting Guide for more details on the above counters.

3.9.3.3 Indications that SAS is actively generating CDRs � M-CDR In order to verify if the SAS application is actively generating M-CDRs and working properly for mobility events:

• First, check to determine if M-CDRs are provisioned via Sgsn Acct cdrCapture attribute.



• Second, check that the Gsc/ Gmm detachesSuccessful counter is increasing. If it is, then check that the corresponding Sas/ closedMcdrs counter is increasing. If these counters indicate that successful detaches are occurring but M-CDRs are not generated, then it is likely that SAS has a problem.

3.9.3.4 Indications that SAS is actively generating CDRs � S-CDR In order to verify if the SAS application is actively generating S-CDRs and working properly for session context events:

• First, check to determine if S-CDRs are provisioned via Sgsn Acct cdrCapture attribute.

• Second, check that the Gsc/ Sm mobileInitDeacts and ggsnInitDeacts

counters are increasing. If they are, then check that the corresponding Sas/ closedScdrs counter is increasing. If these counters indicate that successful deactivations are occurring but S-CDRs are not generated, then it is likely that SAS has a problem.

3.9.4 Affects of Node Failures on SAS

3.9.4.1 GSD Failure A GSD failure impacts all of the active PDP contexts. As a result GSC will delete all of the PDP contexts associated with the failed GSD on a context-by-context basis as mobiles reactivate. SAS will respond to these new activations; it closes the obsolete S-CDRs associated with the failed GSD and marks these with an abnormal release reason. All CDR information associated with the failure that has not been written to disk will be lost. If partial billing records are enabled, then the only billing data that will be lost is information collected since the last partial record was generated.

3.9.4.2 GSC Failure When the GSC fails, all sessions and mobility contexts hosted by the GSC are discarded. SAS is not explicitly notified of GSC failure, but uses audits and IMSI verification to clean-up after GSC failures.



The SAS clean-up of CDRs results in CDRs that are closed with an abnormal release reason code. If partial billing records are enabled, then the only billing data that will be lost is information collected since the last partial record was generated.

3.9.4.3 GGSN failure When the GGSN fails all session contexts associated with the failure are lost. The GSC is notified and when mobiles reactivate, SAS will in turn respond with deleting the obsolete S-CDRs associated with the GGSN failure and marking them with an abnormal release reason. If partial billing records are enabled, then the only billing data that will be lost is information collected since the last partial record was generated.

3.9.5 SAS Failure A failure of the SAS card results in loss of all CDRs that are currently open. If there is a cold standby SAS card configured then the standby card will initialize and begin to process new billing transactions once it is up and running. If the failed SAS card is still viable, there are recovery procedures to claim CDRs from the disk. Please refer to NTP 411-5221-955 Passport 15000-VSS with SGSN Functionality User Guide for more details on the above node failure topics.

3.10 Tcap and Map Stack Monitoring

3.10.1 Tcap/Map Instance Monitoring In order to have a functional SGSN it is mandatory to have at least one instance of a Tcap/MAP application registered with the Nodal Manager. If this criteria is not met, a Critical Set alarm (Nodal Manager Critical Component Missing Alarm: 7068 1025) is raised against the Sgsn component. This alarm is cleared when at least one Tcap/Map registers with the nodal manager. Nodal Manager registration takes place at Tcap/Map initialization time.



3.10.2 Monitoring For Connectivity The connectivity between the Map card and the SIG can be determined by displaying the OSI state of the following components:

• Tcap/ • Tcap/ Ss7IpIf/ • Tcap/ Map

Each of these components represents a layer in the protocol stack used to talk to SIG. The SCIP layer, represented by the Tcap/ Ss7IpIf/ component, is the lowest layer. The next higher layer is TCAP (Tcap/). Above TCAP lies the MAP layer (Tcap/ Map). The Operational State of a give layer depends upon the Operational State of the layer beneath. The operationalState of Tcap/ Ss7IpIf/ component is enabled if the TCP connection to the SIG is established. The Tcap/ operationalState is enabled when TCAP has successfully initialized and the Tcap/ Ss7IpIf/ is enabled. The Tcap/ MapStack operationalState is enabled if Tcap/ Ss7IpIf/ and Tcap/ are enabled, and the GSC Map Client (Gsc/ Mc) has successfully registered with the SIG. If any of the above components is in the disabled state then there is no connectivity to the SIG. A Critical Set alarm (Loss of Connection with the SIG Alarm: 7068 1523) is raised against the Tcap/ Ss7IpIf/ component whenever the TCP connection to the SIG is lost and the Tcap/ Ss7IpIf/ operationalState is disabled. The alarm is cleared when the connection is reestablished and the operationalState indicates enabled once again. The Map Client on the GSC is affected by failures on the MAP card. Refer to section (3.2.5) for information on GSC Map Client monitoring. If the connection state between the MAP and SIG is disabled then mobile attaches fail (4.1). The OSI state of the ss7IpIf subcomponent of the TCAP component mentioned above only cover the scenarios where the TCP connection between the MAP/TCAP card and the SIG is actively closed on the SIG side. For example:

• When the KeepAliveTimer in the SIG for that TCP connection expires (in this case a SIG log will also be generated in the SIG log file)

• When the SIPR process in the SIG dies (in this case the TCP connection should be re-established very quickly because the SIPR process is automatically restarted)

• When the Duplex SIG has undergone a switch-over (in this case it might take up to 30 seconds for the TCP connection to be re-established after the SIG switch-over is finished)



However, there are scenarios where the TCP connection between the MAP/TCAP card and the SIG is broken and the MAP/TCAP card will not detect for up to several hours. For example:

• When the Ethernet cable between the MAP/TCAP card (via the LAN card in the 7K Passport) and the SIG is yanked, Passport Base will generate a generic Critical Set alarm (Common Alarm: 0000 1000).

• In the same scenario as mentioned above, a SIG log will be sent to the SIG log file when the KeepAliveTimer in the SIG expires for that TCP connection caused by missing heartbeat messages from the MAP card.

It is necessary that MAP, MSC and CAP subsystem bind operations take place before the subsystem traffic can flow. If the MAP subsystem fails its bind operation a Minor Set alarm (SGSN MAP Subsystem Bind Failed Alarm: 7068 1515) is raised against the Tcap/ Map component. If this alarm is raised, the SGSN MAP subsystem cannot be used and any MapClient trying to register with this SGSN MAP subsystem will receive a registration failure response. If the MSC subsystem is unable to successfully bind a Minor Set alarm (SGSN MSC Subsystem Bind Failed Alarm: 7068 1516) is raised against the Tcap/ component. If this alarm is raised, the SGSN MSC subsystem cannot be used and any Map Client trying to register with the MSC subsystem will receive a registration failure response. If the CAP subsystem is unable to successfully bind a Minor Set alarm (SGSN CAP Subsystem Bind Failed Alarm: 7068 1517) is raised against the Tcap/ component. If this alarm is raised, the SGSN CAP subsystem cannot be used and any Service Switching Function (SSF) trying to register with the CAP subsystem will receive a registration failure response.

3.10.3 Monitoring For Activity When the MAP/TCAP card receives large number of Notice Indication messages from the SIG, it can be an indication of a SS7 link failure or SS7 link congestion. The Tcap/ invokeSent and invokeReceived counters indicate activity between TCAP and SIG.

3.10.4 Monitoring For Congestion The Tcap/Map application monitors the arrival rate of messages received from the GSCs. If this message arrival rate exceeds a hard coded threshold, a Major Message alarm (MapStack Overload Alarm: 7068 1495) is raised against the Tcap/ component. If this situation occurs, messages received from the GSC applications are dropped until the



message rate falls below the capacity limit. No action is required for a temporary overload condition since this situation can occur due to a GSC application reset. However, if the overload condition persists it should be rectified. This alarm is cleared when the message arrival rate falls below the hard coded threshold. The Tcap/ application monitors the arrival rate of SCCP Notice Indication messages received from the SIG. If the Tcap application determines that the message arrival rate exceeds a hard coded threshold, a Warning Message alarm (SS7 SIG Problem Alarm: 7068 1533) is raised against the Tcap/ Ss7IpIf/ component. The presence of this alarm indicates a potential problem occurred with the SIG in its SS7 layer. The message text of this alarm includes a breakdown of SCCP Return Causes that can help troubleshooting efforts. If the alarm indicates many occurrences of network Congestion and network Failure return Causes were received there may be SS7 link congestion. The operator should also check the condition of the SIG. The Tcap application also monitors the arrival rate of SCCP Notice Indication messages with Returned Cause value equal to networkCongestion or networkFailure. If the arrival rate exceeds a hard coded threshold, a Major Message alarm (SCCP Notice Indication Throttling Alarm: 7068 1534) is raised against the Tcap/ Ss7IpIf/ component. This alarm is cleared when activity falls below the threshold. The Tcap application is provisioned to support up to a maximum number of simultaneous transactions across its SGSN, CAP and MSC subsystems. When the total number of transactions exceeds 95% of the maximum a Critical Set alarm (TcapStack out of Subsystem Resources Alarm: 7068 1505) is raised against the Tcap/ component. This maximum is equal to the sum of max transactions provisioned for each subsystem. This alarm is cleared when the current number of transactions falls below 90% of the maximum. When the set threshold is crossed, Tcap transactions for any given subsystem are still permitted until that subsystem reaches its subsystem defined maximum. When a subsystem reaches its maximum, no additional transactions are permitted for that subsystem until the current transactions falls below the maximum. Each subsystem raises its own alarm when the current number of transactions for that subsystem is close to the maximum. The Map subsystem raises Critical Set alarm (MapStack out of SGSN MAP Subsystem Resources Alarm: 7068 1506) against the Tcap/ Map component. The MSC subsystem raises Critical Set alarm (TcapStack out of SGSN MSC Subsystem Resources Alarm: 7068 1509) against the Tcap/ component. The CAP subsystem raises Critical Set alarm (TcapStack out of SGSN CAP Subsystem Resources Alarm: 7068 1510) against the Tcap/ component. The threshold for raising each of these alarms is 90% of the



subsystem provisioned maximum transactions. The alarm is cleared when current transaction rate for the subsystem falls below 90%. To monitor the congestion level the Tcap/ currentTransaction attribute can be compared with the sum of the provisioned Tcap/ maxTransactionsPerSubsystem. The closer these values, the higher congestion level on the card. There is an upper bound on the maximum number of invokes that can be handled by each subsystem. This limit is set via the maxInvokesPerSubsystem provisioning attribute on the Tcap/ component. When the MSC subsystem has reached its maximum invokes a Major Set alarm (Max MSC MAP Invokes Exceeded Alarm: 7068 1513) is raised against the Tcap/ MapStack component. When this maximum is reached no new invokes are established by the MAP Stack for the MSC subsystem until the in-use invokes are relinquished. The alarm is cleared when the current number of invokes has fallen below a low water mark. The Tcap/ operational attributes concurrentInvokesLowBySs, concurrentInvokesAvgBySs and concurrentInvokesHighBySs can be displayed to determine how close to maximum provisioned values the subsystems are. A similar Set alarm (Max CAP Invokes Exceeded Alarm: 7068 1514) exists for the CAP subsystem to notify the operator of maximum invokes reached for the CAP subsystem. The above mentioned attributes also display information for the CAP subsystem. The Tcap MapStack also monitors for overload situation arising from excessive Mobile Terminated Forward Short Messages (MTFSM) arriving from the SIG. When the MTFSM arrival rate exceeds 33 messages per second, a Major Message alarm (TCAP Mobile-Terminated FSM Overload Alarm: 7068 1536) is raised against the Tcap/ MapStack component. When this overload condition exists, the MapStack drops MTFSM messages arriving from the SIG to stay within the bounds of the permitted arrival rate. This alarm is raised with a cleared severity when the overload condition has abated for a certain period of time.

3.11 SIG Monitoring The SIG (SS7 IP Gateway) is a network element that runs on a Hewlett Packard hardware platform and provides inter-working functionality between GPRS nodes in the IP network and GSM nodes in the SS7 network. This inter-working provides a routing function between Passport-based SGSN on the IP network and the SCP, HLR, SMS-GMSC, SMS-IWMSC, and MSC/VLR network elements on the SS7 network. The SIG also performs protocol conversion function between the TCP/IP protocol and SS7 protocol.



MAP Stack 1

MAP Stack n

BSSAP+ Client 1

BSSAP+ Client n

HLR

SMS

VLR

MAP/ TCAP /SCCP

SGSN Passport

MAP/ TCAP /SCCP

BSSAP+/SCCP

SCIP messagesOver TCP/IP

GPRS IP Network GSM SS7 Network

(Gr’/Gd’ )

(Gr)

(Gs’)

(Gd)

(Gs)

SIG

SCP(Ge)

SCIP messagesOver TCP/IP

Figure 6 SIG Inter-working

Because the SIG communicates with the Passport SGSN, it is important to monitor the relevant components on the Passport that talk to the SIG. Refer to the corresponding interface sections in this document for more information. The SIG is comprised of both Nortel and Hewlett-Packard developed applications. The Nortel applications include

• SIG Application (SIPR) • OM Server • Log Server

The HP applications include

• HP-UX operating system • HP Open Call SS7 • MC/Service Guard • Event Monitoring System

This document provides monitoring guidelines for the Nortel developed applications. For information on monitoring HP applications refer to HP documentation. A complete list of HP documents is provided in NTP 411-5221-975, SS7 IP Gateway User Guide.



3.11.1 SCIP Messages The protocol layers on the Passport, SIG and SS7 network elements that facilitate connectivity between the networks are shown Figure 7. The interface between the SIG and the SGSN is a proprietary interface called SCIP. This interface transfers all incoming and outgoing SS7 traffic.

S C C P P a y lo a d

S C IP

T C P

IP

E h te rn e t

S C C P P a y lo a d

S C C P

M T P

L a y e r 2

L a y e r 1

In te rw o rk in g

S C IP

T C P

IP

S C C P

M T P

L a y e r 2

E h te rn e t L a y e r 1

S G S N P a s s p o r t S IG

S S 7 N e tw o rk E le m e n t

Figure 7 SCIP Message Stack

The types of SCIP messages can be divided into three categories. • Control Messages. • Data Messages. • Heartbeat Messages.

3.11.1.1 Control Messages The SGSN sends Control messages to register its GSC subsystems (i.e.CAP, SGSN-MAP, MSC, BSSAP) with the SIG. Successful registration must take place before subsystem communication between the GSC and the SS7 network can occur. Refer to the following sections for information on monitoring the successful registration of the various interfaces

• Gd Map Client Registration with SIG (2.3.1.2) • Ge Connectivity Monitoring (2.4.1)



• Gr MapClient Registration with SIG (2.6.1.1) • Gs Connectivity to SIG (2.7.1.1) • Monitoring for SIG Registration (3.2.5.1) • Monitoring for Connectivity (3.10.2)

3.11.1.1.1 SCIP Registration

The SCIP Registration message is sent by the client application on the Passport SGSN, to register subsystems with the SS7/IP Gateway and to indicate that it is in-service and ready to send and receive messages. Each Gsc is identified by a unique Global Title (GT) address and this is used by the SIG for message routing.

Figure 8 SCIP Registration

If registration succeeds, the SIG returns a RegistrationACK message to the Passport SGSN. If the SIG fails the registration request, a Registration NACK is sent to the Passport. Refer to section (3.11.4.1) and (3.11.6) for information on monitoring registration on the SIG. On the Passport side, connectivity status and registration status between the Passport and the SIG are monitored on the Tcap/ and Tcap/ Map components (3.10), Gsc/ Bssap (2.7.1.1) component and Gsc/ Mc (3.2.5.1) components.

3.11.1.1.2 SCIP Deregistration

This message is sent by the Client application to the Gateway to indicate that it is Out of service and can no longer receive SCIP messages. Refer to section (3.11.6) for information on tracing these messages on the SIG.



Figure 9 SCIP Deregistration

3.11.1.2 Data Messages Data messages contain information that is delivered to nodes in the SS7 network and the IP network. There is a naming convention used on the SIG for the direction of a data message flow: messages from the SS7 network are Indications, while messages from the IP network are Requests. There are two types of Data message:

• UDT � These are the messages that carry GPRS traffic (i.e. ISD�s, Cancel Location�s, DSD�s, Resets, and SMS).

• Notice/UDTS � These are messages used to tell the sending party why a message

could not be routed. Refer to section (3.11.6) for information on tracing these messages on the SIG.

S G S N

U D TR eq() (m ay contain a M A P U G L m essage)

G atew ay



Figure 10 SCIP DATA Message (UDT)

SGSN

UDT Ind() (could contain a MAP ISD invoke from HLR)

Gateway

Figure 11 SCIP DATA Message (UDT Indication)

Figure 12 SCIP UDTS message (Notice Indication)

3.11.2 High availability The SIG is a High Availability (HA) system, which contains two HP L-series servers in an active/standby configuration. This duplex configuration provides hardware and software redundancy. HP Multi-cluster/ServiceGuard (MC/SG) manages the SIG HA redundancy Software. MC/SG coordinates its transfer to a redundant hardware component in case of hardware failure. MC/SG also manages the SIG package, which includes the software needed for SCIP, SCCP and MTP layer 3 messages. If one of these SIG software components fails, MC/SG coordinates the transfer of the software component.

SGSN

NoticeInd()

Gateway



3.11.3 Monitoring SIG Platform When monitoring the SIG, it is necessary to log on to the SIG as root user, or an account that has root privileges. This is necessary, as most of the cluster commands (those prefixed with �cm� such as �cmviewcl� ) require root privilege.

3.11.3.1 Monitoring for Switchover In a SIG duplex configuration, when a switchover operation is performed from node 1 (active node) to node 2 (inactive node), the Node_Switching_Parameters SWITCHING flag of node 1 is set to disabled. This prevents the SIG package from switching back to node 1. In this state, if a new switchover operation is performed, the SWITCHING flag of node 2 will be set to disabled as well. This will not allow the package to run on either node. The problem that originated the switchover must be solved before the next switchover is attempted. Once the node that caused the switchover is fully operational, the SWITCHING flag for the node should be manually set back to enabled. If the flag remains set to disabled, the next switchover will cause a SIG outage. This characteristic of the SWITCHING flag also applies to manual switchover. A manual switch is performed when a patch is applied and when performing configuration upgrade. If a switchover occurs the SIG generates an SNMP trap to notify that the SS7 Stack process has failed. This trap is mapped to a Major Set alarm (SIG Alarm, C1201 1085) raised against the SIG<device name> HP FTC_PRPC/<process> component. The following commands should be run to ensure switching is re-enabled. Please refer to NTP 411-5221-975, SS7 IP Gateway User Guide for more information.



SigServer1:> cmviewcl �v CLUSTER STATUS SIG_CLUS up NODE STATUS STATE SigServer1 up running Network_Parameters: INTERFACE STATUS PATH NAME PRIMARY up 0/0/0/0 lan2 PRIMARY up 0/10/0/0/4/0 lan6 PRIMARY up 0/10/0/0/7/0 lan1 PRIMARY up 0/9/0/0 lan4 PACKAGE STATUS STATE AUTO_RUN NODE SIG up running enabled SigServer1 Policy_Parameters: POLICY_NAME CONFIGURED_VALUE Failover configured_node Failback manual Script_Parameters: ITEM STATUS MAX_RESTARTS RESTARTS NAME Service up 0 0 SS7GuardianAngel Service up 0 0 SIGMonitor Node_Switching_Parameters: NODE_TYPE STATUS SWITCHING NAME Primary up enabled SigServer1 (current) Alternate up disabled SigServer2 NODE STATUS STATE SigServer2 up running Network_Parameters: INTERFACE STATUS PATH NAME PRIMARY up 0/0/0/0 lan2 PRIMARY up 0/10/0/0/4/0 lan6 PRIMARY up 0/10/0/0/7/0 lan1

In the above output, the user should look at the Node_Switching_Parameters to determine if switching is enabled. If either of the nodes shows a STATUS of disabled, the following command should be run to re-enable switching.

cmmodpkg �e �n <disabled node name> SIG

For example: SigServer1:> cmmodpkg -e -n SigServer2 SIG



3.11.3.2 Monitoring CPU Utilization The SIG platform should not contain any process that is using up high percentages of CPU. If a process is seen utilizing more than 85% CPU, for more than a few seconds, this could be a symptom of a run away process. Nortel Support should be contacted. The top command can be used to obtain CPU usage statistics for all running processes. The percentage of CPU usage is shown under the %CPU column of the output. For example:

Sigserver1:> top Load averages: 0.34, 0.33, 0.31 95 processes: 93 sleeping, 2 running Cpu states: LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS 0.34 0.3% 0.0% 0.0% 99.7% 0.0% 0.0% 0.0% 0.0% Memory: 77340K (55088K) real, 71628K (58988K) virtual, 666660K free Page# 1/4 TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND ? 18 root 152 20 0K 0K run 106:46 1.13 1.13 vxfsd ? 340 root 110 20 23664K 17928K sleep 14:48 0.75 0.74 HPSS7 pty/ttyp1 16200 root 154 20 5568K 4104K sleep 0:11 0.51 0.51 HPSS7RMON

3.11.3.3 Monitoring Critical Processes The sigps command can be issued on the active SIG to ensure the Log Server, OM Server and SIPRGR_TCP applications are running. The output of this command should contain a line for each application together with its process id. For example:



zrc2h020:root> sigps

Setting up SIG application environment...

The load directory is not setup.

The SIG_LD_DIR will be set to /sig/pkg...

SIG application environment is set for SIG40BE load...

Name Os-pid PPID

***********************************************

LogServer.exe 819 811

OmServer.exe 1508 811

SIPRGR_TCP 1481 811

The HP process can be found on both the active and standby SIG nodes. To verify the HP processes are running, on each SIG node issue the ps command and grep the output matching on the string �HPSS7 -C� with a single space character between the �7� and ��. If the pattern match is unsuccessful then this means the process is not running. The following example shows the process is running:

Sigserver1>ps �ef|grep �HPSS7 -C� Root 340 25265 0 Feb 12 ? 47:01 /opt/HP-AIN/SS7_AAA/bin/HPSS7 �C SS7_Stack_AAA � typeName AA

3.11.3.4 Monitoring Disk Space It is important that there be adequate free disk space on both the active and standby SIG. The operator can issue the bdf command from the root directory of each SIG to determine what percentage of disk space is used. The %used column provides this information. For example:



Sigserver1:> bdf . Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 199381 176163 3279 98% /

All file systems should be below 85% usage. If a file system becomes 100% full a log is generated in the active log file contained in the /siglog directory. For more information on monitoring disk space refer to NTP 411-5221-975, SS7 IP Gateway User Guide. The following shows example log output:

File: SigTcp.C Line: 945 PROBLEM:An error condition occured on read() for IP address =209.183.32.114 EXPLANATION:Reason:ENOSPC - No space left on device. ACTION:Report to Nortel Support.

Refer to the section (3.11.5) for more information on monitoring the Nortel logs.

3.11.3.5 Monitoring for Core files The SIG should be clean of core files. If core files appear then Nortel Support should be contacted in order to identify why the core file was generated and attempt to identify a potential problem before it becomes a critical one. This check should be run only during off-peak hours so that the CPU usage is not an issue. The presence of a core file does not necessarily indicate a problem. The core file may be related to past problem. Therefore it is important to look at the time stamp of the core file to determine how recently the problem occurred. The find command is used to search the file system directories. The command should be issued on each SIG. For example

Sigserver1:> find / -name core If any core files are found, cd into that directory and type the following command:

Sigserver1:> file core core: core file from 'sigmonitor' - received SIGABRT

Nortel Support should be contacted and this information along with the core file itself sent to Nortel.



3.11.4 Monitoring SIG Interfaces The SIG is comprised of two main interfaces: the IP interface which faces the packet network, and SS7 interface which faces the SS7 network. The following sections discuss how these two interfaces can be monitored.

3.11.4.1 Monitoring IP Interface This is the interface facing the SGSN. This interface can be monitored to ensure that all the SGSNs that should be connected to the SIG are indeed connected with a valid TCP/IP connection in the Established state. The netstat command is used to monitor the TCP connections at the SIG. Use the grep command to pattern match on the gateway port number. This number is found in file /sig/pkg/SIGdir/data/SYS.DAT, where SIGdir denotes the name of the SIG software directory. The port number is assigned to the variable GATEWAY_PORT_NUM. An example search on port 11005 status is shown in Figure 13.

SigServer1:> netstat -a |grep 11005 tcp 0 0 47.104.76.212.11005 *.* LISTEN tcp 0 0 47.104.76.212.11005 47.104.77.163.11005 ESTABLISHED tcp 0 0 47.104.76.212.11005 47.104.97.139.11005 ESTABLISHED tcp 0 0 47.104.76.212.11005 47.104.77.162.11006 ESTABLISHED tcp 0 0 47.104.76.212.11005 47.104.97.138.11006 ESTABLISHED tcp 0 1 47.104.76.212.11005 47.104.102.206.11005 SYN_RCVD tcp 0 1 47.104.76.212.11005 47.104.102.201.11006 SYN_RCVD tcp 0 1 47.104.76.212.11005 47.104.102.202.11006 SYN_RCVD

Figure 13 Monitoring IP Port status with netstat command

An ESTABLISHED state means the TCP connection has received the needed messages for ensuring a reliable flow of information to the SGSN. A SYN_RCVD state means the TCP connection has not received all the needed messages for a connection to a SGSN. Note that SYN_RCVD is a valid state while in the process of establishing a TCP connection with the SIG. The netstat command should be repeated after 30 seconds to allow the system to update its connection status. The SGSN attempts to connect to the SIG forever and does not give up until the TCP connection is established. If the SIG loses heartbeat messaging with the SGSN, the SIG generates a log in the active log file in /siglog directory. An ESTABLISHED TCP connection does not guarantee SCIP clients have successfully registered with the SIG. The operator can issue the Oams �dbPrint SGSN command at the Unix prompt to determine what SGSN subsystems are registered on the SIG. The



output of this command is written to file /sigdb/TM.SGSN and can be viewed with vi text editor. On the SGSN, the Gsc/ Mc remains in the disabled operationalState until successful registration has occurred, at which point it enters the enabled state.

3.11.4.2 Monitoring SS7 Interface The SS7 interface is implemented by Hewlett Packard hardware and software. Complete information on usage of HP tools can be found in the HP documentation. A complete reference to the HP documents can be found in NTP 411-5221-975, SS7 IP Gateway User Guide. The HLR, VLR, SMS, and SCP reside in the SS7 network. The SIG relies on the SS7 links for communication to these devices in SS7 network. The SS7 links can be monitored using HP tool called ss7MgrStart. The main menu of this tool is shown in Figure 14.

Hewlett Packard SS7 -- MAIN MENU -- -------------------------------------------------------------------------------- 1 - Configure Entities 2 - Monitor Entities 3 - Single Entity Statistics C - Checkpointing H - Help Q - Quit monitor

Figure 14 SS7 Monitoring Tool

From the main menu, select menu item Monitor Entities. From the Monitor Entities sub-menu the operator can choose to monitor the MTP layer links and their status. Example output for the MTP Link Monitoring is shown in Figure 15. The State column indicates if a link is Active or Inactive. All links should be in the Active state. Although some links can be more critical than others, it is important to identify why any of the SS7 link are down.



Hewlett Packard SS7 -- MONITOR - LINK/LINKSET -- LPC: 1.179.10 -------------------------------------------------------------------------------- LINKSET LINK -------------------------------------------------------------------------------- Adj-DPC State Traffic LinkId SLC AIOC Traffic Rx %Use Tx %Use -------------------------------------------------------------------------------- 1.8.1 INACTIVE 0 99 0 ---- 0 0 0 1.21.1 INACTIVE 0 0 0 ---- 0 0 0 1.21.2 INACTIVE 0 1 0 ---- 0 0 0 1.23.1 INACTIVE 0 2 0 ---- 0 0 0 178.18.1 ACTIVE 0 3 0 A--- 0 0 0 4 1 ---- 0 0 0

Figure 15 Monitoring MTP links

From the Monitor Entities sub-menu the operator can also choose to monitor the SCCP layer which contains the subsystems of the SGSN being serviced by the SIG. Example output for SCCP subsystem monitoring is shown in Figure 16 Monitoring SCCP subsystems . It is important that all local subsystem remain INSERVICE.



Hewlett Packard SS7 -- MONITOR - SCCP -- LPC: 1.179.10 ------------------------------------------------------------------<MORE>-------- SIGNALLING POINTS SUBSYSTEMS (USERS) ======================================================= Entity PC State Traffic /s SSN State Traffic /s -------------------------------------------------------------------------------- Local: 1.179.10 AVAILABLE 0 146 INSERVICE 0 149 INSERVICE 0 249 INSERVICE 0 Unroutable Messages 0 Remote: 1.4.3 UNDEFINED 0 6 INSERVICE 0 Remote: 1.8.1 UNDEFINED 0 6 INSERVICE 0 Remote: 1.21.1 UNDEFINED 0 6 OUTOFSVCE 0 8 OUTOFSVCE 0 Remote: 1.21.2 UNDEFINED 0 248 OUTOFSVCE 0 Remote: 1.23.1 UNDEFINED 0 6 INSERVICE 0 (A)ctivate, (D)eactivate, (S)earch, (P)rint, (H)elp

Figure 16 Monitoring SCCP subsystems

Typically the SS7 MTP links and the SS7 SCCP bind recover on their own in the event of a problem. However, discovering why these critical paths went down may help in preventing any further outages.

3.11.5 Log Monitoring The SIG uses a log system as a centralized facility to collect and display information reported by processes. The log system is used to record errors or other significant operational events as they occur. The SIG stores two classes of logs: HP logs and Nortel logs. The Nortel log system is discussed in the following section. For information on the HP generated logs refer to NTP 411-5221-975, SS7 IP Gateway User Guide.

3.11.5.1 Nortel Logs The SIPR process is the SS7 IP routing application. The SIPR process communicates information about relevant events a Log Server over a UDP connection. The Log Server writes this log data to a text file in the /siglog directory. The nature of information stored in these logs includes indications of operational state change, activity, hardware and software faults, and other significant events that can affect SIG performance. The operator should monitor the active log file to troubleshoot problems. The naming convention for these log files is loghhmmss.yymmdd. Entries made to the active log file



(example: log.11223344.020304 ) can be monitored in real time using the tail command as follows: tail �f log.11223344.020304 Alternatively, the log file can be viewed using an ASCII text editor such as vi.

The SIG also has administration logs that are located in the /sigadm/log/sigadm.log file. These logs provide information on the SIG process startups.

3.11.5.2 Notice Indication Logging The NTP 411-5221-975, SS7 IP Gateway User Guide document provides useful information on recommended actions that should be taken when certain logs are seen in the /siglog file. The following provides additional information specific to the Notice Indication logs. Notice Indication messages are recorded in the active log file in the /siglog directory. The log text includes a numeric Return Reason which can provide useful troubleshooting information. Table 1 provides textual names for each of the numeric Return Reasons.

Table 1 Notice Indication return code mappings

Return Reason Text Name Standard 0 SC No Translation Nature ITU-TBB,ANSI88 1 SC_No Translation Specific ITU-TBB,ANSI88 2 SC Subsystem Congestion ITU-TBB,ANSI88 3 SC Subsystem Failure ITU-TBB,ANSI88 4 SC Unequipped User ITU-TBB,ANSI88 5 SC Network Failure ITU-TBB,ANSI88 6 SC Network Congestion ITU-TBB,ANSI88 7 SC Unqualified ITU-TBB,ANSI88 8 SC Error In Message Transport ITU-T WB+96, ANSI96

(XUDTS only) 9 SC Error in Local Processing ITU-T WB+96, ANSI96

(XUDTS only) 10 SC No Destination Reassembly ITU-T WB+96, ANSI96

(XUDTS only) 11 SC Failure ITU-TWB+96, ANSI96

(XUDTS only) 12 SC Hop Counter Violation ITU-T96, ANSI96 13 SC Seg Not Supported ITU-T96 14 SC Seg Failure ITU-T96 249 SC Invalid ISN Routing ANSI96 250 SC Unauthorized Message ANSI96



251 SC Message Incompatibility ANSI96 252 SC No ISN Icons Routing ANSI96 253 SC Redundant ISN Icons Routing ANSI96 254 SC No ISN Identification ANSI96 256 SC No Error Not defined in standard Table 2 provides some possible reasons for seeing some of the more common return reasons.

Table 2 SC Notice Indication common return reasons

Return Reason Possible Reason for Log SC No Translation Nature This return reason log is displayed when the SC

translation table does not contain translations for an IMSI

SC No Translation Specific This return reason log is displayed when the SC translation table does not contain translation either for the IMSI that is being sent on the message or for any of the e.164 numbers (SGSN, HLR, etc

SC Unequipped User This return reason is seen when a message is sent to a node that does not support it

SC Network Failure This return reason occurs when there is a communication problem between the SIG and the node on the SS7 network (e.g. HLR, MSC/VLR). It may indicate the SS7 node cannot process the information correctly. This would result in no answer being sent back to the SIG. It may also indicate the SS7 node was unable to receive messages because the SS7 links are not In Service.

An example SC Notice Indication log is shown in Figure 17.



231 02 08 01 14:31:25 SIG605 SIPR Info Log File: SIntLayer.cpp Line: 1910 PROBLEM: SCCP Notice Ind.: RETURN_REASON = 0 CdPC = 512 CdSSN = 149 CdGTT TT = 0 CdGTT Address = 0983476002 CgPC = 512 CgSSN = 6 CgGTT TT = 0 CgGTT Address = 61134101245199 ACTION: None.

Figure 17 Example SC Notice Indication log with return reason equal to SC No Translation Nature

3.11.6 OAMS Command for SIG The SIG platform collects operational measurements (OMs). There are two main categories of measurements: IP related, and SS7 related. These operational measurements can be viewed via the Oams command. NTP 411-5221-975, SS7 IP Gateway User Guide provides a complete description of the Oams command and the operational measurement groups and registers that can be viewed. The following provides a summary of some useful options. The operator can display help on the Oams command as shown in Figure 18.

SigServer1:> Oams Usage:

Oams -ipMsgOms <list of IPMsg om groups to show | HELP> Oams -resetIpMsg <list of IPMsg om groups to reset | HELP> Oams -ss7MsgOms <list of SS7Msg om groups to show | HELP> Oams -resetSs7Msg <list of SS7Msg om groups to reset | HELP> Oams -delTuple <SGSN#(i.e. 1234567890) & APPTYPE(i.e. 254) & VPC(i.e. 512)> Oams -debugTrc <TRCALLMSG TRCDATAMSG TRCCNTRLMSG TRCHBMSG> Oams -dbPrint <SGSN | VPC> Oams -help

Figure 18 Oams command help

The �ipMsgOms option is used to display IP related OMs while the �ss7MsOms option displays the SS7 related OMs. The operator can also use the Oams command to turn on SCIP Control Message logging as shown in Figure 19. The exact same syntax is used to turn this logging off.



SigServer1:> Oams -debugTrc TRCCNTRLMSGDebug Trace CONTROL Turned ON

Figure 19 SCIP logging using Oams command

The SCIP Control Message logs are written to the active log file (3.11.5.1) in the /siglog directory. These logs are useful when the operator needs to determine specifically what control messages are passing to and from the SIG. For example, Subsystem Registration Request messages originating from the SGSN and responded to by the SIG are logged. Example log output for Registration Request/Response is shown in Figure 20. Note that the Problem field of these logs is used to identify the message type. It does not identify a problem. Example logs associated with SGSN sub-system de-registration are shown in Figure 21. The log output for the Acknowledge messages includes a status value. This is highlighted in bold in the example output. The value of the status attribute should be 0 to denote success. If it is 1 this denotes a failure and Nortel Support should be contacted.



257 03 01 23 04:02:09 SIG605 SiprServer Info Log File: RouterManager.C Line: 410

*************************************************** ***************************************************

PROBLEM: Received a Registration Request *************************************************** IP Address = 47.104.251.93 Port Number = 11006 User ID = 1 SGSN Number = 0 9 8 3 4 7 6 3 3 7 Virtual Point Code Number= 0 Subsystem Type = 249 Connection ID = 0 *************************************************** *************************************************** ACTION: None.

258 03 01 23 04:02:09 SIG605 SiprServer Info Log File: RouterManager.C Line: 903

*************************************************** *************************************************** PROBLEM: Sending a Registration ACK *************************************************** IP Address = 47.104.251.93 Port Number = 11006 Connection ID = 4 User ID = 1 SGSN Number = 0 9 8 3 4 7 6 3 3 7 Virtual Point Code Number= 0 Subsystem Type = 249 status = 0 *************************************************** *************************************************** ACTION: None

Figure 20 Example Registration Request/Response logs



8 03 01 10 12:00:49 SIG605 SiprServer Info Log File: RouterManager.C Line: 657 *************************************************** *************************************************** PROBLEM: Received a DeRegistration Request *************************************************** IP Address = 47.104.77.163 Port Number = 11005 Connection ID = 5 *************************************************** *************************************************** ACTION: Calling TableManager and Retreving Tuple info

9 03 01 10 12:00:49 SIG605 SiprServer Info Log File: RouterManager.C Line: 688 *************************************************** *************************************************** PROBLEM: Tuple Info Retrieved From Data Base *************************************************** IP Address = 47.104.77.163 Port Number = 11005 Connection ID = 5 User ID = 1 SGSN Number = 0 9 8 3 4 7 6 0 0 6 Virtual Point Code Number= 0 Subsystem Type = 149 *************************************************** *************************************************** ACTION: None 10 03 01 10 12:00:49 SIG605 SiprServer Info Log File: RouterManager.C Line: 1059 *************************************************** *************************************************** PROBLEM: Sending a DeRegistration ACK *************************************************** IP Address = 47.104.77.163 Port Number = 11005 Connection ID = 5 User ID = 1 SGSN Number = 0 9 8 3 4 7 6 0 0 6 Virtual Point Code Number= 0 Subsystem Type = 149 status = 0 *************************************************** *************************************************** ACTION: none



Figure 21 Example SGSN subsystem de-registration logs



4 Services 4.1 Mobile Attach

MS7

� Frame Relay

� E1/T1

WPDS GSD

7

� GSD (LLC)

OC3 7

� SIC

� ATM I/F

CGF

SGSN Global

TCP/IP secure

network

SIG

HP

�TCP/IP

SS7 Network

HLR

Gb

2PGPDSK SAS

15

� SAS

� Partial MCDR

2PGPDSK GSC

15

�2PGPDSK TCAP/MAP

15

� TCAP/MAP

� GIPS

LAN 7 � I/O

� LP

4POC3 15

� SIC

� ATM I/F

� ATM MPE

Gr

GrGa

�UDP/IP

Figure 22 Network view Mobile Attach

In order to access the PS services, an MS first makes its presence known to the network by performing a GPRS Attach. This makes the MS available for SMS over PS, paging via the SGSN, notification of incoming PS data, and PDP context activation. In order for Mobile Attaches to succeed, the following interfaces must be operational: Gb (2.2), Gr (2.6) and Gs (2.7) interface for combined attaches. Refer to the corresponding sections in this document for information on how to monitor the health of these interfaces.



In order for Mobile Attaches to succeed the following network elements are required: MS, SGSN Passport, SIG, and HLR. Therefore each of these elements must be operational. Refer to section on SIG (3.11) for monitoring this element. HLR Monitoring is outside the scope of this document. In order for Mobile Attaches to succeed, the following functional components are required: GTL (3.4), GSD LLC (3.3), GSC Gmm (3.2), GSC HlrC, GSC Mc, Tcap/Map (3.10). Refer to the corresponding sections in this document for information on how to monitor the health of these functional components. The guidelines in the following sub-sections can be used to monitor GPRS Attach operations. Additional information on troubleshooting Attach/Detach can be found in UMTS/GPRS Troubleshooting Guide NTP 411-5221-501.

4.1.1 Monitoring Attach Activity The operator can determine how many mobiles are currently attached by displaying the value of Gsc/ Gmm currentlyAttached counter. The GSC has a provisioned maximum number of attaches that can be supported simultaneously via the Gsc/ maxAttachedSubscribers provisioning attribute. When this maximum is reached a Major Set alarm (7068 1006) is raised against the GSC component. No new subscribers can attach to the GSC until the number of currently attached subscribers falls below the provisioned limit. This alarm is updated with a different severity depending upon what percentage of maximum is reached: Minor denotes 90%, Major denotes 95% and Critical severity denotes 100% of maximum. When the maximum is reached no new subscribers are able to attach. The severity of this alarm is reduced to Major and Minor when the number of currently attached subscribes falls below 98% and 93% respectively. Provisioning a new GSC card into the shelf or increasing the provisioned value for Gsc/ maxAttachedSubscribers attribute could prevent this fault from occurring in the future. The Gsc/ currentlyAttached attribute can be compared to the provisioned Gsc/ maxAttachedSubscribers attribute to get an indication of this alarm before the resources are exhausted. The GSC monitors the success rate of mobile attaches. Every 15 minutes, the GSC calculates the percentage of attach rejections vs. total attach requests. If the attach success rate for the 15 minute interval is below 90% then a Major Set alarm (Attach Requests Rejected or not Received Alarm: 7068 1531) is raised against the Gsc/ Gmm component. If the attach success rate is between 90% and 95% this alarm is raised with Minor



severity. The alarm is cleared when the attach success rate is above 95%. This alarm also gets raised with Critical severity if zero attach requests were received by the GSC within the 15 minute window. This occurrence of the alarm is cleared when at least one attach request is received within a 15 minute window. If this alarm is raised, the operator should verify the GTL and MAP components are operating properly.

4.1.2 Identifying Reason for Attach Failure If attach operations are failing, the following counters can be displayed to identify the reason for the failures. All of these counters are on the Gsc/ Gmm component.

• attachRejPacketNetworkFailure � Major contributing factors to this counter is MAP system failure and Gb Xid negotiation timeouts. MAP is receiving �system failure� or �SCCP SAI/UGL UDTS� from the interface.

• attachRejSgsnCongestion - cause could be:

o Maximum number of subscribers limit for GSC card is reached. o GSD Max LLC active subscribers reached. o TLLI collision. o MAP or Gr congestion.

The above counters are also tracked on a per-cell basis. The attribute names are attachRejPacketNetworkFailurePerCell and attachRejSgsnCongestionPerCellis and they reside on the Gsc/ Mcc/ Mnc/ Lac/ Rac/ Cid/ component. In addition to the above mentioned attach reject counters, there are attach reject counters for tracking other attach reject reasons. The full set of counters can be viewed by displaying the Gsc/ Gmm gmmAttRejStats group. Per cell versions of these counters can be viewed by displaying the Gsc/ Mcc/ Mnc/ Lac/ Rac/ Cid/ gmmCellOper group. If the Attach Reject count is greater than 0 for a DCS collection cycle, a warning message alarm (Attach Reject Cause Code Reporting Alarm: 7068 1028) raised against the Gsc/ Gmm component itemizes the specific reasons for the attach rejects. The counts included for network failures are resource exhaustion for primary contexts (noPrimCtxt), resource exhaustion for procedural contexts (canNotAllocateTempCtxt), LLC general failure (genFailureFromLlc), resource exhaustion for HLRc context (canNotAllocateHlrcCtxt), TLLI assignment failures (assignReqFailure), MS reset procedure failure (msResetProcFailure), LLC Deactivation Failures (deactReqFailure), security failures (iovReqFailure), and map client failures (mapClientFailure). The counts included for



congestion failures are maximum provisioned attaches reached (maxSubsReached), resource error on the MAP (mapResourceError), TLLI Collisions (tlliCollision), and failures in the attach confirm message (actConfirmFailure). The warning message is informational in nature and can help to identify the specific part of the network contributing to the attach failure.

4.1.3 CPU Utilization Refer to the Logical Processor Monitoring section (3.8).

4.1.4 Max Subscribers Reached The GSD also has maximum subscribers limit that is accompanied by a Major Message alarm (Maximum Active Subscribers Reached Alarm: 7068 1009) when reached. If the maximum subscribers limit has been reached, no new subscribers will be able to attach until the number of active subscribers falls below the provisioned limit set by Gsd/ maxLlcActiveSubscribers provisioning attribute on the GSD. The GSC may also disallow attaches if congested. The Major Message alarm (GSC Memory Exhausted Alarm: 7068 1005) indicates resources exhausted on the GSC and no further attaches will be allowed.

4.1.5 Other Things to Monitor M-CDRs and M-CDRs are indirect indicators of shelf wide stability. See section (4.2) for billing details.

4.1.6 Overload Conditions See the Overload Control Monitoring section (3.2.6) for information on discarded attaches during overload conditions.

4.2 Billing Billing is recorded by events that occur on both the SGSN and the GGSN. The SGSN creates Mobile Call Detail Record (MCDR) and Serving GPRS Support Node Call Detail Records (SCDR). Each attach mobile generates a time based MCDR for the time that the mobile is attached and a time based SCDR for each session created. For monitoring information, reference the SAS Monitoring Section (3.9).



4.3 RAU/ IRAU

Figure 23 Network view IRAU

Three types of RAU procedures can be performed on the SGSN: Periodic RAU, Intra-RAU, and Inter SGSN RAU. The periodic RAU is a procedure between the SGSN and the MS to maintain the position of the MS. The IntraSGSN-RAU is a procedure in which the MS moves from one Routing Area (RA) to another RA where both are serviced by the same SGSN. Inter SGSN RAU is a procedure in which the MS moves from one RA to another RA where the new RA is served by a different SGSN.

MS7K

� Frame Relay

� E1/T1

� GTL

WPDS GSD

7K

� GSD (LLC)

OC37K

� SIC

� ATM I/F

� ATM MPE

4POC315K

� SIC

� ATM I/F

� ATM MPE

2PGPDSK GSC/DNS

CGF

SGSN Global

TCP/IP secure

network

2PGPDSK SAS

15K

� SAS

�

� MCDR & SCDR

� TCAP/MAP

� GIPS

2PGPDSKTCAP/MAP

15K

SIG

HP

�TCP/IP

�SIPR

SS7 Network

Gb

15K

LAN7K To

GGSN orOld

SGSN

� I/O

� LP

Gn

Ga

Gr

G

HLR

�UDP/IP



4.3.1 Interfaces to Monitor As the RAU procedure uses more nodes, more interfaces are involved in the procedure: for periodic RAU, only the Gb (2.2) interface is used for a single RA, for Intra-RAU the Gb (2.2) interface is used between two RAs, and for Inter SGSN RAU the Gb (2.2), Gn (2.5), Gs (2.7), and Gr (2.6) interfaces are used.

4.3.1.1 Interfaces to Monitor for Periodic RAU The periodic Rau involves a procedure where the mobile messages with the SGSN to indicate that it is still present in the same RA. The number of periodic RAUs received at a GSC is presented in the Gsc/ Gmm periodicIntraSgsnRaUpdate counter. The periodic RAU timer runs on the mobile and triggers the MS to send the periodic RAU Request message to the SGSN, which resets the msReachable timer. When the msReachable timer times out, the MS is implicitly detached. Failures on periodic RAU procedures could be attributed mostly to the Gb interface. The msReachable timer is a provisionable attribute on Sgsn Gsc component.

4.3.1.2 Interfaces to Monitor for Intra RAU The Intra-Rau update involves a procedure where the mobile messages with the SGSN to indicate the new RA that the mobile has moved to. The number of Intra-RAUs received at a GSC is presented in the Gsc/ Gmm normalIntraSgsnRaUpdate counter. The MS location is updated in the GSC and a BVC relating to the new cell is assigned on the GSD. Failures on Intra-RAU procedures could be mostly attributed to Gb interface, GSD, or GTL problems.

4.3.1.3 Interfaces to Monitor for Inter SGSN RAU The Inter SGSN RAU involves a procedure where the context related to the mobile�s attachment and the contexts related to all of the mobile�s sessions are transferred over from the old SGSN to the new SGSN. This includes a short period of time where downlink data is transferred from the old SGSN to the new SGSN while the Gn interface is being moved. The Gb interface on the new SGSN receives the RAU request message indicating that the mobile is requesting a move. A successful move of a mobile to a new SGSN will increment the Gsc/ Gmm interSgsnRaUpdateAccepts counter the old SGSN will decrement the Gsc/ Gmm currentlyAttached counter and the new SGSN will increase that attribute.



Mobile contexts are transferred between SGSN with the use of the Gn interface using the GTP protocol. Inter SGSN RAU specific counters are presented in the Gsc/ GtpM component of the SGSN. The new SGSN uses the DNS to find the IP address of the old SGSN to communicate the Gn signaling with. See the DNS section (3.5) of this document for possible problems with the DNS query. The new SGSN will increment the Gsc/ GtpM sgsnContextReqAttempts and Gsc/ GtpM sgsnContextAcks counters during this communication. A problem with the Gn interface on the new SGSN can be seen by a rapid increase in the Gsc/ GtpM sgsnContextReqExhaust counter. This counter is pegged when the old SGSN does not respond to the SGSN context request message sent across the Gn interface. Failed Gn messaging will cause the old SGSN to continue to hold the context for the mobile while the new SGSN will release any resources allocated for the Inter SGSN RAU procedure. The old SGSN also increments counters for its use of the Gn interface for Inter SGSN RAU procedures. For each SGSN Context Request message received, the old SGSN responds with an SGSN Context Response message, increments the Gsc/ GtpM sgsnContextRespAttempts counter, and waits for an SGSN Context Acknowledge message from the new SGSN. If the SGSN Context Acknowledge message is not received before the GtpM T3 timer and N3 retries is exhausted, the Gsc/ GtpM sgsnContextRespExhaust counter is incremented. A failed response for this message may mean a failed connection, insufficient resources on the new SGSN, or the new SGSN may have failed before sending the acknowledgement back to the old SGSN. To successfully move a mobile from an old SGSN to a new SGSN, the Gr interface is required. The new SGSN will send an Update GPRS Location request to the HLR and receives an ISD from the HLR while the old SGSN will receive a Cancel Location from the HLR. See the Gr interface section of this document for specific monitoring of the Gr interface. A mobile performing an Inter SGSN RAU procedure may contain active sessions that are also transferred with the mobile. When sessions are transferred, extra messaging occurs between the two SGSNs and the new SGSN and the GGSN where the sessions were established. The SGSN Context Acknowledge message informs the old SGSN that the new SGSN is ready to accept data packets. Data packets flowing from the GGSN are tunneled to the old SGSN across the Gn interface, which forwards them to the new SGSN across another Gn interface. The new SGSN delivers the packets to the MS. This happens until the new SGSN receives an Update PDP Ctxt Response message from the GGSN. When this happens, the GGSN starts tunneling packets to the new SGSN directly across a Gn interface. Uplink packets are discarded until the MS sends a RAU Complete message to the new SGSN. Refer to the Gn Interface section (2.5) for information on counters to monitor.



The new SGSN must transfer the Gn interface established between the old SGSN and the GGSN to the new SGSN before completing the Inter SGSN RAU procedure. The update PDP context request and update PDP context response message pair is used to transfer the tunnel from the old SGSN to the new SGSN. Failures on this messaging could indicate a connection or congestion problem on the Gn or GGSN respectively. See the Gn interface section (2.5) for details. Camel sessions transferred to a new SGSN can be deactivated if the Ge interface has a problem. If the subscription for the session being transferred indicates that camel must be active for that tunnel, the new SGSN will deactivate the session once it is received. Refer to section (2.4) on the Ge Interface on how to monitor the health of that interface.

4.3.1.4 GMM T3 Tunnel Timeout on the New SGSN for Inter SGSN RAU Procedures

GMM starts a T3 Tunnel timer on the old SGSN when the SGSN Context Request message is received from the new SGSN. If a cancel location is not received on the old SGSN before this timer expires, the old SGSN stops forwarding data to the new SGSN and continues to service the mobile as before the Inter SGSN RAU procedure started. The number of T3 timeouts is presented in the Gsc/ Gmm t3Timeouts counter. When this counter is determined to be increasing rapidly or have a percentage higher than at normal traffic times, the Gr interface and Gn interfaces should be examined.

4.3.1.5 Insufficient Resources on the New SGSN for Inter SGSN RAU Procedures

The new SGSN must allocate resources for the new mobile and the new sessions transferred over as part of an Inter SGSN RAU procedure. Resources are allocated on the GSD and GSC for each mobile transferred. If resources are exhausted on either the GSD or GSC, one of the following alarms is likely to be seen

• (GSD Maximum Active Subscribers Reached Alarm: 7068 1009) Major

Message alarm, • (GSC Memory Exhausted Alarm: 7068 1005) Message alarm will be indicated

and the procedure will fail, • (GSC Maximum Attached Subscribers Reached Alarm: 7068 1006) Set

alarm.



4.3.1.6 Excessive IRAU or RAU Failure Indications Excessive IRAU and RAU failures are indicated by a minor set alarm (I/RAU Requests Rejected Alarm: 7068 1027) raised against the Gsc/ Gmm component. When the failure rate of the RAU procedure or the IRAU procedure is greater than 5% for the measured DCS interval, this alarm is set. When the failure rate falls below the 5% limit during a DCS interval, the alarm is cleared. This alarm could be the result of a network problem on the Gr interface or an incompatibility issue between the Nortel SGSN and another manufacturer�s SGSN. The total number of IRAU failures is recorded on the Gsc/ Gmm totalIrauRejects operational and collected attributes and the total number of RAU failures is recorded on the Gsc/ Gmm totalRauRejects operational and collected attributes.

4.4 Activation and Deactivation Activations are the establishment of data tunnels between the mobile and the network requested. Multiple sessions can be activated simultaneously on a mobile. Each session on a mobile is treated equally in all session related counters, provisioning and alarms.



Figure 24 Network view Activation and Deactivation

4.4.1 Interfaces to Monitor For activation and deactivation of sessions, the SGSN uses the Gb (2.2) and Gn (2.5) interfaces. Refer to sections on monitoring these interfaces for any of the following problems:

• Excessive activation rejects • Excessive SGSN initiated deactivations (Gsc/ Sm sgsnInitDeacts) • GGSN initiated deactivations (Gsc/ Sm ggsnInitDeacts)

If the Gsc/ Sm mobileInitDeacts counter is not increasing while known MS initiated deactivations are initiated, the Gb connection should be checked. Deactivations initiated by the HLR, GGSN or the SGSN will succeed even without the use of the Gb interface; however, the SGSN may try to page the mobile before skipping the messaging to the mobile and completing the procedure. Not all network initiated deactivations use the Gb interface. Examples of network initiated deactivations without the use of the Gb interface include deactivation for duplicate activation request and deactivations due to power off detach or detach.

MS7

� Frame Relay � E1/T1

WPDSGSD

7

� GSD (LLC) � GSD (LLC) � GSD

OC37

� SIC � ATM I/F

4POC15

� SIC � ATM I/F

2PGPDSKSAS

15

� SAS

2PGPDSKGSC/DNS

Agent15

� GSC

CGF

SGSN Global

TCP/IP secure

network � Partial SCDR

LA7

� SIC � ATM I/F

Gn over100Base

Bearer Data

Ga

To GGS

Gn

To DNS

DNS

Gb

�UDP/IP



The GSC monitors the success rate of PDP Context activations. Every 15 minutes, the GSC calculates the percentage of activation rejections vs. total activation requests. If the success rate for the 15 minute interval is below 90% then a Major Set alarm (PDP Activations Requests Rejected or not Received Alarm: 7068 1532) is raised against the Gsc/ Sm component. If the activation success rate is between 90% and 95% this alarm is raised with Minor severity. The alarm is cleared when the activation success rate is above 95%. This alarm also gets raised with Critical severity if zero activation requests were received by the GSC within the 15 minute window. This occurrence of the alarm is cleared when at least one activation request is received within a 15 minute window. If this alarm gets raised the operator should verify the GTL (3.4)and MAP (3.10) components are operating properly.

4.4.2 GSD Failure on Sessions All SGSN initiated deactivations, resulting from a failed GSD card, will not happen at the time of the card reset. Instead, the deactivation is initiated when the next mobile message originated message is received at the SGSN. A periodic RAU or an activate PDP Context Request message for an additional session as well as others, would trigger an SGSN initiated deactivate PDP Context Request message with the cause value of �reactivation requested� for the sessions on a specific mobile. The Gsc/ Sm sgsnInitDeacts counter and the Gsc/ Sm reactivationsRequested counters used together can indicate a possible GSD failure. An activation reject can be the result of a GSD failure. Although unlikely, there is a small window where the GSD card could fail activation. The GSD card failure alarm will be seen in this situation.

4.4.3 DNS Failure on PDP Context Activation Activation rejects caused by failed DNS queries can be discovered through examining the DnsAg/ serverQueryTimeouts or the DnsAg/ serverQueryFailures counter under the DNS Agent component. The DnsAg/ serverQueryTimeouts counter indicates how many times an external DNS had not responded to a request. The DnsAg/ serverQueryFailures counter is an indication of a failed DNS or a failed link to the DNS. These failures may not be critical since the GSC allows up to four external DNSs to be connected to a single GSC card.

4.4.4 Gn Connection Failures The Gn interface carries the create PDP context message to the GGSN from the SGSN as well as delete PDP context request and response and update PDP context request and



response. Under high traffic conditions, the SGSN will generate the Major Message alarm (GSC Memory Exhausted Alarm: 7068 1005). Two operational parameters in the Gsc/ GtpM gprsGtpMgmtOp group indicate the use of the Gn transactions: the Gsc/ GtpM peakTransactions indicates the high water mark of the resource usage and the Gsc/ GtpM currentTransactions attribute indicates how much GTP resources are currently in use. If this alarm is seen often because of Gn failures, the Gsc/ GtpM maxTransactions provisionable variable can be increased to allow for more transactions to the GGSN.

4.4.5 GSD Resource Constraint on Activation A GSD does not allow sessions to be established on it if the allocated resource for sessions has been exhausted. A Major Message alarm (GSD Maximum Allocated LLEs Reached Alarm: 7068 1012), should be seen simultaneously to the failed activations on the GSC card.

4.4.6 GSC Resource Constraint on Activation When the result of an activation reject is because of Gn or GSC reaching the provisioned limit of resources, the Major Message Alarm (GSC Memory Exhausted Alarm: 7068 1005) is triggered indicating the exhaustion of all available resources. This alarm is an indication of either poor engineering provisioning or high traffic through the GSC card. By checking the CPU usage on the GSC card, the cause of the instability can be better understood. If the CPU is not running at full capacity, the engineered value of the gsc/ maxAttachedSubscribers or the gsc/ avgActivePdpCPerActiveSub attributes may be too low; these attributes are found in the gprsGscProv group. (Note: gsc/ maxAttachedSubscribers and gsc/ avgActivePdpCPerActiveSub attributes should not be set higher than the maximum supported values as specified by Nortel Networks). The Gsc/ maxAttachedSubscribers attribute defines how many mobiles can attach simultaneously to one GSC. The Gsc/ avgActivePdpCPerActiveSub attribute defines the average number of sessions activated per mobile. The GSC monitors the rate of PDP Context activations.

4.4.7 Activation Reject Due to Timeout Activation rejects could occur because of system instability. To activate a PDP context the DNS, the Gb interface, the Gn interface and a GSD are used. The key indication of system instability during activation is timeouts occurring during and activation procedure. When activating, the SGSN has 30 seconds to activate the context before the MS will retry the request. If within that 30 seconds the SGSN does not accomplish the activation, an activate reject shall be sent to the mobile. A delay in activation could be the



result of a failed Gn interface that causes the SGSN to try a new IP addressed obtained from the DNS, no more resources available on the Gn interface to send the create PDP context request to the GGSN, no more resources available on the GSC card to create the local PDP context on the card, or the failure of the GSD card before the activation has completed. Timeouts may also occur due to the fallback procedure implemented on the Gn interface. The SGSN defaults to version 1 of the GTP specifications whenever a path is used for the first time. After exhausting the retry mechanism, the fallback to version 0 of the GTP protocol may use all of the time allocated for activation. To decrease the time needed to send the create PDP Context Request message to the GGSN, the Sgsn Gsc n3CreateRequest retry attribute and the Sgsn Gsc t3CreateResponse timer attribute can be adjusted downward.

4.4.8 SGSN Initiated Deactivations The SGSN can initiate deactivations for stability issues. The stability issue may be internal or external to the SGSN. Internal events requiring an SGSN initiated deactivation include sessions on a GSD that failed or a session where traffic volume query counts can�t be retrieved from the GSD where it was activated. External events requiring an SGSN initiated deactivation include an activation request from the mobile for resources already used by that mobile for a present session, a cancel location received from the HLR against a mobile that has an active session, or a disconnect mode received during an XID negotiation where the QoS reliability class is either class 1 or class 2 or a failed XID negotiation. These deactivations are recorded on the SGSN and sent in a message alarm (Sgsn-Initiated Session Deactivations Cause Code Reporting: 7068 1029) raised against the Gsc/ Sm component on a 15 minute interval.

4.4.9 Overload Conditions See the Overload Control Monitoring section (3.2.6) for information on discarded PDP Context Activate Requests during overload conditions.

4.5 CAMEL Activations A Camel activation is a specialization to a regular activation that adds prepaid billing functionality. Only Ge interface problems discussed in section (2.4) can be attributed to Camel failures.



MS7

� Frame Relay

� E1/T1

� GTL

WPDS GSD

7

� GSD (LLC)

� GSD (LLC)

� GSD (SNDCP)

OC37K

� SIC

� ATM I/F

� ATM MPE

4POC3 15

� SIC

� ATM I/F

� ATM MPE

2PGPDSK GSC/DNS

Agent

15

CG

SGSN Global

TCP/IP secure

network 2PGPDSK

SAS

15

� SAS

� GSC

� SCDR

LA7

Gn over100Base

Bearer Data

ToGGS

SIG

HP

�TCP/IP

SS7 Netwo

rk

� TCAP/MAP

� GIPS

2PGPDSKTCAP/MA

15

SC

� I/O

� LP

Gb

Gn

Ga

�UDP/IP

Ge

Figure 25 Network view for CAMEL

4.6 SGSN and MS-Initiated PDP Context Modification This SGSN and MS-Initiated PDP context modification procedures update specific parameters of an already active PDP context. The SGSN-Initiated PDP context modification is triggered by a change to the Qos in the HLR profile. The MS-Initiated PDP context modification supports the modification of negotiated QoS. The QoS can be upgraded or a downgraded.

4.6.1 Interfaces to Monitor The interfaces used for PDP Context modification are the same as for activation except for the Gr interface is used for the Insert Subscriber Data (ISD) message involved in a HLR initiated PDP context modification; the main interfaces are Gb (2.2) and Gn (2.5).



Monitoring the health of each interface is presented in both SGSN-initiated modifications and MS-initiated modification counters. The attempted SGSN- initiated context modifications are counted on Gsc/ Sm sgsnInitModifyAttempts counter. Failures to modifications on the Gn interface or on the GGSN itself are counted by the Gsc/ Sm sgsnInitFailAtGgsn counter. The attempted MS-initiated context modifications are counted on the Gsc/ Sm msInitModifyAttempts counter. Failures to modifications on the Gn interface or by the GGSN itself are counted by the Gsc/ Sm msInitFailAtGgsn counter, while failures on the Gb interface or on the mobile are counted by the Gsc/ Sm msInitFailAtMs counter.

4.6.2 Congestion During PDP Context Modification Congestion on the SGSN could cause modification failures on the SGSN. The number of failures caused by the SGSN is counted by the Gsc/ Sm msInitFailAtSgsn counter and on the Gsc/ Sm sgsnInitFailAtSgsn counter.



4.7 Short Message Service (SMS)

CGF

MS7

� Frame Relay

WPDS GSD

7

� GSD (LLC)

OC3 7

� SIC

� ATM I/F

4POC3 15

� SIC

� ATM I/F

� ATM MPE

2PGPDSK

� GSC

SIH

SGSN Global

TCP/IP secure

network

�TCP/IP

�SIPR

SS7 Network

SMS Initiated

2PGPDSK

15

� SAS

�2PGPDSKTCAP/MA

15

� TCAP/MAP

� GIPS

� SMT-CDR

7Gb

15

LAN7� I/O

� LP

Gr

Gr Ga�UDP/IP

Figure 26 Network view for SMS

The Short Message Service (SMS) provides a means of sending messages of limited size to and from GSM mobiles. Short messages, which are destined for or originated from a fixed network node or another mobile, are transported through a Service Center that acts as a store and forward center. A GSM PLMN needs to support the transfer of short messages between Service Centers and mobiles. Overload can occur for Mobile Originated Short Messaging when the rate of request from the mobile exceeds the provisioned rate or the map client transactions are exhausted. In either of those cases, a major message alarm (Mobile-Originated SMS Overload Alarm: 7068 1030) is raised against the Gsc/ Sms component to indicate overload on the Gs interface. The alarm is only set if messages are dropped during a DCS cycle because of an overload event.



Overload can occur for Mobile Terminated Short Messaging when the rate of request from the network exceeds the provisioned rate or the map client transactions are exhausted. In either of those cases, a major message alarm (Mobile-Terminated SMS Overload Alarm: 7068 1031) is raised against the Gsc/ Sms component to indicate overload on the Gs interface. The alarm is only set if messages are dropped during a DCS cycle because of an overload event. SMS uses the following network elements: MS, BSS, SGSN, SIG, SMS-GMSC. SMS can be monitored through the following application components within the SGSN: GSC Map Client (3.2.5), Tcap/Map Stack (3.10). SMS utilizes the Gd (2.3), Gr (2.6), and Gb (2.2) interfaces.



4.8 Prepaid Short Message Service (PSMS)

MS7

� Frame Relay

WPDSGSD

7

� GSD (LLC)

OC37

� SIC

� ATM I/F

� ATM MPE

4POC3 15

� SIC

� ATM I/F

� ATM MPE

2PGPDSK GSC

15

2PGPDSKTCAP/MAP

15CGF

SGSN Global

TCP/IP secure

network

SIG HP

�TCP/IP

SS7 Network

2PGPDSK SAS

15

� SAS

�

� TCAP/MAP

� GIPS

� SMO-CDR

SC

Gb

Ge

LA7� I/O

� LP

Ga

Ge �

�UDP/IP

Figure 27 Network view PSMS

The Prepaid Short Message Service extends SMS feature by utilizing an external Service Control Point (SCP) to manage and authorize prepaid SMS subscriber messaging. The SCP supports requests by the Sgsn to increment, and decrement the subscriber account balance when the mobile attempts to utilize the messaging service. The PSMS uses the SMS Service (4.7); therefore the monitoring guidelines for SMS are also relevant for monitoring the availability of PSMS. PSMS uses the following network elements: Service Center, SMS-GMSC/SMS-IWMSC, SIG, SGSN, BSS, MS, HLR, and SCP. Therefore each of these components and interfaces to them must be functional in order to provide PSMS service to the mobile. The following SGSN application components are relevant for monitoring the health of PSMS: GSC SMS (4.7), GSC MAP Client (3.2.5), TCAP/MAP Stack (3.10).



The following subsections provide information on monitoring the connection between GSC PSMS and the SCP.

4.8.1 Monitoring Connectivity to SCP A connection to the SCP must be in service for PSMS to function. The health of the connection(s) between SGSN and SCP can be monitored by displaying the nccpState attribute of the Gsc/ Psms Scp/ component(s). There must be at least one SCP component in the dataExchange state for the service to be functional. If the nccpState is null, connecting, idle, or releasing then PSMS is not in service. If the nccpState is not equal to dataExchange the operator should display the nccploginFailures attribute and the nccpLoginResponseTimeout attribute. If these counters are actively pegging this means the PSMS is trying to log into the SCP and it is not getting an Acknowledge message back from the SCP. The operator can display the IP Server (GIPS) to determine if there is any packet activity on the protocol port (Gips/ Ip/ Tcp ) used by PSMS. The operator should also ping the router that is the next hop from the SGSN to determine if it is responding. The ping should be done from the SGSN Ip Server protocol port that is used by PSMS. If the ping is successful, the operator should then ping the IP address of the SCP. If this ping is successful, it indicates the router knows how to route the packet to the SCP and that the Login Request messages being sent by PSMS on the SGSN are in fact reaching the SCP. Assuming the packets are reaching the SCP, the operator should next check that the clusterId�s are provisioned correctly on the SGSN. These are provisioned on the Gsc/ Psms Scp/ component. The operator needs to verify that the clusterId is a unique number across all the GSC instances that talk to a given SCP. In addition, the operator should verify that the cluster ids provisioned on the SCP side are also unique for each GSC that talks to that SCP. This will rule out the possibility of a problem that may have been introduced during a provisioning change on the SCP or SGSN.

4.8.2 Monitoring Activity between the SGSN and SCP The success rate of transactions between the SGSN and SCP can be obtained by displaying the value of totalTransactionSuccesses vs. totalTransactionFailures on the Gsc/ Psms component. If the failures are pegging more than the successes then further steps should be taken to determine what is wrong. The failure counter is incremented each time the response timer on the GSC expires before receiving a response message from the SCP. This could be due to network congestion or messages are not reaching the SCP.



4.8.3 Monitoring For Congestion on Link to SCP Congestion can be monitored from the PSMS by displaying the Gsc/ Psms peakConcurrentTransactions attribute. This attribute shows the maximum number of concurrent transactions the PSMS has realized during its operation. A transaction represents a message that has been sent to the SCP and the SGSN is waiting on a response. If this counter is going up it indicates congestion is happening at the CTP protocol layer. The congestion problem is most likely at the SCP and should be investigated.

4.9 Packet Flow Management (PFM) The BSS Packet Flow Context (PFC) Feature offers the Aggregate BSS QoS Profile (ABQP) functionality that can be shared by all the activated PDP contexts of the same MS with similar QoS profiles. PFM uses the Gb interface for (2.2) Qos negotiations.

4.9.1 Monitoring for Connectivity to the BSS for PFM The Gb interface is used for the QoS negotiations between the PFM component on the SGSN and the BSS. Beyond monitoring the Gb interface section for connectivity (2.2), the PFM component provides some relative counters. The Gsc/ Pfm component provides a t7RetryExpires operational counter that counts the number of failed messaging to the BSS; an unusually high increase in this counter could indicate a loss of connection.

4.9.2 Monitoring for Activity to the BSS for PFM The number of transactions between the SGSN and the BSS can be obtained by displaying the value of downloadBssPfcRx, createBss,PfcsTx, createBssPfcAcksRx, CreateBssPfmNacksRx, ModifyBssPfcsRx, ModifyBssPfcAcksTx, and DeleteBssPfcsTx operational counters on the Gsc/ Pfm component. When those counters increase, activity is occurring.

4.9.3 Monitoring for Congestion to the BSS for PFM Congestion can be from either a congested link or from a congested BSS. Congestion on the link or on the BSS could result in an increase in the Gsc/ Pfm t7RetryExpires operational attribute due to messages being dropped on the link or on the BSS. A congested BSS could also respond to a create PFC request with a not acknowledged message that is counted on the Gsc/ Pfm CreateBssPfmNacksRx operational attribute.



5 Summary of OAM Indicators Area Alarms Counters External Interfaces Ga Interface

Connectivity

Activity Congestion

Set � 7068 1003 None None

Sas/ cdrsXferCgf1, cdrsXferCgf2, gtpMsgXferCgf1, gtpMsgXferCgf2 Sas/ openScdrs < 900,000 Sas/ openMcdrs < 300,000 Sas/ cdrXferCgf1Fail, cdrXferCgf2Fai, gtpMsgXferCgf1fail, gtpMsgXferCgf2fail

Gb Interface Connectivity Activity Congestion

Set � 7068 1023 Set � 7007 0000 Set � 7007 1000 7007 2000 7007 2020 Set � 7011 2000 Set � 7011 5000 Set � 7011 5002 Set � 7011 5004 Set � 7011 5010 MSG � 7068 1020 None

Sggtl/ Nse/ Nsvc/ blocksFromPcu Gsc/ Sms cpResponseExhaust, rpResponseTimeouts Sggtl/ Nse/Nsvc/ alivesFromPcu, alivesToPcu , aliveAcksFromPcu, alivesAcksToPcu Sggtl/ Nse/ Ptpbvc/ blocksFromPcu Sggtl/ Nse/ Ptpbvc/ resetsFromPcu, pdusToPcu, pduFromPcu, flowCntrlPdusDiscarded

Gd Interface Connectivity

Activity

None None

Gsc/ Sms iwmscResponseTimouts Tcap/ Map moFsmTimeouts , mtFsmTimeouts Gsc/ Sms rpResponseTimeouts Gsc/ Sms moAttempts, moFailNetworkFailures, moFailUnidentifiedSubscriber,



Congestion

None None

moFailFacilityNotSupp, moFailCongestion, moFailUnknownServiceCenter, moFailInvalidSmeAddress, moFailMissingSmsSubscription, moFailOdbSubscriber, moFailOthers Gsc/ Mc ofSmMsgs Gsc/ Sms mtAttempts, mtFailUnidentifiedSubscriber, mtFailSubscriberAbsent, mtFailSubscriberBusy, mtFailSubscriberNotSmEquipped, mtFailNetworkFailures, mtFailMemCapExceeded, mtFailOthers Gsc/ Mc tfsmMsgs Gsc/ Sms moFailCongestion

Ge Interface Connectivity Activity Congestion

Set � 7068 1532 None Set � 7068 1519

Gsc/ Ssf totalTssfTimeouts Gsc/ Ssf attemptedCamelDialogues, unsuccessfulCamelDialogues Gsc/ Ssf pdpContextsRedirected Gsc/ Ssf currentCamelDialogues

Gn Interface Connectivity Activity

Set � 0000 1000 Set - 7068 1540 None

Gsc/ Sm sgsnInitDeacts Gsc/ Sm networkFailures Gsc/ GtpM pathFailures Gsc/ GtpM updatePdpReqAttempts, updatePdpReqExhausted Gsc/ GtpM peakGgsnPaths , currentTransactions Gsd/ Gtp pdusToNetwork, pdusToNetwork Gsc/ Sm sgsnInitDeacts Gsc/ Sm networkFailures



Congestion

None

Gsc/ GtpM currentTransactions, maxTransactions Gsd/ Gtp discPdusFromNetwork Gsd/ Gtp pdusFromNetwork Gsc/ Gtp incomingRequestsRejected, maxIncomingRequests

Gr Interface Connectivity Congestion

MSG - 7068 1535 MSG - 7068 1032 None

Gsc/ Mc sccpServiceRequestTimeouts Gsc/ Mc saiMsgs, uglMsgs , isdMsgs Gsc/ Mc transLimitDiscards, rstMsgs Gsc/ Hlrc recordsdToBeReset, recordsWaitingForHlrConf Tcap/ Map rfSmTimeouts

Gs Interface Connectivity Activity Congestion


Gsc/ Bssap sigRegisterFailures, vlrFailures Gsc/ Bssap gsAssociatedCurrent, gprsDetachMaxAttempts , explicitImsiDetachMaxAttempts, implicitImsiDetachMaxAttempts , sgsnResetMaxAttempts Gsc/ Bssap t8Timeouts, t9Timeouts, t10Timeouts, t12Timeouts.

LICP Interface Connectivity Activity Congestion

Set � 7068 1525 Set � 7068 1528 None None

Liaf/ bufferOverFlows

Functional Components GIPS

Connectivity None

Vr/1 Ip/ tcp attemptFails, inErrs



Activity Congestion

None None

Gips/ Ip/ inDelivers, outRequests

GSC Instance Connectivity Congestion Resources Map Client Overload Control

Set � 7068 1025 Set � 7068 1024 None MSG � 7068 1005 Set - 7068 1996 Set - 7068 1521 MSG � 7068 1520 MSG � 7068 1529 Set � 7068 1511 MSG � 7068 1496

Gsc/ Mc sccpServiceRequestTimeouts, systemFailureRespRecv, uAbortMsgRecv, uglMsgs, uglResponseMsgs, uAbortMsgSent Tcap/ noticeRecieved Gsc/ Mc currentTransactions Gsc/Mc ofSmMsgs, ofSmResMsgs, rsmMsgs, rsmResMsgs Gsc/ cpuOvldAttachesDiscarded, cpuOvldActivationsDiscarded, subCountOvldAttachesDiscarded

GSD

Instance Connectivity Congestion

MSG � 7068 1009 MSG � 7068 1012 Set � 7068 1025 Set � 7068 1024 MSG � 7068 1022 MSG � 7068 1009 MSG-- 7068 1021

Gsd/ DBuff totalDiscardsDueToMaxBytes , totalDiscardsDueToMaxPackets, totalDiscardsDueToBucketFull, totalDiscardsDueToBvcBlocked



Gsd/ Sndcp discardedNpdusFromMS GTL

Instance

Set � 7068 1025

DNS Agent Connectivity Activity Congestion

Set � 7068 1522 Set � 7068 1530 None None

DnsAg/ serverQueryTimeouts, serverQueryFailures DnsAg/ clientQueries, cacheHits , serverQueries DnsAg/ serverPendingQueries

Inter-shelf Connectivity Activity Congestion

Set � 7039 1000 Set � 7039 2000 Set � 7041 0150 MSG � 7041 0251 MSG � 7039 4000 Set � 7039 4001 MSG � 70392001 Set � 7039 5000

Atmif/ Vcc/ rxCell, txCell Atmif/ Vcc/ txCellDiscard, txCellDiscardClp, txFrameDiscard, txFrameDiscardC, rxCellDiscard, rxCellDiscardClp, rxFrameDiscard, & rxFrameDiscardClp

LAIF Instance Connectivity Activity Congestion

Set � 7086 1026 None None Set � 7068 1525

Logical Processor Activity Congestion

None Set � 7013 0022

Lp/ cpuUtil cpuUtilAvg, memoryUsage normalRam

SAS Instance

Set � 7068 1026



Hard Disk Activity

Set � 7068 1001 Set � 7068 1002

Sas/ openScdrs , openMcdrs, closedScdrs, smoCdrs, smtCdrs Sgsn Acct cdrCapture Gsc/ Gmm detachesSuccessful Gsc/ Sm mobileInitDeacts, ggsnInitDeacts

TCAP and Map Stack Instance Connectivity Activity Congestion

Set � 7068 1025 Set � 7068 1523 Set � 0000 1000 Set -- 7068 1515 Set -- 7068 1516 Set -- 7068 1517 None MSG � 7068 1495 MSG � 7068 1533 MSG � 7068 1534 MSG -- 7068 1536 Set � 7068 1505 Set � 7068 1506 Set � 7068 1509 Set � 7068 1510 Set -- 7068 1513 Set -- 7068 1514

Tcap/ invokeSent , invokeReceived Tcap/ currentTransaction, maxTransactionsPerSubsystem, concurrentInvokesLowBySs, concurrentInvokesAvgBySs, concurrentInvokesHighBySs

Services Mobile Attach

Activity Attach Failure

Set � 7068 1006 Set � 7068 1531 None

Gsc/ Gmm currentlyAttached Gsc/ Gmm attachRejPacketNetworkFailure, attachRejSgsnCongestion, gmmAttRejStats Gsc/ Mcc/ Mnc/ Lac/ Rac/ Cid/



CPU Utilization Max Subs reached

None MSG � 7068 1009 MSG � 7068 1005

attachRejPacketNetworkFailurePerCell, attachRejSgsnCongestionPerCellis, gmmCellOper

Billing None RAU/IRAU

Periodic RAU I/F Intra RAU I/F Inter SGSN RAU I/F

GMM T3 Tnl Timeout Insufficient Resources Excessive IRAU or RAU Failure Indications

None None None None MSG � 7068 1009 Set - 7068 1006 MSG � 7068 1005 None

Gsc/ Gmm periodicIntraSgsnRaUpdate Gsc/ Gmm normalIntraSgsnRaUpdate Gsc/ Gmm interSgsnRaUpdateAccepts, currentlyAttached Gsc/ GtpM sgsnContextReqAttempts, sgsnContextAcks, sgsnContextReqExhaust Gsc/ Gmm t3Timeouts None Gsc/ Gmm totalIrauRejects, totalRauRejects

Activation and Deactivation Interfaces GSD Session Failure DNS Failure


Gsc/ Sm sgsnInitDeacts, ggsnInitDeacts, mobileInitDeacts Gsc/ Sm sgsnInitDeacts Gsc/ Sm reactivationsRequested DnsAg/ serverQueryTimeouts,



Gn Connection Failure

GSD Resource Failure GSC Resource Failure Activiation Reject SGSN Initiated Deactivations Overload

MSG � 7068 1005 MSG � 7068 1012 MSG � 7068 1005 None MSG -- 7068 1029 None

serverQueryFailures, serverQueryFailures Gsc/ GtpM gprsGtpMgmtOp, peakTransactions, currentTransactions

CAMEL Activations None SGSN/MS PDP Context Mod

Interfaces Congestion

None None

Gsc/ Sm sgsnInitModifyAttempts sgsnInitFailAtGgsn, msInitFailAtGgsn, msInitFailAtMs Gsc/ Sm msInitFailAtSgsn, sgsnInitFailAtSgsn

Short Message Service MSG -- 7068 1030 MSG -- 7068 1031

Prepaid Short message Service Connectivity Activity Congestion

None None None

Gsc/ Psms Scp nccploginFailures, nccpLoginResponseTimeout Gsc/ Psms Scp totalTransactionSuccesses vs. totalTransactionFailures Gsc/ Psms peakConcurrentTransactions

Packet Flow Management Connectivity Activity

None None

Gsc/ Pfm t7RetryExpires Gsc/ Pfm downloadBssPfcRx, createBss,PfcsTx, createBssPfcAcksRx, CreateBssPfmNacksRx, ModifyBssPfcsRx, ModifyBssPfcAcksTx, and DeleteBssPfcsTx



Congestion None Gsc/ Pfm t7RetryExpires, CreateBssPfmNacksRx



6 Glossary

ATM Asynchronous Transfer Mode BSS Base Station System BSSGP Base Station System GPRS Protocol BVC BSSGP Virtual Circuit BVCI BSSGP Virtual Circuit Identifier CAMEL Customized Applications for Mobile Network Enhanced

Logic CDR Call Detail Record CGF Charging Gateway Function CoS Class of Service CP Control Processor CPU Central Processing Unit DNS Domain Name Server DLCI Data Link Connection Identifier FP Functional Processor GGSN Gateway GSN GIPS GPRS IP Server GPRS General Packet Radio System GSM Global System for Mobile communications GSN GPRS Support Node GTP' GPRS Tunneling Protocol Prime GTP GPRS Tunneling Protocol GTL GPRS Transport Layer HLR Home Location Register HP Hewlett Packard IETF Internet Engineering Task Force IP Internet Protocol IRAU Inter-SGSN Routing Area Update ITU International Telecommunication Union LIAF Lawful Intercept Access Function LICP Lawful Intercept Common Protocol LIG Lawful Intercept Gateway LLC Logic Link Controller LP Logical Processor



M-CDR Mobility Call Detail Record MDM Meridian Data Manager MG Media Gateway MM Mobility Management MS Mobile Station MSA Mobile Serving Area MSC Mobile Switching Center NSAP Network Service Access Point NSE Network Service Entity NS-VCs Network Service Virtual Circuit OAM Operations, Administration, and Maintenance OS Operating System PCU Packet Control Unit PDP Packet Data Path PDU Packet Data Unit PNNI Private-Network-to-Network-Interface PS Packet Switch PtpBvc Point-to-point BVC QoS Quality of Service SAS SGSN Accounting System SCCP Signaling Connection Control Part S-CDR SGSN Call Detail Record SCP Service Control Point SGSN Serving GPRS Support Node SIG SS7/IP Gateway SigBVC Signaling BSSGP Virtual Channel SM Session Management SMS Short Message Service SS7 Signaling System #7 SVC Switched Virtual Circuit TCAP Transaction Capabilities Application Part TCP Transmission Control Protocol UDP User Datagram Protocol UMTS Universal Mobile Telecommunications System VLR Visitor Location Register

test

Family Product Manual Contacts Copyright Confidentiality Legal

GPRS


To order documentation from Nortel Networks Global Wireless Knowledge Services, call (1) (877) 662-5669

To report a problem in this document, call(1) (877) 662-5669or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site athttp://www.nortelnetworks.com/td

Copyright 2003 Nortel Networks, All Rights Reserved

NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein.

Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant.

* Nortel Networks, the Nortel Networks logo, the Globemark, Unified Networks, Passport, and DMS-HLR are trademarks of Nortel Networks. GSM is a trademark of GSM MOU Association.Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.Document number: 411-5221-050Product release: GPRS5.0Document version: Standard 02.01Date: October 2003Originated in the United States of America

Gprs

Documents

nortel networks logo

trademarks of nortel

property of nortel networks

unified networks

nortel networks411

confidential information

standard version

document version