Nortel GGSN User Guide 411-5221-926.10.07

Nortel GGSNUser Guide

GGSNS5.0 Standard 10.07 June 2006

411-5221-926

test


Document number: 411-5221-926Product release: GGSNS5.0Document version: Standard 10.07 Date: June 2006

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright © 2000–2006 Nortel, All Rights Reserved

Originated in the United States of America/Canada

NORTELCONFIDENTIAL

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

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

* Nortel Networks, the Nortel Networks logo, the Globemark, Unified Networks, SCS, Service Creation System, Shasta 5000 BSN, SER 5500, BSN, iSOS, and system 5000 are trademarks of Nortel Networks.All other trademarks and registered trademarks are the property of their respective owners.

Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.

iiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

iiiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

Nortel GGSN User Guide GGSNS5.0

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

GPRS7.0/UMTS5.0, GGSN5.0 10.01. This is the initial draft release of this document for GGSN5.0.

September 2005

GPRS6.0/UMTS4.0, 09.06. This Preliminary version incorporates updates for the following CRs:

• 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

iv Publication historyNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

• 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

GPRS6.0/UMTS4.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 GGSN4.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

GPRS6.0/UMTS4.0, 09.04. This Standard version incorporates updates for GGSN4.1, and CRs:

• Q01005640 (IP Routing)

• Q01047753 (OAM)

• Q01047768 (OAM)

• Q01065315 (Functional Description)

• Q01075378 (Redundancy)

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

Publication history vNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


• 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

GPRS6.0/UMTS4.0, 09.03. Incorporated updates to parameter definitions and values, and branding changes for Nortel, SER 5500, VPN Router, W-NMS.

February 2005

• GPRS6.0/UMTS4.0 09.02. Incorporated change to CR Q01065148 and updated screen captures.

• GPRS6.0/UMTS4.0 09.01. This draft version for the GPRS6.0 and UMTS4.0 (GGSNS4.1) releases includes updates for GGSN4.1.

January 2005

GPRS6.0/UMTS4.0, 08.05. This Preliminary version for the GPRS6.0 and UMTS4.0 (GGSNS4.0) releases includes updates for CRs.

December 2004

GPRS6.0/UMTS4.0, 08.04. This Preliminary version for the GPRS6.0 and UMTS4.0 (GGSNS4.0) releases includes technical updates for CRs and review comments.

December 2004

GPRS6.0/UMTS4.0, 08.03. This Preliminary version for the GPRS6.0 and UMTS4.0 (GGSNS4.0) releases includes information for GGSNS4.0.1.

September 2004

GPRS6.0/UMTS4.0, 08.02. This Preliminary version is updated for the GPRS6.0 and UMTS4.0 (GGSNS4.0) releases.

vi Publication historyNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

July 2004

GPRS6.0/UMTS4.0, 08.01. This Draft version is updated for the GPRS6.0 and UMTS4.0 (GGSNS4.0) releases.

The organization of this document has the following changes from the GGSNS3.2 version:

• The chapter “Configuration procedures” was removed. All configuration information is contained in NTP 411-5221-927, GPRS/UMTS Nortel Networks GGSN Procedures Reference Manual.

• The appendix “Univity GGSN CLI” was removed. All CLI information is contained in NTP 411-5221-922, GPRS/UMTS Nortel Networks GGSN Command Line Interface Guide.

• Information on the RADIUS protocol is removed from appendix “Detailed protocol information”. RADIUS protocol information is contained in NTP 411-5221-928, Nortel Networks GGSN RADIUS Interface Guide.

The name “Univity GGSN” is replaced with “Nortel Networks GGSN.”

May 2004

GPRS5.0/UMTS3.0, 07.03. This Standard version contains updated information for the GPRS5.0 and UMTS3.0 (GGSNS3.2) releases.

May 2004

GPRS5.0/UMTS3.0, 07.02. This is the Standard version for the GPRS5.0 and UMTS3.0 (GGSNS3.2) releases.

This version includes an additional chapter, “Product Conformance”.

Database backup and restore procedures have been moved to NTP 411-5221-927, GPRS/UMTS Univity GGSN Procedures Reference Manual.

January 2004

GPRS5.0/UMTS3.0, 07.01. This Preliminary version for the GPRS5.0 and UMTS3.0 releases is updated for the GGSNS3.2 release of the GGSN software.

October 2003

GPRS5.0/UMTS3.0, 06.05. This Standard version includes updated information for the GPRS5.0 and UMTS3.0 releases.

Database backup and restore procedures are added to chapter “OA&M”.

Publication history viiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


August 2003

GPRS5.0/UMTS3.0, 06.04. This Standard version for the GPRS5.0 and UMTS3.0 releases includes information for the GGSNS3.1 release of the Shasta GGSN software.

June 2003

GPRS5.0/UMTS3.0, 06.03. This is the Standard version for the GPRS5.0 and UMTS3.0 releases.

November 2002

GPRS5.0/UMTS3.0, 06.02. This Preliminary version contains updated information for the GPRS5.0 and UMTS3.0 releases.

September 2002

GPRS5.0/UMTS3.0, 06.01. This Draft version contains updated information for the GPRS5.0 and UMTS3.0 releases.

September 2002


August 2002

GPRS4.0/UMTS2.0, 05.04. This Preliminary version includes updates for Change Requests (CRs) and information about GRE VPN.

May 2002


April 2002


March 2002

GPRS4.0/UMTS2.0, 05.01. This Draft version contains updated information for the GPRS4.0 and UMTS2.0 releases.

February 2002


viii Publication historyNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

October 2001

GPRS3.0/UMTS1.2, 04.02. This is the Preliminary version for the GPRS3.0 and UMTS1.2 releases.

October 2001

GPRS3.0, 04.01. This Draft version contains updated information for the GPRS3.0 release.

September 2001

GPRS2.1, 02.02. This is the Standard version for the GPRS2.1 release.

July 2001

UMTS1.1, Preliminary 03.01. This Preliminary version contains updated information for the UMTS1.1 release.

July 2001

GPRS2.1, 02.01. This Preliminary version contains updated information for the GPRS2.1 release.

June 2001

GPRS2.0/UMTS1.0, 01.04. This Preliminary version contains updated information for the GPRS2.0 release.

May 2001

UMTS1.0, 01.03. This Preliminary version contains updated information for the UMTS1.0 release.

January 2001

UMTS1.0, 01.02. Release for the UMTS1.0 Alpha trial.

December 2000

UMTS1.0, Draft 01.01. Document creation.

ixNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


Contents 1

About this document xiiiAudience for this document xiiiOrganization of this document xiiiRelated documents xvRelated training xviiIndication of hypertext links xviiNortel branding xviii

Release feature contents 1- 1UMTS3.0/GPRS5.0 and Prior Releases 1-1UMTS4.0/GPRS6.0 1-11GGSN5.0 1-22

Introduction 2- 1GGSN interfaces 2-3GGSN services 2-8

Functional description 3- 1Overview 3-1Functional concepts 3-3GTP protocol 3-13Single Access Point Name 3-22Subscriber Access Control 3-32IP address allocation 3-34GGSN accounting 3-41GTP accounting 3-42RADIUS Accounting 3-58Fault Tolerant Billing 3-62Content Based Billing 3-63Partial billing for roamers 3-64Tunneling on the Gi interface 3-64Quality of Service (QoS) 3-80GGSN Administration and Maintenance 3-84Wireless services 3-98Policy merging 3-117SGSN Grouping 3-118

x ContentsNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

Lawful Interception (LI) 3-119Traffic Performance Optimizer (TPO) 3-121

Network deployment models 4- 1Overview 4-1Network models 4-1Wireless ISP model 4-5Wireless ISP VLAN access 4-7L2TP VPN model 4-8VPN variants 4-10Wireless services deployment 4-17

IP services 5- 1Overview 5-1Policy merging 5-2IP Services for IP in IP 5-3Firewall 5-4Traffic Policing 5-5Traffic Shaping 5-7Policy-Based Forwarding 5-8Web Steering 5-8Personal Content Portals 5-9DiffServ Marking 5-9Anti-Spoofing 5-10WAP 1.2 Redirection 5-10Content Based Billing 5-15Event Based Billing 5-21Dynamic Policy Control 5-25Content Filtering 5-28ISP security services 5-30Management Services 5-36Traffic Performance Optimizer (TPO) Interworking 5-37

IP routing 6- 1Overview 6-1Wireless ISP model routing 6-2L2TP VPN model 6-4GGSN VPRN model 6-4GRE VPN model 6-5Multi-Protocol Label-Switching (MPLS) 6-5OSPF-TE 6-12IS-IS routing 6-12Subscriber IP address management 6-14Route redundancy 6-19Layer 2 switched networks 6-21IP multicast 6-21IP address in GTP signaling message 6-22Source Address in RADIUS/DHCP Message 6-24SINK routes 6-25

Contents xiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


Hardware and engineering 7- 1Overview 7-1Services Edge Router hardware description 7-1Engineering configuration 7-10

GUI Provisioning 8- 1Overview 8-1SCS Graphical User Interface 8-1CORBA API User Interface 8-199CORBA Shell Commands 8-199

OA&M 9- 1Overview 9-1Operation Measurements 9-1Alarms 9-118Event Logs 9-218Event Trace 9-288System Time 9-295Software Optionality Control (SOC) 9-295Active Session Management (ASM) 9-295CLI Command 9-301Patching System 9-301Upgrade Strategy 9-302SCS Backup and Restore 9-302

Product limitations 10- 1GGSN Hardware 10-1GTP and GTP’ Protocol Interface 10-2RADIUS Authentication and Accounting 10-4DHCP address allocation 10-5SCS Provisioning 10-5OA&M 10-7GGSN QoS 10-7APN 10-8Prepaid Service 10-9IP Services 10-9IP Routing 10-13

Redundancy 11- 1Nortel GGSN 11-1Service Creation System (SCS) Server 11-5Charging Gateway Function (CGF) 11-5Prepaid Server 11-5Diameter Credit Control Server 11-5Application Server 11-6RADIUS Server 11-6DHCP Server 11-9FTP Server 11-9Traffic Performance Optimizer (TPO) Server 11-9

xii ContentsNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

Product Conformance 12- 1Overview 12-1GPRS Specifications 12-1

12-7UMTS Specifications 12-7

12-41RFC Specifications 12-41

Patching System A-1Patching Functions A-1SSG Upgrade Strategy A-3Patching Privileges A-3Patching Configuration A-3

Detailed Protocol Information B-1GTP Protocol Extension B-1GTP’ Charging Protocol B-5RADIUS Protocol B-45WRAP Protocol B-46Card Telephony Protocol (CTP) B-47Diameter Credit Control (DCC) protocol B-56

List of terms C-1

xiiiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


About this document 1This 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 1This 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 1Information 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.

xivNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

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

xvNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


Related documents 1Roadmap to Packet Core 05 documentation

Figure i shows the NTPs in the documentation suite for PC05.

Figure i PC05 Documentation Roadmap

SpecificationsFor 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

Installation andCommisioning

Upgrading

SGSNBilling Samples411-5221-205

Planning and Engineering

About the UMTS Network

411-8111-502

Terminology411-8111-804

Concepts

GGSN, SCS What's New

411-5221-200

GGSN H/WInstall & Maintenance

411-5221-923

Operations andAdministration

GGSNCLI Guide

411-5221-922

Packet CoreConformance Guide

411-5221-201

Fault and Performance Management

SGSN Alarms

411-5221-500

SGSNMonitoring Guide

411-5221-050

SGSN Components

411-5221-060

Core NetworkTroubleshooting

Guide411-5221-501

GGSN Alarms

411-5221-921

SGSN ProvisioningProcedures

411-5221-904

SGSN What's New

411-5221-202

SGSN/GPRS Upgrade

411-5221-307

SGSN/UMTSUpgrade

411-5221-308

SCS & GGSNUpgrade

411-5221-309

AN Upgrade

411-5221-310

SIG User Guide

411-5221-975

SGSN Accounting

411-5221-312

GGSN User Guide

411-5221-926

GGSN Monitoring Guide

411-5221-924

GGSN ProvisioningProcedures

411-5221-927

GGSN RADIUS Interface Guide 411-5221-928

SIG User Guide

411-5221-975

SGSN Planning& Engineering411-5221-314

GGSN User Guide

411-5221-926

SIG User Guide

411-5221-975

SGSN Overview

411-5221-311

GGSN User Guide

411-5221-926

SIG User Guide

411-5221-975

Corbashell CLI Guide

411-5221-929


411-5221-929


411-5221-929

GGSN User Guide

411-5221-926

GGSN ProvisioningProcedures

411-5221-927

Sept21/05

GGSNBilling Samples411-5221-206

SGSNCall Detail Records

411-5221-204

Packet CoreDocumentation411-5221-004

SGSN Administration411-5221-313

SGSN Administration411-5221-313

xviNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

• 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, Version 2

• 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

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

xviiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


• 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 documentationFor 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 ManagementRefer to NTP 411-5221-003, Nortel Wireless Network Management System Documentation Guide, for a complete list of NTPs in the Wireless Network Management documentation suite.

Related training 1For 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 1Hypertext 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.

xviiiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

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

Table i Original product names mapped to new names

Original Name(s) New Name Short Name Function

Alteon Application Switch xxxx

Nortel Applications Switch xxxx

Applications Switch xxxx

Alteon Web Switch 184 Nortel Web Switch 184 WebSwitch 184

BayStack 450 Nortel Ethernet Switch 450 Ethernet Switch 450

BPS2000 2-port SFP GBIC MDA

Nortel Ethernet Switch 2-port SFP GBIC MDA

CCN CS(DMS MSC)

Nortel GSM/UMTS MSC MSC Mobile Switching Center

—sheet 1 of 3—

xixNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


CCN HLR(DMS HLR)

Nortel GSM/UMTS HLR 100 HLR 100 Home Location Register

Combined MSC and HLR(DMS Trinode)

Nortel GSM/UMTS Combined MSC/HLR

Combined MSC/HLR

Contivity xxxx Secure IP Services Gateway

Nortel VPN Router xxxx VPN Router xxxx

DMS Gateway Mobile Switching Center (GMSC)

Nortel GSM/UMTS MSC Server

MSC Server Mobile Switching Center

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 Preside for Wireless Internet

NIMS-PrOptima™ for W-NMSa

Network Information Management System & Wireless Network Management System

Nortel Networks Secure Router xxxx

Nortel VPN Router xxxx VPN Router xxxx

Offline Configuration for Access Networks (OCAN)

Wireless Provisioning System for Access b

WPS for Access

Wireless Provisioning System

Passport 7400 (7K) Nortel Multiservice Switch 7400

Multiservice Switch 7400





Table i Original product names mapped to new names (continued)


—sheet 2 of 3—

xxNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

Preside for Wireless Internet (PWI)

Nortel Wireless Network Management System

W-NMS Network Management System for Wireless Networks

RNC Nortel UMTS RNC xxxx RNC xxxx

Shasta 5000 BSN Nortel IP Services Edge Router 5500

IP Services Edge Router 5500

Univity GGSN(Shasta GGSN)

Nortel GGSN GGSN Gateway GPRS Support Node

Univity HLR c Nortel GSM/UMTS HLR 200 HLR 200 Home Location Register

Univity MLC(MLC)

Nortel MLC MLC Mobile Location Center

Univity SGSN(SGSN, GPRS SGSN,UMTS SGSN,USGSN or U-SGSN)

Nortel SGSN(Nortel SGSN/GPRSNortel SGSN/UMTS-use where required to differentiate technology.)

SGSN(SGSN/GPRS, SGSN/UMTS-use where required to differentiate technology.)

Serving GPRS Support Node

Univity Signaling Gateway (SIG d, SS7-IP Gateway)

Nortel GSM/UMTS SIG SIG Signaling Interworking Gateway

UMGW (MGW, Passport Voice Gateway (PVG))

Nortel GSM/UMTS MGW MGW Media Gateway

Wireless Gateway (WG) NOTE: Configuration NOT

supported in PC04 and

beyond, is supported in OAM.

See the following:- Nortel SGSN - Nortel GSM/UMTS MGW

a. NIMS PrOptima™ is a sub-component of W-NMSb. WPS for Access is a sub-component of W-NMSc. May have also been referred to as Everest HLRd. May have also been referred to as HP SIG

Table i Original product names mapped to new names (continued)


—sheet 3 of 3—

xxiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks


Table ii New product names mapped to original name(s)

New Name Short Name Original Name(s)

Nortel Ethernet Switch 2-port SFP GBIC MDA

BPS2000 2-port SFP GBIC 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 MSC/HLR

Combined MSC/HLR Combined MSC and 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

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 5500

IP Services Edge Router 5500 Shasta 5000 BSN

NIMS-PrOptima™ for W-NMS c NIMS-PrOptima™ for Preside for Wireless Internet

—sheet 1 of 2—

xxiiNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

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:- Nortel SGSN/GPRS- Nortel SGSN/UMTS

SGSNSGSN/GPRS SGSN/UMTS)

Univity SGSN, GPRS SGSN, UMTS SGSN, U-SGSN, or USGSN function of a Wireless Gateway

Nortel UMTS RNC xxxx RNC xxxx RNC

Nortel Web Switch 184 Web Switch 184 Alteon Web Switch 184

Nortel Wireless Network Management System

W-NMS Preside for Wireless Internet (PWI)

Wireless Provisioning System for Access d

WPS for Access Offline Configuration for Access Networks (OCAN)

a. May also have been referred to as Everest HLRb. May also have been referred to as HP SIGc. NIMS PrOptima™ is a sub-component of W-NMSd. WPS for Access is a sub-component of W-NMS

Table ii New product names mapped to original name(s) (continued)

New Name Short Name Original Name(s)

—sheet 2 of 2—

1-1Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


Release feature contents 1This 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.

UMTS3.0/GPRS5.0 and Prior Releases 1GGSN Functionalities Description

The following basic system functionalities have been included in the GGSN3.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

• 3GPP TS 32.015 compliance

1-2 Release feature contentsNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

• 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-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


Feature DescriptionA number of features have been introduced in the GGSN3.2 and prior releases which are detailed in the following table:

Table 1-1UMTS3.0/GPRS5.0 GGSN Features

UMTS Feature ID

GPRS Feature ID

Feature Title Feature Description

1009 (In GPRS2.1 release)

Provide PDP context support for inter SGSN handoff

Support of PDP context during handoff between SGSNs including fallback/fallforward between GTP version 0 and version 1 SGSNs

1018 12076 & 13270

Transparent access - L2TP over IPSec

Support of GTP-L2TP tunnel switching for PPP and IP PDU type


GPRS Billing GSM TS 32.015 content conformance

Provide 3GPP TS 32.015 version 3.2 compliance for GGSN accounting function.


DHCP - user class ID; configurable client ID

Support of DHCP client function on Nortel GGSN


Hot Billing Support of passing CDRs to CGF in real time

1051 End to End QoS Support

Support of QoS via DiffServ marking on Gn interface


Gi over ATM Support of Gi interface over ATM


Gp Allow subscribers roaming into a VPLMN and being granted service.

12144 Dec 00 CR Compliance

Provide 3GPP GPRS technical specification Dec 00 CR compliance.

12772 Personal Network Portal

Support of personal network portal IP service

60010373 13904 IS-IS Routing Permit GGSN to interconnect with IS-to-IS routing networks.

—sheet 1 of 6—


411-5221-926 Standard 10.07 June 2006

60011189 13905 RADIUS Dynamic Address Allocation

Support of RADIUS dynamic address allocation from the RADIUS servers based on the Class attribute

9152 17971 3GPP TS 32.015 v3.6.0

Compliance to TS 32.015 v3.6.0 provides additional call record related information in the CDRs for operator to process.

11715 15266 IP Multicast IGMP Proxy

IGMP Proxy enables GGSN to proxy multicast control messages between subscribers and routers and broadcast the multicast packets.

11716 12282 Tariff Based Billing

Support of the G-CDR billing based on 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 Accounting

Provide the RADIUS accounting option on the Gi interface.

11840 15272 Performance Metrics: Historical Statistics

Collect the historical performance metrics to enable the performance evaluation for GGSN.

11948 15290 CMC Capacity Enhancement

Increase the total number of simultaneous sessions supported to 128k at GGSN.

12183 15288 DHCP Relay Agent

GGSN acts as a DHCP relay agent between DHCP client (i.e. mobile station) and DHCP server.

12196 15292 Single Access Point Name (APN)

Operators can set up fewer number of APNs and provide a set of services by retrieving per subscriber information in the RADIUS response message.

Table 1-1UMTS3.0/GPRS5.0 GGSN Features (continued)

UMTS Feature ID

GPRS Feature ID


—sheet 2 of 6—



16739 17974 June ‘01 Standard CR Conformance

Provide the compliance to 3GPP Rel 99 Change Requests.

19237 19947 Content-based Billing

Provide support for multiple accounting rates for data based on the origination location.

19704 19949 GGSN Overload Control

Provide the appropriate safeguard against system instability in an overload environment.

19156 Capacity Enhancement Aggregation Sessions

The Nortel GGSN will be modified to provide a unique flexibility for service providers to meet the market needs for 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 Session Management

This feature enhances the Nortel GGSN OAM capabilities by providing a SCS GUI for the display of selected statistic values and the execution of Active Session Management (ASM) commands.

20273 March ‘02 Standard CR Conformance

This feature provides the conformance to the 3GPP Rel 98 and Rel 99 March ‘02 standard change requests. This feature doesn’t include 3GPP TS 32.015.

20781 Gi Interface Availability

Enable the capability to flag APNs as 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.


UMTS Feature ID

GPRS Feature ID


—sheet 3 of 6—


411-5221-926 Standard 10.07 June 2006

21077 Prepaid Location Rating

Enable the Nortel GGSN to provide the 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 Billing for Roamers

Provide the ability to configure a periodic billing interval used to create billing records for outbound roaming subscribers.

21259 GGSN PC03 Counter Enhancement

This feature enables the operator to define a finer 5-minute granularity for one or more of the historical metrics statistics groups.

21523 OS hardening for Solaris 8 for SCS

This feature results in an OS hardening script for Solaris 8 that will be executed during SCS Server installation and upgrade. Following an installation or upgrade, the SCS Server will be hardened.

21610 SCS Support of Solaris 8

The SCS Server is upgraded to the currently available version, i.e. Solaris 8 update 7.

21767 Overload Control Enhancement

Nortel GGSN monitors the amount of usable CMC memory available and 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 Based Billing

The Content Based Billing is enhanced to 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 on Gi

This feature provides the 802.1q VLAN access connection capability used with VPN.


UMTS Feature ID

GPRS Feature ID


—sheet 4 of 6—



24005 CBB Support for WAP

The CBB functionality is extended to support the WAP 1.x protocol stack.

24438 Node and Management Security Services

Add the stateful firewall capability to each ISP to protect Nortel GGSN from malicious external users.

24635 CBB Support for MMS over WAP

Allow MMS over WAP messages to be billed separately from WAP content by using different rate for data flows.

11818 DiffServ EF/CS Marking

The DSCP marking of EF, CS7, CS6 and DE in the IP packet header is supported on the Gn and Gp interfaces for the downlink packets.

20587 Secure GGSN Management Traffic

The SSH for CLI login ensures that all command line interface traffic is encrypted and secure. The SSL between SCS client and SCS server ensures that all management traffic is encrypted and secure.

21309 GGSN Services Capacity Enhancement

This feature provides access to many of the advanced wireless and IP services for the subscribers in APNs enabled for aggregation support.

21586 Standards CR Conformance

This feature provides Nortel GGSN the conformance to the 3GPP Release 98 and Release 4 December 2002 standard Change Requests.

21750 Variable Rate Prepaid

Extend the Nortel GGSN based 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 Counters Enhancements

The Nortel GGSN historical statistics collection mechanism is enhanced to align collection granularity periods to the clock intervals and reset the counter at the beginning of each collection period.


UMTS Feature ID

GPRS Feature ID


—sheet 5 of 6—


411-5221-926 Standard 10.07 June 2006

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.

23394 CBB Scaling and Flexibility Enhancement

This feature enhances CBB by supporting additional WAP protocols and 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 Patching

This feature adds to the existing CMC patching functionality by extending the supported targets to include the SSC.

24640 APN Serviceability Enhancement

This feature expands the operators’ ability to monitor active PDP sessions and control subscriber access on an APN basis.

25488 Access Connections from Wireless ISP

This feature allows access connections to be configured on the Gi interface using the wireless ISP network model.

25944 IP Address Blackout Timer

Subscriber IP address management is enhanced to include an optional address blackout period during which the IP address is restricted from reallocation.

26048 GGSN Support for Cisco RADIUS DNS VSA

This feature expands GGSN RADIUS VSA functionality to include the Cisco VSA for DNS support.

26098 GGSN integrated RADIUS debugging

This feature provides capability to trace RADIUS message flow across all network models.


UMTS Feature ID

GPRS Feature ID


—sheet 6 of 6—



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


411-5221-926 Standard 10.07 June 2006

• 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 UpThe GGSN3.2 software loads are used for the UMTS3.0 and GPRS5.0 releases.



UMTS4.0/GPRS6.0 1Nortel GGSN has the following sub-releases for UMTS4.0 and GPRS6.0 product line releases:

• GGSN4.0

• GGSN4.1.

GGSN4.0 DescriptionThe GGSN4.0 is part of UMTS4.0/GPRS6.0 product release. There are a number of functions being added to GGSN4.0 which are detailed in the following table:

Table 1-2GGSN4.0 Features in UMTS4.0/GPRS6.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 Context

This feature introduces secondary PDP context procedures as defined by the 3GPP Release 4 standards on the GGSN.

11832 ATM Service Classes: CBR, VBR

Improve the shaping capability for UMTS QoS traffic classes over ATM. Specifically, it provides the multiple VC support of CBR, rt-VBR and nrt-VBR.

12059 MPLS VPN (RFC2547bis)

This feature provides the capability on the GGSN to support BGP/MPLS VPN based on RFC 2547 over the Gi interface.

17601 GGSN Integrated Lawful Intercept

This feature provides the necessary capability on the GGSN as an Intercept Access Point (IAP) or Access Function (AF) for Lawful Intercept functions.

—sheet 1 of 5—


411-5221-926 Standard 10.07 June 2006

19061 V-GGSN Access Control

This feature is to control the use of GGSN by visiting subscribers. GGSN allows or inhibits the use of certain APNs by visitors based on the visiting subscriber's IMSI.

22987 GGSN HW for PC04 - SFC2

The SFC2 hardware provides support for expanded ATM service classes as well as robustness and failover improvements.

23710 SSC Billing Resilience

This feature allows a much more frequent internal updating of the SSC billing information to the CMC without generating partial records.

24658 Base Shasta 4.0 Features

This feature encompasses several iSoS 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 System and Centralized Data Backup and Restore

This feature provides the offline ability to perform a full backup and full restore of the Solaris OS, third-party software, SCS application and all server data. In addition, this feature automates the data backup/restore for SCS from centralized PWI backup/restore solution.

Table 1-2GGSN4.0 Features in UMTS4.0/GPRS6.0 (continued)


—sheet 2 of 5—



25767 L2TP Multiple Tunnels

This feature allows attributes of multiple 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 PC04

The feature incorporates the following 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 Capacity Activation Rate Improvement

Via software optimization, this feature improves the activation rate for PDP sessions using DHCP or VPN services and the maximum session capacity using ALC card on the Gi interface.

25832 GGSN Standards CR Conformance

This feature provides conformance to 3GPP standard Release 4 December 2003 CRs.

26534 GGSN MSISDN/IMSI Debug Trace Tool

This feature provides a wide range of 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—


411-5221-926 Standard 10.07 June 2006

26371 Transparent VSA Handling

GGSN supports the reception of a 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 Containers

When tariff switch occurs during prepaid 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 Rounding for GTP’ Billing

This feature provides an option to regularly generate G-CDRs and RADIUS Interim Accounting Records at intervals equal to the billing time limit.

26422 Diameter CC Real-Time Charging

Support a real-time charging interface using the Diameter CC protocol for credit control functions between GGSN and real-time charging server.


26664 CTPv3 Redirection Trigger

Following a quota authorization denial, 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-billing selection

This feature enables control of the 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—



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.

27657 GGSN Basic Software Optionality Control

This feature provides optional feature control to prevent unauthorized use of the functionality offered. It also provides a mechanism to manage exclusivity that may be required for some custom development items.

27762 Charging Characteristics Pass-Through in RADIUS Authentication

The Charging Characteristics parameter in the Create PDP Context Request message is optionally passed to the RADIUS Server during RADIUS authentication.

28188 CBB Usage Time Accounting Enhancements

This activity enhances the existing CBB functionality by filtering different layer 7 applications and report usage based on time.

28307 Diameter CC Lucent Interworking

Interworking with Lucent Technologies 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 WAP Buffering

This feature enhances the existing CBB service to correctly rate the pipelined and fragmented HTTP requests and their responses.



—sheet 5 of 5—


411-5221-926 Standard 10.07 June 2006

• 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 DescriptionGGSN4.1 is part of UMTS4.1/GPRS6.0 product release. It builds on the top of GGSN4.0 release. There are a number of functions being added to GGSN4.1 which are detailed in the following tables:

Table 1-3GGSN4.1 Features in UMTS4.1/GPRS6.0


12250 Data Plane Redundancy for High Capacity APNs

This feature is implemented in a 2N load sharing redundancy configuration. This 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 Enhancements

This feature furthers the development of 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 Interface

Support of the CORBA Shell on the SCS server for GGSN provisioning.

26919 GGSN Control Management Card - Version 3

The third version of Control Management Card (CMC3) is introduced to increase 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 6—



27314 CBB Provisioning XML Import/Export

CORBA support for CBB policy provisioning, including policy string validation.

27356 Service Edge Router Base iSOS Features for GGSN 4.1

This feature encompasses several iSOS 5.0 Service Edge Router Base Features:

1. Dynamic Routing Over IPSec2. Non-wildcard IPSec DPD Keepalive

Mechanism3. VPN Security Enhancements for RADIUS4. IPSec MIB Enhancement5. CardMgr Recovery Robustness6. TaskMgr Sanity Overhaul7. Overload Controls8. MPLS Management VPN9. BGP Route Refresh Capability10.MPLS VRFs - Flexible DF bit treatment

27686 SCS Upgrade Strategy

This feature explains the installation/upgrade enhancements made to the SCS 4.1, to eliminate the errors during the SCS installation and upgrade.



—sheet 2 of 6—


411-5221-926 Standard 10.07 June 2006

27764 Gn Parameters Enhancements (IMEI-SV, RAT)

This feature adds support for handling two new optional IEs defined in 3GPP 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.

28338 Billing Accuracy Enhancement

Ensure the accuracy of accounting timestamps, duration, and partial record interval is +/- 0.5 seconds over the whole PDP context duration.

28339 CTP Prepaid Enhancement: Number of Initial Coupon IDs

The maximum number of initial coupon IDs configured via SCS GUI has been increased to 40.



—sheet 3 of 6—



28340 Partial Record Generation: Switchability of trigger event

Enhance the trigger events RAT change and QoS change to be configurable so that the trigger events can be turned off.

28344 Prepaid Service Redirect Enhancement

Re-classify the charging of TCP connection sequence. A forbidden type of coupon ID is created for the denied service redirect.


28520 GGSN Alarm Trap Replay

This feature allows integration of GGSN/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 Reporting

This feature provides configurable option to report the resource total usage for a coupon ID in addition to the delta usage.

28607 Initial coupon ID configuration

This feature allows the provisioning of Coupon IDs in the CBB policy definition which is sent to the Prepaid/DCC server during initial authorization.



—sheet 4 of 6—


411-5221-926 Standard 10.07 June 2006

28630 GCDR Automated Clean Up

An automated clean up function is 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 5 of 6—




29082 CBB Support for Absolute URL format

Provide support of absolute URL to allow 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 Performance Optimizer (TPO) Interworking

This feature allows interworking between the GGSN and a Traffic Protocol Optimizer. Allow client/server based optimization to take place with all the GGSN IP services and wireless services, including CBB.


27259 Diameter CC Real-time Charging Phase 2

Diameter CC Real-Time Charging introduces GGSN support of the Gy real-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 quota2. Event based quota3. Radio Access Type4. CBB Category/Coupon Blacklisting




—sheet 6 of 6—


411-5221-926 Standard 10.07 June 2006

• 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 UpThe GGSN4.0 software load is used for the UMTS4.0 and GPRS6.0 releases. The GGSN4.1 software load is used for the UMTS4.1 and GPRS6.0 releases.

GGSN5.0 1Nortel GGSN5.0 release is deployed to both GPRS and UMTS networks.

Functionalities DescriptionGGSN5.0 is part of UMTS5.0 product line release. There are a number of functions being added to the GGSN5.0 release which are detailed in the following table:

Table 1-4GGSN5.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 Conformance

Implement approved 3GPP Rel 5 and Rel 6 standard CRs such that the GGSN meets the minimum level of conformance to the published standards.

26434 3GPP Rel 6 Dynamic Policy Control (Gx)

This feature enables dynamic session 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.




26513 3GPP Rel 6 Diameter Credit Control (Gy)

This feature introduces GGSN support of the Gy online charging interface using the Diameter CC protocol for credit control functions between GGSN and online charging server.


26932 Single APN Selectable Address Pools

The GGSN supports the selection of the address pool via Single APN RADIUS Framed-Pool attribute.

27492 User Location Information Support

The user location information which is sent within the PDP context request from the SGSN has been included in all accounting information for the GGSN.

27566 Nortel GGSN Content Filtering

This feature provides support for content 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 based on DCC-CLCI events

This feature reports Diameter CC real-time cause codes in the G-CDR records for the exception cases.

28687 GGSN5.0 Capacity Targets

The introduction of SSC3 card and the optimization around some call models using RADIUS interface or DCC interface improve the overall capacity of the GGSN.

28849 Availability Improvement

The Health Check Monitoring is 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.




411-5221-926 Standard 10.07 June 2006

29351 Parking Meter Event Charging

Enhance CBB to incorporate new 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 Source IP Address Selection

This feature allows the source IP address for all GGSN originated protocols to be either configured ISP default address or hardcoded ISP default address.

29937 GGSN Counter Enhancements

Introduce new counters to generate the call models for the capacity calculation of the GGSN.

29946 Configurable RADIUS Interim Messages

Provide more flexibility for controlling the sending of RADIUS Interim Update message on a per APN basis.






• 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 UpThe GGSN5.0 software load is used for the UMTS5.0 release.

29957 Support for HTTP Methods

This feature adds the support of additional HTTP methods via CBB.

30020 DCC Tx Timeout Alarm

This feature adds an alarm notification for Diameter CC timer Tx expiration.

30077 SGSN Grouping and RAT Mapping Function

Provide the SGSN grouping function and allow the mapping of serving Radio Access Technology if it is not received from the SGSN.


30409 IP Services support for IP in IP

This feature is to provide the support of IP services for the mobile IP traffic that is passing through the Nortel GGSN.





411-5221-926 Standard 10.07 June 2006



Introduction 2Gateway 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 IntroductionNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

Figure 2-1 GGSN network connectivity

Packet DataNetwork

Public

SGSN

SGSN

SGSNSGSNHome PLMN

SGSN

Visiting PLMN

GGSN

BG

GGSN

GGSN

BG - Border Gateway

Introduction 2-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


GGSN interfaces 2Following 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

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

SGSN GGSN

HLR

BillingSystem

TE

Other PLMN

SGSN

PDN

Gc

Gi

GaGp

Gn

CGFCGF

DCCCRF

GyGx


411-5221-926 Standard 10.07 June 2006

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 protocolThe Nortel GGSN does not support the Gc interface.

Gn/Gp interface protocolThe 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:

— 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

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.

L1

L2

IP

UDP

GTP-C

L1

L2

IP

UDP

GTP-C

Gn/GpGSN GSN


411-5221-926 Standard 10.07 June 2006

Figure 2-4 User Plane of SGSN-GGSN

Gi interface protocolsIPv4 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 ProtocolThe 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 integration with 3rd party credit control servers through the use of a standard based Diameter interface.

Application

GTP-U

IP

L2

L1

RelayGTP-U

UDP

L2

L1

SGSN GGSNGn Gi

IP

UDP



Gx Interface ProtocolThe 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.


411-5221-926 Standard 10.07 June 2006

GGSN services 2In 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

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

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

Note: WAP is supported only through RADIUS Accounting for Aggregation APN.

• IP Services

— Policing

— Traffic Shaping

— Policy Based Forwarding

— Personal Network Portals

— DiffServ Marking

— Firewalls

— Anti-Spoofing

— Content Based Billing

— Traffic Performance Optimizer (TPO) Interworking

• IP Routing

— OSPF

— RIP

— BGP

— IS-IS

— IP Multicast

— MPLS


411-5221-926 Standard 10.07 June 2006

Note: IP Multicast is not supported for Aggregation APN.



Functional description 3Overview 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 descriptionNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

To support the functionality listed above, the GGSN must interwork with different components within the PLMN and PDN networks. Figure 3-1 summarizes the supported protocols on the GGSN for interworking with different external components.

Figure 3-1 GGSN interworking components

GGSN

Application

CGF

SGSN

GTP’

WRAPCTP

GTP

real-time

RADIUS Server

RADIUS SCS ServerSMP

OSS

CLI/SNMP/CORBA

SCS Client

Java RMI

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 Service- SMP: Shasta Management Protocol- SNMP: Simple Network Management Protocol- TPO: Traffic Performance Optimizer- WRAP: Wireless RADIUS Application Protocol

DHCP Server

DHCP

FTP Server

FTP

Diameter CreditControl Server

DCC (Gy)

Top-Up Server

TPO Server

LIG

CRF

Gx

IPSec

CFS

TCP/UDP

charging server

Functional description 3-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


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


411-5221-926 Standard 10.07 June 2006

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

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.

GGSN

Gn

ISPGn

Gi

Packet DataNetwork

Con

nect

ion

ISP

APN

APN

SGSN

Con

nect

ion

ISP

APN

APN

APN

Con

nect

ion

ISP

APN

APN

APN

SGSNSGSN

OAMNetwork

Ga ISP

Ga

DefaultISP

OAM

LIG

LI ISP

TPO

TPO ISP

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

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.

GGSN

Gn

ISP

Gn

Con

nect

ion

ISP APN

APN

SGSNC

onne

ctio

n IS

P

APN

APN

APN

Con

nect

ion

ISP

APN

APN

APN

SGSNSGSN

OAMNetwork

Ga

Def

ault

ISP

OAM

LI ISP

TPO Server

LIG

TPO ISP


411-5221-926 Standard 10.07 June 2006

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 ISPThe 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 ISPThe 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 illustrates the Gn ISP configuration concepts based on the Service Creation System* (SCS)* Graphical User Interface (GUI).


411-5221-926 Standard 10.07 June 2006

Figure 3-4 Gn ISP configuration diagram

GTP’ Profile

Gn ISP

Connection Template CGF ProfileConnection Templates

GTP’ Profiles

Access Properties GTP Tunnel

CGF Profiles



Ga ISPThe 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 illustrates the Ga ISP configuration concepts based on the SCS GUI.

Figure 3-5 Ga ISP configuration diagram

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

GTP’ Profile

Ga ISP

CGF Profile

GTP’ Profiles

Access Properties

CGF Profiles


411-5221-926 Standard 10.07 June 2006

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 illustrates the Connection ISP configuration concepts based on the SCS provisioning.

Figure 3-6 Connection ISP configuration diagram

Connection ISP

Billing TariffApplication

Identification Outbound Tunneling IP Address AllocationServices

Membership=Group

RADIUS Profile

PPP Profiles

Access Group

Connection Template

Tariff Profiles

Application Profiles

Access Properties APN

Service Policies

Content Based Billing

IP Address pools

RADIUS Profiles

DHCP Profile

GGSN QoS Profiles

Account

TemplateSubscriber

Profile ProfileGGSNQoS

ProfileToD

Profile

DHCP Profiles

ToD Profiles

Tunnels

L2TP

AdminState



LI ISPLI 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 secure connection between the GGSN and LIG, 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.

TPO ISPThe 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 NameThe 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


411-5221-926 Standard 10.07 June 2006

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

GTP protocol 3One 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 contextsThe 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.

Table 3-1Derived RAT mapping logic

With “RAT Mapping” enabled

RAT received in GTP

RAT not received in GTP

Matching entry in the SGSN Mapping table found

Use the received RAT

Use the RAT of the matching entry

Matching entry in the SGSN Mapping table not found


Default entry in the SGSN Mapping table provisioned

Use the RAT of the default entry

Default entry in the SGSN Mapping table not provisioned

Use “Unknown” (0)


411-5221-926 Standard 10.07 June 2006

Secondary PDP ContextThe 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.

Protocol interactionThe 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 typeFor 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-66 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 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

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.

PPP

IP

Packet DataNetwork

GGSNGTP Tunnel

SGSNPLMNTE

PPP

GTP TunnelIPSec

TE

L2TP Tunnel

(Optional)

PLMN SGSN GGSN

IP

Packet DataNetwork

PPP

PPP

GTP Tunnel

TE

GRE TunnelPLMN SGSN GGSN

IP

Packet DataNetwork


411-5221-926 Standard 10.07 June 2006

Figure 3-8 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

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



SGSN GGSN

Create PDP Context Request For IP PDU type, mobile subscriber authentication 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

GTP Tunnel Established

(PDP Type = IP, APN, Protocol Configuration Options, etc.)

(End User Address, Protocol Configuration Options, etc.)

Data Packets transferred between mobile and PDN



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

Figure 3-9 shows the support of the PPP PDU type on the GGSN.


411-5221-926 Standard 10.07 June 2006

Figure 3-9 IP/PPP sessions for PPP PDU type

GGSN

PPPIP

GTP Tunnel

IPSec Tunnel

IPSec

Packet DataNetwork

TE

GTP Tunnel

PPP

IP

GTP Tunnel

PPPIP

L2TP TunnelPrivate Data

Network

PLMN

SGSN

SGSN

SGSN

TE

TE

Private DataNetwork

(Optional)

GRE TunnelGTP Tunnel

PPP

IP

TE

Private DataNetwork

SGSN



For PPP sessions terminated on the GGSN, the GTP tunnel must be set up before Link Control Protocol (LCP) negotiation for the PPP session. Figure 3-10 summarizes the PDP context activation procedure for PPP PDU type.

Figure 3-10 GTP tunnel setup for PPP PDU type

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

SGSN GGSN

Create PDP Context Request



(PDP Type = PPP, APN, etc.)

(Protocol Configuration Options, etc.)

MS

LCP Negotiation

LCP Authentication (if required)

NCP Negotiation (includes Address Allocation)



411-5221-926 Standard 10.07 June 2006

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

GTP-U sequence numbersThe 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 ModeThe 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 UsernameThe 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 discoveryIn 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


411-5221-926 Standard 10.07 June 2006

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 flagIMS 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 ParametersNortel 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 IndicationIn 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 3Single 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.


411-5221-926 Standard 10.07 June 2006

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 membershipThe 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 VPNWhen 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, 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 that includes the profiles and characteristics provisioned in the new VPN instead of the existing Access Group.


411-5221-926 Standard 10.07 June 2006

Figure 3-11 APN configuration for Single APN

Figure 3-12 APN configuration with new VPN Profiles



Membership = Access Group

APN

Account

TemplateSubscriber


ProfileToD

Profile

DHCP Profile RADIUS Profile DNS NBNS



Membership = VPRN Member

APN

Account

TemplateSubscriber


ProfileToD

Profile

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.

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

Table 3-2 DHCP Profile interaction between existing Access Group and new VPN

DHCP Profile in existing Access Group

DHCP Profile in new VPN

Action taken for the PDP Session

None Configured as DHCP Client

This configuration is not allowed. The DHCP Profile in new VPN is ignored and PDP session setup continues.

None Configured as DHCP Relay Agent

This configuration is not allowed. The DHCP Profile in new VPN is ignored and PDP session setup continues.

Configured as DHCP Client

None DHCP Client configuration in existing Access Group is used.



DHCP Client configuration in new VPN is used.


Configured as DHCP Relay Agent

This configuration is not allowed. This PDP session is rejected.


None DHCP Relay Agent configuration in existing Access Group is used.



DHCP Client configuration in new VPN is used.



This configuration is not allowed. This PDP session is rejected.


411-5221-926 Standard 10.07 June 2006

• 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 ServicesThe 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 subscriptionThe 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 tunnelingA 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.


411-5221-926 Standard 10.07 June 2006

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

Table 3-3 L2TP-GTP Tunnel Switching configuration interaction for Single APN

PDU type Single APN Scenario

Outbound Tunneling Provisioning via SCS GUI

No Layer 2 Tunneling

Tunnel via L2TP (LAC)

Dynamic L2TP VPN

The Tag of Tunnel

attribute is not 0

The Tag of tunnel attribute is 0

GGSN with provisioned

L2TP tunnel

GGSN without

(individual) provisioned

L2TP tunnel

IP PDU type Tunnel attributes are

returned from the RADIUS Server.

This PDP session is rejected.

L2TP-GTP tunnel

switching uses

provisioned L2TP tunnel.

L2TP-GTP tunnel

switching uses returned

L2TP attributes.

L2TP-GTP tunnel

switching uses


L2TP-GTP tunnel


L2TP attributes.a

a. LNS must be configured with LAC Host Name “l2tp-host”. GGSN using “l2tp-host” in Dynamic L2TPVPN mode, when L2TP tunnel does not pre-configured.

No Tunnel attribute is returned from the RADIUS Server.

The wireless ISP model is used for this PDP context.

L2TP-GTP tunnel

switching uses


This PDP context is rejected.

PPP PDU type

Tunnel attributes are

returned from the RADIUS Server.

This PDP session is rejected.

L2TP-GTP tunnel

switching uses


L2TP-GTP tunnel


L2TP attributes.

L2TP-GTP tunnel

switching uses


L2TP-GTP tunnel

switching uses returned L2TP tunnel.

No Tunnel attribute is returned from the RADIUS Server.

The wireless ISP model is used for this PDP context.

L2TP-GTP tunnel

switching uses


This PDP context is rejected.



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 SupportNortel 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 AccountingCertain 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 NTP 411-5221-928, Nortel GGSN RADIUS Interface Guide for details of the extensions to GTP Accounting and RADIUS Accounting billing records.

Aggregation Access Point NameThe 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


411-5221-926 Standard 10.07 June 2006

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 3Visiting 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 ProfileWhen 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 authenticationThe 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 authenticationThe 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-


411-5221-926 Standard 10.07 June 2006

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.

Refer to NTP 411-5221-928, Nortel GGSN RADIUS Interface Guide for supported RADIUS attributes. Unsupported RADIUS attributes are ignored when they are received on the GGSN.

Anonymous RADIUS authenticationAnonymous 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 and the string ‘umts’ 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.

For PPP PDU type, if the username and password are not provided in the PCO, the APN is checked during PAP / CHAP negotiations to determine if anonymous authentication is activated. If it is, the username and password are obtained from the corresponding fields in the APN.

IP address allocation 3The 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.

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

RADIUS static IP address allocationThe 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 allocationThe 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.


411-5221-926 Standard 10.07 June 2006

DHCPThe 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 ClientThe 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-39. 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 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




(PDP Type = IP, APN, Protocol Configuration Option,etc.)

(End User Address, Protocol ConfigurationOptions, etc.)

DHCP Server

DHCPDISCOVER

DHCPOFFER

DHCPREQUEST

DHCPACK

GTP Tunnel Setup:• Authentication (if required)• IP Address allocation = DHCP• DHCP Profile ==> Name Pool=CDE

Data Packets transfer between mobile and PDN

(IP Address from pool with User Class = CDE)

(User Class = CDE)


411-5221-926 Standard 10.07 June 2006

DHCP Relay AgentThe 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 shows the DHCP Relay Agent message flow.



Figure 3-14 GGSN DHCP Relay Agent message flow

DHCP Relay Agent addressIn 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 and GRE 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).

SGSN GGSN




DHCP Server

DHCPDISCOVER

DHCPOFFER

DHCPREQUEST

DHCPACK


MS

Update PDP Context Request

Update PDP Context Response

GTP Tunnel Setup:Authentication (if required)

IP address is allocatedat the DHCP Server

(End User Address=0.0.0.0)

End User Address


411-5221-926 Standard 10.07 June 2006

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

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 poolThe 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 addressIf 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 3The 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.


411-5221-926 Standard 10.07 June 2006

Table 3-4 specifies the billing features supported by each accounting mechanism.

GTP accounting 3GTP 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.

Table 3-4 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



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


411-5221-926 Standard 10.07 June 2006

Figure 3-15 GGSN Accounting

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 billingFor 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 summarizes regular billing on the GGSN and its functions.

GGSNAccounting

Regular Billing Hot Billing



Figure 3-16 GGSN regular billing

Hot billingAnother 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 shows the hot billing accounting option and its functions.

GGSNAccounting

Regular Billing Hot Billing• Accounting records

generated

• Accounting records enter buffer queue

• Accounting records converted into ASN.1 format

• Accounting records transferred to CGFs


411-5221-926 Standard 10.07 June 2006

Figure 3-17 GGSN hot billing

GTP’ protocolThe 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”).

GGSNAccounting

Regular Billing• Accounting records

generated

• Accounting records enter buffer queue



Hot Billing• Accounting records

generated





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


411-5221-926 Standard 10.07 June 2006

APN such as setting or un-setting tariff boundaries take effect in all circumstances, even for active PDP sessions.

Accounting record generationThe 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-58).

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 generationThe 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 SGSN Change Partial Billing is not enabled, when the SGSN address changes 3 times (where 4 SGSN addresses are accumulated) for that PDP context, a G-CDR is generated with cause of Record Closing field set to Max Change Condition.

• A partial accounting record is generated when there is an SGSN address change for the PDP context accompanied by a fallback from GTP version 1 to GTP version 0 or a fallforward from GTP version 0 to GTP version 1.

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


411-5221-926 Standard 10.07 June 2006

• 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 container generationThe 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.

G-CDR identificationThe 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 storageThe 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.


411-5221-926 Standard 10.07 June 2006

Manual G-CDR file retrievalG-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 descriptionThe 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. See Appendix B, “Detailed Protocol Information” for a description of the file naming convention and contents.

Automated Accounting Record TransferAn 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 TransferThe following table explains the interaction between the automated transfer and the existing CLI command used for initiating the G-CDR transfer.

Table 3-5Interaction between automatic and manual G-CDR transfer

Automated G-CDR Transfer Setting

G-CDR Transfer Status

Trigger(s) Action

Disabled No transfer in progress

CLI command “gtpbill disksend allow”

Start transfer of G-CDRs from disk

CLI command “gtpbill disksend off”

No change in transfer status

Transfer in progress due to CLI command




Stop transfer of G-CDRs from disk

Enabled with “Always On” set

Any state CLI command “gtpbill disksend allow” or “gtpbill disksend off”

Disallowed with a CLI error message

—sheet 1 of 2—


411-5221-926 Standard 10.07 June 2006

Interaction with FTP Pull BillingFTP 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.

Enabled with a configured start & stop time

No transfer in progress


Start transfer of G-CDRs from disk



Transfer in progress

due to start time trigger


Disallowed with a CLI error message


Stop transfer of G-CDRs from disk. 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 progress

due to CLI command




Stop transfer of G-CDR from disk. 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.

Table 3-5Interaction between automatic and manual G-CDR transfer (continued)

Automated G-CDR Transfer Setting

G-CDR Transfer Status

Trigger(s) Action

—sheet 2 of 2—



Interaction with G-CDR AuditingIf 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 AuditingG-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 descriptionThe 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 contentsThe 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.


411-5221-926 Standard 10.07 June 2006

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

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


411-5221-926 Standard 10.07 June 2006

RADIUS Accounting 3The 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 NTP 411-5221-928, Nortel GGSN RADIUS Interface Guide 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 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.

• 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


411-5221-926 Standard 10.07 June 2006

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-6Alternate Radius Interim Accounting Time Limit examples

Apn profile(Radius Accounting is enabled)

IMSI profile Billing for roamers (GTP Tunnel)

Resulting value used for RADIUS Interim Time Limit

Comments

Enable Radius Interim Messages checkbox

Enable Alternate Radius Interim Acct. Time limit

Alternate Radius Interim Acct. Time Limit

Time Limit(Default Billing Details)


Time Limit


Time Limit

selected unselected greyed out 60 IMSI profile is not associated with the APN profile or mobile does not match profile.

partial billing for roamers is not enabled or mobile is not a roamer

60 APN value is used since IMSI & Roamer do not apply.

selected selected 100 60 100

selected selected 0 60 0*



RADIUS Accounting record storageThe 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.

selected unselected greyed out 60 IMSI profile is not associated with the APN profile or mobile does not match profile

40 20 20 APN default value is overridden by Roamer default time limit. Alt. time 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 alt. time is enabled.selected selected 100 60 0 20 0*

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 because alt. time is enabled on the APN.

selected selected 100 60 0 10 40 20 0*

* 0 means there will be no Radius Interim Accounting Records generated due to time limit.


411-5221-926 Standard 10.07 June 2006

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 3Fault 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 3Content 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. See “G-CDR Record Format” for details. 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.


411-5221-926 Standard 10.07 June 2006

Partial billing for roamers 3Partial 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 3Tunneling 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 switchingFor 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 PDUFor 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 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.


411-5221-926 Standard 10.07 June 2006

Figure 3-18 GTP tunnel setup in GTP-L2TP tunnel switching for PPP PDU type

Tunnel switching for IP PDUIf 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

SGSN GGSN




(PDP Type = PPP, APN, etc.)

(Protocol Configuration Options, etc.)

MS

LCP Negotiation

LCP Authentication (if required)

IPCP Negotiation (including Address Allocation)


*SCCRQ

LNS

*SCCRP

*ZLB ACK*SCCCN

L2TP Tunnel established

ICRQICRPICCN

L2TP Session established

*Only required if the L2TP tunnel is not already established.



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.

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


411-5221-926 Standard 10.07 June 2006

Figure 3-19 GTP tunnel setup in GTP-L2TP tunnel switching for IP PDU type

SGSN GGSN




(PDP Type = IP, Protocol Configuration Options, etc.)

(with allocated mobile address)

MS


*SCCRQ

LNS

*SCCRP

*ZLB ACK*SCCCN

L2TP Tunnel established

ICRQICRP

L2TP Session established

*Only required if the L2TP tunnel is not already established.

with proxy LCP andauthentication info

LCP re-negotiation**

PAP auth request**

LCP auth result (=pass)(carried within L2TP)

**Only required if LCP re-negotiation is performed from the LNS

ICCN

IPCP Negotiation

(carried within L2TP)



Outgoing to intranet using IPSec tunnelFor 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 configurationAn 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.


411-5221-926 Standard 10.07 June 2006

Figure 3-20 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

Figure 3-21 shows the message flow for setting up a GTP tunnel with outgoing IPSec tunnel to the remote private Intranet.

PrivateIntranetPLMN

Nortel GGSN

IPSec Tunnel

SCSServer

CPE



Figure 3-21 GTP-IPSec tunnel message flow

GGSN VPRN configurationA 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. It can be optionally configured as an IPSec tunnel as shown in Figure 3-23 or an ATM 1483/R VC as shown in Figure 3-24. 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.

SGSN GGSN




(PDP Type = IP/PPP, etc.)

PPP (LCP/Authentication/NCP negotiation) - for PPP PDU type ONLY


Intranet

IPSec Tunnel Established

IPSec tunnel is established when configured by SCS


411-5221-926 Standard 10.07 June 2006

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

Figure 3-23 GGSN VPRN to Intranet through IPSec tunnel

PrivateIntranet

PLMN

Nortel IPSec Tunnel

GGSN

IPSec TunnelGGSN

GGSN

IPSec Tunnel

SCSServer

Access Connection

CPE

PrivateIntranet

PLMN

Nortel IPSec Tunnel

GGSN

IPSec TunnelGGSN

GGSN

IPSec TunnelCPE

IPSec Tunnel

SCSServer



Figure 3-24 GGSN VPRN to Intranet through ATM 1483/R VC

Outgoing to Internet and Intranet using GRE tunnelGRE Wireless ISP modelThe 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 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.

PrivateIntranet

PLMN

Nortel

IPSec Tunnel

GGSN

IPSec Tunnel

GGSN

GGSN

IPSec Tunnel

SCSServer

Router

ATM/

Access NetworkFrame Relay

ATM 1483/R VC


411-5221-926 Standard 10.07 June 2006

Figure 3-25 Wireless ISP GRE configuration

GRE VPN modelThe 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 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.

PLMN

Nortel GGSN

GRE Tunnel

SCSServer

Private

Intranet

GRE Tunnel PublicInternet



Figure 3-26GRE VPN configuration

Figure 3-27 shows the message flow for setting up a GTP tunnel with outgoing GRE tunnel to the remote private Intranet.

PrivatePLMN

Nortel

CPE

GGSN

GRE Tunnel

SCSServer

Intranet


411-5221-926 Standard 10.07 June 2006

Figure 3-27 GTP-GRE tunnel message flow

Outgoing to Internet and Intranet using VLAN TaggingVLAN Tagging provides the logical differentiation of Ethernet frames that share the same physical Ethernet connection.

VLAN Wireless ISP modelThe 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 shows the VLAN tagging between the GGSN and remote Internet and Intranet.

SGSN GGSN




(PDP Type = IP/PPP, etc.)

PPP (LCP/Authentication/NCP negotiation) - for PPP PDU type ONLY


Intranet

GRE Tunnel EstablishedGRE tunnel is establishedwhen configured by SCS GUI



Figure 3-28 VLAN Wireless ISP configuration

VLAN VPN modelVLAN 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 shows the VLAN tagging between the GGSN and remote Intranet.

Private

PLMN

Nortel

CPE

GGSN

VLAN tagged

SCSServer

Intranet

RouterEthernet

Public Internet


411-5221-926 Standard 10.07 June 2006

Figure 3-29 VLAN VPN configuration

Outgoing to Intranet via MPLSMPLS 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.

Private

PLMN

Nortel

CPE

GGSN

VLAN tagged

SCSServer

Intranet

RouterEthernet



• 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

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.

Private

PLMN

Nortel

CPE

GGSN

SCSServer

Intranet

MPLS

Backbone


411-5221-926 Standard 10.07 June 2006

Quality of Service (QoS) 3The 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 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

Mapping of DSCP marking to TOS valueGGSN Differentiated Service uses the recommended mappings of DSCP to TOS value referenced in RFC 2474 and RFC 2597.

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

AF13 00111000

AF12 00110000

—sheet 1 of 2—

UDP IPGTPIPPayload

TOS byte in IP header

GTP Bearer Packet

Marked based on GGSNMarked based on DiffServQoS Profile information.Marking IP service.


411-5221-926 Standard 10.07 June 2006

Uplink data packet QoSThe 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.

AF11 00101000

DE 00000000

Table 3-7 Mapping of DSCP marking to TOS value (continued)

DSCP TOS Value

—sheet 2 of 2—



Downlink data packet QoSAll 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 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 QoSControl 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 ClassesThe 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)


411-5221-926 Standard 10.07 June 2006

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

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 3There 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 AvailabilityGi interface availability has the following capabilities:

• ISP Operational State monitoring

• APN Administrative State control

Table 3-8 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 -



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


411-5221-926 Standard 10.07 June 2006

are rejected according to the Redirect Response Cause set for the GTP Tunnel (see “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 interactionThe ISP Operational State and APN Administrative State work together as shown in Table 3-9.

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-9ISP Operational State and APN Administrative State interaction

ISP Monitoring Redirect

APN Administration State

ISP Operational State

Volume Based Billing

PDP Context Creation

Enabled UP UP Enabled Enabled

DOWN Disabled for all PDP contexts associated with the ISP

Disabled for ALL APNs associated with the ISP

DOWN UP Enabled Disabled for the specific APN

DOWN Disabled for all PDP contexts associated with the ISP

Disabled for ALL APNs associated with the ISP

—sheet 1 of 2—



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

Disabled UP UP Enabled Enabled

DOWN Enabled Enabled

DOWN UP Enabled Disabled for the specific APN

DOWN Enabled Disabled for the specific APN

Table 3-9ISP Operational State and APN Administrative State interaction

ISP Monitoring Redirect

APN Administration State

ISP Operational State

Volume Based Billing

PDP Context Creation

—sheet 2 of 2—


411-5221-926 Standard 10.07 June 2006

GGSN behavior with and without the overload control mechanism is illustrated in Figure 3-32.

Figure 3-32 GGSN overload control

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

Time

Serv

iced

Inpu

t

System Output without Overload Control

System Outputwith Overload Control Overload Entry Point

Overload Exit Point



Figure 3-33 CPU overload control message flow

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

Table 3-10 CPU overload level descriptions

CPU Overload Level

Entry Hysteresis

Exit Hysteresis

Entry Threshold

Exit Threshold

Description

Normal This is an informational log which indicates that the switch is normal and not under overload conditions.

—sheet 1 of 2—


CPU0 Overloaded

Monitor CPUOccupancy

Generate Alarm

Create PDP Context Response(Cause = No Resources available)

GGSNSGSN SCS


411-5221-926 Standard 10.07 June 2006

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 attaining 83% average CPU Occupancy. Any transitions to other levels follow the Entry Hysteresis and Exit Hysteresis.

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

Table 3-10 CPU overload level descriptions (continued)

CPU Overload Level

Entry Hysteresis

Exit Hysteresis

Entry Threshold

Exit Threshold

Description

—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 controlThe 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 controlMemory 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


411-5221-926 Standard 10.07 June 2006

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 shows the message flow for memory overload control.

Figure 3-34 Memory overload control message flow

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.


Generate Alarm at LEVEL1Create PDP Context Response

GGSNSGSN SCS

Generate Alarm at LEVEL2 or LEVEL3

System Memory Overloaded

Monitor System Memory

Additional Memory Check

Create PDP Context RequestMonitor System Memory


(Cause = No Resources Available)

(Cause = Request Accepted)

Occupancy

Occupancy



Memory overload levels are described in Table 3-11.

Table 3-11 Memory overload level descriptions

Memory Overload Level

Entry Hysteresis

Exit Hysteresis

Entry Threshold

Exit Threshold

Description

Normal This is an informational log which indicates that the switch is normal and not under memory overload conditions.

Level 1 4 8 100 free MB 110 free MB This level is not service affecting. When the Free Memory is below 100 MB this alarm is raised after 4 minutes of crossing 100 MB Memory. This overload condition is exited after 8 minutes of crossing 110 Free MB memory. Any transitions to other levels follow the Entry Hysteresis and Exit Hysteresis.

Level 2 3 8 70 free MB 80 free MB When the Free Memory is below 70 MB this alarm is raised after 3 minutes of crossing 70 MB Memory. This overload condition is exited after 8 minutes of crossing 80 Free MB memory. Any transitions to other levels follow the Entry Hysteresis and Exit Hysteresis.

Level 3 2 8 50 free MB 60 free MB When the Free Memory is below 50 MB this alarm is raised after 2 minutes of crossing 50 MB Memory. This overload condition is exited after 8 minutes of crossing 60 Free MB memory. Any transitions to other levels follow the Entry Hysteresis and Exit Hysteresis.


411-5221-926 Standard 10.07 June 2006

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-12 describes CMC Memory fragmentation block sizes.

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

Table 3-12 CMC memory fragmentation block sizes

Memory Overload Level

Entry Block Size

Exit Block Size

Description

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.





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


411-5221-926 Standard 10.07 June 2006

For information on SSL installation and certificate generation, refer to NTP 411-5221-927, GPRS/UMTS Nortel GGSN Provisioning Procedures.

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


411-5221-926 Standard 10.07 June 2006

PDP context Activation AttemptsHealth 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 3The 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 three 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.

The GeoZone service and the GPDN Range Checking feature are only supported with CTP versions 1 and 2. Newer versions of prepaid are not enabled for GeoZone and GPDN Range Checking.

Real-time charging serviceThe 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.

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


411-5221-926 Standard 10.07 June 2006

Figure 3-35 GGSN real-time charging service message flow for IP PDU type

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.

SGSN GGSN





real-time

Mid-call real-time charging request

Initial real-time charging response

Mid-call real-time charging response

Initial real-time charging Request

To renew usage with real-timecharging server


IP Address Allocation is done afterthe GPRS Service Response.

User authentication is done beforethe GPRS Service Request.

charging



Figure 3-36 GGSN real-time charging service message flow for PPP PDU type

In both scenarios, from this point in the PDP session, the coupons will be managed as needed with reauthorization requests until termination.

Mid-call reauthorizationThe 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 chargingreal-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.

SGSN GGSN




PPP LCP/Authentication/IPCP negotiation


Real-time charging server

Mid-call real-time charging request

Initial real-time charging response

Mid-call real-time charging response

Initial real-time charging request

To renew usage with real-time


User Authentication and IP Ad-dress Allocation are done beforethe GPRS Service Request.


411-5221-926 Standard 10.07 June 2006

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

TriggersReal-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 handlingIf 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 versionsThe first version is the Basic Single-Coupon service which uses Card Telephony Protocol (CTP) protocol version 1 to provides a simple real-time charging service. The second version is the Enhanced Single-Coupon service which uses CTP protocol version 2 to add QoS and Content-Based Billing (CBB) information to the billing reports. The third version is the Multi-Coupon 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 couponCTP 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 couponRated 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


411-5221-926 Standard 10.07 June 2006

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

TriggersTriggers 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 returnIn 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 alloted 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 IDsCoupon 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


411-5221-926 Standard 10.07 June 2006

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-13CBB Policy Merge Matrix

# Service Package Type

Tariff Coupons

CBB Coupons from Service Package

CouponTotal<=40

Merged Coupons

Expected Behavior

1 RADIUS 6 7 8 0 1 2 3 4 5

Marked as Request on Service Start

Y 0 1 2 3 4 5 6 7 8

CBB Coupons are available in the RADIUS service package. CBB coupon list is less than 40, so the Tariff coupons are added to the merged list.

2 RADIUS 6 7 8 0 1 2 3 4 5

Marked as Request on Usage

Y 6 7 8 CBB coupons are marked as request on usage; therefore, only the Tariff coupons are included in the merged list.



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

3 None 0 1 2 None Y 0 1 2 No CBB Coupons are available via service packages. Only Tariff coupons are present in the merged list.

4 QoS None 0 1 2 Y 0 1 2 Available CBB coupon list count is < 40; however, no Tariff coupons available to include in the merged list.

5 QoS

Subscriber

Template

41 42 0 - 39


N 0 - 39 Multiple CBB Coupon lists available via the service packages. QoS has the highest order of precedence 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 0 1 2 0 1 2


Y 0 1 2 CBB Coupons and the Tariff coupons are duplicates. Duplicate coupons are excluded from the merged list.

7 Subscriber Template

0 1 2 1 2


0

Marked as Request on Usage

Y 1 2 CBB Coupon “0” is marked as request on usage. Even though this coupon is included in the Tariff coupon list, it is excluded for the merged list. Coupons marked as request on usage are added to the merged list.

Table 3-13CBB Policy Merge Matrix

# Service Package Type

Tariff Coupons

CBB Coupons from Service Package

CouponTotal<=40

Merged Coupons

Expected Behavior


411-5221-926 Standard 10.07 June 2006

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

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

InternetGGSN

Yahoo

Amazon

SGSN

Subscriber

Gn Gi

Top-Up

real-time

Server

charging

server



real-time charging server after the account has been topped up to cause coupons to be cleared from redirection and obtain balance.

Figure 3-38CTPv3 Redirection Messaging

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

GGSN Real-time charging server

Service Request (reauthorization)

Service Response (Denied, Redirection URI)

1

2

3

Reauthorization Command

Reauthorization Command ACK4

Service Request (reauthorization)

5

Reauthorization Command


411-5221-926 Standard 10.07 June 2006

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 ChangeThe 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 provides an example of the new tariff change triggers and include reasons within the GPRS service messages.


411-5221-926 Standard 10.07 June 2006

Figure 3-39 Tariff Time Change message flow

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.

GGSN

Tariff Time Change

Real-time

1 GPRS Service Request message - Initial Auth Request

2 GPRS Service Response message - Initial Auth Response

3 GPRS Service Request message - Re-auth Request

4 GPRS Service Response message - Re-auth Response

5 GPRS Service Request message - Final Report

Tariff Time Change

charging server



GeoZone serviceGeoZone 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 versions 1 and 2. Newer versions of real-time charging are not enabled for GeoZone.

GPDN Range CheckingThis feature gives the GGSN the ability to always send the SGSN IP address to RTCSs via CTPv1 & CTPv2 for all subscribers, regardless of whether or not it has received CGI information for a given subscriber. This feature is activated by using a CLI command. By default, this feature is disabled.

WAP serviceThe 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 activationTo 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


411-5221-926 Standard 10.07 June 2006

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 typeFor 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 typeFor 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 ServerFigure 3-40 through Figure 3-42 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-40WAP service message flow for IP PDU type in Service Mode

SGSN GGSN




For IP PDU type, authenticationand IP address allocation is done.The method of authentication (ifrequired) and the method of IPaddress allocation can be specifiedby configuration.

RADIUS START message(MSISDN, Mobile’s IP Address,

Update PDP Context RequestRADIUS INTERIM-UPDATE message



GGSN IP Address, Charging IDUser Name, APN, QoS,....)

(MSISDN, Mobile’s IP Address,GGSN IP Address, Charging IDUser Name)

RADIUS START Reply

RADIUS INTERIM-UPDATE Reply

ApplicationServer

RADIUS STOP Reply

RADIUS STOP messageDelete PDP Context Request

Delete PDP Context Response


411-5221-926 Standard 10.07 June 2006

Figure 3-41WAP service message flow for IP PDU type in Session Mode

SGSN GGSN


Create PDP Context ResponseGTP Tunnel Established

For IP PDU type, authenticationand IP address allocation are donefor subscribers.The method of authentication (ifrequired) and method of IPaddress allocation are specified byconfiguration.

RADIUS START message(MSISDN, Mobile’s IP Address,

Update PDP Context RequestRADIUS INTERIM-UPDATE message



GGSN IP Address, Charging IDUser Name, APN, QoS,...)

(MSISDN, Mobile’s IP AddressGGSN IP Address, Charging IDUser Name)

RADIUS START Reply


ApplicationServer

RADIUS STOP Reply

RADIUS STOP messageDelete PDP Context Request




Figure 3-42WAP service message flow for PPP PDU type

Policy merging 3Policy 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 GGSN




ApplicationServer

RADIUS START message

Update PDP Context Request RADIUS INTERIM-UPDATE request



PPP session up between MS and GGSN

PPP session termination

PPP session negotiation

(MSISDN, Mobile’s IP Address,GGSN IP Address, Charging IDUser Name)

(MSISDN, Mobile’s IP AddressGGSN IP Address, Charging IDUser Name,....)

RADIUS START Reply


Delete PDP Context Request


RADIUS STOP request(MSISDN, Mobile’s IP AddressGGSN IP Address, Charging IDUser Name)

RADIUS STOP Reply

::

For PPP sessions terminatingon GGSN, authentication andIP address allocation are donefor the subscribers.


411-5221-926 Standard 10.07 June 2006

SGSN Grouping 3When 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-14 shows the logic to derive the SGSN Group Identifier.

Table 3-14Derived SGSN group identifier logic

With “SGSN Grouping” enabled

Derived SGSN Group


Use the SGSN Group Identifier of the matching entry



Use the SGSN Group Identifier of the default entry


Use “No Group” (0)



Lawful Interception (LI) 3This 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 shows the Nortel implementation of the Lawful Interception model.


411-5221-926 Standard 10.07 June 2006

Figure 3-43Nortel implementation of Lawful Interception

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

AF (GGSN)

DF2/DF3ADMF

LEALEA

... CFCF

LICP/LIAP

LIG

provisioning dataintercepted data



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) 3Traffic 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 modeThis 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 modeThis 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.


411-5221-926 Standard 10.07 June 2006

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.



Network deployment models 4Overview 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 4The 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

4-2 Network deployment modelsNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

Table 4-1 summarizes the GGSN configuration options associated with each network model.

Table 4-1 Network model configuration options

Configuration option

Wireless ISP model with traditional APN

Wireless ISP model with Aggregation APN

L2TP VPN model VPN variants (including IPSec VPN, GRE VPN, ATM VPN, VLAN VPN, MPLS VPN, and GGSN VPRN models

Access mode Transparent or non-transparent

Transparent or non-transparent



Subscriber authentication

RADIUS RADIUS LNS RADIUS

PDU type IP or PPP IP or PPP IP or PPP IP or PPP

PPP session Terminated to GGSN

Terminated to GGSN

Created between GGSN and LNS for IP PDU and passing through for PPP PDU.

Terminated to GGSN

Gi interface Raw IP Raw IP L2TP or L2TP over IPSec

IPSec, GRE tunnel, VLAN, or ATM PVC

IP address allocation

Address allocation by GGSN


Address allocation by remote Intranet


IP address domain

Public IP address from operator’s domain or Private IP address from external NAT Server

Public IP address from operator’s domain or Private IP address from external NAT Server

Public or private IP address from operator’s domain

Public or private IP address from operator’s domain

IP address allocation methods

Internal address pools, DHCP or RADIUS static/dynamic address allocation

Internal address pools, DHCP Client or RADIUS static/dynamic address allocation

IP address is allocated at the LNS, not on the GGSN.

Internal address pool, DHCP or RADIUS static/dynamic address allocation

—sheet 1 of 3—

Network deployment models 4-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


IP Services Applied to the data packets on the Gi interface

Applied to the data packets on the Gi interface

Not supported Applied to the data packets on the Gi interface

Prepaid Service

Supported based on configuration




RADIUS Accounting





WAP Service Supported via RADIUS Accounting or Application Profile

Supported via RADIUS Accounting

Not supported Supported via RADIUS Accounting

QoS Service Supported based on configuration

Supported on Gn interface based on configuration

Supported on Gn interface based on configuration


IP Multicast Supported based on configuration and not supported for GRE and VLAN access interface

Not supported Not supported Not supported

End to End Protocols

IP IP IP/PPP for IP PDU and PPP for PPP PDU

IP

Roamer Partial Billing





Single APN Supported based on configuration

Supported for Prepaid Subscription and IP Services



Table 4-1 Network model configuration options (continued)





—sheet 2 of 3—


411-5221-926 Standard 10.07 June 2006

Tariff Based Billing





Table 4-1 Network model configuration options (continued)





—sheet 3 of 3—



Wireless ISP model 4The 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.


411-5221-926 Standard 10.07 June 2006

Figure 4-1 Wireless ISP network model

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.

Internet GGSN

PLMN

SGSN

GTP tunnel

DNS (APN

DNS (ISP

CGF

FTP OAM

resolution)

service)

SCS



Figure 4-2 Wireless ISP GRE access

Wireless ISP VLAN access 4In 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.

Internet

GGSN

PLMN

SGSN

GTP tunnel

DNS (APN CGF

FTP

OAMresolution)

SCS

GRE Tunnel

Intranet/ISP


411-5221-926 Standard 10.07 June 2006

Figure 4-3 Wireless ISP VLAN access

L2TP VPN model 4In 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.

GGSN

PLMN

SGSN

GTP tunnel

DNS (APN CGF

FTP

OAMresolution)

SCS

VLAN tagged

Intranet

Internet



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

Intranet/ISP

Internet

GGSN

PLMN

SGSN

GTP tunnel

DNS (APN CGF

FTP

OAMresolution)

SCS

LAC

LNS

L2TP tunnel

L2TP over IPSec (optional)

Firewall

*AAA

*AAA - Authorization/Authentication/Accounting


411-5221-926 Standard 10.07 June 2006

VPN variants 4The 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 modelThe 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-5IPSec VPN network model

GRE VPN modelThe 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.

This network model provides both transparent and non-transparent 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.

Internet

GGSN

PLMN

SGSN

GTP tunnel

DNS (APN CGF

FTP

OAMresolution)

SCS

IPSec Tunnel

Intranet/ISP


411-5221-926 Standard 10.07 June 2006

Figure 4-6 GRE VPN network model

ATM VPN modelThe 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.

This network model provides both transparent and non-transparent 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.

Internet

GGSN

PLMN

SGSN

GTP tunnel

DNS (APN CGF

FTP

OAMresolution)

SCS

GRE Tunnel

Intranet/ISP



Figure 4-7 ATM VPN network model

VLAN VPN modelThe 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.

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.

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.

Internet

GGSN

PLMN

SGSN

GTP tunnel

DNS (APN CGF

FTP

OAMresolution)

SCS

ATM PVC

Intranet/ISP


411-5221-926 Standard 10.07 June 2006

Figure 4-8 VLAN VPN network model

GGSN VPRN modelThe 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

GGSN

PLMN

SGSN

GTP tunnel

DNS (APN CGF

FTP

OAMresolution)

SCS

VLAN tagged

Intranet/ISP



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

MPLS VPN modelA 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.

PLMN

SGSN

GTP tunnel

DNS (APN CGF

FTP

OAMresolution)

SCS

IPSec Tunnel

GGSN

Intranet/ISP

GGSN

GGSN

VPRN


411-5221-926 Standard 10.07 June 2006

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

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.

GGSN,

P

P

P

PE

PE

PE

acting asa PE

Site A

CE

Site B

CE

Site C

CE

Site DCE

SGSN

Mobile Subscribersbelonging to VPN Y

Mobile Subscribersbelonging to VPN X

MPLS Backbone

(in VPN X) (in VPN Y)

(in VPN Y)

(in VPN X)

P: Provider RouterPE: Provider Edge RouterCE: Customer Edge Router

RADIUS

RADIUS DHCP

DHCP



Wireless services deployment 4In 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 ServiceThe WAP service on the GGSN can be deployed in one of the two ways shown in Figure 4-11:

• 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-11 WAP service deployment models

Static RADIUS address allocation serviceFor 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-12 illustrates this configuration.

RADIUS Application

ApplicationApplicationWRAP

RADIUS RADIUS

RADIUS

GGSN

APN 1

APN 2

Server

Server

w/ RADIUS

w/o RADIUS

Server

Server

Account.ing

Accounting


411-5221-926 Standard 10.07 June 2006

Figure 4-12 Static RADIUS address allocation service deployment

Dynamic RADIUS address allocation serviceDynamic 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-13 illustrates the configuration for dynamic RADIUS address allocation service.

GGSNSGSN

GTP tunnel

DNS

GiGn PLMN

RADIUSAuthentication

ApplicationServer

Service Network

Server

RADIUSAccountingServer



Figure 4-13 Dynamic RADIUS address allocation service deployment

GGSNSGSN

GTP tunnel

GiGn Service PLMN Network

CGF

RADIUS

Application

Server

Server


411-5221-926 Standard 10.07 June 2006



IP services 5Overview 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 NTP 411-5221-927, GPRS/UMTS Nortel GGSN Provisioning Procedures.

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 Redirection

• Traffic Performance Optimizer (TPO) Interworking

• Content Filtering

5-2 IP servicesNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

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 5An 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 SCP is selected and applied to the PDP session. It is important to understand that the

IP services 5-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


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


411-5221-926 Standard 10.07 June 2006

• Service Redirect

• Policing

• Shaping

• Anti-Spoofing

• Diffserv Marking

• Policy Based Forwarding

• Content Filtering

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.

Firewall 5Firewalls 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 5The 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.


411-5221-926 Standard 10.07 June 2006

Figure 5-1 Policing parameters for single-rate three-color marker

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 Precedence

Red Yellow Green

CS7, CS6, EF, DE Drop/allow Drop/allow None

AF4, AF3, AF2, AF1

Drop/setting Drop/setting None/setting

Time

Traf

fic R

ate

Committed Rate

Committed Burst Size

Excess Burst Size

Green

Yellow

Red



Traffic Shaping 5Traffic 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).


411-5221-926 Standard 10.07 June 2006

Policy-Based Forwarding 5Policy-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 5Web 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.




Personal Content Portals 5A 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 5DiffServ 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.


411-5221-926 Standard 10.07 June 2006

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 5Anti-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 Redirection 5Note: 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 303 message (Status 303: 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 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 ModeThe WTP layer provides two optional abilities that need to be handled. Segmentation and Reassembly (SAR) and WTP Layer Concatenation.

Service Redirect Segmentation and Reassembly HandlingThe 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 303.

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


411-5221-926 Standard 10.07 June 2006

WAP Packet RatingThe 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).

Figure 5-2 WAP Redirection (Connection-Oriented and Connection-less calls)

Subscriber GGSN HTTP Gateway

WSP Get/PostURL=wap.yahoo.comTID = x

WSP Reply (Status 0x33)Location: www.topup.comTID = x

WSP Connect(connection-oriented only)

WSP Connect Reply(connection-oriented only)

WTP Ack(connection-oriented only)

WTP Ack(connection-oriented only)TID = x

WSP GetURL www.topup.comTID = x+1



Figure 5-3 WAP Redirection (Concatenated PDU example)


WTP Ack, WSP Get/PostURL=wap.yahoo.comAck TID=yGet TID = x


WTP Ack, WSP GetURL www.topup.comAck TID xGet TID = x+1

WSP ConnectTID=y

WSP Connect ReplyTID=Y

WSP Connect ReplyTid=y

WTP Ack, WSP GetURL www.topup.comAck Tid=yGet Tid= x+1


411-5221-926 Standard 10.07 June 2006

Figure 5-4 WAP Redirection (SAR Example)


WTP Segmented InvokesTID = x, Group 2

WTP InvokeTID=x, Group 1

WTP AckTID=x, Group 1


WTP Segmented InvokesTID = x, Group 3


WTP Segmented InvokeTID = x, Last Packet of message


WTP Ack(connection-oriented only)TID = x

WTP Ack, WSP GetURL www.topup.comAck Tid=yGet Tid= x+1



Content Based Billing 5Content 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 NTP 411-5221-928, Nortel GGSN RADIUS Interface Guide.

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.


411-5221-926 Standard 10.07 June 2006

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.

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


411-5221-926 Standard 10.07 June 2006

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

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

WAP filter overviewThe 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 overviewWAP 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/BearerWDP 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 servicesWSP 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.


411-5221-926 Standard 10.07 June 2006

WAP and MMSIn 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 filterThe 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.

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 comparision 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 5The 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.

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

Table 5-2 Application Level Events

Application Level Event Type Protocol

Email POP3

Email IMAP4

Email SMTP

Instant Message Wireless Village


411-5221-926 Standard 10.07 June 2006

For postpaid billing, a new version of CBB management extension (version 6) is introduced for GTP’ billing and a new version of CBB VSA (version 4) 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 triggersAn “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 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

IMAP4Send from Mobile APPEND

Receive from Mobile FETCH

Wireless Village over HTTP or WAP1.x

Send from Mobile Send Message Request

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

Event and Non-Event TrafficBased 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.


411-5221-926 Standard 10.07 June 2006

Figure 5-5 Generic CBB rating for event based billing

GGSN ServerMobile

Any non-event packets are countedagainst the default content type id and/or coupon id for the specific applicationprotocol. uplink and downlink volume us-age is counted separately based on theconfiguration for the specific applica-tion protocol.

TCP Connection Setup

Application message triggers start of event

CBB rating for application packets passing through GGSN for

}When a event is detected as one of theCBB supported events, CBB starts track-ing the event.The rating information for anevent is toggled to start counting the vol-ume (uplink and downlink) usage againstthe event specific content type id and/orcoupon id for the specific applicationprotocol. If “Event Completion” is disabled, the eventusage count is incremented for the contenttype id and/or decremented for coupon idbased on the configuration for the specificapplication protocol.

Application messages

Application message indicate eventcompletion (Successful or Failed)

}

Application message(s) exchangebut not event specific

Application message(s) exchangebut not event specific Once the event completion is detected, any

non-event specific application messagesexchange uplink and downlink packets arecounted against the default content type idand/or coupon id for volume usage.

}

Once an event is detected, all volumeusage (uplink and downlink) for subse-quent messages are counted againstthe content type id and/or coupon idconfigured for the specific applicationprotocol until the event completionmessage is detected.

:

:

::

:

:

::

::

When event completion is detected, if“Event Completion” is enabled, an eventis incremented for the content type idand/or decremented for the coupon id ifthe event is completed successfully forthe configured specific applicationprotocol.

}

Event Based Billing

Non

-eve

ntE

vent

Non

-eve

nt

User Login (Username and Password Exchange)

Application messages



Event completion optionalityAn 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 WSPPer-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 5Dynamic 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


411-5221-926 Standard 10.07 June 2006

• 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 ModificationThe 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 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-4CBB policy applied to context after CRF interactions

Current CBB policy assigned to context

Charging Rule Base Name from CRF

Charging Rule Definitions from CRF

Result CBB Policy assigned to 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 policy

CBB policy A None Current dynamic policy is deleted and replaced with CBB policy A

Dynamic policy

None rules 1, 2, 3 Rules 1, 2, 3 from CRF are merged with the current dynamic policy


Dynamic policy

CBB policy A rules 1, 2, 3 Current dynamic policy is deleted and replaced with a dynamic policy with rules of CBB policy A and rules 1, 2, 3



411-5221-926 Standard 10.07 June 2006

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 65 shows an example of a dynamic policy consisting of pre-configured CBB rules and dynamic rules ordered from highest to lowest precedence.

Figure 5-6Dynamic CBB policy

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

Rule 3

Rule 2

CBB Policy A Rule 2

CBB Policy A

CBB Policy A Rule 3

CBB Policy A Rule 1

Charging Rule 3

Charging Rule 2

Rule 1Dynamic CBB Policy

CBB Policy

From CRF

Charging Rule 2

Charging Rule 1

Assigned to Context

Charging Rule 3

Charging Rule 1

first in

last in

message

message

highestprecedence

lowestprecedence



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-7GGSN ISP logical configuration

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-8GGSN VPN Only Logical Deployment Configuration

VPN Only deployments must have the Content Filter Servers inside the routing domain of the VPN.

ISPGn ISPMobile SGSN

GGSNContent FilterServers

HTTP/WAPServers

Connection

Mobile SGSNContent FilterServers

HTTP/WAPServers

VPN

ISPGn ISP

GGSNConnection

VPN


411-5221-926 Standard 10.07 June 2006


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-9Content protocols

ISP security services 5This section discusses the GGSN mechanisms that provide security for Gn, Ga, Gi, and other ISP contexts as well as the Default ISP.

HTTP/WAP

TCP/UDP

IP IP IP

GTP-U GTP-U

UDP/IP

L2/L1 L2/L1

UDP/IP

L2/L1 L2/L1

TCP/UDP

HTTP/WAPFilter

Content Filter Server

Mobile SGSN Web ServerGGSN



ISP Node ServicesWhen 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 definitionSecurity 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.


411-5221-926 Standard 10.07 June 2006

Node services can be created, modified and applied by SCS users that have “ISP_Profile” privileges.

Security Policy exampleThe 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 PolicyFigure 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.


411-5221-926 Standard 10.07 June 2006

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 ServicesNode 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 are security policies. Thus the “Profile” panels in these screens are seldom used and generally reserved for future use, though they are functional.


411-5221-926 Standard 10.07 June 2006

Management Services 5Management 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 definitionRefer to “Security Policy definition” on page 5-31. 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 examplesThe 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.

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 ServicesSee “Application of Node Services” on page 5-34. Note that the SCS user must have “Device Owner” privileges to apply Management Services.

Traffic Performance Optimizer (TPO) Interworking 5This feature supports interworking with Bytemobile TPO. Other TPO vendor solutions should be considered separately.


411-5221-926 Standard 10.07 June 2006

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.



Figure 5-16Network with multiple GGSNs and multiple bytemobile TPOs

TPOs

GPRS/PLMN

Mobile Stations

Load Balancers

Packet Data Network

GGSNs

(Mandatory)

Loopback LoopbackBytemobile


411-5221-926 Standard 10.07 June 2006



IP routing 6Overview 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.

The dynamic routing protocols supported on the Gn, Gp, and Gi interfaces by the GGSN are:

• RIPv1

6-2 IP routingNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

• RIPv2

• OSPFv2

• BGPv4

• MPLS

• IS-IS

Wireless ISP model routing 6The 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 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

IP routing 6-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


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

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

GGSN

Gn

ISPGTP Tunnel

Gn

Gi

APN

APN

SGSN

Con

nect

ion

ISP

APNAPNAPN

Con

nect

ion

ISP

APNAPNAPN

SGSNSGSN

10.0.0.0

Internet

Con

nect

ion

ISP


411-5221-926 Standard 10.07 June 2006

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 6An 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 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 6The 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 6The 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) 6The 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 operationA 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.


411-5221-926 Standard 10.07 June 2006

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.

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 SignallingBased 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-DULDP 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-TERSVP-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-existenceRSVP 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.


411-5221-926 Standard 10.07 June 2006

MPLS ForwardingOnce 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 figure below gives an example of packet forwarding of the VPN traffic across the provider backbone.

Figure 6-2MPLS Packet Forwarding

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

Site ASite B

CE-BCE-B

PE-APE-B

P-N P-1

IGPLabel (PE-B)-y

BGPLabel (L1)

IPv4:10.1.1.1

IGPLabel (PE-B)-x

BGPLabel (L1)

IPv4:10.1.1.1

IGPLabel (PE-B)

BGPLabel (L1)

IPv4:10.1.1.1

Pop the IGP Label, and determinethe next hop from it. Then, pushthe appropriate IGP Label and

PE-A receives an IPv4 packet.Query the VRF for Site B:- get the IBGP next hop: PE-B- get the VPN label, L1Determine how PE-B can bereached: IGP Label PE-B.Push the VPN label, and thenthe IGP Label and forward to P-1.

PE-B receives a packet.Pop the IGP Label (terminates here)Pop the VPN Label (points to CE-B)Forward to CE-B

forward to the next hop.

(10.1.1.0/24)

pkt to 10.1.1.1

pkt to 10.1.1.1



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) ServiceThe 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 PoliciesIn 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-1Actions in EFEC policies

Actiona

a. A value of Yes/No for a parameter means that the parameter was specified (or not). A value of’-’ meansthat the user has no option to specify this value.

Description

EXP value

Tunnel Pref

Egress Router

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

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)


411-5221-926 Standard 10.07 June 2006

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 servicesThe 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 topologiesThe 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 supportOnly 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.

MPLS Management VPNIn 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.


411-5221-926 Standard 10.07 June 2006

OSPF-TE 6In 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 6Intermediate 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 dicover 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 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 configured at the ISP level

Level 1 IS-IS participation for an interface


SCS Configuration

Level 1 Yes No No choice for the user. Level 1 routing is the only available choice.

—sheet 1 of 2—


411-5221-926 Standard 10.07 June 2006

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

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.

Table 6-2 Configuration of IS-IS routing level for Interfaces (continued)

IS-IS Level configured at the ISP level



SCS Configuration

—sheet 2 of 2—



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

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


411-5221-926 Standard 10.07 June 2006

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

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

SGSN

DNS

PLMN

Service Network

NAS-IP Addr: 192.192.1.16Summary Route Advertisement Info:start addr: 192.1.1.1 mask: 24

GGSN Node: GGSN_3

NAS-IP Addr: 192.192.1.18Summary Route Advertisement Info:

GGSN Node: GGSN1_1

NAS-IP Addr: 192.192.1.17Summary Route Advertisement Info:start addr: 192.3.1.1 mask: 20

GGSN Node: GGSN_2

NAS-IP Addr: 192.192.1.18start addr: 192.5.1.1 mask: 24



RADIUS Node: RADIUS_1

Gi

Gn

start addr: 192.5.1.1 mask: 24


411-5221-926 Standard 10.07 June 2006

RADIUS static address allocationWhen 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 allocationWhen 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

Route redundancy 6The 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 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.

SGSN

DNS

PLMN

Service Network

DHCP profile_3:pool name = pool_3Summary Route Advertisement Info:start addr: 192.1.1.1 mask: 24

GGSN Node: GGSN_3

DHCP profile_1:pool name = pool_1Summary Route Advertisement Info:

start addr: 192.5.1.1 mask: 16

GGSN Node: GGSN_1

DHCP profile_2:pool name = pool_2Summary Route Advertisement Info:start addr: 192.3.1.1 mask: 24

GGSN Node: GGSN_2

pool name = pool_2start addr: 192.3.1.1 mask: 24



DHCP Node: DHCP_1

Gi

Gn


411-5221-926 Standard 10.07 June 2006

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 ECMPOn 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 6Proxy 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 be used between the GGSN and the layer 2 network. The router will respond to network ARP requests on behalf of the GGSN.

Gratuitous ARPThe 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 6IP 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


411-5221-926 Standard 10.07 June 2006

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 6To 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 0GTP 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.

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


411-5221-926 Standard 10.07 June 2006

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 6This 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-3Source address in RADIUS message

Radius Profile VPRN properties Radius source IP address

Use ISP IP address: Yes

Radius VPN: No

Radius Local: No

ISP IP address


Radius VPN: Yes

Radius Local: No

ISP IP address

Use ISP IP address: No

Radius VPN: No

Radius Local: No

Trunk Interface IP address


Radius VPN: Yes

Radius Local: No

Access sub IP address


Radius VPN: Yes

Radius Local: yes

VPN Local IP address


Radius VPN: Yes

Radius Local: Yes




For the DHCP messages the following table provides the source IP address selected for all the scenarios.

SINK routes 6A 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.

Table 6-4Source address in DHCP message

DHCP Profile VPRN properties DHCP source IP address


DHCP VPN: No

DHCP Local: No

ISP IP address


DHCP VPN: No

DHCP Local: No

Trunk Interface IP address


DHCP VPN: Yes

DHCP Local: No

ISP IP address


DHCP VPN: Yes

DHCP Local: No

Access sub IP address


DHCP VPN: Yes

DHCP Local: No

(Access sub IP address is unnummered)

ISP IP Address


DHCP VPN: Yes

DHCP Local: Yes



DHCP VPN: Yes

DHCP Local: Yes



411-5221-926 Standard 10.07 June 2006

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.

Summary routes are available only within ISPs. VPNs do not currently support summary routes.


411-5221-926 Standard 10.07 June 2006



Hardware and engineering 7Overview 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 7The 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 engineeringNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

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 connectivityThe 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 limitationsOn 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 card

Gigabit Ethernet line card

Aggregation APN Not supported if ATM line card is used on the Gi interface

Supported Supported

—sheet 1 of 2—

Hardware and engineering 7-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


Number of address entries on the line card

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

150K entries 64K entries 1100K entries

Spreading the default SSP to all SSPs

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

Not Supported Supported No need due to large number of address entries

DHCP Relay Agent Address

Not Supported Supported if Fast Ethernet line card is used on the Gi interface

Not Supported

VLAN tagging access interface

Not Supported Maximum 32752 VLAN tag IDs can be used for IP frame differentiation if Fast Ethernet line card is used on the Gi interface

Maximum 4094 VLAN tag IDs can be used for IP frame differentiation if Gigabit Ethernet line card is used on the Gi interface

ATM access interface in ATM VPN

Supported if ATM line card is used on the Gi interface

Not Supported Not Supported

Table 7-1 GGSN line card function limitations (continued)

GGSN function ATM line card Fast Ethernet line card

Gigabit Ethernet line card

—sheet 2 of 2—


411-5221-926 Standard 10.07 June 2006

SCS server and clientHardware platformThe 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-2Minimum system requirements for Sun SFv880

Configuration Domain Server (Support up to 10+ regions)

Region Server (Support up to 16 SER 5500s)


Minimum Memory

4GB 4GB 2GB

CPUs 4 CPUs 4 CPUs 2 CPUs

Free Disk 20GB 20GB 20GB

Operating System

Solaris 9 Solaris 9 Solaris 9



Table 7-3Minimum system requirements for Sun SFv890




Minimum Memory

4GB 4GB 2GB

CPUs 4 CPUs 4 CPUs 2 CPUs

Free Disk 20GB 20GB 20GB

Operating System

Solaris 9 Solaris 9 Solaris 9

Table 7-4 Minimum system requirements for Sun SFv250

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


Region Server (Support up to 16 GGSNs)

Memory 2GB 2GB

CPUs 4 CPUs 4 CPUs

Hard Disk (2) 18GB HD (2) 18GB HD


411-5221-926 Standard 10.07 June 2006

Software versioningThe SCS Server software releases incorporate a number of third party software packages. Some of these packages are: SOLID Embedded Engine,

Operating System Solaris 9 Solaris 9


Configuration Domain Server (Support Up to 2 regions)


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

Configuration Domain Server (Support Up to 2 regions)


Memory 2GB 2GB

CPUs 2 CPUs 2 CPUs

Hard Disk Two 146GB HD Two 146GB HD







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


411-5221-926 Standard 10.07 June 2006

Server Disk PartitioningIt 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-9SCS server disk partitioning

Disk No.

Slice No. Mounted Directory

Maximum Minimum Recommended

Comment

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 Unmounted

22GB 1GB 6GB For future use.

6 /usr 10GB 5GB 9GB

7 Unmounted


Total Mounted

68GB 29GB 60GB

—sheet 1 of 2—



OS HardeningOS 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 PatchesThese patches are critical for Solaris OS, and they must be used for SCS server.

1 0 Unmounted


1 Unmounted


2 4GB 2GB 3GB Backup

3 /var/mail 24GB 11GB 21GB It holds the mail.

4 /export/home

14GB 6GB 12GB

5 /var 14GB 6GB 12GB Mount /var and /var/mail separately.

6 /software 14GB 6GB 12GB

7 Unmounted


Total Mounted

70GB 31GB 60GB

Table 7-9SCS server disk partitioning (continued)

Disk No.

Slice No. Mounted Directory

Maximum Minimum Recommended

Comment

—sheet 2 of 2—


411-5221-926 Standard 10.07 June 2006

SCS Server and GGSN CompatibilityBased 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 configurationMinimum configurationThe 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 configurationBased 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 7To 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 GGSNThe 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 GGSNMultiple 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 GGSNUp 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


411-5221-926 Standard 10.07 June 2006

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 GGSNMultiple 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 GGSNTable 7-10 shows the recommended configuration when using IP Subnet Dedication on the GGSN for an APN.

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

Table 7-10IP Subnet Dedication APN configuration

Configuration Aggregation node Traditional node

Device IP Subnet Dedication

Enabled Disabled or Enabled

Device Preserve Individual Subscriber Routes

Disabled Disabled or Enabled

Connection ISP Summary Route

Configured Optional to configure



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


411-5221-926 Standard 10.07 June 2006

Prepaid Service on SCPThe options for configuring coupon resource allocations are different between CTP versions. They are described separately below.

CTP Versions 1 and 2When 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 3CTP 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.



GUI Provisioning 8Overview 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 8In 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 ProvisioningDuring 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:

• GTP’ Profile

8-2 GUI ProvisioningNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

• CGF Profile

• SNMP Profile


The following is a list of access properties that are applicable for the configuration of Connection ISP:

• RADIUS Profile

• DHCP Profile

• IPSec Profile

• IKE Profile

• PPP Profile

• SNMP Profile


• IGMP Profile

• Tariff Profile

• Coupon Lists

• Application Profile

• ToD Profile

• GGSN QoS Profile

• Global Attributes Profile

• Redundancy Profile

• IPSec Policy

• Access Group

• APN Group

• Connection Template

• Accounting Profile

• Accounting Element

• L2TP Tunnel

• IPSec Tunnel

• GRE Tunnel

• Access Control Profile

• Diameter Profile

• IMSI Rules List and Billing Profile

GUI Provisioning 8-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


• IMS Profile

• Content Filter Profiles

• HA Profile

The following is a list of access properties that are applicable for the configuration of a LI ISP:

• IPSec Profile

• IKE Profile

• SNMP Profile


• IPSec Policy

• IPSec Tunnel

• 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 TemplatesAccess Properties ManagerThe 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

• GTP under Tunnels

• Diameter Profiles


411-5221-926 Standard 10.07 June 2006

• Access Control Profiles

• Lawful Interception Profiles

• IMSI Rules List/Billing Profiles

• Redundancy Profiles

• Coupon Lists

• IMS Profile

• HCM Profiles

• Content Filter Profiles

• HA Profile



Figure 8-1Access Properties Manager

GTP’ ProfileThe 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.


411-5221-926 Standard 10.07 June 2006

Figure 8-2GTP’ Profile Configuration Page

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

Table 8-1GTP’ Profile Configuration Tab

Field Range Default Value

Description

CGF Profile Any configured CGF profiles for the ISP

None CGF profile associated with this device

Device Devices span by the ISP

None This field specifies the CGF profile for the specific device.

DSCP CS7, CS6, EF, AF43, AF42, AF41, AF33, AF32, AF31, AF23, AF22, AF21, AF13, AF12, AF11, DE

DE (best effort)

DSCP marking for GTP’ control packets from GGSN to CGF



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-3PPP Profile Dialog

Table 8-2PPP Profile Configuration


Description

Profile Name 32 Characters string

None Name of the PPP Profile

—sheet 1 of 2—


411-5221-926 Standard 10.07 June 2006

Authentication Protocol

CHAP First, PAP First, CHAP Only, PAP Only

CHAP First Authentication protocol preferences

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 Configure

3 - 30 10 Number of configure requests that can go unacknowledged before assuming that the peer can not respond.

Max Terminate

2 - 10 2 Number of terminate requests that can go 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 Control Character Map

Selected or Not Selected

Not Selected Select to enable or disable flow control using Asynch Control Character Map (ACCM).

Enable ACFC


Selected Enables/disables ACFC.

Enable PFC Selected or Not Selected

Selected Enables/disables PFC.

Table 8-2PPP Profile Configuration

—sheet 2 of 2—



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


411-5221-926 Standard 10.07 June 2006

Figure 8-4General Tab of the CGF Profile Dialog

Table 8-3CGF Profile General Tab


Description


None Name of the CGF Profile

Maximum Retries

0 - 5 3 Maximum of Retries for sending accounting records to CGF

Encoding Scheme

ASN.1-BER or ASN.1-PER

ASN.1-BER Encoding Scheme for GGSN accounting record send to CGF

—sheet 1 of 3—



GCDR Record Version

V3.2 or V3.6 V3.2 G-CDR for GGSN billing record as specified in 32.015 V3.2/V3.6

CBB Management Ext

Version 2, Version 3, Version 4, Version 5, Version 6

Version 2 The version number of CBB management extension. Different versions have different values in the Object ID field of management extension.ID field of management extension.

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

Version 4: Includes uplink/downlink volume usage, time usage per content typeid

Version 5: Includes uplink/downlink volume usage, time usage per content typeid, first packet mark per content typeid, remaining inactivity time per content typeid.

Version 6: Includes uplink/downlink volume usage, time usage per content typeid, first packet mark per content typeid, remaining inactivity time per content typeid, and event count

CDR file open time limit

10 minutes to 1440 minutes (24 hours) in 1 minute increments

30 minutes Maximum amount of time that a G-CDR-file ram buffer will remain open before being closed by the billing system (see note below for CDR file size limit)

CDR file size limit

100 KBytes to 1024 KBytes in 1 KByte increments

1024 KBytes Size limit for G-CDR file

The G-CDR-file ram buffer is closed when the buffer reaches either the size limit or the open-time limit, whichever limit is reached first

Include IMEI-SV


Not Selected

(Disabled)

Enable/disable including IMEI-SV management extension.

Table 8-3CGF Profile General Tab (continued)

—sheet 2 of 3—


411-5221-926 Standard 10.07 June 2006

Include RAT Selected or Not Selected

Not Selected

(Disabled)

Enable/disable including RAT management extension.

Include PLMN Identifier


Not Selected

(Disabled)

Enable/disable including PLMN Identifier management extension.

Include Location Info


Not Selected

(Disabled)

Enables/disables the user’s Location Information to be included in the G-CDR record.

Include DCC Event

Select or Not Select

Not Selected Enable/disable DCC events to be included in the G-CDR record.

Include HSDPA


Not Selected

(Disabled)

Enables/disables HSDPA to be included in the G-CDR record.

Include Parking Meter

Selected/Unselected

Unselected Configuration to support inclusion/non-inclusion of the Parking Meter G-CDR Management extension in the G-CDR.

Table 8-3CGF Profile General Tab (continued)

—sheet 3 of 3—



Figure 8-5CGF Profile Server Page

Table 8-4CGF Profile Server Tab


Description

Server Address

IPv4 IP address format

None CGF IP address

UDP Port Integer 3386 Port number to CGF

Response Timer

5 - 30 seconds 7 Response timer for GTP’ response messages between GGSN and CGF.

Response timer on the GGSN needs to be aligned with what is configured on the CGF.

Echo Interval Disabled, 60 - 900 seconds

300 Echo timer for Echo Request and Response between Nortel GGSN and CGF

Response timer on the GGSN needs to be aligned with what is configured on the CGF.


411-5221-926 Standard 10.07 June 2006

“Automated G-CDR Transfer” check box


Not Selected

This check box can only be checked when there is at least one CGF server provisioned.

Enables or disables automatically sending G-CDR files to CGF from disk.

“Always On” Button


Selected

If the check box “Automated G-CDR Transfer” is 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” Button


Not Selected

This button is used to enable the user to set disksend 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

Table 8-4CGF Profile Server Tab



Figure 8-6CGF Profile CDR Audit Page

Table 8-5CGF Profile CDR Audit Tab


Description

Audit Enable Selected or Not Selected

Not Selected

Enable or Disable

FTP Primary Start Time

None None FTP transfer start time

FTP Additional Start Time

None None FTP transfer start time

Server Address


None FTP IP address


411-5221-926 Standard 10.07 June 2006

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

User Name 8 characters of string

None User Name with account on the ftp server

Password 8 characters of string

None Password for the corresponding user name

Table 8-5CGF Profile CDR Audit Tab



Figure 8-7TOD Profile General Page

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.

Table 8-6TOD Profile General Tab


Description


None Name of the Time of Day (ToD) Profile

Time of Day 01:00 AM - Midnight

None Time of Day for Tariff Billing


411-5221-926 Standard 10.07 June 2006

GTP TunnelThe 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-8GTP Tunnel Configuration/General Page

Table 8-7GTP Tunnel components for a Gn ISP


Description

Tunnel Name 32 Characters string

None Name of the GTP tunnel

Connection Template

All configured connection templates

None Connection Template associated with the tunnel



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

0 (Disabled)

The timer for sending out Echo Request messages to SGSNs to check if SGSN is still alive.

Recommended value is 2 minutes.

Control Packet DSCP

CS7, CS6, EF, AF43, AF42, AF41, AF33, AF32, AF31, AF23, AF22, AF21, AF13, AF12, AF11, DE

DE (best effort)

DSCP marking for control packets from GGSN to SGSN

Device Devices span by Gn the Gn ISP

None If Gn ISP spans multiple devices, this field specifies the specific device for 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.

ISP Monitor Redirect


Selected Determines behavior when an ISP is down. If selected, when an ISP is down, new Create PDP Context Requests for the ISP are disallowed, and existing context volume based billing is disabled.



411-5221-926 Standard 10.07 June 2006

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.

Disallow PDP Context Creations


Not Selected

Determines whether or not new Create PDP Context Requests are allowed on that Univity GGSN Device. This checkbox enables/disables the “Terminate Existing PDP Contexts”.

Redirect Response Cause

{No Resources Available (199), System Failure (204), <NO RESPONSE>}

No Resources Available (199)

When new PDP Session Creations are disallowed on the Univity GGSN Device, ISP, or APN, this is the response cause which is returned in the create request failure response message.

L2TP Secure PAP


Not Selected

Configuration to support enable/disable the secure PAP L2TP tunnel.




Figure 8-9GTP tunnel Device configuration on Gn ISP

Table 8-8GTP Tunnel device specific components for a Gn ISP


Description

Device Devices span by Gn the Gn ISP

None If Gn ISP spans multiple devices, this field specifies the specific device for 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 Tolerant Billing Time Limit

Disabled or 5-60 mins

0(Disabled)

Time limit for triggering Fault Tolerant billing updates.

Enabling prevents loss of data but this also raises the number of G-CDRs generated and impacts the CPU processing.


411-5221-926 Standard 10.07 June 2006

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.

Fault Tolerant Billing Volume Limit

Disabled or 15-5000 KB

0(Disabled)

Volume limit for triggering Fault Tolerant billing updates.

Enabling prevents loss of data but this also raises the number of G-CDRs generated and impacts the CPU processing.

ISP Monitor Redirect


Selected Determines behavior when an ISP is 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 PDP Context Creations


Not Selected

Determines wether or not new PDP Session Creations are allowed on this Univity GGSN Device. This checkbox enables/disables the “Terminate Existing PDP Contexts”.

Redirect Response Cause

{No Resources Available (199), System Failure (204), <NO RESPONSE>}

No Resources Available (199)

When new PDP Session Creations are disallowed on the Univity GGSN Device, ISP, or APN, this is the response cause which is returned in the create request failure response message.

Terminate Existing PDP Contexts

None None When this button is pressed, all PDP contexts currently open on the device 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 PAP


Not Selected

Configuration to support enable/disable the secure PAP L2TP tunnel.

Table 8-8GTP Tunnel device specific components for a Gn ISP



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.


411-5221-926 Standard 10.07 June 2006

Figure 8-10 GTP Tunnel Configuration/SGSN Mapping Page

Table 8-9SGSN Mapping Configuration

Field Range Default Value Description

Enable Partial Billing for Roamers


Not Selected If selected partial billing for roamers will be enabled

Periodic Billing Time Limit for Roamers

Disabled or 10-1440

(min)

0 (Disabled) Time limit for triggering periodic billing records for roamers.



Periodic Billing Volume Limit for Roamers

Disabled or 128 - 5000 (KBytes)a

0 (Disabled) Volume limit for triggering periodic billing records for roamers.

Alternate RADIUS Interim Accounting Time Limit

0, 10..1440(minutes)

0(minutes) Time limit for triggering RADIUS interim accounting records when Alternate RADIUS Interim Accounting Time Limit on the APN is Enabled.

SGSN IP Address


1.1.1.1 Home SGSN IP address

Netmask IPv4 net mask format

/24 (255.255.255.0)

Home SGSN net mask

MCC 3 digit integer None Mobile Country Code

MNC 2 or 3 digit integer

None Mobile Network Code

SGSN Group 0 (No group), 1-255

0 (No group) The SGSN Group ID is provided to group SGSNs for the purpose of optimizing Prepaid Reauth signaling and Radius Interim Billing.

RAT Unknown

UTRAN

GERAN

WLAN

Unknown The serving RAT of the SGSN.

a. 1 KByte = 1024 bytes

Table 8-9SGSN Mapping Configuration


411-5221-926 Standard 10.07 June 2006

Figure 8-11Home MCC / MNC Records Creation

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.

Table 8-10Home MCC / MNC


MCC 3 digit integer None Mobile Country Code

MNC 2 or 3 digit integer

None Mobile Network Code



Figure 8-12SGSN Mapping

Table 8-11SGSN Mapping

Field Name Field Range Default Value

Field Description

SGSN IP Address IPv4 IP address format

None Home SGSN IP address

Netmask IPv4 net mask format /24 (255.255.255.0)

Home SGSN net mask

Mobile Country Code

000---999 None A Public Land Mobile Network is 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);


411-5221-926 Standard 10.07 June 2006

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-12Derived RAT Mapping Logic

Mobile Network Code

000---999 None Mobile Network Code (MNC) is a 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 group)

The SGSN Group ID is provided to group SGSNs for the purpose of optimizing Pre-paid Reauth signaling and Radius Interim Billing.

RAT Unknown

UTRAN

GERAN

WLAN

Unknown

The serving RAT of the SGSN.

With “RAT Mapping” enabled

RAT received in GTP

RAT not received in GTP



Use the RAT of the matching entry




Use the RAT of the default entry


Use “Unknown” (0)

Table 8-11SGSN Mapping



GGSN QoS ProfileThe 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-13GGSN QoS Profile

Table 8-13GGSN QoS Profile


Description

Service Profile

All configured service profiles

N/A Service profile associated with combination of Allocation/Retention Priority and Traffic Class (GTP version 1 only). Note: service profile exists for every allocation/retention priority and traffic class combination.


411-5221-926 Standard 10.07 June 2006

APN GroupThe 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-14Add 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.

DSCP CS7, CS6, EF, AF43, AF42, AF41, AF33, AF32, AF31, AF23, AF22, AF21, AF13, AF12, AF11, DE

DE (best effort)

DSCP associated with combination of Allocation/Retention Priority and Traffic Class (GTP version 1 only). Note: DSCP marking exists for every allocation/retention priority and traffic class combination.

The recommended GGSN QoS DSCPs are EF for conversational, af33 for streaming, af23 for interactive and de for background.

Default Service Profile

All configured service profiles

N/A Default service profile

Default DSCP

CS7, CS6, EF, AF43, AF42, AF41, AF33, AF32, AF31, AF23, AF22, AF21, AF13, AF12, AF11, DE

DE (best effort)

Default DSCP

Table 8-13GGSN QoS Profile


Description



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


411-5221-926 Standard 10.07 June 2006

Figure 8-15APN Group dialog



Table 8-14APN Group General Tab


Description

Name 63 Character string

None Name of APN

Service Key 1 - 50 1 Used for the Prepaid service on SCP to authenticate subscribers and select rate and billing period.

Subscriber Template

All configured subscriber template

None Subscriber Template associated with the APN.

IMS Profile All Configured IMS Profile

None The IMS Profile to be returned to the mobile when P-CSCF discovery is requested.

If this field is empty, P-CSCF discovery is disabled for this APN.

HA Profile 32 character string

None Name of an HA profile previously provisioned. Applies the named list to this APN

Aggregation Selected or Not Selected

Not Selected

Designates this APN as supporting only Aggregation mode GTP Sessions with subset of available features & services.

WAP Session Mode


Not Selected

Select if Session Mode is required for the APN.

PLMN ID Mapping


Not Selected

Enable/disable PLMN id Mapping on a per-APN basis

SIP Inspection

Selected or Not selected

Selected

Used to determine if SIP inspection is required on SIP packets belonging to sessions of the APN.

“RAT Mapping”


Not Selected

Enable/disable RAT Mapping

“SGSN Grouping”


Not Selected

Enable/disable SGSN Grouping

GGSN QoS Profile

All configured GGSN QoS profiles

N/A GGSN QoS Profile associated with the APN.


411-5221-926 Standard 10.07 June 2006

The following figure shows the device specific configuration page for adding Tariff Profile/WAP profile to an APN.

Figure 8-16APN Device Specific Configuration Page

Support QoS Release 5 Format

Selected or not Selected

Not Selected

Enables/Disables to support the Release 5 QoS format needed to support HSDPA.

Allow QoS Signalling Indication


Not Selected

If this checkbox is not selected, any QoS profiles received will be downgraded (i.e. the Signalling Indication in the PDP response will be set to No)

APN blacklist enabled


Not Selected

Indicates whether APN blacklist is enabled.

APN blacklist failure threshold

1 - 7200 Integer 100 Once the provisioned threshold is crossed, the APN is blacklisted for that specific GGSN throughout the interval described below.

APN blackout interval

1 - 86400 Integer

300 Blackout time interval in seconds during which time all PDP context requests to the APN are blocked.

Table 8-14APN Group General Tab


Description



The Tariff and/or WAP profiles selected are applied only to the device that is selected.

Table 8-15APN Specific Device Configuration Tab


Description

Tariff All configured Tariff Profiles on the ISP

None Specify SCP profile used for Prepaid Service and GeoZone service for APN.

Credit Control All configured Diameter Credit Control and Diameter Credit + Policy Control profiles on the device

None Specify Credit Control profile used for Credit Control Service for APN.

NOTE: Diameter Credit + Policy Control profile can be specified for this field to provide Credit Control and Policy Control Service for APN.

Policy Control All configured Diameter Policy Control profiles on the device

None Specify Policy Control profile used for Policy Control Service for APN.

AppServer All configured AppServer Profile on the ISP

None Specify Application profile used for WAP Service for APN.

Device Devices configured for the specific ISP

None Device Name which is configured with a specific ISP.

Administrative State

Up (Enabled) or Down (Disabled)

Up When set to Down, all Create PDP Context Request messages that come to this APN are rejected as per the GTP Tunnel’s Redirect Response Cause configuration.


411-5221-926 Standard 10.07 June 2006

Figure 8-17APN Group Accounting/Billing Page



Table 8-16APN Group Accounting/Billing Tab


Description

TOD Profile All configured GGSN TOD profiles

None TOD Profile associated with the APN.

IMSI Billing Profile

IMSI Billing profiles configured on the provisioned ISP

blank This field will contain the IMSI Billing profile to be used for this APN.

Periodic Billing - Time Limit

Disabled or 10 - 1440 (min)

1440 Time limit for triggering periodic billing records.

Periodic Billing - Volume Limit

Disabled or 128- 5000 (KBytes)

1000 Volume limit for triggering periodic billing records.

GTP’ Billing Container

1 - 4 4 GTP’ Billing Container number of charging condition changes before triggering periodic billing records.

Inactivity Timer

0 (Disabled) - 3600 (in seconds)

0 Inactivity timer is defined as inactivity time for a specific content type when no uplink nor downlink 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.

SGSN Change Partial Billing


Not selected

Select if G-CDR generation on SGSN address changes is required for the APN

Close Container on RAT Change


Selected

If selected, a Container is closed when RAT Change events occur.

Close Container on QoS Change


Selected

If selected, a Container is closed when QoS Change events occur.

Fixed Billing Interval


Not Selected

This field indicates whether the Fixed Billing Interval is enabled or disabled on specific APN.


411-5221-926 Standard 10.07 June 2006

RADIUS Accounting


Not Selected

Enable or Disable RADIUS Accounting

GTP’ Billing Selected or Not Selected

Selected

Enable or Disable GTP’ Billing

Enable RADIUS Interim Messages

selected/unselected

selected

Enable/Disable sending RADIUS Interim accounting messages when the RADIUS accounting is enabled.

Enable Alternate RADIUS Interim Accounting Time Limit

selected/unselected

unselected

Enable/Disable configuring Radius Interim Accounting time limit independent of GTP' when RADIUS Interim Accounting is Enabled.


0, 10..1440(minutes)

1440 (minutes)

Time limit for triggering RADIUS interim accounting records when alternate RADIUS Interim Accounting Time Limit is Enabled.

Session Mode


Not Selected

Enable or Disable RADIUS session mode. This check box will be enabled only if RADIUS Accounting is selected.

Session Mode Timer

1 - 120 second 15 Session Mode Timer. This field will be enabled only 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 to Disk


Selected

Enable or Disable RADIUS Accounting Records to be written to the local Disk.

RADIUS Disconnect


Not Selected

Enable or Disable RADIUS disconnect.

Hot Billing Selected or Not selected

Not selected

Select if Hot Billing is required for the APN.



Description



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.

Charging Rulebase Change Partial Billing

Selected or Not

selected

Not selected

Select if G-CDR generation on Charging Rulebase changes is required for the APN.

Close the container on Parking Meter expiry

Selected/Unselected

Unselected

Configuration to support closing/not closing the G-CDR container on Parking Meter expiry.



Description


411-5221-926 Standard 10.07 June 2006

Figure 8-18APN Group Access Page

Table 8-17APN Group Access Tab


Description

Access Deny Log


Not Selected

Access Deny Log reports all rejected IMSI

APN Session Limit


Not Selected

When selected it only allows the number of PDP sessions specified to be set up in this APN. The range of APN Session Limit is1 - 2147483647



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

Anonymous RADIUS Authentication

Disable

MSISDN

User name / Password

Disable If Disable button is selected, the anonymous RADIUS Authentication is disabled. If MSISDN button is selected, the anonymous RADIUS Authentication is enabled for the APN and it uses MSISDN as user name and umts as password. If User name / Password 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 string

None Configured user name.

Password 6 - 20 character string

None Configured password.

APN Selection Mode - MS/Ntwk Provided Subscription Required


Not Selected

If it is selected, the PDP session is rejected when ‘MS or Network Provided APN, Subscribed Verified’ selection mode value is received.

APN Selection Mode - MS Provided Subscription not Required


Not Selected

If it is selected, the PDP session is rejected when ‘MS Provided APN, Subscription not Verified’ selection mode value is received.

APN Selection Mode - Ntwk Provided Subscription Not Required


Not Selected

If it is selected, the PDP session is rejected when ‘Network Provided APN, Subscription not Verified’ selection mode value is received.

Table 8-17APN Group Access Tab


Description


411-5221-926 Standard 10.07 June 2006

Figure 8-19New IMS Profile

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.

Table 8-18New IMS profile


Field Description

Profile Name 32 character string

None The name of the IMS Profile to be added



Figure 8-20IMS Profile GUI

Table 8-19IMS profile GUI


Field Description


None The name of the IMS Profile to be added


411-5221-926 Standard 10.07 June 2006

P-CSCF Address can be added to IMS Profile, the number of P-CSCF Address could be added up to 24.

Number of P-CSCF Address to Return

1-24 2 Number of P-CSCF Addresses to return to mobile

P-CSCF address format selection

“P-CSCF IPv4 Directly” or “P-CSCF IPv4 mapped IPv6”

P-CSCF IPv4 directly

P-CSCF address format selection

Table 8-19IMS profile GUI



Figure 8-21P-CSCF Address List

Add IP AddressThe following dialog is used to add a new IP address to the list. The edit dialog will look very similar.


411-5221-926 Standard 10.07 June 2006

Figure 8-22Add IP Address

Tariff ProfileThe 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 GeneralThe following figure illustrates the General page of the Tariff Profile.

Table 8-20Add IP address


Field Description

IP Address Valid IP address 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)

1.1.1.1 The IP address to be added to the list



Figure 8-23Tariff Profile General Page

Table 8-21Tariff Profile General Tab


Description

Profile Name 28 Character string

None Name of the Tariff Profile

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 Password

6 - 20 character string

None Password for communicating with Tariff Server


411-5221-926 Standard 10.07 June 2006

Tariff Profile ServersThe following figure illustrates the Servers page of the Tariff Profile.

Login Response Time

1 - 5 (Seconds)

2 Maximum time to wait for the login response from the Tariff Server

Response Time 1 - 15 (Seconds)

2 Maximum time to wait for response to each query from Tariff Server

Response timers on the GGSN need to be aligned with what is configured on the Tariff Server.

Table 8-21Tariff Profile General Tab


Description



Figure 8-24Tariff Profile Servers Page

Tariff Profile DeviceThe following figure illustrates the device specific page of the Tariff profile.

Table 8-22Tariff profile server tab


Description

Server Address(es)


None IP Address(es) of Tariff server(s) to be datafilled. Tariff server(s) can be deployed in a pair. One is active and the other in stand-by mode, thus two IP addresses can be datafilled.


411-5221-926 Standard 10.07 June 2006

Figure 8-25Tariff Profile Device Page

Tariff Profile Device ConfigurationThe following figure illustrates the window that is shown when the Add or Edit button is pressed on the Tariff Profile Device page.

Table 8-23Tariff Profile Device Tab


Description

Device Devices configured for specific ISP

None Device name which is configured with 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.



Figure 8-26Tariff Profile Device Configuration Page

Tariff Profile CTP SettingsThe following figure illustrates the CTP Settings tab of the Tariff Profile when Version 1.

Table 8-24Tariff Profile Device Configuration Tab


Description

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.




411-5221-926 Standard 10.07 June 2006

Figure 8-27Tariff Profile CTP Settings Page for version 1

Table 8-25Tariff Profile CTP Settings Tab


Description

CTP version

Version 1

Version 3

Version 1 Version of CTP protocol. Changing versions will reset all CTP parameters to the default values.



The following figure illustrates the CTP Settings when Version 3 is selected.

Table 8-26Tariff Profile CTP Settings Tab for Version 1


Description

Volume Segment

0 - 1000 (Bytes)

50 Data volume that is allowed if no response is received for re-authorization with volume counting. Only used by CTP version 1.

Time Segment

0 - 60 (Minutes)

15 Length of time that a user is allowed to stay connected if no response is received for re-authorization with time counting. Only used by CTP version 1.

Volume Coupon Timeout

0 (Disabled),

1 - 5 (Hours)

0 (Disabled)

Length of time a volume-based coupon can be held before it is forced to reauth with the SCP. Only used by CTP version 1.


411-5221-926 Standard 10.07 June 2006

Figure 8-28Tariff Profile CTP Settings for Version 3



Description

Permit packets to pass


Selected If this option is selected - GGSN will permit packets to pass during authorization of a new coupon or reauthorization of existing coupon(s).



Block packets until the new coupon has been activated


Not Selected

If this option is selected - GGSN will block packets of a specific rate until a new coupon has been activated or an existing coupon has been reauthenticated.

Block data for that coupon rate id only


Selected If this option is selected - GGSN will block data for that coupon rate id only when the coupon request is denied. If enabled, configure the Re-auth Guard Timer.

Re-auth Guard timer

10 - 600 sec

60 sec This timer is started upon receiving a 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.

Tear down the context associated with the denied coupon


Not Selected

If this option is selected - GGSN will tear down the context associated with denied coupon and report back unused coupon usage when the coupon request is denied.

re-auth on QoS change


Selected (Enabled)

If checked GGSN will reauthorize a subscriber’s 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.

re-auth on SGSN address change

Selected Not Selected

Selected (Enabled)

If checked GGSN will reauthorize a subscriber’s coupons when that session’s SGSN address is changed. If the subscriber’s coupons were previously denied, GGSN will not reauthorize them, when that session’s SGSN address is changed.



Description


411-5221-926 Standard 10.07 June 2006

Application Server profileThe 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.

Re-auth on RAT change


Selected (Enabled)

Enable/disable triggering of real-time charging coupon reauthorization upon a RAT change on a per Tariff Profile basis.

Default re-auth threshold

50 - 100% 100%

(Disabled)

Specifies the default re-auth threshold value for coupons. This can be overridden by a threshold 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 coupon timer

0 - 3600 sec

0 sec (Disabled)

Specifies the default time a coupon can remain idle before it is returned to the SCP server. This can be overridden by a threshold trigger set in the coupon itself.

Keep Alive Idle Time

1 - 120 second

20 second Keep Alive message interval. Only used by CTP version 3.

Keep Alive Response Time

1 - 30 second

5 second Keep Alive allowed response time. Only used by CTP version 3.

Response timers on the GGSN need to be aligned with what is configured on the Tariff server.

Credit usage reporting Total

Selected/Unselected

Unselected

Configuration to support “total” credit usage reporting

Initial Coupon Rate Id

0 - 65535 no coupons.

If the rate id table is configured, the GGSN will request coupons for the listed Rate IDs (i.e. 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.



Description



Application Server Profile GeneralThe following figure illustrates the General page of the Application Profile.


411-5221-926 Standard 10.07 June 2006

Figure 8-29Application Server Profile General Page

Table 8-28WAP Profile General Tab


Description

Profile Name

32 character string

None Name of Application Server Profile

Port Number

0 - 65535 0 Communication port for Application Server

Retry Counter

1 - 10 3 Maximum attempt of sending a RADIUS Request to Application Server

Timeout Value

1 - 30 seconds

3 Maximum time to wait for response from Application Server

Response timers on the GGSN need to be aligned with what is configured on the Application Server.



Application Server Profile ServersThe following figure illustrates the Servers page of the Application Server Profile.

Threshold for SNMP Traps

1 - 1000 10 Number of unacknowledged RADIUS Requests before an SNMP trap is generated to warn the irresponsibleness of Application Server

Threshold Reset Time

60 - 300 60 Time to wait before recounting the unacknowledged RADIUS Request to hit the Threshold for SNMP Trap again

IMSI Attribute


Not Selected

Enable/Disable IMSI Attribute has been sent to WRAP messaging.

MSISDN Attribute


Selected

Enable/Disable MSISDN Attribute being sent in WRAP messaging.

Table 8-28WAP Profile General Tab


Description


411-5221-926 Standard 10.07 June 2006

Figure 8-30Application Server Profile Servers Page

Global Attributes ProfileThe 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

Table 8-29Application Server Profile Server Tab


Description

Server Address(es)


None IP Address(es) of Application Server to be datafilled. Application Server (s) can be deployed in single or duplex mode. Only one IP address is datafilled for either mode.



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-31Global Attributes Profile Page

Table 8-30Global Attributes Profile Tab


Description

Name 63 Character string

None Name of Global Attribute Profile

IP Subnet dedication to SSP


Not Selected

Select if IP Subnet Dedication is to be used by the Nortel GGSN to manage end user IP addresses for the PDP sessions.


411-5221-926 Standard 10.07 June 2006

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

Preserve Individual subscriber routes covered by summary routers or address pools


Selected Preserves individual subscriber address routes even when an existing summary route covers the subscriber address. This option is for the backward compatibility purpose. However, this option can not be selected for aggregation mode PDP sessions or when IP Subnet Dedication is selected.

Table 8-30Global Attributes Profile Tab


Description



Figure 8-32User 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.


411-5221-926 Standard 10.07 June 2006

Figure 8-33SCS Login Window

LI User View ProfileThe 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-34 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-34SCS Available Options for LI ISP

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


411-5221-926 Standard 10.07 June 2006

Figure 8-35ISP 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.

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

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-36LI ISP Device Manager

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


411-5221-926 Standard 10.07 June 2006

Figure 8-37LI Profile Configuration

Table 8-31LI Profile Configuration


Field Description

LI Profile Name 32 Characters string

None Name of the LI Profile

Device Devices configured for LI ISP

None Device name of device that this profile is associated to.

ADMF IP Address 1


None IP Address of ADMF 1

ADMF Port Number 1

1 - 65535 None TCP port of ADMF 1

ADMF IP Address 2


None IP Address of ADMF 2

ADMF Port Number 2

1 - 65535 None TCP port of ADMF 2

Intercept Only When Roaming


Not Selected

Select to intercept only roaming target mobile subscribers. Otherwise, intercept all target mobile subscribers.



Visited GGSN Access ControlThe 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 ProfileThe 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.


411-5221-926 Standard 10.07 June 2006

Figure 8-38Access Properties Manager Menu / Access Control Profiles



Figure 8-39Add New Access Control Profile

Table 8-32Configured Access Control List Profile


Description

Access Control List Profile

All configured Access Control t profiles

None Access Control Profile associated with the APN. The default setting for this feature is disabled for the APN if no Access Control Profile is selected.


411-5221-926 Standard 10.07 June 2006

Figure 8-40Access Control Profile General Tab



Figure 8-41Access Control Profile MCC

MCC/MNC ConsistencyA warning dialog will pop up if no MNC is configured.

Table 8-33Access Control Profile MCC Table


Description

Mobile Country Code

Three Digit Integer

None Mobile Country Code. The range is 000-999

Specify Digits for MNC

Menu of 2 or 3 digits

2 digits Specify the digit MNC. The range for 2 digits is 00-99 and for 3 digits is 000-999


411-5221-926 Standard 10.07 June 2006

Figure 8-42Access Control Profile MNC

Figure 8-43Warning dialog if no MNC is configured



Figure 8-44Add MNC Dialog

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

Table 8-34Access Control Profile MNC Table


Description

Mobile Network Code

Three or two digit Integer

None Mobile Network Code. The range for 2 digits MNC is 00-99 and for 3 digits MNC is 000-999.

Remarks 32 Character string

None Operator Information. This field is optional


411-5221-926 Standard 10.07 June 2006

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 ProfileNew 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-45 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-45New Diameter Profile from Access Properties “Diameter Profiles”

Table 8-35New 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 the following values:

Credit Control

Policy Control

Credit + Policy Control

Credit Control if DCC feature enabled.

Otherwise, Policy Control if DPC feature enabled and DCC feature not enabled.

Application type of the Diameter Profile.

Table 8-35New Diameter Profile


411-5221-926 Standard 10.07 June 2006

Diameter Profile General Tab

Figure 8-46Diameter Profile General Tab

Table 8-36Diameter Profile General Tab



None Name previously entered for the Diameter Profile. Cannot be changed in this dialog.



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.

Watchdog timer

6 - 60 30 Watchdog timer for Device Watchdog Request and Answer between GGSN and Diameter server.

Destination Realm

1 - 127 character string

“default” Destination realm will be used by Diameter proxies for the realm based routing

Version 1 1 Diameter Profile version on Nortel GGSN. This field is for future use and cannot be altered.

Application Credit Control, Policy Control, Credit + Policy Control

Application type from “New Diameter Profile”

Indicates the application type of the profile. This field is not modifiable.

Customer Specific Service Context Identifier

Check box/String

Empty If the Check Box is set the user is able Specify the Service Context Identifier AVP for a particular customer. This is a string value that must be pre-arranged with the customer. If the Check box is not selected then A nortel specific Customer Service Context ID is used

Table 8-36Diameter Profile General Tab


411-5221-926 Standard 10.07 June 2006

Figure 8-47Diameter Profile Servers Tab

Table 8-37Diameter Profile - Servers tab


Field Description

Server Address

IPv4 address in dot notation

None The IPv4 address of the currently configured servers.



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-48Diameter Server Profile General Tab

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.

Table 8-38Diameter Server Profile General Tab


Field Description

Table 8-37Diameter Profile - Servers tab


411-5221-926 Standard 10.07 June 2006

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.

Server Address

IP v4 Address None Server IP Address

Port 0-65535 3868 TCP port for Diameter server

Transport Protocol

TCP/SCTP TCP TCP is the only supported and configurable transport type. This field is for future use and cannot be altered.

Peer Radio Button

(Proxy, Relay, and Direct)

Proxy Set agent type of the DCC peer. When either “Proxy” or “Relay” is selected, the DCC client will set the P bit in all Credit Control Request messages that are sent to this peer.

Table 8-38Diameter Server Profile General Tab



Figure 8-49Diameter Server Profile Device Specific Tab


411-5221-926 Standard 10.07 June 2006

New Diameter Server Device Specific Settings

Figure 8-50New Diameter Server Device Specific Settings

Table 8-39New Diameter Server Device Specific Settings


Field Description



Security Options

None, IPSEC None Security option for the communication between Diameter server and GGSN Diameter Client. The IPSEC option of Security Options field is now supported.

IPSec Profile IPSec profile name

None The IPSec profile that defines the 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 Key

Hexadecimal Format, Text Format

Hexadecimal Format

Enables use of a security key. This field is for future use and cannot be altered.



Hexadecimal input (0x)

Hexadecimal string

None Hexadecimal value entered as the pre-shared key. This field is for future use and cannot be altered.

ASCII text input

Text string None The ASCII text string used for the pre-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 Selected

Not Selected

Indicates that this server is the 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.

Table 8-39New Diameter Server Device Specific Settings


411-5221-926 Standard 10.07 June 2006

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-51Server 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 Figure 8-52).



Figure 8-52IPSec 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.


411-5221-926 Standard 10.07 June 2006

Diameter Profile Credit Control Tab



Figure 8-53Diameter Profile Credit Control Tab (Triggers)


411-5221-926 Standard 10.07 June 2006

Table 8-40Diameter Profile-Credit Control Tab (Trigger)


Field Description

Re-auth on QoS change


Selected (Enabled)

If checked, GGSN reauthorizes a subscriber's 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.

Re-auth on SGSN address change


Selected (Enabled)

If checked, GGSN reauthorizes a subscriber's coupons when that session's SGSN address is changed. If the subscriber's coupons were previously denied, GGSN will not reauthorize them, when that session's SGSN address is changed.

Re-auth on RAT change


Selected (Enabled)

Enable/disable triggering of real-time charging 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 timer

0 - 3600 seconds

0 seconds (Disabled)

Specifies the default time a coupon can remain idle before it is returned to the DCC server. This can be overridden by a threshold trigger set in the coupon itself.

Inactivity Timer

0 - 3600 seconds

0 seconds (Disabled)

This timer value is used to determine when subscriber data packets have temporarily ceased 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.



A check box “Total Credit Usage Reporting” is added to Diameter profile dialog, as shown in Figure 132 on page 335

Default re-auth threshold - Time

50 - 100

(when % button is checked)

100 Specifies the default re-auth threshold value for coupons. This can be overridden by a threshold 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.

Default value for time quota threshold in percentage of DCC server granted units

(the threshold value is GrantedUnits x SCSConfiguredPercentage)

integer

(when seconds is checked)

0 Default value for time quota threshold in absolute units

(the threshold value is GrantedUnits - SCSConfiguredValue)

Default re-auth threshold - Volume

50 - 100

(when % button is checked)

100 Default value for volume quota threshold in percentage of DCC server granted units

(the threshold value is GrantedUnits x SCSConfiguredPercentage)

integer

(when bytes is checked)

0 Default value for volume quota threshold in absolute units

(the threshold value is GrantedUnits - SCSConfiguredValue)

Table 8-40Diameter Profile-Credit Control Tab (Trigger)


411-5221-926 Standard 10.07 June 2006

Figure 8-54Credit Usage Reporting Dialog

Table 8-41Credit usage reporting dialog

Field Name Field Range

Default Value

Field Description

Total Credit Usage Reporting

Selected/Unselected

Unselected

Configuration to support “total” credit usage reporting



Figure 8-55Diameter 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-56 will be displayed.


411-5221-926 Standard 10.07 June 2006

Figure 8-56Add Rate Id Window

Table 8-42Add Rate-id window


Field Description

Rating Group Id

0 - 65535 0 Configure the rate-id’s that the GGSN will request the Diameter Credit Control server to provide in the initial CCR/CCA exchange.



Figure 8-57Diameter Profile Credit Control Tab (Authorization Behavior)

Table 8-43Diameter Profile Credit Control (Authorization Behavior)


Field Description

Quota exhausted

Allow/Block Allow Allow/Block Traffic when re-authorizing due to Quota Exhaustion


411-5221-926 Standard 10.07 June 2006

Quota request for a category when no quota is currently available for that category

Allow/Block Allow Allow/Block Traffic when re-authorizing due to initial requesting a coupon

Quota request due to Change in QoS

Allow/Block Allow Allow/Block Traffic when re-authorizing due to QoS change

Quota request due to Change in RAT

Allow/Block Allow Allow/Block Traffic when re-authorizing due to RAT change

Quota request due to Change in SGSN

Allow/Block Allow Allow/Block Traffic when re-authorizing due to SGSN change

Forced re-authorization initiated by the DCC Server

Allow/Block Allow Allow/Block Traffic when re-authorizing due to Server forced reauthorization

Table 8-43Diameter Profile Credit Control (Authorization Behavior)



Figure 8-58Diameter Profile Credit Control Tab - Denied Coupon Behavior


411-5221-926 Standard 10.07 June 2006

Table 8-44Diameter Profile-Credit Control Tab (Denied Coupon Behavior


Field Description

Denied coupon behavior - Re-auth Guard timer

10 - 600 sec. 60 sec. This timer is started upon receiving a 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 - Block data for that coupon rate id only


Selected

If this option is selected, GGSN blocks data for that coupon rate id only when the coupon request is denied. If enabled, configure the Re-auth Guard Timer.

Denied coupon behavior - Tear down the context associated with the denied coupon


Not selected

If this option is selected, GGSN tears down the context associated with a denied coupon and report back unused coupon usage when the coupon request is denied.



Diameter Profile Request Failure Tab

Figure 8-59Diameter Profile Request Failure Tab

Table 8-45Diameter Profile Request Failure Tab


Field Description

Session Failover Support

Selected or not selected

Not selected

When selected, the DCC client supports failover, i.e. failed DCC requests is re-directed to alternative DCC servers. This is applicable to all sessions.


411-5221-926 Standard 10.07 June 2006

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.

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 Interval

60-65535 seconds

0 (disabled)

Time Interval in seconds in which Tx Timer Event occur.

Tx Event Major Threshold

10-65535 0 (disabled)

Major Threshold values for Tx Timer Event

Tx Event Critical Threshold

10-65535 and greater than above threshold (or disabled)

0 (disabled)

Critical Threshold values for Tx Timer Event

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 Handling

TERMINATE

CONTINUE

RETRY_AND_TERMINATE

TERMINATE

Set default failure handling when Credit-Control-Failure-Handling AVP is not received from the DCC server. This will apply to all sessions.

Determines the handling for active Diameter sessions upon detecting the server failure.

Table 8-45Diameter Profile Request Failure Tab



Figure 8-60 IMSI Rules Configuration

Once the Rule list has been created, click on the add box to create a rule.

Figure 8-61New IMSI Rule


411-5221-926 Standard 10.07 June 2006

Note: In order to match two different values for a digit in the IMSI two different rules will need to be provisioned.

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

Table 8-46IMSI Rule Configuration


Field Description

IMSI List Name

32 character string

None Name of the IMSI list

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.



Figure 8-62IMSI Billing Profile Page


411-5221-926 Standard 10.07 June 2006

Figure 8-63IMSI Billing Element Page

Table 8-47IMSI Profile Fields


Field Description


None Name of the IMSI billing profile.

IMSI Rules List

All configured IMSI Rules list on the provisioned ISP

None IMSI Billing Rule list.

Time Limit

(used for both GTP and Radius billing)

Disabled or 10 - 1440 (min)

1440 Time limit for triggering periodic billing records.

Volume Limit (used for both GTP and Radius billing)

Disabled or 128 - 5000 (Kbytes)

1000 Volume limit for triggering periodic billing records.

Max Billing Containers

1 - 4 4 GTP’ Billing Container number of charging condition changes before triggering periodic billing records.



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 ControlA new GUI tab is added to SCS configuration window to support license key entry, Software Optionality Control (SOC) feature activation and deactivation.

SOC Feature ActivationThe 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.

Set Prepaid CC

(used for both GTP and Radius billing)

Checked or Unchecked

Unchecked

If checked, set the prepaid bit in the charging characteristic.


0, 10..1440(minutes)

1440(minutes)

Time limit for triggering RADIUS interim accounting records when Alternate RADIUS Interim Accounting Time Limit on the APN is Enabled.

Table 8-47IMSI Profile Fields


411-5221-926 Standard 10.07 June 2006

Figure 8-64New SOC Activation Window

Table 8-48New SOC Activation


Field Description

License Key 32 characters (string)

None License key providing access to optional feature.



Figure 8-65Error dialog for invalid license key


411-5221-926 Standard 10.07 June 2006

Figure 8-66SOC Activation Configuration Window

Table 8-49SOC Activation Configuration


Field Description

Feature Name

256 characters (string)

None Optional feature name currently available for configuration.

Activation Status

Enabled or Disabled

Disabled

Feature activation status in network.





The following new GUI screen allows user(s) to edit feature activation status from “Disabled” to “Enabled” & vice versa.

Figure 8-67SOC Activation Configuration

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-68Warning dialog for disabling feature with SCS Configuration

Event Based BillingThe 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

Table 8-50SOC Activation Configuration


Field Description

Feature Name

256 characters (string)

None Optional feature name currently available for configuration.

Activation Status

Enabled or Disabled

Disabled

Feature activation status in network.




411-5221-926 Standard 10.07 June 2006

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 ConfigurationThe 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-69Dialog for POP3 Event Description

Table 8-51POP3 event description


Field Description

EVENT None POP3-RECV

RECV for POP3

Content Type ID

0-65535 None Content Type ID for uplink and 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


411-5221-926 Standard 10.07 June 2006

POP3 Receive Event Configuration

The following is used to configure the coupon id, content type id and Event completion for POP3 Receive Event.

Event Completion

Enabled or Disabled

Disabled

If Event Completion is set to 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.

UpContTypeID

0-65535 None Content Type ID for uplink data packets count

DownContTypeID

0-65535 None Content Type ID for downlink data packets count

UpCouponID 0-65535 None Coupon ID for uplink data packets count

DownCouponID

0-65535 None Coupon ID for downlink data packet count

Table 8-51POP3 event description



Figure 8-70POP3 Receive Event Configuration

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.

Table 8-52POP3 receive event configuration


Field Description

Content Type ID

0-65535 None Content Type ID for uplink/downlink data packets count and event usage count.

Coupon ID 0-65535 None Coupon ID for uplink/downlink data packets count and event usage count.

Event Completion


Not Selected (Disabled)




411-5221-926 Standard 10.07 June 2006

Figure 8-71POP3 Default Configuration

SMTP Event ConfigurationThe following figure shows the rating configuration for SMTP 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.

Table 8-53POP3 default configuration


Field Description

Uplink Content Type ID


Downlink Content Type ID


Uplink Coupon ID 0-65535 None Coupon ID for uplink data packets count

Downlink Coupon ID




Figure 8-72Dialog for SMTP Event Description

Table 8-54SMTP event description


Field Description

EVENT None SMTP-SEND SEND for SMTP

Content Type ID

0-65535 None Content Type ID for uplink and downlink data packets count and event usage count for the EVENT

Coupon ID 0-65535 None Coupon ID for uplink and downlink data packet count and event usage count for the EVENT


411-5221-926 Standard 10.07 June 2006

SMTP Send Event Configuration

The following is used to configure the coupon id, content type id and Event completion for SMTP Send Event.

Event Completion

Enabled or Disabled

Disabled If Event Completion is set to Disabled, the event is counted when the event trigger is detected.


Content None Default Content type description for the default SMTP.

UpContTypeID


DownContTypeID



DownCouponID


Table 8-54SMTP event description



Figure 8-73SMTP Send Event Configuration

New Default SMTP Configuration

The following default parameters is used to configure the uplink and downlink coupon id and content type id or SMTP Non-Event traffic.

Table 8-55SMTP send event configuration


Field Description

Content Type ID



Event Completion






411-5221-926 Standard 10.07 June 2006

Figure 8-74SMTP Default Configuration

IMAP4 Event ConfigurationThe following figure shows the rating configuration for IMAP4 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.

Table 8-56SMTP default configuration


Field Description






Downlink Coupon ID




Figure 8-75Dialog for IMAP4 Event Description

Table 8-57IMAP4 event description


Field Description

EVENT None IMAP4-RECV, IMAP4-SEND

RECV and SEND for IMAP4

Content Type ID

0-65535 None Content Type ID for both uplink and downlink data packets count and event usage count for the EVENT

Coupon ID 0-65535 None Coupon ID for both uplink and downlink data packets count and event usage count for the EVENT


411-5221-926 Standard 10.07 June 2006

IMAP4 Send Event Configuration

The following is used to configure the coupon id, content type id and Event completion for IMAP4 Send Event.

Event Completion

Enabled or Disabled



Content None Default Content type description for the default IMAP4.

UpContTypeID


DownContTypeID



DownCouponID


Table 8-57IMAP4 event description



Figure 8-76IMAP4 Send Event Configuration

IMAP4 Receive Event Configuration

The following is used to configure the coupon id, content type id and Event completion for IMAP4 Receive Event.

Table 8-58IMAP4 send event configuration


Field Description

Content Type ID

0-65535 None Content Type id for uplink/downlink data packets count and event usage count.


Event Completion






411-5221-926 Standard 10.07 June 2006

Figure 8-77IMAP4 Receive Event Configuration

Default IMAP4 Configuration

The following default parameters is used to configure the uplink and downlink coupon id and content type id or IMAP4 Non-Event traffic.

Table 8-59IMAP4 receive event configuration


Field Description

Content Type ID



Event Completion







Figure 8-78IMAP4 Default Configuration

HTTP General Tab ConfigurationThe 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.

Table 8-60IMAP4 default configuration


Field Description






Downlink Coupon ID



411-5221-926 Standard 10.07 June 2006

Figure 8-79Dialog Displaying General HTTP and Content Type

Table 8-61General HTTP and content type


Field Description

URL None None Domain and path of the URL.

UpContTypeID


DownContTypeID



DownCouponID




HTTP MMS Content Type ConfigurationThe 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.

Per-Get Billing Content Type ID

0-65535 None Content Type ID for uplink/downlink data packets count and event usage count per GET event

Per-Get Billing Coupon ID

0- 65535 None Coupon ID for uplink/downlink data packets count and event usage count per GET event

Per-Get Billing Event Completion

Enabled or Disabled



Content None HTTP-DEFAULT

Content type description for the default HTTP record.

UpContTypeID


DownContTypeID



DownCouponID


Table 8-61General HTTP and content type


411-5221-926 Standard 10.07 June 2006

Figure 8-80Provisioning Content Type (MMS)

Table 8-62Provisioning content type (MMS)


Field Description

Content None WAP MMS Description for MMS Content

UpContTypeID


DownContTypeID



DownCouponID

0-65535 None Coupon ID for downlink data packets count



New MMS Configuration

The following is used to configure the uplink and downlink coupon id and content type id for MMS traffic.



UpContTypeID


DownContTypeID



DownCouponID




411-5221-926 Standard 10.07 June 2006

Figure 8-81MMS Configuration

Wireless Village Event ConfigurationThe following figure shows the rating configuration for Wireless Village application. The top part of the screen shows the configuration of event specific rating information and the bottom part of the screen shows rating for Default HTTP.

Table 8-63MMS configuration


Field Description






Downlink Coupon ID 0-65535 None Coupon ID for downlink data packet count



Figure 8-82Provisioning Content Type (Wireless Village)

Table 8-64Provisioning content type (Wireless Village)


Field Description

Content None WV-RECV

WV-SEND

Description for Wireless Village Content for both receive and send events.

Content Type ID




411-5221-926 Standard 10.07 June 2006

Wireless Village Send Event Configuration

The following is used to configure the coupon id, content type id and Event completion for Wireless Village Send Event.

Event Completion

Enabled or Disabled





UpContTypeID


DownContTypeID



DownCouponID





Figure 8-83Wireless Village Send Event Configuration

Wireless Village Receive Event Configuration

The following is used to configure the coupon id, content type id and Event completion for Wireless Village Receive Event.

Table 8-65Wireless Village send event configuration


Field Description

Content Type ID



Event Completion






411-5221-926 Standard 10.07 June 2006

Figure 8-84Wireless Village Receive Event Configuration

Default HTTP Configuration

The following parameters are used to configure the uplink and downlink coupon id and content type id for default HTTP traffic.

Table 8-66Wireless Village receive event configuration


Field Description

Content Type ID



Event Completion







Figure 8-85Default HTTP Configuration

HTTP MISC TabConfigurationThe following figure shows the configuration for HTTP MISC tab.

Table 8-67Default HTTP configuration


Field Description








411-5221-926 Standard 10.07 June 2006

Figure 8-86HTTP Misc Tab

Table 8-68HTTP Misc tab


Forbidden Coupon ID 0-65535 NULL The coupon is used to capture the byte vol-ume of packets which cannot be charged to the original coupon which is in the denied state. NULL signifies the forbidden coupon function is disabled.

Charge TCP Connection to URL rate

boolean(selected/unselected)

unselected If the check box is unselected,the TCP con-nection bytes are still 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 ConfigurationThe 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-87Dialog Displaying General WAP and Content Type

Table 8-69General WAP and content type


Field Description

URL None None Domain and path of the URL.

UpContTypeID


DownContTypeID



411-5221-926 Standard 10.07 June 2006

WAP MMS Content Type ConfigurationThe 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.


DownCouponID





0- 65535 None Coupon ID for uplink/downlink data packets count and event usage count per GET event


Enabled or Disabled



Content None WAP-DEFAULT

Content type description for the default WAP record.

UpContTypeID


DownContTypeID



DownCouponID


Table 8-69General WAP and content type



Figure 8-88Provisioning Content Type (MMS)



Field Description

Content None WAP MMS Description for MMS Content

UpContTypeID

0-65535 None Content Type id for uplink data packets count

DownContTypeID

0-65535 None Content Type id for downlink data packets count


DownCouponID

0-65535 None Coupon ID for downlink data packets count


411-5221-926 Standard 10.07 June 2006

Wireless Village Event ConfigurationThe following figure shows the rating configuration for Wireless Village application. The top part of the screen shows the configuration of event specific rating information and the bottom part of the screen shows rating for Default WAP.



UpContTypeID


DownContTypeID



DownCouponID





Figure 8-89Provisioning Content Type (Wireless Village)



Field Description

Content None WV-RECV

WV-SEND

Description for Wireless Village Content for both receive and send events.

Content Type ID




411-5221-926 Standard 10.07 June 2006

New Default WAP ConfigurationThe following parameters are used to configure the uplink and downlink coupon id and content type id for default WAP traffic.

Event Completion

Enabled or Disabled




Content type description for the default WAP record.

UpContTypeID


DownContTypeID



DownCouponID





Table 8-72Default WAP Configuration

WAP MISC TabThe following figure shows the configuration for WAP MISC tab.

Table 8-73Default WAP configuration


Field Description








411-5221-926 Standard 10.07 June 2006

Figure 8-90WAP Misc Tab

Traffic Performance Optimizer (TPO)TPO ISPA 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

Table 8-74WAP Misc tab


Forbidden Coupon ID 0-65535 NULL The coupon is used to capture the byte vol-ume of packets which cannot be charged to the original coupon which is in the denied state. NULL signifies the forbidden coupon function is disabled.



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

Figure 8-91Device Access Properties

Figure 8-92 shows how to assign an ISP to be the TPO ISP.


411-5221-926 Standard 10.07 June 2006

Figure 8-92TPO ISP Selection

TPO IP ServiceThe 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-93IPO data configuration

Figure 8-94CGF profile


411-5221-926 Standard 10.07 June 2006

Table 8-75CGF Profile General Tab

Table 8-76CGF profile general tab


Field Description


None Name of the CGF Profile

Maximum Retries

0 - 5 3 Maximum of Retries for sending accounting records to CGF

Encoding Scheme

ASN.1-BER or ASN.1-PER

ASN.1-BER

Encoding Scheme for GGSN accounting record send to CGF

GCDR Record Version

V3.2 or V3.6 V3.2 G-CDR for GGSN billing record as specified in 32.015 V3.2/V3.6

CBB Management Ext

2, 3 2 The version number of CBB management extension. Different versions have different values in the Object ID field of management extension.ID field of management extension.

Version 2 of the CBB Management Ext is available for backward compatibility with older releases.

CDR file open time limit

10 minutes to 1440 minutes (24 hours) in 1 minute increments

30 minutes

Maximum amount of time that a G-CDR-file ram buffer will remain open before being closed by the billing system (see note below for CDR file size limit)

CDR file size limit

100 KBytes to 1024 KBytes in 1 KByte increments

1024 KBytes

Size limit for G-CDR file

The G-CDR-file ram buffer is closed when the buffer reaches either the size limit or the open-time limit, whichever limit is reached first



Redundancy Profiles Figure 8-95New Redundancy Profile Dialog

Figure 8-96Edit Redundancy Profile Dialog--General Redundancy Panel

Figure 8-97Edit Redundancy Profile Dialog--SSM Redundancy Panel


411-5221-926 Standard 10.07 June 2006

Coupon ListsThe 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-98Coupon List

Table 8-77Redundancy profile tab

Field Name

Field Range

Default Value

Field Description

SSM Redundancy For Aggregation


Not Selected

The “SSM Redundancy for Aggregation” check box enables or disables SSM redundancy for aggregation APNs.

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



Figure 8-99Add and Edit Coupon

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

Table 8-78Add coupon ID tab

Field Name

Field Range

Default Value

Field Description

Coupon Id 0-65535 0 Coupon Id for CBB policy

Requested Type

At Start)/On Usage

On Usage At Start: The coupon is requested at start

On Usage: The coupon is never requested at start


411-5221-926 Standard 10.07 June 2006

Figure 8-100New HCM Profile Dialog

Figure 8-101Edit HCM profile Dialog

Table 8-79Parameters for new HCM profile


Field Description


None Name of the HCM Profile. The first letter should be [a-z], the valid letter should be [a-z0-9_-./:'#&%$]

Table 8-80Parameters for edit HCM profile


Field Description


None Name of the HCM Profile

HCM Enabled

checked or unchecked

unchecked

Enable or disable HCM functionality



Content Filtering ProfilesA 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

Network activation success rate threshold

1 - 100 Integer 90 The threshold value for Network activation success rate.

Nodal activation success rate threshold

1 - 100 Integer 95 The threshold value for Nodal activation success rate.

Activation attempt threshold

0 -30,000 Integer

0 The threshold value for activation attempt

Table 8-80Parameters for edit HCM profile


411-5221-926 Standard 10.07 June 2006

Figure 8-102New Content Filter Profile

Table 8-81Content Filter Profile Configuration Parameters


Profile Name

32 character string None The name of the Content Filter Profile

IP Addr Integer or IP address in dotted decimal notation

None 32-bit number uniquely identifying the Content Filter Server

Port 16-bit unsigned Integer, 1-65535

For Websense type server, the default value is 15868. For Nortel Proprietary type server, the default value is 1344

The port number of the Content Filter Server

Type Symbolic representation of an

8 bit unsigned Integer,

1=Nortel Networks, 2=Websense

1 The type of the Content Filter Server (Nortel Networks, Websense, etc)

Timeout 16 bit Integer, 1-10 3 The request timeout value of the Content Filter Server in seconds



Figure 8-103Add Content Filter Profile

Table 8-82Content Filter Profile Configuration Parameters


Profile Name

32 character string None The name of the Content Filter Profile

IP Addr Integer or IP address in dotted decimal notation

None 32-bit number uniquely identifying the Content Filter Server

Port 16-bit unsigned Integer, 1-65535

For Websense type server, the default value is 15868. For Nortel Proprietary type server, the default value is 1344

The port number of the Content Filter Server

Type Symbolic representation of an

8 bit unsigned Integer,

1=Nortel Networks, 2=Websense

1 The type of the Content Filter Server (Nortel Networks, Websense, etc)

Timeout 16 bit Integer, 1-10 3 The request timeout value of the Content Filter Server in seconds


411-5221-926 Standard 10.07 June 2006

Figure 8-104Content Filter Profile Server List

Content Filter Service PolicyA 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-105Service Policy Manager Content Filter Policy


411-5221-926 Standard 10.07 June 2006

HA ProfileA 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-106New HA Profile

Table 8-83New HA profile


Description


None Name of the new profile. Hopefully something descriptive.



Figure 8-107HA Profile

Clicking the Add or Edit button brings up the “New HA Server Address” dialog. An example is shown in Figure 8-108.


411-5221-926 Standard 10.07 June 2006

Figure 8-108HA Server Address

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

Table 8-84HA server address


Description

Server Address

Class A, B, or C IPv4 address

None IP address of an Home Agent (HA) or network hosting HAs.

Netmask 128.0.0.0 - 255.255.255.255

None Netmask associated with the provisioned server address. Permits the HA Server List entry to identify a single host or an entire network.



Figure 8-109Connection 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.

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

Table 8-85Connection template general tab


Description

Name 32 Character string None Name of the Connection Template.

Connection ISP

Configured Connection ISPs

Any Selects the ISPs to allow connections to.


411-5221-926 Standard 10.07 June 2006

associated with a VPN, the Access Subscriber local address can not be used for the DHCP Relay Agent Address either.



Figure 8-110DHCP Profile Configuration

Table 8-86DHCP Profile General Tab


Description

Name A text string None Name of the profile


411-5221-926 Standard 10.07 June 2006

Hop Limit 1 - 16 4 Number of hops allowed

Elapsed Seconds Allowed

0, 60 - 65535 16000 Time-out in seconds

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

IPv4 address format None The DHCP relay agent address for the giaddr parameter field in the DHCP messages.

Use ISP address as source address


Not Selected

Select for using the ISP IP address as source address.

DHCP Client Options - Client ID

Wireless:IMSI, Wireless:MSISDN

MSISDN Provides a DHCP Client that identifies the Nortel GGSN for a DHCP address request.

DHCP Relay Agent Options - Circuit ID


Not Selected

Enables you to select the 32-bit integer and String Hostname options.

DHCP Relay Agent Options - 32-bit integer


Not Selected

Provides a slot, port and vpi/vci address that enables the identification of a Nortel GGSN. (ID=slot/port/vpi/vci)

DHCP Relay Agent Options - String Hostname


Not Selected

Provides a text String that identifies a Nortel GGSN. The string is mapped to the following data: slot/port/VP/VCI.

DHCP Relay Agent Options - Remote ID


Not Selected

Selects the remote ID.



Description



Subscriber Outbound TunnelingA 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.

DHCP Relay Agent Options - Subnet Mask


Not Selected

Netmask of the Nortel GGSN inteface receiving the DHCP request.



Description


411-5221-926 Standard 10.07 June 2006

Figure 8-111Subscriber Outbound Tunneling Page

Subscriber Address AllocationThis 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.

Table 8-87Subscriber Outbound Tunneling Tab


Description

Dynamic L2TP VPN


Not Selected

IP/L2TP tunnel switching if the session GTP PDU is IP or PPP.



Figure 8-112Subscriber Account Page

Table 8-88Subscriber Account Tab


Description

Radius/Local Selected or Not Selected

Selected The type of address allocation to use RADIUS/local.

Radius/DHCP


Not Selected

The type of address allocation to use RADIUS/DHCP.


411-5221-926 Standard 10.07 June 2006

Accounting ElementAccounting 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-113 illustrates where these types will be visible.

Figure 8-113Accounting 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-114 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

For default values after GGSN upgrade, please refer to [30]



Figure 8-114Accounting Element Interval Page

Table 8-89Accounting Element Selection Tab

Field Accounting Element

User Privilege Range Default Value

Description

Name All 32 Character String None The name of accounting element


411-5221-926 Standard 10.07 June 2006

Type Device Owner Device Stats, ISP IP Stats, Trunk Stats, Memory Stats, Overload Stats

Device Stats

Accounting Element Stats

ISP ISP IP 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, Trunk Stats, MPLS Stats, DCC Stats, DHCP Stats, Local Addr Pool Stats, Content Filter Stats

ISP IP Stats

Device Owner and ISP

Device Stats, ISP IP Stats, Trunk Stats, Memory 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

Device Stats




Description



Interval (minutes)

Device Stats

Device Owner, Device Owner and ISP

0, 5, 15, 30, 60 15 Collection interval

ISP IP Stats

Device Owner, ISP, Device Owner and ISP


Trunk Stats

Device Owner, Device Owner and ISP


VPRN Stats

ISP, Device Owner and ISP


VPRN Link Stats






Description


411-5221-926 Standard 10.07 June 2006

Interval (Minutes)

Memory Stats

Device Owner and Device Owner and ISP


Overload Stats

Device Owner and Device Owner and ISP


Session Management Stats



APN Stats ISP, Device Owner and ISP


GTP Data Stats



CGF Stats ISP, Device Owner and ISP


GTP Accounting Stats



IPSec Stats



L2TP/IPSec Stats



L2TP Stats



RADIUS Accounting Stats



Wireless Service Stats



SCP Stats ISP, Device Owner and ISP





Description



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

GRE Stats ISP, Device Owner and ISP


Ancillary APN Stats



APN Data Stats



VRF Stats ISP, Device Owner and ISP


MPLS Stats



DCC Stats ISP, Device Owner and ISP


DHCP Stats



Local Addr Pool Stats



Content Filter Stats






Description


411-5221-926 Standard 10.07 June 2006

Figure 8-115Radius Profile Configuration

Table 8-90Radius Profile General Tab

Modified Field Name


Field Description

Profile Name Alphanumeric string

None Identifies the Radius Profile.

Timeout Integer (1-65535)

3 Number of seconds allowed for an acknowledgement packet from the RADIUS server to reach the GGSN before timing out.



Retries Integer (1-65535)

3 Number of tries allowed for the GGSN to establish a connection to the RADIUS server.

Authentication UDP Port

Integer (1-65535)

1812 UDP Port carrying authentication data.

Accounting UDP Port

Integer (1-65535)

1813 UDP port used for transmitting accounting data.

CBB VSA Version

Version 1, 2, 3 and 4

Version 1

Version 1: Includes uplink/downlink 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

Version 3: Includes uplink/downlink volume usage and time usage per content type id

Version 4: Includes uplink/downlink volume usage, time usage and event count per content type id

Trim Domain Name


Not Selected

When checked GGSN removes the domain portion of the subscriber name before sending it to the RADIUS server.

Trim Realm Selected or Not Selected

Not Selected

When checked the GGSN trims the ISP by realm during ISP selection, using the login format domain/user instead of usre@domain.

Trim User Name


Not Selected

When checked, the SER 5500 strips 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 string

empty When Trim User Name is enabled, 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.



411-5221-926 Standard 10.07 June 2006

Retype Password

Alphanumeric string

empty When Trim User Name is enabled, 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 Attribute

Selected or

Not Selected

Not Selected

Selected, if RADIUS Framed-Pool name attribute should be used for IP address assignment from local reserved and unreserved address pools

Framed-Pool Error Log

Selected or

Not Selected

Not Selected

Selected, if a log shall be generated when no framed pool has been found.

Include IMSI Attribute


Not Selected

Enable/disable sending IMSI Attribute in RADIUS Authentication and Accounting messages.

Include MSISDN Attribute


Selected

Enable/Disable sending MSISDN Attribute in RADIUS Authentication and Accounting messages.

Use ISP address as source address


Not Selected

Select this field to send the ISP IP address as source address for all the packets that are sent from GGSN to the Radius Server.

Include NAS Port Attribute


Not Selected

Enable/Disable sending NAS Port 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-116Radius Profile, Radius Servers Tab


411-5221-926 Standard 10.07 June 2006

Figure 8-117RADIUS Profile Advanced Setting Page

Service Policy ManagerA Content Based Billing icon has been added to the Service Policy list on the Service Policy Manager page as shown in Figure 8-118.

Table 8-91RADIUS Profile Advanced Setting Tab


Description

Accounting- On Retry Timeout

0 - 900 9 The period for which Accounting-On will be sent to Accounting RADIUS Server until a valid reply is sent back.

Hold Authentication Period

0 - 1800 0 During this period we will hold all authentication request to the Authentication RADIUS Server which also acts as a Accounting RADIUS Server and we have sent an Accounting-On request to that server.



Figure 8-118Service Policy Manager Page

Changes To CBB Policy Action Dialog for POP3The CBB policy Action dialog is enhanced to support new action filters. Figure 8-119 shows the action filter for POP3 being activated when the service is pop3.


411-5221-926 Standard 10.07 June 2006

Figure 8-119Action Filters For POP3

Changes To CBB Policy Action Dialog for SMTPThe CBB policy action dialog is enhanced to support new action filters. Figure 8-120 shows the action filter for SMTP being activated when the service is SMTP.



Figure 8-120Action 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-121 shows the action filter for IMAP4 being activated when the service is imap4.


411-5221-926 Standard 10.07 June 2006

Figure 8-121Action of Filters For IMAP4

URL Rating Dialog in CBB PolicyThe URL rating configuration Dialog is modified to include new information for Per-Get Billing.



Table 8-92Edit/Add URL Ids (Per-get Billing)

Table 8-93Edit/add URL IDs

Modified Field Name


Field Description

URL Path Case Sensitive


Not Selected

Indicates if the URL string is case sensitive or not.

Content Type ID Uplink


Content Type ID Downlink



411-5221-926 Standard 10.07 June 2006

CBB Provisioning ToolCBB 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.

Coupon ID Uplink

0-65535 None Coupon ID for uplink data packets count

Coupon ID Downlink





0-65535 None Coupon ID for uplink/downlink data packets count and event usage count per GET event






Table 8-93Edit/add URL IDs



Figure 8-122XML 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 PageA 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.


411-5221-926 Standard 10.07 June 2006

Figure 8-123Access Properties Profiles and Keys Page

Table 8-94Access Properties Profiles and Keys Tab


Description

Global Attributes Profile

string default The Global Attributes profile associated with this device.

Redundancy Profile

profile name

default The “Redundancy Profile” text input field associates the redundancy profile to an ISP device.



Address Pool ConfigurationThe blackout time period value is added to the Address Pool Configuration page.

Enable Charging Characteristics


Not Selected

To control whether use Charging Characteristics IE in the Create PDP Context Request message for RADIUS Authentication.

Table 8-94Access Properties Profiles and Keys Tab


Description


411-5221-926 Standard 10.07 June 2006

Figure 8-124Address Pool Configuration Page



Table 8-95Address Pool Configuration Table


Description

Address Pool Name: Reserved


Not Selected

If Selected, this is a 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: Deactivated


Not Selected

If Selected, this pool is 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


411-5221-926 Standard 10.07 June 2006

ISP ConfigurationFigure 8-125MCC and MNC configuration on ISP Configuration / ISP’s Devices



Notification ProfilesNotification 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-126Category Selection Dialog

Table 8-96GGSN-MCC-MNC configuration


Mobile Country Code 3 character numerical string

None Mobile country code

Mobile Network Code 2 or 3 character numerical string

None Mobile network code

Table 8-97Event categories list

Field Name

Field Range Default Value Field Description

Event Category

GTP, GTP Accounting, SCP, WRAP, GGSN AAA, DCC, LI, Health Check Monitor, CFS

None Name of Event Category


411-5221-926 Standard 10.07 June 2006

Access Group ConfigurationAccess Groups are collections of subscribers that share common properties, including the RADIUS profile, DHCP profile, domain name server, and IGMP profile.

Figure 8-127Access Group Configuration

Access Group Configuration Group Management TabThe 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.

Editing Access Group Settings for Device dialogThe 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.

Table 8-98Access Group Configuration, Group Management Tab

Field Field Range Default Value

Description

Name Alphanumeric string (read-only)

None Identifies the access group.

Inherit Unspecified Values from Default Group


Not Selected

If selected, all unspecified field will use values inherit from Default Group.

Device Specific Settings table

A table list device specific access group settings


411-5221-926 Standard 10.07 June 2006

Figure 8-128Editing Access Group Settings for Device dialog



Table 8-99Editing Access Group Settings for Device dialog


Description

RADIUS Override for device


Not Selected

Enable/Disable RADIUS profile override.

RADIUS Profile Alphanumeric string (read-only)

None RADIUS profile assigned for the device to 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 for device


Not Selected

Enable/Disable DHCP profile override.

DHCP Profile Alphanumeric string (read-only)

None DHCP profile assigned for the device to override Access Group setting. Click Select to choose a DHCP profile from a Selection dialog box. Click Clear to erase the current profile.

CFS Override for device


Not Selected

Enable/Disable CFS profile override.

CFS Profile Alphanumeric string (read-only)

None CFS profile assigned for the device to override Access Group setting. Click Select to choose a CFS profile from a Selection dialog box. Click Clear to erase the current profile.

IGMP Profile Alphanumeric string (read-only)

None IGMP profile assigned for the device to override Access Group setting. Click Select to choose an IGMP profile from a Selection dialog box. Click Clear to erase the current profile.

MPLS Override for device


Not Selected

Enable/Disable MPLS settings override.

Route Distinguisher

Alphanumeric string (read-only)

None Route Distinguisher name assigned for the 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.


411-5221-926 Standard 10.07 June 2006

Import Route Target Profile


None Import Route Target profile assigned for the 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 Target Profile


None Export Route Target profile assigned for the 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 Aggregates

Configuration Button

None Click to open the dialog to config Vrf BGP Aggregates for the specific device

IP Address Pool Threshold Override for device


Not Selected

Enable/Disable IP Address Pool Threshold settings override.

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 address usage of the total address pool category (Reserved, Unreserved) per access group is allowed to be, before the Address 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 alarm. If both (Alarm Set and Alarm Clear) are set to 0%, no alarm is generated.

Session Parameters Override for Device


Not Selected

Enable/Disable session parameters settings override.

DNS Primary Address


None The domain name server used for the device to override access group setting.



Access Group Configuration Group Settings TabThe 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.

DNS Secondary Address


None The alternate domain name server used for the device to override access group setting.

NBNS Primary Address


None The NETBIOS name Service server address used for the device to override access group setting.

NBNS Secondary Address


None The backup address of the NBNS server used for the device to override access group setting.

Idle Timeout (min)

0 - 64800 0 Number of minutes a PDP session waits to 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 Timeout (hours)

0 - 48 0 Number of hours a PDP session is active 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.


411-5221-926 Standard 10.07 June 2006

Figure 8-129Access Group Configuration Group Settings Page



Table 8-100Access Group Configuration, Group Settings Tab


Description

RADIUS Profile Alphanumeric string (read-only)

None RADIUS profile assigned to the access group. Click Select to choose a RADIUS profile from a Selection dialog box. Click Clear to erase the current profile.

DHCP Profile Alphanumeric string (read-only)

None DHCP profile assigned to the access group. Click Select to choose a DHCP profile from a Selection dialog box. Click Clear to erase the current profile.

CFS Profile Alphanumeric string (read-only)

None CFS profile assigned to the access group. Click Select to choose a CFS profile from a Selection dialog box. Click Clear to erase the current profile.

IGMP Profile Alphanumeric string (read-only)

None IGMP profile assigned to the access group. Click Select to choose an IGMP profile from a Selection dialog box. Click Clear to erase the current profile.

Specify Session Parameters


Not Selected

Enables the fields for configuring session parameters.

DNS Primary Address


None The domain name server used for the access group.

DNS Secondary Address


None The alternate domain name server used for the access group.

NBNS Primary Address


None The NETBIOS name Service server address. NBNS automatically matches a computer's address and domain name once the computer registers its name on the NBNS server.

NBNS Secondary Address


None The backup address of the NBNS server.


411-5221-926 Standard 10.07 June 2006

Idle Timeout (min)

0 - 64800 0 Number of minutes a PDP session waits to 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 Timeout (hours)

0 - 48 0 Number of hours a PDP session is active 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.

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.



CORBA API User Interface 8Nortel 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 8CORBA 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.

Alarm Clear 0%, 30% - 90% 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 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 alarm. If both (Alarm Set and Alarm Clear) are set to 0%, no alarm is generated.


411-5221-926 Standard 10.07 June 2006



OA&M 9Overview 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 9This 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:

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

9-2 OA&MNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

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

• RADIUS

• APN

• CGF

OA&M 9-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


• 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


411-5221-926 Standard 10.07 June 2006

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 CountersThe 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 per Connection ISP

ISP

APN per APN per Connection ISP

ISP

CGF per CGF on Gn ISP or Ga ISP

ISP

L2TP per Connection ISP ISP

L2IP per Connection ISP ISP

IPSec per Connection ISP ISP

Overload Device Device Owner

Wireless Services per Connection ISP ISP

GRE per Connection ISP ISP



Accounting Group VersionEach 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

SCP per SCP server per CTP profile per Gi ISP

ISP

ISP-IP per Connection ISP Device Owner and ISP

Ancillary APN per APN per Connection ISP

ISP

APN Data Plane per APN per Connection ISP

ISP

MPLS per Connection ISP ISP

VRF per Connection ISP ISP

DCC per Diameter server per Diameter Profile per ISP

ISP

DHCP per DHCP Server per Connection ISP

ISP

Local Address Pool per Local Address Pool per Connection ISP

ISP

Content Filter per CF server per CF profile per Connection ISP/VPN

ISP

a. All Accounting Elements are visible using the combined DeviceOwner and ISP user privilege class.

Table 9-1 Scope of Nortel GGSN accounting groups

Accounting Group Scope User Privilegea


411-5221-926 Standard 10.07 June 2006

version numbers used for each release in the supported Nortel GGSN deployment.

Table 9-2 Accounting Group Version Number

Accounting Group

GGSNS2.0 GGSNS3.2 GGSNS4.0 GGSNS4.1 GGSN5.0

Memory 1 2 2 3

Session Management

1 3 4 5 6

GTP Data 1 3 3 4

GTP Accounting 1 3 3 4

RADIUS 1 2 2 3

APN 1 3 4 5 6

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 Services 1 2 2 3

GRE n/a 1 1 2

SCP n/a 1 2 3

ISP-IP n/a 3 3 4

Ancillary APN n/a 2 2 3

APN Data Plane n/a 1 1 2

MPLS n/a n/a 1 2 2

VRF n/a n/a 1 2 2

DCC n/a n/a 1 2 3

DHCP n/a n/a n/a 1

Local Address Pool

n/a n/a n/a 1



Collection MethodThe 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 StatisticsTable 9-3 describes the statistics that will be collected as part of the Memory Accounting Element group.

Table 9-3 Memory Counters

Content Filter n/a n/a n/a n/a 1

Description

Measurement Name 3GPP Name Collection Method

Size (bits)

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 interval

MEM.ReportingInterval

Gauge 32

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 Usage

MEM.totSystemMemUtil

Gauge 32

Table 9-2 Accounting Group Version Number

Accounting Group

GGSNS2.0 GGSNS3.2 GGSNS4.0 GGSNS4.1 GGSN5.0


411-5221-926 Standard 10.07 June 2006

Session Management StatisticsTable 9-4 lists the Session Management statistics which are supported on the Nortel GGSN.

Table 9-4 Session Management Counters

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 Free MEM.totSystemMemFree

Gauge 32

Spare counter for future enhancement purpose.Initialized to 0 and not pegged.

Spare counter MEM.spare1 TBD 32









Description


Size (bits)



SM.ReportingInterval Gauge 32

This counter counts all attempted sessions and is incremented upon receipt of a Create PDP Context Request

Attempted Session Establishments

SM.AttActPdpCtxt Counter 32

Description


Size (bits)



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

SM.DupAttActPdpCtxt Counter 32

This counter provides the current number of active sessions present at the end of the recording period.

Number of Simultaneous Active Sessions

SM.NbrActPdpCtxt Gauge 32

This counter provides the maximum number of active sessions present during the recording period.

Peak Number of Simultaneous Active Sessions

SM.MaxNbrActPdpCtxt High Tidemark Gauge

32

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 Establishments: Traffic Class (TC): Background; Allocation/Retention (A/R): Low

SM.AttActPdpCtxt.Bgrd.Low Counter 32

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: Low SM.AttActPdpCtxt.Conv.Low Counter 32

TC: Background; A/R: Medium

SM.AttActPdpCtxt.Bgrd.Medium

Counter 32

TC: Interactive; A/R Medium SM.AttActPdpCtxt.Intact.Medium

Counter 32

TC: Streaming; A/R Medium SM.AttActPdpCtxt.Strm.Medium

Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

TC: Conversational; A/R: Medium

SM.AttActPdpCtxt.Conv.Medium

Counter 32

TC: Background; A/R: High SM.AttActPdpCtxt.Bgrd.High Counter 32

TC: Interactive; A/R High SM.AttActPdpCtxt.Intact.High Counter 32

TC: Streaming; A/R High SM.AttActPdpCtxt.Strm.High Counter 32

TC: Conversational; A/R: High

SM.AttActPdpCtxt.Conv.High Counter 32

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 Establishments TC: Background; A/R: Low

SM.SuccActPdpCtxt.Bgrd.Low Counter 32

TC: Interactive; A/R Low SM.SuccActPdpCtxt.Intact.Low Counter 32

TC: Streaming; A/R Low SM.SuccActPdpCtxt.Strm.Low Counter 32

TC: Conversational; A/R: Low SM.SuccActPdpCtxt.Conv.Low Counter 32


SM.SuccActPdpCtxt.Bgrd.Medium

Counter 32

TC: Interactive; A/R Medium SM.SuccActPdpCtxt.Intact.Medium

Counter 32

TC: Streaming; A/R Medium SM.SuccActPdpCtxt.Strm.Medium

Counter 32


SM.SuccActPdpCtxt.Conv.Medium

Counter 32

TC: Background; A/R: High SM.SuccActPdpCtxt.Bgrd.High Counter 32

TC: Interactive; A/R High SM.SuccActPdpCtxt.Intact.High

Counter 32

TC: Streaming; A/R High SM.SuccActPdpCtxt.Strm.High Counter 32


SM.SuccActPdpCtxt.Conv.High Counter 32

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 Establishments

SM.FailActPdpCtxt.NORA Counter 32

Description


Size (bits)



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


SM.FailActPdpCtxt.NORA.Admin

Counter 32

This measurement provides the number of PDP context activations failed with return code “No Resource Available”. Pegged when no addresses left in the local address pool (GTPv0).


SM.FailActPdpCtxt.NORA.AllDynamicAddressesOccupied

Counter 32

This measurement provides the number of PDP context activations failed with return code “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)


SM.FailActPdpCtxt.NORA.Overload

Counter 32

This measurement provides the number of PDP context activations failed with return code “No Resource Available” due to memory exhaustion (GTPv0)


SM.FailActPdpCtxt.NORA.NoMemory

Counter 32

This measurement provides the number of session establishment failures and is incremented whenever there is an PDP context activation attempt after an APN is blacklisted.


SM.FailActPdpCtxt.NORA.ApnBlacklist

Counter 32

This measurement provides the number of PDP context activations failed with return code “No Resource Available” due to reasons other than “Admin”, “AllDynamicAddressesOccupied”, “Overload”, “UDPThresholdReject” ,“NoMemory” and “ApnBlacklist”.


SM.FailActPdpCtxt.NORA.Other

Counter 32

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 ADAO(All Dynamic Addresses Occupied). The reasons for this could be : Local address pools are depleted (GTPv1).


SM.FailActPdpCtxt.ADAO Counter 32

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 NOMA(No Memory Available).


SM.FailActPdpCtxt.NOMA Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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


SM.FailActPdpCtxt.MAPN Counter 32

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


SM.FailActPdpCtxt.UPAT Counter 32

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 UAUF(User Authentication Failure).


SM.FailActPdpCtxt.UAUF Counter 32

This measurement provides the number of PDP context activations failed with return code “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.


SM.FailActPdpCtxt.UAUF.External

Counter 32

This measurement provides the number of PDP context activations failed with return code “User Authentication Failure” due to internal error conditions.


SM.FailActPdpCtxt.UAUF.Internal

Counter 32

This measurement provides the number of PDP context activations failed with return code “User Authentication Failure” due to reasons other than “External” and “Internal”.


SM.FailActPdpCtxt.UAUF.Other Counter 32

Description


Size (bits)



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


SM.FailActPdpCtxt.SYSF Counter 32

This measurement provides the number of PDP context activations failed with return code “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).


SM.FailActPdpCtxt.SYSF.Admin

counter 32

This measurement provides the number of PDP context activations failed with return code “System Failure” due to reasons other than “Admin”.


SM.FailActPdpCtxt.SYSF.Other counter 32

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 SEME(Semantic or Syntactic TFT or Packet Filter Error). The reasons for this could be : Invalid traffic flow template format (GTPv1)


SM.FailActPdpCtxt.SEME counter 32

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


SM.FailActPdpCtxt.IEIN counter 32

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

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006


SM.FailActPdpCtxt.IMFT counter 32

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


SM.FailActPdpCtxt.OVLD counter 32

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 SVNS(Service Not Supported).


SM.FailActPdpCtxt.SVNS counter 32

This measurement provides the number of PDP context activations failed with return code “Service Not Specified” due to an invalid APN received.


SM.FailActPdpCtxt.SVNS.MissingAPN

counter 32

This measurement provides the number of PDP context activations failed with return code “Service Not Specified” due to an unknown PDP Address Type specified in the Create request.


SM.FailActPdpCtxt.SVNS.UnknownPDPAddressType

counter 32

This measurement provides the number of PDP context activations failed with return code “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


SM.FailActPdpCtxt.SVNS.Admin

counter 32

This measurement provides the number of PDP context activations failed with return code “Service Not Specified” due to reasons other than “MissingAPN”, “UnknownPDPAddressType” and “Admin”.


SM.FailActPdpCtxt.SVNS.Other

counter 32

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 NoResp(No Response) which is not sent.


SM.FailActPdpCtxt.NoResp counter 32

Description


Size (bits)



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”


SM.FailActPdpCtxt.NoResp.Admin

counter 32

This measurement provides the number of failed PDP context activations for which no 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).


SM.FailActPdpCtxt.NoResp.SGSNChange

counter 32

This counter counts duplicate create requests for which no reponse is sent . Ths counter is incremented upon receipt of a Create PDP Context Request for which a PDP context is being established or being torn down.


SM.FailActPdpCtxt.NoResp.Duplicate

counter 32

This measurement provides the number of failed PDP context activations for which no 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.


SM.FailActPdpCtxt.NoResp.FallBackFallForward

counter 32

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.


SM.FailActPdpCtxt.NoResp.UDPThresholdReject

Counter 32

This measurement provides the number of PDP context activations failed with return code “No Response Sent” due to error conditions other than “Admin”, “SGSNChange”, “Duplicate” and “FallBackFallForward”.


SM.FailActPdpCtxt.NoResp.Other

counter 32

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.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Attempted move PDP contexts - SSM Redundancy

SM.AttSsmrPdpCtxt Counter 32

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 contexts - SSM Redundancy

SM.SuccSsmrPdpCtxt Counter 32

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 Initiated PDP Context Deactivations

SM.AttDeactPdpCtxtMsAndSgsn

Counter 32

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.

Attempted GGSN Initiated PDP Context Deactivations

SM.AttDeactPdpCtxtGgsn Counter 32

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 deactivation - SSM Redundancy

SM.AttDeactPdpCtxtGgsn.Ssmr

Counter 32

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 deactivation - SSM Redundancy

SM.SuccDeactPdpCtxtGgsn.Ssmr

Counter 32

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 Mode Session Activations

SM.SuccActBamCtxt Counter 32

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.

Description


Size (bits)



Simultaneous Active Sessions Using Basic Access Mode

SM.NbrActBamCtxt Gauge 32

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 Activations

SM.SuccActIpsecCtxt Counter 32

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 Sessions Using IPSec Access Mode (member of a VPRN)

SM.NbrActIpsecCtxt Gauge 32

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.

Successful L2TP/IPSec Session Activations

SM.SuccActL2ipCtxt Counter 32

This measurement provides the current number of simultaneous active sessions using 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 Sessions Using L2TP/IPSec Access Mode

SM.NbrActL2ipCtxt Gauge 32

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 Activations

SM.SuccActL2tpCtxt Counter 32

This measurement provides the current number of simultaneous active sessions using 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 mode is successfully deleted.

Simultaneous Active Sessions Using L2TP Access Mode

SM.NbrActL2tpCtxt Gauge 32

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.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Number of Outbound Roamer Sessions Serviced

SM.SuccActRoamerCtxt Counter 32

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 Outbound Roamer Sessions

SM.NbrActRoamerCtxt Gauge 32

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 with bad header

SM.NbrBadGTPHeader Counter 32

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.

Number of GTP messages with bad packet size

SM.NbrBadGTPPktSize Counter 32

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

SM.AttDeactPdpCtxtGgsn.Manual

Counter 32

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

SM.SuccDeactPdpCtxtGgsn.Manual

Counter 32

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 Deactivation - Idle Timer

SM.AttDeactPdpCtxtGgsn.ITO Counter 32

This counter is incremented when a GGSN completes deactivation of 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.

Successful GGSN Initiated Deactivation - Idle Timer

SM.SuccDeactPdpCtxtGgsn.ITO

Counter 32

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.

Description


Size (bits)



Attempted GGSN Initiated Deactivation - Max Session Duration

SM.AttDeactPdpCtxtGgsn.MaxDur

Counter 32

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.

Successful GGSN Initiated Deactivation - Max Session Duration

SM.SuccDeactPdpCtxtGgsn.MaxDur

Counter 32

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.

Attempted GGSN Initiated Deactivation - SGSN Restart

SM.AttDeactPdpCtxtGgsn.SgsnRstrt

Counter 32

This counter is incremented when a GGSN completes deactivation of 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.

Successful GGSN Initiated Deactivation - SGSN Restart

SM.SuccDeactPdpCtxtGgsn.SgsnRstrt

Counter 32

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.

Attempted GGSN initiated deactivation - SSM Redundancy No Resource

SM.AttDeactPdpCtxtGgsn.Ssmr.NoResource

Counter 32

This measurement provides the number of PDP Context Successful Deactivations initiated 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

Successful GGSN initiated deactivation - SSM Redundancy No Resource

SM.SuccDeactPdpCtxtGgsn.Ssmr.NoResource

Counter 32

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.

Attempted GGSN initiated deactivation - SSM Redundancy No Second Move

SM.AttDeactPdpCtxtGgsn.Ssmr.NoSecondMove

Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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

Successful GGSN initiated deactivation - SSM Redundancy No Second Move

SM.SuccDeactPdpCtxtGgsn.Ssmr.NoSecondMove

Counter 32

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.

Attempted GGSN initiated deactivation - SSM Redundancy System Failure

SM.AttDeactPdpCtxtGgsn.Ssmr.SystemFailure

Counter 32

This measurement provides the number of PDP Context Successful Deactivations initiated by GGSN due to system failure during SSM Redundancy. It is incremented by 1 when PDP Context is successfully taken down from GGSN.

Successful GGSN initiated deactivation - SSM Redundancy System Failure

SM.SuccDeactPdpCtxtGgsn.Ssmr.SystemFailure

Counter 32

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.

Attempted GGSN initiated deactivation - SSM Redundancy for Aggregation is disabled

SM.AttDeactPdpCtxtGgsn.Ssmr.Disabled

Counter 32

This measurement provides the number of aggregation PDP Context Successful 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.

Successful GGSN initiated deactivation - SSM Redundancy for Aggregation is disabled

SM.SuccDeactPdpCtxtGgsn.Ssmr.Disabled

Counter 32

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 an Aggregation session

SM.AttActAggrCtxt Counter 32

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”

Description


Size (bits)



Successful establishments of an Aggregation session

SM.SuccActAggrCtxt Counter 32

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

SM.NbrActAggrCtxt Gauge 32

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 mis-matches encountered

SM.NbrConfigMism Counter 32

This counter shows the number of non-duplicate PPP sessions that were processed by an APN configured for aggregation.

Number of attempted PPP session establishments on an Aggregation APN.

SM.AttActAggrPPP Counter 32

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 Activations

SM.SuccActGreCtxt Counter 32

This measurement provides the current number of simultaneous active sessions using 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 mode is successfully deleted.

Simultaneous Active Sessions Using GRE Access Mode (member of a VPRN)

SM.NbrActGreCtxt Gauge 32

This measurement provides the current number of simultaneous active sessions using 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 Prepaid Sessions

SM.NbrActPrepaidCtxt Gauge 32

This counter provides the maximum number of active Basic Access Mode (untunneled) sessions present during the recording period.

Peak Number of Simultaneous Active Basic Access Mode Sessions

SM.MaxNbrActBamCtxt High Tidemark Gauge

32

This counter provides the maximum number of active IPSec sessions present during the recording period.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Peak Number of Simultaneous Active IPSec Sessions

SM.MaxNbrActIPSecCtxt High Tidemark Gauge

32

This counter provides the maximum number of active L2TP sessions present during the recording period.

Peak Number of Simultaneous Active L2TP Sessions

SM.MaxNbrActL2tpCtxt High Tidemark Gauge

32

This counter provides the maximum number of active L2TP/IPSec sessions present during the recording period.

Peak Number of Simultaneous Active L2TP/IPSec Sessions

SM.MaxNbrActL2ipCtxt High Tidemark Gauge

32

This counter provides the maximum number of active GRE sessions present during the recording period.

Peak Number of Simultaneous Active GRE Sessions

SM.MaxNbrActGreCtxt High Tidemark Gauge

32

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 Simultaneous Active Prepaid Sessions

SM.MaxNbrActPrepaidCtxt High Tidemark Gauge

32

This counter provides the maximum number of active aggregation sessions present during the recording period.

Peak Number of Simultaneous Active Aggregation Sessions

SM.MaxNbrAggrActCtxt High Tidemark Gauge

32

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 Simultaneous Active Services sessions without IP Subnet Dedication

SM.MaxNbrSvcActCtxt High Tidemark Gauge

32

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 Secondary PDP Context Establishments

SM.AttActSecPdpCtxt Counter 32

Description


Size (bits)



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 Secondary PDP Context Establishments

SM.SuccActSecPdpCtxt Counter 32

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 Simultaneous Secondary PDP Context Establishments

SM.NbrActSecPdpCtxt Gauge 32

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 Subscribers using Secondary PDP Contexts

SM.NbrActMsSecInUse Gauge 32

This counter provides the maximum number of mobile subscribers using Secondary PDP contexts.

Peak Number of Mobile Subscribers using Secondary PDP Contexts

SM.MaxNbrActMsSecInUse High Tidemark Gauge

32

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 Activations

SM.SuccActMPLSCtxt Counter 32

This measurement provides the current number of simultaneous active sessions using 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 mode is successfully deleted.

Simultaneous Active Sessions Using MPLS Access Mode

SM.NbrActMPLSCtxt Gauge 32

This counter provides the maximum number of active MPLS sessions present during the recording period.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Peak Number of Simultaneous Active MPLS Sessions

SM.MaxNbrActMPLSCtxt High Tidemark Gauge

32

This measurement provides the number of sessions that were created with Content Filtering enabled.

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 Sessions with CBB

SM.MaxNbrActCbbCtxt High Tidemark Gauge

32

Number of GTP packets dropped at UDP level due to UDP queue overflow on the CMC.

GTP Control packet lost SM.GTPDropPktUDPQueueOvfl

Counter 32

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.SuccActCtxtPcscfDiscReq Counter 32

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 Failed

SM.SuccActCtxtPcscfDiscFailed

Counter 32

This measurement provides the current number of active context bundles that successfully requested P-CSCF Address Discovery.

Simultaneous Active Sessions Requesting P-CSCF Discovery

SM.NbrActPcscfDiscCtxt Gauge 32

This measurement provides the maximum number of simultaneous active context bundles that successfully requested P-CSCF Address Discovery.

Peak Number of Simultaneous Active Sessions Requesting P-CSCF Discovery

SM.MaxNbrActPcscfDiscCtxt High Tidemark Gauge

32

Description


Size (bits)



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.

Number of Successful Aggregation Context Activations with Policy Control

SM.SuccActCtxt.Aggr.PolCtrl Counter 32

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 Policy Control Updates

SM.Aggr.PolCtrlPdfUpd Counter 32

This counter provides the current number of GGSN initiated policy control updates for aggregation contexts.

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 Policy Control Updates

SM.Aggr.PolCtrlGgsnUpd Counter 32

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

SM.Aggr.PolCtrlRuleOps Counter 32

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

Number of Active Simultaneous Policy Control Rules

SM.Aggr.ActivePolCtrlRules Gauge 32

This gauge provides the highest number of simultaneous dynamic policy control rules present for active aggregation contexts during the recording period.

High Tidemark of Simultaneous Policy Control Rules

SM.Aggr.MaxNbrPolCtrlRules High Tidemark Gauge

32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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

Successful VPN session activations

SM.SuccActVpnCtxt Counter 32

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 session activations with IP Subnet Dedication

SM.SuccActSvcSubnetCtxt Counter 32

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 session activations without IP Subnet Dedication

SM.SuccActSvcCtxt Counter 32

This measurement provides the maximum number of Simultaneous Active VPN (VPN variants include IPSec, GRE, ATM, VLAN, MPLS and GGSN VPRN) sessions present during the recording period.

Peak number of Simultaneous Active VPN sessions

SM.MaxNbrActVpnCtxt High Tidemark Gauge

32

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 the recording period.

Peak number of Simultaneous Active Services sessions with IP Subnet Dedication

SM.MaxNbrSvcSubnetActCtxt High Tidemark Gauge

32

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 PDP Context deletions

SM.SuccAggrCtxtDelete Counter 32

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.

Description


Size (bits)



Successful VPN PDP Context deletions

SM.SuccVpnCtxtDelete Counter 32

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 Subnet Dedication PDP Context deletions

SM.SuccSvcSubnetCtxtDelete Counter 32

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 without IP Subnet Dedication PDP Context deletions

SM.SuccSvcCtxtDelete Counter 32

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

SM.SuccL2tpCtxtDelete Counter 32

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 PDP Context Updates

SM.SuccAggrCtxtUpdate Counter 32

This measurement provides the number of successfully performed 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 Context Updates

SM.SuccVpnCtxtUpdate Counter 32

This measurement provides the number of successfully performed PDP 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 transmission/receipt of an Update PDP Context Response message with cause “Request Accepted”.

Successful Services with IP Subnet Dedication PDP Context Updates

SM.SuccSvcSubnetCtxtUpdate Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

This measurement provides the number of successfully performed PDP context updates 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 transmission/receipt of an Update PDP Context Response message with cause “Request Accepted”.

Successful Services without IP Subnet Dedication PDP Context Updates

SM.SuccSvcCtxtUpdate Counter 32

This measurement provides the number of successfully performed 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 Context Updates

SM.SuccL2tpCtxtUpdate Counter 32

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 sessions using GTP accounting

SM.NbrActAggrCtxt.GtpAcct Gauge 32

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

SM.NbrActVpnCtxt.GtpAcct Gauge 32

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 incremented if an active session is using GTP accounting and decremented at session end.

Active Services sessions with IP Subnet Dedication using GTP accounting

SM.NbrActSvcSubnetCtxt.GtpAcct

Gauge 32

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 without IP Subnet Dedication using GTP accounting

SM.NbrActSvcCtxt.GtpAcct Gauge 32

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 incremented if an active session is using GTP accounting and decremented at session end.

Active L2TP VPN sessions using GTP accounting

SM.NbrActL2tpCtxt.GtpAcct Gauge 32

Description


Size (bits)



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 session activations using DHCP

SM.SuccActAggrCtxt.Dhcp Counter 32

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 activations using DHCP

SM.SuccActVpnCtxt.Dhcp Counter 32

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 incremented for successful primary PDP context creations using DHCP based IP address allocation.

Successful Services session activations with IP Subnet Dedication using DHCP

SM.SuccActSvcSubnetCtxt.Dhcp

Counter 32

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 incremented for successful primary PDP context creations using DHCP based IP address allocation.

Successful Services session activations without IP Subnet Dedication using DHCP

SM.SuccActSvcCtxt.Dhcp Counter 32

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 incremented after successful establishment and decremented at session end.

Number of currently active VPN sessions

SM.NbrActVpnCtxt Gauge 32

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.

Number of currently active Services sessions with IP Subnet Dedication

SM.NbrActSvcSubnetCtxt Gauge 32

This measurement provides the current number of Simultaneous Active Services sessions without IP Subnet Dedication for the Wireless ISP network model. This counter is incremented after successful establishment and decremented at session end.

Number of currently active Services sessions without IP Subnet Dedication

SM.NbrActSvcCtxt Gauge 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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 activations using Radius Authentication

SM.SuccActCtxt.RadiusAuth Counter 32

This measurement provides the number of successful establishment of sessions using Radius Accounting. This counter is incremented for successfully established sessions using Radius Accounting.

Successful session activations using Radius Accounting

SM.SuccActCtxt.RadiusAcct Counter 32

This measurement provides the number of successful establishment of sessions using Prepaid solution (DCC or CTP).

Successful session activations using Prepaid solution

SM.SuccActPrepaidCtxt Counter 32

This measurement provides the number of successful re-authentication with Prepaid server (DCC or CTP).

Successful re-authentication with Prepaid server

SM.SuccPrepaidReAuth Counter 32

This measurement provides the number of successful establishment of sessions using Content Based Billing for the Aggregation APN.

Successful Aggregation session activations with Content Based Billing

SM.SuccActAggrCtxt.Cbb Counter 32

This measurement provides the number of successful establishment of sessions using firewall for the Aggregation APN.

Successful Aggregation session activations with firewall

SM.SuccActAggrCtxt.Fw Counter 32

This measurement provides the number of successful establishment of sessions using Anti-spoofing for the Aggregation APN.

Successful Aggregation session activations with Anti-spoofing

SM.SuccActAggrCtxt.Aspoof Counter 32

This measurement provides the number of successful establishment of sessions using Policy Based Forwarding for the Aggregation APN.

Successful Aggregation session activations with Policy Based Forwarding

SM.SuccActAggrCtxt.Pbf Counter 32

Description


Size (bits)



GTP Data StatisticsTable 9-5 describes the statistics that will be collected as part of the GTP Data Accounting Element group.

Table 9-5 GTP Data Counters

This measurement provides the number of successful establishment of sessions using Traffic Shaping for the Aggregation APN.

Successful Aggregation session activations with Traffic Shaping

SM.SuccActAggrCtxt.Shape Counter 32

This measurement provides the number of successful establishment of sessions using Policing for the Aggregation APN.

Successful Aggregation session activations with Policing

SM.SuccActAggrCtxt.Police Counter 32


Spare counter SM.spare1 TBD 32









Description

Measurement Name 3GPP Name Collection Method Size (bits)



GTP.ReportingInterval Gauge 32

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 Packets GTP.DiscDataPkt Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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.

Received GTP Data Packets

Traffic Class (TC): Background; Allocation/Retention (A/R): Low

GTP.IncDataPkt.Bgrd.Low Counter 64

TC: Interactive; A/R Low GTP.IncDataPkt.Intact.Low Counter 64

TC: Streaming; A/R Low GTP.IncDataPkt.Strm.Low Counter 64

TC: Conversational; A/R: Low GTP.IncDataPkt.Conv.Low Counter 64


GTP.IncDataPkt.Bgrd.Medium

Counter 64

TC: Interactive; A/R Medium GTP.IncDataPkt.Intact.Medium

Counter 64

TC: Streaming; A/R Medium GTP.IncDataPkt.Strm.Medium

Counter 64


GTP.IncDataPkt.Conv.Medium

Counter 64

TC: Background; A/R: High GTP.IncDataPkt.Bgrd.High Counter 64

TC: Interactive; A/R High GTP.IncDataPkt.Intact.High

Counter 64

TC: Streaming; A/R High GTP.IncDataPkt.Strm.High Counter 64


GTP.IncDataPkt.Conv.High Counter 64

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

Traffic Class (TC): Background; Allocation/Retention (A/R): Low

GTP.OutDataPkt.Bgrd.Low Counter 64

TC: Interactive; A/R Low GTP.OutDataPkt.Intact.Low

Counter 64

TC: Streaming; A/R Low GTP.OutDataPkt.Strm.Low Counter 64

TC: Conversational; A/R: Low GTP.OutDataPkt.Conv.Low

Counter 64


GTP.OutDataPkt.Bgrd.Medium

Counter 64

Description




TC: Interactive; A/R Medium GTP.OutDataPkt.Intact.Medium

Counter 64

TC: Streaming; A/R Medium GTP.OutDataPkt.Strm.Medium

Counter 64


GTP.OutDataPkt.Conv.Medium

Counter 64

TC: Background; A/R: High GTP.OutDataPkt.Bgrd.High

Counter 64

TC: Interactive; A/R High GTP.OutDataPkt.Intact.High

Counter 64

TC: Streaming; A/R High GTP.OutDataPkt.Strm.High

Counter 64


GTP.OutDataPkt.Conv.High

Counter 64

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 Octets

GTP.IncDataOct.Bgrd.Low Counter 64

TC: Interactive; A/R Low GTP.IncDataOct.Intact.Low

Counter 64

TC: Streaming; A/R Low GTP.IncDataOct.Strm.Low Counter 64

TC: Conversational; A/R: Low GTP.IncDataOct.Conv.Low Counter 64


GTP.IncDataOct.Bgrd.Medium

Counter 64

TC: Interactive; A/R Medium GTP.IncDataOct.Intact.Medium

Counter 64

TC: Streaming; A/R Medium GTP.IncDataOct.Strm.Medium

Counter 64


GTP.IncDataOct.Conv.Medium

Counter 64

TC: Background; A/R: High GTP.IncDataOct.Bgrd.High Counter 64

TC: Interactive; A/R High GTP.IncDataOct.Intact.High

Counter 64

TC: Streaming; A/R High GTP.IncDataOct.Strm.High Counter 64


GTP.IncDataOct.Conv.High

Counter 64

Description



411-5221-926 Standard 10.07 June 2006

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

Counter 64

TC: Interactive; A/R Low GTP.OutDataOct.Intact.Low

Counter 64

TC: Streaming; A/R Low GTP.OutDataOct.Strm.Low

Counter 64

TC: Conversational; A/R: Low GTP.OutDataOct.Conv.Low

Counter 64


GTP.OutDataOct.Bgrd.Medium

Counter 64

TC: Interactive; A/R Medium GTP.OutDataOct.Intact.Medium

Counter 64

TC: Streaming; A/R Medium GTP.OutDataOct.Strm.Medium

Counter 64


GTP.OutDataOct.Conv.Medium

Counter 64

TC: Background; A/R: High GTP.OutDataOct.Bgrd.High

Counter 64

TC: Interactive; A/R High GTP.OutDataOct.Intact.High

Counter 64

TC: Streaming; A/R High GTP.OutDataOct.Strm.High

Counter 64


GTP.OutDataOct.Conv.High

Counter 64

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


Spare counter GTP.spare1 TBD 64



Description




GTP Accounting StatisticsTable 9-6 describes the statistics that will be collected as part of the 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


Size (bits)



GTPP.ReportingInterval Gauge 32

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

Description



411-5221-926 Standard 10.07 June 2006

Attempted CDR Information Transfers

GTPP.CdrTransfReq.CDRC

Counter 32

GTPP.CdrTransfReq.AREL Counter 32

GTPP.CdrTransfReq.DVLM

Counter 32

GTPP.CdrTransfReq.MCCC

Counter 32

GTPP.CdrTransfReq.MGTI Counter 32

GTPP.CdrTransfReq.TLEX Counter 32

GTPP.CdrTransfReq.SCHG

Counter 32

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

Successful/Failed CDR Information Transfers

GTPP.SuccCdrTransf Counter 32

GTPP.FailCdrTransf.FQAF Counter 32

GTPP.FailCdrTransf.INMF (not supported)

Counter 32

GTPP.FailCdrTransf.MIEI (not supported)

Counter 32

GTPP.FailCdrTransf.MIEM (not supported)

Counter 32

GTPP.FailCdrTransf.NRAV Counter 32

GTPP.FailCdrTransf.OIEI (not supported)

Counter 32

GTPP.FailCdrTransf.RQNF Counter 32

GTPP.FailCdrTransf.SVNS (not supported)

Counter 32

GTPP.FailCdrTransf.SYSF Counter 32

GTPP.FailCdrTransf.VNSU Counter 32

This measurement provides the number of redirection requests received by GTP accounting

Number of GTP accounting Redirection Requests received

GTPP.RedirRequestRecvd Counter 32

Description


Size (bits)



RADIUS StatisticsTable 9-7 describes the statistics that will be collected as part of the RADIUS accounting Element group.

Table 9-7 RADIUS Counters

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 GTP accounting packets

GTPP.NbrGTPPTimeouts Counter 32

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” for GTP accounting packets

GTPP.NbrGTPPNoResp Counter 32

This measurement provides the number of GTP accounting protocol errors that have occurred in the GGSN

Number of GTP accounting protocol errors

GTPP.NbrProtErrors Counter 32


Spare counter GTPP.spare1 TBD 32









Description


Size (bits)



RAD.ReportingInterval

Gauge 32

The IP Address of the RADIUS server.

RADIUS Server RAD.Server Identifier 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

This counter is pegged upon fist transmission of RADIUS Accounting On messages, RADIUS Accounting Start and Stop messages.

Attempted CDR Information Transfers

RAD.AcctTransfReq Counter 32

This counter is pegged on retransmission of a RADIUS Accounting On, RADIUS Accounting Start or RADIUS Accounting Stop message.

CDR Information Retransmissions

RAD.AcctRetrans Counter 32

This counter is pegged on receipt of a RADIUS Accounting Response.

Successful CDR Information Transfers

RAD.AcctResponseRcvd

Counter 32

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 Round Trip Time

RAD.AcctAvgRTT Counter 32

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 Requests

RAD.AcctPendingRequests

Gauge 32

Description


Size (bits)



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

RAD.AcctMaxPendingRequests

High Tidemark Gauge

32

Number of Accounting Requests that timed out waiting for Accounting Response from the RADIUS server.

RADIUS AccClient Time-outs RAD.AcctTimeOuts Counter 32

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

RAD.AcctMalformedResponses

Counter 32

Number of Accounting Response packets received from the RADIUS server which contained invalid authenticators.

RADIUS Acc Client Bad Authenticators

RAD.AcctBadAuthenticators

Counter 32

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

RAD.AcctUnknownTypes

Counter 32

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.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

RADIUS AccClient Packets Dropped

RAD.AcctPacketsDropped

Counter 32

Number of Access Request packets sent to RADIUS server excluding retransmissions.

RADIUS Auth Access request RAD.AuthAccessRequests

Counter 32

Number of Access Request packets retransmitted to RADIUS server.

RADIUS Auth Client Access Retransmissions

RAD.AuthAccessRetransmissions

Counter 32

Number of Access Accept packets received from RADIUS server.

RADIUS Auth Access Accept RAD.AuthAccessAccepts

Counter 32

Number of Access Reject packets received from RADIUS server.

RADIUS Auth Access Rejects RAD.AuthAccessRejects

Counter 32

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 Round Trip Time

RAD.AuthAvgRTT Counter 32

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

RAD.AuthPendingRequests

Gauge 32

Description


Size (bits)



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

RADIUS Auth Client Max Pending Requests

RAD.AuthMaxPendingRequests

High Tidemark Gauge

32

Number of Access Requests that timed out waiting for Access Response from the RADIUS server.

RADIUS Auth Client Time-outs

RAD.AuthTimeouts Counter 32

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 Malformed Access Responses

RAD.AuthMalformedAccessResponses

Counter 32

Number of Access Response packets received from the RADIUS server which had invalid authenticators or signature attributes.

RADIUS Auth Client Bad Authenticators

RAD.AuthBadAuthenticators

Counter 32

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

RAD.AuthUnknownTypes

Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

APN StatisticsTable 9-8 describes the statistics that will be collected as part of the APN Accounting Element group.

Table 9-8 APN Counters

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

RAD.AuthPacketsDropped

Counter 32


Spare counter RAD.spare1 TBD 32









Description


Size (bits)



SM.ReportingInterval.Apn Gauge 32

The provisioned name of the APN.

APN Name SPM_APN_NAME Identifier 64 characters

Description


Size (bits)



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

SM.NbrActPdpCtxt.Apn.Bgrd.Low

Gauge 32

TC: Interactive; A/R: Low

SM.NbrActPdpCtxt.Apn.Intact.Low

Gauge 32

TC: Streaming; A/R Low

SM.NbrActPdpCtxt.Apn.Strm.Low

Gauge 32

TC: Conversational; A/R Low

SM.NbrActPdpCtxt.Apn.Conv.Low

Gauge 32


SM.NbrActPdpCtxt.Apn.Bgrd.Medium

Gauge 32

TC: Interactive; A/R: Medium

SM.NbrActPdpCtxt.Apn.Intact.Medium

Gauge 32

TC: Streaming; A/R Medium

SM.NbrActPdpCtxt.Apn.Strm.Medium

Gauge 32

TC: Conversational; A/R Medium

SM.NbrActPdpCtxt.Apn.Conv.Medium

Gauge 32

TC: Background; A/R: High

SM.NbrActPdpCtxt.Apn.Bgrd.High

Gauge 32

TC: Interactive; A/R: High

SM.NbrActPdpCtxt.Apn.Intact.High

Gauge 32

TC: Streaming; A/R High

SM.NbrActPdpCtxt.Apn.Strm.High

Gauge 32

TC: Conversational; A/R High

SM.NbrActPdpCtxt.Apn.Conv.High

Gauge 32

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

SM.AttActPdpCtxt.Apn Counter 32

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

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Successfully Established MS-Initiated sessions

SM.SuccActPdpCtxt.Apn Counter 32

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-Initiated Session Activations with Dynamic PDP Address Allocation Required

SM.AttDynActPdpCtxt.Apn Counter 32

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 Established MS-Initiated sessions with Dynamic PDP Address Allocation Required

SM.SuccDynActPdpCtxt.Apn Counter 32

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.

Attempted Session Establishments with User Authentication Required

SM.AttActPdpCtxtAutReq.Apn Counter 32

This measurement provides the number of PDP context activation procedures which failed due to AAA and SCP authentication failure.

Failed Session Establishments Due to AAA and SCP Authentication Failure

SM.FailActPdpCtxtAutReq.Apn Counter 32

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 Establishments Due to RADIUS Failure

SM.FailActPdpCtxtAuthReq.Radius.Apn

Counter 32

This measurement provides the number of session establishment failures per APN and is incremented whenever there is a SCP related failure for an APN

Description


Size (bits)



Failed Session Establishments Due to SCP Failure

SM.FailActPdpCtxtAuthReq.SCP.Apn

Counter 32

This measurement provides the number of session establishment failures per APN and is incremented whenever there is a Diameter related failure for an APN

Failed Session Establishments Due to Diameter Failure

SM.FailActPdpCtxtAuthReq.Diameter.Apn

Counter 32

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 contexts - SSM Redundancy

SM.AttSsmrPdpCtxt.Apn Counter 32

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 PDP contexts - SSM Redundancy

SM.SuccSsmrPdpCtxt.Apn Counter 32

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.

Attempted MS- and SGSN-Initiated Session Conclusions

SM.AttDeactPdpCtxtMsAndSgsn.Apn

Counter 32

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 SGSN-Initiated Session Conclusions

SM.SuccDeactPdpCtxtMsAndSgsn.Apn

Counter 32

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-Initiated Session Conclusions

SM.AttDeactPdpCtxtGgsn.Apn Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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-Initiated Session Conclusions

SM.SuccDeactPdpCtxtGgsn.Apn

Counter 32

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 initiated deactivation - SSM Redundancy

SM.AttDeactPdpCtxtGgsn.Ssmr.Apn

Counter 32

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 initiated deactivation - SSM Redundancy

SM.SuccDeactPdpCtxtGgsn.Ssmr.Apn

Counter 32

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 Simultaneous Active Sessions

SM.MaxNbrActPdpCtxt.Apn High Tidemark Gauge

32

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- & SGSN-Initiated PDP Context Updates

SM.AttUpdPdpCtxtMsAndSgsn.Apn

Counter 32

This measurement provides the number of successfully performed PDP context updates, and is incremented on transmission of an Update PDP Context message with cause “Request Accepted”.

Successfully Performed MS- & SGSN-Initiated PDP Context Updates

SM.SuccUpdPdpCtxtMsAndSgsn.Apn

Counter 32

This measurement provides the number of PDP context updates generated by the GGSN, retransmissions excluded.

Attempted GGSN-Initiated PDP Context Updates

SM.AttUpdPdpCtxtGgsn.Apn Counter 32

Description


Size (bits)



This measurement provides the number of successfully performed PDP context updates, and is incremented on receipt of an Update PDP Context response message with cause “Request Accepted”.

Successfully Performed GGSN-Initiated PDP Context Updates

SM.SuccUpdPdpCtxtGgsn.Apn Counter 32

Counts number of context creation requests rejected due to either APN administrative state disabled, or ISP operational state down.

PDP Context failed due to APN down.

SM.FailActPdpCtxtApnDown.Apn

Counter 32

Counts number of context creation requests rejected due to IP address unavailability from loacal address pools.

PDP Context failed due to unavailable IP addresses in local address pools.

SM.FailActPdpCtxtNoIPfound.Apn

Counter 32

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 with Dynamic IP Address

SM.NbrDynActPdpCtxt.Apn Gauge 32

Active PDP Context with Static IP Address

SM.NbrStaticActPdpCtxt.Apn Gauge 32

This counter is incremented when a GGSN attempts to deactivate a GTP context due to manual intervention.

Attempted GGSN Initiated Deactivation - Manual

SM.AttDeactPdpCtxtGgsn.Manual.Apn

Counter 32

This counter is incremented when a GGSN completes deactivation of a GTP context due to manual intervention

Successful GGSN Initiated Deactivation - Manual

SM.SuccDeactPdpCtxtGgsn.Manual.Apn

Counter 32

This counter is incremented when a GGSN attempts to deactivate a GTP context due to expiry of the idle timer.

Attempted GGSN Initiated Deactivation - Idle Timer

SM.AttDeactPdpCtxtGgsn.ITO.Apn

Counter 32

This counter is incremented when a GGSN completes deactivation of a GTP context due to expiry of the idle timer.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Successful GGSN Initiated Deactivation - Idle Timer

SM.SuccDeactPdpCtxtGgsn.ITO.Apn

Counter 32

This counter is incremented when a GGSN attempts to deactivate a GTP context due to expiry of the maximum session duration timer.

Attempted GGSN Initiated Deactivation - Max Session Duration

SM.AttDeactPdpCtxtGgsn.MaxDur.Apn

Counter 32

This counter is incremented when a GGSN completes deactivation of a GTP context due to expiry of the maximum session duration timer.

Successful GGSN Initiated Deactivation - Max Session Duration

SM.SuccDeactPdpCtxtGgsn.MaxDur.Apn

Counter 32

This counter is incremented when a GGSN attempts to deactivate a GTP context due to a SGSN restart.

Attempted GGSN Initiated Deactivation - SGSN Restart

SM.AttDeactPdpCtxtGgsn.SgsnRstrt.Apn

Counter 32

This counter is incremented when a GGSN completes deactivation of a GTP context due to a SGSN restart.

Successful GGSN Initiated Deactivation - SGSN Restart

SM.SuccDeactPdpCtxtGgsn.SgsnRstrt.Apn

Counter 32

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.

Attempted GGSN initiated deactivation - SSM Redundancy No Resource

SM.AttDeactPdpCtxtGgsn.Ssmr.NoResource.Apn

Counter 32

This measurement provides the number of PDP Context Successful Deactivations 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.

Successful GGSN initiated deactivation - SSM Redundancy No Resource

SM.SuccDeactPdpCtxtGgsn.Ssmr.NoResource.Apn

Counter 32

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 incremented for user APN by 1 as the process of removing the PDP Context starts in GGSN.

Description


Size (bits)



Attempted GGSN initiated deactivation - SSM Redundancy No Second Move

SM.AttDeactPdpCtxtGgsn.Ssmr.NoSecondMove.Apn

Counter 32

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 for user APN by 1 when PDP Context is successfully taken down from GGSN.

Successful GGSN initiated deactivation - SSM Redundancy No Second Move

SM.SuccDeactPdpCtxtGgsn.Ssmr.NoSecondMove.Apn

Counter 32

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.

Attempted GGSN initiated deactivation - SSM Redundancy System Failure

SM.AttDeactPdpCtxtGgsn.Ssmr.SystemFailure.Apn

Counter 32

This measurement provides the number of PDP Context Successful Deactivations 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.

Successful GGSN initiated deactivation - SSM Redundancy System Failure

SM.SuccDeactPdpCtxtGgsn.Ssmr.SystemFailure.Apn

Counter 32

This measurement provides the number of aggregation PDP Context Deactivations initiated by GGSN as the SSM redundancy for Aggregation was not Enabled. It is incremented for user APN by 1 as the process of removing the PDP Context starts in GGSN.

Attempted GGSN initiated deactivation - SSM Redundancy for Aggregation is disabled

SM.AttDeactPdpCtxtGgsn.Ssmr.Disabled.Apn

Counter 32

This measurement provides the number of aggregation PDP Context Successful 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

Successful GGSN initiated deactivation - SSM Redundancy for Aggregation is disabled

SM.SuccDeactPdpCtxtGgsn.Ssmr.Disabled.Apn

Counter 32

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.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Failed Session Establishments Due to Access Control rejection

SM.PdpCtxtAclRej.Apn Counter 32

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 Contexts

SM.NbrActCtxtPrepaid.Apn Gauge 32

This measurement provides the number of successfully established sessions using Basic Access Mode (untunneled).

Successfully Established Basic Access Mode sessions

SM.SuccActBamCtxt.Apn Counter 32

This measurement provides the number of successfully established sessions using IPSec.

Successfully Established IPSec sessions

SM.SuccActIpsecCtxt.Apn Counter 32

This measurement provides the number of successfully established sessions using GRE.

Successfully Established GRE sessions

SM.SuccActGreCtxt.Apn Counter 32

This measurement provides the number of successfully established sessions using L2TP.

Successfully Established L2TP sessions

SM.SuccActL2tpCtxt.Apn Counter 32

This measurement provides the number of successfully established sessions using L2TP/IPSec.

Successfully Established L2TP/IPSec sessions

SM.SuccActL2ipCtxt.Apn Counter 32

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 Secondary PDP Context Establishments

SM.AttActSecPdpCtxt.Apn Counter 32

This counter provides the number of successful Secondary PDP Context establishments.

Number of Successful Secondary PDP Context Establishments

SM.SuccActSecPdpCtxt.Apn Counter 32

Description


Size (bits)



This counter provides the number of failed Secondary PDP contexts due to no resources in the data plane.

Number of Failed Secondary PDP Contexts due to No Resources in the Data Plane

SM.FailActSecPdpCtxt.NoDataPlaneRsrc.Apn

Counter 32

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

SM.IMSIRuleMatchSucc.Apn Counter 32

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

SM.IMSIRuleMatchFail.Apn Counter 32

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 nuber of IMSI Billing rule comparisons

SM.IMSITotRuleComparisons.Apn

Counter 32

This measurement provides the number of successfully established sessions using MPLS.

Successfully Established MPLS sessions

SM.SuccActMPLSCtxt.Apn Counter 32

This measurement provides the number of simultaneous active sessions that were created with Content Based Billing enabled per APN.

Total Sessions with CBB

SM.SuccActCbbCtxt.Apn Counter 32

This measurement provides the current number of simultaneous active sessions were successfully created with Content Based Billing enabled per APN.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Active Sessions with CBB

SM.NbrActCbbCtxt.Apn 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 Sessions with CBB

SM.MaxNbrActCbbCtxt.Apn High Tidemark Gauge

32

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

Counter 32

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 Failed

SM.SuccActCtxtPcscfDiscFailed.Apn

Counter 32

This measurement provides the current number of active context bundles that successfully requested P-CSCF Address Discovery.

Simultaneous Active Sessions Requesting P-CSCF Discovery

SM.NbrActPcscfDiscCtxt.Apn Gauge 32

This measurement provides the maximum number of simultaneous active context bundles that successfully requested P-CSCF Address Discovery.

Peak Number of Simultaneous Active Sessions Requesting P-CSCF Discovery

SM.MaxNbrActPcscfDiscCtxt.Apn

High Tidemark Gauge

32

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 APN has been Blacklisted

SM.NbrBlacklist.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented whenever there is an PDP context activation attempt after an APN is blacklisted.

Failed Session Establishments Due to APN being Blacklisted

SM.FailActPdpCtxtApnBlacklist.Apn

Counter 32

Description


Size (bits)



This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context Response with failure cause NORA (No Resources Available)

Failed Session Establishments Due to No Resource Available

SM.FailActPdpCtxt.NORA.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context 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 Establishments Due to exhaustion of address pools

SM.FailActPdpCtxt.ADAO.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context Response with failure cause UAUF (User Authentication Failure).

Failed Session Establishments Due to User Authentication Failure

SM.FailActPdpCtxt.UAUF.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context Response with failure cause SYSF (System Failure).

Failed Session Establishments Due to System Failure

SM.FailActPdpCtxt.SYSF.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context 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 Establishments Due to Semantic or Syntactic TFT or Packet Filter Error

SM.FailActPdpCtxt.SEME.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context 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.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Failed Session Establishments Due to Mandatory IE Incorrect, IE missing or Optional IE Incorrect

SM.FailActPdpCtxt.IEIN.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context 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 Establishments Due to Invalid Message Format

SM.FailActPdpCtxt.IMFT.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context Response with failure cause SVNS (Service Not Supported).

Failed Session Establishments Due to Service Not Supported

SM.FailActPdpCtxt.SVNS.Apn Counter 32

This measurement provides the number of session establishment failures per APN and is incremented upon transmission of a non-duplicate Create PDP Context 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 Establishments Due to No Response

SM.FailActPdpCtxt.NoResp.Apn Counter 32

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 terminated due to DCC Failure Handling action

SM.NbrDeactPdpCtxtCCFH.Apn Counter 32

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)

Description


Size (bits)



CGF StatisticsTable 9-9 describes the counters that will be collected as part of the CGF Accounting Element group.

Number of contexts converted to postpaid due to DCC Failure Handling

SM.NbrCtxtPrepaidToNonPrepaid.CCFH.Apn

Counter 32

This counter shows the number of context converted to non-prepaid upon reception of CC-Not-Applicable result code.

Number of contexts converted to postpaid upon reception of DCC Not Applicable

SM.NbrCtxtPrepaidToNonPrepaid.CCNotApp.Apn

Counter 32

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 terminated by DCC server direction

SM.NbrDeactPdpCtxtDCCServer.Apn

Counter 32


Spare counter SM.spare1.Apn TBD 32









Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Table 9-9 CGF Counters

Description


Size (bits)



CGF.ReportingInterval

Gauge 32

The IP Address of the CGF server.

CGF Server Address CGF.Server Identifier 18 characters

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

CGF.EchoReqSent Counter 32

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

CGF.EchoRespSent Counter 32

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

CGF.NodeAliveReq Counter 32

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

CGF.NodeAliveResp

Counter 32


Spare counter CGF.spare1 TBD 32










L2TP StatisticsTable 9-10 describes the counters that will be collected as part of the L2TP Accounting Element group.

Table 9-10 L2TP Counters


Description


Size (bits)



L2TP.ReportingInterval

Gauge 32

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 on Gi Interface

L2TP.NbrTunnels Gauge 32

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 Packets

L2TP.DiscDataPkt Counter 64

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 Packets L2TP.IncDataPkt Counter 64

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

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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


Spare counter L2TP.spare1 TBD 64









Description


Size (bits)



L2IP.ReportingInterval

Gauge 32

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 tunnels on Gi Interface

L2IP.NbrTunnels Gauge 32

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 Received L2IP.IncDataOct Counter 64

Description


Size (bits)



IPSec StatisticsTable 9-12 describes the counters that will be collected as part of the IPSec Accounting Element group.

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 Packets

L2IP.DiscDataPkt Counter 64

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 Packets

L2IP.IncDataPkt Counter 64

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 Sent

L2IP.OutDataPkt Counter 64


Spare counter L2IP.spare1 TBD 64









Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Table 9-12 IPSec Counters

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

Description


Size (bits)



IPSec.ReportingInterval

Gauge 32

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











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.

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


Size (bits)



Ovld.ReportingInterval Gauge 32

Slot - Chassis slot of the card from which the OMs are collected.

Indicates the slot number of the card where the OMs are collected from.

Ovld.Slot Identifier 16

Port - the port of the Slot from which the OMs are collected from.

Indicates the port number where the OMs are collected from.

Ovld.Port Identifier 16

Proc - the processor on the specified port where the OMs are collected from.

Indicates the processor number from which the OMs are collected from.

Ovld.Proc Identifier 16

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 percentage of CPU total occupancy.

Ovld.CpuTot.HighestAvgPct High Tidemark Gauge

16

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 percentage of CPU total occupancy

Ovld.CpuTot.LowestAvgPct Low Tidemark Gauge

16

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.


411-5221-926 Standard 10.07 June 2006

Average percentage of CPU total occupancy

Ovld.CpuTot.AvgPct gauge 16

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 at the start of OM collection period.

Ovld.CpuTot.StartLevel Gauge 16

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 Normal was entered for CPU total.

Ovld.CpuTot.NormEntry Counter 16

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 was entered for CPU total.

Ovld.CpuTot.L1Entry Counter 16

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 was entered from Normal

Ovld.CpuTot.NormToL2Entry Counter 16

Number of times ovld L3 was entered with a jump from Normal (transitions from Normal to L3) for CPU Total occupancy. This OM gets reset to zero after the OM has been collected.


Ovld.CpuTot.NormToL3Entry Counter 16

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 was entered from L1

Ovld.CpuTot.L1ToL3Entry Counter 16

This is the highest weighted average percentage of CPU Interrupt occupancy. This OM gets reset to zero after the OM has been collected.

Description


Size (bits)



Highest weighted average percentage of CPU Interrupt occupancy.

Ovld.CpuInt.HighestAvgPct High Tidemark Gauge

16

This is the overload level at the start of the OM collection period for CPU Interrupt occupancy. This OM gets reset to zero after the OM has been collected.

Overload level of CPU Int at the start of OM collection period.

Ovld.CpuInt.StartLevel Gauge 16

Number of times ovld Normal was entered (transitions from L1 to Normal and from L2 to 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 Normal was entered for CPU Int.

Ovld.CpuInt.NormEntry Counter 16

Number of times ovld L1 was entered (transitions from Normal to L1) for CPU Interrupt occupancy. This OM gets reset to zero after the OM has been collected.

Number of times ovld L1 was entered for CPU Int.

Ovld.CpuInt.L1Entry Counter 16

Number of times ovld L2 was entered (transitions from Normal to L2 and from L1 to L2) for CPU Interrupt 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 Interrupt 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 Interrupt occupancy. This OM gets reset to zero after the OM has been collected.

Number of times ovld L2 was entered from Normal.

Ovld.CpuInt.NormToL2Entry Counter 16

Number of times ovld L3 was entered with a jump from Normal (transitions from Normal to L3) for CPU Interrupt occupancy. This OM gets reset to zero after the OM has been collected.


Ovld.CpuInt.NormToL3Entry Counter 16

Number of times ovld L3 was entered with a jump from L1 (transitions from L1to L3) for CPU Interrupt occupancy. This OM gets reset to zero after the OM has been collected.


Ovld.CpuInt.L1ToL3Entry Counter 16

This is the highest number of allocated mega bytes of system memory. This OM gets reset to zero after the OM has been collected.

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Highest number of system memory allocated in MB.

Ovld.Mem.HighestAllocated High Tidemark Gauge

16

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 lowest block size available in system memory in KB.

Ovld.Mem.LowestFragBlkSize

Low Tidemark Gauge

16

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 occupancy. This OM gets reset to zero after the OM has been collected.

Overload level of system memory at the start of OM collection period.

Ovld.Mem.StartLevel Gauge 16

Number of times ovld Normal was entered (transitions from L1 to Normal and from L2 to 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 Normal was entered for system memory.

Ovld.Mem.NormEntry Counter 16

Number of times ovld L1 was entered (transitions from Normal to L1) for system memory occupancy. This OM gets reset to zero after the OM has been collected.

Number of times ovld L1 was entered for system memory.

Ovld.Mem.L1Entry Counter 16

Number of times ovld L2 was entered (transitions from Normal to L2 and from L1 to L2) for system memory 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 system memory occupancy. This OM gets reset to zero after the OM has been collected.



Description


Size (bits)



Wireless Services StatisticsThe 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.

Number of times ovld L2 was entered with a jump from Normal (transitions from Normal to L2) for system memory occupancy. This OM gets reset to zero after the OM has been collected.


Ovld.Mem.NormToL2Entry Counter 16

Number of times ovld L3 was entered with a jump from Normal (transitions from Normal to L3) for system memory occupancy. This OM gets reset to zero after the OM has been collected.


Ovld.Mem.NormToL3Entry Counter 16

Number of times ovld L3 was entered with a jump from L1 (transitions from L1to L3) for system memory occupancy. This OM gets reset to zero after the OM has been collected.


Ovld.Mem.L1ToL3Entry Counter 16

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

Gauge 32

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


Size (bits)


411-5221-926 Standard 10.07 June 2006

Table 9-14 Wireless Services Counters

Description


Size (bits)



SERV.ReportingInterval Gauge 32

This counter shows the number of Application Service Requests sent from the GGSN to the Application Server/Gateway.

Number of application service request messages sent

SERV.WAP.ReqSent Counter 32

This counter shows the number of Application Service Responses received by the GGSN from the Application Server/Gateway.

Number of application service response messages received

SERV.WAP.RespRcvd Counter 32

This counter shows the number of bad response from Application Server due to unknown message type and bad authenticator

Number of invalid application service response messages received

SERV.WAP.InvalidRespRcvd Counter 32

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 Authorization request messages sent

SERV.PrePaid.ReqSent Counter 32

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 Authorization response messages received

SERV.PrePaid.RespRcvd Counter 32

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 Response messages received

SERV.PrePaid.FailedAuthRespRcvd

Counter 32




GRE StatisticsTable 9-15 describes the counters that will be collected as part of the GRE Accounting Element group.

Table 9-15 GRE Counters

Spare counter SERV.spare1 TBD 32









Description


Size (bits)



GRE.ReportingInterval Gauge 32

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

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

This measurement provides the number of incoming GRE packets discarded due to memory issues.

GRE Packets Discarded due to Memory Issues

GRE.DiscDataPkt.Mem Counter 64

This measurement provides the number of incoming GRE packets discarded due to a non-existent tunnel.

GRE Packets Discarded due to Non-Existent Tunnel

GRE.DiscDataPkt.NoTun Counter 64

This measurement provides the number of incoming GRE packets discarded due to routing issues.

GRE Packets Discarded due to Routing Issues

GRE.DiscDataPkt.NoRoute

Counter 64

This measurement provides the number of incoming GRE packets discarded due to ethertype issues.

GRE Packets Discarded due to Ethertype Issues

GRE.DiscDataPkt.Eth Counter 64

This measurement provides the number of incoming GRE packets discarded due to unsupported strict source routing.

GRE Packets Discarded due to Unsupported Strict Source Routing

GRE.DiscDataPkt.SSR Counter 64

This measurement provides the number of incoming GRE packets discarded due to bad checksum.

GRE Packets Discarded due to Bad Checksum

GRE.DiscDataPkt.BadCksum

Counter 64

This measurement provides the number of incoming GRE packets discarded due to bad key.

GRE Packets Discarded due to Bad Key

GRE.DiscDataPkt.BadKey

Counter 64

This measurement provides the number of incoming GRE packets discarded due to bad sequence number.

GRE Packets Discarded due to Bad Sequence Number

GRE.DiscDataPkt.SeqNum

Counter 64

This measurement provides the number of incoming GRE packets discarded due to no connection interface.

GRE Packets Discarded due to No Connection Interface

GRE.DiscDataPkt.NoIF Counter 64

This measurement provides the number of incoming GRE packets discarded due to IP interrupt queue full.

Description


Size (bits)



SCP StatisticsTable 9-16 describes the statistics that will be collected as part of the SCP Accounting Element group. All statistics in this group apply only to CTP servers.

Table 9-16 SCP Counters

GRE Packets Discarded due to IP Interrupt Queue Full

GRE.DiscDataPkt.IPQFull

Counter 64


Spare counter GRE.spare1 TBD 64









Description


Size (bits)



SCP.ReportingInterval Gauge 32

The IP Address of the SCP server.

SCP Server SCP.Server Identifier 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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

SCP.AttAuthReq Counter 32

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

SCP.SuccAuthReq Counter 32

Description


Size (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 Reauthorizations sent

SCP.AttReauthReq Counter 32

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 Reauthorizations

SCP.SuccReauthReq Counter 32

This counter shows the number of Final Report messages sent from the GGSN to a Prepaid server.

This counter is incremented for all CTP versions.

Number of Final Report messages sent

SCP.AttFinalReport Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

This counter shows the number of successful Final Report response messages received by the GGSN from a Prepaid server.


Number of successful Final Report response messages received

SCP.SuccFinalReport Counter 32

This counter shows the number of incoming CTP messages that failed during parsing due to protocol errors.


Number of Prepaid Request failures due to protocol errors

SCP.ProtErr Counter 32

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

SCP.NoResp Counter 32

Description


Size (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 Request failures explicitly denied.

SCP.DeniedReq Counter 32

This counter shows the number of coupons returned because of an Idle Timeout expiry.


Number of returned coupons due to Idle Timeout.

SCP.ReturnCoupon.IdleTimeOut

Counter 32

This counter shows the number of coupons returned because of a Coupon Lifetime expiry.


Number of returned coupons due to Lifetime Expiry.

SCP.ReturnCoupon.LifeTimeExpiry

Counter 32

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


Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

ISP-IP StatisticsTable 9-17 describes the counters that will be collected as part of the 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.

Table 9-17 ISP-IP Counters

Number of GTP contexts taken down due to rated coupons with no CBB

SCP.NoCouponNoCBB Counter 32

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 Received

SCP.ReauthCommandsRcvd Counter 32


Spare counter SCP.spare1 TBD 32









Description


Size (bits)


Description


Size (bits)




IP.ReportingInterval Gauge 32

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

IP.LocalDlvdPkt Counter 32

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

IP.LocalGenPkt Counter 32

This measurement provides the number of IP packets that have been fragmented before transmission.

Number of fragmented IP packets

IP.FragmentedPkt Counter 32

This measurement provides the number of IP packets that have been reassembled after being received.

Number of reassembled IP packets

IP.ReassembledPkt Counter 32

This measurement provides the number of IP fragments transmitted.

Number of transmitted IP fragments

IP.OutFragments Counter 32

This measurement provides the number of IP packets that could not be fragmented before transmission.

Number of IP packets that could not be fragmented

IP.NoFragmentPkt Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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 packets

IP.BadPkt Counter 32

This measurement provides the number of incoming IP packets received which are for an unreachable destination.

Number of IP packets received for an unreachable destination

IP.DestUnrchPkt Counter 32

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 packets

IP.DropPkt Counter 32

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 dropped by indexed services.

IP.DropIndxSvcPkt Counter 32


Spare counter IP.spare1 TBD 32



Description


Size (bits)



Ancillary APN StatisticsTable 9-18 describes the statistics that will be collected as part of the Ancillary APN Accounting Element group.

Table 9-18 Ancillary APN Counters







Description


Size (bits)



RAD.ReportingInterval.Apn Gauge 32



This measurement is incremented upon transmission of RADIUS Accounting Start messages.

Number of Radius Accounting Start Messages Sent

RAD.AcctStartMsgSent.Apn Counter 32

This measurement is incremented on receipt of a RADIUS Accounting Start response message.

Number of Radius Accounting Start Responses Received

RAD.AcctStartResponseRcvd.Apn

Counter 32

This measurement is incremented on transmission of a RADIUS Accounting Interim Update message.

Number of Radius Accounting Interim Update Messages Sent

RAD.AcctInterimMsgSent.Apn Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

APN Data Plane StatisticsTable 9-19 describes the statistics that will be collected as part of the APN Data Plane Accounting Element group.

Table 9-19 APN Data Plane Counters

This measurement is incremented on receipt of a RADIUS Accounting Interim Update response message.

Number of Radius Accounting Interim Update Responses Received

RAD.AcctInterimResponseRcvd.Apn

Counter 32

This measurement is incremented upon transmission of RADIUS Accounting Stop messages.

Number of Radius Accounting Stop Messages Sent

RAD.AcctStopMsgSent.Apn Counter 32

This measurement is incremented on receipt of a RADIUS Accounting Stop response message.

Number of Radius Accounting Stop Responses Received

RAD.AcctStopResponseRcvd.Apn

Counter 32


Spare counter RAD.spare1.Apn TBD 32









Description


Size (bits)


Description


Size (bits)



MPLS StatisticsTable 9-20 describes the statistics that will be collected as part of the MPLS Accounting Element group.


IP.ReportingInterval.Apn Gauge 32



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 Received

IP.IncDataPkt.Apn Counter 64

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 Received IP.IncDataOct.Apn Counter 64

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









Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Table 9-20 MPLS Counters

VRF StatisticsTable 9-21 describes the statistics that will be collected as part of the VRF Accounting Element group.

Description


Size (bits)



MPLS.ReportingInterval Gauge 32

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











Table 9-21 VRF Counters

Description


Size (bits)



VRF.ReportingInterval Gauge 32

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 Forwarded. VRF.CantForward Counter 32

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

VRF.DropIndxSvcPkt Counter 32


Spare counter VRF.spare1 TBD 32





411-5221-926 Standard 10.07 June 2006

DCC StatisticsTable 9-22 describes the statistics that will be collected as part of the 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


Size (bits)



DCC.ReportingInterval Gauge 32

The name of the Diameter Profile.

Diameter Profile Name DCC.ProfileName Identifier 32 characters

The IP Address of the Diameter server.

Server DCC.Server Identifier 32

Description


Size (bits)



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 Request Messages Sent

DCC.AttInitialCCR Counter 32

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 Control Answer Messages Received

DCC.SuccInitialCCA Counter 32

This counter shows the number of Update 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 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 Request Messages Sent

DCC.AttUpdateCCR Counter 32

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

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


Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Successful Update Credit Control Answer Messages Received

DCC.SuccUpdateCCA Counter 32

This counter shows the number of Termination 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 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 Request Messages Sent

DCC.AttTerminationCCR Counter 32

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

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


Successful Termination Credit Control Answer Messages Received

DCC.SuccTerminationCCA

Counter 32

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 Answer Messages Received

DCC.RedirectCCARcvd Counter 32

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.


Re-Auth Request Messages Received

DCC.RARMsgsRcvd Counter 32

Description


Size (bits)



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

DCC.AttNewRateReq Counter 32

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

DCC.SuccNewRateReq Counter 32

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

DCC.AttReauthReq Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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-authorizations DCC.SuccReauthReq Counter 32

This counter shows the number of quotas returned because of an Idle Timeout expiry.


Returned quotas due to Idle Timeout

DCC.QuotaReturn.IdleTimeOut

Counter 32

This counter shows the number of time-outs of the Request Timer.


Request Time-outs DCC.ReqTimerExpiry Counter 32

Description


Size (bits)



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_UNSUPPORTED3002 - DIAMETER_UNABLE_TO_DELIVER3003 - DIAMETER_REALM_NOT_SERVED3004 - DIAMETER_TOO_BUSY3005 - DIAMETER_LOOP_DETECTED3006 - DIAMETER_REDIRECT_INDICATION3007 - DIAMETER_APPLICATION_UNSUPPORTED3008 - DIAMETER_INVALID_HDR_BITS3009 - DIAMETER_INVALID_AVP_BITS3010 - DIAMETER_UNKNOWN_PEER (CER only)4002 - DIAMETER_OUT_OF_SPACE4003 - ELECTION_LOST5001 - DIAMETER_AVP_UNSUPPORTED5010 - DIAMETER_NO_COMMON_APPLICATION5011 - DIAMETER_UNSUPPORTED_VERSION5012 - DIAMETER_UNABLE_TO_COMPLY5013 - DIAMETER_INVALID_BIT_IN_HEADER5017 - DIAMETER_NO_COMMON_SECURITY5004 - DIAMETER_INVALID_AVP_VALUE5005 - DIAMETER_MISSING_AVP5006 - DIAMETER_RESOURCES_EXCEEDED5007 - DIAMETER_CONTRADICTING_AVPS5008 - DIAMETER_AVP_NOT_ALLOWED5009 - DIAMETER_AVP_OCCURS_TOO_MANY_TIMES5013 - DIAMETER_INVALID_BIT_IN_HEADER5014 - DIAMETER_INVALID_AVP_LENGTH5015 - DIAMETER_INVALID_MESSAGE_LENGTH5016 - DIAMETER_INVALID_AVP_BIT_COMBO5140 - DIAMETER_ERROR_INITIAL_PARAMETERS5141 - DIAMETER_ERROR_TRIGGER_EVENT


Failures due to protocol errors DCC.ProtocolErr Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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 denied for Authentication

DCC.DeniedReq.Authentication

Counter 32

Description


Size (bits)



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 denied for Authorization

DCC.DeniedReq.Authorization

Counter 32

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 Requests DCC.TerminationReason.Normal

Counter 32

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

This counter shows the number of Termination Credit Control Requests sent with a Termination-Reason AVP value of:

3 - DIAMETER_BAD_ANSWER


Bad Answer Termination Requests

DCC.TerminationReason.BadAnswer

Counter 32


4- DIAMETER_ADMINISTRATIVE


Administrative Termination Requests

DCC.TerminationReason.Administrative

Counter 32


5- DIAMETER_LINK_BROKEN


Link Broken Termination Requests

DCC.TerminationReason.LinkBroken

Counter 32


6- DIAMETER_SESSION_TIMEOUT


Session Timeout Termination Requests

DCC.TerminationReason.SessionTimeout

Counter 32

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 terminated due to Failure Handling action

DCC.FailureHandling.NbrTerminated

Counter 32

Description


Size (bits)



DHCP StatisticsTable 9-23 describes the statistics that will be collected as part of the Dynamic Host Configuration Protocol (DHCP) Accounting Element group.

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 continued (converted postpaid) due to Failure Handling action

DCC.FailureHandling.NbrContinue

Counter 32

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 Rule Bases Received

DCC.InvalidChargingRuleBaseRcvd

Counter 32

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

DCC.InvalidChargingRuleRcvd

Counter 32


Spare counter DCC.spare1 TBD 32









Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Table 9-23 DHCP Counters

Description


Size (bits)



DHCP.ReportingInterval Gauge 32

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



Local Address Pool statisticsTable 9-24 describes the statistics that will be collected as part of the Local Address Pool Accounting Element group.

Table 9-24 Local Address Pool Counters

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









Description


Size (bits)



AddrPool.ReportingInterval

Gauge 32

IP Address Pool name

Local Address Pool Name AddrPool.AddressPoolName

Identifier 33 Characters

Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

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 group AddrPool.AccessGroupName

Identifier 33 Characters

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

AddrPool.FreeAddr Gauge 32

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

AddrPool.UsedAddr Gauge 32

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

Maximum address used. AddrPool.MaxAddrUsed High Tidemark Gauge

32

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.

Description


Size (bits)



Content Filter StatisticsThe following table describes the statistics collected for Content Filter servers.

Total attempts to allocate address

AddrPool.AttAddrAllocations

Counter 32

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 to allocate address.

AddrPool.SuccAddrAllocations

Counter 32

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 due to unavailability of addresses

AddrPool.FailAddrAllocations.NoAddr

Counter 32

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


Spare counter AddrPool.spare1 TBD 32









Description


Size (bits)


411-5221-926 Standard 10.07 June 2006

Table 9-25 Content Filter Service Statistics

Description

Measurement Name New 3GPP Name Collection Method

Size (bits)



CFS.ReportingInterval

Gauge 32

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 Sent

CFS.RequestsSent Counter 32

The number of Content Decisions that allow the request to pass through.

Pass through responses received

CFS.PassThrough Counter 32

The number of Content Decisions that redirect the request to another location.

Respond to subscriber redirection response received

CFS.RespToSub.Redirect

Counter 32

The number of Content Decisions that block the request.

Respond to subscriber forbidden response received

CFS.RespToSub.Forbidden

Counter 32

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

Spare counter for future enhancement purposes. Initialized to 0 and not pegged.

Spare counter CFS.spare1 TBD 32



SCS Log ServerThe 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”









Description

Measurement Name New 3GPP Name Collection Method

Size (bits)


411-5221-926 Standard 10.07 June 2006

• 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

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

SCS Log Servercreates ACC fileper single accounting

*.acc Single CSV file

element and CSV file

files per region/device

per region/device. ~/log/SCSLogTimeInterval.config



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.


411-5221-926 Standard 10.07 June 2006

Figure 9-2 CSV File Generation Time Periods

CSV Record FormatEach 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

12:00 12:05 12:10 12:15 12:20 12:25

SSG

SSG

SCS CSV

PeriodCollection

ReportingPeriod

File GenerationPeriod

ExternalDevice



• 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-26Accounting Group Identifier Value

Accounting Group Record Type CSV Record Name

Memory 7 GGSN_Mem_Stats

Session Management 9 SM_Stats

GTP Data 11 GTP_Data_Stats

GTP Accounting 13 GTP_ACCT_Stats

RADIUS 17 RADIUS_ACCT_Stats

APN 10 perAPN_Stats

CGF 12 per_CGF_Stats

L2TP 16 L2TP_Stats


411-5221-926 Standard 10.07 June 2006

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

L2IP 15 L2TP_IPSec_Stats

IPSec 14 IPSec_Stats

Overload 8 GGSN_Overload_Stats

Wireless Services 18 Wireless_Services_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_Stats

VRF 23 VRF_Stats

MPLS 29 MPLS_Stats

DCC 30 DCC_Stats

DHCP 32 DHCP_Stats

Local Address Pool 33 LocalAddrPool_Stats

CFS 34 CFS_Stats

Accounting Group Record Type CSV Record Name



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:


411-5221-926 Standard 10.07 June 2006

Figure 9-3 An Example of Device Based CSV File

CSV File TimestampIn 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

2, 7, , 1, 1, 1, 2, 2, 7, Tue Jan 01 04:48:31 CST 2003, Tue Jan 01 04:53:31 CST



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, 02, 13, , 1, 1, 1, 1, 2, 2, Tue Jan 01 18:28:57 CST 2003, Tue Jan 01 18:33:57 CST

2, 17, 12, , 1, 1, 1, 2, 7, Tue Jan 01 18:28:57 CST 2003, Tue Jan 01 18:33:57 CST


0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 03, 12, , 1, 1, 1, 1, 3, 8, Tue Jan 01 01:18:03 CST 2003, Tue Jan 01 01:23:03 CST




3, 8, ENABLED, 1, 6, 1, 1, 2, 7, Tue Jan 01 09:20:38 CST 2003, Tue Jan 01

0, 0, 0, 0, 2, 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, 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,

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,

2003, GGSNS4.0, 47.104.105.49, ssg55, GTP_ACCT_Stats, 0, 0, 0, 0, 0, 0, 0

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,

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

09:25:38 CST 2003, GGSNS4.0, 47.104.105.49, ssg55, GGSN_Overload_Stats, 192, 11, 2, 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, 01, 3, , 1, 6, 1, 1, 0, 3, Tue Jan 01 09:20:38 CST 2003, Tue Jan 01 09:25:38 CST2003, GGSNS4.0, 47.104.105.49, ssg55, ISP_IP_Stats, 44456, 44433, 44332, 1, 2, 2, 2, 23, 19, , 1, 6, 1, 1, 0, 7, Tue Jan 01 09:20:38 CST 2003, Tue Jan 01 09:25:38 CST2003, GGSNS4.0, 47.104.105.49, ssg55, SCP_Stats, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 03, 20, , 1, 6, 1, 1, 0, 9, Tue Jan 01 09:20:38 CST 2003, Tue Jan 01 09:25:38 CST2003, GGSNS4.0, 47.104.105.49, ssg55, GRE_Stats, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 01, 23, , 1, 6, 1, 1, 0, 9, Tue Jan 01 09:20:38 CST 2003, Tue Jan 01 09:25:38 CST2003, GGSNS4.0, 47.104.105.49, ssg55, MPLS_Stats, 0, 0, 0, 01, 24, , 1, 6, 1, 1, 0, 9, Tue Jan 01 09:20:38 CST 2003, Tue Jan 01 09:25:38 CST2003, GGSNS4.0, 47.104.105.49, ssg55, VRF_Stats, 0, 0, 0, 0, 0, 0, 0, 0



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 IntervalThe 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 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 JobThe ‘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:

#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 2003CSVFileInterval=5


411-5221-926 Standard 10.07 June 2006

Figure 9-5 Sample SCSCronCleancsv.txt

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 MonitoringThe 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 element. Only the counters with Gauge collection method are included in the historical statistics monitoring.

#

#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 are59 23 * * * ksh -e '/opt/SER/bin/SCSCleanLogcsv.ksh 7 pmuser‘

__ days old.



Table 9-27Real-time Statistics Monitoring

Accounting Group

Viewing Privilege Monitoring Counters

Memory Device, Gn ISP, Connection ISP

Mem.totSystemMemUtil

Mem.totSystemMemFree

Session Management

Gn ISP SM.NbrActPdpCtxt

SM.NbrActBamCtxt

SM.NbrActIpsecCtxt

SM.NbrActL2tpCtxt

SM.NbrActL2ipCtxt

SM.NbrActRoamerCtxt

SM.NbrActGreCtxt

SM.NbrActPrepaidCtxt

SM.NbrActMPLSCtxt


411-5221-926 Standard 10.07 June 2006

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.

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

Accounting Group

Viewing Privilege Monitoring Counters



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.


411-5221-926 Standard 10.07 June 2006

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.



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.


411-5221-926 Standard 10.07 June 2006

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.

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 OMsThe 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 OMsThe device OMs are summarized in Table 9-28.

Table 9-28SER Base Device OMs

Measurement Name Description Size (bits)

CMC_BUSY_SINCE_BOOT Percentage of the CMC that is busy since boot time.

8

CMC_BUSY_DELTA Percentage of the CMC that is 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.

8

SSP_NONHIFN_BUSY_SINCE_BOOT

Average percentage across all SSPs in the box that are busy since boot time.

8

SSP_NONHIFN_BUSY_DELTA

Average percentage that 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.

8

SSP_HIFN_BUSY_SINCE_BOOT

Percentage of the SSP-HiFn (encrypted SSP) that is busy since boot time.

8


411-5221-926 Standard 10.07 June 2006

Trunk OMsThe trunk OMs are summarized in Table 9-29.

Table 9-29SER Base Trunk OMs

SSP_HIFN_BUSY_DELTA Percentage of the SSP-HiFn (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.

8

SSP_DRIVER_PKTS_RCVD Total number of packets received by the SPP Driver.

64

CMC_DRIVER_PKTS_RCVD Total number of packets received by the CMC Driver.

64

SSP_DRIVER_BAD_PKTS_RCVD

Total number of bad packets received by the SPP driver.

32

CMC_DRIVER_BAD_PKTS_RCVD

Total number of bad packets received by the CMC driver.

32

SSP_PKTS_DRIVER_DROPPED

Total number of packets dropped by the SSP driver.

32

CMC_PKTS_DRIVER_DROPPED

Total number of packets dropped by the CMC driver.

32

SSP_PKTS_CHIP_DROPPED

Total number of packets dropped by the SSP chip.

32

CMC_PKTS_CHIP_DROPPED

Total number of packets dropped by the CMC chip.

32

ENCRYP_PKTS_PROCESSED

Total number of encrypted packets processed within a single device.

64

ENCRYP_PKTS_DROPPED Total number of encrypted packets dropped within a single device.

32


SPM_TRUNKID Trunk Identification number 32




VPRN OMsThe VPRN OMs are summarized in Table 9-30.

Table 9-30SER Base VPRN OMs

IFI_IPACKETS Number of packets destined for the Trunk (into the trunk).

64

IFI_OPACKETS Number of packets generated by the trunk (out of the trunk).

64

IFI_IBYTES Number of bytes destined for the trunk.

64

IFI_OBYTES Number of bytes generated by the trunk.

64

IFI_IQDROPS Input queues overflow and drop packets.

32

IFI_OQDROPS Output queues overflow and drop packets.

32

PKTS_DROP_ERR Packets drop due to various errors

32

MULTICAST_IN_PKTS Number of multicast packets destined for the trunk.

64

MULTICAST_OUT_PKTS Number of multicast packets generated for the trunk.

64


SPM_VPRNID The VPRN identification number. 32

IPS_TOTAL Total number of packets received by the VPRN.

64

IPS_FORWARD Total number of packets forwarded through the box per VPRN.

64

IPS_DELIVERED Total number of packets destined to the VPRN (into the VPRN).

32

IPS_LOCALOUT Total number of packets generated by the VPRN (out of the VPRN).

32



411-5221-926 Standard 10.07 June 2006

VPRN Link OMsThe VPRN Link OMs are summarized in Table 98, “SER Base VPRN Link OMs,” on page 433.

Table 9-31SER Base VPRN Link OMs

PKTS_BAD Number of bad packets due to errors.

32

IPS_CANTFORWARD Number of packets the VPRN cannot forward due to various errors.

32

PKTS_DROPPED Number of packets dropped due to various errors.

32

PKTS_SVCS_DROPPED Number of packets per service dropped per VPRN due to various errors.

32


SPM_VPRNID The VPRN identification number. 32

REMOTE_IPADDR The IP address of the remote node.

32

IFI_IPACKETS Number of packets destined for the link (into the link).

64

IFI_OPACKETS Number of packets generated by the link (out of the link).

64

IFI_IBYTES Number of bytes destined for the link.

64

IFI_OBYTES Number of bytes generated by the link.

64

IFI_IQDROPS Input queues overflow and drop packets.

32

IFI_OQDROPS Output queues overflow and drop packets.

32

PKTS_DROP_ERR Packets drop due to various error.s

32




OM MonitoringOM 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”


411-5221-926 Standard 10.07 June 2006

• 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 statisticsOn 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 NTP 411-5221-922, GGSN CLI Reference Guide 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 active. IPSec and GRE statistics are persistent for the life of the associated ISP.

Alarms 9The 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:


411-5221-926 Standard 10.07 June 2006

• 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 TrapsThis 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. Nortel GGSN SNMP Alarm System.

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

SNMP Traps

SCS Server

Other SNMPManagers

Nortel GGSN

SNMP Traps

SNMPAgent

EventManager



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 TrapsThe detailed information on the GGSN specific SNMP traps are described in the subsections below.


411-5221-926 Standard 10.07 June 2006

AAA Manager Address Pool Category SNMP Alarms

Table 9-33New MIB Notification Object Name

Table 9-32 GGSN AAAmgr Address Pool Category Alarms

GGSN Function

Trap Severity Alarm State

Alarm Description Transfer to SCS

Transfer to SNMP Manager based on Configuration

AAAmgr MINOR alarmOccur

The local address pool category “Reserved “pools has reached the pre configured depletion value level

YES YES

MINOR alarmOccur

The local address pool category “Unreserved “pools has reached the pre configured depletion value level

YES YES

INFORMATION alarmOccur

The local address pool category “Reserved “pools has dropped to the pre configured depletion value level to clear above alarm

YES YES


The local address pool category “Unreserved “pools has dropped to the pre configured depletion value level to clear above alarm

YES YES

MIB Variable Values

ssg5000TrapAddressPoolAlarmId

reservedThresholdReached(2),

unreservedThresholdReached(3),

ssg5000TrapAddressPoolName string

ssg5000TrapIspName string

ssg5000TrapThresholdLevel integer32 (0..100)



The OID for the Address Pool Alarm Notification object is:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000HAddressPoolAlarmNotification(14)

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)

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

GTP SNMP AlarmsThey are sent using the MIB object ssg5000GTPAlarmNotification described in Table 9-35.

Table 9-34 GGSN GTP Alarms

GGSN Function

Trap Severity Alarm State



GTP Tunnel


An APN is administratively Disabled for the GGSN (will not accept new context creation).

YES YES

INFORMATION alarmClear

An APN that was Disabled is now Enabled.

YES YES


GTP Tunnel creation has been disabled for the GGSN.

YES YES

INFORMATION alarmClear

GTP Tunnel creation was Disabled, now Enabled

YES YES

MINOR alarmOccur

Configured session limit has been exceeded for the APN & ISP specified.

YES YES

MINOR alarmClear

The number of active sessions using the APN & ISP specified has dropped below the configured limit for that APN.

YES YES

MAJOR alarmOccur

APN <apn-name> on ISP <isp-name> has been blacklisted.

YES YES

MAJOR alarmClear

APN <apn-name> on ISP <isp-name> has been blacklisted.

YES YES



Table 9-35SNMP GGSN GTP ALARM MIB Notification Object

Below is an OID for the SNMP GTP alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000GTPAlarmNotification(56)

GTP SNMP EventsThe GGSN GTP Events are listed in Table 9-36. They are sent using the MIB object ssg5000GTPEventNotification described in Table 9-37.

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)



major(2),

minor(4),

info(8)


411-5221-926 Standard 10.07 June 2006

Table 9-36 GGSN GTP Events

Table 9-37SNMP GGSN GTP EVENT MIB Notification Object

GGSN Function

Trap Severity

SCS Client Event Text

Event Description

Transfer to SCS


GTP Tunnel

MINOR WARNING: Access Control Profile rejection for MSISDN <msisdn> IMSI <imsi> on APN <apn> on ISP <isp> Operation <Access Control Profile Rejection>

Create PDP Context Request rejected IMSI (MCC/MNC) not matching Access Control Profile entries for the APN requested

YES YES

INFORMATION

Access Control Profile <profile> is associated with APN <apn> on ISP <isp>

The Access Control Profile is associated with the APN

YES YES

INFORMATION

Access Control Profile <profile> is dissociated with APN <apn> on ISP <isp>

The Access Control Profile is disassociated with the APN

YES YES

MIB Variable Values

ssg5000GtpEventId gtpGgsnAclRej(1)

gtpGgsnAclApnAssoc(2)

gtpGgsnAclApnDisassoc(3)

ssg5000TrapAPNName A trap variable object for providing the APN Name




Below is an OID for the SNMP GTP event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000GTPEventNotification(57)

GTP Accounting SNMP AlarmsThe GGSN GTP Accounting alarms are listed in Table 9-38. They are sent using the MIB object ssg5000GTPAcctAlarmNotification described in Table 9-39.

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



major(2),

minor(4),

info(8)

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Table 9-38 GGSN GTP Accounting Alarms

GGSN Function

Trap Severity

Alarm State

Alarm Description

Transfer to SCS


GTP Accounting

CRITICAL

alarmOccur

CGFs configured on the Gn ISP are not responding.

YES YES

CRITICAL

alarmClear

CGF configured on the Gn ISP are responding.

YES YES

MINOR alarmOccur

CGF Failed for the specified CGF server and ISP.

YES YES

MINOR alarmClear

CGF restored for the specified CGF server and ISP.

YES YES

MINOR alarmOccur

One FTP server used for GTPP audit is down.

YES YES

MINOR alarmClear

An FTP server used for GTPP audit is reachable.

YES YES

CRITICAL

alarmOccur

All FTP servers used for GTPP Audit are down.

YES YES

CRITICAL

alarmClear

An FTP Server used for GTPP Audit is up.

YES YES



Table 9-39SNMP GGSN GTP Accounting ALARM MIB Notification Object

Below is an OID for the SNMP GTP Accounting alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000GTPAcctAlarmNotification(58)

GTP Accounting SNMP EventsThe 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.

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)


411-5221-926 Standard 10.07 June 2006

Table 9-40 GGSN GTP Accounting Events

Table 9-41SNMP GGSN GTP EVENT MIB Notification Object

Below is an OID for the SNMP GTP Account event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000GTPAcctEventNotification(59)

GGSN Function

Trap Severity


Event Description

Transfer to SCS


GTP Accounting

INFORMATION

CGF <cgfname> on ISP ispName SWACTED

Switch of activity occurred for primary and secondary CGFs.

YES YES

MIB Variable Values

ssg5000GtpAcctEventId gtpAcctCgfSwact(1)


ssg5000TrapCGFName A trap variable object for providing the CGF address

ssg5000EventDesrc A trap object for describing a GTP Acct Event



major(2),

minor(4),

info(8)



Table 9-42SNMP Generic Event MIB Notification Object

Below is an OID for the SNMP generic event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000EventNotification(24)

Prepaid Service SNMP AlarmsThe GGSN Prepaid Service alarms are listed in Table 9-43. They are sent using the MIB object ssg5000SCPAlarmNotification described in Table 9-44.

MIB Variable Values

ssg5000EventId 16

ssg5000EventCategory 76

ssg5000EventDesrc A trap object for describing a GTP Acct Event



major(2),

minor(4),

info(8)


411-5221-926 Standard 10.07 June 2006

Table 9-43GGSN Prepaid Service Alarms

Table 9-44SNMP GGSN Prepaid Service Alarm MIB Notification Object

Below is an OID for the SNMP SCP Alarm Notification object:

GGSN Function

Trap Severity

Alarm State

Alarm Description

Transfer to SCS


Prepaid Service

CRITICAL

alarmOccur

SCP server(s) configured in the Tariff Profile on ISP is not reachable.

YES YES

CRITICAL

alarmClear

SCP server(s) is reachable.

YES YES

MIB Variable Values

ssg5000SCPAlarmId noScpAvailable(1)


ssg5000TrapProfileName A trap variable object for providing the Profile name


alarmClear(2)



major(2),

minor(4),

info(8)



iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000SCPAlarmNotification(60)

WAP SNMP AlarmsThe 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 Function

Trap Severity

Alarm State

Alarm Description

Transfer to SCS


WAP Service

CRITICAL

alarmOccur

Application server is not responding to Accounting START/INTERIM UPDATE/STOP requests and the total of these unacknowledged requests has hit the threshold provisioned in the corresponding application server profile.

YES YES

CRITICAL

alarmClear

Application server responding again.

YES YES

CRITICAL

alarmOccur

Application server does not respond to Accounting ON/OFF requests.

YES YES

CRITICAL

alarmClear

Application server responding to accounting requests.

YES YES


411-5221-926 Standard 10.07 June 2006

Table 9-46SNMP GGSN WAP Alarm MIB Notification Object

Below is an OID for the SNMP WAP Alarm Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000WrapAlarmNotification(61)

ISP Manager SNMP AlarmsThe GGSN ISP Manager alarms are listed in Table 9-47. They are sent using the MIB object ssg5000ISPAlarmNotification described in Table 9-48.

MIB Variable Values

ssg5000WrapAlarmId wrlsAppServerFailResponse(1)

wrlsAppServerUnactivated(2)


ssg5000TrapServerName A trap variable object for providing the Server name


alarmClear(2)



major(2),

minor(4),

info(8)



Table 9-47 GGSN ISP Manager Alarms

Table 9-48SNMP GGSN ISP Manager Alarm MIB Notification Object

Below is an OID for the SNMP ISP Alarm Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000ISPAlarmNotification(62)

GGSN Function

Trap Severity

Alarm State

Alarm Description

Transfer to SCS


ISP Manager

CRITICAL alarmOccur

ISP operational state is down. No traffic can be sent from Gn->Gi for this ISP

YES YES

CRITICAL alarmClear

ISP operational state was Down, is now UP.

YES YES

MIB Variable Values

ssg5000ISPAlarmId ispOperStateDown(1)



alarmClear(2)



major(2),

minor(4),

info(8)


411-5221-926 Standard 10.07 June 2006

ISP Manager SNMP EventsThe 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

Table 9-50SNMP GGSN ISP Manager Event MIB Notification Object

GGSN Function

Trap Severity


Event Description

Transfer to SCS


ISP Manager

CRITICAL Add ISP ispName failed

Attempt to add an ISP failed; ISP was not created.

YES YES

MINOR Address Pool pool_name activation failed for isp ispName (err_str)

An address pool activation failed alarm is generated when routing code fails to add summary route to the pool. This is very unlikely scenario.

YES YES

MIB Variable Values

ssg5000ISPEventId ispAddFailed(1)

ispAddrPoolActivationFailed(2)


ssg5000EventDescr A trap object for describing a ISP Event




Below is an OID for the SNMP ISP Event Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000ISPEventNotification(63)

RADIUS Accounting SNMP AlarmsThe GGSN RADIUS Accounting alarms are listed in Table 9-51. They are sent using the MIB object ssg5000AAAAlarmNotification described in Table 9-52.


major(2),

minor(4),

info(8)

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Table 9-51 GGSN RADIUS Accounting Alarms

GGSN Function

Trap Severity

Alarm State


Transfer to SNMP Manager based On Configuration

RADIUS Accounting

CRITICAL

alarmOccur

Error occurred when writing RADIUS accounting record to disk. Only one alarm of this type is generated in a hour interval and a throttle timer of one hour duration is started.

YES YES

CRITICAL

alarmClear

Disk error resolved for RADIUS. The alarm is cleared if the problem no longer persists and the throttle timer started when alarm was raised has expired.

YES YES

MAJOR alarmOccur

Could not contact any RADIUS server for the specified RADIUS profile. Writing to Disk.

YES YES

MAJOR alarmClear

Able to contact a RADIUS server for the specified RADIUS profile. Writing to Disk alarm is cleared.

YES YES

MAJOR alarmOccur

Could not contact any RADIUS Authentication server for the specified RADIUS profile.

An alarm is generated after 3 consecutive session attempt failure for a particular SSP.

YES YES

MAJOR alarmClear

Able to contact a RADIUS Authentication server for the specified RADIUS profile. The alarm is cleared if the problem no longer persists and the throttle timer (started when alarm was raised) has expired

YES YES



Table 9-52SNMP GGSN RADIUS Accounting Alarm MIB Notification Object

Below is an OID for the SNMP RADIUS Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000AAAAlarmNotification(64)

RADIUS Accounting SNMP EventsThe GGSN RADIUS Accounting events are listed in Table 9-53. They are sent using the MIB object ssg5000GGSNAAAEventNotification described in Table 9-54.

MIB Variable Values

ssg5000AAAAlarmId aaaDiskWriteError(1),

aaaWritingToDisk(2),

aaaAuthServerUnreachable(3)


ssg5000TrapProfileName A trap variable object for providing the Profile name


alarmClear(2)



major(2),

minor(4),

info(8)


411-5221-926 Standard 10.07 June 2006

Table 9-53 GGSN RADIUS Accounting Events

GGSN Function

Trap Severity


Event Description Transfer to SCS


RADIUS Accounting

CRITICAL

ISP ispName APN apnName no RADIUS profile.

RADIUS profile not configured for the ISP and APN and RADIUS Accounting option is chosen. Only a maximum of 20 alarms of this type are generated in 5 minutes interval.

YES YES

CRITICAL

ISP ispName APN apnName no RADIUS server.

No Accounting server provisioned and RADIUS Accounting option is chosen. Only one alarm of this type is generated in a hour interval for each RADIUS Profile.

YES YES

CRITICAL

ISP ispName APN apnName no primary RADIUS Server Present.

No Primary Accounting Server specified and RADIUS Accounting Option is chosen. Only one alarm of this type is generated in a hour interval for each RADIUS Profile

YES YES

MINOR Acct-Off timed out for Radius server server_name in profile profile_name.

GGSN couldn't get the response for RADIUS Acct OFF message after configured number of retries on the profile.

NO YES

MINOR Address Pool pool_name deletion failed for isp ispName (err_str)”

There are some GTP sessions using the address pool that AAA Manager is trying to delete and can not invoke take down on these sessions by sending a request to GTP Manager. This is very unlikely scenario.

YES YES



Table 9-54SNMP GGSN RADIUS Accounting Event MIB Notification Object

Below is an OID for the SNMP RADIUS Accounting Event Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000GGSNAAAEventNotification(65)

GGSN Lawful Interception AlarmsThe GGSN Lawful Interception alarms are listed in Table 9-55. They are sent using the MIB object ssg5000LIAlarmNotification described in Table 9-56.

MIB Variable Values

ssg5000GGSNAAAEventId aaaNoAcctProfile(1),

aaaNoAcctServer(2),

aaaNoPrimaryServer(3),

aaaAcctOffTimeout(4),

aaaAddrPoolDeletionFailed(5)


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)


411-5221-926 Standard 10.07 June 2006

Table 9-55 GGSN LI Alarms

Table 9-56SNMP GGSN LI Alarm MIB Notification Object

GGSN Function

Trap Severity

Alarm State



Lawful Interception

MAJOR alarmOccur

TCP connection to the ADMF is down.

YES YES

MAJOR alarmClear

TCP connection to the ADMF is up.

YES YES

MAJOR alarmOccur

TCP connection to DF(s) is down.

YES YES

MAJOR alarmClear

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

YES YES

MIB Variable Values

ssg5000LIAlarmId liAdmfLinkDown(1),

liDfLinksDown(2)

ssg5000LINumDfLinksDown A trap variable object for providing the number of DF links down.


alarmClear(2)



Below is an OID for the SNMP LI Alarm Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000LIAlarmNotification(66)

SNMP Overload AlarmsThe 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.

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



major(2),

minor(4),

info(8)

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Table 9-57 CPU Overload Condition Alarms

Memory AlarmsWhen 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 Type

Overload level

CPU Occupancy

Alarm Severity

Alarm Description

CPU Total Overload

Normal 0% - 74% INFORMATION

CPU Overload Level 0

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

Normal 0% - 19% INFORMATION

CPU Interrupt Overload Level 0

Level 3 20% - 100% CRITICAL CPU Interrupt Overload Level 3

Overload Type

Overload level

Memory Occupancy/Fragmentation

Alarm Severity

Alarm Description

Memory Overload

Normal >= 100 MB Free AND

>= 512 KB block sizes

INFORMATION

Memory Overload Level 0

Level 1 < 100 MB Free OR

< 512 KB block sizes

MINOR Memory Overload Level 1


< 256 KB block sizes

MAJOR Memory Overload Level 2


< 64 KB block sizes

CRITICAL Memory Overload Level 3



Disk Capacity AlarmsThe 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.

Table 9-59 Disk Capacity Overload Condition Alarms

RADIUS Accounting File AlarmsWhen 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.

Overload Type

Overload level

Disk Occupancy Alarm Severity

Alarm Description

Disk Capacity

Normal 0% - 64% (CMC2 card)

0% - 87% (CMC3 card)

INFORMATION

NORMAL: <devName> is <percent_full>% full. (Downgraded)

Level 2 65% - 71% (CMC2 card)

88% - 93% (CMC3 card)

MAJOR WARNING: <devName> is <percent_full>% full. If this level is reached due to an increase in available disk space, (Downgraded) will be added to the message.

Level 3 72% - 100% (CMC2 card)

94% - 100% (CMC3 card)

CRITICAL CRITICAL: <devName> is <percent_full>% full.


411-5221-926 Standard 10.07 June 2006

GTP Accounting File AlarmsWhen 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.

Table 9-60 RADIUS Accounting File Alarm

Overload Type

Overload Level

Number of RADIUS Accounting Files

Alarm Severity

Alarm Description

RADIUS Accounting Files

Normal < 5000 INFORMATION

"NORMAL: Number of files in directory %s [dirname] is below suggested limit of %d [ssg5000TrapOverloadResourceValue]"

Level 2 > 5000 & < 6000 MAJOR "WARNING: %s [dirname] has %d [ssg5000TrapOverloadResourceValue] files (suggested maximum is %d [maxnum]

Level 3 > 6000 CRITICAL "CRITICAL: File writing to directory %s [dirname] has stopped due to file number %d [ssg5000TrapOverloadResourceValue] exceeding %d [maxnum]"



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.

Overload MIB Notification ObjectA 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-62SNMP Overload Alarm MIB Notification Object

Table 9-61 GTP Accounting File Alarm

Overload Type

Overload Level

Number of GTP Accounting Files

Alarm Severity

Alarm Description

GTP Accounting Files

Normal < 5000 INFORMATION

"NORMAL: Number of files in directory %s [dirname] is below suggested limit of %d [ssg5000TrapOverloadResourceValue]"

Level 2 > 5000 & < 6000 MAJOR "WARNING: %s [dirname] has %d [ssg5000TrapOverloadResourceValue] files (suggested maximum is %d [maxnum])"

Level 3 > 6000 CRITICAL "CRITICAL: File writing to directory %s [dirname] has stopped due to file number %d [ssg5000TrapOverloadResourceValue] exceeding %d [maxnum]"

MIB Variable Values

ssg5000TrapSlotId Slot number

ssg5000TrapCardType Card type

ssg5000TrapPortId Port number

ssg5000TrapProcessor id NA = 0

P0=1

P1=2

P2=3

P3=4


411-5221-926 Standard 10.07 June 2006

ssg5000TrapOverloadResourceType

CPU_TOTAL_OVERLOAD =0

CPU_INTERRUPT_OVERLOAD = 1

MEMORY_OVERLOAD =2

BANDWIDTH_OVERLOAD=3

SSP_RESOURCE_OVERLOAD=4

RPC_BUFFER_OVERLOAD=5

DISK_CAPACITY_OVERLOAD=6

ENCRYPTION_SSP_OVERLOAD=7

ssg5000TrapOverloadLevel NORMAL =0

LEVEL_1 = 1

LEVEL_2 = 2

LEVEL_3 = 3

ssg5000TrapOverloadResourceValue

integer

ssg5000TrapOverloadAlarmDescription

A valid text string

ssg5000TrapSSGHostAddress

IP address of GGSN


major(2),

minor(4),

info(8)

ssg5000EventCategory Disk Capacity category (81)

MIB Variable Values



Below is an OID for the SNMP overload alarm notification object.

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(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-63Nortel GGSN Overload MIB Notification

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.

ID MIB Variable Type Description

ssg5000TrapIndexGroup 42

ssg5000TrapOverloadResourceType

OverloadResourceType

A trap variable object for displaying overload resource type


ssg5000TrapOverloadLevel

OverloadLevel

A trap object for indicating Overload Level


ssg5000TrapOverloadAlarmDescription

DisplayString A trap object for describing an overload alarm


ssg5000TrapProcessorId

ProcessorType

A trap object for indicating processor id.


ssg5000TrapOverloadResourceValue

Integer32 A trap object for overload resource value

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Disk Capacity EventsGGSN 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:


A ssg5000EventNotification SNMP trap is generated corresponding to the “Writing to disk allowed” event as the following:


MIB Variable Values

ssg5000EventId 4


ssg5000EventDesrc Writing to disk stopped. Disk space total=<total_space>K, free=<free_space>K, reserved=<reserved_space>K.


ssg5000TrapSeverity critical(1)

MIB Variable Values

ssg5000EventId 5


ssg5000EventDesrc 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 generic event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000EventNotification(24)

SNMP Patch AlarmA 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-66Patch Manager Alarms

Table 9-67Trap Patch Alarm MIB Notification Object

ssg5000TrapSeverity info(8)

GGSN Function

Trap Severity

Alarm State

Alarm Description

Transfer to SCS


Patch Manager

MAJOR alarmOccur

Patch data is out of sync between SSG and SCS

YES YES

MAJOR alarmClear

Patch data is out of sync between SSG and SCS

YES YES

MIB Variable Values

ssg5000TrapSlotId slot number

ssg5000TrapCardType card type

ssg5000TrapPortId port number

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Below is the OID for the SNMP Trap Patch Alarm Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000TrapPatchAlarmNotification(72)

Diameter Credit Control (DCC) AlarmsThe 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.

ssg5000TrapProcessorId processor number


major(2),

minor(4),

info(8)

ssg5000TrapPatchSyncStatus 0 - In Sync

1 - Out of Sync

ssg5000TrapSSGHostAddress IP address of GGSN


alarmClear(2)

MIB Variable Values



Table 9-68 GGSN DCC Alarms

Table 9-69SNMP GGSN DCC Alarm MIB Notification Object

GGSN Function

Trap Severity

Alarm State



Diameter Credit Control

CRITICAL alarmOccur

No Diameter server(s) configured in the DCC Profile on ISP is reachable.

YES YES

CRITICAL alarmClear

At least one Diameter server is now reachable or all Diameter servers are offline.

YES YES

MINOR alarmOccur

Diameter server at address configured on Diameter Profile on ISP is not reachable.

YES YES

MINOR alarmClear

Diameter server is now reachable or has been put in an offline state.

YES YES

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.


411-5221-926 Standard 10.07 June 2006

Below is the OID for the DCC Alarm Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000DCCAlarmNotification(69)

DCC SNMP EventsThe 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.


alarmClear(2)



major(2),

minor(4),

info(8)

MIB Variable Values



Table 9-70 GGSN DCC SNMP Events

GGSN Function

Trap Severity


Event Description Transfer to SCS


Diameter Credit Control

INFO UNRECOGNIZED RATE ID <categoryId> RECEIVED from DCC SERVER <serverIpAddr> for MSISDN <msisdn>, POLICY <profileName>, ISP <ispName>.

Diameter Peer received an Unrecognized Rate ID from GGSN.

YES YES

MAJOR Tx TIMER EXPIRATIONS OF COUNT <TxExpiryCount> EXCEEDED MAJOR THRESHOLD ON DIAMETER PROFILE <profileName> AT DIAMETER SERVER <serverIpAddr>.

By the end of the Tx Timer Event Interval, the number of Tx Expiries was at least equal to the major threshold but less than the critical threshold.

YES YES

CRITICAL Tx TIMER EXPIRATIONS OF COUNT <TxExpiryCount> EXCEEDED CRITICAL THRESHOLD ON DIAMETER PROFILE <profileName> AT DIAMETER SERVER <serverIpAddr>.

By the end of the Tx Timer Event Interval, the number of Tx Expiries was at least equal to the critical threshold.

YES YES


411-5221-926 Standard 10.07 June 2006

Table 9-71SNMP GGSN DCC Event MIB Notification Object

Below is the OID for the DCC Event Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000DCCEventNotification(81)

Health Check Monitor AlarmsThe GGSN Health Check Monitor alarms are listed in Table 9-72. They are sent using the MIB object ssg5000HCMAlarmNotification described in Table 9-73

MIB Variable Values

ssg5000DccEventId dccInvalidCategoryId(1),dccTxExpirationsExceededMajorThreshold(2),dccTxExpirationsExceededCriticalThreshold(3)


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.



Table 9-72 GGSN Health Check Monitor Alarms

GGSN Function

Trap Severity

Alarm State



Health Check Monitor

CRITICAL alarmOccur

Nodal Activation Success Rate has crossed the Threshold Value.

YES YES

CRITICAL alarmClear

Nodal Activation Success Rate has crossed the Threshold Value.

YES YES

CRITICAL alarmOccur

Network Activation Success Rate has crossed the Threshold Value.

YES YES

CRITICAL alarmClear

Network Activation Success Rate has crossed the Threshold Value.

YES YES

INFO alarmOccur

Attempted Activations have crossed the Threshold Value

YES YES

INFO alarmClear

Attempted Activations have crossed the Threshold Value

YES YES


411-5221-926 Standard 10.07 June 2006

Table 9-73SNMP GGSN Health Check Monitor Alarm MIB Notification Object

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

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000HCMAlarmNotification(82)

MIB Variable Values

ssg5000HCMAlarmId hcmNodalActivationSuccessRateDrop(1),

hcmNetworkActivationSuccessRateDrop(2),

hcmNoActivationAttempt(3)

ssg5000TrapHCMCurrentSuccessRate

A trap variable indicating the current success rate for Nodal or Network Activations

ssg5000TrapHCMCurrentValue A trap variable indicating the current value for

Nodal success rate or

Network success rate or

Attempted activations.


alarmClear(2)



major(2),

minor(4),

info(8)



Content FilterThe following new alarms are added for the Content Filter functional area.

Table 9-74 GGSN CFS Alarms

Alarm Function

Trap Severity

Alarm State

Alarm Description

Transfer to SCS

Transfer to SNMP Manager

Content Filtering Service

MAJOR AlarmOccur

No Content Filter servers are available on profile <profile> on ISP <ISP> VPN <VPN>.

YES YES

MAJOR AlarmClear

No Content Filter servers are available on profile <profile> on ISP <ISP> VPN <VPN>.

YES YES

MINOR AlarmOccur

Content Filter server at <address>:<port> on profile <profile> on ISP <ISP> VPN <VPN> is unavailable.

YES YES

MINOR AlarmClear

Content Filter server at <address>:<port> on profile <profile> on ISP <ISP> VPN <VPN> is unavailable.

YES YES


411-5221-926 Standard 10.07 June 2006

Table 9-75SNMP GGSN CFS Alarm MIB Notification Object

Below is an OID for the SNMP CFS alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000CfsAlarmNotification(70)

SER Base SNMP TrapsSNMP AAA EventsThe SNMP AAA events are listed in Table 9-76. They are sent using the MIB object ssg5000AAAEventNotification described in Table 9-77.

New MIB Variable Values

ssg5000CfsAlarmId cfsNoServerAvailable(1),

cfsServerUnavailable(2)


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)



major(2),

minor(4),

info(8)



Table 9-76 SNMP AAA Events

GGSN Function

Trap Severity

Event Text Event Description Transfer to SCS


AAA Manager

INFO Session disconnect successful <success string>

Session successfully disconnected

NO YES

MAJOR Session disconnect failed <failure string>

Session failed to disconnect

NO YES

INFO Session disconnect ignored. <ignore string>

Session disconnect request ignored

NO YES

INFO WARNING radius_acct: NULL username Len <name length>

radius account user name is too small

NO YES

INFO WARNING radius_acct: [<caller id>] RADIUS_ACCT_SESSION aaaid <session id> Username <user name> len <name length> too Big

radius account user name is too long

NO YES

MINOR Freeing bad AAA reply structure with address <reply attributes> tlv-count <tlv count> in <ra>

AAA manager is freeing the memory of invalid reply structure. This event is used only for debugging purpose

NO YES

INFO Freeing bad AAA auth structure with address <auth attributes> tlv-count <tlv count> in <ra>

AAA manager is freeing the memory of invalid authentication structure. This event is used only for debugging purpose

NO YES

MINOR User <user> authentication failed

User authentication failed

NO YES


411-5221-926 Standard 10.07 June 2006

Table 9-77SNMP AAA Event MIB Notification Object

Below is an OID for the SNMP AAA Event Notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000AAAEventNotification(26)

SNMP SCS Sync AlarmsThe detailed information of SER base SNMP Sync alarms is given in Table 9-78.

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)



Table 9-78SER Base SNMP SCS Sync Alarms

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-79SNMP SCS Sync Alarm MIB Notification Object

Below is an OID for the SER base SCS Sync alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000SCSSyncNotification(20)

SNMP SCS Server AlarmsThe detailed information of SER base SNMP SCS Server alarms is given in Table 9-80.

Shasta Function

Alarm Severity

Alarm State

Alarm Description

GGSN Synchronization

MINOR alarmOccur Synchronization between SCS region server and GGSN is out-of-sync.

INFO alarmClear Synchronization between SCS region server and GGSN is in-sync.

MIB Variable Values

ssg5000TrapSCSSyncAlarmId outOfSynced(1)

ssg5000TrapSCSServerIpAddr A trap variable object for providing the SCS IP address

ssg5000TrapOccurClearTag alarmOccur(1)

alarmClear(2)



major(2),

minor(4),

info(8)


411-5221-926 Standard 10.07 June 2006

Table 9-80SER Base SNMP SCS Server Alarms

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-81SNMP SCS Server Alarm MIB Notification Object

Shasta Function

Alarm Severity

Alarm State

Alarm Description

SCS Server MINOR alarmOccur GGSN Connection with the SCS server is down.

INFO alarmClear GGSN connection with SCS Server is up

MIB Variable Values

ssg5000TrapSCSServerAlarmId connectionDown1)

ssg5000TrapSCSServerType unknownServer(1)

logServerLog(2)

pullServer(3)

regionServer(4)

monitoringServer(5)

logServerAccounting(6)

ssg5000TrapSCSServerIpAddr A trap variable object for providing the SCS IP address

ssg5000TrapSCSServerPortNumber

A trap variable object for providing the SCS Server Port number


alarmClear(2)



major(2),

minor(4),

info(8)



Below is an OID for the SER base SCS Server alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000SCSServerNotification(21)

SNMP System AlarmsThe detailed information of SER base SNMP System alarms is given in Table 9-82.


411-5221-926 Standard 10.07 June 2006

Table 9-82 SER Base SNMP System Alarms

Shasta Function

Alarm Severity

Alarm State SCS Alarm Text

Alarm Description

System CRITICAL alarmOccur DC Power Failure

One or more AC or DC power has failed.

INFORMATION

alarmClear DC Power Failure

AC and/or DC power failure has been cleared

CRITICAL alarmOccur AC_DC Shelf Over Temperature

One or more of the DC power modules in the AC shelf is over temperature.

INFORMATION

alarmClear AC_DC Shelf Over Temperature

Over temperature condition of the DC power modules in the AC shelf has been cleared

CRITICAL alarmOccur AC_DC Shelf Failure

One or more of the DC power modules in AC shelf has failed.

MAJOR alarmOccur AC_DC Shelf Failure

Fan tray DC power module in AC Shelf has failed

MINOR alarmOccur AC_DC Shelf Failure

One or more of the DC power modules in AC Shelf is missing.

INFORMATION

alarmClear AC_DC Shelf Failure

Failed/Missing DC power module condition has been cleared

CRITICAL alarmOccur Node rebooted

The node was rebooted by itself.

This alarm is not clearable

CRITICAL alarmOccur Multiple fan failure

Multiple fans have failed.

INFORMATION

alarmClear Multiple fan failure

Multiple fans fail condition is cleared

MAJOR alarmOccur Fan failure Single fan has failed.

CRITICAl alarmOccur Fan failure Fan tray is NOT installed

INFORMATION

alarmClear Fan failure Fan tray / single fan failure condition has been cleared

INFORMATION

alarmOccur System SSMs up

All the SSC cards are up now 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-83SNMP System Alarm MIB Notification Object

Below is an OID for the System alarm 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)



major(2),

minor(4),

info(8)


411-5221-926 Standard 10.07 June 2006

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000SysAlarmNotification(2)

SNMP Card AlarmsThe detailed information of SER base SNMP Card alarms is given in Table 9-84.



Table 9-84 SER Base SNMP Card Alarms

Shasta Function

Alarm Severity

Alarm State

SCS Alarm Text Alarm Description

Card INFO alarmOccur Card missing Slot is configured but no card inserted when the node starts up.

INFO alarmOccur Card in Service The card has been inserted into a slot.

MAJOR alarmOccur Card out of service The card has been removed from its slot.

MAJOR alarmOccur Card Mismatch The installed card type does not match the slot configuration.

CRITICAL alarmOccur Card boot The card is booting from the configuration file.

CRITICAL alarmOccur Card reboot The card was booted by itself.

MINOR alarmOccur Card revision mismatch Incompatible hardware or software version in card.

CRITICAL alarmOccur Card failed in boot The card has failed one or more diagnostics tests during booting.

CRITICAL alarmOccur Card malfunction The card has failed to perform some functions.

MAJOR alarmOccur Card diagnostics The card has failed one or more diagnostics test during booting.

CRITICAL alarmOccur Card dead CMC can not talk to the card.

INFO alarmOccur Card switched active The standby card becomes active after a switch over.The alarm applies only to CMC cards.

CRITICAL alarmOccur Card standby not in redundant

The active card issues this 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.


411-5221-926 Standard 10.07 June 2006

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.

Card INFORMATION

alarmOccur PCMCIA card inserted PCMCIA card has been inserted into the chassis or detected at boot time.

MAJOR alarmOccur PCMCIA card removed PCMCIA card has been removed from the chassis or detected that it is not present at boot time.

MINOR alarmOccur Card unconfigured Card found in unconfigured slot

INFORMATION

alarmOccur Card Up Card is in operational state

CRITICAL alarmOccur Card Disable The card has been administratively disabled

INFORMATION

alarmOccur Card Enable The card has been administratively enabled

INFORMATION

alarmOccur Card switch over is initiated by user

Card switch over is initiated by user via CLI command

MAJOR alarmOccur Card switch over is initiated internally

Card switch over is triggered by internal reason

MINOR alarmOccur Card Standby Not in Redundant

CMC standby and CMC active don’t have the same config/software version

INFO alarmClear Card Standby Not in Redundant

CMC standby and CMC active do have the same config/software version

CRITICAL alarmOccur Card Switched Active SFC Switch to standby SFC has started.

CRITICAL alarmClear Card Switched Active SFC switch to newly active is complete.

Shasta Function

Alarm Severity

Alarm State

SCS Alarm Text Alarm Description



Table 9-85SNMP 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(16)

cardSwitchoverInitiatedInternal(17)

cardEnable(18)

cardDisable(19)

cardUp(20)

cardUnconfigured(21)

ssg5000TrapSlotId A trap slot ID for slot number


411-5221-926 Standard 10.07 June 2006

Below is an OID for the SER base Card alarm notification object:

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)



major(2)

minor(4)

info(8)

MIB Variable Values



iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000CardAlarmNotification(3)

SNMP Card EventsThe detailed information of SER base SNMP Card events is given in Table 9-86.

Table 9-86 SER Base SNMP Card Events

Table 9-87 defines the SER base SNMP Card Event MIB object.

Table 9-87SNMP Card Event MIB Notification Object

Shasta Function

Event Severity

Event Description Text Event Description

Card Major Found card of type <card_type> in slot <slotId>, but slot is not usable.

inserting card in unusable slot

INFORMATION

Card type <card_type> in slot <slotId> is administratively disabled

Card left down since it is administratively disabled.

MAJOR Firmware update of card in slot <slotId> failed

Failed to update the card firmware

INFORMATION

Firmware update of card in slot <slotId> succeeded.

The card firmware is successfully updated

MIB Variable Values

ssg5000CardInfoType cardLeftInactive(1)

cardIgnored(2)

cardFoundUnusable(3)

cardLeftDown(4)

cardReprogrammedSuccess(5)

cardReprogrammedFail(6)



411-5221-926 Standard 10.07 June 2006

Below is an OID for the SER base Card Event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000CardEventNotification(28)

SNMP ATM Port AlarmThe detailed information of SER base SNMP Port alarms is given in Table 9-88.

ssg5000EventDescr A trap object for describing card manager event



major(2)

minor(4)

info(8)

MIB Variable Values



Table 9-88 SER Base SNMP Port Alarms

Shasta Function

Alarm Severity

Alarm State

SCS Client Alarm Text

Alarm Description

ALC Port

INFORMATION

alarmClear

ALC Port Up The port on the ALC card family is administratively enabled.

MAJOR alarmOccur

ALC Port Down The port on the ALC card family is administratively disabled or some alarms (i.e. LOS, LOF) caused the port to become disabled operationally.

MINOR alarmOccur

ALC Line loopback activated

A line loopback has been activated on the port.

MINOR alarmClear

ALC Line loopback activated

A line loopback has been de-activated on the port.

MINOR alarmOccur

ALC LOS LOS (Loss of Signal) detected on the incoming signal. A failure occurs at the source (e.g. laser failure) or the transmission facility.

INFORMATION

alarmClear

ALC LOS LOS (Loss of Signal) detected on the incoming signal has been cleared

MINOR alarmOccur

ALC LOF LOF (Loss of Frame) detected on the incoming signal. A failure related to the SONET framing.

INFORMATION

alarmClear

ALC LOF LOF (Loss of Frame) detected on the incoming signal has been cleared.

MINOR alarmOccur

ALC Line AIS Line layer AIS (Alarm Indication 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 AIS Line layer AIS (Alarm Indication Signal) condition has been cleared.

MINOR alarmOccur

ALC Line RDI Line layer RDI (Remote Defect Indication) detected.


411-5221-926 Standard 10.07 June 2006

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.

ALC Port

INFORMATION

alarmClear

ALC Line RDI Line layer RDI (Remote Defect Indication) condition has been cleared

MINOR alarmOccur

ALC LOP LOP (Loss of Path) detected. A failure related to the SONET pointer processing mechanism.

INFORMATION

alarmClear

ALC LOP LOP (Loss of Path) condition has been cleared.

MINOR alarmOccur

ALC Path AIS Path layer AIS (Alarm Indication 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 AIS Path layer AIS (Alarm Indication Signal) detected. A defect (i.e. LOS, LOF) condition has been cleared.

MINOR alarmOccur

ALC Path RDI Path layer RDI (Remote Defect 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 RDI Path layer RDI (Remote Defect Indication) condition has been cleared

MINOR alarmOccur

ALC Loss of cell delineation

Failure to detect ATM cell boundary/framing.

INFORMATION

alarmClear

ALC Loss of cell delineation

Failure to detect ATM cell boundary/framing condition has been cleared

Shasta Function

Alarm Severity

Alarm State


Alarm Description



Table 9-89SNMP 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),



411-5221-926 Standard 10.07 June 2006

Below is an OID for the SER base ATM Port alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000PortAlarmNotification(4).

SNMP ALC EventsThe detailed information of SER base SNMP ALC Event is given in Table 9-90.




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)



major(2),

minor(4),

info(8)

MIB Variable Values



Table 9-90 SER Base SNMP ALC Events

Table 9-91 defines the SER base SNMP ALC Event MIB object.

Table 9-91SNMP ALC Event MIB Notification Object

Below is an OID for the SER base ALC Event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000ALCEventNotification(27)

SNMP SSM AlarmThe detailed information of SER base SNMP SSM alarms is given in Table 9-92.

Shasta Function

Event Severity


ALC INFO ALC slot <slotId> ICP <icp> CAM <cam> is full

ALC cam is full

MAJOR ALC slot <slotId> port <portid> YELLOW

ALC Port is YELLOW

MAJOR ALC slot <slotId> bad ICP

ALC slot has bad icp

MIB Variable Values

ssg5000ALCInfoType alcCamFull(1)

alcPortYellow(2)

alcIcpFailed(3)

ssg5000EventDescr A trap object for describing ALC event



major(2)

minor(4)

info(8)


411-5221-926 Standard 10.07 June 2006

Table 9-92 SER Base SNMP SSM Alarms

Table 9-93 defines the SER base SNMP SSM alarms MIB object. The notification signal the agent detects an alarm status in the SSM.

Shasta Function

Alarm Severity

Alarm State

Alarm Text Alarm Description

SSM CRITICAL alarmOccur

SSM Failed The SSM failed to 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 alarmOccur

SSM Reset This is a transient state and 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.

INFORMATION

alarmClear

SSM Up After a successful boot, it issues this trap. Now it is in a proper state to service the packet flow.

MAJOR alarmOccur

SSM Down The SSM on the SSC card has been administratively disabled.

CRITICAL alarmOccur

SSM Down SSM on the SSC card is stuck in catchup due to congestion; Taking it temporarily down; To recover manually reset SSM

CRITICAL alarmOccur

SSM Dead SSM has died due to sw module error



Table 9-93SNMP 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)


411-5221-926 Standard 10.07 June 2006

Below is an OID for the SER base SSM 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).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



major(2)

minor(4)

info(8)

Shasta Function

Alarm Severity


SSM MINOR SSM <portId> in slot <slotId> is disabled

SSSM was administratively disabled

MAJOR Erratic SSM: <slotId> <portId> <cpu_miss0> <cpu_miss1> <cpu_miss2> <cpu_miss3>

Error detected in SSM

MAJOR Erratic downloading SSM: <slotId> <portId> <cpu_miss0> <cpu_miss1> <cpu_miss2> <cpu_miss3>

Error downloading the software to SMM

INFO SSM <portId> in slot <slotId> started core dump

SSM started a core dump

MAJOR Core Dump failed for SSM <portId> in slot <slotId> Error <errorcode>

SSM failed to dump core

MIB Variable Values



INFO SSM <portId> in slot <slotId> successfully dumped core

SSM successfully dumped core

INFO SSM <portId> in slot <slotId> removal processing done.

removing SSM is done

MAJOR EPIF channel <channelId> in slot <slotId> has died.

EPIF channel has died

MAJOR Reset SSC Card in slot <slotId>

Error detected and SSC card got reset

MAJOR All SSM in slot <slotId> have failed

ALL SSM on specific slot have failed

Shasta Function

Alarm Severity



411-5221-926 Standard 10.07 June 2006

MAJOR SSM <portId> in slot <slotId> has missed poll <iteration> iterations. SSM received <cmc_2_ssm_hello> hellos, CMC received <ssm_2_cmc_hello> hellos

SSM and CMC received unmatched number of “hello” messages.

The logs are seen when the SSMs are booting up.

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 slot <slotId> are reset (<number_of_ticks>)

All connection to SSC on specific slot have been reset

Shasta Function

Alarm Severity




Table 9-95 defines the SER base SNMP SSM Events MIB object.

Table 9-95SNMP SSM Event MIB Notification Object

INFO SSC in slot <slotId> reset successfully (<number_of_ticks>)

SSC has successfully been reset

MINOR CMC received hello from SSM with invalid slot/port: <slotId> <portId>

CMC received invalid slop/port in the hello message from SSM

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


Shasta Function

Alarm Severity



411-5221-926 Standard 10.07 June 2006

Below is an OID for the SER base SSM Event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000SSMEventNotification(31)

SNMP Ethernet Port AlarmsThe detailed information of SER base SNMP Ethernet port alarms is given in Table 9-96.

Table 9-96 SER Base SNMP Ethernet Port Alarms

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.

Table 9-97SNMP Ethernet Port Alarm MIB Notification Object



major(2)

minor(4)

info(8)

Shasta Function

Alarm Severity

Alarm State


Alarm Description

ETH Port

MAJOR alarmOccur ETH Link Down The port is either 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.

MIB Variable Values

ssg5000TrapETHPortAlarmId ethLinkDown(1)


MIB Variable Values



Below is an OID for the SER base Ethernet Port alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000ETHPortAlarmNotification(8)

SNMP ELC EventsThe detailed information of SER base SNMP ELC Event is given in Table 9-98.




switchFabricCard(3)

oc3AtmLineCard(4)

ds3AtmLineCard(5)

hsiLineCard(6)

e3AtmLineCard(7)

oc12SAtmLineCard(8)

oc12DAtmLineCard(9)

cardTypeUnknown(10)





alarmClear(2)



major(2)

minor(4)

info(8)

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Table 9-98 SER Base SNMP ELC Events

Table 9-99 defines the SER base SNMP ELC Event MIB object.

Table 9-99SNMP ELC Event MIB Notification Object

Below is an OID for the SER base ELC Event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000ELCEventNotification(30)

SNMP SSM EventThe detailed information of SER base SNMP SSM events is given in Table 9-100.

Shasta Function

Event Severity


ELC MAJOR Ethernet slot <slotId>: IPCAM <ipcam> is full

ELC ipcam is full

MIB Variable Values

ssg5000ELCInfoType elcIpCamFull(1)

ssg5000EventDescr A trap object for describing ALC event



major(2)

minor(4)

info(8)



Table 9-100 SER Base SNMP Config Info Events

Table 9-101 defines the SER base SNMP Configuration Events MIB object.

Shasta Function

Alarm Severity


Configuration

INFO Config phase 1 complete Configuration phase 1 complete

CRITICAL

Config phase 1 load failed: <error_reason>

configuration phase 1 loaded failed

INFO Config phase 2 complete Configuration phase 2 complete

CRITICAL

Config phase 2 load failed: <error_reason>

Configuration phase 2 loaded failed

INFO Quickstart information (phase 1) loaded

Quickstart information (phase 1) loaded

CRITICAL

Quickstart load (phase 1) failed: <error_reason>

Quickstart load (phase 1) failed

INFO Quickstart information (phase 2) loaded

Quickstart information (phase 2) loaded

CRITICAL

Quickstart load (phase 2) failed: <error_reason>

Quickstart load (phase 2) failed

INFO Configuration <config_name> initialized

Certain configuration initialized

MINOR Command <command_name> failed: <error_reason>

Certain command has failed

MINOR Error on DB <db_op> in <config> <db> err: <error_num>

Database error

INFO Image files are protected Image files are protected

INFO Image files are not protected Image files are not protected


411-5221-926 Standard 10.07 June 2006

Table 9-101SNMP Config Info MIB Notification Object

Below is an OID for the SER base Config Info notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000ConfigInfoNotification(29)

Config Objects Alarm NotificationTable 9-102 defines the base SER BSN Config Object Changes Alarm Notification. This alarm indicates that the agent has detected a set operation

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



major(2)

minor(4)

info(8)



from the CLI. This event is sent to trigger the SCS to retrieve the specified config object for synchronization.

Table 9-102Config Object Changes MIB Notification Object

Below is an OID for the base SER Service alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000ConfigObjectChangesNotification(22)

SNMP VPN Mesh AlarmsThe detailed information of SER base SNMP VPN Mesh alarms is given in Table 9-103.

Table 9-103 SER Base SNMP VPN Mesh Alarms

Table 9-104 defines the SER base SNMP VPN Mesh alarms MIB object. The notification signals that the SNMP agent detects an alarm status in VPN.

MIB Variable Values

ssg5000TrapConfigChangesAlarmId

set(1)

delete(2)

ssg5000TrapConfigObjectId deviceObject(1)

ssg5000TrapIspName A trap variable object for displaying the ISP name

ssg5000TrapSSGHostAddress The IP address of the GGSN


major(2)

minor(4)

info(8)

Shasta Function

Alarm Severity

Alarm State


Alarm Description

VPN MINOR alarmOccur VPN Mesh Down VPN link failed

MINOR alarmClear VPN Mesh Down VPN link failed condition has cleared


411-5221-926 Standard 10.07 June 2006

Table 9-104SNMP VPN Mesh Alarm MIB Notification Object

Below is an OID for the SER base VPN Mesh alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000VPNMeshtAlarmNotification(13)

SNMP System Monitor AlarmsThe detailed information of SER base SNMP System Monitor alarms is given in Table 9-105.

MIB Variable Values

ssg5000TrapVPNMeshAlarmId vpnMeshDown(1)

ssg5000TrapVPNGlobalId A trap vpn global ID for slot number


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)



major(2)

minor(4)

info(8)



Table 9-105 SER Base SNMP System Monitor Alarms

Table 9-106 defines the SER base SNMP VPN Mesh alarms MIB object.

Table 9-106SNMP System Monitor Alarm MIB Notification Object

Shasta Function

Alarm Severity

Alarm State


Alarm Description

System monitor

MINOR alarmOccur Subscriber count increased

Subscriber threshold ratio has been reached at or below, for the threshold range on the port/slot/card of the GGSN

INFO alarmClear Subscriber count increased

The subscriber threshold ratio level is reached at or above the threshold range on the port/slot/card of the GGSN

MIB Variable Values

ssg5000TrapSysmonAlarmId activeSubMonitor(1)



411-5221-926 Standard 10.07 June 2006

Below is an OID for the SER base System Monitor 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).ssg5000SysmonAlarmNotification(25)




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)



major(2)

minor(4)

info(8)

MIB Variable Values



SNMP L2TP AlarmsThe detailed information of SER base SNMP L2TP alarms is given in Table 9-107.

Table 9-107 SER Base SNMP L2TP Alarms

Table 9-108 defines the SER base SNMP L2TP alarms MIB object. The notification signals that the SNMP agent detects an alarm status in L2TP tunnel.

Table 9-108SNMP L2TP Alarm MIB Notification Object

Below is an OID for the SER base L2tp Tunnel alarm notification object:

Shasta Function

Alarm Severity

Alarm State


Alarm Description

L2TP INFO alarmOccur L2TP Tunnel Down L2TP tunnel is down

INFO alarmClear L2TP Tunnel Down L2TP tunnel is up

MIB Variable Values

ssg5000TrapL2tpTunnelAlarmId l2tpTunnelDown(1)

ssg5000TrapL2tpTunnelIfIndex A trap variable object for providing the l2tp tunnel interface index


ssg5000TrapL2tpTunnelName A trap variable object for providing the l2tp tunnel Name

ssg5000TrapL2tpRemoteTunnelName

A trap variable object for providing l2tp remote tunnel name

ssg5000TrapL2tpTunnelType A trap variable object for providing L2tpTunnel type


alarmClear(2)



major(2)

minor(4)

info(8)


411-5221-926 Standard 10.07 June 2006

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000L2tpTunnelAlarmNotification(17)

SNMP PVC AlarmsThe detailed information of SER base SNMP PVC alarms is given in Table 9-109.

Table 9-109 SER Base SNMP PVC Alarms

Table 9-110 defines the SER base SNMP PVC alarms MIB object. The notification signals that the SNMP agent detects an alarm status in a PVC.

Table 9-110SNMP PVC Alarm MIB Notification Object

Shasta Function

Alarm Severity

Alarm State


Alarm Description

PVC Status

MAJOR alarmOccur Connection Down PVC Connection is down

MAJOR alarmClear Connection Down PVC Connection is up

MIB Variable Values

ssg5000TrapPVCAlarmId ConnectionDown(1)

ssg5000TrapSlotId A trap variable object for providing slot id






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)


ssg5000TrapConnectionName A trap variable object for providing the connection Name

ssg5000TrapSubscriberName A trap variable object for providing the subscriber Name

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Below is an OID for the SER base PVC alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000PVCAlarmNotification(6)

SNMP Serial Port AlarmsThe detailed information of SER base SNMP Serial Port alarms is given in Table 9-111.

Table 9-111SER Base SNMP Serial Port Alarms

Table 9-112 defines the SER base SNMP PVC alarms MIB object. The notification signals that the SNMP agent detects an alarm status in a Serial Port.

Table 9-112SNMP Serial Port Alarm MIB Notification Object



major(2)

minor(4)

info(8)

Shasta Function

Alarm Severity

Alarm State

Alarm Description

Serial Port Status

MINOR alarmOccur CMC Serial Port is down

INFO alarmClear CMC Serial is up

MIB Variable Values

ssg5000TrapSerialPortAlarmId serialPortDown(1)


MIB Variable Values



Below is an OID for the SER base Serial Port alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000SerialPortAlarmNotification(19)

SNMP Serial Port Configuration Change EventThe detailed information of SER base SNMP Serial Port event is given in Table 9-113.




switchFabricCard(3)

oc3AtmLineCard(4)

ds3AtmLineCard(5)

hsiLineCard(6)

e3AtmLineCard(7)

oc12SAtmLineCard(8)

oc12DAtmLineCard(9)

cardTypeUnknown(10)





alarmClear(2)



major(2)

minor(4)

info(8)

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Table 9-113SER Base SNMP Serial Port Configuration Change Event

Table 9-114 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-114SNMP Configuration Change Alarm MIB Notification Object

Shasta Function

Event Severity

Event Description Text

Event Description

Serial Port Configuration Change Notification

INFO Serial port configuration change

CMC Serial Port configuration has changed.

MIB Variable Values

ssg5000TrapSerialPortConfigChangeAlarmId

serialPortConfigChanged(1)




Below is an OID for the SER base Serial Port alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000SerialPortAlarmConfigChangeNotification(55)

SNMP VRF AlarmsThe detailed information of SER base SNMP VRF alarms is given in Table 9-115.




switchFabricCard(3)

oc3AtmLineCard(4)

ds3AtmLineCard(5)

hsiLineCard(6)

e3AtmLineCard(7)

oc12SAtmLineCard(8)

oc12DAtmLineCard(9)

cardTypeUnknown(10)






major(2)

minor(4)

info(8)

MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Table 9-115 SER Base SNMP VRF Alarms

Table 9-116 defines the SER base SNMP VRF alarms MIB object. The notification signals that the SNMP agent detects an alarm status for VRF.

Table 9-116SNMP VRF Alarm MIB Notification Object

Below is an OID for the SER base VRF alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000VRFAlarmNotification(38)

SNMP LFIB E-LSP AlarmsThe detailed information of SER base SNMP LFIB E-LSP alarms is given in Table 9-117.

Shasta Function

Alarm Severity

Alarm State


Alarm Description

MPLS VRF

INFO alarmOccur VRF Deactivated VRF VPN is de-activated in ISP

INFO alarmClear VRF Deactivated VRF VPN is activated in ISP

MIB Variable Values

ssg5000TrapVRFAlarmId vrfDown(1)

ssg5000TrapVRFName A trap variable object for providing the VRF Name



alarmClear(2)



major(2)

minor(4)

info(8)



Table 9-117 SER Base SNMP LFIB E-LSP Alarms

Table 9-118 defines the SER base SNMP LFIB E-LSP alarms MIB object. The notification signals that the SNMP agent detects an alarm status in the E-LSP map.

Table 9-118SNMP LFIB E-LSP Alarm MIB Notification Object

Below is an OID for the SER base LFIB E-LSP alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000LFIBAlarmNotification(32)

SNMP MPLS BE-LSP AlarmsThe detailed information of SER base SNMP MPLS BE-LSP alarms is given in Table 9-119.

Shasta Function

Alarm Severity

Alarm State


Alarm Description

E-LSP Map

INFO alarmOccur E-LSP Deactivated E-LSP is de-activated

INFO alarmClear E-LSP Deactivated E-LSP is activated

MIB Variable Values

ssg5000TrapLFIBELSPAlarmId elspMapDelete(1)

ssg5000TrapISPId A trap variable object for providing the ISP ID

ssg5000TrapELSPName A trap variable object for providing the E-LSP name


alarmClear(2)



major(2)

minor(4)

info(8)


411-5221-926 Standard 10.07 June 2006

Table 9-119 SER Base SNMP MPLS BE-LSP Alarms

Table 9-120 defines the SER base SNMP MPLS BE-LSP alarms MIB object. The notification signals that the SNMP agent detects an alarm status for MPLS BE-LSP.

Table 9-120SNMP MPLS BE-LSP Alarm MIB Notification Object

Below is an OID for the SER base MPLS BE-LSP alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000MPLSBELSPAlarmNotification(33)

SNMP MPLS LDP AlarmsThe detailed information of SER base SNMP MPLS LDP alarms is given in Table 9-121.

Shasta Function

Alarm Severity

Alarm State


Alarm Description

MPLS BE-LSP

INFO alarmOccur MPLS BE LSP down MPLS BE-LSP is down

INFO alarmClear MPLS BE LSP down MPLS BE-LSP is up

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)



major(2)

minor(4)

info(8)



Table 9-121 SER Base SNMP MPLS LDP Alarms

Table 9-122 defines the SER base SNMP MPLS LDP alarms MIB object. The notification signals that the SNMP agent detects an alarm status for MPLS LDP.

Table 9-122SNMP MPLS LDP Alarm MIB Notification Object

Below is an OID for the SER base MPLS LDP alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ss gMIBNotification(0).ssg5000MPLSLDPAlarmNotification(35)

Shasta Function

Alarm Severity

Alarm State


Alarm Description

MPLS LDP

INFO alarmOccur MPLS LDP Session down

MPLS LDP Session is down

INFO alarmClear MPLS LDP Session down

MPLS LDP Session is up

MIB Variable Values

ssg5000TrapLDPAlarmId ldpSessionDown(1)



ssg5000TrapInterfaceNumber A trap variable object for providing the Interface number


alarmClear(2)



major(2)

minor(4)

info(8)


411-5221-926 Standard 10.07 June 2006

SNMP MPLS TE-LSP AlarmsThe detailed information of SER base SNMP MPLS RSVP-TE alarms is given in Table 9-123.

Table 9-123 SER Base SNMP MPLS TE-LSP Alarms

Table 9-126 defines the SER base SNMP MPLS TE-LSP alarms MIB object. The notification signals that the SNMP agent detects an alarm status for MPLS TE-LSP.

Table 9-124SNMP MPLS TE-LSP Alarm MIB Notification Object

Shasta Function

Alarm Severity

Alarm State

SCS Client Alarm Text Alarm Description

MPLS TE-LSP

INFO alarmOccur MPLS TE-LSP down MPLS TE-LSP is down

INFO alarmClear MPLS TE-LSP up MPLS TE-LSP is up

MIB Variable Values

ssg5000TrapTELSPAlarmId telspDown(1)



ssg5000TrapLabelValue A trap variable object for providing the MPLS Label


alarmClear(2)



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:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000MPLSTELSPAlarmNotification(34)

SNMP MPLS RSVP-TE AlarmsThe detailed information of SER base SNMP MPLS RSVP-TE alarms is given in Table 9-125.

Table 9-125 SER Base SNMP MPLS RSVP-TE Alarms

Table 9-126 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-126SNMP MPLS RSVP-TE Alarm MIB Notification Object

Shasta Function

Alarm Severity

Alarm State

SCS Client Alarm Text Alarm Description

MPLS RSVP-TE

INFO alarmOccur MPLS RSVP-TE Session down

MPLS RSVP-TE Session is down

INFO alarmClear MPLS RSVP-TE Session down

MPLS RSVP-TE Session is up

MIB Variable Values

ssg5000TrapRSVPTEAlarmId rsvpteSessionDown(1)





alarmClear(2)


411-5221-926 Standard 10.07 June 2006

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 AlarmsThe detailed information of SER base SNMP MPLS ISP Interface alarms is given in Table 9-129.

Table 9-127 SER Base SNMP MPLS ISP Interface Alarms\

Table 9-128 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-128SNMP MPLS ISP Interface Alarm MIB Notification Object



major(2)

minor(4)

info(8)

Shasta Function

Alarm Severity

Alarm State


Alarm Description

MPLS ISP Interface

INFO alarmOccur MPLS ISP Interface Session down

MPLS ISP Interface Session is down

INFO alarmClear MPLS ISP Interface Session down

MPLS ISP Interface Session is up

MIB Variable Values

ssg5000TrapMPLSINTFAlarmId mplsinterfaceDown(1)



MIB Variable Values



Below is an OID for the SER base MPLS ISP Interface alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000MPLSINTFAlarmNotification(37)

SNMP MP-BGP AlarmsThe detailed information of SER base SNMP MP-BGP alarms is given in Table 9-129.

Table 9-129 SER Base SNMP MP-BGP Alarms

Table 9-130 defines the SER base SNMP MP-BGP alarms MIB object. The notification signals that the SNMP agent detects an alarm status for MP-BGP.

Table 9-130SNMP MP-BGP MIB Notification Object


alarmClear(2)



major(2)

minor(4)

info(8)

Shasta Function

Alarm Severity

Alarm State


Alarm Description

BGP PEER

INFO alarmOccur BGP Peer Down BGP Peer is down

INFO alarmClear BGP Peer Down BGP Peer is up

MIB Variable Values

ssg5000TrapBGPAlarmId bgpPeerDown(1)



MIB Variable Values


411-5221-926 Standard 10.07 June 2006

Below is an OID for the SER base MP-BGP alarm notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SER Experiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(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-131 SER Base SNMP IKE Tunnel Start Event

Table 9-132 defines the SER base SNMP IKE Tunnel Start Event MIB object.


alarmClear(2)



major(2)

minor(4)

info(8)

Shasta Function

Event Severity


IKE INFO IKE tunnel starts successfully with local 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>.

The notification signals the start of IKE tunnel phase 1.

MIB Variable Values



Table 9-132SNMP IKE Tunnel Start Event MIB Notification Object

Below is an OID for the SER base IKE Event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000IKETunnelStartNotification(48)

Table 9-133 SER Base SNMP IKE Tunnel Stop Event

MIB Variable Values

ssg5000TrapIKETunnelStartAlarmId

The Start Alarm ID.

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

ssg5000TrapIKETunnelLifeTime Lifetime value of the IKE tunnel.

ssg5000TrapSSGHostAddress The address of the GGSN.

ssg5000TrapTrapSeverity critical(1)

major (2)

minor(4)

info(8)

Shasta Function

Event Severity


IKE INFO IKE tunnel stops with local 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>.

The notification signals the end of IKE tunnel phase 1.


411-5221-926 Standard 10.07 June 2006

Table 9-134 defines the SER base SNMP IKE Tunnel Stop Event MIB object.

Table 9-134SNMP IKE Tunnel Stop Event MIB Notification Object


iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000IKETunnelStopNotification(49)

MIB Variable Values

ssg5000TrapIKETunnelStopAlarmId

The Stop Alarm ID.






ssg5000TrapIKETunnelLifeTime Lifetime value of the IKE tunnel.



major (2)

minor(4)

info(8)



Table 9-135 SER Base SNMP IKE Tunnel Not Established Event

Table 9-136 defines the SER base SNMP IKE Tunnel Not Established Event MIB object.

Table 9-136SNMP IKE Tunnel Not Established Event MIB Notification Object


Shasta Function

Event Severity


IKE INFO IKE tunnel is not correctly established with local address <ip_address>, remote address <ip_address>, tunnel name <tunnel_name> and cause code <cause_code_number>.

The notification signals that phase 1 was not established for the IKE tunnel.

MIB Variable Values

ssg5000TrapIKETunnelNotEstablishedAlarmId

The IKE Not Established Alarm ID.








major (2)

minor(4)

info(8)


411-5221-926 Standard 10.07 June 2006

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000IKETunnelNotEstablishedNotification(50)

Table 9-137 SER Base SNMP IKE SA Peer Dead Event

SNMP IPSEC Events The detailed information of SER base SNMP IPSEC Events is given in the following tables.

Table 9-138 SER Base SNMP IPSEC Tunnel Start Event

Table 9-139 defines the SER base SNMP IPSEC Tunnel Start Event MIB object.

Shasta Function

Event Severity


IKE INFO IKE SA Peer Dead (<missed event number> missed events)

The notification signals that SA Peer was not established for the IKE tunnel.

Shasta Function

Event Severity


IPSEC INFO IPsec tunnel starts successfully with interface name <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>.

The notification signals the start of IPSEC tunnel phase 2.



Table 9-139SNMP IPSEC Tunnel Start Event MIB Notification Object

Below is an OID for the SER base IPSEC Event notification object:

iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000IPSECTunnelStartNotification(51)

Table 9-140 SER Base SNMP IPSEC Tunnel Stop Event

MIB Variable Values

ssg5000TrapIPSECTunnelStartAlarmId

The Start Alarm ID.

ssg5000TrapIPSECInterfaceName

The name provisioned on the GGSN for this interface.

ssg5000TrapIPSECTunnelName The name provisioned on the GGSN for this tunnel.

ssg5000TrapSubscriberName Subscriber name

ssg5000TrapIPSECTunnelLifeTime

The IPSEC tunnel life time value.

ssg5000TrapIPSECTunnelLifeSize

The IPSEC tunnel life size value.

ssg5000TrapSSGHostAddress The IP address of the GGSN.


major (2)

minor(4)

info(8)

Shasta Function

Event Severity


IPSEC INFO IPsec tunnel stops with interface name <interface_name>, tunnel name <tunnel_name>, subscriber name <sub_name> and cause code <cause_code_value>.

The notification signals the end of IPSEC tunnel phase 2.


411-5221-926 Standard 10.07 June 2006

Table 9-141 defines the SER base SNMP IPSEC Tunnel Stop Event MIB object.

Table 9-141SNMP IPSEC Tunnel Stop Event MIB Notification Object


iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000IPSECTunnelStopNotification(52)

Table 9-142 SER Base SNMP IPSEC Tunnel Not Established Event

Table 9-143 defines the SER base SNMP IPSEC Tunnel Not Established Event MIB object.

MIB Variable Values

ssg5000TrapIPSECTunnelStopAlarmId

The Stop Alarm ID.

ssg5000TrapIPSECInterfaceName

The name provisioned on the GGSN for this interface.

ssg5000TrapIPSECTunnelName The name provisioned on the GGSN for this tunnel.

ssg5000TrapSubscriberName Subscriber name



major (2)

minor(4)

info(8)

Shasta Function

Event Severity


IPSEC INFO IPsec tunnel is not correctly established with local address <ip_addr>, remote address <ip_addr>, tunnel name <tunnel_name> and cause code <cause_code_value>.

The notification signals that phase 2 was not established for the IPSEC tunnel.



Table 9-143SNMP IPSEC Tunnel Not Established Event MIB Notification Object


iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).SER(3199).SERExperiment(10).ssg5000ChasisMIB(28).ssg5000MIBNotificationPrefix(2).ssgMIBNotification(0).ssg5000IPSECTunnelNotEstablishedNotification(53)

SNMP TrapsSNMP Authentication Failure AlarmThe detailed information of SNMP Authentication Failure Alarm is given in Table 184, “SNMP Authentication Failure Alarm”.

Table 9-144 SER Base SNMP Authentication Failure Alarm

Below is an OID for the SNMP Authentication Failure notification object:

MIB Variable Values

ssg5000TrapIPSECTunnelNotEstablishedAlarmId

The IPSEC Not Established Alarm ID.



ssg5000TrapIPSECTunnelName The name provisioned on the GGSN for this tunnel



major (2)

minor(4)

info(8)

Shasta Function

Alarm Severity

Alarm State


Alarm Description

Authentication Failure

MINOR alarmOccur Authentication Failure The indicated Nortel GGSN has received an unauthenticated SNMP request.


411-5221-926 Standard 10.07 June 2006

iso(1).org(3).dod(6).internet(1).snmpV2(6).snmpModules(3).snmpMIB(1).snmpMIBObjects(1).snmpTraps(5).authenticationFailure(5).

Event Logs 9The 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-10. 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-10 Nortel GGSN Event Management

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.

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 LogsGTP Tunnel Event LogsThe event logs related to GTP tunnel are detailed in Table 9-145

Event Manager

Device Console

log files

SYSLOG Server

FunctionalModule

Nortel GGSNEvent Logs

ASCI

I syslogSNMPAgent

(Event Number,Log Type,

Event Text)Trap Flag,


411-5221-926 Standard 10.07 June 2006

Table 9-145 GTP Tunnel Event Logs

Event Number

SysLog Event Severity

Disk & Console Log Event Severity

Event Text Event Description

1 INFO INFO GTP Tunnel on ISP ispName Context Creation Disabled

GTP Tunnel creation has been disabled for the GGSN.

2 CLEAR CLEAR GTP Tunnel on ISP ispName Context Creation Disabled

GTP Tunnel creation was Disabled, now Enabled

3 INFO INFO APN apnName on ISP ispName Disabled

An APN is administratively Disabled for the GGSN (will not accept new context creation).

4 CLEAR CLEAR APN apnName on ISP ispName Disabled

An APN that was Disabled is now Enabled.

5 MINOR MINOR APN apnName (ISP ispName): APN session limit exceeded (Limit: apnLimit)

Configured session limit has been exceeded for the APN & ISP specified.

6 CLEAR CLEAR APN apnName (ISP ispName): APN session limit exceeded (Limit: apnLimit)

The number of active sessions using the APN & ISP specified has dropped below the configured limit for that APN.

7 MINOR MINOR <gtp> has dropped <total number> of create request due to <total number> of pending subscriber requests.

This event is generated when the system overload is detected.

8 MINOR MINOR <gtp> APN: <apn name> Session Mode enabled, but no wrapmgr is provisioned.

The APN profile associated with the call has its Session Mode flag set while its application server profile field remains blank.



9 MINOR MINOR <gtp> APN: <apn name> Session Mode enabled and no response from the Application Server: <application server profile name>.

For each wireless application call in session mode, GGSN sets a timer for the application server response. This event is generated upon the expiry of the timer.

10 MINOR MINOR <gtp> APN: <apn name> Session Mode enabled and the WAP session could not be established on Application Server: <application server profile name>.

The WAP session can’t be established because of an invalid response (such as incorrect authenticator value) received from the application server or insufficient internal resource available.

11 MINOR MINOR <gtp> VPN Name: <vpn_name> invalid for APN: <apn>, Subscribe: <subscriber_name> on RADIUS Server: <radius_server_name> <gtp>.

An invalid VPRN name was returned, i.e. the VPRN name is not provisioned within the VPRN Manager

12 MINOR MINOR <gtp> Service Profile: <service_profile> invalid for APN: <apn>, Subscribe: <subscriber_name> on RADIUS Server: <radius_server_name><gtp>

An invalid Service Profile was returned, i.e. the Service Profile was not configured within the Service Policy Manager

13 MINOR MINOR <gtp> Resource Overload - LOM returned Invalid error code for <err> request.

TBD

14 MINOR MINOR <gtp> Aggregation session rejected because Single-APN VSAs returned from Radius. APN: <apn>, MSISDN: <msisdn>, EUA: <eua>

A single APN VPN VSA was returned from RADIUS Server. This functionality is not supported on Aggregation sessions.

Event Number





411-5221-926 Standard 10.07 June 2006

15 MINOR MINOR <gtp> Aggregation session rejected because subnet dedication was not possible.APN:<apn>, MSISDN: <msisdn>, EUA: <eua>

Aggregation Session rejected due to unavailability of subnet dedication

16 MINOR MINOR <gtp> Aggregation session rejected because it would require sub-specific route advertisement. APN: <apn>, MSISDN: <msisdn>, EUA: <eua>

Aggregation session was rejected due to requirement of individual route advertisement.

17 MINOR MINOR <gtp> Aggregation session rejected because APN is configured with non-aggregation features. APN: <apn>, MSISDN: <msisdn>, EUA: <eua>, Features: <string>

Aggregation session was rejected due to feature set provisioned on an aggregation APN.

18 MINOR MINOR <gtp> Aggregation session rejected because a static IP address appeared in the create request. APN: <apn>, MSISDN: <msisdn>, EUA: <eua>

A static IP address was received in the CREATE PDP CONTEXT REQUEST message.

19 MINOR MINOR <gtp> Aggregation session rejected because of transient SSP failure effect (subnet join failed). APN: <apn>, MSISDN: <msisdn>, EUA: <eua>

Aggregation session was rejected due to failure in subnet programming

20 MINOR MINOR <gtp> Aggregation session rejected/deleted because QoS IE required IP services. APN: <apn>, MSISDN: <msisdn>, EUA: <eua>, Operation: <string>

Aggregation session was rejected because of feature set assigned to QoS level.

21 MAJOR MAJOR <gtp> Hash table Memory: <hash_index> PDPTypeNumber: <pdpd_type>

TBD

Event Number






22 MINOR MINOR No Dynamic L2TP VPN Tunnel Attributes returned for APN:%s Subscriber:%s on Radius Server:%s

The Subscriber was set to use a Dynamic L2TP VPN, but no tunnel attributes were returned from the radius server.

23 MINOR MINOR WARNING: Invalid Tariff Profile <profile_name> for MSISDN <msisdn_name>

Invalid Tariff Profile

24 MINOR MINOR WARNING: Access Control Profile rejection for MSISDN <msisdn> IMSI <imsi> on APN <apn> on ISP <isp> Operation <Access Control Profile Rejection>

Access Control Profile rejection

25 INFO INFO Access Control Profile <profile> is associated with APN <apn> on ISP <isp>

The Access Control Profile is associated with the APN

26 INFO INFO Access Control Profile <profile> is dissociated with APN <apn> on ISP <isp>

The Access Control Profile is disassociated with the APN

27 MAJOR MAJOR <gtp> Software error: <error_title> (<error test string>: <error_code>)

Software error is detected in GTP subsystem

28 CRITICAL CRITICAL <gtp subsystem> <error text string>

A potentially service affecting error has occurred in GTP software subsystem.

29 MAJOR MAJOR < EchoReqTimerCallback > : (Missed N3 Echo Responses from SGSN <SGSN ID>).

The GGSN is removing sessions as a result of echo responses not being received from an SGSN.

Event Number





411-5221-926 Standard 10.07 June 2006

32 INFO INFO <gtp> SSM Redundancy Processing Started at <Date+time>: Moving <Aggregation/non-Aggregation> sessions from failed SSM.

This log is generated as SSM redundancy starts for Aggregation and non-Aggregation APNs.

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.

33 INFO INFO <gtp> SSM Redundancy Processing Completed at <Date+time>: <Aggregation/non-Aggregation> Sessions moved from failed SSM.

This event log is generated as the SSM redundancy is completed for <Aggregation/non-Aggregation> APNs.

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 Processing Started at <Date+time>: Moving <non-Aggregation> sessions to the original SSM

This log is generated as the SSM redundancy starts during recovery of a failed SSM. It is generated only for the non-Aggregation APNs as the sessions are moved to the original SSM.

Event Number






GTP Accounting Event LogsThe event logs related to GTP accounting are detailed in Table 9-146

Table 9-146 GTP Accounting Event Logs

35 INFO INFO <gtp> SSM Redundancy Processing Completed at <Date+time>: non-Aggregation Sessions moved to the original SSM.

This event log is generated as the SSM redundancy is completed for the recovered SSM. It is generated only for the non-Aggregation APNs.

36 INFO INFO SSM Redundancy for Aggregation is <Enabled/Disabled>.

This event log is generated as SSM Redundancy for Aggregation is enabled or disabled from SCS.

37 MAJOR MAJOR APN <apn-name> on ISP <isp-name> has crossed the threshold value <Threshold Value> and has been blacklisted.

The number of consecutive PDP context failures have raised at or above the threshold value for the APN.

38 CLEAR CLEAR APN <apn-name> on ISP <isp-name> has crossed the threshold value <Threshold Value> and has been blacklisted.

The APN is back-in service after the configured blackout period expires.

39 INFO INFO Failed to apply dynamic charging rules for MSISDN <msisdn> NSAPI <nsapi> on APN <apn> on ISP <isp>

Failed to apply dynamic charging rules for a context. This event log is throttled to prevent excessive logs being generated, 10 event logs per minute.

Event Number




5 MINOR MINOR CGF cgfServerName on ISP ispName FAILED

CGF Failed for the specified CGF server and ISP.

Event Number





411-5221-926 Standard 10.07 June 2006

6 CLEAR CLEAR CGF cgfServerName on ISP ispName FAILED

CGF restored for the specified CGF server and ISP.

7 CRITICAL CRITICAL NO CGF AVAILABLE on ISP ispName

CGFs configured on the Gn ISP are not responding.

8 CLEAR CLEAR NO CGF AVAILABLE on ISP ispName

CGF configured on the Gn ISP are responding.

9 INFO INFO CGF <cgfid> on ISP <ispid> ALIVE

CGF is ALIVE

10 MINOR MINOR CGF <cgfid> on ISP <ispid> OFFLINE

CGF is going OFFLINE

11 INFO INFO CGF <cgfid> on ISP ispName is SWACTED

Switch of activity occurred for primary and secondary CGFs.

12 INFO INFO GCDR Auditing enabled on ISP <ispid>

G-CDR Auditing enabled

13 INFO INFO GCDR Auditing disabled on ISP <ispid>

G-CDR Auditing disabled

14 INFO INFO FTP enabled on ISP <ispid>

FTP for G-CDR auditing enabled

15 INFO INFO FTP disabled on ISP <ispid>

FTP for G-CDR auditing disabled

16 CRITICAL CRITICAL <gtp_acct subsystem> <error text string>

A potentially service affecting error has occurred in GTP-accounting software subsystem.

17 MINOR MINOR <gtp_acct subsystem> <warning text string>

A recoverable but unexpected event has occurred in GTP-accounting software subsystem.

18 INFO INFO G-CDR transfer initiated <Transfer Mode = “Transfer Mode”>

Indicates that the GCDR transfer was initiated.

Transfer Mode indicates if the transfer was initiated by the CLI command or by the SCS configuration

Event Number






FTP Service Event LogsThe event logs related to FTP service are detailed in Table 9-147

Table 9-147 FTP Service Event Logs

RADIUS Accounting Event LogsThe event logs related to RADIUS accounting are detailed in Table 9-148

19 INFO INFO G-CDR transfer stopped <Transfer Mode = “Transfer Mode”> <Reason = “Reason”>

Indicates that the GCDR transfer was stopped.

Transfer Mode indicates if the transfer was stopped by the CLI command or by the SCS configuration

Reason indicates the reason why it was stopped

Event Number




1 MINOR MINOR Unable to connect to FTP server ftpServerName on isp ispName

One FTP server used for G-CDR auditing is down.

2 CLEAR CLEAR Unable to connect to GTPP audit FTP server ftpServerName on ISP ispName

An FTP server used for G-CDR auditing is reachable.

3 CRITICAL CRITICAL All of the provisioned FTP servers are down, audit files will remain on disk on isp ispName

All FTP servers used for G-CDR auditing are down.

4 CLEAR CLEAR All GTPP audit FTP servers are down on ISP ispName

An FTP Server used for G-CDR auditing is up.

Event Number





411-5221-926 Standard 10.07 June 2006

Table 9-148 RADIUS Accounting Event Logs

Event Number


Disk & Console log Event Severity


13 CRITICAL

CRITICAL

RADIUS error writing records to disk.

Error occurred when writing RADIUS accounting record to disk.

14 CLEAR CLEAR RADIUS error writing records to disk.

Disk error resolved for RADIUS.

15 MAJOR MAJOR ISP <isp> RADIUS Profile <profile> Cannot contact RADIUS server. Writing to disk.

Could not contact any RADIUS server for the specified RADIUS profile.

16 CLEAR CLEAR ISP ispName RADIUS Profile radiusProfileName Cannot contact RADIUS Server. Writing to disk.

Able to contact a RADIUS server for the specified RADIUS profile.

17 CRITICAL

CRITICAL

ISP ispName APN apnName no RADIUS profile.

RADIUS profile not configured for the ISP and APN and RADIUS Accounting option is chosen.

18 CRITICAL

CRITICAL

ISP ispName RADIUS Profile radiusProfileName APN apnName no RADIUS server.

No Accounting server provisioned and RADIUS Accounting option is chosen.

19 CRITICAL

CRITICAL

ISP ispName RADIUS Profile radiusProfileName APN apnName no primary RADIUS Server Present.

No Primary Accounting Server specified and RADIUS Accounting Option is chosen.

20 CRITICAL

CRITICAL

RADIUS Accounting could not generate record due to lack of memory.

Memory shortage while generating a Accounting message.

21 MINOR MINOR Acct-Off timed out for Radius server <server> in profile <profile>

GGSN couldn't get the response for RADIUS Acct OFF message after configured number of retries on the profile.



Prepaid Service Event LogsThe event logs related to Prepaid service are detailed in Table 9-149

Table 9-149 Prepaid Service Event Logs

22 MINOR MINOR Address Pool <pool name> deletion failed for ISP <isp name> (<error_string>)

There are some GTP sessions using the address pool that AAA Manager is 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 Profile <radius_profile> can Not contact RADIUS Authentication server

RADIUS Authentication server is unreachable

24 CLEAR CLEAR ISP <isp name> RADIUS Profile <radius_profile> can Not contact RADIUS Authentication server

RADIUS Authentication server is reachable

Event Number




1 CRITICAL

CRITICAL

NO SCP AVAILABLE on ISP ispName Tariff Profile tariffProfileName

SCP server(s) configured in the Tariff Profile on ISP is not reachable.

2 CLEAR CLEAR NO SCP AVAILABLE on ISP ispName Tariff Profile tariffProfileName

SCP server(s) is reachable.

3 MINOR MINOR Prepaid CTP invalid IE <Tariff Profile Name = “profile name”> <IE Name = “ie name”> <Field Name = “field name”> <Field Value = “value”>

One of the IEs in the CTP message was incorrectly formatted. Either it was not possible to decode, or an invalid value was included in one of the IE fields.

Event Number


Disk & Console log Event Severity



411-5221-926 Standard 10.07 June 2006

Disk Capacity Event LogsThe event logs related to Disk Capacity are detailed in Table 9-150.

Table 9-150 Disk Capacity Event Logs

Event Number




1 INFO INFO NORMAL: <disk name> is <occup>% full.

A Disk Capacity Normal event is 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.

2 MAJOR MAJOR WARNING: <devname> is <occup>% full.

A Disk Capacity Major event is generated when the 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 CRITICAL

CRITICAL

CRITICAL: <devname> is <occup>% full.

A Disk Capacity Critical event is generated when the disk space on the CMC card is 72% or more full.



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.

4 INFO INFO Writing to disk allowed. Disk spacefree=<free>K, reserved= <reserved>K total=<total>K,

This event is generated when the available disk space on the CMC card is more than the reserved disk space (for coredump plus the safety margin of other critical data).

5 CRITICAL

CRITICAL

Writing to disk stopped. Disk space total=<total>K, free=<free>K, reserved= <reserved>K

This event is generated when the available disk space on the CMC card is less than the reserved disk space (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.

Event Number





411-5221-926 Standard 10.07 June 2006

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 LogsThe event logs related to WAP service are detailed in Table 9-151

Table 9-151 WAP Service Event Logs

Lawful Interception Event LogsThe event logs related to Lawful Interception are detailed in Table 9-152

Event Number




1 CRITICAL

CRITICAL

Application Server appServerName on ISP ispName no response within threshold

Application server is not responding to Accounting START/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 appServerName on ISP ispName no response within threshold

Application server responding again.

3 CRITICAL

CRITICAL

Application Server appServerName on ISP ispName failed to activate

Application server does not respond to Accounting ON/OFF requests.

4 CLEAR CLEAR Application Server appServerName on ISP ispName failed to activate

Application server responding to accounting requests.



Table 9-152 LI Event Logs

Overload Control Event LogsThe event logs related to Overload Control are detailed in Table 9-153 and Table 9-154.

Table 9-153 Overload LOM Event Logs

Event Number




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

TCP connection to DF(s) is down.

4 CLEAR CLEAR DF Links Down: numDfLinksDown

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

Event Number

Log Type Disk & Console Log Event Severity


1 INFORMATION

INFORMATION

RM OVLD Node-<node> Level-<level> with occupancy <%>

This event is generated when an overload transition occurs for CPU Total resource.

2 MINOR MINOR RM OVLD Node-<node> Level-<level> with occupancy <%>



411-5221-926 Standard 10.07 June 2006

3 MAJOR MAJOR RM OVLD Node-<node> Level-<level> with occupancy <%>


4 CRITICAL CRITICAL RM OVLD Node-<node> Level-<level> with occupancy <%>


5 INFORMATION

INFORMATION

RM OVLD INTERRUPT Node-<node> Level-<level> with occupancy <%>

This event is generated when an overload transition occurs for CPU Interrupt resource.

6 MINOR MINOR RM OVLD INTERRUPT Node-<node> Level-<level> with occupancy <%>


7 MAJOR MAJOR RM OVLD INTERRUPT Node-<node> Level-<level> with occupancy <%>


8 CRITICAL CRITICAL RM OVLD INTERRUPT Node-<node> Level-<level> with occupancy <%>


9 INFORMATION

INFORMATION

RM OVLD MEMORY Node-<node> Level-<level> with <num> MB free memory and with fragmentation better than <num> KB

This event is generated when a memory overload transition occurs for a given CPU.

10 MINOR MINOR RM OVLD MEMORY Node-<node> Level-<level> with <num> MB free memory and with fragmentation better than <num> KB


Event Number





Table 9-154 Overload COM Event Logs

ISP Manager Event LogsThe event logs related to ISP manager are detailed in Table 9-155.

Table 9-155 ISP Manager Event Logs

11 MAJOR MAJOR RM OVLD MEMORY Node-<node> Level-<level> with <num> MB free memory and with fragmentation better than <num> KB


12 CRITICAL CRITICAL RM OVLD MEMORY Node-<node> Level-<level> with <num> MB free memory and with fragmentation better than <num> KB


Event Number



1 INFORMATION

INFORMATION

Overload: Notifications for application <application> have been <status>.

This event is used to report the status of registered applications.

Event Number




8 CRITICAL CRITICAL ISP ispName Down ISP operational state is down. No traffic can be sent from Gn->Gi for this ISP

9 CLEAR CLEAR ISP ispName Down ISP operational state was Down, is now UP.

Event Number




411-5221-926 Standard 10.07 June 2006

Log Throttler Event LogsA 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 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:

10 CRITICAL CRITICAL Add ISP ispName failed

Attempt to add an ISP failed. ISP was not created.

11 MAJOR MAJOR Address Pool <pool_name> activation failed for isp <Isp Name> (<error string>)

An address pool activation failed alarm is generated when routing code fails to add summary route to the pool. This is very unlikely scenario

12 INFORMATION

INFORMATION

<isp> TPO Configuration mismatch: Missing TPO ISP configuration

Packets are to be sent to the TPO but the TPO ISP is not configured

Event Number






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

Table 9-156 Log Throttler Event Logs

Memory Trampler Detection Event LogsThe 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.

Event Number




9 MINOR MINOR <dbgmgr> Application Logs Throttled <report of throttled logs>

Print out a report of number of error/warning logs throttled per subsystem for GTP and GTPP.

10 MAJOR MAJOR <dbgmgr> <Throttler error string>

An unexpected error occurred in throttling subsystem.


411-5221-926 Standard 10.07 June 2006

Table 9-157 Memory Trampler Detection Event Logs

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 LogsThe event logs related to the Memory Audit are detailed in Table 9-158

Table 9-158 Memory Audit Event Logs

Event Number




7 CRITICAL CRITICAL <iSOS> Memory trampling detected in task <taskname> tid: <task-id>

<stack-trace>

Prints out details of the task where memory trampling was detected, along with a stack-trace. This log 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.

Event Number




1 INFORMATION

INFORMATION

Memory Leak detected. Mod:%d Instance:%d memory type:%d count:%d

This event is generated when a memory leak has been detected.

2 INFORMATION

INFORMATION

Audit running too long. task name:%s start_time=%02d:%02d:%02d.

This event is generated when an audit has been running too long.



Patching Event LogsThis section describes event logs that are related to patching.

Table 9-159Patching Event Log

Event Number



Event Description

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 MAJOR MINOR Download failure (to device)

5 INFO INFO Patch applied

6 INFO INFO Unapplied Patch

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

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


411-5221-926 Standard 10.07 June 2006

OK to apply profileOK 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.

Example:

Mon 09-Dec-2002 12:46:16 13/1/1:Patchmgr 0 1 1 INFO OK to apply profile MyProfile.

Action:

No action required.

Attempt to verify an already active profileAn attempt to verify a profile which is already the active profile is an invalid operation.

Example:

Mon 09-Dec-2002 12:46:16 13/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 ProfileWhen there is insufficient memory to apply the profile, this log is generated.

Example:

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

Event Number



Event Description



Mon 09-Dec-2002 12:46:16 13/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:

Mon 09-Dec-2002 12:46:16 13/1/1:Patchmgr 0 1 1 WARNING There was a failure when downloading patch Q000532212.

Action:

Perform a patch sync.

Patch AppliedThis is an informational log that records a patch has been successfully applied.

Example:

Mon 09-Dec-2002 12:46:16 13/1/1:Patcher 0 1 1 INFO Applied patchid Q000532212.

Action:

No action required.

Patch ActivatedThis is an informational log that records a patch has been successfully activated.

Example:

Mon 09-Dec-2002 12:46:15 13/1/1:Patcher 0 3 1 INFO Activated patchid Q000532213.

Action:

No action required.


411-5221-926 Standard 10.07 June 2006

Patch DeactivatedThis is an informational log that records a patch has been successfully deactivated.

Example:

Mon 09-Dec-2002 12:46:15 13/1/1:Patcher 0 4 1 INFO Deactivated patchid Q000532213.

Action:

No action required.

Prerequisite Check FailureA prerequisite failure log is generated when a patch is applied out of order.

Example:

Mon 09-Dec-2002 14:11:06 13/1/1:Patcher 0 5 1 INFO Prerequisite check failed when trying to unapply patch Q000532213.

Action:


Mutual Exclusion Check FailureA mutual exclusion failure log may be generated when the SCS and SSG are out of sync.

Example:

Mon 09-Dec-2002 14:10:59 13/1/1:Patcher 0 6 1 INFO Mutual exclusion check failed when trying to apply patch Q000532213.

Action:


Applying a patch which is already applied.This log informs the user that a patch they attempted to apply was already applied.

Example:

Mon 09-Dec-2002 13:38:58 13/1/1:Patcher 0 7 1 INFO Attempted to apply patch Q000532213, 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:

Mon 09-Dec-2002 13:38:58 13/1/1:Patcher 0 8 1 INFO Attempted to unapply patch Q000532213, but it was already unapplied.

Action:

No action required.

Failed to load patchThis log implies that the patch may be corrupt, or the patching software could not properly decode it.

Example:

Mon 09-Dec-2002 13:38:58 13/1/1:Patcher 0 9 1 INFO Failed to load patch Q000532213.

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.

Example:

Mon 09-Dec-2002 13:38:58 13/1/1:Patcher 0 10 1 INFO Internal error. Max jump distance exceeded when attempting to apply patch Q000532213.

Action:

Report the log to Nortel Support.

Patch does not exist.This log is generated when an operation is performed on an unknown patch.


411-5221-926 Standard 10.07 June 2006

Example:

Mon 09-Dec-2002 13:38:58 13/1/1:Patcher 0 11 1 INFO Patch Q000532213 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:

Mon 09-Dec-2002 13:38:58 13/1/1:Patcher 0 12 1 WARNING 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:

Mon 09-Dec-2002 13:38:58 13/1/1:Patcher 0 13 1 WARNING 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:

Mon 09-Dec-2002 13:04:15 13/1/1:Patcher 0 14 1 INFO Failed to apply patch Q000532212 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:

Mon 09-Dec-2002 13:04:15 13/1/1:Patcher 0 15 1 WARNING Possible corrupt patch file for patchID Q000532212.

Action:

Remove the patch from the profile. Add the patch back into the profile.

Patch operation blockedThe patching software was too busy to handle the requested operation.

Example:

Mon 09-Dec-2002 12:46:11 13/1/1:Patcher 0 16 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:

Mon 09-Dec-2002 12:46:24 13/1/1:Patcher 0 17 1 INFO Failed to download patch file to target.

Action:


Patch UnappliedThis is an informational log that records a patch has been successfully unapplied.

Example:

Mon 09-Dec-2002 12:46:15 13/1/1:Patcher 0 18 1 INFO Unapplied patchid Q000532212.


411-5221-926 Standard 10.07 June 2006

Action:

No action required.

SOC Event LogsThis section describes event logs that are related to Software Optionality Control (SOC).

Table 9-160 SOC Event Logs

Diameter Credit Control (DCC) Event LogsTable 9-161 Diameter Credit Control Event Logs

Event Number




1 INFO INFO <featureName> is Enabled The specified feature has been enabled.

2 INFO INFO <featureName> is Disabled

The specified feature has been disabled.

3 INFO INFO Unknown string: <socString>

An attempt was made to enable/disable SOC controlled functionality with an invalid string.

Event Number

Log Type Event Text Event Description

1 CRITICAL NO ONLINE DIAMETER SERVER AVAILABLE on Diameter Profile <profileName> on ISP <ispName>

No Diameter server(s) configured in the Diameter Profile on ISP is reachable.

2 CLEAR NO ONLINE DIAMETER SERVER AVAILABLE on Diameter Profile <profileName> on ISP <ispName>

At least one Diameter server is now reachable or all Diameter servers are offline.

3 MINOR ONLINE DIAMETER SERVER at <serverIpAddress> on Diameter Profile <profileName> on ISP <ispName> is unreachable

Diameter server at address configured on Diameter Profile on ISP is not reachable.



Health Check Monitor Event LogsThe event logs related to the Health Check Monitor are detailed in Table 9-162

4 CLEAR ONLINE DIAMETER SERVER at <serverIpAddress> on Diameter Profile <profileName> on ISP <ispName> is unreachable

Diameter server is now reachable or has been put in an offline state.

5 MINOR ACTIVE DIAMETER SERVER ON DIAMETER PROFILE <profileName> SWITCHED FROM <serverIpAddr> TO <serverIpAddr> REASON <reasonString>

The currently active server has been changed. The reasonString identifies the cause, e.g. manual cation, server unreachable, etc.

6 INFO PROTOCOL ERROR <returnCodeValue> RECEIVED ON DIAMETER PROFILE <profileName> FROM Server at <serverIpAddr>

A protocol error has been detected and received from a server.

7 INFO UNRECOGNIZED RATE ID <categoryId> RECEIVED from DCC SERVER <serverIpAddr> for MSISDN <msisdn>, POLICY <profileName>, ISP <ispName>.

Diameter Peer received an Unrecognized Rate ID from GGSN.

8 MAJOR Tx TIMER EXPIRATIONS OF COUNT <TxExpiryCount> EXCEEDED MAJOR THRESHOLD ON DIAMETER PROFILE <profileName> AT DIAMETER SERVER <serverIpAddr>.

By the end of the Tx Timer Event Interval, the number of Tx Expiries was at least equal to the major threshold but less than the critical threshold.

9 CRITICAL Tx TIMER EXPIRATIONS OF COUNT <TxExpiryCount> EXCEEDED CRITICAL THRESHOLD ON DIAMETER PROFILE <profileName> AT DIAMETER SERVER <serverIpAddr>.

By the end of the Tx Timer Event Interval, the number of Tx Expiries was at least equal to the critical threshold.

Event Number



411-5221-926 Standard 10.07 June 2006

Table 9-162 Health Check Monitor Event Logs

Event Number SysLog

Event Severity



1 CRITICAL

CRITICAL

Nodal Activation Success rate of <Success Rate> has crossed the Threshold Value of <Threshold Value> Counter Log = <counter_log>

The Nodal Activation Success Rate of PDP Create requests, has dropped below the Nodal Success Rate threshold value.

2 CLEAR CLEAR Nodal Activation Success rate of <Success Rate> has crossed the Threshold Value of <Threshold Value> Counter Log = <counter_log>

The Nodal Activation Success Rate of PDP Create requests, has reached at or above the threshold value.

3 CRITICAL

CRITICAL

Network Activation Success rate of <Success Rate> has crossed the Threshold Value of <Threshold Value> Counter Log = <counter_log>

The Network Activation Success Rate of PDP Create requests, has dropped below the Network Success Rate threshold value.

4 CLEAR CLEAR Network Activation Success rate of <Success Rate> has crossed the Threshold Value of <Threshold Value> Counter Log = <counter_log>

The Network Activation Success Rate of PDP Create requests, has reached at or above the threshold value.

5 INFO INFO Attempted Activations of <Number of AttemptedActivations> have crossed the Threshold Value <Threshold Value>

The Attempted PDP context Activations have dropped to or below the threshold value.



Content Filtering Service (CFS) Event LogsTable 9-163 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-163 Content Filtering Service (CFS) Event Logs

6 CLEAR CLEAR Attempted Activations of <Number of AttemptedActivations> have crossed the Threshold Value <Threshold Value>

The Attempted PDP context Activations have raised above the threshold value.

Event Number

Syslog Event Severity

Disk and Console Event Severity


1 MINOR MINOR Content Filter server at cfsServerIpAddress:cfsServerPort on profile cfsProfileName on ISP ispName VPN vpnName is unavailable

Server has transitioned out of the ESTABLISHED state. It will no longer be used.

2 CLEAR CLEAR Content Filter server at cfsServerIpAddress:cfsServerPort on profile cfsProfileName on ISP ispName VPN vpnName is unavailable

Server has transitioned into the ESTABLISHED state. It will now be used.

Event Number SysLog

Event Severity




411-5221-926 Standard 10.07 June 2006

SER Base Event LogsSystem Level Event LogsTable 9-164 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-164 System Level Event Logs

3 MAJOR MAJOR NO Content Filter server available on profile cfsProfileName on ISP ispName VPN vpnName

No Content Filter Servers are in the ESTABLISHED state for a given profile.

4 CLEAR CLEAR NO Content Filter server available on profile cfsProfileName on ISP ispName VPN vpnName

At least one Content Filter server has transitioned into the ESTABLISHED state.

Event Number



Event Text

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

Event Number






Card Level Event LogsTable 9-165 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-165Card Level Event Logs

13 MAJOR MAJOR Single fan has failed

14 CRITICAL CRITICAL Fan Tray is not installed

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

Event Number



Event Text

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>

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

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

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

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

Event Number



Event Text



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.

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.

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

ATM Line Card Event LogsTable 9-166 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-166 ATM Line Card Event Logs

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.

Event Number



Event Text

1 INFO INFO ALC slot <slot number> port <port number> is up

2 MAJOR MAJOR ALC slot <slot number> port <port number> is down

Event Number



Event Text



3 MINOR MINOR ALC slot <slot number> port <port number> looped back

4 MINOR MINOR ALC slot <slot number> port <port number> LOS

5 MINOR MINOR ALC slot <slot number> port <port number> LOF

6 MINOR MINOR ALC slot <slot number> port <port number> LAIS

7 MINOR MINOR ALC slot <slot number> port <port number> LRDI

8 MINOR MINOR ALC slot <slot number> port <port number> LOP

9 MINOR MINOR ALC slot <slot number> port <port number> PAIS

10 MINOR MINOR ALC slot <slot number> port <port number> PRDI

11 MINOR MINOR ALC slot <slot number> port <port 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

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

20 CLEAR CLEAR ALC slot <slot number> port <port number> LOS clear

21 CLEAR CLEAR ALC slot <slot number> port <port number> LOF clear

22 CLEAR CLEAR ALC slot <slot number> port <port number> LAIS clear

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

SSM Event LogsTable 9-167 lists the event logs generated by the SSM manager. It may be useful for troubleshooting if captured to device console or SYSLOG Server.

Table 9-167 SSM Event Logs

23 CLEAR CLEAR ALC slot <slot number> port <port number> LRDI clear

24 CLEAR CLEAR ALC slot <slot number> port <port number> LOP clear

25 CLEAR CLEAR ALC slot <slot number> port <port number> PAIS clear

26 CLEAR CLEAR ALC slot <slot number> port <port number> PRDI clear

27 CLEAR CLEAR ALC slot <slot number> port <port number> loss of delineation clear

28 INFO INFO ALC slot <slot> ICP <icp CAM <cam> is not FULL

Event Number



Event Text

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>

Event Number



Event Text



7 MAJOR MAJOR Erratic downloading SSM: <slot number>/<module number> <cpu_0_miss> <cpu_1_miss> <cpu_2_miss> <cpu_3_miss>

8 MAJOR MAJOR Did not reset SSM MISC/CTRL REG: 0x<reg address>

9 MAJOR MAJOR SSM <module number> in slot <slot number> is down

10 INFO INFO SSM <module number> in slot <slot number> started core dump

11 WARNING MAJOR Core Dump failed for SSM <module number> in slot <slot number> Error <error number>

12 INFO INFO SSM <module number> in slot <slot number> Successfully dumped core

13 INFO INFO SSM <module number> in slot <slot 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

17 MAJOR MAJOR SSM <module number> in slot <slot 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>

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

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

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>

Event Number



Event Text



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>

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>

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

RPC Event LogsTable 9-168 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 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 swicth 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.

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.

Event Number



Event Text



Table 9-168RPC Timeout Event Logs

AAA Manager Event LogsTable 9-169 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-169 AAA Manager Event Logs

Event Number



Event Text

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

Event Number



Event Text

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


411-5221-926 Standard 10.07 June 2006

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

29 INFORMATION

INFORMATION

Reserved IP Address Pool category has dropped to bellow <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>

30 INFORMATION

INFORMATION

Unreserved IP Address Pool category has dropped to bellow <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>

31 INFORMATION

INFORMATION

IP Address Pool name = <poolName> Activation_Deactivation State Change to <state> for address assignment in Access Group <sgroupName> in ISP <ispName>

Event Number



Event Text



IP Forwarding Table Manager Event LogsTable 9-170 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-170FIB Manager Event Logs

SNTP Event LogsTable 9-171 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.

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>

Event Number



Event Text

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>

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

Table 9-171SNTP Event Logs

Interface Manager Event LogsTable 9-172 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.

Table 9-172 Interface Manager Event Logs

Event Number



Event Text

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

Event Number



Event Text

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>



System Manager Event LogsTable 9-173 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-173 System Manager Event Logs

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>

Event Number



Event Text

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

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

Task Manager Event LogsTable 9-174 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-174 Task Manager Event Logs

Configuration Manager Event LogsTable 9-175 lists event logs generated by the Configuration Manager. Configuration logs for which the SYSLOG monitoring is recommended are indicative of configuration related failures. If such logs are seen, Nortel personnel should be notified.

Table 9-175 Configuration Manager Event Logs

Event Number



Event Text

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>

Event Number



Event Text

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



Subscriber Manager Event LogsTable 9-176 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-176 Subscriber Manager Event Logs

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>

20 INFO INFO Finished loading phase <phase> of config <config_name>

21 INFO INFO Unsupported config, Object ID= <objid>, <objname> is REJECTED

Event Number



Event Text

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

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

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

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.

Event Number



Event Text



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.

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>

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

PPP Event LogsTable 9-177 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.

Table 9-177 PPP Event Logs

27 MAJOR MAJOR Subscriber <subname> Move failed: <error_string>

28 MAJOR MAJOR Subscriber <subname>, <domain>, <ispname> Commit Failed: <error_string> IP ADDR: <ipaddr>

Event Number



Event Text

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.

Event Number



Event Text



CMC Redundancy Event LogsTable 9-178 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-178 indicates the CMC type of 2 or 3 for CMC2 or CMC3, respectively.

Table 9-178 CMC Redundancy Event Logs

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.

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

Event Number



Event Text

1 INFO INFO CMC<cmc_type> redundant The CMC is redundant.

2 MINOR MINOR CMC<cmc_type> not redundant : <reason>

The CMC is not redundant.

3 MAJOR MAJOR Standby CMC<cmc_type> not redundant : <reason>

The standby CMC is not redundant.

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

4 MINOR MINOR CMC<cmc_type> images are not the same. Active = <release number> , Standby = <release number>

The images on the active and standby CMCs are not the same.

5 INFO INFO CMC<cmc_type> configs are not the same. Active = <version number>, Standby = <version number>. Syncing configs

The configurations on the active and standby CMCs are not the same. The configurations are being synced.

6 MINOR MINOR Standby CMC<cmc_type> CPU memory (<memory size> MB) is less than active CMC<cmc_type> CPU memory (<memory size> MB).

The standby CMC CPU memory is less than the active CMC CPU memory.

7 CRITICAL CRITICAL CMC<cmc_type> Routing processor failed.

The CMC routing processor failed.

8 CRITICAL CRITICAL This CMC<cmc_type> is taking over as active.

The CMC is taking over as the active CMC.

9 CRITICAL CRITICAL No CMC currently active! Attempting to takeover.

None of the CMCs are active. The CMC is attempting to takeover as the active CMC.

10 INFO INFO Standby CMC reloaded by <module name> (how = <how>)

The standby CMC has been reloaded.

11 CLEAR CLEAR Standby CMC<cmc_type> in slot <slotid> serial port <portid> is up

The serial port of the standby CMC is up.

12 MINOR MINOR Standby CMC<cmc_type> in slot <slotid> serial port <portid> is down

The serial port of the standby CMC is down.

13 CLEAR CLEAR CMC<cmc_type> in slot <slotid> serial port <portid> is up

The serial port of the active CMC is up.

14 MINOR MINOR CMC<cmc_type> in slot <slotid> serial port <portid> is down

The serial port of the active CMC is down.

Event Number



Event Text



15 WARNING MINOR Standby CMC aborted because of mismatch: <reason>

The standby CMC aborted due to a mismatch with the active CMC. <reason> indicates the mismatch reason (e.g. card types are different)

16 INFO INFO Standby CMC config not redundant. CMC core dump will not be attempted.

An error occurred on the active CMC resulting in a core 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 by <module name> (how = <how>)

The standby CMC3 has been reloaded.

18 WARNING MINOR Standby CMC3 aborted because of mismatch: <reason>

The standby CMC3 aborted due to a mismatch with the active CMC. <reason> indicates the mismatch reason (e.g. card types are different)

19 INFO INFO CMC in slot <slotid> serial port <portid> configuration has changed.

The configuration of the CMC serial port has changed.

20 INFO INFO CMC3 in slot <slotid> serial port <portid> configuration has changed.

The configuration of the CMC3 serial port has changed.

21 WARNING MAJOR Active CMC has an invalid boot file1 <file>

The active CMC has an invalid boot file.

22 WARNING MINOR Standby CMC has an invalid boot file1 <file>

The standby CMC has an invalid boot file.

23 INFO INFO Active CMC has valid boot file1 <file>

The active CMC has a valid boot file.

24 INFO INFO Standby CMC has valid boot file1 <file>

The standby CMC has a valid boot file.

25 MAJOR MAJOR Standby CMC3 config not redundant. CMC3 core dump will not be attempted.

An error occurred on the active CMC3 resulting in a core dump. A core dump will not be attempted if the standby CMC3 config is not the same as the active CMC3.

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

User Manager Event LogsTable 9-179 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-179 User Manager Event Logs

IKE Event LogsTable 9-180 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.

26 INFO INFO Standby CMC CPU memory size has been saved on the Active CMC

The active CMC has received info of the standby CMC CPU memory size. This info is saved on the active CMC.

27 WARNING MINOR Standby CMC not responding. Attempting temporary card deletion to clear the problem.

The standby CMC is not responding. Attempting to delete the standby CMC card to clear the problem.

28 CRITICAL CRITICAL SFC Switch to slot <slot> started.

The SFC switch started.

29 CLEAR CLEAR SFC Switch to newly active card in slot <slot> complete.

The SFC switch completed.

Event Number



Event Text

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

Event Number



Event Text



Table 9-180 IKE Event Logs

Event Number



Event Text

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 event number> missed events]

5 INFO INFO IKE Session Timeout [<missed event number> missed events]

6 INFO INFO IKE Bad SA Signature [<missed event number> missed events]

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>, remote address <address>, subscriber name <name>, Sa Id <id number>, VPN Id <id number> and cause code <cc number>


411-5221-926 Standard 10.07 June 2006

VPN Event logsTable 9-181 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-181 VPN Event Logs

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>, remote 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>)”

Event Number



Event Text

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 event number> missed events]

3 INFO INFO Generic VPN event used for debug info [<missed event number> missed events]

Event Number



Event Text



Ethernet Line Card Event LogsTable 9-182 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-182 Ethernet Line Card Event Logs

L2TP Event LogsTable 9-183 lists event logs related to L2TP. The events recommended for SYSLOG monitoring may be indicative of problems with the remote LNS access.

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.

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>

Event Number



Event Text

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

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

Table 9-183 L2TP Event Logs

ISP Manager Event LogsTable 9-184 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-184 ISP Manager Event Logs

Event Number



Event Text

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>

Event Number



Event Text

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.

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



SCS Event LogsTable 9-185 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-185 SCS Event Logs

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>

Event Number



Event Text

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>

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>

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

MPLS Event LogsTable 9-186 lists event logs related to MPLS. The events recommended for SYSLOG monitoring may be indicative of problems with MPLS area.

Table 9-186 MPLS Event Logs

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.

Event Number



Event Text

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

Event Number



Event Text



OAM Event LogsThe event logs related to OAM Manager are detailed in Table 9-187.

Table 9-187 OAM Event Logs

SPS Event LogsTable 9-188 lists event logs related to SPS. The events recommended for SYSLOG monitoring may be indicative of problems with SPS manager.

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

Event Number



Event Text

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

Event Number



Event Text


411-5221-926 Standard 10.07 June 2006

Table 9-188 SPS Event Logs

LFIB Event LogsTable 9-189 lists event logs related to LFIB. The events recommended for SYSLOG monitoring may be indicative of problems with LFIB.

Table 9-189 LFIB Event Logs

IGMP Event LogsTable 9-190 lists event logs related to IGMP. The events recommended for SYSLOG monitoring may be indicative of problems with IGMP.

Table 9-190 IGMP Event Logs

IPHC Event LogsTable 9-191 lists event logs related to IP Health Check (IPHC). The events recommended for SYSLOG monitoring may be indicative of problems with registered IP addresses.

Event Number



Event Text

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>

Event Number



Event Text

1 CLEAR CLEAR E-LSP map <ELSPName> (isp_id <ispId>) added successfully

2 INFO INFO E-LSP map <ELSPName> (isp_id <ispId>) deleted successfully

Event Number



Event Text

1 INFO INFO Node <Node_number> reached max igmp join limit (<max_join_limit>)



Table 9-191 IPHC Event Logs

MPLS VRF Event LogsTable 9-192 lists event logs related to MPLS VRF. The events recommended for SYSLOG monitoring may be indicative of problems with MPLS VRF area.

Table 9-192 MPLS VRF Event Logs

PPPOE Event LogsTable 9-193 lists event logs related to PPPOE. The events recommended for SYSLOG monitoring may be indicative of problems with PPPOE sessions.

Table 9-193 PPPOE Event Logs

Event Number



Event Text

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>

Event Number



Event Text

1 CLEAR CLEAR VRF VPN <vfr_name> is ACTIVATED in ISP <ispname>

2 INFO INFO VRF VPN <vrf_name> is DEACTIVATED in ISP <ispname>

Event Number



Event Text

1 MAJOR MAJOR DOS ATTACH on conn <connid> tunl <tunilId>


411-5221-926 Standard 10.07 June 2006

System Monitor Event LogsTable 9-194 lists event logs related to System Monitor. The events recommended for SYSLOG monitoring may be indicative of problems with system resources.

Table 9-194 System Monitor Event Logs

Flow Management Event LogsThe event logs related to flow Management are detailed in Table 9-195

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>

Event Number



Event Text

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>

Event Number



Event Text



Table 9-195 Flow Management Event Logs

CLI Event LogsTable 9-196 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.

Table 9-196 CLI Event Logs

BGP Event LogsThe event logs related to BGP are detailed below:

Event Number



Event Text

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>

Event Number



Event Text

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


411-5221-926 Standard 10.07 June 2006

Table 9-197 BGP Event Logs

DHCP Event LogsThe event logs related to DHCP are detailed below:

Event Number




1 INFORMATIONAL

Notes:

severity = CLEAR

INFORMATIONAL

“CLEAR, Route Refresh Capable BGP Peer IP_Address (isp_id ISP_ID) is UP”

The BGP connection with the peer has come up. Both the local & remote nodes have advertised support for the route refresh capability.

2 INFORMATIONAL

Notes:

severity = CLEAR

INFORMATIONAL

“INFO, Route Refresh Capable BGP Peer IP_Address (isp_id ISP_ID) is DOWN”

BGP Peer down.

3 INFORMATIONAL

Notes:

severity = CLEAR

INFORMATIONAL

“CLEAR, ORF Capable BGP Peer IP_Address (isp_id ISP_ID) is UP”

The BGP connection with the peer has come up. Both the local & remote nodes have advertised support for the ORF capability.

4 INFORMATIONAL

Notes:

severity = CLEAR

INFORMATIONAL

“INFO, ORF Capable BGP Peer IP_Address (isp_id ISP_ID) is DOWN”

BGP Peer down



Table 9-198 DHCP Event Logs

GuardByte Event LogsThese 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 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.Mon 06-Mar-2006 03:17:03 11/4/1:DBG Manager 0 1 1 INFO DBGMSG_I: GuardBytes:0x27a0530: abababab abafabab *........*0x27a0540: abababab abababab abababab *............*

Mon 06-Mar-2006 03:17:03 11/4/1:DBG Manager 0 1 1 INFO DBGMSG_I: Likely culprit @ pClBuf=0x27a04b8, clPoolPtr=0xd79964.Mon 06-Mar-2006 03:17:03 11/4/1:DBG Manager 0 1 1 INFO 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

Event Number


Disk & Console Event Severity


1 INFO INFO Communication failure with DHCP server on ISP <isp_id> DHCP Profile <profile_name>

The connection between GGSN and DHCP server has failed.

2 INFO INFO Communication failure clear with DHCP server on ISP <isp_id> DHCP Profile <profile_name>

The lost connection between GGSN and DHCP server is UP now.


411-5221-926 Standard 10.07 June 2006

*........}A......*0x27a0530: 23f3c030 01f3a8be *#..0....*

Event Trace 9Event 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 LogsThere 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:



• Informational RADIUS Access Request event

17-Sep-2003 20:20:30 Sending a Radius Access Request MessageTrace Session ID: 4Caller ID: 2147483702Radius_ID: 16777273Session ID: 40Ref Count: 1UserName: testDest: 11.11.100.66 ISP: 5FIB: 80VPN: 80SubID: 139Auth: PAPService-Type: 2Access Group: vpn1Radius Profile: Radius1Auth Attributes:

Calling ID: 19723819664Called ID: ipsec1NAS Port Type: 23

• RADIUS Access Request event messaging

17-Sep-2003 20:20:30 Sending a Radius Access Request MessageTrace Session ID: 4HEX DUMP:05 00 00 00 00 01 00 00 01......................

Table 9-199 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 Message

Hex Dump of incoming message

Context Creation Success Event Internal GTP data structure created

Transitioning to New State Event Internal GTP state change

Authorization and Address Allocation Event

Internal GTP to AAA Manager Event

Authorization and Address Allocation Pending Event

Waiting for response from AAA Manager

Authorization and Address Allocation Success Event

AAA Manager reply success to GTP

Authorization and Address Allocation Failure Event

Authorization and Address Allocation Failure

Authorization and Address Allocation Reply Event

Internal Interface Event, reply received


411-5221-926 Standard 10.07 June 2006

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 Event Internal Radius Accounting response to GTP

Wrap Response Session Mode Event Entered Wrap session-mode processing

Wrap Response Session Mode Timeout Event

Timeout waiting for Wrap session-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 Message

Hex Dump of incoming PDP Update Request

Receiving PDP Delete Request Event PDP Delete Request received by GTP

Receiving PDP Delete Request Message

Hex Dump of incoming PDP Delete Request




Receiving PDP Update Response Event PDP Update Response received by GTP

Receiving PDP Update Response Message

Hex Dump of incoming PDP Update Response

Receiving PDP Delete Response Event PDP Delete Response received by GTP

Receiving PDP Delete Response Message

Hex Dump of incoming PDP Delete Response

Receiving Error Indication Event Error Indication received by GTP

Receiving PDP Error Indication Message

Hex Dump of incoming Error Indication

Sending Create Response Event PDP Create Response sent by GTP

Sending PDP Create Response Message

Hex Dump of outgoing PDP Create Response

Sending Update Response Event PDP Update Response sent by GTP

Sending PDP Update Response Message

Hex Dump of outgoing PDP Update Response

Sending Update Request Event PDP Update Request sent by GTP

Sending PDP Update Request Message Hex Dump of outgoing PDP Update Request

Update Request Timeout Event Timeout waiting for Update Response

Sending Delete Request Event PDP Delete Request sent by GTP

Sending PDP Delete Request Message Hex Dump of outgoing PDP Delete Request

Delete Request Timeout Event Timeout waiting for Delete Response

Sending Delete Response Event PDP Delete Response sent by GTP

Sending PDP Delete Response Message

Hex Dump of outgoing Delete Response

IP Session Timeout Event Session exceeded time limit set for Access Group

Dataplane Delete Timeout Event Timeout waiting for dataplane delete response

Prepaid ReAuth Timeout Event Timeout waiting for Prepaid ReAuth response

Dataplane Delayed Delete Timeout Event

Timeout waiting for final billing information from dataplane processor after session termination

Prepaid Events

Prepaid Auth Request Event Sending Auth request to prepaid server



411-5221-926 Standard 10.07 June 2006

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 Message Hex Dump of incoming response

Prepaid Authorization Failure Event Sending Auth failure to GTP

Prepaid ReAuthorization Failure Event Sending ReAuth failure to GTP

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.




Standard Event LogsTable 9-200 lists trace manager event logs generated for event trace and PDP session activation and deactivation.

Table 9-200 Trace Manager Event Logs

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 Event Client is sending DHCP Discover 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 Event Client is sending DHCP Release message

Receiving DHCP Packet Message Hex Dump of incoming DHCP packet

Receiving DHCP Offer/BootReply Message Event

Client receives DHCP Offer/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 Event Client sends DHCP Request 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 Error Event

Client receives invalid DHCP message

DHCP Renewal Timer Expiry Event Offer lease renewal timer expires

Event Number


1 INFORMATIONAL

“INFO, Session Tracing Tool Activated”

Session tracing has been activated



411-5221-926 Standard 10.07 June 2006

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

• Target session deactivation

20-Oct-2003 15:17:11 14/1/1:max,0: 1, 1, INFO, Session Tracing Target

2 INFORMATIONAL

“INFO, Session Tracing Tool Deactivated”

Session tracing has been deactivated

3 INFORMATIONAL

“INFO, Non-Session Tracing Activated”

Non-session tracing has been activated

4 INFORMATIONAL

“INFO, Non-Session Tracing Deactivated”

Non-session tracing has been deactivated

5 INFORMATIONAL

“INFO, Session Tracing Target: target_type target_identifier Activated”

Notes:

target_type is the string “msisdn” or “imsi” and target_identifier is the corresponding MSISDN or IMSI

The specified MSISDN or IMSI tracing session has been activated

6 INFORMATIONAL

“INFO, Session Tracing Target: target_type target_identifier Deactivated”

Notes:

target_type is the string “msisdn” or “imsi” and target_identifier is the corresponding MSISDN or IMSI

The specified MSISDN or IMSI tracing session has been deactivated

Event Number




012345678901234 DeactivatedSystem 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 changes. The system clock and time should not be altered for these purposes.

Software Optionality Control (SOC) 9This 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) 9Another 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.


411-5221-926 Standard 10.07 June 2006

• 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-11 shows the MSISDN query window.

Figure 9-11 Device Monitoring ASM Page - MSISDN Query



Figure 9-12 shows the IP/VPRN query window.

Figure 9-12 Device Monitoring ASM Page - IP Query

The following table lists the range and default value of each field on the ASM window.

Table 9-201 Device Monitoring ASM Tab


Filter Sessions by

MSISDN MSISDN Display the MSISDN query selection fields

IP Display the IP Address and VPRN Name query selection fields


411-5221-926 Standard 10.07 June 2006

Data Mode Brief Brief Brief information set will be retrieved

Detail Detailed information set will be retrieved

Find MSISDN Brief information set will be retrieved 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 MSISDN

4 - 15 digits None User enters digit string of the MSISDN number

MSISDN Range

1 - 5 1 A contiguous range of MSISDNs.

Input NSAPI 5 - 15 None Network Service Access Point Identifier

Input IP Address

IP address None User enters IP address in dotted decimal format

Selected VPRN

VPRN name None Display only of the VPRN name selected.

Select VPRN Pops up a window for the SCS user to select a VPRN name. Selection of VPRN name is optional

Retrieve Sessions

Initiates a query. Valid selection criteria or a selected PDP context session is required.

Close Session

Closes all PDP context session (s) of 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

Table 9-201 Device Monitoring ASM Tab




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.

Note: Aggregation APNs are not reflected in the counters.

Table 9-202Displayed PDP Session Information

PDP Session Field

Data Mode Description

MSISDN Brief, Detail, Find MSISDN, Find IP

Mobile MSISDN

IP Address Brief, Detail, Find MSISDN, Find IP

Mobile end user address

Version Brief, Detail, Find IP GTP protocol version number

APN Brief, Detail, Find IP Destination APN of the PDP session

ISP Brief, Detail, Find IP The ISP of the PDP session

User Name Brief, Detail, Find IP Mobile user name

PDP Type Organization

Brief, Detail, Find IP ETSI or IETF

PDP Type Number

Brief, Detail, Find IP IP or PPP PDU type

GTPP Enabled

Brief, Detail, Find IP GTP accounting enabled

RADIUS Enabled

Brief, Detail, Find IP RADIUS Accounting enabled

Activation Time

Detail PDP session activation timestamp

NSAPI Detail Mobile NSAPI if input NSAPI is supplied

Number of PDP Contexts in bundle

Brief, Detail, Find IP The number of primary PDP sessions in the bundle

Prepaid Enabled

Brief, Detail Prepaid enabled


411-5221-926 Standard 10.07 June 2006

Delay Class Detail GTP version 0 and version 1 QoS Profile information

Reliability Class

Detail GTP version 0 and version 1 QoS Profile information

Peak Throughput


Mean Throughput


Precedence Class


Allocation/Retention Priority Class

Detail GTP version 1 QoS Profile information

Traffic Class Detail GTP version 1 QoS Profile information

Traffic Handling Priority Class


Delivery Order


Delivery of Erroneous SDUs


Maximum SDU Size


Maximum Bitrate for Uplink


Max Bitrate for Downlink


Guaranteed Bitrate for Uplink


PDP Session Field




CLI Command 9GGSN 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 9There 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

Guaranteed Bitrate for Downlink


Residual Bit Error Ratio


SDU Error Ratio


Transfer Delay


State Detail The state of PDP session (e.g. Established)

Packets Sent Detail GTP packets sent over the user plane

Packets Received

Detail GTP packets received over the user plane

Num Coupons

Detail Number of active coupons for prepaid session

Device Find MSISDN GGSN device

PDP Session Field



411-5221-926 Standard 10.07 June 2006

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

For more information see Appendix A, “Patching System”.

Upgrade Strategy 9The 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 9SCS 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 DescriptionThis 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.

5. Local Backup and RestoreLocally 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.

6. Centralized Backup and RestoreThird 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/RestoreThe 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 ToolThe 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.


411-5221-926 Standard 10.07 June 2006

Full System Restore ToolThe 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/RestoreThe 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.

Local Essential Data Backup and RestoreThe 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 ToolThe 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 ToolThe 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 RestoreThe 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 DataThe 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:

Local Archival and Retrieval of Dynamic DataThe 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 DataThe Veritas NetBackup server is used to remote archive and retrieve essential data:

Table 9-203 Log files and their locations

Data Location backup or not

Note

PM data $SCS_ROOT/log/preside Y PWI maintain

Logging data $SCS_ROOT/log/Monitor_log

Y service logging data, tracks service usage.

Monitoring data $SCS_ROOT/log/region/isp/*.acc

Y Data that was monitored through the GUI.

Server Logging $SCS_ROOT/log/server Y N/A

Session logs $SCS_ROOT/log/regionN/device/session(M/T).log

Y session information


411-5221-926 Standard 10.07 June 2006

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

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

Note: For more details on how to perform Backup and Restore on the SCS Server, refer to SCS GGSN Upgrade Strategy NTP 411-5221-309.



Product limitations 10This chapter specifies the limitations of GGSN functionality on the Nortel GGSN. The limitations are grouped into the following functional areas:

• GGSN Hardware

• 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 101. 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 limitationsNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

GTP and GTP’ Protocol Interface 10GTP 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.

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

Table 10-1Receiving Redirection Request scenarios

Command From Active CGF From Inactive CGF

Receiving a Redirection Request message with no Recommended Address IE

Accept the request and find alternate CGF. If alternate CGF is not available, write to the local disk and mark the sender is down.

Accept the request and mark the sender is down.

Receiving a Redirection Request message with a Recommended Address IE

Reject the Request. Reject the Request.

Receiving a Redirection Request message with a Recommended Address IE that is known and the same as sender

Accept the Request. Reject the Request.

Receiving a Redirection Request message with a Recommended Address IE that is known and different from sender

Accept the request and try to switch to the recommended address. If unable to switch, write to the local disk and mark the sender is down.

Accept the request and mark the sender is down.

Product limitations 10-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


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.


411-5221-926 Standard 10.07 June 2006

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 the existing PDP sessions and data traffic. It may also affect the PDP context creation, updating and deletion.

RADIUS Authentication and Accounting 10Limitations 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.

DHCP address allocation 10Limitations 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 10Provisioning 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.


411-5221-926 Standard 10.07 June 2006

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 parenthis ( ( ), 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 101. Requests for statistics to be collected and sent to the Log Server may be

discarded before being collected in high capacity/high traffic circumstances 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.

GGSN QoS 10GGSN 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.


411-5221-926 Standard 10.07 June 2006

APN 10Limitations 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 10Limitations for Prepaid Service are:

1. For prepaid CTP version 2, when a count for a coupon Id not supported by CTP version 2 arrives, the bytes are not applied to the coupon Id but will be counted as part of the normal resources consumed.

2. Existing CBB limitations are inherently imposed upon multi-rate coupons because prepaid depends on the rate markings generated by CBB.

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

4. Service Redirect requires the use of variable rate prepaid rated coupons. Non-rated coupons are not supported.

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

6. All DCC timers and time related records are accurate to the second.

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

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

IP Services 10Limitations 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


411-5221-926 Standard 10.07 June 2006

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. LI packets are sent on the Gn interface, those packets may be compressed/optimized.

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

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

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

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


411-5221-926 Standard 10.07 June 2006

26. While waiting for a response from the Content Filter Server, any subsequent HTTP packets on the same connection are dropped.

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

28. No blacklisting or caching of response for similar requests is done within the content filter service of the GGSN.

29. Loss of connection to a Content Filter Server may not be detected for a maximum of two minutes.

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

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

32. For HTTP 1.0 requests, redirection is not supported, so all redirected or blocked requests will receive a 403 Forbidden status code response.

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

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

35. SCS logging is not supported for Content Filtering.

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

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

38. SCS doesn’t support CF policy rules validation for the CORBA shell command “set svcpolicy rules...”.

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

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

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

42. Secondary PDP contexts are not supported for subscribers actively using IP-in-IP tunnelled traffic.

43. For all VPNs VPN + Internet type is not supported.

44. SOC is not configurable through CORBA.

IP Routing 101. 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.


411-5221-926 Standard 10.07 June 2006



Redundancy 11This 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 11The 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) redundancyThe 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) redundancyThe 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 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

11-2 RedundancyNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

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.

PPP session terminating on the GGSNSSM 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.

Redundancy 11-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


GTP-L2TP tunnel switching for PPP PDUSSM 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 PDUSSM 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.

Content Based BillingAn 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) redundancySFC 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 redundancyInterface 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.


411-5221-926 Standard 10.07 June 2006

GRE Tunnel redundancyThe 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 redundancyThe 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 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 11The 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) 11The 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 11Two 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.

Diameter Credit Control Server 11Each 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.


411-5221-926 Standard 10.07 June 2006

Application Server 11A 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.

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 11Multiple 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 ServerThe 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.

RADIUS server selection is handled independently per SSP. The following is a summary of the new RADIUS server selection for RADIUS Authentication ACCESS request messages:

• Primary RADIUS servers configured on the profile are load shared using round-robin algorithm, and server availability (i.e. up or down.)

• A message that is transmitted to a primary server and consequently failed is retried on the same primary server. Upon failure of the first retry, a backup server is selected for this message. If there are no backup servers configured on the RADIUS profile, the next primary server is selected.

• Backup RADIUS servers configured on the profile are load shared using round-robin algorithm, and server availability.

• A message that is transmitted to a backup server and consequently failed is retried on the next backup server on the backup server list. If the next backup server cannot be selected and there are more retries available, then the retry attempt will be repeated on the same backup server until retries exhausted.



RADIUS Server Selection ExamplesServer selection for RADIUS Authentication ACCESS request message and RADIUS Accounting START request message can be illustrated in the following examples:

• P1: Primary server #1


• S1: Secondary server #1

• S2: Secondary server #2.

Example: RADIUS profile configured with 2 Primary and 2 Backup servers

PDP session #1: P1 - P1 - S1 - S2 - S2- S2 ..

PDP session #2: P2 - P2 - S1 - S2 - S2- S2..(note: the selection of P2 is for illustration only)

RADIUS Accounting ServerThe 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.

RADIUS server selection is handled independently per SSP. The following is a summary of the new RADIUS server selection for RADIUS Accounting START request messages:

• Primary RADIUS servers configured on the profile are load shared using round-robin algorithm, and server availability (i.e. up or down.)

• A message that is transmitted to a primary server and consequently failed is retried on the same primary server. Upon failure of the first retry, a backup server is selected for this message. If there are no backup servers configured on the RADIUS profile, the next primary server is selected.

• Backup RADIUS servers configured on the profile are load shared using round-robin algorithm, and server availability.

• A message that is transmitted to a backup server and consequently failed is retried on the next backup server on the backup server list. If the next backup server cannot be selected and there are more retries available, then the retry attempt will be repeated on the same backup server until retries exhausted.

For RADIUS Accounting INTERIM and STOP request messages, the SSP sends these messages to the same server that was selected for RADIUS


411-5221-926 Standard 10.07 June 2006

Accounting START request message. If the selected server does not respond to the RADIUS Accounting INTERIM or STOP request message, the server selection outlined above is used to send this message to the next server.

RADIUS Server Selection ExamplesServer selection for RADIUS Authentication ACCESS request message and RADIUS Accounting START request message can be illustrated in the following examples:



• S1: Secondary server #1

• S2: Secondary server #2.

Example: RADIUS profile configured with 2 Primary and 2 Backup servers

PDP session #1: P1 - P1 - S1 - S2 - S2- S2 ..

PDP session #2: P2 - P2 - S1 - S2 - S2- S2..(note: the selection of P2 is for illustration only)

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 again. If it again reaches the maximum number of retries, the RADIUS Accounting STOP message is stored on the local disk again. A log and SNMP trap will be generated when it occurs and no more than one log and trap will be generated in one hour.

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.



DHCP Server 11Multiple 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 11Two 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 11TPO 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.


411-5221-926 Standard 10.07 June 2006



Product Conformance 12Overview 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 123GPP 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 Conformance1 Scope Supported.2 References Supported.3 Definitions and abbreviation Supported.4 General Supported.5 Transmission order and bit

definitionsSupported.

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 ConformanceNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

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

GPRS RequestNot supported.

7.6.2 Sending Routing Information for GPRS Response

Not supported.

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

messagesPartially Supported.

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

Identity (IMSI)Supported.

7.9.3 Routing Area Identity (RAI) Not Applicable.7.9.4 Temporary Logical Link Identity

(TLLI)Not Applicable.

7.9.5 Packet TMSI (P-TMSI) Not Applicable.

Section Section Title Conformance

Product Conformance 12-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


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 Number (MSISDN)

Supported.

7.9.25 Charging Gateway Address Supported.7.9.26 Private Extension Supported.

This includes support of Nortel Extension.

8 Transmission Plane8.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.



411-5221-926 Standard 10.07 June 2006

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

Encapsulated T-PDUsSupported.

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

messageSupported.

10.1.5 Missing mandatory present information element

Supported.

10.1.6 Invalid Length Supported.10.1.7 Invalid mandatory information

elementSupported.

10.1.8 Invalid optional information element Supported.10.1.9 Unknown information element Supported.10.1.10 Out of sequence information

elementsSupported.

10.1.11 Unexpected information element Supported.10.1.12 Repeated information elements Supported.10.1.13 Incorrect optional information

elementsSupported.

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

over the Gp interfaceSupported.

External Border Gateway is required to support Gp interface.

12 IP, the networking technology used by GTP

Supported.

12.1 IP version Supported.12.2 IP fragmentation Supported.




3GPP TS 09.61, version 7.10.0The following table summarized the Nortel GGSN conformance with the GPRS PLMN and PDN interworking specification.

Table 12-2 Summary of conformation to GPRS PLMN/PDN interworking specification

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

checkingNot supported.

Annex C Document change history Supported.

Section Section Title Conformance1 Scope Supported2 References Supported3 Definitions, abbreviations and

symbolsSupported

4 Network characteristics Supported5 Interwoking classifications Supported6 Access reference configuration Supported7 Interface to GPRS Bearer Services Supported.

Optional TCP protocol is not supported between SGSN and GGSN, only UDP is supported.

8 Subscription checking Supported9 Screening Supported10 Interworking with PSDN (X.75/X.25) Not Supported11 Interworking with PDN (IP) Supported.11.1 General Supported11.2 PDN Interworking Model Partially Supported.

Only IPv4 is supported, IPv6 is not supported.

11.2.1 Access to Internet, Intranet or ISP through GPRS

Supported

11.2.1.1 Transparent access to the Internet Supported11.2.1.2 Non Transparent access to an

Intranet or ISPSupported

11.3 Numbering and Addressing Supported11.4 Charging Not Supported



411-5221-926 Standard 10.07 June 2006

11.5 Domain Name Server (DNS) Supported11.6 Screening Supported12 Interworking with PDN (PPP) Supported.12.1 General Supported12.2 PDN Interwoking Model Supported12.2.1 Virtual dial-up and direct access to

PDNs, or ISPs through GPRSSupported

12.2.1.1 Procedural description Supported13 Internet Hosted Octet Stream

Service (IHSOS)Not Supported

14 Interworking between GPRS networks

Supported.

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 Applicable14.2 Routing protocol agreements Not Applicable14.3 Charging agreements Not Applicable15 Void Not Applicable16 Usage of RADIUS on Gi interface Supported16.1 RADIUS Authentication Supported16.2 RADIUS Accounting Supported16.3 Authentication and accounting

message flowsSupported.

16.3.1 IP PDP type Supported16.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 termination

Supported.

The corresponding PDP session is deleted based on the configuration when a Disconnect Request message is received.

16.4 List of RADIUS attributes Supported




12UMTS Specifications 12

3GPP TS 23.060 version 6.7.0The 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

16.4.1 Access-Request message (sent from the GGSN to AAA server)

Supported

16.4.2 Access-Accept (sent from AAA server to GGSN)

Partially Supported.

The username received from AAA server is ignored.

16.4.3 Accounting-Request START (sent from GGSN to AAA server)


The username received from AAA Server in Access Accept message is ignored.

16.4.4 Accounting Request STOP (sent from GGSN to AAA server)



16.4.5 Accounting Request ON (optionally sent from GGSN to AAA server)

Supported

16.4.6 Accounting Request OFF (optionally sent from GGSN to AAA server)

Supported

16.4.7 Sub-attributes of the 3GPP Vendor-Specific attribute

Supported

16.4.8 Accounting Request Interim-Update (sent from GGSN to AAA server)

Supported

16.4.9 Disconnect Request (optionally sent from AAA server to GGSN)

Supported

Annex A Interworking PCS1900 with PSDNs Not SupportedAnnex B Change history Supported

Section Section Title Conformance1 Scope Supported.2 References Supported.3 Definitions, abbreviations and symbols Supported.4 Main Concept Supported.5 General GPRS Architecture and

Transmission MechanismSupported.

5.1 GPRS Access Interfaces and Reference Points

Supported.



411-5221-926 Standard 10.07 June 2006

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

FunctionNot Applicable.

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 Function

Not Supported.

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

(A/Gb mode)Not Applicable.

5.3.5 Radio Resource Management Functions

Not Applicable.

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

Backbone NetworksSupported.

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

Logical ArchitecturePartially Supported.

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

lu modeSupported.

5.6.2.2 MS - GGSN user plane with UTRAN Supported.5.6.2.3 GSN - GSN 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.7 GSN - GSN Supported.5.6.3.8 GGSN - HLR Not Supported.5.7 Functionality Needed for Mobile IP

Using IPv4Not Supported.

5.8 Functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes

Not Applicable.

5.9 Functionality for network sharing Not Applicable.6 Mobility Management Functionality Supported.6.1 Definition of Mobility Management

StatesNot Applicable.

6.2 Mobility Management Timer Functions Not Applicable.6.3 Interactions Between SGSN and MSC/

HLRNot Applicable.

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

Messages Function (A/Gb mode)Not Applicable.

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.



411-5221-926 Standard 10.07 June 2006

7 Network Management Functionality Supported.8 Radio Resource Functionality Not Applicable.9 Packet Routing and Transfer

FunctionalitySupported.

9.1 Definition of Packet Data Protocol States


Nortel GGSN is not allowed to initiate the activation of PDP context.

9.2 PDP Context Activation, Modification, Deactivation, and Preservation Functions

Supported.

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 Procedure


Prohibit Payload Compression and APN Restriction are not returned to the SGSN.

9.2.2.2 Network-Requested PDP Context Activation Procedure

Not Supported.

9.2.3 Modification Procedures Supported.




9.2.3.1 SGSN-Initiated PDP Context Modification Procedure


The GGSN trace function is not supported by Nortel GGSN.

Nortel GGSN doesn’t restrict QoS Negotiation given its capacities and the current load.

The Prohibit Payload Compression and APN Restriction are not returned to the SGSN.

9.2.3.2 GGSN-Initiated PDP Context Modification Procedure


The Prohibit Payload 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.

Nortel GGSN doesn’t restrict QoS Negotiation given its capacities, operator policies and the current load.

The Prohibit Payload Compression and APN Restriction are not returned to the SGSN.

9.2.3.4 RNC/BSS-Initiated PDP 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.5 RAB Release-Initiated Local PDP 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 Procedure (lu mode)

Not Applicable.



411-5221-926 Standard 10.07 June 2006

9.2.4 Deactivation Procedures Supported.9.2.4.1 MS Initiated PDP Context Deactivation

ProcedureSupported.

9.2.4.2 SGSN-initiated PDP COntext Deactivation Procedure

Supported.

9.2.4.3 GGSN-initiated PDP COntext Deactivation Procedure

Supported.

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

RAN in lu modeNot Applicable.

9.6.3 Encapsulation Between SGSN and MS in A/Gb mode

Not Applicable.

9.6.4 Encapsulation Between RAN and MS in lu mode

Not Applicable.

10 Message Screening Functionality Supported.11 Compatibility Issues Supported.11.1 Interaction between Releases 97/98

and 99Supported.

11.1.1 Interaction Between GTP v0 (R97) and GTP v1 (R99)

Supported.

11.1.2 Interaction Between MS R97 and CN R99

Supported.

11.1.3 Interaction Between SM R97 and SM R99

Not Applicable.

11.1.4 Interaction Between MAP R97 and MAP R99

Not Applicable.

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 supported by Nortel GGSN.

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

modeSupported.

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

mode)Not Applicable.

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.



411-5221-926 Standard 10.07 June 2006

3GPP TS 23.107 version 6.2.0The following table summarizes the Nortel GGSN conformance to QoS Concept and Architecture.

Table 12-4 Summary of conformance to QoS Concept and Architecture

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.

Section Section Title Conformance1 Scope Supported.2 References 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 Supported6.1 Overview of Different Levels of QoS Supported.6.1.1 The End-to-End Service and UMTS

Bearer ServiceSupported.

6.1.2 The Radio Access Bearer Service and the Core Network Bearer Service

Supported.

6.1.3 The Radio Bearer Service and the RAN Access Bearer Service

Not Applicable.

6.1.4 The Backbone Network Service Not Applicable.6.2 QoS Management Functions in the

NetworkSupported.

6.2.1 Description of Functions Partially Supported.

See information below.6.2.1.1 QoS Management Functions for UMTS

Bearer Service in the Control PlaneSupported.

6.2.1.2 Functions for UMTS Bearer Service in the User Plane


Nortel GGSN accepts QoS parameters, but does not guarantee them.

6.2.2 Allocation of QoS Management Functions


See information below.6.2.2.1 QoS Management Functions for UMTS

Bearer Service in the Control PlaneSupported.

6.2.2.2 QoS Management Functions for UMTS Bearer Service in the User Plane



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 Supported6.4.1 Asymmetric Bearers Supported.6.4.2 Sources of UMTS Bearer Service

AttributesSupported.



411-5221-926 Standard 10.07 June 2006

6.4.3 UMTS Bearer Service Attributes Partially Supported.

See information below.6.4.3.1 List of attributes Partially Supported.


6.4.3.2 Attributes discussed Per traffic class Partially Supported.


6.4.3.3 UMTS bearer attributes: summary Partially Supported.


6.4.4 Radio Access Bearer Service Attributes

Not Applicable.

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


6.5 Attribute Value Ranges Supported.6.5.1 Ranges of UMTS Bearer Service


6.5.2 Ranges of Radio Access Bearer Service Attributes for UTRAN and for GERAN

Not Applicable.

7 (void) Not Applicable.8 QoS Attribute Mapping Supported.8.1 From Application Attributes to UMTS

Bearer Service AttributesSupported.

8.2 From UMTS Bearer Service Attributes to Radio Access Bearer Service Attributes

Not Applicable.

8.3 From UMTS Bearer Service Attributes to CN Bearer Service Attributes

Not Applicable.

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

multimedia payloadsNot Applicable.

Annex B Reference Algorithm for Conformance Definition of Bitrate

Not Applicable.




3GPP TS 29.060 version 6.7.0The following table summarized the Nortel GGSN conformance with the GTP version 1 specification.

Table 12-5 Summary of conformance to GTP version 1 specification

Annex C Determine which QoS profile is of highest QoS

Not Applicable.

Annex D Determine Traffic Class weights in HLR QoS profile

Not Supported

Annex E Change history Supported.

Section Section Title Conformance1 Scope Supported.2 References 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.

See information below.6.1.1 PDCP PDU Number Not Applicable.6.1.2 Suspend Request Not Applicable6.1.3 Suspend Response Not Applicable6.1.4 MBMS support indication Not Supported7 GTP Messages and Message Formats7.1 Message Formats Supported.7.1.1 Presence requirements of Information

ElementsSupported.

7.2 Path Management Messages Partially Supported.

See information below.7.2.1 Echo Request Supported.7.2.2 Echo Response Supported7.2.3 Version Not Supported Supported.7.2.4 Supported Extension Header Notification Not Supported.7.3 Tunnel Management Messages Partially Supported.

See information below.



411-5221-926 Standard 10.07 June 2006

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 sent from Nortel GGSN.

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 Create PDP Context Response 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 Update PDP Context Response sent from Nortel GGSN.

The Delivery Order field of the QoS IE is set to Without Delivery Order in Update PDP Context Response 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

RequestNot Supported.

7.4.2 Sending Routing Information for GPRS Response

Not Supported.



411-5221-926 Standard 10.07 June 2006

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.

See information below.7.7.1 Cause Supported.7.7.2 International Mobile Subscriber Identity

(IMSI)Supported.

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

(MSISDN)Supported.

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

(and Software Version) (IMEI(SV))Supported.

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.



411-5221-926 Standard 10.07 June 2006

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.

See information below.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 Primitives

Not Applicable.

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

Target RNC via SGSNsNot Applicable.

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 Extension Headers NotificationSupported.

10.1.2 IP Header Supported.10.1.2.1 Request messages and Encapsulated T-

PDUsSupported.

10.1.2.2 Response Messages Supported.10.1.2.3 Error Indication, Version Not Supported

and Supported Extension Headers Notification

Supported.

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

ElementSupported.

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 over Gn and Gp Interfaces

Not Supported.

13 IP, The Networking Technology used by GTP

Supported



411-5221-926 Standard 10.07 June 2006

3GPP TS 29.061, version 6.3.1The following table summarized the Nortel GGSN conformance with the UMTS PLMN and PDN interworking specification.

Table 12-6 Summary of conformation to UMTS PLMN/PDN interworking specification

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.Annex B Change history Supported.

Section Section Title Conformance1 Scope Supported.2 References Supported.3 Definitions, abbreviations and

symbolsSupported.

4 Network characteristics Supported.5 Interwoking classifications Supported.6 Access reference configuration Supported.7 Interface to Packet Domain Bearer

ServicesSupported.

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 through Packet Domain

Supported.

11.2.1.1 Transparent access to the Internet Supported.11.2.1.2 IPv4 Non Transparent access to an

Intranet or ISPSupported.




11.2.1.3 IPv6 Non Transparent access to an Intranet or ISP

Not Supported.

11.2.1.4 Access to Internet, Intranet or ISP with Mobile IPv4

Not Supported.

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.1 General Supported.12.2 PDN Interwoking Model Supported.12.2.1 Virtual dial-up and direct access to

PDNs, or ISPs through Packet Domain

Supported.

12.2.1.1 Procedural description Supported.13 Interworking with PDN (DHCP) Supported.13.1 General Supported.13.2 PDN Interworking Model for DHCP Supported.13.2.1 Address allocation by the Intranet or

ISPSupported.

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

or ISP (IPv6 only)Not Supported.

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.



411-5221-926 Standard 10.07 June 2006

13a.2.1 IMS Specific Configuration in the 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 GGSN

Supported.

13a.2.2.1 Request for Signaling Server Address

Supported.

13a.2.2.2 Establishment of a PDP Context for 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 Media Flows

Not Supported.

14 Internet Hosted Octet Stream Service (IHOSS)

Not Supported.

15 Interworking between Packet Domains

Supported.

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

message flowsSupported.

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 termination

Supported.

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

from the GGSN to AAA server)Supported.

16.4.2 Access-Accept (sent from AAA server to GGSN)


The username received from AAA server is ignored.

16.4.3 Accounting-Request START (sent from GGSN to AAA server)



16.4.4 Accounting Request STOP (sent from GGSN to AAA server)



16.4.5 Accounting Request ON (optionally sent from GGSN to AAA server)

Supported.

16.4.6 Accounting Request OFF (optionally sent from GGSN to AAA server)

Supported.



411-5221-926 Standard 10.07 June 2006

3GPP TS 29.210, version 6.0.0The following table indicates the compliance of the GGSN Gx interface with 3GPP TS 29.210 specification.

Table 12-7 Summary of conformation to 3GPP 29.210 specification

16.4.7 Sub-attributes of the 3GPP Vendor-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 (sent from GGSN to AAA server)

Supported.

16.4.9 Disconnect Request (optionally sent from AAA server to GGSN)

Supported.

17 Usage of Diameter on Gmb interface

Not Supported.

Annex A Interworking PCS1900 with PSDNs Not Applicable.Annex B Change history Supported.

Section Section Title Conformance1 Scope Supported.2 References Supported.3 Definitions, symbols, and

abbreviationsSupported.

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 point

Supported.

4.3.1 Initialization and maintenance of connection

Supported.

4.3.2 Request for charging rules from the TPF

Supported.

4.3.3 Provision of charging rules from the CRF

Noted.

This section applies to the CRF. 4.3.4 Provision of event triggers from the

CRFNoted.

This section applies to the CRF. 4.3.5 Provision of charging addresses

from the CRFNoted.

This section applies to the CRF. 4.3.6 Indication of bearer termination

(from TPF to CRF)Supported.

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.



411-5221-926 Standard 10.07 June 2006

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-Code AVP values

Supported.

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.



411-5221-926 Standard 10.07 June 2006

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

provision and credit authorizationSupported.




3GPP TS 32.015 version 3.2.0The following table summarized the Nortel GGSN conformance to the GTP’ version 3.2.0.

Table 12-8 Summary of conformance to GTP’ ver 3.2.0

Section Section Title Conformance1 Scope Supported.2 Reference Supported.3 Definitions, abbreviations and symbols 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

Information CollectionNot Applicable.

5.6.1.1 Triggers for S-CDR Charging Information Addition

Not Applicable.

5.6.1.2 Triggers for S-CDR Closure Not Applicable.5.6.2 Triggers for M-CDR Charging


5.6.2.1 Triggers for M-CDR Charging Information Addition

Not Applicable.

5.6.2.2 Triggers for M-CDR Closure Not Applicable.5.6.3 Triggers for G-CDR Charging

Information CollectionSupported.

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,

GGSN in HPLMNSupported.


411-5221-926 Standard 10.07 June 2006

5.8 Charging support for CAMEL Not Applicable.6 Charging Data Collection6.1 Record contents Partially Supported.

Optional CDR fields are not operator configurable.

6.1.1 GPRS charging data in SGSN (S-CDR)

Not Applicable.

6.1.2 GPRS charging data in GGSN (G-CDR)


The following fields are not supported: Network Initiated PDP Context, Diagnostics, Node ID and QoS Requested.

6.1.3 GPRS mobile station mobility management data in SGSN (M-CDR)

Not Applicable.

6.1.4 GPRS MO SMS data in SGSN (S-SMO-CDR)

Not Applicable.

6.1.5 GPRS MT SMS data in SGSN (S-SMT-CDR)

Not Applicable.

6.1.6 Description of Record Fields Supported.6.1.6.1 Access Point Name (APN) Network/

Operator IdentifierSupported.

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/

Change of locationNot Applicable.

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’

ProtocolPartially Supported.

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

GPRS nodesSupported.

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.



411-5221-926 Standard 10.07 June 2006

7.3.1 List of GTP’ message types Supported.7.3.2 Reused GTP message types Supported.7.3.3 GTP message type modifications

implied by GTP’Supported.

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

Transfer RequestSupported.

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

Packet IESupported.

7.3.4.5.6 Sequence Numbers of Cancelled Packets IE

Supported.

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

interfaceNot Applicable.

7.5.2 The format of the CDRs at CGF - BS interface

Not Applicable.

8 Charging Data Record Structure Supported.




3GPP TS 32.015 version 3.6.0The following table summarized the Nortel GGSN conformance to the GTP’ version 3.6.0.

Table 12-9 Summary of conformance to GTP’ ver 3.6.0

8.1 ASN.1 definitions for CDR information Partially Supported.

Some ASN.1 fields are not supported.

Section Section Title Conformance1 Scope Supported.2 Reference Supported.3 Definitions, abbreviations and symbols 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


5.6.1.1 Triggers for S-CDR Charging Information Addition

Not Applicable.

5.6.1.2 Triggers for S-CDR Closure Not Applicable.5.6.2 Triggers for M-CDR Charging


5.6.2.1 Triggers for M-CDR Charging Information Addition

Not Applicable.

5.6.2.2 Triggers for M-CDR Closure Not Applicable.5.6.3 Triggers for G-CDR Charging

Information CollectionSupported.

5.7 Examples of charging scenarios Supported.5.7.1 GPRS Mobile to PDN Context Supported.



411-5221-926 Standard 10.07 June 2006

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,

GGSN in HPLMNSupported.

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

Not Applicable.

6.1.2 GPRS charging data in GGSN (G-CDR)


The following fields are not supported: Network Initiated PDP Context, Diagnostics, Node ID and QoS Requested.

6.1.3 GPRS mobile station mobility management data in SGSN (M-CDR)

Not Applicable.

6.1.4 GPRS MO SMS data in SGSN (S-SMO-CDR)

Not Applicable.

6.1.5 GPRS MT SMS data in SGSN (S-SMT-CDR)

Not Applicable.

6.1.6 Description of Record Fields Supported.6.1.6.1 Access Point Name (APN) Network/

Operator IdentifierSupported.

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/

Change of locationNot Applicable.

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’

ProtocolPartially Supported.

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

GPRS nodesSupported.

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.



411-5221-926 Standard 10.07 June 2006

7.3.3 GTP message type modifications implied by GTP’

Supported.

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

Transfer RequestSupported.

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

Packet IESupported.

7.3.4.5.6 Sequence Numbers of Cancelled Packets IE

Supported.

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

interfaceNot Applicable.

7.5.2 The format of the CDRs at CGF - BS interface

Not Applicable.

8 Charging Data Record Structure Supported.




12RFC Specifications 12

RFC 2131 - Dynamic Host Configuration Protocol (DHCP)The following table summarizes the Nortel GGSN conformance to the DHCP RFC in March 1997 version.

Table 12-10 Summary of conformance to DHCP

8.1 ASN.1 definitions for CDR information Partially Supported

Some ASN.1 fields are not supported.

Section Section Title Conformance1 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.

GGSN only supports DHCP Client and Relay functionality

3 The Client-Server Protocol Supported.



411-5221-926 Standard 10.07 June 2006

3.1 Client-server interaction-allocating a network address


GGSN only supports DHCP 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 previously allocated network address


GGSN only supports DHCP Client and Relay functions. GGSN DHCP Client does not 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 time values


GGSN only supports DHCP Client and Relay functions.

3.4 Obtaining parameters with externally configured network address.


GGSN only supports DHCP Client and Relay functions. DHCP INFORM message is not supported.

3.5 Client parameters in DHCP Partially Supported.

GGSN only supports DHCP Client and Relay functionality. 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 interfaces

Supported

3.7 When client should use DHCP Supported4 Specification of the DHCP client-server

protocol

Partially Supported




4.1 Constructing and sending DHCP messages


GGSN only supports DHCP Client and Relay functionality. 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.

GGSN only supports DHCP Client and Relay functionality Vendor class identifier option is not supported currently.

4.3 DHCP server behavior Not Applicable.

GGSN only supports DHCP Client and Relay functionality.

4.4 DHCP Client behavior Partially Supported.



411-5221-926 Standard 10.07 June 2006

4.4.1 Initialization and allocation of network address


DHCP INFORM message is not 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 the DISCOVER or REQUEST message. The GGSN DHCP Client does not include the message option in the DECLINE or RELEASE message. The GGSN DHCP Client does not include the site-specific option in the DISCOVER or REQUEST 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 address

Not Supported.

The GGSN DHCP Client implementation always request the network address except when in a address renewal.

4.4.3 Initialization with an externally assigned network address

Not Supported.

The GGSN DHCP Client implementation always request the network address.




RFC 2865 - Remote Authentication Dial In User Service (RADIUS)The following table summarizes the Nortel GGSN conformance to the RADIUS RFC in June 2000 version.

Table 12-11 Summary of conformance to RADIUS

4.4.4 Use of broadcast and unicast Partially Supported.

The GGSN DHCP Client 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 Supported5 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.

Section Section Title Conformance1.0 Introduction Supported.1.1 Specification of Requirements Noted.1.2 Terminology 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.



411-5221-926 Standard 10.07 June 2006

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

CHAPSupported.

7.3 User with Challenge-Response Card Supported.8 Security Considerations Noted.



411-5221-926 Standard 10.07 June 2006

RFC 2866 - RADIUS AccountingThe following table summarizes the Nortel GGSN conformance to RADIUS Accounting RFC in June 2000 version.

Table 12-12 Summary of conformance to RADIUS Accounting

9 Change Log Noted.10 References Noted.11 Acknowledgement Noted.12 Chair’s Address Noted.13 Authors’ Addresses Noted.

Section Section Title Conformance1.0 Introduction Supported.1.1 Specification of Requirements Noted.1.2 Terminology Noted.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




RFC 1661 - Point-to-Point Protocol (PPP)The following table summarizes the Nortel GGSN conformance to PPP RFC in July 1994 version.

Table 12-13 Summary of conformance to PPP

7.0 Security Considerations Noted8.0 Change log Noted9.0 References Noted10.0 Acknowledgements Noted11.0 Chair’s Address Noted

Section Section Title Conformance1 Introduction Noted1.1 Specification of Requirements Noted1.2 Terminology Noted2 PPP Encapsulation Supported3.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 Supported3.6 Network-Layer Protocol Phase Supported.3.7 Link Termination Phase Supported.4 The Option Negotiation Automation Noted4.1 State Transition Table Supported4.2 States Supported4.3 Events Supported.4.4 Actions Supported4.5 Loop Avoidance Noted4.6 Counters and Timers Supported5 LCP Packet Format Supported5.1 Configure-Request Supported.5.2 Configure-Ack Supported5.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 Supported5.9 Discard-Request Supported.6 LCP Configuration Options Supported.



411-5221-926 Standard 10.07 June 2006

RFC 2661 - Layer Two Tunneling Protocol (L2TP)The following table summarizes the Nortel GGSN conformance to L2TP RFC in August 1999 version.

Table 12-14 Summary of conformance to L2TP

6.1 Maximum-Receive-Unit Supported6.2 Authentication Protocol Supported6.3 Quality-Protocol Supported6.4 Magic-Number Supported6.5 Protocol-Field-Compress Supported6.6 Address-and-Control-Field-

Compression (ACFC)Not Supported.

GGSN does not support this option. It is used for HDLC.

7 Miscellaneous Items Supported.

Section Section Title Conformance1.0 Introduction Supported.1.1 Specification of Requirements Noted.1.2 Terminology Noted.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

MessagesSupported.




4.4.2 Result and Error Codes Supported.4.4.3 Control Connection Management

AVPsSupported.

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.



411-5221-926 Standard 10.07 June 2006

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

Data ChannelSupported.

5.5 Keep Alive Supported.5.6 Session Teardown Supported.5.7 Control Connection Teardown Supported.5.8 Reliable Delivery of Control

MessagesSupported.

6 Control Connection Protocol Specification

Supported.

6.1 Start-Control-Connection-Request (SCCRQ)

Supported.

6.2 Start-Control-Connection-Reply (SCCRP)

Supported.

6.3 Start-Control-Connection-Connected (SCCCN)

Supported.

6.4 Stop-Control-Connection-Notification (StopCCN)

Supported.

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.

Only incoming calls are 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

OperationSupported.



411-5221-926 Standard 10.07 June 2006

RFC 2858 - Multiprotocol Extensions for BGP-4Fully supported.

RFC 2547bis (draft-ietf-ppvpn-rfc2547bis-02.txt)Table 12-15 RFC 2547bis Conformance

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.

Only incoming calls are 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

Congestion AvoidanceNot Supported. The procedure is only recommended.

Appendix B Control Message Examples Supported.Appendix C Intellectual Property Notice Supported.


1 Introduction Partial (see 1.1 through 1.7)




1.1 Virtual Private Networks Partially supported

(Note: Extranets, policies governed by CEs, and partial mesh VRF connectivity are not supported.)

1.2 Edge Devices Partially supported

(Note: 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 System

Not supported

1.6 SP Backbone Routers Supported

1.7 Security Noted

2 Sites and CEs Partially supported

(Note: A given subscriber can only be a member of a single VPN.)

3 Per-Site Forwarding Tables in the PEs Partially supported

(Note: 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



411-5221-926 Standard 10.07 June 2006

4.3.2 Route Distribution Among PEs by BGP Partially supported

(Note: 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

(Note: 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

(Note: “Hub and spoke” VPNs are not supported.)

4.3.6 Route Distribution Among VRFs in a Single PE

Supported

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

(Note: Inter-provider VPNs are not supported.)




RFC 3036 - LDP SpecificationTable 12-16 RFC3036 Conformance

13.2 Control Plane Not supported

13.3 Security of P and PE devices Supported

14 Quality of Service Partially supported

(Note: Support is provided only for DSCP->EXP mapping, via E-LSPs.)

15 Scalability Partially supported

(Note: 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


1. Introduction Noted

2. LDP Operation Partially supported (see subsections)

2.1 FECs Partially supported

(Note: Address prefixes are not supported as a FEC element type.)

2.2 Label Spaces, Identifiers, Sessions and Transport

Partially supported (see subsections)

2.2.1 Label Spaces Partially supported

(Note: per platform spaces are not supported)



411-5221-926 Standard 10.07 June 2006

2.2.2 LDP Identifiers Partially supported

(Note: per platform spaces are not supported)

2.2.3 LDP Sessions Partially supported

(Note: sessions can be established only to directly-connected LSRs)

2.2.4 LDP Transport ???

2.3 LDP Sessions between non-Directly Connected LSRs

Not supported

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

(Note: Frame relay is not supported)

2.6 Label Distribution and Management Partially supported

(Note: 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

(Note: 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 Parameters

Noted

3.4.1 FEC TLV Partially supported

(Note: 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

(Note: the Extended Status optional parameter is not supported)



411-5221-926 Standard 10.07 June 2006

3.5.2 Hello Message Partially supported

(Note: 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

(Note: 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

(Note: 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




RFC 3588 - Diameter Base ProtocolSee 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 SpecificationTable 12-17RFC2616 Conformance

RFC 2702 - Requirements for Traffic Engineering Over MPLSTable 12-18 RFC 2702 conformance

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 A

LDP Label Distribution Procedures Noted


8.1.2.2 Pipelining Supported

Section Section Title Conformance5.0 Traffic Trunk attributes5.1 Bidirectional Traffic Trunks Not supported5.2 Basic operations on traffic trunks Supported5.3 Accounting & Performance Monitoring Not Supported



411-5221-926 Standard 10.07 June 2006

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 Supported5.6.1 Administratively specified explicit paths Partially Supported.

Supports loose/strict IP hops.5.6.2 Hierarchy of Preference rules for Multi-

PathsPartially Supported.

One primary and one secondary path per Tunnel.

5.6.3 Resource Class affinity Not Supported5,6,4 Adaptivity attribute Not Supported5.6.5 Load distribution among parallel traffic

trunksNot supported

5.7 Priority attribute Supported5.8 Pre-emption attribute Not Supported5.9 Resilience attribute Supported

Can specify per tunnel whether to reroute traffic or not.

5.10 Policing attribute Not Supported6.0 Resource Attributes Not Supported7.0 Constraint Based Routing Not Supported7.1 Use of TEDB to compute constraint

based pathNot Supported

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


411-5221-926 Standard 10.07 June 2006

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 Lifetime

Supported

3.8 Traffic policing & Non-integrated Service Hops

Not Supported

3.9 Multihomed hosts Not Supported

3.10 Future compatibility Supported

3.11 RSVP Interfaces Noted

Table 12-19 RFC 2205 Compliance (continued)




RFC 3209 - RSVP-TE: Extensions to RSVP for LSP TunnelsTable 12-20 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 Resource Affinities

Supported

3.1 (cont’d) SESSION_ATTRIBUTE: With Resource Affinities

Not Supported

3.1 (cont’d) SENDER_TEMPLATE Partially Supported


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



411-5221-926 Standard 10.07 June 2006

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

Filter Spec, Label

Supported

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 Object

Not applicable

4.3 Explicit Route Object (ERO) in Path Messages

Partially Supported

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-20 RFC 3209 Conformance (continued)




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




411-5221-926 Standard 10.07 June 2006

RFC 3630 - TE Extensions to OSPF Version 2Table 12-21 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.



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.




411-5221-926 Standard 10.07 June 2006

A-1Nortel Networks Confidential


Patching System APatching Functions

Applying a PatchBy applying a patch profile to a device, a user is applying patches. A patch profile is a collection of patch rules. Patch rules can span multiple releases, but the patches for the current release are only turned on when a profile is applied.

A patch rule defines how a patch should be applied; it contains a patch name, the scope for the patch and, if applicable, the directive for the patch. The scope defines the card slots and the SSM ports where the patch should be applied; the user decides if the patch should be applied to all applicable slots, to a set of slots or to a particular slot. Although the user may select a slot, the patching system applies the patch to the slot only if it can be applied to that slot; the patching system can determine if a patch should not be applied to a particular slot. The user also decides if a patch should be applied to all applicable ports, to a set of ports or to a particular port. Although the user may select a port, the patching system applies the patch to the port only if it can be applied to that port; the patching system can determine if a patch should not be applied to a particular port. Patches are only applied to slots and ports that are in-service. The directive defines the state for the patch.

Applying a patch causes the patch to be downloaded to the SSG’s disk. If the patch is for the current load, the patch is then loaded into memory where the existing software is overwritten by the new patch software. A patch can also be applied through the Sync operation.

When a CMC patch defined for both CMC P0 and P1 processors is applied on GGSN, it is applied on both P0 and P1 processors of active CMC card. The patch is only applied to the P0 processor of Stand-by CMC card. When standby becomes active, the patch gets applied to the P1 processor of newly active CMC card. The standby (previously active) card will have the patch applied only on P0 processor.

A-2 Patching SystemNortel Networks Confidential

411-5221-926 Standard 10.07 June 2006

Unapplying a PatchUnapplying a patch turns off the patch software. If the patch is for the current release, it causes the original software to be written back into memory; note that memory is not freed. For all releases, the patch is removed from the SSG’s disk. The user can unapply a patch by unapplying a patch profile from a device or by deleting a patch rule from a patch profile; it can also be invoked through the Sync operation.

Persistency OperationThe persistency operation sets the state of a patch for the entire system. The possible persistency operations are persistent and non-persistent. Obsolete is the other possible status of persistency that can only be displayed without being taken any operation on. Persistent means that the patch is to be automatically loaded when the SSG reboots; the user marks patches persistent when he or she is comfortable with the sanity of the patch. Non-persistent means that the patch is not automatically reapplied if the SSG reboots. Obsolete means that the patch is no longer a valid patch and cannot be used by the patching system again. Patches can move between the persistent state and the non-persistent state listed; once a patch is obsolete, the other persistency operations are not available so that its state cannot change any more.

Patching DirectivesThe 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 operation.

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

Verify OperationThe Verify operation performs many of the patch verification steps to see if the patch profile can be applied to a particular device. Among other things, this operation makes sure the device can download the patches in the profile. The device decompress 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 OperationThe 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

Patching System A-3Nortel Networks Confidential


patch status on the SSG, but it may update the current status of the patches on the SCS.

Sync OperationThe Sync operation causes the SSG 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 various race conditions. The Sync operation may cause the SSG to apply, unapply, activate or deactivate patches.

Microsyncing patching session errors is supported and works like any other microsync functionality.

Delete OperationThis operation causes a patch to be removed from the system. All configuration information and associated patch files are permanently deleted.

SSG Upgrade StrategyThe 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. For more detailed upgrade procedure information see NTP 411-5221-309, Nortel GGSN - SCS Upgrade Strategy.

Patching PrivilegesThe device_owner user who has read and write node management privileges can perform patching operations. All other users who have read and write node management privileges can view patch information. To access the patching functionality, the user selects the patch icon in the Image Panel or the Patch Manager item in the View menu.

Patching ConfigurationIf the user has the appropriate privileges, the Patch Manager is displayed. The patch manager is where the user performs patching. Patching has been separated into three categories; they are patch, profile and device. Each category is displayed in a tab.


411-5221-926 Standard 10.07 June 2006

Figure A-1Patch Manager Window

Patch TabThe patch tab gives users the ability to accept new patches into the patching system, the ability to delete patches from the patching system and the ability to edit/view patch records.

When the user selects the patch tab from the patch manager, a table of accepted patches is displayed. The table columns include the name of the patch, the load that the patch belongs to, the persistency for the patch and the type of patch.

The total number of the patches accepted in the patching system currently is shown in the text filed at the bottom. And it can be updated by clicking the Update button.



Figure A-2Patch Tab

Accepting a PatchPatches are distributed to the user’s /opt/patches directory. The final step for the user is to move the patch into the patching system; this action is known as accepting a patch.

To accept a patch, the user selects the Add button. A new window is displayed with all patches that have not been accepted into the patching system.


411-5221-926 Standard 10.07 June 2006

Figure A-3Accepting a Patch

The user selects a patch or several patches and the Ok button to accept the selected patches into the patching system. Once accepted, all selected patches are accepted into the patching system one by one. In detail, the contents of each zip file are placed into the /tftpboot/patches directory and the patch is added to the table of accepted patches. By default, the persistency state for accepted patches is non-persistent. But the user can set the persistency for all of the selected patches by checking the ‘Persistent’ and ‘Non-Persistent’ radio buttons. The Cancel button aborts the current action.

Errors can occur when a patch is accepted. The errors can occur if the load information, type field, description, mutually exclusive field, prerequisite field or target field have invalid data; these errors are displayed in a dialog box. After the user clicks the OK button of the dialog box, this patch fails to be accepted, but the patching system will continue to handle the rest of the selected patches if there is any.

Deleting a PatchTo delete a patch, the user selects the appropriate row and the delete button. The user is warned about this action. The user must select the Yes button in order for this action to occur; once selected, the patch data is removed from the system and all associated patch files are removed from the /opt/patches directory and the /tftpboot/patches directory. Selecting No aborts the current action. If the patch is part of a patch rule, the patch can not be deleted; this error is displayed in a dialog box.



Figure A-4Deleting a Patch

Editing/Viewing a Patch RecordTo edit or to view a patch record, the user selects the appropriate row and the Edit button; the user can also double-click the appropriate row. A new window is displayed for either action. The Patch Record Configuration window contains the current persistency state and a pull down menu for other states; all information about the patch is also displayed.To change the persistency, the user selects the persistency state and the Ok button. The Cancel button aborts the current action.

Note that if the patch persistency is obsolete, this indicates that the selected patch is invalid and cannot be used by the patching system. Patches can no longer be set to this state and the patch persistency of these patches can not be changed from obsolete to any other state.


411-5221-926 Standard 10.07 June 2006

Figure A-5Patch Record Configuration Window (persistency as obsolete)



Figure A-6Patch Record Configuration Window (persistency as non-obsolete)


411-5221-926 Standard 10.07 June 2006

Table A-1Settings for patch record configuration

Parameter Possible Values Description

Patch Name Not Editable The name of the patch.

Persistency Non-Persistent

Persistent

Obsolete

The persistency field sets the state of a patch for the entire system. But it only displays the status for obsolete without being taken any operation on. Persistent means that the patch is to be automatically loaded when the SSG reboots; the user marks patches persistent when he or she is comfortable with the sanity of the patch. Non-persistent means that the patch is not automatically reapplied if the SSG reboots. Obsolete means that the patch is no longer a valid patch and cannot be used by the patching system again. Patches can move between the persistent state and the non-persistent state listed; once a patch is obsolete, the other persistency operations are not available so that its state cannot change any more.

Load Not Editable The load name for the patch.

Type Not Editable The patch type; values include:

- GEN -- a general patch.

- DBG -- a patch that is for debugging purposes only.

- ACT -- a patch that can be activated or deactivated.

Description Not Editable A detailed description of the patch; this information may include the problem, the solution and test instructions.

Mutually Exclusive Not Editable A list of patches that cannot exist with this patch in a patch profile; this field may be blank.

Prerequisites Not Editable A list of patches that are required before this patch can be applied; this field may be blank.

Targets Not Editable A list of nodes where the patch can be applied; this information includes the patch name, the target processor name and the target processor.



Profile TabThe profile tab gives the user the ability to create, to edit and to delete patch profiles. By editing a patch profile, the user can create, modify and delete patch rules from a particular patch profile.

When the user selects the profile tab from the patch manager, a table of existing profiles is displayed.

Figure A-7Profile Tab

Creating a Patch ProfileTo create a new profile, the user selects the Add button. A new window is displayed. To create the new profile, the user enters the profile name and selects the Ok button. The user can cancel the action by selecting the Cancel button.


411-5221-926 Standard 10.07 June 2006

Figure A-8Creating a Patch Profile

Optionally, the user can clone an existing patch profile; cloning a profile takes the rules that are in the cloned profile and creates the same rules for the new profile. By default, this value is empty. To clone a profile, the user selects the Select button; a list of existing profiles is displayed in a new window. The user selects the profile to clone and the Ok button. The Cancel button aborts the current operation.

Table A-2Settings for a new patch profile


Profile Name Text string The name of this patch profile.

Clone Patch profile name A patch profile that has already been added to the system.



Figure A-9Cloning a Patch Profile

If a user decides that the new profile should not clone an existing profile, the user selects the Clear button in the Add Patch Profile window.

Deleting a Patch ProfileTo remove a profile, the user selects the appropriate row and the Delete button. A new window is displayed that warns the user about this action. The user must select Yes to delete the profile; selecting No aborts the current action.

Figure A-10Deleting a Patch Profile


411-5221-926 Standard 10.07 June 2006

To remove a profile, the profile must not be applied to a device. If the profile is applied to a device, the profile is not removed and an error window is displayed. The user selects Ok to close this window.

Figure A-11Delete Patch Profile Failure

Editing a Patch ProfileTo add patch rules to a profile, the user selects the appropriate row and the Edit button; the user can also double-click the appropriate row. A new window is displayed. This window contains a pull-down menu for all loads that have patches accepted into the system. In order for a patch to be applied, the “patchable load” for the patch must match the first set of characters of the load name on the SSG; for example, patches with a “patchable load” of “loadname2.0” would be applied to an SSG with a load name of “loadname2.0-XYZ”. If rules have been created for the load, the rules are also displayed.



Figure A-12Editing a Patch Profile

Adding Patch Rules to a Patch ProfileTo create several new rules for a profile, the user selects the load for the patch and selects the Add button. A new window is displayed. To create the new rules, the user selects the patch records that will be added to the profile and enters all data and selects the Ok button. Each of the selected patch records will be added to the profile as a newly created patch rule. The user can cancel the action by selecting the Cancel button.


411-5221-926 Standard 10.07 June 2006

Figure A-13Adding some Patch Rules to a Patch Profile



Patch Rule Prefix Text string The prefix of the names of the patch rules. It will be automatically added before the patch record name to generate the patch rule name for the relative patch record added to this profile.

Patch List Selected Patch records

The names of the selected patches that have been accepted into the system and will be added to a patch profile.



Slot Scope All SlotsSlot 1Slot 2Slot 3Slot 4Slot 5Slot 6Slot 7Slot 8Slot 9Slot 10Slot 11Slot 12Slot 13Slot 14

This field determines the slot where the selected patches should be applied.

If “All Slots” is selected, the patches are applied on all applicable slots; based on the target field in the patch records, the patching system determines where a patch can be applied.

By selecting “Slot 1” through “Slot 14”, the user can pick the slot where the patches should be applied. Multiple slots can be selected; for example, the user could select “Slot 1”, “Slot 5” and “Slot 13”.

Port Scope All PortsPort 1Port 2Port 3Port 4

This field determines the port where the patches should be applied.

If “All Ports” is selected, the patches are applied on all applicable ports; based on the target field in the patch records, the patching system determines where a patch can be applied.

By selecting “Port 1” through “Port 4”, the user can pick the port where the patches should be applied. Multiple ports can be selected; for example, the user could select “Port 1” and “Port 3”.

Directive Non-activatable

Deactivate

Activate

This field determines the state for all the selected patches; the field can be changed based on the patches type. GEN and DBG patches are “Non-activatable” patches; this field cannot be edited for GEN and DBG patches. ACT patches can be set to “Deactivate” and “Activate”. If there is at least one patch of the ACT type in the selected patches, this field can be set to “Deactivate” and “Activate”. Otherwise, if all of the selected patches are of the GEN or DBG type, this field cannot be edited and set as “Non-activatable”




411-5221-926 Standard 10.07 June 2006

To select the patches, the user clicks the Select button; a new window is displayed.

Figure A-14Selecting a Patch

The user selects the appropriate patches and the Ok button; selecting the Cancel button aborts the current action. And the user can reopen this dialog to select more patches, the patches that have been selected and listed in the ‘Add Patch Rule’ dialog will not be listed here any more. And the patches that have been unselected in the ‘Add Patch Rule’ dialog will be listed again to give the user another opportunity to reselect them.

By clicking Select button again, the user can add more patches that have not been selected to the profile. This action may cause the change of the status of the Directive, based on the types of the patches in the selected list.

By selecting the selected patches and clicking Unselect button, the user can remove some patches from the list of selected. This action may cause the change of the status of the Directive, based on the types of the patches in the selected list.

If the user clicks the Select button more than once and resets the configurations, the current settings after his last selection will be used to all of the selected patches.

Particularly, for the directive setting, when there is any one of the selected patches is of the ACT type, the directive combo box is editable. But the settings of directive can only be applied to the patches of the ACT type in the selected patches, the patches of the other types will ignore this setting and use non-activatable directly.



After the user clicks OK button, all the selected patches will be respectively added to the patch profile one by one, with each one as a separate patch rule. Errors may occur during the course and they will be displayed in a error message dialog. After the user clicks the OK button of the dialog box, this patch rule fails to be added, but the patching system will continue to handle the rest of the selected patches if there is any.

The following errors can occur:

• Patch rules have not been created for the prerequisite list.

• The mutually exclusive list has been violated.

• A patch rule with the selected patch record has already been created for the selected slot or selected port.

Deleting a Patch Rule from a Patch ProfileTo delete a patch rule, the user selects the rule to be deleted and the Delete button. The user is warned about this action. The user must select the Yes button in order for this action to occur; once selected, the action is taken and the rule is removed from the profile. Selecting No aborts the current action.

Figure A-15Deleting a Patch Rule

The following errors can occur:

• The patches that define a patch as a prerequisite have not been deleted.

Editing a Patch Rule for a Patch ProfileTo modify an existing patch rule, the user selects the Edit button or double-clicks the patch rule. Editing a patch rule is similar to creating a patch rule; the table below defines the differences.


411-5221-926 Standard 10.07 June 2006

Figure A-16Editing a Patch Rule for a Patch Profile

Table A-4Editing a patch profile


Patch Rule Name Not Editable The name of this patch rule.

Patch Name Not Editable The name of a patch that has been accepted into the system.



Slot Scope All SlotsSlot 1Slot 2Slot 3Slot 4Slot 5Slot 6Slot 7Slot 8Slot 9Slot 10Slot 11Slot 12Slot 13Slot 14

This field determines the slot where the patch should be applied.

If “All Slots” was selected when the rule was created, this field is not editable.

Any slot that was selected when the rule was created is not editable; the user cannot remove slots from a rule.

The user can select “All Slots” to apply the patch to all applicable slots; based on the target field in the patch record, the patching system determines where a patch can be applied.

By selecting “Slot 1” through “Slot 14”, the user can pick the slot where the patch should be applied. Multiple slots can be selected; for example, the user could select “Slot 1”, “Slot 5” and “Slot 13”.

Port Scope All PortsPort 1Port 2Port 3Port 4

The following rules must be followed to change the port scope for a patch rule.

If “All Ports” was selected when the rule was created, this field is not editable.

Any port that was selected when the rule was created is not editable; the user cannot remove ports from a rule.

The user can select “All Ports” to apply the patch to all applicable ports; based on the target field in the patch record, the patching system determines where a patch can be applied.

By selecting “Port 1” through “Port 4”, the user can pick the port where the patch should be applied. Multiple ports can be selected; for example, the user could select “Slot 1”, “Slot 5” and “Slot 13”.




411-5221-926 Standard 10.07 June 2006

The following error can occur:

• A patch rule with the selected patch record has already been created for the selected slot or the selected slot’s port.

Device TabThe device tab gives the user the ability to display patch information for devices, to apply/remove/override patch profiles and to verify that a profile can be added to a device. It also allows the user to query patch information for a device and to sync patch data for a device.

When the user selects the device tab from the patch manager, a list of known regions is displayed. When the user selects a region, the devices for that region are displayed along with the patch profile that has been applied to the device. If a profile has not been applied to a device, the device column contains the name of the device and the corresponding profile column has a - (a dash) in it. Note that only one profile can be applied to a device.

Selected Scope Not Editable This field displays the slots and the ports that have been selected for this patch rule. Initially, the slot(s) and the port(s) that were selected when the rule was created are displayed. As more slots and more ports are selected, this field changes to display those slots and ports. If “All Slots” or “All Ports” is selected, these values will be displayed; none of the other slot or port selections will be displayed.

Directive Non-activatable

Deactivate

Activate

This field determines the state for the patch; the field can be changed based on the patch type. GEN and DBG patches are “Non-activatable” patches; this field cannot be edited for GEN and DBG patches. ACT patches can be set to “Deactivate” and “Activate”.





Figure A-17Device Tab

Displaying Device InformationTo display device specific information, the user double-clicks the name of the device. A new window is displayed with a device tree, the available patch memory for each node and patch status information. Note that the device information is only for the current load. The user selects the Close button to close this window.


411-5221-926 Standard 10.07 June 2006

Figure A-18Viewing Data on a Device

The “Sort By” mechanism gives a user the ability to display the patch status information based on the column headers. Possible choices include Default, Patch, Last SCS Action, Last SCS Action Time, Current Status and Current Status Time.



The device tree gives a user the ability to view data for an entire device, for a specific card or for a specific port. As a user navigates the tree, information for the selected item is displayed.

Figure A-19Viewing Data for a Specific Card/Port

Querying Patch Information for a DeviceIf a user wants to query the patch statuses for a particular device, the user selects the query states button. This action queries all of the patch data that is contained on the SSG. An information window is displayed that tells the user


411-5221-926 Standard 10.07 June 2006

where to find the related data. The user selects Ok to close the window. Note that this action is retrieving data from the device. As a result, the action will take time to display the requested information. Moreover, in order to prevent too often queries, which will burden the system unnecessarily, an error message dialog will pop up to indicate that the customer needs to be waiting for a while to issue another action of querying the patch information when the interval between two consecutive such actions is less than 60 seconds.

Figure A-20Query Information Message

Figure A-21Query Failure Message

Syncing Patch Data for a DeviceIf a user wants to sync the patch data from the SCS to a particular device, the user selects the sync states button. This action ensures that all patch actions that are stored in the SCS are in effect on the SSG. An confirm dialog is displayed to tell the user that this action will unapply all the non-persistent pathces and to ask for user’s confirmation. Clicking No button will cancel this operation. If the user clicks the Yes button, an information message is displayed that tells the user where to find the related data if any inconsistencies exist between the SCS and the SSG. The user selects Ok to close the window.



Figure A-22Sync confirm Message

Figure A-23Sync Information Message

Applying a Patch Profile to a DeviceApplying a profile to a device applies all of the patch rules for the selected profile on the specified SSG. The SSG performs the actions that are related to the patch rule.

To apply a profile to a device or to override a profile on a device, the user selects the appropriate row and the Edit button. A new window is displayed for the user. If a profile exists, the profile name is displayed. The user must select the Ok button to cause the action to take place. Selecting the Cancel button aborts the operation.

Figure A-24Edit Button for Patch Device


411-5221-926 Standard 10.07 June 2006

To apply a profile, the user selects the Select button. A new dialog is displayed with all of the available profiles; the user selects the profile and the Ok button. The Cancel button aborts the current operation.

Figure A-25Selecting a Patch Profile for a Device

Optionally, users can verify that a profile can be applied to a device or that a profile can be overridden on a device. This verification ensures that all prerequisites are valid, but it does not apply or override the profile. To perform this action, the user selects the Verify Profile box in the Patch Device Configuration window. The user selects Ok to close this window.

Figure A-26Verifying a Patch Profile

When the user verifies a profile, an information message is displayed indicating where to look for the corresponding data.



Figure A-27Verify Information Message

Deleting a Patch Profile from a DeviceRemoving a profile from a device unapplies all of the patch rules from the device and deletes all of the patch files from the SSG.

To remove a profile from a device, the user selects the appropriate row and the Edit button. A new window is displayed for the user. In this window, the user selects the Clear button. The user must select the Ok button to cause the action to take place. Selecting the Cancel button aborts the operation.

Figure A-28Edit Button for Patch Device

When the user selects Ok, another window is displayed that warns the user about this action. The user must select the Yes button in order for this action to occur; once selected, all actions are taken and the profile is removed from the device. The user can select No to cancel this action.


411-5221-926 Standard 10.07 June 2006

Figure A-29Deleting a Patch Profile from a Device

B-1Nortel Networks Confidential


Detailed Protocol Information BThis 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 ExtensionThis 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 IEOn 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 InformationNortel Networks Confidential

411-5221-926 Standard 10.07 June 2006

Figure B-1The Private Extension IE Format for GTP Version 0

Bits

Octets 158 7 236 4

Type = 255 (Decimal)1

2 -3

4 - 5

6

12

Length

Extension Identifier = 562 (Decimal)

Opcode Type = 2 (Decimal)

Routing Area Code (Optional)

7 Mobile Country Code

13 - 14

10 - 11

9

8Mobile Network Code

Location Area Code

Cell Identity

means optional field

Detailed Protocol Information B-3Nortel Networks Confidential


Figure B-2The Private Extension IE Format for GTP Version 1

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

Bits

Octets 158 7 236 4

1

2 -3

4 - 5

6

7

12

10 - 11

9

8

Type = 255 (Decimal)

Length

Extension Identifier = 562 (Decimal)

Opcode Type = 3 (Decimal)

Routing Area Code (Optional)

Mobile Country Code

Mobile Network Code

Location Area Code

Service Area Code

means optional field

13 - 14


411-5221-926 Standard 10.07 June 2006

Table B-1IPv4 mapped IPv6 P-CSCF Address format

Table B-2IPv4 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 address Ind

0xFF

0xFF

IPv4 Address 0xXX

0xXX

0xXX

0xXX

PCO Field Value

Container ID (P-CSCF Address) 0x00

0x01

Length (4 bytes) 0x04



GTP’ Charging ProtocolThe 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 FormatThe 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-3G-CDR Fields and Descriptions for 32.015 version 3.2.0

IPv4 Address 0xXX

0xXX

0xXX

0xXX

Field Description Encoding Format

Size (Bytes)

Record Type M GGSN PDP Context Record Integer 1 - 4

Network Initiated PDP Context

C Present if this is a network initiated PDP context

Served IMSI M IMSI of the served party (if Anonymous Access Indicator is FALSE or not supplied).

BCD-encoded Octet String

3 - 8

Served MSISDN

O The primary MSISDN of the subscriber. NPI+NOA is in the first octet of this field.


1 - 9


411-5221-926 Standard 10.07 June 2006

GGSN Address

M IP address of the GGSN used. Hex-value Octet String

4

Charging ID M PDP context identifier used to identify this PDP context in different records created by GSNs.

Unsigned Integer

1 - 4

SGSN Address

M List of SGSN addresses used during the open lifetime of the record

Hex-value Octet String

4 bytes per address

Access Point Name Network Identifier

M The logical name of the connected access point to the external packet data network (network identifier par of APN).

IA5 String 1 - 63

APN Selection Mode

O An index indicating how the APN was selected. Unsigned Integer

1- 4

PDP Type M PDP type, i.e. IP or PPP Hex-value Octet String

2

Served PDP Address

M PDP address, i.e. IPv4. Hex-value Octet String

4

Dynamic Address Flag

C Indicate whether served PDP address is dynamic, which is allocated during PDP context activation.

Boolean 1

List of Traffic Data Volumes

M A list of changes in charging conditions for this PDP context, each time stamped.

Table B-7

Record Opening Time

M TimeStamp when this record was opened. BCD-encoded Octet String

9

Duration M Duration of this record in the GGSN. Integer 1 - 4

Cause of Record Closing

M The reason for the release of record from this GGSN.

Integer 1 - 4

Diagnostics O A more detailed reason for the release of the connection.

Record Sequence Number

C Partial record sequence number, only present in case of partial records.

Integer 1 - 4


Size (Bytes)



Table B-4G-CDR fields and descriptions for 32.015 version 3.6.0

Node ID O Name of the recording entity.

Record Extensions

O A set of network/manufacturer specific extensions to the record.

Table B-9 variable in size

Local Record Sequence Number

O Consecutive record number created by this node.The number is allocated sequentially including all CDR types.

Unsigned Integer

1 - 4

Charging Characteristics

C The Charging Characteristics flag retrieved from subscriber’s data as described in subclause 6.1.6.2a


1


Size(Bytes)

Record Type M GGSN PDP Context Record Integer 1 - 4

Network Initiated PDP Context

C Present if this is a network initiated PDP context



3 - 8

Served MSISDN

O The primary MSISDN of the subscriber. NPI+NOA is in the first octet of this field.


1 - 9

GGSN Address

M IP address of the GGSN used. Hex-value Octet String

4


Unsigned Integer

1 - 4

SGSN Address



4 bytes per address



IA5 String 1 - 63


Size (Bytes)


411-5221-926 Standard 10.07 June 2006

APN Selection Mode

O An index indicating how the APN was selected. Unsigned Integer

1 - 4

PDP Type M PDP type, i.e. IP or PPP Hex-value Octet String

2

Served PDP Address

C PDP address, i.e. IPv4. Hex-value Octet String

4



Boolean 1



Table B-7

Record Opening Time

M TimeStamp when this record was opened. BCD-encoded Octet String

9

Duration M Duration of this record in the GGSN. Integer 1 - 4



Integer 1 - 4

Diagnostics O A more detailed reason for the release of the connection.



Integer 1 - 4

Node ID O Name of the recording entity.

Record Extensions


Table B-9 variable in size



Unsigned Integer

1 - 4


C The Charging Characteristics flag retrieved from subscriber’s data as described in subclause 6.1.6.5


2


Size(Bytes)



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-5Subsequent Partial G-CDR Billing Record Fields for version 3.2.0

Field Description

Record Type M GGSN PDP Context Record


Served MSISDN

C The primary MSISDN of the subscriber.

GGSN Address

M IP address of the GGSN used.


SGSN Address

M Access Point Name Network Identifier



APN Selection Mode

C An index indicating how the APN was selected.

PDP Type M PDP type, i.e. IP or PPP

Served PDP Address

M PDP address, i.e. IPv4





Record Opening Time

M TimeStamp when this record was opened.

Duration M Duration of this record in the GGSN.


411-5221-926 Standard 10.07 June 2006

Table B-6Subsequent Partial G-CDR Billing Record Fields for 32.105 version 3.6.0





Record Extensions





C The Charging Characteristics flag retrieved from subscriber’s data as described in subclause 6.1.6.2a

Filed Description

Record Type M GGSN PDP Context Record


Served MSISDN

C The primary MSISDN of the subscriber.

GGSN Address

M IP address of the GGSN used.


SGSN Address




APN Selection Mode

C An index indicating how the APN was selected.

PDP Type M PDP type, i.e. IP or PPP

Field Description



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-7G-CDR Traffic Data Volume Container

Served PDP Address

C PDP address, i.e. IPv4





Record Opening Time

M TimeStamp when this record was opened.

Duration M Duration of this record in the GGSN.





Record Extensions





C The Charging Characteristics flag retrieved from subscriber’s data as described in subclause 6.1.6.5

Field Description Format Size (Bytes)

QoS Requested

O Quality of Service Requested.

Filed Description


411-5221-926 Standard 10.07 June 2006

Note: 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-8Best Effort Values

QoS Negotiated

O Quality of Service Negotiated. The size of this 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.

QoS Type 4 - 36

Uplink Data Volume

M Uncompressed data count (octets) received from Gn interface.

Integer 1 - 4

Downlink Data Volume

M Uncompressed data count (octets) send to Gn interface.

Integer 1 - 4

Change Condition

M Condition for closing the container Unsigned Integer

1 - 4

Change Time M Timestamp when new volume counts are started or CDR is closed


9

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 Downlink

0 kbps

Field Description Format Size (Bytes)



G-CDR Management ExtensionsTable 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-9Management Extension Format

CBB Management ExtensionsCBB Version 2Table 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

Field Description Notes Sub-Field Format Size

ObjectID Identifier of Management Extension

The length and value sub-fields comprise the objectid field.

Length of ObjectID

Unsigned Integer

2 bytes

Value ASCII string

11 bytes

Significance Indicates if field must be understood by receiver

Significance Boolean 1 byte

Information Contains information section of the management extension

This field will vary in length. It will begin with a tag type and the length of the information followed by the information.


411-5221-926 Standard 10.07 June 2006

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-10CBB Version 2 Information field detailed description

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:

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length

3 Reserved Rate Container

4 Uplink byte count

5

6

7

8 Downlink bye count

9

10

11



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


411-5221-926 Standard 10.07 June 2006

CBB Version 3The ObjectID field for CBB Version 3 is “1.2.840.113533.4.10.1.1.3”. 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-11CBB Version 3 Information Field

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:

Octets

Bits

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

5

6 Uplink Count

7

8

9

10 Downlink Count

11

12

13



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 4Version 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-12CBB version 4 management extension

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length



411-5221-926 Standard 10.07 June 2006

Time Usage

• The time usage field contains the total usage time for the specified context typeid in seconds.

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


4 Content Type ID

5

6 Uplink Count

7

8

9

10 Downlink Count

11

12

13

14 Time Usage

15

16

17



1D = the length of the information in 29 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 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 5Version 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-13CBB version 5 management extension

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length


411-5221-926 Standard 10.07 June 2006

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.

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.


4 Content Type ID

5

6 Uplink Count

7

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



The bytes from 4 to 23 can be repeated up to 6 times within a container. Furthermore we can have up to 4 containers in CBB management extension. Once a PDP session uses 7 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 6 unique content type IDs accessed while the corresponding traffic volume container was open. The 7th 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 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)



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.


411-5221-926 Standard 10.07 June 2006

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 6New 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-14CGF CBB Management Extension version 6

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length


4 Content Type ID

5

6 Uplink Count

7

8

9

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 27 can be repeated up to 5 times within a container. Furthermore we can have up to 4 containers in CBB management extension. Once a PDP session uses 6 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 5 unique content type IDs accessed while the corresponding traffic volume container was open. The 6th rate will be included in the next partial record generated.

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)


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


411-5221-926 Standard 10.07 June 2006


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 ExtensionsWhen 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 NameShasta 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-15Shasta Service Profile Information Field

Example:

All values are in hex

Given the service profile name “ip_service_profile_1”

Octets

Bits

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)


411-5221-926 Standard 10.07 June 2006

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 NameTable B-16VPN Profile Information Field

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

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x16

2 Length

3-18 SHASTA-VPN (up to 16 characters of VPN name)



Table B-17Shasta Prepaid Profile Information Field

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 AddressTable B-18Tunnel Server Endpoint IP Address Information Field

Octets

Bits

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)

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length

3 Tunnel Server Endpoint IP Address [3]




411-5221-926 Standard 10.07 June 2006

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 VSAIf 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-19Transparent Data VSA Information Field Description

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

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length

3 - 249

Transparent Data VSA (up to 247 bytes)


411-5221-926 Standard 10.07 June 2006

Table B-20IMEISV in G-CDR

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 IMEISV07 = TAC4, TAC3 digits of IMEISV06 = TAC6, TAC5 digits of IMEISV05 = TAC8, TAC7 digits of IMEISV04 = SNR2, SNR1 digits of IMEISV03 = SNR4, SNR3 digits of IMEISV02 = SNR6, SNR5 digits of IMEISV01 = SVN2, SVN1 digits of IMEISV

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

Octets

Bits

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



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-21RAT Type management extension

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 binaryUnknown 00UTRAN 01

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x02

2 Length = 1

3 RAT Type for container #4

RAT Type for container #3




411-5221-926 Standard 10.07 June 2006

GERAN 10WLAN 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 IdentifierPLMN 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-22PLMN in G-CDR

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length (3 * number of PLMN entries)

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.

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#143 = MNC1, MCC3 of PLMN Identifier#165 = MNC3, MNC2 of PLMN Identifier#132 = MCC2, MCC1 of PLMN Identifier#254 = MNC1, MCC3 of PLMN Identifier#276 = 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.

Octets

Bits

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)


411-5221-926 Standard 10.07 June 2006

HSDPANortel 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-23 for the example of HSDPA management extension.

Table B-23HSDPA management extension

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

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length = 1-13

3 Container Indicator

4 - 6 HSDPA information Container # 1

7-9 HSDPA information Container #2





Note: 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 MeterParking Meter management extension 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 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-24.

Table B-24Parking Meter Management extension

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.

Octets

Bits

8 7 6 5 4 3 2 1

1 Tag = 0x04

2 Length (0x1A)

3 Container ID Number of Parking Meters for the container

4-5 Parking Meter Content Type

6-9 Parking Meter Start timestamp

10-11 Parking Meter Duration (in seconds)


411-5221-926 Standard 10.07 June 2006

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 this example, the value is 286331440 seconds after January 1,1970 UTC

• 05 30 - duration for parking meter

DCC EventsThis 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-25DCC Event Cause Codes

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.

DCC Event Event Code

The GGSN receives a Diameter CC Not Applicable result code from the Diameter CC server following a CCR Initial and when RulebaseID AVP is ABSENTa

a. If RulebaseID AVP is present, then the new management extension with the event code will NOT appear in the G-CDR.

1

The GGSN terminates the subscriber's PDP context due to failure handling procedures (i.e. Terminate or Retry and Terminate behavior)

5

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

6

The GGSN converts the subscriber's PDP context to non-prepaid, such as after receiving a Diameter CC Not Applicable, due to failure handling procedures (i.e. Continue behavior) following a CCR Update

10

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)

15

The GGSN terminates the subscriber's PDP context as directed by the reception of an Abort Session Request from the Diameter CC server

20

The GGSN receives a User Unknown result code from the Diameter CC server 25


411-5221-926 Standard 10.07 June 2006

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-26GGSN Event Diagnostic in G-CDR

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’


Octets

Bits

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

5

6

7

8 Timestamp

9

10

11




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

The format of the ULI Management Extension is shown in Table B-27.

Table B-27ULI Management Extension in G-CDR

OctetsBits

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


411-5221-926 Standard 10.07 June 2006

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-3Example of ULI in G-CDR

Note: 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 formatThe 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:

7LAC

8

9CI / SAC

10

OctetsBits

8 7 6 5 4 3 2 1

CGI: MCC=123MNC=456LAC=0011CI = 0022

04 08 00 21 63 54 00 11 00 22

Tag = Octet String

MCC = 123

MNC = 456

LAC = 0011CI = 0022

Geo. Loc. Type = CGI

Length



YY Year 00 to 99 BCD encodedMM Month 01 to 12 BCD encodedDD Day 01 to 31 BCD encodedhh hour 00 to 23 BCD encodedmm minute 00 to 59 BCD encodedss second 00 to 59 BCD encodedS Sign 0 = “+”, “-” ASCII encodedhh hour 00 to 23 BCD encodedmm 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 VolumeThe 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 FileThe 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


411-5221-926 Standard 10.07 June 2006

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-28Billing Disk File Header Format

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.

Octets

Bits

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)



• 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-29Billing Disk File Record Format

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 DiskCGF Communication FailureIf 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.

Octets

Bits

8 7 6 5 4 3 2 1

1 - 4 Length (value = n-4 octets)

5 - n Encoded G-CDR Record


411-5221-926 Standard 10.07 June 2006

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

• Log into the Gn or Ga ISP using the SCS Client GUI

• From the Access Properties Manager, select CGF Profiles

• Select the Add button

• 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

• Select OK to accept the CGF profile. The following warning will be displayed

• Select Yes to complete the creation of the CGF Profile

• From the Access Properties Manager, select GTP’ Profiles

• Select the Add button

• Click on the Select button next to the CGF field for a list of available CGF Profiles.

• Select the CGF Profile that was just created

• 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

• Click OK to complete the configuration

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 SwitchoverThere 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 as discussed in section 3.3.6.1.6. In these cases, it will be necessary to pull the billing files manually as discussed under “Manual G-CDR File Retrieval” in section 3.3.6.1.6. 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 ProtocolPlease refer to NTP 411-5221-928, Nortel GGSN RADIUS Interface Guide, for detailed information regarding RADIUS protocol interface on the Nortel GGSN. The RADIUS protocol interface is used for RADIUS authentication and RADIUS accounting,


411-5221-926 Standard 10.07 June 2006

WRAP ProtocolRFC Attributes

This section specifies the RFC attributes used in the WRAP protocol.

Table B-30RFC WRAP protocol attributes

Type Attribute Name Description1 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, INTERIM44 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 AttributesThe 3GPP vendor ID is 10415 and all 3GPP attributes are defined using the vendor specific attribute type 26 described in Table B-31.

Card Telephony Protocol (CTP)There are three versions of GGSN CTP protocol detailed below.

The first version is the Basic Single-Coupon service which uses Card Telephony Protocol (CTP) protocol version 1 to provides a simple Prepaid service. The second version is the Enhanced Single-Coupon service which uses CTP protocol version 2 to add QoS and Content-Based Billing (CBB) information to the billing reports. The third version is the Multi-Coupon service. Each version of the prepaid service relies on a corresponding version of the CTP protocol to communicate with the Prepaid Server. GeoZone and GPDN Range Checking are supported for the first two versions, but not for prepaid version 3.

The communication between the Nortel GGSN and the Prepaid Server is based on a proprietary TCP/IP protocol called CTP.

Table B-313GPP WRAP protocol attributes

Vendor Type

Attribute Name Description

1 3GPP-IMSI The IMSI of the subscriber mobile.5 3GPP-GPRS-QoS-

ProfileQoS profile received.

6 3GPP-SGSN-Address

SGSN IP address that is used by the GTP 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-Stop-Indicator

Indicate the end of the PDP session. A value of 0xFF is passed and it is for STOP message only.

13 3GPP-Charging-Characteristics

Contains the charging 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.


411-5221-926 Standard 10.07 June 2006

Basic Single-Coupon Prepaid ServicePrepaid 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 InformationThe 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 & CTPv2 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 SessionsWhen 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 TimerA 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 both CTP version 1 and 2. CTP version 3 has similar functionality, but it exists as part of the coupon definition instead of being specified in the SCS GUI.

Enhanced Single-Coupon Prepaid ServiceThe prepaid version 2 is closely based on prepaid version 1 to include additional functions. Prepaid billing is able to interact with Content Based



Billing (CBB) with limitations dependent upon the version of CTP being used. For CTP version 1, it is not possible to support coupon IDs for prepaid subscribers except for free and full. All packets which are identified as rate zero are free. These packets are not tallied against the PDP session and are not reported to the Prepaid Server. All other packets, including packets marked with a Coupon ID other than zero, are reported to the Prepaid Server and are charged at full rate. For CTP version 2, the Resources Consumed is still all bytes excluding the zero rate packets. CTP version 2 allows the reporting of counts for various coupon ids.

The existing prepaid service is modified to support optional enhancements. These enhancements include sending the negotiated QoS Profile in CTP request messages as well as reporting a count of resources consumed for up to 4 prepaid coupon IDs (i.e. couponIDs 1 to 4). Any data marked as a coupon ID 5 or greater are not included in the report of CBB counts, but are included in the total byte count. In addition, coupon timeout is added for volume based prepaid to force periodic re-authorizations. These extensions are options which are provisionable via the SCS GUI.

Volume Coupon TimeoutA re-authorization timer has been added to 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 both CTP version 1 and 2.

Multi-Coupon Prepaid ServicePrepaid version 3 along with the CTP protocol version 3 builds on the top of previous two versions to provide multi-coupon prepaid service. 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. Prepaid 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 previous CTP versions.

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)


411-5221-926 Standard 10.07 June 2006

• 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. The Negotiated QoS introduced in CTP version 2 is supported in this version as well. All prepaid time measurements rounded to the nearest second. The following subsections explain the basic version 3 behavior.

Non-Rated CouponPrepaid 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 (unlike prepaid version 1 and 2). 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 CouponThe 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.


411-5221-926 Standard 10.07 June 2006

Coupon Include ReasonThe 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.

TriggersTriggers 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-32Valid trigger actions for various trigger scenarios

Trigger Type Coupon Type Coupon Timing Trigger Action

QoS Change Rated Re-Authorize Coupon

Valid

Return Coupon InvalidUse tariff change coupon

Invalid

Non-Rated Re-Authorize Coupon

Valid


Invalid



SGSN Address Change

Rated Re-Authorize Coupon

Valid


Invalid


Valid


Invalid

Idle Coupon Timeout


Invalid

Return Coupon ValidUse tariff change coupon

Invalid


Invalid


Invalid

Coupon Absolute Lifetime


Valid


Invalid


Valid


Invalid

Coupon Relative Lifetime


Valid


Invalid


Valid


Invalid




411-5221-926 Standard 10.07 June 2006

Transparent DataThe 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 NameThe 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-Authorization Threshold


Valid


Invalid


Valid


Invalid

Tariff Time Change


Invalid


Valid


Invalid


Invalid

RAT Change Rated Re-Authorize Coupon

Valid


Invalid


Valid


Invalid





• 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 StampThe 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-4Message Flow with ToD Event

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.

Prepaid Server

T

GGSN

Initial Auth Response

2

or Re-auth Response

T1

T3

ToD Event:S1

S2

Initial Auth Requestor Re-auth Request

Coupon allocationtime for

ToD Time = 12:00:00S1 = 12:00:00S2 = 11:59:59

11:59:59

12:00:00


411-5221-926 Standard 10.07 June 2006

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.

Diameter Credit Control (DCC) protocolIETF 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 EstablishmentThe 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 SessionThe 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.


411-5221-926 Standard 10.07 June 2006

Diameter Credit Control Session Flow with Service RedirectThe 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 ModelParking 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 received in the MSCC AVP defines Parking Meter duration for that rating group. The GGSN supports reception of a maximum of 40 MSCC AVPs in CCNA CCA(I).

Diameter Credit Control Failure HandlingThe 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 AVPsDCC 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 ProcedureConceptually, 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.


411-5221-926 Standard 10.07 June 2006

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-33Session Failure Handling

Event Failover Supported

CCFH Action

Tx expires Yes/No TERMINATE Terminate the PDP context

CONTINUE

RETRY_AND_TERMINATE

Grant service to current rating group

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



Note: 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-34Roared Reply Handling

Yes TERMINATE

CONTINUE

RETRY_AND_TERMINATE

Retry the request on alternative DCC server

Tr expires Yes/No TERMINATE

RETRY_AND_TERMINATE



Any late reply will be ignored

Return Result Code

Failover Supported

CCFH Action

Temporary Failures Yes TERMINATE

CONTINUE

RETRY_AND_TERMINATE

Send the request to alternative DCC server

No TERMINATE

RETRY_AND_TERMINATE


Event Failover Supported

CCFH Action


411-5221-926 Standard 10.07 June 2006

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.


Permanent Failures

(except for USER_UNKNOWN)

Yes/No TERMINATE

RETRY_AND_TERMINATE



USER_UNKNOWN Yes/No TERMINATE

CONTINUE

RETRY_AND_TERMINATE


Return Result Code

Failover Supported

CCFH Action



Table B-35DCC Agent Type and DCC Failover

Diameter Tx Expiry EventThe 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 SessionUpon 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

Agent Type of Current DCC Peer

Agent Type of Next DCC Peer

CC-Session-Failover Failover

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


411-5221-926 Standard 10.07 June 2006

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 SupportThe 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-5IPSec Tunnels in Diameter Network

IPSec Tunnels notGGSN Configured

DiameterServer

DiameterProxy

DiameterRelay

GGSN

IPSec TunnelsConfigured by GGSN



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 ControlDynamic coupon behavior configured by DCC server via AVPs are supported. All such AVPs are discussed in this section.

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


411-5221-926 Standard 10.07 June 2006

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 ThresholdQuota 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-36Effect of Default Quota Threshold Trigger

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.

Default Quota Threshold Trigger

Quota Threshold AVP 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


411-5221-926 Standard 10.07 June 2006

Quota Idle TimeThe 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 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 Inactivity TimeThe 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.

Validity TimeValidity 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 ChangeThe 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


411-5221-926 Standard 10.07 June 2006

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-37Tariff Change and ToD

ToD Configured Tariff Change AVP Included in CCA

Tariff Change Schedule

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

C-1Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


List of terms CAF

Assured forwarding

APNAccess Point Name

APSAutomatic Protection Switching

ARPAddress Resolution Protocol

ASMActive Session Management

BGBorder Gateway

BSNBroadband Service Node

CBBContent Based Billing

CCFHCredit Control Failure Handling

CCACredit Control Answer

CCRCredit Control Request

CGFCharging Gateway Function

C-2 List of termsNortel Networks Confidential Copyright © 2000–2006 Nortel Networks

411-5221-926 Standard 10.07 June 2006

CGICell Global Identification

CHAPChallenge Handshake Authentication Protocol

CLICommand Line Interface

CMCControl and Management Card

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

CORBACommon Object Request Broker Architecture

CSVComma Separated Values

CTPCard Telephony Protocol

DCCDiameter Credit Control

DHCPDynamic Host Configuration Protocol

DNSDomain Name Service

DSCPDiffServ Code Point

ECMPEqual Cost Multi-Path

FTPFile Transfer Protocol

List of terms C-3Nortel Networks Confidential Copyright © 2000–2006 Nortel Networks


G-CDRGGSN Call Detail Record

GERANGPRS EDGE Radio Access Network

GGSNGateway GPRS Support Node

GPRSGeneral Packet Radio Service

GREGeneric Routing Encapsulation

GSMGlobal System for Mobile communications

GSNGPRS Support Node

GTPGPRS Tunneling Protocol

GTP-CGTP Control - This protocol tunnels signalling messages between SGSNs and GGSNs, and SGSNs, in the backbone network.

GTP-UGTP User - This protocol tunnels user data between GPRS Support Nodes in the backbone network. All PDP PDUs are encapsulated by the GPRS Tunneling Protocol.

HLRHome Location Register

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

HPLMNHome Public Land Mobile Network


411-5221-926 Standard 10.07 June 2006

HTTPHypertext Transfer Protocol

IMAP4Internet Message Access Protocol - Version 4rel1

IMEI-SVInternational Mobile Equipment Identity - Software Version

IPInternet Protocol

IPCPIP Control Protocol

IPSecIP Security Protocol

IRIInterception Related Information

ISPInternet Service Provider

L2TPLayer 2 Tunneling Protocol

LACL2TP Access Concentrator

LACLocation Area Code

LCPLink Control Protocol

LDAPLightweight Directory Access Protocol

LNSL2TP Network Server

MCCMobile Country Code



MEMobile Equipment

MMSMultimedia Messaging Service

MNCMobile Network Code

MSMobile Station

NBNSNetBIOS Name Server

NCPNetwork Control Protocol

NNDCCNortel Networks Diameter Credit Control

NSAPINetwork Service Access Point Identifier

OSSOperations Support System

PAPPassword Authentication Protocol

PCOProtocol Configuration Options

PDNPacket Data Network

PDPPacket Data Protocol

PDUProtocol Data Unit

PLMNPublic Land Mobile Network


411-5221-926 Standard 10.07 June 2006

PNPPersonal Network Portal

POP3Post Office Protocol Version 3

PPPPoint-to-Point Protocol

QoSQuality of Service

RACRouting Area Code

RADIUSRemote Authentication Dial In User Service

RATRadio Access Technology

SAIService Area Identifier

SCPService Control Point

SCSService Creation System

SFCSwitch Fabric Card

SGSNServing GPRS Support Node

SER 5500 GGSNServices Edge Router 5500 with GGSN functionality

SMPShasta Management Protocol

SMTPSimple Mail Transfer Protocol



SNMPSimple Network Management Protocol

SNRSerial Number

SNTPSimple Network Time Protocol

SSCSubscriber Service Card

SSGSubscriber Service Gateway

SSHSecure Socket Shell

SSLSecure Socket Layer

SSMSubscriber Service Module

SSPSubscriber Service Processor

SMPSER 5500 Management Protocol

SNMPSimple Network Management Protocol

SNTPSimple Network Time Protocol

SSHSecure Socket Shell

SSLSecure Socket Layer

SSMSubscriber Service Module


411-5221-926 Standard 10.07 June 2006

SVNSoftware Version Number

TACType Allocation Code

TETerminal Equipment

ToDTime of Day

TOS Type of Services

T-PDUPayload that is tunnelled in the GTP tunnel

TPO Traffic Performance Optimizer

UDP User Datagram Protocol

UMTSUniversal Mobile Telecommunication System

URLUniform Resource Locator

UTCUniversal Time Coordinated

UTRANUMTS Terrestrial Radio Access Network

VPLMNVisiting Public Land Mobile Network

VPNVirtual Private Network

VPRNVirtual Private Routing Network



VSAVendor Specific Attribute

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

WAEWireless Application Environment

WAPWireless Application Protocol

WLANWireless Local Area Network

WRAPWireless RADIUS Application Protocol

WSPWireless Session Protocol

WTLSWireless Transport Layer Security

WTPWireless Transaction Protocol

WVWireless Village


411-5221-926 Standard 10.07 June 2006

test

Family Product Manual Contacts Copyright Confidentiality Legal


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

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

Copyright © 2000–2006 Nortel Networks, All Rights Reserved

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

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

* Nortel Networks, the Nortel Networks logo, the Globemark, Unified Networks, SCS, Service Creation System, Shasta 5000 BSN, SER 5500, BSN, iSOS, and system 5000 are trademarks of Nortel Networks.All other trademarks and registered trademarks are the property of their respective owners.

Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.

Document number: 411-5221-926Product release: GGSNS5.0Document version: Standard 10.07Date: June 2006Originated in the United States of America/Canada

Date post:	26-Dec-2014
Category:	Documents
Upload:	anthony-dyce
View:	338 times
Download:	24 times

Nortel GGSN User Guide 411-5221-926.10.07

Documents