411 5221 926 - 11.06

411-5221-926
Nortel GGSN
User’s Guide
GGSN 6.0 Standard 11.06 September 2008

test
Nortel GGSN
User’s Guide
Document number: 411-5221-926

Product release: GGSN 6.0
Document version: Standard 11.06
Date: September 2008
Copyright Country of printing Confidentiality Legal statements Trademarks
Copyright © 2000–2008 Nortel, All Rights Reserved

Originated in the United States of America/Canada
While the information in this document is believed to be accurate and reliable, except as otherwise expressly agreed to in writing
NORTEL PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OR CONDITION OF ANY KIND, EITHER EXPRESS OR
IMPLIED. The information and/or products described in this document are subject to change without notice.
Nortel, Nortel Networks, the Nortel logo, and the Globemark are trademarks of Nortel Networks.
All other trademarks are the property of their respective owners.

ii
Copyright © 2000–2008 Nortel Networks
411-5221-926 Standard 11.06 September 2008

iii
Publication history
September
GGSN 6.0 Standard 11.06.
Case 080909-56998 has been resolved. Table 9-4 and Table 9-8 have
been updated to correct ordering of the Direct Tunnel related counters.
August 2008
GGSN 6.0, Standard 11.05. This is the standard release of this
document.
May 2008
GGSN 6.0, Preliminary 11.04.
Modified Figure i, "PC05 Documentation Roadmap" on page xxiii
May 2008
GGSN 6.0, Preliminary 11.03. This is the preliminary release of this
document.
Changed Nortel GGSN User Guide to Nortel GGSN User’s Guide.
February 2008
GGSN 6.0, Draft 11.02. Updated information regarding the Continuous
Time Period Time Event Charging feature.
December 2007
GGSN 6.0, Draft 11.01. Updated information regarding the following
features
• Cabcharge L2TP Authentication

• Dual Coupon Tariff Switch
• Direct Tunnel
Nortel GGSN User’s Guide GGSN 6.0

iv Publication history Copyright © 2000–2008 Nortel Networks
• TCP MSS Clamping

• Billing Enhancements
• Idle Session Verification
• GELC Gn Packet Fragmentation
• 3GPP Standards Conformance
April 2007
GGSN 5.0.1, Standard 10.38. The following CR has been updated.
CR Q01573968 - Missing information in output of Event tracetool.

Chapter 9, “Event Trace” updated.
December 2006
GGSN 5.0.1, Standard 10.35.
June 2006
GGSN 5.0, Standard10.07. This is the standard release of this
document.
April 2006
GGSN 5.0, Preliminary 10.06. Updated for change requests.
February 2006
January 2006
GGSN 5.0, Preliminary 10.03. Updated for SME comments and
change requests.
December 2005
GGSN 5.0, Preliminary 10.02.
October 2005
GPRS 7.0/UMTS 5.0, GGSN 5.0 10.01. This is the initial draft release
of this document for GGSN 5.0.
September 2005
GPRS 6.0/UMTS 4.0, 09.06. This Preliminary version incorporates
updates for the following CRs:

Publication history v
• Q01090690 - add two sentences to opening paragraph of

“Diameter Credit Control (DCC) Alarms”; change severity to Minor
for alarmClear in “GGSN DCC Alarms”; remove second entry in
“GTP Accounting SNMP Events”; remove section SNMP Chassis
Alarms and table 9-74 between “SNMP SCS Server Alarms” and
“SNMP System Alarms”.
• Q01199431 - replace Figure 8-46
• correct Figure 8-47, Figure 8-49, and Figure 8-50
• Q01216025-01 - update entry SCP in Table 9-1
• Q01200479 - add text for Aggregation APN behavior in “Subscriber
Service Module (SSM) redundancy”, paragraphs 1 and 6.
• updated collection method to Low Tidemark Gauge for Table 9-13
entry 6; updated collection method to Gauge for entry 1 in Table 9-
3 through Table 9-24.
August 2005
GPRS 6.0/UMTS 4.0, 09.05. This Preliminary version reorders 4.1
feature summary and added PMID 29001 in Table 1-6, and
incorporates updates for the following GGSN 4.1.1 PMIDs:
• 28344 - “Content Based Billing” paragraph 11; “Service Redirect”

paragraphs 4 and 13; and Limitations for “Prepaid Service”
• 28340, 28388, 28545 - “Conditions for accounting record
generation” bullets 2(modified) and 3(new); “RADIUS Accounting”
bullet 4 (modified); “Total resource usage reporting”; replace Figure
8-17; add two entries to Table 8-14; replace Figure 8-24; add one
entry to Table 8-21; replace Figure 8-46; add one entry to Table 8-
33.
• 28607 - “Initial coupon IDs”
• 29082 - “Content Based Billing”, bullet 14 under supported
functionality
July 2005
GPRS 6.0/UMTS 4.0, 09.04. This Standard version incorporates
updates for GGSN 4.1, and CRs:
• Q01005640 (IP Routing)

• Q01047753 (OAM)
• Q01047768 (OAM)
• Q01065315 (Functional Description)
• Q01075378 (Redundancy)

vi Publication history Copyright © 2000–2008 Nortel Networks
• Q01080072-01 (OAM)
• Q01081352-01 (“Outgoing to Internet and Intranet using GRE
tunnel”)
• Q01085756 (OAM)
• Q01093522 (“Diameter Credit Control (DCC) Event Logs”)
• Q01075378 (Redundancy)
• Q01084380 (OAM)
• Q01093522 (OAM)
• Q01094475 (IP Services)
• Q01100746 (“Route redundancy”)
• Q01109982-02 (Provisioning)
• Q01123395 (IP Services)
• Q01160679 (Appendix B: Detailed Protocol Information)
• Q01170977 (Product Limitations chapter) - added per CR, then
removed
• remove “Upgrade strategy” procedures and add reference to
Upgrade NTP
• add overview and pointer to “SCS backup and restore” procedures
in Upgrade NTP
March 2005
GPRS 6.0/UMTS 4.0, 09.03. Incorporated updates to parameter
definitions and values, and branding changes for Nortel, SER 5500,
VPN Router, W-NMS.
February 2005
• GPRS 6.0/UMTS 4.0 09.02. Incorporated change to CR
Q01065148 and updated screen captures.
• GPRS 6.0/UMTS 4.0 09.01. This draft version for the GPRS 6.0
and UMTS 4.0 (GGSNS 4.1) releases includes updates for GGSN
4.1.
January 2005
GPRS 6.0/UMTS 4.0, 08.05. This Preliminary version for the GPRS
6.0 and UMTS 4.0 (GGSNS 4.0) releases includes updates for CRs.

Publication history vii
December 2004
6.0 and UMTS 4.0 (GGSNS 4.0) releases includes technical updates
for CRs and review comments.
December 2004
6.0 and UMTS 4.0 (GGSNS 4.0) releases includes information for
GGSNS 4.0.1.
September 2004
GPRS 6.0/UMTS 4.0, 08.02. This Preliminary version is updated for
the GPRS 6.0 and UMTS 4.0 (GGSNS 4.0) releases.
July 2004
GPRS 6.0/UMTS 4.0, 08.01. This Draft version is updated for the
GPRS 6.0 and UMTS 4.0 (GGSNS 4.0) releases.
The organization of this document has the following changes from the
GGSNS 3.2 version:
• The chapter “Configuration procedures” was removed. All
configuration information is contained in GPRS/UMTS Nortel
Networks GGSN Procedures Reference Manual (411-5221-927).
• The appendix “Univity GGSN CLI” was removed. All CLI
information is contained in GPRS/UMTS Nortel Networks GGSN
Command Line Interface Guide (411-5221-922).
• Information on the RADIUS protocol is removed from appendix
“Detailed protocol information”. RADIUS protocol information is
contained in Nortel Networks GGSN RADIUS Interface Guide (411-
5221-928).
The name “Univity GGSN” is replaced with “Nortel Networks GGSN.”
May 2004
GPRS 5.0/UMTS 3.0, 07.03. This Standard version contains updated
information for the GPRS 5.0 and UMTS 3.0 (GGSNS 3.2) releases.
May 2004
GPRS 5.0/UMTS 3.0, 07.02. This is the Standard version for the
GPRS 5.0 and UMTS 3.0 (GGSNS 3.2) releases.
This version includes an additional chapter, “Product Conformance”.

viii Publication history Copyright © 2000–2008 Nortel Networks
Database backup and restore procedures have been moved to GPRS/

UMTS Univity GGSN Procedures Reference Manual (411-5221-927).
January 2004
5.0 and UMTS 3.0 releases is updated for the GGSNS 3.2 release of
the GGSN software.
October 2003
GPRS 5.0/UMTS 3.0, 06.05. This Standard version includes updated
information for the GPRS 5.0 and UMTS 3.0 releases.
Database backup and restore procedures are added to chapter

“OA&M”.
August 2003
GPRS 5.0/UMTS 3.0, 06.04. This Standard version for the GPRS5 .0
and UMTS 3.0 releases includes information for the GGSNS 3.1
release of the Shasta GGSN software.
June 2003
GPRS 5.0 and UMTS 3.0 releases.
November 2002
GPRS 5.0/UMTS 3.0, 06.02. This Preliminary version contains
updated information for the GPRS5.0 and UMTS3.0 releases.
September 2002
GPRS 5.0/UMTS 3.0, 06.01. This Draft version contains updated
information for the GPRS5.0 and UMTS3.0 releases.
September 2002
August 2002
GPRS 4.0/UMTS 2.0, 05.04. This Preliminary version includes
updates for Change Requests (CRs) and information about GRE VPN.
May 2002
updated information for the GPRS 4.0 and UMTS 2.0 releases.

Publication history ix
April 2002
updated information for the GPRS 4.0 and UMTS 2.0 releases.
March 2002
GPRS 4.0/UMTS 2.0, 05.01. This Draft version contains updated
information for the GPRS 4.0 and UMTS 2.0 releases.
February 2002
October 2001
GPRS 3.0/UMTS 1.2, 04.02. This is the Preliminary version for the
October 2001
GPRS 3.0, 04.01. This Draft version contains updated information for
the GPRS 3.0 release.
September 2001
GPRS 2.1, 02.02. This is the Standard version for the GPRS 2.1
release.
July 2001
UMTS 1.1, Preliminary 03.01. This Preliminary version contains
updated information for the UMTS 1.1 release.
July 2001
GPRS 2.1, 02.01. This Preliminary version contains updated
information for the GPRS 2.1 release.
June 2001
updated information for the GPRS 2.0 release.
May 2001
UMTS 1.0, 01.03. This Preliminary version contains updated
information for the UMTS 1.0 release.
January 2001
UMTS 1.0, 01.02. Release for the UMTS 1.0 Alpha trial.

x Publication history Copyright © 2000–2008 Nortel Networks
December 2000
UMTS 1.0, Draft 01.01. Document creation.

xi
Contents 1
About this document xxi

Audience for this document xxi
Organization of this document xxi
Related documents iii-xxiii
Roadmap to Packet Core 05 documentation xxiii
Specifications xxiv
Services Edge Router 5500 documentation xxv
Nortel Wireless Network Management xxv
Related training xxvi
Indication of hypertext links xxvi
Nortel branding xxvi
Release feature contents 1- 1

UMTS 3.0/GPRS 5.0 and Prior Releases 1-1
GGSN Functionalities Description 1-1
Feature Description 1-3
Release Line Up 1-11
UMTS 4.0/GPRS 6.0 1-11
GGSN 4.0 Description 1-12
GGSN4.1 Description 1-17
GGSN 5.0 1-22
Functionalities Description 1-22
GGSN 5.0.1 1-26
GGSN 6.0 1-29
Introduction 2- 1
GGSN interfaces 2-3
Ga interface protocol 2-3
Gc interface protocol 2-4
Gn/Gp interface protocol 2-4
Gi interface protocols 2-6
Gy Interface Protocol 2-6
Gx Interface Protocol 2-7

xii Contents Copyright © 2000–2008 Nortel Networks
GGSN services 2-8
Functional description 3- 1
Overview 3-1
Functional concepts 3-3
Internet Service Provider (ISP) 3-3
Access Point Name 3-12
Subscriber Template 3-13
RAT Mapping 3-13
GTP protocol 3-14
Multiple primary PDP contexts 3-14
Secondary PDP Context 3-15
Protocol interaction 3-15
IP PDU type 3-15
PPP PDU type 3-18
Path management 3-21
Idle Session Verification 3-22
Direct Tunnel 3-23
GTP-U sequence numbers 3-23
APN Selection Mode 3-23
Subscriber Username 3-24
P-CSCF discovery 3-24
IM CN Subsystem Signalling flag 3-24
HSDPA Parameters 3-25
QoS Signalling Indication 3-25
Single Access Point Name 3-25
Vendor Specific Attributes (VSA) 3-27
VPN membership 3-27
IP Services 3-30
Real-time charging subscription 3-31
Outbound tunneling 3-31
IP Address Pool 3-34
Single APN Accounting 3-34
Aggregation Access Point Name 3-35
Subscriber Access Control 3-35
Visiting GGSN (V-GGSN) Access Control 3-35
Subscriber authentication 3-36
IP address allocation 3-39
RADIUS 3-39
DHCP 3-40
Local address pool 3-46
Static IP address 3-46
GGSN accounting 3-47
GTP accounting 3-47
Regular billing 3-49
Hot billing 3-50
GTP’ protocol 3-51
Tariff Based Billing 3-52
Accounting record generation 3-53
Automated Accounting Record Transfer 3-58

Contents xiii
G-CDR Auditing 3-61

RADIUS Accounting 3-65
RADIUS Accounting record storage 3-68
Fault Tolerant Billing 3-70
Content Based Billing 3-70
Partial billing for roamers 3-71
Tunneling on the Gi interface 3-72
GTP-L2TP tunnel switching 3-72
Outgoing to intranet using IPSec tunnel 3-78
Outgoing to Internet and Intranet using GRE tunnel 3-82
Outgoing to Internet and Intranet using VLAN Tagging 3-85
Outgoing to Intranet via MPLS 3-87
Quality of Service (QoS) 3-90
Mapping of DSCP marking to TOS value 3-91
Uplink data packet QoS 3-92
Downlink data packet QoS 3-93
Control packet QoS 3-93
ATM L2 Service Classes 3-94
GGSN Administration and Maintenance 3-95
Gi Interface Availability 3-95
Overload control 3-97
APN Blacklisting 3-105
Secure SCS network connections 3-106
Health Check Monitor (HCM) 3-107
Wireless services 3-109
Real-time charging service 3-109
Dual Coupon 3-125
GeoZone service 3-127
WAP service 3-127
Policy merging 3-132
SGSN Grouping 3-133
Lawful Interception (LI) 3-134
Traffic Performance Optimizer (TPO) 3-136
Clientless server mode 3-136
Client-server mode 3-136
Network deployment models 4- 1

Overview 4-1
Network models 4-1
Wireless ISP model 4-5
Wireless ISP GRE access 4-6
Wireless ISP VLAN access 4-7
L2TP VPN model 4-8
VPN variants 4-10
IPSec VPN model 4-10
GRE VPN model 4-11
ATM VPN model 4-12
VLAN VPN model 4-13
GGSN VPRN model 4-14
MPLS VPN model 4-15

xiv Contents Copyright © 2000–2008 Nortel Networks
VLAN eBGP VPN model 4-17

Wireless services deployment 4-18
WAP Service 4-18
Static RADIUS address allocation service 4-18
Dynamic RADIUS address allocation service 4-19
IP services 5- 1
Overview 5-1
Policy merging 5-2
IP Services for IP in IP 5-3
Firewall 5-5
Traffic Policing 5-5
Traffic Shaping 5-7
Policy-Based Forwarding 5-8
Web Steering 5-8
Personal Content Portals 5-9
DiffServ Marking 5-9
Anti-Spoofing 5-10
WAP 1.2/2.0 and HTTP 1.1 Redirection 5-10
WAP Connection-oriented Mode 5-11
WAP Packet Rating 5-12
HTTP 1.1 Redirection 5-16
Content Based Billing 5-17
WAP filter overview 5-21
WAP overview 5-21
WSP connection-mode and connectionless session services 5-22
WAP and MMS 5-22
WAP filter 5-22
Event Based Billing 5-24
Event definition and triggers 5-24
Event and Non-Event Traffic 5-25
Event completion optionality 5-27
Per-GET billing for HTTP and WSP 5-27
Dynamic Policy Control 5-27
Charging Rule Modification 5-28
Content Filtering 5-31
ISP security services 5-33
ISP Node Services 5-33
Management Services 5-39
Security Policy definition 5-39
Security Policy examples 5-39
Application of Management Services 5-41
Traffic Performance Optimizer (TPO) Interworking 5-41
Flow Management 5-43
IP routing 6- 1
Overview 6-1
Wireless ISP model routing 6-2
Aggregation APN 6-4
L2TP VPN model 6-4

Contents xv
GGSN VPRN model 6-5

GRE VPN model 6-5
Multi-Protocol Label-Switching (MPLS) 6-6
BGP operation 6-6
MPLS Signalling 6-7
MPLS Forwarding 6-8
Explicit FEC (EFEC) Service 6-10
MPLS/BGP VPN topologies 6-11
E-LSP support 6-12
MPLS Management VPN 6-13
OSPF-TE 6-13
IS-IS routing 6-14
Subscriber IP address management 6-15
IP Subnet Dedication 6-16
Route redundancy 6-20
Gn Interface ECMP 6-22
Layer 2 switched networks 6-22
Proxy ARP 6-22
Gratuitous ARP 6-23
IP multicast 6-23
IP address in GTP signaling message 6-23
GTP Version 0 6-24
GTP Version 1 6-25
Source Address in RADIUS/DHCP Message 6-25
SINK routes 6-27
Hardware and engineering 7- 1

Overview 7-1
Services Edge Router hardware description 7-1
Physical connectivity 7-2
Line card function limitations 7-2
SCS server and client 7-4
GGSN configuration 7-9
Engineering configuration 7-9
ISP configuration on GGSN 7-10
CGF Profile on GGSN 7-10
APN configuration on GGSN 7-10
Tariff Profile on GGSN 7-11
IP Subnet Dedication on GGSN 7-11
Single APN on RADIUS Server 7-12
GTP-L2TP Tunnel Switching on LNS 7-12
Address allocation on RADIUS Server 7-12
Prepaid Service on SCP 7-13
GUI Provisioning 8- 1
Overview 8-1
SCS Graphical User Interface 8-1
Access Properties Provisioning 8-1
GGSN Profiles and Templates 8-3
CORBA API User Interface 8-229

xvi Contents Copyright © 2000–2008 Nortel Networks
CORBA Shell Commands 8-229
OA&M 9- 1
Overview 9-1
Operation Measurements 9-1
Historical Statistics 9-2
SER Base OMs 9-119
SER Base CLI statistics 9-124
Alarms 9-125
SNMP Traps 9-126
GGSN SNMP Traps 9-127
SER Base SNMP Traps 9-169
SNMP Traps 9-229
Event Logs 9-229
GGSN Event Logs 9-231
Patch profile verification started 9-264
Patch Profile Verification Completed 9-264
Information on patch profile 9-267
SER Base Event Logs 9-272
Event Trace 9-311
Event Trace Logs 9-312
Standard Event Logs 9-321
System Time 9-322
Software Optionality Control (SOC) 9-323
Active Session Management (ASM) 9-323
CLI Command 9-330
Patching System 9-330
Upgrade Strategy 9-331
SCS Backup and Restore 9-331
Functional Description 9-331
Local Full System Backup/Restore 9-332
Essential Data Backup/Restore 9-332
Archival and Retrieval of Dynamic Data 9-334
Restrictions / Limitations 9-334
GDC Tool (GGSN Data Collector) 9-335
Background: 9-335
Introducing GDC (GGSN Data Collector) 9-336
Recommendations: 9-336
Running GDC: 9-336
Products and Releases: 9-337
Product limitations 10- 1

GGSN Hardware 10-1
GGSN and SCS Software 10-2
GTP and GTP’ Protocol Interface 10-3
RADIUS Authentication and Accounting 10-6
DHCP address allocation 10-7
SCS Provisioning 10-7
OA&M 10-9
GGSN QoS 10-10

Contents xvii
APN 10-10
Prepaid Service 10-11
IP Services 10-12
IP Routing 10-16
Restrictions for the VLAN BGP VPN Solution 10-16
Redundancy 11- 1
Nortel GGSN 11-1
Control and Management Card (CMC) redundancy 11-1
Subscriber Service Module (SSM) redundancy 11-1
Switch Fabric Card (SFC) redundancy 11-3
Interface redundancy 11-4
GRE Tunnel redundancy 11-4
ATM port redundancy 11-4
Service Creation System (SCS) Server 11-5
Charging Gateway Function (CGF) 11-5
Prepaid Server 11-6
Diameter Credit Control Server 11-6
Application Server 11-6
RADIUS Server 11-7
RADIUS Authentication Server 11-7
RADIUS Accounting Server 11-7
DHCP Server 11-9
FTP Server 11-9
Traffic Performance Optimizer (TPO) Server 11-9
Product Conformance 12- 1

Overview 12-1
GPRS Specifications 12-1
3GPP TS 09.60 version 7.10.0 12-1
3GPP TS 09.61 version 7.10.0 12-5
UMTS Specifications 12-7
3GPP TS 23.060 version 6.7.0 12-7
3GPP TS 23.107 version 6.2.0 12-15
3GPP TS 29.060 version 6.7.0 12-17
3GPP TS 29.060 version 7.5.1 12-24
3GPP TS 29.061 version 6.3.1 12-24
3GPP TS 29.210 version 6.0.0 12-28
3GPP TS 32.015 version 3.2.0 12-33
3GPP TS 32.015 version 3.6.0 12-37
3GPP TS 32.299 version 7.6.0 12-41
RFC Specifications 12-41
RFC 2131 - Dynamic Host Configuration Protocol (DHCP) 12-41
RFC 2865 - Remote Authentication Dial In User Service (RADIUS) 12-45
RFC 2866 - RADIUS Accounting 12-48
RFC 1661 - Point-to-Point Protocol (PPP) 12-49
RFC 2661 - Layer Two Tunneling Protocol (L2TP) 12-50
RFC 2858 - Multiprotocol Extensions for BGP-4 12-54
RFC 2547bis (draft-ietf-ppvpn-rfc2547bis-02.txt) 12-54
RFC 3036 - LDP Specification 12-57

xviii Contents Copyright © 2000–2008 Nortel Networks
RFC 3588 - Diameter Base Protocol 12-61

IETF Draft RFC - Diameter Credit Control (draft-ietf-aaa-diameter-cc-03.txt) 12-
61
RFC 2616 - Hypertext Transfer Protocol - HTTP/1.1 Specification 12-61
RFC 2702 - Requirements for Traffic Engineering Over MPLS 12-61
RFC 2205 - Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification 12-63
RFC 3209 - RSVP-TE: Extensions to RSVP for LSP Tunnels 12-65
RFC 3630 - TE Extensions to OSPF Version 2 12-68
Patching System A-1

GGSN CMC and SSC patching A-1
Patch Package A-1
Patching functions A-2
Persistency operation A-2
Patching directives A-2
Verify operation A-2
Query operation A-2
Sync operation A-3
Unapply Operation A-3
GGSN upgrade strategy A-3
Patching privileges A-3
Reference A-3
Detailed Protocol Information B-1

GTP Protocol Extension B-1
Private Extension IE B-1
IMS Protocol Configuration Options IE B-3
GTP’ Charging Protocol B-5
G-CDR Record Format B-5
G-CDR Management Extensions B-12
Timestamp format B-49
G-CDR Traffic Volume B-50
Billing Disk File B-50
Storage and Retrieval of G-CDR Files on the Local Disk B-52
RADIUS Protocol B-54
WRAP Protocol B-55
RFC Attributes B-55
3GPP Vendor Specific Attributes B-56
Card Telephony Protocol (CTP) B-56
Basic Single-Coupon Prepaid Service B-56
Multi-Coupon Prepaid Service B-58
Diameter Credit Control (DCC) protocol B-65
Diameter Client-Server Connection Establishment B-65
Basic Message Flow for a Diameter Credit Control Session B-66
Diameter Credit Control Session Flow with Service Redirect B-66
Parking Meter Charging Model B-67
Diameter Credit Control Failure Handling B-68
Charging Upon Conversion to a Postpaid Session B-73
IPSec Support B-73

Contents xix
Dynamic Coupon Control B-74
List of terms C-1

xx Contents Copyright © 2000–2008 Nortel Networks

xxi
About this document 1

This document provides the functional description and deployment
information for the Nortel Gateway GPRS Support Node (GGSN)
product. This document covers mainly Nortel GGSN related functional
information. The GGSN functionality is built on the Nortel Services
Edge Router 5500* (SER 5500) hardware platform. In this document,
the Nortel Services Edge Router 5500 along with GGSN functionality
is referred to as the Nortel GGSN.
Audience for this document 1

This document is intended for persons involved in the planning,
engineering, administration, or maintenance of the Nortel GGSN in a
GPRS or UMTS network.
It is assumed that the reader has a general familiarity with GPRS/

UMTS networks, standards, and basic knowledge of the configuration
and terminology of the IP network.
Organization of this document 1

Information in this document is organized as follows:
• Chapter 1, “Release feature contents”—summarizes the GGSN
functionality deployed in different product line releases.
• Chapter 2, “Introduction”—provides a summary of the GPRS/
UMTS network, interfaces and GGSN services.
• Chapter 3, “Functional description”—describes the GGSN specific
functionality on the Nortel GGSN.
• Chapter 4, “Network deployment models”—describes the Nortel
GGSN network configuration models.
• Chapter 5, “IP services”—describes the IP services that are
available and supported on the Nortel GGSN.
• Chapter 6, “IP routing”—describes the IP routing functions that are
available and supported on the Nortel GGSN.

xxii Copyright © 2000–2008 Nortel Networks
• Chapter 7, “Hardware and engineering”—describes the Nortel

GGSN hardware requirements and network engineering
information.
• Chapter 8, “GUI Provisioning”—describes the Nortel GGSN
specific graphical user interface (GUI) provisioning.
• Chapter 9, “OA&M”—describes the SER 5500 base and Nortel
GGSN specific Operational Measurements, logs, alarms and
monitoring as well as other OA&M functionality.
• Chapter 10, “Product limitations”—describes the limitations of
Nortel GGSN functionality.
• Chapter 11, “Redundancy”—describes the Nortel GGSN software
and network configuration redundancy.
• Chapter 12, “Product Conformance”—specifies the State of
Compliancy (SOC) of the Nortel GGSN product to the GGSN
related standards.
• Appendix A, “Patching System”—describes the Nortel GGSN
Patching System.
• Appendix B, “Detailed Protocol Information”—lists GTP protocol
extension, GTP accounting and RADIUS related information on the
Nortel GGSN.
• Appendix C, “List of terms”—defines terms used in this document.

xxiii
Related documents 1
Roadmap to Packet Core 05 documentation
Figure i shows the NTPs in the documentation suite for PC05.
Figure i
PC05 Documentation Roadmap
F a u lt a n d
P la n n in g a n d In s ta lla tio n a n d O p e ra tio n s a nd P e rfo rm a nc e
C o n c e p ts U p g ra d in g
E n g ine e rin g C o m m is s io n in g A d m in is tra tio n M anagem ent
GGSN06 G G S N and S C S S G S N /G P R S S G S N P ro visio n in g SGSN SGSN

D o c u m e n ta tio n N e w in th is R e le a s e U p g ra d e P ro c e d u re s A cc o u n tin g M o n ito rin g G u id e
R oadm ap 4 1 1 -5 2 2 1 -2 0 0 4 1 1 -5 2 2 1 -3 0 7 4 1 1 -5 2 2 1 -9 0 4 4 1 1 -5 2 2 1 -3 1 2 4 1 1 -5 2 2 1 -0 5 0
4 1 1 -5 2 2 1 -0 0 4
SGSN S G S N /U M T S G G S N H a rd w a re SGSN SGSN
A b o u t th e W ha t's N e w U p g ra d e In s ta lla tio n a n d A dm in is tra tio n C o m p o n e n ts
U M T S N e tw o rk 4 1 1 -5 2 2 1 -2 0 2 4 1 1 -5 2 2 1 -3 0 8 M a in te n a n c e G u id e 4 1 1 -5 2 2 1 -3 1 3 4 1 1 -5 2 2 1 -0 6 0
4 1 1 -8 1 1 1 -5 0 2
4 1 1 -5 2 2 1 -9 2 3
P a c k e t C o re G G S N C om m a n d
T e rm in o lo g y S CS and G G S N SGSN
C o n fo rm a n c e G u id e L in e In te rfa c e (C L I)
4 1 1 -8 1 1 1 -8 0 4 U p g ra d e s G G S N P ro vis io n in g A dm in is tra tio n
4 1 1 -5 2 2 1 -2 0 1 G u id e
4 1 1 -5 2 2 1 -3 0 9 P ro c e d u re s 4 1 1 -5 2 2 1 -3 1 3
4 1 1 -5 2 2 1 -9 2 2
SGSN 4 1 1 -5 2 2 1 -9 2 7
SGSN
O ve rvie w AN GGSN SGSN
C a ll D e ta il R e c o rd s
U p g ra d e U se r’s G u id e A la rm s
4 1 1 -5 2 2 1 -3 1 1 4 1 1 -5 2 2 1 -2 0 4
4 1 1 -5 2 2 1 -3 1 0 4 1 1 -5 2 2 1 -9 2 6 4 1 1 -5 2 2 1 -5 0 0
GGSN SGSN
C o re N e tw o rk
U s e r’s G u id e B illin g S a m p le s G G S N P ro vis io n in g T ro u b le s h o o tin g
4 1 1 -5 2 2 1 -9 2 6 4 1 1 -5 2 2 1 -2 0 5 P ro c e d u re s G u id e
4 1 1 -5 2 2 1 -9 2 7 4 1 1 -5 2 2 1 -5 0 1
G G S N R A D IU S GGSN
In te rfa c e G u id e B illin g S a m p le s
G G S N C o rb a s h e ll G G S N A la rm s
4 1 1 -5 2 2 1 -9 2 8 4 1 1 -5 2 2 1 -2 0 6
C L I G u id e R e fe re n c e M a n u a l
4 1 1 -5 2 2 1 -9 2 9 4 1 1 -5 2 2 1 -9 2 1
S IG S G S N P la n n in g
U s e r G u id e & E n g in e e rin g
4 1 1 -5 2 2 1 -3 1 4 S IG GGSN
4 1 1 -5 2 2 1 -9 7 5 M o n ito rin g G u id e
U s e r G u id e
4 1 1 -5 2 2 1 -9 7 5 4 1 1 -5 2 2 1 -9 2 4
GGSN
U s e r’s G u id e GGSN
4 1 1 -5 2 2 1 -9 2 6 U s e r’s G u id e
4 1 1 -5 2 2 1 -9 2 6
S IG
U s e r G u id e G G S N C o rb a s h e ll
4 1 1 -5 2 2 1 -9 7 5 C L I G u id e
4 1 1 -5 2 2 1 -9 2 9
G G S N C o rb a s h e ll
C L I G u id e S IG
4 1 1 -5 2 2 1 -9 2 9 U s e r G u id e
4 1 1 -5 2 2 1 -9 7 5

xxiv Copyright © 2000–2008 Nortel Networks
Specifications
For more information about the GSM, UMTS, and other standards
specifications referred to in this document, refer to the following
documents:
• 3GPP TS 03.60, version 7.9.0, Service Description
• 3GPP TS 09.60, version 7.10.0, GPRS Tunnelling Protocol (GTP)
across the Gn and Gp Interface
• 3GPP TS 09.61, version 7.10.0, Interworking between the Public
Land Mobile Network (PLMN) and Packet Data Network (PDN)
• 3GPP TS 23.060, version 4.9.0, Service Description
• 3GPP TS 23.107, version 4.6.0, UMTS QoS Concept and
Architecture
• 3GPP TS 29.060, version 4.10.0, GPRS Tunnelling Protocol (GTP)
across the Gn and Gp Interface
• 3GPP TS 29.061, version 4.8.0, Interworking between the Public
Land Mobile Network (PLMN) supporting Packet Based Services
and Packet Data Network (PDN)
• 3GPP TS 32.015, version 3.2.0, Charging and Billing
• 3GPP TS 32.015, version 3.6.0, Charging and Billing
• ITU-T X.680 (07/94), OSI Networking and System Aspect -
Abstract Syntax Notation One (ASN.1)
• RFC 1661, The Point-to-Point Protocol (PPP)
• RFC 1701, Generic Routing Encapsulation (GRE)
• RFC 1702, Generic Routing Encapsulation (GRE) over IPv4
Networks
• RFC 1771, A Border Gateway Protocol 4 (BGP-4)
• RFC 2002, IP Mobility Support
• RFC 2131, Dynamic Host Configuration Protocol (DHCP)
• RFC 2236, Internet Group Management Protocol
• RFC 2283, Multiprotocol Extensions for BGP-4
• RFC 2401, Security Architecture for IP
• RFC 2406, IP Encapsulating Security Payload (ESP)
• RFC 2409, The Internet Key Exchange (IKE)
• RFC 2474, Definition of the Differentiated Services Field in the
IPv4 and IPv6 Headers
• RFC 2475, An Architecture for Differentiated Services

xxv
• RFC 2547, BGP/MPLS VPNs

• RFC 2547bis (draft-ietf-ppvpn-rfc2547bis-02.txt)
• RFC 2597, Assured Forwarding PHB Group
• RFC 2616, Hypertext Transfer Protocol - HTTP/1.1, June 1999
• RFC 2661, Layer Two Tunnelling Protocol (L2TP)
• RFC 2796, BGP Route Reflection: An Alternative to Full Mesh
IBGP
• RFC 2858, Multiprotocol Extensions for BGP-4
• RFC 2865, Remote Authentication Dial In User Service (RADIUS)
• RFC 2866, RADIUS Accounting
• RFC 2868, RADIUS Attributes for Tunnel Protocol Support
• RFC 3004, The User Class Option for DHCP
• RFC 3036, LDP Specification
• WRAP_IFSPEC, Wireless RADIUS Application Protocol (WRAP)
• GGSN-CTP Protocol Definition Version 3, Publication number
SB003575
• Nortel Networks GGSN Diameter Credit Control Technical
Specification version 2.12
Services Edge Router 5500 documentation
For more information about the Nortel Services Edge Router 5500, refer
to the following publications:
• Services Edge Router 5500 SCS Client GUI Overview and
Reference Guide
• Services Edge Router 5500 Overview
• Services Edge Router 5500 Provisioning Subscribers
• Services Edge Router 5500 Provisioning Service Policies
• Services Edge Router 5500 Provisioning VPNs, VLANS, and
Tunnels
• Services Edge Router 5500 CORBA API Reference
Nortel Wireless Network Management

Refer to Nortel Wireless Network Management System
Documentation Guide (411-5221-003), for a complete list of NTPs in
the Wireless Network Management documentation suite.

xxvi Copyright © 2000–2008 Nortel Networks
Related training 1
For questions regarding training courses for the Nortel GGSN, please
contact your local Nortel* representative for the latest course
identification, availability, and training center location.
Indication of hypertext links 1

Hypertext links in this document are indicated in blue. If viewing a PDF
version of this document, click on the blue text to jump to the
associated section or page.
Nortel branding 1
Nortel is changing the branding of some of its product lines. Part of this
effort includes changing the names of the products. New product names
have been created using the following format:
Nortel <function> <model>
where:
– <function> describes what function the product performs.

– <model> is a model series number.
For example, the Baystack 450 product has been renamed as the
Nortel Ethernet Switch 450. Some of the new product names are
quite lengthy. To make our documents easier to read, the product
names are shortened after their first occurrence. For example, the
Nortel Ethernet Switch 450 product name is referred to as the
Ethernet Switch 450 for second and subsequent occurrences.
To alleviate any confusion the rebranding might cause, Table i and

Table ii are provided. During the transition, both the existing product
names and the new product names may appear in the documentation
and software.
Table i details the original product names and their corresponding new
and abbreviated product names. Table ii details the new product
names to the original names.

xxvii
Table i
Original product names mapped to new names
Original Name(s) New Name Short Name Function
Alteon Application Nortel Applications Switch Applications

Switch xxxx xxxx Switch xxxx
Alteon Web Switch 184 Nortel Web Switch 184 Web

Switch 184
BayStack 450 Nortel Ethernet Switch 450 Ethernet

Switch 450
BPS2000 2-port SFP Nortel Ethernet Switch 2-port

GBIC MDA SFP GBIC MDA
CCN CS Nortel GSM/UMTS MSC MSC Mobile Switching

(DMS MSC) Center
CCN HLR Nortel GSM/UMTS HLR 100 HLR 100 Home Location
(DMS HLR) Register
Combined MSC and Nortel GSM/UMTS Combined Combined

HLR MSC/HLR MSC/HLR
(DMS Trinode)
Contivity xxxx Secure IP Nortel VPN Router xxxx VPN Router

Services Gateway xxxx
DMS Gateway Mobile Nortel GSM/UMTS MSC MSC Server Mobile Switching
Switching Center Server Center
(GMSC)
GPP Nortel GSM/UMTS IWF IWF Interworking Function
HSS Nortel GSM/UMTS HSS HSS Home Subscriber

Server
iBTS Nortel BTS xxxx BTS xxxx Base Transceiver

Station
IMS Solution Nortel IMS IMS IP Multimedia

Subsystem
NIMS-PrOptima™ for NIMS-PrOptima™ for Network Information

Preside for Wireless W-NMSa Management System
Internet & Wireless Network
Management System
—sheet 1 of 3—

xxviii Copyright © 2000–2008 Nortel Networks
Table i
Original product names mapped to new names (continued)
Nortel Networks Secure Nortel VPN Router xxxx VPN Router

Router xxxx xxxx
Offline Configuration for Wireless Provisioning System WPS for Wireless Provisioning
Access Networks for Access b Access System
(OCAN)
Passport 7400 (7K) Nortel Multiservice Switch Multiservice

7400 Switch 7400

15000 Switch 15000

20000 Switch 20000
Preside for Wireless Nortel Wireless Network W-NMS Network Management

Internet (PWI) Management System System for Wireless
Networks
RNC Nortel UMTS RNC xxxx RNC xxxx
Shasta 5000 BSN Nortel IP Services Edge IP Services

Router 5500 Edge Router
5500
Univity GGSN Nortel GGSN GGSN Gateway GPRS

(Shasta GGSN) Support Node
Univity HLR c Nortel GSM/UMTS HLR 200 HLR 200 Home Location
Register
Univity MLC Nortel MLC MLC Mobile Location

(MLC) Center
Univity SGSN Nortel SGSN SGSN Serving GPRS

(SGSN, (Nortel SGSN/GPRS (SGSN/GPRS, Support Node
GPRS SGSN, Nortel SGSN/UMTS SGSN/UMTS
UMTS SGSN, -use where required to -use where
USGSN or U-SGSN) differentiate technology.) required to
differentiate
technology.)
Univity Signaling Nortel GSM/UMTS SIG SIG Signaling Interworking

Gateway (SIG d, Gateway
SS7-IP Gateway)
—sheet 2 of 3—

xxix
Table i
Original product names mapped to new names (continued)
UMGW (MGW, Nortel GSM/UMTS MGW MGW Media Gateway

Passport Voice
Gateway (PVG))
Wireless Gateway (WG) See the following:

ATTENTION: - Nortel SGSN
Configuration NOT - Nortel GSM/UMTS MGW
supported in PC04 and
beyond, is supported in
OAM.
—sheet 3 of 3—
a. NIMS PrOptima™ is a sub-component of W-NMS
b. WPS for Access is a sub-component of W-NMS
c. May have also been referred to as Everest HLR
d. May have also been referred to as HP SIG
Table ii
New product names mapped to original name(s)
New Name Short Name Original Name(s)
Nortel Ethernet Switch 2-port SFP BPS2000 2-port SFP GBIC

GBIC MDA MDA
Nortel Applications Switch xxxx Applications Switch xxxx Alteon Application Switch
xxxx
Nortel BTS xxxx BTS xxxx iBTS
Nortel Ethernet Switch 450 Ethernet Switch 450 BayStack 450
Nortel GGSN GGSN Univity GGSN, Shasta

GGSN
Nortel GSM/UMTS Combined Combined MSC/HLR Combined MSC and HLR,

MSC/HLR DMS Trinode
Nortel GSM/UMTS HLR 100 HLR 100 CCN HLR, DMS HLR
Nortel GSM/UMTS HLR 200 HLR 200 Univity HLR a
Nortel GSM/UMTS HSS HSS HSS
—sheet 1 of 3—

xxx Copyright © 2000–2008 Nortel Networks
Table ii
New product names mapped to original name(s) (continued)
Nortel GSM/UMTS IWF IWF GPP
Nortel GSM/UMTS MGW MGW UMGW (function of a

Wireless Gateway),
Passport Voice Gateway
(PVG)
Nortel GSM/UMTS MSC MSC CCN CS,

DMS MSC
Nortel GSM/UMTS MSC Server MSC Server DMS Gateway Mobile

Switching Center (GMSC)
Nortel GSM/UMTS SIG SIG Univity Signaling Gateway,

SIG b,
SS7-IP Gateway
Nortel IMS IMS IMS Solution
Nortel IP Services Edge Router IP Services Edge Router 5500 Shasta 5000 BSN
5500
NIMS-PrOptima™ for W-NMS c NIMS-PrOptima™ for

Preside for Wireless
Internet
Nortel MLC MLC Univity MLC, MLC
Nortel Multiservice Switch 7400 Multiservice Switch 7400 Passport 7400 (7K)
Nortel VPN Router xxxx VPN Router xxxx Contivity xxxx Secure IP
Services Gateway,
Nortel Networks Secure
Router xxxx
Nortel SGSN: SGSN Univity SGSN,

- Nortel SGSN/GPRS SGSN/GPRS GPRS SGSN,
- Nortel SGSN/UMTS SGSN/UMTS) UMTS SGSN,
U-SGSN, or USGSN
function of a Wireless
Gateway
—sheet 2 of 3—

xxxi
Table ii
New product names mapped to original name(s) (continued)
Nortel UMTS RNC xxxx RNC xxxx RNC
Nortel Web Switch 184 Web Switch 184 Alteon Web Switch 184
Nortel Wireless Network W-NMS Preside for Wireless

Management System Internet (PWI)
Wireless Provisioning System for WPS for Access Offline Configuration for
Access d Access Networks (OCAN)
—sheet 3 of 3—
a. May also have been referred to as Everest HLR
b. May also have been referred to as HP SIG
c. NIMS PrOptima™ is a sub-component of W-NMS
d. WPS for Access is a sub-component of W-NMS

xxxii Copyright © 2000–2008 Nortel Networks

1-1
Release feature contents 1

This chapter captures the high level functionalities introduced by
different product line releases of Gateway GPRS Support Node
(GGSN). All functionalities described in this document should be
available in the latest GGSN product line release unless specified
otherwise. Different Nortel GGSN software loads may be
corresponding to different Nortel GGSN product line releases which
are detailed in the following sections.
UMTS 3.0/GPRS 5.0 and Prior Releases 1

GGSN Functionalities Description
The following basic system functionalities have been included in the
GGSN 3.2 and prior releases:
• DHCP Client
• Service Edge Router VPRN
• IPSec Branch Office
• RIPv2 Routing
• Routing - OSPFv2
• Service Edge Router Stateful Firewall
• Data Plane Redundancy
• GGSN Prepaid
• Border Gateway Protocol v4
• Policing
• Traffic Shaping
• Policy Based Routing
• DiffServ Marking on Gi interface
• Gn over Ethernet
• GTP version 0 and version 1

1-2 Release feature contents Copyright © 2000–2008 Nortel Networks
• 3GPP TS 32.015 compliance

• Hot Billing
• Gi over ATM
• Gp interface
• Wireless RADIUS Application Protocol (WRAP)
• Service Edge Router VPRN
• IPSec Branch Office
• RIPv2 Routing
• Routing - OSPFv2
• Service Edge Router Stateful Firewall
• Data Plane Redundancy
• GGSN Prepaid
• Border Gateway Protocol (BGP) v4
• Policing
• Traffic Shaping
• Policy Based Routing
• DiffServ Marking on Gi interface
• Gn over Ethernet

Release feature contents 1-3
Feature Description
A number of features have been introduced in the GGSN 3.2 and prior
releases which are detailed in the following table:
Table 1-1
UMTS 3.0/GPRS 5.0 GGSN Features
UMTS GPRS Feature Title Feature Description

Feature ID Feature ID
1009 (In GPRS Provide PDP Support of PDP context during handoff
2.1 release) context support between SGSNs including fallback/
for inter SGSN fallforward between GTP version 0 and
handoff version 1 SGSNs
1018 12076 & Transparent Support of GTP-L2TP tunnel switching

13270 access - L2TP for PPP and IP PDU type
over IPSec
1022 (In GPRS GPRS Billing Provide 3GPP TS 32.015 compliance for
2.1 release) GSM TS 32.015 GGSN accounting function.
content
conformance
1023 (In GPRS DHCP - user Support of DHCP client function on

2.1 release) class ID; Nortel GGSN
configurable
client ID
1033 (In GPRS Hot Billing Support of passing CDRs to CGF in real
2.1 release) time
1051 End to End QoS Support of QoS via DiffServ marking on

Support Gn interface
1059 (In GPRS Gi over ATM Support of Gi interface over ATM

2.1 release)
1061 (In GPRS Gp Allow subscribers roaming into a VPLMN

2.1 release) and being granted service.
12144 Dec 00 CR Provide 3GPP GPRS technical

Compliance specification Dec 00 CR compliance.
12772 Personal Support of personal network portal IP

Network Portal service
60010373 13904 IS-IS Routing Permit GGSN to interconnect with IS-to-

IS routing networks.
—sheet 1 of 6—

Table 1-1
UMTS 3.0/GPRS 5.0 GGSN Features (continued)

60011189 13905 RADIUS Support of RADIUS dynamic address

Dynamic allocation from the RADIUS servers
Address based on the Class attribute
Allocation
9152 17971 3GPP TS Compliance to TS 32.015 v3.6.0 provides

32.015 v3.6.0 additional call record related information
in the CDRs for operator to process.
11715 15266 IP Multicast IGMP Proxy enables GGSN to proxy

IGMP Proxy multicast control messages between
subscribers and routers and broadcast
the multicast packets.
11716 12282 Tariff Based Support of the G-CDR billing based on

Billing the configurable tariff periods.
11717 15291 Gigabit Ethernet Introduce new single port 1 Gigabit

Ethernet line card.
11726 15294 G-CDR Auditing Each G-CDR generated results in an

audit entry in the audit files and the audit
files can be FTP’ed to another node.
11825 15271 Gi RADIUS Provide the RADIUS accounting option

Accounting on the Gi interface.
11840 15272 Performance Collect the historical performance

Metrics: metrics to enable the performance
Historical evaluation for GGSN.
Statistics
11948 15290 CMC Capacity Increase the total number of

Enhancement simultaneous sessions supported to
128k at GGSN.
12183 15288 DHCP Relay GGSN acts as a DHCP relay agent

Agent between DHCP client (i.e. mobile station)
and DHCP server.
12196 15292 Single Access Operators can set up fewer number of
Point Name APNs and provide a set of services by
(APN) retrieving per subscriber information in
the RADIUS response message.
—sheet 2 of 6—

Table 1-1

16739 17974 June ‘01 Provide the compliance to 3GPP Rel 99

Standard CR Change Requests.
Conformance
19237 19947 Content-based Provide support for multiple accounting

Billing rates for data based on the origination
location.
19704 19949 GGSN Overload Provide the appropriate safeguard

Control against system instability in an overload
environment.
19156 Capacity The Nortel GGSN will be modified to

Enhancement provide a unique flexibility for service
Aggregation providers to meet the market needs for
Sessions high volume basic wireless aggregation
as well as support for subscribers with IP
services needs.
19227 GRE VPN Use GRE tunneling protocol to provide

VPN remote access to the corporate
Intranet.
19231 SCS GUI Active This feature enhances the Nortel GGSN
Session OAM capabilities by providing a SCS
Management GUI for the display of selected statistic
values and the execution of Active
Session Management (ASM) commands.
20273 March ‘02 This feature provides the conformance to

Standard CR the 3GPP Rel 98 and Rel 99 March ‘02
Conformance standard change requests. This feature
doesn’t include 3GPP TS 32.015.
20781 Gi Interface Enable the capability to flag APNs as

Availability unavailable if Gi interface failure makes
the Gi side inaccessible. When an APN is
unavailable, the Create PDP Context
Requests for this APN are rejected.
—sheet 3 of 6—

Table 1-1

21077 Prepaid Enable the Nortel GGSN to provide the

Location Rating current SGSN signaling IP address in the
Service Request message sent to the
SCP. SCP uses this information to
determine the roaming status for the
PDP session and facilitate the
appropriate rating for Prepaid service.
21191 GGSN Partial Provide the ability to configure a periodic

Billing for billing interval used to create billing
Roamers records for outbound roaming
subscribers.
21259 GGSN PC03 This feature enables the operator to

Counter define a finer 5-minute granularity for one
Enhancement or more of the historical metrics statistics
groups.
21523 OS hardening This feature results in an OS hardening

for Solaris 8 for script for Solaris 8 that will be executed
SCS during SCS Server installation and
upgrade. Following an installation or
upgrade, the SCS Server will be
hardened.
21610 SCS Support of The SCS Server is upgraded to the

Solaris 8 currently available version, i.e. Solaris 8
update 7.
21767 Overload Nortel GGSN monitors the amount of

Control usable CMC memory available and
Enhancement generates alarms associated with
overload levels. The Create PDP Context
Requests will be rejected when passing
level 2 or 3 overload states.
22847 Uplink Content The Content Based Billing is enhanced to

Based Billing handle uplink traffic in the same fashion
as downlink traffic and consistently count
data in the appropriate rate buckets
regardless of direction.
23286 VLAN Tagging This feature provides the 802.1q VLAN

on Gi access connection capability used with
VPN.
—sheet 4 of 6—

Table 1-1

24005 CBB Support for The CBB functionality is extended to

WAP support the WAP 1.x protocol stack.
24438 Node and Add the stateful firewall capability to each

Management ISP to protect Nortel GGSN from
Security malicious external users.
Services
24635 CBB Support for Allow MMS over WAP messages to be

MMS over WAP billed separately from WAP content by
using different rate for data flows.
11818 DiffServ EF/CS The DSCP marking of EF, CS7, CS6 and
Marking DE in the IP packet header is supported
on the Gn and Gp interfaces for the
downlink packets.
20587 Secure GGSN The SSH for CLI login ensures that all
Management command line interface traffic is
Traffic encrypted and secure. The SSL between
SCS client and SCS server ensures that
all management traffic is encrypted and
secure.
21309 GGSN Services This feature provides access to many of

Capacity the advanced wireless and IP services
Enhancement for the subscribers in APNs enabled for
aggregation support.
21586 Standards CR This feature provides Nortel GGSN the

Conformance conformance to the 3GPP Release 98
and Release 4 December 2002 standard
Change Requests.
21750 Variable Rate Extend the Nortel GGSN based prepaid

Prepaid solution to support variable rates through
the use of multiple coupons for a
subscriber’s data session. The variable
rate enhancement provides full prepaid
integration with Content Based Billing.
22347 GGSN PC04 The Nortel GGSN historical statistics

Counters collection mechanism is enhanced to
Enhancements align collection granularity periods to the
clock intervals and reset the counter at
the beginning of each collection period.
—sheet 5 of 6—

Table 1-1

23394 CBB Scaling This feature enhances CBB by

and Flexibility supporting additional WAP protocols and
Enhancement supporting up to 25 coupons and 10000
CBB rates per CBB policy. The different
coupons are used by Prepaid Service.
23948 Gratuitous ARP The Nortel GGSN will support Gratuitous

ARP on trunk interface in addition to
access interface.
24639 Shasta SSC This feature adds to the existing CMC

Patching patching functionality by extending the
supported targets to include the SSC.
24640 APN This feature expands the operators’

Serviceability ability to monitor active PDP sessions
Enhancement and control subscriber access on an APN
basis.
25488 Access This feature allows access connections

Connections to be configured on the Gi interface using
from Wireless the wireless ISP network model.
ISP
25944 IP Address Subscriber IP address management is

Blackout Timer enhanced to include an optional address
blackout period during which the IP
address is restricted from reallocation.
26048 GGSN Support This feature expands GGSN RADIUS

for Cisco VSA functionality to include the Cisco
RADIUS DNS VSA for DNS support.
VSA
26098 GGSN This feature provides capability to trace
integrated RADIUS message flow across all
RADIUS network models.
debugging
—sheet 6 of 6—
In addition to the GGSN features, there are more product

enhancements in this release as described below:
• The configuration of TCP port number for Prepaid Service via SCS
is moved from the General page to the new Device page in the
Tariff Profile. The TCP port is provisioned on a per device basis.

• The configuration of DHCP pool name via SCS is moved from the
Subscriber Template to the DHCP Profile. When the ISP/APN
spans across multiple devices, the pool name can be assigned on
a per device basis.
• The incoming requests for creating new PDP contexts can be
disallowed via the configuration of GTP Tunnel Device page via
SCS. It provides the option to choose the way to reject the requests
on a per device basis. This function will be used for software
upgrade on Nortel GGSN node.
• A new Ga ISP is introduced for the Ga interface. The billing
information can be transferred using the Gn ISP or the Ga ISP. The
new Ga ISP option is to prevent any IP packets from tandeming
through the Nortel GGSN between PLMN network and OAM
network.
• Based on the configuration of RADIUS Profile and Application
Profile, the MSISDN is optionally added to the Calling-Station-Id
attribute in the RADIUS Access-Request, Accounting-Request
Start/Stop/Interim-Update messages.
• When receiving an Update PDP Context Request message due to
the inter-SGSN Routing Area Update (including fallforward and
fallback), an Accounting Request Interim-Update is sent to
RADIUS Server with the 3GPP-SGSN-Address attribute. This only
occurs when the RADIUS accounting or WAP Service is enabled.
• If the subscriber requests a static IP address or an IP address is
specified with the PPP PDU type, then the End User Address
Information Element (IE) is included in the Create PDP Context
Response message without the PDP Address field.
• Add the APN historical statistics for the Update PDP Context
Request messages sent from the Nortel GGSN in addition to the
statistics for the same request messages sent from the SGSN.
• The support of multiple primary PDP contexts is added to the
Nortel GGSN.
• Two different formats of the Cell Global Identification of GTP
version 0 and Service Area Identifier (SAI) of GTP version 1 in the
GTP private extension are supported by the Nortel GGSN. The
different formats are identified by different Length values in the
private extension IE.
• The range of Periodic Billing - Volume Limit configuration on the
APN Group Accounting Billing page has been changed to 128 -
5000 KBytes.
• The range of Response Time configuration on Tariff Profile General
page has been changed to 1 - 15 seconds.

• The traffic throughput of Gigabit Ethernet Line Card (GELC) on Gn,

Gp or Gi interface is enhanced. The maximum 24k subscriber
restriction is lifted.
• CMC patching is provided for the software changes on the CMC
card without service interruption or degradation.
• When SGSN or subscriber requests a QoS update via Update PDP
Context Request, the Service Profile will not be overwritten if the
currently applied Service Profile was selected via Single APN from
the RADIUS Server.
• A new option called SGSN Change Partial Billing is added to the
APN Group Accounting Billing page for GTP Accounting. When this
option is enabled, as long as there is a SGSN address change, a
G-CDR will be generated.
• Add the configuration capability of DHCP Relay Agent address on
the Nortel GGSN for the DHCP giaddr based address allocation
function.
• The Nortel GGSN is rebased to the Shasta base iSOS 3.01
software load.
• The Nortel GGSN provides N-2 backward compatibility between
SCS Server and GGSN. In other words, SCS Server is compatible
with N-2 versions of GGSN. Therefore GGSN4.0.0 SCS Server
can simultaneously manage GGSN2.x, 3.x and 4.0.0 GGSN. The
SCS Server needs to be upgraded prior to the GGSN.
• Add several CLEAR severity GGSN SNMP service alarms to clear
the alarms on the SCS GUI when problems are resolved.
• Based on the received value of Delivery Order field in the QoS IE,
the sequence number is included in the GTP header of outgoing
GTP-U packets.
• In the event that the static data on CMC card or SSC card is
overridden, a System Manager event log is generated to report the
software violation.
• The pool memory audit is added to the processor 0 of active CMC
card. It allows applications to be bound into the memory leak
auditing. If there is a memory leak, an event log is generated to
report it.
• The GGSN debug level logs are generated to indicate variant
events and activities happening on the Nortel GGSN.
• The memory trampling detection is added to the Nortel GGSN for
identifying and reporting memory trampling on CMC card and SSC
card.

• An option is provided to access to GTP Accounting billing records

stored on the local disk drive via FTP Pull.
• Nortel GGSN supports software linear Automatic Protection
Switching (APS) for ATM Line Card in the form of 1+1
unidirectional non-revertive protection.
Release Line Up
The GGSN 3.2 software loads are used for the UMTS 3.0 and GPRS
5.0 releases.
UMTS 4.0/GPRS 6.0 1

Nortel GGSN has the following sub-releases for UMTS 4.0 and GPRS
6.0 product line releases:

• GGSN 4.0
• GGSN 4.1.
GGSN 4.0 Description
The GGSN 4.0 is part of UMTS 4.0/GPRS 6.0 product release. There
are a number of functions being added to GGSN 4.0 which are
detailed in the following table:
Table 1-2
GGSN 4.0 Features in UMTS 4.0/GPRS 6.0
Feature ID Feature Title Feature Description
11704 Service Redirect The Prepaid Server may instruct the

GGSN to redirect the user session to a
top-up site allowing subscriber to
recharge account. In addition, Prepaid
Server can also force re-authorization for
coupons for a given subscriber due to
external event.
This feature is activated by Software

Optionality Control.
11812 Secondary PDP This feature introduces secondary PDP

Context context procedures as defined by the
3GPP Release 4 standards on the
GGSN.
11832 ATM Service Classes: Improve the shaping capability for UMTS
CBR, VBR QoS traffic classes over ATM.
Specifically, it provides the multiple VC
support of CBR, rt-VBR and nrt-VBR.
12059 MPLS VPN This feature provides the capability on

(RFC2547bis) the GGSN to support BGP/MPLS VPN
based on RFC 2547 over the Gi
interface.
17601 GGSN Integrated This feature provides the necessary

Lawful Intercept capability on the GGSN as an Intercept
Access Point (IAP) or Access Function
(AF) for Lawful Intercept functions.
19061 V-GGSN Access This feature is to control the use of

Control GGSN by visiting subscribers. GGSN
allows or inhibits the use of certain APNs
by visitors based on the visiting
subscriber's IMSI.
—sheet 1 of 5—

Table 1-2
GGSN 4.0 Features in UMTS 4.0/GPRS 6.0 (continued)
22987 GGSN HW for PC04 - The SFC2 hardware provides support for
SFC2 expanded ATM service classes as well
as robustness and failover
improvements.
23710 SSC Billing This feature allows a much more

Resilience frequent internal updating of the SSC
billing information to the CMC without
generating partial records.
24658 Base Shasta 4.0 This feature encompasses several iSoS

Features 4.0 Base Features:
1) SCS Security Enhancements Phase 1
2) Security Enhancements Phase 2
3) Firewall enhancement - Handling of

Unsolicited Packets
4) GigE Scaling of Layer3 Address

Recognition (Gigabit Ethernet Line Card
(GELC) Scaling)
5) SCS Policy Enhancement (Policy:

Prevent Scope Objects Deletion)
6) L2TP Ingress/Egress Shaping

RADIUS VSAs (Dynamic PPP Over
L2TP Shaping)
7) Ultra DMA/33 IDE/ATAPI Driver
25058 SCS - Local Full This feature provides the offline ability to
System and perform a full backup and full restore of
Centralized Data the Solaris OS, third-party software, SCS
Backup and Restore application and all server data. In
addition, this feature automates the data
backup/restore for SCS from centralized
PWI backup/restore solution.
—sheet 2 of 5—

Table 1-2
25767 L2TP Multiple This feature allows attributes of multiple

Tunnels L2TP tunnels to be returned in a single
RADIUS Access-Accept message. The
GGSN then selects one L2TP tunnel
based on preference. This feature also
allows load balancing between these
dynamic tunnels.
25811 GGSN Robustness The feature incorporates the following

PC04 changes to existing functionality:
1) remove the CGF Profile information

from the GTP Tunnel page on the SCS
GUI. The CGF profile configuration is
supported in the GTP’ profile only.
2) the GTP Active Session Management

(ASM) is enhanced to include the display
of the SGSN control and data plane IP
addresses (detailed view only). Also all
QoS parameter columns are changed to
display the corresponding symbols (as
per 3GPP TS 24.008) instead of integer
values.
25818 GGSN Services Via software optimization, this feature

Capacity Activation improves the activation rate for PDP
Rate Improvement sessions using DHCP or VPN services
and the maximum session capacity using
ALC card on the Gi interface.
25832 GGSN Standards CR This feature provides conformance to

Conformance 3GPP standard Release 4 December
2003 CRs.
26534 GGSN MSISDN/IMSI This feature provides a wide range of

Debug Trace Tool session related event traces. The
operator will be able to trace session
related events that include GTP, DHCP
and CTP messaging.
—sheet 3 of 5—

Table 1-2
26371 Transparent VSA GGSN supports the reception of a

Handling freedom ASCII VSA in the Access-
Accept message from RADIUS Server.
This VSA is transparently inserted into
the G-CDR and CTPv3 message if it is
received.
26372 CTPv3 Tariff When tariff switch occurs during prepaid

Containers coupon lifetime, GGSN will report the
tariff switch time and the quota usage
both before and after the boundary to the
Prepaid Server.
26373 GGSN Block This feature provides an option to

Rounding for GTP’ regularly generate G-CDRs and RADIUS
Billing Interim Accounting Records at intervals
equal to the billing time limit.
26422 Diameter CC Real- Support a real-time charging interface

Time Charging using the Diameter CC protocol for credit
control functions between GGSN and
real-time charging server.

26664 CTPv3 Redirection Following a quota authorization denial,

Trigger the Prepaid Server may instruct the
GGSN to redirect the user’s session. The
CTPv3 redirection trigger is used for
service redirect feature.

26699 IMSI-based Hot- This feature enables control of the

billing selection frequency of G-CDR and RADIUS
accounting record generation based on
the subscriber's IMSI.
27346 URL Matching This feature ensures the matching rules

of the URL string for WAP 1.X, HTTP and
WAP 2.0 are fully compliant to the
relevant RFC's, i.e.: RFC 2396 and 2616.
—sheet 4 of 5—

Table 1-2
27657 GGSN Basic This feature provides optional feature

Software Optionality control to prevent unauthorized use of
Control the functionality offered. It also provides
a mechanism to manage exclusivity that
may be required for some custom
development items.
27762 Charging The Charging Characteristics parameter

Characteristics Pass- in the Create PDP Context Request
Through in RADIUS message is optionally passed to the
Authentication RADIUS Server during RADIUS
authentication.
28188 CBB Usage Time This activity enhances the existing CBB
Accounting functionality by filtering different layer 7
Enhancements applications and report usage based on
time.
28307 Diameter CC Lucent Interworking with Lucent Technologies

Interworking SurePay Diameter CC Server. The online
or Closed Loop Charging Interface
(CLCI) is supported.
28308 DCC Failure Handling This feature enables Nortel GGSN with
CCFH capability for a CCA timeout. If the
CCFH value for the session is
CONTINUE, session is continued as a
non-prepaid session.
28317 HTTP Pipelining and This feature enhances the existing CBB
WAP Buffering service to correctly rate the pipelined and
fragmented HTTP requests and their
responses.
—sheet 5 of 5—
In addition to the released features, there are product enhancements

also being included in this release. The following is a list of the
enhancement items:
• The Nortel GGSN is rebased to the Shasta base iSOS 4.5 software
load.
• The disk overload control is enhanced with introducing new event
logs and lowering the alarm threshold for disk overload.
• The WAP Push Service Object is supported for provisioning an
URL list in the CBB policy.

• The DHCP address allocation is enhanced to support DHCP Client

being able to reach DHCP Server in the public network for “VPN
only” VPRN configuration.
• When parsing incoming GTP-C messages from SGSN, check for
stuffed bytes in the MSISDN IE. If present, remove the stuffed
bytes and send only the true numeric number to all accessory
servers (i.e. RADIUS Server, CGF and Prepaid Server).
GGSN4.1 Description
GGSN 4.1 is part of UMTS 4.1/GPRS 6.0 product release. It builds on
the top of GGSN 4.0 release. There are a number of functions being
added to GGSN 4.1 which are detailed in the following tables:
Table 1-3
GGSN 4.1 Features in UMTS 4.1/GPRS 6.0
12250 Data Plane This feature is implemented in a 2N load

Redundancy for High sharing redundancy configuration. This
Capacity APNs redundancy is provided at the SSM level
based on the SSC types provisioned on
the GGSN. This means that if a GGSN
has both SSCs with encryption and
without encryption, 2N redundancy would
mean that two additional cards (one with
encryption and one without encryption)
would be required for system
redundancy.
25833 GGSN Counter This feature furthers the development of

Enhancements the GGSN OAM performance
measurement reporting. Additional
statistical counters are added to the
GGSN to facilitate the evaluation of
GGSN performance.
26514 SCS Command Line Support of the CORBA Shell on the SCS
Interface server for GGSN provisioning.
26919 GGSN Control The third version of Control Management

Management Card - Card (CMC3) is introduced to increase
Version 3 overall session activation rate and
maximum supported sessions at higher
feature penetration levels. Both the
current CMC2 and new CMC3 cards are
supported.
—sheet 1 of 5—

Table 1-3
27314 CBB Provisioning CORBA support for CBB policy

XML Import/Export provisioning, including policy string
validation.
27356 Service Edge Router This feature encompasses several iSOS

Base iSOS Features 5.0 Service Edge Router Base Features:
for GGSN 4.1
1. Dynamic Routing Over IPSec
2. Non-wildcard IPSec DPD Keepalive
Mechanism
3. VPN Security Enhancements for
RADIUS
4. IPSec MIB Enhancement
5. CardMgr Recovery Robustness
6. TaskMgr Sanity Overhaul
7. Overload Controls
8. MPLS Management VPN
9. BGP Route Refresh Capability
10.MPLS VRFs - Flexible DF bit treatment
27686 SCS Upgrade This feature explains the installation/

Strategy upgrade enhancements made to the
SCS 4.1, to eliminate the errors during
the SCS installation and upgrade.
27764 Gn Parameters This feature adds support for handling

Enhancements (IMEI- two new optional IEs defined in 3GPP
SV, RAT) Rel-6, IMEI(SV) and RAT Type, in the
GTP messages. The IMEISV and RAT
Type
are transmitted to the downstream

RADIUS server, CGF and Prepaid
servers.
The feature also modifies the Home

SGSN Configuration table to be used
as
PLMN Id table for deriving the PLMN
Identifier from the SGSN address.
—sheet 2 of 5—

Table 1-3
28338 Billing Accuracy Ensure the accuracy of accounting

Enhancement timestamps, duration, and partial record
interval is +/- 0.5 seconds over the whole
PDP context duration.
28339 CTP Prepaid The maximum number of initial
Enhancement: coupon IDs configured via SCS GUI
Number of Initial has been increased to 40.
Coupon IDs
28340 Partial Record Enhance the trigger events RAT

Generation: change and QoS change to be
Switchability of trigger configurable so that the trigger events
event
can be turned off.
28344 Prepaid Service Re-classify the charging of TCP
Redirect connection sequence. A forbidden type
Enhancement of coupon ID is created for the denied
service redirect.

28520 GGSN Alarm Trap This feature allows integration of GGSN/
Replay SCS to third party OSS. The GGSN
implements an active alarm list. The
active alarm list generally covers the
hardware components of GGSN. A
significant number of alarms, generally
relating to software and services, cannot
be resynced because they are not
present in the MIB.
28545 Total Usage This feature provides configurable option

Reporting to report the resource total usage for a
coupon ID in addition to the delta usage.
28607 Initial coupon ID This feature allows the provisioning of

configuration Coupon IDs in the CBB policy definition
which is sent to the Prepaid/DCC server
during initial authorization.
—sheet 3 of 5—

Table 1-3
28630 GCDR Automated An automated clean up function is

Clean Up provided to clean up G-CDR files stored
on the CMC hard disk drive using a
customer configurable time of day to
transfer files via GTP’ protocol over the
Ga interface. This function provides the
ability to specify clean-up of the billing
records stored on the disk drive at a
customer configured time of day.
29001 Health Check Monitor This feature periodically monitors the
health of the system. Three key
parameters are monitored for measuring
GGSN system stability.
The first parameter is the Nodal

Activation success rate. The second
parameter is the Network Activation
success rate. The third parameter is
used to track the number of PDP context
activation attempts. An alarm is raised, if
there are no PDP context activation
attempts, for two successive intervals.
—sheet 4 of 5—

Table 1-3
29082 CBB Support for Provide support of absolute URL to allow

Absolute URL format assigning different content categories to
URL’s where the only difference is the
port number.
24655 Event Based Billing Event based billing provides the ability to
charge on a per event (e.g. MMS, e-mail,
IM) basis, and not based on the quantity
of data. This function follows current
SMS charging architecture.

26432 GGSN Traffic This feature allows interworking between

Performance the GGSN and a Traffic Protocol
Optimizer (TPO) Optimizer. Allow client/server based
Interworking optimization to take place with all the
GGSN IP services and wireless services,
including CBB.

27259 Diameter CC Real- Diameter CC Real-Time Charging

time Charging Phase introduces GGSN support of the Gy real-
2 time charging interface using the
Diameter CC protocol for credit control
functions between GGSN and DCC
Server. Existing Nortel GGSN prepaid
service logic is maintained, including full
integration with Content Based Billing.
Diameter CC Real-time Charging Phase
2 adds support for the following:
1. Multiple triggers per quota

2. Event based quota
3. Radio Access Type
4. CBB Category/Coupon Blacklisting
—sheet 5 of 5—

enhancement items:

• The Nortel GGSN is rebased to the Service Edge Router base

iSOS 5.0 software load.
• CBB Backend Optimization is introduced in this release.
Release Line Up
The GGSN 4.0 software load is used for the UMTS 4.0 and GPRS 6.0
releases. The GGSN 4.1 software load is used for the UMTS 4.1 and
GPRS 6.0 releases.
GGSN 5.0 1
Nortel GGSN 5.0 release is deployed to both GPRS and UMTS
networks.
Functionalities Description
GGSN 5.0 is part of UMTS 5.0 product line release. There are a
number of functions being added to the GGSN 5.0 release which are
Table 1-4
GGSN 5.0 Features
12205 MPLS RSVP-TE This feature provides the capability to

support the RSVP-TE signaling protocol
to create MPLS tunnels for BGP/MPLS
VPN.
24599 SSC3 Introduction SSC3 increases the overall PDP session

density on the SSC cards. It
provides.faster processors, expanded
memory, and faster encryption
technology than SSC2 card.
26431 Standard CR Implement approved 3GPP Rel 5 and

Conformance Rel 6 standard CRs such that the GGSN
meets the minimum level of conformance
to the published standards.
26434 3GPP Rel 6 Dynamic This feature enables dynamic session

Policy Control (Gx) policy control functions. It provides
support for standard Gx interface, as
basis for supporting peer to peer flow
gating, basic QoS authorization, and
associated per flow charging for both
IMS and non-IMS services.


Table 1-4
GGSN 5.0 Features
26513 3GPP Rel 6 Diameter This feature introduces GGSN support of

Credit Control (Gy) the Gy online charging interface using
the Diameter CC protocol for credit
control functions between GGSN and
online charging server.

26932 Single APN The GGSN supports the selection of the

Selectable Address address pool via Single APN RADIUS
Pools Framed-Pool attribute.
27492 User Location The user location information which is

Information Support sent within the PDP context request from
the SGSN has been included in all
accounting information for the GGSN.
27566 Nortel GGSN Content This feature provides support for content
Filtering filtering allowing to filter Internet requests
from the user. Internet requests can be
HTTP or WAP based and are directed to
a content filtering server.

28631 G-CDR marking This feature reports Diameter CC real-

based on DCC-CLCI time cause codes in the G-CDR records
events for the exception cases.
28687 GGSN5.0 Capacity The introduction of SSC3 card and the

Targets optimization around some call models
using RADIUS interface or DCC interface
improve the overall capacity of the
GGSN.
28849 Availability The Health Check Monitoring is

Improvement expended to enable the configuration of
those alarm thresholds. An APN that has
experienced an abnormal level of failed
PDP context requests will be blocked
from access for a specific period of time.

Table 1-4
GGSN 5.0 Features
29351 Parking Meter Event Enhance CBB to incorporate new

Charging charging model based on a time token or
parking meter. When the parking meter
timer is running, subscriber may send
and receive as much traffic as desired
without incurring further charges.

29420 IMS Interworking Introduce IMS architecture to serve as a
gateway between the UMTS access
network and the Proxy CSCF.

29661 Configurable GGSN This feature allows the source IP address

Source IP Address for all GGSN originated protocols to be
Selection either configured ISP default address or
hardcoded ISP default address.
29937 GGSN Counter Introduce new counters to generate the

Enhancements call models for the capacity calculation of
the GGSN.
29946 Configurable RADIUS Provide more flexibility for controlling the

Interim Messages sending of RADIUS Interim Update
message on a per APN basis.

Table 1-4
GGSN 5.0 Features
29957 Support for HTTP This feature adds the support of

Methods additional HTTP methods via CBB.
30020 DCC Tx Timeout This feature adds an alarm notification

Alarm for Diameter CC timer Tx expiration.
30077 SGSN Grouping and Provide the SGSN grouping function and
RAT Mapping allow the mapping of serving Radio
Function Access Technology if it is not received
from the SGSN.

30409 IP Services support This feature is to provide the support of

for IP in IP IP services for the mobile IP traffic that is
passing through the Nortel GGSN.


enhancement items:
• The GGSN Resync function has been enhanced to optionally

include two phases, the first phase is to build up the GGSN
configuration on the SCS server and the second phase is to
download the configuration to the SSG.
Release Line Up
The GGSN 5.0 software load is used for the UMTS 5.0 release.

GGSN 5.0.1 1
Nortel GGSN 5.0.1 release is deployed to both GPRS and UMTS
networks.
GGSN 5.0.1 is part of UMTS 5.0 product line release. There are a
number of functions being added to the GGSN 5.0.1 release which are

Table 1-5
GGSN 5.0.1 Features
30453 CBB Time Accounting This feature renames Inactivity Timer to

QCT Timeout QCT Inactivity Timer on the Diameter
Optional Inclusion Profile (see figure). Also, on the APN
Profile-Accounting tab, the Inactivity
Timer is renamed to QCT Inactivity Timer
and Exclude QCT option is added (see
figure).
With this feature, the GGSN provides the

optionality to exclude the QCT Time from
the reported usage for prepaid and
postpaid PDP contexts. For prepaid QCT
info, please refer Chapter , “Quota
Consumption Time (QCT) Inactivity
Time” on page 78 and Figure 8-56
“Diameter Profile Credit Control Tab
(Triggers)” on page 93. For postpaid
QCT Inactivity timer info, please refer to
Figure 8-17 “APN Group Accounting/
Billing Page” on page 38.
The Exclude QCT option on the APN

Profile-Accounting tab is a common
selection for both prepaid and postpaid
subscribers.
Q01264512-05 Support of DHCP GGSN now supports DHCP Relay Agent

Relay Agent address address (aka giaddr) field for VLAN VPN.
(aka giaddr) field for Please refer to Chapter 3, “DHCP Relay
VLAN VPN Agent address” on page 44.
Q01339974-01 Enhancement of This feature enhances the generation of

SGSN Change Partial partial accounting record is when there is
Billing an SGSN address change for the PDP
context. Please refer to Chapter 3,
“Conditions for accounting record
generation” on page 53 and 54.

Table 1-5
GGSN 5.0.1 Features
Q01086721-03 Secure PAP/CHAP This feature provides the GGSN with the
L2TP Authentication capability to negotiate up to CHAP from
PAP with bringing up an L2TP tunnel for
a mobile subscriber. Please refer to
Chapter 3, “L2TP secure PAP/ CHAP” on
page 76.
Q01171008 Option to Disallow This feature provides the flexibility to

RADIUS INTERIM send/not send Interim Radius accounting
Messages records on a per APN basis. Please refer
to section RADIUS Accounting Chapter
3, “Functional description” details on 67.
30871 DCC v2 This feature introduces various

Customization enhancements to the GGSN’s Diameter
Essentials CC interface. See Nortel GGSN
Diameter Credit Control Technical
Specification for the detailed information
of DCC protocol.
32688 Support of Offline- This feature adds the capability for a

Charging AVP and session to use postpaid Parking Meter
PM Time Event billing in cases where communication
Charging Default with a DCC server is not possible.
Setting

GGSN 6.0 1
Nortel GGSN 6.0 release is deployed to both GPRS and UMTS
networks.
GGSN 6.0 is part of UMTS 6.0 product line release. There are a
number of functions being added to the GGSN 6.0 release which are
Table 1-6
GGSN 6.0 Features
33974 Cabcharge L2TP This feature provides the capability to

Authentication add APN name as the domain appended
to the anonymous username. This is
applicable to the MSISDN, IMSI and
username options.
33977 DCC Envelope This feature extends envelope reporting

Reporting capabilities to apply to sessions using
Quota Consumption Time (QCT). The
reporting detail is enhanced.
33978 DCCv2 This feature introduces various

Customization enhancements to the GGSN’s Diameter
Essentials CC interface.
33979 Parking Meter This feature adds the capability for a

Enhancement session to use postpaid Parking Meter
billing in cases where communication
with a DCC server is not possible.
33980 Dual Coupon Tariff This feature adds support for the dual
Switch coupon option for tariff change support.
33935 Sarbanes Oxley This feature upgrades the current SCS

Password password management functionality.
Enhancements
34354 3GPP Rel 6 Gy This feature supports AVPs to be

Diameter CC compliant with the 3GPP TS 32.299
Conformance v6.7.0 for customer specific Service-
Context-IDs.
34366 Envelope AVP This feature modifies the CC-Service-

Service-Specific-Units Specific-Units sub-AVP such that the
mandatory bit is not set for Customer
Specific Service Context ID.

Table 1-6
GGSN 6.0 Features
32799 Direct Tunnel This feature supports establishment of a

direct User plane (GTP-U) between the
RNC and GGSN.
33973 TCP MSS Clamping This feature provides the ability to

configure the GGSN to modify the TCP
MSS option for uplink and downlink SYN
packets to prevent IP fragmentation.
34248 IP Services Capacity This feature optimizes how some of the

Enhancements GGSN IP Services are internally
implemented to reduce the required
memory footprint.
33682 Billing Enhancements This feature provides enhancements to

the GGSN billing system.
33509 Idle Session This feature provides the ability to verify

Verification a context if it is idle and take down the
context if it is idle.
34727 GELC Gn Packet This feature provides the ability to

Fragmentation increase the maximum MTU value from
1500 to 1950 bytes for any interface on a
GELC connection type to reduce IP
fragmentation.
32167 3GPP Standards This feature introduces IMEI as a target

Conformance identity for lawful interception of
subscribers.
33982 Continuous Time

Period Time Event This feature introduces support for 3GPP
Charging DTP as part of the 3GPP Gy Diameter CC
interface and extends the GGSN's func-
tionality to support the Continuous Time
Period (CTP) model as well.

2-1
Introduction 2
Gateway GPRS Support Node (GGSN) functionality is common
between GPRS and Universal Mobile Telecommunication System
(UMTS) networks. The GGSN is the element defined the GPRS/UMTS
system to provide interconnection between the GPRS/UMTS IP
backbone network and the external data packet network.
The GGSN is the interconnection point between the Public Land

Mobile Network (PLMN) and a particular Packet Data Network (PDN),
which can be Internet Service Provider (ISP) or Corporate Intranet.
Accordingly, a GGSN maintains a “one to many” relationship with
Serving GPRS Support Node (SGSNs), which may be in either the
Home Public Land Mobile Network (HPLMN) or Visiting Public Land
Mobile Network (VPLMN) for roaming subscribers. The SGSN
provides the mobile subscriber an access point to the GPRS/UMTS
network, and is primarily responsible for network access control and
mobility management.
The GGSN is primarily responsible for packet routing and controlling

access to the public data network (PDN), which includes the following
general functions:
• Routing
• Tunneling
• Security
• Mobile subscriber authentication
• IP address allocation
• GGSN accounting
The GPRS/UMTS specifications clearly define interfaces between

network elements and reference points on the external system. Figure
2-1 shows the various components connected to the GGSN to provide
GPRS/UMTS functionality.

2-2 Introduction Copyright © 2000–2008 Nortel Networks
Figure 2-1
GGSN network connectivity
SGSN
GGSN
SGSN Public
Packet Data
GGSN Network
SGSN
Home PLMN SGSN
BG
SGSN GGSN
Visiting PLMN
BG - Border Gateway

Introduction 2-3
GGSN interfaces 2
Following is a summary of the GGSN standard interfaces that are
defined by the GPRS/UMTS standards. Figure 2-2 shows the GGSN
standard interfaces.
Figure 2-2
GGSN standard interfaces
HLR CRF DCC
Gc Gx
Gy
Gn Gi
SGSN GGSN PDN TE
Gp
Ga
Billing
SGSN CGF
CGF System
Other PLMN
As described in 3GPP TS 03.60, version 7.7.0, “Service Description”,

and 3GPP TS 23.060, version 3.8.0, “Service Description”, the following
GGSN interfaces are defined by the standards:
• Ga - Interface between GGSN and Charging Gateway Function
(CGF) for billing.
• Gc - Interface between GGSN and Home Location Register (HLR)
used for network initiated calls.
• Gi - Interface between GGSN and external PDN
• Gn - Interface between GGSN and SGSN
• Gp - Interface between GGSN and VPLMN’s SGSN
• Gy - Interface between GGSN and Diameter Credit Control
• Gx - Interface between GGSN and Charging Rules Function
Ga interface protocol
The Ga interface is defined in 3GPP TS 32.015, version 3.6.0,
“Charging and Billing”. The specification defines the signaling and data
transfer procedure for the GTP’ protocol used between the GGSN and
the CGF for GGSN accounting. The GGSN accounting records are

transferred from the GGSN to the CGF using GTP’ protocol in ASN.1
format.
The following GTP’ messages are supported between the Nortel GGSN
and CGFs:
• Node Alive Request
• Node Alive Response
• Redirection Request
• Redirection Response
• Echo Request
• Echo Response
• Data Record Transfer Request
• Data Record Transfer Response
• Version not Supported
Gc interface protocol
The Nortel GGSN does not support the Gc interface.
Gn/Gp interface protocol

The Gn/Gp interface is defined in 3GPP TS 09.60, version 7.7.2,
“GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface”,
and 3GPP TS 29.060, version 3.9.0, “GPRS Tunnelling Protocol (GTP)
across the Gn and Gp Interface”. This specification defines the
signaling and data transfer procedures for GTP used between GSN
nodes in the backbone network. GTP is defined both for the Gn
interface between GSNs within a HPLMN and the Gp interface
between GSNs in different PLMNs. GTP is the means by which
tunnels are established, used, managed and released.
The Gp interface is defined for roaming subscribers to communicate

using GTP between the GSNs in different PLMNs. A Border Gateway
(BG) is needed between the GGSN and the SGSN in a different
PLMN. For the Nortel GGSN, an external BG is required for the Gp
interface.
Highlights of the Gn/Gp interface are:

• Internet Protocol version 4 (IPv4) is the networking technology on
which GTP tunneling is based.
• UDP is the underlying path protocol.
• The following GTP messages are supported over the Gn/Gp
interface:

Introduction 2-5
— Create PDP Context Request

— Create PDP Context Response
— Delete PDP Context Request
— Delete PDP Context Response
— Update PDP Context Request
— Update PDP Context Response
— Error Indication
— Echo Request
— Echo Response
— G-PDU
— Version not supported
Figure 2-3 shows the protocol stack for the control plane of GTP
between SGSN and GGSN.
Figure 2-3
Control Plane of SGSN-GGSN
GTP-C GTP-C
UDP UDP
IP IP
L2 L2
L1 L1
GSN Gn/Gp GSN
The User Plane between the SGSN and the GGSN for GPRS
networks and UMTS networks is the same. Figure 2-4 shows the
protocol stack for the User Plane between SGSN and GGSN.

Figure 2-4
User Plane of SGSN-GGSN
Application
Relay GTP-U
GTP-U
UDP UDP
IP IP
L2 L2
L1 L1
Gn Gi
SGSN GGSN
Gi interface protocols
IPv4 is the basis for interworking with external PDNs. Mobile
subscribers can access the external public data network with IP PDU
type or PPP PDU type. Some access modes require tunneling
between the GGSN and the remote Intranet, which means that
tunneling protocols are required on the Gi interface. Tunneling
protocols are supported on the Gi interface between the GGSN and
the remote Intranet to provide security when connectivity is
established across an insecure network (for example, Internet).
The following tunneling protocols are supported on the Nortel GGSN for
the Gi interface:
• L2TP
• L2TP over IPSec
• IPSec
• GRE
• ATM-VC VPN
• MPLS VPN
Gy Interface Protocol
The Gy interface is defined in “3GPP TS 32.299, version 6.1.0,
Diameter Charging Applications.” Diameter Credit Control (DCC)
facilitates GGSN online, real-time charging interoperability and system

Introduction 2-7
integration with 3rd party credit control servers through the use of a
standard based Diameter interface.
Gx Interface Protocol
The Gx interface is defined in “3GPP TS 29.210, version 6.0.0,
Charging rule provisioning over Gx interface” and provided for the
policy control of PDP context. The Gx interface is based on Diameter
as specified in “RFC 3588, Diameter Base Protocol” and Diameter
Credit Control (DCC) Application as specified in “IETF Draft draft-ietf-
aaa-diameter-credit-control-05_04.rtf Diameter Credit-Control
Application.” DCC is also known as the Gy interface. Gx specific AVPs
are supported over the existing DCC protocol. With regard to the
Diameter protocol, the GGSN acts as the Diameter client (network
element requesting charging rules) and the CRF acts as the Diameter
server.
Two models are supported for the Gx interface.

• Model 1: Single Gx/Gy server interacting with a common Gx/Gy
signalling interface on the GGSN. This is also known as Gx over
Gy. The CRF and DCC server are co-located. The interface is used
for both policy control and credit control.
• Model 2: Distinct Gx (CRF) and Gy (DCC) servers present in the
network, resulting in distinct Gx and Gy signalling interfaces on the
GGSN.

GGSN services 2
In addition to the standard interfaces, Nortel GGSN supports a variety
of GGSN services. Depending on what services PLMN operators want
to offer to the subscribers, different kinds of configuration profiles can
be provisioned. These profiles are feasible through the service
functions provided by the Nortel GGSN. For example, access to the
Intranet, Internet or ISP may involve specific service functions, such as
user authentication, user authorization, address allocation and end-to-
end encryption between the mobile and the Intranet/ISP.
To address the need of customers who place more emphasis on the

number of subscribers that can be supported and the speed at which
their sessions can be activated, the Nortel GGSN offers an
aggregation GGSN configuration option at an APN level granularity.
Refer to “Aggregation Access Point Name” for more information.
The Nortel GGSN provides the following configurable services for

subscribers:
— Remote Authentication Dial-In User Service (RADIUS)
authentication
— Dynamic Host Configuration Protocol (DHCP) address
allocation
— RADIUS address allocation
— Local address pool
• Outbound Tunneling
— L2TP
— L2TP over IPSec
— IPSec
— GRE
Attention: Outbound tunneling is not supported for Aggregation

APN.
• Accounting
— GTP Accounting
– G-CDR Auditing
– Tariff Based Billing (Time of Day billing)
– Automated G-CDR Transfer

Introduction 2-9
— RADIUS Accounting
• OA&M
— Operational Measurements
— Event Logs
— Alarms
— Active Session Management (ASM)
— Command Line Interface (CLI)
— CORBA Interface
— Patching
• Wireless Services
— GGSN QoS
— Tariffing (i.e. Prepaid, GeoZone)
— Wireless Application Protocol (WAP)
Attention: WAP is supported only through RADIUS Accounting for

Aggregation APN.
• IP Services
— Firewall
— Traffic Policing
— Traffic Shaping
— Policy-Based Forwarding
— Web Steering
— Personal Content Portals
— DiffServ Marking
— Anti-Spoofing
— Content Based Billing(CBB)
— Event Based billing (EBB)
— Node and Management ISP services
— Wap 1.2/2.0 and HTTP 1.1 Redirection
— Traffic Performance Optimizer (TPO) Interworking
— Content Filtering

— Flow Management
• IP Routing
— OSPF
— RIP
— BGP
— IS-IS
— IP Multicast
— MPLS
Attention: IP Multicast is not supported for Aggregation APN.

3-1
Functional description 3
Overview 3
Nortel GGSN functionality is built on the base on the Nortel Services
Edge Router 5500 (SER 5500) platform. In this chapter, only GGSN
specific functionality is described.
The following functions are provided on the Nortel GGSN to support

GGSN functionality:
• IP and PPP PDU type over GTP
• GTP - L2TP tunnel switching with IPSec option
• Outgoing to Intranet via IPSec, GRE, VLAN Tagging, ATM VC, or
MPLS
• Access Point Name (APN) configuration
• Subscriber Access Control
— Subscriber RADIUS authentication
— Visited GGSN (V-GGSN) Access Control
• Address allocation using DHCP, RADIUS, or local address pool
• GTP accounting with auditing capability
• RADIUS accounting
• Content based billing
• Real-time billing via CTP or DCC
• GGSN QoS support
• GGSN OA&M
• Wireless Application Protocol (WAP) service
• Lawful Interception (LI)
• Software Optionality Control (SOC)

3-2 Functional description Copyright © 2000–2008 Nortel Networks
To support the functionality listed above, the GGSN must interwork

with different components within the PLMN and PDN networks. Figure
3-1 “GGSN interworking components” on page 2. summarizes the
supported protocols on the GGSN for interworking with different
external components.
Figure 3-1
GGSN interworking components
CGF DHCP Server FTP Server LIG
GTP’ DHCP FTP SCS Client

RADIUS Server IPSec
Java RMI
RADIUS
SMP
GGSN SCS Server
SGSN GTP CLI/SNMP/

CORBA
TCP/UDP DCC (Gy)

TPO OSS
WRAP
Server Gx CTP
Application Diameter Credit

Server CRF CFS real-time Control Server
charging server
Top-Up Server
Legend:
- CFS - Content Filtering
- CGF: Charging Gateway Function
- CRF: Charging Rule Function
- CTP: Card Telephony Protocol
- DCC: Diameter Credit Control Application
- DHCP: Dynamic Host Configuration Protocol
- GTP: GPRS Tunneling Protocol
- GTP’: GPRS Tunneling Protocol Prime
- LIG: Lawful Interception Gateway
- OSS: Operations Support System
- RADIUS: Remote Authentication Dial In User Ser-
vice
- SMP: Shasta Management Protocol
- SNMP: Simple Network Management Protocol
- TPO: Traffic Performance Optimizer

Functional description 3-3
The GGSN supports the following network models:

• Wireless ISP model
• L2TP Virtual Private Network (VPN) model
• IPSec VPN model
• GGSN VPRN model
• ATM VPN model
• VLAN VPN model
• MPLS VPN model
These network models allow the GGSN to provide alternative

configurations for mobile subscribers to access public or private
networks through a raw IP or a different tunneling protocol based on
the configuration. For more information see Chapter 4, “Network
deployment models”.
Functional concepts 3
The following sections explain concepts that are fundamental to the
GGSN.
Internet Service Provider (ISP)

The Nortel GGSN uses the concept of an ISP to partition the GGSN
into separate areas of functionality. An ISP is a logical entity that
encapsulates all of the services, interfaces, and functionalities of one
service provider. An ISP on the GGSN is conceptually similar to a
virtual router. The GGSN may contain multiple ISPs.
The GGSN uses the ISP concept to define the OAM interface, Gn
interface, the Ga interface and one or more Gi interfaces, the ADMF/
DF2/DF3 interface, and the Traffic Performance Optimizer (TPO)
interface. This is accomplished by creating an ISP for the Gn interface
which implements the GTP protocol, an ISP for the Ga interface which
handles the GGSN GTP accounting, one or more ISPs for the Gi
interfaces that implements Access Point Name (APN) associated
services and protocols, an ISP for the interface to LIG which provides
the lawful intercept function, and an ISP for the interface to TPO
Server which provides the data optimization and compression
functions. An ISP is automatically created for the OAM interface to the
SCS Server. GGSN needs a resync via SCS GUI if the IP address of
any ISP on the GGSN is changed.
The Default ISP (sometimes called the Management ISP) is

automatically created when software is first loaded onto the GGSN.

The role of the Default ISP is to serve as the communication path

between the GGSN and the SCS Server.
Attention: The GGSN must be re-synced using the SCS GUI if the
IP address of any ISP on the GGSN is changed.
Figure 3-2 “GGSN ISP logical configuration” on page 4. shows the

logical relationship of the Default ISP, Gn ISP, the Ga ISP, the
connection ISPs, the LI ISP, and the TPO ISP.
Figure 3-2
GGSN ISP logical configuration
GGSN
Connection
APN
Gi
ISP
APN
Gn
Gn ISP
SGSN
SGSN APN
SGSN Connection
ISP
APN
Packet Data
APN
Network
APN
Connection
LI ISP
ISP
APN
APN
TPO ISP
LIG
Default
Ga ISP
ISP
Ga OAM
TPO
Server
OAM
Network
An ISP is considered a Gn ISP when it is configured with the GTP

tunneling protocol. An ISP is considered a Ga ISP when it is
configured with the Ga interface with GTP’ protocol. An ISP is

considered a Connection ISP when it is configured with an Access

Point Name (APN). An ISP is considered a LI ISP when it is configured
with the interface to LIG. An ISP is considered a TPO ISP when it is
configured with the interface to TPO Server.
Only one Gn ISP, one Ga ISP, one LI ISP, and one TPO ISP can be
supported per Nortel GGSN. If more than one Gn ISP, Ga ISP, LI ISP,
or TPO ISP is configured on Nortel GGSN, it is considered a
configuration error. However, the Ga interface with the GTP’ protocol
has the option to be configured in the Gn ISP. If the Ga interface in the
Gn ISP option is chosen, the configuration of Ga ISP is not required.
Only one Ga interface can be configured on Nortel GGSN, which can
be located in the Gn ISP or the Ga ISP. Figure 3-3 “GGSN ISP logical
configuration without Ga ISP” shows the relationship between the Gn
ISP and the connection ISPs without a Ga ISP.
Figure 3-3
GGSN ISP logical configuration without Ga ISP
GGSN TPO
TPO ISP
Server
Connection
SGSN APN
SGSN
ISP
SGSN APN
Gn ISP
Gn
APN
Connection
ISP
APN
APN
Ga
APN
Connection
Default ISP
ISP
APN
OAM APN
Network OAM
LI ISP
LIG

The GTP tunnel is provisioned in the Gn ISP. The Ga interface with

GTP’ protocol is provisioned in the Gn ISP or the Ga ISP. One of the
Gn ISP and Connection ISP is configured as the TPO ISP. It is
independent of the network models being implemented.
APNs are provisioned on a Connection ISP according to one of the

network models described in Chapter 4, “Network deployment
models”.
How an APN is configured determines the network model that it will be

deployed with. One Connection ISP can contain multiple APNs, and
each APN can be configured as a different network model. Since an
ISP can span multiple GGSN devices, the APN added to an ISP also
spans the same devices.
When GTP on the Gn ISP receives a Create PDP Context Request, it

determines which Connection ISP is to be used for this session by
matching the APN specified in the request with an APN configured for
the Connection ISP. If one is found, the routing and services
configuration of that ISP and APN are applied to the session.
If more than one Connection ISP is configured with the same APN,
then a match is made with the Connection ISP that was configured
first. Any other ISPs with that APN are never used.
At a high level, the configuration of GGSN functionality on the SER 5500

consists of:
• Configuration of the Default ISP.
• Configuration of the Gn ISP for the Gn interface and optional Ga
interface.
• Optional configuration of the Ga ISP for the Ga interface.
• Optional configuration of the LI ISP for the LIG interface.
• Optional configuration of the TPO ISP for the TPO Server interface.
• Configuration of the Connection ISPs for the Gi interfaces with
APNs.
Default ISP
The Default ISP is configured using the command line interface during
initial installation of the GGSN. The role of the Default ISP is to permit
communications between the GGSN and the SCS Server. Only when
communication has been established, the SCS Server can be used to
further provision the GGSN.

The initial provisioning of the Default ISP is relatively basic. It consists

of defining the IP address of the ISP, adding one or more physical
connections and logical interfaces, assigning static routes, activating
routing protocols, etc. For further information about initial provisioning
of the Default ISP, refer to Nortel Services Edge Router 5500
Overview.
Gn ISP
The Gn ISP implements the Gn interface on the Nortel GGSN. This is
achieved by configuring the ISP with a GTP tunnel. The configured
GTP tunnel on the Gn ISP is a logical entity to identify the Gn interface.
One or more SGSNs can communicate with the Nortel GGSN using
one Gn ISP. The Nortel GGSN node IP address should be used for the
GGSN routing on the DNS servers instead of Gn interface address.
The Nortel GGSN supports both “access” and “trunk” interfaces. An

“Access” interface assumes a single session per Virtual Channel (VC)
with the VC mapped to a specific SSM. To fully utilize the load sharing
mechanism on the GGSN, the PDP sessions need to be dynamically
allocated on different SSMs. Provisioning the Gn interface as “trunk”
interface facilitates load sharing between SSMs since it uses the line
card firmware to map PDP sessions to the proper SSMs. The mapping
of PDP sessions to SSMs is based on the Flow Label for GTP Version
0 messaging and the TEID for GTP Version 1 messaging. Only “trunk”
interface is supported on the Gn interface for GTP tunneling, the
“access” interface is not supported on Nortel GGSN for subscriber
access.
When a GTP tunnel is added to an ISP, it is necessary to specify a

Connection Template that the interface will use (see Chapter 8, “GUI
Provisioning”, section “Connection Template”). The Connection
Template must be defined as the encapsulation type of “GTP” for it to
be used by the Gn ISP. If matching of the APN should be done against
any APN configured on the Nortel GGSN, the “Connection ISP” should
be set to “ANY” within the Connection Template. If matching of the
APN should be done on a specific Connection ISP, the “Connection
ISP” should be set to the ISP that the APN matching uses.
GGSN GTP Accounting can be optionally done in the Gn ISP. The

CGF Profile contains the accounting billing information for the Ga
interface. Since a Gn ISP can span multiple devices, the GTP’ Profile
in the Gn ISP associates a device with a specific CGF profile.
Therefore, different CGF Profiles can be assigned to different GGSNs.
Figure 3-4 “Gn ISP configuration diagram” illustrates the Gn ISP

configuration concepts based on the Service Creation System* (SCS)*
Graphical User Interface (GUI).

Figure 3-4
Gn ISP configuration diagram
Gn ISP
Access Properties
GTP Tunnel GTP’ Profile
Connection Template CGF Profile

Connection Templates
GTP’ Profiles
CGF Profiles

Ga ISP
The Ga ISP is an optional ISP that is configured for the billing
information transfer using the Ga interface. The advantage of
configuring a dedicated ISP for the billing transfer is to separate the
interfaces to the bearer network and to the OAM network. In this case,
the IP packets will not be tandemed between these two networks
through the GGSN.
In the Ga ISP, the CGF Profile contains the accounting billing

information for the Ga interface. Since a Ga ISP can span multiple
devices, the GTP’ Profile in the Ga ISP associates a device with a
specific CGF profile. Therefore, different CGF Profiles can be
assigned to different GGSNs. Only one CGF Profile can be assigned
to a device at any time across the Gn ISP and Ga ISP.
Figure 3-5 “Ga ISP configuration diagram” illustrates the Ga ISP

configuration concepts based on the SCS GUI.
Figure 3-5
Ga ISP configuration diagram
Ga ISP
Access Properties
GTP’ Profile
GTP’ Profiles
CGF Profile
CGF Profiles
Connection ISP
The Connection ISP implements a Gi interface on the GGSN. This is
achieved by configuring an ISP with an APN. The Gi interface on the
Connection ISPs should be configured as trunk connection.

When an APN is added to an ISP it is necessary to specify a Subscriber

Template for the APN to use. The Subscriber Template must be
configured in a way that the behavior of the APN is defined according
to the network models discussed in Chapter 4, “Network deployment
models”. This involves
• Assigning membership to an Access Group, which defines a DHCP
Profile, a RADIUS Profile, and IP address pools.
• Optionally selecting the Outbound Tunneling method.
Tariff Profiles and Application Profiles are also assigned to the APN if it
uses either of these services. Since a Connection ISP can span
multiple devices, the Tariff or Application Profile is specified on a per
device basis.
Figure 3-6 “Connection ISP configuration diagram” illustrates the

Connection ISP configuration concepts based on the SCS
provisioning.

Figure 3-6
Connection ISP configuration diagram
Connection ISP
Access Properties
APN
PPP Profiles
Subscriber Application Tariff GGSNQoS ToD Admin
Billing Template Profile Profile Profile Profile State
Application Profiles
Tariff Profiles
GGSN QoS Profiles
ToD Profiles
Identification Outbound Tunneling Services IP Address Allocation Account

Tunnels
L2TP
Access Group Membership=Group
RADIUS Profiles
DHCP Profiles
DHCP Profile RADIUS Profile IP Address pools
Connection Template
Service Policies
Content Based Billing
LI ISP
LI is configured as a separate ISP on the GGSN. This ISP can only be
accessed by authorized users. Using a separate ISP restricts access
to the LI configuration and parameters. The password for the LI ISP
must be known to access the LI configuration.

To provide a connection between the GGSN and LIG, VLAN

connection or IPSEC tunnel(s) must be configured using the LI ISP.
Also, a new LI Profile containing ADMF related information (IP
address/port) is configured using the LI ISP.
For a secure connection, use of IPSec tunnel is recommended.
TPO ISP
The Traffic Performance Optimizer (TPO) ISP on the GGSN is used to
communicate with the TPO Server. The IP address of TPO ISP is used
by the TPO Server to send IP packets to the GGSN. There can be only
one TPO ISP per GGSN and it has to be a separate ISP, in other
words, can not configure Gn, LI, Ga, or Connection ISP to be a TPO
ISP.
The first service policy in Connection ISP that is applied to the

incoming packet is TPO service. The TPO service policy detects that
the packet needs to be forwarded to TPO Server. The packet is then
handed over to the TPO ISP before it goes through the rest of the IP
services. The packet is then sent to the TPO server over the GGSN-
TPO GRE loop back interface.
Access Point Name

The Access Point Name (APN) determines many of the characteristics
of a data session. Many differing APNs can be configured upon a GGSN
to support data sessions with different characteristics. The APN upon
which a data session is based is delivered to the GGSN in the Create
PDP Context Request message. Characteristics of the data session
which are determined by the APN are:
• Subscriber authentication requirements
• IP address allocation method
• Accounting information
• Real-time charging versus postpaid subscription
• Wireless Application Protocol (WAP) server interaction
• IP Services
• Access Group
• VPRN membership
• PDP session limit
For detailed configuration information, see section “APN Group”.
Based on the APN received within the Create PDP Context Request,
matching is done with the APN against all APN records in the

configuration database. When the match is found, the APN record with
the specific APN and ISP is retrieved. The APN record has GGSN
accounting information in it and a subscriber template listed. Using the
subscriber template listed in the APN record, all the subscriber specific
information is determined.
With the APN Session Limit, the maximum number of concurrent PDP
sessions allowed to use the APN can be specified on a per device
basis. The cause value for PDP session reject after the limit is reached
is “No Resources Available.” Once the APN session limit has been
reached, the GGSN generates a MINOR level alarm. After five
minutes, this alarm is automatically cleared if the number of sessions
using the APN has dropped below the configured limit.
The subscriber template also contains a reference to an Access Group

which has information such as a RADIUS Profile and a DHCP Profile
listed. For VPRN subscribers, the subscriber record points to an entry
in the VPN Manager that provides information such as the IPSec
Profile, RADIUS Server, and DHCP Server.
Subscriber Template
The Subscriber Template is used to provision a group of subscribers
that share the same profiles and services. An instance of a subscriber
is created after matching to a specific Subscriber Template. The
GGSN matches a mobile subscriber with a Subscriber Template using
the APN specified in the Create PDP Context Request. When an APN
is provisioned, it is associated with a specific Subscriber Template that
in turn has all user profiles (for example, RADIUS Profile) and Service
Profiles (for example, IP Service Profile and Policies) associated with
it.
RAT Mapping
RAT Mapping is SOC activated on a per SCS basis. The function RAT
Mapping is triggered on a per APN basis. The serving RAT is
provisionable in SGSN Mapping table. When RAT Mapping is enabled,
the GGSN derives the serving RAT from the table if it is not received in
Create/Update PDP Context Request messages.
The provisioning of the RAT is optional. The provisioning of a default

value is also optional. If no default value is provisioned, “Unknown” will
be used as the default. The following table shows the logic to derive
the RAT.

3GPP defined value Reserved(0) is used as Unknown for this feature.

Table 3-1
Derived RAT mapping logic
With “RAT Mapping” RAT RAT not received in GTP

enabled received in
GTP
Matching entry in the Use the Use the RAT of the matching entry
SGSN Mapping table received RAT
found
Matching entry in the Use the Default entry in the SGSN Use the RAT of
SGSN Mapping table not received RAT Mapping table provisioned the default entry
found
Default entry in the SGSN Use “Unknown”
Mapping table not (0)
provisioned
GTP protocol 3
One of the main functions of the GGSN is to provide routing and
tunneling functionality for the PLMN. To provide the routing and
tunneling capability, a GTP tunnel is established between the GGSN
and other SGSNs within the same or another PLMN. The GTP tunnel
implements the GTP protocol. The GGSN supports GTP Version 0
defined in 3GPP TS 09.60, and Version 1 defined in 3GPP TS 29.060
version 3.12.0, for both PPP and IP PDU types.
The GGSN supports the mobile initiated PDP Context Activation

procedure only.
In addition to the 3GPP standard defined IEs, the Nortel-specific

information can also be encapsulated in the Private Extension IE and
gets passed through the Gn and Gp interfaces. Refer to “GTP Protocol
Extension”.
Multiple primary PDP contexts

The GGSN supports up to 11 primary PDP contexts per mobile
subscriber for GTP Version 0 and GTP version 1. Each PDP context
has its own IP address. In the Create PDP Context Request
messages, the multiple primary PDP contexts should have the same
IMSI IE and different NSAPI IE. The APN IE may be different among
multiple primary PDP contexts.
The multiple primary PDP contexts are treated as independent PDP

session paths and there is no adverse interaction for billing events.
However, there may be issues with interactions with external data

servers. While multiple primary PDP contexts are supported on the

GGSN, they may not be supported when interacting with the same
external data server. The external data servers are configured on a per
APN basis with the SCS GUI.
Secondary PDP Context

The GGSN supports secondary PDP context activation for GTP
version 1 for IP PDU type, in which multiple PDP contexts share the
same APN, IMSI, and PDP address. The term PDP bundle is used to
describe these multiple PDP contexts collectively. Each PDP context
must have a different NSAPI and may have different QoS and IP
services applied. GGSN supports up to 11 total PDP contexts per
mobile subscriber, whether primary or secondary. The primary PDP
context is the first context in the bundle that is set up. Once a
secondary PDP context is established, the order in which the PDP
contexts were activated no longer matters. The last PDP context to be
deleted from the bundle is considered the primary PDP context.
Secondary PDP context activation is performed via the Create PDP
Context Request.
RADIUS authentication is performed only on the primary PDP context

activation. Attributes returned from the RADIUS for single APN feature
are applied to the PDP bundle.
When the GGSN receives a secondary Create PDP Context Request

for a session that has the same IMSI and NSAPI of an already existing
PDP context on the GGSN and the TEID in the request is different
from the TEID of the existing PDP context, then the GGSN deletes the
existing PDP context and does not respond to the request. When the
request is retransmitted, the GGSN processes the request.
Protocol interaction
The GGSN supports GTP fallback and fallforward functionality as
defined in 3GPP TS 23.060, version 3.11.0, “Service Description”.
GTP fallback functionality is the ability for an established Version 1
PDP context to be updated to Version 0, when the mobile moves from
a Version 1 SGSN to a Version 0 SGSN. GTP fallforward functionality
is the ability for an established Version 0 PDP context to be updated to
Version 1, when the mobile moves from a Version 0 SGSN to a
Version 1 SGSN.
IP PDU type
For the IP PDU type, the PPP session is established between the
Terminal Equipment (TE) and the Mobile Station (MS). The PPP
information is captured in the Protocol Configuration Options (PCO) IE
within the Create PDP Context Request and sent to the GGSN from

SGSN. If GTP-L2TP tunnel switching is provisioned, a PPP session is

established between the GGSN and the L2TP Network Server (LNS).
See “Tunnel switching for IP PDU” on page 3-74 for a detailed
description.
In GPRS networks, the GTP tunnel is established between the SGSN

and the GGSN. In UMTS networks, the GTP tunnel is extended from
the SGSN to the UMTS Terrestrial Radio Access Network (UTRAN).
From the GGSN perspective, there is no difference between
supporting GTP protocol in the GPRS network or the UMTS network.
Figure 3-7 “IP/PPP sessions for IP PDU type” shows the IP session
and PPP session in the GPRS/UMTS network for the IP PDU type.

Figure 3-7
IP/PPP sessions for IP PDU type
IP
PPP
Packet Data
Network
GTP Tunnel
PLMN SGSN GGSN
TE
IP
PPP PPP
GTP Tunnel L2TP Tunnel Packet Data

PLMN SGSN GGSN Network
IPSec
TE (Optional)
IP
PPP
GTP Tunnel GRE Tunnel Packet Data

PLMN SGSN GGSN Network
TE
The GTP tunnel establishment on the GGSN is triggered by receiving

the Create PDP Context Request from the SGSN. After the Create
PDP Context Request is received, mobile subscriber authentication (if
required) and IP address allocation are done before the GTP tunnel is
created. A Create PDP Context Response is returned to the SGSN
with the proper cause value depending on whether the GTP tunnel is
established successfully or not.
If a mobile subscriber is identified as a real-time charging Service user,

user authorization via the real-time charging server is required before
the GTP tunnel is set up. If user authorization fails from the real-time

charging server, the PDP Context Request is rejected and the GTP
tunnel is not set up.
Figure 3-8 “GTP tunnel setup for IP PDU type” summarizes the PDP
context activation procedure for the IP PDU type on the GGSN. For
more information on the PDP context activation procedure, refer to
3GPP TS 03.60, version 7.8.0, “Service Description” and 3GPP TS
23.060,version 3.11.0 “Service Description”.
Figure 3-8
GTP tunnel setup for IP PDU type
SGSN GGSN
Create PDP Context Request For IP PDU type, mobile

subscriber authentication
(PDP Type = IP, APN, Protocol Configuration Options, etc.)
and IP address allocation
is done.
The method of
authentication (if required)
and the method of IP
address allocation can be
specified by configuration.
Create PDP Context Response
(End User Address, Protocol Configuration Options, etc.)
GTP Tunnel Established
Data Packets transferred between mobile and PDN
Once the GTP tunnel is established between the GGSN and the
SGSN, data packets can be transferred between the mobile and the
PDN in both directions.
PPP PDU type

The PPP PDU type is supported on the GGSN in two different access
methods. For PPP sessions terminating on the GGSN, the GGSN can
run in both transparent or non-transparent mode. For PPP sessions
that pass through the GGSN, the GGSN is considered to run in
transparent mode only and user authentication and IP address
allocation are done in the remote Intranet. One exception is the single
APN scenario where the GGSN can run in non-transparent mode for
PPP pass through sessions.

The following services can be applied only to PPP sessions that are
terminated on the GGSN:
• Tariff Service
• WAP Services
• IP Services
For PPP sessions that pass through the GGSN with GTP-L2TP tunnel
switching, only Tariff service among the services listed above is
supported.
The establishment of PPP session terminating or passing through

GGSN is currently done using SYNC mode of PPP LCP negotiation.
The LCP negotiation in ASYNC mode is currently not supported on the
GGSN.
Figure 3-9 “IP/PPP sessions for PPP PDU type” shows the support of
the PPP PDU type on the GGSN.

Figure 3-9
IP/PPP sessions for PPP PDU type
IP
PPP
Packet Data
Network
GTP Tunnel
SGSN
TE
IP
PPP
Private Data
GTP Tunnel L2TP Tunnel Network
SGSN IPSec
TE (Optional)
GGSN
PLMN IP
PPP Private Data
Network
GTP Tunnel IPSec Tunnel
SGSN
TE
IP
PPP Private Data
Network
SGSN GTP Tunnel GRE Tunnel
TE

For PPP sessions terminated on the GGSN, the GTP tunnel must be
set up before Link Control Protocol (LCP) negotiation for the PPP
session. The PPP LCP negotiation messages are also counted for
GTP accounting and RADIUS accounting methods. Figure 3-10 “GTP
tunnel setup for PPP PDU type” summarizes the PDP context
activation procedure for PPP PDU type.
Figure 3-10
GTP tunnel setup for PPP PDU type
MS SGSN GGSN
Create PDP Context Request

(PDP Type = PPP, APN, etc.)

(Protocol Configuration Options, etc.)
LCP Negotiation
LCP Authentication (if required)
NCP Negotiation (includes Address Allocation)
Path management
The GGSN supports path management for GTP Version 0 and Version
1 protocols by sending Echo Request and Echo Response messages
on established paths for both GTP-C and GTP-U.
By default, the path failure detection is disabled, as indicated by the

Echo Timer default value of 0. The Echo timer, measured in minutes,
is provisionable from the SCS GUI as a parameter of the GTP tunnel.
Echo Request messages are sent only if the Echo Timer is non-Zero.

The GGSN keeps track of the peer SGSN IP addresses that have
active sessions. If the number of active sessions becomes 0 for a
given SGSN IP address, the corresponding SGSN IP address is no
longer stored. The GGSN maintains information regarding the number
of active sessions with all SGSN peers as well as their Restart Counter
value. If the Echo Timer is non-zero, the GGSN will start a timer for
each path with active sessions. Once a timer expires, the GGSN will
send an Echo Request to the standard port of the peer SGSN.
Once an Echo Request is sent to a given SGSN peer and no response

is received, the GGSN will resend the Echo Request when the T3-
RESPONSE timer expires. The Echo Request will be retransmitted
N3-REQUEST times before considering the SGSN down. Upon
marking the SGSN down the GGSN flags all contexts associated with
the down SGSN for deletion and removes the SGSN from the peer list.
As the SGSN is considered down and to avoid flooding the Gn
interface, the flagged contexts are deleted silently with no GTP
messaging. For contexts with both control and data paths established,
if either the GTP-C or GTP-U SGSN is down, both paths of the context
are deleted.
The optional Recovery IE that contains the GGSN Restart Counter is

included in the following outgoing messages:
• Create PDP Context Response
• Update PDP Context Response
• Echo Response
If the Restart Counter value received in the Recovery IE of the incoming

message is different from the value stored by the GGSN for that peer
SGSN, the GGSN silently takes down all contexts associated with the
SGSN. The Restart Counter value is ignored for GTP-U. The following
messages are checked for the Restart Counter value:
• Create PDP Context Request
• Update PDP Context Request
• Echo Request
Idle Session Verification

An Update PDP Context Request can be sent from the GGSN for
verifying the PDP context with the SGSN. The Idle Verification timer is
a periodic timer that invokes the Idle Verification functionality at the
specified intervals from the receipt of the last uplink packet. The Idle
Verification Timeout functionality sends an Update PDP Context
Request to the SGSN for verifying the context if the context is idle until
the Idle Verification Timer expires. If the “Idle Verification Timeout” is

set to a value other than zero and there is no uplink data before the
Idle Verification Timer expires, the GGSN sends an Update PDP
Context Request to the SGSN for verifying the context.
Direct Tunnel
The Direct Tunnel Flags IE (with DTI bit set to 1) is sent in the Update
PDP context request from SGSN which invokes Direct Tunnel. The
DTI flag in the IE shall be set by SGSN while sending Direct Tunnel
Update Request if the SGSN decides to establish a Direct Tunnel.
Once the GGSN receives a Direct Tunnel Update Request the user
plane is created between the RNC and GGSN.
If the Direct Tunnel context on GGSN receives an Error Indication from

RNC, the GGSN will send an Update Request to SGSN to re-establish
the Data Tunnel back between SGSN and GGSN. The SGSN sends
the SGSNs Data TEID and SGSN Data address in the update
response and the session is reverted back to Non-Direct Tunnel mode.
GTP-U sequence numbers

The GGSN supports GTP-U sequence numbers for GTP version 1. If
the far end SGSN requests delivery order (by specifying “with delivery
order” in the Delivery Order field of the QoS Profile for Create/Update
PDP Context Request message), the GGSN includes a sequence
number in the GTP header of the outgoing GTP-U messages for the
specified context. The sequence number range is 0 to 65,535 and is
reset back to 0 when it reaches the maximum range.
The GGSN does not support buffering or reordering of incoming GTP-

U messages before delivery to the SGSN. The sequence number that
the GGSN includes in the GTP header of the outgoing GTP-U
messages is an incremental sequence number.
Even though the GGSN includes a sequence number in the GTP

header of the outgoing GTP-U messages, the GGSN sets the Delivery
Order field of the QoS IE to “without delivery order” in the Create/
Update PDP Context Response message to the SGSN to indicate no
reordering has been performed by the GGSN.
APN Selection Mode

The GGSN supports the use of the Selection Mode IE in the Create
PDP Context Request to accept or reject the PDP context activation.
The APN Selection Mode is configured on the APN Group Access
dialog box. If the received value of Selection Mode IE is selected in the
corresponding checkbox on SCS GUI, the PDP context activation will
be rejected. The cause value in the Create PDP Context Response for
the rejected PDP contexts is “User Authentication Failed”.

Subscriber Username
The GGSN supports a maximum of 253 characters as the length of the
PCO IE. If the total length of the Username + Domain exceeds 253, it
is truncated to 253 characters.
P-CSCF discovery
In order for an IMS client to communicate with another client, it must
first obtain the addresses of the P-CSCFs that it may connect to. P-
CSCF discovery allows the mobile to request the list of P-CSCF
addresses from the GGSN.
The mobile requests P-CSCF address discovery by including the P-

CSCF Address Request flag in the Protocol Configuration Options
(PCO) within the Create PDP Context request or the Create
Secondary PDP Context request. When the Nortel GGSN receives
this flag (and an IMS Profile containing at least one P-CSCF address
is associated with the APN) the configured number of P-CSCF
addresses are included in the PCO of the successful Create PDP
Context response. If the number of provisioned P-CSCF addresses is
less than the provisioned number to return, then the whole list is
returned in the response.
P-CSCF addresses are not included in unsuccessful Create PDP

Context responses.
In order to provide load sharing of the P-CSCF servers, the Nortel

GGSN will round-robin through the list of P-CSCF address. Each time
a list is sent, the first address in the list is then moved to the last
position. Note that each time the list is modified, the round-robin
selection begins again at the first address provisioned in the list.
A maximum of 24 P-CSCF addresses are added per profile. The

maximum limit for IMS profiles is 256 profiles per ISP and 256 profiles
per SSG.
IM CN Subsystem Signalling flag

IMS signalling is supported on general purpose contexts. Dedicated
IMS signalling contexts are not supported.
A mobile requests a dedicated IMS signalling context by including the

IM CN Subsystem signalling flag in the PCO IE of the Create PDP
Context Request or the Create Secondary PDP Context Request. If
the Nortel GGSN receives a Request with the IM CN Subsystem
signalling flag set, the response that is sent to the mobile does not
include the IM CN Subsystem signalling flag. This indicates that
dedicated IMS signalling is not supported.

HSDPA Parameters
Nortel Networks GGSN receives the new HSDPA values in the Quality
of Service (QoS) parameter IE. HSDPA parameters in the QoS IE are
optional parameters. When a QoS parameter is sent with Rel 5 QoS
parameters, then the first 12 octets are sent as the negotiated R99
QoS parameters. If octet Maximum bit rate for downlink (extended) or
Guaranteed bit rate for downlink (extended) is received with a value
greater than 0x4A, Nortel Networks GGSN returns a value of 0x4A in
the response.
QoS Signalling Indication

In order to provide enhanced Quality of Service (QoS) on the Radio
Access Network, the mobile may set the Signalling Indication flag in
the QoS profile sent in the PDP create request. The requested QoS
can be downgraded by the GGSN through provisioning.
In order to downgrade the requested QoS, the “Allow QoS Signalling

Indication” checkbox on the subscriber’s APN Profile should be
unchecked.
When a Create, Create Secondary, or Update PDP Request with the

QoS signalling indication flag set to “Yes” is received, the Nortel GGSN
checks the subscriber’s APN profile. If the “Allow QoS Signalling
Indication” field is unchecked, the QoS signalling indication flag is set
to “No” in the create PDP response.
Single Access Point Name 3

Single APN enables the wireless operator to minimize the number of
provisionable APNs and to invoke services on a per-subscriber basis.
Subscribers of different VPNs could use the same APN but have
different VPN membership and different IP services. The information
sent back from the RADIUS Server at PDP session setup time
indicates the VPN membership and IP services that are associated
with this subscriber and is used in this PDP session.
The single APN concept enables APN consolidation by storing the per-
subscriber information on the RADIUS Server instead of grouping the
services into different APNs on the GGSN. The services that do not
depend on the APN on the GGSN and can be provisioned on a per-
subscriber basis on the RADIUS Server include:
• VPN membership
• IP Services
• Real-time Charging Subscription
• Outbound Tunneling

• Address Pool
In a non-transparent mode, the RADIUS Access-Accept message sent

from the RADIUS Server may carry one or more attributes signifying
VPN membership, Tariff Profile for real-time charging subscription, IP
Service Package or Outbound L2TP Tunneling information. One or
more of these attributes may be provisioned on the RADIUS Server for
each subscriber. If these attributes are not returned from the RADIUS
Server, the provisioning of the corresponding APN through SCS is
used. The minimum information that must be passed in the RADIUS
Access-Request message for the per-subscriber information lookup is
the subscriber’s username and password. The anonymous mode user
authentication can be used for the Single APN.
When the Single APN attributes are returned from the RADIUS Server
to the GGSN, these attribute values overwrite the APN configuration
provisioned through SCS. This approach effectively associates the
services with individual subscriber, not the destined APN for this PDP
session.
For example, to declare a VPN membership without single APN

capability, the following configuration is provisioned on the GGSN:
• Provision a VPN within the VPRN Manager using SCS.
• Provision the Subscriber Template for the APN with the VPN name.
However, with Single APN capability, the VPN membership

configuration becomes:
• Provision an APN with authentication required.
• Provision a VPN within the VPRN Manager using SCS.
• Provision the RADIUS Server to return the subscriber’s VPN name
upon successful authentication for the subscriber.
Prior to the introduction of Single APN, provisioning multiple VPNs

required one APN for one VPN. The APNs needed to be provisioned in
both the HLR and the subscribers’ mobiles. With additional RADIUS
Server provisioning, Single APN simplifies the complexities of
ensuring that the correct APNs are provisioned in the appropriate
subscriber’s mobiles across a large subscriber base.
On the GGSN, the returned VPN attribute in the RADIUS Access-

Accept message is used to match a provisioned VPN and the matched
VPN configuration is used for the subscriber. As a result, many
subscribers may access the same APN, but retain different VPN
memberships.

If the RADIUS Server does not return any Single APN attributes, the
configuration provisioned through SCS is used. Returning these Single
APN attributes from the RADIUS Server is optional. Nevertheless, the
configuration of multiple APNs for different VPN memberships can still
be used on the GGSN instead of having the per-subscriber information
provisioned on the RADIUS Server.
Single APN capability is supported for all network models and is

available only for the non-transparent mode. The VPN VSA attribute
returned from RADIUS Server for Single APN is not supported when
the PDP Context uses an Aggregation APN. If VPN VSA is returned,
the Create PDP Context Request message will be rejected.
Vendor Specific Attributes (VSA)

To support VPN Membership, IP Service Package and real-time
charging subscription, the provisioning of three new VSAs on the
RADIUS Server are required. These VSAs are returned in the RADIUS
Access-Accept message:
• SHASTA-VPN VSA for the VPN Membership
• SHASTA-SERVICE-PROFILE VSA for the IP Services Package
• SHASTA-PREPAID-SERVER VSA for the Tariff Profile Name
VPN membership
The VPN Name (SHASTA-VPN VSA) returned in the RADIUS Access-
Accept message is used to specify the appropriate VPN membership
for the subscriber.
For VPN network models, the returned attribute provisioned on the

RADIUS Server must contain a value that is equal to the name of a
VPN configured within the VPRN Manager through SCS. For example,
in a VPN configuration, the VPN name is “nortel-vpn”. For the Single
APN to make use of this VPN, the value “nortel-vpn” must be returned
in the SHASTA-VPN attribute.
Note that neither the IPSec tunnel nor the GRE tunnel are dynamically
established once the RADIUS SHASTA-VPN attribute is returned. The
tunnel must be pre-configured through SCS.
An invalid VPN name returned from the RADIUS Server triggers a log
from the Event Manager. A returned VPN name is invalid only if it can
not be found within the VPRN Manager. In this case the invalid VPN
name is ignored and the PDP session setup continues.

APN configuration with new VPN

When a VPN name is returned in the Access-Accept message from
the RADIUS Server, the VPN configuration matched by the VPN name
may have different profiles and characteristics from the existing
Access Group configuration or the existing VPN configuration
provisioned through SCS for the Single APN. Replacing an existing
VPN with a new VPN in the APN configuration is not supported.
In Figure 3-11 “APN configuration for Single APN”, the APN

configuration provisioned for the Single APN through SCS has its
Subscriber Template associated with an Access Group. The Access
Group is provisioned with the RADIUS Profile, DHCP Profile, DNS and
NetBIOS Name Server (NBNS) that are supposed to be used in this
PDP session. When the Access Group is replaced by a new VPN in
the APN configuration upon receipt of a SHASTA-VPN attribute, the
APN configuration becomes the one shown in Figure 3-12 “APN
configuration with new VPN Profiles” that includes the profiles and
characteristics provisioned in the new VPN instead of the existing
Access Group.
Figure 3-11
APN configuration for Single APN
APN
Subscriber Application Tariff GGSNQoS ToD

Billing Template Profile Profile Profile Profile
Membership = Access Group
DHCP Profile RADIUS Profile DNS NBNS

Figure 3-12
APN configuration with new VPN Profiles
APN
Subscriber Application Tariff GGSNQoS ToD

Billing Template Profile Profile Profile Profile
Membership = VPRN Member
DHCP Profile RADIUS Profile DNS NBNS
When replacing the existing access group setting with a new VPN setting
in the APN configuration, the following rules are applied:
• The RADIUS Profile provisioned in the VPN needs to be the same
as the RADIUS Profile in the existing Access Group configuration.
If no RADIUS Profile is provided in VPN, the one in the Access
Group is used.
• The DHCP Profile in the VPN may be different from the one in the
existing Access Group. The interaction between those two DHCP
Profiles is specified in Table 3-2.
Table 3-2
DHCP Profile interaction between existing Access Group and new VPN
DHCP Profile in DHCP Profile in Action taken for the PDP

existing Access new VPN Session
Group
None Configured as This configuration is not allowed.

DHCP Client The DHCP Profile in new VPN is
ignored and PDP session setup
continues.
—sheet 1 of 2—

Table 3-2
DHCP Profile interaction between existing Access Group and new VPN
DHCP Profile in DHCP Profile in Action taken for the PDP

existing Access new VPN Session
Group
None Configured as This configuration is not allowed.

DHCP Relay Agent The DHCP Profile in new VPN is
ignored and PDP session setup
continues.
Configured as None DHCP Client configuration in

DHCP Client existing Access Group is used.
Configured as Configured as DHCP Client configuration in new

DHCP Client DHCP Client VPN is used.
Configured as Configured as This configuration is not allowed.

DHCP Client DHCP Relay Agent This PDP session is rejected.
Configured as None DHCP Relay Agent configuration

DHCP Relay Agent in existing Access Group is used.
Configured as Configured as DHCP Client configuration in new

DHCP Relay Agent DHCP Client VPN is used.
Configured as Configured as This configuration is not allowed.

DHCP Relay Agent DHCP Relay Agent This PDP session is rejected.
—sheet 2 of 2—
• The DNS primary and secondary addresses in the new VPN

configuration are used for this PDP session. If there is no DNS
address configured in the VPN, the existing Access Group’s DNS
addresses are used.
• The NBNS primary and secondary addresses in the VPN
configuration are used for this PDP session. If there is no NBNS
address configured in the VPN, the existing Access Group’s NBNS
addresses are used.
IP Services
The Service Profile (i.e. SHASTA-SERVICE-PROFILE VSA) in the
Access-Accept message returned from the RADIUS Server identifies
the IP Services available to the subscriber.
The Service Profile provisioned on the RADIUS Server must contain

the name of a Service Profile provisioned within the Service Policy
Manager through SCS. For example, within the Service Policy
Manager, the Service Profile Name is “general”. In order to make use

of this Service Profile, the value “general” must be returned in the

SHASTA-SERVICE-PROFILE VSA.
An invalid Service Profile returned from the RADIUS Server will trigger
a log from the Event Manager. A returned Service Profile is invalid only
if it cannot be found within the Service Policy Manager. Also, if an
invalid Service Profile is returned, the PDP session is taken down.
Policy merging is introduced to determine the correct and complete set

of IP services which are applied to a particular subscriber. Policy
merging takes input from one or more sources such as the real-time
charging server, RADIUS Server, GGSN QoS Profile, and subscriber
template. If the policies are from RADIUS or the real-time charging
server, the determined IP services stay for the duration of the PDP
context. Otherwise the IP services may change after context
modification/fallback/fallforward, such as QoS change upon the receipt
of Update PDP Context Request.
Real-time charging subscription

The Tariff Profile (i.e. SHASTA-PREPAID-SERVER VSA) in the
Access-Accept message returned from the RADIUS Server identifies
the real-time charging server or DCC server that should be used for
the Subscriber.
The Tariff Profile provisioned on the RADIUS Server must contain a

name of Tariff Profile provisioned within the Access Properties
Manager through SCS. For example, the Tariff Profile name on the
GGSN is “tariff”. In order to make use of this Tariff Profile, the value
“tariff” must be returned in the SHASTA-PREPAID-SERVER VSA.
A value ‘NULL’ returned in the attribute will not turn on the real-time
charging service and the PDP session remains established. An invalid
Tariff Profile returned from the RADIUS Server will trigger a log from
the Event Manager and stop the PDP session setup. A returned Tariff
Profile is invalid only if it can not be found within the Access Properties
Manager.
Outbound tunneling
A PDP session with IP PDU type or PPP PDU type can perform GTP-
L2TP tunnel switching with the outbound tunnel being returned from
the RADIUS Server instead of being provisioned through SCS.
To perform GTP-L2TP Tunnel Switching, the following RADIUS Tunnel

attributes returned from the RADIUS Server are required.
• TUNNEL-TYPE (MANDATORY)
• TUNNEL-CLIENT-AUTH-ID (OPTIONAL)

• TUNNEL-SERVER-AUTH-ID (OPTIONAL)
• TUNNEL-SERVER-ENDPOINT (MANDATORY)
• TUNNEL-MEDIUM-TYPE (MANDATORY)
• TUNNEL-CLIENT-ENDPOINT (OPTIONAL)
• TUNNEL-PASSWORD (OPTIONAL)
• TUNNEL-ASSIGNMENT-ID (MANDATORY)
• TUNNEL-PREFERENCE (OPTIONAL)
Dynamic outbound tunneling is supported for the L2TP VPN network

model. Dynamic L2TP tunneling must be accomplished by
provisioning a separate APN specifically for the dynamic outbound
tunneling. This can be done by provisioning the Subscriber Template.
Dynamic outbound tunneling provides the capability of establishing the
outbound L2TP tunnel for IP PDU or PPP PDU using the returned
Tunnel attributes from the RADIUS Server.
Multiple L2TP tunnels from RADIUS are supported. The attributes of

multiple L2TP tunnels are returned in a single RADIUS Access-Accept
message. The GGSN then selects one L2TP tunnel based on
preference. Load balancing for L2TP sessions among multiple tunnels
is also supported.
The “Dynamic L2TP VPN” option on the Subscriber Template changes

the behavior of the APN such that it expects to perform Dynamic L2TP
Outbound Tunneling. If the tunnel attributes are not provided by the
RADIUS Server, the PDP session with IP PDU type or PPP PDU type
is not established and a log is triggered in the Event Manager. For
more information refer to “Subscriber Outbound Tunneling”.
Table 3-3 specifies the GTP-L2TP Tunnel Switching’s configuration

interaction for different Single APN scenarios. The different scenarios
include a PDP session with IP PDU type or PPP PDU type, receiving
Tunnel attributes from the RADIUS Server or not, and existing
Outbound Tunneling configuration. The Outbound Tunneling
configuration is provisioned through SCS using the Outbound
Tunneling tab of the Subscriber Template.

Table 3-3
L2TP-GTP Tunnel Switching configuration interaction for Single APN
PDU type Single Outbound Tunneling Provisioning via SCS GUI

APN
Scenario No Layer 2 Tunnel via Dynamic L2TP VPN
Tunneling L2TP
(LAC) The Tag of The Tag of tunnel
Tunnel attribute is 0
attribute is
not 0 GGSN with GGSN
provisione without
d L2TP (individual
tunnel )
provisione
d L2TP
tunnel
IP PDU Tunnel This PDP L2TP-GTP L2TP-GTP L2TP-GTP L2TP-GTP

type attributes session is tunnel tunnel tunnel tunnel
are rejected. switching switching switching switching
returned uses uses uses uses
from the provisioned returned provisioned returned
RADIUS L2TP L2TP L2TP L2TP
Server. tunnel. attributes. tunnel. attributes.a
No Tunnel The L2TP-GTP This PDP context is rejected.

attribute is wireless tunnel
returned ISP model switching
from the is used for uses
RADIUS this PDP provisioned
Server. context. L2TP
tunnel.
PPP PDU Tunnel This PDP L2TP-GTP L2TP-GTP L2TP-GTP L2TP-GTP

type attributes session is tunnel tunnel tunnel tunnel
are rejected. switching switching switching switching
returned uses uses uses uses
from the provisioned returned provisioned returned
RADIUS L2TP L2TP L2TP L2TP
Server. tunnel. attributes. tunnel. tunnel.
No Tunnel The L2TP-GTP This PDP context is rejected.

attribute is wireless tunnel
returned ISP model switching
from the is used for uses
RADIUS this PDP provisioned
Server. context. L2TP
tunnel.

a. LNS must be configured with LAC Host Name “l2tp-host”. GGSN using “l2tp-host” in Dynamic
L2TP VPN mode, when L2TP tunnel does not pre-configured.
IP Address Pool
Single APN enables the wireless operator to select and assign IP
address pools to specific user groups within the same APN. An
example of this capability is to use a single APN for consumers with
private IP addresses and corporate subscribers with public
addresses.The address pools can be classified by the following
options:
• Reserved / Unreserved
• Activation / Deactivation
The option of Reserved /Unreserved address pools will prioritize
address pools for the Framed-Pool attribute. Based on the availability
of an address pool for new address assignment, address pools can be
marked as Deactivated /Activated.
The potential depletion of local IP address pools are monitored, before

the GGSN runs out of IP addresses. Suitable alarms are also
introduced corresponding to this.
RADIUS Framed-Pool Attribute Support

Nortel GGSN supports the selection of local address pools for IP
address assignment based on the RADIUS Framed-Pool attribute
received with the Access Accept response message from RADIUS.
The RADIUS Framed-Pool attribute is used to search for the
appropriate address pool within the user access group.This
functionality is optional on the Nortel GGSN and can be enabled in the
configuration of the RADIUS Profile. It is turned off by default. The
RADIUS server has to be configured to send the Framed-Pool
attribute and the address pool which is configured on the RADIUS
must belong to the subscribers access group or no address is
assigned.
Single APN Accounting

Certain single APN attributes are captured in billing records. Both GTP
Accounting and RADIUS Accounting capture the following information:
• Name of the IP service profile that supplied the CBB policy used by
the subscriber.
• Name of the VPN of which the subscriber is a member.
• Name of the real-time charging service profile assigned to the
subscriber via single APN.

• LNS IP address for L2TP tunnelled sessions.
Refer to “GTP’ Charging Protocol” and Nortel GGSN RADIUS

Interface Guide (411-5221-928) for details of the extensions to GTP
Accounting and RADIUS Accounting billing records.
Aggregation Access Point Name

The Aggregation APN provides a means to configure the GGSN in an
aggregation mode. When configured for aggregation mode, which is
offered on a per APN basis, the GGSN uses new functions for IP
address management. The aggregation node provides the GGSN with
increased PDP session activation rate and increased simultaneous
PDP session support, while still supporting the GGSN IP services.
The Connection ISPs, which must have the device configured with
subnet dedication and without individual route advertisement, enable
aggregation mode for APNs. While the Connection ISP configuration
enables all APNs on a device to offer increased levels of activation
rate and simultaneous session support, this benefit is maximized for
the Aggregation APNs.
Subscriber Access Control 3

Visiting GGSN (V-GGSN) Access Control
Visiting GGSN Access Control functionality enables the GGSN to
allow or disallow the mobile subscriber access to the network. If the
visiting subscriber, identified by the Mobile Country Code (MCC) and
Mobile Network Code (MNC) derived from the IMSI, belongs to the
partnering operator then the access to the network is granted.
A new Access Control Profile is added to allow the operator to

provision a list of MCC/MNC for its partnering network. Up to 100
MCC/MNC pairs are supported per Access Control Profile.
MNC size is checked for consistency for each Access Control Profile.
Either 2 or 3 digit MNCs are allowed to be entered per MCC within the
profile.
Visiting Access Control is an optional functionality on the GGSN. The

operator enables it by assigning the Access Control Profile with MCC/
MNC pair entries to an APN. Access Control Profiles are configured on
the Connection ISP and can be associated with one or more APNs.
IMSI and Access Control Profile

When the GGSN receives a Create PDP Context Request message
for the APN with the assigned Access Control Profile, it compares the
mobile subscriber’s MCC and MNC retrieved from the IMSI against a

list of permitted MCC/MNC pairs in this Profile. The decision to retrieve

a 2 or 3 digit MNC from the IMSI is based on the size of MNC for the
particular MCC, declared when this MCC is entered into the Access
Control Profile. If a match is found, access is granted; otherwise
access is denied with the cause value “User Authentication Failed”
and the Access Control Rejection counter is incremented to record this
event. If the “Access Deny Log” checkbox is enabled in the APN, the
event log is generated, reporting the rejected IMSI, APN, MSISDN and
ISP.
If the MCC/MNC list in the Access Control Profile changes or the

Profile is assigned to the APN while the call is in progress, it affects
only new Create PDP Context Requests. Any existing contexts remain
active and are not affected.
If Gi Interface Availability functionality is activated, it takes precedence

over this functionality. The “Disallow PDP Context activations”
configuration on the Gn Tunnel, takes precedence over this
functionality. The V-GGSN Access Control functionality does not apply
to Secondary PDP Context as access is already granted to the first
PDP Context activation.
Subscriber authentication
The GGSN supports normal user authentication and anonymous
mode user authentication when operating in non-transparent mode.
Only RADIUS authentication service is supported on the GGSN. The

user authentication method for the mobile subscriber is configurable.
Normal RADIUS authentication

The GGSN supports the following authentication protocols mentioned
in RFC 2865, “Remote Authentication Dial In User Service (RADIUS)”
for RADIUS authentication:
• Challenge Handshake Authentication Protocol (CHAP)
• Password Authentication Protocol (PAP)
For a GTP tunnel with IP PDU type, the PCO IE of the Create PDP
Context Request carries the authentication attributes for the user
authentication. If authentication is successful, then the
acknowledgements are passed back to the mobile in the PCO IE of the
Create PDP Context Response. The CHAP re-challenge is not
supported for a PDP session with IP PDU type.
For the PDP session with PPP PDU type, authentication is part of the
PPP negotiation. The PPP negotiation is sub-divided into three parts:
1. The LCP negotiation

2. Authentication, depending on the outcome of the LCP negotiation

on the authentication protocol
3. After a successful authentication, the Network Control Protocol
(NCP) negotiation is started.
The PPP session is ready for data packets when NCP negotiation is
completed. The CHAP re-challenge is supported for PDP sessions
with PPP PDU type.
As indicated in the IPCP part of the PCO IE for IP PDU type or the
NCP negotiation for PPP PDU type, the mobile subscriber may
request for Domain Name Server IP address or NetBIOS Name Server
IP address. Supposed that vendor specific attributes, MS-Primary-
DNS-Server, MS-Secondary-DNS-Server, MS-Primary-NBNS-Server,
MS-Secondary-NBNS-Server and/or Cisco-Primary-Secondary-DNS-
Server (Vendor Type: 1), have been configured on the RADIUS Server
for the subscriber, IP address value of those attributes will be used to
respond to the subscriber’s requests.
The GGSN accepts the VSA received without any data from RADIUS
for the vendor specific attributes Shasta Service Profile and Shasta
Prepaid Server based on the APN Configuration.
Refer to Nortel GGSN RADIUS Interface Guide (411-5221-928) for

supported RADIUS attributes. Unsupported RADIUS attributes are
ignored when they are received on the GGSN.
Anonymous RADIUS authentication

Anonymous mode user authentication supports a GTP tunnel with IP
or PPP PDU type. Anonymous mode user authentication can be
activated for an individual APN. For IP PDU type, when a Create PDP
Context Request without the PCO optional IE is received for an IP
PDU type session and the APN allows Anonymous Mode user
authentication, then either the actual MSISDN, IMSI or a user
configurable name and password are used as the User Name and
Password for user authentication with RADIUS Server. If the PCO IE is
included in the Create PDP Context Request, the User Name and
Password information is obtained from the PCO IE, over-riding the
decision to allow the possibility of anonymous authentication.
However, if the anonymous mode user authentication is not allowed
for that APN and the PCO IE is not included in the message, the
Create PDP Context Request is rejected and the GTP tunnel is not set
up.

The GGSN supports the below functionalities for the username

(MSISDN, IMSI or username) configured through anonymous mode
user authentication which are controlled by APN Configuration.
• Appending domain name to the anonymous username

Adds APN name as the domain appended to the anonymous
username. This is applicable to the MSISDN, IMSI and customer-
defined username anonymous RADIUS authentication options. The
username along with the domain name is used in all types of RADIUS
(authentication and accounting), DIAMETER messages and also the
ICCN messages sent to the L2TP LNS.
Example: If the mobile subscriber session is activated for MSISDN

12345678910 and APN “my-apn.com”, the anonymous username is of
the form 12345678910@my-apn.com.
• Override Mobile supplied Username

Overrides any username supplied by the mobile. If this option is
selected, the username and password information included in the
PCO IE of the Create PDP Context request (for IP PDU) or included in
the PPP authentication message from the mobile (for PPP PDU) are
overridden with the anonymous username (MSISDN or IMSI or
configured username) and password which will be used for RADIUS
authentication.
Also for IP and PPP PDU types, if PCO IE(included in the create PDP
Context Request) is received with only username and no password,
then the GGSN supports the following different behaviors as
mentioned below in Table 3-4. This is controlled by APN configuration:
RADIUS Authentication Type, as mentioned in Chapter 8, Table 8-17.
Table 3-4
Radius Authentication Type configuration values & corresponding GGSN
behavior
Configuration Value Behavior
RFC Compliant Default behavior

The GGSN rejects the create PDP
Context Request
Send only password attribute and no GGSN processes the request by

password value sending only password attribute and no
password value(only tag & length), to
the RADIUS server for authentication.

Table 3-4
Radius Authentication Type configuration values & corresponding GGSN
behavior
Send padded and encrypted blank GGSN processes the request by

character as password to RADIUS sending a padded and encrypted blank
character as the password, to the
RADIUS server for authentication.
IP address allocation 3
The following IP address allocation methods are supported by the
GGSN:
• RADIUS
• DHCP
• Local IP address pools
• Static IP address from Home Location Register (HLR) (that is, the
IP address specified in the Create PDP Context Request)
Overlapping private IP addresses are supported for the IPSec VPN,

GGSN VPRN, and GRE VPN network models since each VPN uses
its own routing table.
RADIUS
In the Wireless GRE/VLAN Access model, it is possible to send
RADIUS messages through GRE tunnel or VLAN access connection.
The determination of whether the messages go through the tunnel or
outside the tunnel is based on routing (matching destination IP
address with routing table entries on the GGSN).
When RADIUS is used for IP address allocation it may be necessary

to provision a sink route to avoid bounced packets. For more
information see Table 6-3.
RADIUS static IP address allocation

The GGSN supports static IP address allocation through the RADIUS
protocol. When the RADIUS Server is configured to provide a static IP
address for the subscriber, an IP address is returned after the
subscriber authentication is successful. The GGSN uses the IP
address returned from the RADIUS Server regardless of the
configured method of IP address allocation for the subscriber.
Although RADIUS is one of the methods supported by the GGSN for
IP address allocation, it is supported only when RADIUS
authentication is used.

RADIUS dynamic IP address allocation

The GGSN supports dynamic IP address allocation through the
RADIUS protocol. If the RADIUS Server is configured to provide a
dynamic IP address for the subscriber, an IP address is returned to
GGSN after the subscriber authentication is successful. At the end of
PDP session, a RADIUS STOP message must be sent to the RADIUS
Server for the release of dynamic IP address.
The dynamic IP address allocation on the GGSN can be done in the

following ways based on the WAP deployment model and the RADIUS
Accounting status:
• The RADIUS Server acts as a WAP Proxy Server and WRAP
messaging is used between GGSN and Application Server.
RADIUS Server forwards all WAP requests to the Application
Server. A WRAP STOP message results in the release of the IP
address that was allocated on the RADIUS Server.
• When RADIUS Accounting is enabled, the dynamic IP address
allocated on the RADIUS Server can be released through RADIUS
Accounting messaging. The Application Server sits behind the
RADIUS Server, and the RADIUS Accounting STOP message
results in the release of the IP address.
All PDP contexts for GTP version 0 and version 1 include the 3GPP-
Session-Stop-Indicator attribute in the WRAP or RADIUS Accounting
STOP message. This attribute is mandatory for release of the IP
address on the RADIUS server.
DHCP
The GGSN supports IP address allocation using the DHCP Server.
The GGSN can function as a DHCP Client on behalf of a mobile or as
a relay agent between DHCP Server and mobile.
When DHCP is used for IP address allocation it may be necessary to

provision a sink route to avoid bounced packets. For more information
see Table 6-4.
DHCP Client
The GGSN DHCP Client is responsible for negotiating IP address
allocation for the mobile subscriber, renewing the lease of an IP
address before the lease expires, and releasing the IP address after
the mobile finishes using the IP address. Multiple DHCP Servers can
be configured; the DHCP Client unicasts to all configured servers and
selects the first response. The multiple DHCP Servers configuration
provides fault tolerance and redundancy to IP address allocation using
DHCP.

IP address allocation using the DHCP Client is supported for both IP

and PPP PDU types on the GGSN. For GTP tunnels with PPP PDU
type, IP address allocation using a DHCP Client can only be used for
the PPP session terminated on the GGSN.
In the Wireless GRE Access model and Wireless VLAN Access model,
it is possible to send DHCP messages through a GRE tunnel or VLAN
access connection. The determination of whether the messages go
through the tunnel is based on routing (that is, matching destination IP
address with routing table entries).
If the DHCP Client is configured for the APN, the IP address returned
from the RADIUS Server has higher precedence than the IP address
through the DHCP Client. In another words, the DHCP Client address
allocation will not occur if an IP address has already been allocated
through the RADIUS Server.
If the “DHCP uses VPN routing context” box is checked in the VPRN
configuration through the SCS GUI, the DHCP Client on the GGSN
goes through the VPN to reach the DHCP Server. Otherwise, the
DHCP Server can be located in the public network and shared by
multiple VPNs for address allocation.
If the DHCP Server is serving multiple APNs that span multiple

devices, it can be configured optionally with a named pool of IP
addresses allocated for a specific device crossing multiple APNs. The
pool name configured on the GGSN is sent to the DHCP Server in the
option #77 (User Class ID Option). A Connection ISP on a specific
device is associated to an address range by a DHCP Profile
configured with the appropriate pool name. This configuration can
prevent routing issues. The other option is to use the DHCP Relay
Agent address. For more information, refer to “DHCP Relay Agent
address” on page 3-44. Multiple IP address ranges can be set up for a
single pool on the DHCP Server. The GGSN specifies the use of a
specific IP address pool by passing the pool name in option #77 (User
Class) parameter field.
Client ID can be set to IMSI+NSAPI or MSISDN+NSAPI based on

configuration which is used for the mapping of client ID to a specific
PDP session (see “DHCP Profile” in Chapter 8, “GUI Provisioning”).
The DHCP Client uses the DHCP Relay Agent to send and receive
appropriate messages. Therefore, both DHCP Client and DHCP Relay
Agent historical statistics are incremented for the DHCP Client
configuration.

Figure 3-13 “GGSN DHCP Client message flow” on page 42. shows
the DHCP Client message flow using the User Class Option for
identification of an Address Pool to use for a specific APN.
Figure 3-13
GGSN DHCP Client message flow
SGSN GGSN DHCP Server

(PDP Type = IP, APN, Protocol Configuration Option, GTP Tunnel Setup:
etc.) • Authentication (if required)
• IP Address allocation = DHCP
• DHCP Profile ==> Name Pool=CDE
DHCPDISCOVER
(User Class = CDE)
DHCPOFFER
(IP Address from pool with
User Class = CDE)
DHCPREQUEST
DHCPACK
(End User Address, Protocol Configuration
Options, etc.)
Data Packets transfer between mobile and PDN
DHCP Relay Agent

The Nortel GGSN supports a DHCP Relay Agent for GTP tunnel IP
address allocation with the IP PDU type only. It does not support any
GTP-L2TP tunnel switching. The DHCP Relay Agent can apply only to
GTP version 1 PDP session. If a GTP version 0 Create PDP Context
Request message is received with Relay Agent selected in the APN
configuration, the PDP context initialization is rejected with cause
value System Failure. The GGSN DHCP Relay Agent is used to relay
the end to end DHCP negotiation between a mobile’s DHCP Client
and a DHCP Server. It relays a DHCP packet between the mobile’s
DHCP Client (i.e. encapsulated in GTP payload) to a DHCP Server.

If the IP address allocation on the GGSN for the APN subscriber is set
to DHCP Relay Agent, the GGSN does not take part in the negotiation
for the IP address for the mobile. It is not responsible for renewing the
lease for the IP address either. The DHCP Client running on the
mobile is responsible for IP address allocation, renewal and releasing
of the address after the session is terminated.
If the DHCP Relay Agent is configured for the APN, the IP address
returned from the DHCP Relay Agent has the highest precedence. In
other words, when a session is configured using DHCP Relay Agent
provisioned in the DHCP Profile associated with the Access Group,
the DHCP Relay Agent is the only address allocation method accepted
even if the “RADIUS/Local” button is checked on the addressing page
of Subscriber Template. If during a DHCP Relay Agent session the
RADIUS Server returns an IP address, then the Create PDP Context
Request is rejected and the session is brought down.
If “VPN Only” is selected in the VPRN configuration, the DHCP Server

can only be reached using the VPN whether the “DHCP uses VPN
routing context” box is checked or not.
When the GGSN receives a Create PDP Context Request for an APN
that has been configured to use the DHCP Relay Agent, it records the
End User Address IE of 0.0.0.0 and sends it to the SGSN in the Create
PDP Context Response message. The IP PDUs are passed from
subscriber’s DHCP Client to the DHCP Server through the GGSN after
the PDP session is established. After DHCP negotiation and after
receiving a DHCP ACK from the DHCP Server, the GGSN sends the
Update PDP Context Request message to the SGSN with an End
User Address IE. Since the IP address allocation is negotiated
between the DHCP Client on the mobile and the DHCP Server, the
DHCP Client on the mobile is responsible for renewing the lease of the
IP address with the DHCP Server.
Figure 3-14 “GGSN DHCP Relay Agent message flow” on page 44.
shows the DHCP Relay Agent message flow.

Figure 3-14
GGSN DHCP Relay Agent message flow
MS SGSN GGSN DHCP Server
GTP Tunnel Setup:

Authentication (if required)
(End User Address=0.0.0.0)
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
IP address is allocated
at the DHCP Server
Update PDP Context Request
End User Address
Update PDP Context Response
DHCP Relay Agent address

In addition to the option #77 User Class, the other option to allocate an
IP address from a specific address pool is to use the giaddr parameter
field in the DHCPDISCOVER message. The giaddr parameter field is
set to the IP address of the DHCP Relay Agent in the DHCP request
and response messages. A pool of IP addresses can be configured to
associate with a DHCP Relay Agent address on the DHCP Server. An
IP address can be allocated from the IP address pool based on the
giaddr parameter value received in the DHCPDISCOVER message.
On the GGSN, the DHCP Relay Agent address can be configured in
the DHCP Profile using the SCS GUI and put into the giaddr
parameter field. A DHCP Profile can be associated with an Access
Group or a VPN. The DHCP Relay Agent address based address
allocation is supported only for the wireless ISP model, GRE VPN
model and VLAN VPN model. In the Wireless GRE Access model and
Wireless VLAN Access model, it is possible to send DHCP messages
through GRE tunnel or VLAN access connection. The determination of

whether the messages go through the tunnel is based on routing (that

is, matching destination IP address with routing table entries).
In the Wireless ISP model, the DHCP Server is located in the public
Internet network. The DHCP Server can serve multiple APNs and
some of the APNs may span over multiple devices. If the operator
wants to allocate a pool of IP addresses for each device, a specific
DHCP Relay Agent address can be used for each device and a pool of
addresses can be configured for each DHCP Relay Agent address on
the DHCP Server crossing multiple APNs. If the operator wants to
have different pools of IP addresses for different APNs, a DHCP Relay
Agent address can be configured for each APN on the device.
The giaddr parameter field in a received DHCP request message is

checked on the DHCP Server. If it is not 0, the IP address in the giaddr
parameter field is used for the destination address of the DHCP
response message. In order to advertise the DHCP Relay Agent
address to the public network for routing the DHCP response
messages back, the DHCP Relay Agent address needs to be
configured in the Summary Route for the Wireless ISP model.
In the GRE VPN model, the DHCP Server is likely to be located in the
private Intranet network. See “Outgoing to Internet and Intranet using
GRE tunnel” on page 3-82. In the private Intranet, the DHCP Server
can serve one GGSN via a point-to-point GRE tunnel. A pool of IP
addresses can be configured to associate with a DHCP Relay Agent
address on the DHCP Server for that GGSN. The same DHCP Relay
Agent address value can be used in different GRE VPNs on different
DHCP Servers. Multiple GRE VPNs can be configured on the same
GGSN and multiple DHCP Relay Agent address values can be
provisioned for sending DHCP response messages back to the same
GGSN. The DHCP Relay Agent address value is configured on a per
VPN per GGSN basis.
To route the DHCP response messages back to the GGSN from the
private Intranet network, the DHCP Relay Agent address must be
provisioned so that the default ISP address will not be used. The
default ISP address may conflict with the local IP address of GRE
tunnel. On the other end of the GRE tunnel, the DHCP relay Agent
address needs to be configured for the tunnel reachability on the
Intranet CPE.
In the VLAN VPN model, the DHCP Server can be located with the
private VLAN VPN. A pool of IP addresses can be configured to
associate with a DHCP Relay Agent address on the DHCP Server for
that VLAN VPN. The DHCP Relay Agent address value is configured
on a per VPN per GGSN basis.

Both option #77 and DHCP Relay Agent address can be added to the
DHCP Profile at the same time. In this case, the giaddr parameter field
is set to the provisioned DHCP Relay Agent address value and the
User Class option parameter field is included in the messages. Note
that the option #77 applies only to the DHCP Client configuration. The
DHCP Relay Agent address applies to both DHCP Client and DHCP
Relay Agent configurations. If the DHCP Relay Agent address is not
provided in the DHCP Profile, the Connection ISP default address will
be used for the giaddr parameter field in the DHCP request and
response messages.
If the DHCP Relay Agent option is configured for the DHCP Profile, the
DHCP Relay Agent address based address allocation cannot interact
with Single APN. In other words, the DHCP Relay Agent address
value configured for an Access Group or a VPN works only when no
VPN name is returned from the RADIUS authentication.
When the DHCP Relay Agent address value is modified in the DHCP
Profile, the change will not be reflected in the existing PDP contexts
using the old DHCP Relay Agent address. Subsequent activated PDP
contexts will use the new DHCP Relay Agent address value.
Local address pool

The GGSN also supports dynamic IP address allocation using local
address pools. Multiple local address pools can be configured on the
Nortel GGSN for individual ISPs. Multiple address ranges can be
supported using multiple IP address pools per APN.
When the IP address Blackout Period timer is enabled, IP addresses

from deleted PDP Contexts using the local address pool remain
unavailable until the blackout timer expires. The IP address blackout
timer enhances network security by prohibiting the immediate reuse by
another subscriber, which could represent a security risk. The IP
address blackout timer allows the Billing System to clear the
respective IP address to subscriber mapping preventing potential
billing errors.
Static IP address
If an IP address is included in the End User Address IE within the
Create PDP Context Request which is derived from the subscriber
configuration on the HLR, the GGSN attempts to use the IP address
provided as the subscriber IP address for the PDP session.
If the IP address in the Create PDP Context Request does not match
the IP address returned from RADIUS Server after user

authentication, the Create PDP Context Request is rejected and the

PDP session is not set up.
GGSN accounting 3
The billing function on the GGSN is achieved through GTP accounting
and the RADIUS accounting. GTP accounting is a billing mechanism
to deliver G-CDR records to the CGF using GTP’ protocol. RADIUS
accounting is a billing mechanism to deliver accounting related
information to the RADIUS Accounting Server using the RADIUS
protocol.
Table 3-5 specifies the billing features supported by each accounting

mechanism.
Table 3-5
GGSN accounting billing features
Billing Feature GTP Accounting RADIUS Accounting
Hot Billing Supported Not Supported
Partial Billing Supported Supported
Real-Time Charging Supported Supported
Content Based Billing Supported Supported
Tariff Based Billing Supported Not Supported
Partial Billing for Roamers Supported Supported
G-CDR Auditing Supported Not Supported
SGSN Change Partial Billing Supported Supported
IMSI Based Billing Supported Supported
GTP accounting 3
GTP Accounting is supported by the GGSN. The accounting
procedure and the protocol used for GGSN accounting is specified in
the GPRS specification defined in 3GPP TS 32.015, version 3.6.0,
“Charging and Billing”. The GTP’ protocol is used for transferring the
GGSN accounting record (G-CDR) from the GGSN to the Charging
Gateway Function (CGF).
The GGSN is the anchor of the GPRS/UMTS data call and has most of
the information contained in the PDP context. The GGSN is
responsible for collecting charging information related to the external
data network usage and charging information on usage of the GPRS/

UMTS network resources related to the GGSN. This includes the

amount of data categorized by QoS, user protocols, and usage of the
packet data protocol address. Packet data volume in both uplink (i.e.
from Gn interface to Gi interface) and downlink (i.e. from Gi interface
to Gn interface) directions is counted separately. If Content Based
Billing is enabled and special rate counts have been produced, these
values will also be contained in the accounting record.
The operator has the option to disable GGSN GTP accounting on a

per APN basis using the SCS GUI. Additionally, if the APN’s ISP is
unreachable, (meaning the operational state is DOWN), uplink and
downlink data packet volume is not billed. This applies to real-time
charging service as well.
The GGSN billing function is distributed across the CMC and SSC cards.
The CMC and SSC perform the following tasks for GGSN billing:
• Call Detail Record creation and closure
• Partial record generation
• ASN.1 formatting of G-CDRs prior to transfer to the CGF or storage
to local disk
• Support of the GTP’ protocol stack used to transfer the G-CDRs to
the CGF
• Support of a primary and secondary CGF for redundancy
Two CGFs can be configured for each GGSN. The primary CGF is
used for normal accounting record transfer. The secondary CGF is
used only when the primary CGF is not accessible. If the primary CGF
later becomes accessible, a manual switch-over must be performed by
the operator. If both CGFs are not accessible, the accounting records
are stored on the local disk. If accounting records are sent to local
disk, the operator must periodically delete the accounting records to
prevent disk overflow. If the local disk is full, new accounting records
will be dropped.
When a possibly duplicated data record packet is sent to the

secondary CGF because the primary CGF is not accessible, a 2-
minute timer is started on the GGSN. If no response message for that
data record packet is received from the primary CGF and the timer
expires, a release data record packet message is sent to the
secondary CGF to have the data packet record released to the
downstream Billing System.
If no CGF is accessible from Nortel GGSN, then the accounting

records will be sent to local disk and the operator must periodically
delete the accounting records to prevent disk overflow.

Two streams of accounting are supported on the GGSN:

• Regular billing
• Hot billing - this option allows the transfer of the GGSN billing
records from the GGSN to the CGF when the record is generated
Figure 3-15
GGSN Accounting
GGSN
Accounting
Regular Billing Hot Billing
The accounting stream used for a specific APN is configured through

the SCS GUI. For more provisioning information see “APN Group”.
For real-time charging subscribers, the billing is tracked by the real-

time charging server and the accounting records generated by the
GGSN indicates that the subscriber has real-time charging service
active. To indicate real-time charging service, the charging
characteristics flags are set to indicate real-time charging and/or
Normal Billing options. The CGF and the Billing System should take
appropriate action to prevent duplicate billing for the real-time charging
subscribers.
Regular billing
For regular billing, the GGSN uses a buffering mechanism to improve
efficiency of the accounting system. There may be a delay involved
due to buffering of the accounting records. If the accounting records
are required to be transferred to the CGF immediately after the
records are generated, Hot Billing should be used. If regular billing is
selected, some delay may be encountered between accounting
records being generated and transferred to the CGF.
For regular billing, when an accounting record is generated, it is

queued in a pre-allocated buffer queue. When the queue is filled up or
a 30-second timer expires, the accounting records are then encoded
to ASN.1 format and transferred to the CGF. There are two versions of
the ASN.1 format, BER and PER. Both are supported by GGSN

Accounting. If the transfer is unsuccessful after the maximum retries,

the accounting records are stored on local disk.
Figure 3-16 “GGSN regular billing” on page 50. summarizes regular

billing on the GGSN and its functions.
Figure 3-16
GGSN regular billing
GGSN
Accounting

• Accounting records
generated
enter buffer queue
converted into ASN.1
format
transferred to CGFs
Hot billing
Another accounting option supported on the GGSN is hot billing. Hot
billing can be selected for an individual APN. With this accounting
option, the associated subscriber accounting records are encoded and
transferred to CGF immediately after the records are generated
without being queued in the buffer queue. Hot billing records
generated by the GGSN include the Charging Characteristic element
in the record.
Figure 3-17 “GGSN hot billing” on page 51. shows the hot billing
accounting option and its functions.

Figure 3-17
GGSN hot billing
GGSN
Accounting

• Accounting records • Accounting records
generated generated
• Accounting records • Accounting records
enter buffer queue converted into ASN.1
format
converted into ASN.1 • Accounting records
format transferred to CGFs
transferred to CGFs
GTP’ protocol
The GTP’ protocol defined in 3GPP TS 32.015, versions 3.2.0 and 3.6.0,
“Charging and Billing” is used for transferring GGSN accounting records
from the GGSN to a CGF. GTP’ on the GGSN provides the following
functions:
• When a CGF is not responding, the GGSN continues to send Echo
Requests to the CGF at the interval specified in the provisioning. If
Echo Request times out, it is not retransmitted until the next
periodic echo is scheduled.
• Upon receipt of an Echo Request or a Node Alive Request
message on the GGSN, a response message is sent back to CGF
and the echo timer is restarted. When the echo timer expires, an
Echo Request message is sent to the CGF.
• The provisioned packet timeout value is used for each
retransmitted message.
• Recognizes a CDR-handling node advertising its transfer
capabilities after a period of downtime.
• Reduces the possibility of sending duplicate G-CDRs to the CGF
that might arise during redundancy operations.
• Supports both GTP version 0 and version 1 header formats.
• Released or cancelled packets will be retransmitted up to the
maximum number of times specified in the CGF Profile “Maximum
Retries” option (see “CGF Profile”).

Since the UDP source port used for GTP' messages is dynamically
allocated, changes to the port number may occur without warning
following a CMC reboot, switchover or software upgrade. It is
recommended to configure the downstream CGF to respond to the
port number referenced in the GTP' message header.
The following Cause Values in the Data Record Transfer (DRT)

Response message are supported on the GGSN:
• Request accepted
• Request already fulfilled
• Request related to possibly duplicated packet already fulfilled
The following DRT Cause Values are treated as a temporary failure of

the CGF processing ability:
• Request not fulfilled
• No resource available
• System failure
The CDR packets are responded to and are retransmitted to the CGF
after the normal response timeout period. If they are not successfully
acknowledged after the maximum number of retransmits, the normal
CDR duplicate prevention mechanism is followed (the CDRs are
transmitted as possibly duplicate to the secondary CGF or written to
disk).
Tariff Based Billing

Tariff Based Billing allows operators to close the open traffic volume
container and open a new one based on provisioned tariff boundaries.
If the maximum amount of traffic volume containers has been reached
for the billing record, a partial record is generated and the new
container is opened in the subsequent partial record.
The operator defines the tariff boundaries through a Time of Day (ToD)
profile. In the profile, the specific hours to close the container are
selected, and the profile is added to the APN. Subscribers using the
APN with the configured ToD profile close and open new traffic volume
containers according to the selected tariff boundaries. This
functionality is supported only for GTP Accounting.
The ToD Profile provisioned for a APN configuration at the time a PDP
session is activated will remain for the duration of the PDP session
regardless of any subsequent changes to the APN configuration. Any
changes made to the APN configuration do not take effect until the
next time a new PDP session is activated. However, changes made to

the ToD profile linked to the APN such as setting or un-setting tariff
boundaries take effect in all circumstances, even for active PDP
sessions.
When ToD event is triggered, the Record Change Time of the

container which was closed due to ToD event will be exactly same as
the time at which the ToD event is triggered.
Accounting record generation

The GGSN produces accounting records for all APNs that have GTP
accounting enabled. The accounting records are transferred from the
GGSN to the CGFs in a timely manner to minimize the processing
required to store the accounting record on local disk.
A partial record is generated when the time limit or data volume limit
condition is met. The time and data volume counts are reset when a
partial record is generated. The Interim Record Session counts reflect
the cumulative totals over the entire lifetime of the PDP context. Only
Partial Records are supported for GTP Accounting. Interim Records
can be generated using RADIUS Accounting (see “RADIUS
Accounting” on page 3-65).
The GGSN provides the ability to capture accounting information on a

per PDP Context basis. The accounting records are captured for both
home and visiting subscribers. An on-going PDP context may have
several partial records generated in real-time. Upon certain conditions,
the G-CDR is closed and a new G-CDR opened with the same
Charging ID but with a different Record Sequence Number. The
downstream CGF and Billing System are responsible for aggregating
multiple G-CDRs belonging to the same PDP context. CDRs are sent
downstream to the CGF or written to disk only when successfully
encoded. If encoding of accounting records is unsuccessful, the billing
data is discarded.
Conditions for accounting record generation

The GGSN generates accounting records under the following
conditions:
• An accounting record is generated when a PDP context is
terminated, including PDP sessions that have session duration and
data transfer count of zero.
• A partial accounting record is optionally generated when the time
limit or the data volume limit is reached for the specific PDP
session.
The time limit and the data volume limit are configured through the
SCS in the APN profile or through the GTP tunnel for outbound

roamers. If the partial billing for roamers is enabled, the time limit
and data volume limit configured in the GTP tunnel are used when
subscriber activates a PDP context in a PLMN or roams to a
VPLMN. This partial billing function allows billing information to be
sent to the CGF in order to prevent loss of data when PDP contexts
have been open for a long period of time. The GGSN G-CDR
timestamps and duration values are accurate to within 1 whole
second. The data volume limit is the sum of the uplink and
downlink data passed through the GTP tunnel.
• Generation of partial accounting records at a consistent time

interval is supported. This is configurable on a per-APN basis. The
“Fixed Billing Interval” checkbox must be selected and the billing
time limit specified in the APN Group, Accounting/Billing tab dialog
box. This option is disabled by default. The GTP session durations
are calculated with an accuracy of +/-0.5 second, by rounding off to
the nearest second.
• Generation of partial accounting records at a consistent time
interval for roamers is supported. In addition to selecting “Fixed
Billing Interval” option for the APN, the option “Enable Partial Billing
for Roamers” and the billing time limit must be configured in the
GTP Tunnel Configuration, Billing for Roamers tab to generate
partial G-CDRs for roaming subscribers.
• A partial accounting record is optionally generated when maximum
changes occurs for the specific PDP session and the maximum
changes setting is configured through SCS in the APN Profile.
• A partial accounting record is generated when maximum number of
rates is reached for a Content Based Billing Policy. The Cause of
Record Closing field in the G-CDR is set to “Management
Intervention”. The maximum number of rates is predefined and
varies for different CBB versions. See “G-CDR Management
Extensions” for more description on the CBB record generation
trigger.
• A partial accounting record is generated when the partial billing for
roamers is enabled and the subscriber roams into a VPLMN or
roams back to the HPLMN.
• A partial accounting record is optionally generated when there is an
SGSN address change for the PDP context. If the option SGSN
Change Partial Billing is enabled in the “APN Group”, a G-CDR will
be generated in the event of an SGSN address change. The Cause
of Record Closing field in the G-CDR will be set to “SGSN
Change”. If the option is disabled, the GGSN does not generate a
partial billing record for every SGSN change. The GGSN allows the
optionality to allow/disallow generation of a partial billing record

every time the maximum limit of 3 SGSN changes is reached

(where 4 SGSN addresses are accumulated). A new check box
“Max SGSN Change Partial Billing” is added in the APN to enable
or disable this option. By default “Max SGSN Change Partial
Billing” check box is enabled. If “Max SGSN Change Partial Billing”
option is disabled, a partial billing record is not generated on every
third SGSN change (4 SGSN addresses are accumulated). If “Max
SGSN Change Partial Billing” option is enabled, the GGSN still
tracks up to the most recent SGSN addresses and corresponding
PLMN information and will include this information in billing
records.
• If the option SGSN Change Partial Billing is enabled in the APN
Group, a partial accounting record is generated for the PDP
context when there is a fallback from GTP version 1 to GTP version
0 or a fallforward from GTP version 0 to GTP version 1
accompanied by a SGSN address change.
• A partial accounting record is optionally generated when there is a
match made from a set of IMSI rules and 1) the time limit is
reached, or 2) the data volume limit is reached, or 3) the max
charging containers have generated for the PDP sessions. IMSI
based billing is enabled when an IMSI billing profile is added to an
APN. The time limit, volume limit, and the max containers are
provisioned on the IMSI billing profile.
• A partial accounting record is optionally generated when a PDP
context’s CBB rule base is changed to another CBB rule base. The
CRF may request a CBB rule base change for a particular PDP
context. If this occurs and the APN for the PDP session is
configured with “Charging Rule Base Change Partial Billing”
enabled, a partial G-CDR is generated. The change condition of
the billing container is “Record Closure” and the record closure
reason is “Management Intervention”.
Conditions for accounting records not generated
The GGSN generates accounting records with one or more containers
in it. In case if the record contains a single container with zero volume
and zero duration, then that particular record will be suppressed if the
record is generated as a result of periodic billing time limits. The
suppression or generation of ZVZD records can be controlled through
the check box “Generate ZVZD G-CDRs” provided in the APN -
Accounting/Billing tab.
Conditions for accounting container generation
The GGSN generates new accounting containers under the following
conditions:
• A new container is generated when the volume counter limit is
reached for the specific PDP session and the volume counter limit

is configured through SCS in the APN Profile. The volume counters

are 32-bit integers, therefore 4 billion bytes of data would need to
be sent for the counter to overflow.
• If the QoS Change Partial Billing option is enabled in the APN
Group Accounting/Billing tab, a new container is generated for QoS
Profile changes when the GTP version remains unchanged.
• If the RAT Change Partial Billing option is enabled in the APN
Group Accounting/Billing tab, a new container is generated for RAT
change when the GTP version remains unchanged.
• A new container is generated at configurable times of the day using
a ToD Profile. An APN profile may be assigned a ToD Profile
allowing for the generation of a new container at any hour of the
day.
Conditions for accounting container not generated
The GGSN generates accounting records with one or more container
in it each consisting of volume counts and time usage. If any of these
containers have zero volume and zero duration then the containers will
be removed from the record if the record is generated as a result of
periodic billing time limits. The suppression or generation of ZVZD
records can be controlled through the check box “Generate ZVZD G-
CDRs” provided in the APN - Accounting/Billing tab
G-CDR identification
The G-CDR contains PDP Context related billing information
consisting of uplink and downlink data volume counts, requested QoS
in the negotiated QoS field and the duration of the PDP context. The
partial record reason code “Maximum number of containers” is
supported with a maximum of 4 containers per G-CDR.
A 32-bit Charging ID assigned by the GGSN uniquely identifies each

G-CDR. This ID is unique to all contexts using the GGSN. Since
several GGSN nodes in a network may use the same Charging ID, the
GGSN address itself can be used along with the charging ID to
guarantee uniqueness among G-CDRs in the network and also allow
the downstream Billing System to aggregate a single PDP Context’s
CDRs from the GGSN and SGSN.
To ensure uniqueness in the event of a system failure, the last used

charging ID is periodically stored to non-volatile storage on both active
and inactive CMC cards. The frequency of the Charging ID file update
is every 600,000 charging IDs used. In the event of a CMC reboot or
switchover, the newly active CMC will read the values from the file on
local disk. A 32-bit Local Record Sequence Number is then
immediately incremented by a value of 300,000. This value is then

immediately written back to the file on disk and also sent to the
inactive CMC.
A 32-bit Local Record Sequence Number assigned by the GGSN is

placed in each CDR generated by the GGSN. All CDRs contain a
unique Local Record Sequence Number.
Accounting record storage

The accounting records for subscribers are stored on local disk if the
transfer of accounting records to CGFs is unsuccessful, or if no CGF
server has been configured.
In the event that the active CGF server loses connection or becomes
uncommunicative with the GGSN, G-CDR records will automatically
be redirected to the standby CGF (if provisioned and available). If
there is no standby CGF server or it is also uncommunicative, the G-
CDR records will be written to the disk on the active CMC of the
GGSN. Additionally, a CRITICAL alarm will be raised. When one of the
provisioned CGF servers becomes available, G-CDR records are
automatically redirected again to use the available CGF server (the
server now becomes the active CGF) and the CRITICAL alarm is
cleared. Any G-CDR record files on the GGSN disk will not be
automatically transferred to the active CGF server.
To begin the automatic transfer of the stored G-CDRs to the active

CGF, the “gtpbill disksend allow” GGSN CLI command must be issued
manually. After the command is issued, records in Unprocessed G-
CDR files (filenames ending in “U”) are transferred from disk to the
CGF. When all of the records in a given file have been sent and
acknowledged by the CGF, the file is deleted (unprocessed G-CDR
files are not automatically deleted). If a CMC switchover occurs before
all Unprocessed files have been transferred to the active CGF, they
will have to be transferred via manual FTP, as discussed in the next
section. Once transferred, they should be manually deleted from the
inactive CMC’s disk to eliminate the possibility of a duplicate transfer
later.
For any G-CDR records that are sent to the local disk, the GGSN first
places the records in a RAM buffer which is flushed to disk when either
the CDR-file open-time limit or CDR-file size limit is reached. Since the
records are initially stored in RAM, there may be a loss of data if the
GGSN is rebooted or suffers a power loss prior to flushing the RAM
buffer to disk.
There is no minimum or designated space allocated for G-CDR files

on the local disk. The local disk is not partitioned. As such, G-CDR

files contend for disk space on an equal basis with any other
application or service using the disk.
Manual G-CDR file retrieval

G-CDR files on the local disk can be retrieved by connecting to the
FTP server which is accessible through the management interface
(default ISP). After connecting to the FTP server, the operator should
retrieve the unprocessed G-CDR files (filenames ending in “U”) from
the “/disk/acct/gtp/cdrs” directory and then delete the retrieved files to
conserve disk space on the device. The G-CDR files are in binary
format so special care should be taken to make sure that binary
transfer mode is selected when performing the FTP transfer.
Additionally, it is recommended that the passive transfer mode be
used to ensure interoperability through firewalls.
G-CDR file description

The G-CDR files are written to the “/disk/acct/gtp/cdrs” directory.
These files are in binary format and consist of a file header followed by
the encoded G-CDR records.
Automated Accounting Record Transfer

An automated transfer of G-CDRs stored on the active CMC to the
CGF server without manual interventions is supported. The transfer of
G-CDRs is triggered based on the configuration. Additional flexibility is
also provided to allow operators to provision a time window for the G-
CDR transfer or set the transfer to be always enabled.
By default, automated G-CDR transfer is disabled. If it is enabled, the

operator has the option of selecting a transfer time frame by setting a
start and stop time for the G-CDR transfer or set the transfer to
“Always On”. If the transfer window is selected by configuring the start/
stop time, the transfer of G-CDRs stored on the GGSN hard disk is
initiated at the configured start time. Once the stop time is reached, the
G-CDR file being transferred will continue until completion but no new
files will be transferred.
The configured stop time cannot be same as the configured start time.
If the configured stop time is less than the configured start time, the
transfer will be stopped on the next day at the configured stop time.
The operator can also always enable the feature instead of specifying
a transfer time frame. This enables the G-CDRs transfer to be initiated
at any time. If the CGF is accessible and if the GGSN overload
conditions are satisfied, any G-CDRs stored on the hard disk are
immediately transferred to the CGF.

The automated G-CDR transfer is stopped if the CGF is not available

at the time of transfer. When the CGF becomes available during the
transfer window, the transfer resumes until the configured stop time. If
the feature configuration is set to “Always On”, the transfer resumes
and continues as long as the CGF is available and there are G-CDRs
on the hard disk.
In order to transfer the G-CDRs to the CGF efficiently without

overloading the GGSN, the G-CDR transfer monitors the GGSN
overload condition. The automated transfer is disabled if the CPU
overload level is 1 or above and re-enabled only when the CPU
overload level is back to NORMAL.
Interaction with Manual G-CDR Transfer

The following table explains the interaction between the automated
transfer and the existing CLI command used for initiating the G-CDR
transfer.
Table 3-6
Interaction between automatic and manual G-CDR transfer
Automated G-CDR Trigger(s) Action

G-CDR Transfer
Transfer Status
Setting
Disabled No transfer in CLI command “gtpbill Start transfer of G-CDRs from disk
progress disksend allow”
CLI command “gtpbill No change in transfer status

disksend off”
Transfer in CLI command “gtpbill No change in transfer status

progress due disksend allow”
to CLI
command CLI command “gtpbill Stop transfer of G-CDRs from disk
disksend off”
Enabled with Any state CLI command “gtpbill Disallowed with a CLI error message
“Always On” disksend allow” or
set “gtpbill disksend off”
—sheet 1 of 2—

Table 3-6
Interaction between automatic and manual G-CDR transfer (continued)
Automated G-CDR Trigger(s) Action

G-CDR Transfer
Transfer Status
Setting
Enabled with No transfer in CLI command “gtpbill Start transfer of G-CDRs from disk
a configured progress disksend allow”
start & stop
time CLI command “gtpbill No change in transfer status
disksend off”
Transfer in CLI command “gtpbill Disallowed with a CLI error message

due to start CLI command “gtpbill Stop transfer of G-CDRs from disk.
time trigger disksend off” Auto transfer will re-attempt at the
configured start time
Stop time trigger Stop transfer of G-CDRs after the

current G-CDR file transfer is
completed
Transfer in CLI command “gtpbill No change in transfer status

due to CLI CLI command “gtpbill Stop transfer of G-CDR from disk.
command disksend off” Auto transfer will be attempted at the
configured start time.
Start time trigger Manual transfer will continue. Auto

transfer will re-attempt at the next
configured start time.
Stop time trigger Ignored as the transfer was triggered

manually.
—sheet 2 of 2—
Interaction with FTP Pull Billing

FTP Pull Billing is used to transfer the billing files containing the G-
CDRs if no CGF server is configured on the CGF profile. The
automated G-CDR transfer cannot be enabled if a CGF server is not
provisioned in the CGF profile.

Interaction with G-CDR Auditing

If G-CDR Auditing is enabled on the GGSN, the G-CDRs generated
are audited and the audit files are stored on the disk. The audit files
stored on the disk can be FTP’ed to another node at a configured time
of day.
It is recommended that the configured FTP start time for G-CDR audit
files should not fall between the configured start and stop time for
automated G-CDR transfer. This is to avoid any potential CPU
overload conditions due to the FTP of a large number of G-CDR audit
files.
G-CDR Auditing
G-CDR Auditing can be enabled per GGSN device. Each accounting
record (CDR) generated on the GGSN results in an audit entry in the
CDR audit file if G-CDR Auditing is enabled. This audit entry indicates
whether the CDR produced is valid or incomplete. The audit entries
are first stored in RAM buffer and flushed to CDR audit files when the
contents of the buffer has reached 1 MB in size or has been open for
more than 1 hour. An audit file is not generated if there have not been
any CDRs audited during the 1 hour duration. The files are stored on
disk and may be transferred by FTP to another node on the network at
a time specified by the operator. Once the file has been successfully
transferred by FTP, it is deleted.
A log is generated in the “/log/EVENT” file when the G-CDR Auditing

or the FTP function is enabled or disabled.
Audit file description

The audit files created are written to the “/disk/acct/gtp/audit” directory.
These are ASCII files and generated in a Comma Separated Value
(CSV) format.
Audit file names are of the form DDMHHmm[A-Z].xxF where:

• DDMHHmm is the time that the auditing buffer was first opened,
specified as day of the month, month in hexadecimal (1-9, Oct = A,
Nov = B, Dec = C), hour, and minute
• [A-Z] is the file series letter within files of same day, month, hour,
minute
• .xxF is the file extension consisting of the ISP ID followed by the
letter F (for example, .01F)

Auditing file contents

The following fields are placed in the header of the file. Each one of
these fields is separated by a comma and the end of the header contains
a new line character.
1. GGSN Node ID - This field contains the GGSN Gn ISP address in
the format xxx.xxx.xxx.xxx, where x is in the range 0 -9.
2. GGSN Restarted - This field contains a “Y” if this is the first audit
file created after the reboot of the GGSN. If this is not the first file
after the reboot of the GGSN, this field contains an “N”.
3. Audit file open timestamp - This field contains the timestamp of
when the audit file was opened. The format of the field is YYYY/
MM/DD hh:mm:ss, where YYYY is the four digit year, MM is the
month (1-12), DD is the day (1-31), hh is the hour (0-23), mm is the
minute (0-59), and ss is the second (0-59).
4. Audit file closing timestamp - This field contains the timestamp of
when the audit file was closed. The format of the field is YYYY/MM/
DD hh:mm:ss, where YYYY is the four digit year, MM is the month
(1-12), DD is the day (1-31), hh is the hour (0-23), mm is the minute
(0-59), and ss is the second (0-59).
5. Number of CDRs - This field contains the number of CDRs audited
in this file. The range of this value is 1 - 32767.
6. CDR Type - This field identifies the type of CDRs. The value in this
field is “G-CDR”.
7. Audit Template Version - This field contains the version number of
the auditing template used to audit the CDRs listed in this audit file.
The template version is1.
The following is an example of the file header:
192.104.98.167,Y,1970/01/09 05:55:22,1970/01/09 05:56:40,5,G-

CDR,1
The following fields are repeated for each CDR audit entry. Each one
of these fields are separated by a comma and a new line character is
appended at the end of each audit entry.
1. CDR opening time stamp - This field contains the timestamp of

when the CDR was opened. The format of the field is YYYY/MM/
DD hh:mm:ss, where YYYY is the four digit year, MM is the month
(1-12), DD is the day (1-31), hh is the hour (0-23), mm is the minute
(0-59), and ss is the second (0-59).
2. Served IMSI - This field contains the unique International Mobile
Subscriber Identify allocated to the mobile subscriber. The

maximum length of an IMSI is 15 digits, each digit is in the range of

0-9.
3. Nature of Address - This field indicates the international number.
The value is one digit in the range of 0-7.
4. Numbering Plan Indicator - Indicates numbering plan used for the
MSISDN. The value can be up to two digits in the range of 0 -15.
5. Served MSISDN - This is the MS international ISDN number for the
subscriber. This value is at most 16 digits long, each digit in the
rage of 0 -9.
6. Local Record Sequence Number - This field contains the local
record sequence number for the CDR being audited. The range of
this value is 1 - 2147483647.
7. Charging ID - This field contains the Charging ID created for the
CDR being audited. The range of this value is 1 - 2147483647.
8. Duration - This field contains the duration of the session being
audited in seconds. The range of this value is 1 - 2147483647.
9. Sequence Number - If the CDR audited is generated as a partial
record, this field contains a value in the range 1 - 2147483647 or 0
when this is not a partial record.
10. Valid CDR - This field contains a “Y” if the CDR was successfully
encoded or a, “N” if there were difficulties encoding the CDR.
The following is an example of CDR audit entry:
,70/01/09
05:55:18,012345678901234,1,1,012345678901234567,235,70,4,0,Y
FTP function
If the FTP function is enabled, the auditing files will be transferred by
FTP to another node on the network at the time specified by the
operator. The standard FTP port of 21 is used and it is assumed that
the user is placed in the appropriate directory upon login to the node.
When transferring CDR audit files, all FTP activity originates from the
management interface (default ISP).
Two FTP servers can be provisioned to transfer the files, a primary

and a secondary. The GGSN tries to contact the primary server first
and begins transferring files at the provisioned time. If the GGSN
cannot establish the connection with the primary server, the secondary
server is used for the connection setup. If both servers are
unavailable, the auditing files remain on the disk.

When an FTP server is unavailable, an SNMP trap is sent to notify the

operator. Once the file has been successfully transferred, it is deleted
from the disk. If the FTP function is not enabled, the operator is
expected to manually move the files to another storage location.
Attention: If the system time on the GGSN is changed, the FTP

time will synchronize with the time change after the timer
associated with the start time expires and gets restarted.

RADIUS Accounting 3
The GGSN supports RADIUS Accounting on the Gi interface. RADIUS
Accounting provides connection ISPs with the billing capability of
wireless data services. RADIUS Accounting can be enabled on a per
APN basis through the SCS GUI. GTP Accounting and RADIUS
Accounting can be enabled for an APN in the same time. RADIUS
Interim Accounting records are generated when “Enable RADIUS
Interim Messages” is enabled on the APN. An alternate RADIUS
Interim Accounting time limit is present which is independent of GTP
Partial billing time limit. This option can also be used to enable/disable
the generation of radius interim accounting for roamers.
The RADIUS Accounting on the GGSN is based on the standard RFC

2866, “RADIUS Accounting”. The GGSN acts as a Network Access
Server (NAS) and is responsible for passing subscriber accounting
information to a designated RADIUS Accounting Server. Refer to
Nortel GGSN RADIUS Interface Guide (411-5221-928) for a list of
RADIUS attributes that the GGSN supports.
The GGSN also supports RADIUS Accounting Session mode for IP

PDU type. In Session Mode, the RADIUS Server is notified with
RADIUS Accounting START message containing subscriber’s
MSISDN and IP address before the PDP context is set up. A RADIUS
Accounting START response is sent from the RADIUS Server to the
GGSN upon receipt of the START message. In session mode, if no
response is received by the GGSN within a configurable time period,
the PDP session creation is rejected. The failure cause type is “User
Authentication Failed”.
For a non-authenticated subscriber, when a Create PDP Context

Request message is received without the PCO optional IE, the GGSN
does not send the User-Name attribute in the Radius Accounting
Messages.
If an APN’s ISP is not reachable (the operational state is DOWN), the

uplink and downlink data packet volume is not billed for RADIUS
Accounting.
The RADIUS Accounting protocol on the GGSN includes the following

functions:
• To activate the connection between GGSN and RADIUS Server, a
RADIUS ACCOUNTING-OFF followed by a RADIUS
ACCOUNTING-ON message is sent to all RADIUS Servers in the
RADIUS profile during the system restart or when the RADIUS
Profile is newly associated with an access group or a new server is
added to the RADIUS Profile which previously has been

associated with an access group. The RADIUS ACCOUNTING-ON

is sent even if no response is received for the RADIUS
ACCOUNTING-OFF message. The RADIUS START/INTERIM-
UPDATE/STOP messages are sent to the RADIUS Server even if
the GGSN failed to get any response for the RADIUS
ACCOUNTING-ON message. It is not mandatory to support
RADIUS ACCOUNTING-ON/OFF messages per RFC 2866,
RADIUS Accounting.
• At the beginning of the PDP Session, a RADIUS Accounting
START message describing the subscriber and the type of service
is sent to the RADIUS Accounting Server. The RADIUS Accounting
Server replies with an acknowledgement. For session mode, the
GGSN waits for the acknowledgement before sending a create
response to the SGSN.
• At the end of the PDP Session, the GGSN generates a RADIUS
Accounting STOP message describing the type of service that was
delivered and the statistics information such as session duration,
uplink and downlink octets, uplink and downlink packets. The
STOP message is sent to the RADIUS Accounting Server, which
sends back an acknowledgement.
• A RADIUS INTERIM-UPDATE message is optionally generated
when
— the time limit or data volume limit is reached
— a QoS change occurs and option QoS Change Partial Billing is
enabled in the APN Group Accounting/Billing tab
— a RAT change occurs and option RAT Change Partial Billing is
enabled in the APN Group Accounting/Billing tab
— the SGSN address changes and option SGSN Change Partial
Billing is enabled in the APN Group Accounting/Billing tab
— a fallback/fallforward occurs when the SGSN address changes
and option SGSN Change Partial Billing is enabled in the APN
Group Accounting/Billing tab
Or it may be generated at a consistent time interval. The time limit
and the data volume limit are configured through the SCS GUI in
the APN profile and the GTP tunnel. If the partial billing for roamers
is enabled, the time limit and data volume limit configured in the
GTP tunnel are used when subscriber activates a PDP session in a
VPLMN or roams to a VPLMN. Configuring “Fixed Billing Interval”
for APN Group enables the messages generated at a consistent
time interval. RADIUS Accounting supports only cumulative totals
in its interim billing messages and never generates partial records.

• Configurable Radius Interim Messages: This functionality provides

the flexibility to send/not send Interim Radius accounting records
on a per APN basis. Upon enabling “Radius Interim Accounting” on
the APN, Radius interim accounting messages are generated
based on the settings specified in the Accounting/Billing tab of the
APN group profile on the SCS GUI. The options allows a
configurable Radius Interim Billing TIME LIMIT independent of
GTP billing when Radius Interim Accounting is enabled on the
APN.
When “Radius Interim Accounting” is disabled on an APN, Radius
interim accounting messages are never generated for that APN.
• A RADIUS INTERIM-UPDATE message is also optionally

generated when the partial billing for roamers is enabled and the
subscriber roams into a VPLMN or roams back to the HPLMN.
• When RADIUS Accounting is enabled on the GGSN, the
Application Profile is not required for the WAP service. The
Application Profile is ignored if it does exist. The RADIUS
Accounting messaging serves the purpose of starting and stopping
the WAP service. The RADIUS Accounting Server must simply be
configured to forward the accounting messages to the Application
Server. If RADIUS Accounting is not enabled, then the Application
Profile is used as normal.
• A RADIUS INTERIM-UPDATE message is generated when the
Radio Access Technology (RAT) Type changes. The Update PDP
Context Request may cause RAT Type change.
• A RADIUS INTERIM-UPDATE message is optionally generated
when there is a match made from a set of IMSI rules and 1) the
time limit is reached, or 2) the data volume limit is reached for the
PDP sessions. The time limit and the volume limit are provisioned
on the IMSI billing profile.
• An “Alternate Radius Interim Accounting Time Limit” field is added
to the Accounting/Billing tab of the APN profile, IMSI billing profile,
and the SGSN Mapping tab of GTP Tunnel. If the alternate Radius
Interim Accounting Time Limit on the APN is enabled, then the time
value will be selected from one of these three values depending
upon which profiles apply to the particular mobile subscriber.
If fixed billing interval is disabled on the APN and if a partial G-CDR
is generated due to any other reason other than “APN Time Limit”,
then the G-CDR timer and radius interim billing timer will get reset.
The following table lists examples to show how the “Alternate

Radius Interim Accounting Time Limit” value on the APN profile,

IMSI profile and GTP tunnel profile interact to determine the active
interim time value for RADIUS accounting.
Table 3-7
Alternate Radius Interim Accounting Time Limit examples
Apn profile IMSI profile Billing for Resultin Comments

(Radius Accounting is enabled) roamers g value
(GTP Tunnel) used for
RADIUS
Enable Enable Alternat Time Alternat Time Alternate Time
Interim
Radius Alternate e Radius Limit e Limit Radius Limit
Time
Interim Radius Interim (Default Radius Interim
Billing
Limit
Message Interim Acct. Interim Acct.
s Acct. Time Details) Acct. Time
checkbo Time Limit Time Limit
x limit Limit
selected unselected greyed out 60 IMSI profile is not partial billing for 60 APN value is used
associated with the roamers is not since IMSI &
selected selected 100 60 100
APN profile or enabled or mobile is Roamer do not
selected selected 0 60 mobile does not not a roamer 0* apply.
match profile.
selected unselected greyed out 60 IMSI profile is not 40 20 20 APN default value
associated with the is overridden by
APN profile or Roamer default
mobile does not time limit. Alt. time
match profile is disabled on
APN so it is
ignored from the
roamer profile.
selected selected 0 60 40 20 40 Roamer alt. value

is used because
selected selected 100 60 0 20 0*
alt. time is
enabled.
selected unselected greyed out 60 30 10 40 20 10 APN default time

value is
overridden by the
IMSI time limit. Alt.
time is disabled on
APN and thus
ignored.
selected selected 100 60 30 10 0 20 30 IMSI alt. time

value is used
selected selected 100 60 0 10 40 20 0* because alt. time
is enabled on the
APN.
* 0 means there will be no Radius Interim Accounting Records generated due to time limit.
RADIUS Accounting record storage

The RADIUS Accounting STOP messages are written to the local disk
in the case of connection loss with the RADIUS Server. The message
is first resent to alternate servers up to a configurable maximum

number of retries. After the maximum number of retries, the record

data is written to the local disk. Once a RADIUS Profile is determined
to be out of contact with the GGSN, the STOP messages for that
profile are written straight to disk. The GGSN continuously attempts to
reestablish contact with the servers in the profile. If the local disk is full,
then no more messages are written to local disk until the condition is
remedied.
For any RADIUS Accounting records that are sent to the local disk, the
GGSN first places the records in a RAM buffer which is flushed to disk
each time the buffer is filled, or when contact is reestablished. Since
the records are initially stored in RAM, there may be a loss of data if
the GGSN is rebooted or suffers a power loss prior to flushing the
RAM buffer to disk.
For any RADIUS Accounting records that are sent to the local disk, the
GGSN first places the records in a RAM buffer which is flushed to disk
each time the buffer is filled, or when contact is reestablished. Since
the records are initially stored in RAM, there may be a loss of data if
the GGSN is rebooted or suffers a power loss prior to flushing the
RAM buffer to disk.
This feature can optionally be turned off from the SCS Console. With
the “RADIUS Disk Write” option, the APN can be configured to either
write or not write records to the disk in the case of connection loss.
Once communication with the RADIUS Server is re-established, the

GGSN begins to automatically transfer stored data from the local disk
to the RADIUS Server. This process is initiated only if the CMC P0
CPU Occupancy is below 64%. The transfer is done smoothly so as
not to flood the RADIUS Server. For every ten real-time accounting
messages sent, from an APN with “RADIUS Disk Write” enabled, one
message from the local disk is also sent to the RADIUS Server until all
data on the local disk has been transferred. The message records will
be removed from the local disk after they have been sent and
acknowledged. If “RADIUS Disk Write” is not enabled, for an APN, that
APN’s RADIUS message will not impact or trigger the read from disk
functionality.
The naming convention of the RADIUS Accounting file is

<MDDsssss.nn<state>
where:
• M is the month (1-9, Oct = A, Nov = B, Dec = C)
• DD is the day (1-31)

• s is file series letter within files of the same day (A-Z)

• nn is the RADIUS Profile ID
• state is a character that indicates the current state of the file
The state of the file can be either “U” which represents a closed
unprocessed file or “W” which represents a open file that is not yet
closed.
For example, if a RADIUS Accounting file is created at 10:43 am on

24th of September and it is the first file generated that day with
RADIUS Profile ID 02, then the filename would be “924AAAAA.02W”.
After the file is full, it would be renamed to 924AAAAA.02U. The next
file created that day would be 924AAAAB.02W, and once it is full or
closed for some other reason, it would be renamed to 924AAAAB.02U,
and so forth.
Fault Tolerant Billing 3

Fault Tolerant Billing allows a frequent internal updating of the SSP
information to the CMC without the generation of partial billing records.
It transfers the information more frequently to the CMC to reduce the
amount of information that may be lost due to SSP failure.
Fault Tolerant Billing provides the ability to configure billing intervals.

The intervals can be configured using the SCS GUI GTP Tunnel Device
Configuration dialog box on the Gn-ISP. There are two options to
configure the billing intervals:
• Fault Tolerant Billing Time Limit: the Time Limit interval has a range
from 5-60 minutes. By default the SSC Billing Resilience timer is
not running and the timer value is set to 0.
• Fault Tolerant Billing Volume Limit: The volume limit interval has a
range from 15-5000 K Bytes. By default the SSC Billing Resilience
Volume limit is not set and the Volume limit value is set to 0.
If both time and volume limits are configured, the update is performed
based on whichever limit is hit first. The feature is disabled by default
and if the intervals configured exceed the partial billing intervals.
Content Based Billing 3

Content Based Billing allows different rates to be applied to data
streams depending on the point of origination or destination of the
data. Many different rates may be applied to bytes sent to or received
from different configured sites. Specification of sites that receive
special rates and the rate they receive is configured through the SCS
GUI. This is done by specifying an IP address (or an IP address

range), a service (such as layer 4 protocol and port number), URL or a

combination of these.
Content Based Billing is implemented as an IP service. Filtering

criteria defined through the SCS GUI are used to select flows in the
uplink and downlink directions which receive special rates. These
special rate counts are reported in the record extension field of the G-
CDR if GTP Accounting is used. If RADIUS Accounting is used, the
counts are passed in a Vendor Specific Attribute. The Billing System is
responsible for the special rates calculation using the counts passed
from the GGSN.
Time based Content Based Billing is supported. The usage time is

applied to per content type instead of per flow. The usage time for a
content type is defined as the total time a mobile subscriber is actively
sending/receiving data (uplink and/or downlink) using a specific
content type. In the case where the same content type ID is assigned
to multiple applications (HTTP, FTP, WAP, etc.), all uplink/downlink
data traffic is counted against the same “usage time” which is tracking
the content type. If persistent HTTP connection is used, the usage
time counts the activity time for the same connection regardless of the
number of GET/POST commands used within the connection.
Partial billing for roamers 3

Partial billing for roamers provides the GGSN with a configurable
option to specify the periodic billing interval (time, volume, or both time
and volume) for outbound roaming subscribers. This interval can be
used to create billing records on a more frequent basis, which limits
the service provider’s exposure to loss of outbound roamer billing
records if the GGSN goes out of service. This is not an issue for
HPLMN customers in that both the home SGSN and the GGSN collect
billing information. The periodic billing interval is used for the PDP
context activation in a VPLMN or from the point where a subscriber
roams into a VPLMN during the PDP context modification.
The roaming status of a mobile subscriber can be determined based

on the MCC/MNC information contained in the RAI IE or Private
Extension IE. In case the RAI IE and Private Extension IE are not
received, the SGSN Address for Signaling IE presented in the Create
and Update PDP Context Request messages is used. It should be
noted that, in the case where both the RAI and the Private Extension
IE are received in a request message, the information from the Private
Extension IE is used. The GGSN then performs a lookup to match the
MCC/MNC or SGSN address against the corresponding information
provisioned on the GTP tunnel. The MCC/MNC information is checked
first. If there is no match, the PDP session is considered an outbound

roamer and the provisioned periodic billing interval for roamers is

applied.
Partial billing for roamers is applied to both GTP Accounting and

RADIUS Accounting. It can be enabled/disabled through the SCS GUI.
The alternate RADIUS interim accounting time limit is provisioned for
enabling or disabling the generation of radius interim records for the
roaming subscribers. The subscribers’ roaming status is determined
when the Create PDP Context Request message is processed and is
kept throughout the entire PDP session. Also, provisioning changes in
the SCS GUI after the PDP session is established do not take effect
unless there is a roaming status change upon receipt of an Update
PDP Context Request message.
Tunneling on the Gi interface 3

Tunneling on the Gi interface is supported to facilitate corporate
access for mobile subscribers to their private intranet. This access
type provides more security for the subscribers’ data traffic.
The GGSN supports the following types of outbound tunneling and/or

connection on the Gi interface:
• L2TP tunnel
• L2TP over IPSec tunnel
• IPSec tunnel
• GRE tunnel
• VLAN tagging
• MPLS
• ATM VC
GTP-L2TP tunnel switching

For the L2TP VPN model, both IP and PPP PDU types are supported.
L2TP over IPSec is optional in this case and is configurable through
SCS. No user authentication or IP address allocation is done on the
GGSN.
Tunnel switching for PPP PDU

For PPP PDU type, the PPP session is passed through transparently
between the mobile and the far end intranet. In this case, a L2TP
tunnel is set up to carry the PPP session to the L2TP Network Server
(LNS).
Once the GTP tunnel is set up, LCP negotiation is performed between
the MS and the GGSN. At the LCP user authentication stage, the

GGSN checks if outbound tunneling is required for this subscriber. If

L2TP is provisioned as the outbound tunneling protocol for the
subscriber or the L2TP outbound tunneling attributes are returned
from the RADIUS Server, the L2TP tunnel and L2TP session are set
up between the GGSN and remote LNS. The user authentication is
then performed by the far end LNS. Finally, the IPCP negotiation takes
place between the MS and the LNS for IP address allocation.
Figure 3-18 “GTP tunnel setup in GTP-L2TP tunnel switching for PPP
PDU type” shows the message flow for the PPP session setup in the
GTP-L2TP tunnel switching scenario. One GTP tunnel is mapped to a
single L2TP session within the L2TP tunnel. Multiple L2TP sessions
can be set up within a L2TP tunnel.

Figure 3-18
GTP tunnel setup in GTP-L2TP tunnel switching for PPP PDU type
MS SGSN GGSN LNS

(PDP Type = PPP, APN, etc.)

(Protocol Configuration Options, etc.)
LCP Negotiation
*SCCRQ
*SCCRP
*SCCCN
*ZLB ACK
L2TP Tunnel established
ICRQ
ICRP
ICCN
L2TP Session established
LCP Authentication (if required)

IPCP Negotiation (including Address Allocation)
*Only required if the L2TP tunnel is not already established.
Tunnel switching for IP PDU

If a mobile does not support PPP PDU but still needs to access an
intranet through the L2TP, then the IP PDU received from the GTP
tunnel on the GGSN must be tunnelled out as a PPP PDU within the
L2TP tunnel. The GGSN acts as a L2TP Access Concentrator (LAC)
in this case.
When a Create PDP Context Request is received at the GGSN for the
IP PDU and the subscriber template associated to the APN has an

outbound tunnel configured or returned from the RADIUS Server, the

L2TP tunnel and L2TP session are set up from the GGSN to the LNS.
The authentication information within the PCO IE of the Create PDP
Context Request message and the default LCP options are proxied
over to the LNS.
Attention: The LCP options within the PCO IE are not proxied over
because these options are only applied to the PPP session
between the TE and MS. GGSN and LNS can negotiate a new set
of LCP options. Also, when authentication is applied, the
information in the Access-Accept message from the RADIUS
Server is not propagated into the PCO IE of Create PDP Context
Response message.
If the LNS does not agree with the default LCP options or is configured
for the LCP re-negotiation, the LCP re-negotiation is performed
between the GGSN and the LNS. After the LCP negotiation,
authentication is conducted at the LNS.
It is required that primary and secondary Domain Name Server (DNS)

addresses and NetBIOS Name Server (NBNS) address are passed to
the mobile through the PCO IE of the response message when these
addresses are requested in the PCO IE of Create PDP Context
Request message. The addresses can be obtained from the IPCP
negotiation between the GGSN and the LNS.
If the mobile requests a dynamic PDP address, the LNS is responsible

for allocating the mobile address. The GGSN is informed of the
allocated address through IPCP negotiation. The allocated address is
included in the Create PDP Context Response sent to the SGSN.
The following diagram shows the message flow for setting up the GTP/
L2TP tunnel switching scenario for IP PDU with PAP.

Figure 3-19
GTP tunnel setup in GTP-L2TP tunnel switching for IP PDU type
MS SGSN GGSN LNS

(PDP Type = IP, Protocol Configuration Options, etc.)
*SCCRQ
*SCCRP
*SCCCN
*ZLB ACK
L2TP Tunnel established
ICRQ
ICRP
ICCN
with proxy LCP and
authentication info
L2TP Session established
LCP re-negotiation**
PAP auth request**
LCP auth result (=pass)

(carried within L2TP)
IPCP Negotiation
Create PDP Context Response (carried within L2TP)

(with allocated mobile address)
*Only required if the L2TP tunnel is not already established.

**Only required if LCP re-negotiation is performed from the LNS
L2TP secure PAP/ CHAP

The GGSN provides username and password security option for L2TP
outbound IP PDU sessions. If the authentication received in the PCO
is PAP, the username and password are not sent out in the ICCN
message while negotiating the initial L2TP session setup with the LNS.

The username and password are only sent after the LNS forces the
GGSN to negotiate authentication.
The L2TP secure authentication option can be turned ON/OFF

through the SCS GUI provisioning. Please refer to Figure 8-8
The GGSN can negotiate up to CHAP from PAP in the PCO. In other
words, if the LNS challenges the GGSN to provide CHAP
authentication information, the GGSN responds successfully to CHAP
challenges from the LNS by sending the username and password in
encrypted form. If the LNS wants to negotiate PAP, the GGSN sends
the required authentication information as clear text. This security
option applies to both static and dynamic L2TP tunnel setup.
When authentication requested in the PCO is CHAP, the GGSN

proxies the CHAP challenge and response from the PCO to the LNS in
the ICCN message. The authentication information is sent out in
encrypted form.

Outgoing to intranet using IPSec tunnel

For mobile subscribers accessing a private intranet, security could be
a very important factor. One way to achieve this security is to have a
secure IPSec tunnel between the GGSN and the private Intranet.
Tunneling to an Intranet with IPSec supports both IP and PPP PDU
types and the PPP session must be terminated on the GGSN.
There are two configurations where an IPSec tunnel can be established

between the GGSN and an Intranet.
• IPSec VPN
• GGSN VPRN
Dynamic Routing over IPSec is supported by allowing a GGSN to
participate in a dynamic routing protocol protected by IPsec with a
Contivity switch. Packets from networks discovered by the routing
protocol are tunneled over the IPsec tunnel with the Contivity. An
additional configuration parameter in the tunnel configuration to
indicate the tunnel can perform this function is required. Additionally,
the IKE Quick mode negotiation was modified to detect when a peer is
negotiating dynamic routing and to be able to initiate a tunnel for
dynamic routing. The data path will perform the encapsulation IP-in-IP
over IPsec Transport Mode. This is a proprietary feature negotiated
between the GGSN and Contivity switch.
Dead Peer Detection (DPD) keep alive mechanism as defined in [51]

is supported on Nortel GGSN. The behavior of non-wildcard IPsec
tunnels is changed, if DPD keep alive is enabled, as follows:
• Once an IPsec tunnel interface is created, it is left in the DOWN

state.
• If IKE is successfully established, the IPsec tunnel’s interface state
is changed to UP. Reachability information is installed in the routing
table.
• If both ends agree to run DPD keep alive and if the remote peer is
detected as dead, the IPsec tunnel’s interface state is changed
back to DOWN. Reachability information is removed from the
routing table.
IPSec VPN configuration

An IPSec tunnel can be configured as an access IPSec tunnel on the
Gi interface of the GGSN to access the private Intranet. An Access
Subscriber node representing the customer premises equipment
(CPE) associated with the IPSec tunnel is added for the VPN group.
When a GTP Create PDP Context Request is received for the
subscriber within the VPN group, data packets are routed to the Gi

interface through the IPSec tunnel that is associated with the Access
Subscriber node. The Access Subscriber node is provisioned as an
Access Subscriber that is associated to the IPSec tunnel in the VPN
group.
Figure 3-20 “IPSec VPN configuration” shows the IPSec access tunnel
between the GGSN and a remote CPE that is the gateway to the
private Intranet. The IPSec tunnel is point to point between the two
nodes.
Figure 3-20
IPSec VPN configuration
SCS
Server
Nortel
GGSN
Private
PLMN Intranet
IPSec Tunnel
CPE
Figure 3-21 “GTP-IPSec tunnel message flow” shows the message

flow for setting up a GTP tunnel with outgoing IPSec tunnel to the
remote private Intranet.

Figure 3-21
GTP-IPSec tunnel message flow
SGSN GGSN Intranet
IPSec Tunnel Established
IPSec tunnel is established

when configured by SCS
(PDP Type = IP/PPP, etc.)
PPP (LCP/Authentication/NCP negotiation) - for PPP PDU type ONLY
GGSN VPRN configuration

A Virtual Private Routing Network (VPRN) group can be created to
span an ISP to multiple GGSNs. This solution provides the added
functionality of IP address broadcasting between wireless Virtual
Private Network (VPN) groups. Multiple GGSN nodes can be added to
the VPRN group of the ISP for a point to multiple IPSec tunnels and
private Intranet access.
To support the link between GGSN VPRN and the private Intranet, an
access connection is configured as shown in Figure 3-22 “GGSN
VPRN to Intranet through access connection”. It can be optionally
configured as an IPSec tunnel as shown in Figure 3-23 “GGSN VPRN
to Intranet through IPSec tunnel” or an ATM 1483/R VC as shown in
Figure 3-24 “GGSN VPRN to Intranet through ATM 1483/R VC”. The
ATM VC connection does not have any tunneling associated with it
and can be configured without the VPRN on the GGSN for private
Intranet access.
The traffic from the Gn interface can be routed through an IPSec

tunnel from any GGSN in the VPRN to the one that has the access

connection to the private Intranet. From this GGSN node, the traffic is
forwarded to the CPE which is the gateway of the Intranet.
Attention: All GGSN nodes configured with the same VPRN group
need to run the same software release load in order to synchronize
with the SCS Server.
Figure 3-22
GGSN VPRN to Intranet through access connection
SCS
Server GGSN
IPSec Tunnel
Nortel CPE
IPSec Tunnel
GGSN Private
Intranet
PLMN
Access Connection
IPSec Tunnel
GGSN
Figure 3-23
GGSN VPRN to Intranet through IPSec tunnel
SCS
Server GGSN
IPSec Tunnel Private

Nortel Intranet
GGSN IPSec Tunnel
CPE
PLMN
IPSec Tunnel
GGSN IPSec Tunnel

Figure 3-24
GGSN VPRN to Intranet through ATM 1483/R VC
SCS
Server GGSN
Private
IPSec Tunnel Intranet
Nortel Router
GGSN IPSec Tunnel
PLMN ATM 1483/R VC
IPSec Tunnel ATM/
Frame Relay
GGSN Access Network
Outgoing to Internet and Intranet using GRE tunnel

GRE Wireless ISP model
The GRE wireless ISP model allows GRE tunnels to be set up using
access connections in the Wireless ISP model. This model does not
need to be associated with a VPN and all Wireless ISP services and
functions can be applied.
A GRE tunnel can be configured in the Access Group on the Gi

interface of Nortel GGSN to access the private Intranet and public
Internet. When a GTP data packet is received and the destination IP
address matches the reachability of GRE tunnel access subscriber,
this data packet is routed to the GRE tunnel associated with this
access subscriber. GRE over IPSec is not supported for the GRE
wireless ISP model.
Figure 3-25 “Wireless ISP GRE configuration” shows the GRE tunnels
between the GGSN and remote networks in the GRE wireless ISP
model. The GRE tunnel is point-to-point between two network nodes.

Figure 3-25
Wireless ISP GRE configuration
SCS
Server
GRE Tunnel Public
Internet
Nortel
GGSN
PLMN
GRE Tunnel
Private
Intranet
GRE VPN model

The GRE VPN provides a lightweight tunneling protocol for VPN
service. Where the use of IPSec is either not permitted or not required,
VPN functionality can be provided by GRE VPN. Tunneling to an
Intranet with GRE supports both IP and PPP PDU types and the PPP
session must be terminated on the GGSN. The GRE VPN
configuration allows a GRE tunnel to be established between the
GGSN and an Intranet.
A GRE tunnel can be configured as an access GRE tunnel on the Gi

interface of the GGSN to access the private Intranet. An Access
Subscriber node (CPE) associated with the GRE tunnel is added for
the VPN group. When a GTP Create PDP Context Request is received
for the subscriber within the VPN group, data packets are routed to the
Gi interface through the GRE tunnel which is associated with the
Access Subscriber node. The Access Subscriber node is provisioned
as an access subscriber which is associated with the GRE tunnel in
the VPN group. Encryption using IPSec is not supported for the GRE
VPN.
Figure 3-26 “GRE VPN configuration” shows the GRE tunnel between
the GGSN and a remote CPE which is the gateway to the private
Intranet. The GRE tunnel is point-to-point between two network nodes.

Figure 3-26
GRE VPN configuration
SCS
Server
Nortel
GGSN
Private
PLMN CPE
GRE Tunnel Intranet
Figure 3-27 “GTP-GRE tunnel message flow” shows the message flow
for setting up a GTP tunnel with outgoing GRE tunnel to the remote
private Intranet.

Figure 3-27
GTP-GRE tunnel message flow
SGSN GGSN Intranet
GRE Tunnel Established

GRE tunnel is established
when configured by SCS GUI
(PDP Type = IP/PPP, etc.)
PPP (LCP/Authentication/NCP negotiation) - for PPP PDU type ONLY
Outgoing to Internet and Intranet using VLAN Tagging

VLAN Tagging provides the logical differentiation of Ethernet frames
that share the same physical Ethernet connection.
VLAN Wireless ISP model

The VLAN wireless ISP model is configured in the Access Group on
the Gi interface and is not associated with any VPN. When a GTP data
packet is received on the GGSN and the destination IP address
matches the reachability of the VLAN tagging access subscriber, this
data packet is routed to the VLAN tagged access interface.
Configuring any IP service for the access subscriber is not supported
since it may degrade the traffic volume across the access subscriber.
Figure 3-28 “VLAN Wireless ISP configuration” shows the VLAN

tagging between the GGSN and remote Internet and Intranet.

Figure 3-28
VLAN Wireless ISP configuration
SCS
Server
Nortel
Private
GGSN
Intranet
PLMN CPE
VLAN tagged Router
Ethernet
Public
Internet
VLAN VPN model

VLAN tagging provides logical port fan out on the GGSN and is well
suited for VPN service. VLAN VPN supports both IP and PPP PDU
types; the PPP session is terminated on the GGSN.
A VLAN tagged access interface is configured on the Gi interface of

the GGSN. An Access Subscriber node (CPE) associated with the
VLAN tunnel is added for the VPN group. When a GTP Create PDP
Context Request is received for the subscriber within the VPN group,
data packets are routed to the Gi interface through the VLAN tagged
access interface which is associated with the Access Subscriber node.
The Access Subscriber node is provisioned as an access subscriber
which is associated with the VLAN tagged access interface.
Configuring any IP service for the access subscriber is not supported
since it may degrade the traffic volume across the access subscriber.
Figure 3-29 “VLAN VPN configuration” shows the VLAN tagging

between the GGSN and remote Intranet.

Figure 3-29
VLAN VPN configuration
SCS
Server
Nortel
Private
GGSN
Intranet
PLMN CPE
VLAN tagged Router
Ethernet
Outgoing to Intranet via MPLS

MPLS VPNs provide secured service to customers without using
underlying layer-2 overlays, or layer-3 tunnel-based approaches.
A site is made up of one or more networks which gain access to the

MPLS network by way of a Customer Edge router connected to a
Provider Edge (PE) router. Two sites connected to different PEs can
talk over the backbone only if they have at least one common network.
The common network becomes the VPN. A “Virtual Routing and
Forwarding” (VRF) instance is associated with each site. A one-to-one
relationship does not necessarily exist between customer sites and
VPNs; a given site can be a member of multiple VPNs. However, a site
can be associated with only one VRF on the Provider Edge Router.
Each VPN is associated with one or more VRFs. In the context of the
GGSN, a site is defined as a collection of subscribers sharing the
same set of VPNs.
Within the Gi MPLS Network, the GGSN will primarily serve as a PE,
also called a Label Edge Router (LER). See “MPLS VPN model” for
MPLS Network Architecture.
Functioning as a PE router, the GGSN has the following characteristics:

• The GGSN is attached to one or more CEs. In this case, a CE is a
logical entity which represents mobile subscribers belonging to a
particular VPN.
• The GGSN is “attached to a VPN” if it serves a mobile subscriber
that belongs to the VPN.

• The GGSN’s role as a PE is fully administrated by the provider.

• The GGSN runs (internal) BGP with other PEs.
If all sites in a VPN are owned by a single enterprise, then the VPN is
a corporate Intranet. If there exist sites that are owned by different
enterprises then the VPN is an Extranet. From the protocol point-of-
view there are no differences. The two scenarios are achieved by
explicit provisioning.
Figure 3-30
MPLS VPN configuration
SCS
Server
Nortel Private
GGSN
Intranet
PLMN CPE
MPLS
Backbone
Nortel GGSN also supports traffic engineered MPLS networks. In

order to achieve this objective, a support for RSVP-TE is added, as
defined in RFC 3209, as another Label Distribution protocol on the Gi
interfaces. The support of RSVP-TE as the signaling protocol allows
the creation of TE Tunnels which act as conduits to transport user
data. The mapping of customer traffic to these TE Tunnels is
accomplished by supporting service-provider configured Explicit FEC
(EFEC) Policies. These policies can be applied at (a) ISP level and (b)
at the subscriber template level. This flexibility in mapping customers’
traffic onto LSPs can provide greater service differentiation,
prioritization of traffic, and assist in accounting and billing. This
extension would allow subscriber traffic to be transported via Traffic
Engineered LSPs whenever they are available. In the absence of any
TE Tunnels, the GGSN will make use of any BE-LSPs to the same PE,
if they have been setup through the use of LDP-DU. Only MPLS VPN
traffic would be transported over LSPs on the Gi side. Also an impact

of this is the RSVP-TE is used as one of the signalling protocols on the

Gi side.

Quality of Service (QoS) 3

The GGSN Quality of Service features provide differentiated grades of
service within the core network on a per-subscriber basis. This
differentiation exists in both the uplink and downlink directions. GGSN
differentiation is achieved by marking the DiffServ CodePoint (DSCP)
of the Type of Service (TOS) byte in the IP packet header. The GGSN
supports the Differentiated Services Architecture as described in RFC
2474, “Definition of the Differentiated Services Field in the IPv4 and
IPv6 Headers”, RFC 2475, “An Architecture for Differentiated
Services” and RFC 2597, “Assured Forwarding PHB Group”. The
GGSN supports DiffServ on both GTP version 0 and GTP version 1.
For GTP version 1, the allocation/retention priority field and traffic

class are used to determine the priority level of the PDP context. The
allocation/retention priority and traffic class are delivered to the GGSN
in the Create PDP Context Request message. The UMTS QoS traffic
class is defined and explained in detail in 3GPP TS 23.107,version
4.6.0, “UMTS QoS Concept and Architecture”.
There are 12 possible combinations of allocation/retention and traffic

class, hence 12 differentiated levels of service are possible on the
GGSN. A Service Profile and a DSCP can be provisioned on the
GGSN for each combination of allocation/retention priority and traffic
class. The Service Profile identifies a DiffServ policy which marks
packets exiting the Gi interface and optionally additional IP services
which are applied to the data session. A DiffServ mark is also applied
to GTP packets exiting the Gn interface. This DiffServ mark is
provisioned via the GGSN QoS profile. The GGSN is also provisioned
with a control packet policy that determines the DSCP applied to all
control packets for a particular GTP tunnel.
For GTP version 0, the service level is defined by applying to the data
session a provisioned default Service Profile which contains a DiffServ
policy to mark packets exiting the Gi interface and optionally additional
IP services. A provisioned default DSCP is applied to GTP packets
exiting the Gn interface. These services are applied to all data packets
in both directions. GTP control packets may also be marked with
specific DSCP.
The GGSN supports the Expedited Forwarding (EF), Class Selector 7

(CS7), Class Selector 6 (CS6), Assured Forwarding (AF) and DEfault
Forwarding (DE) DSCP marking. The Class Selector 0 to 5 (CS0-CS5)
per hop behaviors are not supported on the Nortel GGSN.
Figure 3-31 “DSCP marking for the packets from Gi interface to Gn

interface” depicts the layer 3 bearer packet as is appears in the

network over the Gn interface. It also shows where the GGSN

performs the DSCP marking in the packet.
Figure 3-31
DSCP marking for the packets from Gi interface to Gn interface
TOS byte in IP header

GTP Bearer Packet
Payload IP GTP UDP IP
Marked based on DiffServ Marked based on GGSN

Marking IP service. QoS Profile information.
Mapping of DSCP marking to TOS value

GGSN Differentiated Service uses the recommended mappings of
DSCP to TOS value referenced in RFC 2474 and RFC 2597.
Table 3-8
Mapping of DSCP marking to TOS value
DSCP TOS Value
EF 10111000
CS7 11100000
CS6 11000000
AF43 10011000
AF42 10010000
AF41 10001000
AF33 01111000
AF32 01110000
AF31 01101000
AF23 01011000
AF22 01010000
AF21 01001000
—sheet 1 of 2—

Table 3-8
Mapping of DSCP marking to TOS value (continued)
DSCP TOS Value
AF13 00111000
AF12 00110000
AF11 00101000
DE 00000000
—sheet 2 of 2—
Uplink data packet QoS

The IP packets exiting the Gi interface are DiffServ marked if a
DiffServ policy is provisioned. A DiffServ policy is not required.
DiffServ policies are provisioned through the Service Policies menu of
the SCS. The various IP services applied to a subscriber PDP session,
including DiffServ marking, are collected into a Service Profile. A
Service Profile is a collection of individual policies. The GGSN QoS
profile selects one of twelve Service Profiles to apply to a subscriber
PDP session. Each APN on the GGSN can be associated with one
GGSN QoS profile. Associating an APN with a GGSN QoS profile is
optional.
Note that the Service Profile provisioned in the GGSN QoS Profile
takes precedence over a Service Profile or individual IP services
provisioned in the subscriber template for the APN.
When an Update PDP Context Request message is received which

modifies the allocation/retention and/or traffic class of a subscriber
PDP session, the QoS associated with the session is also modified.
When the Update PDP Context Request message arrives, the Service
Profile referenced in the QoS in the GGSN QoS Profile may also be
changed. The new Service Profile and its associated IP services,
including diffserv marking, are applied to the subscriber PDP context.
If a DiffServ policy is modified, the changes to the DiffServ policy are

applied to all existing subscriber PDP contexts using the DiffServ
policy. However, if a GGSN QoS profile is modified through the SCS
GUI, the changes are not applied to existing subscriber PDP contexts
using the GGSN QoS profile. In the GGSN QoS profile, if the DiffServ
policy associated with a Service Profile is deleted and added again
with different policy parameters, these changes are not applied to
existing subscriber PDP contexts using the GGSN QoS profile.
Existing subscriber PDP contexts continue with the values and

parameters that are configured at the time the subscriber PDP context
is created. Subscriber PDP contexts created after the GGSN QoS
profile is modified inherit the new values.
Downlink data packet QoS

All data packets from a subscriber PDP context that exit the Gn
interface are DiffServ marked based on provisioning in the GGSN QoS
profile. The only exception is the Error Indication Request packet. Note
that only the TOS byte in the outer IP header associated with the GTP
packet is marked. The TOS byte of the inner IP header for the user
packet is not marked. If it is desirable to mark the inner TOS byte, the
DiffServ Marking IP service can be used. Refer to Figure 3-31 “DSCP
marking for the packets from Gi interface to Gn interface” to
differentiate the inner and outer IP headers.
The DiffServ marking of the outer GTP IP header is provisioned in the

GGSN QoS profile. The mark applied to the packets of a given
subscriber PDP context is determined by the allocation/retention and
traffic class values of that context. Up to 12 different combinations of
allocation/retention and traffic class are possible; hence up to 12
different DiffServ marks can be provisioned. All packets associated
with a given subscriber PDP context receive the same DiffServ mark.
When an Update PDP Context Request message is received which

modifies the allocation/retention and/or traffic class of a subscriber
PDP session, the QoS associated with the session is also modified.
When the Update PDP Context Request message arrives, the new
DiffServ mark referenced by the new QoS in the GGSN QoS Profile is
applied to the GTP data packets of that context on the Gn interface.
If a GGSN QoS profile is modified through SCS, the changes are not
applied to existing subscriber PDP contexts using the GGSN QoS
profile. Existing subscriber PDP contexts continue with the values and
parameters which were configured at the time the subscriber PDP
context was created.
Control packet QoS

Control packets from GGSN to SGSN are also DiffServ marked,
however the method of provisioning this functionality is distinct. The
DSCP for GTP control packets is selected when the GTP tunnel is
provisioned via the GTP tunnel on the Access Properties menu. The
DSCP for GTP’ packets is selected when the GTP’ Profile is
provisioned on the Access Properties menu. Both the GTP control
packets and GTP’ packets used for accounting are marked with the
selected DSCP. When the control packet DSCP value is modified, the

QoS change is applied immediately to the GTP control packets and the
GTP’ packets associated with the GTP tunnel.
ATM L2 Service Classes

The ATM VC provides the logical differentiation of ATM connections
which share the same physical ATM trunk. The following service classes
are supported:
• Constant Bit Rate (CBR)
• Variable Bit Rate Real-Time (VBR-RT)
• Variable Bit Rate Non-Real-Time (VBR-NRT)
• Unspecified Bit Rate (UBR)
The following traffic shaping parameters are supported:

• Sustainable Cell Rate (SCR)
• Peak Cell Rate (PCR)
• Minimum Cell Rate (MCR)
• Maximum Burst Size in cells (MBS)
Table 3-9 shows the applicable combinations of the service classes

and the traffic shaping parameters. The ATM VC services are
determined by the setting of the traffic shaping parameters.
Table 3-9
Service Classes vs. Traffic Shaping parameters
Service Class/Traffic Shaping SCR PCR MCR MBS
CBR - X - -
VBR-RT X X - X
VBR-NRT X X - X
UBR - X X -
The ATM L2 service classes and the traffic shaping parameters for
each ATM service class will be stored in the traffic (shaping) profile via
SCS (Service Creation System) configuration.
Note that the ATM service class(es) and the traffic (shaping)
parameter(s) are applicable to the outgoing ATM trunk connections,
not for the incoming ATM trunk connections. (For the incoming traffic
on the ATM trunk connection, the data is manipulated using the VPI/
VCI mapping, not managed by the ATM service class or the traffic
parameters.)

GGSN Administration and Maintenance 3

There are a number of wireless specific monitoring/maintenance
functions provided on the GGSN for UMTS/GPRS services which are
detailed in the following sections.
Gi Interface Availability
Gi interface availability has the following capabilities:
• ISP Operational State monitoring
• APN Administrative State control
Gi Interface availability is determined on a per device basis. The

configuration and monitoring are in effect for one GGSN at a time.
ISP Operational State monitoring

A Connection ISP’s operational state is determined by monitoring the
trunk interfaces assigned to the ISP. It reflects the ability of the
Connection ISP to pass traffic on a given GGSN. It has the values UP
and DOWN.
A Connection ISP is assigned one or more Gi trunk interfaces. Each

trunk interface has its own operational state, reflecting whether it has
physically connected and is properly configured. To determine the ISP
operational state, the assigned trunk interfaces are checked. If at least
one is UP, the ISP is UP. If all of them are DOWN or none have been
assigned to the ISP, the ISP is DOWN.
When a Connection ISP is determined to be DOWN, an alarm is

generated. The alarm is applicable to a single GGSN. If the ISP spans
multiple GGSNs, each GGSN is alarmed individually.
If ISP Monitoring Redirect is enabled, then new Create PDP Context

Request messages for any APN assigned to the ISP are rejected
according to the Failure Response for Disallow set for the GTP Tunnel.
This could be no response or one of the cause values - No Resources
Available or System Failure. Additionally, for existing PDP contexts,
the volume based billing in uplink and downlink directions is not
accumulated for either GTP accounting or RADIUS accounting while
the ISP is DOWN. There is no impact on Update PDP Context
Request message handling.
If ISP Monitoring Redirect is not enabled, the processing of new

Create PDP Context Request messages and the billing of the existing
PDP contexts are not impacted.

When an ISP returns to the UP state, a clearing alarm is issued and

the handling of Create PDP Context Request messages and billing for
existing PDP contexts returns to normal.
APN Administrative State control

The APN administrative state is set by the operator. It reflects the
decision whether to permit the PDP context activation for an APN on a
specific device. It has the values UP and DOWN. When it is set to
DOWN, it prevents new PDP contexts from being activated on an APN
for a specific device, irrespective of the ISP Monitoring Redirect
setting. If the APN spans multiple devices, each must be configured
individually.
When an APN is set to DOWN from the SCS GUI, an INFO alarm is
generated. New Create PDP Context Request messages for the
specific APN are rejected according to the Redirect Response Cause
set for the GTP Tunnel. This could be no response or one of the cause
values - No Resources Available or System Failure.
When the APN is set to UP, a clearing alarm is generated. PDP

context activation returns to normal.
Gi interface state interaction

The ISP Operational State and APN Administrative State work
together as shown in Table 3-10.
Volume based billing is suspended when ISP Operational State is

DOWN and ISP Monitoring Redirect is enabled. The PDP contexts will
not be established:
• when APN Administration State is DOWN.
• when ISP Operational State is DOWN and ISP Monitoring Redirect
is enabled.

Table 3-10
ISP Operational State and APN Administrative State interaction
ISP APN ISP Operational Volume Based PDP Context

Monitoring Administration State Billing Creation
Redirect State
Enabled UP UP Enabled Enabled
DOWN Disabled for all Disabled for ALL

PDP contexts APNs associated with
associated with the ISP
the ISP
DOWN UP Enabled Disabled for the

specific APN
DOWN Disabled for all Disabled for ALL

PDP contexts APNs associated with
associated with the ISP
the ISP
Disabled UP UP Enabled Enabled
DOWN Enabled Enabled
DOWN UP Enabled Disabled for the

specific APN
DOWN Enabled Disabled for the

specific APN
Overload control
The GPRS/UMTS network can present more messages to a GGSN
over a given time than it is possible to process in that time. This
consumes resources, and processing work cannot be successfully
completed. This situation degrades overall performance of the GGSN
node. Overload controls permit the GGSN to maintain processing
throughput when the offered load exceeds the supported load.
Three levels of overload are defined for the GGSN. Each level of
overload control provides more aggressive control of access to the
GGSN than does the prior level. The entry and exit criteria for each
level are well defined. The following sections provide additional
description of the actions taken for each level of overload.

Overload controls can be divided into three areas:

• Monitor: Monitoring the status of critical resource(s). Three critical
resources are supported. They are CPU, interrupt, and memory.
The resource monitoring can be done on CMC P0, CMC P1, and
SSC.
• Detection: The detection of an overload condition. Detection has a
distinct entry point and exit point. The entry point is a value defining
that a specific level of overload has been reached. At that point,
one or more actions will be initiated to relieve the overload. The exit
point is a value defining when the system can safely exit the
overload state and terminate the actions that were triggered upon
entrance into overload.
• Action: This is the act that is taken as the system reaches
overload. Usually it includes notification via alarm mechanisms and
termination of some events which triggered the system to enter an
overload level.
GGSN behavior with and without the overload control mechanism is

illustrated in Figure 3-32 “GGSN overload control”.
Figure 3-32
GGSN overload control
System Output
with Overload Control Overload Entry Point
Serviced Input
System Output Overload Exit Point

without Overload Control
Time
The GGSN overload control functionality resides on processor 0 of the

active CMC card. An alarm is reported to the SCS Server once the
overload level criteria is reached. When the overload condition is
cleared, a notification is sent to the SCS Server to reset the overload
alarm. The criteria for entry and exit of an overload level have been
carefully designed to avoid oscillation between overload levels.

CPU overload control

Processor 0 of the CMC card is the most critical of all resources of the
system. This processor is monitored for CPU overload.
The overload control mechanism monitors the CPU occupancy and

informs the Gn interface as it enters overload condition. The Gn
interface takes action to alleviate some of the load on the processor.
Similarly, as the CPU exits the overload condition, it informs the Gn
interface of exit of overload. The Gn interface removes the action that
was applied for CPU overload control.
PDP Sessions that have reached a stable state are unaffected by

overload controls.
When in overload, the Gn interface responds to an incoming Create

PDP Context Request with a Create PDP Context Response which
indicates the session was not setup. The Cause IE of the response
message is configured using the SCS GUI in the GTP Tunnel
Configuration dialog box. The handling of a new PDP activation when
the CPU is overloaded is shown in Figure 3-33 “CPU overload control
message flow”.
Figure 3-33
CPU overload control message flow
GGSN SCS
SGSN
Monitor CPU
Occupancy
CPU0 Overloaded
Generate Alarm

(Cause = No Resources available)
Three levels of CPU overload are Level 1, Level 2 and Level 3.

Overload detection or entry criteria for any of the Levels is percentage

CPU Occupancy. The ‘Entry Hysteresis’ is the number of minutes the

‘Entry Threshold’ value has to hold before declaring a transition up
(entry) to this level. The ‘Exit Hysteresis’ is the number of minutes the
‘Exit Threshold’ value has to hold before declaring a transition down
(exit) from this level.
CPU overload levels are described in Table 3-11.

Table 3-11
CPU overload level descriptions
CPU Entry Exit Entry Exit Description

Overload Hysteresis Hysteresis Threshold Threshold
Level
Normal This is an informational log

which indicates that the
switch is normal and not
under overload conditions.
Level 1 3 6 75 73 This level is not service

affecting. When the
average CPU Occupancy
is above 75% this alarm is
raised after 3 minutes of
attaining 75% average
CPU Occupancy. This
overload condition is exited
after 6 minutes of attaining
73% average CPU
Occupancy. Any transitions
to other levels follow the
Entry Hysteresis and Exit
Hysteresis.
Level 2 3 6 85 83 When the average CPU

Occupancy is above 85%
this alarm is raised after 3
minutes of attaining 85%
average CPU Occupancy.
This overload condition is
exited after 6 minutes of
CPU Occupancy. Any
transitions to other levels
follow the Entry Hysteresis
and Exit Hysteresis.
—sheet 1 of 2—

Table 3-11
CPU overload level descriptions (continued)
CPU Entry Exit Entry Exit Description

Level
Level 3 3 6 90 88 When the average CPU

Occupancy is above 90%
minutes of attaining 90%
average CPU Occupancy.
CPU Occupancy. Any
—sheet 2 of 2—
If the GGSN Average CPU Occupancy is above 80% the GGSN stops
accepting new Create PDP Context Request. However the existing
sessions are not dropped.
Disk capacity overload control

The GGSN monitors available disk space on the CMC card. The disk
space used is compared against a set of threshold levels. When the
amount of disk space used reaches a threshold level, an alarm is raised.
Additional alarms are raised if available disk space decreases beyond
additional threshold levels. The frequency of disk capacity checking
depends on the severity of current overload level:
• Normal - Disk capacity checking occurs every 10 minutes.
• Overload Level 2 - Disk capacity checking occurs every 5 minutes.
• Overload Level 3 - Disk capacity checking occurs every 1 minute.
Memory overload control

Memory overload occurs when memory utilization reaches a threshold
level or when memory fragmentation begins to affect the operation of
the GGSN.
Memory resources enter an overload level when the following two

conditions are present for multiple consecutive evaluation cycles:
• The free processor system memory is below a defined number of
free megabytes.

• A free memory block of defined size (in kBytes) is not available in

the processor memory.
Memory resources exit an overload level when the following two

conditions are present for multiple consecutive evaluation cycles:
• The free processor system memory rises above a defined number
of free megabytes.
• A free memory block of defined size (in kBytes) is available in the
processor memory.
For a given overload level, the entry/exit thresholds are defined to be

not equal. The exit criteria is set more conservatively than the entry
criteria to provide hysteresis.
In a level 1 overload state, the GGSN continues with normal

processing of all incoming GTP messages that arrive at the Gn
interface. An alarm is raised to indicate that the first level of overload
has been reached.
In Level 2 and Level 3 overload states, additional alarms are

generated. Also, additional checks are performed on memory
availability. If the additional memory checks show insufficient memory
available, the Create PDP Context Request message is rejected with a
configured cause value.
Memory overload control never deletes existing PDP context sessions.
Figure 3-34 “Memory overload control message flow” shows the

message flow for memory overload control.

Figure 3-34
Memory overload control message flow
GGSN SCS
SGSN
Monitor System Memory
Occupancy
System Memory Overloaded
Create PDP Context Response Generate Alarm at LEVEL1

(Cause = Request Accepted)

Monitor System Memory
Occupancy
Generate Alarm at LEVEL2 or LEVEL3
Additional Memory Check

(Cause = No Resources Available)
Three levels of Memory overload are Level 1, Level 2 and Level 3.

Overload detection or entry criteria for any of the Levels is percentage
Memory Usage. The ‘Entry Hysteresis’ can be described as the
number of minutes the ‘Entry Threshold’ value has to hold before
declaring a transition up (entry) to this level. The ‘Exit Hysteresis’ can
be described as the number of minutes the ‘Exit Threshold’ value has
to hold before declaring a transition down (exit) from this level.
Memory overload levels are described in Table 3-12.

Table 3-12
Memory overload level descriptions
Memory Entry Exit Entry Exit Description

Level
Normal This is an informational log

which indicates that the
switch is normal and not
under memory overload
conditions.

Table 3-12
Memory overload level descriptions
Memory Entry Exit Entry Exit Description

Level
Level 1 4 8 100 free MB 110 free MB This level is not service

affecting. When the Free
Memory is below 100 MB
minutes of crossing 100
MB Memory. This overload
condition is exited after 8
minutes of crossing 110
Free MB memory. Any
Level 2 3 8 70 free MB 80 free MB When the Free Memory is

below 70 MB this alarm is
crossing 70 MB Memory.
crossing 80 Free MB
memory. Any transitions to
other levels follow the
Hysteresis.
Level 3 2 8 50 free MB 60 free MB When the Free Memory is

below 50 MB this alarm is
crossing 50 MB Memory.
crossing 60 Free MB
memory. Any transitions to
other levels follow the
Hysteresis.
If the GGSN Memory Usage is above 70% the GGSN stops accepting
new Create PDP Context Request. However, the existing sessions are
not dropped. Memory resources may also enter an overload level
when a free memory block of defined size (in kBytes) is not available
in the processor memory. Memory resources exit an overload level

when a free memory block of defined size (in kBytes) is available in

the processor memory.
Table 3-13 describes CMC Memory fragmentation block sizes.

Table 3-13
CMC memory fragmentation block sizes
Memory Entry Block Exit Block Description

Overload Size Size
Level
Level 1 512 kB 512 kB When the Free Memory Block is below 512 kB
this alarm is raised. This overload condition is
exited after the availability of the Free Memory
Block of 512 kB. Any transitions to other levels
follow the Entry Hysteresis and Exit
Hysteresis.
Hysteresis.

Hysteresis.
APN Blacklisting
The APN blacklist functionality provides protection to the system from
repeated PDP context activation failures for an individual APN and
enhances system performance.
This functionality monitors the number of consecutive PDP context

failures for each APN. If the PDP context failures for an APN exceeds
a configurable threshold, the APN is blacklisted for a configurable time
interval. A major alarm is raised and an event is logged when an APN
is blacklisted. The alarm is cleared once the APN is back in service.
If PDP context activations are rejected because of configured ACL,

APN session limits, APN marked administratively down, etc; those
PDP context activation failures will not count against the number of
consecutive failures required to activate the blacklisting functionality.
Also since current GGSN system overload functionality prevents PDP

context activations prior to APN based processing, memory and CPU

overload failures will not count towards the consecutive failures for
APN blacklisting. Additionally, PDP context activation failures due to V-
GGSN access control, access controlled via IMSI and maximum APN
subscriber limits exceeded will not count towards consecutive failures
for APN blacklisting.
During the blackout period all the PDP create requests will be rejected
with cause code as “No resource available”. Upon expiry of the
blackout period, the APN is unblocked and is returned to service. The
administrator can make a blacklisted APN available for service before
the blackout period expires via CLI command.
This functionality is OFF by default for all APNs. If the APN has been
manually disabled by the administrator, this functionality is inactive for
the specific APN on that GGSN.
Secure SCS network connections

Secure Socket Layer (SSL)
Secure Socket Layer enables SSL connections between SCS servers
and clients. SSL is provided with static certificate files. SSL can be
enabled or disabled, which affects all the SCS components on the
server.
While starting a server or client for SCS, a socket is initialized to

supply sockets and server sockets to that particular SCS process.
When SSL is used, the socket provided is identified as an SSL socket
and provides an added level of security for the connection based on
the cipher suite used.
The following SCS components have SSL connections between them:

• SCSClient and SCSDomainServer
• All SCS Servers and SCSDaemon
• SCSDomainSever and SCSRegionServers
• SCSMonitoringServer and SCSDomainServer
• SCSPullServer and SCSDomainServer
• SCSCorbaServer and SCSDomainServer
If the SCS Server is using SSL, the client should also use SSL to
connect to that SCS Server. It is the user’s responsibility to know
whether SCS servers are using SSL or not before connecting to a
server.

For information on SSL installation and certificate generation, refer to

GPRS/UMTS Nortel GGSN Provisioning Procedures (411-5221-927).
Secure Socket Shell (SSH)

Secure Shell (SSH) is a suite of network connectivity tools that
provides secure network services over an insecure network between
two untrusted hosts. These tools include a server, a couple of client
applications and some other basic utilities. One of the most recognized
benefits of using SSH is that all traffic including passwords is
encrypted. SSH is intended to be used instead of the Berkeley
services (for example, rlogin, rsh) to connect to a GGSN. A user will
see no differences between the SSH services and those it replaced.
The SSH daemon listens for connections from clients and spawns a
new daemon for each connection received. This new daemon handles
key exchange, encryption, authentication, command execution and
data exchange. Key exchange between the client and server employs
DSA (Digital Signature Algorithm) to identify the hosts. This key is
used to encrypt the all further communications during the session
using a symmetric cipher that the client selects from those offered by
the server. User authentication is performed using public key or
traditional password.
Secure shell works very similar to Secure Sockets Layer web

transactions. Both can set up encrypted channels using generic host
keys.
First, the client and the server exchange public host keys. If the client
machine has never encountered a given public key before, SSH asks
the user whether to accept the untrusted key. Next they use these to
negotiate a session key that is used to encrypt all subsequent session
data using a block cipher.
The client is then prompted for a standard username/password

combination. Finally after successful authentication the session proper
begins. A remote shell, a secure file transfer or a remote command is
begun over the encrypted tunnel.
Current implementation of SSH provides access to the GGSN from 20

simultaneous SSH Clients. SSH username and password must be
configured on the GGSN. RADIUS authentication of GGSN users who
are using SSH to log in is not supported.
Health Check Monitor (HCM)

The Health Check Monitor periodically monitors the health of the
system. It enables the operator to monitor the system and take
appropriate actions when the threshold is reached. For example, if

PDP contexts are not getting created, the Health Check Monitor
detects this condition and an alarm is generated to inform the operator.
This functionality also provides configurable alarm thresholds to the
administrator in case of specific network performance requirements.
Health Check Monitor alarms are not intended for the use of
calculation of outage time.
Three key parameters for measuring GGSN system stability are

monitored. The first parameter is the Nodal Activation success rate.
The second parameter is the Network Activation success rate. The
third parameter is used to track the number of PDP context activation
attempts. They are detailed in the following sections.
Nodal Activation success rate

The Nodal Activation success rate measures the percentage of Create
PDP Context Request messages, which result in a successful
activation excluding the effects of “normal failures” (e.g. non-service
affecting duplicate create requests, administratively disabled GTP
tunnels) and “abnormal network failures” outside the GGSN's control
(e.g. malformed packets, external user authentication failures.) As
such, the Nodal Activation success rate is the primary indicator of the
performance of the GGSN from a nodal perspective, by highlighting
conditions such as internal software errors and internal resource
shortages.
As the Nodal Activation success rate crosses the threshold value, a

critical alarm and event log are generated/cleared to inform the
operator of this condition. The Nodal Activation success rate threshold
value is configurable. For detailed threshold configuration information
and their value range, please refer to GUI Provisioning chapter.
Network Activation success rate

The Network Activation success rate measures the percentage of
Create PDP Context Request messages, which result in a successful
activation excluding the effects of “normal failures” (e.g. non-service
affecting duplicate create requests, administratively disabled GTP
tunnels) and “abnormal nodal failures” (e.g. out of memory, internal
user authorization failures.) As such, the Network Activation success
rate provides insight to the packet core network performance from the
perspective of the GGSN, by highlighting conditions such as
malformed packets, mis-provisioned APNs, RADIUS server issues,
and network overload.
As Network Activation success rate crosses the threshold value, a

critical alarm and event log are generated/cleared to inform the
operator of this condition. The Network Activation success rate

threshold value is configurable. For detailed threshold configuration

information and their value range, please refer to GUI Provisioning
chapter.
PDP context Activation Attempts

Health Check Monitor detects if system level PDP context activation
attempts have dropped to or below the threshold value. If the total
number of attempted PDP context activations is less than or equal to
the threshold value in the last two successive intervals, an information
alarm and event log are generated to inform the operator of this
condition. If the number of attempted PDP context activations raises
above the threshold value in an interval, the alarm is cleared.
The PDP context Activation Attempts threshold value is configurable.

For detailed threshold configuration information and their value range,
please refer to GUI Provisioning chapter.
Wireless services 3
The GGSN supports tariff services (real-time charging and GeoZone)
and WAP service. It interworks with the real-time charging server for
tariff services. It interworks with the WAP gateway or the Application
Server for WAP service.
Real-time charging server and Application Server addresses are

configurable through SCS GUI for a specific APN. For PDP contexts
that have tariff service, the specific service information is captured in
the G-CDR records and RADIUS Accounting messages. The CGF and
RADIUS Server are responsible for processing the services records
accordingly.
To enable the real-time charging service one of two real-time charging

protocols, Card Telephony Protocol (CTP) and Diameter Credit Control
(DCC), must be selected. If CTP is selected, one of two CTP versions
must be selected. This has to be done for each APN. Multiple real-time
charging protocols/versions can be used within a single ISP.
Real-time charging service

The real-time charging service allows subscribers to pay for services
such as PDP context time or packet volume in advance. As the
subscriber consumes the services, both the GGSN and the real-time
charging server keep track of resources used and the SCP deducts
charges from the subscriber’s account for the service being used. For
real-time charging service the G-CDR records and RADIUS messages
are captured for information only.

Two protocols, Card Telephony Protocol (CTP) and Diameter Credit

Control (DCC), are used for the communication between the GGSN
and the real-time charging server and DCC Server. Below is a general
description of real-time charging services. Please note that in this
description, the term “real-time charging server” is used generically to
represent the server used by CTP or the server used by DCC. See
“Card Telephony Protocol (CTP)” and “Diameter Credit Control (DCC)
protocol” for detailed information.
The Diameter Credit Control feature is disabled by default on the

GGSN. It can be enabled by a feature activation means. If the feature
is disabled, the GGSN does not process any DCC configuration
message from the SCS GUI or through the CORBA API and SCS will
be out of sync with session errors upon configuration of the DCC
profile(s). If the feature is enabled, the GGSN processes the
configuration message and the feature is available to use. If the
feature is disabled after having been enabled, the feature will be
available for already configured profiles until the box is resynched.
Both protocols use the concept of a coupon in order to allocate

resources for the subscriber. See “Content Based Billing” for
information about coupons as they apply real-time charging services.
The GGSN is responsible for session control. Once the subscriber’s

real-time charging service is authorized, it regulates the session
according to a usage coupon provided by the real-time charging
server. It ensures real-time charging subscribers are given service
only as authorized, that all usage information is provided to the real-
time charging server and the sessions are terminated when
appropriate.
The GGSN will check the length of the received packet against the
remaining granted volume quota resources prior to forwarding the
subscriber packets. If the packet's length fits within the remaining
quota, the GGSN will consume the volume from the granted resources
and forward the packet to/from the subscriber. However, if the packet's
length exceeds the remaining quota(i.e. over consume the granted
quota) then the GGSN triggers a quota exhaustion reauthorization and
discards the packet.
Initial authorization
When a Create PDP Context Request is received on the Nortel
GGSN, the Tariff Profile associated with the APN for the specific
device is retrieved if it is provisioned. This is how the GGSN identifies
the session as real-time charging. There are two different scenarios for
tunnel establishment for subscribers with real-time charging service.
Scenarios depend upon the PDU type of the PDP session.

If the PDP session is the IP PDU type, after mobile subscriber’s

authentication, the Nortel GGSN sends a real-time charging request
message to the real-time charging server to request the tariff (i.e. real-
time charging or GeoZone) information for the subscriber. The real-
time charging server checks the users account to verify that there are
sufficient funds available and if so, returns a coupon and a successful
response. When the GGSN receives the response indicating success,
the GTP tunnel is setup and data packets can be transferred. If the
real-time charging response from the real-time charging server
indicates failure, then the GTP tunnel will not be established. Also, if
subsequent real-time charging requests to extend the time/volume
limit for the real-time charging subscriber fail, the GTP tunnel is taken
down.
The following diagram shows the message flow for real-time charging
service supported for IP PDU type on the Nortel GGSN.
Figure 3-35
GGSN real-time charging service message flow for IP PDU type
SGSN GGSN real-time

charging

User authentication is done before
the GPRS Service Request.
Initial real-time charging Request

Initial real-time charging response
IP Address Allocation is done after

the GPRS Service Response.
To renew usage with real-time

charging server
Mid-call real-time charging request
Mid-call real-time charging response

If the PDP session is the PPP PDU type, the GTP tunnel needs to be
set up before the LCP negotiation for the PPP session. The real-time
charging service is involved after a successful PPP authentication.
This means the GTP tunnel is established before the Service Request
message is sent to real-time charging server. If the Service Response
indicates a success, the GTP tunnel will remain up and the subscriber
data transferred prior to receiving the successful Service Response
will be charged for. If the Service Response indicates a failure, the
GTP tunnel will be taken down. The volume count of the GTP
accounting and RADIUS accounting will be different from the real-time
charging service. This is because PPP LCP negotiation messages are
counted for GTP accounting and RADIUS accounting but not for real-
time charging service.
The following diagram show the message flow for real-time charging
service supported for PPP PDU type on Nortel GGSN.
Figure 3-36
GGSN real-time charging service message flow for PPP PDU type
SGSN GGSN Real-time charging server
PPP LCP/Authentication/IPCP negotiation
User Authentication and IP Ad-

dress Allocation are done before
the GPRS Service Request.
Initial real-time charging request

Initial real-time charging response
To renew usage with real-time
Mid-call real-time charging request
Mid-call real-time charging response

In both scenarios, from this point in the PDP session, the coupons will
be managed as needed with reauthorization requests until termination.
Mid-call reauthorization
The subscriber browses the web and uses resources associated with
the coupon (time or volume). The GGSN requests a new coupon once
the provisioned threshold value is reached, the real-time charging
server explicitly request the GGSN to reauthorize a coupon, or if a
provisioned trigger event occurs. In the request for a new coupon, the
GGSN reports the resources used since the last report. While the real-
time charging Server is processing the request, depending on
provisioning, the GGSN either allows data to flow or blocks data for the
rate identified by the coupon until the response is received.
If sufficient funds are available in the account, another service coupon

is issued and sent to the GGSN. In this case the PDP session is
extended. This re-authorization process continues as long as the data
traffic continues and there are sufficient funds in the subscriber’s
account.
Once the real-time charging server responds with a new coupon and
assuming the GGSN is provisioned to allow data to flow while waiting
for new coupons, the GGSN subtracts from the new coupon any
resources used while waiting for the response. Any residual resources
associated with the old coupon are discarded. If the real-time charging
server responds with a denial coupon, the GGSN immediately blocks
traffic or it tears down the PDP context associated with the denied
coupon. Any resources used while the request was outstanding are
reported in the final message to the real-time charging server.
The GGSN also has the capability to return coupons that have been
idle for a period of time. This may be triggered through provisioning or
from a request from the real-time charging server.
Call termination
Once the PDP session is terminated, the GGSN sends a final request
to the real-time charging server. This request contains an end of call
indication as well as the consumed resources in last segment. The
real-time charging service updates the subscriber’s balance based on
the consumed resources. The real-time charging server sends an
acknowledgement back to the GGSN.
Total resource usage reporting

If the Total option is enabled in CTPv3 and DCC profile, GGSN reports
the total resource usage for a coupon since the first use of coupon in
mid-call reauthorization and final request to the real-time charging
server. In case of tariff time change functionality, total resource usage

is reported separately for both of the coupons: before the tariff change
and after the tariff change.
Triggers
Real-time charging triggers provide a mechanism whereby the GGSN
executes two primary functions of the real-time charging service:
• Validate the subscriber’s request for services.
• Count the report consumed resources usage.
In CTP version 3 and DCC, the reauthorization threshold value is
configurable from 50% to 100% of the authorized resource. If the
resource is time, the above mechanism works the same way. The
threshold value is configurable per tariff profile or, for CTP version 3, it
can be returned as part of the coupon by the real-time charging server
which overrides any provisioned value on the GGSN.
Failure handling
If the real-time charging server is out of service, the proper SNMP trap
is generated to indicate the problem.
In general, if the initial or mid-call authorization requests to the real-

time charging server fail, the PDP session is taken down. The Cause
value in the Create PDP Context Response message is set to “User
Authentication Failed”. Please refer to the CTP or DCC technical
specifications for details.
CTP real-time charging versions

Card Telephony Protocol (CTP) protocol version 1 provides a simple
real-time charging service Basic Single-Coupon (see “Basic Single-
Coupon Prepaid Service”). CTP version 3 provides the Multi-Coupon
service (see “Multi-Coupon Prepaid Service”). Each version of the
real-time charging service relies on a corresponding version of the
CTP protocol to communicate with the real-time charging server.
Multiple coupon tracking (CTP version 3 and DCC)

CTP version 3 as well as Diameter Credit Control both support
multiple coupon tracking for a single PDP context through the use of
rated coupons. This enables a single PDP context to be charged at
different rates for different content. The initial request can ask the real-
time charging server to authorize a certain set of real-time charging
coupon rates by specifying the rate IDs in the request. The real-time
charging server authorizes a set of real-time charging coupon rates in
response to the initial request. These rates could be different from the
rates requested in the initial request. New coupons for new rate IDs
can also be requested throughout the duration of the PDP session. In
addition, coupons can specify volume and time as the resource

authorized. The real-time charging server is solely responsible for

managing coupon size and account balance. The GGSN makes no
attempt to distribute funds across coupons beyond its ability to return
idle coupons to the real-time charging server.
Non-rated coupon
CTP version 3 contains a non-rated coupon to take on the function of
single coupon billing. When this coupon is in use, all data packets in
the PDP session are counted against this coupon.
Diameter Credit Control does not support non-rated coupons.
Rated coupon
Rated coupon is similar to non-rated coupon except it specifies a
coupon rate ID. The coupon rate ID identifies the rated group of data
traffic that the resources authorized in the coupon will be applied to.
The coupon rate ID is specified and enabled using a CBB Service
Policy. At any point in time, a single PDP session can have zero to
many rated coupons. Each Rated Coupon transferred between the
GGSN and real-time charging server contains either usage or
authorization information for a single coupon rate. Multiple Rated
Coupons can exist in a single real-time charging request or response
message. Multi-rate coupons are not supported in the L2TP Network
Model.
With rated coupons, new coupon rates can be requested both during
initial authorization and once the context is established. Individual
coupons may be re-authorized or returned during a session by
including the rated coupon for each of the corresponding coupon rates
in a re-authorization message. The Rated Coupon includes the
resource usage for the coupon rate being re-authorized or returned. All
coupons including denied coupons that are held at the end of a
session are returned with a Rated Coupon that reports their individual
usage.
Because GGSN supports the ability to allow rated packets to pass

during authorization, it may include Rated Coupons at the end of a
session for coupon rates that were not explicitly authorized by the real-
time charging server even if the usage that reported is zero.
At any time during a PDP session, if the subscriber is attempting to

use rated coupons but does not have a CBB Service Policy assigned,
then the PDP session must be taken down.
If rated coupons are in use and data packets come through that do not
match any CBB filtering criteria, then the data packets will not be rated

and thus they will not be billed. It will be reported in the total counts for
GTP Accounting and RADIUS Accounting.
Rate Request
During initial authorization of the session, the GGSN can request the
real-time charging server to authorize a set of rated coupons. This is
accomplished by including the Rate Request for every new rate in an
initial request message to the real-time charging server. During the
initial authorization, this is treated as a hint to the real-time charging
server. The real-time charging server can ignore the requested rates
altogether and authorize a different set of rates or a partial set of the
requested rates. Once a session has been established, the real-time
charging server must respond to each rate requested with a coupon.
Each coupon will either have authorized resources or will indicate that
the rate is denied.
Triggers
Triggers provide a mechanism to specify actions for the GGSN to take
when certain real-time charging events happen. An event could be
SGSN address change and the action would be coupon re-
authorization. Another event could be an idle coupon timeout and the
action would be returning the coupon to real-time charging server.
The following triggers can be provisioned on the GGSN on a per Tariff

Profile basis: Re-authorization on QoS change, Re-authorization on
SGSN change, Re-authorization threshold and an idle coupon timer.
For CTP version 3, triggers may also be returned from the real-time
charging server. Multiple triggers can be included in each coupon. A
single trigger consists of a trigger type, a trigger action and possibly a
trigger value. The trigger type specifies which event triggers the action.
The trigger action indicates the GGSN what to do with the coupon
when the trigger event happens. The trigger value field conditionally
stores extra information needed to watch for the event such as a time
value or a threshold value.
Provisioned triggers behave in the same way as the triggers included

in the coupons returned from the real-time charging server and apply
only to rates that were successfully authorized (i.e. they do not apply
to unauthorized or denied rates). Triggers included by the real-time
charging server override any provisioned value of the same trigger
type on the GGSN.
Requested idle coupon return

In order to more efficiently manage and distribute the total real-time
charging account balance among all the rated coupons, CTP version 3
and Diameter Credit Control have the ability to give back coupons to

the real-time charging server that are not being used so that the
money allotted to them can be added back into the account balance.
This is the reason for the existence of the coupon idle timer.
If the idle timer is set too long, or the account balance is getting low,
then the idle timer may not be responsive enough. In this case, the
CTP protocol allows the real-time charging server to ask the GGSN to
return whatever coupons it deems to be most likely idle. The real-time
charging server cannot initiate a message to the GGSN, but it can use
one of a few special coupon include reasons in a response message
to request the return of idle coupons. When the GGSN receives one of
these special include reasons, it will analyze the coupons held by that
subscriber. It will return coupons that it considers to be idle up to half of
the total number of coupons held, but not more than twenty coupons.
A coupon is treated as a Idle Coupon if it has been idle for at least 30
seconds and longer than 50% of Idle Coupon Timer. After a re-auth
event the idle timeout for idle coupons is re-calculated. The new value
is the remaining idle time
If a data packet is requested for a rated coupon that has been

returned, then the GGSN will re-request the coupon from the real-time
charging server.
Initial coupon IDs

Coupon IDs may be provisioned in the CBB policy definition, which
may be sent to the real-time charging/DCC server during the initial
authorization between the GGSN and the real-time charging/DCC
server. These CBB initial authorization coupons allow the operator to
manage subscriber service with greater efficiency and control.
Additionally, communication is reduced between the GGSN and the
real-time charging/DCC server after call setup has been completed as
a result of an optimized coupon list being presented during initial
authorization.
Coupon IDs defined by CBB policy definition can be marked either

“Request on Service Start” or “Request on Usage”. A total of 40
coupons of both types is supported per CBB policy definition. An
attempt to configure a coupon list with greater than 40 coupons is
rejected. Coupons marked as “Request on Service Start” are merged
with the default coupons provisioned in the Tariff Profile and used to
negotiate with the real-time charging/DCC server. If the coupon is
marked as “Request on Usage”, the coupon is not sent to the real-time
charging/DCC server during Initial Authorization.

The requested coupons from the CBB policy marked for “Request on
Service Start” can be merged with the coupons provisioned in the Tariff
Profile to form an optimized coupon list for both CTPv3 and Diameter.
The coupons provisioned in the CBB policy have priority over those
defined in the Tariff Profile. After the completion of the merge, the
optimized list of Coupons is included in the Initial Authorization
message and presented to the real-time charging/DCC server for
service negotiation.
Table 3-14
CBB Policy Merge Matrix
# Service Tariff CBB Coupon Merged Expected Behavior

Package Coupons Coupons Total Coupons
Type from Service <=40
Package
1 RADIUS 678 012345 Y 01234 CBB Coupons are available

5678 in the RADIUS service
Marked as package. CBB coupon list is
Request on less than 40, so the Tariff
Service Start coupons are added to the
merged list.
2 RADIUS 678 012345 Y 678 CBB coupons are marked as

request on usage; therefore,
Marked as only the Tariff coupons are
Request on included in the merged list.
Usage
3 None 012 None Y 012 No CBB Coupons are

available via service
packages. Only Tariff
coupons are present in the
merged list.
4 QoS None 012 Y 012 Available CBB coupon list

count is < 40; however, no
Tariff coupons available to
include in the merged list.

Table 3-14
CBB Policy Merge Matrix
# Service Tariff CBB Coupon Merged Expected Behavior

Package Coupons Coupons Total Coupons
Type from Service <=40
Package
5 QoS 41 42 0 - 39 N 0 - 39 Multiple CBB Coupon lists

available via the service
Subscriber Marked as packages. QoS has the
Request on highest order of precedence
Template Service Start and is chosen to provide the
coupon list. The number of
coupons present in the list is
40. Only 40 coupons can be
added to the merged list. The
Tariff coupons are ignored.
6 RADIUS 012 012 Y 012 CBB Coupons and the Tariff

coupons are duplicates.
Marked as Duplicate coupons are
Request on excluded from the merged
Service Start list.
7 Subscriber 012 12 Y 12 CBB Coupon “0” is marked

Template as request on usage. Even
Marked as though this coupon is
Request on included in the Tariff coupon
Service Start list, it is excluded for the
merged list. Coupons marked
0 as request on usage are
added to the merged list.
Marked as
Request on
Usage
Service Redirect
When a subscriber’s real-time charging balance on any coupon falls to
zero, a Reauth Request is sent to the Real Time Charging Server. If
the account is out of funds, the real-time charging server can deny the
request and provide the URI of a Top-Up server where the subscriber
can replenish their account.
The next time the subscriber tries to initiate normal browsing, the
GGSN intercepts the Request and initiates messaging between the
subscriber and GGSN that causes the subscriber’s browser to be
redirected to the Top-Up server. Once “topped-up”, the real-time
charging server must signal the GGSN in order to allow the

subscriber’s data to pass normally through the GGSN. Service

Redirect is implemented to work with CTPv3 and Diameter.
Service Redirection is on a per coupon basis. This means that once a

specific coupon is out of available funds, all traffic on that coupon is
redirected to the “Top-Up” site. Also, once a subscriber is redirected to
a “Top-up” site, the user replenishes funds for all coupons that are
currently in the redirected state. This is to avoid potential problems
that would arise if a service provider chose to provision a downlink-
only coupon.
Figure 3-37
Service Redirect configuration
Subscriber Yahoo
real-time
charging
server
SGSN Gn Gi
GGSN Internet
Top-Up
Server
Amazon
The CTPv3 Protocol has been updated to support Service Redirection

for rated coupons. The real-time charging server can now send a
Redirection URI to the GGSN in a GPRS Service Response message
when the subscriber is out of funds for the requested coupon ID. The
real-time charging server can also send a Reauth Command to the
GGSN to force the GGSN to request reauthorization for coupons. The
Reauth Command should be sent by the real-time charging server
after the account has been topped up to cause coupons to be cleared
from redirection and obtain balance.

Figure 3-38
CTPv3 Redirection Messaging
GGSN Real-time charging server
1
Service Request (reauthorization)
2
Service Response (Denied, Redirection URI)
3
Reauthorization Command
Reauthorization Command
4
Reauthorization Command ACK
5
Service Request (reauthorization)
1. GGSN sends a reauthorization request for a particular coupon -

this could also be for a new coupon.
2. Real-time charging server rejects the request and includes a
Redirection URI for the GGSN to use. The subscriber is redirected
on their next initiation of browsing. The subscriber adds funds to
their account through the Top-Up server which eventually updates
the real-time charging server.
3. The real-time charging server sends a Reauthorization Command
to the GGSN. Unless a rated coupon IE is included specifying
individual coupon IDs, the Reauthorization Command applies to all
of the subscriber’s coupons. Upon receipt, GGSN discards any
Redirection URIs associated with coupons being reauthorized.
4. GGSN sends a Reauthorization Command ACK to acknowledge
receipt of the Command.
5. GGSN sends a service request to reauthorize the subscriber’s
coupons that are not currently in the process of being reauthorized.
The Redirection URI is received from the real-time charging server in

response to an auth request or reauth request. The real-time charging
server can tailor the URI to the relevant subscriber and/or coupon ID
or make it common across all subscribers and coupon IDs. The GGSN
does not parse the contents of the URI. The redirection URI for a given
coupon ID is only used when a GET/POST is rated for that coupon ID
in either the uplink or downlink direction. Even if a redirection URI is

present for one coupon ID, packets rated against other coupon IDs are
unaffected.
A coupon denied by the OCS, can be either redirected to a URI or

dropped. If a redirected URL is contained within the OCS Server
Response, then the coupon would be forwarded to the “Top-Up”
server. If the Redirection URL is not present, then a packet processed
by the CBB, that is charged against the denied coupon is dropped.
The packet volume counts are also dropped. The Forbidden Coupon is
a way for the CBB to account for the packets dropped due to the OCS
denying the rated coupon without a Redirect URL. The packet is still
dropped, after checking that it is provisioned against a Coupon denied
by the OCS. However, the packet’s volume counts are incremented
against the Forbidden Coupon. Any dropped packet is counted against
the Forbidden Coupon, including packets dropped during a Re-
Authorization Request. The Forbidden Coupon operates as any other
Coupon. It may be Re-authorized or denied. If the Forbidden Coupon
is in the Denied State, or the Forbidden Coupon is not available on the
Nortel GGSN, any volume counts against a denied coupon are
dropped.
It is assumed that the URI can be used for both WAP and HTTP/TCP
redirection. The Top-Up site should be simple enough for a WAP
gateway to translate it into WML. For HTTP/TCP connection, the
Connection Sequence occur prior to the HTTP Request messages.
The HTTP Request and the Connection Sequence are charged
against the rate assigned to the HTTP Request. After the Connection
Sequence, if no HTTP Request arrives on the Nortel GGSN, the
Connection Sequence is rated against the Default Coupon. The
charging of the TCP Connection Sequence is provisionable. The
operator may charge these initial packets towards the Default Coupon,
or towards the first HTTP Request. In case of depleted prepaid funds,
since the Subscriber is re-located to a Top-Up Server, the messages
are charged against the coupon ID provisioned against the Redirect
URL. If this URL is provisioned in the CBB policy filter’s URL list, all
Service Redirect messages are counted towards this coupon else the
messages are counted against the Default Coupon ID.
The Service Redirect feature has been disabled by default. A Software

Optional Configuration (SOC) license key must be provided in order to
access Service Redirect functionality. If the function is disabled, the
GGSN ignores the redirect URI contained in messages from a real-
time charging server and treats the coupon as a denied coupon. If the
function is enabled, the GGSN stores the redirect URI for future
redirection. If the function is disabled after having been enabled, any
redirection URIs obtained for subscribers are used if triggered. The
reauthorization command is not disabled. Even if Service Redirect is

disabled, the GGSN responds to the reauthorization command by

sending a reauthorization request as directed.
Tariff Time Change

The Tariff Containers feature enhances the GGSN, GPRS service
request message and GPRS service response message as follows:
• Reports the Service Profile name contributing the active Content
Based Billing Policy to the real-time charging server within the
GPRS service request reauthorization and report messages.
• Tracks coupon time and volume usage before and after tariff time
changes. The usage is reported during normal coupon reporting
rather than during the tariff time change.
The real-time charging server triggers the tariff change functionality by
authorizing a coupon with a tariff time change trigger.
The GGSN tracks the coupon time and volume usage before and after
the tariff time change. No messaging is initiated by the GGSN when
the tariff time change occurs. Instead, the usage report is contained
within the two coupons. The first containing the usage before the tariff
change and the second contains the usage after the tariff change.
Tariff time changes are configurable on the GGSN through the SCS
GUI. The GGSN can be configured with many different tariff time
change profiles to provide different groups of users with different tariff
time plans. The tariff time profile that is used for each user session can
be configured statically on the APN ToD profile.
Figure 3-39 “Tariff Time Change message flow” provides an example

of the new tariff change triggers and include reasons within the GPRS
service messages.

Figure 3-39
Tariff Time Change message flow
GGSN
Real-time
charging server
1 GPRS Service Request message - Initial Auth Request
2 GPRS Service Response message - Initial Auth Response
Tariff Time Change
3 GPRS Service Request message - Re-auth Request
4 GPRS Service Response message - Re-auth Response
Tariff Time Change
5 GPRS Service Request message - Final Report
1. Initial Auth request - Unchanged, the GGSN requests for coupons.

2. Initial Auth response - real-time charging initiates the feature by
returning a rated coupon containing the normal Successful coupon
include reason and a Tariff Time Change Trigger.
3. Re-auth request - A tariff time change occurred prior to the coupon
requiring a re-auth. Two coupons are delivered to the real-time
charging server. The first coupon reports the usage before the tariff
time change, contains a timestamp sub IE with the time of the tariff
change and has a coupon include reason of Return Coupon -
usage before tariff change. The second coupon is treated as a
normal re-auth reporting the usage after the tariff time change.
4. Re-auth response - Since the first coupon was returned with the
usage before the tariff change, the real-time charging server re-
initiates the tariff change functionality by including the Tariff Time
Change Trigger within the successful re-authorized coupon.
5. Final Report - A tariff time change occurred prior to the coupon
being returned. The first coupon reports the usage before the tariff
time change, contains a timestamp sub IE with the time of the tariff
change and has a coupon include reason of Return Coupon -
usage before tariff change. The second coupon is treated as a
normal final report containing the usage after the tariff time change.

Dual Coupon
The GGSN supports the dual coupon option in which the Online
Charging Server separately authorizes quota to be used before and
after the tariff boundary. This is done by granting two instances of the
same coupon id - one for before and one after the tariff boundary.
Any usage that occurs before the tariff boundary is consumed from the
before-coupon. When a tariff switch occurs, the GGSN closes the
before-coupon and subsequently deducts any usage that occurs after
the boundary from the after-coupon.
When a tariff boundary is crossed, the type of tariff change functionality

used for a particular subscriber is controlled based on message
elements received from the Online Charging Server. The selection
criteria and resulting behavior for CTPv3 is shown in Table 3-15:
“CTPv3 Tariff Change Functionality,” on page 125. The selection
criteria and resulting behavior for DCC is shown in Table 3-16: “DCC
Tariff Change Functionality,” on page 126.
Table 3-15
CTPv3 Tariff Change Functionality
TOD Profile Tariff Change Dual Tariff Behavior

Configured Coupon Change
on SCS Trigger Coupon
Present In Trigger
Coupon Present In
Grant Coupon
Grant
N N N No Tariff Change occurs.
N Y N No Tariff Change occurs.
N N Y No Tariff Change occurs.
N Y Y Invalid combination. A
particular coupon cannot
use both trigger types.
This is a parsing error; an
error response is
generated by the GGSN.
Y N N No Tariff Change occurs.
Y Y N Tariff Change occurs on

configured TOD boundary
using single coupon
functionality.

TOD Profile Tariff Change Dual Tariff Behavior

Configured Coupon Change
on SCS Trigger Coupon
Present In Trigger
Coupon Present In
Grant Coupon
Grant
Y N Y Tariff Change occurs on

configured TOD boundary
using dual coupon
functionality.
Y Y Y Invalid combination. A
particular coupon cannot
use both trigger types.
This is a parsing error; an
error response is
generated by the GGSN.
Table 3-16
DCC Tariff Change Functionality
TOD Profile Configured Tariff-Time- Tariff- Behavior

on SCS Change AVP Change-
Present In Usage AVP
Quota Grant Present In
Quota Grant
N N N No Tariff Change
occurs.
N Y N Tariff Change occurs

at time specified in
TTC AVP using single
coupon functionality.
N N Y No Tariff Change
occurs.
N Y Y Tariff Change occurs

at time specified in the
TTC AVP using dual

Y N N Tariff Change occurs

on configured TOD
boundary using sin-
gle coupon functional-
ity.
Y Y N Tariff Change occurs

at time specified in
TTC AVP using single
Y N Y Tariff Change occurs

on configured TOD
boundary using dual
Y Y Y Tariff Change occurs

at time specified in the
TTC AVP using dual
GeoZone service
GeoZone service is another tariff service supported on the GGSN. It
allows different tariff based on where the subscriber originates the
PDP context geographically. This is indicated in the Cell Global ID
(GTP Private Extension IE) of the Create PDP Context Request
message. In GeoZone service, the mid-call Service Request is not
triggered by receiving the Update PDP Context Request message.
The real-time charging server expects only the begin-call Service
Request for GeoZone service. GeoZone service is supported only with
CTP version 1. Newer versions of real-time charging are not enabled
for GeoZone.
WAP service
The GGSN supports Wireless Application Protocol (WAP) service by
communicating with the Application server through the Wireless
RADIUS Application Protocol (WRAP), configured in the Application
Profile, or by proxying through the RADIUS Accounting Server using
RADIUS protocol. For more information see “WAP Service”.
WAP service activation

To activate the WAP service for the mobile subscriber on a specific
data session, the Application Server must be notified when the
subscriber starts a data session that requires the service. When a
Create PDP Context Request is received, its APN is used to determine
if the subscriber is a WAP subscriber and the Application Server to be

contacted for the subscriber session. After successful subscriber

authentication and IP address allocation for the subscriber, the GGSN
sends a RADIUS START message to the Application Server with the
MSISDN and the mobile’s IP address. When the GTP tunnel is taken
down, the GGSN again sends a RADIUS STOP message to the
Application Server to indicate the session has ended for the
subscriber. During the session, if a subscriber’s QoS parameters
change for any reason and WAP service is enabled, a RADIUS
INTERIM-UPDATE message will be sent from the GGSN to the
Application Server to update the subscriber’s QoS information.
To activate the connection between GGSN and Application Server, a

RADIUS ACCOUNTING-OFF followed by a RADIUS ACCOUNTING-
ON messages are sent to the Application Server during the boot time
or when the Application Profile is newly provisioned in the system.
Only after receiving a proper response for each of these two
messages, the GGSN deems the connection has been established
successfully. None of these RADIUS START/INTERIM-UPDATE/
STOP messages are sent to the Application Server if the connection
establishment fails.
If the Application Server is out of service, the proper SNMP trap is

generated to indicate the problem and the connection activation
procedure described above is executed. The GGSN keeps sending
the ACCOUNTING-OFF message to the Application Server until the
response comes back. Following that, an ACCOUNTING-ON request
and response is exchanged between the two nodes.
WAP service for IP PDU type

For an IP PDU type session there are two modes of operation,
configurable through the SCS:
• Service Mode: The Application Server is notified with the RADIUS
START message consisting of the mobile’s MSISDN and the IP
address after the GTP tunnel is set up. A RADIUS START reply
message is received if authorization and authentication is
successfully executed at the Application Server. If no response is
received, the request is considered failed. The GTP tunnel stays up
regardless of whether the WAP authorization or authentication is
successful or not.
• Session Mode: The Application Server is notified with the RADIUS
START message consisting of the mobile’s MSISDN and the IP
address before the GTP tunnel is set up. A RADIUS START reply
message is received if authorization and authentication is
successfully executed at the Application Server. If no response is
received or if access is rejected at the Application Server, the
request is considered failed and the session is taken down. If

RADIUS Accounting is enabled, the RADIUS Accounting Session

Mode is supported for IP PDU type.
WAP service for PPP PDU type

For PPP PDU type, only Service mode can be applied. A GTP tunnel
is set up for PPP session negotiation. Since the Application Server
requires an IP address for the mobile subscriber, and the NCP
negotiation of the PPP session determines the IP address for the
mobile to use for that PPP session, the Application Server is notified
with the RADIUS START message after the IPCP negotiation is
completed. WAP service only provides support for the PPP PDU type
when the PPP session terminates on the GGSN.
Interaction between GGSN and Application Server

Figure 3-40 “WAP service message flow for IP PDU type in Service
Mode” through Figure 3-42 “WAP service message flow for PPP PDU
type” shows the interaction between the GGSN and the Application
Server for setting up and taking down a GTP tunnel for IP and PPP
PDU types.

Figure 3-40
WAP service message flow for IP PDU type in Service Mode
SGSN GGSN Application

Server

For IP PDU type, authentication
and IP address allocation is done.
The method of authentication (if
required) and the method of IP
address allocation can be specified
Create PDP Context Response by configuration.

RADIUS START message
(MSISDN, Mobile’s IP Address,
GGSN IP Address, Charging ID
User Name, APN, QoS,....)
RADIUS START Reply

RADIUS INTERIM-UPDATE message
Update PDP Context Response (MSISDN, Mobile’s IP Address,
User Name)
RADIUS INTERIM-UPDATE Reply
Delete PDP Context Request

RADIUS STOP message
Delete PDP Context Response
RADIUS STOP Reply

Figure 3-41
WAP service message flow for IP PDU type in Session Mode
Application
SGSN GGSN Server
For IP PDU type, authentication
Create PDP Context Request and IP address allocation are done
for subscribers.
The method of authentication (if
required) and method of IP
address allocation are specified by
configuration.

User Name, APN, QoS,...)
RADIUS START Reply

RADIUS INTERIM-UPDATE message
Update PDP Context Response (MSISDN, Mobile’s IP Address
User Name)

RADIUS STOP message
Delete PDP Context Response
RADIUS STOP Reply

Figure 3-42
WAP service message flow for PPP PDU type
SGSN GGSN Application

Server

For PPP sessions terminating
on GGSN, authentication and
IP address allocation are done
for the subscribers.
:
PPP session negotiation
:
PPP session up between MS and GGSN
User Name)
RADIUS START Reply
Update PDP Context Request RADIUS INTERIM-UPDATE request

(MSISDN, Mobile’s IP Address
User Name,....)

PPP session termination RADIUS STOP request
(MSISDN, Mobile’s IP Address
Delete PDP Context Response User Name)
RADIUS STOP Reply
Policy merging 3
Policy merging is the functionality the GGSN uses to determine the
correct and complete set of IP services that are applied to a particular
subscriber. Policy merging takes input from one or more sources.
These sources include the real-time charging server, RADIUS Server,
GGSN QoS Profile, and subscriber template. Each of these sources
can supply one or more IP Service Profiles, each containing one or
more IP service policies, to be applied to a subscriber’s PDP session.
The function of policy merging is to sort through all these inputs,
prioritize the offered inputs, and select the final set of IP service
policies which are then applied to the PDP session.

SGSN Grouping 3
When an inter-SGSN handover occurs, an Update PDP Context
Request is sent from the new SGSN to the GGSN. In some network
configurations, inter-SGSN handover can result in a significant
signalling load due to the presence of multiple SGSNs serving an
area. SGSN grouping is made to limit the amount of messaging in
such cases.
The GGSN compares the Group Identifier of the new SGSN and that
of the old SGSN. If the Group Identifiers match, the GGSN does not
signal Diameter Credit Control (DCC) Update Credit Control Request
(CCR(U)) message, RADIUS Accounting Request Interim-Update
message, and CTP Re-Auth Request message.
Handover between SGSNs, in which either the old or the new SGSN
does not belong to a group, is considered as SGSN change. Therefore
no signaling optimization is performed.G-CDR record generation to the
CGF servers is not affected by this functionality.
SGSN Grouping is SOC activated on a per SCS basis. The function

SGSN Grouping is triggered on a per APN basis. When SGSN
Grouping is enabled, the GGSN uses the SGSN address for Control
Plane to derive the SGSN Group Identifier. The SGSN Group Identifier
is provisioned in SGSN Mapping table, previously known as PLMN ID
Mapping table. Up to 255 SGSN groups are supported.
The provisioning of SGSN Group Identifier is optional. The

provisioning of a default SGSN Group Identifier is also optional. If no
SGSN Group Identifier is provisioned, “No Group” will be used as a
default. Table 3-17 “Derived SGSN group identifier logic” on page 133.
shows the logic to derive the SGSN Group Identifier.
Table 3-17
Derived SGSN group identifier logic
With “SGSN Grouping” Derived SGSN Group

enabled
Matching entry in the SGSN Use the SGSN Group Identifier of the matching entry
Mapping table found
Matching entry in the SGSN Default entry in the SGSN Use the SGSN Group
Mapping table not found Mapping table provisioned Identifier of the default entry
Default entry in the SGSN Use “No Group” (0)

Mapping table not
provisioned

Lawful Interception (LI) 3

This feature provides Lawful Interception capability on the GGSN for
packet data services. Both GTP v0 and v1 are supported by this feature.
The GGSN LI feature provides the capability for a law enforcement
agency to target a wireless data user and collect information transmitted
through a packet data session on a GGSN. The following are categories
of information that can be collected:
• Interception Related Information (IRI) is the call identifying
information.
• Communication Content (CC) information is the actual data
packets transmitted to and from the user.
This feature implements the Access Function (AF) functionality on the

GGSN as specified in TS 33.106 and TS 33.107.
The function entities are described as follows:

• ADMF (Administration Function) obtains lawful authorization from
one or more Law Enforcement Agency (LEA) and sends
provisioning data to Access Functions (AF) and/or Delivery
Functions (DF).
• AF (Access Function) accesses IRI and CC and delivers IRI to
DF2, CC to DF3.
• DF2 (Delivery Function 2) delivers IRI to authorized CFs
• DF3 (Delivery Function 3) delivers CC to authorized CFs.
• CF (Collection Function) collects and processes IRI and CC for the
LEA.
The GGSN (as AF) interfaces with ADMF and DF using Nortel
Network’s proprietary protocol, Lawful Interception Common Protocol
(LICP) and Lawful Interception Access Protocol (LIAP). LICP/LIAP
uses TCP/IP as the transport layer.
In this document, the ADMF, DF2, and DF3 are generally referred to
as the Lawful Interception Gateway (LIG). Also, for convenience both
DF2 and DF3 are referred as DF. Figure 3-43 “Nortel implementation
of Lawful Interception” shows the Nortel implementation of the Lawful
Interception model.

Figure 3-43
Nortel implementation of Lawful Interception
AF (GGSN) provisioning data

intercepted data
LICP/LIAP
ADMF DF2/DF3
LIG
CF
... CF
LEA LEA
The GGSN plays a passive role in the LI scheme. It provides the

interception function. The ADMF sends the provisioning information of
target mobile subscribers to the GGSN. The GGSN stores the target
information in a database. The target information consists of the target
id, information to intercept (IRI only or both IRI and CC), DF2 address/
port, and DF3 address/port. When the GGSN detects that a target is
conducting activity, it notifies the LIG, intercepts the data packets of the
target, duplicates the data packets without interpretation or alteration
and delivers them to the LIG. It is the responsibility of the LIG to
understand the protocols embedded in the data packets, reconstruct
the data sessions that take place, and provide usable content to the
LEA. The LEA equipment displays the intercepted information in a
usable format.
The LIG is implemented by another equipment manufacturer. This

feature does not address the implementation of the LIG, only the

GGSN as the AF and the interface between the GGSN and the LIG
are discussed. Also, the CF implementation and interface to LEAs are
not addressed in this document.
In this document, a target mobile subscriber is referred to as “target”.

The GGSN target database can store a maximum of 30,000 targets,
but the GGSN only supports the interception of 3,000 contexts
(including primary and secondary) simultaneously. When the 3,000
limit is reached, all subsequent targets are not intercepted. When the
number of active targets being intercepted goes below the limit, the
interception for the missed targets is not automatically started. These
targets are intercepted the next time they become active.
Traffic Performance Optimizer (TPO) 3

Traffic Performance Optimizer (TPO) servers are used by wireless
operators to optimize and compress the data between the mobile
subscriber and the TPO to enhance the user experience. It is enabled
through Software Optionality Control (SOC) and can not be disabled
once enabled.
The TPO operates in the following modes:

• clientless
• client-server
Clientless server mode
This mode means there is no client software required on the mobile
device. This means that any protocol optimization of the payload
manipulation performed by the TPO should be compliant to the IETF
standards and understood by the applications on the mobile device.
Client-server mode
This mode is where client software is installed on the mobile device.
This results in the performance optimization in exchanging data
between the TPO client on the mobile device and the TPO server. The
method of transport of data and the protocol optimization performed is
typically proprietary to the TPO vendor and may not be compliant to
IETF specifications. For example, the optimization of HTTP made by
the TPO client-server mode typically results in the GGSN not being
able to perform deep packet inspection on the data flow to extract the
URL. TPO client-server mode typically provides a greater level of
optimization and compression performance than TPO clientless mode.
Although the principal driver for TPO is the interworking of the GGSN
CBB for both real-time charging and postpaid, it allows the
interworking of all GGSN IP services and functionality with the
optimized data flow. Without seeing the un-optimized data packets, the

GGSN cannot effectively inspect packets to apply the different IP

services including the CBB.
For this purpose, a loopback interface between the GGSN and TPO is
implemented. GRE tunneling is used for the loopback interface
between the GGSN and the TPO.
In the client-server mode, optimized uplink packets travel from the

mobile station to the GGSN. The GGSN detects this optimization
packets based on some basic rules, and forwards those packets to the
TPO. The TPO de-optimizes the packets and sends them back to the
GGSN. The GGSN then routes the packets through the IP service
chain before forwarding the packets to the Internet. In the clientless
mode, the GGSN detects the traffic based on the same basic rules as
the client-server mode and forwards all TCP traffic to the TPO.
In both client-server and clientless modes, in the downlink direction,

packets coming from the Internet travel un-optimized to the GGSN,
where they are run through IP services first and then are redirected to
the TPO through the loopback interface. The GGSN sends a downlink
packet to the TPO if the uplink packets that belongs to the same flow
are being sent to the TPO, if uplink information are not available for
some reason, then the policy rule is applied for that purpose. The TPO
optimizes the packet and sends it back to the GGSN. The GGSN then
forwards the optimized packet back to the mobile station.
For a subscriber to use the TPO service, a TPO IP service has to be

applied to that subscriber either through the APN configuration on the
SCS or through the single APN configuration. The TPO IP service
configuration (policy service) is used to make the decision whether a
traffic in both uplink and downlink directions are to be sent to the TPO
or not. The required configuration for this function is basically
forwarding all TCP traffic to the TPO.
Without having the IP packets un-optimized and readable, the GGSN

cannot execute most of the IP services, including the CBB for Time,
Volume and Event based billing. Running an optimized packet through
the CBB infrastructure would not yield accurate results. TPO reports
billing information based on Gi side packets. This means all volume
byte counts are the byte counts for the un-optimized packets and don’t
reflect over the air byte counts. The timestamps for the time based
billing are also based on the Gi packets.
TPO supports all network models for both IP PDU and PPP PDU types
as well as for both primary and secondary PDP contexts. Each context
on a GGSN is uniquely identified by the GRE key and user IP address.

The TPO uniquely identifies each context using the GRE key, user IP
address, and the GGSN TPO IP address.

4-1
Network deployment models 4

Overview 4
To interwork with the Packet Data Network (PDN) as described in
3GPP TS 09.61, version 7.10.0, “Interworking between the Public
Land Mobile Network (PLMN) and Packet Data Network (PDN)” and
3GPP TS 29.061, version 4.8.0, “Interworking between the Public
Land Mobile Network (PLMN) supporting Packet Based Services and
Packet Data Network (PDN)”, the Nortel GGSN supports a variety of
deployment configurations. The interworking with PDN network is
done using IP routers. The Gi interface is the reference point from the
GGSN to communicate with external public and private IP networks.
From the external viewpoint in the PDN, the GGSN is seen as a
regular IP router.
With a variety of operational configurations, the GGSN allows the

configurations to be grouped under different APNs. Each individual
APN can be configured to have one of the following network
deployment models. The Aggregation APN is restricted to use the
Wireless ISP model only.
Network models 4
The network models that the GGSN supports are:
• Wireless ISP model
• L2TP Virtual Private Network (VPN) model
• VPN Variants
— IPSec VPN model
— Generic Routing Encapsulation (GRE) VPN model
— ATM VPN model
— VLAN VPN model
— GGSN VPRN model
— MPLS VPN model
— VLAN eBGP VPN model

4-2 Network deployment models Copyright © 2000–2008 Nortel Networks
Table 4-1 summarizes the GGSN configuration options associated

with each network model.
Table 4-1
Network model configuration options
Configuration Wireless ISP Wireless ISP L2TP VPN model VPN variants
option model with model with (including IPSec
traditional APN Aggregation VPN, GRE VPN,
APN ATM VPN, VLAN
VPN, MPLS
VPN, and GGSN
VPRN models
Access mode Transparent or Transparent or Transparent or Transparent or

non-transparent non-transparent non-transparent non-transparent
Subscriber RADIUS RADIUS LNS RADIUS

authentication
PDU type IP or PPP IP or PPP IP or PPP IP or PPP
PPP session Terminated to Terminated to Created between Terminated to

GGSN GGSN GGSN and LNS for GGSN
IP PDU and
passing through for
PPP PDU.
Gi interface Raw IP Raw IP L2TP or L2TP over IPSec, GRE

IPSec tunnel, VLAN, or
ATM PVC
IP address Address Address Address allocation Address

allocation allocation by allocation by by remote Intranet allocation by
GGSN GGSN GGSN
IP address Public IP address Public IP address Public or private IP Public or private

domain from operator’s from operator’s address from IP address from
domain or Private domain or Private operator’s domain operator’s
IP address from IP address from domain
external NAT external NAT
Server Server
IP address Internal address Internal address IP address is Internal address

allocation pools, DHCP or pools, DHCP allocated at the pool, DHCP or
methods RADIUS static/ Client or RADIUS LNS, not on the RADIUS static/
dynamic address static/dynamic GGSN. dynamic address
allocation address allocation allocation
—sheet 1 of 3—

Network deployment models 4-3
Table 4-1
Network model configuration options (continued)
APN ATM VPN, VLAN
VPN, MPLS
VPN, and GGSN
VPRN models
IP Services Applied to the Applied to the Not supported Applied to the

data packets on data packets on data packets on
the Gi interface the Gi interface the Gi interface
Prepaid Supported based Supported based Supported based Supported based

Service on configuration on configuration on configuration on configuration
RADIUS Supported based Supported based Supported based Supported based

Accounting on configuration on configuration on configuration on configuration
WAP Service Supported via Supported via Not supported Supported via
RADIUS RADIUS RADIUS
Accounting or Accounting Accounting
Application Profile
QoS Service Supported based Supported on Gn Supported on Gn Supported based

on configuration interface based interface based on on configuration
on configuration configuration
IP Multicast Supported based Not supported Not supported Not supported

on configuration
and not supported
for GRE and
VLAN access
interface
End to End IP IP IP/PPP for IP PDU IP

Protocols and PPP for PPP
PDU
Roamer Partial Supported based Supported based Supported based Supported based
Billing on configuration on configuration on configuration on configuration
Single APN Supported based Supported for Supported based Supported based
on configuration Prepaid on configuration on configuration
Subscription and
IP Services
—sheet 2 of 3—

Table 4-1
Network model configuration options (continued)
APN ATM VPN, VLAN
VPN, MPLS
VPN, and GGSN
VPRN models
Tariff Based Supported based Supported based Supported based Supported based
Billing on configuration on configuration on configuration on configuration
—sheet 3 of 3—

Wireless ISP model 4

The Wireless ISP model is a basic ISP service offered to a mobile
subscriber. The IP packets from the mobile are routed on the Gi
interface to the public Internet. IP packets received on the Gi interface
are sent back to the appropriate mobile subscriber.
To address the multiple market deployments, the Wireless ISP model

supports an additional aggregation configuration. This variant of the
Wireless ISP model offers significantly higher activation rates and
session capacity compared to the traditional configuration.
In order to segregate the two base configurations in the Wireless ISP

model, a distinction is made during APN configuration. The GGSN
may be configured using exclusively traditional APNs, exclusively
Aggregation APNs or a mixture of the two. This decision is based on
requirements of the GGSN in a specific market deployment.
The Wireless ISP model, using traditional APNs, supports both

transparent and non-transparent access for IP and PPP PDU types.
For PPP PDU type, the PPP session is terminated on GGSN and the
encapsulated raw IP packets are delivered to the Gi interface. Any
configured IP services are applied to the IP packets before the packets
are sent to or received from the Gi interface.
The Wireless ISP model, using Aggregation APNs, supports both

transparent and non-transparent access for the IP and PPP PDU
types. PPP PDU type PDP sessions are supported on Aggregation
APNs, however, incoming PPP activations are processed as if they
were received on a traditional APN in terms of resource consumption.
It is recommended that subscribers using the PPP PDU type be
configured on a traditional APN.
In Figure 4-1, the PLMN is the UMTS/GPRS packet domain network

where the GTP tunnel is embedded for carrying the bearer traffic. The
OAM network is used for provisioning access, statistics and alarm
transfer, billing delivery and auditing. The IP packets can be routed to
different networks through different trunk interfaces with different ISPs
on the GGSN. The source address of outgoing IP packets is the
address of the ISP to which the trunk interfaces belongs. The Gn ISP
is used to communicate with the PLMN network, the default ISP and
the Ga ISP are used to communicate with the OAM network. The
default ISP is automatically created on the GGSN for access to the
SCS Server and FTP Server.

Figure 4-1
Wireless ISP network model
SCS
CGF
DNS FTP
(APN OAM
resolution)
SGSN
GGSN
Internet
PLMN
DNS
(ISP
GTP tunnel service)
Wireless ISP GRE access

GRE provides a lightweight data-encapsulating tunnel to a remote
network.
In this GRE access, a GRE tunnel between the GGSN and the remote
network is defined. If the destination address of a GTP data packet
from the mobile matches the reachability of a GRE tunnel Access
Subscriber, this data packet is routed through GRE tunnel associated
with this access subscriber to the public Internet or private Intranet.
A point to point GRE tunnel can be configured from the GGSN to

remote networks. Figure 4-2 shows the network layout of the GRE
access interface.

Figure 4-2
Wireless ISP GRE access
FTP SCS
Internet
DNS
(APN CGF OAM
resolution)
SGSN
GGSN
PLMN Intranet/ISP
GTP tunnel GRE Tunnel
Wireless ISP VLAN access

In a VLAN access interface, a VLAN Access Subscriber is configured.
If the destination address of a GTP data packet from the mobile
matches the reachability of the Access Subscriber, this data packet is
VLAN tagged and routed through the VLAN access interface to the
public Internet or private Intranet.
A VLAN tagged Ethernet connection can be configured from the

GGSN to a remote network. Figure 4-3 shows the network layout of
the VLAN tagged access interface.

Figure 4-3
Wireless ISP VLAN access
FTP SCS
Intranet
DNS
(APN CGF OAM
resolution)
SGSN
GGSN
PLMN Internet
GTP tunnel VLAN tagged
L2TP VPN model 4

In the L2TP VPN model, the GGSN terminates a GTP tunnel from the
SGSN and creates an associated L2TP tunnel to the Intranet. The
tunnel mapping at the GGSN is a one-to-one mapping (one GTP
tunnel to one L2TP session). This network model provides transparent
access mode to the GGSN. Both IP and PPP PDU type are supported
in this network model. For PPP PDU, the PPP session from the mobile
is passed through to the L2TP tunnel. For IP PDU, a new PPP session
is created between the GGSN and the L2TP Network Server (LNS).
For the PPP PDU type, the GGSN proxies all PPP packets from the
mobile to the remote LNS. For the IP PDU type, the GGSN packs the
IP packets from the mobile with a PPP header and sends them to an
L2TP tunnel. On the receiving side, the header of the PPP packets is
removed and GGSN sends the packets to the mobile.
In this network model, GGSN acts as a L2TP Access Concentrator

(LAC). The operator has the option of enabling security (IPSec) on the
L2TP tunnel to the remote LNS. Subscriber authentication and IP
address allocation can be done by the LNS at the remote Intranet. The
GGSN does not perform any subscriber authentication nor the IP
address allocation for the mobile subscriber.

When configuring a dynamic L2TP VPN for single APN, non-

transparent access mode must be used. Multiple L2TP tunnels may be
received from the RADIUS Server. All the attributes of the same tunnel
have the same tag. One of the tunnels is selected based on the
preference attribute. The L2TP tunnel is established over the selected
tunnel. In this case, the LNS is still responsible for the subscriber
authentication.
The subscriber is also dependent upon the remote Intranet to provide

the access to the Internet. A remote firewall can be used to protect and
restrict the subscribers’ access to the Internet as shown in Figure 4-4.
It has the same PLMN and OAM network configuration as the Wireless
ISP model.
Figure 4-4
L2TP VPN network model
FTP SCS
Intranet/ISP
*AAA LNS
DNS
(APN CGF OAM
resolution) Firewall
SGSN
GGSN
Internet
PLMN LAC
GTP tunnel L2TP tunnel

L2TP over IPSec (optional)
*AAA - Authorization/Authentication/Accounting

VPN variants 4
The GGSN provides a number of VPN variants. All are conceptually
similar, but differ in certain specifics. At the heart of each VPN variant
is the creation of a VPN within one or more GGSNs. A VPN is
essentially a small, private routing table within an existing ISP of a
GGSN. Only members of the VPN have access to the routing table, so
only members can send packets to the various destinations within the
VPN. Refer to Nortel Services Edge Router 5500 Provisioning VPNs,
VLANs, and Tunnels for more information about configuring VPNs.
Mobile subscribers access a VPN in the same manner for each VPN
variant. The difference among the VPN variants is in the manner in
which Access Subscribers are configured in the VPN. An Access
Subscriber represents the connection of a corporate or private Intranet
to the VPN. Hence the Access Subscriber is not an individual person,
but rather an entity or organization. The Access Subscriber represents
the CPE through which mobile subscribers who are members of the
VPN access the corporate network.
Through the configuration of VPN and the addition of Access

Subscriber in a VPN, the mobile subscribers are granted secure
access to a private Intranet and the network users can securely
communicate with the mobile subscribers.
The different Access Subscriber methodologies are described in the

following sections.
IPSec VPN model

The IPSec VPN provides a secure link (IPSec) to a corporate or
private IP network. Members of the VPN can access the private
network using an authenticated and/or encrypted link between the
GGSN and the CPE portal of the private network.
In this VPN model, an IPSec tunnel between the GGSN and the
corporate network is defined. An Access Subscriber is created to
represent the corporate network. This Access Subscriber is then
bound to the IPSec tunnel (all data to and from the Access Subscriber
must utilize the IPSec tunnel) and is also made a member of the VPN.
This network model provides both transparent and non-transparent

access modes. Both IP PDU and PPP PDU types are supported in this
model. If PPP PDU type is used, the PPP session is terminated on the
GGSN and the IP packets are forwarded to the IPSec layer.

A single point to point IPSec tunnel can be configured from the GGSN
to the remote Intranet gateway (see Figure 4-5). It has the same
PLMN and OAM network configuration as the Wireless ISP model.
Figure 4-5
IPSec VPN network model
FTP SCS
Intranet/ISP
DNS
(APN CGF OAM
resolution)
SGSN
GGSN
Internet
PLMN
GTP tunnel IPSec Tunnel
GRE VPN model

The Generic Routing Encapsulation (GRE) VPN is similar to the IPSec
VPN in that a VPN is created on the GGSN and an Access Subscriber
is accessed using an IP tunnel. However, the tunnel technology is
different in that GRE is used rather than IPSec. GRE provides a
lightweight data-encapsulating tunnel to a corporate or private
Intranet.
In this VPN model, a GRE tunnel between the GGSN and the
corporate network is defined. An Access Subscriber is created to
represent the corporate network. This Access Subscriber is then
bound to the GRE tunnel (all data to/from the access subscriber must
use the GRE tunnel) and is also made a member of the VPN.

access modes. Both IP PDU and PPP PDU types are supported. If
PPP PDU type is used, the PPP session is terminated on the GGSN
and the IP packets are forwarded to the GRE layer.

A single point-to-point GRE tunnel can be configured from the GGSN

to the remote Intranet gateway. Figure 4-6 shows the network layout of
the GRE VPN model. It has the same PLMN and OAM network
configuration as the Wireless ISP model.
Figure 4-6
GRE VPN network model
FTP SCS
Intranet/ISP
DNS
(APN CGF OAM
resolution)
SGSN
GGSN
Internet
PLMN
GTP tunnel GRE Tunnel
ATM VPN model

The ATM VPN is similar to the IPSec VPN and GRE VPN in that a
VPN is created on the GGSN and an Access Subscriber is also added
to the VPN. However, in an ATM VPN, the Access Subscriber is
created, made a member of the VPN and also is bound to an ATM
PVC connection which has been previously configured. All traffic to
this Access Subscriber is sent on the ATM PVC, all traffic arriving on
the ATM PVC is presumed to have arrived from the Access
Subscriber.

access modes. Both IP PDU and PPP PDU types are supported. If PPP
PDU type is used, the PPP session is terminated on the GGSN and the
IP packets are forwarded to the ATM PVC.
A single ATM PVC connection can be configured from the GGSN to the
remote Intranet gateway. Figure 4-7 shows the network layout of the
ATM VPN model. It has the same PLMN and OAM configuration as the
Wireless ISP model.

Figure 4-7
ATM VPN network model
FTP SCS
Intranet/ISP
DNS
(APN CGF OAM
resolution)
SGSN
GGSN
Internet
PLMN
GTP tunnel ATM PVC
VLAN VPN model

The VLAN VPN is similar to the IPSec VPN, GRE VPN, and ATM VPN
in that a VPN is created on the GGSN and an Access Subscriber is
added to the VPN. However, in an VLAN VPN, the Access Subscriber
is created, made a member of the VPN and also is bound to a VLAN
tagged ethernet access connection. All traffic to this Access
Subscriber is forwarded out the ethernet connection with a VLAN tag.
Similarly, all traffic arriving with the corresponding VLAN tag is
presumed to have arrived from the Access Subscriber.

access modes. Both IP PDU and PPP PDU types are supported in this
model. If PPP PDU type is used, the PPP session is terminated on the
GGSN.
A single VLAN tagged ethernet connection can be configured from the

GGSN to a remote Intranet gateway. Figure 4-8 shows the network
layout of the VLAN tagged VPN model. It has the same PLMN and
OAM network configuration as the Wireless ISP model.

Figure 4-8
VLAN VPN network model
FTP SCS
Intranet/ISP
DNS
(APN CGF OAM
resolution)
SGSN
GGSN
PLMN
GTP tunnel VLAN tagged
GGSN VPRN model

The GGSN VPRN is similar to the IPSec VPN. However it provides a
means to expand a VPN to encompass multiple GGSNs. A mobile
subscriber who is a member of a GGSN VPRN can send data packets
to any other subscriber who is a member of the GGSN VPRN, even if
the other subscriber is connected to another GGSN within the VPRN.
This VPN model addresses the needs of VPNs which must support
very large numbers of subscribers and/or that require access to
multiple GGSNs for redundancy purposes.
Both the GGSN and remote GGSN are configured as members of a

VPRN group. An IPSec tunnel is automatically created between the
GGSNs which are members of the VPRN. This IPSEC tunnel
facilitates secure communication between VPN members hosted on
different GGSNs. Mobile subscribers may use any one of the GGSNs
within the VPRN, subject to the appropriate network provisioning.
Access Subscribers may be added to any of the GGSNs within the
VPRN using the IPSec, GRE or ATM PVC models described
previously.
This VPN model supports both static address and dynamic address as
well as providing both transparent and non-transparent access modes.
Both IP PDU and PPP PDU types are supported in this model. If PPP

PDU type is used, the PPP session is terminated on the GGSN and
the IP packets are forwarded to the VPRN.
For security reasons it is important that the packets exchanged

between a GGSN and a RADIUS server traverse only nodes within the
VPRN. The VPN Local Address is introduced to support the use for
sourcing RADIUS packets in a VPRN Context. The VPN Local
Address can be any IPv4 address and is configured per VPRN, per
GGSN.
Figure 4-9
GGSN VPRN network model
SCS Intranet/ISP
FTP
DNS
(APN CGF OAM
resolution)
SGSN GGSN
GGSN VPRN
PLMN
GGSN
GTP tunnel IPSec Tunnel
MPLS VPN model

A site is made up of one or more networks which gain access to the
MPLS network by way of a Customer Edge (CE) router connected to a
Provider Edge (PE) router. Two sites connected to different PEs can
talk over the backbone only if they have at least one common network.
The common network becomes the VPN. A “Virtual Routing and
Forwarding” (VRF) instance is associated with each site. A one-to-one
relationship does not necessarily exist between customer sites and
VPNs; a given site can be a member of multiple VPNs. However, a site
can be associated with only one VRF on the Provider Edge Router.
Each VPN is associated with one or more VRFs. In the context of the
GGSN, a site is defined as a collection of subscribers sharing the
same set of VPNs.

Within the Gi MPLS Network, the GGSN will primarily serve as a PE,
also called a Label Edge Router (LER), as seen in the following figure.
Figure 4-10
UMTS/GPRS MPLS network architecture
Site A Site B
(in VPN X) (in VPN Y)
CE
CE
MPLS Backbone
PE
PE
P Site C
(in VPN X)
GGSN,
acting as
a PE
P
CE
SGSN PE
RADIUS
DHCP Site D
P: Provider Router CE
Mobile Subscribers (in VPN Y)
belonging to VPN Y PE: Provider Edge Router
CE: Customer Edge Router
Mobile Subscribers
belonging to VPN X DHCP
RADIUS
Functioning as a PE router, the GGSN will have the following

characteristics:
• The GGSN is attached to one or more CEs. In this case, a CE is a
logical entity which represents mobile subscribers belonging to a
particular VPN.
• The GGSN is “attached to a VPN” if it serves a mobile subscriber
that belongs to the VPN.
• The GGSN’s role as a PE is fully administrated by the provider.
• The GGSN will run (internal) BGP with other PEs.
If all sites in a VPN are owned by a single enterprise, then the VPN is
a corporate “intranet”. If there exist sites that are owned by different
enterprises then the VPN is an “extranet”. From the protocol point-of-
view there are no differences. The two scenarios are achieved by
explicit provisioning.

VLAN eBGP VPN model

The VLAN eBGP VPN model combines the scalability of the BGP
routing protocol and traffic isolation and security of ethernet VLAN.
This VPN model is well suited to work with an existing MPLS core.
Figure 4-11
VLAN eBGP VPN model
BGP in the VLAN eBGP VPN configuration propagates reachability

information from the GGSN to the remote Customer Edge Router and
vice versa. It ensures that the routes for a given VPN are learned only
by other members of that VPN, allowing members of the VPN to
communicate with each other.
Attention: When BGP is used between different autonomous

systems (AS), the protocol is referred to as External BGP (eBGP).
Topology Details
• A VLAN VPN is configured on the GGSN. Ethernet and Gigabit
Ethernet ports can be used
• BGP is turned on for the VPN.
• Determine the BGP AS number for the MPLS core.

• Configure the BGP AS number for the VPN on the GGSN to be

different than the MPLS core
• Configure the remote Customer Edge router similarly as the GGSN
• Advertise a default route on the Customer Edge router through the
VPN
Wireless services deployment 4
In addition to the different network models, the GGSN also supports
deployment of a number of wireless services. The following sections
describe some examples of the service deployments.
WAP Service
The WAP service on the GGSN can be deployed in one of the two
ways shown in Figure 4-12:
• When GGSN RADIUS Accounting is enabled for an APN, the

RADIUS Server acts as a proxy between the GGSN and the
Application Server for the WAP service deployment. In this
configuration, the Application Profile is not required. All RADIUS
messages are forwarded to the Application Server from the
RADIUS Server. This is the supported configuration for WAP on
APNs configured for aggregation.
• If the GGSN RADIUS Accounting is disabled for an APN, the
Application Profile is used for the WAP Service deployment. The
WRAP messaging carries the WAP service information between
the GGSN and the Application Server.
Figure 4-12
WAP service deployment models
GGSN
APN 1 RADIUS RADIUS RADIUS

Server Application
w/ RADIUS
Server
Account.ing
RADIUS
APN 2
WRAP Application Application
w/o RADIUS
Accounting Server Server
Static RADIUS address allocation service

For the deployment of static RADIUS address allocation service, the
RADIUS Server must be a RADIUS Authentication Server. It does not

have to be a proxy for an Application Server for WAP service nor a

RADIUS Accounting Server. This is because the static RADIUS
Address is not required to receive a RADIUS STOP message to
release the address. Figure 4-13 illustrates this configuration.
Figure 4-13
Static RADIUS address allocation service deployment
RADIUS
Accounting
DNS Server
SGSN
GGSN
Gn Gi Service
PLMN Network
Application
Server
RADIUS
GTP tunnel Authentication
Server
Dynamic RADIUS address allocation service

Dynamic RADIUS address allocation service on the GGSN can be done
in the following ways based on the WAP service deployment and the
RADIUS Accounting status.
• The RADIUS Server that provides the address allocation function
may act as a proxy for the Application Server. WAP service
messages are forwarded to the Application Server from the
RADIUS Server. A RADIUS STOP message results in the release
of the dynamic IP address on the RADIUS Server.
• When GGSN RADIUS Accounting is enabled, the RADIUS
Accounting messaging can serve to release the dynamic IP
address if the RADIUS Accounting Server is the one that provides
the address allocation function. The WAP service is not required in
this configuration and the RADIUS STOP message for the RADIUS
Accounting results in the release of the dynamic IP address on the
RADIUS Server. This is the supported configuration for dynamic
RADIUS addressing on APNs configured for aggregation.

Figure 4-14 illustrates the configuration for dynamic RADIUS address

allocation service.
Figure 4-14
Dynamic RADIUS address allocation service deployment
CGF
SGSN
GGSN
Gn Gi Service
PLMN Network
Application
Server
RADIUS
GTP tunnel Server

5-1
IP services 5
Overview 5
This chapter describes Nortel Services Edge Router 5500 IP services
that are supported on the Nortel GGSN. The IP services mentioned
here apply only to the subscriber’s data traffic on the Gi interface. For
information on provisioning these IP services using the SCS GUI, refer
to Nortel Services Edge Router 5500 Provisioning Service Policies
and GPRS/UMTS Nortel GGSN Provisioning Procedures (411-5221-
927).
The following IP services are available on the GGSN. These IP services

include the IP service policies inherited from the Nortel Services Edge
Router 5500 (SER 5500) and those developed for GGSN functionality:
• Firewall
• Traffic Policing
• Traffic Shaping
• Policy-Based Forwarding
• Web Steering
• Personal Content Portals
• DiffServ Marking
• Anti-Spoofing
• Content Based Billing (CBB)
• Event Based billing (EBB)
• Node and Management ISP services
• Wap 1.2/2.0 and HTTP 1.1 Redirection
• Traffic Performance Optimizer (TPO) Interworking
• Content Filtering
• Flow Management

5-2 IP services Copyright © 2000–2008 Nortel Networks
The service policies of the IP services can be applied to the subscriber’s

data traffic through the following mechanisms:
• The service policies can be provisioned in the Subscriber Template
that is associated to an APN. When subscribers are connected to
that APN, the service policies are applied.
• The service policies can be added to a Service Profile. The Service
Profile can be associated to a QoS level in the GGSN QoS Profile.
When subscribers create a PDP session with that QoS level, the
service policies are applied.
• A Service Profile attribute can be returned from the RADIUS Server
during subscriber authentication to specify which Service Profile is
used in the PDP session. The service policies in that Service
Profile are applied when the Service Profile attribute is returned.
• A Service Profile attribute can be returned from the prepaid server.
Policy merging 5
An IP service policy is a generic way of referring to an IP service which
has been previously configured on the GGSN. For example, a firewall
policy is an IP service policy. An IP service profile is a collection of
specific IP service policies. For example, a profile may consist of a
CBB policy and a firewall policy.
Policy merging means the rule to select the IP service policy to be

applied to a PDP session. This occurs when there are multiple sources
(such as GGSN QoS Profile, Subscriber Template, SCP and RADIUS
Server) providing the IP service policy to a PDP session. It only
permits the sources to identify a previously configured IP service
policy for use in a PDP session. Policy merging works by identifying all
the offered IP service policies from each source. It then prioritizes
each IP service policy, selects the highest precedence policy for each
IP service and applies the final mixture of IP services to the PDP
session.
Following are the IP service policies derived from different sources

ranged from the highest precedence to the lowest precedence:
• IP service policies in the IP Service Profile from SCP
• IP service policies in the IP Service Profile from RADIUS Server
• IP service policies in the IP Service Profile from GGSN QoS Profile
• IP service policies in the IP Service Profile and individual IP service
policies from Subscriber Template
For example, if both SCP and RADIUS Server identify IP Service

Profiles containing CBB policies, the CBB policy supplied through the

IP services 5-3
SCP is selected and applied to the PDP session. It is important to

understand that the contents of the two CBB policies are not merged;
one policy is selected above the other because the source has higher
precedence. The other example is both SCP and RADIUS Servers
identify IP Service Profiles. If the SCP profile contains a CBB policy,
but no firewall policy and the RADIUS Server profile contains both,
then the CBB policy selected is the one identified by SCP and the
firewall policy selected is the one identified by RADIUS Server.
If two or more Service Profiles are returned from a single source (for
example, from a RADIUS Server), there must not be any overlap in the
IP service policies identified by the profiles.
Both SCP and RADIUS Server may return more than one IP Service
Profile. In such case the first profile identified from SCP has the
highest precedence. A maximum of six IP Service Profiles can be
merged. If more than six profiles are supplied, all those beyond the
first six are ignored. If the SCP, RADIUS, or Personal Content Portal
server returns an invalid Service Profile, the PDP context is taken
down. A Service Profile is invalid if it can not be found within the
Service Policy Manager.
If the CBB policy or the service profile contributing the CBB policy is
obtained from the subscriber template, GGSN sends subscriber
template name prefixed with a special character to the prepaid server.
If prepaid server returns the same name in the response message,
GGSN ignores the Service Profile and allows the PDP context to
establish as normal.
An Update PDP Context Request message can cause a new IP

Service Profile to be applied to the PDP session. If the IP Service
Profile contains an IP service policy already applied to the PDP
session from the SCP or RADIUS Server, the IP service policy from
the GGSN QoS Profile is ignored.
An operator can edit an IP service policy or a Service Profile at any

time. When a policy is modified, changes are effective immediately for
all PDP sessions using the policy. When a Service Profile is modified
by either adding or deleting a policy, the changes do not take effect on
the active PDP sessions.
IP Services for IP in IP 5
IP Services for IP in IP enables the Nortel GGSN to apply certain IP
services to IP in IP encapsulated packets. Such encapsulation is used
by the Mobile IP (MIP) protocol. The enhancements permit the GGSN
to apply IP services based upon the inner IP header and payload,

rather than the outermost IP header. This functionality permits the

application of the following IP Services when a mobile subscriber has
established a MIP tunnel to a Home Agent (HA) located on the Gi side
of the Nortel GGSN.
• Content Based Billing

• Service Redirect
• Policing
• Shaping
• Anti-Spoofing
• Diffserv Marking
• Policy Based Forwarding
• Content Filtering
• Event Based Billing
This functionality implements the Nortel GGSN portion of a WLAN/
GPRS/UMTS integration solution. The mobile device utilizes a mobile
IP client to access a Home Agent (HA) located on the Gi side of the
Nortel GGSN. Mobile IP is used to provide seamless access as the
mobile device moves between WLAN and GPRS/UMTS access. The
mobile IP client allows the mobile device retain the same IP address
as it moves from WLAN access to GPRS / UMTS. The GGSN applies
IP services based upon the GGSN assigned mobile subscriber IP
address and the final destination host IP address. The GGSN does not
consider either the HA IP address or the IP address assigned to the
Mobile IP client when applying IP services to encapsulated packets.
This functionality is consistent with the operation of IP services on the
Nortel GGSN when IP-IP tunnelling is not in use.
The following IP services are not supported in combination with IP-in-

IP tunnels: TPO Interworking, Captive Portal and Web Steering. These
IP services must not be applied to a subscriber with the IP-in-IP
functionality active. Other IP services which are not supported for non-
tunnelled traffic on the GGSN are also not supported for IP-in-IP
tunnelled traffic. Also GGSN does not act as a multicast router for IP
multicast packets (IGMP) encapsulated within an IP-in-IP tunnel.
Tunnelled multicast packets are forwarded through the GGSN based
on the destination IP address of the encapsulating IP header. IP
Services for IP in IP requires the IP-in-IP client and server to utilize
Tunnel MTU negotiation. This does not support fragmentation of the
outer IP packet of the IP-IP tunnel. When an inner IP packet is
fragmented, it may not be recreated with the exact same
fragmentation when the fragments are forwarded by the GGSN. The
GGSN does insure the fragments meet the tunnel MTU requirement.

IP services 5-5
Firewall 5
Firewalls prevent unwanted or unauthorized traffic from leaving or
entering a subscriber’s site. The services are created based on
policies that are defined by mapping actions to pre-defined addresses
and services. Firewall addresses can be subscriber address or
address ranges, services can be ports or protocols, and actions can
include packet accept, reject or drop.
When subscriber sends the first packet to the IP network, a semi-

permanent uplink flow is created. The created uplink flow must satisfy
the firewall rule. In the same time, a predicted downlink flow is created
for the response packets from the IP network. If a response packet is
received in 60 seconds, a semi-permanent downlink flow is created for
it. At this point, two-way communication is established. Otherwise, the
predicted downlink flow will be removed in 60 seconds and only one-
way communication is established. After predicted flow time-out,
subsequent response packet from the IP network is viewed as a new
packet and it is required to satisfy firewall rule in order to establish
another flow.
Traffic Policing 5
The purpose of a Traffic Policing policy is to restrict the data
throughput coming from the subscriber side (from the Gn interface to
the Gi interface). It protects the IP network from traffic in excess of the
subscriber’s contracted rate. On the GGSN, the Traffic Policing policy
can also restrict the data throughput coming from the Internet (from
the Gi interface to the Gn interface) for the IPSec VPN model, GRE
VPN model, and ATM VPN model. This scenario occurs when a Traffic
Policing policy is configured for the access connection on the Gi
interface. The policing function relies on the results of the DiffServ
marking in conjunction with bandwidth limits to set different packet
drop priorities.
Figure 5-1 illustrates the way that the parameters of a policing policy
work for a Single-Rate Three-Color Marker (srTCM).
To define srTCM policing policy, the Committed Information Rate

(CIR), Committed Burst Size (CBS) and Excess Burst Size (EBS) must
be set for each DiffServ CodePoint (DSCP)/IP precedence - CS7,
CS6, EF, Assured Forwarding (AF1 - AF4), and Default Forwarding
(DE). Then, an action must be specified for each category (green,
yellow or red). A packet is marked green if it doesn't exceed the CBS,
yellow if it does exceed the CBS but not the EBS, and red otherwise.
It is also possible to define a Two-Rate Three-Color Marker (trTCM)

policing policy. In this case, the parameters that need to be defined

would be Committed Information Rate (CIR), Committed Burst Size

(CBS), Peak Information Rate (PIR) and Peak Burst Size (PBS). A
packet is marked red if it exceeds the PIR. Otherwise it is marked
either yellow or green depending on whether it exceeds or does not
exceed the CIR.
Figure 5-1
Policing parameters for single-rate three-color marker
Traffic Rate
Red
Excess Burst Size
Yellow
Committed Burst Size
Green
Committed Rate
Time
The potential actions - none, allow (pass packet through normally),

setting (setting the IP precedence or the drop precedence - low,
medium or high) or drop (dropping the packet entirely) for each DSCP/
IP Precedence are listed in the following table.
Table 5-1
Actions on DSCP/IP Precedences
DSCP/IP Red Yellow Green

Precedence
CS7, CS6, EF, DE Drop/allow Drop/allow None
AF4, AF3, AF2, Drop/setting Drop/setting None/setting

AF1

IP services 5-7
Traffic Shaping 5
Traffic Shaping allows overall rate limits and per connection rate limits
to be applied to traffic coming from the Internet. On the GGSN, the
Traffic Shaping can also apply to the traffic coming from the
subscribers for the IPSec VPN model. This scenario occurs when
Traffic Shaping is configured for the access connection on the Gi
interface.
Two traffic shaper types - Flow shaper (rule-based) and AF shaper

(DiffServ AF-based) can be selected in GGSN Traffic Shaping policy
configuration.
A Flow shaper (rule-based) traffic shaping policy is a set of rules that

are defined on a per-flow basis. A flow is defined by a source address,
destination address and service type.
For each flow, the Rate Weight, Rate Limit, Per Connection Rate Limit,
and Queue Length must be defined. These parameters take effect only
during times of congestion.
• Rate Weight - determines what percentage of the available
bandwidth that a given traffic type (for example, Web traffic) can be
used during times of congestion.
• Rate Limit - the maximum bandwidth available to a given traffic
type across the link.
• Per Connection Rate Limit - the maximum bandwidth available to
a given traffic type for a single connection.
• Queue Length - the maximum queue length (packets) available to
a given traffic type across the link. The maximum queue length can
not be exceed 128 (packets).
An AF shaper (DiffServ AF-based) traffic shaping policy is a set of

DSCPs that are included as CS7, CS6, EF, AF4-AF1 and DE codepoints
(which are more than the AF4-AF1 codepoints). For each codepoint, the
Weight, Rate Limit, and the Queue Length must be defined. These
parameters take effect only during times of congestion.
• Weight - determines what percentage of the available bandwidth
that a given traffic type (e.g. Web traffic) using the codepoint can
be used during times of congestion.
• Rate Limit - the maximum bandwidth available to a given traffic
type across the codepoint.
• Queue Length - the maximum queue length (packets) available to
a given traffic type across the codepoint. The maximum queue
length for all codepoints can not be exceed 128 (packets).

Policy-Based Forwarding 5
Policy-Based Forwarding allows traffic from subscribers to be
redirected based on a set of policies or rules. It essentially forwards
packets of matching conversations (flows) out the interface chosen by
performing a route lookup on the IP address specified in the matching
rules action. The destination of the packet must be only a single hop
away from the current location where the packet is being forwarded.
Defining a Policy-Based Forwarding policy requires specifying a flow

(defined by a source address, destination address and service type),
and then specifying an action for that flow type. The action can be
either default (do nothing) or forwarding, which then requires a
forwarding IP address to be defined.
VPN + Internet is not supported.
Web Steering 5
Web Steering service provides capability for HTTP targeted traffic to
be redirected to a proxy cache server at port 80 without the knowledge
of the web client. This policy has rule-based format as other policies
that can specify which IP conversations should be redirected and
which IP conversations should continue to be directed to the original
port 80. Each HTTP connection that matches a rule is redirected to
one of the servers listed in the corresponding IP-farm object. The IP-
farm object has a list of IP addresses that refer to the proxy cache
servers.

IP services 5-9
Personal Content Portals 5

A Personal Content Portal (PCP) intercepts a subscriber’s HTTP request
and redirects the subscriber to a URL on the Personal Network Portal
website. Several parameters must be set in order to define the captive
action:
• URL - indicates the URL of the page that will handle HTTP
requests for redirection to the PCP site.
• Session Timeout - defines the length of time the GGSN must wait
before it changes the session from non-captive to captive mode.
This allows personal portal web site to send new information to
subscribers after a certain length of time.
• Captive IP Address - indicates the site to which packets should be
redirected.
• Controller IP Address - indicates a controller that is enabled to
send messages to the GGSN in order to switch subscribers from
captive to non-captive mode.
Some applications of the PCP service are delivering a customized
“splash” page to a customer when they first log into a network, and the
ability to push advertising content to a subscriber who is using a free
Internet access provider. These scenarios also require specific
functionality to be developed for the PCP server.
After the PDP session is initialized with PCP service policy, a new
service profile can be sent from the PCP server upon successful
authentication. The existing service profile can be replaced by the new
set of services for the PDP session. If the PCP service policy is not
included in the new service profile, the captive portal function will not
be enabled for the PDP session. To ensure that PDP sessions can be
re-captured based on the idle timeout value, it is recommended that
the service profile sent from the PCP server include the same PCP
service policy used during PDP session activation.
DiffServ Marking 5
DiffServ Marking allows scalable service differentiation within a
network. There are four AF classes - 1 (worst) to 4 (best) - which
describe the relative priority of the traffic. Within each AF class, there
are three different levels of Drop Precedence (DP) - 1 (best) to 3
(worst) - which define how likely the traffic will be discarded if the
network experiences congestion or if the subscriber exceeds the traffic
contract. In addition to the AF/DP 12 classes of service, there are EF
(Expedited Forwarding), CS7 (Class Selector 7), CS6 (Class Selector
6), and DE (Best Effort Forwarding or Default Forwarding) classes of
service available on the GGSN. Therefore, DiffServ Marking can mark
the IP packets for 16 different classes of service. It is also possible to

“alias” an IP packet to have a certain DiffServ marking internally to

GGSN. This allows the packet to be treated as if it had a certain
marking without actually changing the contents of the IP header.
DiffServ marking can be used in both directions (exiting both the Gi

and Gn interfaces). However, since the IP packet is encapsulated
within a GTP tunnel on the Gn interface, DiffServ marking would
essentially be useless here. For those PPP sessions that pass through
the GGSN, DiffServ marking is not supported on the Gi interface.
Anti-Spoofing 5
Anti-Spoofing ensures protection from Internet attacks by preventing a
malicious subscriber from masquerading as a third party, or a
malicious third party from masquerading as a subscriber. Security is
achieved by filtering arriving traffic based on the expected source IP
address of the traffic.
The Anti-Spoofing policy ensures that packets received at the Gi

interface do not have a source IP address identical to the IP address
of the subscriber to which the packet is being sent. If the source IP
address of the packet matches the destination subscriber IP address
in the packet, then the packet is dropped. The default policy for the
Anti-Spoofing can not be modified.
The other type of Anti-Spoofing policy is Ingress Anti-Spoofing (i.e.

from Gn interface to Gi interface). This policy ensures that packets
received at the Gn interface have the correct source IP address. The
source IP address must be that of the subscriber which sent the
packet. If the source IP address in the packet is other than the
expected value, the packet is dropped. The default policy for ingress
anti-spoofing can not be modified.
WAP 1.2/2.0 and HTTP 1.1 Redirection 5

Attention: WAP 2.0 is a dual stack comprising of WAP 1.2 and
HTTP. This section is intended as a solution for the WAP 1.2
protocol stack. The solution for the HTTP protocol stack was
described earlier. There is no “WAP 2.0” protocol stack. It is simply
a specification of the dual stack comprising these two protocols.
WAP Redirection is achieved through WAP protocol messaging,

triggered by a WSP Get/Post message in the uplink direction. When a
WSP Get/Post is received, the Nortel GGSN replies to the incoming
WSP message with a WAP byte encoded HTTP 1.1 Status 302
message (Status 302: See Other). The location field of the message
contains the URI that was received on the Nortel GGSN from the
Prepaid Server via a Top-Up server. This message is then be sent out

IP services 5-11
the Gn interface. The original WAP Request to the WAP Gateway, will
be dropped. The WAP browser will then issue a new transaction to the
URI in the location field of the received WSP Reply. The Handset must
be able to receive the HTTP1.1 Redirect messages.
After the Nortel GGSN issues a WSP Reply for the original WAP
request, any other subsequent message from the Client or Server
belonging to that transaction, will be dropped on the Nortel GGSN.
The first messages of any Connection-oriented WAP flow are a

Connection Sequence. This connection sequence currently receives
the Default WAP rate. For redirection of Connection Mode WAP 1.2,
the user will have to have available funds (or free) assigned to the
Default WAP rate. If not, the connection can not be established, and a
Connection-oriented WAP device can not issue a WSP message that
can be redirected.
WAP Connection-oriented Mode

The WTP layer provides two optional abilities that need to be handled.
Segmentation and Reassembly (SAR) and WTP Layer Concatenation.
Service Redirect Segmentation and Reassembly Handling

The Nortel GGSN follows WTP Specification [WAP-224-WTP-
20010710-a] for Segmentation and Reassembly. Upon receiving a
WTP Invoke indicating subsequent messages, the Nortel GGSN will
send a WTP Ack acknowledging the receipt of each packet group.
When the final message of the packet sequence is received, the Nortel
GGSN will issue a WSP Reply Status 302.
Service Redirection is not applied in the middle of a Segmented

Transaction, i.e. If the first Invoke was not issued upon a denied
coupon and Service Redirect was not applied, subsequent Segmented
Invokes will not be redirected.
Service Redirect WTP Concatenation Handling

Concatenation is where one or more WTP PDUs may be contained in
one datagram. The concatenated packets must be using the same
bearer and is commonly used to send an Acknowledgement with a
new Request. The Nortel GGSN supports up to three WTP PDUs
concatenated together at one time.
If the WSP Get/Post is contained within a concatenated packet, A

WSP Reply will be issued for that transaction, to the WAP browser.
The entire original packet will then be dropped. The Nortel GGSN will
depend on the associated WTP PDUs in the packet to be re-
transmitted by the WAP device.

Similarly, a WTP PDU belonging to a transaction that is redirected will

be dropped by the Nortel GGSN. If that PDU is part of a concatenated
packet, the entire packet will be dropped. The Nortel GGSN will
depend on the associated WTP PDUs in the packet to be re-
transmitted by the WAP device.
WAP Connection-less Mode

The behavior of the Nortel GGSN is unchanged from WAP
Connection-oriented Service Redirection. However, WAP Connection-
less protocol does not involve a WTP layer. Only the WSP layer is
involved. Therefore there is no need for the handling of Segmentation
and Reassembly (SAR) and WTP Layer Concatenation.
WAP Packet Rating

The original WSP Get/Post is be dropped by the Nortel GGSN. This
packet is not rated. The Nortel-generated WSP Reply is not rated. Any
associated packet that may be issued as a resultant of the redirected
message is dropped on the Nortel GGSN and is not rated.
The new transaction issued by the WAP Browser in response to the

Location Field of the WSP Reply (i.e. The Top-Up server), is rated
according to the operator provisioned scheme (i.e. Free, Default, or
Specially Rated according to the URI of the Top-Up site).

IP services 5-13
Figure 5-2
WAP Redirection (Connection-Oriented and Connection-less calls)
Subscriber GGSN HTTP Gateway

WSP Connect
(connection-oriented only)
WSP Connect Reply

WTP Ack
WSP Get/Post
URL=wap.yahoo.com
TID = x
WSP Reply (Status 0x32)

Location: www.topup.com
TID = x
WTP Ack
TID = x
WSP Get
URL www.topup.com
TID = x+1

Figure 5-3
WAP Redirection (Concatenated PDU example)

WSP Connect
TID=y
WSP Connect Reply

TID=Y
WTP Ack, WSP Get/Post

URL=wap.yahoo.com
Ack TID=y
Get TID = x
WSP Reply (Status

0x32)
TID = x
WTP Ack, WSP Get

URL www.topup.com
Ack TID x
Get TID = x+1
WSP Connect Reply

Tid=y
WTP Ack, WSP Get

URL www.topup.com
Ack Tid=y
Get Tid= x+1

IP services 5-15
Figure 5-4
WAP Redirection (SAR Example)

WTP Invoke
TID=x, Group 1
WTP Ack
TID=x, Group 1
WTP Segmented In-

vokes
TID = x, Group 2
WTP Ack
TID=x, Group 2
WTP Segmented In-

vokes
TID = x, Group 3
WTP Ack
TID=x, Group 3
WTP Segmented Invoke

TID = x, Last Packet of message
WSP Reply (Status 0x32)

TID = x
WTP Ack
TID = x
WTP Ack, WSP Get

URL www.topup.com
Ack Tid=y
Get Tid= x+1

HTTP 1.1 Redirection
HTTP Redirection is a simple messaging from the GGSN to the Mobile.

The Redirection is triggered via an HTTP GET/POST message from
the subscriber in the uplink (Gn -> Gi) direction. When received on the
GGSN, it will drop this packet to keep it from going out the Gi interface
to the HTTP Server. GGSN will then compose its own Reply to this
message in the form of an HTTP Redirect message (Status 302) and
route the packet back to the mobile through the Gn interface. When the
mobile receives the packet, it will assume it is from the HTTP Server
and Redirect based upon the URI that is supplied in the location field.
This URI is supplied to the GGSN from the Real Time Charging Server
(RTCS).

IP services 5-17
Content Based Billing 5

Content Based Billing (CBB) permits policies to be defined that
categorize IP flows into specific categories for charging purposes.
Each charging category may receive different treatment from the
billing system. The billing system may then apply unique charging
formulas to each category, permitting the operator to deliver special
rates for specific content. Special rates may include free transport of
packets to attract subscribers to a particular website, for example. Up
to 65,534 different categories may be provisioned.
Content Based Billing supports both postpaid and prepaid subscribers

with equivalent functionality. Different terminology is used to refer to
postpaid special rates versus prepaid special rates. In postpaid billing
each special rate category is referred to as a content type ID. In
prepaid billing each special rate category is referred to as a coupon ID.
Content Based Billing is not supported with L2TP tunneling.
The uplink and downlink byte count for each charging category is
separately reported to the billing system. For the purposes of CBB,
uplink is defined as packets sent by the mobile toward the Gi interface
and downlink consists of traffic sent toward the subscriber.
Content Based Billing supports both GTP accounting and RADIUS

accounting for postpaid billing. Support for GTP Accounting is provided
by using proprietary management extensions to include the byte
counts and the time usage for each special rate category used by a
subscriber into the standard G-CDR record. Refer to “GTP’ Charging
Protocol” for detailed information. Support for RADIUS accounting is
provided via the definition of a Vendor Specific Attribute (VSA) to
contain the uplink and downlink byte counts as well as the time usage.
For detailed information, refer to Nortel GGSN RADIUS Interface
Guide (411-5221-928).
Prepaid Service is also supported in combination with Content Based

Billing. The CBB service retrieves a separate special rate coupon from
the SCP for each special rated service accessed by the mobile
subscriber. It is possible for a mobile subscriber to have several
prepaid coupons active at any point in time. The CBB service
manages subscribers’ active coupons to prevent fragmentation of their
prepaid balance. Prepaid coupons may also be assigned a time or
volume based lifetime by the SCP.
CBB criteria and the associated rate or coupon IDs are stored on the
GGSN as an IP service policy. Many CBB rules can be applied to
subscribers, enabling support of many special rated sites or services.
When a subscriber accesses a site or service which matches a CBB

policy rule, the packet flow is marked with the special rate. As packets
are sent or received in response to the access, they are marked with
the special rate.
Content Based Billing on the GGSN is based on the destination IP

address, URL, protocol, or some combination of these fields within the
subscriber packets. The filtering criteria is provisioned through SCS.
The GGSN collects both a cumulative byte count and individual byte
counts for each special rate category. Any packets which do not match
any of the provisioned CBB filter policies are counted only in the
standard uplink or downlink count of the CDR. Packets which match a
CBB filter policy are counted both in the special rate ID/coupon
assigned for the filter policy and in the total count within the CDR.
If an access to a special rated site terminates prematurely, the byte

count for the uploaded/downloaded portion is recorded. Content
Based Billing does not determine whether a transaction has completed
successfully.
Content Based Billing can support any simple application protocol

which requires only an IP address or a well known port number. Of the
complex application protocols that require more than one flow per
conversation, Content Based Billing supports FTP, HTTP and WAP. To
apply special rates to HTTP requests that are redirected, either
through the Web Steering or the Personal Content Portals, the
redirected URL must be provisioned in the Content Based Billing
policy through the SCS GUI.
When filtering on simple protocols (such as instant messaging),

Content Based Billing captures and rates every packet of a flow at the
provisioned special rate. However, for complex protocols such as
HTTP using URL based filtering, the initial connection sequence
packets are captured at the default rate unless the CBB filter is
provisioned to accumulate the byte count for the initial packets and
associate it with the rate assigned the URL in the first HTTP request.
All subsequent packets within the flow receive the special rate
associated with the URL. If no HTTP request follows the initial
connection sequence, then the initial overhead packets associated
with the setting up the TCP/IP session to support the HTTP request
are captured at the default rate. Because these TCP/IP overhead
packets do not contain the URL of the web page to be retrieved, they
cannot receive the special rate associated with the web page. Once
the URL is recognized, all subsequent packets within the flow receive
the special rate associated with the URL.

IP services 5-19
The CBB counts are sent from SSC to CMC every time Fault Tolerant
Limit is reached in order to minimize the amount of information lost
due to SSC card failure.
If more detailed CBB information is needed, please contact Nortel

personnel for CBB technical document.
Content Based Billing supports the following functionality:

• Provisioning of Source IP address. Previous releases permitted
only a wildcard entry in the Source IP address field of a rule. The
Source IP address field may now be provisioned with an IP
address, network, set of hosts, etc. This extension permits
differentiation of flows originating from the network toward the
mobile subscriber vs. those originated by the mobile subscriber
toward the network. A flow between a mobile subscriber and a host
can now be rated differently based upon which endpoint initiated
the flow.
• Provisioning of separate uplink and downlink rates for the already
existing traffic types
• Provisioning of default uplink and downlink rates for HTTP. Default
rates are applied to a flow when no URL match is found. Previous
releases applied full rate to unmatched URLs. The rate applied to
unmatched URLs may now be provisioned.
• Provisioning of full rate for all protocol types. The full rate may now
be provisioned as the desired rate when a rule or URL match
occurs.
• Support of WAP Connection Mode and WAP Connectionless mode
filtering. Special rating can now be applied to WAP1.1 and WAP1.2
flows, including URL matching. Both WAP connectionless and
WAP connection-oriented flows may be inspected. Multimedia
Messaging Service (MMS) traffic may be rated differently than
other WAP traffic types.
• Provisioning of a URL list for the WAP Push Service. A WAP 1.2
Push message carrying an MMS Notification Indicator will attempt
to match the Content Location field, of the MMS Notification
Indicator, to the URL list provisioned within the Service Object. A
successful match will result in the MMS Notification Indicator being
rated according to provisioning. An unsuccessful match will receive
the MMS default rate.
• Separation of postpaid and prepaid CBB content type IDs. Different
rates may be applied to a given site depending on whether the
subscriber accessing the site is a prepaid or postpaid customer.

• Dramatic increase in the number of unique rates supported. Up to

65,535 different rates may be assigned.
• Support for up to 1000 URLs per CBB policy.
• Support for up to 750 rules per CBB policy.
• Support for up to 1000 CBB policies per ISP, 63,000 CBB policies
per GGSN.
• Support for wildcard within URL strings. The “*” character may be
used to construct wildcard URL strings which match many possible
requests. The wildcard may be embedded anywhere within the
URL string, and more than one wildcard may be used per URL
string. The first “/” character separates the domain name and the
path portion of the provisioned URL. URL matching is performed by
individually matching domain name and the path portion. If the
provisioned URL does not contain “/”, the URL matching is
performed by matching for empty path. For example, provisioned
URL “www.yahoo.*” matches URL “http://www.yahoo.com” and not
URL “http://www.yahoo.com/test.html”.
Attention: If there is an exact match URL rule (for example,
217.12.3.11:*/*) listed after a catch-all wildcard URL rule (for
example, *:*/*), a URL can still match the latter URL rule. URL
matching is performed separately for the hostname and path
portion of the URL rule. During URL matching, the list without
wildcards in the host is searched first. If no match is found then the
wildcard list is searched. To avoid confusion, the user should
provision the */*:* as the last URL in the CBB policy.
• The GGSN CBB permits explicit port numbers within the

provisioned URL patterns. The GGSN can differentiate between
and assign two different rates to two URLs such as the following:
— http://wap.someoperator.com:1999/index.html
— http://wap.someoperator.com:2000/index.html
• Support for case-dependent comparisons of URLs. A check box to
choose case-sensitive comparison for the path portion of the URL
is introduced. The default is to perform case-insensitive
comparison. A case-sensitive comparison is performed if the box is
checked.
• Support for case-insensitive comparison of HTTP methods.
• Support for correctly rating the pipelined and fragmented HTTP
requests and their responses.

IP services 5-21
WAP filter overview

The WAP filter operates on the WAP1.1 and WAP1.2 protocol stacks.
It supplies functionality that supports the application of special rates
based upon the URL accessed or the type of operation - web access
vs. MMS. The WAP filter does not support WAP2.0. Because WAP2.0
is effectively HTTP traffic, the HTTP filter can be used to apply special
rates to WAP2.0 traffic.
WAP overview
WAP has been designed using current Internet standards such as
HTML, HTTP, XML, TCP, IP, and UDP as its basis. The main goals in
developing this new protocol were to optimize performance in low
bandwidth wireless networks and flexibility to work with small screens
of different shapes as typically found on mobile devices. Bandwidth
requirements are reduced by transferring all information in binary
format and not as plain text as in similar protocols like HTTP. Header
information is optimized to be small and the page markup language
supports making applications small and flexible.
WAP defines a specific protocol stack that operates between the WAP
Devices and the WAP. The various layers of this protocol stack are
described below.
Wireless Application Environment (WAE)

The WAE defines the user interface and operating environment of the
mobile device. WAE contains the Wireless Markup Language (WML).
The WAE layer is neither visible nor relevant to the GGSN.
Wireless Session Protocol (WSP)

The WSP layer links the WAE to two session services- one connection
oriented and operating above the Wireless Transaction Protocol, the
other connectionless and operating above the Wireless Datagram
Protocol. WAP CBB inspects the contents of the WSP Layer to
determine the transaction type (WAP vs. MMS) and/or URL.
Wireless Transaction Protocol (WTP)

The WTP protocol runs on top of a datagram service such as User
Datagram Protocol (UDP) to provide a simplified protocol suitable for
low bandwidth mobile stations. WAP CBB inspects the WTP Layer to
track WAP transactions via their Transaction Identifier (TID). By
tracking transactions only the first message of the transaction need be
rated; all subsequent messages are quickly rated based upon their
TID.

Wireless Transport Layer Security (WTLS)

WTLS incorporates security features that are based upon the
established Transport Layer Security (TLS) protocol. WAP CBB
cannot filter packets encrypted by the WTLS layer; the packet contents
are not available for inspection. The Filter by Other CBB service may
be used to assign a special rate to WTLS encrypted traffic. However, it
is not possible to rate WTLS encrypted traffic based upon URL
accessed.
WDP/Bearer
WDP is a general datagram service defined by WAP. For GPRS and
UMTS networks WDP is defined to be UDP.
WSP connection-mode and connectionless session services

WSP has two modes of service: connection oriented and
connectionless. In connection-mode, a session must first be set up;
the exchange of WSP Connect and ConnectReply happen before any
WSP Get, Post, or Push can occur. The session can also be
suspended, resumed or disconnected. In connectionless mode, no
session is required before the WSP Get, Post, or Push PDU can be
issued. The connection-mode and connectionless services each have
been assigned well know port numbers.
WAP and MMS

In the MMS, the WAP protocol stack is used to transfer multimedia
messages between the mobile terminal and MMS Proxy-Relay. The
MMS Proxy-Relay is the network entity that supplies access to the
subscriber’s e-mail account. It supports notification of newly arrived
messages, viewing of messages in the mailbox, creation of new
messages in the mailbox, etc.
WAP filter
The WAP filter sniffs the packet stream flowing between the WAP
enabled mobile and a WAP gateway. It compares each packet to the
rules provisioned in the Filter. Each packet is assigned to a rate
category, whether special rated or full rate. The bytes transferred for
each packet are charged at the rate category to which that packet has
been assigned.
The WAP filter is similar to the HTTP filter in that it contains two levels
of filtering. As with HTTP the first level filter is the basic GGSN Source/
Destination/Service tuple. The second level filter is a URL filter. In
addition, the WAP filter supports the concept of default rates for WAP
and MMS requests that do not match a provisioned URL.

IP services 5-23
The first level Source/Destination/Service filter is not overly significant

when working with the WAP filter. This is because of the simple fact
that all WAP traffic for a given subscriber flows between the mobile
terminal and a single WAP gateway. Put another way, it all has the
same destination, regardless of the user’s request (web vs. MMS), or
the web page being viewed. Hence for WAP the first level filter is
provisioned only to capture the WAP traffic. It is possible to have
multiple Filter by WAP rules within a policy, and to assign different
rates to WAP traffic based upon the WAP gateway used, but seems an
unlikely occurrence.
The second level of matching compares the URL requested by the

mobile subscriber against a provisioned list of URLs within the Filter by
WAP policy. If a match occurs, a provisioned special rate is charged.
Case sensitive comparison for the path portion of the URL is
supported.
The URLs provisioned by the service provider are partial URLs. They
must include the hostname (or server IP address), and may include
one or more levels of the directory path of the complete URL. The
complete URL including the filename cannot be provisioned. In
addition to URL matching, the WAP filter includes the concept of
default rates for both WAP and MMS traffic. A default rate is applied to
a transaction when the URL for that transaction does not match any of
the provisioned URLs. The default rate can be any of the permitted
rates; a special rate or full rate. The determination whether to apply the
WAP or MMS default rate is made by examining the message type
and/or application in the message header.
When using the WAP filter to charge differentially for web versus MMS
service, it is necessary to provision the URL of the MMS server in the
URL list. Not all MMS messages can be identified as distinct from web
requests; hence the URL is necessary for complete and accurate
filtering of MMS requests distinct from web page requests.
The WAP CBB filter is bidirectional. Phrased another way, the WAP
CBB filter operates on WAP flows initiated by the mobile device and
also on WAP flows initiated by the WAP gateway. Different rules in the
WAP CBB policy can be created to apply special rates only to mobile
initiated flows, only to WAP gateway initiated flows, or to any flow. The
“_subaddr” and “Any” (wildcard) objects can be used in WAP CBB
policy rules to control to which flows the rules apply. For example, use
of the “_subaddr” object in the Source field insures the rule applies
only to subscriber initiated flows. Use of the “_subaddr” object in the
Destination field insures the rule applies only to WAP gateway initiated
flows. Use of the Any object in both the Source and Destination fields
applies the rule to both mobile and gateway initiated flows.

Event Based Billing 5

The application level events detection capability is provided on the
Nortel GGSN in addition to the CBB. The application level events
shown in the following table are incorporated in CBB to support Event
Based Billing. Many IMAP clients use SMTP for mail sending
functions. Configuration of SMTP Event Based Billing is required in
addition to IMAP4 configuration to capture SMTP traffic.
Table 5-2
Application Level Events
Application Level Event Type Protocol
Email POP3
Email IMAP4
Email SMTP
Instant Message Wireless Village
The ability is incorporated with CBB to detect application level event

for e-mails (POP3, IMAP4, SMTP protocols) and instant messages
(Wireless Village protocol). The content type usage reports contains
events as well as volume and time for post paid billing (GTP
Accounting and RADIUS Accounting). The coupon ID may optionally
contain resource units for events, volume and/or time for prepaid
(CTPv3 and DCC).
For postpaid billing, a new version of CBB management extension is

introduced for GTP’ billing and a new version of CBB VSA is
introduced for RADIUS Accounting to report volume, time and event
usage for individual content type ID. For prepaid subscribers (CTPv3
and DCC), the Prepaid Data Node (PDN) can optionally grant coupons
for any combinations of volume, time and event for each coupon ID.
The GGSN triggers a re-authentication for a coupon ID when one of
these usage resource types has exhausted its allocation.
If more detailed EBB information is needed, please contact Nortel

personnel for EBB technical document.
Event definition and triggers

An “event” is defined by direction and application protocol type. The
supported event(s) for each protocol are pre-defined and not
configurable using SCS Client.
The direction is logical and is relevant from the point of view of the
mobile subscriber and should not be confused with the direction of the

IP services 5-25
uplink and downlink packets which traverse the GGSN as a result of

‘one event’. For example the mobile sends an instant message on its
terminal application that may result in multiple uplink and downlink
messages passing through the GGSN, but from the point of view of
identifying this event, it is considered as ‘one send event’.
The Nortel GGSN supports the event definition listed below for Event
Based Billing triggers for CBB.
Table 5-3
Event definition and triggers
Protocol Direction Event triggers Commands
POP3 Receive from Mobile RETR and TOP
SMTP Send from Mobile DATA and BDATA
Send from Mobile APPEND

IMAP4
Receive from Mobile FETCH
Send from Mobile Send Message Request

Wireless Village over HTTP
or WAP1.x Receive from Mobile Get Message Request and New
Message
In addition an HTTP or a WSP GET is also considered an Application

Event. See “Per-GET billing for HTTP and WSP” on page 5-27.
Event and Non-Event Traffic

Based on the event definition listed in the previous section, CBB rates
event and non-event traffic separately. The volume of all packets
associated with a given event are counted against the volume count of
the corresponding content type ID and/or coupon ID. Any other
messages which are not related to the event trigger message or the
subsequent messages related to the event trigger message are
counted against the default rate (content type ID and/or coupon ID) for
the specific application protocol. All the event/non-event content type
id and coupon ID’s are configurable in the CBB policy. Thus if an
application level event happens both the event and volume counts are
pegged against the particular content type id and/or coupon id. But for
the non-event packets only uplink/downlink volume counts are pegged
for against the particular content type ID and/or coupon ID.
The following figure provides a generic view on CBB rating for event/
non-event messages.

Figure 5-5
Generic CBB rating for event based billing
CBB rating for application packets

GGSN Server passing through GGSN for
Mobile Event Based Billing
Any non-event packets are counted
TCP Connection Setup against the default content type id and/
Non-event
}
User Login (Username and Password Exchange) or coupon id for the specific application
protocol. uplink and downlink volume us-
age is counted separately based on the
configuration for the specific applica-
Application message(s) exchange
but not event specific
: tion protocol.
When a event is detected as one of the

CBB supported events, CBB starts track-
ing the event.The rating information for an
event is toggled to start counting the vol-
ume (uplink and downlink) usage against
Application message triggers start of event
:
} the event specific content type id and/or
coupon id for the specific application
protocol.
: If “Event Completion” is disabled, the event
usage count is incremented for the content
}
: type id and/or decremented for coupon id
based on the configuration for the specific
application protocol.
Application messages
Event
: Once an event is detected, all volume

usage (uplink and downlink) for subse-
: quent messages are counted against
: the content type id and/or coupon id
configured for the specific application
Application messages protocol until the event completion
message is detected.
:
:
Application message indicate event
When event completion is detected, if
completion (Successful or Failed)
} “Event Completion” is enabled, an event
is incremented for the content type id
and/or decremented for the coupon id if
the event is completed successfully for
the configured specific application
protocol.
Non-event
Application message(s) exchange

but not event specific
: } Once the event completion is detected, any

non-event specific application messages
exchange uplink and downlink packets are
counted against the default content type id
and/or coupon id for volume usage.

IP services 5-27
Event completion optionality

An event may consist of one or multiple messages exchange between
the mobile application and the remote server. It is possible that an
event could fail if the server went down during the event messages
transfer or due to any other un-foreseen network issues. A
configurable option is provided by this feature to the operator to only
count the event usage when the event is completed successfully. This
“Event Completion” option is configurable in CBB policy for each pre-
defined event for the protocols supported for Event Based Billing. The
default setting for the “Event Completion” is disabled. If “Event
Completion” is disabled, the event usage count increments the content
type id and/or decrements the coupon id when the event trigger is
detected. Otherwise, the event usage count increments the content
type ID and/or decrements the coupon ID when the event is completed
successfully.
It should be clear that the “Event Completion” functionary is only

applicable to event counting and the volume counts are pegged
regardless even if the event is not completed successfully.
Per-GET billing for HTTP and WSP

Per-GET billing functionality enhances CBB to charge an event if an
HTTP or a WSP GET request is recognized in the packet flow. If a per-
get content type and coupon ID has been provisioned for the URL,
they are applied to that packet and an event is counted. If the “Event
Completion” is enabled, the event is counted unless a valid response
is received from the server.
Dynamic Policy Control 5

Dynamic policy control function enables GGSN integration with IMS
solutions via the Gx interface to provide dynamic charging support for
peer to peer IMS sessions and sessions that use SIP signalling
compression/encryption. The Gx interface can also be used for non-
IMS sessions. Providing dynamic policy control for IMS and non-IMS
sessions benefits our IMS and GGSN customers.
The dynamic policy control capability is provided on the GGSN for IMS
and non-IMS contexts. The Gx interface enables the GGSN to support
dynamic CBB policies and packet inspection rules on a per PDP
context basis.
The following functionality are provided:

• CBB processing on:
— IMS peer to peer services where pre-configuration of CBB rules
is not possible due to dynamic bearer session end points

— IMS SIP session bearer flows where SIP signaling SDP

information is compressed or encrypted hence unreadable at
the GGSN
• Mid-session driven CBB policy changes based on QoS, SGSN,
TFT, or RAT changes and unsolicited CBB policy changes from an
external server
• Ability to specify a “deny” action in a CBB rule (static or dynamic
rule) to deny flows
• Ability to disable the current inspection of SIP flows in which the
GGSN attempts to determine the dynamically assigned SIP bearer
port. Allow the Gx interface to determine how SIP flows should be
inspected.
The policy control on the Nortel GGSN includes the Traffic Plane
Function (TPF) on the GGSN as specified in [9]. The GGSN interacts
with the Charging Rules Function (CRF) using the Gx interface to
request charging rules for contexts.
Charging Rule Modification

The Charging-Rule-Install AVP is used for installing or modifying
charging rules for a PDP context. This AVP is received in the Diameter
CCA message. The Charging-Rule-Base-Name is equivalent to the
name of a CBB policy pre-configured on the GGSN. The GGSN does
not support names for the CBB rules within a pre-configured CBB
policy.
The Charging-Rule-Base-Name AVP is optional and contains the

name of a pre-configured CBB policy. If this AVP is received in the
Charging-Rule-Install AVP, the GGSN makes a CBB rule base change
by replacing the current CBB policy assigned to the context with the
specified CBB policy. The GGSN does not support the merging of the
two CBB policies to form one CBB policy. Only replacing a CBB rule
base with another rule base (pre-configured CBB policy) is supported.
The GGSN supports only one Charging-Rule-Base-Name. If more

than one Charging-Rule-Base-Name AVP are provided in the
Charging-Rule-Install AVP, the last Charging-Rule-Base-Name AVP
within the Charging-Rule-Install AVP is used to replace the PDP
context’s CBB policy. If more than one Charging-Rule-Install AVP are
received in the CCA message, the Charging-Rule-Base-Name in the
last Charging-Rule-Install AVP is used.
The Charging-Rule-Definition AVP is optional and defines a dynamic

charging rule. A dynamic charging rule is a charging rule from the
CRF. It is equivalent to GGSN’s CBB rule. One or more Charging-
Rule-Definition AVPs may be provided. If Charging-Rule-Definition

IP services 5-29
AVPs are within the Charging-Rule-Install AVP, the GGSN creates a

dynamic CBB policy with the specified charging rules and applies the
policy to the context. If more than one Charging-Rule-Install AVP are
received in the CCA message, the charging rules of all the Charging-
Rule-Install AVPs are used to create a dynamic CBB policy. The
GGSN supports a maximum of 20 install Charging-Rule-Definition
AVPs in a CCA message. If more than 20 are received in the CCA, the
remaining Charging-Rule-Definition AVPs are ignored.
Table 5-4 shows the type of CBB policy applied to a context after
interacting with the CRF.
Table 5-4
CBB policy applied to context after CRF interactions
Current CBB Charging Rule Charging Rule Result CBB Policy assigned to context
policy Base Name Definitions
assigned to from CRF from CRF
context
None CBB policy A None CBB Policy A
None None rules 1, 2, 3 Dynamic policy with rules 1, 2, 3
None CBB policy A rules 1, 2, 3 Dynamic policy with rules of CBB policy A
and rules 1, 2, 3
dynamic rules from CRF take precedence
CBB policy A CBB policy B None CBB policy B
CBB policy A None rules 1, 2, 3 Dynamic policy with rules of CBB policy A
and rules 1, 2, 3
CBB policy A CBB policy B rules 1, 2, 3 Dynamic policy with rules of CBB policy B
and rules 1, 2, 3
Dynamic CBB policy A None Current dynamic policy is deleted and

policy replaced with CBB policy A
Dynamic None rules 1, 2, 3 Rules 1, 2, 3 from CRF are merged with the
policy current dynamic policy
—sheet 1 of 2—

Table 5-4
CBB policy applied to context after CRF interactions (continued)
Current CBB Charging Rule Charging Rule Result CBB Policy assigned to context
policy Base Name Definitions
assigned to from CRF from CRF
context
Dynamic CBB policy A rules 1, 2, 3 Current dynamic policy is deleted and

policy replaced with a dynamic policy with rules of
CBB policy A and rules 1, 2, 3
—sheet 2 of 2—
If a dynamic policy contains pre-configured CBB rules and dynamic

rules from the CRF, the dynamic rules have higher precedence. If
multiple Charging-Rule-Definition AVPs are within the Charging-Rule-
Install AVPs, the precedence is based on the order they are received
in the message. Figure 5-6 shows an example of a dynamic policy
consisting of pre-configured CBB rules and dynamic rules ordered
from highest to lowest precedence.

IP services 5-31
Figure 5-6
Dynamic CBB policy
CBB Policy
Assigned to Context
CBB Policy A
Dynamic CBB Policy
Rule 1
Charging Rule 1 highest
precedence
Rule 2
Charging Rule 2
Rule 3
Charging Rule 3
CBB Policy A Rule 1

From CRF
CBB Policy A Rule 2
Charging Rule 1 first in
message CBB Policy A Rule 3 lowest
Charging Rule 2 precedence
Charging Rule 3 last in

message
The CRF can inform the GGSN to modify an existing dynamic

charging rule by sending the Charging-Rule-Definition AVP in the
Charging-Rule-Install AVP with the Charging-Rule-Name of an existing
rule. The attributes of the existing rule are overwritten with the
attributes specified in the Charging-Rule-Definition. Attributes not
provided in the Charging-Rule-Definition are set to default values.
Content Filtering 5
The Content Filter functionality adds to the GGSN the functionality of
filtering HTTP and WAP requests, through the use of third party
content filter products. When the Content Filter Service is provisioned
for a subscriber, all HTTP and WAP content requests (containing
methods currently supported by Content-Based billing) sent from
mobile are intercepted by the GGSN. For each HTTP/WAP request
the GGSN sends a request to one of its available provisioned Content
Filter Servers, asking permission on behalf of the subscriber to allow
the HTTP or WAP request to pass through the GGSN. The Content
Filter Server then responds back to the GGSN with a decision to do
one of the following:

• Pass-through - HTTP/WAP request is allowed to pass through the

GGSN.
• Respond to Client - HTTP/WAP request is dropped and an HTTP/
WAP response is sent back to the mobile subscriber indicating why
the request was dropped (e.g., 302 Re-direction, 403 Forbidden).
The Content Filter feature is only supported for contexts using the IP
PDU.
Content Filter Servers are connected to the appropriate Connection

ISP.
Figure 5-7
GGSN ISP logical configuration
Content Filter
GGSN Servers
Mobile SGSN Connection

Gn ISP ISP
HTTP/WAP
Servers
For VPN subscribers, the Content Filter Servers may reside within the
VPN routing domain, depending on the type of VPN. The following
figure shows example deployment for VPN Only model.
Figure 5-8
GGSN VPN Only Logical Deployment Configuration
VPN
GGSN
Content Filter
Connection
Mobile SGSN Servers
ISP
Gn ISP VPN
HTTP/WAP
Servers
VPN Only deployments must have the Content Filter Servers inside
the routing domain of the VPN.

IP services 5-33
A single Content Filter server may be used by more than one

Connection ISP. In this scenario, the same Content Filter attributes (IP
address, port, and server type) are configured within each ISP.
If a Content Filter server is configured within a single ISP that spans

multiple devices, each device will connect to the configured Content
Filter server independently.
Interception of HTTP/WAP requests is performed by inspecting the

packets which are sent through the GGSN by the mobile subscriber.
The GGSN snoops and modifies the packet stream, but does not
terminate or proxy TCP connections or WTP streams. All HTTP/WAP
requests are filtered, by sending a request to a content filter server,
however, any re-directs or responses for blocked URLs are sent back
to the mobile. In the case of a re-direct, the mobile would then initiate a
new HTTP/WAP request to the new URL.
This feature is optional. A software key is required to enable the

feature through Software Optionality Control (SOC).
Figure 5-9
Content protocols
Content Filter Server
Filter
HTTP/WAP HTTP/WAP
TCP/UDP TCP/UDP
IP IP IP
GTP-U GTP-U L2/L1 L2/L1
UDP/IP UDP/IP
L2/L1 L2/L1
Mobile SGSN GGSN Web Server
ISP security services 5

This section discusses the GGSN mechanisms that provide security
for Gn, Ga, Gi, and other ISP contexts as well as the Default ISP.
ISP Node Services

When an ISP context is created there are no node services applied.
Nevertheless an ISP context does not allow any incoming connections

to any TCP port. It is, for example, impossible to telnet or FTP to any
IP address of a standard ISP context. The only exception is TCP Port
8888 which is used for Personal Content Portal. An attempt to telnet to
an ISP context IP address will result in a RST (connection refused).
By default, outgoing connections and flows (telnet, ping, traceroute)

originating from the ISP context are allowed.
An ISP context is essentially a virtual router. As such it has a number

of IP interfaces as well as an ISP default address which is roughly
equivalent to a loopback interface or a “circuitless IP address.”
Node Services - specifically Security Policies under Node Services -

can be considered a special type of “per-ISP-context” firewall applied
to packets originating from or destined to IP addresses which are part
of the ISP context. The ISP default address and IP addresses
assigned to trunk interfaces owned by the ISP context are the possible
destinations of such packets.
It is important to emphasize that Node Services are not the equivalent

of an interface access list that filters all traffic which flows through an
interface. All packets are permitted to tandem through an ISP, entering
one interface and being forwarded out another. The Node Services
firewall applies only to packets originated from or destined to the ISP
or its trunk interfaces. Node services security policies are applied to
packets flows to/from the ISP context, not through the ISP context.
Node Services security policies are applied to the ISP as a whole. It is

not possible to have different security policies for different interfaces in
the ISP context.
Security Policy definition

Security Policies for Node and Management services are defined in
the “Service Policies” section of the SCS GUI.
In the GUI, Traffic Services refers to the definition of policies applied to

subscribers (security, shaping, policing, accounting, etc.)
ISP Node Services refers to the definition of policies applied to ISP

contexts. Currently only security (firewall) policies are permitted.
Management Services refers to the definition of policies applied to the

management ISP. Currently only security (firewall) policies are
permitted.
Node services can be created, modified and applied by SCS users

that have “ISP_Profile” privileges.

IP services 5-35
Security Policy example

The default security policy proposed by the system when a new policy
is added is shown in Figure 5-10.
Figure 5-10
Default Node Services Security Policy
This policy allows outgoing connections from any of the IP addresses

of the ISP context (Virtual Router) and denies any incoming
connections.
The construct “_IspDefaultAddr” (not shown in the figure) resolves to

the ISP Default Address (loopback address) assigned to an ISP
context in a specific node.
The construct “_IspAddr” resolves to “_IspDefaultAddr” plus any trunk

or access interface addresses in the ISP context.
Note that this policy prevents any incoming flow into the ISP context.
For example, it is not possible to ping, open IPSec, L2TP or GRE
tunnels into the ISP context.
This policy may also interfere with the operation of RIP or the
establishment of adjacencies if the ISP context is running OSPF.
A note about the “Action” column of the table. A “Drop” action silently
discards packets. A “Reject” action will send a RST packet for TCP
connections (thus providing faster feedback and potentially more
information to intruders).
Allow Incoming GTP Tunnel Security Policy

Figure 5-11 shows a modified security policy that permits incoming
GTP-99 packets (UDP 2123 / 2152) from SGSN devices located in

networks SGSN-Set-1 and SGSN-Set-2. It also permits OSPF traffic

to/from the ISP context.
More elaborate policies are possible (for example, allowing GTP-97

from a set of IP addresses and GTP-99 from a number of subnets).
Figure 5-11
Node Services Security Policy example
Note that all outgoing connections are still permitted by Rule 1 in the
Security Policy example.

IP services 5-37
Figure 5-12
GTP-99-C Service Object definition and Network Object definition
The “GTP-99-C” service has been defined as a service object

consisting of UDP (destination) Port 2123. “GTP-99-U” is defined
similarly with UDP port 2152.
Note that port ranges (for example, 2920-2930) are also allowed in the
service object definition. Additionally, it is possible to group non-
contiguous services into a service entity.
Network 172.16.128.0/17 has been defined as network object “SGSN-

Set-1”.
If a node services policy is modified (for example, if a new network or

IP Farm object “SGSN-Set-3” is added to rule 2), the change is
propagated automatically to all GGSNs to which that policy is applied
(all GGSNs with an instance of the ISP context in which the policy is
provisioned). There is no need to reconfigure the individual GGSNs.
Application of Node Services

Node services are provisioned through SCS GUI. Under the “Devices”
menu select <device>->configure->Node Services. Figure 5-13 shows
the application of node services to an ISP context “isp2.” Given the
nature of the policy (involving GTP) we can infer that the ISP context is
actually a Core Network ISP.

Figure 5-13
Application of Node Services
If the SCS user has “ISP_Profile” privileges and does not belong to the
Default ISP (that is, Device_Owner ISP shown on the User Manager
screen), only the “ISP Node Policies” and “ISP Node Service Profiles”
panels are displayed. If the SCS user has “Device Owner” privileges
and belongs to the Default ISP, only the “Management Service
Profiles” and “Management Policies” panels are displayed. In the
example in Figure 5-13, the SCS user has both ISP Profile and Device
Owner privileges.
Note that a “Service Profile” is simply a collection of service policies.

Currently the only Node and Management policies that can be defined

IP services 5-39
are security policies. Thus the “Profile” panels in these screens are
seldom used and generally reserved for future use, though they are
functional.
Management Services 5
Management services are essentially “Node Services” applied to the
Default ISP context which owns the management ports of the GGSN.
Recall that the management ports are used for communication
between the GGSN and SCS, GGSN and log server, etc.
Most of the concepts mentioned when discussing Node Services are

also applicable to Management Services. However, the specific
firewall rules required differ from what is appropriate for an ISP
context.
Management Services must be configured by an SCS user that has

“Device Owner” privileges.
Security Policy definition

Refer to “Security Policy definition” on page 5-34. Management
services are also defined in the “Service Policies” screen of the SCS
GUI.
Defining Management Services requires “Device Owner” privileges in

the SCS.
Security Policy examples

The default policy proposed by the system is shown in Figure 5-14.
This policy allows all outgoing connections, permits incoming
connections from the SCS, and drops anything else. Note that if this
policy is applied it is impossible to telnet or FTP into the GGSN.

Figure 5-14
Default Management Services Security Policy
SpmAddr resolves to the set of IP addresses of the different SCS

functional components (Region Server, Pull Server, Log Server, etc.).
SCS addresses can be viewed (with Device Owner privileges) in the
SCS under File->SCS Properties. They can also be checked by
issuing the CLI command “show spmaddr.” In the example in Figure 5-
15, all components of the SCS run on the same server.

IP services 5-41
Figure 5-15
Management Services Security Policy
Note that SPM – “Subscriber Policy Manager” is the old name for SCS
(“Service Creation System”). _IspAddr resolves to the IP addresses of
the management ports plus the _IspDefaultAddress of the default ISP
context (if defined via CLI).
Application of Management Services

See “Application of Node Services” on page 5-37. Note that the SCS
user must have “Device Owner” privileges to apply Management
Services.
Traffic Performance Optimizer (TPO) Interworking 5

This feature supports interworking with Bytemobile TPO. Other TPO
vendor solutions should be considered separately.
This feature specifies the ISP on the GGSN that is used to

communicate with the TPO. This ISP is referred by this feature by TPO
ISP. The TPO ISP IP address is used by the TPO to send packets to
the GGSN. There can be only one TPO ISP per GGSN and it has to be
a separate ISP, in other words, can not configure Gi, Gn, LI, or Ga ISP
to be a TPO ISP.

When the GGSN receives a packet from the MS, the packet is handled
by the Gn ISP. The packet is then delivered to the Gi ISP. A set of IP
services is executed on the packet on the Gi ISP, the first service that
is applied to the packet is the TPO service. The TPO service detects
that the packet needs to be forwarded to the TPO server. The packet is
then handed over to the TPO ISP before it goes through the rest of the
IP services. The packet is then sent to the TPO server over the
GGSN-TPO GRE loop back interface. The TPO process the packet
and then send it back to the GGSN using the TPO ISP IP address. The
packet is received on the TPO ISP and then delivered to the Gi ISP to
go through the rest of the IP services and then out to the destination
(web server). The downlink packet goes through similar path.
The figure below shows the Network Architectures when interacting

with Bytemobile TPO servers.

IP services 5-43
Figure 5-16
Network with multiple GGSNs and multiple bytemobile TPOs
GPRS/PLMN
Mobile Stations
Load Balancers
(Mandatory)
Loopback Loopback
GGSNs
Bytemobile
TPOs
Packet Data
Network
Flow Management 5
It has been observed that an individual wireless subscriber can
potentially allocate thousands of flow cache resources on the GGSN.
This can occur when the wireless subscriber is infected with a virus or
worm or when the subscriber uses applications such as file sharing.
File sharing can be slow or may not terminate a TCP connection
leading to this type of issue. This can result in PDP activation failures,
throughput issues, RPC timeouts and missed poll event logs.
The above issues result when there is no limitation put on the number
of flow cache resources that an individual wireless subscriber is
allowed to allocate.

The GGSN supports a flow management service policy feature which

restricts the number of flow cache resources that are allowed to be
allocated per subscriber. The policy is created and set to a flow limit
currently recommended to be 500. The policy is then bound to the
subscriber template.
Due to the nature of the GGSN architecture, the flow is still created
and bound to the subscriber. Once the GGSN can determine the
subscriber has too many flows, it will put the flow in the drop list. After
10 seconds or immediately upon request for a new resource if the
corresponding free list has been exhausted the flow is destroyed and
unbound from the subscriber. Although there is a small window where
the flow is still allocated, activating this feature helps to greatly control
and alleviate the described symptoms.
Due to the high impact this issue has, it is strongly recommended that
the flow management service policy be active on every in service
GGSN.
Attention: For subscribers which attempt to allocate more than the

configured value of flow cache resources, an info event log is
generated

6-1
IP routing 6
Overview 6
The Nortel GGSN incorporates many attributes and much of the same
functionality as a router or layer 3 switch. This chapter discusses the
router-like functionalities of the GGSN.
Routing functionality on the GGSN is used to forward packets toward

their destination using the most efficient network path. This is true of
both the Gi and Gn interfaces. On the Gi interface, subscriber packets
are forwarded toward application or service provider networks, public
or private ISPs or private Intranets. On the Gn interface, user packets
are encapsulated inside GTP packets. Routing is again used to
forward the GTP packets toward their intended SGSN using the most
efficient path. The forwarding information in the header of the user IP
packet is not used for routing on the Gn interface.
Routes can be configured on the GGSN manually through SCS or

automatically through a number of routing protocols. Manually
provisioned routes are referred to as static routes - they are always
present and unchanging. Static routes are simple, straightforward, and
understandable. A disadvantage of static routes is they do not respond
to changes in the availability of network nodes, links, or topologies,
and can require extensive manual provisioning.
Dynamic routing protocols automatically determine which subnets are

reachable from the GGSN and the best route for doing so. Dynamic
routing protocols require only initial provisioning, after which they
automatically adapt to changes in network nodes, links, and
topologies. An advantage of routing protocols is they require only initial
provisioning, not ongoing changes and modifications. Dynamic routing
protocols can tremendously reduce the ongoing labor cost to maintain
a packet network. A disadvantage of routing protocols is the operator
cedes some control of the network to software algorithms.

6-2 IP routing Copyright © 2000–2008 Nortel Networks
The dynamic routing protocols supported on the Gn, Gp, and Gi

interfaces by the GGSN are:
• RIPv1
• RIPv2
• OSPFv2
• BGPv4
• MPLS
• IS-IS
Wireless ISP model routing 6
The Wireless ISP network model is perhaps the one in which the
GGSN most directly uses available routing functionality.
In Figure 6-1, each of the four ISPs shown - the Gn ISP and three
Connection ISPs - are separate and distinct virtual routers within the
GGSN. A virtual router is a logically distinct entity containing a unique
routing table, Forwarding Information Base (FIB), static routes, routing
protocols, etc. Each virtual router is unique, completely separate from
other virtual routers contained within the platform. Virtual routers
cannot pass packets to other virtual routers. A virtual router can
receive packets upon and forward packets out connections which are
assigned to it. These rules are true of the GGSN, with one very
significant exception. The Gn ISP is capable of passing packets
received on the Gn interface to the connection ISPs. The connection
ISPs then treat these packets as if they were received upon a
conventional interface, such as an Ethernet link. Similarly, the
connection ISPs can pass subscriber packets to the Gn ISP for GTP
encapsulation and forwarding into the core network.
Each of the Connection ISPs can be independently configured with

static routes, dynamic routing protocols, or a combination of the two.
Static routes and routing protocols provisioned upon one Connection
ISP do not apply to any other Connection ISP; each must be
provisioned separately.
The routing information used by a Connection ISP can be simple or

complex, depending on the network attached to the Gi interface of the
Connection ISP. In the simplest case, only a single connection is
available for forwarding packets, such as a single Ethernet link to a
router. In this case the router at the far end of the Ethernet link is
referred to as the “default router” because it is the first hop to which
every outgoing packet is forwarded. A “default route” is configured to
forward every packet to the router. A default route is a static route that
uses the 0.0.0.0 netmask to identify destinations reachable through

IP routing 6-3
that connection. All packets match the 0.0.0.0 netmask, hence all
packets are forwarded through the associated connection on the
GGSN to the default router.
The bottom Connection ISP in Figure 6-1 shows a slightly more

complex scenario. Two networks are connected to this ISP, one
private; the other the public Internet. Additional routes are required to
correctly steer user traffic to each of these networks. In this instance a
single static route can be used to direct packets destined for the
private network. The route will identify the subnet as 10.0.0.0 and the
ethernet connection to the private network. A default route can be
used to steer all other traffic to the public internet. The route used for
any given packet is decided based upon the best match. In this
example any packet with a destination address of 10.x.x.x is routed to
the private network, all other packets to the public network. Of course,
dynamic routing protocols may also be used to the same effect.
It is important to note some potential security issues in this network

model. Any ISP on a GGSN is capable of tandeming packets between
two interfaces. A tandem packet is one that is not destined for or
received from a GGSN subscriber, but rather enters via one trunk
interface and exits another. In the example below, the 10.0.0.0 private
network is essentially connected to the internet because of the tandem
capability of Connection ISP. GGSN subscriber firewall rules do not
address this situation.

Figure 6-1
Wireless ISP routing example
Gi
Connection
APN
ISP
APN
Gn
Connection
APN
Gn ISP
SGSN GTP Tunnel
ISP
SGSN APN
SGSN
APN
Connection
APN 10.0.0.0
ISP
APN
APN Internet
GGSN
Aggregation APN
One variant of the Wireless ISP model is the ability to configure APNs
belonging to Connection ISPs as Aggregation APNs. Aggregation
APNs offer the ability to support increased numbers of subscriber’s
PDP sessions.
By configuring an APN for aggregation mode, all PDP sessions using

that APN will not be able to access all services and features available
on the GGSN.
When using the Wireless ISP model for Aggregation APN, certain
engineering and configuration rules must be considered for end user
IP address assignment.
Subscriber Service Module (SSM) Redundancy for Aggregation APNs

is now supported. Upon SSM failure, all sessions on that failed SSM
are moved to other SSMs. Under overload conditions, higher priority is
given to session redundancy processing than that of creating new
contexts.
L2TP VPN model 6

An L2TP VPN creates a tunnel through the network between the
GGSN and the L2TP Network Server (LNS), a particular node within
the network. Any packet placed within the tunnel by the GGSN is

IP routing 6-5
automatically conveyed to the LNS. When the destination APN of a

PDP session is configured with an L2TP VPN, all packets sent in that
PDP session are placed within the tunnel. Hence the subscriber can
send packets only to the LNS. As a result, the GGSN does not route
subscriber packets when the L2TP VPN model is deployed.
However, routing still comes into play for this network model. To tunnel
a subscriber packet through the network, the GGSN creates a new
packet and places the entire subscriber packet, including IP header,
into the new packet. The GGSN builds the IP header for this
encapsulating packet. Routing information is then used to forward the
L2TP packet toward the LNS. As with the wireless ISP model, either
static or dynamic routes can be used to forward L2TP packets.
The GGSN permits multiple L2TP tunnels to the same destination in

support of redundancy and capacity scaling. A mobile subscriber data
session is created on only one tunnel, even if multiple tunnels are
available. If the selected tunnel fails (due to a link failure, for example),
the subscriber session must be recreated on one of the alternate
tunnels.
GGSN VPRN model 6

The GGSN VPRN model is similar to the IPSec VPN model in that in a
GGSN VPRN the far end node must also be a GGSN and the tunnel is
an IPSec tunnel. The GGSN uses routing protocols to determine to
which far end GGSN the packet is to be forwarded. The subscriber
packet is then encapsulated and forwarded through the IPSec tunnel.
If several corporate Intranet locations are connected into the GGSN

VPRN, the various Intranets are capable of communicating by
tandeming packets though the GGSN. Tandeming involves the GGSN
receiving packets not destined for mobile subscribers on one interface
and forwarding those packets out another interface toward their
destination.
GRE VPN model 6

The Generic Routing Encapsulation (GRE) VPN model is also similar
to the IPSec VPN model in that a tunnel is used to carry subscriber
packets. In this case, a GRE tunnel is created through the network
between the GGSN and a CPE in the private network. Any packet
placed within the tunnel by the GGSN is automatically conveyed to the
CPE. When the destination APN of a PDP session is configured with a
GRE VPN, all packets sent in that PDP session are placed within the
tunnel. Therefore, the subscriber can send packets only to the private
network. As a result, the GGSN does not route subscriber packets
when the GRE VPN model is deployed.

However, as in the IPSec case, routing still comes into play for this
network model. To tunnel a user packet through the network, the
GGSN creates a new packet and places the entire user packet,
including IP header, into the new packet. The GGSN builds the IP
header for this encapsulating packet. Routing information is then
utilized to forward the GRE packet toward the CPE. As with the
wireless ISP model, either static or dynamic routes can be used to
forward GRE packets.
Multi-Protocol Label-Switching (MPLS) 6

The distribution of VPN routing information is controlled through the use
of VPN route target communities, implemented by BGP extended
communities. Each VRF has an import target and an export target list.
The route-target-attribute is logically equivalent to a VPN. Distribution
of VPN routing information is controlled as follows:
• When a VPN route learned from a CE is injected into BGP, a list of
VPN route target extended community attributes is associated with
it. Typically, the list of route target communities is obtained from the
export list of route targets associated with the VRF from which the
route was learned.
• An import list of route target extended communities associated with
each VRF controls the information that gets imported into the
routing table. The BGP routing update should contain at least one
matching route target so that the NLRI information carried in the
update can be imported into the VRF.
BGP operation
A PE router can learn an IP prefix from a CE router by static
configuration, through a BGP session with the CE router, or through
the RIP/OSPF exchange with the CE router. The PE converts the IP
prefix into a VPN-IPv4 prefix by combining it with an 8-byte route
distinguisher (RD). The route-distinguisher format allows the user to
configure it using either an autonomous system number or an IP
address. Each VRF is identified by its route-distinguisher. The
generated VPN-Ipv4 prefix uniquely identifies the customer address,
even if the customer site is using globally non-unique private IP
addresses.
The route distinguisher used to generate the VPN-Ipv4 prefix is

specified by a configuration command associated with the VRF on the
PE router. BGP distributes reachability information for VPN-Ipv4
prefixes for each VPN. BGP communication takes place at two levels:
within an autonomous system (PE-PE, PE-RR (route reflector) IBGP
sessions) or between domains (IBGP sessions between PE and CE).
The PEs in a VPN peer with one another as IBGP peers over the
provider’s network.

IP routing 6-7
BGP propagates reachability information for VPN-Ipv4 prefixes among

PE routers by means of the BGP multi-protocol extensions (RFC 2858,
Multi-protocol Extensions for BGP-4). It does this in a manner in which
the routes for a given VPN are learned only by other members of that
VPN, enabling members of the VPN to communicate with each other.
The PE router also binds a label to each customer prefix it advertises
in BGP routing updates.
For this release, a single label is distributed for all the routes in a VRF.
This label forms the inner label of the two-label stack used during
forwarding.
In GGSN 4.1, the GGSN includes support for the BGP ROUTE-
REFRESH capability, as well as Outbound Route Filtering (ORF). In
order to understand the benefit of this capability, consider the following
scenario. The BGP peers of GGSN nodes typically (a) implement
automatic filtering of inbound routes (b) depend on the route refresh
ability to deal with changes in input policies. When a new MPLS VRF
is provisioned on one of these BGP peers, it would (assuming that the
GGSN advertised support for the BGP ROUTE-REFRESH capability)
originate a BGP ROUTE-REFRESH message and expect the GGSN
to re-send the VPN routes the local PE may have discarded earlier,
due to automatic route filtering. If the GGSN did not support the BGP
ROUTE-REFRESH capability, the only option left to the remote PE is
to reset the TCP connection, which would cause all existing routes to
be discarded at the GGSN node as well as at the remote BGP peer,
and then subsequently reacquired. The support for BGP ORF allows
the GGSN to further limit the re-sent routes to the set of routes of
interest to the originator of the BGP ROUTE-REFRESH message.
A Nortel GGSN acting as a PE router should not be configured as a

BGP peer of another Nortel GGSN. The Nortel GGSN PE router
should BGP peer with a PE router connected to the far end VPN site.
MPLS Signalling
Based on routing information stored in the VRF, packets are forwarded
to their destinations using MPLS tunnels.
A two-level label stack is used when sending packets on the MPLS

tunnel between PEs. The outer label is used for the immediate next
hop and the inner label, which is popped by the egress router,
specifies the outgoing interface to the customer and the layer-2
encapsulation to use. For this release, we only support Ethernet
interfaces (FELC, GELC). In this release, this outer label will be
distributed via LDP-DU.

LDP-DU
LDP is a signaling protocol used for setting up best effort LSPs. LDP
operates in downstream-unsolicited mode. Essentially, each PE router
distributes a label for itself on establishing a session with a peer. In the
case of the GGSN, a label is distributed for the ISP IP address by
default. LDP is defined in RFC 3036.
RSVP-TE
RSVP-TE is a signaling protocol used to setup Traffic Engineered
LSPs. RSVP-TE extends the basic IP reservation scheme, the
“classical” Resource Reservation Protocol by adding support for MPLS
Labels Specification of the path for the tunnels. TE tunnels are
configured between end-points and can consist of multiple LSPs for
redundancy support. The following RSVP-TE capabilities are
supported:
• Instantiation of Explicitly Routed, ER-LSPs, with or without

bandwidth reservation. This capability makes use of the Explicit
Route Object (ERO) in RSVP-TE. The current release supports the
specification of hops as IPv4 addresses. The explicit routes can be
tagged as strict or loose hops. Loose hops involve use of IP routing
table lookup to reach the next specified hop.
• GGSN supports the provisioning of the tunnel bandwidth; this
provisioned value will be used only to derive and populate
information elements in the RSVP-TE signaling messages, so that
LSRs along the path can reserve the appropriate amount of
bandwidth. Note that no bandwidth reservations would occur on the
GGSN interfaces. On incoming requests (i.e. PATH & RESV
messages), the bandwidth parameter will be ignored and
acceptance/rejection decisions will not be made based on the
bandwidth attributes
• MPLS TE-Tunnels comprising of primary & backup LSPs.
• LSP reroute.
• RSVP Refresh & Refresh Reduction.
• RSVP Hellos.
RSVP & LDP Co-existence
RSVP and LDP-DU are not mutually exclusive and both protocols can
be enabled on the same MPLS interface. The LDP-DU installed BE-
LSPs should work independently of any RSVP signaled TE LSPs that
originate on the same interface.
MPLS Forwarding
Once the LSPs are set up, they are used to forward the VRF traffic. In
this release, best effort LSPs will be used to carry the VRF traffic. The

IP routing 6-9
figure below gives an example of packet forwarding of the VPN traffic

across the provider backbone.
Figure 6-2
MPLS Packet Forwarding
Site A
(10.1.1.0/24)
Site B
pkt to 10.1.1.1
CE-B
CE-B
P-N P-1 pkt to 10.1.1.1
PE-B PE-A
IGPLabel (PE-B)-y IGPLabel (PE-B)-x IGPLabel (PE-B)
BGPLabel (L1) BGPLabel (L1) BGPLabel (L1)
IPv4:10.1.1.1 IPv4:10.1.1.1 IPv4:10.1.1.1
PE-B receives a packet. PE-A receives an IPv4 packet.

Pop the IGP Label (terminates here) Query the VRF for Site B:
Pop the VPN Label (points to CE-B) Pop the IGP Label, and determine - get the IBGP next hop: PE-B
Forward to CE-B the next hop from it. Then, push - get the VPN label, L1
the appropriate IGP Label and Determine how PE-B can be
forward to the next hop. reached: IGP Label PE-B.
Push the VPN label, and then
the IGP Label and forward to P-1.
The example in Figure 6-2 illustrates a case where the customer IP

packet, after being encapsulated with the 2-level MPLS label stack, is
still small enough to be directly transmitted on the appropriate MPLS
interfaces on the GGSN. This means that a large IP packet must be
fragmented if necessary, and then encapsulated with the MPLS header.
If the IP packet has the Do not Fragment (DF-bit) set in the IP header,
and is large enough to require fragmentation, the GGSN node has no
choice but to drop it. In order to provide relief from this issue, the GGSN
allows customers to choose between the following options, on a per-
VRF basis:
• The normal (standard) treatment of the DF bit

• The new treatment of the DF bit: In this mode, the GGSN

disregards the original setting of the DF bit in the packet. If the
packet size is too large, it clears the DF bit in the header, fragments
the packet, and transmits the multiple fragments after suitable
MPLS encapsulation.
• Once the MPLS tunnels have been configured with the required
parameters, the system uses RSVP-TE to setup the tunnels for
transporting data. These MPLS-TE Tunnels are “owned” by the
ISP, and not restricted (e.g. because of constraints supplied at its
creation time) to carrying the traffic for any specific VRF/VPN. It is
of course possible to provision specific EFEC policies that map
each VRF/VPN’s traffic to a separate tunnel.
Explicit FEC (EFEC) Service
The Explicit FEC functionality enables the flexible mapping of
customer data flows onto previously configured and established MPLS
TE Tunnels. This mapping happens at the granularity of a flow (as
characterized by a 5-tuple consisting of source/destination IP
addresses, TCP/UDP port numbers etc.). The EFEC mapping is
implemented as a service.
Actions in EFEC Policies

In order to provide full flexibility in the determination of the tunnel used
to transport a particular flow, the EFEC policies allow the users to
provision an action against each flow. The possible combinations of
parameters that specify an action, and their interpretation is specified
in the following table.
Table 6-1
Actions in EFEC policies
Actiona Description
EXP Tunnel Egress Tunnel

value Pref Router Name
Yes/No No No Yes This is the most specific mapping possible. The flow
makes use of the specified tunnel, if one of its
underlying LSP tunnels are in the established state.
If the EXP parameter is entered, this will be used to set

the EXP bits in the outer (or only MPLS label attached
to the packet).
Yes/No Yes Yes No In this case the system searches for Tunnels with the
specified Egress Router as the destination address,
and having the preference specified by the user.
(same treatment of EXP bits as the first case)

IP routing 6-11
Table 6-1
Actions in EFEC policies
Actiona Description
EXP Tunnel Egress Tunnel

value Pref Router Name
Yes/No Yes No No The system looks for tunnels which have the specified
preference value, and which have the specific PE
advertising the BGP route as the destination node. This
rule is applicable only in the case of EFEC policies
provisioned against VRFs.
(same treatment of EXP bits as the first case)

a. A value of Yes/No for a parameter means that the parameter was specified (or not). A value
of’-’ means that the user has no option to specify this value.
If the received packet does not match the rules contained in any of the
EFEC service policies: the following actions are taken when the packet
processing occurs at the VPN/VRF context:
• check if there is a BE-LSP to the appropriate PE router. If there is

one, send the packet on that BE-LSP.
• If no BE-LSP exists, discard the packet
Tunnel Selection and Load Balancing in EFEC services
The network operator is given the option of selecting the tunnel either by:
• specifying the preference or tunnel-name or
• specifying the preference or
• specifying the preference and egress router
If more than one suitable tunnel exists, load balancing of MPLS EFEC
traffic is done on a per flow basis. Thus,
• If a flow is already existing, no lookup is done and the same tunnel

is continued.
• If no flow exists, round robin rules for tunnel selection is enforced
as follows to ensure load-balancing:
— rotating through next hops(i.e: egress routers), if not specified,
of the same destination.
— rotating through tunnels in a list of tunnels of the same
preference if tunnel name is not specified.
MPLS/BGP VPN topologies
The primary topologies used in BGP/MPLS are full-mesh and hub-
and-spoke. It is also possible to use BGP route reflectors to simplify

the connectivity between the PEs. In this release, only full-mesh and
route reflector (client) based topologies are supported.
E-LSP support
Only the configuration of DSCP->EXP bit mapping in the ingress
direction for the outer label will be supported in this release. This
configuration is via SCS per device, under MPLS Properties. By
default, if an EXP mapping is not specified for a particular DSCP
value, a default EXP is used. This default EXP can be selected to be
any one of the possible 8 values.
On a per ISP basis, the user can select the default DSCP->EXP
mapping that will set the outer label EXP.
On a per MPLS trunk interface basis, the user can select the DSCP-
>EXP mapping that will set the outer label EXP for all LSPs on that
interface.
The method for selecting which DSCP value to use for the DSCP-
>EXP mapping entries is provided via a DiffServ marking policy
(analogous to the existing DiffServ marking policy). This provides an
“internally used” DSCP value for the mapping to the EXP bits for the
outer label (that is, the DSCP value of the packet header is not
affected). The user can select “copy from inner (IP header)” which
uses the IP header DSCP value (set by selecting Diffserv policy for
subscriber), or the user can select a specific DSCP value at the VRF
screen (applied to all subscribers part of the VRF).
If no DSCP value is explicitly selected, 000000 will be the default

“internally used” DSCP value if E-LSP is configured on the MPLS
interface.
There are two components to providing E-LSP support:

• Marking (or Classification, since we don’t really mark the IP
packet header): Marking/Classification is achieved by configuring
policies. Based on the configuration, the Marking/Classification
derives the DSCP value (later will be mapped to EXP bits).
Currently, deriving the “internal used” DSCP value from IP packet
header DSCP field, or simply by setting a fixed value for it, are
supported.
• Mapping between DSCP and EXP bits using a statically
configured DSCP->EXP map: For mapping, the user is allowed
to configure a static map between different DSCP values and
EXP values.

IP routing 6-13
MPLS Management VPN

In some networks, a managed router service is provided for their
customers. The customer LAN IP networks are part of the customer IP
VPN, whereas the loopback addresses of the CE routers are put into a
separate Management VPN. Hence, support to overwrite the Route
Target for a BGP vpnv4 route is required. The GGSN solution is
flexible and allows a management station per VPN or a common
management station for multiple VPNs. The GGSN PE allows for
advertising certain routes with multiple Route Targets.
In the customer VRFs, a VRF outbound policy is used to advertise

some prefixes with the Route Target of the Management VPN. The
other prefixes are advertised with the export Route Target of the
customer VRF. To rewrite the Route Target for some prefixes, the route
policy was enhanced with the Route Target Profile attribute in the set
field. The Route Target Profile, can have a single Route Target or
multiple Route Targets. The routes are matched using the prefix list
field.
The VRF is enhanced with inbound and outbound route policies, that
help in selectively advertising or rejecting inbound and outbound
routes. The match policy of a Route Policy was also enhanced with
Route Target Support. This feature will also help in setting path
attributes for outgoing and incoming updates, and deny or accept
specific prefixes.
OSPF-TE 6
In order to support TE networks, OSPF has been extended to support
the network-wide distribution of resource availability, and resource
attributes. These extensions enable all the nodes participating in
OSPF-TE to receive the complete network state (in terms of resource
availability, resource attributes etc.) periodically (or when significant
changes have occurred), and use the acquired information to setup
LSPs to satisfy various constraints (such as bandwidth, QoS etc.).
The GGSN implementation of OSPF-TE has the following attributes:

• Support the origination, maintenance, storage and flooding of
OSPF Traffic Engineering LSAs, as specified in the IETF draft
“Traffic Engineering Extensions to OSPF Version 2". The Traffic
Engineering LSA will support the two TLV types - the Router
Address TLV and the Link TLV.
• OSPF-TE will be supported within the ISP context, not within a
VPN context. It will be enabled/disabled on a per-area basis. The
TE support for an area is disabled by default. A TE-metric can be
configured for each OSPF PtoP and broadcast link within the area.

• GGSN supports a reference bandwidth parameter. If specified, the

reference metric will be used to calculate the TE-metric for
interfaces that don't explicitly configure the TE-metric. The TE-
metric is derived as the Reference bandwidth/ physical bandwidth
of link.
Note that the GGSN implementation does not support the calculation
of constraint's based paths using the information stored in it's Traffic
Engineering Database.
IS-IS routing 6
Intermediate System to Intermediate System (IS-IS) is an OSI link-
state hierarchical routing protocol where routers exchange adjacency
information, as well as the metric(s) associated with interfaces, to
automatically discover the network topology. GGSN supports the IS-IS
protocol, as defined in ISO 10589, extended as specified in RFC 1195
to support IPv4 intermediate systems (routers) and end-systems
(hosts).
The basic functions of an IS-IS router are to:

• Exchange hello packets and form adjacencies with neighbors.
• Create and Flood Link State PDUs (LSPs) that contain information
about discovered or configured adjacencies, and costs or metrics
associated with interfaces or links.
• Propagate LSPs originated by other routers.
• Use the combination of (a) LSPs originated by itself and (b) the
LSPs received from other routers to compute the network topology
and the SPF tree rooted at itself.
OSI IS-IS routing makes use of a two-level hierarchy. A routing domain
is partitioned into areas (which is a grouping or cluster of routers which
have an area address in common). The collection of areas is
connected via a backbone spanning the “border routers” for each of
the areas (i.e. the backbone must be a single connected graph).
Forwarding within a single area is accomplished by Level 1 routers.
Level 1 routers know the complete topology (including intermediate
and end-systems) within their own area. Forwarding within a single
area therefore only involves a sequence of Level 1 router hops.
Forwarding within a Level 1 area is done on the basis of a “system ID”
which uniquely identifies an IS-IS router.
When a Level 1 router needs to send data to a system outside its own
area, it forwards the packet to some Level 2 router that resides in its
own area. Level 2 routers maintain topology information about other
Level 2 routers, and facilitate packet forwarding based on the area

IP routing 6-15
address contained in the packet. Once the packet reaches the correct
Level 2 router, it is forwarded to the intended destination using the
Level 1 forwarding mechanism.
In the GGSN, when IS-IS is configured at the ISP level, it is configured

for the highest level of IS-IS routing in which the node can participate.
If the highest level of IS-IS routing is configured as Level1, all the
interfaces associated with this IS-IS instance can only be Level1.
However, if the highest level of routing is configured as Level2, the
interfaces associated with this IS-IS instance can serve either IS-IS
Level2 only, or Level1 and Level2. Thus the level of IS-IS participation
is specified at the granularity of an interface. Table 6-1 illustrates the
combinations of Level1&2 routing that can be enabled on the
interfaces associated with an IS-IS instance; this table also shows the
procedure for selecting these combinations via the SCS GUI.
Table 6-2
Configuration of IS-IS routing level for Interfaces
IS-IS Level Level 1 IS-IS Level 2 IS-IS SCS Configuration

configured participation participation
at the ISP for an for an
level interface interface
Level 1 Yes No No choice for the user. Level

1 routing is the only available
choice.
Level 2 No Yes Check “Level 2-only” box in

the interface configuration
screen.
Yes Yes Leave the “Level 2-only” box

in the interface configuration
screen unchecked.
On the Nortel GGSN, when an interface is added to an IS-IS routing

instance, the IS-IS routing PDUs can be transported using (a) the
interface’s native Layer 2 or (b) IP encapsulation. The choice of the
encapsulation mode is configurable (via SCS) at the granularity of an
interface.
Subscriber IP address management 6

In the Wireless ISP, GGSN VPRN, and GRE VPN network models, the
GGSN anchors the mobile subscriber IP address. Phrased another
way, all IP packets forwarded to the mobile subscriber IP address
arrive at the GGSN. That the GGSN in turn forwards these packets is
not apparent to the sender.

For packets destined to a mobile subscriber to arrive at the correct

GGSN, network nodes must have knowledge of which subscriber IP
addresses are hosted on a GGSN. One method is to configure static
routes on each node - host or router - which may be required to
forward packets to a GGSN. This approach enables deterministic
routing within the network, but can require significant time and effort to
configure and maintain.
An alternative is to enable a routing protocol within the network. When

a routing protocol is configured on the GGSN it automatically
advertises the subscriber IP addresses which it is hosting. Routers
and hosts on networks connected to the GGSN are automatically
made aware of the IP addresses hosted on the GGSN, and the best
path to send packets to the GGSN. As subscribers arrive and depart
the GGSN, routing protocols update the neighboring nodes as to
which IP addresses are available on the GGSN. A downside of this
process is that many routing updates may be required. Routing table
updates consume processing bandwidth on the network nodes and
network bandwidth between the nodes. In a worst case scenario,
routing updates can impact the ability of the network to carry
subscriber traffic.
Summary routes are used to reduce the number and size of routing
updates required within the network. A summary route is a single route
that covers a range of IP addresses rather than a single IP address.
An efficient network design dedicates a range of IP addresses to a
particular GGSN. A summary route is then published by the GGSN
covering that range of addresses.
Note that subscriber IP addresses hosted by a GGSN must be in

distinct subnets from the subnets that contain the ISP and interface
addresses of the GGSN platform.
IP Subnet Dedication
IP Subnet Dedication on the GGSN allows the management of
subscribers’ PDP sessions by assigning end user address pools
(ranges or subnets of IP addresses) to dedicated GGSN nodes. This
approach provides more efficient management of scarce end user IP
address resources. At the same time, it reduces the amount of routing
protocol traffic required on the Gi interface.
The implication of using the IP Subnet Dedication is that all end user
IP addresses within a subnet range must be assigned to the PDP
sessions on the same GGSN node. Therefore, the allocation of the
end user IP addresses must be carefully planned and configured
within the IP network.

IP routing 6-17
The major benefits of using IP Subnet Dedication are:

• Increased scalability (a larger number of simultaneous PDP
sessions)
• Increased call processing rates (faster PDP session activation/
deactivation)
• Improved network engineering of end user IP addressing
IP Subnet Dedication configuration

IP Subnet Dedication on the GGSN is configurable using the SCS
GUI. For more information see “Global Attributes Profile”.
The Fast Ethernet Line Card (FELC) and Gigabit Ethernet Line Card
(GELC) are supported for IP Subnet Dedication on the Connection
ISP. IP Subnet Dedication must be configured for the PDP sessions
that belong to Aggregation APN. It is also the recommended
configuration for the Traditional APN.
PDP session with PPP PDU type can not take advantage of IP Subnet
Dedication. It is not applicable for the GGSN DHCP Relay Agent, VPN
or any outbound tunneling on the Gi interface.
Summary routes should be configured on the GGSN if an off-board

server is used to assign end user IP addresses. The address pool
starting address and address range must match the pool size defined
on the off-board server.
The Preserve Individual Subscriber Routes option should be disabled

when the GGSN is configured to use IP Subnet Dedication. Summary
routes eliminate the need for individual route advertisement. The
configured routing protocol (for example, RIP) advertises the summary
routes address range(s) far more efficiently than individual route
advertisements.
If a IP address is allocated by an off-board server and it is not covered

by a summary route on the GGSN, then the PDP session cannot take
advantage of IP Subnet Dedication. It is not considered an error when
using Traditional APN configurations. The PDP session is activated
without IP Subnet Dedication and fewer PDP sessions can be
activated on the GGSN. For Aggregation APNs, if an IP address is
allocated to a subscriber that is not covered by a summary route, it is
considered an error and the PDP session is rejected.
IP Subnet Dedication guidelines

When using IP Subnet Dedication, each GGSN should be configured
with IP address ranges that are advertised by the routing protocols.
These are referred to as static summary routes.

A particular IP address or IP address range is valid only for a particular

GGSN while it is included in a summary route for that GGSN. A range
of IP addresses that are advertised by a summary route can be
assigned only to PDP sessions that are activated on that GGSN.
If IP addresses are allocated by an off-board device, the off-board

device must select a suitable IP address based on the particular
GGSN on which that the subscriber’s PDP session is activated. In the
PLMN with several GGSNs, off-board servers must be configured with
address pools that exactly match the GGSN summary route
information in order to determine which IP address ranges are valid on
which GGSN.
When IP addresses are assigned statically (programmed into the

subscriber mobile or configured in the subscriber information on the
HLR), the PDP session should be restricted to the particular GGSN
where the static IP address is configured in the summary route. This
can be achieved by configuring the APN used by the subscriber on just
the GGSN where the IP address is summarized. In this case, IP
Subnet Dedication is not permitted.
RADIUS address allocation

When the RADIUS Server is responsible for the IP address allocation
and the IP Subnet Dedication is enabled on the GGSN, the following
configuration should be adopted by the RADIUS Server and GGSN:
• On the GGSN:
— Each GGSN should be configured to advertise the summary
routes of end user IP addresses that the GGSN is responsible
for.
— IP Subnet Dedication should be configured in the Global
Attribute Profile.
— Ensure that the Preserve Individual Subscriber Routes is not
selected.
• On the RADIUS Server:
— Ensure that each RADIUS Server is configured to allocate an IP
address based on the summary route that the GGSN is
configured with. This can be achieved by allocating IP
addresses based upon the NAS-IP-Address and NAS-Port
attributes in the RADIUS Access-Request message. The NAS-
IP-Address is the address of the Connection ISP that originates
the RADIUS Access-Request message.

IP routing 6-19
When an IP Address is no longer needed, it is returned to the address

pool based upon the NAS-IP-Address attribute in the RADIUS
Accounting STOP message sent by the GGSN.
Figure 6-3
Example configuration of RADIUS address allocation
GGSN Node: GGSN1_1 RADIUS Node: RADIUS_1

NAS-IP Addr: 192.192.1.18
NAS-IP Addr: 192.192.1.18
start addr: 192.5.1.1 mask: 24
Summary Route Advertisement Info:
start addr: 192.5.1.1 mask: 24 NAS-IP Addr: 192.192.1.17
DNS start addr: 192.3.1.1 mask: 20
NAS-IP Addr: 192.192.1.16
GGSN Node: GGSN_2 start addr: 192.1.1.1 mask: 24
NAS-IP Addr: 192.192.1.17
PLMN
Gn
GGSN Node: GGSN_3

NAS-IP Addr: 192.192.1.16 Service
Summary Route Advertisement Info: Network
SGSN start addr: 192.1.1.1 mask: 24 Gi
RADIUS static address allocation

When a RADIUS Server is configured to allocate a static IP address
for a subscriber, in some scenarios, the PDP session may not be able
to activate if the GGSN is configured to use IP Subnet Dedication.
In order to support static IP address allocation, the subscriber’s APN

should be configured on a specific GGSN so that the PDP session is
always activated on the same GGSN. This is because IP addresses
must be allocated based on the summary route configuration on the
GGSN. Since the PDP session is always activated on the same
GGSN, if that node is unavailable, the subscriber will not be able to
activate a PDP session.
DHCP address allocation

When using DHCP Server to allocate IP addresses, it should be
configured to allocate IP addresses from named pools to benefit IP
Subnet Dedication. This allows the DHCP Server to allocate a IP

address based on the GGSN that sends the DHCP Discover message.
The pool name configured on the GGSN is sent to the DHCP Server in
the User Class ID Option.
On the GGSN, the pool names are configured in the DHCP Profile.
This pool name is sent to the DHCP Server. In order to request an IP
address that matches the summary route information, the pool name
must be unique in the IP network on the DHCP Server. Figure 6-4
shows an example of DHCP address pool configuration when IP
Subnet Dedication is enabled on the GGSNs. In this example, the
address pools configured on the DHCP Servers are unique and the
starting address and pool size are matched exactly by the summary
route configuration on the GGSN where the pool is used.
Figure 6-4
Example configuration of DHCP address allocation
GGSN Node: GGSN_1 DHCP Node: DHCP_1

DHCP profile_1: pool name = pool_2
pool name = pool_1 start addr: 192.3.1.1 mask: 24
pool name = pool_3
DNS start addr: 192.1.1.1 mask: 24
pool name = pool_1
GGSN Node: GGSN_2
DHCP profile_2:
pool name = pool_2
PLMN
Gn
GGSN Node: GGSN_3

DHCP profile_3: Service
pool name = pool_3 Network
Gi
SGSN Summary Route Advertisement Info:
Route redundancy 6
The GGSN supports Equal Cost Multi-Path (ECMP) routing. ECMP is
a method to increase both the bandwidth and availability of
connectivity between the GGSN and the network. In ECMP, more than

IP routing 6-21
one link is capable of carrying traffic to the same destination network.

If one link fails, packets are seamlessly routed using one of the
available alternative links. The GGSN supports a maximum of six links
to a destination. Activation of ECMP is automatic on the GGSN.
It is important to note ECMP is unidirectional. It permits the GGSN to

use more than one route to a destination. However, GGSN ECMP
does not automatically create multiple equal cost routes to the GGSN
from other network nodes. ECMP must be configured on other network
nodes to permit use of multiple routes to the GGSN.
The ECMP load balancing is traffic pattern dependent. The following

points illustrate the ECMP behavior in more detail.
• The GGSN ECMP load balancing algorithm is per flow (source
address + destination address + source port + destination port +
protocol) based, in a round-robin fashion. It is independent of
routing protocol (such as OSPF).
• ECMP load balancing is also per SSP. Each SSP makes
forwarding decisions independent of other SSPs.
— If there are multiple equal cost routes to a destination, for a
given flow all traffic from the same SSP will use the same route.
Within a single SSP, traffic for a given flow is not shared
between multiple equal cost routes.
— For the same flow, traffic from a different SSP could use the
same route used by another SSP, or could choose a different
equal cost route.
The Nortel GGSN implementation of ECMP ensures that traffic is load

shared across all available interfaces. The GGSN ECMP design for
GTP data plane traffic and GTP control plane traffic are as follows:
Nortel GGSN implementation of ECMP ensures that traffic is load

shared across the available interfaces in the GTP data plane. Each
SSP load shares its Gn traffic across the set of available interfaces. In
a full configuration with 6 SSC cards (each SSC card has 4 SSMs with
each SSM with 4 SSPs), all 96 SSPs select an interface independent
of one another for sending traffic to a given SGSN. The net effect is
that the traffic returning to a given SGSN is load shared across the
available interfaces in the GTP data plane.
For GTP control traffic, the routing decision is made on the CMC card.
The CMC chooses one interface to return all GTP-C packets back to a
particular SGSN, and that interface is used until the interface goes
down or the CMC is forced to use another interface, or until there are
no packets between the GGSN and that particular SGSN and it times

out. Since each GGSN has one (active) CMC card processing all GTP-
C messages, all traffic back to a given SGSN is sent out on a particular
interface. This interface is used for the duration of the flow. Traffic to a
set of SGSNs is spread across all available interfaces.
In summary, the GGSN ECMP design ensures load balancing across

all available interfaces. The GGSN ECMP design load shares the GTP
data plane traffic returning to a given SGSN across the available
interfaces. For GTP control traffic, the GGSN design selects a
particular interface for routing all GTP control plane traffic until the
interface goes down or it is forced to use another interface or
connectivity times out.
The GGSN does not guarantee symmetric routing of packets. The

responses do not necessarily go out of the same interface upon which
the request arrived.
It is possible to force symmetric traffic by setting up the multiple

interfaces to have UNequal cost. The GGSN will always choose the
lower cost route, as long as it is available. If the far end router is also
provisioned to use the same route as lower cost, then traffic is
symmetric. This routing architecture uses the available links in a
primary/secondary manner rather than a load sharing manner. This
routing architecture approach does lower the bandwidth to/from the
GGSN because it does not load share traffic across multiple available
links, but it does allow for ease of troubleshooting by knowing which
link is a primary interface and which link is the secondary interface.
Gn Interface ECMP
On the Gn interface all traffic is encapsulated within GTP between the
GGSN Gn ISP and an SGSN. Although this is frequently referred to as
one GTP tunnel, the GGSN can forward these GTP packets out of
several Gn interfaces. Each SSP independently chooses an interface
from which to forward GTP packets, resulting in a distribution of GTP
packets across the available interfaces.
Layer 2 switched networks 6

Proxy ARP
The GGSN is intended to operate in networks that use layer 3
switches and routers to direct traffic. The GGSN does not natively
operate in networks using layer 2 switches. This is because the GGSN
does not support proxy ARP. Because proxy ARP is not supported,
hosts within the network cannot resolve mobile subscriber IP
addresses to MAC addresses in order to communicate to the GGSN.
To facilitate operation within a layer 2 switched network a router must

IP routing 6-23
be used between the GGSN and the layer 2 network. The router will
respond to network ARP requests on behalf of the GGSN.
Gratuitous ARP
The GGSN supports Gratuitous ARP defined in RFC 2002, “IP Mobility
Support” on all trunk interfaces with Ethernet card. The GGSN
gratuitously sends an ARP message for each trunk interface when
initially brought in-service or upon a GGSN restart to inform the next-
hop routers of the trunk interface’s IP address and MAC address.
Gratuitous ARP enables the re-establishment of service in the event of
a GGSN restart, especially when not using a static MAC address.
IP multicast 6
IP multicast is a one-to-many transmission methodology which
provides the transmission of an IP datagram to a host group. The host
group is a set of zero or more hosts (subscribers) identified by a single
IP destination address. The multicast datagrams are identified as
those packets whose destinations are class D IP addresses. A
multicast datagram is delivered to all members of its destination host
group. The membership is dynamic; that is, subscribers can join and
leave groups at any time using Internet Group Management Protocol
(IGMP) messaging or group timer. The static IP multicast group
provisioning through the SCS is not supported on the GGSN.
The IGMP protocol is used by the GGSN to learn the existence of host
group members on all locally attached IP interfaces. The GGSN acts
as a IGMP proxy. This means the GGSN plays the role of a multicast
router toward subscribers by periodically sending IGMP Membership
Query to all its subscribers. The IGMP message is encapsulated in a
GTP tunnel on the Gn interface. Both IP and PPP PDU types are
supported for IGMP proxy. The GGSN also plays the role of a
multicast host to the upstream multicast routers by sending the IGMP
Membership Report message and Leave Group message on behalf of
its subscribers. The IGMP membership Report message is sent when
the first member is joining the group or a Membership Query message
is received. The Leave Group message is sent when the last member
in the group is leaving. The IGMP proxy function only works with the
Wireless ISP model due to the inability to recognize IGMP messages
on the Gi interface in other network models. IGMPv2 defined in RFC
2236, “Internet Group Management Protocol, Version 2” is supported
by the GGSN and it is backward compatible with IGMPv1.
IP address in GTP signaling message 6

To properly engineer the wireless IP network, it is important to
understand how the GGSN uses IP addresses when originating or
responding to GTP messages on the Gn interface. The GGSN

operates differently on GTP version 0 versus GTP version 1

messages. The operational characteristics of each are described in
the following sections.
The Gn ISP of the GGSN is configured with two types of IP addresses

- interface addresses are assigned to each trunk interface, as well as
the Gn ISP default (or loopback) address. GSNs forwarding GTP
packets to a GGSN may set the destination address of those packets
to either the interface or loopback address and the packets will be
correctly handled by the GGSN. This is true of both GTP-C and GTP-U
packets.
However, the interface and loopback addresses should not be

considered equally good choices as the destination of a GTP packet.
The loopback address is strongly favored over the interface addresses
for reliability reasons. In a properly configured network, the Gn ISP
loopback address may be reached via more than one link on the Gn
ISP. For example, if the Gn ISP has three links and one has failed, all
GTP packets addressed to the Gn ISP loopback interface can be
delivered over the remaining two in-service links.
In contrast, GTP packets addressed to an interface address of the Gn

ISP must be delivered using only the specific link identified by that
interface address. If the link associated with the destination address is
out of service, then the packet cannot be delivered and is dropped.
This is true even if other interfaces are available and in-service on the
Gn ISP.
GTP Version 0
GTP version 0 packets may be addressed to either the Gn ISP
loopback address or an interface address on the Gn ISP. As discussed
previously there are significant advantages to using the loopback
address.
When replying to version 0 GTP-C messages originated by other GSN

nodes, the GGSN swaps the source and destination IP addresses in
the received message and uses these swapped addresses as the
destination and source, respectively. Hence the source address of the
reply message is the address on the GGSN to which the originating
GSN node sent the message.
When originating version 0 GTP-C messages to other GSN nodes (as

opposed to replying), the GGSN always uses the Gn ISP loopback
address as the source address of the message in the IP header. The
GGSN never originates messages using the IP address of an interface
as the source IP address of the message.

IP routing 6-25
Version 0 GTP-U packets are always forwarded to the SGSN using the
Gn ISP loopback address as the source IP address of the packet.
(Note this applies only to the outer IP header used for GTP
encapsulation. The inner IP header associated with the subscriber
packet is not modified.)
GTP Version 1
GTP version 1 packets may be addressed to either the Gn ISP
loopback address or an interface address on the Gn ISP. As discussed
previously there are significant advantages to using the loopback
address.
When replying to version 1 GTP-C messages originated by other GSN

nodes, the GGSN always uses the Gn ISP loopback address as the
source address of the message in the IP header. In this scenario, the
source IP address of the reply message from the GGSN may be
different than the address to which the originating GSN node sent the
message. This situation occurs when the originating GSN sends the
message to an interface address of the Gn ISP on the GGSN.
When originating version 1 GTP-C messages to other GSN nodes, the

GGSN always uses the Gn ISP loopback address as the source
address of the message in the IP header. The GGSN never originates
messages using the IP address of an interface as the source IP
address of the message.
Version 1 GTP-U packets are always forwarded to the SGSN using the
Gn ISP loopback address as the source IP address of the packet. This
applies only to the outer IP header used for GTP encapsulation. The
inner IP header associated with the subscriber packet is not modified.
Source Address in RADIUS/DHCP Message 6

This source IP address can be configured to either the ISP IP address
or the physical interface address. The default value is the physical
interface address. The source IP address sent for the RADIUS
messages for all the scenarios are summarized in the following table.

Table 6-3
Source address in RADIUS message
Radius Profile VPRN properties Radius source IP

address
Use ISP IP address: Radius VPN: No ISP IP address

Yes
Radius Local: No
Use ISP IP address: Radius VPN: Yes ISP IP address

Yes
Radius Local: No
Use ISP IP address: Radius VPN: No Trunk Interface IP

No address
Radius Local: No
Use ISP IP address: Radius VPN: Yes Access sub IP

No address
Radius Local: No
Use ISP IP address: Radius VPN: Yes VPN Local IP address

Yes
Radius Local: yes
Use ISP IP address: Radius VPN: Yes VPN Local IP address

No
Radius Local: Yes
For the DHCP messages the following table provides the source IP
address selected for all the scenarios.
Table 6-4
Source address in DHCP message
DHCP Profile VPRN properties DHCP source IP

address
Use ISP IP address: DHCP VPN: No ISP IP address

Yes
DHCP Local: No
Use ISP IP address: DHCP VPN: No Trunk Interface IP

No address
DHCP Local: No

IP routing 6-27
Table 6-4
Source address in DHCP message
DHCP Profile VPRN properties DHCP source IP

address
Use ISP IP address: DHCP VPN: Yes ISP IP address

Yes
DHCP Local: No
Use ISP IP address: DHCP VPN: Yes Access sub IP address

No
DHCP Local: No
Use ISP IP address: DHCP VPN: Yes ISP IP Address

No
DHCP Local: No
(Access sub IP address

is unnummered)
Use ISP IP address: DHCP VPN: Yes VPN Local IP address

Yes
DHCP Local: Yes
Use ISP IP address: DHCP VPN: Yes VPN Local IP address

No
DHCP Local: Yes
SINK routes 6
A SINK route is a route provisioned in the GGSN Forwarding
Information Base (FIB) which causes packets to be discarded rather
than forwarded. SINK routes are useful tools to prevent bounced
packets.
A bounced packet is one that is repeatedly forwarded between a

GGSN and its next hop router until the Time To Live (TTL) is
exhausted and the packet discarded. Bounced packets consume
network and processor bandwidth without ever being delivered to their
final destination.
Bounced packets may occur when packets arrive at the GGSN for a
deleted PDP context. This situation can occur when subscribers close
their PDP context in the middle of a transaction, when the mobile
moves out of radio coverage, etc. Because the GGSN does not have
an active subscriber using the IP address to which the packet is
addressed, it uses the next best matching route in the FIB to forward
the packet. The next best match is frequently a default route directing
the packet back to the next hop router from which it originated. The

next hop router in turn forwards the packet back to the GGSN, and the
cycle repeats. Default routes are commonly used to forward all IP
packets not destined for mobile subscribers out of the GGSN toward
intranets, the Internet, etc.
The bouncing packets problem can occur when a two-level routing

hierarchy is used in the GGSN FIB. The FIB contains a host route (one
that matches all 32 bits of the IP address) for every active subscriber
on the GGSN, and also summary or default routes - ones which
partially match a large range of addresses. In a typical deployment the
subscriber host routes (which are automatically added and deleted as
PDP contexts are activated and deleted) are used to route arriving
packets to the correct mobile subscribers, while default routes are
used to forward packets sent by mobile subscribers toward their final
destination.
The solution to the bounced packets problem is to add a third level to

the routing hierarchy, between host routes and default routes. It
involves the addition of SINK routes to the FIB. As previously
discussed, SINK routes cause matching packets to be discarded
rather than forwarded. This behavior is desirable when packets arrive
at the GGSN intended for a PDP context which has been deleted.
SINK routes partially match a broad range of IP addresses,
corresponding to the address pools used on the GGSN. The SINK
routes are more general than the host routes (i.e. less than 32 bits
match between route and IP address) but more specific than the
default route. As such, only packets for which there is no matching
PDP context (and host route) are captured by the SINK route and
discarded. A packet arriving at the GGSN for an active PDP context is
never discarded by a SINK route. Likewise, packets sent by a mobile
subscriber do not match the SINK routes, and are forwarded out of the
GGSN by the default route.
SINK routes are not directly provisioned on the GGSN. Rather, a

summary route is provisioned and a matching SINK route is
automatically created in the GGSN FIB. Provisioning a summary route
indicates the GGSN “owns” the range of IP addresses covered by the
summary route. If dynamic routing protocols are active, the GGSN will
advertise the summary route to its neighbors. If a network utilizes
static routes, the provisioning of a summary route on the GGSN has
no effect other than the addition of the SINK route.
SINK routes are appropriate on the GGSN when external IP address

allocation methods are used. These include RADIUS, DHCP, or static
allocation methods. It is not necessary to provision a SINK route when
local IP address pools are utilized on the GGSN; a SINK route is
automatically created when the address pool is provisioned.

IP routing 6-29
Summary routes are available only within ISPs. VPNs do not currently
support summary routes.


7-1
Hardware and engineering 7

Overview 7
The Nortel GGSN is deployed for GPRS/UMTS networks with the
following hardware components:
• Services Edge Router hardware platform
• Service Creation System (SCS) Server and Client
The Services Edge Router hardware platform provides the data packet
processing functionality for the GGSN. The SCS server and client are
used for configuring the GGSN. A single SCS server and client can be
used to provision multiple GGSNs in the GPRS/UMTS network. To
support GGSN functionality, the software loads with GGSN
functionality are required for both SCS and Services Edge Router
platform hardware platforms.
Services Edge Router hardware description 7

The GGSN functionality is supported on the SER 5500 without any
hardware modifications. Only a subset of the SER 5500 hardware is
supported in the GGSN configuration. This section lists the hardware
that is supported on the GGSN.
The Nortel Services Edge Router shelf consists of the following

components:
• Services Edge Router Chassis (DC Power) (NTJT10AA)
• Switch Fabric Card (SFC) - provides ATM interconnect and
queuing between cards
• Control and Management Card (CMC) - responsible for system
management functions
• Subscriber Service Card (SSC) - delivers scalable processing for
high touch services
• Line Cards - provide physical connectivity into and out of the shelf
• Slot Cover (NTJT16AA)

7-2 Hardware and engineering Copyright © 2000–2008 Nortel Networks
The following cards are supported on the GGSN:

• SFC with 10 Gbps Switch Fabric (NTJT20CA)
• SFC2 with 10 Gbps Switch Fabric (NTJT20FA)
• CMC2 with 1 GBytes RAM (NTJT22DA)
• CMC3 with 4 GBytes RAM (NTJT45BA)
• SSC2 with 512 MBytes RAM, 4 SSM with 3DES (NTJT29BB)
• SSC2 with 512 MBytes RAM, 4 SSM NOENC (NTJT29CB)
• SSC3 without Hifn (NTJT40AA)
• SSC3 with Hifn (NTJT41AA)
Physical connectivity
The GGSN supports the following line cards as physical interfaces on
the Gn, Gp and Gi interfaces:
• 4 port ATM STM-1/OC-3 SM (NTJT30AA)
• 4 port ATM STM-1/OC-3 MM (NTJT30BA)
• 8 port Fast Ethernet (NTJT36CA)
• 1 port Gigabit Ethernet SM (NTJT36KA)
• 1 port Gigabit Ethernet MM (NTJT36JA)
The GGSN also supports the following interface on the Management

Ethernet ports.
• 2 port 10/100 BaseT Ethernet on CMC2 card
Line card function limitations

On the GGSN, there may be some function limitations by using
different types of line cards with different kinds of trunk interface
setups. Table 7-1 describes the line card function limitations.
Table 7-1
GGSN line card function limitations
GGSN function ATM line card Fast Ethernet line Gigabit Ethernet line
card card
Aggregation APN Not supported if ATM Supported Supported

line card is used on the
Gi interface
—sheet 1 of 2—

Hardware and engineering 7-3
Table 7-1
GGSN line card function limitations (continued)
GGSN function ATM line card Fast Ethernet line Gigabit Ethernet line
card card
Number of address 150K entries 64K entries 1100K entries

entries on the line card
Attention: The address

entries are used for
mapping the incoming IP
packets to a specific SSP
based on the destination
address or TEID (i.e. for
Gn interface) in the IP
packets.
Spreading the default Not Supported Supported Supported

SSP to all SSPs
Attention: When an
incoming IP packet
cannot be mapped to a
specific SSP using the
address entries lookup,
this IP packet is
forwarded to the default
SSP.
DHCP Relay Agent Not Supported Supported if Fast Not Supported

Address Ethernet line card is
used on the Gi
interface
VLAN tagging access Not Supported Maximum 32752 Maximum 4094 VLAN
interface VLAN tag IDs can be tag IDs can be used for
used for IP frame IP frame differentiation
differentiation if Fast if Gigabit Ethernet line
Ethernet line card is card is used on the Gi
used on the Gi interface
interface
ATM access interface Supported if ATM line Not Supported Not Supported
in ATM VPN card is used on the Gi
interface
—sheet 2 of 2—

Attention: Inserting a new FELC card into a non high density slot
(green colour on the chassis) will result in session errors on the SCS
for ports 5 through 8.
Impact: No service impact, other than the session errors.
Workaround: Performing a resync on the GGSN will allow the SCS to

correctly configure the FELC card to contain 4 ports instead of 8 in a
non high density slot.
SCS server and client

Hardware platform
The following hardware platforms are supported for the GGSN SCS
Server:
• Sun Fire V880 (SFv880) Server
• Sun Enterprise 450 (E450) Server
• Sun Enterprise 250 (E250) Server
• Sun Netra 240 Server
All servers are supported for the software upgrade from older
releases. The E450 and E250 servers are not recommended for the
new software installation. The SFv880 server is recommended for all
SCS Server hardware platforms in order to achieve the synergies
within the Nortel UMTS/GPRS wireless product line.
Table 7-2 through Table 7-7 list the minimum system requirements for
each hardware platform.
Table 7-2
Minimum system requirements for Sun SFv880
Configuration Domain Server Region Server Region Server

(Support up to (Support up to 16 (Support up to 8
10+ regions) SER 5500s) SER 5500s)
Minimum 4GB 4GB 2GB

Memory
CPUs 4 CPUs 4 CPUs 2 CPUs
Free Disk 20GB 20GB 20GB
Operating Solaris 9 Solaris 9 Solaris 9

System

Table 7-3
Configuration Domain Server Region Server Region Server

(Support up to (Support up to 16 (Support up to 8
10+ regions) SER 5500s) SER 5500s)
Minimum 4GB 4GB 2GB

Memory
CPUs 4 CPUs 4 CPUs 2 CPUs
Free Disk 20GB 20GB 20GB
Operating Solaris 9 Solaris 9 Solaris 9

System
Table 7-4
Configuration Region Server (Support up to 8

GGSNs)
Minimum Memory 2GB
CPUs 2 CPUs
Free Disk 20GB
Operating System Solaris 9
Table 7-5
Minimum system requirements for Sun E450
Configuration Domain Server (Support Region Server (Support

up to 10+ regions) up to 16 GGSNs)
Memory 2GB 2GB
CPUs 4 CPUs 4 CPUs
Hard Disk (2) 18GB HD (2) 18GB HD
Operating System Solaris 9 Solaris 9

Table 7-6
Minimum system requirements for Sun E250

Up to 2 regions) up to 8 GGSNs)
Memory 1GB 1GB
CPUs 2 CPUs 2 CPUs
Hard Disk (1) 18GB HD (1) 18GB HD
Table 7-7
Minimum system requirements for Sun Netra 240

Up to 2 regions) up to 8 GGSNs)
Memory 2GB 2GB
CPUs 2 CPUs 2 CPUs
Hard Disk Two 146GB HD Two 146GB HD
Software versioning
The SCS Server software releases incorporate a number of third party
software packages. Some of these packages are: SOLID Embedded
Engine, Netscape Directory Server (NDS) LDAP and Sun operating
system. Table 7-8 specifies the versioning of the incorporated
software packages:
Table 7-8
Third party software versioning
Software Package Version Number
SOLID Embedded Engine Version 4.0
iPlanet Directory Server Version 5.1
Operating System Solaris 9
Veritas Netbackup DataCenter Version 4.5

Server Disk Partitioning

It is recommended to install 2 hard disk drives on the SCS server. The
following is an example of Sun SFv250 with 2 disk drives. Each drive
has the free space of 73GB.
Table 7-9
SCS server disk partitioning
Disk Slice No. Mounted Maximum Minimum Recomme Comment

No. Directory nded
0 0 / 14GB 6GB 12GB Root directory
1 swap 10GB 4GB 9GB
2 3GB 1GB 3GB Backup
3 /opt 24GB 10GB 21GB SCS software load is

installed in this directory.
4 /tmp 7GB 3GB 6GB It holds all temporary

files.
5 Unmounte 22GB 1GB 6GB For future use.

d
6 /usr 10GB 5GB 9GB

d
Total 68GB 29GB 60GB

Mounted
—sheet 1 of 2—

Table 7-9
SCS server disk partitioning (continued)
Disk Slice No. Mounted Maximum Minimum Recomme Comment

No. Directory nded
1 0 Unmounte 14GB 1GB 4GB For future use.

d

d
2 4GB 2GB 3GB Backup
3 /var/mail 24GB 11GB 21GB It holds the mail.
4 /export/ 14GB 6GB 12GB

home
5 /var 14GB 6GB 12GB Mount /var and /var/mail

separately.
6 /software 14GB 6GB 12GB

d
Total 70GB 31GB 60GB

Mounted
—sheet 2 of 2—
OS Hardening
OS Hardening modifies the Solaris Operating Environment to secure
the system against unauthorized access and modification. Solaris
services that present security risks are restricted or stopped. Refer to
411-5221-309, Nortel SCS and GGSN Upgrade Manual for detailed
information on the OS hardening procedure.
OS Hardening requires a script for the Solaris 9 operating system that

is executed during SCS Server installation or upgrade. OS Hardening
makes it more difficult for a malicious user to cause the damage to the
SCS Server. It ensures that only the necessary processes and file
permissions are allowed for the applications to use.
Solaris Recommended Patches

These patches are critical for Solaris OS, and they must be used for
SCS server.

SCS Server and GGSN Compatibility

Based on the N-2 compatibility rule, the SCS Server is compatible with
version N-2 to N of GGSNs. The GGSN is an UMTS/GPRS node that
runs GGSN software on the Services Edge Router hardware platform.
GGSN configuration
Minimum configuration
The minimum configuration for the GGSN consists of the following
components:
• 1 Services Edge Router platform for packet processing
• 1 SCS server and client for GGSN configuration
The minimum Services Edge Router platform configuration for the

GGSN is:
• 1 Services Edge Router chassis
• 1 CMC without redundancy
• 1 SFC without redundancy
• 1 SSC with 4 SSMII
• 1 or 2 line cards distributing ports across Gn and Gi interfaces
Scalable configuration
Based on the capacity requirements, the Services Edge Router platform
configuration can be scalable for the GGSN. The following lists the
scalability of each card:
• 1 Services Edge Router chassis
• 1 to 2 CMCs with redundancy
• 1 to 2 SFCs with redundancy
• 1 to 6 SSCs with 4 SSMII on each card
• 1 to 4 line cards on both Gn and Gi interfaces
Engineering configuration 7
To support GGSN functionality, a list of GGSN specific parameters are
configured on the GGSN as well as on the external components. This
section lists GGSN configurable parameters and their impacts to the
GGSN.
The GGSN provides enhanced functions including wireless services

and IP services. The implementation of these services on the GGSN
impacts system capacity as more system resources are required to
provide these services. System capacity and performance are
dependent on the customer specific service deployment models and

should be engineered appropriately. Operators should size the GGSN

for system capacity at initial purchasing. When increasing the set of
GGSN features or functions, it is recommended to re-size the GGSN
capacity and re-engineer the GGSN configuration.
It is also recommended that modifications to existing Service Profiles

that are currently being used by PDP sessions be restricted to the
maintenance window due to the impact to the activation rate by
changing services on a large number of PDP sessions.
ISP configuration on GGSN

The GGSN uses the concept of multiple ISPs to separate the Gn
interface, the Ga interface and the Gi interface on GGSN. A single Gn
ISP and a single Ga ISP are supported, but one or multiple Connection
ISPs are supported on the GGSN. Multiple Connection ISPs can be
used for separating the traffic of different physical interfaces (for
example, ATM, Ethernet, etc.).
Since the mapping of APN from Gn ISP to Connection ISPs can be

specified by the Connection Template setting for GTP tunnel on the Gn
ISP, the number of Connection ISPs configured on the GGSN is
equivalent to the maximum number of ISPs that can be configured on
GGSN minus 2 (one for the Gn ISP and one for the Ga ISP). There is
no performance impact based on the number of ISPs configured on
the GGSN.
CGF Profile on GGSN

Multiple CGF profiles can be configured in the Gn ISP or Ga ISP and
associated with different devices in the GTP’ Profile. Since the Gn ISP
and the Ga ISP can be configured to span multiple GGSNs, the CGF
profile is designed to be device specific. Only one CGF profile can be
selected per GGSN in the GTP’ Profile. There is no performance
impact to the GGSN based on the number of CGF profiles provisioned
in the Gn ISP or Ga ISP.
APN configuration on GGSN

Up to 2000 APNs can be configured per Connection ISP. Besides the
memory storage required to store the APN on the GGSN, there is no
performance impact to the GGSN based on the number of APNs
provisioned for the Connection ISP.
An APN contains information such as time/volume limit, maximum

number of changes and ToD tariff boundaries that trigger partial billing
or new billing container. These fields are used to determine how often
a billing container or a partial billing record should be generated for
each individual PDP session set up using this APN. The lower the

setting of these fields or the more frequently the QoS changes or ToD
tariff boundary occurs, the more often the billing containers and partial
billing records are generated. This may impact the performance of the
GGSN. The ToD settings, in particular, should be used with care.
Unlike the other settings, ToD closures happen exactly at the same
time making it even more likely that an overload of system resources
may occur, particularly if the ToD tariff changes are set very often.
The defaults are the recommended settings for the APN configuration
fields. The APN also contains an option to have Hot Billing for the APN
subscriber.
Tariff Profile on GGSN

Multiple Tariff Profile(s) can be configured on the Connection ISPs.
There is no physical limitation on the number of Tariff Profiles that can
be configured per Connection ISP. In addition to the memory storage
required to store the Tariff Profile on the GGSN, there is a performance
impact to the GGSN based on the number of Tariff Profiles.
IP Subnet Dedication on GGSN

Table 7-10 shows the recommended configuration when using IP
Subnet Dedication on the GGSN for an APN.
Table 7-10
IP Subnet Dedication APN configuration
Configuration Aggregation node Traditional node
Device IP Subnet Enabled Disabled or Enabled

Dedication
Device Preserve Disabled Disabled or Enabled

Individual Subscriber
Routes
Connection ISP Configured Optional to configure

Summary Route
On the aggregation node, IP Subnet Dedication must be enabled,

Preserve Individual Subscriber Routes must be disabled, and
summary route must be configured.
On the traditional node, IP Subnet Dedication can be enabled or

disabled. When IP Subnet Dedication is enabled, Preserve
Individual Subscriber Routes must be disabled. When IP Subnet
Dedication is disabled, Preserve Individual Routes can be enabled
or disabled.

Single APN on RADIUS Server

RADIUS Server should support sending the RADIUS Tunnel Attributes
back to the GGSN for the L2TP Outbound Tunneling function of Single
APN. The Tunnel Attributes sent back cannot be on a per-APN basis.
In a Dynamic L2TP scenario, the Tunnel Attributes should be on a per
subscriber basis.
To have the RADIUS Tunnel Attributes on the RADIUS Server

returned for a specific subscriber, the RADIUS Server should be
configured appropriately. For example, on the MetaSolv Server, the
‘radius.dct’ file must be altered. This change is to put a “r” next to the
names of the tunnel attributes (for example, ATTRIBUTE Tunnel-Type
64 integer tr). This change is applied to each of the nine RADIUS
Tunnel Attributes. The attributes must then be included in the User
Profile.
GTP-L2TP Tunnel Switching on LNS

The Nortel Services Edge Router 5500 (SER 5500) or the Nortel VPN
Router can be configured as remote LNS. When SER 5500 is used as
LNS, authentication failure including the address pool exhaustion at
LNS for the IP PDU type has the Cause Reason in Create PDP
Context Response message set to Authentication Failure. For other
failure situations, the Cause Reason is set to System Failure. When a
Nortel VPN Router is used as LNS, authentication failure at LNS for
the IP PDU type has the Cause Reason in Create PDP Context
Response message set to Authentication Failure. For other failure
situations, the Cause Reason is set to System Failure.
If the mobile already has a static IP address in the Create PDP

Context Request message, it is up to the LNS to grant the address. If
the LNS does not grant the static IP address, a different address is
allocated by the LNS and sent back to the GGSN. When “learn from
peer” box is checked through the SCS and an SER 5500 LNS is used,
the static address from the subscriber will be granted. The Nortel VPN
Router box can provide a similar function.
In the event that the LNS is not an SER 5500 or the sequence number
is required in the L2TP header, SSM redundancy is not supported
during card failure.
Address allocation on RADIUS Server

In order to load balance over multiple RADIUS Servers and have the
RADIUS Server allocate IP addresses at the same time, the RADIUS
Server should be able to allocate and release the IP address even if
the RADIUS STOP message is received on a different RADIUS Server
from the one allocating the IP address.

Otherwise, a DHCP Server can be configured behind the RADIUS

Servers to allocate the IP address. Each RADIUS Server must be set
up to communicate with the DHCP Server for IP address allocation
and release.
If load balancing and redundancy are not required (the IP address

allocation and the receipt of RADIUS STOP message for the IP
address release are on the same RADIUS Server), then the built-in
address pools on the RADIUS Server can be used.
Prepaid Service on SCP

The options for configuring coupon resource allocations are different
between CTP versions. They are described separately below.
CTP Version 1
When configuring volume based limits on a Nortel ServiceBuilder SCP
for Prepaid Service, operator has the option of Octet, KiloOctet (1024
bytes) and MegaOctet (1,048,576 bytes) segment units. The
maximum number of segment units allowed for MegaOctets is 4095. If
a value greater than the maximum number is configured, it will be
reduced to 4095.
Selecting segment units other than Octet results in the rounding of the
final message sent to the SCP equal to less than 1% of the segment
unit. Thus the total session volume reported to the SCP may be
different from the GTP Accounting and RADIUS Accounting counts by
up to 10 Octets when KiloOctets segment unit is used or 10,485
Octets when MegaOctet segment unit is used. To avoid this difference,
use only the Octet segment unit.
CTP Version 3
CTP version 3 simplifies the units allowed for volume and time-based
segment units. KiloOctets, MegaOctets, minutes, and hours are no
longer valid segment units. The only valid segment units are bytes and
seconds. Up to 4GB of volume or 136 years of time can be specified
using these units. These units are used for the Resource Authorization
within the Rated or Non-Rated Coupons.


8-1
GUI Provisioning 8
Overview 8
This chapter describes the provisioning information of Nortel GGSN
via SCS GUI. It covers only the user interfaces of GGSN related
functionality. The user interfaces of SER base functionality is not
covered here.
SCS Graphical User Interface 8

In order to support GGSN functionality on the Nortel GGSN, new
provisioning templates are introduced and a number of existing
provisioning templates from Services Edge Router are modified. They
will be detailed in the following sections.
Access Properties Provisioning

During the provisioning of an ISP through SCS GUI, a numbers of
access properties can be added and selected within the scope of the
ISP. This provisioning rule applies to Gn ISP, Ga ISP and Connection
ISPs. However, certain types of access properties are only applicable
to a certain type of ISP’s. The following is a list of access properties
that are applicable for the configuration of a Gn ISP:
• SNMP Profile
• IGMP Profile
• Connection Template
• Accounting Profile
• Accounting Element
• GTP Tunnel
• SNMP Profile
• Notification Profile
The following is a list of access properties that are applicable for the
configuration of a Ga ISP:

8-2 GUI Provisioning Copyright © 2000–2008 Nortel Networks
• GTP’ Profile
• CGF Profile
• SNMP Profile
configuration of Connection ISP:
• RADIUS Profile
• DHCP Profile
• IPSec Profile
• IKE Profile
• PPP Profile
• SNMP Profile
• IGMP Profile
• Tariff Profile
• Coupon Lists
• Coupon Profile
• Content Type Profile
• Application Profile
• ToD Profile
• GGSN QoS Profile
• Global Attributes Profile
• Redundancy Profile
• IPSec Policy
• Access Group
• APN Group
• User Agent Profile
• Connection Template
• Accounting Profile
• Accounting Element
• L2TP Tunnel
• IPSec Tunnel

GUI Provisioning 8-3
• GRE Tunnel
• Access Control Profile
• Diameter Profile
• IMSI Rules List and Billing Profile
• IMS Profile
• Content Filter Profiles
• HA Profile
configuration of a LI ISP using IPSec connection:
• IPSec Profile
• IKE Profile
• SNMP Profile
• IPSec Policy
• IPSec Tunnel
• Lawful Interception (LI) Profile
configuration of a LI ISP using VLAN access connection:
• SNMP Profile
• Lawful Interception (LI) Profile
There is no access property required for the configuration of a TPO
ISP. The TPO ISP is a separate ISP from other Gn ISP, Ga ISP,
Connection ISP and LI ISP. Only trunk interface and routing are
needed for the configuration of a TPO ISP.
In general, it is not allowed to include space in any profile name when

a new profile is provisioned.
GGSN Profiles and Templates

Access Properties Manager
The following is a list of profiles and templates added to the Access
Properties of SCS menu as shown in Figure 8-1 for supporting GGSN
functionailies:
• Tariff Profiles

• Application Server Profiles

• GTP’ Profile
• CGF Profiles
• ToD Profiles
• GGSN QoS Profiles
• Global Attributes Profiles
• APN Groups
• User Agent Profile
• GTP under Tunnels
• Diameter Profiles
• Access Control Profiles
• Lawful Interception Profiles
• IMSI Rules List/Billing Profiles
• Redundancy Profiles
• Coupon Lists
• Coupon Profile
• Content Type Profile
• IMS Profile
• HCM Profiles
• Content Filter Profiles
• HA Profile

Figure 8-1
Access Properties Manager
GTP’ Profile
The GTP’ Profile is added to the Access Properties for provisioning the
association between the devices and CGF Profiles when the ISP
spans over multiple devices. The DSCP selection for the QoS of the
GTP’ control packets is also included in this page on a per device
basis. This profile can be provisioned in the Gn ISP or the Ga ISP. The
following diagram shows the GTP’ Profile configuration page.

Figure 8-2
GTP’ Profile Configuration Page
Table 8-1
GTP’ Profile Configuration Tab
Field Range Default Description

Value
CGF Profile Any configured None CGF profile associated with this
CGF profiles for device
the ISP
Device Devices span None This field specifies the CGF profile for
by the ISP the specific device.
DSCP CS7, CS6, EF, DE (best DSCP marking for GTP’ control
AF43, AF42, effort) packets from GGSN to CGF
AF41, AF33,
AF32, AF31,
AF23, AF22,
AF21, AF13,
AF12, AF11, DE
PPP Profile
A PPP profile defines the properties Nortel GGSN applies when
negotiating with Point-to-Point Protocol, a protocol that encapsulates
and transmits data over point-to-point links. The PPP Profile

Configuration dialog box lets you configure new PPP profiles and edit
the parameters of current PPP profiles. The following figure and table
describe the items in this dialog box.

Figure 8-3
PPP Profile Dialog
Table 8-2
PPP Profile Configuration

Value
Profile Name 32 Characters None Name of the PPP Profile

string
—sheet 1 of 2—

Table 8-2
PPP Profile Configuration
Authenticatio CHAP First, CHAP First Authentication protocol preferences

n Protocol PAP First,
CHAP Only,
PAP Only
Restart Timer 3 - 30 10 Number of seconds in which the PPP link must

be authenticated before resending the
authentication packet.
Max. Failure 3 - 30 6 Number of failed authentication attempts

allowed.
Echo Interval 1 - 86400 3600 Interval separating LCP echo requests.
Max Echo 3 - 10 4 Number of echo requests that do not receive

echo-replies before the SER†5500 assumes that
the peer cannot respond.
Max 3 - 30 10 Number of configure requests that can go

Configure unacknowledged before assuming that the peer
can not respond.
Max 2 - 10 2 Number of terminate requests that can go

Terminate unacknowledged before assuming that the peer
cannot respond.
Max Failure 3 - 30 10 Maximum number of times LCP is allowed to fail

to configure a PPP connection before timing out.
Restart Timer 1-10 3 Period of time in which a terminate or configure

request must complete transmission before
timing out and retransmitting.
MTU Size 0 - 65536 1500 Greatest size packet that the PPP connection
can support.
Async Selected or Not Not Selected Select to enable or disable flow control using
Control Selected Async Control Character Map (ACCM).
Character
Map
Enable Selected or Not Selected Enables/disables ACFC.

ACFC Selected
Enable PFC Selected or Not Selected Enables/disables PFC.

Selected
—sheet 2 of 2—

CGF Profile
The CGF Profile is added to the Access Properties of SCS menu for
supporting GGSN functionality. The following figure shows the CGF
Profile configuration in an ISP.
If the device associated to the CGF doesn’t have the configuration of a

static route to the CGF, it is recommended that the maximum retries
value provisioned in the CGF Profile is greater than 0. This is due to
the fact that the dynamic route to the CGF may not be added until the
GGSN accounting software attempts to send a Node Alive request to
the CGF.

Figure 8-4
General Tab of the CGF Profile Dialog
Table 8-3
CGF Profile General Tab

Value
Profile Name 32 Characters None Name of the CGF Profile

string
Maximum 0-5 3 Maximum of Retries for sending accounting

Retries records to CGF
—sheet 1 of 3—

Table 8-3
CGF Profile General Tab (continued)
Encoding ASN.1-BER or ASN.1-BER Encoding Scheme for GGSN accounting record

Scheme ASN.1-PER send to CGF
GCDR V3.2 or V3.6 V3.2 G-CDR for GGSN billing record as specified in
Record 32.015 V3.2/V3.6
Version
Include CBB Selected or Not Not Selected Enable/Disable including Content Based Billing
Selected Management Extension.
CBB Version 2, Version 2 The version number of CBB management

Management Version 3, extension. Different versions have different
Ext Version 4, values in the Object ID field of management
Version 5, extension.ID field of management extension.
Version 6
Version 2: Include uplink/downlink volume usage
per content typeid (content type id supported
only between 0 - 4)
Version 3: Includes uplink/downlink volume

usage per content typeid

usage, time usage per content typeid

usage, time usage per content typeid, first packet
mark per content typeid, remaining inactivity time
per content typeid.

usage, time usage per content typeid, first packet
mark per content typeid, remaining inactivity time
per content typeid, and event count
CDR file 10 minutes to 30 minutes Maximum amount of time that a G-CDR-file ram
open time 1440 minutes buffer will remain open before being closed by
limit (24 hours) in 1 the billing system (see note below for CDR file
minute size limit)
increments
CDR file size 100 KBytes to 1024 KBytes Size limit for G-CDR file
limit 1024 KBytes in
1 KByte The G-CDR-file ram buffer is closed when the
increments buffer reaches either the size limit or the open-
time limit, whichever limit is reached first
—sheet 2 of 3—

Table 8-3
CGF Profile General Tab (continued)
Include IMEI- Selected or Not Not Selected Enable/disable including IMEI-SV management
SV Selected extension.
(Disabled)
Include RAT Selected or Not Not Selected Enable/disable including RAT management
Selected extension.
(Disabled)
Include Selected or Not Not Selected Enable/disable including PLMN Identifier

PLMN Selected management extension.
Identifier (Disabled)
Include Selected or Not Not Selected Enables/disables the user’s Location Information
Location Info Selected to be included in the G-CDR record.
(Disabled)
Include DCC Select or Not Not Selected Enable/disable DCC events to be included in the
Event Select G-CDR record.
Include Selected or Not Not Selected Enables/disables HSDPA to be included in the G-

HSDPA Selected CDR record.
(Disabled)
Include Selected or Not Unselected Enable/Disable including Parking Meter G-CDR

Parking Selected Management extension in the G-CDR.
Meter
PM Version 1, Version 1 The version of Parking Meter G-CDR

Management Version 2 and Grayed Management extension in the G-CDR.
Extension out
—sheet 3 of 3—

Figure 8-5
CGF Profile Server Page
Table 8-4
CGF Profile Server Tab

Value
Server IPv4 IP address None CGF IP address

Address format
UDP Port Integer 3386 Port number to CGF
Response 5 - 30 seconds 7 Response timer for GTP’ response messages

Timer between GGSN and CGF.
Response timer on the GGSN needs to be aligned

with what is configured on the CGF.

Table 8-4
CGF Profile Server Tab
Echo Interval Disabled, 60 - 300 Echo timer for Echo Request and Response between
900 seconds Nortel GGSN and CGF
Response timer on the GGSN needs to be aligned

with what is configured on the CGF.
“Automated Selected or Not Not This check box can only be checked when there is at
G-CDR Selected Selected least one CGF server provisioned.
Transfer”
check box Enables or disables automatically sending G-CDR
files to CGF from disk.
“Always On” Selected or Not Selected If the check box “Automated G-CDR Transfer” is
Button Selected selected, the user must select one of the two radio
buttons - “Always On” or “Set Time”. If the user
selects “Always On”, the G-CDRs on the disk will
always be sent to the CGF
“Set Time” Selected or Not Not This button is used to enable the user to set disksend
Button Selected Selected start time and stop time
Start Time 00:01 - 23:59 None Start time for initiating automated transfer of G-CDRs
from the disk to CGF.
A value of start time same as the value of stop time is

not allowed
Stop Time 00:01 - 23:59 None Stop time for stopping automated transfer of G-
CDRs from the disk to CGF.
A value of stop time same as the value of start time is

not allowed

Figure 8-6
CGF Profile CDR Audit Page
Table 8-5
CGF Profile CDR Audit Tab

Value
Audit Enable Selected or Not Not Enable or Disable

Selected Selected
FTP Primary None None FTP transfer start time

Start Time

Table 8-5
CGF Profile CDR Audit Tab
FTP None None FTP transfer start time

Additional
Start Time
Server IPv4 IP address None FTP IP address

Address format
User Name 8 characters of None User Name with account on the ftp server
string
Password 8 characters of None Password for the corresponding user name

string
The FTP servers configured via the CDR Audit Tab refer to FTP
servers external to the GGSN to which the GGSN connects for the
periodic transfer of CDR Audit files. They are not associated with the
retrieval of the G-CDR files via FTP pull.
Time of Day (ToD) Profile

The ToD Profile is added to the Access Properties of SCS menu for
supporting GGSN functionality. The following figure shows the ToD
Profile configuration for Connection ISP.

Figure 8-7
TOD Profile General Page
Table 8-6
TOD Profile General Tab

Value
Profile Name 32 Characters None Name of the Time of Day (ToD) Profile
string
Time of Day 01:00 AM - None Time of Day for Tariff Billing

Midnight
The default value “None” for the Time of Day is not the recommended
value for the ToD billing function.
Do not put the GGSN’s busy hour as a tariff boundary in the ToD
profile configuration. This puts an additional capacity impact to the
GGSN during the busy hour.

GTP Tunnel
The GTP Tunnel is a tunnel option in the Access Properties for
supporting GGSN functionality. The following figure shows the GTP
Configuration page for a Gn ISP.
Figure 8-8
GTP Tunnel Configuration/General Page
Table 8-7
GTP Tunnel components for a Gn ISP

Value
Tunnel Name 32 Characters None Name of the GTP tunnel

string

Table 8-7
Connection All configured None Connection Template associated with the tunnel
Template connection
templates
N3 Counter 1-5 5 Maximum number of attempt make by GTP to send

a request message.
Total echo request retry time (N3 counter * T3

timer) on the GGSN needs to be configured with a
greater value than 30-40seconds (which is the time
of the CP switchover on the Nortel SGSN 7K shelf).
Otherwise, PDP contexts may be dropped by the
GGSN if it gets no answer from the SGSN after N3
* T3 time.
T3 Timer 5 - 25 (seconds) 20 GTP wait time for a response of a request

message. If no answer is received from the SGSN,
the N3 counter is incremented.
Total echo request retry time (N3 counter * T3

timer) on the GGSN needs to be configured with a
greater value than 30-40seconds (which is the time
of the CP switchover on the Nortel SGSN 7K shelf).
Otherwise, PDP contexts may be dropped by the
GGSN if it gets no answer from the SGSN after N3
* T3 time.
Echo Timer Disabled, 1 - 0 The timer for sending out Echo Request messages
300 mins (Disabled) to SGSNs to check if SGSN is still alive.
Recommended value is 2 minutes.
Control CS7, CS6, EF, DE (best DSCP marking for control packets from GGSN to
Packet AF43, AF42, effort) SGSN
DSCP AF41, AF33,
AF32, AF31,
AF23, AF22,
AF21, AF13,
AF12, AF11, DE
Device Devices span None If Gn ISP spans multiple devices, this field specifies
by Gn the Gn the specific device for the Gn ISP. If Gn ISP only
ISP belongs to one Univity GGSN, this device should
be the Univity GGSN. A device must be selected to
save a configuration.

Table 8-7
ISP Monitor Selected or Not Selected Determines behavior when an ISP is down. If
Redirect Selected selected, when an ISP is down, new Create PDP
Context Requests for the ISP are disallowed, and
existing context volume based billing is disabled.
Disallow Selected or Not Not Determines whether or not new Create PDP
PDP Context Selected Selected Context Requests are allowed on that Univity
Creations GGSN Device. This checkbox enables/disables the
“Terminate Existing PDP Contexts”.
Redirect {No Resources No When new PDP Session Creations are disallowed
Response Available (199), Resources on the Univity GGSN Device, ISP, or APN, this is
Cause System Failure Available the response cause which is returned in the create
(204), <NO (199) request failure response message.
RESPONSE>}
L2TP Secure Selected or Not Not Configuration to support enable/disable the secure
PAP Selected Selected PAP L2TP tunnel.
In the following figure, it shows device specific configuration page for

disallowing the creation of new PDP contexts on this device. The
Disallow PDP Context Creation option is used for GGSN software
upgrade. In the software upgrade, Terminate Existing PDP Contexts
option can be used for deactivating all PDP contexts on this device
right away. When PDP context is deleted in this manner, the Delete
PDP Context Request message will not be sent to SGSN.
The operational state of a Gi connection ISP is determined by the state

of its trunk connections. If all trunk connections are down, then the ISP
is also down and will not accept new PDP context activations. If no
trunk interfaces are defined, the ISP is placed in the DOWN
operational state and PDP context activations are rejected.

Figure 8-9
GTP tunnel Device configuration on Gn ISP
Table 8-8
GTP Tunnel device specific components for a Gn ISP

Value
Device Devices span None If Gn ISP spans multiple devices, this

by Gn the Gn field specifies the specific device for
ISP the Gn ISP. If Gn ISP only belongs to
one Univity GGSN, this device should
be the Univity GGSN. A device must
be selected to save a configuration.
Fault Disabled or 5- 0(Disabled) Time limit for triggering Fault Tolerant

Tolerant 60 mins billing updates.
Billing Time
Limit Enabling prevents loss of data but this
also raises the number of G-CDRs
generated and impacts the CPU
processing.

Table 8-8
GTP Tunnel device specific components for a Gn ISP
Fault Disabled or 15- 0(Disabled) Volume limit for triggering Fault

Tolerant 5000 KB Tolerant billing updates.
Billing
Volume Limit Enabling prevents loss of data but this
also raises the number of G-CDRs
generated and impacts the CPU
processing.
ISP Monitor Selected or Not Selected Determines behavior when an ISP is

Redirect Selected down. If selected, when an ISP is
down, new PDP Context creations for
the ISP are disallowed, and existing
context volume-based billing is
disabled.
Disallow Selected or Not Not Determines wether or not new PDP

PDP Context Selected Selected Session Creations are allowed on this
Creations Univity GGSN Device. This checkbox
enables/disables the “Terminate
Existing PDP Contexts”.
Redirect {No Resources No When new PDP Session Creations

Response Available (199), Resources are disallowed on the Univity GGSN
Cause System Failure Available Device, ISP, or APN, this is the
(204), <NO (199) response cause which is returned in
RESPONSE>} the create request failure response
message.
Terminate None None When this button is pressed, all PDP

Existing PDP contexts currently open on the device
Contexts will be flagged for cascading
termination. A warning/confirmation
dialog is presented to ensure user is
aware of the danger. When
confirmed, the other 2 values of this
dialog are saved to the database so
no new contexts will be established
while current contexts are being
terminated.
L2TP Secure Selected or Not Not Configuration to support enable/

PAP Selected Selected disable the secure PAP L2TP tunnel.
Figure 8-10 shows the configuration of periodic billing intervals (i.e.

volume and time) to be used for outbound roamers. This periodic
billing interval will be utilized for new PDP contexts originating in a
VPLMN (Visitor Public Land Mobile Network) or from the point where
subscriber roams into VPLMN.

Home MCC/MNC and PLMN Id mapping configurations are used to

determine the roaming status of the subscriber at PDP session
activation and modification. The PLMN Id table is configured to provide
a mapping of the SGSN’s IP address/mask to its MCC/MNC in both
the HPLMN (Home Public Land Mobile Network) and VPLMN. The
Home MCC/MNC lists the MCC/MNC of all SGSN’s in the HPLMN.
This list is associated to each GGSN within the GTP tunnel.
For a given SGSN address, a session is determined to be Home or

Roamer as mentioned below
• If no matching entry exists in PLMN Id Mapping table, the session

is Roamer.(Here the SGSN IP address with the netmask
configured in the SCS GUI is matched with the SGSN IP address
received in the PDP session activation/modification request)
• If a match exists in PLMN Id Mapping table and the corresponding
MCC/MNC exists in the Home MCC/MNC Configuration table, the
session is Home
• If a match exists in PLMN Id Mapping table and the corresponding
MCC/MNC does not exist in the Home MCC/MNC Configuration
table, the session is Roamer
In order to enable Partial Billing for Roamers function, the operator
needs to configure the Home MCC/MNC configuration and PLMN Id
mapping configuration. It is also required to enter time limit, volume
limit or both and check the Enable Partial Billing for Roamers box. If
Enable Partial Billing for Roamers box is checked but the Home MCC/
MNC and the PLMN Id mapping configuration list are empty, a warning
is displayed. In this case all subscribers will be treated as roamers.
The MCC/MNC list is limited to 15 entries. The PLMN Id mapping

doesn’t allow subnet overlap. An error message is displayed and it will
prevent operator from entering a SGSN IP address and netmask that
is overlapped with an existing entry.

Figure 8-10
GTP Tunnel Configuration/SGSN Mapping Page
Table 8-9
SGSN Mapping Configuration
Field Range Default Value Description
Enable Selected or Not Not Selected If selected partial billing for roamers
Partial Billing Selected will be enabled
for Roamers
Periodic Disabled or 1- 0 (Disabled) Time limit for triggering periodic billing

Billing Time 1440 records for roamers.
Limit for
Roamers (min)

Table 8-9
SGSN Mapping Configuration
Periodic Disabled or 1 - 0 (Disabled) Volume limit for triggering periodic

Billing 1000000 billing records for roamers.
Volume Limit (KBytes)a
for Roamers
Alternate 0, 0(minutes) Time limit for triggering RADIUS

RADIUS 1..1440(minutes interim accounting records when
Interim ) Alternate RADIUS Interim Accounting
Accounting Time Limit on the APN is Enabled.
Time Limit
SGSN IP IPv4 IP address 1.1.1.1 Home SGSN IP address

Address format
Netmask IPv4 net mask /24 Home SGSN net mask

format (255.255.255.
0)
MCC 3 digit integer None Mobile Country Code
MNC 2 or 3 digit None Mobile Network Code

integer
SGSN Group 0 (No group), 1- 0 (No group) The SGSN Group ID is provided to
255 group SGSNs for the purpose of
optimizing Prepaid Reauth signaling
and Radius Interim Billing.
RAT Unknown Unknown The serving RAT of the SGSN.
UTRAN
GERAN
WLAN
a. 1 KByte = 1024 bytes

Figure 8-11
Home MCC / MNC Records Creation
Table 8-10
Home MCC / MNC
MCC 3 digit integer None Mobile Country Code
MNC 2 or 3 digit None Mobile Network Code

integer
Figure 8-12 shows adding a new PLMN ID Mapping and the right is for
the default value.
— If the “Default” is checked, the controls “SGSN IP Address” and

“Netmask” will be grayed out.
— Only one default value can be configured, or an error message will
pop out.
— While sending the default value to a box, the field IP Address will
be set to 0.
The MCC and MNC fields can be blank when upgrading from lower
versions.

Figure 8-12
SGSN Mapping
Table 8-11
SGSN Mapping
Field Name Field Range Default Field Description

Value
SGSN IP Address IPv4 IP address None Home SGSN IP address

format
Netmask IPv4 net mask format /24 Home SGSN net mask
(255.255.
255.0)
Mobile Country 000---999 None A Public Land Mobile Network is

Code uniquely identified by its PLMN identifier.
PLMN-Id consists of Mobile Country
Code (MCC) and Mobile Network Code
(MNC).
-PLMN-Id = MCC || MNC
Mobile Country Code (MCC) identifies

the country in which the GSM PLMN is
located. The value of the MCC is the
same as the three digit MCC contained
in international mobile subscriber identity
(IMSI);

Table 8-11
SGSN Mapping
Mobile Network 000---999 None Mobile Network Code (MNC) is a code

Code identifying the GSM PLMN in that
country. The MNC takes the same value
as the two or three digit MNC contained
in IMSI;
SGSN Group ID 0 (No group), 1-255 0 (No The SGSN Group ID is provided to
group) group SGSNs for the purpose of
optimizing Pre-paid Reauth signaling
and Radius Interim Billing.
RAT Unknown Unknown The serving RAT of the SGSN.
UTRAN
GERAN
WLAN
RAT Mapping is SOC activated on a per SCS basis. The function RAT
Mapping is triggered on a per APN basis. The serving RAT is
configurable in SGSN Mapping table. When RAT Mapping is enabled,
the GGSN derives the serving RAT from the table if it is not received in
Create/Update PDP Context Request messages.
The provisioning of the RAT is optional. The provisioning of a default

value is also optional. If no default value is provisioned, “Unknown” will
be used as the default. Table 8-12 shows the logic to derive the RAT.
3GPP defined value Reserved(0) is used as Unknown for this feature.
Table 8-12
Derived RAT Mapping Logic
With “RAT Mapping” RAT RAT not received in GTP
enabled received in
GTP
Matching entry in the Use the Use the RAT of the matching entry
SGSN Mapping table received RAT
found
Matching entry in the Use the Default entry in the SGSN Use the RAT of
SGSN Mapping table not received RAT Mapping table provisioned the default entry
found Default entry in the SGSN Use “Unknown”
Mapping table not (0)
provisioned

GGSN QoS Profile

The GGSN QoS Profile is part of the Access Properties menu for
supporting GGSN functionality. A profile is selected on a per-APN
basis.
The GGSN QoS Profile contains the service profile and DSCP data
packet marking selections for every combination of Allocation/
Retention Priority (three) and Traffic Class (four) defined in the QoS
information element of the GTP Create PDP Context Request for GTP
version 1 users. A default service profile and DSCP marking is also
available from the GGSN QoS Profile exclusively for users of the GTP
version 0 QoS information element. The following figure shows to
configuration for a GGSN QoS Profile
Figure 8-13
GGSN QoS Profile
Table 8-13
GGSN QoS Profile

Value
Service All configured N/A Service profile associated with combination of

Profile service profiles Allocation/Retention Priority and Traffic Class (GTP
version 1 only). Attention: service profile exists for
every allocation/retention priority and traffic class
combination.

Table 8-13
GGSN QoS Profile

Value
DSCP CS7, CS6, EF, DE DSCP associated with combination of Allocation/

AF43, AF42, (best Retention Priority and Traffic Class (GTP version 1
AF41, AF33, effort) only).
AF32, AF31,
AF23, AF22, Attention: DSCP marking exists for every allocation/
AF21, AF13, retention priority and traffic class combination.
AF12, AF11, DE
The recommended GGSN QoS DSCPs are EF for
conversational, af33 for streaming, af23 for interactive
and de for background.
Default All configured N/A Default service profile

Service service profiles
Profile
Default CS7, CS6, EF, DE Default DSCP

DSCP AF43, AF42, (best
AF41, AF33, effort)
AF32, AF31,
AF23, AF22,
AF21, AF13,
AF12, AF11, DE
APN Group
The APN is added as an option to the Access Properties of the SCS
menu for supporting GGSN functionality. Multiple APNs can be
datafilled per ISP.
The first dialog box that appears when the ADD APN button is
selected is illustrated in the following figure. Here the APN name is
entered and the subscriber template that the APN is to associated to is
selected.

Figure 8-14
Add APN Page
Once this is completed, the APN edit page is presented. Since

individual ISPs can span multiple Nortel GGSNs, the APN edit page is
divided into two parts. The first part contains ISP specific information
that is common to all devices that have that ISP. The second part of
the profile contains ISP specific information about specific devices.
The APN naming convention on Nortel GGSN is as the following:
[A-Za-z0-9]+{[A-Za-z0-9-.]}*
It means an APN name can start with a letter or a number, followed by

letters, numbers, ‘-’ and ‘.’.

Figure 8-15
APN Group dialog

Table 8-14
APN Group General Tab

Value
Name 63 Character None Name of APN

string
Service Key 1 - 50 1 Used for the Prepaid service on SCP to authenticate

subscribers and select rate and billing period.
Subscriber All configured None Subscriber Template associated with the APN.
Template subscriber
template
IMS Profile All Configured None The IMS Profile to be returned to the mobile when P-
IMS Profile CSCF discovery is requested.
If this field is empty, P-CSCF discovery is disabled

for this APN.
HA Profile 32 character None Name of an HA profile previously provisioned.

string Applies the named list to this APN
Aggregation Selected or Not Not Designates this APN as supporting only Aggregation
Selected Selected mode GTP Sessions with subset of available
features & services.
WAP Selected or Not Not Select if Session Mode is required for the APN.
Session Selected Selected
Mode
PLMN ID Selected or Not Not Enable/disable PLMN id Mapping on a per-APN

Mapping Selected Selected basis
SIP Selected or Not Selected Used to determine if SIP inspection is required on

Inspection selected SIP packets belonging to sessions of the APN.
“RAT Selected or Not Not Enable/disable RAT Mapping

Mapping” selected Selected
“SGSN Selected or Not Not Enable/disable SGSN Grouping

Grouping” selected Selected
GGSN QoS All configured N/A GGSN QoS Profile associated with the APN.
Profile GGSN QoS
profiles

Table 8-14
APN Group General Tab

Value
Support QoS Selected or not Not Enables/Disables to support the Release 5 QoS
Release 5 Selected Selected format needed to support HSDPA.
Format
Allow QoS Selected or Not Not If this checkbox is not selected, any QoS profiles
Signalling Selected Selected received will be downgraded (i.e. the Signalling
Indication Indication in the PDP response will be set to No)
APN blacklist Selected or Not Not Indicates whether APN blacklist is enabled.
enabled Selected Selected
APN blacklist 1 - 7200 Integer 100 Once the provisioned threshold is crossed, the APN
failure is blacklisted for that specific GGSN throughout the
threshold interval described below.
APN 1 - 86400 300 Blackout time interval in seconds during which time
blackout Integer all PDP context requests to the APN are blocked.
interval
TCP MSS Selected or Not Not This checkbox is used to enable/disable TCP MSS
Clamping Selected Selected Clamping feature.
enabled
TCP 536 - 1460 1424 Configured value for TCP MSS attribute in a range
Maximum from 536 - 1460. The default value is 1424.
Segment
Size This field is enabled only if “TCP MSS
Clamping“checkbox is checked.
The following figure shows the device specific configuration page for
adding Tariff Profile/WAP profile to an APN.

Figure 8-16
APN Device Specific Configuration Page
The Tariff and/or WAP profiles selected are applied only to the device
that is selected.
Table 8-15
APN Specific Device Configuration Tab

Value
Tariff All configured None Specify SCP profile used for Prepaid Service and
Tariff Profiles on GeoZone service for APN.
the ISP
Credit Control All configured None Specify Credit Control profile used for Credit
Diameter Credit Control Service for APN.
Control and
Diameter Credit Attention: Diameter Credit + Policy Control profile
+ Policy Control can be specified for this field to provide Credit
profiles on the Control and Policy Control Service for APN.
device
Policy Control All configured None Specify Policy Control profile used for Policy
Diameter Policy Control Service for APN.
Control profiles
on the device

Table 8-15
APN Specific Device Configuration Tab
AppServer All configured None Specify Application profile used for WAP Service
AppServer for APN.
Profile on the
ISP
Device Devices None Device Name which is configured with a specific

configured for ISP.
the specific ISP
Administrative Up (Enabled) or Up When set to Down, all Create PDP Context

State Down Request messages that come to this APN are
(Disabled) rejected as per the GTP Tunnel’s Redirect
Response Cause configuration.

Figure 8-17
APN Group Accounting/Billing Page

Table 8-16
APN Group Accounting/Billing Tab

Value
TOD Profile All configured None TOD Profile associated with the APN.
GGSN TOD
profiles
IMSI Billing IMSI Billing blank This field will contain the IMSI Billing profile to be
Profile profiles used for this APN.
configured on
the provisioned
ISP
Periodic Disabled or 1 - 1440 Time limit for triggering periodic billing records.
Billing - Time 1440 (min)
Limit
Periodic Disabled or 1- 1000 Volume limit for triggering periodic billing records.
Billing - 1000000
Volume Limit (KBytes)
GTP’ Billing 1-4 4 GTP’ Billing Container number of charging

Container condition changes before triggering periodic billing
records.
QCT 0 (Disabled) - 0 QCT Inactivity timer is defined as inactivity time for

Inactivity 3600 (in a specific content type when no uplink nor downlink
Timer seconds) data traffic is received on the GGSN for a specific
content type. It is used to calculate the usage time
for a specific content type.
Exclude QCT Selected or Not Not Select this field to enable the functionality of
Timeout Selected selected Exclude QCT Timeout.
Attention: This option applies to postpaid and
prepaid billing subscribers.
SGSN Selected or Not Not Select if G-CDR generation on SGSN address

Change Selected selected changes is required for the APN
Partial Billing
Max SGSN Selected or Not Selected Use to determine if Partial billing record should be
Change Selected generated every time the maximum limit of SGSN
Partial Billing address changes is reached. This field is ignored if
“SGSN Change Partial Billing” is selected.

Table 8-16

Value
Close Selected or Not Selected If selected, a Container is closed when RAT

Container on selected Change events occur.
RAT Change
Close Selected or Not Selected If selected, a Container is closed when QoS

Container on selected Change events occur.
QoS Change
Fixed Billing Selected or Not Not This field indicates whether the Fixed Billing
Interval Selected Selected Interval is enabled or disabled on specific APN.
Generate Selected or not Selected If not selected, Zero Volume Zero Duration (ZVZD)
ZVZD G- selected containers and records that are generated by the
CDRs occurrence of a periodic billing time limit are
suppressed.
RADIUS Selected or Not Not Enable or Disable RADIUS Accounting

Accounting Selected Selected
GTP’ Billing Selected or Not Selected Enable or Disable GTP’ Billing

Selected
Enable selected/ selected Enable/Disable sending RADIUS Interim

RADIUS unselected accounting messages when the RADIUS
Interim accounting is enabled.
Messages
Enable selected/ Not Enable/Disable configuring Radius Interim

Alternate unselected Selected Accounting time limit independent of GTP' when
RADIUS RADIUS Interim Accounting is Enabled.
Interim
Accounting
Time Limit
Alternate 0, 1440 Time limit for triggering RADIUS interim accounting

RADIUS 1..1440(minutes (minutes) records when alternate RADIUS Interim
Interim ) Accounting Time Limit is Enabled.
Accounting
Time Limit
Session Selected or Not Not Enable or Disable RADIUS session mode. This
Mode Selected Selected check box will be enabled only if RADIUS
Accounting is selected.

Table 8-16

Value
Session 1 - 120 second 15 Session Mode Timer. This field will be enabled only
Mode Timer if Session Mode check box is selected. This timer
controls the time the GGSN waits for the RADIUS
START response from the RADIUS server.
Allow Write Selected or Not Selected Enable or Disable RADIUS Accounting Records to
to Disk Selected be written to the local Disk.
RADIUS Selected or Not Not Enable or Disable RADIUS disconnect.

Disconnect Selected Selected
Hot Billing Selected or Not Not Select if Hot Billing is required for the APN.
selected selected
Charging Selected or Not Not Select if G-CDR generation on Charging Rulebase

Rulebase selected changes is required for the APN.
Change selected
Partial Billing
Close Selected or Not Unselected Configuration to support closing/not closing the G-

Container on Selected CDR container on Parking Meter Series Expiry.
Parking
Meter Series
Expiry
Report DTP At Start/ On At Start Report Discrete Time Period (DTP) either ‘at Start’
Expiry or ‘on Expiry’ of the DTP envelope.
Max Number 10 - 30 10 Max Number of Completed Envelopes.

of Completed
Envelopes
Enabling the log to report the access deny on APN Group Access
page must be exercised with caution. The performance of the GGSN
can be adversely affected when large quantities of logs are generated
in the case of faulty home network entry.

Figure 8-18
APN Group Access Page

Table 8-17
APN Group Access Tab

Value
Access Deny Selected or Not Not Access Deny Log reports all rejected IMSI
Log Selected Selected
APN Session Selected or Not Not When selected it only allows the number of PDP
Limit Selected Selected sessions specified to be set up in this APN. The
range of APN Session Limit is1 - 2147483647
RADIUS RFC When enabled it defines the behavior when only

Authentication: Compliant username is provided and no password is provided
Type Default in the PCO IE
behavior
RFC Compliant If this value is selected and the password received

Default from PCO IE is NULL,GGSN rejects the call without
behavior consulting the RADIUS server.
Send only If this value is selected and the password received

password from PCO IE is NULL,GGSN sends the password
attribute and no attribute only without any value(only tag and
password value length).
Send padded
and encrypted
blank character If this value is selected and the password received
as password to from PCO IE is NULL,GGSN sends a padded and
RADIUS encrypted blank as password to RADIUS.
Attention: If both user name and password are not

provided in the PCO IE and “Anonymous RADIUS
Authentication” is enabled, then the user name and
password configured in Anonymous RADIUS
Authentication are considered.
Also if checkbox “Override Mobile supplied user

name” is selected the dropdown box”RADIUS
Authentication: Type” will be grayed out.Hence the
username and password provided in Anonymous
RADIUS Authentication will be considered
irrespective of the PCO IE value.

Table 8-17

Value
Ignore invalid Selected or Not Selected If selected, the GGSN ignores NULL values
Shasta Service Selected received for the Shasta Service Profile or Shasta
Profile and Prepaid Server VSAs and continues with the PDP
Shasta Prepaid context activation using the GGSN configured
Server values. NULL value means VSA with no data.
Anonymous Disable Disable If Disable button is selected, the anonymous

RADIUS RADIUS Authentication is disabled. If MSISDN
Authentication MSISDN button is selected, the anonymous RADIUS
Authentication is enabled for the APN and it uses
IMSI MSISDN as user name and configured password. If
IMSI button is selected, the anonymous RADIUS
User name Authentication is enabled for the APN and it uses
IMSI as user name and configured password. If
User name button is selected, the anonymous
RADIUS Authentication is enabled for the APN and
it uses the configured user name and password.
User name 28 character None Configured user name.

string
Password 6 - 20 character None Configured password.

string
Confirm 6 - 20 character None Confirm the configured password.

Password string
Add APN as Selected or Not Not If selected, APN name is added as the domain
domain selected Selected appended to the anonymous username. This field
is grayed out if "Anonymous RADIUS
Authentication" is disabled.
Override Mobile Selected or Not Not If selected, any username supplied in the PCO and
supplied selected Selected PAP protocol is overridden and the anonymous
username username (MSISDN or IMSI or configured
username) is used for RADIUS authentication. This
field is grayed out if "Anonymous RADIUS
Authentication" is disabled.
APN Selection Selected or Not Not If it is selected, the PDP session is rejected when
Mode - MS/ Selected Selected ‘MS or Network Provided APN, Subscribed Verified’
Ntwk Provided selection mode value is received.
Subscription
Required

Table 8-17

Value
Mode - MS Selected Selected ‘MS Provided APN, Subscription not Verified’
Provided selection mode value is received.
Subscription
not Required
Mode - Ntwk Selected Selected ‘Network Provided APN, Subscription not Verified’
Provided selection mode value is received.
Subscription
Not Required
User Agent Profile

An User Agent profile is added by clicking on the Add button when the
User Agent Profile folder is selected in the Access Properties
Manager. The following dialog is used to provide a name for the new
User Agent Profile.
Attention: Only one User Agent Profile may be configured per ISP.
Figure 8-19
New User Agent Profile
Table 8-18
New User Agent Profile

Value
User Agent 32 character None The name of the User Agent Profile to
Profile Name string be added

After providing a name for the new User Agent Profile, the following
dialog is used to display and edit the currently provisioned User Agent
Profile.
Figure 8-20
User Agent Profile Configuration Dialog
Table 8-19
User Agent field description
Field Name Type Maximum Default Field Description

Length Value
User Agent String 254 N/A User Agent string. Required.
Add/Modify User Agent

This dialog is user to add/modify an User Agent string to User
Agent Profile

Figure 8-21
User Agent Add/Modify Dialog
IMS Profile
An IMS Profile is added by clicking on the Add button when the IMS
Profile folder is selected in the Access Properties Manager. The
following dialog is used to provide a name for the new IMS profile.
Figure 8-22
New IMS Profile
Table 8-20
New IMS profile

Value
Profile Name 32 character None The name of the IMS Profile to be

string added

After providing a name for the new IMS Profile (or when editing an
existing Profile) the following dialog is used to display and edit the
currently provisioned IMS Profile.
Figure 8-23
IMS Profile GUI

Table 8-21
IMS profile GUI

Value
Profile Name 32 character None The name of the IMS Profile to be

string added
Number of P- 1-24 2 Number of P-CSCF Addresses to

CSCF return to mobile
Address to
Return
P-CSCF “P-CSCF IPv4 P- P-CSCF address format selection

address Directly” or “P- CSCF
format CSCF IPv4 IPv4
selection mapped IPv6” directly
P-CSCF Address can be added to IMS Profile, the number of P-CSCF

Address could be added up to 24.

Figure 8-24
P-CSCF Address List
Add IP Address
The following dialog is used to add a new IP address to the list. The
edit dialog will look very similar.

Figure 8-25
Add IP Address
Table 8-22
Add IP address

Value
IP Address Valid IP address 1.1.1.1 The IP address to be added to the list

in the range of:
[1..255].[0..255]
.[0..255].[0.254]
except loopback
(127.x.y.z) and
multicast
([224..239].x.y.z
)
Tariff Profile
The Tariff Profile is part of the Access Properties. Within the Tariff
Profile page, there are 4 tabs - General tab, Servers tab, Device tab
and CTP Version 3 Setting tab.
Tariff Profile General

The following figure illustrates the General page of the Tariff Profile.

Figure 8-26
Tariff Profile General Page
Table 8-23
Tariff Profile General Tab

Value
Profile Name 28 Character None Name of the Tariff Profile

string

Table 8-23
Tariff Profile General Tab

Value
Cluster ID 0-255 10 Cluster ID required to login to the Tariff Server
Node ID 0-255 10 Node ID required to login to the Tariff Server
Server 6 - 20 None Password for communicating with Tariff Server

Password character
string
Login Response 1-5 2 Maximum time to wait for the login response from the
Time (Seconds) Tariff Server
Response Time 1 - 15 2 Maximum time to wait for response to each query

(Seconds) from Tariff Server
Response timers on the GGSN need to be aligned

with what is configured on the Tariff Server.
Tariff Profile Servers

The following figure illustrates the Servers page of the Tariff Profile.

Figure 8-27
Tariff Profile Servers Page
Table 8-24
Tariff profile server tab

Value
Server IPv4 IP None IP Address(es) of Tariff server(s) to be datafilled.

Address(es) address Tariff server(s) can be deployed in a pair. One is
format active and the other in stand-by mode, thus two IP
addresses can be datafilled.
Tariff Profile Device

The following figure illustrates the device specific page of the Tariff
profile.

Figure 8-28
Tariff Profile Device Page
Table 8-25
Tariff Profile Device Tab

Value
Device Devices None Device name which is configured with specific ISP.
configured
for specific
ISP
Port 0-65535 0 TCP Port for Prepaid Server. Zero signifies no

connection from the device to the Prepaid Server.
Values chosen between 48700 and 48999
inclusive result in better performance on the
GGSN.
Tariff Profile Device Configuration

The following figure illustrates the window that is shown when the Add
or Edit button is pressed on the Tariff Profile Device page.

Figure 8-29
Tariff Profile Device Configuration Page
Table 8-26
Tariff Profile Device Configuration Tab

Value
Port 0-65535 0 TCP port for Prepaid Server. Zero signifies no

connection from the device to the Prepaid Server.
Values chosen between 48700 and 48999
inclusive result in better performance on the
GGSN.
Device Devices None Device name which is configured with specific ISP.
configured
for specific
ISP
Tariff Profile CTP Settings

The following figure illustrates the CTP Settings tab of the Tariff Profile
when Version 1.

Figure 8-30
Tariff Profile CTP Settings Page for version 1
Table 8-27
Tariff Profile CTP Settings Tab

Value
CTP Version 1 Version 1 Version of CTP protocol. Changing versions will

version reset all CTP parameters to the default values.
Version 3

Table 8-28
Tariff Profile CTP Settings Tab for Version 1

Value
Volume 0 - 1000 50 Data volume that is allowed if no response is

Segment (Bytes) received for re-authorization with volume counting.
Only used by CTP version 1.
Time 0 - 60 15 Length of time that a user is allowed to stay

Segment (Minutes) connected if no response is received for re-
authorization with time counting. Only used by
CTP version 1.
Volume 0 0 Length of time a volume-based coupon can be

Coupon (Disabled) (Disabled) held before it is forced to reauth with the SCP.
Timeout , Only used by CTP version 1.
1-5
(Hours)
The following figure illustrates the CTP Settings when Version 3 is

selected.

Figure 8-31
Tariff Profile CTP Settings for Version 3

Table 8-29

Value
Permit Selected or Selected If this option is selected - GGSN will permit

packets to Not packets to pass during authorization of a new
pass selected coupon or reauthorization of existing coupon(s).
Block Selected or Not If this option is selected - GGSN will block packets
packets Not Selected of a specific rate until a new coupon has been
until the Selected activated or an existing coupon has been
new reauthenticated.
coupon
has been
activated
Block data Selected or Selected If this option is selected - GGSN will block data for
for that Not that coupon rate id only when the coupon request
coupon Selected is denied. If enabled, configure the Re-auth Guard
rate id Timer.
only
Re-auth 10 - 600 60 sec This timer is started upon receiving a coupon from
Guard sec the Prepaid Server with one of the following
timer denied reasons: General Error, Insufficient Funds,
or Too Many Coupons in Use. The GGSN will not
attempt to re-authorize the coupon until this timer
expires. If a coupon is denied for some other
reason, the timer is not started and the coupon
becomes unusable for the life of the PDP context.
Tear down Selected or Not If this option is selected - GGSN will tear down the
the Not Selected context associated with denied coupon and report
context Selected back unused coupon usage when the coupon
associated request is denied.
with the
denied
coupon
re-auth on Selected or Selected If checked GGSN will reauthorize a subscriber’s

QoS Not (Enabled) coupons when that session’s QoS is changed. If
change Selected the subscriber’s coupons were previously denied,
GGSN will not reauthorize them, when that
session’s QoS is changed.

Table 8-29

Value
re-auth on Selected Selected If checked GGSN will reauthorize a subscriber’s

SGSN Not (Enabled) coupons when that session’s SGSN address is
address Selected changed. If the subscriber’s coupons were
change previously denied, GGSN will not reauthorize
them, when that session’s SGSN address is
changed.
Re-auth Selected or Selected Enable/disable triggering of real-time charging

on RAT Not (Enabled) coupon reauthorization upon a RAT change on a
change Selected per Tariff Profile basis.
Default re- 50 - 100% 100% Specifies the default re-auth threshold value for
auth coupons. This can be overridden by a threshold
threshold (Disabled) trigger set in the coupon itself. This threshold
value applies to volume and time based coupons.
The percentage value indicates how much of the
resource must be used before a re-auth will be
triggered.
Idle 0 - 3600 0 sec Specifies the default time a coupon can remain
coupon sec (Disabled) idle before it is returned to the SCP server. This
timer can be overridden by a threshold trigger set in the
coupon itself.
Keep Alive 1 - 120 20 second Keep Alive message interval. Only used by CTP
Idle Time second version 3.
Keep Alive 1 - 30 5 second Keep Alive allowed response time. Only used by
Response second CTP version 3.
Time
with what is configured on the Tariff server.
Credit Selected/ Unselected Configuration to support “total” credit usage

usage Unselected reporting
Total

Table 8-29

Value
Credit Selected or Selected • If selected, the GGSN supports receiving Event

usage Not (Enabled) quota and reporting Event usage;
Event Selected Attention: enabling this option may result in the
Usage reporting of event usage when no event quota was
received (e.g. when re-requesting a coupon that
was denied on the first request for quota of that
coupon).
• If unselected, the GGSN rejects reception of

Event quota and does not report event usage.
Default choice is Selected.
Initial 0 - 65535 no If the rate id table is configured, the GGSN will

Coupon coupons. request coupons for the listed Rate IDs (i.e.
Rate Id content type IDs) at PDP session activation. A
maximum of 5 rates can be configured in a single
profile. If the CTP version is switched to other CTP
version and then switched back, the list of coupon
rate IDs is retained until it is modified.
Application Server profile

The Application server profile can be added to the Access Properties.
Up to 8 profiles can be datafilled. Within the Application profile page
there are two tabs: the General tab and Servers tab.
Application Server Profile General

The following figure illustrates the General page of the Application
Profile.

Figure 8-32
Application Server Profile General Page
Table 8-30
WAP Profile General Tab

Value
Profile 32 None Name of Application Server Profile

Name character
string
Port 0 - 65535 0 Communication port for Application Server

Number
Retry 1 - 10 3 Maximum attempt of sending a RADIUS Request

Counter to Application Server
Timeout 1 - 30 3 Maximum time to wait for response from

Value seconds Application Server

with what is configured on the Application Server.
Threshold 1 - 1000 10 Number of unacknowledged RADIUS Requests

for SNMP before an SNMP trap is generated to warn the
Traps irresponsibleness of Application Server

Table 8-30
WAP Profile General Tab

Value
Threshold 60 - 300 60 Time to wait before recounting the

Reset unacknowledged RADIUS Request to hit the
Time Threshold for SNMP Trap again
IMSI Selected Not Enable/Disable IMSI Attribute has been sent to

Attribute or Not Selected WRAP messaging.
Selected
MSISDN Selected Selected Enable/Disable MSISDN Attribute being sent in

Attribute or Not WRAP messaging.
Selected
Application Server Profile Servers

The following figure illustrates the Servers page of the Application
Server Profile.

Figure 8-33
Application Server Profile Servers Page
Table 8-31
Application Server Profile Server Tab

Value
Server IPv4 IP None IP Address(es) of Application Server to be

Address(es) address datafilled. Application Server (s) can be deployed
format in single or duplex mode. Only one IP address is
datafilled for either mode.
Global Attributes Profile

The Global Attributes Profile page is used to configure some ISP
device parameters. The Global Attributes Profile is added, modified
and deleted by accessing the Global Attributes Properties page from
the Access Properties Manager page.
A Global Attributes Profile may be associated with a specific device by

configuring an existing Global Attribute profile in the Device
Configuration - Access Properties page.
When Preserve Individual Subscriber Routes is selected, it ensures

that the internal routing tables maintained by the Nortel GGSN will

include the address of each individual PDP session. This is required if

summary routes have not been configured on the Nortel GGSN or it is
not used by the routing protocols to advertise subscriber reachability.
However, if summary routes are configured and used to advertise
subscriber reachability, therefore the individual subscriber routing
entries are not required. When IP Subnet Dedication is selected,
Preserve Individual Subscriber Routes can’t be selected.
Figure 8-34
Global Attributes Profile Page
Table 8-32
Global Attributes Profile Tab

Value
Name 63 None Name of Global Attribute Profile

Character
string
IP Subnet Selected Not Select if IP Subnet Dedication is to be used by the

dedication to or Not Selected Nortel GGSN to manage end user IP addresses
SSP Selected for the PDP sessions.
Preserve Selected Selected Preserves individual subscriber address routes

Individual or Not even when an existing summary route covers the
subscriber Selected subscriber address. This option is for the
routes covered backward compatibility purpose. However, this
by summary option can not be selected for aggregation mode
routers or PDP sessions or when IP Subnet Dedication is
address pools selected.

Lawful Interception (LI)

The SCS GUI client is used to configure the LI feature. The following
are added to the SCS GUI:
• LI User
• LI User View Profile
• LI ISP
• LI Profile
LI User
This feature creates a special user that has exclusive access to the LI
provisioned data on the SCS GUI client. This user is referred as the “LI
user”. Only the LI user is allowed to login to the LI ISP to view and
configure LI related data. The LI user is not allowed to resync the
GGSNs. This capability is blocked on the SCS GUI client. The user
name of “_li_user” and default password of “_li_user” are used to login
to the LI ISP. It is recommended that the LI user change the password
after logging in for the first time. If the password is forgotten, the
customer must contact Nortel Networks TAS team to reset the
password.
The LI user name is unique to the SCS and is not configurable by

users. The user name and password are created at the time of SCS
installation or upgrade. The LI user name can not be modified and only
the password can be changed by the LI user. User names are listed in
the “User Manager” of the SCS GUI. The LI user name is only visible
to the LI user and not visible to other users logged into the SCS GUI.

Figure 8-35
User List
Currently, the previous Login user name and a list of SCS server
addresses connected to previously are preserved so that the next time
a user logs into the SCS GUI client, the user does not have to retype
the information. To protect the identity of the LI user, the LI user name,
“_li_user”, is not saved for the SCS Login window.

Figure 8-36
SCS Login Window
LI User View Profile

The LI user has its own user view profile for defining the LI user’s read
and write privileges among the SCS options. A user view profile with
the name of “_li_user_profile” is created at the time of SCS installation
or upgrade. The LI user view profile name is unique to the SCS and is
not configurable by users. User view profiles are listed in the “User
Manager”.
The privilege settings are fixed for the LI user view profile. All users
are not allowed to modify the name or settings of the profile. The LI
user view profile is not visible to users logged into the SCS GUI.
Figure 8-37 shows the SCS options available to the LI user when
logged into the LI ISP. The options are based on the LI user view
profile privileges.

Figure 8-37
SCS Available Options for LI ISP
LI ISP
The new LI ISP isolates the LI provisioned data. All LI configuration

must be added by logging into the LI ISP as the LI user. An ISP with
the name of “li_default_isp” is created at the time of SCS installation or
upgrade. The LI ISP name is unique to the SCS and is not
configurable by users. The LI ISP name can not be modified.
ISPs are listed in the “ISP Manager”. The LI ISP is only visible to the LI
user and not visible to other users logged into the SCS GUI.
Figure 8-38
ISP List
To configure the LI feature for a GGSN, the GGSN device must be

added to the LI ISP. Multiple GGSN devices can be added to the LI
ISP.

Attention: When LI ISP is provisioned for the 2nd SSG (or when LI
ISP is provisioned for more than 1 SSG) on the SCS server, LI ISP
(default_li_isp) appears as a VPRN.LI ISP is configured with IKE
(needed for IPSec).Anytime an ISP (even non-LI ISPs) is
configured with IKE and more than 1 SSG is added to the ISP, the
CLI commands like “show interface”, “show vprn” or “show ike sa”
start showing the ISP as VPRN even though the VPRN
configuration is not quite complete. To complete a VPRN
configuration, a VPRN group needs to be added.But as VPRN is
not supported for LI ISP configuration of VPRN is prevented. As
such, because of the side effect of configuring two or more SSG on
the same LI ISP, it appears as VPRN.
Attention: When modifying GGSN LI interface configuration from

IPSec to VLAN or vice versa, the LI target database must be reset
in order for the DF connections to connect using the new interface.
To reset target database, the ADMF can send a reset request to
GGSN or the user can remove and re-add the LI profile
configuration.
Currently, the GGSN supports 63 configurable ISPs. If the GGSN

device is added to the LI ISP, only 62 configurable ISPs are available
for the GGSN. Since the LI ISP is created from the same pool, the LI
ISP takes away one of the available ISPs.

Figure 8-39
LI ISP Device Manager
LI Profile
The new LI profile is used to configure the ADMF information. LI
profiles are configured using the LI ISP and are under the “LI Profiles”
option of the “Access Properties Manager”. Only one LI profile is
allowed to be configured for a device. LI profiles are only visible to the
LI user.

Figure 8-40
LI Profile Configuration
Table 8-33

Value
LI Profile Name 32 Characters None Name of the LI Profile

string
Device Devices None Device name of device that this profile

configured for LI is associated to.
ISP
ADMF IP IPv4 IP address None IP Address of ADMF 1

Address 1 format
ADMF Port 1 - 65535 None TCP port of ADMF 1

Number 1
ADMF IP IPv4 IP address None IP Address of ADMF 2

Address 2 format
ADMF Port 1 - 65535 None TCP port of ADMF 2

Number 2

Table 8-33
Intercept Only Selected or Not Not Select to intercept only roaming target
When Roaming Selected Selected mobile subscribers. Otherwise,
intercept all target mobile subscribers.
Visited GGSN Access Control

The Access Control profile has been newly added to the Access
Properties of SCS menu for supporting V-GGSN Access control
feature on the Connection ISP.
Access Control Profile

The Access Control Profile is added to the Access Properties page on
SCS GUI. This profile is used for the visiting GGSN access control
function to match subscriber IMSI with the MCC/MNC in the profile.
The provisioning rule of the Access Control Profile is the following:
• The maxim number of the Access Control Profiles that can be

provisioned per Connection ISP is 2000.
• The maximum number of MCC entries in the Access Control Profile
is 1000.
• The maximum number of MNC entries per MCC is either 100 or
1000 depending on whether 2 digit or 3 digit MCN is used,
respectively.

Figure 8-41
Access Properties Manager Menu / Access Control Profiles

Figure 8-42
Add New Access Control Profile
Table 8-34
Configured Access Control List Profile

Value
Access All configured None Access Control Profile

Control List Access Control associated with the APN. The
Profile t profiles default setting for this feature is
disabled for the APN if no
Access Control Profile is
selected.
Figure 8-43
Access Control Profile General Tab

Figure 8-44
Access Control Profile MCC
Table 8-35
Access Control Profile MCC Table

Value
Mobile Three None Mobile Country Code. The range is 000-999

Country Digit
Code Integer
Specify Menu of 2 2 digits Specify the digit MNC. The range for 2 digits is 00-
Digits for or 3 digits 99 and for 3 digits is 000-999
MNC
MCC/MNC Consistency
A warning dialog will pop up if no MNC is configured.

Figure 8-45
Access Control Profile MNC
Figure 8-46
Warning dialog if no MNC is configured

Figure 8-47
Add MNC Dialog
Table 8-36
Access Control Profile MNC Table

Value
Mobile Three or None Mobile Network Code. The range for 2 digits MNC
Network two digit is 00-99 and for 3 digits MNC is 000-999.
Code Integer
Remarks 32 None Operator Information. This field is optional

Character
string

Diameter Profile
Diameter Credit Control configuration can be added from the Diameter
Profiles tab of the Access properties list. If Diameter Credit Control is
disabled, the GGSN does not process any DCC configuration
message from SCS GUI or CORBA API. While DCC is disabled,
configuration of DCC profile will result in ‘out of sync’ GGSN with
session error for DCC Profile configuration.
Once the function is enabled it can only be disabled after deletion of all
DCC profiles from SCS. If DCC is disabled via SOC after having been
enabled, the DCC functionality is available for existing APN's with
DCC Profiles until the GSSN is resynced.
New Diameter Profile

New Diameter Profile Using the Diameter Tab
When adding a new Diameter Credit Control profile from the newly
created Diameter Credit Control tab of the Access properties list, the
window in Figure 8-48 will be displayed. There are three application
options:
• Credit Control: Allows user to create a diameter profile of

application type Credit Control. This profile is currently supported
by the GGSN. This application type is visible to the user only after
successful SOC activation of the Credit Control feature.
• Policy Control: Allows user to create a diameter profile of
application type Policy Control. This option is visible to the user
only after successful SOC activation of the Policy Control feature.
• Credit + Policy Control: Allows user to create a diameter profile of
application type Credit and Policy Control. This option is visible to
the user only after successful SOC activations of both the Credit
Control and Policy Control features.

Figure 8-48
New Diameter Profile from Access Properties “Diameter Profiles”
Table 8-37
New Diameter Profile
Field Name Field Range Default Value Field Description
Profile Name 32 character string None Name of the Diameter Profile
Application A drop down box with Credit Control if Application type of the Diameter
the following values: DCC feature Profile.
enabled.
Credit Control
Otherwise,
Policy Control Policy Control if
DPC feature
Credit + Policy Control enabled and
DCC feature not
enabled.

Diameter Profile General Tab
Figure 8-49
Table 8-38
Profile Name 32 character None Name previously entered for the Diameter
string Profile. Cannot be changed in this dialog.
Watchdog 6 - 60 30 Watchdog timer for Device Watchdog Request

timer and Answer between GGSN and Diameter
server.
Destination 1 - 127 “default” Destination realm will be used by Diameter

Realm character string proxies for the realm based routing

Table 8-38
Version 1 1 Diameter Profile version on Nortel GGSN. This

field is for future use and cannot be altered.
Application Credit Control, Application Indicates the application type of the profile. This
Policy Control, type from field is not modifiable.
Credit + Policy “New
Control Diameter
Profile”
Report DCC Selected or Not Selected Use Report Diameter CC Time Event Billing in
Time Event Selected G-CDR PM Extension instead of Content Type
Billing in G- Profile
CDR PM
Extension
Credit Control Service Context ID

Nortel Selected or Not Selected When checked, users can choose the Service
Specific Selected Context Identifier AVP with
"v1.ggsn.r7@nortel.com" or
"v1.ggsn@nortel.com" in the combo box.
Default is "v1.ggsn.r7@nortel.com".
Other, <string> Empty When checked, users can enter any string. If
Please the value is an unknown string, the GGSN will
specify behave as if “v1.ggsn.r7@nortel.com” was
entered.
Diameter Profile Servers Tab
Up to 2 Diameter Credit Control servers may be added to the Diameter

Credit Control profile. Both the IP address and TCP port of the target
server must be specified for each configured server.

Figure 8-50
Diameter Profile Servers Tab

Table 8-39
Diameter Profile - Servers tab

Value
Server IPv4 address in None The IPv4 address of the currently

Address dot notation configured servers.
Port 0 - 65535 3868 Port number of the currently

configured servers.
Transport TCP TCP Only TCP is supported currently.This

field is for future use & cannot be
altered.
Diameter Server General Tab
Each Diameter Credit Control profile may be configured with up to 2

Diameter Credit Control servers, each server is configured with the IP
address and port of the target server device. Multiple profiles may use
the same server IP address and port combination.

Figure 8-51
Diameter Server Profile General Tab
Table 8-40
Diameter Server Profile General Tab

Value
Server IP v4 Address None Server IP Address

Address
Port 0-65535 3868 TCP port for Diameter server
Transport TCP/SCTP TCP TCP is the only supported and

Protocol configurable transport type. This field
is for future use and cannot be
altered.
Peer Radio Button Proxy Set agent type of the DCC peer.
When either “Proxy” or “Relay” is
(Proxy, Relay, selected, the DCC client will set the P
and Direct) bit in all Credit Control Request
messages that are sent to this peer.

Diameter Server Device Specific Tab
Since Diameter Credit Control profiles may span several physical

GGSN devices, each server added to the profile must be configured
for a device. Multiple devices may use the same server IP address and
port combination. But the server configured for a Diameter Credit
Control profile is specific to that profile AND device. For example, if
two Diameter Credit Control profiles wish to use the same server
endpoint, each connection is treated independently. Changing the
status of one the server in one profile, does not affect the status of the
server in the other.
Figure 8-52
Diameter Server Profile Device Specific Tab

New Diameter Server Device Specific Settings
Figure 8-53
Table 8-41
Device Devices None Device name which is configured with

configured for specific ISP.
specific ISP
Security None, IPSEC None Security option for the communication

Options between Diameter server and GGSN
Diameter Client. The IPSEC option of
Security Options field is now
supported.
IPSec Profile IPSec profile None The IPSec profile that defines the
name security protocol for the IPSec policy.
Right-click the icon to access the
configuration dialog box. This field is
for future use and cannot be altered.
Pre-Shared Hexadecimal Hexadecimal Enables use of a security key. This

Key Format, Text Format field is for future use and cannot be
Format altered.

Table 8-41
Hexadecimal Hexadecimal None Hexadecimal value entered as the

input (0x) string pre-shared key. This field is for future
use and cannot be altered.
ASCII text Text string None The ASCII text string used for the pre-
input shared key. This field is for future use
and cannot be altered.
Online Yes or No No Determines if this configured server

should be used by the GGSN. If the
server is marked as not online, no
session messaging will be sent to the
server.
Primary Selected or Not Not Selected Indicates that this server is the
Selected primary server in the profile. When
this server is available and
communicating, it is the server used
for new session establishment. This
server is also the server used initially
after GGSN system restart.

Diameter Provisioning Restrictions
With IPSec support now enabled, it is necessary to only allow

modification to profiles that are in the “Offline” state. When a Diameter
Profile is opened, if any of the Device Specific records are in the
“Online” state, the server IP address will not be modifiable (See
“Server IP Address Locked Out”)
Figure 8-54
Server IP Address Locked Out
Also, for a given Device Specific record, if it is in the “Online” state, the
IPSec information cannot be modified (See “IPSec Profile and Key
Locked Out”).

Figure 8-55
IPSec Profile and Key Locked Out
To modify either of these values, the operator must first set the server
to “Offline” to modify the IPSec info, and must set all servers to
“Offline” to modify the server IP address.

Diameter Profile Credit Control Tab
Figure 8-56
Diameter Profile Credit Control Tab (Triggers)
Table 8-42
Diameter Profile-Credit Control Tab (Trigger)

Value
Re-auth on Selected or Not Selected If checked, GGSN reauthorizes a subscriber's

QoS change Selected (Enabled) coupons when that session's QoS is changed. If the
subscriber's coupons were previously denied,
GGSN will not reauthorize them, when that
session's QoS is changed.

Table 8-42
Re-auth on Selected or Not Selected If checked, GGSN reauthorizes a subscriber's

SGSN Selected (Enabled) coupons when that session's SGSN address is
address changed. If the subscriber's coupons were
change previously denied, GGSN will not reauthorize them,
when that session's SGSN address is changed.
Re-auth on Selected or Not Selected Enable/disable triggering of real-time charging

RAT change Selected (Enabled) coupon reauthorization upon a RAT change on a
per Tariff Profile basis. When selected, the RAT
change trigger is enabled. The quota threshold
default value to be set separately for time based
quota and volume based quota. The threshold
value can be given in either percentage of the
quota or in absolute value.
Idle coupon 0 - 3600 0 seconds Specifies the default time a coupon can remain idle
timer seconds (Disabled) before it is returned to the DCC server. This can be
overridden by a threshold trigger set in the coupon
itself.
Reset Idle Selected or Not Not This field determines if the Idle coupon time is reset
time on CCA Selected Selected on CCA receipt for coupons received in the CCA.
QCT 0 - 3600 0 seconds This timer value is used to determine when

Inactivity seconds (Disabled) subscriber data packets have temporarily ceased
Timer and so temporarily halt any usage timer associated
with the traffic. This value should be less than the
Idle coupon timer value configured above.
See the Nortel Networks Diameter Credit Control

specification for a full description and examples.

Table 8-42
Default re- 50 - 100 100 Specifies the default re-auth threshold value for
auth coupons. This can be overridden by a threshold
threshold - (when % button trigger set in the coupon itself. This threshold value
Time is checked) applies to volume and time based coupons. The
percentage value indicates how much of the
resource must be used before a re-auth will be
triggered.
Default value for time quota threshold in

percentage of DCC server granted units
(the threshold value is GrantedUnits x

SCSConfiguredPercentage)
integer 0 Default value for time quota threshold in absolute

units
(when seconds
is checked) (the threshold value is GrantedUnits -
SCSConfiguredValue)
Default re- 50 - 100 100 Default value for volume quota threshold in
auth percentage of DCC server granted units
threshold - (when % button
Volume is checked) (the threshold value is GrantedUnits x
SCSConfiguredPercentage)
integer 0 Default value for volume quota threshold in

absolute units
(when bytes is
checked) (the threshold value is GrantedUnits -
SCSConfiguredValue)
A check box “Total Credit Usage Reporting” is added to Diameter

profile dialog, as shown in Figure 8-57.

Figure 8-57
Credit Usage Reporting Dialog

Table 8-43
Credit usage reporting dialog
Field Name Field Default Field Description

Range Value
Total Credit Usage Selected/ Unselected Configuration to

Reporting Unselected support “total” credit
usage reporting

Figure 8-58
Diameter Profile Credit Control Tab (Rating Group ID)
Add Rate-Id
The GGSN Diameter Credit Control profile may be optionally

configured to request zero or more quotas in the Initial CCR message.
For example, this may be used to reduce messaging overhead for
commonly used service quotas. The set of rate-ids is configured using
the “Coupon request at session start” “Add...” button. The window in
Figure 8-59 will be displayed.

Figure 8-59
Add Rate Id Window
Table 8-44
Add Rate-id window

Value
Rating Group 0 - 65535 0 Configure the rate-id’s that the GGSN

Id will request the Diameter Credit
Control server to provide in the initial
CCR/CCA exchange.

Figure 8-60
Diameter Profile Credit Control Tab (Authorization Behavior)

Table 8-45
Diameter Profile Credit Control (Authorization Behavior)

Value
Quota exhausted Allow/Block Allow Allow/Block Traffic when re-

authorizing due to Quota Exhaustion
Quota request for a Allow/Block Allow Allow/Block Traffic when re-

category when no quota is authorizing due to initial requesting a
currently available for that coupon
category
Quota request due to Allow/Block Allow Allow/Block Traffic when re-

Change in QoS authorizing due to QoS change

Change in RAT authorizing due to RAT change

Change in SGSN authorizing due to SGSN change
Forced re-authorization Allow/Block Allow Allow/Block Traffic when re-

initiated by the DCC Server authorizing due to Server forced
reauthorization

Figure 8-61
Diameter Profile Credit Control Tab - Denied Coupon Behavior

Table 8-46
Diameter Profile-Credit Control Tab (Denied Coupon Behavior

Value
Denied coupon behavior 10 - 600 sec. 60 sec. This timer is started upon receiving a
- Re-auth Guard timer coupon from the Prepaid Server with
one of the following denied reasons:
General Error, Insufficient Funds, or
Too Many Coupons in Use. The
GGSN will not attempt to re-authorize
the coupon until this timer expires. If a
coupon is denied for some other
reason, the timer is not started and
the coupon becomes unusable for the
life of the PDP context.
Denied coupon behavior Selected or Not Selected If this option is selected, GGSN
- Block data for that Selected blocks data for that coupon rate id
coupon rate id only only when the coupon request is
denied. If enabled, configure the Re-
auth Guard Timer.
Denied coupon behavior Selected or Not Not If this option is selected, GGSN tears
- Tear down the context Selected selected down the context associated with a
associated with the denied coupon and report back
denied coupon unused coupon usage when the
coupon request is denied.

Diameter Profile Request Failure Tab
Figure 8-62

Table 8-47
Session Failover Selected or not Not selected When selected, the DCC client
Support selected supports failover, i.e. failed DCC
requests is re-directed to alternative
DCC servers. This is applicable to all
sessions.
Tx Timer 2-15 10 The maximum time to wait for a

response to each request from
Diameter Credit Control Server.if no
response is received before this timer
expires, the request is discarded and
appropriate failure handling action is
taken.
Tx Timer Event 60-65535 0 (disabled) Time Interval in seconds in which Tx

Interval seconds Timer Event occur.
Tx Event Major 10-65535 0 (disabled) Major Threshold values for Tx Timer

Threshold Event
Tx Event Critical 10-65535 and 0 (disabled) Critical Threshold values for Tx Timer
Threshold greater than Event
above threshold
(or disabled)
Request Timeout 2-180 90 The maximum life span of a pending

request.if no response is received
before this timer expires, the request
is discarded and appropriate failure
handling action is taken.
Default Failure TERMINATE TERMINATE Set default failure handling when

Handling Credit-Control-Failure-Handling AVP
CONTINUE is not received from the DCC server.
This will apply to all sessions.
RETRY_AND_
TERMINATE Determines the handling for active
Diameter sessions upon detecting the
server failure.

IMSI Rules List
Each IMSI rule list supports the definition of multiple IMSI rules. One
or more IMSI rule lists can be associated with one or more IMSI billing
profiles. A Rules List can be added when clicking on the Add button
with the Rules list folder selected.
Figure 8-63
IMSI Rules Configuration
Once the Rule list has been created, click on the add box to create a
rule.

Figure 8-64
New IMSI Rule
Attention: In order to match two different values for a digit in the

IMSI two different rules will need to be provisioned.
Table 8-48
IMSI Rule Configuration

Value
IMSI List 32 character None Name of the IMSI list

Name string
IMSI Rule *, 0 - 9 * The value in each field in the IMSI rule

means the IMSI digit in the IMSI
tested must equal that value for the
rule to match the IMSI. A value of *
means for that digit in the IMSI it can
be anything.
Once the rules are provisioned in a list, individual rules may be moved
up or down in the list. This is done by highlighting a rule, then right
mouse click and a “move up or move down” menu will show. Simply
click on the direction you want the rule to move. An IMSI is compared
with rules starting with the first rule in a list so the order the rules are
provisioned is important.
IMSI Billing Profile

An IMSI Billing profile is used to store IMSI Rule lists. Each profile can
be configured to have multiple IMSI rule lists. IMSI billing profiles are
located under the Access Properties folder on the SCS. The profiles
are provisioned on the Connection ISP.

Figure 8-65
IMSI Billing Profile Page

Figure 8-66
IMSI Billing Element Page
Table 8-49
IMSI Profile Fields

Value
Profile Name 32 character None Name of the IMSI billing profile.

string
IMSI Rules All configured None IMSI Billing Rule list.

List IMSI Rules list
on the
provisioned ISP
Time Limit Disabled or 1 - 1440 Time limit for triggering periodic billing records.
1440 (min)
(used for
both GTP
and Radius
billing)
Volume Limit Disabled or 1 - 1000 Volume limit for triggering periodic billing records.
(used for 1000000
both GTP (Kbytes)
and Radius
billing)
Max Billing 1-4 4 GTP’ Billing Container number of charging

Containers condition changes before triggering periodic billing
records.

Table 8-49
IMSI Profile Fields
Set Prepaid Checked or Unchecked If checked, set the prepaid bit in the charging
CC Unchecked characteristic.
(used for
both GTP
and Radius
billing)
Alternate 0, 1440(minut Time limit for triggering RADIUS interim

RADIUS 1..1440(minutes es) accounting records when Alternate RADIUS
Interim ) Interim Accounting Time Limit on the APN is
Accounting Enabled.
Time Limit
Once lists are provisioned in a billing profile, the lists can be moved
around. To move a list up or down in a profile right mouse click on the
list and menu will pop up. On the menu select “move up” or “move
down” and the list will move in the direction selected. When an IMSI is
compared to a list of rules it starts with the first list provisioned in a
profile, so the order the lists are provisioned in a profile is important.
There can be 1 or more IMSI billing profiles provisioned on an ISP.

Only 100 rules may be provisioned per IMSI billing Rule List and only
10 Rules List may be provisioned on an IMSI billing profile.
Software Optionality Control

A new GUI tab is added to SCS configuration window to support
license key entry, Software Optionality Control (SOC) feature
activation and deactivation.
SOC Feature Activation

The following new GUI screen allow users to enter a license key to
have control over the optional feature. Once the valid license key is
entered, the corresponding operational feature is added to the table
and displayed with “Disabled” status.

Figure 8-67
New SOC Activation Window
Table 8-50
New SOC Activation

Value
License Key 32 characters None License key providing access to

(string) optional feature.
Figure 8-68
Error dialog for invalid license key

Figure 8-69
SOC Activation Configuration Window
Table 8-51
SOC Activation Configuration

Value
Feature 256 characters None Optional feature name currently

Name (string) available for configuration.
Activation Enabled or Disabled Feature activation status in network.

Status Disabled
License Key 32 characters None License key providing access to

(string) optional feature.
The following new GUI screen allows user(s) to edit feature activation
status from “Disabled” to “Enabled” & vice versa.

Figure 8-70
Table 8-52

Value
Feature 256 characters None Optional feature name currently available for
Name (string) configuration.
Activation Enabled or Disabled Feature activation status in network.

Status Disabled
License Key 32 characters None License key providing access to optional feature.
(string)
Optional features that do require SCS provisioning cannot be disabled

from SOC GUI. If user tries to perform the operation, it results in the
following error message.
Figure 8-71
Warning dialog for disabling feature with SCS Configuration

Event Based Billing

The CBB Policy configuration is re-designed to accommodate
changes to support Event Based Billing. New configuration Dialogs
are added for POP3, SMTP and IMAP4. The MMS Content Type
specific configuration is moved and group under new “Content Type”
tab as new content type “Wireless Village” is added to be a newly
support content type for CBB.
POP3 Event Configuration

The following figure shows the rating configuration for POP3
application. The top part of the screen shows the configuration of
event specific rating information and the bottom part of the screen
shows the default rating.

Figure 8-72
Dialog for POP3 Event Description
Table 8-53
POP3 event description

Value
EVENT None POP3- RECV for POP3

RECV
Content Type 0-65535 None Content Type ID for uplink and

ID downlink data packets count and
event usage count for the EVENT
Coupon ID 0-65535 None Coupon ID for uplink and downlink

data packets count and event usage
count for the EVENT

Table 8-53
POP3 event description
Event Enabled or Disabled If Event Completion is set to Disabled,

Completion Disabled the event is counted when the event
trigger is detected.
If Event Completion is set to Enabled,

the event is only counted when the
event is completed successfully.
Content None Default Content type description for the

default POP3.
UpContTypeI 0-65535 None Content Type ID for uplink data

D packets count
DownContTy 0-65535 None Content Type ID for downlink data

peID packets count
UpCouponID 0-65535 None Coupon ID for uplink data packets

count
DownCoupo 0-65535 None Coupon ID for downlink data packet

nID count
POP3 Receive Event Configuration
The following is used to configure the coupon id, content type id and
Event completion for POP3 Receive Event.

Figure 8-73
POP3 Receive Event Configuration
Table 8-54
POP3 receive event configuration

Value
Content Type 0-65535 No Content Type ID for uplink/downlink

ID default data packets count and event usage
value count.
Base Time 60-3600 60 Base Time Interval in seconds

Interval
Time Quota Discrete, Discrete Time Quota Types:

Type Continuous
- Discrete Time Period
- Continuous Time Period
Envelope “Time Only”, Time Indicates the type of info to report in

Reporting “Time,Volume Only the G-CDR PM management
and Events” extension.
Coupon ID 0-65535 None Coupon ID for uplink/downlink data

packets count and event usage count.

Interval

Table 8-54
POP3 receive event configuration

Type Continuous
Envelope “Do Not Do Not Indicates the type of info to report in

Reporting Report“, “Time Report the G-CDR PM management
Only” and extension.
“Time,Volume
and Events”
Event Selected or Not Not If Event Completion is set to Disabled,

Completion Selected Selected the event is counted when the event
(Disable trigger is detected.
d)
Default POP3 Configuration
The following default parameters is used to configure the uplink and

downlink coupon id and content type id or POP3 Non-Event traffic.

Figure 8-74
Edit Default ID’s for POP3
POP3 Default Configuration
See Table 8-55.

Table 8-55
POP3 default configuration

Value
Uplink Content Type 0-65535 None Content Type ID for uplink data
ID packets count
Base Time Interval 60-3600 60 Base Time Interval in seconds
Time Quota Type Discrete, Discrete Time Quota Types:

Continuous
Envelope Reporting “Time Only”, Time Indicates the type of info to report in
“Time,Volume Only the G-CDR PM management
Downlink Content 0-65535 None Content Type ID for downlink data

Type ID packets count

Continuous
Uplink Coupon ID 0-65535 None Coupon ID for uplink data packets

count

Continuous

Table 8-55
POP3 default configuration
Envelope Reporting “Do Not Report“, Do Not Indicates the type of info to report in
“Time Only” and Report the G-CDR PM management
“Time,Volume extension.
and Events”
Downlink Coupon ID 0-65535 None Coupon ID for downlink data packet

count

Continuous
Envelope Reporting “Do Not Report“, Do Not Indicates the type of info to report in
“Time Only” and Report the G-CDR PM management
and Events”
SMTP Event Configuration

The following figure shows the rating configuration for SMTP

Figure 8-75
Dialog for SMTP Event Description
Table 8-56
SMTP event description

Value
EVENT None SMTP-SEND SEND for SMTP
Content Type 0-65535 None Content Type ID for uplink and

Coupon ID 0-65535 None Coupon ID for uplink and downlink

data packet count and event usage
count for the EVENT

Table 8-56
SMTP event description



default SMTP.

D packets count

peID packets count

count

nID count
SMTP Send Event Configuration
Event completion for SMTP Send Event.

Figure 8-76
SMTP Send Event Configuration
Table 8-57
SMTP send event configuration

Value
Content Type 0-65535 None Content Type ID for uplink/downlink

ID data packets count and event usage
count.

Interval

Type Continuous
Envelope “Time Only”, Time Only Indicates the type of info to report in
Reporting “Time,Volume the G-CDR PM management


Interval

Table 8-57
SMTP send event configuration

Type Continuous

“Time,Volume
and Events”

(Disabled) trigger is detected.

New Default SMTP Configuration

downlink coupon id and content type id or SMTP Non-Event traffic.

Figure 8-77
SMTP Default Configuration
Table 8-58
SMTP default configuration

Value
Uplink Content 0-65535 None Content Type ID for uplink data


Continuous

Table 8-58
SMTP default configuration


Continuous

count

Continuous
Envelope Reporting “Do Not Do Not Indicates the type of info to report in
Report“, “Time Report the G-CDR PM management
“Time,Volume
and Events”
Downlink Coupon 0-65535 None Coupon ID for downlink data packet

ID count

Continuous
“Time,Volume
and Events”

IMAP4 Event Configuration

The following figure shows the rating configuration for IMAP4
Figure 8-78
Dialog for IMAP4 Event Description
Table 8-59
IMAP4 event description

Value
EVENT None IMAP4- RECV and SEND for IMAP4

RECV,
IMAP4-
SEND

Table 8-59
IMAP4 event description
Content Type ID 0-65535 None Content Type ID for both uplink and
downlink data packets count and
Coupon ID 0-65535 None Coupon ID for both uplink and




default IMAP4.
UpContTypeID 0-65535 None Content Type ID for uplink data

packets count
DownContTypeI 0-65535 None Content Type ID for downlink data

D packets count

count
DownCouponID 0-65535 None Coupon ID for downlink data packet

count
IMAP4 Send Event Configuration
Event completion for IMAP4 Send Event.

Figure 8-79
IMAP4 Send Event Configuration
Table 8-60
IMAP4 send event configuration

Value
Content Type 0-65535 None Content Type id for uplink/downlink data packets
ID count and event usage count.

Interval

Type Continuous
Envelope “Time Only”, Time Indicates the type of info to report in the G-CDR
Reporting “Time,Volume Only PM management extension.
and Events”
Coupon ID 0-65535 None Coupon ID for uplink/downlink data packets count

and event usage count.

Interval

Table 8-60
IMAP4 send event configuration

Type Continuous
Envelope “Do Not Do Not Indicates the type of info to report in the G-CDR
Reporting Report“, “Time Report PM management extension.
Only” and
“Time,Volume
and Events”
Event Selected or Not Not If Event Completion is set to Disabled, the event is
Completion Selected Selected counted when the event trigger is detected.
(Disable
d) If Event Completion is set to Enabled, the event is
only counted when the event is completed
successfully.
IMAP4 Receive Event Configuration
Event completion for IMAP4 Receive Event.

Figure 8-80
IMAP4 Receive Event Configuration
Table 8-61
IMAP4 receive event configuration

Value
Content Type 0-65535 None Content Type id for uplink/downlink

count.

Interval

Type Continuous
Envelope “Time Only”, Time Indicates the type of info to report in



Interval

Table 8-61
IMAP4 receive event configuration

Type Continuous

“Time,Volume
and Events”

(Disable trigger is detected.
d)
Default IMAP4 Configuration

downlink coupon id and content type id or IMAP4 Non-Event traffic.

Figure 8-81
IMAP4 Default Configuration
Table 8-62
IMAP4 default configuration

Value
Uplink Content 0-65535 None Content Type ID for uplink data


Continuous

Table 8-62
IMAP4 default configuration


Continuous

count

Continuous
“Time,Volume
and Events”
Downlink Coupon 0-65535 None Coupon ID for downlink data packet

ID count

Continuous
“Time,Volume
and Events”

HTTP General Tab Configuration

The following figure shows the rating configuration for HTTP General
Tab. The top part of the screen shows the configuration of URL rating
information and the bottom part of the screen shows the rating for
HTTP Default.
Figure 8-82
Dialog Displaying General HTTP and Content Type
Table 8-63
General HTTP and content type

Value
URL None None Domain and path of the URL.

packets count
DownContTypeID 0-65535 None Content Type ID for downlink data

packets count

Table 8-63
General HTTP and content type

count

count
Per-Get Billing 0-65535 None Content Type ID for uplink/downlink

Content Type ID data packets count and event usage
count per GET event
Per-Get Billing 0- 65535 None Coupon ID for uplink/downlink data

Coupon ID packets count and event usage count
per GET event
Per-Get Billing Enabled or Disabled If Event Completion is set to Disabled,

Event Completion Disabled the event is counted when the event

Content None HTTP- Content type description for the

DEFAULT default HTTP record.

packets count

packets count

count

count
HTTP MMS Content Type Configuration

The following figure shows the rating configuration for HTTP MMS.
The top part of the screen shows the configuration of MMS Content
Type specific rating information and the bottom part of the screen
shows the default rating for HTTP Default.

Figure 8-83
Provisioning Content Type (MMS)
Table 8-64
Provisioning content type (MMS)

Value
Content None WAP MMS Description for MMS Content

packets count

packets count

count
DownCouponID 0-65535 None Coupon ID for downlink data packets

count


Table 8-64

packets count

packets count

count

count
New MMS Configuration
The following is used to configure the uplink and downlink coupon id

and content type id for MMS traffic.

Figure 8-84
MMS Configuration
Table 8-65
MMS configuration

Value
ID packets count

Continuous

Table 8-65
MMS configuration


Continuous

count

Continuous
“Time,Volume
and Events”

count

Continuous
“Time,Volume
and Events”

Wireless Village Event Configuration

The following figure shows the rating configuration for Wireless Village
shows rating for Default HTTP.
Figure 8-85
Provisioning Content Type (Wireless Village)
Table 8-66
Provisioning content type (Wireless Village)

Value
Content None WV-RECV Description for Wireless Village

Content for both receive and send
WV-SEND events.
Content Type 0-65535 None Content Type ID for both uplink and

Table 8-66





D packets count

peID packets count

count

nID count
Wireless Village Send Event Configuration
Event completion for Wireless Village Send Event.

Figure 8-86
Wireless Village Send Event Configuration
Table 8-67
Wireless Village send event configuration

Value

count.

Interval

Type Continuous


Interval

Table 8-67
Wireless Village send event configuration

Type Continuous

“Time,Volume
and Events”


Wireless Village Receive Event Configuration
Event completion for Wireless Village Receive Event.

Figure 8-87
Wireless Village Receive Event Configuration
Table 8-68
Wireless Village receive event configuration

Value

count.

Interval

Type Continuous


Interval

Table 8-68
Wireless Village receive event configuration

Type Continuous

“Time,Volume
and Events”


Default HTTP Configuration
The following parameters are used to configure the uplink and

downlink coupon id and content type id for default HTTP traffic.

Figure 8-88
Default HTTP Configuration
Table 8-69
Default HTTP configuration

Value
ID packets count

Continuous
Envelope Reporting “Time Only”, Time Only Indicates the type of info to report in
“Time,Volume the G-CDR PM management

Table 8-69
Default HTTP configuration


Continuous
Envelope Reporting “Time Only”, Time Only Indicates the type of info to report in
“Time,Volume the G-CDR PM management

count

Continuous
“Time,Volume
and Events”

count

Continuous
“Time,Volume
and Events”

HTTP MISC TabConfiguration

The following figure shows the configuration for HTTP MISC tab.
Figure 8-89
HTTP Misc Tab
Table 8-70
HTTP Misc tab
Forbidden Coupon ID 0-65535 NULL The coupon is used to capture the

byte volume of packets which
cannot be charged to the original
coupon which is in the denied state.
NULL signifies the forbidden coupon
function is disabled.

Table 8-70
HTTP Misc tab

Continuous
Envelope “Do Not Report“, Do Not Report Indicates the type of info to report in
Reporting “Time Only” and the G-CDR PM management
and Events”
Charge TCP boolean(selected unselected If the check box is unselected,the

Connection to URL /unselected) TCP connection bytes are still
rate charged against the default rate as
the first seen HTTP request arrives.
If the check box is selected, TCP
conneciton bytes will be charged
against the URL rate as the first
seen HTTP request arrives.
WAP General Tab Configuration

The following figure shows the rating configuration for WAP General
Tab. The top part of the screen shows the configuration of URL rating
information and the bottom part of the screen shows the rating for
WAP Default.

Figure 8-90
Dialog Displaying General WAP and Content Type
Table 8-71
General WAP and content type

Value
URL None None Domain and path of the URL.

D packets count

peID packets count

count

nID count

Table 8-71
General WAP and content type
Per-Get 0-65535 None Content Type ID for uplink/downlink

Billing data packets count and event usage
Content Type count per GET event
ID
Per-Get 0- 65535 None Coupon ID for uplink/downlink data

Billing packets count and event usage count
Coupon ID per GET event
Per-Get Enabled or Disabled If Event Completion is set to Disabled,

Billing Event Disabled the event is counted when the event
Completion trigger is detected.

Content None WAP- Content type description for the

DEFAULT default WAP record.

D packets count

peID packets count

count

nID count

WAP MMS Content Type Configuration

The following figure shows the rating configuration for WAP MMS. The
top part of the screen shows the configuration of MMS Content Type
specific rating information and the bottom part of the screen shows the
default rating for WAP Default.
Figure 8-91
Provisioning Content Type (MMS)
Table 8-72

Value
Content None WAP MMS Description for MMS Content
UpContTypeID 0-65535 None Content Type id for uplink data

packets count

Table 8-72
DownContTypeID 0-65535 None Content Type id for downlink data

packets count

count
DownCouponID 0-65535 None Coupon ID for downlink data packets

count


packets count

packets count

count

count

Wireless Village Event Configuration

The following figure shows the rating configuration for Wireless Village
shows rating for Default WAP.
Figure 8-92
Provisioning Content Type (Wireless Village)
Table 8-73

Value
Content None WV-RECV Description for Wireless Village

Content for both receive and send
WV-SEND events.

Table 8-73
Content Type ID 0-65535 None Content Type ID for both uplink and

Event Completion Enabled or Disabled If Event Completion is set to Disabled,

Disabled the event is counted when the event


DEFAULT default WAP record.

packets count

packets count

count

count
New Default WAP Configuration

The following parameters are used to configure the uplink and
downlink coupon id and content type id for default WAP traffic.

Figure 8-93
Default WAP Configuration
Table 8-74
Default WAP configuration

Value
ID packets count

Continuous

Table 8-74
Default WAP configuration


Continuous

count

Continuous
“Time,Volume
and Events”

count

Continuous
“Time,Volume
and Events”

WAP MISC Tab

The following figure shows the configuration for WAP MISC tab.
Figure 8-94
WAP Misc Tab
Table 8-75
WAP Misc tab
Forbidden Coupon ID 0-65535 NULL The coupon is used to capture the

byte volume of packets which
cannot be charged to the original
coupon which is in the denied state.
NULL signifies the forbidden coupon
function is disabled.

Table 8-75
WAP Misc tab

Continuous
Envelope “Do Not Report“, Do Not Report Indicates the type of info to report in
Reporting “Time Only” and the G-CDR PM management
and Events”
Traffic Performance Optimizer (TPO)

TPO ISP
A new TPO ISP selection is added to the Device Access Properties.
This is only available from the device owner ISP. The TPO ISP IP
address is used to communicate with the TPO. GGSN provides this
address to the TPO in the GRE frame. The TPO uses this address to
send all the GRE frames to the GGSN. Only one TPO ISP can be
assigned to a device.
The Device Access Properties is shown in the Figure 8-95.

Figure 8-95
Device Access Properties
Figure 8-96 shows how to assign an ISP to be the TPO ISP.

Figure 8-96
TPO ISP Selection
TPO IP Service
The TPO IP service is responsible for re-directing a packet to the TPO
server based on the TPO IP service policy configuration. The TPO IP
service is configured on the Gi ISP. In SCS GUI, the TPO Service
policy entry is added in the Service Policies selection tree. TPO Data
configuration is part of the TPO IP service configuration. The TPO
Data specifies the TPO Interface type. Type A is the only type that is
supported in this feature. TPO Interface type A is used when
interworking with Bytemobile TPO. The TPO profile configuration is
shown in Figure 8-97.

Figure 8-97
IPO data configuration
Redundancy Profiles
Figure 8-98
New Redundancy Profile Dialog

Figure 8-99
Edit Redundancy Profile Dialog--General Redundancy Panel

Figure 8-100
Edit Redundancy Profile Dialog--SSM Redundancy Panel
Table 8-76
Redundancy profile tab

Range Value
SSM Selected Not The “SSM Redundancy for Aggregation” check

Redundancy or Not Selected box enables or disables SSM redundancy for
For Selected aggregation APNs.
Aggregation
Attention: The “SSM Redundancy for Aggregation”
check box should always be checked for aggregation
APNs in order to have complete SSM Redundancy
functionality. If this check box is not selected, the SSM
Redundancy functionality will not work. PDP contexts
would temporarily be transferred to a new SSM without
allowing traffic to pass through, and once the failed SSM
recovers, the PDP contexts would move back and traffic
would resume.
Coupon Lists
The Coupon Lists is present in the Access Properties to provision
Coupon Lists and Coupon IDs.The Coupon List resides at the ISP
level. There is only one table called Coupon IDs on this profile. The
Coupon List can be accessible with ISP privilege. The “Coupon List”

configuration table contains two columns, Coupon ID and Request

Type.
Figure 8-101
Coupon List

Figure 8-102
Add and Edit Coupon
Table 8-77
Add coupon ID tab

Range Value
Coupon Id 0-65535 0 Coupon Id for CBB policy
Requested At Start)/ On Usage At Start: The coupon is requested at start

Type On Usage
On Usage: The coupon is never requested at start
Coupon Profile
Coupon Profile dialog is used to configure mappings between Coupon
Id and its attributes. This feature introduces the Base Time Interval,
Time Quota Type and Envelope Reporting as attributes of a Coupon
Id. The value of Base Time Interval is in seconds, Time Quota Type is
“Discrete“or “Continuous“, Envelope Reporting is “Do Not Report“,
“Time Only“or “Time, Volume and Events“. The maximum number of
Coupon Ids allowed in a Coupon Profile is 255.
A Coupon Profile can be associated with a CBB Policy. See figure

“Service Policy Manager” on page 202
The Coupon Profile configuration table contains four columns, Coupon

Id, Base Time Interval, Time Quota Type and Envelope Reporting.

Figure 8-103
Coupon Profile
Table 8-78
New Coupon Profile

Value
Coupon 32 character No Name of the Coupon Profile

Profile Name string default
value

Figure 8-104
Coupon Profile
Coupon Attributes Dialog

Coupon Attributes dialog is used to add or edit a mapping between
Coupon Id, Base Time Interval, Time Quota Type and Envelope
Reporting.
Figure 8-105
Coupon Attributes Dialog

Table 8-79
Parameters for Coupon Profile

Value
Coupon Id 0-65535 No Coupon Id

default
value

Interval

Type Continuous
Discrete Time Period
Continuous Time Period

Reporting Report”, “Time Report the G-CDR PM management
Only”, extension.
“Time,Volume
and Events”
“Discrete” is used for DTP and “Continuous” is used for CTP. When
both “TIME EVENT BILLING” and “CTP TIME EVENT BILLING” SOCs
are enabled, “Discrete” option is set as default value. Otherwise, either
“Discrete” or “Continuous” will be visible when one of two SOCs above
is enabled.
Content Type Profile

Content Type Profile dialog is used to configure mappings between
Content Type Id and its attributes. This feature introduces the Base
Time Interval, Time Quota Type and Envelope Reporting as attributes
of a Content Type Id. The value of Base Time Interval is in seconds,
Time Quota Type is “Discrete“or “Continuous“, Envelope Reporting is
“Time Only“or “Time, Volume and Events“. The maximum number of
Content Type Ids allowed in a Content Type Profile is 255.
A Content Type Profile can be associated with a CBB Policy. See

figure “Service Policy Manager” on page 202.
The Content Type Profile configuration table contains four columns

and a combo box, Content Type Id, Base Time Interval, Time Quota
Type, Envelope Reporting and Report Discrete Time Period on the top.

Figure 8-106
Table 8-80
New Content Type Profile

Value
Content Type 32 character No Name of the Content Type Profile

Profile Name string default
value

Figure 8-107
Content Type Attributes Dialog

Content Type Attributes dialog is used to add or edit a mapping
between Content Type Id, Base Time Interval, Time Quota Type and
Envelope Reporting.
Figure 8-108
Content Type Attributes Dialog

Table 8-81
Parameters for Content Type Profile

Value
Content Type 0-65535 No Content Type Id
Id default
value

Interval

Type Continuous
Envelope “Time Only” and Time Indicates the type of info to report in
“Discrete” is used for DTP and “Continuous” is used for CTP. When
both “TIME EVENT BILLING” and “CTP TIME EVENT BILLING” SOCs
are enabled, “Discrete” option is set as default value. Otherwise, either
“Discrete” or “Continuous” will be visible when one of two SOCs above
is enabled.
HCM Profiles
A new profile at the device level named “HCM Profile” is added to
provision the HCM alarm threshold values. There is one checkbox and
three editable text fields on this profile dialog.

Figure 8-109
New HCM Profile Dialog
Table 8-82
Parameters for new HCM profile

Value
Profile Name 32 character None Name of the HCM Profile. The first
string letter should be [a-z], the valid letter
should be [a-z0-9_-./:'#&%$]
Figure 8-110
Edit HCM profile Dialog
Table 8-83
Parameters for edit HCM profile

Value
Profile Name 32 character None Name of the HCM Profile

string
HCM checked or unchecked Enable or disable HCM functionality

Enabled unchecked

Table 8-83
Parameters for edit HCM profile
Network 1 - 100 Integer 90 The threshold value for Network

activation activation success rate.
success rate
threshold
Nodal 1 - 100 Integer 95 The threshold value for Nodal

activation activation success rate.
success rate
threshold
Activation 0 -30,000 0 The threshold value for activation

attempt Integer attempt
threshold
Content Filtering Profiles

A new Content Filter Profiles icon has been added to the Access
Properties Manager of SCS GUI menu for supporting Content Filtering
server profile configuration. The user is able to configure the profile
name as well as the following fields per server:
• IP Address
• Port Number (used for both TCP and UDP communications)
• Server Protocol Type (i.e., Nortel Content Filter Protocol v1.0,
Websense Server Protocol v4.2)
• Request Timeout

Figure 8-111
New Content Filter Profile
Table 8-84
Content Filter Profile Configuration Parameters
Profile 32 character string None The name of the Content Filter

Name Profile
IP Addr Integer or IP address None 32-bit number uniquely identifying

in dotted decimal the Content Filter Server
notation
Port 16-bit unsigned For Websense The port number of the Content
Integer, 1-65535 type server, the Filter Server
default value is
15868. For Nortel
Proprietary type
server, the default
value is 1344
Type Symbolic 1 The type of the Content Filter

representation of an Server (Nortel Networks,
Websense, etc)
8 bit unsigned
Integer,
1=Nortel Networks,
2=Websense
Timeout 16 bit Integer, 1-10 3 The request timeout value of the

Content Filter Server in seconds

Figure 8-112
Add Content Filter Profile
Table 8-85
Content Filter Profile Configuration Parameters
Profile 32 character string None The name of the Content Filter

Name Profile
IP Addr Integer or IP address None 32-bit number uniquely identifying

in dotted decimal the Content Filter Server
notation
Port 16-bit unsigned For Websense The port number of the Content
Integer, 1-65535 type server, the Filter Server
default value is
15868. For Nortel
Proprietary type
server, the default
value is 1344
Type Symbolic 1 The type of the Content Filter

representation of an Server (Nortel Networks,
Websense, etc)
8 bit unsigned
Integer,
1=Nortel Networks,
2=Websense
Timeout 16 bit Integer, 1-10 3 The request timeout value of the

Content Filter Server in seconds

Figure 8-113
Content Filter Profile Server List

Content Filter Service Policy

A new Content Filter icon has been added to the Service Policy
Manager of SCS GUI menu for supporting Content Filter Service
policy feature.
Figure 8-114
Service Policy Manager Content Filter Policy
HA Profile
A new HA Profile is introduced. The new profile contains a list of Home
Agents for which GGSN IP services are to be applied.Each APN may
have a single HA profile assigned. A given HA profile may be assigned
to many APNs.

Figure 8-115
New HA Profile
Table 8-86
New HA profile

Value
Profile Name 32 character None Name of the new profile. Hopefully

string something descriptive.

Figure 8-116
HA Profile
Clicking the Add or Edit button brings up the “New HA Server Address”
dialog. An example is shown in Figure 8-117.

Figure 8-117
HA Server Address
Table 8-87
HA server address

Value
Server Class A, B, or C None IP address of an Home Agent (HA) or

Address IPv4 address network hosting HAs.
Netmask 128.0.0.0 - None Netmask associated with the

255.255.255.255 provisioned server address. Permits
the HA Server List entry to identify a
single host or an entire network.
Connection Template
Connection Template under Access Properties is modified to support
GTP type and match by APN. Connection ISP within the Connection
Template can be used to specify which ISP the matching of APN.
A new type of connection template type is defined for GTP. The

following figure illustrates the GTP connection template.

Figure 8-118
Connection Template General Page
The Encapsulation is forced to GTP with the “Use Match By APN”

option since the connection template type has been defined as GTP.
Table 8-88
Connection template general tab

Value
Name 32 Character string None Name of the Connection Template.
Connection Configured Connection Any Selects the ISPs to allow connections

ISP ISPs to.
On the Subscriber template the user can specify the MTU value. The
MTU value can be configured in the range of 68-1950 bytes. The
default MTU value is 1500 bytes.
DHCP Profile
The DHCP profile is used to enable the DHCP Client or DHCP Relay
Agent functionality on the Nortel GGSN for the IP address allocation
from the DHCP Server. Four fields are added to the DHCP Profile -
Pool Name, DHCP Relay Agent Address, Use ISP Address as Source
Address and DHCP Client ID options.
Once the DHCP Profile is associated with an Access Group or a VPN,

the DHCP Relay Agent Address can not be modified. This field can
only be modified after all DHCP Profile associations are removed.

The DHCP Relay Agent Address can not be provisioned with the same
address as the Connection ISP or Trunk Interface. If the DHCP Profile
is associated with a VPN, the Access Subscriber local address can not
be used for the DHCP Relay Agent Address either.

Figure 8-119
DHCP Profile Configuration
Table 8-89
DHCP Profile General Tab

Value
Name A text string None Name of the profile

Table 8-89

Value
Hop Limit 1 - 16 4 Number of hops allowed
Elapsed 0, 60 - 65535 16000 Time-out in seconds

Seconds
Allowed
Pool Name 32 character string None This is an optional field. It is used at

the DHCP Server to select an address
from a specific address pool.
DHCP Relay IPv4 address format None The DHCP relay agent address for
Agent the giaddr parameter field in the
Address DHCP messages.
Use ISP Selected or Not Not Select for using the ISP IP address as
address as Selected Selected source address.
source
address
DHCP Client Wireless:IMSI, MSISDN Provides a DHCP Client that identifies

Options - Wireless:MSISDN the Nortel GGSN for a DHCP address
Client ID request.
DHCP Relay Selected or Not Not Enables you to select the 32-bit
Agent Selected Selected integer and String Hostname options.
Options -
Circuit ID
DHCP Relay Selected or Not Not Provides a slot, port and vpi/vci
Agent Selected Selected address that enables the identification
Options - 32- of a Nortel GGSN. (ID=slot/port/vpi/
bit integer vci)
DHCP Relay Selected or Not Not Provides a text String that identifies a
Agent Selected Selected Nortel GGSN. The string is mapped to
Options - the following data: slot/port/VP/VCI.
String
Hostname
DHCP Relay Selected or Not Not Selects the remote ID.

Agent Selected Selected
Options -
Remote ID

Table 8-89

Value
DHCP Relay Selected or Not Not Netmask of the Nortel GGSN inteface
Agent Selected Selected receiving the DHCP request.
Options -
Subnet Mask
Subscriber Outbound Tunneling

A new button, Dynamic L2TP VPN, is added to the Subscriber
Outbound Tunneling page for Single APN function. If this button is
checked, it allows the PDP sessions with IP PDU type or PPP PDU
type perform GTP-L2TP tunnel switching when the RADIUS Tunnel
attributes of L2TP Outbound Tunneling are returned from the RADIUS
Server. If No Level 2 Tunneling button is checked and the RADIUS
Tunnel attributes are returned from the RADIUS Server, the PDP
sessions with IP PDU type or PPP PDU type will be rejected.

Figure 8-120
Subscriber Outbound Tunneling Page
Table 8-90
Subscriber Outbound Tunneling Tab

Value
Dynamic Selected or Not Not IP/L2TP tunnel switching if the

L2TP VPN Selected Selected session GTP PDU is IP or PPP.
Subscriber Address Allocation

This is to add the provisioning at the SCS subscriber or template for
selection of IP address allocation method. It can be RADIUS/DHCP or
RADIUS/Local.

Figure 8-121
Subscriber Account Page
Table 8-91
Subscriber Account Tab

Value
Radius/Local Selected or Not Selected The type of address allocation to use

Selected RADIUS/local.
Radius/ Selected or Not Not The type of address allocation to use

DHCP Selected Selected RADIUS/DHCP.
Accounting Element
Accounting Element are found under Access Properties. The available
set of accounting types is based on user privilege. For example, the
set of Accounting Elements which are available for Device Owner User

Privilege are Device, Memory, Overload, ISP IP and Trunk stats.

Figure 8-122 illustrates where these types will be visible.
Figure 8-122
Accounting Element Type Page
The collection interval for these accounting types can be one of five
possible values: 0, 5, 15, 30, 60 minutes. These collection intervals
are aligned on the hour. Figure 8-123 illustrates how the interval drop
down list will be visible. The default value for each accounting element
is 15 minutes. Configuration of the value zero (0) for the accounting
interval disables collection for that accounting group

Figure 8-123
Accounting Element Interval Page
Table 8-92
Accounting Element Selection Tab
Field Accounting User Privilege Range Default Description

Element Value
Name All 32 Character String None The name of

accounting
element

Table 8-92

Element Value
Type Device Owner Device Stats, ISP IP Stats, Device Accounting

Trunk Stats, Memory Stats, Stats Element
Overload Stats Stats
ISP ISP IP Stats, VPRN Stats, ISP IP

VPRN Link Stats, Session Stats
Management Stats, APN
Stats, GTP Data Stats, CGF
Stats, GTP Accounting
Stats, IPSec Stats, L2TP/
IPSec Stats, L2TP Stats,
RADIUS Accounting Stats,
Wireless Service Stats,
SCP Stats, GRE Stats,
Ancillary APN Stats, APN
Data Stats, VRF Stats,
Trunk Stats, MPLS Stats,
DCC Stats, DHCP Stats,
Local Addr Pool Stats,
Content Filter Stats
Device Owner Device Stats, ISP IP Stats, Device

and ISP Trunk Stats, Memory Stats, Stats
Overload Stats, VPRN
Stats, VPRN Link Stats,
Session Management Stats,
APN Stats, GTP Data Stats,
CGF Stats, GTP Accounting
Stats, IPSec Stats, L2TP/
IPSec Stats, L2TP Stats,
RADIUS Accounting Stats,
Wireless Service Stats,
SCP Stats, GRE Stats,
Ancillary APN Stats, APN
Data Stats, VRF Stats,
MPLS Stats, DCC Stats,
DHCP Stats, Local Addr
Pool Stats, Content Filter
Stats, Content Filter Stats

Table 8-92

Element Value
Interval Device Stats Device Owner, 0, 5, 15, 30, 60 15 Collection

(minutes) Device Owner interval
and ISP
ISP IP Stats Device Owner, 0, 5, 15, 30, 60 15 Collection

ISP, Device interval
Owner and ISP
Trunk Stats Device Owner, 0, 5, 15, 30, 60 15 Collection

Device Owner interval
and ISP
VPRN Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

Owner and ISP interval
VPRN Link ISP, Device 0, 5, 15, 30, 60 15 Collection

Stats Owner and ISP interval

Table 8-92

Element Value
Interval Memory Device Owner 0, 5, 15, 30, 60 15 Collection

(Minutes) Stats and Device interval
Owner and ISP
Overload Device Owner 0, 5, 15, 30, 60 15 Collection

Stats and Device interval
Owner and ISP
Session ISP, Device 0, 5, 15, 30, 60 15 Collection

Managemen Owner and ISP interval
t Stats
APN Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

GTP Data ISP, Device 0, 5, 15, 30, 60 15 Collection

CGF Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

GTP ISP, Device 0, 5, 15, 30, 60 15 Collection

Accounting Owner and ISP interval
Stats
IPSec Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

L2TP/IPSec ISP, Device 0, 5, 15, 30, 60 15 Collection

L2TP Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

RADIUS ISP, Device 0, 5, 15, 30, 60 15 Collection

Accounting Owner and ISP interval
Stats
Wireless ISP, Device 0, 5, 15, 30, 60 15 Collection

Service Owner and ISP interval
Stats
SCP Stats ISP, Device 0, 5, 15, 30, 60 15 Collection


Table 8-92

Element Value
GRE Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

Ancillary ISP, Device 0, 5, 15, 30, 60 15 Collection

APN Stats Owner and ISP interval
APN Data ISP, Device 0, 5, 15, 30, 60 15 Collection

VRF Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

MPLS Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

DCC Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

DHCP Stats ISP, Device 0, 5, 15, 30, 60 15 Collection

Local Addr ISP, Device 0, 5, 15, 30, 60 15 Collection

Pool Stats Owner and ISP interval
Content ISP, Device 0, 5, 15, 30, 60 15 Collection

Filter Stats Owner and ISP interval
RADIUS Profile
A number of checkbox are added to the General page of RADIUS
Profile. On the RADIUS Servers page, up to 8 primary and 8 backup
servers can be provisioned for the RADIUS Profile. On the Advanced
Setting page, several RADIUS parameters are provisioned.

Figure 8-124
Radius Profile Configuration
Table 8-93
Radius Profile General Tab
Modified Field Range Default Field Description

Field Name Value
Profile Name Alphanumeric None Identifies the Radius Profile.

string
Timeout Integer (1-65535) 3 Number of seconds allowed for an

acknowledgement packet from the
RADIUS server to reach the GGSN
before timing out.

Table 8-93
Retries Integer (1-65535) 3 Number of tries allowed for the GGSN

to establish a connection to the
RADIUS server.
Authenticatio Integer (1-65535) 1812 UDP Port carrying authentication

n UDP Port data.
Accounting Integer (1-65535) 1813 UDP port used for transmitting

UDP Port accounting data.
CBB VSA Version 1, 2, 3 Version 1 Version 1: Includes uplink/downlink

Version and 4 volume usage per content type id
(Content type id supported is only
between 0-4)
Version 2: Includes uplink/downlink

volume usage per content type id

volume usage and time usage per
content type id

volume usage, time usage and event
count per content type id
Trim Domain Selected or Not Not When checked GGSN removes the
Name Selected Selected domain portion of the subscriber
name before sending it to the
RADIUS server.
Trim Realm Selected or Not Not When checked the GGSN trims the
Selected Selected ISP by realm during ISP selection,
using the login format domain/user
instead of usre@domain.
Trim User Selected or Not Not When checked, the SER 5500 strips
Name Selected Selected the username from a fully-qualified
domain name (FQDN) received from
a PPP user, and forwards only the
domain name to the RADIUS server
for authentication.
Password Alphanumeric empty When Trim User Name is enabled,

string specifies the password that is sent to
the RADIUS server as the user
password in authentication
messages. When you type this value,
the dialog box echoes it as asterisks.

Table 8-93
Retype Alphanumeric empty When Trim User Name is enabled,

Password string specifies the password that is sent to
the RADIUS server as the user
password in authentication
messages. When you type this value,
the dialog box echoes it as asterisks.
Framed-Pool Selected or Not Selected, if RADIUS Framed-Pool

Attribute Selected name attribute should be used for IP
Not Selected address assignment from local
reserved and unreserved address
pools
Framed-Pool Selected or Not Selected, if a log shall be generated

Error Log Selected when no framed pool has been found.
Not Selected
Include IMSI Selected or Not Not Enable/disable sending IMSI Attribute

Attribute Selected Selected in RADIUS Authentication and
Accounting messages.
Include Selected or Not Selected Enable/Disable sending MSISDN

MSISDN Selected Attribute in RADIUS Authentication
Attribute and Accounting messages.
Use ISP Selected or Not Not Select this field to send the ISP IP
address as Selected Selected address as source address for all the
source packets that are sent from GGSN to
address the Radius Server.
Include NAS Selected or Not Not Enable/Disable sending NAS Port

Port Attribute Selected Selected Attribute in RADIUS Authentication
and RADIUS Accounting messages.
The value of the NAS Port Attribute
sent is always 0 for the Univity GGSN.

Figure 8-125
Radius Profile, Radius Servers Tab

Figure 8-126
RADIUS Profile Advanced Setting Page
Table 8-94
RADIUS Profile Advanced Setting Tab

Value
Accounting- On 0 - 900 9 The period for which Accounting-On will be sent to

Retry Timeout Accounting RADIUS Server until a valid reply is
sent back.
Hold 0 - 1800 0 During this period we will hold all authentication

Authentication request to the Authentication RADIUS Server
Period which also acts as a Accounting RADIUS Server
and we have sent an Accounting-On request to
that server.

Service Policy Manager

A Content Based Billing icon has been added to the Service Policy list
on the Service Policy Manager page as shown in Figure 8-127.
Figure 8-127
Service Policy Manager Page

Changes To CBB Policy Action Dialog for POP3

The CBB policy Action dialog is enhanced to support new action filters.
Figure 8-128 shows the action filter for POP3 being activated when the
service is POP3.
Figure 8-128
Action Filters For POP3

Changes To CBB Policy Action Dialog for SMTP

The CBB policy action dialog is enhanced to support new action filters.
Figure 8-129 shows the action filter for SMTP being activated when
the service is SMTP.
Figure 8-129
Action Filters For SMTP

Changes To CBB Policy Action Dialog for IMAP4

The CBB policy action dialog is enhanced to support new action filters.
Figure 8-130 shows the action filter for IMAP4 being activated when
the service is imap4.

Figure 8-130
Action of Filters For IMAP4
URL Rating Dialog in CBB Policy

The URL rating configuration Dialog is modified to include new
information for Per-Get Billing.

Figure 8-131
Edit/Add URL Ids (Per-get Billing)
Table 8-95
Edit/add URL IDs
Modified Field Range Default Field Description

Field Name Value
URL Path Selected or Not Not Indicates if the URL string is case
Case Selected Selected sensitive or not.
Sensitive

Table 8-95
Edit/add URL IDs
Content Type 0-65535 None Content Type ID for uplink data

ID Uplink packets count
Content Type 0-65535 None Content Type ID for downlink data

ID Downlink packets count
Coupon ID 0-65535 None Coupon ID for uplink data packets

Uplink count
Coupon ID 0-65535 None Coupon ID for downlink data packet

Downlink count
Per-Get 0-65535 None Content Type ID for uplink/downlink

Billing data packets count and event usage
Content Type count per GET event
ID
Per-Get 0-65535 None Coupon ID for uplink/downlink data

Billing packets count and event usage count
Coupon ID per GET event
Per-Get Selected or Not Not If Event Completion is set to Disabled,

Billing Event Selected Selected the event is counted when the event
Completion (Disabled) trigger is detected.


Figure 8-132
CBB Policy Dialog

Figure 8-133
Configure IDs
Figure 8-134
Modify Coupon Attributes

Figure 8-135
Modify Content Type Attributes
Figure 8-136
Add Coupon Attributes

Figure 8-137
Add Content Type Attributes

CBB Provisioning Tool

CBB policy can be exported to XML files from SCS GUI. In the ‘Policy
Edit’ dialog, choose ‘File’->’Export Policy...’, then user can export an
policy to a local file. Prior to this feature, the output file is in plain string
format, while in this feature, the ‘XML’ format option is provided.
Figure 8-138
XML Option on Save Dialog
When user choose ‘*.xml’ option, the CBB policy will be exported to an
XML file. If the file name specified in ‘File Name’ field does not
contains ‘.xml’, an ‘xml’ extension will be automatically appended.
Access Properties Page

A new profile entry box is added to the Profiles and Keys page under
the Device Configuration - Access Properties. By default the Global
Attribute Profile is set to Default Profile entry. The Default Profile can’t
be modified and a new Global Attribute Profile is needed for new
configuration.

Figure 8-139
Access Properties Profiles and Keys Page
Table 8-96
Access Properties Profiles and Keys Tab

Value
Global string default The Global Attributes profile associated with this
Attributes device.
Profile
Redundancy profile default The “Redundancy Profile” text input field

Profile name associates the redundancy profile to an ISP
device.
SGSN Reset Selected Selected Enable/disable EchoReqTimerCallbackV1Sig

Warning Log or Not message to be shown in the logs.
Selected

Table 8-96
Access Properties Profiles and Keys Tab

Value
Enable Selected Not If the checkbox is enabled then an event log is

Logging of or Not Selected generated for the context deleted due to negative
Contexts Selected response from the SGSN.
Deleted By
Idle Attention: This field is available if and only if IDLE
Verification SESSION VERIFICATION SOC is activated.
Enable Selected Not To control whether use Charging Characteristics

Charging or Not Selected IE in the Create PDP Context Request message
Characteristics Selected for RADIUS Authentication.
Default 1..480 1 Provision the default extended life timeout for the
Extended Life device. The GGSN marks a LNS server as
Timeout (in unusable if there is no response from the LNS for
minutes) 54 secs. The Servers will be tried again only after
the expiry of l2tp_default_extended_life_timeout
value.
Address Pool Configuration

The blackout time period value is added to the Address Pool
Configuration page.

Figure 8-140
Address Pool Configuration Page

Table 8-97
Address Pool Configuration Table

Value
Address Pool Name: Selected or Not Not If Selected, this is a

Reserved Selected Selected reserved address pool for
RADIUS Framed-Pool
name selection. If Not
Selected, this pool is
used by all subscribers
within the pools access
group
Address Pool Name: Selected or Not Not If Selected, this pool is

Deactivated Selected Selected not used for any further
new address assign
requests, but the already
assigned addresses are
still valid until the
subscriber deactivates
the PDP context
If Not Selected, the

address pool is enabled
for address assignment
Black Out Period 0 - 7200 seconds 0 Black-out period timer

ISP Configuration
Figure 8-141
MCC and MNC configuration on ISP Configuration / ISP’s Devices

Table 8-98
GGSN-MCC-MNC configuration
Mobile Country Code 3 character numerical None Mobile country code

string
Mobile Network Code 2 or 3 character None Mobile network code

numerical string
Notification Profiles
Notification Profiles can be found under Access Properties. New
GGSN specific event categories are added to the event category list
under “Category Selection” dialog-box as shown below.
Figure 8-142
Category Selection Dialog
Table 8-99
Event categories list
Field Field Range Default Value Field Description

Name
Event GTP, GTP None Name of Event Category

Category Accounting,
SCP, WRAP,
GGSN AAA,
DCC, LI,
Health Check
Monitor, CFS

Access Group Configuration

Access Groups are collections of subscribers that share common
properties, including the RADIUS profile, DHCP profile, domain name
server, and IGMP profile.
Figure 8-143
Access Group Configuration
Access Group Configuration Group Management Tab

The Group Management tab of the Access Group Configuration dialog
box lets you view the devices to which the access group applies, and
the device settings that differ from those of the access group. The
following table describes the items in this tab.
Table 8-100
Access Group Configuration, Group Management Tab
Field Field Range Default Description

Value
Name Alphanumeric None Identifies the access group.

string (read-only)

Table 8-100
Access Group Configuration, Group Management Tab
Inherit Selected or Not Not If selected, all unspecified field will use
Unspecified Selected Selected values inherit from Default Group.
Values from
Default Group
Device Specific A table list device specific access group

Settings table settings
Editing Access Group Settings for Device dialog

The Editing Access Group Settings for Device dialog lets you add or
edit group settings for a device. The following table describes the
items in this dialog.
Figure 8-144

Table 8-101

Value
RADIUS Selected or Not Not Enable/Disable RADIUS profile override.

Override for Selected Selected
device
RADIUS Profile Alphanumeric None RADIUS profile assigned for the device to
string (read-only) override Access Group setting. Click Select
to choose a RADIUS profile from a Selection
dialog box. Click Clear to erase the current
profile.
DHCP Override Selected or Not Not Enable/Disable DHCP profile override.

for device Selected Selected
DHCP Profile Alphanumeric None DHCP profile assigned for the device to
to choose a DHCP profile from a Selection
profile.
CFS Override Selected or Not Not Enable/Disable CFS profile override.

CFS Profile Alphanumeric None CFS profile assigned for the device to
to choose a CFS profile from a Selection
profile.
IGMP Profile Alphanumeric None IGMP profile assigned for the device to
to choose an IGMP profile from a Selection
profile.
MPLS Override Selected or Not Not Enable/Disable MPLS settings override.

Route Alphanumeric None Route Distinguisher name assigned for the

Distinguisher string (read-only) device to override Access Group setting.
Click Select to choose a Route Distinguisher
name from a Selection dialog box. Click Clear
to erase the current one.

Import Route Alphanumeric None Import Route Target profile assigned for the
Target Profile string (read-only) device to override Access Group setting.
Click Select to choose an Import Route
Target profile from a Selection dialog box.
Click Clear to erase the current profile.
Export Route Alphanumeric None Export Route Target profile assigned for the
Target Profile string (read-only) device to override Access Group setting.
Click Select to choose an Export Route
Target profile from a Selection dialog box.
Click Clear to erase the current profile.
Vrf BGP Configuration None Click to open the dialog to config Vrf BGP
Aggregates Button Aggregates for the specific device
IP Address Pool Selected or Not Not Enable/Disable IP Address Pool Threshold

Threshold Selected Selected settings override.
Override for
device
Alarm Set 0%, 35% - 95% 0% The entered number is a relative value of the
address usage of the total address pool
category (Reserved, Unreserved) per access
group is allowed to be, before the Address
Pool Alarm is raised. As Example, if from 100
unreserved IP addresses 90 are already in
use, alarm is raised. This value has to be at
least 5% higher than the value to clear the
alarm. If both (Alarm Set and Alarm Clear)
are set to 0%, no alarm is generated.
Alarm Clear 0%, 30% - 90% 0% The entered number is a relative value of the
Pool Alarm is cleared after it has been raised.
As Example, if the pool category was 90% in
use and has dropped to 80%, the alarm for
that pool category is cleared again. This
value has to be This is value has to be at
least 5% lower than the value to set the
Session Selected or Not Not Enable/Disable session parameters settings

Parameters Selected Selected override.
Override for
Device
DNS Primary IPv4 IP address None The domain name server used for the device
Address format to override access group setting.

DNS Secondary IPv4 IP address None The alternate domain name server used for
Address format the device to override access group setting.
NBNS Primary IPv4 IP address None The NETBIOS name Service server address
Address format used for the device to override access group
setting.
NBNS IPv4 IP address None The backup address of the NBNS server
Secondary format used for the device to override access group
Address setting.
Idle Timeout 0 - 64800 0 Number of minutes a PDP session waits to

(min) receive data packet before timeout. Once the
timer expires, the PDP session will be
deactivated.
The Cause of Record Closing in the G-CDR

is set to Normal Release in this case. The
Idle Timeout value can be provisioned via
SCS GUI on a per access group basis or
received in the Access-Accept message from
RADIUS Server.
The default value of the Idle Timeout is set to

Disabled, which would result in PDP sessions
remaining activated indefinitely, even if no
data packet transmission is taking place.
Setting a value for this timer will ensure that
after a particular duration of time, if no packet
data is being sent by the user, the PDP
session can be deactivated and the GGSN
resources are freed.
Session 0 - 48 0 Number of hours a PDP session is active

Timeout (hours) before timeout with or without receiving data
packet. Once the timer expires, the PDP
session will be deactivated. The Session
Timeout value can be provisioned via SCS
GUI on a per access group basis or received
in the Access-Accept message from RADIUS
Server.
Idle Verification 0 (disabled) or 10- 0 Configured value for Idle Verification Timeout
Timeout (min) 64800. Must be 0 attribute. It is periodic interval that specifies
or less than Idle how often to verify that an idle context still
Timeout value. exists on the SGSN. Minimum value is 10
(minutes).
Attention: This field is available if IDLE

SESSION VERIFICATION SOC is activated.

Access Group Configuration Group Settings Tab

The Group Settings tab of the Access Group Configuration dialog box
lets you set the parameters for an access group. The following table
describes the items in the Group Setting tab.
Figure 8-145
Access Group Configuration Group Settings Page

Table 8-102
Access Group Configuration, Group Settings Tab

Value
RADIUS Profile Alphanumeric None RADIUS profile assigned to the access

string (read-only) group. Click Select to choose a RADIUS
profile from a Selection dialog box. Click
Clear to erase the current profile.
DHCP Profile Alphanumeric None DHCP profile assigned to the access group.
string (read-only) Click Select to choose a DHCP profile from a
Selection dialog box. Click Clear to erase the
current profile.
CFS Profile Alphanumeric None CFS profile assigned to the access group.
string (read-only) Click Select to choose a CFS profile from a
current profile.
IGMP Profile Alphanumeric None IGMP profile assigned to the access group.
string (read-only) Click Select to choose an IGMP profile from a
current profile.
Specify Session Selected or Not Not Enables the fields for configuring session
Parameters Selected Selected parameters.
DNS Primary IPv4 IP address None The domain name server used for the access
Address format group.
DNS Secondary IPv4 IP address None The alternate domain name server used for
Address format the access group.
NBNS Primary IPv4 IP address None The NETBIOS name Service server address.
Address format NBNS automatically matches a computer's
address and domain name once the
computer registers its name on the NBNS
server.
NBNS IPv4 IP address None The backup address of the NBNS server.
Secondary format
Address

Idle Timeout 0 - 64800 0 Number of minutes a PDP session waits to

(min) receive data packet before timeout. Once the
timer expires, the PDP session will be
deactivated.
The Cause of Record Closing in the G-CDR

is set to Normal Release in this case. The
Idle Timeout value can be provisioned via
SCS GUI on a per access group basis or
received in the Access-Accept message from
RADIUS Server.
The default value of the Idle Timeout is set to

Disabled, which would result in PDP sessions
remaining activated indefinitely, even if no
data packet transmission is taking place.
Setting a value for this timer will ensure that
after a particular duration of time, if no packet
data is being sent by the user, the PDP
session can be deactivated and the GGSN
resources are freed.
Session 0 - 48 0 Number of hours a PDP session is active

Timeout (hours) before timeout with or without receiving data
packet. Once the timer expires, the PDP
session will be deactivated. The Session
Timeout value can be provisioned via SCS
GUI on a per access group basis or received
in the Access-Accept message from RADIUS
Server.
Idle Verification 0 (disabled) or 10- 0 Configured value for Idle Verification Timeout
Timeout (min) 64800. Must be 0 attribute. It is periodic interval that specifies
or less than Idle how often to verify that an idle context still
Timeout value. exists on the SGSN. Minimum value is 10
(minutes).
Attention: This field is available if and only if

IDLE SESSION VERIFICATION SOC is
activated.

Alarm Set 0%, 35% - 95% 0% The entered number is a relative value of the
Pool Alarm is raised. As Example, if from 100
unreserved IP addresses 90 are already in
use, alarm is raised. This value has to be at
least 5% higher than the value to clear the
Alarm Clear 0%, 30% - 90% 0% The entered number is a relative value of the
Pool Alarm is cleared after it has been raised.
As Example, if the pool category was 90% in
use and has dropped to 80%, the alarm for
that pool category is cleared again. This
value has to be This is value has to be at
least 5% lower than the value to set the

CORBA API User Interface 8

Nortel GGSN also supports the provisioning of a variety of profiles and
templates through the CORBA API.
Using SCS GUI provisioning, the range and error checking is

performed at the SCS Client. If CORBA interface is used for
provisioning, the operator is responsible for the correctness of the
provisioning information. No error checking on the provisioning
information has been provided when using CORBA API.
CORBA Shell Commands 8

CORBA shell is a shell-like command line utility that can be used to
configure various elements in SCS using the CORBA API.
All provisioning should be done through the SCS GUI, SCS CORBA
API or CORBA Shell command.


9-1
OA&M 9
Overview 9
This Operation, Administration, and Maintenance (OA&M) chapter
describes the OA&M functions of Nortel GGSN in the following
aspects:
• Operation Measurements (OMs)

• Alarms
• Event Logs
• Event Trace
• Active Session Management (ASM)
• Software Optionality Control (SOC)
• Command Line Interface (CLI) Commands
• Patching System
• Upgrade Strategy
The OA&M information covered in this chapter includes not only the
GGSN specific ones, but also the SER base OA&M functions that are
available on the Nortel GGSN.
Operation Measurements 9
This section defines the Operation Measurements relevant to the
GGSN functionality which includes:
• Historical Statistics
• SER Base Operation Measurements
• SER Base CLI Statistics
Nortel GGSN statistics are collected using a flexible mechanism that
allows configurable collection interval and different ways to display.
Two separate methods are supported for collecting statistics as
mentioned below:

9-2 OA&M Copyright © 2000–2008 Nortel Networks
The first statistics method involves polling the OMs from the SCS
Server and displaying them on the client GUI as needed. The OMs are
viewed from the SCS Device Monitoring window while polling is
activated. The polling interval may be adjusted from the GUI within the
minimum and maximum allowable ranges. Only partial Historical
Statistics is supported by using this method.
The second collection method allows OMs to be written to the binary

files on the SCS Server at regular intervals. OM files are stored on the
SCS Log Server host machine in directories indicating the accounting
element location of the device in files with ‘.acc’ suffixes. For example,
the session management OMs for the first Nortel GGSN device added
to Region 50 would be in an OM file called <SCS installation
directory>/log/region50/device1/isp2/sm.acc.
The CSV files are generated for Historical Statistics from ACC OM files
and waiting for FTP to the OAM Server. The CSV files will not be
generated for SER base OMs and the SER Base CLI Statistics.
The ACC OM files can be viewed on the SCS Log Server via the
SCSLogCat utility program which is provided with the SCS servers
and installed in the SER binary directory. The SCSLogCat command,
issued without arguments, will show the usage syntax. With the -i
argument, SCSLogCat displays the current contents of the specified
log file and creates a bookmark indicating the last record displayed.
Subsequent SCSLogCat -i commands will display only new records
appended to the OM file.
These same ACC OM files can be viewed from the Log Manager
window of the SCS Client GUI. OM files can become very large over
time, up to 100MB, and viewing them via the SCS Client GUI not only
creates burdensome network traffic, but also slows down GUI display
update.
Historical Statistics
Nortel GGSN provides many different performance statistics for use by
a customer’s operation support systems. These statistics, collected as
members of accounting groups, characterize the capacity and
performance of the Nortel GGSN. Nortel GGSN statistics are collected
within the following accounting groups.
• Memory
• Session Management
• GTP Data
• GTP Accounting

OA&M 9-3
• RADIUS
• APN
• CGF
• L2TP
• L2TP over IPSec (L2IP)
• IPSec
• Overload
• Wireless Services
• GRE
• SCP
• ISP-IP
• Ancillary APN
• APN Data Plane
• MPLS
• VRF Accounting
• DCC
• DHCP
• Local Address Pool
• Content Filter
All statistics are initialized to zero at system startup. All counter
statistics are then reset at the end of each corresponding collection
period. Statistics indicating a “high-water” mark are reset to the current
level after reporting statistics to the SCS Log Server. Gauge counters
are never reset, as they are simply incremented and decremented to
reflect the current state of the Nortel GGSN. The CGF, SCP, RADIUS
and DHCP statistics for a particular CGF, SCP, RADIUS or DHCP
server are also reset whenever the IP address of the server changes.
The current values of any statistical group can be viewed by running

the CLI command which shows the historical statistics accounting
element data. For showing the historical statistics with CLI commands,
please refer to Nortel GGSN Command Line Interface Guide.
The statistics collection interval for all accounting elements can be 0,

5, 15, 30 or 60 minutes. No other interval values are allowed. The
default collection interval is 15 minutes. A collection interval value of 0
will disable the collection of the statistics. The collection intervals are
lined up such that they fall on hourly boundaries. For example, if a

user configures an accounting element to collect every 15 minutes,

then the statistics for that accounting element will be collected for the
intervals x:00-x:15, x:15-x:30, x:30-x:45, and x:45-(x+1):00, for every x
hour (0-23). The statistics reported will be collected from these
intervals and will be reported to the SCS within the first 5 minutes after
the end of each collection interval.
Whenever the associated object of an accounting element is deleted

from the GGSN configuration, any statistics data which have not been
reported are discarded. For example, when an SCP is removed via
SCS GUI, the SCP historical stats which have not yet been reported
for that SCP are discarded. Also, the data for certain statistics (GTP
Data, L2TP, L2IP, IPSec, GRE, ISP-IP, APN Data, MPLS, and VRF), is
kept partially or entirely on the SSPs; therefore, if an SSP goes down,
any unreported statistics data which was on that SSP will be lost.
Scope of Statistics Counters

The Nortel GGSN is configured with a single Gn ISP, a single Ga ISP,
multiple Connection ISPs, optionally a single LI ISP, and optionally a
single TPO ISP. The following table summarizes the scope of the
accounting groups used by the Nortel GGSN.
Table 9-1
Scope of Nortel GGSN accounting groups
Accounting Group Scope User Privilegea
Memory Active CMC Device Owner
Session Management Gn ISP ISP
GTP Data Gn ISP ISP
GTP Accounting Gn ISP or Ga ISP ISP
RADIUS per RADIUS Server ISP

per Connection ISP
APN per APN per ISP

Connection ISP
CGF per CGF on Gn ISP or ISP

Ga ISP
L2TP per Connection ISP ISP
L2IP per Connection ISP ISP
IPSec per Connection ISP ISP

OA&M 9-5
Table 9-1
Scope of Nortel GGSN accounting groups
Accounting Group Scope User Privilegea
Overload Device Device Owner
Wireless Services per Connection ISP ISP
GRE per Connection ISP ISP
SCP per SCP server per ISP

CTP profile per Gi ISP
ISP-IP per Connection ISP Device Owner

and ISP
Ancillary APN per APN per ISP

Connection ISP
APN Data Plane per APN per ISP

Connection ISP
MPLS per Connection ISP ISP
VRF per Connection ISP ISP
DCC per Diameter server ISP

per Diameter Profile
per ISP
DHCP per DHCP Server per ISP

Connection ISP
Local Address Pool per Local Address ISP

Pool per Connection
ISP
Content Filter per CF server per CF ISP

profile per
Connection ISP/VPN
a. All Accounting Elements are visible using the combined
Device Owner and ISP user privilege class.
Accounting Group Version

Each accounting group has a version field in the header that is used to
interpret the statistical elements it contains. As new fields are added,
deleted or changed, the version field must be incremented to allow for
proper interpretation of the elements it contains. The following table

illustrates the version numbers used for each release in the supported
Nortel GGSN deployment.
Table 9-2
Accounting Group Version Number
Accounting GGSN 2.0 GGSN 3.2 GGSN 4.0 GGSN 4.1 GGSN GGSN 6.0
Group 5.0
Memory 1 2 2 3
Session 1 3 4 5 6 7
Management
GTP Data 1 3 3 4 5
GTP 1 3 3 4
Accounting
RADIUS 1 2 2 3
APN 1 3 4 5 6 7
CGF 1 3 3 4
L2TP 1 2 2 3
L2IP 1 2 2 3
IPSec 1 2 2 3
Overload 1 3 3 4
Wireless 1 2 2 3
Services
GRE n/a 1 1 2
SCP n/a 1 2 3
ISP-IP n/a 3 3 4
Ancillary n/a 2 2 3
APN
APN Data n/a 1 1 2

Plane
MPLS n/a n/a 1 2 2
VRF n/a n/a 1 2 2
DCC n/a n/a 1 2 3

OA&M 9-7
Table 9-2
Accounting Group Version Number
Accounting GGSN 2.0 GGSN 3.2 GGSN 4.0 GGSN 4.1 GGSN GGSN 6.0
Group 5.0
DHCP n/a n/a n/a 1
Local n/a n/a n/a 1 1 2

Address
Pool
Content n/a n/a n/a n/a 1 1

Filter
Collection Method
The collection method in the statistics tables indicates the collection
mechanism for the statistics information. The following is a list of
collection method:
• Counter: This type of counter indicates a number within an

historical statistics collection period. It gets reset to zero after the
statistics collection.
• Continuous Counter: This type counter indicates a number since
the system boot time. It is not reset after statistics collection.
• Gauge: This is a level that is set through out the statistics collection
period.
• High/Low Tidemark Gauge: This is the highest/lowest level
reached within the statistics collection period.
• Identifier: This is a value that is interpreted in the context of the
statistics and mainly used for information.
Memory Statistics
Table 9-3 describes the statistics that will be collected as part of the
Memory Accounting Element group.
Table 9-3
Memory Counters
Description
Measurement Name 3GPP Name Collection Size (bits)
Method
This counter gives the time difference in seconds between the start and stop of the
statistics collection period. This counter facilitates a more accurate analysis of the
statistics for a given accounting interval.
Counter element Reporting MEM.ReportingInter Gauge 32
interval val

Description
Method
This measurement provides the current amount of system memory in use on the active
CMC. The measurement takes into account both static and dynamic memory and these
counters are for CMC P0 processor.
Current System Memory MEM.totSystemMem Gauge 32
Usage Util
This measurement provides the current amount of system memory that is free on the active
CMC. The measurement takes into account both static and dynamic memory and these
counters are for CMC P0 processor.
Current System Memory MEM.totSystemMem Gauge 32
Free Free
Spare counter for future enhancement purpose.Initialized to 0 and not pegged.
Spare counter MEM.spare1 TBD 32
Session Management Statistics

Table 9-4 lists the Session Management statistics which are
supported on the Nortel GGSN.
Table 9-4
Session Management Counters
Description
Measurement Name 3GPP Name Collection Size
Method (bits)
Counter element Reporting SM.ReportingInterval Gauge 32
interval
This counter counts all attempted sessions and is incremented upon receipt of a Create
PDP Context Request

OA&M 9-9
Description
Method (bits)
Attempted Session SM.AttActPdpCtxt Counter 32
Establishments
This counter counts all duplicate create requests and is incremented upon receipt of a
Create PDP Context Request for which a PDP context already exists. It takes into account
requests from the same SGSN.
The SM.AttActPdpCtxt counter is pegged at the first determination that a GTP packet is a
Create PDP Request, the SM.DupAttActPdpCtxt counter is pegged at determination that
the create request was received for a pre-existing PDP Context. Since there exists multiple
reasons (e.g. memory exhaustion, parse failure, etc.) why a create request may be dropped
after first determination and prior to determination of a pre-existing context.
Duplicate Attempts to SM.DupAttActPdpCtxt Counter 32
Establish Session
This counter provides the current number of active sessions present at the end of the
recording period.
Number of Simultaneous SM.NbrActPdpCtxt Gauge 32
Active Sessions
This counter provides the maximum number of active sessions present during the
recording period.
Peak Number of SM.MaxNbrActPdpCtxt High Tidemark 32
Simultaneous Active Gauge
Sessions
These counters provide the number of non-duplicate, attempted session establishments,
pegged by the traffic class (or delay class for Version 0) and allocation/retention priority
(or precedence class for Version 0) indicated in the QoS profile of the Create PDP Context
Request message. See 3GPP TS 23.107 for mappings between Version 0 and Version 1
QoS attribute mappings. This measurement will not include those contexts which are
rejected before their QoS is determined (although such contexts may be counted as part of
the FailActPdpCtxt counters).
The counters are pegged in idle state when a create request is received.
Attempted Session SM.AttActPdpCtxt.Bgrd.Low Counter 32
Establishments: Traffic
Class (TC): Background;
Allocation/Retention (A/R):
Low
TC: Interactive; A/R Low SM.AttActPdpCtxt.Intact.Low Counter 32
TC: Streaming; A/R Low SM.AttActPdpCtxt.Strm.Low Counter 32
TC: Conversational; A/R: SM.AttActPdpCtxt.Conv.Low Counter 32
Low
TC: Background; A/R: SM.AttActPdpCtxt.Bgrd.Medi Counter 32
Medium um

Description
Method (bits)
TC: Interactive; A/R SM.AttActPdpCtxt.Intact.Med Counter 32
Medium ium
TC: Streaming; A/R Medium SM.AttActPdpCtxt.Strm.Medi Counter 32
um
TC: Conversational; A/R: SM.AttActPdpCtxt.Conv.Medi Counter 32
Medium um
TC: Background; A/R: High SM.AttActPdpCtxt.Bgrd.High Counter 32
TC: Interactive; A/R High SM.AttActPdpCtxt.Intact.Hig Counter 32
h
TC: Streaming; A/R High SM.AttActPdpCtxt.Strm.High Counter 32
TC: Conversational; A/R: SM.AttActPdpCtxt.Conv.High Counter 32
High
These counters provide the number of sessions successfully established, pegged by
traffic class (or delay class for Version 0) and allocation/retention priority (or precedence
class for Version 0) indicated in the QoS profile of the Create PDP Context Request
message. See 3GPP TS 23.107 for mappings between Version 0 and Version 1 QoS
attribute mappings. The measurement is incremented on transmission of a Create PDP
Context Response with cause set to “Request Accepted” corresponding to a non-duplicate
Create PDP Context Request message.
Successful Session SM.SuccActPdpCtxt.Bgrd.Lo Counter 32
Establishments w
TC: Background; A/R: Low
TC: Interactive; A/R Low SM.SuccActPdpCtxt.Intact.L Counter 32
ow
TC: Streaming; A/R Low SM.SuccActPdpCtxt.Strm.Lo Counter 32
w
TC: Conversational; A/R: SM.SuccActPdpCtxt.Conv.Lo Counter 32
Low w
TC: Background; A/R: SM.SuccActPdpCtxt.Bgrd.Me Counter 32
Medium dium
TC: Interactive; A/R SM.SuccActPdpCtxt.Intact.M Counter 32
Medium edium
TC: Streaming; A/R Medium SM.SuccActPdpCtxt.Strm.Me Counter 32
dium
TC: Conversational; A/R: SM.SuccActPdpCtxt.Conv.M Counter 32
Medium edium
TC: Background; A/R: High SM.SuccActPdpCtxt.Bgrd.Hi Counter 32
gh
TC: Interactive; A/R High SM.SuccActPdpCtxt.Intact.Hi Counter 32
gh

OA&M 9-11
Description
Method (bits)
TC: Streaming; A/R High SM.SuccActPdpCtxt.Strm.Hi Counter 32
gh
TC: Conversational; A/R: SM.SuccActPdpCtxt.Conv.Hi Counter 32
High gh
This measurement provides the number of session establishment failures and is
incremented upon transmission of a non-duplicate Create PDP Context Response with
failure cause NORA(No Resources Available).
Failed Session SM.FailActPdpCtxt.NORA Counter 32
Establishments
This measurement provides the number of PDP context activations failed with return code
“No Resource Available” due to configuration settings. Pegged in cases where GTP
creates are disabled and the return code is configured as No Resources Available or APN
session limit is exceeded
Failed Session SM.FailActPdpCtxt.NORA.Ad Counter 32
Establishments min
“No Resource Available”. Pegged when no addresses left in the local address pool
(GTPv0).
Failed Session SM.FailActPdpCtxt.NORA.All Counter 32
Establishments DynamicAddressesOccupied
“No Resource Available” due to overload conditions. Pegged in cases where there is a
Selective Reject due to CPU Overload or a Selective Reject due to Mem Overload (GTPv0)
Failed Session SM.FailActPdpCtxt.NORA.Ov Counter 32
Establishments erload
“No Resource Available” due to memory exhaustion (GTPv0)
Failed Session SM.FailActPdpCtxt.NORA.No Counter 32
Establishments Memory
incremented whenever there is an PDP context activation attempt after an APN is
blacklisted.
Failed Session SM.FailActPdpCtxt.NORA.Ap Counter 32
Establishments nBlacklist
“No Resource Available” due to reasons other than “Admin”,
“AllDynamicAddressesOccupied”, “Overload”, “NoMemory” and “ApnBlacklist”.
Failed Session SM.FailActPdpCtxt.NORA.Ot Counter 32
Establishments her

Description
Method (bits)
failure cause ADAO(All Dynamic Addresses Occupied). The reasons for this could be:
Local address pools are depleted (GTPv1).
Failed Session SM.FailActPdpCtxt.ADAO Counter 32
Establishments
failure cause NOMA(No Memory Available).
Failed Session SM.FailActPdpCtxt.NOMA Counter 32
Establishments
failure cause MAPN(Missing or Unknown APN). The reasons for this could be: GGSN does
not have the APN provisioned, specified in the Create PDP Context Request(GTPv1).
Failed Session SM.FailActPdpCtxt.MAPN Counter 32
Establishments
failure cause UPAT(Unknown PDP Address or PDP Type). The reasons for this could be:
PDU type in the Create PDP Context Request is not IP or PPP (GTPv1)
Failed Session SM.FailActPdpCtxt.UPAT Counter 32
Establishments
failure cause UAUF(User Authentication Failure).
Failed Session SM.FailActPdpCtxt.UAUF Counter 32
Establishments
“User Authentication Failure” due to external error conditions. Pegged in the following
cases:
AAA Auth Failure (reject and timeout)
Prepaid Auth Failure (reject and timeout)
The LNS initiating take down for a IP over GTP-L2TP context with a User Error termination
cause
AAA failure due to invalid parameters.
A PDP Create Context Request is received with an un-authorized/un-provisoned

MCC+MNC.

OA&M 9-13
Description
Method (bits)
Failed Session SM.FailActPdpCtxt.UAUF.Ext Counter 32
Establishments ernal
“User Authentication Failure” due to internal error conditions.
Failed Session SM.FailActPdpCtxt.UAUF.Int Counter 32
Establishments ernal
“User Authentication Failure” due to reasons other than “External” and “Internal”.
Failed Session SM.FailActPdpCtxt.UAUF.Oth Counter 32
Establishments er
failure cause SYSF (System Failure).The Reason for this could be: GGSN administratively
configured to return "System Failure" for Create PDP Context Request Messages, RADIUS/
DCHP returns Address to the GGSN that it already has assigned to a different subscriber,
LNS returns a cause other than User Error to GGSN and L2TP tunnel establishment fails or
other errors due to resource shortage, unexpected messaging, etc.
Failed Session SM.FailActPdpCtxt.SYSF Counter 32
Establishments
“System Failure” due to configuration settings. Pegged in the following cases:
GTP creates being disabled and the return code is configured as System Failure.
Session mode being enabled without RADIUS Accounting being enabled (GTPv1).
Session mode being enabled without Wrap server on APN (GTPv1).
Aggregation configuration mismatch (GTPv1).

Failed Session SM.FailActPdpCtxt.SYSF.Ad counter 32
Establishments min
“System Failure” due to reasons other than “Admin”.
Failed Session SM.FailActPdpCtxt.SYSF.Oth counter 32
Establishments er
failure cause SEME(Semantic or Syntactic TFT or Packet Filter Error). The reasons for this
could be: Invalid traffic flow template format (GTPv1)
Failed Session SM.FailActPdpCtxt.SEME counter 32
Establishments

Description
Method (bits)
failure cause IEIN(Mandatory IE Incorrect, IE missing or Optional IE Incorrect). The reasons
for this could be: Length of mandatory/optional IE within message does not match with
actual length specified or Mandatory IE missing from message.
Failed Session SM.FailActPdpCtxt.IEIN counter 32
Establishments
failure cause IMFT(Invalid Message Format). The reasons for this could be: Length of GTP
packet in header does not match with actual length,Out of Order IE or No GSN address or
TEID in message.
Failed Session SM.FailActPdpCtxt.IMFT counter 32
Establishments
failure cause OVLD(Overload). The reasons for this could be: Create request selectively
rejected due to CMC P0 CPU overload status or Create request selectively rejected due to
CMC P0 Memory overload status. Note that SM.FailActPdpCtxt.NORA is also pegged in this
scenario.
Failed Session SM.FailActPdpCtxt.OVLD counter 32
Establishments
failure cause SVNS(Service Not Supported).
Failed Session SM.FailActPdpCtxt.SVNS counter 32
Establishments
“Service Not Specified” due to an invalid APN received.
Failed Session SM.FailActPdpCtxt.SVNS.Mis counter 32
Establishments singAPN
“Service Not Specified” due to an unknown PDP Address Type specified in the Create
request.
Failed Session SM.FailActPdpCtxt.SVNS.Un counter 32
Establishments knownPDPAddressType

OA&M 9-15
Description
Method (bits)
“Service Not Specified” due to configuration settings. Pegged in the following cases for
GTPv0:
Aggregation configuration mismatch
Session mode being enabled without RADIUS Accounting being enabled
Session mode being enabled without Wrap server on APN

Failed Session SM.FailActPdpCtxt.SVNS.Ad counter 32
Establishments min
“Service Not Specified” due to reasons other than “MissingAPN”,
“UnknownPDPAddressType” and “Admin”.
Failed Session SM.FailActPdpCtxt.SVNS.Oth counter 32
Establishments er
failure cause NoResp(No Response) which is not sent.
Failed Session SM.FailActPdpCtxt.NoResp counter 32
Establishments
This measurement provides the number of failed PDP context activations for which no
response is sent due to configuration settings. Pegged in the following cases for GTPv0
where the GTP tunnel is configured so that no Create Response is sent:
GTP creates being disabled
APN Admin state is not “enabled”
ISP Admin state is not “UP”

Failed Session SM.FailActPdpCtxt.NoResp.A counter 32
Establishments dmin
response is sent due to requests from different SGSNs. Pegged in the following cases:
Create PDP Context Request from different SGSN is received with TID already stored in
GGSN(GTPv0).
Create PDP Context Request from different SGSN is received with IMSI and NSAPI already
stored in GGSN(GTPv1).
Failed Session SM.FailActPdpCtxt.NoResp.S counter 32
Establishments GSNChange

Description
Method (bits)
This counter counts duplicate create requests for which no response is sent. This counter
is incremented upon receipt of a Create PDP Context Request for which a PDP context is
being established or being torn down.
Failed Session SM.FailActPdpCtxt.NoResp.D counter 32
Establishments uplicate
response is sent due to a fallback/fallforward scenario wherein a second Create PDP
Context Request is received instead of an Update PDP Context Request.
Failed Session SM.FailActPdpCtxt.NoResp.F counter 32
Establishments allBackFallForward
This measurement provides the number of PDP create requests rejected with cause code
“No Response Sent” due to the depth of the GTP UDP socket buffer exceeding its
threshold.
Failed Session SM.FailActPdpCtxt.NoResp.U Counter 32
Establishments DPThresholdReject
“No Response Sent” due to error conditions other than “Admin”, “SGSNChange”,
“Duplicate”, “FallBackFallForward” and “UDPThresholdReject”.
Failed Session SM.FailActPdpCtxt.NoResp. counter 32
Establishments Other
This measurement provides the number of PDP context attempted to move to the target
ssp during SSM Redundancy, and is incremented by 1 as it is attempted to move.
Attempted move PDP SM.AttSsmrPdpCtxt Counter 32
contexts - SSM
Redundancy
This measurement provides the number of PDP context attempted to move to the target
ssp during SSM Redundancy and is incremented by 1 when a PDP contexts is successfully
moved to the target ssp.
Successfully moved PDP SM.SuccSsmrPdpCtxt Counter 32
contexts - SSM
Redundancy
This measurement provides the number of PDP context deactivations initiated by SGSN,
and is incremented on receipt of a Delete PDP Context Request message.
Attempted MS & SGSN SM.AttDeactPdpCtxtMsAndS Counter 32
Initiated PDP Context gsn
Deactivations
This measurement provides the number of PDP Context Deactivations initiated by GGSN.
This is a general counter which gets incremented for one of the following reasons:
Whenever a delete command is issued from the CLI, a delete command is issued from the
SCS or there is a deactivate PDP context request received from the RADIUS/DCC(Manual),
Idle Timeout(ITO), expiry of maximum session duration timer (Maxdur), SGSN
Restart(SGSNRstrt) or expiry of the N3 timer.

OA&M 9-17
Description
Method (bits)
Attempted GGSN Initiated SM.AttDeactPdpCtxtGgsn Counter 32
PDP Context Deactivations
This measurement provides the number of PDP Context Deactivations initiated by GGSN
during SSM Redundancy. It is incremented by 1 as it is attempted to removed a PDP
Context from GGSN.
Attempted GGSN initiated SM.AttDeactPdpCtxtGgsn.Ss Counter 32
deactivation - SSM mr
Redundancy
This measurement provides the number of PDP Context Successful Deactivations initiated
by GGSN during SSM Redundancy. It is incremented by 1 when a PDP Context is
successfully removed from GGSN.
Successful GGSN initiated SM.SuccDeactPdpCtxtGgsn. Counter 32
deactivation - SSM Ssmr
Redundancy
This measurement provides the number of Basic Access Mode sessions created. Basic
Access Mode is one in which tunneling is not present between the GGSN and the remote
intranet. The counter gets incremented when a Basic Access Mode session is created.
Successful Basic Access SM.SuccActBamCtxt Counter 32
Mode Session Activations
This measurement provides the number of simultaneous active sessions using basic
access mode. The measurement is incremented when an untunneled session is
successfully created and decremented when an untunneled session is successfully
deleted.
Simultaneous Active SM.NbrActBamCtxt Gauge 32
Sessions Using Basic
Access Mode
This measurement provides the number of IPSec access mode sessions created, and is
incremented whenever a session which indicates that it uses IPSec is successfully
created.
Successful IPSec Session SM.SuccActIpsecCtxt Counter 32
Activations
This measurement provides the current number of simultaneous active sessions using
IPSec access mode. The measurement is incremented when a session which uses IPSec
access mode is successfully created and decremented when a session using IPSec access
mode is successfully deleted.
Simultaneous Active SM.NbrActIpsecCtxt Gauge 32
Sessions Using IPSec
Access Mode (member of a
VPRN)
This measurement provides the number of L2TP/IPSec access mode sessions created, and
is incremented whenever a session which indicates that it uses L2TP/IPSec is successfully
created.

Description
Method (bits)
Successful L2TP/IPSec SM.SuccActL2ipCtxt Counter 32
Session Activations
L2TP/IPSec access mode. The measurement is incremented when a session which uses
L2TP/IPSec access mode is successfully created and decremented when a session using
L2TP/IPSec access mode is successfully deleted.
Simultaneous Active SM.NbrActL2ipCtxt Gauge 32
Sessions Using L2TP/IPSec
Access Mode
This measurement provides the number of L2TP access mode sessions created, and is
incremented whenever a session is successfully created which indicates that it uses L2TP
not over IPSec.
Successful L2TP Session SM.SuccActL2tpCtxt Counter 32
Activations
L2TP access mode. The measurement is incremented when a session which uses L2TP
access mode is successfully created and decremented when a session using L2TP access
Simultaneous Active SM.NbrActL2tpCtxt Gauge 32
Sessions Using L2TP
Access Mode
This measurement provides the number of outbound roamer sessions serviced. The
measurement is incremented when a outbound roamer session is successfully established
or when a subscriber roams into a VPLMN. This statistic is enabled only if Enable Partial
Billing for Roamers is selected in the GTP Tunnel Configuration.
Number of Outbound SM.SuccActRoamerCtxt Counter 32
Roamer Sessions Serviced
This measurement provides the current number of simultaneous active outbound roamer
sessions. The measurement is incremented when a outbound roamer session is
successfully established or when a subscriber roams into a VPLMN. It is decremented
when a session is deleted or when a subscriber roams out of the VPLMN. This statistic is
enabled only if Enable Partial Billing for Roamers is selected in the GTP Tunnel
Configuration.
Number of Active SM.NbrActRoamerCtxt Gauge 32
Outbound Roamer
Sessions
This counter shows the number of GTP messages that are received at the GGSN which has
Bad Header. This counter is incremented only for GTP-C control messages.
Number of GTP messages SM.NbrBadGTPHeader Counter 32
with bad header
This counter shows the number of GTP messages that are received at the GGSN which has
a bad packet size. This counter is incremented only for GTP-C control messages.

OA&M 9-19
Description
Method (bits)
Number of GTP messages SM.NbrBadGTPPktSize Counter 32
with bad packet size
This counter is incremented when a GGSN attempts to deactivate a GTP context due to
manual intervention. This is calculated as the sum of deactivation attempts due to the
following reasons: Deactivate context requests received from the CLI of the GGSN,
Deactivate context requests received from the SCS and Deactivate context requests
received from DCC or RADIUS.
Attempted GGSN Initiated SM.AttDeactPdpCtxtGgsn.Ma Counter 32
Deactivation - Manual nual
This counter is incremented when a GGSN completes deactivation of a GTP context due to
manual intervention. This is calculated as the sum of: Successful deactivations of contexts
issued from the CLI of the GGSN, Deactivate context requests received from the SCS and
Deactivate context requests received from DCC or RADIUS.
Successful GGSN Initiated SM.SuccDeactPdpCtxtGgsn. Counter 32
Deactivation - Manual Manual
This counter is incremented when a GGSN attempts to deactivate a GTP context due to
expiry of the idle timer. This timer sets the number of minutes a PDP session waits to
receive a data packet.
Attempted GGSN Initiated SM.AttDeactPdpCtxtGgsn.IT Counter 32
Deactivation - Idle Timer O
expiry of the idle timer. This timer sets the number of minutes a PDP session waits to
receive a data packet.
Successful GGSN Initiated SM.SuccDeactPdpCtxtGgsn.I Counter 32
Deactivation - Idle Timer TO
This counter is incremented whenever the GGSN attempts to deactivate a GTP session
because the GTP session timer has exceeded the Maximum session duration for that GTP
session.
Attempted GGSN Initiated SM.AttDeactPdpCtxtGgsn.Ma Counter 32
Deactivation - Max Session xDur
Duration
This counter is incremented whenever the GGSN successfully completes deactivation of a
GTP session because the GTP session timer has exceeded the Maximum session duration
for that GTP session.
Deactivation - Max Session MaxDur
Duration
This counter is incremented when a GGSN attempts to deactivate a GTP context due to a
SGSN restart. This happens if the restart counter value received in the Recovery IE of the
incoming message is different from the value stored by the GGSN for that particular SGSN.
These values of restart counter are checked in Create and Update PDP context requests
and also in Echo requests.

Description
Method (bits)
Attempted GGSN Initiated SM.AttDeactPdpCtxtGgsn.Sg Counter 32
Deactivation - SGSN snRstrt
Restart
a SGSN restart. This happens if the restart counter value received in the Recovery IE of the
incoming message is different from the value stored by the GGSN for that particular SGSN.
These values of restart counter are checked in Create and Update PDP context requests
and also in Echo requests.
Deactivation - SGSN SgsnRstrt
Restart
This measurement provides the number of PDP Context Deactivation Attempt initiated by
GGSN due to no resource on the target SSP during SSM Redundancy. It is incremented by
1 as the process of removing the PDP Context starts in GGSN.
deactivation - SSM mr.NoResource
Redundancy No Resource
by GGSN due to no resource on target ssp during SSM Redundancy and is incremented. It
is incremented by 1 when PDP Context is successfully taken down from GGSN
deactivation - SSM Ssmr.NoResource
Redundancy No Resource
This measurement provides the number of aggregation PDP Context Deactivation Attempt
initiated by GGSN as the second move is not allowed during SSM Redundancy. It is
incremented by 1 as the process of removing the PDP Context starts in GGSN.
deactivation - SSM mr.NoSecondMove
Redundancy No Second
Move
This measurement provides the number of aggregation PDP Context Successful
Deactivations initiated by GGSN as the second move is not allowed during SSM
Redundancy. It is incremented by 1 when PDP Context is successfully taken down from
GGSN
deactivation - SSM Ssmr.NoSecondMove
Redundancy No Second
Move
This measurement provides the number of PDP Context Deactivation Attempt initiated by
GGSN due to system failure during SSM Redundancy. It is incremented by 1 as the process
of removing the PDP Context starts in GGSN.

OA&M 9-21
Description
Method (bits)
deactivation - SSM mr.SystemFailure
Redundancy System
Failure
by GGSN due to system failure during SSM Redundancy. It is incremented by 1 when PDP
Context is successfully taken down from GGSN.
deactivation - SSM Ssmr.SystemFailure
Redundancy System
Failure
This measurement provides the number of aggregation PDP Context Deactivation Attempt
initiated by GGSN as the SSM redundancy for Aggregation was not Enabled and is
incremented. It is incremented by 1 as the process of removing the PDP Context starts in
GGSN.
deactivation - SSM mr.Disabled
Redundancy for
Aggregation is disabled
Deactivations initiated by GGSN as the SSM redundancy for Aggregation is not Enabled. It
is incremented by 1 when PDP Context is successfully taken down from GGSN.
deactivation - SSM Ssmr.Disabled
Redundancy for
Aggregation is disabled
This counter shows the number of non-duplicate, attempted aggregation context
establishments. This counter is incremented upon receipt of a Create PDP Context
Request message indicating an APN which is configured for aggregation
Attempted establishment of SM.AttActAggrCtxt Counter 32
an Aggregation session
This counter shows the number of successful aggregation context establishments. This
counter is incremented upon transmission of a Create PDP Context Response message
with cause value “request accepted”
Successful establishments SM.SuccActAggrCtxt Counter 32
of an Aggregation session
This counter shows the number of active aggregation sessions. This counters is
incremented after successful establishment and decremented at session end.
Number of currently active SM.NbrActAggrCtxt Gauge 32
Aggregation sessions

Description
Method (bits)
This counter shows the number of times that an attempted aggregation session
establishment encountered on-board or off-board provisioning of functionality that is not
supported on an APN configured for aggregation.
Number of configuration SM.NbrConfigMism Counter 32
mis-matches encountered
This counter shows the number of non-duplicate PPP sessions that were processed by an
APN configured for aggregation.
Number of attempted PPP SM.AttActAggrPPP Counter 32
session establishments on
an Aggregation APN.
This measurement provides the number of GRE access mode sessions created, and is
incremented whenever a session which indicates that it uses GRE is successfully created.
Successful GRE Session SM.SuccActGreCtxt Counter 32
Activations
GRE access mode. The measurement is incremented when a session which uses GRE
access mode is successfully created and decremented when a session using GRE access
Simultaneous Active SM.NbrActGreCtxt Gauge 32
Sessions Using GRE
Access Mode (member of a
VPRN)
Prepaid. The measurement is incremented when a prepaid session is successfully created
and decremented when a prepaid session is successfully deleted. This includes prepaid
services that use CTP as well as DCC.
Simultaneous Active SM.NbrActPrepaidCtxt Gauge 32
Prepaid Sessions
This counter provides the maximum number of active Basic Access Mode (untunneled)
sessions present during the recording period.
Peak Number of SM.MaxNbrActBamCtxt High Tidemark 32
Simultaneous Active Basic Gauge
Access Mode Sessions
This counter provides the maximum number of active IPSec sessions present during the
recording period.
Peak Number of SM.MaxNbrActIPSecCtxt High Tidemark 32
Simultaneous Active IPSec Gauge
Sessions
This counter provides the maximum number of active L2TP sessions present during the
recording period.

OA&M 9-23
Description
Method (bits)
Peak Number of SM.MaxNbrActL2tpCtxt High Tidemark 32
Simultaneous Active L2TP Gauge
Sessions
This counter provides the maximum number of active L2TP/IPSec sessions present during
the recording period.
Peak Number of SM.MaxNbrActL2ipCtxt High Tidemark 32
Simultaneous Active L2TP/ Gauge
IPSec Sessions
This counter provides the maximum number of active GRE sessions present during the
recording period.
Peak Number of SM.MaxNbrActGreCtxt High Tidemark 32
Simultaneous Active GRE Gauge
Sessions
This counter provides the maximum number of active prepaid sessions present during the
recording period. This includes prepaid services that use CTP as well as DCC.
Peak Number of SM.MaxNbrActPrepaidCtxt High Tidemark 32
Prepaid Sessions
This counter provides the maximum number of active aggregation sessions present during
Peak Number of SM.MaxNbrAggrActCtxt High Tidemark 32
Aggregation Sessions
This measurement provides the maximum number of Simultaneous Active sessions of
Services APN without IP Subnet Dedication for the Wireless ISP network model present
during the recording period.
Peak number of SM.MaxNbrSvcActCtxt High Tidemark 32
Services sessions without
This counter provides the number of non-duplicate, attempted Secondary PDP Context
establishments. The counter is incremented by 1 upon receipt of a Create PDP Context
request for a secondary PDP context.
Number of Attempted SM.AttActSecPdpCtxt Counter 32
Establishments
This counter provides the number of successful Secondary PDP Context establishments.
The counter is incremented by 1 upon successful secondary context creation and before
sending the create response to the SGSN.
Number of Successful SM.SuccActSecPdpCtxt Counter 32
Establishments

Description
Method (bits)
This counter provides the current number of simultaneous active Secondary PDP Context
establishments. When there is more than one PDP context in the bundle, deletion of any
PDP context will cause this counter to decrement by one. When there is only one PDP
context left in the bundle, it is considered the primary PDP context and deletion of it will
not decrement this counter.
Current Number of SM.NbrActSecPdpCtxt Gauge 32
Simultaneous Secondary
PDP Context
Establishments
This counter provides the current number of mobile subscribers using Secondary PDP
contexts. It will be incremented once there is more than one PDP context in the PDP
bundle. It will be decremented once the PDP bundle contains only one context.
This counter gets incremented when the first secondary of a bundle is created and gets
decremented when the last secondary of the bundle is deleted.
Current Number of Mobile SM.NbrActMsSecInUse Gauge 32
Subscribers using
Secondary PDP Contexts
This counter provides the maximum number of mobile subscribers using Secondary PDP
contexts.
Peak Number of Mobile SM.MaxNbrActMsSecInUse High Tidemark 32
Subscribers using Gauge
Secondary PDP Contexts
This measurement provides the number of MPLS access mode sessions created, and is
incremented whenever a session is successfully created which indicates that it uses
MPLS.
Successful MPLS Session SM.SuccActMPLSCtxt Counter 32
Activations
MPLS access mode. The measurement is incremented when a session which uses MPLS
access mode is successfully created and decremented when a session using MPLS access
Simultaneous Active SM.NbrActMPLSCtxt Gauge 32
Sessions Using MPLS
Access Mode
This counter provides the maximum number of active MPLS sessions present during the
recording period.
Peak Number of SM.MaxNbrActMPLSCtxt High Tidemark 32
Simultaneous Active MPLS Gauge
Sessions
This measurement provides the number of sessions that were created with Content
Filtering enabled.

OA&M 9-25
Description
Method (bits)
Total Sessions with CF SM.SuccActCfCtxt Counter 32
This measurement provides the number of CBB sessions that were created with Content
Based Billing enabled.
Total Sessions with CBB SM.SuccActCbbCtxt Counter 32
This measurement provides the number of simultaneous active sessions that were created
with Content Based Billing enabled.
Active Sessions with CBB SM.NbrActCbbCtxt Gauge 32
This measurement provides the maximum number of sessions present during the
recording period that were created with Content Based Billing enabled.
Peak Simultaneous SM.MaxNbrActCbbCtxt High Tidemark 32
Sessions with CBB Gauge
Number of GTP packets dropped at UDP level due to UDP queue overflow on the CMC.
GTP Control packet lost SM.GTPDropPktUDPQueueO Counter 32
vfl
This measurement shows the number of successfully established contexts requesting P-
CSCF Address Discovery. This counter is incremented even if the P-CSCF Address
Discovery request is not fulfilled.
P-CSCF Address Requests SM.SuccActCtxtPcscfDiscRe Counter 32
q
This measurement shows the number of successfully established contexts requesting P-
CSCF Address Discovery where the P-CSCF Address Discovery request could not be
fulfilled. This could be because there is no IMS Profile associated with the APN or the
associated profile contained no addresses.
P-CSCF Address Request SM.SuccActCtxtPcscfDiscFai Counter 32
Failed led
This measurement provides the current number of active context bundles that
successfully requested P-CSCF Address Discovery.
Simultaneous Active SM.NbrActPcscfDiscCtxt Gauge 32
Sessions Requesting P-
CSCF Discovery
This measurement provides the maximum number of simultaneous active context bundles
that successfully requested P-CSCF Address Discovery.
Peak Number of SM.MaxNbrActPcscfDiscCtxt High Tidemark 32
Sessions Requesting P-
CSCF Discovery
This counter provides the current number of successful aggregation context activations
with policy control.
This counter is incremented for each successful aggregation context that interacts with
the PDF server for policy control during activation.

Description
Method (bits)
Number of Successful SM.SuccActCtxt.Aggr.PolCtrl Counter 32
Aggregation Context
Activations with Policy
Control
This counter provides the current number of PDF server initiated policy control updates for
aggregation contexts.
This counter is incremented for each RAR request from the PDF server for an aggregation
context.
Number of PDF Initiated SM.Aggr.PolCtrlPdfUpd Counter 32
Policy Control Updates
This counter provides the current number of GGSN initiated policy control updates for
This counter is incremented each time the GGSN sends a CCR (Update) to the PDF server
for policy control updates of an aggregation context.
Number of GGSN Initiated SM.Aggr.PolCtrlGgsnUpd Counter 32
Policy Control Updates
This counter provides the current number of dynamic policy control rule operations (add,
modify, delete) performed on aggregation contexts.
This counter is incremented for each time a dynamic policy control rule is added, modified,
or deleted for an aggregation context.
Number of Policy Control SM.Aggr.PolCtrlRuleOps Counter 32
Rule Operations
This gauge provides the current number of simultaneous dynamic policy control rules
present for active aggregation contexts.
This counter is incremented for each dynamic policy control rule added to active
aggregation contexts and decremented for each dynamic policy control rule removed from
Number of Active SM.Aggr.ActivePolCtrlRules Gauge 32
Simultaneous Policy
Control Rules
This gauge provides the highest number of simultaneous dynamic policy control rules
present for active aggregation contexts during the recording period.
High Tidemark of SM.Aggr.MaxNbrPolCtrlRule High Tidemark 32
Simultaneous Policy s Gauge
Control Rules
This measurement provides the number of successful establishment of VPN (VPN variants
include IPSec, GRE, ATM, VLAN, MPLS and GGSN VPRN) sessions. This counter is
incremented upon transmission of a Create PDP Context Response message with cause
value “request accepted”.

OA&M 9-27
Description
Method (bits)
Successful VPN session SM.SuccActVpnCtxt Counter 32
activations
This measurement provides the number of successful establishment of Services session
with IP Subnet Dedication for the Wireless ISP network model. This counter is incremented
upon transmission of a Create PDP Context Response message with cause value “request
accepted”.
Successful Services SM.SuccActSvcSubnetCtxt Counter 32
session activations with IP
Subnet Dedication
This measurement provides the number of successful establishment of Services session
without IP Subnet Dedication for the Wireless ISP network model. This counter is
incremented upon transmission of a Create PDP Context Response message with cause
value “request accepted”.
Successful Services SM.SuccActSvcCtxt Counter 32
session activations without
This measurement provides the maximum number of Simultaneous Active VPN (VPN
variants include IPSec, GRE, ATM, VLAN, MPLS and GGSN VPRN) sessions present during
Peak number of SM.MaxNbrActVpnCtxt High Tidemark 32
Simultaneous Active VPN Gauge
sessions
This measurement provides the maximum number of Simultaneous Active sessions of
Services APN with IP Subnet Dedication for the Wireless ISP network model present during
Peak number of SM.MaxNbrSvcSubnetActCtx High Tidemark 32
Simultaneous Active t Gauge
Services sessions with IP
Subnet Dedication
This measurement provides the number of successfully deleted Aggregation sessions.
This counter is incremented when an established PDP context or the entire bundle (in case
of teardown indicator been set in the Delete PDP Context Request message) is removed
from the system for any reason.
Successful Aggregation SM.SuccAggrCtxtDelete Counter 32
PDP Context deletions
This measurement provides the number of successfully deleted VPN (VPN variants include
IPSec, GRE, ATM, VLAN, MPLS and GGSN VPRN) sessions. This counter is incremented
when an established PDP context or the entire bundle (in case of teardown indicator been
set in the Delete PDP Context Request message) is removed from the system for any
reason.
Successful VPN PDP SM.SuccVpnCtxtDelete Counter 32
Context deletions

Description
Method (bits)
This measurement provides the number of successfully deleted Services sessions with IP
Subnet Dedication for the Wireless ISP network model. This counter is incremented when
an established PDP context or the entire bundle (in case of teardown indicator been set in
the Delete PDP Context Request message) is removed from the system for any reason.
Successful Services with IP SM.SuccSvcSubnetCtxtDelet Counter 32
Subnet Dedication PDP e
Context deletions
This measurement provides the number of successfully deleted Services sessions without
IP Subnet Dedication for the Wireless ISP network model. This counter is incremented
when an established PDP context or the entire bundle (in case of teardown indicator been
set in the Delete PDP Context Request message) is removed from the system for any
reason.
Successful Services SM.SuccSvcCtxtDelete Counter 32
without IP Subnet
Dedication PDP Context
deletions
This measurement provides the number of successfully deleted L2TP VPN (applicable only
to L2TP without IPSec tunnel configuration) sessions. This counter is incremented when
an established PDP context or the entire bundle (in case of teardown indicator been set in
the Delete PDP Context Request message) is removed from the system for any reason.
Successful L2TP VPN PDP SM.SuccL2tpCtxtDelete Counter 32
Context deletions
This measurement provides the number of successfully performed PDP context updates
initiated by both the MS/SGSN and the GGSN for the Aggregation APN. This counter is
incremented on the transmission/receipt of an Update PDP Context Response message
with cause “Request Accepted”.
Successful Aggregation SM.SuccAggrCtxtUpdate Counter 32
PDP Context Updates
initiated by both the MS/SGSN and the GGSN for the VPN (VPN variants include IPSec,
GRE, ATM, VLAN, MPLS and GGSN VPRN). This counter is incremented on the
transmission/receipt of an Update PDP Context Response message with cause “Request
Accepted”.
Successful VPN PDP SM.SuccVpnCtxtUpdate Counter 32
Context Updates
initiated by both the MS/SGSN and the GGSN for the Services APN with IP Subnet
Dedication for the Wireless ISP network model. This counter is incremented on the
Accepted”.
Successful Services with IP SM.SuccSvcSubnetCtxtUpda Counter 32
Subnet Dedication PDP te
Context Updates

OA&M 9-29
Description
Method (bits)
initiated by both the MS/SGSN and the GGSN for the Services APN without IP Subnet
Dedication for the Wireless ISP network model. This counter is incremented on the
Accepted”.
Successful Services SM.SuccSvcCtxtUpdate Counter 32
without IP Subnet
Dedication PDP Context
Updates
initiated by both the MS/SGSN and the GGSN for the L2TP VPN (applicable only to L2TP
without IPSec tunnel configuration). This counter is incremented on the transmission/
receipt of an Update PDP Context Response message with cause “Request Accepted”.
Successful L2TP VPN PDP SM.SuccL2tpCtxtUpdate Counter 32
Context Updates
This measurement provides the number of active sessions of Aggregation APN using GTP
accounting. This counter is incremented if an active session is using GTP accounting and
decremented at session end.
Active Aggregation SM.NbrActAggrCtxt.GtpAcct Gauge 32
sessions using GTP
accounting
This measurement provides the number of active sessions of VPN (VPN variants include
IPSec, GRE, ATM, VLAN, MPLS and GGSN VPRN) using GTP accounting. This counter is
incremented if an active session is using GTP accounting and decremented at session
end.
Active VPN sessions using SM.NbrActVpnCtxt.GtpAcct Gauge 32
GTP accounting
This measurement provides the number of active sessions of Services APN with IP Subnet
Dedication for the Wireless ISP network model using GTP accounting. This counter is
end.
Active Services sessions SM.NbrActSvcSubnetCtxt.Gt Gauge 32
with IP Subnet Dedication pAcct
using GTP accounting
This measurement provides the number of active sessions of Services APN without IP
Subnet Dedication for the Wireless ISP network model using GTP accounting. This counter
is incremented if an active session is using GTP accounting and decremented at session
end.
Active Services sessions SM.NbrActSvcCtxt.GtpAcct Gauge 32
without IP Subnet
Dedication using GTP
accounting

Description
Method (bits)
This measurement provides the number of active sessions of L2TP VPN (applicable only to
L2TP without IPSec tunnel configuration) using GTP accounting. This counter is
end.
Active L2TP VPN sessions SM.NbrActL2tpCtxt.GtpAcct Gauge 32
using GTP accounting
This measurement provides the number of successful activations of Aggregation APN
using DHCP. This counter is incremented for successful primary PDP context creations
using DHCP based IP address allocation.
Successful Aggregation SM.SuccActAggrCtxt.Dhcp Counter 32
session activations using
DHCP
This measurement provides the number of successful activations of VPN (VPN variants
include IPSec, GRE, ATM, VLAN, MPLS and GGSN VPRN) using DHCP. This counter is
incremented for successful primary PDP context creations using DHCP based IP address
allocation.
Successful VPN session SM.SuccActVpnCtxt.Dhcp Counter 32
activations using DHCP
This measurement provides the number of successful activations of Services APN with IP
Subnet Dedication for the Wireless ISP network model using DHCP. This counter is
allocation.
Successful Services SM.SuccActSvcSubnetCtxt.D Counter 32
session activations with IP hcp
Subnet Dedication using
DHCP
This measurement provides the number of successful activations of Services APN without
IP Subnet Dedication for the Wireless ISP network model using DHCP. This counter is
allocation.
Successful Services SM.SuccActSvcCtxt.Dhcp Counter 32
session activations without
IP Subnet Dedication using
DHCP
This measurement provides the current number of Simultaneous Active VPN (VPN variants
include IPSec, GRE, ATM, VLAN, MPLS and GGSN VPRN) sessions. This counter is
Number of currently active SM.NbrActVpnCtxt Gauge 32
VPN sessions
This measurement provides the current number of Simultaneous Active Services sessions
with IP Subnet Dedication for the Wireless ISP network model. This counter is incremented
after successful establishment and decremented at session end.

OA&M 9-31
Description
Method (bits)
Number of currently active SM.NbrActSvcSubnetCtxt Gauge 32
Services sessions with IP
Subnet Dedication
This measurement provides the current number of Simultaneous Active Services sessions
without IP Subnet Dedication for the Wireless ISP network model. This counter is
Number of currently active SM.NbrActSvcCtxt Gauge 32
Services sessions without
This measurement provides the number of successful establishment of sessions using
Radius Authentication. This counter is incremented for successful primary PDP context
creations using Radius Authentication.
Successful session SM.SuccActCtxt.RadiusAuth Counter 32
activations using Radius
Authentication
Radius Accounting. This counter is incremented for successfully established sessions
using Radius Accounting.
Successful session SM.SuccActCtxt.RadiusAcct Counter 32
activations using Radius
Accounting
Prepaid solution (DCC or CTP).
Successful session SM.SuccActPrepaidCtxt Counter 32
activations using Prepaid
solution
This measurement provides the number of successful re-authentication with Prepaid
server (DCC or CTP).
Successful re- SM.SuccPrepaidReAuth Counter 32
authentication with Prepaid
server
Content Based Billing for the Aggregation APN.
Successful Aggregation SM.SuccActAggrCtxt.Cbb Counter 32
session activations with
firewall for the Aggregation APN.
Successful Aggregation SM.SuccActAggrCtxt.Fw Counter 32
firewall

Description
Method (bits)
Anti-spoofing for the Aggregation APN.
Successful Aggregation SM.SuccActAggrCtxt.Aspoof Counter 32
Anti-spoofing
Policy Based Forwarding for the Aggregation APN.
Successful Aggregation SM.SuccActAggrCtxt.Pbf Counter 32
Policy Based Forwarding
Traffic Shaping for the Aggregation APN.
Successful Aggregation SM.SuccActAggrCtxt.Shape Counter 32
Traffic Shaping
Policing for the Aggregation APN.
Successful Aggregation SM.SuccActAggrCtxt.Police Counter 32
Policing
Indicates the number of Attempts of SGSN Update PDP Request for Direct Tunnel
Establishment. This stat is incremented irrespective of “DIRECT TUNNEL” SOC state (i.e.
SOC enabled/disabled)
Attempted Direct Tunnel SM.AttUpdPdpCtxtMsAndSg Counter 32
Activate Updates sn.DT
Indicates the number of Successful SGSN Update PDP context requests for Direct Tunnel
when SOC is Enabled. This stat is not incremented when “DIRECT TUNNEL” SOC is
disabled.
Successful Direct Tunnel SM.SuccUpdPdpCtxtMsAndS Counter 32
Activate Updates gsn.DT
Indicates the number of attempts of GGSN initiated Update request(s) due to Error
Indication Handling for a Direct Tunnel context. This stat is incremented irrespective of
“DIRECT TUNNEL” SOC state.
Attempted GGSN Initiated SM.AttUpdPdpCtxtGgsn.DT Counter 32
Update Requests for Error
Indication received on
GGSN for context in Direct
Tunnel
Indicates the number of successful GGSN initiated Update request(s) due to Error Indication
Handling for a Direct Tunnel context. This stat is incremented irrespective of “DIRECT
TUNNEL” SOC state.

OA&M 9-33
Description
Method (bits)
Successful GGSN Initiated SM.SuccUpdPdpCtxtGgsn.D Counter 32
Update Requests for Error T
Indication received on
GGSN for context in Direct
Tunnel
Indicates the number of Attempts of SGSN Update Request sent to deactivate the Direct
Tunnel. This stat is incremented irrespective of “DIRECT TUNNEL” SOC state.
Attempted Direct Tunnel SM.AttUpdPdpCtxtMsAndSg Counter 32
De-activate Update sn.deactDT
requests
Indicates the number of Successful SGSN Update Request sent to deactivate the Direct
Tunnel. This stat is incremented irrespective of “DIRECT TUNNEL” SOC state.
Successful Direct Tunnel SM.SuccUpdPdpCtxtMsAndS Counter 32
De-activate Update gsn.deactDT
requests
This measurement indicates the number of failed Update responses encountered by GGSN
for the GGSN Initiated Update request sent during Error Indication Handling for Direct
Tunnel context. This stat is incremented irrespective of “DIRECT TUNNEL” SOC state.
Failed Update Response SM.FailUpdPdpCtxtGgsn.DT Counter 32
from SGSN for GGSN
Initiated Update Request for
Error Indication Handling
for context in Direct Tunnel
Indicates the current number of sessions in Direct Tunnel when SOC is Enabled. This stat
is not incremented when “DIRECT TUNNEL” SOC is disabled.
Number of Active Direct SM.NbrDirectTunnels Gauge 32
Tunnel Sessions
Indicates the number of attempts of the GGSN initiated Update PDP Context Request(s) due
to Idle Session Verification, that has been sent to the SGSN.
Counter 32
Number of attempts the SM.AttUpdPdpCtxtGgsn.Ctxt
GGSN sent Update PDP Verify
Context Request to verify a
context
Indicates the number of Successful GGSN initiated Update PDP Context Request(s) for Idle
Session Verification.
Counter 32
Number of SGSN Update SM.SuccUpdPdpCtxtGgsn.Ct
PDP Context Responses xtVerify
indicating context is valid
This measurement indicates the number of failed Update responses encountered by GGSN
for the GGSN Initiated Update PDP Context Request sent for Idle Session Verification.

Description
Method (bits)
Counter 32
Failed Update Response SM.FailUpdPdpCtxtGgsn.Ctx
from SGSN for GGSN tVerify
Initiated Update PDP
Context Request for Idle
Session Verification.
Spare counter SM.spare1 TBD 32
GTP Data Statistics

GTP Data Accounting Element group.
Table 9-5
GTP Data Counters
Description
Measurement Name 3GPP Name Collection Method Size (bits)
Counter element Reporting GTP.ReportingInterval Gauge 32
interval
This measurement provides the number of GTP data packets discarded in the uplink
direction and is incremented whenever an uplink GTP data packet is discarded. The GTP
packet is discarded if there is a GTP packet format error.
Discarded GTP Data GTP.DiscDataPkt Counter 32
Packets
This measurement provides the number of GTP data packets received on the Gn
interface, and is incremented on receipt of a GTP data packet on the Gn interface. This
measurement is pegged by traffic class and allocation/retention priority.

OA&M 9-35
Description
Received GTP Data Packets GTP.IncDataPkt.Bgrd.Lo Counter 64
w
Traffic Class (TC):
Background; Allocation/
Retention (A/R): Low
TC: Interactive; A/R Low GTP.IncDataPkt.Intact.L Counter 64
ow
TC: Streaming; A/R Low GTP.IncDataPkt.Strm.Lo Counter 64
w
TC: Conversational; A/R: GTP.IncDataPkt.Conv.Lo Counter 64
Low w
TC: Background; A/R: GTP.IncDataPkt.Bgrd.Me Counter 64
Medium dium
TC: Interactive; A/R GTP.IncDataPkt.Intact.M Counter 64
Medium edium
TC: Streaming; A/R Medium GTP.IncDataPkt.Strm.Me Counter 64
dium
TC: Conversational; A/R: GTP.IncDataPkt.Conv.M Counter 64
Medium edium
TC: Background; A/R: High GTP.IncDataPkt.Bgrd.Hi Counter 64
gh
TC: Interactive; A/R High GTP.IncDataPkt.Intact.Hi Counter 64
gh
TC: Streaming; A/R High GTP.IncDataPkt.Strm.Hi Counter 64
gh
TC: Conversational; A/R: GTP.IncDataPkt.Conv.Hi Counter 64
High gh
This measurement provides the number of GTP data packets sent on the Gn interface,
and is incremented on transmission of a GTP packet on the Gn interface. This
measurement is pegged by traffic class and allocation/retention priority.
Sent GTP Data Packets GTP.OutDataPkt.Bgrd.Lo Counter 64
w
Traffic Class (TC):
Background; Allocation/
Retention (A/R): Low
TC: Interactive; A/R Low GTP.OutDataPkt.Intact.L Counter 64
ow
TC: Streaming; A/R Low GTP.OutDataPkt.Strm.Lo Counter 64
w
TC: Conversational; A/R: GTP.OutDataPkt.Conv.L Counter 64
Low ow

Description
TC: Background; A/R: GTP.OutDataPkt.Bgrd.M Counter 64
Medium edium
TC: Interactive; A/R GTP.OutDataPkt.Intact.M Counter 64
Medium edium
TC: Streaming; A/R Medium GTP.OutDataPkt.Strm.M Counter 64
edium
TC: Conversational; A/R: GTP.OutDataPkt.Conv.M Counter 64
Medium edium
TC: Background; A/R: High GTP.OutDataPkt.Bgrd.Hi Counter 64
gh
TC: Interactive; A/R High GTP.OutDataPkt.Intact.H Counter 64
igh
TC: Streaming; A/R High GTP.OutDataPkt.Strm.Hi Counter 64
gh
TC: Conversational; A/R: GTP.OutDataPkt.Conv.Hi Counter 64
High gh
This measurement provides the number of GTP payload octets received, and is
incremented on receipt of a GTP data packet on the Gn interface. The data packet size is
extracted from the GTP header and added on to the measurement value. This
measurement is pegged by traffic class and allocation/retention priority. These counters
do not include GTP transport layer octets.
Received GTP Payload GTP.IncDataOct.Bgrd.Lo Counter 64
Octets w
TC: Interactive; A/R Low GTP.IncDataOct.Intact.L Counter 64
ow
TC: Streaming; A/R Low GTP.IncDataOct.Strm.Lo Counter 64
w
TC: Conversational; A/R: GTP.IncDataOct.Conv.Lo Counter 64
Low w
TC: Background; A/R: GTP.IncDataOct.Bgrd.Me Counter 64
Medium dium
TC: Interactive; A/R GTP.IncDataOct.Intact.M Counter 64
Medium edium
TC: Streaming; A/R Medium GTP.IncDataOct.Strm.Me Counter 64
dium
TC: Conversational; A/R: GTP.IncDataOct.Conv.M Counter 64
Medium edium
TC: Background; A/R: High GTP.IncDataOct.Bgrd.Hi Counter 64
gh
TC: Interactive; A/R High GTP.IncDataOct.Intact.Hi Counter 64
gh

OA&M 9-37
Description
TC: Streaming; A/R High GTP.IncDataOct.Strm.Hi Counter 64
gh
TC: Conversational; A/R: GTP.IncDataOct.Conv.Hi Counter 64
High gh
This measurement provides the number of GTP payload octets sent, and is incremented
on transmission of a GTP data packet on the Gn interface. The data packet size is
extracted from the GTP header and added on to the measurement value. This
measurement is pegged by traffic class and allocation/retention priority. These counters
do not include GTP transport layer octets.
Sent GTP Payload Octets GTP.OutDataOct.Bgrd.L Counter 64
ow
TC: Interactive; A/R Low GTP.OutDataOct.Intact.L Counter 64
ow
TC: Streaming; A/R Low GTP.OutDataOct.Strm.L Counter 64
ow
TC: Conversational; A/R: GTP.OutDataOct.Conv.L Counter 64
Low ow
TC: Background; A/R: GTP.OutDataOct.Bgrd.M Counter 64
Medium edium
TC: Interactive; A/R GTP.OutDataOct.Intact. Counter 64
Medium Medium
TC: Streaming; A/R Medium GTP.OutDataOct.Strm.M Counter 64
edium
TC: Conversational; A/R: GTP.OutDataOct.Conv.M Counter 64
Medium edium
TC: Background; A/R: High GTP.OutDataOct.Bgrd.Hi Counter 64
gh
TC: Interactive; A/R High GTP.OutDataOct.Intact.H Counter 64
igh
TC: Streaming; A/R High GTP.OutDataOct.Strm.Hi Counter 64
gh
TC: Conversational; A/R: GTP.OutDataOct.Conv.H Counter 64
High igh
This counter shows the number of Error Indication messages received by the GGSN. The
counter gets pegged when an Error Indication message is received by the GGSN if it
sends a G-PDU for which no PDP context exists.
Error indication received GTP.IncErrIndMsg Counter 32
This counter shows the number of Error Indication messages sent by the GGSN.The
counter gets pegged when an Error Indication message is sent by the GGSN if it receives
a G-PDU for which no PDP context exists.
Error indication sent GTP.OutErrIndMsg Counter 32

Description
Indicates number of Error Indication message ignored by GGSN
Number of Incoming Error GTP.IncErrIndMsgIgnd Counter 32
Indication Message Ignored
Spare counter GTP.spare1 TBD 64
GTP Accounting Statistics

GTP Accounting accounting element group. When the
GTPP.FailCdrTransf.FQAF counter is incremented, it is possible that
the CDR was transferred successfully to the CGF previous to the
receipt of the FQAF message, but the successful response sent by the
CGF was never received by the GGSN.
If GTP Accounting record retries are enabled for the CGF Servers,
CDR transfer failures followed by a successful CDR transfer on a retry
will increment the successful CDR transfer statistic and the applicable
failure CDR transfer statistic one or more times.
Table 9-6
GTP Accounting Counters
Description
Method (bits)
Counter element Reporting GTPP.ReportingInterval Gauge 32
interval

OA&M 9-39
Description
Method (bits)
This measurement provides the number of CDR information transfers attempted due
to a certain cause value, and is incremented when the Data Record Transfer Request
with the corresponding cause value is sent to a CGF without having been saved to
disk or the CDR is saved to disk. The cause values are CDR Closure/Normal Release
(CDRC), Abnormal Release (AREL), Data Volume Limit (DVLM), Maximum Number of
Charging Condition Changes (MCCC), Management Intervention (MGTI), Time Limit
(TLEX) and SGSN Change (SCHG).
Attempted CDR Information GTPP.CdrTransfReq.CD Counter 32
Transfers RC
GTPP.CdrTransfReq.AR Counter 32
EL
GTPP.CdrTransfReq.DV Counter 32
LM
GTPP.CdrTransfReq.MC Counter 32
CC
GTPP.CdrTransfReq.MG Counter 32
TI
GTPP.CdrTransfReq.TLE Counter 32
X
GTPP.CdrTransfReq.SC Counter 32
HG
These measurements provide a measure of the response of the CGF regarding the
DRT’s received by the CGF (one DRT may contain more than one CDR) due to a certain
cause value and are incremented upon the receipt of a DRT(Data Record Transfer)
response with the corresponding cause value. Supported cause values are Successful
CDR Transfer, Request Already Fulfilled (FQAF), No Resource Available (NRAV),
Request Not Fulfilled (RQNF), System Failure (SYSF) and Version Not Supported
(VNSU). Cause values that are not supported are Invalid Message Format (INMF),
Mandatory IE Incorrect (MIEI), Mandatory IE Missing (MIEM), Optional IE Incorrect
(OIEI) and Service Not Supported (SVNS).

Description
Method (bits)
Successful/Failed CDR GTPP.SuccCdrTransf Counter 32
Information Transfers GTPP.FailCdrTransf.FQA Counter 32
F
GTPP.FailCdrTransf.INM Counter 32
F (not supported)
GTPP.FailCdrTransf.MIEI Counter 32
(not supported)
GTPP.FailCdrTransf.MIE Counter 32
M (not supported)
GTPP.FailCdrTransf.NR Counter 32
AV
GTPP.FailCdrTransf.OIEI Counter 32
(not supported)
GTPP.FailCdrTransf.RQ Counter 32
NF
GTPP.FailCdrTransf.SVN Counter 32
S (not supported)
GTPP.FailCdrTransf.SYS Counter 32
F
GTPP.FailCdrTransf.VNS Counter 32
U
This measurement provides the number of redirection requests received by GTP
accounting
Number of GTP accounting GTPP.RedirRequestRecv Counter 32
Redirection Requests d
received
This measurement provides the number of GTP accounting packets that are sent to
the CGFs but did not get an acknowledgement before timeout period set in the
configuration
Number of time-outs for GTPP.NbrGTPPTimeouts Counter 32
GTP accounting packets
This measurement provides the number of GTP accounting packets that are sent to
the CGFs but did not get a response after maximum retry set in the configuration.
Number of “no responses” GTPP.NbrGTPPNoResp Counter 32
for GTP accounting packets
This measurement provides the number of GTP accounting protocol errors that have
occurred in the GGSN
Number of GTP accounting GTPP.NbrProtErrors Counter 32
protocol errors

OA&M 9-41
Description
Method (bits)
Spare counter GTPP.spare1 TBD 32
RADIUS Statistics
RADIUS accounting Element group.
Table 9-7
RADIUS Counters
Description
Method
Counter element Reporting RAD.ReportingInte Gauge 32
interval rval
The IP Address of the RADIUS server.
RADIUS Server RAD.Server Identifier 32
This counter is pegged upon first transmission of RADIUS Accounting On and Off
messages, RADIUS Accounting Start and Stop messages.
Attempted CDR Information RAD.AcctTransfRe Counter 32
Transfers q
This counter is pegged on retransmission of a RADIUS Accounting On, RADIUS
Accounting Off, RADIUS Accounting Start or RADIUS Accounting Stop message.
CDR Information RAD.AcctRetrans Counter 32
Retransmissions
This counter is pegged on receipt of a RADIUS Accounting Response.
Successful CDR RAD.AcctRespons Counter 32
Information Transfers eRcvd

Description
Method
RADIUS Accounting Client Average Round Trip Time in ms between transmission of
Accounting Request message and receipt of Accounting Response message within the
set accounting interval.
The Total Round Trip Time is accumulated on a per-Accounting transaction basis for a
particular RADIUS server during the accounting interval. At the end of the accounting
interval, the Total Round Trip Time is divided by the number of accounting transactions
performed during the accounting interval to arrive at the RADIUS Accounting Client
Average Round Trip Time.
Accounting transaction pertains to the transaction wherein an Accounting Request

message is sent to a particular RADIUS server, and Accounting Response message
received thereafter. Accounting Request timeouts are not accounted as Accounting
transactions.
RADIUS Acc Client Avg RAD.AcctAvgRTT Counter 32
Round Trip Time
Number of RADIUS Accounting Request packets that have not yet timed out or received
a response from RADIUS server.
Increment this counter whenever an Accounting Request message is sent out to RADIUS
server.
Decrement this counter once an Accounting Response is received from RADIUS server
OR a timeout occurs.
RADIUS Acc Client Pending RAD.AcctPending Gauge 32
Requests Requests
The peak of the pending RADIUS accounting requests during the last reporting interval.
If (AcctMaxPendingRequests <= AcctPendingRequests)
- Incremented at the time of sending RADIUS accounting request.
If (AcctMaxPendingRequests > AcctPendingRequests)
Remains unchanged.
This counter is reset to the AcctPendingRequests counter value at the start of the next
accounting interval.
RADIUS Acc Client Max RAD.AcctMaxPend High Tidemark 32
Pending Requests ingRequests Gauge
Number of Accounting Requests that timed out waiting for Accounting Response from
the RADIUS server.
RADIUS AccClient Time- RAD.AcctTimeOut Counter 32
outs s

OA&M 9-43
Description
Method
Number of malformed Accounting Response packets received from the RADIUS server.
Malformed packets include packets with an invalid length (packet length is “less than the
minimum header length” OR “greater than the maximum allowed RADIUS packet
length”). Bad Authenticators and unknown types are not included as malformed access
responses.
RADIUS AccClient RAD.AcctMalforme Counter 32
Malformed Responses dResponses
Number of Accounting Response packets received from the RADIUS server which
contained invalid authenticators.
RADIUS Acc Client Bad RAD.AcctBadAuth Counter 32
Authenticators enticators
Number of RADIUS packets of unknown type which are received on the Accounting Port.
Packet of unknown type corresponds to the packet with message type other than
Accounting Response received on the RADIUS accounting port.
RADIUS AccClient RAD.AcctUnknown Counter 32
Unknown Types Types
Number of RADIUS packets received on the Accounting Port which are dropped for
failure reasons other than one of the existing counters.
This counter is incremented for cases such as
1) Packet is received with an identifier value not available in the GGSN.
2) Other Internal software errors.

RADIUS AccClient Packets RAD.AcctPacketsD Counter 32
Dropped ropped
Number of Access Request packets sent to RADIUS server excluding retransmissions.
RADIUS Auth Access RAD.AuthAccessR Counter 32
request equests
Number of Access Request packets retransmitted to RADIUS server.
RADIUS Auth Client Access RAD.AuthAccessR Counter 32
Retransmissions etransmissions
Number of Access Accept packets received from RADIUS server.
RADIUS Auth Access RAD.AuthAccessA Counter 32
Accept ccepts
Number of Access Reject packets received from RADIUS server.
RADIUS Auth Access RAD.AuthAccessR Counter 32
Rejects ejects

Description
Method
RADIUS Authentication Client Average Round Trip Time in ms between transmission of
Access Request message and receipt of Access Response (Access Accept/Challenge/
Reject) message within the set accounting interval.
The Total Round Trip Time is accumulated on a per-Authentication transaction basis for
a particular RADIUS server during the accounting interval. At the end of the accounting
interval, the Total Round Trip Time is divided by the number of authentication
transactions performed during the accounting interval to arrive at the RADIUS
Authentication Client Average Round Trip Time.
Authentication transaction pertains to the transaction wherein an Access Request

message is sent to a particular RADIUS server, and Access Response (Access Accept/
Reject) message received thereafter. Access Request timeouts are not accounted as
Authentication transactions.
RADIUS Auth Client Avg RAD.AuthAvgRTT Counter 32
Round Trip Time
Number of RADIUS Access Request packets that have not yet timed out or received a
response from RADIUS server.
Increment this counter whenever an Access Request message is sent out to RADIUS
server.
Decrement this counter once an Access Response is received from RADIUS server OR a
timeout occurs.
RADIUS Auth Client RAD.AuthPending Gauge 32
Pending Requests Requests
The peak of the pending RADIUS auth requests during the last reporting interval.
If (AuthMaxPendingRequests <= AuthPendingRequests)
- Incremented at the time of sending RADIUS auth request.
If (AuthMaxPendingRequests > AuthPendingRequests)
Remains unchanged.
This counter is reset to the AuthPendingRequests counter value at the start of the next
RADIUS Auth Client Max RAD.AuthMaxPend High Tidemark 32
Pending Requests ingRequests Gauge
Number of Access Requests that timed out waiting for Access Response from the
RADIUS server.
RADIUS Auth Client Time- RAD.AuthTimeouts Counter 32
outs

OA&M 9-45
Description
Method
Number of malformed Access Response packets received from the RADIUS server.
Malformed packets include packets with an invalid length (packet length is “less than the
minimum header length” OR “greater than the maximum allowed RADIUS packet
length”). Bad Authenticators, Signature Attributes, and unknown types are not included
as malformed access responses.
RADIUS Auth Client RAD.AuthMalforme Counter 32
Malformed Access dAccessResponse
Responses s
Number of Access Response packets received from the RADIUS server which had
invalid authenticators or signature attributes.
RADIUS Auth Client Bad RAD.AuthBadAuth Counter 32
Authenticators enticators
Number of RADIUS packets of unknown type which are received on the Authentication
Port.
Packet of unknown type corresponds to the packet with message type other than Access
Accept/Reject received on the RADIUS authentication port.
RADIUS Auth Client RAD.AuthUnknow Counter 32
Unknown Types nTypes
Number of RADIUS packets received on the Authentication Port which are dropped for
failure reasons other than one of the existing counters.
This counter is incremented for cases such as
1) Packet is received with an identifier value not available in the GGSN.
2) Other Internal software errors.

RADIUS Auth Client RAD.AuthPackets Counter 32
Packets Dropped Dropped
Spare counter RAD.spare1 TBD 32

APN Statistics
APN Accounting Element group.
Table 9-8
APN Counters
Description
Method
Counter element SM.ReportingInterval.Apn Gauge 32
Reporting interval
The provisioned name of the APN.
APN Name SPM_APN_NAME Identifier 64
character
s
These Gauge measurements provide the current number of active sessions per APN,
pegged by traffic class and allocation/retention priority indicated in the QoS profile.
They are incremented on transmission of a Create PDP Context Response with cause
“Request Accepted” and decremented on transmission or receipt of a Delete PDP
Context Response. In the case of a successful QoS update for an active PDP context,
the counter corresponding to the old QoS will be decremented and the counter
corresponding to the new QoS will be incremented.
TC: Background; A/R: SM.NbrActPdpCtxt.Apn.Bgrd. Gauge 32
Low Low
TC: Interactive; A/R: SM.NbrActPdpCtxt.Apn.Intact. Gauge 32
Low Low
TC: Streaming; A/R SM.NbrActPdpCtxt.Apn.Strm. Gauge 32
Low Low
TC: Conversational; SM.NbrActPdpCtxt.Apn.Conv. Gauge 32
A/R Low Low
Medium Medium
Medium Medium
Medium Medium
A/R Medium Medium
High High

OA&M 9-47
Description
Method
High High
High High
A/R High High
This measurement provides the number of non-duplicate, PDP context activation
procedures initiated by the MS, and is incremented on receipt of a Create PDP
Context Request message from the SGSN. This measurement will not include those
measurements dropped before their APN is determined.
Attempted MS- SM.AttActPdpCtxt.Apn Counter 32
Initiated Sessions
This measurement provides the number of successfully completed activations of
PDP contexts, and is incremented on transmission of a Create PDP Context
Response message with cause “Request Accepted”.
Successfully SM.SuccActPdpCtxt.Apn Counter 32
Established MS-
Initiated sessions
This measurement provides the number of non-duplicate, dynamic PDP context
activation procedures initiated by the MS where a dynamic PDP address is requested,
and is incremented on receipt of a Create PDP Context Request message with an
empty PDP address. This measurement will not include those messages that are
dropped before the PDP address is determined.
Attempted MS- SM.AttDynActPdpCtxt.Apn Counter 32
Initiated Session
Activations with
Dynamic PDP
Address Allocation
Required
This measurement provides the number of successfully established sessions where
a dynamic PDP address is requested, and is incremented on transmission of a Create
PDP Context Response message with cause “Request Accepted”, where the PDP
address has been dynamically assigned.
Successfully SM.SuccDynActPdpCtxt.Apn Counter 32
Established MS-
Initiated sessions
with Dynamic PDP
Address Allocation
Required
This measurement provides the number of non-duplicate, PDP context activation
procedures for which user authentication is required, and is incremented when a
Create PDP Context Request message is received for which the APN indicates that
user authentication is required.

Description
Method
Attempted Session SM.AttActPdpCtxtAutReq.Apn Counter 32
Establishments with
User Authentication
Required
This measurement provides the number of PDP context activation procedures which
failed due to AAA and SCP authentication failure.
Failed Session SM.FailActPdpCtxtAutReq.Ap Counter 32
Establishments Due n
to AAA and SCP
Authentication
Failure
This measurement provides the number of session establishment failures per APN
and is incremented whenever there is a Radius related failure for an APN
Failed Session SM.FailActPdpCtxtAuthReq.R Counter 32
Establishments Due adius.Apn
to RADIUS Failure
and is incremented whenever there is a SCP related failure for an APN
Failed Session SM.FailActPdpCtxtAuthReq.S Counter 32
Establishments Due CP.Apn
to SCP Failure
and is incremented whenever there is a Diameter related failure for an APN
Failed Session SM.FailActPdpCtxtAuthReq.Di Counter 32
Establishments Due ameter.Apn
to Diameter Failure
This measurement provides the number of PDP context attempted to move to the
target ssp during SSM Redundancy and is incremented for the user APN by 1 as it is
attempted to move.
Attempted move PDP SM.AttSsmrPdpCtxt.Apn Counter 32
contexts - SSM
Redundancy
This measurement provides the number of PDP context attempted to move to the
target ssp during SSM Redundancy and is incremented for the user APN by 1 when a
PDP contexts is successfully moved to the target ssp.
Successfully moved SM.SuccSsmrPdpCtxt.Apn Counter 32
PDP contexts - SSM
Redundancy
This measurement provides the number of PDP context deactivation procedures
initiated by either the MS or SGSN, and is incremented on receipt of a Delete PDP
Context Request message from the SGSN for an existing PDP context.

OA&M 9-49
Description
Method
Attempted MS- and SM.AttDeactPdpCtxtMsAndSg Counter 32
SGSN-Initiated sn.Apn
Session Conclusions
This measurement provides the number of successfully completed PDP context
deactivation procedures initiated by either the MS or SGSN, and is incremented on
transmission of a Delete PDP Context Response message with cause “Request
Accepted” to the SGSN for an existing context which is successfully deleted.
Successful MS- and SM.SuccDeactPdpCtxtMsAnd Counter 32
SGSN-Initiated Sgsn.Apn
Session Conclusions
This measurement provides the number of PDP context deactivation procedures
initiated by the GGSN, and is incremented on transmission of a Delete PDP Context
Request message to the SGSN.
Attempted GGSN- SM.AttDeactPdpCtxtGgsn.Apn Counter 32
Initiated Session
Conclusions
This measurement provides the number of successfully completed PDP context
deactivation procedures initiated by the GGSN, and is incremented when a context is
successfully deleted due to a Delete PDP Context Response message with cause
“Request Accepted” from the SGSN, N3 Timer expiry or successful silent deletion.
Successful GGSN- SM.SuccDeactPdpCtxtGgsn.A Counter 32
Initiated Session pn
Conclusions
This measurement provides the number of PDP Context Deactivations initiated by
GGSN during SSM Redundancy. It is incremented for the user APN by 1 as the
process of removing a PDP Context starts in GGSN.
Attempted GGSN SM.AttDeactPdpCtxtGgsn.Ss Counter 32
initiated deactivation mr.Apn
- SSM Redundancy
This measurement provides the number of PDP Context Successful Deactivations
initiated by GGSN during SSM Redundancy. It is incremented for the user APN by 1
when a PDP Context is successfully removed from GGSN.
Successful GGSN SM.SuccDeactPdpCtxtGgsn.S Counter 32
initiated deactivation smr.Apn
- SSM Redundancy
This measurement provides the peak number of active PDP contexts in GGSN during
the interval period, and is obtained by comparing an update on the actual number of
active PDP contexts in the GGSN and the current maximum value of the
measurement.
Peak Number of SM.MaxNbrActPdpCtxt.Apn High Tidemark 32
Sessions

Description
Method
This measurement provides the number of PDP context updates attempted, and is
incremented on receipt of an Update PDP Context Request message for an existing
PDP context.
Attempted MS- & SM.AttUpdPdpCtxtMsAndSgs Counter 32
SGSN-Initiated PDP n.Apn
Context Updates
This measurement provides the number of successfully performed PDP context
updates, and is incremented on transmission of an Update PDP Context message
Successfully SM.SuccUpdPdpCtxtMsAndS Counter 32
Performed MS- & gsn.Apn
SGSN-Initiated PDP
Context Updates
This measurement provides the number of PDP context updates generated by the
GGSN, retransmissions excluded.
Attempted GGSN- SM.AttUpdPdpCtxtGgsn.Apn Counter 32
Initiated PDP Context
Updates
This measurement provides the number of successfully performed PDP context
updates, and is incremented on receipt of an Update PDP Context response message
Successfully SM.SuccUpdPdpCtxtGgsn.Ap Counter 32
Performed GGSN- n
Initiated PDP Context
Updates
Counts number of context creation requests rejected due to either APN
administrative state disabled, or ISP operational state down.
PDP Context failed SM.FailActPdpCtxtApnDown. Counter 32
due to APN down. Apn
Counts number of context creation requests rejected due to IP address unavailability
from local address pools.
PDP Context failed SM.FailActPdpCtxtNoIPfound. Counter 32
due to unavailable IP Apn
addresses in local
address pools.
These Gauge measurements provide the current number of active sessions per APN,
pegged by the type of IP address allocated for the session. They are incremented on
transmission of a Create PDP Context Response with cause “Request Accepted” and
decremented on transmission or receipt of a Delete PDP Context Response.
Active PDP Contexts SM.NbrDynActPdpCtxt.Apn Gauge 32
with Dynamic IP
Address

OA&M 9-51
Description
Method
Active PDP Context SM.NbrStaticActPdpCtxt.Apn Gauge 32
with Static IP Address
This counter is incremented when a GGSN attempts to deactivate a GTP context due
to manual intervention.
Attempted GGSN SM.AttDeactPdpCtxtGgsn.Ma Counter 32
Initiated Deactivation nual.Apn
- Manual
This counter is incremented when a GGSN completes deactivation of a GTP context
due to manual intervention
Successful GGSN SM.SuccDeactPdpCtxtGgsn.M Counter 32
Initiated Deactivation anual.Apn
- Manual
to expiry of the idle timer.
Attempted GGSN SM.AttDeactPdpCtxtGgsn.ITO. Counter 32
Initiated Deactivation Apn
- Idle Timer
due to expiry of the idle timer.
Successful GGSN SM.SuccDeactPdpCtxtGgsn.IT Counter 32
Initiated Deactivation O.Apn
- Idle Timer
to expiry of the maximum session duration timer.
Attempted GGSN SM.AttDeactPdpCtxtGgsn.Max Counter 32
Initiated Deactivation Dur.Apn
- Max Session
Duration
due to expiry of the maximum session duration timer.
Successful GGSN SM.SuccDeactPdpCtxtGgsn.M Counter 32
Initiated Deactivation axDur.Apn
- Max Session
Duration
to a SGSN restart.
Attempted GGSN SM.AttDeactPdpCtxtGgsn.Sgs Counter 32
Initiated Deactivation nRstrt.Apn
- SGSN Restart
due to a SGSN restart.

Description
Method
Initiated Deactivation gsnRstrt.Apn
- SGSN Restart
This measurement provides the number of PDP Context Deactivation Attempt
initiated by GGSN due to no resource on the target SSP during SSM Redundancy. It is
incremented for user APN by 1 as the process of removing the PDP Context starts in
GGSN.
initiated deactivation mr.NoResource.Apn
- SSM Redundancy
No Resource
initiated by GGSN due to no resource on target ssp during SSM Redundancy.It is
incremented for user APN by 1 when PDP Context is successfully taken down from
GGSN.
initiated deactivation smr.NoResource.Apn
- SSM Redundancy
No Resource
This measurement provides the number of aggregation PDP Context Deactivations
initiated by GGSN as the second move is not allowed during SSM Redundancy. It is
GGSN.
initiated deactivation mr.NoSecondMove.Apn
- SSM Redundancy
No Second Move
Deactivations initiated by GGSN as the second move is not allowed during SSM
Redundancy. It is incremented for user APN by 1 when PDP Context is successfully
taken down from GGSN.
initiated deactivation smr.NoSecondMove.Apn
- SSM Redundancy
No Second Move
This measurement provides the number of PDP Context Deactivation Attempt
initiated by GGSN due to system failure during SSM Redundancy. It is incremented
for user APN by 1 as the process of removing the PDP Context starts in GGSN.
initiated deactivation mr.SystemFailure.Apn
- SSM Redundancy
System Failure

OA&M 9-53
Description
Method
initiated by GGSN due to system failure during SSM Redundancy. It is incremented
for user APN by 1 when PDP Context is successfully taken down from GGSN.
initiated deactivation smr.SystemFailure.Apn
- SSM Redundancy
System Failure
This measurement provides the number of aggregation PDP Context Deactivations
initiated by GGSN as the SSM redundancy for Aggregation was not Enabled. It is
GGSN.
initiated deactivation mr.Disabled.Apn
- SSM Redundancy
for Aggregation is
disabled
Deactivations initiated by GGSN as the SSM redundancy for Aggregation is not
Enabled. It is incremented for user APN by 1 when PDP Context is successfully taken
down from GGSN
initiated deactivation smr.Disabled.Apn
- SSM Redundancy
for Aggregation is
disabled
This measurement provides the number of PDP context activation procedures which
failed due to the Visited GGSN Access Control rejection, incremented when a Create
PDP Context Response message with cause “User Authentication Failed” is sent.
Failed Session SM.PdpCtxtAclRej.Apn Counter 32
Establishments Due
to Access Control
rejection
This Gauge measurement provides the current number of active prepaid sessions per
APN. This includes prepaid services that use CTP as well as DCC.
Active Prepaid SM.NbrActCtxtPrepaid.Apn Gauge 32
Contexts
This measurement provides the number of successfully established sessions using
Basic Access Mode (untunneled).
Successfully SM.SuccActBamCtxt.Apn Counter 32
Established Basic
Access Mode
sessions

Description
Method
IPSec.
Successfully SM.SuccActIpsecCtxt.Apn Counter 32
Established IPSec
sessions
GRE.
Successfully SM.SuccActGreCtxt.Apn Counter 32
Established GRE
sessions
L2TP.
Successfully SM.SuccActL2tpCtxt.Apn Counter 32
Established L2TP
sessions
L2TP/IPSec.
Successfully SM.SuccActL2ipCtxt.Apn Counter 32
Established L2TP/
IPSec sessions
This counter provides the number of non-duplicate, attempted Secondary PDP
Context establishments. A Secondary PDP Context is classified during parsing of the
Create PDP Context request. If the GGSN control TEID in the GTP header has already
been assigned and no IMSI is present, this counter will be incremented.
Number of Attempted SM.AttActSecPdpCtxt.Apn Counter 32
Secondary PDP
Context
Establishments
This counter provides the number of successful Secondary PDP Context
establishments.
Number of SM.SuccActSecPdpCtxt.Apn Counter 32
Successful
Secondary PDP
Context
Establishments
This counter provides the number of failed Secondary PDP contexts due to no
resources in the data plane.
Number of Failed SM.FailActSecPdpCtxt.NoData Counter 32
Secondary PDP PlaneRsrc.Apn
Contexts due to No
Resources in the Data
Plane

OA&M 9-55
Description
Method
This measurement provides the number of primary PDP contexts created on an APN
with their billing parameters overridden by the IMSI Billing profile associated with that
APN. This counter is incremented by one when a Create PDP Context Request is
received from the SGSN containing an APN with an IMSI Billing profile configured and
the IMSI present in the request matches at least one rule in the profile. Note that for
APNs with no IMSI Billing profile configured, this counter will never be incremented.
Successful IMSI SM.IMSIRuleMatchSucc.Apn Counter 32
Billing Match
This measurement provides the number of primary PDP contexts created on an APN
with an IMSI Billing profile with their APN Billing parameters NOT overridden by the
IMSI Billing profile for that APN. This counter is incremented by one when a Create
PDP Context Request is received from the SGSN containing an APN with an IMSI
Billing profile configured and the IMSI present in the request does not match at least
one rule in the profile. Note that for APNs with no IMSI Billing profile configured, this
counter will never be incremented.
UnSuccessful IMSI SM.IMSIRuleMatchFail.Apn Counter 32
Billing Match
This measurement provides the number of rule comparisons made for APNs with an
IMSI Billing profile. This counter is incremented by one for each rule comparison
made when a Create PDP Context Request is received from the SGSN containing an
APN with an IMSI Billing profile configured. Note that for APNs with no IMSI Billing
profile configured, this counter will never be incremented.
Total number of IMSI SM.IMSITotRuleComparisons. Counter 32
Billing rule Apn
comparisons
MPLS.
Successfully SM.SuccActMPLSCtxt.Apn Counter 32
Established MPLS
sessions
This measurement provides the number of simultaneous active sessions that were
created with Content Based Billing enabled per APN.
Total Sessions with SM.SuccActCbbCtxt.Apn Counter 32
CBB
This measurement provides the current number of simultaneous active sessions
were successfully created with Content Based Billing enabled per APN.
Active Sessions with SM.NbrActCbbCtxt.Apn Gauge 32
CBB
This measurement provides the maximum number of sessions present during the
recording period that were created with Content Based Billing enabled.
Peak Simultaneous SM.MaxNbrActCbbCtxt.Apn High Tidemark 32
Sessions with CBB Gauge

Description
Method
This measurement shows the number of successfully established contexts
requesting P-CSCF Address Discovery. This counter is incremented even if the P-
CSCF Address Discovery request is not fulfilled.
P-CSCF Address SM.SuccActCtxtPcscfDiscReq Counter 32
Requests .Apn
This measurement shows the number of successfully established contexts
requesting P-CSCF Address Discovery where the P-CSCF Address Discovery request
could not be fulfilled. This could be because there is no IMS Profile associated with
the APN or the associated profile contained no addresses.
P-CSCF Address SM.SuccActCtxtPcscfDiscFail Counter 32
Request Failed ed.Apn
This measurement provides the current number of active context bundles that
successfully requested P-CSCF Address Discovery.
Simultaneous Active SM.NbrActPcscfDiscCtxt.Apn Gauge 32
Sessions Requesting
P-CSCF Discovery
This measurement provides the maximum number of simultaneous active context
bundles that successfully requested P-CSCF Address Discovery.
Peak Number of SM.MaxNbrActPcscfDiscCtxt. High Tidemark 32
Simultaneous Active Apn Gauge
Sessions Requesting
P-CSCF Discovery
This measurement provides the number of times the APN has been blacklisted during
the historical collection period and is incremented whenever the APN is blacklisted.
This measurement is reported on a per-APN basis
Number of times the SM.NbrBlacklist.Apn Counter 32
APN has been
Blacklisted
and is incremented whenever there is an PDP context activation attempt after an APN
is blacklisted.
Failed Session SM.FailActPdpCtxtApnBlackli Counter 32
Establishments Due st.Apn
to APN being
Blacklisted
and is incremented upon transmission of a non-duplicate Create PDP Context
Response with failure cause NORA (No Resources Available)
Failed Session SM.FailActPdpCtxt.NORA.Apn Counter 32
Establishments Due
to No Resource
Available

OA&M 9-57
Description
Method
Response with failure cause ADAO (All Dynamic Addresses Occupied). The reasons
for this could be: Address pools for the APN are exhausted (GTPv1).
Failed Session SM.FailActPdpCtxt.ADAO.Apn Counter 32
Establishments Due
to exhaustion of
address pools
Response with failure cause UAUF (User Authentication Failure).
Failed Session SM.FailActPdpCtxt.UAUF.Apn Counter 32
Establishments Due
to User
Authentication
Failure
Response with failure cause SYSF (System Failure).
Failed Session SM.FailActPdpCtxt.SYSF.Apn Counter 32
Establishments Due
to System Failure
Response with failure cause SEME (Semantic or Syntactic TFT or Packet Filter Error).
The reasons for this could be: Invalid traffic flow template format (GTPv1). This
counter is not pegged and is meant for future use.
Failed Session SM.FailActPdpCtxt.SEME.Apn Counter 32
Establishments Due
to Semantic or
Syntactic TFT or
Packet Filter Error
Response with failure cause IEIN (Mandatory IE Incorrect, IE missing or Optional IE
Incorrect). The reasons for this could be: Length of mandatory/optional IE within
message does not match with actual length specified or Mandatory IE missing from
message. This counter is not pegged and is meant for future use.
Failed Session SM.FailActPdpCtxt.IEIN.Apn Counter 32
Establishments Due
to Mandatory IE
Incorrect, IE missing
or Optional IE
Incorrect

Description
Method
Response with failure cause IMFT (Invalid Message Format). The reasons for this
could be: Length of GTP packet in header does not match with actual length, Out of
Order IE or No GSN address or TEID in message. This counter is not pegged and is
meant for future use
Failed Session SM.FailActPdpCtxt.IMFT.Apn Counter 32
Establishments Due
to Invalid Message
Format
Response with failure cause SVNS (Service Not Supported).
Failed Session SM.FailActPdpCtxt.SVNS.Apn Counter 32
Establishments Due
to Service Not
Supported
Response with failure cause NoResp (No Response) which is not sent. This counter is
only pegged in the following cases:
Fallback/ Fallforward failure scenarios
Failures dues to configuration settings wherein return code is configured as “No

Response”
Failed Session SM.FailActPdpCtxt.NoResp.A Counter 32
Establishments Due pn
to No Response
This counter shows the number of contexts terminated by the GGSN as a result of
either CCFH set to Terminate or RetryAndTerminate
This counter is not pegged for CCR Final.

Number of contexts SM.NbrDeactPdpCtxtCCFH.Ap Counter 32
terminated due to n
DCC Failure Handling
action
This counter shows the number of context converted to non-prepaid as a result of
any failure and CCFH is set to continue.
(i.e. Tr expiry, Transport failure)

OA&M 9-59
Description
Method
Number of contexts SM.NbrCtxtPrepaidToNonPrep Counter 32
converted to postpaid aid.CCFH.Apn
due to DCC Failure
Handling
This counter shows the number of context converted to non-prepaid upon reception
of CC-Not-Applicable result code.
Number of contexts SM.NbrCtxtPrepaidToNonPrep Counter 32
converted to postpaid aid.CCNotApp.Apn
upon reception of
DCC Not Applicable
This counter shows the Number of contexts terminated by DCC server direction as
described below
1. Receive ASR form the DCC Server.
2. Receive a CCA with Result code User Unknown.
3. Receive CCA with Result code End User Service Denied.
3. Receive CCA with Result code Diameter Authorization Rejected
Number of contexts SM.NbrDeactPdpCtxtDCCServ Counter 32

terminated by DCC er.Apn
server direction
Indicates the number of Attempts of SGSN Update PDP Request for Direct Tunnel
Establishment on per APN basis. This stat is incremented irrespective of “DIRECT
TUNNEL” SOC state (i.e. SOC enabled/disabled)
Attempted Direct SM.AttUpdPdpCtxtMsAndSgs Counter 32
Tunnel Activate n.DT.Apn
Updates for particular
APN
Indicates the number of Successful SGSN Update PDP context requests for Direct
Tunnel on per APN basis when the SOC is enabled. This stat is not incremented when
“DIRECT TUNNEL” SOC is disabled.
Successful Direct SM.SuccUpdPdpCtxtMsAndS Counter 32
Tunnel Activate gsn.DT.Apn
Updates
Indicates the number of attempts of GGSN initiated Update request(s) due to Error
Indication Handling for a Direct Tunnel context on per APN basis. This stat is
incremented irrespective of “DIRECT TUNNEL” SOC state.

Description
Method
Attempted GGSN SM.AttUpdPdpCtxtGgsn.DT.A Counter 32
Initiated pn
Update Requests for
Error Indication
received on GGSN for
a context in Direct
Tunnel for particular
APN
Indicates the number of Successful GGSN initiated Update request(s) due to Error
Indication Handling for context involved in Direct Tunnel on per APN basis. This stat
is incremented irrespective of “DIRECT TUNNEL” SOC state.
Successful GGSN SM.SuccUpdPdpCtxtGgsn.DT. Counter 32
Initiated Apn
Update Requests for
Error Indication
received on GGSN for
context in Direct
Tunnel for particular
APN
Indicates the number of Attempts of SGSN Update Request sent to deactivate the
Direct Tunnel on per APN basis. This stat is incremented irrespective of “DIRECT
Attempted Direct SM.AttUpdPdpCtxtMsAndSgs Counter 32
Tunnel De-activate n.deactDT.Apn
Update request for
particular APN
Indicates the number of Successful SGSN Update Request sent to deactivate the
Direct Tunnel on per APN basis. This stat is incremented irrespective of “DIRECT
Successful Direct SM.SuccUpdPdpCtxtMsAndS Counter 32
Tunnel De-activate gsn.deactDT.APN
Update request for
particular APN
This measurement indicates the number of failed Update responses encountered by
GGSN for the GGSN Initiated Update request sent for Error Indication Handling for a
context involved in Direct Tunnel on per APN basis. This stat is incremented
irrespective of “DIRECT TUNNEL” SOC state.
Failed Update SM.FailUpdPdpCtxtGgsn.DT.A Counter 32
Response from SGSN pn
for GGSN Initiated
Update Request for
Error Indication
Handling for context
in Direct Tunnel

OA&M 9-61
Description
Method
Indicates the current number of Sessions in Direct Tunnel on per APN basis when SOC
is Enabled. This stat is not incremented when “DIRECT TUNNEL” SOC is disabled.
Number of Active SM.NbrDirectTunnels.Apn Gauge 32
Direct Tunnel
sessions for
particular APN
Spare counter SM.spare1.Apn TBD 32
CGF Statistics
Table 9-9 describes the counters that will be collected as part of the CGF
Accounting Element group.
Table 9-9
CGF Counters
Description
Method
This counter gives the time difference in seconds between the start and stop of
the statistics collection period. This counter facilitates a more accurate analysis
of the statistics for a given accounting interval.
Counter element Reporting CGF.ReportingInte Gauge 32
interval rval
The IP Address of the CGF server.
CGF Server Address CGF.Server Identifier 18
character
s
This measurement provides the number of Echo Request messages sent. This
measurement is incremented on transmission of an Echo Request message to a
CGF via the Ga interface.
Number of Echo Request CGF.EchoReqSent Counter 32
Messages Sent

Description
Method
This measurement provides the number of Echo Response messages sent. This
measurement is incremented on transmission of an Echo Response to a CGF via
the Ga interface.
Number of Echo Response CGF.EchoRespSe Counter 32
Messages Sent nt
This measurement provides the number of Node Alive Request messages sent.
This measurement is incremented on transmission of a Node Alive Request
message to a CGF via the Ga interface.
Number of Node Alive CGF.NodeAliveRe Counter 32
Requests Sent q
This measurement provides the number of Node Alive Response messages
receive. This measurement is incremented on receipt of a Node Alive Response
message from a CGF via the Ga interface.
Number of Node Alive CGF.NodeAliveRe Counter 32
Responses Received sp
Spare counter CGF.spare1 TBD 32
L2TP Statistics
Table 9-10 describes the counters that will be collected as part of
the L2TP Accounting Element group.
Table 9-10
L2TP Counters
Description
Method (bits)

OA&M 9-63
Description
Method (bits)
Counter element Reporting L2TP.ReportingInt Gauge 32
interval erval
This measurement provides the current number of active L2TP tunnels (not over
IPSec), and is incremented on the creation of an L2TP tunnel on the Gi interface
and decremented on removal of an L2TP tunnel on the Gi interface.
Simultaneous L2TP tunnels L2TP.NbrTunnels Gauge 32
on Gi Interface
This measurement provides the number of L2TP octets received and is
incremented on receipt of an IP packet in an L2TP tunnel on the Gi interface. The
data packet size is extracted from the packet header and added on to the
measurement value.
L2TP Octets Received L2TP.IncDataOct Counter 64
This measurement provides the number of L2TP octets sent and is incremented
on transmission of an IP packet in an L2TP tunnel on the Gi interface. The data
packet size is extracted from the packet header and added on to the
measurement value.
L2TP Octets Sent L2TP.OutDataOct Counter 64
This measurement provides the number of incoming L2TP packets discarded
and is incremented whenever an IP packet received in an L2TP tunnel is
discarded.
Discarded L2TP Data L2TP.DiscDataPkt Counter 64
Packets
This measurement provides the number of L2TP packets received and is
incremented on receipt of an IP packet in an L2TP tunnel on the Gi interface.
Received L2TP Data L2TP.IncDataPkt Counter 64
Packets
This measurement provides the number of L2TP packets sent and is
incremented on transmission of an IP packet in an L2TP tunnel on the Gi
interface.
L2TP Data Packets Sent L2TP.OutDataPkt Counter 64
Spare counter L2TP.spare1 TBD 64

Description
Method (bits)
L2IP Statistics
Table 9-11 describes the counters that will be collected as part of the
L2TP over IPSec (L2IP) Accounting Element group.
Table 9-11
L2IP Counters
Description
Method (bits)
Counter element Reporting L2IP.ReportingInte Gauge 32
interval rval
This measurement provides the current number of active L2TP over IPSec
tunnels, and is incremented on the creation of an L2TP/IPSec tunnel on the Gi
interface and decremented on removal of an L2TP/IPSec tunnel on the Gi
interface.
Simultaneous L2TP/IPSec L2IP.NbrTunnels Gauge 32
tunnels on Gi Interface
This measurement provides the number of L2TP/IPSec octets received and is
incremented on receipt of an IP packet in an L2TP/IPSec tunnel on the Gi
interface. The data packet size is extracted from the packet header and added on
to the measurement value.
L2TP/IPSec Octets L2IP.IncDataOct Counter 64
Received
This measurement provides the number of L2TP/IPSec octets sent and is
incremented on transmission of an IP packet in an L2TP/IPSec tunnel on the Gi
interface. The data packet size is extracted from the packet header and added on
to the measurement value.
L2TP/IPSec Octets Sent L2IP.OutDataOct Counter 64
This measurement provides the number of incoming L2TP/IPSec packets
discarded and is incremented whenever an IP packet received in an L2TP/IPSec
tunnel is discarded
Discarded L2TP/IPSec Data L2IP.DiscDataPkt Counter 64
Packets

OA&M 9-65
Description
Method (bits)
This measurement provides the number of L2TP/IPSec packets received and is
incremented on receipt of an IP packet in an L2TP/IPSec tunnel on the Gi
interface.
Received L2TP/IPSec Data L2IP.IncDataPkt Counter 64
Packets
This measurement provides the number of L2TP/IPSec packets sent and is
incremented on transmission of an IP packet in an L2TP/IPSec tunnel on the Gi
interface
L2TP/IPSec Data Packets L2IP.OutDataPkt Counter 64
Sent
Spare counter L2IP.spare1 TBD 64
IPSec Statistics
IPSec Accounting Element group.
Table 9-12
IPSec Counters
Description
Method (bits)
Counter element Reporting IPSec.ReportingInt Gauge 32
interval erval

Description
Method (bits)
This measurement provides the number of IPSec octets received and is
incremented on receipt of an IP packet in an IPSec tunnel on the Gi interface.
The data packet size is extracted from the packet header and added on to the
measurement value.
IPSec Octets Received IPSec.IncDataOct Counter 64
This measurement provides the number of IPSec octets sent and is incremented
on transmission of an IP packet in an IPSec tunnel on the Gi interface. The data
packet size is extracted from the packet header and added on to the
measurement value.
IPSec Octets Sent IPSec.OutDataOct Counter 64
This measurement provides the number of incoming IPSec packets discarded
and is incremented when an IP packet received in an IPSec tunnel is discarded.
IPSec Packets Discarded IPSec.DiscDataPkt Counter 64
This measurement provides the number of IPSec packets received and is
incremented on receipt of an IP packet in an IPSec tunnel on the Gi interface.
IPSec Packets Received IPSec.IncDataPkt Counter 64
This measurement provides the number of IPSec packets sent and is
incremented on transmission of an IP packet in an IPSec tunnel on the Gi
interface.
IPSec Packets Sent IPSec.OutDataPkt Counter 64
Spare counter IPSec.spare1 TBD 64
Overload Statistics
Each resource that is monitored by overload control has it’s own set of
statistics. Currently - CPU total, CPU interrupt and system memory
resources are being monitored by overload control on CMC Processor
0, CMC Processor 1, and on the SSC SSM processors. These
statistics are incremented when the resource enters into an overload
level and gets reset to zero after the OMs have been collected. The
resource overload statistics have been captured in Table 9-13.

OA&M 9-67
Overload stats are generated and displayed on the SCS accounting

server. The collection interval is configurable via SCS.
Table 9-13
CMC Resource Overload Counters
Description
Method (bits)
Counter element Reporting Ovld.ReportingInterval Gauge 32
interval
Slot - Chassis slot of the card from which the OMs are collected.
Indicates the slot number Ovld.Slot Identifier 16
of the card where the OMs
are collected from.
Port - the port of the Slot from which the OMs are collected from.
Indicates the port number Ovld.Port Identifier 16
where the OMs are
collected from.
Proc - the processor on the specified port where the OMs are collected from.
Indicates the processor Ovld.Proc Identifier 16
number from which the
OMs are collected from.
This is the highest weighted average percentage of CPU Total occupancy. This OM gets
reset to zero after the OM has been collected.
Highest weighted average Ovld.CpuTot.HighestAvgPc High Tidemark 16
percentage of CPU total t Gauge
occupancy.
This measurement provides the lowest percentage of CPU occupancy of the processor.
The CPU occupancy values are obtained every update interval and the lowest weighted
average of these values is reported by this OM.This OM gets reset to zero after the OM
has been collected.
Minimum weighted average Ovld.CpuTot.LowestAvgPct Low Tidemark 16
percentage of CPU total Gauge
occupancy
This measurement provides the average percentage of CPU occupancy of the processor.
The CPU occupancy values are obtained every update interval and a simple average of
these values is reported by this OM. This OM gets reset to zero after the OM has been
collected.
Average percentage of CPU Ovld.CpuTot.AvgPct gauge 16
total occupancy

Description
Method (bits)
This is the overload level at the start of the OM collection period for CPU Total occupancy.
This OM gets reset to zero after the OM has been collected.
Overload level of CPU total Ovld.CpuTot.StartLevel Gauge 16
at the start of OM collection
period.
Number of times ovld Normal was entered (transitions from L1 to Normal and from L2 to
Normal and from L3 to Normal) for CPU Total occupancy. This OM gets reset to zero after
the OM has been collected.
Number of times ovld Ovld.CpuTot.NormEntry Counter 16
Normal was entered for
CPU total.
Number of times ovld L1 was entered (transitions from Normal to L1) for CPU Total
occupancy. This OM gets reset to zero after the OM has been collected.
Number of times ovld L1 Ovld.CpuTot.L1Entry Counter 16
was entered for CPU total.
Number of times ovld L2 was entered (transitions from Normal to L2 and from L1 to L2)
for CPU Total occupancy. This OM gets reset to zero after the OM has been collected.
Number of times ovld L3 was entered (transitions from Normal to L3 and from L1 to L3
and from L2 to L3) for CPU Total occupancy. This OM gets reset to zero after the OM has
been collected.
Number of times ovld L2 was entered with a jump from Normal (transitions from Normal
to L2) for CPU Total occupancy. This OM gets reset to zero after the OM has been
collected.
Number of times ovld L2 Ovld.CpuTot.NormToL2Ent Counter 16
was entered from Normal ry
to L3) for CPU Total occupancy. This OM gets reset to zero after the OM has been
collected.
Number of times ovld L3 Ovld.CpuTot.NormToL3Ent Counter 16
was entered from Normal ry
Number of times ovld L3 was entered with a jump from L1 (transitions from L1to L3) for
CPU Total occupancy. This OM gets reset to zero after the OM has been collected.
Number of times ovld L3 Ovld.CpuTot.L1ToL3Entry Counter 16
was entered from L1
This is the highest weighted average percentage of CPU Interrupt occupancy. This OM
gets reset to zero after the OM has been collected.

OA&M 9-69
Description
Method (bits)
Highest weighted average Ovld.CpuInt.HighestAvgPct High Tidemark 16
percentage of CPU Gauge
Interrupt occupancy.
This is the overload level at the start of the OM collection period for CPU Interrupt
Overload level of CPU Int at Ovld.CpuInt.StartLevel Gauge 16
the start of OM collection
period.
Normal and from L3 to Normal) for CPU Interrupt occupancy. This OM gets reset to zero
after the OM has been collected.
Number of times ovld Ovld.CpuInt.NormEntry Counter 16
CPU Int.
Number of times ovld L1 was entered (transitions from Normal to L1) for CPU Interrupt
Number of times ovld L1 Ovld.CpuInt.L1Entry Counter 16
was entered for CPU Int.
for CPU Interrupt occupancy. This OM gets reset to zero after the OM has been collected.
and from L2 to L3) for CPU Interrupt occupancy. This OM gets reset to zero after the OM
has been collected.
to L2) for CPU Interrupt occupancy. This OM gets reset to zero after the OM has been
collected.
Number of times ovld L2 Ovld.CpuInt.NormToL2Entr Counter 16
was entered from Normal. y
to L3) for CPU Interrupt occupancy. This OM gets reset to zero after the OM has been
collected.
Number of times ovld L3 Ovld.CpuInt.NormToL3Entr Counter 16
was entered from Normal y
CPU Interrupt occupancy. This OM gets reset to zero after the OM has been collected.

Description
Method (bits)
Number of times ovld L3 Ovld.CpuInt.L1ToL3Entry Counter 16
was entered from L1
This is the highest number of allocated mega bytes of system memory. This OM gets
reset to zero after the OM has been collected.
Highest number of system Ovld.Mem.HighestAllocate High Tidemark 16
memory allocated in MB. d Gauge
This is the fragmentation check lowest block size available in system memory. This OM
gets reset to highest value (all 1’s 16-bit value) after the OM has been collected.
Fragmentation check Ovld.Mem.LowestFragBlkSi Low Tidemark 16
lowest block size available ze Gauge
in system memory in KB.
This measurement provides the CPU static memory Megabytes in use.

CPU Static Memory Usage Ovld.Mem.StaticUtil Gauge 16
This measurement provides the CPU static memory Megabytes available.
CPU Static Memory Free Ovld.Mem.StaticAvail Gauge 16
This measurement provides the CPU dynamic memory Megabytes available.
CPU Dynamic Memory Free Ovld.Mem.DynamicAvail Gauge 16
This is the overload level at the start of the OM collection period for system memory
Overload level of system Ovld.Mem.StartLevel Gauge 16
memory at the start of OM
collection period.
Normal and from L3 to Normal) for system memory occupancy. This OM gets reset to
zero after the OM has been collected.
Number of times ovld Ovld.Mem.NormEntry Counter 16
system memory.
Number of times ovld L1 was entered (transitions from Normal to L1) for system memory
Number of times ovld L1 Ovld.Mem.L1Entry Counter 16
was entered for system
memory.
for system memory occupancy. This OM gets reset to zero after the OM has been
collected.

OA&M 9-71
Description
Method (bits)
memory.
and from L2 to L3) for system memory occupancy. This OM gets reset to zero after the
OM has been collected.
memory.
to L2) for system memory occupancy. This OM gets reset to zero after the OM has been
collected.
Number of times ovld L2 Ovld.Mem.NormToL2Entry Counter 16
was entered from Normal
to L3) for system memory occupancy. This OM gets reset to zero after the OM has been
collected.
Number of times ovld L3 Ovld.Mem.NormToL3Entry Counter 16
was entered from Normal
system memory occupancy. This OM gets reset to zero after the OM has been collected.
Number of times ovld L3 Ovld.Mem.L1ToL3Entry Counter 16
was entered from L1
Total disk space un-used in megabytes.Total unused disk space is calculated/reported in
this counter at the time of reporting.
Free disk space on CMC Ovld.CmcDisk.AvailableSp Gauge 32
ace
Total disk space used in megabytes.Total used disk space is calculated/reported in this
counter at the time of reporting.
Used disk space on CMC. Ovld.CmcDisk.UsedSpace Gauge 32
Spare counter Ovld.spare1 TBD 16

Description
Method (bits)
Wireless Services Statistics

The following services related counters are added to the Nortel GGSN
to provide measurements on the usage of the WAP services and
Prepaid/GeoZone services. The wireless services statistics are not
collected unless at least one Application Profile or Tariff Profile is
configured.
Table 9-14
Wireless Services Counters
Description
Method (bits)
Counter element Reporting SERV.ReportingInterval Gauge 32
interval
This counter shows the number of Application Service Requests sent from the GGSN to
the Application Server/Gateway.
Number of application SERV.WAP.ReqSent Counter 32
service request messages
sent
This counter shows the number of Application Service Responses received by the GGSN
from the Application Server/Gateway.
Number of application SERV.WAP.RespRcvd Counter 32
service response
messages received
This counter shows the number of bad response from Application Server due to unknown
message type and bad authenticator
Number of invalid SERV.WAP.InvalidRespRcv Counter 32
application service d
response messages
received
This counter shows the number of prepaid request messages sent from the GGSN to a
CTP based Prepaid Server. This includes Initial Authorization, Mid-Call Authorization, and
Final Report messages.
Number of Service SERV.PrePaid.ReqSent Counter 32
Authorization request
messages sent

OA&M 9-73
Description
Method (bits)
This counter shows the number of prepaid response messages received by the GGSN
from a CTP based Prepaid Server. This includes responses to Initial Authorization, Mid-
Call Authorization, and Final Report messages.
Number of Service SERV.PrePaid.RespRcvd Counter 32
Authorization response
messages received
This counter shows the number of failed prepaid response messages received by the
GGSN from a CTP based Prepaid Server. This includes responses to Initial Authorization,
Mid-Call Authorization, and Final Report messages. A failed prepaid response message is
any response message with a failure value for the Service Response Code, or a Reauth
response message with at least one prepaid coupon that is not approved.
Number of Failed Auth SERV.PrePaid.FailedAuthR Counter 32
Response messages espRcvd
received
Spare counter SERV.spare1 TBD 32
GRE Statistics
GRE Accounting Element group.
Table 9-15
GRE Counters
Description
Method (bits)
Counter element Reporting GRE.ReportingInterval Gauge 32
interval

Description
Method (bits)
This measurement provides the number of GRE octets received and is incremented
on receipt of an IP packet in an GRE tunnel on the Gi interface. The data packet size is
extracted from the packet header and added on to the measurement value.
GRE Octets Received GRE.IncDataOct Counter 64
This measurement provides the number of GRE octets sent and is incremented on
transmission of an IP packet in an GRE tunnel on the Gi interface. The data packet
size is extracted from the packet header and added on to the measurement value.
GRE Octets Sent GRE.OutDataOct Counter 64
This measurement provides the number of GRE packets received and is incremented
on receipt of an IP packet in an GRE tunnel on the Gi interface.
GRE Packets Received GRE.IncDataPkt Counter 64
This measurement provides the number of GRE packets sent and is incremented on
transmission of an IP packet in an GRE tunnel on the Gi interface.
GRE Packets Sent GRE.OutDataPkt Counter 64
This measurement provides the number of incoming GRE packets discarded due to
memory issues.
GRE Packets Discarded GRE.DiscDataPkt.Mem Counter 64
due to Memory Issues
This measurement provides the number of incoming GRE packets discarded due to a
non-existent tunnel.
GRE Packets Discarded GRE.DiscDataPkt.NoTun Counter 64
due to Non-Existent Tunnel
routing issues.
GRE Packets Discarded GRE.DiscDataPkt.NoRoute Counter 64
due to Routing Issues
ethertype issues.
GRE Packets Discarded GRE.DiscDataPkt.Eth Counter 64
due to Ethertype Issues
unsupported strict source routing.
GRE Packets Discarded GRE.DiscDataPkt.SSR Counter 64
due to Unsupported Strict
Source Routing
bad checksum.
GRE Packets Discarded GRE.DiscDataPkt.BadCksum Counter 64
due to Bad Checksum

OA&M 9-75
Description
Method (bits)
bad key.
GRE Packets Discarded GRE.DiscDataPkt.BadKey Counter 64
due to Bad Key
bad sequence number.
GRE Packets Discarded GRE.DiscDataPkt.SeqNum Counter 64
due to Bad Sequence
Number
no connection interface.
GRE Packets Discarded GRE.DiscDataPkt.NoIF Counter 64
due to No Connection
Interface
This measurement provides the number of incoming GRE packets discarded due to IP
interrupt queue full.
GRE Packets Discarded GRE.DiscDataPkt.IPQFull Counter 64
due to IP Interrupt Queue
Full
Spare counter GRE.spare1 TBD 64
SCP Statistics
SCP Accounting Element group. All statistics in this group apply only
to CTP servers.

Table 9-16
SCP Counters
Description
Method (bits)
Counter element Reporting SCP.ReportingInterval Gauge 32
interval
The IP Address of the SCP server.
SCP Server SCP.Server Identifier 32
This counter shows the number of Initial Authorizations sent from the GGSN to a
Prepaid server. An Initial Authorization is either an Initial Authorization request
message, or a coupon being newly requested in a Mid-Call Authorization request
message. An Initial Authorization request message always counts as one Initial
Authorization, regardless of whether it includes suggested coupon rates (such as in
a CTPv3 Rate Request IE).
This counter is incremented as follows:
once for each Initial Authorization request message sent; and
once for each coupon rate included in a CTPv3 RateRequest IE in a Mid-Call

Authorization request message.
Number of Initial SCP.AttAuthReq Counter 32
Authorizations sent.
This counter shows the number of successful Initial Authorizations received by the
GGSN from a Prepaid server. An Initial Authorization is defined in the description of
SCP.AttAuthReq. A successful Initial Authorization is an Initial Authorization that is
approved by a Prepaid server.
This counter is incremented as follows
once for each successful Initial Authorization response message received,

irrespective of the set of coupons included in that response or in its corresponding
request; and
once for each rated coupon included in a successful Mid-Call Authorization response
message whose coupon rate was included in a CTPv3 Rate Request IE in the
corresponding request, and whose Include Reason indicates a successful
authorization.
A successful Initial Authorization or Mid-Call Authorization response message is one

such message with a successful Service Response Code.
Number of successful SCP.SuccAuthReq Counter 32
Initial Authorizations.

OA&M 9-77
Description
Method (bits)
This counter shows the number of Reauthorizations sent from the GGSN to a Prepaid
server. A Reauthorization is either a request to authorize additional prepaid
resources for a GTP context, or a request to authorize additional prepaid resources
for a specific prepaid coupon of a GTP context.
once for each Mid-Call Authorization request message sent that contains no prepaid
coupons; and
once for each prepaid coupon included in a Mid-Call Authorization request message
whose Include Reason indicates a reauthorization is being requested (i.e. a return is
not being requested).
This counter is not incremented for coupon rates included in a CTPv3 Rate Request
IE in a Mid-Call Authorization request message.
Number of SCP.AttReauthReq Counter 32
Reauthorizations sent
This counter shows the number of successful Reauthorizations. A Reauthorization is
defined in the description of SCP.AttReauthReq. A successful Reauthorization is a
Reauthorization that is approved by a Prepaid server.
once for each successful Mid-Call Authorization response message whose

corresponding request message includes no prepaid coupons; and
once for each prepaid coupon included in a successful Mid-Call Authorization

response message that is also included in the set of coupons being reauthorized (i.e.
not returned and not newly requested) in the corresponding Mid-Call Authorization
request message, and whose Include Reason in the response message indicates
successful reauthorization.
A successful Mid-Call Authorization response message is one such message with a

successful Service Response Code
This counter is incremented for all CTP versions.

Number of successful SCP.SuccReauthReq Counter 32
Reauthorizations
This counter shows the number of Final Report messages sent from the GGSN to a
Prepaid server.

Number of Final Report SCP.AttFinalReport Counter 32
messages sent

Description
Method (bits)
This counter shows the number of successful Final Report response messages
received by the GGSN from a Prepaid server.

Number of successful SCP.SuccFinalReport Counter 32
Final Report response
messages received
This counter shows the number of incoming CTP messages that failed during
parsing due to protocol errors.

Number of Prepaid SCP.ProtErr Counter 32
Request failures due to
protocol errors
This counter shows the number of prepaid request messages that failed due to a
request timeout. A prepaid request message is defined in the description of
SCP.ProtErr.

Number of Prepaid SCP.NoResp Counter 32
Request timeouts

OA&M 9-79
Description
Method (bits)
This counter shows the number of denied Authorizations. An Authorization is either
an Initial Authorization (defined in the description of SCP.AttAuthReq) or a
Reauthorization (defined in the description of SCP.AttReauthReq). A denied
Authorization is an Authorization that is denied by a Prepaid Server.
once for each unsuccessful Initial Authorization response message, irrespective of

the set of coupons included in the corresponding request;
once for each unsuccessful Mid-Call Authorization response message for which the
corresponding request message included no prepaid coupons;
once for each coupon that is implicitly denied in an unsuccessful Mid-Call

Authorization response message because it is included in the set of coupons being
either newly requested or reauthorized (but not returned) in the corresponding
request; and
once for each prepaid coupon that is explicitly denied in a successful Mid-Call
Authorization response message, and that is also included in the set of coupons
being either newly requested or reauthorized (but not returned) in the corresponding
request message.
An unsuccessful Initial Authorization or Mid-Call Authorization request message is

one such message with an unsuccessful Service Response Code. A coupon is
implicitly denied by including an unsuccessful Service Response Code in the Mid-
Call Authorization response message, and not including the coupon that was in the
corresponding request.

Number of Prepaid SCP.DeniedReq Counter 32
Request failures explicitly
denied.
This counter shows the number of coupons returned because of an Idle Timeout
expiry.

Number of returned SCP.ReturnCoupon.IdleTim Counter 32
coupons due to Idle eOut
Timeout.
This counter shows the number of coupons returned because of a Coupon Lifetime
expiry.

Description
Method (bits)
Number of returned SCP.ReturnCoupon.LifeTim Counter 32
coupons due to Lifetime eExpiry
Expiry.
This counter shows the number of GTP contexts taken down because rated coupons
are returned by a Prepaid server for a GTP context to which no CBB policy applies

Number of GTP contexts SCP.NoCouponNoCBB Counter 32
taken down due to rated
coupons with no CBB
This counter shows the number of redirection requests received by the GGSN from a
Prepaid Server. A redirection request is sent by the Online Charging Server in a
Reauth Response message with a Deny-Redirect Include Reason.

SCP Redirection Requests SCP.AttRedirectionReq Counter 32
This counter shows the number of Reauth Commands received by the GGSN from a
Prepaid Server. A Reauth Command is sent by the OCS to request the GGSN to
reauthorize some or all the coupons for a session.

SCP Reauth Commands SCP.ReauthCommandsRcv Counter 32
Received d
Spare counter SCP.spare1 TBD 32
ISP-IP Statistics
ISP-IP Accounting Element group. The ISP-IP statistics counts all IP
traffic that is sent and received on a particular ISP, not just subscriber
data plane traffic.

OA&M 9-81
Table 9-17
ISP-IP Counters
Description
Method (bits)
Counter element Reporting IP.ReportingInterval Gauge 32
interval
This measurement provides the number of IP packets received and is
incremented on receipt of an IP packet on the Gi interface.
IP Packets Received IP.IncDataPkt Counter 64
This measurement provides the number of IP packets sent and is incremented
on transmission of an IP packet on the Gi interface.
IP Packets Sent IP.OutDataPkt Counter 64
This measurement provides the number of IP octets received and is incremented
on receipt of an IP packet on the Gi interface.
IP Octets Received IP.IncDataOct Counter 64
This measurement provides the number of IP octets sent and is incremented on
transmission of an IP packet on the Gi interface.
IP Octets Sent IP.OutDataOct Counter 64
This measurement provides the number of incoming IP packets delivered locally
to an upper level of the protocol stack on the GGSN. (For e.g.: TCP, UDP, ICMP
etc) These IP packets are processed locally on the GGSN and not forwarded.
Number of IP packets IP.LocalDlvdPkt Counter 32
delivered locally
These are locally generated packets on the GGSN (For e.g.: CTP requests,
RADIUS requests etc.) and not received from any outside network element.
Number of IP packets IP.LocalGenPkt Counter 32
locally generated
This measurement provides the number of IP packets that have been fragmented
before transmission.
Number of fragmented IP IP.FragmentedPkt Counter 32
packets
This measurement provides the number of IP packets that have been
reassembled after being received.
Number of reassembled IP IP.ReassembledPkt Counter 32
packets
This measurement provides the number of IP fragments transmitted.
Number of transmitted IP IP.OutFragments Counter 32
fragments

Description
Method (bits)
This measurement provides the number of IP packets that could not be
fragmented before transmission.
Number of IP packets that IP.NoFragmentPkt Counter 32
could not be fragmented
This measurement provides the total number of bad IP packets. Packets are
classified as bad if they have a bad checksum, the packet length is too short, not
enough data is contained within the packet, the IP header length is bad, or the IP
version is bad.
Total number of bad IP IP.BadPkt Counter 32
packets
This measurement provides the number of incoming IP packets received which
are for an unreachable destination.
Number of IP packets IP.DestUnrchPkt Counter 32
received for an unreachable
destination
This measurement provides the total number of dropped IP packets. Packets are
dropped due to lack of memory, lack of buffer space, an interface is down, or
due to packet classification.
Total number of dropped IP IP.DropPkt Counter 32
packets
This measurement provides the total number of IP packets dropped by indexed
services. The indexed services refer to IP services which are supported by the
GGSN and are applied to the subscriber’s data on the Gi interface. This counter
is also incremented when a Content Filter Service drops an IP packet. Packets
can be dropped by the Content Filter Service for several reasons. Some of them
are:
Mobile originated packet destined for a reset TCP connection.
Mobile originated request packet is received, when cached HTTP/TCP block/

redirect responses exist. Request must be retransmitted by mobile after block/
redirect messages are sent to mobile (due to TCP sequencing).
Mobile originated packet is received while waiting for a TCP FIN response packet
from mobile, after GGSN closes connection (following a block/redirect).
Web server originated packet after TCP connection was reset.
Concatenated connected WAP request is received and must be chopped into

multiple requests, due to mixed allowed/blocked/redirect case. Original request
packet is dropped.
Total number of IP packets IP.DropIndxSvcPkt Counter 32
dropped by indexed
services.

OA&M 9-83
Description
Method (bits)
Spare counter IP.spare1 TBD 32
Ancillary APN Statistics

Ancillary APN Accounting Element group.
Table 9-18
Ancillary APN Counters
Description
Method
Counter element Reporting RAD.ReportingInterval.Apn Gauge 32
interval
character
s
This measurement is incremented upon transmission of RADIUS Accounting Start
messages.
Number of Radius RAD.AcctStartMsgSent.Apn Counter 32
Accounting Start Messages
Sent
This measurement is incremented on receipt of a RADIUS Accounting Start response
message.
Number of Radius RAD.AcctStartResponseRcv Counter 32
Accounting Start d.Apn
Responses Received

Description
Method
This measurement is incremented on transmission of a RADIUS Accounting Interim
Update message.
Number of Radius RAD.AcctInterimMsgSent.A Counter 32
Accounting Interim Update pn
Messages Sent
This measurement is incremented on receipt of a RADIUS Accounting Interim Update
response message.
Number of Radius RAD.AcctInterimResponseR Counter 32
Accounting Interim Update cvd.Apn
Responses Received
This measurement is incremented upon transmission of RADIUS Accounting Stop
messages.
Number of Radius RAD.AcctStopMsgSent.Apn Counter 32
Accounting Stop Messages
Sent
This measurement is incremented on receipt of a RADIUS Accounting Stop response
message.
Number of Radius RAD.AcctStopResponseRcv Counter 32
Accounting Stop d.Apn
Responses Received
Spare counter RAD.spare1.Apn TBD 32
APN Data Plane Statistics

APN Data Plane Accounting Element group.

OA&M 9-85
Table 9-19
APN Data Plane Counters
Description
Method
the statistics collection period. This counter facilitates a more accurate
analysis of the statistics for a given accounting interval.
Counter element Reporting IP.ReportingInterval.A Gauge 32
interval pn
character
s
This measurement provides the number of downlink IP packets received per
APN and is incremented on receipt of a downlink IP packet.
IP Downlink Packets IP.IncDataPkt.Apn Counter 64
Received
This measurement provides the number of uplink IP packets sent and is
incremented on transmission of an uplink IP packet.
IP Uplink Packets Sent IP.OutDataPkt.Apn Counter 64
This measurement provides the number of downlink subscriber data plane IP
octets received and is incremented on receipt of a downlink IP packet.
IP Downlink Octets IP.IncDataOct.Apn Counter 64
Received
This measurement provides the number of uplink subscriber data plane IP
octets sent and is incremented on transmission of an uplink IP packet.
IP Uplink Octets Sent IP.OutDataOct.Apn Counter 64
Spare counter IP.spare1.Apn TBD 64
MPLS Statistics
MPLS Accounting Element group.

Table 9-20
MPLS Counters
Description
Method
Counter element Reporting MPLS.ReportingInterva Gauge 32
interval l
This is the VRF ID.
VRF ID MPLS.SpmVrfId Identifier 32
This measurement provides the number of MPLS octets received and is
incremented on receipt of an IP packet on a MPLS interface. The data packet
size is extracted from the packet header and added on to the measurement
value.
MPLS Octets Received MPLS.IncDataOct Counter 64
This measurement provides the number of MPLS octets sent and is incremented
on transmission of an IP packet on a MPLS interface. The data packet size is
extracted from the packet header and added on to the measurement value.
MPLS Octets Sent MPLS.OutDataOct Counter 64
This measurement provides the number of MPLS packets received and is
incremented on receipt of an IP packet on a MPLS interface.
MPLS Packets Received MPLS.IncDataPkt Counter 64
This measurement provides the number of MPLS packets sent and is
incremented on transmission of an IP packet on a MPLS interface.
MPLS Packets Sent MPLS.OutDataPkt Counter 64
Spare counter MPLS.spare1 TBD 64
VRF Statistics
VRF Accounting Element group.

OA&M 9-87
Table 9-21
VRF Counters
Description
Method
Counter element Reporting VRF.ReportingInterval Gauge 32
interval
This is the VRF ID.
VRF ID VRF.SpmVrfId Identifier 32
This measurement provides the total number of packets received by the VRF.
VRF Received Packets VRF.ReceivedPkts Counter 64
This measurement provides the total number of packets forwarded through the
VRF.
VRF Forwarded Packets VRF.ForwardedPkts Counter 64
This measurement provides the total number of packets destined for the VRF.
VRF Delivered Packets VRF.DeliveredPkts Counter 32
This measurement provides the total number of packets generated by the VRF.
VRF Originated Packets VRF.LocalOutPkts Counter 32
This measurement provides the total number of bad IP packets received by the
VRF. Packets are classified as bad if they have a bad checksum, the packet length
is too short, not enough data is contained within the packet, the IP header length
is bad, or the IP version is bad.
VRF Bad packets VRF.BadPkt Counter 32
This measurement provides the number of incoming VRF IP packets received
which cannot be forwarded due to various errors.
VRF Packets Not VRF.CantForward Counter 32
Forwarded.
This measurement provides the total number of dropped VRF IP packets. Packets
are dropped due to lack of memory, lack of buffer space, an interface is down, or
due to packet classification.
VRF Dropped Packets VRF.DropPkt Counter 32
This measurement provides the total number of VRF IP packets dropped by
indexed services. This counter is pegged only for VPN-only VRFs.
VRF Dropped Packets by VRF.DropIndxSvcPkt Counter 32
Indexed Services.
Spare counter VRF.spare1 TBD 32

Description
Method
DCC Statistics
Diameter Credit Control (DCC) Accounting Element group. Diameter
Policy Control is based on DCC. The DCC Accounting Element group
is also used for Diameter Policy Control. The statistics are collected on
a per Diameter server per Diameter profile per ISP basis. The
statistics are collected for the following types of servers:
• Diameter Credit Control (Gy)

• Diameter Policy Control (Gx)
• Combined Diameter Credit and Policy Control (Gx over Gy)
If a counter is not applicable to the particular server, the counter is 0.
Table 9-22
DCC Counters
Description
Method
Counter element Reporting DCC.ReportingInterval Gauge 32
interval
The name of the Diameter Profile.
Diameter Profile Name DCC.ProfileName Identifier 32
character
s
The IP Address of the Diameter server.
Server DCC.Server Identifier 32

OA&M 9-89
Description
Method
This counter shows the number of Initial Credit Control Requests (CCR) sent
from the GGSN to a Diameter server.
This counter is incremented once for each Credit Control Request message sent
where the CC-Request-Type AVP value is set to INITIAL_REQUEST. However,
the counter is only incremented when the request is sent for the first time. It is
not incremented for requests that are resent via an alternate peer.
This counter is applicable to Gy, Gx, and Gx over Gy.

Initial Credit Control DCC.AttInitialCCR Counter 32
Request Messages Sent
This counter shows the number of successful Initial Credit Control Answers
(CCA) received by the GGSN from a Diameter server. A successful Credit
Control Answer is a Credit Control Answer that contains a successful Result-
Code AVP (a value in the 2xxx range).
This counter is incremented as follows once for each successful Credit Control
Answer message received where the CC-Request-Type AVP value is set to
INITIAL_REQUEST.

Successful Initial Credit DCC.SuccInitialCCA Counter 32
Control Answer Messages
Received
This counter shows the number of Update Credit Control Requests (CCR) sent
from the GGSN to a Diameter server.
where the CC-Request-Type AVP value is set to UPDATE_REQUEST. However,
the counter is only incremented when the request is sent for the first time. It is
not incremented for requests that are resent via an alternate peer.

Update Credit Control DCC.AttUpdateCCR Counter 32
Request Messages Sent
This counter shows the number of successful Update Credit Control Answers
(CCA) received by the GGSN from a Diameter server. A successful Credit
Control Answer is a Credit Control Answer that contains a successful Result-
Code AVP (a value in the 2xxx range).
UPDATE_REQUEST.

Description
Method
Successful Update Credit DCC.SuccUpdateCCA Counter 32
Control Answer Messages
Received
This counter shows the number of Termination Credit Control Requests (CCR)
sent from the GGSN to a Diameter server.
where the CC-Request-Type AVP value is set to TERMINATION_REQUEST.
However, the counter is only incremented when the request is sent for the first
time. It is not incremented for requests that are resent via an alternate peer.

Termination Credit Control DCC.AttTerminationCC Counter 32
Request Messages Sent R
This counter shows the number of successful Termination Credit Control
Answers (CCA) received by the GGSN from a Diameter server. A successful
Credit Control Answer is a Credit Control Answer that contains a successful
Result-Code AVP (a value in the 2xxx range).
TERMINATION_REQUEST.

Successful Termination DCC.SuccTermination Counter 32
Credit Control Answer CCA
Messages Received
This counter shows the number of Redirect Credit Control Answer (CCA)
messages received by the GGSN from a Diameter server. A Redirect CCA
message is a CCA message where the Final-Unit-Action AVP has a value of
REDIRECT.
This counter is incremented once for each Redirect CCA received.
This counter is applicable to Gy and Gx over Gy.

Redirect Credit Control DCC.RedirectCCARcvd Counter 32
Answer Messages
Received
This counter shows the number of Re-Auth Request (RAR) messages received
by the GGSN from a Diameter server.
This counter is incremented once for each RAR received.

OA&M 9-91
Description
Method
Re-Auth Request Messages DCC.RARMsgsRcvd Counter 32
Received
This counter shows the number of new rate requests sent from the GGSN to a
Diameter server. An new rate request corresponds to a Rating-Group being
newly requested in an Update Credit Control Request message.
This counter is incremented once for each unique new Rating-Group in an

Update Credit Control Request message.

Number of Attempted New DCC.AttNewRateReq Counter 32
Rate Requests
This counter shows the number of successful new rate requests received by the
GGSN from a Diameter server. A new rate request is defined in the description
of DCC.AttNewRateReqs. A successful new rate request is an new rate request
that is approved by a Diameter server.
This counter is incremented once for each Rating-Group included in a

successful Update Credit Control Answer message whose Rating-Group was
included in a Multiple-Services-Credit-Control AVP in the corresponding
request, and whose Result-Code AVP value indicates a successful authorization
(in the 2xxx range).

Number of Successful New DCC.SuccNewRateReq Counter 32
Rate Requests
This counter shows the number of Reauthorizations sent from the GGSN to a
Diameter server. A Reauthorization is either a request to authorize additional
prepaid resources for a GTP context, or a request to authorize additional
prepaid resources for a specific prepaid quota of a GTP context.
This counter is incremented once for each Rating-Group included in a Update

Credit Control Request message where the Result-Code within the Multiple-
Services-Credit-Control AVP indicates Reauthorization.

Number of DCC.AttReauthReq Counter 32
Reauthorizations sent

Description
Method
This counter shows the number of successful Reauthorizations. A
Reauthorization is defined in the description of DCC.AttReauthReq. A
successful Reauthorization is a Reauthorization that is approved by a Diameter
server.
This counter is incremented once for each prepaid quota included in a

successful Update Credit Control Answer message that is also included in the
set of Rating-Groups being reauthorized (i.e. not returned and not newly
requested) in the corresponding Update Credit Control Request message, and
whose Result-Code AVP in the response message indicates successful
reauthorization (in the 2xxx range).
A successful Update Credit Control Answer response message is one such

message with a successful Service Result-Code AVP value (in the 2xxx range).

Successful Re- DCC.SuccReauthReq Counter 32
authorizations
This counter shows the number of quotas returned because of an Idle Timeout
expiry.

Returned quotas due to Idle DCC.QuotaReturn.Idle Counter 32
Timeout TimeOut
This counter shows the number of time-outs of the Request Timer.

Request Time-outs DCC.ReqTimerExpiry Counter 32

OA&M 9-93
Description
Method
This counter shows the number of Credit Control messages that the Diameter
server failed due to protocol errors. This counter is incremented when the
GGSN receives a response from the Diameter server with any of the following
Return-Code AVP values:
3001 - DIAMETER_COMMAND_UNSUPPORTED
3002 - DIAMETER_UNABLE_TO_DELIVER
3003 - DIAMETER_REALM_NOT_SERVED
3004 - DIAMETER_TOO_BUSY
3005 - DIAMETER_LOOP_DETECTED
3006 - DIAMETER_REDIRECT_INDICATION
3007 - DIAMETER_APPLICATION_UNSUPPORTED
3008 - DIAMETER_INVALID_HDR_BITS
3009 - DIAMETER_INVALID_AVP_BITS
3010 - DIAMETER_UNKNOWN_PEER (CER only)
4002 - DIAMETER_OUT_OF_SPACE
4003 - ELECTION_LOST
5001 - DIAMETER_AVP_UNSUPPORTED
5010 - DIAMETER_NO_COMMON_APPLICATION
5011 - DIAMETER_UNSUPPORTED_VERSION
5012 - DIAMETER_UNABLE_TO_COMPLY
5013 - DIAMETER_INVALID_BIT_IN_HEADER
5017 - DIAMETER_NO_COMMON_SECURITY
5004 - DIAMETER_INVALID_AVP_VALUE
5005 - DIAMETER_MISSING_AVP
5006 - DIAMETER_RESOURCES_EXCEEDED
5007 - DIAMETER_CONTRADICTING_AVPS
5008 - DIAMETER_AVP_NOT_ALLOWED
5009 - DIAMETER_AVP_OCCURS_TOO_MANY_TIMES
5013 - DIAMETER_INVALID_BIT_IN_HEADER
5014 - DIAMETER_INVALID_AVP_LENGTH
5015 - DIAMETER_INVALID_MESSAGE_LENGTH
5016 - DIAMETER_INVALID_AVP_BIT_COMBO
5140 - DIAMETER_ERROR_INITIAL_PARAMETERS
5141 - DIAMETER_ERROR_TRIGGER_EVENT

Failures due to protocol DCC.ProtocolErr Counter 32
errors

Description
Method
This counter shows the number of Credit Control Requests (Initial, Update, or
Final) denied by the Diameter server because of authentication failure.
A CCR denied because of authentication failure is a CCR that is denied by a

Diameter Server as indicated by a non-successful Result-Code AVP with the
value of 4001 - DIAMETER_AUTHENTCATION_REJECTED.
For all Diameter servers, once for each unsuccessful Initial Credit Control
Answer message received (irrespective of the set of Rating-Groups included in
the corresponding request);
For DCC and Gx over Gy servers, once for each Rating-Group that is denied in
an Update Credit Control Answer message that is included in the set of Rating-
Groups being either newly requested or reauthorized (but not returned) in the
corresponding request;
For Gx servers, once for each unsuccessful Update Credit Control Answer
message received;
For all Diameter servers, once for each unsuccessful Final Credit Control
Answer message received.
Request failures explicitly DCC.DeniedReq.Authe Counter 32
denied for Authentication ntication

OA&M 9-95
Description
Method
This counter shows the number of Credit Control Requests (Initial, Update, or
Final) denied by the Diameter server because of authorization failure.
A CCR denied because of authentication failure is a CCR that is denied by a

Diameter Server as indicated by a non-successful Result-Code AVP with the
value of 5003 - DIAMETER_AUTHORIZATION_REJECTED.
For all Diameter servers, once for each unsuccessful Initial Credit Control
Answer message received (irrespective of the set of Rating-Groups included in
the corresponding request);
For DCC and Gx over Gy servers, once for each unsuccessful Update Credit
Control Answer message for which the corresponding request message
included no Multiple-Services-Credit-Control AVP;
For DCC and Gx over Gy servers, once for each Rating-Group that is denied in
an Update Credit Control Answer message that is included in the set of Rating-
Groups being either newly requested or reauthorized (but not returned) in the
corresponding request;
For Gx servers, once for each unsuccessful Update Credit Control Answer
message received;
For all Diameter servers, once for each unsuccessful Final Credit Control
Answer message received.
Request failures explicitly DCC.DeniedReq.Autho Counter 32
denied for Authorization rization
This counter shows the number of Termination Credit Control Requests sent
with non-exceptional Termination-Reason AVP.
Specifically, the following values are applicable:
1 - DIAMETER_LOGOUT
2 - DIAMETER_SERVICE_NOT_PROVIDED

Normal Termination DCC.TerminationReas Counter 32
Requests on.Normal

Description
Method
with a Termination-Reason AVP value of:
3 - DIAMETER_BAD_ANSWER

Bad Answer Termination DCC.TerminationReas Counter 32
Requests on.BadAnswer
4- DIAMETER_ADMINISTRATIVE

Administrative Termination DCC.TerminationReas Counter 32
Requests on.Administrative
5- DIAMETER_LINK_BROKEN

Link Broken Termination DCC.TerminationReas Counter 32
Requests on.LinkBroken
6- DIAMETER_SESSION_TIMEOUT

Session Timeout DCC.TerminationReas Counter 32
Termination Requests on.SessionTimeout
This counter shows the number of context failures that were the result of either
Failure Handling set to “Terminate” or “RetryAndTerminate”.
This counter is not pegged for CCR Final.

Number of contexts DCC.FailureHandling.N Counter 32
terminated due to Failure brTerminated
Handling action

OA&M 9-97
Description
Method
This counter shows the number of context continued (converted to non-prepaid)
as a result of any failure and Failure Handling is set to “Continue”.
(i.e. Tr expiry, Transport failure)

Number of contexts DCC.FailureHandling.N Counter 32
continued (converted brContinue
postpaid) due to Failure
Handling action
This counter shows the number of times an Invalid Charging Rule Base was
sent by the Diameter server.
This counter is incremented once for each invalid Charging Rule Base received.
This counter is applicable to Gx and Gx over Gy.

Number of Invalid Charging DCC.InvalidChargingR Counter 32
Rule Bases Received uleBaseRcvd
This counter shows the number of times an Invalid Charging Rule was sent by
the Diameter server.
This counter is incremented once for each invalid Charging Rule received.
This counter is applicable to Gx and Gx over Gy.

Number of Invalid Charging DCC.InvalidChargingR Counter 32
Rules Received uleRcvd
Spare counter DCC.spare1 TBD 32
DHCP Statistics
Dynamic Host Configuration Protocol (DHCP) Accounting Element
group.

Table 9-23
DHCP Counters
Description
Method
Counter element Reporting DHCP.ReportingInterv Gauge 32
interval al
The IP address of the DHCP server.
DHCP Server DHCP.Server Identifier 32
Number of DHCP Discover messages sent by the GGSN to the DHCP server.
This counter is incremented when a DHCPDISCOVER message is transmitted/

retransmitted from GGSN to DHCP server.
DHCP Discover Sent DHCP.DiscoverSent Counter 32
Number of DHCP Request messages sent by the GGSN to the DHCP server.
This counter is incremented when a DHCPREQUEST message is transmitted/

retransmitted from GGSN to DHCP server.
DHCP Request Sent DHCP.RequestSent Counter 32
Number of DHCP Decline packets sent by the GGSN to the DHCP server.
This counter is incremented when a DHCPDECLINE message is transmitted from

GGSN to DHCP server.
DHCP Decline sent DHCP.DeclineSent Counter 32
Number of DHCP Release messages sent by the GGSN to the DHCP server.
This counter is incremented when a DHCPRELEASE message is transmitted

from GGSN to DHCP server.
DHCP Release Sent DHCP.ReleaseSent Counter 32
Number of DHCP Offer messages received by GGSN from DHCP server.
DHCP Offer Received DHCP.OfferReceived Counter 32
Number of DHCP Ack messages received by GGSN from DHCP server.
DHCP Ack received DHCP.AckReceived Counter 32
Number of DHCP Nak messages received by GGSN from DHCP server.
DHCP Nak Received DHCP.NakReceived Counter 32
Number of times DHCP messages cannot be sent to the DHCP server.
DHCP Message Send Error DHCP.SendErrors Counter 32

OA&M 9-99
Description
Method
Number of DHCP packets that were received from the DHCP server and dropped.
This counter is incremented
1) When the incoming DHCP packet is of invalid length.
2) Other internal Software errors.

DHCP Packets Dropped DHCP.PktsDropped Counter 32
Spare counter DHCP.spare1 TBD 32
Local Address Pool statistics

Local Address Pool Accounting Element group.
Table 9-24
Local Address Pool Counters
Description
Measurement Name 3GPP Name Collectio Size (bits)
n Method
Counter element Reporting AddrPool.ReportingInterval Gauge 32
interval
IP Address Pool name
Local Address Pool Name AddrPool.AddressPoolNam Identifier 33
e Character
s

Description
n Method
Access Group name
This identifier enables downstream processing to identify the access group

associated with the address pool. Downstream processing can collate the address
pool statistics on an access group basis.
Local Addr pool Access AddrPool.AccessGroupNam Identifier 33
group e Character
s
Total number of IP address configured in the address pool.
Total address in the pool AddrPool.TotAddrInPool Counter 32
Number of free IP addresses in the address pool.
Decremented when an IP address is allocated from the given Local Address pool.
Incremented when an IP address is deallocated for the given Local Address pool.
Free address in the Local AddrPool.FreeAddr Gauge 32
address pool
Number of IP Address which are in use in the address pool.
Incremented when an IP address is allocated from the given Local Address pool.
Decremented when an IP address is deallocated for the given Local Address pool.
Address in use in the local AddrPool.UsedAddr Gauge 32
address pool
The peak of the IP addresses usage during the last reporting interval.
If (MaxAddrUsed < UsedAddr)
- Incremented during IP Address allocation from the given Local Address Pool.
If (MaxAddrUsed >= UsedAddr)
Remains unchanged.
This counter is reset to the UsedAddr counter value at the start of the next
Maximum address used. AddrPool.MaxAddrUsed High 32
Tidemark
Gauge
Number of times an IP address is requested from the address pool.
Incremented when an IP address is requested from the given Local Address pool.

OA&M 9-101
Description
n Method
Total attempts to allocate AddrPool.AttAddrAllocation Counter 32
address s
Number of times an IP address is successfully allocated from the address pool.
Incremented when an IP address is allocated from the given Local Address pool.
Total successful attempts AddrPool.SuccAddrAllocati Counter 32
to allocate address. ons
Number of times an IP address is NOT successfully allocated from the address pool
because no address is available.
Incremented when an IP address cannot be allocated from the given Local Address
pool, due to unavailability of IP address.
Address allocation failures AddrPool.FailAddrAllocatio Counter 32
due to unavailability of ns.NoAddr
addresses
Number of times an IP address is released back to the address pool.
Incremented when an IP address is deallocated for the given Local Address pool.
Address released by GGSN AddrPool.TotalAddrFrees Counter 32
Number of addresses that are in Blackout.
Incremented when an IP address is placed in Blackout after being released.

Decremented when an IP address exits Blackout.
Addresses in Blackout AddrPool.Black- Gauge 32
outAddresses
Spare counter AddrPool.spare1 TBD 32
Content Filter Statistics

The following table describes the statistics collected for Content Filter
servers.

Table 9-25
Content Filter Service Statistics
Description
Measurement Name New 3GPP Name Collection Size (bits)
Method
Counter element Reporting CFS.ReportingInter Gauge 32
interval val
The name of the Content Filter Service (CFS) Profile.
CFS Profile Name CFS.ProfileName Identifier 32 characters
The IP address of the CFS server.
IP Address CFS.IpAddress Identifier 32
The port of the CFS server.
Port CFS.Port Identifier 16
The VPN name (if applicable) of the CFS server. If this server is not part of a VPN, this
value will be “NONE”, in which case the accounting element corresponds to the non-VPN
server entry on the ISP. Whether or not the VPN name field is “NONE” depends on
whether or not the Content Filter profile is associated with a VPN or not. Note that a
profile may be used both with a VPN and with the non-VPN domain, simultaneously, in
which case there will be distinct accounting elements reported.
VPN Name CFS.VpnName Identifier 32 characters
The number of Content Decision Requests sent to this server.
Content Decision Requests CFS.RequestsSent Counter 32
Sent
The number of Content Decisions that allow the request to pass through.
Pass through responses CFS.PassThrough Counter 32
received
The number of Content Decisions that redirect the request to another location.
Respond to subscriber CFS.RespToSub.Re Counter 32
redirection response direct
received
The number of Content Decisions that block the request.
Respond to subscriber CFS.RespToSub.Fo Counter 32
forbidden response rbidden
received
The number of Content Decisions where some protocol error occurs.
Protocol error in response CFS.ProtocolError Counter 32
The number of Content Decision Requests that do not receive a response within the
timeout period.
Request time outs CFS.Timeouts Counter 32

OA&M 9-103
Description
Measurement Name New 3GPP Name Collection Size (bits)
Method
Spare counter for future enhancement purposes. Initialized to 0 and not pegged.
Spare counter CFS.spare1 TBD 32
SCS Log Server

The historical statistics are retrieved from Nortel GGSN devices based
on the time interval provisioned against each accounting group. These
historical statistics are then stored on the SCS Log Server in the binary
format under the following directories. The ‘~’ is the pathname of
directory containing SCS installation tar file (i.e. $SCS_ROOT) which
is configurable at the installation time.
• Memory - “~/log/region<n>/device<n>/mem.acc”
• Session Mgmt - “~/log/region<n>/device<n>/isp<n>/sm.acc”
• GTP Data - “~/log/region<n>/device<n>/isp<n>/gtp.acc”
• GTP Accounting - “~/log/region<n>/device<n>/isp<n>/gtpp.acc”
• RADIUS - “~/log/region<n>/device<n>/isp<n>/rad.acc”
• APN - “~/log/region<n>/device<n>/isp<n>/apn.acc”
• CGF - “~/log/region<n>/device<n>/isp<n>/cgf.acc”
• L2TP - “~/log/region<n>/device<n>/isp<n>/l2tp.acc”
• L2IP - “~/log/region<n>/device<n>/isp<n>/l2ip.acc”
• IPSec - “~/log/region<n>/device<n>/isp<n>/ipsec.acc”
• Overload - “~/log/region<n>/device<n>/overload.acc”
• Wireless Services - “~/log/region<n>/device<n>/isp<n>/
wireless.acc”
• ISP-IP - “~/log/region<n>/device<n>/isp<n>/isp.acc”
• SCP - “~/log/region<n>/device<n>/isp<n>/scp.acc”

• GRE - “~/log/region<n>/device<n>/isp<n>/gre.acc”
• Ancillary APN - “~/log/region<n>/device<n>/isp<n>/
ancillary_apn.acc”
• APN Data - “~/log/region<n>/device<n>/isp<n>/apndata.acc”
• MPLS - “~/log/region<n>/device<n>/isp<n>/mpls.acc”
• VRF - “~/log/region<n>/device<n>/isp<n>/vrf.acc”
• DCC - “~/log/region<n>/device<n>/isp<n>/dcc.acc”
• DHCP - “~/log/region<n>/device<n>isp<n>/dhcp.acc”
• Local Address Pool - “~/log/region<n>/device<n>isp<n>/
localaddrpool.acc”
• VPRN - “~/log/region<n>/device<n>/isp<n>/vprn.acc”
• VPRN Link - “~/log/region<n>/device<n>/isp<n>/vprnlink.acc”
• CFS - “~/log/region<n>/device<n>/isp<n>/cfs.acc”
CSV File Creation and Removal
Figure 9-1
CSV File Generation on SCS Log Server
SCS Log Server

creates ACC file
per single accounting
element and CSV file
per region/device. ~/log/SCSLogTimeInterval.config
*.acc Single CSV file

files per region/device
At the end of the collection interval for accounting elements, the data
for that interval are stored in a holding container on the GGSN. Within
the next five minutes, each accounting element instance which has
been saved in a holding container is reported randomly to the SCS
Log Server. As each instance is received, the Log Server writes the
data received into the corresponding accounting element-specific ACC
file. At the same time, the Log Server also writes those same data
records into the CSV file corresponding to the region and device of the
statistics received. The ACC is a binary file and CSV is a comma
delimited ASCII file. The Log Server continuously starts an internal
timer based on the values it reads from the input file ‘~/log/

OA&M 9-105
SCSLogTimerInterval.config’. This timer determines when the active

CSV file is closed and made available for FTP from an external device.
The timer expiration time is lined up with the hour, and the default
value is 15 minutes. For more on the SCSLogTimerInterval.config file,
See “CSV Collection Timer Interval” for more information. SER Base
OM ACC files are not converted into CSV files on the SCS server.
To summarize, there are three different time intervals that are relevant
to CSV file creation:
• SSG Collection Period: This is the period of time during which

statistics for a particular accounting element are collected on the
GGSN, configured by setting the intervals in the Accounting Profile.
At the end of each collection period, the accumulated counts are
moved into a holding container and any new counts will be part of
the next collection period.
• SSG Reporting Period: This is the period of time during which the
statistics that have been accumulated on the GGSN are reported,
one instance at a time, to the SCS Log Server. The reporting period
is fixed at 5 minutes, which means that all accounting element data
for the collection period just ended are reported within 5 minutes
after the collection period ends, assuming that the link between the
GGSN and SCS Log Server is up.
• SCS CSV File Generation Period: The time period during which a
particular CSV file remain opens. At the end of this period, the file
is closed and becomes available for transfer. Any new records
coming into the SCS Log Server after the end of this period are
written to a new CSV file.
The figure below illustrates an example how these different time
periods correspond to each other. In this example, the SSG Collection
Period is set to 15 minutes and the SCS CSV File Generation Period is
set to 5 minutes. The arrows indicate the path of the data. So, it can be
seen that the data collected on the GGSN from 12:00 to 12:15 is
reported during the 5 minutes after that. At the same time, the data is
written to the CSV file. This example shows that the CSV file
containing the data that was collected from 12:00 to 12:15 is available
for transfer by 12:20. In this example, since the SSG Collection Period
is set to 15 minutes, in the normal case there will not be any CSV files
created between 12:05 and 12:15. However, setting the SCS CSV file
generation period to five minutes means that every five minutes, if a
CSV file is open and it will only be opened if statistics were reported
during the CSV file generation period, it will be closed.

Figure 9-2
CSV File Generation Time Periods
External
Device
SCS CSV
File Generation
Period
SSG
Reporting
Period
SSG
Collection
Period
12:00 12:05 12:10 12:15 12:20 12:25
CSV Record Format

Each record field value which is separated by the comma in the CSV
file aligns with the record format defined as the following.
• Record Version - This is the version number of data field format in

the record. It is an integer value.
• Record Type - The record type is in number form. This number
corresponds to the identifier value defined in Table 9-26.
• Record Flags - These flags indicate the status of the record. It is a
bit value field. The number is in the ACC file and the text is in the
CSV file. The following are the valid record flags. If none of these
bits are set then blank value is written to the CSV file.
— 1 = CLEARED
— 2 = CREATED
— 4 = DELETED
— 8 = MODIFIED
— 10 = ENABLED
— 80 = STATS_INVALID
— 4000 = OVERFLOW_DETECTED

OA&M 9-107
• Region ID - The number of the network region where the reporting

Nortel GGSN is provisioned. It is an integer value.
• Device ID - The number assigned to the reporting Nortel GGSN. It
is an integer value.
• Subscriber Instance - The instance number of the subscriber. It is
an integer value.
• Subscriber ID - The number assigned to the reporting subscriber. It
is an integer value.
• Customer ID - The number assigned to the customer. It is an
integer value.
• ISP ID - The number assigned to the reporting ISP. It is an integer
value.
• Start Time - The time when the historical statistics collection period
is started.
• Stop Time - The time when the historical statistics collection period
is stopped.
• Management IP Address - The management Ip Address of the
Nortel GGSN.
• Software Version - The software version of the Nortel GGSN.
• Hostname - The hostname of the Nortel GGSN.
• Accounting Element Name - The name corresponds the
accounting element group in Table 9-26.
• Various Counters - The remaining fields after the accounting
element name field are generated according to the statistic
counters defined for each accounting element group.
Table 9-26
Accounting Group Identifier Value
Accounting Group Record Type CSV Record Name
Memory 7 GGSN_Mem_Stat
s
Session Management 9 SM_Stats

GTP Data 11 GTP_Data_Stats
GTP Accounting 13 GTP_ACCT_Stats
RADIUS 17 RADIUS_ACCT_St
ats
APN 10 perAPN_Stats

Accounting Group Record Type CSV Record Name
CGF 12 per_CGF_Stats
L2TP 16 L2TP_Stats
L2IP 15 L2TP_IPSec_Stats
IPSec 14 IPSec_Stats
Overload 8 GGSN_Overload_
Stats
Wireless Services 18 Wireless_Service
s_Stats
ISP-IP 3 ISP_IP_Stats
SCP 21 SCP_Stats
GRE 20 GRE_Stats
Ancillary APN 19 perAPN_Ancillary

_Stats
APN Data Plane 22 perAPN_Data_Sta

ts
VRF 23 VRF_Stats
MPLS 29 MPLS_Stats
DCC 30 DCC_Stats
DHCP 32 DHCP_Stats
Local Address Pool 33 LocalAddrPool_St

ats
CFS 34 CFS_Stats
The following is an example of the contents of a Session Management

(i.e. SM_Stats) statistics record in the CSV file:
3, 9, , 1, 1, 1, 1, 2, 8, Tue Jan 01 23:45:14 CST 2002, Tue Jan 01

23:50:14 CST 2002, GGSNS3.2, 47.104.105.49, ssg55, SM_Stats, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
Device Based CSV File

Records from numerous accounting element instances of different
types will often cover the same clock interval. The device-based CSV
file should contain all such records from the SSG Collection Period just
ending. However, given the GGSN’s processing capacity, networks

OA&M 9-109
conditions between the GGSN’s to the SCS Log Servers, and the
processing capacity of the SCS Log Servers, it is possible that the
CSV file may not contain all the records from the previous SSG
Collection Period. A record may be processed into a later CSV file if
the factors listed above are severe enough to cause statistical record
processing at the SCS Log Server to overflow the CSV file generation
period. The timestamp data fields in the records should accurately
indicate the SSG Collection Period during which the data was
collected.
The SCS Log Server writes the CSV file in the specific directory
depending on the region and device. The device based CSV file is
located at:
“~/log/preside/region<x>/device<y>/
region<x>_device<y>_<timestamp>_<seq. #>.csv”
where ‘x’ and ‘y’ are the region and device numbers.
The timestamp (fixed 12 digits number) is when the file is generated by

the Log Server. The sequence number (fixed 3 digit number) is
incremented by the Log Server after every time interval where the
valid values are 000 to 999. The sequence number information is
maintained per device in the region#_device#_SCSLogSeqNum file in
the appropriate device directory. Also, when new data is written to the
CSV file, it is maintain in the temporary file
(region#_device#_<timestamp>_<seq.#>) until clock interval expires
at which time the file name will be appended with the .csv and the file
ownership will be changed.
The directory ‘~’ in this example is the SCS head directory where the
SCS Server software is installed.
The following is an example of the device based CSV pathname:
“~/log/preside/region1/device1/
region1_device1_200211272230_055.csv”
where 2002 is year (4 digits), 11 is month (2 digits -01 to 12), 27 is day

(2 digits - 01 to 31), 2230 is time (4 digits), and 055 is sequence
number (3 digits).
The following is an example of the contents of a device based CSV

file. Notice that records of each accounting element type are included:

Figure 9-3
An Example of Device Based CSV File
2, 7, , 1, 1, 1, 2, 2, 7, Tue Jan 01 04:48:31 CST 2003, Tue Jan 01 04:53:31 CST

2003, GGSNS4.0, 47.104.105.49, ssg55, GGSN_Mem_Stats, 61451280, 5
2003, GGSNS4.0, 47.104.105.49, ssg55, SM_Stats, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, GTP_Data_Stats, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, GTP_ACCT_Stats, 0, 0, 0, 0, 0, 0, 0
2, 17, 12, , 1, 1, 1, 2, 7, Tue Jan 01 18:28:57 CST 2003, Tue Jan 01 18:33:57 CST
2003, GGSNS4.0, 47.104.105.49, ssg55, RADIUS_ACCT_Stats, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, perAPN_Stats, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, perCGF_Stats, 0, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, L2TP_Stats, 0, 0, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, L2TP_IPSec_Stats, 0, 0, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, IPSec_Stats, 0, 0, 0, 0, 0, 0
3, 8, ENABLED, 1, 6, 1, 1, 2, 7, Tue Jan 01 09:20:38 CST 2003, Tue Jan 01
09:25:38 CST 2003, GGSNS4.0, 47.104.105.49, ssg55, GGSN_Overload_Stats, 192, 11, 2, 0,
0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0
2, 18, ENABLED, 1, 6, 1, 1, 0, 3, Tue Jan 01 09:20:38 CST 2003,
Tue Jan 01 09:25:38 CST 2003, GGSNS4.0, 47.104.105.49, ssg55, Wireless_Services_Stats,
10, 10, 0, 5, 5, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, ISP_IP_Stats, 44456, 44433, 44332, 1, 2, 2, 2, 2
2003, GGSNS4.0, 47.104.105.49, ssg55, SCP_Stats, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, GRE_Stats, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, MPLS_Stats, 0, 0, 0, 0
2003, GGSNS4.0, 47.104.105.49, ssg55, VRF_Stats, 0, 0, 0, 0, 0, 0, 0, 0

OA&M 9-111
CSV File Timestamp

In order to generate the correct timestamp in the CSV file, the time,
date and time zone need to be configured correctly on Nortel GGSN.
The way to check if proper time has been set is to use the CLI
commands - ‘show time’, ‘show timezone’ and ‘show tzdb’.
The timestamps in the CSV file are as per the Log Server time. For
example, if there is a GGSN in different time zone (e.g. Pacific time
zone or Eastern time zone) and the SCS Log server is in the Central
time zone, then all the records generated at 9:00 AM Central time (i.e.
7:00 AM pacific and 10:00 AM Eastern) have the same time string
“09:00:00 CST”.
CSV Collection Timer Interval

The Log Server uses SCSLogTimerInterval.config to set the times that
a CSV file is opened and closed. The file is located in the ~log/
directory. A user can modify this file and change the interval without
shutting down the Log Server. The Log Server will check this file entry
every “CSVFileInterval” time interval (or every 15 minutes if the
CSVFileInterval is 0).
Figure 9-4
Sample SCSLogTimerInterval.config file
#The valid values for Timer Interval is 0, 5, 15, 30, and 60 minutes.
#The value of 0 will stop generating *.csv files.
#Thu Mar 27 13:57:10 CST 2003
CSVFileInterval=5
The CSVFileInterval indicates the number of minutes a CSV file may

be open before it is closed. In other words, if the CSVFileInterval is set
to 5 minutes, then every 5 minutes, the Log Server will check if any
CSV files are open. If any are, they will be closed, and thus made
available for FTP by an OAM server. If user sets the value other than
0, 5, 15, 30, 60 then the Log Server will use the default value of 15
minutes. The default of 15 minutes is chosen because it corresponds
to a typical time period during which all of the accounting element
records are reported by the GGSN after the end of an accounting
element interval. The CSVFileInterval controls the delay in accounting
element data being available for FTP. If the user sets the value of 0
then CSV files will not be generated.
If the Accounting_time_Interval for a certain group is set to a value

less than the value of the Accounting_time_interval of other groups, it
is possible to see accounting information with time stamp that does not
belong to the time interval of the CSV file.

CSV Clean File Cron Job

The ‘SCSCronCleanLogcsv.txt’ is the cron job to delete the historical
statistics per-ISP statistic csv files on the SCS Log Server. Note that
these files are no longer generated. This utility is included only to
delete such files generated from a previous release. Here’s a sample
SCSCronCleancsv.txt file:
Figure 9-5
Sample SCSCronCleancsv.txt
#59 23 is 11:59pm
#SCSHead is /opt/SER
#days old is 7
#user id is pmuser
#This script wakes up every 24 hours to clean *.csv that are
59 23 * * * ksh -e '/opt/SER/bin/SCSCleanLogcsv.ksh 7 pmuser‘
# __ days old.
Follow these steps to run the cron job on the SCS Log Server:
• Make sure that SCSCronCleanLogcsv.txt contains a correct path to

SCSCleanLogcsv.ksh executable.
• Make sure that SCSCronCleanLogcsv.txt contains the time period
that the historical statistics CSV files need to be kept. A zero or
negative value causes SCSCleanLogcsv.ksh to exit.
• Make sure your SCSCronCleanLogcsv.txt has the desired User ID
set. The User ID is used to set the owner of the log file.
• Use the SCSLogcsv-enable command to add the
SCSCronCleanLogcsv.txt to the crontab.
Historical Statistics Monitoring
The historical statistics monitoring provides a real-time display of
selected Nortel GGSN statistics on the SCS GUI. A HistStats tab is
available on the device monitoring window for monitoring display. To
access this window from the SCS GUI, select Devices in the left
column of the main GUI window. Then in the Device Manager page,
select the region and device to be monitored. Click on the GGSN
device icon to view the drop-down menu and select Monitoring and
HistStats. This creates a tabbed device monitoring window with the
HistStats tab selected. Table 9-27 lists the accounting elements and
associated counters displayed via the real-time monitoring
functionality.
The View Privileges column indicates the view privileges needed for
the user profile to be able to monitor the accounting element. The real-
time monitoring doesn’t cover all counters in each accounting

OA&M 9-113
element. Only the counters with Gauge collection method are included
in the historical statistics monitoring.
Table 9-27
Real-time Statistics Monitoring
Accounting Viewing Privilege Monitoring Counters

Group
Memory Device, Gn ISP, Mem.totSystemMemUtil

Connection ISP
Mem.totSystemMemFree
Session Gn ISP SM.NbrActPdpCtxt

Managemen
t SM.NbrActBamCtxt
SM.NbrActIpsecCtxt
SM.NbrActL2tpCtxt
SM.NbrActL2ipCtxt
SM.NbrActRoamerCtxt
SM.NbrActGreCtxt
SM.NbrActPrepaidCtxt
SM.NbrActMPLSCtxt

Accounting Viewing Privilege Monitoring Counters

Group
APN Connection ISP SM.NbrActPdpCtxt.Apn
SM.MaxNbrActPdpCtxt.Apn
SM.NbrActPdpCtxt.Apn.Bgrd.Low
SM.NbrActPdpCtxt.Apn.Intact.Low
SM.NbrActPdpCtxt.Apn.Strm.Low
SM.NbrActPdpCtxt.Apn.Conv.Low
SM.NbrActPdpCtxt.Apn.Bgrd.Medium
SM.NbrActPdpCtxt.Apn.Intact.Medium
SM.NbrActPdpCtxt.Apn.Strm.Medium
SM.NbrActPdpCtxt.Apn.Conv.Medium
SM.NbrActPdpCtxt.Apn.Bgrd.High
SM.NbrActPdpCtxt.Apn.Intact.High
SM.NbrActPdpCtxt.Apn.Strm.High
SM.NbrActPdpCtxt.Apn.Conv.High
SM.NbrDynActPdpCtxt.Apn
SM.NbrStaticActPdpCtxt.Apn
L2TP Connection ISP L2TP.NbrTunnels
L2IP Connection ISP L2IP.NbrTunnels
The following figures illustrate the historical statistics monitoring pages

for different accounting element groups. The buttons in the page are
for the accounting element groups available to the operator baed on
the provisioned view privileges. Figure 9-6 is for an operator logged in
the Device Owner.

OA&M 9-115
Figure 9-6
Device Monitoring HistStats Page - Device View
Figure 9-7 is for an operator logged in to a connection ISP with ISP

privileges.

Figure 9-7
Device Monitoring HistStats Page - Connection ISP view
Figure 9-8, is for an operator logged in to Gn ISP with ISP privileges.

Notice the addition of the Session Management group.

OA&M 9-117
Figure 9-8
Device Monitoring HistStats Page - Gn ISP view
Selecting an accounting element button pops up a window for the

accounting element. See Figure 9-9 for an example of what the APN

accounting element looks like on the accounting element monitoring

window.
Figure 9-9
Monitoring Window example - APN
The polling interval at the bottom of the screen sets the interval for
retrieving the counters values from 5 - 300 seconds and the default is
30 seconds. Notice the LastPollTime column indicates the same time
differences as the set polling interval.
The display in the middle of the window is updated at each time

interval with a new line added listing the set of counter values if the
Multi-Row Display checkbox is checked. Otherwise, there is only one
line in the list, which is updated at each time interval. The APN name
selection field is at the top of the window. The APN name must be
selected before the start button is available to start monitoring.
The data retrieved by the SCS Monitoring is transmitted directly from

the selected Nortel GGSN device. It is displayed as shown on the
screen. The data is not stored to any file. Once the window is closed,
all retrieved data is cleared from memory.

OA&M 9-119
Since this data is retrieved directly from the GGSN device at

potentially very short intervals (i.e. starting at 1 second) the processing
and memory available on the GGSN to service connections may be
adversely affected.
SER Base OMs

The following OM groups are inherited from the SER base and are
relevant to the GGSN functionality on Nortel GGSN.
• Device OMs
• Trunk OMs
• VPRN OMs
• VPRN Link OMs
When using SCSLogCat utility to view the SER Base OM ACC files on
the SCS Log Server, the start time and the stop time are the same and
it is the OM collection timestamp.
Device OMs
The device OMs are summarized in Table 9-28.
Table 9-28
SER Base Device OMs
Measurement Name Description Size

(bits)
CMC_BUSY_SINCE_BOOT Percentage of the CMC that is 8

busy since boot time.
CMC_BUSY_DELTA Percentage of the CMC that is 8
busy since the last time slice.
This value is generated
internal to ISOS without any
relation to the configuration of
interval in the SCS GUI.
SSP_NONHIFN_BUSY_SINCE_BOOT Average percentage across all 8

SSPs in the box that are busy
since boot time.
SSP_NONHIFN_BUSY_DELTA Average percentage that 8

across all SSPs that are busy
since the last time slice. This
value is generated internal to
ISOS without any relation to
the configuration of interval in
the SCS GUI.


(bits)
SSP_HIFN_BUSY_SINCE_BOOT Percentage of the SSP-HiFn 8

(encrypted SSP) that is busy
since boot time.
SSP_HIFN_BUSY_DELTA Percentage of the SSP-HiFn 8

(encrypted SSP) that is busy
since last time slice. This value
is generated internal to ISOS
without any relation to the
configuration of interval in the
GUI.
SSP_DRIVER_PKTS_RCVD Total number of packets 64

received by the SPP Driver.
CMC_DRIVER_PKTS_RCVD Total number of packets 64

received by the CMC Driver.
SSP_DRIVER_BAD_PKTS_RCVD Total number of bad packets 32

received by the SPP driver.
CMC_DRIVER_BAD_PKTS_RCVD Total number of bad packets 32

received by the CMC driver.
SSP_PKTS_DRIVER_DROPPED Total number of packets 32

dropped by the SSP driver.
CMC_PKTS_DRIVER_DROPPED Total number of packets 32

dropped by the CMC driver.
SSP_PKTS_CHIP_DROPPED Total number of packets 32

dropped by the SSP chip.
CMC_PKTS_CHIP_DROPPED Total number of packets 32

dropped by the CMC chip.
ENCRYP_PKTS_PROCESSED Total number of encrypted 64

packets processed within a
single device.
ENCRYP_PKTS_DROPPED Total number of encrypted 32

packets dropped within a
single device.
Trunk OMs
The trunk OMs are summarized in Table 9-29.

OA&M 9-121
Table 9-29
SER Base Trunk OMs

(bits)
SPM_TRUNKID Trunk Identification number 32
IFI_IPACKETS Number of packets destined for 64

the Trunk (into the trunk).
IFI_OPACKETS Number of packets generated 64

by the trunk (out of the trunk).
IFI_IBYTES Number of bytes destined for 64

the trunk.
IFI_OBYTES Number of bytes generated by 64

the trunk.
IFI_IQDROPS Input queues overflow and 32

drop packets.
IFI_OQDROPS Output queues overflow and 32

drop packets.
PKTS_DROP_ERR Packets drop due to various 32

errors
MULTICAST_IN_PKTS Number of multicast packets 64

destined for the trunk.
MULTICAST_OUT_PKTS Number of multicast packets 64

generated for the trunk.
VPRN OMs
The VPRN OMs are summarized in Table 9-30.
Table 9-30
SER Base VPRN OMs

(bits)
SPM_VPRNID The VPRN identification 32

number.
IPS_TOTAL Total number of packets 64

received by the VPRN.
IPS_FORWARD Total number of packets 64

forwarded through the box per
VPRN.


(bits)
IPS_DELIVERED Total number of packets 32

destined to the VPRN (into the
VPRN).
IPS_LOCALOUT Total number of packets 32

generated by the VPRN (out of
the VPRN).
PKTS_BAD Number of bad packets due to 32

errors.
IPS_CANTFORWARD Number of packets the VPRN 32

cannot forward due to various
errors.
PKTS_DROPPED Number of packets dropped 32

due to various errors.
PKTS_SVCS_DROPPED Number of packets per service 32

dropped per VPRN due to
various errors.
VPRN Link OMs

The VPRN Link OMs are summarized in Table 98, “SER Base VPRN
Link OMs,” on page 433.
Table 9-31
SER Base VPRN Link OMs

(bits)
SPM_VPRNID The VPRN identification 32

number.
REMOTE_IPADDR The IP address of the remote 32
node.
IFI_IPACKETS Number of packets destined for 64

the link (into the link).
IFI_OPACKETS Number of packets generated 64

by the link (out of the link).
IFI_IBYTES Number of bytes destined for 64

the link.
IFI_OBYTES Number of bytes generated by 64

the link.

OA&M 9-123

(bits)
IFI_IQDROPS Input queues overflow and 32

drop packets.
IFI_OQDROPS Output queues overflow and 32

drop packets.
PKTS_DROP_ERR Packets drop due to various 32

error.s
OM Monitoring
OM monitoring can be triggered and viewed by clicking on any tab on
Device Manager Monitoring page. The OM for that tab can be
monitored and saved to a disk file. The OM log file is located in “~/log/
Monitor_log/Device#” directory. The OM monitoring is on a per device
basis, the OM belongs to one group on a device is stored in one file.
All these OM files are in binary format, they can be viewed via
SCSLogCat utility.
The following is a list of example OM files with their locations, the

directory ‘~’ is the SCS head directory where the SCS Server software
is installed:
• ISP OM: “~/log/Monitor_log/device<n>/Isp/isp<n>/IspStats.log”

• SSC OM: “~/log/Monitor_log/device<n>/Card<n>/Slot<n>/
SscStats.log”
• ALC OM: “~/log/Monitor_log/device<n>/Card<n>/Slot<n>/
AlcStats.log”
• SFC OM: “~/log/Monitor_log/device<n>/Card<n>/Slot<n>/
SfcStats.log”
• CMC OM: “~/log/Monitor_log/device<n>/Card<n>/Slot<n>/
CmcStats.log”
• SSM OM: “~/log/Monitor_log/device<n>/Card<n>/Slot<n>/ssm<n>/
SsmStats.log”
• Port OM: “~/log/Monitor_log/device<n>/Card<n>/Slot<n>/port<n>/
PortStats.log”
• Ethernet port OM: “~/log/Monitor_log/device<n>/Card<n>/Slot<n>/
port<n>/EtherPortStats.log”
• Address pool OM: “~/log/Monitor_log/device<n/AddrPoolStats.log”
• Alarm panel: “~/log/Monitor_log/device<n>/AlarmPanel.log”
• ASM query: “~/log/Monitor_log/device<n>/AsmQuery.log”

• Connection OM: “~/log/Monitor_log/device<n>/

ConnectionStats.log”
• DHCP OM: “~/log/Monitor_log/device<n>/DhcpStats.log”
• Interface OM: “~/log/Monitor_log/device<n>/InterfaceStats.log”
• L2TP tunnel summary: “~/log/Monitor_log/device<n>/
L2tpTunlistSumm.log”
• OSPF interface OM: “~/log/Monitor_log/device<n>/OspfIfStats.log”
• OSPF number OM: “~/log/Monitor_log/device<n>/
OspfNbrStats.log”
• OSPF neighbor OM: “~/log/Monitor_log/device<n>/
OspfNeighborStats.log”
• RADIUS OM: “~/log/Monitor_log/device<n>/RadiusStats.log”
• Routing table summary: “~/log/Monitor_log/device<n>/
RouteTblSumm.log”
• SSG OM: “~/log/Monitor_log/device<n>/SsgStats.log”
• Subscriber summary: “~/log/Monitor_log/device<n>/SubSumm.log”
• VPRN OM: “~/log/Monitor_log/device<n>/VprnStats.log”
SER Base CLI statistics
On top of the SER Base OMs, there are CLI statistics displayed using
CLI command “show stats” for the following protocols to provide a
better understanding on the capacity and performance of Nortel
GGSN:
• Multicast
• ARP
• IP
• ICMP
• IPSec
• TCP
• UDP
• IGMP
• GRE
Please refer to GGSN CLI Reference Guide (411-5221-922) for the
detailed information of CLI statistics on the Nortel GGSN node. The
CLI statistics are different from the historical statistics and other OMs
in that these CLI statistics only exist when the protocols or tunnels are

OA&M 9-125
active. IPSec and GRE statistics are persistent for the life of the
associated ISP.
Alarms 9
The Nortel GGSN contains a SNMP Agent which is used for SNMP
trap management. The SNMP Agent notifies SNMP Managers of
many different types of traps utilizing different trap MIB objects. The
SNMP traps are sent from SNMP Agent to the managers for trap
notification purpose.
Additionally, the Nortel GGSN contains an event log reporting service.

Please refer to “Event Logs”. Event logs can be used to record the
occurrence of many events, some of which generate SNMP traps. In
fact many event logs on the Nortel GGSN generate SNMP traps to
convey information to the operators. It can be an alarm SNMP trap or
a non-alarm SNMP trap. An alarm SNMP trap has a state while a non-
alarm SNMP trap does not. There are two state for an alarm, Alarm
Occur and Alarm Clear. The alarm SNMP trap is called SNMP Alarm
and the non-alarm SNMP trap is called SNMP Event.
The SNMP traps support the severities INFORMATION, MINOR,

MAJOR, CRITICAL. An alarm trap must have a severity and a state
attributes. It may also have additional attributes. An alarm trap is said
to be raised when its state attribute is set to Alarm Occur. An alarm
trap is said to be cleared when its state attribute is set to Alarm Clear
and the severity attribute and any other attributes have the same
values when the alarm has been raised.
The SNMP Agent generates different types of traps and the following
SNMP traps are relevant to the Nortel GGSN:
• AAA Manager Address Pool Category SNMP Alarms

• GTP SNMP Alarms
• GTP SNMP Events
• GTP Accounting SNMP Alarms
• GTP Accounting SNMP Events
• RADIUS Accounting SNMP Alarms
• RADIUS Accounting SNMP Events
• Prepaid Service SNMP Alarms
• WAP Service SNMP Alarms
• Lawful Interception SNMP Alarms
• ISP Manager SNMP Alarms

• ISP Manager SNMP Events

• Overload SNMP Alarms
• Chassis SNMP Alarms
• System SNMP Alarms
• Card SNMP Alarms
• ATM Port SNMP Alarms
• SSM SNMP Alarms
• Ethernet Port SNMP Alarms
• Diameter Credit Control (DCC) SNMP Alarms
• IKE SNMP Events
• IPSEC SNMP Events
• Content Filter Service (CFS) SNMP Alarms
A four-tier system is being used for indicating the levels of criticality via
ALARMS icon on the SCS GUI. The definition are as follows:
• CRITICAL - Indicate a service affecting condition or a non-

recoverable error which requires immediate corrective action,
possibly a system reboot.
• MAJOR - Designate a recoverable error which requires operator
intervention.
• MINOR - It signifies a recoverable error.
• INFORMATION - Convey the information and it is event driven.
SNMP Traps
This section illustrates SNMP Agent interactions and describes the
SNMP traps. The SNMP Agent notifies SNMP Managers (including
the SCS Server and other managers) using traps defined in the “MIB
SSG-5000-CHASSIS-MIB”. The SCS Server is an SNMP Manager,
meaning it has software to receive and interpret the SNMP traps. The
traps are used to create the SCS alarm list, which can be displayed on
the SCS client via the ALARMS icon.
The SNMP Agent on the Nortel GGSN sends all SNMP traps to the
SCS Server. It can also be configured to forward traps directly to other
SNMP Managers.
The Nortel GGSN generates alarms which originate from the event
manager.

OA&M 9-127
Figure 9-10
Nortel GGSN SNMP Alarm System
Nortel GGSN
ps
P Tra
M
SN
SCS Server
Event SNMP
Manager Agent SNM
P Tr
aps
Other SNMP
Managers
A replay facility for the SNMP traps is now supported. The GGSN
maintains a list of all the recent traps associated with the alarms for the
all entities that are not included in the MIB. When requested, it can
replay the traps in the order they were originally sent, effectively
repopulating the Fault management system with the current alarm list.
The trigger to send the trap list is a CLI command on the GGSN. 100
recently generated traps are saved. The replay facility of the SNMP
traps may contain duplicate traps.
GGSN SNMP Traps

The detailed information on the GGSN specific SNMP traps are
described in the subsections below.

AAA Manager Address Pool Category SNMP Alarms
Table 9-32
GGSN AAAmgr Address Pool Category Alarms
GGSN Trap Severity Alarm Alarm Description Transfer Transfer to

Function State to SCS SNMP
Manager
based on
Configuration
AAAmgr MINOR alarmOccu The local address YES YES

r pool category
“Reserved “pools has
reached the pre
configured depletion
value level
MINOR alarmOccu The local address YES YES

r pool category
“Unreserved “pools
has reached the pre
value level
INFORMATION alarmOccu The local address YES YES

r pool category
“Reserved “pools has
dropped to the pre
value level to clear
above alarm
INFORMATION alarmOccu The local address YES YES

r pool category
“Unreserved “pools
has dropped to the
pre configured
depletion value level
to clear above alarm
Table 9-33
New MIB Notification Object Name
MIB Variable Values

ssg5000TrapAddressPoolAlar reservedThresholdReached(2),
mId
unreservedThresholdReached(3),

OA&M 9-129
MIB Variable Values
ssg5000TrapAddressPoolName string
ssg5000TrapIspName string
ssg5000TrapThresholdLevel integer32 (0..100)
ssg5000TrapTotalAddr integer32
ssg5000TrapTotalAddrUsed integer32
ssg5000TrapOccurClearTag alarmOccur(1),
alarmClear(2)
ssg5000TrapSSGHostAddress The IP address of the Nortel GGSN
ssg5000TrapSeverity critical(1),
major(2),
minor(4),
info(8)
The OID for the Address Pool Alarm Notification object is:
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).S
ERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPr
efix(2).ssgMIBNotification(0).ssg5000HAddressPoolAlarmNotification(
14)

GTP SNMP Alarms

They are sent using the MIB object ssg5000GTPAlarmNotification
described in Table 9-35.
Table 9-34
GGSN GTP Alarms
GGSN Trap Severity Alarm Alarm Description Transfer Transfer to

Function State to SCS SNMP
Manager
based on
Configuration
GTP INFORMATIO alarmOccu An APN is YES YES

Tunnel N r administratively
Disabled for the
GGSN (will not
accept new context
creation).
INFORMATIO alarmClear An APN that was YES YES

N Disabled is now
Enabled.
INFORMATIO alarmOccu GTP Tunnel creation YES YES

N r has been disabled
for the GGSN.
INFORMATIO alarmClear GTP Tunnel creation YES YES

N was Disabled, now
Enabled
MINOR alarmOccu Configured session YES YES

r limit has been
exceeded for the
APN & ISP specified.
MINOR alarmClear The number of active YES YES

sessions using the
APN & ISP specified
has dropped below
the configured limit
for that APN.
MAJOR alarmOccu APN <apn-name> on YES YES

r ISP <isp-name> has
been blacklisted.
MAJOR alarmClear APN <apn-name> on YES YES

ISP <isp-name> has
been blacklisted.

OA&M 9-131
Table 9-35
SNMP GGSN GTP ALARM MIB Notification Object
MIB Variable Values

ssg5000GTPAlarmId gtpCtxtCreateDisabled(1)
gtpApnDisabled(2)
gtpApnSessionLmtReached(3)
gtpApnBlacklisted(4)
ssg5000TrapAPNName A trap variable object for

providing the APN Name
ssg5000TrapIspName A trap variable object for

providing the ISP name
alarmClear(2)
ssg5000TrapSSGHostAddress The IP address of the Nortel
GGSN
major(2),
minor(4),
info(8)
Below is an OID for the SNMP GTP alarm notification object:
efix(2).ssgMIBNotification(0).ssg5000GTPAlarmNotification(56)
GTP SNMP Events

The GGSN GTP Events are listed in Table 9-36. They are sent using
the MIB object ssg5000GTPEventNotification described in Table 9-37.

Table 9-36
GGSN GTP Events
GGSN Trap Severity SCS Client Event Event Transfer Transfer

Function Text Description to SCS to SNMP
Manager
based on
Configurat
ion
GTP MINOR WARNING: Create PDP YES YES
Tunnel Access Control Context Request
Profile rejection rejected IMSI
for MSISDN (MCC/MNC) not
<msisdn> IMSI matching
<imsi> on APN Access Control
<apn> on ISP Profile entries
<isp> Operation for the APN
<Access Control requested
Profile
Rejection>
INFORMATION Access Control The Access YES YES
Profile <profile> Control Profile
is associated is associated
with APN <apn> with the APN
on ISP <isp>
INFORMATION Access Control The Access YES YES

Profile <profile> Control Profile
is dissociated is disassociated
with APN <apn> with the APN
on ISP <isp>
Table 9-37
SNMP GGSN GTP EVENT MIB Notification Object
MIB Variable Values

ssg5000GtpEventId gtpGgsnAclRej(1)
gtpGgsnAclApnAssoc(2)
gtpGgsnAclApnDisassoc(3)
ssg5000TrapAPNName A trap variable object for

providing the APN Name


OA&M 9-133
MIB Variable Values
ssg5000TrapMsisdnName A trap variable object for

providing the MSISDN Name
ssg5000TrapProfileName A trap variable object for

providing the Profile Name
ssg5000EventDesrc A trap object for describing a GTP
Event

GGSN
major(2),
minor(4),
info(8)
Below is an OID for the SNMP GTP event notification object:
efix(2).ssgMIBNotification(0).ssg5000GTPEventNotification(57)
GTP Accounting SNMP Alarms

The GGSN GTP Accounting alarms are listed in Table 9-38. They are
sent using the MIB object ssg5000GTPAcctAlarmNotification

Table 9-38
GGSN GTP Accounting Alarms
GGSN Trap Alarm State Alarm Transfer Transfer to

Function Severity Description to SCS SNMP Manager
based on
Configuration
GTP CRITICAL alarmOccu CGFs YES YES
Accountin r configured on
g the Gn ISP
are not
responding.
CRITICAL alarmClear CGF YES YES

configured on
the Gn ISP
are
responding.
MINOR alarmOccu CGF Failed YES YES

r for the
specified
CGF server
and ISP.
MINOR alarmClear CGF restored YES YES

for the
specified
CGF server
and ISP.
MINOR alarmOccu One FTP YES YES

r server used
for GTPP
audit is down.
MINOR alarmClear An FTP YES YES

server used
for GTPP
audit is
reachable.
CRITICAL alarmOccu All FTP YES YES

r servers used
for GTPP
Audit are
down.
CRITICAL alarmClear An FTP YES YES
Server used
for GTPP
Audit is up.

OA&M 9-135
Table 9-39
SNMP GGSN GTP Accounting ALARM MIB Notification Object
MIB Variable Values

ssg5000GTPAcctAlarmId gtpAcctCGFFailed1)
gtpAcctNoCgfAvailable(2)
gtpAcctFtpServerDown(3)
gtpAcctFtpAllServersDown(4)
ssg5000TrapIspName A trap variable object for providing

the ISP Name
ssg5000TrapServerName A trap variable object for providing

the Server name
ssg5000TrapCGFName A trap variable object for providing

the CGF address
alarmClear(2)
major(2),
minor(4),
info(8)
Below is an OID for the SNMP GTP Accounting alarm notification

object:
efix(2).ssgMIBNotification(0).ssg5000GTPAcctAlarmNotification(58)
GTP Accounting SNMP Events

The GGSN GTP Accounting Events are listed in Table 9-40. They are
sent using two different MIB objects ssg5000GTPAcctEventNotification
described in Table 9-41 and ssg5000EventNotification described in
Table 9-42.

Table 9-40
GGSN GTP Accounting Events
GGSN Trap Severity SCS Client Event Event Transfer Transfer

Function Text Description to SCS to SNMP
Manager
based
on
Configur
ation
GTP INFORMATION CGF <cgfname> Switch of YES YES

Accountin on ISP ispName activity
g SWACTED occurred for
primary and
secondary
CGFs.
Table 9-41
SNMP GGSN GTP EVENT MIB Notification Object
MIB Variable Values
ssg5000GtpAcctEventId gtpAcctCgfSwact(1)

ssg5000TrapCGFName A trap variable object for
providing the CGF address

Acct Event

GGSN
major(2),
minor(4),
info(8)
Below is an OID for the SNMP GTP Account event notification object:
efix(2).ssgMIBNotification(0).ssg5000GTPAcctEventNotification(59)

OA&M 9-137
Table 9-42
SNMP Generic Event MIB Notification Object
MIB Variable Values

ssg5000EventId 16
ssg5000EventCategory 76

Acct Event
GGSN
major(2),
minor(4),
info(8)
Below is an OID for the SNMP generic event notification object:
efix(2).ssgMIBNotification(0).ssg5000EventNotification(24)
Prepaid Service SNMP Alarms

The GGSN Prepaid Service alarms are listed in Table 9-43. They are
sent using the MIB object ssg5000SCPAlarmNotification described in
Table 9-44.

Table 9-43
GGSN Prepaid Service Alarms
GGSN Trap Alarm State Alarm Transfer Transfer to

Function Severity Description to SCS SNMP Manager
based on
Configuration
Prepaid CRITICAL alarmOccur SCP YES YES

Service server(s)
configured in
the Tariff
Profile on
ISP is not
reachable.
CRITICAL alarmClear SCP YES YES
server(s) is
reachable.
Table 9-44
SNMP GGSN Prepaid Service Alarm MIB Notification Object
MIB Variable Values
ssg5000SCPAlarmId noScpAvailable(1)

the ISP Name
ssg5000TrapProfileName A trap variable object for providing

the Profile name
alarmClear(2)
major(2),
minor(4),
info(8)
Below is an OID for the SNMP SCP Alarm Notification object:
efix(2).ssgMIBNotification(0).ssg5000SCPAlarmNotification(60)

OA&M 9-139
WAP SNMP Alarms

The GGSN WAP alarms are listed in Table 9-45. They are sent using
the MIB object ssg5000WrapAlarmNotification described in Table 9-
46.
Table 9-45
GGSN WAP Alarms
GGSN Trap Alarm Alarm Transfer Transfer

Function Severity State Description to SCS to SNMP
Manager
based
on
Configur
ation
WAP CRITICAL alarmOccu Application YES YES
Service r server is not
responding to
Accounting
START/INTERIM
UPDATE/STOP
requests and
the total of
these
unacknowledge
d requests has
hit the threshold
provisioned in
the
corresponding
application
server profile.
CRITICAL alarmClear Application YES YES

server
responding
again.
CRITICAL alarmOccu Application YES YES

r server does not
respond to
Accounting ON/
OFF requests.
CRITICAL alarmClear Application YES YES
server
responding to
accounting
requests.

Table 9-46
SNMP GGSN WAP Alarm MIB Notification Object
MIB Variable Values

ssg5000WrapAlarmId wrlsAppServerFailResponse(1)
wrlsAppServerUnactivated(2)

the ISP Name
ssg5000TrapServerName A trap variable object for providing

the Server name
alarmClear(2)
major(2),
minor(4),
info(8)
Below is an OID for the SNMP WAP Alarm Notification object:
efix(2).ssgMIBNotification(0).ssg5000WrapAlarmNotification(61)
ISP Manager SNMP Alarms

The GGSN ISP Manager alarms are listed in Table 9-47. They are
sent using the MIB object ssg5000ISPAlarmNotification described in
Table 9-48.

OA&M 9-141
Table 9-47
GGSN ISP Manager Alarms
GGSN Trap Alarm State Alarm Transfer Transfer

Function Severity Description to SCS to SNMP
Manager
based
on
Configur
ation
ISP CRITICA alarmOccur ISP operational YES YES

Manager L state is down.
No traffic can
be sent from
Gn->Gi for this
ISP
CRITICA alarmClear ISP operational YES YES

L state was
Down, is now
UP.
Table 9-48
SNMP GGSN ISP Manager Alarm MIB Notification Object
MIB Variable Values
ssg5000ISPAlarmId ispOperStateDown(1)

the ISP Name
alarmClear(2)
major(2),
minor(4),
info(8)
Below is an OID for the SNMP ISP Alarm Notification object:

efix(2).ssgMIBNotification(0).ssg5000ISPAlarmNotification(62)
ISP Manager SNMP Events

The GGSN ISP Manager Events are listed in Table 9-49. They are
sent using the MIB object ssg5000ISPEventNotification described in
Table 9-50.
Table 9-49
GGSN ISP Manager Events
GGSN Trap SCS Client Event Event Transfer Transfer

Function Severity Text Description to SCS to SNMP
Manager
based
on
Configur
ation
ISP CRITICA Add ISP ispName Attempt to add YES YES

Manager L failed an ISP failed;
ISP was not
created.
MINOR Address Pool An address YES YES

pool_name pool activation
activation failed for failed alarm is
isp ispName generated
(err_str) when routing
code fails to
add summary
route to the
pool. This is
very unlikely
scenario.
Table 9-50
SNMP GGSN ISP Manager Event MIB Notification Object
MIB Variable Values
ssg5000ISPEventId ispAddFailed(1)
ispAddrPoolActivationFailed(2)
the ISP Name

OA&M 9-143
MIB Variable Values
ssg5000EventDescr A trap object for describing a ISP

Event

major(2),
minor(4),
info(8)
Below is an OID for the SNMP ISP Event Notification object:
efix(2).ssgMIBNotification(0).ssg5000ISPEventNotification(63)
RADIUS Accounting SNMP Alarms

The GGSN RADIUS Accounting alarms are listed in . They are sent
using the MIB object ssg5000AAAAlarmNotification described in Table
9-52.

Table 9-51
GGSN RADIUS Accounting Alarms
GGSN Function Trap Alarm Alarm Description Transfer Transfer to

Severity State to SCS SNMP Man-
ager based
On Configu-
ration
RADIUS Accounting CRITICAL alarm- Error occurred YES YES

Occur when writing
RADIUS account-
ing record to disk.
Only one alarm of
this type is gener-
ated in a hour
interval and a
throttle timer of
one hour duration
is started.
CRITICAL alarm- Disk error resolved YES YES

Clear for RADIUS. The
alarm is cleared if
the problem no
longer persists and
the throttle timer
started when alarm
was raised has
expired.
MAJOR alarm- Could not contact YES YES

Occur any RADIUS server
for the specified
RADIUS profile.
Writing to Disk.

OA&M 9-145
MAJOR alarm- Able to contact a YES YES

Clear RADIUS server for
the specified
RADIUS profile.
Writing to Disk
alarm is cleared.
MAJOR alarm- Could not contact YES YES

Occur any RADIUS
Authentication
server for the spec-
ified RADIUS pro-
file. An alarm is
generated after 3
consecutive ses-
sion attempt failure
for a particular
SSP.
Table 9-52
SNMP GGSN RADIUS Accounting Alarm MIB Notification Object
MIB Variable Values
ssg5000AAAAlarmId aaaDiskWriteError(1),
aaaWritingToDisk(2),
aaaAuthServerUnreachable(3)

the ISP Name
ssg5000TrapProfileName A trap variable object for providing

the Profile name
alarmClear(2)

MIB Variable Values
major(2),
minor(4),
info(8)
Below is an OID for the SNMP RADIUS Notification object:
efix(2).ssgMIBNotification(0).ssg5000AAAAlarmNotification(64)
RADIUS Accounting SNMP Events

The GGSN RADIUS Accounting events are listed in Table 9-53. They
are sent using the MIB object ssg5000GGSNAAAEventNotification
Table 9-53
GGSN RADIUS Accounting Events
GGSN Function Trap SCS Cli- Event Description Transfer Transfer

Severity ent Event to SCS to SNMP
Text Manager
based on
Configu-
ration
RADIUS Accounting CRITI- ISP isp- RADIUS profile YES YES

CAL Name not configured for
APN apn- the ISP and APN
Name no and RADIUS
RADIUS Accounting option
profile. is chosen. Only a
maximum of 20
alarms of this type
are generated in 5
minutes interval.

OA&M 9-147
CRITI- ISP isp- No Accounting YES YES

CAL Name server provi-
APN apn- sioned and
Name no RADIUS Account-
RADIUS ing option is cho-
server. sen. Only one
alarm of this type
is generated in a
hour interval for
each RADIUS Pro-
file.
CRITI- ISP isp- No Primary YES YES

CAL Name Accounting Server
APN apn- specified and
Name no RADIUS Account-
primary ing Option is cho-
RADIUS sen. Only one
Server alarm of this type
Present. is generated in a
hour interval for
each RADIUS Pro-
file
MINOR Acct-Off GGSN couldn't get NO YES

timed out the response for
for RADIUS Acct OFF
Radius message after
server configured num-
server_n ber of retries on
ame in the profile.
profile
profile_n
ame.

MINOR Address There are some YES YES

Pool GTP sessions
pool_na using the address
me dele- pool that AAA
tion Manager is trying
failed for to delete and can
isp isp- not invoke take
Name down on these
(err_str)” sessions by send-
ing a request to
GTP Manager.
This is very
unlikely scenario.
Table 9-54
SNMP GGSN RADIUS Accounting Event MIB Notification Object
MIB Variable Values
ssg5000GGSNAAAEventId aaaNoAcctProfile(1),
aaaNoAcctServer(2),
aaaNoPrimaryServer(3),
aaaAcctOffTimeout(4),
aaaAddrPoolDeletionFailed(5)

the ISP Name
ssg5000TrapAPNName A trap variable object for providing

the APN name
ssg5000EventDescr A trap object for describing GGSN

AAA Event

major(2),
minor(4),
info(8)

OA&M 9-149
Below is an OID for the SNMP RADIUS Accounting Event Notification

object:
efix(2).ssgMIBNotification(0).ssg5000GGSNAAAEventNotification(65)
GGSN Lawful Interception Alarms

The GGSN Lawful Interception alarms are listed in Table 9-55. They
are sent using the MIB object ssg5000LIAlarmNotification described in
Table 9-56.
Table 9-55
GGSN LI Alarms
GGSN Trap Alarm State Alarm Description Transfer Transfer

Function Severity to SCS to SNMP
Manager
based
on
Configur
ation
Lawful MAJOR alarmOccur TCP connection to YES YES

Interceptio the ADMF is down.
n
MAJOR alarmClear TCP connection to YES YES
the ADMF is up.
MAJOR alarmOccur TCP connection to YES YES

DF(s) is down.
MAJOR alarmClear TCP connections YES YES

to all DFs are up.
A 5-minute timer is
started when the
alarm is raised.
The alarm clears
only after the timer
expires and the
TCP connections
to all DFs are up.
Otherwise, the
alarm remains
raised and the
timer is restarted.

Table 9-56
SNMP GGSN LI Alarm MIB Notification Object
MIB Variable Values

ssg5000LIAlarmId liAdmfLinkDown(1),
liDfLinksDown(2)
ssg5000LINumDfLinksDown A trap variable object for providing

the number of DF links down.
alarmClear(2)
major(2),
minor(4),
info(8)
Below is an OID for the SNMP LI Alarm Notification object:
efix(2).ssgMIBNotification(0).ssg5000LIAlarmNotification(66)
SNMP Overload Alarms

The Nortel GGSN overload alarms indicate the severity of the overload
with four levels:
• CRITICAL - Used for reporting level 3 of resource overload

condition. This level reports that the resource is being utilized
nearly at the maximum capacity level.
• MAJOR - Used for reporting level 2 of resource overload condition.
This level reports that the resource is being utilized in the level 2
overload range.
• MINOR - Used for reporting level 1 of resource overload condition.
This level reports that the resource is being utilized in the level 1
overload range.
• INFORMATION - Used to report when a resource utilization moves
from overload condition to normal condition of the resource.

OA&M 9-151
CPU Alarms
Each CMC card has two CPUs - Processor 0 and Processor 1 and
each SSC card has four CPUs. When any one of these processors is
overloaded, an alarm indication is sent. A MIB notification object has
been created to send overload alarm notification. These alarms are
informational only, no action is required from the operator. “CPU Total
Overload” and “CPU Interrupt Overload” have been defined for
overload alarms. The overload condition alarms are given in Table 9-
57.
Table 9-57
CPU Overload Condition Alarms
Overload Overload CPU Alarm Alarm Description

Type level Occupancy Severity
CPU Total Normal 0% - 74% INFORMATI CPU Overload Level 0
Overload ON
Level 1 75% - 84% MINOR CPU Overload Level 1
Level 2 85% - 89% MAJOR CPU Overload Level 2
Level 3 90% - 100% CRITICAL CPU Overload Level 3
CPU Normal 0% - 19% INFORMATI CPU Interrupt
Interrupt ON Overload Level 0
Overload Level 3 20% - 100% CRITICAL CPU Interrupt
Overload Level 3
Memory Alarms
When Processor 0 system memory on the active CMC card is over
utilized an alarm indication is sent. These alarms are informational
only, no action is required from the operator. An “Memory Overload”
alarm type is defined for overload alarms. The overload condition
alarms are illustrated in Table 9-58.

Table 9-58
Memory Overload Condition Alarms
Overload Overload Memory Alarm Alarm Description

Type level Occupancy/ Severity
Fragmentation
Memory Normal >= 100 MB INFORMATI Memory Overload
Overload Free AND ON Level 0
>= 512 KB
block sizes
Level 1 < 100 MB Free MINOR Memory Overload
OR Level 1
< 512 KB block

sizes
Level 2 < 70 MB Free MAJOR Memory Overload
OR Level 2
< 256 KB block

sizes
Level 3 < 50 MB Free CRITICAL Memory Overload
OR Level 3
< 64 KB block
sizes
Disk Capacity Alarms

The disk capacity check can also send an overload alarm. When a
disk capacity alarm is received, the operator may need to take action
and free up disk space. The disk capacity alarms are illustrated in
Table 9-59.

OA&M 9-153
Table 9-59
Disk Capacity Overload Condition Alarms
Overload Overload Disk Occupancy Alarm Alarm Description

Type level Severity
Disk Normal 0% - 64% (CMC2 INFORMATI NORMAL: <devName>
Capacity card) ON is <percent_full>%
full. (Downgraded)
0% - 87% (CMC3
card)
Level 2 65% - 71% (CMC2 MAJOR WARNING:

card) <devName> is
<percent_full>% full. If
88% - 93% (CMC3 this level is reached
card) due to an increase in
available disk space,
(Downgraded) will be
added to the message.
Level 3 72% - 100% CRITICAL CRITICAL:
(CMC2 card) <devName> is
<percent_full>% full.
94% - 100%
(CMC3 card)
RADIUS Accounting File Alarms

When the number of RADIUS Accounting files within the directory “/
disk/acct/radius” rises above a certain level, a RADIUS Accounting
File Alarm is raised. The operator may need to take action and reduce
the number of existing files to clear the alarm.The details are
illustrated in Table 9-60.

Table 9-60
RADIUS Accounting File Alarm
Overload Overload Number of Alarm Severity Alarm Description

Type Level RADIUS
Accounting Files
RADIUS Normal < 5000 INFORMATION "NORMAL: Number of files in

Accountin directory %s [dirname] is
g Files below suggested limit of %d
[ssg5000TrapOverloadResour
ceValue]"
Level 2 > 5000 & < 6000 MAJOR "WARNING: %s [dirname] has
%d
ceValue] files (suggested
maximum is %d [maxnum]
Level 3 > 6000 CRITICAL "CRITICAL: File writing to

directory %s [dirname] has
stopped due to file number
%d
ceValue] exceeding %d
[maxnum]"
GTP Accounting File Alarms

When the number of GTP Accounting files within the directory “/disk/
acct/gtp/cdrs” rises above a certain level, a GTP Accounting File Alarm
is raised. The operator may need to take action and reduce the
number of existing files to clear the alarm. The details are illustrated in
Table 9-61.
Table 9-61
GTP Accounting File Alarm
Overload Type Overload Level Number of GTP Alarm Severity

Accounting Files
GTP Accounting Normal < 5000 INFORMATION

Files
Level 2 > 5000 & < 6000 MAJOR
Level 3 > 6000 CRITICAL

Accounting Files

OA&M 9-155
Table 9-61
GTP Accounting File Alarm

Accounting Files
GTP Accounting Normal < 5000 INFORMATION

Files
Level 2 > 5000 & < 6000 MAJOR
Overload MIB Notification Object

A MIB notification object for the overload event is created to define an
overload trap. This object is created in the SSG-5000-CHASSIS-MIB.
The overload alarm notification object contains different MIB variables
described in the following table.
Table 9-62
SNMP Overload Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSlotId Slot number
ssg5000TrapCardType Card type
ssg5000TrapPortId Port number
ssg5000TrapProcessor id NA = 0
P0=1
P1=2
P2=3
P3=4

MIB Variable Values

ssg5000TrapOverloadResourc CPU_TOTAL_OVERLOAD
eType =0
CPU_INTERRUPT_OVERLO
AD = 1
MEMORY_OVERLOAD =2
BANDWIDTH_OVERLOAD=
3
SSP_RESOURCE_OVERLO
AD=4
RPC_BUFFER_OVERLOAD
=5
DISK_CAPACITY_OVERLO
AD=6
ENCRYPTION_SSP_OVERL
OAD=7
ssg5000TrapOverloadLevel NORMAL =0
LEVEL_1 = 1
LEVEL_2 = 2
LEVEL_3 = 3
ssg5000TrapOverloadResourc integer
eValue
ssg5000TrapOverloadAlarmDe A valid text string
scription
ssg5000TrapSSGHostAddress IP address of GGSN
major(2),
minor(4),
info(8)
ssg5000EventCategory Disk Capacity category (81)

OA&M 9-157
MIB Variable Values

ssg5000EventId Writing to disk stopped (4)
Writing to disk allowed (5)

ssg5000EventDescr Writing to disk stopped.
Disk space
total=<total_space>K,
free=<free_space>K,
reserved=<reserved_space
>K.
Writing to disk allowed.

Disk space
total=<total_space>K,
free=<free_space>K,
reserved=<reserved_space
>K.
Below is an OID for the SNMP overload alarm notification object.
efix(2).ssgMIBNotification(0).ssg5000OverloadAlarmNotification(18)
The following table shows new objects that are defined for the Nortel
GGSN to support an overload MIB notification object.
Table 9-63
Nortel GGSN Overload MIB Notification
ID MIB Variable Type Description

ssg5000TrapInde ssg5000TrapOverloa OverloadResourc A trap variable
xGroup 42 dResourceType eType object for
displaying overload
resource type
ssg5000TrapInde ssg5000TrapOverloa OverloadLevel A trap object for
xGroup 43 dLevel indicating Overload
Level
ssg5000TrapInde ssg5000TrapOverloa DisplayString A trap object for
xGroup 44 dAlarmDescription describing an
overload alarm

ID MIB Variable Type Description

ssg5000TrapInde ssg5000TrapProcess ProcessorType A trap object for
xGroup 45 orId indicating
processor id.
ssg5000TrapInde ssg5000TrapOverloa Integer32 A trap object for
xGroup 46 dResourceValue overload resource
value
Disk Capacity Events

GGSN reserves disk space based on a 1GB CMC core dump and a
100MB safety margin, as follows:
• Reserved disk space is 1GB + 100M = 1.1GB if no CMC

coredumps exist or if only one core dump exists, that is, if either /
disk/core1 or /disk/core2 is, or both are empty.
• Reserved disk space is 100MB if two CMC coredumps exist, that
is, both /disk/core1 and /disk/core2 are not empty.
A ssg5000EventNotification SNMP trap is generated corresponding to
the “Writing to disk stopped” event as the following:
Table 9-64
MIB Variable Values
ssg5000EventId 4
ssg5000EventDesrc Writing to disk stopped. Disk

space total=<total_space>K,
free=<free_space>K,
reserved=<reserved_space>K.

GGSN
ssg5000TrapSeverity critical(1)
A ssg5000EventNotification SNMP trap is generated corresponding to

the “Writing to disk allowed” event as the following:
Table 9-65
MIB Variable Values
ssg5000EventId 5

OA&M 9-159
MIB Variable Values
ssg5000EventDesrc Writing to disk allowed. Disk

space total=<total_space>K,
free=<free_space>K,
reserved=<reserved_space>K.
GGSN
ssg5000TrapSeverity info(8)
efix(2).ssgMIBNotification(0).ssg5000EventNotification(24)
SNMP Patch Alarm

A SNMP trap is generated when a patching operation fails on the SSG.
The alarm is generated whenever a condition is detected that indicates
that the SSG is out of “patch sync” with the SCS. The alarm is
generated based on the slot/port/processor that the failure occurred.
Only one alarm will be generated for a slot/port/processor; if multiple
patching operation failures exist, only one alarm is generated for the
slot/port/processor. If the conditions that caused the alarm are
resolved, the patch alarm is cleared.
A “Patch Sync Status” alarm type is defined for patch alarms.

Table 9-66
Patch Manager Alarms
GGSN Trap Alarm State Alarm Transfer Transfer

Manager
based
on
Configur
ation
Patch MAJOR alarmOccur Patch data is YES YES

Manager out of sync
between SSG
and SCS
MAJOR alarmClear Patch data is YES YES
out of sync
between SSG
and SCS
Table 9-67
Trap Patch Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSlotId slot number
ssg5000TrapCardType card type
ssg5000TrapPortId port number
ssg5000TrapProcessorId processor number
major(2),
minor(4),
info(8)
ssg5000TrapPatchSyncStatus 0 - In Sync
1 - Out of Sync
ssg5000TrapSSGHostAddress IP address of GGSN
alarmClear(2)
Below is the OID for the SNMP Trap Patch Alarm Notification object:

OA&M 9-161
efix(2).ssgMIBNotification(0).ssg5000TrapPatchAlarmNotification(72)
Diameter Credit Control (DCC) Alarms

The GGSN Diameter Credit Control alarms are listed in Table 9-68.
They are sent using the MIB object ssg5000DCCAlarmNotification
described in Table 9-69. Diameter Policy Control is based on DCC.
The DCC alarms are also used for Diameter Policy Control.
Table 9-68
GGSN DCC Alarms

Manager
based
on
Configur
ation
Diameter CRITICA alarmOccur No Diameter YES YES

Credit L server(s)
Control configured in the
DCC Profile on ISP
is reachable.
CRITICA alarmClear At least one YES YES

L Diameter server is
now reachable or
all Diameter
servers are offline.
MINOR alarmOccur Diameter server at YES YES
address
configured on
Diameter Profile
on ISP is not
reachable.
MINOR alarmClear Diameter server is YES YES

now reachable or
has been put in an
offline state.

Table 9-69
SNMP GGSN DCC Alarm MIB Notification Object
MIB Variable Values

ssg5000DccAlarmId dccNoOnlineServerAvailable(1),
dccOnlineServerUnreachable(2)
ssg5000TrapIspName A trap variable object for displaying

the ISP name.
ssg5000TrapProfileName A trap variable indicating the profile

name.
ssg5000DccServerIpAddr A trap variable object for displaying

Diameter
Server IP Address.
alarmClear(2)
major(2),
minor(4),
info(8)
Below is the OID for the DCC Alarm Notification object:
efix(2).ssgMIBNotification(0).ssg5000DCCAlarmNotification(69)
DCC SNMP Events

The GGSN Diameter Credit Control SNMP events are listed in Table
9-70. They are sent using the MIB object
ssg5000DCCEventNotification described in Table 9-71.

OA&M 9-163
Table 9-70
GGSN DCC SNMP Events
GGSN Trap SCS Client Event Event Description Transfer Transfer to

Function Severity Text to SCS SNMP
Manager
based on
Configurati
on
Diameter INFO UNRECOGNIZED Diameter Peer YES YES
Credit RATE ID received an
Control <categoryId> Unrecognized Rate
RECEIVED from ID from GGSN.
DCC SERVER
<serverIpAddr> for
MSISDN <msisdn>,
POLICY
<profileName>, ISP
<ispName>.
MAJOR Tx TIMER By the end of the YES YES

EXPIRATIONS OF Tx Timer Event
COUNT Interval, the
<TxExpiryCount> number of Tx
EXCEEDED MAJOR Expiries was at
THRESHOLD ON least equal to the
DIAMETER major threshold
PROFILE but less than the
<profileName> AT critical threshold.
DIAMETER SERVER
<serverIpAddr>.
CRITICA Tx TIMER By the end of the YES YES

L EXPIRATIONS OF Tx Timer Event
COUNT Interval, the
<TxExpiryCount> number of Tx
EXCEEDED Expiries was at
CRITICAL least equal to the
THRESHOLD ON critical threshold.
DIAMETER
PROFILE
<profileName> AT
DIAMETER SERVER
<serverIpAddr>.

Table 9-71
SNMP GGSN DCC Event MIB Notification Object
MIB Variable Values

ssg5000DccEventId dccInvalidCategoryId(1),
dccTxExpirationsExceededMajorThre
shold(2),
dccTxExpirationsExceededCriticalThr
eshold(3)
ssg5000TrapIspName A trap variable object for displaying

the ISP name.
ssg5000DccServerIpAddr A trap variable object for displaying

Diameter Server IP Address.
ssg5000TrapMsisdnName A trap variable indicating the MSISDN

name.
ssg5000TrapProfileName A trap variable indicating the profile
name.
ssg5000DccCategoryId A trap variable object for displaying

DCC category Id.
major(2),
minor(4),
info(8)
ssg5000TrapTxExpiryCount The number of Tx Expirations during

a configured interval.
Below is the OID for the DCC Event Notification object:
efix(2).ssgMIBNotification(0).ssg5000DCCEventNotification(81)
Health Check Monitor Alarms

The GGSN Health Check Monitor alarms are listed in Table 9-72.
They are sent using the MIB object ssg5000HCMAlarmNotification
described in Table 9-73

OA&M 9-165
Table 9-72
GGSN Health Check Monitor Alarms

Manager
based
on
Configur
ation
Health CRITICA alarmOccur Nodal Activation YES YES
Check L Success Rate has
Monitor crossed the
Threshold Value.
CRITICA alarmClear Nodal Activation YES YES
L Success Rate has
crossed the
Threshold Value.
CRITICA alarmOccur Network Activation YES YES

L Success Rate has
crossed the
Threshold Value.
CRITICA alarmClear Network Activation YES YES

L Success Rate has
crossed the
Threshold Value.
INFO alarmOccur Attempted YES YES

Activations have
crossed the
Threshold Value
INFO alarmClear Attempted YES YES

Activations have
crossed the
Threshold Value

Table 9-73
SNMP GGSN Health Check Monitor Alarm MIB Notification Object
MIB Variable Values

ssg5000HCMAlarmId hcmNodalActivationSuccessRateDro
p(1),
hcmNetworkActivationSuccessRateD
rop(2),
hcmNoActivationAttempt(3)
ssg5000TrapHCMCurrentSucc A trap variable indicating the current

essRate success rate for Nodal or Network
Activations
ssg5000TrapHCMCurrentValu A trap variable indicating the current

e value for
Nodal success rate or
Network success rate or
Attempted activations.
alarmClear(2)
major(2),
minor(4),
info(8)
Attention: The default Nodal Activation Success Rate Threshold

value is 95%. The default Network Activation Success Rate
Threshold value is 90%. The default Activation Attempt Frequency
Threshold value is 0.
Below is the OID for the Health Check Monitor Alarm Notification
object:
efix(2).ssgMIBNotification(0).ssg5000HCMAlarmNotification(82)

OA&M 9-167
Content Filter
The following new alarms are added for the Content Filter functional
area.

Table 9-74
GGSN CFS Alarms
Alarm Trap Alarm State Alarm Transfer Transfer

Manager
Content MAJOR AlarmOccur No Content YES YES
Filtering Filter
Service servers are
available on
profile
<profile> on
ISP <ISP>
VPN <VPN>.
MAJOR AlarmClear No Content YES YES

Filter
servers are
available on
profile
<profile> on
ISP <ISP>
VPN <VPN>.
MINOR AlarmOccur Content YES YES

Filter server
at
<address>:<
port> on
profile
<profile> on
ISP <ISP>
VPN <VPN>
is
unavailable.
MINOR AlarmClear Content YES YES

Filter server
at
<address>:<
port> on
profile
<profile> on
ISP <ISP>
VPN <VPN>
is
unavailable.

OA&M 9-169
Table 9-75
SNMP GGSN CFS Alarm MIB Notification Object
New MIB Variable Values

ssg5000CfsAlarmId cfsNoServerAvailable(1),
cfsServerUnavailable(2)
displaying the ISP name.
ssg5000TrapVPNName A trap variable object for
displaying the VPN name, if
applicable or <none> if the profile
is not in use on a VPN
ssg5000TrapProfileName A trap variable object indicating
the profile name.
ssg5000ServerIpAddr A trap variable object for
displaying the CFS server IP
address.
ssg5000TrapPortId A trap variable object for
displaying the CFS server port.
alarmClear(2)
GGSN
major(2),
minor(4),
info(8)
Below is an OID for the SNMP CFS alarm notification object:
efix(2).ssgMIBNotification(0).ssg5000CfsAlarmNotification(70)
SER Base SNMP Traps

SNMP AAA Events
The SNMP AAA events are listed in Table 9-76. They are sent using
the MIB object ssg5000AAAEventNotification described in Table 9-77.

Table 9-76
SNMP AAA Events
GGSN Trap Event Text Event Description Transfer Transfer

Manager
based
on
Configur
ation
AAA INFO Session disconnect Session NO YES
Manager successful <success successfully
string> disconnected
MAJOR Session disconnect Session failed to NO YES

failed <failure string> disconnect
INFO Session disconnect Session NO YES

ignored. <ignore disconnect request
string> ignored
INFO WARNING radius_acct: radius account NO YES

NULL username Len user name is too
<name length> small
INFO WARNING radius_acct: radius account NO YES

[<caller id>] user name is too
RADIUS_ACCT_SESSI long
ON aaaid <session id>
Username <user name>
len <name length> too
Big
MINOR Freeing bad AAA reply AAA manager is NO YES

structure with address freeing the memory
<reply attributes> tlv- of invalid reply
count <tlv count> in structure. This
<ra> event is used only
for debugging
purpose
INFO Freeing bad AAA auth AAA manager is NO YES

structure with address freeing the memory
<auth attributes> tlv- of invalid
count <tlv count> in authentication
<ra> structure. This
event is used only
for debugging
purpose
MINOR User <user> User authentication NO YES
authentication failed failed

OA&M 9-171
Table 9-77
SNMP AAA Event MIB Notification Object
MIB Variable Values

ssg5000AAAInfoType aaaAuthFail(1)
aaaDisconnectSuccess(2)
aaaDisconnectFailure(3)
aaaDisconnectIgnore(4)
aaaAcctNullUsername(5)
aaaAcctLongUsername(6)
aaaFreeBadReply(7)
aaa2ndSessionForConn(8)
aaaFreeBadAuth(9)
ssg5000EventDescr A trap object for describing GGSN

AAA Event
major(2),
minor(4),
info(8)
Below is an OID for the SNMP AAA Event Notification object:
efix(2).ssgMIBNotification(0).ssg5000AAAEventNotification(26)
SNMP SCS Sync Alarms

The detailed information of SER base SNMP Sync alarms is given in
Table 9-78.

Table 9-78
SER Base SNMP SCS Sync Alarms
Shasta Alarm Alarm Alarm Description

Function Severity State
GGSN MINOR alarmOccu Synchronization between
Synchronizatio r SCS region server and
n GGSN is out-of-sync.
INFO alarmClear Synchronization between

SCS region server and
GGSN is in-sync.
Table 9-79 defines the SER base SNMP SCS Sync alarms MIB object.
The notification signals that the SNMP agent detects the alarm status
of the synchronization between SCS region server and GGSN.
Table 9-79
SNMP SCS Sync Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSCSSyncAlarmId outOfSynced(1)
ssg5000TrapSCSServerIpAddr A trap variable object for
providing the SCS IP address
ssg5000TrapOccurClearTag alarmOccur(1)
alarmClear(2)
GGSN
major(2),
minor(4),
info(8)
Below is an OID for the SER base SCS Sync alarm notification object:
efix(2).ssgMIBNotification(0).ssg5000SCSSyncNotification(20)
SNMP SCS Server Alarms

The detailed information of SER base SNMP SCS Server alarms is
given in Table 9-80.

OA&M 9-173
Table 9-80
SER Base SNMP SCS Server Alarms

SCS Server MINOR alarmOccu GGSN Connection with the
r SCS server is down.
INFO alarmClear GGSN connection with

SCS Server is up
Table 9-81 defines the SER base SNMP SCS Server alarms MIB
object. The notification signals that the SNMP agent detects the alarm
status of the connection between SCS server and GGSN is up or
down and SCS Server location.
Table 9-81
SNMP SCS Server Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSCSServerAlarmI connectionDown1)
d
ssg5000TrapSCSServerType unknownServer(1)
logServerLog(2)
pullServer(3)
regionServer(4)
monitoringServer(5)
logServerAccounting(6)
ssg5000TrapSCSServerIpAddr A trap variable object for
providing the SCS IP address
ssg5000TrapSCSServerPortNu A trap variable object for
mber providing the SCS Server Port
number
alarmClear(2)

MIB Variable Values

GGSN
major(2),
minor(4),
info(8)
Below is an OID for the SER base SCS Server alarm notification
object:
efix(2).ssgMIBNotification(0).ssg5000SCSServerNotification(21)
SNMP System Alarms

The detailed information of SER base SNMP System alarms is given
in Table 9-82.

OA&M 9-175
Table 9-82
SER Base SNMP System Alarms
Shasta Alarm Severity Alarm State SCS Alarm Alarm Description

Function Text
System CRITICAL alarmOccur DC Power One or more AC or DC power

Failure has failed.
INFORMATION alarmClear DC Power AC and/or DC power failure

Failure has been cleared
CRITICAL alarmOccur AC_DC Shelf One or more of the DC power

Over modules in the AC shelf is
Temperature over temperature.
INFORMATION alarmClear AC_DC Shelf Over temperature condition of

Over the DC power modules in the
Temperature AC shelf has been cleared
CRITICAL alarmOccur AC_DC Shelf One or more of the DC power
Failure modules in AC shelf has failed.
MAJOR alarmOccur AC_DC Shelf Fan tray DC power module in

Failure AC Shelf has failed
MINOR alarmOccur AC_DC Shelf One or more of the DC power

Failure modules in AC Shelf is
missing.
INFORMATION alarmClear AC_DC Shelf Failed/Missing DC power
Failure module condition has been
cleared
CRITICAL alarmOccur Node The node was rebooted by

rebooted itself.
This alarm is not clearable
CRITICAL alarmOccur Multiple fan Multiple fans have failed.

failure
INFORMATION alarmClear Multiple fan Multiple fans fail condition is
failure cleared
MAJOR alarmOccur Fan failure Single fan has failed.
INFORMATION alarmClear Fan failure Single fan failure condition

has been cleared
CRITICAL alarmOccur Fan Dead Fan Dead
INFORMATION alarmClear Fan Dead Fan dead is cleared

Shasta Alarm Severity Alarm State SCS Alarm Alarm Description

Function Text
INFORMATION alarmOccur System All the SSC cards are up now

SSMs up and SSG is able to accept
commands from SCS.
This alarm is not clearable
Table 9-83 defines the SER base SNMP System alarm MIB object.
The notification signal the SNMP agent detects an alarm status in the
system.
Table 9-83
SNMP System Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSystemAlarmId nodeDead(1)
nodeReboot(2)
fanDead(3)
fanFailure(4)
temperatureOverheat(5)
dcPowerFailure(6)
acDcShelfFailure(7)
acDcShelfOverheat(8)
batteryFailure(9)
batteryOverheat(10)
pcmciaCardInserted(11)
pcmciaCardRemoved(12)
sysSSMsAreUp(13),
multipleFanFailure(14)
alarmClear(2)

OA&M 9-177
MIB Variable Values

GGSN
major(2),
minor(4),
info(8)
Below is an OID for the System alarm notification object:
efix(2).ssgMIBNotification(0).ssg5000SysAlarmNotification(2)
SNMP Card Alarms

The detailed information of SER base SNMP Card alarms is given in
Table 9-84.

Table 9-84 SER Base SNMP Card Alarms

OA&M 9-179
Shasta Alarm Alarm SCS Alarm Text Alarm Description

Card INFO alarmOccu Card missing Slot is configured but no

r card inserted when the node
starts up.
INFO alarmOccu Card in Service The card has been inserted

r into a slot.
MAJOR alarmOccu Card out of service The card has been removed
r from its slot.
MAJOR alarmOccu Card Mismatch The installed card type does

r not match the slot
configuration.
CRITICAL alarmOccu Card boot The card is booting from the

r configuration file.
CRITICAL alarmOccu Card reboot The card was booted by

r itself.
MINOR alarmOccu Card revision Incompatible hardware or

r mismatch software version in card.
CRITICAL alarmOccu Card failed in boot The card has failed one or
r more diagnostics tests
during booting.
CRITICAL alarmOccu Card malfunction The card has failed to

r perform some functions.
MAJOR alarmOccu Card diagnostics The card has failed one or

r more diagnostics test during
booting.
CRITICAL alarmOccu Card dead CMC can not talk to the card.
r
INFO alarmOccu Card switched active The standby card becomes

r active after a switch
over.The alarm applies only
to CMC cards.
CRITICAL alarmOccu Card standby not in The active card issues this
r redundant when the database
operation for the standby
card fails for some reason or
if the standby card which
was in standby mode is
administratively taken down
or.

Shasta Alarm Alarm SCS Alarm Text Alarm Description

Card INFORMA alarmOccu PCMCIA card inserted PCMCIA card has been
TION r inserted into the chassis or
detected at boot time.
MAJOR alarmOccu PCMCIA card removed PCMCIA card has been

r removed from the chassis or
detected that it is not
present at boot time.
MINOR alarmOccu Card unconfigured Card found in unconfigured

r slot
INFORMA alarmOccu Card Up Card is in operational state
TION r
CRITICAL alarmOccu Card Disable The card has been

r administratively disabled
INFORMA alarmOccu Card Enable The card has been

TION r administratively enabled
INFORMA alarmOccu Card switch over is Card switch over is initiated
TION r initiated by user by user via CLI command
MAJOR alarmOccu Card switch over is Card switch over is triggered

r initiated internally by internal reason
MINOR alarmOccu Card Standby Not in CMC standby and CMC

r Redundant active don’t have the same
config/software version
INFO alarmClear Card Standby Not in CMC standby and CMC
Redundant active do have the same
config/software version
CRITICAL alarmOccu Card Switched Active SFC Switch to standby SFC

r has started.
CRITICAL alarmClear Card Switched Active SFC switch to newly active

is complete.
Table 9-85 defines the SER base SNMP Card alarms MIB object. The
notification signal the SNMP agent detects an alarm status in the card.

OA&M 9-181
Table 9-85
SNMP Card Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapCardAlarmId cardMissing(1)
cardInserted(2)
cardRemoved(3)
cardMismatch(4)
cardBoot(5)
cardReboot(6)
cardRevMismatch(7)
cardFailed(8)
cardMalfunction(9)
cardFailDiag(10)
cardDead(11)
cardSwitchToActive(12)
cardStandbyNotInRedundant(13)
cardPcmciaInserted(14)
cardPcmciaRemoved(15)
cardSwitchoverInitiatedByUser(1
6)
cardSwitchoverInitiatedInternal(1
7)
cardEnable(18)
cardDisable(19)
cardUp(20)
cardUnconfigured(21)
ssg5000TrapSlotId A trap slot ID for slot number

MIB Variable Values

ssg5000TrapCardType cardAbsent(0)
controlManagementCard(1)
subscriberServiceCard(2)
switchFabricCard(3)
oc3AtmLineCard(4)
ds3AtmLineCard(5)
hsiLineCard(6)
e3AtmLineCard(7)
oc12SAtmLineCard(8)
oc12DAtmLineCard(9)
cardTypeUnknown(10)
ds3ChannelizedFrameCard(11)
ethernetLineCard(12)
gigabitEthernetLineCard(13)
oc3stm1ChannelizedFrameCard(
14)
controlManagementCard3(19)
subscriberServiceCard3(22)
switchFabricCard2(24)
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)

OA&M 9-183
Below is an OID for the SER base Card alarm notification object:
efix(2).ssgMIBNotification(0).ssg5000CardAlarmNotification(3)
SNMP Card Events

The detailed information of SER base SNMP Card events is given in
Table 9-86.
Table 9-86
SER Base SNMP Card Events
Shasta Event Severity Event Description Text Event Description

Function
Card Major Found card of type inserting card in unusable

<card_type> in slot slot
<slotId>, but slot is not
usable.
INFORMATION Card type <card_type> Card left down since it is
in slot <slotId> is administratively disabled.
administratively
disabled
MAJOR Firmware update of Failed to update the card

card in slot <slotId> firmware
failed
INFORMATION Firmware update of The card firmware is

card in slot <slotId> successfully updated
succeeded.
Table 9-87 defines the SER base SNMP Card Event MIB object.

Table 9-87
SNMP Card Event MIB Notification Object
MIB Variable Values

ssg5000CardInfoType cardLeftInactive(1)
cardIgnored(2)
cardFoundUnusable(3)
cardLeftDown(4)
cardReprogrammedSuccess(5)
cardReprogrammedFail(6)
ssg5000EventDescr A trap object for describing card
manager event
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base Card Event notification object:
efix(2).ssgMIBNotification(0).ssg5000CardEventNotification(28)
SNMP ATM Port Alarm

The detailed information of SER base SNMP Port alarms is given in
Table 9-88.
Table 9-88
SER Base SNMP Port Alarms
Shasta Alarm Severity Alarm SCS Client Alarm Description

Func- State Alarm Text
tion
ALC INFORMATION alarmClear ALC Port The port on the ALC card family
Port Up is administratively enabled.

OA&M 9-185
MAJOR alarmOc- ALC Port The port on the ALC card family
cur Down is administratively disabled or
some alarms (i.e. LOS, LOF)
caused the port to become dis-
abled operationally.
MINOR alarmOc- ALC Line A line loopback has been acti-

cur loopback vated on the port.
activated
MINOR alarmClear ALC Line A line loopback has been de-

loopback activated on the port.
activated
MINOR alarmOc- ALC LOS LOS (Loss of Signal) detected

cur on the incoming signal. A fail-
ure occurs at the source (e.g.
laser failure) or the transmis-
sion facility.
INFORMATION alarmClear ALC LOS LOS (Loss of Signal) detected

on the incoming signal has
been cleared
MINOR alarmOc- ALC LOF LOF (Loss of Frame) detected

cur on the incoming signal. A fail-
ure related to the SONET fram-
ing.
INFORMATION alarmClear ALC LOF LOF (Loss of Frame) detected

on the incoming signal has
been cleared.
MINOR alarmOc- ALC Line Line layer AIS (Alarm Indication

cur AIS Signal) detected. A defect (i.e.
LOS, LOF) detected by the peer
equipment, but is not likely
caused by the SSG.
INFORMATION alarmClear ALC Line Line layer AIS (Alarm Indication

AIS Signal) condition has been
cleared.
MINOR alarmOc- ALC Line Line layer RDI (Remote Defect

cur RDI Indication) detected.
ALC INFORMATION alarmClear ALC Line Line layer RDI (Remote Defect
Port RDI Indication) condition has been
cleared

MINOR alarmOc- ALC LOP LOP (Loss of Path) detected. A

cur failure related to the SONET
pointer processing mechanism.
INFORMATION alarmClear ALC LOP LOP (Loss of Path) condition

has been cleared.
MINOR alarmOc- ALC Path Path layer AIS (Alarm Indication

cur AIS Signal) detected. A defect (i.e.
LOS, LOF) detected by the peer
equipment, and is possibly
caused by the SSG. (e.g. The
peer does not receive signal
from the SSG.)
INFORMATION alarmClear ALC Path Path layer AIS (Alarm Indication

AIS Signal) detected. A defect (i.e.
LOS, LOF) condition has been
cleared.
MINOR alarmOc- ALC Path Path layer RDI (Remote Defect

cur RDI Indication) detected. A defect
(i.e. LOS, LOF) detected by the
peer equipment, and is possibly
caused by the SSG. (e.g. The
peer does not receive signal
from the SSG.)
INFORMATION alarmClear ALC Path Path layer RDI (Remote Defect

RDI Indication) condition has been
cleared
MINOR alarmOc- ALC Loss Failure to detect ATM cell

cur of cell boundary/framing.
delineation
INFORMATION alarmClear ALC Loss Failure to detect ATM cell

of cell boundary/framing condition
delineation has been cleared
Table 9-89 defines the SER base SNMP ATM Port alarms MIB object.
The notification signals that the SNMP agent detects an alarm status
in the ATM port.

OA&M 9-187
Table 9-89
SNMP ATM Port Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapALCPortAlarmId portUp(1),
portDown(2),
portLoop(3),
portLOS(4),
portLOF(5),
portLAIS(6),
portLRDI(7),
portLOP(8),
portPAIS(9),
portPRDI(10),
portLCD(11),

MIB Variable Values

switchFabricCard(3)
oc3AtmLineCard(4)
ds3AtmLineCard(5)
hsiLineCard(6)
e3AtmLineCard(7)
oc12SAtmLineCard(8)
oc12DAtmLineCard(9)
cardTypeUnknown(10)
ssg5000TrapPortId A trap port ID for port number
alarmClear(2)
GGSN
major(2),
minor(4),
info(8)
Below is an OID for the SER base ATM Port alarm notification object:
efix(2).ssgMIBNotification(0).ssg5000PortAlarmNotification(4).

OA&M 9-189
SNMP ALC Events

The detailed information of SER base SNMP ALC Event is given in
Table 9-90.
Table 9-90
SER Base SNMP ALC Events
Shasta Event Event Description Text Event Description

Function Severity
ALC INFO ALC slot <slotId> ICP ALC cam is full

<icp> CAM <cam> is
full
MAJOR ALC slot <slotId> port ALC Port is YELLOW

<portid> YELLOW
MAJOR ALC slot <slotId> bad ALC slot has bad icp
ICP
Table 9-91 defines the SER base SNMP ALC Event MIB object.
Table 9-91
SNMP ALC Event MIB Notification Object
MIB Variable Values

ssg5000ALCInfoType alcCamFull(1)
alcPortYellow(2)
alcIcpFailed(3)
ssg5000EventDescr A trap object for describing ALC
event
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base ALC Event notification object:
efix(2).ssgMIBNotification(0).ssg5000ALCEventNotification(27)

SNMP SSM Alarm

The detailed information of SER base SNMP SSM alarms is given in
Table 9-92.
Table 9-92
SER Base SNMP SSM Alarms
Shasta Alarm Severity Alarm Alarm Text Alarm Description

Function State
SSM CRITICAL alarmOccu SSM Failed The SSM failed to

r download the code from
the CMC. After trying a few
times, it gives up and
issues failed trap. The
alphanumeric display on
the SSC card display this
alarm.
MAJOR alarmOccu SSM Reset This is a transient state and

r the trap may not be issued.
When SSM runs out of
resources (e.g. memory) or
unable to talk to CMC card,
it issues this trap. The
alphanumeric display
shows it as Reset (RST).
The SSM tries to boot up. If
it fails for a few times, it
goes into failed state.
INFORMATIO alarmClear SSM Up After a successful boot, it

N issues this trap. Now it is in
a proper state to service
the packet flow.
MAJOR alarmOccu SSM Down The SSM on the SSC card

r has been administratively
disabled.
CRITICAL alarmOccu SSM Down SSM on the SSC card is

r stuck in catchup due to
congestion; Taking it
temporarily down; To
recover manually reset
SSM
CRITICAL alarmOccu SSM Dead SSM has died due to sw

r module error

OA&M 9-191
Table 9-93 defines the SER base SNMP SSM alarms MIB object. The
notification signal the agent detects an alarm status in the SSM.
Table 9-93
SNMP SSM Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSSMAlarmId ssmFailed(1)
ssmReset(2)
ssmUp(3)
ssmDead(4)
ssmDown(5)
switchFabricCard(3)
oc3AtmLineCard(4)
ds3AtmLineCard(5)
hsiLineCard(6)
e3AtmLineCard(7)
oc12SAtmLineCard(8)
oc12DAtmLineCard(9)
cardTypeUnknown(10)
alarmClear(2)

MIB Variable Values

GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base SSM alarm notification object:
ER
Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix
(2).ssgMIBNotification(0).ssg5000SSMAlarmNotification(5)
SNMP SSM Event

The detailed information of SER base SNMP SSM alarms is given in
Table 9-94.
Table 9-94
SER Base SNMP SSM Events
Shasta Alarm Event Description Text Event Description

Function Severity
SSM MINOR SSM <portId> in slot SSSM was administratively disabled

<slotId> is disabled
MAJOR Erratic SSM: <slotId> Error detected in SSM
<portId> <cpu_miss0>
<cpu_miss1> <cpu_miss2>
<cpu_miss3>
MAJOR Erratic downloading SSM: Error downloading the software to

<slotId> <portId> SMM
INFO SSM <portId> in slot SSM started a core dump

<slotId> started core dump

OA&M 9-193

Function Severity
MAJOR Core Dump failed for SSM SSM failed to dump core
<portId> in slot <slotId>
Error <errorcode>
INFO SSM <portId> in slot SSM successfully dumped core

<slotId> successfully
dumped core
INFO SSM <portId> in slot removing SSM is done
<slotId> removal
processing done.
MAJOR EPIF channel <channelId> EPIF channel has died
in slot <slotId> has died.
MAJOR Reset SSC Card in slot Error detected and SSC card got
<slotId> reset
MAJOR All SSM in slot <slotId> ALL SSM on specific slot have failed
have failed


Function Severity
MAJOR SSM <portId> in slot SSM and CMC received unmatched

<slotId> has missed poll number of “hello” messages.
<iteration> iterations. SSM
received The logs are seen when the SSMs are
<cmc_2_ssm_hello> hellos, booting up.
CMC received
<ssm_2_cmc_hello> hellos When the SSM(s) are coming up the
CMC polls their status by sending
“Hello” messages and noting their
response from the SSM(s)
If the difference between the “SSM

received hellos” (the “hello
messages sent by CMC) and the
“CMC received hellos” (“Hello”
messages sent by the SSM(s))
continuously goes on increasing, it
means that the SSM is not able to
respond.
If the SSMs fails to respond to the

“Hello” messages then the sending
of the “Hello” messages continues
till a predefined number of times.
- If a single SSM fails to respond then

an internal timer timeout occurs and
only that SSM is reset (No need to
reset the SSC card). Provision is
made for maximum number of resets.
If the maximum number of reset is
attained the faulty SSM is declared as
failed and is held in reset state.
- If more than one SSM on an SSC fail

to respond then an internal timer
timeout occurs and the SSC card is
reset. Provision is made for
maximum number of resets. If the
maximum number of reset is attained
the faulty SSM is declared as failed/
disabled.
MINOR All connections to SSC in All connection to SSC on specific slot

slot <slotId> are reset have been reset
(<number_of_ticks>)

OA&M 9-195

Function Severity
INFO SSC in slot <slotId> reset SSC has successfully been reset
successfully
(<number_of_ticks>)
MINOR CMC received hello from CMC received invalid slop/port in the
SSM with invalid slot/port: hello message from SSM
<slotId> <portId>
Table 9-95 defines the SER base SNMP SSM Events MIB object.
Table 9-95
SNMP SSM Event MIB Notification Object
MIB Variable Values

ssg5000TrapSSMInfoType ssmDisabled(1)
ssmErratic(2)
ssmErraticDownload(3)
ssmStartDump(4)
ssmDumpError(5)
ssmFinishDump(6)
ssmRemoveDone(7)
epifChannelDied(8)
sscCardRest(9)
ssmAllFailed(10)
ssmMissPoll(11)
sscConnectionReset(12)
sscConnectionResetOK(13)
ssmBadHello(14)
ssg5000EventDescr A trap object for describing SSM
Info event

MIB Variable Values

GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base SSM Event notification object:
efix(2).ssgMIBNotification(0).ssg5000SSMEventNotification(31)
SNMP Ethernet Port Alarms

The detailed information of SER base SNMP Ethernet port alarms is
Table 9-96
SER Base SNMP Ethernet Port Alarms
Shasta Alarm Severity Alarm SCS Client Alarm Alarm Description

Function State Text
ETH Port MAJOR alarmOccu ETH Link Down The port is either
r administratively down or
because of some problem
the attached interface is
operationally down.
INFORMATION alarmClear ETH Link Down The port is administratively

enabled and the attached
interface is up.
Table 9-97 defines the SER base SNMP Ethernet Port alarms MIB
object. The notification signals that the SNMP agent detects an alarm
status in the Ethernet port.

OA&M 9-197
Table 9-97
SNMP Ethernet Port Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapETHPortAlarmId ethLinkDown(1)
switchFabricCard(3)
oc3AtmLineCard(4)
ds3AtmLineCard(5)
hsiLineCard(6)
e3AtmLineCard(7)
oc12SAtmLineCard(8)
oc12DAtmLineCard(9)
cardTypeUnknown(10)
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)

Below is an OID for the SER base Ethernet Port alarm notification
object:
efix(2).ssgMIBNotification(0).ssg5000ETHPortAlarmNotification(8)
SNMP ELC Events

The detailed information of SER base SNMP ELC Event is given in
Table 9-98.
Table 9-98
SER Base SNMP ELC Events

Function Severity
ELC MAJOR Ethernet slot <slotId>: ELC ipcam is full

IPCAM <ipcam> is full
Table 9-99 defines the SER base SNMP ELC Event MIB object.
Table 9-99
SNMP ELC Event MIB Notification Object
MIB Variable Values

ssg5000ELCInfoType elcIpCamFull(1)
ssg5000EventDescr A trap object for describing ALC
event
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base ELC Event notification object:
ER
(2).ss gMIBNotification(0).ssg5000ELCEventNotification(30)

OA&M 9-199
SNMP SSM Event

The detailed information of SER base SNMP SSM events is given in
Table 9-100.
Table 9-100
SER Base SNMP Config Info Events

Function Severity
Configuratio INFO Config phase 1 complete Configuration phase 1

n complete
CRITICAL Config phase 1 load failed: configuration phase 1

<error_reason> loaded failed
INFO Config phase 2 complete Configuration phase 2
complete
CRITICAL Config phase 2 load failed: Configuration phase 2

<error_reason> loaded failed
INFO Quickstart information Quickstart information

(phase 1) loaded (phase 1) loaded
CRITICAL Quickstart load (phase 1) Quickstart load (phase 1)
failed: <error_reason> failed
INFO Quickstart information Quickstart information

(phase 2) loaded (phase 2) loaded
CRITICAL Quickstart load (phase 2) Quickstart load (phase 2)

failed: <error_reason> failed
INFO Configuration Certain configuration

<config_name> initialized initialized
MINOR Command Certain command has

<command_name> failed: failed
<error_reason>
MINOR Error on DB <db_op> in Database error

<config> <db> err:
<error_num>
INFO Image files are protected Image files are protected
INFO Image files are not Image files are not

protected protected
Table 9-101 defines the SER base SNMP Configuration Events MIB
object.

Table 9-101
SNMP Config Info MIB Notification Object
MIB Variable Values

ssg5000ConfigInfoType configPhase1Loaded(1)
configPhase1Failed(2)
configPhase2Loaded(3)
configPhase2Failed(4)
configQsP1Loaded(5)
configQsP1Failed(6)
configQsP2Loaded(7)
configQsP2Failed(8)
configInitialized(9)
configBadCommand(10)
configDbOpError(11)
configProtectImageFiles(12)
configNotProtectImageFiles(13)
ssg5000EventDescr A trap object for describing
config info event
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base Config Info notification object:
efix(2).ssgMIBNotification(0).ssg5000ConfigInfoNotification(29)

OA&M 9-201
Config Objects Alarm Notification

Table 9-102 defines the base SER BSN Config Object Changes Alarm
Notification. This alarm indicates that the agent has detected a set
operation from the CLI. This event is sent to trigger the SCS to retrieve
the specified config object for synchronization.
Table 9-102
Config Object Changes MIB Notification Object
MIB Variable Values

ssg5000TrapConfigChangesAl set(1)
armId
delete(2)
ssg5000TrapConfigObjectId deviceObject(1)
displaying the ISP name
ssg5000TrapSSGHostAddress The IP address of the GGSN
major(2)
minor(4)
info(8)
Below is an OID for the base SER Service alarm notification object:
efix(2).ssgMIBNotification(0).ssg5000ConfigObjectChangesNotificatio
n(22)
SNMP Memory Changed Event

The detailed information of SER base SNMP Memory Changed event
is given in Table 9-103
Table 9-103
GGSN Memory changed event

Function Severity
CMC INFO Redundant CMC has sent Memory of CMC has been
memory size to Active CMC changed
Table 9-104 defines the base SER BSN Memory Changed Event. The
GGSN Memory Changed Event indicates that the redundant CMC has

sent memory size to the Active CMC. It is used to trigger SCS to

perform a get card operation.
Table 9-104
SNMP GGSN Memory Changed MIB Notification Object
MIB Variable Values

ssg5000TrapMemoryChangeAlarmI Memory changed (1)
d
ssg5000TrapSlotId 13 or 14
ssg5000TrapCardType Standby CMC
GGSN
ssg5000TrapServerity Info(8)
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SE
RExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(
2).ssgM IBNotification(0).ssg5000MemoryChangeNotification(23)
SNMP VPN Mesh Alarms

The detailed information of SER base SNMP VPN Mesh alarms is
Table 9-105
SER Base SNMP VPN Mesh Alarms
Shasta Alarm Alarm SCS Client Alarm Alarm Description

Function Severity State Text
VPN MINOR alarmOccu VPN Mesh Down VPN link failed

r
MINOR alarmClear VPN Mesh Down VPN link failed condition

has cleared
Table 9-106 defines the SER base SNMP VPN Mesh alarms MIB
status in VPN.

OA&M 9-203
Table 9-106
SNMP VPN Mesh Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapVPNMeshAlarmId vpnMeshDown(1)
ssg5000TrapVPNGlobalId A trap vpn global ID for slot
number
providing the ISP Name
ssg5000TrapVPNName A trap variable object for
providing the VPN Name
ssg5000TrapRemoteIpAddr A trap variable object for
providing the remote IP address
of VPN link
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base VPN Mesh alarm notification object:
ER
(2).ss gMIBNotification(0).ssg5000VPNMeshtAlarmNotification(13)
SNMP System Monitor Alarms

The detailed information of SER base SNMP System Monitor alarms is

Table 9-107
SER Base SNMP System Monitor Alarms

System MINOR alarmOccu Subscriber count Subscriber threshold ratio

monitor r increased has been reached at or
below, for the threshold
range on the port/slot/card
of the GGSN
INFO alarmClear Subscriber count The subscriber threshold

increased ratio level is reached at or
above the threshold range
on the port/slot/card of the
GGSN
Table 9-108 defines the SER base SNMP VPN Mesh alarms MIB object.
Table 9-108
SNMP System Monitor Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSysmonAlarmId activeSubMonitor(1)

OA&M 9-205
MIB Variable Values

switchFabricCard(3)
oc3AtmLineCard(4)
ds3AtmLineCard (5)
hsiLineCard(6)
e3AtmLineCard(7)
oc12SAtmLineCard(8)
oc12DAtmLineCard(9)
cardTypeUnknown(10)
ssg5000TrapThresholdLevel A trap variable object for
providing the threshold level
ssg5000TrapSubscriberCount A trap variable object for
providing the subscriber count
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base System Monitor alarm notification
object:

ER
(2).ssgMIBNotification(0).ssg5000SysmonAlarmNotification(25)
SNMP L2TP Alarms

The detailed information of SER base SNMP L2TP alarms is given in
Table 9-109.
Table 9-109
SER Base SNMP L2TP Alarms

L2TP INFO alarmOccu L2TP Tunnel Down L2TP tunnel is down

r
INFO alarmClear L2TP Tunnel Down L2TP tunnel is up
Table 9-110 defines the SER base SNMP L2TP alarms MIB object.
in L2TP tunnel.
Table 9-110
SNMP L2TP Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapL2tpTunnelAlarmI l2tpTunnelDown(1)
d
ssg5000TrapL2tpTunnelIfInde A trap variable object for
x providing the l2tp tunnel interface
index
ssg5000TrapL2tpTunnelName A trap variable object for
providing the l2tp tunnel Name
ssg5000TrapL2tpRemoteTunn A trap variable object for
elName providing l2tp remote tunnel
name
ssg5000TrapL2tpTunnelType A trap variable object for
providing L2tpTunnel type
alarmClear(2)

OA&M 9-207
MIB Variable Values

GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base L2tp Tunnel alarm notification
object:
ER
(2).ss gMIBNotification(0).ssg5000L2tpTunnelAlarmNotification(17)
SNMP PVC Alarms

The detailed information of SER base SNMP PVC alarms is given in
Table 9-111.
Table 9-111
SER Base SNMP PVC Alarms

PVC MAJOR alarmOccu Connection Down PVC Connection is down

Status r
MAJOR alarmClear Connection Down PVC Connection is up
Table 9-112 defines the SER base SNMP PVC alarms MIB object.
in a PVC.
Table 9-112
SNMP PVC Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapPVCAlarmId ConnectionDown(1)
ssg5000TrapSlotId A trap variable object for
providing slot id

MIB Variable Values

switchFabricCard(3)
oc3AtmLineCard(4)
ds3AtmLineCard(5)
hsiLineCard(6)
e3AtmLineCard(7)
oc12SAtmLineCard(8)
oc12DAtmLineCard(9)
cardTypeUnknown(10)
ssg5000TrapInterfaceNumber A trap variable object for
providing Interface number
ssg5000TrapVPINumber A trap variable object for
providing VPI number
ssg5000TrapVCINumber A trap variable object for
providing VCI number
alarmClear(2)
GGSN
ssg5000TrapConnectionName A trap variable object for
providing the connection Name
ssg5000TrapSubscriberName A trap variable object for
providing the subscriber Name

OA&M 9-209
MIB Variable Values

major(2)
minor(4)
info(8)
Below is an OID for the SER base PVC alarm notification object:
ER
(2).ss gMIBNotification(0).ssg5000PVCAlarmNotification(6)
SNMP Serial Port Alarms

The detailed information of SER base SNMP Serial Port alarms is
Table 9-113
SER Base SNMP Serial Port Alarms

Serial Port MINOR alarmOccu CMC Serial Port is down

Status r
INFO alarmClear CMC Serial is up
Table 9-114 defines the SER base SNMP PVC alarms MIB object.
in a Serial Port.
Table 9-114
SNMP Serial Port Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSerialPortAlarmId serialPortDown(1)
providing slot id

MIB Variable Values

switchFabricCard(3)
oc3AtmLineCard(4)
ds3AtmLineCard(5)
hsiLineCard(6)
e3AtmLineCard(7)
oc12SAtmLineCard(8)
oc12DAtmLineCard(9)
cardTypeUnknown(10)
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base Serial Port alarm notification object:
ER
(2).ss gMIBNotification(0).ssg5000SerialPortAlarmNotification(19)

OA&M 9-211
SNMP Serial Port Configuration Change Event

The detailed information of SER base SNMP Serial Port event is given
in Table 9-115.
Table 9-115
SER Base SNMP Serial Port Configuration Change Event
Shasta Event Event Event Description

Function Severity Description
Text
Serial Port INFO Serial port CMC Serial Port

Configura configuratio configuration has changed.
tion n change
Change
Notificatio
n
Table 9-116 defines the associated Alarm MIB object. The notification
signals that the SNMP agent detects a change in the configuration of a
Serial Port.
Table 9-116
SNMP Configuration Change Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapSerialPortConfig serialPortConfigChanged(1)
ChangeAlarmId
providing slot id

MIB Variable Values

switchFabricCard(3)
oc3AtmLineCard(4)
ds3AtmLineCard(5)
hsiLineCard(6)
e3AtmLineCard(7)
oc12SAtmLineCard(8)
oc12DAtmLineCard(9)
cardTypeUnknown(10)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base Serial Port alarm notification object:
ER
(2).ss
gMIBNotification(0).ssg5000SerialPortAlarmConfigChangeNotification
(55)
SNMP VRF Alarms

The detailed information of SER base SNMP VRF alarms is given in
Table 9-117.

OA&M 9-213
Table 9-117
SER Base SNMP VRF Alarms

MPLS INFO alarmOccu VRF Deactivated VRF VPN is de-activated in
VRF r ISP
INFO alarmClear VRF Deactivated VRF VPN is activated in ISP
Table 9-118 defines the SER base SNMP VRF alarms MIB object. The
notification signals that the SNMP agent detects an alarm status for
VRF.
Table 9-118
SNMP VRF Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapVRFAlarmId vrfDown(1)
ssg5000TrapVRFName A trap variable object for
providing the VRF Name
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base VRF alarm notification object:
ER
(2).ss gMIBNotification(0).ssg5000VRFAlarmNotification(38)
SNMP LFIB E-LSP Alarms

The detailed information of SER base SNMP LFIB E-LSP alarms is

Table 9-119
SER Base SNMP LFIB E-LSP Alarms

E-LSP INFO alarmOccu E-LSP Deactivated E-LSP is de-activated
Map r
INFO alarmClear E-LSP Deactivated E-LSP is activated
Table 9-120 defines the SER base SNMP LFIB E-LSP alarms MIB
status in the E-LSP map.
Table 9-120
SNMP LFIB E-LSP Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapLFIBELSPAlarmI elspMapDelete(1)
d
ssg5000TrapISPId A trap variable object for
providing the ISP ID
ssg5000TrapELSPName A trap variable object for
providing the E-LSP name
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base LFIB E-LSP alarm notification
object:
ER
(2).ss gMIBNotification(0).ssg5000LFIBAlarmNotification(32)

OA&M 9-215
SNMP MPLS BE-LSP Alarms

The detailed information of SER base SNMP MPLS BE-LSP alarms is
Table 9-121
SER Base SNMP MPLS BE-LSP Alarms

MPLS INFO alarmOccu MPLS BE LSP down MPLS BE-LSP is down

BE-LSP r
INFO alarmClear MPLS BE LSP down MPLS BE-LSP is up
Table 9-122 defines the SER base SNMP MPLS BE-LSP alarms MIB
status for MPLS BE-LSP.
Table 9-122
SNMP MPLS BE-LSP Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapBELSPAlarmId belspDown(1)
ssg5000TrapPrefixIpAddr A trap variable object for
providing the prefix IP Address
ssg5000TrapLabelValue A trap variable object for
providing the Label value
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base MPLS BE-LSP alarm notification
object:

ER
(2).ss gMIBNotification(0).ssg5000MPLSBELSPAlarmNotification(33)
SNMP MPLS LDP Alarms

The detailed information of SER base SNMP MPLS LDP alarms is
Table 9-123
SER Base SNMP MPLS LDP Alarms

MPLS INFO alarmOccu MPLS LDP Session MPLS LDP Session is

LDP r down down
INFO alarmClear MPLS LDP Session MPLS LDP Session is up

down
Table 9-124 defines the SER base SNMP MPLS LDP alarms MIB
status for MPLS LDP.
Table 9-124
SNMP MPLS LDP Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapLDPAlarmId ldpSessionDown(1)
providing the Interface number
alarmClear(2)

OA&M 9-217
MIB Variable Values

GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base MPLS LDP alarm notification object:
ER
(2).ss gMIBNotification(0).ssg5000MPLSLDPAlarmNotification(35)
SNMP MPLS TE-LSP Alarms

The detailed information of SER base SNMP MPLS RSVP-TE alarms
is given in Table 9-125.
Table 9-125
SER Base SNMP MPLS TE-LSP Alarms
Shasta Alarm Alarm SCS Client Alarm Text Alarm Description

MPLS INFO alarmOccu MPLS TE-LSP down MPLS TE-LSP is down

TE-LSP r
INFO alarmClear MPLS TE-LSP up MPLS TE-LSP is up
Table 9-128 defines the SER base SNMP MPLS TE-LSP alarms MIB
status for MPLS TE-LSP.
Table 9-126
SNMP MPLS TE-LSP Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapTELSPAlarmId telspDown(1)
ssg5000TrapLabelValue A trap variable object for
providing the MPLS Label

MIB Variable Values

alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
ssg5000TrapAdminStatus up (1),
down (2)
ssg5000TrapOperStatus up (1),
down (2)
Below is an OID for the SER base MPLS TE-LSP alarm notification
object:
ER
(2).ssgMIBNotification(0).ssg5000MPLSTELSPAlarmNotification(34)
SNMP MPLS RSVP-TE Alarms

The detailed information of SER base SNMP MPLS RSVP-TE alarms
is given in Table 9-127.
Table 9-127
SER Base SNMP MPLS RSVP-TE Alarms
Shasta Alarm Alarm SCS Client Alarm Text Alarm Description

MPLS INFO alarmOccu MPLS RSVP-TE Session MPLS RSVP-TE Session is

RSVP-TE r down down
INFO alarmClear MPLS RSVP-TE Session MPLS RSVP-TE Session is

down up

OA&M 9-219
Table 9-128 defines the SER base SNMP MPLS RSVP-TE alarms
MIB object. The notification signals that the SNMP agent detects an
alarm status for MPLS RSVP-TE.
Table 9-128
SNMP MPLS RSVP-TE Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapRSVPTEAlarmId rsvpteSessionDown(1)
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base MPLS RSVP-TE alarm notification
object:
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER
Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2)
.ssgMIBNotification(0).ssg5000MPLSRSVPTEAlarmNotification(36)
SNMP MPLS ISP Interface Alarms

The detailed information of SER base SNMP MPLS ISP Interface
alarms is given in Table 9-131.

Table 9-129
SER Base SNMP MPLS ISP Interface Alarms

MPLS ISP INFO alarmOccu MPLS ISP Interface MPLS ISP Interface
Interface r Session down Session is down
INFO alarmClear MPLS ISP Interface MPLS ISP Interface

Session down Session is up
Table 9-130 defines the SER base SNMP MPLS ISP Interface alarms
MIB object. The notification signals that the SNMP agent detects an
alarm status for MPLS ISP Interface.
Table 9-130
SNMP MPLS ISP Interface Alarm MIB Notification Object
MIB Variable Values

ssg5000TrapMPLSINTFAlarmI mplsinterfaceDown(1)
d
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base MPLS ISP Interface alarm
notification object:
efix(2).ssgMIBNotification(0).ssg5000MPLSINTFAlarmNotification(37)

OA&M 9-221
SNMP MP-BGP Alarms

The detailed information of SER base SNMP MP-BGP alarms is given
in Table 9-131.
Table 9-131
SER Base SNMP MP-BGP Alarms

BGP INFO alarmOccu BGP Peer Down BGP Peer is down

PEER r
INFO alarmClear BGP Peer Down BGP Peer is up
Table 9-132 defines the SER base SNMP MP-BGP alarms MIB object.
for MP-BGP.
Table 9-132
SNMP MP-BGP MIB Notification Object
MIB Variable Values

ssg5000TrapBGPAlarmId bgpPeerDown(1)
alarmClear(2)
GGSN
major(2)
minor(4)
info(8)
Below is an OID for the SER base MP-BGP alarm notification object:
ER
(2).ss gMIBNotification(0).ssg5000BGPAlarmNotification(39)

SNMP IKE Events

The detailed information of SER base SNMP IKE Events is given in
the following tables. Since the GGSN generates subscribers
dynamically, the subscriber name variable in the IKE events is the
local peer address of the IKE tunnel.
Table 9-133
SER Base SNMP IKE Tunnel Start Event

Function Severity
IKE INFO IKE tunnel starts The notification signals the

successfully with local start of IKE tunnel phase 1.
Address <ip_addr>,
remote Address
<ip_addr>, subscriber
name <sub_name>, SA
Id <id_number>, VPN Id
<id_number>, tunnel
life time <lifetime> and
cause code
<cause_code>.
Table 9-134 defines the SER base SNMP IKE Tunnel Start Event MIB
object.
Table 9-134
SNMP IKE Tunnel Start Event MIB Notification Object
MIB Variable Values

ssg5000TrapIKETunnelStartAl The Start Alarm ID.
armId
ssg5000TrapPeerLocalAddr The peer’s local IP address of the
IKE tunnel.
ssg5000TrapPeerRemoteAddr The peer’s remote IP address of
the IKE tunnel.
ssg5000TrapSubscriberName The peer’s local IP address of the
IKE tunnel.
ssg5000TrapIKESaId The Security Association ID
number.
ssg5000TrapIKEVPNId The VPN ID number
ssg5000TrapIKETunnelLifeTim Lifetime value of the IKE tunnel.
e

OA&M 9-223
MIB Variable Values

ssg5000TrapSSGHostAddress The address of the GGSN.
ssg5000TrapTrapSeverity critical(1)
major (2)
minor(4)
info(8)
Below is an OID for the SER base IKE Event notification object:
efix(2).ssgMIBNotification(0).ssg5000IKETunnelStartNotification(48)
Table 9-135
SER Base SNMP IKE Tunnel Stop Event

Function Severity
IKE INFO IKE tunnel stops with The notification signals the
local Address end of IKE tunnel phase 1.
<ip_addr>, remote
Address <ip_addr>,
subscriber name
<sub_name>, SA Id
<id_number>, VPN Id
<id_number>, tunnel
life time <lifetime> and
cause code
<cause_code>.
Table 9-136 defines the SER base SNMP IKE Tunnel Stop Event MIB
object.
Table 9-136
SNMP IKE Tunnel Stop Event MIB Notification Object
MIB Variable Values

ssg5000TrapIKETunnelStopAl The Stop Alarm ID.
armId
IKE tunnel.
the IKE tunnel.

MIB Variable Values

IKE tunnel.
number.
ssg5000TrapIKETunnelLifeTim Lifetime value of the IKE tunnel.
e
major (2)
minor(4)
info(8)
efix(2).ssgMIBNotification(0).ssg5000IKETunnelStopNotification(49)
Table 9-137
SER Base SNMP IKE Tunnel Not Established Event

Function Severity
IKE INFO IKE tunnel is not The notification signals

correctly established that phase 1 was not
with local address established for the IKE
<ip_address>, remote tunnel.
address <ip_address>,
tunnel name
<tunnel_name> and
cause code
<cause_code_number>
.
Table 9-138 defines the SER base SNMP IKE Tunnel Not Established
Event MIB object.

OA&M 9-225
Table 9-138
SNMP IKE Tunnel Not Established Event MIB Notification Object
MIB Variable Values

ssg5000TrapIKETunnelNotEst The IKE Not Established Alarm ID.
ablishedAlarmId
IKE tunnel.
the IKE tunnel.
IKE tunnel.
number.
major (2)
minor(4)
info(8)
efix(2).ssgMIBNotification(0).ssg5000IKETunnelNotEstablishedNotific
ation(50)
Table 9-139
SER Base SNMP IKE SA Peer Dead Event

Function Severity
IKE INFO IKE SA Peer Dead The notification signals

(<missed event that SA Peer was not
number> missed established for the IKE
events) tunnel.
SNMP IPSEC Events

The detailed information of SER base SNMP IPSEC Events is given in
the following tables.

Table 9-140
SER Base SNMP IPSEC Tunnel Start Event

Function Severity
IPSEC INFO IPsec tunnel starts The notification signals the
successfully with start of IPSEC tunnel phase
interface name 2.
<interface_name>,
tunnel name
<tunnel_name>,
subscriber name
<sub_name>, tunnel
life time
<lifetime_value>,
tunnel life size <size>
and cause code
<cause_code_value>.
Table 9-141 defines the SER base SNMP IPSEC Tunnel Start Event
MIB object.
Table 9-141
SNMP IPSEC Tunnel Start Event MIB Notification Object
MIB Variable Values

ssg5000TrapIPSECTunnelStar The Start Alarm ID.
tAlarmId
ssg5000TrapIPSECInterfaceNa The name provisioned on the
me GGSN for this interface.
ssg5000TrapIPSECTunnelNam The name provisioned on the
e GGSN for this tunnel.
ssg5000TrapSubscriberName Subscriber name
ssg5000TrapIPSECTunnelLife The IPSEC tunnel life time value.
Time
ssg5000TrapIPSECTunnelLife The IPSEC tunnel life size value.
Size
ssg5000TrapSSGHostAddress The IP address of the GGSN.
major (2)
minor(4)
info(8)

OA&M 9-227
Below is an OID for the SER base IPSEC Event notification object:
efix(2).ssgMIBNotification(0).ssg5000IPSECTunnelStartNotification(5
1)
Table 9-142
SER Base SNMP IPSEC Tunnel Stop Event

Function Severity
IPSEC INFO IPsec tunnel stops with The notification signals the
interface name end of IPSEC tunnel phase
<interface_name>, 2.
tunnel name
<tunnel_name>,
subscriber name
<sub_name> and
cause code
<cause_code_value>.
Table 9-143 defines the SER base SNMP IPSEC Tunnel Stop Event
MIB object.
Table 9-143
SNMP IPSEC Tunnel Stop Event MIB Notification Object
MIB Variable Values

ssg5000TrapIPSECTunnelStop The Stop Alarm ID.
AlarmId
ssg5000TrapIPSECInterfaceNa The name provisioned on the
me GGSN for this interface.
e GGSN for this tunnel.
ssg5000TrapSubscriberName Subscriber name
major (2)
minor(4)
info(8)

efix(2).ssgMIBNotification(0).ssg5000IPSECTunnelStopNotification(5
2)
Table 9-144
SER Base SNMP IPSEC Tunnel Not Established Event

Function Severity
IPSEC INFO IPsec tunnel is not The notification signals

correctly established that phase 2 was not
with local address established for the IPSEC
<ip_addr>, remote tunnel.
address <ip_addr>,
tunnel name
<tunnel_name> and
cause code
<cause_code_value>.
Table 9-145 defines the SER base SNMP IPSEC Tunnel Not
Established Event MIB object.
Table 9-145
SNMP IPSEC Tunnel Not Established Event MIB Notification Object
MIB Variable Values

ssg5000TrapIPSECTunnelNot The IPSEC Not Established Alarm
EstablishedAlarmId ID.
IKE tunnel.
the IKE tunnel.
e GGSN for this tunnel
major (2)
minor(4)
info(8)

OA&M 9-229
efix(2).ssgMIBNotification(0).ssg5000IPSECTunnelNotEstablishedNot
ification(53)
SNMP Traps
SNMP Authentication Failure Alarm
The detailed information of SNMP Authentication Failure Alarm is
Table 9-146
SER Base SNMP Authentication Failure Alarm
Shasta Alarm Alarm State SCS Client Alarm Alarm Description

Function Severity Text
Authentication MINOR alarmOccur Authentication The indicated Nortel

Failure Failure GGSN has received an
unauthenticated SNMP
request.
Below is an OID for the SNMP Authentication Failure notification

object:
iso(1).org(3).dod(6).internet(1).snmpV2(6).snmpModules(3).snmpMIB
(1).snmpMIBObjects(1).snmpTraps(5).authenticationFailure(5).
Event Logs 9
The event manager on the Nortel GGSN is used to report and log
events for the GGSN services and functions which includes:
• GGSN event logs

• SER base event logs
The event logs notification system is illustrated in Figure 9-11. Nortel
GGSN functional modules on the SSG generate events. Each event
has event number, log type, trap flag and event text attributes. The log
type is either INFORMATION, MINOR, MAJOR or CRITICAL. The
event manager uses the log type to determine where the log is sent.
The event logs destination is configured via the SCS GUI on a per
device basis. There are three possible destinations which are log files
on the GGSN local disk, the GGSN device console, and UNIX systems
(via UNIX SYSLOG messages). The event manager uses the trap flag
attribute to determine whether the event is also forwarded to the
SNMP Agent to generate an alarm.

Due to the significant impacts to the CPU utilization when writing all
event logs to the local disk, it is recommended that only event logs
with CRITICAL log type is sent to the log files on the local disk. The
SYSLOG utility is recommended to use for capturing event logs on a
remote server.
Figure 9-11
Nortel GGSN Event Management
log files
Nortel GGSN
Event Logs
(Event Number,
Log Type,
Trap Flag,
Event Text)
Functional Event SNMP
Module Manager Agent
sy
CII
slo
AS
Device Console SYSLOG Server
These event logs may be informational only, or they may be indicative

of an abnormal system condition requiring administrative action. For
those event logs requiring administrative action, it is recommended
that the event logs be sent to a SYSLOG Server. Processing within the
SYSLOG Server is beyond the scope of this document. Some of the
events requiring administrative action correspond to SNMP traps, in
which case, sending to a SYSLOG server is redundant. Other event
logs generated necessitate no particular administrative action, but may
be indicative of configuration errors, or may be useful for
troubleshooting if captured on a Device Console or a SYSLOG Server.
If SYSLOG monitoring is to be performed, it is important to note that

the event numbers reported to SYSLOG are not unique. Event content
as well as event number must both be used in order to categorize
events.

OA&M 9-231
The Subscriber Service Logs on the Logs Manager window via SCS
GUI is not supported by the Nortel GGSN. Displaying the service logs
would impact the system performance greatly.
GGSN Event Logs

GTP Tunnel Event Logs
The event logs related to GTP tunnel are detailed in Table 9-147
Table 9-147
GTP Tunnel Event Logs
Event SysLog Disk & Event Text Event Description

Number Event Console
Severity Log Event
Severity
1 INFO INFO GTP Tunnel on ISP GTP Tunnel creation has

ispName Context been disabled for the
Creation Disabled GGSN.
2 CLEAR CLEAR GTP Tunnel on ISP GTP Tunnel creation was

ispName Context Disabled, now Enabled
Creation Disabled
3 INFO INFO APN apnName on ISP An APN is

ispName Disabled administratively Disabled
for the GGSN (will not
accept new context
creation).
4 CLEAR CLEAR APN apnName on ISP An APN that was Disabled

ispName Disabled is now Enabled.
5 MINOR MINOR APN apnName (ISP Configured session limit

ispName): APN session has been exceeded for the
limit exceeded (Limit: APN & ISP specified.
apnLimit)
6 CLEAR CLEAR APN apnName (ISP The number of active

ispName): APN session sessions using the APN &
limit exceeded (Limit: ISP specified has dropped
apnLimit) below the configured limit
for that APN.
7 MINOR MINOR <gtp> has dropped <total This event is generated

number> of create when the system overload
request due to <total is detected.
number> of pending
subscriber requests.


Severity Log Event
Severity
8 MINOR MINOR <gtp> APN: <apn name> The APN profile

Session Mode enabled, associated with the call
but no wrapmgr is has its Session Mode flag
provisioned. set while its application
server profile field
remains blank.
9 MINOR MINOR <gtp> APN: <apn name> For each wireless

Session Mode enabled application call in session
and no response from mode, GGSN sets a timer
the Application Server: for the application server
<application server response. This event is
profile name>. generated upon the expiry
of the timer.
10 MINOR MINOR <gtp> APN: <apn name> The WAP session can’t be
Session Mode enabled established because of an
and the WAP session invalid response (such as
could not be established incorrect authenticator
on Application Server: value) received from the
<application server application server or
profile name>. insufficient internal
resource available.
11 MINOR MINOR <gtp> VPN Name: An invalid VPRN name

<vpn_name> invalid for was returned, i.e. the
APN: <apn>, Subscribe: VPRN name is not
<subscriber_name> on provisioned within the
RADIUS Server: VPRN Manager
<radius_server_name>
<gtp>.
12 MINOR MINOR <gtp> Service Profile: An invalid Service Profile

<service_profile> invalid was returned, i.e. the
for APN: <apn>, Service Profile was not
Subscribe: configured within the
<subscriber_name> on Service Policy Manager
RADIUS Server:
<radius_server_name><
gtp>
13 MINOR MINOR <gtp> Resource TBD

Overload - LOM returned
Invalid error code for
<err> request.

OA&M 9-233

Severity Log Event
Severity
14 MINOR MINOR <gtp> Aggregation A single APN VPN VSA

session rejected was returned from
because Single-APN RADIUS Server. This
VSAs returned from functionality is not
Radius. APN: <apn>, supported on Aggregation
MSISDN: <msisdn>, sessions.
EUA: <eua>
15 MINOR MINOR <gtp> Aggregation Aggregation Session

session rejected rejected due to
because subnet unavailability of subnet
dedication was not dedication
possible.APN:<apn>,
MSISDN: <msisdn>,
EUA: <eua>
16 MINOR MINOR <gtp> Aggregation Aggregation session was

session rejected rejected due to
because it would require requirement of individual
sub-specific route route advertisement.
advertisement. APN:
<apn>, MSISDN:
<msisdn>, EUA: <eua>
session rejected rejected due to feature set
because APN is provisioned on an
configured with non- aggregation APN.
aggregation features.
APN: <apn>, MSISDN:
<msisdn>, EUA: <eua>,
Features: <string>
18 MINOR MINOR <gtp> Aggregation A static IP address was

session rejected received in the CREATE
because a static IP PDP CONTEXT REQUEST
address appeared in the message.
create request. APN:
<apn>, MSISDN:
<msisdn>, EUA: <eua>


Severity Log Event
Severity

session rejected rejected due to failure in
because of transient SSP subnet programming
failure effect (subnet join
failed). APN: <apn>,
MSISDN: <msisdn>,
EUA: <eua>

session rejected/deleted rejected because of
because QoS IE required feature set assigned to
IP services. APN: <apn>, QoS level.
MSISDN: <msisdn>,
EUA: <eua>, Operation:
<string>
21 MAJOR MAJOR <gtp> Hash table TBD

Memory: <hash_index>
PDPTypeNumber:
<pdpd_type>
22 MINOR MINOR No Dynamic L2TP VPN The Subscriber was set to

Tunnel Attributes use a Dynamic L2TP VPN,
returned for APN:%s but no tunnel attributes
Subscriber:%s on were returned from the
Radius Server:%s radius server.
23 MINOR MINOR WARNING: Invalid Tariff Invalid Tariff Profile

Profile <profile_name>
for MSISDN
<msisdn_name>
24 MINOR MINOR WARNING: Access Access Control Profile

Control Profile rejection rejection
for MSISDN <msisdn>
IMSI <imsi> on APN
<apn> on ISP <isp>
Operation <Access
Control Profile
Rejection>
25 INFO INFO Access Control Profile The Access Control
<profile> is associated Profile is associated with
with APN <apn> on ISP the APN
<isp>

OA&M 9-235

Severity Log Event
Severity
26 INFO INFO Access Control Profile The Access Control

<profile> is dissociated Profile is disassociated
with APN <apn> on ISP with the APN
<isp>
27 MAJOR MAJOR <gtp> Software error: Software error is detected

<error_title> (<error test in GTP subsystem
string>: <error_code>)
28 CRITICAL CRITICAL <gtp subsystem> <error A potentially service

text string> affecting error has
occurred in GTP software
subsystem.
29 MAJOR MAJOR < The GGSN is removing

EchoReqTimerCallback sessions as a result of
> : (Missed N3 Echo echo responses not being
Responses from SGSN received from an SGSN.
<SGSN ID>).
32 INFO INFO <gtp> SSM Redundancy This log is generated as

Processing Started at SSM redundancy starts
<Date+time>: Moving for Aggregation and non-
<Aggregation/non- Aggregation APNs.
Aggregation> sessions
from failed SSM. This log is always
generated for non-
Aggregation calls as the
redundancy is always ON
and even if there are no
calls are established.
On the other hand, for

Aggregation this log is
generated only if the SSM
Redundancy for
Aggregation feature is
enabled and calls have
been established.


Severity Log Event
Severity
33 INFO INFO <gtp> SSM Redundancy This event log is

Processing Completed at generated as the SSM
<Date+time>: redundancy is completed
<Aggregation/non- for <Aggregation/non-
Aggregation> Sessions Aggregation> APNs.
moved from failed SSM.
The log is always
generated for non-
Aggregation sessions,
even if no non-
Aggregation sessions
moved.
On the other hand, for

Aggregation this log is
generated only if the SSM
Redundancy for
Aggregation feature is
enabled and call moves
had been initiated.
34 INFO INFO <gtp> SSM Redundancy This log is generated as

Processing Started at the SSM redundancy
<Date+time>: Moving starts during recovery of a
<non-Aggregation> failed SSM. It is generated
sessions to the original only for the non-
SSM Aggregation APNs as the
sessions are moved to the
original SSM.
35 INFO INFO <gtp> SSM Redundancy This event log is

Processing Completed at generated as the SSM
<Date+time>: non- redundancy is completed
Aggregation Sessions for the recovered SSM. It
moved to the original is generated only for the
SSM. non-Aggregation APNs.
36 INFO INFO SSM Redundancy for This event log is
Aggregation is <Enabled/ generated as SSM
Disabled>. Redundancy for
Aggregation is enabled or
disabled from SCS.

OA&M 9-237

Severity Log Event
Severity
37 MAJOR MAJOR APN <apn-name> on ISP The number of

<isp-name> has crossed consecutive PDP context
the threshold value failures have raised at or
<Threshold Value> and above the threshold value
has been blacklisted. for the APN.
38 CLEAR CLEAR APN <apn-name> on ISP The APN is back-in

<isp-name> has crossed service after the
the threshold value configured blackout
<Threshold Value> and period expires.
has been blacklisted.
39 INFO INFO Failed to apply dynamic Failed to apply dynamic

charging rules for charging rules for a
MSISDN <msisdn> context. This event log is
NSAPI <nsapi> on APN throttled to prevent
<apn> on ISP <isp> excessive logs being
generated, 10 event logs
per minute.
40 MINOR MINOR Missed N3 Echo Failed to receive Echo

Responses from RNC %s Responses after N3*T3
[tmpIp]. Contexts timeout.
associated with the RNC
are waiting for Update
Request from SGSN.
41 INFO INFO Idle Verification deletion: This event log is

IMSI %s [imsi], NSAPI generated during context
%d [nsapi], APN %s deletion due to Idle
[apn_name], SGSN %s Verification Update
[sgsn_addr], cause %d request receiving a
[cause], Session Idle response other than
Time %d Request Accepted.
[sess_idle_time]
42 INFO INFO Take down of Hung This event log is

session: MSISDN generated when a Hung
<msisdn>, NSAPI session is deleted.
<nsapi>, TIMESTAMP
<Date+time>, STATE
<state>


Severity Log Event
Severity
43 INFO INFO Service Package not This log is generated

found, svcpkg_id = when there is a service
<service package id>, package data mismatch
merge_id = <merge id> between GTP Manager
name = <name> and Subscriber Manager.
It is generated only for
Aggregation APNs. When
this event is logged, the
customer should reload
the GGSN or else calls can
not be brought up.
GTP Accounting Event Logs

The event logs related to GTP accounting are detailed in Table 9-148
Table 9-148
GTP Accounting Event Logs

Severity Log Event
Severity
5 MINOR MINOR CGF cgfServerName on CGF Failed for the

ISP ispName FAILED specified CGF server and
ISP.
6 CLEAR CLEAR CGF cgfServerName on CGF restored for the

ISP ispName FAILED specified CGF server and
ISP.
7 CRITICAL CRITICAL NO CGF AVAILABLE on CGFs configured on the

ISP ispName Gn ISP are not
responding.
8 CLEAR CLEAR NO CGF AVAILABLE on CGF configured on the Gn

ISP ispName ISP are responding.
9 INFO INFO CGF <cgfid> on ISP CGF is ALIVE

<ispid> ALIVE
10 MINOR MINOR CGF <cgfid> on ISP CGF is going OFFLINE
<ispid> OFFLINE
11 INFO INFO CGF <cgfid> on ISP Switch of activity occurred

ispName is SWACTED for primary and secondary
CGFs.

OA&M 9-239

Severity Log Event
Severity
12 INFO INFO GCDR Auditing enabled G-CDR Auditing enabled

on ISP <ispid>
13 INFO INFO GCDR Auditing G-CDR Auditing disabled

disabled on ISP <ispid>
14 INFO INFO FTP enabled on ISP FTP for G-CDR auditing

<ispid> enabled
15 INFO INFO FTP disabled on ISP FTP for G-CDR auditing

<ispid> disabled
16 CRITICAL CRITICAL <gtp_acct subsystem> A potentially service affecting
<error text string> error has occurred in GTP-
accounting software
subsystem.
17 MINOR MINOR <gtp_acct subsystem> A recoverable but

<warning text string> unexpected event has
occurred in GTP-accounting
software subsystem.
18 INFO INFO G-CDR transfer Indicates that the GCDR

initiated <Transfer transfer was initiated.
Mode = “Transfer
Mode”> Transfer Mode indicates if
the transfer was initiated
by the CLI command or by
the SCS configuration
19 INFO INFO G-CDR transfer Indicates that the GCDR
stopped <Transfer transfer was stopped.
Mode = “Transfer
Mode”> <Reason = Transfer Mode indicates if
“Reason”> the transfer was stopped
by the CLI command or by
the SCS configuration
Reason indicates the

reason why it was stopped
FTP Service Event Logs

The event logs related to FTP service are detailed in Table 9-149

Table 9-149
FTP Service Event Logs

Severity Log Event
Severity
1 MINOR MINOR Unable to connect to One FTP server used for
FTP server G-CDR auditing is down.
ftpServerName on
isp ispName
2 CLEAR CLEAR Unable to connect to An FTP server used for

GTPP audit FTP G-CDR auditing is
server reachable.
ftpServerName on
ISP ispName
3 CRITICAL CRITICAL All of the All FTP servers used

provisioned FTP for G-CDR auditing are
servers are down, down.
audit files will remain
on disk on isp
ispName
4 CLEAR CLEAR All GTPP audit FTP An FTP Server used

servers are down on for G-CDR auditing is
ISP ispName up.
RADIUS Accounting Event Logs

The event logs related to RADIUS accounting are detailed in Table 9-
150
Table 9-150
RADIUS Accounting Event Logs

Number Event Console log
Severity Event
Severity
13 CRITICAL CRITICAL RADIUS error writing Error occurred when

records to disk. writing RADIUS accounting
record to disk.
14 CLEAR CLEAR RADIUS error writing Disk error resolved for

records to disk. RADIUS.

OA&M 9-241

Severity Event
Severity
15 MAJOR MAJOR ISP <isp> RADIUS Profile Could not contact any
<profile> Cannot contact RADIUS server for the
RADIUS server. Writing specified RADIUS profile.
to disk.
16 CLEAR CLEAR ISP ispName RADIUS Able to contact a RADIUS

Profile server for the specified
radiusProfileName RADIUS profile.
Cannot contact RADIUS
Server. Writing to disk.
17 CRITICAL CRITICAL ISP ispName APN RADIUS profile not

apnName no RADIUS configured for the ISP and
profile. APN and RADIUS
Accounting option is
chosen.
18 CRITICAL CRITICAL ISP ispName RADIUS No Accounting server
Profile provisioned and RADIUS
radiusProfileName APN Accounting option is
apnName no RADIUS chosen.
server.
19 CRITICAL CRITICAL ISP ispName RADIUS No Primary Accounting

Profile Server specified and
radiusProfileName APN RADIUS Accounting
apnName no primary Option is chosen.
RADIUS Server Present.
20 CRITICAL CRITICAL RADIUS Accounting Memory shortage while

could not generate generating a Accounting
record due to lack of message.
memory.
21 MINOR MINOR Acct-Off timed out for GGSN couldn't get the
Radius server <server> response for RADIUS Acct
in profile <profile> OFF message after
configured number of
retries on the profile.


Severity Event
Severity
22 MINOR MINOR Address Pool <pool There are some GTP

name> deletion failed for sessions using the address
ISP <isp name> pool that AAA Manager is
(<error_string>) trying to delete and can not
invoke take down on these
sessions by sending a
request to GTP Manager.
This is very unlikely
scenario.
23 MAJOR MAJOR ISP <isp name> RADIUS RADIUS Authentication

Profile <radius_profile> server is unreachable
can Not contact RADIUS
Authentication server
24 CLEAR CLEAR ISP <isp name> RADIUS RADIUS Authentication

Profile <radius_profile> server is reachable
can Not contact RADIUS
Authentication server
Prepaid Service Event Logs

The event logs related to Prepaid service are detailed in Table 9-151

OA&M 9-243
Table 9-151
Prepaid Service Event Logs

Severity Log
Event
Severity
1 CRITICAL CRITICA NO SCP AVAILABLE on SCP server(s) configured
L ISP ispName Tariff Profile in the Tariff Profile on ISP
tariffProfileName is not reachable.
2 CLEAR CLEAR NO SCP AVAILABLE on SCP server(s) is

ISP ispName Tariff Profile reachable.
tariffProfileName
3 MINOR MINOR Prepaid CTP invalid IE One of the IEs in the CTP
<Tariff Profile Name = message was incorrectly
“profile name”> <IE Name formatted. Either it was
= “ie name”> <Field Name not possible to decode, or
= “field name”> <Field an invalid value was
Value = “value”> included in one of the IE
fields.
Disk Capacity Event Logs

The event logs related to Disk Capacity are detailed in Table 9-152.
Table 9-152
Disk Capacity Event Logs

Severity Log Event
Severity
1 INFO INFO NORMAL: <disk A Disk Capacity
name> is Normal event is
<occup>% full. generated when the
disk space on the
CMC card is 64% or
less full.
Downgraded is
added to event text
if the event is
generated due to
increase in disk
space.


Severity Log Event
Severity
2 MAJOR MAJOR WARNING: A Disk Capacity

<devname> is Major event is
disk space on the
CMC card is 65% -
71% full.
Downgraded is
added to event text
if the event is
generated due to
increase in disk
space.
3 CRITICA CRITICAL CRITICAL: A Disk Capacity

L <devname> is Critical event is
disk space on the
CMC card is 72% or
more full.
4 INFO INFO Writing to disk This event is

allowed. Disk generated when the
spacefree=<free>K, available disk
reserved= space on the CMC
<reserved>K card is more than
total=<total>K, the reserved disk
space (for
coredump plus the
safety margin of
other critical data).

OA&M 9-245

Severity Log Event
Severity
5 CRITICA CRITICAL Writing to disk This event is

L stopped. Disk generated when the
space available disk
total=<total>K, space on the CMC
free=<free>K, card is less than the
reserved= reserved disk space
<reserved>K (for coredump plus
the safety margin of
other critical data).
When this event is
logged, the
customer should
perform the
necessary disk
space recovery
actions, such as
deleting old core
files.
If the available disk space is lesser or equal to the reserve disk space,
GTP billing and Radius accounting records won't be saved to the disk.
Two new events will be logged depending on the status of the disk:
• “Writing to disk stopped. Disk space total=<t>K, free=<f>K,

reserved=<r>K.”
• “Writing to disk allowed. Disk space total=<t>K, free=<f>K,
reserved=<r>K.”
The first event will be logged if the available disk space goes under the
reserve space threshold. The value of 'free' in the event message is
less than or equal to the value of 'reserved' space in kilobytes.
The second event will be logged if the available disk space goes over
the reserve space threshold. The value of 'free' in the event message
is greater than the value of 'reserved' space in kilobytes.
The customer is advised that if disk utilization crosses the critical

threshold of 72% that the event logs should also be monitored if the
“Writing to disk stopped.” event was also logged, and to perform the
necessary disk space recovery actions, such as deleting old core files.

If a Standby CMC is available all the disk capacity event logs would be
generated on the standby CMC as well. But the corresponding SNMP
trap is not generated for the standby CMC.
WAP Service Event Logs

The event logs related to WAP service are detailed in Table 9-153
Table 9-153
WAP Service Event Logs

Number Event Console Log
Severity Event
Severity
1 CRITICAL CRITICAL Application Server Application server is not

appServerName on ISP responding to
ispName no response Accounting START/
within threshold INTERIM UPDATE/STOP
requests and the total of
these unacknowledged
requests has hit the
threshold provisioned in
the corresponding
application server profile.
2 CLEAR CLEAR Application Server Application server

appServerName on ISP responding again.
ispName no response
within threshold
3 CRITICAL CRITICAL Application Server Application server does
appServerName on ISP not respond to
ispName failed to activate Accounting ON/OFF
requests.
4 CLEAR CLEAR Application Server Application server

appServerName on ISP responding to
ispName failed to activate accounting requests.
Lawful Interception Event Logs

The event logs related to Lawful Interception are detailed in Table 9-
154

OA&M 9-247
Table 9-154
LI Event Logs

Severity Log
Event
Severity
1 MAJOR MAJOR ADMF Link Down TCP connection to the ADMF

is down.
2 CLEAR CLEAR ADMF Link Down TCP connection to the ADMF

is up.
3 MAJOR MAJOR DF Links Down: TCP connection to DF(s) is

numDfLinksDown down.
4 CLEAR CLEAR DF Links Down: TCP connections to all DFs

numDfLinksDown are up.
A 5-minute timer is started

when the alarm is raised. The
alarm clears only after the
timer expires and the TCP
connections to all DFs are up.
Otherwise, the alarm remains
raised and the timer is
restarted.
Overload Control Event Logs

The event logs related to Overload Control are detailed in Table 9-155
and Table 9-156.
Table 9-155
Overload LOM Event Logs
Event Log Type Disk & Event Text Event Description

Number Console Log
Event Severity
1 INFORMATION INFORMATIO RM OVLD Node- This event is
N <node> Level-<level> generated when an
with occupancy <%> overload transition
occurs for CPU
Total resource.


Number Console Log
Event Severity
2 MINOR MINOR RM OVLD Node- This event is

<node> Level-<level> generated when an
occurs for CPU
Total resource.
3 MAJOR MAJOR RM OVLD Node- This event is

occurs for CPU
Total resource.
4 CRITICAL CRITICAL RM OVLD Node- This event is

occurs for CPU
Total resource.
5 INFORMATION INFORMATIO RM OVLD INTERRUPT This event is

N Node-<node> Level- generated when an
<level> with overload transition
occupancy <%> occurs for CPU
Interrupt resource.
6 MINOR MINOR RM OVLD INTERRUPT This event is

Node-<node> Level- generated when an
Interrupt resource.
7 MAJOR MAJOR RM OVLD INTERRUPT This event is

Interrupt resource.
8 CRITICAL CRITICAL RM OVLD INTERRUPT This event is
Interrupt resource.
9 INFORMATION INFORMATIO RM OVLD MEMORY This event is

N Node-<node> Level- generated when a
<level> with <num> memory overload
MB free memory and transition occurs
with fragmentation for a given CPU.
better than <num> KB

OA&M 9-249

Number Console Log
Event Severity
10 MINOR MINOR RM OVLD MEMORY This event is

Node-<node> Level- generated when a
11 MAJOR MAJOR RM OVLD MEMORY This event is

12 CRITICAL CRITICAL RM OVLD MEMORY This event is

Table 9-156
Overload COM Event Logs

Number Console
Log Event
Severity
1 INFORMATI INFORMATI Overload: Notifications This event is used to
ON ON for application report the status of
<application> have been registered
<status>. applications.
ISP Manager Event Logs

The event logs related to ISP manager are detailed in Table 9-157.

Table 9-157
Event SysLog Event Disk & Event Text Event Description

Number Severity Console Log
Event Severity
8 CRITICAL CRITICAL ISP ispName ISP operational state is

Down down. No traffic can be
sent from Gn->Gi for this
ISP
9 CLEAR CLEAR ISP ispName ISP operational state was

Down Down, is now UP.
10 CRITICAL CRITICAL Add ISP ispName Attempt to add an ISP

failed failed. ISP was not
created.
11 MAJOR MAJOR Address Pool An address pool

<pool_name> activation failed alarm is
activation failed generated when routing
for isp <Isp code fails to add summary
Name> (<error route to the pool. This is
string>) very unlikely scenario
12 INFORMATIO INFORMATIO <isp> TPO Packets are to be sent to

N N Configuration the TPO but the TPO ISP
mismatch: is not configured
Missing TPO ISP
configuration
Log Throttler Event Logs

A throttling mechanism is implemented for gtp and gtp-accounting to
control the number of event logs generated. This does not impact the
system capacity. The throttling of error and warning logs are done at
the following two levels:
Global throttle Rate Limit: This restricts the maximum number of GTP
and GTP Accounting event logs generated per minute. By default this
limit is set to 100 logs/minute.
Per Subsystem Throttle Rate Limit: GTP and GTP Accounting modules
are subdivided into multiple subsystems. This limits the maximum
number of error and warning logs generated per subsystem of GTP
and GTP Accounting. The per subsystem throttle rate is 10 error logs
and 5 warning logs per minute.
The system checks the number of throttled logs every minute and
generates a Warning Event log at console to report the number of logs

OA&M 9-251
throttled The throttling report is generated only if the logs are throttled.
The parameters of throttling functionality survives system reboots.
Example of a throttled error log:
14-Aug-2003 10:43:11 14/1/1:gtp,0: 28, 1, CRITICAL,

GTP_DBG_PARSE: New NSAPI Does not match the previous one
New/Old = 5/0
Example of a throttled warning log:
14-Aug-2003 10:45:02 14/1/1:gtp,0: 29, 1, WARNING,

GTP_DBG_CREATE: <handle_ES_createReq> Duplicate Secondary
Create Req Failed, sending response cause = 201
The event logs related to Log Throttler are detailed in Table 9-158.
Table 9-158
Log Throttler Event Logs

Severity Log Event
Severity
9 MINOR MINOR <dbgmgr> Application Print out a report of
Logs Throttled <report of number of error/
throttled logs> warning logs throttled
per subsystem for GTP
and GTPP.
10 MAJOR MAJOR <dbgmgr> <Throttler error An unexpected error

string> occurred in throttling
subsystem.
Memory Trampler Detection Event Logs

The GGSN memory management system is capable of detecting
trampling of memory-blocks on memory pools. On detecting memory
trampling, the event log listed below gets generated. If such logs are
seen, Nortel personnel should be notified.

Table 9-159
Memory Trampler Detection Event Logs

Severity Log Event
Severity
7 CRITICAL CRITICAL <iSOS> Memory Prints out details of

trampling detected in the task where
task <taskname> tid: memory trampling was
<task-id> detected, along with a
stack-trace. This log
<stack-trace> gives the memory
block details and the
memory pool details.
Also prints out a hex-
dump of the memory
block header and of
the data stored in the
block.
Example:
07-Aug-2003 17:23:01 14/1/1:iSOS,0: 7, 1, CRITICAL,
Memory trampling detected in task concli tid: 24890cc8
Stack Trace:
Memory Audit Event Logs

The event logs related to the Memory Audit are detailed in Table 9-160
Table 9-160
Memory Audit Event Logs
Event SysLog Event Disk & Console Event Text Event Description
Number Severity Log Event
Severity
1 INFORMATIO INFORMATION Memory Leak This event is

N detected. Mod:%d generated when a
Instance:%d memory leak has
memory type:%d been detected.
count:%d

OA&M 9-253
Event SysLog Event Disk & Console Event Text Event Description
Severity
2 INFORMATIO INFORMATION Audit running too This event is

N long. task name:%s generated when an
start_time=%02d:%0 audit has been
2d:%02d. running too long.
Patching Event Logs

This section describes event logs that are related to patching.
Table 9-161
Patching Event Log
Event SysLog Disk & Event Description

Severity Log Event
Severity
1 INFO INFO OK to apply profile
2 INFO INFO Attempt to verify an already active
profile
3 INFO INFO Insufficient memory for profile
4 MINOR MINOR Download failure (to device)
5 INFO INFO Patch applied
6 INFO INFO Unapplied Patch
Attention: This event log is obsolete

and no longer generated by the GGSN.
Please see event log 22 below for the
"Patch Unapplied" event log.
7 INFO INFO Patch activated
8 INFO INFO Patch deactivated
9 INFO INFO Prerequisite check failure
10 INFO INFO Mutual exclusion check failure
11 INFO INFO Applying a patch which is already
applied
12 INFO INFO Unapply a patch which is already
unapplied
13 INFO INFO Failed to load patch
14 INFO INFO Internal error: max jump distance
exceeded
15 INFO INFO Patch does not exist
16 MINOR MINOR Patch partition now has less than
100K of memory

Event SysLog Disk & Event Description

Severity Log Event
Severity
17 MINOR MINOR Patch partition now has less than
50K of memory
18 INFO INFO Failed to apply patch because
there is not enough memory in the
patch partition.
19 INFO INFO Possible corrupt patch file
20 INFO INFO Patch operation blocked
21 INFO INFO Download failure (to target)
22 INFO INFO Patch unapplied
23 MAJOR MAJOR Target Patcher registration failed.
24 MAJOR MAJOR Patch status out of sync
25 CLEAR CLEAR Patch Status in sync
26 MAJOR MAJOR Unable to mirror patch to standby
cmc.
27 INFO INFO Successfully mirrored patch to
standby cmc.
28 INFO INFO TFTP download is started
29 INFO INFO TFTP download is stopped
30 INFO INFO Patch profile verification started
31 INFO INFO Patch profile verification
completed
32 INFO INFO Patch profile verification failure
33 INFO INFO Applying patch profile
34 INFO INFO Applied patch profile
35 INFO INFO Unapplying patch profile
36 INFO INFO Unapplied patch profile
37 INFO INFO Patching initialization completed
for processor
38 INFO INFO Information on patch profile
39 INFO INFO Information on patchable memory
OK to apply profile
OK to apply profile log is generated when the user requests to verify
that a profile can be applied. A series of checks are made on the SSG
to determine that the profile will successfully apply. If all checks pass,
this log is generated.

OA&M 9-255
Example:
07-Feb-2008 03:26:46 14/1/1:patchmgr,0: 1, 1, INFO, OK to apply

profile MyProfile.
Action:
No action required.
Attempt to verify an already active profile

An attempt to verify a profile which is already the active profile is an
invalid operation.
Example:
07-Feb-2008 03:26:47 14/1/1:patchmgr,0: 2, 1, INFO, Attempt to

verify profile MyProfile, which is already the active profile.
Action:
No action required.
Insufficient memory for Profile

When there is insufficient memory to apply the profile, this log is
generated.
Example:
07-Feb-2008 03:26:47 14/1/1:patchmgr,0: 3, 1, INFO, There is

insufficient memory to apply profile MyProfile.
Action:
If this profile is needed, the user should first unapply the current profile
(if any) and resync the device. Once the resync is complete, the
desired profile can then be applied.
Download Failure (to device)

This log occurs when a patch fails to download to the SSG.

Example:
07-Feb-2008 03:26:47 14/1/1:patchmgr,0: 4, 1, MINOR, There was a
failure when downloading patch Q000123456.
Action:
Perform a patch sync.
Patch Applied
This is an informational log that records a patch has been successfully
applied.
Example:
07-Feb-2008 03:26:48 14/1/1:patchmgr,0: 5, 1, INFO, Applied

patchid Q000123456.
Action:
No action required.
Patch Activated
activated.
Example:
07-Feb-2008 03:26:49 14/1/1:patchmgr,0: 7, 1,

INFO, Activated patchid Q000123456.
Action:
No action required.
Patch Deactivated
deactivated.

OA&M 9-257
Example:
07-Feb-2008 03:27:31 14/1/1:patchmgr,0: 8, 1, INFO, Deactivated patchid

Q000123456.
Action:
No action required.
Prerequisite Check Failure

A prerequisite failure log is generated when a patch is applied out of
order.
Example:
07-Feb-2008 03:27:31 14/1/1:patchmgr,0: 9, 1, INFO,

Prerequisite check failed when trying to unapply patch
Q000123456.
Action:
Mutual Exclusion Check Failure

A mutual exclusion failure log may be generated when the SCS and
SSG are out of sync.
Example:
07-Feb-2008 03:27:46 14/1/1:patchmgr,0: 10, 1, INFO, Mutual

exclusion check failed when trying to apply patch Q000123456.
Action:
Applying a patch which is already applied.

This log informs the user that a patch they attempted to apply was
already applied.

Example:
07-Feb-2008 03:27:46 14/1/1:patchmgr,0: 11, 1, INFO, Attempted

to apply patch Q000123456, but it was already applied.
Action:
No action required.
Unapply a patch which is already unapplied.

This log informs the user that a patch they attempted to unapply was
already unapplied.
Example:
07-Feb-2008 03:27:46 14/1/1:patchmgr,0: 12, 1, INFO, Attempted

to unapply patch Q000123456, but it was already unapplied.
Action:
No action required.
Failed to load patch

This log implies that the patch may be corrupt, or the patching
software could not properly decode it.
Example:
07-Feb-2008 03:27:46 14/1/1:patchmgr,0: 13, 1,
INFO, Failed to load patch Q000123456.
Action:
Report the log to Nortel Support.
Internal error. Max jump distance exceeded.

This log implies that the patch may be corrupt, or the patching
software could not properly decode it.

OA&M 9-259
Example:
Internal error. Max jump distance exceeded when
attempting to apply patch Q000123456.
Action:
Report the log to Nortel Support.
Patch does not exist.

This log is generated when an operation is performed on an unknown
patch.
Example:
07-Feb-2008 03:28:00 14/1/1:patchmgr,0: 15, 1, INFO, Patch

Q000123456 does not exist.
Action:
Patch partition now has less than 100K of memory.

This log is generated when the available patch memory drops below
100 kilobytes (100KB). It is only generated once.
Example:
07-Feb-2008 03:28:01 14/1/1:patchmgr,0: 16, 1, MINOR, Patch

partition now has less than 100K of memory.
Action:
No action required.
Patch partition now has less than 50K of memory.

This log is generated when the available patch memory drops below
50 kilobytes (50KB). It is only generated once.

Example:
07-Feb-2008 03:28:01 14/1/1:patchmgr,0: 17, 1, MINOR, Patch

partition now has less than 50K of memory.
Action:
No action required.
Failed to apply patch because there is not enough memory in the

patch partition.
This log occurs when the memory available for patches has run out.
Example:
07-Feb-2008 03:28:01 14/1/1:patchmgr,0: 18, 1, INFO, Failed
to apply patch Q000123456 because there is not enough memory
in the patch partition.
Action:
Resync the device.
Possible corrupt patch file

The patch may have been corrupted during transfer.
Example:
07-Feb-2008 03:28:24 14/1/1:patchmgr,0: 19, 1,

INFO, Possible corrupt patch file for patchID
Q000123456.
Action:
Remove the patch from the profile. Add the patch back into the profile.
Patch operation blocked

The patching software was too busy to handle the requested
operation.

OA&M 9-261
Example:
07-Feb-2008 03:28:24 14/11:patchmgr,0: 20, 1,
INFO, Patch operation blocked because the target
patcher is busy.
Action:
Wait a few minutes. Perform a patch sync.
Download Failure (to target)

The patch file failed to reach the target processor.
Example:
07-Feb-2008 03:28:24 14/1/1:patchmgr,0: 21, 1, INFO, Failed to

download patch file for Q000123456 to target.
Action:
Patch Unapplied
unapplied.
Example:
07-Feb-2008 03:28:25 14/1/1:patchmgr,0: 22, 1, INFO, Unapplied

patchid Q000123456.
Action:
No action required.
Target patcher registration failed

This event log is generated to inform the user that, the processor has
failed to register with the patch manager.

Example:
07-Feb-2008 03:28:37 14/1/1:patchmgr,0: 23, 1, MAJOR, Target

Patcher registration failed.
Action:
No action required.
Patch status out of sync

This event log informs the user that, the patch is out of sync with a
specific processor.
Example:
07-Feb-2008 04:19:49 14/1/1:patchmgr,0: 24, 1, MAJOR, Patch

status Out of Sync, slot 2 card type 2, port 3 proc 3
Action:
No action required.
Patch status in sync

This event log informs the user that, the patch is in sync with a specific
processor.
Example:
07-Feb-2008 03:28:38 14/1/1:patchmgr,0: 25, 1, CLEAR, Patch status
in Sync, slot 2 card type 2, port 3 proc 3
Action:
No action required.
Unable to mirror patch to standby CMC

This event log informs the user that one or more files of the patch did
not get mirrored to standby cmc.

OA&M 9-263
Example:
07-Feb-2008 03:28:38 14/1/1:patchmgr,0: 26, 1, MAJOR, Unable to

mirror patch Q000123456 to standby cmc.
Action:
No action required.
Successfully mirrored patch to standby CMC

This event log informs the user that all files for this patch were
successfully mirrored to standby cmc.
Example:
07-Feb-2008 03:28:47 14/1/1:patchmgr,0: 27, 1, INFO, Successfully

mirrored patch Q000123456 to standby cmc.
Action:
No action required.
TFTP download started

This event log indicates that the patchmgr has started downloading the
patches in the patch profile.
Example:
07-Feb-2008 03:28:47 14/1/1:patchmgr,0: 28,
1, INFO, TFTP download started for profile
MyProfile.
Action:
No action required.
TFTP download stopped

This event log indicates that the patchmgr has downloaded all the
available patches in the patch profile.

Example:
07-Feb-2008 03:28:48 14/1/1:patchmgr,0: 29,

INFO, TFTP download stopped for profile MyProfile.
Action:
No action required.
Patch profile verification started

This event log indicates that the patchmgr has started verifying the
profile.
Example:

Verifying patch profile MyProfile.
Action:
No action required.
Patch Profile Verification Completed

An event log is generated when the profile verification is completed.
Example:

Verifying patch profile G501 completed.
Action:
No action required.
Patch Profile Verification Failure

OA&M 9-265
When there is insufficient memory to apply the profile or when a patch

fails to download or when buffer cannot be allocated for downloading
the patch for verification, this event log is generated.
Example:
07-Feb-2008 00:10:34 14/1/1:patchmgr,0: 32, 1, INFO, Cannot apply
profile MyProfile.
Action:
Perform a GGSN resync.
Applying Patch Profile

This event log informs that the patchmgr has started applying the
patches in the profile.
Example:
07-Feb-2008 09:47:38 14/1/1:patchmgr,0: 33, 1, INFO, Applying

patch profile MyProfile.
Action:
No action required.
Applied Patch Profile

This event log informs that all the patches in the profile are applied.
Example:

Applying patch profile MyProfile completed.
Action:
No action required.

Unapplying Patch Profile

This event log informs that the patchmgr has started unapplying the
profile.
Example:
07-Feb-2008 09:52:20 14/1/1:patchmgr,0: 35, 1,

INFO, Unapplying patch profile MyProfile.
Action:
No action required.
Unapplied Patch Profile

This event log is generated after the profile has been unapplied.
Example:

Unapplying patch profile completed.
Action:
No action required
Patchmgr Initialization Completed

This event log informs that the patchmgr initialization has completed
for the particular target node.
Example:
07-Feb-2008 07:11:34 14/1/1:patchmgr,0: 37, 1, INFO, Patchmgr

Init completed for processor 2/1/1
Action:
No action required.

OA&M 9-267
Information on patch profile

An event log is generated to provide information on the patch
profile.The information includes profile name, number of patches in the
profile, memory required on CMC and on SSP.
Example:
07-Feb-2008 03:15:34 14/1/1:patchmgr,0: 38, 1,

INFO, Profile name: MyProfile, No. of patches in
profile: 6, Memory required on CMC: 576, Memory
required on SSP: 576
Action:
No action required.
Information on patchable memory

An event log is generated to provide information on the patchable
memory available on CMC and SSP processors.
Example:
07-Feb-2008 03:15:34 14/1/1:patchmgr,0: 39,

1, INFO, Patchable memory for CMC Processors:
2096200, SSP Processors: 1047616
Action:
No action required.
SOC Event Logs

This section describes event logs that are related to Software
Optionality Control (SOC).
Table 9-162
SOC Event Logs

Severity Log Event
Severity
1 INFO INFO <featureName> is The specified feature has
Enabled been enabled.


Severity Log Event
Severity
2 INFO INFO <featureName> is The specified feature has

Disabled been disabled.
3 INFO INFO Unknown string: An attempt was made to

<socString> enable/disable SOC
controlled functionality
with an invalid string.
Diameter Credit Control (DCC) Event Logs

Table 9-163
Diameter Credit Control Event Logs
Event Log Type Event Text Event Description

Number
1 CRITICAL NO ONLINE DIAMETER No Diameter server(s)

SERVER AVAILABLE on configured in the Diameter
Diameter Profile Profile on ISP is reachable.
<profileName> on ISP
<ispName>
2 CLEAR NO ONLINE DIAMETER At least one Diameter server

SERVER AVAILABLE on is now reachable or all
Diameter Profile Diameter servers are offline.
<ispName>
3 MINOR ONLINE DIAMETER SERVER Diameter server at address
at <serverIpAddress> on configured on Diameter
Diameter Profile Profile on ISP is not
<profileName> on ISP reachable.
<ispName> is unreachable
4 CLEAR ONLINE DIAMETER SERVER Diameter server is now

at <serverIpAddress> on reachable or has been put in
Diameter Profile an offline state.
<ispName> is unreachable
5 MINOR ACTIVE DIAMETER SERVER The currently active server

ON DIAMETER PROFILE has been changed. The
<profileName> SWITCHED reasonString identifies the
FROM <serverIpAddr> TO cause, e.g. manual cation,
<serverIpAddr> REASON server unreachable, etc.
<reasonString>

OA&M 9-269

Number
6 INFO PROTOCOL ERROR A protocol error has been

<returnCodeValue> RECEIVED detected and received from a
ON DIAMETER PROFILE server for a particular msisdn.
<profileName> FROM Server at
<serverIpAddr> for MSISDN
<msisdn>
7 INFO UNRECOGNIZED RATE ID Diameter Peer received an

<categoryId> RECEIVED from Unrecognized Rate ID from
DCC SERVER <serverIpAddr> GGSN.
for MSISDN <msisdn>, POLICY
<profileName>, ISP
<ispName>.
8 MAJOR Tx TIMER EXPIRATIONS OF By the end of the Tx Timer

COUNT <TxExpiryCount> Event Interval, the number of
EXCEEDED MAJOR Tx Expiries was at least equal
THRESHOLD ON DIAMETER to the major threshold but
PROFILE <profileName> AT less than the critical
DIAMETER SERVER threshold.
<serverIpAddr>.
9 CRITICAL Tx TIMER EXPIRATIONS OF By the end of the Tx Timer
COUNT <TxExpiryCount> Event Interval, the number of
EXCEEDED CRITICAL Tx Expiries was at least equal
THRESHOLD ON DIAMETER to the critical threshold.
PROFILE <profileName> AT
DIAMETER SERVER
<serverIpAddr>.
Health Check Monitor Event Logs

The event logs related to the Health Check Monitor are detailed in
Table 9-164

Table 9-164
Health Check Monitor Event Logs
Event Event Text Event Description

Number SysLog Disk &
Event Console
Severity Log Event
Severity
1 CRITICAL CRITICAL Nodal Activation The Nodal Activation

Success rate of Success Rate of PDP
<Success Rate> has Create requests, has
crossed the Threshold dropped below the Nodal
Value of <Threshold Success Rate threshold
Value> Counter Log = value.
<counter_log>
2 CLEAR CLEAR Nodal Activation The Nodal Activation
crossed the Threshold reached at or above the
Value of <Threshold threshold value.
Value> Counter Log =
<counter_log>
3 CRITICAL CRITICAL Network Activation The Network Activation

crossed the Threshold dropped below the
Value of <Threshold Network Success Rate
Value> Counter Log = threshold value.
<counter_log>
4 CLEAR CLEAR Network Activation The Network Activation

crossed the Threshold reached at or above the
Value of <Threshold threshold value.
Value> Counter Log =
<counter_log>
5 INFO INFO Attempted Activations The Attempted PDP
of <Number of context Activations have
AttemptedActivations> dropped to or below the
have crossed the threshold value.
Threshold Value
<Threshold Value>

OA&M 9-271
Event Event Text Event Description

Number SysLog Disk &
Event Console
Severity Log Event
Severity
6 CLEAR CLEAR Attempted Activations The Attempted PDP

of <Number of context Activations have
AttemptedActivations> raised above the
have crossed the threshold value.
Threshold Value
<Threshold Value>
Content Filtering Service (CFS) Event Logs

Table 9-165 lists the event logs generated on the system level. It may
be useful for troubleshooting if captured to device console or SYSLOG
Server.
Table 9-165
Content Filtering Service (CFS) Event Logs
Event Syslog Disk and Event Text Event

Number Event Console Description
Severity Event
Severity
1 MINOR MINOR Content Filter Server has
server at transitioned out
cfsServerIpAddre of the
ss:cfsServerPort ESTABLISHED
on profile state. It will no
cfsProfileName longer be used.
on ISP ispName
VPN vpnName is
unavailable
2 CLEAR CLEAR Content Filter Server has

server at transitioned into
cfsServerIpAddre the
ss:cfsServerPort ESTABLISHED
on profile state. It will now
cfsProfileName be used.
on ISP ispName
VPN vpnName is
unavailable

Event Syslog Disk and Event Text Event

Number Event Console Description
Severity Event
Severity
3 MAJOR MAJOR NO Content Filter No Content Filter

server available Servers are in the
on profile ESTABLISHED
cfsProfileName state for a given
on ISP ispName profile.
VPN vpnName
4 CLEAR CLEAR NO Content Filter At least one

server available Content Filter
on profile server has
cfsProfileName transitioned into
on ISP ispName the
VPN vpnName ESTABLISHED
state.
SER Base Event Logs

System Level Event Logs
Table 9-166 lists the event logs generated on the system level. It may
be useful for troubleshooting if captured to device console or SYSLOG
Server.
Table 9-166
System Level Event Logs
Event SysLog Disk & Event Text

Severity Log
Event
Severity
1 CRITICAL CRITICAL One or more AC/DC shelves have failed
2 CRITICAL CRITICAL Temperature fault in AC/DC shelf
3 CRITICAL CRITICAL One or more power supplies losing power
4 MINOR MINOR One or more power supplies not installed
5 MAJOR MAJOR Battery power not available
6 MAJOR MAJOR Battery interface unit has failed
7 MAJOR MAJOR Battery interface unit is over temperature
8 MAJOR MAJOR Alarm module on fan tray has power error
9 MAJOR MAJOR Battery 1 does not have full charge
10 MAJOR MAJOR Battery 2 does not have full charge
11 MAJOR MAJOR Battery 1 is not installed
12 MAJOR MAJOR Battery 2 is not installed

OA&M 9-273

Severity Log
Event
Severity
13 MAJOR MAJOR Single fan has failed
14 CRITICAL CRITICAL Fan Dead
15 CRITICAL CRITICAL Multiple fans have failed
16 CRITICAL CRITICAL Relay alarms disabled
17 CRITICAL CRITICAL Node is dead
18 CRITICAL CRITICAL Node Rebooted (how = <how>)
19 INFO INFO Reload delayed due to uninterrupted
operation (how = <how>)
20 INFO INFO SSM initialization completed
21 CLEAR CLEAR One or more AC/DC shelves failure
cleared
22 CLEAR CLEAR Temperature fault in AC/DC shelf cleared
23 CLEAR CLEAR One or more power supplies losing power
cleared
24 CLEAR CLEAR Battery power available
25 CLEAR CLEAR Battery interface unit over temperature
cleared
26 CLEAR CLEAR Single fan failure cleared
27 CLEAR CLEAR Multiple fans failure cleared
28 CLEAR CLEAR Fan dead is cleared
Card Level Event Logs

Table 9-167 lists the event logs generated on the card level. It may be
useful for troubleshooting if captured to device console or SYSLOG
Server.
Table 9-167
Card Level Event Logs

Severity Log Event
Severity
1 INFO INFO Card of type <card type> inserted in
slot <slot number>
2 MAJOR MAJOR Card of type <card type> removed
from slot <slot number>


Severity Log Event
Severity
3 CRITICAL CRITICAL Card of type <card type> in slot <slot
number> failed
4 CRITICAL CRITICAL Card of type <card type> in slot <slot
number> is missing
5 CRITICAL CRITICAL Card (<card type>) in slot <slot
number> rebooted
6 MAJOR MAJOR Expected <card type> in slot <slot
number> but found <card type>
7 CRITICAL CRITICAL Card in slot <slot number> is dead
8 INFO INFO SSM initialization completed
9 INFO INFO PCMCIA Card inserted
10 MAJOR MAJOR PCMCIA Card removed
11 INFO INFO Card will not be activated
12 MAJOR MAJOR Found card of type <card type> in
slot <slot number>, but slot is not
usable
13 MINOR MINOR Found card of type <card type> in
slot <slot number>, but slot is not
configured
14 INFO INFO Card [type <card type>] is
administratively disabled
15 MINOR MINOR Card in slot <slot number> cannot be
identified, ignoring
16 INFO INFO Firmware update of card in slot <slot
number> succeed
17 MAJOR MAJOR Firmware update of card in slot <slot
number> failed
18 INFO INFO APS group <group name> is added
19 INFO INFO APS group <group name> is deleted
20 INFO INFO APS port <port number> in slot <slot
number> has switched from active to
become standby.
21 INFO INFO APS port <port number> in slot <slot
number> has switched from standby
to become active
22 INFO INFO Both APS ports (<slot number>/<port
number>) and (<slot number>/<port
number>) are down

OA&M 9-275

Severity Log Event
Severity
23 CRITICAL CRITICAL Card <card type> in slot <slotid>
booted
24 INFO INFO Image <image> has been copied to
<dest>
25 MINOR MINOR Image <image> could not be copied
to <dest>
26 MINOR MINOR Image for <image> is being reset
back to default image
27 MINOR MINOR Card <card type> in slot <slotid>
mismatch revision
28 CRITICAL CRITICAL Card of type <card type> in slot
<slot> malfunctioned
29 MAJOR MAJOR Card of type <card type in slot <slot>
failed diags
30 INFO INFO Switch to newly active card in slot
<slot> complete
31 CRITICAL CRITICAL Card standby not in redundant
32 INFO INFO Card in slot <slot> has been disabled
33 INFO INFO Card in slot <slot> has been enabled
34 INFO INFO Card in slot <slot> is up
35 INFO INFO Card switchover from slot <slot>
issued by user via CLI command
36 MAJOR MAJOR Card switch over in slot <slot>
triggered by <reason_string>
37 INFO INFO Card will not be activated (mismatch)
38 INFO INFO Card will not be activated (disabled)
39 MINOR MINOR Can’t execute APS command on
protection port <portid> in slot
<slotid. Please specify working port
in the command.
40 MINOR MINOR Can’t lockout APS port <portid> in
slot <slotid>
41 INFO INFO lockout APS port <portid> in slot
<slotid>
42 MINOR MINOR This port has already been switched
from working. Can’t switch again.
43 MINOR MINOR Protection port is down. Can’t switch
to protection port.


Severity Log Event
Severity
44 MINOR MINOR Can’t force switch port <portid> in
slot <slotid> from working to
protection. This port has probably
been locked out or forced switching
earlier.
45 MINOR MINOR Can’t manual switch port <portid> in
slot <slotid> from working to
protection. This port has probably
been locked out or forced switching
earlier.
46 MINOR MINOR This port has already been switched
from protection. Can’t switch again.
47 MINOR MINOR Working port is down. Can’t switch to
working port.
48 MINOR MINOR Can’t force switch port <portid> in
slot ><slotid> from protection to
working. This port has probably been
locked out or forced switching
earlier.
49 MINOR MINOR Can’t manual switch port <portid> in
slot ><slotid> from protection to
working. This port has probably been
locked out or forced switching
earlier.
50 INFO INFO All previous APS command are clear.
51 MINOR MINOR There is no existing APS commands
to be cleared.
52 MINOR MINOR Can’t clear switch command op port
<portid> in slot <slotid>. Current
request status is not in Lockout,
Forced or Manual switch.
53 MINOR MINOR unsupported APS switch command.
54 MINOR MINOR Image <image> does not match card
type specified
55 MINOR MINOR Switchover failed - could not initialize
SFC in slot <slotid>. Wait for 5
minutes before initiate another
switch back to old SFC.

OA&M 9-277
ATM Line Card Event Logs

Table 9-168 lists the event logs generated by the ATM Line Card
Manager. It may be useful for troubleshooting if captured to device
console or SYSLOG Server.
Table 9-168
ATM Line Card Event Logs

Severity Log Event
Severity
1 INFO INFO ALC slot <slot number> port <port
number> is up
2 MAJOR MAJOR ALC slot <slot number> port <port
number> is down
3 MINOR MINOR ALC slot <slot number> port <port
number> looped back
number> LOS
number> LOF
number> LAIS
number> LRDI
number> LOP
number> PAIS
number> PRDI
number> lost delineation
12 CLEAR CLEAR ALC slot <slot number> port <port
number> unlooped
13 INFO INFO ALC slot <slot number> ICP <port
number> CAM is FULL
14 MAJOR MAJOR ALC slot <slot number> port <port
number> YELLOW
15 MAJOR MAJOR ALC slot <slot number>: bad ICP
16 MAJOR MAJOR ALC slot <slot number>: bad ICP
Semaphore


Severity Log Event
Severity
17 MINOR MINOR ALC slot <slot number>: bad ICP
duplicate entries
18 MINOR MINOR ALC slot <slot number>: bad ICP isn
bus read error
19 MINOR MINOR ALC slot <slot number>: bad ICP null
list
number> LOS clear
number> LOF clear
number> LAIS clear
number> LRDI clear
number> LOP clear
number> PAIS clear
number> PRDI clear
number> loss of delineation clear
28 INFO INFO ALC slot <slot> ICP <icp CAM <cam>
is not FULL
SSM Event Logs

Table 9-169 lists the event logs generated by the SSM manager. It
may be useful for troubleshooting if captured to device console or
SYSLOG Server.

OA&M 9-279
Table 9-169
SSM Event Logs

Severity Log Event
Severity
1 CRITICAL CRITICAL SSM <module number> in slot <slot
number> failed
2 MAJOR MAJOR SSM <module number> in slot <slot
number> was reset MISC/CTRL REG:
0x<reg address>
3 INFO INFO SSM <module number> in slot <slot
number> is up
4 CRITICAL CRITICAL SSM <module number> in slot <slot
number> died
5 MINOR MINOR SSM <module number> in slot <slot
number> was disabled
6 MAJOR MAJOR Erratic SSM: <slot number>/<module
number> <cpu_0_miss>
<cpu_1_miss> <cpu_2_miss>
<cpu_3_miss>
7 MAJOR MAJOR Erratic downloading SSM: <slot
number>/<module number>
8 MAJOR MAJOR Did not reset SSM MISC/CTRL REG:
0x<reg address>
number> is down
number> started core dump
11 WARNING MAJOR Core Dump failed for SSM <module
number> in slot <slot number> Error
<error number>
number> Successfully dumped core
number> removal processing done
14 MAJOR MAJOR EPIF channel <channel number> in
slot <slot number> has died
15 MAJOR MAJOR Reset SSC card in slot <slot number>
16 MAJOR MAJOR All SSMs in slot <slot number> has
failed


Severity Log Event
Severity
number> has missed poll. SSM
received <hello number> hellos, CMC
received <hello number> hellos
18 MINOR MINOR All connections to SSC slot <slot
number> are reset
19 INFO INFO SSC slot <slot number> reset
successfully
20 MINOR MINOR CMC received hello from SSM with
invalid slot/port: <slot number> <port
number>
21 INFO INFO <multicast info> Source: Slot <root
slot number> Port <root port
number> VPI <out vpi number> VCI
<out vci number>, Dest: Slot <local
slot number> Port <local port
number> VPI <in vpi number> VCI <in
vci number> Proc <procedure>
mmc_result <multicast result>
22 MINOR MINOR Resource bandwidth for <conn_type>
connection type was changed from
<old_bd> kbps to <new_bd> kbps.
23 INFO INFO SSM <portid> in slot <slotid> was
spared.
24 INFO INFO Spared SSM <portid> in slot <slotid>
was activated.
25 INFO INFO SSM sparing enabled
26 MINOR MINOR SSM <portid> in slot <slotid> may
need a forced catchup to move stuck
connection.
27 INFO INFO SSM <portid> in slot <slotid> forced
catchup success
28 MINOR MINOR SSM <portid> in slot <slotid> forced
catchup unsuccessful
29 MINOR MINOR Object for SSM <portid> in slot
<slotid> already exists, resetting
SSM.
30 MINOR MINOR SSP <node> currently doesn’t have
sufficient resources to provision
connections

OA&M 9-281

Severity Log Event
Severity
31 MINOR MINOR No SSPs currently have sufficient
resources to provision connections
32 INFO INFO Too many resource log messages,
temporally suppressing.
33 MINOR MINOR The CMC image <cmc_image> and
SSM image <ssm_image> do not
match for slot <slotid> module
<moduleid>
34 MAJOR MAJOR SSS <portid> in slot <slotid> catchup
failed, initiating cleanup and SSM
reset.
35 MAJOR MAJOR ISPMGR catchup returned
<error_string>
36 MAJOR MAJOR VPNMGR catchup returned
<errot_string>
37 MAJOR MAJOR LFIBMGR catchup returned
<error_string>
38 MAJOR MAJOR SVCMGR catchup returned
<error_string>
39 MAJOR MAJOR SVCMGR catchup returned
<error_string>
40 MAJOR MAJOR SUBMGR catchup returned
<error_string>
41 MAJOR MAJOR IFMGR catchup returned
<error_string>
42 MAJOR MAJOR FIBMGR catchup returned
<error_string>
43 MAJOR MAJOR ATMPMGR catchup returned
<error_string>
44 MAJOR MAJOR SUBMGR remove SSM failed
<error_string>
45 MAJOR MAJOR IFMGR remove SSM callback failed
<error_string>
46 MAJOR MAJOR ISPMGR remove SSM callback failed
<error_string>
47 MAJOR MAJOR ATMPMGR remove SSM failed
<error_string>
48 MAJOR MAJOR VPNMGR remove SSS phase
<phase> failed <error_string>


Severity Log Event
Severity
49 MAJOR MAJOR SVCMGR remove SSM failed
<error_string>
50 CRITICAL CRITICAL SSM <portid> in slot <slotid> stuck in
catchup due to congestion. taking
SSM temporarily down; To recover
manually reset SSM
51 MAJOR MAJOR Catchup timed out, module
<module>; Aborting catchup
52 MINOR MINOR System reached 80 percent of Max
Conn Capacity: <log_buffer>
53 MAJOR MAJOR Maximum simultaneous SSM
coredump limit reached. Disallowing
coredump of SSM <portid> in slot
<slotid>
58 WARNING MAJOR Reset SSC3 card in slot <slot>
59 WARNING MINOR All connections to SSC3 slot <slot> are
reset.
60 INFO INFO SSC3 slot <slot> reset successfully
61 WARNING MAJOR SSC3 slot <slot> initialization aborted
62 WARNING MAJOR Failed to set CP for SSC3 in slot
<slot>
63 WARNING MINOR Failed to set MP for SSC3 in slot <slot>
64 INFO INFO SSM <SSM> set as CP for SSC3 in slot
<slot>
65 INFO INFO SSM <SSM> set as MP for SSC3 in slot
<slot>
66 WARNING CRITICAL SSO on SSC3 in slot <slot> has failed
67 INFO INFO SSO on SSC3 in slot <slot> is up.
68 WARNING MAJOR SSO on SSC3 in slot <slot> is down.
77 INFO INFO GGSN is in SSC3 migration mode.
78 INFO INFO GGSN is not in SSC3 migration mode.
79 MAJOR MAJOR EPIF slot <slot> port <port> is locked
up.Lockup Info :
<lockup_info>
RPC Event Logs

Table 9-170 lists the event logs generated to report internal
interprocess communication errors. These events themselves are not
indicative of any problems, but may be useful for troubleshooting if
captured to device console or SYSLOG Server. The RPC events are

OA&M 9-283
symptomatic of a heavily loaded system. Typically, the system will

recover from these transient load scenarios with no operator
intervention required. RPC events may appear during SFC switchover
due to the manual switch SFC CLI command or the faulty of the active
SFC. In this case, the system will recover after the switching SFC
completed. RPC events are present for information gathering
purposes in scenarios where the system does not auto recover or the
other scenarios where the system experiences subsequent instability
or other issues.
Table 9-170
RPC Timeout Event Logs
Event Number SysLog Disk & Event Text

Event Console
Severity Log
Event
Severity
1 MINOR MINOR Module <dst_module>
<dst_instnace> on node <dst_node>
did not process an incoming RPC
request from module <src_module>
<src_instance> on node <src_node> -
timed out after <msec> msec (op
<op>, xid <id>, #retrans
<num_trans>, intvl <intvl>)
2 INFO INFO Module <dst_module>
<dst_instance> on node <dst_node>
did not process an incoming RPC
request from module <src_module>
<src_instance> on node <src_node>
in the allotted time and the request
was dropped (op <op>, xid <id>, life
<life>, age <age>)
AAA Manager Event Logs

Table 9-171 lists the event logs generated to report AAA manager
events. These events themselves are not indicative of any problems,
but may be useful for troubleshooting if captured to device console or
SYSLOG Server.

Table 9-171
AAA Manager Event Logs
Event SysLog Event Disk & Console Event Text

Severity
2 INFO INFO Session disconnect successful
<success string>
3 MAJOR MAJOR Session disconnect failed <failure
string>]
4 INFO INFO Session disconnect ignored. <ignore
string>
5 INFO INFO WARNING radius_acct: NULL
username Len <name length>
6 INFO INFO WARNING radius_acct: [<caller id>]
RADIUS_ACCT_SESSION aaaid
<session id> Username <user name>
len <name length> too Big
7 MINOR MINOR Freeing bad AAA reply structure with
address <reply attributes> tlv-count
<tlv count> in <ra>
9 MINOR MINOR Freeing bad AAA auth structure with
address <auth attributes> tlv-count
<tlv count> in <ra>
27 MINOR MINOR Reserved IP Address Pool category
has reached above
<percent_value>% in Access Group
<group_name> in ISP <isp_name>.
Total number of addresses in this
category = <total_addr> and number
of addresses used =<used_addr>
28 MINOR MINOR Unreserved IP Address Pool category
has reached above
29 INFORMATION INFORMATION Reserved IP Address Pool category
has dropped to bellow

OA&M 9-285
Event SysLog Event Disk & Console Event Text

Severity
30 INFORMATION INFORMATION Unreserved IP Address Pool category
has dropped to bellow
31 INFORMATION INFORMATION IP Address Pool name = <poolName>
Activation_Deactivation State
Change to <state> for address
assignment in Access Group
<sgroupName> in ISP <ispName>
32 INFORMATION INFORMATION No Pool found - invalid Framed-Pool
name, User name = <userName>,
Framed-Pool name received =
<poolName> in Access Group
<sgroupName> in ISP <ispName>
timeStamp = <timeStamp>
33 INFORMATION INFORMATION No Pool found, User name =
<userName>, Framed-Pool name
received = <poolName> in Access
Group <%s <sgroupName> in ISP
<%s <ispName> timeStamp =
<timeStamp>
IP Forwarding Table Manager Event Logs

Table 9-172 lists the event logs generated to report internal IP
forwarding table manager events. These events themselves are not
indicative of any problems, but may be useful for troubleshooting if
captured to device console or SYSLOG Server.

Table 9-172
FIB Manager Event Logs

Severity Log
Event
Severity
1 MINOR MINOR FIB add on node <node name>: dest
<ip address> mask 0x<fib mask>
gateway <ip address> outif <if name>
proto <protocol name>: <string>
2 MINOR MINOR FIB delete on node <node name>:
dest <ip address> mask 0x<fib mask>
gateway <ip address> outif <if name>
proto <protocol name>: <string>
3 MINOR MINOR FIB batch request failed: RPC time-
out on node <node name>
SNTP Event Logs

Table 9-173 lists the event logs generated to report SNTP Client
events. Occurrences of these events may indicate networking
problems or problems with the SNTP Servers themselves.
Table 9-173
SNTP Event Logs

Severity Log
Event
Severity
1 MINOR MINOR SNTP server <server address>
unsynchronized
2 MINOR MINOR SNTP server <server address>
version <sntp version> unsupported
3 MAJOR MAJOR SNTP server <server address> mode
<sntp mode> is not broadcast
4 MINOR MINOR SNTP unicast to <server address>
timed out
Interface Manager Event Logs

Table 9-174 lists event logs generated by the Interface Manager.
These logs may provide useful historical records, but it is not
necessary to monitor them in real-time.

OA&M 9-287
Table 9-174
Interface Manager Event Logs

Severity Log Event
Severity
1 MINOR MINOR On connection <connection name>,
found IP address <ip address> but
configured is <ip address>
2 MINOR MINOR Connection <connection name>
marked down by OAM
3 INFO INFO Connection <connection name>
marked up by OAM
4 MINOR MINOR Error moving conn: <connection
name> with invalid slot: 0x<slot
number> to node: 0x<node number>
at Catchup 0
5 MINOR MINOR Attempt to write invalid pointer, data=
<caddr> is not valid memory address!
table= <table>, index= <index>
6 MINOR MINOR Attempt to read invalid pointer, chunk
data instance= <chunk> val= <caddr>
is not valid memory address! table=
<table>, index= <index>
7 MINOR MINOR Function <func_name> has
attempted to add an invalid <invalid>
pointer: <pointer> to chunk data
8 MINOR MINOR CAC bandwidth allocation error for
slot: <slotid> port: <portid> while
modifying profile <profilename>
System Manager Event Logs

Table 9-175 lists event logs generated by the System Manager. These
event logs may provide useful historical records, but, with the
exception of the Memory Management, it is not necessary to monitor
them in real-time.
In the event that the static data on CMC card or SSC card is
overridden, the bad memory event log (i.e. event number 7) is
generated for reporting the software violation. In this case, Nortel
personnel should be notified.
In the event that unaligned data access occurred on CMC3, the CMC3
unaligned address event log (i.e. event number 14) is generated for
reporting the software error. These errors are not critical because the
unaligned access that was requested is completed. For each

unaligned data access software error, only the first occurrence is

logged. Occurrence of this log should be reported to Nortel personnel.
Table 9-175
System Manager Event Logs

Severity Log Event
Severity
1 INFO INFO mgmt-eth0: link up
2 MINOR MINOR mgmt-eth0: link down
3 INFO INFO serv-eth <ethernetId>: link up
4 MINOR MINOR serv-eth <ethernetId>: link down
5 INFO INFO System reloaded by <module name>
6 INFO INFO System initialized: version <version
number>
7 CRITICAL CRITICAL <bad memory string>
12 MINOR MINOR Number of Routes has reached
<number_of_routes>
13 INFO INFO SSC3 unaligned addr. <info>
14 INFO INFO CMC3 unaligned addr:.
Task Manager Event Logs

Table 9-176 lists event logs generated by the Task Manager. These
logs provide critical information about the internal system tasks. In the
event of “Suspended task” or “System should be restarted”, Nortel
personnel should be notified.
Table 9-176
Task Manager Event Logs

Severity Log Event
Severity
1 MINOR MINOR Suspended task: name= ‘<task
name>’(0x<task id>), mid =’<module
name>’, inst=<instance number>
2 CRITICAL CRITICAL System should be restarted
3 INFO INFO <Debug info for suspended tasks>
Configuration Manager Event Logs

Table 9-177 lists event logs generated by the Configuration Manager.
Configuration logs for which the SYSLOG monitoring is recommended

OA&M 9-289
are indicative of configuration related failures. If such logs are seen,

Nortel personnel should be notified.
Table 9-177
Configuration Manager Event Logs

Severity Log Event
Severity
1 INFO INFO Config phase 1 complete
2 CRITICAL CRITICAL Config phase 1 load failed
3 INFO INFO Config phase 2 complete
4 CRITICAL CRITICAL Config phase 2 load failed
5 INFO INFO Quickstart information (phase 1)
loaded
6 CRITICAL CRITICAL Quickstart load (phase 1) failed:
7 INFO INFO Quickstart information (phase 2)
loaded
8 CRITICAL CRITICAL Quickstart load (phase 2) failed
9 INFO INFO Configuration initialized
10 MINOR MINOR Command failed
11 MINOR MINOR Error on db <db_op> in <config>/
<db> err= <error_string>
12 INFO INFO Image files are protected
13 INFO INFO Image files are not protected
14 INFO INFO Config save in progress. Standby
CMC will be temporarily non-
redundant.
15 CRITICAL CRITICAL Failed to save <db_name> db. Needs
a manual save.
16 INFO INFO Finished backing up config
<config_name>
17 MINOR MINOR Failed to backup config
<config_name>
18 MINOR MINOR Encountered 4 byte offset problem.
Saved files <file_name> and <
verdb_back_fname>
19 INFO INFO Starting loading phase <phase> of
config <config_name>


Severity Log Event
Severity
20 INFO INFO Finished loading phase <phase> of
config <config_name>
21 INFO INFO Unsupported config, Object ID=
<objid>, <objname> is REJECTED
Subscriber Manager Event Logs
Table 9-178 lists event logs generated by the Subscriber Manager.
Subscriber Manager logs for which the SYSLOG monitoring is
recommended are indicative of loss of service for subscribers. If such
logs are seen, Nortel personnel should be notified.
Table 9-178
Subscriber Manager Event Logs

Severity Log Event
Severity
1 MAJOR MAJOR Subscriber Configuration Failed
2 MAJOR MAJOR Subscriber Commit Failed
3 MAJOR MAJOR Access Connection Commit Failed
4 MAJOR MAJOR Bulk Access failure
5 MAJOR MAJOR IPDemux Subscriber <sub_name>,
<domain_name>, <ispname> Commit
Failed: <error_string>
This log is generated in a call setup,
when the SSM goes down in the
interval between the allocation of the
SSM and the subscriber being
committed to it. The error string
indicates the cause of the failure.
6 MINOR MINOR Subscriber <sub_name>,
<domain_name>, <ispname> Delete
Failed: <error_string>
7 MAJOR MAJOR Subscriber <sub_name>. <domain>,
<ispname> Database Read Failed:
<error_string>
8 INFO INFO SCS configuration save begin
9 INFO INFO SCS configuration save done
10 INFO INFO Dedicated subscriber pull completed
11 INFO INFO Finished saving pulled dedicated
subscribers

OA&M 9-291

Severity Log Event
Severity
12 MAJOR MAJOR Subscriber <sub_id>, <ispname>
Uncommit failed: <error_string>
This log is generated when sessions
are taken down in the Nortel GGSN
and critical information about a
session is not found. The error string
indicates the cause of the failure.
13 MAJOR MAJOR Failed to commit subscriber
<sub_name> (<sub_id>) with
interface <interface_name>
(<interface_id>) on connection
<conn> (<connid>) because remote
address <addr> is already attached to
subscriber <sub_name2>(<subid2>)
with interface <ifname2>(<ifif2>) on
connection <conn2>(<connid2>)
(IPCP = <ipcp>)
14 MINOR MINOR No response from pull server.
Bypassing a subscriber and domain
group pulling.
15 INFO INFO Pull server responding. Subscriber
pulling and domain group pulling
available.
16 MAJOR MAJOR Subscriber <sub_name> Move
Commit Failed
17 INFO INFO Subscriber <sub_name> (<subid>)
with interface <ifname> (<ifid>) and
connection found its remote address
is in the fib. Since the fib is attached
to NULL subscriber with NULL
interface and NULL connection
(IPCP= <ipcp>). Sub is trying to
remove this fib.
18 MAJOR MAJOR Traffic profile modification.
Connection <conn> reset failed to
reset with new parameters:
<error_string>
19 MINOR MINOR Unable to move conn <conn>
because SSP <node> currently does
not have sufficient resources.
20 MINOR MINOR Unable to move conn <conn>
because no SSP currently has
sufficient resources.


Severity Log Event
Severity
21 INFO INFO <subs_message_string>
22 INFO INFO Subscriber <subname> (<subid>)
with interface <ifname> (<ifid>) and
connection <conn> (connid>) found
its remote address <raddress> is
attached to interface <ifname2>
(ifid2>). But this interface has no
subscriber <subname2> (<subid2>)
and poisoned connection <conn2>
(<connid2>) (IPCP= <ipcp>). Sub is
trying to delete this interface.
23 INFO INFO Try to uncommit the leftover sub
<subname> (<subid>) to make sure
the next time the sub can commit.
24 INFO INFO Try to delete leftover interface
<ifname> (<ifid>) to make sure the
next time the sub can commit
25 INFO INFO Subscriber <subname> (<subid>)
with interface <ifname> (<ifid>) on
connection <conn> (<connid>) found
it remote/network address
<raddress> in fib. Entry was learned
in <protocol> on interface <ifname2>
(<ifid2>) and connection <conn2>
(<connid2>)
26 MAJOR MAJOR <Subscriber bulk reset failure string>
27 MAJOR MAJOR Subscriber <subname> Move failed:
<error_string>
28 MAJOR MAJOR Subscriber <subname>, <domain>,
<ispname> Commit Failed:
<error_string> IP ADDR: <ipaddr>
PPP Event Logs

Table 9-179 lists PPP-related logs. While these logs are marked as
recommended for the SYSLOG or device console monitoring. Multiple
occurrences of these logs may be indicative of network problems.

OA&M 9-293
Table 9-179
PPP Event Logs

Severity Log Event
Severity
1 MAJOR MAJOR PPP Subscriber Commit Failed
Callback: pppid <connid> subid
<subid> ip <ipaddr> <error_string>
2 MINOR MINOR PPP Subscriber Uncommit Failed
Callback: pppid <connid> subid
<subid> ip <ipaddr> downflag <flag>
<<error_string>
3 MINOR MINOR PPP Subscriber Auth Callback: pppid
<connid> subid <subid> ip <ipaddr>
<error_string>
4 MINOR MINOR PPP Conflicting IP Address: pppid
<connid> ppp_cb_ip <ppp_ipaddr>
aaa_ip <aaa_ipaddr>
5 INFO INFO PPP received an obsolete sync reply
message from AAA: pppid <connid>
subid <subid> req rpl <rpl>.
Authentication server (e.g. radius)
may be congested.
6 INFO INFO PPP received an obsolete asyn reply
message from AAA: pppid <connid>
subid <subid> req rpl <rpl>.
Authentication server (e.g. radius)
may be congested.
7 INFO INFO PPP received obsolete callback from
Subscriber Auth.: pppid <connid>
subid <subid> req rpl <rpl>. Ignoring
reply. May indicate pull server
congestion.
8 MINOR MINOR Invalid Link Count: bundle_id <id>
link_count <lcount>
bundle_link_count <bcount> node
<node> ppp_if <ppp_if> bundle
<bundle> Err= <err_string>.
9 INFO INFO PPP throttle cleared.


Severity Log Event
Severity
10 INFO INFO WARNING:<ppp> Service Profile:
<profile string> invalid for APN: <>
invalid for APN: <apn name>,
Subscriber: <user name> on Radius
Server: <radius profile>.
11 INFO INFO WARNING:<ppp> VPN Name: <vpn
string> Invalid for APN: <apn name>
Subscriber: <user name> on Radius
Server: <radius profile>.
CMC Redundancy Event Logs

Table 9-180 lists CMC redundancy event logs. Logs marked as
recommended for SYSLOG monitoring may be indicative of serious
system problems. Nortel personnel should be notified upon any
occurrences of these logs.
The <cmc_type> field in Table 9-180 indicates the CMC type of 2 or 3

for CMC2 or CMC3, respectively.
Table 9-180
CMC Redundancy Event Logs

Severity Log Event
Severity
1 INFO INFO CMC<cmc_type> The CMC is redundant.
redundant
2 MINOR MINOR CMC<cmc_type> not The CMC is not
redundant : <reason> redundant.
3 MAJOR MAJOR Standby CMC<cmc_type> The standby CMC is not
not redundant : <reason> redundant.
4 MINOR MINOR CMC<cmc_type> images The images on the
are not the same. Active = active and standby
<release number> , CMCs are not the same.
Standby = <release
number>
5 INFO INFO CMC<cmc_type> configs The configurations on
are not the same. Active = the active and standby
<version number>, CMCs are not the same.
Standby = <version The configurations are
number>. Syncing configs being synced.

OA&M 9-295

Severity Log Event
Severity
6 MINOR MINOR Standby CMC<cmc_type> The standby CMC CPU
CPU memory (<memory memory is less than the
size> MB) is less than active CMC CPU
active CMC<cmc_type> memory.
CPU memory (<memory
size> MB).
7 CRITICAL CRITICAL CMC<cmc_type> Routing The CMC routing
processor failed. processor failed.
8 CRITICAL CRITICAL This CMC<cmc_type> is The CMC is taking over
taking over as active. as the active CMC.
9 CRITICAL CRITICAL No CMC currently active! None of the CMCs are
Attempting to takeover. active. The CMC is
attempting to takeover
as the active CMC.
10 INFO INFO Standby CMC reloaded by The standby CMC has
<module name> (how = been reloaded.
<how>)
11 CLEAR CLEAR Standby CMC<cmc_type> The serial port of the
in slot <slotid> serial port standby CMC is up.
<portid> is up
12 MINOR MINOR Standby CMC<cmc_type> The serial port of the
in slot <slotid> serial port standby CMC is down.
<portid> is down
13 CLEAR CLEAR CMC<cmc_type> in slot The serial port of the
<slotid> serial port active CMC is up.
<portid> is up
14 MINOR MINOR CMC<cmc_type> in slot The serial port of the
<slotid> serial port active CMC is down.
<portid> is down
15 WARNIN MINOR Standby CMC aborted The standby CMC
G because of mismatch: aborted due to a
<reason> mismatch with the
active CMC. <reason>
indicates the mismatch
reason (e.g. card types
are different)


Severity Log Event
Severity
16 INFO INFO Standby CMC config not An error occurred on
redundant. CMC core the active CMC
dump will not be resulting in a core
attempted. dump. A core dump will
not be attempted if the
standby CMC config is
not the same as the
active CMC.
17 INFO INFO Standby CMC3 reloaded The standby CMC3 has
by <module name> (how = been reloaded.
<how>)
18 WARNIN MINOR Standby CMC3 aborted The standby CMC3
G because of mismatch: aborted due to a
<reason> mismatch with the
active CMC. <reason>
indicates the mismatch
reason (e.g. card types
are different)
19 INFO INFO CMC in slot <slotid> serial The configuration of the
port <portid> CMC serial port has
configuration has changed.
changed.
20 INFO INFO CMC3 in slot <slotid> The configuration of the
serial port <portid> CMC3 serial port has
configuration has changed.
changed.
21 WARNIN MAJOR Active CMC has an invalid The active CMC has an
G boot file1 <file> invalid boot file.
22 WARNIN MINOR Standby CMC has an The standby CMC has
G invalid boot file1 <file> an invalid boot file.
23 INFO INFO Active CMC has valid boot The active CMC has a
file1 <file> valid boot file.
24 INFO INFO Standby CMC has valid The standby CMC has a
boot file1 <file> valid boot file.
25 MAJOR MAJOR Standby CMC3 config not An error occurred on
redundant. CMC3 core the active CMC3
dump will not be resulting in a core
attempted. dump. A core dump will
not be attempted if the
standby CMC3 config is
not the same as the
active CMC3.

OA&M 9-297

Severity Log Event
Severity
26 INFO INFO Standby CMC CPU The active CMC has
memory size has been received info of the
saved on the Active CMC standby CMC CPU
memory size. This info
is saved on the active
CMC.
27 WARNIN MINOR Standby CMC not The standby CMC is not
G responding. Attempting responding. Attempting
temporary card deletion to to delete the standby
clear the problem. CMC card to clear the
problem.
28 CRITICAL CRITICAL SFC Switch to slot <slot> The SFC switch started.
started.
29 CLEAR CLEAR SFC Switch to newly active The SFC switch
card in slot <slot> completed.
complete.
User Manager Event Logs

Table 9-181 lists User manager event logs. These logs provide
historical records of users logging onto and off of the Nortel GGSN.
Recommendations for review or monitoring of these logs are left to the
operators.
Table 9-181
User Manager Event Logs

Severity Log Event
Severity
1 INFO INFO <user name> logged on <device
name> (from <where>)
2 INFO INFO <user name> logged out from
<where>
3 MINOR MINOR <user name> failed to log on <device
name> (from <where>)
IKE Event Logs

Table 9-182 lists event logs related to cryptographic key management
for VPNs. These logs may be indicative of mis-configuration or
malevolent external devices, and hence should be monitored.
Administrative action should include configuration and network
security verification.

Table 9-182
IKE Event Logs

Severity Log Event
Severity
1 MINOR MINOR No interface for vpn <vpn oui>-<vpn
id> to host <ip address>, isp <isp
name> [<number> missed events]
2 MINOR MINOR No ike profile for security
association, isp <isp name> [<missed
event number> missed events]
3 MINOR MINOR Cannot send to host <ip address>,
isp <isp name> [<missed event
number> missed events]
4 INFO INFO IPSec Client Idle Timeout [<missed
5 INFO INFO IKE Session Timeout [<missed event
6 INFO INFO IKE Bad SA Signature [<missed event
7 MINOR MINOR IKE Bad HIFN Event
8 INFO INFO IKE Good HIFN Event
9 INFO INFO IKE tunnel starts successfully with
local Address <address>, remote
Address <address>, subscriber name
<name>, SA Id <id number>, VPN Id
<id number>, tunnel life time
<lifetime>and cause code <cc
number>
10 INFO INFO IKE tunnel stops with local address
<address>, remote address
<address>, subscriber name <name>,
SA Id <id number>, VPN Id <id
number>, tunnel life time <lifetime>,
and cause code <cc number>
11 INFO INFO IKE tunnel is not correctly
established with local address
<address>, subscriber name <name>,
Sa Id <id number>, VPN Id <id
number> and cause code <cc
number>

OA&M 9-299

Severity Log Event
Severity
12 INFO INFO IPsec tunnel starts successfully with
interface name <name>, tunnel name
<name>, subscriber name <name>,
tunnel life time <lifetime value>,
tunnel life size <lifetime size> and
cause code <cc number>
13 INFO INFO IPsec tunnel stops with interface
name <name>, tunnel name <name>,
subscriber name <name> and cause
code <ccnumber>
14 INFO INFO IPsec tunnel is not correctly
established with local address
<address>, tunnel name <name> and
cause code <cc number>
15 INFO INFO Dead Peer Detection keepalive
started on SA <sa number>
16 INFO INFO Dead Peer Detection configuration
error <description> (<ip address>)”
VPN Event logs

Table 9-183 lists VPN-related logs. No specific administrative action is
recommended for these events, and they are therefore marked as
recommended for SYSLOG or device console monitoring.
Table 9-183
VPN Event Logs

Severity Log Event
Severity
1 MINOR MINOR Mesh down for vprn <isp name>-<vpn
name> peers expected <trunk if
number>, actual <actual number>
[<missed event number> missed
events]
2 INFO INFO Mesh up for vprn <vpn oui>-<vpn id>
peers expected <trunk if number>,
actual <actual number> [<missed


Severity Log Event
Severity
3 INFO INFO Generic VPN event used for debug
info [<missed event number> missed
events]
4 MINOR MINOR peer <peer name> down for vprn
<vpn name> isp_id <isp id>
5 INFO INFO peer <peer name> up for vprn <vpn
name> isp_id <isp id>
6 MINOR MINOR vprn <vpn_name> isp_id <ispid>
schedule for peer refresh, add peer
<peer_name> fail.
7 MINOR MINOR Vpn mesh down: vpn name
<vpn_name> isp name <ispname>
8 CLEAR CLEAR Vpn mesh up: vpn name <vpn_name>
isp name <ispname>
Ethernet Line Card Event Logs

Table 9-184 lists event logs related to Ethernet Line Card (ELC). The
events recommended for SYSLOG monitoring may be indicative of
problems with the ELC hardware. Administrative action should be to
contact Nortel personnel to ascertain if hardware replacement is
necessary.
Table 9-184
Ethernet Line Card Event Logs

Severity Log Event
Severity
1 CLEAR CLEAR Ethernet slot <slot number>: port
<port number> is up
2 MAJOR MAJOR Ethernet slot <slot number>: port
<port number> is down
3 MAJOR MAJOR Ethernet slot <slot number>: IPCAM
(IP Content Addressable Memory) is
full
L2TP Event Logs

Table 9-185 lists event logs related to L2TP. The events
recommended for SYSLOG monitoring may be indicative of problems
with the remote LNS access.

OA&M 9-301
For L2TP tunnels configured to be dynamic, the tunnel up and down

logs are not generated for routine tunnel up and down events. Only
error scenarios generate logs for dynamic tunnels.
Table 9-185
L2TP Event Logs

Severity Log Event
Severity
1 CLEAR CLEAR L2TP Tunnel Up ‘<tunnel name>’
[Tunnel Id = 0x<tunnel id>, ISP <isp
id>]
2 INFO INFO L2TP Tunnel Down ‘<tunnel name>’
[Tunnel Id = 0x<tunnel id>, ISP <isp
id>]
4 INFO INFO L2TP: [Tunnel Id = 0x<tunnel id>, ISP
<isp id>] <packet number> mismatch
data packet
6 INFO INFO L2TP: <tunnelName> [Remote Host
Name= <hostname> ISP <ispid>]
doesn’t recover for over an hour
7 INFO INFO L2TP throttle cleared
8 INFO INFO L2TP Tunnel Up <description_string>
9 INFO INFO L2TP Tunnel Down
<description_string>

Table 9-186 lists event logs related to the ISP Manger. The events
recommended for SYSLOG monitoring may be indicative of internal
system problems. Administrative action should be to contact Nortel
personnel.
Table 9-186

Severity Log Event
Severity
1 MAJOR MAJOR ipsecifid=<if id> got newssp <ssp
name>, but detach_if failed
2 INFO INFO move ipsecifid=<if id> from homeless
to <ssp name> failed: stay homeless.


Severity Log Event
Severity
3 MAJOR MAJOR ipsecifid=<if id> moved from
homeless to <ssp name>, but
ifmgr_attach_if failed
4 MAJOR MAJOR ipsecifid=<if id> moved from
homeless to <ssp name>, but
modify_ipsec_tunl failed
5 MAJOR MAJOR Alloc of newssp for homeless
ipsecifid=<if id> failed
6 MAJOR MAJOR Traffic profile modification:
Connection <conn_name> reset
failed to reset with new parameters:
<error_string>
7 INFO INFO <ISP_MSG_Description_string>
SCS Event Logs

Table 9-187 lists logs related to the connection with the SCS Server.
The events recommended for SYSLOG monitoring may be indicative
of network or SCS Server problems. Administrative action should be
verify connectivity to SCS Server and verify the system integrity of
SCS Server.
Table 9-187
SCS Event Logs

Severity Log Event
Severity
1 CLEAR CLEAR BSN connection UP with <file name>
SCS Log Server <ip address>/<port
number>
2 MINOR MINOR BSN connection DOWN with <file
name> SCS Log Server <ip address>/
<port number>
3 MINOR MINOR spm result unknown
4 CLEAR CLEAR Synchronization between SCS region
server and BSN in-sync, scs ip =
<ipaddress>
5 MINOR MINOR Synchronization between SCS region
server and BSN out-of-sync, scs ip =
<ipaddress>

OA&M 9-303

Severity Log Event
Severity
6 CLEAR CLEAR BSN connection UP with SCS
Monitoring Svr <server_ip_addr>
<portid>
7 MINOR MINOR BSN connection DOWN with SCS
Monitoring Svr <server_ip_addr>
<portid>
8 CLEAR CLEAR BSN connection UP with SCS region
Svr <server_ip_addr> <portid>
9 MINOR MINOR BSN connection DOWN with SCS
region Svr <server_ip_addr> <portid>
10 CLEAR CLEAR BSN connection UP with SCS Pull Svr
<server_ip_addr> <portid>
11 MINOR MINOR BSN connection DOWN with SCS Pull
Svr <server_ip_addr> <portid>
12 MINOR MINOR BSN dropping logs since msg length
<msg_len> greater than expected
value of <expectled_len>
13 MAJOR MAJOR BSN does not have a SCS Pull Svr
configured
14 INFO INFO The EMS Client has notified SCS to
stop sending provisioning requests.
15 INFO INFO The EMS Client has notified SCS to
start sending provisioning requests.
MPLS Event Logs

Table 9-188 lists event logs related to MPLS. The events
with MPLS area.

Table 9-188
MPLS Event Logs

Severity Log Event
Severity
1 CLEAR CLEAR BE-LSP to ip_addr <prefixIpAddr> is
UP (ips_id: <ispid>, Label=
<labelValue>)
2 INFO INFO BE-LSP to ip_addr <prefixIpAddr> is
Down (ips_id: <ispid>, Label=
<labelValue>)
3 CLEAR CLEAR LDP session (LSR is <ldp_id>, isp_id
<ispid>, if_id <if_number>, remote
LSR is <peer_ldp_id>, peer IP addr:
<ipaddress> is UP
4 INFO INFO LDP session (LSR is <ldp_id>, isp_id
<ispid>, if_id <if_number>, remote
LSR is <peer_ldp_id>, peer IP addr:
<ipaddress> is DOWN
5 CLEAR CLEAR TE-LSP to ip_addr <prefixIpAddr> is
UP (isp_id: <ispid>, Label=
<labelValue>)
6 INFO INFO TE-LSP to ip_addr <prefixIpAddr> is
Down (isp_id: <ispid>, Label=
<labelValue>)
7 CLEAR CLEAR RSVP-TE session (isp_id <ispId>,
if_id <IFNumber>, end_point
<PrefixIpAddr>, tunnel_id
<tunnel_id>) is UP
8 INFO INFO RSVP-TE session (isp_id <ispId>,
if_id <IFNumber>, end_point
<PrefixIpAddr>, tunnel_id
<tunnel_id>) is DOWN
9 CLEAR CLEAR MPLS Interface <if_name> (on trunk
if_id <IFNumber>, isp_id <ispid>) is
UP
10 INFO INFO MPLS Interface <if_name> (on trunk
if_id <IFNumber>, isp_id <ispid>) is
DOWN
OAM Event Logs

The event logs related to OAM Manager are detailed in Table 9-189.

OA&M 9-305
Table 9-189
OAM Event Logs

Event Console
Severity Log Event
Severity
1 MINOR MINOR Reached maximum OAM AIS/RDI
outage connections of
<outage_conn>; Not marking down
any further connection
2 INFO INFO OAM AIS/RDI outage condition is
cleared
3 MAJOR MAJOR OAM indicated connection <conn>
<vci_num> down
4 MINOR MINOR OAM indicated connection <conn>
<vci_num> up
SPS Event Logs

Table 9-190 lists event logs related to SPS. The events recommended
for SYSLOG monitoring may be indicative of problems with SPS
manager.
Table 9-190
SPS Event Logs

Severity Log Event
Severity
1 MINOR MINOR <spsmgr> ISP <ispid> addr <ipaddr>
subnet record not found
2 MINOR MINOR <spsmgr> ISP <ispid> subnet
<subnet> addr_in_use 0 but
subnet_session_usage <usage>
LFIB Event Logs

Table 9-191 lists event logs related to LFIB. The events recommended
for SYSLOG monitoring may be indicative of problems with LFIB.

Table 9-191
LFIB Event Logs

Severity Log Event
Severity
1 CLEAR CLEAR E-LSP map <ELSPName> (isp_id
<ispId>) added successfully
2 INFO INFO E-LSP map <ELSPName> (isp_id
<ispId>) deleted successfully
IGMP Event Logs

Table 9-192 lists event logs related to IGMP. The events
with IGMP.
Table 9-192
IGMP Event Logs

Event Console
Severity Log Event
Severity
1 INFO INFO Node <Node_number> reached max
igmp join limit (<max_join_limit>)
IPHC Event Logs

Table 9-193 lists event logs related to IP Health Check (IPHC). The
events recommended for SYSLOG monitoring may be indicative of
problems with registered IP addresses.
Table 9-193
IPHC Event Logs

Severity Log Event
Severity
1 INFO INFO IpAddr <ipaddr> (isp <ispname>)
marked alive by health-check type
<iphc_type>
2 INFO INFO IpAddr <ipaddr> (isp <ispname>)
dead alive by health-check type
<iphc_type>

OA&M 9-307
MPLS VRF Event Logs

Table 9-194 lists event logs related to MPLS VRF. The events
with MPLS VRF area.
Table 9-194
MPLS VRF Event Logs

Severity Log Event
Severity
1 CLEAR CLEAR VRF VPN <vfr_name> is ACTIVATED
in ISP <ispname>
2 INFO INFO VRF VPN <vrf_name> is
DEACTIVATED in ISP <ispname>
PPPOE Event Logs

Table 9-195 lists event logs related to PPPOE. The events
with PPPOE sessions.
Table 9-195
PPPOE Event Logs

Event Console
Severity Log Event
Severity
1 MAJOR MAJOR DOS ATTACH on conn <connid> tunl
<tunilId>
2 MAJOR MAJOR Found hung session: Tunnel
<tname> (tid= <tid>), mac= <mac>,
conn= <connid>, sid= <sid>
3 INFO INFO Recovered hung session: Tunnel
<tname> tid= <tid>), mac= <mac>,
conn= <connid>, sid= <sid>
System Monitor Event Logs

Table 9-196 lists event logs related to System Monitor. The events
with system resources.

Table 9-196
System Monitor Event Logs

Severity Log Event
Severity
1 MINOR MINOR ALARM: slot <SlotId> port <PortId>
thresh <ThresholdLevel> subs
<SubscriberCount>
2 CLEAR CLEAR CLEAR: slot <SlotId> port <PortId>
thresh <ThresholdLevel> subs
<SubscriberCount>
3 INFO INFO Connection Monitor found
<connTrapTotal> PPPOE hung
sessions, successfully cleaned
<CommonTrapCleanCount>
Flow Management Event Logs

The event logs related to flow Management are detailed in Table 9-
197
Table 9-197
Flow Management Event Logs

Event Console
Severity Log Event
Severity
1 INFO INFO Flow Management Service:

Subscriber <subname> first drop
starts at <numberOfMinute> minutes
ago, current drop count <count>
(Flows: Maximum configured
<configuredFlow> current
<currentFlow> prflows <prFlow>
CLI Event Logs

Table 9-198 lists the event logs generated when the CLI commands
are executed. These events themselves are not indicative of any
problems, but provides information what has been modified using CLI
commands.

OA&M 9-309
Table 9-198
CLI Event Logs

Severity Log
Event
Severity
3 INFO INFO This log is generated when the “set
quickstart” CLI command changes
the management IP address. The log
text is as follows:
“There is set operation in CLI: <CLI

command> changed management IP
address in config object=<objectId>
isp=<ispName>”
BGP Event Logs

The event logs related to BGP are detailed below:
Table 9-199
BGP Event Logs
Event Syslog Event Disk and Console Event Text Event Description
Number Severity Event Severity
1 INFORMATIONA INFORMATIONAL “CLEAR, Route The BGP connection

L Refresh Capable with the peer has
BGP Peer come up. Both the
Notes: IP_Address local & remote nodes
(isp_id ISP_ID) is have advertised
severity = CLEAR UP” support for the route
refresh capability.
2 INFORMATIONA INFORMATIONAL “INFO, Route BGP Peer down.

L Refresh Capable
BGP Peer
Notes: IP_Address
(isp_id ISP_ID) is
severity = CLEAR DOWN”
3 INFORMATIONA INFORMATIONAL “CLEAR, ORF The BGP connection

L Capable BGP with the peer has
Peer IP_Address come up. Both the
Notes: (isp_id ISP_ID) is local & remote nodes
UP” have advertised
severity = CLEAR support for the ORF
capability.

Event Syslog Event Disk and Console Event Text Event Description
Number Severity Event Severity
4 INFORMATIONA INFORMATIONAL “INFO, ORF BGP Peer down

L Capable BGP
Peer IP_Address
Notes: (isp_id ISP_ID) is
DOWN”
severity = CLEAR
DHCP Event Logs

The event logs related to DHCP are detailed below:
Table 9-200
DHCP Event Logs
Event Syslog Event Disk & Event Text Event Description

Number Severity Console
Event
Severity
1 INFO INFO Communication The connection

failure with DHCP between GGSN and
server on ISP DHCP server has
<isp_id> DHCP failed.
Profile
<profile_name>
2 INFO INFO Communication The lost connection

failure clear with between GGSN and
DHCP server on DHCP server is UP
ISP <isp_id> now.
DHCP Profile
<profile_name>
GuardByte Event Logs

These logs are generated from a robustness feature that resolves
some SSM failure scenarios. These example logs below indicate that
an SSP 11/4/1 encountered an error, but that SSP simply corrected

OA&M 9-311
the error without system impact. The Guard Bytes prevent the SSM
from crashing.
Mon 06-Mar-2006 03:17:03 11/4/1:DBG Manager 0 1 1 INFO

DBGMSG_I: GuardBytes trampled @ pClBuf=0x27a0550, clSize=128,
clPoolPtr=0xd79964, count=4, GuardPattern=0xabababab.
DBGMSG_I: GuardBytes:
0x27a0530: abababab abafabab *........*
0x27a0540: abababab abababab abababab *............*

DBGMSG_I: Likely culprit @ pClBuf=0x27a04b8, clPoolPtr=0xd79964.
DBGMSG_I: Overrun Cluster:
0x27a04b0: 027a0258 38a8ee01 *.z.X8...*
0x27a04c0: ff000000 00000004 30c00002 00030068 *........0......h*
0x27a04d0: 00ad0003 000000ac 00030000 00000000 *................*
... <snip> ...
0x27a0510: 000000c4 000567c8 00000010 ac1f3b19

*......g.......;.*
0x27a0520: 00000000 0090cfbd 7d410000 00000000
*........}A......*
0x27a0530: 23f3c030 01f3a8be
*#..0....*
Event Trace 9
Event trace provides operators with the ability to target specific PDP
sessions for tracing by allowing operators to provision subscribers’
MSISDN or IMSI. Once a PDP Create Request message is received,
the trace target database is searched. If a match occurs, the trace is
turned on for that session and the trace information is delivered to the
event queue. The event queue is read by the trace task which formats
and displays to the required output device. The output device may be
CLI (i.e. Telnet session or GGSN console) or local disk.
CLI commands are provided to activate and deactivate the event trace
and to add/modify/delete/show up to a maximum of 10 tracing entries.
Each entry can be activated or deactivated and survives the system
reboot. During CPU and memory overload conditions, the event trace
logs will not be generated.
Trace events delivered to disk are written to separate trace files under
path ‘/disk/log’. The filename can be input by the operators during
provisioning. These files are checked for removal during add, modify

and delete targets CLIs. During disk overload, files are not written to
disk.
There are two kinds of event logs generated for the event trace:
• Event Trace Logs - During normal operation, various GTP,

RADIUS, DHCP and Prepaid events trigger information and GTP,
RADIUS, DHCP and Prepaid event message trace logs for
targeted subscribers are delivered to the Telnet session, GGSN
console or disk.
• Standard Event Logs - Standard event logs are generated for event
trace and PDP session activation and deactivation.
Session tracing activation/deactivation only takes affect during initial
session activation. Any sessions associated with the traced MSISDN
or IMSI that already exist at the time the MSISDN or IMSI is added to
the trace tool database will not be traced.
If a PDP Create Request would match more than a single entry in the
trace-tool database, it may be difficult to determine in advance which
trace-tool session will be activated for that PDP session. For GTP
version 0, the GGSN software searches for a matching IMSI in the
trace-tool database before searching for an MSISDN match. For GTP
version 1, the search order depends on the order of the IEs within the
PDP Create Request message.
Event Trace Logs

There are two basic kinds of GTP, RADIUS, DHCP and Prepaid event
trace logs, informational and messaging. Examples of the two types of
logs are shown below:

OA&M 9-313
• Informational RADIUS Access Request event

23-Oct-2007 08:04:05
Node: 2/4/2 Message Timestamp: Tue 23-Oct-2007 08:04:03.841 Radius Access
Request Message Event
Trace Session ID: 8
Caller ID: 8388610
Transaction ID: 0
ISP: 11
VPN: 11
Radius Profile: radius_catt_gi
Auth Attributes:
30 Called Station ID: gicradlocrteauth
26 Vendor 10415 Type 18 SGSN MCC MNC: 90150
26 Vendor 10415 Type 5 GPRS QOS Profile: 99-
22131F9314010122060101
26 Vendor 10415 Type 22 ULI: MCC:901 MNC:50-1 LAC:0x0503
SAC:0x0100
1 User Name: test
2 User Password: --------
4 NAS IP Address: 47.104.188.106
26 Vendor 3199 Type 4 Shasta ISOS Version: Shasta 5000:
iSOS (tm), GGSNS6.0I-jyothi_tcp_mss-33
44 Acct Session ID: 2F68BC69381C9FC2
6 Service Type: 2
7 Framed Protocol: 7
61 NAS Port Type: 18
26 Vendor 10415 Type 3 PDP Type: 0x0
26 Vendor 10415 Type 6 SGSN Address: 47.104.153.85
26 Vendor 10415 Type 21 RAT Type : 0x1
31 Calling Station ID: 7962480167
26 Vendor 10415 Type 10 NSAPI: 5
26 Vendor 10415 Type 13 Charging Characteristic: 0008
26 Vendor 10415 Type 2 Charging ID: 0x381c9fc2
RADIUS Access Request event messaging
23-Oct-2007 08:04:05
Node: 2/4/2 Message Timestamp: Tue 23-Oct-2007 08:04:03.841 Sending Radius
Authentication Message To Event
Trace Session ID: 8
Caller ID: 8388610
Src Addr: 47.104.188.106
Dest Addr: 47.104.153.117
ISPID: 11
VPNID: 11
Retry Count: 0
23-Oct-2007 08:04:05
Node: 2/4/2 Message Timestamp: Tue 23-Oct-2007 08:04:03.841 Sending Radius
Access Request Message
Trace Session ID: 8
Hex Dump
7a8afb18> 01 00 01 2F 00 00 41 C6 00 00 16 7E 00 00 27 81 00 00 44 6B
7a8afb2c> 1E 12 67 69 63 72 61 64 6C 6F 63 72 74 65 61 75 74 68 1A 0D
7a8afb40> 00 00 28 AF 12 07 39 30 31 35 30 1A 21 00 00 28 AF 05 1B 39
7a8afb54> 39 2D 32 32 31 33 31 46 39 33 31 34 30 31 30 31 32 32 30 36
7a8afb68> 30 31 30 31 1A 10 00 00 28 AF 16 0A 01 09 F1 05 05 03 01 00
7a8afb7c> 01 06 74 65 73 74 02 12 A5 30 D1 53 14 EE C7 69 F9 21 F2 94
7a8afb90> 65 1C FB EB 04 06 2F 68 BC 6A 1A 3B 00 00 0C 7F 04 35 53 68

7a8afba4> 61 73 74 61 20 35 30 30 30 3A 20 69 53 4F 53 20 28 74 6D 29
7a8afbb8> 2C 20 47 47 53 4E 53 36 2E 30 49 2D 6A 79 6F 74 68 69 5F 74
7a8afbcc> 63 70 5F 6D 73 73 2D 33 33 2C 12 32 46 36 38 42 43 36 39 33
7a8afbe0> 38 31 43 39 46 43 32 06 06 00 00 00 02 07 06 00 00 00 07 3D
7a8afbf4> 06 00 00 00 12 1A 0C 00 00 28 AF 03 06 00 00 00 00 1A 0C 00
7a8afc08> 00 28 AF 06 06 2F 68 99 55 1A 09 00 00 28 AF 15 03 01 1F 0C
7a8afc1c> 37 39 36 32 34 38 30 31 36 37 1A 09 00 00 28 AF 0A 03 35 1A
7a8afc30> 0C 00 00 28 AF 0D 06 30 30 30 38 1A 0C 00 00 28 AF 02 06 38
7a8afc44> 1C 9F C2

OA&M 9-315
In addition to the event trace, the trace tool also displays:
• The processor nodes for all messages

• A second timestamp (Message Time Stamp) to all messages.
All events have two timestamps. The first timestamp indicates the time
at which the log was written to file (or displayed to the screen). The
second timestamp indicates the time at which the log was actually
generated by the processor. An off board tool ttsort.pl is available that
sorts the messages and separates the hex dump messages from the
others. This is available at nortel.com/support (under the tools tab).
Table 9-201
Event Trace Log Types
Log Type Description
GTP Trace Events
Receiving Create Request Event PDP Create Request message
received by GTP
Receiving PDP Create Request Hex Dump of incoming message
Message
Context Creation Success Event Internal GTP data structure created
Transitioning to New State Event Internal GTP state change
Authentication Request Event An internal AAA event that
indicates GGSN is about to send an
authentication request
Radius Access Request Message A decoded Authentication Request
Event message to be sent to RADIUS
Radius Access Accept Reply Event A decoded Access Accept message
received from RADIUS
Address Allocation Requesting Event Internal GTP to AAA Manager Event
Event
Authorization Pending Event Waiting for response from AAA
Manager
Accounting Request Event Internal AAA event to prior to
sending Accounting Request
message
Radius Accounting Request Session A decoded RADIUS Accounting
Start Event Start message to be sent to
RADIUS
Accounting Request Success Event An internal AAA event to indicate
RADIUS Accounting message has
been sent to RADIUS server


Radius Accounting Reply Session An internal AAA event to indicate
Start Event RADIUS Accounting Start response
has been received from RADIUS
server
Radius Accounting Request Session A decoded RADIUS Accounting
Stop Event Request Session Stop message to
be sent to the RADIUS server
Radius Accounting Reply Session Internal AAA event to indicate a
Stop Event RADIUS Accounting Replay for the
Session Stop has been received
Radius Access Reject Reply Event Internal AAA event to indicate a
RADIUS Access Reject reply
message has been received from
RADIUS server
Radius Access Challenge Reply Message generated if the Access
Event Reply message received from the
RADIUS is an Access Challenge
Radius Reply Unrecognized Event This event is generated when the
auth response from the radius
server is not recognized (i.e. it is
not an Access Accept, Access
Reject, Access Challenge).
Radius Request Unrecognized Event This event is generate when the
accounting request being sent by
GGSN's AAA software is not
recognizable (i.e. not a Acct Start,
Acct Stop, Acct Interim).
Radius Accounting Request Session A decoded RADIUS Interim
Interim Event Accounting Request message prior
to sending the message to RADIUS
server
Radius Accounting Reply Session Internal AAA event on receiving
Interim Event RADIUS Interim Accounting Reply
Radius Accounting Reply Unknown This event is generated when the
Event accounting reply from the RADIUS
server doesn't match one of these:
Acct stop, Acct start, Acct interim.
Sending Radius Authentication Internal AAA event prior to sending
Message To Event RADIUS Access Request message
to RADIUS
Sending Radius Accounting Message Internal AAA event prior to sending
To Event Radius Accounting Request
message to RADIUS
Address Allocation Success Event AAA Manager reply success to GTP

OA&M 9-317

Authorization and Address Allocation Authorization and Address
Failure Event Allocation Failure
Authorization and Address Allocation Internal Interface Event, reply
Reply Event received
Prepaid Auth Request Event Internal GTP to Prepaid Service
request
Setup Session Event GTP session control-plane setup
Prepaid Auth Success Event Prepaid service returns Auth
Success to GTP
Dataplane Setup Success Event GTP session datapath was setup
successfully
Radius Session Mode Event Entered Radius session-mode
processing
Radius Session Mode Timeout Event Timeout waiting for radius session-
mode response
Wrap Session Event Indicates the session requires
WRAP session mode processing
Radius Acct Response Success Internal Radius Accounting
Event response to GTP
Wrap Response Session Mode Event Entered Wrap session-mode
processing
Wrap Response Session Mode Timeout waiting for Wrap session-
Timeout Event mode response
DHCP Relay Ack Event Internal DHCP response to GTP
DHCP Relay Timer Event Starting DHCP Relay timer
DHCP Relay Timeout Event DHCP Relay timeout occurred
Prepaid ReAuth Event GTP requests prepaid re-
authorization
IP Address Assigned Event IP address has been assigned to
PDP session
Secondary Create Event Received create request for
Secondary PDP session
Map PPP to PCO Event PPP dataplane addresses being
mapped to session PCO data
structure
Proxy PPP Conn Event GTP-LT2P Tunnel connection
established
Prepaid Update ReAuth Event Request reAuth on receipt of PDP
Update Request
Receiving Update Request Event PDP Update Request received by
GTP


Receiving PDP Update Request Hex Dump of incoming PDP Update
Message Request
Receiving PDP Delete Request Event PDP Delete Request received by
GTP
Receiving PDP Delete Request Hex Dump of incoming PDP Delete
Message Request
Receiving PDP Update Response PDP Update Response received by
Event GTP
Receiving PDP Update Response Hex Dump of incoming PDP Update
Message Response
Receiving PDP Delete Response PDP Delete Response received by
Event GTP
Receiving PDP Delete Response Hex Dump of incoming PDP Delete
Message Response
Receiving Error Indication Event Error Indication received by GTP
Receiving PDP Error Indication Hex Dump of incoming Error
Message Indication
Sending Create Response Event PDP Create Response sent by GTP
Sending PDP Create Response Hex Dump of outgoing PDP Create
Message Response
Sending Update Response Event PDP Update Response sent by GTP
Sending PDP Update Response Hex Dump of outgoing PDP Update
Message Response
Sending Update Request Event PDP Update Request sent by GTP
Sending PDP Update Request Hex Dump of outgoing PDP Update
Message Request
Update Request Timeout Event Timeout waiting for Update
Response
Sending Delete Request Event PDP Delete Request sent by GTP
Sending PDP Delete Request Hex Dump of outgoing PDP Delete
Message Request
Delete Request Timeout Event Timeout waiting for Delete
Response
Sending Delete Response Event PDP Delete Response sent by GTP
Sending PDP Delete Response Hex Dump of outgoing Delete
Message Response
IP Session Timeout Event Session exceeded time limit set for
Access Group
Dataplane Delete Timeout Event Timeout waiting for dataplane
delete response

OA&M 9-319

Prepaid ReAuth Timeout Event Timeout waiting for Prepaid ReAuth
response
Dataplane Delayed Delete Timeout Timeout waiting for final billing
Event information from dataplane
processor after session termination
Prepaid Events
Prepaid Auth Request Event Sending Auth request to prepaid
server
Prepaid Reauth Request Event Sending ReAuth request to prepaid
server
Sending Prepaid Request Message Hex Dump of outgoing request
Prepaid Final Request Event Sending Final request to prepaid
server
Prepaid Initial Response Event Receiving Initial response from
prepaid server
Prepaid ReAuth Response Event Receiving ReAuth response from
prepaid server
Prepaid Final Response Event Receiving Final Response from
prepaid server
Receiving Prepaid Response Hex Dump of incoming response
Message
Prepaid Authorization Failure Event Sending Auth failure to GTP
Prepaid ReAuthorization Failure Sending ReAuth failure to GTP
Event
Prepaid Request Timeout Timeout waiting for response from
prepaid server
DCC Initial Request Event Info log. Generated when the initial
CCR is sent to the DCC server
DCC Initial Answer Event Info log. Generated when the initial
CCA is received from the DCC server
DCC Re-Auth Request Event Info log. Generated when re-auth CCR
is sent to the DCC server
DCC Re-Auth Answer Event Info log. Generated when re-auth CCA
is received from the DCC server
DCC Final Request Event Info log. Generated when the final CCR
is sent to the DCC server
DCC Final Answer Event Info log. Generated when the final CCA
is received from the DCC server
DCC Received Message Content Event Hexdump. Generated to dump contents
of DCC CCR.
DCC Sent Message Content Event Hexdump. Generated to dump contents
of DCC CCA.


DCC Redirect Event Info log. Generated when a re-direct
AVP is received from the DCC server
DCC Server Request Event Info log. Generated when a request is
received from the DCC server
DCC Server Answer Event Info log. Generated when an answer is
sent to the DCC server after a server
request
DCC Authorization Failure Event Info log. Generated to display error
code when authorization fails
DCC Tx Timeout Event Info log. Generated when the DCC
session request timer (Tx) expires.
DHCP Events
Receiving Address Request Event Address lease is requested through
DHCP
Receiving Address Release Event Address is released through DHCP
Address Request Error Event Address lease request resulted in
an error
Sending DHCP Discover Message Client is sending DHCP Discover
Event message
Assign Lease ID Event Lease ID is assigned to client
interface
Sending DHCP Packet Message Hex Dump of outgoing DHCP
packet
Sending DHCP Release Message Client is sending DHCP Release
Event message
Receiving DHCP Packet Message Hex Dump of incoming DHCP
packet
Receiving DHCP Offer/BootReply Client receives DHCP Offer/
Message Event BootReply message
DHCP Offer State Selecting Event Client stops accepting any more
offer leases from DHCP servers and
proceeds to selecting an offer lease
Sending DHCP Request Message Client sends DHCP Request
Event message to the server
Cancelling an Address Lease Event Client cancels an address offer
lease
Binding an Address Lease Event Client binds/associates an offer
lease to an address lease request
Receiving DHCP Ack Message Event Client receives DHCP Ack message
Receiving DHCP Nak Message Event Client receives DHCP Nak message
Receiving Invalid DHCP Message Client receives invalid DHCP
Error Event message

OA&M 9-321

DHCP Renewal Timer Expiry Event Offer lease renewal timer expires
Standard Event Logs

Table 9-202 lists trace manager event logs generated for event trace
and PDP session activation and deactivation.
Table 9-202
Trace Manager Event Logs

Number
1 INFORMATIONAL “INFO, Session Tracing Tool Session tracing has been

Activated” activated
2 INFORMATIONAL “INFO, Session Tracing Tool Session tracing has been

Deactivated” deactivated
3 INFORMATIONAL “INFO, Non-Session Tracing Non-session tracing has

Activated” been activated
4 INFORMATIONAL “INFO, Non-Session Tracing Non-session tracing has

Deactivated” been deactivated
5 INFORMATIONAL “INFO, Session Tracing The specified MSISDN or

Target: target_type IMSI tracing session has
target_identifier Activated” been activated
Notes:
target_type is the string

“msisdn” or “imsi” and
target_identifier is the
corresponding MSISDN or
IMSI
6 INFORMATIONAL “INFO, Session Tracing The specified MSISDN or

Target: target_type IMSI tracing session has
target_identifier Deactivated” been deactivated
Notes:
target_type is the string

“msisdn” or “imsi” and
target_identifier is the
corresponding MSISDN or
IMSI
Four examples of trace manager event logs are shown below:

• Session tracing activation
20-Oct-2003 15:17:11 14/1/1:max,0: 1, 1, INFO, Session Tracing Tool

Activated
• Session tracing deactivation
20-Oct-2003 15:17:11 14/1/1:max,0: 1, 1, INFO, Session Tracing

Tool Deactivated
• Target session activation
20-Oct-2003 15:17:11 14/1/1:max,0: 1, 1, INFO, Session

Tracing Target 012345678901234
Activated
• Target session deactivation
20-Oct-2003 15:17:11 14/1/1:max,0: 1, 1, INFO, Session Tracing

Target
012345678901234 Deactivated
System Time 9
The system time on the Nortel GGSN can be set via the CLI
command, SCS GUI or through communication with an Simple
Network Time Protocol (SNTP) server. Internally, the GGSN system
clock uses UTC time. Changes to the system time should be made
when there are no active PDP sessions on the Nortel GGSN. Abrupt
changes to the system time by using the CLI command or the SCS
GUI may result in incorrect time calculations in billing records for
active PDP sessions.
The time zone should be set and used to adjust for local time which
will automatically be adjusted for daylight saving time. This can be
done from the SCS GUI. Therefore, the time zone setting must be
used in order to set the local time and allow for daylight saving

OA&M 9-323
changes. The system clock and time should not be altered for these
purposes.
Software Optionality Control (SOC) 9

This feature provides the capability to activate optional feature(s)
using license key(s). It allows customers to buy features which are
activated on the product via supplied license keys entered via the
Service Creation System (SCS) GUI. So that unauthorized use of the
functionality offered can be prevented.
On input of valid license key(s) in SCS, the feature(s) can be enabled

in the network managed by that SCS. SOC offers the following
capabilities:
• Provides a GUI interface to enter license keys that grant the

operator the right to use a given optional feature(s).
• Provides centralized key management for validating & storing of
license keys, provide transparency to optional feature from license
key management.
• Creates a session log on SCS and event log on GGSN for optional
feature activations which occur in the SOC functionality.
Active Session Management (ASM) 9
Another tool available to the operator from the device monitoring
window is the ASM. It provides the operator with a way to display
information associated with active PDP sessions. Also, the ASM
allows active PDP sessions to be closed.
The PDP sessions are queried or closed by matching criteria

including:
• Find all PDP sessions with a given MSISDN with/without NSAPI.

• Find all PDP sessions associated with a range of MSISDNs.
• Find all PDP sessions associated with a given MSISDN on any
device.
• Close all PDP sessions associated with a given MSISDN with/
without NSAPI.
• Find all PDP sessions associated with an IP address with/without
NSAPI.
• Find the PDP session associated with an IP address on a given
VPRN with/without NSAPI.
• Find all PDP sessions associated with an IP address for any
Connection ISP on the device.

• Close a PDP session associated with a given IP address with/

without NSAPI.
PDP sessions exist in a real-time environment. The ASM function
takes a snapshot of the current PDP context information. PDP context
information queried at different points in time may be different. For
example, QoS information and packet information will vary with time.
MSISDN range and NSAPI are mutually exclusive; only one is

available for MSISDN queries.
Two main search criteria are the MSISDN and IP Address with
optional VPRN name. Figure 9-12 shows the MSISDN query window.
Figure 9-12
Device Monitoring ASM Page - MSISDN Query
Figure 9-13 shows the IP/VPRN query window.

OA&M 9-325
Figure 9-13
Device Monitoring ASM Page - IP Query
The following table lists the range and default value of each field on
the ASM window.
Table 9-203
Device Monitoring ASM Tab
Default
Field Range Description
Value
Filter MSISDN MSISDN Display the MSISDN query selection

Sessions by fields
IP Display the IP Address and VPRN

Name query selection fields

Table 9-203
Default
Value
Data Mode Brief Brief Brief information set will be retrieved

Detail Detailed information set will be
retrieved
Find Brief information set will be retrieved

MSISDN for any MSISDN on any device where
the SCS user’s ISP has an
appearance. Available only with
MSISDN filter.
Find IP Brief information set will be retrieved

for any IP address on any ISP on the
device.Available only with IP filter.
Input 4 - 15 digits None User enters digit string of the

MSISDN MSISDN number
MSISDN 1-5 1 A contiguous range of MSISDNs.

Range
Input NSAPI 5 - 15 None Network Service Access Point

Identifier
Input IP IP address None User enters IP address in dotted

Address decimal format
Selected VPRN name None Display only of the VPRN name

VPRN selected.
Select VPRN Pops up a window for the SCS user

to select a VPRN name. Selection of
VPRN name is optional

OA&M 9-327
Table 9-203
Default
Value
Retrieve Initiates a query. Valid selection

Sessions criteria or a selected PDP context
session is required.
Close Closes all PDP context session (s) of
Session the selected PDP context session. A
PDP context session in the Session
List panel must be selected. The
“Filter Sessions by” value indicates
whether the MSISDN is used to close
all PDP context sessions based on
MSISDN or the IP address is used to
close the PDP context session with
the IP address.
Help Pop-up window displays help

information for the ASM functionality
Close Close the ASM monitoring window
The following table lists the PDP session information displayed on

Device Monitoring ASM page based on the selected search criteria.
The QoS Profile information in the PDP session is defined in related
3GPP specification.
Attention: Aggregation APNs are not reflected in the counters.
Table 9-204
Displayed PDP Session Information
PDP Data Mode Description

Session
Field
MSISDN Brief, Detail, Find Mobile MSISDN

MSISDN, Find IP
IP Address Brief, Detail, Find Mobile end user

MSISDN, Find IP address
Version Brief, Detail, Find IP GTP protocol version
number
APN Brief, Detail, Find IP Destination APN of the

PDP session


Session
Field
ISP Brief, Detail, Find IP The ISP of the PDP

session
User Name Brief, Detail, Find IP Mobile user name
PDP Type Brief, Detail, Find IP ETSI or IETF

Organizatio
n
PDP Type Brief, Detail, Find IP IP or PPP PDU type

Number
GTPP Brief, Detail, Find IP GTP accounting

Enabled enabled
RADIUS Brief, Detail, Find IP RADIUS Accounting

Enabled enabled
Activation Detail PDP session
Time activation timestamp
NSAPI Detail Mobile NSAPI if input

NSAPI is supplied
Number of Brief, Detail, Find IP The number of

PDP primary PDP sessions
Contexts in in the bundle
bundle
Prepaid Brief, Detail Prepaid enabled
Enabled
Delay Class Detail GTP version 0 and

version 1 QoS Profile
information
Reliability Detail GTP version 0 and

Class version 1 QoS Profile
information
Peak Detail GTP version 0 and

Throughput version 1 QoS Profile
information
Mean Detail GTP version 0 and

Throughput version 1 QoS Profile
information
Precedence Detail GTP version 0 and

Class version 1 QoS Profile
information

OA&M 9-329

Session
Field
Allocation/ Detail GTP version 1 QoS

Retention Profile information
Priority
Class
Traffic Class Detail GTP version 1 QoS

Profile information
Traffic Detail GTP version 1 QoS
Handling Profile information
Priority
Class
Delivery Detail GTP version 1 QoS
Order Profile information
Delivery of Detail GTP version 1 QoS

Erroneous Profile information
SDUs
Maximum Detail GTP version 1 QoS

SDU Size Profile information
Maximum Detail GTP version 1 QoS
Bitrate for Profile information
Uplink
Max Bitrate Detail GTP version 1 QoS

for Profile information
Downlink
Guaranteed Detail GTP version 1 QoS

Uplink
Guaranteed Detail GTP version 1 QoS

Downlink
Residual Bit Detail GTP version 1 QoS

Error Ratio Profile information
SDU Error Detail GTP version 1 QoS

Ratio Profile information
Transfer Detail GTP version 1 QoS
Delay Profile information
State Detail The state of PDP

session (e.g.
Established)


Session
Field
Packets Detail GTP packets sent over

Sent the user plane
Packets Detail GTP packets received

Received over the user plane
Num Detail Number of active
Coupons coupons for prepaid
session
Device Find MSISDN GGSN device
CLI Command 9
GGSN CLI command is available through a terminal connected to the
GGSN, either through a Telnet session or connected directly to the console
port connector at the front of the CMC card. Using GGSN CLI commands
for provisioning is not recommended and supported on the Nortel
GGSN. Running off-board Unix scripts is also not supported on
GGSN. Unexpected behaviors may happen by doing so.
Patching System 9
There is a need to patch a live system without impacting the operation
of the tasks being executed by any particular processor. The Services
Edge Router 5500 has a variety of card types with variable numbers of
processors. This patching system addresses the requirements to
patch the CMC card and SSC card.
The primary User Interface is the SCS GUI. Patch statuses are
recorded for synchronization, robustness and reporting. Each patching
action for a device generates a System Information Log. These logs,
along with other system information logs, are displayed as Session
Logs for the device.
Other patching systems provide mechanisms for applying and

removing patches; this system provides the same functionality. The
expected behavior is that patches can be applied and removed without
interruption of service. Although some patches may require task
restarts due to the nature of the bugs or the features in question, no
interruption to service is the primary goal for patching.
Patching requires the Trivial File Transfer Protocol (TFTP) to be

enabled on the SCS Server. GGSNs use this protocol to request and
download software patches from the SCS Server. As configured for
the SCS Server, Solaris TFTP offers no risk to obtain unauthorized file

OA&M 9-331
access or grants of higher system privileges. Since a GGSN may

request patches at any time due to patch activation, software load
changes, reboots, and CMC switchover, TFTP should remain enabled.
Disabling TFTP on the SCS would result in a system that could no
longer be patched and resynch of affected GGSNs would fail.
Upgrade Strategy 9
The SCS Server is upgraded before the GGSN. Newer GGSN
software is not compatible with older versions of the SCS Server.
However, the SCS Server is backwards compatible for two major
versions of GGSN.
SCS Backup and Restore 9

SCS Backup and Restore provides the customer the ability to restore
the SCS system in event the server failure or corruption. The following
backup and restore procedures are supported for SCS.
• Local full system backup and restore.

• Local backup and restore of essential data. Essential data is
configuration data and system fault data.
• Local backup and restore of dynamic data. Dynamic data are
performance counters and logs.
• Remote backup and restore of essential data
• Remote archival and retrieval of dynamic data.
The difference between backup and archive is that, in the case of
archive, the archived data is not supposed to be put back into the
directory they came from, they are meant to be put in an alternate
directory for off-line viewing.
Functional Description
This feature provides the customer the capability to backup the SCS
server either in its entirety or partially so that if the SCS server is
corrupted, the user can restore the previous backup version to bring
the system to the latest functional state. It provides a suite of functions
that separated into two categories: local or centralized.
1. Local Backup and Restore

Locally backup and restore the system either in a complete form or in
partial form.The information backed up is transferred to a permanent
mass storage device (ex. tape drive) during backup. Similarly, a
restore operation can be carried out by transferring the backup files
from permanent mass storage device and restoring to the SCS server.
It breaks down into three ways of backup.

• Full system backup. It enables the user to backup the whole

system down to the OS level, so that if the whole server is
corrupted, the system can be brought back to the latest functional
state.
• Essential system data backup. It allows the user to backup
configuration data, system management data etc, so in case the
database is corrupted, the user can restore the essential data back
to the latest functional state.
• Dynamic data archival and retrieval backup. The backup of
dynamic data is performed online and allowed for later retrieval.
2. Centralized Backup and Restore
Third party tool, Veritas’s backup and restore utility - NetBackup, is
used to remotely backup and restore essential system data and
dynamic data. This allows the customer to manage all backup and
restore operations from a single location.
Local Full System Backup/Restore

The local full system backup/restore solution consists of two tools: one
for the backup and one for the restore. They are supported on Solaris
8.
Full System Backup Tool

The full system backup tool is a Unix shell script based on Solaris
ufsdump command for backing up the file systems to the tapes. The
user launches the tool from the Unix command line to perform the
backup after bring the server to the single user mode.
It supports writing to multiple tapes if the amount of data exceeds the

tape capacity. A log file is generated to record the backup status and
included in the backup.
Full System Restore Tool

The full system restore tool is a Unix shell script based on Solaris
ufsrestore command for restoring the file systems from the tapes. The
user launches the tool from the Unix command line to perform the
restore after booting the server with a CD-ROM and bring the server to
the single user mode.
Essential Data Backup/Restore

The Online Essential Data Backup and Restore are supported in local
and centralized solutions. Provisioning is blocked per SER SCS
backup procedure. The essential data consists of two databases:
LDAP and Solid database and $SCS_ROOT/bin/.scs.config file, since
it is required to rebuild the system.

OA&M 9-333
Local Essential Data Backup and Restore

The local essential data backup/restore solution consists of two tools:
one for backup and one for restore. During these operations, SCS GUI
client is notified that the provision and login are disabled.
Local Essential Data Backup Tool

The local essential data backup tool (SCSAdmin backup system) is a
Unix shell script that automate the backing up of LDAP and Solid
database to tapes. Currently the tool only supports backing up to local
directory, it is enhanced to including an option to let the user to backup
to the tape. The backup process for the enhancement are to first
backup those database to the local directories, then after enabling
user provision, it transfers the backed-up files to the tape. The user
lunches the tool from the Unix command line to perform the backup. A
log file is generated to record the backup status. It is included in the
backup.
Local Essential Data Restore Tool

The local essential data restore tool (SCSAdmin restore system) is a
Unix shell script that automate the restoring LDAP and Solid database
from tapes. It is also enhance the current SCSAdmin command with
an extra option to handle the tapes. The restore process for the tape
option first transfers files from tapes to the local directory, and then call
the SCSAdmin to restore to the destination directories. The user
launches the tool from the Unix command line to perform the restore
Centralized Essential Data Backup and Restore

The Veritas NetBackup server is used to remotely backup and restore
essential data:
• For backup operations, the user needs to configure a backup class

on the Veritas NetBackup server specifying the backup paths
where the backed-up files are located and the pre_backup script
that is automatically run prior the backup take place. The
procedure is explained in Appendix. The pre_backup script
basically backup the database and put the output files into the
backup paths
• For restore operations, the user selects from the GUI which
backed-up version is going to be restored. Then he needs to
manually log into the client machine to run a post_restore script
provided with the installation package
• We provide both pre/post scripts and instructions to perform
configuration.

Archival and Retrieval of Dynamic Data

The dynamic data is located in $SCS_ROOT/log directory. Online
Data Archival and Retrieval are supported in local and centralized
solutions. Both archival and retrieval operations are performed on-line.
It involves copying log files into a time-stamp embedded directory and
then copying to a tape. After a archival is performed, the archived data
isn’t removed from the system. The following is the list of log data:
Table 9-205
Log files and their locations
Data Location backup or Note

not
PM data $SCS_ROOT/log/preside Y PWI maintain
Logging data $SCS_ROOT/log/ Y service logging data,

Monitor_log tracks service usage.
Monitoring data $SCS_ROOT/log/region/ Y Data that was

isp/*.acc monitored through the
GUI.
Server Logging $SCS_ROOT/log/server Y N/A
Session logs $SCS_ROOT/log/regionN/ Y session information

device/session(M/T).log
Local Archival and Retrieval of Dynamic Data

The local Archive and Retrieval tool is a Unix shell script. The syntax
of using it is in Appendix B. The SCS log file are stored in a directory
with time stamp as a part of the directory name.
Centralized Archival and Retrieval of Dynamic Data

The Veritas NetBackup server is used to remote archive and retrieve
essential data:
• For archive operations, the user needs to configure a backup class

on the Veritas NetBackup server specifying the archival paths
where the archival files are located.
• For retrieval operations, the user selects from the GUI which
archival version is going to be retrieved. The Veritas Restore GUI is
used to navigate through the directory trees to find the files/
directories for retrieval.
Restrictions / Limitations
• For this feature, we assume all components (LDAP, domain server,
region server) are needed to be co-located in one box.

OA&M 9-335
• If the server is configured with Solaris Volume Manager, the SCS

hardware configuration must match the PWI hardware
configuration and must be installed using the PWI installation
procedure.
• For local essential data backup, each backup is kept on a separate
tape. Multiplexing multiple backups into single tape is not
supported.
• For centralized essential data restore and dynamic data retrieval,
the local Veritas NetBackup agent should be installed.
• For essential data restore and dynamic data retrieval, the version
of the backup data and running SCS server must match.
• During backup, installation, patches or upgrades can not be
applied.
• SCS CORBA clients don’t get notifications when essential data is
backup/restored.
Attention: For more details on how to perform Backup and
Restore on the SCS Server, refer to SCS GGSN Upgrade Strategy
(411-5221-309).
GDC Tool (GGSN Data Collector) 9
Background:
For issues that are found in the field, cases are sometimes opened
without sufficient preliminary data.This is due to several reasons
including:
1. Manual data collection on the GGSN can be a time consuming and
tedious task.
2. There is a potential to miss critical information during manual data
collection.
3. Sometimes there is not enough time to manually enter all the
necessary commands before service recovery.
When a CASE is created without a sufficient set of preliminary data, it

is much harder to trouble-shoot and find the root cause of the problem.
Thus it takes longer to arrive at the resolution.

Introducing GDC (GGSN Data Collector)
GGSN Data Collector (GDC) is designed to minimize the challenges

associated with manual data collection, and to ensure that a sufficient
set of preliminary data is collected when the issue is first encountered.
GDC is included and delivered to the customer in SCS package.

Customers have access to this tool at $SCS_ROOT/tools/gdc/dc folder.
Access details of GDC by running "gdc-help", or by reading the

gdc.README file which is included within the gdc package in
$SCS_ROOT/tools/gdc/dc.
Note that GDC must be executed as root on the SCS server.
Recommendations:
Customers should run GGSN Data Collector during the time window in
which the GGSN is experiencing a problem. The output should then be
made available to Nortel at the time of case creation.
Running GDC:
GDC has several options that allow the user to select the type of data
to be collected. If you’re not certain about which type of data to collect
for the issue you’re seeing, you may choose all of the applicable
options, or the “-all” option.
Examples:
./gdc -ggsn -dest=/shasta/scs/my_data
./gdc -ggsn -core -scs -dest=/shasta/scs/my_data
./gdc -all -dest=/shasta/scs/my_data
Some GDC options are listed below. Enter “./gdc -help” to see a full
list of options and detailed usage instructions, and note the warnings
section.

OA&M 9-337
Table 9-206
GDC Options
Option Description
-ggsn Collect data from the GGSN: show commands, log files,
etc.
-core Collect core files from the GGSN.
-scs Collect data and files from the SCS server.

-perf Collect data and files from a Nortel performance server.
-all Equivalent to specifying all four of the above options: -

ggsn -core -scs -perf
-lite Collect only parf of the second sample of show

commands. Valid only with the -ggsn or -all options.
-help GGSNS 5.0.1

- Display the version of GDC.
version
Products and Releases:
The information in this bulletin is intended to be used with the following

products and associated releases:
Product Release
GSM-Packet Core-GGSN Shasta-GSM GGSNS 4.1.1
GSM-Packet Core-GGSN Shasta-GSM GGSNS 5.0
GSM-Packet Core-GGSN Shasta-GSM GGSNS 5.0.1
GSM-Packet Core-GGSN Shasta-GSM GGSNS 6.0i

UMTS-Packet Core-GGSN Shasta-UMTS GGSNS 4.1.1
UMTS-Packet Core-GGSN Shasta-UMTS GGSNS 5.0
UMTS-Packet Core-GGSN Shasta-UMTS GGSNS 5.0.1
UMTS-Packet Core-GGSN Shasta-UMTS GGSNS 6.0i


10-1
Product limitations 10
This chapter specifies the limitations of GGSN functionality on the Nortel
GGSN. The limitations are grouped into the following functional areas:
• GGSN Hardware
• GGSN and SCS Software
• GTP and GTP’ Protocol Interface
• RADIUS Authentication and Accounting
• DHCP Address Allocation
• SCS Provisioning
• OA&M
• GGSN QoS
• APN
• Prepaid Service
• IP Services
• IP Routing
GGSN Hardware 10
1. Two USB ports are present on the CMC3 faceplate, however, they
are not supported. No USB ports are present on the CMC2 card.
2. If the last SSM or SSC goes out of service or is disabled, all access
subscribers on the GGSN also go out of service and do not come
in service once the SSM or SSC is brought in service. To bring the
access subscribers back in service, access subscribers should be
reconfigured from the SCS.
3. If the last SSM or SSC goes out of service or disabled, all the VRF
subscribers may not come up after the SSM or SSC is brought in
service. To bring the VRF subscribers back in service, theVRF and
the subscribers should be reconfigured from the SCS.
4. The SSC3 is incompatible with the SFC1 and should only be used
with a CMC3 card and a SFC2 card.

10-2 Product limitations Copyright © 2000–2008 Nortel Networks
5. GGSN Ethernet Limitation:

— CMC ports are not intended to carry traffic at the rate of a line
card but rather are for OA&M purposes.
— Multiple Ethernet connections with overlapping sub-nets for
different ISPs are supported with the following one restriction:
The overlapping subnets must be on different Ethernet ports
(even being shared by the same EPIF). This restriction is
required for ARP and multicast forwarding.
6. File Operations: When simultaneous file manipulations are done on
thousands of files the GGSN can go into overload. For instance if
multiple sessions are doing a DIR and a remove file is being
performed on large (hundreds/thousands) number of files the
GGSN can go into overload. The GGSN will recover from overload
once the commands have finished processing. In GGSN 5.0.1 the
number of files that can be deleted at a time is limited to 100 files. If
more that 100 files are being concatenated due to a wildcard, a
warning is displayed and operation continues. After around 100
files are removed another message is displayed and the command
stops. DIR command is also modified. If a wildcard is given and
after 100 files are concatenated, a warning is sent to the screen
and files are displayed. After 100 files are displayed another
warning is generated asking user to turn on paging to page 100
listings at a time. The warning also gives the exact command to
use. After the warning the DIR command stops.
7. With little or no traffic running on GGSN, the SSPs may show load
of 30 to 40% even when the CMC processor load remains fairly low
(around 6%). Since the SSPs run a timer based process that
constantly wakes up to take any new actions, there is no impact on
the capacity of GGSN.
8. When CMC core files are generated, the timestamps of the files are
in UTC time, not in the relevant timezone time as for other files.
The event logs on the GGSN and the core files themselves contain
the time of the crash relevant to the timezone setting of the GGSN,
so there is no impact on crash analysis based on the core files.
GGSN and SCS Software 10

1. GGSN Overload Limitation:
— GGSN takes 3 consecutive 300 second samples with CPU
occupancy greater than the overload threshold to go into
overload.
— ‘show overload cpu’ command shows 100% CPU for P1 even
when the ‘show cpu’ command shows 85% idle.

Product limitations 10-3
— ‘show cpu’ command may show a higher CPU utilization as

compared to ‘show overload cpu’ command, as the later
ignores the low priority task’s CPU utilization for its
computation.
2. Telnet Sessions on the GGSN: No more than 19 telnet sessions on
the GGSN should be open at any one time.
3. VNC Client Support: Some versions of VNC UNIX Client Software
are not compatible with the SCS Client, which inhibits the SCS
Client from opening.
• Supported Configuration
— VNC Client using the 3.3 protocol – VNC Server for Win32 4.0
— VNC Servers: vnc_sun4_sosV_5.5 and VNC 3.3.3r2 Binary
Distribution for Unix platforms
GTP and GTP’ Protocol Interface 10

GTP accounting limitations are:
1. The sending of Redirection Request message to any CGF other
than the two CGFs provisioned for the GGSN is not supported. A
Redirection Response message with cause value “Service Not
Supported” is returned when receiving the request message. Table
10-1 specifies all possible scenarios for receiving a Redirection
Request message.
Table 10-1
Receiving Redirection Request scenarios
Command From Active CGF From Inactive CGF
Receiving a Redirection Accept the request and Accept the request and
Request message with find alternate CGF. If mark the sender is down.
no Recommended alternate CGF is not
Address IE available, write to the
local disk and mark the
sender is down.
Receiving a Redirection Reject the Request. Reject the Request.

Request message with a
Recommended Address
IE
—sheet 1 of 2—

Table 10-1
Receiving Redirection Request scenarios (continued)
Command From Active CGF From Inactive CGF
Receiving a Redirection Accept the Request. Reject the Request.

Request message with a
Recommended Address
IE that is known and the
same as sender
Receiving a Redirection Accept the request and Accept the request and
Request message with a try to switch to the mark the sender is down.
Recommended Address recommended address.
IE that is known and If unable to switch, write
different from sender to the local disk and mark
the sender is down.
—sheet 2 of 2—
2. All cause values received in a Redirection Request are treated the

same way as “This node is about to go down”.
3. Served PDP address is set to “0.0.0.0” for PPP PDU types in pass
through mode on GGSN and terminated in L2TP tunnel. IP address
is negotiated between the PPP client on the mobile and the LNS in
the far end, GGSN is not involved in the IP address allocation in
this case.
4. In the event that the primary CGF returns to service after a period
of unavailability (by sending the GGSN a Node Alive Request
message) and G-CDR output is being sent to the secondary CGF,
a manual switch of activity must be issued in order that the primary
CGF becomes the active CGF. If the IP address in the IE is
different from the source IP address in the Node Alive Request
message, this message is ignored.
5. If no GTP’ Profile is provisioned and no association between
Device and CGF Profile in GTP tunnel exists, the PDP context can
still be set up. However, no G-CDR is generated for the PDP
context when GTP accounting is selected.
6. The DSCP value set in the GTP’ Profile only applies to the request
messages initiated by Nortel GGSN. It doesn’t apply to the
response messages sent back to CGF.
7. When GTP billing files are read from disk the version of
management extension used to encode the CBB data cannot
change. It is expected that the CGF will be able to handle both the
old and new versions.

8. When reporting the service profile name, tariff profile name, or VPN
name used in a G-CDR or VSA only the first 16 characters are
used. If the name is longer than 16 characters it is truncated.
9. When OID version 1.2.840.113533.4.10.1.1.2 of the CBB
Management extension is used and counts for Content Type Ids
not supported by version 2 are received, the counts for that
Content Type Id will not be placed in the G-CDR. The counts are
counted as usual in the traffic volume container.
10. Secondary PDP context is not supported for PPP PDU. If a
secondary create request is received for the PPP PDU, the call is
rejected with cause value “Unknown PDP Address or PDP Type.”
11. TFT filtering by IPv6 address and/or flow label is not supported as
the GGSN does not currently support IPv6. If these filter types are
included, the GGSN will reject the TFT with the cause code
“Semantic errors in packet filters.”
12. Secondary PDP context is not supported for L2TP VPN or secure
L2TP VPN model for IP PDU. If an APN is requested in a Create
PDP Context Request that is provisioned to use L2TP tunnelling,
the GGSN will reject the request with cause “System Failure”.
13. Uniqueness of the packet filters in a TFT IE or for a bundle is not
verified on the GGSN as the filter precedence will be used. The
TFT filter that first matches the packet, in the precedence order, will
be applied on the packet even though another filter may also match
the packet.
14. For multiple L2TP tunnels from RADIUS, once a tunnel is selected
for a session and that tunnel does not come up, the session will
fail. No other valid tunnels or candidate tunnels are considered
again for the same session.
15. If the system time is changed after configuring the start and stop
times, the change in time will be effective for the automated
transfer only after the current start/stop time expires. After a
system time change, the G-CDR file transfer will be initiated and
stopped at the old system time for the first time. Subsequent
transfers will be initiated and stopped at the new system time.
16. Performing a switch SFC on the Nortel GGSN may result in the
loss of existing PDP sessions or data traffic. Switch SFC may also
affect the PDP context creation, updating and deletion. When
OSPF is in use, the repopulation of OSPF learned routes following
a switch SFC can take significant time. The population time for
OSPF routes increases with an increase in the number of
subscribers present. New contexts and data traffic may not be
possible until the OSPF routes are populated.

17. TCP Out of Sequence Packets - Dropped packets due to TCP out
of sequence scenario for postpaid billing and CTP V1 billing will not
be counted for billing.
RADIUS Authentication and Accounting 10

Limitations for RADIUS Accounting are:
1. When RADIUS Accounting is active, the Application Profile can not
be defined. As a result, the session mode in the Application Profile
will not be effective.
2. RADIUS Accounting does not support partial billing records. All
interim messages have the cumulative session counts.
3. Disabling the Include MSISDN Attribute in the RADIUS Profile (to
prevent the MSISDN being sent outside of the PLMN) prevents the
use of anonymous mode for RADIUS authentication. Anonymous
mode for RADIUS authentication must be turned off manually to
prevent MSISDN from being sent in the RADIUS messages.
4. If the WAP gateway application or other services need the
MSISDN to function properly, do not disable Include MSISDN
Attribute in the RADIUS Profile or Application Profile. Disabling
Include MSISDN Attribute may prevent proper authentication or
accounting needed to support WAP gateway and other functions
that use RADIUS messaging.
5. Session Mode is not supported for PPP PDU type using RADIUS
Accounting.
6. When reporting the service profile name or tariff profile name used
in a G-CDR or VSA only the first 16 characters are used. If the
name is longer than 16 characters it is truncated.
7. If the version 1 VSA is used then byte counts for Content Type Ids
greater than that supported by the version 1 VSA are not placed in
the VSA. The byte counts included as part of the cumulative uplink
and downlink totals.
8. If Radius accounting is used in conjunction with Content Based
Billing, a maximum of 170 unique Content Type IDs are permitted
within one PDP session. Attempts to use more than 170 rates
result in the PDP context being deleted.
9. The Transparent Data VSA is captured only during the setup of
PDP Context based on the RADIUS Access-Accept. It is not
possible to update the Transparent Data VSA with any dynamic
information (e.g. SGSN MCC/MNC change) during the lifetime of
the PDP context.

10. Session billing information could be lost due to failure of SSP card
if the failure occurs when Nortel GGSN is trying to send the
message to server or if the information is in active batch buffer.
11. In a VPN call model setup, when the RADIUS authentication and
accounting messages are sent, the RADIUS response messages
could be dropped if the ISP Firewall policy is configured to accept
only packets from ISP IP address to RADIUS server and reject all
other packets. This is a limitation of distributed AAA and could be
overcome by adding another rule to the firewall policy to accept
packets in the reverse direction i.e. from RADIUS server to ISP IP
address.
DHCP address allocation 10

Limitations for DHCP address allocation are:
1. MPLS VPN network model does not support the DHCP Client
reaching the DHCP Server in the public network with “VPN only”
box checked in the VPRN configuration.
2. The DHCP Relay Agent address based address allocation is
supported only for the Wireless ISP model and GRE VPN model.
3. The DHCP Relay Agent address based address is supported only
using the Fast Ethernet Line Card (FELC) on the Gi interface.
4. The DHCP Relay Agent address based address allocation is not
supported when the DHCP Relay Agent option is selected in the
DHCP Profile and a new VPN name is returned from the RADIUS
authentication.
5. The DHCP Relay Agent address in the DHCP Profile cannot be
configured with the same IP address as Connection ISP, trunk
interfaces and access subscriber in the Connection ISP.
6. The change of DHCP Relay Agent address will not be reflected in
the existing PDP context. As a result, the IP address renewal for
the subscriber may fail because the DHCP response message may
not be able to route back to the GGSN using the old DHCP Relay
Agent address.
SCS Provisioning 10
Provisioning limitations for the GGSN are as follows:
1. Only one Gn ISP and one Ga ISP are supported per GGSN. If
multiple GTP tunnels are configured on a GGSN, this is considered
a configuration error and this configuration is NOT supported.
2. Duplicate APN names on different ISPs on the same GGSN is not
supported. If the same APN is provisioned on different ISPs on the

same GGSN, the APN and subscriber template used for GTP
tunnel setup is undetermined.
3. Error checking for valid ranges of fields used in provisioning is
performed by the SCS Client. If the CORBA API or SCS CLI are
used for provisioning, the operator is responsible for the
correctness of the provisioning information. There may be a
serious performance impact if the provisioned values are out of
range as supported by provisioning through the SCS Client.
4. Interoperability testing is required for the CORBA API between the
customer equipment and GGSN prior to using the CORBA API
provisioning.
5. The Virtual Circuit Identifier (VCI) value in ATM Connection
configuration enforces the restriction that the value cannot be set in
the range of 0 to 31 inclusively since these values are designated
as reserved by the ITU-T and ATM forum. Due to the restriction
change, it is possible that the VCI field may contain these reserved
values from previous releases. The presence of these reserved
values does not affect the operation of the GGSN. However,
subsequent SCS GUI changes to this configuration will require that
the non-standard VCI values be modified.
6. For SCS backup and restore, it is assumed all components (LDAP,
domain server, region server, etc.) are co-located in one box.
7. For local essential data backup, each backup is kept on a separate
tape. Multiplexing multiple backups into single tape is not
supported.
8. For centralized essential data restore and dynamic data retrieval,
the local Veritas NetBackup agent should be installed.
9. For SCS essential data restore and dynamic data retrieval, the
version of backup SCS data must match to the running software.
10. During SCS backup, patches and upgrades cannot be applied.
11. SCS CORBA clients do not get notifications when essential data is
backed up or restored.
12. When provisioning URL Rates or URL IDs for CBB Policy, the
following restrictions are enforced:
— The colon character ( : ) and its equivalent Hex Escape “%3A”
or “%3a” is not allowed in Domain Name. The port number is
configured as part of the five tuple rule used to provision any
CBB policy.
— The number sign character ( # ) is not allowed as part of URL.
— The left parenthesis ( ( ), right parenthesis ( ) ) and double
quotation mark ( “ ) characters are SCS reserved characters

and are not allowed as part of URL. Their equivalent Hex

Escapes must be used if these characters are need to be
entered as part of the URL.
— The asterisk character ( * ) is used for provisioning wildcard
URLs. To configure a URL which contains “*”, “*” in the URL
should be represented in its equivalent escape sequence
“%2A”.
13. Software licensing on a per GGSN basis is not supported.
14. SOC feature inter-dependencies are not supported.
15. New optional features can't be SOC controlled without upgrading
SCS.
OA&M 10
1. Requests for statistics to be collected and sent to the Log Server
may be discarded before being collected when
a) in high capacity/high traffic circumstances or
b) address pool is being modified (Delete/Add operation)
This is because of the low priority of statistical collections. The
statistics that would have been gathered if the request was not
dropped will be grouped with the statistics from next time interval.
2. Private AAA and DHCP server IP addresses are not guaranteed to
be unique. In the case where two or more private AAA/DHCP
server IP addresses collide within the same Gi ISP context, the
counters for the multiple servers will be aggregated. If multiple
AAA/DHCP servers with the same private IP addresses must be
deployed on the same GGSN, it is recommended that separate Gi
ISP contexts be created to avoid the collision of IP addresses and
subsequent aggregation of counters.
3. The timestamp that shows up in the replayed alarm will not be the
timestamp when the event occurred, rather it will be the time when
it was replayed.
4. When requested to replay the traps will be sent to all configured
SNMP agents without any filtering. (Notification profile filters will
not be applied when re-sending the traps).
5. List of saved traps will not survive the reboot or CMC switchover
6. Event trace is not supported with the following deployment models:
L2TP VPN and IPsec VPN.
7. Aggregation APN Sessions Cannot Be Monitored on SCS Client:
PDP sessions, which are associated with services APN calls, can
also be monitored under Monitor---> ISP window. However, PDP
sessions, which are associated with Aggregation APNs, will not be
reflected in the counters under Monitor --->ISP window.

GGSN QoS 10
GGSN QoS limitations are:
1. The GGSN supports QoS only in the marking of data and control
packets. Requests for bandwidth, delay and maximum throughput
are not supported at this time. No resource decisions are made
based on these parameters.
2. The QoS negotiation is not supported on the GGSN. The values of
Allocation/Retention Priority and Traffic Class are the same as
received in the Create PDP Context Response message. The
Reliability Class will be changed to 2 in the Create PDP Context
Response message if it is larger than 2.
3. Support of GTP data packets based on the QoS IE value mapping
to DSCP marking is only for GTP version 1. For GTP version 0, the
QoS IE is not used for determining the DSCP marking for GTP data
packets. A provisioned “default” setting is used for GTP version 0
QoS.
4. The QoS functionality is not supported when interfacing with non-
Nortel equipment that does not send allocation/retention priority
and traffic class information to the GGSN.
APN 10
Limitations of APN are:
1. When single APN is used for redirecting PDP sessions to different
VPNs on a subscriber basis, the RADIUS Profiles provisioned in
different VPNs are required to be the same as single APN. In this
case, all authentication, address allocation and RADIUS
Accounting messages are sent to the same RADIUS Server. It may
be necessary to proxy those messages to different VPNs from the
RADIUS Server.
2. When single APN is used for redirecting PDP sessions to different
VPNs on a subscriber basis, the DHCP Relay Agent is not allowed
to be provisioned in the VPNs.
3. To support the dynamic L2TP VPN for GTP-L2TP tunnel switching,
a dedicated APN is needed for the Single APN configuration.
4. The PDP sessions that encounter unsupported configurations will
be rejected in an aggregation APN.
5. IP Subnet Dedication is required for the Connection ISPs that have
APNs configured for aggregation mode.
6. IP Subnet Dedication requires provisioning summary routes for all
address allocation methods including DHCP and RADIUS address
allocation.

7. The removal of IP Subnet Dedication is not recommended while

active PDP sessions reside on the Connection ISP. If there are
active PDP sessions on the Connection ISP during this
provisioning change, a SCS resync will be required to activate IP
Subnet Dedication.
8. IP Subnet Dedication does not support address range overlapping.
VPN address pools that may contain overlapping addresses will
not use IP Subnet Dedication.
9. It is recommended that modifications to the existing summary
routes be restricted to the maintenance window. Otherwise, the
active PDP sessions should be cleared before the summary route
modification.
10. Active PDP sessions for an aggregation APN are not affected by a
Service Profile modification. The current services will not be
changed to the new services. Only new Aggregation PDP sessions
will use the modified Service Profile.
11. If a subscriber static IP address is included in the Create PDP
Context Request message for an Aggregation APN, the PDP
context is rejected with cause value Service Not Supported.
12. To have visiting GGSN access control enabled in an APN, the
respective Access Control Profile must contain at least 1 entry.
13. The Framed-Pool name string supports only following characters
and the first character can be any lower case letter [a-z]+[a-z,0-
9,_,-,$,%,&,#,:,’,.,/,*]. Also “* “is the only wildcard character which is
supported by Partial address pool names and it can be added only
at the end of the pool name string.
Prepaid Service 10
Limitations for Prepaid Service are:
1. Existing CBB limitations are inherently imposed upon multi-rate
coupons because prepaid depends on the rate markings generated
by CBB.
2. The Service Profile changes are applied to the existing PDP
sessions for Traditional APNs. However, when the CBB Service
Policy is removed from the Service Profile of existing PDP contexts
that are using Rated Coupons, the time/volume usage is no longer
reported and no further reauthorizations occur. For IP PDU, these
PDP contexts are brought down when any new data arrives. For
PPP PDU, PDP contexts remain active without Prepaid billing
function.
3. Service Redirect requires the use of variable rate prepaid rated
coupons. Non-rated coupons are not supported.

4. The enable/disable status of GGSN feature “GPDN Range

Checking” needs to be saved by entering CLI command “save
config qs1”. If the GGSN reboots, the feature will be in the last state
that was saved in qs1 database or in its default state.
5. All DCC timers and time related records are accurate to the
second.
6. The G-CDR traffic data volume is increment each time a subscriber
packet transits in the GGSN. In contrast, the CBB is accumulating
byte counts for later charging. If a partial G-CDR is generated while
CBB is holding uncharged bytes due to TCP sequence, then a
mismatch between the traffic data volume and CBB counts in the
G-CDR would occur.
7. If TCP connection bytes are charged at the URL rate, the time
usage for coupon is not computed for the TCP connection packets
as the CBB classification is not performed for the TCP connection
packets when the packets are received by the GGSN.
8. TCP Out of Sequence Packets - Dropped packets due to TCP out
of sequence scenario for postpaid billing and CTP V1 billing will not
be counted for billing.
IP Services 10
Limitations for IP Services are:
1. URL filtering for streams that are compressed, encrypted, or
otherwise distort the IP packet is not supported.
2. HTTP version 1.0 may not include the host name in the GET
request packet. In this case, Content Based Billing will try to use
the destination IP address as the host name for the received URL
to compare against the provisioned URL.
3. HTTP version 1.1 supports the pipelining of request packets and
response packets. It causes multiple request packets queued up
before receiving any response packets for previous requests. In
this scenario, the accounting rate of the last request packet in the
pipeline is applied to the response packets received in this TCP
connection.
4. The logs for Content Based Billing when filtering by HTTP only
reflect the default rate because the URL matching for determining
the rate of HTTP packets hasn’t occurred when the log is
generated.
5. Uplink data packets are rated after being processed for the GTP
accounting. If the CBB uplink packet causes a G-CDR to be
generated, the rate count of the packet will not be reflected in this
G-CDR. It will be included in the following G-CDR’s rate count.

6. The IP packets after Redirection may be charged with different rate

if the redirected URL is not provisioned with the same rate in
Content Based Billing.
7. At most six service profiles can be merged for IP service policy,
additional profiles are discarded. The decision to discard profiles is
based on precedence. Profiles with the highest precedence are
kept while those lower in precedence are discarded.
8. Once a PDP session is established, additional messages from
RADIUS Server or SCP to change the IP service package are
ignored.
9. Service Redirect is not supported for HTTP1.0 as this protocol
does not support automatic redirection.
10. Service Redirect is triggered by a GET or POST. If a coupon ID
applies to packets in message flows that never contain a GET or
POST, that coupon ID will never trigger Service Redirect.
11. HTTPS and WTLS transaction can not be rated by the Nortel
GGSN due to the nature of the encrypted packet. These packets
will not be candidates for Service Redirect. If their coupon expires,
the PDP session will be dropped.
12. WAP 1.2 redirection cannot change the subscriber provisioned port
that connects the mobile to WAP 1.2 gateway. We can not redirect
a client to a site using a WTLS port.
13. The redirection URI sent to the GGSN from Prepaid Server must
be an absolute URI.
14. Only the commands listed are considered CBB events supported
for Event Based Billing. All event triggers for individual protocols
are pre-defined and not configurable.
15. Event Based Billing only supports non encrypted packets passing
through GGSN as deep packet inspection is required to inspect the
content and match the event triggers commands for specific
application protocol. All encrypted packets may be rated as Default
for a specific application protocol.
16. GGSN does not support WTP re-assembly. If WSP fragmented
PDU’s arrive on GGSN out of order, the event usage may not be
correct.
17. GGSN does not detect the state of the compression client on the
mobile station. After the first compressed packet is received from
the mobile, all downlink packets are sent through the TPO. If the
state of the client on the mobile station changes during a session,
the GGSN does not know about it and does not take any action. In
that case the GGSN may keep sending the download traffic to the
TPO.

18. If the client on the MS is turned on for a subscriber that does not
have the TPO IP service applied, the GGSN would route the
packets if they were regular un-compressed packets. Note that
TPO IP service may be removed when the session is active (e.g.
Qos changes).
19. Only Fast Ethernet (FE) and Gigabit Ethernet (GE) Line Cards are
supported for interworking with the TPO server.
20. TPO only supports interworking for TCP traffic. UDP and other type
of traffic are not supported.
21. The two new TPO RADIUS VSAs that are introduced by TPO are
sent in the RADIUS Accounting START/STOP messages only if
TPO ISP is properly configured and the TPO IP service is applied
to the subscriber at the time of session setup. If TPO IP Service is
added or deleted in the middle of the session, the inclusion of
these new VSAs in the RADIUS Accounting STOP follows the
behavior in the RADIUS Accounting START at the time of the
session setup.
22. For PPP PDU calls type, the GGSN TPO ISP IP Address and the
TPO GRE Key VSAs will not be sent in RADIUS Accounting
START/STOP messages.
23. The configuration of any IP service on a VLAN Access Subscriber
is not supported. This includes both VLAN Wireless ISP and VLAN
VPN network models. IP services can be provisioned via the SCS
GUI, but GGSN will not apply them to the VLAN Access
Subscriber. However, there is no impact to the IP services
configured on the mobile subscribers.
24. Dynamic policy control capability is only supported for aggregation
sessions. If service sessions are configured to interact with a CRF
for dynamic policy control, the GGSN ignores the configuration and
does not contact the CRF for dynamic charging rules.
25. While waiting for a response from the Content Filter Server, any
subsequent HTTP packets on the same connection are dropped.
26. After sending the HTTP block or redirect response to the mobile,
the TCP connection to both the mobile and the HTTP content
server are reset.
27. No blacklisting or caching of response for similar requests is done
within the content filter service of the GGSN.
28. Loss of connection to a Content Filter Server may not be detected
for a maximum of two minutes.
29. The Content Filter Server is connected to the Gi interface of the
GGSN. If VPNs are used, the Content Filter server must be
routable within the VPN.

— Note that with L2TP VPN no services are applied.

30. If the WAP 1.2 URL is segmented across more than one WTP
message, only the portion of the URL contained in the first WTP
message is captured and sent to the Content Filter Server (no
WTP reassembly is done on the GGSN.)
— This behavior is consistent with the current CBB
implementation.
31. For HTTP 1.0 requests, redirection is not supported, so all
redirected or blocked requests will receive a 403 Forbidden status
code response.
32. Only HTTP and WAP protocol method requests supported by
content-based billing in Nortel Networks GGSN release 5.0 are
filtered. All other method requests are always allowed.
33. Historical CFS statistics are only reported for CF servers, which
have remained in the ESTABLISHED state for the entire reporting
interval. All other servers will show all zeros for its counts and will
show no accounting interval duration (start time = stop time =
collection time).
34. SCS logging is not supported for Content Filtering.
35. Though Content Filtering may be provisioned on dedicated
subscribers (access subs), it will not take effect. Instead, it should
be provisioned on the subscriber template(s) associated with the
dedicated subscriber.
36. When provisioning a Content Filter server on a VPN, the VPN must
have its local IP address configured, or else the GGSN will not be
able to establish communications with the Content Filter server. If
the local VPN address is not configured, then the “show cfs”
command will show the servers in that profile as
“DISCONNECTED” with a reason of “VPN LOCAL IP ADDRESS
IS NOT CONFIGURED.“
37. SCS doesn’t support CF policy rules validation for the CORBA
shell command “set svcpolicy rules...”.
38. IP Services for IP in IP is not supported with the following
deployment models: GRE Access Connection, VLAN access
Connection and the VPN models IPsec VPN, GRE VPN, ATM-VC
VPN, MPLS VPN, VLAN VPN.
39. With this feature active, the CBB IP service accounts for the
additional outer 20 byte IP header. Any optional extension headers
(E.G. record router, timestamp) inserted between the outer and
inner IP header are not counted by the CBB service. If optional
headers are present the G-CDR list of traffic volumes and CBB
byte counts will be different.

40. The permitted throughput of the shaping and policing IP services is

less accurate when operating on IP-in-IP tunnelled packets
because the encapsulating 20 byte IP header is not included in the
throughput calculations.
41. Secondary PDP contexts are not supported for subscribers actively
using IP-in-IP tunnelled traffic.
42. For all VPNs VPN + Internet type is not supported.
43. SOC is not configurable through CORBA.
IP Routing 10
1. MPLS is supported only on Trunk Interfaces. The following MPLS
areas are not supported in GGSNS4.0:
— RSVP-TE/TE Tunnels
— ER-LSPs
— Route-Reflector Server
— Hub-and-Spoke VRF support
2. OSPF routing protocol is not supported on CMC management port.
However this port can still support static routes. If OSPF is used in
default ISP for the management network, auxiliary management
ports on line cards and CMC server ports can be provisioned for it.
3. Scaling numbers from Network Engineering suggests that we can
have 512 OSPF adjacencies when subscribers are all area 0 and
part of backbone and also 512 when subscribers are all area 1 and
part of backbone 0. For subscribers all in unique areas but part of
backbone the number of adjacencies is 256. When all subscribers
are running a unique instance of OSPF the number is 95.
4. Other vendors like Cisco will need to implement the DPD keepalive
(as outlined in RFC3706) in order to interwork with the GGSN,
since this is the only keepalive mechanism GGSN plans to support
for non-wildcard IPSec.
5. IPSec MIB Enhancement is not configurable through CORBA.
6. No support for QoS based route selection. The tunnel bandwidth is
used only for signaling via RSVP-TE and not used for path
selection.
Restrictions for the VLAN BGP VPN Solution 10

1. When RADIUS server is inside VPN, during resync, Acct ON
message is sent from the ISP before BGP neighbor is up. Only
after the BGP neighbor is established, GGSN will get routes to the
RADIUS server.

2. When Ethernet port is configured with multiple Ethernet access

connections with unique IP addresses, the data transfer from a
server in the same subnet as the Ethernet access interface may
not be possible. The reason for this behavior is that Ethernet
connection does not respond to ARP requests. After a successful
round trip of a ping packet from the GGSN ISP (through VPN) to
the same host, data can be sent from the server to the Ethernet
interface.
3. When the BGP neighbor for the GGSN VPRN goes down, the BGP
connection for the VPRN is deleted after 120 to 160 seconds. Data
from the mobile could be forwarded through the VPRN for this
duration.
4. RADIUS Accounting-ON packets may be lost if the BGP neighbor
has not been established before Acct-ON packets are sent. This
can be seen if there are more than 120 VPRN's with BGP enabled
are configured.
5. Summary routes are required for all contiguous address pool
ranges from RADIUS/ DHCP.


11-1
Redundancy 11
This chapter discusses redundancy of the Nortel GGSN components
as well as redundancy of external components in the IP network. The
GGSN uses the software redundancy infrastructure of the Nortel
Services Edge Router 5500 to achieve product reliability. The GGSN
also provides physical connection redundancy to a variety of servers in
the IP network.
Nortel GGSN 11
The Nortel GGSN inherits support of hardware and software
redundancy from the Nortel Services Edge Router 5500 (SER 5500).
Redundancy of the various components of the GGSN are described in
the following sections.
Control and Management Card (CMC) redundancy

The GGSN supports hardware redundancy for the CMC. A
configuration with two CMC cards is supported in cold standby mode.
When the active CMC card goes down, all information of the in-
processing sessions, including billing information, which was on the
failed CMC card is lost. However, the billing information on the disk is
kept.
Press the reset button on the active CMC card or on the standby CMC
card will reboot the whole Nortel GGSN shelf.
During the CMC2 to CMC3 upgrade window, the CMC2 and CMC3
can coexist in the same chassis, but redundancy is not supported.
The CMC core dump flag is ignored when the other CMC is not
redundant. A new event log is used to indicate that if the CMC core
dump is disabled.
Subscriber Service Module (SSM) redundancy

The Nortel GGSN provides the support of SSM software redundancy.
Multiple SSMs can be provided on the GGSN, which provide hardware
and software redundancy to the Nortel GGSN. When an SSM goes

11-2 Redundancy Copyright © 2000–2008 Nortel Networks
down, the software on the CMC gets a notification and uses the
existing session information on the CMC to move the active sessions
that were on the failed SSM to a new functional SSM. PDP Sessions
activated on both Aggregation and non-Aggregation APNs are moved
during SSM failure.If all the functional SSMs on the GGSN are fully
occupied, the active PDP sessions on an SSM that fails will not be
able to be moved. The PDP session is taken down.
For SSM redundancy to work properly, the GGSN must be provisioned

for load sharing 2N-type redundancy. Each SSC in the shelf must be
provisioned with another load sharing and redundant SSC that has
equivalent processing capabilities (for example, CPU horsepower,
encryption capabilities, and memory). On a GGSN where SSM
redundancy must be supported, the total number of active subscribers
is 50% that of a GGSN where SSM redundancy is not required, if both
GGSNs have equivalent call models and configuration.
When an SSM fails, all sessions on a failed SSP are moved to a new
SSP. These sessions cannot be distributed to different SSPs. If the
number of sessions moved to the new SSP plus the number of existing
sessions on the SSP exceeds the SSP capacity limit, the sessions
beyond the capacity limit will be taken down.
When a single SSC card failure occurs, the active PDP sessions on
the card will be moved to the SSMs on the other available SSC cards.
However, this scenario is not supported for multiple SSC card failure
on the GGSN.
When the failed SSM or SSC recovers, the non-Aggregation PDP

sessions that were moved during the failure are returned to the original
SSM or SSC. The transferring of sessions back to the restored SSM or
SSC may cause a brief pause in the user data path. For Aggregation
APNs, the moved contexts remain on the new SSMs.
GPRS Tunneling Protocol (GTP)

SSM redundancy provides some software redundancy for GTP. After
the GTP tunnel is set up, if the SSM on which the GTP active tunnel
resides goes down, the GTP software on the CMC receives a
notification and the GTP tunnel is reestablished on another functional
SSM.
The sequence number in the GTP header is reset by the GGSN during
the tunnel move. For both GTP version 0 and version 1, the sequence
number is not used on the GGSN.
The charging data volume on the failed SSM is lost but the charging
duration of PDP contexts are still valid.

Redundancy 11-3
PPP session terminating on the GGSN

SSM redundancy provides software redundancy for PPP over GTP. If
SSM failure occurs after a session is established (that is, after IPCP
finishes the negotiation), the GTP tunnel is moved to a new SSM after
the PPP session is moved. If either the PPP session or the GTP tunnel
fails to move to the new SSM, the PPP session and the GTP tunnel
are taken down.
GTP-L2TP tunnel switching for PPP PDU

SSM redundancy provides the software redundancy for PDP sessions
with GTP-L2TP tunnel switching for PPP PDU type after IPCP finishes
the negotiation. If a non-SER 5500 is used for the LNS, SSM
redundancy is not supported since the L2TP sequence number is
missed.
GTP-L2TP tunnel switching for IP PDU

SSM redundancy provides software redundancy for PDP sessions
with GTP-L2TP tunnel switching for IP PDU type after the Create PDP
Context Response is sent back to the SGSN. This means SSM
redundancy takes effect after all PPP, L2TP and GTP tunnel sessions
have been successfully established. If a non-SER 5500 is used for the
LNS, the SSM redundancy is not supported since the L2TP sequence
number is missed.

An SSM failure during a PDP session using Content Based Billing may
cause subscriber packets to be charged at an incorrect rate. If an SSM
fails during a PDP session, the session is recreated on an alternate
SSM. If the subscriber had one or more active flows at the time of the
failure, the flows may continue when the session is recreated on the
alternate SSM. It also depends on if the flows have timed out or not. If
the flows have not timed out, some flows which were started on the
previous SSM may be charged at full rate on the new SSM, regardless
of the rate which they were charged on the previous SSM. Flows that
require the GGSN to access to the first packet of the flow have this
characteristic. HTTP and FTP are two examples of protocols which
exhibit this behavior during an SSM failure.
Switch Fabric Card (SFC) redundancy

SFC redundancy is supported as on the Services Edge Router.
When the active SFC card is pulled without doing a switch SFC, the
fabric will lose its clocking, possibly causing the CMC to crash. Before
pulling the SFC card, a switch SFC command needs to be executed so
the redundant SFC will become active and be responsible for the
switch clock. In the advent of a real active SFC failure, the inactive
SFC will become the active SFC automatically and take over the clock.

Interface redundancy
Interface redundancy is supported as part of the Services Edge Router
functionality. This redundancy works only when the GGSN node IP
address is provisioned on the DNS Server. It is recommended to
provision a minimum of two interfaces on the Gn ISP and on each
Connection ISP on the GGSN for redundancy purposes.
GRE Tunnel redundancy

The GRE VPN model does not support tunnel redundancy. The private
Intranet can be divided into smaller groups with one GRE tunnel per
group. However, there is no tunnel redundancy across the GRE
tunnels on the GGSN.
ATM port redundancy

The GGSN supports software linear Automatic Protection Switching
(APS) for the OC-3 ATM single-mode and multi-mode Line Cards in
the form of 1+1 unidirectional, non-revertive protection.
The 1+1 APS architecture means that there is simultaneous

transmission of the same data from both the working and protection
ports. It also means that reception occurs on either the working or
protection port as chosen by the APS management module.
Software APS operates in unidirectional mode. That is, an error

condition detected on the inbound (receive) channel alone determines
when the APS management module switches lines. It does not require
that the other entity switch its receive channel as well.
Software APS operates exclusively in non-revertive mode, where a

switch to the protection line (or to the working line) remains in effect
even after the faulted line recovers from its error condition.
One advantage of Software APS is its flexibility in port selection. The

working port and the protection port can reside on the same card
(intra-card) or on different cards (inter-card) as long as the cards are of
the same type. Whether using intra-card or inter-card, any available
ports on the card can be used. For example, intra-card does not
require the use of adjacent ports and inter-card does not require the
use of the same port number. In addition, for inter-card the cards do
not have to be adjacent.
When a Signal Fail (SF) condition is detected, the APS management

module automatically switches the source of inbound ATM cells from
the working line to the protection line, or from the protection line to the
working line (depending on which line was the ATM cell source prior to
the APS event). A Signal Fail (SF) condition is a hard failure condition

Redundancy 11-5
detected on the incoming OC-3 signal. An SF condition can be Loss of

Signal (LOS), Loss of Frame (LOF), a Line Alarm Indication Signal
(AIS-L) defect, or a Line Remote Defect Indication (RDI-L). Software
APS does not respond to SF or Signal Degradation (SD) caused by
excessive bit error rates.
The ATM card generates event logs when the following events occur:
• An APS group has been administratively changed (added,
modified, or deleted).
• A switchover occurred in an APS group due to an SF condition.
• An APS group became unavailable (all ports failed).
The OC-3 cards generate physical port alarms (LOS, LOF, etc.) on
APS ports as well as non-APS ports. However, the ALC card interprets
and handles physical port alarms differently for APS versus non-APS
ports. When a non-APS port is in alarm, the ALC card marks all the
interfaces on that port as “down”. When a non-APS port comes out of
alarm, its interfaces are brought back up. The interface for an APS port
remains up as long as at least one of the ports is up. When a port goes
up/down (both APS and non-APS), the ALC card accordingly clears/
generates port down alarms.
Service Creation System (SCS) Server 11

The multi-tiered SCS Server architecture has been designed to
minimize the impact of system failures. Any one of the components
fails should not cause service disruption on the GGSN. If eliminating
the management functions disruption is required in addition to the
service disruption, the system High Availability (HA) mechanism can
be added to the configuration of the SCS Server.
SCS server redundancy can be provided by two SCS servers with the
same IP address. SCS Resiliency script is responsible for transferring
the SCS data from active SCS server to standby SCS server
periodically.
Charging Gateway Function (CGF) 11

The CGF is a GPRS/UMTS network node that processes the GGSN
accounting records (G-CDRs) before sending them to the Billing
System for downstream processing.
Two CGFs are supported on the GGSN for each device within the ISP
that has the Ga interface provisioned. This provides redundancy for
the GGSN in case the connection to one of the CGFs fails.

Prepaid Server 11
Two Prepaid Servers are supported on the GGSN per APN. This
provides redundancy to the GGSN for Prepaid/GeoZone Service in
case the connection to one of the Prepaid Servers is down. The GGSN
communicates to one Prepaid Server at a time; if the primary Prepaid
Server is not responding, the backup Prepaid Server takes over.
The GGSN manages the CTP prepaid server connections by

designating a primary and secondary server within a CTP Tariff Profile.
The determination of the active server is based on the following two
factors:
— The first response received by the GGSN

— Server that is configured to be Primary
When a secondary server enters the connected state and the active
server of the same CTP Tariff Profile is not in the connected state, the
secondary server becomes the active server.
When a primary server enters the connected state it becomes the

active server. If there was already an active server at the time the
primary server enters the connected state then the former ceases to
be the active server.
When the active server exits the connected state and the secondary
server of the CTP Tariff Profile is in the connected state, then the
secondary server becomes the active server.
In addition, the GGSN will maintain the connection to both servers to

facilitate switching over in case of a failure with active server. If the
connection to the non-active server is lost, the GGSN will attempt to
reestablish it.
Diameter Credit Control Server 11

Each Diameter client in the GGSN supports communication with up to
two Diameter peers in active/standby mode. The Diameter protocol
defines a mechanism for Diameter nodes to select which connection is
used for sending diameter requests.
Application Server 11
A single Application Server is supported on the GGSN per APN. To
provide redundancy, the Application Server can be configured in
duplex mode. This duplex mode is provided by the Application Server
itself and is external to the GGSN.

Redundancy 11-7
When the RADIUS Server acts as a proxy of the Application Server,

the RADIUS primary server and backup server also provide the
redundancy for the RADIUS Accounting messaging between the
GGSN and the Application Server.
RADIUS Server 11
Multiple RADIUS Servers are supported on the GGSN for each device
within a Connection ISP. Each RADIUS Profile supports up to 8
primary and 8 backup servers. Each RADIUS Server can be
configured as primary server or backup server as well as each
RADIUS Server can be configured as Authentication server,
Accounting server or both.
RADIUS Authentication Server

The RADIUS Access Request message is sent to a primary
Authentication server that is selected in round-robin order from the
primary server list. If it times out before the Nortel GGSN gets back a
reply message, the request message is sent to the backup
Authentication servers in round-robin order until the configured
maximum number of retries is reached.
When a RADIUS Profile contains multiple primary servers and multiple

backup servers, the load sharing mechanism along with round-robin
among multiple primary servers and secondary servers is used to
select a RADIUS server. For example, the first RADIUS Access
Request message is sent to primary server #1. If there is no response
message from primary server #1, the request message is sent again to
primary server #1. When the primary server #1 fails to respond for the
second time, then the backup server #1 is contacted. If there is no
response message from backup server #1, then the backup server #2
is contacted. The second RADIUS Access Request message is
directed to primary server #2 and the same round-robin mechanism
applies. If the last backup (or primary, if no backups are present)
server cannot be contacted and there are more retries available, then
the next retry attempt will start back with the primary server(s).
RADIUS Accounting Server

The RADIUS Accounting START message is sent to a primary
Accounting server that is selected in round-robin order from the
primary server list. A messaging timeout results in trying the backup
Accounting servers in round-robin order until the configured maximum
number of retries is reached. Only the backup servers handle a
timeout retransmission of RADIUS Accounting START message.
The round-robin mechanism described above is valid only for the

RADIUS Accounting START message. The RADIUS Accounting

INTERIM and STOP messages are handled slightly differently. The

Nortel GGSN tries to send the RADIUS Accounting INTERIM and
STOP messages to the same server to which the corresponding
RADIUS Accounting START message has been sent. If the selected
server doesn’t respond to the RADIUS Accounting INTERIM or STOP
message, a round-robin algorithm is used to send this message to the
immediate next server. For example, let's assume that the RADIUS
Accounting START message sent to primary server #1 was
successful. When the PDP session ends, an attempt is made to send
the RADIUS Accounting STOP message to primary server #1. If we
fail to receive a response from primary server #1, then we retry the
primary server #1 for one more time, failing which we try the backup
server #1 and so on. If the RADIUS Accounting START message is
sent to backup server #1, the RADIUS Accounting STOP message is
sent to the backup server #1. If no response message is received from
backup server #1, we will try backup server #2 and so on. If we can not
find a server match for the corresponding RADIUS Accounting START
message, we employ the usual round-robin mechanism and start by
sending this message to a primary server and then continuing with
backup servers if necessary.
If the maximum number of retries in a RADIUS Profile is reached while

trying to transmit a RADIUS Accounting message, then any RADIUS
Accounting STOP message sent to RADIUS Server using this
RADIUS profile is immediately stored on the local disk. The RADIUS
Accounting START and INTERIM messages are discarded to save
disk space. The Nortel GGSN will continuously attempt to
communicate with the RADIUS Servers in the RADIUS Profile for only
one PDP session at a time and rejects other PDP context creation
requests without sending any RADIUS Accounting messages. If it
again reaches the maximum number of retries, the RADIUS
Accounting STOP message is stored on the local disk again.
On addition of a RADIUS server to the GGSN, RADIUS accounting Off

followed by accounting On messages are sent. If the initial attempt to
contact the RADIUS server is unsuccessful, then further attempts will
be made to contact the RADIUS server, as specified by the “retries”
field in the “RADIUS Profile - General Tab”. The total number of
attempts will be “retries” plus one (for the initial attempt).
Adding the same RADIUS server to multiple profiles could result in

loss of accounting session data, since accounting Off / On messages
will be sent for each profile. A warning is now displayed when this
provisioning is done, to make the operator aware of this possible
behavior.

Redundancy 11-9
DHCP Server 11
Multiple DHCP Servers are supported on the GGSN for each device
within a Connection ISP. The DHCP message is unicast to each of the
DHCP Servers for address soliciting. One of the DHCP Servers is
selected to provide the address.
FTP Server 11
Two FTP Servers are supported on the GGSN for each device. These
servers are used to transfer G-CDR Auditing files via the FTP protocol.
This provides redundancy for the GGSN in case the connection to one
of the FTP Servers fails.
Traffic Performance Optimizer (TPO) Server 11

TPO server and load balancer redundancy is transparent to the
GGSN. When TPO server goes down, another TPO server takes over
and GGSN does not need to know about it. GGSN keeps sending the
traffic to the pre configured IP address in the TPO IP service.
When a load balancer goes down, another one takes over, this does
not affect the GGSN, the GGSN keeps sending the traffic to the pre
configured IP address as mentioned above. The GGSN does not know
about all the redundancy activities on the TPO which is transparent to
the GGSN.


12-1
Product Conformance 12
Overview 12
This chapter specifies the State of Compliancy (SOC) of Nortel GGSN
product. The SOC contains the standard conformance information of
the GGSN related standard documentation:
• 3GPP GPRS Specifications

• 3GPP UMTS Specifications
• IETF RFC Specifications
GPRS Specifications 12
3GPP TS 09.60 version 7.10.0
The following table summarized the Nortel GGSN conformance with
the GTP version 0 specification.
Table 12-1
Summary of conformation to GTP version 0 specification
Section Section Title Conformance
1 Scope Supported.
2 References Supported.
3 Definitions and abbreviation Supported.
4 General Supported.
5 Transmission order and bit Supported.
definitions
6 GTP Header Supported.
7 Signalling Plane Supported.
7.1 Signalling protocol Supported.
7.2 Signalling Message Formats Please refer to individual message
section for conformance information.
7.3 Usage of the GTP Header Supported.
7.4 Path Management messages Supported.
7.4.1 Echo Request Supported.
7.4.2 Echo Response Supported.
7.4.3 Version Not Supported Supported.
7.5 Tunnel Management messages Supported.

12-2 Product Conformance Copyright © 2000–2008 Nortel Networks

7.5.1 Create PDP Context Request Supported.
7.5.2 Create PDP Context Response Supported.
Reordering Required is always set to

FALSE in Create PDP Context
Response message sent from Nortel
GGSN.
7.5.3 Update PDP Context Request Supported.
7.5.4 Update PDP Context Response Supported.
Charging ID IE is always included in

the Update PDP Context Response
sent from Nortel GGSN.
7.5.5 Delete PDP Context Request Supported.
7.5.6 Delete PDP Context Response Supported.
7.5.7 Create AA PDP Context Request Not supported.
7.5.8 Create AA PDP Context Response Not supported.
7.5.9 Delete AA PDP Context Request Not supported.
7.5.10 Delete AA PDP Context Response Not supported.
7.5.11 Error Indication Supported.
7.5.12 PDU Notification Request Not Applicable.
7.5.13 PDU Notification Response Not Applicable.
7.5.14 PDU Notification Reject Request Not Applicable.
7.5.15 PDU Notification Reject Response Not Applicable.
7.6 Location Management messages Not supported.
7.6.1 Sending Routing Information for Not supported.
GPRS Request
7.6.2 Sending Routing Information for Not supported.
GPRS Response
7.6.3 Failure Report Request Not supported.
7.6.4 Failure Report Response Not supported.
7.6.5 Note MS GPRS Present Request Not supported.
7.6.6 Note MS GPRS Present Response Not supported.
7.7 Mobility Management messages Not Applicable.
7.8 Reliable delivery of signalling Partially Supported.
messages
The increment of sequence number in
the signaling request messages is not
on a per path basis.
7.9 Information elements
7.9.1 Cause Supported.
7.9.2 International Mobile Subscriber Supported.
Identity (IMSI)
7.9.3 Routing Area Identity (RAI) Not Applicable.
7.9.4 Temporary Logical Link Identity Not Applicable.
(TLLI)
7.9.5 Packet TMSI (P-TMSI) Not Applicable.

Product Conformance 12-3

7.9.6 Quality of Service (QoS) Profile Supported.
7.9.7 Reordering Required Supported.
7.9.8 Authentication Triplet Not Applicable.
7.9.9 MAP Cause Not supported.
7.9.10 P-TMSI Signature Not Applicable.
7.9.11 MS Validated Not Applicable.
7.9.12 Recovery Supported.
7.9.13 Selection mode Supported.
7.9.14 Flow Label Data I Supported.
7.9.15 Flow Label Signalling Supported.
7.9.16 Flow Label Data II Not Applicable.
7.9.17 Charging ID Supported.
7.9.18 End User Address Supported.
Only IPv4 is supported.

7.9.19 MM Context Not Applicable.
7.9.20 PDP Context Not Applicable.
7.9.21 Access Point Name Supported.
7.9.22 Protocol Configuration Options Supported.
7.9.23 GSN Address Supported.
While decoding the GSN Address IE

on the Nortel GGSN, the Address
Length field from GSM 03.03 can be
included or not included in the GSN
Address field. The Length field of GSN
Address IE differentiates the different
formats of the GSN Address field.
7.9.24 MS International PSTN/ISDN Supported.
Number (MSISDN)
7.9.25 Charging Gateway Address Supported.
7.9.26 Private Extension Supported.
This includes support of Nortel

Extension.
8 Transmission Plane
8.1 Protocol Stack Supported.
8.1.1 Usage of the GTP Header Supported.
8.1.1.1 Usage of the Sequence Number Partially Supported.
Nortel GGSN sets the sequence

number before sending data. Nortel
GGSN ignores the sequence number
when receiving data.
8.2 Tunnelling between SGSNs Not Applicable.
8.3 Tunnelling between GGSNs Supported.
9 Path Protocols Supported.


9.1 UDP/IP Supported.
9.1.1 UDP Header Supported.
9.1.1.1 Signalling request messages Supported.
9.1.1.2 Signalling response messages Supported.
9.1.1.3 Encapsulated T-PDUs Supported.
9.1.2 IP Header Supported.
9.1.2.1 Signalling request messages and Supported.
Encapsulated T-PDUs
9.1.2.2 Signalling response messages Supported.
9.2 TCP/IP Not supported.
9.2.1 TCP Header Not supported.
9.2.2 IP Header Not supported.
10 Error handling Supported.
10.1 Protocol Error Supported.
10.1.1 Different GTP versions Supported.
10.1.2 GTP Message too short Supported.
10.1.3 Unknown GTP signalling message Supported.
10.1.4 Unexpected GTP signalling Supported.
message
10.1.5 Missing mandatory present Supported.
information element
10.1.6 Invalid Length Supported.
10.1.7 Invalid mandatory information Supported.
element
10.1.8 Invalid optional information element Supported.
10.1.9 Unknown information element Supported.
10.1.10 Out of sequence information Supported.
elements
10.1.11 Unexpected information element Supported.
10.1.12 Repeated information elements Supported.
10.1.13 Incorrect optional information Supported.
elements
10.2 Path failure Partially Supported.
Only Echo Request message is used

for the detection of path failure on
GGSN.
10.3 MS detach Not Applicable.
10.4 Restoration and Recovery Supported.
11 Inter-PLMN GTP communication Supported.
over the Gp interface
External Border Gateway is required to
support Gp interface.
12 IP, the networking technology used Supported.
by GTP
12.1 IP version Supported.
12.2 IP fragmentation Supported.


12.2.1 MO direction Supported.
12.2.2 MT direction Supported.
12.2.3 Tunnelling from old to new SGSN Not Applicable.
13 GTP parameters Supported.
13.1 Timers Supported.
13.2 Others Supported.
Annex A Naming convention Not Applicable.
Annex B A method of sequence number Not supported.
checking
Annex C Document change history Supported.

the GPRS PLMN and PDN interworking specification.
Table 12-2
Summary of conformation to GPRS PLMN/PDN interworking specification
1 Scope Supported
2 References Supported
3 Definitions, abbreviations and Supported
symbols
4 Network characteristics Supported
5 Interwoking classifications Supported
6 Access reference configuration Supported
7 Interface to GPRS Bearer Services Supported.
Optional TCP protocol is not supported

between SGSN and GGSN, only UDP
is supported.
8 Subscription checking Supported
9 Screening Supported
10 Interworking with PSDN (X.75/X.25) Not Supported
11 Interworking with PDN (IP) Supported.
11.1 General Supported
11.2 PDN Interworking Model Partially Supported.
Only IPv4 is supported, IPv6 is not

supported.
11.2.1 Access to Internet, Intranet or ISP Supported
through GPRS
11.2.1.1 Transparent access to the Internet Supported
11.2.1.2 Non Transparent access to an Supported
Intranet or ISP
11.3 Numbering and Addressing Supported
11.4 Charging Not Supported


11.5 Domain Name Server (DNS) Supported
11.6 Screening Supported
12 Interworking with PDN (PPP) Supported.
12.1 General Supported
12.2 PDN Interwoking Model Supported
12.2.1 Virtual dial-up and direct access to Supported
PDNs, or ISPs through GPRS
12.2.1.1 Procedural description Supported
13 Internet Hosted Octet Stream Not Supported
Service (IHSOS)
14 Interworking between GPRS Supported.
networks
Nortel GGSN can not act as a Border
Gateway. It needs a Border Gateway
between the GGSN in home PLMN
and the SGSN in visited VLMN.
14.1 Security Agreements Not Applicable
14.2 Routing protocol agreements Not Applicable
14.3 Charging agreements Not Applicable
15 Void Not Applicable
16 Usage of RADIUS on Gi interface Supported
16.1 RADIUS Authentication Supported
16.2 RADIUS Accounting Supported
16.3 Authentication and accounting Supported.
message flows
16.3.1 IP PDP type Supported
16.3.2 PPP PDP type Partially Supported.
Nortel GGSN will not drop user data

before the Accounting Response
START is received from the AAA
Server and will not delete the PDP
context if the response is not received
Nortel GGSN can not handle PPP
CHAP when an Access Challenge is
received.
16.3.3 Accounting Update Supported
Nortel GGSN will not delete the PDP

context if the Accounting Response is
not received from the AAA Server.
16.3.4 AAA-Initiated PDP context Supported.
termination
The corresponding PDP session is
deleted based on the configuration
when a Disconnect Request message
is received.
16.4 List of RADIUS attributes Supported


16.4.1 Access-Request message (sent Supported
from the GGSN to AAA server)
16.4.2 Access-Accept (sent from AAA Partially Supported.
server to GGSN)
The username received from AAA
server is ignored.
16.4.3 Accounting-Request START (sent Partially Supported.
from GGSN to AAA server)
Server in Access Accept message is
ignored.
16.4.4 Accounting Request STOP (sent Partially Supported.
ignored.
16.4.5 Accounting Request ON (optionally Supported
sent from GGSN to AAA server)
16.4.6 Accounting Request OFF (optionally Supported
16.4.7 Sub-attributes of the 3GPP Vendor- Supported
Specific attribute
16.4.8 Accounting Request Interim-Update Supported
(sent from GGSN to AAA server)
16.4.9 Disconnect Request (optionally sent Supported
from AAA server to GGSN)
Annex A Interworking PCS1900 with PSDNs Not Supported
Annex B Change history Supported
12
UMTS Specifications 12
The following table summarizes the Nortel GGSN conformance to the
service description for the GPRS which is a packet bearer service and
a main part of the packet domain.
Table 12-3
Summary of conformance to GPRS Service Description
1 Scope Supported.
3 Definitions, abbreviations and symbols Supported.
4 Main Concept Supported.
5 General GPRS Architecture and Supported.
Transmission Mechanism
5.1 GPRS Access Interfaces and Supported.
Reference Points


5.2 Network Interworking Supported.
5.2.1 Internet (IP) Interworking Supported.
5.3 High-Level Functions Supported.
5.3.1 Network Access Control Functions Partially Supported.
User network access occurred

from the fixed side of the network
is not supported.
5.3.1.1 Registration Function Not Applicable.
5.3.1.2 Authentication and Authorization Not Applicable.
Function
5.3.1.3 Admission Control Function Not Applicable.
5.3.1.4 Message Screening Function Supported.
5.3.1.5 Packet Terminal Adaptation Function Not Applicable.
5.3.1.6 Charging Data Collection Function Supported.
5.3.1.7 Operator Determined Barring Function Not Applicable.
5.3.2 Packet Routing and Transfer Functions Supported.
5.3.2.1 Relay Function Supported.
5.3.2.2 Routing Function Partially Supported
Only Ethernet and ATM are

supported for the data
transmission.
5.3.2.3 Address Translation and Mapping Not Supported.
Function
5.3.2.4 Encapsulation Function Supported.
5.3.2.5 Tunnelling Function Supported.
5.3.2.6 Compression Function Not Applicable.
5.3.2.7 Ciphering Function Not Applicable.
5.3.2.8 Domain Name Server Function Supported.
5.3.3 Mobility Management Functions Supported.
5.3.4 Logical Link Management Functions Not Applicable.
(A/Gb mode)
5.3.5 Radio Resource Management Not Applicable.
Functions
5.3.6 Network Management Functions Supported.
5.4 Logical Architecture Partially Supported.
Gc interface to HLR is not

supported.
5.4.1 GPRS Core Network Nodes Supported.
5.4.2 GPRS Packet Domain PLMN Supported.
Backbone Networks
5.4.3 HLR Not Applicable.
5.4.4 SMS-GMSC and SMS-IWMSC Not Applicable.
5.4.5 Mobile Stations (A/Gb mode) Not Applicable.
5.4.6 Mobile Stations (lu mode) Not Applicable.


5.4.7 Charging Gateway Functionality Supported.
5.5 Assignment of Functions to General Partially Supported.
Logical Architecture
See information above.
5.6 User and COntrol Planes Supported.
5.6.1 User Plane (A/Gb mode) Supported.
5.6.1.1 MS - GGSN Supported.
5.6.1.2 GSN - GSN Supported.
5.6.2 User Plane (lu mode) Supported.
5.6.2.1 MS - GGSN user plane with GERAN in Supported.
lu mode
5.6.2.2 MS - GGSN user plane with UTRAN Supported.
5.6.3 Control Plane Supported.
5.6.3.1 MS - SGSN (A/Gb mode) Not Applicable.
5.6.3.2 MS - SGSN (lu mode) Not Applicable.
5.6.3.3 SGSN - HLR Not Applicable.
5.6.3.4 SGSN - MSC/VLR Not Applicable.
5.6.3.5 SGSN - EIR Not Applicable.
5.6.3.6 SGSN - SMS-GMSC or SMS-IWMSC Not Applicable.
5.6.3.8 GGSN - HLR Not Supported.
5.7 Functionality Needed for Mobile IP Not Supported.
Using IPv4
5.8 Functionality for Intra Domain Not Applicable.
Connection of RAN Nodes to Multiple
CN Nodes
5.9 Functionality for network sharing Not Applicable.
6 Mobility Management Functionality Supported.
6.1 Definition of Mobility Management Not Applicable.
States
6.2 Mobility Management Timer Functions Not Applicable.
6.3 Interactions Between SGSN and MSC/ Not Applicable.
HLR
6.4 MM Procedures Not Applicable.
6.5 GPRS Attach Function Supported.
6.6 Detach Function Supported.
6.7 Purge Function Not Applicable.
6.8 Security Function Not Applicable.
6.9 Location Management Function Supported.
6.10 Tunnelling of non-GSM Signalling Not Applicable.
Messages Function (A/Gb mode)
6.11 Subscriber Management Function Not Applicable.
6.12 Service Request Procedure (lu mode) Supported.
6.13 Intersystem Change Supported.
6.14 Classmark Handling Not Applicable.


7 Network Management Functionality Supported.
8 Radio Resource Functionality Not Applicable.
9 Packet Routing and Transfer Supported.
Functionality
9.1 Definition of Packet Data Protocol Partially Supported.
States
Nortel GGSN is not allowed to
initiate the activation of PDP
context.
9.2 PDP Context Activation, Modification, Supported.
Deactivation, and Preservation
Functions
9.2.1 Static and Dynamic PDP Addresses Supported.
9.2.1.1 Dynamic IPv6 Address Allocation Not Supported.
9.2.2 Activation Procedures Supported.
9.2.2.1 PDP Context Activation Procedure Partially Supported.
The GGSN trace function is not

supported by Nortel GGSN.
APN restriction is not supported

by Nortel GGSN.
Nortel GGSN doesn’t restrict QoS

Negotiation given its capacities
and the current load.
The Prohibit Payload

Compression information is not
returned to the SGSN.
The PDP context doesn’t get

rejected due to imcompatible
QoS Negotiated received from
SGSN.
9.2.2.1.1 Secondary PDP Context Activation Partially Supported.
Procedure
Prohibit Payload Compression
and APN Restriction are not
returned to the SGSN.
9.2.2.2 Network-Requested PDP Context Not Supported.
Activation Procedure
9.2.3 Modification Procedures Supported.


9.2.3.1 SGSN-Initiated PDP Context Partially Supported.
Modification Procedure
The GGSN trace function is not

Negotiation given its capacities
and the current load.

Compression and APN
Restriction are not returned to the
SGSN.
9.2.3.2 GGSN-Initiated PDP Context Partially Supported.
Compression and APN
Restriction are not sent to the
SGSN.
9.2.3.3 MS-Initiated PDP COntext Modification Partially Supported.
The Update PDP Context

Request doesn’t get rejected due
to imcompatible QoS Negotiated
or TFT received from SGSN.

Negotiation given its capacities,
operator policies and the current
load.

Compression and APN
Restriction are not returned to the
SGSN.
9.2.3.4 RNC/BSS-Initiated PDP Context Partially Supported.
Nortel GGSN doesn’t stop
sending packets to SGSN upon
receiving 0 kbits/s maximum bit
rate for a specific PDP context.
9.2.3.5 RAB Release-Initiated Local PDP Partially Supported.
Context Modification Procedure
Nortel GGSN doesn’t stop
sending packets to SGSN upon
receiving 0 kbits/s maximum bit
rate for a specific PDP context.
9.2.3.6 RAN-initiated RAB Modification Not Applicable.
Procedure (lu mode)


9.2.4 Deactivation Procedures Supported.
9.2.4.1 MS Initiated PDP Context Deactivation Supported.
Procedure
9.2.4.2 SGSN-initiated PDP COntext Supported.
Deactivation Procedure
9.2.4.3 GGSN-initiated PDP COntext Supported.
Deactivation Procedure
9.2.5 Preservation Procedures Not Applicable.
9.3 Packet Routing and Transfer Function Partially Supported.
The PDP type PPP is not

supported for the secondary PDP
context. In this case, the PDP
context request is rejected.
9.4 Relay Function Partially Supported.
PDP PDUs are not stored and no

maximum holding time is
implemented on the Nortel
GGSN.
PDP PDUs are not re-sequenced

on the Nortel GGSN.
9.5 Packet Terminal Adaptation Function Not Applicable.
9.6 Encapsulation Function Supported.
9.6.1 Encapsulation Between GSNs Supported.
9.6.2 Encapsulation Between SGSN and Not Applicable.
RAN in lu mode
9.6.3 Encapsulation Between SGSN and MS Not Applicable.
in A/Gb mode
9.6.4 Encapsulation Between RAN and MS Not Applicable.
in lu mode
10 Message Screening Functionality Supported.
11 Compatibility Issues Supported.
11.1 Interaction between Releases 97/98 Supported.
and 99
11.1.1 Interaction Between GTP v0 (R97) and Supported.
GTP v1 (R99)
11.1.2 Interaction Between MS R97 and CN Supported.
R99
11.1.3 Interaction Between SM R97 and SM Not Applicable.
R99
11.1.4 Interaction Between MAP R97 and Not Applicable.
MAP R99
12 Transmission Supported.
13 Information Storage Supported.
13.1 HLR Not Applicable.


13.2 SGSN Not Applicable.
13.3 GGSN Partially Supported.
MNRG, GTP-SNU, GGSN Trace

information, and Prohibit Payload
Compression are not part of PDP
context fields on the Nortel
GGSN.
13.4 MS Not Applicable.
13.5 MSC/HLR Not Applicable.
13.6 BSS in A/Gb mode Not Applicable.
13.7 RNC/BSC for lu mode Not Applicable.
13.8 Recovery and Restoration Procedures Supported.
13.8.1 HLR Failure Not Applicable.
13.8.2 SGSN Failure Partially Supported.
PDU Notification Request and

Response messages are not
13.8.3 GGSN Failure Supported.
13.8.4 VLR Failure Not Applicable.
13.8.5 BSS Failure (A/Gb mode) Not Applicable.
13.8.6 RNC/BSC Failure (lu mode) Not Applicable.
14 Identities Supported.
14.1 IMSI Supported.
14.2 Packet TMSI Not Applicable.
14.3 NSAPI and TLLI for A/Gb mode Supported.
14.4 NSAPI, RB Identity, and RAB ID for lu Supported.
mode
14.5 PDP Address Partially Supported.
IPv6 address is not supported on

Nortel GGSN.
14.6 TEID Supported.
14.7 Routing Area Identity Supported.
14.8 RAN Registration Area Identity (lu Not Applicable.
mode)
14.9 Cell Identity Supported.
14.10 Service Area Identity (lu mode) Supported.
14.11 GSN Addresses Supported.
14.11.1 GSN Address Partially Supported.
IPv6 address is not supported on

Nortel GGSN
14.11.2 GSN Number Not Supported.
14.12 RNC/BSC Addresses (lu mode) Not Applicable.
14.13 Access Point Name Supported.


15 Operation Aspects Supported.
15.1 Charging Partially Supported.
The charging of subscriber is not

based on the Subscribed or PDP
context Charging Characteristics
in the HLR. It’s based on the local
configuration via SCS GUI and/or
attributes received from RADIUS
server in Access-Accept
message.
Charging by a CAMEL server

using CAMEL interaction
procedures is not supported on
the Nortel GGSN.
15.1.1 Charging Information Supported.
15.1.2 Reverse Charging Not Supported.
15.2 Quality of Service Profile Partially Supported.
Nortel GGSN doesn’t negotiate

the QoS attributes.
15.3 Traffic Flow Template Partially Supported.
The flow label and IPv6 address

are not supported on Nortel
GGSN.
15.4 APN Restriction Not Supported.
15.5 Automatic Device Detection Not Applicable.
16 Interactions with Other Services Supported.
16.1 Point-to-point Short Message Service Not Applicable.
16.2 Circuit-switched Services (A/Gb mode) Not Applicable.
16.3 Supplementary Services Not Applicable.
16.4 CAMEL Services Not Supported.
Annex A APN and GGSN Selection Not Applicable.
Annex B Change history Supported.

service description for the GPRS which is a packet bearer service and
a main part of the packet domain.
Table 12-4
Summary of conformance to service description for GPRS

15.6 Direct Tunnel Functionality Supported


The following table summarizes the Nortel GGSN conformance to
QoS Concept and Architecture.
Table 12-5
Summary of conformance to QoS Concept and Architecture
1 Scope Supported.
3 Abbreviations Supported.
4 High Level Requirements Supported.
4.1 End User QoS Requirements Supported.
4.2 General Requirements for QoS Supported.
4.3 Technical Requirements for QoS Supported.
5 CS QoS in release 1999 Not Supported.
6 QoS Architecture Supported
6.1 Overview of Different Levels of QoS Supported.
6.1.1 The End-to-End Service and UMTS Supported.
Bearer Service
6.1.2 The Radio Access Bearer Service and Supported.
the Core Network Bearer Service
6.1.3 The Radio Bearer Service and the Not Applicable.
RAN Access Bearer Service
6.1.4 The Backbone Network Service Not Applicable.
6.2 QoS Management Functions in the Supported.
Network
6.2.1 Description of Functions Partially Supported.
See information below.

6.2.1.1 QoS Management Functions for UMTS Supported.
Bearer Service in the Control Plane
6.2.1.2 Functions for UMTS Bearer Service in Partially Supported.
the User Plane
Nortel GGSN accepts QoS
parameters, but does not
guarantee them.
6.2.2 Allocation of QoS Management Partially Supported.
Functions
6.2.2.1 QoS Management Functions for UMTS Supported.
Bearer Service in the Control Plane
6.2.2.2 QoS Management Functions for UMTS Partially Supported.
Bearer Service in the User Plane
guarantee them.


6.3 UMTS QoS Classes Supported.
6.3.1 Conversational Class Supported.
6.3.2 Streaming Class Supported.
6.3.3 Interactive Class Supported.
6.3.4 Background Class Supported.
6.4 QoS Parameters Supported
6.4.1 Asymmetric Bearers Supported.
6.4.2 Sources of UMTS Bearer Service Supported.
Attributes
6.4.3 UMTS Bearer Service Attributes Partially Supported.

6.4.3.1 List of attributes Partially Supported.

guarantee them.
6.4.3.2 Attributes discussed Per traffic class Partially Supported.

guarantee them.
6.4.3.3 UMTS bearer attributes: summary Partially Supported.

guarantee them.
6.4.4 Radio Access Bearer Service Not Applicable.
Attributes
6.4.5 Radio Bearer Service Attributes Not Applicable.
6.4.6 RAN Access Bearer Service Attributes Not Applicable.
6.4.7 Core Network Bearer Service Supported.
Attributes
6.5 Attribute Value Ranges Supported.
6.5.1 Ranges of UMTS Bearer Service Supported.
Attributes
6.5.2 Ranges of Radio Access Bearer Not Applicable.
Service Attributes for UTRAN and for
GERAN
7 (void) Not Applicable.
8 QoS Attribute Mapping Supported.
8.1 From Application Attributes to UMTS Supported.
Bearer Service Attributes
8.2 From UMTS Bearer Service Attributes Not Applicable.
to Radio Access Bearer Service
Attributes


8.3 From UMTS Bearer Service Attributes Not Applicable.
to CN Bearer Service Attributes
9 Interworking Supported.
9.1 UMTS-GSM CS/GPRS Not Applicable.
9.2 UMTS-PSTN Not Applicable.
9.3 UMTS-ISDN Not Applicable.
9.4 UMTS-Internet Supported.
Annex A Error resilience in real-time packet Not Applicable.
multimedia payloads
Annex B Reference Algorithm for Conformance Not Applicable.
Definition of Bitrate
Annex C Determine which QoS profile is of Not Applicable.
highest QoS
Annex D Determine Traffic Class weights in HLR Not Supported
QoS profile
Annex E Change history Supported.

Table 12-6
Summary of conformance to GTP version 1 specification
1 Scope Supported.
3 Definitions and abbreviation Supported.
4 General Supported.
5 Transmission Order and Bit Definitions Supported.
6 GTP Header Supported.
6.1 Extension headers Partially Supported.

6.1.1 PDCP PDU Number Not Applicable.
6.1.2 Suspend Request Not Applicable
6.1.3 Suspend Response Not Applicable
6.1.4 MBMS support indication Not Supported
7 GTP Messages and Message Formats
7.1 Message Formats Supported.
7.1.1 Presence requirements of Information Supported.
Elements
7.2 Path Management Messages Partially Supported.

7.2.1 Echo Request Supported.
7.2.2 Echo Response Supported


7.2.3 Version Not Supported Supported.
7.2.4 Supported Extension Header Notification Not Supported.
7.3 Tunnel Management Messages Partially Supported.

7.3.1 Create PDP Context Request Supported.
If a new Create PDP Context

Request is incoming on a TEID
which is different from 0 and this
TEID is already allocated to
activated PDP contexts, a rejection
cause code Mandatory IE Incorrect
is returned and the activated PDP
contexts are deleted.
If Maximum Bit Rate for Downlink is set

to a value less than 8640 Kbps and
Maximum Bit Rate for Downlink
(extended) is present in the QoS Profile
IE, the request message will be rejected
with cause Mandatory IE Incorrect.
7.3.2 Create PDP Context Response Supported.
The Reordering Required IE is set to

FALSE in the response message
Charging ID IE is always included in

the response message sent from
Nortel GGSN.
The End User Address IE is

included in the response message
for secondary PDP context
activation procedure.
Only IPv4 GGSN addresses are

included in the response message
sent from Nortel GGSN to indicate
GGSN is not IPv6 capable.
The Delivery Order field of the QoS

IE is set to Without Delivery Order in
message sent from Nortel GGSN to
indicate no reordering has been
performed.


7.3.3 Update PDP Context Request Partially Supported.
The P-CSCF Address Request and

IM CN Subsystem Signaling Flag
parameters in the PCO IE are not
supported in the Update PDP
Context Request message received
by Nortel GGSN.
If Maximum Bit Rate for Downlink is

set to a value less than 8640 Kbps
and Maximum Bit Rate for Downlink
(extended) is present in the QoS
Profile IE, the request message will
be rejected with cause Mandatory IE
Incorrect.
7.3.4 Update PDP Context Response Supported.
TEID Control Plane IE and Charging

ID IE are always included in the
The Delivery Order field of the QoS

IE is set to Without Delivery Order in
message sent from Nortel GGSN to
indicate no reordering has been
performed.
7.3.5 Delete PDP Context Request Supported.
7.3.6 Delete PDP Context Response Partially Supported.
Even the Delete PDP Context

Response message contains a
cause value other than Request
Accepted and Non Existent, the
PDP context on the Nortel GGSN
will still be deleted.
7.3.7 Error Indication Supported.
7.3.8 PDU Notification Request Not Supported.
7.3.9 PDU Notification Response Not Supported.
7.3.10 PDU Notification Reject Request Not Supported.
7.3.11 PDU Notification Reject Response Not Supported.
7.4 Location Management Messages Not Supported.
7.4.1 Sending Routing Information for GPRS Not Supported.
Request


7.4.2 Sending Routing Information for GPRS Not Supported.
Response
7.4.3 Failure Report Request Not Supported.
7.4.4 Failure Report Response Not Supported.
7.4.5 Note MS GPRS Present Request Not Supported.
7.4.6 Note MS GPRS Present Response Not Supported.
7.5 Mobility Management messages Not Applicable.
7.5A MBMS Messages Not Supported.
7.6 Reliable delivery of signalling messages Partially Supported.
The increment of sequence number

for the signaling request messages
is not on a per path basis. Only one
counter is maintained for all
signaling messages on a GGSN.
7.7 Information elements Partially Supported.

7.7.1 Cause Supported.
7.7.2 International Mobile Subscriber Identity Supported.
(IMSI)
7.7.3 Routing Area Identity (RAI) Supported.
7.7.4 Temporary Logical Link Identity (TLLI) Not Applicable.
7.7.5 Packet TMSI (P-TMSI) Not Applicable.
7.7.6 Reordering Required Supported.
7.7.7 Authentication Triplet Not Applicable.
7.7.8 MAP Cause Not Supported.
7.7.9 P-TMSI Signature Not Applicable.
7.7.10 MS Validated Not Applicable.
7.7.11 Recovery Supported.
7.7.12 Selection mode Supported.
7.7.13 Tunnel Endpoint Identifier Data I Supported.
7.7.14 Tunnel Endpoint Identifier Control Plane Supported.
7.7.15 Tunnel Endpoint Identifier Data II Not Applicable.
7.6.16 Teardown Ind Supported.
7.7.17 NSAPI Supported.
7.7.18 RANAP Cause Not Applicable.
7.7.19 RAB Context Not Applicable.
7.7.20 Radio Priority SMS Not Applicable.
7.7.21 Radio Priority Not Applicable.
7.7.22 Packet Flow Id Not Applicable.
7.7.23 Charging Characteristics Supported.
7.7.24 Trace Reference Not Supported.
7.7.25 Trace Type Not Supported.
7.7.25A MS Not Reachable Reason Not Applicable.
7.7.25B Radio Priority LCS Not Applicable.


7.7.26 Charging ID Supported.
7.7.27 End User Address Supported
Only IPv4 address is supported.

7.7.28 MM Context Not Applicable.
7.7.29 PDP Context Not Applicable.
7.7.30 Access Point Name Supported.
7.7.31 Protocol Configuration Options Supported.
The IM-CN Subsystem Signaling

Flag and Policy Control Rejection
Code parameters are not included in
the response message sent from
Nortel GGSN in the network to MS
direction.
7.7.32 GSN Address Supported.
7.7.33 MS International PSTN/ISDN Number Supported.
(MSISDN)
7.7.34 Quality of Service (Qos) Profile Supported.
7.7.35 Authentication Quintuplet Not Applicable.
7.7.36 Traffic Flow Template (TFT) Partially Supported.
The Authorization Token and Flow

Identifier parameters are not
supported in the TFT IE.
7.7.37 Target Identification Not Applicable.
7.7.38 UTRAN Transparent Container Not Applicable.
7.7.39 RAB Setup Information Not Applicable.
7.7.40 Extension Header Type List Not Supported.
7.7.41 Trigger Id Not Supported.
7.7.42 OMC Identity Not Supported.
7.7.43 RAN Transparent Container Not Applicable.
7.7.44 Charging Gateway Address Supported.
7.7.45 PDP Context Prioritization Not Applicable.
7.7.45A Additional RAB Setup Information Not Applicable.
7.7.46 Private Extension Supported.
7.7.47 SGSN Number Not Applicable.
7.7.48 Common Flags Not Supported.
7.7.49 APN Restriction Not Supported.
7.7.50 RAT Type Supported.
7.7.51 User Location Information Supported.
7.7.52 MS Time Zone Not Supported.
7.7.53 International Mobile Equipment Identity Supported.
(and Software Version) (IMEI(SV))
7.7.54 CAMEL Charging Information Container Not Supported.
7.7.55 MBMS UE Context Not Supported.
7.7.56 Temporary Mobile Group Identity Not Supported.


7.7.57 RIM Routing Address Not Applicable.
7.7.58 MBMS Protocol Configuration Options Not Supported.
7.7.59 MBMS Session Duration Not Supported.
7.7.60 MBMS Service Area Not Supported.
8 Control Plane (GTP-C) Supported.
8.1 Control Plane Protocol Supported.
8.2 Usage of the GTP-C Header Supported.
9 GTP-U Supported.
9.1 GTP-U Protocol Entity Partially Supported.

9.1.1 Handling of Sequence Numbers Partially Supported.
Nortel GGSN ignores the sequence

number when receiving GTP-U
messages. The Nortel GGSN does
not support buffering and reordering
of incoming GTP-U messages.
The increment of sequence number

for the signaling request messages
is not on a per path basis. Only one
counter is maintained for all
signaling messages on a GGSN.
9.2 GTP-U Service Access Points and Not Applicable.
Primitives
9.3 Protocol Stack Supported.
9.3.1 Usage of GTP-U Header Supported.
9.3.1.1 Usage of Sequence Number Partially Supported.
Nortel GGSN ignores the sequence

number when receiving GTP-U
message. The Nortel GGSN does
not support buffering and reordering
of incoming GTP-U messages, nor
maintain the expected sequence
number.
If the far end SGSN requests

delivery order, the sequence
number that the Nortel GGSN
includes in the GTP header of the
outgoing GTP-U messages is an
incremental sequence number.
9.4 Tunnelling between SGSNs Not Applicable.
9.5 Tunnelling between Source RNC and Not Applicable.
Target RNC via SGSNs
9.6 Tunnelling between GGSNs Supported.


10 Path Protocols Supported.
10.1 UDP/IP Supported.
10.1.1 UDP Header Supported.
10.1.1.1 Request Messages Supported.
10.1.1.2 Response Messages Supported.
10.1.1.3 Encapsulated T-PDUs Supported.
10.1.1.4 Error Indication, Version Not Support and Supported.
Supported Extension Headers Notification
10.1.2 IP Header Supported.
10.1.2.1 Request messages and Encapsulated T- Supported.
PDUs
10.1.2.2 Response Messages Supported.
10.1.2.3 Error Indication, Version Not Supported Supported.
and Supported Extension Headers
Notification
11 Error handling Supported.
11.1 Protocol Error Supported.
11.1.1 Different GTP Versions Supported.
11.1.2 GTP Message Too Short Supported.
11.1.3 Unknown GTP Control Plane Message Supported.
11.1.4 Unexpected GTP Control Plane Message Supported.
11.1.5 Missing Mandatory Present Information Supported.
Element
11.1.6 Invalid Length Supported.
11.1.7 Invalid Mandatory Information Element Supported.
11.1.8 Invalid Optional Information Element Supported.
11.1.9 Unknown Information Element Supported.
11.1.10 Out of Sequence Information Elements Supported.
11.1.11 Unexpected Information Element Supported.
11.1.12 Repeated Information Elements Supported.
11.1.13 Incorrect Optional Information Elements Supported.
11.2 Path Failure Partially Supported.
Only Echo Request message is

used for the detection of path failure
on GGSN.
11.3 MS Detach Not Applicable.
11.4 Restoration and Recovery Partially Supported.
GGSN doesn’t maintain restart

counter for each peer SGSN that it
is in contact with. Only one restart
counter is kept on the GGSN.
12 Security provided to GTP Communication Not Supported.
over Gn and Gp Interfaces
13 IP, The Networking Technology used by Supported
GTP


13.1 IP Version Supported.
Only IPv4 is supported.

13.2 IP Fragmentation Supported.
13.2.1 MO Direction Supported.
13.2.2 MT Direction Supported.
13.2.3 Tunnelling from old to new SGSN Not Applicable.
14 GTP Parameters Supported.
14.1 Timers Supported.
14.2 Others Supported.
Annex A A method for sequence number checking Not Supported.

Table 12-7
Summary of conformation to UMTS PLMN/PDN interworking specification
7.7.81 Direct Tunnel Flags Supported.

the UMTS PLMN and PDN interworking specification.
Table 12-8
Summary of conformation to UMTS PLMN/PDN interworking specification
1 Scope Supported.
3 Definitions, abbreviations and Supported.
symbols
4 Network characteristics Supported.
5 Interwoking classifications Supported.
6 Access reference configuration Supported.
7 Interface to Packet Domain Bearer Supported.
Services
7.1 A/Gb mode Supported.
7.2 Lu mode Supported.
8 Subscription checking Supported.
8A Prevention of IP spoofing Supported.
9 Message Screening Supported.


10 Interworking with PSDN (X.75/X.25) Not Supported.
11 Interworking with PDN (IP) Supported.
11.1 General Supported.
11.2 PDN Interworking Model Partially Supported.
Only IPv4 is supported, IPv6 is not

supported.
11.2.1 Access to Internet, Intranet or ISP Supported.
through Packet Domain
11.2.1.1 Transparent access to the Internet Supported.
11.2.1.2 IPv4 Non Transparent access to an Supported.
Intranet or ISP
11.2.1.3 IPv6 Non Transparent access to an Not Supported.
Intranet or ISP
11.2.1.4 Access to Internet, Intranet or ISP Not Supported.
with Mobile IPv4
11.3 Numbering and Addressing Supported.
11.4 Charging Supported.
11.5 Domain Name Server (DNS Server) Supported.
11.6 Screening Supported.
11.7 IP Multicast access Partially Supported.
Nortel GGSN acts as an IGMP proxy. It

doesn’t support any Inter-Router
Multicast protocol.
12 Interworking with PDN (PPP) Supported.
12.2 PDN Interwoking Model Supported.
12.2.1 Virtual dial-up and direct access to Supported.
PDNs, or ISPs through Packet
Domain
12.2.1.1 Procedural description Supported.
13 Interworking with PDN (DHCP) Supported.
13.2 PDN Interworking Model for DHCP Supported.
13.2.1 Address allocation by the Intranet or Supported.
ISP
13.2.1.1 Address allocation using DHCPv4 Supported.
13.2.1.2 Address allocation using DHCPv6 Not Supported.
13.2.2 Other configuration by the Intranet Not Supported.
or ISP (IPv6 only)
13a Interworking with IMS Supported.
13a.1 General Partially Supported.
The dedicated signaling PDP contexts

and Go interface are not supported on
the Nortel GGSN.


13a.2 IMS Interworking Model Not Supported.
13a.2.1 IMS Specific Configuration in the Partially Supported.
GGSN
The static packet filters for dedicated
signaling PDP contexts and Go
interface are not supported on the
Nortel GGSN.
Only IPv4 P-CSCF addresses are pre-

configured and returned to MS via the
PCO IE.
P-CSCF discovery via DHCPv6 relay

agent is not supported.
13a.2.2 IMS Specific Procedures in the Supported.
GGSN
13a.2.2.1 Request for Signaling Server Supported.
Address
13a.2.2.2 Establishment of a PDP Context for Partially Supported.
Signaling
The IM CN Subsystem Signaling flag is
not included in the response to MS.
This is to indicate that dedicated IMS
signaling is not supported on the Nortel
GGSN.
13a.2.2.3 Creation of a PDP Context for IMS Not Supported.
Media Flows
14 Internet Hosted Octet Stream Not Supported.
Service (IHOSS)
15 Interworking between Packet Supported.
Domains
Nortel GGSN can not act as a Border
Gateway. It needs a Border Gateway
between the GGSN in the home PLMN
and the SGSN in the visited VLMN.
15.1 Security Agreements Not Applicable.
15.2 Routing protocol agreements Not Applicable.
15.3 Charging agreements Not Applicable.
16 Usage of RADIUS on Gi interface Supported.
16.1 RADIUS Authentication Supported.
16.2 RADIUS Accounting Supported.
16.3 Authentication and accounting Supported.
message flows
16.3.1 IP PDP type Supported.


16.3.2 PPP PDP type Partially Supported.
Nortel GGSN doesn’t drop user data

before the Accounting Response
START is received from the AAA
Server and doesn’t delete the PDP
context if the response is not received.
Nortel GGSN can not handle PPP
CHAP when an Access Challenge is
received.
16.3.3 Accounting Update Supported.
Nortel GGSN doesn’t delete the PDP

context if the Accounting Response is
not received from the AAA Server.
16.3.4 AAA-Initiated PDP context Supported.
termination
The corresponding PDP session is
deleted based on the configuration
when a Disconnect Request message
is received.
16.4 List of RADIUS attributes Supported.
16.4.1 Access-Request message (sent Supported.
from the GGSN to AAA server)
16.4.2 Access-Accept (sent from AAA Partially Supported.
server to GGSN)
server is ignored.
16.4.3 Accounting-Request START (sent Partially Supported.
ignored.
16.4.4 Accounting Request STOP (sent Partially Supported.
ignored.
16.4.5 Accounting Request ON (optionally Supported.
16.4.6 Accounting Request OFF (optionally Supported.


16.4.7 Sub-attributes of the 3GPP Vendor- Partially Supported.
Specific attribute
If Enable Charging Characteristics
option is selected via SCS GUI, the
Charging Characteristics IE value in
Create PDP Context Request message
is included in 3GPP-Charging-
Characteristics VSA. If the option is not
selected, the local provisioning
information and/or attributes received
from RADIUS server in Access-Accept
message is used.
The following 3GPP VSAs are not

supported on the Nortel GGSN: 3GPP-
CG-IPv6-Address, 3GPP-SGSN-IPv6-
Address, 3GPP-GGSN-IPv6-Address,
3GPP-IPv6-DNS-Servers, 3GPP-
Teardown-Indicator, 3GPP-IMS-
Timezone, 3GPP-Packet-Filter, and
3GPP-Negotiated-DSCP.
16.4.8 Accounting Request Interim-Update Supported.
(sent from GGSN to AAA server)
16.4.9 Disconnect Request (optionally sent Supported.
from AAA server to GGSN)
17 Usage of Diameter on Gmb Not Supported.
interface
Annex A Interworking PCS1900 with PSDNs Not Applicable.

The following table indicates the compliance of the GGSN Gx interface
with 3GPP TS 29.210 specification.
Table 12-9
Summary of conformation to 3GPP 29.210 specification
1 Scope Supported.
3 Definitions, symbols, and Supported.
abbreviations
3.3 Definitions Supported.
4 Gx reference point Supported.
4.1 Overview Supported.


4.2 Charging Rules Partially supported.
Only CBB policies (group of charging

rules) can be pre-configured.
Service identifier, metering, and

precedence are not supported.
Dynamic rules from CRF have
precedence over static rules. The
dynamic rules are ordered as they are
received.
4.3 Functionality of the Gx reference Supported.
point
4.3.1 Initialization and maintenance of Supported.
connection
4.3.2 Request for charging rules from the Supported.
TPF
4.3.3 Provision of charging rules from the Noted.
CRF
This section applies to the CRF.
4.3.4 Provision of event triggers from the Noted.
CRF
4.3.5 Provision of charging addresses Noted.
from the CRF
4.3.6 Indication of bearer termination Supported.
(from TPF to CRF)
5 Gx Protocol Supported.
5.1 Protocol support Supported.
5.2 Gx specific AVPs Partially supported.
Subsections below indicate if AVP

supported or not.
5.2.1 Bearer-Usage AVP Partially supported.
Only GENERAL is sent for this AVP.


5.2.2 Charging-Rule-Install AVP Partially supported.
Charging-Rule-Name within this AVP

not supported.
Only one Charging-Rule-Base-Name

AVP supported. If more than one
received, the last one in message is
used.
5.2.3 Charging-Rule-Remove AVP Partially supported.
Charging-Rule-Base-Name within this

AVP not supported.
5.2.4 Charging-Rule-Definition AVP Partially supported.
Service-Identifier, Reporting-Level,
Metering Method, Precedence, AF-
Charging-Identifier, and Flows not
supported.
Only one Flow-Description AVP is

supported.
If received Charging-Rule-Definition
AVP matches an existing charging rule,
the charging rule is overwritten.
Attributes not provided within the AVP
are set with default values.
5.2.5 Charging-Rule-Base-Name AVP Supported.
5.2.6 Charging-Rule-Name AVP Supported.
5.2.7 Event-Trigger AVP Supported.
5.2.8 Metering-Method AVP Not supported.
5.2.9 Offline AVP Supported.
5.2.10 Online AVP Supported.


5.2.11 Precedence AVP Partially supported.
Supported within the TFT-Packet-

Filter-Information AVP. Not supported
within the Charging-Rule-Definition
AVP.
5.2.12 Primary-CCF-Address AVP Not supported.
5.2.13 Primary-OCS-Address AVP Not supported.
5.2.14 RAT-Type AVP Supported.
5.2.15 Report-Level AVP Not supported.
5.2.16 Secondary-CCF-Address AVP Not supported.
5.2.17 Secondary-OCS-Address AVP Not supported.
5.2.18 TFT-Filter AVP Supported.
5.2.19 TFT-Packet-Filter-Information AVP Supported.
5.2.20 ToS-Traffic-Class AVP Supported.
5.3 Gx re-used AVPs Partially supported.
3GPP-SGSN-IPv6-Address, AF-
Charging-Identifier, CC-Sub-Session-
Id, Flows, Framed-IPv6-Prefix,
Service-Identifier, and User-
Equipment-Info AVPs not supported.
5.4 Gx specific Experimental-Result- Supported.
Code AVP values
5.4.1 Success Supported.
5.4.2 Permanent Failures Supported.
6 Gx Messages Partially supported.
Each PDP context (primary or

secondary) maps to one Diameter
session. Diameter sub-sessions not
supported.
6.1 Gx Application Supported.


6.1.1 CC-Request (CCR) Command Partially supported.
CC-Sub-Session-Id, Framed-IPv6-
Prefix, User-Equipment-Info, 3GPP-
SGSN-IPv6-Address, Proxy-Info, and
Route-Record AVPs not supported for
this message.
3GPP-GGSN-Address, 3GPP-
Charging-Id, 3GPP-IMSI, and 3GPP-
NSAPI AVPs added to CCR as pre-
standard optional AVPs.
6.1.2 CC-Answer (CCA) Command Partially supported.
CC-Sub-Session-Id, Primary-CCF-
Address, Secondary-CCF-Address,
Primary-OCF-Address, Secondary-
OCF-Address, Error-Message, Error-
Reporting-Host, Failed-AVP, Proxy-
Info, and Route-Record AVPs not
supported for this message.
6.1.3 Re-Auth-Request (RAR) Command Partially supported.
Destination-Realm, Destination-Host,
Re-Auth-Request-Type, CC-Sub-
Session-Id, and Origin-State-Id AVPs
not supported for this message.
6.1.4 Re-Auth-Answer (RAA) Command Partially supported.
Experimental-Result, CC-Sub-
Session-Id, Error-Message, Error-
Reporting-Host, and Failed-AVP AVPs
not supported for this message.
6.2 Gx over Gy Application Supported.
6.2.1 Simultaneous charging rule Supported.
provision and credit authorization


The following table summarized the Nortel GGSN conformance to the
GTP’ version 3.2.0.
Table 12-10
Summary of conformance to GTP’ version 3.2.0
1 Scope Supported.
2 Reference Supported.
4 Architecture Supported.
4.1 Charging Gateway Functionality Partially Supported.
The GGSN does not include the

CGF function internally.
5 Charging Principles Supported.
5.1 Requirements Partially Supported.
Item 4 is not supported.

5.2 Charging Information Supported.
5.3 Charging Data Collection Principles Supported.
5.3a Volume counting in RNC Not Applicable.
5.4 Generation of Charging ID Supported.
5.5 Charging for SMS in GPRS Not Applicable.
5.6 Charging Triggers - CDR Generation Supported.
5.6.1 Triggers for S-CDR Charging Not Applicable.
Information Collection
5.6.1.1 Triggers for S-CDR Charging Not Applicable.
Information Addition
5.6.1.2 Triggers for S-CDR Closure Not Applicable.
5.6.2 Triggers for M-CDR Charging Not Applicable.
5.6.2.1 Triggers for M-CDR Charging Not Applicable.
5.6.2.2 Triggers for M-CDR Closure Not Applicable.
5.6.3 Triggers for G-CDR Charging Supported.
5.7 Examples of charging scenarios Supported.
5.7.1 GPRS Mobile to PDN Context Supported.
5.7.2 GPRS Mobile to Mobile Context Partially Supported.
Network initiated PDP context

activation is not supported.
5.7.3 PDN to GPRS Mobile Context Not Supported.
5.7.4 GPRS Mobile to PDN Context while, Supported.
GGSN in HPLMN


5.8 Charging support for CAMEL Not Applicable.
6 Charging Data Collection
6.1 Record contents Partially Supported.
Optional CDR fields are not

operator configurable.
6.1.1 GPRS charging data in SGSN (S- Not Applicable.
CDR)
6.1.2 GPRS charging data in GGSN (G- Partially Supported.
CDR)
The following fields are not
supported: Network Initiated PDP
Context, Diagnostics, Node ID
and QoS Requested.
6.1.3 GPRS mobile station mobility Not Applicable.
management data in SGSN (M-CDR)
6.1.4 GPRS MO SMS data in SGSN (S- Not Applicable.
SMO-CDR)
6.1.5 GPRS MT SMS data in SGSN (S-SMT- Not Applicable.
CDR)
6.1.6 Description of Record Fields Supported.
6.1.6.1 Access Point Name (APN) Network/ Supported.
Operator Identifier
6.1.6.1a Destination Number Not Applicable.
6.1.6.1b CAMEL Information Not Applicable.
6.1.6.1c APN Selection Mode Supported.
6.1.6.2 Cause of Record Closing Supported.
6.1.6.2a Charging Characteristics Supported.
6.1.6.3 Charging ID Supported.
6.1.6.4 Diagnostics Not Supported.
6.1.6.5 Duration Partially Supported
Zero duration and zero data byte

transferred records are
generated.
6.1.6.6 Dynamic Address Flag Supported.
6.1.6.7 Event Time Stamps Supported.
6.1.6.8 GGSN Address/GGSN Address Used Supported.
6.1.6.9 List of Traffic Data Volumes Supported.
6.1.6.9a RNC Unsent Downlink Volume Not Applicable.
6.1.6.10 Local Record Sequence Number Supported.
6.1.6.11 Message reference Not Applicable.
6.1.6.12 MS Network Capability Not Applicable.
6.1.6.13 Network Initiated PDP Context Not Supported.
6.1.6.14 Node ID Not Supported.
6.1.6.15 PDP Type Supported.


6.1.6.16 QoS Requested/QoS Negotiated Partially Supported.
QoS Requested is put in the QoS

Negotiated field. The value will be
adjusted if it is out of range.
6.1.6.17 Record Extensions Supported.
6.1.6.18 Record Opening Time Supported.
6.1.6.19 Record Sequence Number Supported.
6.1.6.20 Record Type Supported.
6.1.6.21 Recording Entity Number Not Supported.
6.1.6.22 “Void” Not Applicable.
6.1.6.23 Routing Area Code/Cell Identity/ Not Applicable.
Change of location
6.1.6.24 Served IMEI Not Applicable.
6.1.6.25 Served IMSI Supported.
6.1.6.26 Served MSISDN Supported with slight deviance.
If msisdn_stuff_remove is
enabled, check for stuffed bytes
in MSISDN. If stuffed bytes
present, remove the stuffed
bytes.
6.1.6.27 Served PDP Address Supported.
6.1.6.28 Service Centre Address Not Applicable.
6.1.6.29 SGSN Address Supported.
6.1.6.30 SGSN Change Not Applicable.
6.1.6.31 Short Message Service (SMS) Result Not Applicable.
6.1.6.32 System Type Not Supported.
7 Charging Protocols Supported.
7.1 GPRS CDR Collection by GTP’ Partially Supported.
Protocol
Redirection of G-CDR to another
un-provisioned CGF is not
supported.
7.1.1 SGSN - CGF communication Not Applicable.
7.1.2 GGSN - CGF communication Supported.
7.1.3 CGF - CGF communication Not Applicable.
7.1.4 Port usage Supported.
7.1.4.1 UDP as the Path Protocol Supported.
7.1.4.2 TCP as Path Protocol Not Supported.
7.1.4.3 Network layer and lower layers Supported.
7.1.5 Charging related requirements for Supported.
GPRS nodes
7.2 The GTP’ charging protocol Supported.
7.2.1 Usage of GTP Header in charging Supported.
7.2.2 Information elements Supported.
7.3 GTP’ Message Types Supported.


7.3.1 List of GTP’ message types Supported.
7.3.2 Reused GTP message types Supported.
7.3.3 GTP message type modifications Supported.
implied by GTP’
7.3.4 GTP’ message types Supported.
7.3.4.1 Node Alive Request Supported.
7.3.4.2 Node Alive Response Supported.
7.3.4.3 Redirection Request Partially Supported.
See limitation section for

redirection limitation.
7.3.4.4 Redirection Response Partially Supported.
Redirection Request is not sent

by GGSN.
7.3.4.5 Data Record Transfer Request Supported.
7.3.4.5.1 General logic Supported.
7.3.4.5.2 Information Elements in Data Record Supported.
Transfer Request
7.3.4.5.3 Packet Transfer Command IE Supported.
7.3.4.5.4 Data Record Packet IE Supported.
7.3.4.5.5 Sequence Numbers of Released Supported.
Packet IE
7.3.4.5.6 Sequence Numbers of Cancelled Supported.
Packets IE
7.3.4.5.7 Private Extension IE Not Supported.
7.3.4.6 Data Record Transfer Response Partially Supported.
The following Cause Values are

not supported: Service Not
Supported, Mandatory IE
Incorrect, Mandatory IE Missing,
Optional IE Incorrect and Invalid
Message Format.
7.3.4.7 Examples of GTP’ messaging cases Supported.
7.4 Data Record Formats used in GTP’ Partially Supported.
No private formats are supported.

7.4.1 ASN.1 format Supported.
7.4.2 Other formats Not Supported.
7.5 CGF - BS Protocol Interface Not Applicable.
7.5.1 The transfer protocols at CGF - BS Not Applicable.
interface
7.5.2 The format of the CDRs at CGF - BS Not Applicable.
interface
8 Charging Data Record Structure Supported.


8.1 ASN.1 definitions for CDR information Partially Supported.
Some ASN.1 fields are not

supported.

GTP’ version 3.6.0.
Table 12-11
Summary of conformance to GTP’ version 3.6.0
1 Scope Supported.
2 Reference Supported.
4 Architecture Supported.
4.1 Charging Gateway Functionality Partially Supported.
The GGSN doesn’t include the

CGF functionality.
5 Charging Principles Supported.
5.1 Requirements Partially Supported.
Item 4 is not supported.

5.2 Charging Information Supported.
5.3 Charging Data Collection Principles Supported.
5.3a Volume counting in RNC Not Applicable.
5.4 Generation of Charging ID Supported.
5.5 Charging for SMS in GPRS Not Applicable.
5.6 Charging Triggers - CDR Generation Supported.
5.6.1 Triggers for S-CDR Charging Not Applicable.
5.6.1.1 Triggers for S-CDR Charging Not Applicable.
5.6.1.2 Triggers for S-CDR Closure Not Applicable.
5.6.2 Triggers for M-CDR Charging Not Applicable.
5.6.2.1 Triggers for M-CDR Charging Not Applicable.
5.6.2.2 Triggers for M-CDR Closure Not Applicable.
5.6.3 Triggers for G-CDR Charging Supported.
5.7 Examples of charging scenarios Supported.
5.7.1 GPRS Mobile to PDN Context Supported.


5.7.2 GPRS Mobile to Mobile Context Partially Supported.
Network initiated PDP context

activation is not supported.
5.7.3 PDN to GPRS Mobile Context Not Supported.
5.7.4 GPRS Mobile to PDN Context while, Supported.
GGSN in HPLMN
5.8 Charging support for CAMEL Not Applicable.
6 Charging Data Collection Supported.
6.1 Record contents Partially Supported.
Optional CDR fields are not

operator configurable.
6.1.1 GPRS charging data in SGSN (S- Not Applicable.
CDR)
6.1.2 GPRS charging data in GGSN (G- Partially Supported.
CDR)
The following fields are not
supported: Network Initiated PDP
Context, Diagnostics, Node ID
and QoS Requested.
6.1.3 GPRS mobile station mobility Not Applicable.
management data in SGSN (M-CDR)
6.1.4 GPRS MO SMS data in SGSN (S- Not Applicable.
SMO-CDR)
6.1.5 GPRS MT SMS data in SGSN (S-SMT- Not Applicable.
CDR)
6.1.6 Description of Record Fields Supported.
6.1.6.1 Access Point Name (APN) Network/ Supported.
Operator Identifier
6.1.6.2 APN Selection Mode Supported.
6.1.6.3 CAMEL Information Not Applicable.
6.1.6.4 Cause of Record Closing Supported.
6.1.6.5 Charging Characteristics Supported.
6.1.6.6 Charging ID Supported.
6.1.6.7 Destination Number Not Applicable.
6.1.6.8 Diagnostics Not Supported.
6.1.6.9 Duration Partially Supported. Zero duration
and zero data byte transferred
records are generated.
6.1.6.10 Dynamic Address Flag Supported.
6.1.6.11 Event Time Stamps Supported.
6.1.6.12 GGSN Address/GGSN Address Used Supported.
6.1.6.13 List of Traffic Data Volumes Supported.
6.1.6.14 Local Record Sequence Number Supported.
6.1.6.15 Message reference Not Applicable.
6.1.6.16 MS Network Capability Not Applicable.


6.1.6.17 Network Initiated PDP Context Not Supported.
6.1.6.18 Node ID Not Supported.
6.1.6.19 PDP Type Supported.
6.1.6.20 QoS Requested/QoS Negotiated Partially Supported.
QoS Requested is put in the QoS

Negotiated field. The value will be
adjusted if it is out of range.
6.1.6.21 Record Extensions Supported.
6.1.6.22 Record Opening Time Supported.
6.1.6.23 Record Sequence Number Supported.
6.1.6.24 Record Type Supported.
6.1.6.25 Recording Entity Number Not Supported.
6.1.6.26 RNC Unsent Downlink Volume Not Applicable.
6.1.6.27 Routing Area Code/Cell Identity/ Not Applicable.
Change of location
6.1.6.28 Served IMEI Not Applicable.
6.1.6.29 Served IMSI Supported.
6.1.6.30 Served MSISDN Supported.
6.1.6.31 Served PDP Address Supported.
6.1.6.32 Service Centre Address Not Applicable.
6.1.6.33 SGSN Address Supported.
6.1.6.34 SGSN Change Not Applicable.
6.1.6.35 Short Message Service (SMS) Result Not Applicable.
6.1.6.36 System Type Not Supported.
7 Charging Protocols Supported.
7.1 GPRS CDR Collection by GTP’ Partially Supported.
Protocol
Redirection of G-CDR to another
un-provisioned CGF is not
supported.
7.1.1 SGSN - CGF communication Not Applicable.
7.1.2 GGSN - CGF communication Supported.
7.1.3 CGF - CGF communication Not Applicable.
7.1.4 Port usage Supported.
7.1.4.1 UDP as the Path Protocol Supported.
7.1.4.2 TCP as Path Protocol Not Supported.
7.1.4.3 Network layer and lower layers Supported.
7.1.5 Charging related requirements for Supported.
GPRS nodes
7.2 The GTP’ charging protocol Supported.
7.2.1 Usage of GTP Header in charging Supported.
7.2.2 Information elements Supported.
7.3 GTP’ Message Types Supported.
7.3.1 List of GTP’ message types Supported.
7.3.2 Reused GTP message types Supported.


7.3.3 GTP message type modifications Supported.
implied by GTP’
7.3.4 GTP’ message types Supported.
7.3.4.1 Node Alive Request Supported.
7.3.4.2 Node Alive Response Supported.
7.3.4.3 Redirection Request Partially Supported.
See limitation chapter for

redirection limitation.
7.3.4.4 Redirection Response Partially Supported.
Redirection Request is not sent

by GGSN.
7.3.4.5 Data Record Transfer Request Supported.
7.3.4.5.1 General logic Supported.
7.3.4.5.2 Information Elements in Data Record Supported.
Transfer Request
7.3.4.5.3 Packet Transfer Command IE Supported.
7.3.4.5.4 Data Record Packet IE Supported.
7.3.4.5.5 Sequence Numbers of Released Supported.
Packet IE
7.3.4.5.6 Sequence Numbers of Cancelled Supported.
Packets IE
7.3.4.5.7 Private Extension IE Not Supported.
7.3.4.6 Data Record Transfer Response Partially Supported.
The following Cause Values are

not supported: Service Not
Supported, Mandatory IE
Incorrect, Mandatory IE Missing,
Optional IE Incorrect, Invalid
Message Format and CDR
Decoding Error.
7.3.4.7 Examples of GTP’ messaging cases Supported.
7.4 Data Record Formats used in GTP’ Partially Supported.
No private formats are supported.

7.4.1 ASN.1 format Supported.
7.4.2 Other formats Not Supported.
7.5 CGF - BS Protocol Interface Not Applicable.
7.5.1 The transfer protocols at CGF - BS Not Applicable.
interface
7.5.2 The format of the CDRs at CGF - BS Not Applicable.
interface
8 Charging Data Record Structure Supported.


8.1 ASN.1 definitions for CDR information Partially Supported
Some ASN.1 fields are not

supported.
12
Diameter Charging version 7.6.0.
Table 12-12
Summary of Conformance to TS 32.299 version 7.6.0
6.5.6 Envelope Reporting Supported.
6.5.7 Combinational Quota Supported.
RFC Specifications 12
RFC 2131 - Dynamic Host Configuration Protocol (DHCP)
DHCP RFC in March 1997 version.
Table 12-13
Summary of conformance to DHCP
1 Introduction Supported.
1.1 Changes to RFC1541 Partially Supported.
DHCP INFORM message is not

supported.
1.2 Related Work Noted.
1.3 Problem definition and issues Noted.
1.4 Requirements Noted.
1.5 Terminology Noted.


1.6 Design goals Partially Supported.
GGSN only supports DHCP

Client and Relay functionality.
The GGSN DHCP Client does not
retain configuration information
across reboots. Our DHCP Client
does not perform any check on
the provided network address to
see if it is currently in use. This is
left upto the DHCP Server.
2 Protocol Summary Partially Supported.
The client does not provide the

maximum message size option, it
maintains the minimum IP MTU
size (576 bytes). GGSN only
supports DHCP Client and Relay
functionality
2.1 Configuration parameters repository Supported.
2.2 Dynamic allocation of network address Partially Supported.

Client and Relay functionality
3 The Client-Server Protocol Supported.
3.1 Client-server interaction-allocating a Partially Supported.
network address
Client and Relay functionality. All
dhcp messages are unicasted to
a provisioned set of DHCP
Servers.
GGSN DHCP Client does not

verify if the address in currently in
use.
GGSN DHCP Client selects first

valid Offer message.
3.2 Client-server interaction - reusing a Partially Supported.
previously allocated network address
Client and Relay functions.
verify if the address is currently in
use. GGSN DHCP Client informs
the application to take down the
session. It is up to the subscriber
to restart the process.


3.3 Interpretation and representation of Partially Supported.
time values
3.4 Obtaining parameters with externally Partially Supported.
configured network address.
supported.
3.5 Client parameters in DHCP Partially Supported.

The client does not provide the
maximum message size option, it
maintains the minimum IP MTU
size (576 bytes).
3.6 Use of DHCP in clients with multiple Supported
interfaces
3.7 When client should use DHCP Supported
4 Specification of the DHCP client-server Partially Supported
protocol
4.1 Constructing and sending DHCP Partially Supported.
messages
GGSN DHCP Client forwards the
message through a relay task
which sets the source address to
the ISP Gi address.
4.2 DHCP server administration controls Partially Supported.

Client and Relay functionality
Vendor class identifier option is
not supported currently.
4.3 DHCP server behavior Not Applicable.

4.4 DHCP Client behavior Partially Supported.


4.4.1 Initialization and allocation of network Partially Supported.
address
supported. In the GGSN DHCP
DISCOVER, the lease time
option is not sent. In the GGSN
DHCP REQUEST, the lease time
option is not sent. The GGSN
DHCP Client does not include the
vendor class identifier option in
the DISCOVER or REQUEST
message. The GGSN DHCP
Client does not include the
maximum message size option in
message. The GGSN DHCP
Client does not include the
message option in the DECLINE
or RELEASE message. The
include the site-specific option in
message. The only options
included in the DECLINE
message are the message type,
server identifier, requested
address, and client identifier. The
only options in the RELEASE
message are the message type,
server identifier, and client
identifier. The GGSN DHCP
Client does not verify the
suggested address.
4.4.2 Initialization with known network Not Supported.
address
The GGSN DHCP Client
implementation always request
the network address except when
in a address renewal.
4.4.3 Initialization with an externally Not Supported.
assigned network address
implementation always request
the network address.


4.4.4 Use of broadcast and unicast Partially Supported.

provisions DHCP Servers
addresses. The Client unicasts to
all the servers provisioned DHCP
INFORM message is not
supported
4.4.5 Reacquisition and expiration Partially Supported.
If the lease expires, the

application is informed and the
session is released.
4.4.6 DHCPRELEASE Supported
5 Acknowledgements Noted.
6 References Noted.
7 Security Considerations Noted.
8 Author’s Address Noted.
Annex A Host Configuration Parameters Partially Supported.
The only parameters accepted

are the IP address, subnet mask,
and dns server addresses for the
dhcp client. DHCP Relay
transparently returns all
parameter to the host device.
RFC 2865 - Remote Authentication Dial In User Service (RADIUS)

RADIUS RFC in June 2000 version.
Table 12-14
Summary of conformance to RADIUS
1.0 Introduction Supported.
1.1 Specification of Requirements Noted.
2 Operation Supported.
2.1 Challenge/Response Supported.
2.2 Interoperation with PAP and CHAP‘ Supported.
2.3 Proxy Not Applicable. This concept
applies to Radius Server.
2.4 Why UDP Supported.
2.5 Retransmission Hints Supported.
2.6 Keep-Alive Considered Harmful Supported.
3 Packet Format Supported.
4 Packet Type Supported.


4.1 Access-Request Supported.
4.2 Access-Accept Supported.
4.3 Access-Reject Supported.
4.4 Access-Challenge Not Supported.
RFC stated ‘If the NAS does not

support challenge/response, it
MUST treat an Access-Challenge
as though it had received an
Access-Reject instead’.
5 Attributes Supported.
5.1 User-Name Supported.
5.2 User-Password Supported.
5.3 CHAP-Password Supported.
5.4 NAS-IP-Address Supported.
5.5 NAS-Port Supported.
5.6 Service-Type Supported.
5.7 Framed-Protocol Partially Supported.
Only PPP and SLIP are

supported.
5.8 Framed-IP-Address Supported.
5.9 Framed-IP-Netmask Supported.
5.10 Framed-Routing Not Supported.
5.11 Filter-Id Not Supported.
5.12 Framed-MTU Supported.
5.13 Framed-Compression Not Supported.
5.14 Login-IP-Host Not Applicable.
5.15 Login-Service Not Applicable.
5.16 Login-TCP-Port Not Applicable.
5.18 Reply-Message Supported.
5.19 Callback-Number Not Applicable.
5.20 Callback-Id Not Applicable.
5.22 Framed-Route Supported.
5.23 Framed-IPX-Network Not Applicable.
5.24 State Supported.
5.25 Class Supported.
5.26 Vendor-Specific Supported.


5.27 Session-Timeout Partially Supported.
Session-Timeout returned from

RADIUS Server, in second unit,
will be rounded up to the hour. For
example, if Session-Timeout is
3600 seconds, the session will be
expired after 1 hour. However, if
Session-Timeout is 3800
seconds, the session will be
expired after 2 hours. In addition,
the maximum value of Session-
Timeout on the GGSN is 172800
seconds (or 48 hours.)
5.28 Idle-Timeout Supported.
5.29 Termination-Action Supported.
5.30 Called-Station-Id Supported.
GGSN sends APN as called-

station-id.
5.31 Calling-Station-Id Supported.
GGSN sends MSISDN as calling-

station-id.
5.32 NAS-Identifier Not Supported.
5.33 Proxy-State Not Applicable.
5.34 Login-LAT-Service Not Applicable.
5.35 Login-LAT-Node Not Applicable.
5.36 Login-LAT-Group Not Applicable.
5.37 Framed-AppleTalk-Link Not Applicable.
5.38 Framed-AppleTalk-Network Not Applicable.
5.39 Framed-AppleTalk-Zone Not Applicable.
5.40 CHAP-Challenge Supported.
5.41 NAS-Port-Type Supported.
5.42 Port-Limit Supported.
5.43 Login-LAT-Port Not Applicable.
5.44 Table of Attributes Partially Supported. See above
sections.
6 IANA Consideration Supported.
6.1 Definition of Terms Supported.
6.2 Recommended Registration Supported.
7 Examples Supported.
7.1 User Telnet to Specified Host Supported.
7.2 Framed User Authenticating with Supported.
CHAP
7.3 User with Challenge-Response Card Supported.
8 Security Considerations Noted.


9 Change Log Noted.
10 References Noted.
11 Acknowledgement Noted.
12 Chair’s Address Noted.
13 Authors’ Addresses Noted.
RFC 2866 - RADIUS Accounting

RADIUS Accounting RFC in June 2000 version.
Table 12-15
Summary of conformance to RADIUS Accounting
2.0 Operation Supported.
2.1 Proxy Not Applicable. GGSN acts as
NAS.
3.0 Packet Format Supported.
4.0 Packet Types Supported.
4.1 Accounting-Request Supported.
4.2 Accounting-Response Supported.
5.0 Attributes Supported.
5.1 Acct-Status-Type Supported.
5.2 Acct-Delay-Time Supported.
5.3 Acct-Input-Octets Supported.
5.4 Acct-Output-Octets Supported.
5.5 Acct-Session-Id Supported.
5.6 Acct-Authentic Supported.
5.7 Acct-Session-Time Supported.
5.8 Acct-Input-Packets Supported.
5.9 Acct-Output-Packets Supported.
5.10 Acct-Terminate-Cause Supported.
5.11 Acct-Multi-Session-Id Not Supported.
Multi-link PPP is not supported on

the GGSN.
5.12 Acct-Link-Count Not supported. Multi-link PPP is
not supported on the GGSN.
5.13 Table of Attributes Accounting particular attributes are
discussed above. Compliance for
other attributes is included in the
compliance document for
RFC2865.
6.0 IANA Considerations Noted


7.0 Security Considerations Noted
8.0 Change log Noted
9.0 References Noted
10.0 Acknowledgements Noted
11.0 Chair’s Address Noted
RFC 1661 - Point-to-Point Protocol (PPP)

PPP RFC in July 1994 version.
Table 12-16
Summary of conformance to PPP
1 Introduction Noted
1.1 Specification of Requirements Noted
1.2 Terminology Noted
2 PPP Encapsulation Supported
3.1 Overview Supported.
3.2 Phase Diagram Supported.
3.3 Link Dead (physical-layer not ready) Supported.
3.4 Link Established phase Supported.
3.5 Authentication Phase Supported
3.6 Network-Layer Protocol Phase Supported.
3.7 Link Termination Phase Supported.
4 The Option Negotiation Automation Noted
4.1 State Transition Table Supported
4.2 States Supported
4.3 Events Supported.
4.4 Actions Supported
4.5 Loop Avoidance Noted
4.6 Counters and Timers Supported
5 LCP Packet Format Supported
5.1 Configure-Request Supported.
5.2 Configure-Ack Supported
5.3 Configure-Nak Supported.
5.4 Configure-Reject Supported.
5.5 Terminate-Request and Terminate-Ack Supported.
5.6 Code-Reject Supported. On receipt of code-
reject, it is recommended that the
connection being dropped.
Current implementation just
ignores the message.
5.7 Protocol-Reject Supported.
5.8 Echo-Request and Echo-Reply Supported
5.9 Discard-Request Supported.
6 LCP Configuration Options Supported.


6.1 Maximum-Receive-Unit Supported
6.2 Authentication Protocol Supported
6.3 Quality-Protocol Supported
6.4 Magic-Number Supported
6.5 Protocol-Field-Compress Supported
6.6 Address-and-Control-Field- Not Supported.
Compression (ACFC)
GGSN does not support this
option. It is used for HDLC.
7 Miscellaneous Items Supported.
RFC 2661 - Layer Two Tunneling Protocol (L2TP)

L2TP RFC in August 1999 version.
Table 12-17
Summary of conformance to L2TP
2.0 Topology Supported. GGSN can act as
LAC only.
3.0 Protocol Overview Supported.
3.1 L2TP Header Format Supported.
3.2 Control Message Types Supported.
WEN and SLI messages are not

applicable for GGSN. See 6.13
and 6.14.
4.0 Control Message Attribute value pairs Supported.
4.1 AVP Format Supported.
4.2 Mandatory AVPs Supported.
4.3 Hiding of AVP Attribute Values Supported.
4.4 AVP Summary Supported.
4.4.1 AVPs Applicable to All Control Supported.
Messages


4.4.2 Result and Error Codes Supported.
4.4.3 Control Connection Management Supported.
AVPs
Protocol Version Supported.
Framing Capabilities Supported.
Bearer Capabilities Supported.
Tie Breaker Supported.
Firmware Revision Supported.
Vendor Name Supported.
Assigned Tunnel ID Supported.
Receive Window Size Supported.
Challenge Supported.
Challenge Response Supported.


4.4.4 Call Management AVPs Supported.
Cause Code Supported.
Assigned Session ID Supported.
Call Serial Number Supported.
Minimum BPS Supported.
Maximum BPS Supported.
Bearer Type Supported.
Framing Type Supported.
Called Number Supported.
GGSN sends APN as Called

Number.
Calling Number Supported.
GGSN sends MSISDN as Calling

Number.
Sub-Address Not Supported.
This is a field for passing

additional dialing information from
the LAC to the LNS.
Tx Connect Speed Supported.
Rx Connect Speed Supported.
Physical Channel ID Supported.
Private Group ID Not Supported.
This field is used by the LAC to

indicate the call is associated with
a particular customer group.
Sequencing Required Supported.
4.4.5 Proxy LCP and Authentication AVPs Supported.
Initial Received LCP CONFREQ Supported.
Last Sent LCP CONFREQ Supported.
Last Received LCP CONFREQ Supported.
Proxy Authen Type Partially Supported.
Only authen type of 2,3, and 4

are supported.
Proxy Authen Name Supported.
Proxy Authen Challenge Supported.
Proxy Authen ID Supported.
Proxy Authen Response Supported.
4.4.6 Call status AVPs Not Applicable. See below.
Call Errors Not Applicable. It is used for
HDLC.
ACCM Not Applicable. It is used for
HDLC.


5.0 Protocol Operation Supported.
5.1 Control Connection Establishment Supported.
5.1.1 Tunnel Authentication Supported.
5.2 Session Establishment Supported.
5.2.1 Incoming Call Establishment Supported.
5.2.2 Outgoing Call Establishment Not Applicable.
Only incoming calls are

supported on the GGSN (acting
as LAC).
5.3 Forwarding PPP Frames Supported.
5.4 Using Sequence Numbers on the Supported.
Data Channel
5.5 Keep Alive Supported.
5.6 Session Teardown Supported.
5.7 Control Connection Teardown Supported.
5.8 Reliable Delivery of Control Supported.
Messages
6 Control Connection Protocol Supported.
Specification
6.1 Start-Control-Connection-Request Supported.
(SCCRQ)
6.2 Start-Control-Connection-Reply Supported.
(SCCRP)
6.3 Start-Control-Connection-Connected Supported.
(SCCCN)
6.4 Stop-Control-Connection-Notification Supported.
(StopCCN)
6.5 Hello (HELLO) Supported.
6.6 Incoming-Call-Request (ICRQ) Supported.
6.7 Incoming-Call-Reply (ICRP) Supported.
6.8 Incoming-Call-Connected (ICCN) Supported.
6.9 Outgoing-Call-Request (OCRQ) Not Applicable.

supported on the GGSN (acting
as LAC).
6.10 Outgoing-Call-Reply (OCRP) Not Applicable. Same as above.
6.11 Outgoing-Call-Connected (OCCN) Not Applicable. Same as above.
6.12 Call-Disconnect-Notify (CDN) Supported.
6.13 WAN-Error-Notify (WEN) Not Applicable. I is used for
HDLC.
6.14 Set-Link-Info (SLI) Not Applicable. I tis used for
HDLC.
7 Control Connection State Machines Supported.
7.1 Control Connection Protocol Supported.
Operation


7.2 Control Connection States Supported.
7.2.1 Control Connection Establishment Supported.
7.3 Timing Consideration Supported.
7.4 Incoming Callas Supported.
7.4.1 LAC Incoming Call States Supported.
7.4.2 LNS Incoming Call States Not Applicable. GGSN only acts
as LAC.
7.5 Outgoing Calls Not Applicable.

supported on the GGSN.
7.5.1 LAC Outgoing Call States Not Applicable. Same as above.
7.5.2 LNS Outgoing Call States Not Applicable. Same as above.
7.6 Tunnel Disconnection Supported.
8 L2TP over Specific Media Supported.
8.1 L2TP over UDP/IP Supported.
8.2 IP Partially Supported.
There is no other configurable

configuration.
9 Security Consideration Supported.
9.1 Tunnel Endpoint Security Supported.
9.2 Packet Level Security Supported.
9.3 End to End Security Supported.
9.4 L2TP and IPSEC Supported.
9.5 Proxy PPP Authentication Supported.
10 IANA Consideration Supported.
11 References Noted.
12 Acknowledgement Noted.
13 Authors’ Addresses Noted.
Appendix A Control Channel Slow Start and Not Supported. The procedure is
Congestion Avoidance only recommended.
Appendix B Control Message Examples Supported.
Appendix C Intellectual Property Notice Supported.
RFC 2858 - Multiprotocol Extensions for BGP-4

Fully supported.
RFC 2547bis (draft-ietf-ppvpn-rfc2547bis-02.txt)
Table 12-18
RFC 2547bis Conformance

1 Introduction Partial (see 1.1 through 1.7)

1.1 Virtual Private Networks Partially supported
(Attention: Extranets, policies governed

by CEs, and partial mesh VRF
connectivity are not supported.)
1.2 Edge Devices Partially supported
(Attention: The Nortel GGSN, in the

role of a PE, supports only the listed
functionality associated with PEs.)
1.3 Multiple Forwarding Tables in PEs Supported
1.4 VPNs with Overlapping Address Space Supported
1.5 VPNs with Different Routes to the Same Not supported

System
1.6 SP Backbone Routers Supported

1.7 Security Noted
2 Sites and CEs Partially supported
(Attention: A given subscriber can only

be a member of a single VPN.)
3 Per-Site Forwarding Tables in the PEs Partially supported
(Attention: Multiple routes to the same

site are not supported.)
4 VPN Route Distribution via BGP Supported
4.1 The VPN-IPv4 Address Family Supported
4.2 Encoding of Route Distinguishers Supported
4.3 Controlling Route Distribution Partially supported (see 4.3.1 through

4.3.6)
4.3.1 The Route Target Attribute Supported

4.3.2 Route Distribution Among PEs by BGP Partially supported
(Attention: The following functional

areas are not supported.
- Route Reflector Server
- PE peer in different AS
- Inner Label mapping to access port
- Outbound route filtering
- Inbound filtering
4.3.3 Use of Route Reflectors Partially supported
(Attention: Support is provided only for

Route Reflector client functionality.)
4.3.4 How VPN IPv4 NLRI is Carried in BGP Supported

4.3.5 Building VPNs using Route Targets Partially supported
(Attention: “Hub and spoke” VPNs are

not supported.)
4.3.6 Route Distribution Among VRFs in a Supported

Single PE
5 Forwarding Across the Backbone Supported
6 Maintaining Proper Isolation of VPNs Supported
7 How PEs Learn Routes from CEs Not applicable
8 How CEs Learn Routes from PEs Not applicable

9 Carriers’ Carriers Not supported
10 Inter-Provider Backbones Not supported
11 Accessing the Internet from a VPN Supported

12 Management VPNs Not supported
13 Security Partially supported (see 13.1 through

13.3
13.1 Data Plane Partially supported
(Attention: Inter-provider VPNs are not

supported.)

13.2 Control Plane Not supported
13.3 Security of P and PE devices Supported

14 Quality of Service Partially supported
(Attention: Support is provided only for

DSCP->EXP mapping, via E-LSPs.)
15 Scalability Partially supported
(Attention: Route reflector server and

multi-provider VPNs are not supported,
and the Nortel GGSN does not act as a
P router.
16 Intellectual Property Considerations Noted
17 Acknowledgements Noted
18 Authors’ Addresses Noted
19 Normative References Noted
20 Informational References Noted

21 Full copyright Statement Noted
RFC 3036 - LDP Specification
Table 12-19
RFC3036 Conformance

1. Introduction Noted
2. LDP Operation Partially supported (see

subsections)
2.1 FECs Partially supported
(Attention: Address
prefixes are not supported
as a FEC element type.)
2.2 Label Spaces, Identifiers, Sessions and Partially supported (see

Transport subsections)

2.2.1 Label Spaces Partially supported
(Attention: per platform

spaces are not supported)
2.2.2 LDP Identifiers Partially supported
(Attention: per platform

spaces are not supported)
2.2.3 LDP Sessions Partially supported
(Attention: sessions can

be established only to
directly-connected LSRs)
2.2.4 LDP Transport
2.3 LDP Sessions between non-Directly Not supported

Connected LSRs
2.4 LDP Discovery Partially supported (see

subsections)
2.4.1 Basic Discovery Supported
2.4.2 Extended Discovery Not supported
2.5 Establishing and Maintaining LDP Sessions Partially supported
(Attention: Frame relay is

not supported)
2.6 Label Distribution and Management Partially supported
(Attention: Downstream
On Demand distribution is
not supported)
2.6.1 Label Distribution Control Mode Noted
2.6.1.1 Independent Label Distribution Control Supported

2.6.1.2 Ordered Label Distribution Control Not supported
2.6.2 Label Retention Mode Noted
2.6.2.1 Conservative Label Retention Mode Not supported

2.6.2.2 Liberal Label Retention Mode Supported

2.6.3 Label Advertisement Mode Partially supported
(Attention: Downstream
On Demand distribution is
not supported)
2.7 LDP Identifiers and Next Hop Addresses Supported

2.8 Loop Detection Supported
2.9 Authenticity and Integrity of LDP Messages Not supported
2.10 Label Distribution for Explicitly Routed LSPs Noted
3 Protocol Specification Noted
3.1 LDP PDUs Supported
3.2 LDP Procedures Noted
3.3 Type-Length-Value Encoding Supported
3.4 TLV Encodings for Commonly Used Noted

Parameters
3.4.1 FEC TLV Partially supported
(Attention: Wildcard and

Prefix FEC Element types
are not supported.
FEC TLVs with more than

one FEC element are not
supported)
3.4.2 Label TLVs Noted

3.4.2.1 Generic Label TLV Supported
3.4.2.2 ATM Label TLV Not supported
3.4.2.3 Frame Relay Label TLV Not supported

3.4.3 Address List TLV Supported
3.4.4 Hop Count TLV Supported
3.4.5 Path Vector TLV Supported
3.4.6 Status TLV Supported
3.5 LDP Messages Noted

3.5.1 Notification Message Partially supported
(Attention: the Extended

Status optional parameter
is not supported)
3.5.2 Hello Message Partially supported
(Attention: The following

Common Hello Parameters
are not supported: T
(Targeted Hello) and R
(Request Send Targeted
Hellos).
The following optional

parameters are not
supported: Configuration
Sequence Number and
IPv6 Transport Address.)
3.5.3 Initialization Message Partially supported
(Attention: The ATM

Session Parameters and
Frame Relay Session
Parameters are not
supported.)
3.5.4 KeepAlive Message Supported
3.5.5 Address Message Supported
3.5.6 Address Withdraw Message Supported

3.5.7 Label Mapping Message Partially supported
(Attention: The Label

Request Message ID
optional parameter is not
supported.)
3.5.8 Label Request Message Not supported
3.5.9 Label Abort Request Message Not supported
3.5.10 Label Withdraw Message Supported
3.5.11 Label Release Message Supported
3.6 Messages and TLVs for Extensibility Not supported

3.7 Message Summary Noted
3.8 TLV Summary Noted

3.9 Status Code Summary Noted
3.10 Well-known Numbers Noted
4 IANA Considerations Noted

5 Security Considerations Noted
6 Areas for Future Study Noted
7 Intellectual Property Considerations Noted
8 Acknowledgements Noted
9 References Noted
10 Authors’ Addresses Noted
Appendix LDP Label Distribution Procedures Noted

A
RFC 3588 - Diameter Base Protocol

See Nortel Network technical specification for details.
IETF Draft RFC - Diameter Credit Control (draft-ietf-aaa-diameter-cc-

03.txt)
See Nortel Networks technical specification for details.
RFC 2616 - Hypertext Transfer Protocol - HTTP/1.1 Specification
Table 12-20
RFC2616 Conformance
8.1.2.2 Pipelining Supported
RFC 2702 - Requirements for Traffic Engineering Over MPLS
Table 12-21
RFC 2702 conformance
5.0 Traffic Trunk attributes


5.1 Bidirectional Traffic Trunks Not supported
5.2 Basic operations on traffic trunks Supported
5.3 Accounting & Performance Monitoring Not Supported
5.5 Traffic Parameter Attributes Partially Supported.
Only the bandwidth parameter can be

specified. The bandwidth specified by the
users is used only for RSVP-TE
signaling; it is not used to do bandwidth
reservation on GGSN interfaces. The
traffic parameters like peak burst rate are
derived from this parameter and the MTU
size.
5.6 Generic Path Selection & Mtc. Attributes Not Supported
5.6.1 Administratively specified explicit paths Partially Supported.
Supports loose/strict IP hops.

5.6.2 Hierarchy of Preference rules for Multi- Partially Supported.
Paths
One primary and one secondary path per
Tunnel.
5.6.3 Resource Class affinity Not Supported
5,6,4 Adaptivity attribute Not Supported
5.6.5 Load distribution among parallel traffic Not supported
trunks
5.7 Priority attribute Supported
5.8 Pre-emption attribute Not Supported
5.9 Resilience attribute Supported
Can specify per tunnel whether to

reroute traffic or not.
5.10 Policing attribute Not Supported
6.0 Resource Attributes Not Supported
7.0 Constraint Based Routing Not Supported
7.1 Use of TEDB to compute constraint Not Supported
based path
7.2 OSPF-TE/ISIS-TE Extensions Partially Supported.
ISIS-TE is not supported.

RFC 2205 - Resource ReSerVation Protocol (RSVP) -- Version 1

Functional Specification
Table 12-22
RFC 2205 Compliance

1.1 Data Flows: Unicast, Multicast Supported
1.3 Reservation Styles Partially Supported.
Fixed Filter & Shared Explicit -

Supported.
Wildcard Filter - Not supported.
2.2 Merging Flowspec Not Supported.
No reservation performed on the Shasta

2.3 Soft State Supported
2.4 Teardown Supported
2.5 Errors Supported

2.6 Confirmation Not Supported
2.7 Policy Control Not Supported
2.8 Security Not Supported

2.9 Non-RSVP Cloud Supported
2.10 Host Model
3.1.1 RSVP Message Formats Supported
3.1.2 RSVP Objects Partially Supported.
INTEGRITY, SCOPE, RESV_CONFIRM

not supported.
3.1.3 Path Messages Supported
3.1.4 Resv Messages Supported
3.1.5 PathTear Messages Supported
3.1.6 ResvTear Messages Supported
3.1.7 PathErr Messages Supported

3.1.8 ResvErr Messages Supported
3.1.9 Confirmation Messages Not Supported.

Table 12-22
RFC 2205 Compliance (continued)

3.2 Port Usage Not Supported.
3.3 Sending RSVP Messages Supported
3.4 Avoiding RSVP message loops Not Supported.
GGSN never forwards RSVP messages

3.5 Blockade state Supported
3.6 Local repair Supported
3.7 Time Parameters: Refresh period, State Supported

Lifetime
3.8 Traffic policing & Non-integrated Service Not Supported

Hops
3.9 Multihomed hosts Not Supported
3.10 Future compatibility Supported
3.11 RSVP Interfaces Noted

RFC 3209 - RSVP-TE: Extensions to RSVP for LSP Tunnels

Table 12-23
RFC 3209 Conformance

3.0 LSP Tunnel related Message Formats Partially Supported
3.1 Path Message Partially Supported
3.1 (cont’d) INTEGRITY Not Supported

3.1 (cont’d) SESSION Partially Supported
(see the conformance for section 4.6.1

in this table)
3.1 (cont’d) RSVP_HOP Supported
3.1 (cont’d) TIME_VALUES Supported
3.1 (cont’d) EXPLICIT_ROUTE Partially Supported
(see the conformance for section 4.3 in

this table)
3.1 (cont’d) LABEL_REQUEST Partially Supported
(see the conformance for section 4.2 in

this table)
3.1 (cont’d) SESSION_ATTRIBUTE: Without Supported

Resource Affinities
3.1 (cont’d) SESSION_ATTRIBUTE: With Resource Not Supported

Affinities
3.1 (cont’d) SENDER_TEMPLATE Partially Supported

in this table)
3.1 (cont’d) SENDER_TSPEC Supported
3.1 (cont’d) ADSPEC Not Supported
3.1 (cont’d) RECORD_ROUTE Not Supported
3.2 Resv Message Partially Supported
3.2 (cont’d) INTEGRITY Not Supported

3.2 (cont’d) SESSION Partially Supported

in this table)

Table 12-23
RFC 3209 Conformance (continued)
3.2 (cont’d) RSVP_HOP Supported
3.2 (cont’d) TIME_VALUES Supported
3.2 (cont’d) RESV_CONFIRM Not Supported

3.2 (cont’d) SCOPE Supported
3.2 (cont’d) POLICY_DATA Supported
3.2 (cont’d) STYLE Supported
3.2 (cont’d) Flow Descriptor List Partially Supported
3.2 (cont’d) Flow Spec - Cos, Max Packet Size Supported
Filter Spec, Label
3.2 (cont’d) RECORD_ROUTE Partially Supported
(/32 IPv4 addresses only)
4.0 LSP Tunnel Related Objects Partially Supported
4.1 Label Object in Resv messages Supported
4.2 LABEL_REQUEST object Partially Supported
4.2.1 Without Label Range (C-type=1) Supported
4.2.2 ATM Label Range (C-type=2) Not Supported
4.2.3 FR Label Range (C-type=3) Not Supported
4.2.4 Handling of LABEL_REQUEST Object Supported

4.2.5 Non-Support of LABEL_REQUEST Not applicable
Object
4.3 Explicit Route Object (ERO) in Path Partially Supported

Messages
Support only a strict/loose sequence of /
32 IPv4 addresses
4.3.5 ERO Loop Detection Supported
4.3.6 ERO Forward Compatability Supported
4.4 Record Route Object (RRO) Partially Supported
Only /32 IPv4 addresses are supported.
4.4.4 RRO Loop Detection Supported

Table 12-23
4.4.5 RRO Forward Compatibility Not Supported
4.6.1 Session Object Partially Supported
only LSP_TUNNEL_IPv4 supported.
4.6.2 Sender Template Partially Supported
only LSP_TUNNEL_IPv4 supported.
4.6.3 Filter Specification

4.6.4 Reroute & Bandwidth Increase
4.7.3 Support for setup & holding priorities Only passes information downstream
4.7.4 Resource Affinity Procedures Not Supported

5.0 Hello Extension Supported

RFC 3630 - TE Extensions to OSPF Version 2

Table 12-24
RFC 3630 Conformance

1.0 Introduction Noted
2.0 LSA Format Supported
2.4 LSA Payload Detail Supported

2.4.1 Router Address TLV Supported
2.4.2 Link TLV Supported
2.5 Sub-TLV Details Partially Supported
2.5.1 Link Type Partially Supported
(Point-to-Point links are not supported)

2.5.2 Link ID Supported
2.5.3 Local Interface IP address Supported
2.5.4 Remote Interface IP address Supported
2.5.5 Traffic Engineering Metric Supported
2.5.6 Maximum Bandwidth Partially Supported
GGSN always includes a constant value

for this parameter, independent of the
bandwidth consumed by any
established tunnels.

Table 12-24
2.5.7 Maximum Reservable Bandwidth Partially Supported

2.5.8 Unreserved Bandwidth Partially Supported

2.5.9 Administrative Group Not Supported
3.0 Elements of Procedure Not Supported
GGSN doesn’t update its TE LSAs as

LSPs get established. This is because
GGSN doesn’t support any bandwidth
reservation on its own interfaces.


A-1
Patching System A
GGSN CMC and SSC patching
From time to time, patches will need to be applied to a live GGSN
without impacting the operation of the tasks being executed by any
particular GGSN processor. The GGSN incorporates a variety of card
types with variable numbers of processors. The GGSN patch manager
addresses the requirements to patch the Control and Management
Card (CMC) and the Subscriber Service Card (SSC).
Attention: Patches are only available for GGSN. SCS software is

not patchable.
GGSN patches can be applied from the SCS client. Patch status are
recorded on the SCS client for synchronization and reporting. Each
patching action for a GGSN generates a System Information Log.
These logs, along with other System Information Logs, are displayed
as Session Logs for the device.
The GGSN patch manager provides mechanisms to apply and remove

patches without interruption of service. Although some patches may
require a resync due to the nature of the bugs or the features in
question, no interruption to service is the primary goal for patching.
Patching requires the Trivial File Transfer Protocol (TFTP) be enabled

on the SCS server. GGSNs use this protocol to request and download
software patches from the SCS server. As configured for the SCS,
Solaris TFTP offers no risk to obtain unauthorized file access or grants
of higher system privileges. Since a GGSN may request patches at
any time due to patch activation, software load changes, reboots, and
CMC switchover, TFTP should remain enabled on the SCS server.
Disabling TFTP on the SCS server would result in a system that could
no longer be patched and resync of affected GGSNs could fail.
Patch Package
Beginning with GGSN 5.0.1 release, the GGSN can be patched with a
patch package. A patch package is a bundle of patches that can be

A-2 Patching System Copyright © 2000–2008 Nortel Networks
applied to the GGSN. The patch package is distributed as a ‘tar’ file.

Detailed patching instructions are explained later in this document.
Attention: There are no patch packages available for GGSN

software releases prior to GGSN 5.0.1
Patching functions
Persistency operation
The persistency operation sets the state of a patch for the entire
system. The possible persistency operations are Persistent and Non-
Persistent. Persistent means that the patch is to be automatically
loaded when the GGSN reboots; the user marks patches persistent
after sanity of the patch has been verified. Non-persistent means that
the patch is not automatically reapplied if the GGSN reboots. Patches
can move between the persistent state and the non-persistent state.
Patching directives
The Activate operation turns on special functionality that the patch
writer built into the patch. This operation gives the patch writer the
flexibility of applying the patch before completely turning on all new
functionality. The user can activate a patch by setting the directive in
the patch rule; it can also be invoked through the “Sync States”
operation (explained later).
The Deactivate operation turns off the special functionality that has
been coded into the patch. The user can deactivate a patch by setting
the patch directive in the patch rule; it can also be invoked through the
“Sync States” operation.
Verify operation
The Verify operation performs many of the patch verification steps to
see if the patch profile can be applied to a particular GGSN. Among
other things, this operation makes sure the device can download the
patches in the profile. The GGSN decompresses the patch files and
verifies basic file integrity. The device also makes sure the patches for
the current system release fit into the available patch memory. The
device always generates an event log when a verify operation is
performed. This operation does not affect patch status.
Query operation
The Query operation allows the user to query the available patch
memory and the status of patches on particular nodes. This operation
does not affect the patch status on the GGSN, but it may update the
current status of the patches on the SCS.

Patching System A-3
Sync operation
The Sync operation causes the GGSN to make sure that it has all
patches that the SCS thinks it should have. Discrepancies may have
been created due to network connectivity issues or other race
conditions. The Sync operation may cause the GGSN to apply,
unapply, activate or deactivate patches.
Unapply Operation
This operation causes a patch to be removed from the GGSN. All
configuration information and associated patch files are permanently
deleted.
GGSN upgrade strategy

The contents of a patch profile can span multiple releases; for
example, a profile could have patch rules that contain patches for a
current load and patches for a future load. To upgrade, for example,
from Release A to Release B, an existing Release A profile is cloned.
This profile is overridden on a device that is scheduled to receive the
new load. When this device moves to the new load, the new release
patches are applied to the device. If the device moves back to the old
load, the old release patches are still available to be patched. As
devices are scheduled to move to the new load, their profile is
overridden with the cloned profile. Once all devices have been
upgraded to the new release, the old patch rules should be manually
removed from the cloned profile.
Patching privileges
By default, only ‘device_owner’ user on the SCS client is given
access to Add/ Modify/ Delete patch functionality. To access the
patching functionality, the ‘device_owner’ user selects the patch icon
in the Image Panel or the Patch Manager item in the View menu.
Reference
Please refer to GGSN NTP: Nortel GGSN Provisioning Procedures
(411-5221-927) for GGSN 5.0.1 for detailed instructions of GGSN
patching functionality.

A-4 Patching System Copyright © 2000–2008 Nortel Networks

B-1
Detailed Protocol Information B

This appendix provides detailed GGSN related protocol information
that includes GTP protocol extension, GTP’ charging protocol,
RADIUS protocol attributes, WRAP protocol, Card Telephony Protocol
(CTP) and Diameter Credit Control (DCC) protocol.
GTP Protocol Extension

This section specifies the private extension IE used to transfer Nortel
Networks proprietary information over the Gn and Gp interfaces. The
is an optional IE and can be included in any GTP signaling messages.
Private Extension IE
On the Nortel GGSN, the following Private Extension IE is included in
the Create PDP Context Request message and Update PDP Context
Request message sent from the SGSN. The Extension Identifier field
is the value of the Private Enterprise number defined in RFC 1700.
The Cell Global Identification of GTP version 0 and the Service Area
Identifier (SAI) of GTP version 1 are the information included in the
Extension Value field.
The Opcode Type is set to 2 for GTP version 0 and set to 3 for GTP
version 1 in the private extension. The Routing Area Code (RAC) field
of Cell Global ID and SAI is optional. As a result, there are 2 formats
for the Cell Global ID and SAI which is identified by the Length field in
the private extension. The format of Extension IE for GTP version 0 is
specified in Figure B-1 and the format for GTP version 1 is specified in
Figure B-2.
The Cell Global ID and SAI information received in the incoming

messages are forward to the Prepaid Server for the GeoZone Service.

B-2 Detailed Protocol Information Copyright © 2000–2008 Nortel Networks
Figure B-1
The Private Extension IE Format for GTP Version 0
Bits
Octets 8 7 6 5 4 3 2 1
1 Type = 255 (Decimal)
2 -3 Length
4-5 Extension Identifier = 562 (Decimal)

6 Opcode Type = 2 (Decimal)
7 Mobile Country Code

8
9 Mobile Network Code
10 - 11 Location Area Code

12 Routing Area Code (Optional)
13 - 14 Cell Identity
means optional field

Figure B-2
The Private Extension IE Format for GTP Version 1
Bits
Octets 8 7 6 5 4 3 2 1
1 Type = 255 (Decimal)
2 -3 Length
4-5 Extension Identifier = 562 (Decimal)

6 Opcode Type = 3 (Decimal)
7
Mobile Country Code
8
9 Mobile Network Code
10 - 11 Location Area Code

12 Routing Area Code (Optional)
13 - 14 Service Area Code
means optional field
The format of Cell Global ID is defined in 3GPP TS 09.02 - Mobile

Application Part Specification. The format of Service Area Identifier
(SAI) is defined in 3GPP TS 25.413 - UTRAN lu Interface RANAP
Signaling.
IMS Protocol Configuration Options IE

3GPP TS 24.008 specifies that the returned P-CSCF address is IPv6.
Since the provisioned P-CSCF address via SCS GUI are IPv4, the
format of the returned addresses is configurable. The addresses can
be encoded as “IPv4 mapped IPv6 addresses”. See Table B-1 for an
example of this encoding. Alternately, the P-CSCF address may be
encoded as IPv4 addresses. See Table B-2 for an example of this
encoding.
If multiple P-CSCF address are sent, multiple P-CSCF Address

containers are included in the PCO. The number of P-CSCF
Addresses returned is limited by the maximum size of the PCO as well

as other configuration options contained within the PCO (PAP/CHAP,

etc.).
Table B-1
IPv4 mapped IPv6 P-CSCF Address format
PCO Field Value

Container ID (P-CSCF Address) 0x00
0x01
Length (16 bytes) 0x10
IPv4 mapped IPv6 address Filler 0x00
0x00
0x00
0x00
0x00
0x00
0x00
0x00
0x00
0x00
Mapped 0xFF
address Ind
0xFF
IPv4 Address 0xXX

0xXX
0xXX
0xXX
Table B-2
IPv4 P-CSCF Address format
PCO Field Value
Container ID (P-CSCF Address) 0x00
0x01
Length (4 bytes) 0x04

IPv4 Address 0xXX
0xXX
0xXX
0xXX
GTP’ Charging Protocol

The GTP’ charging protocol has been designed to deliver G-CDR to
the CGF for the charging data collection. The G-CDR format and GTP
accounting related information are detailed in the following sections.
G-CDR Record Format

The following tables list the fields with the appropriate ASN.1 types.
The “shaded” fields listed in the following table are not supported by
Nortel GGSN and will not be generated or included in any G-CDR sent
to CGF. All IP addresses used in G-CDRs will be IPv4, binary
formatted as per the ASN.1 definition.
The tables below depict all the mandatory, conditional, and optional
fields supported in the G-CDR, as well as the format and sizes of the
fields when transferred to the CGF compliant to 32.015 version 3.2.0
and version 3.6.0. The fields are encoded in the least amount of bytes
possible per the encoding rules of the encoding format used.
Table B-3
G-CDR Fields and Descriptions for 32.015 version 3.2.0
Field Description Encoding Size

Format (Bytes)
Record Type M GGSN PDP Context Record Integer 1-4
Network C Present if this is a network initiated PDP context

Initiated PDP
Context
Served IMSI M IMSI of the served party (if Anonymous Access BCD- 3-8
Indicator is FALSE or not supplied). encoded
Octet
String
Served O The primary MSISDN of the subscriber. NPI+NOA BCD- 1-9

MSISDN is in the first octet of this field. encoded
Octet
String


Format (Bytes)
GGSN M IP address of the GGSN used. Hex-value 4

Address Octet
String
Charging ID M PDP context identifier used to identify this PDP Unsigned 1-4
context in different records created by GSNs. Integer
SGSN M List of SGSN addresses used during the open Hex-value 4 bytes
Address lifetime of the record Octet per
String address
Access Point M The logical name of the connected access point to IA5 String 1 - 63
Name the external packet data network (network
Network identifier par of APN).
Identifier
APN O An index indicating how the APN was selected. Unsigned 1- 4

Selection Integer
Mode
PDP Type M PDP type, i.e. IP or PPP Hex-value 2

Octet
String
Served PDP M PDP address, i.e. IPv4. Hex-value 4

Address Octet
String
Dynamic C Indicate whether served PDP address is dynamic, Boolean 1

Address Flag which is allocated during PDP context activation.
List of Traffic M A list of changes in charging conditions for this Table B-7
Data PDP context, each time stamped.
Volumes
Record M TimeStamp when this record was opened. BCD- 9

Opening encoded
Time Octet
String
Duration M Duration of this record in the GGSN. Integer 1-4
Cause of M The reason for the release of record from this Integer 1-4
Record GGSN.
Closing
Diagnostics O A more detailed reason for the release of the

connection.
Record C Partial record sequence number, only present in Integer 1-4

Sequence case of partial records.
Number


Format (Bytes)
Node ID O Name of the recording entity.
Record O A set of network/manufacturer specific extensions Table B-9 variable

Extensions to the record. in size
Local Record O Consecutive record number created by this Unsigned 1-4
Sequence node.The number is allocated sequentially Integer
Number including all CDR types.
Charging C The Charging Characteristics flag retrieved from Hex-value 1

Characteristi subscriber’s data as described in subclause Octet
cs 6.1.6.2a String
Table B-4
G-CDR fields and descriptions for 32.015 version 3.6.0

Format (Bytes)
Record Type M GGSN PDP Context Record Integer 1-4
Network C Present if this is a network initiated PDP context

Initiated PDP
Context
Served IMSI M IMSI of the served party (if Anonymous Access BCD- 3-8
Indicator is FALSE or not supplied). encoded
Octet
String
Served O The primary MSISDN of the subscriber. NPI+NOA BCD- 1-9

MSISDN is in the first octet of this field. encoded
Octet
String
GGSN M IP address of the GGSN used. Hex-value 4

Address Octet
String
Charging ID M PDP context identifier used to identify this PDP Unsigned 1-4
context in different records created by GSNs. Integer
SGSN M List of SGSN addresses used during the open Hex-value 4 bytes
Address lifetime of the record Octet per
String address
Access Point M The logical name of the connected access point to IA5 String 1 - 63
Name the external packet data network (network
Network identifier par of APN).
Identifier


Format (Bytes)
APN O An index indicating how the APN was selected. Unsigned 1-4
Selection Integer
Mode
PDP Type M PDP type, i.e. IP or PPP Hex-value 2

Octet
String
Served PDP C PDP address, i.e. IPv4. Hex-value 4
Address Octet
String
Dynamic C Indicate whether served PDP address is dynamic, Boolean 1
List of Traffic M A list of changes in charging conditions for this Table B-7
Data PDP context, each time stamped.
Volumes
Record M TimeStamp when this record was opened. BCD- 9

Opening encoded
Time Octet
String
Duration M Duration of this record in the GGSN. Integer 1-4
Cause of M The reason for the release of record from this Integer 1-4
Record GGSN.
Closing
Diagnostics O A more detailed reason for the release of the

connection.
Record C Partial record sequence number, only present in Integer 1-4

Number
Node ID O Name of the recording entity.
Record O A set of network/manufacturer specific extensions Table B-9 variable

Extensions to the record. in size
Local Record O Consecutive record number created by this Unsigned 1-4
Sequence node.The number is allocated sequentially Integer
Charging C The Charging Characteristics flag retrieved from Hex-value 2

Characteristi subscriber’s data as described in subclause Octet
cs 6.1.6.5 String

The following tables contain the fields in the partial/interim G-CDR.

This CDR contains fields necessary to identify the PDP Context and
mobile subscriber, and any dynamic fields that may vary from partial
record to partial record. This includes Traffic Data Volume Containers.
Table B-5
Subsequent Partial G-CDR Billing Record Fields version 3.2.0
Field Description
Record Type M GGSN PDP Context Record
Served IMSI M IMSI of the served party (if Anonymous Access

Indicator is FALSE or not supplied).
Served MSISDN C The primary MSISDN of the subscriber.
GGSN Address M IP address of the GGSN used.
Charging ID M PDP context identifier used to identify this PDP

context in different records created by GSNs.
SGSN Address M Access Point Name Network Identifier

Access Point M The logical name of the connected access point to
Name Network the external packet data network (network
Identifier identifier par of APN).
APN Selection C An index indicating how the APN was selected.

Mode
PDP Type M PDP type, i.e. IP or PPP

Served PDP M PDP address, i.e. IPv4
Address
Dynamic C Indicate whether served PDP address is dynamic,

List of Traffic M A list of changes in charging conditions for this

Data Volumes PDP context, each time stamped.
Record Opening M TimeStamp when this record was opened.
Time
Duration M Duration of this record in the GGSN.
Cause of Record M The reason for the release of record from this
Closing GGSN.
Record C Partial record sequence number, only present in
Number

Field Description
Record O A set of network/manufacturer specific extensions

Extensions to the record.
Local Record O Consecutive record number created by this

Sequence node.The number is allocated sequentially
Charging C The Charging Characteristics flag retrieved from

Characteristics subscriber’s data as described in subclause
6.1.6.2a
Table B-6
Subsequent Partial G-CDR Billing Record Fields for 32.105 version 3.6.0
Filed Description
Record Type M GGSN PDP Context Record
Served IMSI M IMSI of the served party (if Anonymous Access

Indicator is FALSE or not supplied).
Served MSISDN C The primary MSISDN of the subscriber.

GGSN Address M IP address of the GGSN used.
Charging ID M PDP context identifier used to identify this PDP

context in different records created by GSNs.
SGSN Address M List of SGSN addresses used during the open

lifetime of the record
Access Point M The logical name of the connected access point to

Name Network the external packet data network (network
Identifier identifier par of APN).
APN Selection C An index indicating how the APN was selected.

Mode
PDP Type M PDP type, i.e. IP or PPP

Served PDP C PDP address, i.e. IPv4
Address
Dynamic Address C Indicate whether served PDP address is dynamic,

Flag which is allocated during PDP context activation.
List of Traffic Data M A list of changes in charging conditions for this

Volumes PDP context, each time stamped.
Record Opening M TimeStamp when this record was opened.
Time
Duration M Duration of this record in the GGSN.

Filed Description
Cause of Record M The reason for the release of record from this
Closing GGSN.
Record Sequence C Partial record sequence number, only present in

Number case of partial records.
Record O A set of network/manufacturer specific extensions

Extensions to the record.
Local Record O Consecutive record number created by this

Sequence node.The number is allocated sequentially
Charging C The Charging Characteristics flag retrieved from

Characteristics subscriber’s data as described in subclause
6.1.6.5
The table below depicts the format of the Traffic Data Volume
Container.
The fields are encoded in the least amount of bytes possible per the
encoding rules of the encoding format used.
Table B-7
G-CDR Traffic Data Volume Container
Field Description Format Size

(Bytes)
QoS O Quality of Service Requested.

Requested
QoS O Quality of Service Negotiated. The size of this QoS Type 4 - 36

Negotiated structure is dependent on the GTP version used
and the billing version used. The largest the
structure could be 36 bytes if using GTP99 and
32.015 v3.2.
Uplink Data M Uncompressed data count (octets) received from Integer 1-4
Volume Gn interface.
Downlink M Uncompressed data count (octets) send to Gn Integer 1-4

Data Volume interface.
Change M Condition for closing the container Unsigned 1-4

Condition Integer
Change Time M Timestamp when new volume counts are started BCD- 9
or CDR is closed encoded
Octet
String

Attention: When a PDP Record is converted from 32.015 version

3.2.0 to version 3.6.0 for a GTP version 1 context, seven QoS field
values will not be available. These fields will be filled in with Best
Effort Values. This happens only in the rare scenario when the
specified upgrade procedure is not adhered to. The fields and Best
Effort values are shown in the table below.
Table B-8
Best Effort Values
QoS Fields Best Effort Values
Delay Class Delay Class 4
Reliability Class Unacknowledged GTP and

LLC; Acknowledged RLC,
Protected Data
Peak Throughput Up to 1 000 octet/s
Precedence Class Normal Priority
Mean Throughput Best Effort

Guaranteed bit rate for uplink 0 kbps
Guaranteed bit rate for 0 kbps

Downlink
G-CDR Management Extensions

Table B-9 describes the format of a G-CDR management extension.
For all management extensions created the Significance field is set to
1. The Tag and Length sub-fields are the first two in the Information
field. Tag and Length appear only once. If the data described after the
length field is larger than 127 bytes then the length field will be
represented in long form. In long form the first byte of the length field is
0x8_, where “_” is the number of bytes needed to describe the length.
Then the following “_” number of bytes is used to identify the length of
the data portion for the information field. For more information on the
length format see ITU-T Recommendation X.690. The Information
length field will contain the length of the information field in octets, not
including the tag and length fields themselves.All multi-byte types such
as uplink and downlink byte counts are sent in network byte order.
The fields are encoded in the least amount of bytes possible per the
encoding rules of the encoding format used.

Table B-9
Management Extension Format
Field Description Notes Sub-Field Format Size

ObjectID Identifier of The length and Length of Unsigne 2 bytes
Management value sub-fields ObjectID d Integer
Extension comprise the
objectid field. Value ASCII 11
string bytes
Significance Indicates if field Significance Boolean 1 byte

must be
understood by
receiver
Information Contains This field will vary

information section in length. It will
of the begin with a tag
management type and the
extension length of the
information
followed by the
information.
CBB Management Extensions

CBB Version 2
Table B-10 describes the format of the management extension. A CBB
management extension is included when the CDR contains one or
more special rates generated by the Content Based Billing IP service.
All special rates from all containers within the CDR are contained in a
single management extension. Only special rates with non-zero
counts are included. Any special rates which do not appear in the CDR
have zero counts. Note that it is possible for a special rate to appear in
one container and not others.
The ObjectID field for CBB Version 2 is “1.2.840.113533.4.10.1.1.2”.

This value is passed as an ASCII string. The data placed into this field
are encoded as an octet string with tag 0x04.
Table B-10
CBB Version 2 Information field detailed description
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04

Octet Bits
s
8 7 6 5 4 3 2 1
2 Length
3 Reserved Rate Container
4 Uplink byte count
5
6
8 Downlink bye count
9
10
11
The five sub-fields of the Information field (Container, Rate, Reserved,

Uplink Byte Count and Downlink Byte Count) are repeated from 1 to
20 times within the management extension. Each repetition of these
fields conveys the byte count within one CDR container of one special
rate. A CDR with four containers and all five special rates in both
directions for every container has the maximum of 20 repetitions.
The values of these five sub-fields are as follows:
Reserved
• The reserved field is not used at present. Both bits are set to the
value 1.
Rate
• The Rate field of the special rated count buckets is encoded as

follows:
Rate Value
rate 0 (free) 0
rate 1 1
rate 2 2
rate 3 3

rate 4 4
Container
• The container field identifies which of the up to four containers

within the G-CDR to which this special rate information
corresponds.
Uplink Byte Count
• The count field contains the number of bytes for the specified rate,
in the uplink (mobile -> GGSN) direction, for the specified
container.
Downlink Byte Count
• The count field contains the number of bytes for the specified rate,
in the downlink (GGSN -> mobile) direction, for the specified
container.
As mentioned above the information string in the management
extension is composed of a tag, a length and a value. Given an
example string - ‘04 09 C1 00 00 00 F0 00 00 00 F0’
04 = the tag value for octet string.
09 = the length of the information is 9 bytes.
C1 = a bit structure packed in big endian format. In this byte the

container and rate are listed. When decoded into binary form -
‘11000001’
11 = reserved for future use
000 = 0 for the rate
001 = 1 for the container
00 00 00 F0 = 240 for the uplink byte counts of the rate 0 of container 1
00 00 00 F0 = 240 for the downlink byte counts of the rate 0 of

container 1
CBB Version 3

Table B-11
CBB Version 3 Information Field
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length
3 Container ID Number of Content Type IDs
4 Content Type ID
6 Uplink Count
10 Downlink Count
11
12
13
Octet 3 represents the traffic volume container ID in which the content

IDs were captured along with the number of content IDs captured in
the container. This octet may be repeated when there are multiple
containers in a billing record and content types are captured in multiple
traffic volume containers. The bytes from 4 to 13 are repeated for each
unique content type ID. Furthermore we can have up to 4 containers in
CBB management extension. Once a PDP session uses 11 content
type IDs in a container, a partial billing record is generated with Cause
of Record Closing field set to Management Intervention. This G-CDR
generated will include the first 10 unique content type IDs accessed
while the corresponding traffic volume container was open. The 11th
rate will be included in the next partial record generated.
For example, the CBB management extension as ‘04 20 22 00 F4 00

00 00 F0 00 00 00 F0 00 C8 00 00 00 FF 00 00 00 FF 81 1F 40 00 00
00 F0 00 00 00 F0’. It is decoded below:
04 = tag value for octet string.

20 = the length of the information in 32 bytes (excluding tag and length

bytes)
22 = container ID = 1 (3 bits) of first container and number of Content

IDs = 2 (5 bits) in this container which in binary is 001|00010 = 22 hex
00 F4 = First content type ID of container 1
00 00 00 F0 = 240 for the uplink byte counts
00 00 00 F0 = 240 for the downlink byte counts
00 C8 = Second content type ID of container 1
00 00 00 FF = 255 for uplink byte count
00 00 00 FF = 255 for downlink byte count
81 = container ID and number of content IDs for the second container
1F 40 = First content type ID of container 2
00 00 00 F0 = 240 for uplink byte count
00 00 00 F0 = 240 for downlink byte count
CBB Version 4
Version 4 CBB Management extension version is introduced to
support reporting time usage for a particular content type identifier
within the G-CDR container.

Table B-12
CBB version 4 management extension
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length
4 Content Type ID

6 Uplink Count
7
8
10 Downlink Count
11
12
13
14 Time Usage
15
16
17
Time Usage
• The time usage field contains the total usage time for the specified
context typeid in seconds.
traffic volume containers. The bytes from 4 to 17 can be repeated up to
9 times within a container. Furthermore we can have up to 4
containers in CBB management extension. Once a PDP session uses
10 content type IDs in a container, a partial billing record is generated
with Cause of Record Closing field set to Management Intervention.
This G-CDR generated will include the first 9 unique content type IDs
accessed while the corresponding traffic volume container was open.
The 10th rate will be included in the next partial record generated.
For example, the CBB management extension as ‘04 1D 22 00 32 00

00 04 38 00 00 00 F0 00 00 00 0A 00 3C 00 00 00 F0 00 00 04 38 00
00 00 15’.
It is decoded below:

1D = the length of the information in 29 bytes (excluding tag and length

bytes)

IDs =
2 (5 bits) in this container which in binary is 001|00010 = 22 hex
00 32 = First content type ID of container 1
00 00 04 38 = 1080 for the uplink byte counts
00 00 00 0A = 10 seconds of usage time.
00 3C = Second content type ID of container 1
00 00 04 38 = 1080 for downlink byte count
00 00 00 15 = 21 seconds of usage time.
Upgrade of the CGF to support this management extension version is

required before changing the configuration of CBB management
extension version setting in CGF Profile on GGSN to prevent loss of
billing information.
CBB Version 5
Version 5 CBB Management extension version is introduced to
support reporting time usage for a particular content type identifier
within the G-CDR container.
The ObjectID field for Version 5 is “1.2.840.113533.4.10.1.1.5”. This

value is passed as an ASCII string. The data placed into this field are
encoded as an octet string with tag 0x04.
Table B-13
CBB version 5 management extension
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length

4 Content Type ID
5
6 Uplink Count
8
9
10 Downlink Count
11
12
13
14 Time Usage
15
16
17
18 First packet timestamp
19
20
21
22 Remaining inactivity time
23
Time Usage
• The time usage field contains the total usage time for the specified
content typeid in seconds.
• The First packet timestamp contains the timestamp of the first
packet sent/received for the specified content typeid.
• The remaining inactivity time contains the unaccounted inactivity
time for the specified content typeid in seconds.


For example, the CBB management extension as ‘04 1D 22 00 32 00

00 04 38 00 00 00 F0 00 00 00 0A 41 0F 09 BC 00 04 00 3C 00 00 00
F0 00 00 04 38 00 00 00 15 41 0F 09 BA 00 05’.
It is decoded below:
1D = the length of the information in 29 bytes (excluding tag and length

bytes)

IDs =
00 32 = First content type ID of container 1
00 00 04 38 = 1080 for the uplink byte counts
00 00 00 0A = 10 seconds of usage time.
41 0F 09 BC = First packet timestamp.
00 04 = 4 seconds of remaining inactivity time.
00 3C = Second content type ID of container 1
00 00 04 38 = 1080 for downlink byte count
00 00 00 15 = 21 seconds of usage time.
41 0F 09 BA = First packet timestamp.

00 05 = 5 seconds of remaining inactivity time.
Upgrade of the CGF to support this management extension version is

required before changing the configuration of CBB management
extension version setting in CGF Profile on GGSN to prevent loss of
billing information.
CBB Version 6
New CBB Management extension version (version 6) is introduced to
support reporting event usage for a particular content type identifier
within the G-CDR container. Upgrade of the CGF to support this
management extension version is required before changing the
configuration of CBB management extension version setting in CGF
Profile on GGSN to prevent loss of billing information.

Additional 4 byte event counter is added for each content type id to

report event usage in the new version.
Table B-14
CGF CBB Management Extension version 6
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length
4 Content Type ID
6 Uplink Count
7
8
10 Downlink Count
11
12

13
14 Time Usage (in Seconds)
15
16
17
18 First packet timestamp

19
20
21
22 Remaining inactivity time
23
24 Event Count
25
26
27

For example, the CBB management extension as ‘04 4A 22 00 F4 00

00 00 F0 00 00 00 F0 00 00 0E 10 41 0F 09 BC 00 04 00 00 00 0A 00
C8 00 00 00 FF 00 00 00 FF 00 00 04 B0 41 0F 09 BA 00 05 00 00 00
00 81 1F 40 00 00 00 F0 00 00 00 F0 00 00 02 58 41 0F 09 CA 00 09
00 00 00 05’. It is decoded below:
4A = the length of the information in 74 bytes (excluding tag and length

bytes)


IDs =
00 F4 = First content type ID of container 1
00 00 00 F0 = 240 for the uplink byte counts
00 00 0E 10 = 3600 for the time usage (in seconds)
41 0F 09 BC = First packet timestamp
00 04 = 4 seconds of remaining inactivity time
00 00 00 0A = 10 for the event count
00 C8 = Second content type ID of container 1
00 00 00 FF = 255 for uplink byte count
00 00 00 FF = 255 for downlink byte count
00 00 04 B0 = 1200 for the time usage (in seconds)
41 0F 09 BA = First packet timestamp
00 00 00 00 = 0 for the event count
81 = container ID and number of content IDs for the second container
1F 40 = First content type ID of container 2
00 00 00 F0 = 240 for downlink byte count
00 00 02 58 = 600 for the time usage (in seconds)
41 0F 09 CA = First packet timestamp

00 00 00 05 = 5 for the event count.
Single APN Management Extensions

When single APN attributes are returned from a RADIUS response
during a PDP session activation the attributes will be placed in the first
G-CDR generated for a session. Each attribute will be placed in its
own management extension. The attributes for which management
extensions are created are Prepaid Server Profile name, Shasta
Service Profile Name, VPN Service Profile name, and Tunnel Endpoint
Server IP address. When storing the profile name in the management
extension, only the first 16 characters of a profile name are placed in
the management extension. The NULL terminator is not included in
the profile name stored in the management extension.
Service Profile Name

Shasta Service Profile is the name of the service profile that provides
the CBB policy. This Management Extension is present only if CBB
policy is defined and the profile name is available in
• RADIUS authentication Response or

• Prepaid authentication response or
• Subscriber Template or
• GGSN QoS Profile
If the Shasta Service Profile providing CBB is derived from the
subscriber template, then the subscriber template name is reported as
the Service Profile Name. Note that only the first 16 characters of
subscriber template name are added to the management extension.
The Object ID for SHASTA-SERVICE-PROFILE is assigned

“1.2.840.113533.4.10.1.2.1”.
Table B-15
Shasta Service Profile Information Field
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x16
2 Length
3-18 SHASTA-SERVICE-PROFILE (up to 16 characters of CBB profile name)
Example:

All values are in hex
Given the service profile name “ip_service_profile_1”
16 10 69 70 5F 73 65 72 76 69 63 65 5F 70 72 6F 66 69
16 = tag for IA5String
10 = length of information after the length field
69 70 5F 73 65 72 76 69 63 65 5F 70 72 6F 66 69 = ip_service_profi
VPN Profile Name

Table B-16
VPN Profile Information Field
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x16
2 Length
3-18 SHASTA-VPN (up to 16 characters of VPN name)
This extension contains the name of the VPN profile the subscriber
has been assigned. This Management Extension is present if
SHASTA-VPN VSA is returned in RADIUS Access-Accept message.
The Object ID for SHASTA-VPN is assigned
“1.2.840.113533.4.10.1.3.1”.
Example:
Given the VPN profile name “vpn_profile_1”
16 0D 76 70 6E 5F 70 72 6F 66 69 6C 65 5F 31
0D = length of information after the length field
76 70 6E 5F 70 72 6F 66 69 6C 65 5F 31 = vpn_profile_1
Prepaid Profile Name

Table B-17
Shasta Prepaid Profile Information Field
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x16
2 Length
3-18 SHASTA-PREPAID_SERVER (up to 16 characters of Prepaid Server
name)
This management extension contains the name of the tariff profile to

be used for the context. This Management Extension is present if
SHASTA_PREPAID_SERVER is returned in RADIUS Access-Accept
message. The Object ID for SHASTA-PREDPAID-PROFILE is
assigned “1.2.840.113533.4.10.1.4.1”.
Example:
Given the Prepaid profile name “prepaid_profile_1”
16 10 70 72 65 70 61 69 64 5F 70 72 6F 66 69 6C 65 5F
70 72 65 70 61 69 64 5F 70 72 6F 66 69 6C 65 5F = prepaid_profile_
Tunnel Server Endpoint IP Address
Table B-18
Tunnel Server Endpoint IP Address Information Field
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length
3 Tunnel Server Endpoint IP Address [3]

This Management Extension is present if Dynamic L2TP tunnel

information element is returned in RADIUS Access-Accept message.
The Object ID for Tunnel- Server-Endpoint is assigned
“1.2.840.113533.4.10.1.5.1”. The data is sent in network byte order
and only IPv4 addresses are supported.
Example
Tunnel Server Endpoint (LNS) IP address is 47.90.123.26 which is

2F.5A.7C.1A in hex.
Tunnel Server Endpoint IP Address [3] = 0x2F,
Tunnel Server Endpoint IP Address [2] = 0x5A,
Tunnel Server Endpoint IP Address[1] = 0x7C,
Tunnel Server Endpoint IP Address [0] = 0x1A.
Length = 0x04
Tag= 0x04
Hence the example string - ‘04042F5A7C1A’ will mean an octet string

of length 4 bytes with the LNS IP address being 47.90.123.26.
Transparent Data VSA

If the Transparent Data VSA is received in RADIUS Authentication
response during the creation of the context, it will be inserted in
management extension in G-CDR and sent to CGF.
The ObjectID field for Transparent Data VSA in G-CDR Management

extension is “1.2.840.113533.4.10.1.6.1”. The data placed into this
field are encoded as an octet string with tag 0x04.
This management extension contains the Transparent Data VSA used

for billing purposes for the context.
Example:

Given the Transparent Data VSA information is TEST-VSA
04 08 54 45 53 54 2d 56 53 41
04 = tag for octet string
54 45 53 54 2d 56 53 41 = TEST-VSA
Table B-19
Transparent Data VSA Information Field Description
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length
3- Transparent Data VSA (up to 247 bytes)

249
The values of these fields in the message format are as follows:
Tag
• 04 = Tag value for octet string

Length
• the length of the information (excluding tag and length bytes)

Transparent Data VSA Octet
• Transparent Data VSA information of 247 bytes

Subscriber Information
IMEISV
IMEISV is optionally recorded as a management extension in G-CDR.
Inclusion of IMESV management extension is configurable per CGF
profile. The ObjectID field for IMEISV in G-CDR Management
extension is “1.2.840.113533.4.10.1.7.1”. IMEISV is a table of BCD
digits and the tag for the management extension is 0x04. IMEISV is
coded in the digits form, as received in the control plane. IMEISV
management extension is included in the first G-CDR for the
session.The format for IMEISV in G-CDR is shown in table Table B-
20.

Table B-20
IMEISV in G-CDR
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length (8)
3 TAC Digit 2 TAC Digit 1

7 SNR Digit 2 SNR Digit 1

10 SVN Digit 2 SVN Digit 1
The information field contains the IMEISV. It is composed of the

following sub-fields: TAC, SNR, and SVN which are BCD encoded.
Example for IMEISV management extension (all values are in hex):
Given an IMEISV of 8070605040302010, the encoded string is- ‘04 08

08 07 06 05 04 03 02 01’
04 = the tag value for octet string
08 = the length of the information is 8 bytes
08 = TAC2, TAC1 digits of IMEISV

04 = SNR2, SNR1 digits of IMEISV
01 = SVN2, SVN1 digits of IMEISV
RAT Type
RAT Type management extension records the RAT Type for all the
containers in the G-CDR. Inclusion of RAT Type management
extension is configurable per CGF profile. The objectId of RAT Type

management extension is “1.2.840.113533.4.10.1.8.1”. It is encoded

as an integer with tag 0x02. The format of RAT Type management
extension is shown in table Table 10, “RAT Type management
extension”.
The values supported for RAT Type are, Unknown (0), UTRAN(1),
GERAN(2), and WLAN(3). GERAN represents GPRS access
technology and UTRAN represents UMTS access technology. If the
RAT Type is not available, RAT Type is set to Unknown.
If the number of containers in the G-CDR is less than the supported

maximum number of containers, RAT Type values are valid only for
those containers. RAT Types for containers not present in the G-CDR
should be ignored.
RAT Type management extension is included in the G-CDR only if

RAT Type is available, either received as RAT Type IE in GTP request
or derived from CellId private extensions (CGI or SAI), for at least one
container in the G-CDR. RAT Type management extension will be
included in all G-CDRs.
A change in RAT Type will trigger G-CDR container closure. The

container closure reason will be “Qos change”.
If the number of containers become equal to the configured number, a

partial G-CDR will be generated.
Table B-21
RAT Type management extension
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x02
2 Length = 1
3 RAT Type for RAT Type for RAT Type for RAT Type for
container #4 container #3 container #2 container #1
The information field encodes RAT Type for the containers in the G-
CDR. Bits 1, 2 encode RAT Type for first container. Bits 3, 4 encode
RAT Type for second container. Bits 5, 6 encode RAT Type for third
container. Bits 7, 8 encode RAT Type for fourth container. The RAT
Type is encoded as follows:

RAT Type Value of two bits in binary

Unknown 00
UTRAN 01
GERAN 10
WLAN 11
Example for RAT Type management extension (all values are in hex):
Given an example string - ‘02 01 25’
02 = the tag value for integer
01 = the length of the information is 1byte
25 = a bit field, encoding the RAT Type for the four containers. 0x25 is
00100101 in binary.
01 = UTRAN = RAT Type for container#1(bits 1, 2)

01 = UTRAN = RAT Type for container#2 (bits 3, 4)
10 = GERAN = RAT Type for container#3 (bits 5, 6)
00 = Unknown = RAT Type for container#4 (bits 7, 8)
PLMN Identifier
PLMN Identifier, either received from SGSN or derived on the GGSN,
is recorded as an optional management extension in G-CDR. Inclusion
of PLMN ID management extension is configurable per CGF profile.
The data in the management extension is a table of PLMN identifiers.
Each change in SGSN results in recording the corresponding PLMN
Identifier, if available. The PLMN identifiers are chronologically
ordered with the most recent as the last PLMN identifier. The ObjectID
field for PLMN Identifier in G-CDR Management extension is
“1.2.840.113533.4.10.1.9.1”. The tag for the management extension is
0x04. PLMN Identifier management extension will be included in all G-
CDRs. The format for PLMN identifiers in G-CDR is shown in Table B-
10.
Table B-22
PLMN in G-CDR
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length (3 * number of PLMN entries)

Octet Bits
s
8 7 6 5 4 3 2 1
3- x MCC2 MCC1
MNC1 MCC3
MNC3 MNC2
x is dependent on the number of PLMN identifiers recorded in G-CDR.

If n is the number of PLMN Identifiers in G-CDR, x would equal 3 + (n *
3) - 1.
Each PLMN identifier consists of MCC and MNC fields, encoded in

BCD. The MCC, MNCsub-fields of the information field are repeated 1
to 4 times within the management extension.
Table B-23
PLMN encoded in BCD
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length (6)
3 0x2 (MCC2) 0x1 (MCC1)
4 0x4 (MNC1) 0x3 (MCC3)
5 0x6 (MNC3) 0x5 (MNC2)
6 0x3 (MCC2) 0x2 (MCC1)
7 0x5 (MNC1) 0x4 (MCC3)
8 0x7 (MNC3) 0x6 (MNC2)
Example for PLMN Identifier management extension (all values are in

hex):
Given an example string of - ‘04 06 2143 65 32 54 76’
21 = MCC2, MCC1 of PLMN Identifier#1

43 = MNC1, MCC3 of PLMN Identifier#1

65 = MNC3, MNC2 of PLMN Identifier#1

32 = MCC2, MCC1 of PLMN Identifier#2
54 = MNC1, MCC3 of PLMN Identifier#2
76 = MNC3, MNC2 of PLMN Identifier#2
This example shows encoding for PLMN management extension with

two PLMN identifiers. The first PLMN identifier is 123/456 and the
second PLMN identifier is 234/567. In the above example, the PLMN
identifier 123/456 is the least recent PLMN identifier.
HSDPA
Nortel Networks GGSN sends the HSDPA values to CGF in the G-
CDR management extensions. When a QoS parameter is sent with
Rel 5 QoS parameters, then the first 12 octets are sent as the
negotiated R99 QoS parameters in G-CDR and only the octets 14 to
16 which include the HSDPA parameters are sent in the G-CDR
management extension. If octet 15 or 16 is received with a value
greater than 0x4A, Nortel Networks GGSN returns a value of 0x4A in
the response. HSDPA parameters are sent to GTP Accounting in
Management Extension with octet tag 0x04 and object id
1.2.840.113533.4.10.1.12.1.
A change in HSDPA triggers G-CDR container closure. The container

closure reason in this case is “QoS change”. If Nortel Networks GGSN
receives only 14 octets, then octet 14 is captured in the GTP
Accounting Management Extension and the octets 15 and 16 are
captured as zeros.
If the number of containers become equal to the configured number, a

partial G-CDR is generated.
If there is a QoS change for the PDP context, old and new HSDPA
related parameters of QoS is captured in the new management
extension with reference to the Container number. Please refer to
Table B-24 for the example of HSDPA management extension.
Table B-24
HSDPA management extension
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length = 1-13

Octet Bits
s
8 7 6 5 4 3 2 1
3 Container Indicator
4-6 HSDPA information Container # 1
7-9 HSDPA information Container #2
Attention: The 3rd octet in the HSDPA Management Extension is

used for indicating the container having HSDPA parameters. The
Least Significant Bit corresponds to the 1st container.
Attention: If the “QoS Change” check-box is unchecked on APN,

QoS container is not closed on QoS change and QoS information
is over-written everytime QoS is updated for a PDP context. This
feature takes the latest HSDPA information from the QoS
Container and stores it in the HSDPA management extension at
the timer of G-CDR generation.
Parking Meter Management Extension Version 1

Parking Meter management extension version 1 is used to report
parking meters in G-CDR. All the parking meters activated since the
previous partial G-CDR are recorded in one Parking Meter
management extension. The ObjectID for the management extension
is 1.2.840.113533.4.10.1.13.1.
Parking Meter management extension version 1 records parking

meters for each QoS container in the G-CDR. For each QoS container,
the number of parking meters and the details of parking meters are
recorded as shown in Table B-25.
Table B-25
Parking Meter Management extension
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length (0x1A)
3 Container ID Number of Parking

Meters for the container

Octet Bits
s
8 7 6 5 4 3 2 1
4-5 Parking Meter Content Type

6-9 Parking Meter Start timestamp
10-11 Parking Meter Duration (in seconds)
Octets 3 to 11 may be repeated when there are multiple containers in

the billing record. Octets 4 to 11 are repeated for each Parking Meter
in the container.The details of each field is as follows:
Container ID: The Container ID field identifies the value of one of the
QoS containers within the G-CDR. Maximum number of Containers
being supported are 4.
Number of Parking Meter for the Container: This field’s value identifies
number of Parking Meters in the container mentioned in container ID
field.
Parking Meter Content Type: This field’s value identifies the Content
Type for the Parking Meter.
Parking Meter Start timestamp: This field identifies the timestamp at

which the Parking Meter is activated. The timestamp value is an
unsigned 32-bit integer representing the number of seconds since
January 1, 1970 UTC, ignoring leap seconds.
Parking Meter Duration: This field’s value identifies the time duration
for the Parking Meter in seconds.The range for this value is between
60 to 3600.
The example string of “04 1A 12 00 64 11 11 11 11 00 60 00 64 11 11

11 96 00 60 21 00 65 11 11 12 30 05 30” is composed as
• 04 - Octet string Tag

• 1A - Length of 26 bytes
• 12 - Container Id 1 and number of parking meters in the container
as 2
• 00 64 - content type (100) for first parking meter in the container
• 11 11 11 11 - start time stamp (286331153) for first parking meter.In
this example, the value is 286331163 seconds after January
1,1970 UTC.
• 00 60 - duration (96 seconds) for the first parking meter

• 00 64 - content type for second parking meter

• 11 11 11 96 - start time stamp for the second parking meter
• 00 60 - duration for second parking meter
• 21 - container id 2 and number of parking meters included as 1
• 00 65 - content type for first parking meter in the container
• 11 11 12 30 - start time stamp(286331440) for the parking meter.In
1,1970 UTC
• 05 30 - duration for parking meter
With the "Maximum number of Closed Envelopes" configurable to the

upper limit of 30, the PM Management Extension Version 1 may not be
able to report all envelopes due to the fact that
• Maximum length for the PM report supported by length field of
extension is 127 bytes.
• The 4 bit wide field ‘Number of Parking Meters for the Container’
limits only 15 PMs to be reported at a time.
To overcome the above limitations, multiple Parking Meter

Management Extensions for Version 1 are triggered when
• Value of Length field exceeds 127 bytes.
• The Number of Parking Meters to be reported for the container
exceeds 15.
Example 1:
Configuration:
CTP and DTP SOC enabled,
DTP configured to be reported at Expiry and
Maximum number of Closed Envelopes is 30.
The container information at the time of a partial G-CDR is:

ContainerID1: 7 expired DTPs,
ContainerID2: 20 expired CTP series,
ContainerID 3: 20 active CTP series.

In this case there will be 4 Parking Meter Extensions:

• 1st PM Extension:
ContainerID 1 with 7 PMs and
ContainerID 2 with 8 PMs (ContainerID 2 is limited to 8 PMs
because of length field ((7 PMs + 8 PMs) * 8 bytes = 120 bytes).
After this no other PM can be accommodated.)
• 2nd PM Extension: ContainerID 2 with 12 PMs and ContainerID
3 with 3 PMs
• 3rd PM Extension: ContainerID 3 with 15 PMs
• 4th PM Extension: ContainerID 3 with 2 PMs
Example 2:
Configuration:
Only DTP SOC enabled,
DTP configured to be reported at Start and
Maximum number of Closed Envelopes is 10.
The container information at the time of a partial G-CDR is:

ContainerID1: 3 DTPs
ContainerID2: 4 DTPs
ContainerID 3: 2 DTPs
In this case there only one Parking Meter Extension is sufficient to
report the above container information.
Parking Meter Management Extension Version 2 is introduced as an

enhancement of version 1 and contains fields as shown in Table B-26.
This Version has an object ID 1.2.840.113533.4.10.1.13.2.
Table B-26
Octets Bits
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length
.... (variable length field continued...)
n (Max Length
129)
n+1 Container ID (1 byte)
n+2 Number of Parking Meters for the container (1 byte)

Octets Bits
8 7 6 5 4 3 2 1
n+3 Parking Meter Content Type (2 bytes)
n+5 Parking Meter Start timestamp (4 bytes)
n+9 Parking Meter Duration (in seconds) (2 bytes)
n + 11 Reserved Envelope Event Downlink Uplink Number of

Closed count byte byte consecutiv
present count count e Parking
present present Meters
present
n + 12 Number of consecutive Parking Meters (optional) (1 byte)
n + 13 Uplink byte count (optional) (4 byte)
n + 17 Downlink byte count (optional) (4 byte)
n + 21 Event count (optional) (4 byte)
Octets (n+3) to (n+21) are repeated for each Parking Meter or CTP
series in the container. Octets (n+1) to(n+21) may be repeated when
there are multiple containers in the billing record.
Length Octets
The length field is encoded in two forms: short (for lengths between 0
and 127), and long (for lengths greater than 127).
Short form: 1 octet. Bit 8 has value "0" and bits 7-1 give the length.
Long form: 2 to 127 octets. Bit 8 of first octet has value "1" and bits 7-1
give the number of additional length octets. Second and following
octets give the length.
Container ID
The Container ID field identifies the value of one of the QoS
containers within the G-CDR. Value of container id is supported in the
range 1-4.
Number of Parking Meters for the Container

This field’s value identifies number of Parking Meters in the container
for DTP Time Event Charging. For CTP Time Event Charging this field
indicates the number of CTP series being reported. The size of this field
is limited to hold a maximum of 255, when the number of envelopes to
be reported exceeds this limit, an additional PM Extension is generated
to include the remaining envelopes.

Parking Meter Content Type

This field’s value identifies the Content Type for the Parking Meter
Parking Meter Start timestamp

This field identifies the timestamp at which the time-envelope is
activated. The timestamp value is an unsigned 32-bit integer
representing the number of seconds since January 1, 1970 UTC,
ignoring leap seconds
Parking Meter Duration

This field’s value identifies the time duration for the Parking Meter in
seconds. For CTP this field’s value identifies the total parking meter
duration for the CTP series and is calculated as Total Parking Meter
Duration = Base Time Interval x Number of consecutive BTIs triggered.
Octet 12 indicates set of optional fields reported for the Parking meter:
• Reserved (3 bits)
The reserved field is not used at present. All 3 bits are set to the
value 0
• Envelope Closed
This bit field is used to indicate the end of a CTP series. For DTP
Time Event Charging this bit is always set
• Event count present
The fourth bit is set if event count is not 0 and is included in the
report for this time-envelope
• Downlink byte count present
The third bit is set if downlink byte count is not 0 and is included
in the report for this time-envelope
• Uplink byte count present
The second bit is set if uplink byte count is not 0 and is included
in the report for this time-envelope
• Number of Consecutive Parking Meters present
The first bit is set if the Number of Consecutive Parking Meters
field is included for a CTP series. For DTP this bit is set to zero.
Number of Consecutive Parking Meters (optional field)

This field’s value identifies the number of consecutive BTIs that are
triggered in the period covered by the G-CDR container. The range for
this value is between 1 to 255. This optional field is not included when
DTP Time Event Charging is selected.
Uplink Byte count (optional field)

This field’s value identifies the number of bytes for the specified Parking
Meter in the uplink (mobile -> GGSN) direction.

Downlink Byte count (optional field)

This field’s value identifies the number of bytes for the specified Parking
Meter in the downlink (GGSN -> mobile) direction.
Event count (optional field)

This field’s value identifies the event count for each Parking Meter.
The PM Management extension version 2 has optional fields are

updated based on APN Configuration as well as the Content Type
Profile configuration. Table B-27 describes the various scenarios in
which the Number of Consecutive PMs, Uplink bytes, Downlink bytes
and Event Count bit fields are updated. In addition a field is not included
if while reporting the actual value of the field is zero.
Table B-27
Updating bit fields of the PM Management Extension Version 2
Content Profile and Bit field values (0=Absent, 1=Present)

APN Configuration
Event count Downlink byte Uplink byte Number of
present count present count present consecutive
Parking Meters
present
DTP Time Event 0 0 0 0

Charging
Report DTP at Start

Charging
Report DTP on
Expiry
Report Time,
Volume and Events:
No

Charging
Report DTP on
Expiry
Report Time,
Volume and Events:
Yes

Content Profile and Bit field values (0=Absent, 1=Present)

APN Configuration
Event count Downlink byte Uplink byte Number of
present count present count present consecutive
Parking Meters
present
CTP Time Event 0 0 0 1

Charging
Report Time,
Volume and Events:
No
CTP Time Event 1 1 1 1

Charging
Report Time,
Volume and Events:
Yes
Multiple Parking Meter Management extensions for Version 2 are

generated when the number of Parking Meters to be reported in a
container exceed 255.
Example: The container information at the time of the final G-CDR is

ContainerID 1: 20 expired PMs
ContainerID 2: 9 expired PMs and 255 active CTP series (at session
deletion).
In the above case there will be 2 Parking Meter Management

extensions generated:
• 1st PM Extension:
ContainerID 1 with 20 PMs;
ContainerID 2 with 9 expired CTP series and 246 CTP series
• 2nd PM Extension:
ContainerID 2 with 9 CTP series.
Reporting using the PM Management Extension
If the PM Management extension version 1 is chosen to be reported in

the G-CDR container then DTP Time Event Charging is reported as in
GGSN5.0. CTP Time Event Charging updates the field ‘Parking Meter
Duration’ to include the total Parking Meter Duration = Base Time
Interval x Number of BTIs.
The example string of “04 2C 12 00 64 11 11 11 11 04 B0 00 14 11 11

11 11 04 D8 21 00 65 11 11 12 30 01 B4” is a report of 3 CTP series

using PM Management extension version 1:

• 2C - Length of 44 bytes
• 01 - Container Id 1
• 02 - Number of parking meters in the container is 2
• 00 64 - content type (100) for the first parking meter in the
container
• 11 11 11 11 - start time stamp (286331153) for the parking meter. In
1,1970 UTC.
• 04 B0 - duration (1200 seconds) for the CTP series
• 00 14 - content type (20) for the second parking meter in the
container
1,1970 UTC.
• 04 D8 - duration (1240 seconds) for the CTP series
• 21 - Container id 2 and number of parking meters included as 1
• 00 65 - content type (101) for first parking meter in this container
• 11 11 12 30 - start time stamp(286331440) for the parking meter. In
1,1970 UTC
• 01 B4 - duration (436 sec) for the CTP series
The example string of “04 2C 12 00 64 11 11 11 11 04 B0 13 20 00 00

00 F0 00 14 11 11 11 11 09 D8 15 21 00 00 00 FF 21 00 65 11 11 12 30
00 B4 12 00 00 00 F0” is a report of 2 CTP series and one DTP using
PM Management extension version 2:
• 2C - Length of 44 bytes
• 01 - Container Id 1
• 02 - Number of parking meters in the container is 2
• 00 64 - content type (100) for the first parking meter in the
container


1,1970 UTC.
• 04 B0 - duration (1200 seconds) for the parking meter
• 13 - Envelope Closed, Number of consecutive Parking Meters and
uplink byte count fields are included (0001 0011)
• 20 - Number of consecutive Parking Meters
• 00 00 00 F0 - 240 for the uplink byte counts
• 00 14 - content type (20) for the second parking meter in the
container
1,1970 UTC.
• 09 D8- duration (2520 seconds) for the CTP series
• 15 - Envelope Closed, Number of consecutive Parking Meters and
downlink byte count fields are included (0001 0101)
• 21 - Number of consecutive Parking Meters
• 00 00 00 FF - 255 for the downlink byte counts
• 02 - Container id 2
• 01 - Number of parking meters included is 1
• 00 65 - content type (101) for first parking meter in this container
• 11 11 12 30 - start time stamp(286331440) for the parking meter. In
1,1970 UTC
• 00 B4 - duration for parking meter (180 sec)
• 12 - Envelope Closed and uplink byte count fields are included
(0001 0010)
• 00 00 00 F0 - 240 for the uplink byte counts
Support of Offline-Charging AVP and PM Time Event Charging
Default Setting
Prior to this feature, the GGSN allowed for postpaid Parking Meter
only in the case where the DCC server indicates that a session
should be postpaid (DCC server returns Credit Control Not
Applicable (CCNA) response in the CCA Initial) and also includes
Parking Meter coupons in the CCA Initial.
This feature adds the capability for a session to use postpaid

Parking Meter billing in cases where communication with a DCC

server is not possible. Additionally, for cases where communication

is possible, support for the Offline-Charging AVP is added.
Specifically, the following functionality is added by this feature:
• the capability to provision parking meter duration within Content

Based Billing policies on a per-coupon ID basis
• support for postpaid parking meter sessions using the parking
meter durations provisioned in the CBB policy
• support for receipt of the Offline-Charging AVP in the CCA Initial
and use the parameters provided in this AVP for postpaid billing
Feature Limitation
Parking Meter provisioning does not apply to contexts interfacing
with CTP prepaid servers and does not apply to PPP contexts.
DCC Events
This management extension reports Diameter CC real-time charging
cause codes in G-CDR record for the following exception cases:
• The GGSN receives a Diameter CC Not Applicable result code

from the Diameter CC server
• The GGSN terminates the subscriber's PDP context due to failure
handling procedures (i.e. Terminate or Retry and Terminate
behavior)
• The GGSN opens a non-prepaid (i.e. postpaid assuming G-CDR
records are generated for the APN) PDP context due to failure
handling procedures (i.e. Continue behavior) following a CCR
Initial
• The GGSN converts the subscriber's PDP context to non-prepaid
due to failure handling procedures (i.e. Continue behavior)
following a CCR Update
• The GGSN terminates the subscriber's PDP context as directed by
the reception of a DIAMETER_AUTHORIZATION_REJECTED
result code from the Diameter CC server (e.g. due to lack of funds)
• The GGSN receives a User Unknown result code from the
Diameter CC server
• The GGSN terminates the subscriber's PDP context as directed by
the reception of an Abort Session Request from the Diameter CC
server
The cause codes to be used for these DCC events in the G-CDR are
as follows:

Table B-28
DCC Event Cause Codes
DCC Event Event

Code
The GGSN receives a Diameter CC Not Applicable result code from the 1
Diameter CC server following a CCR Initial and when RulebaseID AVP is
ABSENTa
The GGSN terminates the subscriber's PDP context due to failure handling 5
procedures (i.e. Terminate or Retry and Terminate behavior)
The GGSN opens a non-prepaid (i.e. postpaid assuming G-CDR records are 6
generated for the APN) PDP context due to failure handling procedures (i.e.
Continue behavior) following a CCR Initial
The GGSN converts the subscriber's PDP context to non-prepaid, such as after 10
receiving a Diameter CC Not Applicable, due to failure handling procedures
(i.e. Continue behavior) following a CCR Update
The GGSN terminates the subscriber's PDP context as directed by the 15

reception of a DIAMETER_AUTHORIZATION_REJECTED result code from
the Diameter CC server (e.g. due to lack of funds)
The GGSN terminates the subscriber's PDP context as directed by the 20

reception of an Abort Session Request from the Diameter CC server
The GGSN receives a User Unknown result code from the Diameter CC server 25
a. If RulebaseID AVP is present, then the new management extension with the
event code will NOT appear in the G-CDR.
Along with the event code, a timestamp of the DCC Event will also be
captured in the G-CDR in a new GGSN Event Diagnostic management
extension, which initially will contain the DCC Event information but
which could also be used for other diagnostic purposes.
The GGSN Event Diagnostic is optionally recorded as a management

extension in the G-CDR. Inclusion of the GGSN Event Diagnostic
management extension is configurable per CGF profile. The ObjectID
field for the GGSN Event Diagnostic in the G-CDR Management
extension is “1.2.840.113533.4.10.1.14.1”. The GGSN Event
Diagnostic consists of the number of events reported, the event code,
and the timestamp. If the number of events is more than one, then
there will be that number of (event code, timestamp) pairs. The tag for
the management extension is 0x04 (octet string). The GGSN Event
Diagnostic management extension is included in the G-CDR after
receiving an applicable DCC cause code and for every G-CDR
afterwards for that session. The format for the GGSN Event Diagnostic
in the G-CDR is shown in table Table B-20.

Table B-29
GGSN Event Diagnostic in G-CDR
Octet Bits
s
8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length (9, 17, 25, 33)

3 Number of Events (1, 2, 3, 4)
4 Event Code
6
7
8 Timestamp
9
10
11
The information field contains the GGSN Event Diagnostic. It is

composed of the following sub-fields: Number of events, Event Code,
and Timestamp. Example for GGSN Event Diagnostic management
extension (all values are in hex):
Given an Event Code of 15, the encoded string might be- ‘04 09 01 00
00 00 0F 42 B1 DE D5’
01 = the number of events is 1
00 00 00 0F = Event Code (in this case, 15)
42 B1 DE D5 = timestamp (in “Unix time”, in this case, 1118953173

seconds since Jan. 1, 1970 GMT, or Thu Jun 16 15:19:33 GMT-06:00
2005, or 050616151933(-0600) in compact UTC format).
The GGSN Event Diagnostic management extension should appear in

the billing record following the event and for all subsequent records for
that session.

This functionality is made optional through SCS provisioning, with the

default as disabled. When disabled, the GGSN Event Diagnostic and
timestamp will not be recorded in the G-CDR. The option appears as a
Include GGSN Event Diagnostic checkbox in the CGF Profile.
ULI Management Extension

A new ASN.1 encoded ULI Management Extension is introduced for
including the CGI/SAI. The ObjectId for the User Location Info in the
G-CDR Management Extension is “1.2.84.113533.4.10.1.10.1”
(1.2.84.113533=Nortel, 4=wireless, 10=GPRS/UMTS, 1=GGSN,
10=ULI, 1=version). The tag for the management extension is 0x04
(Octet tag).
The Management Extension is included in all G-CDRs, if the

corresponding option in the CGF profile is activated (refer to Figure
8-4).
The format of the ULI Management Extension is shown in Table B-30.
Table B-30
ULI Management Extension in G-CDR
Octet Bits
s 8 7 6 5 4 3 2 1
1 Tag = 0x04
2 Length
3 Geographic Location Type = 0 for CGI / = 1 for SAI
4 MCC digit 2 MCC digit 1
5 MNC digit 3 MCC digit 3
6 MNC digit 2 MNC digit 1
7
LAC
8
9
CI / SAC
10
The ULI Management Extension is included, if either an ULI-IE, or a

Private Extension containing the location information has been
received from the SGSN.
Example:
An example string of the ULI in the G-CDR is shown in Figure B-3.

Figure B-3
Example of ULI in G-CDR
CGI: MCC=123
MNC=456
LAC=0011
CI = 0022
04 08 00 21 63 54 00 11 00 22
CI = 0022
LAC = 0011
MNC = 456
MCC = 123
Geo. Loc. Type = CGI
Length
Tag = Octet String
Attention: If the ULI Management Extension is included in the G-

CDR, the PLMN Id Management Extension may also be included
as per existing functionality, although they might have same MCC
and MNC information.
Timestamp format
The Opening and the ChangeOfCharCondition timestamps in the G-
CDR are reported in local time. The contents of these fields are a
compact form of the Universal Time (UTC) format containing local time
(plus an offset to universal time). Binary coded decimal encoding is
employed for the digits to reduce the storage and transmission
overhead.
The format of the timestamp is: YYMMDDhhmmss(Shhmm) where:
YY Year 00 to 99 BCD encoded

MM Month 01 to 12 BCD encoded
DD Day 01 to 31 BCD encoded
hh hour 00 to 23 BCD encoded
mm minute 00 to 59 BCD encoded
ss second 00 to 59 BCD encoded
S Sign 0 = “+”, “-” ASCII encoded
hh hour 00 to 23 BCD encoded
mm minute 00 to 59 BCD encoded

The UTC offset is calculated as defined in ITU-T X.680. Local time

zones west of UTC have a negative sign character, while time zones
east of UTC have a positive sign character. If the local time zone has
not been set or is UTC, the offset will be “+00”. The UTC offset is
automatically adjusted for daylight saving changes as defined for the
configured time zone.
G-CDR Traffic Volume

The GGSN supports GTP version 0 and version 1 volume containers,
the container used depends upon the version of the Create PDP
Context Request message. The G-CDRs may contain multiple Traffic
Data Volume Containers, which are added to the G-CDR under certain
change conditions. This container holds the negotiated QoS, uplink
data volume count and downlink data volume count.
The data volumes counted on the Nortel GGSN cover the amount of
data transferred between the UDP and GTP protocol layers. The data
volumes are required to reflect the application data as precisely as
possible as delivered from/to the subscriber. The following rules apply
to the measurement of uplink & downlink data volumes on Nortel
GGSN:
• The volume counter is incremented when a packet has been

successfully sent by the GGSN towards the Gi interface.
• The volume counter includes the length of the UDP/IP packets, it
does not include the size of the GTP message header.
Billing Disk File
The naming convention of billing disk file indicates the date that the
disk file was created, the active CMC slot number and a file state.
Example: “MDDsssss.IDx”, where:
M = month in Hexadecimal format (1 character); Range: 1 to C

(January = 1, etc., October = A, November = B & December = C),
DD = day of the month (2 characters); Range: 01 to 31
s = Day series character (5 characters) file series for files generated

on the same date; Range: A to Z. First file for a given date has series
characters AAAAA. The G-CDR file names are guaranteed to be
unique from AAAAA to ZZZZZ. The file name sequence allows for
26^5 unique file names in a 24 hour period. The sequence characters
are reset back to AAAAA on each day.
ID = active CMC slot number (2 characters); Range: 13 or 14

x = file state; Range: W = open writing, U = Closed Unprocessed, P =

Processed and Closed, B = Corrupted.
When the file size reaches the operator defined size limit or when the
maximum open-time limit is reached, the file will be closed and a new
one opened. The SCS GUI or the CLI can also be used to manually
close the open G-CDR Billing file by changing the G-CDR file open-
time limit. This command will flush the G-CDR file RAM buffer to local
disk.
The following table describes the format of the G-CDR Billing Disk File
header.
Table B-31
Billing Disk File Header Format
Octet Bits
s
8 7 6 5 4 3 2 1
1-4 Offset
5-8 Encoding (ASN1_BER=1, ASN1_PER=42)
9-12 Total CDRs in File
13-16 CDRs Read from File
17-20 File Size (in octets)
21-24 G-CDR Record Version (V3.2=1, V3.6=7)
All of the fields in the header are signed 32-bit values in big-endian
format (network byte order). The descriptions of the fields are as
follows:
• Offset - This field is used by the GGSN in transferring CDRs stored

on the disk to an active CGF. It contains the offset in bytes from the
end of the header to the first CDR in the file that has not yet been
read in preparation for sending to the CGF. For files in which none
of the records have been sent to a CGF, the value of Offset is zero.
• Encoding - The Encoding field contains information about the
method for encoding the G-CDRs. A value of 1 indicates that
ASN.1 BER encoding was used. A value of 42 (decimal) indicates
PER encoding.
• Total CDRs in File - the total number of CDRs in the file.
• CDRs Read from File - This field is used by the GGSN in
transferring CDRs stored on the disk to an active CGF (see the

Offset field above). It contains the number of CDRs read from the
file for sending to the CGF. For files in which none of the records
have been sent to a CGF, the value of CDRs Read from File is
zero.
• File size - This field indicates the total size of the file in octets,
including the file header.
• G-CDR Record Version - This field indicates the record version as
specified in 32.015 V3.2/3.6. A value of 1 indicates V3.2; a value of
7 indicates V3.6.
Following the header, there are one or more encoded G-CDR records,
each of which is preceded by four octets describing the length of the
encoded record.
Table B-32
Billing Disk File Record Format
Octet Bits
s
8 7 6 5 4 3 2 1
1-4 Length (value = n-4 octets)
5-n Encoded G-CDR Record
The Length field is a signed 32-bit integer in big-endian format

(network byte order) and includes only the length of the Encoded G-
CDR Record itself, excluding the four octets of the Length field.
Storage and Retrieval of G-CDR Files on the Local Disk

CGF Communication Failure
If all the CGF servers for the selected CGF Profile become
unreachable (for example, due to a network failure that isolates the
Nortel GGSN from the CGFs) the G-CDR records will be stored on the
local disk on the Nortel GGSN active CMC card. Each file contains
ASN.1 encoded G-CDRs encoded using the same ASN.1 encoding
standard (BER or PER) as provisioned on the CGF profile. Any G-
CDRs that have been sent to a CGF but remain unacknowledged are
also written to the same disk files.
When connectivity to the CGF nodes is re-established, the files are

processed and the G-CDRs transferred to the CGF along with any
newly created G-CDRs, if the CLI command “gtpbill disksend” is set to
Allow.

When a file has been completely processed (i.e. all the G-CDRs in the
file have been sent to a CGF), the file will be deleted from the Nortel
GGSN local disk.
GTP’ Billing without a CGF Server Configured

For installations that must operate in the absence of a CGF server, the
GGSN can be configured to store all G-CDR records on the local disk
by creating and selecting a CGF Profile with no CGF Server
configurations. The steps below describe how to creates such a profile
from the SCS GUI.
Procedure B-1
Creating a CGF Profile
Step Action
1 Log into the Gn or Ga ISP using the SCS Client GUI
2 From the Access Properties Manager, select CGF Profiles
3 Select the Add button
4 Provide a name in the New Profile window, and select OK. The CGF
Profile General page will appear and the configuration can be changed if
desired
5 Select OK to accept the CGF profile. Figure B-4 will be displayed
Figure B-4
Warning display for the creation of the CGF Profile

Step Action
6 Select Yes to complete the creation of the CGF Profile
7 From the Access Properties Manager, select GTP’ Profiles
8 Select the Add button
9 Click on the Select button next to the CGF field for a list of available CGF
Profiles.
10 Click on the Select button next to the Device field for a list of devices and
select the GGSN on which the CGF Profile will be installed
11 Click OK to complete the configuration
12 Select the CGF Profile that was just created
Selecting a CGF Profile with no provisioned CGF servers directs the

GGSN to store all CDR records on the local disk. Periodically, the
operator should initiate an FTP session to the IP address of the default
ISP and retrieve the completed files (i.e., all files with a ‘U’ as the file
state). Care should be taken that binary transfer mode is selected
when retrieving the files since the CDR files are in binary format. In
this configuration, the GGSN will not delete the CDR files
autonomously, therefore the operator should delete the files to
conserve disk space after successful retrieval.
Manual File Retrieval after a CMC Switchover

There are two scenarios in which Unprocessed G-CDR files need to
be manually transferred from the standby CMC after a CMC
switchover. The first case is when the GGSN is simply configured to
operate without any CGFs as discussed in section B.2.6.2. The other
case is one in which the GGSN was forced to write G-CDRs to disk
because no CGF servers were online, but had not yet had an
opportunity to automatically send the G-CDRs to their destination. In
these cases, it will be necessary to pull the billing files manually as
discussed under “Manual G-CDR File Retrieval”. While following this
procedure, it is important to be sure that the standby’s management IP
address is being used. Because this address moves between CMC
units during a switchover, it will be the same address regardless of
which unit is currently the standby.
RADIUS Protocol
Please refer to Nortel GGSN RADIUS Interface Guide (411-5221-928),
for detailed information regarding RADIUS protocol interface on the

Nortel GGSN. The RADIUS protocol interface is used for RADIUS

authentication and RADIUS accounting,
WRAP Protocol
RFC Attributes
This section specifies the RFC attributes used in the WRAP protocol.
Table B-33
RFC WRAP protocol attributes
Type Attribute Name Description
1 User-Name IP PDU type: User name from PCO
Information Element from Create PDP
Context Request. If Anonymous Mode of
RADIUS Authentication is supported and
PCO is not included, MSISDN is used in
the User-Name parameter send to the
RADIUS Server.
4 NAS-IP Address IP address of the NAS requesting
authentication. (GGSN Gi ISP address)
8 Framed IP Address IP address returned from RADIUS Server
or local address pool or DHCP after
authentication.
25 Class Returned by NAS unmodified in
Accounting-Request. There are up to 4
Class attributes that can be stored on
GGSN and returned to RADIUS Server.
26 Vendor Specific See 3GPP VSA descriptions.
30 Called-Station-ID APN from the Create PDP Context
Request.
31 Calling-Station-ID MSISDN of the mobile subscriber. SCS
Selectable see note 1.
40 Acct-Status-Type START, STOP, INTERIM
44 Acct-Session-ID Unique Accounting ID to make it easy to
match start and stop records. GGSN uses
GGSN Gn IP + Charging ID for this.
46 Acct-Session-Time Indicates how many seconds the user
has received service for. Only present in
INTERIM & STOP messages.
55 Event-Timestamp The timestamp of the event.

3GPP Vendor Specific Attributes

The 3GPP vendor ID is 10415 and all 3GPP attributes are defined
using the vendor specific attribute type 26 described in Table B-34.
Table B-34
3GPP WRAP protocol attributes
Vendor Attribute Name Description
Type
1 3GPP-IMSI The IMSI of the subscriber mobile.
5 3GPP-GPRS-QoS- QoS profile received.
Profile
6 3GPP-SGSN- SGSN IP address that is used by the GTP
Address control plane for the handling of control
messages. It may be used to identify the
PLMN to which the user is attached.
10 3GPP-NSAPI Identify a particular PDP context for the
associated PDN and MSISDN/IMSI from
creation to deletion.
11 3GPP-Session- Indicate the end of the PDP session. A
Stop-Indicator value of 0xFF is passed and it is for
STOP message only.
13 3GPP-Charging- Contains the charging characteristics
Characteristics flags that are set based on the local
provisioning information and/or attributes
received from RADIUS server in Access-
Accept message. Currently used to
Indicate PrePaid and/or Normal Billing
options.
Card Telephony Protocol (CTP)

Card Telephony Protocol (CTP) is a proprietary TCP/IP protocol used
to communicate with an online charging server to provide prepaid
service. Two different versions of CTP are supported to provide two
different variants of prepaid service. CTP version 1 is used to provide
the Basic Single-Coupon service. CTP version 3 is used to provide the
Multi-Coupon service. GeoZone and GPDN Range Checking are
supported for CTP version 1, but not for CTP version 3.
Basic Single-Coupon Prepaid Service

Prepaid service can be used with the CBB feature on the Nortel GGSN
to provide an ability to identify specific content to be counted as free
traffic and not applied against the prepaid balance at the Prepaid
Server. Only volume based billing of Prepaid service is supported for
CBB. It also provides subscriber roaming national and international
location information that can then be used for special rating by the
Prepaid Server.

Location Information
The Nortel UMTS/GPRS network architecture supports roaming for
prepaid subscribers in a transparent way. Using GTP Private
Extension IE, the subscriber can be located and the appropriate tariff
is applied. The parameters describing subscriber’s location are Mobile
Country Code (MCC), Mobile Network Code (MNC), Local Area Code
(LAC) and Cell ID (CI) in the Cell Global ID. When there is no GTP
Nortel Private Extension or these parameters are not present in the
GTP message, the SGSN IP address is included in the Service
Request message and sent to the Prepaid Server. The SGSN IP
address is carried in the LAC and CI fields of the CTP protocol. The
Prepaid Server will map the address to the associated MCC and MNC
thus enabling the Prepaid Server to differentiate billing by originating
network.
The SGSN IP address is always sent to the Prepaid Servers via

CTPv1 for all subscribers if the feature “GPDN Range Checking” is
enabled.
PLMN Identifier (MCC/MNC) is sent to Prepaid Server using version2

of Location IE. If PLMN Identifier is available, it is included in all the
CTPv3 Service requests (Initial, Re-auth and Final messages). If
available, RAT type is sent to prepaid server in all CTPv3 Service
Requests.
Multiple Sessions
When a prepaid data subscriber initiates multiple simultaneous data
sessions, each session is treated separately, i.e. each session
undergoes the authorization and re-authorization process
independently and the cost of each session is debited from the
subscriber’s account independently.
Reauthorization Timer
A re-authorization timer can be configured to force periodic re-
authorization if the authorized volume is not exhausted within the
specified time. The timeout period is specified in the SCS GUI and
defaults to Disabled. This timeout is supported for CTP version 1. CTP
version 3 has similar functionality, but it exists as part of the coupon
definition instead of being specified in the SCS GUI.
Volume Coupon Timeout

A re-authorization timer is supported for volume coupons to force
periodic re-authorization if the authorized volume is not exhausted
within the specified time. The timeout period is specified in the SCS
GUI and defaults to Disabled. This timeout is supported for CTP
version 1.

Multi-Coupon Prepaid Service

The Multi-Coupon Prepaid Service and CTP version 3 build on top of
the Basic Single-Coupon service and CTP version 1. Refer to Nortel
Networks technical specification for more information. The message
flow of CTP protocol is not changed from previous versions. So most
of the CTP content in “Basic Single-Coupon Prepaid Service” still
applies to this version. CTP version 3 adds new IEs to the existing
messages and adds new events that can cause a re-authorization
message to be sent to the Prepaid Server.
If multiple rates are not desired, then the new Non-Rated Coupon IE
can be used to provide an enhanced version of the coupon used in the
Basic Single-Coupon service.
If the coupon is denied because of the following reasons and the

provisioned denied behavior is Block Data, GGSN starts a guard timer.
After guard timer expiry, GGSN initiates re-authorization upon
receiving the first data packet for that rate.
• General error (146)

• Insufficient funds (147)
• Too many coupons in use (148)
• Unknown rate (149)
• Incompatible QoS (150)
If the coupon is denied because of the following reason(s), GGSN
does not attempt to reauthorize the coupon:
• Rate restricted from use(151)

New events are supported that can now trigger actions upon both
rated and non-rated coupons. Each coupon can define triggers that
result in a re-authorization or return of the coupon. The triggers can be
QoS change, SGSN address change, idle coupon timeout, coupon
lifetime and others.
A specific service profile name can be specified by the Prepaid Server

for a subscriber by including the Service Profile Name in the CTP
response message. The profile specified can be merged with other
profiles for the subscriber via policy merging. If an invalid Service
Profile is returned from the Prepaid Server, the PDP session is taken
down. A Service Profile is invalid if it cannot be found within the
Service Policy Manager. If the CBB policy or the service profile
contributing the CBB policy is obtained from the subscriber template,
GGSN sends subscriber template name prefixed with a special
character to the prepaid server. If prepaid server returns the same

name in the response message, GGSN ignores the Service Profile

and allows the PDP context to establish as normal.
The APN Name is included in the version 3 Initial Authorization

Request to provide the Prepaid Server with more complete billing
information. All prepaid time measurements rounded to the nearest
second. The following subsections explain the basic version 3
behavior.
Non-Rated Coupon
CTP version 3 contains a non-rated coupon to take on the function of
single coupon billing. When this coupon is in use, all data packets in
the PDP session are counted against this coupon. Note that prepaid
Coupon ID zero (i.e. rate ID zero) is not a free rate and is reported like
any other rate. If operator wants to support a free rate, then they
should use rated coupons.
If non-rated single coupon prepaid billing is desired, then the Non-

Rated Coupon IE must be returned in the initial authorization response
with non-zero authorized resources. In that case, the PDP context can
never request a coupon for a different rate during that session.
However, it may continue to request resources for that rate by
including a Non-Rated Coupon IE in a re-authorization message. Only
a single Non-Rated Coupon IE can exist in a CTP message. If no
Coupon IE is returned in the initial authorization response, then that
subscriber is assumed to be using rated coupons.
Prepaid resource usage is reported by including a Non-Rated Coupon

IE in each mid-call re-authorization request and final request
message. Usage report contains resources consumed since the last
report and not the resources for the entire PDP session.
For non-rated single coupon, if the coupon is denied, the PDP session
is taken down irrespective of what the Denied Coupon Behavior on the
SCS GUI. Also, the coupon Authorization Behavior is not applied to
non-rated sessions. Coupon Authorization Behavior is specified via
the field Authorization Behavior which is part of CTP version 3 settings
on the SCS GUI. So data packets are always allowed for non-rated
sessions during re-authorization irrespective of the configured
authorization behavior.
Rated Coupon
The Prepaid Server initiates the tariff time change functionality by
authorizing a rated coupon with a trigger subtype IE containing the
tariff time change trigger. The trigger subtype IE has an action of use
tariff change coupon.

During a tariff time change, the usage is preserved within the first
coupon along with the time in which the tariff change occurred. A
second coupon is created to track the usage after the tariff change.
Once the coupons need to be re-authorized or returned, the first
coupon contains the coupon include reason of Return Coupon - usage
before tariff change. The time stamp subtype IE is populated with the
time the tariff change occurred. The usage report subtype IEs contain
the resource usage prior to the tariff change. Immediately following is
the second coupon with the normal coupon include reason indicating
why the coupon is being returned along with the subtype IEs reporting
the usage after the tariff change. Both coupons must contain the same
rate ID.
If the coupon is reauthorized or returned prior to the tariff time change,

then only one coupon is used to report the usage.
A maximum of one tariff boundary may be crossed before reporting the

coupons. If a second tariff boundary is crossed, then the coupons are
reauthorized with a coupon include reason of Re-auth coupon due to
coupon re-auth threshold hit.
A maximum of 40 coupons are allowed per session. Prior to a tariff

change, coupons containing the use tariff change coupon trigger
action are treated as two coupons since after the tariff change, the
Usage before tariff change coupons are treated as separate coupons.
Coupon Include Reason

The Coupon Include Reason is a field in both the Rated and Non-
Rated coupon IEs. In a CTP request message, this field indicates the
reason the coupon is being either re-authorized or returned. In the
response message, this field indicates whether an authorization, re-
authorization or return was successful or denied. Some of the possible
values for this field only make sense for multiple coupons and thus
would not be used in the Non-Rated Coupon IE.
Triggers
Triggers can be included as a sub-IE within either the Rated Coupon
or Non-Rated Coupon IE. Multiple triggers can be included in each
coupon IE. A single trigger consists of a trigger type, a trigger action
and possibly a trigger value. The trigger type specifies which event
triggers the action. The trigger action indicates the GGSN what to do
with the coupon when the trigger event happens. The trigger value
field conditionally stores extra information needed to watch for the
event such as a time value or a threshold value.
Certain trigger scenarios may not result in the corresponding trigger

actions. The trigger scenario is the combination of trigger type, coupon

type and coupon timing. The following table gives the valid trigger
scenarios for the trigger actions being taken. The invalid trigger
scenario will bring down the PDP session.
Table B-35
Valid trigger actions for various trigger scenarios
Trigger Type Coupon Type Coupon Timing Trigger
Action
QoS Change Rated Re-Authorize Valid
Coupon
Return Coupon Invalid
Use tariff change Invalid
coupon
Non-Rated Re-Authorize Valid
Coupon
coupon
SGSN Rated Re-Authorize Valid
Address Coupon
Change Return Coupon Invalid
coupon
Coupon
coupon
Idle Coupon Rated Re-Authorize Invalid
Timeout Coupon
Return Coupon Valid
coupon
Non-Rated Re-Authorize Invalid
Coupon
coupon

Table B-35
Action
Coupon Rated Re-Authorize Valid
Absolute Coupon
Lifetime Return Coupon Valid
coupon
Coupon
coupon
Coupon Rated Re-Authorize Valid
Relative Coupon
Lifetime Return Coupon Valid
coupon
Coupon
coupon
Re- Rated Re-Authorize Valid
Authorization Coupon
Threshold Return Coupon Invalid
coupon
Coupon
coupon
Tariff Time Rated Re-Authorize Invalid
Change Coupon
Use tariff change Valid
coupon
Non-Rated Re-Authorize Invalid
Coupon
coupon

Table B-35
Action
RAT Change Rated Re-Authorize Valid
Coupon
coupon
Coupon
coupon
Transparent Data
The Transparent Data IE contains vendor specific information for the
current session. This IE provides vendor specific information, possibly
obtained via RADIUS, that can be used by the server for billing
purposes. The Transparent Data IE is optional, but can be sent in the
CTP Service Request Initial Authorization, Re-authorization and Final
messages, only if the Transparent Data was received from RADIUS
during the session setup.
Service Profile Name

The role of the Service Profile Name IE has been expanded to include
the service profile name contributing the currently active CBB policy in
the following GPRS service request messages:
• Re-Auth Request
• Final Report
Even though multiple CBB policies may be received, only the service
profile containing the active CBB policy is sent to the Prepaid Server.
If a CBB policy is not available, then the Service Profile Name IE is not
included in the GPRS service request messages.
Time Stamp
The Time Stamp IE contains the coupon reporting or authorization
time. For the GGSN, this timestamp indicates when the authorization
request or coupon report was generated. For the Prepaid Server,
indicates when the coupons was authorized.
If the GGSN requests for coupons and a tariff time change occurs prior
to the response, this timestamp IE is used to determine if the tariff
change should be applied to the received coupons.

Figure B-5
Message Flow with ToD Event
GGSN Prepaid Server
T1 Initial Auth Request

or Re-auth Request
11:59:59
S1 Coupon allocation
ToD Event: time for
S1 = 12:00:00
ToD Time = 12:00:00
S2
T2 S2 = 11:59:59
T3
Initial Auth Response
12:00:00 or Re-auth Response
S1 ToD occurred prior to the Prepaid Server receiving the request.

S2 ToD occurred prior to the GGSN receiving the response.
If the GGSN receives a Timestamp IE containing a time value during

or after the tariff change (S1), then the received coupons are treated
as if a tariff change did not occur.
If the time value is prior to the tariff time change (S2), then the coupons
are treated as if the tariff change has occurred. For initial responses,
the first coupon reports zero usage and the second coupon contains
all the usage. For re-authorization responses, the first coupon reports
the usage between the time the request was sent and the response
was received. The second coupon contains the remaining usage. For
both the initial response and reauthorization scenarios, the timestamp
contains the time the response was received.
Dual Coupons
Nortel GGSN supports “Return Coupon - unused tariff change coupon”
Coupon Include Reason for the GPRS service request message and
two Coupon Include Reason for the GPRS service response,
Successful - Coupon for after tariff change and Denied - Coupon for
after tariff change. These include reasons are only allowed in Rated
Coupon IEs. The Successful - Coupon for after tariff change and
Denied - Coupon for after tariff change include reasons are the only
reasons that the GGSN accepts in the after-coupon

Diameter Credit Control (DCC) protocol

IETF Diameter Credit Control is the first industry standard, online
credit control application and protocol for use in 3GPP packet core
networks. It is the first open standard protocol designed specifically to
be fully integrated with the IP Flow Charging framework (Content
Based Billing) allowing multiple, simultaneous, independent service
quotas to be controlled by the GGSN for a session.
The Diameter Credit Control (DCC) Application has been developed

on the Nortel GGSN to provide a similar set of functionality as the
existing, field proven Nortel proprietary prepaid protocol, CTP.
For additional flexibility in network configuration, the Diameter Credit

Control profiles can be configured to use a different ISP routing
domain than the user traffic. For example, the Diameter servers may
be configured in a separate ISP domain, allowing a clear separation of
Diameter control traffic from the Gi ISP domain traffic. This is termed
“ISP Independence”.
The Diameter Credit Control interface is based on a client-server

configuration using TCP/IP as the transport protocols. This ensures
the reliable, in sequence delivery of charging and control information
between the GGSN and the Diameter Credit Control server.
The Diameter Credit Control server may be incorporated with a

subscriber account management system or it may be connected to a
Prepaid Server.
See Nortel GGSN Diameter Credit Control Technical Specification for

the detailed information of DCC protocol.
Diameter Client-Server Connection Establishment

The following figure describes the message exchange between the
GGSN Diameter Credit Control client and the Diameter Credit Control
server at connection establishment.
Connections may be established when a new or modified Diameter

server is configured in a Diameter Credit Control profile. In addition,
the connection is re-established after either the client or the server
restart/reboot or after a period of transport connection loss.
The Capabilities Exchange Request (CER) is sent by the GGSN in

order to establish a transport connection towards the server. The
GGSN only attempts to open communication with statically configured
servers.

The GGSN advertises the Diameter Credit Control application

identifier (4) to the server. If the server supports this application, and
accepts the connection, it shall respond with a Capabilities Exchange
Answer (CEA) message to the GGSN.
Basic Message Flow for a Diameter Credit Control Session

The following figure describes the basic message flow for a Diameter
Credit Control session showing the interaction of Diameter Credit
Control with existing AAA and post-paid billing protocols and GTP IP
PDP context set-up.
After the Create PDP context is received, the GGSN may perform user
authentication to a RADIUS server as normal. Once the GGSN
receives a positive response from the authentication, the Diameter
Credit Control messaging can begin to authorize the session. The
Initial Credit Control Request (CCR) contains the subscriber
information such as IMSI, MSISDN, IP address and user name when
available. Additionally, the Initial request may contain requests for
service quota if the GGSN Diameter Credit Control profile has been
configured for this.
The Credit Control Answer (CCA) may contain service quota in the
form of Granted-Service-Units (Bytes, seconds, etc.) if the subscriber
account has sufficient funds available and usage has been authorized.
Multiple instances of service quota may be present, each to be used
for a particular traffic or service type as tracked by the GGSN.
At this point, RADIUS Accounting may be started for the same

session.
At some point in the subscriber’s session, the Granted-Resource-Units

may be exhausted. In this situation, the GGSN will send an Update
CCR message to the Diameter Credit Control server. The CCR
contains the reported usage and a request for new allocation of quota
for the service. In the example below, the server returns a new
allocation to the GGSN.
At the end of the subscriber’s session, the GGSN sends a Final CCR
to the Diameter Credit Control server to report the amount of the quota
allocation that has been used. At the same time the RADIUS STOP
message is also sent to the RADIUS Accounting server and a G-CDR
is generated if GTP’ accounting is enabled.
Diameter Credit Control Session Flow with Service Redirect

The following figure describes the basic message flow for a Diameter
Credit Control session where the credit control server has instructed

the GGSN to redirect the user traffic to a top-up or Advice of Charge

site. For example, when the subscriber attempts to use a service, the
GGSN requests resource quota allocation from the Diameter Credit
Control server. In the case where the subscriber has insufficient funds,
the server may return the URL of a top-up server instead of quota
allocation.
The GGSN then redirects any subscriber traffic for the service being
redirected towards the URL provided by the server. At this point the
subscriber may top-up the account. This prompts the Diameter server
to issue a Re-Authorize Request to the GGSN for that session. This
instructs the GGSN to request new quota for the session, which in the
example below, allows the subscriber to use the service.
Parking Meter Charging Model

Parking Meter model works on per rating group basis. When first
packet for a rating group that utilizes Parking Meter model is received
by the Nortel Networks GGSN, a parking meter is started for the rating
group. While a parking meter is active for a rating group, all volume
and event usage for the rating group is accounted against the active
parking meter.
Parking Meter model is supported for prepaid sessions controlled by

Diameter Credit Control (DCC) server. DCC Server identifies a rating
group to utilize Parking Meter model by including Time-Quota-
Mechanism (TQM) in Multi-Service-Credit-Control (MSCC) AVP for the
rating group. TQM AVP contains Parking Meter duration in units of
seconds and the range supported is between 60 and 3600.
The Parking Meter Model supports postpaid services when the DCC
Server returns a Credit Control Not Applicable (CCNA) response in the
Credit Control Answer (CCA) initial at context set-up. The DCC Server
identifies rating groups for which the Parking Meter model is to be
applied by including a MSCC AVP with the TQM AVP for each such
rating group. The TQM AVP defines Parking Meter duration for that
rating group. The GGSN supports receiving MSCC AVPs in the CCA-I
message level or within the Offline-Charging AVP of the CCA-I. The
attributes received in the MSCC level within the Offline-Charging AVP
override the attributes received in the MSCC level within the CCA-I
message level. If one or more MSCC AVPs are received in the Offline-
Charging AVP, all MSCC AVPs in the CCA-I message level are
ignored.
The GGSN can also receive the TQM AVP in the Offline-Charging
AVP. This TQM is used as default if the TQM AVP is not specified in
the MSCC AVP.

The GGSN supports reception of a maximum of 40 MSCC AVPs in

CCNA CCA(I).
The GGSN supports the capability for a session to use postpaid

Parking Meter billing in cases where communication with a DCC
server is not possible. This is achieved using configuration on the
GGSN. Please refer to Coupon Profile.
Feature Limitation
Parking Meter provisioning does not apply to contexts interfacing with
CTP prepaid servers and does not apply to PPP contexts.
Diameter Credit Control Failure Handling

The DCC client may fail to send a request to the DCC server because
it is unable to communicate with the desired destination. This could be
due to the peer being down, or due to the peer sending back a
transient failure or temporary protocol error notification
DIAMETER_TOO_BUSY, DIAMETER_UNABLE_TO_DELIVER, or
DIAMETER_LOOP_DETECTED in the Result-Code AVP of the
answer message.
A timer value Tw which detects the transport layer failure and a user
response timer Tx which provides real-time response for subscriber’s
credit control requests are defined. In addition, a request timeout timer
Tr is defined. If a credit control request issued by the DCC client has
not been answered for the duration of Tr, the request is no longer
considered valid.
Failure Handling DCC AVPs

DCC uses information provided by the CC-Session-Failover (CCSF)
AVP and Credit-Control-Failure-Handling (CCFH) AVP to determine its
failure handling behavior on a specific DCC session.
Either FAILOVER_NOT_SUPPORTED or FAILOVER_SUPPORTED

are allowed to be configured via SCS in the CCSF field. This value will
be used as the default in the absence of CCSF AVP in the DCC
answer message from the DCC server.
Three options of CCFH AVP: TERMINATE, CONTINUE, and

RETRY_AND_TERMINATE are supported. It can also be provisioned
via SCS to be the default value in the absence of CCFH AVP in the
DCC answer message.
The DCC server can sends either or both CC-Session-Failover and

Credit-Control-Failure-Handling AVPs in CCA messages to the DCC
client to control the failover handling behavior of the client. In the
absence of such AVPs, the failure handling of the client is determined

by the default setting provisioned via SCS. If any of these AVPs is

received from DCC server, its value always overwrites the SCS
provisioned value.
Failure Handling Procedure

Conceptually, the failure handling of a DCC request during its lifetime
can be divided into three stages.
First, the expiration of the Tx timer triggers the failure handling process
for a DCC request. This timer expires because the answer for the
request did not come soon enough. The underlying network may or
may not have problem. The requested message could be late because
of busy network. However, DCC client needs to respond to the end
user quickly because of the real-time nature of credit control process.
After Tx expires, if CCFH setting is TERMINATE, the DCC client will
terminate the PDP context associated with the current DCC session. If
CCFH is not TERMINATE, the DCC client will continue to allow the
subscriber to use the current service without a renewed coupon.
The request failure handling enters the second stage when Tw

expires. This signals the transport layer failure. When this happens,
the DCC client determines whether to try an alternative DCC server
according to CCSF setting, and subsequent behavior according to
CCFH setting.
In most cases, both Tx and Tw will expire in a failure situation.

However, it is possible that no answer is received for a request and Tw
never expires. For example, the connection between the DCC client
and its immediate peer is fine, and therefore Tw never expires.
However, the request message is lost beyond the immediate peer, and
the reply message takes a very long time to return to the client or even
never returns. In this case, the time Tr is used to set a maximum
lifetime for the request. If the life span of a pending request is longer
than Tr, the DCC client will consider that the answer will never come
back, and will handle the DCC session according to setting of CCFH.
In reality, the distinction between these stages may not be very clear.
For example, since Tw applies to the DCC client and its peer, while Tx
applies to individual DCC request, it is possible that Tw expires before
a particular Tx expires. If this happens, the DCC client will handle the
situation as specified by the CCFH setting.

Table B-36
Session Failure Handling
Event Failover CCFH Action

Supported
Tx expires Yes/No TERMINATE Terminate the PDP context
CONTINUE Grant service to current rating

group
RETRY_AND_TERMINATE
Tw expires No TERMINATE Not applicable if Tx expires earlier
Terminate the PDP context if Tw

expires first and the PDP context
still exists
CONTINUE Grant unlimited resources to the

PDP context session (the Prepaid
DCC session becomes a Postpaid
session)
RETRY_AND_TERMINATE Terminate the PDP context
Yes TERMINATE Retry the request on alternative

DCC server
CONTINUE
RETRY_AND_TERMINATE
Tr expires Yes/No TERMINATE Terminate the PDP context
RETRY_AND_TERMINATE
CONTINUE Grant unlimited resources to the

PDP context session (the Prepaid
DCC session becomes a Postpaid
session)
Any late reply will be ignored
Attention: In the table, failover is not supported if either CC-

Session-Failover is set to FAILOVER_NOT_SUPPORTED or an
alternative server is not available.
The CCFH setting is also used to handle certain situation when the
received reply message contains error result code. The result can be
either Permanent Failure or Temporary Failure, as defined by
Diameter Base document. The handling processes are listed in the
following table.

Table B-37
Roared Reply Handling
Return Result Failover CCFH Action

Code Supported
Temporary Failures Yes TERMINATE Send the request to
alternative DCC server
CONTINUE
RETRY_AND_TERMINATE
No TERMINATE Terminate the PDP context
RETRY_AND_TERMINATE
CONTINUE Grant unlimited resources to

the PDP context session (the
Prepaid DCC session
becomes a Postpaid
session)
Permanent Failures Yes/No TERMINATE Terminate the PDP context
(except for RETRY_AND_TERMINATE

USER_UNKNOWN)
CONTINUE Grant unlimited resources to
the PDP context session (the
Prepaid DCC session
becomes a Postpaid
session)
USER_UNKNOWN Yes/No TERMINATE Terminate the PDP context
CONTINUE
RETRY_AND_TERMINATE
When a DCC client fails to receive any answer from a DCC server, the
DCC client also check the agent type of next available DCC peer to
determine if a failover should be initiated. If the next available DCC
peer is a DCC proxy or a relay, a failover is initiated regardless of the
setting of CC-Session-Failover, as show in table below. The
destination host in the new update CCR message in this case will
remain to be the same as the failed CCR message. Such handling can
reduces number of request failures caused by bad connection to the
immediate DCC peer.
When the Tx timer expires on CCR(I) and the CCFH is continue then
the call is converted to postpaid otherwise it is Terminated.

When the Tx timer expires on CCR(F) the request time out timer is
started and the call waits for a possible late response or a failure over
condition is detected then the request is retransmitted. If no response
comes back and the Request Timeout timer times out. Then all
resources are cleaned.
Table B-38
DCC Agent Type and DCC Failover
Agent Type Agent Type of CC-Session-Failover Failover

of Current Next DCC Peer
DCC Peer
Server Server FAILOVER_SUPPORTED Yes
FAILOVER_NOT_SUPPORTED No
Server Proxy/Relay FAILOVER_SUPPORTED Yes
FAILOVER_NOT_SUPPORTED Yes
Proxy/Relay Server FAILOVER_SUPPORTED Yes
FAILOVER_NOT_SUPPORTED No
Proxy/Relay Proxy/Relay FAILOVER_SUPPORTED Yes

FAILOVER_NOT_SUPPORTED Yes
Diameter Tx Expiry Event

The Diameter Tx Timer defines the maximum time to wait for a
response to each Request from the Diameter Server. For a
provisioned interval of T seconds and threshold values of N1 (MAJOR
threshold) and N2 (CRITICAL threshold), a MAJOR event will be
raised if the Tx Expiry counts exceed N1 during the T seconds of any
given interval. If the Tx Expiry counts exceed N2 during the T second
interval, a CRITICAL event will instead be raised.
When the interval is configured, a timer starts at that point. The SNMP
trap can only occur at the end of the interval. At that time, the number
of Tx Expirations that occurred during that interval is compared to the
configured thresholds. If the number is greater than or equal to the
Major threshold, but less than the Critical threshold, then a Major
event is raised. If the count is greater than the Critical threshold, then a
Critical event is raised. The internal timer and counter used for this
calculation are then reset. Note that since the calculation is only made
at the end of the interval, any changes to the configured threshold
values during an interval will be in effect at the end of that interval,
However, a change to the interval value itself will result in restarting
the timer and resetting the counter.

Charging Upon Conversion to a Postpaid Session

Upon conversion of a context as a Postpaid session due to an Update
CCR failure, a RADIUS accounting record and a partial G-CDR are
generated with the latest usage counts based on the provisioning for
the APN. If neither RADIUS accounting nor the GTP’ billing is enabled
for the APN, no billing records are generated for the session. The open
traffic volume container in the G-CDR is closed with the container
closure reason “Record Closure” and the partial G-CDR is generated
with the closure reason “Management Intervention”. The Charging
Characteristics for these records are marked as prepaid.
The reauthorization timeout may result in reporting some usage

counts as prepaid in G-CDR and RADIUS accounting records while
the same may not have been successfully reported to DCC server.
After conversion of a context as a Postpaid session, either during

context establishment or during reauthorization, the Charging
Characteristics in G-CDRs and RADIUS accounting records is marked
as prepaid if
• “Set Prepaid CC” is marked for the set of rules, for the IMSI profile
associated with the APN, that matches IMSI of the subscriber
• Charging Characteristics supplied by the SGSN is marked as
prepaid
IPSec Support
The IPSec feature is enabled. Its configuration is described below.
IPSec is implemented using statically configured pre-shared IKE key

between the GGSN and the Diameter peer. Each end of the tunnel will
have the same security parameters and IKE key. All Diameter traffic
between the GGSN and the Diameter Peer will use the IPSec tunnel
established. The IPSec tunnel, however, is between the GGSN and
the first Diameter Peer.

Figure B-6
IPSec Tunnels in Diameter Network
GGSN Diameter
Server
Diameter
Proxy
GGSN Configured
IPSec Tunnels IPSec Tunnels not
Configured by GGSN
Diameter
Relay
Any data that the GGSN receives from the Diameter Peer must be IKE
traffic (for tunnel configuration and keep-alive) or IPSec traffic (the
actual data). Any data that is not IKE or IPSec will be silently discarded
by the GGSN using the configured ISP security policy. Any IPSec data
that the GGSN receives that it cannot authenticate using existing
IPSec Security Associations will be silently discarded as well. The
Diameter or DCC applications will not have any knowledge of these
packets as they will be dropped at the IPSec layer.
The GGSN IKE and IPSec implementation now contains a keep-alive

mechanism so that one tunnel end-point can determine if its peer has
gone down, been rebooted, etc. If the GGSN detects that the other
end of the tunnel has gone down, IKE and IPSec will be renegotiated.
This renegotiation will prevent stale tunnels where neither side can
authenticate the data.
All IPSec related information can be provisioned via the SCS.
Dynamic Coupon Control

Dynamic coupon behavior configured by DCC server via AVPs are
supported. All such AVPs are discussed in this section.

Triggers
GGSN uses triggers to initiate re-authorization when certain system
information is changed. For example, when an SGSN trigger is
enabled, GGSN generates a re-auth request when SGSN changes.
Similarly, triggers can be configured for QoS change, RAT change,
etc.
Provisioning of default trigger behavior in Diameter profile via SCS is

supported. All coupons using the same Diameter profile share the
same trigger setting.
Triggers configured by DCC server via trigger AVPs are supported.

The DCC server may include zero or more trigger type AVPs in the
Multiple-Service-Credit-Control (MSCC) AVP of a Credit Control
Answer (CCA) message to enable triggers on a specific rating group.
If the initial CCA to a PDP context does not include any trigger AVPs,
the default trigger setting will be used for all coupons included in the
CCA. The default setting remains effective until a trigger AVP is
received.
When at least one trigger AVP is received in the initial CCA or any
update CCA, the triggers with types corresponding to the received
trigger AVPs will be enabled. All other triggers will be disabled. If no
trigger AVPs are received in an update CCA, all trigger settings on the
current coupon will be the same as in the previous coupon of the same
rating group.
The trigger AVPs modify behavior of credit control coupons on a per

coupon base. Different coupons within a same PDP context can
respond differently to the same trigger event. Coupons for the same
rate at different times can also respond differently to the same trigger
event.
If a re-authorization is initiated as result of a trigger event, the Credit

Control Request (CCR) message will include a trigger AVP identifying
the trigger which causes the re-authorization.
SGSN change trigger, QoS change trigger, and RAT change trigger
are supported.
Quota Threshold
Quota threshold allows a coupon be re-authorized before the quota is
exhausted.
Provisioned quota threshold in the Diameter profile from SCS is

supported, and the quota threshold is given as percentage of the

quota, regardless if the quota type is time or volume. All DCC sessions
using the same Diameter profile have the same quota threshold
setting for all coupons on all of the sessions.
Dynamically configured quota threshold on individual coupons are

allowed. The configuration is done by the DCC server via quota
threshold AVPs. In addition, the quota threshold can be given either as
a percentage of the quota (as provisioned from SCS) or an absolute
value (as provisioned from SCS or specified in AVPs received from the
DCC server).
To configure quota threshold of a coupon, the DCC server can include

either or both of time quota threshold AVP and volume quota threshold
AVP within a Multiple-Service-Credit-Control (MSCC) AVP.
Both AVPs contains absolute value of quota threshold. The time quota
threshold AVP contains threshold for time based quota in seconds.
The volume quota threshold AVP contains threshold for volume based
quota in number of bytes.
A zero valued quota threshold AVP disables the quota threshold for
that quota type. The threshold values contained in quota threshold
AVPs cannot be larger than the corresponding quota values. If the
threshold value is larger than the quota value, it is set to zero, i.e.
quota threshold is disabled.
The default quota threshold value can be provisioned separately for

time and volume, from SCS as either a percentage or an absolute
value. When it is configured as percentage, its value must be in the
range of 50% and 100%. When it is configured as absolute value, it
follows the same rule as in the AVP case described in the previous
paragraph.
Together, the quota threshold AVPs and the provisioned quota

threshold in Diameter profile determines when an re-authorization can
happen for a particular coupon. The following table lists such
behaviors.

Table B-39
Effect of Default Quota Threshold Trigger
Default Quota Quota Threshold AVP

Threshold Trigger Included in CCA Event
Enabled Yes Re-auth occurs when a non-zero
threshold specified in AVP is
crossed
No threshold if the AVP contains a

zero value
No Re-auth occurs when threshold

specified in the Diameter profile is
crossed
Disabled Yes Re-auth occurs when a non-zero

threshold specified in AVP is
crossed
No threshold if the AVP contains a

zero value
No Re-auth occurs when quota is

exhausted
When a quota threshold AVP is received by the DCC client, the

threshold with a type different from the quota type will be ignored. For
example, a time quota threshold AVP received with a volume quota will
be ignored.
When a quota threshold AVP is received by the DCC client, all

provisioned quota threshold values will be ignored. For example, if
both time and volume thresholds are provisioned, and only a time
quota threshold AVP is received, the provisioned volume threshold will
have no effect.
Both time quota threshold AVP and volume quota threshold AVP can
be included within a single MSCC AVP. In that case, only the threshold
with the same type as the quota type will be used. If the MSCC also
contain two quota type, i.e. both time and volume quota, both
threshold values will be sent to GTP backend for prepaid checking.
Whichever threshold being crossed first will trigger a re-authorization
on that coupon.

Quota Idle Time

The quota idle time specifies how long a coupon can stay idle before
an re-auth is needed. It can be provisioned via the Diameter profile
from SCS.
The DCC server is allowed to configure the quota idle time on a

particular coupon by including a quota idle time AVP in the MSCC AVP.
The AVP contains the quota idle time in seconds. A value of 0 in the
AVP data field disables the quota idle timer for the coupon.
When a DCC session is setup, all coupons in the session shall have
the same quota idle time as that provisioned in the Diameter profile
until a quota idle time AVP is received for the rating group.
If a quota idle time AVP is included in the received MSCC, either in the
initial CCA or the update CCA, the quota idle time of the coupon will be
set according to the value contained in the quota idle time AVP, i.e.
zero to disable and non-zero to enable.
If the quota idle time AVP is not included in the received MSCC AVP,
the quota idle time of the coupon will be the same as the previous
coupon of the same rating group.
The quota idle time applies to both time based and volume based
quota.
When quota idle time AVP is received by the DCC client together with
quota inactivity time (see later section), the quota idle time value must
be larger than or equal to that for quota inactivity time. If received
quota idle time is less than quota inactivity time, the setting of both
quota idle time and quota inactivity time from the previous coupon of
the same rating group will be used.
Quota Consumption Time (QCT) Inactivity Time

The quota inactivity timer changes how a time based quota is
consumed. Without this timer, the time based quota will be counted
continuously from the moment the coupon is received by GGSN until it
is completely consumed. If the quota inactivity timer is enabled, the
timer starts when user traffic stops, and the GGSN stops quota usage
counting when the timer expires. The timer also stops if user traffic is
detected before the timer expires. When operating in this mode, the
time based quota is not consumed in real time, but by envelopes of
actual usage time.
The quota inactivity time can be provisioned via Diameter profile from
SCS.

The DCC server is allowed to configure the quota inactivity time on a

particular coupon by including a quota inactivity time AVP in the MSCC
AVP that contains the coupon. The AVP contains quota inactivity time
in seconds. A value of 0 in the AVP data field disable the quota
inactivity timer and returns the coupon consumption back to real time
mode.
When a DCC session is setup, all coupons in the session shall have
the same quota inactivity time as that provisioned in the Diameter
profile until a quota inactivity time AVP is received for the rating group.
If a quota inactivity time AVP is included in the received MSCC, either

in the initial CCA or the update CCA, the quota inactivity time of the
coupon will be set according to the value contained in the quota
inactivity time AVP, i.e. zero to disable and non-zero to enable.
If the quota inactivity time AVP is not included in the received MSCC
AVP, the quota inactivity time of the coupon will be the same as the
previous coupon of the same rating group.
The quota inactivity time AVP is only valid when the quota is time
based. If a quota inactivity time AVP is included in a MSCC AVP that
contains only a volume based quota, the AVP is ignored.
If a quota inactivity time AVP is received by the DCC client together

with quota idle time AVP, the quota idle time value must be larger than
that for quota inactivity time. If the received quota idle time is less than
the quota inactivity time, the setting of both quota idle time and quota
inactivity time in the previous coupon of the same rating group will be
used.
The GGSN provides the optionality to exclude the QCT Time from the
reported usage for prepaid PDP contexts. If the option is set to exclude
QCT Time, the following is the time usage reporting behaviour:
• Not including the QCT Time period if the Idle Time between two
consecutive packets is equal to or greater than the QCT Time.
• Not including any of the Idle Time between the last packet and a
final usage reporting.
Validity Time
Validity time of a coupon determines the relative life-time of the
coupon. If the quota contained in the coupon has not been consumed
within the validity time specified in this AVP, the GGSN will initiate a re-
authorization for the coupon.

Validity timer is supported. A coupon will have a life-time as specified

by a standard DCC Validity-Time AVP that is included in the CCA
message from the DCC server.
Validity time can be configured only via the validity time AVP, i.e. no
default value can be provisioned via SCS.
Tariff Change
The tariff change mechanism allows the credit control system to apply
different charging rate before and after a specific time, i.e. tariff change
time. To achieve this in a DCC system, the DCC client needs to report
separately the resource usage before and after the tariff change time.
The existing Time-of-Day (ToD) feature is used to provide the tariff

change support. The ToD feature allows tariff change to occur at the
top of the hours. A DCC session can adopt the ToD process by being
associated with a ToD profile. The ToD profile contains one or more
hours when the tariff will change. Once passed the tariff change hour,
the next credit control request issued by a coupon will contain two
portions of resource usage: before and after the hour.
The ToD feature can be activated via SCS by assigning the ToD profile
with an APN. All DCC sessions using the same APN will have the
same ToD setting.
A tariff change may occur for a specific coupon at any time given by a
Tariff-Change-Time AVP that is included in Granted-Service-Unit
(GSU) AVP by the DCC server.
The Tariff-Time-Change AVP (AVP code 451) is defined by the DCC

draft. If the coupon lifetime spans across the tariff change time, the
next CCR issued by the coupon will contain two Used-Service-Unit
AVP in the Multiple-Service-Credit-Control AVP for the coupon. The
Used-Service-Unit AVP will also contain a Tariff-Change-Usage AVP
that specifies whether the usage reported in the Used-Service-Unit
occurred before or after the tariff change time.
If a Tariff-Time-Change AVP is not included in CCA and a ToD profile is

associated with the DCC session, the ToD profile defines the tariff
change behavior (see the following table).

Table B-40
Tariff Change and ToD
ToD Configured Tariff Change AVP Tariff Change Schedule

Included in CCA
Yes Yes Tariff change occurs according to

schedule specified in the Tariff-
Time-Change AVP
Yes No Tariff change occurs according to

schedule specified in the ToD
profile
No Yes Tariff change occurs according to

schedule specified in the Tariff-
Time-Change AVP
No No No tariff change will happen

Dual Coupon
Nortel GGSN supports decoding of the Diameter Tariff-Change-Usage

AVP. The Tariff-Change-Usage AVP (AVP Code 452) is of type
Enumerated and defines whether units are to be used before or after a
tariff change event. When the Tariff-Time-Change AVP is present,
omission of this AVP in answer messages means that the single quota
mechanism applies.
If the Tariff-Change-Usage AVP is included in two allocations, but the

Tariff-Time-Change AVP is not included, the dual coupon
implementation is used with the ToD profile.
Inclusion of a Tariff-Time-Change AVP in an MSCC with a Tariff-

Change-Usage AVP containing UNIT_AFTER_TARIFF_CHANGE is
not supported and is treated as a protocol error.
Within an Answer message, Tariff-Change-Usage AVP is present in the

MSCC and can contain the values shown below.
Table B-41
Tariff-Change-Usage AVP Values in MSCC
Name Value Comment
UNIT_BEFORE_TARIFF_CHANG 0 the units allocated

E in the MSCC are
for use before a
tariff change
occurs
UNIT_AFTER_TARIFF_CHANGE 1 the units allocated
in the MSCC are
for use after a tariff
change occurs
Envelope Reporting
Nortel GGSN supports reporting usage of Parking Meter and QCT in

Envelopes to the DCC server. The Envelope Reporting AVP (AVP code
272) of type Enumerated, specifies whether to report usage in
Envelopes and whether to report the Envelopes with or without volume
to the DCC Server. The GGSN supports receiving of the Envelope-
Reporting AVP in the CCA Initial message level and in the MSCC AVP
for the initial allocation of a coupon. The one in the MSCC AVP takes
precedence over the one in the CCA(I). The GGSN may also be
configured with an Envelope-Reporting default on a per-rate basis
through the Coupon/Content profile.

The following values are supported:

• DO_NOT_REPORT_ENVELOPES
• REPORT_ENVELOPES
• REPORT_ENVELOPES_WITH_VOLUME_AND_EVENTS
The envelopes are encoded on the Envelope-Reporting value. The

Usage will not be reported in envelopes for the following cases:
• If the AVP is not received
• If the AVP received is DO_NOT_REPORT_ENVELOPES.
• If the default configuration in the coupon/content profile is
DO_NOT_REPORT_ENVELOPES
Table B-42
AVPs Included in Envelope AVP
AVP Included if Envelope- Included if Envelope-

Reporting = Reporting =
REPORT_ENVELOPES ...WITH_VOLUME
Envelope-Start- yes yes
Time
Envelope-End-Time included if Envelope is included if Envelope is

closed closed
CC-Total-Octets no yes
CC-Input-Octets no yes
CC-Output-Octets no yes
CC-Service- no yes
Specific-Units


C-1
List of terms C
AF
Assured forwarding
APN
Access Point Name
APS
Automatic Protection Switching
ARP
Address Resolution Protocol
ASM
Active Session Management
BG
Border Gateway
BSN
Broadband Service Node
CBB
CCFH
Credit Control Failure Handling
CCA
Credit Control Answer
CCR
Credit Control Request
CGF
Charging Gateway Function

C-2 List of terms
CGI
Cell Global Identification
CHAP
Challenge Handshake Authentication Protocol
CLI
Command Line Interface
CMC
Control and Management Card
Cold Standby
A redundancy feature where configuration information is available in the
StandBy unit, but the active session information is only in the active unit.
When a fault is encountered, the standby unit will take over all activities to
support setting up new sessions. All active sessions go down as the “active”
unit goes down.
CORBA
Common Object Request Broker Architecture
CSV
Comma Separated Values
CTP
Card Telephony Protocol
CTP
DCC
Diameter Credit Control
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name Service
DTP
DTI
Direct Tunnel Indicator

List of terms C-3
DTF
Direct Tunnel Flags
DSCP
DiffServ Code Point
ECMP
Equal Cost Multi-Path
EI
Error Indication
FTP
File Transfer Protocol
G-CDR
GGSN Call Detail Record
GCSI
GPRS CAMEL Subscription Information
GERAN
GPRS EDGE Radio Access Network
GGSN
Gateway GPRS Support Node
GPRS
General Packet Radio Service
GRE
Generic Routing Encapsulation
GSM
Global System for Mobile communications
GSN
GPRS Support Node
GTP
GPRS Tunneling Protocol
GTP-C
GTP Control - This protocol tunnels signalling messages between SGSNs
and GGSNs, and SGSNs, in the backbone network.

C-4 List of terms
GTP-U
GTP User - This protocol tunnels user data between GPRS Support Nodes
in the backbone network. All PDP PDUs are encapsulated by the GPRS
Tunneling Protocol.
HLR
Home Location Register
Hot Standby
A redundancy feature where dynamic data is stored for all current “stable”
active sessions. Sessions that are “unstable” (i.e. currently being created,
etc.) do not survive.
HPLMN
Home Public Land Mobile Network
HTTP
Hypertext Transfer Protocol
IMAP4
Internet Message Access Protocol - Version 4rel1
IMEI-SV
International Mobile Equipment Identity - Software Version
IMSI
International Mobile Subscriber Identity
IP
Internet Protocol
IPCP
IP Control Protocol
IPSec
IP Security Protocol
IRI
Interception Related Information
ISP
Internet Service Provider
L2TP
Layer 2 Tunneling Protocol

List of terms C-5
LAC
L2TP Access Concentrator
LAC
Location Area Code
LCP
Link Control Protocol
LDAP
Lightweight Directory Access Protocol
LNS
L2TP Network Server
MCC
Mobile Country Code
ME
Mobile Equipment
MMS
Multimedia Messaging Service
MNC
Mobile Network Code
MS
Mobile Station
MSS
Maximum Segment Size
NBNS
NetBIOS Name Server
NCP
Network Control Protocol
NNDCC
Nortel Networks Diameter Credit Control
NSAPI
Network Service Access Point Identifier

C-6 List of terms
OSS
Operations Support System
PAP
Password Authentication Protocol
PCO
Protocol Configuration Options
PDN
Packet Data Network
PDP
Packet Data Protocol
PDU
Protocol Data Unit
PLMN
Public Land Mobile Network
PNP
Personal Network Portal
POP3
Post Office Protocol Version 3
PPP
Point-to-Point Protocol
QoS
Quality of Service
RAC
Routing Area Code
RADIUS
Remote Authentication Dial In User Service
RAT
Radio Access Technology
SAI
Service Area Identifier

List of terms C-7
SCP
Service Control Point
SCS
Service Creation System
SFC
Switch Fabric Card
SGSN
Serving GPRS Support Node
SER 5500 GGSN

Services Edge Router 5500 with GGSN functionality
SMP
Shasta Management Protocol
SMTP
Simple Mail Transfer Protocol
SNMP
Simple Network Management Protocol
SNR
Serial Number
SNTP
Simple Network Time Protocol
SSC
Subscriber Service Card
SSG
Subscriber Service Gateway
SSH
Secure Socket Shell
SSL
Secure Socket Layer
SSM
Subscriber Service Module

C-8 List of terms
SSP
Subscriber Service Processor
SMP
SER 5500 Management Protocol
SNMP
Simple Network Management Protocol
SNTP
Simple Network Time Protocol
SSH
Secure Socket Shell
SSL
Secure Socket Layer
SSM
Subscriber Service Module
SVN
Software Version Number
TAC
Type Allocation Code
TE
Terminal Equipment
TEID
Tunnel Endpoint Identifier
ToD
Time of Day
TOS
Type of Services
T-PDU
Payload that is tunnelled in the GTP tunnel
TPO
Traffic Performance Optimizer

List of terms C-9
UDP
User Datagram Protocol
UMTS
Universal Mobile Telecommunication System
URL
Uniform Resource Locator
UTC
Universal Time Coordinated
UTRAN
UMTS Terrestrial Radio Access Network
VPLMN
Visiting Public Land Mobile Network
VPN
Virtual Private Network
VPRN
Virtual Private Routing Network
VSA
Vendor Specific Attribute
Warm Standby
A redundancy feature where the redundancy device is already in-service
and is ready to take the place of the failed device. Dynamic state information
is not stored and all current sessions are lost.
WAE
Wireless Application Environment
WAP
Wireless Application Protocol
WLAN
Wireless Local Area Network
WRAP
Wireless RADIUS Application Protocol

C-10 List of terms
WSP
Wireless Session Protocol
WTLS
Wireless Transport Layer Security
WTP
Wireless Transaction Protocol
WV
Wireless Village

test
Family Product Manual Contacts Copyright Confidentiality Legal
Nortel GGSN
User’s Guide
Document number: 411-5221-926

Product release: GGSN 6.0
Document version: Standard 11.06
Date: September 2008
Originated in the United States of America/Canada
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/documentfeedback
Copyright © 2000–2008 Nortel Networks, All Rights Reserved
While the information in this document is believed to be accurate and reliable, except as otherwise expressly agreed to in writing
NORTEL PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OR CONDITION OF ANY KIND, EITHER EXPRESS
OR IMPLIED. The information and/or products described in this document are subject to change without notice.
Nortel, Nortel Networks, the Nortel logo, and the Globemark are trademarks of Nortel Networks.
All other trademarks are the property of their respective owners.

411 5221 926 - 11.06

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

411 5221 926 - 11.06

Загружено:

Авторское право:

Доступные форматы

411-5221-926

GGSN 6.0 Standard 11.06 September 2008

Document number: 411-5221-926

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright © 2000–2008 Nortel, All Rights Reserved

All other trademarks are the property of their respective owners.

411-5221-926 Standard 11.06 September 2008

Modified Figure i, "PC05 Documentation Roadmap" on page xxiii

Changed Nortel GGSN User Guide to Nortel GGSN User’s Guide.

• Cabcharge L2TP Authentication

Nortel GGSN User’s Guide GGSN 6.0

• TCP MSS Clamping

CR Q01573968 - Missing information in output of Event tracetool.

GGSN 5.0, Preliminary 10.05. Updated for change requests.

411-5221-926 Standard 11.06 September 2008

• Q01090690 - add two sentences to opening paragraph of

• 28344 - “Content Based Billing” paragraph 11; “Service Redirect”

• Q01005640 (IP Routing)

Nortel GGSN User’s Guide GGSN 6.0

411-5221-926 Standard 11.06 September 2008

This version includes an additional chapter, “Product Conformance”.

Nortel GGSN User’s Guide GGSN 6.0

Database backup and restore procedures have been moved to GPRS/

Database backup and restore procedures are added to chapter

411-5221-926 Standard 11.06 September 2008

Nortel GGSN User’s Guide GGSN 6.0

411-5221-926 Standard 11.06 September 2008

About this document xxi

Release feature contents 1- 1

Nortel GGSN User’s Guide GGSN 6.0

GGSN services 2-8

411-5221-926 Standard 11.06 September 2008

G-CDR Auditing 3-61

Network deployment models 4- 1

Nortel GGSN User’s Guide GGSN 6.0

VLAN eBGP VPN model 4-17

411-5221-926 Standard 11.06 September 2008

GGSN VPRN model 6-5

Hardware and engineering 7- 1

Nortel GGSN User’s Guide GGSN 6.0

CORBA Shell Commands 8-229

Product limitations 10- 1

411-5221-926 Standard 11.06 September 2008

Product Conformance 12- 1

Nortel GGSN User’s Guide GGSN 6.0

RFC 3588 - Diameter Base Protocol 12-61

Patching System A-1

Detailed Protocol Information B-1

411-5221-926 Standard 11.06 September 2008

Dynamic Coupon Control B-74

List of terms C-1

Nortel GGSN User’s Guide GGSN 6.0

411-5221-926 Standard 11.06 September 2008

About this document 1

Audience for this document 1

It is assumed that the reader has a general familiarity with GPRS/

Organization of this document 1

Nortel GGSN User’s Guide GGSN 6.0

• Chapter 7, “Hardware and engineering”—describes the Nortel

411-5221-926 Standard 11.06 September 2008

GGSN06 G G S N and S C S S G S N /G P R S S G S N P ro visio n in g SGSN SGSN

Nortel GGSN User’s Guide GGSN 6.0