411-5221-955.08.08 SGSN User Guide

411-5221-955
GPRS
Nortel SGSN/GPRS
User Guide
GPRS6.0 Standard 08.08 October 2005 411-5221-955.08.08
What’s inside...
About GPRS
About the SGSN
SGSN hardware
Reliability
Services and features
Accounting
Operations, administration, and maintenance
Software management
Technical specifications and conformances
Engineering rules
SGSN parameters
Single slot 32-Port MSA cabling
test
GPRS
Nortel SGSN/GPRS
User Guide
Document number: 411-5221-955

Product release: GPRS6.0
Document version: Standard 08.08
Date: October 2005
Copyright Country of printing Confidentiality Legal statements Trademarks
Copyright  1999–2005 Nortel Networks, All Rights Reserved

Originated in the United States of America
NORTEL NETWORKS CONFIDENTIAL
The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in
writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees
with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree
of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in
writing by Nortel Networks, the holder is granted no rights to use the information contained herein.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as
progress in engineering and manufacturing may warrant.
NORTEL, NORTEL NETWORKS, the globemark design, and the NORTEL corporate logo are trademarks of Nortel.GSM is a
trademark of GSM MOU Association.
Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
ii
Nortel Networks Confidential Copyright  1999–2005 Nortel Networks
411-5221-955 Standard 08.08 October 2005

iii
Publication history
October 2005
GPRS6.0, 08.08. This Standard version is updated for Change Requests
(CRs).
July 2005
GPRS6.0, 08.07. This Standard version contains technical changes for the
GPRS6.0 Channel Ready release.
May 2005
GPRS6.0, 08.06. This Preliminary version incorporates technical review
comments.
May 2005
GPRS6.0, 08.05. This Preliminary version includes a new appendix,
Appendix D, “Single slot 32-Port MSA cabling”.
May 2005
GPRS6.0, 08.04. This Preliminary version contains technical changes for the
GPRS6.0 release. Other changes include:
• Replaced “Nortel Networks” with “Nortel.”
• Added chapter “Reliability” and moved sections on redundancy and
overload controls into the new chapter.
• Added Appendix C, “SGSN parameters”.
February 2005
GPRS6.0 release.
January 2005
GPRS6.0, 08.02. This Preliminary version is updated for the GPRS6.0
Customer Ready release.
GPRS Nortel SGSN/GPRS User Guide GPRS6.0

iv Publication history
November 2004
GPRS6.0 release.
October 2004
GPRS5.0, 07.05. This version includes a new appendix, Appendix C, “SGSN
parameters”.
July 2004
GPRS6.0, 08.01. This Draft version is updated for the GPRS6.0 release. The
title of this document is changed from GPRS Passport 15000-VSS with SGSN
Functionality User Guide to Nortel Networks SGSN/GPRS User Guide.
October 2003
GPRS5.0, 07.04. This Standard version contains updates for Change
Requests (CRs) for the GPRS5.0 Channel Ready release. This version also
includes a new appendix, Appendix B, “Engineering rules”.
June 2003
GPRS5.0, 07.03. This is the Standard version for the GPRS5.0 release. This
version includes information about the following features that were added to
GPRS5.0 since the Preliminary version:
• HLR reset and SMS overload controls
• 4POC3/PQC12 card
• BSS Packet Flow Context
November 2002
GPRS5.0 release.
Removed chapter “Software Description” and moved the information to

chapter “Operations, Administration, and Maintenance.”
September 2002
GPRS5.0, 07.01. This Draft version is updated to reflect GPRS5.0
information.
SGSN accounting information has been moved to a separate chapter,

“Accounting”.
September 2002
GPRS4.0, 06.05. This is the Standard version for the GPRS4.0 release.

Publication history v
May 2002
GPRS4.0, 06.04. This Preliminary version includes information on SGSN
buffering in Chapter 2, “Functional description”.
May 2002
GPRS4.0 release.
April 2002
GPRS4.0 release.
March 2002
GPRS4.0, 06.01. This Draft version is updated to reflect GPRS4.0
information. In addition, Chapter 8, “Alarms” has been moved to NTP 411-
5221-500, SGSN Alarms Reference Manual.
February 2002
GPRS3.0, 05.03. This Standard version for the GPRS3.0 release includes
information about SGSN IP address reduction.
October 2001
GPRS3.0 release.
October 2001
GPRS3.0, 05.01. This Draft version contains updates for the GPRS3.0 release:
• Added new alarm information for SGSN
September 2001
GPRS2.0/2.1, 04.02. This is the Standard version for the GPRS2.0 and
GPRS2.1 releases. Information about GPRS Short Message Service (SMS)
applies to GPRS2.1 only.
July 2001
GPRS2.1, 04.01. This Preliminary version includes technical updates for the
GPRS2.1 release.
June 2001
GPRS2.0, 03.02. This Preliminary version includes technical updates for the
GPRS2.0 release.

vi Publication history
April 2001
GPRS2.0, 03.01. This Preliminary version is updated to reflect GPRS2.0
information, including:
• SGSN billing
• Multishelf SGSN
• Tiered subscription
• Inter-SGSN Routing Area Update (IRAU)
• GPRS Short Message Service (SMS)
• GPRS Prepaid SMS
Note: GPRS SMS will be supported in GPRS2.1.
December 2000
GPRS1.5, 02.02. This Standard version of the Passport 15000-VSS with SGSN
Functionality User’s Guide includes the following additional information:
• Added section “Increasing Sgsn maxSubscribers using
maxSubsAccessCode” to “Software description” chapter.
• Added section “Downloading and applying patches” to “Software
management” chapter.
October 2000
GPRS1.5, 02.01. This Preliminary version of the Passport 15000-VSS with
SGSN Functionality User’s Guide is updated to reflect GPRS1.5 information.
The document title was changed from Passport 8380 G with SGSN
Functionality User’s Guide to Passport 15000-VSS with SGSN Functionality
User’s Guide.
May 2000
GPRS01, 01.05. This Preliminary version of the Passport 8380 G with SGSN
Functionality User’s Guide includes technical updates and editorial changes.
March 2000
GPRS01, 01.04. This updated Draft version contains changes based on changes
to product functionality and general editing:
• Updated “Related documents” section.
• Added index.

Publication history vii
January 2000
GPRS01, 01.03. This updated Draft version includes information on
restrictions and considerations in “Functional Description” chapter. This
version also contains changes based on Subject Matter Expert (SME) review
and general editing.
November 1999
GPRS01, 01.02. The documentation product release stream was changed
from GPP02 to GPRS01. The updated Draft version released based upon
comments received from Subject Matter Expert (SME) reviewers.
September 1999
GPP02, 01.01. This draft document was created for the GPP02 release.

viii Publication history

ix
Contents 1
About this document xxv

Purpose xxv
Audience xxv
Organization xxv
Software release applicability xxvi
Related documents xxvii
Roadmap to Packet Core 04 documentation xxvii
Specifications xxviii
Passport documentation xxix
Nortel Wireless Network Management xxx
Preside Multiservice Data Manager (MDM) release 14.3 documentation xxx
Related training xxxi
Indication of hypertext links xxxi
Nortel branding xxxi
Introduction 1-1
General Packet Radio Service 1-1
GPRS SGSN product 1-8
Ga interface 1-8
Gb interface 1-9
Gd interface 1-10
Ge interface 1-11
Gn and Gp interfaces 1-12
Gr', Gs', Gd', and Ge' interfaces 1-13
Gr interface 1-13
Gs interface 1-15
X1 interface 1-15
Release 97 and Release 99 standards support 1-16
Functional description 2-1

SGSN software architecture 2-2
GPRS Transport Layer 2-2
Network Service Entity (NSE) 2-3
BSSGP Virtual Connections (BVCs) 2-4
GPRS Subscriber Data 2-5
GPRS Subscriber Control 2-6
GPRS Mobility Management layer 2-6

x Contents
Session Management layer 2-8

GTP-C 2-9
HLR Cache 2-12
MAP Client 2-12
Service Switching Function (SSF) 2-15
Lawful Interception (LI) Client 2-15
Short Message Service (SMS) 2-15
BSSAP+ 2-15
GSC addressing 2-15
MAP/TCAP Stack 2-17
Routing layer between MapStack and SIG 2-18
Multishelf MAP 2-18
Node failure processing and MAP Stack 2-21
Restrictions and limitations 2-22
Domain Name System Agent 2-23
IP addressing and routing 2-24
Passport 15000 Virtual Routers (VR) 2-24
IP access mechanisms and media 2-25
IP based applications 2-25
IP routing 2-26
Special considerations for I/O routing 2-26
Multishelf configuration 2-29
Function distribution 2-29
Inter-shelf communication 2-32
Provisioning requirements for multishelf 2-34
Hardware description 3-1

Overview 3-1
Passport 15000-VSS frame 3-4
Breaker interface panel 3-5
Cooling unit 3-9
Passport 7400 3-10
Cable management assembly 3-11
Shelf assembly 3-12
Power converter 3-14
Cooling unit 3-16
Signal and power distribution 3-16
7400 control processor 3-17
Timing 3-19
7400 function processors 3-20
Passport 15000 shelf 3-28
Backplane 3-29
Fabric cards 3-30
Power interface modules (PIMs) 3-30
Media access control (MAC) address module 3-31
Alarm/BITS module 3-31
15000 Control processor 3-31
2-port General Processor with Disk (2pGPDsk) 3-32
4-port OC-3 multimode ATM function processor 3-34
4 port DS3 channelized FR function processor 3-35

Contents xi
4 port Gigabit Ethernet function processor 3-37

Network clock synchronization 3-39
Internal timing reference 3-39
External timing reference 3-39
Minimum GPRS SGSN subscriber configurations 3-39
Hardware requirements for OA&M 3-40
Text-based OA&M hardware 3-40
Wireless Network Management System hardware 3-41
Reliability 4-1
Redundancy capabilities 4-1
Control processor card redundancy 4-5
ATM I/O redundancy 4-5
GTL redundancy 4-5
GSD redundancy 4-8
GSC redundancy 4-9
SAS redundancy 4-14
Lawful Interception redundancy 4-15
MAP redundancy 4-16
Gigabit Ethernet redundancy 4-17
IP Carrier Grade redundancy 4-17
Redundancy limitations 4-17
Nodal Manager reliability 4-18
SGSN audits 4-21
Hung Process Audit 4-21
Memory Audit 4-21
Nodal Manager Audit 4-22
Audits and redundancy 4-22
Resource overload controls 4-23
Overload terminology 4-24
GSC functional changes 4-25
Message overload controls 4-27
Message overload handling 4-28
Messages with overload control 4-29
Overload criteria 4-33
OAM for message overload controls 4-35
Services and features 5-1

Feature optionality 5-2
Packet service domain mobility 5-2
Routing area update (RAU) 5-2
Equivalent PLMN (ePLMN) 5-3
Seamless National Roaming (SNR) 5-3
Subscriber designation 5-3
SNR coverage area configuration example 5-5
Equivalent PLMN list selection 5-6
Enhanced APN Selection 5-8
Roaming restrictions 5-8

xii Contents
Quality of Service equivalence 5-10

OAM 5-10
Feature interactions and dependencies 5-14
GPRS Short Message Service (SMS) 5-15
Supported MAP versions 5-15
GPRS SMS network structure 5-16
SMS external interfaces 5-17
Gd' SMS procedures 5-18
GPRS Prepaid Short Message Service (SMS) 5-18
Service Control Point 5-18
GPRS Prepaid SMS network structure 5-19
Messaging protocols 5-20
Provisioning 5-21
Prepaid Short Message Mobile Originated Transfer procedure 5-22
CAMEL Phase 3 5-23
Functional components 5-25
SSF 5-25
PDP Context support 5-27
Billing and charging 5-31
Node failure processing and CAMEL 5-34
PDP context modification 5-38
SGSN initiated PDP Context modification 5-38
MS initiated PDP Context modification 5-38
Service Switching Function 5-39
Timer expiry 5-40
Collision detection 5-40
Error cases 5-40
PDP context modification counters 5-41
Restrictions 5-42
Secondary PDP context activation 5-43
Extended TI IE 5-43
PDP bundle 5-44
Secondary PDP Context activation procedure 5-45
TFT modification 5-46
Deactivation and teardown 5-48
Inter-SGSN routing area update 5-49
OAM 5-51
QoS negotiation 5-53
BSS Packet Flow Context 5-55
PFC procedure 5-55
PCF support and negotiation 5-56
Aggregate BSS QoS Profile 5-56
Packet Flow Identifier 5-57
BSSGP Layer enhancements 5-58
PFM layer 5-59
SM layer 5-63

Contents xiii
GTP layer 5-64

SGSN downlink PDU buffering 5-65
System buffer management 5-66
OA&M 5-66
Restrictions and Limitations 5-67
Lawful Interception (LI) 5-68
LI reference model 5-68
SGSN as the Access Function 5-70
Interception of Intercept Related Information 5-72
Interception of Communication Content 5-73
LI hardware 5-75
Error scenarios involving SGSN cards 5-75
Redundancy 5-76
Security 5-77
LI operation, administration and maintenance 5-77
End user security functions 5-80
Authentication 5-80
Packet Temporary Mobile Subscriber Identity (P-TMSI) 5-81
P-TMSI Signature 5-81
Ciphering 5-81
P-TMSI enhancements 5-82
GMM enhancements 5-82
LLC enhancements 5-83
P-TMSI signature 5-83
Configuration management 5-83
IP Header Compression 5-84
Repair mechanisms for lost TCP/UDP packets 5-84
Lost packets in UDP and other non-TCP packet stream 5-85
OAM 5-86
MS Purge 5-88
MS Purge provisioning 5-88
MS Purge statistics 5-89
Accounting 6-1
SGSN Accounting Server (SAS) 6-2
SAS hardware 6-2
Standards support 6-4
Call Detail Records 6-5
Operations performed on CDRs 6-5
Causes for closing CDRs 6-6
Daylight Savings Time interaction 6-7
CDRs and Subscriber Control Card Reset 6-7
S-CDR partial records 6-8
Data Volume Limit 6-8
PDP Context duration limit 6-9

xiv Contents
Time based partial and DVL partial record interaction 6-9

Maximum number of charging condition changes 6-10
Management Intervention 6-10
Tariff Time Change 6-11
Location Based Billing 6-13
Specific Daily Partial 6-13
TODA provisioning 6-15
S-CDR partial record common provisioning 6-16
Counters for S-CDRs 6-17
M-CDR partial records 6-17
Billing record storage 6-18
Batch file naming conventions 6-18
Normal batch file processing 6-18
Recovery batch file processing 6-19
Charging Gateway Function (CGF) 6-19
CGF Data Record Transfer Request threshold 6-20
CGF Data Record Transfer Response processing 6-20
Billing redundancy 6-22
Hot standby 6-22
Fault management 6-23
Accounting management 6-25
Performance management 6-25
Node failure processing and SAS 6-25
GGSN 6-25
CGF 6-26
SGSN 6-27
SC 6-27
SD 6-27
General 6-27
Multi-active SAS 6-28
SAS hot standby redundancy 6-29
CAMEL 6-30
Partial records 6-30
Daylight Savings Time interaction 6-31
Operations, administration, and maintenance 7-1

OA&M overview 7-2
Components 7-2
Data collection 7-7
Security management 7-8
Text interface 7-9
Nortel Wireless Network Management System 7-11
Provisioning maxSubscribers 7-12
Increasing “Sgsn maxSubscribers” using “maxSubsAccessCode” 7-12
Sgsn component verification 7-13
Gsc and Gsd component verification 7-13

Contents xv
Performance counters 7-14

Enabling per cell statistics collection 7-14
Session Management 7-14
Routing Area Update 7-16
SCCP UDTS failure 7-17
Call model validation 7-18
GMM Attach/Detach/IRAU/RAU Procedures 7-19
GPRS5.0.1/UMTS3.0.1 performance management content 7-25
Displaying GMM and SM counters 7-26
Displaying GSC success rates 7-28
Attach and activate failure alarms 7-29
Alarm operation 7-29
Provisioning 7-32
Redundancy 7-33
Displaying IMSI information 7-34
Clearing a GTP path 7-34
Clearing an inactive mobile 7-34
SGSN trace tools 7-35
SC Diagnostic Tool 7-36
Provisioning 7-36
Alarms 7-38
Active alarm list 7-45
Audit alarms 7-45
Locking/unlocking a GSC 7-46
Gsc lock operation 7-46
Gsc lock - force operation 7-46
Gsc unlock operation 7-47
Daylight Savings Time adjustment 7-47
GMM Cause Code mapping 7-48
Valid 29.002 MAP errors 7-49
Valid 24.008 GMM Cause Codes 7-49
User Defined GMM Cause Code 7-50
MAP Error to GMM Cause Code default mapping 7-51
DNS Query Failure to GMM Cause Code default mapping 7-52
CAS provisioning examples 7-52
OSI states 7-56
BSSAP 7-57
DNS 7-58
GSC 7-61
GSC SSF 7-63
GSD 7-66
GTP-C 7-67
GTP Path 7-69
LIAF 7-70
MapClient 7-72

xvi Contents
MapStack 7-74
NSE 7-77
SAS 7-79
SGGTL 7-80
SGSN 7-82
Sgsn Shelf ConM and ConS 7-83
TcapStack 7-85
Software management 8-1

Software distribution 8-1
Software upgrade strategy 8-2
Downloading and applying patches 8-2
Removing patches 8-5
Technical specifications and conformances A-1

GSM specification conformance A-2
MTBF ratings for Passport hardware components A-2
Node capacity A-2
Bus performance A-2
Physical characteristics A-2
Dc power input specifications A-4
7400 node A-4
15000 node A-4
Dc grounding scheme A-4
Environmental specifications A-5
Node ventilation and access clearances A-5
Heat dissipation A-5
Thermal engineering A-5
Passport switch standards conformances A-6
Dc power supply summary A-6
Control processor A-7
100BaseT Ethernet function processor A-7
2-port OC-3 ATM function processor A-7
MSA32 function processor A-9
2pGPDsk function processor A-10
4-port OC-3 ATM function processor A-10
4-port DS3 channelized FR function processor A-11
Century compliance for Passport software A-11
Statement of Year 2000 compliance A-12
Engineering rules B-1

Network engineering rules B-1
SGSN shelf B-1
CP cards B-2
Intershelf ATM cards B-2
GSC B-3
GSD B-3
SAS/LI B-4
MAP B-4
MSA32 B-5

Contents xvii
4port-DS3 B-7
GTL on MSA32 B-8
GTL on 4pOC3 B-8
2p100base-t LAN B-12
2pGPDsk LAN B-12
4pGigabit Ethernet B-13
Gb interface engineering B-13
NS-VC B-13
NSE B-14
BVC B-16
DLCI B-18
Channel B-19
Gb Interface limitation B-20
Frame relay rules B-22
Gn interface B-24
Gx’ interface B-24
Ga interface B-24
X1 interface B-24
OA&M interface B-25
Provisioning rules B-25
Attached subscriber rules B-25
Sgsn maxsubscriber B-25
GSC/n MaxAttachedSubscribers B-25
GSD/n maxLlcActiveSubscribers B-25
White Book SCCP compliance B-26
Routing area rules B-27
SGSN parameters C-1

Summary of Timers and retry settings C-1
The impact of the timers on the Performance C-1
The impact of the timers on the System Capacity C-2
Timer Provisioning Guidelines C-3
Number of Retries C-4
SGSN recommendation tables C-6
SGSN attributes C-6
SGSN GTL attributes C-6
GTL/* attributes C-7
SGSN GSD attributes C-7
GSD/* attributes C-10
GSD/* buffering attributes C-10
SGSN GSC attributes C-12
GSC/* attributes C-16
DNS attributes C-18
TCAP/* attributes C-18
SGSN SAS attributes C-20
SGGTL NSE attributes C-21
SGSN provisionable attributes C-21
GPRS Subscriber Control (GSC) provisionable attributes C-24
Session Management C-26
GPRS Mobility Management C-28

xviii Contents
MAP Client C-40

BSSAP Client C-43
Service Switching Function (SSF) Client C-47
GTP Tunnel and Path Management C-50
Short Message Service C-58
Packet flow management C-59
HLR Cache C-62
Location services (Q01068044) C-63
GPRS Subscriber Datapath (GSD) provisionable attributes C-63
GSD attributes C-64
GSD LLC attributes C-65
Capacity attributes C-67
SNDCP attribute C-73
SAPI Control attribute (SAP-1) C-77
SAPI Data/<Sapi> attribute (SAP-3, SAP-5, SAP-9, SAP-11) C-81
SAPI Data/<SapiSms> attribute (SAP-7) C-86
GPRS Transport Layer (GTL) provisionable attributes C-88
PDU buffering provisionable attributes C-89
GPRS Routing Area provisionable attributes C-98
MAP stack provisionable attributes C-100
DNS Agent provisionable attributes C-110
SGSN Accounting Server (SAS) provisionable attributes C-111
PC04: SNR (Seamless National Roaming) provisionable attributes C-120
PC04: Secondary PDP provisionable attributes C-123
PC04: Overload control C-124
Single slot 32-Port MSA cabling D-1

32-port DS1 MSA 1-slot function processors D-1
32-port DS1 MSA 1-slot faceplate D-2
32-port DS1 MSA 1-slot and 2-slot FP replacements D-3
32-port DS1 MSA 1-slot and 2-slot FP sparing combinations D-4
32-port DS1 MSA termination panels for 1-slot FPs D-5
32-port DS1 MSA prefabricated cable assemblies for FPs and sparing panels D-
5
32-port DS1 MSA custom-made cable assemblies for FPs and sparing panels D-
13
32-port DS1 MSA 1-slot FP pinouts D-14
32-port DS1 MSA termination panel pinouts for CPE connections D-20
32-port E1 MSA 1-slot function processors D-23
32-port E1 MSA 1-slot faceplate D-23
32-port E1 MSA 1-slot and 2-slot FP replacements D-24
32-port E1 MSA 1-slot and 2-slot FP sparing combinations D-25
32-port E1 MSA termination panels for 1-slot FPs D-26
32-port E1 MSA prefabricated cable assemblies for FPs and sparing panels D-26
32-port E1 MSA custom-made cable assemblies for FPs and sparing panels D-
33
32-port E1 MSA 1-slot FP pinouts D-34
32-port E1 MSA termination panel pinouts for CPE connections D-40
List of terms E-1

Contents xix
Index F-1
List of figures
Figure i PC04 Documentation Roadmap xxvii
Figure 1-1 Nortel SGSN and its relationship to GPRS specified interfaces 1-2
Figure 1-2 U-plane protocol stacks between the MS and the GGSN 1-6
Figure 1-3 C-plane protocol stacks between the MS and SGSN 1-7
Figure 1-4 Message protocol stacks for the Ga interface 1-9
Figure 1-5 Message protocol stacks for the Gd interface 1-11
Figure 1-6 Message protocol stacks for the SGSN, SIG, and SCP 1-12
Figure 1-7 Message protocol stacks for the SGSN, SIG, and HLR 1-14
Figure 1-8 Message protocol stacks for the Gs interface 1-15
Figure 2-1 MAP Client interfaces 2-13
Figure 2-2 Single Point Code scheme 2-16
Figure 2-3 Multiple Virtual Point Code scheme 2-17
Figure 2-4 MAP/TCAP single shelf configuration 2-19
Figure 2-5 MAP/TCAP multiple-shelf configuration 2-20
Figure 2-6 Faceplate port(s) on same FP example 2-27
Figure 2-7 Faceplate port(s) on intra-shelf FP example 2-28
Figure 2-8 4pOC3MmAtm example 2-28
Figure 2-9 2pGPDsk Dedicated for I/O example 2-29
Figure 2-10 SGSN function distribution 2-30
Figure 2-11 SVC connections (simplified view) 2-33
Figure 3-1 Passport 15000 frame 3-4
Figure 3-2 Passport 7400 node assemblies 3-11
Figure 3-3 SGSN cable management 3-12
Figure 3-4 Shelf assembly 3-13
Figure 3-5 Dc shelf assembly, rear view 3-14
Figure 3-6 CP2 faceplate 3-19
Figure 3-7 100BaseT Ethernet function processor faceplate 3-21
Figure 3-8 2-port OC-3 ATM function processor faceplate 3-22
Figure 3-9 MSA32 function processor faceplate 3-23
Figure 3-10 WPDS faceplate 3-25
Figure 3-11 WPDS logical diagram 3-26
Figure 3-12 Typical 15K shelf (front view) 3-28
Figure 3-13 Typical 15K shelf (rear view) 3-29
Figure 3-14 CP3 faceplate 3-32
Figure 3-15 2pGPDsk faceplate 3-33
Figure 3-16 4-port OC-3 ATM function processor faceplate 3-35
Figure 3-17 4pDS3Ch FR function processor faceplate 3-36
Figure 3-18 4pGe faceplate 3-37
Figure 3-19 SX/LX SPF module 3-38
Figure 4-1 GTL redundancy 4-6
Figure 4-2 GTL pair architecture for NSE redundancy 4-8
Figure 4-3 Card sparing architecture 4-15
Figure 4-4 Resource usage characteristic example showing overload regions and
hysteresis bands 4-24
Figure 4-5 Message overload handling 4-28
Figure 4-6 Attach/SAI overload control example 4-35

xx Contents
Figure 5-1 National roaming network 5-5

Figure 5-2 ePLMN list example 5-7
Figure 5-3 Roaming restrictions example 5-9
Figure 5-4 GPRS SMS network structure 5-16
Figure 5-5 GPRS SMS Prepaid network structure 5-19
Figure 5-6 Message protocol stack for GPRS Prepaid SMS 5-20
Figure 5-7 Nortel IN network architecture 5-24
Figure 5-8 Secondary PDP context example 5-44
Figure 5-9 BSS QoS addressing architecture 5-55
Figure 5-10 Aggregate BSS QoS Profile IE 5-57
Figure 5-11 PFI Information Element 5-58
Figure 5-12 Nortel implementation of the LI Reference Model 5-69
Figure 5-13 LICP protocol stack 5-71
Figure 5-14 Sample SGSN/GPRS configuration for LI 5-75
Figure 5-15 GSM authentication procedure 5-80
Figure 6-1 UMTS/GPRS charging overview 6-1
Figure 6-2 Time based and DVL partial record creation interaction 6-10
Figure 6-3 Specific Daily S-CDR partial record example 6-15
Figure 6-4 Active/standby synchronization 6-22
Figure 7-1 Components form into parent and subcomponents by their relative
positions 7-4
Figure 7-2 Format of screen: provisioning mode or operational mode 7-10
Figure 7-3 Sample screen, valid command in provisioning mode 7-10
Figure 7-4 Sample screen, valid command in operational mode 7-10
Figure 7-5 Example maxSubscribers provisioning 7-12
Figure 7-6 Sliding window success calculation 7-30
Figure 7-7 BSSAP OSI state diagram 7-57
Figure 7-8 DNS component OSI state diagram 7-59
Figure 7-9 GSC component OSI state diagram 7-61
Figure 7-10 Gsc Ssf component OSI state diagram 7-64
Figure 7-11 GSD component OSI state diagram 7-66
Figure 7-12 GTP-C component OSI state diagram 7-67
Figure 7-13 GTP Path component OSI state diagram 7-69
Figure 7-14 LIAF component OSI state diagram 7-70
Figure 7-15 MapClient OSI state diagram 7-73
Figure 7-16 MapStack component OSI state diagram 7-75
Figure 7-17 NSE component OSI state diagram 7-77
Figure 7-18 SAS OSI state diagram 7-79
Figure 7-19 SGGTL component OSI state diagram 7-81
Figure 7-20 SGSN component OSI state diagram 7-82
Figure 7-21 SGSN Sh ConM and ConS components OSI state diagram 7-84
Figure 7-22 TcapStack component OSI state diagram 7-86
Figure B-1 Dual Cabinet configuration B-1
Figure B-2 Gb interface engineering B-6
Figure B-3 N+1 Sparing on MSA32 B-7
Figure B-4 4pDS3 connectivity B-8
Figure B-5 GTL provisioning with redundancy B-9
Figure B-6 GTL redundancy (provisioned at 40%) B-9
Figure B-7 GTL redundancy (provisioned at 80%) B-10
Figure B-8 GTL provisioning with redundancy B-11
Figure B-9 NSE redundancy (2N), each GTL provisioned at 40% B-11

Contents xxi
Figure B-10 GTL redundancy 2N+1: each active card provisioned at 80% B-12
Figure B-11 Relationship between NS-VCs and NS-VLs B-14
Figure B-12 Correspondence between PCU and SPM in the PCUSN B-15
Figure B-13 Network Service Entity B-16
Figure B-14 BVC within SGSN B-17
Figure B-15 Frame relay B-18
Figure B-16 Unchannelized links used with Nortel Nodes B-19
Figure B-17 Channelized is used with NOKIA PCU or NOKIA SGSN B-20
Figure B-18 Location area and routing area topology B-27
Figure C-1 Timer Value > 99.99% of Delay C-4
Figure C-2 SGSN GTL attributes C-6
Figure C-3 GSC provisionable attributes C-24
Figure C-4 BSS QoS addressing architecture C-60
Figure C-5 GSD provisionable attributes C-64
Figure C-6 GPRS Routing Area provisionable attributes C-98
Figure C-7 MAP stack provisionable attributes C-100
Figure C-8 SNR provisionable attributes C-120
Figure D-1 Faceplate of a 32-port DS1 MSA 1-slot FP with PEC NTNQ94 D-3
Figure D-2 Inter-panel flexi-cable NTJS99 for MSA32 sparing panels with RJ-45
connectors D-7
Figure D-3 Inter-panel flexi-cable NTY199AB for MSA32 sparing panels with DB15
connectors D-8
Figure D-4 Fanout cable NTPS32 or NTPS33 for a 32-port DS1 MSA 1-slot FP D-
10
Figure D-5 Fanout cable NTPS36 or NTPS37 with sliding latch D-subs for a 32-port
DS1 MSA 1-slot FP D-11
Figure D-6 Fanout cable adapter NTPS39 for connecting a 1-slot FP to 2-slot
cables NTPS03 or NTPS04 D-12
Figure D-7 Fanout cable NTPS03 or NTPS04 to connect to an adapter cable
NTPS39 of a DS1 1-slot FP D-13
Figure D-8 32-port DS1 MSA termination panel pinouts and signal names: 1-port/
DB15 D-21
Figure D-9 32-port DS1 MSA termination panel pinouts and signal names: 2-port/
DB15 D-21
Figure D-10 32-port DS1 MSA termination panel pinouts and signal names:
RJ-45 D-22
Figure D-11 Faceplate of a 32-port E1 MSA 1-slot FP with PEC NTNQ93 D-24
Figure D-12 Inter-panel flexi-cable NTJS99 for MSA32 sparing panels with RJ-45
connectors D-27
Figure D-13 Inter-panel flexi-cable NTY199AB for MSA32 sparing panels with BNC
or DB15 connectors D-28
Figure D-14 Fanout cable NTPS32 or NTPS33 for a 32-port E1 MSA 1-slot FP D-
30
Figure D-15 Fanout cable NTPS36 or NTPS37 with sliding latch D-subs for a 32-port
E1 MSA 1-slot FP D-31
Figure D-16 Fanout cable adapter NTPS39 for connecting a 1-slot FP to 2-slot
cables NTPS03 or NTPS04 D-32
Figure D-17 Fanout cable NTPS03 or NTPS04 to connect to an adapter cable
NTPS39 of an E1 1-slot FP D-33
Figure D-18 32-port E1 MSA termination panel pinouts and signal names: 1-port/
DB15 D-41

xxii Contents
Figure D-19 32-port E1 MSA termination panel pinouts and signal names: 2-port/
DB15 D-41
Figure D-20 32-port E1 MSA termination panel pinouts and signal names:
RJ-45 D-42
List of tables
Table i Original product names mapped to new names xxxii
Table ii New product names mapped to original name(s) xxxiv
Table 1-1 GPRS6.0 SGSN interface support 1-5
Table 2-1 IP based applications 2-25
Table 2-2 2-26
Table 2-3 SGSN function summary 2-31
Table 3-1 Passport 7400 shelf processors 3-2
Table 3-2 Passport 15000 shelf processors 3-3
Table 3-3 Alarm LED status indicators for the EBIP alarm module 3-6
Table 3-4 Power LED status indicators for the EBIP alarm module 3-6
Table 3-5 EBIP hardware alarm definitions 3-7
Table 3-6 Cooling unit LED indications 3-9
Table 3-7 Dc power requirements 3-16
Table 4-1 Redundancy types 4-2
Table 4-2 Functional Processor redundancy summary 4-4
Table 5-1 Feature optionality 5-2
Table 5-2 Mobility event support 5-2
Table 5-3 Application of SNR attributes 5-4
Table 5-4 Roaming restrictions 5-6
Table 5-5 SNR provisioning fault messages 5-11
Table 5-6 SNR provisioning warnings 5-12
Table 5-7 CAMEL triggers 5-26
Table 5-8 Abnormal cases for PDP Context Activation 5-28
Table 5-9 Abnormal cases for PDP Context Deactivation 5-30
Table 5-10 Error scenarios for PDP context modification 5-41
Table 5-11 PDP context prioritization scheme 5-50
Table 5-12 Traffic classes 5-53
Table 5-13 QoS background TC 5-54
Table 5-14 BSSGP layer enhancements for PFC 5-58
Table 5-15 PFM layer enhancements 5-60
Table 5-16 SM layer enhancements 5-64
Table 5-17 GTP layer enhancements 5-64
Table 5-18 Intercept information 5-72
Table 5-19 Event details 5-73
Table 5-20 CC message information 5-74
Table 5-21 GPRS/UMTS specific Product detail 5-74
Table 5-22 LIAF component status attributes 5-78
Table 5-23 SGSN supported ciphering algorithms 5-81
Table 5-24 P-TMSI collision cause 5-82
Table 6-1 Example list of traffic data volumes 6-11
Table 6-2 DRT response message cause value descriptions 6-20
Table 7-1 Summary of characteristics of provisioning operations 7-6
Table 7-2 Sample success calculation data points 7-30
Table 7-3 SC Diagnostic Tool security alarms 7-38

Contents xxiii
Table 7-4 SC Diagnostic Tool activation alarms 7-41

Table 7-5 SC Diagnostic Tool general alarms 7-45
Table 7-6 MAP errors valid for mapping 7-49
Table 7-7 Standard GMM Cause Codes valid for mapping 7-50
Table 7-8 PC04 MAP error to GMM Cause Code default mapping 7-51
Table 7-9 PC04 DNS Query Failure to GMM Cause Code Default mapping 7-52
Table 7-10 BSSAP component state combinations 7-58
Table 7-11 DNS Agent OSI state combinations 7-60
Table 7-12 Supported state combinations for Gsc 7-62
Table 7-13 Supported state combinations for Gsc Ssf 7-65
Table 7-14 GTP-C component state combination 7-68
Table 7-15 GTP Path component state combination 7-70
Table 7-16 LIAF component state combination 7-72
Table 7-17 MapClient state combinations 7-74
Table 7-18 MapStack component state combination 7-76
Table 7-19 NSE component OSI state combinations 7-78
Table 7-20 SAS component state combinations 7-80
Table 7-21 SGGTL component state combination 7-81
Table 7-22 SGSN component state combination 7-83
Table 7-23 SGSN Sh ConM and ConS component state combinations 7-85
Table 7-24 TcapStack component state combination 7-87
Table A-1 Summary of equipment dimensions and weights A-3
Table A-2 Environmental requirements A-5
Table B-1 FRATM naming convention B-23
Table B-2 White Book SCCP compliance B-26
Table C-1 Message delays C-3
Table C-2 Call Success Rate with Message Loss Probability p =0.001 (1 out of
1000) C-5
Table C-3 Call Success Rate with Message Loss Probability p = 0.01 (1 out of
100) C-5
Table C-4 SGSN attributes C-6
Table C-5 GTL/* attributes C-7
Table C-6 SGSN GSD attributes C-7
Table C-7 GSD/* attributes C-10
Table C-8 GSD/* buffering attributes C-10
Table C-9 SGSN GSC attributes C-12
Table C-10 GSC/* attributes C-16
Table C-11 DNS attributes C-18
Table C-12 TCAP attributes C-18
Table C-13 SGSN SAS attributes C-20
Table C-14 Sggtl NSE attributes C-21
Table C-15 APN vs. Subscriber capacity C-26
Table C-16 Recommended overload control settings C-124
Table D-1 Compatible replacements for equivalent DS1 MSA 1-slot and 2-slot
FPs D-4
Table D-2 Sparing combinations of DS1 MSA FPs and sparing panels D-5
Table D-3 PECs of the MSA32 DS1 flexi-cables between sparing panels D-6
Table D-4 PECs of the MSA32 DS1 interface fanout cables from FP to sparing
panel D-8
Table D-5 Mapping of MSA 1-slot FP port numbers to fanout cable connectors D-
14

xxiv Contents
Table D-6 DS1 MSA 1-slot FP connector pinouts for P0 ports 0 to 7 and P1 ports
16 to 23 D-15
Table D-7 DS1 MSA 1-slot FP connector pinouts for P0 ports 0 to 7 and P1 ports
16 to 23 D-16
Table D-8 32-port DS1 MSA 1-slot FP connector pinouts for P0 ports 8 to 15 and
P1 ports 24 to 31 D-17
Table D-9 32-port DS1 MSA 1-slot FP connector pinouts for P0 ports 8 to 15 and
P1 ports 24 to 31 D-19
Table D-10 Compatible replacements for equivalent E1 MSA 1-slot and 2-slot
FPs D-25
Table D-11 Sparing combinations of E1 MSA FPs and sparing panels D-25
Table D-12 PECs of the MSA32 E1 flexi-cables between sparing panels D-27
Table D-13 PECs of the MSA32 E1 interface fanout cables from FP to sparing
panel D-29
Table D-14 Mapping of MSA 1-slot FP port numbers to fanout cable connectors D-
34
Table D-15 E1 MSA 1-slot FP connector pinouts for P0 ports 0 to 7 and P1 ports 16
to 23 D-35
Table D-16 E1 MSA 1-slot FP connector pinouts for P0 ports 0 to 7 and P1 ports 16
to 23 D-36
Table D-17 32-port E1 MSA 1-slot FP connector pinouts for P0 ports 8 to 15 and P1
ports 24 to 31 D-37
Table D-18 32-port E1 MSA 1-slot FP connector pinouts for P0 ports 8 to 15 and P1
ports 24 to 31 D-39
List of procedures
Procedure 8-1 Downloading and applying SGSN patches 8-3
Procedure 8-2 Removing an SGSN patch 8-5

xxv
About this document

Purpose 0
This Nortel Technical Publication (NTP) describes the 15000-VSS Passport*
platform functioning as a Serving General Packet Radio Service (GPRS)
Support Node (SGSN).
Audience 0
This publication is intended for persons involved in the planning,
engineering, administration, or maintenance of the SGSN system.
It is assumed that the reader has a general familiarity with GPRS networks
and standards, and a similar familiarity with the 15000-VSS Passport
platform.
Organization 0
This publication consists of the following chapters:
• Chapter 1, “Introduction” introduces the GPRS network and the Nortel
SGSN as it relates to the GPRS network nodes and interfaces.
• Chapter 2, “Functional description” describes the SGSN core functions.
• Chapter 3, “Hardware description” describes the SGSN hardware
components.
• Chapter 4, “Reliability” describes the reliability, redundancy and
availability of the SGSN.
• Chapter 5, “Services and features” describes services that the SGSN
supports.
• Chapter 6, “Accounting” describes the SGSN Accounting application.
• Chapter 7, “Operations, administration, and maintenance” describes the
supported OA&M interfaces, SGSN component OSI states, and other
aspects of OA&M specific to the SGSN.
• Chapter 8, “Software management” provides information on the software
management of the SGSN.

xxvi About this document
• Appendix A, “Technical specifications and conformances” provides

technical specifications and conformances for the SGSN node.
• Appendix B, “Engineering rules” provides product engineering rules for
provisioning a GPRS6.0 SGSN.
• Appendix C, “SGSN parameters” describes the Nortel SGSN
configuration parameters that have a capacity and/or performance impact
the SGSN or end user.
• Appendix D, “Single slot 32-Port MSA cabling” provides information
about the single slot 32 port MSA card.
• Appendix E, “List of terms” provides a list of terms and acronyms and
their definitions.
Software release applicability 0

This publication is applicable to the GPRS6.0 software release. GPRS6.0 is
part of the Packet Core 04 (PC04) release. Unless this publication is revised,
it also applies to offices that have software releases greater than GPRS6.0.
This document provides a comprehensive view of the SGSN product as of

GPRS 6.0 and does not distinguish between this release and previous
releases. For a detailed description of previous releases, refer to the
corresponding version of this document.
The SGSN in GPRS6.0 is based on the Passport 15000 and Passport VSS
PCR 5.2 release.
The Multiservice Data Manager (MDM) software load must be version 14.3
or higher. Note that MDM is outside the scope of this document.
GPRS 6.0 is based on GPRS Release ‘4. Refer to NTP 411-5221-201,

Specifications for UMTS/GPRS Packet Core Conformance Guide for detailed
standards applicability.

About this document xxvii
Related documents 0
Roadmap to Packet Core 04 documentation
Figure i shows the NTPs in the documentation suite for PC04.
Figure i
PC04 Documentation Roadmap
Planning and Installation and Operations and Fault and

Concepts Upgrading Performance
Engineering Commisioning Administration
Management
Packet Core GGSN, SCS Delta Packet Core SGSN Provisioning SGSN/UMTS GGSN
Customer
Documentation 411-5221-200 Upgrade Strategy Procedures User Guide Monitoring Guide
Documentation
411-5221-004 411-5221-303 411-5221-904 411-8111-903 411-5221-924
411-5221-003
SGSN, SIG Delta GGSN Provisioning
About the UMTS SIG GGSN SGSN/GPRS
411-5221-202 Procedures
Network Upgrade User Guide Monitoring Guide
411-5221-306 411-5221-927 411-5221-926
411-8111-502 Packet Core 411-5221-050
Conformance Guide SGSN/GPRS GGSN H/W
411-5221-201 SGSN/GPRS SGSN/UMTS
Terminology Upgrade Install & Maintenance
User Guide Monitoring Guide
411-8111-804 411-5221-307 411-5221-923
SGSN 411-5221-955 411-8111-050
Call Detail Records
GGSN RADIUS SGSN/UMTS SIG
411-5221-204 SGSN Components
Interface Guide Upgrade User Guide 411-5221-060
411-5221-928 SGSN 411-5221-308 411-5221-975
Billing Samples SGSN Alarms
SGSN/UMTS 411-5221-205 SCS & GGSN GGSN 411-5221-500
User Guide Upgrade CLI Guide
411-8111-903 GGSN 411-5221-309 411-5221-922 GGSN Alarms
Billing Samples 411-5221-921
GGSN 411-5221-206 AN Upgrade GGSN Provisioning
User Guide 411-5221-310 Procedures Core Network
411-5221-926 SGSN/UMTS 411-5221-927 Troubleshooting
User Guide
Guide
SGSN/GPRS 411-5221-903
411-5221-501
User Guide
411-5221-955 GGSN SGSN/UMTS
User Guide User Guide
SIG 411-5221-926 411-8111-903
User Guide
411-5221-975 SGSN/GPRS GGSN
411-5221-955 411-5221-926
SIG SGSN/GPRS
411-5221-975 411-5221-955
SIG
User Guide
411-5221-975
Feb 14/05

xxviii About this document
Specifications
For more information about the GPRS interfaces and protocols referred to in
this document, refer to the following specifications:
• GSM 04.64 (V8.7.0), “Digital cellular telecommunications system (Phase
2+); General Packet Radio Service (GPRS); Mobile Station – Serving
GPRS Support Node (MS - SGSN) Logical Link Control (LLC) layer
specification”
2+); General Packet Radio Service (GPRS); Mobile Station (MS) –
Serving GPRS Support Node (SGSN); Subnetwork Dependent
Convergence Protocol (SNDCP)”
• GSM TS 08.14 (V8.0.0), “Digital cellular telecommunications system
(Phase 2+); General Packet Radio Service (GPRS); Base Station System
(BSS) - Serving GPRS Support Node (SGSN) interface; Gb interface
Layer 1”
• GSM 08.16, Digital cellular telecommunications system (Phase 2+);
General Packet Radio Service (GPRS); Base Station System (BSS) -
Serving GPRS Support Node (SGSN); Network Service
2+); General Packet Radio Service (GPRS); Base Station System (BSS) -
Serving GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)”
• 3GPP TS 03.33 (V8.1.0), “Lawful Interception; Stage 2 (Release 99)”
• 3GPP TS 09.60 (V7.6.0), “Digital cellular telecommunications system
(Phase 2+); General Packet Radio Service (GPRS); Base Station System
(BSS) - Serving GPRS Support Node (SGSN); GPRS Tunnelling Protocol
(GTP) across the Gn and Gp Interface”
• 3G TS 23.060, (V4.9.0), “GPRS Service Description. Stage 2”
• 3GPP TS 23.078, (V4.11.1), “Camel Service Description; Stage 2”
• 3GPP TS 23.040 (V4.8.0), “Technical realization of the Short Message
Service (SMS); Point-to Point (PP)”
• 3GPP TS 24.008 (V4.14.0), “Mobile radio interface layer 3 specification;
Core Network Protocols – Stage 3”
• 3GPP TS 24.011 (V4.1.1), “Point-to-Point Short Message Service (SMS)
support on mobile radio interface”
• 3GPP TS 29.002 (V4.15.0), “SGSN Mobile Application Part (MAP)
Specification”
• 3GPP TS 29.016 (V4.1.0), “SGSN –Visitors Location Register (VLR) Gs
interface network service specification”

About this document xxix
• 3GPP TS 29.018 (V4.5.0), “General Packet Radio Service (GPRS);

Serving GPRS Support Node (SGSN) –Visitors Location Register (VLR);
Gs interface layer 3 specification”
• 3GPP TS 29.060 (V4.11.0), “General Packet Radio Service (GPRS);
GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface”
• 3GPP TS 29.078 (V4.8.0), “Camel Phase 3, Camel Application Part
(CAP) Specification”
• 3GPP TS 32.015 (V3.6.0), “GSM call and event data for the packet
switched domain”
• 3GPP TS 33.106 (V4.0.0), “Lawful Interception Requirements”
• 3GPP TS 33.107 (V4.3.0), “Technical Specification Group Services and
Systems Aspects; 3G Security; Lawful Interception Architecture and
Functions”
Passport documentation
Refer to the following NTPs in the Passport suite (PCR 5.2) for additional
information relative to the Passport platform:
• 241-1501-200, Passport 15000, 20000 Hardware Description
• 241-1501-205, Passport 15000, 20000 Site Requirements and
Preparation Guide
• 241-1501-240, Passport 15000, 20000 Hardware Installation,
Maintenance and Upgrade
• 241-5701-001, Passport 7400, 15000, 20000 Documentation Guide
• 241-5701-005, Passport 7400, 15000, 20000 List of Terms
• 241-5701-030, Passport 7400, 15000, 20000 Overview
• 241-5701-045, Passport 7400, 15000, 20000 Management System User
Interface Guide
• 241-5701-050, Passport 7400, 15000, 20000 Commands
• 241-5701-053, Passport 7400, 15000, 20000 Command Summary Card
• 241-5701-060, Passport 7400, 15000, 20000 Components
• 241-5701-270, Passport 7400, 15000, 20000 Software Installation Guide
• 241-5701-500, Passport 6400, 7400, 15000, 20000 Alarms
• 241-5701-510, Passport 7400, 15000, 20000 Trace Guide
• 241-5701-520, Passport 7400, 15000, 20000 Troubleshooting Guide
• 241-5701-600, Passport 7400, 15000, 20000 Configuration Guide
• 241-5701-605, Passport 7400, 15000, 20000 User Access Guide
• 241-5701-611, Passport 7400, 15000, 20000 Data Collection Guide

xxx About this document
• 241-5701-615, Passport 7400, 15000, 20000 FP Configuration Reference

• 241-5701-650, Passport 7400, 15000, 20000 Accounting Fundamentals
• 241-5701-700, Passport 7400, 15000, 20000 ATM Overview
• 241-5701-702, Passport 7400, 15000, 20000 ATM Routing and Signaling
Fundamentals
• 241-5701-705, Passport 7400, 15000, 20000 ATM Traffic Management
Fundamentals
• 241-5701-706, Passport 7400, 15000, 20000 ATM Traffic Shaping and
Policing
• 241-5701-707, Passport 7400, 15000, 20000 ATM Queuing and
Scheduling
• 241-5701-710, Passport 7400, 15000, 20000 ATM Configuration Guide
• 241-5701-715, Passport 7400, 15000, 20000 ATM Monitoring and
Troubleshooting Guide
• 241-5701-805, Passport 7400, 15000, 20000 Understanding IP
• 241-5701-810, Passport 7400, 15000, 20000 Configuring IP
• 241-5701-901, Passport 7400, 15000, 20000 Frame Relay Fundamentals
• 241-5701-902, Passport 7400, 15000, 20000 Configuring Frame Relay
• 241-5701-920, Passport 7400, 15000, 20000 Frame Relay to ATM
Interworking Guide
• 241-7401-200, Passport 7400 Hardware Description
• 241-7401-240, Passport 7400 Hardware Installation, Maintenance and
Upgrade
Nortel Wireless Network Management

Refer 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.
Preside Multiservice Data Manager (MDM) release 14.3 documentation

Refer to the following NTPs in the Preside MDM suite (release 14.3) for
additional information about Passport OA&M:
• 241-6001-011, Preside MDM Fault Management User Guide
• 241-6001-023, Preside MDM Configuration Management for Passport
User Guide
• 241-6001-303, Preside MDM Administrator Guide
• 241-6001-309, Preside MDM Management Data Provider User Guide

About this document xxxi
• 241-6001-804, Preside MDM Workstation Utilities User Guide

• 241-6001-806, Preside MDM MDP Data Formats Reference Guide
Related training 0
For questions regarding training courses for the SGSN, please contact your
local Nortel representative for the latest course identification, availability, and
training center location.
Indication of hypertext links 0

Hypertext links in this document are indicated in blue. If viewing a PDF
version of this document, click on the blue text to jump to the associated
section or page.
Nortel branding 0
Nortel is changing the branding of some of its product lines. Part of this effort
includes changing the names of the products. New product names have been
created using the following format:
Nortel <function> <model>
where:
– <function> describes what function the product performs.
– <model> is a model series number.
For example, the Baystack 450 product has been renamed as the Nortel
Ethernet Switch 450. Some of the new product names are quite lengthy. To
make our documents easier to read, the product names are shortened after
their first occurrence. For example, the Nortel Ethernet Switch 450 product
name is referred to as the Ethernet Switch 450 for second and subsequent
occurrences.
To alleviate any confusion the rebranding might cause, Table i and Table ii
are job aids to assist the end user in reconciling inconsistent product
terminology across multiple documents. 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.

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

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

Switch 184
BayStack 450 Nortel Ethernet Switch 450 Ethernet

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

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

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

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

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

Server
iBTS Nortel BTS xxxx BTS xxxx Base Transceiver

Station
IMS Solution Nortel IMS IMS IP Multimedia

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

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

About this document xxxiii
Table i
Original product names mapped to new names (continued)
Nortel Networks Secure Nortel VPN Router xxxx VPN Router

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

7400 Switch 7400

15000 Switch 15000

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

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

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

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

(MLC) Center
Univity SGSN Nortel SGSN SGSN Serving GPRS

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

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

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

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

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

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

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

About this document xxxv
Table ii
New product names mapped to original name(s) (continued)
Nortel GSM/UMTS MGW MGW UMGW (function of a

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

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

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

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

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

- Nortel SGSN/GPRS SGSN/GPRS GPRS SGSN,
- Nortel SGSN/UMTS SGSN/UMTS) UMTS SGSN,
U-SGSN, or USGSN
function of a Wireless
Gateway
Nortel UMTS RNC xxxx RNC xxxx RNC
Nortel Web Switch 184 Web Switch 184 Alteon Web Switch 184
—sheet 2 of 3—

xxxvi About this document
Table ii
New product names mapped to original name(s) (continued)
Nortel Wireless Network W-NMS Preside for Wireless

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

1-1
Introduction 1
This section introduces the GPRS network and the Nortel SGSN as it relates
to the GPRS network nodes and interfaces.
General Packet Radio Service 1

General Packet Radio Service (GPRS) is a second generation (2G) wireless
standard based on a Global System for Mobile communications (GSM)
access network and Mobile Application Part (MAP) core. Nortel offers a
complete GPRS portfolio covering both radio access and the backbone Core
Network. GPRS offers direct Internet Protocol (IP) connectivity and provides
packet radio access to external packet data networks (PDN).
The Nortel GPRS network architecture is implemented on the existing wireless

infrastructure with the inclusion of the following network entities:
• Serving GPRS Support Node (SGSN)
• Gateway GPRS Support Node (GGSN)
• SS7/IP Gateway (SIG)
• Packet Control Unit Support Node (PCUSN)
The placement of the SGSN with respect to standard interfaces is shown in

Figure 1-1. Note that this diagram is not representative of hardware quantity
for the SGSN cluster.

1-2 Introduction
Figure 1-1
Nortel SGSN and its relationship to GPRS specified interfaces
SMS-GMSC
SMS-IWMSC SM-SC
E C
Gd
MSC/VLR HLR
SCP D
Gs Ge
A
Gc
SGSN Complex Gr
Gb
SIG
TE MT BSS Gx’
R Um Gi
SGSN
GGSN PDN TE
Gn Gn
Ga
SGSN Ga
CGF
Gp
X1
LIG
W-NMS Policy Services
OA&M
GGSN
Other PLMN
Signalling Interface
Signalling and Data Transfer Interface
Gx’ ≡ Gs’, Ge’, Gd’, Gr’ – Proprietary interfaces between the SGSN and the SIG
The user equipment consists of the

• Mobile Terminal (MT) — The MT is responsible for correctly
formatting, or rate adapting, the data stream from the connected
equipment for transmission over the air interface. The MT also performs
the necessary functions to forward the data from the network to the
connected equipment.

Introduction 1-3
• Terminal Equipment (TE) — The TE runs user applications. For

example, this may be a personal computer running a web browser or other
data communications software or some other data device.
The MT and the TE are collectively referred to as the Mobile Station (MS).
The primary network nodes are

• GPRS Support Node (GSN) - A GSN contains functionality required to
support GPRS. The GPRS Support Nodes include two elements: the
Gateway GSN (GGSN) and the Serving GSN (SGSN). These elements
may be co-located or separate. The SGSN and GGSN contain IP routing
functionality and may be interconnected with IP routers.
— Serving GPRS Support Node (SGSN) - The SGSN performs
mobility management, implements authentication procedures and
routes packet data.
The SGSN requests location information from the Home Location
Register (HLR) through the Gr interface. These messages are routed
through the SS7/IP Gateway (SIG), which provides interworking
between GPRS nodes in an IP network and GSM nodes in a signaling
system 7 (SS7) network.
— Gateway GPRS Support Node (GGSN) - The GGSN provides the

point of interconnection with external PDNs for Public Land Mobile
Networks (PLMN) supporting GPRS. This interconnection utilizes
the Gi interface.
The GGSN stores routing information for attached GPRS users. The
routing information is used to tunnel Protocol Data Units (PDU) to the
current point of attachment of the MS; for example, the SGSN.
• SS7/IP Gateway (SIG) - The SIG provides a relay function between the
SGSN and the SS7 nodes. In this release, the SIG supports the Gd
interface between the SGSN and Gateway MSC for Short Message
Services/Interworking MSC for Short Message Services (SMS-GMSC/
SMS-IWMSC), the Ge interface between the SGSN and the Service
Control Point (SCP), the Gr interface between the SGSN and HLR, and
the Gs interface between the SGSN and the MSC/VLR. Multiple SGSNs
exist in the GPRS network, making the SIG responsible for routing
messages from the GSM HLR or MSC to the correct SGSN.
• Home Location Register (HLR) - The HLR is a network database used
for permanent management of mobile subscribers within a PLMN. It is
accessible from the SGSN through the Gr interface. The HLR includes
GPRS subscription data and routing information.
• Base station system (BSS) - The BSS provides the air interface resources
and is composed of the Base Transceiver Station (BTS) and the Base

1-4 Introduction
Station Controller (BSC). The BSS also includes the Packet Control Unit
Support Node (PCUSN).
• Packet Control Unit Support Node (PCUSN) - The PCUSN is a node in
the BSS which interacts either directly or indirectly with all the BSS
nodes, except the Transcoder Unit (TCU), such as the BSC, the BTS and
the Operation and Maintenance Center - Radio (OMC-R). The main
function of the PCUSN is to manage channel and radio link control.
• Mobile Switching Center (MSC) - The MSC is responsible for call
processing and circuit-switched data. The MSC does not perform
functions for the GPRS network.
The primary supported interfaces are

• Ga - The interface between the SGSN and the Charging Gateway
Function (CGF).
• Gb - The interface between the SGSN and the BSS. This interface is
frame relay.
• Gd - The interface between the SGSN and the Gateway MSC for Short
Message Services or Interworking MSC for Short Message Services
(SMS-GMSC or SMS-IWMSC).
• Ge - The interface between the SGSN and the SCP. The Ge interface is
used for Customized Application for Mobile network Enhanced Logic
(CAMEL) phase 3 services.
• Gi - An external interface between the GGSN and another type (non-
GPRS) of packet network.
• Gn - The interface based on IP that is between the SGSN and the GGSN.
• Gp - The interface based on IP that is between the SGSN and the GGSN
in different PLMNs.
• Gr - The interface between the SGSN and the HLR.
• Gs - The interface between the SGSN and MSC/VLR. The Gs interface
provides mobiles the ability to communicate with the MSC/VLR for
circuit switch services while they are attached to the packet network.
• X1 - A set of three interfaces between a network and a Lawful Intercept
Delivery Domain.
• Gr', Gs', Gd' Ge'- The interface between the SGSN and the SIG. These
are Nortel proprietary messaging interfaces.

Introduction 1-5
Table 1-1 summarizes SGSN support of the standard interfaces in the

GPRS6.0 release.
Table 1-1
GPRS6.0 SGSN interface support
Interface Supported Notes
Ga Yes
Gb Yes
Gd Yes via the SIG
Ge Yes via the SIG
Gf No
Gn Yes
Gp Yes
Gr Yes via the SIG
Gs Yes via the SIG
X1 Yes
The following figures represent the protocol stacks used in this

implementation of a GPRS network. Figure 1-2 illustrates the user plane (U-
plane), or datapath, between the MS and the GGSN. Figure 1-3 illustrates the
control plane (C-plane), or signaling path, between the MS and the SGSN.

1-6 Introduction
Figure 1-2
U-plane protocol stacks between the MS and the GGSN
Um Gb Gn Gi
App.
IP IP IP
SNDCP SNDCP GTP GTP
LLC LLC UDP UDP
RLC Relay
RLC BSSGP BSSGP IP IP
MAC MAC NS NS L2 L2 L2
GSM GSM L1 (FR) L1 (FR) L1 L1 L1

RF RF
MS PCUSN SGSN GGSN
App. - Application Layer L2 - Layer 2

BSSGP - BSS GPRS Protocol LLC - Logical Link Control
FR - Frame Relay MAC - Medium Access Control
GSM RF - GSM Radio Frequency NS - Network Services
GTP - GPRS Tunneling Protocol RLC - Radio Link Control
IP - Internet Protocol SNDCP - SubNetwork Dependent Convergence
L1 - Layer 1 Protocol
The C-plane consists of protocols for control and support of the U-plane
functions:
• controlling the GPRS network access connections, such as attaching to
and detaching from the GPRS network
• controlling the attributes of an established network access connection,
such as activation of a Packet Data Protocol (PDP) address

Introduction 1-7
• controlling the routing path of an established network connection in order

to support user mobility
• controlling the assignment of network resources to meet changing user
demands
• providing supplementary services
Figure 1-3
C-plane protocol stacks between the MS and SGSN
Um Gb
SM SM
HLR
Cache
GMM GMM
LLC LLC
RLC Relay
RLC BSSGP BSSGP
MAC MAC NS NS
GSM GSM L1 (FR) L1 (FR)

RF RF
MS PCUSN SGSN
GMM - GPRS Mobility Management

SM - Session Management

1-8 Introduction
GPRS SGSN product 1

The Nortel GPRS SGSN product is based on the Nortel Passport 15000 and
the Nortel SS7/IP Gateway (SIG) which performs SS7 signaling on behalf of
SGSN(s).
The externally visible SGSN core interfaces are implemented to align with
the standard definition of the interface. The SGSN supports Release 4 of the
GPRS Standards. The following sections describe the SGSN interfaces that
are implemented on the Passport 15000 and SIG.
Ga interface
Ga is the interface between GSNs (SGSNs and GGSNs) and the Charging
Gateway Function (CGF). GTP' is the protocol used for the Ga interface
(GSNs to CGF). GTP' can be used to collect CDRs from any GPRS element
that supports this interface. This feature is desirable for operators who have
multiple GPRS suppliers in the core network and plan to collect billing
records at a common CGF platform. For more information about the SGSN
Accounting System (SAS), refer to Chapter 6, “Accounting”.
SAS is supported over various Layer 2 and Layer 1 options as shown in

Figure 1-4.

Introduction 1-9
Figure 1-4
Message protocol stacks for the Ga interface
Ga
GTP’ GTP’
UDP UDP
IP IP
AAL5 AAL5
Ethernet Ethernet
ATM ATM
L1 100BaseT L1 100BaseT
SAS CGF
SAS - SGSN Accounting Server CGF - Charging Gateway Function
Gb interface
The Gb interface is the name given to the logical connection between a SGSN
and a BSS (also referred to as a PCUSN or PCU). (The Um interface applies
between the BSS and MS.) Even though the physical Gb interface is between
the SGSN and the BSS, it includes the LLC and SNDCP protocol layers,
which are used for logical communication directly between the SGSN and
MS. See Figure 1-3.
The Gb layers on the SGSN are:

• Frame Relay transport (FR) - This is the Frame Relay network
underlying the protocol stack (the Network Services (NS) layer and
above). It serves to route packets between the SGSN and the BSS.
• Network Services (NS) layer - The NS layer creates Network Services
Virtual Connections (NS-VC). The NS-VCs provide end-to-end
communication between the BSS and the SGSN. These NS-VCs can be
multiplexed over a single physical link.

1-10 Introduction
A group of NS-VCs belongs to a particular Network Services Entity

(NSE), a logical entity that is defined end-to-end between the SGSN and
PCU. End-to-end signifies that both the SGSN and the PCU must be
statically provisioned by the operator with the same identifier. The
purpose of the NSE is to provide network management services on a per-
NS-VC basis. These services include circuit blocking and unblocking,
and notification to higher layers of congestion on the Frame Relay
network.
NS-VCs are Frame Relay Permanent Virtual Connections. Virtual

connections (VCs) provide the user with the equivalent of a physical
connection to a destination address using shared facilities. A VC is
anchored in the processor cards connected to the end user devices.
Note: All NS-VCs within the same NSE must have the same bandwidth.
For example, if NS-VC 12 in NSE 3 has a total bandwidth of 128 kbit/s,
all NS-VCs within NSE 3 must have a total bandwidth of 128 kbit/s.
• Base Station System GPRS Protocol (BSSGP) layer - The BSSGP layer
creates BSSGP Virtual Connections (BVCs), which provide
communication paths between peer BSSGP entities. Capabilities of the
BSSGP include management of its BVCs, performance of flow control on
them, and relay of signaling messages to and from the GMM layer.
All BVCs within an NSE are unique. A single BVC carries all traffic for
exactly one cell. Traffic for a BVC may use any NS-VC in service within
its NSE. For more information on BVCs, see “BSSGP Virtual
Connections (BVCs)” on page 2-4.
• Logical Link Control (LLC) layer - Resides at layer 2 in the OSI model
(that is, the “Data Link Layer”). LLC among other things provides
acknowledged and unacknowledged data transfers with the peer LLC
entity in the MS. LLC also supports data error detection by performing
the Cyclic Redundancy Check (CRC) procedure, as well as optionally
supporting user data encryption/decryption when requested by the user.
• SubNetwork Dependent Convergence Protocol (SNDCP) layer - The
SNDCP layer multiplexes multiple PDP contexts from a user onto a
single logical link to send to the LLC layer. It optionally supports V.42bis
compression for the user data and RFC-1144 compression for
Transmission Control Protocol (TCP)/IP packet headers.
Gd interface
The Gd interface is a signaling link that provides point-to-point Short
Message Service (SMS) message transfers between the SGSN and Short
Message Service – Mobile Services switching Center (SMS-MSC). For more
information about SMS on the SGSN, refer to section “GPRS Short Message
Service (SMS)” in Chapter 5, “Services and features”.

Introduction 1-11
Figure 1-5 illustrates the message protocol stacks for the SGSN, SIG, and
SMS-MSC. The signaling protocol plane consists of protocols for control and
support of the transmission plane functions, that is, point-to-point short
message mobile originated transfer and short message mobile terminated
transfer.
Figure 1-5
Message protocol stacks for the Gd interface
MAP MAP
TCAP Relay TCAP
SCIP SCIP
SCCP SCCP
TCP TCP
IP IP MTP3 MTP3
AAL5 Ethernet L2 MTP2 MTP2
ATM
L1 100BaseT Gd' L1 L1 L1
Gd
SGSN SIG SMS-MSC
L2/1 - Layer 2/1 SCIP - SCCP Client Interface Protocol (Nortel

MAP - Mobile Application Part proprietary)
MTP - Message Transfer Part TCAP - Transaction Capabilities Application
SCCP - Signaling Connection Control Part Part
Ge interface
The Ge interface provides SGSN connectivity to the SCP in the GPRS/UMTS
network. The SGSN transports CAP/TCAP messages over IP to the SIG
using the Ge' interface, a Nortel proprietary interface for passing SCCP Client
Interface Protocol (SCIP) messages. The SIG then transports these messages
over SS7 using SCCP to the SCP.
SCP.

1-12 Introduction
Figure 1-6
Message protocol stacks for the SGSN, SIG, and SCP
Ge' Ge
CAP CAP
TCAP TCAP
SCCP
SCIP SCIP SCCP
MTP3 MTP3
TCP TCP
IP IP
L2 L2 MTP2 MTP2
L1 L1 L1 L1
SGSN SIG SCP
L2/1 - Layer 2/1 MTP - Message Transfer Part

IP - Internet Protocol SCCP - Signaling Connection Control
TCP - Transmission Control Protocol Part
SCIP - SCCP Client Interface Protocol SCP - Service Control Point
(Nortel proprietary) CAP - CAMEL Application Part
TCAP - Transaction Capabilities
Application Part
Gn and Gp interfaces
The Gn interface is the name given to the interface based on IP that is
between the SGSN and the GGSN. The Gp interface is the name given to the
interface based on IP that is between the SGSN and the GGSN in different
PLMNs.
The Gn and Gp interfaces utilize the GPRS Tunneling Protocol (GTP) (see
Figure 1-2). GPRS Tunneling Protocol allows multi-protocol packets to be
tunneled through the GPRS backbone between the GSNs. GTP utilizes User
Datagram Protocol (UDP)/IP and creates a “tunnel” between the SGSN and
the GGSN for each MS user.

Introduction 1-13
There are two GTP planes:

• GTP-C: Carries signaling traffic and path management messages across
the interfaces where it is used. The GTP signaling messages are used to
create, modify, and delete tunnels. GTP-C resides on the GSC card (see
“GTP-C” on page 2-9).
• GTP-U: Carries user data traffic and path management across the
interfaces where it is used. GTP uses a tunneling mechanism that is based
on UDP/IP to provide an encapsulated datagram service for carrying user
data packets. GTP-U resides on the GSD card.
Functionally, GTP in the SGSN handles the following functions:
• interacting with the SM layer in the SGSN to initiate all GTP signaling
messages or handle any signaling message coming from GGSN node
• interacting with the SNDCP layer to handle all user data packets from and
to the SNDCP layer
• interacting with the UDP/IP layer to tunnel all GTP messages, both
signaling and Transport Protocol Data Unit (TPDU), from and to its peer
GGSN node
• handling path management across the GTP tunnels as required in
specification GSM 09.60
Gr', Gs', Gd', and Ge' interfaces
In the GPRS network reference architecture, the Gr, Gs, Gd, and Ge
interfaces are transported through SS7 networks. Since the Passport 15000-
based SGSN communicates only using IP, an SS7/IP conversion is necessary.
Nortel provides this conversion through the HP-based SS7/IP Gateway (SIG).
For the purposes of this document, the interface between the SIG and the
SGSN is known as Gr', Gs', Gd', or Ge', depending on whether the reference
interface is Gr, Gs, Gd, or Ge, respectively.
Gr interface
The Gr interface is the name given to the interface between the SGSN and the
HLR.
All operations relevant to SS7 signaling and the HLR in the GPRS system are
handled through the Gr interface and by the GPRS signaling system which
includes MAP. Messages using the Gr interface may be initiated by the HLR
or by the SGSN. A MAP/TCAP protocol stack resides on the MAP card on
the SGSN, providing MAP protocol services for the MAP based interfaces
(Gr and Gd). The SGSN transports MAP messages over IP to the SIG using
the Gr’ interface, a Nortel proprietary interface for passing SCCP Client
Interface Protocol (SCIP) messages. The SIG then transports these messages
over SS7 using SCCP to the HLR. For more information regarding the SIG,
refer to NTP 411-5221-975, GPRS/UMTS SS7/IP Gateway User’s Guide.

1-14 Introduction
The MAP Client (MAP-C) is a subsystem of the SGSN GPRS Subscriber

Control. The MAP-C is responsible for sending MAP messages to the HLR
based upon events in the HLR-Cache. The MAP-C utilizes the MAP Stack to
send and receive MAP messages to and from the HLR. See “MAP Client” on
page 2-12.
HLR.
Figure 1-7
Message protocol stacks for the SGSN, SIG, and HLR
Gr' Gr
MAP MAP
TCAP TCAP
SCCP
SCIP SCIP SCCP
MTP3 MTP3
TCP TCP
IP IP
L2 L2 MTP2 MTP2
L1 L1 L1 L1
SGSN SIG HLR
L2/1 - Layer 2/1 MTP - Message Transfer Part

IP - Internet Protocol SCCP - Signaling Connection Control
TCP - Transmission Control Protocol Part
SCIP - SCCP Client Interface Protocol MAP - Mobile Application Part
(Nortel proprietary)
TCAP - Transaction Capabilities
Application Part

Introduction 1-15
Gs interface
The Gs interface is the signaling link between the MSC/VLR and the SGSN.
The Gs interface enables mobiles to communicate with the MSC/VLR for
circuit switch services while they are attached to the packet network.
BSSAP+ is the protocol used in the Gs interface.
The BSSAP+ Client is an application that resides on the SGSN and provides
the SGSN with the capability to send and receive BSSAP+ messages to and
from the MSC through the SIG.
MSC/VLR.
Figure 1-8
Message protocol stacks for the Gs interface
SGSN Gs' SIG Gs MSC/VLR
BSSAP+ BSSAP+
SCIP SCIP SCCP SCCP
TCP TCP MTP3 MTP3

IP IP
L2 L2 MTP2 MTP2
L1 L1 L1 L1
L2/1 - Layer 2/1 MTP3/2 - Message Transfer Part 3/2

IP: Internet Protocol SCCP - Signaling Connection
TCP - Transmission Control Protocol Control Part
SCIP - SCCP Client Interface Protocol
(Nortel proprietary)
BSSAP+ - Base Station System
Application Part +
X1 interface
The interface between the SGSN and the Delivery Domain (DD) for Lawful
Interception (LI) is referred to in 3GPP TS 33.107, “Technical Specification
Group Services and Systems Aspects; 3G Security; Lawful Interception
Architecture and Functions” as the X1 interface. X1 is further divided into 3
sub-interfaces:
• X1-1 Administration functions

1-16 Introduction
• X1-2 Intercept Related Information (IRI)

• X1-3 Content of Communication (CC)
Refer to “Lawful Interception (LI)” on page 5-68 for more information about
LI.
Release 97 and Release 99 standards support

In the GPRS5.0 release, the SGSN is compliant to the March 2002 Release 99
standards for all procedures that were supported in GPRS release 97 (Nortel
SGSN GPRS2.1). This section describes SGSN Rel97-Rel99 support for the
affected GPRS interfaces. Refer to NTP 411-5221-201, Specifications for
UMTS/GPRS Packet Core Conformance Guide for complete compliancy
information.
Ga interface
There is no Rel99-Rel97 fallback mechanism on this interface since there are
no header or parameter changes in Release 99.
Gb interface
There is no Rel99-Rel97 fallback mechanism on this interface since the only
difference between BSSGP Release 97 and Release 99 messages are optional
parameters. Optional parameters are ignored if the receiving entity does not
support the parameters.
Gd' interface (SGSN - SIG)

Gn and Gp interfaces
Whenever the SGSN communicates with another GSN, it sends a Release 99
message the first time. Each outgoing request is associated with a timer. Upon
expiry of the timer, i.e. failure to receive a response, GTP attempts in Release
99 format for the maximum number of times defined in the respective
attempts attribute.
If the number of attempts is exhausted, GTP falls back and sends the same
request in Release 97 format (GTP notes that future communications with that
GSN requires Release 97). Once the paths to that GSN are deleted, version
discovery between peers will reoccur after a period of inactivity, therefore
restarting communications with Release 99.
Gr' interface (SGSN - SIG)

The MAP Stack on the SGSN supports sending both Release 97 and Release
99 messages to the HLR for backwards compatibility reasons. A fallback
table is created to store all HLRs that cannot perform Release 99 V3
messaging. When the SGSN MAP initiates a dialogue with the HLR, the

Introduction 1-17
MAP performs a check on the destination IMSI (HLR number) to see if the
HLR is in the table. If an HLR is found, then Release 97 V2 is sent. If not
found, the Release 99 V3 is sent. The SGSN MAP, by default, assumes that
an HLR can handle Release 99 V3. If that assumption is incorrect, the HLR
will send a U-Abort back to the SGSN MAP. The SGSN MAP will verify that
the version incompatibility caused the U-Abort message. If so, the HLR
number will be added to the fallback hash table.
Gs' interface (SGSN - SIG)


1-18 Introduction

2-1
Functional description 2
The Nortel SGSN is built upon the Passport 15000 Variable Speed Switch
(VSS) product. Passport 15000-VSS is a high-speed packet switch providing
an integrated set of data, voice, video, and image networking services.
The SGSN performs similar functions as the Nortel GSM/UMTS MSC except
that it processes packet data instead of circuit-switched data. The main functions
of the SGSN include
• detect new GPRS mobile stations in its service area
• send and receive data packets to and from the mobile stations
• record the location of mobile stations inside its service area
One of the main roles of the SGSN is to perform data packet routing, using IP
as the network layer protocol. The Passport 15000 InterLan Switching (ILS)
platform is implemented as the routing engine for the GPRS network
developed by Nortel.
Another key role of the SGSN is mobility management. This encompasses

activities such as session management and state control. Mobility
management also handles data packet routing on the downlink to the mobile
station, including location tracking and authentication between the Mobile
Station (MS), user, and network using information on the subscriber-identity
module (SIM) card.
In addition to these two key roles, the SGSN provides a number of other
functionalities. These include ciphering and compression.
Note 1: The SGSN is supported on the Passport 15000 platform

functioning as an SGSN. The SGSN is not supported on the Passport
20000.
Note 2: A node functioning as an SGSN does not support other GSM

applications, such as the Nortel GSM/UMTS Interworking Function
(IWF) or the PCUSN. The node only supports SGSN functionality.

2-2 Functional description
SGSN software architecture 2

The SGSN software is divided into three major components:
• GPRS Transport Layer (GTL) interface protocols
• GPRS Subscriber Data (GSD) interface protocols
• GPRS Subscriber Control (GSC) interface protocols
The combination of the Subscriber Layer protocols, GSD and GSC, are
collectively referred to as GPRS Subscriber Layers (GSL).
The SGSN has the following additional peripheral functionality.

• SGSN Accounting Server (SAS)—Responsible for SGSN billing. The
SAS is considered a separate component, and resides on a separate
function processor from the primary SGSN components. SGSN billing is
described in Chapter 6, “Accounting”.
• MAP Stack—The MAP Stack is described in “MAP/TCAP Stack” on
page 2-17.
• Lawful Intercept component—provides lawful interception functionality
on the SGSN. See Chapter 5, “Services and features”, section “Lawful
Interception (LI)” on page 5-68.
Domain Name System (DNS) Agent is an external component used by GPRS

components. DNS Agent is described in “Domain Name System Agent” on
page 2-23.
GPRS Transport Layer 2

The GTL application performs several functions:
• Terminates the Gb interface between the BSS and SGSN.
• Terminates the Network Service (NS) protocol between the BSS and
SGSN.
• Terminates the Base Station System GPRS Protocol (BSSGP) between
the BSS and SGSN.
• Provides transfer of uplink/downlink control and bearer traffic in the
Packet Domain between an MS and SGSN over the Gb interface.
• Communicates with GSDs through multi-shelf communication or over
the Passport 15000 backplane if GTLs are co-located with GSDs on the
7K shelf.
The GTL protocols are not cognizant of the subscriber related activities; this
information is at the GSD and GSC components. The GTL is transport for
both the U-plane and the C-plane.

The GTL is hosted on a 7K shelf on a 32pMSA (E1/DS1) Function Processor

(FP), or on a 15K shelf on a 4pOC3MmAtm FP. The GTL must be
provisioned exclusively on the 15K, or on one of the two 7K shelves (one or
the other 7K, not both). Only one GTL may be provisioned per FP, and no
other SGSN applications may be present concurrent with the GTL
application. The GTL may be provisioned on the same 4pOC3MmAtm
providing inter-shelf communications but is not recommended.
The GTL application does not support an in-service software upgrade

strategy.
Network Service Entity (NSE)

The Network Service Entity (NSE) manages all the physical and logical
connections used to route packets between the SGSN and the mobile, through
the BSS. An NSE is statically provisioned on both the SGSN and the BSS.
BSSGP Virtual Connections (BVCs) and Network Service Virtual
Connections (NS-VCs) can be thought of as entities that are part of a NSE.
The term NSE management refers to management of NSE, BVCs, and NS-
VCs.
NS-VCs can essentially be thought of as entities that provide the transport

mechanism between SGSN and BSS. Each NS-VC has a one-to-one
relationship with a DLCI (Data Link Connection Identifier). NS-VCs across
an SGSN work in a load shared fashion, that is, provide multiple access
routes between SGSN and BSS. Load-sharing functions at the BSS and the
SGSN are independent. Therefore, uplink and downlink packets for a
subscriber may be transferred over different NS-VCs. Within an NSE, an NS-
VC can carry traffic for any BVC. For a BVC, when there is no unblocked
NS-VC left between a BSS and an SGSN, the NS at the source discards the
corresponding traffic.
For information about NSE redundancy, see “NSE redundancy” on page 4-7.

BSSGP Virtual Connections (BVCs)

BVCs are logical entities that have significance only within a single NSE. A
single BVC represents a single cell within a PCU. A Nortel SGSN can
support up to 21000 BVCs.
BVCs are created at the PCU through operator provisioning. After a BVC is
created, the PCU sends a BVC RESET message to the SGSN. If the BVC
specified in the message is unknown at the SGSN, the message causes the
SGSN to dynamically create the BVC with a particular BVCI (BVC
Identifier) number in the SGSN on every GTL serving the NSE associated
with this BVC. Every GTL application that supports a particular NSE also
supports every BVC defined within that NSE.
BVC blocking and unblocking functions can be initiated only by the BSSGP
entity at the PCU side.
BVC flow control

The SGSN is required to control downlink packets destined for each BVC
based upon flow control messages received from the PCU. BSSGP uses the
leaky bucket flow control algorithm. Essentially, the bucket (Bmax) is a
variable representing how much downlink packet data the PCU can buffer.
The leak rate (R) represents the rate at which the PCU can send data to the
mobile(s) served by a particular BVC across the air interface. The PCU can
change the variables of this algorithm by sending the SGSN BSSGP entity a
flow control message. It is possible for the PCU to completely stop downlink
packets by setting the leak rate to zero.
BVC unavailability
A BVC is defined as unavailable if any of the following conditions are true:
• A BVC is blocked beyond a provisioned amount of time
• Bmax = 0 for the BVC beyond a provisioned amount of time
• R (leak rate) = 0 for the BVC beyond a provisioned amount of time.
An alarm is set when an NSE entity determines that the number of its
unavailable BVCs exceeds the provisioned high-water threshold. The alarm is
cleared when the number of unavailable BVCs drops below the provisioned
low-water threshold. For more information about SGSN alarms, see NTP
411-5221-500, SGSN Alarms Reference Manual.
When this alarm is set, the operator can display statistics to determine which
BVCs are unavailable and why they are unavailable. Statistics can be viewed
with the MultiService Data Manager (MDM) tool. For more information
about BVC provisionable and operational statistics, refer to NTP 411-5221-
060, SGSN Components Reference Manual.

Refer to “OSI states” on page 7-56 for Nse component OSI state information.
GPRS Subscriber Data 2

The GSD application performs several functions:
• Terminates the Logical Link Control (LLC) protocol between the MS and
SGSN (encryption/decryption and CRC calculation is performed in
software or on the on-board Field Programmable Gate Array (FPGA),
depending on provisioning).
• Terminates the SNDCP protocol between the MS and SGSN.
• Provides V.42bis data compression per the SNDCP layer.
• Terminates the GPRS Tunneling Protocol (GTP) for bearer plane traffic
between the SGSN and GGSNs (via ATM or Ethernet I/O).
• Provides transfer of uplink/downlink bearer traffic in the Packet Domain
between an MS and GGSN.
• Provides transfer of control traffic between the MS and the SGSN (the
GSD forwards control traffic to a GSC).
• Downlink buffering
• IRAU buffering
• LLC Acknowledge buffering
• MS Flow Control
• Captures information related to billing.
The GSD application is hosted on the WPDS FP on a 7K shelf. Only one

GSD may be provisioned per FP, and no other applications may be present
concurrent with the GSD application.
In dual cabinet SGSN configurations, additional GSD cards can be deployed

on the second 7K shelf for increased capacity.
The GSD application does not support an in-service software upgrade

strategy. Multiple GSDs should be provisioned (N+1 load sharing) to achieve
high availability.
The GSD buffers downlink packets in the data path if the packet cannot be
immediately delivered to the mobile. For more information, see “SGSN
downlink PDU buffering” on page 5-65.

GPRS Subscriber Control 2

The GSC is responsible for the control plane in the Packet Domain. The GSC
consists of several individual software components that work together to
provide the GPRS Control Plane. The GSC responsibilities, and the applications
that handle them, include:
• Mobility Management
• Session Management
• GTP-C
• HLR Cache
• MAP Client
• SSF
• LI Client
• SMS
• BSSAP+
The GSC communicates signaling information over the Gn interface using

GTP, over the Gb interface using LLC, and over the Gr', Gs', Gd' and Ge'
interfaces using SCCP Client Interface Protocol (SCIP) over TCP/IP.
The GSC application is hosted on the General Services Processor (2pGPDsk).

Only one GSC may be provisioned per FP, and no other applications may be
present concurrent with the GSC application.
The GSC application supports 1:1 redundancy. In-service software upgrades

are not supported. Multiple GSCs may still be provisioned using the N+1 load
spreading redundancy method to achieve high availability. Note that when
dimensioning GSCs, it must be assumed that each GSC is executing at its
engineered level. This ensures that the SGSN is capable of supporting the
load of the accumulated GSCs.
Physically, all traffic for GSCs is via ATM, or Ethernet via a separate
2pGPDsk dedicated as a LAN FP, or ATM to the 7K and then Ethernet
through the 2pEth100BaseT on the 7K shelf. DNS queries will utilize the
same I/O route as the GTP-C. 1:1 Ethernet Line Sparing (ELS) is not
supported on the 2pGPDsk hosting the GSC application.
GPRS Mobility Management layer

The GPRS Mobility Management (GMM) layer communicates with the LLC,
BSSGP (through LLC), and SM layers. It functions as a control and a support
entity for the GPRS U-plane by performing such tasks as
• controlling network access such as mobile attaching and detaching

• performing security functions to guard against unauthorized access to the

network and to provide data confidentiality
• controlling the routing path of an established network connection in order
to support user mobility
• storing GMM context information for all active MSs
• handling all GMM functions for users, including suspend/resume and
paging. GMM also derives a Packet - Temporary Mobile Subscriber
Identity (P-TMSI) from the Temporary Logical Link Identifier (TLLI)
created by the LLC, and controls whether the P-TMSI should be re-
allocated by requesting that LLC define a new TLLI.
Handling of unknown routing area ID

GMM uses operator-defined routing area information to provide user
mobility management functionality such as GPRS attach, GPRS detach,
security, routing area update, location update and paging. A routing Area is an
operator-defined area consisting of one or more cells. One Routing Area
belongs to one and only one Location Area, and it is served by only one
SGSN. Each Routing Area is uniquely identified by its Routing Area
Identifier, which includes the Mobile Country Code (MCC as first 3 digits),
the Mobile Network Code (MNC as next 2 digits), the Location Area Code
(LAC as next 4 digits), and the Routing Area Code (RAC as last 2 digits).
On the SGSN, the operator must provision all the routing areas that the SGSN
supports. Provisioning attributes of a routing area include network service
entities, periodic routing area update timer value, etc.
When GMM is unable to look up the routing area information for a given
routing area ID, it generates an alarm to inform the operator to verify
provisioning of the unknown routing area ID. In addition, GMM performs the
following:
• Keeps track of a list of routing area IDs that GMM failed to look up. The
size of the list is 100 items. If there are more than 100 distinct routing
area IDs that need to be tracked, a LIFO mechanism is employed to allow
new unknown routing area IDs to replace old ones.
• Every time GMM tries to look up routing area information for a routing
area ID, but is not able to find it, it checks whether the routing area ID is
in the list of unknown routing area IDs:
— If it is not, it adds the routing area ID to the list of unknown routing
area IDs, and records the timestamp information.
— If it is, GMM updates the look-up failure timestamp information for
the unknown RAI.

• Every hour, on the hour, GMM generates the “gscRaiProvMissing”

message alarm to report all the routing area Ids that GMM failed to look
up during the past hour.
Operational attribute Gsc unknownRai enables the operator to display a list of

all the unknown routing area IDs (limited to the most recent 20) for a GSC.
To get the full list of 100 unknown RAIs per GSC, the operator must use data
from the message alarms.
Session Management layer

The Session Management (SM) sublayer is part of the C-plane protocol stack
that deals primarily with the PDP contexts for a user terminal. The SM layer
communicates with the GMM, LLC, SNDCP, and GTP layers. It enables the
MS to activate the packet data address it wants to use, whereby the MS makes
itself known in the corresponding GGSN. The SM sublayer handles
procedures for Identified PDP context Activation and Deactivation. The SM
stores PDP context information for all active sessions of an MS.
The PDP context contains information required for transferring data between
the MS and the PDN. A PDP context needs to be activated in the MS, the
SGSN, and the GGSN before the MS can send and receive GPRS data.
The GSC supports up to 11 simultaneously active PDP Contexts per IMSI.

This maximum number may include multiple primary and associated
secondary PDP contexts and may use the same APN.
Static IP address
When an MS undertakes a GPRS Attach procedure, the SGSN retrieves all
the subscription information corresponding to the MS’s IMSI from the HLR
and stores it in HLRC. HLRC stores subscription data for all active
subscribers.
Subscription data retrieved from HLRC has a PDP Address field

corresponding to each MS. If the contents of this field are zero (meaning
dynamic IP addressing) and the PDP Type is IP, then the GGSN assigns an IP
address to the SGSN using DHCP. If the PDP Address has a predefined value
(static IP addressing), then the SGSN uses this address to set up PDP Context.
IRAU supports both types of addressing for a PDP Context.
PPP PDU type

This allows an end-to-end PPP session from the mobile to the GGSN. Any
activate request which comes into the SGSN with a PDP Type Organization
of ETSI and a PDP Type number other than PPP (value 1) is interpreted as
X.121, which makes the protocol X.25. If the PDP type number of PPP is
received, it is transported with the same PPP protocol and type number.

GGSN reselection
During an activation procedure, the GGSN responds with a create PDP
context response message for a create PDP context request from the SGSN.
The cause Information Element (IE) in the response message indicates
whether the PDP context was created on the GGSN.
For certain failures on the GGSN side, including when a connection to the
internet/intranet destination (APN) is not available due to Gi interface failure,
the GGSN sends the Create PDP Context Response message to the SGSN with
one of the following reject causes for Release 99 interworking:
• No Resources Available
• System Failure
• User Authentication Failed
• All dynamic PDP Addresses are occupied
• No Memory Available
• Missing or Unknown APN
For Release 97 interworking, the GGSN responds with the following cause
values:
• No Resources Available
• System Failure
• User Authentication Failed
• Service not supported
Upon reception of these cause values, the SGSN retries creating the PDP
context on the next GGSN available for the APN selected. The SGSN tries up
to ten entries for GGSN addresses in the DNS agent’s list. If the SGSN runs
out of GGSNs for the selected APN, SGSN rejects the activation with the
failure cause value received from the last GGSN tried for activation.
GGSN reselection is bound by an activation timer. If the whole process of

reselection or retries exceeds the activation timer value, the SGSN abandons
the reselection and starts the Activation Rejection procedure.
GTP-C
The GPRS Tunnel Protocol – Control (GTP-C) plane is part of the GSC
function. GTP-C is the protocol between the GSC and the GGSN used to
communicate on behalf of the GMM and SM functions.
Path management
Path management is supported on the GTP-C plane. A path is a physical
connection (direct or indirect) between a pair of source and destination IP

address. Path management can be performed on any path in use. The path is
considered to be in use if at least one PDP (Packet Data Protocol) context
uses the path to the other GSN. The key role of path management is to trigger
GTP-C to send Echo Request messages and make sure the corresponding
Echo Response messages are received before indicating to the upper layer
that the path is down.
Following is general mechanism for current path failure detection and path
failure discovery on GTP-C:
• Path Failure Detection
When an SGSN communicates to a GSN for the first time, path
management creates a “path” entity representing that GSN and
continuously monitors the state of the path.
If path management detects the path’s lack of response to a signaling

request upon expiration of T3 for N3 times, it declares that the path or
GSN as failed. T3 and N3 are a provisionable Timer and Counter respectively.
• Path Failure Discovery

When the SGSN declares a GSN path as failed, it immediately marks the
path as being “down”. The upper layer will not place any new sessions on
the corresponding IP address, and instead direct them to the remaining
“good” IP address for the APN being requested by the mobile.
In addition to the current GTP-C path management implementation as

described in the 3GPP standards, the SGSN enhances GTP-C path
management as described in the following sections.
GTP-C path failure management

When GTP-C detects a path failure condition on a path, GTP-C starts a
“Grace Timer” period during which the SGSN attempts to recover the path.
This interval is specified in attributes Sgsn Gsc sgsnGraceTimer and
ggsnGraceTimer (default is 5 minutes). At this time, a “minor” path failure
detection alarm warns the operator that the system has detected a possible
path failure condition. During this Grace Period, Echo Request messages are
sent on the path once every 15 seconds until a response is received or the
Grace Period expires. Once the Grace Period expires, the path is declared
“Failed” and the operator is alerted to the failure with an alarm. If the path in
question is either a GGSN path with no current active sessions or an SGSN
path, the path is deleted immediately, and the path failure alarm is cleared.
Note: For information about GTP Path alarms, see NTP 411-5221-500,
SGSN Alarms Reference Manual.
However, if the path is a GGSN path with active sessions, the SGSN acts as if
the path failure is due to a network glitch, and is temporary. The SGSN

deletes the sessions associated with the path, but the path itself is saved in the
system temporarily until it is clear that the SGSN will no longer use it. The
path will increment a failure restart counter to be sent to the GGSN once
network conditions allow the path to recover. This restart counter indicates to
the GGSN that the SGSN detected path failure, and tells the GGSN that it
needs to clean up the associated GGSN sessions for the path. Cleaning up the
sessions on the GGSN ensures that reactivating mobiles on the recovered path
are able to successfully activate.
Path versioning
An internal “rediscovery” timer upon expiring signals to the SGSN to attempt
to upgrade a path from V0 to V1. This time interval is provisionable in
attribute Sgsn Gsc pathRediscoveryTimer. This rediscovery function
mitigates the instances in which two ends of a GTP-C path communicate V0
on nodes that support V1. If this condition were allowed to continue, it would
limit the SGSN’s capabilities. Some features such as SRNS and Secondary
PDP Context Activation work only on V1 paths.
If the GTP path between SGSN and GGSN falls back to V0, subscribers’
attempts to activate secondary activations will fail. Even after the path is
upgraded to V1, attempts to activate secondary activations for V0
contexts will fail. Subscribers must activate new V1 primary contexts to
activate associated secondary contexts.
In addition to the rediscovery timer, paths will attempt to upgrade themselves

from V0 to V1 any time an inbound V1 GTP-C message is detected on a V0
path. Both of these actions help in that new messages over an existing path
that has recently upgraded to V1 from V0 will be created as V1 messages.
This gives the SGSN a better chance to maintain communications in V1.
Cleanup mechanism for idle SGSN/GGSN paths

Any path (GGSN or SGSN) is cleaned up after a period of time (provisioned
using attribute Sgsn Gsc pathInactivityTimer) if there are no active PDP
contexts associated with the path. The countdown to cleanup is started upon
path creation for SGSN paths, since these paths do not have PDP contexts
associated with them. For GGSN paths, the path inactivity timer is started
when the path is created, stopped when the path becomes active, and started
again when the path no longer has active PDP Contexts associated with it.
This behavior protects the system from reaching the maximum number of
GTP Paths threshold by clearing out unused paths.
An operator can manually clear a GTP path based on an IP address. See

“Clearing a GTP path” on page 7-34.

GTP-C versioning per context

GTP-C supports versioning by context. This means that the SGSN handles
both V0 and V1 messages regardless of the path version. V0 messages are
handled on V1 paths and V1 messages are handled on V0 paths.
N3/T3 Improvements for DISCOVERY

During DISCOVERY for a GGSN type path, the provisioned n3/t3 values for
a particular message are ignored in favor of hardcoded values. This mitigates
problems during DISCOVERY where the SGSN is not given a chance to retry
a message (where the n3 was provisioned to 1). SM can also time out before
an activate attempt completes, thus aborting the attempt (when n3/t3 values
are set too high) and sending GTP-C into an endless loop of sending out
messages and having them aborted before the retry can be attempted. During
DISCOVERY, n3 retries is set to 4, and t3 is set to 2 seconds. In addition, the
path will enter PENDING_FAIL after exceeding the new n3 retries when in
DISCOVERY. These hard coded values do not apply to SGSN path type
messages.
Restrictions and limitations

Adjacent SGSN and GGSN nodes must support Echo Request/Response for
path version rediscovery and path recovery during Grace Period to work.
HLR Cache
The HLRs contain subscription information related to GPRS for all
International Mobile Subscriber Identities (IMSI) within a PLMN. The
SGSN, on the other hand, dynamically stores subscriber information related
to GPRS when a mobile enters the area under the control of this particular
SGSN. This entity in the SGSN which stores the subscription information is
known as the HLR Cache.
The HLR Cache is responsible for the administration, storage, update (from
the HLR) and retrieval of subscription data within the SGSN. The purpose of
this entity is to retain subscription records for a period of time even after the
MSs Detach. If the MSs reattach during the retention period, the subscription
records can be fetched locally from the cache, instead of getting them from
the HLRs. Additionally, the HLR Cache stores other information for active
MSs, such as authentication information, to reduce traffic to the HLRs.
Note: The HLR Cache does not keep any information related to the
active GMM and PDP contexts for each subscriber that is attached to the
SGSN.
MAP Client
The GSC may use any configured MAP card on any shelf for MAP protocol
transactions (see “Multishelf MAP” on page 2-18). The MAP Client exists as
part of the GSC for communicating to the MAP card.

Note: Within this document, the term “MAP/TCAP card” is used to refer
to the 2pGPDsk card hosting the MapStack and TcapStack components.
Likewise, “GSC card” refers to the 2pGPDsk card hosting the Gsc
component.
The MAP Client (MapClient or MAP-C) sends MAP messages to the HLR
using the MAP Stack upon receiving events from the HLR Cache (HLRC). It
sends MAP parameters to the HLRC for storage when MAP messages arrive
from the MAP Stack.
Figure 2-1 illustrates the MAP-C to MAP Stack interface as well as the SCIP
interface with the SIG.
Figure 2-1
MAP Client interfaces
TCP TCP
The main function of MAP-C is to keep a state machine of each on-going

MAP dialogue. Each state machine keeps track of all the relevant timers for
its MAP dialogue.
For all invoke messages on the Gr interface, MAP-C checks if the SCCP
Variant attribute is set to ITU. If so, MAP-C generates correct Global Title
digits for the invoke message by translating the IMSI from E.212 format into
E.214 format. According to TS 29.002, “3GPP MAP Specification, the
Global Title used for SCCP routing in an ITU area must be of type mobile
global title (an E.214 number).
The MAP Client counts as a Virtual User when Multiple (Virtual) Point
Codes (see “GSC addressing” on page 2-15) are utilized at the SIG.

Refer to “OSI states” on page 7-56 for MapClient OSI state information.
Node failure processing and MAP-C

The MAP-C application is affected by failures of other functional processors
in the SGSN and other nodes in the GPRS network. The effects of failures of
these other processors and nodes on MAP-C are described below:
• GSC card
The MAP Client is hosted on the GSC card. If the GSC card fails, the
Nodal Manager informs the MAP/TCAP stack about the failure, and it
deregisters the MAP Client applications. When the GSC card comes up
again, the MAP Client applications must register with the MAP/TCAP
stack again.
• MAP card
The MAP/TCAP Stack resides on the MAP card. If the MAP card fails,
the Nodal Manager informs the MAP Client about the failure. All the
current transactions are lost and the MAP Client must register with the
MAP/TCAP stack again when the MAP card comes back into service.
• SIG
If the SIG or TCP connection fails, the MAP/TCAP Stack keeps retrying
the connection. If this happens during initialization, the MAP Client can
not register successfully with the MAP/TCAP stack. However, if this
occurs after a successful registration, all messages sent by the MAP Client
are lost, and it times out on the message send.

MAP-C has the following restrictions:
• MAP-C does not change or add any incremental functionality for the
PCS-1900 market (for example, compliance with ANSI or other non
3GPP specifications).
MAP-C has the following limitations in this GPRS release:

• Τhe SAI dialogue has not been upgraded to V3 and the V2 SAI messages
are still used.
• The number of transactions the MAP-C may process at any given time is
1,024. Once the maximum value is reached, additional transactions are
rejected, until the concurrent transactions begin to be freed up again. The
operational attribute Gsc Mc transLimitDiscards counts the number of
times a transaction is rejected.

Service Switching Function (SSF)

The SSF provides the interface between regular call processing and the
Intelligent Network (IN). Its key tasks are to recognize mobile calls that
require IN service processing, and to interact with Call Control Function
(CCF) call processing and Service Control Function (SCF), residing on a
Service Control Point (SCP), service logic to ensure that those calls are
successfully completed. The SSF communicates via the MAP FP.
SSF counts as a Virtual User when Multiple (Virtual) Point Codes (see “GSC
addressing” on page 2-15) are utilized at the SIG. For more information about
the SSF, refer to “SSF” on page 5-25.
Lawful Interception (LI) Client

The GSC uses the LI application for relaying LI related information to a
Distribution Function (DF). The LI Agent of the GSC is responsible for
providing the Intercept Related Information (IRI) to the LI application. See
“Lawful Interception (LI)” on page 5-68 for details.
Short Message Service (SMS)

The GSC supports mobile-terminated and mobile-initiated SMS. It also
provides a proprietary mechanism for pre-paid mobile-initiated SMS. For
more information, see “GPRS Prepaid Short Message Service (SMS)” on
page 5-18.
BSSAP+
The GSC terminates the BSSAP+ protocol from the MSC via the SIG (the Gs'
interface). The link between SGSN and SIG for BSSAP+ is over TCP.
BSSAP+ effectively provides a gateway between the packet domain and the
circuit domain for Class B mobiles which are capable of both circuit and
packet operation. By relaying information to the MSC/VLR via the BSSAP+
protocol, the SGSN allows the MSC/VLR to route circuit pages through the
SGSN rather than over the A-Interface to the BSC.
BSSAP+ provides some other functionality as well, but its primary purpose is
to provide a paging facility.
GSC addressing
There are two SS7 addressing techniques that are supported by the GSC (and
SIG):
• Single Point Code (SPC)
• Multiple Virtual Point Codes (VPC)
Note: While the term “Virtual Point Code” is used, the point code is
visible to external SS7 network as a “real” point code. It is a PC of the
corresponding GSC.

With the SPC scheme (see Figure 2-2), the SIG is assigned a single PC and
each GSC is assigned a unique Global Title (GT) address (E.164 address). In
this case, the SIG performs an E.164 address to IP address mapping. The
advantage of this scheme is a minimal requirement for PCs, i.e., one per SIG.
The disadvantage is that if a GSC is out-of-service and the SIG is operational,
there is no way via SS7 Subsystem Maintenance messages to designate it.
Figure 2-2
Single Point Code scheme
SGSN
E.164u1 E.164u2 E.164ub
USC/
USC USC/
USC ... USC/
USC
GSC 1 GSC 2 GSC b
SIG SPC
SS7
HLRs
With the Multiple PC scheme (see Figure 2-3), the SIG is assigned a Local
Point Code (LPC) and each GSC is assigned a unique PC along with a unique
GT, or E.164 address. The advantage to this scheme is that SCCP Subsystem
maintenance messages may be utilized for each GSC. There are two
disadvantages to this scheme:
• The quantity of PCs required, for example, N + 1 where N equals the
number of GSCs
• Virtual User restriction may limit capacity of the SIG (refer to NTP 411-
5221-975, SS7/IP Gateway User Guide, for more information).

Figure 2-3
Multiple Virtual Point Code scheme
SGSN
E.164u1 E.164u2 E.164ub
USC/
USC USC/
USC2 ... USC/
USC
GSC 1 GSC GSC b
PC u1 PC u2 PC ub
SIG PC
SS7
HLRs
With either scheme used, each GSC appears as a unique SGSN from the
HLR’s perspective.
The GSC may be configured with separate E.164 addresses for each
supported SS7 interface (Gd, Gr, Gs, Ge).
MAP/TCAP Stack 2
The SGSN contains SCCP subsystem applications that require access to the
HLR, VLR or SCP across the SS7 network. These are the MAP SGSN
subsystem applications, which handle messages for the Gr and Gd interfaces,
and the CAMEL applications (CAP subsystem), which handle messages
across the Ge interface.
The MAP/TCAP protocol stack on the SGSN’s MAP card provides MAP
protocol services for the MAP based (Gr and Gd) interfaces. The MAP
stack’s upper layer interface is with the MAP Client which provides MAP
primitives to the stack and acts as the MAP SGSN subsystem. The MAP stack
provides dialogue management only.
The TCAP stack can be used independently of the MAP stack. The TCAP
stack provides generic TCAP services to any application that uses TCAP to

send messages to its peers over the SS7 network. MAP makes use of the
services provided by TCAP and is a TCAP user.
Refer to “OSI states” on page 7-56 for MAP/TCAP stack OSI state
information.
Routing layer between MapStack and SIG

MAP sends the MAP, CAMEL Application Part (CAP), and TCAP protocols
over TCP/IP to communicate with the SIG. The SIG then removes the TCP/IP
transport protocol and replaces it with SCCP and MTP protocols for transport
through the SS7 network. Each MAP application communicates with one
primary SIG and may communicate with a secondary SIG in the case that
communication to the primary SIG fails.
Refer to “Special considerations for I/O routing” on page 2-26 for I/O
options.
Multishelf MAP
The MAP application resides on a General Services Processor (2pGPDsk),
which can be deployed on any 15K shelf in the SGSN. Up to four (4) fully
redundant active MAP cards are supported per shelf, for a maximum of eight
(8) MAP cards. Four MAP cards are provisioned as active and the other four
MAP cards are in warm standby. (For more information on redundancy,
including MAP card redundancy, see “Redundancy capabilities” on page 4-
1.)
Prior to this release, the MAP/TCAP server applications were accessible only
to clients located in the same shelf as the MAP/TCAP server. They were
connected to each other by means of provisionable service links. Every
MapClient application (on the GSC) was linked to a single MapStack instance
on the same shelf. Likewise, every ServiceSwitchingFunction (SSF) was
linked to a single TcapStack instance on the same shelf. A single MapStack or
TcapStack server could support one or more clients. See Figure 2-4.

Figure 2-4
MAP/TCAP single shelf configuration
SGSN
MAP/TCAP 1 MAP/TCAP 2
shelf
MapStack MapStack
TcapStack TcapStack
MapClient MapClient MapClient
SSF SSF SSF
GSC 1 GSC 2 GSC 3
A MAP/TCAP component may provide service to GSC components within

the same shelf as well as GSC components on another shelf within the same
SGSN (GSC components are supported only on the master 15k shelf). See
Figure 2-5. Although not shown in the diagram, it is also possible to provision
a MAP/TCAP component that services only remote clients. (Connecting lines
in the diagram represent provisioned associations only. They do not represent
physical links.)
Removing the previous restriction of requiring at least one MAP/TCAP card

to reside on a shelf where MAP/TCAP protocol services are needed gives
way for increased flexibility, reduced shelf footprint of MAP/TCAP cards,
and better MAP/TCAP card utilization. There can be fewer MAP/TCAP
cards servicing more clients. Such clients no longer have to reside on the
same shelf to get MAP protocol services. Thus, the MAP/TCAP cards can be
used to their full processing capacity.

Figure 2-5
MAP/TCAP multiple-shelf configuration
SGSN SGSN
shelf 1 (master) shelf 2 (slave)
MAP/TCAP card pair
MapStack
TcapStack
MapClient
SSF
GSC card
Inter-shelf MAP/TCAP card pair

links
MapClient
MapStack
SSF
TcapStack
GSC card
MAP card provisioning

Multishelf MAP adds new provisionable attributes to the MapClient and SSF
subcomponents under Gsc. The new MapClient attribute is called Gsc mc
remoteMapStackServer and allows the operator to provision the Shelf ID and
Instance of a MapStack component located on another shelf. The new SSF
attribute is called Gsc ssf remoteTcapStackServer and designates the Shelf ID
and Instance of a TcapStack component located on another shelf. These new
attributes are analogous to the existing linkToMapStack and linkToTcapStack
attributes that continue to provide CDL service links to a MapStack or
TcapStack residing on the same shelf as the GSC card.
When creating a MapClient-MapStack or SSF-TcapStack association, you

must provision either the CDL link or remote server attribute but not both.
Use linkToMapStack and linkToTcapStack for links to a local MAP/TCAP
card. Use remoteMapStackServer and remoteTcapStackServer for links to a
remote MAP/TCAP card. A “check prov” error will result if both attributes
are provisioned on the same MapClient or SSF component.
Inspecting remote MAP/TCAP associations

For local CDL links, the attributes linkToMapStackUsers (under MapStack)
and linkToTcapStackUsers (under TcapStack) provide a means for examining

which clients are associated with a particular MapStack or TcapStack

component. When remote/inter-shelf links are used, these attributes will be
empty. Instead, you can list the RegisteredClient components under
TcapStack and MapStack to see which clients are connected. The index of the
RegisteredClient component identifies the application type, shelf, and
instance of the all clients which have registered with the MAP or TCAP
server. For example, RegisteredClient/MAPC,0,1 refers to the MapClient on
Gsc/1 on the master shelf (shelf 0). RegisteredClient/SSF,0,2 refers to
ServiceSwitchingFunction on Gsc/2 on the master shelf (shelf 0).
The multishelf MAP feature creates the new RegisteredClient component

type. It is a dynamic subcomponent of MapStack and TcapStack. When a
client running on a local or remote shelf comes into service and registers with
the MAP/TCAP card, it causes a new RegisteredClient component to appear.
Upon deregistration or loss of communication with the client, the
RegisteredClient component disappears. The RegisteredClient component
currently contains no attributes.
Each RegisteredClient instance is identified by a three-part index:
RegisteredClient/<app type>,<shelf id>,<instance>
<app type> is MAPC or SSF, indicating MapClient or

ServiceSwitchingFunction.
<shelf id> ranges from 0 to 15.
<instance> ranges from 1 to 15 and indicates the provisioned instance of the

GSC hosting the client application.
Node failure processing and MAP Stack

The MAP Stack application is affected by failures of other functional
processors in the SGSN and other nodes in the GPRS network. The effects of
failures of these other processors and nodes on MAP Stack are described
below:
• GSC card—This card hosts the MapClient and the SSF, which are users of
the MapStack. If the card fails, the Nodal Manager informs the MAP/
TCAP stack about the failure, and it deregisters these applications. When
the GSC card comes up again, the applications must register with the
MAP/TCAP stack again.
• SIG—If the SIG or TCP connection fails, the MAP/TCAP Stack keeps
retrying the connection. If this happens during initialization, the
MapClient/SSF will not be able to register successfully with the MAP/
TCAP stack. However, if this occurs after a successful registration, all

messages sent by the clients are lost, and the clients will time out on the
message send.
The MAP/TCAP stack and multishelf MAP feature have the following
restrictions and limitations:
• The TCAP stack must be provisioned on the same card as the MAP Stack.
• The SSF/MapClients must have a unique point code and subsystem
number pair so that the messages can be routed correctly.
• A pair of active and standby MAP/TCAP cards must have the same
hardware type (2pGPDsk) and PEC code, and they must reside in the
same shelf.
• All affected cards must be running GPRS6.0 software before you may
configure inter-shelf links between a MAP/TCAP client and server.
• FP switchover will result in a loss of any transactions in progress. The
newly active MAP/TCAP card must re-establish communication with the
HP SIG before service resumes. See “MAP redundancy” on page 4-16.
• To minimize communication outages - as recommended in previous
releases - do not use the Ethernet ports provided on the MAP/TCAP
card’s faceplate. Instead, IP traffic should be routed through a separate
ATM card or LAN card. Using the faceplate ports may result in
switchover times exceeding one minute.
• If all MAP/TCAP cards for an SGSN are consolidated onto a single shelf,
future rolling upgrades will result in a total outage for a brief period of
time while the MAP/TCAP shelf is upgraded.
• Configuration of multi-shelf links is not validated at entry time. If the
shelf id and application instance are set improperly, the MapClient or SSF
component will generate an alarm. Check the component’s OSI state to
ensure that the service is working.
• Changing the linkage of MapClient to MapStack or SSF to TcapStack will
result in the loss of any transactions in progress and a brief interruption of
service to the affected client. Depending on what transactions are
outstanding, this may cause a brief spike in certain statistics such as
MapStack timeouts (e.g., uglTimeouts), MapClient mcTimeouts, and SSF
totalTssfTimeouts.
• The maximum number of clients that may simultaneously register with a
single MAP/TCAP card is 42. (This is increased from the previous limit
of 20 clients.) MapClient and SSF each count as separate clients. SMS is
also a client, but it only counts against this limit if it is provisioned with
mscEmulationMode set to on. (mscEmulationMode is a provisionable
attribute under the Sgsn Gsc component in the GprsSmsCpProv group.)

For example, suppose CAMEL is in use and mscEmulationMode is off. In

this case, one MAP/TCAP card can support 21 MAP clients and 21 SSF
clients - in other words 21 GSCs.
If neither CAMEL nor SMS is enabled, a single MAP/TCAP card can

support an upper limit of 42 GSCs. In the worst case, if CAMEL is in use
and SMS mscEmulationMode is on (requiring three clients per GSC), a
single MAP/TCAP card can support an upper limit of 14 GSCs.
Note: The actual engineering limits may be lower depending on the call
model.
• The MAP/TCAP card no longer supports the 1:1 cold standby

configuration. It also does not support the 1:N cold standby configuration.
• As in previous releases, the MapStack/TcapStack cannot share a card with
any other SGSN components (aside from IP Server).
• The linkToMapStack and linkToTcapStack attributes can be used with this
Multishelf Map Feature for only one set of redundant MAP cards on the
same shelf. If more than one set of redundant map cards reside on the
same shelf, the new remoteToMapStackServer and
remoteToTcapStackServer attributes must be used for both local and
remote provisioning.
Domain Name System Agent 2

The SGSN requires a name-to-IP address mapping mechanism in order for
applications to convert logical name addresses to their corresponding IP
addresses. This entity is known as the Domain Name System (DNS) Agent.
The DNS Agent is used by the SM to get the IP addresses of the GGSN. The
DNS Agent is also used in inter-SGSN handover at the new SGSN to query
the IP Address of the old SGSN (see “Packet service domain mobility” on
page 5-2 for more information about inter-SGSN handover).
To perform a DNS query, applications need to provide a logical name, for

example, www.nortelnetworks.com, to the DNS Agent, which is responsible
for retrieving information from its local cache table or sending request to a
domain name server. The DNS Agent acts as a service provider to
applications. In turn, it acts as a client to the provisioned domain name server.
The DNS Agent maintains a list of domain name servers to which queries are
sent. This increases the reliability that the required answer is received. Both
static and dynamic mapping are supported and can be used at the same time:
• static mapping—the operator provisions the mapping at the SGSN.
• dynamic mapping—the operator provides the domain name server
external to the SGSN.

The DNS Agent handles:

• maintaining a cache table, which includes a refreshing and purging
mechanism
• accepting multiple queries from applications
• interpreting responses when dynamic mappings are required
• returning the information, such as the IP address list and error code
indications, to the applications that request it
• implementing the retry mechanism
• querying the name server(s) if necessary
• multiplex concurrent requests
The DNS Agent is a “stub resolver” relying on the services of a recursive

name server on the connected network. This scheme allows the SGSN to pass
on the burden of the resolver function to a name server on another node. A
local cache table is maintained by the DNS Agent to facilitate the query
process.
For efficiency, a maximum of 10 IP addresses are stored in the cache table for
one logical name. The maximum entry held in the cache table is a
provisionable value (Dnsag maxDynamicEntries) which is the same as the
maximum number of the outgoing queries that one DNS Agent can handle at
the same time.
Note: The DNS query from the GSC should not be confused with a DNS
query from a mobile user, which is distinct and separate.
IP addressing and routing 2

This section contains information about Passport 15000 IP addressing and
routing used for the SGSN.
Passport 15000 Virtual Routers (VR)

Passport 15000 virtual routers (VR) provide a software emulation of physical
routers. A VR has two main functions:
• Constructing routing tables describing the paths to networks or
subnetworks
• Forwarding or switching packets to the final destination network or
subnetwork
VRs on a Passport 15000 node can perform the functions of independent
physical routers, forwarding packets to the correct destination, while isolating
traffic from other VRs in the same way that physical routers do. VRs also
have independent IP routing tables that are isolated from each other.

The management VR is a Passport 15000 VR that provides a single point of

external entry into the Passport 15000 node. The first VR provisioned
becomes the management VR. All VRs added after the management VR are
considered customer VRs.
The VR has logical ports, called Protocol Ports, which link the VR to
different media. Protocol Ports are assigned IP address(es).
IP access mechanisms and media

IP access can be achieved through the following interface protocols including:
• Ethernet
• ATM
• GPRS IP Server (GIPS)
Both the CP and the 2pGPDsk FPs offer Ethernet connectivity. Management
functions on the Passport 15000 node may use the CP Ethernet media for
external access. For a list of wireless applications that may use the 2pGPDsk
Ethernet media, refer to Table 2-3.
The ATM Multi-Protocol Encapsulation (ATM MPE) interface is an access

service that allows IP encapsulation over ATM in accordance with RFC 1483.
The ATM MPE service allows IP traffic to be transmitted across the ATM
network using the ATM MPE media.
GPRS IP Server (GIPS) is a wireless implementation of the IP protocol

family used specifically for wireless IP based applications allowing
origination and termination of IP traffic at the FP with the GIPS process. For
ease of implementation, GIPS uses the same media type as the Passport
15000 Point-to-Point Protocol (PPP). (GIPS registers itself as a “PPP” media
type with the Passport 15000 VR, but in reality, the PPP protocol is not used.)
Note: Passport 15000 shelves with wireless applications may not utilize
the PPP media that implies PPP over any interface type including Packet
Over Sonet (POS).
IP based applications
The applications running in the SGSN shelves requiring IP addresses are
shown in Table 2-1.
Table 2-1
IP based applications
Processor Clients # GIPS / FP # IP Addresses Address type
CP OA&M N/A 1 Routable IP @
—sheet 1 of 2—

Table 2-1
IP based applications (continued)
Processor Clients # GIPS / FP # IP Addresses Address type
GSC FP DNS Agent 1-3 1 - 3 based on Public IP @

GTP-C number of clients
BSSAP
GSD FP GTP-D 1 1 / GSD FP Public IP @
MAP FP SCIP 1 1 / MAP FP pair Routable IP @
SAS FP GTP’ 1-2 1 - 2 based on Routable IP @

number of clients
LI FP LICP
—sheet 2 of 2—
IP routing
Table 2-2 lists which routing protocols implemented within the Passport base
are supported on the SGSN.
Table 2-2
Routing protocol Support Comments
Static Yes Preferred for higher reliability
Open Shortest Path First Yes Dynamic routing

(OSPF)
Routing Information Protocol No No longer supported as of

(RIP) PC04
Border Gateway Protocol v4 No Never supported by SGSN/

(BGP-4) GPRS
When OSPF is used, it exists between the SGSN and the external network.
Static routing is still used for inter-shelf communications.
Special considerations for I/O routing

MAP, SAS, and LI applications reside on the 2pGPDsk. The traffic associated
with each of these applications may take one of four options:
• Faceplate port(s) on same FP
• Faceplate port(s) on intra-shelf FP sponsoring same application type, for
exanple, MAP
• 4pOC3MmAtm (recommended for better reliability)

• 2pGPDsk dedicated for I/O with no wireless application (recommended

for better reliability)
Faceplate port(s) on same FP
The applications listed above can use the Ethernet ports on the FP on which
that individual application resides. For example, MAP’s Gr traffic may be
routed over the faceplate ports of that same FP. Figure 2-6 shows an example
of Ga and X1 traffic using the faceport port of the 2pGPDsk FP.
Figure 2-6
Faceplate port(s) on same FP example
A 0 1 2 3 4 5 6 7
Ga, X1
Filler
CP Expansion
Filler
2pGPDsk
Filler
Filler
Filler
SAS/LI
2pGPDsk
Filler
SAS/LI
CP3
CP3
B 8 9 10 11 12 13 14 15
Filler
I/O
CP Expansion
2pGPDsk
Filler
Filler
Filler
Filler
Filler
I/O
2pGPDsk
4pOC3Filler
I/O
4pOC3Filler
I/O
Atm
Atm
Faceplate port(s) on intra-shelf FP

In the case of multi-active applications, (multiple active applications on the
same shelf), the I/O for that application type can be aggregated using a single
pair of FPs sponsoring that application. For example, one pair of MAP FPs
can be used to support the Ethernet I/O for all MAP applications on that same
shelf, as shown in the example in Figure 2-7.

Figure 2-7
Faceplate port(s) on intra-shelf FP example
A 0 1 2 3 4 5 6 7
Filler
Filler
2pGPDsk
Filler
Filler
CP Expansion
2pGPDsk
Filler
Filler
2pGPDsk
MAP
MAP
MAP
CP3
CP3
2pGPDsk
MAP
Gd, Ge, Gr, Gs
B 8 9 10 11 12 13 14 15
CP Expansion
2pGPDsk
Filler
2pGPDsk
4pOC3Filler
I/O
4pOC3Filler
I/O
Filler
Filler
Filler
Filler
I/O
Filler
I/O
Atm
Atm
4pOC3MmAtm
MAP, SAS and LI applications can route their traffic using the
4pOC3MmAtm FPs on the same shelf (IP/AAL5/ATM) as shown in the
example in Figure 2-8.
Figure 2-8
4pOC3MmAtm example
A 0 1 2 3 4 5 6 7
Filler
Filler
Filler
Filler
Filler
Filler
CP Expansion
CP3
CP3
2pGPDsk
2pGPDsk
2pGPDsk
2pGPDsk
SAS/LI
SAS/LI
SAS/LI
SAS/LI
B 8 9 10 11 12 13 14 15
4pOC3Filler
4pOC3Filler
Filler
Filler
Filler
Filler
Filler
Filler
CP Expansion
I/O
I/O
I/O
I/O
2pGPDsk
2pGPDsk
Atm
Atm
Ga

2pGPDsk dedicated for I/O

In the case of the SGSN/GPRS which may have a dedicated 2pGPDsk, the
MAP, SAS, and LI applications can route their traffic using the 2pGPDsk
pair(s), even if this dedicated pair(s) exists on another shelf within the SGSN
complex (see Figure 2-9). This technique not only minimizes cabling but also
provides the opportunity to use Ethernet Line Sparing (ELS) on the dedicated
2pGPDsk FPs.
Figure 2-9
2pGPDsk Dedicated for I/O example
A 0 1 2 3 4 5 6 7
CP Expansion
Filler
2pGPDsk
Filler
2pGPDsk
Filler
Filler
Filler
MAP
CP3
CP3
2pGPDsk
2pGPDsk
Filler
MAP
MAP
MAP
B 8 9 10 11 12 13 14 15
CP Expansion
Filler
4pOC3Filler
I/O
4pOC3Filler
I/O
Filler
Filler
Filler
Filler
I/O
Filler
2pGPDsk
I/O
Atm
Atm
2pGPDsk Gd, Ge, Gr, Gs
Multishelf configuration 2
SGSN software entities are distributed across the 7400 and 15000 shelves
within the Passport 15000 cabinet. There are also dual cabinet configurations;
see “Minimum GPRS SGSN subscriber configurations” on page 3-39 for
more information.
In a two-shelf configuration, the 15000 is designated as the “master shelf,”

and the 7400 is designated as the “slave shelf.” In a configuration that has
more than one 15000 shelf, a 15000 shelf can be a master or slave shelf. The
master shelf is the primary controller in the multishelf network and is
physically connected to the slave shelf through redundant high-speed optical
carrier (OC) interfaces.
Function distribution
The GSC resides on the 15000 shelf, while the GSD resides on the 7400 shelf.
The GTL can be on either 7400 or 15000 shelves.
Figure 2-10 represents the distribution of functions in the Passport 15000

cabinet in a single cabinet configuration.

Figure 2-10
SGSN function distribution
7K shelf
15K shelf
MAP
MAP
SAS

Table 2-3 provides a summary of the SGSN functions and associated cards.
For more information about the cards, see Chapter 3, “Hardware description”.
Table 2-3
SGSN function summary
Shelf Function Card Layer 2 Faceplate Co-location

I/O with other
SGSN
functions
7400 Nodal Manager CP2 N/A OAM Enet None
GTLa 32pE1Msa Frame Relay Used Frame Relay
32pDS1Msa
GSD Wireless N/A N/A None

Packet Data
Server
I/O Gb 32pE1Msa Frame Relay Used GTL
32pDS1Msa
Inter-shelf 2 port OC-3 ATM Used None

communication ATM
Optional 2 port Ethernet Used None

interface to 100BaseT
core network Ethernetb
15000 Nodal Manager CP3 N/A OAM Enet None
GTL 4 port OC-3 None Optionalc None

ATM
GSC 2pGPDsk ATM Not usedd None

Ethernet
MAP 2pGPDsk ATM Optional None

Ethernet
SGSN Accounting Server 2pGPDsk ATM Optional Lawful

Ethernet Interception
(optional)
Lawful Interception 2pGPDsk ATM Optional SGSN

Ethernet Accounting
Server
(optional)
—sheet 1 of 2—

Table 2-3
SGSN function summary (continued)
Shelf Function Card Layer 2 Faceplate Co-location

I/O with other
SGSN
functions
15000 I/O Inter-shelf 4 port OC-3 ATM Used None

(cont.) communication ATM
and interface
to core
network
Frame relay 4pDS3Ch Frame Relay Used None

transport
Interface to 2pGPDske Ethernet Used None

core network
Interface to 4pOC3SmIr ATM Used None

core network Atm
Interface to 4pGigE Ethernet Used None

core network
—sheet 2 of 2—
a. The GTL application can be provisioned on either a 7K or a 15K shelf, but not simultaneously on both
shelves. MSA as GTL is no longer available for order as of PC04.
b. No longer available for order in PC04
c. Usage of the faceplate I/O for the GTL on an MSs 15000 shelf is only for inter-shelf communications.
This configuration is supported but not recommended.
d. Nortel Wireless Network Engineering (WNE) field data indicates that GSC faceplate ports are not
utilized. The option to use GSC faceplate ports is removed as of PC04.
e. If Ethernet Hot Sparing is employed, the I/O functionality cannot be co-located with other GPRS
applications.
Inter-shelf communication
Nodal Manager software, hosted on the control processor (CP) cards for both
the master and slave shelves, provides integrity across the multishelf network
by keeping each shelf “aware” of SGSN application availability. Both shelves
are viewed as a single SGSN by means of the Nodal Manager entity.
For intercard communication on the same shelf, the Passport 15000

backplane is used, while for inter-shelf communication, ATM connectivity
through the OC-3 ATM function processors is used. The 2 port OC3 ATM FP
on the 7400 is physically connected to the 4 port OC3 FP on the 15000.
ATM point-to-point switched virtual circuits (SVCs) are established over the
OC interfaces to support nodal manager and application communications.

ATM Private-Network-to-Network-Interface (PNNI) provides dynamic

routing and signaling for SVC establishment and monitors the network
topology.
An ATM Network Service Access Point (NSAP) address is provisioned

against the slave shelf Nodal Manager. This value is then provisioned at the
master shelf Nodal Manager. Applications such as the GSC and GSD also
have NSAPs, but they are automatically generated. The master shelf Nodal
Manager establishes a point-to-point SVC to the slave shelf Nodal Manager.
Upon SVC establishment, configuration information is exchanged between
the Nodal Managers, which includes a list of SGSN applications on each shelf
and their NSAPs.
Once SGSN application information is disseminated across the multishelf

network, secondary SVCs between SGSN applications are established (for
example, between GSC and GSD applications). All connections are
established at start-up and not on demand.
Figure 2-11 shows a simplified view of SVC connections. Note that each GSC
has a connection to each GSD. Other applications, such as SAS and GTL, are
present but are not shown.
Figure 2-11
SVC connections (simplified view)
15K Shelf
CP FP
[Master shelf] Nm GSC
S S S
V V ... V
C C C
[Slave shelf] Nm GSD GSD
CP FP ... FP pt2pt SVC

7K Shelf

Provisioning requirements for multishelf

The following requirements must be satisfied in order for the Multishelf SGSN
to function properly:
• ATM Networking (PNNI), and related configuration options, must be
provisioned on the OC facilities between the 15000 and 7400.
• ATM MPE (multiprotocol encapsulation) must be provisioned on the OC
facilities between the 15000 and 7400. ATM MPE is used to route IP
traffic between the 15000 and 7400 for applications using IpServer on the
15000 (the packets are routed to/from the 7400 LAN interface).
• The 7400 must be provisioned as the slave shelf.
The Sgsn Shelf component is used to reflect the SVC connections that are
established between Nodal Managers and SGSN applications. Refer to
NTP 411-5221-060, SGSN Components for SGSN component
descriptions.
For information about ATM SVCs and configuring PNNI, refer to the following
Passport NTPs:
• 241-5701-700, Passport 7400, 15000, 20000 ATM Overview
• 241-5701-702, Passport 7400, 15000, 20000 ATM Routing and Signaling
Fundamentals
• 241-5701-705, Passport 7400, 15000, 20000 ATM Traffic Management
Fundamentals
• 241-5701-710, Passport 7400, 15000, 20000 ATM Configuration Guide
• 241-5701-715, Passport 7400, 15000, 20000 ATM Monitoring and
Troubleshooting Guide
For information about ATM MPE, refer to the following Passport NTPs:
• 241-5701-805, Passport 7400, 15000, 20000 Understanding IP
• 241-5701-810, Passport 7400, 15000, 20000 Configuring IP

3-1
Hardware description 3
This chapter describes the hardware components of the Nortel Passport 15000
Variable Speed Switch (VSS) platform functioning as an Nortel SGSN/
GPRS. This chapter also describes the supported SGSN hardware
configurations.
The hardware components of the SGSN minimally include:

• Passport 15000- VSS frame
• Passport 7400 shelf (1 per VSS frame)
• Passport 15000 shelf (1 per VSS frame)
Refer to Appendix A, “Technical specifications and conformances” for an

overall technical summary of the SGSN.
Note 1: The SGSN is supported on the Passport 15000 platform

functioning as an SGSN. The SGSN is not supported on the Passport
20000.
Note 2: A node functioning as an SGSN does not support other GSM

applications, such as the Nortel GSM/UMTS Interworking Function
(IWF) or the PCUSN. The node only supports SGSN functionality.
Overview 3
The multishelf SGSN consists of two shelves within a VSS cabinet: a “master
shelf,” hosted on the Passport 15000, and a “slave shelf,” hosted on the
Passport 7400 (there are also dual cabinet configurations; see “Minimum
GPRS SGSN subscriber configurations” on page 3-39 for more information).
The master shelf is the primary controller in the multishelf network and is
physically connected to the slave shelf with redundant high-speed optical
carrier (OC) interfaces.
SGSN functionality is divided between both Passport 7400 and Passport

15000 functional and control processors. Table 3-1 lists 7400 shelf
processors. Processors for the 15000 are listed in Table 3-2.

3-2 Hardware description
Table 3-1
Passport 7400 shelf processors
Card Name Abbreviation Product Line Rate SGSN MTBF

Engineering per Port Applications (Years)
Code (PEC) a
Control Processor CP2 NTNQ01 9.6 kbps Nodal 24.4

(V.24) Manager
NTNQ03
10 Mbps
(10BaseT)
100BaseT LAN 2pEth100BaseT NTNQ37 100 Mbps I/O 56
Wireless Packet WPDS NTNQ64 N/A GSD 40

Data Server
Multi-Service 32pDS1Msa Single Slotb: 1.544 Mbps I/O, GTLd 26.9

Access (MSA) 32pE1Msa 2.048 Mbps
NTNQ94 (DS1)
NTNQ93 (E1)
Dual Slotc:
NTNQ74 (DS1)
NTNQ69 (E1)
2-port OC3 Multi- 2pOC3MmAtm2 NTNQ65 155.52 Mbps I/O, Inter- 45

mode ATM shelf I/O
a. The values in this table represent the entire FP being unavailable for service.
b. Only the AA vintage may be used with PCR5.2 (PC04); the BA vintage with support for a new framer
chip may not be used with PCR5.2 (PC04). Additionally, the single-slot MSA card may only be used for
Gb I/O, and may not host the GTL application software. For single-slot MSA32 cabling and configuration
information, refer to Appendix D, “Single slot 32-Port MSA cabling”.
c. The dual-slot MSA card will no longer be available as of PC04.
d. The GTL application can be deployed on the 7400 (Dual Slot 32pMSA) or 15000 (4pDS3Ch), but not
simultaneously on both shelves.

Table 3-2
Passport 15000 shelf processors
Card Name Abbreviation Product Line Rate per SGSN MTBF

Engineering Port Applications (Years)a
Code (PEC)
Control CP3 b NTHW06 9.6 kbps (V.24) Nodal 17.8

Processor (DS1) Manager
100 Mbps
NTHW08 (100BaseT) Administration
(E1)
2-Port General 2pGPDsk NTHW10 100 Mbps LI 16.2

services MAP
Processor with SAS
Disk GSC
I/O
4-port 0C-3/STM- 4pOC3MmAt NTHR17c 155.52 Mbps I/O, GTL 22.2

1 Multi-mode m
ATM FP NTHW05
4-port OC-3/ 4pOC3SmIrAt NTHR21d 155.52 Mbps I/O (external 22.2

STM-1 Single m only)
Mode ATM FP NTHW15
4-port DS-3 4pDS3Ch NTHR89 44.736 Mbps I/O (Gb) 19.9

Channelized
Cooling Unit NTHR10e >50

Controller
4 Port Gigabit 4pGe NTHW49 1000 Mbps f I/O (Gn, Gp) 18.6
Ethernet
Fabric Card NTHR16g >50
a. The values in this table represent the entire FP being unavailable for service.
b. Delivered as part of a 15000 cabinet or shelf assembly and is typically not ordered separately.
c. Must be CA vintage or higher to support inter-card APS (includes HSM and FPSO). NTHW05 is the
replacement using PQC12 technology for the NTHR17.
d. NTHW15 is the replacement using PQC12 technology for the NTHR21.
e. Delivered as part of a 15000 cabinet or shelf assembly and is typically not ordered separately.
f. The port speed is 1000 Mbps but the aggregate rate for all 4 ports on the FP cannot exceed 2.5 Gbps
g. For PCR5.2, NTHR16EA is the replacement for NTHR16DA.

Passport 15000-VSS frame 3

The SGSN is housed in a 15000-VSS Network Equipment-Building System
(NEBS) 2000 frame assembly. A Passport 7400 shelf occupies the top portion
of the frame, and a Passport 15000 shelf occupies the bottom portion of the
frame. The 15000-VSS frame is available only in a direct current (dc)
version.
The frame consists of the following components:

• Enhanced Breaker interface panels (EBIPs)
• Cooling unit
See Table A-1 in Appendix A, “Technical specifications and conformances”

for a summary of the approximate dimensions and weights of the hardware
that may be involved.
Figure 3-1 shows the Passport 15000-VSS frame.
Figure 3-1
Passport 15000 frame
Passport
7400 shelf
cooling unit
Passport
15000 shelf

Breaker interface panel

The enhanced breaker interface panel (EBIP) provides a central location
where redundant dc input power feeds can be connected (nominal voltage of -
48/-60V) of up to 100 amps. These feeds are connected to either two or four
breaker interface modules (BIMs) on the BIP. The SGSN uses two BIMs.
While the breaker interface module is rated up to 100 amps for the base
Passport 15000, for the SGSN, with the power consumption of the SGSN
cards, a 40 amp breaker is sufficient, even if 16 cards are installed in the
15000 shelf of the Passport 15000-VSS cabinet. 40 amp breakers must be
used to power the SGSN since the power cabling kits have been designed
with cabling sized for 40 amp breakers. If power cables longer than 60 meters
are required, the cables must be engineered.
Power is distributed from the BIMs to the 15000 shelves and cooling unit.
The Passport 15000-VSS cabinet supports the use of a two-BIM single 15000
module. The BIP also contains an alarm module which monitors system
components, generates alarms, and controls LED status indicators.
Breaker interface modules (BIM)

A two-BIM model is used in frames which are intended to support only one
Passport 15000. In a two-BIM model, the empty BIM slots must be covered
with filler plates to protect EBIP circuitry and to meet safety requirements.
The breaker interface modules (BIMs) are located on the right side of the
EBIP. In four-breaker models, the breakers fill the left side of the shelf and the
alarm module. In two-BIM models, the BIMs are located in the two right-
hand slots next to the alarm module, with the two BIM slots on the left side
left empty but covered with filler plates.
The power breakers on each BIM control the -48/-60 V dc A and B power
supplies to the power interface modules (PIMs) and to the upper and lower
cooling units (CUs).
Each BIM supports a maximum of five PCB mount circuit breakers made up
of four 20 A shelf breakers and one central 5 A CU breaker. The 20 A
breakers support the shelf cages and the 5 A breaker supports either the upper
or lower CU.
The power breakers are arranged such that each Passport 15000 in a frame
can draw power from two independent power sources (usually labeled A and
B). Breakers should be set to off before a BIM is removed from the EBIP.
One BIM receives an input power feed for a shelf, so that two BIMs are
required for each shelf.

Alarm module
The EBIP alarm module is located at the front, on the right side of the EBIP.
The EBIP alarm module front panel has the following features:
• a triangular alarm LED for the alarm module (see Table 3-3)
• a rectangular power LED for the alarm module (see Table 3-4)
• three separate alarm indicators for minor, major, and critical alarms (see
Table 3-5)
• an audio-visual follow-me indicator to assist an operator to locate a faulty
module
• a LEDTEST switch which, when pressed for five seconds, causes all the
EBIP LED alarm indicators to light up
• an audible alarm cut-off switch labeled ACO
• a thumbscrew to hold the module in place
Table 3-3
Alarm LED status indicators for the EBIP alarm module
LED color Mode Meaning
red solid critical/major fault
amber solid minor/software fault
green solid normal operation
Table 3-4
Power LED status indicators for the EBIP alarm module
LED color Mode Meaning
green solid no fault, in service — active
off invalid state — test for loss of

power

Table 3-5
EBIP hardware alarm definitions
Alarm Definitions
type
Critical Indicates that a severe, service-affecting condition has occurred and

immediate action is required. For example:
• a CP failure causes a loss of call processing capability
• a fabric failure preventing a switchover to a standby (redundant)
fabric card
Major Indicates that a service-affecting condition has occurred and urgent

corrective active is required. Service-affecting conditions include
disruption or degradation of service, or malfunction of an important
circuit. For example:
• a breaker is tripped
• a breaker has failed, meaning the power interface module (PIM)
receiving the power from the breaker has failed or input power to
the PIM has failed (for example, the power cable to the PIM is
disconnected)
• external power has failed from an ac rectifier provided the EBIP is
powered from it and the rectifier’s alarm output wires are
connected to the central office side of the EBIP alarm module; in
this case, a failed breaker alarm is also indicated
Minor Indicates that a non-service-affecting hardware or software failure

has occurred. Corrective action must be taken to prevent a minor fault
from escalating into a more serious problem. For example:
• a fan or its controller has failed
• a shelf temperature is higher than 72 degrees Celsius (161.2
degrees Fahrenheit)
• the alarm module detects the same failure in two shelves (two
nodes) supported by the same EBIP
See NTP 241-5701-500, Passport 6400, 7400, 15000, 20000 Alarms for more
details.
External alarm system

The design of the Passport allows for implementation of an external alarm
system. External alarms inform personnel at a remote site when there are
problems with the equipment. They are triggered when a set of dry relay
contacts close.

The Enhanced Breaker Interface Panel (EBIP) can be connected to external

alarms such as end-of-aisle lamp, an LED, or an audible alarm with a D-type,
15-pin connector, labelled “Alarm 1” or “ALM 1”. There are three sets of
major alarm contacts and three sets of minor alarm contacts. Each set of
contacts is rated at 72 V DC, 1 A DC.
Keep these considerations in mind if an external alarm system is implemented:

• The customer must provide cabling from the external “Alarm 1”
connector of the node to the external alarm system.
Note: When two shelf assemblies are in the same rack or frame, the
“Alarm 2” connectors of both shelves must be connected by a shelf alarm
interconnect cable assembly. This provides a single source of alarms for
the door alarm and the external alarms connector “Alarm 1”. The
interconnect cable is available separately from Nortel.
• The cabling must allow the external alarm system to detect contact
closure for activating the alarm.
• For long cables, ensure that the external alarm system can detect contact
closures and is not impeded by the cable resistance.
• Connection requires a 15-pin, D-type connector.
• A switch can be inserted between the alarm cable and external alarm
system to isolate the external alarm system from the Passport alarm
connector during repairs.
Refer to NTP 241-1501-200, Passport 15000, 20000 Hardware Description

for a complete list of available EBIP external alarm connections and the types
of alarms they provide.
Backplane power interconnections to the EBIP

The EBIP backplane power connections are located along the right side of the
rear of the EBIP. A strain-relief bar is located directly in front of the power
connections. This bar is used to prevent heavy input power cables from
placing too much stress on the EBIP backplane.
The EBIP backplane power connections are the terminations for input power
feeds up to 40 A, and for output power cables from the EBIP to the shelves
and cooling units. A four-BIM model EBIP supports eight input feeds (a
battery and battery return wire per BIM), while a two-BIM model supports
four power feeds. A backplane safety cover overlays the backplane to prevent
inadvertent shorts from metallic contact with the connectors. Each power
input connection is covered by an insulating boot.

The backplane provides the following connection components for each BIM:
• four power studs for connecting two dc power input cables (two studs per
cable) by #1/0 and #2/0 AWG 90-degree offset 2-hole lugs (#2/0 are
supplied in case of thicker strands in 1/0 AWG cable)
• two 1x4 MATE-N-LOK II connectors for cables providing power output
to the PIMs in the shelves
• one 1x2 MATE-N-LOK II connector for cables providing power output to
either the upper or lower cooling unit
• one insulating boot per power stud
Cooling unit
The Passport 15000 frame has two cooling units located in the middle of the
frame, between the upper and lower shelf assemblies. The upper cooling unit
pushes air from the fan under the modules in the upper shelf assembly and out
through the exhaust plenum under the EBIP. The lower cooling unit pulls air
in from the bottom of the frame, over the modules in the lower shelf assembly
and out through the fan assembly.
Each cooling unit consists of three fans and a cooling unit backplane located
in a common shelf. Each cooling unit is controlled by temperature sensors
located in the shelf assembly.
Passport uses forced air for cooling internal assemblies. The intake draws air
from both the base and front of the frame, and forces it vertically through the
shelf where it exhausts to the rear of frame at the cable management section.
The Passport 15000 frame is also equipped with air filters to prevent dust and
other airborne contaminants from being drawn into the shelf assemblies by
the cooling units.
Each cooling unit is equipped with LEDs to indicate the unit’s status.
Table 3-6 lists the possible LED displays.
Table 3-6
Cooling unit LED indications
LED color Description
Green light on Unit on, no fault detected
Red light on Fan fault, missing fan or temperature sensor

detected. A FANFAIL signal is sent to the alarm/
BITS module, and the remaining fans are
switched to the high speed setting.

Caution: To ensure proper cooling of function processors and the shelf

fabric, empty FP slots should be equipped with filler cards. Failure to
install filler cards will result in a lower MTBF for the FP and CP cards.
Passport 7400 3
The Passport 7400 is a 16-slot Passport node running the SGSN application.
The design of the 16-slot Passport platform provides an ideal software and
hardware base for the SGSN. The design of the Passport is flexible and
upgradable for smooth transition to future multimedia networks. Key
components of this strategy include:
• capability for both frame and cell switching
• modularity in both software and hardware design
• a highly reliable multiprocessor architecture
• state-of-the-art fault-tolerant software
The Passport 7400 consists of three assemblies (see Figure 3-2):

• cable management assembly
• shelf assembly
• cooling unit
Note: In this document, port refers to the part of a data processor that is
dedicated to a single channel for the purpose of receiving data from or
transmitting data to, one or more external remote devices.
Node is the term used to encompass the processor card section, the power
converter section, the cooling unit and the cable management assembly.
Node is used synonymously with shelf.

Figure 3-2
Passport 7400 node assemblies
Cable
management
assembly
Housing assembly
Cable guide
Shelf assembly
Processor cards
Cooling unit
assembly Power converters
Air filter assembly

Cooling unit
Cable management assembly

The cable management assembly is situated at the top of a 16-slot Passport
node.
The cable management assembly organizes and manages a large number of

cables (copper, coaxial, and fiber). This is especially useful for configurations
involving high cabling termination.
The cable management assembly consists of a cable guide and a housing

assembly.
• The cable guide is quarter-rounded, ensuring that a minimum bend radius
is met for copper and fiber cables. Its guide slots, which support and route
cables, are in two widths (thick and thin) to separate fiber cables from
other types of cables.
• The housing assembly routes cables from the front of the frame to the
rear. It has a door which swings upward and slides back for installing
cables. The door has a configuration map for marking cable information.

Cables connect to the faceplates of the processor cards, and are routed vertically
upwards to the guide slots of the cable guide.
Note: The cable guide ensures that
— cables of adjacent processor cards do not interfere with each other.

— any processor card can be withdrawn from the shelf without
disturbing adjacent cards or their cables.
From the cable guide, cables are routed to the rear of the node where they can
be routed upwards or downwards in channels along both sides of the node.
The Passport frame has exit ports on the top and bottom for the cables.
The guideline for Passport cable management is to route fiber on the left side
of the frame and copper on the right side of the frame.
Figure 3-3
SGSN cable management
Optical fiber
Copper
Shelf assembly
The shelf assembly houses the function and control processors (FP and CP,
respectively) and the power converters, providing distribution of secondary
power and communication between the function processors through the
backplane.

The SGSN is available in direct current version only. The dc version of the
shelf assembly has a specific type of rear power input panel for connecting
the power source. Likewise, the power converter used is specific to the dc
configuration. Function and control processors, however, are common to both
configurations.
The shelf assembly can contain up to sixteen function and control processors:
• a total of 14 function processors and two control processors
• a total of 15 function processors and one control processor
Each processor card slides into its allocated shelf slot, labeled 0 to 15, where
its connector engages with a connector on the backplane, see Figure 3-4. Shelf
slots are allocated as follows:
• function processors can occupy any of slots 1 to 15
• control processors can occupy slots 0 or 15 only
Figure 3-4
Shelf assembly
Control processor
Function processor
Ejector latches at the top and bottom of the front panel of each processor card
secure it in place. A lock latch prevents tampering.
Slots not occupied by a function or control processor are fitted with blank
cards to ensure proper cooling of the node, and for electro-magnetic
interference (EMI) protection and safety compliances. Blank cards are
labeled Blank.

Access to the function and control processors is from the front. The faceplate
of each processor card contains connectors and an LED status indicator.
The following sections further describe Passport 7400 shelf components:

• power converters
• cooling unit
• backplane
• control processor cards
• function processor cards
Power converter
The SGSN is available in direct current (dc) version only, however an external
ac/dc power converter may be used. Alternating current (ac) and dc versions
are not interchangeable since each requires a distinct type of:
• power converter
• mechanical metal housing (shelf) containing the processor cards and the
power converters
• grounding scheme
Figure 3-5
Dc shelf assembly, rear view
Dc shelf assembly
The power converters are located directly below the function and control
processors. The power converters slide into their allocated slots where their

connectors engage with those of the backplane. A handle mounted on the

front panel of each power converter lowers to remove the unit, and snaps into
the upright position to secure the unit in place. A locking screw prevents
tampering. As with the function and control processors, blank power
converter units are inserted into slots not used to ensure cooling of the node.
Blank power converters are labeled Blank.
The front panel of each power converter has a power (On/Standby) switch
and an LED status indicator. The switch is set to On for powering the node
and to Standby for removing the power converter.
If the power converter to be removed is spared as described in the following

note, SGSN operation will not be interrupted.
Note: Two power converters are required to power a fully equipped node
(that is sixteen function and control processors); a third power converter
provides N + 1 sparing. Although the three power converters operate in a
load-sharing capacity, two will maintain SGSN services should one fail.
One of the three power converters can be removed without disrupting
service.
The following subsections highlight the dc power requirements. See NTP

241-7401-200, Passport 7400 Hardware Description, for additional
information regarding power and grounding requirements and specifications.
Dc power
Power and ground for the 7400 node is brought directly into the shelf from
the Power Distribution Center. Three –48V power leads are connected to the
7400 node. For reliability they should be two “A” Feeds and one “B” Feed, or
they should be one “A” Feed and two “B” Feeds.
The dc power source must be within the range of 39 to 72 V dc and must be

capable of providing 2000 W per switch, that is, rated at 60 A dc (for 39 V dc)
and 33 A dc (for 72 V dc).
To maintain an IEC 950 safety classification, the power source connection to

dc power supplies must be provided via a disconnect device. The disconnect
device must be external to the Passport frame and must reside in the same
room. It must have a voltage rating of 48/60 V dc nominal and a current rating
of 30 A dc nominal for each power supply.
The power converters convert primary power inputs into secondary operating
voltages. The direct current power converter accepts voltages as described in
Table 3-7, and converts them into the required +5, +12, and -12 V dc
operating voltages for distribution by way of the backplane through the node.

Table 3-7
Dc power requirements
Parameter Specification
Nominal input voltage: -48 to -60 V with input operational range of -40 to -72 V
Output power: Cannot exceed 600 W
Cooling unit
The cooling unit for the 16-slot Passport is located below the shelf assembly.
Passport uses forced air for cooling internal assemblies. The intake draws air
from both the base and front of the cabinet, and forces it vertically through the
shelf where it exhausts to the rear of cabinet at the cable management section.
The cooling section has two separate components:

• a fan assembly with two fans
• a filter
Both components span the width of the node and slide into position.
The fan assembly, like the power converters, has a front handle that lowers
for removing the assembly, and a locking screw which prohibits tampering.
Pressing the center of the air filter disengages the filter so that the filter
material may be removed for replacement.
A front panel LED status indicator glows either red or green to indicate the
status of the section.
Signal and power distribution

For the Passport 7400 shelf, the backplane is a printed circuit board which
interconnects with the node assemblies for integrated power and signal
distribution. Up to 16 function and control processor cards can connect to the
backplane, each through a 4 x 90 Norcon connector. Two bus terminator
cards, one at each end of the backplane, terminate backplane traces, reducing
signal ringing by eliminating signal reflection.
Passport bus
The Passport 7400 bus is the bridge which allows data to be switched across
different types of processor cards. The bus also allows FPs and CPs to
communicate for implementing services, and it is used by processor cards to
broadcast messages across the backplane to other processor cards.
The Passport bus is fully redundant. It consists of two synchronous 32-bit

25-MHz cell buses, operating in a load-sharing capacity, which can

communicate with up to sixteen function and control processors. Each bus

operates at 800-Mbit/s for an aggregate speed of 1.6 Gbit/s. When both buses
are active, traffic is distributed across both buses (dual-bus mode); should one
bus fail, the other continues, although capacity is reduced to 800 Mbit/s
(single-bus mode).
7400 control processor

Control processors and function processors are the processing elements for
performing and managing SGSN functions. In contrast to the function
processors, the control processors are not part of the data path through the
node. Instead, control processors manage and control applications supporting
both system and network functions.
One control processor is sufficient to manage each shelf. Using a second

control processor will provide redundancy, the first is active and the other is
standby. If the active control processor fails, the standby control processor
becomes active. It is strongly recommended to operate the SGSN shelf with
dual control processors. This configuration provides maximum robustness
and redundancy; however, is not required.
Note: The control processor is vital to the operation of the node. If it fails
and there is no redundancy, the node does not operate.
The minimum processor card requirements for a 16-slot Passport switch are
one of the following:
• one CP in slot 0, plus three FPs
• one CP in slot 0 and one CP in slot 15 (standby), plus one FP in any other
slot
In most cases, the software providing a service is split into control and function
parts. The control part runs on the CP; the function part, on the FP. This results
in:
• more efficient data flow since the FP does not do resource-consuming
non-data-path processing
• more efficient memory resources for data transmission
The computational resources on-board the control processors provide an
environment for these system-wide functions. Principally, this entails:
• management support for the function processors (including software
download, and interface for operator commands, and provisioning)
• data storage
• real-time clock
• shelf monitoring and alarm processing

• interfacing a network management system (a workstation or a text

interface device)
The control processor consists of a processor module, an interface module, and

a hard disk drive.
• The processor module connects the CP to the backplane, providing an
interface with the bus. It performs activities associated with the bus and
routing data through the node. Passport has a multiprocessor architecture.
Each processor card has its own microprocessor.
• The interface module supports CP shelf manager functions, including:
— disk interface
— Stratum-3 clock
— real-time clock
— shelf alarm circuitry
— external interfaces
• Attached to the interface module is a hard disk drive. The hard disk drive
stores software, configuration data, and spooled information.
Figure 3-6 shows the faceplate for the 7400 CP2 control processor.

Figure 3-6
CP2 faceplate
5
9
Ejector latch 6
1
Locking latch
V.24 DCE 9-pin
D-type connector
Pin Numbering Scheme
V.24 DCE port
LED status indicator

for Ethernet port (not used)
10Base-T Ethernet port

RJ45 connector (not used)
Locking latch
Ejector latch
For additional details on the control processor card, see NTP 241-7401-200,
Passport 7400 Hardware Description.
Timing
The Passport 7400 can accept timing reference signals from any FP or can
generate a stratum III reference clock on the CP2. The configuration selected
for the SGSN/GPRS should use the BITS timing module on the Passport
15000 and timing for the Passport 7400 should be derived from the
2pOC3MM OC-3 shelf interconnect (for example, using the “Line”
provisioning setting). This effectively slaves the Passport 7400’s timing
reference to the Passport 15000’s BITS source. The CP3 on the Passport

15000 can either source a stratum III clock or can slave to a Stratum III (or
better source) through the BITS module. If the SGSN is using an external
BITS reference, one Passport 15K in the SGSN complex should receive the
timing feed (either E1 or T1) from the BITS source and all other Passport
15000 and 7400s should time off of this shelf using the line provisioning
setting for the OC3 inter-connects.
7400 function processors

The function processors provide the interface ports to the SGSN. They
perform those functions that switch data from external sources through the
bus and out of the node through other function processors.
As a result, the function processors have been designed and optimized

specifically to accommodate high data throughput. Their computational
resources support and execute only those real-time processes critical to
rapidly delivering a service.
The following types of Passport 7400 function processors are used by the
SGSN:
• 100BaseT Ethernet (two ports)
• 2 port OC-3 ATM Function Processor
• 32 port Multi-Service (MSA32)
• Wireless Packet Data Server (WPDS)
100BaseT Ethernet function processor

The 100BaseT Ethernet function processor
• has two Ethernet 100BaseT ports
• supports half duplex and full duplex networking
• supports layer 2 hardware switching between ports
• supports LAN to LAN routing and bridging services
• supports one-for-one sparing and load-sharing redundancy models
The functions of this processor card include

• LAN based Operations, Administration, and Maintenance (OA&M)
connectivity
• Gn Layer 1/2
• SIG connectivity
Customer equipment connects directly to the ports on the faceplate of the

100BaseT Ethernet FP.

Figure 3-7
100BaseT Ethernet function processor faceplate
Ejector latch
Locking latch
Port 1
Port 1
RJ45 connector
Port 0
Port 0
RJ45 connector
Locking latch
Ejector latch
For additional details on the 100BaseT Ethernet function processor card, see
NTP 241-7401-200, Passport 7400 Hardware Description.
2-port OC-3 ATM function processor

The 2-port OC-3 ATM function processor for the SGSN has two SONET
interfaces, or ports and is available in multi-mode format. It delivers feature
rich ATM traffic management functions, including fair queuing and traffic
shaping. The single mode version of this card is not supported for the SGSN.
The 2-port OC-3 ATM function processor in the SGSN is used for inter-shelf
communication.

The OC-3 ATM function processor supports optional line automatic

protection switching (line APS) between SONET interfaces on the same card.
It does not use termination panels or support sparing.
Figure 3-8 shows the faceplate for the OC-3 ATM function processor.
For additional details on the OC-3 ATM function processor card, see NTP
241-7401-200, Passport 7400 Hardware Description.
Figure 3-8
2-port OC-3 ATM function processor faceplate
Ejector latch
Locking latch
Transmit (Tx)
Port 0 Port 0
Receive (Rx)
Port 1
Transmit (Tx)
Port 1
Receive (Rx)
Ejector latch
32 port Multi-Service Access (MSA32) function processor

The 32 port Multi-Service (MSA32) function processor provides external
frame relay connectivity from the SGSN to the BSS on the Frame Relay
based Gb interface. The MSA32 occupies two adjacent slots in the shelf. (The
software uses only the first slot number and ignores the second one.)
Note: The dual-slot MSA card will no longer be available as of PC04.

The single-slot MSA card may only be used for Gb I/O, and may not host

the GTL application software. For single-slot MSA32 cabling and

configuration information, refer to Appendix D, “Single slot 32-Port
MSA cabling”.
In the SGSN1 configuration (see “Minimum GPRS SGSN subscriber

configurations” on page 3-39), the MSA32 provides the functions of the
SGSN’s GTL application. There is one GTL entity per 2-slot MSA32 card.
The E1 version of the MSA32 has a line rate of 2.048Mbit/s. The DS1 version
of the card has a line rate of 1.544Mbit/s. The MSA32 supports the use of
termination panels.
Figure 3-9 shows the faceplate for the MSA32 function processor.
Additional details for termination panels and the MSA32 function processor
are covered in NTP 241-7401-200, Passport 7400 Hardware Description.
Figure 3-9
MSA32 function processor faceplate
Ejector latch
44 30 15
Locking latch
Ports 0-7
(P0)
Ports 8-15
(P1)
31 16 1
Ports 16-23 44-pin
(P2) High density
D-type connector
Maintenance port Pin Numbering
Scheme
Ports 24-31
(P3)
PPT 2844 001 AC

Wireless Packet Data Server

The wireless packet data server (WPDS) supports the GSD wireless
applications and performs encryption and decryption of data packets to and
from the mobile. The WPDS is a Nortel proprietary FP and increases the
performance of wireless services. The GprsIpServer component is also
supported on cards where the GSD component is supported.
The WPDA hosts a daughter card with a Field Programmable Gate Array
(FPGA) . The daughter card provides a GPRS encryption engine for the
GPRS Encryption Algorithm 1 (GEA1), and also provides the CRC machine.
Data encryption and authentication is provided by either the software or with
hardware assist depending on provisioning. Note that failure of the hardware
assist FPGA does not disable the WPDS; it simply reverts to software based
encryption (although at reduced capacity).
The WPDS provides its state; it is either enabled or disabled. (If the wpds
component is locked, the WPDS is disabled; otherwise, it is enabled.)
A standby WPDS option supports one-for-one sparing. All traffic goes

through the active FP. The standby FP is idle but ready to assume traffic
should the active FP fail. This FP requires no cabling, therefore, you must
provision sparing. For more information, see 241-5701-600 Passport 7400,
15000, 20000 Configuration Guide.
Figure 3-10 shows the faceplate for the wireless packet data server. The
WPDS does not require external cabling, and therefore has no ports on the
faceplate. An LED shows the operational status of the FP.

Figure 3-10
WPDS faceplate
Status
PPT 3018 001 AA
Hardware ciphering assist

The provisional parameter cipheringHardwareAssist controls the use of
hardware assistance for encryption on the GSD. The default setting of this
parameter is autoconfigure meaning that if specialized hardware exists on a
card, that it will be used. For more information on SGSN parameters, refer to
NTP 411-5221-060, SGSN Components.
Note: Parameter cipheringHardwareAssist applies only to cards that

have hardware assist capabilities such as the WPDS.
The existing operational parameter crcErrorsFromMs can be used as an

indicator of the number of frames received by the SGSN in which decryption
errors were encountered.
Figure 3-11 shows a logical diagram of the WPDS card performing Logical
Link Control (LLC) layer encryption.

Figure 3-11
WPDS logical diagram
GSC on a different GSD on a WPDS/PDA card

card and shelf
PDS Mother Board
GMM/SMS SNDCP
4u 1d PDA Daughter card

2d
4u 1d
3u GEA1
LLC and
2u CRC
1u
3d
BSSGP
GTL on a different card
Message flow in the uplink direction:

1u - LLC receives a ciphered frame from the MS
2u - LLC sends the frame to be deciphered to the daughter card
3u - Daughter card deciphers and does the CRC check on the frame and
sends it to LLC
4u - LLC checks the SAPI number in the message and either sends to SNDCP
(data SAPI) or to the GSC card (control SAPI or SMS SAPI)
Message flow in the downlink direction:

1d -GSC card or SNDCP send a message to the MS via LLC
2d - LLC sends a frame to be ciphered to the daughter card
3d - daughter card appends the FCS field and ciphers the frame and forwards
the ciphered frame to BSSGP on the GTL card.
-- Passport shelf cards
-- GPRS protocol layers and GPRS cipher algorithm and CRC machine

The SET Software Ciphering Alarm (7068 1022) is generated when more
than a pre-determined number (currently 10) of uplink data frames are
dropped by the hardware ciphering system. Since this suggests an
unfavorable hardware condition, the system reverts to software ciphering.
After a switch to software ciphering, the Ciph alarm can be acknowledged

and cleared at MDM level to remove the alarm from MDM’s calculation of
the raw state of the GSD component, but this action is not propagated to the
Passport. To restore the hardware encryption services, the WPDS card should
be reset with the cipheringHardwareAssist attribute still provisioned to
autoConfigure. However, since the problem could have been caused by a
hardware fault, the same problem could occur again. Nortel Global Product
Support should be contacted promptly to review the situation. If hardware
encryption services are restored without resetting the card, either manually
with unsupported tools, or automatically by a future enhancement, the Ciph
CLR alarm will be issued.
The currentCipheringMethod attribute of the Gsd component shows whether

hardware or software is providing encryption services, and the
pdaFpgaVersion attribute shows the version of the FPGA in the hardware
encryption datapath. The availabilityStatus OSI Status attribute of the Gsd
component is normally Empty, but is set to Degraded upon a switch to
software ciphering. It is reset to Empty upon reversion to hardware ciphering
if there is no other indication of degraded availability.

Passport 15000 shelf 3

The Passport 15000 frame includes a Passport 15000 shelf. The Passport 15000
shelf (see Figure 3-12) contains:
• backplane
• fabric cards
• Power interface modules (PIMs)
• Media access control (MAC) address module
• Alarm/BITS module
• Control processors (CP3) and function processors (FPs)
Figure 3-12
Typical 15K shelf (front view)
Each processor card slides into its allocated shelf slot, labeled 0 to 15, where
its connector engages with a connector on the backplane. Shelf slots are
allocated as follows:
• Function processors can occupy any of slots 2 to 15
• Control processors occupy slots 0 and 1only
Ejector latches at the top and bottom of the front panel of each processor card
secure it in place. A lock latch prevents tampering.

Slots not occupied by a function or control processor are fitted with blank
cards to ensure proper cooling of the node, and for electro-magnetic
interference (EMI) protection and safety compliances. Blank cards are
labeled Blank.
Note: Any slot not occupied by an FP must be equipped with a blank card
to prevent degradation of the service life of active FPs.
Access to the function and control processors is from the front. The faceplate
of each processor card contains connectors and an LED status indicator.
Backplane
The backplane of the Passport 15000 shelf assembly is a 20-layer printed
circuit board containing 8 signal layers and 12 power/ground layers and is
located between the processor cards and the fabrics. Each processor card
connects to the backplane with four Z-PACK connectors with a total of 658
pins per processor card slot, plus additional pins for the fabric card, MAC
address module, alarm/Building Integrated Timing Supply (BITS) module,
and the power interface modules (PIMs) (see Figure 3-13).
Figure 3-13
Typical 15K shelf (rear view)

The serial link architecture of the backplane allows for hot-swapping packs
by isolating each card to a single fabric port, preventing card failures from
propagating through the switching fabric. The back-plane also provides links
between adjacent FPs for functions such as sparing, clock distribution, and
distribution of -48/-60 V dc.
The Passport 15000 backplane is the point across which all processor cards
and fabric cards in a shelf intercommunicate. The backplane can function in
dual- or single-fabric mode.
Fabric cards
The fabric cards are located at the rear of the Passport 15000 shelf assembly.
Each shelf contains two fabrics enclosed in a carrier module.
Each shelf contains two fabric cards, located one above the other at the rear of
the shelf assembly. The upper and lower fabric cards are rotated 180 degrees
relative to each other to minimize serial link lengths.
Each fabric is an individual switch embedded in a chip set. Each card consists
of a 254 mm tall by 406 mm wide PCB module. It provides 16 input ports and
16 output ports. A single fabric provides 3.52 Gbit/s bandwidth for each input
and output port, for a total throughput of 56.3 Gbit/s. The fabrics provide
eight high-speed serial links for each input and output port, with each line
operating at 440 Mbit/s.
The fabric cards provide the shelf with two redundant 16x16 switching
elements for interconnecting up to 16 processor cards. Both fabrics are used
to carry traffic, although a single fabric can handle all traffic carried by a fully
provisioned and configured Passport 7400. Under normal circumstances, each
processor card transmits to and receives from half the processors on the upper
fabric (usually labeled the X fabric) and half on the lower fabric (the Y
fabric).
Power interface modules (PIMs)

Four power interface modules (PIMs) are located along the left side of the
rear of the Passport 15000 shelf assembly.
Each PIM provides a point at which power cables from the EBIP are
connected. Each shelf assembly contains four PIMs: two for A power feeds
and two for B feeds. Each PIM provides separate power filtering for the
portions of the shelf it supports. The PIMs also provide termination for the
shelf clocks and for the secondary control bus.

Media access control (MAC) address module

The media access control (MAC) address module is located on the left side of
the rear of the Passport 15000 shelf assembly, between the two fabric cards
and between the PIMs of the upper and lower module cage.
The MAC address module is a field-replaceable unit (FRU) which provides

the shelf with media access control (MAC) addresses for the control and
function processors. The MAC address module contains a circuit board with
an 87C51 8-bit micro controller and a Z-PACK connector used to provide an
interface to the shelf backplane. The module contains the base MAC address
and the range of MAC addresses available for assignment (based on the base
address value). During the Passport boot sequence, the control processor
takes the range stored in the MAC address module, divides this value by the
number of functional processors, and distributes to each functional processor
a base value and range.
Caution: The MAC module does not have guide pins and must be
inserted carefully to prevent damage to the pins on the back plane. This
module has a high service lifetime and replacement is not likely to be
necessary over the lifetime of the shelf.
Alarm/BITS module
The alarm/BITS module is located at the right side of the rear of the Passport
15000 shelf assembly, between the upper and lower fabric modules.
The alarm/BITS module is a field-replaceable unit (FRU) which terminates

cables carrying alarm signals (from the cooling unit and EBIP), and BITS
signals, and passes the information over the shelf backplane to the control
processors and expansion slots.
The alarm/BITS module contains the following connectors:

• BITS ports
• Cooling unit alarm connector
• EBIP alarm connector
Both the E1 and T1 alarm/BITS module are supported.
Caution: The alarm/BITS module does not have guide pins and must be
inserted carefully to prevent damage to the pins on the back plane. This
module has a high service lifetime and replacement is not likely to be
necessary over the lifetime of the shelf.
15000 Control processor

The CP3 is the control processor for the 15000 shelf. The CP3 performs nodal
management in the multishelf SGSN.

The CP3 has two 100 BaseT ports on faceplate (see Figure 3-14), one is used
for OA&M.
For more information on the CP3, see NTP 241-1501-200, Passport 15000,
20000 Hardware Description.
Figure 3-14
CP3 faceplate
Status LEDs
Status
LEDs
Clock
Clock
crossover
crossover
V.24
V.24DCE
DCE
operator
operatorport
port
Not
Notused
used
Not
Notused
used
Ethernet
Ethernet
100BaseT port
100BaseT port
PPT 2906 001 AB
2-port General Processor with Disk (2pGPDsk)

The 2-port general processor with disk (2pGPDsk) is a Passport 15000
function processor that has the capability of automatically spooling data to its
internal 20 gigabyte hard drive.
The 2pGPDsk line rate supports asynchronous data transfer. The data transfer
rate varies with the services being offered on the FP.

On the SGSN, the 2pGPDsk is used for GSC, SGSN billing, MAP, and
Lawful Interception applications. 2pGPDsk cards can be spared.
Figure 3-15 shows the 2pGPDsk faceplate.
Figure 3-15
2pGPDsk faceplate
10used
Not BT
(10 BT debug port)
port
For future use

(100 BT)
100 BT
100 BT Ethernet
portsport
2pGPDsk components
The 2-port general processor with disk consists of a motherboard, a memory
daughter card, and a power supply daughter card, with a hard disk mounted
on the motherboard.
The 2pGPDsk connects to the shelf backplane, providing an interface to both

fabric modules.
The 2pGPDsk interface supports these functions

• disk interface
• 1 Mbyte FLASH memory
• 512 Mbyte DRAM memory
• V.24 DCE port for W-NMS Multiservice Data Manager connectivity

The hard drive has data automatically spooled to it by the applications

running on the 2-port general processor.
4-port OC-3 multimode ATM function processor

The 4pOC3MmAtm function processor on the 15000 shelf is a 4-port multi-
mode card that provides an ATM interface to the SGSN. It is used for
connectivity between the 15000 shelf and the 7400 shelf of the SGSN. For all
SGSN configurations except the minimum configuration (see “Minimum
GPRS SGSN subscriber configurations” on page 3-39), the 4pOC3MmAtm is
also used for the GTL application.
This FP may also be used to provide LAN (Gn interface) connectivity instead
of the 100BaseT Ethernet FPs on the 7400 shelf.
Prior to the GPRS5.0 release, the SGSN supported the PQC6 version of the
4pOC3 function processor. Beginning in GPRS5.0, the SGSN supports a
PQC12 version called the 4pOC3E. The newer card provides an increase in
the IP packet forwarding rate that can be supported by the Passport Queue
Controller. The newer PQC12 cards have twice the IP forwarding capacity of
the PQC6 cards. Other than the PQC, the rest of card’s functionality and
capacity is rated the same. The 4pOC3E is mandatory for new SGSN
installations; the 4pOC3 based on PQC2 will be supported until End Of Life.
Note that use of a 4pOC3E card does not increase the committed capacity of
any of the GPRS applications.
Note: In GPRS5.0, a SONET port was required to be provisioned for the

GTL and GIPS applications hosted on the 4pOC3 card, even in
configurations where the line interface was otherwise not needed for
traffic or other purposes. This restriction is removed in the GPRS6.0
release.
Figure 3-16 shows the 4-port OC-3 ATM FP faceplate.

Figure 3-16
4-port OC-3 ATM function processor faceplate
For more information on the 4-port OC-3 ATM FP, see NTP 241-1501-200,
Passport 15000, 20000 Hardware Description.
4 port DS3 channelized FR function processor

The 4-port DS3 function processor (FP) has the following characteristics:
• The line rate is 44.736 Mbps.
• For port configuration, the ports on the FP can be configured as either
unchannelized or channelized. When unchannelized, the entire payload
bandwidth functions as single clear channel. When channelized there are
28 DS1 within a DS3. Each DS1 can then be channelized to 24 DS0
timeslots.
• The DS3 clockingSource attribute in software is module (the default) or
local, and the DS1 clockingSource is sameAsDs3.
The Passport 15000 derives the transmit clock for all ports from the same
reference. There is one transmit clock on the card and it is shared by all the
DS3 and DS1 ports. At the DS3 level, all DS3 components on the card must

have the same clockingSource. The DS3 clockingSource attributes can only
be local or module. At the DS1 level, all DS1 components on the card must
have the same clockingSource. The DS1 clockingSource attribute must be
the same as the DS3 clocking source and can only have a value of
sameAsDs3.
Figure 3-17 shows the 4pDS3Ch faceplate.
Figure 3-17
4pDS3Ch FR function processor faceplate
For more information on the 4pDS3Ch FPs, see NTP 241-1501-200, Passport
15000, 20000 Hardware Description.

4 port Gigabit Ethernet function processor

The 4pGe card (see Figure 3-18) provides 4 Gigabit Ethernet ports and is used
by the SGSN for the Gn and Gp interfaces. The 4pGe FP has the following
characteristics:
• The line rate is 1000 Mbps.
• Supports 1000 BASE-SX and 1000 BASE-LX for short and long range
fiber interconnects through the use of small form factor pluggable (SFP)
optical modules.
• Uses MS3 network processing chipset for higher sustained backplane I/O.
Figure 3-18
4pGe faceplate
4pGe Small Form-Factor Pluggable modules

The Gigabit Ethernet FP can support both LX and SX (long and short range
respectively) modes through the use of separately ordered small form factor
pluggable (SFP) modules (see Figure 3-19). Each SFP module provides one
optical port through a duplex LC connector and up to 4 SFP modules can be
installed per FP.

The LX version:
• Is for long haul (up to 10 km) delivery of the optical transmission
• Interfaces to single mode fiber only.
• Uses a long wavelength laser (1270 to 1355 nanometers) for transmission
The SX SFP module:

• Is for short-range transmission, with a maximum segment length of 0.5
km.
• Interfaces to multi-mode fiber only
• Uses a shorter wavelength laser (770 to 860 nanometers) for transmission.
Note: Only SX mode should connect to SX mode and LX mode connects

to LX mode. The usage of attenuators is not recommended.
Figure 3-19
SX/LX SPF module

Network clock synchronization 3

Internal timing reference
The Passport has a Stratum 3 clocking including holdover capability. This is
compliant with Bellcore GR-1244- CORE and meets the following
characteristics:
• Accuracy: +- 4.6x10-6 (+- 7.1Hz@1.544 MHz / 9.3HZ@2.048MHz) )
• Stability: +- 3.7x10-7/day for the initial 24 hours of holdover
• Pull in range: +-4.6x10-6
External timing reference

The Passport 15000 can accept two external timing references sources (A and
B), for redundancy purposes. These external timing reference sources should
provide a better than stratum-3 timing reference. The chosen timing reference
will then be provided on all outgoing links. These external timing reference
sources should be DS1 or E1 digital timing reference in accordance with
G703. These signals are framed, but they do not carry traffic. The E1 or DS1
is connected to a clocking BITS/Alarm module on the Passport 15000 frame.
In case of failure of the two external timing reference sources, the Passport
15000 goes to the Holdover Mode. In this mode, the stratum 3 Clock of the
Passport 15000 continues to operate at its last adjusted frequency and does
not update its frequency.
Minimum GPRS SGSN subscriber configurations 3

The SGSN is designed to provide a highly available, robust, and scalable
architecture. A large number of variations are possible with I/O and
processing options. This flexibility allows the SGSN to be configured based
on customer network needs. The Network Engineering group engineers each
customer site on a case-by-case basis determined by required capacity and
customer call model.
The minimum single frame configuration for a fully functional SGSN consists
of:
• A single Passport VSS frame
— The Passport 15000 contains:
– Two CP3 cards for shelf control.
– Two 2pGpDsk cards 1:1 sparing mode running the GSC
application.
– Two 4-port OC-3 cards in 1+1 hot sparing mode for shelf
interconnect.
– Two 2pGpDsk cards running the SAS application.
– Two 2pGpDsk cards running the MAP application.

– Two 2pGpDsk for 100BaseT or two 4pGe for 1000BaseT for Gp/
Gn LAN access.
– Four slots are spared.
— The Passport 7400 shelf contains

– Three MSA32 (E1 or T1) cards running the GTL application.
These are configured in 2N+1 sparing mode.
– Two CP2 cards for shelf control.
– Two WPDS cards running the GSD application in N+1 sparing
mode.
– Two 2-port OC3 cards for shelf interconnect.
– Four slots are spared.
• This configuration provides support for up to 40,000 subscribers (GSD
bound) using a low bits/sub model. More GSDs would have to be added
to support a higher data rate per SGSN. Total engineered GSD throughput
per WPDS card is 8 Mb/s. Maximum engineered packets per second is
2700.
The maximum configuration for a GPRS SGSN is a dual frame configuration

and supports a variable number of subscribers based on the call model used.
For more information about single and dual cabinet SGSN configurations, see
Appendix B, “Engineering rules”.
Hardware requirements for OA&M 3

The following sections highlight the peripheral hardware for OA&M of the
SGSN.
Text-based OA&M hardware

The SGSN can also be managed using a text-based interface through a local
operator terminal. The requirements consist of the following:
• any VT100 terminal, or device that emulates a VT100 terminal
• a 9 pin “D” type interface cable, to properly connect the terminal to the
V.24 DCE port on the faceplate of the control processor
• a printer, optional, to print any alarms that appear on-screen
Software distribution site

The software distribution site (SDS) is a workstation that has been set up for
storage, management, and distribution of Passport software. The SGSN uses
file transfer protocol (FTP) to pull software from the SDS to add or upgrade
services, capabilities, or features.

The workstation used for the SDS must have the following capabilities:
• have sufficient hard disk space to accommodate Passport software
• be configured with a CD-ROM drive (Rockridge format)
• have userids and passwords in place for FTP and remote login sessions
• be connected to the network with an IP address
Wireless Network Management System hardware

For information about Wireless Network Management System (W-NMS)
hardware, refer to NTP 450-3101-638, W-NMS Engineering Guide for
OAM4.1.


4-1
Reliability 4
This chapter describes the reliability, redundancy and availability of the
SGSN.
The following is presented in this chapter:

• Redundancy capabilities
• Nodal Manager reliability
• SGSN audits
• Resource overload controls
• Message overload controls
Redundancy capabilities 4
The SGSN Redundancy features allow services to continue with as little
interruption as possible when the following failures occur:
• card reset or failure of an application (GTL, GSD, GSC, etc.)
• For the GTL application, partial Frame Relay network failure where some
of the GPRS NS-VC become unavailable
A card reset occurs in the event of a software failure (or when initiated by the
operator), causing the card to lose all data in memory and reload all of its
onboard software. A card failure usually occurs in the event of a hardware
failure or critical recurring software failure. In either scenario, the redundancy
features act immediately and new traffic is rerouted to other cards in the
SGSN (if available).

4-2 Reliability
There are several redundancy schemes, and the type of redundancy supported
varies by card and application. Table 4-1 lists redundancy types. Table 4-2
provides a summary of SGSN card redundancy.
Table 4-1
Redundancy types
Redundancy type Description
1:1 equipment sparing Two physical FPs are provisioned as one Logical Processor. The Active FP
has a Stand-by FP. The Standby cannot be used while the Active FP is in
service. Therefore, there is no load sharing of the standby FP. It remains
idle until it becomes the Active FP. In the event of a failure of the active FP,
the stand-by FP immediately becomes the Active Processor.
While both FPs may offer service only one has a network connection at
one time. Removing the inactive spare card has no impact on the
connection to the network.
1+1 line sparing Used by ATM Automatic Protection Switching (APS) in which information is
simultaneously sent on both the active and spare links.
1:1 cold sparing Also known as cold standby. The Stand-by FP has no provisioning loaded
on it at failure of the Active FP card. It does not receive information from
the Active FP on the state of current processes and stored information. If
there is a failure of the Active FP, the Stand-by is booted and assumes the
Active FP role and begins processing information. Because it does not
have copies of the active information of the failed FP, any dynamic
information is lost, which may result in the need to re-start any in progress
information that depends on the application that was running on the failed
FP.
1:1 warm sparing The Stand-by FP is loaded with the same software and provisioning
information as the Active FP. It does not receive journaling information from
the Active FP. If the Active FP fails, the Standby FP assumes the Active FP
role and begins processing new transactions.
1:1 hot sparingh The Stand-by FP is loaded with the same provisioning information as the
Active FP. It also receives information from the Active FP on the state of
current processes and stored information in a process known as
“journaling”. If there is a failure of the Active FP, the Stand-by assumes the
Active FP role and begins processing information. Because it has copies of
the active information of the failed FP, there is minimal loss of service and
minimal impacts to the network.
—sheet 1 of 2—

Reliability 4-3
Table 4-1
Redundancy types (continued)
Redundancy type Description
2N load sharing Redundancy technique where the engineered load is carried by twice as
many resources as would be required without redundancy. Both resources
simultaneously carry the load. If one resource fails, the remaining resource
has sufficient capacity to handle the load from the failed card as well as its
original load. For example, if the engineered limit for an individual resource
is 80%, in a 2N configuration, each of the two resources would normally
carry 40% of the full capacity.
N+1 over-provisioning Includes one extra unit of hardware for a given function over the
engineered requirement. Load sharing occurs across all the units of
hardware such that the extra hardware participates in the normal
processing of that function.
In 1+1 sparing, while both FPs terminate connections to the network only
one of the FPs act as the interface to the fabric. Removing the spare
causes the loss of one network connection.
—sheet 2 of 2—

4-4 Reliability
Table 4-2
Functional Processor redundancy summary
Functional Equipment Standby HSM Special considerations

Processor and/ Protection
or application
2pEth100BaseT N+1 N/A No
2pGPDsk (LAN) 1:1 Warm Yes ELS
2pOC3MmAtm2 N+1 N/A No
32pDS1Msa 1:N N/A No
32pE1Msa
4pDS3Ch N+1 N/A No
4pGe N+1 N/A No
CP2, CP3 1:1 Cold Yes NM does not utilize JFK. Other CP3
applications do utilize JFK.
ATM I/O N+1 N/A No MSS 7400
1:1 Hot Yes MSS 15000 1+1 LP APS
GSC 1:1 Hot Yes Recommended for better reliability
N+1 N/A No
GSD N+1 N/A No
GTL 2N+1 N/A No
2N
LI 1:1 Warm Yes Recommended for better reliability.

Must be Warm if co-located with a Hot
application.
Cold No No longer supported as of PC04.
MAP 1:1 Warm Yes
SAS 1:1 Hot Yes Non-redundant SAS configuration is

not supported
Cold No No longer supported as of PC04.

Reliability 4-5
The following sections detail the redundancy capabilities of the various

SGSN applications.
Control processor card redundancy

In the event of a control processor (CP) reset or failure, the Passport 15000
Hot CP Switchover capability is utilized to preserve the services which reside
on the CP. Again, there is no visible service interruption to the user. However,
a second CP card must be installed for this feature to be available. CP
Switchover is supported for both 15000 and 7400 CPs.
If a Master Shelf performs a CP switchover, the Master NM loses state

information and the SVCs go down. Once the switchover is complete, the
SVCs are automatically re-established to all the Slave NMs. The Slave NMs
and the applications on the Master Shelf register with the Master NM to bring
the Master NM back into synchronization.
If a Slave Shelf performs a CP switchover, the Slave NM loses state

information and the SVC between that Slave NM and the Master NM goes
down. Once the switchover is complete, the SVC is automatically re-
established. The applications on the Slave Shelf register with the Slave NM.
The Slave NM registers with the Master NM including its set of applications
to bring the Master NM and Slave NM back into synchronization.
ATM I/O redundancy

Each ATM I/O FP is configured as 1:1. Note that Automatic Protection
Switching (APS) is provided on the 15K where, in case of line failure, the
APS switches to the spare FPs port, while the Active FP continues to process
the traffic. In the case of an FP failure, both the port and FP switch over to
the Spare FP. In the case of an upgrade, there is an immediate switchover
form the Active to Spare FP. The switchover is specified to occur in less than
or equal to 50 ms.
Caution: Carrier grade is guaranteed only for ATM PVCs. SPVC and
SVC type connections are not guaranteed over a failure.
GTL redundancy
The GTL function supports NSE Redundancy via software (see “NSE
redundancy” on page 4-7), and therefore is not spared in the traditional sense
of Passport card sparing. Additionally, the GTL supports a unique
redundancy scheme termed 2N+1, which enables all FPs running the GTL
function to be engineered at 80% CPU capacity. In the 2N+1 scheme, the
external fanout/sparing panel allows one cold standby backup FP to takeover
for any failing FP serving as a GTL (see Figure 4-1). All GTLs on the shelf
load share across NSEs in FP pairs (thus 2N).

4-6 Reliability
Figure 4-1
GTL redundancy
If the SGSN configuration includes two or more cards containing GTL

applications, the following process is executed to ensure continued operation
in the event of a card reset or failure:
• The NS software on other GTLs sends the NS-BLOCK messages for all
NS-VCs on the crashed card. This informs the BSS NS entity that the NS-
VCs in question are not available for service.
• The affected downlink traffic is rerouted to GTLs that are still operational.
Uplink traffic is rerouted by the BSS, which sends it to the SGSN on
unblocked NS-VCs. Load balancing algorithms determine which traffic
goes to which GTLs.
• Upon recovery of the GTL, NS-UNBLOCK messages are sent out to
unblock the appropriate NS-VCs.
Regardless of whether a card reset or failure has occurred, all data in transit
within the GTL application at the time of the error is lost. It is then the
responsibility of the LLC or other higher-layer protocols to recover the lost
data.

Reliability 4-7
When a Frame Relay network failure occurs, some of the NS-VCs of the
SGSN are impacted. In such cases, messages destined for newly unavailable
NS-VCs must be rerouted to other NS-VCs of the same NSE. The NM then
reroutes the affected downlink traffic to other NS-VCs that are still
operational.
NSE redundancy
NSE redundancy enables a single NSE to exist across two GTLs (see Figure
4-2). The ability to provision an NSE on two GTL cards provides a redundant
card.
Uplink data coming from the BSS on a NSE can be received by either of the
two GTLs, depending on the NS-VC to which the message is sent. The other
GTL card that provides NSE redundancy is synchronized using internal
messaging. Every message used to synchronize the NSE information between
GTL cards is acknowledged. This acknowledgement mechanism prevents the
GTL pair from being out of sync under normal conditions. In the event a BVC
state mismatch is detected, an internal audit and recovery mechanism allows
the system to recover on its own.

4-8 Reliability
Figure 4-2
GTL pair architecture for NSE redundancy
BVC/3 BVC/4 BVC/3 BVC/4
NSE 1 NSE 2 NSE 1 NSE 2
NsVc NsVc NsVc NsVc NsVc NsVc NsVc NsVc

A B C D W X Y Z
DLCI1 DLCI2 DLCI3 DLCI4 DLCI5 DLCI6 DLCI7 DLCI8
GTL 1 GTL 2
GTL syncs up with

its mate GTL. NSE,
BVC, NS-VC
information
is exchanged.
Frame Relay network to BSS
NSE redundancy is controlled through the attribute SgGtl associatedGtl. You

can specify any two GTL cards to provide NSE redundancy. BVC information
is shared between the GTL pair.
All or none of the NSEs on a GTL card are redundant. A valid card value set
for attribute associatedGtl signifies that for all NSEs on that card, the mate
exists on the specified GTL pair card. If attribute associatedGtl is not set, the
NSEs on this GTL are not redundant.
GSD redundancy
The GSD function is N+1 spared. This implies that one additional GSD is
provisioned within the SGSN complex. All GSDs within the complex are

Reliability 4-9
load spread. In the event of a GSD failure, the subscribers belonging to that
GSD will lose their PDP context, but will remain attached. Since an
additional GSD is engineered, there should be enough GSD capacity to
accommodate the re-activation of PDP contexts.
Multiple shelves of GSDs (up to 2 shelves) are supported and if N+1

redundancy is provisioned, then the +1 backup GSD can exist on any shelf
supporting GSDs.
If the SGSN configuration includes two or more cards containing GSD

applications, the following process is executed to ensure continued operation
in the event of a card reset or failure:
• Any packets which are destined for the failed GSD are rerouted to a
different GSD. The NM insures that the packets are redistributed in a
balanced fashion.
• All mobiles which have their packets rerouted to a different GSD must be
assigned a new TLLI and must reactivate their PDP contexts. GMM
contexts however are preserved and the MS does not have to re-ATTACH.
Regardless of whether it is a card reset or failure, all contexts in the LLC and
SNDCP layers within the affected GSD application are lost.
GSC redundancy
GSC redundancy provides the ability to preserve GSC data after a crash,
while continuing to provide GPRS mobility services. The GSC function is
N+1 cold or 1:1 hot spared.
Cold sparing
For N+1 sparing, an additional GSC is provisioned within the SGSN
complex. For GSCs that are N+1 cold spared and a GSC failure occurs, the
subscribers belonging to that GSC lose their attachment and PDP context, if
established. Since an additional GSC is engineered, there should be
enough GSC capacity to accommodate re-attachment of the subscribers.
Hot sparing
For GSCs that are 1:1 hot spared, loss of a GSC will not affect MS attaches or
PDP contexts. All data required to maintain the MS context is automatically
journaled to the inactive FP in the GSC pair based on provisioning. All GSCs
within the complex are load spread.
Hot standby redundancy increases the number of 2pGpDsk cards required for
GSC, unless the operator already has additional GSC cards in a cold standby
configuration. Both the active and standby GSC cards must be the same
hardware type (2pGpDsk), have the same PEC code, and be on the same
shelf.

4-10 Reliability
GSC hot standby redundancy is provided by default when both the mainCard
and spareCard attributes are provisioned for the Logical Processor (LP)
component supporting the GSC application. Addition/removal of the
spareCard provisioning attribute causes both cards involved (mainCard and
spareCard for the LP) to be reset. Information on the standby card is provided
under the Shelf Card/* sparedServices component.
Checkpointing
Upon startup of the hot standby GSC application, mobility and session data in
the active GSC application is synchronized with the standby via
checkpointing mechanisms. The standby application instructs the active
application to initiate transfer of mobility and session data upon startup of the
standby card. If the standby card becomes out of sync any time after startup,
it will also initiate checkpointing at that time.
If the active card is in the process of checkpointing with the standby card and
crashed, the new active card will raise an alarm to let the operator know not
all mobility and session data was synchronized.
Journaling
The GSC application receives messages that cause the creation of mobility and
session data, modification of mobility and session data, and deletion of mobility
and session data. Dynamic data is journaled from the active GSC application
to the standby GSC application for synchronization of mobility and session
data. GSC hot standby redundancy implements a journaling mechanism to
preserve the subscriber data on the standby instantiation. This mechanism
involves:
• Sending provisioning data to both active and standby card
• Using the application triggers like GPRS Attach, Routing Area Update,
Location Area Update, etc. to journal dynamic data from the active card
to the standby card.
To achieve hot standby capability and enable switchover on GSC faults
within the shortest possible period of time without any service disruption,
information about the mobile’s location, ID, data session and in general
mobile subscriber information is spared. Information is spared so that a
mobile does not have to reattach, reactivate or reregister in the event of a GSC
failure.
If a failure were to occur while sending information, prior to the standby

being in sync, not all the information is spared, as some information which
was in the transaction is lost. This would mean that some of the subscribers
might have to reattach, reactivate or reregister.

Reliability 4-11
Switchover
A switchover occurs when the control of a service is passed from the active
processor to its standby. A normal switchover is provoked by the failure of
the active GSC card or by any CAS commands such as “reset lp/3”, “restart
lp/3”, “switchover lp/3” or “reset sh card/x” when there is a GSC card
associated with lp/3. The recommended way to force a switchover is with the
CAS command “switchover lp/3”.
Note that when the active card goes down, it becomes a spare card when it
comes up after a switchover.
If the active card is in the process of checkpointing with the standby card and
crashed, the new active card will raise an alarm to let the operator know not all
mobility and session data was synchronized. The message associated with this
alarm is:
• “Checkpointing interupted by switchover. Approximate percentage of
mobiles impacted: 99”
Routine Exercise (REX) Testing

Routine Exercise (REX) Testing enables the SGSN to swap the roles of the
active and standby cards at a provisioned “RexTime”. At the provisioned
“RexTime”, SGSN performs a reset of the standby card to sync up with the
active card. After the standby card has synced up with the active card, SGSN
resets the active card to initiate a switchover. If multiple instances of the
subscriber cards are provisioned, SGSN staggers the REX test for each
subscriber card. This stagger time is 20 minutes. “RexTime” should be set
appropriately to ensure that the REX window does not conflict with busy
hours.
SGSN provides the operator with 3 levels of control for the REX Feature. The
operator may choose to:
1. Disable REX feature.
2. Re-synchronize the standby card at provisioned time if a sync loss was
detected.
3. Enable REX feature to swap roles of active and standby cards at
provisioned time.
The feature is disabled by default. The operator controls the REX feature by
provisioning the “RexType” parameter.
Synchronization loss is determined based on the following gauge stats on the

active and standby cards for a system under nornal usage level.
• Current Attached Subscribers on the active and standby cards mismatch
by 5%

4-12 Reliability
• Current Active PDP Contexts on the active and standby cards mismatch
by 5%.
If the Gauge Stats differences between the active and standby cards exceed
5%, SGSN raises the ‘Sync Loss’ alarm. The sync loss alarm indicates if the
operator must take action to recover from the synchronization loss. If REX
Testing is enabled, SGSN automatically performs recovery action at the
provisioned REX time. Depending on the “RexType” provisionable
parameter the alarm is modified as follows:
• If the REX testing is disabled, the operator is expected to manually reset

the standby card. The alarm has information pertaining to the erroneous
SC card with the following message:
— “Sync loss between active and standby cards. Reset the standby card
to re-synch with the active card”
• If the feature status is set to “resyncStandbyOnly”, the standby card is
reset at the provisioned “RexTime” to recover from the error condition.
The alarm has information pertaining to the erroneous SC card with the
following message:
— “Sync Loss between active and standby cards. Standby card will
automatically be at the provisioned “RexTime” to re-synch with the
active card”
• If the feature status is set to “switchActiveAndStandby”, sync loss
condition is recovered during the REX window. The alarm will indicate
the following:
— “Sync Loss between active and standby cards. Standby card will
automatically be reset during REX testing at the provisioned REX
time.”
GSC locking
Once an active GSC is locked and it has a standby GSC, then the lock has an
effect on the standby as well. If the standby GSC takes over as the new active
GSC, then the lock is transferred to the new GSC. An explicit unlock
operation is necessary to make the GSC to serve new attaches again.
The OSI administrative state (locked, unlocked, shuttingDown) that was

modified by the GSC lock/lock-force/unlock operation will be retained after a
GSC switchover. Also if the detach/cleanup procedure was started as part of
the “lock -force” command (see “Locking/unlocking a GSC” on page 7-46), it
will be reinitiated after the switchover.

GSC redundancy has the following restrictions and limitations:
• GSC and USC redundancy solution applies only to PP15K 2pGpDsk
cards.

Reliability 4-13
• Both the active and spare GSC/USC cards must be of the same hardware
type and on the same shelf.
• Only steady state events will be journaled. Transient events will not be
journaled. For transient events, we will rely on the retry mechanism of
the external entity.
• If the active card crashed before synching all the data, then data for some
mobiles is susceptible to loss.
• Any ongoing SGSN-Initiated transactions are not automatically
reinitiated after a GSC/USC switchover.
• Statistics will not be journaled from the active to the standby card. Only
gauge type statistics will be regenerated on the standby card.
• Sparing can be turned on/off through provisioning; however, doing this
would result in both the active and standby cards resetting.
• GSC and USC redundancy only covers failures that result in a reset of an
FP card.
• Critical provisioning changes will cause both cards to reset (i.e., loss of
redundancy if maxAttachedSubs is changed.)
• BSSAP data is not spared; therefore, on card switchover the SGSN will
send a reset message to the VLR. The VLR can choose to deliver any CS
paging through the BSS directly or still send the page through the SGSN.
The SGSN performs broadcast paging when the reset flag is set.
• HLR Reset interactions are not journaled by Sc Redundancy. During a
HLR Reset, the mobile’s location information is updated in the HLR via a
UGL. If a switchover occurs before the completion of a HLR Reset, the
UGL procedure is not restarted for the remaining mobiles. When the
mobile performs an Attach or IRAU message after a HLR Reset, the
mobile subscription information is updated in the HLR and is journaled
from the active to the standby card.
• The Mobile Reachable Timer on GPRS is restarted for standby mobiles
after card switchover. If the GSD audit is on after switchover, the mobile
may be implicitly detached at the original time.
• The Mobile Reachable Timer on UMTS is restarted for idle mobiles after
card switchover.
• Under certain scenarios such as when the HLR sends segmented SAI
response messages to the SGSN, the standby card will not have all of the
authentication vectors. In these cases, the remaining authentication
vectors will be journaled to the standby when the mobile does a Re-
Attach, Periodic RAU, Intra Rau, Inter RAU or ServiceRequest. If a
switchover where to happen prior to journaling the remaining
authentication vectors, the SGSN will simply issue a SAI request to
retrieve new vectors upon the next Mobile GMM event.

4-14 Reliability
• Changes to REX Test provisionable attributes will take effect only during
the next REX cycle.
• Switchover during REX window will stop REX test. REX window is the
duration between start of REX Testing for the first subscriber card to the
end of REX Testing for the last subscriber card/
• Subscriber cards added to the SGSN during a REX window will be
subjected to REX testing during the next REX cycle.
• In the current release, overload conditions are not considered before
initiating REX Test at the provisioned “RexTime”. Operator is expected
to adjust the provisionable “RexTime” based on peak hour operations of
the network
• It is recommended that REX and TTCT events be provisioned such that
they don't trigger at the same time.
• The Last Mobile Activity Time timestamp in GPRS will not always be in
sync on the active and standby cards. The timestamp is updated on the
standby card only at the completion of a procedure while the active card
updates the timestamp on every incoming message.
SAS redundancy
The SAS application supports 1:1 hot standby redundancy. Both the SAS
application and Lawful Intercept (LI) application may reside on the same
Logical Processor (LP) pair; LI supports 1:1 warm standby redundancy as
described in “Lawful Interception redundancy” on page 4-15. Up to 4 SAS
cards can be provisioned to be active concurrently and each of these active
SAS cards must have a corresponding standby card configured. Thus a total
of 8 SAS cards can be deployed to a shelf.
Figure 4-3 depicts a redundant billing server containing the SAS and optional
LI (Lawful Intercept) application. Both hot and warm standby instances
receive provisioning data. The active SAS application explicitly
communicates its own dynamic data changes to the standby.

Reliability 4-15
Figure 4-3
Card sparing architecture
CAS
Main Card Spare Card
Prov data
hot
SAS SAS standby
dynamic data
warm
LI LI standby
active apps standby apps
The dynamic data on the Active SAS FP is journaled to the Standby FP for all
transactions. Upon failure of the Active FP, all open Call Detail Records
(CDR) are maintained on the FP that takes over as active. Closed CDRs are
preserved on the hard drive. Upon failure of the active card, a switch-over
occurs, causing the stand-by to enable as active and begin processing
incoming billing requests. Billing operations for previously open records
(updates and closes) are maintained. The card sparing strategy reduces the
Billing card outage time, and provides a high-availability solution for SGSN
Billing.
For more information on SAS and SAS redundancy, refer to Chapter 6,

“Accounting”, “Billing redundancy” on page 6-22.
Lawful Interception redundancy

The Lawful Intercept (LI) application supports 1:1 warm standby redundancy.
(References to the LI application here apply only to the portion of LI that runs
alongside the SAS application on the same card or independently on its own
card. This does not include any portion of LI which is part of the subscriber
control cards.) Provisioning the spareCard attribute for the Logical Processor
component supporting the LI application provides redundancy. Addition/
removal of the spareCard attribute causes both cards involved (mainCard and
spareCard for the LP) to be reset.
The card supporting LI is indicated as hot standby though the LI application

operates in a warm standby mode only. As such, it detects whether it is on the
standby card and initializes accordingly. The LI application is loaded,
provisioned and ready for service on the standby card, but no dynamic data
updates are sent from the active card to the standby card for synchronization.

4-16 Reliability
Upon switchover, the standby card receives a “become active” notification

which causes the standby LI application to complete initialization and
reestablish connectivity with the LIG in order to takeover as the active
instance. Any monitoring underway at the time of switchover is terminated.
The LIG in turn downloads current interception orders to the new LI. The LI
function serves the GSCs present on that shelf along with the GSDs
supporting PDP Contexts for the subscribers associated with the GSCs. The
target to associate path is not impacted due to an LI failure. Switchover of the
LI application is functionally equivalent to a card reset though recovery is
quicker.
SAS and LI often reside on the same card. However these two components
use different mechanisms for determining which SC cards each instance of
the component supports. With the Multi-SAS feature, SAS uses a load
balancing technique and LI uses provisioning to determine the SC
communication path. Care must be taken when determining the shelf
configuration with respect to card failures. Multi-active LI is not supported.
Therefore, each SC card can be associated with only one LI card and LI
should be configured on only one of the SAS cards per shelf.
MAP redundancy
The MAP application supports 1:1 warm standby redundancy provided the
MAP cards are in the same Passport 15000 shelf. Multiple MAP cards can be
provisioned on different shelves to balance the load and to eliminate
bottlenecks. If the active MAP application or hardware experiences a failure,
the standby MAP application becomes active. Any MAP transactions in the
progress queue may be lost, but the application is available for any new
transactions. The MAP application does not support in-service software
upgrades.
Existing TCAP sessions and client registration information are lost upon card
failure. All clients have to reregister when the card becomes available. See
“Node failure processing and MAP-C” on page 2-14 and “Node failure
processing and MAP Stack” on page 2-21.
The SGSN performs retries when no response is received from the MAP
Card, until either an error is received or the maximum number of retries is
reached. The SGSN will then either allow the PDP Context to continue or
request the PDP Context to be discontinued based upon the provisioning of
the Default Handling field in the G-CSI on the HLR.
Given the nature of the MAP application:

• Transaction oriented with short time durations per transactions
• Application level re-transmissions

Reliability 4-17
short outages of the MAP function can be tolerated with little to no

degradation in service. 1:1 ELS is not supported on the 2pGPDsk hosting the
MAP application even though the MAP application may be warm spared.
Gigabit Ethernet redundancy

The Gigabit Ethernet card supports 1:1 cold standby redundancy. In the event
of a hardware failure, the standby GigE card software is downloaded and the
card takes over the IP routes from the failing FP.
Caution: The cold standby model requires the takeover FP to re-

establish routes upon activation. This may result in OSPF/RIP “storms” as
the FP queries nodes to build its route tables.
IP Carrier Grade redundancy

IP redundancy can be provided when static IP Route Entries and Static ARP
Entries are provisioned.
If a CP fails, most of the IP processes and data structures are preserved.

When the standby CP becomes active via a CP Switchover (CPSO), the IP
components resynchronize their data with the new CP. Note that only the
outage times for CPSO with a committed provisioning view are improved
because the IP components on the FP are recreated and reinitialized if the
provisioning View is uncommitted.
Similar to CPSO, any Hot or Warm spared FP in the system utilizing IP will
also have IP redundancy for Static IP Route entries.
The IP components take advantage of the journaling mechanism so that the

Local Cache Manager (LCM) entries and Address Resolution Protocol (ARP)
entries will be populated to the spared FP.
Journaling Framework (JFK) functionality accompanied with the Equipment

Protection (EP) of the FP ensure the service outage duration will be
minimized to be shorter than 50 msec for optical cards and no longer than 100
msec for electrical cards.
Caution: Service outage reductions do not apply to configurations employing

Equal Cost Multi-Path (ECMP) or IP Class of Service (CoS).
Redundancy limitations
SGSN redundancy does not address any issues which relate to shelf resets.
Shelf resets are either operator initiated or considered software failures and
are not handled by SGSN redundancy. This limitation includes the shelf reset
that occurs during the upgrade procedure to the SGSN.

4-18 Reliability
Nodal Manager reliability 4

The Nodal Manager provides automatic recovery functionality for some inter-
shelf communication problems. Alarms are provided for Nodal Manger
problems that cannot be resolved automatically, which improves the
robustness of multi-shelf systems. The status of inter-shelf communication
can be monitored using the OSI state of the Sgsn Shelf ConnectionToMaster
(ConM) and Sgsn Shelf ConnectionToSlave (ConS) components.
OSI State
In a multi-shelf system, a single ConM component is provisioned on each
slave shelf, and several ConS components are provisioned on the master (one
for each slave.) The ConM component on each slave shelf contains the
address of the master shelf and information about the ATM connection to the
master shelf. Each ConS component on the master shelf contains the address
of a slave shelf and information about the corresponding ATM connection.
By setting the ConS and ConM OSI State for a particular connection to
Unlocked, Enabled, Busy (UEB) when the slave is registered with the master,
and by setting it to Unlocked, Disabled, Idle (UDI) otherwise, this feature
allows the status of inter-shelf application communication to be established.
A change from UEB to UDI is accompanied by a SET alarm with a severity
of criticalSeverity_c, a probable cause of callEstablishmentErrorCause_c,
and a type of communicationsType_c. A change from UDI to UEB following
a SET alarm clears that alarm with a CLR alarm. These alarms are described
below.
Note that a UEB state for a particular connection shows that the master and
slave applications are communicating freely. This is different from the
information obtained from the AtmConnection subcomponent of the
associated ConS or ConM. The AtmConnection State attribute specifies the
link status, but says nothing of the application status. The link could
conceivably be up but the applications not communicating, so inter-shelf
communication must be monitored by tracking application activities, such as
registration.
The master NM keeps a table that describes the status of each slave
connection with a ShelfState variable that characterizes the connection as
Unequipped, Link Down, Unregistered, or Registered. The Registered state
indicates that the master and slave NMs are communicating freely, and any
other state indicates that they are not. Thus, the ConS OSI State is directly
linked to the ShelfState of the connection: if the ShelfState of a particular
connection is Registered, then its OSI State is UEB; otherwise it is UDI. The
slave NMs do not track the ShelfState like the master, so the ConM OSI State
variables must be set on a case by case basis.
For ConM and ConS OSI state diagram and description, see “OSI states”,
section “Sgsn Shelf ConM and ConS” on page 7-83.

Reliability 4-19
Invalid Master
The Nodal Manager is designed to work with only one master; however, there
is nothing to prevent a user from provisioning multiple masters. To identify
such errors, this feature tests incoming calls on each slave, comparing the
NSAP of the calling NM with the NSAP provisioned in the slave’s ConM
component. If the test fails, the call is rejected and a SET alarm is raised.
The slave starts or re-starts a timer each time a call is rejected from an invalid
master. If the timer is allowed to reach a pre-determined value without being
reset, the slave will assume that some change (e.g., re-provisioning of the
invalid master) has taken place and will issue a CLR alarm.
Resource Failure
If insufficient resources are available for a call to be established or
maintained, the originator is issued a resource failure notification. If the
master is notified of a resource failure, the associated shelf state is set to Link
Down, and accordingly, the associated OSI State is set to UDI. This feature
then issues a SET alarm and waits for a short amount of time before
attempting recovery. This provides an opportunity for the required resources
to become available. If a slave is notified of a resource failure, this feature
sets the associated OSI State to UDI, and issues a SET alarm. The slave does
not attempt recovery because only the master can place calls. This feature
issues a CLR alarm when the call is reestablished.
Outgoing Call Request Failure

To communicate with a slave NM, the master NM must request an outgoing
call. The associated shelf state is set to Link Down before the request, so this
feature sets the associated ConS OSI State to UDI. If the request fails, this
feature waits for a short amount of time and then retries the call. This
provides an opportunity for the required resources to become available. If the
retry fails, this feature issues a SET alarm and continues to retry the call
periodically. If the SET alarm is issued, a CLR alarm will be issued when the
call is placed successfully. Slave NMs are not affected by this type of failure
since they do not place outgoing calls.
Incoming Call Timeout

Some problems can prevent the master from successfully calling a slave. For
example, if a ConS component is missing from the master’s provisioning,
communication with the associated slave is impossible, and the master shelf
will not be able to detect the problem. To inform the operator of this type of
situation, this feature implements a timer on the slave to be started when the
slave is initialized, and cancelled when a call is received from the master. If
the timer is allowed to expire, this feature issues a SET alarm and the
associated OSI State remains UDI. When the slave successfully registers
with the master, this feature issues a CLR alarm and updates the OSI State to
UEB. If the master detects that the slave cannot be contacted (for example, if
the master is provisioned with a ConS with an incorrect NSAP), it may
generate another alarm (for example, an outgoing call request failure alarm).

4-20 Reliability
Taken together, the alarms from the master and the slave will help to identify
the cause of the problem.
Registration Error
If a slave receives an error response when trying to register with the master, it
continues to try to register. After a certain number of attempts, this feature
issues a SET alarm to inform the operator that the slave is trying to register.
The OSI State remains UDI as the slave continues to attempt registration.
This feature issues a CLR alarm when the slave successfully registers with
the master. Although the slave is designed to respond appropriately to
registration error messages, this functionality is currently unused because the
master only sends registration OK messages. Also, since the master does not
send registration error messages, it does not generate any associated alarms.
Call Released
If the far end equipment releases a call, the near end equipment is notified.
Upon receiving this notification, the master sets the associated shelf state to
Link Down, so this feature sets the associated OSI State to UDI and issues a
SET alarm from the master. If the slave receives notification of call release,
this feature sets the OSI State to UDI, and issues a SET alarm from the slave.
Attempted automatic recovery is already implemented on the master, so in
either case, this feature issues a CLR alarm from the NM that issued the SET
alarm as soon as the call is reestablished.
Registration Success
To inform the user that a slave has registered with the master, this feature
implements a registration success alarm. Since this alarm is simply
informational, and requires no action on the part of the user, it is implemented
as a MSG alarm. This alarm is generated on the master when a slave’s
registration message is accepted, and it is generated on the slave when the
master’s registration acknowledge message is received. If a slave has an
outstanding SET alarm for a registration error, the master’s registration
acknowledge message will trigger a CLR alarm for the registration error
instead of the normal MSG alarm for registration success.

Reliability 4-21
SGSN audits 4
The SGSN has an audit solution to guard against errors that can lead to
outages. The audits apply only to the GSC, TCAP, and CP cards.
The audits are configurable from the console to allow tuning of audit
parameters or to turn audits on or off. The audit configuration interface is not
customer visible; there are no CAS components or interface to control the
audits. Audit configuration is meant for Nortel personnel only.
All audits generate debugging information that is viewable from the console.
In addition, any critical information is spooled to disk. This is especially true
when an audit determines that an FP reset is necessary. Audits can also
generate set/clear alarms; for more information see “Audit alarms” on page 7-
45.
The audit solution includes the following audits:

• Hung process audit
• Memory audit
• Leak audit
• Corruption audit
• Nodal manager audit
Hung Process Audit

The Hung Process Audit periodically pings an Execution Engine to determine
if that Execution Engine is able to process new Process Environment (PEV)
messages. It can also determine if the Execution Engine is stuck in an infinite
processing loop. If it is determined that an Execution Engine is in one of
these two states, the FP hosting that Execution Engine is reset.
Note: EventLogger tracing on the FP card slows down the processing of

the FP. As a result it starves the Execution Engine, so the Execution
Engine cannot respond to the Hung Process Audit ping requests. This
causes the Hung Process Audit to crash the card. It is advisable not to turn
on all the Event Logger traces in the startup card.
Memory Audit
The memory audit is split into two areas: memory leak detection and memory
corruption detection. Both areas are described below. The decision to audit
certain memory blocks and not others was made using information from
customer sites, as well as internal analysis. Critical memory blocks, and
memory blocks that have been prone to error in the past were rated as
necessary for inclusion in this feature.

4-22 Reliability
Leak Audit
The Memory Leak Audit runs all the time, regardless of whether the audits
are on. The leak audit depends upon the Mem’ PC04 feature work. Each
pool that is audited provides a leak detection function and a maximum
amount of time each block in the pool can be allocated. If the maximum
amount of time passes, Mem’ invokes the leak detector function. At that
time, the auditor determines if the block is leaked or not.
Blocks that are leaked are re-claimed and all resources associated with the
block are cleaned up. Blocks that are not leaked are given more time to be
allocated.
The Leak audit maintains internal counters to keep track of the number of
leaked blocks found and the number of blocks that required more allocation
time.
Corruption Audit
The Memory Corruption Audit verifies the integrity of a memory block. The
audit verifies that all of the values in the block are correct. If any of the
values are not correct, the audit attempts to de-allocate the memory block and
clean up any associated resources. If a memory block cannot be returned to
the memory pool, the audit raises an alarm to the operator the first time this
scenario occurs. If the number of corrupt memory blocks that cannot be re-
claimed reaches a defined threshold, the audit raises another alarm.
The corruption audit maintains counters to keep track of the number of

corrupt blocks found, number of corrupt blocks fixed, and number of corrupt
blocks that were unable to be fixed.
Nodal Manager Audit

The Nodal Manager Audit verifies that the required FPs are available for an
SGSN to provide service to mobile customers. If the FPs are not available,
then the audit raises an alarm. The type of alarm depends upon the criticality
of the FP that is not available.
The Nodal Manager Audit also raises an alarm if the SVC between two
applications on an SGSN is out of service. The alarm will only be cleared
when the SVC in question is back in service.
Audits and redundancy

The only section of the audit solution that would impact redundancy is the
memory audits. Also, only if corrective measures are taken would
redundancy be impacted. The audit itself has no impact on redundancy.
Leaked and corrupt blocks that are returned to the memory pool do not need
to be journalled, since only the memory location could be used to identify the
block on the standby card. Since the same block will already have a different

Reliability 4-23
memory location on the standby card, there is no information that can be

given to the standby card to return the block.
Any resources that are cleaned up as a result of returning a memory block to

the memory pool will use existing redundancy mechanisms to update the
standby card.
Resource overload controls 4

Resource overload can be defined as the SGSN running out of memory and/or
central processor unit (CPU) resources to the extent that it can no longer
adequately handle existing and new service requests. The SGSN implements
an overload controls framework that applications can use to manage overload
situations such as CPU and memory resource exhaustion.
Note 1: CPU overload control is disabled by default and can be enabled

by Nortel development and field service personnel only. For information
about enabling CPU overload control, contact Nortel Technical Support.
Note 2: Subscriber Count overload detection is enabled by default.
Resource overload controls provide:

• Central overload control agent that exists on control processor (CP) and
GPRS Subscriber Control (GSC) application processors (cards).
• For GSC application processor cards, a Central Processing Unit (CPU)
overload detection mechanism will generate customer-visible alarms that
signal CPU overload onset and CPU overload abatement on each
application processor. The CPU overload alarm is disabled by default and
can be enabled by Nortel personnel.
• On-card command utilities that allow Nortel personnel to turn overload
controls on and off.
• On card command utilities that allow Nortel personnel to alter the pre-
defined overload onset and abatement thresholds that exist for CPU
overload for each application processor.
• On-card command utilities that allow Nortel personnel to determine for a
given application processor what resources are in overload state and what
the level (Critical, Major, Minor, None) of the overload condition is.
• Collected and operational statistics that define what the CPU overload
level was for the GSC application processors.
• Collected and operational statistics that define how many subscriber
attach requests and session activate requests were rejected due to CPU
overload on the GSC application processors.

4-24 Reliability
• Collected and operational statistics that define how many subscribers

attach requests were rejected due to attached subscriber overload on the
GSC application processors.
Overload terminology
In general, all overload conditions can be characterized according to Figure 4-
4. This figure shows an example resource usage characteristic along with the
defined overload regions.
Figure 4-4
Resource usage characteristic example showing overload regions and
hysteresis bands
KEY :-
L3 => Level 3 ; L2 => Level 2 ; L1 => Level 1
E.L. => Engineering Limit;
100
Overload Level 3 (critical)
L3 onset
L3 abatement
Resource Usage %
Overload Level 2 (major)

L2 onset
L2 abatement
Overload Level 1 Exit Overload Level 1 (minor)

L1 onset / E.L.
L1 abatement /
Exit Level
Overload Level 1 Entry
Overload Level Normal
TIME
Key points to note about Figure 4-4 are:

• The shaded bands illustrate hysteresis regions, which are configured
regions that attempt to prevent a resource from moving into and out of
overload. Once the resource usage has crossed the onset threshold / level
(for example, L3 onset), it cannot return to the lower operating region
(major) until it has correspondingly crossed the abatement threshold (L3
abatement).
• The Engineering Limit (E.L.) marks the boundary where the system
moves from the guaranteed operational region into the overloaded region
where service levels are not guaranteed.

Reliability 4-25
• Abatement level (L1) is also referred to as the Exit Level as this marks the
boundary where the system moves from the overloaded state back into the
normal operating region (guaranteed service operating region).
The value of L1 abatement should not be greater than 90% of the
Engineering Limit.
• Overload control actions do not become active until the resource usage
has entered into the critical overload level. Prior to this the overload levels
referred to as minor and major provide a warning mechanism whereby
customer visible set alarm indications are generated.
GSC functional changes
Following are the changes to GSC application processor functionality for CPU
overload and attached subscriber overload conditions:
• If CPU overload controls are active, and the CPU is considered to be at a
critical overload level on the GSC, overload controls on the GSC
application processors are invoked and new subscriber attach request
messages are discarded. Once the CPU overload condition abates below
the critical overload abatement level, future subscriber attach request
messages are then allowed to proceed. Minor and major CPU overload
conditions only result in the generation of CPU overload set alarm
indications. The CPU overload set alarm condition is cleared with a CPU
overload clear alarm when the CPU overloads level falls into the normal
operating region.
• Support is present to discard attach and session activation request
messages during CPU overload conditions. However, this functionality is
by default inactive and if required must be enabled by Nortel support
personnel.
• If the number of attached subscribers reaches the provisioned maximum
number of attached subscribers, future mobile attach requests are rejected
until the number of currently attached mobiles falls below the maximum
provisioned number of attached mobiles. The subscriber count overload
set alarm condition is cleared with a subscriber count overload clear alarm
when the subscriber count overloads level falls into the normal operating
region.
• If CPU overload controls are active and both critical CPU overload and
critical subscriber count overload exist, precedence is given to subscriber
count overload. This is because the action assigned to subscriber count
overload (that is, 100% mobile attach request discards) is at least as
severe as any corresponding CPU overload control action.
• If CPU overload controls are active and either critical CPU overload or
critical subscriber count overload exists, the action is determined by
which ever is in critical overload.

4-26 Reliability
GSC subscriber count overload control procedure

When the number of attached subscribers has risen above the critical overload
threshold, 100% of all future subscribers attach request messages are rejected
with a reject cause of “congestion.” Rejection of subscriber attach request
messages continues until the number of attached subscribers has fallen below
the configured L3 onset threshold for attached subscribers (refer to Figure 4-
4). The L3 onset value is set to be equal to the provisioned maximum number
of attached subscribers.
GSC CPU overload control procedure

When the CPU usage level on the GSC application processor has exceeded
the critical level (L3 onset), future mobile attach request and or mobile
session activation request messages may be discarded. The reject cause is set
to “congestion” for attach rejection, and “insufficientResources” for
activation rejection. The rules for determining the actions (if any) to take
during critical CPU overload conditions are as follows (control actions are
assumed active unless otherwise stated):
• If CPU overload control actions are enabled for attach request message
discarding (this is disabled by default), then the initial number of attach
request messages that will be discarded is determined by the following
formula (refer to Figure 4-4):
Attach Request Discard % = (L3 Onset % - L1 Abatement %) / 2
Every second thereafter the discard rate is incrementally increased until either
the CPU usage level falls below L3 abatement or the discard rate reaches
100%. Assuming that the CPU usage rate falls below L1 abatement, the
discard rate is incrementally decreased to zero discards (this assumes that the
CPU usage rate does not rise above L1 onset).
• If CPU overload control actions are enabled for session activate request
message discarding (this is disabled by default), then the initial number of
session activate request messages that will be discarded is determined by
the following formula:
Session Activate Discard % = (L3 Onset % - L1 Abatement %) / 2
Every second there after the discard rate is incrementally increased until
either the CPU usage level falls below L3 abatement or the discard rate
reaches 100%. Assuming that the CPU usage rate falls below L1 abatement,
the discard rate is incrementally decreased to zero discards (this assumes that
the CPU usage rate does not rise above L1 onset).
If both CPU overload and subscriber count overload exist, the overload
control action that is applied for attach request message discards is the same
as described in “GSC subscriber count overload control procedure” on page
4-26.

Reliability 4-27

This release of resource overload controls has the following restrictions and
limitations:
• The Resource Overload Control framework is not controllable from the

Component Administration System (CAS). Instead, overload controls
such as overload enable/disable and threshold settings are controlled from
on-card debug command utilities.
• The presence of the resource overload control framework does not mean
that the SGSN system will not experience overload related problems such
as card crashes.
• There is no bearer path application based packet discarding due to bearer
path related overload conditions.
• Pool managed resource congestion conditions must be detected and
handled from the applications that use the pool manager resource pools.
Note there is no pool managed resource overload detection.
• No application processor overload control operations other than those
already discussed are supported.
Message overload controls 4

SGSN Message Overload Controls (SMOCs) provide a mechanism to handle
message overload conditions caused by message request rates that are higher
than the rates that the SGSN is engineered to handle. These conditions can
potentially be triggered by high Attach or RAU Request traffic, bulk Update
GPRS Location (UGL) requests following an HLR-Reset, bulk location
update requests triggered by IntraSGSN RAU traffic, and bulk MS-
ACTIVITY-INDICATION requests following an HLR-Reset. Such
conditions may often trigger resource problems in the message signaling path
at the GSC card or TCAP card such as exhaustion of MAP Client or MAP
Stack transaction buffers, or congestion of SS7 links at the SIG.
Message overload controls can detect the following types of overload

conditions:
• When MAP Client transaction buffer occupancy for a specific message
type exceeds the engineered MAP Client transaction buffer occupancy for
that message type on the GSC card
• When MAP Stack transaction buffer occupancy for a specific message
type exceeds the engineered MAP Stack transaction buffer occupancy for
that message type on the TCAP card
• When the message rate for a specific message type exceeds the current
allowable message rate for that message type based on SIG congestion
feedback

4-28 Reliability
• When the message rate for a specific message type exceeds a fixed
configured message rate
Note: In this section, the term “overload” or “overload condition”
signifies that one or more of the above overload conditions has been
detected.
In general, a message overload control has the following responsibilities:

• Detect the potential message overload onset and abatement condition
• Handle the potential message overload onset and abatement condition
• Set and clear alarms to alert the operator
• Peg applicable statistics associated with the message overload condition
Message overload handling

Figure 4-5 shows a conceptual view of how the message overload handling is
performed.
Figure 4-5
Message overload handling
The functional entities shown in Figure 4-5 are explained below:
• Message Overload Control: A message overload control is placed at a

specific point (Overload Detection Point) in the SGSN call processing
software, in order to detect a potential message overload condition. The
overload control accomplishes its objective on the basis of provisioned
and/or dynamic overload criteria.
• Provisioned Overload Criteria: The main provisionable criterion is the
maximum rate-allowed value. This value specifies the maximum message
rate that will be allowed to pass through if no dynamic overload criteria

Reliability 4-29
were defined or if dynamic criteria were defined but system was not
overloaded. Besides these, there are several auxiliary provisionable
criteria such as the rate increase/decrease percentage, the Set/Clear alarm,
set/clear delays, etc. which are used to fine-tune the overload control
behavior. The provisionable criteria for each overload control are detailed
in the .Configuration Management. section in the document.
• Dynamic Overload Criteria: These criteria allow the system to operate
in a “closed loop” mode. The usage of “closed loop” means these criteria
allow the overload control to perform overload calculations in real-time,
using data such as SIG-SS7 congestion data, MAP Client transaction
occupancy data, or MAP Stack transaction occupancy data. These data are
used by the overload control to adjust its real-time overload thresholds.
For applicable SMOCs, the SIG congestion data is used to calculate an
effective allowable message rate in each one second interval.
• Alarms/Counters: The overload control has the ability to set alarms upon
the detection of a message overload condition and clear them when the
condition ceases. The overload control also pegs applicable OMs and
collected statistics.
Messages with overload control

The SGSN has message overload control mechanisms for the following
messages:
• HLR Reset
• Attach
• Send Authentication Request (SAI) and non-SAI
• InterSGSN RAU
• Location Update Request
• BSSAP+ MS-Activity Indication
• SMS-MO
• SMS-MT
• InitialDPS
Appropriate Set/Clear alarms are set and cleared during the message overload
handling sequence to alert the operator to the onset and abatement of the
overload condition. The overload criteria applicable to these controls are
covered in “Overload criteria” on page 4-33. The following sections describe
the overload control for each message listed above.
HLR Reset
When the SGSN receives an HLR reset, all mobile contexts associated with
that HLR must be refreshed with an Update GPRS Location (UGL) procedure
towards the HLR. If all mobiles associated with the reset-HLR request service

4-30 Reliability
(such as a PDP- activate) in the same time window, this will trigger a burst of
UGL-requests that can potentially exceed the engineered UGL request rate.
This overload condition will impact the entities in the UGL message
signaling path such as the GSC card, TCAP card, SIG and SS7 links.
To prevent this, an overload control is introduced at a suitable point in the

HLR-Reset UGL message flow. This control is implemented on the GSC
card. When the overload control detects an overload condition, it triggers
HLR-Request UGL requests to be flagged for sending later. This means the
UGL will be attempted again on the next mobile activity or when the
overload condition ceases, depending on the state of the mobile in the SGSN.
Attach (normal and combined)

When the SGSN receives a rate higher than the engineered rate of Attach
requests, there is a potential for overloading the entities in the SGSN
signaling path such as the GSC or TCAP card, SIG and SS7 Links. To prevent
this, an overload control is introduced at a suitable point in the attach message
flow. This control is implemented on the GSC card. When the overload
control detects an overload condition, it triggers Attach requests to be
dropped until they are below or equal to the message overload criteria for
this control.
SAI
For a TCAP card serving several GSC cards, there is a potential for a high
number of SAI requests from each GSC card to be funneled onto the TCAP
card which exceed the SAI engineered rate of the TCAP card. Another
potential problem is if the TCAP-MAP transaction buffers occupied by the
SAI message exceed the engineered buffer occupancy. Both these conditions
can potentially drive the TCAP card as well as the upstream entities such as
the SIG and SS7 links into overload.

TCAP component handling code. This control is implemented on the TCAP
card. When the overload control detects an overload condition, it triggers SAI
requests to be dropped until they are below or equal to the message overload
criteria for this control.
Non-SAI
Similar to the SAI overload control, another message overload control has
been introduced to cover all other messages besides the SAI message. This
control is called the “Non-SAI overload control” and its mandate is to protect
the TCAP card from a high number of non-SAI message requests which
exceed the engineered non-SAI message rate. Note that the non-SAI message
overload control does not have a buffer occupancy overload criterion. This is
because the buffer occupancy overload criterion is already applied to the SAI
overload control. Therefore, the rest of the TCAP-MAP buffers are
automatically available for non-SAI messages.

Reliability 4-31
Like the SAI overload control, the non- SAI overload control is introduced at
a suitable point in the TCAP component handling code. This control is
implemented on the TCAP card. When the overload control detects an
overload condition, it triggers non-SAI requests to be dropped until they are
below or equal to the message overload criteria for this control.
InterSGSN-RAU (normal and combined)

A normal InterSGSNRAU occurs when a GPRS-attached subscriber changes
SGSNs. A combined InterSGSN RAU occurs when a GPRS and IMSI-
attached subscriber changes SGSNs and MSC/VLRs. In these scenarios,
when the SGSN receives a rate higher than the engineered rate of InterSGSN-
RAU requests, there is a potential of overloading the entities in the SGSN
signaling path such as the GSC or TCAP card, SIG and SS7 Links.

InterSGSN-RAU message flow. This control is implemented on the GSC
card. When the overload control detects an overload condition, it triggers
InterSGSN-RAU requests to be dropped until they are below or equal to the
message overload criteria for this control.
Location Update Request

When the SGSN receives a rate higher than the engineered rate of
IntraSGSN-RAU (Periodic or Combined) requests, there is a potential of
generating bulk Location Update requests, thereby overloading entities in the
SGSN signaling path such as the SIG and SS7 links. To prevent this, an
overload control is introduced at a suitable point in the IntraSGSN-RAU
message flow. This control is implemented on the GSC card. This overload
control handles both periodic and combined IntraSGSN-RAU messaging.
This also covers overload control of MSC/VLR location-update messaging
needed following a VLR-Reset. When the overload control detects an
overload condition, it triggers Location Update requests to the MSC/VLR to
be dropped until they are below or equal to the message overload criteria for
this control.
When a Location Update is dropped due to overload, the RAU-Accept is sent

to the mobile with a cause code=Congestion (decimal 22) and update-
type=RA-only (indicating that LA update was not successful).
BSSAP+ MS-Activity Indication

Following an HLR reset, the VLR informs the SGSN to tag all mobile
subscribers that are VLR-attached via the SGSN with the .Non-GPRS Alert
(NGAF). Flag. This means that upon the next mobile activity of the NGAF-
tagged subscriber, a BSSAP+ MS- Activity Indication message needs to be
sent to the VLR. In this case, an overload condition can potentially be
triggered by a burst of BSSAP+ MS-Activity Indication message activity if
all mobiles associated with the reset-HLR request service (e.g. PDP-
activation) in the same time window. This overload condition will impact the

4-32 Reliability
entities in the BSSAP+ MS-Activity Indication signaling path such as the HP-
SIG and SS7 links.

BSSAP+ MS-Activity Indication message flow. This control is implemented
on the GSC card. When the overload control detects an overload condition, it
triggers the BSSAP+ MS-Activity Indication request to be re- tagged for
sending later (that is, the BSSAP+ MS-Activity Indication will be attempted
again on the next mobile activity).
SMS-MO
When the SGSN receives a rate higher than the engineered rate of SMS-MO
this, an overload control is introduced at a suitable point in the SMS-MO
message flow. This control is implemented on the GSC card. When the
overload control detects an overload condition, it triggers SMS-MO requests
to respond back to the originating mobile with a CPError message with cause
set to “congestion” until they are below or equal to the message overload
criteria for this control.
SMS-MT GSC
When the SGSN receives a rate higher than the engineered rate of SMS-MT
requests, typically following an SMSC reset, there is a potential for
overloading the GSC card. To prevent this, an overload control is introduced
at a suitable point in the SMS-MT message flow. This control is implemented
on the GSC card.
When the overload control detects an overload condition, it triggers the

sending of a MAP-MT-FORWARD-SHORT-MESSAGE Response primitive
with User Error = “Subscriber Busy for MT SMS” (including
GprsConnectionSuspended = True extension parameter) to the GMSC, for
every SMS-MT request that exceeds the SMS-MT GSC card overload
criteria. See 3GPP TS 29.002, “Mobile Application Part (MAP) specification
(Release 1999)” for further details about this primitive.
SMS-MT TCAP
When the SGSN receives a rate higher than the engineered rate of SMS-MT
requests, typically following an SMSC reset, there is a potential for
overloading the TCAP card. To prevent this, an overload control is introduced
at a suitable point in the SMS-MT message flow. This control is implemented
on the GSC card.
When the overload control detects an overload condition, it triggers sending

of a TC-U-ABORT message to the GMSC for every SMS-MT request that
exceeds the SMS-MT TCAP card overload criteria.

Reliability 4-33
InitialDPGPRS
When the SGSN detects a rate higher than the engineered rate of CAMEL
originations triggered by PDP-Establishment or PDP-ChangeOfPosition
this, an overload control is introduced at a suitable point in the CAMEL
message flow. This control is implemented on the GSC card. When the
overload control detects an overload condition, it triggers the PDP-Context
requesting CAMEL service to receive CAMEL “default handling” treatment.
Overload criteria
This section describes the two types of overload criteria, dynamic and
provisionable.
Dynamic criteria
Dynamic criteria are:
• SIG-congestion information: indicates whether the SIG is congested. This
criterion applies to all SGSN message overload controls except the SMS-
MT TCAP Overload Control, SMS-MT GSC Overload Control, SAI
Overload Control and Non-SAI Overload Control.
• MAP Client transaction buffer occupancy information: indicates the
current MAP Client transaction buffer occupancy level. This criterion
applies to HLR- Reset UGL Overload Control, Attach Overload Control,
InterSGSN RAU Overload Control and SMS-MO Overload Control and
SMS-MT GSC Overload Control.
• MAP Stack transaction buffer occupancy information: indicates the
current MAP Stack transaction buffer occupancy level. This criterion
applies to the SAI- Overload Control and SMS-MT TCAP Overload
Control.
Provisionable criteria
The default values for provisionable criteria are specified by the Nortel Systems
Engineering team based on the Nortel SGSN call model and the SGSN/SIG
network configuration. Provisionable criteria are:
• Maximum Rate: maximum message rate allowed by overload control to
pass through. This criterion applies to all SGSN message overload
controls.
• MAP Client Transaction percentage threshold: percentage of MAP Client
transaction buffer occupancy threshold. This indicates how many MAP
Client transaction buffers may be used up after which overload control is
applied. This criterion applies to HLR-Reset UGL Overload Control,
Attach Overload Control, InterSGSN RAU Overload Control, SMS-MT
GSC Overload Control and SMS-MO Overload Control.

4-34 Reliability
• MAP Stack Transaction percentage threshold: percentage of MAP Stack

transaction buffer occupancy threshold. This indicates how many MAP
Stack transaction buffers may be used up after which overload control is
applied. This criterion applies to SMS-MT TCAP Overload Control and
SAI Overload Control.
• Set/Clear alarm Clear Delay: consecutive seconds of overload inactivity
before Set/Clear alarm is cleared. This value may be used to prevent
alarm oscillations (cycles of Set/Clear alarm setting and clearing). For
example, we want to wait 5 consecutive seconds of non-overload before
clearing the alarm. This criterion applies to all SGSN message overload
controls.
Overload control example

Figure 4-6 illustrates the operation of the Attach overload control and the SAI
overload control. Both these overload controls work in conjunction to protect
each of their cards, the GSC and TCAP card as well as flow-control of
upstream messaging to the SIG. The behavior of the rest of the overload
controls is along similar lines for each of their overload criteria. Therefore,
the Attach/SAI overload control has been used as a typical example.

Reliability 4-35
Figure 4-6
Attach/SAI overload control example
Attach/SAI Overload Control & Congestion Feedback
Max SC Attach Rate Thresh=30

Min SC Attach Rate Thresh=1
GSC MAPc Buffer Thresh=30% Max SAI Rate Thresh=40
GSC-1
SC-1 30, 15, 7, 3, 2, 1
MAP
50
SIG SS7
SS7
30, 15, 7, 3, 2, 1
card NW
50
GSC-2
SC-2 NW
50 NOTICE-INDICATION Feedback
30, 15, 7, 3, 2, 1
Attach Rate fall-off based on congestion feedback
GSC-3
SC-3
MAPc Buffer Usage Feedback
2. Average 50 attach/sec/GSC 3. Total 90 attach/sec 4. SS7 link congested after 15

1. 150 attach/sec
GSC throttles at 30 attach/sec MAP throttles at 40 attach/sec min of high traffic
5. Notice Indication return to GSC
6. GSC throttles down to 7. Total 15 attach/sec

8. SS7 recovered from congestion
15 attach/sec No throttling is required
9. Notice Indication values within limits

GSC returns to normal
Throttle at 30 attach/sec if necessary
OAM for message overload controls

This section summarizes the OAM for the message overload controls feature.
Fault management
Each message overload control described in “Messages with overload
control” on page 4-29 has an associated Set/Clear alarm. For alarm
descriptions, see NTP 411-5221-500, SGSN Alarms Reference Manual.
Configuration management
On the FPs, component OverloadControl (OC) is added under the GSC, USC
and TCAP components. For descriptions of the provisionable attributes for
Overload Control component, see NTP 411-5221-060, SGSN Components
Reference Manual.
The overload criteria provisionable thresholds need to be set based on the

SGSN network configuration. This takes into account among other things the
number of GSC cards, number of SIG-SS7 links etc. The provisioning
recommendations for overload thresholds need to be provided by the systems
engineering team based on a customer’s target system configuration.

4-36 Reliability
Accounting management
No CAMEL information will be added to billing records for CAMEL calls
that receive overload handling.
Performance management
The following groups contain the operational attributes and collected
statistics related to message overload controls:
• ScOcOper, ScOcColl
• GscOcOper, GscOcColl
• TcapOcOper, TcapOcColl
For descriptions of these operational attributes and collected statistics, see
NTP 411-5221-060, SGSN Components Reference Manual.

It is possible for a GSC card switchover to occur when one or more message
overload alarms are active, i.e. some of the SMOCs on the active card may
have been operating at a message rate less than the max message rate and
greater than or equal to the minimum message rate for a given SMOC. Since
these message rates are not journaled to the standby card, it is not possible to
determine whether a message overload condition existed prior to the standby
card coming up. Therefore, in order not to impact the services in the “standby
become active” GSC card, all SMOC message rates are initialized to their
provisioned maximum message rates on the “standby become active” card
after a switchover has occurred. These maximum message rates will be
gradually decreased to the minimum rates upon detection of overload
conditions in the “standby become active” card (if any).
No CAMEL information will be added to billing records for CAMEL PDP-

Establishment or CAMEL PDP-Change Of Position Context requests that
receive overload handling.

5-1
Services and features 5

This chapter describes the following Nortel SGSN/GPRS services and features:
• Feature optionality
• Packet service domain mobility
• Seamless National Roaming (SNR)
• GPRS Short Message Service (SMS)
• GPRS Prepaid Short Message Service (SMS)
• CAMEL Phase 3
• PDP context modification
• Secondary PDP context activation
• QoS negotiation
• BSS Packet Flow Context
• SGSN downlink PDU buffering
• Lawful Interception (LI)
• End user security functions
• IP Header Compression
• MS Purge
For information about the parameters used to provision the services described
in this chapter, refer to NTP 411-5221-060, SGSN Components Reference
Manual. For procedures to provision the new PC04 features refer to NTP
411-5221-904, SGSN Provisioning Procedures.

5-2 Services and features
Feature optionality 5
The following is a list of product-supported optionality, i.e., capabilities in the
software that provide optionality opportunities. This is not to be confused
with sales and/or marketing options that are not related to a software function.
Table 5-1
Feature optionality
Feature Range Control

Mechanism
Maximum Attached Subscribers (per 1,000 – Usage SOC

shelf) 5,000,000
Packet service domain mobility 5

Routing area update (RAU)
The intra-SGSN Routing Area Update (RAU) is a mobile initiated procedure
used to inform the network that the mobile has entered a new routing area
(RA) or that a periodic RAU timer has expired. The SGSN’s mobility
context is updated. The HLR is not involved since the SGSN is unchanged.
The inter-SGSN RAU (IRAU) is also mobile initiated to inform the network
that the mobile has entered a new RA, although in this case, the new RA is
serviced by a different SGSN (new SGSN) than the previous RA’s SGSN (old
SGSN). The existing mobility and session contexts are moved from the old
SGSN to the new SGSN. The HLR is updated with the new serving SGSN
address. If a Packet Data Protocol (PDP) Context was activated, the GTP
tunnel between the old SGSN and GGSN is moved to the new SGSN. Data
Forwarding is the transfer of incoming Gn packets on the old SGSN to the
new SGSN during Inter-SGSN RAU.
Table 5-2 lists mobility event support.

Table 5-2
Mobility event support
Mobility Event Supported
Periodic RAU Yes
Intra-RAU Yes
Inter-RAU Yes
2G -> 3G Inter-RAU Yes
3G -> 2G Inter-RAU Yes
—sheet 1 of 2—

Table 5-2
Mobility event support (continued)
Mobility Event Supported
MM Context Exchanged Yes
PDP Context Exchanged Yes
No Re-attach Required Yes
No Re-activation Required Yes
Data Forwarding (Downlink direction Yes

only. Data buffering is not supported.)
—sheet 2 of 2—
Equivalent PLMN (ePLMN)

Equivalent PLMN (ePLMN) allows the mobile station to treat selected PLMNs
with different PLMN codes as equivalent to each other at PLMN selection,
handover, cell re-selection, etc. ePLMN is useful in several scenarios:
• Allows operators to share coverage zones
• In the initial deployment period, it offers each cooperating operator a
wider coverage area than what was achievable as a single operator
• Provides equivalency of PLMNs for operators with both a 2G and 3G
PLMN using different PLMN codes.
ePLMN is provided on a per SGSN basis. Each SGSN contains a list of
equivalent PLMNs.
Seamless National Roaming (SNR) 5

Seamless National Roaming (SNR) enables network operators to offer
seamless roaming to subscribers of partner operators. The transition between
PLMN coverage areas is transparent to the subscribers. Handover of PDP
contexts without interruption across PLMN boundaries is enabled by fast
PLMN selection through equivalent PLMN (ePLMN) support (see
“Equivalent PLMN (ePLMN)” on page 5-3).
To reduce the initial build-out cost of networks, providers often sign roaming
agreements with other in-country operators to share coverage areas. SNR
allows operators to reduce initial network build-out costs but still provide
large, country-wide coverage footprints.
Subscriber designation
With the introduction of SNR to the network, subscribers can now be
classified in several differing ways other than just being a Home subscriber or
a Roaming subscriber. Home subscribers are designated by the operator by

provisioning the appropriate IMSI range in the SGSN PlmnImsiRange

component on a GPRS system and the USGSN PlmnImsiEntry on the UMTS
system. All IMSIs matching this range would be considered home subscribers
where the rest were considered roamers. With SNR the operator has the
ability to further segregate and change the designation of subscribers in their
network based on location and IMSI. SNR can apply 4 different attributes to
an IMSI that attempts access to the SGSN at a particular location.
1. Equivalent Plmn List – provides a list of up to 5 equivalentPlmn that can

be sent back to a Release 99 mobile in the Attach Accept or RAU Accept
message for the mobile to perform retries to. This attribute applies
regardless of whether the subscriber is a Home or Roaming subscriber.
2. GMM Reject Cause – contains a GMM reject code to be sent back to any
subscriber (homer or roamer) if their IMSI matches a provisioned
IMSIMask and this attribute is provisioned.
3. SNR APN Operator Id OI – contains the APN Operator Id (OI) to be used
in APN selection if the mobile is a roamer as defined by the IMSI Range
not being provided in the SGSNPlmnImsiRange component or the
USGSN PlmnImsiEntry and if the VPLMN Access Allowed (VAA) flag
returned from the HLR is set to Y.
4. QOS Equivalency – contains the designation Homer or Roamer to allow
an operator to give certain subscribers the quality of service that it would
provide the operator’s own subscribers.
The above attributes can also be characterized by which mobiles the action
applies to, as shown in Table 5-3.
Table 5-3
Application of SNR attributes
Attribute Home subscriber Roaming subscriber
Equivalent Plmn List Applied Applied
GMM Reject Cause Applied Applied
SNR APN Operator Id Not applied Applied
QOS Equivalency Not applied Applied

SNR coverage area configuration example

In support of SNR, both Operator A and Operator B build unshared and
shared areas. The unshared coverage areas of Operator A serve subscribers of
Operator A and international roaming partners only.
Subscribers of Operator B are denied service in Operator A’s unshared area.

Operator B’s subscribers are allowed service in Operator A’s shared-coverage
areas and are, in some respects, treated as home subscribers in these areas (the
reverse scenario holds true for Operator B’s shared and un-shared coverage
areas).
Figure 5-1 depicts coverage areas owned by two network operators A and B.
Both operators have 2G and 3G spectrums (only the 2G network for Operator
B is shown). Both operators have shared and unshared areas, with roaming
agreements in place for the shared areas.
Figure 5-1
National roaming network
Operator A Unshared Area Operator A 3G Spectrum
RA-1 RA-2
RA-3 RA-4
Operator A Shared Area
Operator B 3G Allowed
Operator B 3G Restricted
Operator A 3G Allowed
Operator B Shared Area Operator A 3G Allowed
Operator A2G Restricted
Operator A 2G Restricted
Operator B 3G Spectrum
RA-2 RA-1
RA-4 RA-3
Operator B Unshared Area

Operator B 3G Allowed Operator B 3G Allowed
Operator B 2G Restricted Operator B 2G Restricted
Operator A 3G Allowed Operator A 3G Restricted
Operator A 2G Restricted Operator A 2G Restricted
Operator B 2G Spectrum
RA-1 RA-2 Operator B 3G Allowed

Operator B 2G Allowed
RA-3 Operator A 3G Restricted
Operator A 2G Restricted

Table 5-4 indicates possible roaming restrictions in place between Operators

A and B. This is only one possible implementation of roaming restrictions.
Nortel provides the network operator the ability to manage these restrictions
via provisioning data.
Table 5-4
Roaming restrictions
Operator Operator Operator A Operator Operator Operator B

A 2G A 3G 3G Network B 2G B 3G 3G
Network Network (Unshared) Network Network Network
(Shared) (Shared) (Unshared)
Operator A 2G Permitted Denied Denied Denied Denied Denied

Subscriber
Operator A 3G Permitted Permitted Permitted Denied Permitted Denied

Subscriber
Operator B 2G Denied Denied Denied Permitted Denied Denied

Subscriber
Operator B 3G Denied Permitted Denied Permitted Permitted Permitted

Subscriber
Equivalent PLMN list selection

The 3GPP standards define a “list of Equivalent PLMNs” that may be sent to
a MS in the Accept message upon a successful GPRS Attach or Routing Area
Update procedure. This list may contain up to 5 MCC+MNC pairs (as
required by the GSM 24.008 standards), each of which identifies a PLMN
that the MS is to treat as “equivalent” to the serving PLMN. This equivalency
allows the MS to perform a quicker cell reselection compared to the PLMN
search when performing Inter-PLMN mobility events. This results in less
interruption to the end-user, adding to the “Seamless” roaming concept.
SNR expands on this feature by providing ePLMN lists based upon the
subscriber’s IMSI and current location. Thus, subscribers from different
PLMNs could potentially receive different ePLMN lists when in the same
geographic region. Similarly, a subscriber’s ePLMN list may change based on
the subscriber’s location changes. SNR therefore expands the existing list of 5
MCC+MNC pairs from only 1 list into 200 lists. This is done while still
keeping the first element as the default SGSN Equivalent Plmn list in the case
that an SNR Equivalent Plmn has not been set or if SNR is not being used.
Figure 5-2 shows two network operators (A and B) in the same country
(mobile country code 101 selected at random). Both of the operators support
shared and unshared coverage areas, with roaming agreements between them

for access to the shared areas. The coverage areas are defined such that the
shared and unshared areas have different Mobile Network Codes (MNC)
(though they could use the same MNC if desired).
Figure 5-2
ePLMN list example
Shared Areas
Operator A Operator B
Unshared Areas
SGSN SGSN
Subscriber “A” ePLMN list
Not Allowed
Subscriber “B” ePLMN list
101/21, 101/78
RA 3
101/20
RA 4
RA 1 RA 2 101/21
101/78 101/79
Subscriber “A” ePLMN list Subscriber “A” ePLMN list Subscriber “A” ePLMN list
101/79, 101/21 101/78, 101/21 101/78, 101/79
Subscriber “B” ePLMN list Subscriber “B” ePLMN list Subscriber “B” ePLMN list
101/20, 101/21 Not Allowed 101/20, 101/78
The SGSN must have two pieces of information to format and send the correct
ePLMN list: the subscriber’s IMSI and current Routing Area. Taking Routing
Area 4 in Figure 5-2 as an example:
• Subscribers belonging to Operator A on Routing Area 4 are sent an
ePLMN list consisting of Routing Areas 1 and 2. Routing Area 3 is not
included since this is an unshared area serving Operator B exclusively.
• Subscribers belonging to Operator B on RA4 are sent an ePLMN list
consisting of RA3 (Operator B’s unshared area), along with RA1
(Operator A’s shared area).

Enhanced APN Selection

In the current UMTS and GPRS networks, the SGSN uses the VPLMN Address
Allowed (VAA) flag from a roaming subscriber’s HLR subscription data to
determine which APN to use for packet data service. The APN selection
algorithm works as follows:
• For home subscribers, the SGSN checks the subscribers’s VAA flag in the
HLR data. If “TRUE”, then it appends the default APN Operator
Identifier to the APN Network Identifier (NI) and performs a DNS look-
up to determine the GGSN address. If the VAA flag is “FALSE”, then
SGSN appends the subscriber’s MCC+MNC (from the IMSI) to the APN
NI and performs a DNS look up to determine the GGSN address. This
GGSN will be in the home network.
• For roamers, the SGSN checks the subscriber’s VAA flag in the HLR
data. If “TRUE”, then the subscriber is allowed to use the GGSN in the
visited network, so the SGSN appends the default APN OI and performs
the DNS look-up.
• If the roaming subscriber’s VAA flag is set to “FALSE”, then the roamer
must use the GGSN in the roamer’s home network. In this case, the SGSN
appends the subscriber’s MCC+MNC (from the IMSI) to the APN NI and
queries the DNS server for the IP address of the GGSN in the subscriber’s
home network
Seamless National Roaming enhances this functionality by allowing the

operator to determine which GGSN is used for roamers based upon the
subscriber’s IMSI and current location. In this scheme, if the VAA flag is set
then the network operator can allow certain roamers (say family-member
roamers or National Roaming partners) to use the visited GGSN, regardless
of what the HLR subscription data indicates. This provides functionality
similar to that of the VAA flag, but on a more granular (per-PLMN) basis.
Roaming restrictions
In support of Seamless National Roaming, the SGSN provides the ability to
the network operator to control network access based upon a subscriber’s
IMSI and current location.
The 3GPP standards support Regional Subscription, an HLR-based feature

which provides Location Area-based Roaming Restrictions on a per-
subscriber basis. In this scheme, the HLR contains a list of Zone Codes which
are downloaded to the SGSN/MSC during attach and update location events.
The SGSN/MSC is responsible for mapping the Zone Codes to a set of
Location Areas and permissions. Network operators, however, are reluctant to
rely on a foreign HLR to provide roaming restrictions within their network,
and so desire the ability to have the SGSN provide this type of functionality.

To support per-subscriber roaming restrictions, the SGSN must be

provisioned with an “exclusion list” of IMSIs or IMSI-ranges and applicable
rejection Cause Codes (from 24.008). These may be provisioned on a per-
Routing Area, per- Location Area, or on a per-PLMN basis within the SGSN.
When a subscriber whose IMSI is found in the exclusion list attempts to
access the network (via GPRS Attach or RAU), the network access attempt is
rejected with the Cause code associated with the subscriber’s IMSI in the
exclusion list. This rejection shall take place regardless if the mobile is
performing a GPRS or a Combined procedure.
Note that not all excluded IMSIs need to be added to the SGSN’s exclusion
list. For instance, an international roamer may attempt to get service, but is
rejected by the home HLR based upon PLMN access restrictions. In this case,
the access attempt is rejected based upon the Cause code returned from the
HLR. The SGSN-based exclusion list is of particular interest when providing
Seamless National Roaming since it gives the network operator the ability to
screen access attempts at the SGSN, and provide a specific reject Cause
Code. Figure 5-3 illustrates one potential configuration for provisioning
roaming restrictions on the SGSN. This illustration depicts a simple
implementation on the SGSN.
Figure 5-3
Roaming restrictions example
Shared Areas
Unshared Areas
SGSN
RA 2 Exclusion list
- 101/100, #12
- 034, #15
RA 1 RA 2
101/78 101/79
Subscribers from PLMN 101/100 are rejected by

the SGSN with Cause code #12
Any subscriber from Country #34 is rejected by

the SGSN with Cause code #15
All other subscribers are handled via normal HLR

messaging.

Quality of Service equivalence

Currently, the SGSN permits network operators to provision IMSIs (or IMSI
ranges) to identify home subscribers (“homers”). IMSIs not provisioned in
this table are considered roamers, and are handled accordingly for Billing
purposes. However, identifying homers on a per-SGSN basis does not fit
neatly into the “multi-PLMN” functionality supported on the SGSN. In other
words, operators may support multiple PLMNs on the same SGSN, but can
only define homers on a per-SGSN basis, not on a PLMN-basis.
In support of Seamless National Roaming, the SGSN is enhanced to support

the provisioning of homers on a per-Routing Area basis. This allows roaming
partners to be treated as homers in the “shared” coverage areas served by an
SGSN and receive QoS equivalent to what they would receive if they were in
their home network. This gives the “transparency” between the home
coverage areas and visited shared areas the network.
OAM
The following sections provide Operations, Administration, and Maintenance
(OAM) information for SNR.
CAS provisioning enables the operator to enter up to 200 EquivalentPlmn
components on the SGSN. Each of these EquivalentPlmn components can
contain a list up to 5 equivalent PLMNs. The operator can also provision up to
200 SubscriberClass components on the SGSN. Each subscriber class
component may be provisioned to provide these SNR services:
• Roaming Restrictions with provisionable cause codes
• A link to a provisioned Equivalent Plmn list
• New APN-OI to determine the GGSN to which the mobile can activate
• An Equivalent Quality of Service of homer or roamer
Once a Subscriber Class component has been provisioned, it can be linked to

an ImsiMask component. An ImsiMask can be provisioned on the PLMN
(MCC/MNC), LAC, or the RAC components. These ImsiMask components
consist of up to 15 digits or wildcards meant to be matched to mobiles’
IMSIs.
For information on the provisionable attributes for these components, refer to

NTP 411-5221-060, SGSN Components Reference Manual.

Error messages are given to the operator during entry of the provisioning
faults listed in Table 5-5.
Table 5-5
SNR provisioning fault messages
Fault Message
Add an EquivalentPlmn component Invalid syntax: {instance} unexpected, value must be

outside the 1 to 200 range. from 1 to 200.
Input: add (U)Sgsn EquivalentPlmn/{201}
Set a larger than 6 digit PLMN in the Invalid syntax: {list value} unexpected, too long (7),
EquivalentPlmn plmnList attribute. must be at most 6 long.
Input: set (U)Sgsn longMncMccs 12345 23456 56789

{1234567}
Set a smaller than 5 digit PLMN in the Invalid syntax: {list value} unexpected, too short (4),
EquivalentPlmn plmnList attribute. must be at least 5 nibbles long.
Input: set (U)Sgsn longMncMccs 12345 23456 56789

{1234}
Add a SubscriberClass component Invalid syntax: {instance} unexpected, value must be

outside of the 1 to 200 range. from 1 to 200.
Input: add (U)Sgsn SubscriberClass/{201}
Set the rejectCause attribute of the Invalid syntax: {attributeValue} unexpected, value must
SubscriberClass to a value outside of the be from 1 to 255 or one of the following named values:
1 to 255 range. disabled.
Input: set (U)Sgsn SubscriberClass/1 rejectCause {256}
Set the linkToEplmn attribute of the Sgsn SubscriberClass/1 Component (U)Sgsn

SubscriberClass to a non-existent EquivalentPlmn/5 does not exist.
EquivalentPlmn component.
Set the apnoi attribute of the Invalid syntax: {attributeValue} unexpected, string too
SubscriberClass to a string longer than 37 long.
characters.
Input: set (U)Sgsn SubscriberClass/1 apnoi
{1234567890123456789012345678901234567}8
—sheet 1 of 2—

Table 5-5
SNR provisioning fault messages
Fault Message
Set the qosEquivalency attribute of the Invalid syntax: {attributeValue} unexpected, invalid
SubscriberClass to a value other than enumeration value.
“homer” or “roamer”.
Input: set (U)Sgsn SubscriberClass qosEquivalency
{gomer}
Add an imsiMask component mask Invalid syntax:{instance}unexpected, too long (17),

instance that is more than 15 digits long. must be at most 15 long.
Input: add (U)Sgsn mcc/123 mnc/45 imsiMask/

{12345678901234567}
—sheet 2 of 2—
Check prov warnings and errors will be given to the operator for the faults
listed in Table 5-6.
Table 5-6
SNR provisioning warnings
Fault Response Text
Check prov warnings
Set rejectCause attribute of RejectCause OutOfSet Warning:

the SubscriberClass to a It is recommended that the cause code be
value not in the following one of the 3GPP 24.008 specification
snrCauseCodes set defined location or IMSI-based cause
{disabled, code.
7,8,11,12,13,14,15}.
Provision more than 200 ImsiMaskLi Warning:

imsiMask components on the mitPerSgsn Reason: Provisioning more than 200
(U)Sgsn. ‘ImsiMask’ components on the (U)Sgsn is
not supported. Reclaiming the memory
used requires deprovisioning the
ImsiMasks back to 200 followed by a card
reset for all ‘Gsc’ or ‘Usc’ component(s).
Check prov errors
—sheet 1 of 2—

Table 5-6
SNR provisioning warnings
Fault Response Text
Add EquivalentPlmn WlcPlmnListNotSet Error:

component without setting the Reason: 'plmnList' attribute has not been
PlmnList attribute. set. The 'EquivalentPlmn' component
must have at least one PLMN
provisioned.
Set more than 5 PLMNs in RejectCauseOutOfSet EquivalentPlmn/1 Error:

the EquivalentPlmn plmnList. Attribute: plmnList Reason: Too many
values (6) in list (max 5).
Add SubscriberClass WlcSubClass Error:

component without setting AttributeNotSet Reason: The attributes of the
any of its attributes. 'SubscriberClass' component have not
been set. At least one of the attribute
values must be set.
Set an snrApnOperatorId that WlcInvalidS Error:

is not of the proper format. nrApnOperatorId Reason: Invalid 'snrApnOperatorId' set.
Valid format is 'DNS-label.DNSlabel.
gprs'.
Check prov errors
Add an imsiMask with a WlcInvalidWildcards Error:

trailing wildcard, or add a Reason: Cannot provision wildcards to the
defaultMask with more than right of a mask or provision more than one
one wildcard. wildcard in the default mask.
Add an imsiMask without WlcLinkToSubscriberC Error:

setting linkToSubscriberClass lassNotSet Reason: The 'linkToSubscriberClass'
attribute. attribute has not been set or the
'SubscriberClass' component has been
deleted.
—sheet 2 of 2—

Accounting Management
Seamless National Roaming has no impact on SGSN-generated CDRs. Looking
at the major features that make up Seamless National Roaming:
• ePLMN list generation – no M-CDR impacts since this information is not
captured in the M-CDR.
• Roaming Restrictions – applies to denial of service based on SGSN
provisioning. Since M-CDRs are not generated for unsuccessful attaches,
SGSN Billing is unaffected.
• QoS Equivalency – allows selected subscribers to be treated as “homers”
in terms of QoS negotiation. The negotiation is performed on the GSC
card, and the Requested/Negotiated/Subscribed QoS profiles are simply
recorded in the S-CDR. This is existing functionality, so SGSN Billing is
unaffected.
• APN OI Selection – As with QoS negotiation, APN OI selection is
performed on the GSC and the APN OI merely recorded in the SCDR.
SGSN Billing is therefore unaffected. This is existing functionality, so
SGSN Billing is unaffected.
Performance Management
Real-time and historical statistics count the Attach and the Routing Area
Update procedures rejected due to roaming restrictions provisioned on the
SGSN. Mobiles that are Attaching and mobiles that are performing a RAU
that are roamers as well as those roamers receiving SNR homer equivalency
are also counted. These counters are added to the Gsc Gmm and Gsc Sm
subcomponents.
For counter descriptions, refer to NTP 411-5221-060, SGSN Components

Reference Manual.
Feature interactions and dependencies

SNR has the following interactions and dependencies with other SGSN
features:
• SNR changes the structure of the Equivalent PLMN component which
was added from the Release 99 requirements. However, the existing
functionality of the Default EquivalentPLMN remains intact across the
SGSN. The entry at index 1 serves as the default EquivalentPLMN.
• SRNS (Serving Radio Network Subsystem) Relocation complements
SNR in delivering true seamless capabilities; however, SNR and SRNS
are not dependent on one another. SNR functionality is SGSN-based and
is oriented towards enhancing call connectivity, while SRNS Relocation
is RNC-based and oriented toward enhancing packet flow during call
handovers.
• The CAMEL feature takes precedence over SNR in APN selection since
it is an AIN service.


No restrictions have been identified for SNR.
The following limitations have been identified for SNR:

• The operator is issued a check prov warning if the number of IMSI masks
provisioned is more than 200. However, the operator is not prevented
from provisioning more than 200 masks. If an operator exceeds the 200
IMSIMASKs and an upgrade is required, the operator must bring the
number of IMSIMASKs to 200 or below to ensure an upgrade will be
successful. The system is engineered to support 200 IMSIMASKs.
Results will be indeterminate if the 200 IMSIMASK limit is exceeded.
• The designation of Homer quality of service on a GPRS system only has
the impact of pegging the appropriate SNR Operational measurements.
Currently there is no differentiation of the quality of service provided to a
roamer or homer on the SGSN.
• The QoS designation of the mobile when activated will remain the same
through the time of the activation. If a RAU event occurs and the
provisioning had changed the snrCurrentlyActivated, snrPeakActivated
and snrActivatesSuccessful will not be changed. Only an activate event
will cause these counters to be pegged.
GPRS Short Message Service (SMS) 5

The SGSN/GPRS supports transport of Mobile Originated and Mobile
Terminated Short Message Service (SMS) messages over the GPRS network.
The Gd interface (described in “Gd interface” on page 1-10) is the signaling

link that provides point-to-point short message service message transfers
between the SGSN and SMS-GMSC/SMS-IWMSC.
Nortel Network’s Gd architecture consists of two separate interfaces, Gd and

Gd'. The Gd interface handles short message functionality between the SS7/
IP Gateway (SIG) and the GSM SMS-GMSC/SMS-IWMSC. The Gd'
interface, a Nortel proprietary interface, handles short message functionality
between the SGSN and the SIG.
The SIG provides support for connectivity with multiple SMS-GMSC/SMS-

IWMSCs. Global Title Translations is used to determine to which SMS-
GMSC/SMS-IWMSC a specific message is routed.
Supported MAP versions

MAPv3 and MAPv2 messages are supported. When MAPv3 is used between
the HLR and SMS-GMSC/SMS-IWMSC, the choice between GSM or GPRS
as the transmission path is made at the SMS-GMSC/SMS-IWMSC. Both the
SGSN E164 number and the MSC E164 number are returned to the SMS-
GMSC/SMS-IWMSC. This information can be used to forward a short

message to a class B or Class A mobile if the mobile is both GSM and GPRS
attached.
When MAPv2 is used between the HLR and SMS-GMSC/SMS-IWMSC, the

choice between GSM or GPRS as the transmission path for SMS is made at
the HLR. This is because with MAPv2, the “Send Routing Information for
SM” is defined to contain only one address. This information is used to
forward a short message to a class B or A mobile if the mobile is both GPRS
and GSM attached.
GPRS SMS network structure

The GPRS SMS network structure, which includes the Gd and Gd' interfaces,
is shown in Figure 5-4.
Figure 5-4
GPRS SMS network structure
MS
SGSN
SMS-GMSC/
MAPC
SIG
SC SMS-IWMSC SMS BSS
Legend
Gd
Gd’ & Gr’
HLR Gr
The GPRS SMS network elements are

• SGSN: Communicates with the SIG over the Gd' interface for transferring
SMS messages. The following applications on the SGSN are responsible
for implementing SMS functionality:

— SMS Entity: a control interface responsible for retrieving and

processing limited sized short message service messages between a
Mobile Station and a Service Center. The SMS Entity interfaces with
the HLRC to access a mobile subscriber’s subscription information
within the SGSN, such as SMS teleservice, Mobile Originated ODB
(BAOC) restriction, and location confirmed in HLR indicator flag.
The SMS Entity interacts with GMM to obtain a mobile subscriber’s
IMSI, MS Network Capability, and GSD relevant information for a
specific mobile subscriber.
— MAP Client: a protocol interface responsible for sending MAP
messages to the SMS-IWMSC/SMS-GMSC and the HLR through the
SS7/IP Gateway (see “Gr interface” on page 1-13). The MAP Client
also interfaces with the HLRC to store Short Message Service
subscription information received from the HLR.
• Service Center (SC): responsible for relaying and storing-and-
forwarding short messages between a MS and SME (Short Message
Entity). A SME is an entity that either sends or receives short messages.
• Short Message Service-Gateway MSC and Short Message Service-
InterWorking MSC (SMS-GMSC/SMS-IWMSC): responsible for
connecting to the SGSN through the Gd interface to enable the GPRS
MSs to send and receive short messages over GPRS radio channels.
• SS7 IP Gateway (SIG): responsible for the SS7 and IP interworking
functions between SGSN and HLR, as well as SGSN and SMS-GMSC/
SMS-IWMSC.
SMS external interfaces

This section describes the interaction between the SGSN components that
provide SMS functionality and other SGSN components. For more
information about these components, see Chapter 2, “Functional description”.
SMS entity
The SMS entity interacts with the following SGSN components:
• HLRC—SMS Entity interfaces with HLRC to access a mobile
subscriber’s subscription information within the SGSN, such as SMS
teleservice, Mobile Originated ODB restrictions, and location confirmed
in HLR indicator flag.
• LLC—The LLC layer is modified to support SMS. SMS Entity utilizes
the unacknowledged mode of LLC frame transfer, and SAPI 7 to identify
the SMS Logical Link Entity within the LLC layer.
• GMM—SMS Entity interacts with GMM to obtain a mobile subscriber’s
IMSI, MS Network Capability, MS state information and GSD relevant
information for a specific mobile subscriber.

MAP client
The MAP client interacts with the following SGSN components:
• MAP stack—MAP Client interfaces with the MAP stack on the SGSN to
relay short message service MAP messages to/from the IWMSC/GMSC
and the HLR.
• HLRC—MAP Client interfaces with HLRC to store Short Message
Service subscription information received from the HLR
Gd' SMS procedures

The following SMS procedures are supported for the Gd' interface:
• Short Message Mobile Originated Transfer
• Short Message Mobile Terminated Transfer
• Short Message Multiple Mobile Terminated Transfer
• Short Message Alert - Mobile Subscriber Reachable
• Short Message Alert - Memory Available Notification

For the SMS Entity, the following restrictions apply:
• The SMS Entity processes up to 8 concurrent short message transfers per
MS.
For the Map Client, the following restrictions apply:

• GSC software must be updated to support the new Gr interface.
• Gd' functionality must use the SIG4.0 SIG software release.
GPRS Prepaid Short Message Service (SMS) 5

GPRS Prepaid SMS is an extension of GPRS SMS that incorporates prepaid
messaging services. An external entity, the Service Control Point (SCP), is
required for GPRS Prepaid SMS to manage and authorize Prepaid SMS
subscriber messaging. GPRS Prepaid SMS supports only mobile originated
prepaid messaging.
Service Control Point

The SCP is an external entity that manages a Prepaid SMS subscriber’s
account. The SCP supports requests to increment, decrement, recharge, and
query a subscriber’s account balance.
The SCP consists of a duplex pair of Service Processors (SP), one of which is
the active SP and the other is the stand-by SP. Failure of the active SP causes
the stand-by SP to take over.

Multiple SCPs may be deployed, using a load-balancing scheme, in order to

support large numbers of prepaid subscribers. This load-balancing scheme
requires that each subscriber be assigned a specific SCP for all of that
subscriber’s transactions.
GPRS Prepaid SMS network structure

The network structure for GPRS Prepaid SMS (see Figure 5-5) is similar to
SMS, with the addition of the SCP(s).
Figure 5-5
GPRS SMS Prepaid network structure
MS
SGSN
SMS-GMSC/
MAPC
SIG
SC SMS BSS
SMS-IWMSC
SCP
Legend
Gd
HLR
Gd’ & Gr’
Gr

Messaging protocols
Communication between the SGSN and the SCPs is based on TCP/IP. Two
other protocols, the Network Connection Control Protocol (NCCP) and
Prepaid-CTP, are layered above the TCP layer as shown in Figure 5-6.
Figure 5-6
Message protocol stack for GPRS Prepaid SMS
SCP SGSN/GSC
Prepaid-CTP Prepaid-CTP
NCCP NCCP
TCP TCP
IP IP
Prepaid-CTP - Prepaid Card NCCP - Network Connection Control

Telephony Protocol Protocol
The Network Connection Control Protocol (NCCP) defines the base structure
of the messages and the procedures that govern how these messages are used.
This protocol manages the TCP socket connection between the SCP and its
client (in this case, the SGSN), handles client login to and logout from the
SCP, maintains the link via heartbeat messages, and releases the connection
when a logout is requested or errors are detected.
The Prepaid Card Telephony Protocol (Prepaid-CTP) is the application-level

protocol. It defines the structure of the application messages and the
procedures that govern how these messages are used. Application-level
messages are used to increment, decrement, recharge, and query a
subscriber’s account balance.
Note that the protocols used between the SCP and its clients are not robust.
Hardware or software failures on either side (including SP take-over) as well
as network congestion on the link between the SCP and its client may cause

transactions in progress to be lost and the subscriber may be incorrectly

charged for these lost transactions.
Provisioning
The following sections contain information about provisioning GPRS Prepaid
SMS.
Subscriber identification
A Prepaid SMS subscriber is identified by a service provider defined Access
Point Name (APN) in the subscriber’s record stored on the HLR. This APN is
used to identify the specific SCP on which all transactions for this subscriber
must be sent. Datafill on the SGSN associates each prepaid APN with a
specific SCP.
For a Prepaid SMS subscriber, the service provider must ensure the following:
• The subscriber is provisioned on exactly one SCP.
• The SGSN is provisioned to communicate with that subscriber’s SCP (as
described above). The SGSN provisioning includes defining a unique
APN that is used to identify this SCP.
• The subscriber’s record on the HLR contains the APN as defined above.
Note: It is highly recommended that the service provider provision the
subscriber on the SCP and that the communication link to this SCP has
been provisioned on the SGSN before the subscriber is entered into the
HLR. Otherwise, if the subscriber’s mobile performs an attach before the
SGSN becomes aware of this particular SCP, the subscriber will be denied
prepaid messaging service until the mobile detaches and subsequently re-
attaches.
SGSN provisioning
Once the SGSN receives provisioning for an SCP to communicate with, it
attempts to establish a TCP connection with and login to the active SCP. This
connection establishment may be delayed pending resource availability and
any transactions destined for this SCP are denied until communication has
been successfully established.
If the provisioning for an SCP is deleted, pending transactions will complete

before the connection is torn down.
Finally, if the provisioning for an SCP changes, the changes may require the
connection to be closed and re-established. Pending transactions will be
completed, but subsequent transactions may be denied until communication is
re-established.

Prepaid Short Message Mobile Originated Transfer procedure

The Prepaid Short Message Mobile Originated transfer procedure transfers
short messages submitted by the Mobile Subscriber (MS) to SME (Short
Message Entity) via a SC, and provides information about the delivery of the
short message, either by a deliver report or a failure report.
A mobile originated transfer is initiated when the mobile subscriber sends a

short message to the SGSN via a CP-Data message. The SGSN then
determines if the mobile subscriber is a Prepaid SMS customer. This is
accomplished by comparing each of the APNs in the subscriber’s record to
the list of APNs associated with each SCP provisioned on the SGSN. If a
match is found, the subscriber is identified as a Prepaid SMS customer and is
so denoted in the subscriber’s subscription data on the SGSN.
If the MS is not a Prepaid SMS subscriber, verification continues.
If the MS is a Prepaid SMS subscriber, the SGSN sends a decrement request

to the specific SCP (as identified earlier by the APN contained in the
subscriber record). If the response from the SCP indicates that the subscriber
has a sufficient balance to send the message, the SGSN relays the short
message to the SIG via the MAP Client interface.
The SIG then relays the short message to the SMS-IWMSC. The SMS-
IWMSC transfers the short message to the SC. Once the SC completes the
transaction, it relays information about the delivery of the short message to
the SMS-IWMSC.
The SMS-IWMSC relays the delivery information to the SIG. The SIG then
relays the delivery information to the SGSN, via the MAP Client Interface.
Finally, the SGSN relays the delivery information to the MS.

The following restrictions and limitations apply to GPRS Prepaid SMS:
• The SGSN supports only prepaid Mobile Originated short message
transfer
• The SGSN supports only the authorization of prepaid messaging. No
support is provided for querying or recharging a subscriber’s prepaid
account balance.
• The SGSN supports prepaid SMS service for only one GSC card per
shelf. No support is provided for prepaid SMS service if there are multiple
GSC cards in the shelf.

CAMEL Phase 3 5
Customized Application for Mobile network Enhanced Logic (CAMEL)
Phase 3 offers service providers the ability to implement an Intelligent
Network (IN) solution that functions as part of a GPRS and/or Universal
Mobile Telephone System (UMTS) network. CAMEL is a network feature
that provides the mechanisms to support services that are not covered by
standard GSM services. CAMEL enables the use of Operator Specific
Services (OSS) by a subscriber even when roaming outside the HPLMN.
CAMEL Phase 3 introduces IN to GPRS and UMTS networks, allowing not

only voice, but also data access to trigger IN events. CAMEL 3 implements
the SCP, as well as functional elements new to the GPRS network.
A key business driver for CAMEL PHASE 3 is the prepaid account service,
allowing service providers to charge mobile subscribers in real-time for usage
of the network. CAMEL PHASE 3 provides the Camel Application Part
(CAP) protocol required for communicating between IN nodes - the Serving
GPRS Service Node (SGSN) and the Service Control Point (SCP). Figure 5-7
shows the Nortel GPRS network with corresponding IN nodes.

Figure 5-7
Nortel IN network architecture
The CAMEL PHASE 3 procedures allow pre-paid services to be supported

on a GPRS Session (Attach/Detach) basis, or on an individual PDP Context
basis. When pre-paid is supported on a GPRS session basis, the SCP is
notified whenever a pre-paid subscriber attaches to the GPRS/UMTS
network. Note that pre-paid on a GPRS Session basis is not supported in the
Nortel GPRS network. The second method of supporting pre-paid service is
on an individual PDP Context basis. This functionality is supported in the
first release of Camel3 pre-paid in the Nortel Network’s GPRS network.
The 3GPP Standards allow for both single and multiple component TCAP
messaging over the Ge interface between the CAMEL SSF (the CAMEL
entity residing on the SGSN) and the SCP, but the 3GPP standards,
(specifically 23.078 and 29.078) do not indicate a preference or that this
scenario is not supported.
This feature allows the SGSN to accept and accurately interpret all
components of TCAP messages received from the SCP and provides for more
efficient use of network resources. With this ability, the CAMEL Phase III
feature works with most SCP manufacturers.

Functional components
Components required for CAMEL Phase 3 include the SGSN and Service
Switching Function (SSF), the SIG, the SCP and the HLR.
SGSN
The SGSN has the following functionality for CAMEL Phase 3 support:
• The SSF component on the SGSN and support for the CAP protocol
enables the SGSN to communicate with the SCP.
• GPRS CAMEL Subscriber Information (G-CSI), data stored on HLRs,
allows the SGSN to decide which subscribers are CAMEL-enabled, when
to communicate with the SCP, and how to communicate with the SCP.
• CAMEL Detection Points (DP), a mechanism on the SGSN, allows the
triggering of DPs on the SGSN to indicate when the SCP needs to be
contacted.
• CAMEL Applied Charging. Upon request from an SCP, the SGSN places
limitations on the subscriber’s data connection. The limitations can be on
data volume or elapsed time.
• Free Format Billing. Upon request from an SCP, the SGSN stores billing
data in the SCP’s own format (free format) for the subscribers S-CDRs.
SIG
To support CAMEL 3, the SIG handles communication between the SGSN
and the SCP – the Ge interface. The Ge interface allows CAP/TCAP
messages to be transported between the SGSN and SCP in a similar fashion
as MAP messages are between the SGSN and HLR. The SIG supports a
Subsystem and Global Title (GT) for the Ge interface to the SCP, for the
SCCP and MTP communication. The Subsystem Number (SSN) of the SCP
is provisioned on the SIG and SGSN. The GT of the SCP is supplied to the
SIG by the SGSN.
SSF
The CAMEL 3 SSF is the SGSN component that handles the communication
with a SCP. It is primarily responsible for maintaining the state in the
dialogue with the SCP by using a state machine. The SSF is informed of any
potential Detection Points (DP) on the SGSN; the SSF then checks if the DP
is armed and allows the SCP to control the progress of the data call if it is.
The SSF also handles the GPRS dialogue with the SCP, which includes
encoding/decoding as well as validating of CAP messages to/from ASN.1
format.
The SSF can handle multiple-component TCAP messages from the SCP, up
to a maximum of five components per TCAP message.
Refer to “OSI states” on page 6-6 for SSF component state information.

Triggers
Two kinds of triggers are supported by the SSF: Trigger Detection Point
(TDP) and Event Detection Point (EDP). The TDPs are provisioned in the G-
CSI on the HLR. These triggers are statically armed and can only be disarmed
by changing the G-CSI on the HLR. The EDPs are dynamically armed by the
SCP and can be dynamically disarmed by the SCP. EDPs can either be EDP-R
(Request) or EDP-N (Notification); both types are supported by SSF. Each
trigger that occurs causes a state change.
Table 5-7 describes the supported CAMEL triggers.

Table 5-7
CAMEL triggers
Trigger type Trigger name Description
TDP-R PDP Context When the SSF on the SGSN detects a TDP, the SSF
Establishment checks if the TDP is armed. If it is not armed, the SSF
ignores the TDP and allows the PDP context to continue
Change of Position as normal.
PDP Context If it is armed, the SSF creates a new GPRS dialogue,
sends an InitialDPGRPS CAP message to the SCP, and
goes from the Idle state to the Waiting for Instructions state
to wait for more instructions from the SCP.
EDP-R PDP Context When the SSF on the SGSN detects an EDP, the SSF
Establishment checks if the EDP is armed. If it is not armed, the SSF
Acknowledgement ignores the EDP and allows the PDP context to continue
as normal.
PDP Context If it is armed, and is armed as an EDP-R, the SSF sends
Disconnection an EventReportGPRS CAP message to the SCP and
transitions from either the Monitoring state or the Waiting
for Instructions state to the Waiting for Instructions state to
wait for more instructions from the SCP.
EDP-N PDP Context When the SSF on the SGSN detects an EDP, the SSF
Establishment checks if the EDP is armed. If it is not armed, the SSF
Acknowledgement ignores the EDP and allows the PDP context to continue
as normal.
PDP Context If it is armed, and is armed as an EDP-N, the SSF sends
Disconnection an EventReportGPRS CAP message to the SCP and
resumes processing of the PDP context without waiting for
a response from the SCP. The state machine stays in the
Monitoring state or stays in the Waiting for Instructions
state if it is already there from a previous TDP/EDP-R. The
SCP is just “notified” of the event, but normal SGSN
processing resumes instead of waiting for more
instructions from the SCP.

PDP Context support

The following sections describe CAMEL Phase 3 functionality for Inter-
SGSN RAU and PDP Context Activation and Deactivation.
Inter-SGSN RAU
Inter-SGSN RAU (IRAU) from the old SGSN to the new SGSN triggers
CAMEL support when the MS is notified of the RAU being accepted. If the
corresponding Change of Position PDP Context TDP is armed, CAMEL
support ends on the old SGSN and begins on the new SGSN.
When an IRAU Request message with an old Routing Area Identifier (RAI)
is sent to the SGSN from the MS, and the SGSN does not have an active
mobility context for the IMSI, the SGSN is considered the “new SGSN” and
the context information needs to be retrieved from the “old SGSN” in order to
allow the mobile to remain active on this new SGSN.
When the RAU is accepted by the SGSN and the MS is notified, the SSF on
the SGSN then checks whether the subscriber is enabled for CAMEL support
and the associated Change of Position PDP Context TDP is armed.
If SSF determines that the subscriber is enabled for CAMEL support and the
TDP is armed, the SSF then begins a new dialogue with the SCP as though a
new PDP Context had begun for this subscriber. Otherwise, if the subscriber
is enabled for CAMEL support but the TDP is not armed, the SSF does not
begin a new dialogue with the SCP and takes the GPRS Default Handling as
provisioned in the G-CSI on the HLR.
When context information is requested on the old SGSN by the new SGSN,
the old SGSN returns the context information to the new SGSN and
terminates the current context.
Once the context information has been sent by the old SGSN to the new
SGSN, and the old SGSN terminates the context, the SSF is then notified that
the PDP Context has been deactivated. The SSF informs the SCP of the event
and the GPRS dialogue ends.
PDP context activation

The purpose of this procedure is to activate a PDP context, which contains
information required to transmit GPRS/UMTS data between the MS and the
Public Data Network. This activation procedure is initiated by an MS with a
mobility context already established in the SGSN.
When the MS initiates a PDP context activation to the SGSN, the SSF checks
whether CAMEL support is enabled for the corresponding IMSI. If CAMEL
support is enabled, the SSF then begins a new dialogue with the SCP for the
new PDP Context.

When the SGSN has determined which GGSN needs to be used, the SGSN
requests the GGSN to establish a new data connection for the PDP context.
The GGSN allocates a dynamic PDP address for the PDP context to be
activated and responds to the SGSN indicating the GGSN address and
Charging ID for the PDP context.
If the PDP Context Establishment Acknowledgement EDP has been armed by

the SCP, the SGSN may then send the GGSN address and Charging ID to the
SCP using the Event Report GPRS CAP message.
Table 5-8 lists abnormal cases for PDP Context Activation.

Table 5-8
Abnormal cases for PDP Context Activation
Error case Solution
The SGSN cannot determine the APN The SGSN rejects the PDP context
based on the APN selection rules. activation by sending an Activate PDP
Context Reject message to the MS.
Also the SSF is notified of this event.
The SGSN receives a Create PDP The SGSN rejects the PDP context
Context Response message from the activation by sending an Activate PDP
GGSN with the cause parameter Context Reject message to the MS.
indicating an error. Also the SSF is notified of this event.
The SGSN does not receive a Create The SGSN rejects the PDP context
PDP Context Response message from activation by sending an Activate PDP
the GGSN. Context Reject message to the MS.
Also the SSF is notified of this event.
Secondary PDP context activation

The optional parameter SecondaryPdp-context in the InitialDpGprs message
is used to indicate a secondary PDP context activation. The SGSN SSF
component sends the InitialDpGprs message to the gsmScf with the
secondaryPdp-context parameter included during the activate secondary PDP
context procedure.
PDP context deactivation

The purpose of this procedure is to deactivate an existing PDP context
between the MS and the network. The deactivation procedure can only be
performed when a mobility context has been established between the MS and
the SGSN.

When a Deactivate PDP Context is requested on the SGSN, and the

corresponding PDP Context Disconnection EDP is armed on the SGSN, the
SSF reports the event to the SCP and either terminates the GPRS dialogue
(EDP-N) or waits for a response from the SCP (EDP-R).
During MS-initiated procedure, the MS informs the network that it does not
want access to the SGSN-based services. All PDP contexts for the MS are
torn down.
MS-initiated PDP Context Deactivation can occur in one of the cases :

• MS-initiated Detach Procedure – This procedure is invoked by the MS if
the MS is powered off, the SIM card is removed from the MS or if the
GPRS/UMTS capability of the MS is disabled.
• MS-initiated PDP Context Deactivation – This procedure is invoked by
the MS.
During Network-initiated procedure, the Network (SGSN/GGSN/SCP/HLR)

informs the MS that it does not have access to the SGSN-based services any
more. All PDP contexts for the MS are torn down.
Network-initiated PDP Context Deactivation can occur in one of the cases :

• SGSN-initiated Detach procedure – This procedure is invoked by the
SGSN to detach the IMSI for GPRS services.
• HLR-initiated Detach procedure – This procedure is invoked by the HLR
when the HLR sends a Cancel Location message to the SGSN.
• SGSN-initiated PDP Context Deactivation – This procedure is invoked by
the SGSN when it receives a Delete Subscriber Data message from HLR.
• GGSN-initiated PDP Context Deactivation – This procedure is invoked
by the GGSN.
• SCP-initiated – This procedure is invoked by the SCP when the SCP
decides to tear down a PDP Context using ReleaseGPRS message.

Table 5-9 lists abnormal cases for PDP Context Deactivation.

Table 5-9
Abnormal cases for PDP Context Deactivation
Error case Solution
The SGSN receives a Detach Request Both procedures are considered

message with “power off” indicated, complete.
before the SGSN initiated GPRS
detach procedure is completed.
The SGSN receives a Detach Request The SGSN sends a Detach Accept
message without “power off” indicated, message to the MS.
before the SGSN initiated GPRS
detach procedure has been completed.
The SGSN receives a Routing Area The detach procedure is progressed

Update Request message before the and the RAU request is ignored.
SGSN initiated GPRS detach
procedure has been completed.

Billing and charging

The following sections describe CAMEL Phase 3 billing and charging
functionality.
Charging ID and GGSN Address

During PDP Context Activation, the Charging ID and GGSN Address
parameters from the GGSN would not be available to the SCP until after the
PDP Context has been created on the GGSN successfully. Therefore, these
parameters may only be sent after receiving Create PDP Context Response
from the GGSN. In order for the SCP to receive these parameters, it is
necessary to trigger the PDP Context Establishment DP. Whereas for IRAU,
the parameters would be present, and therefore may be sent initially during
IRAU Event.
Apply Charging
To support the pre-paid service, the SGSN must support the CAMEL 3
Charging procedures.
The SCP has the ability to send both a traffic volume threshold and a PDP
Context duration threshold to the SGSN. The data volume threshold indicates
the total volume (combined uplink and downlink) the PDP Context may
transfer before the SCP must be notified. Similarly, the duration threshold
indicates how long the PDP Context may be active before the SCP must be
notified. The SCP may optionally arm a TariffSwitch interval parameter. This
parameter represents the time in seconds until tariff switch.
The SGSN is responsible for monitoring both the traffic volume and duration
thresholds for the PDP Context. When a threshold is reached, the SGSN
notifies the SCP, clears its count (volume and/or duration) and continues. The
SCP can either tear down the PDP Context or let it continue with new
thresholds. If the SCP tries to tear down the PDP Context, the SCP-initiated
PDP Context Deactivation Procedure is invoked.
The SCP may combine data volume threshold requests with time duration
threshold requests. In the case of combining these two requests, the SCP is
required to send 2 ApplyChargingGPRS request messages, and the SGSN is
required to respond with 2 ApplyChargingReportGPRS messages. In both
cases, the data volume threshold request/report is always sent before the time
duration threshold request/report.
Data volume thresholds

The SCP requests the SGSN to monitor data volume for a PDP Context using
the ApplyChargingGPRS CAP message. The requested data volume
thresholds are then applied on the SGSN.

Once the data volume threshold is applied, the SGSN continues monitoring
the PDP context volume until either the PDP Context is ended, or the data
volume threshold is reached.
When the data volume threshold is reached, the SGSN notifies the SCP using
the ApplyChargingReportGPRS CAP message. The SCP may respond with
either another ApplyChargingGPRS request, or may end the GPRS dialogue
using the ReleaseGPRS CAP message. The SGSN continues monitoring the
volume while waiting for a response from the SCP. If the SCP responds with
another ApplyChargingGPRS request, the SGSN resumes the monitoring of
the volume using the new threshold from the point that the previous
ApplyChargingReportGPRS CAP message was sent.
The ApplyChargingReportGPRS CAP message contains the actual data

volume amount counted since the beginning of the PDP context.
Time duration thresholds

The SCP requests the SGSN to monitor the elapsed time of a PDP Context
using the ApplyChargingGPRS CAP message. Time duration timers are
created on the SGSN.
Once the time duration timer has been set up, the timer is monitored until
either the PDP Context is ended, or the timer expires.
When the timer expires, the SGSN notifies the SCP using the
ApplyChargingReportGPRS CAP message. The SCP may respond with
either another ApplyChargingGPRS request, or may end the GPRS dialogue
using the ReleaseGPRS CAP message. If the SCP responds with another
ApplyChargingGPRS request, the SGSN resumes the monitoring of the
elapsed time using the new threshold from the point that the previous
ApplyChargingReportGPRS CAP message was sent.
The ApplyChargingReportGPRS CAP message contains the actual elapsed

time since the beginning of the PDP context.
TariffSwitch Interval
The SCP optionally requests the SGSN to start a tariffSwitch timer for a PDP
Context, using the ApplyChargingGPRS CAP message Upon receipt of this
parameter, the SGSN “immediately” starts a TariffSwitch timer (Tsw) for the
specified interval, for the given PDP context.
The SGSN monitors the PDP context TariffSwitch timer expiry. When a
TariffSwitch timer expiry is detected, the SGSN collects the interim volume
and/or duration counts for the PDP context, and stores them. When a time
and/or volume threshold is reached, the SGSN notifies the SCP via an
ApplyChargingReportGPRS message, which optionally contains
TariffSwitch information.

Furnished Charging Information

The SCP is able to send charging information to the SGSN in the form of the
Furnish Charging Information (FCI) GPRS CAP message.
The FCI GPRS CAP message may be sent by the SCP to the SGSN at any
point during an established PDP context. The SCP may also send multiple
FCI GPRS CAP messages during a PDP context. Multiple FCI GPRS CAP
messages may either append further free format data to, or replace, existing
data on the SGSN. FCIs sent prior to the PDP context being established on the
SGSN will not be included in the S-CDR as the S-CDR is not created on the
SGSN until the PDP context is established.
As the SGSN receives FCI GPRS requests from the SCP, the SGSN stores the
free format data with the existing S-CDR data to be sent to the downstream
billing system. Once a PDP context is completed, the SGSN sends the S-CDR
to the billing system.
Free Format Data

The free format data received from the SCP in the Furnish Charging
Information (FCI) GPRS CAP message is an octet string containing charging
or billing details as formatted by the SCP.
It is the responsibility of the service provider to ensure that the free format
data supplied by the SCP is formatted suitably for the downstream billing
system to process correctly. The SGSN simply receives and stores the free
format data from the SCP and sends it to the billing system at the end of the
PDP context.
S-CDR enhancements
The CAMEL Information is a Conditional field in the S-CDR. It is included if
the subscriber is CAMEL-enabled in the G-CSI data. The individual fields
making up the CAMEL Information are optional, which means each field
does not need to be included in all CDRs. This is particularly useful when
generating partial records. For instance, the first record generated for a PDP
Context may contain the Free Format Data and FFD Append Indicator fields.
However, subsequent partial records for this PDP Context would not need to
contain this information, thus saving space in both volatile (RAM) and non-
volatile (disk) storage on the SGSN.
Excluding the Free Format Data and FFD Append Indicator fields, all of the
CAMEL Information is not stored in the S-CDR until prior to the PDP
context being disconnected. If the CAMEL dialogue does not perform any
Apply Charging (see “Apply Charging” on page 5-31) and does not arm the
Disconnect EDP (see “Triggers” on page 5-26), then CAMEL will not be
involved in the Deactivation procedure and CAMEL Billing Information will
not be included in the S-CDR.

For a description of the S-CDR CAMEL Information fields, see NTP 411-
5221-204, SGSN Call Detail Records (CDRs).
Node failure processing and CAMEL

The CAMEL 3 feature on the SGSN is affected by failures of other functional
failures of these other processors and nodes on CAMEL 3 are described
below.
Refer to “Redundancy capabilities” on page 4-1 for information about

redundancy and SGSN components.
GGSN
For a GGSN failure, the PDP Contexts in the GGSN are lost. The GSC
detects the GGSN outage via the Path Management functionality. When a
mobile station with a PDP Context on the failed GGSN next communicates
with the SGSN (either uplink bearer or signaling messaging), the GSC
deactivates the PDP Context. The deactivation causes the GPRS dialogue
with the SCP to be terminated.
HLR
For an HLR failure, the Mobility Contexts in the SGSN are marked as
inactive while the HLR restarts. Existing PDP Contexts and GPRS Dialogues
with the SCP are allowed to continue on the SGSN. When the next attach or
IRAU occurs on the SGSN, the SGSN sends the usual Update GPRS
Location MAP message to the HLR. If the HLR is still inactive, the SGSN
will not be able to proceed and will not allow the attach or IRAU to occur. In
this case, existing PDP contexts and GPRS Dialogues for the roaming MS
will be ended.
SGSN
Failure of the SGSN shelf as a whole results in the loss of all open GPRS
dialogues. Since the dialogues are stored in volatile memory until closure
(when they are moved to disk), there is no mechanism for recovering the
GPRS dialogues.
GSC
When a GSC card fails, all sessions and mobility contexts hosted by the GSC
are discarded. Similarly, all existing CAMEL Dialogues are also lost, which
is the desired operation since the PDP Context no longer exists.
Due to the GSC card failure, the SGSN cannot report the termination of the
PDP Contexts or the CAMEL Dialogues to the SCP. The SCP will determine
the SGSN is not in service via the Activity Test GPRS CAP message (and
presumably tear down all the inactive Dialogues).

Mobiles hosted by the failed GSC must re-attach and reactivate their PDP
Contexts in order to resume service.
GSD
Upon GSD card failure, the GSC tears down all the PDP Contexts associated
with the failed GSD card. In this scenario, the SGSN can report the
termination of the PDP Context to the SCP, and thus end the GPRS Dialogue
normally. The only issue with GSD failures is that the accumulated traffic
volumes are monitored on these cards, and are lost upon card failure. The
SGSN is unable to report the traffic volumes to the SCP.
MAP card
If the MAP card fails, existing TCAP sessions and client registration
information are lost. All clients must reregister with the MAP/TCAP stack
again when the MAP card comes back into service.
The SGSN performs retries when no response is received from the MAP
Card, until either an error is received or the maximum number of retries is
reached. The SGSN will then either allow the PDP Context to continue or
request the PDP Context to be discontinued based upon the provisioning of
the Default Handling field in the G-CSI on the HLR.
SAS
Refer to “Node failure processing and SAS” on page 6-25.
ATM I/O card

If the GTP path fails, all PDP contexts are torn down. In the case of Gn over
ATM, if the ATM card fails and recovers before GTP detects a path failure,
the PDP contexts are not torn down. If the ATM I/O card fails and does not
recover, the SGSN is unable to communicate with any other nodes in the
network and tears down all the PDP contexts. In this scenario, the SGSN can
not report the termination of the PDP context to the SCP. The SCP will
determine the SGSN is not in service via the Activity Test GPRS CAP
message (and presumably tear down all the inactive Dialogues).
SIG
If the SIG or TCP connection fails, the MAP/TCAP Stack keeps retrying the
connection. If this happens during initialization, the SSF will not be able to
register successfully with the MAP/TCAP stack. However, if this occurs after
a successful registration, all messages sent by the clients will be lost, and the
clients will time out on the message send.
SCP
If the SCP is configured as a duplex system with active/standby nodes, upon
SCP failure the standby node switches over to active mode and continues
processing queries. Thus limiting the loss of messages between the SGSN and
SCP.

If the SCP is configured as a simplex system, upon SCP failure the SCP
cannot provide any service and all existing GPRS dialogues are terminated on
the SGSN on the next attempt to communicate with the SCP. The SGSN may
retry sending messages to the SCP before terminating the dialogue.

The following list gives an overview of the main features not supported for
CAMEL 3 in this release.
• The SGSN will not communicate with the legacy HP SIG containing the
MAP stack. A network with the MAP stack located on the SIG will not
support CAMEL.
• The SGSN does not verify the contents of the Charging Characteristic in
the subscriber’s profile.
• Mobile-originated SMS prepaid employing the CAMEL architecture is
not supported in the GPRS SGSN.
• Only PDP Context trigger points are supported. The GPRS Session
(GPRS Attach/Detach) trigger points and associated messaging/
functionality are not supported.
• The Advice of Charge feature is not supported.
• In order to provide seamless service to pre-paid subscribers, all the
SGSNs of a GGSN must support CAMEL services. For instance, for an
IRAU, which includes inter-SGSN RAU and Inter-System Changes
(UMTS<->GPRS mobility), performed from an SGSN that supports
CAMEL and one that does not, there is no mechanism to establish a
dialog with the SCP to obtain the necessary charging information to
monitor the pre-paid PDP Context.
• Roaming is not supported for CAMEL when the Change of Position PDP
Context TDP is not provisioned in the G-CSI. Since all DPs are inherently
optional, if the TDP for Change of Position PDP Context is not
provisioned, the SCP will never be notified by the new SGSN.
• Processing of the Tariff Switch Interval IE in the ApplyChargingGPRS
message is currently not supported.
• Extensions and Ellipsis fields in CAP messages are not used.
• Due to overall end-to-end timer restrictions enforced in the SGSN
network it is recommended that when fine tuning SGSN provisionable
attributes:
— TssfChargingGuardTimer
— TssfChargingGuardRetryAttempts
the product of the (TssfChargingGuardTimer) and
(TssfChargingGuardRetryAttempts + 1) not exceed 15 seconds. This
product represents the time the gprsSSF component spends in attempting

to receive a response from the SCP. If the value is considerably larger than
15 seconds, then it is possible that while the gprsSSF is waiting for a
response from the SCP, a failure procedure is initiated by the SGSN, due
to an overall timeout at the SGSN.
Following are examples of how these attributes may be provisioned.
Example provisioning - Less retry attempts, Higher Retry Interval

TssfChargingGuardRetryAttempts = 2
TssfChargingGuardTimer = 5
((2+1) x 5 = 15 This is equal to the maximum recommended value of 15
seconds)
Example provisioning - More retry attempts, Smaller Retry Interval

TssfChargingGuardRetryAttempts = 4
TssfChargingGuardTimer = 3
((4+1) x 3 = 15 This is equal to the maximum recommended value of 15
seconds)
• Excluding the Free Format Data and FFD Append Indicator fields, all of
the CAMEL Information is not stored in the S-CDR until prior to the PDP
context being disconnected. If the CAMEL dialogue does not perform any
Apply Charging and does not arm the Disconnect EDP, then CAMEL will
not be involved in the Deactivation procedure and CAMEL Billing
Information will not be included in the S-CDR.
• FCIs sent prior to the PDP context being established on the SGSN will not
be included in the S-CDR as the S-CDR is not created on the SGSN until
the PDP context is established. Further, the SSF will respond to such FCIs
with a TaskRefused Error.
• On incoming CAP messages, if the SSF detects one of the following
errors: MissingParameter, ParameterOutOfRange, UnexpectedDataValue,
or UnexpectedParameter, it will send a Reject(InvokeProblem,
mistypedParameter) to the SCP.
• The SystemFailure Error is currently unsupported by the SSF.
• Lawful Interception is not supported for CAMEL messages.
• The maximum number of components per TCAP message that the SGSN
TCAP supports is five.

PDP context modification 5

It is possible to modify specific parameters of an already existing PDP
context. The context modification may be initiated by the SGSN or by the
MS.
SGSN initiated PDP Context modification

SGSN initiated PDP context modification supports the modification of only
the negotiated QoS. SGSN initiated PDP Contexts may be modified for any of
the following reasons:
• Updated subscribed QoS profiles in the HLR. This is initiated by the
HLR.
• Mobility (for example, IRAU). The negotiated QoS may need to be
altered across Routing Areas.
The steps in SGSN initiated PDP context modification are:

1. When the QoS profile of the MS is changed (upgrade or downgrade) in
the HLR, an Insert Subscriber Data message is sent to the SGSN.
2. The SGSN updates its subscription data and acknowledges the Insert
Subscriber Data message by returning an Insert Subscriber Data Ack
message.
3. For an active PDP context, the SGSN compares the new QoS subscribed
with QoS requested. A new negotiated QoS is selected by the SGSN. If
the new Negotiated QoS is different from previously Negotiated QoS, the
new Negotiated QoS is transferred to the GGSN via the Update PDP
Context Request message.
4. If QoS Negotiated received from SGSN is incompatible with the PDP
context being modified, the GGSN rejects the Update PDP Context
Request and then the SGSN abandons the modification procedure and
uses the previously negotiated QoS. If it is compatible, GGSN stores the
QoS Negotiated and returns an Update PDP Context Response message.
5. Then SGSN sends a Modify PDP Context Request to the MS with the
new Negotiated QoS. The MS may either accept the new QoS, or initiate
a deactivation procedure.
6. The MS sends a Modify PDP Context Accept to the SGSN.
For details about the messages and the corresponding parameters, refer to
specification 3G TS 23.060 v3.12.0, “GPRS Service Description. Stage 2”.
MS initiated PDP Context modification

MS initiated context modification enables the end user or the MS to modify
specific parameters of an already active PDP context.

This feature is normally invoked by the end user (or the MS) when the QoS
associated with a PDP context is not appropriate to run a particular
application. This procedure can be invoked directly by the end user by
modifying some parameters on the device or can be invoked transparent to
the end user based on an application’s QoS requirements. The “negotiated”
QoS is captured in the billing records in the core network. (Refer to NTP 411-
5221-204, SGSN Call Detail Records (CDRs) for more information about
billing records.) The MS-Initiated PDP Context Modification functionality
allows consumer flexibility for on-demand QoS, and also allows for
application-efficient QoS settings.
The steps in MS initiated PDP context modification are:

1. The MS sends a Modify PDP Context Request to the SGSN with a new
Requested QoS.
2. For an active PDP context, the SGSN compares the new QoS Requested
with QoS subscribed. A new Negotiated QoS is selected by the SGSN. If
the new Negotiated QoS is different from previously Negotiated QoS, the
new Negotiated QoS is transferred to the GGSN using the Update PDP
Context Request message.
3. If it is compatible, GGSN stores the QoS Negotiated and returns an
Update PDP Context Response message.
4. The SGSN sends a Modify PDP Context Accept to the MS with the new
Negotiated QoS. The MS may either accept the new QoS, or initiate a
deactivation procedure.
Note: If QoS Negotiated received from the SGSN is incompatible with

the PDP context being modified, the GGSN rejects the Update PDP
Context Request. The SGSN then sends another Update PDP Context
Request to the GGSN with the previously negotiated QoS. Then SGSN
sends a Modify PDP Context Accept to the MS with the previously
negotiated QoS.
Service Switching Function

The GPRS Service Switching Function (SSF) provides the interface between
regular PDP Context processing in the GPRS network and the Intelligent
Networking (IN) functionality added by CAMEL Phase 3. In support of
SGSN and MS-Initiated PDP Context Modification, SSF must report the
change in QoS for a CAMEL-enabled subscriber to the SCP.
After the GGSN has been successfully updated, SSF reports the QoS Change
and traffic counts and elapsed PDP Context duration to the SCP using the
Apply Charging GPRS Report CAP message. Refer to “CAMEL Phase 3” on
page 5-23 for more information about CAMEL Phase 3.

Timer expiry
On the network side, upon transfer of the Modify PDP Context Request
message to the MS, the SGSN sets timer T3386. Upon expiration of this
timer, the SGSN re-transmits the message and restarts the T3386 timer. This
message may be resent up to four times by the SGSN. After the fifth timeout,
the SGSN may continue to use the previously negotiated QoS.
MS Timer Expiry is outside the scope of this document because it is mobile

driven.
Collision detection
Collision detection error handling is defined for scenarios where MS-Initiated
and Network-Initiated PDP Context Modifications occur simultaneously for a
PDP Context. In the case of such a collision, the Network-Initiated PDP
Context Modification shall take precedence over the MS-Initiated PDP
Context Modification. Nortel SGSN prioritizes the PDP Context
Modification in the following order: HLR, IRAU, GGSN, MS.
Collision can also occur between PDP Context Modification (could be either
MS or Network-Initiated) and Service Request handling. The process which
is already in progress, will be completed before the other one is started.
Error cases
The general approach for handling error scenarios for PDP context modification
is:
• Upon any GGSN failure, the SGSN tries to recover by reverting back to
the original QoS.
• Upon any QoS negotiation failure, the original QoS is sent without
updating GGSN.
• Upon any recovery error, (such as GGSN fails when trying to change to
the original QoS), the SGSN initiates a deactivation on the mobile.

Table 5-10 lists errors scenarios for PDP context modification and indicates
whether they are MS or SGSN initiated.
Table 5-10
Error scenarios for PDP context modification
Error MS-initiated SGSN-initiated
Modify PDP Context Request is received Yes No

with invalid QoS

with invalid length/message

with TFT/Packet Flow Id
QoS negotiation fails Yes Yes
Update PDP Context Response is received Yes Yes

with invalid QoS with reserved values

with QoS upgrade

with QoS downgrade
Update PDP Context Request failure Yes Yes
Modify PDP Context Request times out No Yes
PDP context modification counters

Statistical data related to SGSN and MS-Initiated PDP Context Modification
can be displayed under the Gsc sessionManagement (Sm) component. They
are mainly of 2 types:
• Counter indicating the number of PDP context modifications attempted
• Counters for unsuccessful PDP context modifications at each of nodes -
SGSN, GGSN, MS.
Refer to “Performance counters” on page 7-14 for more information about
session management counters. Refer to NTP 411-5221-060, SGSN Components
Reference Manual, for complete counter descriptions.
• sgsnInitModifyAttempts—number of PDP context modifications initiated
from the SGSN.
• sgsnInitModFailAtMs—number of unsuccessful PDP context
modifications initiated from the SGSN that failed at the MS.

• sgsnInitModFailAtGgsn—number of unsuccessful PDP context

modifications initiated from the SGSN that failed at the GGSN
• sgsnInitModFailAtSgsn—number of unsuccessful PDP context
modifications initiated from the SGSN that failed at the SGSN.
• msInitModifyAttempts—number of PDP context modifications initiated
from the MS.
• msInitModFailAtMs— number of unsuccessful PDP context
modifications initiated from the MS that failed at the MS.
• msInitModFailAtGgsn— number of unsuccessful PDP context
modifications initiated from the MS that failed at the GGSN.
• msInitModFailAtSgsn— number of unsuccessful PDP context
modifications initiated from the MS that failed at the SGSN.
Restrictions
PDP Context modification has the following restrictions:
• The QoS policy described here affects traffic on the GPRS/UMTS
network only; it is not QoS end-to-end policy.
• Only SGSN and MS-Initiated PDP Context Modifications are supported.
The RNC and GGSN initiated procedures are not supported. The SGSN-
Initiated PDP Context Modification procedure is only supported upon
HLR change to QoS Profile and over Inter-SGSN Routing Area Updates
event.
• In the MS-Initiated PDP Context Modification, the MS can only modify
the Negotiated QoS of an existing PDP Context. The modification of TFT
template and LLC SAPI are not supported.
• In the SGSN-Initiated PDP Context Modification, only the Negotiated
QoS of an existing PDP Context can be modified. The modification of
Radio Priority, LLC SAPI and PacketFlow Id are not supported.
• The Modify PDP Context Reject message is not supported. This SGSN-
>MS message is used only to reject changes to TFT templates, and is not
used to reject changes in the QoS (3G TS 24.008). As TFT templates are
not supported, this message is unnecessary and not supported in the
SGSN.
• DSCP marking is not supported for GPRS.
• If invalid or no QoS exists in the Modify PDP Context Request message,
that message is ignored. Also if Modify PDP Context Request message
contains no parameters, that message is ignored as well.

Secondary PDP context activation 5

The SGSN supports Secondary PDP context as defined by the 3GPP Release
4 standards (3GPP TS 24.008, “Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3”, 3GPP TS 29.060, “General Packet Radio
Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp
Interface” and 3GPP TS 23.107, “Quality of Service (QoS) concept and
architecture” Annex C).
Secondary PDP context support allows a MS to activate one or more

secondary PDP contexts using the same PDP Address and APN as an
associated primary PDP context. Each secondary PDP context may specify its
own level of QoS. Traffic flow templates (TFT) are provided by the MS
during secondary activation and used by the MS and GGSN to associate data
flows using the same PDP Address with their proper GTP tunnels. Secondary
PDP context functionality therefore allows per application QoS levels using a
single PDP Address. Additionally, each PDP context may have different tariff
rates applied based on their use, which provides flexibility for operator
service definitions and significant opportunity for revenue generation. The
secondary PDP context feature can be enabled and disabled by the operator.
Secondary PDP context has several significant benefits including the following:
• New revenue opportunities, allowing per application QoS in a single
session (single IP address)
• Enabler for release 5 SIP based session control for advanced services such
as voice over IP, multi-media messaging etc.
• Efficient use of over the air resources for multi-media data streams
• Enables always on communication without requiring context
modification
Extended TI IE
In addition to secondary PDP context, this feature introduces support for the
extended Session Management Transaction Indicator (TI) Information
Element (IE). The extended TI value is an optional extension of the TI and
allows TI values from 0 – 127. The number of simultaneously active PDP
contexts however only increases to 11 from the previous 7 since the Network
Service Access Point Identifier (NSAPI) becomes the 3GPP limiting factor
when using extended TI. The NSAPI value ranges from 5 – 15 and is used by
the MS and GGSN to identify the service access point that is used for data
transfer at layer 3.
The SGSN therefore supports up to 11 simultaneously active PDP Contexts

per subscriber. This maximum number may include multiple primary and
associated secondary PDP contexts. The extended TI support is always
available even when the secondary PDP context feature is disabled. In this
case a subscriber may have up to eleven concurrent primary contexts.

PDP bundle
A primary PDP context together with its associated secondary contexts make
up a PDP bundle. A PDP bundle is a term which refers to the group of PDP
contexts each associated with the same PDP Address and APN. Figure 5-8
depicts a MS that has activated a primary PDP context and several secondary
PDP contexts resulting in a PDP bundle with all contexts using the same PDP
Address and APN. Each PDP context in the bundle may have a different QoS
allowing efficient use of bandwidth as dictated by mobile application
requirements. The MS can use one context dedicated for low bandwidth
activities such as e-mail and another context for high bandwidth activities
such as streaming audio. Each PDP context is billed using the same billing
methods available to the primary context and uses its own CDRs.
In the example in Figure 5-8, the primary PDP context is without a TFT and is
therefore the “default context”. Any GTP downlink packets not matching any
of the TFT packet filters in the PDP bundle will be routed to the default
context. A PDP bundle may or may not contain a default context; additionally
the default context may be a primary or a secondary PDP context.
Specification of a default context is determined and controlled by the MS.
Figure 5-8
Secondary PDP context example

Secondary PDP Context activation procedure

The purpose of this procedure is to establish an additional PDP context
between the MS and the network using a specific Traffic Flow Template
(TFT) and QoS profile while reusing the PDP Address and APN of an already
active PDP context. The MS optionally includes the TFT in the request but
must ensure that no more than one context is without a TFT for a successful
activation to occur. A unique TI and a unique NSAPI allows identification of
each PDP context sharing the same PDP address and APN.
Error scenarios
Upon receipt of an ACTIVATE SECONDARY PDP CONTEXT REQUEST
message, the network may reject the MS initiated PDP context activation by
sending an ACTIVATE SECONDARY PDP CONTEXT REJECT message to
the MS. This message contains a cause code indicating the nature of the
problem. Primary PDP context activation and secondary PDP context
activation procedures can fail due to the same reasons (for example,
insufficient resources, authentication failed, GGSN rejection, etc.) except for
those errors related to APN selection and PDP Address. Error conditions (and
their corresponding SM cause codes) specific to secondary PDP context
activation are:
• Linked TI in the Activate Secondary PDP Context Request message does

not match an already active PDP context for this mobile (cause code:
“Unknown PDP context”)
• Semantic or syntactical error in TFT or TFT packet filters (these errors
are detected by the GGSN and indicated to the SGSN via GTP cause IE)
(cause codes: “Semantic error in the TFT operation”, “Syntactic error in
the TFT operation”, “Semantic error in packet filters”, “syntactic errors in
packet filters”)
• MS does not include a TFT in the request and there is already one PDP
context without a TFT (cause code: “PDP context without TFT already
activated”)
Abnormal scenarios
Following are abnormal scenarios related to secondary PDP context activation:
• Reactivation of a secondary PDP context
It is possible for the SGSN to receive an Activate Secondary PDP Context
Request message containing an NSAPI or TI value that is being used by a
currently activated PDP context. In this scenario the currently activated
context is deactivated without informing the mobile (the mobile is not
messaged since it is assumed the mobile has lost knowledge of the
currently activated PDP context). After deactivation of the original
context the new secondary activation request is processed. This allows the
new secondary PDP context activation to replace the previous PDP
context activation.

• Reactivation of a secondary PDP context – bad linked TI case

When an activate secondary PDP context request is received, the
duplicate TI and duplicate NSAPI checks will be first performed to check
for the reactivation scenario described above. After the reactivation
procedure is completed, the linked TI IE of the secondary request is
examined. If the linked TI does not match an existing active PDP context
(i.e. could match the previously deactivated PDP context) then the
secondary PDP context request is rejected with the cause “Unknown PDP
Context”.
• Reactivation of a primary PDP context

It is possible for the SGSN to receive an Activate PDP Context Request
message containing the same combination of APN, PDP type and PDP
address as a currently activated PDP context. In this scenario the currently
activated context and all other PDP contexts with the same APN, PDP
type and PDP address are deactivated without informing the mobile (the
mobile is not messaged since it is assumed the mobile has lost knowledge
of the currently activated PDP contexts). After deactivation of these
contexts the new activation request is processed.
• Secondary PDP context feature disabled

If the SGSN receives an Activate Secondary PDP Context Request
message with the secondary functionality disabled (see “Configuration
management” on page 5-51), the SGSN rejects the request with cause
code “service option not supported”.
• Secondary Activation with GTP Tunnel Version 0

Version 0 GTP tunnels do not support Release 99 secondary PDP context
requirements. Therefore when an attempt is made to activate a secondary
PDP context specifying a linked context that has established a Version 0
GTP tunnel to the GGSN, the SGSN will reject the request with cause
code “service option not supported”.
If the version 0 tunnel was established to a Release 99+ GGSN as the

result of fallback procedures, the behavior of rejecting secondary
activation attempts will be maintained even after the path to the GGSN is
upgraded to version 1. The MS must then establish a new primary PDP
context to the upgraded GGSN path to be able successfully activate a
secondary PDP context.
TFT modification
The PDP context modification procedure (see “PDP context modification” on
page 5-38) is used to allow modification of a TFT associated with a primary
or secondary PDP context. The TFT is a list of packet filter specifications
provided by the MS and is used by the MS and GGSN to route packets onto

proper GTP tunnels. The TFT is not significant to the SGSN; consequently,
the SGSN only validates the TFT IE length before passing the TFT to the
GGSN. Modification of the TFT may only be initiated by the MS and may
include a request to create or delete a TFT, or a request to add, replace or
delete the TFT packet filters.
Only one PDP context per PDP address may be without a TFT. A PDP
context without TFT serves as the default context for packets not matching
any other TFTs associated with that PDP Address.
Error scenarios
The modify PDP context procedure allows update of both TFT and QoS
parameters. In this case the network handling of error conditions depends on
the nature of the error. 3GPP TS 24.008 specification requires that the modify
PDP context reject message be used to reject errors related to the TFT.
Conversely a modify PDP context reject message must not be used if the only
error in the procedure is related to QoS.
Errors unrelated to QoS

The MS initiated modify PDP context procedure may fail due to errors
detected by the network. If the error is unrelated to the QoS then the modify
PDP context reject message is sent from the network to the MS with a cause
code indicating the reason for the rejection. Possible error conditions are:
• Semantic or syntactical error in TFT or TFT packet filters (these errors

are detected by the GGSN and indicated to the SGSN via GTP cause IE)
(cause codes: “Semantic error in the TFT operation”, “Syntactic error in
the TFT operation”, “Semantic error in packet filters”, “syntactic errors in
packet filters”)
• MS requests deletion of a TFT and there is already one PDP context in the
bundle without a TFT (cause code: “Semantic error in the TFT
operation”)
• TFT IE length invalid (cause code: “Syntactical error in the TFT
operation”)
• GGSN does not respond to the update PDP context request message or
responds with an error unrelated to QoS. In this case the SGSN responds
with one of the following cause codes:
— Unknown PDP Context
— Service Option Not Supported
— Network Failure
— Semantically Incorrect Message

Errors related to QoS

The following QoS errors may be encountered as a result of a request to modify
both the QoS and TFT:
• QoS Negotiation Failure
If the QoS negotiation on the SGSN fails, the modify PDP context
procedure continues except that the old QoS is returned to the mobile in
the Modify PDP Context Accept message.
• New negotiated QoS equals current negotiated QoS

If the QoS negotiation on the SGSN results in a negotiated QoS equal to
the current value of QoS then the modify PDP context procedure
continues except that the old QoS is returned to the mobile in the Modify
PDP Context Accept message.
Abnormal scenarios for TFT modification

The following are abnormal scenarios for TFT modification:
• Secondary PDP context feature disabled

If the SGSN receives a Modify PDP Context Request message with a
request to modify TFT and secondary PDP context functionality is
disabled (see “Configuration management” on page 5-51), then the SGSN
will ignore the TFT IE in accordance with 3G TS 24.008 (Release 4) and
continue to process the request.
• Collisions with other modification procedures

Collision error handling is performed as stated in “PDP context
modification”, “Collision detection” on page 5-40 (i.e. network initiated
PDP modification requests take precedence over MS initiated requests)
with the following exception.
If an existing MS initiated modification request to modify the TFT only

collides with a subsequent HLR initiated request to modify the QoS, then
the MS initiated request to modify the TFT only is completed. After
completion of the MS initiated request, the HLR initiated request to
modify QoS is processed. This collision handling ensures that the MS and
GGSN will not get out of synchronization regarding TFT storage.
Deactivation and teardown

Deactivation with teardown is the deactivation of all contexts in the PDP
bundle in one deactivation procedure. The advantage of this procedure is
primarily that all contexts in the PDP bundle can be deactivated with reduced
network messaging. This is accomplished through use of the teardown
indicator IE which if set to “1” indicates a request for teardown of all contexts
in the bundle. This IE is optional over the Gb interface and conditional over

the Gn interface. If this IE is not present in the request then only normal
deactivation of a single PDP context occurs even if there are multiple
contexts in the PDP bundle.
Deactivation with teardown procedure is supported for MS initiated, GGSN

initiated and SGSN initiated deactivation.
Inter-SGSN routing area update

In inter-SGSN routing area update (IRAU) scenarios, this feature prioritizes
each PDP context according to the algorithm specified in 3GPP TS 23.107
and transfers the prioritized list of contexts to the new SGSN. In this manner
all PDP contexts associated with the MS are reestablished on the new SGSN
(provided sufficient resources exist on the new SGSN).
IRAU to a Release 97 or Release 98 SGSN

An IRAU event occurs when a MS previously served by an R4 SGSN enters a
routing area served by an R97 or R98 SGSN. Since R97/R98 compliant
networks do not support secondary PDP context or extended TI, the R4
SGSN must drop any PDP contexts using extended TI and then transfer only
the highest priority remaining context from the PDP bundle(s) to the R97/R98
SGSN. The context is prioritized as described in “PDP context prioritization
algorithm”.
IRAU to a Release 4 or Release 99 SGSN

An IRAU event occurs when a MS previously served by an R4 SGSN enters a
routing area served by another R4 or R99 SGSN. Since R4/R99 networks
support secondary PDP context and extended TI, the “old” SGSN must
transfer all active primary and secondary PDP contexts to the new SGSN as
part of the IRAU procedure. In this case the PDP contexts are prioritized
without regard to PDP bundle if multiple bundles exist. The context is
prioritized as described in “PDP context prioritization algorithm”.
PDP context prioritization algorithm

Active PDP contexts are prioritized using their QoS profile in accordance
with 3G TS 23.107 Annex C (Release 4). This prioritization reflects the
relative importance of preserving a PDP context compared to the other active
contexts for a mobile. The prioritization is necessary in case the new SGSN
can not accept all the transferred PDP contexts due to resource or other
problems. In this case the new SGSN will not accept the lowest prioritized
PDP context(s) so that the highest PDP context(s) are preserved.

Table 5-11 shows how the SGSN uses the PDP context QoS profile to
perform the prioritization.
Table 5-11
PDP context prioritization scheme
QoS ranking Traffic class Traffic handling priority
1 Interactive 1
2 conversational Not applicable
3 streaming Not applicable
4 Interactive 2
5 Interactive 3
6 Background Not applicable
If more than one context has the same traffic class and traffic handling priority,
the context is chosen based on the following criteria (in order presented):
1. maximum downlink bandwidth
2. maximum uplink bandwidth
3. lowest NSAPI
Secondary PDP context disabled

This feature allows secondary PDP context functionality to be disabled or
enabled through provisioning (see “Configuration management” on page 5-51).
If secondary PDP contexts are transferred to the “new” SGSN in the GTP SGSN
Context Response message and secondary PDP context functionality is
disabled, then the “new” SGSN will behave as follows:
• The IRAU procedure is completed
• All PDP contexts (except highest priority context per PDP bundle) is
deactivated
Note that the SGSN Context Response message provides no indication of

which transferred contexts were activated using primary activation
procedures and which were activated using secondary activation procedures;
therefore the scenario described in this section only ensures that a single PDP
context per PDP Address and APN remains activated on the “new” SGSN.
Also note that the SGSN uses the prioritized list of PDP contexts received in
the SGSN Context Response message to determine which PDP context per

bundle to retain. The highest ranking PDP context in the list in each bundle is
retained.
OAM
(OAM) information for Secondary PDP context.
Fault management
The following alarms indicate when there are insufficient resources available
to complete the primary or secondary PDP context activation:
• GPRS Alarm 7068 1005: GSC Memory Exhausted
• UMTS Alarm 7068 1502: SM Max Active Sessions Exceeded
These alarms are set upon receipt of the activation request from the MS and
are cleared after subsequent deactivations of either primary or secondary
contexts.
For more information on these alarms, refer to NTP 411-5221-500, SGSN

Alarms Reference Manual.
Attribute secondaryPdpContext in component GprsSubscriberControl (Gsc)
specifies whether secondary Packet Data Protocol (PDP) context
functionality is disabled or enabled. The range is “disabled - enabled”; the
default is “disabled”.
If the attribute is “disabled”, requests for secondary PDP context activations

are rejected using the ACTIVATE SECONDARY PDP CONTEXT REJECT
message. This event is indicated by the msSecActServiceOpNotSupported
attribute of the Gsc GprsSessionManagement component.
Also, if the value of this attribute is “disabled”, secondary PDP contexts

transferred to this Gsc component as part of an IRAU event are immediately
deactivated. This event is indicated by the newSgsnInvalidPdpCtxtsDropped
attribute of the GprsSessionManagement component.
Warning: Changing this attribute from “enabled” to “disabled” causes a

subscriber control card restart resulting in loss of service. The operator is
warned about the restart.
The operator is also warned when all cards on the same shelf do not have the
same provisioned value for this attribute.
This feature does not add or change billing records. Primary and secondary
PDP contexts are billed in an identical manner; therefore this feature reuses

billing records currently used for primary PDP contexts. This includes
prepaid, postpaid and partial billing records.
Statistical data related to secondary PDP context can be displayed under the
Gsc Sm component.
Refer to “Performance counters” on page 7-14 for more information about
performance management counters. For complete statistics descriptions, refer
to NTP 411-5221-060, SGSN Components Reference Manual.

The following restrictions and limitations apply to this feature:
• Once enabled via provisioning, the secondary PDP context functionality
cannot be disabled without a subscriber control card restart. This restart
will result in a temporary loss of service for subscribers being served by
the reset card. Subscribers must re-attach and re-activate all contexts in
order to resume lost service.
• When the secondary PDP context feature is disabled on the new SGSN
via provisioning, all secondary PDP contexts transferred to the new
SGSN in a Inter- SGSN Routing Area Update procedure will be accepted
but deactivated after the IRAU procedure completes.
• Disabling secondary PDP context via provisioning does not disable
Extended Transaction Identifier (eTI) functionality.
• The SGSN only validates TFT IE length and does not validate TFT
contents or semantics. Other TFT syntactic and all TFT semantic checks
must be performed by the GGSN.
• IPv6 PDP Type is not supported by this feature.
• Subsequent to establishment of the PDP context, all primary and
secondary PDP contexts are treated equally and no attempt is made by the
SGSN to distinguish between them.
• Transfer of PDP contexts using the extended Transaction Identifier (eTI)
to a non- Nortel SGSN not supporting eTI will result in undefined
behavior. This undefined behavior could include a failed IRAU or a
successful IRAU with dropped PDP contexts.
• When secondary PDP context is disabled, attempting to add a TFT to a
primary PDP context may lead to network rejection of subsequent related
secondary PDP context activation attempts after the secondary PDP
context feature is enabled. (see section 3.3.4.1 for how the SGSN will
handle the TFT IE when secondary PDP context is disabled)
• The SGSN will accept the End User Address (EUA) IE with or without
the optional PDP address field in the create PDP context response for a
secondary activation. Also the contents of the EUA IE will be ignored in

this case since this information is redundant with that received during
primary activation. This SGSN behavior is a result of unclear 3GPP
specifications concerning inclusion of PDP address for the create PDP
context response for secondary activations and is an attempt to mitigate
vendor interoperability risks.
QoS negotiation 5
QoS negotiation provides standards based negotiation of traffic classes during
PDP context activation procedures to ensure compatibility with a variety of
terminals and access nodes. This ensures interoperability with a large number
of access and terminal vendors so that features work end-to-end without
extensive network tailoring.
According to 3GPP TS 24.008, “Mobile Radio Interface layer 3

Specification”, there are four traffic classes as shown in Table 5-12.
Table 5-12
Traffic classes
Bits Traffic class Quality of Service
001 Conversational Highest
010 Streaming High
011 Interactive Low
100 Background Lowest
QoS negotiation requires that the SGSN set the negotiated traffic class (TC)
to the lower of interactive or subscribed when the requested traffic class
during a mobile initiated PDP context activation or modification procedure is
“use subscribed TC.” Since the SGSN uses the “lower of the interactive or
subscribed” traffic class, the traffic class will be either “Interactive” or
“Background” whenever the mobile initiated PDP context activation or
modification procedure Qos TC states “use subscribed traffic class.”
Therefore, the negotiated TC is always “Interactive” unless the subscribed TC

is “Background.” If the subscribed TC is “Background,” then the negotiated
TC is “Background” as shown in Table 5-13.

Table 5-13
QoS background TC
Subscribed/Provisioned TC Negotiated QoS
Conversational Interactive
Streaming Interactive
Interactive Interactive
Background Background
Note: The SGSN converts any received R97 QoS to R99 QoS. The R97
Delay Class is converted to R99 Traffic Class as follows:
— Delay Class 1,2,3, -> Interactive Traffic Class

— Delay Class 4 -> Background Class
Therefore, mobiles that request R97 QoS have only the 2 Traffic Classes
(Interactive or Background) available as the requested Traffic Class.
A second QoS negotiation requirement is for the SGSN to negotiate the traffic
class (TC) during a mobile initiated PDP context activation or modification
procedure to be the lower of the subscribed TC and the requested TC.
Previously, the SGSN would reject the mobile if the mobile requested a
“higher” traffic class than what was subscribed/provisioned. The mobile is
now allowed to proceed with activation/modification. The mobile is sent the
negotiated traffic class value which is the subscribed/provisioned value (even
if the mobile requested a higher traffic class value). It is then up to the mobile
to decide whether to accept or reject the negotiated TC value. For example, if
a particular mobile is subscribed to Interactive traffic class and requests
Conversational TC, the negotiated TC value is set to Interactive in the reply to
the mobile activation.

BSS Packet Flow Context 5

The BSS Packet Flow Context (PFC) feature provides the Base Station
System (BSS) with information that describes QoS characteristics for data
transmission. Packet Flow Management (PFM) is the service entity in the
BSS and the SGSN for the establishment, modification, and deletion of the
PFCs.
PFC procedure
The BSS and the SGSN negotiate the PFC feature bit during the BVC Reset
procedure as per the GPRS Release 99 Standards. If both the BSS and the
SGSN support the PFC feature then the SGSN can initiate the Packet Flow
Context negotiation for an MS. This is primarily done to negotiate the
Aggregate BSS QoS Profile (ABQP) parameter.
The SGSN can provide a BSS with information related to ongoing user data
transmission. The information related to one MS is stored in a BSS context
that can contain a number of PFCs (see Figure 5-9). (The BSS may contain
BSS contexts for several MSs.) The SGSN calculates the aggregate QoS of
the mobile’s activated PDP contexts that have identical or similar QoS profile
and assigns a packet flow identifier (PFI) to identify a BSS PFC within a BSS
context.
Figure 5-9
BSS QoS addressing architecture
MS LLC SAPI
TLLI ABQP Shared by
PDP BSS and
Context 1 SGSN
PDP
Context 2 NSAPI=15, SAPI=3 PFI=21
PFC 1
NSAPI=14, SAPI=3 PFI=21
PDP
Context 3
NSAPI=13, SAPI=5 PFI=16 PFC 2
GMM/SM Signaling, SAPI=1 PFI=1

PFC -
SMS, SAPI=7 PFI=2 Signaling
SMS
PFC -
SMS
The ABQP is negotiated between the SGSN and the BSS. This defines the
QoS that must be provided by the BSS for a given packet flow between the
MS and the SGSN. When a PDP context is activated, modified or deactivated,
the SGSN updates the ABQP and can create, modify, or delete the BSS PFCs.

The BSS can restrict the requested ABQP based on its capabilities and the
current load, but cannot negotiate the PFCs for three reserved and pre-defined
packet flow identifiers (best-effort service, SMS and signaling). The SGSN
can assign the best-effort or SMS PFI to any PDP context. For SMS, the BSS
handles the packet flow for the PDP context with the same QoS in which it
handles SMS.
A BSS Packet Flow Timer (PFT) indicates the maximum time that the BSS
may store the PFC during periods of inactivity for that PFC. The BSS PFT is
started when the BSS PFC is stored in the BSS and restarted after the
retransmission of an uplink PDU for that PFC. This should not exceed the
value of the READY timer for this MS. When the BSS PFT expires the BSS
deletes the BSS PFC.
PCF support and negotiation

The SGSN supports the BSS Packet Flow Context procedure and the Packet
Flow Management (PFM) if all the following conditions are met:
• The GTL is provisioned to support PFC
• Both the BSS and the SGSN support PFC after negotiating the PFC
Feature Bit during the BVC Reset procedure as per the GPRS Release 99
Standards.
• The SGSN receives a PFC support Information Element (IE) in the MS
Network Capability during the Attach and RAU procedure from the
mobile.
• The GSC that hosts the mobile has a PFM component provisioned.
If PFC is supported, the SGSN creates, modifies, or deletes BSS PFCs, when
a PDP context is activated, modified, or deactivated.
SGSN cannot initiate the CREATE-BSS-PFC procedure if any one of the

above mentioned conditions are not met. In this case, SGSN also cannot
respond to a DOWNLOAD-BSS-PFC message from the BSS. The PFM
feature can be disabled by deleting the PFM components on all the GSC cards
and resetting the PFC provisioning on all the GTL cards. If a GSC card has a
PFM component provisioned, then the PFC is negotiated for those mobiles
that use that card.
For information about PFM provisioning parameters and operational/

statistical counters, refer to 411-5221-060, SGSN Components Reference
Manual.
Aggregate BSS QoS Profile

The BSS QoS profile for the PDP contexts that share the same packet flow is
called the aggregate BSS QoS profile. The ABQP is considered to be a single
parameter with multiple data transfer attributes as defined in 3G TS 24.008. It

defines the QoS that must be provided by the BSS for a given packet flow
between the MS and the SGSN, that is, for the Um and Gb interfaces
combined. The ABQP is negotiated between the SGSN and the BSS.
The SGSN uses the following attributes to upgrade or downgrade the ABQP
for a PFI:
• Maximum uplink bit rate
• Maximum downlink bit rate
• Guaranteed uplink bit rate
• Guaranteed downlink bit rate
All other attributes in the Aggregate BSS QoS Profile (see Figure 5-10) are
the same as the negotiated QoS Profile of the PDP context.
Figure 5-10
Aggregate BSS QoS Profile IE
8 7 6 5 4 3 2 1
Aggregate quality of service IEI octet 1
Length of quality of service IE Octet 2
0 0 Delay Reliability octet 3
spare class class
Peak 0 Precedence octet 4
throughput spare class
0 0 0 Mean octet 5
spare throughput
Traffic Class Delivery order Delivery of erroneous Octet 6
SDU
Maximum SDU size Octet 7
Maximum bit rate for uplink Octet 8
Maximum bit rate for downlink Octet 9
Residual BER SDU error ratio Octet 10
Transfer delay Traffic Handling Octet 11
priority
Octet 12
Guaranteed bit rate for uplink
Guaranteed bit rate for downlink Octet 13
Packet Flow Identifier

A Packet Flow Identifier (PFI) is used to identify a BSS PFC, as specified in
3G TS 23.060. Only a single PFI refers to a PFC and the corresponding
ABQP. Therefore, multiple PDP contexts may use the same PFI when
referring to the same PFC. If the PFC exists for the PFI then the BSS uses the
PFC to obtain the QoS profile. If the PFI is one of the reserved values then the
default PFC for that service is used. If the PFI does not correspond to an
existing PFC then the BSS sends the DOWNLOAD-BSS-PFC PDU to the
SGSN to initiate the PFC creation procedure across the Gb interface.

The following PFIs are defined with corresponding pre-defined PFCs:

• 0 - Best Effort
• 1 - Signaling
• 2 - SMS
• 3-7 (reserved)
• 8-127 (dynamically assigned by the SGSN)
Default PFCs for non-User Data LLC PDUs are used for PFIs 0-2. Figure 5-
11 shows the format of the PFI information element.
Figure 5-11
PFI Information Element
8 7 6 5 4 3 2 1
Packet Flow Identifier IEI octet 1
Length of Packet Flow Identifier IE octet 2
Spare Packet Flow Identifier value octet 3
0
BSSGP Layer enhancements

Table 5-14 summarizes BSSGP layer enhancements to support PFC,
described in 3G TS 08.18 v 8.10.0: “General Packet Radio Service (GPRS);
Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface;
BSS GPRS Protocol (BSSGP) (Release ‘99)”.
Table 5-14
BSSGP layer enhancements for PFC
Description Standards reference
DL-UNITDATA 3G TS 08.18 Section 10.2.1
UL- UNITDATA 3G TS 08.18 Section 10.2.2
PAGING PS 3G TS 08.18 Section 10.3.1
DOWNLOAD-BSS-PFC PDU from 3G TS 08.18 Section 10.4.16

BSS to SGSN
CREATE-BSS-PFC-ACK PDU from 3G TS 08.18 Section 10.4.18

BSS to SGSN
CREATE-BSS-PFC-NACK PDU from 3G TS 08.18 Section 10.4.19

BSS to SGSN
—sheet 1 of 2—

Table 5-14
BSSGP layer enhancements for PFC (continued)
Description Standards reference
MODIFY-BSS-PFC PDU from BSS to 3G TS 08.18 Section 10.4.20

SGSN
DELETE-BSS-PFC-ACK PDU from 3G TS 08.18 Section 10.4.23

BSS to SGSN
CREATE-BSS-PFC PDU from SGSN 3G TS 08.18 Section 10.4.17

to BSS
MODIFY-BSS-PFC-ACK PDU from 3G TS 08.18 Section 10.4.21

SGSN to BSS
DELETE-BSS-PFC PDU from SGSN to 3G TS 08.18 Section 10.4.22

BSS
—sheet 2 of 2—
PFM layer
The PFM layer is responsible for the ABQP calculation and update. It also
assigns the PFI and relays this information to other layers, for example, the
SM layer.
If the MS, the BSS and the GSC that hosts the mobile support the Packet
Flow Context feature (as described in “PCF support and negotiation” on page
5-56), then SGSN initiates the BSS Packet Flow Context procedure. The BSS
can also initiate this procedure by sending a DOWNLOAD-BSS-PFC PDU to
the SGSN.
During a PDP context activation, deactivation, or modification, PFM

calculates the ABQP and assigns a PFI for each session and notifies the
BSSGP with a CREATE-BSS- PFC event. PFM waits for a response before
allowing the associated event to continue.
Table 5-15 summarizes enhancements to the PFM layer described in 3G TS

08.18 v 8.10.0: “General Packet Radio Service (GPRS); Base Station System
(BSS) - Serving GPRS Support Node (SGSN) interface; BSS GPRS Protocol
(BSSGP) (Release ‘99)”.

Table 5-15
PFM layer enhancements
Description Standards Reference
Packet Flow Identifier IE 3G TS 08.18 Section 10.3.42
Aggregate BSS QoS Profile IE 3G TS 08.18 Section 10.3.43
Timers: T7, T9 3G TS 08.18 Section 12.1
ABQP calculation
The Maximum Downlink and Uplink BitRates, Guaranteed Downlink and
Uplink BitRates of the negotiated QoS of a PDP context are used for
calculating and assigning the ABQP and PFI.
For the first PDP context activated for a mobile, the ABQP is the negotiated
QoS of that PDP context. For any subsequent PDP contexts, the negotiated
QoS of the PDP context is compared with the negotiated QoS of the activated
PDP contexts. If the negotiated QoS of the new PDP context is different, then
a new PFI with this ABQP is created and is assigned to this session. If the
new PDP context has the same negotiated QoS as a previously activated PDP
context, then the PFI of the previous active PDP context is reused (in this case
the ABQP of both the contexts is recalculated). If more than 2 sessions have
the same negotiated QoS, then all those sessions have the same PFI assigned
and the ABQP is recalculated. ABQP Qos elements are coded the same as the
QoS profile (3GPP spec 08.18 section 11.3.43), hence the same restriction
would automatically apply for ABQP Uplink/Downlink values.
Note: For ABQP Max and Guaranteed Uplink/Downlink bitrates

calculation, refer to 3GPP TS 24.008 section 10.5.6.5.
Following are examples of how PFIs are allocated.

• Example 1: Different QoS profile but same uplink and downlink bitrates
PDP Context 1: Traffic Class = conversational,
Max Bit Rate for Uplink = 9 kbps
Max Bit Rate for Downlink = 9 kbps
Guaranteed Bit Rate for Uplink = 9 kbps
Guaranteed Bit Rate for Downlink = 9 kbps
...
PFI = 0x08, ABQP = negotiated QoS
PDP Context 2: Traffic Class = streaming,
...

Traffic class is different, but the rest of the Qos parameters are the same.
So, allocate new PFI for PDPC 2.
So, if any of the QoS attributes are different, a new PFI is assigned.
• Example 2: Different uplink or downlink bitrates

PDP Context 1: Delivery Order = withDeliveryOrder,
...
PDP Context 2: Delivery Order = withDeliveryOrder,
...
Max Downlink bitrate is different, but the rest of the Qos parameters are
the same. So, allocate new PFI for PDPC 2.
• Example 3: Same QoS profile (PDP Context 1 = PDP Context 2)

The negotiated QoS profiles of both the PDP Context are the same. In this
case, we double the respective values of the Max, Guaranteed Uplink and
Downlink bitrates, while the rest of the QoS attributes are the same as the
negotiated values.
PDP Context 1: Max Bit Rate for Uplink = 9 kbps

...
PFI = 0x08,
...
PFI = 0x08 (reuse PFI 0x08 for PDPC 2)
ABQP for both the PDP contexts in this case:
PDP Context 1, 2: Max Bit Rate for Uplink = 18 kbps
(Rest of the attributes have the same value as the
negotiated QoS)

• Example 4: Same QoS profile (PDP Context 1 = PDP Context 2 = PDP

Context 3)
The negotiated QoS profiles of all 3 PDP Contexts are the same. In this
case, we triple the respective values of the Max, Guaranteed Uplink and
Downlink bitrates, while the rest of the QoS attributes are the same as the
negotiated values.

...
PFI = 0x08,
...
PFI = 0x08
...
PFI = 0x08 (reuse PFI 0x08 for PDPC 1, 2)
ABQP for the 3 PDP contexts in this case:
PDP Context 1, 2, 3: Max Bit Rate for Uplink = 27 kbps
(Rest of the attributes have the same values as the
negotiated QoS)
Thus the ABQP value of these 4 parameters is bumped up if a session

being activated has the same negotiated QoS as an existing activated
session for that mobile. Similarly, the ABQP value of these 4 parameters
is bumped down if a session being deactivated has the same negotiated
QoS as an existing activated session for that mobile.
• Example 5: If the ABQP exceeds the maximum allowed value for the
guaranteed or max DL, UL bit rates:
Suppose that PDP contexts 1 and 2 have the same negotiated QoS and
have the following ABQP:
PDP Context 1, 2 Max Bit Rate for Uplink = 3000 kbps



...
PFI for PDP contexts 1, 2= 0x08
ABQP for PDP contexts 1, 2:
(Rest of the attributes have the same values as the negotiated QoS)
Suppose a 3rd PDP context gets activated with the same negotiated QoS as
the PDP contexts 1 and 2. In this case, if all 3 sessions share the same
ABQP, the value of “Max Bit Rate for Uplink = 9000” would exceed the
max allowed value “8640”. Hence, in this case PDP context 3 is assigned
a new PFI/ABQP as follows:
ABQP for the PDP context 3:

PFI = 0x09 (for PDPC 3)

(Rest of the attributes have the same values as the negotiated QoS)
PFI journalling
The PFM layer uses the GSC redundancy framework to provide redundancy
functionality. The PFI is journaled to the Spare GSC card after PDP-Context
Activation, PDP-Context Modification and IRAU. If the Active GSC card
goes down, the Spare GSC card becomes active and will continue supporting
the Packet Flow Contexts. PFI journaling is not supported if SGSN does not
support the PFC feature (as described in “PCF support and negotiation” on
page 5-56).
SM layer
The PFC functionality enhances SM on SGSN PDUs to include the optional
PFI IE. To support Packet Flow Management, the MS, the BSS and the SGSN
should support the PFC feature (as described in “PCF support and
negotiation” on page 5-56).

Table 5-16 lists the SM layer PDUs/messages that support PFI IE.
Table 5-16
SM layer enhancements
ACTIVATE PDP CONTEXT ACCEPT 3G TS 24.008 Section 9.5.2
MODIFY PDP CONTEXT REQUEST 3G TS 24.008 Section 9.5.9

(Network to MS direction)
MODIFY PDP CONTEXT AC 3G TS 24.008 Section 9.5.12

(Network to MS direction)
GTP layer
Table 5-17 lists the GTP layer PDUs/messages that support PFI IE.
Table 5-17
GTP layer enhancements
SGSN CONTEXT RESPONSE 3G TS 29.060 Section 7.5.4

Packet flow context functionality has the following restrictions and limitations:
• The SGSN derives the ABQP from the following bit rates: Max Bit Rate
UpLink, Max Bit Rate Down Link, and Guaranteed Bit Rate UpLink &
Guaranteed Bit Rate Down Link of the negotiated QoS Profile.
• The ABQP is not derived from the Transfer Delay attribute as explained
in 3G TS 23.060 section 12.6.3.5.1.
• SGSN does not support PFI IE in the GGSN-Initiated PDP Context
Modification Procedure (as defined in 3G TS 24.008 section 9.2.3.2).
This procedure is currently not supported, therefore PFI IE cannot be
added to this PDU.
• Although the SGSN supports PFM messaging and associated IEs
including PFI and ABQP, the SGSN does not guarantee Quality of
Service for GPRS. Packet flow context provides the BSS with necessary
information for it to allocate sufficient resources to the MS.
• SGSN does not initiate the Packet Flow Context negotiation if the MS or
the SGSN or the BSS do not support the PFC feature (refer to “PCF
support and negotiation” on page 5-56).
• In the IRAU procedure, if no PFI is received in the SGSN CONTEXT
RESPONSE from the old-SGSN (for example, the old-SGSN does not
support PFC) then the new-SGSN activates sessions with a PFI of “best-

effort”. For all new PDP contexts activated by the MS, the PFI and ABQP
are calculated similar to the normal activation.
• Maximum bit rate allowed by the 24.008 specification is 8640. In that
case the ABQP IE cannot have bit rates more than 8640, according to the
specification. Therefore, if addition of a session context to a PFI is going
to increase the bit rates of ABQP beyond 8640, then a new PFI is
allocated for that session context. This ensures that each session sharing a
PFI gets the bit rates that were negotiated.
• The SGSN does not use the “PFC transfer result” IE in the FLUSH-LLC-
ACK PDU received from the BSS (as explained in 3G TS 08.18 Section
8.1).
• PFI journaling (see “PFI journalling” on page 5-63) is not supported if
SGSN does not support PFC feature (as described in “PCF support and
negotiation” on page 5-56).
SGSN downlink PDU buffering 5

This section describes downlink Protocol Data Unit (PDU) buffering on the
SGSN.
In SGSN/GPRS buffering, downlink data is buffered on the GSD. It is

primarily intended to benefit end-to-end throughput in the case where the
BSS provides only a small buffer, in which case the SGSN would compensate
by increasing the total amount of data buffered for a mobile.
Upon receipt of downlink data from the GGSN, the SGSN tests various
conditions to determine if the packet can be immediately sent to the BSS. The
SGSN, depending on the configuration, may buffer packets under the following
conditions:
• Flow Control: a leaky bucket algorithm defined in GSM 08.18 governs
Downlink mobile (MS) flow control. If the leaky bucket on the BSS
becomes full, the SGSN will buffer incoming downlink data.
• LLC Suspended: LLC, which is the data link layer between the SGSN
and the mobile, may be suspended due to a Routing Area Update or
because the mobile is in Standby State. The SGSN will buffer downlink
data while LLC is suspended.
• IRAU Buffering: in IRAU, the old SGSN (SGSN that mobile is moving
from) buffers and then forwards the packets. In the New SGSN (SGSN
that mobile is moving to), the packets are buffered until the lower layers
come up.
Previously the SGSN/GPRS supported only downlink buffering. Packets
received during RAU on the old SGSN were discarded. IRAU buffering is
now supported.

System buffer management

SGSN downlink buffering uses a component for system wide buffer
management. The PduBuffer component is used by all applications in the
GSD card (for example, downlink buffering and IRAU).
Customers can provision five different buffer sizes as well as the total number
of blocks in each size:
• Mini
• Small
• Medium
• Large
• Xlarge
The ability to provision different buffer sizes allows customers to engineer

their networks for various traffic patterns and data useage. The maximum
available memory for buffer useage is determined by Systems Engineering
and is enforced during provisioning. A warning is generated when more than
the System Engineering buffer size is provisioned in the SGSN.
OA&M
This section describes PDU buffering OA&M. For complete descriptions of
buffering provisionable and operational parameters, refer to NTP 411-5221-
060, SGSN Components Reference Manual. For information on SGSN
alarms, refer to 411-5221-500, SGSN Alarms Reference Manual.
Fault management
Adding the PduBuffer subcomponent to a GSD that is already active results in
a loss of service for that GSD. If the PduBuffer component is provisioned
such that not enough memory is available on the GSD to support the
provisioning, a SET alarm (7068 1021) is generated and Buffering is
disabled. The GSD component continues to function normally.
A set alarm (7068 1038) is generated by GSD application to report any

changes in the congestion levels of provisioned frame buffer memory pools.
Following is an example of the set alarm used by GSD to report Minor
congestion.
Gsd/7; 2003-11-13 16:16:15.01

SET minor processing outOfMemory 70681038
ADMIN: unlocked OPER: enabled USAGE: active
AVAIL: PROC: CNTRL:
ALARM: STBY: notSet UNKNW: false
Id: 07000002 Rel: Lp/7
Com: FrameBuf usage is at minor congestion level.

Congestion level stats:

Mini-block pool = 15.40%
Small-block pool = 80.3%
Medium-block pool = 53.2%
Large-block pool = 3.80%
Xlarge-block pool = 0.0%
Int: 7/0/2/21970; gprsSgsnGsdProcess.cc; 1943; ""
If Downlink Buffer alarms are generated, the network operator must

manually acknowledge them at MDM or reset the GSD to clear them.
Required component PduBuffer under the Gsd component is used to
provision PDU buffering and buffer sizes. Optional components PduBuffer
IrauBuffer and PduBuffer DownlinkBuffer are used to provision the memory
allocated for IRAU buffering and downlink buffering, respectively.
PDU buffering provides the following statistics groups:
• BufPoolComOper—operational attributes for the PduBuffer component
• BufPoolOper—operational attributes for the 5 Buffer pool
components.
• BufApplOper—operational attributes for the IrauBuffer and
DownlinkBuffer components.
Restrictions and Limitations

Memory Block Allocation
Because the allocation of memory for buffering utilizes a fixed-size block
allocation method, the actual amount of buffered data is less than the
allocated memory.
Lossless IRAU
This feature does not implement lossless IRAU.

Lawful Interception (LI) 5

The Nortel GPRS Packet Domain Lawful Interception (LI) solution enables
security agencies to intercept and monitor target mobile subscribers within a
GPRS or UMTS network. Nortel LI application is common to both GPRS and
UMTS implementations. Lawful Interception permits the surveillance
organization to easily monitor Packet Domain communications. Both
Communication Content (CC) and Intercept Related Information (IRI) may
be reported. The LI application described in this document is applicable to
any country where a Nortel SGSN may be deployed. Any country specific
requirements are provided by external mediation devices.
The SGSN LI capability utilizes the services of a third party adjunct platform
to perform the administration and delivery functions necessary to satisfy
Lawful Interception requirements. The adjunct platform is responsible for
administering the interception of the target mobile terminals and also
performing the formatting and delivery of the CC and IRI to the Monitoring
Center (MC) and/or Law Enforcement Agencies (LEA).
LI reference model
3GPP TS 33.107, “Technical Specification Group Services and Systems
Aspects; 3G Security; Lawful Interception Architecture and Functions” defines
the LI Reference Model. The functional entities in the LI Reference Model are:
• ADMF—(Administration Function) obtains lawful Authorization from
one or more LEAs 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.
Figure 5-12 shows the Nortel implementation of the LI Reference Model.

This document describes the Access Function implemented on the SGSN.
Note: For information about compliance of the GPRS SGSN Lawful

Intercept feature with 3GPP TS 33.107 and 3GPP TS 33.106, “Lawful
Interception Requirements”, refer to NTP 411-5221-201, Specifications
for UMTS/GPRS Packet Core Conformance Guide.

Figure 5-12
Nortel implementation of the LI Reference Model
SGSN (AF)
Routers with
IPSec
ADMF/DF
CF
.. CF
LEA LEA
ADMF, DF2 and DF3 are implemented by other equipment manufacturers.

The ADMF, DF2 and the DF3 are generally referred to in this document as
LIG (Lawful Interception Gateway). For convenience both DF2 and DF3 are
referred to in this document as DF.
Secure delivery of intercepted information is done through external routers

with IPSec functionality, such as the Nortel CES (Contivity Extranet Switch).
The Collection function and any interface to LEAs is not addressed by this
feature.

SGSN as the Access Function

Every physical SGSN is linked by its own interface to the ADMF/DF.
Consequently, every single SGSN performs interception (activation,
deactivation, interrogation as well as invocation) independently from all other
SGSNs.
Both the SGSN and the ADMF/DF exchange information using the Lawful
Interception Common Protocol (LICP) to accomplish the interception. The
ADMF sends the SGSN provisioning information about the target. The SGSN
stores the target information. When the SGSN detects that a target is
conducting activity (i.e. Attach, PDP Context Activation, etc.), then the
SGSN sends intercepted IRI and CC to the DF. The DF is then responsible for
any further formatting and delivers the IRI and CC to the LEAs.
Interface between SGSN and ADMF/DF

The interface between AF and ADMF/DF must be secure and reliable. To
satisfy this requirement, Nortel uses its own Lawful Interception Common
Protocol (LICP) between the AF (SGSN) and the ADMF/DF. Figure 5-13
shows the LICP protocol stack. The stack is used to provide both the
administration and delivery functions of the packet data legal interception
network.

Figure 5-13
LICP protocol stack
LIAP
CAP
CDP
TCP
IPSec*
IP
L2
L1
LIAP - Lawful Interception Access Protocol

CAP - Common Administration Part
CDP - Common Delivery Part
IPSec* - Optional Security Layer
IPSec provides optional network layer security to secure the interface

between the Access Function and Administration functions. IPSec is provided
by a router. TCP is used as the transport layer between the AF and the ADMF.
When the AF restarts (initializes, reboots, etc.) then the TCP connection to
the ADMF is requested. The connection is re-established and a reset
notification is sent to the ADMF to tell the ADMF that the LI Database is
cleared. The TCP connection stays up waiting for administrative messages
from the ADMF.
The LICP layer is technology independent and also product independent and
intended to specify the packet data interception interfaces for all of Nortel’s
wireless data products. It includes both the Common Administrative Part
(CAP) and Common Delivery Part (CDP). CAP defines the interface between
AF and ADMF for provisioning a target for Lawful Interception. CDP defines
the interface between AF and DF for delivery of IRI and CC.
LIAP defines the product or technology specific fields for IRI and CC. For this
feature, the LIAP contains the GPRS/UMTS specific IRI and CC.

Interception of Intercept Related Information

When the target conducts any activity, the SGSN copies relevant information
and sends it to the DF using the Common Delivery part and the product
specific LIAP part of the LICP protocol.
Table 5-18 lists all potential intercepted information. Not all information is
found in every IRI event.
Failure events are captured for mobility events such as attach, PDP activation
and, in the case of the GPRS LI implementation, SMS.
Table 5-18
Intercept information
Field Description
Network Operator ID Length Length for the Network Operator ID digits
Network Operator ID Network Operator ID digits
Network Element ID Type Type of Network Element ID (e.g., E.164, X.25, IPv4 and IPv6)
Network Element ID Length Length of Network Element ID
Network Element ID Network Element ID digits
Observed ID 1 1st ID of the target subscriber (monitored subscriber)
Observed ID 2 Optional 2nd ID of the target subscriber (monitored subscriber)
Observed ID 3 Optional 3rd ID of the target subscriber (monitored subscriber)
Direction Type toward network or target (i.e., uplink/downlink PDU or MO/MT

SMS)
Product Type Type of product (for example, GPRS-UMTS, CDPD)
Event Type Attach, Detach, PdpContextAct, PdpContextDeact,

PdpContextStart, CellRAUpdate, SMS Event (GPRS only)
Event Detail Detail of the event generation in the SGSN

Table 5-19 lists the fields in the GPRS/UMTS Event details.

Table 5-19
Event details
Field Description
APN Access Point Number
End User Address Used PDP Type and Address
Correlation Number Charging ID and GGSN Address
SMS SMS Content and Header, sent with SMS-Service
Location ID Composed of location area ID and routing area ID
Failed Attach Reason Reason for failed attach of target subscriber
Failed Context Activation Reason Reason for failed context activation of target subscriber
SMS Event status Status of SMS Event
For each communication or other activity relating to a target identity, a

correlation number is generated by the relevant network element. The
correlation number consists of the following two identifiers:
• Network Identifier (NID)
• Communication Identity Number (CIN)
The GGSN address is used for the NID in the GPRS/UMTS system. The
charging ID is used for the CIN. The correlation number is used only for
successful PDP Context Activation and associated intercepted packets. The
correlation number is unique in the whole PLMN.
Interception of Communication Content

The access method used for delivery of the GPRS/UMTS Intercept Product is
based on duplication of packets without modification at SGSN. The duplicated
packets (for example, CC messages) are sent to the DF when a target receives
or sends a data packet; however, the delivery of intercepted packets to the DF
can be dependant upon decision logic evaluated within other software
components in the data path, for example:
• existing GPRS flow control criteria could prohibit delivery of a packet in
which case LI would not forward CC to the DF.

CC messages are CDP messages. A CC message is unacknowledged, relying

on the underlying TCP for guaranteed delivery to the DF.
Table 5-20
CC message information
Field Description
Network Operator ID Length for the Network Operator ID digits

Length
Network Operator ID Network Operator ID digits
Network Element ID Type of Network Element ID (e.g., E.164, X.25, IPv4 and IPv6)
Type
Network Element ID Length of Network Element ID

Length
Network Element ID Network Element ID digits.
Observed ID 1 1st ID of the target subscriber (monitored subscriber)
Observed ID 2 Optional 2nd ID of the target subscriber (monitored subscriber)
Observed ID 3 Optional 3rd ID of the target subscriber (monitored subscriber),
Direction Type toward network or target (i.e., uplink/downlink PDU or MO/MT SMS)
Product Type Type of product (e.g., GPRS-UMTS, CDPD)
Product Detail Information about Product
The GPRS/UMTS specific Product detail is shown in Table 5-21.

Table 5-21
GPRS/UMTS specific Product detail
Field Description
Correlation Number Charging ID and GGSN address. Correlates CC and IRI.
Location ID Location Identifier
PDU Packet Data Unit

LI hardware
A 2 Port General Purpose with Disk card (2PGPDsk) is required for the LI
component and its database. This card is functionally called the Lawful
Interception Service Processor (LISP) card. The LISP has a LAN port so that
a private LAN can be established between the SGSN and the ADMF/DF.
Refer to “Special considerations for I/O routing” on page 2-26 for I/O
options.
All events (IRI) and packets (CC) intercepted on the SGSN are sent to the
LISP card for formatting and delivery. The LISP card must be located within
in the same SGSN shelf that contains the GSC cards that it will support.
Figure 5-14 shows a logical, sample configuration of the LISP card on the
SGSN.
Figure 5-14
Sample SGSN/GPRS configuration for LI
Gb interface to MS Gn interface to GGSN
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
7K
ATM
GTL
LAN
LAN
GSD
GSD
CP
CP
Shelf
CC
IRI
15K
LI /Billing
ATM
Shelf
GSC
GSC
CP
CP
LICP interface to LIG
Error scenarios involving SGSN cards

If some of the cards in the SGSN shelf go down, the LI functionality may be
affected or totally disrupted.
• If a LISP card crashes and/or is reset:
— no IRI nor CC is delivered to the DF
— LI provisioning data stored in the LISP card’s volatile memory is lost.

After the LISP card boots (either the original or the standby if spared),
the LISP notifies the ADMF of the Reset, and the ADMF re-sends LI
provisioning information to the SGSN.
• If the target’s GSC card crashes:

For a non-redundant GSC card, no further monitoring takes place for IRI,
but CC continues until the context is deleted. IRI resumes when
subscriber reattaches.
For a redundant GSC card, the hot standby SC card takes over and
monitoring continues for both IRI and CC.
• If a target’s GSD crashes, no further monitoring takes place for CC, but
the IRI monitoring continues. Once the PDP session is re-established
(possibly on another card), CC continues for the targeted subscriber.
• All LI provisioning data on the SGSN which is stored in volatile memory
on the LISP card is lost once the card crashes and/or is reset.
Error recovery
• If any TCP connection goes down, then the Access Function tries to re-
establish it. A connection request is sent periodically until success to the
ADMF. LISP does not buffer any messages for retransmission (only the
TCP layer handles any packet buffering).
• If the Access Function TCP buffers overflow, any outgoing data will be
lost until the overflow situation is resolved.
Redundancy
The following sections describe the redundancy capabilities of the primary
SGSN cards used for Lawful Intercept. For more information on SGSN
redundancy, see “Redundancy capabilities” on page 4-1.
LISP card
The LI application supports 1:1 Warm redundancy. In the event of a hardware
failure, the LI application on the standby FP will takeover for the failing FP.
Data between the FPs for LI sessions is not synchronized so the newly
activated LI will send a RESET message to the Lawful Intercept Gateway
(LIG) and the LIG will in turn download current interception orders to the
new LI. The LI function serves the GSCs present on that shelf along with the
GSDs supporting PDP Contexts for the subscribers associated with the GSCs.
The target to associate path is not impacted due to an LI failure.

Subscriber Control Card

If the GSC cards support N + 1 redundancy, upon a GSC card failure, no
further monitoring takes place for IRI for the sessions that were active on the
failed GSC card, but the CC continues until the associated PDP contexts are
deleted. IRI resumes when a subscriber reattaches and CC resumes when the
subscriber reinitiates the PDP session.
If the GSC cards support 1:1 hot spare redundancy, upon a GSC card failure,
the hot spare standby card takes over and monitoring continues for both IRI
and CC.
Subscriber Data Card

The GSD cards support N + 1 redundancy. Upon a GSD card failure, the GSC
tears down all of the PDP Contexts associated with the failed GSD. This
forces any PDP session to be reinitiated (by the MS or the GGSN). Upon the
reestablishment of the PDP session, CC capture continues if the subscriber was
a target.
Security
The LI database is only accessible (provisioning or de-provisioning) to the
ADMF. It is invisible to SGSN authorized users.
There is no journalling for LI provisioning at the SGSN.
The LI component (CDL) can be provisioned by SGSN authorized users.
LI operation, administration and maintenance

The following sections describe aspects of Operation, Administration, and
Maintenance (OA&M) for the GPRS Lawful Intercept component hosted on a
SGSN. Note that no interface is provided to the SGSN operator (other than the
ADMF/DF), which would allow for the discovery of secure information such
as subscribers that are targeted for interception, address of the delivery
function, etc.
The LI attributes (alarms, provisioning attributes, and operational statistics)

that are defined in this section are common to both the UMTS and GPRS
implementations.
LI Provisioning
The Lawful Interception Access Function (LIAF) component is a root
component on the FP card. This component contains the LI provisionable
parameters. It also provides the means to display the operational and
statistical information maintained by the LI component.

The Sgsn and Gsc provisioning groups also contain provisioning parameters
that are related to LI functionality. For information about the LI provisionable
and operational attributes, refer to NTP 411-5221-060, SGSN Components.
LIAF OSI states

The LIAF component of the LI feature’s LISP card supports the OSI state
model. The LIAF OSI state indicates the overall health of the application. The
LIAF components on the GSC and GSD cards do not affect the OSI states of
these cards after card boot. See “OSI states” on page 7-56 for LIAF
component OSI state information.
Status attributes
Table 5-22 lists status attribute values supported for the LISP component.
Table 5-22
LIAF component status attributes
Status Attribute Supported Types Meaning
Alarm Status Alarm Outstanding An alarm condition exists

within the LIAF. Otherwise
it is empty.
Procedural Status Initializing LIAF initialization in

progress. Otherwise it is
empty.
Availability Status Degraded Operating in a degraded

state due to the maximum
number of targeted
subscribed all being
attached.
Control Status None
Standby Status None
Unknown Status Not used

Alarms
The LIAF component of the SGSN Lawful Intercept Server is responsible for
reporting certain operating failures as alarms. The reported alarms are sent to
a Management User, which is typically a command-line UI or a graphical UI.
Set/clear alarms are generated for resource problems and LIG communication
link failure.
For LIAF alarm descriptions, refer to NTP 411-5221-500, SGSN Alarms

Reference Manual.

Lawful Interception on the SGSN has the following restrictions and limitations:
• The AF supports the delivery of IRI and CC to only 1 DF at this time.
This can be enhanced to support more than one DF in future releases. The
ADMF and the DF may share the same IP address but need different
ports. Currently there is only one ADMF/DF pair associated with a
SGSN, and it is assumed that an ADMF/DF pair manages one target
interception database.
• IRI and CC message buffering or storage is not done at the SGSN.
• The LI application supports 1:1 Warm redundancy. In the event of a
hardware failure, the LI application on the standby FP will takeover for
the failing FP. Data between the FPs for LI sessions is not synchronized
so the newly activated LI will send a RESET message to the Lawful
Intercept Gateway (LIG) and the LIG will in turn download current
interception orders to the new LI. The LI function serves the GSCs
present on that shelf along with the GSDs supporting PDP Contexts for
the subscribers associated with the GSCs. The target to associate path is
not impacted due to an LI failure.
• The MSISDN used in Lawful Interception is an international number.
• A maximum of 32,000 entries are allowed in the LI Database on the LISP
card.
• A maximum of 3,000 active subscribers can be monitored at one time.
• If multiple agencies are tracking a single user, the Access Function will
send one set of interception information.
• If the ADMF connection is reset or the ADMF IP address or ADMF port
number is changed by an operator, it is the operator’s responsibility to
make sure that the LI Database entries are consistent with the new ADMF.
Operator should reset and re-configure the LI Database with new target
and interception information for the new ADMF.
• If more than 1 LISP card is provisioned, then the ADMF should make
sure that all of the corresponding LI Databases are identical to ensure that,
irrespective of which GSC/GSD card supports a given subscriber’s
session, the subscriber’s CC and IRI will be intercepted.

• If linkToLisp is changed to point to a new LISP card, operator must make

sure that the new LI Database is identical to the old one, to avoid losing
any IRI and CC packets from the previously monitored targets. Consider
the following scenario:
If a GSC card is switched from LISP1 to LISP2 while a subscriber is
attached and targeted, the subscriber’s IRI and CC messages would then
be forwarded to the LISP2 card. If the LISP2 card has no record of the
subscriber being activated as a target, the subscriber’s IRI/CC messages
would not be relayed to the DF (LISP2 would drop the messages).
• If the linkToPort is changed to point to another IP server, then the

connection to the ADMF/DF will get reset. Depending on how long it
takes to bring up the TCP connection to the LIG, there may be some
packet (IRI/CC) loss during reprovisioning of the new IP server.
• The SGSN Lawful Intercept Access Function component is supported
only on the General Server Processor card. As such, it is supported only
on the Passport 15K shelf.
• Lawful Interception is not supported for CAMEL messages
End user security functions 5

The SGSN supports the following end user security functions.
Authentication
The SGSN supports the GSM Authentication Procedure (see Figure 5-15) as
described in 3GPP TS 23.060, “Technical Specification Group Services and
System Aspects; General Packet Radio Service (GPRS); Service description;
Stage 2”.
Figure 5-15
GSM authentication procedure
The SGSN supports the storage and management of Authentication quintets.

Packet Temporary Mobile Subscriber Identity (P-TMSI)

To enhance confidentiality of the subscriber, the SGSN allocates the Packet
Temporary Mobile Subscriber Identity (P-TMSI), a 32-bit identifier, in the
following cases:
• Upon every successful Attach Procedure
• Upon every successful Intra-SGSN RAU Procedure
• Upon every successful Inter-SGSN RAU Procedure
• Upon every successful Periodic RAU Procedure
The P-TMSI is described in 3GPP TS 23.003, “Technical Specification Group

Core Network; Numbering, addressing and identification”.
P-TMSI Signature
The P-TMSI Signature is used by the SGSN to detect possible TLLI
Collisions. The P-TMSI Signature consists of 24-bits. A P-TMSI Signature
from the mobile equal to all 1’s indicates that no valid P-TMSI Signature is
available (See 3GPP TS 23.003.) See “P-TMSI enhancements” on page 5-82
for more information.
Ciphering
The ciphering function preserves the confidentiality of user data and
signaling across the radio channels and inherently protects the PLMN from
intruders. For more information, see 3GPP TS 23.060, “Technical
Specification Group Services and System Aspects; General Packet Radio
Service (GPRS); Service description; Stage 2”.
The SGSN supports ciphering (see Figure 5-15).
Ciphering is accomplished via hardware assist in the WPDS FP’s Field

Programmable Gate Array (FPGA). Failure of the hardware assist FPGA does
not disable the WPDS; It simply reverts to software based encryption
(although at reduced capacity). For more information about the WPDS, see
“Wireless Packet Data Server” on page 3-24 and “Hardware ciphering assist”
on page 3-25.
The SGSN supports the ciphering algorithms shown in Table 5-23.

Table 5-23
SGSN supported ciphering algorithms
Algorithm Hardware Software Comments
GEAV#1 Yes Yes
GEAV#2 No Yes Via PC04 patch

P-TMSI enhancements 5
Packet Temporary Mobile Subscriber Identity (P-TMSI) enhancements on the
SGSN reduce the impact on mobile end-users due to P-TMSI collisions. The
enhancements both reduce the statistical probability of a P-TMSI collision
occurring as well as reducing the impact of a collision that does occur.
A P-TMSI collision can occur when one mobile tries to attach to an SGSN
with a P-TMSI that is currently being used by another mobile. This scenario
is possible during an Attach (ATT), a Routing Area Update (RAU), or an
Inter-SGSN Routing Area Update (IRAU). It may also occur during MS
Initiated Detach (DET) under certain error scenarios.
The current specifications do not address the handling of a P-TMSI collision.

Currently, the specification defines a P-TMSI as a 32 bit structure. As a result,
the best case, theoretical probability of a P-TMSI collision is determined by
the number of currently attached subscribers on the SGSN and the number of
possible unique P-TMSIs available. Functionality on the SGSN reduces the
probability of a P-TMSI collision to approach the theoretical limit.
Additionally, the SGSN uses procedures to detect the collision via either the
use of the P-TMSI Signature or via Authentication. When a P-TMSI collision
is detected, the colliding mobile will be rejected.
GMM enhancements
GMM enhancements consist of detecting the mobile PTMSI collision and
rejecting the mobile with a cause of Cause #22 (Congestion) or Cause #9
(MS identity cannot be derived by the network) depending on the procedure
in which collision occurs. Upon detecting the collision, the GMM increments
the CAS counters to record the PTMSI collision based on the procedure in
which the collision occurred (see “Performance counters”, section “P-TMSI
collision” on page 7-26). Table 5-24 lists the possible P-TMSI collisions and
the default resulting rejection cause code.
Table 5-24
P-TMSI collision cause
P-TMSI Collision Reject Cause
ATT Cause # 22
RAU Cause #9
IRAU Cause #9
DETACH None (message ignored)

LLC enhancements
The TLLI is the LLC identifier derived from the P-TMSI. The LLC includes
enhanced TLLI management procedures to further reduce the possibility of a
TLLI collision.
• Separate tables used to distinguished between mobiles with foreign vs.
local TLLIs (this eliminates Collisions between Foreign and Local
TLLIs).
• Increase the number of bits within the TLLI used to uniquely identify a
mobile within a GSD.
P-TMSI signature
The SGSN uses P-TMSI signature IE that is defined in 3G TS 24.008 to
detect TLLI collisions. The P-TMSI signature is an optional 24-bit field that
contains an identifier that is allocated to the MS when the SGSN assigns a
new P-TMSI to the MS. The MS uses the P-TMSI signature in certain
signaling messages. The SGSN uses a unique combination of P-TMSI
Signature and P-TMSI to validate a mobile for messages that support P-TMSI
Signature. The SGSN assigns, unassigns and maintains a PTMSI signature
along with a PTMSI.
The authenticateSmPdus provisionable parameter controls whether the
SGSN authenticates the mobile upon receipt of an unciphered PDP Context
Activation request or PDP Context Deactivation request. If set to ENABLE,
the SGSN authenticates the mobile upon receipt of these messages.
Authenticating the mobile in this scenario prevents the SGSN from writing to
the wrong billing record. This scenario could occur due to a P-TMSI collision
or a rogue mobile attempting to use a P-TMSI assigned to a valid mobile.
Authenticating the mobile will result in additional messaging between the
SGSN and the HLR. If set to DISABLE, authentication is not performed on
each unciphered PDP context activation request and unciphered PDP context
deactivation request (note, regular 1 in N authentication is still in effect,
therefore, an authentication can still be performed in this case).
The default value of this parameter is DISABLE to match previous release

functionality. Setting this value to ENABLE will enhance the security of the
overall system at the expense of additional authentication messages on the Gr
interface.

This feature does not prevent PTMSI collisions. This feature provides the
ability to detect PTMSI collisions and prevent mobile context corruption
when a collision does occur. In addition to this it decreases the possibility of a
collision from occurring.

IP Header Compression 5
RFC 2507 IP Header Compression adds support for the RFC 2507 header
compression algorithm in addition to the existing RFC 1144 TCP/IP header
compression algorithm on the SGSN.
IP Header Compression provides an efficient, standards based

compression mechanism for multiple IP headers and TCP and UDP
headers over point to point links. Compression decreases header overhead
and reduces packet loss rate over lossy links, thereby reducing the bandwidth
needed for the headers and enabling higher quality of transmission. Typical
UDP headers (28 octets) or TCP headers (40 octets) can be compressed
down to 4-7 octets including the 2 octets for the UDP or TCP checksum. This
largely removes the negative impact of large IP headers and allows efficient
use of bandwidth on low and medium speed links. This feature also
incorporates a reduction in the packet loss rate and thus improves the
spectral efficiency and the revenue of operators.
Repair mechanisms for lost TCP/UDP packets

The RFC 2507 header compression scheme has mechanisms to update the
context at the decompressor and to detect or avoid incorrect decompression
when the lost packets occur. These mechanisms are very different for TCP
and non-TCP streams, and are described in the following sections.
Lost packets in TCP packet stream

Since TCP headers are compressed using the difference from the previous
TCP header, loss of a packet with a compressed or full header will cause
subsequent compressed headers to be decompressed incorrectly because the
context used for decompression was not incremented properly. There are two
TCP repair mechanisms that retransmit the discarded segment. The
compressor peeks into the TCP headers to detect when TCP retransmits.
The “twice” algorithm

The decompressor can compute the TCP checksum to determine if its context
is not updated properly. If the checksum fails, the error is assumed to be
caused by a lost segment that did not update the context properly. The delta
of the current segment is then added to the context again on the assumption
that the lost segment contained the same delta as the current. By
decompressing and computing the TCP checksum again, the decompressor
checks if the repair succeeded or if the delta should be applied once more.

Header Requests
When the decompressor fails to repair the context after a loss of the packet
using the “twice” algorithm, the decompressor may request a full header from
the compressor. This is possible on links where the decompressor can
identify the compressor and send packets to it.
Lost packets in UDP and other non-TCP packet stream

Incorrectly decompressed headers of UDP packets and other non-TCP
packets are not so well-protected by checksum as TCP packets. There are no
sequence numbers that become off-by-k, where k is the size of the lost
segment, and virtually guarantees a failed checksum. Compression slow-
starts and periodic header refreshes are used as the repair mechanisms for
UDP and other non-TCP packet streams.
Compression Slow-Start
To allow the decompressor to recover quickly from loss of a full header that
would have changed the context, full headers are sent periodically with an
exponentially increasing period after a change in the context. This technique
avoids an exchange of messages between compressor and decompressor.
Such exchanges can be costly for wireless mobiles as more power is
consumed by the transmitter and delay can be introduced by switching
between sending and receiving.
Periodic Header Refreshes

To avoid losing too many packets if a receiver has lost its context, there is an
upper limit, rfc2507MaxPeriod, on the number of non-TCP packets with
compressed headers that may be sent between header refreshes. If a packet is
to be sent and rfc2507MaxPeriod compressed headers have been sent since
the last full header for this packet stream was sent, a full header must be sent.
To avoid long periods of disconnection for low data rate packet streams, there
is also an upper bound, rfc2507MaxTime, on the time between full headers in
a non-TCP packet stream. If a packet is to be sent and more than
rfc2507MaxTime seconds have passed since the last full header was sent for
this packet stream, a full header must be sent.

OAM
(OAM) information for IP Header Compression.
Fault management
The RFC 2507 IP Header Compression feature generates a warning alarm for
the provisioning attribute maxHeaderCompressionEntities when the memory
pool for header compression entities reaches 100% of usage. The alarm is
cleared when the level lowers to 90%.
The following lists the provisioning attributes that are renamed or added by
this feature:
The provisioning attribute maxHeaderCompressionEntities and
allowableCompressionAlgorithms are added to the component Gsd/#
GprsSubNetworkDataConvergenceProtocol.
The provisioning attributes, rfc2507MaxPeriod, and rfc2507MaxTime are

added to the component GprsSubscriberDatapathCp. These 2 attributes
cannot be changed in this release.
The following three RFC 2507 TCP/IP and UDP/IP header compression
parameters are defined as data members in the implementation instead of
defining them as provisioning attributes:
• MAX_HEADER - This parameter indicates the largest header size in
octets that may be compressed. The implementation supports negotiation
down to 60 bytes, and the header size will not go beyond 96 bytes. The
default value is 96 bytes.
• TCP_SPACE - This parameter indicates the maximum Context Identifier
(CID) value for TCP. The implementation supports negotiation down to
3, and the maximum value for CID will not go beyond 7. The default
value is 7.
• NON_TCP_SPACE - This parameter indicates the maximum CID value
for non-TCP. The implementation supports negotiation down to 3, and
the maximum value for CID will not go beyond 7. The default value is 7.

The following new groups are added by this feature:
The groups GprsSndcpHeaderCompressionOp, GprsSndcpRfc2507Op and
GprsSndcpRfc2507Stats are added to the component Gsd/#
GprsGsdSessionContext.
The following operational and collected statistical attributes are added by this
feature:
The following operational attributes are added to the component Gsd/#
GprsSubNetworkDataConvergenceProtocol; msCompressionReqRfc1144,
msCompressionFailRfc1144, msCompressionSuccessRfc1144,
nwkCompressionPreallocFailRfc1144, nwkCompressionSuccessRfc1144,
msCompressionReqRfc2507, msCompressionFailRfc2507,
msCompressionSuccessRfc2507, nwkCompressionPreallocFailRfc2507,
nwkCompressionSuccessRfc2507, currentRfc2507Entities and
peakHeaderCompressionEntities.
The total number of compression entities used by mobiles can be derived by

adding msCompressionSuccessRfc1144 + nwkCompressionSuccessRfc1144
+ msCompressionSuccessRfc2507 + nwkCompressionSuccessRfc2507.
The following operational attribute is added to the component Gsd/#

GprsGsdSessionContext; negTypeOfHeaderCompression.

RFC 2507 IP Header Compression has the following restrictions/limitations:
• Only IPv4 PDP type is supported for RFC 2507 IP Header Compression.
• Either RFC 1144 TCP/IP header compression algorithm or RFC 2507
TCP/IP and UDP/IP header compression algorithm may be selected for a
PDP context. The SGSN does not support both types of compression for
a PDP context at the same time.
• An NSAPI is removed from the Applicable NSAPIs of the compression
entity, which means that NSAPI no longer uses a compression entity. If
that NSAPI shares the compression entity with other NSAPIs due to a
PDP context modification, it is not removed.
• Mobiles devices must support RFC 2507 for UDP/IP header compression
to take place.

MS Purge 5
The SGSN sends the PurgeMS message to the HLR when the Mobility
Management (MM) contexts of an inactive mobile are deleted in the SGSN.
This can reduce messaging on the Gr, Gd, and Gn interfaces. However, before
the contexts are removed from the SGSN and the PurgeMS message is sent,
the mobile contexts may be kept for a period of time after detaches. If the mobile
reattaches to the SGSN within a provisionable period of time, the previous
context information is retrieved.
The catalysts for deleting a context from the SGSN and triggering the MS Purge
message to the HLR are:
• After a periodic audit (scheduled through operator provisioning). This
procedure deletes the inactive contexts older than the provisioned time
period.
• After each explicit detach (if provisioned). The power off detach is an
example of an explicit detach.
Note: Implicitly detached mobiles, for example, Mobile Reachable Timer
Expiry related detaches, can be handled through the MS Purge Audit.
• After the operator explicitly initiates a purge for a specific detached

mobile IMSI using the clear command (see “Clearing an inactive mobile”
on page 7-34). The operator can determine if a mobile is detached by
viewing the dynamic data through CAS.
• After an inactive context is deleted/reused during the course of SGSN
context management operations.
Note: The maximum number of inactive mobiles retained is set to 20% of
the value provisioned for maxAttachedSubscribers. Once these containers
are exhausted, inactive contexts are purged based on time of inactivity.
Context deletions that occur after the reception of Cancel Location message,
for a particular mobile, do not result in an MS Purge since the HLR has
already moved the SGSN association for this mobile to another SGSN.
MS Purge provisioning
MS Purge provisioning parameters are under the Sgsn Gsc subcomponent (on
the CP). There are three provisionable parameters to control the purge
procedure:
• msPurgeFunction—enables the purging function for the SGSN.
• purgeOnExplicitDetach—determines whether mobiles are purged upon
explicit mobile detach.
• purgeMinimumInactiveMobileAge— specifies the context retention
interval after which inactive mobiles are purged.

If the provisionable parameter msPurgeFunction is set to disabled, no purge

message is sent from the SGSN to the HLR. Only context reuse and operator
directed purge of the mobile on the SGSN without any external messaging
can take place. All other purging functionality is disabled. If
msPurgeFunction is enabled, context reuse and operator directed purging
functionality (see “Clearing an inactive mobile” on page 7-34) are enabled. In
addition, the other purging provisioning becomes meaningful:
• The PurgeOnExplicitDetach parameter allows the Purge MS message to

be sent when the user initiates detaches (for example, power off detach).
Under the Tcap Map component, the pmsSanityTimer specifies the amount of
time the Tcap Map stack waits for the PurgeMS acknowledgments from HLR.
Note: For more information about the MS Purge provisionable

parameters, refer to NTP 411-5221-060, SGSN Components.
If mobiles are too frequently purged, either due to explicit detach purging or
short retention period purging, there can be many PurgeMS messages sent to
the HLR. This could be counter-productive if those mobiles quickly
reattached to the SGSN, requiring full Attach procedure messaging. If
mobiles are not purged frequently enough, the HLR could believe that a
mobile is still at the operator SGSN. If any information needs to be sent to the
mobile, the HLR could waste network capacity by needlessly messaging the
old SGSN.
MS Purge statistics
Several areas of statistics maintain MS Purge data:
• Group Gsc Statistics maintains operating statistics for MS Purge.
• Group Gsc MapClient Statistics maintains statistics for MS Purge
messaging.
• Attribute Tcap Map pmsTimeouts tracks expiries of the pmsSanityTimer
attribute.
The statistics are incremented only when the MS Purge functionality is

enabled through provisioning. For details on these statistics, refer to NTP
411-5221-060, SGSN Components.

• The context data deletion occurs when the PurgeMS message is sent out.
The PurgeMS Ack message only affects counters.
• The SGSN ignores conditional Freeze P-TMSI indicator in MS Purge
acknowledgement from HLR.
• Granularity of minimum age of inactive context is1 hour. This is based on
DMS-MSC precedent for the MS purge functionality.

• For MS Purge audit, an internal message throttling system is active so that

the overall Gr Interface Capacity is not overloaded. This also limits the
SGSN CPU impact. PurgeMS messages are sent out in short bursts at
regular intervals until all inactive context purging is complete for that
hour.
• Catastrophic failures (uncontrolled erasure of data) in the SGSN do not
generate PurgeMS messages. Non-redundant card failure (GSC) will
cause contexts to be lost without the transmission of MS purge (i.e. reset
of the GSC card).
• The maximum number of inactive mobiles retained is restricted to 20% of
the value provisioned for maxAttachedSubscribers. This is calculated on a
per FP basis for each of the GSC cards.

Accounting 6-1
Accounting 6
Charging information in the UMTS/GPRS network is collected for each
Mobile Station (MS) by the SGSNs that are serving the MS. The SGSN
transfers collected charging information to the Charging Gateway Function
(CGF) periodically, as provisioned by the network operator. The CGF acts as
a storage buffer for real-time charging information collection, and provides
the charging information to the operator’s Billing System (BS). SGSN
accounting is compliant to the GTP’ protocol (defined in 3G TS 32.015) and
uses the Ga interface. Figure 6-1 illustrates the GPRS charging architecture.
Note: The terms accounting, billing and charging are used

interchangeably.
Figure 6-1
UMTS/GPRS charging overview
SGSN Gn GGSN
Ga Ga
S-CDR G-CDR
M-CDR
CGF
S-SMO-CDR
S-SMT-CDR
CDRs
Billing
System
Between the GGSN and the CGF, the Ga interface allows accounting for data
sent and received on the Gi interface. Between the SGSN and the CGF, the Ga
interface allows accounting for mobility events, Short Message Service
transactions (SMS is available only in GPRS), and data sent and received
between the mobile and the SGSN. Hence, the data counts on the GGSN and
on the SGSN may not be the same.

6-2 Accounting
SGSN Accounting Server (SAS) 6

The SGSN Accounting Server (SAS) is the entity that provides the SGSN
billing functionality. The SAS is responsible for:
• Receipt and recording of traffic data volume updates
• All aspects of Call Detail Record (CDR) handling
— SGSN CDRs (S-CDRs), Mobility Management CDRs (M-CDRs),
SGSN delivered Short message Mobile Originated CDRs (S-SMO-
CDRs) and SGSN delivered Short message Mobile Terminated CDRs
(S-SMT-CDRs)
— Partial records
— Storage and management of CDRs in non-volatile store
• Recording of routing area updates
• Protocol support
— ASN.1 formatting of CDRs prior to transfer to the CGF
— GTP’ protocol support for the transfer of CDRs to the CGF
— Support for a secondary CGF in case of primary CGF failure
• OAM Support
— Receipt and processing of provisioning data
— Generation of alarms and logs as appropriate
— Generation of billing statistics
SAS hardware
The SAS application is implemented on the Passport 15000-VSS 2 port
General Processor with Disk (2pGPDsk). The 2pGPDsk has a 20 gigabyte
hard drive mounted to its motherboard that is used to store billing data.
The 2pGPDsk FP supports its own 100BaseT LAN connection on the

external faceplate. Billing records are therefore spooled directly from the
SAS FP to a downstream billing server via the ATM I/O interface or the
100BaseT port of the 2pGPDsk FP. Ethernet Hot Switchover is not supported.
For more information about the 2pGPDsk, refer to Chapter 3, “Hardware
description”. Refer to “Special considerations for I/O routing” on page 2-26
for I/O options.
The SAS application may co-exist with the Lawful Interception (LI)
application on the same FP. Only one SAS application may be provisioned
per FP.

Accounting 6-3
Multiple SAS cards per shelf

Multiple primary SAS cards can be concurrently active in a common Passport
15000 shelf. In-service activation of up to 4 active SAS cards is supported.
Each card must be redundant in a 1:1 configuration. For more information
about SAS redundancy, see “Node failure processing and SAS” on page 6-25.
Billing traffic load is shared across the cards, thereby mitigating the risk of
billing record loss. SAS cards can be provisioned to use different CGFs or the
same CGF.
All SAS cards must reside on the same shelf as the corresponding Subscriber
Control (SC) cards. For any given SC card that is provisioned, subscribers are
distributed among the available SAS cards on the shelf. When a mobile
attaches, the SC card assigns it to a SAS instance. It will choose the one with
the fewest subscribers to achieve some basic load balancing. As a result, the
subscriber load is naturally distributed across the active SAS cards
provisioned on the shelf.
Note: “Subscriber Control (SC) card” refers to both GPRS Subscriber

Control (GSC) and UMTS Subscriber Control (USC) cards.
Provisioning multiple SAS cards

In the GPRS6.0/UMTS4.0 release, the “Accounting” subcomponent under
(U)Sgsn is obsoleted to logically arrange all the provisionable accounting
attributes in one group under one component. All the provisionable attributes
under this subcomponent are moved to the existing group “ Sas Prov” under
the Sas/x component. Also the names of the following provisionable
attributes are changed to more accurately describe their function.
Old Name New Name
updateInterval cdrUpdateInterval
cdrTransferTime drtResponseTimeout
cdrRetries drtRetries
The system validates that the value of the following Sas component
provisionable parameters is the same on all other Sas components on the shelf:
• cdrCapture
• locationBasedBilling
• roamerCapture

6-4 Accounting
The system validates that the values in the following attributes are the same
across all provisioned instances of the SAS component. These attributes under
the SAS components must be provisioned with the same values as these
attributes under the USD or GSD component. (These attributes are described
in “S-CDR partial record common provisioning” on page 6-16).
• scdrPartialRecordInterval
• scdrMaxContainers
• specificDailyScdrPartial
• dailyPartialTimeOfDay
Provisionable attributes are automatically transferred from the U/Sgsn Acct

component to the Sas component when upgrading. This prevents the operator
from having to reprovision all the attributes on the first SAS card.
In GPRS6.0/UMTS4.0, two new provisionable attributes, transferTimeOfDay

and cdrUpdateTimeOfDay, are available on each Sas/x component.
Introduction of these two attributes provides more precise control over the
CDR transfer and update processes. The specific time of day at which SAS
runs these processes is now configurable. For example, setting the
transferTimeOfDay to 1425 minutes (i.e. 11:45 P.M.) and transferInterval to
1440 minutes (0:00 midnight) would cause SAS to transfer spooled CDRs to
the CGF once a day at 11:45 P.M.
diskUsage, diskFreeSpace and diskCapacity are three new operational

attributes that are available to provide the operator with a view of the current
disk usage. These statistics are available on each Sas/x component.
The timeOffset attribute was not moved to the “Sas/x” component when the
other attributes under the “(U)Sgsn Accounting” subcomponent were moved.
The offset value populated in the CDRs will be the system time offset value
provisioned for the passport under the Time component.
For complete descriptions of all SAS provisionable and statistics attributes,

refer to NTP 411-5221-060, SGSN Components.
Standards support
SGSN Billing supports 3G TS 32.015 v3.2.0 and v3.6.0. Note that only one
version is used at a time (that is, CDRs output from SAS follow either the
3.2.0 format or the 3.6.0 format). The version supported is selected via
provisioning data, and no card reset is required for the change to take effect.

Accounting 6-5
Call Detail Records 6

The Nortel SGSN can create the following CDRs. For detailed information
about SGSN CDRs, including CDR format, refer to NTP 411-5221-204, SGSN
Call Detail Record (CDR).
• SGSN CDRs (S-CDRs)—Used to collect charging information related to
the packet data information for a mobile in the SGSN. An S-CDR is
opened for each activated PDP Context, and contains the uplink and
downlink data volume counters and the PDP Context duration.
• Mobility Management CDRs (M-CDRs)—Used to collect charging
information related to the mobility management of a mobile in the SGSN.
An M-CDR is opened for each mobile upon attach, and contains the
mobile’s location information.
• SGSN delivered Short message Mobile Originated CDRs (S-SMO-
CDRs)—Used to collect charging information related to the transfer of
short message service transfers from the mobile to the SGSN. No active
PDP Context is required when sending short messages, and data volume
counters in the SGSN are not incremented.
• SGSN delivered Short message Mobile Terminated CDRs (S-SMT-
CDRs)—Used to collect charging information related to the transfer of
short message service transfers from the SGSN to the mobile station. No
active PDP Context is required when sending short messages, and data
volume counters in the SGSN are not incremented.
Note: SMS messages are sent over the circuit domain in the Nortel
UMTS network. Therefore, the SGSN/UMTS does not generate S-SMO-
CDRs or S-SMT-CDRs.
Attribute Sas cdrCapture specifies which of these CDRs are generated.
Operations performed on CDRs

The Accounting Server receives notification of events (attaches, activates,
routing area updates, etc.) from various SGSN software entities. These event
notifications cause the Accounting Server to perform operations on the
corresponding Call Detail Record. The operations that can be performed on
CDRs are open (create), update, and close.
Open
An open operation results in the creation of a CDR in RAM. M-CDRs are
stored in RAM for as long as the mobile is attached to the GPRS/UMTS
network through the serving SGSN. S-CDRs are stored in RAM for as long as
the session is active in the serving SGSN. SMS CDRs are not stored long-
term in RAM; they are immediately closed and written to non-volatile store
(hard disk).

6-6 Accounting
Update
An update operation is performed on an open S-CDR or M-CDR. This
operation results in the addition of a new container to the CDR, or the
updating of exiting data already captured in the CDR.
The SAS initiates the traffic volume update procedures for open S-CDRs.
This involves requesting updated volume counts for Data Volume Counts
from each active PDP Context at the time interval provisioned in Sas
cdrUpdateInterval, and updating the S-CDR with the returned traffic data
volume counts.
In certain conditions, dependent upon provisioning information, update

operations could result in the generation of partial records (see “S-CDR
partial records” on page 6-8 and “M-CDR partial records” on page 6-17 for
information on partial records).
Close
A close operation is also performed on an open S-CDR or M-CDR, or on a
new SMS CDR. This operation results in the S-CDR or M-CDR being moved
from RAM to the end of the current “Closed” file. The S-CDR or M-CDR is
then removed from RAM. For SMS CDRs, the close operation is the act of
both creating the new CDR and appending it to the end of the “Closed” file in
one single operation. SMS CDRs are not stored long-term in RAM.
S-CDRs or M-CDRs are stored on hard disk until they are sent to the CGF,
based on the setting of Sas transferInterval. Upon closure of an S-CDR,
another S-CDR in the form of a “subsequent” S-CDR is opened in memory to
maintain the billing information of the still-activated PDP context. The
subsequent S-CDR contains the same Charging Id as the closed S-CDR so the
records can be later aggregated by the operator’s downstream Billing System.
Likewise, upon closure of an M-CDR, another M-CDR is opened in memory
to maintain the billing information of the still-attached mobile.
For all CDRs, the network operator may request that closed billing records be
sent to the CGF without delay by provisioning attribute Sas transferInterval.
In this case, the closed CDRs are written to hard disk to protect the data in
case of CGF failure or if retransmission is necessary, and then they are written
to the CGF with as minimal delay as possible. This charging characteristic
may be described as Near Hot Billing.
Causes for closing CDRs

In TS 32.015, the causes for closing CDRs have been defined by the following
parameters:
• Normal release
• Abnormal release

Accounting 6-7
• Volume limit
• Time limit
• SGSN change
• Maximum change conditions
• Management intervention
• CAMEL Init Call Release
In the present release, partial records are created from data volume limit,
duration (time) limit, SGSN change, tariff time change, and maximum
changing conditions. Management Intervention is currently not used to
indicate OA&M intervention, but it is used in support of Location Based
Billing and specific daily partial records. The abnormal release is generated
due to system failures within the SGSN or GGSN nodes, network failures,
GGSN reset, etc. All PDP Context Releases, GPRS Detaches, and other
UMTS/GPRS events are classified as “normal” in SAS CDRs.
Daylight Savings Time interaction

The SAS reacts to Daylight Savings Time (DST) adjustments. Each
timestamp within CDRs reflects the local time of the SGSN at the time of that
event, including the system offset at that time.
An example would be a record that is opened prior to DST, a Tariff Time

Change Trigger (TTCT) event after a DST change and the subsequent CDR
closure. The record opening time stamp will show a pre-DST time and the
TTCT changeTime timestamp will be a post-DST time stamp with the
changed offset. The duration calculation will recognize the time change event
and provide the actual elapsed time that the CDR was open.
Modifications to system time that are not done with system time offset will
affect the CDR time stamps and duration in an unpredictable manner.
CDRs and Subscriber Control Card Reset

The SAS card receives a notification when any SC card is reset. When the
SAS card is notified of the SC card reset or failure, the SC card failure
notification time is stored and the SAS card starts a process to identify all
CDRs that require abnormal closure. For each associated context on the SC
card that is reset, a CDR on the SAS card is closed with an abnormal closure
reason and with a duration relative to the failure notification time. For each
closed CDR a record is written to disk and subsequently transferred to the
CGF in the appropriate transfer interval. If required, message throttling is
employed to avoid system impacts of closing a large number of CDRs all at
once upon an SC card reset.

6-8 Accounting
S-CDR partial records 6

An ongoing PDP Context may have several partial records generated in real-
time. Upon certain triggers, an S-CDR is closed and a new S-CDR opened
with the same Charging ID/GGSN Address but with a different Record
Sequence Number. The downstream CGF or Billing System is responsible for
aggregating multiple S-CDRs for the same PDP Context.
An S-CDR record is closed and a new partial record opened upon the following
conditions:
• Data Volume Limit
• PDP Context duration limit
• Maximum number of charging condition changes
• Management Intervention
The following billing feature triggers traffic volume updates:

• Tariff Time Change
• PDP Context QoS modifications
The following billing features trigger generation of partial S-CDRs with closure
reason Management Intervention:
• Location Based Billing
• Specific Daily Partial
Data Volume Limit

Data Volume Limit (DVL) generates partial S-CDRs when a PDP Context
transfers an operator-provisioned limit of combined uplink and downlink user
traffic. The value of this feature is that it reduces the potential for billing data
loss by generating partial records based upon the operator’s risk tolerance
according to how high or low the data volume threshold is set.
SGSN is provisioned with attribute Sgsn dataVolumeLimit (minimum of 128

Kilobytes, maximum of 5 Megabytes) in 1 Kilobyte increments. If
dataVolumeLimit is set to disabled (the default), then a 2-gigabyte volume
limit is used for the volume counters, which means approximately 2 billion
bytes of data would need to be sent (in one direction) to trigger the data
volume overflow. (This is not expected to occur.)
While processing each Packet Data Unit (PDU), the SGSN compares the
current combined uplink and downlink traffic volume. If the value is greater
than the specified threshold, SAS updates the appropriate S-CDR and
generates a partial record with reason, “Data Volume Limit.” DVL partial
records are created with volume counts of no more than one packet more than
the provisioned value.

Accounting 6-9
PDP Context duration limit

The PDP Context duration limit condition is triggered by the SD cards. SAS
is notified when the interval provisioned in Sas/Gsd/Usd
scdrPartialRecordInterval has expired for an individual session. At that point
SAS generates duration limit partial records for the S-CDRs that have been
opened longer than the provisioned time period.
The S-CDR PDP context duration period can be set to noTimeLimitPartials,

which disables generation of time duration limit S-CDR partial records, or to
a time period between 15 minutes to 24 hours, in 15-minute increments. This
functionality allows S-CDRs for Contexts that have been open for a long
period of time to be closed, and the billing information sent downstream in
order to prevent loss of data. A subsequent S-CDR, with an incremented
Record Sequence Number, is left open in the Accounting Server to continue
servicing the active PDP Context.
Time based partial records are created with durations within a small tolerance
of the provisioned value. The exception to this is any time-based partial
records created subsequent to a Specific Daily S-CDR partial (see “Specific
Daily Partial” on page 6-13). These subsequent records may have durations
that exceed the provisioned time interval by several minutes.
Time based partial and DVL partial record interaction

Figure 6-2 illustrates the interaction of the Time-Based partial record and
DVL partial record creation if both features are active. If DVL is reached
before the expiration of the provisioned time interval, the partial record is
created with a closure reason indicating volume limit. The time interval is
restarted for the next partial record at the time when the previous partial
record is created.

6-10 Accounting
Figure 6-2
Time based and DVL partial record creation interaction
Time & Volume Partial CDR Operation

Partial Time Based CDR Interval – 30 Minutes (example)
(sdScdrPartialRecordInterval )
Volume Limit – 0.5M (example)
(dataVolumeLimit )
Time
t=0 15 30 45 60 75 90 105 120 135 150 165 180 195 210

1Mb
Volume .5 Mb
t=8
TB VB TB TB VB TB TB
t=38 t=59 t=89 t=119 t=135 t=165 t=195
Session Started t=8

Trigger:
TB – Time Based
VB – Volume Based
NOTE: Creation of volume based partials reset the starting time for
time-based partials.
Maximum number of charging condition changes

S-CDRs are provisioned in Sas/Gsd/Usd scdrMaxContainers with a
maximum number of traffic data volume containers. When this maximum
value is reached, a partial record is generated for the S-CDR. For S-CDRs,
traffic data volume containers are added when the QoS of the PDP Context
dynamically changes or a tariff time change event occurs. Both the QoS
change and Tariff Time Change triggers are supported. If an S-CDR achieves
the provisioned maximum number of traffic data volume containers, a partial
record is created with the reason of “Maximum number of charging condition
changes”. From 1 to 10 Change of Charging Condition containers can be
provisioned.
Management Intervention
The Management Intervention cause for partial record generation of S-CDRs
is used in conjunction with the Location Based Billing and Specific Daily
Partial features.

Accounting 6-11
Tariff Time Change

The Tariff Time Change Trigger (TTCT) enables the down stream billing
system to use different billing rates for different time periods. Upon receiving
operator provisioned tariff period change events, SAS performs the following
actions for all active PDP contexts:
• The existing data volume container for a given context is closed with
updated volume counts and with close reason “Tariff Time Change”.
• A new traffic data volume container is added to the S-CDR.
In addition, a partial S-CDR is generated if the maximum number of traffic

volume containers is reached.
TTCT events can be configured using the existing Time Of Day Accounting
(TODA) provided by Data Collection System (DCS) in the Passport base
software. The network operator can provision multiple tariff periods for
packet services on GPRS and UMTS networks.
TTCT operates as follows:

1. TTCT is enabled with attribute Sgsn tariffTimeChangeTrigger
(ttcTrig). The Passport configuration management system validates that
collection times for TODA are no closer than 4 hours and that no more
than 6 periods are provisioned.
2. SAS updates the volume counts and opens a new volume container
whenever a tariff time change occurs.
Traffic data volume containers

The definition of an S-CDR defines a “list of traffic data volumes” which
consists of one or more containers. Table 6-1 is an example of a list, which
has three containers (sets of volume counts) caused by one QoS change and
one tariff time change. This example is taken from the billing specification,
3GPP TS 32.015 V3.6.0 (2001-06) Charging and Billing, to illustrate the
effect of Tariff Time Change Trigger events.
Table 6-1
Example list of traffic data volumes
QoS Requested = QoS1

QoS Negotiated = QoS1 QoS Negotiated = QoS2
Data Volume Uplink = 1 Data Volume Uplink = 5 Data Volume Uplink = 3

Data Volume Downlink = 2 Data Volume Downlink = 6 Data Volume Downlink = 4
Change Condition = QoS Change Condition = Tariff Change Condition = Record

change change closed
Time Stamp = TIME1 Time Stamp = TIME2 Time Stamp = TIME3Change
Condition

6-12 Accounting
First container includes initial QoS values and corresponding volume counts. Second container includes
new QoS values and corresponding volume counts before tariff time change. Last container includes
volume counts after the tariff time change. Following total volume counts can be itemized (tariff1 is used
before and tariff2 after the tariff time change):
Container
QoS1+Tariff1 uplink = 1, downlink = 2 1
QoS1 uplink = 1, downlink = 2 1
QoS2 uplink = 8, downlink = 10 2+3
Tariff1 uplink = 6, downlink = 8 1+2
Tariff2 uplink = 3, downlink = 4 3
[T.S. 32.015]
The objective is to create one closed container per active PDP context per
tariff time period so that the downstream billing system can apply different
tariffs for the volume counts provided by the SGSN for the distinct tariff time
periods.
Due to the amount of time it takes to update volume counts for all active PDP
sessions, especially those that are idle, there may be a delay of several
minutes before SAS updates its volume counts and creates a new time change
container for every active S-CDR.
Because TTCT introduces multiple data volume containers per S-CDR, the
configurable attribute Sas/Usd/Gsd scdrMaxContainers enables the operator
to specify the maximum containers within an S-CDR before a partial record is
generated. According to the 3GPP Charging and Billing Specification, all the
active PDP contexts are not required to have exactly the same time stamp due
to same tariff time change (variance of the time stamps is traffic load
dependent).
TTCT interactions and dependencies

The following features involve co-ordination of the TTCT provisionable
parameters and the use of the container changes made in TTCT.
• The Data Volume Limit (DVL) feature interacts with TTCT by
accommodating multiple containers when a partial record is generated.
The DVL feature implements the operational attributes and collected
events for partial records and containers, including TTCT specific
counters.

Accounting 6-13
• PDP Context Modification enables SAS to respond to changes in QoS.

PDP Context modification depends on the multi-container functionality
added by TTCT to set new QoS values when a QoS change occurs. Both
the Negotiated and Requested QoS should be present in the first container.
After that, the Negotiated QoS is included only if the previous container
was closed due to a “QoS Change”.
TTCT provisioning
The following component attributes are used to provision TTCT:
• Sas/Gsd/Usd Acct scdrMaxContainers—allows the operator to determine
the maximum container limit per S-CDR. When this limit is reached, a
partial record is generated. The value used for the maximum number of S-
CDR containers will determine how often S-CDRs are closed and ready
for transfer as well as the number of S-CDRs transferred to the CGF.
• Sgsn tariffTimeChangeTrigger—enables the Tariff Time Change Trigger
functionality. TTCT must be enabled for each SGSN root component
configured within a Passport. All shelves within the SGSN must have this
attribute provisioned with the same value. The enabling of this value
allows the verification of restrictions specific to TTCT placed on the
TODA events configured.
In addition, collection times for Time of Day accounting to take place must be
provisioned (see “TODA provisioning” on page 6-15). The TODA events are
used to indicate Tariff Time Changes. The USD/GSD and SAS register to
receive the timed events. All time events provisioned on SGSNs containing
USD/GSD and SAS cards should be exactly the same.
Location Based Billing

A Nortel proprietary feature called Location Based Billing (LBB) enables the
network operator to provision SGSN billing to generate partial S-CDRs based
upon routing area changes.
Note: This feature is disabled by default.
LBB is provisioned in attribute Sas locationBasedBilling. When enabled,

every S-CDR contains only the traffic data volume counts for a single routing
area. This allows the operator to bill based on data volume in a geographic
region, if desired. Note that the use of LBB increases the number of partial S-
CDRs generated by the SGSN (dependent upon MS mobility characteristics).
As there is no specific partial record closure reason for LBB in the 32.015
standard, this feature employs the “Management Intervention” reason.
Specific Daily Partial

A partial S-CDR record can be created for each active session at a specified
time of day. The Specific Daily S-CDR feature is beneficial to customers that

6-14 Accounting
require a daily billing event. This facility is based on the basic Tariff Time
Change (TTCT) feature. All the provisioning required for any TTCT event
must be provided for the Specific Daily S-CDR time. The time specified for
the Specific Daily S-CDR partial must be one of the provisioned Time of Day
Accounting (TODA) times.
In addition to the TODA time, the Specific Daily S-CDR feature must be
enabled in attribute Sas/Gsd/Usd specificDailyScdrPartial and the specific
time of day for the partial provisioned in attribute Sas/Gsd/Usd
dailyPartialTimeOfDay. This is required to distinguish this event from all
other TTCT events. The reaction to this event is different from a normal
TTCT event in that a partial record is created even if the number of traffic
volume containers is less than the provisioned scdrMaxContainers.
The Specific Daily S-CDR partial record may not appear on the SAS hard drive
for up to several minutes after the specified time of day. The following is a list
of specifications for this feature:
• The container changeTime (the time when the S-CDR is closed) is exactly
Specific Daily S-CDR time of day.
• The volume counts reflect only data transmitted/received prior to Specific
Daily S-CDR time of day.
• The record closing reason for this partial is Management Intervention.
• The subsequent S-CDR has a record opening time of exactly Specific
Daily S-CDR time of day.
The first S-CDR created for each session following the specific daily S-CDR
partial due to timeLimit may have a duration that exceeds the partial record
interval by several minutes. The variation in duration is completely dependent
on system load.
The example in Figure 6-3 uses midnight for the specified time of day.

Accounting 6-15
Figure 6-3
Specific Daily S-CDR partial record example
Midnight CDR Operation

Trigger:
Partial Time Based CDR Interval – 30 Minutes (example) TB – Time Based
Volume Limit – 0.5M (example) (sdScdrPartialRecordInterval
)
(dataVolumeLimit ) VB – Volume Based
MB – Midnight Based
Time Midnight
t=0 15 30 45 60 75 90 105 120 135 150 165 180 195 210

1Mb
Volume
.5 Mb
Example 1:
Active Data
Session at
Midnight Start VB VB TB TB TB MB TB
t=8 t=35 t=57 t=87 t=117 t=147 t=172 t=202
The duration of any
t=175 S-CDR following a
daily cutover partial
will vary. The
duration is
Example 2: dependent upon
Idle Data system load.
Session Example shows 33
at Midnight minutes.
Start VB VB TB TB TB MB TB
t=8 t=35 t=57 t=87 t=117 t=147 t=172 t=205
For provisioning shown in this example, time-based partial S-CDRs

following midnight will have duration longer than 30 minutes for
those sessions which were idle at midnight. Duration is load
dependent.
TODA provisioning
Passport Base software includes a Data Collection System that the Tariff
Time Change and Specific Daily partial features use to provide timed events
to USD/GSD and SAS. The DCS Collector’s subcomponent “Accounting”
has an attribute, collectionTimes, which is used to configure the times for the
Tariff Time period changes. The tariff times may not be closer than 4 hours
and there can be no more than 6 distinct periods provisioned.
For information about configuring TODA, refer to NTP 241-5701-650,

Passport 7400, 15000, 20000 Accounting Fundamentals.
Guidelines
Determination of appropriate TODA provisioning should be made based on
the traffic patterns of each node. It is recommended that TODA periods not
begin or end during peak periods to avoid flood of messages between
components (USD/GSD and SAS).

6-16 Accounting
Setting of the maximum S-CDR container value should reflect the traffic and
the desired interval at which S-CDRs are transferred to the billing system. If
the value is set very low there may be a large number of partial records
created. If the value is set too high the partial records may not be created in a
timely manner.
S-CDR partial record common provisioning

Several facets of the billing functionality require that the Subscriber Data
(SD) card(s) and the SAS card(s) have identical provisioning. A common
group, BillingCommonProv in the Sas, Usd and Gsd components provides
billing attribute definition across multiple components. When the attribute
values are provisioned, a warning message appears to notify the operator that
ALL SD and SAS cards must have identical provisioning. Crosschecking is
not possible because the components are on different shelves.
Note: “Subscriber Data (SD) card” refers to both GPRS Subscriber Data
(GSD) and UMTS Subscriber Data (USD) cards.
These four attributes are provisioned in the Sas, Gsd and Usd components.
Multiple instances of these components must have the same values for the
attributes described.
• scdrPartialRecordInterval — This attribute controls the generation of
time-based partial S-CDRs. A partial S-CDR is generated at each
provisioned time relative to the last partial created for this PDP session.
Modification to the scdrPartialRecordInterval requires a reset of the SD
cards. A warning is issued when the provisioning is modified for this
attribute.
• scdrMaxContainers— This attribute controls the number of traffic volume

containers allowed in a partial S-CDR. Traffic volume containers are
created due to a tariff time change event or a PDP modification event.
• specificDailyScdrPartial—This attribute enables the creation of a
management intervention partial scheduled for a specific time each day.
This partial is created at the specified time regardless of when the
previous partial S-CDR record was created for this session. This timed
event is a tariff time change event, provisioned as all other TTCT events
with the specified TODA time. It is handled differently so that a partial
record may be created regardless of the number of containers.
• dailyPartialTimeOfDay—This attribute specifies which TODA event is to
be used as the Specific Daily S-CDR partial event if the Specific Daily S-
CDR Partial is enabled.
A check on activation is provided so that the Specific Daily S-CDR time
of day is one of the available TODA events provisioned and that the
TTCT feature (U/SGSN tariffTimeChangeTrigger attribute) is enabled.

Accounting 6-17
Counters for S-CDRs

Operational and collected statistics provide tracking of functionality related
to S-CDRs. Partial record billing counters delineate the type of partial record
generated. Statistics also track the number of CDRs closed with abnormal
closure reason. These statistics are broken down so that various events that
cause CDRs to close prior to MS detach/deactivate may be tracked. If an SC
failure-handling scenario is in progress it is indicated by a statistic.
The number of partial timers active on each SD at any time is available. This
statistic should match the number of sessions on each SD card.
Refer to NTP 411-5221-060, SGSN Components, for complete descriptions of

Sas and Gsc accounting statistics.
M-CDR partial records 6

Upon certain triggers, an existing M-CDR may be closed and a new M-CDR
opened with the same subscriber identity information, but with a different Local
Record Sequence Number and Record Sequence Number. The downstream
CGF or Billing System is responsible for handling multiple M-CDRs generated
for the same mobile station. A partial M-CDR record is closed and a new partial
M-CDR record is opened upon the following conditions:
• time (duration) limit
• maximum number of mobility changes
• management intervention
The GPRS Attach duration limit condition is triggered by an Accounting

Server audit process that generates partial records for M-CDRs that have been
opened longer than a provisionable time period.
This time period can be set to noTimeLimitPartials, which disables

generation of M-CDR partial records, or to a time period between 15 minutes
to 24 hours, in 15 minutes increments. This functionality allows mobile
stations that have been attached for a long period of time to be closed, and the
mobility- related billing information sent downstream in order to prevent loss
of data. A subsequent M- CDR, with an incremented Record Sequence
Number, is left open in the Accounting Server to continue servicing the active
mobile station.
M-CDRs are provisioned with a maximum number of change of location

containers. When this maximum value is reached, a partial record is
generated for the M-CDR. For M-CDRs, change of location containers are
added when the mobile station performs an intra-SGSN Routing Area
Update. From 1 to 10 Change of Location containers can be provisioned.

6-18 Accounting
There are no plans to use the Management Intervention trigger for M-CDRs
as of this release.
Billing record storage 6

The SAS is responsible for storing and managing CDRs on the 2pGPDsk’s hard
disk. The SAS is integrated with the underlying 2pGPDsk file management
software to allow:
• File writes (for partial and closed CDRs)
• File reads (transfer of CDRs to the CGF and recovery procedures)
• File deletes (upon successful transfer to the CGF)
Each 2pGPDsk card can support up to three days of storage.
CDRs are stored in batch files on the 2pGPDsk hard drive and processed as
described in the following sections.
Batch file naming conventions

CDR batch files reside in one of three directories on the 2pGPDsk hard drive:
• /close - Contains CDR batch files that were created since the last transfer
began.
• /xfr - Contains CDR batch files that are in the process of being
transferred.
• /sent - Contains CDR batch files that have been transferred but are not yet
acknowledged by the CGF.
• /archive - Exists to hold CDRS only for multiple failure scenarios where
synchronization of active and standby did not occur.
The standby SAS cleans its old files during initialization. This is
accomplished by moving the /close, /xfr, and /sent” directories into an
archive directory (e.g., “/local/archive”). If an archive directory already
exists the files are removed when standby SAS is initialized, then the
current /close, /xfr, /sent files are moved to the archive directory.
All CDR batch files are named “cdrsN”, where N is an integer in the range {1
to 1073741824} that represents the batch file number.
Normal batch file processing

The SAS always maintains an open batch file to which it writes CDRs as they
are closed. The SAS closes this batch file and opens a new one when one of
the following conditions is met:
• A new transfer to the CGF is started. This is explained in detail below.
• The file exceeds the maximum size of 1,048,576 bytes.

Accounting 6-19
When a new transfer begins, the SAS first moves all the CDR batch files from
the /close directory to the /xfr directory and then opens a new batch file in the
/close directory for storing newly closed CDRs. The CDR batch files in the /
xfr directory are then sequentially transferred to the CGF. As each CDR batch
file is transferred, it is moved to the /sent directory. When all the CDRs in a
batch file have been acknowledged by the CGF, that batch file is deleted from
the /sent directory.
Any time a new CDR batch file is created, its batch file number will be the
batch file number of the last CDR batch file plus one. When a batch file
number exceeds the value 1,073,741,824, it rolls over to 1.
Recovery batch file processing

When the SAS is first brought on-line, all CDR batch files that exist in any of
the /close, /xfr, or /sent directories are transferred at the first expiration of the
billingXferInterval. This is done to prevent the loss of any closed billing
records in the event of SGSN or SAS failure.
If the network operator removes an SGSN, or just its 2pGPDsk card, from
service and then returns that 2pGPDsk card to service at a later date, any CDR
batch files that exists on the SAS card from when it went out of service are
retransmitted to the CGF soon after it is placed back in service. (New 2pGPDsk
cards are delivered without any CDR batch files in the /close, /xfr, or /sent
directories.) If this behavior is not desired, the network operator can first
perform one of the following.
• Delete all files from the /close, /xfr, and /sent directories on the 2pGPDsk
card’s local disk.
• Move all files from the /close, /xfr, and /sent directories on the 2pGPDsk
card’s local disk to some other location.
Charging Gateway Function (CGF) 6

The SGSN generates accounting records that are collected by the CGF in real
time or by configurable increments of 15 minutes. The CGF consolidates
these records with GGSN records.
A unique reference (Charging ID in combination with GGSN address) is used

to identify all records produced in SGSN(s) and GGSN involved in a single
PDP context. The Charging ID is generated by the GGSN at PDP context
activation and transferred to the context requesting SGSN. At inter-SGSN
routing area update, the charging ID is transferred to the new SGSN as part of
each active PDP context.
The network operator can provision both a primary and secondary CGF IP
Address. The provisioned primary CGF IP Address is the address used by the
SAS when transferring closed CDRs to the CGF. If the primary CGF is not in
service, the SAS uses the provisioned secondary CGF IP Address.

6-20 Accounting
The GGSN also sends a CGF IP Address to the SGSN in the PDP Context
Accept message. This CGF IP address from the GGSN should match the
primary CGF IP Address provisioned by the network operator in the SGSN.
In the case of discrepancies, only the provisioned CGF IP addresses are used.
CGF Data Record Transfer Request threshold

The SGSN limits the number of outstanding Data Record Transfer (DRT)
Request messages to any one CGF to 30. When this threshold is reached, the
SGSN stops sending new DRT requests until enough Data Record Transfer
Response messages have been received to lower this number to 27 or less.
The SGSN will not send any DRT request messages to the secondary CGF in
response to the primary CGF reaching this threshold. However, if the primary
CGF is later deemed to be down, DRT requests will then be redirected to the
secondary CGF. (See “Node failure processing and SAS”.)
CGF Data Record Transfer Response processing

3G TS 32.015 v3.2.0 describes a number of cause values returned in a DRT
Response message but does not clearly define how all the cause values are to
be interpreted by a GSN. Table 6-2 describes how the SGSN reacts to the
returned cause values. It is based on how each sequence number in the
“Request Responded” IE of the DRT response message was sent in the most
recent DRT request message to the CGF.
Table 6-2
DRT response message cause value descriptions
Cause value Description
Request Accepted If this was a normal DRT request, the CDRs that were sent in
the DRT request are freed and any files on disk are deleted
(unless those files still contain unacknowledged CDRs).
If the DRT request was sent as a possibly duplicated message,

“Request Accepted” means the CGF did not receive the
sequence numbers. If they were sent to CGF2, a release
message is sent to CGF2. If they were not sent to another
CGF, the DRT request is resent as a full DRT request.
Request related to possibly If the DRT request was sent as an empty test packet, in
duplicated packet already fulfilled/ response to a CGF that was temporarily down, and if the DRT
Request already fulfilled request was also sent to CGF2, a cancel DRT message is sent
to CGF2.
If this was a normal DRT request, the cause is treated just like
a “Request Accepted” since it implies the CGF already
processed the DRT request a previous time and the SGSN did
not get acknowledgment of that event.
—sheet 1 of 2—

Accounting 6-21
Table 6-2
DRT response message cause value descriptions (continued)
Cause value Description
Version not supported The highest GTP version supported by the CGF is sent in this
DRT response message.
• If that version is not supported by the SGSN, a “Version
Not Supported” message is sent to the CGF and the DRT
response message is ignored.
• Otherwise, the message is resent to the same CGF using
the GTP version requested by the CGF. All future
messages with the CGF will use the new GTP version.
No resources available/Service not The SGSN marks the CGF as being down and immediately
supported/System failure/Request sends the DRT requests to CGF2 marked as “possibly
not fulfilled duplicated”, if CGF2 is available.
Mandatory IE incorrect/Mandatory The CDRs used to create the DRT request are discarded and
IE missing/Optional IE incorrect/ saved in a bad CDRs file (/bad/cdrs.new). No attempt is made
Invalid message format to reformat or resend the DRT request.
Invalid cause This is any other cause value not specified above.
The CDRs used to create the DRT request are discarded and
saved in the bad CDRs file. No attempt is made to reformat or
resend the DRT request.
—sheet 2 of 2—

6-22 Accounting
Billing redundancy 6
The SAS application supports 1:1 hot standby redundancy. Up to 4 primary
SAS cards can be concurrently active in a common Passport 15000 shelf.
Each card must be redundant in a 1:1 configuration with up to four standby
cards.
Both the active and standby SAS cards must be on the same 15000 shelf. In
the event of a failure (assuming it is not a disk crash), all closed CDRs are
preserved on the hard disk of the failed FP. The two spare cards must be of
the same version. For the purpose of hardware replacement, the spare pair
may be of different versions but this needs to be rectified within the
maintenance window.
Hot standby
Figure 6-4 depicts the flow of information between the active and standby
SAS cards to support synchronization for the hot standby mode of operation.
Figure 6-4
Active/standby synchronization
file sys file sys

CGF
closed closed
CDRs CDRs
open CDR checkpointing

GTP’: CDR bulk SAS SAS
transfers journaling of billing info
(active) (standby)
billing
requests/events
GMM
SM
SC SC SC SC SMS
SSF (CAMEL)
SD SD SD SD
The SAS application receives event notifications from the various Subscriber
Control (SC) cards it supports. These messages cause new CDRs to be
opened, existing CDRs to be updated, partial records to be generated, and
existing CDRs to be closed. This affects the active records in main memory
and closed records in secondary storage (the hard disk). Dynamic data is
journaled from the active SAS application to the standby SAS application for
synchronization of incoming billing information.

Accounting 6-23
Upon startup of the standby SAS card, open CDR data in the active SAS
application is synchronized with the standby via checkpointing mechanisms.
The active application initiates transfer of closed CDRs to the Charging
Gateway Function (CGF) upon synchronization of the standby card. This
avoids capacity issues which arise from full hard disk synchronization of
closed CDRs. Subsequent CDR closure occurs simultaneously on both the
active and the standby.
The dynamic data on the Active SAS FP is journaled to the Standby FP for all
transactions. Upon failure of the Active FP, all open Call Detail Records
(CDR) are maintained on the FP that takes over as active. Closed CDRs are
preserved on the hard drive. Upon failure of the active card, a switch-over
occurs, causing the stand-by to enable as active and begin processing
incoming billing requests. Billing operations for previously open records
(updates and closes) are maintained.
When the SAS is in hot standby, the disks are in sync and manual recovery of
billing files is not required. To limit the loss of billing data, it is recommended
that the collection of traffic volume counts and the generation of partial S-
CDRs occur as frequently as possible without impeding required capacity.
The frequency of these events is independently operator-configurable from a
minimum of every 15 minutes to a maximum of every 24 hours.
Note: A SAS card that has many records stored to disk takes longer to
initialize. On startup, a disk test checks all content on the disk. Each file
is examined; this has taken as long as 10 minutes in the lab. To avoid such
delays, files stored on the disk should be transferred off of the SAS card
often enough to minimize the number of records.
Fault management
Billing redundancy utilizes existing Passport Base alarms related to
redundancy and modifies the behavior of existing SAS alarms. On switchover
all alarms for the LP and its subcomponents are cleared. The standby card
raises any alarms that still exist after switchover.
Passport base alarms

The Passport base includes some alarms related to card sparing. They include:
• 7012 0201
• 7012 0202
• 7012 0300
• 7012 0301
• 7054 0104
• 7054 0105

6-24 Accounting
Refer to NTP 241-5701-500 Passport 15000 Alarms for more details.
SAS alarms
This section describes alarms related to SAS hot standby. For complete
information on all alarms, see NTP 411-5221-500, Nortel SGSN Alarms
Reference Manual.
The following alarms are generated on the card currently operating as the
standby though they are converted to MSG alarms against either the
Shelf Card/ x StandbyServices or Prov Migration component, depending on
whether the card is standby or migration active.
• 7068_1016, SAS Initialization Failure Alarm
Initialization failure alarms are generated on the standby for any failure
which precludes the standby from being able to perform the role of hot
standby.
An additional alarm text is possible for 7068 1016 if a switchover occurs

but the active and standby were not synchronized. This alarm is SET but
there is never a CLR. The operator must recognize that some data is lost
and manually clear the alarm.
• 7068_1002, SAS Disk Failure Alarm

Disk failures occur independently on each FP. Whenever a disk failure is
detected, it is important to inform the operator via an alarm. In a
redundant configuration, when a critical SAS Disk Failure is detected on
the active SAS card, switchover to the standby is forced provided that the
standby is completely synchronized.
• 7068_1001, SAS Disk High Usage Alarm

SAS checks periodically to see how much space is left on its disk. This
alarm is only generated on the standby when the critical disk full
threshold level is reached. Since both cards should have approximately
the same amount of free space, it is sufficient for only the active card to
generate this alarm when the minor or major severity threshold level is
reached. If the condition still exists after a switchover, the spare card
effectively regenerates the alarm after checking its own disk. If the
condition has cleared before switchover, there is nothing special to do.
The following alarm is generated from both the active card and the standby
card with text that indicates which card is issuing the alarm. This is done to
make sure the correct information is given to the operator in a situation where
the channel between the active and standby is not functioning correctly.
• 7068_1566, SAS Not Ready for Switchover Alarm

Accounting 6-25
This alarm is used to inform the operator of the availability of hot standby
services for SAS.
The following alarms are not generated on the card currently operating as the
standby:
• 7068_1003, CGF Link Failure Alarm
The standby application does not communicate with the CGF. After it
becomes active, it starts talking to the CGF(s) and may then generate an
alarm if it cannot establish communication.
Configuration of a hot spare is part of the base Passport carrier grade
functionality. Billing / LI Redundancy makes use of the 1:1 sparing option
available using the mainCard/spareCard attributes of the Logical Processor
component. Reference NTP 241-5701-600: Passport 7400, 15000, 20000
Configuration Guide.
Billing redundancy adds no additional provisioning components or attributes.
Billing redundancy is entirely related to accounting and serves to greatly
reduce the possibility of lost billing records through providing hot standby
redundancy.
Billing redundancy does not include any additions or changes to counters,
thresholds, or otherwise affect any aspects of performance management
except as noted in the Fault Management section above. Existing counters are
not synchronized to the standby therefore switchover essentially resets the
counters. Thus, counter changes within the last 15 minute collection interval
can be lost.
Node failure processing and SAS 6

The SGSN Billing functionality is affected by failures of other functional
failures of these other processors and nodes on SGSN billing are described
below.
GGSN
For a GGSN failure, the PDP Contexts in the GGSN are lost. The GSC
detects the GGSN outage via the Path Management functionality. When a
mobile station with a PDP Context on the failed GGSN next communicates
with the SGSN (either uplink bearer or signaling messaging), the GSC
deactivates the PDP Context. The deactivation causes the S-CDR to be
closed with the “abnormal release” reason.

6-26 Accounting
M-CDRs are unaffected by GGSN failures, so SAS takes no action on M-

CDRs in this scenario.
CGF
Normal CGF recovery is handled as described in 3G TS 32.015 v3.2.0
The SGSN deems the CGF to be down in response to any of the following:
• After sending three consecutive “Echo Request” messages to the CGF
without receiving an “Echo Response” message.
• Receiving a “Data Record Transfer Response” message with cause “No
resources available”, “Service not supported”, “System failure”, or
“Request not fulfilled”.
• After sending a “Data Record Transfer Request” message the provisioned
number of times without receiving a “Data Record Transfer Response”
message for that request.
• After receiving a “Redirection Request” message from that CGF.
At the time the SGSN deems the primary CGF to be down and if the
secondary CGF is in service at that time, the SGSN sends any
unacknowledged “Data Record Transfer Request” messages to the secondary
CGF, marked as possibly duplicated. If, at some time after the primary CGF is
deemed to be down the secondary CGF becomes available, no possibly
duplicated DRT requests are sent to the secondary CGF.
The SGSN deems a CGF to be back in service in response to any of the

following:
• After receiving a “Node Alive Request” message from that CGF.
• After receiving a “Node Alive Response” message that was in response to
a “Node Alive Request” message sent by the SGSN.
• After receiving an “Echo Response” message that was in response to an
“Echo Request” message sent by the SGSN.
• After receiving an “Echo Request” message from the CGF.
At the time the SGSN deems a CGF to be back in service, the SGSN sends all
unacknowledged “Data Record Transfer Request” messages back to the CGF
as empty test packets and marked as possibly duplicated. If the CGF responds
to these empty test DRT requests with the “Request Accepted” cause and the
DRT request was never sent to the secondary CGF, the SGSN then resends
the full DRT request message back to the CGF.
If a CGF is reprovisioned to a new IP address after it has been deemed to be

down, any unacknowledged “Data Record Transfer Request” messages that

Accounting 6-27
were sent to the old IP address are then be sent to one of the provisioned
CGFs, with preference given to the primary CGF.
SGSN
Failure of the SGSN shelf as a whole results in the loss of all open CDRs on
the SAS card. Since CDRs are stored in volatile memory until closure (when
they are moved to disk), there is no mechanism for recovering these CDRs.
Upon recovery of the SGSN, closed CDRs that were stored onto the hard
drive prior to the SAS failure are processed as normal (sent to the CGF upon
expiry of the transfer timer). Since all the open CDRs were lost, billing
operations for previously open records (updates and closes) are discarded by
SAS.
SC
The SC function is N+1 cold or 1:1 hot spared. See “GSC redundancy” on
page 4-9 for detailed SC redundany information.
Subscriber card application status change may be the result of two different
types of events. For an SGSN with redundant SC cards, a switchover may
have occurred. The notification may indicate a total SC failure. The SAS
card determines which type of event triggered the notification. If the SC card
subscribers are no longer being handled, the associated CDRs are closed with
abnormal closure reason with the captured event time. Refer to “CDRs and
Subscriber Control Card Reset” on page 6-7.
SD
When an SD card fails, GSC is notified of the failure and summarily deletes
all of the active PDP Contexts associated with the failed GSD. It also instructs
SAS to close all of the affected S-CDRs with the “abnormal release” reason.
M-CDRs are unaffected by GSD failures, and therefore SAS does not need to
take any action on the M-CDR in this scenario.
Restrictions and limitations 6

This section lists the restrictions and limitations inherent in this release of
SGSN Billing. These restrictions and limitations include functionality defined
in the standard but not implemented, limitations imposed by hardware
availability, and software functionality outside the scope of the billing
requirements.
General
The GPRS6.0 release of SGSN Billing has the following limitations:
• SGSN billing adds no additional functionality for synchronizing CDRs
across SGSNs above and beyond the Network Time Protocol (NTP)
currently supported by Passport.

6-28 Accounting
• Only a primary and secondary CGF are used, as provisioned, on the

SGSN.
• The CGF Address sent to the SGSN in the Create PDP Context Response
from the GGSN is not supported by SAS. Only the CGFs provisioned on
the SGSN are used by SAS.
• The “Address of Recommended Node” parameter in the Redirection
Request message is not supported by the SGSN. Only the provisioned
CGF IP addresses are supported.
• GTP' over TCP is not supported since the GTP' protocol has its own
reliable error checking mechanisms.
• Configuration parameters must be set correctly for SAS, USD, GSD
components to provide desired results. Warnings are given where multiple
components must have matching attribute values.
• M-CDR provisioning values are still required for the SAS component. M-
CDR partial record creation mechanism is not modified.
• SAS audit which occurs at the specified cdrUpdateInterval will continue
to retrieve updates for volume counts as provisioned on SAS card by
update interval. This maintains the data on the SAS card between partial
record intervals and ensures that volume counts are more up-to-date in the
event of an SC card reset. It is recommended that the cdrUpdateInterval
be set to the highest value possible to avoid unnecessary message traffic.
The cdrUpdateInterval is still used to determine M-CDR partial record
creation.
• Closure of CDRs due to an SC card reset may not occur immediately. All
CDRs are associated with the failed SC card are marked but closure of
CDRs is throttled to allow SAS card receipt and handling of all events.
• SAS card operation is unpredictable with hard drive utilization over 90%.
It is recommended that SAS hard drive usage level be maintained below
20%. Hard drive alarms indicating high disk usage or hard drive errors
must be handled immediately to maintain operation of SAS card.
• As in all previous releases, reset of SD card(s) result in loss of volume
counts since the last partial record was created for open S-CDRs. A
volume count of out sync software error may be seen on a SD reset.
• Reset of SD card(s) result in loss of partial timed events for open S-CDRs.
• As in all previous releases, modifications to maximum container settings
that reduce the maximum number of containers may cause CDRs to be
created with more containers between previous provisioning and new
provisioned value.
Multi-active SAS
• A maximum of four (4) active and four (4) standby SAS cards, eight (8)
total, is allowed.

Accounting 6-29
• No cross shelf communication with USC/GSC is provided. All SAS

cards must reside on the same shelf as the corresponding USC/GSC cards.
• Non-redundant SAS configuration is not supported. Each SAS card must
be configured with a corresponding standby card.
SAS hot standby redundancy

SAS Hot Standby Billing Redundancy has the following restrictions and
limitations:
• Hot standby spare card must be hardware identical to the main card (i.e.,
same PEC code).
• Main and spare card must reside in the same shelf.
• CDR audit files are not synchronized.
• Hard disk files are not 100% synchronized between active and standby
instances.
• Performance statistics are not explicitly spared, meaning they may not
match exactly on the spare SAS card. Some performance data loss is
possible in a switchover.
• Hot standby redundancy provides high availability and minimal data loss
for single failure scenarios only. No special handling is provided to deal
with multiple (independent) hardware or software failures that take place
at the same time or within the same time window.
• Incomplete transactions and any messages queued on the SAS card are
lost when the card fails. Loss of billing transactions not to exceed 5
seconds of traffic. If a PDP activation is lost during this time no S-CDR is
opened hence subsequently received data traffic counts for that session
are also dropped regardless of how long that session might be active.
• When the spare card boots, the SAS application is not considered fully
redundant until the active card has successfully completed a CGF transfer
of all the billing records stored on its disk. This includes any records
written to disk prior to the completion of checkpointing.
• LI application supports warm standby only. Switchover to the standby
instance is functionally equivalent to a reset of the LI card. (The only
difference is that recovery time is reduced.)
• SAS FP(s) are reset whenever a critical provisioning change occurs,
including a change to the redundancy model (i.e., adding or deleting the
spare card).
• Change to/from hot standby configuration should be done in maintenance
window.
• On upgrade all existing closed CDRs must be sent to the CGF and the
disk should not contain any CDRs.

6-30 Accounting
• GTP` sequence numbers are not synchronized between the active and the
standby. Switchover results in a reset of these sequence numbers.
• CGF transfers in-progress at time of switchover are restarted on the
standby. This may result in duplicate CDR transfers to the CGF.
• When the active SAS card does not receive an acknowledgement from the
primary CGF, it will send “possible duplicate” messages to the secondary
CGF. When the primary CGF recovers, the SAS card will send a cancel
or release message to the secondary CGF. In a redundant SAS
configuration, GTP’ message information is not journaled to the SAS
standby card, therefore if a primary CGF fails causing “possible
duplicate” records to be sent to the secondary CGF and a SAS card
switchover occurs prior to the primary CGF recovery, no release or cancel
messages will be sent to the secondary CGF.
CAMEL
• Excluding the Free Format Data and FFD Append Indicator fields, all of
the Camel Information is not stored in the S-CDR until prior to the PDP
context being disconnected. If the Camel dialogue does not perform any
Apply Charging and does not arm the Disconnect EDP, then Camel will
not be involved in the Deactivation procedure and Camel Billing
Information will not be included in the S-CDR.
Partial records
• A reset is required on the SD card to react to modification of the
scdrPartialRecordInterval.
Time based partial records
• Time based partial records are created for each S-CDR at the provisioned
partial record interval with actual CDR duration subject to variations
resulting from system delays and traffic load conditions.
Data Volume Limit Trigger
• Employing both the Data Volume Limit Trigger and Time-Based Partial
billing could have a capacity impact on the SGSN and CGF.
• During a SAS audit, there may be occasions where the audit may
determine that more than one condition exists to trigger the generation of
a partial S-CDR record. In such cases, where both the DVL threshold and
the time duration limit have been exceeded, the partial S-CDR record will
be generated using the data volume limit as the partial record reason.
• The partial record reason “Management Intervention” is not supported for
M-CDRs.
• S-CDR Data Volume Limit partials contain volume counts with the
provisioned data volume limit plus up to one additional packet.

Accounting 6-31
Tariff Time Change and Specific Daily Partial

• The Tariff Time Change feature requires that system time be accurate.
The synchronization of time to actual time and all time changes are
handled by existing Passport base software components. The Passport
NTPs listed in “Passport documentation” on page -xxix detail the
functionality of the existing Base Passport components.
• It is desirable to configure the tariff time changes to be outside peak
traffic times to avoid message flooding between software components.
There is significant message traffic anticipated following a tariff time
change to handle active PDP contexts.
• The tariff time changes may not be configured any closer than 4 hours
apart. The tariff time changes may not be configured more than 12 hours
apart.
• There is no guarantee that containers for all idle PDP contexts will be
closed within a tariff time interval. Every attempt will be made to close at
least one container for each tariff time period for all existing PDP
contexts. The specification says — Billing “should close the existing
volume counters and open new ones when appropriate traffic is detected
[TS 32.015]”.
• Actual tariffs for the S-CDRs are provided by downstream billing, SAS
provides the data volume counts for downstream billing to use.
• There is no capability within the existing TODA configuration to
provision a per day-of-the-week tariff period. The operator’s Billing
System can assign tariff rates based on day-of-the-week.
• The timestamp of Closed S-CDR Traffic Volume Container will not
exactly match the Tariff Time Change time. The volume counts will be
accurate.
• Tariff Time Change feature must be enabled with at least 2 collection
times set. If the Specific Daily S-CDR partial attribute is enabled, one of
the collection times must be set to the Specific Daily S-CDR time of day
for the Specific Daily S-CDR partial to be created. These values must be
the same on all shelves. Time must be consistent across all shelves.
• A partial S-CDR record is created for each activated session at the
provisioned Specific Daily S-CDR time of day, if all necessary
provisioning attributes are set correctly. The record may not appear on the
SAS hard drive for up to fifteen minutes. The record closing reason for
this partial is management intervention. A subsequent S-CDR created due
to timeLimit may have a duration that exceeds the provisioned partial
record interval by at most 16 minutes.
Daylight Savings Time interaction
• The offset attribute of the TIME component must be used to modify the
time for DST for CDR duration and time stamps to be recorded correctly.

6-32 Accounting
• Only CDR durations are addressed for DST (Daylight Savings Time)
changes. Automation of offset change due to DST is not addressed.

7-1
Operations, administration, and

maintenance 7
This chapter provides a high-level overview of the Passport OA&M functions
used when provisioning, operating, and monitoring the SGSN. This chapter
also provides the following SGSN-specific OA&M information:
• Provisioning maxSubscribers
• Performance counters
• Displaying GSC success rates
• Attach and activate failure alarms
• Displaying IMSI information
• Clearing an inactive mobile
• Clearing a GTP path
• SGSN trace tools
• SC Diagnostic Tool
• Active alarm list
• Audit alarms
• Locking/unlocking a GSC
• Daylight Savings Time adjustment
• GMM Cause Code mapping
• OSI states

7-2 Operations, administration, and maintenance
OA&M overview 7
The SGSN is managed and viewed
• using the text interface
— using a local text interface device, such as a VT100 terminal,
connected to the SGSN
— using a Telnet session from a remote terminal
• using Nortel Wireless Network Management System
The operations and maintenance of the SGSN node includes procedures for
software installation, provisioning, monitoring, data collection, and fault
management.
Note: Running off-board UNIX scripts on the SGSN is not tested or

supported, therefore unanticipated behaviors may result.
To operate and maintain the SGSN, you need to understand some basic
Passport operations concepts. These concepts include an understanding of the
network management functions of Passport, the architecture of Passport, and
how node software is handled. For additional information on Passport base
OA&M procedures, refer to NTP 241-5701-045, Passport 7400, 15000,
20000 Management System User Interface Guide, and NTP 241-5701-600,
Passport 7400, 15000, 20000 Configuration Guide. An overview of some of
the management functions is included in the following sections.
Note: No Passport maintenance commands, unless explicitly detailed in

this NTP are supported on any Passport components provisioned with
SGSN functionality.
This chapter provides an overview of the software component architecture of

the Passport 15000-VSS platform functioning as a Serving General Packet
Radio Service (GPRS) Support Node (SGSN).
Components
A large part of Passport flexibility resides in the extensive use of components
in both its design and deployment. A component represents some part of the
system which could be a service, a piece of software or a physical hardware
component. Virtually every Passport subsystem has components.
Components are manageable entities which control Passport software,
hardware capabilities and access services.
NTP 241-5701-060, Passport 7400, 15000, 20000 Components, provides

detailed reference material for all Passport components. This multi-volume
documentation suite contains multiple indices for quickly searching for
components, attributes, and verbs. It also contains detailed descriptions of
generic components and attributes and the functional relationship that exists

between them. Nevertheless, an introduction to the component architecture is

included in this chapter.
NTP 411-5221-060, SGSN Components, contains descriptions of Passport

components specific to the SGSN.
Components provide the infrastructure through which network operators and

administrators interact with Passport. Standardized and organized in a highly
structured environment, components provide the model for operator
interaction with Passport.
Components are arranged into hierarchies. A hierarchy is a tree-like structure

that defines relationships between the individual components. Through this
structure, a functional relationship is developed between each of the
components that combine to form the Passport system.
By their relative positions in the hierarchy, components have their parent

components and subcomponents defined (see Figure 7-1). A component can
have another component below it in the hierarchy. They are called
subcomponents. Subcomponents have all the normal characteristics of
components and they have a parent component.
Components form the building blocks of Passport functionality. Everything

that makes up a component has a responsibility to perform a task.
Components combine to form components.
Subcomponents and components have the same properties. “Sub” indicates

the relative position of the component within the hierarchy. In some cases,
components may have operational influence over their respective parent and
subcomponents. They are the method for indicating the behavior of some
functionality in Passport.

Figure 7-1
Components form into parent and subcomponents by their relative positions
Parent component
A component may be a
subcomponent to a parent
component and a parent
Subcomponent Subcomponent to another subcomponent
Parent component simultaneously.
Subcomponent Subcomponent
Components have attributes that define the behavior or informational aspects

associated with a specific component. Attributes are either:
• operational
• provisionable
Note: Components with operational attributes may also have

provisionable attributes.
Operational attributes provide information or data used for monitoring the

operation of Passport and its services. The values of operational attributes are
not retained across system restarts. These values can not be provisioned, but
some of them can be set. These attributes include information such as:
• component OSI management state
• statistical data
Provisionable attribute values can be configured by the network operator or

administrator so that Passport subsystems or services perform or behave in a
certain manner. All components which are provisioned are saved across
system restarts. Some components with provisionable attributes are
mandatory and are created automatically by their parent. Components with
provisionable attributes can also have operational attributes.
SGSN components
SGSN functionality builds on top of existing “base” functionality of the
Passport. Passport software consists of applications. Base Passport applications
include:
• atmNetworking_xxxxxx
• base_xxxxxx
• frameRelay_xxxxxx

• ip_xxxxxx
• networking_xxxxxx
• wanDTE_xxxxxx
The wireless applications needed for a GPRS SGSN are:

• wirelessSgsn
• wirelessNssBss
• wirelessCommon
• wirelessSgsnCommon
• genericUtilities
Applications provide certain types of software functionality called features.

(Some applications, such as wirelessNssBss do not have features.) Refer to
NTP 411-5221-904, Nortel SGSN Provisioning Procedures, Appendix D,
“Recommended Hardware Baseline and Lpt featureList” for the hardware
baseline and recommended logical processor type feature list for each of the
supported hardware types and software components on each SGSN shelf.
Instances of the ApplicationVersion component represent the software

applications currently available on the node (stored on its file system).
Instances of the Feature component represent each of these applications. You
can download new software applications to the node from a software
distribution site (SDS).
Even though many applications are available on the node, the SGSN only
uses the items specified on the application version list (the avList attribute of
the Software component). This capability allows storage of new applications
or new versions of existing applications on the node for future use.
Note: For more information on Passport software and architecture, see

NTP 241-5701-600, Passport 7400, 15000, 20000 Configuration Guide.
In most cases, the software is backward compatible. New software can load
provisioning files and interpret provisioning views created using a previous
version of the software. The Release Notes document, which is included with
each new software release, specifies any exceptions.
Configuration management involves provisioning and software management.
• Software distribution, also referred to as software installation, involves
configuring and downloading software to SGSN nodes to add or upgrade
services, capabilities, or features. Refer to Chapter 8, “Software
management” for SGSN software management information.

• Provisioning entails modifying SGSN provisioning data to add or

terminate services, or to alter the behavior of the node or services.
Provisioning involves using the views and provisioning data files
described in NTP 241-5701-060, Passport 7400, 15000, 20000
Components, and in NTP 411-5221-060, SGSN Components. Complete
SGSN provisioning procedures are provided in NTP 411-5221-904, SGSN
Provisioning Procedures.
Provisioning views
The provisioned and operational parameters on a node are a set of data
entries. A set of data entries that defines both the capabilities of a node
(access services, for example) and the specific characteristics of its
performance is called a view.
The SGSN has four types of views:

• current view: This view contains the set of provisioned and operational
data that defines the current configuration of the node.
• edit view: This view is the set of provisioned data to which data can be
changed or appended. It is used for controlled modifications to the current
view. Once an edit view is complete, it can be activated as a current view.
• saved view: These views are copies of either the current view or the edit
view. Saved views are stored on the control processor disk.
• committed view: This is a saved view in the system; it is the rollback
point to which the node returns upon reset, restart, or switchover.
The current and edit views are held in memory; the saved and committed
views are stored on disk on the CP.
Provisioning system commands provide the functionality required to

manipulate whole views (current view or edit view) or to provision specific
components.
The Passport provisioning system is open-ended and can be adapted to

specific administration requirements and processes. These provisioning
processes are summarized in Table 7-1.
Table 7-1
Summary of characteristics of provisioning operations
Process Planning required Time of activation
Bulk provisioning Planned in advance Immediate or delayed
—sheet 1 of 2—

Table 7-1
Summary of characteristics of provisioning operations (continued)
Process Planning required Time of activation
Regular customer-order Daily activity Delayed and several sets of

processing changes are activated in bulk
Activation of regular customer Completed at pre-determined Immediate

orders times, probably daily as an
over-night process
Immediate (or emergency) Unplanned Immediate

provisioning
Global data changes Planned in advance Immediate
Network configuration changes Planned in advance Immediate
—sheet 2 of 2—
Data collection
The Passport data collection system collects statistical data that you can use
to calculate the systems performance.
Statistics data
Every fifteen minutes the statistic probe is broadcast to collect the statistics
(also referred to as counters) for the SGSN. The following components generate
statistics records that are spooled or can be monitored real-time:
• MapClient Statistics are collected indicating the number of MAP
transactions serviced by MapClient as well as number of errors
encountered. These statistics are generated for the various MAP
transactions, such as ISD, DSD, UGL, CL, and SAI.
• GMM Statistics are collected indicating the number of mobility
management transactions serviced by GMM. These statistics are
generated for the various GMM transactions, such as authentication,
ciphering, and P-TMSI reallocation.
• SM Statistics are collected indicating the number of session management
transactions serviced by SM. These statistics are generated for the various
SM transactions, such as PDP context activation and PDP context
deactivation.
• HLRC Statistics are collected indicating the number of subscription
records maintained by the HLR Cache.
• SNDCP Statistics are collected indicating the number of transactions
serviced by SNDCP. These statistics include the number of SN_PDU/
N_PDU and activate/deactivate requests serviced by SNDCP.

• BVC Statistics are collected to indicate the throughput of the BVC. These
statistics include the number of PDUs sent in the uplink/downlink
direction.
• NSE Statistics are collected to indicate the number of BVC within an
NSE.
• NSVC Statistics are collected to indicate the number of transactions
processed by NSVC.
• SGSN Accounting Server (SAS) statistics are collected indicating the
number and type of Call Detail Records (CDRs) handled by the SAS.
More information about SGSN statistics is provided in “Performance
counters” on page 7-14.
Security management
Security management involves controlling individual operator capabilities, as
well as the security capabilities of the network management device.
Passport implements the following security capabilities:

• access to the SGSN through userids and passwords
• maintaining information on:
— user IDs, passwords, capabilities, customer identifiers, and network
management interfaces (NMIFs)
— IP addresses of specific network management devices from which an
SGSN will accept connections (referred to as friendly IP addresses)
— operator commands issued to the node
Fault management
The key to Passport fault management is alarms. An alarm indicates that there
is a fault in your network. OSI state information can help you determine the
cause of a fault. See “OSI states” on page 7-56 for OSI states of SGSN
components.
The user connects to the node through the OA&M interface device (or Telnet
session). The user then monitors the information by issuing various
commands.
Alarms
Passport provides a method for components in the system to asynchronously
signal events or alarms to an external management device (for example, a
VT100 terminal or a network management workstation).
Alarms are based on an event-driven system; that is, alarms are generated
when certain events occur.

An alarm appears on the terminal when a component of the node detects a fault
or failure condition with either itself or another component on the node.
Common alarm situations include:
• a failure or fault occurs
• a fault or failure condition has been fixed (this is a clear alarm)
• cases where conditions are transient or cannot be repaired (a message
alarm may appear to inform you of the condition)
For information about SGSN alarms, see 411-5221-500, SGSN Alarms

Reference Manual.
For complete information on base Passport alarm formats and OSI states, see
NTP 241-5701-500, Passport 6400, 7400, 15000, 20000 Alarms.
Text interface
The user interface on a VT100 terminal or terminal emulator consists of
• commands that are entered
• responses to those commands provided by the Passport system.
Both commands and responses have specific formats for more effective
interpretation.
All common commands use a variation of the following form:

verb [-options[(option_value)]]... component_name [attribute_name|
group_name]...
A verb is the action portion of the command form.
Note: The command description in this section follows these

conventions:
– bold indicates a keyword explicitly typed by the operator

– square brackets, [], indicate optional parameters
– <italic> indicates a user-specified parameter
If the system cannot interpret and process the command, it displays an error
response to indicate the failure.
The text interface characteristics depend on the active mode state:

• provisioning mode
• operational mode
• encountering alarms

The characteristics of these modes are described in the following sections.
The text interface also provides a set of keyboard shortcuts that can be used to
accelerate work in provisioning and operational modes. Many of these
shortcuts permit editing of the command line. Other shortcuts permit control
of the display of the system response.
Provisioning mode and operational mode

Provisioning mode is used to create and modify views of current data or data
on file. Operational mode is used to display current operating parameters and
conditions. Figure 7-2 shows an example of the screen format.
Figure 7-2
Format of screen: provisioning mode or operational mode
prompt #> <command> command line

<component>
<data>
.
. response
.
<data>
<status> <date> <time> status line
Figure 7-3 provides a sample screen of the text interface command while in
provisioning mode. Figure 7-4 provides a sample screen of the text interface
command while in operational mode.
Figure 7-3
Sample screen, valid command in provisioning mode
PROV 4> set shelf card/1 cardType del

Shelf Card/1
ok 1999-07-15 12:23:47.23
PROV 5>
Figure 7-4
Sample screen, valid command in operational mode
4> display -p shelf card/1

Shelf Card/1
cardType = V35
configuredLPs = Lp/2
ok 1999-07-29 10:14:38.24
5>

Terminal
A terminal allows the user to key commands and view responses on the screen.
It has the following capabilities:
• displays information in textual format
• can be connected directly to a node (local)
• used to view only the node to which it is connected
A terminal (VT100 compatible) is suitable for small networks where nodes
are within reasonable proximity. It is limited to managing one node at a time.
Telnet
Telnet is an industry-standard remote terminal protocol based on the TCP/IP
transport protocol which allows remote viewing of a node in the same textual
format as that of a local text interface device. A Telnet session offers the same
capabilities as a terminal, although from a remote location. Each Telnet
session can manage only one node at a time. Each node supports thirty-two
Telnet sessions at one time.
Nortel Wireless Network Management System

Nortel Wireless Network Management System (W-NMS) is the OAM
solution for Nortel’ UMTS/GPRS Access, Packet Core, and Circuit Network.
For existing GPRS customers, W-NMS offers Main Server (MDM based) and
either the Performance Server (NexusMETER) or Performance Server
(XML).
For new GPRS customers, W-NMS offers Main Server (NSP based) and
Performance Server (XML).
It offers the CGF functionality (through MetaSolv Network Mediation) as

well as IP Network Services (through MetaSolv Policy Services and
MetaSolv RADIUS Server.)
For more information, refer to NTP 411-5221-003, Wireless Network

Management System Customer Documentation.

Provisioning maxSubscribers 7
The SGSN uses Software Optionality Control (SOC) to control the maximum
number of subscribers that the SGSN supports. The total number of “GPRS-
Attached” subscribers the SGSN can support simultaneously is controlled
through two attributes: maxSubscribers and maxSubsAccessCode. It does
this by limiting the total of all the individual maxAttachedSubscribers
attributes in the Gsc components and maxLlcActiveSubscribers in the Gsd
components.
For example (see Figure 7-5), if the SGSN has two Gsc applications
provisioned, the first one provisioned to support 5000 subscribers and the
second to support 2500 subscribers, attribute maxSubscribers must be
provisioned with a value of 7500 or greater.
Figure 7-5
Example maxSubscribers provisioning
SGSN/ GSC/1
maxSubscribers 7500 maxAttachedSubscribers 5000

maxSubsAccessCode 614671113415012478
GSC/2
maxAttachedSubscribers 2500
Increasing “Sgsn maxSubscribers” using “maxSubsAccessCode”

To increase the value of maxSubscribers, an activation code must first be
obtained from an authorized Nortel representative and provisioned in
attribute maxSubsAccessCode. The activation code is unique for each SGSN
and each value of maxSubscribers. Each SGSN requires a unique activation
code for each and every increase to the maxSubscribers attribute.
The Customer provides the new maxSubscribers number along with the
Passport Node name (for example, GPP20BL). A Nortel representative inputs
these two parameters to the Algorithm that generates a
“maxSubsAccessCode” that can then be provisioned ONLY on that Passport.
The Passcode will NOT work on any other Passport.

To display the Passport Node name, enter:
> d -p mod
Note: If the Passport node name is changed (in attribute Mod

nodeName), a new access code must be obtained from Nortel. A “check
prov” warning is issued to notify the operator of this whenever the node
name is changed.
Sgsn component verification

GprsSgsnProv defines maxSubscribers and maxSubsAccessCode.
MaxSubscribers is the maximum number of subscribers allowed on the
SGSN. MaxSubsAccessCode is the password received from Nortel that
allows the maxSubscribers field to be changed.
The maxSubscribers defaults to 1000 subscribers. Once the value is increased

above 1000, the maxSubsAccessCode must also be provisioned to allow the
increase to occur.
Gsc and Gsd component verification

GprsGscProv defines the maxAttachedSubscribers for a Gsc, and
GprsGsdProv defines the maxLlcActiveSubscribers for a Gsd. When this
value is changed, the value of all maxAttachedSubscribers on all Gsc or
maxLlcActiveSubscribers on all Gsd component instances is summed. The
sum of the maxAttachedSubscribers provisioned on all the Gsc component
instances should not exceed the value of maxSubscribers provisioned for the
Sgsn component. Likewise, the sum of the maxLlcActiveSubscribers
provisioned on all the GSD component instances should not exceed the value
of maxSubscribers provisioned for the Sgsn component.
If this sum is less than or equal to maxSubscribers provisioned for the Sgsn
component, then the change is allowed.
Note: Changing the value of parameter maxAttachedSubscribers for a

Gsc or maxLlcActiveSubscribers for a Gsd will result in the process to
which the attribute’s component is associated to be taken out of service.

Performance counters 7
Real-time counters (also called operational attributes), historical counters
(also called collected events) and alarms are related to measuring and
assessing the performance of the SGSN. They are the key elements that can
help customers maintain and operate their network in the most efficient
manner.
The following sections provide a high level overview of the various counters
being introduced or changed in GPRS6.0. Unless otherwise specified, for
every counter there is an operational statistic (real-time counter) and a
collected event (historical counter) equivalent. For complete descriptions of
all SGSN statistics, refer to NTP 411-5221-060, SGSN Components.
Enabling per cell statistics collection

The provisionable attribute Sgsn PerCellStatistics is used to enable and
disable per cell statistics (this attribute is disabled by default). The per cell
statistics are defined in the Gsc/n Mcc/mcc Mnc/mnc Lac/lac Rac/rac CellId/
cid component (see “Per-Cell group” on page 7-24).
When enabled, the per cell statistics data is collected and spooled by the Data
Collection System (DCS). Collection does not start for a cell until that cell
receives its first uplink message.
Note 1: Enabling per cell statistics can have a significant impact on

system resources. Please consult with Nortel support before enabling this
feature.
Note 2: Enabling per cell statistics can impact capacity on the OAM
Performance server. For more details refer to NTP 450-3101-638, Nortel
Wireless Network Management System (W-NMS) OAM Engineering
Guide.
Session Management
Real-time and historical Session Management (SM) counters are provided for
GSC card performance management under the Gsc Sm component. The
following sections provide a high level overview of SM counters. Unless
otherwise specified, for every counter there is an operational statistic (real-
time) and a collected event (historical) equivalent.
Naming convention
SM counters are named so that their names clarify their purpose and are
organized to provide one set of counter names between the GPRS and UMTS
products. The counters are grouped by SM procedure, and the names are
prefixed with the initiator of the procedure. Included in the name is also the
cause code sent to the mobile or the Nortel specific reason that the SGSN sent
a cause to the mobile. Where there are several reasons the SGSN sends a

particular cause code to the mobile, a separate group which enumerates the
predominant reasons exists. The few counters in one group or record where
the counters do not describe a particular procedure are collected together.
The SM counter naming convention is:

Procedure
Initiator
Cause
Nortel specific reason
General SM counters
Operational attributes and collected events are provided for SM information
not specific to an SM procedure. These counters track activity on a per-GSC
basis. This includes:
• Peak number of active PDP contexts
• Peak and current number of subscribers with one or more active contexts
sharing an APN and PDP address where at least one of these contexts
were activated as secondary PDP contexts.
• Peak and current number of active subscribers
• Peak roamers
• Peak QoS reliability
• Total PDP context activation attempts
• Total PDP context activation successes
• Total PDP context activation failures
SM status from mobile

Operational attributes and collected events are provided for causes that the
SM receives in the SM STATUS message from the mobile. These counters
track activity on a per-GSC basis.
Activation
Operational attributes and collected events are provided to describe activation
attempt, success and failure scenarios for primary and secondary PDP
contexts. To differentiate between failures on the SGSN and failures on the
GGSN, a group and a record are added to count the failure cause codes that
the GGSN sends the SGSN in the CREATE PDP CONTEXT RESPONSE
message. Also, to further the GPRS/UMTS counter unification effort, of these
new operational and collected counters, thirteen GPRS counters and eleven
UMTS counters already exist in the system and constitute a name change
only. GPRS attribute nsapiAlreadyUsed is removed since, according to the
3GPP v4 standards, only SGSNs using a version of software prior to R99
send this cause code to the mobile.

Deactivation
Operational attributes and collected events describe deactivation attempt,
execution and failure scenarios. To further the GPRS/UMTS counter
unification effort, of these new operational and collected counters, six GPRS
counters and four UMTS counters already exist in the system and constitute a
name change only. These counters do not distinguish between primary and
secondary PDP context deactivations because there is no concept of primary
and secondary PDP context once a mobile has activated a PDP context.
In GPRS 5.0 and all UMTS releases, when a path failure or a GGSN restart
restoration occurred, Nortel counted them as a GGSN initiated deactivation.
In GPRS 6.0 and UMTS 4.0, Nortel counts them as a SGSN initiated
deactivation. This is because, although it is not clearly an SGSN failure in the
case of the path failure and the failure occurred in the GGSN in the case of the
GGSN restart restoration, it is the SGSN which initiated and executed the
deactivation. The counter names, sgsnDeactReactReqGgsnFailure and
sgsnDeactReactReqGgsnRestart, do clearly indicate that the SGSN initiated
the deactivation and that it occurred because of a path failure or a GGSN
restart restoration. Also, this feature removes UMTS attribute
attemptedNetworkDeactivationsPdpC because network deactivations cannot
fail, and therefore a statistic counting the number of deactivations that the
network attempted makes no sense. As such, the naming convention adds the
word “Executed” instead of “Attempts” in the counter names for SGSN and
GGSN initiated deactivations. Also as a result of this feature, the SGSN-
Initiated Session Deactivations Cause Code Reporting Alarm (7068 1029) is
obsolete.
Inter-Routing Area Update

Operational attributes and collected events are provided to describe the
effects of IRAU on a mobile’s PDP context on the old SGSN and on the new
SGSN. The name of the new counters clearly differentiate between events
which occurred on the old and those that occurred on the new SGSN. Also, to
differentiate between failures on the SGSN and failures on the GGSN, a
group and a record are added to count the failure cause codes that the GGSN
sends the SGSN in the UPDATE PDP CONTEXT RESPONSE message.
Modification
Operational attributes and collected events are added to describe the total
number of modified PDP contexts. Two GPRS IRAU counters are moved
from the GprsSmPdpStatistics record to the new modification group.
Routing Area Update

New operational attributes and collected events are introduced for inter-SGSN
and intra-SGSN Routing Area Update reject scenarios under the Gsc Gmm
component. These counters track activity on a per-GSC basis.
• IMSI unknown in HLR.

• Illegal MS.
• GPRS services not allowed.
• GPRS services and non-GPRS services not allowed.
• MS identity cannot be derived by the network
• Implicitly detached.
• PLMN not allowed.
• Location area not allowed.
• Roaming not allowed in this location area.
• GPRS services not allowed in this PLMN.
• Network failure.
• Congestion.
• No suitable cell in location area.
• Protocol errors which include the following possible cause values:
— Semantically incorrect message.
— Invalid mandatory information.
— Message type non-existent or not implemented.
— Message type not compatible with protocol state.
— Information element non existent or not implemented.
— Conditional IE error.
— Message not compatible with the protocol state.
— Unspecified protocol error.
SCCP UDTS failure

New operational attributes and collected events are introduced for SCCP
UDTS failure cause codes system activity under the Tcap component. These
counters are converted from the MAP Notice Indication Display Alarm (7068
1520), which is now obsoleted by the counters. The former TCAP message
alarm counters were previously maintained in application software and sent
from the TCAP card to MDM, but not displayed via component
administration system (CAS).
For inbound SCCP notice indications corresponding to each MAP dialogue

type listed below, one counter is added for the “No Translation for this Address”
cause value and one counter is added for all other cause values.
• UGL
• SAI

• MOFSM
• MTFSM
• RFSM
• ISD
• PMS
Call model validation

The following counters are introduced for Call Model Performance
Validation. These counters have been specified by Nortel System Engineering
team as the necessary set of counters to accurately measure and validate the
Nortel Standard Call Model for both UMTS and GPRS SGSN.
GPRS Subscriber Control

New operational attributes and collected events are added for GPRS Subscriber
Control under the Gsc Gmm component. The MS initiated detach procedure
and SGSN initiated detach procedure counters are broken down into multiple
counters and the existing Inter-SGSN routing area update for new SGSN
counter is renamed as described in “GMM Attach/Detach/IRAU/RAU
Procedures” on page 7-19.
• Maximum number of attached subscribers.
• Maximum number of subscribers in the ready state.
• Maximum number of subscribers in the standby state.
• Current number of subscribers in the standby state.
• Number of subscriber transitions from idle to ready state.
• Number of subscriber transitions from standby to ready state.
• Number of subscriber transitions from idle to standby state.
• Number of subscriber transitions from ready to standby state.
• Number of subscriber transitions from standby to idle state.
• Number of subscriber transitions from ready to idle state.
GSD packet size distribution

Two new operational attributes and two new collected events are added under
the Gsd component to reflect data packet size distribution intervals in 64 byte
increments. Each of the twenty five increments is counted in both the downlink
and uplink directions.
• Number of packets with a size of 0 to 63 bytes.


GMM Attach/Detach/IRAU/RAU Procedures

Existing attach, detach, RAU and IRAU counters are reorganized within new
groups under the Gsc Gmm component. Corresponding counters used in
previous product releases are moved and in some cases are also renamed.
Additional counters are introduced to further refine the attaches rejected due
to congestion and network failure counters. The following sections describe
the new groups.
Attach group
Operational attributes and collected events are introduced for the following
Attach scenarios:
• Total attach requests received from MS.
• Total combined attach requests.
• Attach requests with known P-TMSI.
• Attach requests with unknown P-TMSI.
• Attach requests with known TLLI.
• Attach requests with unknown TLLI.
• Attach requests with IMSI already known.
• Attach requests with IMSI unknown.
• Ignored duplicate attach requests.

• Aborted attach requests.

• Ignored attach requests.
• Attaches rejected due to IMSI classification.
• Attaches rejected due to illegal MS.
• Attaches rejected due to illegal ME.
• Attaches rejected due to GPRS services not allowed.
• Attaches rejected due to GPRS services and non-GPRS services not
allowed.
• Attaches rejected due to PLMN not allowed.
• Attaches rejected due to location area not allowed.
• Attaches rejected due to roaming not allowed in this location area.
• Attaches rejected due to GPRS services not allowed in this PLMN.
• Attaches rejected due to no suitable cell in location area.
• Attaches rejected due to network failure.
• Attaches rejected due to congestion.
• Attaches rejected due to protocol errors.
• Attach rejects not included in other reject counters.
• Total failed combined attach requests.
• Combined attaches rejected due to IMSI unknown in HLR.
• Combined attaches rejected due to unreachable MSC.
• Combined attaches rejected due to network failure.
• Combined attaches rejected due to congestion.
• Successful attaches.
• Successful attaches with P-TMSI allocated.
• Attach procedures that received an AttachComplete message.
Detach group
Operational attributes and collected events are introduced for the following
detach scenarios.
• Total detach requests received from MS.
• Combined detach requests.
• IMSI detach requests.
• MS power off detach requests.
• Duplicate detach requests.

• Ignored duplicate detach requests.

• Detach requests ignored due to P-TMSI collision.
• Rejected detach requests.
• Successful detaches.
• Network initiated detaches.
• Network initiated detaches due to HLR cancel location.
• Network initiated detaches due to timer expiration.
• Network initiated detaches due to network failure.
• Network initiated detaches due to MS re-attaching without first detaching.
• Network initiated detaches due to subscription withdrawn.
• Network initiated detaches with reattach required set.
Intra-SGSN RAU group

New operational attributes and collected events are introduced for Intra-SGSN
RAU. The counters for rejected IRAU replace the I/RAU Requests Rejected
Alarm (7068 1027).
• Total RAU requests.
• Number of normal RAU requests.
• Number of periodic RAU requests.
• Total combined RAU requests.
• Ignored duplicate RAU requests.
• Aborted RAU requests.
• Ignored RAU requests.
• Normal RAU requests rejected.
• Periodic RAU requests rejected.
• RAU requests rejected due to IMSI classification.
• RAU rejected due to illegal MS. *
• RAU rejected due to illegal ME.
• RAU rejected due to GPRS services not allowed. *
• RAU rejected due to GPRS services and non-GPRS services not allowed.
*
• RAU rejected due to MS identity cannot be derived by the network. *
• RAU rejected due to implicitly detached. *
• RAU rejected due to PLMN not allowed. *

• RAU rejected due to location area not allowed. *

• RAU rejected due to roaming not allowed in this location area. *
• RAU rejected due to GPRS services not allowed in this PLMN. *
• RAU rejected due to no suitable cell in location area. *
• RAU rejected due to network failure. *
• RAU rejected due to congestion. *
• RAU rejected due to protocol errors. *
• RAU rejected due to P-TMSI collision.
• RAU rejects not included in other reject counters.
• Total failed combined RAU requests.
• Combined RAU rejected due to IMSI unknown in HLR. *
• Combined RAU rejected due to unreachable MSC.
• Combined RAU rejected due to network failure.
• Combined RAU rejected due to congestion.
• Successful RAU.
• Successful RAU with P-TMSI allocated.
• RAU procedures that received a RauComplete message.
* These counters are the same as those described in “Routing Area Update”
on page 7-16.
Inter-SGSN RAU group

New operational attributes and collected events are introduced for Inter-SGSN
RAU. The counters for rejected IRAU replace the I/RAU Requests Rejected
Alarm (7068 1027). Except as noted, all counters are pegged by the new SGSN.
• Total IRAU requests.
• Number of normal IRAU requests.
• Total combined IRAU requests.
• Ignored duplicate IRAU requests.
• Aborted IRAU requests.
• Ignored IRAU requests.
• Normal IRAU requests rejected.
• IRAU requests rejected due to IMSI classification.
• IRAU rejected due to illegal MS. *
• IRAU rejected due to illegal ME.

• IRAU rejected due to GPRS services not allowed. *

• IRAU rejected due to GPRS services and non-GPRS services not allowed.
*
• IRAU rejected due to MS identity cannot be derived by the network. *
• IRAU rejected due to implicitly detached. *
• IRAU rejected due to PLMN not allowed. *
• IRAU rejected due to location area not allowed. *
• IRAU rejected due to roaming not allowed in this location area. *
• IRAU rejected due to GPRS services not allowed in this PLMN. *
• IRAU rejected due to no suitable cell in location area. *
• IRAU rejected due to network failure. *
• IRAU rejected due to congestion. *
• IRAU rejected due to protocol errors. *
• IRAU rejected due to P-TMSI collision.
• IRAU rejects not included in other reject counters.
• Total failed combined IRAU requests.
• Combined IRAU rejected due to IMSI unknown in HLR.*
• Combined IRAU rejected due to unreachable MSC.
• Combined IRAU rejected due to network failure.
• Combined IRAU rejected due to congestion.
• Successful IRAU.
• Successful IRAU with P-TMSI allocated.
• IRAU procedures that received a RauComplete message.
• Attempts to move a MS to a new SGSN (pegged by the old SGSN).
• Uncompleted attempts to move a MS to a new SGSN (pegged by the old
SGSN).
SGSN Congestion Attach Rejects group

New operational attributes and collected events are introduced which further
break down the attaches rejected due to congestion attribute based on vendor
specific reasons for the standard congestion cause. These counters replace the
Attach Reject Cause Code Reporting Alarm (7068 1028). The sum of the SGSN
congestion attributes listed below is not intended to equal the value of the
attaches rejected due to congestion attribute.
• Maximum number of supported subscribers reached.

• MAPC resource exhaustion.

• External resource exhaustion reported by MAP.
• P-TMSI collision.
• LLC resource exhaustion.
• HLRC resource exhaustion.
• Procedural context exhaustion.
Network Failure Attach Rejects group

New operational attributes and collected events are introduced which further
break down the attaches rejected due to network failure attribute based on
vendor specific reasons for the standard network failure cause. These counters
replace the Attach Reject Cause Code Reporting Alarm (7068 1028). The sum
of the network failure attributes listed below is not intended to equal the value
of the attaches rejected due to network failure attribute.
• SGSN internal error.
• Mobile station reset failure.
• Mobile station security procedure failure. *
• Unsupported mobile station ciphering algorithm.
• HLR UGL failure.
• HLR SAI failure.
• Unsupported RAI.
Per-Cell group
The descriptions for fourteen operational attributes and fourteen collected
events are changed in the Gsc/n Mcc/ Mnc/ Lac/ Rac/ CellId/ component. This
is done to maintain consistency with the definitions of counters described in
previous sections. In addition, one per-cell operational attribute and one per-
cell collected event are renamed due to compiler restrictions.
• Total attach requests received from MS.
• Attaches rejected due to illegal MS.
• Attaches rejected due to GPRS services not allowed.
• Attaches rejected due to roaming not allowed in this location area. *
• Attaches rejected due to PLMN not allowed.
• Attaches rejected due to GPRS services not allowed in this PLMN.
• Attaches rejected due to network failure.
• Attaches rejected due to congestion.
• Attaches rejected due to protocol errors.

• Network initiated detaches due to HLR cancel location.

• Network initiated detaches due to timer expiration.
• Network initiated detaches due to network failure.
• Network initiated detaches due to MS re-attaching without first detaching.
• Network initiated detaches with reattach required set.
Other groups
One new operational attribute and one collected event are introduced to track
P-TMSI reallocations independent of GMM procedures.
• Explicit P-TMSI reallocations.
GPRS5.0.1/UMTS3.0.1 performance management content

The following counters are added/deleted to ensure changes made to
GPRS5.0.1/UMTS3.0.1 performance management content are reflected in
future releases.
Added counters
The following new operational attributes and collected events are added to the
GsdRelayLayer component.
• Packets discarded due to full bucket.
• Packets discarded due to blocked BVC.
• Packets discarded due to flow control LLC window.
• Packets discarded due to suspended mobile.
One new operational attribute and one new collected event are added to the Gsc
ServiceSwitchingFunction component.
• CAP messages that failed to receive a SCP response.
Deleted counters
Two operational attributes and two collected events are removed from the
GprsMobilityManagement component. These counters were introduced in
GPRS5.0.1 but are superseded by the new per-cause IRAU/RAU reject
counters.
• Total number of rejected IRAU requests.
• Total number of rejected RAU requests.

P-TMSI collision
Four new operational attributes and four new collected events are introduced
for under Gsc Gmm for SGSN P-TMSI enhancements. These counters are
included in the new SGSN congestion attach rejects, detach, IRAU and RAU
groups, so all four counters are previously described in “GMM Attach/Detach/
IRAU/RAU Procedures” on page 7-19.
• attachRejCngPtmsiCollision - Attaches rejected due to congestion with a
reason of P-TMSI collision.
• msDetachReqIgnoredPtmsiCollision - Detach requests ignored due to P-
TMSI collision.
• rauRejIdNotDerivedPtmsiCollision - RAU rejected due to P-TMSI
collision.
• irauRejIdNotDerivedPtmsiCollision - IRAU rejected due to P-TMSI
collision.
Displaying GMM and SM counters

Base Passport (safely) truncates CAS output at 8K bytes. Since displaying all
GMM or SM attributes may exceed the 8K limit, counters under these
components are best displayed either individually or by group. To quickly
determine which groups are available under the GMM and SM components,
the “show” verb has been added (because the “help” output is too verbose).
Following is an example of using the “show” verb for the GMM component.
4> show gsc/12 gmm

Gsc/12 Gmm
Component GprsMobilityManagement
Provisionable Groups
Prov
CauseMapping
Operational Groups
State
Attach
AttachCng
AttachNwk
SnrOper
Detach
Rau
Irau
Misc
StatusRx
Circuit
ok 2004-06-10 19:56:38.49
5> d gsc/12 gmm attach

Gsc/12 Gmm

msAttachRequests = 0
attachReqAccepted = 0
attachReqAcceptedPtmsiRealloc = 0
msAttachCompletes = 0
msAttachReqCombined = 0
msAttachReqKnownTlli = 0
msAttachReqUnknownTlli = 0
msAttachReqKnownImsi = 0
msAttachReqUnknownImsi = 0
msAttachReqDuplicate = 0
msAttachReqAborted = 0
msAttachReqIgnored = 0
. . .
attachCombNetworkFailure = 0
attachCombCongestion = 0
ok 2004-06-10 19:56:47.89

Displaying GSC success rates 7

Information about the health of a GSC can be obtained using a tool that
allows quick display of GSC success rates. Operational attributes reflect the
calculation of GSC attach, activation, RAU and IRAU success rates as well as
PDP context retainability. Attach and activation success rates are shown from
both a nodal and overall network perspective. The attributes are available
through the CAS command “d gsc/* health” as shown in the following
example.
CAS> d gsc/* health

Gsc/*
+===+---+---+---+---+---+---+----+----------------------------
|Gsc|att|att|act|act|pdp|rau|irau|Response
| | %|Nwk| %|Nwk|Ret|Nwk|Nwk |
| | | %| | %| %| %| %|
+===+---+---+---+---+---+---+----+----------------------------
| 6 |100|100|100|100|100|100| 100|
ok
Group Gsc Health contains the calculated operational attributes that represent
the health of services provided by subscriber control functionality. For
descriptions of these attributes and the formulas used to calculate the success
rates, refer to NTP 411-5221-060, Nortel SGSN Components Reference
Manual.

Attribute values are calculated at a frequency determined by the Sgsn Gsc
attActAlarmUpdatePeriod attribute. This means if the
attActAlarmUpdatePeriod is set to three minutes, there will be a three minute
window during which the Gsc Health group attribute values will not change.
In addition, the data used for calculating attribute values is based on the most
recently completed three minute window and may not represent the precise
SGSN state at the time the display command is issued.

Attach and activate failure alarms 7

The SGSN provides the following SET/CLR alarms for monitoring failures
that may occur when an MS performs an attach to the network or activates a
PDP context:
• 7068_1574 - Attach Success Rate Threshold Alarm—this alarm is issued
with major, minor or cleared severity depending on the current state of the
alarm and the relationship between the calculated attach success rate and
the provisionable major, minor and clear thresholds.
• 7068_1575 - Activation Success Rate Threshold Alarm—This alarm is
issued with major, minor or cleared severity depending on the current
state of the alarm and the relationship between the calculated activation
success rate and the provisionable major, minor and clear thresholds.
Complete alarm descriptions are provided in NTP 411-5221-500, Nortel

SGSN Alarms Reference Manual.
For information about monitoring activation success rates and the detailed
formulas used to calculate success rates, refer to NTP 411-5221-050, Nortel
SGSN/GPRS Monitoring Guide.
Alarm operation
The purpose of the attach and activate success rate threshold alarms is to alert
network operators to issues causing attach and PDP context activation
failures. These alarms are issued based on the attach/activate success rates.
The basic formula is calculated as follows:
Success Rate = 100% * successes/(successes + failures)
This equation shows that the success rates are obtained by collecting the sum
of the successful attempts and the sum of the failed attempts over the
collection interval and finding the percentage of total attempts that were
successful. The use of the success equation is shown in Figure 7-6.

Figure 7-6
Sliding window success calculation
As illustrated in Figure 7-6 the collection window (width ww) is comprised of

a series of window update periods (wups). Each time a wup elapses, the data
from that wup replaces the oldest wup data in the window. For example,
consider the following data.
Table 7-2
Sample success calculation data points
Window update period Number of successful Number of failed

instance number attempts attempts
1 15 1
2 25 2
3 10 3
4 20 1
5 22 1
—sheet 1 of 2—

Table 7-2
Sample success calculation data points (continued)
Window update period Number of successful Number of failed

instance number attempts attempts
6 14 2
—sheet 2 of 2—
Using a 3 minute window update period and a 15 minute window width, the
first success rate calculation can be performed over the window consisting of
wups 1 through 5. Since, during this window, there were 92 successful
attempts and 8 failed attempts, the success rate is calculated as S = 92/(92+8)
= 92%. After the next window update period, the new wup data (14
successful, 2 failed) replaces the oldest wup data in the window (15
successful, 1 failed), and the success rate becomes S = 100 x 91/(91+9) =
91%.
After each window update period, the success rate is calculated and the
attach/activate alarms are updated as appropriate (provided enough wups
have passed to fill a window).
The attach/activate alarms have three states and three thresholds:

• The alarm moves from the “no alarm” state to the “minor alarm” state
when crossing the minor threshold, and from the “no alarm” state to the
“major alarm” state when crossing the major threshold. If the success rate
stays above these thresholds, then the alarm will not move from the “no
alarm” state.
• The alarm moves from the “minor alarm” state to the “no alarm” state
when crossing the clear threshold and from the “minor alarm” state to the
“major alarm” state when crossing the major threshold. If the success rate
stays between the major and clear thresholds, the alarm will not move
from the “minor alarm” state.
• The alarm moves from the “major alarm” state to the “minor alarm” state
when crossing the minor threshold, and from the “major alarm” state to
the “no alarm” state when crossing the clear threshold. If the success rate
stays below these thresholds, then the alarm will not move from the
“major alarm” state.
The operation of this state machine is illustrated in Figure 7-6, where the
minor threshold is 95%, the major threshold is 90% and the clear threshold is
98%. When the window update period ends at minute 27, the success rate
for the preceding 15 minute window drops to 93.6%. This is below the
minor threshold of 95%, so a minor alarm is issued at minute 27.

When the window update period ends at minute 36, the success rate for
the preceding 15 minute window drops to 89.4%. This is below the major
threshold of 90%, so a major alarm is issued at minute 36. When the window
update period ends at minute 48, the success rate for the preceding 15 minute
window rises to 95.5%. This is above the minor threshold of 95%, so
the major alarm is converted to a minor alarm at minute 48. Finally, when
the window update period ends at minute 54, the success rate for the
preceding 15 minute window rises to 98.1%. This is above the clear
threshold of 98%, so the minor alarm is cleared at minute 54.
The minimum data requirement prevents possibly insignificant attach/activate

problems from causing major alarms. Without such a requirement, a single
attach/activate failure could generate a major alarm when usage is very low.
For example, using the default major, minor and clear thresholds, if only 9
users attach to the network during one collection interval, a single failure
would bring the success rate down to 89% and cause a major alarm. It would
take 41 more successful attaches with no more failures to clear the
alarm. Requiring a minimum number of data points reduces the
incidence of such trivial alarms; however, the higher the minimum number
of data points, the lower the alarm responsiveness, so this value should be
provisioned such that responsiveness and usefulness are balanced. The
default value of 100 ensures that no single failure can contribute more than
one percentage point to the failure rate.
Provisioning
The following provisionable attributes are available in the Sgsn Gsc
ScGlobalProv group for setting the sliding window parameters and the alarm
thresholds:
• attActAlarmUpdatePeriod—specifies how often attach and activate

success rate calculations are performed and used for the purpose of alarm
generation.
• attActAlarmWindow—specifies the time interval over which attach and
activate data is considered, and it is comprised of a collection of update
periods. After each update period, the attach and activate success rates are
calculated using the data from the last window.
• attActAlarmMinDataThreshold—specifies the minimum number of
attach attempts or activate attempts that must be made during the
provisioned window for an attach or activate success rate to be calculated
for the purpose of alarm generation. If at the end of an update period
fewer than the minimum number of attempts have been made during the
last window, then no alarm changes will be made. Attach attempts and
activate attempts are considered separately.
• attAlarmMajorThreshold—specifies the minimum success rate required
to prevent a major attach success rate threshold alarm.

• attAlarmMinorThreshold—specifies the minimum success rate required

to prevent a minor attach success rate threshold alarm from being set. It is
also the minimum success rate required to convert a major alarm to a
minor alarm.
• attAlarmClearThreshold —specifies the minimum success rate required
to clear an attach success rate threshold alarm.
• actAlarmMajorThreshold—specifies the minimum success rate required
to prevent a major activation success rate threshold alarm.
• actAlarmMinorThreshold—specifies the minimum success rate required
to prevent a minor activation success rate threshold alarm from being set.
It is also the minimum success rate required to convert a major alarm to a
minor alarm.
• actAlarmClearThreshold—specifies the minimum success rate required to
clear an activation success rate threshold alarm.
For complete attribute descriptions, refer to NTP 411-5221-060, Nortel SGSN

Components Reference Manual. For provisioning procedures, refer to 411-
5221-904, Nortel SGSN/UMTS Provisioning Procedures.
Redundancy
The association between redundancy and alarms is largely based on whether
or not an alarm that was set and not cleared before a switchover can and
should be re-issued by the card that becomes active. In the case of the attach/
activate alarms, the card that becomes active after a switchover cannot re-
issue the alarms because of journaling restrictions. Since journaling only
takes place after a mobile is completely attached/activated, the inactive card
will never receive information about attach/activate failures. Accordingly,
attach/activate alarms cannot be re-issued automatically by the newly active
card after a switchover.

Alarms are not provided for attach/activate failures when no attach/activate
attempts are detected. It is assumed that other alarms will be generated for
faults that prevent detection of attach/activate attempts.
As stated in “Redundancy” above, attach/activate alarms cannot be re-issued

automatically upon switchover. If the condition that caused the alarm to be
set on the formerly active card is not present after switchover, then the alarm
does not need to be re-issued. However, if the condition still exists, at least
one collection interval will have to pass before the condition will be re-
alarmed on the newly active card. It could take more collection intervals to
re-raise the alarm if the minimum number of data points is not met.

Displaying IMSI information 7

Prior to the GPRS6.0 release, the component administration system (CAS)
command “d Sgsn Imsi/n” was used to obtain MobileContext (Mc),
SessionContext (Sc) and SubscriptionRecord (Sr) information for a particular
mobile. The operator did not need to know the specific GSC associated with
the IMSI to use this command. On a Passport with a single GSC the “d Sgsn
Imsi/n” command functioned normally. However, when there is load sharing
or when multiple GSCs are provisioned on the Passport, the command
malfunctioned as CAS is limited to handle only one response and not multiple
responses with respect to this command.
The “d Gsc/* imsi” command has the same functionality as “d Sgsn imsi” and
is also capable of handling multiple response cases. The wildcard character
“*” for the Gsc index allows the operator to display IMSI information without
knowing the actual GSC(s) on which the subscriber is attached.
To resolve the issue with the “d Sgsn Imsi” command, the Imsi subcomponent
under Sgsn is obsoleted and the “d Gsc/* Imsi/n” command now replaces the
“d Sgsn Imsi” command.
Clearing a GTP path 7

A Clear CAS command allows the operator to remove a GTP path based on a
given IP address. Resources allocated for the GTP path are released. A GTP
path must not have active PDP contexts.
Use the “-force” option to clear a GTP path that has active PDP contexts. The
“-force” option allows the operator to clear a GTP path that has active PDP
contexts. If the clear command succeeds with the “-force” the PDP contexts
are deactivated in a controlled manner and the path state is changed to
failureDeclared as indicated by the pathState attribute. Without this option the
clear command fails for a path that has active PDP Contexts. If the clear
command is used on a path with a state in failureDeclared a message is
displayed to the operator indicating that the path is failed and no action is
taken for the command.
The command syntax is:
clear [-force] gsc/n gtp path/<ip address>
Clearing an inactive mobile 7

The clear command causes an inactive mobile’s context and resources to be
deleted within the SGSN. As a side effect, if msPurge is enabled (see “MS
Purge” on page 5-88), a purge command is sent to the HLR. The inactive
mobile is defined by the IMSI. The command syntax is:
clear gsc/n imsi/<imsi>

To identify inactive mobiles, enter the command:
display gsc/* imsi/<imsi> mc gmmstate
Inactive mobiles have this field set to idle.
The clear command has no affect on mobiles that are not detached. If the clear
command is issued when a mobile is active, the following response is
returned:
Cannot clear non-detached mobiles

• Operator initiated immediate purge is allowed only on a detached MS. An
attempt to purge a non-detached mobile has no affect on either the MM
context or PDP context.
• Operator initiated immediate purge for multiple mobiles is not supported.
SGSN trace tools 7

The SGSN trace tools provide the ability to monitor both the control and
datapath packets as they are processed on the SGSN. Various levels of tracing
are supported that provide the ability to capture just packet headers or packet
headers and the associated payload data. The packets can be captured at every
internal interface corresponding to protocol layers as defined by the GPRS
specifications as well as all proprietary software layers. In addition, the tools
provide the ability to capture software layer state information and variables at
the time of packet processing. A command line help file is also available on
the SGSN. All traced information can be spooled to a user console or to the
disk resident on the CP for later extraction and analysis.
These tools are for use by design, product test, support, TAS, and other
internal Nortel support groups only.

SC Diagnostic Tool 7
The Subscriber Control (SC) Diagnostic Tool is used for diagnosing and
debugging failures under traffic conditions. This tool emits a message alarm
for attach or activate failures for a particular IMSI and provides a reason for
the failure. Capabilities of the tool are:
• Reports failures for up to 5 pilot mobiles without throttling.
(Provisionable)
• Reports failures for all other IMSIs with throttling. The tool generates
only a provisioned number of alarms for a given period of time. Extra
alarms generated are suppressed and corresponding internal counters are
pegged. The types of failures reported are also provisionable.
• When enabled, the tool monitors the failures. If a failure occurs, the tool
generates a message alarm that has information such as filename where
the failure occurred, line number where the failure occurred and a brief
text describing the failure.
An example is shown below:

Gsc/2; 2004-07-08 00:41:26.00
MSG warning debug debugging 70681034
AVAIL: PROC: CNTRL:
Id: 02000013 Rel: Lp/2
Com: Network Initiated Detach
IMSI: 310980972130064 P-TMSI: 0xec9b6fda
Reason: Mobile reachable timer expires, last activity
2004-07-07 22:40:35
Int: 2/0/2/11057; gmm2gPrimaryRegStyImplicit.cc; 551; ""
Provisioning
The SC Diagnostic Tool is provisioned under the Gsc Diagnostics
component. Provisioning the tool involves adding the component, adding
IMSIs to the list of pilot mobiles, setting alarms message throttling, and
provisioning the types of failures reported.
Add the Diagnostics component

The following provisioning command adds the Diagnostics optional
component to Gsc:
prov #>add gsc/xx Diagnostics
Add IMSIs to the pilot mobile list

The pilotMobileList attribute is used to provision up to 5 IMSIs. The
following example adds 3 IMSIs to pilotMobileList. Failures from these

mobiles are reported regardless of the restrictions imposed by the attributes

alarmMaxMessages, alarmPeriod and alarmEvents.
prov #>set gsc/xx Diagnostics pilotMobileList IMSI1 IMSI2

IMSI3
Set message throttling

Attributes alarmMaxMessages and alarmPeriod throttle the message alarms
reported by non-pilot mobiles according to the provisioned values. The
following example sets message alarms reporting failures from non- pilot
mobiles to a maximum rate of 10 per 15 minutes. All the other alarms will be
suppressed by the tool.
prov #>set gsc/xx Diagnostics alarmMaxMessages 10

prov #>set gsc/xx Diagnostics alarmPeriod 15
Set alarm mode

Currently the alarm mode can be only set to brief mode as shown in the
following example. Verbose mode may be supported in a future release.
prov #>set gsc/xx Diagnostics alarmMode brief
Set alarm events

The alarmEvents attribute controls the type of failure reported by the non-
pilot mobiles. Attach, activation, security and some general failures are
supported. The following example shows setting the alarm events:
prov #>set gsc/xx Diagnostics alarmEvents attachFailure

activationFailure securityFailure generalFailure
By default , attachFailure, activationFailure, securityFailure, and

generalFailure are enabled. Any of these can be disabled. The following
example shows disabling attachFailure. In this case, alarms reporting attach
failures from non-pilot mobiles will be suppressed and only activation,
security and general failures will be reported .
prov #>set gsc/xx Diagnostics alarmEvents ~attachFailure

Alarms
Table 7-3 through Table 7-5 describe SC Diagnostic Tool alarms for attach
failures, security failures and activation failures for GPRS and UMTS.
Table 7-3
SC Diagnostic Tool security alarms
Alarm Operator Alarm Description

No.
Security Failures
1. Security: Auth Ciph Response The Authentication Ciphering Response message

Message not valid. Cause is received is invalid.
‘cause’
2. Security: Assign Data Cnf The received Assign Data Confirm message is
Message not valid invalid. Security Failed.
3. Security: Auth Ciph Resp has msg The received Authentication and Ciphering response
error: ‘error’ message is invalid. The cause is specified in the
alarm.
4. Security: Identity Response The received identity response is invalid. The cause
Message not valid. Cause is is specified in the alarm.
‘cause’
5. Security: Iov Cnf msg not valid Invalid Iov Confirm message was received. Security
failed.
6. Security: Auth Ciph Resp msg not Timer expired while waiting for Authentication
recv, retries exhausted Ciphering Response. The specified number of retries
also expired. Security Failed.
7. Security: Failed to receive Identity Timer expired while waiting for Identity Response.
Response. Retries Exhausted. The specified number of retries also expired.
Security Failed.
8. Security: Assign Data Cnf Failed to receive Assign Data Confirm message in
Message not recv, retries specified time. The retries also got exhausted.
exhausted
9. Security: No ID Response from Timer expired while waiting for Identity Response.
mobile. Exhausted retries The specified number of retries also expired.
Security Failed.
10. Security: Iov Cnf msg not recv, Failed to receive Iov Confirm message in specified
retries exhausted time. The retries also got exhausted.
—sheet 1 of 3—

Table 7-3
SC Diagnostic Tool security alarms (continued)

No.
11. Security: Failed to receive Security Timer expired while waiting for Security Mode
Mode complete. Retries complete. The specified number of retries also
Exhausted. expired. Security Failed.
12. Security: Suspend Failed Failed to perform Internal Suspend during security
procedure.
13. Security: IMSI has problems The IMSI used was found to have caused problems
earlier in interaction with HLR. Security failed.
14. Security: TLLI Collision TLLI collision encountered while performing security
procedure.
15. Security: Can not allocate Suspend Failed to allocate suspend and resume context while
and Resume context initiating the security procedure.
16. Security: Could not send Assign Failed to send LLC Assign Request to GSD. This
Req. to LLC might also be due to failure to start the timer.
17. Security: Could not send Iov Req. Failed to send Iov Request. This might also be due to
to LLC failure to start the timer.
18. Security: Could not send Identity Failed to send Identity Request. This might also be
Req. due to failure to start the timer.
19. Security: Could not send Auth and Failed to send Authentication and Ciphering Reject.
Ciph Reject This might also be due to failure to start the timer.
20. Security: Could not send Auth Trip Failed to send Authentication triplets request. This
Req. might also be due to failure to start the timer.
21. Security: Failed to send Security This occurs when SGSN fails to send the Security
Mode Info. Mode Info to the RNC.
22. Security: Failed to send Auth and The SGSN failed to send an Authentication and
Ciph request. Ciphering request to the MS. Security fails.
23. Security: LLC could not assign LLC could not perform Assign successfully due to the
successfully. LLC Internal Error: specified internal error. Security failed.
‘error’
24. Security: LLC could not perform LLC failed to perform Iov due to the specified internal
Iov. LLC Internal Error: ‘error’ error.
—sheet 2 of 3—

Table 7-3
SC Diagnostic Tool security alarms (continued)

No.
25. Security: Invalid SRES. MS was Invalid SRES received in Authentication and
attaching with imsi Ciphering response while MS was performing IMSI
attach. No identity request is performed as IMSI is
already known. Attach is rejected.
26. Security: Ms failed authentication The mobile has failed the authentication.
27. Security: Auth Cipher Response Security failed as XRES in Authentication Ciphering
XRES is not equal to RES. response did not match. This may be an invalid
mobile.
28. Security: Ciphering failure This happens when a ciphering failure message is
message received. received from the mobile.
29. Security: MAP Error occurred Failed to retrieve Authentication vectors due to
while retrieving auth vectors, specified map errors. The internal error is also
mapError: ‘map error’, 0408 cause: specified in the alarm.
‘0408 cause’. MAP Client Internal
Error: ‘error’
30. Security: Unable to find HLRC This occurs if the HLRC context could not be found
context. for the IMSI in the attach request, while performing
the security procedure.
31. Security: IMSI not found in the This happens during security procedure when SGSN
mobile contexts. is unable to find the IMSI.
32. Security: Error in received HLRC This occurs when the received HLRC Authentication
Auth Vectors. vectors has some error. The error may be internal or
maybe a MAP error.
33. Security: Failed to negotiate This occurs when the SGSN is not able to negotiate
Ciphering Algorithm the Ciphering Algorithm with the MS. Security fails.
34. Security: ID Response message The Identity response has the wrong Identity type.
has wrong Mobile Identity type (not SGSN was expecting IMSI as the Identity type.
IMSI)
35. Security: Received a Security Security failed as SGSN received a Security Mode
Mode Reject Reject.
—sheet 3 of 3—

Table 7-4
SC Diagnostic Tool activation alarms

No.
Activation Failures
1. Activation: Apn Selection Failure This occur when APN requested is missing or
unknown. This could also happen when Access was
not requested through VPLMN first in previous DNS
Agent query.
2. Activation: DNS Responded with DNS responds with an unknown error. This alarm is
an Unknown Error not used.
3. Activation: No IP Address is DNS Agent did not return any IP address for the
returned by DNS GGSN for the APN selected. Send activate reject to
the MS.
4. Activation: GGSN Failed to Create This happens when SM fails to setup a tunnel with
a Tunnel GGSN. One of the reasons could be that a valid IP
address is not found from the GGSN address list.
5. Activation: SM Could not send a This happens when SM fails to send Create PDP
Message to GTP layer Context Request to GTP-C layer.
6. Activation: GGSN has Responded This could happen when the current GGSN is not
with an Error Cause or has not responding and there are no more valid IP
responded and there are no more Addresses for the APN selected.
GGSN's to Activate
7. Activation: SM could not send a Activation is rejected when SM is not able to send the
Mapping Request to DNS mapping message to the DNS Agent from the DNS
proxy.
8. Activation: SM could not send a Activation is rejected when SM could not successfully
RAB Assignment Request to RNC send a RAB Request to RNC.
9. Activation: SM could not send a Activation is rejected when SM failed to send a

message to Subscriber Data card message (Create or Activate session indication
message) to Subscriber Data card (relayProxy
failure).
10. Activation: SM could not send a Activation is rejected when SM failed to send a
message to Mobile message (ActivatePdpContext Accept) to MS
(msProxy failure).
11. Activation: Subscriber Data card Activation is rejected when SM gets a response
could not create a Session failure from Subscriber Data card for create session
request.
—sheet 1 of 4—

Table 7-4
SC Diagnostic Tool activation alarms (continued)

No.
12. Activation: RNC could not Assign a Activation is rejected when there is a failure in RAB
RAB to the session assignment.
13. Activation: Relay function could not Activation is rejected when the final tunnel setup fails
establish the final tunnel setup because of relay failure.
14. Activation: SM could not start an Activation is rejected when the Overall activation
Over all Activation Timer Timer is not started successfully while processing
ActivatePdpContext request.
15. Activation: Activation Timer Expired Activation is rejected when the Activation timer gets
waiting for Security confirmation expired while waiting for Security confirmation from
from GMM GMM to activate the request.
waiting for a DNS Response expired while waiting for DNS response.
waiting for an Initial Tunnel setup expired while waiting for an Initial Tunnel setup
Response from SD card Response from SD card.
18. Activation: Activation Timer Expired Timer expiry while waiting for a CreatePdpContext
waiting for a Response from GGSN response from GGSN.
19. Activation: Activation Timer Expired Timer expires while waiting for RAB assignment
waiting for a Response from RNC response from RNC.
for RAB
20. Activation: Activation Timer Expired Timer expiry while SM waits for activate session
waiting for a Final Tunnel Setup response from SD card.
from SD card
21. Activation: SM could not start a SM Failed to start RAB setup timer while handling
RAB Setup Timer the data associated with the RAB assignment
request.
22. Activation: DNS Responded with DNS agent sent an error.

an Error cause
23. Activation: Mobile has Requested a Activation is rejected when a Mobile sends a detach
Detach request.
24. Activation: Mobile has Requested a The rejection is caused by the mobile requesting a
Detach and the session is almost detach.
up
—sheet 2 of 4—

Table 7-4

No.
25. Activation: Mobile has Re-Attached When a mobile attaches while attached, activation
so cleaning up the sessions gets rejected for the first session.
26. Activation: GTP Declared a Path When a GGSN goes down or is reset, SM
Failure so Rejecting the Activation deactivates all tunnels that are created on that path.
27. Activation: GGSN has sent a Activation rejected by SM due to Delete PDP Context
Delete PDP Context Request for Request from GGSN.
this session
28. Activation: GGSN has Re Started Activation rejection because of restart of the GGSN
so cleaning up the session to which this session is associated.
29. Activation: Received a Delete A subscription can be invalidated at any time during
Subscription Data message from an activation. If the subscription is determined to be
HLR invalid while waiting for a response from GTP
indicating that a tunnel has been established
between the GGSN and the SGSN, the activation is
rejected.
30. Activation: There is a failure in The radio network or the signalling gateway card that
Radio Network (RNC) or SG so provides the connectivity between the SGSN and the
cleaning up the sessions radio network can fail. In that case, SM must reject
an activation on that network.
31. Activation: Subscriber Data card Activate rejected because of GSD/USD failure.
rebooted so cleanup the sessions
32. Activation: Mobile has sent a The MS wants to activate a session that is already
Duplicate Activate Request active, therefore SM deactivates the existing session
without contacting the MS.
33. Activation: Mobile has sent a Activation rejected because of request from mobile.
Deactivate Request, so cleanup
the session
34. Activation: Mobile has Requested Activation rejected because of Mobile Request in
to Detach in the middle of IRAU middle of a handover.
procedure
35. Activation: Security procedure Failed to send security message to GMM.

failed so rejecting the Activation
36. Activation: SM Received a Release SM received a failure or release message from SSF.
GPRS Message from SSF Layer
—sheet 3 of 4—

Table 7-4

No.
37. Activation: Received a SSF Error SM receives an SSF Error response.

from SSF Layer
38. Activation: Over ALL Activation Timer expiry while SM waiting for SSF response.
Timer Expired waiting for a
Response from SSF
39. Activation: Over All Activation Timer expiry while SM waiting for SSF
Timer expired waiting for an Ack activatePdpContext acknowledgement.
from SSF
40. Activation: Received IU Release Activation rejected because of IU Release Complete

Complete from RNC message from RNC.
41. Activation: Activation Timer Expired Timer expiry while SM waiting for response from
waiting for a PFM Agent Response PFM Agent.
42. Activation: Qos Negotiation failed Activation is rejected when negotiation of subscribed
between MS and SGSN. Qos with requested Qos fails between MS and
SGSN.
43. Activation: Activation Context Not Procedural context not found. This can happen at
Found. any state when SM tries to find the activation context.
44. Activation: Linked TI does not When a secondary PDP context is getting activated,
indicate an active context SM tries to find the primary active context linked with
it. Activation rejected when an active primary context
is not found.
45. Activation: GGSN In Use is GTPv0. This happens when a secondary PDP activation is
GTPv0 does not support attempted with a R97 GGSN. Secondary activation is
secondary activation. not supported by R97 GGSN.
—sheet 4 of 4—

Table 7-5
SC Diagnostic Tool general alarms

No.
General Failures
1. Mobile reachable timer expires: last Mobile reachable Timer has expired. The last activity
activity ‘last ActTime’ was reported at the time specified in the alarm.
2. Reset: Failure has occurred during MS Reset failed due to specified internal errors.
MS Reset. LLC Internal Error:
‘internal error’
3. Mobile has been idle for too long. Gsd Audit found that the mobile has been inactive for
Last activity: ‘time’ more than the provisioned time. The last activity of
the mobile was registered at the time specified in the
alarm.
Active alarm list 7

The active alarm list (AAList) feature is an optional base Passport feature that
is required on the SGSN beginning in GPRS6.0. This feature provides an on-
switch list that contains, at any specific time, a list of all active alarms that
were raised, but not yet cleared, on a Passport. The AAList is used to improve
the accuracy and completeness of fault reporting when connected to a
Wireless Network Management System (W-NMS) multiservice data manager
(MDM).
For more information on the active alarm list feature, refer to NTP 241-5701-
611, Passport 7400, 15000, 20000 Data Collection Guide.
Audit alarms 7
Audits performed on the SGSN (see “SGSN audits” on page 4-21) can generate
the following set/clear alarms:
• Memory corruption minor alarm - This alarm notifies the customer that
the minor threshold for corrupt memory blocks was crossed. The
customer should reset the FP as soon as possible.
• Memory corruption major alarm - This alarm notifies the customer that
the number of corrupt blocks on the FP has reached a critical level. This
alarm clears the memory corruption minor alarm, if it was set.
• Nodal manager component minor alarm - This alarm notifies the
customer that a non-critical FP is missing from the SGSN.
• Nodal manager component critical alarm - This alarm notifies the
customer that a critical FP is missing from the SGSN.

• Nodal manager SVC alarm - This alarm notifies the customer that the link
between two applications on the SGSN has gone out of service. The alarm
is generated only by the application responsible for creating the SVC.
Audits performed on the SGSN can generate the following console errors:
• FP reset software error - When an FP is about to be reset, an error
message is generated to the console.
For more information on these alarms, refer to NTP 411-5221-500 Nortel

SGSN Alarms.
Audit alarm generation can be disabled by Nortel personnel only.
Locking/unlocking a GSC 7
Lock and unlock are two common verbs provided by the Passport CAS
interface for the operator to block provisioned components from their
normal activities. A provisioned GSC can be locked and unlocked. The lock -
force option is also supported on the GSC.
Gsc lock operation

When the lock command is issued, the GSC will transition to “locked”
administrative state as follows:
• If there are no subscribers on the GSC, the GSC transitions to
“locked” administrative state immediately. No new subscribers will be
able to attach to the locked GSC.
• If there are subscribers on the GSC, the GSC transitions to
“shuttingDown” state. No new subscribers will be provided service on the
GSC. However existing mobiles on the GSC continue to receive service.
When all the subscribers on the GSC have detached, the GSC transitions
to “locked” administrative state. No new subscribers will be able to
attach to the locked GSC.
If a lock command is issued on a GSC that is already “locked”, the new

lock command is ignored.
Gsc lock - force operation

When the lock -force command is issued, the GSC transitions to “locked”
• If there are no subscribers on the GSC, the GSC transitions to
“locked” administrative state immediately. No new subscribers will be
able to attach to the locked GSC.
• If there are subscribers on the GSC, the GSC transitions to
“shuttingDown” state. No new subscribers will be provided service on the
GSC. However existing mobiles on the GSC will continue to receive
service. At the same time the GSC will start detaching mobiles

implicitly. In addition to implicitly detaching all mobiles on the GSC

card, the mobile context and the HLRC context will be removed and
not placed in the corresponding inactive queues. The detaching process
is throttled to minimize CPU impact. When all the subscribers on the GSC
have detached, the GSC will transition to “locked” administrative state.
No new subscribers will be able to attach to the locked GSC.
Gsc unlock operation

When the unlock command is issued, the GSC transitions to “unlocked”
• If the GSC is not in the process of detaching mobiles (because of a
previous lock -force command), the GSC transitions to “unlocked”
administrative state immediately. The GSC can now handle new
subscribers.
• If the GSC is in the process of detaching mobiles (because of a previous
lock -force command), the detach process is stopped and the GSC
transitions to “unlocked” administrative state immediately. The GSC
can now handle new subscribers.
If the unlock command is issued on a GSC that is not locked, the

command is ignored.
Daylight Savings Time adjustment 7

The SGSN can perform automatic time adjustment for Daylight Savings Time
(DST). The operator provisions the preset date and time when DST starts and
ends. The SGSN automatically changes the offset of the system. The
following timestamps on the SGSN are displayed in the adjusted local time
after the DST change (both start and end):
• Newly generated alarms

• Newly collected DCS
• Billing record (along with the new offset)
The SGSN uses the ModuleTime subcomponent under the Time component
to reflect the local time. When the offset is changed, the ModuleTime is
adjusted at the same time.
Fault management
When the automatic time adjustment for DST occurs, a message alarm is
displayed to log the event. Following is an example of the alarm:
Time; 2003-10-01 12:41:45.24

MSG warning operator operationalCondition 70150001
AVAIL: PROC: CNTRL:

Id: 0100001C Rel:

Com: Time offset changed by local operator for -3600 seconds.
Time was 2003-10-01 13:41:45
Int: 1/1/2/25132; ntsCasInterface.cc; 1351; G5016AW
The optional component DaylightSavingTime (DST) is responsible for
automatic time adjustment for DST. There are 3 provisionable attributes under
this component:
• springTimechange—specifies the date and time when this module’s time
is increased by the timeChangeOffset attribute.
• fallTimechange—specifies the date and time when this module’s time is
decreased by the timeChangeOffset attribute.
• timeChangeOffset—specifies the amount of time to change this module's
time.
The springTimechange and fallTimechange attributes must be manually

updated every year.
GMM Cause Code mapping 7

The SGSN provides a CAS provisionable mapping table that enables network
operators to specify the GMM cause codes that are sent to mobile stations for
MAP and DNS errors.
This feature manages the mapping of MAP errors, as defined in 3GPP TS

29.002, and DNS query failures to 3GPP TS 24.008 GMM cause codes and
non-standard network operator defined GMM cause codes. Network operators
can:
• display the cause value of each supported GMM cause code as defined in
3GPP TS 24.008
• specify the GMM cause codes that will be sent to mobile stations in the
GMM Attach Reject message or in the GMM Routing Area Update
Reject message, for the error scenarios when the SGSN queries the HLR
for subscriber information via the Gr interface, by linking the supported
MAP error to a GMM cause value from 1 to 255
• specify the GMM cause codes that will be sent to mobile stations in the
GMM Routing Area Update Reject message, for the error scenarios when
the SGSN queries the DNS server for DNS look up, by linking the DNS
query failure to a GMM cause value from 1 to 255
The attribute group Gsc Gmm GmmCauseCodeMappingProv

(CauseMapping) enables the network operator to display and provision the
mapping using CAS. Refer to NTP 411-5221-060 Nortel Networks SGSN
Components for more information.

Valid 29.002 MAP errors

Table 7-6 lists the MAP errors from which the GMM cause codes are derived.
Table 7-6
MAP errors valid for mapping
Error Remark
System Failure
Data Missing
Unexpected Data Value
Unknown Subscriber
GPRS Subscription Diagnostic value of the optional parameter –

Unknown unknownSubscriberDiagnostic for Unknown
Subscriber
Unidentified Subscriber
Roaming Not Allowed
PLMN Roaming Not Diagnostic value of the mandatory parameter –

Allowed roamingNotAllowedCause for Roaming Not
Allowed
Operator Determined Diagnostic value of the mandatory parameter –

Barring roamingNotAllowedCause for Roaming Not
Allowed
Illegal Subscriber
Illegal Equipment
Resource Limitation User Abort reason
Resource Unavailable User Abort reason
Resource Limitation Provider Abort reason
Unknown HLR Indicates that the SS7 network cannot find the
translation to the HLR
Valid 24.008 GMM Cause Codes

The GMM cause codes listed in Table 7-7 are based on 3GPP TS 24.008,
“Mobile Radio Interface Layer 3 Specification, Core Network Protocols,

Stage 3” (Release 4), section 4.7.3 Attach Procedure and section 4.7.5
Routing Area Update Procedure.
Table 7-7
Standard GMM Cause Codes valid for mapping
Cause Value Cause Code
2 IMSI unknown in HLR
3 Illegal MS
6 Illegal ME
7 GPRS services not allowed
8 GPRS services and non-GPRS services not allowed
9 MS identity cannot be derived by the network
10 Implicitly detached
11 PLMN not allowed
12 Location Area not allowed
13 Roaming not allowed in this location area
14 GPRS services not allowed in this PLMN
15 No Suitable Cells in Location Area
16 MSC temporarily not reachable
17 Network failure
22 Congestion
User Defined GMM Cause Code

The valid GMM cause value range is set from 1 to 255. Any cause value not
associated with any valid 24.008 GMM cause code (see “Valid 24.008 GMM
Cause Codes” on page 7-49) is considered a user defined GMM cause code.
The purpose of allowing network operators to define their own GMM cause
codes is for the flexibility to introduce new GMM cause codes, and also for
supporting their network’s services and roaming agreements. However,
network operators should avoid using user defined GMM cause codes that are
non-standard and may cause service impact to mobile stations and the system
networks.

MAP Error to GMM Cause Code default mapping

Table 7-8 shows the default mapping of MAP errors to GMM Cause Codes
for the PC04 release.
Table 7-8
PC04 MAP error to GMM Cause Code default mapping
MAP 29.002 Error GMM 24.008 Cause Code
System Failure 17 = Network Failure
Data Missing 17 = Network Failure
Unexpected Data Value 17 = Network Failure
Unknown Subscriber 3 = Illegal MS
GPRS Subscription Unknown 7 = GPRS Services Not Allowed
Unidentified Subscriber 3 = Illegal MS
Roaming Not Allowed 11 = PLMN Not Allowed
PLMN Roaming Not Allowed 11 = PLMN Not Allowed
Operator Determined Barring 11 = PLMN Not Allowed
Illegal Subscriber 3 = Illegal MS
Illegal Equipment 6 = Illegal ME
Resource Limitation (User Abort) 22 = Congestion
Resource Unavailable (User 17 = Network Failure

Abort)
Resource Limitation (Provider 22 = Congestion

Abort)
Unknown HLR 13 = Roaming Not Allowed in this Location

Area

DNS Query Failure to GMM Cause Code default mapping

Table 7-9 shows the default mapping of DNS Query Failures to GMM Cause
Codes for the PC04 release.
Table 7-9
PC04 DNS Query Failure to GMM Cause Code Default mapping
DNS Query Failure GMM 24.008 Cause Code
No IP address list returned 17 = Network Failure
CAS provisioning examples

Following are examples of displaying and modifying GMM cause code
mapping information.
Display valid 29.002 MAP and DNS errors

CAS command:
h gsc/<card number> gmm causemapping
Expected result:
Gsc/<card number> Gmm

Group WlcGmmCauseCodeMappingProv (causeMapping)
Properties Provisionable
Attributes mapSystemFailureToGmm,
mapDataMissingToGmm,
mapUnexpectedDataValueToGmm,
mapUnknownSubscriberToGmm,
mapGprsSubscriptionUnknownToGmm,
mapUnidentifiedSubscriberToGmm,
mapRoamingNotAllowedToGmm,
mapPlmnRoamingNotAllowedToGmm,
mapOperatorDeterminedBarringToGmm,
mapIllegalSubscriberToGmm,
mapIllegalEquipmentToGmm,
mapUresourceLimitationToGmm,
mapUresourceUnavailableToGmm,
mapPresourceLimitationToGmm,
mapUnknownHlrToGmm
dnsNoIpAddressListReturnedToGmm

Display valid 24.008 GMM cause codes and User Defined GMM
cause codes
CAS command:
h gsc/<card number> gmm mapSysFail
Note: “mapSysFail” is an example. It can be replaced by any other

attributes under causemapping.
Expected result:

Attribute mapSystemFailureToGmm (mapSysFail)
Access Read: passive Write: service
Criticality none
Type Decimal
Values 1,4,5,[18-21],[23-255]
imsiUnknownInHlr(imsiUnkHlr),
illegalMs(illMs),
illegalMe(illMe),
gprsServiceNotAllowed(gprsSvcNotAllow),
serviceNotAllowed(svcNotAllow),
msIdNotDerivedByNetwork(msIdNotDerived),
implicitlyDetached(implicitDetach),
plmnNotAllowed(plmnNotAllow),
locationAreaNotAllowed(laNotAllow),
roamingNotAllowedInLa(rnaNotAllow),
gprsNotAllowedInThisPlmn(gprsNotAllowPlmn),
noSuitableCellInLa(noSuitableCell),
mscTempNotReachable(mscTmpNotReach),
networkFailure(netFail),
congestion
Note: 1, 4, 5, 18-21, 23-255 are classified as User Defined GMM cause

codes.
Display the default mapping of MAP and DNS errors to GMM

cause codes
CAS command:
d gsc/<card number> gmm causemapping

Expected result:
mapSystemFailureToGmm = networkFailure
mapDataMissingToGmm = networkFailure
mapUnexpectedDataValueToGmm = networkFailure
mapUnknownSubscriberToGmm = illegalMs
mapGprsSubscriptionUnknownToGmm = gprsServiceNotAllowed
mapUnidentifiedSubscriberToGmm = illegalMs
mapRoamingNotAllowedToGmm = plmnNotAllowed
mapPlmnRoamingNotAllowedToGmm = plmnNotAllowed
mapOperatorDeterminedBarringToGmm = plmnNotAllowed
mapIllegalSubscriberToGmm = illegalMs
mapIllegalEquipmentToGmm = illegalMe
mapUresourceLimitationToGmm = congestion
mapUresourceUnavailableToGmm = congestion
mapPresourceLimitationToGmm = congestion
mapUnknownHlrToGmm = roamingNotAllowedInLa
dnsNoIpAddressListReturnedToGmm = networkFailure
Change the mapping of the DNS error

“dnsNoIpAddressListReturnedToGmm” to valid 24.008 GMM
cause code “implicitlyDetached”
CAS command:
set gsc/<card number> gmm dnsNoIpAddressListReturnedToGmm implicitDetach

ch pr
act pr
conf pr
d gsc/<card number> gmm dnsNoIpAddressListReturnedToGmm
Expected result:

dnsNoIpAddressListReturnedToGmm= implicitDetach

Change the mapping of the MAP error

“mapUresourceUnavailableToGmm” to the User Defined GMM
cause code “250”
A warning about unpredicted impacts to the system by using User Defined
GMM cause codes appears.
CAS command:
set gsc/<card number> gmm mapUresourceUnavailableToGmm 250

ch pr
act pr
conf pr
d gsc/<card number> gmm mapUresourceUnavailableToGmm
Expected result:

Warning:
It is not recommended to provision
“mapUresourceUnavailable ToGmm” attribute to a user defined
GMM cause code as it is not defined in the standards and may cause
service impacts on the Mobile Stations and the network.

mapUresourceUnavailableToGmm= 250

This feature does not allow explicit mapping of Gr SCCP errors.

OSI states 7
The following SGSN components maintain OSI states:
• BSSAP
• DNS
• GSC
• GSC SSF
• GSD
• GTP-C
• GTP Path
• LIAF
• MapClient
• MapStack
• NSE
• SAS
• SGGTL
• SGSN
• Sgsn Shelf ConM and ConS
• TcapStack
For general information about OSI states, refer to 241-5701-520, Passport

7400, 15000, 20000 Troubleshooting Guide.
This section describes each component’s OSI state with an OSI state diagram,
a description of each state transition, and a table of valid state combinations.

BSSAP
The initial OSI state of BSSAP is Unlocked, Disabled, Idle and is set during
the initialization of the BSSAP component. Figure 7-7 illustrates the OSI
state transitions for BSSAP.
Figure 7-7
BSSAP OSI state diagram
Unlocked
Disabled Enabled
1
Idle Idle Active Busy
2
Disabled Enabled Enabled
Locked Shutting Down
The state transitions shown in Figure 7-7 are:

1. BSSAP transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Idle once it completes initialization, establishes
connectivity, and registers successfully with the SS7 IP Gateway.
2. BSSAP transitions from Unlocked, Enabled, Idle to Unlocked, Disabled,
Idle if it loses connectivity with the SS7 IP Gateway.

Table 7-10 shows the BSSAP OSI state combinations.

Table 7-10
BSSAP component state combinations
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state of the BSSAP while attempting
to establish connectivity with the SS7 IP gateway.
This is also a valid state after it has lost its
connectivity with the SS7 IP gateway.
Unlocked, Enabled, Idle This is a valid state once the BSSAP has established
connectivity and registers with the SS7 IP gateway.
DNS
The initial OSI state of the DNS Agent is Unlocked, Disabled, Idle and is set
during the initialization of the DNS Agent. If the DNS Agent supports both
static and dynamic name-to-IP address mapping (local and remote), the state
does not transition from Enabled to Disabled when the DNS Agent fails to
communicate with any of the Name Servers. If the DNS Agent supports only
dynamic name-to-IP address mapping, the state transitions from Enabled to
Disabled when the DNS Agent fails to communicate with any of the Name
Servers. Figure 7-8 illustrates the OSI state transitions for DNS.

Figure 7-8
DNS component OSI state diagram
Unlocked
Disabled Enabled
2
1
Locked Shutting down

1. The DNS Agent transitions from its initial state of Unlocked, Disabled,
Idle to Unlocked, Enabled, Active when the initialization of the DNS
Agent is successfully completed.
2. DnsAgent transitions from Unlocked, Enabled, Active to Unlocked,
Disabled, Idle when the DnsAgent can not communicate with any Name
Servers and does not support static query.

Table 7-11 shows DNS Agent component OSI state combinations.

Table 7-11
DNS Agent OSI state combinations
Valid states Details
Unlocked, Disabled, Idle This is the initial state prior to the DNS
Agent initialization.
Unlocked, Enabled, Active This is a valid state when the DNS

Agent is initialized and operating
properly.
State Change Notifications

The DNS Agent has State Change Notifications (SCNs) automatically
generated by DCS in the event of an Operational state change (for example,
Enabled to Disabled).

GSC
The initial OSI state of GSC is Unlocked, Disabled, Idle and is set during the
initialization of the GSC. Figure 7-9 illustrates the OSI state transitions for
GSC.
Figure 7-9
GSC component OSI state diagram
Unlocked
Disabled Enabled
1 3 5

2 14 4 6
10 8
9 7
13
12 11

1. The GSC transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Idle once the GSC completes initialization. It also
makes this transition if it has been disabled and then becomes able to
establish ATM SVCs to GSC, GSD, MAP or SAS applications.
2. The GSC transitions from Unlocked, Enabled, Idle to Unlocked,
Disabled, Idle, when it is unable to establish ATM SVC links to any GSD,
MAP, SAS or GSC application.
3. The GSC transitions from Unlocked, Enabled, Idle to Unlocked, Enabled,
Active when the first subscriber attach is successfully completed.

4. The GSC transitions from Unlocked, Enabled, Active to Unlocked,

Enabled, Idle when the last subscriber detaches so that the GSC has no
subscribers attached.
5. The GSC transitions from Unlocked, Enabled, Active to Unlocked,
Enabled, Busy when the maximum number of attached subscribers is
reached. Future requests by subscribers to attach will fail until the number
of attached subscribers falls below the provisioned maximum.
6. The GSC transitions from Unlocked, Enabled, Busy to Unlocked,
Enabled, Active when the number of attached subscriber falls below the
provisioned maximum.
7. The GSC transitions from Unlocked, Enabled, Busy to Shutting Down,
Enabled, Busy when the a “lock” command is received from CAS.
8. The GSC transitions from Shutting Down, Enabled, Busy to Unlocked,
Enabled, Busy when the an “unlock” command is received from CAS.
9. The GSC transitions from Unlocked, Enabled, Active to Shutting Down,
Enabled, Active when a “lock” command is received from CAS.
10. The GSC transitions from Shutting Down, Enabled, Active to Unlocked,
Enabled, Active when an “unlock” command is received from CAS.
11. The GSC transitions from Shutting Down, Enabled, Busy to Shutting
Down, Enabled, Active when the number of attached subscriber falls
below the provisioned maximum.
12. The GSC transitions from Shutting Down, Enabled, Active to Locked,
Enabled, Idle when the last subscriber is detached.
13. The GSC transitions from Unlocked, Enabled, Idle to Locked, Enabled,
Idle when a “lock” command is received from CAS.
14. The GSC transitions from Locked, Enabled, Idle to Unlocked, Enabled,
Idle when an “unlock” command is received from CAS.
Table 7-12 describes the Gsc state combinations.

Table 7-12
Supported state combinations for Gsc
Unlocked, Disabled, Idle This is the initial state prior to GSC

initialization and after if the GSC is
unable to establish ATM SVCs to any
GSC, GSD, MAP, or SAS application.
—sheet 1 of 2—

Table 7-12
Supported state combinations for Gsc (continued)
Unlocked, Enabled, Idle This is a valid state when the GSC is

initialized and operating properly with
no mobile users attached.
Unlocked, Enabled, Active This is a valid state when the GSC has
at least one mobile user attached.
Unlocked, Enabled, Busy This is a valid state when the GSC has
the maximum number of mobile users
attached. No new attaches are
possible while in this state.
Shutting Down, Enabled, Busy This is a valid state when the GSC has
the maximum number of mobile users
attached and a lock command is being
processed.
Shutting Down, Enabled, Active This is a valid state when the GSC has
at least one mobile user attached and a
lock command is being processed.
Locked, Enabled, Idle This is a valid state when the GSC has
no mobile users attached and is locked.
—sheet 2 of 2—
GSC SSF
Figure 7-10 illustrates the OSI states for Gsc Ssf.

Figure 7-10
Gsc Ssf component OSI state diagram
Unlocked
Disabled Enabled
6 7
1 2 3
8 5 4
The initial OSI state of Gsc Ssf is Unlocked, Disabled, Idle and is set during
the initialization of the Gsc Ssf. The following describes the OSI state
transitions for the Gsc Ssf component:
1. Gsc Ssf transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Idle once Gsc Ssf completes initialization and
establishes connectivity with the TcapStack.
2. Gsc Ssf transitions from Unlocked, Enabled, Idle to Unlocked, Enabled,
Active when the first camel dialogue is established by a SCP with the Gsc
Ssf. Gsc Ssf will remain in the Active state until there are no active camel
dialogues or the high water mark for the maximum number of camel
dialogues is reached.
3. Gsc Ssf transitions from Unlocked, Enabled, Active to Unlocked,
Enabled, Busy when the number of camel dialogues reaches the high
water mark for the maximum number of dialogues allowed. Additional
camel dialogues may be established until the maximum limit is reached at
which time the Gsc Ssf will start failing requests from the SCP(s).

4. Gsc Ssf transitions from Unlocked, Enabled, Busy to Unlocked, Enabled,

Active when the number of camel dialogues complete such that the low
water mark for the maximum number of camel dialogues is reached.
Enabled, Idle when the last camel dialogue completes so that no SCPs
have a camel dialogue established with the Gsc Ssf.
6. Gsc Ssf transitions from Unlocked, Enabled, Busy to Unlocked, Disabled,
Idle if the Gsc Ssf loses connectivity with the TcapStack or all SCPs while
the number of established camel dialogues exceeds the high water mark.
Note: all camel dialogues existing at the time of the loss of connectivity
will time out at the SCP.
Disabled, Idle if the Gsc Ssf loses connectivity with the TcapStack or all
SCPs while there are established camel dialogues. Note: all camel
dialogues existing at the time of the loss of connectivity will time out at
the SCP.
8. Gsc Ssf transitions from Unlocked, Enabled, Idle to Unlocked, Disabled,
Idle if the Gsc Ssf loses connectivity with the TcapStack or all SCPs while
there are no established camel dialogues.
Table 7-13 describes the Gsc Ssf state combinations.

Table 7-13
Supported state combinations for Gsc Ssf
Unlocked, Disabled, Idle This is the initial state of the Gsc Ssf
while attempting to establish
connectivity with the TcapStack. This is
also a valid state after Gsc Ssf has lost
its connectivity with the TcapStack.
Unlocked, Enabled, Idle This is a valid state once the Gsc Ssf
has established connectivity with the
TcapStack.
Unlocked, Enabled, Active This is a valid state once the Gsc Ssf
has established at least one camel
dialogue with a SCP.
Unlocked, Enabled, Busy This is a valid state when the number of

established camel dialogues with SCP
nodes reaches the high water mark for
the maximum number of camel
dialogues allowed.

GSD
The initial OSI state of GSD is Unlocked, Disabled, Idle and is set during the
initialization of the GSD. Figure 7-11 illustrates the OSI state transitions for
GSD.
Figure 7-11
GSD component OSI state diagram
Unlocked
Disabled Enabled
2 1
The initial OSI state of GSD is Unlocked, Disabled, Idle and is set during the
initialization of the GSD. The following describes the OSI state transitions for
the GSD component:
1. GSD transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Active once GSD completes initialization.
2. GSD transitions from Unlocked, Enabled, Active to Unlocked, Disabled,
Idle when the GSD is de-provisioned or is deleted from CAS.
3. The GSD can transition from Unlocked, Enabled, Active to Unlocked,
Disabled, Idle when GSD is unable to establish ATM SVC links to any
GTL application.

4. The GSD can transition from Unlocked, Disabled, Idle to Unlocked,

Enabled, Idle when GSD is able to establish ATM SVCs to GTL
application.
GTP-C
OSI states for the GTP-C component are shown in Figure 7-12.
Figure 7-12
GTP-C component OSI state diagram
Unlocked
Disabled Enabled
1 2 3

6 5 4
The initial OSI state of GTP-C is Unlocked, Disabled, Idle. The following
describes the OSI state transitions for the GTP-C component:
1. The GTP-C transitions from initial state (Unlocked, Disabled, Idle) to
Unlocked, Enabled, Idle when GTP-C initialization is successfully
performed and the number of GTP transactions is zero.
2. The GTP-C transitions from Unlocked, Enabled, Idle to Unlocked,
Enabled, Active when the number of GTP transactions is larger than zero.

3. The GTP-C transitions from Unlocked, Enabled, Active to Unlocked,

Enabled, Busy when the maximum number of GTP paths or simultaneous
GTP transactions is reached.
4. The GTP-C transitions from Unlocked, Enabled, Busy to Unlocked,
Enabled, Active when the number of GTP paths and GTP transactions
drops below the maximum provisioned values.
5. The GTP-C transitions from Unlocked, Enabled, Active to Unlocked,
Enabled, Idle when the number of GTP transactions is equal to zero.
6. The GTP-C transitions from Unlocked, Enabled, Idle to Unlocked,
Disabled, Idle when the USC/GSC is reset.
Table 7-14
GTP-C component state combination
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state prior to the GTP-C initialization.
Unlocked, Enabled, Idle This is a valid state when the GTP-C is initialized and
the number of transactions is zero.
Unlocked, Enabled, This is a valid state when GTP-C is initialized and

Active operating properly.
Unlocked, Enabled, Busy This is a valid state when the maximum number of
GTP paths or simultaneous GTP transactions is
reached.

GTP Path
OSI states for the GTP Path component are shown in Figure 7-13.
Figure 7-13
GTP Path component OSI state diagram
Unlocked
Disabled Enabled
1

2
The initial OSI state of GTP Path is Unlocked, Disabled, Idle. The following
describes the OSI state transitions for the GTP Path component:
1. The GTP Path transitions from its initial state (Unlocked, Disabled, Idle)
to Unlocked, Enabled, Active when its initialization is performed.
2. The GTP Path is set to Unlocked, Disabled, Idle when it is detected as
failed.
3. The GTP Path transitions from Unlocked, Disabled, Idle to Unlocked,
Enabled, Active when it is detected as recovered.

Table 7-15
GTP Path component state combination
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state prior to GTP Path initialization,
and also a valid state when GTP path is detected as
“down”.
Unlocked, Enabled, This is a valid state when GTP Path is initialized and
Active operating properly and when GTP path is recovered
from failure.
LIAF
OSI states for the SGSN Lawful Intercept Server’s LIAF component are
shown in Figure 7-14.
Figure 7-14
LIAF component OSI state diagram
Unlocked
Disabled Enabled
1 2 3 4

7 6 5
OSI State definition:

1) Administrative
(e.g. Unlocked)
2) Operational
(e.g. Disabled)
3) Usage
(e.g. Idle)
Disabled Enabled Enabled * Shaded areas

denote unused &
unimplemented
Locked* Shutting Down* states for Lawful
Intercept

The initial OSI state of the Lawful Intercept Access Function (LIAF) is
Unlocked, Disabled, Idle and is set during the initialization of the LIAF. The
following text describes the OSI state transitions for the LIAF component. Note
that the Lawful Intercept Gateway (LIG) is a network node that the LIAF
component connects to thus allowing target provisioning and intercepted data
to be exchanged.
1. The initial OSI state of a LIAF component is <Unlocked, Disabled, Idle>
and is set at the beginning of the initialization of the LIAF component
(e.g. when physical card is first inserted).
2. A LIAF transitions from its initial state of <Unlocked, Disabled, Idle> to
<Unlocked, Enabled, Idle> once the LIAF component successfully
completes its initialization (including successful TCP connection to the
LIG).
3. A LIAF transitions from <Unlocked, Enabled, Idle> to <Unlocked,
Enabled, Active> when the first subscriber that is targeted attaches. LIAF
will remain in the Active state until: a) there are no remaining subscribers
that are both attached and targeted or, b) the threshold is reached for the
maximum number of subscribers who are targeted and are also attached.
4. A LIAF transitions from <Unlocked, Enabled, Active> to <Unlocked,
Enabled, Busy> when the maximum number of subscribers that are
targeted are also attached.
5. A LIAF transitions from <Unlocked, Enabled, Busy> to <Unlocked,
Enabled, Active> when the number of subscribers that are both targeted
and attached falls below the threshold of the maximum number of
subscribers targeted.
6. A LIAF transitions from <Unlocked, Enabled, Active> to <Unlocked,
Enabled, Idle> when the last subscriber who is both attached and targeted
detaches such that the LIAF has no intercept packet activity.
7. A LIAF transitions from <Unlocked, Enabled, Idle> to <Unlocked,
Disabled, Idle> at the beginning of the initialization of the LIAF
component (e.g. when physical card is rebooted).
8. Also note that a LIAF can transition between <Unlocked, Enabled, *> and
<Unlocked, Disabled, *>, where * indicates a “don’t care” Usage State, as
a function of the state of the TCP connection to the LIG (e.g. a TCP
connection failure results in a Disabled Operational state).

Table 7-16
LIAF component state combination
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state of the LIAF while it is in the
process of becoming operable.
Unlocked, Enabled, Idle This is a valid state when the LIAF has initialized,
is operating properly, and there are no attached
subscribers who are targeted.
Unlocked, Enabled, Active This is a valid state when the LIAF has initialized,
is operating properly, and there is at least one
subscriber, but less than the provisioned
maximum number of intercepted subscribers,
who are attached and targeted.
Unlocked, Enabled, Busy This is a valid state when the LIAF has initialized,
is operating properly, and there is at least the
provisioned maximum number of intercepted
subscribers who are attached and targeted.
MapClient
OSI States consists of three independent state attributes: Usage, Operational,
and Administrative. The Usage State (Idle, Active, and Busy) and the
Operational State (Disabled and Enabled) are controlled by the application,
and cannot be modified by the operator. The Administrative state (Locking/
Unlocking) of the MapClient component is not supported.
The initial OSI state of MapClient is Unlocked, Disabled, Idle and is set
during MapClient initialization. Figure 7-15 illustrates the OSI state
transitions for MapClient.

Figure 7-15
MapClient OSI state diagram

1. MapClient transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Idle once MapClient has successfully registered with
the MapStack.
2. MapClient transitions from Unlocked, Enabled, Idle to Unlocked,
Enabled, Active when the first transaction is sent.
3. MapClient transitions from Unlocked, Enabled, Active to Unlocked,
Enabled, Busy when the number of transactions with MapStack reaches
the high water mark for the maximum number of transactions allowed.
4. MapClient transitions from Unlocked, Enabled, Busy to Unlocked,
Enabled, Active when the number of transactions with MapStack does not
reach the high water mark for the maximum number of transactions
allowed.
Enabled, Idle when the number of transactions with MapStack reaches the
low water mark for transactions.
6. MapClient transitions from Unlocked, Enabled, Idle to Unlocked,
Disabled, Idle when the MapClient has de-registered with MapStack, the
MAP card goes down, or the MapStack instance is changed by
provisioning.
Disabled, Idle when the MAP card goes down or there are provisioning
changes (for example, the MapStack instance number or SGSN number
changes).
8. MapClient transitions from Unlocked, Enabled, Busy to Unlocked,
Disabled, Idle when the MAP card goes down or there are provisioning

changes (for example, the MapStack instance number or SGSN number

changes).

The Data Collection System (DCS) automatically generates State Change
Notifications (SCNs) for the MapClient component in the event of an
Operational state change (for example, Enabled to Disabled). Table 7-17
shows the MapClient OSI state combinations.
Table 7-17
MapClient state combinations
Combination (Administrative, Details

Operational, Usage)
Unlocked, Disabled, Idle This is the initial state of the MapClient

prior to successful registration with the
MapStack.
Unlocked, Enabled, Idle This is a valid state once the MapClient

has successfully registered with the
MapStack.
Unlocked, Enabled, Active This is a valid state once the MapClient

has established at least one
transaction with a MapStack node.

transactions with MapStack reaches
the high water mark for the maximum
number of transactions.
MapStack
The initial OSI state of MapStack is Unlocked, Disabled, Idle and is set
during the initialization of the MapStack. Figure 7-16 illustrates the OSI state
transitions for MapStack.

Figure 7-16
MapStack component OSI state diagram
Unlocked
Disabled Enabled
1 2 3
8 5 4

1. MapStack transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Idle once MapStack completes initialization, and the
MapStack binds to the SGSN and the MSC subsystems successfully.
2. MapStack transitions from Unlocked, Enabled, Idle to Unlocked,
Enabled, Active when the first map dialogue is established by a
MapClient or remote SS7 node with the MapStack. MapStack will remain
in the Active state until there are no active map dialogues or the high
water mark for the maximum number of map dialogues is reached.
3. MapStack transitions from Unlocked, Enabled, Active to Unlocked,
Enabled, Busy when the number of map dialogues reaches the high water
mark for the maximum number of dialogues allowed. Additional map
dialogues may be established until the maximum limit is reached at which
time the MapStack will start failing requests from the MapClient or
remote SS7 nodes.

4. MapStack transitions from Unlocked, Enabled, Busy to Unlocked,

Enabled, Active when the number of map dialogues complete such that
the low water mark for the maximum number of dialogues is reached.
5. MapStack transitions from Unlocked, Enabled, Active to Unlocked,
Enabled, Idle when the last map dialogue completes so that no
MapClients or remote SS7 nodes have a map dialogue established with
the MapStack.
6. MapStack transitions from Unlocked, Enabled, Idle to Unlocked,
Disabled, Idle if the TCAP Stack cannot bind to the MSC Subsystem
while there are no established dialogues.
Table 7-18 shows the Mapstack OSI state combinations.

Table 7-18
MapStack component state combination
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state of the MapStack while
attempting to establish connectivity with the IP
server. This is also a valid state after MapStack
has lost its connectivity with the IP Server.
Unlocked, Enabled, Idle This is a valid state once the MapStack has
established connectivity with the IP server.
Unlocked, Enabled, Active This is a valid state once the MapStack has
established at least one map dialogue with a
MapClient or remote SS7 node.

established dialogues with MapClients or remote
SS7 nodes reaches the high water mark for the
maximum number of dialogues allowed.

NSE
The initial OSI state of the SgGtl Nse component is Unlocked, Disabled, Idle
and is set during the initialization of the NSE. The NSE OSI state diagram is
shown in Figure 7-17.
Figure 7-17
NSE component OSI state diagram
Unlocked
Disabled Enabled
Locked Shutting down

1. The NSE transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Active when the initialization of the NSE is
successfully completed.

Table 7-19 shows NSE component OSI state combinations.

Table 7-19
NSE component OSI state combinations
Unlocked, Disabled, Idle This is the initial state of the NSE while
it is in the process of becoming
operational.
Unlocked, Enabled, Active This is a valid state when the NSE is

initialized and operating properly.

The NSE has State Change Notifications (SCNs) automatically generated by
DCS in the event of an Operational state change (for example, Enabled to
Disabled).

SAS
The initial OSI state of the SGSN Accounting Server (SAS) is Unlocked,
Disabled, Idle and is set during the initialization of the SAS. Figure 7-18
illustrates the OSI state transitions for SAS.
Figure 7-18
SAS OSI state diagram
Unlocked
Disabled Enabled
1
Idle Active
2

1. The SAS transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Active when the initialization of the SAS is
successfully completed.
2. The SAS transitions from Unlocked, Enabled, Active to Unlocked,
Disabled, Idle when the card is reset.

Table 7-20 describes the SAS state combinations.

Table 7-20
SAS component state combinations
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state of the SAS while it is in the
process of becoming operable.
Unlocked, Enabled, This is a valid state when the SAS is initialized and
Active operating properly.
SGGTL
Figure 7-19 illustrates the OSI state transitions for the SGGTL component.

Figure 7-19
SGGTL component OSI state diagram
Unlocked
Disabled Enabled
1
The initial OSI state of SGGTL is Unlocked, Disabled, Idle. The following
describes the OSI state transitions for the SGGTL component:
1. The SGGTL transitions from its initial state (Unlocked, Disabled, Idle) to
Unlocked, Enabled, Active when its initialization is complete. If
initialization fails, the state remains Unlocked, Disabled, Idle.
Table 7-21
SGGTL component state combination
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state prior to SGGTL initialization.
This state remains valid if initialization fails.
—sheet 1 of 2—

Table 7-21
SGGTL component state combination (continued)
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Enabled, This is a valid state when the SGGTL is successfully

Active initialized.
—sheet 2 of 2—
SGSN
Figure 7-20 illustrates the OSI state transitions for the Sgsn component.
Figure 7-20
SGSN component OSI state diagram
Unlocked
Disabled Enabled
1
Idle Active Idle Busy
2
The initial OSI state of SGSN is Unlocked, Disabled, Idle and is set during the
initialization of the SGSN. The following describes the OSI state transitions:
2. SGSN transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Active when the SgsnNmMaster or SgsnNmSlave
object is successfully created and one instance of each critical component
(GSC, GSD, GTL, MAP) is found.

3. SGSN transitions from Unlocked, Enabled, Active to Unlocked,

Disabled, Idle if it the SGSN system does not have any critical
components (i.e., GSC, GSD, GTL or MAP).
Table 7-22
SGSN component state combination
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state of the SGSN during startup.
This is also a valid state if any critical components are
missing.
Unlocked, Enabled, This is a valid state once the initialization is complete

Active and one instance of all critical components are found.
Sgsn Shelf ConM and ConS

Figure 7-21 illustrates the OSI state transitions for Sgsn Sh
ConnectionToMaster and ConnectionToSlave components.

Figure 7-21
SGSN Sh ConM and ConS components OSI state diagram
Unlocked
Disabled Enabled
1
Idle Active Idle Busy

2
The initial OSI state of ConM and ConS components is Unlocked, Disabled,
Idle and is set during initialization. The following describes the OSI state
transitions:
1. A ConM or ConS component transitions from the initial state of
Unlocked, Disabled, Idle to Unlocked, Enabled, Busy when it is
provisioned, its communication link is up, and the slave shelf has
registered with the master.
2. A ConM or ConS component transitions from Unlocked, Enabled, Busy
to Unlocked, Disabled, Idle when it is deleted or the associated master
and slave are unable to communicate.

Table 7-23
SGSN Sh ConM and ConS component state combinations
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state of the component while it is in
the process of becoming operable. The component
remains in this state if it is not provisioned, its
communication link is down, or the slave shelf has not
registered with the master. A SET alarm is generated
if the OSI State changes from Unlocked, Enabled,
Busy to this state.
Unlocked, Enabled, Busy This is a valid state when the component is

provisioned, its communication link is up, and the
slave shelf has registered with the master. A CLR
alarm is generated if the OSI State changes from
Unlocked, Disabled, Idle to this state and a SET
alarm was previously generated.
TcapStack
Figure 7-22 illustrates the OSI state transitions for the TcapStack component.

Figure 7-22
TcapStack component OSI state diagram
Unlocked
Disabled Enabled
6 7
1 2 3
8 5 4
The initial OSI state of TcapStack is Unlocked, Disabled, Idle and is set during
the initialization of the TcapStack. The following describes the OSI state
transitions:
1. TcapStack transitions from its initial state of Unlocked, Disabled, Idle to
Unlocked, Enabled, Idle once it completes initialization and establishes
connectivity with the SS7 IP Gateway.
2. TcapStack transitions from Unlocked, Enabled, Idle to Unlocked,
Enabled, Active when the first Tcap dialogue is established by a
MapClient/SSF or remote SS7 node with the TcapStack. It will remain in
the Active state until there are no active Tcap dialogues or the high water
mark for the maximum number of dialogues is reached.
3. It transitions from Unlocked, Enabled, Active to Unlocked, Enabled,
Busy when the number of Tcap dialogues reaches the high water mark for
the maximum number of dialogues allowed. Additional dialogues may be
established until the maximum limit is reached at which time the
TcapStack will start failing requests from the MapClient/SSF or remote
SS7 nodes.

4. TcapStack transitions from Unlocked, Enabled, Busy to Unlocked,

Enabled, Active when the number of Tcap dialogues complete such that
the low water mark for the maximum number of dialogues is reached.
5. It transitions from Unlocked, Enabled, Active to Unlocked, Enabled, Idle
when the last Tcap dialogue completes so that no MapClients/SSFs or
remote SS7 nodes have a Tcap dialogue established with the TcapStack.
6. TcapStack transitions from Unlocked, Enabled, Busy to Unlocked,
Disabled, Idle if it loses connectivity with the IP Server while the number
of established Tcap dialogues exceeds the high water mark. Note: all Tcap
dialogues existing at the time of the loss of connectivity will time out at
the MapClient/SSF or the remote SS7 node.
7. TcapStack transitions from Unlocked, Enabled, Active to Unlocked,
Disabled, Idle if the it loses connectivity with the IP Server while there
are established dialogues. Note: all Tcap dialogues existing at the time of
the loss of connectivity will time out at the MapClient/SSF or remote SS7
node.
8. TcapStack transitions from Unlocked, Enabled, Idle to Unlocked,
Disabled, Idle if it loses connectivity with the SS7 IP Gateway while there
are no established log dialogues.
Table 7-24
TcapStack component state combination
Combination Details
(Administrative,
Operational, Usage)
Unlocked, Disabled, Idle This is the initial state of the TcapStack while
attempting to establish connectivity with the SS7 IP
gateway. This is also a valid state after it has lost its
connectivity with the SS7 IP gateway.
Unlocked, Enabled, Idle This is a valid state once the TcapStack has
established connectivity with the SS7 IP gateway.
Unlocked, Enabled, This is a valid state once the TcapStack has

Active established at least one Tcap dialogue with a
MapClient/SSF or remote SS7 node.
Unlocked, Enabled, Busy This is a valid state when the number of established
dialogues with MapClients/SSFs or remote SS7
nodes reaches the high water mark for the maximum
number of dialogues or maximum number of invokes
allowed.


8-1
Software management 8
Software management is concerned with distributing and configuring
software to each SGSN. Software management may be accomplished using
any of the supported OA&M interfaces.
Software distribution 8
Software distribution, also referred to as software installation, involves
configuring and downloading software to SGSN nodes to add or upgrade
services, capabilities, or features.
Overall, this process involves the following steps:

• setting up a software distribution site (SDS) for storing, managing, and
distributing software
• transferring software received from Nortel from CD-ROM, or the web, to
the SDS
• configuring software so that certain services operate on certain processor
cards
• downloading software to the node

8-2 Software management
Software distribution site

The SDS is a repository of Passport software that you access when
downloading particular software applications to the SGSN.
For additional information on the SDS and its directory structure, see NTP
241-5701-270, Passport 7400, 15000, 20000 Software Installation Guide.
Software upgrade strategy 8

For information about upgrading the SGSN software, refer to NTP 411-5221-
303, GPRS/UMTS Packet Core Network Upgrade Manual.
Downloading and applying patches 8

A patch is a temporary enhancement or correction to the functionality of a
single Passport application version. Modifications to more than one
application require more than one patch. Patches allow for a number of small
changes to be made to an application until the next version of the application
is available. In general, a new application version will incorporate all the
changes in functionality made in the preceding patches.
A patch consists of a package of the new code and the mechanism to modify
the existing code on a switch, and a patch descriptor file. These files are
stored in the SDSs from where you can download them to the switch.
Prior to downloading the patch from the website, the SDS should be set up as
described in NTP 241-5701-270, Passport 7400, 15000, 20000 Software
Installation Guide. One SDS site should be used for ALL patch downloads
for a particular load. This will prevent previously downloaded patches from
being removed.
Procedure 8-1 describes downloading and applying patches from a UNIX

based SDS site to the SGSN. PC based SDS sites are not supported. In this
procedure, example commands are given for downloading patch
“base7T005A” to an SGSN with software load “CGA515A” active. For

complete information on Passport commands, refer to NTP 241-5701-050,

Passport 7400, 15000, 20000 Commands.
Procedure 8-1
Downloading and applying SGSN patches
Step Action
1 Download the compressed patch tar file to the SDS software directory by clicking on the
desired patch's Patch Id link.
2 After the file is retrieved, set file permissions with the chmod 644 command. For
example,
chmod 644 base7T005A_CGA515A.tar.Z.bin
3 Remove the .bin extension from the downloaded files. For example,
mv base7T005A_CGA515A.tar.Z.bin base7T005A_CGA515A.tar.Z
4 Uncompress the tar files. For example,

uncompress base7T005A_CGA515A.tar.Z
5 Untar the file in the software directory with the tar -xvf command. For example,
tar -xvf base7T005A_CGA515A.tar
This creates the software directory ~/base/CGA515A/ with the patch files. For an sgsn
patch (for example, sgsn30324737_CGA515A), the software directory would be created
as ~/wirelessSgsn/CGA515A/
6 Review the patch description file (*.pd) by clicking on the desired patch’s Admin link.
7 Go to the patch file directory and verify that the checksum value for the patch executable
file (*.o) is the same as described in the *.pd file under the “Patched File Checksum”
section. For example, go to cd ~/base/CGA515A and run the command
chksum scsGblSemChkPatcbs_CGA515A.o
Compare and verify that the output value is the same as the checksum value provided in
the base7T005A_CGA515A.pd file (2968210986).
8 Telnet to the SGSN.
9 If the patch target is for both i960 and ppc, set up the processor targets as follows:
s sw dld processorTargets i960 ppc
10 Select the SDS software directory on the SGSN to which to download the patch file. For
example,
set sw dld avl ! base_CGA515A
—sheet 1 of 2—

Procedure 8-1
Downloading and applying SGSN patches (continued)
Step Action
11 Start the download. Type

start -h(ip_address) -u(login_id) -p(password) sw dld
where ip_address is the IP address of the to the SDS machine, and login_id and
password are a valid login ID and password on the SDS site.
12 Once the download command is finished, apply the patch on the switch. For example,
start prov
set sw patch base7T005A
check prov
act prov
conf prov
end prov
The patch identifier is the downloaded file name less the _CGA515A* extension on the
SGSN.
13 Verify that the patch has been downloaded and applied on the switch. For example,
l sw av/* patch/*
d sw patch
14 If it is necessary to remove a patch on the switch, enter the commands as shown in the
following example:
start prov
set sw pa ~base7T005A
check prov
act prov
conf prov
end prov
—sheet 2 of 2—

Removing patches 8
Procedure 8-2 describes the removal of patches from an SGSN. In this
procedure, example commands are given for removing a downloaded and
applied patch "base7T00A" to an SGSN with software load "CGA515A"
active. The instructions are generic in nature as they could vary from one
patch to another. Please refer to the individual patch descriptor (PD) file for
specific removal instructions. For complete information on Passport
commands, refer to NTP 241-5701-050, Passport 7400, 15000, 20000
Commands.
Procedure 8-2
Removing an SGSN patch
Step Action
1 Issue the following commands to remove the patch from the patch list.
Important: Patch removal instructions could vary from one patch to another. The
commands displayed below are for illustrative purposes only. Please follow the patch
removal instructions, if any, in the patch descriptor (PD) file.
start prov
set sw pa ~base7T005A
check prov
act prov
conf prov
save -f(<new_committed_prov_name>) -ascii -port -prend prov
2 Refer to the patch descriptor (PD) file and identify the object files associated with this
patch. Delete those object files and the PD file from the SDS site.


A-1
Technical specifications and

conformances A
This chapter provides the following technical specifications and conformances
for the SGSN:
• GSM specification conformance
• MTBF ratings for Passport hardware components
• Node capacity
• Bus performance
• Physical characteristics
• Dc power input specifications
• Dc grounding scheme
• Environmental specifications
• Node ventilation and access clearances
• Heat dissipation
• Thermal engineering
• Passport switch standards conformances
— Dc power supply summary
— Control processor
— 100BaseT Ethernet function processor
— 2-port OC-3 ATM function processor
— MSA32 function processor
— 2pGPDsk function processor
— 4-port OC-3 ATM function processor
— 4-port DS3 channelized FR function processor
• Century compliance for Passport software
— Statement of Year 2000 compliance

A-2 Technical specifications and conformances
For additional information and specifications pertaining to the Passport

platform, see NTP 241-7401-200, Passport 7400 Hardware Description, and
NTP 241-1501-200, Passport 15000, 20000 Hardware Description.
GSM specification conformance

Refer to NTP 411-5221-201, Specifications for UMTS/GPRS Packet Core
Conformance Guide, for information on the conformance of the NSS
components and interfaces of the Nortel GPRS system to the applicable GSM
specifications.
MTBF ratings for Passport hardware components

Contact the Nortel account representative for information on the expected
failure rate, mean time between failure (MTBF), and return rate during steady
state period for each Passport component.
Node capacity
Given below is the node capacity for the SGSN:
• maximum of one 7400 node and one 15000 node per frame
• sixteen (16) processor card slots per 7400 node:
— maximum of fifteen (15) function processors per shelf
— maximum of two control processors per shelf
Note: Control processors must be located in either the right-most or left-
most card slots (slots 0 and 15).
• maximum of three power supplies can be accommodated per node. Fully

equipped node requires minimum of two power supplies; a third may be
used for redundancy.
Bus performance
The maximum shelf throughput is a function of the performance of the Passport
bus. Since the 64-byte packets appearing on the Passport bus have a 4-byte
internal overhead, the resulting bus efficiency is 94%. The shelf throughput
capacity is measured as:
• raw Passport bus capacity: 1.6 Gbit/s
• node user data throughput, no faults, two buses running: 1.5 Gbit/s
• node user data throughput, one bus failed: 750 Mbit/s
Physical characteristics
Table A-1 summarizes the physical characteristics of the SGSN.

Note: The dimensions are the actual measurements of the equipment.

Table A-1
Summary of equipment dimensions and weights
Equipment Outside dimensions Weight

(height x width x depth)
15K-VSS frame example: 2 shelf assemblies, 1 23.62 in. x 23.62 in. x 83.66 in. 1316.8 lb
EBIP, cooling unit, air filter assembly, and cable (60 cm. x 60 cm. x 212.5 cm.) (598.5 kg)
management unit
15K-VSS frame (empty) 23.62 in. x 23.62 in. x 83.66 in. 474.6 lb
(60 cm. x 60 cm. x 212.5 cm.) (215.7 kg)
Node shelf assembly, with cooling unit, cable 33.25 in. x 17.5 in. x 19.75 in. 177 lb
management unit, 3 power converters, 2 control (84.5 cm x 44.5 cm x 50 cm) (80.6 kg)
processors, 14 function processors
Node shelf assembly (empty) 21 in. x 17.5 in. x 19.75 in. 46 lb

(53.5 cm x 44.5 cm x 50 cm) (20.9 kg)
Note: This set of dimensions does not include the
cable management unit or the cooling unit. The
depth measurement includes cable guides.
Cable management unit 7 in. x 17.5 in. x 18.75 in. 12 lb

(18 cm x 44.5 cm x 48 cm) (5.5 kg)
Cooling unit and air filter assembly 5.25 in. x 17.5 in. x 14.75 in. 20 lb
(13.5 cm x 44.5 cm x 37.5 cm) (9.1 kg)
Power converter (dc) 7.5 in. x 5.75 in. x 16 in. 13.7 lb

(19 cm x 15 cm x 41 cm) (6.2 kg)
Note: The depth measurement includes the
connector on the back
Power converter (blank) 6.7 in. x 5.7 in. x 14.0 in. 2.2lb
(17.0 cm x 14.4 cm x 36.7 cm) (1.0 kg)
Function processor 12.0 in. x 1.0 in. x 15.5 in. 3.5 lb

(30.5 cm x 2.5 cm x 39.4 cm) (1.5 kg)
Control processor 12.0 in. x 1.0 in. x 15.5 in. 4.5 lb

(30.5 cm x 2.5 cm x 39.4 cm) (2 kg)
Blank processor 12.0 in. x 1.0 in. x 15.5 in. 1.1 lb

(30.5 cm x 2.5 cm x 39.4 cm) (0.5 kg)
1-unit-high termination panel (rack-mount) 1.75 in. x 19.0 in. x 0.7 in 1 lb

(4.45 x 48.3 cm x 1.8 cm) (0.44 kg)

Dc power input specifications

7400 node
You must supply your own dc power cords. Cables must be able to carry 30 A
dc and must be protected with a 30-Amp circuit breaker or fuse.
The nominal input voltage can be -48/-60 V with an operational range for
input power of -40 to -72 V dc. The output power cannot exceed 600 W.
Input voltage under minimum battery operating conditions must supply a

minimum of 39.5 V to the power supply. For example, if the minimum
battery specification for your site is 42 V, then the voltage can drop only 2.5
V.
15000 node
Redundant dc input power feeds (nominal voltage of -48/-60V) of up to 100
amps are connected to the enhanced breaker interface panel (EBIP) in the
Passport 15000-VSS frame. These feeds are connected to either two or four
breaker interface modules (BIMs) on the BIP. The SGSN uses two BIMs.
While the breaker interface module is rated up to 100 amps for the base
Passport 15000, for the SGSN, with the power consumption of the SGSN
cards, a 40 amp breaker is sufficient, even if 16 cards are installed in the
15000 shelf of the Passport 15000-VSS cabinet. 40 amp breakers must be
used to power the SGSN since the power cabling kits have been designed
with cabling sized for 40 amp breakers. If power cables longer than 60 meters
are required, the cables must be engineered.
For more information on the EBIP, refer to “Breaker interface panel” in

Chapter 3, “Hardware description”.
Dc grounding scheme
Grounding for the dc configuration is based on separate signal and frame
grounds. These are separately connected directly to the ground window.
External dc power supply returns must also be connected to the common
grounding point.

Environmental specifications
The required environmental conditions for Passport hardware are given in the
Table A-2.
Table A-2
Environmental requirements
Environmental factor Mode Specification
Temperature Operating 10°C to 40°C (one 16-slot Passport node

installed in a 15K-VSS frame)
Rate of Change <10°C/hr
Storage -40°C to +70°C
Rate of Change <100°C/hr
Relative Humidity Operating 10% to 80% non-condensing (5.2 kPa

pressure maximum)
Storage 10% to 80% non-condensing (5.2 kPa

pressure maximum)
Altitude Operating 200 ft (61 m) below sea level to 6600 ft

(2000 m) above sea level
Particulate atmosphere Class 100,000 (Fed. Std. No. 209B)
Node ventilation and access clearances

A fully configured dual-shelf system generates about 3540 W, 1770 W from
each shelf assembly. It needs specific clearances for ventilation and access.
See NTP 241-1501-205, Passport 15000, 20000 Site Requirements and

Preparation Guide, for specific clearances for ventilation and access.
Heat dissipation
The heat dissipation for a 15K-VSS frame configured with a 16-slot Passport
switch is:
• per switch: 6,018 BTUs/h
• maximum per frame: 12,036 BTUs/h
Thermal engineering
Use the following information to find temperature needs for Passport nodes.

Note: Always keep temperatures low. Conventional theory suggests that

MTBF halves for every 5°C rise in temperature.
Air Inlet temperature:

Maximum 40°C for long term reliability
Maximum 55°C for short term functionality (as defined in Bellcore GR-63-
CORE, no more than a total of 96 hours for not more than 15 days in a year)
Air outlet temperature:

Maximum 60°C for long term reliability
Maximum 75°C for short term functionality
Passport switch standards conformances

The 16-slot Passport switch complies with the following regulatory standards:
• UL Listed. UL1950 Data processing equipment
• CSA certified per CSA C22.2 No. 950-M89 Information Technology
Equipment
• Nortel corporate safety standards 9001
• European Norm EN60950 (VDE)
• FCC Part 15B Class A system
• EN 55022 Class A
• CISPR 22 Class A
• EN50082-1
• ICES-003 issue
• AS/NZ 3548
• VCCI Class 1
• GR-1089-CORE
• GR-63-CORE
• FCC Part 68
• Industry Canada CS-03
• TRS 400078
Dc power supply summary

The dc power supply of the 16-slot Passport switch complies with the
appropriate sections of these documents:
• In North America, UL and CSA specifications apply to an absolute
minimum input voltage of -60 V dc, wherein battery return (BR) and

Logic Return (LR) are properly grounded. The BR and LR are grounded
at the system ground window according to Nortel corporate grounding
standard CS 1422.
• In the international market, specifications apply to an absolute maximum
input voltage of -72 V dc, wherein BR and LR are properly grounded. The
BR and LR are grounded at the system ground window according to
Nortel corporate grounding standard CS 4122.
• UL 1950; March, 1989; Safety of Information Technology Equipment
• CSA C22.2 950; October, 1989; Information Technology Equipment
• EN 60950; 1988; Information Technology Equipment
Control processor
Each V.24 port supports a subset of CCITT V.24 standards and can
accommodate most interface devices.
100BaseT Ethernet function processor

The 100BaseT Ethernet function processor complies with these standards and
conventions:
• IEEE 802.3 and 802.3u
• local bridging as defined by IEEE 802.1D
• translation bridging for DIX Ethernet as defined in IEEE 802.1H
• remote transparent bridging as defined in IEEE 802.1G

The OC-3 ATM function processor complies with the applicable sections of
these standards:
SONET
ATM Forum
• AF-UNI-0010.002 (ref. [28])
— Complies to section 2.1.
• AF-TEST-0024.000 (ref. [31])
Bellcore
• GR-253-CORE (ref. [35]):
— Complies to all required and applicable items for STS-3 ATM
operation.
— Note that the following optional bytes are not supported by OC-3
ATM IPs:
– - E1: Orderwire

– - F1: Section User Channel

– - D1-D3: Section Data Communication Channel
– - J1: STS Path Trace
– - F2: Path User Channel
– - N1: Tandem Connection Maintenance/Path Data Channel
• TR-NWT-001112 (ref. [38])
ANSI
• T1.105-1995 (ref. [12]):
• T1.231-1993 (ref. [22]):
— Complies to section 8 for all SONET alarms and statistics listed in
Section 3.2.3 on page 8.
• T1.646-1995 (ref. [24], supersedes T1.624):
• T1E1.2/96-002 (ref. [25])
• 216 MD-1998.0041 - Version 01.05 - released - 1998-07-31 (PP504,
P6.0)
SDH
ITU-T
• G.707 (ref. [45], replaces G.708. G.709) complies except for section
9.2.2.11 Table 5 which states that on receipt of an MS-AIS signal, line-
timing should not be used.
Note: the following optional bytes are not supported by OC-3 ATM IPs:
– E1: Orderwire
– F1: Section User Channel
– D1-D3: Section Data Communication Channel
– J1: STS Path Trace
– F2: Path User Channel
– N1: Tandem Connection Maintenance/Path Data Channel
• G.782 (ref. [48])
• G.783 (ref. [49])
• G.813 (ref. [51])
• G.825 (ref. [54])
— Complies, except may not meet wander requirements.
• G.957 (ref. [56])

Note: the OC-3 ATM IP single mode FP is classified as application code

L-1.1.
• G.958 (ref. [57])

• I.432 (ref. [58])
— Complies to section 2 (Physical Medium at 155 520 kbit/s)
— Complies to section 4 (TC Sublayer) except:
— Section 4.2.1.2: Physical layer cells are not guaranteed to be inserted
in the cell stream every 27 cells.
— Section 4.2.1.3: Physical layer OAM cells are not implemented.
• ETSI
• ETS 300 417 (previously ETS DE/TM-01015) (ref. [40])
• BABT
• BABT TC/139 (ref. [33])
MSA32 function processor

The DS1 MSA32 function processor (FP) complies with the applicable sections
of these North American DS1 interconnect standards:
• FCC Part 68 (DS1 interconnect)
• Industry Canada CS-03 (DS1 interconnect)
• ITU-T G.703
• ITU-T G.704
• ITU-T G.706
• ITU-T G.824
• ITU-T I.363.1
• ANSI T1.102
• ANSI T1.403
• ANSI T1.630
The E1 MSA32 function processor (FP) complies with the applicable sections
of these international, European, and Australian E1 interconnect standards:
• ITU-T G.703 (excluding Annex B)
• ITU-T G.704
• ITU-T G.706
• ITU-T G.732
• ITU-T G.823

• ITU-T I.363.1
2pGPDsk function processor

The V.24 port supports a subset of CCITT V.24 standards and can
accommodate most interface devices.
The 2pGPDsk is compliant with ISO 8601 and Nortel Corporate Standard
1805.00.

The 4-port OC-3/STM-1 function processor (FP) complies with the applicable
sections of these standards:
• ATM UNI Forum Standard 3.1
• ITU-T I.432
• ITU-T G.707
• ITU-T G.708
• ITU-T G.709
• ITU-T G.782
• ITU-T G.783
• ITU-T G.813
• ITU-T G.825 with the exception of wander requirements
• ITU-T G.957
The OC-3 multi-mode FP is classified as having application code I-1, but is 6

to 7 dBm more sensitive in receive, and consequently provides up to 5 dBm
less transmit power.
• ITU-TG.958
• I.432, complies with section 2 (Physical Medium at 155 520 kbit/s),
complies with section 4 with the exception of section 4.2.1.2 (physical
layer cells are not guaranteed to be inserted in the cell stream every 27
cells) and section 4.2.1.3 (physical layer OAM cells are not implemented)
• ANSI T1.105.1995
• ANSI T1.646
• ANSI T1.231 Partial compliance
• ANSI T1E1.2/96-002
• Bellcore GR-253-CORE
• TS026

• BABT/TC/139
4-port DS3 channelized FR function processor

The 4-port DS3 function processor (FP) complies with the applicable sections
of these standards:
• ITU-T G.824
• ANSI T1.102-199X, Section 6.4
• ANSI T1.107-1998 and T1.107a-1990, Sections 8.1, 8.4, except 8.4.7
• ANSI T1.404-19XX
• ANSI T1.231-1993 Sections 7 and 9 except 15 minute and day counts and
thresholds
• ANSI T1E1.2/94-002R1, 1994, Sections 9 and 15.2
• ANSI T1.646-1995
• Telcordia TR-TSV-000773, 1993, Section 4
• Telcordia TR-NWT-000499, 1991, Sections 10.5.1 and 10.5.3
• Telcordia TR-TSY000009, Sections 2.6 (DS3 coding) and 4.1 (Condition
monitoring and failure detection thresholds)
• ATM Forum ATM User-Network Interface Specification Draft Version
3.1, 1994.
• ATM Forum AF-PHY-0054.000
• ATM Forum AF-TEST-0023.000, except items 3.3.7 and 3.3.8: C-bit
terminal-to-terminal data link is not supported; and item 3.6.2: by default
cell payload scrambling is enabled
• ATM Forum AF-TEST-0082.000
Century compliance for Passport software

Passport was conceived and designed as a Year 2000-ready product able to
properly process and display four-digit years as part of a more important
capability - accurate date-processing before, during, and after the year 2000.
Since its introduction, Passport has fulfilled its key Year 2000 requirements in
• managing dates in data manipulation
• calculating and identifying leap years
• managing Julian dates
• computing intervals, scheduling events, and maintaining day-of-week
timekeeping
The term century compliant shall mean that the specified product shall
function until the end of its warranty period without any material, service

affecting non-conformance to the applicable Nortel product specification with

respect to the operations performed by such product which are date
dependent, provided that the specified software load or release, if any,
identified by Nortel (including any associated hardware), has been installed
with respect to such product; and further provided that the use of such product
is in conformance with the associated user documentation. The statement that
a product is century compliant should not be interpreted as a commitment to
support a product beyond its committed support window.
The terms Year 2000 readiness and Year 2000-ready in regard to Passport
products shall mean that the Passport product is century compliant, as defined
above.
For end-to-end Year 2000 readiness, ensure that the management systems
interacting with Passport are also upgraded to Year 2000-ready releases.
Statement of Year 2000 compliance

In the range 1980 to 2035, the SGSN application running on a Passport
• does not produce errors while processing dates for interval calculations,
scheduling events, or day of week timekeeping;
• the format of date information output by the system is accurate,
unambiguous, and uses a 4 digit year; and
• handles leap years correctly.

B-1
Engineering rules B
This appendix provides product engineering rules for provisioning a
GPRS6.0 SGSN.
Network engineering rules

SGSN shelf
Figure B-1 Dual Cabinet configuration
Slave Shelf 1 Slave Shelf 3

7K module 1 7K m odule 2
{G SD} {G SD ext.}
Port 0 Port 0
Port 1 Port 1
PRIM ARY FRAM E SECONDARY FRAM E

Vcc/0.41
M aster Shelf Vcc/0.41 Slave Shelf 2

15K module 1 15K module 2
Nodal M anager
{G SC} {G TL}
Connection: PVC to
NonIP configure
To Backbone
Port 3 ATM (MM ) Port 3
Port 2 Port 2
Port 1 Vcc/0.41 Port 1
Port 0 Vcc/0.42 Port 0
Vcc/0.43
• The largest available market model in PC04 is a Dual cabinet. Each

cabinet is populated with (1) 7K shelf and (1) 15K shelf.
• The base market model in PC04 is a Single Cabinet (7K for Data
processing, 15K for control plane)
• There is one Nodal Manager (NM) on one SGSN shelf, referred to as the
Master Shelf. Master Shelf is always 15K supporting GSC cards. All

B-2 Engineering rules
other shelves contain NMs that are considered slave NMs; these are
referred to as Slave shelves:
— Slave shelf 1: First cabinet, 7K supporting GSD
— Slave shelf 2: Second cabinet, 15K supporting GTL
— Slave shelf 3: Second cabinet, 7K supporting GSD extension.
• Master or Slave shelves are provisioned by CDL component Sgsn Shelf
ConS/x SlaveAddress or ConM MasterAddress. Master Address is
provisioned in the Slave shelves; all the Slave shelves are provisioned in
the Master.
CP cards
• Each 7K shelf is equipped with two CP2 cards in slots 0 and 15, running
in 1:1 cold spare mode.
• Each 15K shelf is equipped with two CP3 cards in slots 0 and 1, running
in 1:1 cold spare mode.
• CP3 can be E1 or T1, depending on the BITS module used.
• Nodal manager runs on the CP cards. There is one master NM on one
SGSN shelf, referred to as the Master shelf (supporting GSC), within the
SGSN complex. All other shelves contain NMs that are considered a slave
NM, referred to as a Slave Shelf.
• In GPRS, OA&M traffic is connected directly to the Ethernet port of CP
cards. LAN cards are mainly reserved to support GPRS traffic (signaling,
billing, LI and Gn/Gp).
Note: When the active CP card detects an Ethernet cable or port failure,
by default it will not switch to the stand-by CP card: the CP card loses
connection with the OAM server. If configured it is possible to switch on
the stand-by card but during about 1 minute no IP traffic can occur on the
shelf.
Intershelf ATM cards

• In the SGSN, only Multi Mode ATM cards are used for this
functionality. 2pOC3 card is used for intershelf communication in the 7K
and 4pOC3 card is used in the 15K.
• Inter-Connectivity between 7K/15K and primary/secondary frames is
described in Figure B-1.
• 2pOC3 cards are always located in slots 1 and 2; 4pOC3 cards are always
located in slots 8 and 9. Cards are placed in the left hand side of the shelf
since fiber optic cabling typically runs on that side of the rack.
• Cards are always deployed in pairs 1:1 and load is distributed across the
FPs. Every card is configured active.

• APS is not supported on the SGSN for inter-shelf links since APS on the
2pOC3 FPs is only between ports on the same FP.
• When provisioning ATM port, SDH must be used everywhere except the
US, Canada and Japan. In these countries SONET must be used instead.
This is applicable for intershelf and all ATM interfaces.
• Only static routes are used internally to the SGSN. OSPF can be used on
the external interfaces only.
• In PC04, a new 4pOC3 based on PQC12 has been introduced to replace
4pOC3 based on PQC2, which will be MD in 2004.
• 4pOC3 based on PQC2 will be supported until End Of Life. PQC12
version becomes mandatory for new orders in PC04.
• Redundancy between 4pOC3 based on PQC2 and PQC12 is not
supported; therefore each pair must be based on the same PQC.
• It is possible to have 1 pair 4pOC3 (PQC12) and 1 pair 4pOC3 (PQC2) in
the same shelf (for GTL functionality for example).
• If the Gn/Gp interface of the SGSN must be connected via ATM:
— If it is Multi Mode: port 0 of the 4pOC3 can be used.
— If it is Single Mode: add a SM pair in the slave 15K.
GSC
• GSC cards are always provisioned on the 15K Master shelf. Multi-shelf
GSC is not allowed.
• GSC card is always co-located on the same shelf with the SAS card (as
long as multi-shelf SAS is not supported).
• GSC function is either 1:1 Hot Standby or N+1 over provisioned. All the
GSCs need to be either of the mentioned modes, a combination is not
allowed.
• If (1:1) Hot Standby feature is used, main and spare cards need to be in
adjacent slots; only the main card must be provisioned.
• Ethernet ports on the GSC cannot be used in GPRS/UMTS networks. Use
dedicated LAN cards with Ethernet line Sparing (ELS).
• Each card must be provisioned with component Gsc/n
maxAttachedSubscribers. The value must be provisioned according to the
call profile used, and cannot exceed 88K subs per card. Each GSC
installed must be provisioned with the same value (all the cards are active
and traffic will be loadshared over the cards).
GSD
• GSDs are N+1 over provisioned with load sharing through the shelves
(dual cabinet configuration).

• GSD cards can exist in isolation on the 7K shelf with just CP and I/O
cards.
• Each card must be provisioned with component Gsd/n
MaxLlcActiveSubscribers. The value must be provisioned according to
the call profile used, and cannot exceed 40K subs per card (low
throughput). Each GSD installed must be provisioned with the same value
(all the cards are active and traffic will be loadshared over the cards).
SAS/LI
• SAS and LI applications are provisioned on the same card.
• SAS application is supported in (1:1) hot standby mode only, for new and
existing customers.
• LI application is (1:1) warm standby mode.
• Two pairs of SAS cards may be provisioned in the master shelf (feature
Multi-active SAS).
• SAS card must be provisioned in the master 15K shelf only.
• In order to limit the loss of billing data, it is recommended that the
collection of traffic volume counts occur as frequently as possible without
impeding upon required capacity. See recommendation in the CIQ.
• In a Nortel SGSN, the "SGSN address field" used in the CDRs
corresponds to the GIPS IP address of the SAS card.
• It is not recommended (but supported) to connect the billing or X1 LAN
directly to the SAS card via its Ethernet port, as the base software does
not support Ethernet Hot Switchover:
— The SAS card does not detect an Ethernet cable or port failure. In case
of out-band Billing traffic, when an Ethernet cable failure occurs the
SAS card is still considered as active but cannot contact the Billing
server.
— The recommendation is to send X1 or billing traffic through the
Ethernet ports of dedicated LAN card with ELS.
MAP
• Only one TCAP application, supporting both MAP (Gr) and (Gd), CAP
(Ge) can be provisioned on the MAP card. Bssap (Gs interface) does not
run on the MAP, but on GSC.
• MAP is always provisioned in (1:1) warm standby redundant mode.
• In PC04, there can be more than 1 active MAP cards per shelf (feature
Multi-active MAP). Up to 4 multi-active MAP cards per shelf can be
provisioned (4 active + 4 spare).
• In PC04 with feature Multi-shelf MAP, it is not necessary to co-locate
MAP with GSC and SAS card.

• In a dual cabinet configuration, it is recommended to have at least 1 pair

of MAP cards in the slave 15K, in order to leave slots available in the
master 15K to add GSCs or SASs.
• It is not recommended to connect the SIG directly to the MAP card via its
Ethernet port as the base software does not support Ethernet Hot
Switchover:
— The MAP card does not detect an Ethernet cable or port failure. In
case of out-band MAP traffic, when an Ethernet cable failure occurs
the MAP card is still considered active but cannot contact the SIG.
— The recommendation is to send Gx’ traffic through the Ethernet ports
of a dedicated LAN card with ELS.
MSA32
• In PC04, MSA-32 is used in the 7K shelf as I/O for the Gb interface
(except for models with DS3). MSA as GTL is no longer a model
proposed in PC04, although existing configurations are still supported.
• depending on the Pulse Code modulation (PCM) link (E1 or T1), MSA32-
E1 or MSA32-T1 is used.
• a maximum of 32 PCM links per card is supported.
• 1Slot-MSA is a new card introduced in PCO4. This card replaces the
2Slot-MSA in the GPRS6.0 models. These 2 cards can coexist in the 7K
(they are completely similar).
• 1 Slot-MSA and 2 Slot-MSA use the same termination panel.
• Fanout cables to connect the MSA32 card to termination panels are
different between the 1 Slot and 2 Slot-MSA, because of the connector
type on the faceplate of these cards.
MSA32 in a Single cabinet
• N:1 redundancy is supported for 1 Slot or 2 Slot-MSA32 cards. 2N
redundancy is always supported in a single cabinet; therefore MSA32
must be provisioned in a pair with 2N loadsharing. Each card is
engineered at 40% of the maximum capacity, in order to support all the
traffic in case of one card failure.
• If N:1 redundancy is used (N cards active, 1 spare), a sparing panel must
be used and each active card can be provisioned at 80%.
• Limit to 3 MSA Gb I/O (Dual slot version) per 7K shelf.
• Sparing panel (N:1) or termination panels (2N) must be mounted in a
separate frame (there is no place available in the SGSN frames).
• For redundancy, the traffic coming from a PCU must be transported at
least on 2 different PCM, with each PCM on a different MSA32.

Figure B-2 Gb interface engineering
PCU Traffic <NSE>

NS-VC NS-VC
Bearer Bearer
Term. Panel Term. Panel
MSA32 MSA32
40% 40%
MSA32 in a Dual cabinet

• In a Dual cabinet, MSA32 cards are located in the second 7K shelf
exclusively.
• Redundancy applied is 1:N, minimum configuration is 2 cards.
• Limit to 3 MSA Gb I/O (dual slot version) and 6 MSA Gb I/O (single slot
version) per 7K shelf (PLM limitation)
• With only 2 cards, each card must be engineered at 40% of maximum
capacity as described in “MSA32 in a Single cabinet” on page B-5.
• With at least 3 cards, all the FPs point towards the same inactive card as
the standby card. The standby operation is cold only. Each active card can
be engineered at 80% of maximum card capacity, the spare MSA at 0%.
• The maximum number of PCM links supported is identical to the number
of active MSAs multiplied by 32.
• A Sparing Panel is required per active MSA32 for bearer connectivity.
This Sparing Panel must be mounted in a separate frame (there is no place
vacant in the SGSN frames).

Figure B-3 N+1 Sparing on MSA32
PCU Traffic <NSE>

NS-VC NS-VC
Bearer Bearer
Sparing Panel
Term. Panel Sparing Panel
MSA32 MSA32
MSA32
80% 80% 0%
4port-DS3
• This optional card introduced in PC03 can replace MSA32-T1 in U.S.
markets only, to connect the Gb interface.
• It is provisioned in 2N load sharing; each card is active. DS3 and GTL
must reside on the same 15K shelf (Master 15K: single cabinet or Slave
15K: dual cabinet).
• Currently 2 cards are provisioned per shelf, with a maximum of (3) 4p-
DS3 per SGSN.
• Ports can be configured as either unchannelized (DS3 interface) or
Channelized (DS1 interface), 28 DS1 within a DS3.
• A Fanout Panel kit is required to accommodate up to 12 DS3. This Fanout
Panel must be mounted in a separate frame (there is no place vacant in the
SGSN frames).

Figure B-4 4pDS3 connectivity
PCU Traffic <NSE>

NS-VC NS-VC
Bearer Bearer
Mux Mux
Fanout Panel
4pDS3 4pDS3
GTL on MSA32
Although this configuration is no longer allowed for new customers, it is still
supported for existing configurations in Dual or Single slot MSA.
GTL on 4pOC3
• In PC04, GTL functionality is performed in the 4pOC3 cards on the 15K
shelf.
GTL in a Single cabinet

• 4pOC3 must be provisioned in pairs in 2N load sharing using
provisioning parameter associatedGtl. The pair of cards must be in
adjacent slots.
• (2) pair 4pOC3 per single cabinet is the standard configuration,
supporting the Nortel call model. The first pair supports intershelf ATM
and GTL functionality, the second pair supports only GTL.
• A configuration with only 1 pair of GTL+intershelf is not supported (this
configuration does not provide enough redundancy). Therefore the
minimum number of pairs is (2), with a maximum of (3) pairs (3 pairs are
supported only if all the interfaces are through ATM).
• Considering one GTL pair, Nortel recommendation for redundancy is to
provision a NSE on each GTL card. That means 1 NSE is split into 2 NS-
VCs, with 1 NS-VC/NSE provisioned per card.
• As each NSE is provisioned on each GTL card (within a pair), the
corresponding BVCs served by this NSE are duplicated on the 2 cards. On

the other hand, without redundancy, BVCs are configured only on one
GTL card.
Figure B-5 GTL provisioning with redundancy
NSE A NSE A
BVC BVC BVC BVC BVC BVC BVC BVC BVC BVC
A1 A2 A3 An-1 An A1 A2 A3 An-1 An
NSE B NSE B
BVC BVC BVC BVC BVC BVC’s are duplicated BVC BVC BVC BVC BVC
B1 B2 B3 Bn-1 Bn on each card B1 B2 B3 Bn-1 Bn
GTL-1 GTL-2
AssociatedGtl
• There are 2 ways to engineer GTL:

— If subscriber and throughput redundancy are required, then each GTL
card must be provisioned at 40% of the maximum capacity. In that
case, if one card fails, the remaining card is able to support the full
capacity of the NSEs configured on this card.
Figure B-6 GTL redundancy (provisioned at 40%)
GTL-1 GTL-2 Remaining GTL-1
80%
Failure
40% 40%
40% + 40% = 80%

AssociatedGtl
< Eng’g limit
— Each GTL card is provisioned at 80% of the maximum capacity. If

one card fails, all the cells (BVCs) are served by the remaining GTL,
only throughput will be potentially reduced (limited by 4pOC3
processing).

Figure B-7 GTL redundancy (provisioned at 80%)

UP to 100%
GTL-1 GTL-2
80% 80% 80%
Failure
Throughput limit
80%+ 80%
AssociatedGtl > CPU processing
GTL in a Dual cabinet

• GTL can only be provisioned in the 15K slave shelf.
• The first pair of OC3 cards supports intershelf ATM functionality only,
the other pairs support only GTL.
• GTL function supports NSE redundancy via software. In this case, GTLs
are provisioned in pairs, in adjacent slots, whereby if one of the two
GTLs fails, the other will take over the NSEs supported for the failed GTL
(2N). This NSE redundancy is achieved with provisionable parameter
associatedGTL.
• Considering one GTL pair, Nortel recommendation for redundancy is to
provision a NSE on each GTL card. That means 1 NSE is split into 2 NS-
VCs, with 1 NS-VC/NSE provisioned per card.
• As each NSE is provisioned on each GTL card (within a pair), the
corresponding BVCs served by this NSE are duplicated on the 2 cards. On
the other hand, without redundancy, BVCs are configured only on one
GTL card.
• In addition, up to 6 GTL can have a cold standby FP that will take over for
a failed GTL. This is via the Passport base 1:N sparing technique where N
in this case will be either 2, 4 or 6.
• The combination of NSE redundancy (2N) plus the 1:N sparing (the GTL
redundancy scheme) is referred to as 2N+1.

Figure B-8 GTL provisioning with redundancy
NSE A NSE A
BVC BVC BVC BVC BVC BVC BVC BVC BVC BVC
A1 A2 A3 An-1 An A1 A2 A3 An-1 An
NSE B NSE B
BVC BVC BVC BVC BVC BVC’s are duplicated BVC BVC BVC BVC BVC
B1 B2 B3 Bn-1 Bn on each card B1 B2 B3 Bn-1 Bn
GTL-1 GTL-2
AssociatedGtl
There are two possible ways to provision GTL, depending on the redundancy
scheme used:
• In the case of a 2N redundancy scheme (NSE redundancy only), each

GTL card must be provisioned at 40% of the max capacity. In that case, if
one card fails, the remaining card is able to support the full capacity of the
NSEs configured on this card.
Figure B-9
NSE redundancy (2N), each GTL provisioned at 40%
GTL-1 GTL-2 Remaining GTL-1
80%
Failure
40% 40%
40% + 40% = 80%

AssociatedGtl
< Eng’g limit
• With the 2N+1 redundancy scheme, the GTL functions are engineered at
80% of capacity because the time duration for a GTL to take over the
NSEs of a failed partner is only the time it takes for the cold standby to
take the place of the failed GTL.

Figure B-10
GTL redundancy 2N+1: each active card provisioned at 80%
GTL-1 GTL-2 GTL +1

80% 80%
Spare card
Failure in
Cold Standby
AssociatedGtl
GTL-1 GTL-2 GTL +1

80% 80%
Failure
AssociatedGtl
2p100base-t LAN
• In PC04, LAN cards in the 7K can no longer be ordered, as this card will
be MD in 2Q05.
• Existing configurations with LAN in the 7K are still supported in PC04,
but a new configuration cannot be ordered with 7K LAN cards.
• 7K LAN cards in the second 7K shelf are not supported.
• The cards are always deployed in pairs and the load is distributed across
the FPs.
2pGPDsk LAN
• LAN FPs are provisioned in pairs (1:1) hot standby mode with Ethernet
line Sparing (ELS) feature.
• Up to three pairs of LANs may be provisioned, depending on the traffic
segregation. If traffic segregation is needed (as in most cases), Nortel
recommends:
— Pair 1 - Port 0: Gn/Gp traffic
— Pair 1 - Port 1: Gx’ traffic
— Pair 2 - Port 0: billing traffic
— Pair 2 - Port 1: X1 traffic
• In a dual cabinet configuration, it is recommended to provision LAN
cards in the slave 15K, in order to leave slots available in the master 15K
to add GSCs or SASs.

• Support of both static routes and dynamic routes across any mix of GigE
and Ethernet cards on the Gn/Gp interface is not available.
• 100Base-Tx connections require Category 5, twisted-pair wire. 100
meters (328 feet) is the maximum recommended cable segment length
between a 100Base-Tx repeater and another node (due to signal timing
requirements).
4pGigabit Ethernet
• 4pGiGE is a new card introduced in PC04, with Passport release PCR5.1.
• It is provisioned in (1:1) for Gn/Gp interface only, cold standby
redundancy (the port will reinitialize upon a CPSO).
• This card must be installed in the slave 15K shelf, in order to leave slots
available in the master 15K to add GSCs or SASs.
• Per SGSN, the limit is 2 cards 4pGiGe.
• The 4pGe card will inter-work with 2p/4pOC3; the 4pGe card does not
interwork with the 2pGPDsk card.
• Due to restrictions/limitations, the VR supported Gn/Gp interface on
4pGige, can only be connected with atmmpe and gigabit ethernet media
type. In other words, PP/Gips cannot be configured on this VR.
• All the 4 ports of the 4pGiGE can be used, but the throughput limit is
2,5Gbit/s.
• Static and dynamic routes (RIP, OSPF) are supported on this card.
• MPLS via RSVP-TE supported only for SGSN/UMTS, not for SGSN/
GPRS.
Gb interface engineering
NS-VC
In order to provide end-to-end communication between the PCU and SGSN,
the concept of Network Service Virtual Connection (NS-VC) is used. The
NS-VCs are end-to-end virtual connections between the PCU and SGSN. At
each side of the Gb interface there is a one-to-one correspondence between
NS-VCs and NS-VLs. In a Frame Relay network, the NS-VC is the FR
permanent virtual connection (PVC).

Figure B-11 Relationship between NS-VCs and NS-VLs
End-to-end NS-VC
PCU SGSN
Frame
relay
Network
NS-VL at the PCU side NS-VL at the SGSN side
A Frame relay PVC must be contained within a PCM. A PCM can support
several NS-VCs. The limitation of the NS-VCs per PCM depends on the QoS
parameters used for these NS-VCs.
For example, with a PCM at 2.048 Kbps, engineered at 70%, the maximum
throughput is 1.430Kbps. If all the NS-VCs have a Committed Information
Rate (CIR) of 200kb, the number of NS-VCs are equal to 1.430/200.
Therefore, 7 NS-VCs can be used for this PCM.
NSE
The Network Service Entity (NSE) manages all the logical and physical
connections used to route packets between the PCU and the SGSN on the Gb
interface. The NSEI is used by the PCU and the SGSN to determine the NS-
VCs that provide service to a BVCI.
To provide redundancy on this Gb interface, the NSE associated to a PCU

must span a minimum of 2 NS-VCs, with each NS-VC supported by a
different link (for link redundancy) and each link on a different E1/DS1 card
(for card redundancy).
For Nortel access, (1) NSE per logical PCU (i.e, 1 NSE per BSC) is defined
as shown in Figure B-12. Motorola, Ericsson and Nortel access work in the
same way.

Figure B-12 Correspondence between PCU and SPM in the PCUSN
Logical PCU
BSC 1 (1 link Agprs)
PCUSP Card
BSC 2
SPM1
(BSC1)
BSC 3
A
G
P
R
S
E3
M
AGPRS U
E1 link
BSC 9 X
BSC11
BSC 10
SPM11 SPM12
BSC 11
Logical PCU
(2 links
Agprs)
For NOKIA access, PCU cards are installed in the BSC. It is possible to have
more than 1 PCU card per BSC; in that case for the same BSC multiple NSEs
are defined, (1) NSE per PCU.
Note that one NSE cannot be shared between two or more BSCs.

Figure B-13 Network Service Entity
PCU cards
Frame M M NORTEL
S S
relay A A
SGSN
P P P Network 1 2
NOKIA C C C
BSS U U U
3 2 1 NS-VC
11
NS-VC10
NSE1 NS-VC
NS-VC20 21
NSE2
NS-VC
NS-VC30
NSE3 31
NS-VC
NS-VC40 41
NS-VC50 NS-VC
51
NORTEL G G
T T
PCUSN L L
NSE4 NSE5
1 2
BSC4 BSC5
BVC
BSSGP Virtual Connections (BVCs) provide communication paths between
BSSGP entities. Each BVC is used in the transport of BSSGP PDUs between
peer point-to-point (PTP) functional entities. The BVCI is used to enable the
lower network service layer to efficiently route the BSSGP PDU to the peer
entity. This parameter is not part of the BSSGP PDU across the Gb interface,
but is used by the network service entity across the Gb.
A PTP functional entity is responsible for PTP user data transmission. There
is one PTP functional entity per cell. Within GSM 08.18, a cell is identified
by a BVCI unless it is explicitly stated otherwise.
Each BVC is identified by means of a BSSGP Virtual Connection Identifier

(BVCI) which has end-to-end significance across the Gb interface. Each
BVCI is unique between two peer Network Service Entities.

In the BSS, it is possible to configure BVCIs statically by administrative

means, or dynamically. In case of dynamic configuration, the BSSGP accepts
any BVCI passed by the underlying Network Service entity.
On the SGSN side, BVCIs associated with PTP functional entities are
dynamically configured.
Figure B-14 BVC within SGSN
Active BVC
GTL 1 Duplicated BVC GTL 2
BVC BVC BVC BVC BVC BVC

1 2 3 1 2 3
BVC BVC
SGSN 4 5
Gb Interface Gb Interface
NS-VC10 NS-VC11
NS-VC20
NSEI 1 NSEI 2
With redundancy W/o redundancy
BVC BVC BVC BVC BVC

1 2 3 4 5
One BVC defined per Cell
Redundancy has an important impact on the number of NSEs or BVCs

supported by the SGSN.
When NSE redundancy is used on Gb (NSE1 in Figure B-14), since each

NSE is provisioned on each GTL card, the corresponding BVC served by this

NSE is duplicated on the 2 cards. On the other hand, without redundancy

(NSE2 in Figure B-14), the BVC is configured only on one GTL card.
In this example, when 100% redundancy is used, the number of BVCs or

NSEs that can be configured per GTL is equivalent to the number of BVC/
NSE per GTL pair. (If the limit is 10,000 BVCs per GTL, it will be 10,000
BVCs for the pair).
DLCI
Frame relay networks use DLCI (Data Link Channel Identifier) to route the
frames. Between 2 adjacent nodes, a DLCI identifies a channel. Frame Relay
switches have routing tables that associate a port and DLCI in input to another
port and another DLCI in output. Creating a PVC between two users consists
of datafilling these routing tables.
Figure B-15 Frame relay
Frame relay
Network
PCUSN SGSN
Port 1 P4 P5 P5 P2 Port0
Dlci30 Dlci1500 Dlci200
Port4 Port5
Dlci30 Dlci1500
NS-VC
DLCI 21
A
Frame
NSE NS-VC DLCI 22 relay
B
There is one-to-one correspondence between NS-VCi and DLCI, as shown in

Figure B-15.

DLCI can be in the range 16 to 1007 inclusive.
DLCI has local significance only; this is NOT the address of the final frame’s
destination.
For point to point connections between PCU and SGSN, the DLCI must be
the same at both ends.
In case of a FR cloud used between PCU and SGSN, the DLCI is provided by
the FR operator.
Channel
Generically, “channel” refers to the user access channel across which frame
relay data travels. Within a given T1 or E1 physical line, a channel can be
either unchannelized or channelized, depending on how the line is configured.
Unchannelized:
In an unchannelized configuration, the entire T1/E1 line is considered a
channel, where:
• The T1 line operates at speeds of 1.536 Mbps and is a single channel

consisting of 24 T1 time slots.
• The E1 line operates at speeds of 1.984 Mbps and is a single channel
consisting of 31 E1 time slots.
Figure B-16 Unchannelized links used with Nortel Nodes
NORTEL G G MM NORTEL
T T SS
PCUSN L L AA
SGSN
NSE4 NSE5 1 2 Channel0= 1 2
TS [1…30]: (NSE4) NSVC1), (NSE5) (NSVC1)
E1 Link
BSC4 BSC5
E1 Link
Channel0=TS [1…30]: (NSE4) NSVC2), (NSE5) (NSVC2)

In a Nortel unchannelized configuration, Time slots are dynamically

allocated. The main advantage in the above figure is that if one NSE does not
need the whole bandwidth, it can be used by the other NSE if needed.
Channelized:
In a channelized configuration, the channel is any one of N time slots within a
given line, where:
• The T1 line consists of any one or more channels. Each channel is any
one of 24 time slots. The T1 line operates at speeds in multiples of 64
Kbps to 1.536 Mbps, with aggregate speed not exceeding 1.536 Mbps.
• The E1 line consists of one or more channels. Each channel is any one of
31 time slots. The E1 line operates at speeds in multiples of 64 Kbps to
1.984 Mbps, with aggregate speed not exceeding 1.984 Mbps.
Figure B-17 Channelized is used with NOKIA PCU or NOKIA SGSN
PCU cards
N N N
NOKIA S S S MM NORTEL
BSS E E E
Ch 0=TS [1…7]: (NSE1) NSVC1),
S S
SGSN
3 2 1 A A
Ch 1=TS [8…14]: (NSE2) NSVC1), 1 2
Ch 2=TS [15…30]: (NSE3) NSVC1),
E1 Link
E1 Link
Ch 0=TS [1…7]: (NSE1) NSVC2),
Ch 1=TS [8…14]: (NSE2) NSVC2),
Ch 2=TS [15…30]: (NSE3) NSVC2),
In the above configuration, 3 channels per E1 port must be datafilled , with

each channel using a number of TS and each channel supporting the traffic of
a PCU card.
Gb Interface limitation
NSE per SGSN
The maximum number of NSEs the SGSN can support is redundancy
dependent:

• Without redundancy: (not recommended by Nortel, but could exist with

access provider like Motorola), limitation is 200 NSEs per GTL card with
a maximum of 256 NSEs per SGSN.
• With redundancy: 200 NSEs maximum per GTL pair, with a maximum
of 256 NSEs per SGSN.
Sgsn parameter (maxNseSupported) limits the provisioning to the maximum
value: Range (1 to 256).
GTL supporting a single NSE

• without redundancy: a single NSE is supported by (1) GTL card only
• with redundancy: a single NSE is supported by a GTL pair (the 2 active
GTLs)
• an NSE cannot be split within more than a GTL pair
Simultaneous redundant and non-redundant NSE
• Parameter associatedGtl associates GTLs in pairs for redundancy.
• When using redundancy on NSE, only an even number of NS-VCs must
be defined and the same number of NS-VCs must be datafilled on each
GTL card of the pair. (2) NS-VC per NSE is the engineering
recommendation.
• If there is no redundancy for NSE, (which is not recommended),
parameter associatedGTL is not needed. An odd or even number of NS-
VCs per NSE can be defined and supported on the same GTL card.
• It is possible to provision a mix of redundant and non-redundant NSEs on
the same GTL cards by adding provisioning for the NSE to the mate GTL
without provisioning associated NSVCs/DLCIs.
NSE recovery delay
Ensure that there are no unused NSEs provisioned on the SGSN. If an NSE is
provisioned but does not have a real frame relay connection behind it, the
SGSN can wait several dozen seconds before moving on to the next one.
Normally, only a few milliseconds are sufficient before an NSE is ready.
NS-VC per NSE

• Up to (8) NS-VCs per NSE have been tested. The software allows more
than 8.
• Nortel Recommended value is : (2) NS-VCs per NSE
• For redundancy, it is recommended to split 1 NSE to an even number of
NS-VCs, the same number of NS-VCs configured on 2 different GTLs
belonging to the same pair or at least on a different port for link
redundancy. Using more than (2) NS-VCs per NSE may limit the number
of NSEs per SGSN (due to duplication).

• There is a one to one correspondence between NS-VC and DLCI. For

NSE redundancy, it is recommended to provision the 2 DLCIs on different
I/O cards (MSA32 or DS3).
NS-VC per SGSN
A maximum of 1536 NS-VCs can be defined per SGSN.
BVC per NSE

The number of BVCs per NSE depends on the number of NSEs defined in the
SGSN. The greater the number of NSEs, the fewer number of BVCs per NSE
and vise versa.
The Sgsn parameter maxBvcPerNse (see CIQ) must be datafilled. The range
is 1 to 600.
Total BVCs within the NSE configured must be greater than or equal to
10,000 BVCs per GTL pair in PC04.
The following sliding limits are observed, with 2N redundancy:
• with all NSEs provisioned, each pair of GTLs supports 50 BVCIs/NSE

(10,000/200).
• By fully provisioning each NSE, each GTL supports 16 NSEs (10,000/
600) per GTL pair.
BVC per GTL
• Without GTL redundancy: 10,000 BVCs maximum per GTL card.
• With GTL redundancy: 10,000 distinct point-to-point BVCs maximum
per GTL pair.
BVC per SGSN
• Without GTL redundancy, maximum 21,000 BVCs per SGSN
• With GTL redundancy: 21,000 distinct point-to-point BVCs per SGSN
(if we count the redundant ones it is 2 x 21000 Bvcs)
Frame relay rules
Frame relay service instances
• MSA32 supports up to 32 ports of FRUNI, FRNNI and /or FRATM FRF.5
(FR-ATM-FR Network interworking) and FRF.8 (FR-ATM Service
interworking).
Frame relay parameters
• QoS parameters (CIR, EIR, Bc, Tc) must be the same for all NS-VCs
associated to the same NSE.
• An attempt to bypass this rule will be rejected by the SGSN.

FrAtm number
To simplify, the FrAtm/<n> corresponds to a channel on a physical port. The
FrAtm number has only a local significance, and must be unique inside the
equipment. FrAtm number format is as shown in Table B-1:
Table B-1 FRATM naming convention
MSA Card DS3 Card
LP number 00 to 15 00 to 15
Port number 00 to 31 00 to 03
DS1 instance N/A 01 to 28
Channel number 00 to 23 00 to 23
• example: fratm/011023
The number of FrAtm defined per MSA32 does not exceed 500. The range is
(1 - 4294967295).
FrAtm address
Each FrAtm number is associated with an E.164 address, which has a local
significance, is unique inside the equipment and has the same format as the
FrAtm number. For example, The FrAtm address associated to the FrAtm/300
is E.300
Channel number
• On each port of the Gb interface card, used to connect a PCM link, a
channel must be defined, with the corresponding number of TS used for
this PCM:
— E1 link: 32 Time Slots : TS0 reserved for synchronization, TS1 to
TS31 used for data traffic
— T1 link: 24 Time Slots: TS1 to TS24 used for data traffic
• With Nortel access only one channel is defined per physical port (FrAtm)
with the default value zero (0), although the Passport accepts multiple
channels per port.
• For ERICSSON and NOKIA access, in certain cases we need to define
multiple channels. Each Channel is then associated with a range of TS, for
example:
— Channel 0 : TS [1-6]
— Channel 1: TS [7-17]
— Channel 2: TS [18-25]
— Channel 3: TS [26-31]

Rate Enforcement
This parameter controls the usage by GTL card of Frame Relay parameters
link committed information Rate (CIR) and Excess information Rate(EIR).
When set to OFF, CIR and EIR parameters associated to a Frame Relay
Virtual Circuit are not taken into account. It is highly recommended to set this
parameter to ON to maintain QoS and provision CIR and EIR correctly.
Gn interface
• The SGSN/GPRS can support the Gn interface in the following ways:
— Gn over ATM through 4pOC3 on the 15K shelf.
— Gn on Ethernet with dedicated LAN cards 2pGPDsk (ELS) on the
15K shelf. This solution is the most common in GPRS. Port 0 of
2pGPDsk is used. OSPF or static routes can be used.
— 4pGiGe in the 15K shelf can be used for Gn/Gp traffic, with some
restrictions (see “4pGigabit Ethernet” on page B-13).
Gx’ interface
• Gx’ LAN connects the SGSN to the SIG platform through Ethernet. The
recommendation is to use port 1 of the 2pGPDsk dedicated LAN card.
Ga interface
• Ga LAN connects the SGSN to the Billing platform through Ethernet. The
recommendation is to use a second pair of 2pGPDsk cards with ELS and
connect this LAN to port 0.
• A supported variation is to use Ethernet port 0 on SAS and MAP cards.
The two ports can be used to offer resilience. The traffic is load balanced
between the 2 ports thanks to flow based ECMP use (on a per source /
destination IP address). Only static routing is supported. Please be aware
that this solution is secured only if:
— dynamic routing is enabled on the network, otherwise the external link
failure won't be detected. When using static routing, it would not be
able of detecting external Ethernet link failure. Static routing allows
only to detect local link failure.
X1 interface
• X1 LAN connect the SGSN to the LI platform through Ethernet. The
recommendation is to use a second pair of 2pGPDsk with ELS and
connect this LAN to port 1.
• A supported variation is to use Ethernet port 1 on SAS and MAP cards.
The two ports can be used to offer resilience. The traffic is load balanced
between the 2 ports using flow based ECMP (per source/destination IP
address). Only static routing is supported. This solution is secure only if:
— dynamic routing is enabled on the network; otherwise external link
failure will not be detected. When using static routing, it is not

possible to detect external Ethernet link failure. Static routing allows

detection of local link failure only.
OA&M interface
• In the SGSN the CP card Ethernet port is used to carry the OA&M traffic.
In a shelf (2) connections are used, one per CP card.
Provisioning rules
Attached subscriber rules
The following parameters configure the number of attached subscribers that
the SGSN can support.
Sgsn maxsubscriber
This attribute specifies the total number of ‘GPRS-Attached’ subscribers this
SGSN can support simultaneously. The current number of ‘GPRS-Attached’
subscribers can be obtained from the sum of the currentlyAttached attribute
defined in the Gsc GMM component for all the Gsc instances. Value of this
attribute cannot be greater than the number authorized by the access code.
Example with 3 GSC (2+1) provisioned to 88K subs per GSC
Sgsn Maxsub >= sum(maxattach/Gsc) = 88K x 3 = 264K subs.
Access code must be requested to support 264K in this example.
GSC/n MaxAttachedSubscribers
This attribute specifies the maximum number of attached subscribers for this
instance of Gsc. This number must never exceed the capacity defined in the
capacity report of each GPRS release.
The number of attached subscribers per GSC is affected by the call model and
mainly by parameters:
• GSC/n avgActivePdpCPerActiveSub
• GSC/n avgPdpContextPerRecord
If the value of avgActivePdpCPerActiveSub and avgPdpContextPerRecord
increase, parameter MaxAttachedSubscribers must be reduced (due to GSC
memory constraint).
The card must be reset, to take into account the new number of attached
subscribers
GSD/n maxLlcActiveSubscribers
This attribute specifies the maximum number of MS that can be attached for
this instance of GSD. This gives the number of mobile subscribers that the
LLC and the SNDCP is to support per Gsd.

This parameter must be provisioned according to the customer call profile and
must never exceed 40K per GSD (memory limit with low throughput).
Parameter GSC/n avgActivePdpCPerActiveSub has an impact on
maxLlcActiveSubs provisioned per GSD.
Sum(maxAttach on GSC) >= Sum(maxLlcActive on GSD)
If this rule is not respected, you will not be able to activate more subscribers
than you define as attached.
The card must be reset, to take into account the new number of attached
subscribers.
White Book SCCP compliance

Nortel White Book SCCP implementation (compliant to ITU-T Q.711-Q.716
1993 recommendations), introduces both the Segmentation and Reassembly
(SAR) and XUDT/XUDTS messages.
Table B-2 lists the WB SCCP compliance in the different releases.

Table B-2 White Book SCCP compliance
GPRS2.1 and GPRS4.0 and

Platform GPRS6.0
GPRS3.0 GPRS5.0
SGSN compliant to ITU-T compliant to ITU-T compliant to

Q.711 - Q.716 1993 Q.711 - Q.716 1993 ITU-T Q.711 -
(WB SCCP) (WB SCCP) Q.716 1993
(WB SCCP)
exception Messages > 1KB not Messages > 2KB not
supported supported

Routing area rules

Figure B-18 Location area and routing area topology
HLR
GGSN
MSC/VLR Gn
Gn
Points to consider:
SGSN
1. A RA cannot span
SGSN
LA2 RA1 over more than one LA,
LA1
RA2 but can be as big as LA
RA3 RA4 RA1 RA2 RA4
2. An RA is controlled by
RA3
6 only one SGSN
5
7 CE 3. Each SGSN controls
1 4 LL 5
6 C
more than one RA.
6 4
5
6 7 1 E4 LL
27 5
4. The cells bordering
2 3
7 CE 3 7 two RA has more
1 4 LL C 7 4
4 1 4ELL messaging
6
5 4
2 2
3 6 5
7 CE 3
1 4 LL 7 C
1
4 1 1 ELL
2 4
4
2
RAC and LAC per SGSN

Information about RAC and LAC are listed in a table which is limited to 1000
entries. Each entry is defined by its unique combination of a
MCC+MNC+LAC+RAC entry. The limitation depends on the number of
MCC, MNC and LAC provisioned.
The RAs cannot be shared, that is, two SGSNs cannot share the same RA.
RAC per LAC

A RAC (Routing Area Code) cannot span more than one LAC (Location Area
Code), but can be as big as a LAC. A LAC is greater or equal to the RAC.
One RAC per LAC minimum must be defined.


C-1
SGSN parameters C
This appendix describes the Nortel SGSN features and associated parameters
from an engineering point of view. It contains parameters setting know-how
with inputs from R&D or 3GPP specifications.
Note that this high-level view shows only some of the SGSN components.
This appendix is not intended to detail all configuration parameters but it
focuses mainly on wireless specific parameters (Mobility Management,
Session management, etc.) that have a capacity and/or performance impact
the SGSN or end user.
For a complete description of SGSN components, refer to NTP 411-5221-060

Nortel SGSN Components.
Refer to NTP 241-5701-050, Passport 7400, 15000, 20000 Commands and

NTP 241-5701-600, Passport 7400, 15000, 20000 Configuration Guide for
further information on Passport Configuration Management.
Summary of Timers and retry settings

A significant number of provisionable parameters are related to Timers (in
order to monitor message losses) and the Number of Retries (when the timers
expire). This section briefly describes the generic guidelines used in
provisioning these parameters and their impact on the system capacity and
performance.
The Timers are classified in to the following classes:

1. Call related inter-nodal message monitoring timers
2. Nodal health checking timers
The following sections provide basic guidelines in provisioning Call related

inter-nodal message monitoring timers. The Nodal Health Checking Timers
are provisioned independently and case by case basis.
The impact of the timers on the Performance

Under normal operating conditions, irrespective of the timer values, the
timers do not have any impact on the User observable performance (KPI) of

C-2 SGSN parameters
the system. The normal operating conditions are, both links and nodes are
properly engineered and are operating in their engineering limits. The call
success rate > 99.99%.
The abnormal conditions are those conditions, where the message delays and
losses are higher than expected values, may be due to higher traffic levels,
system overload conditions and bad link conditions.
Under abnormal conditions, if the timer values are provisioned less than the
occurred delays, false retransmissions occur (i.e. messages are retransmitted
unnecessarily even when the messages are not lost). This does not impact the
performance, but impacts the capacity.
Under abnormal conditions, if the timer values are provisioned more than the
occurred delays, there is no impact on the performance. But, if the messages
are lost, then the detection of message loss takes longer time. This increases
the Call setup delay and other call related procedure delays observable by the
user. In the worst case, the user re-originates a new call, before the message
loss is detected. This impacts the call success rate.
The impact of the timers on the System Capacity

Under normal operating conditions, the properly provisioned timer values do
not have any impact on the Capacity of the System. The normal operating
conditions – both links and nodes are properly engineered and are operating
in their engineering limits. The call success rate > 99.99%. The delays are
within the expected values.
Under normal conditions, if the timer values are provisioned less than the
unnecessarily even when the messages are not lost). This impacts the capacity
due to retransmissions consuming both CPU real-time and link bandwidth.
Under normal conditions, if the timer values are provisioned more than the
occurred delays, there is no impact on the capacity.
Under abnormal conditions, if the timer values are provisioned less than the
unnecessarily even when the messages are not lost). This impacts the capacity
due to retransmissions consuming both CPU real-time and link bandwidth.
Under abnormal conditions, if the timer values are provisioned more than the
occurred delays and if the messages are lost, then the detection of message
loss takes longer time. In the worst case, the user re-originates a new call,
before the message loss is detected. This impacts the call success rate. It also
impacts the capacity of the system, as more resources are tied for the longer
duration.

SGSN parameters C-3
Table C-1
Message delays
Item Physical Layer Message Delay Comments

(msec)
Avg 99.99%
1 Wired Interface (Nodes are < 200 < 500 Significant portion of delay occurs
co-located) at the End Nodes. Therefore, the
delays are significantly impacted
by the capacities of the End
nodes.
2 Wired Interface (Nodes are < 500 < 1000 Significant portion delay occurs
Remotely Located from not only at the End Nodes, but also
each other) in the Network. The network delay
depends on the distance between
the nodes, the number of routers,
switches and the type of network
technologies, IP or ATM. Usually,
messages in IP network
experience more delays than ATM
network.
3 Wireless Interface < 500 < 3000 A significant portion of the

message delay occurs not only in
the low bandwidth wireless links,
but also at the low capacity mobile
terminals and access
technologies.
Timer Provisioning Guidelines

The values of the Timers should be large enough not to have false
retransmissions and small enough to identify message losses quickly. Due to
low message loss rate, the Timer values are provisioned larger than required
in order to make false retransmissions negligible (> 99.99%). Another
important objective is to make the provisioning simple. Therefore, all the
timers at layer 3 and above (both Wireline and Wireless) are recommended
to be provisioned at 5 Sec, unless otherwise specifically mentioned to go
with the values provided in 3GPP TS 24.008 v3.18.0.

C-4 SGSN parameters
Figure C-1
Timer Value > 99.99% of Delay
pdf
99.99% Delay value
Delay (msec) Recommended

Timer value
Number of Retries
The number of retries parameter is decided by the amount of the time that the
end user waits before re-originating another call.
The # Retries= (Call re-origination Time/current layer timer).
With the assumption that a wireless caller waits about 10 sec before re-
originate the call and with the Timer value = 5 Sec, the number of retries =
(10/5) – 1 = 2 -1 = 1.
Let the message loss probability be p and let the number of retransmissions be
n. Then, the probability of successful delivery is 1-p(n+1). If a call contains
N number of messages, then the probability of successful call is (1-pn+1)N.
Table C-2 gives the call success rate for various values of p, n and N.

SGSN parameters C-5
Table C-2
Call Success Rate with Message Loss Probability p =0.001 (1 out of 1000)
n N=2 4 6 8 10
0 0.998001 0.996005996 0.99401498 0.992027944 0.99004488
1 0.999998 0.999996 0.999994 0.999992 0.99999
2 0.999999998 0.999999996 0.999999994 0.999999992 0.99999999
3 1 1 1 1 1
4 1 1 1 1 1
Table C-3
Call Success Rate with Message Loss Probability p = 0.01 (1 out of 100)
n N=2 4 6 8 10
0 0.9801 0.96059601 0.941480149 0.922744694 0.904382075
1 0.99980001 0.99960006 0.99940015 0.99920028 0.99900045
2 0.999998 0.999996 0.999994 0.999992 0.99999
3 0.99999998 0.99999996 0.99999994 0.99999992 0.9999999
4 1 1 0.999999999 0.999999999 0.999999999
Green: Call Success Rate > 4 9’s Red: Call Success Rate < 4 9’s
It is recommended that all the Number of Retries parameter should be

provisioned 2, unless otherwise specifically mentioned to go with the values
in the 3GPP specifications.
Some scenarios, the number of retries parameter value is provisioned greater

than 2. For example, for heart-beat messages, this parameter is recommended
to be > 2 as it needs to address system reset scenarios.

C-6 SGSN parameters
SGSN recommendation tables

SGSN attributes
Table C-4
SGSN attributes
Attribute Full Name Default Recommended Value

value
ResetTimer Sgsn rstTim 0 default value
maxNseSupported Sgsn MaxNse 256 256
maxBvcPerNse Sgsn MaxBvc 200 200
dataVolumeLimit Sgsn dvl disabled default value
perCellStatistics Sgsn disabled default value
tariffTimeChangeTrigger Sgsn ttcTrig disabled default value
SGSN GTL attributes

Figure C-2
SGSN GTL attributes
Attribute Full Name Default Recommended
NsBlockTimer Sgsn Gtl Ns tnsBlk 3 default value
NsBlockRetries Sgsn Gtl Ns nBlk 3 default value
NsUnBlockRetries Sgsn Gtl Ns nUnBlk 3 default value
NsResetTimer Sgsn Gtl Ns tnsReset 3 default value
NsResetRetries Sgsn Gtl Ns nReset 5 default value
NsTestTimer Sgsn Gtl Ns tnsTest 30 60
NsAliveTimer Sgsn Gtl Ns tnsAlive 3 default value
NsAliveRetries Sgsn Gtl Ns nAlive 10 default value
BvcResetTimer Sgsn Gtl Bssgp tBvcReset 60 default value
bvcResetRetries Sgsn Gtl Bssgp nBvcReset 3 default value

SGSN parameters C-7
GTL/* attributes
Table C-5
GTL/* attributes
bvcBlockedTimer SgGtl tbvcBlocked 10 default value
bvcBmaxTimer SgGtl tbvcBmax 10 default value
bvcLeakRateTimer SgGtl tbvcLeakRate 10 default value
bvcBlockSetThreshold SgGtl bvcBlockedSet 10 default value
bvcBlockedClrThreshold SgGtl bvcBlockedClr 5 default value
packetFlowContext SgGtl Pfcfeat disabled default value
SGSN GSD attributes

Table C-6
SGSN GSD attributes
rfc1144Slots Sgsn Gsd Sndcp 16 8 - 16; no lower

than 8
rfc2507MaxPeriod Sgsn Gsd Sndcp 256 default value
rfc2507MaxTime Sgsn Gsd Sndcp 5 default value
v42bisDictionary Sgsn Gsd Sndcp p1 512 default value
alternateLlcXidNegotiation Sgsn Gsd disabled default value
generateLlcXidForNonDefaults Sgsn Gsd disabled default value
xidDuringIrauAdmMode Sgsn Gsd enabled default value
v42bisMaxStringSize Sgsn Gsd Sndcp p2 20 default value
v42bisMaxStringSize Sgsn Gsd Sndcp p2 20 default value

—sheet 1 of 3—

C-8 SGSN parameters
Table C-6
SGSN GSD attributes (continued)
compressionAlgorithmsInIrau Sgsn Gsd Sndcp rfc1144, default value

rfc2507,
v42bis
CipheringHardwareAssist Sgsn Gsd LLc Autoconfig- Autoconfigure

ure
t200RetransmitTimer Sgsn Gsd SapiC t200 5.0 default value
n200MaxRetransmits Sgsn Gsd SapiC n200 3 default value
n201UMaxUinfoFieldLength Sgsn Gsd SapiC n201U 400 default value
msFlowControlThTimer Sgsn Gsd SapiC msFlow 5 readyTimer
t200RetransmitsTimer Sgsn Gsd SapiD /3 t200 5 default value
pduunconfirmedInformationLife- Sgsn Gsd SapiD /3 pduUn- no default same as t200

Time Info (sapi3)
n200MaxRetransmits Sgsn Gsd SapiD /3 n200 3 default value
n201UMaxUinfoFieldLength Sgsn Gsd SapiD /3 n201U 500 1520 (per GPS

Bulletin)
n201IMaxIinfoFieldLength Sgsn Gsd SapiD /3 n201I 1503 default value
kWindowSizeDownlink Sgsn Gsd SapiD /3 kD 16 default value
kWindowSizeUplink Sgsn Gsd SapiD /3 kU 16 default value
t200RetransmitsTimer Sgsn Gsd SapiD /5 t200 10.0 default value

Time Info (sapi5)

Bulletin)

—sheet 2 of 3—

SGSN parameters C-9
Table C-6
SGSN GSD attributes (continued)

Time Info (sapi9)

Bulletin)

Time Info (sapi11)
Bulletin)

—sheet 3 of 3—

C-10 SGSN parameters
GSD/* attributes
Table C-7
GSD/* attributes
maxLlcActiveSubscribers Gsd maxLlcActSubs 100 40000
sessionsToMobileRatio Gsd sessionsToMobileRatio 1.0 default value
maxHeaderCompressionEnti- Gsd Sndcp 0 = no head 0 = no head

ties comp comp
MaxV42bisEntities Gsd Sndcp 0 = noV42b 0 = noV42b comp

comp
lleToMobileRatio Gsd Llc lleToMobileRatio 1.5 default value
abmModeLleToMobileRatio Gsd Llc abmModeLleToMo- 1.5 default value

bileRatio
allowableCompressionAlgo- Gsd Llc allowableCompres- rfc1144, default value -

rithms sionAlgorithms rfc2507 none
GSD/* buffering attributes

Table C-8
GSD/* buffering attributes
Buffering
NumBlocks Gsd Buffer/mini NumBlocks 11236 default value
BlockSize Gsd Buffer/mini BlockSize 128 default value
NumBlocks Gsd Buffer/small NumBlocks 5728 default value
BlockSize Gsd Buffer/small BlockSize 604 default value
NumBlocks Gsd Buffer/medium NumBlocks 881 default value
BlockSize Gsd Buffer/medium BlockSize 1501 default value
NumBlocks Gsd Buffer/large NumBlocks 4186 default value
BlockSize Gsd Buffer/large BlockSize 1520 default value

—sheet 1 of 2—

SGSN parameters C-11
Table C-8
GSD/* buffering attributes (continued)
Buffering
NumBlocks Gsd Buffer/extralarge NumBlocks auto- default value

config
BlockSize Gsd Buffer/extralarge BlockSize 4096 default value
DownlinkBuffer (optional compo-

nent)
maxSessWithBuff Gsd DLBuf maxSessWithBuff 1000 1000
maxPacketsBuffPerSess Gsd DLBuf maxPacketsBuffPerSess 12 12
maxBytesBuffPerSess Gsd DLBuf maxBytesBuffPerSess 10486 default value
totalBytesReservedForBuffer- Gsd DLBuf 104857 10485760

ing 60
pduLifetimeInBuff Gsd DLBuf pduLifetimeInBuff 20 same as

t200Retransmit
timer; 5
BuffCheckInterval Gsd DLBuf buffCheckInterval 2.0 1.0
IrauBuffer (optional component)
maxSessWithBuff Gsd IrauBuf maxSessWithBuff 1000 100
maxPacketsBuffPerSess Gsd IrauBuf maxPacketsBuff- 12 12

PerSess
maxBytesBuffPerSess Gsd IrauBuf maxBytesBuffPerSess 10486 default value
totalBytesReservedForBuffer- Gsd IrauBuf totalBytesReservedFor- 104857 1048576

ing Buffering 6
pduLifetimeInBuff Gsd IrauBuf pduLifetimeInBuff 20 same as

t200Retransmit
timer; 5
BuffCheckInterval Gsd IrauBuf buffCheckInterval 2.0 1.0

—sheet 2 of 2—

SGSN GSC attributes

Table C-9
SGSN GSC attributes
Attribute Full Name Default value Recommended
uglRetries Sgsn Gsc MapC nUgl 0 default value
SaiRetries Sgsn Gsc MapC nSai 0 default value
mcTimer Sgsn Gsc MapC tMc 13 default value
mapFallbackTimer Sgsn Gsc MapC fbTmr 30 default value
afrRetries Sgsn Gsc MapC afrRetries 1 2
readyTimer Sgsn Gsc Gmm t3314 see comments 44
mobileReachableTimer Sgsn Gsc Gmm tReach- 0 58

able
implicitDetachTimer Sgsn Gsc Gmm tImplicit 0 default value
pagingTimer Sgsn Gsc Gmm t3313 8 default value
pagingRetries Sgsn Gsc Gmm n3313 1 default value
nwkInitiatedDetachTimer Sgsn Gsc Gmm t3322 6 default value
nwkInitDetachRetries Sgsn Gsc Gmm n3322 4 2
idRequestTimer Sgsn Gsc Gmm t3370 6 default value
idRequestRetries Sgsn Gsc Gmm n3370 4 default value
ptmsiReallocTimer Sgsn Gsc Gmm t3350 6 default value
ptmsiReallocationRetries Sgsn Gsc Gmm n3350 4 default value
authCipheringTimer Sgsn Gsc Gmm t3360 6 default value
authCipheringRetries Sgsn Gsc Gmm n3360 4 default value
authEvents Sgsn Gsc Gmm authEv- 20 20

ents
cipheringAlgorithms Sgsn Gsc Gmm ciphAlgo 1: noCiphering 1: geav1

2: noCiphering 2: noCiphering
—sheet 1 of 5—

Table C-9
SGSN GSC attributes (continued)
subsRegisterRecoveryUpda- Sgsn Gsc Gmm tSubsReg 5 default value

teTimer
T3TunnelTimer Sgsn Gsc Gmm t3 Tunnel 20 12
authTripletsReuse Sgsn Gsc HlrC authTrip 5000 default value
nwkPdpDeactTimer Sgsn Gsc Sm t3395 8 default value
nwkPdpDeactRetries Sgsn Gsc Sm t3395Retry 4 default value
nwkPdpModifyTimer Sgsn Gsc Sm t3386 8 default value
nwkPdpModifyRetries Sgsn Gsc Sm n3386 4 default value
tc1n (CpResponseTimer) Sgsn Gsc sms tc1n 20 default value
tc1n retries (CpResponseRe- Sgsn Gsc sms tc1nret 3 default value

tries)
tr1n (RpResponseTimer) Sgsn Gsc sms tr1n 78 default value
tr2n (iwmscResponseTimer) Sgsn Gsc sms tr2n 33 default value
n3CreateRequest Sgsn Gsc Gtp n3CrReq 2 default value
t3CreateResponse Sgsn Gsc Gtp t3CrResp 2 5
n3DeleteRequest Sgsn Gsc Gtp n3DelReq 5 default value
t3DeleteResponse Sgsn Gsc Gtp t3DelResp 2 5
n3EchoRequest Sgsn Gsc Gtp n3EcReq 5 8
t3EchoResponse Sgsn Gsc Gtp t3EcResp 60 15
n3SgsnContextRequest Sgsn Gsc Gtp 2 default value

n3SgsnCntxreq
t3SgsnContextResponse Sgsn Gsc Gtp 5 default value

t3SgsnCntxresp
n3UpdateRequest Sgsn Gsc Gtp 2 default value

n3Updatereq
—sheet 2 of 5—

Table C-9
t3UpdateResponse Sgsn Gsc Gtp 4 5

t3UpdateResp
gtpV0Version Sgsn Gsc Gtp Gtpver ver7-3 see comment
echoRequest Sgsn Gsc GtpM echoReq enabled default value
echoTimeInterval Sgsn Gsc GtpM echoInt 2 formula
maxGtpPaths Sgsn Gsc GtpM maxPaths 10 formula
ggsnGraceTimer Sgsn Gsc ggsnGraceTimer 5 default value
sgsnGraceTimer Sgsn Gsc sgsnGraceTimer 5 default value
pathInactivityTimer Sgsn Gsc pathInactivity- 10 default value

Timer
pathRediscoveryTimer Sgsn Gsc pathRediscov- 5 default value

eryTimer
msPurgeFunction """ Mspurge msPurge disabled default value
purgeOnExplicitDetach """ Mspurge purgeExplicit disabled default value
purgeMinimumInactiveAge """ Mspurge purgeMinAge disabled default value
locationUpdateTimer Sgsn Gsc Bssap tLocUpd 15 10
explicitGprsDetachTimer Sgsn Gsc Bssap t8 4 default value
explicitGprsDetachRetries Sgsn Gsc Bssap n8 2 default value
explicitImsiDetachTimer Sgsn Gsc Bssap t9 4 default value
explicitImsiDetachRetries Sgsn Gsc Bssap n9 2 default value
implicitImsiDetachTimer Sgsn Gsc Bssap t10 4 default value
implicitImsiDetachRetries Sgsn Gsc Bssap n10 2 default value
sgsnResetTimer Sgsn Gsc Bssap t12 4 default value
sgsnResetRetries Sgsn Gsc Bssap n12 2 default value

—sheet 3 of 5—

Table C-9
BssapSccpUserInfo: This group contains attributes added to support Bssap Sccp User Information
BssapReturnOption Sgsn Gsc bssapRetOpt RetUndeliver- default value

able
BssaphopCounter Sgsn Gsc bssapHopCntr 15 default value
BssapXudtOption Sgsn Gsc bssapXudt OFF default value
BssapRegistrationRequest- Sgsn Gsc bssapReqTmr 10 5

Timer
SSFGroupprov: This group has been added to support all the SSF components in the shelf
tssfTimer Sgsn Gsc tssftimer 3 5
ssfchargingGuardTimer Sgsn Gsc ssfCGuard- 3 5

Timer
ssfTcapStackRegistration- Sgsn Gsc ssfTcapRegTmr 10 default value

Timer
ssfChargingGuardRetryAt- Sgsn Gsc ssfCGuardRe- 0 default value

tempts tryAtt
ssfRoamerService Sgsn Gsc ssfRoamServ Enabled default value
ssfSupportedCamelPhase Sgsn Gsc ssfSupported- notSupported 3

Phase
ImeiIdRequest Sgsn Gsc imeiId (Gmm) Disabled Configurable for

LI
authNonCiphSmPdu Sgsn Gsc Gmm AuthNon- Disable default value

Ciph
ppfresettimer Sgsn Gsc Disable=0 default value
authenticateSmPdus Sgsn Gsc Disable default value
imeiIdRequest Sgsn Gsc Disable default value
sendOldAndNewTlli Sgsn Gsc Enabled default value

—sheet 4 of 5—

Table C-9
n3IdRequest Sgsn Gsc 5 2
t3IdResponse Sgsn Gsc 5 default value

—sheet 5 of 5—
GSC/* attributes
Table C-10
GSC/* attributes
maxAttachedSubscribers Gsc/n maxAtSubs 500 see comment
avgActivePdpCPerActiveSubs Gsc/n avgPdpC 1.0 Customer depen-

dent
maxConcurrentTransactions Gsc/n GtpM maxTr 100 350
maxTransactions Gsc/n GtpM 100 500
maxTransactions Gsc/n Mc 1024 default value
maxIncomingRequests Gsc/n GtpM maxInReq 1000 default value
heartbeatTimer Gsc/n Bssap SS7IpIf 5 default value

HbTimer
keepAliveTimer Gsc/n Bssap SS7IpIf 15 default value

KAliveTr
T7Timer Gsc/n Pfm T7Timer 5 default value
T7Retries (nT7) Gsc/n Pfm T7Retries 3 1
PacketFlowTimer (t9) Gsc/n Pfm PacketFlow- 6 40

Timer
maxCamelDialogues Usc/n Ssf 35000 20000

maxCamelDialogues
resetPpfUponRadioStatusInd Gsc/n disabled default value

—sheet 1 of 2—

Table C-10
GSC/* attributes (continued)
Clearalarmdelay Gsc/n Oc prov 30 Default Value
sigCongestionMark Gsc/n Oc prov 3 Default Value
sigCongestionCycleDuration Gsc/n Oc prov 1 Default Value
maxRateAllowedForAttach Gsc/n Oc prov 40 Default Value
maxRateAllowedForIrau Gsc/n Oc prov 25 Default Value
maxRateAllowedForHlrResetUgl Gsc/n Oc prov 25 Default Value
maxRateAllowedForInitialDp Gsc/n Oc prov 20 Default Value
maxMapcBufferForAttach Gsc/n Oc prov 40 Default Value
maxMapcBufferForIrau Gsc/n Oc prov 50 Default Value
maxMapcBufferForHlrResetUgl Gsc/n Oc prov 35 Default Value
maxRateAllowedForMofsm Gsc/n Oc prov 11 Default value
maxRateAllowedForMtfsm Gsc/n Oc prov 11 Default value
maxRateAllowedForBssapLocUpdt Gsc/n Oc prov 30 Default Value
maxRateAllowedForBssapMsActInd Gsc/n Oc prov 30 Default Value
maxMapcBufferAllowedForMofsm Gsc/n Oc prov 60% Default value
maxMapcBufferAllowedForMtfsm Gsc/n Oc prov 60% Default value

—sheet 2 of 2—

DNS attributes
Table C-11
DNS attributes
retryTimer Sgsn DnsAg tRetry 5 default value
maxRetries Sgsn DnsAg nRetry 2 default value
refreshTime Sgsn DnsAg tRefresh 10080 default value
maxDynamicEntries maxDyEnt 0 200
maxDnsQueries DnsAg 200 default value
TCAP/* attributes
Table C-12
TCAP attributes
maxInvokesPerSubsystem Tcap maxInvPerSub Sgsn- Sgsn-

Subsy=600 Subsy=2500
CapSub = 600 CapSub = 1250
MscEmul=600 MscEmul=1250
maxTransactionsPerSubsystem Tcap maxTransPerSub Sgsn- Sgsn-

Subsy=600 Subsy=2000
CapSub = 600 CapSub = 1000
MscEmul=600 MscEmul=1000
registrationTimer Tcap registrationTimer 10 default value
hopCounter Tcap HopCptr 15 default value
XUDToption Tcap XudtOpt OFF ?
heartbeatTimer Tcap SS7IpIf HbTimer 5 default value
keepAliveTimer Tcap SS7IpIf KAliveTr 15 default value
hdlcBuffers Tcap SS7IpIf HdlcBuf 2250 Disabled

—sheet 1 of 2—

Table C-12
TCAP attributes (continued)
lostMessagesThreshold Tcap SS7IpIf Lostmsg 1300 default value
cnxUpTimer Tcap SS7IpIf cnxUp- 10 default value

Timer
clDialogueTimer Tcap 20 default value
UGLSanTimer Tcap Map Ugltim 11 11
SAISanTimer Tcap Map Saitim 9 9
CLSanTimer Tcap Map Cltim 10 25
DSDSanTimer Tcap Map Dsdtim 25 5
ISDSanTimer Tcap Map Isdtim 25 8
MTFSMSanTimer Tcap Map Mtfsmtim 79 60
MOFSMSanTimer Tcap Map Mofsmtim 60 default value
FSMSanTimer Tcap Map Fsmtim 60 default value
RFSMSanTimer Tcap Map Rfsmtim 25 5
AFRSanTimer Tcap Map Afrtim 25 5
PMSSanityTimer Tcap Map Pmstim 50 5
PSLSanityTimer Tcap Map Pslstim 60 default value
Clearalarmdelay Tcap Oc prov 30 default value
maxRateAllowedForSai Tcap Oc prov 90 default value
maxRateAllowedForMtfsm Tcap Oc prov 38 default value
maxRateAllowedForNonSaiMsg Tcap Oc prov 900 default value
maxTransBufferForSai Tcap Oc prov 40% default value
maxTransBufferForMtfsm Tcap Oc prov 30% default value

—sheet 2 of 2—

SGSN SAS attributes

SGSN ACCT is obsoleted; see “SGSN Accounting Server (SAS)
provisionable attributes” on page C-111 for details.
Table C-13
SGSN SAS attributes
Attribute Full Name Default value Value
cdrCapture Sas/* cdrCap No default Sgsn, ~mobility,

smo, smt
locationBasedBilling Sas/* lbb disabled default value
transferInterval Sas/* trInt 30 NoDelay
cdrUpdateInterval Sas/* updateInt 60 15
scdrPartialRecordInterval Sas/* scdrInt NoPartial- 30

Records
ScdrMaxContainers Sas/* scdrMaxC 5 1
mcdrPartialRecordInterval Sas/* mcdrInt NoPartial- NoPartial-

Records Records
mcdrMaxContainers Sas/* mcdrMaxC 5 default value
echoRequestInterval Sas/* echoReqInt 5 1
drtResponseTimeout Sas/* tCdrTr 5 default value
drtRetries Sas/* nCdr 1 default value
genAuditFiles Sas/* genAf disabled default value
AuditFileLife Sas/* afLife 5 default value
RoamerCapture Sas/* roamCap all default value
dailyPartialTimeOfDay Sas/* dailyPartialTimeOf- disable default value

Day
asn1FileGeneration Sas/* disable 1000000

asn1FileGeneration

SGGTL NSE attributes

Table C-14
Sggtl NSE attributes
Attribute Full Name Default value Value
bwForSvcToFratm Sggtl Nse 1000000 default value
SGSN provisionable attributes

This group contains general provisioning data for ServingGprsSupportNode
(Sgsn).
Reset Timer
Description This attribute specifies the reset timer used for a
GprsSubscriberControl (Gsc). This timer is started when an FP on which a
Gsc component is provisioned comes up. During the reset timer period, the
Gsc is considered to have recently experienced a restart, and the GPRS
Mobility Management (GMM) ignores and discards messages from the
mobile (except ATTACH REQUESTS and ROUTING AREA UPDATE
REQUESTS). If the reset timer has expired, and the mobile subscriber has not
performed a subsequent GPRS-Attach, any received messages are considered
a protocol violation and responded to with the appropriate reject or a GMM
STATUS message, until the mobile performs another GPRS-Attach.
Range value 0 – 255 mn
Default value 0
Recommended value 0
Engineering rule
tariffTimeChangeTrigger
Description This attribute specifies whether Tariff Time Change Trigger
(TTCT) feature is enabled or disabled. When enabled, SGSN Accounting
Server will close the existing data volume container and open a new container
in S-CDR when a Tariff Time Change event is received. This enables the
down stream billing system to use different billing rates for different time
container
Range value disabled=ttcTriggerOff, enabled = ttcTriggerOn
Default value Disabled

Recommended value Disabled
Engineering rule This is enabled is the customer is using DVL. The Tariff
Time Change Trigger (TTCT) feature adds Tariff Time Change processing
capability to the SGSN Billing application. The DVLT feature will
accommodate multiple containers implemented by the TTCT feature when
generating a partial record. Additionally, the DVLT feature implements
operational attributes and collected events for partial records and containers
specifically used by the TTCT feature.
maxSubscribers
Description This attribute specifies the total number of ‘GPRS-Attached’
subscribers this SGSN can support simultaneously. It does this by limiting the
total of all the individual maxAttachedSubscribers attribute in all the
GprsSubscriberControl (Gsc) components. For example, if this SGSN has
two GSC provisioned with 75K subs per GSC, this attribute must be
provisioned with a value of 150K. For each GPRS release, it exists a
maximum number of attached subscribers per GSC, which is given in the
corresponding capacity bulletin. In GPRS5.0, the value is 85K subs per GSC.
Range value 1000 - 5000000
Default value
Recommended value customer network dependent
Engineering rule The value of this attribute cannot be greater than the
number authorized by the access code. The access code (attribute
maxSubsAccessCode) is unique for each SGSN.
Please contact your local Nortel Customer Service representative for more
information.
maxNSEsupported
Description This attribute specifies the maximum Network Service Entities
(NSEs) supported on this SGSN. The value provisioned for
maxNseSupported affects the allowed value for maxBvcPerNse, and vice
versa. The higher the value for maxNseSupported, the lower the allowed
value for maxBvcPerNse.
Range value 1 - 256
Default value 256
Recommended value Must be in accordance with the total number of NSEs

defined on the Gb interface. In GPRS5.0, it cannot exceed 200 NSEs per GTL

card. Using 2 GTL cards with redundancy, as each NSE is defined on each
card, we are limited to 256 NSE per SGSN.
Engineering rule The product of maxNseSupported and maxBvcPerNse

should not exceed 51200. Changing the value of maxNseSupported will result
in a system reload.
maxBvcPerNse
Description This attribute specifies the maximum BSS GPRS Virtual
Connections (BVCs) supported per Network Service Entity (NSE). One BVC
corresponds to a unique cell.
Range value 1 - 600
Default value 200
Recommended value Must be datafilled with the value corresponding to the

network
Engineering rule The value provisioned for maxNseSupported affects the

allowed value for maxBvcPerNse, and vice versa. The higher the value for
maxNseSupported, the lower the allowed value for maxBvcPerNse.
The product of maxNseSupported and maxBvcPerNse should not exceed

51200
The total number of BVC per GTL doesn’t exceed 7000BVC.
dataVolumeLimit
Description This attribute gives the operator the ability to determine when
partial SGSN Packet Data Protocol (PDP) Call Detail Records (S-CDRs) are
generated with a partial record reason of “data volume limit” based upon the
number of combined uplink and downlink kilobytes that have been
transferred by the active session.If this attribute is set to disabled, then a 2-
gigabyte volume limit will be used to trigger the generation of a partial S-
CDRs.
Range value 128 – 5120 (Kbytes)
Engineering rule The Data Volume Limit Trigger (DVLT) feature generates
partial SGSN Customer Data Records (S-CDRs) when a PDP Context
transfers an operator-provisioned limit of combined uplink and downlink user
traffic. The value of this feature is that it reduces the potential for billing data

loss by generating partial records based upon the operator’s risk tolerance
according to how high or low the data volume threshold is set
perCellStatistics
Description This attribute specifies whether per cell statistics are enabled or
disabled. The per cell statistics are defined in the Gsc/n Mcc/mcc Mnc/mnc
Lac/lac Rac/rac CellId/cid component. When enabled, the per cell statistics
data is collected and spooled by the Data Collection System (DCS).
Collection does not start for a cell until that cell receives its first uplink
message.
Range value enabled,disabled
Engineering rule There is no noticeable performance/realtime impact to the

SGSN. There is, however, an impact to the OAM Performance Server, and
thus the recommendation for not activating these counters on a network-wide
basis. Please consult with Nortel support before enabling this feature.
GPRS Subscriber Control (GSC) provisionable attributes

Figure C-3
GSC provisionable attributes
(Root)
SGSN maxAtSubs AvgPdpC MaxpercentHand

nUgl nSaitMc fbTmr SgsnNum Lpc
Afrretries mscEmulmode mscSsn
GSC GSC/n Msce164@ HlrsimIP@

T3314 tReachable tImplicit
authevents Ciphalgo tSubsregister HlrSimport smcri
MAP client T3313 n3313 T3370 MAP client Mssn sccpsvcreqtr
T3322 n3322 n3370 mapsccpvar
T3350 n3350 T3360
Gmm T3tunnel n3360 Gmm
Radioprioritylevel
Sm
T3395 t3395retry t3386
T3386retry defAPNoper defAPNnetwk
Sms
Tc1n tc1nret
Gtp Tr1n tr2n maxtransaction
GtpM n3CrReq t3CrReq n3delreq GtpM

t3delResp n3EcReq t3EcResp VlrSsn E164@
N3cntxreq t3cntxresp n3updatereq Ss7IP@ Ss7Tcpport
Bssap T3updateresp Bssap heartbeatTr keepAlivetr
Ssf Echoreq echoInt maxpaths Ssf

maxcamel
HlrC RtInd BssapSsn BssapnatofAdd HlrC
Bssape164TT BssapRetOpt BssapHopCntr
BssapXudt BssapReqTmr Maxrecs pdpPerrec
SstTimer SsfCGuardTr SsfCapRegTr

SsfCGuardRetry SsfCgpaRInd SsfSsn
SstRoamserv SsfSupCamel
AuthTriplet

maxAttachedSubscribers
Description This attribute specifies the maximum number of attached
subscribers for this instance of GprsSubscriberControl (Gsc). The current
attached subscribers can be obtained from the attribute currentlyAttached
defined in the GprsMobilityManagement component.
Range value 1 - 1 000 000
Default value 500
Recommended value depends of the dimensioning study.
Engineering rule The sum of the maxAttachedSubscribers provisioned on

all the Gsc instances should not exceed the value of maxSubscribers
provisioned on the ServingGprsSupportNode (Sgsn).
avgActivePdpCPerActiveSub (avgPdpC)
Description This attribute specifies the average number of PDP contexts that
can be active for an active subscriber in this GprsSubscriberControl (Gsc).
Range value Decimal (1.0..16.0)
Default value 1.0
Recommended value 1.0
Engineering rule Increasing this parameter increases memory usage and can
adversely affect the capacity of the SGSN. This parameter is dependent on the
devices in the customers network; and as to how many active PDPs the
devices run at one time.
avgPdpContextPerRecord
Description This attribute specifies the average number of PDP contexts that
can be active for an active subscriber in this GprsSubscriberControl (Gsc).
Range value Decimal (0..50)
Default value 1
Recommended value Customer Dependent; see engineering rules below;

must match the avg number of APNs provisioned on the HLR per sub. The
value of the provisioned parameter gsc/* hlrc avgPdpContextPerRecord needs
to be set to the average number of PDP context subscription data records per
subscriber in the HLR taking roamers into account. (Per GPS Bulletin #127.)

Engineering rule This value correlates to the average number of APN

defined per subscriber in the HLR Increasing this parameter increases HLRC
memory usage and can adversely affect the capacity of the SGSN
If the average number of APN in the HLR is greater than the

avgpdpcontextPerRecord, there is a risk of attach reject, when memory
reserved for HlrcPdpContext entities is completely allocated. If this parameter
is under provisioned, ISDs and corresponding UGLs can fail due to resource
exhaustion of HlrcPdpContexts. These contexts are used to store the PDP
context subscription data records.
Up to 2 avgPdpContextPerRecord, with Nortel call model has no significant

impact on GSC capacity (at 3; it is negligible) {see chart below}
If > 3 , you will have to reduce maxattachedsubs per GSC (reduce approximately
from 2000 subs, each time you add 1 avgpdpctxtperrecord)
Table C-15
APN vs. Subscriber capacity
Max. Max.
Attached Attached
No. Of Max. Attached Max. Attached Subs Subs
APN's Subs (MEM) Subs (CPU) (PROV) (Overall)
1 97700 166620.3906 88000 88000
2 91700 166620.3906 88000 88000
3 86300 166620.3906 88000 86300
4 81600 166620.3906 88000 81600
5 77300 166620.3906 88000 77300
6 73500 166620.3906 88000 73500
7 70000 166620.3906 88000 70000
Session Management
The component "Sgsn GprsSubscriberControl and GprsSmGlobalProv"
represents the common provisioning data for the Session Management
protocol layer of the 2G-SGSN. It contains the provisionable attributes
detailed below.
nwkPdpDeactTimer (T3395)
Description This attribute specifies the timer value used in the SGSN or in
the GGSN initiated PDP Context Deactivation procedure.
This timer is started when a DEACTIVATE PDP CONTEXT REQUEST

message is sent to the MS and is stopped when a DEACTIVATE PDP
CONTEXT ACCEPT message is received from the MS. If this timer expires
before the receipt of a DEACTIVATE PDP CONTEXT ACCEPT message, the
SGSN or GGSN initiated PDP Context deactivation procedure is retried for a
maximum of nwkPdpDeactRetries. The timer must be provisioned to a

value that is greater than the maximum expected round trip delay of a
Protocol Data Unit (PDU).
Range value 1 - 255 s
Default value 8 s
Recommended value default
Engineering rule Spec 24.008 Sec:11.2.2 defines that this parm should be
set to the default.
The timer must be provisioned to a value that is greater than the maximum
expected round trip delay of a Protocol Data Unit.
It is advised to keep this attribute at a reasonably low value so as to free

resources in SGSN and GGSN as soon as possible and to prevent wasting
network resources, e.g., in case of radio problems preventing the MS response
to be received.
nwkPdpDeactRetries (T3395Retry)
Description This attribute specifies the number of retry attempts after the
timer nwkPdpDeactTimer (T3395) expires during a SGSN or GGSN initiated
PDP Context deactivation procedure.
Range value 0 - 4
Default value 4
Recommended value Default
set to the default.
This value must be kept to a low value to free resources in SGSN and GGSN
as soon as possible and to prevent wasting network resources, e.g., in case of
radio problems preventing the MS response to be received.
nwkPdpModifyTimer (T3386)
Description This attribute specifies the timer value used in the SGSN
initiated PDP Context Modification procedure. This timer is started when a
MODIFY PDP CONTEXT REQUEST message is sent to the MS and is
stopped when a MODIFY PDP CONTEXT ACCEPT message is received
from the MS. If this timer expires before the receipt of a MODIFY PDP
CONTEXT ACCEPT message, the PDP Context modification procedure is
retried for a maximum of nwkPdpModifyRetries.

Default value 8 s
set to the default.
expected Round Trip Delay of a PDU between the SGSN and the MS.
nwkPdpModifyRetries (N3386)
Description This attribute specifies the number of times the SGSN, while
acting as the new SGSN, resends a MODIFY PDP CONTEXT REQUEST
message to the MS if the nwkPdpModifyTimer expires while the MS is
undergoing an Inter-SGSN Routing Area Update (IRAU).
Range value 0 - 4
Default value 4
set to the default
If this attribute is exhausted, the nwkPdpModifyRetriesExhausted attribute

will be incremented.
GPRS Mobility Management

(New in PC04) GMM and DNS failure cause code mapping is introduced.
The component "Sgsn GprsSubscriberControl GmmGlobalProv" represents

the common provisioning data for the GPRS Mobility Management protocol
layer of the SGSN
readyTimer (T3314)
Description The timer is restarted whenever a signaling or data Protocol
Data Unit (PDU) is received from the MS. In the event of readyTimer expiry,
the gmmState (defined in MobilityContext) transitions to STANDBY state.
There are three possible values of the READY Timer: useMsValue,

forceStandby, and normal timer values.
If the value is set to the useMsValue, the value sent by the MS is used as the
READY Timer. However, if the value is set to useMsValue and the MS

attempts to cancel the READY Timer, the SGSN overrides the cancel attempt
by using the forceStandby value.
The forceStandby value causes the MS’s GMM context to be immediately

transitioned to STANDBY state after a received or transmitted PDU is
processed.
All other values of this attribute cause both the SGSN and MS to use this
value; the MS cannot negotiate it.
Range value useMsValue, forceStandby, (1.. 11160) seconds
Default value 44 seconds
Recommended value 44s (as per Spec)
Engineering Rule The readyTimer value should be at least 10% greater than
the t200RetransmitTimer provisioned in the SapiControl component, except
when readyTimer is set to forceStandby or useMsValue. The negotiated value
for the readyTimer for an MS can be displayed in the MobilityContext
component. The timer must be provisioned to a value that is greater than the
maximum expected round trip delay of a Protocol Data Unit (PDU).
If the timer value is less than 60 s, then it must be a multiple of 2 seconds. If

the timer value is greater than 60 s, but less than 360 s, it must be a multiple of
60 s. If the timer value is greater than 360s, it must be a multiple of 360s.
mobileReachableTimer
Description The mobileReachableTimer is started when the MS drops
from READY state to STANDBY state or when the MS is forced to
STANDBY state. In the event of mobileReachableTimer expiry, the GMM
starts the implicitDetachTimer.
Range value 0 - 255 min
Default value 58 min
Recommended value 58 minutes (at a minimum T3312 + 4 mn)
Engineering rule TS 24.008 indicates that the timer value must be at least
four minutes longer than the longest periodicRaUpdateTimer - T3312
(defined in component SGSN MobileCountryCode/n MobileNetworkCode/n
LocationAreaCode/n RoutingAreaCode/n).
Furthermore, the timer must be provisioned to a value that is greater than the
maximum expected Round Trip Delay of a PDU between SGSN and MS.

implicitDetachTimer
Description This attribute specifies the timer value used by the GPRS
Mobility Management (GMM) for the removal of GMM context in an
implicit detach after the mobileReachableTimer has expired.
Default value 0
Recommended value 0; in order to optimize SGSN resources
Engineering rule the timer value must be provisioned to a value that is

greater than the maximum expected Round Trip Delay of a PDU between
SGSN and MS.
pagingTimer (T3313)
Description Timer used for the GPRS Paging procedure. Upon expiry of the
pagingTimer, if the Paging procedure is not completed, the GPRS Paging
procedure is restarted for a maximum number of pagingRetries (N3313).
Default value 8 s
Recommended value 8
Engineering rule the timer must be provisioned to a value that is greater

than the maximum expected RTD of a PDU between SGSN and MS.
The value of the attribute rpResponseTimer cannot be less than the sum of the
maximum number of cpResponseRetries(tc1nRet) multiplied by the
cpResponseTimer(tc1n) value plus the maximum number of pagingRetries
(n3313) multiplied by the pagingTimer (t3313) value.
pagingRetries (N3313)
Description Specifies the number of retry attempts after the pagingTimer
(T3313) expires.
Range value 0 - 4
Default value 1
Recommended value 1
Engineering rule The value of the attribute rpResponseTimer cannot be less

than the sum of the maximum number of cpResponseRetries(tc1nRet)

multiplied by the cpResponseTimer(tc1n) value plus the maximum number of

pagingRetries (n3313) multiplied by the pagingTimer (t3313) value.
The increase in retries may not significantly improve the success probability
nwkInitiatedDetachTimer (T3322)
Description this attribute specifies the timer used in the network initiated
Detach procedure. The timer is started on transmission of DETACH
REQUEST to the MS and stopped on receipt of DETACH ACCEPT from the
MS. Upon expiry of nwkInitiatedDetachTimer, if the Detach procedure is not
completed, the network initiated Detach procedure is restarted for a
maximum of nwkInitDetachRetries (N3322).
Default value 5 s
Recommended value 5s

nwkInitDetachRetries (N3322)
Description this attribute specifies the number of retry attempts after the
nwkInitiatedDetachTimer (T3322) expires.
Range value 0 - 8
Default value 4
Recommended value 2
Engineering rule
idRequestTimer (T3370)
Description This attribute specifies the timer used in Identification
procedure. Upon expiry of the idRequestTimer, if the identification procedure
is not finished, the identification procedure is restarted for a maximum of
idRequestRetries (N3370).
Default value 6 s


idRequestRetries (N3370)
idRequestTimer (T3370) expires
Range value 0 - 8
Default value 4
set to the default.
ptmsiReallocTimer (T3350)
Description This attribute specifies the timer used in the P-TMSI
Reallocation procedure. The P-TMSI reallocation procedure can also be
performed within the Attach or RA Update procedures as well. This timer is
thus either started on transmission of ATTACH ACCEPT sent with P-TMSI
and/or TMSI, and stopped on receipt of ATTACH COMPLETE or started on
transmission of RAU ACCEPT with P-TMSI and/or TMSI and stopped on
receipt of RAU COMPLETE or started on transmission of P-TMSI REALLOC
COMMAND and stopped on receipt of P-TMSI REALLOC COMPLETE.
Upon expiry of the ptmsiReallocTimer, if the P-TMSI Reallocation procedure

is not finished, it is restarted for a maximum of ptmsiReallocationRetries
(N3350).
Default value 6 s
set to the default.
expected RTD of a PDU between SGSN and MS.
ptmsiReallocationRetries (N3350)
ptmsiReallocTimer (T3350) expires.
Range value 0 - 8

Default value 4
set to the default.
authCipheringTimer (T3360)
Description This attribute specifies the timer used in Authentication and
Ciphering procedure. The timer is started on transmission of
AUTHENTICATION AND CIPHERING REQUEST to the MS and stopped on
receipt of either AUTHENTICATION AND CIPHERING RESPONSE or
AUTHENTICATION AND CIPHERING FAILURE from the MS. Upon expiry
of this timer, if the Authentication and Ciphering procedure is not finished, it
is restarted for a maximum of authCipheringRetries (N3360).
Default value 6 s
set to the default. The timer must be provisioned to a value that is greater than
the maximum expected RTD of a PDU between SGSN and MS.
authCipheringRetries (N3360)
authCipheringTimer (T3360) expires.
Range value 0 - 8
Default value 4
set to the default.
authEvents
Description this attribute specifies the number N which indicates that at
every Nth event requiring authentication, the Authentication procedure is
initiated with the MS.
This parameter is not for per MS; it’s used to count events over all the affected
procedures per GSC.

Range value 0 (never), 1 - 255
Default value 20
Recommended value 20; Reducing this value impacts the capacity and
increase this value compromises security. Refer the Capacity tool for your
customer call profile for the Sensitivity analysis
Engineering rule When the value is set to never, the Authentication

procedure is never performed;. When the value is set to 1, the Authentication
procedure is performed every time an event that triggers authentication
occurs. The provisioning of any other value N for this attribute indicates that
every Nth event that can be authenticated undergoes this Authentication
procedure.
cipheringAlgorithms
Description This attribute specifies the Ciphering Algorithms supported on
this SGSN in descending order of preference. The mobile provides a list of
the ciphering algorithms it supports to the SGSN. The SGSN compares the
mobile provided values with the values listed in this attribute.
The ciphering algorithms supported are: geav1 (GPRS algorithm)
Range value noCiphering, geav1
Default value noCiphering
Recommended value geav1. As per the Capacity Report, ciphering does not
have an adverse affect on the capacity and throughput of the SGSN
Engineering rule The first value provisioned in this attribute that is also in
the mobile provided list is chosen as the ciphering algorithm for use in
communicating with this mobile.
subsRegisterRecoveryUpdateTimer
Description This attribute specifies the maximum recovery delay time used
by the SGSN to re-create the association between the HLR, in the case of the
HLR Reset, or VLR, in the case of VLR Reset, and a MS. The timer is started
on a receipt of a valid LLC frame from the MS following the Reset HLR or
VLR to which this MS is attached. When the timer expires the appropriate
procedure is initiated by the GPRS Mobility Management (GMM). The actual
timer used is a randomized value less than this value in order to distribute the
traffic to HLR or VLR after an HLR or VLR Reset. In the case of an HLR
Reset, a MAP-UPDATE GPRS LOCATION (UGL) is performed and in the
case of a VLR Reset a MAP-LOCATION UPDATE is performed.

Default value 5 s
Recommended value 5 s
Engineering rule If C is the capacity of the HLR in terms of messages per

sec. and R is the rate at which LLCs from the MS, the timer value must be
max(5, R/C).
t3TunnelTimer
Description This attribute specifies the time that the old SGSN will continue
to forward packets to the new SGSN during an Inter SGSN Routing Area
Update. The timer is started in the old SGSN when it receives a GTP SGSN
CONTEXT REQUEST message and there is at least one active PDP context.
Upon timer expiry, the packets are no longer forwarded to the new SGSN.
Default value 20 s (see 3GPP TS 29.060)
Engineering rule This parameter value must be greater than

t3SgsnContextResponse * n3SgsnContextRequest ( 5 * 2 = 10).
This value must be smaller than the CL ACK timer on the HLR. In past
activity in other customer networks, the duration of t3TunnelTimer needs to
be coordinated with the HLR timer that is used to wait for cancel location ack.
During the InterSGSN RAU, the old SGSN does not acknowledge the cancel
location from the HLR until the T3 tunnel timer is expired. Therefore, the
HLR timer used to wait for CL ack needs to be larger than the t3TunnelTimer
to ensure smooth operation. In fact the value of this timer must be coordinated
with the HLR
The MM and PDP contexts are removed by the old SGSN only when the
t3TunnelTimer expires. This allows the old SGSN to complete the forwarding
of N-PDUs. It also ensures that the MM and PDP contexts are kept in case the
MS initiates another inter SGSN routeing area update before completing the
ongoing one.
authTripletsReuse
Description This attribute specifies the maximum number of times each
Authentication Triplet can be reused when authenticating a subscriber. The
reuse of the Authentication Triplets is done only in abnormal situations, when
new triplets cannot be received from the HLR due to connectivity breakdown
between the SGSN and the HLR.
Range value (0 – 5000)

Default value 5000
Recommended value 5000
Engineering rule the recommended value supports up to 100000 subscribers

being attached (with 1 :20 authevents). With 9 attaches per second, it allows
about 3 Hr HLR downtime.
ImeiIdRequest
Description (PC04: A00004238) This attribute controls whether or not the
SGSN will send an ID Request message to the MS to retrieve its IMEI. This
attribute specifies whether the Serving GPRS Support Node (SGSN)
sends the Identity Request message to the Mobile Station (MS) to retrieve the
International Mobile Equipment Identifier (IMEI). This message is sent
during an attach or inter SGSN routing area update procedure. If the MS does
not provide the IMEI in an Identity Response, the attach or IRAU is rejected
This parameter enhances the SGSN to support handling a mobile subscriber’s

International Mobile Equipment Identifier (IMEI) in the SGSN for Lawful
Interception and billing purposes
Range value Integer 0 or 1; (disabled=0, enabled=1)
Default value disabled=0
Recommended value Customer Dependent
Engineering rule
authNonCiphSmPdu
Description (PC04:A0000762) The new authNonCiphSmPdu provisionable
parameter is used to control whether the SGSN authenticates the mobile upon
receipt of an unciphered PDP context activation request or PDP Context
Deactivation request. If set to ENABLE, the SGSN shall authenticate the
mobile upon receipt these messages. Authenticating the mobile in this
scenario will prevent the SGSN from writing to the wrong billing record. This
scenario could occur due to a PTMSI collision or.a rogue mobile attempting
to use a PTMSI assigned to a valid mobile. Authenticating the mobile will
result in additional messaging between the SGSN and the HLR. If set to
DISABLE, authentication shall not be performed on each unciphered PDP
context activation request and unciphered PDP context deactivation request
(note, regular 1 in N authentication is still in effect, therefore, an
authentication can still be performed in this case).Setting this value to
ENABLE will enhance the security of the overall system at the expense of
additional authentication messages on the Gr interface.

Default value disabled
Recommended value Customer Dependent
Engineering rule Enabling this feature will result in additional SGSN –

HLR messaging. If the customer is already TCAP limited, then enabling this
feature could have a negative impact on the capacity of the SGSN.
ppfresettimer
Description (A00006626)Periodic Paging Resumption: This attribute
specifies the timer for which a response must be received for a Cancel
Location message from the GPRS Mobility Management (GMM) application.
The timer is started when a Cancel Location message is received from the
Home Location Register (HLR) and cancelled when a response is received
from GMM. If the timer expires, then the transaction in the Mobile
Application Part (MAP) Client is released and a Cancel Location response
message sent to the HLR.
Range value 0=disabled, 0-10
Recommended value disabled
Engineering rule Enabling this feature will result in additional SGSN –

HLR messaging. If the customer is already TCAP limited, then enabling this
feature could have a negative impact on the capacity of the SGSN.
In PC03 was associated to CustomSpare/2 spare9Prov.
authenticateSmPdus
Description (A00000762) This attribute specifies that every non-ciphered
ACTIVATE PDP CONTEXT REQUEST and DEACTIVATE PDP
CONTEXT REQUEST message initiated by the Mobile Station (MS) is
authenticated. This attribute enables mandatory authentication of every
message only if the mobile has attached in non-ciphering mode. Optional
authentication is controlled by the authEvents attribute and still applies if the
message is ciphered. For example, if the value of authEvents is 3, then if the
3rd event was a ciphered ACTIVATE PDP CONTEXT REQUEST message,
the authentication procedure is initiated. Session Management (SM) requests
GPRS Mobility Management (GMM) to perform the authentication
procedure.
Range value enabled, disabled

Engineering rule Enabling shall increase the number of authentications

performed by the SGSN when it receives an unciphered PDP Context
Activation or Deactivation Request. This shall result in an increase in the
number of SAI messages sent by the SGSN to the HLR over Gr interface. The
increase in the number of SAI messages can be roughly calculated.
Increase in number of SAI messages =
[(Number of unciphered Activation Requests + Number of unciphered

Deactivation Requests) * (1 – 1/N)]
_________________________________________________________
Number of authentication vectors received per SAI Response Message
where (1 – 1/N) excludes the number of SAI messages due to1-in-N

Authentication supported by the SGSN.
imeiIdRequest
Description (a00004238) This attribute specifies whether the Serving GPRS
Support Node (SGSN) sends the Identity Request message to the Mobile
Station (MS) to retrieve the International Mobile Equipment Identifier
(IMEI). This message is sent during an attach or inter SGSN routing area
update procedure. If the MS does not provide the IMEI in an Identity
Response, the attach or IRAU is rejected..
Engineering rule The total number of Attach and IRAU rejects may increase
when the “ImeiIdRequest” is enabled. The reason is that in addition to pre-
existing conditions, mobile subscribers will be rejected if they fail to provide
their IMEI when the SGSN requests it.
sendOldAndNewTlli
Description (PC04) This attribute specifies how the Serving GPRS Support
Node (SGSN) is to handle the Temporary Logical Link Identity (TLLI) in
messages sent to the Mobile Station (MS) during the period of time after an
ATTACH COMPLETE, ROUTING AREA UPDATE COMPLETE, or
ACTIVATE REQUEST message is received from the MS, all using the old
TLLI, until the MS sends a message with the new TLLI. If set to enabled, the
SGSN uses both the old and new TLLIs and includes both in the messages
sent to MS during this period. When the SGSN receives a message from the
MS with a new TLLI, it will start using that TLLI and stop using the old
TLLI. If set to disabled, the SGSN includes only the old TLLI in the

messages sent to the MS during this period. This behavior may cause
problems with delivery of the messages to the MS and Nortel support
personnel should be contacted before using this setting.
Default value enabled
Recommended value enabled
Engineering rule If the customer wants this parameter disabled; contact

Nortel support because this may cause problems with messaging to the MS.
n3IdRequest
Description This attribute specifies the number of times this SGSN, while
acting as the new SGSN, will attempt to send an IDENTIFICATION
REQUEST message to the old SGSN.
Range value 1-20
Default value 5
Recommended value 2
Engineering Rule Recommendation based upon the timer and retry study
previously noted in “Summary of Timers and retry settings” on page C-1.
t3IdResponse
Description This attribute specifies the time this SGSN, while acting as the
new SGSN, will wait for a response to the IDENTIFICATION REQUEST
message from the old SGSN..
Range value 1-20
Default value 5
Engineering rule Recommendation based upon the timer and retry study
previously noted in “Summary of Timers and retry settings” on page C-1.
resetPpfUponRadioStatusInd
Description This attribute specifies whether to set "Paging Proceed Flag
(PPF)" to True or False when a "Mobile Station (MS)" in ready state
temporarily goes out of reach as indicated by the BSSGP Radio status
message received by GMM.If the value of this attribute is set to disable, PPF
is not set to False when Radio Status message is received.If the value of this

attribute is set to enable, PPF is set to False when Radio status message is
received.This attribute is added to provide the flexibility to the operator to
either set PPF to True or False when Radio Status message is received..
Engineering rule Dependent on whether the customer wants to set the PPF
when radio status is received.
MAP Client
The component "Sgsn GprsSubscriberControl MapClientGlobalProv"
represents the MAP Client functionality of GSC boards. It contains the
provisionable attributes detailed below.
mcTimer
Description This attribute specifies the amount of time the MapClient allows
for a response from the HLR. The timer is started when messages MAP
SEND AUTHENTICATION INFO, stand-alone MAP INSERT SUBSCRIBER
DATA, MAP UPDATE GPRS LOCATION, or READY-FOR-SMS are sent to
the HLR.
Default value 13 s
Engineering rule The timer must be provisioned to a value that is greater

than the maximum expected round trip delay of a Protocol Data Unit (PDU)
and greater than all the timers provisioned in the MapStack component for
messages sent to the HLR.
The timer value is recommended to 13 Sec, in stead of 5 sec (past setting), in

order to reduce the number of retries during the overload conditions.
uglRetries
Description This attribute specifies the times the SGSN can send the MAP-
UPDATE GPRS LOCATION to the HLR upon no reception of the MAP-
UPDATE GPRS LOCATION ACK.
Range value 0 - 4
Default value 0

Recommended value 0
Engineering rule The number of retries are set to zero, instead of 1, in order
to reduce the impact on MAP card during the overload conditions.
saiRetries
Description This attribute specifies the number of times the SGSN can send
the MAP SEND AUTHENTICATION INFO to the HLR upon no reception
of the MAP SEND AUTHENTICATION INFO ACK.
Range value 0 - 4
Default value 0
Recommended value 0
Engineering rule The number of retries are set to zero, instead of 1, in order
to reduce the impact on MAP card during the overload conditions.
afrRetries
the MAP AUTHENTICATION FAILURE REPORT to the HLR upon no
reception of the MAP AUTHENTICATION FAILURE REPORT ACK.
Range value 0 - 4
Default value 1
Recommended value 2
Engineering rule The increase in retries may not significantly improve the
success probability.
mcFallbackResetTimer
Description The MapClient is capable of retaining backward compatibility
for certain MAP messages it supports. This attribute is used by the MapClient
to determine when to reset its application Context version lookup tables to the
latest versions. This would be useful for example if the HLR node gets
upgrade from a old version of the MAP to the version the SGSN supports. In
response to a table reset, the Map Client will initially use the latest application
context version when addressing all HLRs.
A value of 0 means the fallback tables will not be reset.
Range value 0 - 365 days
Default value 30 days

Recommended value 30 days
Engineering rule
sccpServiceRequestTimer
Description This attribute specifies the amount of time the Map Client will
wait for a response after sending a Service Request primitive to the Map
Protocol Stack. The Service request will result in a bind of the MAP SGSN
subsystem into the SCCP protocol layer. The count of timeouts can be viewed
in the SccpServiceRequestTimeouts attribute of the MapClientStat group.
Retries of the ServiceRequest are infinite since the MapClient can not send or
receive Map messages until it is successfully registered with the Map Stack.
Range value 0 – 60 sec
Default value 10 s
Engineering rule
msPurgeFunction
Description This attribute determines whether the purge function is enabled.
If it is disabled, no purge messaging will occur regardless of the other purge
provisioning.
Range value Disable, Enable
Default value Disable
Recommended value Disable; Enabling the feature has a capacity impact on

the SGSN. See Capacity Report
Engineering rule
purgeOnExplicitDetach
Description This attribute determines whether the purge procedure is
initiated on a mobile initiated detach (i.e. power-off detach).
Range value Disable, Enable
Default value Disable

the SGSN. See Capacity Report
Engineering rule

purgeMinimumInactiveAge
Description This attribute specifies the minimum length of time that a
context must be inactive before being purged by the MS Purge audit.
Range value Disabled, 1-744

the SGSN given the extra signalling to the HLR notifying to purge MS
Engineering rule
BSSAP Client
The component "Sgsn GprsSubscriberControl BssapClientGlobalProv"
represents the Bssap Client functionality of GSC boards. It contains the
provisionable attributes detailed below.
locationUpdateTimer
Description This attribute specifies the amount of time the BSSAP+ allows
for a response from the VLR when BSSAP+ LOCATION UPDATE
REQUEST messages are sent to the VLR.
Default value 15 s
Recommended value 10; The response time from the HLR should be less
than 10 s.

than the maximum expected round trip delay of a Protocol Data Unit (PDU).
bssapHopCounter
Description Each SS7 node decrements the hop counter by one. If the
message makes more hops than is specified, the message is dropped at the
node where the counter was exhausted.
Range value 1 - 15
Default value 15
Recommended value 15; no impact on capacity
Engineering rule This attribute is used for circular route prevention and is
only supported by Whitebook/ANSI96 SCCP.

bssapXudtOption
Description This attribute specifies whether or not XUDT (extended
unitdata) messages can be used. The specified value is used to determine the
type of message used for transmission of SCCP connectionless data.
If off: an SCCP XUDT (extended unitdata) message is transmitted only when

the data size is such that segmentation is required, otherwise an SCCP UDT
(unitdata) message is transmitted.
If on: an XUDT message is transmitted for all connectionless data regardless

of data size.
Range value ON, OFF
Default value OFF
Recommended value Usually, this attribute should specify off so that XUDT
is only used when needed.
Engineering rule Because XUDT is only supported by Whitebook, an

operator may desire to set this value to on so that this node supports
Whitebook (ITU-T 96/ANSI-96) SCCP.
bssapRegistrationRequestTimer
Description This attribute specifies the amount of time the BSSAP Client
waits for the REGISTRATION ACK message after sending a REGISTRATION
REQUEST message to the SCCP Protocol Stack. Retries of the Registration
Request are infinite since the BSSAP Client cannot send or receive BSSAP
messages until it is registered successfully with the SCCP stack. The
reqTimeouts attribute indicates the number of timeouts that have occurred.
Default value 10 s
Engineering rule
explicitGprsDetachTimer (T8)
for a response from the VLR when BSSAP+ GPRS DETACH INDICATION
messages are sent to the VLR. The count of timeouts can be viewed in the
t8Timeouts attribute.

Default value 4 s
Engineering rule Per GSM Spec 9.18, Section 19.
expected round trip delay of a Protocol Data Unit (PDU).
explicitGprsDetachRetries (N8)
the BSSAP+_GPRS_DETACH_INDICATION to the VLR upon no reception
of the BSSAP+_GPRS_DETACH_ACK. If the maximum number of retries is
reached, BSSAP+ increments the gprsDetachMaxAttempts attribute (defined
in Gsc Bssap).
Range value 0 - 8
Default value 2
explicitImsiDetachTimer (T9)
Description This attribute specifies the amount of time the (BSSAP+) allows
for a response from the VLR when explicit BSSAP+ IMSI DETACH
INDICATION messages are sent to the VLR. The count of timeouts can be
viewed in t9Timeouts attribute (defined in Gsc Bssap).
Range value 1 - 30 sec
Default value 4 s
explicitImsiDetachRetries (N9)
the explicit BSSAP+ IMSI DETACH INDICATION to the VLR upon no

reception of the BSSAP+ IMSI DETACH_ACK. If the maximum number of

retries is reached, BSSAP+ increments the explicitImsiDetachMaxAttempts
attribute (defined in Gsc BSSAP).
Range value 0 - 9
Default value 2
implicitImsiDetachTimer (T10)
for a response from the VLR when implicit BSSAP+ IMSI DETACH
INDICATION messages are sent to the VLR. The count of timeouts can be
viewed in t10Timeouts attribute (defined in Gsc Bssap).
Default value 4
implicitImsiDetachRetries (N10)
the BSSAP+ IMSI DETACH INDICATION to the VLR upon no reception of
the BSSAP+ IMSI DETACH ACK. If the maximum number of retries is
reached, BSSAP+ increments the implicitImsiDetachMaxAttempts attribute
(defined in Gsc Bssap)
Range value 0 –10
Default value 2

sgsnResetTimer (T12)
for a response from the VLR when BSSAP+ RESET INDICATION messages
are sent to the VLR. This message is sent when a Gsc recovers following a
card failure. The count of timeouts can be viewed in t12Timeouts attribute
(defined in Gsc Bssap).
Range value 1 –120 sec
Default value 4 s
expected round trip delay of a Protocol Data Unit (PDU)
SgsnResetRetries (N12)
Description This attribute specifies the number of times the BSSAP+ can
send the BSSAP+ RESET INDICATION to the VLR upon no reception of the
BSSAP+ RESET ACK. If the maximum number of retries is reached, BSSAP+
increments the sgsnResetMaxAttempts attribute (defined in Gsc Bssap).
Range value 0 - 12
Default value 2
Engineering rule Per GSM Spec 9.18, Section 19
Service Switching Function (SSF) Client

tssfTimer
Description This attribute specifies the amount of time the SSF will wait for
an SCP response while in the Waiting for Instructions state. Each new CAP
message from an SCP stops the Tssf timer. The timer is started when the SSF
enters the Waiting for Instructions state. If a response is not received in the
amount of time specified by this attribute, the SSF will give up and use the
Default GPRS Handling field of the related mobile’s CAMEL Subscriber Info
(CSI) to determine the appropriate action to take.

Default value 3 s
Engineering rule
ssfChargingGuardTimer
a reply from an SCP once an applyChargingReportGPRS CAP message has
been sent and successfully received by the SCP. If a response if not received
in the amount of time specified by this attribute, the SSF will give up and used
the Default GPRS Handling field of the related mobile’s CAMEL Subscriber
Info (CSI) to determine the appropriate action to take.
This attribute also specifies the amount of time the SSF will wait for a reply
from an SCP indicating that one of the following SGSN initiated messages
has been received: applyChargingReportGPRS, eventReportGPRS,
entityReleasedGPRS and initialDPGPRS. If an acknowledgement is not
received from the SCP in the amount of time specified by this attribute for any
of the messages listed above, the message is sent again to the SCP. The SSF
will continue to retransmit the previous CAP message after each timeout until
the number of consecutive timeouts reaches the value specified by the
ssfChargingGuardRetryAttempts attribute. If the maximum number of
timeouts is reached, the SSF will give up and use the DefaultGprsHandling
field of the related mobile’s CAMEL Subscriber Info (CSI) to determine the
appropriate action to take.
Default value 3 s
Engineering rule
ssfChargingGuardRetryAttempts
Description This attribute specifies the maximum number of retry attempts
after the ssfChargingGuardTimer expires.
Range value 0 - 5
Default value 0

Engineering rule Per Spec, there are no retries.
ssfTcapStackRegistrationTimer
a registration response from the TCAP Stack after sending a registration
request. If the timer expires, the SSF sends another registration request. The
SSF continues to send registration requests whenever the timer expires until
registration is successful.
Default value 10 s
Engineering rule
ssfRoamerService
Description This attribute specifies if CAMEL roaming subscribers are
supported.
If ssfRoamerService is set to disabled and a CAMEL subscriber roams into an

area served by this SGSN, active PDP contexts are dropped and new contexts
cannot be created.
disabled-> disable roamer service, refusing roaming subscribers.
If ssfRoamerService is set to enabled and a CAMEL subscriber roams into an

area served by this SGSN, existing PDP Contexts are maintained and new
contexts are created when requested. enabled-> enable roamer service,
allowing roaming subscribers.
Recommended value
Engineering rule
ssfSupportedCamelPhase
Description This attribute specifies the highest phase of CAMEL supported
by the SGSN. If notSupported is specified, it indicates to all Ssf components
that CAMEL is not supported by the network.
Range value 3, not supported

Default value not supported
Recommended value If utilized 3; but recommended “not supported”
Engineering rule Enabling CAMEL has a major effect on capacity affect to

the SGSN. See Capacity Report for more details on capacity impact of
CAMEL. Ultimately, perform a capacity analysis for the customer to see the
direct impact to the customers network.
maxCamelDialogues
Description Specifies the maximum number of CAMEL dialogs that can be
active at any time. [Usc/* SSF]
Range value 1 – 150,000
Default value 35000
Recommended value MaxCamelDialogues = maxAttachedSubscribers *

Percentage of subscribers that have CAMEL. (SE recommendation = 20,000)
Note that if there are no CAMEL subscribers in the network, this attribute
should be set to zero.
Engineering rule Changing the size of this attribute controls the size of the
SsfCamelContext pool. Typically this attribute should be set using the
following formula above.
GTP Tunnel and Path Management

The component " Sgsn GprsSubscriberControl GtpProv" contains
provisionable attributes to define the GTP provisioning function of the SGSN.
This includes Tunnel Management and Path Management functionality.
n3CreateRequest
Description This attribute specifies the maximum number of attempts made
by the GTP to send the CREATE PDP CONTEXT REQUEST message to a
GGSN.
Range value 1 - 10
Default value 2
Recommended value 2; It is recommended that the total wait time (that is,
the product of n3CreateRequest and t3CreateResponse) is to be shorter
than the MS wait time between retries of ATTACH and RA-UPDATE
messages.
Engineering rule

t3CreateResponse
Description This attribute specifies the maximum wait time for a response of
a CREATE PDP CONTEXT REQUEST message.
Default value 2
the product of n3CreateRequest and t3CreateResponse) is to be shorter
than the MS wait time between retries of ATTACH and RA-UPDATE
messages.

from this SGSN to any GGSN.
n3DeleteRequest
by the GTP to send the DELETE PDP CONTEXT REQUEST message to the
GGSN.
Range value 1 - 10
Default value 2
the product of n3DeleteRequest and t3DeleteResponse) is to be shorter than
the MS wait time between retries of ATTACH and RA-UPDATE messages.
Engineering rule
t3DeleteResponse
a DELETE PDP CONTEXT REQUEST message from the GGSN.
Default value 5 s
Recommended value 5 s; It is recommended that the total wait time (that is,
the product of n3DeleteRequest and t3DeleteResponse) is to be shorter than
the MS wait time between retries of ATTACH and RA-UPDATE messages.


n3EchoRequest
by the GTP to send the ECHO REQUEST message to the GGSN.
Range value 1 -10
Default value 5
Recommended value 8
Engineering rule Due to the criticality of this procedure, more attempts are
recommended.
t3EchoResponse
a ECHO REQUEST message from the GGSN.
Default value 60 s
Recommended value 15; in order to quickly identify the GGSN recovery
Engineering Rule The timer must be provisioned to a value that is greater

n3SgsnContextRequest
Description This attribute specifies the number of times that this SGSN,
while acting as the new SGSN, sends the SGSN CONTEXT REQUEST
message while the MS is undergoing an Inter-SGSN Routing Area Update
(IRAU).
Range value 1 - 20
Default value 2
Recommended value 2
Engineering rule
t3SgsnContextResponse
Description This attributes specifies the time that this SGSN, while acting as
the new SGSN, waits for an SGSN CONTEXT RESPONSE message from the
SGSN which is acting as old SGSN while the MS is undergoing an Inter-
SGSN Routing Area Update (IRAU).

Default value 5 s

n3UpdateRequest
Description This attribute specifies the number of times that this SGSN,
while acting as the new SGSN, sends an UPDATE PDP CONTEXT
REQUEST message to the GGSN while the MS is undergoing an Inter-SGSN
Routing Area Update (IRAU).
Range value 1 - 20
Default value 2
Recommended value 2
Engineering rule
t3UpdateResponse
Description This attributes specifies the time that this SGSN, while acting as
the new SGSN, waits for an UPDATE PDP CONTEXT REPONSE message
from the GGSN while the MS is undergoing an Inter-SGSN Routing Area
Update (IRAU).
Default value 4 s

echoRequest
Description This attribute specifies whether the ECHO REQUEST message
is to be sent out for signaling path to the GGSN node.
Range value disable, enable
Recommended value enable

Engineering rule Per PC03 GPS Bulletin, this parameter should be enabled
for better link failure recovery.
echoTimeInterval
Description This attribute specifies the time interval at which ECHO
REQUESTS are sent on a signaling path in use from the SGSN to the GGSN.
Range value 1 – 300 mn
Default value 2 mn
Recommended value (n3EchoRequest * t3EchoResponse) + 2 minutes
Engineering rule Per GPS, the echoTimeInterval should be set to a value 1

minute greater than the complete time allocated for echo requests =
(n3EchoRequest * t3EchoResponse) + 2 minutes.
maxGtpPaths
Description This attribute specifies the maximum number of managed paths
that can be setup between this SGSN and the GGSNs. Each path contains one
or more tunnels which may be used by, for example, PDP Contexts. It is
possible to have more paths than specified by the maxGtpPaths, but those
exceeded are not managed paths (for example, cannot do echo). The peak
number of transactions can be obtained from the attribute peakGgsnPaths
(defined in Gsc GtpMgmt).
Range value 1 - 65535
Default value 10
Recommended value At a minimum set to 1000 or “equation + 500”. See

additional comments below.
Engineering rule The formula below should be utilized to set this parameter
but at a minimum this value should be set to 1000. The purpose of this
parameter is to best estimate the max number of GTP paths that may be
established on this SGSN. The additional padding in the formula below is to
account for the possible SGSN/GGSNs that may not have been accounted for
in the formula. At a minimum, 500 should be used for padding. If your
customer is expecting large future build out, increasing the padding factor
will ensure enough paths are allocated for network growth.
maxGtpPaths = number of GTP paths + 500 (for padding)
number of GTP paths = ((#Home GGSN's + #Roamer GGSN's) * (#IP

Addresses per GGSN)) + ((#3G SGSN's -1) * (1 or #USC's for Nortel 3G

SGSN)) in the same PLMN + ((2G SGSN's) * (1 or #GSC's for Nortel 2G

SGSN))
Where (#IP Addresses per GGSN) = 2
If the setting is too low, then when the number of established GGSN paths
reaches the value provisioned for sgsn gsc maxGtpPaths PDP context
activation to any new GGSNs fails. You want the maxGtpPaths to a high
enough value to account for all of the customers GGSNs, SGSN USC IRAU
paths, and all roaming partners GGSNs/SGSNs.
Important: If the customer is planning on expanding their network in the

near future (adding USC cards, GGSNs, or additional roaming agreements),
then add additional “padding” to the value to account for the near-future
expansion.
This parameter must be increased with the expansion of GSC, GGSNs, or

roaming agreements.
Monitoring: The usage of this parameter should be monitored to ensure the

peak provisioned limit is not nearing. The following stats can be added to
your customer’s monitoring activity
Operational statistics to monitor for maxGtpPath:
• peakGtpPaths: indicates the peak number of managed paths that have

been set up between this UMTS Serving GPRS Support Node (USGSN)
and the GPRS Support Nodes (GSNs)
• currentGtpPaths: attribute indicates the number of managed paths
currently maintained that have been setup between this UMTS Serving
GPRS Support Node (USGSN) and the GPRS Support Nodes (GSNs))
Alarms: The usage of this parameter also is flagged by an alarm as the
threshold of GTP paths approaches 90%. [7068_1538 - GTP Path High Usage
Alarm (GPRS/UMTS)]. The alarm is cleared once the number of GTP paths
falls belows 80%
maxTransactions (GtpM)
Description This attribute specifies the maximum number of outstanding
GPRS Tunneling Protocol (GTP) messages that can be simultaneously
waiting for responses or acknowledgments from the peer GPRS Support
Nodes (GSNs). The peak number of transactions can be obtained from the
attribute peakTransactions.
Range value 10..65535
Default value 100

Engineering rule maxTransaction memory allocation = Gtpmsg pool size X

maxTransaction parameter increase.
There is a memory impact as a result of provisioning maxTransactions. The

greater the value the larger amount of memory is utilized.
maxTransactions (Mc)
Description This attribute specifies the concurrent transactions the MAP
Client can process at any given time.The card running this GPRS Subscriber
Control (GSC) application is reset to accommodate an increase in the attribute
value. An increase in the attribute value is accepted without application reset,
providing it passes check prov..
Range value 1…4500
Default value 1024
Engineering rule
maxIncomingRequests
incoming GTP requests that can be handled. Changing the value changes the
amount of memory allocated for these requests.
Range value Decimal (10-1000)
Default value 1000
Engineering rule
ggsnGraceTimer
Description (PC04: Q00845825) This attribute specifies the time interval
between a path failure detection and the path failure declaration for a path to a
Gateway GPRS Support Node (GGSN). During this period the Serving
GPRS Support Node (SGSN) attempts to recovery the path. When
the value is set to disabled the GGSN grace timer will never run
Range value 0 (disabled), 1-300 minutes

Default value 5
Recommended value 5
Engineering Rule In summary this states how long should we wait before
declaring link dead; time of recovery.
sgsnGraceTimer
between a path failure detection and the path failure declaration for a path to a
Serving GPRS Support Node (SGSN). During this period the SGSN attempts
to recovery the path. When the value is set to disabled the SGSN grace timer
will never run
Default value 5
Recommended value 5
Engineering Rule In summary this states how long should we wait before
declaring link dead; time of recovery.
pathRediscoveryTimer
which path rediscovery is attempted. Path rediscovery consists of sending a
version 1 Echo Request on a version 0 path. If a version 1 Echo Response is
received the path version is upgraded to version 1. When the value is set to
disabled the rediscovery procedure will never run.
Default value 5
Recommended value 5
Engineering rule
pathInactivityTimer
Description (PC04: Q00845825) This attribute specifies the timer interval
for which an inactive path resource is released. A path to a Gateway GPRS
Support Node (GGSN) is inactive when there are no PDP contexts active on
this path during the time interval. A path to a Serving GPRS Support Node
(SGSN) is inactive when there is no messaging on this path during the time
interval. When the value is set to disabled the path inactivity timer will never
run.

Default value 10
Engineering rule The past PC03 parameter, pathHistoryExpireTimeInterval,

had a recommendation from GPS to be set to 1, in order to recover the failed
path. In PC04 this is done independent of the inactivity timer; the inactivity
timer is only used to recover resources that are not utilized.
Short Message Service

cpResponseTimer (TC1N)
Description This attribute specifies the amount of time the Short Message
Service (SMS) allows for a CP-ACK or CP-ERROR response from the MS
when a CP-DATA message is sent to the MS. This timer is used in mobile
originated and mobile terminated transactions. When this timer expiries, the
SMS re-sends the CP-DATA message up to the maximum number of
cpResponseRetries. Once the maximum number of cpResponseRetries is
reached, the outstanding transaction is aborted. The count of the
cpResponseTimer expiries due to the maximum number of
cpResponseRetries can be viewed in cpResponseExhaust attribute (defined
in Gsc ShortMessageService).
Default value 20 s
Recommended value The value of the attribute rpResponseTimer cannot

be less than the sum of the maximum number of cpResponseRetries
multiplied by the cpResponseTimer value plus the maximum number of
pagingRetries (n3313) multiplied by the pagingTimer (t3313) value
Engineering Rule The timer must be provisioned to a value that is greater

but less than the rpResponseTimer.
cpResponseRetries (TC1NRet)
Description This attribute specifies the number of times the Short Message
Service (SMS) sends the CP-DATA message to the MS when a CP-ACK or
CP-ERROR message is not received.
Range value 1, 2 or 3
Default value 3
Recommended value

Engineering Rule The value of the attribute rpResponseTimer cannot be

less than the sum of the maximum number of cpResponseRetries multiplied
by the cpResponseTimer value plus the maximum number of pagingRetries
(n3313) multiplied by the pagingTimer (t3313) value.
rpResponseTimer (TR1N)
Service (SMS) allows for a RP-ACK or RP-ERROR response from the MS
when a CP-DATA message is sent to the MS in a Mobile Terminated (MT)
transaction. When this timer expiries, the MT transaction is aborted. The
value of this attribute cannot be less than the sum of the maximum number of
cpResponseRetries(tc1nRet) multiplied by the cpResponseTimer(tc1n) value
plus the maximum number of pagingRetries (n3313) multiplied by the
pagingTimer (t3313).
Default value 79 s
Recommended value
Engineering rule
iwmscResponseTimer (TR2N)
Service (SMS) allows for:
• a MO FORWARD SHORT MESSAGE ACK response from the Service

Center when a MO-FORWARD SHORT MESAGE message is sent to the
MS in a MO transaction. When this timer expires, the MO transaction is
aborted.
• a READY FOR SM ACK response when a READY FOR SM MEMORY
AVAILABLE message is sent.
Default value 33 s

Packet flow management

New in PC04: (A00000537)The BSS and the SGSN negotiate the PFC feature
bit during the BVC Reset procedure as per the GPRS Release 99 Standards. If
both the BSS and the SGSN support the PFC feature then the SGSN can

initiate the Packet Flow Context negotiation for an MS. This is primarily done
to negotiate the Aggregate BSS QoS Profile parameter.
Figure C-4
BSS QoS addressing architecture
MS LLC SAPI
TLLI ABQP Shared by
PDP BSS and
Context 1 SGSN
PDP
Context 2 NSAPI=15, SAPI=3 PFI=21
PFC 1
NSAPI=14, SAPI=3 PFI=21
PDP
Context 3
NSAPI=13, SAPI=5 PFI=16 PFC 2
GMM/SM Signaling, SAPI=1 PFI=1

PFC -
SMS, SAPI=7 PFI=2 Signaling
SMS
PFC -
SMS
This feature has a memory impact (about 5MB) on the Gprs Subscriber
Control (GSC) card; based on NSCM, there is about a 2% gain in modeled
memory utilization. For the impact of enabling this feature, use the Capacity
tool to see the memory impact for the particular customer model.
If the provisioned value of maximum subscribers is X and maximum sessions

is Y then the memory impact for the PFM feature would be as follows:
GscContextManager: X subs * 4 bytes (pointer)

PfmAgent/mobile: X subs * 24 bytes
PFC/session: Y sessions * 28 bytes
Following is an example:
maximum subscribers = 85k

average Active Sessions Per Subscriber = 1.1 =>maximum sessions = 93.5k
The memory impact for this feature is:
GscContextManager: 85k subs * 4 bytes (pointer) = 340,000

PfmAgent/mobile: 85k * 16 bytes = 1,360,000
PFC/session: 93500 sessions * 40 bytes = 3,740,000
Total:5.44MB

Gsc/x Pfm component contains the provisionable attributes detailed below.
T7Timer
Description This attribute specifies the timer value to guard the CREATE-
BSS-PFC procedures. The Serving GPRS Support Node (SGSN) sends a
CREATE-BSS-PFC Protocol Data Unit (PDU) to the Packet Control Unit
(PCU) and starts the t7Timer for a BSS GPRS Virtual Connection (BVC).
The SGSN stops the timer upon reception of a CREATE-BSS-PFC-ACK
PDU from the PCU. If the timer expires, the SGSN retries this procedure.
Range value 0.1 – 10 sec
Default value 5 s
Recommended value 5
Engineering Rule the T7Timer * T7Retries is not more than the total
activation timer.
T7Retries (nT7)
Description This attribute specifies the maximum number of times the
Serving GPRS Support Node (SGSN) can send the BVC-RESET Protocol
Data Unit (PDU) in case a BVC-RESET-ACK is not received before the
bvcResetTimer expiry.
Range value 0 – 6
Default value 3
Engineering Rule The T7Timer * T7Retries is not more than the total
activation timer.
PacketFlowTimer (t9)
Description This attribute specifies the maximum time the BSS can hold the
Packet Flow Context (PFC) during periods of inactivity for a PFC. The
packetFlowTimer attribute is provided to the Base Station System (BSS) by
the Serving GPRS Support Node (SGSN).
The timer is started on receipt of a CREATE-BSS-PFC Protocol Data Unit

(PDU) and restarted after the transmission of an uplink PDU. The timer is
also started upon the transfer of the corresponding PFC from an old to a new
cell.

The standards recommend the range of the packetFlowTimer attribute to be

the same as the range of the readyTimer attribute (defined in Sgsn Gmm
component). The value of the packetFlowTimer attribute must not exceed the
value of the readyTimer attribute unless the value of the readyTimer attribute
is less than 6 seconds.
The value of the packetFlowTimer attribute is rounded off to the next

encodable value as described in the GSM 8.18 specification. The following
are the timer value ranges and the corresponding roundoff encoded values
Timer range 0 - 62 is rounded to 2 seconds,
Timer range 63 - 1860 is rounded to 1 minute,
Timer range 1861 - 5760 is rounded to 6 minutes,
Timer range 5761 - 11160 is rounded to 1 minute.
Range value (same as ReadyTimer) 6..11160, disabled = 0
Default value 6
Recommended value 40 (must not exceed readyTimer)
Engineering rule
HLR Cache
The component "Sgsn Gsc/n HlrCache " represents the provisioning data for
the HLR Cache functionality of the GSC.
authTripletsReuse
Description this attribute specifies the number of times an Authentication
vector (quintuplet) can be reused when authenticating a subscriber. The reuse
of the Authentication vector is done only in abnormal situations when the new
vectors cannot be received from the HLR due to connectivity breakdown
between the SGSN and the HLR.
Default value 5000
Engineering rule

umtsAuthVectorAllocation
Description (PC04) This attribute specifies the percentage of Quintet
authentication vectors allocated in HlrCache to support UMTS authentication
procedures on this GPRS Subscriber Control (GSC) card. The remaining
percentage is allocated as Triplet authentication vectors in HlrCache to
support GSM authentication. This feature is a prep feature to support a
subsequent GPRS Authentication Quintets Support feature and alone will not
cause any change in the SGSN handling of Authentication Quintets received
during IRAU or authentication of UMTS subscribers.
The total number of authentication vectors allocated in HlrCache remains

unchanged.
Changing the value of this attribute causes the card to be reset and all
outstanding transactions will be affected
Range value DECIMAL(0.. 100)
Default value 0
Recommended value 0
Engineering Rule Dependent on the amount of interaction with 3G UMTS

subscribers.
Location services (Q01068044)

LCS (location services) is a dormant/prep feature in PC04. It requires patches
to be activated.
The new components introduced by this feature are the following:
GSC/n LCS (optional component: DO NOT PROVISION THIS

COMPONENT)
GPRS Subscriber Datapath (GSD) provisionable attributes

New In PC04
Per RFC 2507 IP Header Compression feature, provisioning attribute

maxRfc1144Entities is renamed to maxHeaderCompressionEntities. Its
provisioning value is migrated to the provisioning attributes
maxHeaderCompressionEntities and allowableCompressionAlgorithms as
following:
If the value of maxRfc1144Entities is 0 then the value of attribute

maxHeaderCompressionEntities is 0 and the list
allowableCompressionAlgorithms is empty.

If the value of maxRfc1144Entities is not 0 then the value of attribute

maxHeaderCompressionEntities is the provisioned value of
maxRfc1144Entities and the list allowableCompressionAlgorithms has the
value of rfc1144.
Figure C-5
GSD provisionable attributes
(Root)
SGSN
GSD/n V42bisCompression direction
Max RFC 1144 entities
Max V42bis entities
GSD SNDCP
Ciphering hardware assist
LLC Link to port {IP, UDP}

Gtp
Rfc 1144 slots
V42bis dictionary
V42bis max string size
SNDCP snP du timer MaxMswithBuff
Downlink MaxPacketsBuffperMs
maxBytesBuffperMs
Buffer
T200 n200 pduLifetimeInBuff
n201U buffCheckInterval
SAPI C NumBlocks
msflowcontrol timer
BuffOnFcBucketFull
BuffOnLlcSuspended
T200 n200
SAPI D n201U n201I
kD kU
SAPI SMS T200 n200

n201U
msflowcontrol timer
IMPORTANT NOTE: Below there are compression parameter

recommendations. The recommended values for the compression parameters
are based upon if a customer is utilizing compression. Compression by
default is not turned on and as an overall recommendation, compression
should be turned off because of the memory and capacity hit the SGSN takes
with the enabling of compression
GSD attributes
The following attributes are the provisionable attributes for the GSD/y
component
sessionsToMobileRatio
Description (PC04: A00004113)This attribute specifies on an average the
ratio of sessions that a mobile can support. This ratio is used to allocate the
session entity pool for all the sessions on a GSD card. This shall not limit a
mobile entity from having multiple sessions. For example, a value of 2
specifies that on an average, it is expected that mobiles can use two PDP
sessions, and memory is allocated accordingly. Mobiles are not prevented
from using more than two PDP sessions, but if many mobiles do this, then it is

possible that there will be no available memory for other mobiles to activate
PDP sessions.
Range value 1.0 – 3.0 (DecimaL)
Default value 1
Recommended value Dependent on customer call model.
Engineering Rule This ratio is used to allocate the session entity pool for all
the sessions on a GSD card.
The higher the value the more memory is allocated per mobile. If the
customer is already GSD limited, then increasing this parameter may
negatively impact the system
GSD LLC attributes

The following attributes are the provisionable attributes for the GSD/y llc
component
lleToMobileRatio
Description (PC04:A0004113)This attribute specifies on an average the ratio
of the DATA Logical Link Entity (LLE) and Short Message Service (SMS)
LLE that a mobile can support. This ratio is used to allocate the LLE entity
pool for all the DATA and SMS LLEs on a GSD card. This shall not limit a
mobile entity from having multiple DATA or SMS LLEs. DATA LLEs are
Service Access Point Identifiers (SAPI) 3, 5, 9 and 11. SMS LLE is SAPI 7.
For example, a value of 2 specifies that on an average, it is expected that all

the mobiles attached use one SMS LLE and one DATA LLE, and memory is
allocated accordingly. Mobiles are not prevented from using more than one
SMS LLE and more than one DATA LLEs but if many mobiles do this, then it
is possible that there will be no available memory for other mobiles to get
DATA LLEs or SMS LLE.
Default value 1.5
Recommended value Dependent on customer call model.
Engineering Rule This ratio is used to allocate the LLE entity pool for all
the DATA and SMS LLEs on a GSD card. This shall not limit a mobile entity
from having multiple DATA or SMS LLEs. DATA LLEs are Service Access
Point Identifiers (SAPI) 3, 5, 9 and 11. SMS LLE is SAPI 7.

negatively impact the system
abmModeLleToMobileRatio
Description (PC04:A0004113)This attribute specifies on an average the ratio
of Logical Link Entities (LLEs) per mobile that can be in Asynchronous
Balanced Mode (ABM). This ratio is used to allocate the LLE ABM data
entity pool for all the DATA LLEs on a GSD card. This shall not limit a
mobile entity from having multiple LLEs in the ABM mode. DATA LLEs are
Service Access Point Identifiers (SAPI) 3, 5, 9 and 11.
For example, a value of 2 specifies that on an average, it is expected that all

the attached mobiles use two DATA LLE in the ABM Mode, and memory is
allocated accordingly. Mobiles are not prevented from using more than two
DATA LLEs, but if many mobiles do this, then it is possible that there will be
no available memory for other mobiles to use DATA LLEs in the ABM mode.
Default value 1.5
Recommended value Dependent on customer call model. The higher the

value the more memory is allocated per mobile. If the customer is already
GSD limited, then increasing this parameter may negatively impact the
system
Engineering Rule The size of this LLE pool should not be greater than the
lleToMobileRatio.
negatively impact the system.
cipheringHardwareAssist
Description This parameter determines if the LLC packet ciphering and de-
ciphering functions are performed in software (disable) or hardware
(autoConfigure). This parameter should not impact the functional operations
with the MS.
Range value autoConfigure, disable
Default value autoConfigure
Recommended value autoConfigure. If set to disabled and if ciphering is

active then the CPU impact incurred on the GSD cards by having to perform
ciphering/de-ciphering in software will be significant

Engineering rule
Capacity attributes
maxLlcActiveSubscribers
Description This attribute specifies the maximum number of Mobile
Stations (MS) that can be attached for this instance of Gsd. This gives the
number of mobile subscribers that the LogicalLinkControl (Llc) and the
SubNetworkDataConvergenceProtocol (Sndcp) is to support per Gsd. The
current attached subscribers can be obtained from the attribute
currentLlcActiveSubscribers. Currently attached subscribers are unaffected
by changes to this value. Changing the value of this parameter requires a reset
of the card that has a Gsd.
Range value 1…50000
Default value 100
Recommended value
• 40000 (No Compression, No Ciphering)

• 15000 (with Compression, No Ciphering)
• Allocation of these resources directly impacts the amount of memory that
is left to support other functions on the GSD card
Engineering Rule Gives the maximum number of simultaneous subscribers

that can be attached per GSD. The number of subscribers supported by a
GSD must be carefully engineered. If the actual number of subscribers is
more than this value, GSD rejects new attaches and accordingly, the system
shows significant number of call failures (packetnetworkfailure counter
shows the failed calls). SGSN memory resources defined by this parameter
are directly used to support mobile procedures in the GSD card. If this
parameter is not set high enough for the given network the result could be that
the mobiles are unable to attach onto the SGSN.
• Decreasing this parameter to less than 40000 leads to lesser number of

simultaneous subscribers attached to GSD.
• Increasing this parameter to more than 40000 could lead to memory
issues.
v42bisCompressionDirection (p0) – removed in PC04
Description This attribute specifies the V.42bis data compression direction
to be supported. The value for compression direction is negotiated at link
setup by the data link protocol by way of the EXCHANGE IDENTIFICATION
(XID) negotiation of parameter P0 (compression direction). During XID
negotiation of parameter P0, both sides (the SGSN to the MS or the MS to the
SGSN) agree on the compression direction. Valid values are:

• none, No compression is present.

• fromMs, The data received from the other entity is compressed.
• toMs, The data sent to the other entity is compressed.
• both, The data sent and received by the SGSN is compressed.
Range value None, fromMS, toms, both
Default value both
Recommended value both
Engineering rule
• The setting of this value determines how the negotiation of compression

parameter P0 (compression direction) is performed between the MS and
the SGSN. Setting this parameter incorrectly will result in non-desired
compression behavior between the MS and SGSN.
• Determines how the compression parameter P0 is negotiated with the MS
maxHeaderCompressionEntities (formally maxRfc1144Entities)

Description This attribute indicates the total number of RFC1144 and RFC
2507 header compression entities for this GSD instance. The provisioning
value from maxRfc1144Entities is migrated to this parameter.
The current RFC 1144 entities can be obtained from the attribute
currentRfc1144Entities, and the current RFC 2507 entities can be obtained
from the attribute currentRfc2507Entities respectively.
SGSN memory resources defined by this parameter are directly used to

support RFC 1144 header compression to and from the mobile (MS). Inability
to obtain these resources for a given MS will result in RFC 1144 header
compression not being able to be performed to the mobile
Range value decimal (0…65535)
Default value 0
Recommended value 0 – no header compression. In the event that

compression is used - 15000
• 15000 (Provision based on the call model. With Header compression, the
memory capacity (and the total # subscribers supported by the GSD)
drops.). If customer wants 100% compression then maxLlc and
compressionEntities is recommended to be 15,000.
Engineering rule

• Dependent on the how much compression ; if customer is already memory

limited, then this would negatively affect the system because more
mobiles performing compression affects the memory resources on the
GSD
• Basically this parameter states how many mobiles of your system will you
support utilizing compression
is left to support other functions on the GSD card. Provisioning of
memory resources on the GSD card is a trade-off between supporting
specific numbers of mobiles with various levels of functionality
allowableCompressionAlgorithms
Description (PC04: 60012127) This attribute indicates which header
compression algorithms can be performed on this GSD instance. The
provisioning value from maxRfc1144Entities is migrated to this parameter as
well.
If the list allowableCompressionAlgorithms is empty, neither RFC 1144 nor

RFC 2507 are performed.
If the value of allowableCompressionAlgorithms includes rfc1144, RFC 1144

may be performed.
If the value of allowableCompressionAlgorithms includes rfc2507, RFC 2507

may be performed.
Range value LIST: rfc1144, rfc2507
Default value <empty list>
Recommended value
Engineering rule
maxV42bisEntities
Description This attribute specifies the maximum number of V.42bis
compression entities for this instance of GprsSubscriberDataPath (Gsd). If the
value is 0, V.42bis compression is not performed. The current V.42bis entities
can be obtained from the attribute currentV42bisEntities.
SGSN memory resources defined by this parameter are directly used to

support V42Bis data compression to and from the mobile (MS). Inability to
obtain these resources for a given MS will result in V42Bis data compression
not being able to be performed to the mobile
Range value decimal (0…65535)

Default value 0
• (Provision based on the call model. With Header compression, the

memory capacity (and the total # subscribers supported by the GSD)
drops.) (Ref: Capacity Report)
Engineering rule
• Compression ratio; based on how much compression is being performed

(based on customer and RF)
• Basically this parameter states how many mobiles off your system will
you support utilizing compression.
is left to support other functions on the GSD card. Provisioning of
memory resources on the GSD card is a trade-off between supporting
specific numbers of mobiles with various levels of functionality
rfc2507MaxPeriod
Description (PC04:60012127)This attribute indicates the largest number of
compressed non-TCP headers that may be sent without sending a full header.
This attribute is used as an upper limit, on the number of non-TCP packets

with compressed headers that may be sent between header refreshes, to avoid
losing too many packets if a receiver has lost its context.
Range value decimal (1 – 65535)
Default value 256
Engineering rule
rfc2507MaxTime
Description (PC04:60012127) This attribute indicates that a full header
must be sent when rfc2507MaxTime seconds have passed since the last full
header was sent for this packet stream.
This attribute is used as an upper bound, on the time between full headers in a
non-TCP packet stream, to avoid long periods of disconnection for low data
rate packet streams.
Range value decimal (1 - 255

Default value 5
Engineering rule
alternateLlcXidNegotiation
Description This attribute specifies if the Serving GPRS Support Node
(SGSN) is to follow an alternate and noncompliant to 3GPP Logical Link
Control (LLC) standards behavior with respect to the handling of LLC
parameters during eXchange IDentification (XID) with the Mobile Station
(MS). This alternate behavior allows MSs that are not compliant to the LLC
specifications (3GPP TS 44.064) to process data packets after a Packet Data
Protocol (PDP) context activation.
This affects the SGSN's handling of the following LLC parameters.-

information frame buffer size in the uplink direction (mU),- information
frame buffer size in downlink direction (mD),- maximum information field
length for unnumbered and unconfirmed information frames (N201-U), and-
maximum information field length for information frames (N201-I).Note that
SGSN only supports the value of 0 for mU and mD, meaning that the SGSN
does not keep count of outstanding I frame octets in the uplink or downlink
directions. Setting attribute alternateLlcXidNegotiation to enabled does not
change SGSN support of mU or mD, and enables SGSN behavior that is not
compliant to the 3GPP LLC standards.
If set to enabled, the SGSN does the following:
1. In the SGSN initiated XID request to MS, the SGSN includes the default
mU and mD. The SGSN ignores the mU and mD values received in the XID
response from the MS and proceeds with the only SGSN supported values of
0.
2. For an MS initiated XID request, the SGSN includes the received mU and
mD in the XID response. If no mU or mD was included in the XID request
from MS then the SGSN includes the default mU and mD in the XID
response. Regardless, the SGSN proceeds with its only supported mU and
mD values of 0.
3. For an MS initiated XID request, the SGSN does not include N201-I and
N201-U in the XID response if the MS requested N201-U and N201-I are
accepted. If the MS does not include N201-U and N201-I in the XID request,
the SGSN sends either the provisioned or current values of N201-U and
N201-I.
If set to disabled, the SGSN handles the XID procedure according to 3GPP
standards.

Engineering rule This parameter is only needed to address non-spec

compliant mobiles; and should not be set unless there is a specific request
from the customer to address this non-compliant functionality.
generateLlcXidForNonDefaults
Description This attribute specifies how the Serving GPRS Support Node
(SGSN) handles eXchangeIDentification (XID) when provisioned with XID
parameters that differ from the LLC specifications (3GPP TS 44.064) defined
defaults. The following XID parameters are provisioned on the SGSN.-
maximum information field length for unnumbered and unconfirmed
information frames (N201-U) (the n201MaxUInfoFieldLength attribute in
Sgsn Gsd SapiData/n, Sgsn Gsd SapiControl, and Sgsn Gsd SapiSms) and-
maximum information field length for information frames (N201-I) (the Sgsn
Gsd SapiData/n n201MaxIinfoFieldLength attribute) .
The attribute generateLlcXidForNonDefaults specifies whether the SGSN

should negotiate with the Mobile Station (MS) for those XID parameters
which are provisioned with non-default LLC specification values. If
generateLlcXidForNonDefaults is set to enabled and if any of the previously
mentioned XID parameters in the SGSN are provisioned with non default
values, then the SGSN will initiate an XID request to the MS.
If generateLlcXidForNonDefaults is set to disabled, then even if any of the

previously mentioned XID parameters in the SGSN are provisioned with non
default values, the SGSN will not initiate an XID request to the MS.By
default generateLlcXidForNonDefaults is set to disabled, which ensures that
the SGSN will not initiate an XID request to the MS because the provisioned
XID parameters on the SGSN differ from the LLC specification (3GPP TS
44.064) defined defaults. The SGSN may initiate an XID request for other
reasons.
If the SGSN is engineered such that the provisioned XID parameters do not
allow support for the LLC specification (3GPP TS 44.064) defined default
values, then Nortel recommends that attribute
generateLlcXidForNonDefaults be set to enabled.

Engineering rule
xidDuringIrauAdmMode
Description This attribute specifies whether the Serving GPRS Support Node
(SGSN) will send an Exchange Identification (XID) command to the Mobile
Station (MS) during an Inter SGSN Routing Area Update (IRAU) procedure
on the New SGSN, when the MS is in Logical Link Control (LLC)
Asynchronous Disconnected Mode (ADM) mode. SubNetwork Data
Convergence Protocol (SNDCP) parameters, mainly those related to data
compression, are negotiated at this time. This XID command is in addition to
the XID reset command always sent by LLC.If the mobile is in LLC
Asynchronous Balanced Mode (ABM) and does an IRAU, an Establish
procedure is done instead of an XID and is not affected by this attribute.If set
to enabled, the SGSN sends the XID command to the MS during IRAU in
ADM mode. The SGSN may propose compression algorithms as specified
by the compressionAlgorithmsProposed attribute. This is the recommended
value.If set to disabled, the SGSN does not send the XID command to the MS
during IRAU in ADM mode. Because no XID command is sent, XID
parameters will remain at their default values. The default value for SNDCP
version is 0, and the default value for compression is no compression.
Subsequent data transfers involving the MS will not be compressed if the
mobile does not initiate an XID request with acceptable compression entities
proposed. The operator may choose this setting to accommodate
interoperability issues with non-compliant behavior in other mobiles or
nodes. This has been added in place of two patch solutions that either
accepted invalid XID responses from the mobile or delayed the XID request.
Engineering rule
SNDCP attribute
The component "Sgsn Gsd/n SndcpProv" represents the provisioning data for
the SNDCP of the SGSN.
snPduTimer
Description (PC04:A00003795) This attribute specifies the timing when a
complete Network Protocol Data Unit (N-PDU) is received by the
SubNetwork Dependent Convergence Protocol (SNDCP). This attribute is
used in N-PDU reassembly from SN-UNITDATA PDUs. It specifies the
maximum time SNDCP waits for additional SN-UNITDATA PDUs for a
given N-PDU. If this timer expires the partially reassembled N-PDU is
discarded. This timer is restarted when each segment of the original N-PDU is

received. This timer is only applicable to unacknowledged Logical Link

Control (LLC) mode.
Default value 60 s
Recommended value (for most of the networks, user plane RTD between
SGSN to MS is less than this value for most of the packets). Do not go below
the max default value for the SAPI t200/t201 timer value.
Engineering rule This timer is only applicable to unacknowledged (LLC)

mode.
• Impact on the Performance

— Decreasing this parameter to less than recommended value leads to
higher percentage of packets being discarded. And thereby, decreases
the throughput.
— Increasing this parameter to more than recommended value leads to
unnecessary buffering of a segment of the lost packet.
• Impact on the Capacity
— Increasing this parameter to more than recommended value may use
additional memory, but does not significantly impact.
rfc1144Slots
Description This parameter defines the number of “state slots” RFC-1144
TCP/IP header compression algorithm. If this value is negotiated to be too
small < 8 or does not match up between the MS and the SGSN the result
could be that the header compression algorithm will not perform as
effectively as it possibly could. This parameter is negotiated between MS and
GSD.
Range value 1 – 256
Default value 16
Recommended value 8: allowable range is 8 – 16; but no lower than 8.
Engineering rule
• If this value is < 8, then the compression algorithm does not perform
efficiently.

• Compression increases the RF efficiency, but reduces the GSD capacity.

Impact on the Performance
• The value of this parameter must be greater than the number of
simultaneous TCP connections by MS. If the MS has larger number of
simultaneous TCP connections than this value, then the effectiveness of
the compression algorithm potentially decreases. As per RFC 1144, if
this value is set to less than 8, a significant degradation in the
effectiveness of the compression scheme has been observed (again, this
degradation depends on the number of simultaneous TCP connections
from the MS). As per RFC 1144, the number of simultaneous TCP
connections more than 16 is extremely unlikely. Therefore, SE
recommends this value to be provisioned 8-16.
Impact on the Capacity
• As this value is increased, the memory requirement increases and the
effective number of simultaneous subscribers supported by a GSD is
decreased. (Please see the Capacity Tool.)
v42bisDictionary
Description This parameter (P1) defines the maximum number of V.42bis
code words. Negotiation of this parameter between the MS and SGSN can
impact the overall performance of the data compression encoding algorithm.
Noting that a larger number of code words does not automatically mean an
improvement in compression performance as it is ultimately data set related.
As the maximum number of code words supported on the SGSN increases

then so does the memory resource requirements.
Range value 512, 1024, 2048 and 4096
Default value 512
Engineering rule
Impact on the Performance

• In general, increasing the dictionary size increases the compression ratio.
But, the actual ratio of the compression depends on the characteristics of
the input data. Sometimes, the larger dictionary size decreases the
compression ratio. This is due to the increase in the size of the Codeword
as the Dictionary size increases.
• In general, increase in the compression ratio, increases the End to End
Throughput. The amount of increase in the Throughput depends on the
available RF bandwidth and End2End delay between the MS and Server.

As RF bandwidth increases, the impact of compression decreases, As the

End2End delay increases, the impact of compression decreases.
Impact on the Capacity
• Increasing this parameter > 512 impacts the memory Capacity and hence,
overall Subscriber capacity (see the Capacity Tool).
v42bisMaxStringSize
Description This parameter (P2) defines the maximum number of characters
allowed in a string represented by a codeword that the SGSN supports.
Negotiation of this parameter between the MS and SGSN can impact the
overall performance of the V.42bis data compression algorithm.
Range value 512, 1024, 2048 and 4096
Default value 6…250
Engineering rule
• If the customer is already memory limited, then increasing this parameter

can have a negative impact on the SGSN because increasing the value
increases memory usage.
compressionAlgorithmsInIrau
Description This attribute specifies the compression algorithms that are
proposed by this instance of Gsd during Inter Serving GPRS Support Node
(SGSN) Routing Area Update (IRAU). If a compression algorithm is
specified, then the SGSN will propose a compression entity of that type as
part of Exchange Identification (XID) negotiation during IRAU if the
following conditions are met:1) The compression algorithm is supported by
the SGSN. 2) There are available compression entities for that
algorithm.Support of the RFC 1144 and RFC 2507 algorithms is specified in
the allowableCompressionAlgorithms attribute. Support of the V.42bis
algorithm is specified by a non-zero value for the maxV42bisEntities
attribute. This allows an operator to accommodate Mobile Stations (MS) that
don't properly handle the SGSN's proposal of RFC 2507 compression entities.
Removing an algorithm from this attribute will impact an MS that is using
that compression algorithm prior to undergoing IRAU with this SGSN. The
MS will no longer have that compression after IRAU, which can result
decreased data throughput..
Range value rfc1144, rfc2507,v42bis
Default value (rfc1144, rfc2507, v42bis)

Engineering rule
SAPI Control attribute (SAP-1)

The component "Sgsn Gsd/n SapiCProv" represents the provisioning data for
the Service Access Point 1 (SAP-1) of the Logical Link Control (LLC)
protocol layer.
t200RetransmitTimer (t200)
Description This attribute specifies the time within which an
acknowledgment of an Exchange Information (XID) frame must be received
by the Service Access Point 1 (SAP-1) LLC entity. During the XID
negotiation, both the Logical Link Control (LLC) entities (the Mobile Station
and the SGSN) can agree to use a specific value for this timer. The SGSN
attempts to negotiate to the value specified by this attribute. Changes to this
attribute do not trigger re-negotiation of this parameter with the Mobile
Station.
The value of timer T200 represents the time for which the SGSN will wait
before re-transmitting an LLC XID message prior to receiving a XID
response from the MS. In the case of SAPI 1 the XID messages in question
would specifically be for the IOV and Reset parameters. In either case the
worst case scenario for an erroneous T200 setting would be to cause XID
messages to be re-transmitted. In the very worst case XID failures on SAPI 1
could lead to both Attach and IRAU procedure failures
Range value 0.1 – 409.5 sec
Default value 5 s
• t200retransmitTimer refer to frame XID (exchange identification), XID

message is < 512 Bytes. Default value is 5 sec. The recommended value
should be 2 times Round Trip Delay. RTD is 1.5 sec in the worst case. As
recommended value, 3 seconds is enough. The operator has the option to
lower the initial value used on the SGSN in order to optimize network
performance.
• The readyTimer value provisioned in the Sgsn GprsSubscriberControl
component should be at least 10% greater than the t200RetransmitTimer
value, except when readyTimer is set to forceStandby or useMsValue.
Engineering rule
• Increased T200 timer activity can lead to an increased CPU usage on the
SGSN.

• The T200 parameter is negotiated with the MS. As the sense of

negotiation is up then this means that the SGSN will accept the same or a
higher value in the response from the MS. The operator has the option to
performance. The T200 parameter is defined in the LLC protocol
specification; see section 8.
n200MaxRetransmits (n200)
Service Access Point 1 (SAPI-1) LLC entity retransmits an individual frame
following the expiry of the t200 timer. During the Exchange Information
(XID) negotiation, both the Logical Link Control (LLC) entities (the Mobile
Station and the SGSN) can agree to use a specific value for n200. The SGSN
attribute do not trigger re-negotiation of this parameter with the mobile.
The value of timer N200 represents the number of times the SGSN will
transmit an LLC XID message prior to failing the XID transaction in the
event that no XID response is received from the MS. In the worst case a value
for N200 that was to low could result in XID transaction failures which could
lead to Attach and IRAU procedure failures. Whereas a value of N200 that
was to large could result in unnecessary message re-transmission that simply
waste Gb link message bandwidth.
Range value 1 - 5
Default value 3
• Default value is recommendation. If identification cannot be done within

9 sec, there is certainly an issue in the access part and then the SGSN
doesn’t need to wait more time.
Engineering rule
• Increasing numbers of XID message re-transmits can lead to an increased

CPU usage on the SGSN.
• The N200 parameter is negotiated with the MS. As the sense of
performance. The N200 parameter is defined in the LLC protocol

n201MaxUInfoFieldLength
Description This attribute specifies the maximum number of octets allowed
in Unnumbered (U) and Unconfirmed Information (UI) frames for the Service
Access Point 1 (SAP-1). During the EXCHANGE INFORMATION (XID)
and the SGSN) can agree to use a specific value for n201U. The SGSN
Station.
The value n201MaxUinfoFieldLength parameter represent the maximum

number of LLC message information field octets that are allowed to be
transmitted. In the worst case whereby N201U is to low the result could be
that SAPI 1 LLC UI messages could be discarded
Range value 140 – 1520 octets
Recommended value default - 400
• From what has been noted on Gb side, the size of signaling messages is
always less than 400 Bytes. This is why the default value is the
recommended value.
Engineering rule
• Altering the size of parameter n201MaxUinfoFieldLength should not

have any noticeable adverse impacts on the SGSN.
• The n201MaxUinfoFieldLength parameter is negotiated with the MS. As
the sense of negotiation is down then this means that the SGSN will
accept the same or a lower value in the response from the MS. The
operator has the option to alter the initial value used on the SGSN in order
to optimize network performance. The n201MaxUinfoFieldLength
parameter is defined in the LLC protocol specification; see section 8.
msFlowControlThTimer
Description This attribute specifies the interval for which the Serving GPRS
Support Node (SGSN) uses the flow control parameters of the Mobile Station
(MS). Upon expiry, the SGSN uses the default parameters of the MS. This
parameter can only be modify in Debug mode.
msFlowControlThTimer parameter determines what the MS flow control Th

timer should be set to. The Th timer as defined in BSSGP 08.18 specification
section 8.2 describes how the SGSN should handle MS flow control
parameters sent to it from the BSS. The MS flow control parameters sent
from the BSS are used to tell the SGSN that for a given MS the SGSN can
send more or less data. Such MS flow control parameters are kept in use until
the Th timer expires at such time the default MS flow control parameters are

reverted back to. In the worst case scenarios given that the Th timer was to
short then assuming that the MS flow control parameters were higher than
default MS flow control parameters the result would be that end-end data
throughput to the MS could be reduced. Conversely a Th timer value that was
to high could lead to increased MS flow control messages that would
effectively waste Gb message bandwidth
• Before the msflowctlthtimer expires, SGSN uses R value provided in the

msflowcontrol message sent by Access.
• After the msflowctlthtimer expires, SGSN uses the default provisioned
parameter, which is most likely 10 kbps. This value of 10Kbps is
provisioned at PCU side.
Default value 5 s
Recommended value equal to the ReadyTimer value
Engineering rule (Based upon GPS Bulletin #116) The

msFlowControlThTimer timer needs to be set to the same value of the
readyTimer. It is expected that the readyTimer be close or equal to the default
value of 44 seconds.
Comments Investigation of high CPU Utilization on the GSD card has found
that when there is a high volume of MS Flow Control messages, the SGSN
may experience a Control Processor Switch Over. This CP SO is caused by
failure of the GSD to respond to CP card messaging when a flood of signaling
messages was received from the PCUSNs. The GSD cards were unable to
process these messages as CPU bandwidth was unavailable on the cards,
causing a timeout between CP and GSD cards. Incoming messages were
queued and when the threshold was surpassed, the CP performed a
switchover. As stated earlier, increased flow control messages from the
PCUSNs caused a CPU bottleneck on the GSD cards. This prevented the
GSD from responding to the CP card under certain conditions forcing a CP
switchover. The setting of parameter msFlowControlThTimer to 6000
seconds caused the CPU bottleneck on GSD card under these specific
conditions.
Because the readyTimer and msFlowControlThTimer share the same queue, it

can take a long time to find the proper place to insert the next timer. The
traversal of the queue has a direct impact on the CPU Utilization on the GSD
card. This is especially true when the number of active timers grow because
the msFlowControlThTimer is provisioned to 6000 seconds.

SAPI Data/<Sapi> attribute (SAP-3, SAP-5, SAP-9, SAP-11)

acknowledgment of a Unnumbered (U) frame must be received by the Service
Access Point (SAP) LLC entity. This attribute is only applicable for
Exchange Information (XID) negotiations and for Asynchronous Balanced
Mode (ABM) mode. During the XID negotiation, both the Logical Link
Control (LLC) entities (the Mobile Station and the SGSN) can agree to use a
specific value for this timer. The SGSN attempts to negotiate to the value
specified by this attribute. Changes to this attribute do not trigger re-
negotiation of this parameter with the Mobile Station.
The value of timer T200 represents the time for which the SGSN will wait
before re-transmitting an LLC XID message prior to receiving an XID
response from the MS. In the case of LLC data SAPI’s (3, 5, 9, 11) the XID
messages in question would specifically be for bearer plane data traffic for
both LLC UNACK and ACK modes of operation. In either case the worst
case scenario for an erroneous T200 setting would be to cause XID messages
to be re-transmitted. In the very worst case XID failures on data SAPI’s could
lead to activate PDP session procedure failures.
Default value no default
Recommended value Use Spec compliant default.
• t200retransmitTimer refers only to frame XID (exchange identification),

XID message is < 512 Bytes. Default value is 5 sec. The recommended
value should be 2 times Round Trip Delay. RTD is 1.5 sec in the worst
case. As recommended value, 3 seconds is enough
• But if the network is experiencing CPU at 50% + for GSD cards, please
contact GPS for additional assistance on this parameter setting.
• Increased T200 timer activity can lead to an increased CPU usage on the
SGSN.
• The T200 parameter is negotiated with the MS. As the sense of
performance. The T200 parameter is defined in the LLC protocol
specification see section 8. Also note that T200 is also used on the SGSN
to support the T201 LLC ACK mode protocol timer.

Description This attribute specifies the maximum number of times Logical
Link Entity (LLE) representing that Service Access Point (SAP) retransmits
an individual frame following the expiry of t200 timer. During the Exchange
Information (XID) negotiation, both the Logical Link Control (LLC) entities
(the Mobile Station and the SGSN) can agree to use a specific value for n200.
The SGSN attempts to negotiate to the value specified by this attribute.
Changes to this attribute do not trigger re-negotiation of this parameter with
the Mobile Station.
The value of timer N200 represents the number of times the SGSN will
transmit an LLC XID message prior to failing the XID transaction in the
event that no XID response is received from the MS. In the very worst case
XID failures on data SAPI’s could lead to activate PDP session procedure
failures. Whereas a value of N200 that was to large could result in
unnecessary message re-transmission that simply waste Gb link message
bandwidth
Range value 1 - 15
Recommended value Default - 3
• Default value is recommendation. If identification cannot be done within

9 sec, there is certainly an issue in the access part and then the SGSN
doesn’t need to wait more time.
Engineering rule
• Increasing numbers of XID message re-transmits can lead to an increased

CPU usage on the SGSN..
• The N200 parameter is negotiated with the MS. As the sense of
performance. The N200 parameter is defined in the LLC protocol
n201MaxUInfoFieldLength (n201U)
in Unnumbered (U) and Unconfirmed Information (UI) frames for that
Service Access Point (SAP). During the Exchange Information (XID)
negotiation, both the LLC entities (Mobile Station and SGSN) can agree to
use a specific value for n201U. The SGSN attempts to negotiate to the value

• The value n201MaxUinfoFieldLength parameter represents the maximum

number of LLC UI message information field octets that are allowed to be
transmitted. In the worst case whereby N201U is to low the result could
be that data SAPI LLC UI messages could be discarded.
• Depending on the overall radio network stability along with MS support
could mean that if this parameter is optimized then the overall data
through put to the MS for LLC UI messages could be improved
• The recommendation of n201MaxUinfoFieldLength for all SGSN GSD

Data SAPI values to 1520 is based on GPRS4.0 and GPRS5.0 throughput
testing. The following scenarios illustrate the potential behavior that is
experienced by some mobiles:
— If the SGSN has the n201MaxUinfoFieldLength set to the maximum
value (1520), the possible outcomes are:
– If the SGSN and mobile agree on this value, this should prevent
the SGSN from fragmenting packets.
– If the MS negotiates a smaller value, the SGSN will fragment the
packets to comply with the new value.
— If the SGSN has the n201MaxUinfoFieldLength set to 500, the SGSN
limits the frame size to a maximum of 500 bytes. If a mobile wants to
negotiate to 1520 and it is refused by the SGSN, there is frame
segmentation. Segmentation requires the mobile to have to re-
assemble the packets and it will take some CPU load in the Mobile.
Some mobiles have a problem processing the segmented packets.
Setting the n201MaxUinfoFieldLength attribute to the maximum
value on the SGSN will prevent frame size segmentation and be
compliant with all the mobiles.
See GPS Bulletin #113.
Engineering rule
• If setting is high and a lot of MS have a lower value, it will increase the
number of XID and possibly reduce capacity of the SGSN (Systems does
not have a quantified value on how much XID messages affect capacity).
• Recommendation from SE is that we should stick to what conforms to the
Spec and/or what conforms with the majority of the users in the field;

which corresponds to 520. But if the majority of the customer’s mobiles

use a MTU of 1520, then the SGSN should be set accordingly as well.
Comments
• If the mobile’s parameter value is less than this value, MS responds with
its smaller value. Most of the mobiles can use 1520, the SGSN doesn’t
have to reduce this PDU size, as it will be negotiated by the MS. This
increases the communication between MS and SGSN and thereby,
impacts the capacity. That’s the reason, it is recommended to survey the
LLC PDU size used by the Mobiles and set this value accordingly.
• Having larger value reduces the fragmentation of packets (based on the
negotiated value with MS), but under bad RF conditions reduces the
throughput.
n201MaxIinfoFieldLength (n201I)
in confirmed Information (I) frame for that Service Access Point (SAP).
During the Exchange Information (XID) negotiation, both the Logical Link
Control (LLC) entities (the Mobile Station and the SGSN)) can agree to use a
specific value for n201I. The SGSN attempts to negotiate to the value
• The value n201MaxIinfoFieldLength parameter represents the maximum

number of LLC ACK mode I message information field octets that are
allowed to be transmitted. In the worst case whereby N201I is to low the
result could be that data SAPI LLC ACK mode I messages could be
discarded.
• Depending on the overall radio network stability along with MS support
could mean that if this parameter is optimized then the overall data
through put to the MS for LLC ACK mode I messages could be improved.
Default value 1503 Bytes
Recommended value
• MTU + 20 Bytes or the LLC PDU value used by most of the user mobiles.
• If the customers mobiles follow the GSM spec, we should use the default
values: N201-U=500 and N201-I=1503. If the mobiles use 1520, N201-I
should be provisioned as 1520, in order to avoid additional XID
interaction.
Engineering rule

Comments If the mobile’s parameter value is less than this value, MS

responds with its smaller value. Most of the mobiles can use 1520, the SGSN
doesn’t have to reduce this PDU size, as it will be negotiated by the MS.
This increases the communication between MS and SGSN and thereby,

impacts the capacity. That is the reason it is recommended to survey the LLC
PDU size used by the Mobiles and set this value accordingly.
Having larger value reduces the fragmentation of packets (based on the

negotiated value with MS), but under bad RF conditions reduces the
throughput.
kWindowSizeDownlink
unacknowledged sequenced Information (I) frames from the SGSN to the
mobile for that Service Access Point (SAP). During the Exchange
Information (XID) negotiation, both the Logical Link Control (LLC) entities
(the Mobile Station and the SGSN) can agree to use a specific value for kD.
The SGSN attempts to negotiate to the value specified by this attribute.
Changes to this attribute do not trigger re-negotiation of this parameter with
the Mobile Station.
The value kWindowSizeDownlink (AKA kD - LLC ACK mode window size)

parameter represents the maximum number of LLC ACK mode I messages
that have been sent by the SGSN and have not yet been acknowledged by the
MS. In the worst case whereby kD is too small the result could be that data
LLC ACK mode I messages could be discarded prematurely resulting in
reduced end to end through put.
Range value 1 - 255
Default value
• Default: according to see GSM spec 4.64 section LLC layer parameter
default value
— SAPI D/3 - 16
— SAPI D/5 - 8
— SAPI D/9 – 4
— SAPI D/11 – 2
Recommended value Default value
Engineering rule

• The kD parameter is negotiated with the MS. As the sense of negotiation

is down then this means that the SGSN will accept the same or a lower
value in the response from the MS. The operator has the option to alter the
initial value used on the SGSN in order to optimize network performance.
The kD parameter is defined in the LLC protocol specification; see
section 8.
• Altering the size of parameter kD determines how many outstanding LLC
ACK mode I frames can be buffered on the SGSN waiting for ACK’s to
be returned by the MS. Given this then increasing the size of kD may lead
to increased message buffering requirements in the LLC layer for LLC
ACK mode I frames. Given that memory for LLC ACK mode in PC02 is
at a premium could worst case result in failure to buffer an I frame for re-
transmission. Such a scenario could lead to a protocol violation and or
reduced data through put to the MS.
kWindowSizeUplink
unacknowledged sequenced Information (I) frames from the mobile to the
SGSN for that Service Access Point (SAP). During the Exchange Information
Station and the SGSN) can agree to use a specific value for kU. The SGSN
Station.
Range value 1 - 255
Recommended value same as fro kWindowSizeDownlink
Engineering rule
SAPI Data/<SapiSms> attribute (SAP-7)

acknowledgment of an Exchange Information (XID) frame must be received
by the Service Access Point 7 (SAP-7) LLC entity. During the XID
and the SGSN) can agree to use a specific value for this timer. The SGSN
Station.

Default value 20 s
Engineering rule The readyTimer value provisioned in the Sgsn

GprsSubscriberControl component should be at least 10% greater than the
t200RetransmitTimer value. The timer must be provisioned to a value that is
greater than the expected maximum expected round trip delay of a (PDU).
Service Access Point 7 (SAPI-7) LLC entity retransmits an individual frame
following the expiry of the t200 timer. During the Exchange Information
Station and the SGSN) can agree to use a specific value for n200. The SGSN
attribute do not trigger re-negotiation of this parameter with the mobile.
Range value 1 - 15
Default value 3
Recommended value 3
Engineering rule
n201MaxUInfoFieldLength (n201U)
in Unnumbered (U) and Unconfirmed Information (UI) frames for the Service
Access Point 7 (SAP-7). During the Exchange Information (XID) negotiation,
both the Logical Link Control (LLC) entities (the Mobile Station and the
SGSN) can agree to use a specific value for n201U. The SGSN attempts to
negotiate to the value specified by this attribute. Changes to this attribute do
not trigger re-negotiation of this parameter with the Mobile Station.
Range value 140 – 1520 octets
Default value 270 octets
Engineering rule

GPRS Transport Layer (GTL) provisionable attributes

bvcResetTimer
Description This attribute specifies the timer value to guard the BVC-
RESET procedure. The SGSN sends a BVC-RESET PDU to the PCU and
starts the bvcResetTimer for a BVC. The SGSN stops the timer upon
reception of a BVC-RESET-ACK PDU from the PCU. If the timer expires,
the SGSN retries the BVC-RESET procedure.
Range value 1 – 120 s
Default value 60 s

than the maximum expected round trip delay of a PDU.
bvcResetRetries
SGSN can send the BVC-RESET PDU in case a BVC-RESET-ACK is not
received before the bvcResetTimer expiry.
Range value 0 - 6
Default value 3
Recommended value 3
Engineering rule
PacketFlowContextFeature (pfcFeat)
Description (PC04: A00000537)This attribute specifies if the Packet Flow
Context Feature is enabled for all the Network Service Entities (NSEs) on this
SgGtl component.
If this attribute is set to ‘enabled’, then the SGSN shall send a BVC-Reset
message to BSS and re-negotiate the Feature Bitmap Information Element.
Recommended value dependent on if customer takes feature
Engineering Rule

bwForSvcToFratm
Description (PC04: Q00597422) This attribute specifies the amount of ATM
Switched Virtual Circuit (SVC) bandwidth allocated for each Network
Service Virtual Circuit (NSVC) on this Network Service Entity (NSE). The
value of this attribute should match that of the mate NSE on the associated
SgGtl component...
Range value 0..50000000 (bit/sec)
Default value 1000000
Recommended value see engineering rule
Engineering Rule If the FrAtm/m and SgGtl/n Nse/p components are

provisioned on the same shelf, the value of this attribute is ignored. If they are
on different shelves, this attribute should match the associated FrAtm/m Dlci/
n sp committedInformationRate attribute where CIR=Bc/Tc
All NS-VCs within the same NSE must have the same bandwidth. Every NS-
VC is linked to a DLCI.
PDU buffering provisionable attributes

New in PC04
Per the SGSN PDU Buffering feature, the following components have been
added to the GSD/x component:
• PduBuffer/x : The optional component dbuf will be obsolete and now the
five different buffer sizes (mini, small, medium, large and extralarge) will
be allocated under the required component Buffer.
• downlinkBuffer : This is a new optional component for downlink
buffering. This is replacing the existing dbuf component in the GSD card.
In the Usd card this will be added
• irauBuffer : This is a new optional component for IRAU buffering in the
GSD and USD card
Also The following are three common attributes that will be moved from
GprsGsdDbuffProv to wlcDownlinkProv and wlcIrauBuffProv and the
attribute names will change to.
Old Name-------------------New Name
maxMsWithBuff -------------- maxSessWithBuff
maxBytesBuffPerMs --- ------ maxBytesBuffPerSess

maxPacketsBuffPerMs --------------- maxPacketsBuffPerSess
Currently the CDL hierarchy has dbuf as an optional component under GSD.
So an upgrade from PC03 to PC04 the 2G SGSN will have a required
component buffer. The Dbuf component will be obsolete and its attributes
will be migrated under the new component, Buffer
Please note that the block size mentioned below is the payload size. Please
note that when memory is allocated the bucket size may differ. The total
memory allocated for buffering is being changed to 40MB. The total memory
used by different application in the GSD/USD card – LLC ACK, IRAU,
downlink should not exceed 40MB. If the customer is not using LLC ACK
mode, then the totalMemoryAllocated should not exceed 17MB
Because the allocation of memory for buffering utilizes a fixed-size block

allocation method, the actual amount of buffered data will be less than the
allocated memory.
totalMemoryAllocated = (numMiniBlocks_m * blockSize)

+(numSmallBlocks_m * blockSize)+ (numMediumBlocks_m * blockSize) +
(numLargeBlocks_m * blockSize)
The following parameters (numBlocks and blockSize) are located under each
buffer size and used to set the required buffer parameters for:
• Mini (Gsd Buffer/mini)
• Small (Gsd Buffer/small)
• Medium (Gsd Buffer/medium)
• Large (Gsd Buffer/large)
• XLarge (Gsd Buffer/XLarge) – this block size should not be set to any
other value other than the defaulted value.
Important: The defaulted values are the recommendation but numBlocks
can be tweaked according to the customer’s needs/requests per their packet or
memory distribution needs. The parameter, “blockSize”, should not deviate
from the default. The defaulted sizes were only utilized and also the defaulted
sizes is according to the spec.
numBlocks
Description This attribute specifies the number of mini/small/medium/large/
x-large memory blocks that are allocated for buffering of Protocol Data Units
(PDUs).
The total memory allocated for buffering must not exceed the total available
memory.

The value for this attribute should be carefully considered as changing this
value may adversely result in a loss of service or may impact performance for
the GSD or USD applications. Decreasing the value shall result in a card reset
for the lower value to take effect
(MINI)
Range value Decimal 0..178304
Default value 11236
(SMALL)
Range value DECIMAL(0..54876)
Default value 5728
(MEDIUM)
Default value 881
(LARGE)
Default value 4186
(X-LARGE)
Range value When set to autoConfig, the default value is based on the
application. The default value is 0 for the USD application and the default
value is 100 for the GSD application. DECIMAL(0..8200,
autoConfig=65535)
Default value autoConfig

Recommended value default. The XL settings should not deviate from the
defaulted value.
blockSize
Description This attribute specifies the size of the mini/small/medium/large/
x-large memory block.
The total memory allocated for buffering must not exceed the total available
memory.
The value for this attribute should be carefully considered as changing this
value may adversely result in a loss of service or may impact performance for
the GPRS Subscriber Datapath (GSD) or UMTS Subscriber Datapath (USD)
applications. The card running the application will be reset to reflect the
change in the value of the attribute
Overall these values must not deviate from the defaulted values; and should
not be engineered by the customer.
(MINI)
Default value 128 bytes
Recommended value
(SMALL)
Recommended value
(MEDIUM)
Default value 1501 byes
Recommended value
(LARGE)

Recommended value
(X-LARGE)
Recommended value The XL settings should not deviate from the defaulted
value
The following parameters are located under the new optional component Gsd/
n DownlinkBuffer and Gsd/n IrauBuffer.
maxSessWithBuff (formally maxMsWithBuff)

Description (PC04: A00003234)This parameter defines the total number of
mobiles that can employ buffering at any given time.
• Gives the maximum number of mobiles that can use down link buffering
at any given time. This parameter along with other two parameters:
MaxPacketsBuffPerMs and MaxBytesBuffPerMs decides which MS gets
the buffers and which MS does not get the buffers.
• This parameter defines the maximum number of mobiles that can use
down link buffering at any given time. As the overall amount of memory
for all mobiles per GSD is fixed means that as the number of mobiles to
be supported increases then this potentially decreases the amount of data
that can be buffered per mobile.
(IRAU)
Default value 100
(DOWNLINK)
Default value 1000

Engineering rule The value for this parameter should be carefully

considered based on the number of mobiles predicted to be served by a single
GSD at any given time, and on the predicted data arrival rate for those
mobiles. It is expected that only a small percentage of active mobiles should
require buffering concurrently, but the actual value selected should be
dependent on the traffic patterns expected.
Depending on the value of buffCheckInterval, some capacity degradation may

be incurred
Comments
• Increasing/decreasing this parameter value increases/decreases the

number MS allowed buffering at SGSN provided sufficient number of
buffers is available.
• The general rule is you cannot exceed the allocated 10MB allocated for
DBuf: maxMSwithBuff * maxpacketsBuffMs = 40MB
• As the overall amount of memory for all mobiles per GSD is fixed means
that as the number of mobiles to be supported increases then this
potentially decreases the amount of data that can be buffered per mobile.
• NOTE well the absolute maximum amount of memory that is reserved for
buffering per GSD card is 40MBytes. Engineering of this parameter is
network specific. As such there are no guarantees that this value will
actually be met on the GSD.
maxPacketsBuffPerSess (formally MaxPacketsBuffPerMS )

Description (PC04: A00003234) This attribute specifies the maximum
number of downlink packets that may be buffered for a single mobile at any
given time, regardless of packet size or number of octets currently buffered.
Packets received beyond this limit are discarded by the SGSN.
• Gives the maximum number of packets that can stored into the down link
buffer at any given time for any given mobile.
• This parameter defines the maximum number of packets that can stored
into the down link buffer at any given time for any given mobile. As the
overall amount of memory for all mobiles per GSD is fixed means that as
the number of packets per MS increases then this potentially decreases the
number of mobiles that can use the down link buffer at any given moment.
Range value 0 -100
Default value 12
Recommended value 40MB/(MaxMSWithBuf*AvgPacketSize))

Engineering rule There is no guarantee that each mobile will be able to

buffer this number of packets; rather, this parameter is intended only to limit
the number of packets that may be buffered on a per-mobile basis to avoid an
over allocation of resources to a single mobile.
Comments
• Increasing this number allows a MS to buffer more number of packets.

But, due to Memory limitation, it may starve other MSs.
• Decreasing this number limits the number of packets a MS can buffer.
that as the number of packets that can be stored in the down link buffer per
MS is increased, means a potential decrease in the number of mobiles that
can use the down link buffer at any given moment.
• NOTE well the absolute maximum amount of memory that is reserved for
buffering per GSD card is 40MBytes. Engineering of this parameter is
network specific. As such there are no guarantees that this value will
maxBytesBuffPerSess (formally maxBytesBuffPerMs)

number of octets that may be buffered for a single mobile at any given time,
regardless of the number of packets currently buffered for the mobile. Packets
received beyond this limit are discarded by the SGSN.
• This parameter defines the maximum number of bytes that can stored into
the down link buffer at any given time for any given mobile. As the
overall amount of memory for all mobiles per GSD is fixed means that as
the number of bytes to be supported increases then this potentially
decreases the number of mobiles that can use the down link buffer at any
given moment.
Recommended value 40MB/(maxSessWithBuff)
Engineering rule This does not imply that the amount of memory allocated
for buffering must be sufficient for ALL mobiles to buffer maxBytes of data
concurrently; rather, this parameter limits only the maximum amount of data
that a single mobile may buffer, thereby ensuring that no one mobile is
allocated an inordinate share of the available buffering resources.
Comments

• Increasing this number slightly is OK under lighter loads, because it

allows a MS to store more bytes than its share, when needed. Increasing
this number under heavy load causes unfair allocation of memory buffers.
• Decreasing this number does not provide fair share number of memory
buffers.
that as the number of bytes that can be stored in the down link buffer per
MS is increased, means a potential decrease in the number of mobiles that
can use the down link buffer at any given moment.
• NOTE well the absolute maximum amount of memory that is reserved
link buffering per GSD card is 40MBytes. Engineering of this parameter
is network specific. As such there are no guarantees that this value will
totalBytesReservedForBuffering
Description (PC04: A00003234) This attribute reflects the total number of
bytes reserved for buffering on this UMTS Subscriber Data (USD) and GPRS
Subscriber Data (GSD). It is equal to (the value of the numMiniBlocks
attribute * 128) + (the value of the numSmallBlocks attribute * 604) + (the
value of the numMediumBlocks attribute * 1501) + (the value of the
numLargeBlocks attribute * 1520) + (the value of the numXLargeBlocks
attribute * 4096).
(IRAU)
Recommended value
(DOWNLINK)
Recommended value
Engineering rule In PC04, the maximum buffering allowed for IRAU and
DL buffering is increased to a total of 17MB.
The following two are provisionable attributes of the U(G)sd/n PduBuffer

components.

pduLifeTimeInBuff
amount of time that a single PDU may be buffered. After expiry of this time
period, if the buffered PDU has not been sent to the mobile, the PDU is
discarded. This attribute is used by applications using the memory block
pools.
The value of this attribute must be provisioned to a value that is greater than
the value of the buffCheckInterval attribute and also greater than the
maximum expected round trip delay of a PDU.
• Gives the amount of time a packet is buffered in the Dbuf buffer.

• This parameter defines the maximum amount of time that a single packet
can be stored in the down link buffer. Given this then if this value is too
small then it could lead to premature packet discards. Alternatively it
could result in reduced levels of support for all mobiles i.e. less mobiles
can use down link buffering.
Default value 20 s
Recommended value 5 s; This value must be equal to t200Retransmit timer

t200 (aka t201) which defines the LLC I frame re-transmit time. Hence there
is no point in retransmitting frames faster than LLC is allowed to send them.
Adjust to the worst case LA/RA update in NMO2 (around 15 sec),

encompass: radio loss of com; inter/intra RA cell reselection; IRAU reselect;
combined LA/RA update.
Engineering rule The SGSN will monitor the buffers to ensure that any
packet buffered longer than the configured maximum time will be discarded,
thereby freeing the buffer space for other mobiles.
Comments
• If the timer value is smaller than SE recommended value, then the packet
gets unnecessarily dropped, thereby, decreasing the End2End throughput.
that as the amount of time that a single packet can be stored in the down
link buffer is increased, means a potential decrease in the number of
mobiles that can use the down link buffer at any given moment.
buffCheckInterval
Description (PC04: A00003234) This attribute specifies the periodic time
interval which triggers the Serving GPRS Support Node (SGSN) to attempt to

transmit buffered Protocol Data Units (PDUs) to a mobile data session. This
attribute is used by applications using the memory block pools.
The value of this attribute must be selected very carefully. It should be

provisioned based on the expected availability of the peer. However, if this
value is set too low, depending on the number of sessions allowed to do
buffering concurrently, a non-negligible impact to system capacity may result.
Range value DECIMAL_PLACES=1; 0.1..20 seconds
Default value 2.0 s
Recommended value 1.0 s
Engineering rule must be smaller than the pdulifetime in buffer parameter.
GPRS Routing Area provisionable attributes

The component “Sgsn Mcc/n Mnc/n Lac/n RoutingAreaCode/n" represents
the Routing Area Codes (RAC) supported by the SGSN.
Figure C-6
GPRS Routing Area provisionable attributes
(Root)
SGSN
MCC/n
MNC/n - CountryCode
- NetworkCode
- Lac
T3312
ptmsiEvents
linkToVlr
Nsei
periodicRaUpdateTimer (T3312)
Description The MS receives this timer from the network during GPRS
Attach Accept and during Periodic Routing Area Update Accept. It is started
when PMM-CONNECTED mode is left and stopped when the MS enters
state GMM-DEREGISTERED (that is after a successful MS-INITIATED PS
DETACH, a NETWORK-INITIATED PS DETACH, an ATTACH REJECT or
an RAU REJECT) When this timer expires, the MS notifies the SGSN of the

current routing area of the MS. This timer value is per Routing Area. The
value deactivate means that no periodic messages are sent.
Range value 0 (deactivation value); from 1 to 31 min in 1 min steps; from 36

to 186 min in 6 min steps
Engineering rule Value must be less than half of MobileReachable Timer

(58 min.) so that the mobile user gets at least two chances for updates.
The mobileReachableTimer provisioned in the Sgsn GprsSubscriberControl

component must be at least four minutes longer than the longest
periodicRaUpdateTimer.
Since RAU procedures involve GMM signalling messages that are to be

processed by the GSC cards of the SGSN, it is advised to set this timer to a
higher value in high mobility and dense traffic areas.
A low value for this timer is of interest to recover quickly the effective RA of
the MS when MS lost coverage, as explained in the chapter related to periodic
RAU timer function above.
ptmsiEvents
Description This attribute specifies the number, N, which indicates that at
every Nth event requiring (P-TMSI) reallocation, the P-TMSI Reallocation
procedure is initiated with the MS. This parameter is not per MS, rather it
applies to events over a specific RA.
Range value 0 (never); 1 - 255
Default value 10
Recommended value To reduce the probability of a TLLI collision, GPS

recommends to set the parameter ptmsiEvents to NEVER. See WDS bulletin
#71 dated on 2004/02/12 and bulletin #101. Change this value do not require
card reset.
Given in PC04, new code is introduced to reduce the probability to TLLI

collisions to once every 50 years; the defaulted value of 10 is acceptable as
well.
Engineering rule When this value is set to never, the P-TMSI Reallocation
procedure is never performed on local P-TMSIs received from the mobile
subscriber. Only the non local P-TMSIs undergo P-TMSI reallocation.

When the value is set to 1, P-TMSI Reallocation procedure is performed

every time an event that triggers P-TMSI reallocation occurs. This means that
the P-TMSI is reallocated whether it is local, foreign or random.
MAP stack provisionable attributes

The component "sgsn MapStack/n" represents the MAP stack of the SGSN.
There is one component per MAP card. It contains the provisionable
attributes detailed below.
Figure C-7
MAP stack provisionable attributes
(Root)
Sccp variant Nature of address

Sccp class of operation E.164 TT
E164 MOFSMTT E212 TT
TCAP/1 E214 TT SccpreturnOption
Hopcounter Xudtoption
SccpUserInfo
Max concurrent transaction
Max concurrent invokes
Capacity Max invokes per subsystem
Max transactions per subsystem
Map Stack UGL sanity timer SAI sanity timer

CL sanity timer DSD sanity timer
ISD sanity timer MTFSM sanity timer
FSM sanity timer MOFSM sanity timer
Msg Timer RFSM sanity timer AFR sanity timer
Link to port SIG IP address

SIG Tcp port
SS7IpIf/n Heartbeat timer keep alive timer
uglSanityTimer
Description This attribute specifies the amount of time the MAP Stack waits
for the UPDATE GPRS LOCATION RESPONSE from the HLR. The timer is
started when the UPDATE GPRS LOCATION message is sent to the HLR.
The number of retries is specified by the attribute uglRetries in the MapClient
component that is associated with this MAP Stack.
Default value 11 s
Recommended value 11s; associated with PC03 recommendation (from

patch sgsnQ00891463EMG which addresses GmmPrimaryContexts Hung
During GSC Overload Conditions.). Given the issue is to be resolved in
PC04, the parameter can be further reduced to 6 s.


than the maximum expected RTD of a PDU between the SGSN and the HLR.
The number of timeouts of this timer is indicated by the operational attribute
uglTimeouts.
This timer value must be greater than isdSanity timer value.
saiSanityTimer
for the SEND AUTHENTICATION INFORMATION RESPONSE from the
HLR. The timer is started when the SEND AUTHENTICATION
INFORMATION message is sent to the HLR. The number of retries is
specified by the attribute saiRetries in the MapClient component that is
associated with this MAP Stack.
Default value 9 s
Recommended value 9s; associated with PC03 recommendation (from

patch sgsnQ00891463EMG which addresses GmmPrimaryContexts Hung
During GSC Overload Conditions.). Given the issue is to be resolved in
PC04, the parameter can be further reduced to 5 s.

saiTimeouts.
afrSanityTimer
for the AUTHENTICATION FAILURE REPORT RESPONSE from the HLR.
The timer is started when the AUTHENTICATION FAILURE REPORT
message is sent to the HLR. The number of retries is specified by the attribute
afrRetries in the MapClient component that is associated with this MAP
Stack.
Default value 25 s

The number of timeouts of this timer is indicated by the attribute afrTimeouts.

pmsSanityTimer
for the PurgeMS acknowledgement from the HLR.The timer is started when
the PurgeMS message is sent to the HLR. Upon expiry, only statistics are
incremented.
Range value 1 - 60 seconds
Default value 50 s

clSanityTimer
for the CANCEL LOCATION RESPONSE from the MAP Client. The timer is
started when the CANCEL LOCATION message is received from the HLR.
The number of retries is specified by the HLR provisioning which is external
to the SGSN.
Default value 25 s
Recommended value 25 secs, per PC03 recommendation. Given the issue is

to be resolved in PC04, the parameter can be further reduced to 11 s.

clTimeouts.
clSanityTimer value must be greater than T3TunnelTimer
dsdSanityTimer
for the DELETE SUBSCRIBER DATA RESPONSE from the MAP Client. The
timer is started when the DELETE SUBSCRIBER DATA message is received
from the HLR. The number of retries is specified by the attribute dsdRetries
in the MapClient component that is associated with this MAP Stack.
Default value 25 s


dsdTimeouts.
isdSanityTimer
for the INSERT SUBSCRIBER DATA RESPONSE from the MAP Client. The
number of timeouts of this timer is indicated by the attribute isdTimeouts. The
number of retries is specified by HLR provisioning which is external to the
SGSN.
Default value 25 s
Recommended value 8s per PC03 GPS recommendation. Given the issue is

to be resolved in PC04, the parameter can be further reduced to 5 s.

isdTimeouts.
mtfsmSanityTimer
for the MOBILE TERMINATED FORWARD SHORT MESSAGE RESPONSE
from the MAP Client. The timer is started when the MOBILE TERMINATED
FORWARD SHORT MESSAGE message is received from the Short Message
Service Center (SMSC). The number of retries is specified by SMSC
provisioning which is external to the SGSN.
Default value 79 s

mtfsmTimeouts.

mofsmSanityTimer
for the MOBILE ORIGINATED FORWARD SHORT MESSAGE RESPONSE
from the SMSC. The timer is started when the MOBILE ORGINATED
FORWARD SHORT MESSAGE message is sent to the SMSC. There are no
retries associated with this message.
Default value 60 s

than the maximum expected RTD of a PDU between the USGSN and the
HLR. The number of timeouts of this timer is indicated by the operational
attribute mofsmTimeouts.
fsmSanityTimer
for the FORWARD SHORT MESSAGE RESPONSE from the MAP Client.
The timer is started when the FORWARD SHORT MESSAGE message is
received from the Short Message Service Center (SMSC). The number of
retries is specified by SMSC provisioning which is external to the SGSN.
Default value 60 s

The number of timeouts of this timer is indicated by the attribute
fsmTimeouts.
rfsmSanityTimer
for the READY FOR FORWARD SHORT MESSAGE RESPONSE from the
HLR. The timer is started when the READY FOR FORWARD SHORT
MESSAGE message is sent to the HLR.
Default value 25 s


rfsmTimeouts.
PslSanityTimer
for the PROVIDE SUBSCRIBER LOCATION RESPONSE message from
the MAP Client.The timer is started when the PROVIDE SUBSCRIBER
LOCATION message is received from the Gateway Mobile Location Center
(GMLC).The number of timeouts of this timer is indicated by the pslTimeouts
attribute.In the GPRS network, this attribute value must be greater than the
value of the pagingTimer attribute.In the UMTS network, this attribute value
must be greater than the sum of the pagingTimer attribute and either the
locationReportTimer attribute or the locationNotifyTimer attribute,
depending on which of the two has the higher value.
Default value 60 s
Engineering rule
maxTransactionsPerSubsystem
Description This attribute specifies the maximum number of concurrent
TCAP Transactions that are supported by the TCAP stack for each subsystem
receiving service. The current number of TCAP transactions active for each
subsystem is indicated by the currentTransactionsPerSubsystem operational
attribute. If the current number of active transactions for a given subsystem
reaches the maximum, new requests for service from that subsystem are
ignored. A Critical alarm is set when the current number of transactions for a
subsystem reaches 95% of the value specified for that subsystem by this
attribute. Altering the value specified by this attribute after initial activation
will result in an interruption of service for all clients while the TCAP stack is
restarted. Transactions in progress are lost and new transactions cannot be
serviced.
Range value 200 – 4000 for Sgsn, Cap, MscEmulation
Default value 500
Recommended value sgsnSubsy=2000
CapSub = 1000

MscEmul=1000
Engineering rule The value specified for each subsystem must be less than
or equal to that specified by the maxInvokesPerSubsystem attribute for the
same subsystem.
maxInvokesPerSubsystem
Description This attribute specifies the maximum number of concurrent
TCAP invokes that are supported by the TCAP Stack for each subsystem
receiving service. The current number of TCAP invokes active for each
subsystem is indicated by the currentInvokesPerSubsystem operational
attribute. If the current number of active invokes for a given subsystem
reaches the maximum, new requests for service from that subsystem are
ignored. A Minor alarm is set when the current number of transactions
reaches 90% of the value specified by this attribute. A Critical alarm is set at
95%. Altering the value specified by this attribute after initial activation will
result in an interruption of service for all clients while the TCAP stack is
restarted. Transactions in progress are lost and new transactions cannot be
serviced.
Range value 200 – 5000 for Sgsn, Cap, MscEmulation
Default value 600
Recommended value SgsnSubsy=2400
CapSub = 1250
MscEmul=1250
Engineering rule The value specified for each subsystem must be greater
than or equal to that specified by the maxTransactionsPerSubsystem attribute
for the same subsystem.
The value specified for each subsystem must be greater than or equal to that
specified by the maxTransactionsPerSubsystem attribute for the same
subsystem. maxInvokes = maxTransaction * 1.2 {20% greater}
registrationTimer
Description (PC04: A00001863)This attribute specifies the amount of time
the TCAP waits for a response after sending another registration message on
behalf of the client to the SIG. Retries of registration request are infinite.
Range value DECIMAL(0-60 sec.)
Default value 10 s

Engineering rule
The following are attributes associated with the TCAP/7 SS7IpIf component
(New in PC04: A00003052)
• The linktoPort attribute has been modified to include UDP. The link
pointed to by this attribute specifies the protocol TCP or UDP and IP
address that is used by the passport for communicating with the SS7 IP
Gateway (SIG). This attribute is not changed, but the Component
Administration System (CAS) escape is changed from only accepting
TCP to accepting either TCP or UDP for Transaction Capabilities
Application Part (Tcap). (Base Sub System Application Part (BSSAP)
will continue to only accept TCP).
• Also the following parameter names were changed
— ss7IpGatewayTcpPort changed to ss7IpGatewayPort since the port
can now be either TCP or UDP
— tcpCnxUpTimer changed to cnxUpTimer since the port now can
now be either TCP or UDP
heartbeatTimer
Description This attribute specifies the time interval between the heartbeat
messages sent to the SIG by the Ss7ipif. The value specified by this attribute
should be less than the keep-alive timer specified on the SIG. It's
recommended that this attribute specify a value that is one-third the value of
that specified by the keep-alive.
(PC04:A00003052) The default value of the heartbeat timer is changed from

20 seconds to 5 seconds since the UDP implementation is relying indirectly
on this timer to tell when the link is down. Having the value smaller by
default allows the software to detect a bad link quicker. Shortening the value
does not affect capacity as the heartbeat is only sent out when there is no
incoming traffic.
Range value DECIMAL(disabled=0, 1..100 sec.)
Default value 5 s
Engineering rule

keepaliveTimer
Description This attribute specifies the amount of time the Ss7IpIf waits to
receive heartbeat messages from the USP SIG before timing out. If the
Ss7IpIf does not receive a heartbeat message from the SIG within the amount
of time specified, it transitions into the OSI disabled operational state until
connectivity with the SIG can be reestablished.
If the Ss7IpIf is provisioned to connect to an HP SIG, this attribute should be

set to disabled. Setting this attribute to disabled indicates that the Ss7IpIf will
not monitor heartbeat messages from the SIG.
This attribute should specify a value greater than that specified by the
heartbeat timer on the SIG. It is recommended that this attribute specify a
value that is three times the value specified by the heartbeat timer on the SIG.
(PC04:A00003052) The default value of the keepalive timer is changed from

60 seconds to 15 seconds since the UDP implementation is relying on this
timer to tell when the link is down. Having the value smaller by default
allows the software to detect a bad link quicker. Shortening the value does
not affect capacity in any way.
Range value DECIMAL(disabled=0, 1..300)
Default value 15 s
Engineering rule
hdlcBuffers
Description (PC04:A00003052) This process critical attribute specifies the
number of buffers that the High-Level Data Link (HDLC) layer preallocates
during initialization to store outgoing messages to the SS7 IP Gateway (SIG).
Setting this attribute to the value of disabled indicates that the HDLC layer is
turned off. This means that no memory is allocated and no retries are done on
the UDP connection.
This attribute applies only to UDP.
Range value Decimal (disabled, 1..32768)
Default value 1800
Recommended value Disabled, Since UDP is removed from the Gr’

connection, it is recommended to set this to “disabled”.
Engineering rule

lostMessagesThreshold
Description (PC04:A00003052) This process critical attribute specifies the
number of outstanding lost messages that the High-Level Data Link Control
(HDLC) layer keeps track of. If the number of outstanding lost messages goes
above this threshold, an alarm indicating an excessively noisy link between
the MapStack and SS7 IP Gateway (SIG) is raised.
This attribute applies only to UDP.
Range value Decimal (1..32768)
Default value 1300
Engineering rule Since this applies to only UDP, this parameter setting has
no bearing. UDP is not utilized on the SGSN to SIG connection.
cnxUpTimer
Description (PC04: A00001863) This attributes specifies the time the
TCAP/BSSAP component waits after the connection (TCP for BSSAP and
TCP or UDP for TCAP) comes back up before the link is considered
“healthy”.
Range value DECIMAL(disabled=0, 1-300 seconds.)
Default value 10 s
Engineering rule
clDialogueTimer
Description This attribute specifies the timer for which a response must be
received for a Cancel Location message from the GPRS Mobility
Management (GMM) application. The timer is started when a Cancel
Location message is received from the Home Location Register (HLR) and
cancelled when a response is received from GMM. If the timer expires, then
the transaction in the Mobile Application Part (MAP) Client is released and a
Cancel Location response message sent to the HLR.
Range value DECIMAL(1-32)
Default value 20 s

Engineering rule Previously a PC02/PC03 startup file variable.
DNS Agent provisionable attributes

The "Sgsn DnsAgent" component represents the DNS Agent functionality. It
contains the provisionable attributes detailed below.
retryTimer
Description this attribute specifies how long the DNS agent waits for a
response from a Domain Name System (DNS) Server following the initial
query. Intervals for subsequent retries if required, are computed using an
algorithm based on this attribute.
Default value 5 s

than the maximum expected RTD of a PDU between the SGSN and any DNS
Server.
maxRetries
Description this attribute specifies the maximum number of retries for a
DNS query. After maxRetries expiry, if there is no response from the DNS
Server, the DNS agent sends an error indication to the application.
Range value 0 - 5
Default value 2
Engineering rule
refreshTime
Description this attribute specifies how often DNS cache table entries are
refreshed. After the timer expires for a given entry, the next client query for
that entry Logical Name causes the DNS Server to be queried again to update
the Logical Name information in the SGSN DNS cache.
Range value 0 - 14 400 min
Default value 10 080 min

Recommended value 10080; there is only a capacity impact if the parameter

is set very low.
Engineering rule
maxDynamicEntries
Description This attribute specifies the maximum number of dynamic
entries supported by the DnsAgent cache table. Decrease in the cache size
will be effective only in the next restart. The current cache usage can be
obtained from the attribute currentCacheUsage.
Range value 0 - 500
Default value 0
Engineering rule This parameter has a capacity impact because it defines

many entries are stored in the cache table.
maxDynamicEntries memory allocation = GprsDnsAgentCacheEntry pool

size x maxDynamicEntries parameter increase
maxDnsQueries
Description This attribute specifies the maximum number of dynamic
queries supported simultaneously by DnsAgent. A decrease in the value of
this attribute will lead to the decrease in the number of dynamic queries
supported by DnsAgent..
Range value 20..5000
Default value 200
Engineering rule Unlike maxDnsEntries, it does not have a major memory/

capacity hit to the SGSN. Its not controlling any pool like
maxDynamicEntries does.
SGSN Accounting Server (SAS) provisionable attributes

New in PC04 (A00004239): In order to logically arrange all the provisionable
accounting attributes in one group under one component, the “Accounting”
subcomponent under Sgsn is obsoleted. All the provisionable attributes under
this subcomponent are moved to the existing group “WlcSasProv” under the
Sas/x component. Sas/x instances can be provisioned with x = 1 .. 16. The
system will validate that only a maximum of 4 Sas/x instances can be

provisioned. The new attributes are automatically populated with the existing
values from the obsoleted (U)Sgsn Acct component.
Also the names of the following provisionable attributes are changed to more
accurately describe their function.
Old Name-------------------New Name
updateInterval--------------cdrUpdateInterval
cdrTransferTime --- ------drtResponseTimeout
cdrRetries ---------------drtRetries
Also new in PC04; the following four attributes will be modified/added in each
SAS and GSD component. Multiple instances of these components must have
the same values for the attributes described. A common group will be added to
the SAS and GSD components to provide billing attribute definition across
multiple components.
• scdrPartialRecordInterval
• scdrMaxContainers
• specificDailyScdrPartial
• dailyPartialTimeOfDay
Important: These four parameters must be set to the same value between the
SAS and GSD. There is not a “check escape” that checks the values between
the two applications because they are on different shelves.
cdrCapture
Description this attribute specifies which of the following Call detail
Records (CDRs) are generated: S-CDRs, M-CDRs, S-SMO-CDRs and/or S-
SMT-CDRs.
Range value bitmap (sgsn, mobility, smo, smt)
Default value disabled (No CDRs are generated)
Recommended value customer dependent (sgsn)
Engineering rule This value of this component needs to be the same on all
other Sas components on the shelf.
locationBaseBilling
Description This attribute specifies whether location-based billing for the
generation of partial Serving GPRS Support Node (SGSN) Packet Data

Protocol (PDP) Call Detail Records (S-CDRs) upon routing area changes is
enabled or disabled. When set to enabled, every S-CDR will only contain the
traffic data volume counts for a single routing area, allowing the operator to
bill based on the geographic location.When set to disabled, routing area
changes do not affect S-CDRs.The value of this attribute needs to be the same
on all other Sas components on the shelf.
Recommended value customer dependent
Engineering rule both S-CDRCapture and M-CDRCapture must be enabled

for this attribute to be enabled.
This value of this component needs to be the same on all other Sas
components on the shelf.
CPU & Memory Impact as a result of generating Location Based Billing

records.
transferInterval
Description This attribute specifies the interval at which currently spooled
closed Call Detail Records (CDRs) are to be transferred to the Charging
Gateway Functionality (CGF). When set to noDelay, closed CDRs are
transferred to the CGF with minimal delay. When set to any other value,
closed CDRs on the hard disk are sent to the CGF at the time specified by the
transferTimeOfDay attribute, and then transferred every interval of minutes as
specified by the value of the transferInterval attribute.
Range value NoDelay, 15 - 1440 min in 15 min increments
Recommended value NoDelay or 15 mn if possible.
Engineering rule Throughput & CPU impact as a result of transferring

Billing records.
The setting of the transferInterval is dependent on the frequency at which an

operator requires CDR files for downstream processing. Determine how often
you require CDRs for downstream processing. The engineered setting does
have an impact on several core network components. They are CGF capacity,
SAS card hard drive usage and transfer capabilities between the SAS card and
the CGF.

cdrUpdateInterval (formally updateInterval)

Description (New in PC04:A00004239) This attribute specifies the interval
at which currently spooled closed Call Detail Records (CDRs) are to be
transferred to the Charging Gateway Functionality (CGF). When set to
noDelay, closed CDRs are transferred to the CGF with minimal delay. When
set to any other value, closed CDRs on the hard disk are sent to the CGF at the
time specified by the transferTimeOfDay attribute, and then transferred every
interval of minutes as specified by the value of the transferInterval attribute.
Range value 15 - 1440 min in 15 min increments
Recommended value 30 min (per Design).
Engineering rule The value of this attribute must be less than or equal to the
scdrPartialRecordInterval and mcdrPartialRecordInterval attributes.
scdrPartialRecordInterval
Description This attribute specifies the interval at which the partial S-CDRs
are generated. When set to a value other than NoPartialRecords, S-CDRs that
have been open longer than scdrPartialRecordInterval are closed with a partial
record reason of "time (duration) limit".
(PC04:A00004239)This attribute is set in the SAS and GSD components.
Range value NoPartialRecords,15 - 1440 min in 15 min increments
Default value NoPartialRecords
Engineering rule The value of the scdrPartialRecordInterval attribute must

be greater than or equal to the value of the cdrUpdateInterval attribute when
partial records are enabled.
The setting for scdrPartialRecordInterval is dependant on the granularity of

SCDR increments. Based on the timer setting a partial record will be
generated in addition to the SCDR generated when the subscriber activates a
session. This parameter setting is dependant on the operators billing
requirements. The number of partial records generated will be a function of
the timer setting and the amount of time a subscriber stays activated over a
given time. The engineering of this attribute will impact the billing cards
capacity with respect to PS Attached subscribers supported.

mcdrPartialRecordInterval
Description this attribute specifies the interval at which the partial M-CDRs
are generated. When set to a value other than NoPartialRecords, M-CDRs that
have been opened longer than mcdrPartialRecordInterval are closed with a
partial record reason of "time (duration) limit".
Range value NoPartialRecords, 15 - 1440 min in 15 min increments
Default value NoPartialRecords
Recommended value
Engineering rule The setting for the mcdrPartialRecordInterval is dependant

on the granularity of MCDR increments. Based on the timer setting a partial
record will be generated in addition to the MCDR generated when the
subscriber attaches to the SGSN. This parameter setting is dependant on the
operators billing requirements. The number of partial records generated will
be a function of the timer and the amount of time a subscriber stays attached
over a given time. The engineering of this attribute will impact the SAS cards
capacity with respect to PS Attached subscribers supported.
The value of the mcdrPartialRecordInterval attribute must be greater than or

equal to the cdrUpdateInterval attribute.
mcdrMaxContainers
Description M-CDRs may contain multiple Change of Location containers,
which are added to the M-CDR as a result of mobility events (routing area
changes). In addition to the mobile station’s IMSI, this container holds the
routing, area, location area, and cell ID identifying the mobile station’s
location.
Range value 1 - 10
Default value 5
Recommended value 5
Engineering rule Memory Impact for allocating MCDR Containers.
The setting of this attribute is dependant on the number of containers an

operator wishes to link to an open MCDR. This setting maybe dependant on
the downstream processing software ability to link containers to the MCDR
for correlation. From a capacity impact perspective the best setting is the
maximum value. Note that if the threshold is reached a partial MCDR is
generated. This has incremental effects to billing card capacity.

In the Nortel implementation, an M-CDR can have at most 10 Change of

Location containers. Once this number of containers is exceeded, a partial
M-CDR is generated with a partial record reason of "maximum number of
mobility changes".
scdrMaxContainers
Description This attribute specifies the maximum number of Traffic Volume
Containers in an S-CDR before a partial record should be generated. Traffic
volume containers are created due to a tariff time change event or a PDP
modification event.
(PC04:A00004239) This attribute is set in the SAS and GSD components
Range value 1 - 10
Default value 5
Recommended value 5
Engineering rule Memory Impact for allocating SCDR Containers.
Comments: The setting of this attribute is dependant on the number of

containers an operator wishes to link to an open SCDR. This setting maybe
dictated by the downstream processing software ability to link containers to
the SCDR for correlation.
From a capacity impact perspective the best setting is the maximum value.
Note that if the threshold is reached a partial SCDR is generated. This has
incremental effects to billing card capacity.
echoRequestInterval
Description This attribute specifies the interval at which GTP’ ECHO
REQUEST messages are sent to the CGF.
Range value 1 - 60 min in 1 min increments
Default value 5 min
Recommended value 1
Engineering rule Per Design recommendation; the lower the value the less
time the new feature functionality for SAS hot standby takes to recover.
drtResponseTimeout (formally cdrTransferTime)

Description (New in PC04:A00004239) This attribute (formally called
cdrTransferTime) specifies the initial waiting time in seconds for the response
message for a Call Detail Record (CDR) transfer request. The request

message can contain one or more CDRs. The timer doubles after each
successive retransmission of the same CDR.
Default value 5 min
Recommended value 5
Engineering rule
drtRetries (formally cdrRetries)

Description (New in PC04:A00004239) This attribute (formally called
cdrRetries) specifies the number of times the SGSN tries to resend a billing
record to the Charging Gateway Functionality (CGF) when the SGSN does
not get the acknowledgment before the tCdrXfer expires. If maximum value
of nCdrRetries is reached and there is no secondary CGF, the CDRs will be
sent to the CGF whenever the CGF is back in service. The SGSN knows that
the CGF is alive either by the ECHO REQUEST message or the NODE
ALIVE message
Range value 1 - 3
Default value 1
Recommended value 1
Engineering rule
sasAuditFileLife
Description This attribute allows the operator to specify how long the CDR
audit files will remain on the hard drive before being deleted.
Range value 1..10 days
Default value 5 days
Engineering rule
sasGenAuditFiles
Description This attribute gives the operator the ability to enable or disable
the generation of CDR audit files. When enabled, files are created which can
be used to audit the closed CDRs that were generated by this SGSN and
transferred to a CGF.

Range value enabled ; disabled
Engineering rule
sasroamerCapture
Description this attribute allows the operator to specify whether CDRs
should be generated for all subscribers or only Roamers.
Range value enumerated {all subscribers, roamers only}
Default value all subscribers
Engineering rule This value must match across all Sas/x instances. A
mismatch will result in an error at check prov time.
transferTimeOfDay
Description (New in PC04:A00004239) This attribute specifies a time of
day offset for the transfer of currently closed spooled Call Detail Records
(CDRs) to the CGF. The value is defined in minutes after midnight.
A transfer occurs at the time specified by this attribute and then transferred
every interval of minutes as specified by the value of the transferInterval
attribute. A minimum of one transfer will occur in every 24-hour period. The
number of transfers per day depends on the value of the transferInterval
attribute.
Range value 0-1439
Default value 0
Engineering rule
cdrUpdateTimeOfDay
Description (New in PC04: A00004239) This attribute specifies a time of
day offset for the processing of Call Detail Record (CDR) updates. The value
is defined in minutes after midnight. CDR updates occur at the time specified
by this attribute, and then updates every interval of minutes as specified by the
value of the cdrUpdateInterval attribute.

A minimum of one update will occur in every 24-hour period. The number of
updates per day depends on the value of the cdrUpdateInterval attribute.
Range value 0-1439
Default value 0
Engineering rule
specificDailyScdrPartial
Description (New in PC04: A00004239) This attribute enables the creation
of a management intervention partial scheduled for a specific time each day.
This partial is created at the specified time regardless of when the previous
partial S-CDR record was created for this session. This timed event is a tariff
time change event, provisioned as all other TTCT events with the specified
TODA time. It is handled differently so that a partial record may be created
regardless of the number of containers.
When this attribute is enabled, a Specific Daily S-CDR partial record will be
created for each open S-CDR at the time of day specified in the
dailyPartialTimeOfDay attribute. The partial record will be generated due to
a specific tariffTimeChangeTrigger event. Only one daily partial record will
be created per session. Record closure reason will be management
intervention.
Default value 0 (disable)
Engineering rule
dailyPartialTimeOfDay
Description (New in PC04: A00004239) This attribute specifies which
TODA event is to be used as the Specific Daily S-CDR partial event if the
Specific Daily S-CDR Partial is enabled.
A check on activation will be provided so that the Specific Daily S-CDR time
of day is one of the available TODA events provisioned and that the TTCT
feature (U/SGSN tariffTimeChangeTrigger attribute) is enabled.
Range value Time
Default value N/A

Engineering rule
asn1FileGeneration
Description (New in PC04: A00006625) and it enables or disables ASN.1
formatted billing file generation by setting its value to “enabled” or
“disabled”.
Range value enable, disable
Default value disable
Recommended value disable
Engineering rule Since all of the CDL changes are preparation for the future
feature, this attribute is designed as “disabled” all the time until the whole
feature is completed. The intention of provisioning this attribute to “enabled”
will fail.
PC04: SNR (Seamless National Roaming) provisionable attributes

Figure C-8
SNR provisionable attributes
CAS ROOT
sgsn *
equivalentPlmn subscriberClass mcc

mnc imsiMask
lac imsiMask
New components
rac imsiMask
Modified components
* Required components
The following are new or modified SNR(A00000281) attributes under the

“Sgsn EquivalentPlmn/n” component.
Obsoleted Parameters: “MCC” and “MNC” were obsoleted in PC04 since it

will be covered by the PlmnList.

rejectCause
Description This provisionable attribute is a cause value for rejecting the
mobile. Disabled indicates that this mobile will not get a reject cause
returned and can proceed to use the SGSN.
Response: RejectCauseOutOfSet
This is a warning that shall be issued if it is not in the set of SnrCauseCodes.

This set is the set of GSM24.008 specification defined GPRS cause codes
which are location or IMSI based causes.
Range value Decimal: disabled, 1..255
Default value disabled = 0
Recommended value Customer dependent
Engineering rule The reject may be set to any number from 0 – 255, but a
check prov warning will result if it is not in the set to a number in the set of
snrCauseCodes {0, 7, 8, 11, 12, 13, 14, 15}.
linkToEquivalentPlmn
Description This provisionable attribute is a link to the Equivalent Plmn
component. This link is not mandatory to be filled because the default
EplmnList would be used in that case. However, an error shall be given if an
Equivalent Plmn that is entered does not exist. The full path of the
EquivalentPlmn component must be entered for the link to work.
Range value N/A
Default value null
Engineering rule This attribute is ignored if the rejectCause is set to a non-

zero value.
The linkToEplmn can only be set to an existing equivalentPlmn component.
If the linkToEplmn is not set then it defaults to Null in which case the 1’st
instance of the EquivalentPlmn component shall be used and its Eplmn list
shall be sent to the mobile.
If the linkToEplmn is left to default to Null and if no 1’st instance of the

EquivalentPlmn component has been provisioned, then no Eplmn list shall be
sent to the mobile.

snrApnOperatorId
Description This provisionable attribute specifies the APN Operator
Identifier provisioned for SNR. Its structure is a string of three labels
separated by periods. The validateApnOperatorId check escape shall be used
to check the proper syntax.
Range value String(1..37, ASCII)
Default value null
Engineering rule This attribute is ignored if the rejectCause is set to a non-

zero value.
The apnoi may contain up to 37 characters indicating the GGSN the mobile
may be connected to.
The apnoi may be left un-set in which case the default behavior for GGSN
selection would take place.
qosEquivalency
Description This provisionable attribute specifies the Equivalent Quality of
Service that a roaming mobile may receive due to SNR.
The qosEq defaults to roamer, but may be set to homer in order to indicate
that homer QoS shall be negotiated for PDP Contexts activated by this mobile
Range value 0..1 (roamer= roamer_c/0, homer= homer_c/1)
Default value roamer
Engineering rule
The following are new components under “Sgsn MCC/x MNC/y LAC/z
RAC/t” for the SNR feature. It can appear under MNC, LAC, or RAC.
Sgsn MCC/x MNC/y ImsiMask/mask

Description Added this component to provide up to 200 masks on the Sgsn.
This mask instance value specifies a string of BCD digits including wildcard
“?” digits.
The CRDna syntax check prohibits wildcards to the right of a mask, and it
also prevents default masks from containing more than one wildcard.

Duplicate masks within the component containing this imsiMask shall be

prevented.
Response: ImsiMaskLimitPerSgsn
Warning: The limit of 200 imsiMask components per Sgsn has been
exceeded.
The following shows an example of how to create an ImsiMask component:
Add sgsn mcc/123 mnc/456 imsiMask/123??6
Range value N/A
Default value Null
Engineering rule The imsiMask instances must not end with a wildcard “?”
character.
The imsiMask instance representing the default mask must contain only one
wildcard.
Multiple imsiMasks may be provisioned on the MNC, LAC, or the RAC

components.
The imsiMask instances must be unique intra- parent component.
PC04: Secondary PDP provisionable attributes

The following are new attributes for secondary PDP (A00000176) under the
“Gsc/n” component.
Gsc/n secondaryPdpContext
Description This attribute specifies whether secondary Packet Data Protocol
(PDP) context functionality is disabled or enabled. If the value of this
attribute is disabled, then requests for secondary PDP context activations will
be rejected using the ACTIVATE SECONDARY PDP CONTEXT REJECT
message. This event is indicated by the msSecActServiceOpNotSupported
attribute of the GprsSessionManagement component. Additionally, if the
value of this attribute is disabled, then secondary PDP contexts transferred to
this Gsc component as part of Inter Routing Area Update (IRAU) will be
immediately deactivated. This event is indicated by the
newSgsnInvalidPdpCtxtsDropped attribute of the GprsSessionManagement
component. Changing the value of this attribute from enabled to disabled will
cause loss of service for subscribers currently served by this Gsc component.

Range value disabled - enabled.
Engineering rule IPv6 PDP Type is not supported by this feature
There is a memory impact (dependent on the % of subs utilizing the

secondary PDP). Perform capacity study to see true impact to the specific
customer call model.
PC04: Overload control

(A00002494) The goal of the “SGSN Message Overload Controls” (SMOC)
feature is to provide a suitable mechanism to handle message overload
conditions caused by message request rates that are higher than the rates that
the SGSN is engineered to handle. These conditions can potentially be
triggered by - high Attach or RAU Request traffic, bulk Update GPRS
Location (UGL) requests following an HLR-Reset, bulk location update
requests triggered by IntraSGSN RAU traffic, bulk MS-ACTIVITY-
INDICATION requests following an HLR-Reset. Such conditions may often
trigger resource problems in the message signaling path at the USC/GSC
card or TCAP card such as exhaustion of MAP Client or MAP Stack
transaction buffers, or congestion of SS7 links at the SIG.
Table C-16 shows the recommended overload control settings from the PC04
Capacity Report.
Table C-16
Recommended overload control settings
Overload Parameter Default Settings
GSC
sigCongestionMark 3 3
sigCongestionCycleDuration 1 1
maxRateAllowedForAttach 40 40
maxRateAllowedForIrau 25 25
maxRateAllowedForHlrResetUgl 25 25
maxRateAllowedForInitialDp 20 20
—sheet 1 of 2—

Table C-16
Recommended overload control settings (continued)
Overload Parameter Default Settings
maxMapcBufferForAttach 40 40
maxMapcBufferForIrau 50 50
maxMapcBufferForHlrResetUgl 35 35
maxRateAllowedForMofsm 11 11
maxRateAllowedForMtfsm 11 11
maxRateAllowedForBssapLocUpdt 30 30
maxRateAllowedForBssapMsActInd 30 30
maxMapcBufferAllowedForMofsm 60% 60%
maxMapcBufferAllowedForMtfsm 60% 60%
MAP
maxRateAllowedForSai 90 90
maxRateAllowedForMtfsm 38 38
MAP (continued)
maxRateAllowedForNonSaiMapcMsg 900 900
maxTransBufferForSai 40% 40%
maxTransBufferForMtfsm 40% 30%

—sheet 2 of 2—
clearAlarmDelay
Description This attribute specifies the time delay to clear an overload alarm
for a message overload condition when that condition is no longer occurring.
This attribute should be set to the same value throughout all OverloadControl
components. The parameter under the TCAP and GSC OC components
should match.
Range value 1 – 300 seconds.
Default value 30

Engineering rule
sigCongestionMark
Description This attribute specifies the number of Notice Indication
messages per second received from the SS7/IP Gateway (SIG) with
"NetworkCongestion" or "NetworkFailure" causes in order to determine that
the SIG is congested in the UMTS Subscriber Control (USC) and GPRS
Subscriber Control (GSC) applications. SIG congestion is used in
determining the message overload conditions.This attribute should be set to
the same value throughout all OverloadControl components used by the
UMTS Subscriber Control (USC) and GPRS Subscriber Control (GSC)
applications. For example, if more than 20 Notice Indication messages with
the above causes are received per second and this attribute is set to 20, the
SIG is marked as congested.
Default value 20
Recommended value See Table C-16.
Engineering rule
sigCongestionCycleDuration
Description This attribute specifies the time duration for counting the Notice
Indication messages received from the SS7/IP Gateway (SIG) in the UMTS
Subscriber Control (USC) and GPRS Subscriber Control (GSC) applications.
This attribute should be set to the same value throughout all OverloadControl
components used by the UMTS Subscriber Control (USC) and GPRS
Subscriber Control (GSC) applications. For example, if this attribute is set to
1 second, the internal data used to account for the SIG congestion is reset
every second.
Default value 1
Engineering rule
maxRateAllowedForAttach
Description This attribute specifies the maximum number of Attach Request
messages per second allowed to be processed in the UMTS Subscriber
Control (USC) and GPRS Subscriber Control (GSC) applications. This

attribute is used in conjunction with SS7/IP Gateway (SIG) congestion to

determine message overload conditions. For example, if this attribute is set to
30, then the 31st Attach Request messages received within the same second
will be dropped.
Range value 1 – 5000 (decimal).
Default value 30
Engineering rule
maxRateAllowedForIrau
Description This attribute specifies the maximum number of Inter-SGSN
Routing Area Update (IRAU) Request messages per second allowed to be
processed in the UMTS Subscriber Control (USC) and GPRS Subscriber
Control (GSC) applications. This attribute is used in conjunction with SS7/IP
Gateway (SIG) congestion to determine message overload conditions.For
example, if this attribute is set to 30, then the 31st IRAU Request message
received within the same second will be dropped.
Default value 38
Engineering rule
maxRateAllowedForHlrResetUgl
Description This attribute specifies the maximum number of Home Location
Register (HLR) Reset triggered Update GPRS Location (UGL) messages per
second allowed to be processed in the UMTS Subscriber Control (USC) and
GPRS Subscriber Control (GSC) applications. This attribute is used in
conjunction with SS7/IP Gateway (SIG) congestion to determine message
overload conditions.For example, if this attribute is set to 30, then the 31st
HLR Reset triggered UGL message received within the same second will be
dropped.
Default value 20
Engineering rule

maxRateAllowedForInitialDp
Description This attribute specifies the maximum number of Customized
Application for Mobile network Enhanced Logic (CAMEL) InitialDPGPRS
messages per second allowed to be processed in the UMTS Subscriber
Control (USC) and GPRS Subscriber Control (GSC) applications.This
attribute is used in conjunction with SS7/IP Gateway (SIG) congestion to
determine message overload conditions.For example, if this attribute is set to
30, then the 31st CAMEL InitialDPGPRS message to be sent within the same
second will be dropped.
Default value 20
Engineering rule
maxMapcBufferForAttach
Description This attribute specifies the maximum percentage of MapClient
transaction buffers currently in use in determining if an Attach Request
message can be processed in the UMTS Subscriber Control (USC) and GPRS
Subscriber Control (GSC) applications. For example, if this attribute is set to
30% and the current usage of MapClient transaction buffers has reached 30%,
then the next Attach Request received will be dropped.
Default value 30
Recommended value See table Table C-16.
Engineering rule
maxMapcBufferForIrau
transaction buffers currently in use in determining if an Inter-SGSN Routing
Area Update (IRAU) Request and the other message can be processed in the
UMTS Subscriber Control (USC) and GPRS Subscriber Control (GSC)
applications. For example, if this attribute is set to 30% and the current usage
of MapClient transaction buffers has reached 30%, then the next IRAU
Request message received will be dropped.
Default value 30

Recommended value See table
Engineering rule
maxMapcBufferForHlrResetUgl
transaction buffers currently in use in determining if an Home Location
Register (HLR) Reset triggered Update GPRS Location (UGL) message can
be processed in the UMTS Subscriber Control (USC) and GPRS Subscriber
Control (GSC) applications. For example, if this attribute is set to 30% and
the current usage of MapClient transaction buffers has reached 30%, then the
next HLR Reset triggered UGL message received will be dropped.
Default value 25
Engineering rule
maxRateAllowedForMofsm
Originated Forward Short Messages (MOFSMs) per second allowed to be
processed by the GPRS Subscriber Control application. This attribute is used
in conjunction with SS7/IP Gateway congestion to determine message
MOFSM received within the same second will be dropped.
Range value 1 – 5000 (decimal; messages/sec).
Default value 11
Engineering rule
maxRateAllowedForMtfsm
Terminated Forward Short Messages (MTFSMs) per second allowed to be
processed by the GPRS Subscriber Control application.This attribute is used
in conjunction with SS7/IP Gateway congestion to determine message
MTFSM received within the same second will be dropped.

Default value 11
Engineering rule
maxRateAllowedForBssapLocUpdt
Description This attribute specifies the maximum number of Base Station
Subsystem Application Part (BSSAP)+ Location Update (BLU) messages per
second allowed to be processed by the GPRS Subscriber Control application.
This attribute is used in conjunction with SS7/IP Gateway congestion to
determine message overload conditions.For example, if this attribute is set to
30, then the 31st BLU message received within the same second will be
rejected.
Default value 50
Engineering rule
maxRateAllowedForBssapMsActInd
Description This attribute specifies the maximum number of Base Station
Subsystem Application Part (BSSAP)+ MS-Activity-Indication (BMAI)
messages per second allowed to be processed by the GPRS Subscriber
Control application This attribute is used in conjunction with SS7/IP Gateway
congestion to determine message overload conditions.For example, if this
attribute is set to 30, then the 31st BMAI message received within the same
second will be dropped.
Default value 50
Engineering rule
maxMapcBufferAllowedForMofsm
transaction buffers currently in use to determine if an Mobile Originated
Forward Short Message (MOFSM) and the other messages can be processed
by the GPRS Subscriber Control application. For example, if this attribute is
set to 30% and the current usage of MapClient transaction buffers has reached
30%, then the next MOFSM received will be dropped.

Range value Decimal (0..100 %).
Default value 60
Engineering rule
maxMapcBufferAllowedForMtfsm
transaction buffers currently in use to determine if an Mobile Terminated
Forward Short Message (MTFSM) and the other messages can be processed
by the GPRS Subscriber Control application. For example, if this attribute is
set to 30% and the current usage of MapClient transaction buffers has reached
30%, then the next MTFSM received will be dropped.
Range value Decimal (0..100 %).
Default value 60
Engineering rule
The following are new attributes under the new “TCAP/n oc” component.
maxRateAllowedForSai
Description This attribute specifies the maximum number of Send
Authentication Info (SAI) messages per second allowed to be processed in the
TcapStack application. For example, if this attribute is set to 30, then the 31st
SAI message received within the same second will be dropped.
Range value 1 – 5000 msg/seconds.
Default value 90
Engineering rule
maxRateAllowedForMtfsm
Terminated Forward Short Messages (MTFSMs) per second allowed to be
processed in the TcapStack application. For example, if this attribute is set to
30, then the 31st MTFSM received within the same second will be dropped.

Default value 38
Engineering rule
maxRateAllowedForNonSaiMsg
Description This attribute specifies the maximum number of Non-Send
Authentication Info (Non-SAI) messages per second allowed to be processed
in the TcapStack application. For example, if this attribute is set to 30, then
the 31st Non-SAI message received within the same second will be dropped.
Default value 900
Engineering rule
maxTransBufferForSai
Description This attribute specifies the maximum percentage of Mobile
Application Part (MAP) transaction buffers currently in use in determining if
a Send Authentication Info (SAI) and the other messages can be processed in
the TcapStack application. For example, if this attribute is set to 30% and the
current usage of MAP transaction buffers has reached 30%, then the next SAI
message received will be dropped.
Range value 1 – 100 % (Decimal)
Default value 40%
Engineering rule
maxTransBufferForMtfsm
Description This attribute specifies the maximum percentage of Mobile
Application Part (MAP) transaction buffers currently in use in determining if
an Mobile Terminated Forward Short Messages (MTFSMs) and the other
messages can be processed in the TcapStack application. For example, if this
attribute is set to 30% and the current usage of MAP transaction buffers has
reached 30%, then the next MTFSM received will be dropped.
Range value 1 – 100 % (Decimal)
Default value 30%

Engineering rule


D-1
Single slot 32-Port MSA cabling D

32-port DS1 MSA 1-slot function processors
The 32-port DS1 for multi-service access (MSA) function processor (FP)
occupies one slot of a shelf assembly. The product engineering code (PEC) of
the available DS1 MSA32 1-slot FP is:
• NTNQ94AA for the 32-port DS1 MSA 1-slot with the older framer chip
for any PCR software
Note: Only the AA vintage may be used with PCR5.2 (PC04); the BA
vintage with support for a new framer chip may not be used with PCR5.2
(PC04).
The software card type for an NTNQ94 is 32pDs1Msa, which is the same for
its 2-slot equivalent version (NTNQ74). The software configuration
information for these FPs is in NN10600-551, Nortel Networks Multiservice
Switch 7400/15000/20000 FP Configuration Reference.
The 1-slot FPs are the non-optical versions of the MSA32 FPs, and do not
have a monitor port on the faceplate.
The typical power consumption of an NTNQ94 is 43 watts while the

maximum is 62.5 watts.
The following apply only to the 1-slot MSA32 FPs unless otherwise specified.
• “Faceplate of a 32-port DS1 MSA 1-slot FP with PEC NTNQ94” on page
D-3
• “32-port DS1 MSA 1-slot and 2-slot FP replacements” on page D-3
• “32-port DS1 MSA 1-slot and 2-slot FP sparing combinations” on page
D-4
• “32-port DS1 MSA termination panels for 1-slot FPs” on page D-5
• “32-port DS1 MSA prefabricated cable assemblies for FPs and sparing
panels” on page D-5

D-2 Single slot 32-Port MSA cabling
• “32-port DS1 MSA custom-made cable assemblies for FPs and sparing
• “32-port DS1 MSA 1-slot FP pinouts” on page D-14
• “32-port DS1 MSA termination panel pinouts for CPE connections” on
page D-20
32-port DS1 MSA 1-slot faceplate

A 32-port DS1 MSA 1-slot FP occupies one slot in a shelf assembly. (The
software checks whether a 1-slot or a 2-slot FP is present so that sparing can
be accommodated between the two sizes of FPs.) See the figure “Faceplate of
a 32-port DS1 MSA 1-slot FP with PEC NTNQ94” on page D-3. Although
the 1-slot and 2-slot MSA32 FPs have the same functionality, the 1-slot FP
has two 68-pin SCSI 2x34 female D-sub connectors instead of the 44-pin
high-density female D-sub connectors of the 2-slot faceplate. The pinouts are
identified in “32-port DS1 MSA 1-slot FP pinouts” on page D-14.

Figure D-1
Faceplate of a 32-port DS1 MSA 1-slot FP with PEC NTNQ94
EMI gasket
68 34
P0
Ports 0 to 15
35 1
68-pin SCSI 2 x 34
female D-sub connector
P1 Pin numbering
Ports 16 to 31 scheme
68-pin SCSI 2x34

LED status indicator female D-sub connector
Latch lock
Card latch
MSS 3519 002 AA2
32-port DS1 MSA 1-slot and 2-slot FP replacements

A 32-port DS1 MSA 1-slot FP can replace an equivalent 2-slot FP under
specific circumstances, and vice versa. The PECs and circumstances are
identified in the table “Compatible replacements for equivalent DS1 MSA
1-slot and 2-slot FPs” on page D-4.

Table D-1
Compatible replacements for equivalent DS1 MSA 1-slot and 2-slot FPs
PECs of PECs of Circumstance to enable replacing the FP
FPs to be replacement
replaced FPs
NTNQ74 NTNQ74 normal
(2-slot)
NTNQ94AA normal, and an FP slot becomes available
NTNQ94BA provided the node is running PCR 6.1 or later

software, and an FP slot becomes available
NTNQ94Ax NTNQ94Ax normal
(1-slot)
NTNQ94Bx provided the node is running PCR 6.1 or later
software
NTNQ74 provided the adjacent slot to the right of the

NTNQ94 is available and, if part of a sparing
configuration, the adjacent slot has an even number
NTNQ94Bx NTNQ94Bx normal
(1-slot)
Note: The value of x is any letter in that PEC vintage.
32-port DS1 MSA 1-slot and 2-slot FP sparing combinations

The possible combinations of all 32-port DS1 1-slot and 2-slot FPs in sparing
configurations are shown in the table “Sparing combinations of DS1 MSA
FPs and sparing panels” on page D-5. The combination shows DS1 FPs that
are 1-slot or 2-slot with or without the optical ports in the same sparing
configuration.

Table D-2
Sparing combinations of DS1 MSA FPs and sparing panels
Spare FP Main FPs Sparing panels
DS1 NTNQ74 (2-slot) one or any combination up to six of the following: NTJS95,
NTNQ74 without optical ports (2-slot) NTY195, or
NTNQ76 multimode with optical ports (2-slot) NTY197
NTNQ78 single-mode with optical ports (2-slot)
NTNQ94 without optical ports (1-slot)
32-port DS1 MSA termination panels for 1-slot FPs

The 32-port DS1 MSA 1-slot (or 2-slot) FPs use the termination panels that
fan out customer equipment connections so that each DS1 port has its own
termination point and access.
The MSA32 DS1 or E1 termination panels also support either one-for-one

sparing or up to one-for-six sparing for the electrical ports on the MSA32
FPs. Depending on the type of panel, one panel is needed for each FP and up
to six panels can be interconnected to use one spare FP. The setup involves up
to six main FPs and one spare FP.
32-port DS1 MSA prefabricated cable assemblies for FPs and sparing
panels
The prefabricated cable assemblies for one or more 32-port DS1 MSA 1-slot
or 2-slot FPs and their sparing panels provide:
• interfacing between the sparing panel and its FPs, both the mains and the
spare
• inter-panel connections in a one-for-n (1:n) sparing configuration that is
not one-for-one (1:1) for MSA32

• interfacing between the sparing panel and intra-office equipment such as

CSUs or DSXs
The FP interface and inter-panel cables are manufactured by Nortel Networks

in fixed lengths with the appropriate connectors.
Inter-panel connections for one-for-n sparing configurations require flexi-

cables for linking the panels together. The product engineering codes (PECs)
for the flexi-cables are in the table “PECs of the MSA32 DS1 flexi-cables
between sparing panels” on page D-6 and the cable assemblies are shown in
these figures:
• “Inter-panel flexi-cable NTJS99 for MSA32 sparing panels with RJ-45

connectors” on page D-7
• “Inter-panel flexi-cable NTY199AB for MSA32 sparing panels with
DB15 connectors” on page D-8
Table D-3
PECs of the MSA32 DS1 flexi-cables between sparing panels
PEC Type of sparing panel
NTJS99 RJ-45
NTY199AA DB15 1-port, DB15 2-port
NTY199AB DB15 1-port, DB15 2-port with shorter flexi-cables

Figure D-2
Inter-panel flexi-cable NTJS99 for MSA32 sparing panels with RJ-45 connectors
For studs or hex

Sliding latch
fasteners to screw
into the alignment
posts
Fits over
alignment posts
PPT 2947 002 AA

Figure D-3
Inter-panel flexi-cable NTY199AB for MSA32 sparing panels with DB15 connectors
Sliding latch
Ribbon cable
PPT 3330 001 AA
The available MSA32 FP interface cables are listed in the table “PECs of the
MSA32 DS1 interface fanout cables from FP to sparing panel” on page D-8.
In addition to providing connectivity for the DS1 ports, each MSA32 FP
interface cable also integrates sparing panel control lines. Each cable also
provides ferrite shielding in the connector shrouds, and is automatically
grounded when connected securely to Multiservice Switch equipment.
Table D-4
PECs of the MSA32 DS1 interface fanout cables from FP to sparing panel
Cable Connector at FP Connector at panel end Cable length DS1 FPs Panel
PECs end PECs
NTPS03 angled 44-pin high- straight 44-pin high- 3 m (9.8 ft) NTNQ74 NTJS95
density male D-sub density female D-sub NTNQ76 NTY195
NTNQ78 NTY196
NTY197
NTNQ78 NTY196
NTY197
—sheet 1 of 2—

Table D-4
PECs of the MSA32 DS1 interface fanout cables from FP to sparing panel (continued)
Cable Connector at FP Connector at panel end Cable length DS1 FPs Panel
PECs end PECs
NTPS32 angled 68-pin SCSI split into two straight 3 m (9.8 ft) NTNQ93 NTJS95
2x34 male D-sub 44-pin high-density female NTNQ94 NTY195
D-sub NTY196
NTY197
D-sub NTY196
NTY197
2x34 male D-sub 44-pin high-density female NTNQ94 converted
D-sub with sliding latch (or to sliding
locking clip) latch
D-subs
locking clip) latch
D-subs
D-subs; NTY196
mainly intended to connect NTY197
to previously installed
NTPS03 or NTPS04
cables
—sheet 2 of 2—
The fanout cables for the NTNQ93 and NTNQ94 FPs are shown in the
following figures:
• “Fanout cable NTPS32 or NTPS33 for a 32-port DS1 MSA 1-slot FP” on
page D-10
• “Fanout cable NTPS36 or NTPS37 with sliding latch D-subs for a 32-port
DS1 MSA 1-slot FP” on page D-11
• “Fanout cable adapter NTPS39 for connecting a 1-slot FP to 2-slot cables
NTPS03 or NTPS04” on page D-12
The prefabricated fanout cable that connects to a cable adapter NTPS39 for
use with the 1-slot FPs is shown in the figure “Fanout cable adapter NTPS39
for connecting a 1-slot FP to 2-slot cables NTPS03 or NTPS04” on page D-
12.

Figure D-4
Fanout cable NTPS32 or NTPS33 for a 32-port DS1 MSA 1-slot FP
3 m or 15 m
(9.9 ft or 49.2 ft) For an FP or a
termination panel
Label with
For the FP part number
P0 or P1
44-pin high-density
male D-sub connector
68-pin SCSI 2x34

male D-sub connector D-sub fastening screw
MSS 3519 003 AA2

Figure D-5
Fanout cable NTPS36 or NTPS37 with sliding latch D-subs for a 32-port DS1 MSA 1-slot FP
3 m or 15 m
termination panel
Label with
P0 or P1
44-pin high-density
with sliding latch
68-pin SCSI 2x34

male D-sub connector Sliding latch
of D-sub connector
MSS 3519 004 AA2

Figure D-6
Fanout cable adapter NTPS39 for connecting a 1-slot FP to 2-slot cables NTPS03 or NTPS04
1 m (9.9 ft)
Label with
For the part number
FP cable
44-pin high-density
68-pin SCSI 2x34

MSS 3519 005 AA2

Figure D-7
Fanout cable NTPS03 or NTPS04 to connect to an adapter cable NTPS39 of a DS1 1-slot FP
For the FP For an FP or a

termination panel
3 m or 15 m
(9.9 ft or 49.2 ft)
Label with
part number
D-sub fastening
screw
44-pin high-density
PPT 3530 001 AA
32-port DS1 MSA custom-made cable assemblies for FPs and sparing
panels
The specifications to custom make your own 32-port DS1 MSA cable
assemblies to connect an FP to a sparing panel are as follows:
• The maximum cable length for DS1 lines to customer equipment is 340 m
(1100 ft). The distance between the FP and the termination panel is part of
the total length.
• Use AWG No. 28 (0.32 mm), 100 ohm shielded, twisted pair cables.
• The insertion loss of each pair must not exceed 6 dB measured at
1024 kHz. Insertion loss is proportional to cable length and varies among
types of cables.
• The types of cable connectors are shown in these figures:
— “Fanout cable NTPS32 or NTPS33 for a 32-port DS1 MSA 1-slot FP”
on page D-10
— “Fanout cable NTPS36 or NTPS37 with sliding latch D-subs for a
32-port DS1 MSA 1-slot FP” on page D-11
— “Fanout cable adapter NTPS39 for connecting a 1-slot FP to 2-slot
cables NTPS03 or NTPS04” on page D-12

• For a 1-slot FP, use the connector pinouts in “32-port DS1 MSA 1-slot FP
pinouts” on page D-14.
32-port DS1 MSA 1-slot FP pinouts
When connecting directly from a 32-port DS1 MSA 1-slot FP to customer
premises equipment (CPE), in effect bypassing the MSA32 termination
panels or not using the prefabricated Nortel Networks cables, the CPE cabling
must be adapted to the FP’s 68-pin D-sub faceplate pinouts. Refer to the
figure “Faceplate of a 32-port DS1 MSA 1-slot FP with PEC NTNQ94” on
page D-3.
The 1-slot NTNQ94 FP has higher density D-sub connectors on its faceplate
than the 2-slot NTNQ74 FP, but both FPs connect to the same types of
termination or sparing panels. To accommodate the different numbers of pins
in the connectors, prefabricated fanout cables and a fanout cable adapter are
available from Nortel Networks for the 1-slot FPs. Each fanout cable can be
used at either the P0 or P1 sets of ports at the FP. The cables are identified and
shown in “32-port DS1 MSA prefabricated cable assemblies for FPs and
sparing panels” on page D-5.
The relationship of FP and split cable connectors is identified in the table

“Mapping of MSA 1-slot FP port numbers to fanout cable connectors” on
page D-14.
Table D-5
Mapping of MSA 1-slot FP port numbers to fanout cable connectors
FP 68-pin Fanout cable 44-pin Fanout cable 44-pin
connector labels connector labeled P0/P2 connector labeled P1/P3
P0 when connected to MSA when connected to MSA
has ports 0 to 15 termination or sparing panel termination or sparing panel
P0, has ports 0 to 7 P1, has ports 8 to 15
P2, has ports 16 to 23 P3, has ports 24 to 31 and
operational signals
The following tables identify the 1-slot FP 68-pin and termination panel 44-pin
connector pinouts:
• “DS1 MSA 1-slot FP connector pinouts for P0 ports 0 to 7 and P1 ports
16 to 23” on page D-15
• “32-port DS1 MSA 1-slot FP connector pinouts for P0 ports 8 to 15 and
P1 ports 24 to 31” on page D-17

Table D-6
DS1 MSA 1-slot FP connector pinouts for P0 ports 0 to 7 and P1 ports 16 to 23
FP pin numbers of a 68-pin Signal name at Signal name at
connector FP P0 FP P1
57 port 0 Tx + port 16 Tx +
33 port 0 Tx - port 16 Tx -
66 port 0 Rx + port 16 Rx +
32 port 0 Rx - port 16 Rx -
—sheet 1 of 2—

Table D-6
—sheet 2 of 2—
Table D-7
FP pin numbers of a Signal name Signal name at Sparing panel pin
68-pin connector at FP P1 numbers of a 44-pin
FP P0 connector
57 port 0 Tx + port 16 Tx + 39
33 port 0 Tx - port 16 Tx - 9
66 port 0 Rx + port 16 Rx + 25
32 port 0 Rx - port 16 Rx - 10
—sheet 1 of 2—

Table D-7
FP pin numbers of a Signal name Signal name at Sparing panel pin
68-pin connector at FP P1 numbers of a 44-pin
FP P0 connector
—sheet 2 of 2—
Table D-8
32-port DS1 MSA 1-slot FP connector pinouts for P0 ports 8 to 15 and P1 ports
24 to 31
FP pin numbers of 68-pin Signal name at Signal name at
—sheet 1 of 2—

Table D-8
24 to 31 (continued)
FP pin numbers of 68-pin Signal name at Signal name at
34 --------- FP_CLOCK
68 --------- FP_DATA
1 --------- 12V_PROT
35 --------- ground
shield frame ground frame ground
—sheet 2 of 2—

Table D-9
24 to 31
FP pin numbers of Signal name Signal name Sparing panel pin
68-pin connector at at numbers of 44-pin
FP P0 FP P1 connector
47 port 10 Tx + port 26 Tx + 42
13 port 10 Tx - port 26 Tx - 28
46 port 10 Rx + port 26 Rx + 13
12 port 10 Rx - port 26 Rx - 43
45 port 11 Tx + port 27 Tx + 30
11 port 11 Tx - port 27 Tx - 15
44 port 11 Rx + port 27 Rx + 14
10 port 11 Rx - port 27 Rx - 44
43 port 12 Tx + port 28 Tx + 32
42 port 12 Rx + port 28 Rx + 33
41 port 13 Tx + port 29 Tx + 20
40 port 13 Rx + port 29 Rx + 34
39 port 14 Tx + port 30 Tx + 21
38 port 14 Rx + port 30 Rx + 36
—sheet 1 of 2—

Table D-9
FP pin numbers of Signal name Signal name Sparing panel pin
68-pin connector at at numbers of 44-pin
FP P0 FP P1 connector
37 port 15 Tx + port 31 Tx + 38
36 port 15 Rx + port 31 Rx + 37
34 FP_CLOCK --------- 1
68 FP_DATA --------- 2
1 12V_PROT --------- 16
35 ground --------- 24
shield frame ground --------- shield
—sheet 2 of 2—
32-port DS1 MSA termination panel pinouts for CPE connections

The pinouts for connecting customer premises equipment (CPE) to a 32-port
DS1 MSA termination panel are identified in the figures:
• “32-port DS1 MSA termination panel pinouts and signal names: 1-port/
DB15” on page D-21
• “32-port DS1 MSA termination panel pinouts and signal names: 2-port/
• “32-port DS1 MSA termination panel pinouts and signal names: RJ-45”
on page D-22

Figure D-8
32-port DS1 MSA termination panel pinouts and signal names: 1-port/DB15
Termination
panel cable Pin Name
1 Receive +
2 Frame Ground
8 3 Transmit +
15
7 4 Frame Ground
14 9 Receive -
6 11 Transmit -
13
5
12
4
11 Tx Pair
3
10 To customer
2
9 Rx Pair
1
Pinouts for each of the 32 ports follow the pattern shown in the figure
“32-port DS1 MSA termination panel pinouts and signal names: 1-port/
DB15” on page D-21.
Figure D-9
32-port DS1 MSA termination panel pinouts and signal names: 2-port/DB15
Termination panel
cable connector Pin Name
1 Port 1 transmit +
2 Port 1 receive +
8 5 Signal ground
15 Port 0 Tx pair 7 Port 0, receive +
7 8 Port 0, transmit +
14 Port 0 Rx pair
9 Port 1, transmit -
6 10 Port 1, receive -
13 12 Frame ground
5
4 15 Port 0, transmit -
11
3
10
2 Port 1 Rx pair
9 To customer equipment
1 Port 1 Tx pair
PPT 2862 001 AB

“32-port DS1 MSA termination panel pinouts and signal names: 2-port/
DB15” on page D-21. All odd-numbered ports (1,3,5,...,31) have identical
pinouts, as do all even-numbered ports (0,2,4,...,30).
Figure D-10
32-port DS1 MSA termination panel pinouts and signal names: RJ-45
RJ-45 connector
12345678 Pin Signal

1 Rx-
2 Rx+
3 Not used
4 Tx-
5 Tx+
6 Not used
7 Not used
8 Not used
PPT 2898 001 AA
“32-port DS1 MSA termination panel pinouts and signal names: RJ-45” on
page D-22.

32-port E1 MSA 1-slot function processors

These sections are for information about the 32-port E1 for multi-service access
(MSA) function processors (FP) that occupy one slot of a shelf assembly. The
product engineering code (PEC) of the available E1 MSA32 1-slot FP is:
• NTNQ93AA for the 32-port E1 MSA 1-slot with the older framer chip for
any PCR software
The software card type for an NTNQ93 is 32pE1Msa, which is the same for
its 2-slot equivalent version (NTNQ73). The software configuration
information for these FPs is in NN10600-551 Nortel Networks Multiservice
Switch 7400/15000/20000 FP Configuration Reference.
The 1-slot FPs are the non-optical versions of the MSA32 FPs, and do not
have a monitor port on the faceplate.
The typical power consumption of an NTNQ93 is 43 watts while the

maximum is 62.5 watts.
The following apply only to the 1-slot MSA32 FPs unless otherwise specified.
• “Faceplate of a 32-port E1 MSA 1-slot FP with PEC NTNQ93” on page
D-24
• “32-port E1 MSA 1-slot and 2-slot FP replacements” on page D-24
• “32-port E1 MSA 1-slot and 2-slot FP sparing combinations” on page D-
25
• “32-port E1 MSA termination panels for 1-slot FPs” on page D-26
• “32-port E1 MSA prefabricated cable assemblies for FPs and sparing
• “32-port E1 MSA custom-made cable assemblies for FPs and sparing
• “32-port E1 MSA 1-slot FP pinouts” on page D-34
• “32-port E1 MSA termination panel pinouts for CPE connections” on
page D-40
32-port E1 MSA 1-slot faceplate

A 32-port E1 MSA 1-slot FP occupies one slots in a shelf assembly. (The
software checks whether a 1-slot or a 2-slot FP is present so that sparing can
be accommodated between the two sizes of FPs.) See the figure “Faceplate of
a 32-port E1 MSA 1-slot FP with PEC NTNQ93” on page D-24. Although the
1-slot and 2-slot MSA32 FPs have the same functionality, the 1-slot FP has
two 68-pin SCSI 2x34 female D-sub connectors instead of the 44-pin high-
density female D-sub connectors of the 2-slot faceplate. The pinouts are
identified in “32-port E1 MSA 1-slot FP pinouts” on page D-34.

Figure D-11
Faceplate of a 32-port E1 MSA 1-slot FP with PEC NTNQ93
EMI gasket
68 34
P0
Ports 0 to 15
35 1
68-pin SCSI 2 x 34
P1 Pin numbering
Ports 16 to 31 scheme
68-pin SCSI 2x34

LED status indicator female D-sub connector
Latch lock
Card latch
MSS 3519 002 AA2
32-port E1 MSA 1-slot and 2-slot FP replacements

A 32-port E1 MSA 1-slot FP can replace an equivalent 2-slot FP under
specific circumstances, and vice versa. The PECs and circumstances are
identified in the table “Compatible replacements for equivalent E1 MSA
1-slot and 2-slot FPs” on page D-25.

Table D-10
Compatible replacements for equivalent E1 MSA 1-slot and 2-slot FPs
PECs of PECs of Circumstance to enable replacing the FP
FPs to be replacement
replaced FPs
NTNQ69 NTNQ69 normal
(2-slot)
NTNQ93AA normal, and an FP slot becomes available
NTNQ93Ax NTNQ93Ax normal
(1-slot)
NTNQ93Bx provided the node is running PCR 6.1 or later
software
NTNQ69 provided the adjacent slot to the right of the

NTNQ93 is available and, if part of a sparing
configuration, the adjacent slot has an even number
NTNQ93Bx NTNQ93Bx normal
(1-slot)
Note: The value of x is any letter in that PEC vintage.
32-port E1 MSA 1-slot and 2-slot FP sparing combinations

The possible combinations of all 32-port E1 1-slot and 2-slot FPs in sparing
configurations are shown in the table “Sparing combinations of E1 MSA FPs
and sparing panels” on page D-25. The combination shows E1 FPs that are
1-slot or 2-slot with or without the optical ports in the same sparing
configuration.
Table D-11
Sparing combinations of E1 MSA FPs and sparing panels
E1 NTNQ69 (2-slot) one or any combination up to six of the following: NTJS95,
NTNQ69 without optical ports (2-slot) NTY195,
NTNQ71 multimode with optical ports (2-slot) NTY196 or
NTNQ73 single-mode with optical ports (2-slot) NTY197
—sheet 1 of 2—

Table D-11
Sparing combinations of E1 MSA FPs and sparing panels (continued)
—sheet 2 of 2—
32-port E1 MSA termination panels for 1-slot FPs

The 32-port E1 MSA 1-slot (or 2-slot) FPs use the termination panels that fan
out customer equipment connections so that each E1 port has its own
termination point and access.
The MSA32 E1 or E1 termination panels also support either one-for-one

sparing or up to one-for-six sparing for the electrical ports on the MSA32
FPs. Depending on the type of panel, one panel is needed for each FP and up
to six panels can be interconnected to use one spare FP. The setup involves up
to six Main FPs and one Spare FP.
32-port E1 MSA prefabricated cable assemblies for FPs and sparing

panels
The prefabricated cable assemblies for one or more 32-port E1 MSA 1-slot or
2-slot FPs and their sparing panels provide:
• interfacing between the sparing panel and its FPs, both the mains and the
spare
• inter-panel connections in a one-for-n (1:n) sparing configuration that is
not one-for-one (1:1) for MSA32
• interfacing between the sparing panel and intra-office equipment such as
CSUs or DSXs
The FP interface and inter-panel cables are manufactured by Nortel Networks

in fixed lengths with the appropriate connectors.

Inter-panel connections for one-for-n sparing configurations require

flexi-cables for linking the panels together. The product engineering codes
(PECs) for the flexi-cables are in the table “PECs of the MSA32 E1 flexi-cables
between sparing panels” on page D-27 and the cable assemblies are shown in
the figures:
• “Inter-panel flexi-cable NTJS99 for MSA32 sparing panels with RJ-45
connectors” on page D-27
• “Inter-panel flexi-cable NTY199AB for MSA32 sparing panels with
BNC or DB15 connectors” on page D-28
Table D-12
PECs of the MSA32 E1 flexi-cables between sparing panels
PEC Type of sparing panel

NTJS99 RJ-45
NTY199AA BNC, DB15 1-port, DB15 2-port
NTY199AB BNC, DB15 1-port, DB15 2-port with shorter flexi-cables and
optionally used with a cable cover NTPS07
Figure D-12
Inter-panel flexi-cable NTJS99 for MSA32 sparing panels with RJ-45 connectors
For studs or hex

Sliding latch
fasteners to screw
into the alignment
posts
Fits over
alignment posts
PPT 2947 002 AA

Figure D-13
Inter-panel flexi-cable NTY199AB for MSA32 sparing panels with BNC or DB15 connectors
Sliding latch
Ribbon cable
PPT 3330 001 AA
The E1 MSA32 sparing panels with BNC or DB15 connectors can have an
optional cable cover installed over the inter-panel flexi-cables of a one-for-n
configuration. The cover is identified by PEC NTPS07. The flexi-cable
assembly must be the shorter version identified by NTY199AB or later.
The available MSA32 FP interface cables are listed in the table “PECs of the
MSA32 E1 interface fanout cables from FP to sparing panel” on page D-29.
In addition to providing connectivity for the E1 ports, each MSA32 FP
interface cable also integrates sparing panel control lines. Each cable also
provides ferrite shielding in the connector shrouds, and is automatically
grounded when connected securely to Multiservice Switch equipment.

Table D-13
PECs of the MSA32 E1 interface fanout cables from FP to sparing panel
Cable Connector at FP Connector at panel end Cable length E1 FPs Panel
PECs end PECs
NTNQ73 NTY196
NTY197
NTNQ73 NTY196
NTY197
D-sub NTY196
NTY197
D-sub NTY196
NTY197
locking clip) latch
D-subs
locking clip) latch
D-subs
2x34 female D-sub 44-pin high-density female NTNQ93 NTY195
D-subs; NTY196
mainly intended to connect NTY197
to previously installed
NTPS03 or NTPS04
cables
The fanout cables for the NTNQ93 and NTNQ93 FPs are shown in the
following figures:
• “Fanout cable NTPS32 or NTPS33 for a 32-port E1 MSA 1-slot FP” on
page D-30

• “Fanout cable NTPS36 or NTPS37 with sliding latch D-subs for a 32-port
E1 MSA 1-slot FP” on page D-31
• “Fanout cable adapter NTPS39 for connecting a 1-slot FP to 2-slot cables
NTPS03 or NTPS04” on page D-32
The prefabricated fanout cable that connects to a cable adapter NTPS39 for
use with the 1-slot FPs is shown in the figure “Fanout cable adapter NTPS39
for connecting a 1-slot FP to 2-slot cables NTPS03 or NTPS04” on page D-
32.
Figure D-14
Fanout cable NTPS32 or NTPS33 for a 32-port E1 MSA 1-slot FP
3 m or 15 m
termination panel
Label with
P0 or P1
44-pin high-density
68-pin SCSI 2x34

male D-sub connector D-sub fastening screw
MSS 3519 003 AA2

Figure D-15
Fanout cable NTPS36 or NTPS37 with sliding latch D-subs for a 32-port E1 MSA 1-slot FP
3 m or 15 m
termination panel
Label with
P0 or P1
44-pin high-density
with sliding latch
68-pin SCSI 2x34

male D-sub connector Sliding latch
of D-sub connector
MSS 3519 004 AA2

Figure D-16
Fanout cable adapter NTPS39 for connecting a 1-slot FP to 2-slot cables NTPS03 or NTPS04
1 m (9.9 ft)
Label with
For the part number
FP cable
44-pin high-density
68-pin SCSI 2x34

MSS 3519 005 AA2

Figure D-17
Fanout cable NTPS03 or NTPS04 to connect to an adapter cable NTPS39 of an E1 1-slot FP
For the FP For an FP or a

termination panel
3 m or 15 m
(9.9 ft or 49.2 ft)
Label with
part number
D-sub fastening
screw
44-pin high-density
PPT 3530 001 AA
32-port E1 MSA custom-made cable assemblies for FPs and sparing

panels
The specifications to custom make your own E1 MSA cable assemblies to
connect an FP to a sparing panel are as follows:
• The maximum cable length for E1 lines to customer premises equipment
(CPE) is 230 m (754.6 ft). The distance between the FP and the
termination panel is part of the total length.
• Use AWG No. 28 (0.32 mm), 100 ohm shielded, twisted pair cables.
• The insertion loss of each pair must not exceed 6 dB measured at
1024 kHz. Insertion loss is proportional to cable length and varies among
types of cables.
• The types of cable connectors are shown in these figures:
— “Fanout cable NTPS32 or NTPS33 for a 32-port E1 MSA 1-slot FP”
on page D-30
— “Fanout cable NTPS36 or NTPS37 with sliding latch D-subs for a
32-port E1 MSA 1-slot FP” on page D-31
— “Fanout cable adapter NTPS39 for connecting a 1-slot FP to 2-slot
cables NTPS03 or NTPS04” on page D-32

• For a 1-slot FP, use the connector pinouts in “32-port E1 MSA 1-slot FP
pinouts” on page D-34.
32-port E1 MSA 1-slot FP pinouts
When connecting directly from a 32-port E1 MSA 1-slot FP to customer
premises equipment (CPE), in effect bypassing the MSA32 termination
panels or not using the prefabricated Nortel Networks cables, the CPE cabling
must be adapted to the FP’s 68-pin D-sub faceplate pinouts. Refer to the
figure “Faceplate of a 32-port E1 MSA 1-slot FP with PEC NTNQ93” on
page D-24.
The 1-slot NTNQ93 FP has higher density D-sub connectors on its faceplate
than the 2-slot NTNQ73 FP, but both FPs connect to the same types of
termination or sparing panels. To accommodate the different numbers of pins
in the connectors, prefabricated fanout cables and a fanout cable adapter are
available from Nortel Networks for the 1-slot FPs. Each fanout cable can be
used at either the P0 or P1 sets of ports at the FP. The cables are identified and
shown in “32-port E1 MSA prefabricated cable assemblies for FPs and
sparing panels” on page D-26.
The relationship of FP and split cable connectors is identified in the table

“Mapping of MSA 1-slot FP port numbers to fanout cable connectors” on
page D-34.
Table D-14
Mapping of MSA 1-slot FP port numbers to fanout cable connectors
FP 68-pin Fanout cable 44-pin Fanout cable 44-pin
connector labels connector labeled P0/P2 connector labeled P1/P3
P0, has ports 0 to 7 P1, has ports 8 to 15
P2, has ports 16 to 23 P3, has ports 24 to 31 and
operational signals
The following tables identify the 1-slot FP 68-pin and termination panel 44-pin
connector pinouts:
• “E1 MSA 1-slot FP connector pinouts for P0 ports 0 to 7 and P1 ports 16
to 23” on page D-35
• “32-port E1 MSA 1-slot FP connector pinouts for P0 ports 8 to 15 and P1
ports 24 to 31” on page D-37

Table D-15
E1 MSA 1-slot FP connector pinouts for P0 ports 0 to 7 and P1 ports 16 to 23
connector P0 P1
—sheet 1 of 2—

Table D-15
connector P0 P1
—sheet 2 of 2—
Table D-16
FP pin numbers of a Signal name Signal name Sparing panel pin
68-pin connector at at numbers of a 44-pin
P0 P1 connector
—sheet 1 of 2—

Table D-16
P0 P1 connector
—sheet 2 of 2—
Table D-17
32-port E1 MSA 1-slot FP connector pinouts for P0 ports 8 to 15 and P1 ports
24 to 31
connector P0 P1
—sheet 1 of 2—

Table D-17
connector P0 P1
34 --------- FP_CLOCK
68 --------- FP_DATA
1 --------- 12V_PROT
35 --------- ground
shield frame ground frame ground
—sheet 2 of 2—

Table D-18
24 to 31
P0 P1 connector
47 port 10 Tx + port 26 Tx + 42
13 port 10 Tx - port 26 Tx - 28
46 port 10 Rx + port 26 Rx + 13
12 port 10 Rx - port 26 Rx - 43
45 port 11 Tx + port 27 Tx + 30
11 port 11 Tx - port 27 Tx - 15
44 port 11 Rx + port 27 Rx + 14
10 port 11 Rx - port 27 Rx - 44
43 port 12 Tx + port 28 Tx + 32
42 port 12 Rx + port 28 Rx + 33
41 port 13 Tx + port 29 Tx + 20
40 port 13 Rx + port 29 Rx + 34
39 port 14 Tx + port 30 Tx + 21
38 port 14 Rx + port 30 Rx + 36
—sheet 1 of 2—

Table D-18
P0 P1 connector
37 port 15 Tx + port 31 Tx + 38
36 port 15 Rx + port 31 Rx + 37
34 FP_CLOCK --------- 1
68 FP_DATA --------- 2
1 12V_PROT --------- 16
35 ground --------- 24
shield frame ground --------- shield
—sheet 2 of 2—
32-port E1 MSA termination panel pinouts for CPE connections

The pinouts for connecting customer premises equipment (CPE) to a 32-port
E1 MSA termination panel are identified in the figures:
• “32-port E1 MSA termination panel pinouts and signal names: 1-port/
• “32-port E1 MSA termination panel pinouts and signal names: 2-port/
• “32-port E1 MSA termination panel pinouts and signal names: RJ-45” on
page D-42

Figure D-18
32-port E1 MSA termination panel pinouts and signal names: 1-port/DB15
Termination
panel cable Pin Name
1 Receive +
2 Frame Ground
8 3 Transmit +
15
7 4 Frame Ground
14 9 Receive -
6 11 Transmit -
13
5
12
4
11 Tx Pair
3
10 To customer
2
9 Rx Pair
1
“32-port E1 MSA termination panel pinouts and signal names: 1-port/DB15”
on page D-41.
Figure D-19
32-port E1 MSA termination panel pinouts and signal names: 2-port/DB15
Termination panel
cable connector Pin Name
1 Port 1 transmit +
2 Port 1 receive +
8 5 Signal ground
15 Port 0 Tx pair 7 Port 0, receive +
7 8 Port 0, transmit +
14 Port 0 Rx pair
9 Port 1, transmit -
13 12 Frame ground
5
4 15 Port 0, transmit -
11
3
10
2 Port 1 Rx pair
9 To customer equipment
1 Port 1 Tx pair
PPT 2862 001 AB

“32-port E1 MSA termination panel pinouts and signal names: 2-port/DB15”
on page D-41. All odd-numbered ports (1,3,5,...,31) have identical pinouts, as
do all even-numbered ports (0,2,4,...,30).
Figure D-20
32-port E1 MSA termination panel pinouts and signal names: RJ-45
RJ-45 connector
12345678 Pin Signal

1 Rx-
2 Rx+
3 Not used
4 Tx-
5 Tx+
6 Not used
7 Not used
8 Not used
PPT 2898 001 AA
“32-port E1 MSA termination panel pinouts and signal names: RJ-45” on
page D-42.

E-1
List of terms E
Numerics
1+1 FP Sparing
While both FPs terminate connections to the network only one of the FPs act as the
interface to the fabric. Removing the spare causes the loss of one network
connection.
1:1 FP Sparing
While both FPs may offer service only one has a network connection at one time due
to the presence of a sparing panel. Removing the inactive spare card has no impact
on the connection to the network.
A
ABQP
Aggregate BSS QoS Profile
APS
Automatic Protection Switching
B
backplane
Allows power and signal to be distributed to the cards connected to it and provides
connectors for sixteen processor cards and two bus terminator cards. Dual 800-Mbit/
s buses form part of the backplane.
Base Station Controller (BSC)

The BSC is in charge of the allocation and release of radio channels, and handover
management.
Base Station System GPRS Protocol (BSSGP) layer

This entity communicates routing and Quality of Service information between the
SGSN and the BSS.

E-2 List of terms
Base Transceiver Station (BTS)

A GSM network component that serves one cell and is controlled by a BSC.
Base Station System (BSS)

The BSS is associated with the radio channel management.
BITS
Building Integrated Timing Supply
BSSGP Virtual Connection (BVC)

An end to end virtual communications path between remote network service user
entities.
C
cable guide
This quarter-rounded guide ensures that a minimum bend radius is met for copper
and fiber cables. Its guide slots support and route cables.
cable management assembly

Allows orderly management of cables (copper, coaxial, and fiber) and acts as an
exhaust duct for hot air.
CAMEL
Customized Application for Mobile network Enhanced Logic.
CAS
Component Administration System
Charging Gateway Function (CGF)

External entity that processes GPRS accounting records.
ChR
Channel Ready
control plane (C-plane)

Administration functions outside the transfer of user data packets associated with
functions such as setting up and tearing down of connections, establishing identities,
and authorizing users.
Control processor (CP)

Control processors manage and control applications supporting both system and
network functions.
cooling unit
Contains a forced-air cooling system that ensures adequate cooling

List of terms E-3
of the processor card section.
CR
Change Request
CuR
Customer Ready
Cyclic Redundancy Check (CRC)

The monitoring of a digital bit stream to detect deviations from the expected bit
patterns.
D
DCS
Data Collection System
Domain Name System (DNS)

Part of the IP protocol stack. Allows host name to IP address mapping within an
Internet environment.
E
ELS
Ethernet Line Sparing
F
FPSO
FP switchover
Frame Relay transport (FR)

Frame Relay is a statistically multiplexed interface protocol for packet-switched data
communications.
Function processor (FP)

The function processors perform those functions that switch data from external
sources through the bus and out of the node through other function processors.
G
Ga interface
The interface between the SGSN and the CGF.
Gateway GPRS Support Node (GGSN)

The node within the GPRS core network which is responsible for interworking with
external PDNs, such as the Internet.

E-4 List of terms
Gb interface
The interface between the SGSN and the BSS. This interface is frame relay.
Gd interface
The interface between the GSM SMS-GMSC/SMS-IWMSC and the SGSN.
Gd’ interface
The interface between the SGSN and the SIG. The Gd’ interface is a Nortel
proprietary messaging interface.
Ge interface
The interface between the SCP and the SGSN.
Ge’ interface
The interface between the SGSN and the SIG. The Ge’ interface is a Nortel
General Packet Radio Service (GPRS)

A packet radio access technique based on GSM radio to transfer data in an efficient
manner optimizing the use of network resources. It re-uses existing GSM radio
technology.
Gi interface
An external interface between the GGSN and another type (non-GPRS) of packet
network.
Global System for Mobile communications (GSM)

A technical standard for European mobile networks.
Gn interface
The interface based on IP that is between the SGSN and the GGSN.
GPRS Mobility Management (GMM) context

The GMM context is the information sets held at the MS and the SGSN. It contains
mobility related information such as the Mobility Management state as well as
location information, IMSI, and negotiated timer values.
GPRS Subscriber Control (GSC)

Primary purpose is to organize the related C-plane processes, such as GMM, SM,
HLR Cache, and MAP Client.
GPRS Subscriber Layer Data (GSD)

Consists of the protocols involved in the data path, LLC and SNDCP.
GPRS Subscriber Layers (GSL)

List of terms E-5
Collectively refers to the combination of the GSD and GSC interface protocols.
GPRS Support Node (GSN)

Constitutes the interface between the radio system and the fixed networks for packet
switched services. The GSN performs all necessary functions in order to handle the
packet transmission to and from the mobile stations.
GPRS Transport Layer (GTL)

Consists of the protocol layers that are involved in the transport of information
between the SGSN and the BSS.
GPRS Tunneling Protocol (GTP)

The transport protocol used between the SGSN and GGSN for both signaling and
user data transfer.
Gr interface
The interface between the SGSN and the HLR.
Gr' interface
The interface between the SGSN and the SIG. The Gr' interface is a Nortel
Gs interface
The interface between the SGSN and MSC/VLR. The Gs interface provides mobiles
the ability to communicate with the MSC/VLR for circuit switch services while they
are attached to the packet network.
Gs’ interface
The interface between the SGSN and SIG. The Gs’ interface is a Nortel proprietary
messaging interface.
H
Home Location Register (HLR)
Used to store the subscription record, temporary data, the serving-MSC number and
VLR number of a mobile subscriber.
housing assembly
Routes cables from the front of the cabinet to the rear.
HSM
Hitless Software Migration
I
Internet Protocol (IP)

E-6 List of terms
One of the fundamental protocols of the TCP/IP Internet Protocol suite. It defines the
IP datagram as the unit of information passed across an Internet and provides the
basis for connection-less, best-effort packet delivery service.
Inter-SGSN Routing Area Update (IRAU)

Procedure that enables a subscriber to move between cells covered by different
SGSNs while maintaining an active PDP context.
L
Logical Link Control (LLC) layer
The upper sublayer of the data link layer of the seven-layer OSI model, which
provides media-independent functions and the logical connection between the
stations within the local area network.
M
MBTF
Mean Time Before Failure
mobile application part (MAP)

The MAP is the software protocol layer that allows information about a roaming
mobile-subscriber (MS) to flow between functional entities in the Public Land
Managed Network (PLMN).
mobile station (MS)

Subscriber equipment that provides access into the PLMN.
Mobile Switching Center (MSC)

Provides switching and call control of GSM basic and supplementary services.
N
Network Equipment-Building System (NEBS)
A set of standards issued by Bellcore that defines a rigid and extensive set of
performance, quality, environmental, and safety requirements for equipment
installed in switching facilities.
Network Services (NS) layer

The transport protocol used between the SGSN and the BSS, specifically the PCUSN
of the BSS, to ensure in order delivery of packets sent between higher layer
protocols.
Network Services Entity (NSE)

A logical entity that exists on both the SGSN and the BSS for managing the transport
of both signaling and data packets between them.

List of terms E-7
Network Services Virtual Connection (NS-VC)

An end to end logical connection for the transport of signaling and data packets
between the SGSN and the BSS.
Nodal Manager (NM)

Performs several tasks involved with SGSN management.
O
Open Systems Interconnection (OSI)
An abstract description of the digital communications between application processes
running in distinct systems. The model employs a hierarchical structure of seven
layers.
Operations, Administration, and Maintenance (OA&M)

All the tasks necessary for providing, maintaining, or modifying the services
provided by a switching system.
P
Packet Control Unit Support Node (PCUSN)
A node in the BSS which interacts either directly or indirectly with all the BSS nodes,
except the Transcoder Unit (TCU).
packet data network (PDN)

A communications system designed to carry packet data.
Packet Data Protocol (PDP) context

The PDP context is the information sets held in the MS and the GSNs for a PDP
address. It contains information such as PDP Type, QoS Profile, APN and GGSN.
Passport bus
Two synchronous 32-bit 25-MHz cell buses, operating in a load-sharing capacity,
which can communicate with up to 16 function and control processors. Each bus
operates at 800 Mbit/s for a combined speed of 1.6 Gbit/s.
PEC
Product Engineering Code
port
In this document, refers to the part of a data processor that is dedicated to a single
channel for the purpose of receiving data from, or transmitting data to, one or more
external remote devices.
power converter
Converts primary power inputs into secondary operating voltages. Power converters

E-8 List of terms
are only available in the direct current version for the SGSN application.
Synonymous with power supply.
Prepaid Short Message Service (SMS)

Extension of GPRS SMS that incorporates prepaid messaging services.
Protocol Data Units (PDU)

A data unit that (a) is transferred among peer entities of a network and (b) contains
protocol information, such as control information and address information.
P-TMSI
Packet Temporary Mobile Subscriber Identity
Public Land Mobile Network (PLMN)

A network, established and operated by an Administration or its licensed operator(s),
for the specific purpose of providing land mobile communication services to the
public.
S
SCCP Client Interface Protocol (SCIP)
A proprietary protocol that encapsulates SS7 SCCP messages and transports it to the
MAP client via TCP.
Service Control Point (SCP)

External entity used to manage Prepaid SMS subscriber accounts.
Service Switching Function (SSF)

component on the SGSN and support for the CAP protocol enables the SGSN to
communicate with the SCP.
Serving GPRS Support Node (SGSN)

Main functions are to detect new GPRS mobile stations in its service area, send/
receive data packets to/from the mobile stations, and record the location of mobile
stations inside its service area.
SGSN Accounting Server (SAS)

SGSN entity that provides the SGSN billing functionality.
Short Messages Service (SMS)

Provides the means to transfer messages between a GPRS PLMN MS and a Short
Message entity via a service center.
signaling system 7 (SS7)

Common channel signaling system designed for the control of voice and non-voice

List of terms E-9
services and for use in a digital environment, where signaling information may be
sent at 64 kbit/s.
software distribution site (SDS)

A workstation designated to manage, store, and distribute Passport software.
SNR
Seamless National Roaming
SS7/IP Gateway (SIG)

The SIG provides interworking between GPRS nodes in an IP network and GSM
nodes in an SS7 network.
SubNet Dependent Convergence Protocol (SNDCP) layer

Responsible for segmentation or reassembly and possibly compression of data
packets for transport between the MS and the SGSN.
T
Temporary Logical Link Identifier (TLLI)
Describes an identified MS registered in the network and owning a LLC context with
the SGSN.
terminal equipment (TE)

A device that converts data from the parallel format used within a terminal to the
serial format used on a communications link.
transaction capabilities application part (TCAP)

TCAP uses the MTP and SCCP software layers to provide connectionless signaling
for transaction services. Simply put, it allows two nodes to communicate with each
other in the same language.
Transmission Control Protocol/Internet protocol (TCP/IP)

A protocol stack, designed to connect different networks, on which the Internet is
based.
Transport Protocol Data Unit (TPDU)

A TPDU is a data unit to exchange information between two transport entities.
U
User Datagram Protocol/Internet Protocol (UDP/IP)
A transport layer, connectionless mode protocol, providing a datagram mode of
communication for delivery of packets to a remote or local user.
user plane (U-plane)

E-10 List of terms
Function associated with the transfer of actual user data to and from a PDN.
VSS
Variable Speed Switch

F-1
Index F
Numerics authCipheringRetries - N3360 C-33
100BaseT Ethernet function processor 3-20, 3- authCipheringTimer - T3360 C-33
21, A-7 authentication 2-12, 5-80
15K-VSS 3-4 authEvents C-33
2pGPDsk function processor 3-32, 3-33, 6-2 authTripletsReuse
MAP application 2-18 GSC/Gmm C-35
2-port OC-3 ATM function processor 3-22 HLRC C-62
4pDS3Ch function processor 3-36 Avg activepdpcontext per activesubscribers
C-25
4-port OC-3 ATM function processor 3-34
avgPdpContextPerRecord C-25
A B
accounting
see billing backplane 3-18
active alarm list 7-45 for Passport 15000 shelf 3-29
afrRetries C-41 for Passport 7480 3-16
afrSanityTimer C-101 power connections to BIP 3-8
Aggregate BSS QoS Profile (ABQP) 5-55 Base Station System GPRS Protocol (BSSGP)
alarm/BITS module 3-31 layer 1-10
alarms billing
BIP alarm module 3-6 and node failure 6-25
events 7-9 CAMEL Phase 3 5-31
external 3-7 hardware 6-2
allowableCompressionAlgorithms C-69 record storage 6-18
applications redundancy 6-22
SGSN 7-5 blockSize C-92
ASN.1 formatting 6-2 breaker interface modules (BIMs) 3-5
asn1FileGeneration C-120 BSSAP+ 2-15
ATM function processor 3-34 bssapHopCounter C-43
ATM I/O bssapRegistrationRequestTimer C-44
redundancy 4-5 bssapXudtOption C-44
ATM MPE 2-34 BSSGP layer 1-6, 1-10
attach and activate failure alarms 7-29 BSSGP Virtual Connections 1-10, 2-4
attributes 7-4 flow control 2-4
audit solution 4-21
alarms 7-45

F-2 Index
buffCheckInterval C-97 CP3 3-31

bus 3-16 function 3-17
performance A-2 maximum per shelf A-2
BVC redundancy 3-17
flow control 2-4 slots 3-13, A-2
bvcResetRetries C-88 cooling unit
bvcResetTimer C-88 for NEBS 2000 frame 3-9
bwForSvcToFratm C-89 for Passport 7480 3-16
CP Switchover (CPSO) 4-17
C CP2 3-18
cable guide 3-12 CP3 3-31
cable management assembly 3-11 C-plane 1-6
Call Detail Record (CDR) 6-2 cpResponseRetries - TC1NRet C-58
see also CDRs cpResponseTimer - TC1N C-58
CAMEL Phase 3 5-23–5-37 CPU usage 4-26
billing and charging 5-31
cdrCapture C-112 D
cdrRetries C-117 dailyPartialTimeOfDay 6-16, C-119
CDRs 6-6 data collection system 7-7, 7-74
batch file Data Volume Limit (DVL) 6-8
naming 6-18 Daylight Savings Time
processing 6-18 and SAS 6-7
maximum number of charging condition automatic time adjustment 7-47
changes 6-10 Dc power 3-15
open 6-5 input specifications A-4
record storage 6-18 DMS-MSC 1-4
recovering 6-19 DNS Query Failure to GMM Cause Code
update 6-6 default mapping 7-52
cdrTransferTime C-116 Domain Name System (DNS) Agent 2-23, 2-
cdrUpdateInterval C-114 24
cdrUpdateTimeOfDay C-118 downlink PDU buffering 5-65
century compliance A-11 downloading software 8-1, 8-2
Charging Gateway Function (CGF) 1-8, 6-1, 6- drtResponseTimeout C-116
19, 7-11 drtRetries C-117
checkpointing 4-10 DS3 function processor 3-35
ciphering 5-81 dsdSanityTimer C-102
cipheringAlgorithms C-34 DTE 1-3
clDialogueTimer C-109
Clear command 7-34 E
cnxUpTimer C-109 echoRequest C-53
cold standby 4-2 echoRequestInterval C-116
components 7-3 echoTimeInterval
SGSN 7-4 SGSN to CGF See echoRequestInterval C-
compression 1-10 116
control processor 4-5, A-7 SGSN to GGSN C-54
CP2 3-18

Index F-3
encryption 1-10 Gb interface 1-9

engineering rules B-1–B-27 G-CSI 5-25, 5-26
enhanced breaker interface panel (EBIP) 3-5, Gd interface 5-15
A-4 Gd’ interface 1-13, 5-15
environmental specifications A-5 Ge interface 1-11
Equivalent PLMN 5-3 Ge’ interface 1-13
Ethernet function processor 3-20 genericUtilities 7-5
explicitGprsDetachRetries - N8 C-45 GGSN
explicitGprsDetachTimer - T8 C-44 reselection 2-9
explicitImsiDetachRetries - N9 C-45 Gi interface 1-3
explicitImsiDetachTimer - T9 C-45 Gigabit Ethernet
Extended TI IE 5-43 redundancy 4-17
GMM 1-7, 2-8
F statistics 7-7
fabric cards 3-30 GMM cause code mapping 7-48
faceplate port 2-27 Gn interface 1-12
feature optionality 5-2 Gp interface 1-12
frame 3-4 GPRS
Frame Relay 1-6, 1-9 definition 1-1
network failure 4-7 interfaces 1-4
fsmSanityTimer C-104 network architecture 1-1
function processor card 2-32 nodes 1-1, 1-3
100BaseT Ethernet 3-20, 3-21, A-7 user equipment 1-2
2pGPDsk 3-32, 3-33, 6-2 GPRS Mobility Management (GMM) 1-7, 2-6
2-port OC-3 ATM 3-22 See also GMM
4 port DS3 3-35 GPRS Subscriber Control (GSC) 2-6
4-port OC-3 ATM 3-34 See also GSC
for 15000 shelf 3-3 GPRS Subscriber Data (GSD) 2-5
for 7400 shelf 3-2 See also GSD
functions 2-29, 2-31, 3-20 GPRS Support Node (GSN) 1-3
maximum per shelf A-2 GPRS Transport Layer (GTL) 2-2
MSA32 3-23, D-1 See also GTL
OC-3 ATM 3-21, 3-23 GPRS Tunneling Protocol (GTP) 1-6, 1-12
redundancy summary 4-4 See also GTP
slots 3-13 Gr interface 1-3, 1-13
wireless packet data server (WPDS) 3-24, 3- Gr’ interface 1-13, 2-6
25, 3-26 Gs interface 1-15
Gs’ interface 1-13
G GSC
applications 7-12
Ga interface 1-8, 6-1
Gateway GPRS Support Node card reset and CDRs 6-7
see also GGSN
checkpointing 4-10
journaling 4-10
locking 4-12, 7-46
OSI states 7-61
redundancy 4-9
success rates 7-28

F-4 Index
unlocking 7-47 Gn 1-12

GSD Gp 1-12
OSI states 7-66 GPRS 1-4
redundancy 4-8 Gr 1-3, 1-13
GSM specifications, compliance A-2 Gr’ 1-13, 2-6
GTL Gs 1-15
redundancy 4-5 Gs’ 1-13
GTP 1-6, 2-8 X1 1-15
path Inter-SGSN Routing Area Update (IRAU) 5-
clearing 7-34 2
GTP-C and CAMEL Phase 3 5-27
path management 2-9 and secondary PDP context activation 5-49
inter-shelf communication 2-32
H IP
hardware assisted encryption 3-25 redundancy 4-17
hdlcBuffers C-108 IP address
heartbeatTimer C-107 maximum in cache table 2-24
heat dissipation A-5 of GGSN 2-23
HLR 1-13 static 2-8
HLR Cache 1-7, 2-12 IP Header Compression 5-84
statistics 7-7 isdSanityTimer C-103
hot standby 4-2 iwmscResponseTimer - TR2N C-59
billing 6-22
GSC 4-9 J
Hung Process Audit 4-21 journaling 4-10
I K
I/O routing 2-26 keepaliveTimer C-108
idRequestRetries - N3370 C-32 kWindowSizeDownlink C-85
idRequestTimer - T3370 C-31 kWindowSizeUplink C-86
implicitDetachTimer C-29, C-30
implicitImsiDetachRetries - N10 C-46 L
implicitImsiDetachTimer - T10 C-46 Last Mobile Activity Time 4-14
IMSI 2-12 Lawful Interception (LI) 5-68
IMSI information, displaying 7-34 redundancy 4-15
IN 5-23, 5-24 linkToMapStack 2-20
inactive mobile linkToTcapStack 2-20
clearing 7-34 LLC layer 1-10, 2-8, 4-9
interfaces lleToMobileRatio C-65
Ga 1-8, 6-1 load balancing 4-6
Gb 1-9 Location Based Billing 6-13
Gd 5-15 parameter C-112
Gd’ 1-13, 5-15
Ge 1-11
Ge’ 1-13
Gi 1-3

Index F-5
locationUpdateTimer - T6-1 C-43 master shelf 2-29, 3-1

lostMessagesThreshold C-109 maxAttachedSubscribers 7-12, 7-13, C-25
maxBvcPerNse C-23
M maxBytesBuffPerMs C-95
MAC layer 1-6, 1-7 maxBytesBuffPerSess C-95
MAP maxCamelDialogues C-50
error to GMM cause code default mapping maxDnsQueries C-111
7-51 maxDynamicEntries C-111
redundancy 4-16 maxGtpPaths C-54
valid 29.002 errors 7-49 maxHeaderCompressionEntities C-68
MAP versions maxInvokesPerSubsystem C-106
supported for SMS 5-15 maxLlcActiveSubscribers 7-12, 7-13, C-67
MapClient 1-14, 5-17 maxMsWithBuff C-93
OSI states 7-72 maxNSE supported C-22
statistics 7-7 maxPacketsBuffPerMs C-94
mapFallbackResetTimer C-41 maxPacketsBuffPerSess C-94
mapping maxRetries C-110
dynamic 2-23 maxRfc1144Entities C-68
static 2-23 maxSessWithBuff C-93
MapStack 2-13, 2-17 maxSubsAccessCode 7-12
and node failures 2-21 maxSubscribers 7-12, C-22
multishelf 2-18 maxTransactionsPerSubsystem C-105
OSI states 7-74 maxV42bisEntities C-69
provisioning 2-20 M-CDR partial records 6-17
routing 2-18 mcdrMaxContainers C-115
mcdrPartialRecordInterval C-115
M-CDRs 6-5
mcTimer C-40
media access control (MAC) address module
3-31
memory audit 4-21
corruption 4-22
leak 4-22
mobile terminal 1-2
mobileReachableTimer C-29, C-99
mobility management 2-1
number of transactions 7-7
mofsmSanityTimer C-104
MS Purge 5-88
MSA32 function processor
dual slot 3-23
single slot D-1

F-6 Index
msFlowControlThTimer C-79 numBlocks C-90

MTBF A-2 nwkInitDetachRetries - N3322 C-31
mtfsmSanityTimer C-103 nwkInitiatedDetachTimer - T3322 C-31
Multiple Point Code 2-16, 2-17 nwkPdpDeactRetries - T3395Retry C-27
multishelf configuration 2-29, 3-1 nwkPdpDeactTimer - T3395 C-26
provisioning requirements 2-34 nwkPdpModifyRetries - N3386 C-28
nwkPdpModifyTimer - T3386 C-27
N
n200MaxRetransmits - N200 O
SAP1 C-78 OA&M
SAP3, 5, 9, 11 C-82 hardware requirements 3-40
SAP7 C-87 of SGSN 7-1
n201MaxIinfoFieldLength - N201I C-84 overview 7-2
n201MaxUInfoFieldLength - N201U text interface 7-9–7-11
SAP1 C-79 OC-3 ATM function processor 3-21, 3-23
SAP3, 5, 9, 11 C-82 OSI states 7-8
SAP7 C-87 BSSAP 7-57
n3CreateRequest C-50 DNS 7-58
n3DeleteRequest C-51 GSC 7-61
n3EchoRequest C-52 GSD 7-66
n3SgsnContextRequest C-52 GTP Path 7-69
n3UpdateRequest C-53 GTP-C 7-67
Near Hot Billing 6-6 LI 7-70
Network Connection Control Protocol MapClient 7-72
(NCCP) 5-20 MapStack 7-74
Network Service Access Point (NSAP) 2-33 NSE 7-77
Network Service Entity 2-3 SAS 7-79
redundancy 4-7 SGGTL 7-80
Nodal Manager 2-32, 4-18 Sgsn 7-82
Nodal Manager Audit 4-22 Sgsn Sh ConM 7-83
node Sgsn Sh ConS 7-83
assemblies in Passport 7480 3-11 SSF 7-63
description 3-10 TCAP 7-85
throughput A-2 overload controls
noTimeLimitPartials 6-9 example 4-34
NS layer 1-6, 1-9 message 4-27
NS-VCs 1-10, 4-6, 4-7 resource 4-23
statistics 7-8
P
Packet Control Unit Support Node (PCUSN)
1-4
Packet Flow Context 5-55
Packet Flow Identifier 5-57
Packet Temporary Mobile Subscriber Identity

Index F-7
(P-TMSI) 5-81 Private-Network-to-Network-Interface

PacketFlowContextFeature C-88 (PNNI) 2-33
PacketFlowTimer (t9) C-61 protocol stacks
pagingRetries - N3313 C-30 between MS and GGSN 1-6
pagingTimer - T3313 C-30 between MS and SGSN 1-7
partial records between SGSN and SCP 5-20
common provisioning 6-16 for Ga interface 1-9
Management Intervention cause for for GPRS Prepaid SMS 5-20
generation 6-10 for Gs interface 1-11, 1-15
M-CDR 6-17 for SGSN, SIG, and HLR 1-12, 1-14
S-CDR 6-8 provisioning
time based 6-9 SGSN 7-5
volume based 6-9 PslSanityTimer C-105
Passport P-TMSI Signature 5-81
operations 7-2 ptmsiEvents C-99
Passport 15000 3-1 ptmsiReallocationRetries - N3350 C-32
description 2-1 ptmsiReallocTimer - T3350 C-32
InterLan Switching (ILS) 2-1
Passport 15000 shelf 3-28 Q
patches 8-2 QoS 5-55
path management 2-9 QoS negotiation 5-53
PDP context 1-10, 2-8
duration limit 6-9
modification 5-38
R
readyTimer - T3314 C-28
MS initiated 5-38 Record Sequence Number 6-9
SGSN initiated 5-38 redundancy
pduLifeTimeInBuff C-97 ATM I/O FP 4-5
PerCellStatistics 7-14 billing 6-22
performance counters 7-14 control processor 3-17, 4-5
periodicRaUpdateTimer - T3312 C-29, C-98 FP summary 4-4
Point Code function processor 4-1
Multiple 2-16, 2-17 Gigabit Ethernet 4-17
provisioning 2-16 GSC 4-9
Single 2-16 GSD 4-8
port GTL 4-5
description 3-10 IP 4-17
power converter 3-14, 3-15 Lawful Interception 4-15
power interface modules (PIMs) 3-30 limitations 4-17
power supply MAP 4-16
number per node A-2 power supply A-2
redundancy A-2 SGSN 4-1
PPP PDU type 2-8 SGSN Accounting Server 4-14
Prepaid Card Telephony Protocol (Prepaid- types of 4-2
CTP) 5-20
Prepaid SMS 5-18
procedure 5-22
provisioning 5-21

F-8 Index
refreshTime C-110 Session Management (SM) 1-7, 2-8

RegisteredClient 2-21 statistics 7-7
registrationTimer C-106 sessionsToMobileRatio C-64
remoteMapStackServer 2-20 SGSN
remoteTcapStackServer 2-20 accounting 1-8
reselection, GGSN 2-9 applications 7-5
Reset Timer C-21 billing 3-33, 6-1–6-32
retryTimer C-110 downloading and applying patches 8-3
REX test 4-11 functions 2-1
RFC 2507 IP Header Compression 5-84 hardware description 3-1–3-41
rfc2507MaxPeriod C-70 heat dissipation A-5
rfc2507MaxTime C-70 physical specifications A-2
rfsmSanityTimer C-104 provisioning 7-5
Routine Exercise (REX) Testing 4-11 redundancy features 4-1
routing limitations 4-17
I/O 2-26 software architecture 2-2, 7-2–7-13
IP 2-26 software installation 8-1
rpResponseTimer - TR1N C-59 specifications A-1–A-12
views 7-6
S SGSN Accounting Server (SAS)
saiRetries C-41 redundancy 4-14, 6-22
saiSanityTimer C-101 SGSN Accounting Server (SAS) See Also
SAS SAS 6-2
hardware 6-2 sgsnResetRetries - N12 C-47
multiple cards per shelf 6-3 sgsnResetTimer - T12-2 C-47
sasAuditFileLife C-117 shelf
sasGenAuditFiles C-117 See node
sasroamerCapture C-118 shelf assembly 3-13
sccpServiceRequestTimer C-42 Short Message Service (SMS) 5-15
scdrMaxContainers 6-10, 6-16 maximum number of concurrent short
scdrPartialRecordInterval 6-9, 6-16, C-114 message transfers 5-18
S-CDRs 6-5 network elements 5-16
partial records 6-8 Prepaid 5-18, 5-21, 5-22
Seamless National Roaming (SNR) 5-3 procedures 5-18
Secondary PDP context activation 5-43 Single Point Code 2-16
example 5-44 slave shelf 2-29, 2-34, 3-1
security 5-80 SM layer 1-13
functions 2-7 SMS-GMSC/SMS-IWMSC 5-17
management 7-8 SNDCP layer 1-6, 1-10, 2-8, 4-9
Service Center (SC) 5-17 statistics 7-7
Service Control Point (SCP) software architecture, SGSN 7-2–7-13
provisioning 5-18 software distribution site (SDS) 3-40, 7-5, 8-1,
Service Switching Function (SSF) 5-25
OSI states 7-63
Serving GPRS Support Node (SGSN)
See also SGSN 1-3

Index F-9
8-2 t3CreateResponse C-51

software installation 8-1 t3DeleteResponse C-51
Software Optionality Control (SOC) 7-12 t3EchoResponse C-52
Specific Daily Partial 6-13 t3SgsnContextResponse C-52
specifications A-1–A-12 t3TunnelTimer C-35
specificDailyScdrPartial 6-16, C-119 t3UpdateResponse C-53
SS7 1-13 T7Retries (nT7) C-61
SS7/IP Gateway (SIG) 1-3 T7Timer C-61
ssfChargingGuardRetryAttempts C-48 Tariff Time Change Trigger (TTCT) 6-11
ssfChargingGuardTimer C-48 TC1N See cpResponseTimer C-58
ssfRoamerService C-49 TC1NRet See cpResponseRetries C-58
ssfSupportedCamelPhase C-49 TCAP
ssfTcapStackRegistrationTimer C-49 OSI states 7-85
S-SMO-CDRs 6-5 Telnet 7-2, 7-11
S-SMT-CDRs 6-5 temperatures A-6
standards compliance A-6 Temporary Logical Link Identifier (TLLI) 2-
static IP address 2-8 7
statistics 7-7 terminal 7-11
stub resolver 2-24 throughput A-2
Subscriber Control (SC) Diagnostic Tool 7-36 Time Of Day Accounting (TODA) 6-11
subscribers TLLI 2-7, 4-9
count overload control 4-26 collisions 5-81, 5-82
number of, provisioning 7-12 totalBytesReservedForBuffering C-96
prepaid 5-21 TR1N See rpResponseTimer C-59
subsRegisterRecoveryUpdateTimer C-34 TR2N See iwmscResponseTimer C-59
success rates trace tools 7-35
GSC 7-28 traffic classes 5-53
supplementary services 1-7 traffic data volume containers 6-11
switched virtual circuits (SVCs) 2-32, 2-33 transferInterval C-113
transferTimeOfDay C-118
T Transport Protocol Data Unit (TPDU) 1-13
t200RetransmitTimer - T200 C-29 triggers 5-26
SAP1 C-77 Event Detection Point (EDP) 5-26
SAP3, 5, 9, 11 C-81 Trigger Detection Point (TDP) 5-26
SAP7 C-86

F-10 Index
tssfTimer C-47
tunnel creation 1-13
U
uglRetries C-40
uglSanityTimer C-100
Um 1-6, 1-7
umtsAuthVectorAllocation C-63
updateInterval C-114
upgrade 8-1
U-plane 1-6, 1-13
V
v42bisCompressionDirection (p0) C-67
ventilation A-5
views 7-6
virtual connections 1-10
See also NS-VCs
virtual routers 2-24
W
wireless packet data server (WPDS) 3-24, 3-
25, 3-26
hardware assisted encryption 3-25
wirelessCommon 7-5
wirelessNssBss 7-5
wirelessSgsn 7-5
wirelessSgsnCommon 7-5
W-NMS 3-41
X
X1 interface 1-15

test
Family Product Manual Contacts Copyright Confidentiality Legal
GPRS
Nortel SGSN/GPRS
User Guide
To order documentation from Nortel Global Wireless Knowledge Services, call

(1) (877) 662-5669
To report a problem in this document, call
(1) (877) 662-5669
or send e-mail from the Nortel Customer Training & Documentation World Wide Web site at
http://www.nortel.com/td
Copyright  1999–2005 Nortel Networks, All Rights Reserved
NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in
writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its
employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the
same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly
authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as
progress in engineering and manufacturing may warrant.
NORTEL, NORTEL NETWORKS, the globemark design, and the NORTEL corporate logo are trademarks of Nortel.GSM is a
trademark of GSM MOU Association.
Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
Document number: 411-5221-955
Product release: GPRS6.0
Document version: Standard 08.08
Date: October 2005
Originated in the United States of America

411-5221-955.08.08 SGSN User Guide

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

411-5221-955.08.08 SGSN User Guide

Enviado por

Direitos autorais:

Formatos disponíveis

411-5221-955

Document number: 411-5221-955

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright  1999–2005 Nortel Networks, All Rights Reserved

NORTEL NETWORKS CONFIDENTIAL

411-5221-955 Standard 08.08 October 2005

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

Removed chapter “Software Description” and moved the information to

SGSN accounting information has been moved to a separate chapter,

411-5221-955 Standard 08.08 October 2005

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

Note: GPRS SMS will be supported in GPRS2.1.

411-5221-955 Standard 08.08 October 2005

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

411-5221-955 Standard 08.08 October 2005

About this document xxv

Functional description 2-1

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

Session Management layer 2-8

Hardware description 3-1

411-5221-955 Standard 08.08 October 2005

4 port Gigabit Ethernet function processor 3-37

Services and features 5-1

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

Quality of Service equivalence 5-10

411-5221-955 Standard 08.08 October 2005

GTP layer 5-64

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

Time based partial and DVL partial record interaction 6-9

Operations, administration, and maintenance 7-1

411-5221-955 Standard 08.08 October 2005

Performance counters 7-14

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

Software management 8-1

Technical specifications and conformances A-1

Engineering rules B-1

411-5221-955 Standard 08.08 October 2005

SGSN parameters C-1

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

MAP Client C-40

Single slot 32-Port MSA cabling D-1

List of terms E-1

411-5221-955 Standard 08.08 October 2005

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

Figure 5-1 National roaming network 5-5

411-5221-955 Standard 08.08 October 2005

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

411-5221-955 Standard 08.08 October 2005

Table 7-4 SC Diagnostic Tool activation alarms 7-41

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

411-5221-955 Standard 08.08 October 2005

About this document

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

• Appendix A, “Technical specifications and conformances” provides

Software release applicability 0

This document provides a comprehensive view of the SGSN product as of

GPRS 6.0 is based on GPRS Release ‘4. Refer to NTP 411-5221-201,

411-5221-955 Standard 08.08 October 2005

Planning and Installation and Operations and Fault and

GPRS Nortel SGSN/GPRS User Guide GPRS6.0

411-5221-955 Standard 08.08 October 2005

• 3GPP TS 29.018 (V4.5.0), “General Packet Radio Service (GPRS);