Gprs

GPRS
SGSN Monitoring Guide

GPRS5.0 Standard 02.01 October 2003 411-5221-050.02.01
Whats inside...
Introduction
External Interface View
SGSN Functional Components
Services
Summary of OAM Indicators
Glossary
411-5221-050
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-050
Product release: GPRS5.0
Document 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.
ii
Nortel Networks Confidential Copyright ! 2003 Nortel Networks
411-5221-050 Standard 02.01 October 2003
iii
GPRS SGSN Monitoring Guide GPRS5.0
Publication history
October 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.
iv Publication history
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 Nortels 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 Nortels 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 Internationals 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 Users 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)
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)
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)
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 theres 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 BVCs 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 Bvcs 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
doesnt 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 components 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 subscribers 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 applications 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
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 cant 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
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
D
B
Query 1
Response
1
Application DNS Agent
Response
2

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
C
P
-
N
M
MSA
(GTL)
MSA
(GTL)
G
S
D
G
S
D
G
S
D
G
S
D
G
S
D
G
S
D
O
C
3
O
C
3
L
A
N
L
A
N
C
P
-
N
M
CP3 -
NM

CP3 -
NM
Empty 4pOC3 GSC
(2pGp
Dsk)
GSC
(2pGp
Dsk)
4pOC3 Empty
Empty

Empty Empty Empty SAS
(2pGp
Dsk)
SAS
(2pGp
Dsk)
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.

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.


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 messages
Over TCP/IP
GPRS IP Network GSM SS7 Network
(
Gr/Gd )
(Gr)
(Gs)
(Gd)
(Gs)
SIG
SCP
(Ge)
SCIP messages
Over 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 yl o a d
S C IP
T C P
IP
E h t er n et
S C C P P a yl o a d
S C C P
M T P
L a y er 2
L a y er 1
In t er w or k i n g
S C IP
T C P
IP
S C C P
M T P
L a ye r 2
E h t er n et L a ye r 1
S G S N
P a s s p o r t
S IG
S S 7
N et w o r k
E l e m en 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. ISDs, Cancel
Locations, DSDs, 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.
SGSN

UDTReq() (may contain a MAP UGL message)
Gateway



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

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.21.1 UNDEFINED 0 6 OUTOFSVCE 0
8 OUTOFSVCE 0
Remote: 1.21.2 UNDEFINED 0 248 OUTOFSVCE 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 TRCCNTRLMSG
Debug 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.


***************************************************
***************************************************
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
status = 0
***************************************************
***************************************************
ACTION:
None

Figure 20 Example Registration Request/Response logs



***************************************************
***************************************************
PROBLEM:
Received a DeRegistration Request
***************************************************
IP Address = 47.104.77.163
Port Number = 11005
Connection ID = 5
***************************************************
***************************************************
ACTION:
Calling TableManager and Retreving Tuple info

***************************************************
***************************************************
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
***************************************************
***************************************************
ACTION:
None

***************************************************
***************************************************
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
status = 0
***************************************************
***************************************************
ACTION:
none



Figure 21 Example SGSN subsystem de-registration logs



4 Services
4.1 Mobile Attach

MS
7
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
Gr
Ga
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.

MS
7K
Frame Relay
E1/T1
GTL
WPDS
GSD
7K
GSD
(LLC)
OC3
7K
SIC
ATM I/F
ATM MPE
4POC3
15K
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
2PGPDSK
TCAP/MAP
15K
SIG
HP
TCP/IP
SIPR
SS7
Network
Gb
15K
LAN
7K To
GGSN or
Old
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 mobiles
attachment and the contexts related to all of the mobiles 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
manufacturers 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
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.
MS
7
Frame
Relay
E1/T1
WPDS
GSD
7
GSD (LLC)
GSD (LLC)
GSD
OC3
7
SIC
ATM I/F
4POC
15
SIC
ATM I/F
2PGPDSK
SAS
15
SAS
2PGPDSK
GSC/DNS
Agent 15
GSC
CGF
SGSN
Global
TCP/IP
secure
network
Partial SCDR
LA
7
SIC
ATM I/F
Gn over
100Base
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
cant 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.


MS
7
Frame Relay
E1/T1
GTL
WPDS
GSD
7
GSD (LLC)
GSD (LLC)
GSD
(SNDCP)
OC3
7K
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
LA
7
Gn over
100Base
Bearer
Data
To
GGS
SIG
HP
TCP/IP
SS7
Netwo
rk
TCAP/MAP
GIPS
2PGPDSK
TCAP/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.

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
MS
7
Frame
Relay
WPDS
GSD
7
GSD (LLC)

OC3
7
SIC
ATM I/F
4POC3
15
SIC
ATM I/F
ATM MPE
2PGPDS
K

GSC
SI
H
SGSN
Global
TCP/IP
secure
network
TCP/IP
SIPR
SS7
Network
SMS
Initiated
2PGPDS
K
15
SAS
2PGPDSK
TCAP/MA
15
TCAP/MAP
GIPS
SMT-CDR
7
Gb
15
LAN
7
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)
MS
7
Frame
Relay
WPDS
GSD
7
GSD
(LLC)
OC3
7
SIC
ATM I/F
ATM MPE
4POC3
15
SIC
ATM I/F
ATM MPE
2PGPDSK
GSC
15
2PGPDSK
TCAP/MAP
15
CGF
SGSN
Global
TCP/IP
secure
network
SIG
HP
TCP/IP
SS7
Network
2PGPDSK
SAS
15
SAS
TCAP/MAP
GIPS
SMO-CDR
SC
Gb
Ge
LA
7
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
clusterIds 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 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

Set 7068 1523

None

None

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

Set 7068 1532

None

None

Gsc/ Sm sgsnInitDeacts, ggsnInitDeacts,
mobileInitDeacts

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-5669
or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site at
http://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-050
Product release: GPRS5.0
Document version: Standard 02.01
Date: October 2003
Originated in the United States of America

Gprs

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Gprs

Încărcat de

Drepturi de autor:

Formate disponibile

GPRS

SGSN Monitoring Guide

S-ar putea să vă placă și