Cs2000 Mega

International Succession Networks
CS2000 International Product Description

Communication Server Capabilities for International Markets
Issue ISN07_v3 (approved), 17 August 2004

Preface
The ISN07 Product

This document is a CS2000 Product Description for ISN07. The name ISN07 denotes a
set of ISN (International Succession Networks) software loads installed on
Communication Server 2000 hardware platforms.
CS2000 belongs to the Nortel Networks portfolio of Succession Networks products. It
provides call handling capabilities for use with packet-based IP (Internet Protocol) and
ATM (Asynchronous Transfer Mode) media networks. These capabilities include a wide
range of internationally proven call processing agents, translations, routing, billing and
services software. Specific applications currently supported over packet bearer networks
are VoIP (Voice over IP) and VoATM (Voice over ATM). ISN07 support for these
applications is made available to customers via Nortel-defined network solutions:
VoIP The PToIP (Packet Trunking over IP), IAW (Integrated Access Wireline) and
IAC (Integrated Access Cable) solutions are based on an IP backbone
network.
Note: The IP backbone network can be implemented in a number of different
ways, depending on the requirements and preferences of the network
operator. These include VoIP with MPLS at Layer 2 and VoIP over ATM
using AAL5. See the separate document IP Networks for Succession for
further information.
VoATM The VToATM (Voice Trunking over ATM) solution is based on an ATM
backbone network with AAL2 (ATM Adaptation Layer 2) bearer connections.
ISN software can also be installed on the DMS-100 hardware platform to provide
circuit-based switching and service support capabilities, in which case it is referred to as
ISN (TDM). ISN software can even be installed in a hybrid configuration that comprises
CS2000-specific and DMS-specific hardware as well as hardware that is common to both.
Such a hybrid configuration can support circuit-based and packet-based capabilities
simultaneously, using looparound trunks to support call interworking between the circuit
and packet environments.
Development of a software load that can support both packet-based and circuit-based
capabilities is central to Nortels Succession Networks strategy. This strategy is based on
maximum re-use of proven telephony software combined with maximum exploitation of
leading-edge hardware and network architecture. It means that the same range of proven
call-processing agents, translations and routing capabilities and value-added services is
Issue ISN07_v3 (approved) PROPRIETARY Page

17 August 2004 Nortel Networks i
potentially available to any network operator regardless of backbone network type, and
that there is an easy migration path to a packet-based next-generation network
architecture. The aim is to realise the Nortel Networks vision of Unified Networks that
can convey voice, data and multimedia traffic with equal ease.
Document Purpose and Structure

The aim of this Product Description is to provide a high-level functional view of the
complete portfolio of ISN07 capabilities. It describes the superset of all capabilities that
are formally supported and available for deployment, not the subset of capabilities
deployed by any one network operator.
The document serves as a single source of high-level product information about the ISN07
capabilities available for deployment in international markets. It is intended for internal
use and for controlled external distribution to Nortel Networks customers. Within Nortel,
it can be used as a baseline for product planning, as a checklist for integration and testing,
and as a reliable summary of capabilities for the use of business units. Externally, it
provides a basis for discussions between Nortel and its customers about how they can best
take advantage of the capabilities described.
The document comprises the following parts, each of which is further divided into
chapters that provide more detailed information:
! Part A: Introduction
! Part B: Hardware
! Part C: Software
! Part D: Packet Telephony Protocols
! Part E: TDM Telephony Interfaces
! Part F: Features and Services
! Part G: Network Fit
! Part H: OAM&P
See the ISN07 Release Contents appendix on page 843 for information about the delta
between ISN07 and the previous ISN05 release.
Relationship with Other Documents

As explained on the previous page, ISN software can support both packet-based and
circuit-based capabilities, and (in a hybrid configuration) can even support them
simultaneously.
This Product Description provides detailed descriptions only of CS2000 components and
of DMS hardware components that are common to DMS and CS2000 and may be
included in a non-hybrid CS2000 configuration. For a systematic description of all DMS
hardware, including components for which hybrid configuration interworking is
supported, refer to the separate ISN07 (TDM) Product Description.
This Product Description is intended to complement the FCAPS documents that provide
detailed reference information about service configuration and datafill, not to replace
them. Specifically, its functional view of ISN07 capabilities is intended to provide a
context within which implementation details are easier to understand.

17 August 2004 Nortel Networks ii
Table of Contents
Part A
Overview
Chapter A1 Market Overview 2
Chapter A2 Network Overview 3

A2.1 MEGACO Network Architecture 3
A2.2 CS2000 Implementation of MEGACO Architecture 5
A2.3 CS2000 Support for Network Architecture 7
A2.3.1 Hardware Support 7
A2.3.2 Software Support 13
A2.4 The Backbone Packet Network 19
A2.4.1 Network Characteristics 19
A2.4.2 PSTN Equivalence for Packet Networks 19
Chapter A3 Product Overview 21

A3.1 Configurations Available 21
A3.2 Capacity 22
A3.3 Telephony Interfaces Supported 22
A3.4 Interworkings between Telephony Interfaces 25

17 August 2004 Nortel Networks iii
Part B
Hardware
Chapter B1 CS2000 Hardware 29

B1.1 Overview 30
B1.2 Processor Complex (Core) 34
B1.2.1 XA-Core 34
B1.2.2 Processor Complex for CS2000-Compact 38
B1.3 Internal Communication (CS LAN and MS) 42
B1.4 Gateway Controllers (GWCs) 53
B1.5 Session Server 71
B1.6 CCS7 Signalling Terminations 72
B1.6.1 USP (Universal Signalling Point) 73
B1.6.2 FLPP Signalling Peripheral 78
B1.7 OAM&P Hardware 81
B1.8 CS2000 Interworking with Legacy Peripherals 89
B1.8.1 Hybrid Configurations using Looparound Trunks 89
B1.8.2 Hybrid Configurations using the IW-SPM 90
B1.9 Hardware Packaging 93
B1.9.1 CS2000 Cabinets 93
B1.9.2 Typical Cabinet Lineups 94
Chapter B2 CS2000 Support for Media Gateways 96

B2.1 Introduction 96
B2.2 Categorising Media Gateway Capabilities 98
B2.3 PVG (Packet Voice Gateway) Trunk Gateways 99
B2.4 PVG as a V5.2 Gateway 111
B2.5 H.323 Gateways 115
B2.6 Mediant 2000 Trunk Gateway 116
B2.7 Westell DPNSS Gateway 118
B2.8 Carrier-Located Line Media Gateways 119
B2.9 Line Media Gateways on Customer LANs 123
B2.10 Line Media Gateways on Cable Access Networks 126
B2.11 CVX1800 Media Gateway for RAS 130
Chapter B3 CS2000 Support for Media Servers 133

B3.1 Introduction 133
B3.2 AudioCodes MS2000 Series (MS2010 / MS2020) 135
B3.3 Universal Audio Server (UAS) 138
Chapter B4 CentrexIP Remote Clients and the CentrexIP Client Manager 144
B4.1 Network Configuration for CentrexIP Client Access 144
B4.2 CentrexIP Clients and their Capabilities 146
B4.3 CentrexIP Client Manager (CICM) 149

17 August 2004 Nortel Networks iv
Chapter B5 Media Proxies 153

B5.1 Media Proxy Functions 153
B5.1.1 Network Address Translation (NAT) 153
B5.1.2 NAT Traversal 154
B5.2 RTP Media Portal 156
Chapter B6 Multimedia Communication Server (MCS52000) 165

B6.1 Network Role of MCS5200 165
B6.2 MCS5200 Components 166
B6.3 MCS5200 Connectivity 169
B6.4 CS2000 / MCS5200 Combined Configuration 170
Part C
Software
Chapter C1 Software Loads 172

C1.1 CS2000 Core Load 173
C1.2 Loads for Other CS2000 Components 176
C1.3 Loads for Media Gateways and Servers 178
C1.4 OAM&P Software 179
Chapter C2 Trunk and Line Datafill 182

C2.1 The Purpose of Datafill 182
C2.2 Trunk Group Provisioning 183
C2.3 Signalling Link Provisioning 185
C2.4 Provisioning GWC Units 189
C2.5 Provisioning Gateways, Carriers and Trunk Endpoints 190
C2.6 Provisioning Inter-CS Trunks 191
C2.7 Provisioning Lines 196
C2.8 Provisioning Gateways and Line Endpoints 200
C2.9 Provisioning Tones and Announcements 203
Chapter C3 Translations and Routing 204

C3.1 Overview 205
C3.2 NCOS Screening 206
C3.3 IBN Translations 207
C3.4 Indirect Access to Universal Translations 209
C3.5 Universal Translations 210
C3.6 Codec Selection via Translations 216
C3.7 Routing 218
C3.7.1 Line Routing and Selection 218
C3.7.2 Trunk Routing and Selection 219
C3.7.3 Routing to Treatment 227
C3.8 Support for CCD (Clear Channel Data) Calls 229
C3.9 Order Codes for Translations and Routing Software 229
Page PROPRIETARY Issue ISN07_v3 (approved)

v Nortel Networks 17 August 2004
Part D
Packet Telephony Protocols
Chapter D1 Overview of Packet Telephony Protocols 231

D1.1 Packet Network Protocol Stacks 233
D1.2 Transport Protocols 234
D1.2.1 UDP (User Datagram Protocol) 234
D1.2.2 TCP (Transaction Control Protocol) 234
D1.2.3 SCTP (Stream Control Transmission Protocol) 235
D1.2.4 RUDP (Reliable UDP) 238
D1.3 Session Descriptions (SDP) 239
Chapter D2 SIP and SIP-T 243
Chapter D3 H.248 256
Chapter D4 ASPEN 280
Chapter D5 H.323 288
Chapter D6 UniStim 300
Chapter D7 NCS 308
Chapter D8 MGCP 319
Chapter D9 MPCP 325
Chapter D10 IUA 329
Chapter D11 V5UA 332
Chapter D12 MTP Adaptation Protocols (M3UA and M2PA) 338
Chapter D13 DSM-CC 342
Chapter D14 OAM&P Protocols 347

D14.1 SNMP (Simple Network Management Protocol) 348
D14.2 Configuration Protocols (BOOTP, DHCP, TFTP) 352

17 August 2004 Nortel Networks vi
Part E
Telephony Interfaces
Chapter E1 Overview of Support for Telephony Interfaces 357

E1.1 CCS7 Trunk Interfaces 358
E1.2 Intelligent Network Interfaces 360
E1.3 Access Interfaces 361
E1.4 VPN Interfaces 362
E1.5 Basic Analogue Subscriber Line Interfaces 363
E1.6 CentrexIP Lines 363
E1.7 Interworking in a Packet Network Environment 364
Chapter E2 CCS7 Interfaces 368

E2.1 Introduction 368
E2.2 TDM and Packet Network Implementations of CCS7 371
E2.3 ISDN User Part (ISUP) Support 381
E2.3.1 Overview 381
E2.3.2 ISUP Standards and Variants 382
E2.3.3 CS2000 Support for ETSI / ITU ISUP 386
E2.3.4 CS2000 Support for ANSI ISUP Variants 395
E2.3.5 UK ISUP Support 398
E2.3.6 SPIROU (French ISUP) Support 400
E2.3.7 Interworking Support for ISUP Variants 401
E2.3.8 Software Order Codes for ISUP 405
E2.4 Telephony User Part (TUP) Support 406
E2.4.1 IUP / BTUP Support 406
E2.4.2 SSUTR2 / FTUP Support 410
E2.4.3 CTUP Support 413
E2.4.4 Software Order Codes for TUP 415
E2.5 MTP, SCCP and TCAP Support 416
Chapter E3 INAP 422

E3.1 Functional Description 422
E3.1.1 IN Functional Elements 422
E3.1.2 INAP Specifications 423
E3.1.3 Peer-to-Peer Communication using INAP 424
E3.1.4 Interaction between Call Processing and IN 426
E3.2 CS2000 Implementation 430
E3.2.1 INAP Operation Support 430
E3.2.2 Detection Point Support 438
E3.2.3 Support for Application Context Negotiation 441
E3.3 INAP Signalling Interworkings 442
E3.4 Overview of Feature Set Support 444
E3.5 Order Codes for INAP 444
Chapter E4 PRI Access Interface 445

E4.3 Capabilities Supported 455
E4.4 Limitations 460

vii Nortel Networks 17 August 2004

E4.6 Order Codes for PRI 460
Chapter E5 QSIG VPN Interface 461

E5.3 Limitations 482
E5.5 Order Codes for QSIG 482
Chapter E6 DPNSS Interface 483

E6.3 Order Codes for DPNSS 489
Chapter E7 IBN Lines 490

E7.2.1 Lines off Large Carrier-Located Gateways 491
E7.2.2 Cable Lines off MTA Gateways 493
E7.2.3 Customer LAN Lines 497
E7.2.4 V5.2 PSTN Lines 499
E7.3 Line Provisioning 507
E7.5 Order Codes for Analogue Lines 507
Chapter E8 CentrexIP Lines 508

E8.2 CentrexIP Clients and their Capabilities 509
E8.3 Network Configuration for CentrexIP Client Access 512
Part F
Features and Services
Chapter F1 Feature Support Overview 515

F1.1 Feature Sets Currently Supported 515
F1.2 Feature Support in a Packet Network Environment 518
Chapter F2 Analogue Subscriber Line Services 530

F2.1 Introduction 530
F2.1.1 Assigning Services to Lines 530
F2.1.2 Service Packaging 531
F2.2 Service Categories and Services Available 532
F2.2.1 Call Barring and Restrictions 532
F2.2.2 Speed Calling Services 533
F2.2.3 Call Forward Services 533
F2.2.4 Call Handling 535
F2.2.5 Hunt Groups 536

17 August 2004 Nortel Networks viii
F2.2.6 Uniform Call Distribution (UCD) 536

F2.2.7 Automatic Call Distribution (ACD) 537
F2.2.8 Voice Mail 542
F2.2.9 Party Information Services 543
F2.2.10 Data Download 545
F2.2.11 Screening Services 546
F2.2.12 Call Completion / Call Return 547
F2.2.13 Regulatory Services 548
F2.2.14 Miscellaneous Services 549
F2.3 CEPT Services and the CEPT Line Option 550
F2.4 Service Availability with Different Line Types 552
F2.5 Service Support on Interworking 556
F2.6 Order Codes for Analogue Line Services 556
Chapter F3 Feature Support for CentrexIP Clients 558

F3.1 Feature Categories Supported 558
F3.2 Feature Assignment and Activation for CentrexIP Clients 559
F3.3 Features and Options Supported 560
Chapter F4 ISDN Supplementary Services 565

F4.2 MoU1 Service Support 566
F4.3 MoU2 Service Support 567
F4.4 Non-ETSI ISDN Services 574
F4.5 Networked Support for Supplementary Services 575
F4.6 Order Codes for ISDN Supplementary Services 576
Chapter F5 QSIG Services 577

F5.1 Overview 577
F5.2 Features Supported as Part of QSIG Basic Call 578
F5.3 QSIG Additional Network Features 578
F5.3.1 Transit Counter 578
F5.4 VPN Support via QSIG Feature Transparency (QFT) 579
F5.5 ISDN Supplementary Services 582
F5.5.1 Connected Party Number (COLP/COLR) 582
F5.5.2 Advice of Charge (AOC) 582
F5.5.3 Call Completion (CCBS / CCNR) 583
F5.6 German Network Features 584
F5.7 Service Support on Interworking 585
F5.8 Order Codes for QSIG Services 585
Chapter F6 DPNSS Features 586

F6.1 Functional Description 586
F6.2 DPNSS Feature Support Mechanisms 594
F6.2.1 Direct Support 594
F6.2.2 Support via DPNSS Feature Transparency (DFT)594
F6.3 DPNSS / Centrex Feature Interactions 596
F6.4 Order Codes for DPNSS Services 597

ix Nortel Networks 17 August 2004
Chapter F7 APM Feature Transparency 598

F7.1 Overview 598
F7.2 Application Contexts Supported by CS2000 600
F7.2.1 Services Supported via APM AC 1 (PSS1) 600
F7.2.2 Services Supported via APM AC 3 (AOC) 602
F7.2.3 Services Supported via APM AC 124 (Nortel) 603
Chapter F8 VPN 605

F8.1.1 VPN Infrastructure Options and Benefits 605
F8.1.2 VPN Access Options and Benefits 606
F8.2 VPN Telephony Overview 607
F8.2.1 VPN Functional Elements 607
F8.2.2 VPN Call Types 608
F8.2.3 VPN Services 609
F8.2.4 Flexible Translations and Routing 611
F8.3 Protocols Used for VPN 612
F8.3.1 Access Signalling Support 612
F8.3.2 Network Signalling Support 615
F8.3.3 Trunk and Access Signalling Options 621
F8.4 Interaction with MCS5200 to Support VPN 622
F8.5 Order Codes for VPN 623
Chapter F9 Voice Mail 624

F9.1 Overview 624
F9.2 Voice Mail Interfaces 626
F9.2.1 Message Desk Interface 626
F9.2.2 Subscriber Interface 626
F9.4 Order Codes for Voice Mail 627
Chapter F10 Conferencing 628

F10.1 Overview 628
F10.2 Network Configuration for Conferencing 629
F10.3 Using Conferencing Capabilities 630
F10.4 Order Codes for Conference Services 630
Chapter F11 Indirect Access 631

F11.1 The Purpose of Indirect Access 631
F11.2 Call Completion Scenarios 632
F11.3 Different Types of Indirect Access 635
F11.3.1 CLI Checking via Table DNSCRN 636
F11.3.2 Authcode Checking via Table AUTHCDE 640
F11.4 Supporting Interfaces and Call Flows 643
F11.4.1 Call Flows for CLI-Based Indirect Access 644
F11.4.2 Call Flow for Authcode Access 649
F11.5 Indirect Access Billing 650
F11.6 Order Codes for Indirect Access 651

17 August 2004 Nortel Networks x
Chapter F12 IN Services 652

F12.2 Service Support Capabilities 653
F12.3 Creating and Deploying Services 656
F12.4 Interaction between IN and Non-IN Features 657
F12.5 Order Codes for IN Services 659
Chapter F13 Providing Call Party Information (CLI and Related Services) 660
F13.1 Terminology and Basic Concepts 661
F13.2 Party Information Services 664
F13.3 Functional Overviews 666
F13.4 Parameters for Conveying Party Information 670
F13.5 Delivery of Party Information for Display 680
F13.6 CS2000 Provisioning 682
F13.7 Per-Interface Summary of Capabilities 686
Chapter F14 Regulatory Services 693

F14.1 Special Call Types 694
F14.1.1 Emergency Calls 694
F14.1.2 Priority Calls 696
F14.2 Call Tracking and Supervision Features 697
F14.2.1 Malicious Call Identification (MCID) 697
F14.2.2 Lawful Interception (LI) 699
F14.3 Charging and Billing Features 703
F14.3.1 Network Advice of Charge (NAOC) 703
F14.3.2 Payment Ceiling for Analogue Lines (PCA) 704
F14.3.3 Notification of Time and Charge (NTC) 705
F14.4 Network Interconnect Features 706
F14.4.1 Basic Interconnect 706
F14.4.2 Indirect Access 706
F14.4.3 Carrier Selection 706
F14.4.4 Carrier Name Notification (CNN) 706
F14.4.5 Account Code (ACCT) 706
F14.4.6 Number Portability 707
F14.5 Miscellaneous Features 711
F14.5.1 Call Forward Restrictions for Hong Kong 711
F14.6 Order Codes for Regulatory Services 711
Chapter F15 Multimedia Services for Blended Users 712

F15.2 CS2000 Blended User Configuration 713
F15.3 Call Setup Sequences 715
F15.4 Specific Services Supported 718
Chapter F16 ADSL Data Sessions 719
Chapter F17 RAS (Remote Access Service) 720

F17.1 Overview 720
F17.2 Virtual Points of Presence (VPOPs) 722

xi Nortel Networks 17 August 2004
Part G
Network Fit
Chapter G1 Numbering Plan 724

G1.1 Public Numbering Plan 724
G1.1.1 Support for Geographic Numbers 724
G1.1.2 Non-Geographic Numbers and Services 726
G1.1.3 International Calls 726
G1.1.4 CS2000 Inpulsing/Outpulsing Capacity 727
G1.1.5 Number Portability 727
G1.1.6 ODP and Services 728
G1.1.7 Order Codes for Open Dial Plan Support 730
G1.2 Private Numbering Plans 731
Chapter G2 CS2000 Support for Tones 733

G2.1 Overview 734
G2.2 Classifying and Identifying Tones 735
G2.3 CS2000 Implementation 738
G2.3.1 Identifying Tones 738
G2.3.2 Requesting the Playing of a Tone 738
G2.4 Media Gateway Support for Tones 739
Chapter G3 CS2000 Support for Announcements 742

G3.1 Announcement Characteristics 743
G3.2 The Role of the MS2000/UAS Media Server 744
G3.3 GWC - Media Server Communication via H.248 745
G3.4 Announcement Capacity 746
G3.5 Announcement Datafill 746
G3.6 The Audio Provisioning Server (APS) 747
Chapter G4 Network Integration Issues 748

G4.1 CS2000 Solutions 748
G4.2 International Deployment Considerations 749
G4.2.1 International Gateway Functionality 749
G4.2.2 Support for Multiple Timezones 750
G4.2.3 MCCS (Multi-Country Call Server) Capability 750
G4.3 Bearer Capability Mapping 751
G4.3.1 End-to-End Codec Negotiation 751
G4.3.2 Codec Negotiation via Translations 752
G4.3.3 RFC2833, T.38 and Comfort Noise (CN) 753
G4.4 Packet / Circuit Interworking 754
G4.4.1 Echo Cancellation 754
G4.4.2 Continuity Testing 755
Chapter G5 IP Addressing and Internet Transparency 756

G5.1 Public and Private IP Addresses 756
G5.2 Communication between Address Domains 757
G5.3 Network Address and Port Translation 759
G5.4 NAT Traversal 760

17 August 2004 Nortel Networks xii
G5.5 IP Addressing Example for CS2000 Solutions 762
Chapter G6 CAC (Call Admission Control) 764

G6.1 The Need for Call Admission Control 764
G6.2 CS2000 Support for Virtual Call Admission Control 765
G6.2.1 Logical Network Model 765
G6.2.2 GWC Support for LBL Traversal and VCAC 767
G6.3 Order Codes for VCAC 767
Part H
OAM&P
Chapter H1 Overview of OAM&P for CS2000 Solutions 769

H1.1 Logical OAM&P Architecture 770
H1.1.1 The TMN Hierarchy 770
H1.1.2 EMs and Management Applications Supported 771
H1.2 Physical OAM&P Architecture 774
H1.2.1 Trusted Access to NEs via the OAM&P VLAN 774
H1.2.2 External cccess to the OAM&P VLAN 776
H1.2.3 Software Packaging for EMs and Applications 777
H1.3 Access to EMs and Management Applications 782
H1.3.1 IEMS 782
H1.3.2 User Access to IEMS, EMs and Applications 783
Chapter H2 Fault Management 784

H2.1 Summary of Fault Management Capabilities 784
H2.2 Alarm Reporting 788
H2.3 Fault Reporting via Logs 789
H2.4 Other Fault Reporting Mechanisms 793
H2.5 Fault Isolation and Correction (Maintenance) 794
Chapter H3 Configuration 795

H3.1 Summary of Configuration Capabilities 795
H3.1.1 Commissioning 795
H3.1.2 Service Activation 796
H3.2 Hardware Commissioning 798
H3.3 Trunk Provisioning 799
H3.4 Line Provisioning 800
H3.5 V5.2 Provisioning 801
H3.6 Connections to Provisioning Applications 802
Chapter H4 Accounting 803

H4.1 Summary of Accounting Capabilities 803
H4.2 CS2000 Core Support for Billing 804
H4.2.1 Call Recording Formats Supported 804
H4.2.2 Automatic Message Accounting (AMA) 805
H4.2.3 Station Message Detail Recording (SMDR) 819
H4.2.4 Creation and Transfer of Billing Records 819
H4.2.5 Controlling the Generation of Billing Records 820

xiii Nortel Networks 17 August 2004
H4.2.6 Metering / Advice Of Charge (AOC) 821

H4.2.7 Order Codes for Accounting Support 822
H4.3 Core Manager SBA Support for Billing 823
H4.3.1 Overview 823
H4.3.2 Closing Billing Files Ready for Transfer 824
H4.3.3 File Transfer Options 824
H4.3.4 File Transfer Performance 825
H4.3.5 AMA Search via AMADUMP 825
Chapter H5 Performance Management 826

H5.1 Summary of Performance Monitoring Capabilities 826
H5.2 Performance Monitoring via OMs 830
H5.3 Performance Monitoring via PMs 835
H5.4 QoS Monitoring 836
Chapter H6 Security (OAM&P Access Control) 837

H6.1 Network Architecture for Security 838
H6.2 Security Overview 838
H6.3 User Authentication and Account Administration 840
H6.4 Secure Remote Access 841
Appendices
Appendix A ISN07 Release Contents 843

A.1 Overview 844
A.2 Hardware 844
A.3 Software 849
A.4 Packet Telephony Protocols 849
A.5 Telephony Interfaces 852
A.6 Features and Services 856
A.7 Network Fit 862
A.8 OAM&P 864
Appendix B Summary of Product Description Updates for ISN07 871
Appendix C References 877

C.1 Nortel Interface Specifications 877
C.2 Standards 878
C.3 Nortel Design Documents (FNs) 881

17 August 2004 Nortel Networks xiv
Abbreviations
3PC Third-Party Core (Motorola N765 processors used by CS2000-Compact)

3WC Three-Way Call (line service)
AC Audio Controller (GWC for UAS)

ACRJ Anonymous Call Rejection (line service)
AAL ATM Adaptation Layer
AAL2 ATM Adaptation Layer for VBR real-time traffic; can be used for voice
AAL5 ATM Adaptation Layer for lightweight VBR data traffic (also called SEAL)
ACIF Australian Communication Industry Forum (standards body)
ADSL Asymmetrical Digital Subscriber Line
AISUP Australian ISUP (IBN7-based agent used to support Malaysian ISUP V1)
A-law International PCM standard used for speech path encoding/companding
AMA Automatic Message Accounting (for billing calls)
ANF Additional Network Feature (type of QSIG service)
ANSI American National Standards Institute
AO Alternative Operator (competing with an established PTT)
AOC Advice Of Charge (ISDN service)
API Application Program Interface (for standard calls to software functionality)
APM Application Transport Mechanism (for feature transparency)
APS Audio Provisioning Server (for UAS provisioning)
AR Automatic Recall
ARDDN Automatic Recall of Diallable Directory Number
ARP Address Resolution Protocol (finding the Ethernet address for an IP address)
ASN Abstract Syntax Notation
ASPEN Proprietary device control protocol used to control PVG media gateways
ATA ASCII Terminal Access (OAM&P application)
ATM Asynchronous Transfer Mode
AUL Automatic Line (line service)
AVT Audio / Video Transport (IETF working group)
AXU Alarm Cross-Connect Unit (connectivity for optional OAU)
BCP Best Common Practice

BCT Bearer Channel Tandeming (for LI)
BDF Binary Distribution Format
BHCA Busy Hour Call Attempts
BICC Bearer Independent Connection Control (ISUP with packet extensions)
BML Buriness Management Layer (in TMN hierarchy)
BNS Billing to the Nearest Second (for NAOC)

17 August 2004 Nortel Networks xv
BOOTP Bootstrap Protocol

BSL Bar-Separated Log
CAC Connection Admission Control

CBM Core and Billing Manager (successor / alternative to SDM)
CBR Constant Bit Rate
CC Call Control
CCB CEPT Call Back (implemented via AR)
CCBS Call Completion to Busy Subscriber
CCD Clear Channel Data (as used for ISDN data calls)
CCF Call Control Function (call processing model used for IN)
CCF Call Control Frame (PTE2000 housing CS2000-Compact Core)
CCITT Consultative Committee for International Telephone / Telegraph (now ITU)
CCS7 Common Channel Signalling System No. 7 (also called SS7)
CCW Cancel Call Waiting (line service)
CDP Charge Determination Point (for NAOC)
CEM Common Equipment Module (IW-SPM controller card)
CES Circuit Emulation Service
CFB Call Forward on Busy (line service)
CFD Call Forward on DoesntAnswer (line service)
CFDVT Call Forward on DoesntAnswer with Variable Timer (line service)
CFNA Call Forward on No Answer (see CFD)
CFNR Call Forward on No Reply (see CFD)
CFU Call Forward Unconditional (line service)
CG4500E Hardware platform for MTA line gateway
CGP Charge Generation Point (for NAOC)
CHD Call Hold (line service)
CIC Carrier Identification Code (as used in IA carrier selection)
CIC Circuit Identification Code (in MTP routing label)
CICM CentrexIP Client Manager
CID Correlation ID
CLASS Custom Local Area Signalling Services
CIEC Chosen Intermediate Exchange Carrier
CLF Calling Line Flash (MCID)
CLI Calling Line Identification (caller number)
CLLI Common Local Language Identifier (identifying trunk destination)
CLUI Command Line User Interface
CM Computing Module (alternative name for XA-Core or Compact 3PC)
CMT CS2000 Management Tools
CMTS Cable Modem Termination System
CNAB Calling Name Delivery Blocking (line service)
CNAMD Calling Name Delivery (line service)
CND Calling Number Delivery (line service, 10-digit CLIs only)
CNDB Calling Number Delivery Blocking (line service)
CO LAN Central Office LAN (name previously used for CS LAN)
COPS Common Open Policy Service (GWC - CMTS signalling for CAC)
CORBA Common Object Request Broker Architecture (as used by PMSS)
cPCI Compact Personal Computer Interface
CPE Customer Premises Equipment
CPS Carrier Pre-Selection (as used in indirect access)
CR Centralised Replicator (used to implement LI BCT for packet network calls)
CRCX Create Connection (ASPEN message)
CRR Conditional Re-Routing (of ISUP call if congestion is encountered)
CRR Call Retrieval Request (for voice mail)

xvi Nortel Networks 17 August 2004
CSP Communication Services Platform (CS2000 Base / Telecom layer software)

CS Call server (alternative name for Communication Server)
CS Comunication Server
CS LAN Communication Server LAN (as used to connect CS2000 components)
CS2000 Nortel Networks Communication Server described in this document
CS2E SDM software load supporting CS2000 Core Manager
CS2M CS2000 Management Tools (Sun server load supporting EMs)
CSP Carrier Selection Parameter (for inter-network use)
CSV Comma-Separated Values (format for data file)
CUG Closed User Group
CWT Call Waiting (line service)
CXR Call Transfer (line service)
DCE Distributed Computing Environment

DCOS Data Collection Operations System (passive collection of performance OMs)
DCP Device Control Protocol
DDMS DMS Data Management System (OAM&P application)
DDN Delivery of Diallable Number (line service)
DHCP Dynamic Host Configuration Protocol
DLCX Delete Connection (ASPEN message)
DM Domain Management
DMC Device / Media Control (signalling between GWC and gateway)
DMZ Demilitarised Zone (network supporting public address domain)
DNS Domain Name Server
DN Directory Number
DOCSIS Data Over Cable System Interface Specification (CMTS - MTA signalling)
DOR Denied Origination (outgoing call barring)
DPNSS Digital Private Network Signalling System
DPT Dynamic Packet Trunk (for inter-CS communication via SIP-T or BICC)
DQoS Dynamic Quality of Service
DS Data Store (XA-Core memory used to store customer data)
DSLAM Digital Subscriber Line Access Multiplexer
DSM-CC Digital Storage Media Command and Control (protocol used for RAS)
DSS1 Digital Signalling System No1 (Q.931)
DSP Digital Signal Processor
DTC Digital Trunk Controller
DTD Document Type Definition (for XML file)
DTM Denied Termination (incoming call barring)
DTMF Dual-Tone Multi-Frequency (tones used in dialling)
E1 2Mb/s PCM30 carrier (international TDM standard)

EADAS Engineering and Administrative Data Aquisition System (early DCOS)
EBIP Electrical Breaker Interface Panel
EID Endpoint Identifier (for a particular channel on a particular E1 at a gateway)
EIOP XA-Core IOP equipped with Ethernet packlet (now superseded by HIOP)
ELN Essential Line
EM Element Manager (for an NE)
EML Element Manager Layer
EMS Element Management System (OAM&P server type or application)
ESA Emergency Stand-Alone
ETA Enhanced Terminal Access (OAM&P application)
ETSI European Telecommunications Standards Institute
EuroDOCSIS DOCSIS standard defined for use in Europe

17 August 2004 Nortel Networks xvii
FCM Fabric Control Message (used to co-ordinate GWCs)

FLPP Fiberised Link Peripheral Processor (SG terminating CCS7 signalling links)
FP Function Processor
FQDN Fully Qualified Domain Name (identifies an IP network host)
FSM Finite State Machine
G.703 ITU-T standard for PCM30 interface (E1 carriers)

G.711 ITU-T standard for A-law and m-law PCM of speech transported at 64Kb/s
G.726 Compression codec supported for VoAAL2 solutions
G.729 Compression code supported with effect from ISN05
GARP Gratuitous ARP (broadcast indicating change in IP/MAC address mapping)
GEM Gigabit Ethernet Module (packet-side interface for IW-SPM)
GigE Gigabit Ethernet
GoS Grade of Service (resilience / availability of packet network)
GUI Graphical User Interface
GW Gateway
GWC Gateway Controller (CS2000 peripheral housed in SAM21)
H.248 Standard device control protocol for media gateway control (used for UAS)
H.323 Set of ITU-defined IP protocols for conveying voice and other media types
HFC Hybrid Fibre Coax (used to support digital cable access networks)
HIOP High-capacity XA-Core IOP supporting Ethernet (standard since ISN03)
HLM Higher-Level Management (OAM&P applications covering multiple NEs)
IA Indirect Access
IAC Integrated Access Cable (network solution supported by CS2000)
IAD Integrated Access Device (combined line media gateway and WAN access
device on customer premises)
IAM Initial Address Message (initiating ISUP or TUP call)
IAW Integrated Access Wireline (network solution supported by CS2000)
IBL Initial Boot Load (for GWC to notify GWC EM when installed)
IBN Integrated Business Network (support for proprietary value-added services)
IBN7 Proprietary variant of ANSI CCS7, providing networked support for IBN
ICE IPConnect Call Engine (alternative name for SoftSwitch or CS3000 TSS)
ID Internet Draft (proposed IETF standards document)
IE Information Element (ISDN parameter)
IEC Inter-Exchange Carrier
IEMS Integrated Element Management System
IETF Internet Engineering Task Force (standards body for internet protocols)
I-ISUP Interconnect ISUP
IMS Interactive Multimedia Server (pre-ISN07 name for MCS5200)
IN Intelligent Networking
INAP Intelligent Networks Application Part (CCS7 protocol)
IOM Input-Output Module (datalink used to bring CS2000 into service)
IOP Input-Output Processor (XA-Core component)
IP Internet Protocol
IP Intelligent Peripheral (supports IN SRF functionality)
IPSP IP Signalling Point (CCS7 node with IP signalling connection)
ISDN Integrated Services Digital Network
ISM Integrated Service Module (used to house IOMs)
ISN International Succession Networks
ISN07 International Succession Networks Release 07 (described in this document)
ISP Internet Service Provider
ISUP ISDN User Part (CCS7 protocol)

xviii Nortel Networks 17 August 2004
ITU-T International Telecommunication Union-Telecommunications

ITX Internet Telephony Extender (links between MG9000 shelves)
IU Interface Unit (generic term for LIU and EIU)
IUA ISDN User Adaptation (IETF protocol to carry Q.921 user info, e.g. Q.931)
IVR Interactive Voice Response
IW-SPM Interworking SPM
Kb/s Kilobits per second
L2TP Layer 2 Tunneling Protocol (as used for RAS calls through packet network)
LAN Local Area Network
LCI Local Craft Interface
LCR Least Cost Routing
LDAP Lightweight Directory Access Protocol
LEA Law Enforcement Agency
LEN Line Equipment Number (virtual physical address associated with line DN)
LI Lawful Interception (regulatory service allowing an LEA to monitor calls)
LIS Link Interface Shelf (in FLPP)
LMM Line Maintenance Manager
LNP Local Number Portability
LNR Last Number Redial (line service)
LTM Line Test Manager
M2PA MTP2-User Peer-to-Peer Adaptation (for CCS7 messaging over IP network)

M2UA MTP Layer 2 User Adaptation (superseded in ISN07 by M2PA)
M3UA MTP Layer 3 User Adaptation (for CCS7 messaging via CS2000 CS LAN)
MAC Media Access Control (a MAC address is a Layer 2 network address)
Mb/s Megabits per second
MCCS Multi-Country Call Server (one CS2000 with gateways in several countries)
MCID Malicious Call Identification
MCMP Media Control Message Protocol (for specifying currency/language to UAS)
MCS5200Multimedia Communication Server 5200
MDCX Modify Connection (ASPEN message)
MEGACO Alternative name for H.248 media gateway control protocol (also the name
of the IETF working group that developed H.248)
MG Media Gateway (as defined in MEGACO architecture)
MGC Media Gateway Controller (network role of CS2000)
MGCP Media Gateway Control Protocol (used to control LAN line gateways)
MIB Management Information Base (object-oriented SNMP information model)
MIME Multi-purpose Internet Mail Extensions (for determining how to handle data)
-law North American PCM standard used for speech path encoding/companding
MMU Memory Management Unit
MMUSIC IETF working group (originally responsible for SIP and SDP)
MPC Multiple Point Code (ability for CS2000 to have up to 31 CCS7 point codes)
MPCP Media Proxy Control Protocol (used to control RTP Media Portal)
MPLS Multi-Protocol Label Switching (possible Layer 2 implementation for VoIP)
MS Message Switch
MTA Multimedia Terminal Adapter (line gateway supporting VoIP over cable)
MTP Message Transfer Part (CCS7 part supporting OSI Layer 1-3 functions)
MTU Maximum Transmission Unit (conveyed in an ATM service record)
MWI Message Waiting Indicator
NAOC Network Advice Of Charge (ISDN service)

NAPT Network Address and Port Translation

17 August 2004 Nortel Networks xix
NAT Network Address Translation

NCAS Non Call Associated Signalling (e.g. TCAP)
NCL Non-CM Load
NCOS Network Class Of Service (mechanism for call screening)
NCS Network-based Call Signalling (between CS2000 GWC and MTA)
NDND Non-DMS Name Delivery
NE Network Element
NEL Network Element Layer (in TMN hierarchy)
NEBS Network Equipment Building System
NFS Network File Server (as used by CS2000-Compact)
NIC Network Identification Code (Nortel term for NRN, as used in NP)
NIIF Network Interworking Industry Forum (predecessor to ACIF)
NLO New Licensed Operator (competing with an established PTT)
NM Network Management
NML Network Management Layer (in TMN hierarchy)
NNSC Nortel Networks Service Class (for marking and prioritising traffic)
NP Number Portability
NPM Network Patch Manager
NRN Network Routing Number (as used in NP)
NRR Network Re-Routing (of ISUP call if congestion is encountered)
NSP Network Services Platform (OAM&P desktop)
NTFY Notify (ASPEN/NCS message indicating occurrence of monitored event)
NTMOS Network Traffic Management Operation System (near real-time trunk OMs)
OAM&P Operations, Administration, Maintenance and Provisioning

OC Optical Carrier (SONET optical signal format)
OC-3 OC Level 3 (155 Mb/s, North American equivalent to STM-1)
ODP Open Dial Plan
OLEC Originating Local Exchange Carrier
OSS Operations Support System (centralised OAM&P application)
OSSDI OSS Data Interface
PAM Pluggable Authentication Module
PBX Private Branch Exchange
PCL Product CM Load
PCM Pulse Code Modulation (as used to digitise speech)
PDP Policy Decision Point (for COPS-based CAC)
PE Processor Element (XA-Core component)
PEC Product Engineering Code (Nortel hardware idenifier)
PEEL Protel Environment Emulation Layer
PEP Policy Enforcement Point (for COPS-based CAC)
PID Package Identifier (part of PID/TID used to denote a tone)
PLC Packet Loss Concealment (used to camoflage gaps in packetised speech)
PM Peripheral Module
PMDM Preside Multi-service Data Manager (for management of PVGs)
POTS Plain Ordinary Telephone System (basic telephony)
PP Passport (family of ATM and IP switches and media gateways)
PP7480 Passport 7000 PVG
PP8600 Passport 8600 routing switch on which the CS2000 CS LAN is based
PP15000 Passport 15000 PVG
PPVM Peripheral Processor Virtual Machine (CS2000 internal protocol)
PRI Primary Rate Interface (ISDN)
PS Program Store (XA-Xore memory used to hold executable code)
PSS1 Private Signaling System No1 (QSIG)

xx Nortel Networks 17 August 2004
PSTN Public Switched Telephone Network

PTE Packet Telephony Equipment
PTE2000 Frame used to house SAM21 shelves for GWCs and CS2000-Compact
PTM Packet Telephony Manager (old name for SSPFS / SESM)
PVC Permanent Virtual Circuit (statically allocated AAL2 or AAL5 channel)
PVC Protocol Version Control (used to distinguish PRI variants and issues)
PVG Packet Voice Gateway (PP7480 or PP15000 supporting VoIP or VoATM))
QCA QoS Collector Application (for end-of-call QoS data provided by GWCs)
QoS Quality of Service
RAID Rapid Access Integrated Disk

RAS Remote Access Service (support for dial-up data calls)
RAS Registration, Admission and Status (H.323/H.225 capability)
RES Resume (reactivate service to line)
RFC Request For Comment (IETF document type for defining internet standards)
RFC1350 Internet standards document for TFTP
RFC1542 Internet standards document for BOOTP
RFC1889 Internet standards document for RTP
RFC2030 Internet standards document for SNTP
RFC2045-9Internet standards documents for MIME
RFC2131 Internet standards document for DHCP
RFC2327 Internet standards document for SDP
RFC2543 Internet standards document for SIP
RFC2960 Internet standards document for SCTP
RFC3015 Internet standards document for H.248
RFC3057 Internet standards document for IUA
RFC3435 Internet standards document for MGCP
RISC Reduced Instruction Set Computing
RM Resource Module (for IW-SPM)
RMGC Redirecting MGC (enables line media gateway to find IP address of GWC)
RMI Remote Maintenance Interface
RMP RTP Media Portal
RQNT Request Notification (ASPEN/NCS message to initiate monitoring)
RRC Re-Routing on Congestion (of ISUP call)
RSA Registered Site Access (remote access to VPN)
RSIP Realm-Specific Internet Protocol
RTP Real Time Protocol (as used for media streams through IP network)
RTCP Real Time Control Protocol (complements RTP by monitoring data delivery)
SACB Subscriber Activated Call Barring (line service)

SAM Service Application Module
SAM16 16-slot CS2000 SAM used as UAS
SAM21 21-slot CS2000 SAM used to house GWCs
SAPI Service Access Point Identifier (for ISDN Layer 2/3 communication)
SBC Single-Board Computer
SCA Selective Call Acceptance (screening service for lines)
SCC2 Switching Control Centre 2 (format used to standardise multi-vendor logs)
SCF Service Control Function (for IN)
SCF Selective Call Forward (screening service for lines)
SCL Speed Calling, Individual Long List (line service)
SCP Service Control Point (for IN)
SCS Speed Calling, Individual Short List (line service)
SCSI Small Computer System Interface

17 August 2004 Nortel Networks xxi
SCP CCS7 Service Control Point

SCRJ Selective Call Rejection (screening service for lines)
SCTP Stream Control Transmission Protocol (IETF reliable transport protocol)
SCU Service Control Unit (term sometimes used for SAM21 housing GWCs)
SDH Synchronous Digital Hierarchy
SDM SuperNode Data Manager (hardware supporting PMSS XA-Core EM)
SDN Secondary Directory Number (Teen Service)
SDP Session Description Protocol (used to complement ASPEN and SIP-T)
SEAL Simple and Efficient Adaptation Layer (AAL5)
SESM Succession Element and Subnetwork Manager
SFT Secure File Transfer
SG Signalling Gateway (as defined in MEGACO architecture)
SGC Succession Gateway Controller (term sometimes used for GWC)
SIBB Service-Independent Building Block (for creating IN services)
SIGTRAN IETF working group on IP transport protocols (SCTP, IUA, M2PA, M3UA)
SIP Session Initiation Protocol (IETF protocol)
SIP-T Session Initiation Protocol for Telephony (supports CCS7 encapsulation)
SL Secondary Language
SLE Screening List Editing
SLG Log Generation
SM Shared Memory (XA-Core component)
SMDI Simplified Message Desk Interface (data link for voice mail)
SML Service Management Layer (in TMN hierarchy)
SMS Succession Management System (old name for PMSS)
SN Succession Networks
SNH Succession Networks based on H.248 (alternative name for ISN software)
SNH01 First generally available SNH software release (predecessor to ISN03)
SNM Succession Network Manager (software load supporting Core Manager)
SNMP Simple Network Management Protocol (for EM/NE communication)
SPFS Succession Platform Foundation Software
SPM Spectrum Peripheral Module
SRF Specialised Resource Function (for IN)
SS Session Server
SS7 Signalling System No. 7 (also called CCS7)
SSF Service Switching Function (for IN)
SSH Secure Shell
SSP CCS7 Service Switching Point
SSPFS Succession Server Platform Foundation Software
SS-SS BCPSoftSwitch-SoftSwitch Best Common Practice (old name for SIP-T)
SSV Sucession Subnet View
SSV Semicolon-Separated Values (format for data file)
STD Nortel standard log format
STM Synchronous Transfer Mode (SDH signal format)
STM-1 STM Level 1 (155 Mb/s, equivalent to OC-3)
STORM Storage Manager (file storage for CS2000-Compact)
STP CCS7 Signalling Transfer Point
SU Service Unit (card used to support GWC functionality)
SUS Suspend (deny service to line)
SUSP Subscriber Usage-Sensitive Pricing (billing for feature usage)
SVC Switched Virtual Circuit (dynamically allocated AAL2 or AAL5 channel)
SWACT Switch of Activity (inactive standby unit taking over from active unit)
TDM Time Division Multiplexing (traditional telephony switching)

TEI Terminal Endpoint Identifier (for ISDN)

xxii Nortel Networks 17 August 2004
TFTP Trivial File Transfer Protocol

TID Terminal Identifier (as used by XA-Core call processing to identify a trunk)
TID Tone Identifier (part of PID/TID used to denote a tone)
TLEC Terminating Local Exchange Carrier
TMM Trunk Maintenance Manager
TMN Telecommunications Management Network
TNS Transit Network Selection (CSP for intra-network use)
TR740 Bellcore standard for DCOS performance data
TR746 Bellcore standard for NTMOS performance data
TSS Telephony Soft Switch (e.g. CS2000)
TUP Telephony User Part (CCS7 protocol)
UA User Adaptation
UAS Universal Audio Server (proprietary media server used by CS2000)
UDP User Datagram Protocol (unreliable / best-try protocol running over IP)
UP Universal Port (gateway supporting dial-up RAS as well as VoIP)
URI Uniform Resource Identifier (as used in SIP-T)
USP Universal Signalling Point
VBD Voice Band Data

VBR Variable Bit Rate
VLAN Virtual LAN (as supported by PP8600 routers)
VM Voice Mail (line service)
VME Versa Module Europe (industry hardware standards)
VoATM Voice over ATM
VoIP Voice over IP
VRDN Virtual Routing Distribution Node (GWC supporting DPTs)
VRRP Virtual Router Redundancy Protocol (as used between CS LAN PP8600s)
VSP Voice Service Processor (PVG component for circuit/packet conversion)
WAN Wide Area Network

WML Warm Line (line service)
WUCR Wake-Up Call Request (line service)
X.25 ITU-T packet-switching standard

XA Extended Architecture (as in XA-Core)
XAI Extended Architecture Interconnect (XA-Core internal comms links)
XML Extensible Markup Language (data self-description via DTD and tags)

17 August 2004 Nortel Networks xxiii
Part A
Overview
CS2000 International Product Description Part A Chapter A1
Communication Server Capabilities Overview Market Overview
Chapter A1 Market Overview

CS2000 is a key part of the Nortel Networks product portfolio for the support of
converged carrier networks. Converged networks are managed IP core networks that
simultaneously support real-time IP telephony, multimedia and a range of non-real-time
data services. The justification for deploying them is that they can deliver a combination
of immediate and longer-term benefits for network operators.
The rationale for the initial deployment of converged networks is based on their enabling
network operators to achieve cost savings in the short term, i.e. within two to five years.
There are two main ways in which this short-term benefit can be realised:
! Network bandwidth can be used more efficiently. Bandwidth for voice traffic is
used only when voice packets actually need to be transmitted, rather than being
statically reserved as with TDM voice circuits. Bandwidth efficiency is also
promoted by the ability to combine different traffic flows with varied requirements.
! Operational costs can be reduced because only one network infrastructure needs to
be supported, which also simplifies management and maintenance via centralised
OSS/BSS applications.
Over the longer term, the main benefit of converged networks is their ability to serve as a
unified platform for new services, particularly multimedia services that are genuinely
integrated. As with traditional telecommunications networks, network operators will
receive revenue both from services that they develop and provide directly, and from
providing appropriate facilities to specialised service providers. Operators who choose
not to make the strategic shift to converged networks will be unable to benefit from these
new revenue streams, and may find themselves left behind as purveyors of legacy services
and undifferentiated bandwidth with only commodity value.
CS2000 is uniquely placed to enable network operators to adopt the new packet-based
network architecture without having to restrict themselves in terms of the capabilities and
services they can offer to their customers. This is because the CS2000 software load
includes call processing agents, translations, routing, billing and services software that
have been proven on other Nortel platforms in a wide range of international markets.
New alternative operators can use CS2000 as the basis for future-proof networks that can
compete cost-effectively with those of established operators. For such established
operators, on the other hand, CS2000 can enable the transition from TDM to packet
architecture to be seamless, with existing services remaining fully operational and
continuing to generate revenue throughout the upgrade process.

17 August 2004 Nortel Networks 2
Chapter A2 Network Overview
A2.1 MEGACO Network Architecture

The network architecture implemented by CS2000 is based on a conceptual model
defined by the IETF MEGACO (Media Gateway Control) working group [1]. This model
specifies the logical functions that must be provided in a packet backbone network used
to support multimedia traffic. Some of these logical functions exist within the packet
network; others exist at its periphery, supporting access to the packet network from TDM
networks and from various types of access network.
A gateway provides an interface between two domains, e.g. between a packet network and
a TDM network. This involves two types of gateway functionality:
! A media gateway provides an interface for bearer connections, e.g. mapping a
packet-based media stream on to a circuit-based media stream, seamlessly
providing any required format conversion while maintaining content integrity.
! A signalling gateway provides an interface for signalling connections. It terminates
legacy network signalling on one side and packet network signalling on the other,
and supports all necessary interpretation and conversion between the two.
These are logical functions, not node types. A given node may provide media gateway
functionality, signalling gateway functionality, or both. Similarly, gateway functionality
may be provided by a combination of nodes rather than a single node.
Gateways provide basic connectivity across the packet network. Additional capabilities
are provided by servers of various kinds within the packet network. In-band services such
as announcements and video are provided by media servers. Call processing capabilities
and related features are provided by communication servers (also known as call servers).
The control and co-ordination of packet network gateways to support applications such as
VoIP (Voice over IP) is the responsibility of a Media Gateway Controller (MGC). As with
gateways, an MGC is a logical function, not a node type. MGC functionality may be
provided by a combination of nodes rather than a single node, and it is possible for a given
node to provide server functionality as well as MGC functionality.
[1] This working group was also responsible for specifying the H.248 protocol defined in RFC3015.

Communication Server Capabilities Overview Network Overview
Figure 1 provides a generic view of the MEGACO network architecture, illustrating the
key principle on which it is based, i.e. the separation of media streams and signalling.
Media streams are handled in accordance with MGC instructions, but are not handled
directly by MGCs, only by media gateways and media servers.
See Figure 2 on page 6 for an illustration of how this generic network architecture is
implemented for a VoIP solution based on CS2000.
Media Media
Gateway Gateway
Controller Controller
(MGC) (MGC)
Core network
(packet backbone)
MGC-to-MGC signalling
MGC-MG MGC-MG
signalling: signalling:
Device/media Device/media
control Media control
Backhauled server Backhauled
call control call control
Announcements,
PSTN CCS7 signalling (e.g. ISUP)
PSTN CCS7 signalling (e.g. ISUP)

conferencing
Media Media
Media stream, e.g. packetised voice
Gateway Gateway
(MG) (MG)
Different types of access (list not exhaustive):

(1) CCS7 (trunk media gateway terminates
3 TDM bearer channels only) 3
(2) PRI PBXs, e.g. PRI (combined media and
2 signalling gateway terminates bearer 2
channels and supports backhaul of call
1 control signalling to MGC) 1
(3) Analogue lines (line media gateway
terminates bearer channel and in-band
DTMF)
PBX PBX
TDM network, e.g. PSTN
Figure 1: Generic view of MEGACO network archiecture

Chapter A2 Part A CS2000 International Product Description
Network Overview Overview Communication Server Capabilities
A2.2 CS2000 Implementation of MEGACO Architecture

CS2000 is a communication server providing call processing capabilities. In terms of the
MEGACO network architecture, it provides MGC functionality. Together with various
types of gateway and server, it can support VoIP (Voice over IP) or VoATM (Voice over
ATM), depending on the type of backbone packet network to be used. Specific CS2000
capabilities include:
! Basic connectivity and network element control
" Control over the media gateways that provide the bearer connection interface
between the packet network environment and other TDM or access networks.
In ISN07, CS2000 supports the following types of access via media gateways:
# CCS7 trunk access to/from the PSTN or another TDM network
# PRI and QSIG access for digital PBXs and other PRI-enabled devices
# V5.2 access, currently for analogue subscriber lines only
# Analogue line access via a variety of gateway types, including CPE
gateways attached to customer LANs or cable networks
" Control over media servers supporting capabilities such as announcements
and conferencing over the packet network.
" Originations and terminations for inter-CS signalling across the packet
network to/from other CS2000s and compatible MGCs such as MCS5200.
" Originations and terminations for TDM-side CCS7 signalling.
! Call processing
" A wide range of internationally proven call processing agents and protocols.
" Translations and routing for calls entering, leaving and crossing the packet
network.
" Support for requests to apply tones and announcements.
" Support for billing, event reporting and performance monitoring.
! Service support
" Support for specific sets of value-added features.
" Support for general-purpose service delivery platforms.
" Support for regulatory features, e.g. lawful intercept and number portability.
A CS2000 can be regarded as a single node, but it is not monolithic. The capabilities listed
above are provided by separate CS2000 components (see section A2.3), of which the most
important are Gateway Controllers (GWCs). These are used for two main purposes:
! To serve as controllers for media gateways, controlling their operation via
device/media control signalling based on packet network protocols.
Note: Depending on the type of access to be supported, a gateway may provide
signalling gateway functionality as well as media gateway functionality, in which
case the GWC and gateway will exchange call control signalling as well as media
control signalling. This is the case with PRI, QSIG, V5.2 and analogue line access.
! To support communication between peer communication servers for the handling
of networked calls. This is accomplished via inter-CS signalling, also based on
packet network protocols.
In the CS2000 architecture, GWCs are configured as CS2000 peripherals, but from an IP
network perspective a GWC is an independent host with its own IP address.
A range of packet network protocols have been developed for different types of
communication in which GWCs are involved. The protocols supported by CS2000 GWCs
are discussed in section A2.3.2. (Packet network protocols for communication between
media gateways are outside the scope of this document; the most important is RTP/RTCP
for VoIP bearer traffic.)

5 Nortel Networks 17 August 2004
Figure 2 provides a schematic view of CS2000 network architecture for VoIP (OAM&P
units omitted for simplicity).
CS2000 Core supports:

Call processing Media server switched
Translations / routing Session Server into calls to support:
Service logic supports SIP signalling Announcements
Core and GWCs together to/from peer MGCs Conferencing
support MGC functionality. BCT for LI
GWCs individually configured to support:
Device/media control for MGs USP supports CCS7
Backhauled call control for MGs Media proxy signalling to/from
H.323 access switched into calls CICM provides TDM networks via
CICM control to support services for remote dedicated signalling
DPTs between CS2000s NAT traversal for CentrexIP clients links (not via packet
Media server control media streams network)
Media proxy control between IP
RMGC functionality address domains
CS2000 CS LAN CS2000 CS LAN

CS2000 Core CS2000 Core
MS2000
GWCs MS2000
GWCs
Session
CICM Server Session
Server CICM USP
USP
Dual PP8600s Media proxies Dual PP8600s
Core network
PVG PVG PVG MG9000
Customer Edge Customer Edge

(CE) router (CE) router
PRI Enterprise
CCS7 or V5.2
trunks Access or network
QSIG enterprise
H.323 access to network
PBX V5.2 core network for:
AN M1 IP PBX
BCM CentrexIP clients
Lines
and CSE1000
ADSL Cisco routers Low-capacity
DPNSS GW media gateways,
PSTN or other e.g. IAD, MTA
TDM network
Figure 2: CS2000 network architecture

A2.3 CS2000 Support for Network Architecture

A2.3.1 Hardware Support
A2.3.1.1 CS2000 Components

In CS2000 release ISN07, the allocation of Communication Server functionality to
CS2000 components is as follows (see Chapter B1: CS2000 Hardware for details):
! Call processing, translation, routing and service logic are supported by the CS2000
processor complex (Core).
! The CS2000 CS LAN that links CS2000 components and enables them to
communicate with the managed IP core network is supported by dual PP8600
routing switches.
! CCS7 signalling gateway functionality is supported in two ways:
" For communication between the CS2000 network and TDM networks such as
the PSTN, CCS7 signalling is supported by the termination of TDM-side
CCS7 signalling links on either the Universal Signalling Point (USP) or the
FLPP (Fiberised Link Peripheral Processor). The corresponding trunks are
terminated on trunk media gateways controlled by GWCs.
" For communication across the managed IP core network between peer MGCs,
CCS7 is supported using DPTs (Dynamic Packet Trunks) terminated on DPT
GWCs. CCS7 signalling is conveyed encapsulated in SIP (Session Initiation
Protocol) messages. SIP signalling is terminated on the Session Server, which
extracts the CCS7 signalling and passes it on to the DPT GWC.
Note: Session Server support for SIP signalling and CCS7 encapsulation is
designed to be compliant with RFC3261, which defines a SIP interface for
open interoperability between call servers and other network elements. Prior
to the ISN07 introduction of the Session Server implementation, CS2000
support for SIP was based on pre-RFC3261 drafts and implemented by
configuring GWCs as VRDNs (Virtual Router Distibution Nodes) to provide
initial points of contact for peer-to-peer SIP signalling. This VRDN
implementation is still supported, but has now been superseded by the Session
Server implementation.
! GWCs can be configured to support and control VoIP access to the managed IP core
network for a wide range of media gateways and other units, as follows:
" Trunk media gateways supporting CCS7 trunks to/from the PSTN or other
TDM networks.
" Trunk media gateways supporting PBX interfaces (PRI, QSIG, DPNSS).
" V5.2 gateways supporting V5.2 access, currently for analogue lines only.
" Large carrier-located line media gateways supporting analogue subscriber
lines and ADSL (Asymmetrical Digital Subscriber Line) data access.
" H.323-controlled units such as IP-enabled PBXs and third-party routers.
" Low-capacity CPE line media gateways supporting access for analogue
subscriber lines attached to customer LANs or cable access networks.

" Remote CentrexIP clients attached to enterprise networks.

Note: CentrexIP clients are not controlled directly by GWCs, but by a CICM
(CentrexIP Client Manager) on the CS LAN; the CICM is in turn controlled
by a GWC. It is a twin-card unit that is housed alongside GWCs.
" Universal Port (UP) gateways supporting RAS dial-up access to internet
and/or intranet data sessions as well as VoIP voice calls.
! Dynamic Packet Trunks for inter-CS signalling based on CCS7 encapsulated in SIP
(Session Initiation Protocol) are supported by DPT GWCs with no subtending units.
DPTs are so called because trunk characteristics such as the ISUP protocol variant
to be used are determined on the basis of the telephony profile of the selected route,
which is downloaded to the DPT GWC during call establishment.
To support inter-CS signalling, the operation of DPT GWCs is co-ordinated with
that of one or other of the following unit types:
" The preferred implementation with effect from ISN07 is based on DPT GWCs
interacting with the Session Server. SIP signalling is terminated on the
Session Server, which extracts the CCS7 signalling and passes it on to the
DPT GWC.
" Prior to ISN07 (and still supported for existing deployments), the standard
implementation was based on a DPT GWC interacting with another GWC
configured as a VRDN (Virtual Router Distibution Node) to provide an
externally visible IP address as a point of initial contact for its host CS2000
In this implementation, DPT GWCs were responsible for terminating SIP
signalling and extracting CCS7.
See Figure 13 on page 62 for an illustration of how DPT GWCs interact with these
other units to support inter-CS communication via SIP.
designed to be compliant with RFC3261, which defines a SIP interface for open
interoperability between call servers and other network elements. The VRDN
implementation was based on pre-RFC3261 drafts and has now been superseded by
the Session Server implementation.
! GWCs can also be configured to support a range of gateways and other units that
provide specialised service support functionality, as follows:
" GWC for MS2000 Series media servers, which support:
# Announcements
# Conferencing
# Bearer Channel Tandeming (BCT) functionality for call monitoring via
the LI (Lawful Interception) regulatory service
Note: MS2000 Series media servers are compact, enhanced versions of the
UAS (Universal Audio Server), which provided media server functionality
prior to ISN07. Deployed UASs are still supported, but MS2000 Series media
servers are to be used for new deployments.
" GWC for RTP Media Portal providing media proxy functionality
The RTP media portal is a GWC-controlled media proxy. Its primary purpose
is to support public address discovery for media streams that have been routed
via a NAT. The media portal examines incoming packets on each of its ports
to determine their origin, and can thus work out the destination to which
return packets in the other direction should be sent. In a carrier network

supporting a CS2000 solution, each media proxy has two connections, one
with the private VoIP network and one with the carriers public network. This
enables it to support two specific capabilities:
# It supports communication with and between private address domains,
e.g. for enterprise networks hosting line media gateways and CentrexIP
clients, by enabling media streams that traverse NATs to be routed
across the carriers public network.
# It can act as a firewall to control the traversal of media streams into the
private VoIP address domain used for the CS2000 CS LAN and large
telco-located gateways.
! A GWC can be configured to support Redirecting Media gateway Controller
(RMGC) functionality, which enables line gateways to discover the address of their
controlling GWC.
The hardware characteristics of all types of GWC are essentially the same. CS2000
datafill is used to specify the intended function of each GWC and ensure that its software
load is configured appropriately.
From an IP network perspective, a GWC is an independent host with a Layer 3 IP address
that is externally visible, i.e. reachable from the carriers public network, plus other IP
addresses for CS2000 use. Other CS2000 components that have externally visible IP
addresses are:
! USP
! Session Server
! CICM
! Media servers (not strictly speaking CS2000 components, but typically on the CS
LAN)
! RTP Media Portal (not strictly speaking a CS2000 component, but can be on the CS
LAN)
The IP addresses of the CS2000 Core are not externally visible. The FLPP (if used)
supports only TDM-side functionality, and has no IP address.

A2.3.1.2 Gateways and Other GWC-Controlled Units

CS2000 release ISN07 supports the use of the gateway types listed below:
! Media gateways
Note: Media gateways are independent units with their own release schedules. The
range of supported gateways may therefore change within the life-cycle of a given
CS2000 release.
" Passport PVGs (Packet Voice Gateways) configured to support trunk access
PVGs can support either VoIP or VoATM for CCS7, ISDN PRI and QSIG
trunks. Two hardware platforms can be used to provide PVG capabilities:
# PP7480
# PP15000
" PVGs configured to support V5.2 access for analogue lines
PVGs can support VoIP for V5.2 interfaces supporting analogue lines. The
architecture and physical characteristics of a PVG configured to support V5.2
access are the same as those of a PVG configured to support trunk access.
" High-capacity line media gateways, typically located on operating company
premises. In ISN07, CS2000 supports the MG9000, a high-capacity media
gateway for analogue lines and ADSL (Asymmetrical Digital Subscriber
Line) access. The largest MG9000 configuration supported can terminate up
to 5920 POTS lines.
" CPE gateways and 3rd-party units controlled by CS2000 H.323 proxy (GWC
equivalent) via H.323 / H.225 / H.245:
# IP-enabled Meridian 1 PBXs
# IP-enabled Business Call Manager (BCM) PBXs
# CSE1000 Call Server for Enterprise
# Westell DPNSS gateways (DPNSS signalling encapsulated in H.323)
# Cisco 2600/3600 access routers
" CPE line media gateways attached to customer LANs, which are in turn
connected to the IP backbone network. Signalling between the GWC and the
media gateway is supported end-to-end using an IP Layer 3 protocol. Two
gateways of this type are used to support VoIP in ISN07:
# Ambit line media gateways and IADs supporting 1, 16 or 32 ports
# Askey line media gateways supporting 4, 12 or 30 ports
# Mediatrix 1124 line media gateways supporting 24 ports
" CPE line media gateways attached to cable access networks to support VoIP
for analogue subscriber lines. Two types of gateway can be used to support
these capabilities:
# Motorola MTA (Multimedia Terminal Adapter)
# Arris MTA
An MTA line gateway is not directly connected to the IP backbone network.
Instead, it is connected to a HFC (Hybrid Fibre Coax) cable access network,
which is in turn connected to the IP backbone network via a CMTS (Cable
Modem Termination System) and a PP8600 router. Signalling between the
GWC and the MTA is supported end-to-end using an IP Layer 3 protocol,
conveyed over the IP backbone for part of the way and over the HFC network
for the rest.

" Universal Port (UP) gateways that support RAS dial-up access to internet
and/or intranet data sessions via CCS7 trunks, as well as VoIP voice calls. The
gateway type used for this purpose in ISN07 is the CVX1800.
Note: CS2000 support for RAS has been tested and verified for deployment
only in a specific customer network, and is not generally available in ISN07.
! Remote CentrexIP clients controlled by the CentrexIP Client Manager (CICM)
CS2000 provides VoIP support for two types of CentrexIP client:
" Etherset clients
IP-enabled Ethernet telephone sets with a large display and programmable
softkeys.
" Soft clients
PCs running a telephony client application, with speech transmission and
reception supported via a headset attached to the PC and call control
capabilities provided by a screen-based GUI.
CentrexIP clients are controlled by the CentrexIP Client Manager (CICM). CS2000
perceives the CICM as a large gateway and CentrexIP clients as lines served by
CICM gateways, but the CICM is not a media gateway in MEGACO terms because
it handles only signalling traffic, not media streams. It can be regarded as a terminal
server, and its role is similar to that of a GWC controlling multiple small CPE line
gateways. CICMs are connected to the CS2000 CS LAN, and communicate with
their remote CentrexIP clients over the managed IP network. Each CICM subtends
and is controlled by a CS2000 GWC.
! MS2000 Series media server or Universal Audio Server (UAS)
MS2000 Series media servers are enhanced, compact versions of the UAS available
with effect from ISN07, though deployed UASs continue to be supported. Both
types of unit provide essentially the same media server capabilities, as follows:
" Packetised announcements provided to call parties in response to CS2000
requests.
Note: In general, tones are provided by gateways directly to their TDM-side
trunks and lines, not by a media server.
" Conference circuits for multi-party calls across the packet network.
" Bearer Channel Tandeming (BCT) functionality for the LI (Lawful
Interception) regulatory service, which allows packet network bearer
connections to be monitored by an LEA (Law Enforcement Agency).
MS2010 media servers for VoIP are housed in a 1U chassis designed to be mounted
horizontally in a standard 19" frame; MS2020 media servers for VoATM are
housed in a 2U chassis. UASs are housed in 16-slot SAM16 shelves. Media servers
are co-located with the CS2000 and connected to the CS LAN. In terms of CS2000
network architecture, however, a media server subtends a GWC, although it cannot
be categorised as a media gateway because it has no TDM-side connections.

! RTP Media Portal

The RTP media portal is a GWC-controlled media proxy. Its primary purpose is to
support public address discovery for media streams that have been routed via a
NAT. The media portal examines incoming packets on each of its ports to determine
their origin, and can thus work out the destination to which return packets in the
other direction should be sent. In a carrier network supporting a CS2000 solution,
each media proxy has two connections, one with the private VoIP network and one
with the carriers public network. This enables it to support two specific
capabilities:
" It supports communication with and between private address domains, e.g. for
enterprise networks hosting line media gateways and CentrexIP clients, by
enabling media streams that traverse NATs to be routed across the carriers
public network.
" It can act as a firewall to control the traversal of media streams into the private
VoIP address domain used for the CS2000 CS LAN and large telco-located
gateways.
From a packet network perspective, each media gateway is an independent node with its
own Layer 2 and Layer 3 addresses. A media gateway may have multiple addresses for
different purposes, as follows:
! Either IP or ATM addressing is used for originating and terminating media streams.
IP addressing is used for VoIP; ATM addressing is used for VoATM, and for VoIP
over AAL5 over ATM.
! IP addressing is used for device/media control signalling between a media gateway
and its GWC.
! IP addressing is used for backhauled call control signalling between a media
gateway and its GWC (PRI, QSIG, V5.2 and analogue line access only; not
applicable for CCS7).
! IP addressing is used for OAM&P signalling between a media gateway and its EM
(Element Manager).
For further information about the capabilities of the media gateways supported by
CS2000, see Chapter B2: CS2000 Support for Media Gateways. See Chapter B3:
CS2000 Support for Media Servers for information about the UAS.

A2.3.2 Software Support
A2.3.2.1 Packet Telephony Protocols

Because a CS2000 network is a distributed system rather than a monolithic unit, it is
necessary to consider CS2000 support for the IP protocols that are internal to the packet
network as well as the telephony interfaces that the CS2000 supports externally. Several
different types of IP signalling are involved in setting up calls across the packet network,
as summarised in the remainder of this section. See Part DPacket Telephony Protocols for
descriptions of each protocol, and particularly Figure 64 on page 236 for an illustration of
the protocol stacks with all the acronyms expanded.
Note: All packet network signalling is conveyed using IP at Layer 3, regardless of the
backbone network type. Intra-CS signalling uses IP over 100BaseT Ethernet. Signalling
between CS2000 and the packet backbone uses either IP over Gigabit Ethernet (for an IP
backbone network) or IP / AAL5 / ATM (for an ATM backbone network).
Protocol stacks used in setting up calls across the packet network:
! Access signalling between Gateway Controllers (GWCs) and media gateways.
! Network signalling between peer Communication Servers.
! SDP (Session Description Protocol) session description signalling specifying bearer
capabilities and address information.
! CCS7 signalling within the CS2000 itself.
These different types of packet network signalling are described in separate subsections
on the following pages.
Another packet network protocol supported supported by CS2000 is SNMP (Simple
Network Management Protocol). This is a general-purpose OAM&P interface for the
management and maintenance of network elements in a packet network. It is not used in
setting up calls. In a CS2000 network, it is used by the GWC EM (Element Manager) to
communicate with the GWCs it controls.
Access Signalling between Gateway Controllers (GWCs) and Media Gateways

Two types of access signalling are supported:
! Media or device control signalling that allows the GWC to control the
characteristics of the packet network bearer connections used for a call. Protocols
supported in ISN07:
" H.248 / UDP / IP
# Communication with PVGs configured as trunk or V5.2 gateways.
# Communication with large telco-located MG9000 line gateways.
# Communication with the CentrexIP Client Manager (CICM) that
controls remote CentrexIP clients.
# Communication with media servers to support announcements (tones
are provided by gateways), conferencing, LI and trunk testing.
H.248 is a joint ITU-T / IETF protocol defined in ITU-T Recommendation
H.248 and IETF RFC3015. It fully supports the same basic device/media
control capabilities as the proprietary ASPEN protocol that it has now
superseded (see below). More importantly, it is based on a more flexible
functional model that provides better support for multimedia and conference
capabilities.

" ASPEN / UDP / IP

Communication with PVGs configured as trunk gateways, in support of VoIP
or VoATM.
ASPEN is a proprietary protocol based on standard MGCP. It is a superset of
MGCP, supporting the same standard connection control commands plus a
number of additional proprietary commands defined to provide extra
maintenance functionality. It is still supported, but has now been superseded
by the standard H.248 protocol (see above).
" H.323 / (TCP or UDP) / IP
H.323 is an ITU-defined umbrella specification for use in the definition and
implementation of multimedia services supporting the integration of voice,
video and data applications. It should be regarded as a framework or
architecture rather then a protocol in its own right, because it actually
comprises a number of different protocols.
The underlying control protocol in the H.323 architecture is H.225, which
provides esentially the same range of call control messages as those defined
in Q.931. More importantly, H.225 allows other types of H.323 signalling to
be conveyed in order to support enhanced capabilities, as follows:
# H.225 defines RAS (Registration, Admission and Status) messages and
procedures for controlling access to the network.
# H.450 protocols provide service-related data definitions in ASN.1
format.
# H.245 defines messages and procedures to be used in setting up and
taking down logical channels within the context of a H.225 call.
" UniStim / RUDP / UDP / IP
UniStim is the protocol used by the CentrexIP Client Manager to
communicate with CentrexIP remote clients. It is a Nortel Networks protocol,
but is available under licence to other equipment vendors who wish to design
and manufacture CentrexIP-compatible terminals.
UniStim is a stimulus protocol whose command set enables a Network
Intelligence (NI), i.e. CICM, to control every aspect of the operation of a
client Internet Terminal (IT). To provide reliable transport over UDP,
UniStim uses a simple Go-Back-N scheme to provides a suitable Reliable
UDP (RUDP) layer for UniStim.
" NCS / UDP / IP
Communication with cable network line gateways, in support of VoIP.
NCS (Network-based Call Signalling), which is also based on MGCP, is
designed to support embedded VoIP client devices in a PacketCable
environment; it supports call control signalling as well as media control. It is
defined in PacketCable(TM) specification PKT-SP-EC-MGCP-I10-040402
(or later issue found at http://www.packetcable.com/specs).
" MGCP / UDP / IP
Communication with customer LAN line gateways, in support of VoIP.
MGCP (Media Gateway Control Protocol) is a protocol defined in IETF
RFC3435.

" MPCP / UDP / IP

Communication with RTP Media Portal to support media proxy functionality,
specifically to support public address discovery for media streams that have
been routed via a NAT. It thus makes NAT traversal possible for media
streams, and supports communication with and between private networks.
MPCP (Media Proxy Control Protocol) is a version of standard MGCP
enhanced with proprietary extensions designed to support multimedia
sessions and NAPT.
" DSM-CC / UDP / IP
Communication with CVX1800 UP gateways, in support of RAS and VoIP.
The Digital Storage Media Command and Control (DSM-CC) protocol is a
toolkit for developing control channels associated with MPEG-1 and
MPEG-2 streams. It is defined in a series of standards, of which the most
important is MPEG-2 ISO/IEC 13818-6, i.e. Part 6 of the MPEG-2 standard:
Extensions for DSM-CC.
! Backhauled call control signalling (setup and clearing messages) for message-based
non-CCS7 interfaces such as ISDN PRI, QSIG and V5.2, for which access network
signalling is terminated at the media gateway. Protocol stacks supported in ISN07:
" Q.931 / IUA / SCTP / IP
" QSIG / IUA / SCTP / IP
" V5.2 / V5UA / SCTP / IP
" DPNSS / H.323 / TCP / IP, which is interworked at the H.323 GWC to
DPNSS over QSIG
IUA (ISDN User Adaptation) over SCTP is defined in RFC3057. SCTP is defined
in RFC2960. V5UA (V5 User Adaptation) is defined in draft-ietf-sigtran-v5ua.
! Call control signalling for analogue subscriber lines. Protocol stacks supported in
ISN07:
" H.248 / UDP / IP (for lines served by high-capacity MG9000 gateways)
" MGCP / UDP / IP (for lines served by gateways on customer LANs)
" NCS / UDP / IP (for lines served by MTA gateways on cable networks)
In these cases, the protocol used for call control is the same protocol used for media
control, i.e. one protocol supports both types of signalling. Call control signalling
allows the GWC to be informed of events such as hook state changes, to initiate
digit collection, and to request the application of ringing and in-band tones.

Network Signalling between Peer Communication Servers

Three types of peer-to-peer signalling are supported:
! Circuit-oriented ISUP or TUP signalling
CCS7 is supported using DPTs (Dynamic Packet Trunks) terminated on DPT
GWCs. ISUP or TUP messages are conveyed across the managed IP core network
encapsulated within SIP-T messages by means of the MIME mechanism. The
protocol stack used is therefore:
" SIP-T (ISUP or TUP) / (TCP or UDP) / IP
CS2000 supports two different implementations of SIP / SIP-T.
With effect from ISN07, the recommended implementation is based on the use of
the Session Server to terminate SIP-T signalling. Session Server support for SIP
signalling and CCS7 encapsulation is designed to be compliant with RFC3261,
which defines a SIP interface for open interoperability between call servers and
other network elements. In this implementation, SIP signalling is terminated on the
Session Server, which extracts the CCS7 signalling and passes it on to the DPT
GWC.
Prior to the ISN07 introduction of the Session Server implementation, CS2000
support for SIP was based on RFC2543 and other pre-RFC3261 drafts and
implemented by configuring GWCs as VRDNs (Virtual Router Distibution Nodes)
to provide initial points of contact for peer-to-peer SIP signalling. In this
implementation, the DPT GWC is responsible for terminating SIP-T signalling as
well as CCS7 signalling. This VRDN implementation is still supported, but has now
been superseded by the Session Server implementation.
! SIP signalling with no encapsulated CCS7 signalling
SIP without CCS7 encapsulation is used for communication between CS2000 and
the Multimedia Communication Server 5200 (previously known as IMS). This is a
Nortel product that supports access to multimedia services and advanced telephony
features for SIP clients.
Because no encapsulated CCS7 messages are included in the SIP-T message, the
CCS7 meaning of each SIP-T message must be inferred from the message header
and parameters. In ISN07, the only CCS7 protocol that can be emulated is this way
is IBN7 (ANSI ISUP+). Protocol stack:
" SIP-T (no CCS7) / (TCP or UDP) / IP
! TCAP-based NCAS (Non Call Associated Signalling)
The CS000 USP used to terminate CCS7 signalling links with TDM networks can
also support NCAS with remote CS2000s (strictly speaking, with USPs belonging
to remote CS2000s) via the managed IP core network. Protocol stack:
" TCAP / SCCP / MTP3 / M2PA / SCTP / IP
M2PA (MTP2-User Peer-to-Peer Adaptation) is an IETF protocol for
communication over a packet network between systems with different CCS7 point
codes. It is defined in draft-ietf-sigtran-m2pa.
Note: The USP could also support ISUP or TUP signalling between CS2000s over
MTP3 / M2PA / SCTP / IP, but this capability is not used by the CS2000
international product. SIP-T encapsulation of ISUP or TUP is used instead.

SDP (Session Description Protocol) session description signalling

SDP signalling is used to complement both GWC-gateway signalling and inter-CS
signalling by specifying bearer capabilities and address information. SDP is defined in
IETF standards document RFC2327.
For VoIP, SDP conveys IP address information as specified in RFC2327. For VoATM,
SDP conveys ATM address information by means of SDP extensions defined in a
complementary ID (Internet Draft). See Chapter D1.3: Session Descriptions (SDP) for
more details.
SDP information is conveyed in one of two ways:
! To complement GWC-gateway signalling using H.248, ASPEN, NCS or MGCP,
SDP information is provided inside the device control messaging.
! To complement SIP-T inter-CS signalling, SDP information is encapsulated via the
MIME mechanism in the same way as ISUP messages (but separately).
Codec negotiation takes place between the media gateways involved in a call to determine
the correct codec to use. The aim is that the codec used should be the codec that is highest
in preference order and supported by both gateways. An SDP session description is used
to convey the capabilities of each media gateway to its GWC and to the far-end gateway.
An appropriate codec is then selected from the intersection of both gateways sets of
capabilities.
Intra-CS2000 CCS7 Signalling

Within a distributed system whose components can be accessed via a single CCS7 point
code, M3UA (MTP Layer 3 User Adaptation) can be used to convey user part messages
between those components. Each incoming message is distributed to the appropriate
component and presented to the appropriate user part (ISUP, TUP, TCAP) exactly as if
MTP Layer 3 was doing the distribution rather than M3UA.
In a CS2000 that uses the USP to terminate CCS7 signalling, the USP and the Core share
the same point code, and the USP uses M3UA to distribute incoming CCS7 messages to
the Core and directly to GWCs. Use of M3UA over the CS2000 CS LAN between USP
and the Core makes it unnecessary for the Core to provide MTP3 functionality.
The protocol stack used is CCS7 (Layers 4-7) / M3UA / SCTP / IP.

A2.3.2.2 Telephony Interfaces

CS2000 uses telephony interfaces to support voice calls and data sessions over packet
backbone networks for TDM or circuit-based PSTN switches, PBXs and lines.
Use of Telephony Interfaces to Support VoIP

Access to packet networks for VoIP and VoATM is supported in ISN07 over three types
of telephony interface:
! CCS7 interfaces such as ISUP and TUP.
! ISDN PRI, QSIG and DPNSS interfaces for digital PBXs. PRI access is also
supported for other PRI-enabled devices such as IN external IPs (Intelligent
Peripherals).
! Analogue subscriber lines served by cable access networks, customer LANs or V5.2
Access Networks (ANs).
See Chapter A3: Product Overview for a list of supported interface variants and a matrix
summarising the interworkings between them. See Part ETelephony Interfaces for
descriptions of each interface, and Part FFeatures and Services for information about
support for telephony services across the packet backbone network.
Use of Telephony Interfaces to Support Data Sessions

CS2000 also uses telephony interfaces to support access to packet networks for data
sessions, as follows:
CentrexIP Remote CentrexIP clients are connected to the managed IP core network
using a single port that supports both VoIP and Ethernet 10/100BaseT
connectivity for data sessions initiated and controlled via the end users PC.
ADSL Digital Subscriber Line technology exploits unused frequencies to support
simultaneous transmission of voice and high-speed data over conventional
copper telephone lines. The service is "always on", meaning that subscribers
don't need to dial in or wait for call set-up.
ADSL (Asymmetrical DSL) is so called because it allows data to be
downloaded much faster than it can be uploaded (6Mb/s downloading vs
640Kb/s uploading), reflecting what users typically require. ADSL is defined
in ITU-T Recommendation G.992.1 and ANSI Standard T1.413-1998.
In ISN07, CS2000 supports ADSL for subscribers served by high-capacity
MG9000 line media gateways.
RAS Remote Access Service means support for dial-up access to internet and/or
intranet sessions. In ISN07, CS2000 supports RAS for incoming calls over
CCS7 trunks (IUP/BTUP and UK ISUP).
CS2000 also supports multimedia services by means of so-called blended user
capabilities. Blended users can have screen-based interactive access to databases and
media sources while simultaneously participating in a VoIP phone call established via
CS2000. In ISN07, multimedia services for CS2000 solutions are provided by the
MCS5200 described in Chapter B6: Multimedia Communication Server (MCS52000).
Multimedia sessions hosted by the MCS5200 Application Server enable blended users to
communicate with MCS5200 while simultaneously participating in a VoIP phone call
established via CS2000.

A2.4 The Backbone Packet Network

A2.4.1 Network Characteristics
The backbone packet network actually comprises two logically distinct networks:
! The bearer network used to convey media streams such as speech, data or video.
! The control network used to convey signalling, e.g. to set up and control bearer
connections between media gateways.
For convenience, this document refers simply to IP or ATM backbone packet networks.
It is important to understand that this refers to the bearer network, not the control network.
The control network uses IP at Layer 3 regardless of whether the bearer network is based
on IP or ATM. References to ATM therefore mean an ATM backbone network with
AAL2 used for bearer connections and IP over AAL5 for signalling. An IP bearer network
can use a range of implementation options, including ATM at Layer 2.
Note: CS2000 supports line access only for IP backbone networks.
A2.4.2 PSTN Equivalence for Packet Networks

A2.4.2.1 Comparisons and Objectives
To date, IP core networks have primarily been engineered to meet the requirements of
data services. These include dial-up and always-on Internet access, content hosting,
corporate intranets and IP VPNs. What these have in common is that they are
delay-tolerant applications that can be adequately supported using the conventional
Internet best-effort service model. Traffic is processed and conveyed as rapidly as
possible, but with no guarantee of timeliness or reliability, regardless of traffic type.
Congestion results in poorer response times for all connected users.
CS2000 VoIP solutions impose different requirements on IP core networks, as described
in the separate document Telephony Requirements for Carrier IP Networks. The
overall requirement is to achieve PSTN equivalence, i.e. no perceived degradation of
service for traffic that would previously have been conveyed over a circuit-switched
PSTN. This overall requirement for carrier grade service implies the following:
! Carrier grade performance or QoS (Quality of Service) is specified in terms of
targets and limits for the core networks contribution to latency, jitter and packet
loss for voice and voice-band data (see section A2.4.2.2 on page 20 for details).
! Service dependability derives from the design and traffic engineering of the core
network. It requires high router availability combined with mechanisms for fast
re-routing of traffic onto backup paths in the event of link or network element
failures. The main characteristic of carrier grade dependability is typically
summarised as "five nines" or 99.999% availability, corresponding to about 5
minutes accumulated down time per year.
! For TDM networks, GoS (Grade of Service) is defined as the likelihood of being
able to set up a call, and is given by the probability of encountering blocking. GoS
can be determined only at an admission control point, and is typically in the range
0.1% to 0.5%. For a packet network to use this definition of GoS, CAC (Call
Admission Control) mechanisms must be used to prevent access to the network if
sufficient resources are not available. Otherwise, congestion will result in poorer
voice quality not only for new calls but also for calls already in progress.

A2.4.2.2 QoS (Quality of Service) Metrics and Mechanisms

Quality of Service metrics are used to provide measurable targets for factors that affect
the perceived quality of bearer streams conveyed over a packet network, e.g. the
perceived quality of speech delivered via VoIP or VoATM.
The QoS metric most often used in assessing voice quality is latency, i.e. the total
end-to-end delay incurred in conveying speech between users. Excessive latency makes
echo more noticeable and can disrupt conversational flow. To ensure there is no
significant degradation in voice quality for VoIP calls, Nortel recommends that overall
latency should not exceed 150ms.
Distance-related propagation delays contribute equally to latency figures for circuit-based
networks and packet-based networks. In addition to distance, however, VoIP/VoATM
speech quality is also affected by a number of factors that are specific to packet networks,
as follows:
! Media gateway processing
Codec processing takes place at the ingress media gateway where a call enters the
packet network, and also at the egress media gateway where it leaves the packet
network. This processing imposes additional delay or latency, which contributes
towards the overall end-to-end latency figure.
! Packet delay variation (jitter)
Variations in latency arises from queueing and routing delays as packets traverse the
core network. To ensure that this does not cause gaps in speech media streams, a
terminating media gateway may use a jitter buffer to hold packets before they are
played out. This holds packets for long enough to eliminate inter-packet gaps
caused by jitter, at the expense of introducing additional delay (equal to the jitter
buffer size) that contributes to the overall end-to-end latency figure. Packets
delayed by more than the buffer size are lost because they miss their playout times.
Hence packet delay variation and packet loss are closely related.
! Packet mis-sequencing
Packets that follow different routes may be received out of sequence. In this case,
the terminating media gateways jitter buffer can be used to hold received packets
so that they can be re-ordered into the correct sequence before they are played out.
An alternative is to engineer the core network to ensure that all the bearer packets
for a call follow the same route.
! Packet loss
Loss of packets between media gateways can cause gaps in a speech flow being
played out. In a packet-based network, congestion increases packet loss. Calls
continue to be set up, but voice quality is impaired both for new calls and for
existing calls. This is in contrast with congestion in a circuit-based network, which
has the effect of preventing calls from being set up.
Media gateways collect information about packets/octets sent, packets/octets received
and packets lost/discarded in the course of a call, and provide these QoS statistics to their
CS2000 GWCs when the call is complete.

Chapter A3 Product Overview
A3.1 Configurations Available

To meet the needs of different types of customer, two types of CS2000 hardware
configuration are supported in ISN07:
! Standard CS2000 configuration
Note: The term standard configuration describes a CS2000 that uses the XA-Core
processor complex, and can denote either a full SuperNode configuration or a
streamlined SNSE (SuperNode Size Enhanced) configuration.
! CS2000-Compact configuration
Both types of configuration support the same range of call processing agents, protocols
and telephony features. The main differences between them are that the CS2000-Compact
uses a different processor complex, has a significantly smaller system footprint, and
currently delivers reduced call processing capacity. It is therefore more appropriate for
small applications.
A CS2000 Communication Server is a distributed system comprising a number of
different functional elements. The main functional elements are common to both types of
CS2000 configuration, but there are some differences between the standard and Compact
configurations in terms of the hardware components used to implement certain functions.
See Chapter B1: CS2000 Hardware for further information.
ISN software can also be supported by a hybrid configuration that comprises not only
CS2000 hardware supporting packet-based capabilities, but also legacy DMS hardware
supporting conventional circuit-based switching. Call interworking between the packet
and circuit environments can be supported in either of two ways:
! By looparound trunks with one end terminated on the TDM side of a PVG trunk
gateway and the other end terminated on a legacy trunk peripheral.
! By means of an IW-SPM (Interworking Spectrum Peripheral Module) controlled by
XA-Core. The IW-SPM provides GigE links with the backbone packet network for
packet-based connections and DS-512 links with the legacy ENET switching matrix
for 64Kb/s circuit-based connections, and supports interworking between the
different connection types. In effect, it is a media gateway with TDM-side
connections that are internal rather than external.

Communication Server Capabilities Overview Product Overview
A3.2 Capacity
Note: All figures quoted are general, and are subject to variation depending on the
network call model and capacity requirements. Network-specific estimates should be
determined in consultation with Nortel Sales Engineering.
! Call processing
" Maximum 2.0 million BHCA (Busy Hour Call Attempts)
Note: For the CS2000-Compact, the maximum is 1 million BHCA.
" Maximum 100,000 simultaneous calls
! Overall maximum of 200,000 trunk and/or line endpoints. Within this, the limits
that apply to different endpoint types are:
" 200,000 CCS7 trunks
" 81,860 SIP-T Dynamic Packet Trunks (DPTs)
" 48,000 PRI or QSIG trunks
" 130,000 analogue subscriber lines
! Maximum number of CCS7 signalling links is 328 (USP) or 180 (FLPP)
A3.3 Telephony Interfaces Supported

This section provides a "black box" view of the capabilities of the CS2000
Communication Server by listing the external telephony interfaces that can be supported
by a CS2000 and its gateways using the ISN07 software release.
! CCS7 trunk interfaces
Note: For each ISUP and TUP variant listed, CS2000 supports both a TDM-side
implementation (for access to the backbone packet network, e.g. from the PSTN)
and a packet-side implementation (for inter-CS signalling via SIP-T). In general, the
capabilities and interworkings supported by the two implementations of a given
CCS7 interface are identical; any exceptions are noted explicitly.
" ETSI ISUP V1
A base / generic call processing agent, plus national variants for:
# Brazil
# Czech Republic
# Denmark
# Italy
# Malaysia
# Mexico
# Norway
# Portugal
# Spain
# Turkey
" ETSI ISUP V2
A base / generic call processing agent, plus national variants for:
# Belgium
# Chile
# China

Product Overview Overview Communication Server Capabilities
# Germany (DTAG Gateway ISUP and Transit ISUP as well as German

ETSI ISUP V2)
# Hong Kong
# India
# Israel (civil and defence variants)
# Italy
# Russia
# Singapore
# Spain
# Sweden
# Turkey
Note: The CS2000 implementation of ETSI ISUP V2 is sometimes referred
to as V2+ because it supports some ETSI ISUP V3 capabilities.
ETSI ISUP V2 is also used as the base for ISUP variants used in:
# Australia:
$ ACIF G.500 Interconnect ISUP (I-ISUP)
$ Telstra CA30 ISUP, for use within the Telstra network
# Japan:
$ JI-ISUP (Japanese Interconnect ISUP), the interconnect standard
" ETSI ISUP V3
No base / generic call processing agent, but national variants for:
# UK (UK ISUP)
# France (SPIROU)
" IBN7 (ANSI ISUP+)
" North American Feature Group D ISUP (FGD ISUP)
" TUP interfaces:
# IUP (BTUP) for the UK
# SSUTR2 (FTUP) for France
# CTUP for China
Note: CCS7 trunk interfaces are also used to support RAS dial-up access for data
sessions. In ISN07, RAS is supported via IUP/BTUP and UK ISUP trunks.
! Intelligent Network Application Part (INAP)
! ETSI PRI base / generic agent, plus national PRI variants for
" Spain
" China
" USA (ANSI PRI)
" Hong Kong (CR13)
" Japan (INS1500)
! QSIG VPN interface
! DPNSS VPN interface for the UK

Communication Server Capabilities Overview Product Overview
! Basic analogue subscriber lines implemented/supported in the following ways:

" Lines served by high-capacity telco-located line media gateways
" Lines served by small CPE media gateways attached to customer LANs
" Lines served by small CPE media gateways attached to cable access networks
" V5.2 PSTN lines served by PVGs
! Lines served by gateways, PBXs and other units connected to CS2000 via H.323
! CentrexIP lines serving IP-enabled Ethersets and PC-based soft clients
See Part ETelephony Interfaces for descriptions of these interfaces. See the interworking
matrix on page 26 for a summary of the supported interworkings between interfaces.
CS2000 also supports ADSL (Asymmetrical Digital Subscriber Line) lines for
high-speed, always-on access to enterprise networks or the public Internet.

Product Overview Overview Communication Server Capabilities
A3.4 Interworkings between Telephony Interfaces

This section provides an interworking matrix that summarises all of the possible basic call
interworkings between the telephony interfaces supported by CS2000.
Each interworking between two interfaces is represented by a cell in the table. The table
cell representing an interworking contains one of the following, to indicate the level of
support for the interworking:
Y The interworking is supported.
N The interworking is not supported.
Note: Interworkings are deemed not to be supported if they have not been explicitly
documented or tested. This applies even to interworkings that are expected to work
(i.e. design work is not believed to be necessary), and for which support will
eventually be provided by an FMA, or by a test-only activity in a future release.
X The interworking is not applicable, e.g. interworking between two national-variant
interfaces that would not be deployed on the same CS2000.
See section E1.7 on page 364 for information about how interworking between telephony
interfaces is affected by the separation between signalling and bearer channels in a packet
network environment.

17 August 2004
Issue ISN07_v3 (approved)
Communication Server Capabilities

CS2000 support for basic call SIP CCS7 Access / VPN
interworkings in ISN07 IN IBN lines
ISUP TUP H.323 Q.931 / IUA
(with CCS7)
Y = Supported N = Not supported [1]
(no CCS7)
CentrexIP
FGD ISUP
EISUP V1
EISUP V2
ANSI PRI
ETSI PRI
LAN MG
UK ISUP
SPIROU
MG9000
INS1500
HK PRI
X = Not relevant (e.g. not for the same market)
DPNSS
CTUP
BTUP
FTUP
H.323
QSIG
INAP
MTA
IBN7
V5.2
I/F type Interface
SIP (no CCS7) Y Y Y Y N Y N Y N Y N N N N Y N N N Y Y Y Y Y

SIP
SIP-T (encapsulating CCS7) Interworkings supported for CCS7 conveyed in SIP-T are in general as for the CCS7 protocol conveyed [2]
Base / generic ETSI ISUP V1 Y Y Y Y Y Y Y Y Y N Y Y N Y Y Y Y Y N N Y Y Y
and national V1 variants [3]
Base / generic ETSI ISUP V2 Y Y Y Y Y Y N Y Y Y Y Y N Y Y Y Y Y N N Y Y Y
and national V2 variants2 [4]
ISUP
Interworkings for CCS7 in SIP-T are as for the CCS7 protocol conveyed [2]
UK ISUP (V3) [5] Y Y Y Y X Y X Y X X N Y N Y Y X X X N N N N N
CCS7
SPIROU (French V3) [5] N Y Y X Y Y X X N X N N X Y Y X X X N N N N N

IBN7 (ANSI ISUP+) Y Y Y Y Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y N N N
US FGD ISUP N Y N X X N Y X X X N N X N X N X X N N N N N
Nortel Networks
PROPRIETARY
IUP / BTUP Y Y Y Y X Y X Y X X Y N N N Y X X X Y N N N N
TUP
Overview
SSUTR2 (FTUP) N Y Y X N Y X X Y X Y N X N Y X X X N N N N N
Part A
China TUP (CTUP) Y N Y X X Y X X X Y N N X N N X X X N N N Y N
IN INAP N Y Y N N Y N Y Y N X N N Y Y N N N N N Y Y Y
H.323 / QSIG [6] Y Y Y Y N Y N N N N N Y N Y Y N N N Y N Y Y N
H.323
DPNSS / H.323 / QSIG [7] N N N N N Y X N X X N N Y N N X X X N N Y N N
QSIG N Y Y Y Y Y N N N N Y Y N Y Y N N N N N Y N N
Access / VPN
Q.931 / IUA
Base / generic ETSI PRI and Y Y Y Y Y Y X Y Y N Y Y N Y Y N Y N N N Y Y Y

national 30B+D variants [8]
ANSI PRI N Y Y X X Y N X X X N N X N N Y X X N N N N N
Hong Kong PRI (CR13) N Y Y X X Y X X X X N N X N Y X Y X N N N Y N
Japan PRI (INS1500) N Y Y X X Y X X X X N N X N N X X Y N N N N N
Uni- CentrexIP remote clients Y N N N N Y N Y N N N Y N N N N N N Y Y N Y N
Stim
Telco-located gateways
Product Overview
Basic analogue
MG9000 Y N N N N Y N N N N N N N N N N N N Y Y Y Y N
lines (IBN)
Lines
V5.2 PSTN off PVG Y Y Y N N N N N N N Y Y Y Y Y N N N N Y Y Y Y
Chapter A3
CPE gateways
Customer LAN MGs [9] Y Y Y N N N N N N Y Y Y N N Y N Y N N Y Y Y N
Page
Cable MTAs [10]

26
Y Y Y N N N N N N N Y N N N Y N N N N N Y N Y
27
Page
Product Overview
Chapter A3
[1] Interworkings are deemed not to be supported if they have not been explicitly documented or tested. This applies even to interworkings that are expected
to work (i.e. design work is not believed to be necessary), and for which support will eventually be provided by an FMA, or by a test-only activity in a future
release.
[2] For details, refer to Table 34: Interworking support for ISUP variants on page 401.
[3] In addition to base/generic ETSI ISUP V1, CS2000 supports national variants of ETSI ISUP V1 for deployment in Brazil, the Czech Republic, Denmark,
Italy (standard national interconnect interface), Malaysia, Mexico (including Telmex subvariant), Norway, Portugal, Spain and Turkey.
In general, the supported interworkings for such a national variant are as for base/generic ETSI ISUP V1, plus interworkings with appropriate national
interfaces such as the corresponding national variant of ETSI PRI, but minus interworkings with interfaces and interface variants that are specific to other
markets.
For details, refer to Table 34: Interworking support for ISUP variants on page 401.
[4] In addition to base/generic ETSI ISUP V2, CS2000 supports national variants of ETSI ISUP V2 for deployment in Australia (ACIF G.500 I-ISUP and Telstra
CA30 ISUP), Belgium, Chile, China, the Czech Republic, Germany (DTAG T-ISUP and G-ISUP variants as well as German ETSI ISUP V2), Hong Kong,
India, Israel (variants for civil and military use), Italy (intra-network support of regulatory services), Japan (JI-ISUP), Russia, Singapore, Spain, Sweden (V1
implemented as V2 variant) and Turkey.
In general, the supported interworkings for such a national variant are as for base/generic ETSI ISUP V2, plus interworkings with appropriate national
interfaces such as the corresponding national variant of ETSI PRI, but minus interworkings with interfaces and interface variants that are specific to other
markets.
For details, refer to Table 34: Interworking support for ISUP variants on page 401.
[5] ISN07 supports two national variants of ETSI ISUP V3, but does not support a base/generic V3 call processing agent.
[6] The international implementation of H.323 is based on mapping H.225 connection control messages (SETUP etc) on to their QSIG equivalents, with
APDUs being conveyed transparently in Facility IEs in QSIG messages. Support for H.323 basic call interworking means support for H.225 call
Nortel Networks
establishment, and does not imply support for the handling of non-call-related information over the interworking. Basic call interworkings supported are
PROPRIETARY
therefore as for QSIG.
Overview
[7] CS2000 support for DPNSS is based on the international implementation of H.323 (see footnote [6]). Between the GWC and the Westell DPNSS gateway,
Part A
DPNSS signalling is encapsulated in Westell-defined manufacturer-specific operations in the H450.1 SupplementaryService data field of a H323 message.
For communication between the GWC and the Core, the GWC performs mapping between these operations and QSIG Facility IEs.
[8] In addition to base/generic ETSI PRI, CS2000 supports national variants of 30B+D PRI for deployment in China and Spain.
In general, the supported interworkings for such a national variant are as for base/generic ETSI PRI, plus interworking with the corresponding national
variant of ETSI ISUP, but minus interworkings with interfaces and interface variants that are specific to other markets.
[9] CS2000 supports three types of customer LAN media gateway: Ambit, Askey and Mediatrix. All three use the MGCP device-media control protocol. A
given interworking is shown as supported if it has been verified for any of these three gateway types.
[10]CS2000 supports two types of MTAs for cable access networks: Motorola and Arris. Both use the NCS device-media control protocol. A given interworking

is shown as supported if it has been verified for either of these gateway types.

17 August 2004
Part B
Hardware
Chapter B1 Part B CS2000 International Product Description
CS2000 Hardware Hardware Communication Server Capabilities
Chapter B1 CS2000 Hardware
This chapter describes the hardware of the CS2000 itself, and is organised into the
following sections:
! Section B1.1: Overview on page 30
! Section B1.2: Processor Complex (Core) on page 34
! Section B1.3: Internal Communication (CS LAN and MS) on page 42
! Section B1.4: Gateway Controllers (GWCs) on page 53
! Section B1.5: Session Server on page 71
! Section B1.6: CCS7 Signalling Terminations on page 72
! Section B1.7: OAM&P Hardware on page 81
! Section B1.8: CS2000 Interworking with Legacy Peripherals on page 89
! Section B1.9: Hardware Packaging on page 93
ISN software can also be installed on the DMS-100 hardware platform to provide
circuit-based switching and service support capabilities, in which case it is referred to as
ISN (TDM). ISN software can even be installed in a hybrid configuration that comprises
CS2000-specific and DMS-specific hardware as well as hardware that is common to both.
Such a hybrid configuration can support circuit-based and packet-based capabilities
simultaneously, as described in section B1.8 on page 89.
This Product Description provides detailed descriptions only of CS2000 components and
of DMS hardware components that are common to DMS and CS2000 and may be
included in a non-hybrid CS2000 configuration. For a systematic description of all DMS
hardware, including components for which hybrid configuration interworking is
supported, refer to the separate ISN07 (TDM) Product Description.

CS2000 International Product Description Part B Chapter B1
Communication Server Capabilities Hardware CS2000 Hardware
B1.1 Overview
To meet the needs of different types of customer, a range of different CS2000 hardware
configurations are supported in ISN07. These can be categorised in two main ways:
! In terms of the type of processor complex used:
" Standard CS2000 configuration
Note: A standard configuration is a CS2000 that uses the XA-Core processor
complex. The term can denote either a full SuperNode configuration or a
streamlined SNSE (SuperNode Size Enhanced) configuration.
" CS2000-Compact configuration with minimised system footprint
! In terms of the extent to which they incorporate DMS hardware as well as CS2000
hardware, the possibilities being:
" Configurations consisting entirely of CS2000 hardware
" Configurations that use DMS hardware for selected functions
" Hybrid configurations that support interworking between CS2000 and DMS
trunk and line peripherals
These configuration options are illustrated in Figures 3 to 5.
A CS2000 is a distributed system comprising a number of different functional elements.
The main functional elements are common to all types of CS2000 configuration, but there
are some differences between configurations in terms of the hardware components used
to implement certain functions. These differences are summarised on page 32 and
discussed in more detail in the sections dealing with particular components.
Physically, a CS2000 configuration consists of circuit packs housed in slots in shelves,
which are in turn packaged into cabinets to form a cabinet lineup. See section B1.9 on
page 93 for information about CS2000 hardware packaging and illustrations of some
typical cabinet lineups.
USP supports CCS7 CS2000 Core (XA-Core or GWCs individually configured to support:
signalling to/from Compact) supports: Device/media control for MGs
TDM networks via Call processing Backhauled call control for MGs
dedicated signalling Translations / routing H.323 access
links (not via packet Service logic DPTs between CS2000s
network) Core and GWCs together Media server control
support MGC functionality. CICM control
Media server switched Media proxy control
into calls to support: RMGC functionality
Announcements CICM provides Session Server
Conferencing services for remote supports SIP signalling
BCT for LI CentrexIP clients to/from peer MGCs
CS2000 CS LAN OAM&P

CS2000 servers
Core Session
USP MS2000 CICM Server
Trunk CICM AC H.323 Line RMGC DPT
GWC GWC GWC GWC GWC GWC GWC
UAS can be used GWC configured as

instead of MS2000 VRDN can be used
Dual PP8600s instead of Session Server
Figure 3: CS2000 configuration with no legacy hardware

Input / Output Office ENET

Module supports Alarms switching
datalinks Unit matrix
IOM OAU ENET
in ISM
Message Switch (bus) supports

MS MS internal communication
Fiberised Link
Peripheral SuperNode Data Manager supports
FLPP Processor SDM OAM&P for CS2000 Core and FLPP
supports
CCS7 links
CS2000 CS LAN OAM&P

servers
CS2000 Core
Session
MS2000 CICM Server
Dual PP8600s
Figure 4: CS2000 configuration using DMS hardware for selected functions
Trunks Two mechanisms for

Legacy (including interworking betweeen circuit
trunk looparounds) and packet environments:
peripherals Looparound trunks
IOM OAU ENET
in ISM connecting legacy
peripherals with TDM side
Legacy of PVG trunk gateway
line Lines Interworking SPM
MS MS
peripherals (IW-SPM) connected both
to legacy peripherals (via
ENET) and to media
FLPP SDM gateways (via CS LAN and
IW-SPM
packet backbone network)
CS2000 OAM&P
CS LAN servers
CS2000 Core
Session
MS2000 CICM Server
Dual PP8600s
Figure 5: Hybrid configuration with interworking between CS2000 and DMS peripherals

The CS2000 components illustrated in Figures 3 to 5 and described elsewhere in this

chapter are listed below.
! The processor complex, the central computing engine of the CS2000.
" Standard CS2000 configurations use XA-Core, as described in section B1.2.1
on page 34.
" CS2000-Compact configurations use the 3PC (Third-Party Core), as
described in section B1.2.2 on page 38.
! Intra-CS2000 communication is based on one or both of the following:
" Most intra-CS2000 communication (all internal communication in the case of
configurations with no DMS hardware) utilises the CS LAN, a subnetwork
connected to the external managed packet network via dual Passport PP8600
routers, as described in section B1.3.1 on page 42.
" In a CS2000 configuration that includes DMS hardware, communication
between the Core and the FLPP and SDM uses the internal bus provided by
the Message Switch (MS). Communication with the OAU uses the ENET
switching matrix as well as the MS. The MS and ENET are both described in
section B1.3.2 on page 51.
" In a hybrid configuration that supports interworking with DMS trunk and line
peripherals, these peripherals use both the MS and ENET.
! Gateway Controllers (GWCs) supporting access to the packet network backbone are
housed in SAM21 card cages (21-slot Service Application Modules). GWCs can be
configured to support a number of different functions, of which the most important
are:
" To control the operation of media gateways and other units supporting trunk
and line access to the packet network.
" To control the operation of the CentrexIP Client Manager (CICM), which acts
as an intermediary between line GWCs and remote CentrexIP clients,
terminating UniStim signalling and supporting client services such as
registration and call logging.
" To communicate with remote CS2000s across the packet network. Dynamic
Packet Trunks for inter-CS signalling based on CCS7 encapsulated in SIP are
supported by DPT GWCs with no subtending units. DPTs are so called
because trunk characteristics such as the ISUP protocol variant to be used are
determined on the basis of the telephony profile of the selected route, which
is downloaded to the DPT GWC during call establishment.
" To control the operation of media servers and media proxies.
" To support Redirecting Media gateway Controller (RMGC) functionality,
which enables line gateways to discover the address of their controlling
GWC.
GWCs are described in section B1.4 on page 53.
Note: As the CentrexIP Client Manager (CICM) is housed alongside GWCs in a
SAM21 shelf, it is also described in section B1.4, in section B1.4.2 on page 55.

! The Session Server has been introduced in ISN07 as the new standard platform for
communication across the managed IP core network between peer MGCs. CCS7 is
supported using DPTs (Dynamic Packet Trunks) terminated on DPT GWCs. CCS7
signalling is conveyed encapsulated in SIP (Session Initiation Protocol) messages.
SIP signalling is terminated on the Session Server, which extracts the CCS7
signalling and passes it on to the DPT GWC.
interoperability between call servers and other network elements. Prior to the ISN07
introduction of the Session Server implementation, CS2000 support for SIP was
based on pre-RFC3261 drafts and implemented by configuring GWCs as VRDNs
(Virtual Router Distibution Nodes) to provide initial points of contact for
peer-to-peer SIP signalling. This VRDN implementation is still supported, but has
now been superseded by the Session Server implementation.
! Terminations for CCS7 signalling links.
" Since ISN04, the recommended unit for terminating CCS7 signalling links
has been the Universal Signalling Point (USP) described in section B1.6.1 on
page 73. This is available for use with both standard and Compact
configurations.
Note: A Compact version of the USP is available for use in CS2000-Compact
configurations that have limited requirements for CCS7 signalling links.
" As an alternative to the USP, a standard CS2000 configuration can include a
Fiberised Link Peripheral Processor (FLPP), as described in section B1.6.2 on
page 78.
! For configurations with no legacy hardware, Sun Netra 240 servers can be used as
the standard platform for OAM&P applications. CS2000 Core Manager capabilities
are provided by Core and Billing Manager (CBM) applications running on a
dedicated CBM server, while Element Managers (EMs) for most other components
run on a dedicated CS2000 Management Tools (CMT) server. For configurations
that include legacy hardware, Core Manager capabilities are instead provided by
SuperNode Data Manager (SDM) applications running on a PowerPC / AIX
platform. Use of the CBM and standardisation on Sun servers is recommended with
effect from ISN07, but deployed SDMs continue to be supported. CBM and SDM
application capabilities are equivalent. See section B1.7 on page 81 for more details
of OAM&P hardware.
Note: The configurations illustrated in Figures 3 to 5 all include an MS2000 Series media
server supporting announcements, conferencing and BCT for LI. The MS2000 is typically
located on the CS2000 CS LAN, but in terms of CS2000 network architecture it is an
independent media server that does not logically belong to the CS2000 configuration. It
is therefore described separately, in Chapter B3: CS2000 Support for Media Servers.
Chapter B3 also describes the UAS (Universal Audio Server), which provided media
server functionality before the ISN07 introduction of the MS2000 Series, and is still
supported.
Many CS2000 components are duplicated for reliability. Others operate in load-sharing
mode using N+1 sparing. In both cases the aim is that a functional element can survive
the failure of one of its constituent hardware units. Because the primary aim of this chapter
is to provide a functional view of hardware operation, the illustrations do not show
hardware component duplication or sparing.

B1.2 Processor Complex (Core)

The processor complex or Core is the central computing engine of a CS2000
Communication Server. This is where the PCL (Product Computing-Module Load) for
the current software release is installed. Although specialised processing is delegated
where possible to other components, it is the centrally loaded PCL that supports call
processing agents for telephony interfaces, translations and routing, and service logic for
the delivery of value-added features and services. It also includes software for controlling
packet network bearer connections established via GWCs and media gateways.
CS2000 configurations may be based on either of two Cores:
! The Extended Architecture Core (XA-Core), as described in section B1.2.1,
provides processing power for standard CS2000 configurations.
! The Call Agent or Third-Party Core (3PC), as described in section B1.2.2 on page
38, provides processing power for CS2000-Compact configurations.
Both types of Core support essentially the same capabilities. The main difference between
them is in capacity, e.g. a maximum of 1 million BHCA for the 3PC compared with 2
million BHCA for XA-Core.
B1.2.1 XA-Core
B1.2.1.1 Overview
Subsystems
XA-Core design is based on the principle of using independently scalable subsystems to
deliver call processing capacity. Such subsystems can be incrementally tailored to meet
customer requirements, instead of replacements and upgrades being required. The
XA-Core subsystems are:
! Processor subsystem
! Shared memory
! Input/output processors
Links between subsystems (bus capabilities) are provided by a set of independent
communication links known as the XAI (Extended Architecture Interconnect).
Physical Implementation
Physically, each type of subsystem is implemented as a circuit pack. XA-Core as a whole
consists of a single shelf that provides slots for inserting these circuit packs and is housed
in a SuperNode C42 cabinet
The XA-Core shelf can be packaged in a cabinet along with the MS, with the FLPP and
ENET (if used) in separate cabinets. Alternatively, it can be packaged in a SNSE
Combined Core Cabinet along with streamlined versions of the MS, LPP and ENET. The
shelf is identical in both cabinets.
See section B1.9.2 on page 94 for illustrations of how the XA-Core shelf can be packaged
in some typical cabinet lineups.

Logical Architecture
Figure 6 shows XA-Core architecture. Subsystems are described in sections B1.2.1.2 to
B1.2.1.4.
CS2000
Shared memory
XA-Core (SM)
Tape
XAI comms links
Disk
Processor I/O Processors

Elements (PEs) (IOPs)
Terminal
MS used only if configuration 100BaseT
includes DMS hardware OC-3 links
(see Figures 4 and 5) Ethernet links
Message Switch (CS2000 bus) CS LAN
Links to FLPP, SDM, IOM, ENET Links to USP and GWCs
Figure 6: XA-Core architecture
B1.2.1.2 Processor Subsystem

Each XA-Core Processor Element (PE) is a single-card unit comprising twin PowerPC
processors. The recommended PE is the enhanced LX02DA Atlas PE, which is the
successor to the LX02CA Rhino PE. Atlas PEs have twin PowerPC 7410 processors
instead of the twin 604s used by Rhino PEs, and Atlas capacity is 1.65 times that of Rhino.
The design aim of XA-Core is to allow the processing capacity of a switch to be increased
simply by adding PEs, and to use processor capacity as efficiently as possible by means
of N+M sparing. N+M sparing means engineering N PEs to meet the capacity demands
of the application, with M additional PEs provided for exception conditions, where M=1
is the minimum requirement for system reliability and availability.
N+M sparing relies on dynamic load distribution to allocate work evenly between PEs,
and on unblocking mechanisms to guarantee data integrity while ensuring that processing
is not held up when two tasks require access to the same resource.
ISN07 supports N+1 XA-Core sparing, i.e. N+1 active load-sharing PEs handling a
workload engineered for N, thus leaving any one theoretically spare and giving the system
the ability to handle the full workload even in the event of a PE failure. 2+1 sparing is
standard for XA-Core configurations based on the Atlas PE, but 3+1 Atlas sparing is also
supported for additional capacity. 3+1 sparing is standard for Rhino configurations. PE
configurations must be all Atlas or all Rhino; mixed configurations are not supported.

B1.2.1.3 Shared Memory

Each Shared Memory (SM) element is a card housing two or three 128-Mbyte memory
modules. Memory is provided by mated pairs of 32-Mbyte memory blocks located on
different memory cards, each storing duplicated data, so that one copy of the data will be
retained in the event of a memory failure. Pairs of memory blocks are independently
mated, such that problems with a given mated pair have no impact on any other mated
pair.
Minimum provisioning recommendations are as follows:
! XA-Core end offices should be provisioned with a total of six SM cards supporting
a total of 960 Mbytes of memory using a 5+1 sparing configuration.
! XA-Core tandem offices should be provisioned with a total of seven SM cards
supporting a total of 1152 Mbytes of memory using a 6+1 sparing configuration.
In ISN07, the overall maximum memory that can be provided by the SM subsystem for
XA-Core is 1728 Mbytes (1152 Mbytes for SNSE).

B1.2.1.4 Input/Output Subsystem

Input / Output Processors provide system load capabilities and support communications
links with other CS2000 components. Each IOP motherboard houses one or two dedicated
application-specific packlets designed to support capabilities such as:
! Ethernet ports for IP communication via the CS LAN with other IP hosts attached
to the LAN. These include:
" GWCs housed in SAM21 card cages.
" The USP signalling gateway, if this is used instead of the FLPP.
" The Session Server.
" The CBM, if this is used instead of the SDM to support the Core Manager.
The standard type of IOP for ISN07 is the HIOP (High-capacity IOP), an LX04 card
supporting 100BaseT Ethernet. The HIOP has superseded the LX03BA EIOP
(Ethernet IOP) used with SNH01, but already-deployed EIOPs are still supported.
XA-Core is equipped with two HIOP cards, which are connected to the PP8600
routers via 100BaseT full duplex links (XA-Core therefore uses one port on each
PP8600). During normal operation, both HIOPs are active and operate in
load-balancing mode.
A total of six consecutive IP addresses are assigned for XA-Core use, as follows:
" Two floating addresses for the active interfaces
" One address for the maintenance interface on each HIOP (two in all)
" One address for the physical interface on each HIOP (two in all)
! An optional interface to the CS2000 MS (bus) for communication with DMS
hardware if this is included in the configuration. The Core can communicate with
the following units via the MS:
" The SDM, if this is used instead of the CBM to support the Core Manager.
" The FLPP signalling peripheral, if this is used instead of the USP.
" IOM datalinks.
" The ENET switching matrix, which can in turn support connections with the
OAU and (in a hybrid configuration) with legacy trunk and line peripherals
and the IW-SPM.
Each IOP used for MS connections supports ports for terminating ATM over
SONET OC-3 links operating at 155 Mb/s.
! Disk storage with capacity of 4 Gbytes
! Tape storage (DAT) with capacity of 1.3, 2 or 4 Gbytes

B1.2.2 Processor Complex for CS2000-Compact
B1.2.2.1 Call Agent Components
3PC (Third Party Core)

The processor complex for the CS2000-Compact is referred to as the Call Agent. It is a
non-proprietary 3PC (Third Party Core), which consists of a pair of Motorola N765
processor cards, also known as 3PC blade cards. Each card has:
! 1 Gbyte RAM
! Two 10/100BaseT Ethernet ports for CS LAN connections
! A fibre channel interface to the other processor card
The CS2000-Compact Call Agent uses the Linux operating system and PEEL (Protel
Environment Emulation Layer) software to support the ISN07 software load.
The two 3PC blade cards that provide processing power for a CS2000-Compact
configuration are housed in a Call Agent shelf in a Call Control Frame (CCF), as
described and illustrated in section B1.2.2.2 on page 39.
Persistent Data Storage and Storage Manager (STORM)

For the 3PC Call Agent, data storage (e.g. for the Core load) and storage management can
be provided using either of two implementations. Both implementations make use of a
dedicated persistent data storage shelf in the Call Control Frame, but they differ in terms
of how and where Storage Management (STORM) capabilities are provided, as follows:
! Available since ISN06 and recommended for new deployment
Data storage and STORM are both provided by a pair of HP SAM-XTS (eXtreme
Thin Servers) housed in the persistent data storage shelf. The 3PC Call Agent cards
communicate with these SAM-XTS servers via the CS LAN PP8600s.
! Used prior to ISN06, and still supported
Data storage for the 3PC Call Agent is provided by a DotHill RAID system housed
in the persistent data storage shelf. This system binds a number of disks together to
form an integrated storage volume, using the space of one of the bound disks to
provide data storage redundancy.
STORM access to the RAID system is provided by two Motorola N750 Network
File System (NFS) cards, one in each Call Agent shelf. The 3PC Call Agent cards
communicate with these NFS cards via the SAM21 shelf bus, and the NFS cards
communicate with the RAID system by means of a 160Mb/s fibre channel interface
to the persistent data storage shelf.

B1.2.2.2 Hardware Packaging
Call Control Frame (CCF)

The Call Agent is housed in a SAM21 shelf in a PTE2000 frame, which is referred to as
a Call Control Frame (CCF). The SAM21 is so called because it is a Service Application
Module shelf with 21 slots. A PTE2000 frame is a 61cm wide x 213cm high x 61cm deep
(24 x 84 x 24) walled frame with a door. Figure 7 illustrates the CCF and its contents.
Power distribution shelf

Astec EBIP (Electrical Breaker Interface Panel)
Persistent data storage provided either by:

Twin SAM-XTS servers with integrated STORM
(as shown)
DotHill RAID system (now superseded; requires
separate STORM NFS card on Call Agent shelf)
Media server capabilities provided either by:

Up to six MS20x0s (two shown)
SAM16 shelf housing UAS (now superseded)
Media server is not a CS2000 component, but is
typically housed together with CS2000-Compact
processor complex.
One or two SAM21 Call Agent shelves housing:

Second shelf
(optional) Call Agent card
3PC processor
One pair of Shelf Controller cards per shelf (in slots
7 and 9)
Up to 7 pairs of Gateway Controller (GWC) cards per
shelf, each pair configured as one of:
- GWC for media gateway
- DPT GWC
- CICM
Main shelf - AC for UAS
(mandatory)
Optional USP-Compact (Universal Signalling Point)
terminating CCS7 signalling links
Optional separate STORM (now superseded)
NFS card with optical links to RAID system
PTE2000 Packet Telephony Equipment frame

61cm wide x 213cm high x 61cm deep (24 x 84 x 24)
Figure 7: CS2000-Compact Call Control Frame (CCF)

Call Agent Shelf Contents

A Call Agent shelf is a SAM21 Service Application Module with 21 slots. In addition to
housing a 3PC blade card and a STORM NFS card (now optional), each SAM21 Call
Agent shelf houses a Shelf Controller (SC) that provide control and co-ordination for the
shelf as a whole. The SC consists of two separate SC cards, each with the following
characteristics:
! Motorola N750 single-board computer with 366 MHz processor, 128 Mbytes RAM
and 96 Mbytes flash memory
! Ethernet 10/100BaseT port for CS LAN connections
Most Call Agent shelf slots not used for processor complex hardware are used to house
Gateway Controllers (GWCs). See section B1.4 on page 53 for information about GWCs
and their functions. A GWC consists of two separate GWC cards, each with the following
characteristics:
! Motorola N750 single-board computer with 366 MHz processor and 128 Mbytes
RAM
! Ethernet 10/100BaseT port for CS LAN connections
A Compact version of the USP is available for use in CS2000-Compact configurations as
an alternative to the full-scale USP. A USP-Compact consists of a pair of USP-Compact
cards, one housed in each SAM21 Call Agent shelf in a CS2000-Compact Call Control
Frame. Each USP-Compact card provides an E1 carrier port for external CCS7 signalling
links and a 100BaseT Ethernet port for communication across the CS LAN. The
maximum capacity of a two-card USP-Compact is 16 CCS7 signalling links. See section
B1.6.1.4 on page 77 for more information about the USP.
Other Components in the Call Control Frame

! Media server
In addition to two SAM21 Call Agent shelves, the CS2000-Compact Call Control
Frame can also be used to house one or more media server units. Although logically
and functionally a media is a centralised resource, it is typically co-located with the
CS2000-Compact and communicates with it via the CS LAN to support the
following:
" Packetised announcements
" Conference circuits
" Bearer Channel Tandem functionality for the Lawful Interception service
Media server capabilities can be implemented in either of two ways:
" By means of up to six self-contained Media Server 2000 Series units
(MS2010 units for VoIP, MS2020 units for VoATM)
" By means of a set of UAS (Universal Audio Server) cards in a SAM16 shelf
Media server control connections are based on IP over the CS LAN for both VoIP
and VoATM. For VoIP, media server bearer connections also use the CS LAN, and
reach the IP backbone network via the CS LANs PP8600 routers. For VoATM,
however, the media server supports direct bearer connections with the ATM
backbone network.
For more details, see Chapter B3: CS2000 Support for Media Servers.

! Power Distribution Shelf

The power distribution shelf occupies the top position in each CCF. This is an Astec
Electrical Breaker Interface Panel (EBIP) that not only provides the power supply
for the other shelves in the frame, but also provides frame alarm lamps.
! Persistent Data Storage Shelf
Data storage for the 3PC Call Agent is provided either by SAM-XTSs or by a RAID
system. It is housed in a dedicated persistent data storage shelf located immediately
below the power distribution shelf in the Call Control Frame.
Other Frames in a CS2000-Compact Cabinet Lineup

A CS2000-Compact configuration typically includes a number of additional frames to
complement the Call Control Frame, as follows:
! A cabinet housing the dual PP8600 routing switches that provide the connectivity
for the CS LAN (see section B1.3.1.6 on page 47 for details).
! A frame housing a USP (Universal Signalling Point) to provide CCS7 signalling
terminations, as described in section B1.6.1.3 on page 76.
Note: A separate USP cabinet is not required in a CS2000-Compact configuration
that uses the USP-Compact. A USP-Compact consists of a pair of USP-Compact
cards, one housed in each Call Agent shelf in a CS2000-Compact CCF. The
USP-Compact reduces system footprint, but has significantly less signalling link
capacity (16 CCS7 links as opposed to 328 for the full-scale USP) and is subject to
some other restrictions, as described in section B1.6.1.4 on page 77.
! A PTE2000 frame housing the Sun Netra 240 servers used to support OAM&P
functionality, as follows:
" A CBM (Core and Billing Manager) server supporting the applications that
provide management capabilities for the Core.
Note: If the SDM (SuperNode Data Manager) platform is used instead of the
CBM for the CS2000 Core Manager, this requires a separate C28 cabinet.
" A CMT (CS2000 Management Tools) server supporting EMs for other
CS2000-Compact components such as GWCs.
See section B1.7 on page 81 for further information about OAM&P hardware.
To increase capacity, a CS2000-Compact cabinet lineup can include a PTE2000
Expansion Frame as well as the Call Control Frame. Such an expansion frame can house
any appropriate combination of the following units:
! SAM21 shelves with additional GWCs (up to three per frame)
! Additional MS20x0 media server units (up to six per frame)
! Twin Session Server units supporting peer-to-peer SIP / SIP-T signalling
See section B1.9 on page 93 for further information about CS2000-Compact cabinet
lineups.

B1.3 Internal Communication (CS LAN and MS)

Internal communication between the components of a CS2000 Communication Server is
based on one or both of the following:
! The CS LAN (Communication Server Local Area Network)
Used to support Ethernet communication between CS2000 components.
! The Message Switch (bus)
Used to provide a system bus for peer-to-peer messaging between XA-Core and the
DMS legacy hardware components that may be included in a CS2000 configuration,
e.g. the SDM and the FLPP (if used instead of the CBM and USP).
Note: The MS is not required or used in CS2000 configurations with no DMS hardware.
B1.3.1 Communication Server Local Area Network (CS LAN)
B1.3.1.1 CS2000 Components Linked by the CS LAN

The CS2000 CS LAN supports Ethernet comunication between the following CS2000
hardware components:
! CS2000 Core (XA-Core or Compact 3PC)
Note: If the configuration includes DMS hardware units, these communicate with
the Core via the MS rather than the CS LAN.
! GWCs
! CICM (if used)
! Session Server (if used)
! USP
Note: If the FLPP is used instead of the USP, it is not connected to the CS LAN.
! A Sun Netra 240 CBM (Core and Billing Manager) server supporting the
applications that provide management capabilities for the Core.
Note: In an XA-Core configuration in which the SDM (SuperNode Data Manager)
platform is used instead of the CBM for the CS2000 Core Manager, the SDM
communicates with the Core via the MS rather than the CS LAN.
! A Sun Netra 240 CMT (CS2000 Management Tools) server supporting EMs for
other CS2000-Compact components such as GWCs.

B1.3.1.2 Non-CS2000 Components that may be Connected to the CS LAN

The CS LAN can also support communication between CS2000 components and some
co-located non-CS2000 components, as follows:
! MS2000 Series media server or UAS (Universal Audio Server)
Logically, MS2000s and UASs are independent media servers, but they are
typically located on the CS LAN.
! Large telco-located media gateways
PVGs may be connected to the CS LAN.
! Media proxies
RTP Media Portals providing media proxy functionality may be connected to the
CS LAN.
! MCS5200
The MCS5200 can be deployed as a stand-alone solution in its own right, but when
it is deployed as part of a complete VoIP solution involving both MCS5200 and
CS2000 the MCS5200 LAN is typically co-located with the CS2000 CS LAN.
Care must be taken to ensure that the volume of traffic generated by non-CS2000
components connected to the CS LAN does not encroach on the PP8600 capacity required
for CS2000 components.
B1.3.1.3 CS LAN Characteristics and Structure

The CS2000 CS LAN is an Ethernet 100BaseT network based on the Passport PP8600
router / Ethernet switch. Physically, the CS LAN consists of direct Ethernet cable
connections between ports on the PP8600 and ports on CS2000 hardware components.
To provide redundancy, each CS LAN has two PP8600s, configured to use VRRP (Virtual
Router Redundancy Protocol) and operating in load-sharing mode. A given CS2000
component is connected to both PP8600s, using one as its default router and the other as
a backup. (In the case of a twin-card unit such as a GWC, each card is connected to one
PP8600 and its mate is connected to the other.) The dual PP8600 routers provide all the
routing and Ethernet switching functionality for communication across the CS LAN.
The CS LAN PP8600s are an integral part of a CS2000 configuration. They support
essential communications between the other CS2000 components, and their ability to do
so has been exhaustively tested and verified by Nortel.
For intra-CS2000 communication, the CS LAN is organised into a number of VLANs
(Virtual LANs), as explained in the following list and illustrated in Figure 8 on page 44:
! Signalling VLAN (also referred to as the call processing or CallP VLAN)
This interconnects the functional CS2000 Network Elements (NEs) involved in call
processing and service provision for end users.
! External signalling VLAN
This interconnects the NEs involved in SIP/SIP-T signalling with peer MGCs.
These are DPT GWCs and either the Session Server or GWCs configured as
VRDNs
! Client signalling VLAN
This interconnects the NEs involved in controlling access to the packet network for
CPE units that are attached to enterprise or access networks and located behind

NATs and firewalls, e.g. customer LAN media gateways, IP-enabled PBXs and
remote CentrexIP clients. These NEs include H.323 GWCs, line GWCs, CICM and
GWCs configured to provide RMGC functonality.
! OAM&P VLAN
This interconnects the EMS (Element Management System) servers supporting the
EMs (Element Managers) for functional network elements. These EMs are the only
entities that are permitted to access the functional CS2000 NEs on the signalling
VLANs. The EMS servers belonging to the OAM&P VLANperform a dual role:
" They have trusted access to the CS2000 network elements on the signalling
VLAN, for which purpose they can use the private IP address space of the
signalling VLAN.
" They support controlled access from external entities, for which purpose they
are assigned IP addresses in the address space of the carriers intranet.
Note: These IP addresses are sometimes referred to as public addresses. This
means only that they are external to the VoIP address domain to which
functional NEs belong, not that they are public Internet addresses. In practice,
a carriers OAM&P intranet will also be a private network.
! Bearer VLAN
If the backbone packet network is IP, an MS2000/UAS bearer VLAN is configured
to handle audio bearer traffic (the CS LAN otherwise handles only signalling). This
is not necessary for an ATM backbone network, as the UAS can support direct
ATM bearer connections that bypass the CS LAN PP8600s.
The CS2000 CS LAN cannot be split between different geographic sites.
Figure 8 illustrates how the CS LAN is structured into different VLANs for different
purposes.
CS2000 CS LAN OAM&P

CS2000 servers
Core Session
USP MS2000 CICM Server
Signalling VLAN
Client signalling VLAN
External signalling VLAN
Bearer VLAN
OAM&P VLAN
Dual PP8600s Router/firewall

controlling access
to/from NOC LAN
Figure 8: Virtual LANs supported by the CS2000 CS LAN

B1.3.1.4 Configuring Additional VLANs off the CS2000 CS LAN

Figure 8 on page 44 shows the PP8600 routers of the CS LAN supporting five VLANs.
This is a typical configuration, but it is not mandatory. The only mandatory components
of the CS LAN are the PP8600 routing switches and the signalling VLANs used for call
processing and OAM&P. The MS2000/UAS bearer LAN is almost invariably configured
as an additional VLAN because this is an efficient way of using PP8600 resources, but
logically the MS2000/UAS bearer LAN is independent of the CS LAN.
Provided that capacity studies and estimates are used to verify that sufficient capacity is
available, the CS LAN PP8600s may also be used to support additional VLANs for other
network elements that are otherwise assumed to have separate core network connections,
as follows:
! Large telco-located media gateways (PVGs)
One or more large gateways can be connected to a bearer VLAN supported by the
CS LAN PP8600s. Depending on the traffic profile to be supported, this could be
either the same bearer VLAN as the MS2000/UAS (with switching between
gateways and MS2000/UAS) or an independent gateway bearer VLAN (with
routing between gateways and UAS). For signalling purposes, the gateway(s)
would be connected to the CS LANs signalling VLAN.
! Media proxies (RTP Media Portals providing media proxy functionality)
In a carrier network supporting a CS2000 solution, each media proxy has two
connections, one with the private VoIP network supporting the CS LAN and large
telco-located gateways, and one with the carriers public network. This enables it to
support two specific capabilities:
publiuc network.
gateways.
! MCS5200 providing multimedia support for CS2000 solutions
The MCS5200 LAN is typically described as being separate from the CS LAN,
reflecting the fact that the MCS5200 can be deployed as a stand-alone solution in
its own right. However, when deployed as part of a complete multimedia solution
involving both MCS5200 and CS2000, the MCS5200 LAN is typically co-located
with the CS2000 CS LAN and configured as two additional VLANs, one
private/internal and one public/external. MCS5200 units are connected directly to
the CS LAN PP8600s. See Chapter B6: Multimedia Communication Server
(MCS52000) for MCS5200 configuration information.
Care must be taken to ensure that the volume of traffic conveyed over such additional
VLANs does not encroach on the PP8600 capacity required for the CS LAN.

B1.3.1.5 CS LAN External Connectivity

The CS LAN not only supports intra-CS2000 communication, but also provides the
interface between the CS LAN and the external packet network, as shown in Figure 9.
Scenario A:- Connectivity for an IP backbone network

signalling
IP
Ethernet
GigE
signalling
signalling Intra-PP8600 links signalling IP
IP IP Ethernet
Ethernet Ethernet GigE
IP
100BaseT GigE backbone PVG
PP8600 packet
Uplinks to
CS LAN backbone network network bearer
IP
Ethernet
GigE
Scenario B:- Connectivity for an ATM backbone network

signalling
IP
Ethernet
GigE signalling
signalling IP
signalling Intra-PP8600 links IP AAL5
IP AAL5 ATM
Ethernet ATM STM-x
100BaseT STM-x ATM
backbone PVG
PP8600 packet
Uplinks to
CS LAN backbone network network bearer
AAL2
ATM
STM-x
Figure 9: Connectivity provided by the PP8600 router / switch for the CS LAN
The CS LAN PP8600s support two types of external communication:

! Backbone network connectivity
GigE uplinks to the packbone packet network. These are used for signalling
between CS2000 GWCs and their remote media gateways, and for peer-to-peer
signalling between CS2000 and remote compatible MGCs such as MCS5200. They
can also convey UAS bearer traffic if required.
! Intranet connectivity
OAM&P connections between the EMs on the OAM&P VLAN and the client
desktops and higher-level management application servers that access these EMs in
order to perform management tasks. Depending on the network architecture, these
clients may reside either on a dedicated Network Operations Centre (NOC) LAN or
in the operating companys intranet.

B1.3.1.6 PP8600 Hardware Characteristics

The PP8600 router / switch on which the CS LAN is based is a modular product that offers
Layer 2 switching along with wire-speed, IP-based Layer 3 switching functionality in a
single 10-slot 8010 chassis. All system components are hot-swappable and redundant,
with takeover in the event of failure measured in microseconds.
For a given CS LAN, PP8600 routing functionality is provided by two complementary
PP8600 routers housed in a single PTE2000 cabinet or 19" standard frame, each housed
in a separate shelf / chassis and provisioned with hardware components as summarised in
Table 1.
Table 1: PP8600 hardware
Unit Function Provisioning
Centre slots (5 and 6) reserved for 8691 cards.

8010co Provides 10 slots for housing Other slots (1-4 and 7-10) available for I/O
chassis PP8600 cards
support.
PP8600 CPU and switching

8691 CPU/SF fabric One per chassis.
Two per chassis, supporting a minimum total of 8

GigE ports for the CS LAN, allocated as follows:
Supports: 4 GigE ports are used for fully redundant
32 Ethernet 100BaseT inter-chassis communication via at least 2
8632TXE ports GigE links.
2 Gigabit Ethernet ports For VoIP, at least two 2 GigE ports are used
for uplinks to the packet backbone network (4
can be used if required)
Provides 8 slots for GBIC

8608GBE (Gigabit Interface Converter)
modules Each GigE port requires a dedicated GBIC
module or connection to provide its physical and
Equivalent to 8608GBE, optical interface characteristics. At least one
but uses fixed GBIC 8608 card is therefore required per PP8600.
8608SXE
connections instead of GBIC
modules
Provides two slots for MDA Mandatory for VoATM.

(Media-Dependent
8672ATME Adaptors) terminating ATM / Used for VoIP only if the backbone network uses
STM-x uplinks to ATM
IP over ATM.
backbone network
Provides 48 10/100BaseT Used to provide additional 100BaseT ports for CS

8648TXE
Ethernet ports (RJ-45) LAN connectivity if required

B1.3.1.7 CS LAN Connections for CS2000 Components

Within a CS2000 CS LAN, communication is based on IP over 100BaseT Ethernet. Table
2 summarises how the 100BaseT Ethernet ports provided by the dual PP8600 routers are
used to support CS LAN connections with other components.
Table 2: CS LAN connections supported by PP8600 dual routers
100BaseT
Connection
Component terminations
characteristics IP addressing [1]
provided by
CS2000 Core
XA-Core LX04 HIOP Redundancy provided by Six IP addresses:
cards in independent connections Two floating logical addresses for the
XA-Core shelf with both routers. active interfaces.
Each HIOP is connected One address for the maintenance
to one PP8600 but not to interface on each HIOP (two in all).
the other. One address for the physical interface
During normal operation, on each HIOP (two in all).
both HIOPs are active and
operate in load-balancing
mode.
3PC Call Two Ethernet Redundancy provided by Ten IP addresses in all, including two
Agent ports on N765 independent connections floating logical addresses for the active
processor with both routers. interfaces.
cards, one in Two ports per processor
each SAM21 card, each connected to
Call Agent one of the dual PP8600
shelf routers.
GWCs in SAM21 Ethernet ports Redundancy provided by Four IP addresses per GWC:
chassis on GWC cards independent connections One externally visible floating logical
(connectivity with both routers. address for the active unit.
identical for all GWC One port per GWC card, One floating logical address for the
types) therefore two for a GWC inactive unit.
pair. Each card is Two static addresses for OAM&P /
connected to one of the physical access to each card
dual PP8600 routers.
SAM21 SCs Ethernet ports Redundancy provided by Four IP addresses per SC:
on SC cards independent connections One externally visible floating logical
with both routers. address for the active unit.
One port per SC card, One floating logical address for the
therefore two for an SC inactive unit.
pair. Each card is Two static addresses for OAM&P /
connected to one of the physical access to each card.
dual PP8600 routers.
Session Server Ethernet ports Redundancy provided by Four IP addresses per Session Server:
on HP-CC3310 independent connections One externally visible floating logical
platform with both routers. address for the active unit.
Two ports per One floating logical address for the
HP-CC3310, each inactive unit.
connected to one of the Two static addresses for OAM&P /
dual PP8600 routers. physical access to each unit

100BaseT
Connection
provided by
USP (if used) Ethernet USP houses two or four IP Four to six IP addresses:
Transition system nodes, which Two or four CS-LAN IP addresses are
Module (TM) operate in active/active required for the IP system nodes,
for IP system load-sharing mode and which operate in active/active
node are redundantly load-sharing mode.
connected to the PP8600 Two static addresses for OAM&P /
routers. physical access to each system node.
These IP addresses, as used for
communication with the Core and GWCs,
can be private. (The USP also requires a
public IP address for communication with
the Networks Operations Centre.)
Media server (MS2000/UAS) [2]
H.248 Dual Ethernet Redundancy provided by One externally visible IP address for
signalling ports on independent connections dual-port network interface configured in
connections MS20x0 or on with both routers. active/standby mode. If the link terminated
UAS processor Each port is connected to on the primary port fails, the standby port
card. one of the PP8600 routers becomes active and the IP address is
but not the other. transparently switched to it.
Bearer Dual Ethernet Redundancy provided by One externally visible IP address per
connections ports on independent connections MS2010 or per UAS CG6000, for
(VoIP only [3] MS2010 or on with both routers. dual-port network interface configured in
each UAS Each port is connected to active/standby mode. If the link terminated
CG6000. one of the PP8600 routers on the primary port fails, the standby port
but not the other. becomes active and the IP address is
transparently switched to it.
CS2000 Core Manager
CBM Ethernet ports Redundancy provided by The CBM requires two IP addresses:
on Sun server independent connections One address for the signalling VLAN.
platform with both routers. One address for the OAM&P VLAN.
Each port is connected to It utilises two links to each PP8600 (one
one of the PP8600 routers signalling, one OAM&P), i.e. four PP8600
but not the other. links in all.
SDM NTRX50NK Redundancy provided by The SDM requires three IP addresses:
UMFIO independent connections One address for the signalling VLAN.
Personality with both routers. One address for the OAM&P VLAN.
Module (PM) SDM houses two PM One address for the DS-512 link to the
cards in SDM cards, each connected to MS.
shelf. one of the PP8600 routers It utilises two links to each PP8600 (one
but not the other. signalling, one OAM&P), i.e. four PP8600
links in all.
Other OAM&P nodes
CS2M Ethernet ports Redundancy provided by Each functional OAM&P element on Sun
comprising: on Sun server independent connections server requires three IP addresses for
SESM platform with both routers. redundancy.
APS Each port is connected to There is one logical IP address,
SSPF one of the PP8600 routers and two physical addresses referred to as
but not the other. test IP addresses.

100BaseT
Connection
provided by
IEMS Shares Sun server platform (and Ethernet connections) with CBM or CS2M
PMDM [4] Ethernet ports Redundancy provided by Each functional OAM&P element on Sun
on Sun server independent connections server requires three IP addresses for
platform with both routers. redundancy.
Each port is connected to There is one logical IP address,
one of the PP8600 routers and two physical addresses referred to as
but not the other. test IP addresses.
[1] All of the IP addresses for a given unit are consecutive. The first address is explicitly specified when configuring
the unit. The subsequent addresses are then assigned automatically.
[2] On CS LAN, but not a CS2000 component.
[3] VoATM bearer connections are supported over direct ATM / STM-x connections to the packet backbone
network, terminated on MS2020 or on UAS P200.
[4] PMDM is typically located on the NOC LAN rather than the CS LAN, in which case the customer (operating
company) is responsible for supplying it. It can, however, be supplied by Nortel and connected to the CS LAN if
this is requested by the customer.
Figure 10 illustrates the connectivity provided within a typical CS2000 CS LAN.
Backbone packet network
PP8600/0 PP8600/1
Default VLAN Default VLAN
192.168.0.2/22 192.168.0.3/22
Running VRRP GWCs GWCs Running VRRP
VRRP/IP 0 1 0 1 VRRP/IP
192.168.0.1 0 1 0 1 192.168.0.1
0 1 0 1
0 1 0 1
0 1 0 1
192.168.x.x/22 0 1 0 1 MS2010/0
3PC blade 0 1 0 1 192.168.x.x/22
0 1 0 1
Core 0 1 0 1 MS2010/1
0 1 0 1 192.168.x.x/22
3PC blade 0 1 0 1
192.168.x.x/22 0 1 0 1 MS2010/2
0 1 0 1 192.168.x.x/22
0 1 0 1
0 1 0 1 MS2010/3
USP 0 1 0 1 192.168.x.x/22
192.168.x.x/22 0 1 0 1
0 1 0 1
0 1 0 1
0 1 0 1 Netra cluster
192.168.x.x/22
CBM
192.168.x.x/22 Netra cluster
192.168.x.x/22
Figure 10: Example of CS LAN connectivity

B1.3.2 DMS Hardware Used for Internal Communication
B1.3.2.1 Message Switch (CS2000 Bus)

See Figure 4 on page 31 for an illustration of how the MS supports communication
between some CS2000 components in an XA-Core configuration that includes DMS
hardware such as the SDM and FLPP. The MS is not required or used in CS2000
configurations that include no legacy hardware.
CS2000 Components Linked by the MS

The MS can be used in a standard CS2000 configuration to support messaging between
the following:
! XA-Core
! SDM
! FLPP (if used instead of the USP)
! IOM / ISM
An Input / Output Module datalink housed in an Integrated Service Module shelf is
used to bring the SDM and the CS2000 into service. See section B1.7.5.1 on page
87 for further information.
! ENET switching matrix providing 64 Kb/s cross-connections with other units (see
section B1.3.2.2 on page 52)
MS Hardware
The bus consists of two identical load-sharing planes called Message Switches (MSs),
each with the capacity and connectivity to support the full internal messaging load if the
other plane fails. Each Message Switch plane comprises the following:
! A 32-bit Motorola 68000 Series control processor with on-board memory.
! Two buses for communication:
" The Transaction Bus (T-Bus) carries the messaging payload, i.e. the messages
sent from one CS2000 component to another via the MS. The Transaction Bus
operates at 128 Mb/s, with a typical throughput of 250,000 64-byte messages
per second and an average port-to-port delay of less than 100s.
" The Processor Bus (P-Bus) carries internal messages to control MS operation.
! A mapper subsystem that converts physical addresses (port numbers within the MS)
to/from the logical addresses of switch components.

! A port interface subsystem comprising a number of Port Interface Units (PIUs),

each of which combines:
" An interface card that logically faces towards the MS T-Bus and provides
MS-addressable ports.
" A paddleboard supporting one or more links to other switch components:
# OC-3 optical fibre links are used for XA-Core
# Subrate SR128 fibre links are used for the FLPP
# DS-512 optical fibre links are used for the SDM
# DS-30 copper links are used for ISM IOMs
! A clock subsystem that provides XA-Core with a clock source for Time Of Day
synchronisation. For accuracy, this clock subsystem is connected to an external
clock source such as a Building Integrated Timing System or a GPS clock system.
Note: In a hybrid configuration, the clock subsystem also provides the system clock
and network synchronisation for components such as trunk and line peripherals.
B1.3.2.2 ENET Switching Matrix

ENET is a switching matrix that provides crosspoints for the cross-connection of 64 Kb/s
channels. It is a single-stage time switch that provides switching with a constant delay of
125 s. ENET is connected to the MS by DS-512 optical fibre links; the OAU is
connected to ENET via DS-30 copper links. In a standard SuperNode CS2000 cabinet
lineup, ENET is housed in a dedicated additional cabinet.
In a CS2000 configuration that uses DMS hardware for selected functions, as illustrated
in Figure 4 on page 31, ENET is used primarily to support communication with the Office
Alarms Unit (OAU) described in section B1.7.5.3 on page 88.
In a hybrid configuration that supports interworking between CS2000 and legacy trunk
and line peripherals, as illustrated in Figure 5 on page 31, ENET is also used to support
communication with the legacy perpherals, as described in section B1.8 on page 89.

B1.4 Gateway Controllers (GWCs)

B1.4.1 GWC Types and Functions
Gateway Controllers (GWCs) enable CS2000 to access the packet network backbone.
Their two most important functions are:
! Controlling the operation of media gateways that support trunk and line access to
the packet network.
! Communicating with remote CS2000s across the packet network.
The hardware characteristics of all types of GWC are essentially the same. CS2000
datafill is used to specify the intended function of each GWC and ensure that its software
load is appropriately configured to equip it for its network role. Possible GWC network
roles are described in sections B1.4.1.1 to B1.4.1.3.
B1.4.1.1 GWC Support for Access to the Packet Backbone Network

GWCs can be configured to support and control access to the packet backbone network
for a wide range of media gateways and other units, as follows:
! Tunk media gateways supporting CCS7 trunks to/from the PSTN or other TDM
networks.
! Trunk media gateways supporting PBX interfaces (PRI, QSIG, DPNSS).
! V5.2 gateways supporting V5.2 access, currently for analogue lines only.
! High-capacity line media gateways supporting analogue subscriber lines and ADSL
(Asymmetrical Digital Subscriber Line) data access.
! H.323-controlled units such as IP-enabled PBXs and third-party routers.
! Low-capacity CPE line media gateways supporting access for analogue subscriber
lines attached to customer LANs or cable access networks.
! Remote CentrexIP clients attached to enterprise networks.
Note: CentrexIP clients are not controlled directly by GWCs, but by a CICM
(CentrexIP Client Manager) on the CS LAN; the CICM is in turn controlled by a
GWC. It is a twin-card unit that is housed alongside GWCs. See section B1.4.2 on
page 55 for details.
! Universal Port (UP) gateways supporting RAS dial-up access to internet and/or
intranet data sessions as well as VoIP voice calls.
See Chapter B2: CS2000 Support for Media Gateways for information about the media
gateways supported by CS2000.

B1.4.1.2 GWC Support for Peer-to-Peer Inter-MGC Signalling

CS2000 supports peer-to-peer signalling with other CS2000s and with compatible peer
MGCs such as the MCS5200.
Dynamic Packet Trunks for inter-CS signalling based on CCS7 encapsulated in SIP-T
(Session Initiation Protocol for Telephony) are supported by DPT GWCs with no
subtending units. DPTs are so called because trunk characteristics such as the ISUP
protocol variant to be used are determined on the basis of the telephony profile of the
selected route, which is downloaded to the DPT GWC during call establishment.
Note: SIP signalling to/from MCS5200 conveys no encapsulated CCS7. Instead, the
DPT supports IBN7 ISUP signalling that is interworked to SIP equivalents.
To support inter-CS signalling, the operation of DPT GWCs is co-ordinated with that of
one or other of the following unit types:
! The preferred implementation with effect from ISN07 is based on DPT GWCs
interacting with the Session Server. SIP signalling is terminated on the Session
Server, which extracts the CCS7 signalling and passes it on to the DPT GWC.
! Prior to ISN07 (and still supported for existing deployments), the standard
implementation was based on a DPT GWC interacting with another GWC
configured as a VRDN (Virtual Router Distibution Node) to provide an externally
visible IP address as a point of initial contact for its host CS2000. In this
implementation, DPT GWCs were responsible for terminating SIP signalling and
extracting CCS7.
See section B1.4.5.3 on page 62 for an illustrated explanation of how DPT GWCs interact
with these other units to support inter-MGC communication via SIP.
Note: Session Server support for SIP signalling and CCS7 encapsulation is designed to
be compliant with RFC3261, which defines a SIP interface for open interoperability
between call servers and other network elements. The VRDN implementation was based
on pre-RFC3261 drafts and has now been superseded by the Session Server
implementation.
B1.4.1.3 GWC Control of Units Providing Service Support Functionality

GWCs can be configured to support a range of gateways and other units that provide
specialised service support functionality, as follows:
! Audio Controller GWC for an MS2000 Series media server, which supports:
" Announcements
" Conferencing
" Bearer Channel Tandeming (BCT) functionality for call monitoring via the LI
(Lawful Interception) regulatory service
MS2000 Series media servers are enhanced, compact versions of the UAS
(Universal Audio Server), which provided this functionality prior to ISN07 and
continues to be supported.
The MS2000/UAS is typically located on the CS LAN, but in terms of CS2000
logical network architecture it is an independent media server, and it is therefore
described separately, in Chapter B3: CS2000 Support for Media Servers.

! GWC for RTP Media Portal providing media proxy functionality

The RTP media portal is a GWC-controlled media proxy that supports public
address discovery for media streams that have been routed via a NAT. It supports
two specific capabilities:
public network.
gateways.
Note: An RTP Media Portal can be co-located with the CS LAN and has a
connection with the CS LANs private VoIP domain as well as one with the carriers
public network, but in terms of CS2000 logical network architecture it is an
independent media proxy, and it is therefore described separately, in Chapter B5:
Media Proxies.
! A GWC can be configured to support Redirecting Media Gateway Controller
(RMGC) functionality, which enables line gateways to discover the address of their
controlling GWC.
Some functions can be simultaneously supported by a single gateway, e.g. RMGC
functionality is typically provided by an Audio Controller GWC.
B1.4.2 CentrexIP Client Manager (CICM)

The CentrexIP Client Manager (CICM) is described in this section because it is a
twin-card unit housed in the SAM21 shelf alongside other GWCs, although it is itself
controlled by a GWC. The CICM acts as a terminal server for multiple remote CentrexIP
clients, terminating UniStim signalling and supporting client services such as registration
and call logging.
Remote IP clients controlled by the CICM via UniStim include:
! i2001, i2002 and i2004 Ethersets
! m6350 soft clients
For further information, see Chapter B4: CentrexIP Remote Clients and the CentrexIP
Client Manager (CICM).
Implementation details:
! CICM subtends GWC and is controlled by H.248
! Each CICM can support up to 3050 users
! CICM supports failover for active calls
! The CICM EM runs on a separate card (typically duplicated for redundancy) that is
housed in a SAM21 shelf in the same way as CICM card pairs. A given CS2000
configuration requires only one CICM EM to provide OAM&P support for all its
CICMs.
! CICM and CICM EM CPU cards are detected via PCI device identification
Note: The twin-card ISN07 implementation of the CICM replaces an initial ISN06.x
implementation of the CICM as a SAM16 unit connected to CS LAN and controlled by
GWC via H.248 (like UAS), supporting up to 1,000 users per shelf.

B1.4.3 GWC Hardware Characteristics

GWCs are housed in SAM21 card cages or shelves, as described in section B1.4.4 on page
57, along with a pair of Shelf Controller (SC) cards operating in hot standby mode to
provide control and co-ordination for the entire shelf. The hardware characteristics of the
SC and GWC are as follows:
! Shelf Controller characteristics
A SAM21 SC provides control and co-ordination for a complete SAM21 shelf. It
consists of two separate SC cards, each with the following characteristics:
" Single-board computer with 366 MHz processor, 128 Mbytes RAM and 96
Mbytes flash memory
" Ethernet 10/100BaseT port
! Gateway Controller characteristics
A GWC consists of two separate GWC cards, each with the following
characteristics:
" Single-board computer with 366 MHz processor and 128 Mbytes RAM
" Ethernet 10/100BaseT port
See section B1.4.5 on page 60 for information about the IP addressing scheme used
to support duplicated GWC cards.

B1.4.4 GWC Packaging

GWCs are housed in SAM21 card cages or shelves, which are in turn housed in cabinets.
See the following sections for further information:
! Section B1.4.4.1: SAM21 Card Cages
! Section B1.4.4.2: Cabinets used to house GWCs/SAM21s on page 59
B1.4.4.1 SAM21 Card Cages

GWCs are housed in SAM21 card cages. The SAM21 is so called because it is a
single-shelf Service Application Module (SAM) with 21 slots for housing circuit packs.
These 21 slots are allocated as follows:
! Shelf Controller
Slots 7 and 9 are system slots that are reserved for a pair of Shelf Controller (SC)
cards operating in hot standby mode, i.e. only one of the SC cards is active at a given
moment. The two SC cards make up a single logical SC unit.
! Gateway Controllers
Slots 1-6 and 11-20 are I/O slots that are reserved for GWCs. Each GWC consists
of two separate Service Unit (SU) cards operating in hot standby mode. The two
cards that make up a GWC can be housed in any of the GWC slots in the SAM21;
they need not be in adjacent slots, i.e. although a GWC logically comprises two
cards, it is not physically a twin-card unit.
! Slot 21 at the end of the shelf is always left empty.
A fully provisioned SAM21 needs to be allocated 9 ports on each of the dual PP8600
routers that support the CS LAN, one port for the Shelf Controller card pair and one for
each two-card GWC.
The base technology for the SAM21 is the Motorola cPCI card cage. The backplane of the
card cage provides a cPCI bus for communication between the circuit packs housed in the
card cage. This bus has three segments, which are bridged by Hot Swap Controller (HSC)
cards. Access to the PP8600-based CS LAN is supported by Ethernet 10/100BaseT ports
on the cards themselves.
GWCs are connected both to the cPCI bus on the SAM21 backplane and to the CS LAN.
The cPCI bus enables the SC to communicate with GWCs to provides control and
co-ordination for the shelf. The CS LAN enables GWCs to communicate with other
CS2000 components, including XA-Core and other GWCs, and (via the LANs dual
PP8600 routers) with media gateways and other CS2000s. If an ATM backbone network
is in use, access to it is via IP / AAL5 / ATM through the PP8600 router.

Figure 11 summarises which GWCs and other units are housed in a SAM21, and
illustrates how they use the CS LAN to communicate with each other and with other
CS2000 and packet network components.
Notes:
! Communication between SCs and GWCs via the cPCI bus is not illustrated.
! Not all types of GWC or GWC equivalent are shown, e.g. the configuration
illustrated does not show a VRDN or a CICM EM.
,
Up to 8 Gateway Controllers (GWCs)
GWCs for DPT Audio Intra-CS links to

trunk and GWCs for CICM CS200 Core,
H.323 Controller
line media trunks controlled Session Server
proxy (AC) GWC by line
gateways, to/from GWC for media and other GWCs
GWC
Ethernet CS LAN
e.g. PVG peer CSs server
Dual
PP8600
routers
Note: Each GWC actually consists of

a pair of cards operating in hot standby Media
mode, as explained in detail in section Managed
IP or ATM gateways
B1.4.5 on page 60, but for simplicity and other
this hardware duplication is not shown. network
CS2000s
Similarly, the SC comprises two cards.
The packet network
Shelf backbone can be either
IP or ATM; if an ATM
SAM21 Controller
(SC) backbone network is in use,
signalling to/from CS2000
card cage is via IP / AAL5 / ATM
(AAL5 added/removed
by PP8600 routers))
Figure 11: Logical view of different GWC types and their interaction

B1.4.4.2 Cabinets used to house GWCs/SAM21s

Figure 12 illustrates how up to three SAM21 card cages can be housed in a standard
Packet Telephony Equipment (PTE2000) cabinet, and summarises the allocation of card
slots on SAM21 shelves for different purposes.
Up to three
SAM21 card cages
System slots per cabinet,
7 and 9 house one per shelf
SC cards
I/O slots (11-20)

I/O slots (1-6) for GWC cards
for GWC cards
Figure 12: SAM21 card cages and GWCs housed in a dedicated PTE2000 cabinet
A PTE2000 cabinet need not be dedicated to housing SAM21 card cages and GWCs, as
follows:
! Units other than GWCs may be housed in a SAM21 card cage. In the main Call
Control Frame of a CS2000-Compact configuration, for example, SAM21s are used
to house not only GWCs, but also 3PC processor cards, as illustrated in Figure 7 on
page 39.
! Units other than SAM21s can be housed in a PTE2000 cabinet. For example, the
main Call Control Frame of a CS2000-Compact configuration can house up to six
MS2010 media server units instead of a third SAM21.
PTE2000 cabinets housing three SAM21s containing only GWCs are typically used either
to increase capacity or in standard configurations where XA-Core is housed in a separate
cabinet.

B1.4.5 GWC Interaction with the Packet Network
B1.4.5.1 GWC Configuration and Operation

Logically, a GWC is a single entity that can be accessed via a single IP address.
Physically, however, a GWC consists of two separate GWC cards, each of which has its
own 10/100BaseT Ethernet port. At a given moment, one of these cards is active and the
other is inactive.
The two cards that make up a given GWC need not be adjacent. They can occupy any of
the SAM21 shelf slots reserved for GWC cards, i.e. a GWC comprises two cards, but it is
not physically a twin-card unit. In theory, the two cards that make up a given GWC could
even be housed in separate SAM21 shelves; this is not supported in ISN07, but will be
supported in a subsequent release.
The operation of the inactive GWC card/unit is synchronised with that of the active unit,
so that in the event of a problem the inactive unit can take over from the active unit. This
is known as warm standby operation. The takeover process is known as a SWACT
(Switch of Activity), and may be either warm or cold. If a warm SWACT occurs, stable
calls (calls that have been answered) will survive, but calls being set up will be dropped.
If a cold SWACT occurs, all calls are dropped.
A GWC has four IP addresses:
! Two logical addresses for functional / messaging access:
" The IP address of the current active unit, which is used by other network
entities. Specifically, this is the address used by other GWCs and the Core for
sending messages related to the handing of calls, and by media gateways
controlled by the GWC in question. This is the IP address specified when the
GWC is datafilled in table SERVRINV (see section C2.4 on page 189 for
details); the other three IP addresses are assigned automatically in sequence.
" The IP address of the current inactive unit, which is used only for
synchronisation and for heartbeat messaging to/from the corresponding active
GWC unit.
The externally visible IP address is a floating address, i.e. the address used is always
the same, but the physical unit that it denotes changes in the event of a SWACT.
! Two static addresses for OAM&P / physical access to specific GWC cards:
" The IP address of Unit #0
" The IP address of Unit #1
These addresses are mapped on to Layer 2 MAC (Media Access Control) addresses,
i.e. Ethernet physical addresses.
Other hosts that wish to communicate with a GWC rely on the Ethernet ARP (Address
Resolution Protocol) running on the CS LAN. Essentially, another host on the CS LAN
broadcasts a message indicating that it is looking for a particular Layer 3 IP address (that
of the current active GWC unit), and the active GWC unit replies with its MAC address.
The other host can then send an Ethernet Layer 2 message to the correct physical address.
When a GWC SWACT occurs, the newly active unit broadcasts a GARP (Gratuitous
ARP) message announcing the resulting change in IP-to-MAC address mapping. This
ensures that messages destined for the IP address of the GWCs active unit are sent to the
MAC address of the newly active unit.

B1.4.5.2 Media Gateway Configuration

GWCs and large media gateways (PVGs) are separately provisioned with the address
information they need to communicate with each other. For each large media gateway
controlled by a GWC, GWC datafill specifies information such as the gateway IP address,
UDP port and trunk or line endpoints available. Similarly, media gateway datafill
specifies information about the controlling GWC, including its IP address and the UDP
port to be used for device control messaging.
GWCs and small CPE line media gateways obtain each others address information
dynamically. Details of the method used vary depending on the gateway type and on how
the CS2000 network has been designed to operate, but the basic sequence of events is:
1 Line media gateway is booted up and automatically broadcasts a DHCP (Dynamic
Host Configuration Protocol) message requesting configuration data.
2 DHCP server responds by sending the gateway a DHCP message giving the name
and location / address of a TFTP (Trivial File Transfer Protocol) server from which
it can download a configuration file.
3 Line media gateway sends the specified server a TFTP request to download the
required configuration file.
4 TFTP server responds by downloading a file containing configuration data,
including the IP address of the GWC with which the gateway should register itself.
5 Line media gateway sends the specified GWC an RSIP (Restart In Progress)
message to initiate registration. Depending on the gateway type and the
device/media control protocol in use, the GWC does one of the following:
" For a customer LAN gateway controlled via MGCP, the IP address provided
in the downloaded configuration file is that of an Audio GWC configured to
provide RMGC (Redirecting MGC) functionality. This responds to the RSIP
by sending back an MGCP message specifying the name and IP address of the
GWC that will actually control the gateway. The gateway then sends another
RSIP to the correct GWC.
GWC support for RMGC functionality is described in A89008489. It requires
the GWC to maintain a local copy of the MG-to-MGC mapping database,
instead of querying a central network view database.
" For a cable gateway controlled via NCS, the IP address provided in the
configuration file is that of the correct GWC. On receipt of the RSIP, this
GWC contacts a central DNS (Domain Name Server) supporting mapping
between FQDNs (Fully Qualified Domain Names) and IP addresses. This
returns the IP address to use for the line media gateway in response to the
GWCs query specifying its FQDN. See section C2.8.3 on page 201 for a
more detailed description.
6 The eventual response to the RSIP is a message from the GWC to the line media
gateway, confirming that it has been registered and that calls can be made to/from it.
DHCP and TFTP servers are not CS2000 components, and their type and location are a
matter for the network operator. Typically, they will be located remotely from the CS2000
at a point where traffic to/from many line media gateways is aggregated. Similarly, the
way in which DNS functionality is provided is a matter for the network operator.
For information about the provisioning of GWCs to support media gateways, see section
C2.5 on page 190 (trunk access) and section C2.8 on page 200 (line access).

B1.4.5.3 Selection and Use of GWCs for Peer-to-Peer Inter-MGC Signalling

MGCs such as the MCS5200. The protocol used is Session Initiation Protocol (SIP) or SIP
for Telephony (SIP-T). The difference between SIP and SIP-T is that SIP-T messages
convey encapsulated CCS7 messages while SIP messages do not. SIP-T therefore
supports CCS7 signalling directly, by enabling CCS7 messages to be inserted in and
extracted from SIP-T messages. SIP does not provide direct CCS7 support, but SIP
messages can be interworked with CCS7 equivalents to provide indirect CCS7 support.
Dynamic Packet Trunks for inter-CS signalling are supported by DPT GWCs with no
selected route, which is downloaded to the DPT GWC during call establishment. For
SIP-T, the telephony profile indicates the protocol characteristics of encapsulated CCS7
signalling messages, which can be those of any supported ISUP or TUP variant. For SIP,
the telephony profile indicates the CCS7 protocol that is to be interworked with SIP,
which in ISN07 can only be IBN7 ISUP. The telephony profile itself is selected on the
basis of the far-end host name, as determined by translations and routing for an originating
CS2000 or as indicated by the first incoming message for a terminating CS2000.
Typically, SIP-T is used for signalling between CS2000s, while SIP is used for signalling
between CS2000 and MCS5200.
The DPT GWCs on a CS2000 provide a pool of resources that can be used for connections
to any peer CS2000 or compatible MGC. A DPT GWC is selected and allocated only for
the duration of a given call, and is then returned to the pool for re-use. The fact that trunk
group data for a selected DPT is downloaded to its DPT GWC only when the DPT is
selected and allocated promotes efficiency in two ways:
! It is not necessary to provision inter-CS trunks statically, which would involve
estimating the proportion of traffic to be handled by each type of trunk, with the
consequent risks of under-provisioning (leading to unnecessary congestion) or
over-provisioning (with wasted capacity).
! It is not necessary for a CS2000 or peer MGC to know the IP addresses of all the
DPT GWCs on another CS2000 with which it may need to communicate, only a
single target IP address on each remote CS2000.
! Prior to ISN07 (and still supported), the standard implementation was based on a
DPT GWC interacting with another GWC configured as a VRDN (Virtual Router
Distibution Node) to provide an externally visible IP address as a point of initial
contact for its host CS2000. In this implementation, DPT GWCs were responsible
for terminating SIP signalling and extracting CCS7.
Figure 13 on page 63 illustrates how DPT GWCs interact with these other units to support
inter-MGC communication via SIP / SIP-T.
Note: Session Server support for SIP signalling and CCS7 encapsulation is designed to
be compliant with RFC3261, which defines a SIP interface for open interoperability

between call servers and other network elements. The VRDN implementation was based
on pre-RFC3261 drafts and has now been superseded by the Session Server
implementation. See Chapter D2: SIP and SIP-T for more details.
GWC support for inter-CS signalling using Session Server
Originating CS2000 Terminating CS2000
Call processing Call processing

DPT DPT
provisioning provisioning
DPT Inter-CS DPT

GWC connection GWC
Access Session Session Access
GWC DPT Server Server DPT GWC
GWC GWC
DPT DPT
GWC GWC
Session Servers terminate

SIP / SIP-T signalling
Media Media
gateway gateway
DPT GWCs terminate CCS7 signalling
GWC support for inter-CS signalling using a VRDN
DPT DPT
Inter-CS
DPT connection DPT
GWC VRDN GWC
Access Access
GWC DPT A GWC DPT GWC
GWC GWC
No VRDN
DPT for call DPT
GWC origination B GWC
A Signalling for initial INVITE and redirection

response is between DPT GWC and VRDN
Media Media
gateway gateway
B All SIP / SIP-T signalling after redirection is between DPT GWCs
Figure 13: DPT GWC interaction with other units to support peer-to-peer SIP signalling

B1.4.6 GWC Signalling Protocols

The primary purpose of a GWC is to act as an intermediary between packet network
components (gateways, peer MGCs, media servers) and the call processing and service
logic functionality provided by the CS2000 Core. It does this by relaying requests and
information from the packet network components to the Core, and relaying instructions
and information from the Core. GWCs terminate packet network signalling and map this
on to proprietary intra-CS2000 signalling to/from the Core. GWCs must also provide
protocol support for OAM&P access. GWC software also supports Layer 4-7 ISUP and
TUP call processing (but not maintenance messaging), and call control signalling for
non-CCS7 interfaces such as PRI, QSIG and V5.2. Three types of protocol are supported,
as described in sections XX to XXX:
B1.4.6.1 GWC Support for Packet Network Signalling Protocols

This section describes GWC support for packet network signalling protocols. See Part
DPacket Telephony Protocols for descriptions of each protocol, and particularly Figure
61 on page 233 for an illustration of the protocol stacks with all the acronyms expanded.
Note: This signalling is conveyed over IP even if an ATM backbone network is in use.
Specifically, IP / AAL5 / ATM is used across any ATM part of the packet backbone.
Two types of access signalling are supported:
! Media or device control signalling that allows the GWC to control the
characteristics of the packet network bearer connections used for a call. Protocols
supported in ISN07:
" H.248 / UDP / IP
# Communication with PVGs configured as trunk or V5.2 gateways.
# Communication with large telco-located MG9000 line gateways.
# Communication with the CentrexIP Client Manager (CICM) that
controls remote CentrexIP clients.
# Communication with media servers to support announcements (tones
are provided by gateways), conferencing and LI.
" ASPEN / UDP / IP
Proprietary protocol supported as an alternative to H.248 for communication
with PVGs configured as trunk gateways.
" H.323 / (TCP or UDP) / IP
For communication with H.323-controlled units such as IP-enabled PBXs and
third-party routers.
" UniStim / RUDP / UDP / IP
UniStim is the protocol used by the CentrexIP Client Manager to
communicate with CentrexIP remote clients. It is a Nortel Networks protocol,
but is available under licence to other equipment vendors who wish to design
and manufacture CentrexIP-compatible terminals.
" NCS / UDP / IP
Communication with cable network line gateways, in support of VoIP.
" MGCP / UDP / IP
Communication with customer LAN line gateways, in support of VoIP.

" MPCP / UDP / IP

Communication with RTP Media Portal to support media proxy functionality.
MPCP is a version of standard MGCP enhanced with proprietary extensions
designed to support multimedia sessions and NAPT.
" DSM-CC / UDP / IP
Communication with CVX1800 UP gateways, in support of RAS and VoIP.
! Backhauled call control signalling (setup and clearing messages) for message-based
non-CCS7 interfaces such as ISDN PRI, QSIG and V5.2, for which access network
signalling is terminated at the media gateway. Protocol stacks supported in ISN07:
" Q.931 / IUA / SCTP / IP
" QSIG / IUA / SCTP / IP
" V5.2 / V5UA / SCTP / IP
" DPNSS / H.323 / TCP / IP, which is interworked at the H.323 GWC to
DPNSS over QSIG
! Call control signalling for analogue subscriber lines. Protocol stacks supported in
ISN07:
" H.248 / UDP / IP (for lines served by high-capacity MG9000 gateways)
" MGCP / UDP / IP (for lines served by gateways on customer LANs)
" NCS / UDP / IP (for lines served by MTA gateways on cable networks)
In these cases, the protocol used for call control is the same protocol used for media
control, i.e. one protocol supports both types of signalling. Call control signalling
allows the GWC to be informed of events such as hook state changes, to initiate
digit collection, and to request the application of ringing and in-band tones.
GWCs support three types of peer-to-peer signalling by means of the following protocols:
! Circuit-oriented ISUP or TUP signalling
" SIP-T (ISUP or TUP) / TCP or UDP / IP
! SIP signalling with no encapsulated CCS7 signalling
" SIP-T (no CCS7) / TCP or UDP / IP interworked to IBN7 ISUP
! TCAP-based NCAS (Non Call Associated Signalling) with remote CS2000s
(strictly speaking, with USPs belonging to remote CS2000s) via the managed IP
core network. Protocol stack:
" TCAP / SCCP / MTP3 / M2PA / UDP / IP
Note: SDP session description signalling is used to complement both access
signalling and inter-CS signalling. It indicates the gateway IP address / port number
to be used for a media stream, and conveys information about media stream
characteristics and codec capabilities for use in codec negotiation.

B1.4.6.2 GWC Support for Proprietary Intra-CS Protocols

GWCs support the following proprietary protocols for communication with other CS2000
components:
! Circuit supervision signalling between the Core and GWCs, e.g. ISUP supervision
or (for GWCs supporting Q.931/QSIG access or analogue line gateways) Peripheral
Processor Virtual Machine (PPVM) protocol.
! Fabric Control Messages (FCM) sent by the Core to enable direct peer-to-peer
signalling between GWCs. The FCM also provides connectivity information to
access GWCs to allow them to control their media gateways.
! Inter-GWC Messaging between peer GWCs after FCMs have established a
peer-to-peer connection, including CSMs (Channel Supervision Messages).
B1.4.6.3 GWC Support for OAM&P Protocols

GWCs support the Simple Network Management Protocol (SNMP) for communication
between GWCs and the CS2000 GWC Manager running on a Sun Netra OAM&P server
B1.4.7 GWC Provisioning and Capabilities

Note: All figures quoted are general, and are subject to variation depending on the
network call model and capacity requirements. Network-specific estimates should be
! SAM21s / GWCs
" A SAM21 has a maximum of 16 slots available for GWCs, and can therefore
house a maximum of 8 GWCs of all types.
The maximum number of GWCs that can be housed in a SAM21 Call Agent
shelf in a CS2000-Compact configuration is 7, because shelf slots are required
for the 3PC.
" The recommended maximum number of GWCs that can be provisioned on a
CS2000 is 60 GWCs of all types, of which up to 30 can be GWCs for media
gateways and 30 can be packet-side GWCs (SIP-T, VRDN, UAS control).
" A given GWC can support either trunk access or line access, but not both.
! DPTs
" Maximum 81,860 provisioned on a CS2000
" Maximum 6,000 provisioned between any two CS2000s
! VRDN GWCs
" A VRDN is responsible for communication with one or more other CS2000s
or compatible MGCs such as MCS5200, up to a datafill-defined maximum of
64.
" All traffic to/from a given remote CS2000 or compatible MGC must be
handled by one VRDN.
Note: Because each VRDN comprises an active unit and an inactive unit,
redundancy is built in. It is not necessary to use a second VRDN to provide
backup for an inter-CS2000 connection.

" A CS2000 can support a maximum of 10 VRDNs.

" A VRDN that supports SIP-T over UDP can support 900,000 BHCA.
This total capacity is shared between all the inter-CS connections supported
by a given VRDN.
Note: Because no more than one VRDN can be used for all traffic to/from a
given CS2000, the maximum capacity between any two CS2000s is also
subject to these limits.
" There is no limit to the number of simultaneous calls that can be supported by
a VRDN using UDP.
" The number of VRDNs required to support a given number of connections to
other CS2000s or compatible MGCs depends on the call model and capacity
requirements for the network in question, and should be determined in
consultation with Nortel Sales Engineering.
" In a network based on a single CS2000, it is not necessary to have a VRDN.
! DPT GWCs
" The DPT GWCs on a CS2000 make up a pool of available resources that can
be used for any peer-to-peer connection to/from the CS2000. SIP-T DPTs are
allocated and dynamically provisioned with trunk subgroup data on a per-call
basis.
" Up to 4,093 DPTs (strictly speaking, 4,093 DPT Terminal IDs) can be
provisioned on a DPT GWC. This is supported by allowing two logical
subtending DPT nodes to be defined when the GWC is datafilled, each
supporting up to 2048 DPTs.
" A DPT GWC can terminate up to 4,093 simultaneous inter-CS calls (i.e. 4,093
DS0s) or 96,000 BHCA.
" In a network based on a single CS2000, no DPT GWCs are required.

! Trunks / lines / endpoints

" A CS2000 can support an overall maximum of 200,000 trunk and/or line
endpoints. Within this, the limits that apply to different endpoint types are:
# 200,000 CCS7 trunks
Note: To support 90,000 or more CCS7 trunks in a configuration that
uses the FLPP to support CCS7 signalling links, the CS2000 Core must
be configured to use external routing, with some of the LIU7s in the
FLPP used to support external router functionality (see Figure 20 on
page 80 for details) instead of terminating TDM-side CCS7 signalling
# 48,000 PRI or QSIG trunks
# 130,000 lines
" The number of TDM-side CCS7 trunks that can be supported on a given
CS2000 is reduced by 4,093 for each DPT GWC supported. For example, a
CS2000 with the maximum number of 112,000 CCS7 trunks and a total of 8
DPT GWCs could support a maximum of 79,256 TDM-side CCS7 trunks
(112,000 minus 8x4093).
" The allocation of the total number of supported trunks between access GWCs
and DPT GWCs depends on the call model to be supported by the CS2000.
At one extreme, for example, given a network based on one CS2000 with no
calls networked to other CS2000s, all trunks would be allocated to access
GWCs. At the other (less likely) extreme, given a network with no
intra-CS2000 calls and all calls networked, 50% of trunks would be allocated
to access GWCs and 50% to DPT GWCs. In call models for large CS2000s,
it is common to assume that approximately 40% of trunks are DPTs.
! GWCs and gateways for trunk access
" A trunk access GWC can support up to 30 media gateways.
Note: From the perspective of the GWC, each VSP (Voice Service Processor)
housed in a PVG is a separate gateway. A given PVG frame can house
multiple VSPs, each independently performing circuit/packet conversion. See
section B2.3 on page 99 for details.
" A trunk access GWC can support up to 4,093 TDM-side trunk endpoints
terminated on media gateways (up to 2,048 on a given gateway).
" A trunk access GWC can support both E1 and T1 TDM-side endpoints.
" Maximum BHCA 96,000 (CCS7) or 45,000 (PRI or QSIG)
" Maximum simultaneous calls 4,093 (CCS7) or 3,870 (PRI or QSIG)
" Maximum 130 PRI or QSIG D-channels and 3,870 B-channels
Note: A trunk GWC can support CCS7, PRI and QSIG access. In this case, the
overall maximum of 4,093 endpoints is allocated as required between CCS7 bearer
channels, ISDN B-channels, and ISDN D-channels (one D-channel for every 30
B-channels).

! GWCs and gateways for V5.2 access

" A V5.2 access GWC can support a maximum of four media gateways. This
limit is imposed by base GWC configuration restrictions that apply to large
media gateways because a PVG VSP (Voice Service Processor) is considered
to be a large gateway.
Note: From the perspective of the GWC, each VSP housed in a PVG is a
separate gateway. A given PVG frame can house multiple VSPs, each
independently performing circuit/packet conversion. See section B2.3 on
page 99 for details.
" Maximum number of line endpoints that can be supported by a V5.2 access
GWC is 6,384.
" Maximum BHCA that can be supported by a V5.2 access GWC is 38,868.
" Lines are assigned to V5.2 interfaces, which are connected to Access
Networks (ANs). Each V5.2 interface consists of a maximum of 2048 lines.
All of the lines belonging to a given interface, and all the gateways (VSPs)
serving those lines, must be supported by one GWC.
" Maximum 3,840 simultaneous calls per line GWC
" Maximum 128 V5 links (E1s) per line GWC
Note: These E1s are controlled by the V5.2 GWC, but are physically
terminated at the PVG.
" Maximum 53 V5.2 interfaces per line GWC, with or without V5.2 protection
switching.
Note: V5.2 software permits up to 63 interfaces, but the physical maximum
that can be supported by a GWC is 53 because this is the maximum number
of 120-line V5.2 ANs (the smallest size supported) that can be accommodated
within the GWC limit of 6400 lines. See section B2.4.2: Capacity and
Configuration on page 112 for further information.
! GWCs for H.323 access
" Maximum 1024 ports
" Maximum 1024 simultaneous calls

! GWCs and gateways for analogue line access

" Maximum number of line endpoints that can be supported by a line access
GWC depends on the type of line gateway:
# For large telco-located line gateways such as MG9000, the maximum is
5,920 endpoints (see A00004236).
# For small CPE line gateways, the maximum is 6,400.
" Maximum BHCA that can be supported by a line access GWC is 38,000.
" Large telco-located line gateways (MG9000)
# Single-frame configuration
$ 1952 POTS lines
$ 488 POTS+ADSL lines
# Maximum four-frame configuration
$ 5,920 POTS lines
" CPE LAN line gateways (Ambit, Askey, Mediatrix)
# Lines are assigned to line groups, each consisting of a maximum of
1024 lines (actually 1023, as one is reserved for maintenance). All of the
lines belonging to a given line group, i.e. all the gateways serving those
lines, must be supported by one GWC.
# Each line gateway supports
$ 1, 16 or 32 analogue subscriber lines (Ambit)
$ 4, 12 or 30 analogue subscriber lines (Askey)
$ Up to 24 analogue subscriber lines (Mediatrix)
# Maximum 2,000 simultaneous calls per line GWC
" MTA line gateways
# Lines are assigned to line groups, each consisting of a maximum of
1024 lines (actually 1023, as one is reserved for maintenance). All of the
lines belonging to a given line group, i.e. all the gateways serving those
lines, must be supported by one GWC.
# Each MTA line gateway supports up to two analogue subscriber lines.
# Recommended maximum of 1,000 subtending MTA gateways for each
CMTS (Cable Modem Termination System) used to relay NCS
signalling between GWC and MTAs. This implies a maximum 2,000
lines per CMTS.
# Maximum 2,000 simultaneous calls per line GWC
! Audio Controller GWC (AC) for MS2000/UAS media servers
" A maximum of 1280 resources (media server ports) can be controlled by an
AC GWC, with usage as follows:
# One port is used for each announcement played to a call party
# One port per call party is used for conferencing
# Four ports are used for a call subject to LI monitoring
" Maximum 1280 simultaneous announcements
" Maximum BHCA:
# 80,000 (MS2010 / VoIP)
# 60,000 (MS2020 / VoATM)
# 60,000 (UAS)

B1.5 Session Server

ISN07 introduces the Session Server to interact with DPT GWCs in support of
peer-to-peer communication across the packet backbone network using SIP / SIP-T
signalling, superseding the use of GWCs configured as VRDN GWCs for this purpose.
Session Server support for SIP signalling and CCS7 encapsulation is designed to be
compliant with RFC3261, which defines a SIP interface for open interoperability between
call servers and other network elements. Prior to the ISN07 introduction of the Session
Server implementation, CS2000 support for SIP was based on pre-RFC3261 drafts and
implemented by configuring GWCs as VRDNs to provide initial points of contact for
peer-to-peer SIP signalling. This VRDN implementation is still supported, but has now
been superseded by the Session Server implementation.
MGCs such as the MCS5200. The protocol used is Session Initiation Protocol (SIP) or SIP
for Telephony (SIP-T). The difference between SIP and SIP-T is that SIP-T messages
convey encapsulated CCS7 messages while SIP messages do not. SIP-T therefore
supports CCS7 signalling directly, by enabling CCS7 messages to be inserted in and
extracted from SIP-T messages. SIP does not provide direct CCS7 support, but SIP
The role of the Session Server is to terminate SIP / SIP-T signalling and present CCS7
signalling to the DPT selected for a given call. This contrasts with the VRDN
implementation, in which SIP termination functionality had to be provided by the DPT
GWC. See section B1.4.5.3 on page 62 for an illustratede description of the interaction
between DPT GWCs and the Session Server.
The Session Server consists of a NEBS Level 3 compliant hardware platform plus a
software framework and architecture for developing carrier-grade applications and
services. The hardware platform is the Hewlett Packard HP-CC3310, which provides
processing, memory, and disk capacity for STORM, SIP and SIP applications. The base
layer of Session Server Software uses NCGL (Nortel Carrier Grade Linux) layer, which
includes the Linux kernel. See A00003933 for details. Hardware characteristics:
! One or two 2.4 GHz Pentium 4 Xeon processor with 512 Kbyte integrated cache.
! Support for a maximum of 12 Gbytes of memory using up to six memory modules.
! Support for up to two SCSI hard disk drives with 36 / 73 / 146 Gbytes storage.
! Two 10/100/1000BaseT Ethernet ports for LAN connections.
The Session Server functions as its own Element Manager (EM). This means that
provisioning and maintenance activities for a Session Server take place on the Session
Server itself, using web pages provided by a web server running on the Session Server.

B1.6 CCS7 Signalling Terminations

CS2000 can support CCS7 signalling using either the USP (Universal Signalling Point)
or the FLPP (Fiberised Link Peripheral Processor), as shown in Figure 14.
Scenario A:- CCS7 support provided by USP (Universal Signalling Point)
TDM-side switches,
CS2000 TCAP
ISUP TUP
SCPs, etc
TCAP SCCP Conventional
ISUP TUP CCS7
SCCP MTP3 signalling
MTP2 network
M3UA
SCTP MTP1
CS2000 USP
Core IP TCAP
SCCP
MTP3
Other CS2000s,
MCS5200s, etc
M2PA
CS LAN SCTP
IP IP control
network over
Session backbone
DPT Server SIP-T SIP-T
GWC packet network
or ISUP TUP
VRDN
SDP SDP
See section B1.4.5.3 on page 62 for TCP or UDP
information about DPT GWC interaction
with Session Server or VRDN IP
Scenario B:- CCS7 support provided by FLPP (Fiberised Link Peripheral Processor)
CS2000
Message Switch (CS2000 bus)
TDM-side switches,
TCAP
ISUP TUP
SCCP Conventional
CCS7 SCPs, etc
Proprietary messaging MTP3
signalling
XA-Core FLPP MTP2 network
MTP1
Note: No packet network support for

CS LAN NCAS (Non Call Associated Signalling)
with FLPP-based configuration
Session SIP-T SIP-T

Other CS2000s,
MCS5200s, etc
DPT Server
GWC ISUP TUP IP control
or
VRDN network over
SDP SDP backbone
TCP or UDP packet network
See section B1.4.5.3 on page 62 for
information about DPT GWC interaction IP
with Session Server or VRDN
Figure 14: Alternative methods of supporting CCS7 on CS2000

B1.6.1 USP (Universal Signalling Point)

Use of the USP to support CCS7 signalling is recommended for all new CS2000
configurations. The USP uses the CS LAN for intra-CS2000 communication, especially
with the Core. It is available in both standard and Compact CS2000 configurations.
Note: A Compact version of the USP is available for use in CS2000-Compact
configurations as an alternative to the full-scale USP. See section B1.6.1.4 on page 77 for
a description of the USP-Compact and its capabilities.
B1.6.1.1 USP Functions
Signalling to/from CCS7 Signalling Network

The primary purpose of the USP is to provide CCS7 signalling terminations that enable a
CS2000 to exchange ISUP, TUP and TCAP signalling with a conventional TDM-side
CCS7 signalling network. In this role, the USP is a complete replacement for the FLPP
described in section B1.6.2 on page 78, and use of the USP rather than the FLPP is
recommended in new CS2000 configurations.
The USP supports circuit-oriented CCS7 signalling terminations for ETSI ISUP, IBN7
(ANSI ISUP+), national ISUP and national TUP interfaces. The term circuit-oriented
means that there is a traffic circuit (a channel conveying voice or data) associated with a
given signalling link, and that the messages conveyed over a signalling link relate to a
particular traffic circuit, e.g. they control call establishment and clearing over a particular
traffic circuit.
The USP also supports circuit-independent CCS7 signalling terminations for TCAP
interfaces. The term circuit-independent means that there is no traffic circuit associated
with a given signalling link. Such signalling links enable peer entities on different nodes
to exchange information and instructions. The operations and parameters used for this
purpose may be defined to support a particular service or defined as elements of a
general-purpose service support platform such as the Intelligent Network Application Part
(INAP).
The external physical interface between the USP and the CCS7 signalling network is
typically provided by means of E1 carriers, but can alternatively be provided by means of
V.35 links connected to an external multiplexer. Within the USP, the physical interface is
terminated on a CCS7 link system node in the USP CAM shelf. In ISN07, support for
signalling links over these different types of connection is as follows:
! An E1 carrier can be configured to support up to 8 channelised CCS7 links, each
using a dedicated timeslot; the other timeslots are unused.
! A V.35 interface can support up to four CCS7 links.
! An E1 carrier can be configured as an unchannelised 2Mb/s High Speed Link (HSL)
compliant with Q.703 Annex A.
The USP can terminate an overall maximum of 328 CCS7 signalling links.

Intra-CS2000 Signalling via CS LAN

The USP distributes incoming CCS7 signalling to the CS2000 Core and directly to GWCs
via the CS LAN. For this purpose, CCS7 user part messages are conveyed over an M3UA
/ SCTP / IP protocol stack. M3UA (MTP Layer 3 User Adaptation) is an IETF protocol
for communication between distributed system components that share the same CCS7
point code. Outgoing CCS7 user part messages sent by the Core over M3UA / SCTP / IP
are encapsulated by the USP in standard MTP MSUs (Message Signalling Units) for
routing over the CCS7 signalling network.
A single CS2000 using a USP can have 31 point codes.
Each entity to which a USP distributes traffic is provisioned at the USP as an Application
Server (AS). Typically, an AS comprises two Application Server Processes (ASP), one
primary and one secondary, of which only one is active at a given moment. Up to four
logical paths can be provisioned from a USP to each ASP. For a CS2000 running ISN07,
the CS2000 Core is provisioned as one AS, and each GWC is also provisioned as an AS.
In terms of MTP functionality, MTP routing means the distribution of messages from a
USP to an AS with a different CCS7 point code, while MTP distribution means the
distribution of messages to an AS with the same CCS7 point code.
In theory, one USP could support several CS2000s, but this is not supported in ISN07.
The CS LAN interface used for communication with the Core and with GWCs is provided
by a 10/100BaseT Ethernet LAN port on a USP IP system node.
NCAS (Non Call Associated Signalling) over the Packet Network

The USP also supports NCAS (Non Call Associated Signalling) with remote CS2000s
(strictly speaking, with USPs belonging to remote CS2000s) via the backbone packet
network. The protocol stack used for this purpose is TCAP / SCCP / MTP3 / M2PA /
SCTP / IP, where M2PA (MTP2-User Peer-to-Peer Adaptation) is an IETF protocol for
communication over a packet network between systems with different CCS7 point codes.
In ISN07, USP support for mapping CCS7 links to an external SCTP connection is subject
to the restriction that each logical CCS7 link (or SCTP connection) must map to an
individual 100baseT Ethernet connection. Support for NCAS between a network of N
CS2000s (each with one USP) therefore requires each USP to support N-1 100BaseT
Ethernet interfaces dedicated to this purpose, one for each other CS2000/USP. A network
of four CS2000s, for example, would require a mesh of six dedicated NCAS links, adding
a fifth CS2000 would require four additional links, and so on.
Note: The USP could also support ISUP or TUP signalling between CS2000s over MTP3
/ M2PA / SCTP / IP, but this capability is not used by the CS2000 international product.
Inter-CS signalling via ISUP and TUP is instead supported by DPT GWCs using SIP-T
encapsulation of CCS7 user part messages, as described in section B1.4.5.3 on page 62.

B1.6.1.2 USP Hardware

A USP main shelf is a CAM (Communication Application Module) shelf with 18 front
and 18 rear slots. The combination of a mission card in a front slot with a TM (Transition
Module) card in the corresponding rear slot makes up a USP system node. The following
system nodes are supported:
! Twin CAM Controller (CC) system nodes.
! Twin Real-Time Controllers (RTCs). Each RTC consists of a compute engine card
with an integral disk drive. The two RTCs communicate by means of a SCSI cable
terminated on their TMs. The TM for the RTC compute engine also has an Ethernet
port for system control and OAM&P.
Note: Compute engine card with integral disk drive introduced in ISN07 as
replacement for card with separate single-slot SCSI hard drive card.
! IP system node, equipped with an Ethernet TM for communication with the CS2000
Core and with GWCs via the CS LAN. There must be two or four IP system nodes
in a USP shelf. These operate in active/active load-sharing mode and are
redundantly connected to the PP8600 routers. Each IP system node can terminate
up to 16 M3UA paths.
! CCS7 link system node, equipped either with an E1 TM or with a V.35 TM. In
ISN07, support for signalling links over these different types of connection is as
follows:
" An E1 carrier can be configured to support up to 8 channelised CCS7 links,
each using a dedicated timeslot; the other timeslots are unused.
" A V.35 interface can support up to four CCS7 links.
" An E1 carrier can be configured as an unchannelised 2Mb/s High Speed Link
(HSL) compliant with Q.703 Annex A.
The maximum number of slots available for CCS7 link system nodes in a USP main
shelf is 10, which means that the maximum signalling link capacity of the shelf is
80.
If required, one or more USP extension shelves can be used to increase capacity. Each
USP extension shelf provides 18 additional slots for CC system nodes, IP system nodes
and CCS7 link system nodes. There are no RTC cards in an extension shelf, as the RTC
cards in the main shelf provide RTC capabilities for extension shelves as well. Each
extension shelf can support up to 128 CCS7 signalling links.
The USP uses ATM switching as its internal transport system. The shelf backplane has
fully duplicated ATM paths for reliability, ensuring that no single failure results in
message loss. The USP is based on commercial processors using a fault-tolerant,
high-capacity, distributed processing architecture to deliver SS7 functionality. The CAM
shelf, mission cards, TMs and backplane mechanics comply with VME (Versa Module
Europe) industry hardware standards.

B1.6.1.3 USP Hardware Packaging

The recommended housing for USP shelves is the Nortel standard Packet Telephony
Equipment (PTE2000) frame, as used to house CS2000-Compact components
(NTTD35AA). The Nortel NTST34AA 19" relay rack can be used as an alternative.
A CS2000 supporting the maximum of 328 CCS7 signalling links by means of the USP
requires one USP main shelf and three USP extension shelves. These are housed in two
adjoining frames, with two USP shelves in each frame. The space above the USP shelves
in the frame housing the USP main shelf is used to house the following ancillary USP
equipment:
! Twin ICCMs (Inter-CC Modules) supporting communication between shelf CCs
! BALUN (Balanced / Unbalanced) line and impedance converter for European
markets requiring coax cable termination, enabling E1s to be transported over coax
This example USP configuration is illustrated in Figure 15.
USP ancillary equipment:

ICCMs
BALUN converter
USP USP
main extension
shelf shelf
USP USP
extension extension
shelf shelf
Figure 15: USP hardware packaging

B1.6.1.4 USP Compact

A Compact version of the USP is available for use in CS2000-Compact configurations as
an alternative to the full-scale USP. A USP-Compact consists of a pair of USP-Compact
cards, one housed in each SAM21 Call Agent shelf in a CS2000-Compact Call Control
Frame.
Each USP-Compact card provides the following types of input/output port:
! An E1 carrier port for external CCS7 signalling links
! A 100BaseT Ethernet port for communication across the CS LAN
! A timing input port
! A serial dialogue port
An E1 carrier terminated on a USP can support either four or eight CCS7 signalling links
on dedicated timeslots. The maximum capacity of a USP-Compact is therefore 16
signalling links (two cards terminating one E1 carrier each).
Figure 16 illustrates the protocol stacks supported by the USP-Compact.
External signalling over Intra-CS2000 signalling

CCS7 signalling network over CS LAN
TCAP TCAP
ISUP TUP ISUP TUP
SCCP SCCP
MTP3 M3UA
MTP2 SCTP
MTP1 IP
Figure 16: Signalling supported by the USP-Compact
A USP-Compact cannot support the following USP capabilities:

! CCS7 signalling links over V.35
! Non Call Associated Signalling (NCAS) across the backbone packet network.
The following list summarises how SAM21 shelf slots are allocated for the Call Agent
shelves in a CS2000-Compact configuration that incorporates a USP-Compact:
! One slot for Call Agent card (3PC processor)
! One slot for STORM (Storage Manager) NFS card with optical links to persistent
data storage
! Two slots for a pair of Shelf Controller cards (in slots 7 and 9)
! One slot for a USP Compact card (in slot 21)
! Remaining slots for up to 7 pairs of Gateway Controller (GWC) cards

B1.6.2 FLPP Signalling Peripheral

Use of the FLPP to support CCS7 signalling is standard in existing TDM switches, and it
is expected that these FLPPs will be continue to be used when the switches are upgraded
to Succession. The FLPP is not connected to the CS LAN, and uses the MS for
intra-CS2000 communication with the Core, as illustrated in Figure 4 on page 31. It is
available only in standard CS2000 configurations based on XA-Core.
B1.6.2.1 FLPP Functions

The Fiberised Link Peripheral Processor (FLPP) provides a platform for terminating
TDM-side CCS7 signalling links. For incoming signalling, it extracts the contents of
MSUs (MTP Signalling Units) so that they can be appropriately handled by the CS2000
Core and GWCs, e.g. extracting ISUP or TUP messages for translations and routing. For
outgoing signalling, it accepts CCS7 user part messages from the Core, inserts these into
MSUs, and sends the MSUs to the CCS7 network.
Note: The FLPP is not involved in any way in the handling of call control signalling for
PRI, QSIG or lines.
The FLPP supports circuit-oriented CCS7 signalling terminations for ETSI ISUP, IBN7
(ANSI ISUP+), national ISUP and national TUP interfaces. The term circuit-oriented
means that there is a traffic circuit (a bearer channel conveying voice or data) associated
with a given signalling link, and that the messages conveyed over a signalling link relate
to a particular traffic circuit, e.g. they control call establishment and clearing over a
particular traffic circuit. In the CS2000 network architecture, such CCS7 traffic circuits
are handled by media gateways, and GWC-gateway signalling (e.g. ASPEN) is used to
co-ordinate call control signalling at the CS2000 with the handling of the traffic circuit by
the media gateway.
The FLPP also supports circuit-independent CCS7 signalling terminations for TCAP
interfaces. The term circuit-independent means that there is no traffic circuit associated
with a given signalling link. Such signalling links enable peer entities on different nodes
to exchange information and instructions. The operations and parameters used for this
purpose may be defined to support a particular service or defined as elements of a
general-purpose service support platform such as the Intelligent Network Application Part
(INAP).
B1.6.2.2 FLPP Hardware
The FLPP Cabinet

An FLPP cabinet houses two types of hardware unit:
! Up to three Link Interface Shelves (LISs), each providing 12 slots for housing
Interface Units (IUs). IUs are the circuit packs supporting the various applications
on the LPP, and are therefore also referred to as Application-Specific Units (ASUs).
! A Link Interface Module (LIM), comprising two Local Message Switches (LMSs)
operating in load-sharing mode and two F-Buses connecting the IUs/ASUs in the
LISs. These LMSs support direct high-speed communication between IUs.
The LIM also supports SR128 subrate optical fibre links with the CS2000 MS for
conveying signalling messages to/from XA-Core.

LIS and LIM units are housed in C42 cabinets as illustrated in figure 17. A CS2000
configuration can include up to six LPP cabinets.
LMS functions:
Link Interface Module To terminate SR128 links
to/from the MS (CS2000 bus).
LPP LMS 0 LPP LMS 1 To support communication
between IUs/ASUs
Link Interface Shelf 1
LISs provide
Link Interface Shelf 2 slots for
IUs/ASUs,
e.g. LIU7s
Link Interface Shelf 3
Figure 17: LPP cabinet configuration
LIU7s Terminating CCS7 Signalling

Each CCS7 signalling channel terminates on an LIU7 (Link Interface Unit for CCS7) in
an LPP. The interface between the LIU7 and the external multiplexer is V.35, controlled
by a 9X77 paddleboard in the LPP. The configuration is shown in Figure 18.
CS2000
V.35
Link
Peripheral Link External
Processor Interface mux
MS
(FLPP) Unit (LIU7)

64 Kb/s links conveying CCS7 signalling
Figure 18: LPP support for CCS7 terminations using an external multiplexer
Figure 18 provides a more detailed view of an individual LIU7, showing its components
and the interaction between them.
Link Interface Unit for CCS7 (LIU7)

EX22 9X76 9X77
Integrated ASU Processor
and F-Bus Interface (IPF) Signalling Terminal CCS7
(ST) supporting Interface
ASU processor Processor Layer 2 datalink paddleboard
bus functions for one
CCS7 link
F-Bus Interface
To/from External
F-Bus CCS7 link
Figure 19: Components of an LIU7

All 12 slots on each FLPP shelf are available for LIU7s terminating external CCS7
signalling links, which means that one FLPP cabinet can support a maximum of 36
signalling links. A CS2000 can support up to 180 CCS7 signalling links (slightly fewer if
some LIU7s are used as external routers, as described in the following section).
External Routers (LIU7s Dedicated to MTP Routing)

An external router is an FLPP LIU7 dedicated to supporting MTP routing functionality.
Use of external routers makes it possible to increase the number of TDM-side CCS7
trunks supported by a CS2000 from 58,000 to 90,000 (using LIU7s with 8 Mbytes of
memory) or 200,000 (using 32-Mbyte LIU7s).
External routing is supported by means of a routing database that maps MTP DPCs
(Destination Point Codes) on to Signalling Link Selection (SLS) values used to select
specific CCS7 signalling links. When such a database is set up on an LIU7 external router,
CS2000 Core call processing needs only to select that router when setting up a TDM-side
CCS7 call; it does not need to select a particular signalling link.
A CS2000 that uses external routers requires at least two additional LIU7s for this purpose
to provide redundancy, and can use up to eight. The minimum provisioning requirement
of two routers is based on 90,000 BHCA per router, with 40% engineered capacity.
Figure 20 illustrates the use of external routers to select CCS7 signalling links.
Message Switch (CS2000 bus)

CS2000
FLPP
XA-Core
(CS2000 central LMS
processing engine)
LIU7s used as
external routers
F-Bus
CCS7
LIU7s terminating network
CCS7 signalling
Figure 20: Use of LIU7 external routers to select CCS7 signalling links

B1.7 OAM&P Hardware

OAM&P functionality for CS2000 is provided by a range of Element Managers (EMs),
each designed to control a particular type of Network Element (NE), and management
applications, each designed to deliver particular functionality for one or multiple NEs. It
is not the purpose of this section to describe EMs and management applications and the
functionality they provide; this information is provided in Chapter H1: Overview of
OAM&P for CS2000 Solutions. The aim of this section is to provide an overview of
hardware-related aspects of OAM&P support. This is done under the following headings:
! Trusted access to NEs via the OAM&P VLAN of the CS LAN (see section B1.7.1)
! Access to the OAM&P VLAN from outside the CS2000 CS LAN (see section
B1.7.2 on page 83)
! Hardware platforms used for EMs and management applications (see section B1.7.3
on page 84
! Integrated access to EMs and management applications (see section B1.7.4 on page
86)
! Optional use of DMS hardware for OAM&P functions (see section B1.7.5 on page
87)
B1.7.1 Trusted Access to NEs via the OAM&P VLAN of the CS LAN
The OAM&P VLAN of the CS LAN interconnects the EMS (Element Management
System) servers supporting the EMs (Element Managers) for functional network
elements. These EMs are the only entities that are permitted to access the functional
CS2000 NEs on the signalling VLANs. The EMS servers belonging to the OAM&P
VLANperform a dual role:
! They have trusted access to the CS2000 network elements on the signalling VLAN,
for which purpose they can use the private IP address space of the signalling VLAN.
! They support controlled access from external entities.
The EMS servers on the OAM&P VLAN can be accessed by:
! Appropriately authenticated entities on the NOC LAN, e.g. NOC desktop clients
and Higher Level Management (HML) application servers.
! Appropriately filtered and authenticated external users in Operating Company
intranets, e.g. from the OSS LAN.
Other users in the NOC LAN and Operating Company intranets can access CS2000
network elements only via the EMS interfaces. They have no direct IP route to the CS2000
network elements. No extension of the OAM&P VLAN to other servers or services is
permitted, as this would compromise the security of the CS2000 network elements.
Figure 21 on page 82 illustrates the network architecture.

Nortel
OSS LAN / OC corporate internet Remote
(centralised OAM&P applications) Access
HLM PC clients for EMs and

applications management applications Contivity 600
secure gateway
Enterprise Secure
servers tunneling
NOC LAN
RA to OAM&P VLAN
Untrusted indirect
access to NEs via EMs
RA to CS2000
Element Managers
(trusted access to Network Elements)
Firewall /
perimeter IEMS /
network CBM Other
CMT EMs/apps
PP8600
CS2000
Sun server Sun server Sun server DM CS LAN
EMS servers
CS LAN (OAM&P VLAN)
EM
functionality
for 3rd-party
media Telco SAM21 SS USP
router CS2000 (inc.
gateways Core CICM (inc. MS2010
SC GWC inc. EM EM) EM)
CS LAN can comprise

multiple signalling
VLANs, as illustrated CS LAN (signalling VLANs)
in Figure 8 on page 44;
this diagram simplifies
the network structure (not needed for VoATM)
in order to focus on
OAM&P access PP8600 CS LAN (bearer VLAN)
routers
PVG
Packet backbone network gateways
Line
gateways
Figure 21: Physical OAM&P architecture

B1.7.2 Access to the OAM&P VLAN from outside the CS2000 CS LAN
B1.7.2.1 The NOC (Network Operations Centre) LAN

Network elements and their EMs are managed either from client desktops or indirectly via
higher level management application servers. Depending on the network architecture,
these clients and applications may reside either on a dedicated Network Operations Centre
(NOC) LAN, or elsewhere in the operating companys intranet. The key point is that they
do not reside in the CS LAN. In a given CS2000 network, a higher-level management
application may be responsible for one or more CS2000s.
These entities are regarded as untrusted and may only access management functionality
via the EMS servers on the OAM&P VLAN, which implement user authentication to
control access. Once appropriately authenticated, the clients and higher level management
applications are able to access various OAM&P functions to control CS2000 NEs.
To ensure security for operating company access to the Network Operations Centre
(NOC) LAN, a perimeter network or firewall must be configured between the NOC LAN
entities and other operating company sites.
B1.7.2.2 The Operating Company Intranet and OSS LAN

Access to functional elements and EMs is required by various external entities within the
operating companys main corporate intranet. This includes desktop client applications
outside the NOC LAN, and OSSs that typically reside on an OSS LAN. Such applications
may be centralised and communicate with one or more signaling VLANs.
Because of the external nature of these LANs, these external entities are regarded as
completely untrusted. Security needs to be provided by deploying a perimeter network or
firewall between the CS2000 NOC LAN entities and the operating companys intranet
and OSS LANs. The way in which this perimeter network is implemented is outside the
scope of this CS2000 Product Description. Once appropriately authenticated, these higher
level applications/clients are able to access various OAM&P functions on the EMSs to
control CS2000 NEs.
B1.7.2.3 Emergency and Remote Access

Secure Remote Access (RA) to CS2000 is required for Nortel GlobalCustomer Care staff
who are responsible for patching, emergency support and problem solving. RA is
supported by the Contivity 600 secure gateway, using a high-bandwidth TCP/IP link via
the external Internet. This provides secure Telnet access to both the Operations LAN and
the CO LAN by using VPN tunnelling and Telnet proxy. The EMS and NE platforms
support Telnet access secured either by standard UID and Password or by use of SSH.
EMS servers may also support Telnet proxy for access to NE platforms from the
Operations LAN and operating company intranet.

B1.7.3 Hardware Platforms used for EMs and Management Applications

B1.7.3.1 OAM&P Packaging and Integration
CS2000 EMS OAM&P functionality can be divided into the following categories:
! Core Manager capabilities provided by the CS2000 Manager running on the Call
and Billing Manager (CBM) server or SuperNode Data Manager (SDM) platform.
! Non-Core management capabilities provided by Non-CM Loads (NCLs) hosted by
the CMT (CS2000 Management Tools) server. Of these, the most important are:
" The CS2M (CS2000 Management) NCL comprising EMs and management
applications for most CS2000 components.
" The Integrated Element Management System (IEMS) NCL, which provides a
single integrated desktop environment for access to all CS2000 EMs and
management applications.
! Capabilities provided by non-CMT-resident EMs
Note: The software that supports these capabilities is not integrated in a
CMT-resident NCL, e.g. it may be hosted by an NE or embedded in an NE load, but
integrated access to it is supported via IEMS.
For details of the specific EMs and management applications supported on these hardware
platforms, see section H1.2.3 on page 777.
Figure 22 illustrates how the IEMS provides integrated access to OAM&P capabilities
hosted on different platforms.
Clients for
EMs and HLM applications
management on enterprise
applications servers
NOC LAN
IEMS provides one OAM&P VLAN

externally visible
IP address for
access to all EMs
IEMS
Non-CMT-resident EMs,
e.g. for Session Server,
USP, CICM EM
EMs and mgmt
apps, e.g. GWC
Core Manager EM, SAM21 EM,
applications configuration apps
CBM server or SDM CMT server Non-CMT-resident EMs

(e.g. NE-hosted or embedded)
Figure 22: Integrated access to OAM&P capabilities via IEMS

B1.7.3.2 Hardware Characteristics
Netra 240 Server (as used for CBM and CMT)

With effect from ISN07, the Sun Netra 240 is the recommended standard hardware
platform for CS2000 OAM&P functionality, including:
! CBM (Core and Billing Manager)
! CMT (CS2000 Management Tools), including most EMs
! The IEMS described in section B1.7.4 on page 86
Hardware characteristics:
! Up to two 1.28-GHz UltraSPARC IIIi processors
! Up to 8 Gbytes of main memory (DDR-1 SDRAM 128-bit plus ECC)
! Four 10/100/1000 BaseT Ethernet ports
! Expansion bus with three 64-bit expansion slots (one full-length, two half-length)
! Up to two 3.5" x 1.0" 72-Gbyte Ultra160 SCSI hot-swappable drives
! Operating system: Solaris 8 HW 7/03
! Telecom environment certification: NEBS Level 3
Motorola PowerPC Series FX (as used for SDM)

The SDM hardware is a Motorola PowerPC Series FX system running AIX (the IBM
version of UNIX). The SDM is co-located with the CS2000. In a CS2000-Compact
configuration, it communicates with the Core via the OAM&P VLAN of the CS LAN. In
a standard XA-Core configuration, it uses the OAM&P VLAN to support BOOTP/TFTP
services for other CS2000 components; for communication with XA-Core, it has a
dedicated DS-512 interface with the Message Switch (MS).
The SDM is a high-performance, fault-tolerant computing platform with redundant I/O
buses, mirrored disk storage, and redundant communications ports. The SDM also has
fault-isolating software that guarantees a fault-tolerant architecture. The redundant
hardware components are run in full synchronisation, with one unit as master and the
other running in hot standby mode. There is no loss of service during a switch of activity.
The SDM is designed to prevent any loss of instructions or data during a switch between
master and standby components.
The SDM occupies one shelf in a C28 cabinet.
An SDM comprises dual control processors plus various different types of MFIO
(Multi-Function Input/Output) module, as follows:
! Dual PowerPC Arthur 400MHz CPUs with 512 Mbytes of memory each
! Four MFIOs for 100BaseT Ethernet links
! Two MFIOs for DS-512 links (not applicable for CS2000-Compact)
! Two MFIO dual-disk modules, each supporting two 36-Gbyte disk drives
! Two MFIO tape/disk modules, each supporting a 36-Gbyte disk drive plus a DAT
(Digital Audio Tape) drive

B1.7.4 Integrated Access to EMs and Management Applications

With effect from ISN07, Nortel provides the Integrated Element Management System
(IEMS) to integrate and correlate OAM&P functionality. This has two main purposes:
! It aggregates northbound data streams from individual EMs and management
applications, e.g. for fault reporting and performance measurements, and presents
these to OSS applications using standard formats and interfaces.
! It provides a single access point for browsing the topology of CS2000
configurations and for launching EMs and management applications.
IEMS runs on the same Sun Netra 240 server as CMT. It provides a tree-like expandable
Integrated EMS Topology menu to represent and support drill-down access to:
! Network Elements
" CS2000 Core (XA-Core or Compact)
" STORM
" PP8600
" GWC
" SAM21
" CICM
" Session Server
" USP
" MS2000 or UAS
" PVG
" MG9000
" MCS5200
" RTP Media Portal
! Element Managers
" CS2000 Core Manager
" GWC Manager
" SAM21 Manager
" CICM Manager
" USP Manager
" UAS Manager
" APS Manager
" MCS System Manager
" Preside MDM
! EMS Platforms such as
" SDM
" SSPFS
" MDM
" CICM Manager platform
" MCS Manager platform
! EMS Applications such as
" OSSGate (single access point for provisioning applications)
" TMM (Trunk Maintenance Manager)
" LMM (Line Maintenance Manager)
" LTM (Line Test Manager)
" APS
" QCA (QoS Collector Application)
" NPM (Network Patch Manager)

B1.7.5 Optional Use of DMS Hardware for OAM&P Functions
B1.7.5.1 ISM (Integrated Services Module)

The Integrated Service Module (ISM) is a specialised module designed to accommodate
test and service circuit packs used in switch and facility maintenance.
In a standard CS2000 configuration based on XA-Core, the ISM is used to house IOMs
(Input/Output Modules). These provide ports for serial input and output, enabling local
and remote devices to communicate with the rest of the CS2000 via the CS2000 Message
Switch. CS2000 IOMs support the datalinks used to bring the SDM platform (for the Core
Manager) and the CS2000 into service.
An ISM cabinet has four shelves. In a CS2000 configuration, two of these shelves are ISM
shelves that provide slots to house IOMs. Each shelf has 18 slots available. The other two
shelves are left empty unless the CS2000 configuration includes the optional OAU, in
which case they are used as follows:
! One shelf is used for the Office Alarms Unit (OAU)
! One shelf is used for the Alarms Cross-Connect Unit (AXU)
B1.7.5.2 IOM (Input-Output Module)

Each single-slot IOM FX30 Communications Card (CC) housed in an ISM can support
up to 16 ports for:
! 64 Kb/s synchronous V.35 links, e.g. for billing data
! 28.8 Kb/s asynchronous RS232 links, e.g. for on-site terminals / modems / printers
X.25 data communications, as used for applications such as file transfer and terminal
access, can be supported over either V.35 or RS232.
The physical interface between the IOM CC and the external connector for a device is the
same for each type of link, a 4-wire DS-30 cable. Within the IOM CC, the different types
of link are distinguished by means of an on-board Enhanced Multi-Protocol Connector
(EMPC). At the device end of the cable is a smart connector that performs the necessary
mapping between the standard 4-wire interface and the external interface, as summarised
in Figure 23. Connection of a different device requires only a new external cable, not
hardware changes within the CS2000.
4-wire
standard sockets
DS-30 Local/
Bulkhead with
IOM cable Smart remote

Port connector device
4-wire
DS-30
EMPC Port cables
DS-30 link to MS (CS2000 bus)
Figure 23: IOM support for serial input/output
The IOM CC can also support two SCSI ports, which are used for connections to a
two-slot Storage Media Card (SMC) supporting a 1-Gbyte DDU and a 1.3-Gbyte DAT.
The DDU can be used to store billing data, backup images and software loads.

B1.7.5.3 Office Alarms Unit (OAU)

The Office Alarms Unit (OAU) is an optional component, and is available for use only in
standard CS2000 configurations based on XA-Core. It can be used to connect a CS2000
with the office alarm system to provide notification of physical or electrical problems. It
comprises two main types of functional element:
! Scan points and monitoring devices for collecting environmental input (e.g.
temperature levels) and detecting state changes in peripheral equipment.
! Output devices such as Signal Distribution Points (SDPs), to provide collected
information for inclusion in logs and displays and to activate audible alarms (e.g.
bells or sirens) when required.
The wiring required for connections between the OAU and the alarm system is provided
by the Alarm Cross-Connect Unit (AXU). Both the OAU and the AXU are single-shelf
peripherals that are housed in an ISM (Integrated Service Module) cabinet.
The OAU is directly connected to the Enhanced Network (ENET), which is in turn
connected to the MS to support communication between the OAU and XA-Core.
See Figure 4 on page 31 for a functional view of the interaction between hardware
components in a CS2000 standard configuration that includes the OAU.

B1.8 CS2000 Interworking with Legacy Peripherals

In a hybrid configuration, the Core can use the ISN07 PCL to support circuit-based and
packet-based capabilities simultaneously. Support for hybrid configurations eases the
transition from a circuit-based network architecture to a packet-based architecture,
enabling network operators to maintain continuity for existing services while moving to
a next-generation platform that can support an even more extensive service portfolio.
For DMS hardware supporting circuit-based connectivity, trunk and line peripherals
terminate bearer channels as well as call control signalling, while bearer channels are
cross-connected internally via ENET. For CS2000 hardware supporting packet-based
connectivity, bearer channels are terminated on external media gateways and
cross-connected via the backbone packet network. Links between the circuit and packet
environments can be provided in either of two ways:
! Via circuit-based trunk connections between a legacy trunk peripheral and the TDM
side of a PVG trunk gateway, as decribed in section B1.8.1.
! Via packet network connections between the CS2000 Interworking SPM (IW-SPM)
and the packet side of a media gateway, as described in section B1.8.2 on page 90.
B1.8.1 Hybrid Configurations using Looparound Trunks

Call interworking between the circuit and packet environments, i.e. interworking of
bearer paths and signalling, can be supported by means of looparound trunks. As far as
call processing software in the Core is concerned, an outgoing call made via a
looparound trunk is handled exactly as if the looparound trunk provided a connection to
a remote node. Similarly, an incoming call over a looparound trunk is handled as if it was
a call from a remote node. The network configuration is illustrated in Figure 24.
PVG
Legacy Legacy trunks TDM side
trunk of PVG
IOM OAU ENET peripherals
in ISM Looparound trunks connecting
legacy peripherals with TDM Packet
side of PVG trunk gateway side of
MS MS PVG
Legacy
Lines
line
FLPP SDM peripherals Packet
backbone
network
Dual PP8600s
CS2000 OAM&P
CS LAN servers
CS2000 Core
Session
MS2000 CICM
Trunk CICM AC H.323 Line RMGC DPT Server
Figure 24: Hybrid configuration interworking via looparound trunks

B1.8.2 Hybrid Configurations using the IW-SPM
B1.8.2.1 IW-SPM Support for Interworking

The Spectrum Peripheral Module (SPM) is an advanced legacy trunk peripheral designed
to support high-capacity applications by providing terminations for optical carriers rather
than the copper carriers terminated by legacy DTCs. The Interworking SPM (IW-SPM) is
a version of the SPM with carrier connections that are used to support high-capacity links
for packet-based media streams rather than circuit-based trunks.
The primary purpose of the SPM is to terminate external links to/from other packet
network hosts, and to map media streams to/from these hosts on to channels provided by
internal DS-512 optical fibre links to the ENET switching matrix. Physically, the
IW-SPM is connected to the CS2000 CS LAN, and communicates with external packet
network hosts such as PVGs via the CS LANs PP8600 routers. In effect, the IW-SPM is
a media gateway that is internal to a CS2000 hybrid configuration, performing
circuit/packet conversion between conventional 64Kb/s circuit connections on one side
and streams of packetised voice on the other. Use of the IW-SPM eliminates the need to
use looparound trunks in hybrid configurations and thus conserves the use of TDM-side
ports on DTCs and PVGs.
The IW-SPM is connected to the PP8600 routers of the CS LAN via Gigabit Ethernet.
Figure 25 illustrates the network configuration used to support CS2000 interworking with
legacy peripherals via the IW-SPM.
Legacy Legacy
trunk trunks PVG
peripherals
IOM OAU ENET
in ISM TDM
side of
Legacy Legacy PVG
MS MS line lines Packet
peripherals side of
PVG
FLPP SDM
IW-SPM
Interworking SPM (IW-SPM) Packet

connected both to legacy backbone
peripherals (via ENET) and to
media gateways (via CS LAN network
and packet backbone network)
Dual PP8600s
OAM&P CS2000
servers CS LAN
CS2000 Core
Session
MS2000 CICM
Trunk CICM AC H.323 Line RMGC DPT Server
Figure 25: Hybrid configuration interworking via the IW-SPM

B1.8.2.2 Interworking Spectrum Peripheral Module (IW-SPM) Hardware
IW-SPM Functional Elements

The relationship between IW-SPM functional elements is illustrated in Figure 26.
IW-SPM
DS-512 Common Gigabit

fibre link Equipment Ethernet
to ENET Module Module
switching (CEM) (GEM)
matrix GigE packet-side
interface with CS
Four DS-512 CEM GEM terminates LAN PP8600s
Circuit-based links duplicated physical interface
interface with (one active link,
(2048 64 Kb/s for reliability and provides all one for protection
ENET channels) DSP functionality switching)
DS-512 Common Gigabit
fibre link Equipment Ethernet
to ENET Module Module
switching (CEM) (GEM)
matrix
Internal serial links provide connections

between IW-SPM components
Figure 26: IW-SPM logical architecture
The IW-SPM comprises the following functional elements:

! Circuit-side interface
Four Resource Modules (RMs) terminating DS-512 optical fibre links to/from the
ENET switching matrix, supporting a total of 2,048 64 Kb/s channels.
! Packet-side interface
A pair of Gigabit Ethernet Modules (GEMs), one active and one for protection
switching. Each GEM is an RM that not only provides a physical termination for a
GigE interface but also provides all DSP functionality.
! Controller cards
A duplicated pair of Common Equipment Module (CEM) cards, each equipped with
a PowerPC processor.
! Internal serial links between IW-SPM components.

IW-SPM Capacity
On the packet-side, an IW-SPM supports one active GigE link that operates in the range
of 400 Mb/s, plus a second GigE link for protection switching. These GigE links are
connected to the PP8600 routers of the CS2000 CS LAN, and via them to the backbone
packet network.
On the circuit side, an IW-SPM can supported up to 2,048 64Kb/s user channels provided
by four DS-512 link with ENETs.
There is no concentration at the IW-SPM. Media streams to/from other packet network
hosts are mapped 1:1 on to 64Kb/s user channels.
Note: Although technically feasible, use of the SPM as a trunk traffic peripheral in a
CS2000 SNSE configuration is not recommended. This is primarily because it allows
trunk capacity to be increased only in 2,000-trunk steps, which is not an appropriate level
of granularity for increasing the trunk capacity of small switches.
IW-SPM Hardware Packaging

The IW-SPM is a double-height
shelf unit (in effect a twin-shelf IW-SPM
frame
unit), and is housed in a customised housing two
four-shelf system frame as shown double-height
in Figure 27. (twin-shelf)
IW-SPM units
Two IW-SPM units can be housed
in a given frame.
The dimensions of IW-SPM IW-SPM #1
hardware are smaller than those of
the equivalent legacy peripherals,
but to minimise costs adapter
brackets are used to house SPMs
within standard Nortel C28 frames.
The IW-SPM has been designed to
be entirely front-loading for ease of
maintenance, i.e. all IW-SPM card
slots are accessible from the front
of the frame. The backplane of the
double-height shelf provides 30 IW-SPM #2
card slots that are allocated as
follows:
! Two slots for Common
Equipment Modules
! Two slots for Shelf Interface
Modules (for power and
alarms)
! Remaining 26 slots available
for Resource Modules Figure 27: IW-SPM hardare packaging
An SPM system frame is always configured with two units, even if only one is to be used
initially. This makes it possible to accommodate subsequent system expansion merely by
adding circuit packs and cabling.

B1.9 Hardware Packaging

Two different types of CS2000 configuration are supported in ISN07:
! Standard CS2000 configuration based on XA-Core
! CS2000-Compact configuration based on 3PC Call Agent
Both types of configuration support the same range of call processing agents, protocols
and telephony features. The main differences between them are that the CS2000-Compact
uses a different processor complex, has a significantly smaller system footprint, and
delivers reduced call processing capacity. The Compact configuration is designed to
support small applications, where minimising initial capital costs and system footprint is
more important than switching capacity.
B1.9.1 CS2000 Cabinets

CS2000 components are housed in cabinets with the following dimensions:
! C42 equipment cabinet (referred to as LX01AA for XA-Core)
Dimensions: 107 cm wide x 183 cm high x 71 cm deep (42 x 72 x 28)
Used to house: XA-Core
MS
FLPP
ENET
! C28 equipment cabinet
Used to house: SDM
ISM / IOM
! PTE2000 equipment cabinet (NTTD35AA)
Used to house: SAM21 shelves with GWCs (also 3PC Call Agent, NFS and
media server for CS2000-Compact)
USP
PP8600 routing switch in 8010 chassis (two chassis per cabinet)
Sun Netra servers for EMs and OAM&P applications
Note: In a CS2000-Compact configuration, the main PTE2000
cabinet can house media servers as well as two SAM21 shelves.
A second PTE2000 frame is required to house the EMs for
CS2000-Compact components.
! Telco-standard NEBS3-compliant 19" frame (NTST34AA)
Possible alternative to PTE2000 for housing PP8600 routing switch in 8010 chassis
(two chassis per frame)
Each cabinet or frame contains equipment shelves that provide slots for the installation of
circuit packs and/or space to house specialised units that in turn contain circuit packs.
CS2000 cabinets meet industry requirements for isolated grounding and feature
connectors to facilitate testing. They provide greater physical and electrostatic discharge
(ESD) damage protection for the enclosed equipment than open frames. They are also
compliant with electromagnetic compatibility (EMC) requirements, and provide Zone 4
earthquake protection without additional bracing.

B1.9.2 Typical Cabinet Lineups

Figures 28 to 31 illustrate some example cabinet lineups that show how the main CS2000
hardware elements are packaged into cabinets in typical configurations.
MX20x0 OAM&P
media Session servers
servers Server frame
PP
213cm
8600
183cm
USP
main
PP
SAM21 shelves 8600 Depth
Depth USP
housing GWCs ext. 61cm
71cm
XA-Core
107cm 61cm 61cm 61cm 61cm 61cm 61cm
Figure 28: Example Lineup A:- XA-Core configuration with no legacy hardware
Call SAMF OAM&P

Control expansion USP servers
Frame frame frame frame
Session
Server
PP
213cm
MX20x0
media 8600
servers
USP
main
SAM21 Call Agent CA1
shelves housing: PP
3PC Call 8600 Depth
Agent card USP
ext. 61cm
(main shelf) CA0
GWCs
61cm 61cm 61cm 61cm 61cm
Figure 29: Example Lineup B:- Compact configuration with no legacy hardware

XA-Core / MS FLPP ENET

cabinet cabinet cabinet
213cm
183cm
MS 0 LMS ENET 0
MS 1 LIS 0 ENET 1
LIS 1 SAM21 shelves

Depth housing GWCs Depth
71cm 61cm
XA-Core LIS 2
107cm 107cm 107cm 61cm 61cm
SS
PP
213cm
8600
OAU MS
CMT
AXU on Sun
SDM PP
ISM
on shelves 8600 Depth
Series FX for 61cm
IOMs
71cm 71cm 61cm 61cm 61cm
Figure 30: Example Lineup C:- XA-Core configuration with selected legacy hardware
Combined
Core cabinet
SS
PP
213cm
8600
183cm
MS OAU MS
LIS CMT
AXU on Sun
SAM21s SDM PP
ENET with ISM
Depth shelves on 8600 Depth
GWCs Series FX
71cm for 61cm
XA-Core IOMs
107cm 61cm 71cm 71cm 61cm 61cm 61cm
Figure 31: Example Lineup D:- XA-Core SNSE configuration with selected legacy
hardware

Chapter B2 CS2000 Support for Media
Gateways
B2.1 Introduction
In order to perform its network role, a CS2000 must be deployed along with one or more
media gateways for handling packet network bearer connections. A media gateway
provides an interface for bearer connections, e.g. mapping a packet-based media stream
on to a circuit-based media stream, seamlessly providing any required format conversion
while maintaining content integrity. Depending on the telephony interface to be
supported, a media gateway may also provide signalling gateway functionality. A
signalling gateway terminates legacy network signalling on one side and packet network
signalling on the other, and supports interpretation and conversion between the two.
This chapter provides a brief functional overview of each type of gateway that can be
deployed with an ISN07 CS2000. First, section B2.2 discusses how to categorise and
assess the capabilities of different types of gateway; the remaining sections of this chapter
then deal with specific gateway types. For ISN07, the gateway types supported [1] are:
! PVG (Packet Voice Gateway) trunk gateways, which can support both VoIP and
VoATM. The Passport PP7480, PP15000 and PP20000 PVGs supported in ISN07
are described in section B2.3 on page 99.
! PVGs configured to support V5.2 access to IP networks for analogue subscriber
lines, as described in section B2.4 on page 111.
! CPE gateways and 3rd-party units controlled by CS2000 H.323 proxy GWC via
H.323 / H.225 / H.245. See section B2.5 on page 115.
! Audiocodes Mediant 2000 gateways supporting PRI or CCS7. See section B2.6 on
page 116.
! Westell DPNSS gateways. See section B2.7 on page 118.
[1] Gateways are independent units with their own release schedules. The range of supported gateways may
therefore change within the lifecycle of a given CS2000 release.

CS2000 Support for Media Gateways Hardware Communication Server Capabilities
! High-capacity line media gateways, typically located on operating company

premises. In ISN07, CS2000 supports the MG9000 as a high-capacity media
gateway for analogue lines and ADSL (Asymmetrical Digital Subscriber Line)
access. The MG9000 is described in section B2.8 on page 119.
! Line media gateways located on customer premises and connected to an Ethernet
LAN. A number of different customer LAN gateway types are available to support
VoIP for analogue subscriber lines. As the main characteristics of these different
gateway types are essentially the same from a CS2000 perspective, they are all
listed and briefly described in one section, section B2.9 on page 123.
! MTA (Multimedia Terminal Adapter) line media gateways located on customer
premises and connected to a cable access network to support VoIP for analogue
subscriber lines. Several different MTA gateway types are available to support
VoIP for analogue subscriber lines. As the main characteristics of these different
gateway types are essentially the same from a CS2000 perspective, they are all
listed and briefly described in one section, section B2.10 on page 126.
! CVX1800 Universal Port media gateways providing TDM-side trunk terminations
to support two types of access to the packet network:
" RAS (Remote Access Service), i.e. dial-up access to internet / intranet
sessions
" VoIP voice calls
CVX1800 media gateways are described in section B2.11 on page 130.
Note: CS2000 support for RAS has been tested and verified for deployment only
in a specific customer network, and is not generally available in ISN07.
Note: Although it is not possible to describe CS2000 operation and capabilities without
also referring to the capabilities of the gateways it supports, gateways are not part of the
CS2000 product. For detailed, definitive information about the capabilities of a given
gateway type, it is necessary to refer to its product documentation. In the event of any
discrepancy between statements made in this chapter and statements made in a gateways
product documentation, the gateway product documentation should take precedence.

Communication Server Capabilities Hardware CS2000 Support for Media Gateways
B2.2 Categorising Media Gateway Capabilities
Packet network control signalling

GWC-gateway signalling path,
described in terms of:
Gateway port/termination TDM bearer channels
characteristics
Media control signalling for Packet network bearer connections
bearer connections
- H.248 (or ASPEN) for PVGs CS2000
supporting CCS7 and/or PRI
access
- H.248 for PVGs supporting
V5.2 access Gateway
- NCS for MTA line gateways Controller
- MGCP for CPE LAN line (GWC)
gateways
- DSM-CC for CVX1800 RAS
gateways
Call control signalling
(where gateway provides SG
functionality as well as MG
functionality) Packet
- N/A for CCS7 access
ne
- Q.931 or QSIG over
tw
IUA/SCTP/IP for PRI or
or
k
QSIG access
- V5-PSTN over
(ATM or IP)
V5UA/SCTP/IP for V5.2
access
- H.323 for H.323 gateways
- NCS for MTA cable lines
- MGCP for CPE LAN lines
Access network
(e.g. PSTN, ISDN, Media Far-end
V5.2 AN, analogue gateway gateway
lines)
Access network connections, described in

terms of:
Physical circuits and terminations used
to support access
Types of bearer channel to/from access
network Packet-side bearer
- 64 Kb/s bearer circuits for CCS7 connections, described
- ISDN PRI B-channels in terms of:
- V5.2 B-channels Termination
- Analogue lines characteristics
- ADSL
Signalling terminations (where gateway Packet network
provides SG functionality as well as MG backbone type (IP
functionality) or ATM)
- N/A for CCS7
- Q.921 user D-channel terminations
- LAP-V5 user C-channel terminations
- In-band DTMF for lines
Figure 32: Categorising gateway capabilities

B2.3 PVG (Packet Voice Gateway) Trunk Gateways

See section B2.4 on page 111 for information about using PVGs to support V5.2 access.
B2.3.1 Overview
A PVG consists of a gateway software load (PCR 6.1 for ISN07) running on a Passport
hardware platform to support VoIP or VoATM. The platforms supported in ISN07 are the
PP15000, PP20000 and PP7480. All three types of PVG provide essentially the same
capabilities. The main difference between them is that the PP7480 houses a smaller range
of functional elements and supports less capacity. The PP15000 and PP20000 can both
house the same range of hardware components and are functionally identical. To avoid
duplication and repetition, the remainder of this section refers only to the PP15000, but
all PP15000 references should be taken to apply equally to the PP20000.
The functional elements that can be housed in a PVG are as follows:
! Voice Service Processor (VSP) supporting TDM/packet conversion
Each VSP housed in a PVG is actually a separate gateway. A given PVG can house
multiple VSPs, each independently performing circuit/packet conversion. See the
following page for further information, and for details of the VSP types supported.
! Terminations for TDM-side carriers
TDM-side terminations can be provided in either of two ways:
" By dedicated Function Processor (FP) cards. The following types of
TDM-side FP are supported in ISN07:
# STM-1 FP with 4 ports, each supporting 63 E1 terminations (PP15000
only)
Note: The STM-1 FP can also be configured to support OC-3 with DS1
channelisation.
# E1 FP with two ports (16 E1s can be multiplexed into each port, which
means that an E1 FP can support a total of 32 E1s)
# T1 FP with two DS3 ports (28 DS1s can be multiplexed into each DS3
port, which means that a T1 FP can support a total of 56 T1s)
" By means of integrated TDM-side ports on the VSP (PP15000 only)
The VSP3-o available with effect from ISN07 provides an STM-1/OC-3 port
supporting 63 E1 terminations.
! Terminations for packet network connections
Packet network terminations can be provided in either of two ways:
" By dedicated Function Processor (FP) cards. The following types of
packet-side FP are supported in ISN07:
# 4pGE card providing 4 Gigabit Ethernet (GigE) ports for access to IP
backbone networks (PP15000 only).
# By dedicated 155Mb/s STM-1 or 622Mb/s STM-4 ATM FPs
ATM FPs support direct access to ATM backbone networks, and can
support access to IP backbone networks using AAL5 (which is added /
removed by an edge device). ATM FPs are supported by all PVG types.
" By means of integrated packet-side ports on the VSP (PP15000 only)
The VSP3 available since ISN05 provides two GigE ports (one active, one
standby) for access to IP backbone networks.

Figure 33 illustrates PVG components and their functions at a logical level.
Configuration A: Capabilities provided by separate cards

Packet network
(IP or ATM)
PVG Packet network
terminations
support both bearer
connections and
H.248 or ASPEN
control connections
VSP with GWC
TDM or access
Dedicated FP
TDM FP (Voice Service Processor) (IP or ATM)
(Function
network
supporting TDM/packet supporting

Processors) conversion STM-x ATM FPs
packet-side support ATM
supporting terminations
TDM-side directly, and
terminations support IP by
means of AAL5
Two 16-slot PVG shelves

can be housed in a cabinet 4pGE FPs provide
4 ports for direct
GigE support of IP
Configuration B: Integral GigE packet-side ports on VSP3

Packet network
(IP or ATM)
PVG Packet network
terminations
support both bearer
connections and
H.248 or ASPEN
control connections
with GWC
TDM or access
TDM FP VSP
(Function Integral
network
(Voice Service GigE

Processors) Processor) supporting Direct GigE
supporting TDM/packet conversion port support of IP
TDM-side
terminations
Configuration C: Integral STM-1/OC-3 packet-side ports on VSP3-o

Packet network
(IP or ATM)
PVG Packet network
terminations
support both bearer
connections and
H.248 or ASPEN
control connections
Dedicated FP with GWC
TDM or access
VSP
Integral (Voice Service (IP or ATM)
network
STM-1 Processor) supporting supporting STM-x ATM FP

port TDM/packet conversion packet-side or 4pGE IP FP
terminations
Figure 33: Logical configuration of a PVG

The trunks on a given TDM-side carrier are all assigned to a particular VSP and are not
available to any other VSP. For access to the packet network, however, FPs and even ports
may be shared by different VSPs.
From a network perspective, each VSP is an independent unit with its own IP addresses [1].
If more than one VSP is housed in a PVG shelf, the GWC perceives each one as a separate
media gateway entity. This in turn means that a PVG is not itself a gateway, as multiple
VSPs, each providing gateway functionality, can be housed in a given PVG.
Three generations of VSP technology are supported. These can be distinguished on the
basis of capacity and configuration, as follows:
Available with TDM-side terminations Packet network terminations
VSP PP STM-1
type 15000 PP FP E1 FP T1 FP GigE IP GigE IP STM-4 STM-1
(32 (56 ports ports on ATM FP ATM FP
or 7480 (4 x 62
20000 E1 ports) E1s) T1s) on VSP 4pGE FP 622 Mb/s 155 Mb/s
VSP3-o Yes No No No No No Yes Yes Yes
VSP3 Yes No Yes Yes Yes Yes Yes Yes Yes
VSP2 Yes Yes Yes Yes Yes No No Yes Yes
A given VSP can support both E1 and T1 TDM-side terminations provided that these are
served by different TDM-side FPs, as follows:
! A VSP2 or VSP3 can support connections with multiple TDM-side FPs of different
types, and can therefore can support both E1 and T1 endpoints.
! A VSP3-o has a single integrated STM-1 port, and therefore cannot support
different endpoint types. Two VSP3-o cards in a given shelf can, however, support
different endpoint types.
See the table in section B2.3.2.2 on page 104 for information about the maximum number
of E1s/DS0s that can be supported by different VSP configurations. Note that this varies
depending on the backbone network type (IP or ATM) and the codec used.
VSP and FP cards are housed in 16-slot Passport shelves. Intra-shelf communication is
based on an ATM switching fabric with capacity of 40 Gb/s (PP15000) or 800 Mb/s
(PP7480). Two shelves can be housed in a cabinet.
PP7480 and PP15000 PVGs are managed by the Preside MultiService Data Manager
(PMDM). A PMDM is typically co-located with each CS2000 supporting PVGs.
[1] A VSP supports up to three IP hosts, each with its own IP address. Every VSP has separate IP hosts for bearer
connections and device/media control signalling. VSPs supporting PRI also have an IP host for Q.931
signalling backhaul.

B2.3.2 PVG Functional Elements
B2.3.2.1 Packet Network Connections

Note: A VSP3 that needs to access an ATM packet network as well as (or instead of) an
IP network can use an ATM FP for this purpose in the same way as a VSP2.
Integral GigE Ports on VSP3

A VSP3 is equipped with two integral GigE ports for direct access to IP packet networks.
One port is active, while the other operates in hot standby mode, ready to take over
immediately in the event of any failure.
Each GigE port terminates not only packet network bearer connections, but also the
packet network connections used for GWC-gateway control signalling, as follows:
! Device / media control connections:
" For CCS7 and PRI access, the recommended protocol stack for device/media
control signalling is
H.248 / UDP / IP / Ethernet
ASPEN continues to be supported as an alternative to H.248.
" For QSIG access, the only protocol stack supported for device/media control
signalling is
ASPEN / UDP / IP / Ethernet
Verification testing of H.248 is required before it can supersede ASPEN as the
recommended device/media control protocol for use with QSIG.
" For a PVG configured to support V5.2 line acess as described in section B2.4
on page 111, the only protocol stack supported for device/media control
signalling is
H.248 / UDP / IP / Ethernet
! Call control connections (signalling backhaul; not applicable for CCS7):
" For PRI and QSIG access, the protocol stacks for backhauled call control
signalling are
Q.931 / IUA / SCTP / IP / Ethernet
QSIG / IUA / SCTP / IP / Ethernet
" For a PVG configured to support V5.2 line acess as described in section B2.4
on page 111, the protocol stack for backhauled call control signalling is
V5.2 / V5UA / SCTP / IP / Ethernet
A PVG requires two or three IP addresses for its packet network connections. One IP
address is used for the bearer connection and one for the device/media control connection.
The optional third IP address is used if a call control connection is also required, i.e. for
PRI/QSIG trunk access or V5.2 line access.

ATM FPs
ATM FPs terminate packet network connections both for ATM backbone networks and
IP backbone networks. Two types of physical termination are supported:
! 155Mb/s ATM packet network connection terminated on an STM-1 FP card
! 622Mb/s ATM packet network connection terminated on an STM-4 FP card
An ATM FP terminates not only packet network bearer connections, but also the packet
network connections used for GWC-gateway control signalling (device/media control
signalling for CCS7, PRI and QSIG access; call control signalling as well for PRI/QSIG
access). Packet network connections are handled differently depending on whether the
packet network backbone is IP or ATM, as follows:
! IP backbone network
" Device / media control connections:
# For CCS7 and PRI access, the recommended protocol stack for
device/media control signalling is
H.248 / UDP / IP / RFC2684 / AAL5 / ATM
# For QSIG access, the only protocol stack supported for device/media
ASPEN / UDP / IP / RFC2684 / AAL5 / ATM
Verification testing of H.248 is required before it can supersede ASPEN
as the recommended device/media control protocol for use with QSIG.
# For a PVG configured to support V5.2 line acess as described in section
B2.4 on page 111, the only protocol stack supported for device/media
" Call control connections (signalling backhaul; not applicable for CCS7):
# For PRI and QSIG access, the protocol stacks for backhauled call
control signalling are
Q.931 / IUA / SCTP / IP / RFC2684 / AAL5 / ATM
QSIG / IUA / SCTP / IP / RFC2684 / AAL5 / ATM
# For a PVG configured to support V5.2 line acess as described in section
B2.4 on page 111, the protocol stack for backhauled call control
signalling is
V5.2 / V5UA / SCTP / IP / RFC2684 / AAL5 / ATM
" Bearer connections
RTP / UDP / IP / RFC2684 / AAL5 / ATM / STM-x
RTCP / UDP / IP / RFC2684 / AAL5 / ATM / STM-x
Note: T.38 / UDP / IP is also supported.
For an IP backbone network not based on ATM, AAL5 must be removed by an edge
device, but this is not necessary if the entire backbone network uses IP over ATM.

! ATM backbone network

" Device / media control connections:
# For CCS7 and PRI access, the recommended protocol stack for
device/media control signalling is
# For QSIG access, the only protocol stack supported for device/media
ASPEN / UDP / IP / RFC2684 / AAL5 / ATM
Verification testing of H.248 is required before it can supersede ASPEN
as the recommended device/media control protocol for use with QSIG.
AAL5 removed at CS2000 CS LAN (or by core network router).
" Call control connections (signalling backhaul for PRI/QSIG; not applicable
for CCS7):
Q.931 / IUA / SCTP / IP / RFC2684 / AAL5 / ATM
QSIG / IUA / SCTP / IP / RFC2684 / AAL5 / ATM
AAL5 removed at CS2000 CS LAN (or by core network router).
" Bearer connections
AAL2 / ATM
A PVG can use AAL2 with either static PVCs (Permanent Virtual Circuits)
or dynamically assigned SVCs (Switched Virtual Circuits) across the ATM
backbone network. Endpoint-provisioned SVCs are also supported.
Note: V5.2 access is not currently supported with an AAL2 backbone network.
ATM FPs implement all ATM layer and corresponding physical layer requirements,
including ATM OAM&P functionality and ATM emission priorities.
For access to the packet network, FPs and even ports may be shared by different VSPs.
B2.3.2.2 TDM Network Connections (TDM FPs)

TDM-side connections are provided either by TDM FP cards supporting E1 or T1
terminations, or by an integrated STM-1/OC-3 port on a VSP3-o. These options are
mutually exclusive, i.e. dedicated TDM-side FPs cannot be used with a VSP3-o.
Three types of dedicated FP card are supported for use with ISN07:
! STM-1 FP with 4 ports, each supporting supporting 63 E1 terminations (PP15000
only)
Note: The STM-1 FP can also be configured to support OC-3 with DS1
channelisation.
! E1 FP with two ports supporting a total of 32 E1s
! T1 FP with two DS3 ports supporting a total of 56 T1s
TDM FPs provide physical port terminations together with multiplexing/demultiplexing
of individual 64 Kb/s channels to/from carriers. The E1s terminated on a given PVG trunk
gateway can be used to support CCS7 bearer channels, 30B+D interfaces for ISDN PRI
and QSIG, or a mixture of CCS7 and ISDN.
Note: The preceding description assumes that CCS7 signalling channels are groomed off
from channnelised TDM-side carriers by a separate multiplexer unit, logically

independent of the PVG but typically co-located with it. As an alternative to this
configuration, it is possible for such grooming to be performed by the PVG itself, as
follows:
! For channelised carriers terminated on 4-port STM-1 FPs, the AAL1 CES (Circuit
Emulation Service) can be used to establish a connection between two specified
TDM-side DS0s.
! For a channelised carrier terminated on the integrated STM-1/OC-3 port of a
VSP3-o, selected channels can be groomed off via the TimeslotRelay feature (note
that this is not a CES function).
Both mechanisms make it possible to groom off signalling channels and consolidate them
on to a dedicated E1 port for presentation to the CS2000.
The trunks on a given TDM-side E1 carrier are all assigned to a particular VSP and are
not available to any other VSP. E1 carriers terminated on a given dedicated STM-1 or E1
TDM-side FP can be assigned to different VSPs, but E1 carriers terminated on the
integrated STM-1/OC-3 port of a VSP3-o cannot be asigned to another VSP.
The table below gives the overall maximum number of 64Kb/s bearer connections or
DS0s that can be supported by various PVG configurations (the numbers will be less if
redundancy is in use).
Max. 64Kb/s
Network
PVG type Codec type channels / DS0s
type per VSP
G.711 (10ms) 2,016
G.711 (20ms) 2,016
IP
G.729a/b (10ms + digit collection) 1,512
PP15000 with G.729a/b (20ms + digit collection) 1,512
VSP3 G.711 (5ms) 2,016
G.726-32 (5ms) 2,016
ATM (AAL2)
G.726-32 (10ms) 2,016
G.729a/b (10ms) 1,512
G.711 (10ms) 1,120
G.711 (20ms) 1,120
IP
G.729a/b (10ms + digit collection) 800
PP15000 with
G.711 (5ms) 1,120
VSP2
G.711 (5ms + digit collection) 960
ATM (AAL2) G.726-32 (10ms) 1,120
G.726-32 (10ms + digit collection) 960
G.729a/b (10ms) 1,512
G.711 (10ms) 1,008
G.711 (20ms) 1,008
IP
PP7480 with
G.711 (5ms) 1,008
VSP2
G.711 (5ms + digit collection) 864
ATM (AAL2) G.726-32 (10ms) 1,008
G.726-32 (10ms + digit collection) 864
Reliability and quality of service are carrier grade, even in a non-redundant configuration
in which E1 carriers are not duplicated.

B2.3.2.3 Voice Service Processor (VSP)

The VSP is the PVG component that supports seamless conversion between access
network media streams (e.g. circuit-based PSTN media streams) and packet network
media streams. From a network perspective, each VSP is an independent unit with its own
IP address. If more than one VSP is housed in a PVG shelf, the GWC perceives each one
as a separate media gateway entity.
The type of conversion performed by a VSP depends not only on the codec used (one
default codec and one compression codec can be provisioned for a given VSP), but also
on the packet network type and on how the VSP accesses the packet network, as follows:
! A VSP3 supporting direct access to an IP packet network via its integral GigE port
packetises voice samples into RTP to be conveyed over IP and Ethernet. Codec
capabilities supported:
" G.711, packet size 10ms or 20ms
" G.729a and G.729b, packet size 10ms or 20ms
! A VSP supporting access to an IP packet network via an ATM FP packetises voice
samples into RTP and supports IP datagram encapsulation using AAL5 and
RFC2684. Codec capabilities supported:
" G.711, packet size 10ms or 20ms
" G.729a and G.729b, packet size 10ms or 20ms
! A VSP supporting access to an ATM packet network via an ATM FP packetises
voice samples into AAL2 ATM cells. Codec capabilities supported:
" G.711, packet size 5ms
" G.726, packet size 10ms (VSP3 and VSP3-o also support 5ms packetisation)
Note: VSP3 and VSP3-o also support RFC2833 for DTMF transparency and T.38 fax
relay (VoIP only).

The VSP responds to GWC requests made via H.248 or ASPEN to make and break
narrow-band connections between TDM trunks and packet bearer connections (either
RTP or AAL2). It also supports specific voice services, as follows:
! Tone generation
When CS2000 determines that a tone needs to be applied, the GWC sends an
ASPEN command to the PVG, specifying the logical identifier of the tone. CS2000
does not need to know about market-specific variations in tone characteristics; it
relies on the gateway to ensure that the tones characteristics are correct when it is
played, based on the country in which the gateway is deployed.
! Silence suppression
! Comfort noise insertion
! Echo cancellation
The PVG can apply echo cancellation to its TDM-side circuits when this is required
to maintain voice quality.
! COT (Continuity Testing)
The PVG can apply continuity tones and loop-back tones on its TDM-side circuits
when required for CCS7 continuity testing.
! In-band digit collection and generation
! CLASS support
The PVG can provide V.23 modem capabilities to support CLASS data download
functionality for CS2000 V5.2 lines.
B2.3.2.4 PVG Support for TDM Looparounds

For incoming calls to ingress DPT GWCs, for which the GWC has no access to packet
network media streams, it may be necessary to introduce a TDM looparound trunk into a
call to provide such access, e.g. for digit collection or tone insertion. Looparound
capabilities can be provided by any PVG type (PP15000 or PP20000 equipped with
VSP3, VSP3-o or VSP2, or PP7480 equipped with VSP2). The existence of such
looparounds between TDM-side endpoints is not visible to the controlling GWC, which
perceives both ends as separately addressable endpoints. See section F1.2.2 on page 519
for further information.
B2.3.2.5 Access to TDM Side of Dual Working Configuration

A CS2000 dual working configuration is one that includes conventional circuit-based
trunk and line peripherals as well as trunk and line media gateways. The ISN07 software
load includes support for both, allowing TDM and packet capabilities to be supported in
parallel by XA-Core.
Looparound trunks are used to provide connections between the TDM and packet
environments. In the packet environment, the E1 carrier that supports the looparound is
terminated on the TDM side of a PVG; in the TDM environment, it is terminated on a
Digital Trunk Controller (DTC) peripheral.
From the perspective of the call processing software running in the CS2000 Core, calls
to/from such a looparound trunk appear to be calls to/from a remote network node.

B2.3.3 Summary of Characteristics
B2.3.3.1 Applications Supported

! VoIP
! VoATM (VoAAL2)
B2.3.3.2 GWC-Gateway Signalling

Physical connections:
! GWC termination
100BaseT Ethernet terminated on GWC card in SAM21
! Gateway terminations may be either:
" Gigabit Ethernet terminated on 4-port GigE card on VSP3 or VSP3-o (VoIP
only)
" Gigabit Ethernet terminated on integral GigE port on VSP3 (VoIP only)
" ATM connection terminated on ATM FP card in PVG (155 Mb/s STM-1 or
622 Mb/s STM-4)
Device / media control signalling is H.248 or ASPEN over UDP / IP. Lower layers depend
on type of gateway access to packet network:
! H.248 (or ASPEN) / UDP / IP / Ethernet for Gigabit Ethernet terminated on integral
GigE port on VSP3
! H.248 (or ASPEN) / UDP / IP / RFC2684 / AAL5 / ATM for ATM connection
terminated on ATM FP card in PVG
" For an IP backbone network not based on ATM, AAL5 must be removed by
an edge device, but this is not necessary if the entire backbone network uses
IP over ATM.
" AAL5 removed at CS2000 CS LAN (or by core network router) if backbone
network is ATM
Note: Signalling between the GWC and the CS LAN PP8600 is IP over Ethernet;
the GWC does not know about the lower levels of the protocol stack (below the IP
layer), which are used only outside the CS LAN.
Call control signalling (where PVG provides signalling gateway functionality as well as
media gateway functionality):
! N/A for CCS7 (signalling terminated separately, on USP or FLPP in CS2000)
! Q.931 over IUA/SCTP/IP for PRI (lower layers vary, as for H.248 device / media
control signalling)
! QSIG over IUA/SCTP/IP for PRI (lower layers vary, as for H.248 device / media
control signalling)
Note: A PVG configured to support V5.2 access uses V5.2 / V5UA / SCTP / IP for V5.2
signalling backhaul.

B2.3.3.3 PSTN / TDM Access

Physical circuits and terminations used to support access:
! E1 or T1 carriers to/from PSTN, PRI PBX or other PRI-enabled device such as IN
external IP, or QSIG PINX
! STM-1 carriers to/from PSTN
! Carrier terminations on TDM FP cards in PVG or on integrated STM-1/OC-3 port
on VSP3-o
Note: VSP3-o supports only TDM-side trunk access, not V5.2 line acess.
Types of bearer channel to/from access network
! 64 Kb/s bearer circuits for CCS7
! 64 Kb/s B-channels for PRI and QSIG
Signalling terminations (where PVG provides signalling gateway functionality as well as
media gateway functionality)
! N/A for CCS7
Note: PVG does not terminate CCS7 signalling, but can groom off CCS7 signalling
channels from TDM-side carriers and consolidate them on to a dedicated E1 port
for presentation to the CS2000, as described in section B2.3.2.2 on page 104. .
! D-channel terminations for PRI (Q.931) and QSIG
B2.3.3.4 Packet Network Bearer Connections

Port / termination characteristics:
! Gateway terminations may be either:
" Gigabit Ethernet terminated on integral GigE port on VSP3 (VoIP only) or on
GigE port on dedicated 4pGE FP card
" ATM connection terminated on ATM FP card in PVG (155 Mb/s STM-1 or
622 Mb/s STM-4)
Voice bearer connections across packet network depend on type of access to packet
network:
! For Gigabit Ethernet terminated on integral GigE port on VSP3
RTP / UDP / IP / Ethernet and RTCP / UDP / IP / Ethernet
! For ATM connection terminated on ATM FP card in PVG
" IP network
RTP / UDP / IP / RFC2684 / AAL5 / ATM
RTCP / UDP / IP / RFC2684 / AAL5 / ATM
T.38 / UDP / IP / RFC2684 / AAL5 / ATM
For an IP backbone network not based on ATM, AAL5 must be removed by
an edge device unless the entire backbone network uses IP over ATM.
" ATM network
AAL2 / ATM
The lower layers of the protocol stack are the same for other types of IP network bearer
connection, e.g. T.38 / UDP / IP.

Up to three codecs can be provisioned for a given VSP: a compression codec and two
G.711 codecs. Supported codec capabilities:
! G.711, packet size 10ms or 20ms (VoIP) or 5ms (VoATM)
! G.729a and G.729b, packet size 10ms or 20ms (VoIP) or 10ms (VoATM)
! G.726 (VoATM only), packet size 10ms (VSP3 and VSP3-o also support 5ms
packetisation)
! In-band DTMF tone capabilities supported by VSP3 but not VSP2:
" RFC2833 is supported for G.711 and G.729
" For VoAAL2, VSP3 supports DTMF transport using I.366-1 Annex K
! Group 3 fax between two PVGs (VoIP or VoATM), with auto-change to G.711
! T.38 fax (VSP3 and VSP3-o VoIP only)
! Modem between two PVGs (VoIP or VoATM), with auto-change to G.711
! Text telephone between two PVGs (VoIP or VoATM), with auto-change to G.711
Codec negotiation takes place between the media gateways involved in a call to determine
the correct codec to use. The aim is that the codec used should be the codec that is highest
in preference order and supported by both gateways. The capabilities of each media
gateway are conveyed to its GWC and to the far-end gateway in the form of an SDP
(Session Description Language) session description, and an appropriate codec is selected
from the intersections of both gateways sets of capabilities. See see section G4.3 on page
751 for further information about codec negotiation, and section D4.6.1 on page 286 for
some examples of SDP relayed via ASPEN.

B2.4 PVG as a V5.2 Gateway

B2.4.1 Overview
A PVG can be configured as a V5.2 gateway rather than a trunk gateway. A PVG V5.2
gateway supports V5.2 interfaces connected to V5.2 Access Networks (ANs) serving
V5.2 PSTN lines, i.e. analogue subscriber lines.
As for PRI and QSIG access to the packet network, a PVG that supports V5.2 access must
provide signalling gateway functionality as well as media gateway functionality, to
provide mapping and conversion between the following:
! TDM-side 64Kb/s channels configured as V5.2 communication channels
(C-channels) conveying Layer 3 call control messages and other signalling over a
LAPV5 Layer 2 datalink.
For analogue lines, V5-PSTN call control messages convey the equivalents of
DTMF in-band signalling or standard POTS electrical signals.
In addition to call control signalling, V5.2 C-channels support the following
protocols for controlling and maintaining the channels of the V5.2 interface:
" A Bearer Channel Control (BCC) protocol is used to assign bearer channels
dynamically, as required.
" A common control protocol is used to provide common control functions and
user port control.
" A protection protocol is used to switch a logical C-channel to an alternative
physical C-channel if there is a failure on the current physical C-channel.
" A link control protocol is used to support maintenance access to individual
carriers (referred to as links in V5 terminology) within a V5.2 interface.
The term V5.2 signalling should be taken to include control and maintenance
signalling as well as call control. The term V5-PSTN signalling specifically denotes
call control signalling for PSTN (analogue) lines.
! Packet network connections supporting a V5.2 / V5UA / SCTP / IP protocol stack.
V5UA (V5.2 User Adaptation) is designed to convey V5.2 Layer 3 messages
between a GWC and a gateway. V5UA provides adaptation between V5.2
signalling and the SCTP layer used to provide reliable transport.
The protocol used for the device/media control signalling that complements V5-PSTN
call control signalling between the GWC and gateway is H.248.
The architecture and physical characteristics of a PVG configured to support V5.2 lines
are as described in section B2.3 on page 99 for PVGs used to support CCS7, PRI and
QSIG access, and to avoid duplication the description is not repeated in full here. The VSP
version used can be either VSP3 (housed in PP15000) or VSP2 (housed in PP15000 or
PP7480). The TDM-side FP card used must be an E1 FP terminating 32 E1s (V5.2 is not
supported using VSP-3o STM-1 ports).
The distinguishing characteristic of a PVG configured to support V5.2 lines is that its
TDM-side E1 carriers are grouped into one or more integrated V5.2 interfaces, each
serving a V5.2 Access Network (AN). The grouping of E1s and their assignment to V5.2
interfaces controlled by the V5.2 provisioning application at the CS2000 Core, and is

transparent to the PVG. The maximum number of E1 carriers per interface is 16. Each
V5.2 interface consists of bearer channels and shared C-channels.
The maximum number of line endpoints that can be supported over a given V5.2 interface
is 2048. No more than 6,384 V5.2 lines can be supported by a given line GWC. The
number of line endpoints defined and the number of bearer channels available at the PVG
determine the concentration that takes place between the V5.2 AN and the gateway. All
of the lines belonging to a given interface, and all the gateways (VSPs) serving that
interface, must be supported by one GWC.
B2.4.2 Capacity and Configuration

This section provides a summary of the capacity and configuration options available for
PVG support of V5.2 interfaces. See A89009559 for a more detailed discussion, including
information about capacity enhancements in ISN06.
! TDM-side E1 links
A V5.2 GWC can support up to 128 E1 links and 63 AN interfaces (in practice, 53
AN interfaces, as explained in the list item on AN sizes).
A given VSP can support E1s that are terminated on different 32-port E1 FP cards.
The overall maximum number of E1s that can be supported is subject to VSP
hardware limitations and codec used. Assuming that each E1 FP used for V5.2 has
30 DS0s, the table below summarises the E1 capacity of the different VSPs
supported.
Hardware E1 capacity [1] [2]

VSP type PVG type G.711 G.729
VSP3 PP15000 64 50
PP15000 37 26
VSP2
PP7480 33 24
[1] E1s used for V5.2 interface may have 0 to 2 C-channels. Typically, only 1 C-channel is
defined on a link, thus an average of 30 DS0s is assumed per E1.
[2] VSP capacity (BHHCA) may preclude usage of the maximum theoretical number of E1s.
! Bearer channels
The maximum number of B-channels per E1 carrier is from 29 to 31, depending on
whether TS16 and TS15 are defined as C-channels (TS31 is not available for use as
a C-channel). The maximum number of bearer channels available for a complete
V5.2 interface is approximately 480 (16 E1s with an average of 30 B-channels),
while the maximum number of bearer channels for a line GWC is 3,840. The
number of line endpoints defined (see below) and the number of bearer channels
available at the PVG determine the concentration that takes place between the V5.2
AN and the gateway.

! AN sizes (line endpoints)

The size of a given AN interface is specified in terms of the number of line
endpoints to be supported by the AN (see section C2.7.2 on page 197). Although
any size up to the maximum of 2048 may be specified, only the AN types/sizes
listed below are fully supported. If an AN size other than one of these is specified
as the MAXLINES value for the V5.2 interface, table control code automatically
rounds up the number entered to match the next supported AN size, e.g. an entered
size of 375 would be automatically rounded up and would cause 480 lines to be
reserved.
Type Size Max. no. ANs Reserved capacity

Small120 120 53 6360 [1]
Small240 240 26 6240 [1]
Small480 480 13 6240 [1]
Small 672 9 6048
Medium 1344 4 5376 [1]
Large 2048 3 6144 [1]
[1] This is the maximum number of V5.2 line endpoints that can be defined for a given GWC
using only ANs of this size without exceeding the GWC maximum of 6400 lines. Using a
mixture of AN sizes, the maximum number of V5.2 lines that can be defined for a GWC is
6384.
! GW and GWC capacity

The maximum number of V5.2 line endpoints that can be supported by a given
GWC is 6,384. The maximum number of simultaneous calls is 3,840 per GWC,
corresponding to the maximum number of B-channels that can be supported.
! VSP capacity
The B-channels and C-channels for a given AN interface can be distributed between
different VSPs, subject to the general rule that all the VSPs involved in supporting
an interface must subtend the same GWC. VSP capacity must therefore be stated in
terms of the numbers of B-channels and C-channels supported. This depends on the
hardware and codec used, as summarised in the table below.
Hardware C-channel B-channel capacity
VSP type PVG type capacity [1] G.711 G.729

VSP3 PP15000 64 [2] 2016 [2] 1512 [2]
PP15000 40 1120 800
VSP2
PP7480 40 1008 720
[1] A V5.2 interface may have from 1 to 4 C-channels. A V5 link (an E1 carrier belonging to a
V5.2 interface) can support from 0 to 2 C-channels. A V5.2 C-channel is a HDLC entity,
and the overall number of C-channels supported is subject to the VSP hardware limit on
such entities.
[2] The overall maximum number of B-channels plus C-channels on a VSP3 must not exceed
2048.

B2.4.3 Robustness and Protection Switching

The V5.2 standard recommends that each AN interface should have a backup C-channel
on a separate carrier to support protection switching (switching from active to backup
C-channel in the event of failure). Nortel further recommends that the active and backup
C-channels for a given AN interface are on E1 carriers connected to different VSP cards
in separate PVG shelves (see section B2.4.3 on page 114 for more details). This
configuration ensures carrier grade service in the event of primary link failure, VSP card
failure, or PVG software upgrade [1].
Figure 34 illustrates a simple protection switching configuration based on two VSPs.
PVG
AN Shelf 1 GWC
VSP-A
V5.2 C-path
Primary E1-Link
SG
Call
Packet Network
V5UA
Bearer MG control
Managed
RTP
VSP-B
V5.2 C-path H.248 Media
Secondary E1-Link SG control
RTP
Bearer MG
Shelf 2
Figure 34: V5.2 configuration with redundant VSPs
V5.2 protection switching ensures that V5.2 signalling continues over the secondary V5.2
link in the event of a failure. Use of the recommended configuration illustrated in Figure
34 ensures that continuity of service is maintained when either the primary V5.2 link or
the VSP card fails. What happens is as follows:
! Existing calls on the unaffected links are maintained. Calls on the affected link will
drop, but users can re-originate immediately. V5.2 signalling immediately switches
to the protection link for call and interface control, and new (reorginated) calls will
use B-channels on unaffected E1s terminated on either VSP.
! Calls on other V5.2 interfaces served by VSP-A signalling links are unaffected.
V5.2 protection switching and its operation are completely transparent to the V5.2 AN
connected to the V5.2 interface.
The AN sizes being used must be taken into account when V5.2 interfaces and the VSPs
used to support them are configured. For example, use of small ANs with line sizes of 120
or 240 lines makes it possible to maximise GWC line capacity, but may cause VSP
capacity to be exceeded if only two VSPs are used, depending on the VSP BHCA capacity
and the traffic model for the lines being served. See A89009559 and the separate Nortel
document IAW Engineering Guidelines for details.
[1] PVG software upgrades are performed shelf by shelf, and the entire shelf is out of service for the duration of the
upgrade. The only way to avoid service outage during upgrades is therefore to ensure that the VSPs used for a
given V5.2 interface are in separate shelves. These may be in the same PVG frame or in different frames.

B2.5 H.323 Gateways

H.323 is a protocol architecture, not a gateway type. It is an ITU-defined umbrella
specification for use in the definition and implementation of multimedia services
supporting the integration of voice, video and data applications. It is important because,
as an open interface, it enables such multimedia services to be implemented in
multi-vendor networks. See Chapter D5: H.323 for a detailed description.
In ISN07, CS2000 H.323 GWCs use H.323 to control a wide variety of units, as illustrated
in Figure 35. The software order code for H.323 functionality is CS2B0004.
Full interworking via FT trunks

with H.323-controlled units
CS2000 served by other CS2000s
CS2000 Core
Basic interoperability via
non-FT trunks with units
served by other CS2000s
H.323 proxy H.323 Other
(GWC equivalent) proxy GWCs
Full interworking Basic

with other interoperability
H.323-controlled with non-H.323
H.323 signalling units served by units served by
(no bearer traffic) same CS2000 same CS2000
Business Communication
Proprietary Meridian 1 Call Server for
units IP PBX Manager Enterprise
(BCM) (CSE1000)
Cisco
access router / Westell
Third-party DPNSS gateway
units gatekeeper
(2600 / 3600 / (InterChange
7200) iQ203x)
Figure 35: The role of H.323 in a CS2000 network

B2.6 Mediant 2000 Trunk Gateway

B2.6.1 Overview
With effect from ISN07, CS2000 offers a choice of gateway types for supporting trunk
access to the packet network:
! Packet Voice Gateway (PVG) described in section B2.3 on page 99
! The AudioCodes Mediant 2000 gateway described in this section
In purely functional terms, the PVG and Mediant 2000 provide essentially the same
capabilities, as follows:
! Telephony interface support
Both types of gateway support
" TDM-side ETSI ISUP CCS7 trunks, as described in Chapter E2: CCS7
Interfaces.
" ISDN PRI access trunks, as described in Chapter E4: PRI Access Interface.
! Device/media control signalling
Both types of gateway are controlled via H.248, as described in Chapter D3: H.248.
! Backhauled PRI call control signalling
Both types of gateway support IUA, as described in Chapter D10: IUA.
The differences between PVG and Mediant 2000 gateways are to do with capacity and
deployment options rather than functionality, as follows:
! The PVG is a high-capacity gateway that is typically owned and operated by the
operating company and located on telco premises.
! The Mediant 2000 is a small gateway that is typically owned and operated by an
enterprise and located on customer premises. It is designed to provide cost-effective
support for remote deployment of a relatively small number of CCS7 or PRI
interface terminations, e.g. for connecting PBXs. It is a compact unit that can be
installed either on a desktop or in a 1U space in a standard 19" rack.
The Mediant 2000 is based on a TP-1610 cPCI VoIP communication board with
integrated ports that can support the following:
! TDM-side connections
1, 2, 4, 8 or 16 E1 or T1 carrier spans
! Packet-side connections
Two 10/100 BaseT Ethernet ports
A TP-1610 actually comprises two logically independent gateway units, each with its own
IP address and MAC address.
A Mediant 2000 gateway can support up to 480 simultaneous calls.


! VoIP

Physical connections for VoIP
! GWC termination
! Gateway termination
10/100 BaseT Ethernet connection terminated on TP-1610 board in Mediant 2000
Device / media control signalling:
! H.248 / UDP / IP
Call control signalling (PRI only):
! Q.931 / IUA / SCTP / UDP / IP
B2.6.2.3 TDM-Side Access

Physical circuits and terminations used to support access:
! E1 carriers supporting TDM-side ETSI ISUP trunks
! 30B+D E1 or 24B+D T1 carriers to/from PRI PBX or other PRI-enabled device
such as IN external IP
Types of bearer channel to/from access network
! 64 Kb/s B-channels for PRI
Signalling terminations (gateway provides signalling gateway functionality as well as
media gateway functionality)
! 64 Kb/s D-channel terminations for PRI (Q.931)

A Mediant 2000 gateway is typically not directly to the IP backbone network. Instead, it
is connected to an Ethernet LAN, which is in turn connected to the IP backbone network.
Bearer connections across the packet network are therefore Ethernet end-to-end.
Codec capabilities:
! G.711, packet size 10ms or 20ms (VoIP)
! G.729a and G.729b, packet size 10ms or 20ms (VoIP)
! In-band DTMF tones (RFC2833 supported for G.729)
! T.38 fax

B2.7 Westell DPNSS Gateway

Westell InterChange iQ2030 Series gateways are used in CS2000 solutions to support the
DPNSS VPN interface described in Chapter E6: DPNSS Interface. Two gateway types
are supported:
! iQ2030, which provides one E1 carrier connection (30 user channels) to support a
TDM-side DPNSS link with a customer PBX.
! iQ2032, which provides two E1 carrier connections (60 user channels) for
TDM-side DPNSS links.
Each gateway also provides a 10/100BaseT Ethernet connection with the core network,
and is controlled by a H.323 GWC using the H.323 interface described in Chapter D5:
H.323.
Figure 36 illustrates the network configuration used by CS2000 to support DPNSS
signalling.
CS2000 DPNSS over DFT trunks To/from other

(NTP[HNIP] in IBN7 messages) CS2000s
CS LAN
CS2000
Core
To/from TDM VPNs
Looparounds for
interoperability
with IBN lines
H.323 H.323
proxy proxy
GWC DPNSS over QSIG GWC
(in QSIG Facility IEs)
DPNSS DPNSS
over H.323 over H.323
(in H.225 (in H.225
UUI IEs) UUI IEs)
IP core network
DPNSS DPNSS
over E1 over E1
carriers Westell Westell carriers
Digital iQ203x iQ203x Digital
PBX Bearer connections PBX
gateway gateway
Figure 36: CS2000 support for DPNSS signalling

B2.8 Carrier-Located Line Media Gateways

B2.8.1 Functional Overview
Carrier-located line media gateways provide essentially the same functionality as CPE
line gateways attached to customer LANs or cable acess networks, as described in
sections B2.9 and B2.10 respectively, i.e. access to the packet backbone network for VoIP
and data. The main difference is that carrier-located gateways are significantly larger,
such that a given gateway can support access for hundreds or even thousands of end users.
This increases the range of deployment options that a carrier network can offer its
customers. Specifically, it enables customers who do not wish to own and maintain their
own access networks to lease capacity from the carier network instead.
Typically, a carrier-located line media gateway supports both VoIP and high-speed data
access for subscribers. Figure 37 provides a simplified functional view of the capabilities
provided.
CS2000 CS LAN
CS2000 Core
MS2000
GWC
GWC-gateway
Dual PP8600s signalling (H.248)
Core Bearer connections for VoIP

network
Bearer connections for data
are independent of
MG9000 CS2000-controlled VoIP connections
Lines and ADSL
Figure 37: Functional view of capabilities provided by carrier-located line media

gateways
In ISN07, CS2000 supports the deployment of the MG9000 as a carrier-located line media
gateway. It is described in section B2.8.2 on page 120.

B2.8.2 MG9000 Media Gateway

B2.8.2.1 Overview
With effect from ISN07, CS2000 supports the MG9000 as a high-capacity line media
gateway. The main functional elements of an MG9000 are:
! Service Module (SM) cards providing different types of access network
termination. ISN07 supports two types of termination:
" Type A POTS lines
" ADSL (Asymmetrical Digital Subscriber Line) lines
! Internet Telephony Processor (ITP) card for aggregating circuit-based voice flows
to/from SM cards and performing conversion to/from packet-based
RTP/UDP/IP/AAL5/ATM flows.
! Supercore card providing an STM-1/OC-3 interface to the packet network for
AAL5/ATM traffic, and also providing an internal ATM switching fabric.
The device/media control protocol used by CS2000 GWCs to control MG9000 operation
is H.248.
The MG9000 supports both voice and data access to packet network (no need for external
splitter or DSLAM), and can support ADSL broadband and POTS narrowband services
simultaneously. Intra-switching of bearer connections is supported via the MG9000s
internal ATM switching fabric, conserving backbone network resources. Support for ESA
(Emergency Stand-Alone) operation means that the bearer paths for intra-switched calls
remain through-connected even if the control connection with the CS2000 GWC is lost.
Figure 33 illustrates the logical configuration of an MG9000 media gateway.
Service Module (SM)

MG9000 media gateway
connection with
CS2000 GWC
cards supporting H.248 control
access network
connections
POTS-32 cards Internet Telephony SuperCore

(each supporting 32 Processor (ITP) STM-1c
Type A POTS lines) providing media network
gateway functionality interface Bearer
connections
25 Mb/s links
POTS+ADSL cards between ITP
and ITX 200 Mb/s links
(each supporting between network
8 Type A POTS ports interface and ITX
plus 8 ADSL ports) Internet Telephony
Extender (ITX) links to
subtending shelves Backbone
(master shelf only) packet
network
25 Mb/s links
between ITX and
subtending shelves
Figure 38: Logical configuration of an MG9000 media gateway (master shelf)

B2.8.2.2 MG9000 Shelves and their Contents

Each MG9000 shelf provides four specialised control card slots and up to 16 Service
Module (SM) slots for access network termination cards. Slots are allocated as follows:
! The four control card slots house two pairs of duplicated control cards:
" Internet Telephony Processor (ITP)
The ITP is a Virtual Media Gateway (VMG) that aggregates voice on each
shelf. There is a pair of ITPs on each shelf, supporting:
# VoIPoAAL5 adaptation
# Echo cancellation
# 25 Mb/s serial link interface to ITX
# H.248 signaling client for communication with GWC
" SuperCore (packet network interface)
# STM-1c network interface
# 1:1 card redundancy
# APS
# 200 Mb/s links to ITX for voice over IP subtending
# 2.5 Gb/s ATM switching fabric
! Each shelf provides 16 Service Module (SM) slots, which are used primarily for
" POTS-32 cards (32 Type A POTS lines)
" POTS+ADSL cards (8 Type A POTS ports, plus 8 ADSL ports offering
6.144Mb/s downloading and 640Kb/s uploading)
! In the master / controller shelf of an MG9000 frame, some SM slots are used to
house Internet Telephony Extender (ITX) cards, which provide the following
functionality:
" Delivering voice to the SC card over the controller backplane
" Supporting 25 Mb/s star subtending links
ITX cards are controller cards and are duplicated for reliability. One ITX pair can
support up to 8 shelves of voice services. Two ITX pairs are required for 12 shelves,
which is the maximum number that an MG9000 can support in ISN07.
B2.8.2.3 Configurations and Capacity

MG9000 shelves are housed in four-shelf frames.
A single-shelf MG9000 unit can provide gateway functionality for up to 406 POTS lines
or 104 POTS lines together with 104 ADSL lines. Different types of service module card
can be mixed in a shelf.
To make the most efficient use of the STM-1 connection with the backbone network, an
MG9000 typically comprises one master shelf and one or more subtending shelves. The
master shelf houses the packet connection used by all the other shelves, and provides
25Mb/s connections to enable subtending shelves to access the shared packet network
connection.

A fully equipped four-shelf frame in which only the master shelf has a packet network
connection is regarded as one logical MG9000 unit. This configuration offers 61 service
module slots per frame (13 on the master shelf and 16 on each subtending shelf), and thus
supports the following access network capacity:
! 1952 POTS lines per frame
! 488 POTS+ADSL lines per frame
Multi-frame MG9000 configurations are also supported. There is a single master shelf for
the configuration as a whole, subtended by all the other shelves in the same frame and in
different frames. In ISN07, the largest MG9000 configuration supported is one with three
frames, which can support up to 5,920 POTS lines. A multi-frame configuration can be
equipped with a second packet network connection if this is believed to be necessary to
provide sufficient capacity for the expected traffic profile. Such a second packet network
connection is also housed in the master shelf of the configuration.

! VoIP
! ADSL data sessions

! GWC termination
" 155 Mb/s STM-1 interface
! H.248 / UDP / IP
Call control signalling:
! H.248 is used to report the occurrence of relevant events on the line interface, e.g.
off-hook detection for a call attempt from a line, and causes the initiation of events
over the line interface, e.g. ringing for an incoming call to a line.
B2.8.3.3 Bearer Access

! Type A POTS lines
! ADSL ports offering 6.144 Mb/s downloading and 640 Kb/s uploading

155 Mb/s STM-1 interface supporting RTP / RTCP bearer flows over IP / AAL5 / ATM.

B2.9 Line Media Gateways on Customer LANs

A customer LAN line gateway or Integrated Access Device (IAD) consists of a gateway
software load running on a dedicated hardware platform to support VoIP. Specifically, it
supports voice-only access to an IP backbone network for analogue subscriber lines.
A customer LAN line gateway is not directly connected to the IP backbone network.
Instead, it is connected to an Ethernet LAN, which is in turn connected to the IP backbone
network (a variety of access mechanisms are available). The gateway is typically located
on customer premises, in a cabinet or frame that houses multiple gateways of the same
type. A range of technology options are available for implementing the customer LAN
and enabling it to access the backbone packet network; the most appropriate technology
to use in a given CS2000 network configuration should be determined in consultation with
Nortel Sales Engineering.
The three main functional elements in any customer LAN line gateway are:
! RJ-11 or RJ-21X terminations for analogue subscriber lines
! Ethernet LAN interface
! Codec supporting analogue / digital conversion for bearer connections
Figure 39 illustrates these gateway components and their functions at a logical level.
Customer LAN
Customer LAN Gateway
MGCP
RJ-11 or Codecs LAN interface MGCP
RJ-21X supporting supporting Alternative IP
terminations analogue / access to the access
for analogue digital IP backbone technologies
backbone
subscriber conversion network via a Bearer flows available network
lines (G.711, G.729) customer LAN
Bearer flow
Figure 39: Logical configuration of a customer LAN line gateway
Typically, customer LANs supporting line media gateways use a firewall / NAT (Network
Address Translator) to provide security. To support NAT traversal for signalling traffic,
media gateways and other hosts that are located behind a NAT must:
! Initiate communication with their GWCs (a GWC cannot initiate communication
with a gateway behind a NAT).
! Provide their GWCs with address information embedded in signalling packets,
which the GWC can then map on to the source address in the packet header (which
is that of the NAT rather than the gateway).
! Use keep-alive messaging to ensure that communication with their GWCs is
maintained when no call is in progress (the GWC will otherwise be unable to send
setup messages for calls incoming to the gateway).

Dynamic address discovery for signalling is described in detail in section D8.4 on page
322.
Address discovery is also a requirement for bearer connections across the packet
backbone network. This involves the use of a media proxy, as described in section
B5.1.2.2 on page 155.
B2.9.2 Specific Gateway Types Supported

All of the customer LAN gateway types supported in ISN07 provide essentially the same
functionality (as described in section B2.9.1 on page 123) and have essentially the same
characteristics (as summarised in section B2.9.3 on page 125). The main difference
between them is in the number of lines they can terminate and the type of termination
used.
Nortel has defined naming conventions for the customer LAN gateways supported as
standard in CS2000 international solutions. These conventions are designed to ensure that
the name provides a summary of the characteristics and capabilities of the gateway type:
! Generic name
Nortel Networks Integrated Access Device
! Model number with the format 1PnnV, where
P indicates the device/media control protocol, for which two values have
currently been defined:
0 SIP
1 MGCP
nn indicates the number of TDM-side lines supported, e.g. 01, 04, 08, 16, 32
V indicates the equipment vendor, and for ISN07 is one of:
M Ambit
S Askey
Table 3 lists the customer LAN gateways types supported in ISN07 and gives the standard
Nortel IAD name for each one.
Table 3: Nortel Networks IADs supported in ISN07

Vendor Model name Customer LAN gateway type Protocol
1101M 1-port LG001S IAD
Ambit 1116M 16-port gateway MGCP
1132M 32-port LG132E gateway
1104S VG201 with 4 RJ-11 ports (previously known as RT-132)
Askey [1] MGCP
1130S VG601 with 30 RJ-21X ports
[1] Askey line gateways have currently been productised only for deployment in China and Hong
Kong.
Support is also provided for Mediatrix 1124 customer LAN gateways under the Nortel
Business Partner Program. The Mediatrix 1124 supports up to 24 analogue subscriber
lines by means of a 50-pin RJ-21X connector.


Listed characteristics apply equally to Askey, Ambit and Mediatrix gateways except
where explicitly noted otherwise.

! VoIP

! GWC termination
Ethernet connection terminated on LAN interface card in gateway
! MGCP / UDP / IP
Note: MGCP is also used for dynamic address discovery, as described in section
D8.4 on page 322.
! MGCP is used to report the occurrence of relevant events on the line interface, e.g.
B2.9.3.3 Line Access

Characteristics of analogue POTS lines terminated on customer LAN gateways:
! 2-wire
! Loop start
! DTMF in-band dialling
! Call progress signalling via in-band tones (except hook state changes and ringing)
! CLASS functionality (downloading digital data in-band) supported

A customer LAN line media gateway is not directly connected to the IP backbone
network. Instead, it is connected to an Ethernet LAN, which is in turn connected to the IP
backbone network. Bearer connections across the packet network are therefore Ethernet
end-to-end. Codec capabilities:
! G.711, packet size 10ms or 20ms (VoIP)
! G.729a and G.729b, packet size 10ms or 20ms (VoIP)
! In-band DTMF tones (RFC2833 supported for G.729)
! T.38 fax
MGCP messaging is used in codec negotiation, i.e. to determine the correct codec to use
for a given call (see section G4.3 on page 751).

B2.10 Line Media Gateways on Cable Access Networks

A HFC cable access network comprises two main functional elements:
! Multimedia Terminal Adaptors (MTAs) located on customer premises and
providing line gateway functionality (see section B2.10.1.1).
! A Cable Modem Termination System (CMTS) located at the head (upstream) end
of the cable access network and providing a bridge between the access network and
the packet backbone network (see section B2.10.1.2 on page 127).
B2.10.1.1 Multimedia Terminal Adaptor (MTA) Gateways

An MTA line gateway consists of a gateway software load running on a dedicated
hardware platform (including a cable modem) to support VoIP. Specifically, it supports
access to an IP backbone network for analogue subscriber lines. (It also supports data
access access for non-VoIP applications, such as internet access, but CS2000 is not
involved in providing this functionality in ISN07.)
An MTA line gateway is not directly connected to the IP backbone network. Instead, it is
connected to a HFC (Hybrid Fibre Coax) cable access network, which is in turn connected
to the IP backbone network via a CMTS (Cable Modem Termination System) and an edge
router. The gateway is typically located on customer premises. Layer 3 IP messaging runs
from the IP backbone, through the CMTS to the MTA over HFC.
Figure 40 illustrates the logical configuration of the access network used by MTA line
gateways.
Three types of information flow take place over the HFC

network:
NCS control connections between CS2000 GWC IP backbone network
and MTA (NCS signalling routed/relayed via CMTS
and edge router)
DOCSIS control connections between CMTS and
MTA (terminated at CMTS)
Bearer connections (DOCSIS packet flows
converted to/from IP packet flows at CMTS)
HFC cable access network
Multimedia Terminal Adaptor
HFC
Two RJ-11 CMTS
Codecs cable modem NCS
terminations supporting supporting
for analogue analogue / access to the (Euro)DOCSIS Edge
subscriber digital IP backbone router
lines (also an network via a Bearer flows
conversion
Ethernet/USB (G.711 A-law) cable access
port for a PC) network
Figure 40: Logical configuration of an MTA line gateway

A variety of hardware platforms can be used to support MTA line gateway capabilities
for CS2000 solutions. The basic functionality provided is the same regardless of the MTA
model. Depending on the market for deployment, an MTA may use either of two versions
of the DOCSIS (Data Over Cable System Interface Specification) protocol, as follows:
! MTAs for deployment in Europe use EuroDOCSIS 1.1 or 2.0.
! MTAs for deployment in Australia, Japan and CALA use DOCSIS 1.1 or 2.0.
The MTA model and the DOCSIS version used involve only the MTA and the CMTS,
and are transparent to the CS2000 GWC. To avoid repetition, this section uses the name
DOCSIS to denote both DOCSIS and EuroDOCSIS (except where the difference between
them is significant), and uses the generic name MTA to denote any MTA type.
B2.10.1.2 CMTS (Cable Modem Termination System)

A CMTS is located at the head (upstream) end of a CaTV access network based on HFC
(Hybrid Fibre Coax) cable. It acts as a Layer 1 and Layer 2 bridge between the access
network and the IP backbone network, supporting:
! Mapping and co-ordination between two types of control signalling:
" NCS (Network Call Signalling), as used between the CS2000 GWC and the
MTA, which passes though the CMTS. NCS is a PacketCable protocol
defined in PKT-SP-MGCP-I10-040402 (or later issue found at
www.packetcable.com). It conveys SDP session description information as
well as NCS commands and parameters.
" DOCSIS signalling, as used between the CMTS and MTAs. This is relevant
only within the access network, and is not visible to the CS2000 GWC
(though it is affected by NCS from the GWC). EuroDOCSIS differs from the
North American standard (DOCSIS) in the following key areas:
# Modulation format, for which EuroDOCSIS uses ITU-T J83 Annex A.
# EuroDOCSIS uses different frequency split to separate upstream and
downstream directions: 8 MHz downstream and 5 to 65 MHz upstream
spectrum.
These two differences result in the use of slightly different Management
Information Bases (MIBs) for CMTS and MTA OAM&P.
Note: If the CMTS is to support CAC (Connection Admission Control) for DQoS,
it must also terminate COPS (Common Open Policy Service) gate control signalling
to/from the CS2000 GWC, as described in section D7.7 on page 317.
! Bearer connection mapping between two types of information flow:
" IP information flow across the backbone packet network
" DOCSIS information flow or QoS service flow across the HFC access
network
Both types of information flow are unidirectional packet sequences that can convey
multiple multimedia streams.
As with MTA gateways, CMTS functionality is largely generic, and a variety of CMTS
models may be used to provide it, depending on the type of MTA in use. See section
B2.10.2 for more details.

B2.10.2 Specific Gateway Types Supported

All MTA cable gateway types provide essentially the same functionality (as described in
section B2.10.1 on page 126) and have essentially the same characteristics (as
summarised in section B2.10.3 on page 129). Two MTA types are supported in ISN07:
! Motorola MTAs (see section B2.10.2.1)
! Arris MTAs (see section B2.10.2.2 on page 128).
B2.10.2.1 Motorola MTAs

Specific MTA models supported in ISN07 include the Motorola CG4500 and the
Motorola SBV4200, each of which has a DOCSIS version and a EuroDOCSIS version.
The EuroDOCSIS version of the CG4500 is known as the CG4500E.
An MTA is located at the subscriber (downstream) end of a CaTV HFC access network.
It supports analogue POTS line access for DTMF telephone sets and cable modem access
for other subscriber devices such as PCs. It comprises:
! Interfaces to the subscribers CPE
" Two independent RJ-11 sockets for telephone lines, supporting the
connection of handsets, fax machines and modems.
" 10/100BaseT Ethernet (RJ-45) and USB connectivity
Either or both types of connection can be used for a stand-alone PC or a
home/office network. The ports are bridged internally.
Note: CS2000 is not involved in providing this functionality in ISN07.
! A HFC interface to the cable access network, with support for DOCSIS and
PacketCable 1.0 protocols (including NCS)
! Codec capabilities: G.711, packet size 10ms
! Dynamic Quality of Service (DQoS) capabilities supported in conjunction with the
ADC Cuda 12000 CMTS.
Specific types of CMTS supported in ISN07 for use with Motorola MTAs are:
! ADC Cuda 12000 CMTS, which uses an ASIC-based HFC redundancy scheme for
its CMTS interface modules. This pairs two active interface modules to provide full
HFC redundancy without wasting resources on dormant standby CMTS interfaces
or external equipment.
! Motorola BSR64K CMTS
B2.10.2.2 Arris MTAs

Arris Touchstone Telephony Modem (TTM) models T102 and T202. These have slightly
varying physical characteristics but identical functional characteristics:
! Two subscriber line ports
! Support for data service using 10/100BaseT Ethernet or 12Mb/s USB.
DOCSIS and EuroDOCSIS versions of both the T102 and the T202 are available.
Arris TTM MTAs are deployed with the Arris Cadant C4 CMTS and edge router.


Listed characteristics apply equally to Motorola and Arris MTAs.

! VoIP

! GWC termination
HFC cable connection terminated on HFC port in MTA
Note: Interface between HFC cable and IP backbone is provided by CMTS.
! NCS / UDP / IP
! NCS is used to report the occurrence of relevant events on the line interface, e.g.
B2.10.3.3 Line Access

Characteristics of analogue POTS lines terminated on MTA:
! 2-wire
! Loop start
! DTMF in-band dialling
! Call progress signalling via in-band tones (except hook state changes and ringing)
! CLASS functionality (downloading digital data in-band) supported
Note: An MTA also provides an Ethernet/USB port for data access via cable modem,
but CS2000 is not involved in providing this functionality in ISN07.

An MTA line gateway is not directly connected to the IP backbone network. Instead, it is
connected to a HFC (Hybrid Fibre Coax) cable access network, which is in turn connected
to the IP backbone network via a CMTS (Cable Modem Termination System) and an edge
router. HFC cable terminated on MTA port supports three types of information flow (see
section B2.10.2.1 on page 128 for HFC network characteristics):
! NCS control connections between CS2000 GWC and MTA (NCS signalling
routed/relayed via CMTS and edge router)
! DOCSIS control connections between CMTS and MTA (terminated at CMTS)
! Bearer connections (DOCSIS packet flows converted to/from IP packet flows at
CMTS)

B2.11 CVX1800 Media Gateway for RAS

B2.11.1 Overview
CS2000 solutions use CVX1800 media gateways primarily to support dial-up access to
internet and/or intranet sessions, but CVX1800 can also support VoIP voice calls. Support
for dial-up data access is referred to as RAS (Remote Access Service). The ability of the
CVX1800 to support both RAS and VoIP is referred to as Universal Port (UP) capability.
For a functional view of RAS, see Chapter F17: RAS (Remote Access Service), and
particularly Figure 163 on page 721. See A89008121 for implementation details.
Note: CS2000 support for RAS has been tested and verified for deployment only in a
specific customer network, and is not generally available in ISN07.
The protocol used for signalling between the GWC and the CVX1800 UP gateway is
DSM-CC version 5.2, as described in Chapter D13: DSM-CC. CVX1800 management
functions are supported by a GUI provided by the CVXView management application.
When a CVX1800 receives an incoming call over a TDM-side CCS7 trunk (IUP/BTUP
or UK ISUP), CS2000 translations determine whether the call is a voice call or a RAS call.
In the case of a voice call, the terminating media gateway is identified and call setup
proceeds in the usual way. In the case of a RAS call, the CS2000 GWC uses DSM-CC to
tell the CVX1800 to connect the call to one of its modem ports for demodulation, and to
specify the internet / intranet destination (IP address and port number) with which a data
session should be initiated.
Note: RAS calls are single-ended, i.e. only an originating gateway is involved.
Pre-authorisation is performed by a CVX Policy Manager (CPM) attached to the
CVX1800. Caller authentication and authorisation is performed by a Remote Access
Dial-In User Services (RADIUS) server connected to the internet / intranet destination.
On the telephone network side, the CVX1800 uses E1 interfaces; on the data network side,
the CVX1800 uses Ethernet interfaces.
Figure 41 illustrates CVX1800 components and their functions at a logical level.
CVX1800
Packet network
CCS7 trunks to/from
TDM network
DACs (Digital SCC (System

Access Cards) MACs (Modem
Access Cards) Control Card)
supporting supporting
TDM-side E1 supporting
modem ports Ethernet links with Packet network
terminations packet network terminations
support both
bearer connections
and DSM-CC
4 x 1Gb/s packet bus control connections
800 Mb/s TDM bus with GWC
Four 18-slot CVX1800 shelves

can be housed in a frame
Figure 41: Logical configuration of a CVX1800

B2.11.2 CVX1800 Shelves and their Contents

A CVX1800 is a single-shelf unit with 18 slots for housing the following components:
! System Control Card (SCC)
The SCC provides CVX1800 system-level processing, and network ports for up to
three auto-sensing 10/100 Mb/s Ethernet connections to the packet network.
! Digital Access Card (DAC)
A DAC provides direct E1 connections to the PSTN or other TDM network.
! Modem Access Card (MAC)
A MAC provides modem ports to terminate calls from remote users who dial in
using an analogue modem.
Slots 9 and 10 in the CVX1800 chassis are reserved for redundant SCCs. DACs and
MACs can be housed in any of the remaining 16 slots (slots 1-8 and 11-18).
For internal communication, the CVX1800 uses two parallel buses:
! 800 Mb/s TDM bus
! Packet bus consisting of four parallel 1Gb/s buses
It is the capacity of the TDM bus that determines how many dial-up connections the
CVX1800 can support.
Note: There is also a cell bus for future expansion and emerging broadband technologies,
such as digital subscriber line (DSL), but this is not used in supporting RAS for CS2000.
B2.11.3 Configuration and Capacity

A CVX1800 chassis can be installed as a stand-alone unit on a flat surface, or in a shelf
in a standard 19-inch or 23-inch computer rack. Up to four CVX1800 shelves can be
houses in a NEBS-compliant 7-foot rack.
In support of RAS, one CVX1800 can handle up to 2,688 simultaneous calls. Four
CVX1800s in a 7-foot rack can handle up to 10,752 calls.
The maximum number of simultaneous voice calls that can be supported by a CVX1800
is less than the number of simultaneous RAS calls. The precise figure depends on card
configurations and engineering.
The CVX1800 uses DMS-CC messages to keep the GWC informed about the availability
of RAS modems, VoIP modems and HDLC terminations.
If no RAS modems are available, the GWC will not initiate any new RAS calls, but can
continue to initiate VoIP calls. Similarly, if no VoIP modems are available, the GWC will
not initiate any new VoIP calls, but can continue to initiate RAS calls. If no front-end
processor is available, no new calls of either type will be initiated.
When packet network call setup cannot be completed for an incoming call attempt
received by a CVX1800, CS2000 indicates this by sending back an REL message with a
release cause of CI_TEMPORARY_FAILURE (for a UK ISUP call) or
NTWK_OUT_OF_ORDER (for a BTUP call).

B2.11.4 Summary of CVX1800 Characteristics

! RAS
! VoIP

! GWC termination
10/100BaseT Ethernet terminated on SCC in MG9000
! DSM-CC / UDP / IP
! Not applicable. The CCS7 signalling used to set up and clear RAS and VoIP calls
is separately terminated on the CS2000 USP or FLPP.
B2.11.4.3 Bearer Access

! 64Kb/s CCS7 bearer channels

! 10/100 Mb/s Ethernet interface terminated on SCC in CVX1800

Chapter B3 CS2000 Support for Media
Servers
B3.1 Introduction
A media server is a centralised resource for the delivery, management and manipulation
of packet-based media streams and services over the backbone network.
Note: This CS2000 Product Description is not intended to be the primary source of
information about supported media servers and their capabilities. Media servers are
products in their own right, and for detailed, definitive information about the capabilities
of a given server type it is necessary to refer to its product documentation. In the event of
any discrepancy between statements made in this chapter and statements made in a media
servers product documentation, the server product documentation should take
precedence.
In ISN07, CS2000 supports the following types of media server:
! AudioCodes MS2000 Series media servers, which are described in section B3.2 on
page 135. Two models are available:
" The MS2010, which is for use in VoIP solutions
" The MS2020, which is for use in VoATM (VoAAL2) solutions
! UAS (Universal Audio Server), which is described in section B3.3 on page 138.
MS2000 Series media servers have been introduced in ISN07 as compact, enhanced
replacements for the Universal Audio Server (UAS). Deployed UASs are still supported,
but MS2000 Series units are to be used for all new media server deployment.
Although logically and functionally a media server is a centralised resource, the
MS2000/UAS is in practice co-located with the CS2000 and connected to the CS2000 CS
LAN.

Communication Server Capabilities Hardware CS2000 Support for Media Servers
Both types of server support the following capabilities:

! Packetised announcements provided via media gateways to call parties in response
to CS2000 requests. The CS2000 itself can specify which announcement to apply
in a given situation, but cannot actually provide it because it does not directly
support bearer connections.
Note: In general, tones are provided by gateways directly to their TDM-side trunks
and lines, not by a media server. Both the MS2000 Series and the UAS can,
however, provide tones across the packet network if this is required for a particular
customer solution.
! Packet-based audio conference circuits for multi-party calls across the packet
network.
! BCT (Bearer Channel Tandem) functionality for the LI (Lawful Intercept)
regulatory service, which allows packet network bearer connections to be
monitored by an LEA (Law Enforcement Agency). See section F14.2.2 on page 699
for a full description of the role of the MS2000/UAS in supporting CR functionality
for LI.
Media server operation is controlled by a CS2000 Audio Controller (AC) GWC. The AC
GWC uses the H.248 protocol to request the playing of an announcement, the setting up
of a conference call or the initiation of LI monitoring. See section B1.4 on page 53 for
more information about CS2000 GWCs. See Chapter D3: H.248 for a description of the
H.248 protocol and examples of its use.

CS2000 Support for Media Servers Hardware Communication Server Capabilities
B3.2 AudioCodes MS2000 Series (MS2010 / MS2020)

B3.2.1 Overview
AudioCodes MS2000 Series media servers have been introduced in ISN07 as compact,
enhanced replacements for the Universal Audio Server (UAS) described in section B3.3
on page 138. Deployed UASs are still supported, but MS2000 Series units will be used
for all new media server deployment. Two models are available:
! The MS2010, which is for use in VoIP solutions
! The MS2020, which is for use in VoATM (VoAAL2) solutions
In logical terms, both units provide the same media server functionality, as described in
the previous section, but there are some differences in configuration and capabilities.
Table 4 summarises the similarities and differences between MS2010 and MS2020 media
servers.
Table 4: Characteristics of MS2000 Series media servers

Characteristic MS2010 (for VoIP) MS2020 (for VoATM)
1U (1.75") chassis 2U (3.5") chassis
Shape and size
Designed for horizontal mounting in standard 19" frame
Logical modules Two logically separate media server modules,
per chassis each with its own IP address and MAC address
Technology AudioCodes IPM-1610 AudioCodes TP-6310
Up to six MS2010s in
CS2000-Compact CCF; Up to five MS2020s
up to ten MS2010s in
in SAMF PTE2000 frame
CS2000 housing SAMF PTE2000 frame (CS2000-Compact
(XA-Core configuration and XA-Core configurations)
or additional capacity
for CS2000-Compact)
H.248 signalling to/from AC GWC
via Ethernet connections with CS LAN PP8600s
Connections Terminations for
Bearer connections with backbone
direct STM-1 carrier corrections
network via Ethernet connections
with backbone network
with CS LAN PP8600s
for bearer traffic using AAL2 / ATM
120 ports per module; 240 ports per module;
240 ports per chassis 480 ports per chassis
Capacity 240 simultaneous 480 simultaneous
announcements [1] announcements [1]
80,000 BHCA 60,000 BHCA
Software load [2] AMS 4.4
Software order code MS200070 MS2A0070
[1] There is also an overall limit of 1280 on the number of simultaneous annluncements that can be
supported by a given AC GWC.
[2] Software loads for MS2000 Series media servers provide all the capabilities of UAS load UAS08,
as supported in ISN06.

Figure 42 illustrates the physical and logical configuration of MS2000 Series MS2010
and MS2020 media servers.
MS2010 media server (as used in VoIP solutions)

Logical ports (120 per module)
for terminating packetised IPM-1610 cPCI board
bearer connections supporting two logical
media server modules
Module 0
Local storage Dual redundant 100BaseT Ethernet ports

for approx. connected to CS LAN PP8600s for:
40 minutes H.248 signalling to/from Audio
of audio Module 1 Controller GWC via signalling VLAN
Bearer connections via bearer VLAN
MS2020 media server (as used in VoAAL2 solutions)

Logical ports (240 per module)
for terminating packetised TP-6310 cPCI board
bearer connections supporting two logical
media server modules
Dual redundant 100BaseT Ethernet

ports connected to CS LAN PP8600s
Module 0 for H.248 signalling to/from Audio
Controller GWC via signalling VLAN
Local storage
for approx.
40 minutes
of audio Module 1
Direct dual STM-1

bearer connections with
the external backbone
packet network
Figure 42: Physical and logical configuration of MS2000 Series media servers


! VoIP
B3.2.2.2 GWC-MS2000 Signalling

! Dual redundant 10/100BaseT Ethernet connection between GWC and media server
Media / bearer control protocols:
! H.248
Call control protocols:
! N/A

Media servers do not have to support PSTN / TDM access directly. They communicate
only with GWCs and gateways, and only via the packet backbone network.

MS2010 (VoIP):
! RTP / RTCP over UDP / IP via CS2000 bearer VLAN and CS LAN PP8600s
MS2020 (VoATM):
! RTP / RTCP over direct AAL2 / ATM connections with backbone network
Codecs:
! G.711 with 10ms or 20ms packetisation
! G.729a/b with 10ms or 20ms packetisation
B3.2.2.5 OAM&P
! Provisioning via APS (Audio Provisioning Server). One APS can support
co-ordinated provisioning for multiple media servers.
! Management/control via CLUI (Command Line Uer Interface) provided by CS2000
IEMS (Integrated Element Management System). The IEMS can provide
management capabilities for all the media servers belonging to a CS2000.
B3.2.2.6 Language support

English, German, Italian, French, Netherlands Dutch, Belgium Dutch, Portuguese,
Japanese, Mandarin, Cantonese, Korean, Malay, Tagalog, Thai, Hebrew, Czech, Greek,
Turkish, Vietnamese and four variants of Spanish.
B3.2.2.7 Feature Support

! Announcements
! Conference calls with up to 30 participants, conference chaining
! Bearer Channel Tandem (Lawful Interception)

B3.3 Universal Audio Server (UAS)

B3.3.1 Overview
UASs are housed in 16-slot SAM shelves with capabilities similar to those of the SAM21
shelves used to house GWCs, and SAM16s are connected to the PP8600s of the CS LAN
in the same way as SAM21s. In terms of CS2000 network architecture, however, there are
two logical UAS units per SAM16 shelf, and each one subtends a GWC and is controlled
by the GWC in the same way as a media gateway.
As explained in section B1.3.1.3 on page 43, the UAS is connected to the call processing
VLAN of the CS LAN for signalling purposes. The way in which UAS bearer traffic is
handled depends on whether the backbone network is IP or ATM, as follows:
! If the backbone network is IP, a UAS bearer VLAN is configured off the CS LAN
PP8600s to handle UAS bearer traffic (the CS LAN otherwise handles only
signalling).
! If the backbone network is ATM, the UAS can support direct ATM bearer
connections that bypass the CS LAN PP8600s.
CS2000 UAS configurations are provisioned using N+1 sparing, i.e. N+1 active
load-sharing UAS units handling a workload engineered for N units. In effect, this means
that a spare UAS unit is available, which ensures that the configuration can handle the full
workload if any unit should fail.
The number of UASs that can be supported by a CS2000 is solution-dependent:
! Trunk-only VoIP or VoATM solution: maximum 8 UASs
! Integrated VoIP solution including line access: maximum 6 UASs
UAS provisioning is supported by the Audio Provisioning Server (APS). This is an Oracle
database application that runs on a dedicated Sun Netra server under the control of a
remote provisioning client. One APS can support the co-ordinated provisioning of
multiple UASs. See section G3.6 on page 747 for further information.

B3.3.2 UAS Components and Configuration

The UAS comprises the following main functional elements:
! A CPU card that provides processing power and terminates a connection with the
PP8600 router for signalling over the CS LAN (e.g. H.248 to/from the audio GWC).
This is a dual-port network interface configured in active/standby mode, with one
externally visible IP address. If the active link fails, the software transparently
switches the IP address to the standby port and makes it active. For reliability, the
two interfaces are connected to different CS LAN PP8600 routers.
! Digital Signal Processor (DSP) cards that provide logical ports for terminating
individual media streams. The type of DSP card used depends on the type of
backbone packet network in use:
" For IP, the UAS uses CG6000 DSP cards.
In addition to logical media stream terminations, CG6000 cards provide
Ethernet 100BaseT ports for external network connections made via the
PP8600 and the CS LAN. Each CG6000 card supports a dual-port network
interface configured in primary/secondary mode, with one externally visible
IP address.
If the primary interface detects a network problem, the CG6000 card will
automatically switch traffic processing to the secondary interface. Once the
network has been re-established on the primary interface, the CG6000
automatically switches traffic back to the primary.
For reliability, the two CG6000 ports are connected to different CS LAN
PP8600 routers.
" For ATM, the UAS uses AG4000 DSP cards.
AG4000 cards do not support external network connections. Instead, a UAS
configured for use with ATM must be provisioned with a PA200 card set,
which includes an R200 transition module that provides an STM-1 port for a
direct ATM connection to the external network.
! 36-Gbyte disk drive providing storage capacity for 780 hours of uncompressed
audio files. When the UAS receives a request to play an announcement, the UAS
CPU retrieves and assembles the elements of the announcement, then sends it to a
DSP card to be processed and transmitted over the IP or ATM backbone network.
See Figure 43 on page 140 for an illustration of the alternative UAS configurations used
for IP and ATM.

Figure 43 illustrates the alternative UAS configurations used for IP and ATM.
UAS configured to support VoIP
CPU
Connection with PP8600 for
signalling over the CS LAN
(e.g. H.248 to/from the
audio GWC)
Logical ports (up to 120)

for terminating packetised CG6000
bearer connections DSPs
Bearer connections with the
external backbone packet
network; CG6000 100BaseT
ports are connected to the
PP8600 to support bearer
connections via the CS LAN
36 Gbyte disk drive providing
storage capacity for 780 hours
of uncompressed audio files
UAS configured to support VoATM
CPU
Connection with PP8600 for
signalling over the CS LAN
(e.g. H.248 to/from the
audio GWC)
Logical ports (up to 128) AG4000

for terminating packetised DSPs
bearer connections
PA200 card set
PA200 R200
card TM Direct STM-1 bearer
connection with the external
backbone packet network
36 Gbyte disk drive providing

storage capacity for 780 hours
of uncompressed audio files
Figure 43: Alternative UAS configurations (functional view)

The UAS is built on the Nortel SAM16 platform, which is so called because it is a
single-shelf Service Application Module (SAM) with 16 slots for housing PCI-based
cards. A SAM16 consists of two 8-slot subsystems or domains, each of which is organised
as follows to provide UAS functionality:
! One slot for the host controller CPU (700MHz 5370 processor)
! One slot for a Hot Swap Controller (HSC)
! The remaining slots are available for cPCI I/O cards providing DSP functionality
and/or interface terminations for bearer connections. Assuming the 5370 processor
is used, these are used as follows:
" For IP, all six slots are available for CG6000 DSPs
" For ATM, one slot is used for a PA200 STM-1 card, leaving five slots
available for AG4000 DSPs
B3.3.3 DSP Capabilities and Capacity

The number of ports supported on a DSP card depends on factors such as network type
(ATM or IP), packetisation size (10ms or 20ms) and features requested (announcement,
conference or monitoring). One DSP port is used for every announcement played to a call
party, four ports are used for a monitored call, and one port is used for each party
connected to a conference call.
Note: There is a level of abstraction between logical endpoints known to the audio GWC
and physical resources in the UAS. The ports on the DSP cards housed in a UAS make up
a pool of specialised resources for use by the GWC, but the GWC cannot identify or
access specific DSP ports or cards; instead, it specifies its requirements in terms of logical
audio terminations to participate in a call, leaving it to the UAS to assign a specific
physical resource to each audio termination. GWC requests are made via H.248, as
described in section D3.6.3 on page 269.
The CG6000 used for IP can support all UAS features (announcements, conferences and
monitoring). Port availability/usage per CG6000 is as follows:
! Announcements
Maximum 78 ports
! Conferencing
Maximum 120 ports with 20ms packetisation
Maximum 90 ports with 10ms packetisation.
! Lawful Interception
Maximum 90 ports
The AG4000 used for ATM supports can support 128 ports for announcements without
any limitations on packetisation. It can also support monitoring.

In ISN07, the capacity limits for a UAS in a CS2000 configuration are:

! Maximum number of simultaneous announcements per UAS:
" 468 simultaneous VoIP announcements (six CG6000 DSP cards supporting
78 ports each).
" 640 VoATM announcements (five AG4000 DSP cards supporting 128 ports
each).
There is also an overall limit of 1280 on the maximum number of UAS resources
that can be controlled by an Audio Controller GWC.
! Maximum BHCA per UAS: 60,000 (700MHz 5370 CPU)
! Maximum BHCA per DSP card: 20,000 for both the CG6000 and the AG4000
B3.3.4 Hardware Packaging

In ISN07, UAS hardware is housed in the following PTE2000 cabinet configuration:
! One or more SAMF cabinets (RX51HA), each housing a 5370 processor and up to
six UASs on three shelves.
! One OAME cabinet (RX51KE) housing the following OAM&P components:
" Sun Netra 240 for UAS EM and APS.
" One or more Rose KVM switches for communication between UASs in
different cabinets. (depending on number of SAMF cabinets)
" NEW keyboard / monitor
A 5370-based UAS configuration can support up to 60,000 BHCA.

! VoIP
! VoATM
B3.3.5.2 GWC-UAS Signalling

! 10/100BaseT Ethernet connection between GWC and gateway
! H.248
! N/A


The UAS does not have to support PSTN / TDM access directly. It communicates only
with GWCs and gateways, and only via the packet backbone network.

VoIP bearer connections
! RTP / RTCP over UDP / IP via CS2000 bearer VLAN and CS LAN PP8600s
ATM bearer connections
! RTP / RTCP over direct AAL2 / ATM connections with backbone network
Codecs:
! G.711 with 10ms or 20ms packetisation
! G.729a/b with 10ms or 20ms packetisation
B3.3.5.5 OAM&P
! Provisioning via APS (Audio Provisioning Server). One APS can support
co-ordinated provisioning for multiple UASs.
! Management/control via UAS Manager, which provides logs, alarms, OMs,
configuration management and state indications. One UAS Manager can serve as
the Device Manager for all the UASs beonging to a CS2000.
B3.3.5.6 Language support

English, German, Italian, French, Netherlands Dutch, Belgium Dutch, Portuguese,
Japanese, Mandarin, Cantonese, Korean, Malay, Tagalog, Thai, Hebrew, Czech, Greek,
Turkish, Vietnamese and four variants of Spanish.

Features supporrted for VoIP:
! Announcements
! Conference calls with up to 30 participants, conference chaining
! Bearer channel tandem (Lawful Interception)
Features supporrted for VoATM:
! Announcements
! Bearer channel tandem (Lawful Interception)

Chapter B4 CentrexIP Remote Clients
and the CentrexIP Client
Manager (CICM)
This chapter describes the hardware used to provide VoIP support for remote CentrexIP
clients served by CS2000. It is organised into the following sections:
! Section B4.1: Network Configuration for CentrexIP Client Access
! Section B4.2: CentrexIP Clients and their Capabilities on page 146
! Section B4.3: CentrexIP Client Manager (CICM) on page 149
B4.1 Network Configuration for CentrexIP Client

Access
CS2000 provides VoIP support for two types of CentrexIP client (see section B4.2 on
page 146 for a more detailed description):
! Etherset clients
IP-enabled Ethernet telephone sets with a large display and programmable softkeys.
! Soft clients
PCs running a telephony client application, with speech transmission and reception
supported via a headset attached to the PC and call control capabilities provided by
a screen-based GUI.
perceives the CICM as a large gateway and CentrexIP clients as lines served by CICM
gateways, but the CICM is not a media gateway in MEGACO terms because it handles
only signalling traffic, not media streams. It can be regarded as a terminal server, and its
role is similar to that of a GWC controlling multiple small CPE line gateways. CICMs are
connected to the CS2000 CS LAN, and communicate with their CentrexIP clients over the
packet backbone network using the UniStim protocol described in Chapter D6: UniStim.
See section B4.3 on page 149 for a more detailed description of the CICM.
Each CICM subtends and is controlled by a CS2000 GWC, which communicates with the
CICM via the CS LAN by means of the H.248 protocol described in Chapter D3: H.248.
The GWC in turn communicates with the CS2000 Core, which supports call processing

CentrexIP Remote Clients Hardware Communication Server Capabilities
for CentrexIP clients as if they were legacy business sets controlled via the proprietary
P-phone interface.
As a large line gateway, a CICM can share a GWC with other gateways of the same type,
i.e. another CICM or an MG9000, but not with small CPE line gateways.
Figure 44 illustrates the network configuration used by CS2000 to provide VoIP support
for CentrexIP clients.
CS2000 exercises control over CS2000 CS2000 Core

remote CentrexIP clients using three CS LAN
types of signalling:
Signalling between CS2000 Core
and the GWC that controls the
CICM emulates P-phone
signalling for business sets.
H.248 signalling is used between GWC
the CICM GWC and the CICM. for CICM
UniStim signalling is used
between CICM and remote
CentrexIP clients.
CentrexIP Client
Manager (CICM)
Perceived by
CS2000 as
large gateway
Etherset client (i200x):
IP-enabled Ethernet
phone with display
and function keys H.248 P-Phone
Dual PP8600s
Enterprise network IP core network

UniStim
Bearer connections for VoIP are
routed across the core network;
they are not handled by the CICM
Bearer connections for additional media

streams , e.g. to/from MCS5200, can be
co-ordinated with VoIP for multimedia
CentrexIP soft client (m6350):
Speech transmission and Bearer connections for
reception via headset. non-VoIP-related data sessions
Call control via CentrexIP client are independent of CS2000
application GUI.
Figure 44: CS2000 support for CentrexIP line access

Communication Server Capabilities Hardware CentrexIP Remote Clients
B4.2 CentrexIP Clients and their Capabilities

This section describes the characteristics and capabilities of the CentrexIP remote clients
supported by CS2000 in ISN07. It is organised as follows:
! Section B4.2.1 describes the characteristics and capabilities of Etherset clients,
which are IP-enabled Ethernet phones.
! Section B4.2.2 on page 147 describes the characteristics and capabilities of
PC-based soft clients.
! Section B4.2.3 on page 148 describes characteristics and capabilities that are
common to both types of CentrexIP client.
B4.2.1 i200x Etherset Characteristics and Capabilities

An Etherset is an IP-enabled Ethernet phone. It uses a large display and programmable
softkeys to support quick and easy access to capabilities such as multiple directories,
multimedia mailboxes and voice recognition.
Three types of Nortel Networks Etherset are supported in ISN07:
! i2001
! i2002
! i2004
These all support the same basic functions, but the specific capabilities they offer (number
of function keys, size of screen display, menus) increase from the low-cost, entry-level
i2001 to the fully featured i2004. In addition, the range of function keys supported by a
i2002 or i2004 can be further extended by equipping it with a key expansion module.
The CICM controls i200x Ethersets by means of the UniStim protocol defined in NIS
D201-1. This is a Nortel Networks protocol, but is available under licence to other
equipment vendors who wish to design and manufacture CentrexIP terminals that support
interoperability with Nortel Networks products such as CS2000.
The basic functions common to all types of i200x Etherset are as follows:
! Ethernet connectivity
The users desktop Etherset and PC are connected to the network using a single port.
The i2002/4 has a built-in Ethernet 10/100BaseT Layer 2 switch that splits the
network cable into separate feeds, providing an additional RJ-45 port for the PC
connection. The internal Ethernet switch gives fixed, hardware-based priority to the
voice port to ensure that high-quality voice service is always available. (The i2001
does not have an integrated switch.)
! Establishing communication with the CICM
To enable an i200x terminal to provide services for a particular end user, that user
must log in. When a terminal is powered on or reset, it sends an unsolicited UniStim
message to the CICM to open a pinhole in the enterprise NAT/firewall, which
enables the CICM to discover the public NAT/firewall address that it needs to use
to send return packets to the terminal. The login process then determines the DN for
which the i200x is to provide VoIP support, and causes the CICM to configure the
terminals capabilities in accordance with the profile of the logged-in user, e.g. by
downloading an appropriate set of feature key assignments.

B4.2.2 Soft Client Characteristics and Capabilities

The purpose of a PC-based CentrexIP soft client is to make advanced telephony features
available to end users at their desktops via the same PC they use for other tasks. Speech
transmission and reception is supported via a headset attached to the PC, while incoming
and outgoing calls are controlled via a screen-based GUI provided by a telephony client
application running on the PC. Use of a USB headset is recommended, to ensure that
voice quality is consistent regardless of the PCs sound card and audio configuration.
Incoming ringing and ring-splash are implemented in two ways simultaneously:
! A pop-up dialogue box
! An audio prompt on the client PC
The capabilities available to the end user are the same as those available to users of the
i200x terminals discussed in section B4.2.1 on page 146, but they are controlled by
pointing and clicking in a dedicated PC window rather than by means of physical keys.
Figure 45 indicates the capabilities provided via a soft client GUI window.
Display, e.g.
for CLI of
incoming call
Feature keys
with
dynamically
Standard assigned
numeric functons
keypad for
point-and-clic
k dialling
Figure 45: CentrexIP soft client user interface (as displayed in PC window)
The primary purpose of a PC-based soft client is to complement a users desktop phone
by providing point-and-click control over call handling. Typically, however, the speech
path is routed through the users telephone set, as this offers a quality of service superior
to that of a PC.
A further advantage of a PC-based soft client is that it can be used to extend the
capabilities of a business users desktop line to wherever that user may be. For example,
a user can log in to the corporate telephone network from a hotel room using a laptop, or
from a desktop PC at home. In either case, the fact that the soft client is provisioned with
the same telephone number as the desktop phone means that incoming calls will
automatically be redirected to the CentrexIP soft client, and that outgoing calls will be
handled in exactly the same way as if they originated from the desktop phone. The
standard set of non-VoIP capabilities supported by the corporate network is also available,
e.g. email.
The login process establishes an IP connection with the CICM, determines the DN for
which the soft client is to provide VoIP support, and causes the CICM to configure the
clients capabilities in accordance with the profile of the logged-in user, e.g. by

Support for the standard TAPI interface makes it possible for CentrexIP soft clients to be
connected to TAPI-aware applications such as contact databases or customer care
systems, and to use these to make calls.
B4.2.3 Common Characteristics and Capabilities

The following list describes characteristics and capabilities that are common to the i200x
clients described in section B4.2.1 on page 146 and the PC-based soft clients described in
section B4.2.2 on page 147.
! Control protocol
The protocol used by the CICM to control CentrexIP client operations is UniStim,
as described in Chapter D6: UniStim. This runs over UDP with a reliability layer.
! Dynamic IP addressing with a standard DHCP server
Dynamic endpoint duscovery is supported for CentrexIP clients. The CICM
automatically detects the network association for each terminal that is connected to
it, which allows users to roam across different networks and still obtain service.
When a terminal connects to the CICM from behind a NAT, the source IP address
of packets from the terminal will be the public address of that NAT, which can be
used by the CICM to associate the terminal with the subnetwork to which that NAT
belongs. The GWC can then be notified of the endpoint to subnetwork mapping via
H.248, which enables it to make decisions about media proxy requirements.
! Codec support for media streams:
" G.711 (A-law and/or -law)
" G.729 a/b
! Tone generation (see also section B4.3.4 on page 151)
Audible tones to be played back to the user, e.g. dialtone and ring tone, are
generated by i200x terminals themselves.
Each tone available for playback is stored by the i200x terminal as an audio stream.
The stream content comprises up to four frequency pairs and cadences. An i200x
terminal can store up to 16 tone streams, each with its own stream ID.
Tone information is stored at the CICM in the form of administrator-defined tone
profiles, each comprising a complete set of tones. The tone set to be made available
to a given user is determined by the tone profile associated with that user.
When CS2000 determines that a tone needs to be played, H.248 signalling from the
GWC determines the tone ID, the CICM selects the appropriate tone profile, and the
i2000x terminal plays the appropriate audio stream.
! Dynamic feature key assignment
It is the CICM that determines which capabilities are available via i2000x function
keys. As the range of capabilities varies depending on the state of the terminal, the
only features with lamps on are those that can be activated in the current state.
Features are categorised as follows:
" DN features that control active/idle status, e.g. keys for Primary / Secondary
DN or automatic DOD line.
" Features that can be used only when there is an active call, e.g. Call Transfer.
" Features that can be used only when there is not an active call, e.g. Call
Forward.
" Features that are always usable regardless of whether there is an active call.

B4.3 CentrexIP Client Manager (CICM)

B4.3.1 CICM Hardware
With effect from ISN07, the CICM is based on Motorola CompactPCI cards equipped
with Intel Pentium processors. Like a CS2000 GWC, a CICM is a unit that logically
comprises two cPCI cards operating in hot standby mode, with a backup unit ready to take
over from the active unit immediately in the event of a failure. Also like a GWC, CICM
cards are housed in SAM21 shelves, as described in section B1.4.4: GWC Packaging on
page 57. The two cards that make up a CICM can be housed in any of the GWC slots in
a SAM21; they need not be in adjacent slots, i.e. although a CICM logically comprises
two cards, it is not physically a twin-card unit.
Note: There was a pre-ISN07.0 implementation of the CICM as a single-shelf unit based
on the same SAM16 technology used for the UAS. This was for use in customer trials,
and is not intended for general deployment. It provided essentially the same functionality
as the ISN07 implementation, but significantly less capacity and resilience.
A SAM21 is a Motorola cPCI card cage, the backplane of which provides a cPCI bus for
communication between the cPCI cards housed in the card cage. Access to the
PP8600-based CS LAN is supported by Ethernet 10/100BaseT ports on the cards
themselves. Three main types of communication are supported for the CICM:
! Communication between the CICM and the CS2000 GWC that controls it takes
place over the CS LAN and uses the H.248 protocol described in Chapter D3:
H.248.
! Communication between the CICM and its CentrexIP clients traverses both the CS
LAN and the backbone packet network, and uses the UniStim protocol described in
Chapter D6: UniStim.
! Communication between the CICM and the SAM21 Shelf Controller (SC) that
provides control and co-ordination for the shelf takes place via the cPCI bus.
Each device known to the SAM21 SC is listed in a configuration file that maps each PCI
Vendor ID on to a device entry defining the characteristics of the corresponding card type.
It is these device entries that enable the SC to perform status tracking and drive
maintenance actions for each card. CICM cards are denoted as MCPN5385 devices in the
configuration file.
CICM Element Manager (EM) capabilities are provided by a CICM EM that runs on a
separate 5385 card (typically duplicated for redundancy) that is housed in a SAM21 shelf
in the same way as CICM card pairs. A given CS2000 configuration requires only one
CICM EM to provide OAM&P support for all its CICMs. The CICM EM is controlled by
a management client running on a Windows PC.
Logically, a CICM is a single entity that can be accessed via a single IP address.
Physically, however, a CICM consists of two separate cards, each of which has its own
10/100BaseT Ethernet port. At a given moment, one of these cards is active and the other
is inactive, and the externally visible IP address is associated with the active card. The
operation of the inactive CICM card/unit is synchronised with that of the active unit, so
that in the event of a problem the inactive unit can take over from the active unit; the IP
address is then associated with the newly active card. The IP addressing and SWACT
(Switch of Activity) support are essentially the same as for a GWC, as described in section

B1.4.5.1: GWC Configuration and Operation on page 60. For CICM, the mechanism
referred to as Dual Node Redundancy (DNR) and the process as hitless failover.
The hardware characteristics of the Motorola 5385 controller cards used as the platform
for the CICM are as follows:
! 1.2GHz Pentium processor
! Up to 2Gbytes of 266MHz double data rate (DDR) SDRAM
! PCI-X internal bus for high speed on-board communication
! Dual GigE interfaces
B4.3.2 Capacity
One CICM can support up to 3050 CentrexIP clients. These are provisioned on the
CS2000 Core as lines served by large line media gateways and belonging to line groups.
In call processing terms, the CS2000 Core perceives CentrexIP clients as equivalent to
lines serving business sets, and controls their operation by means of the proprietary
P-phone signalling described in NIS S106-2.
As described in section C2.7.1 on page 196, the line group mechanism permits the
definition of logical frame and unit numbers for use in identifying lines. These provide
information equivalent to that used in defining the physical location of slots housing
traditional line cards.
The maximum number of lines in a line group is 1024. At least three line groups must
therefore be defined to support access to the maximum number of 3050 CentrexIP clients
that can be supported by a CICM. All the line groups used to support access to a given
CICMs clients must be controlled by a single GWC.
A given CICM line group can support access to CentrexIP clients belonging to different
enterprise networks. The CICM automatically detects the network association for each
terminal that is connected to it, which allows users to roam across different networks and
still obtain service. See section B4.3.3 for more details.
B4.3.3 Support for Multiple Enterprise Networks

Each CICM maintains a subnetwork mapping table that is used in deciding whether NAT
traversal is required for calls involving its CentrexIP clients. This mapping table
associates each CICM-controlled endpoint (i.e. CentrexIP client) with one of the
subnetworks known to its controlling GWC.
Each NAT is described as a subnetwork of the public network to which the CICM is
connected. For example, a NAT with a single address is described as a sub-network of one
address (mask is 255.255.255.255). The entries in the CICM subnetwork mapping table
also provide information about NAT-specific settings such as the UDP lease timeout.
When a terminal connects to the CICM from behind a NAT, the source IP address of
packets from the terminal will be the public address of that NAT. This can be used by the
CICM to associate the terminal with the subnetwork to which that NAT belongs. The
CICM uses H.248 to inform its controlling GWC of the endpoint to subnetwork mapping,
which enables the GWC to decide whether media proxy insertion is required for a given
call.

B4.3.4 Tone Support and Toneset Profiles

In the CS2000 architecture, tones are generated and played back by media gateways,
typically in response to CS2000 Core requests that are relayed to gateways by their
GWCs. This approach conserves network bandwidth, and allows CS2000 call processing
to specify tones to be played by means of logical tone identifiers, leaving it to individual
gateways to play back tones with the appropriate characteristics (frequency, level and
cadence) for the endpoint in question.
Tone generation for CentrexIP clients follows the same basic principles, but there are
some variations because the CICM is not actually a media gateway, and therefore cannot
handle bearer connections or provide tones. Audible tones to be played back to the user,
e.g. dialtone and ring tone, are generated by CentrexIP clients themselves.
Each tone available for playback is stored by the CentrexIP client as an audio stream. The
stream content comprises up to four frequency pairs and cadences. Each client can store
up to 16 tone streams, each with its own stream ID.
Tone information is stored at the CICM in the form of administrator-defined tone profiles,
each comprising a complete set of tones. The tone set to be made available to a given user
is determined by the tone profile associated with that user. The association between tone
profiles and users can be set up at any of three levels:
! User (tone profile associated with a specific user)
! User profile (tone profile associated with all user of a given type)
! Gateway default (one tone profile for all users served by CICM)
The most detailed tone profile association that has been defined is used, i.e. a user-specific
tone profile takes precedence over one associated with a user profile.
When CS2000 determines that a tone needs to be played, H.248 signalling from the GWC
determines the tone ID, the CICM selects the appropriate tone profile, and the CentrexIP
client plays the appropriate audio stream.

B4.3.5 Codec Negotiation using CICM Audio Profiles

Codec negotiation for CentrexIP clients is controlled at the CICM level by means of an
administrator-defined audio profile. This profile specifies the preferred and default codecs
supported by the CICM, which apply to all the CentrexIP clients supported by that CICM.
For a given VoIP call to/from a CentrexIP client, the GWC controlling the CICM uses
SDP conveyed in-line with H.248 to inform the CICM of the preferred and default codecs
(or only codec) supported by the remote endpoint for the call. H.248(SDP) signalling is
also used by the CICM to inform the GWC of its preferred and default codecs. The result
of the negotiation process, i.e. the codec used for the call, reflects the intersection of
CICM and GWC capabilities, as summarised in Table 5.
Table 5: Codec negotiation for CICM

Codec choicet in Codec choice Result of negotiation
CICM audio profile indicated by GWC (codec used for call)
G.729 only Call attempt cleared
G.729 then G.711 G.711
G.711 only
G.711 then G.729 G.711
G.711 only G.711
G.729 only G.729
G.729 then G.711 G.729 then G.711 [2]
G.729 then G.711 [1]
G.711 then G.729 G.711
G.711 only G.711
[1] G.711 is the only codec accepted as a default by the GWC.
[2] As both can be supported, the choice is left to the remote GWC/endpoint.

Chapter B5 Media Proxies
A media proxy (strictly speaking, a media transport proxy) is a network element that
terminates and re-originates the transport layer for media traffic. It acts as an intermediary
in a call between two packet network endpoints when the media stream for the call is
routed through one or more Network Address Translators and NAT traversal is therefore
required. Section B5.1 discusses media proxy functionality and NAT traversal in generic
terms. Section B5.2 on page 156 describes the capabilities of the RTP Media Portal, which
is the media proxy implementation supported by CS2000 in ISN07.
B5.1 Media Proxy Functions

B5.1.1 Network Address Translator (NAT) Functionality
A media proxy is a network element that acts as an intermediary in a call between two
packet network endpoints when NAT traversal is required for the calls media stream. The
media proxy examines incoming packets on each of its ports to determine their origin, and
can thus work out the destination to which return packets in the other direction should be
sent. Two media proxy ports are used in handling a typical call, each presenting an
interface to one of the endpoints involved in the call, and there is a connection across the
media proxy between the two ports to support end-to-end communication between the
two packet network endpoints.
The necessity for using a media proxy on a packet network call arises when one of the call
endpoints is behind a NAT (Network Address Translator), typically because it belongs to
a private network that is kept secure from the carriers public network. The carriers
public network is actually a private network owned and operated by the carrier, but it is
described as public because it can be accessed by all of the carriers customers to support
communication between them, including customers served by different private networks;
it is sometimes referred to as a DMZ (De-Militarised Zone). For packets that originate
from a private network endpoint and traverse the carriers public network, a NAT changes
the originating IP address. Instead of the private IP address of the endpoint, which is not
made visible over the public network, the originating IP address of packets routed through
the NAT is the public network address of a port on the NAT. The NAT performs mapping
or binding between such externally visible public network addresses and the private
addresses used within the private network.

Communication Server Capabilities Hardware Media Proxies
Note: If translation is applied to ports as well as to IP addresses, the device is referred to

as a NAPT (Network Address and Port Translator). As the principles involved are the
same, this chapter simply uses the term NAT except where it is necessary to make a
distinction between NAT and NAPT.
B5.1.2 NAT Traversal
B5.1.2.1 NAT Traversal for Signalling

To support NAT traversal for signalling traffic, media gateways and other hosts that are
located behind a NAT must:
See section D8.4.2 on page 322 for information about the message sequence used to
support NAT traversal for the MGCP signalling used to control customer LAN gateways.
See section D6.4 on page 307 for information about the command sequence used to
support NAT traversal for the UniStim signalling used to control remote CentrexIP
clients.

Media Proxies Hardware Communication Server Capabilities
B5.1.2.2 NAT Traversal for Bearer Traffic

For VoIP, bearer connections across the packet network are established between
RTP/RTCP endpoints, i.e. ports on media gateways. During call establishment, each
gateway uses device/media control signalling to inform its GWC of the bearer capabilities
it can support, e.g. codecs and packetisation rates. It also tells the GWC the IP address and
RTP port number to which bearer packets destined for it should be sent.
Bearer capability and media address information is conveyed embedded in device/media
control signalling, either in SDP session description lines in MGCP messages or in
UniStim commands. A problem arises if NAT is in use, however, because media address
information embedded in signalling packets is of no use to a remote terminating endpoint
that receives it; it identifies the originating endpoint by means of a private address to
which the terminating endpoint has no access.
NAT traversal for media streams requires knowledge not only of what media gateways
can be accessed via a network, but also of which NAT (if any) needs to be traversed to
reach a given gateway. Specifically, being able to send media packets to a given gateway
requires knowledge of the public NAT address that is bound to the gateways private
address. However, the public NAT address for a media stream cannot be discovered by a
GWC in the same way as the public NAT address for a signalling connection, because
media packets are by definition not sent by a gateway to its GWC. And RTP/RTCP
provides no address discovery mechanism that can be used to set up a two-way connection
between media gateways.
Hence the need for a media proxy as an intermediary. If a GWC knows that a given
gateway is behind a NAT, it can insert a media proxy into a call as a destination for media
packets from that gateway, and the media proxy can then discover the public NAT address
from which those media packets are being sent. The media proxy can then receive media
packets from the far-end gateway and send them to the correct public address on the NAT,
which uses the previously created NAT bind to send the media to the private network
endpoint behind the NAT. Two-way media streams for calls involving media gateways
behind NATs can thus be set up, provided that media packets are routed via the media
proxy.
To enable CS2000 GWCs to determine whether a media proxy needs to be inserted in a
given call, each GWC stores the following data:
! Information about all the middleboxes in the network, including NATs.
! Information about each media proxy available to the GWC.
! Information about which middlebox(es), if any, need to be traversed to reach each
gateway or remote CentrexIP client in the network.
Using a GWC-controlled media proxy to support NAT traversal for media streams means
that no changes are required to media gateway or NAT functionality. In particular, it does
not require gateways to be aware of network topology and middlebox deployment. It is a
scalable solution with no dependencies on factors outside the network operators control.
The situation for determining whether a media proxy needs to be inserted in a call to
support NAT traversal is very similar to the situation for determining whether CAC
should be applied. NATs and Limited Bandwidth Links (LBLs) can both be regarded as
types of middlebox whose involvement in a call has an impact on call establishment at the
GWC. See Chapter G6: CAC (Call Admission Control) for further information.

B5.2 RTP Media Portal

The RTP media portal is a GWC-controlled media proxy. Its primary purpose is to support
public address discovery for media streams that have been routed via a NAT. The media
portal examines incoming packets on each of its ports to determine their origin, and can
thus work out the destination to which return packets in the other direction should be sent.
In a carrier network supporting a CS2000 solution, each media proxy has two
connections, one with the private VoIP network supporting the CS LAN and large
telco-located gateways, and one with the carriers public network or DMZ. This enables
it to support two specific capabilities:
! It supports communication with and between private address domains, e.g. for
enterprise networks hosting line media gateways and CentrexIP clients, by enabling
media streams that traverse NATs to be routed across the carriers publiuc network.
! It can act as a firewall to control the traversal of media streams into the private VoIP
address domain used for the CS2000 CS LAN and large telco-located gateways.
The RTP media portal is built on the SAM16 hardware platform, as described in section
B5.2 on page 156. It is controlled by CS2000 GWCs using the Media Proxy Control
Protocol (MPCP) described in Chapter D9: MPCP.
Figure 46 illustrates the network role of the RTP media portal in supporting NAT traversal
between two media gateways located in private networks behind NAT devices.
CS2000 Core
(call processing)
Control / signalling
Media stream
Line CentrexIP
GWC GWC
H.248
MPCP
Uni
CICM
Public address MGCP
discovery for
signalling UniStim
Enterprise network Media portal Enterprise network

(private address domain) controller (private address domain)
Private Public Public Private

RTP media
portal
Firewall Firewall
Line (NAT/NAPT) Media packet (NAT/NAPT) CentrexIP
gateway engine on client
on LAN peripheral card
Public address Two-way NAT
discovery for functionality for
media stream RTP/UDP
media stream NAPT-port@NAPT-address.
(IP address belongs to selected card; port is
dynamically assigned from pool for domain)
Figure 46: Network role of RTP media portal

B5.2.2 Rules for Media Proxy Insertion

A media portal is selected and inserted in a call when CS2000 call processing determines
that a media stream needs to be set up between endpoints in different address domains.
This is necessary, for example, for media streams between different enterprise address
domains, and also for media streams between the private Succession address domain and
a public address domain. There are three possible locations for media gateways in terms
of the address domains or VPNs to which they belong, as summarised in the list below
and illustrated in Figure 47 on page 158:
! A media gateway may belong to the same private VoIP address domain as its GWC
and other CS2000 components. This is typically the case for large media gateways
such as PVGs supporting trunk and V5.2 access, and also for the UAS (though it is
not strictly speaking a media gateway).
! A media gateway may belong to the public / common address domain or DMZ used
to facilitate communication between different VPNs.
! A media gateway may belong to a private enterprise or residential VPN isolated
from the public address domain behind an NAT device or firewall.
A media portal must be inserted in a call when the bearer connection for that call crosses
the boundary between two address domains or VPNs.
There are nine possible scenarios for the establishment of a bearer connection between
two media gateways. Table 6 summarises which of these connection scenarios require a
media portal to be inserted in the call, and which types of interface connection the media
proxy needs to be provide in each case.
Table 6: Rules for inserting a media portal in a call between two media gateways
Location of terminating media gateway
Private VoIP domain Public domain / DMZ Enterprise domain
MP with MP with
Private VoIP one private VoIP I/F one private VoIP I/F
No MP required
originating media gateway
domain and one public I/F and one public I/F to

direct to gateway enterprise NAT device
Location of
MP with MP with two public I/Fs,

Public
one private VoIP I/F one direct to gateway
domain / No MP required
DMZ and one public I/F and one to
direct to gateway enterprise NAT device
No MP if both GWs in
MP with MP with two public I/Fs,
same domain;
Enterprise one private VoIP I/F one direct to gateway
otherwise, MP with
domain and one public I/F to and one to
two public I/Fs to
enterprise NAT device enterprise NAT device
enterprise NAT devices
Note: In terms of whether a media proxy needs to be inserted in a call, inter-CS calls
between media gateways controlled by different CS2000s are handled in the same way as
calls between gateways controlled by the same CS2000, provided that both CS2000s
belong to the same VoIP address domain. See section B5.2.4.4 on page 161 for
information about how calls between CS2000s belonging to different address domains are
handled.

Figure 47 illustrates the three possible locations for CS2000 media gateways in terms of
the address domains or VPNs to which they belong, and indicates how the RTP media
portal may be involved in supporting different types of connections between media
gateways.
CS2000 CS2000
and service logic and service logic
(CS2000 Core) (CS2000 Core)
GWCs for GWCs for GWCs for GWCs for

media DPTs to/from DPTs to/from media
gateways peer MGCs peer MGCs gateways
MG in VoIP MG in VoIP
address domain address domain
(private) (private)
TSPs VoIP address domain (private)
Private addresses
Media Portal (MP)
Public addresses
MG in MG in
public / common Public / common address domain (DMZ) public / common
(no NAT) (no NAT)
Public addresses Public addresses
NAT NAT
Private addresses Private addresses
MG in MG in
enterprise Other private address domains, e.g. for enterprise VPNs enterprise
(behind NAT) (behind NAT)
Figure 47: Media gateway locations in terms of address domains

B5.2.3 Network Location

Because media traffic for calls involving a media proxy does not pass directly between
media gateways, network engineering must consider the following:
! Capacity is affected because packet flows routed through media proxies need extra
bandwidth on the network segments containing the media proxies.
! Performance is affected because packet flows routed through media proxies incur
small additional delays.
Generally media proxies should be located as close as possible to the media gateways for
which they are to provide proxy functionality. The following configurations are typical:
! Media proxies located on the CS LAN.
! Media proxies co-located with large telco-located gateways.
! Media proxies co-located with broadband remote access servers connected to
customer-located gateways.
B5.2.4 Software Support for the RTP Media Portal
B5.2.4.1 Topology and Middlebox Data Stored at Line GWCs

In order to communicate with the media gateways it controls, a line GWC stores two types
of basic data:
! Static data about the gateway, including its FQDN, control protocol and
codec/packetisation support capabilities.
! A dynamic record of the IP address and port to which messages should be sent.
In addition to this basic gateway data, the GWC stores information that allows it to
communicate with gateways located behind middleboxes and to insert media portals into
calls when required:
! Information about intermediate middleboxes
The MB topology table specifies the parent MB of every middlebox in the network.
This reflects the hierarchy of MBs that exists in the network, beginning with the
lowest MBs at the network edge and ending at the core. The highest level of MBs
have a parent MB of 0 to indicate that there is nothing between them and the core.
! Media portal database recording information about each media portal available to
the GWC
" Global ID
" Name
" IP address and port to use for media portal controller
" Control protocol (MPCP)
! Additional MB-related information for each media gateway
For each gateway that may be behind a NAT device (LAN gateway or CICM), the
GWC datafill for the gateway specifies which MB to use for it. The ID of the
adjacent MB for a given gateway can be combined with the MB topology table to
generate an ordered list of the middleboxes to be traversed to reach that gateway.
Gateways in the VoIP domain have no associated middleboxes.

B5.2.4.2 Additional GWC Functionality for Controlling Media Portal Usage

To make use of the additional data described in section B5.2.4.1 on page 159, additional
functionality has been added to the GWC software load:
! An MPCP control engine that can be used to insert a media portal into a call when
the GWC (acting as the master GWC for a call) determines that this is necessary.
! An ITA (Internet Transparency Application) that uses gateway-provided SDP
together with gateway data held at the GWC to determine how to communicate with
each gateway and whether to insert a media portal into a call.
Figure 48 illustrates how GWC components interact to assess the need for media portal
capabilities and control media portal involvement in a call.
CS2000 Core Peer GWC
Internet Gateway
Transparency topology
Application data
(ITA)
Connection MB lookup
broker (Middlebox
data)
GWC
Gateway control MPCP
engine (MGCP engine
or H.248) (for RMP)
Line gateway Media portal

or CICM
Figure 48: Interaction between GWC components to for media portal control

B5.2.4.3 Signalling (Proprietary Extensions to SDP)

GWC control of media portal functionality depends on the ability to convey NAT-related
information between GWCs, both directly (for GWCs belonging to the same CS2000) and
indirectly via SIP-T (for DPT GWCs used to support communication between peer
CS2000s). The approach adopted has been to convey the necessary information as a
number of proprietary extensions to SDP, which can be conveyed in-line with MGCP and
H.248 or via MIME encapsulation in SIP-T. They are:
! Ordered list of MBs to be used to reach a given gateway (the default is to assume
direct contact with no intermediate MB).
Note: If the two media gateways in a call are both reached via ordered lists of MBs,
the ITA compares the two lists to determine whether there is an MB that is common
to both lists. If so, it can be used to bridge media bearer connections between
subtending MBs on the two lists (or between the gateways themselves if there are
no further MBs subtending the common MB).
! Indication of whether the gateway is inside the VoIP address domain or outside (the
default is to assume that it is outside).
! Indication of whether the gateway is behind a NAT device or not (the default is to
assume no NAT).
Although the information conveyed using these SDP extensions is proprietary, they are
added to SDP commands in a standard way. If they were to be provided to an SDP
recipient that did not recognise them, they would simply be ignored. This situation should
never occur, however, because these extensions are exchanged only between CS2000
GWCs; they are not passed on to media gateways or any other non-CS2000 device.
B5.2.4.4 Media Portal Usage for Inter-CS Calls

A given network may be based on two or more CS2000s. If so, it is up to the network
operator to decide whether their CS LANs should should share a single private VoIP
address domain or should each have its own private VoIP address domain.
If multiple CS2000 CS LANs are to share a single address domain, it is the responsibility
of the network operator to adopt an appropriate IP addressing strategy for them and ensure
that there are no clashes. The provisioning of the different CS LANs must be manually
co-ordinated to achieve this integration, as CS2000 provisioning cannot be automatically
co-ordinated across different CS LANs.
Datafill for the DPTs used for peer-to-peer communication between CS2000s has been
modified to indicate whether a given DPT is communicating with a CS2000 belonging to
the same private VoIP address domain or with a CS2000 belonging to a different address
domain. This determines how proprietary SDP extensions conveying NAT-related
information are handled over the DPT in question, as follows:
! For an INTERNAL DPT (to/from a CS2000 in the same domain), the proprietary
SDP extensions are conveyed unmodified. The two line GWCs involved in a
networked call set up via such a DPT can therefore decide upon and control media
portal involvement in the same way as if they belonged to the same CS2000.
! For an EXTERNAL DPT (to/from a CS2000 in a different domain), the proprietary
SDP extensions are discarded, and the SDP sent to the far-end GWC must come
from a public IP address and port. This requires a media portal to be inserted in the
call to provide an inter-domain connection and present this IP address and port.

B5.2.5 Components and Configuration

The RTP media portal is built on the SAM16 hardware platform, which is so called
because it is a single-shelf Service Application Module (SAM) with 16 slots for housing
PCI-based cards. A SAM16 consists of two 8-slot subsystems or domains, each of which
is a logical RTP media portal unit comprising the following:
! A host CPU card that supports control signalling between the GWC and the media
portal.
! Up to six peripheral cards, each supporting a media packet engine that relays RTP
packets between two address domains, and performs NAPT on them as they pass
through.
Figure 49 illustrates the logical configuration of an RTP media portal.
Host CPU card Host CPU card has two 100BaseT

Two RTP media portal units Ethernet ports, but uses only one
per SAM16 shelf
Connection with CS LAN PP8600
Each unit comprises a host for MPCP signalling to/from GWC,
CPU card, and up to six and for OAM&P signalling to/from
peripheral cards supporting MCS Manager
media packet engines
Peripheral cards with

media packet engines
Each peripheral card has
two 100BaseT Ethernet
ports for RTP streams.
These ports face different
Logical UDP ports for address domains,
terminating packetised enabling the RTP portal to
bearer connections act as a bridge between
for which NAPT those domains.
functionality is provided The media packet engine
on the peripheral card
relays packets and
performs address
mapping between
domains.
Figure 49: Logical configuration of an RTP media portal
When an RTP media portal is to be inserted in a call, the GWC controlling the selected
media portal sends the portals host CPU an MPCP message requesting a media portal
connection. The host CPU selectes one of its peripheral cards to host the multimedia
session, basing the selection on which card currently has most ports available. Card
selection determines which IP addresses are made available for media streams, because
each peripheral card has two static IP addresses: one on the private internal network (the
Succession address domain), and one on the public external network.

Each peripheral card manages two pools of UDP ports, one for each of its IP addresses.
Ports are randomly allocated from one or both of these pools in response to MPCP
commands sent by the MP GWC to request resources for the multimedia session. As ports
are allocated, the count of available ports is updated accordingly, ensuring that a
peripheral card is not selected for a new session if all of its ports have already been
allocated.
When two ports on a peripheral card have been dynamically allocated to a multimedia
session, a media stream can be routed across the media portal via those ports. There are
two possible scenarios:
! Media stream using one private and one public port on the media portal to traverse
the boundary between the private VoIP address domain and the external public
address domain.
! Media stream using two public ports on the media portal to traverse the boundary
between two external address domains, e.g. two private domains belonging to
different enterprise VPNs.
The two RTP media portals in a SAM16 shelf are independent active units.
One or two SAM16 shelves housing two or four RTP media portal units can be housed in
a dedicated PTE2000 frame.
One CS2000 GWC can control up to 20 RTP media portals. Together, these provide a
pool of resources (IP addresses and UDP ports) for the use of the GWC.
Equal usage of media portals is ensured by using a selection mechanism that cycles
through all the RTP media portals in the pool available.
Each peripheral card has two IP addresses, one from the private Succession domain and
one from the public domain. Each peripheral card also has a number of UDP ports (half
private, half public) determined when it is configured. When a GWC determines that a call
requires media portal capabilities, it selects and uses whichever peripheral card has most
free UDP ports. Redundancy is achieved by provisioning more UDP ports than strictly
necessary for the expected traffic flow.


! VoIP
B5.2.6.2 GWC-MP Signalling

! 10/100BaseT Ethernet connection between GWC and gateway
! MPCP
! N/A

The RTP Media Portal does not have to support PSTN / TDM access directly. It
communicates only with packet network endpoints.

Note: The RTP media portal does not generate or manipulate media streams; it merely
relays them. It is therefore not required to provide codec functionality.
! RTP / RTCP over UDP / IP for VoIP
! T.38 over UDP / IP for fax
B5.2.6.5 OAM&P
! Provisioning, management and control via MCS Manager EM application

! Controlled NAT functionality for media stream traversal of address domain
boundaries
! Controlled firewall functionality for VoIP private address domain

Chapter B6 Multimedia Communication
Server (MCS52000)
B6.1 Network Role of MCS5200

The Multimedia Communication Server (MCS5200) is a peer MGC on a par with
CS2000. It can be deployed as a stand-alone solution in its own right. It can also, however,
be deployed as part of a complete VoIP solution involving both MCS5200 and CS2000.
In this case, the MCS5200 LAN is typically co-located with the CS2000 CS LAN and
configured as a pair of additional VLANs, as shown in section B6.4 on page 170.
MCS5200 delivers multimedia servers for SIP clients, including client managers who act
as intermediaries between MCS5200 and remote clients. MCS5200 client managers
communicate with their own clients using a variety of protocols, and communicate with
MCS5200 on behalf of those clients using SIP. The signalling used is as follows:
! Signalling to/from remote IP telephony clients such as i2004 Ethersets. UniStim
signalling is conveyed across the core network between the clients and an IP Client
Manager attached to the MCS5200 LAN.
! Signalling to/from remote Web clients to permit browser access to multimedia
servers. Signalling in an appropriate protocol, e.g. WCSCP (Web Client Session
Control Protocol) is conveyed across the core network between the clients and a
Web Client Manager attached to the MCS5200 LAN.
! Signalling to/from remote multimedia clients such as SIP PC clients and SIP IP
phones. SIP signalling is conveyed across the core network between the clients and
the MCS5200 Application Server attached to the MCS5200 LAN
! SIP-T signalling to/from peer MGCs, e.g. CS2000.
MCS5200 bearer traffic to/from the core network can involve either of two types of media
server attached to the MCS5200 LAN:
! The Audio Server, which supports packet-based conferencing and announcements.
! The RTP Media Portal, which provides the bearer connections that enable remote
clients to use MCS5200 multimedia services.

Communication Server Capabilities Hardware Multimedia Communication Server (MCS52000)
B6.2 MCS5200 Components

B6.2.1 Functional Components
The main functional components of the MCS5200 are:
! The SIP Application Module (AM) is the central component of MCS5200. It
supports the SIP sessions that enable MCS5200 clients to communicate with each
other and to access MCS5200 databases and media servers. Specific capabilities
provided for SIP clients:
" Authentication and registration
" Presence management
" CPL (Call Processing Language) scripting, e.g. for screening
All service logic is executed on the Application Module, with reference being made
to the Database Module for subscriber information, CPL scripts, service data,
component configuration data and so on.
The Application Module also manages interworking between SIP-based networks
and non-SIP networks.
! The IP Client Manager (IPCM) supports call management functions for remote IP
telephony clients such as i2004 Ethersets. It acts as an intermediary between its IP
clients and the MCS5200 Application Module. Signalling between the IPCM and
its clients across the core network uses the UniStim protocol, while signalling
between the IPCM and the ISM AM uses SIP. The IPCM performs protocol
conversion between UniStim and SIP, and supports the following specific
functions:
" It initiates requests to the AM on behalf of its IP clients, e.g. registration.
" It originates SIP call processing messages on behalf of its IP clients, e.g.
INVITEs, and sends these to the AM to be forwarded to the correct
destination.
" It terminates SIP call processing messages sent by the AM and destined for its
IP clients.
" It initiates requests to its IP clients on behalf of the AM, e.g. applying tones.
Code on the IPCM recognises and responds to feature activation requests made via
Etherset softkeys, and supports features such as transfer, call waiting, call hold,
mute, speed dialing and so on.
! The Web Client Manager (WCM) manages browser sessions for web-based client
applications, and enables browsers to be used to initiate SIP sessions. Like the
IPCM, the WCM acts as an intermediary between its clients and the MCS5200
Application Module. Signalling between the WCM and its clients across the core
network uses the Web Client Session Control Protocol (WCSCP), while signalling
between the WCM and the ISM AM uses SIP. The WCM performs protocol
conversion between WCSCP and SIP, and provides functionality similar to that of
the IPCM (see above). This includes maintaining call states and implementing
features for web clients.

Multimedia Communication Server (MCS52000) Hardware Communication Server Capabilities
! The SIP Audio Server provides conferencing for MCS5200. It uses the same
platform as the UAS described in section B3.3: Universal Audio Server (UAS) on
page 138. Like the UAS, it provides ports for the termination of media flows to/from
conference participants.
! The RTP Media Portal supports Network Address and Port Translation (NAPT),
which enables it to acts as a firewall and media portal for RTP/RTCP media flows
between endpoints in the private MCS5200 LAN and endpoints on the managed IP
backbone network. It is controlled by the SIP Application Module. NAPT can be
performed both on the destination IP address and port and on the source IP address
and port for each IP packet that traverses the media portal . The portal can thus relay
packets between two endpoints located in different networks and using different IP
address domains.
! The SIP PRI Gateway provides media gateway functionality between a
circuit-based access network and the packet-based MCS5200 LAN. On the access
network side, the SIP PRI gateway supports ISDN PRI connections (30B+D or
24B+D), while on the MCS5200 LAN side it supports SIP signalling and RTP
bearer connections. The gateway performs mapping between PRI (Q.931)
signalling and SIP signalling, and is responsible for the conversion of packet-based
voice streams to circuit-based voice streams.

B6.2.2 OAM&P Components

Servers:
! The Database Module stores subscriber data, CPL scripts, service profiles,
component configuration data and translation information for use by the MCS5200
Application Module.
! The Provisioning Module (PM) provides a user-friendly, web-based interface for
provisioning the data stored on the Database Module. Data entered is validated
before being stored. The PM also supports the downloading of address book and
service package data to SIP clients via the MCS5200 Application Module. It
provides a CLI (Command Line Interface) for bulk provisioning as well as the
web-based interface.
! The Management Module supports management and administration functions for
MCS5200 modules and services. It is used to deploy software loads and
configuration data to the SIP Application Module. It also manages the collection of
OAM&P data from the functional MCS5200 components described in section
B6.2.1.
! The Accounting Module provides a framework for the transport of accounting
information from MCS5200 system to a service providers back-end billing system.
It stores billing records and supports formatting of accounting files.
B6.2.3 Remote Clients

MCS5200 can support the following types of remote client:
! Remote IP telephony clients, such as i2004 Ethersets or PCs running compatible
telephony client applications. The i2004 is a proprietary IP-enabled Ethernet phone.
It uses a large display and programmable softkeys to support quick and easy access
to capabilities such as multiple directories, multimedia mailboxes and voice
recognition. It uses the UniStim protocol to communicate with the IP Client
Manager, which in turn communicates with the MCS5200 Application Module via
SIP.
! Remote Web clients supporting browser access to multimedia servers. The SIP
Multimedia Web Client is a thin client that uses a web browser on a PC platform. It
uses WCSCP to communicate with the Web Client Manager, which in turn
communicates with the MCS5200 Application Module via SIP.
! Remote multimedia clients such as SIP PC clients and SIP IP phones. SIP signalling
is conveyed across the core network between the clients and the MCS5200
Application Server attached to the MCS5200 LAN. The SIP Multimedia PC Client
is an intelligent SIP endpoint installed on a PC, which provides advanced IP
telephony features, many of which are unavailable in a conventional circuit-based
telephone network.

Multimedia Communication Server (MCS52000) Hardware Communication Server Capabilities
B6.3 MCS5200 Connectivity

Connectivity within a stand-alone MCS5200 LAN is provided by the BPS2000 Layer 2
Business Policy Switch. This supports traffic marking and prioritisation via DiffServ and
802.1p/q. At least two BPSs are required for the MCS5200 LAN to provide redundancy.
Additional BPSs may be required depending on the number of MCS5200 components to
be connected and the volume of traffic to be handled.
The dual BPSs should be configured to support two DiffServ-enabled VLANs, one
private and one public. The term public means that the IP addresses for components on
the MCS5200 public VLAN are visible outside the VLAN; they need not be public IP
addresses, but must belong to the same IP address domain as the managed IP backbone
network. Routing between the public and private MCS5200 VLANs should not be
permitted unless there is a firewall between them. Table 7 indicates for each MCS5200
component whether it should be connected only to the private VLAN or to both VLANs
(or to neither, in the case of remote clients).
Table 7: VLAN connectivity for MCS5200 components

Requires connection to
MCS5200 component MCS5200 MCS5200 Backbone
private VLAN public VLAN network
MCS5200 Application Module Yes Yes Yes [1]
MCS5200 Database Module Yes No No
MCS5200 Accounting Module Yes No No
MCS5200 Management Module Yes No No
MCS5200 Provisioning Module Yes Yes Yes [1]
IP Client Manager (IPCM) Yes Yes Yes [1]
Web Client Manager (WCM) Yes Yes Yes [1]
RTP Media Portal Yes Yes Yes [1]
Audio Server Yes No No
SIP PRI Gateway Yes No No
Remote IP client No No Yes
Remote Web client No No Yes
Remote SIP multimedia client No No Yes
[1] TheIP addresses assigned to components on the MCS5200 public VLAN are visible to the
managed IP backbone network.
The BPSs of the MCS5200 LAN rely on an appropriate routing switch such as PP8600 to
provide connections with the core network. GigE links are used between the BPSs and the
routing switches.

B6.4 CS2000 / MCS5200 Combined Configuration

When deployed as part of a complete Succession solution involving both MCS5200 and
CS2000, the MCS5200 LAN is typically co-located with the CS2000 CS LAN and
configured as a pair of additional VLANs, as shown in Figure 50. In such a combined
configuration, BPSs are not required, as MCS5200 components are attached directly to
the CS LAN PP8600s.
CS2000 OAM&P VLAN

(signalling only)
EMs EMs MCS5200 private VLAN

SDM on Sun on
servers PCs Database Mgmt
Module Module
CS2000 bearer VLAN Accounting Provisioning

Private Module Module
VLAN
Media
server
DSPs
MCS5200 SIP
Media Audio PRI
server Server Gateway
Media
USP Core server GWCs
CPU MCS5200 IP Web
Application Client Client
Module Manager Manager
CS2000 call processing VLAN
(signalling only)
MCS5200 public VLAN

Media proxy switched into calls to
support NAT and NAT traversal for
media streams between IP address
domains.
NAT provides security for streams Dual
entering/leaving CS LAN. PP8600s
NAT traversal makes communication
possible between different private
domains. MCS5200-related signalling across the core
CS2000 portal is controlled by a GWC. network between:
MCS5200 portal is controlled by the IP Client Manager and remote IP
MCS5200 AM. telephony clients such as i2004
RTP RTP Ethersets
CS2000-related signalling Media Media Web Client Manager and remote Web
across the core network Portal Portal clients to permit browser access to
between: multimedia servers
GWCs and remote MCS5200 Application Server and
media gateways remote multimedia clients such as SIP
CS2000 Core and PC clients and SIP IP phones
peer MGCs
Packet backbone network
Figure 50: Logical configuration of MCS5200 deployed alongside CS2000

Part C
Software
CS2000 International Product Description Part C Chapter C1
Communication Server Capabilities Software Software Loads
Chapter C1 Software Loads
This chapter describes the software loads that are required for the various constituent units
of a CS2000 in order to create a complete operational system.
It also lists the software loads for complementary non-CS2000 components such as media
gateways, and for OAM&P units supporting Element Managers (EMs).
It is organised as follows:
! Section C1.1: CS2000 Core Load on page 173
! Section C1.2: Loads for Other CS2000 Components on page 176
! Section C1.3: Loads for Media Gateways and Servers on page 178
! Section C1.4: OAM&P Software on page 179

Chapter C1 Part C CS2000 International Product Description
Software Loads Software Communication Server Capabilities
C1.1 CS2000 Core Load

This section describes the structure of the CS2000 Core software load required to make a
CS2000 operational.
The Core software load is known as the Product Computing-Module Load (PCL). The
ISN07 load installed in the 3PC in Compact configurations supports the same call
processing and service functionality as the load installed in XA-Core in standard
configurations. The XA-Core load is formally referred to as PSNWC07 (order code
SW000007); the 3PC load is formally referred to as CSNWC07 (order code SWC00007).
Note: Other CS2000 units have their own software loads, as described in the other
sections of this chapter. These include the GWC, the USP, the FLPP and the Core and
Billing Manager (CBM) or SuperNode Data Manager (SDM) used as the platform for the
CS2000 Core Manager.
CS2000 is a layered product, with ownership of the layers defined and a clear
understanding of the allocation of functions to layers and the dependencies between
layers. The main layers are:
! Base, which comprises basic computing functions such as processing, memory
management and hardware diagnostics.
! Telecom, which supports the peripheral types used by CS2000 and provides call
processing support functions such as translations and routing.
Note: The combination of Base layer software and Telecom layer software is
known as the Communication Services Platform (CSP).
! Product, which supports call processing applications and services by means of
reusable software objects and generic agents. The Product Layer also includes any
software required to customise a Communication Server for use in a particular
market, e.g. the software used to customise CS2000 for European and Australasian
markets. For example, the base capabilities required to implement an interface such
as ETSI ISUP are typically provided by means of a generic call processing agent,
and variants of this agent are made available to meet the requirements of specific
national markets.
To allow development to proceed independently for different parts of the system, the
complete software configuration for a Communication Server is assembled from
separately delivered Development Release Units (DRUs). A DRU may be a complete
software layer or a set of integrated software within a layer. It cannot straddle layers, and
is always delivered and included in the switch configuration as a whole.
Note: Some software is also made available as part of a library, which is a collection of
self-contained software components for re-use by different products. The difference
between a library and a DRU is that it is possible to select a subset of software from a
library for inclusion in a PCL rather than including the library as a whole.

Figure 51 illustrates the layered structure of the software in the CS2000 Core software
load used by CS2000 in ISN07.
TOPS DRU
World Trade DRU (WT20), (TOPS20),
comprising comprising MSH
market-specific operator (Multi-Service Hub)
Product Layer custom software services DRU (MSH20),
and general-purpose software. supporting
international software (in load, but CS2000-related
functionality connectivity)
is not
Common software (CCM20) supported
(lines software applicable both in ISN07)
internationally and in Nth America)
Shared Library (SHR20)
(software applicable for other Nortel
products as well as CS2000)
Call processing support

CSP20 Platform
Telecom Peripheral support

Layer
(TL20)
OAM support
Base
(BASE20) Basic computing functionality
(processor support, memory management, etc)
Figure 51: DRUs and libraries included in the ISN07 Core load (XA-Core or 3PC)
ISN software loads can support dual working configurations in which conventional
circuit-based trunk and line peripherals are used as well as trunk and line media gateways,
allowing TDM and packet capabilities to be supported in parallel. Looparound trunks are
used to support call interworking between the TDM and packet environments, as
described in section B2.3.2.5 on page 107.

Table 8: Order codes for base capabilities provided by CS2000 Core

Order code Name / description
SW000007 ISN07 International CS2000 PCL
SWC00007 ISN07 International CS2000 - Compact SN06 PCL
CPUS0001 XA-Core Processors
CPUS0003 Multi-Core 3+1
W3PC0002 Compact SOS Processor
BPRD0001 CS2000 Platform
CS2B0001 Communication Server 2000 Base
CS2B0002 GWC Support and Control
CS2B0005 Dynamic Packet Trunks
CS2W0002 Inter-CS Communication via SIP-T
BASE0011 CO Data Change Capture
BASE0100 XA-Core Max Power (controls number of XA-Core PEs)
TEL00004 C7 Routeset Increment
TEL00006 C7 Link Protocol Tester
TEL00007 C7 Link Fault Locator
TEL00009 C7 Network Integrity Items
TEL00011 C-Side 14 Extended Messaging
TEL00012 Multiple Point Code
TEL00015 NI Interworking
TEL00016 TOD Clock Synchronisation to SDM
STRM0006 STORM NCL
3PC00070 3PC Peel/Linux NCL
PSNW0007 ISN07 Peripheral Firmware Load

C1.2 Loads for Other CS2000 Components

C1.2.1 SAM21 and GWC (Gateway Controller) Software Loads
CS2000 GWCs are used for a number of different functions, but the same international
software load is used for all of them. CS2000 datafill is used to customise this load for
each GWC, to equip the GWC for its intended role.
Table 9: ISN07 GWC software load
Peripheral Software Load
GWC (Gateway Controller) GC070
SC (SAM21 Shelf Controller) SCU10
C1.2.2 Signalling Peripheral Software Loads

Table 10: ISN07 signalling peripheral software loads
Session Server NGSS07
USP USP9.0
USP-Compact USPL9
LPP (LIM) LPC17
LIU7 (8 Mbyte) NCH17
LIU7 (32 Mbyte) NCT17
C1.2.3 Miscellaneous Component Loads

Table 11: ISN07 miscellaneous component loads
PP8600 router Rel 3.7
Session Server NGSS07
ISM MTMKA02
IOM IOMR
ENET (optional, for use with OAU) ENC17
OAU (optional) MTMKA02
MS MUC20

C1.2.4 Firmware Loads

Table 12: ISN07 firmware loads
Peripheral Firmware Load
XA IOP (OC-3) XAIO01AK
HIOP (100BaseT Ethernet) XHIO02
6X17BA Ethernet packlet for IOP EP14DO03
GWC firmware RM07
MS (Port Card) MPF17
C1.2.5 Software Order Codes
Table 13: Order codes for base capabilities provided by other CS2000 components
GWCW0070 Gateway Controller NCL (inc. RMGC)
SAM20070 Service Application Module NCL
CICM0070 CentrexIP Client Manager
NGSS0070 Session Server
RMPx0070 RTP Media Portal
MS200070 MS2010
MS2A0070 MS2020
UASA0008 Universal Audio Server NCL
GSS00033 Global Server SW Rel 3.2 NCL for UAS
GSSB0002 3rd Party MS Windows 2000 OS
GSSB0003 3rd Party MS Windows 2000 Res kit
GSSB0004 Windows Terminal Services Client
GSSB0006 Ghost Enterprise Software
APS00007 Audio Provisioning Server NCL
APSB0007 3rd Party AdventNet 4.1
USP00090 Universal Signalling Point Server NCL
USPL0090 Basic Universal Signalling Point - Compact
SSAS0001 SSAS Basic Platform
SSAS0002 Basic OAM&P
SSAS0004 IP High Speed Link
SSAS0005 SSOMs
SSAS0007 GUI Workstation
SSAS0011 Routeset 256 to 511

Table 13: Order codes for base capabilities provided by other CS2000 components
SSAS0019 ITU High Speed Link
SSAS0021 OSS Electronic CLI
C1.3 Loads for Media Gateways and Servers

C1.3.1 Media Gateway Loads
Table 14: Media gateway loads available for deployment with ISN07
Unit Load
PP15000 PVG PCR 6.1
PP7480 PVG PCR 6.1
MG9000 MG9K0070
Mediatrix 1124 Release 4.3
CG4500E MTA Version 5.4
Cuda 12000 CMTS Version 5
Motorola BSR64000 CMTS Version 2.2
Westell iQ203x Version R1.6.11
C1.3.2 Media Server Loads

Table 15: Media server loads available for deployment with ISN07
Unit Load
MS2000 Series (MS2010 and MS2020) AMS 4.4.
UAS UAS08MR

C1.4 OAM&P Software

OAM&P capabilities are provided for CS2000 and the other elements of a CS2000-based
Succession Network by means of EMs and management applications that run on a variety
of hardware platforms to deliver both nodal and network management capabilities.
Table 16 lists the software loads used to deliver OAM&P functionality in ISN07. Sections
C1.4.1 and C1.4.2 discuss the CBM/CS2E and CS2M loads in more detail.
Table 16: OAM&P loads available for deployment with ISN07
Application Platform Load
CBM (Core and Billing Manager)
CBM00070
on Netra 240
CS2000 Core Manager
SDM (SuperNode Data Manager)
CS2E07
on Series FX (AIX)
CS2000 Management
Components [1] Sun Netra 240 CS2M07
IEMS Sun Netra 240 (shared) IEMS0070
PP8600 Manager Windows PC / Sun workstation Device Manager Version 5.7
APS Sun Netra 240 APS09
PMDM (PVG) Sun Netra 240 PMDM 15.1
MG9000 EM Sun Netra 240 9KEM0070
Cuda Provisioning Manager Version 5.0
[1] Comprises Succession Server Platform Foundation Software (SSPFS) platform, line / trunk
provisioning applications, GWC EM, SAM21 EM, UAS EM, LMM, TMM, NPM and QCA.
C1.4.1 Core Manager Software Load

In ISN07, management capabilities for the CS2000 Core can be delivered in either of two
ways:
! By the Core and Billing Manager (CBM), which is implemented by means of the
CBM software package running on a Sun Netra 240 server.
! By the SuperNode Data Manager (SDM), which is implemented by means of the
CS2E software package on a Motorola PowerPC Series FX system running AIX.
Prior to ISN07, the Core Manager ran only on the SDM AIX platform. This platform is
still supported in ISN07, but supporting the Core Manager on a Sun Netra 240 server
potentially makes it possible to support all CS2000 OAM&P in a single Sun frame. For
an XA-Core configuration using an FLPP, CBM/CS2E software also comprises EM
functionality for the FLPP.

C1.4.2 CMT Server Load

The CS2000 Management Tools (CMT) server is a Sun Netra 240 server housed in a
PTE2000 cabinet and attached to the OAM&P VLAN. It hosts a number of Non-Core
Loads (NCLs) that provide management capabilities for CS2000 components. These
NCLs are:
! The CS2M (CS2000 Management Components) NCL, which comprises the
following software packages:
" SESM (Succession Element and Sub-Network Manager)
A software package that includes the following applications:
# GWC Manager
# Node Configuration
# Trunk Configuration
# Carrier Endpoint Configuration
# Line Configuration (SERVORD+)
# TMM (Trunk Maintenance Manager)
# LMM (Lines Maintenance Manager)
# LTM (Line Test Manager)
# V5.2 Configuration
# V5.2 Maintenance
# Media server management
# Media server configuration
# APS Manager
# Common Launch Point (CLP) for CS2000 Management Tools
" SAM21 SC EM
The software package that contains the CS 2000 SAM21 Manager application
for the SAM21 Shelf controller.
The software package that contains the QoS collector application for per-call
QoS records sent from the CS2000 GWC.
! IEMS (Integrated Element Management System)
The NCL that provides a single integrated desktop environment for access to most
other (eventually all) CS2000 EMs and management applications.
! APS (Audio Provisioning Server)
The NCL software package that contains the APS application for provisioning
announcements on the UAS and MS2000 Series.
! SSPFS (Succession Server Platform Foundation Software)
The NCL software package that contains base operating system and common tools,
libraries and server functions used by EML applications. These include:
" EMS proxy services supporting access to embedded server software,
including:
# Call Agent Manager for the Call Agent platform
# STORM Manager embedded in STORM software load
# Client for USP Manager embedded in USP software load
" PM Poller
" NPM (Network Patch Manager) for GWCs
" Generic services and protocols such as BOOTP, DHCP, TFTP and KDC

C1.4.3 Software Order Codes
Table 17: Order codes for OAM&P software
CBM00070 CS2000 Core Manager NCL (CBM)
CS2E0070 CS2000 Core Manager NCL (SDM)
ATA00001 ASCII Terminal Access Gateway
CNCD0004 CNCD RTB OFT
CNCD0006 Billing Filtering
CNOM0001 CNOM PH 1
CNOM0002 CNOM OM 02
ENTA0001 Enhanced Terminal Access
SBM00001 Billing Appl Base
SBM00003 AMADNS DDI I/F
SBM00006 SBA-SMDR
SFT00001 Secure File Transfer
CS2M0070 CS2000 Management Components (GWC, UAS, APS, SAM21)
SAMM0021 SAM21 EMS
UASM0001 Universal Audio Server EMS
CICE0070 CICM EM
SPFS0070 Succession Solutions Platform Software 3rd Party NCL
LCS00015 Oracle Enterprise 817 3rd Party License
LCS00019 AdventNet SNMP V3 Platform 3rd Party License
LCS00020 ILOG JView Platform 3rd Party License
NSW00007 ISN07 Non-Resident Load NCL

Chapter C2 Trunk and Line Datafill
C2.1 The Purpose of Datafill

Datafill is used to customise CS2000 components for their role. The capabilities provided
by CS2000 software loads are generic, and each CS2000 needs to be provided with
additional network-specific information to make it ready for deployment. Two types of
datafill are used for this purpose:
! The operation of CS2000 Core and the FLPP is controlled by data schema tables
that are stored by the Core. Data schema tables are also used to provide an interface
between the Cores translations and routing functionality and the GWCs used to set
up and take down connections across the packet bearer network. Access to CS2000
Core data schema tables is supported by the CS2000 Core Manager, as described in
Chapter H1: Overview of OAM&P for CS2000 Solutions.
! The operation of GWCs with subtending units is controlled not only by CS2000
Core configuration data, but also by SNMP MIBs (Management Information Bases)
stored by the GWCs themselves. SNMP (Simple Network Management Protocol)
is an IETF protocol designed for communication between Device Managers and the
network elements they control. A MIB is an object-oriented data structure designed
to capture provisioning information in a standardised way. The GWC Manager uses
SNMP to populate each GWCs MIB with the information it requires to perform its
network role, e.g. information about gateways, carriers, and trunk or line endpoints
supported.
This chapter describes the datafill used to provision trunk and line interfaces on CS2000.

Trunk and Line Datafill Software Communication Server Capabilities
C2.2 Trunk Group Provisioning

This section lists and briefly describes the CS2000 Core data schema tables used to
provision trunk groups and destinations to support the trunk routing functionality
described in Chapter C3: Translations and Routing. See section C2.3 on page 185 for
information about the tables used to provision signalling links, which convey the
messages used by the Core to translate and determine the destination of a call so that an
appropriate trunk can be selected. CS2000 supports the following types of trunk
destination, for which the datafill requirements are described in other sections in this
chapter:
! TDM-side trunks served by media gateways (see section C2.5 on page 190).
! DPTs (Dynamic Packet Trunks) to packet network destinations served by other
CS2000s (see section C2.6 on page 191).
Trunk group provisioning tables:
! Table CLLI
Defines a logical Common Language Location Identifier (CLLI) to denote the far
end of a trunk group and indicate its function. This CLLI is used as a key in tables
TRKGRP, TRKSGRP, TRKMEM, ISUPDEST, C7TRKMEM and LTMAP. For
CCS7 and ISDN trunks, the CLLI defines a common destination for voice trunks
and signalling links that follow separate routes (as they do in the CS2000
architecture).
! Table TRKGRP
Defines type and direction (2W, IC, OG) of trunk groups. Also provides entry points
to translations, service assignments and so on for trunk groups.
For ISDN trunks, the LTID field of table TRKGRP specifies the logical terminal
identifier. This should be set to $, which causes the field to be updated automatically
when table LTMAP is datafilled.
! Table TRKSGRP
Defines the signalling characteristics of a given trunk group.
For CCS7 trunks, the PROTOCOL field specifies the signalling protocol and the
VERSION field identifies the call processing agent; if necessary, the VARIANT
field can be used to identify a specific agent variant. ETSI ISUP trunks, for
example, have Q767 in the PROTOCOL field and either 100_WHITE for the ETSI
ISUP V2 agent or 100_BLUE for the ETSI ISUP V1 agent; the VARIANT field is
used to identify different national variants of 100_WHITE and 100_BLUE.
Note: Prior to ISN04, all the TDM-side trunks terminated on a given GWC had to
be provisioned with the same signalling protocol. This was to prevent unpredictable
consequences arising from datafilling trunks that support maintenance-oriented
group blocking (e.g. IBN7) on the same GWC as trunks that do not (e.g. BTUP). In
ISN04, maintenance messaging between the GWC and Core was enhanced to allow
the GWC to request the blocking of a group of specified TIDs rather than a complete
carrier. The Core can then decide (on the basis of the protocol in use) whether to
relay this information to the far-end switch as a group blocking message or as
individual blocking messages. See A59035762 for further information.
For ISDN trunks, table TRKSGRP defines the location and characteristics of the
D-channel for the trunk group (see section C2.3.2 on page 186).

Communication Server Capabilities Trunk and Line Datafill
! Table TRKMEM (also table C7TRKMEM for CCS7 trunks)

Assigns individual trunks to trunk groups. Also used in mapping individual trunks
on to physical locations and carrier timeslots (virtual locations and timeslots in the
case of CS2000, which does not physically terminate trunk bearer channels).
Table TRKMEM defines the TIDs (terminal identifiers) used by CS2000 Core call
processing to identify and select specific trunks. Media gateways identify the
TDM-side trunks they support by means of EIDs (endpoint identifiers) specifying a
particular 64 Kb/s channel on a particular E1 carrier. Mapping between TIDs and
EIDs is provided by GWC datafill, as summarised in section C2.5.2 on page 190.
! Table TRKOPTS
Defines additional options for trunk groups, e.g. trunk group options used to support
Carrier Selection. These include:
" The DYNAMIC option, which is used in provisioning the DPT GWCs used
to terminate CCS7 signalling encapsulated in SIP-T messages, as described in
section C2.6.2 on page 192.
" The VOICELAW option, which indicates the companding voice-law used on
bearer connections (g711_a_law or g711_mu_law). This information is
conveyed in the IAM USI parameter for outgoing calls made via the trunk
group. See A59029963 for more information.
Note: CS2000 has no way of verifying that the voice-law provisioned and
signalled in the IAM is the voice-law actually used by the gateway. This must
be ensured by co-ordinating CS2000 and gateway datafill.
! Table SIPLINK (Session Server implementation of SIP/SIP-T)
Contains the access link information that is used to direct calls to the appropriate
SIP server. This information is also used by Session Server devices for mapping
incoming calls.
! Table LTDATA (ISDN trunks only)
Datafilled with the LTID, data type and logical terminal values of the trunk group.
Can also include options for provisioning services, including:
" The DN option, which is used in provisioning the default directory number.
" The CLI option, which is used in provisioning CLI-related ISDN features
such as CLIR (Calling Line Identity Restriction) and 2CLI (Two Calling
Party Number Delivery).
" The SERV option, which is used in provisioning ISDN supplementary
services such as MCID (Malicious Call Identification) and UUS1
(User-To-User Information Service Type 1).

C2.3 Signalling Link Provisioning

This section lists and briefly describes the CS2000 Core data schema tables used to
provision signalling links, which convey the messages used by the Core to translate and
determine the destination of a call so that an appropriate trunk can be selected. See section
C2.2 on page 183 for information about the tables used to provision trunk groups so that
a call can be completed when its destination has been determined.
Specifying the signalling capability required for each trunk group/member is essential to
ensure that the signalling channels entering the CS2000 are routed to appropriate
signalling terminations.
C2.3.1 CCS7 Signalling Links

The way in which CCS7 signalling links are datafilled depends partly on whether CCS7
functionality is provided by the USP or the FLPP, which is indicated by office parameter
USP_ACTIVE_IN_NETWORK. Most signalling link datafill is the same in both cases,
but physical link terminations are defined differently.
! Table C7NETWRK lists the CCS7 point code domains supported and indicates the
network type of each (ANSI or ITU-T/ETSI). It also specifies the point code(s)
used to identify each CS2000 network appearance to other nodes or network
appearances within a CCS7 given point code domain. A CS2000 can be assigned up
to four point codes in a given domain and up to 31 point codes in total.
! Table C7RTESET defines routesets, where a routeset comprises all the possible
routes (up to a maximum of eight, listed in order of preference) from a CS2000 to
another to other target node or network appearance within a CCS7 given point code
domain. Each element in a routelist is a linkset, where a signalling linkset is a group
of one or more signalling links that provides a route to an adjacent CCS7 node. For
a direct route to the target node, the linkset provides a direct connection. For an
indirect route to the target node via one or more other nodes, the linkset provides a
connection to the first node on the route.
Note: If CCS7 functionality is provided by the USP, table C7RTESET is
automatically populated with data downloaded to the CS2000 Core from the USP.
! The way in which linksets are defined depends on whether CCS7 functionality is
provided by the USP or the FLPP, as follows:
" If CCS7 functionality is provided by the USP, linksets are datafilled on the
USP rather than the Core. The USP sends the Core the routeset information it
needs to populate table C7RTESET, and also keeps the Core informed about
routeset availability.
" If CCS7 functionality is provided by the FLPP, signalling linksets are defined
in table C7LKSET. The individual links belonging to a linkset are defined in
table C7LINK, which in turn refers to the datafilled list of available link
terminations in table LIUINV). Each linkset is associated with a particular
CCS7 network appearance defined in table C7NETWRK (network type, point
code domain, point code).
! ISUP and TUP signalling links are provisioned using tables ISUPDEST (which
maps trunk groups to the signalling routesets and associated network appearances
defined in table C7RTESET) and C7TRKMEM (which assigns CICs).

C2.3.2 ISDN Signalling Links

Signalling links for ISDN PRI are provisioned using table TRKSGRP, as used to define
the signalling characteristics of a given trunk group. QSIG signalling links are datafilled
in the same way. A PRI trunk group has no subgroups as such, but table TRKSGRP
defines the signalling characteristics of the D-channel that conveys the ISDN signalling
for the B-channels in the group:
! Signalling type ISDN
! Protocol version 87Q931
! Configuration PT_PT
In conceptual terms, there is a logical terminal (LT) at either end of an ISDN PRI trunk
interface. Each logical terminal has an identifier and belongs to a logical terminal group.
On CS2000, logical terminal attributes are datafilled in tables LTGRP, PRIPROF,
LTDEF and LTMAP, as follows:
! Table LTGRP is used to define group numbers to be assigned to ISDN logical
terminals. Only one option is available per group, this being SAPI16. SAPI16 is the
Service Access Point Identifier used for communication between Layers 2 and 3.
! Table PRIPROF is used to create profiles that can be used by ISDN logical terminal
groups. The key field is PROFNAME, which is referenced in table LTDEF. Profiles
are used when interworking with a PBX that uses an implementation of ETSI PRI
that differs from the CS2000 implementation. This table provides additional control
of PRI variants on each interface to ensure compatibility.
! Table LTDEF identifies logical terminals and defines their access privileges. Since
each PRI trunk group is considered as the equivalent of a logical terminal, it must
be assigned a logical terminal identifier (LTID) and access privileges in table
LTDEF. The protocol variant information is extracted from table PRIPROF.
" LTAP field is B for the logical terminal access privilege.
" LTCLASS field is PRA for the logical terminal class.
" NUMBCHNL field defines the number of B-Channels associated with this
logical terminal.
" The version of PRI to be used, which is identified by means of a unique
Protocol Version Control (PVC) value generated from the values of the
VARIANT and ISSUE fields in the table LTDEF entry. Base/generic ETSI
PRI trunks, for example, have ETSI PRI in the VARIANT field and 1990 in
the ISSUE field; other values in the ISSUE field are used to identify different
national variants, e.g. SPAIN1 for Spanish PRI.
Note: QSIG trunks, for which Layer 3 signalling is very similar to PRI, are
datafilled with the value QSIGPRI in the VARIANT field.
! Table LTMAP associates the LTID assigned to the trunk group in table LTDEF
with the trunk group CLLI.
" MAPTYPE field specifies the CLLI for mapping purposes.
" OPTION field specifies 0 as the TEI (Terminal Endpoint Identifier)

C2.3.3 Trunk Provisioning Flowcharts (TDM-Side)
See document
START CS2000 Configuration
(NN10193-511)
Add trunk endpoints

via GWC Manager Add new trunk group
name to table CLLI
Capture Node and
Terminal numbers
Add trunk group data
to table TRKGRP
Captured Node and Terminal numbers
Is carrier N Add trunk group data

already provisioned to table TRKSGRP
on gateway
[Y/N]?
Y to table TRKOPTS
Provision carrier
on gateway
(Carrier can be provisioned Does
in advance, before trunk CCS7 route N
Does endpoints are added)
for new trunk group
trunk group already exist
already exist N [Y/N]?
[Y/N]?
Add CCS7 link/route and
Y destination data to
Y associated dependent tables
Add trunks to table

TRKMEM using captured Add CCS7 destination
Node and Terminal numbers information to table
ISUPDEST
Add trunks to table
C7TRKMEM, using assigned
CIC for each member
Unlock carrier
on gateway
BSY trunk
members on TMM
Run COT test

from far-end switch Running COT test from far-end switch verifies provisioning
(optional) and hardware connections before traffic is allowed
RTS trunk
members on TMM
FINISH
Figure 52: Provisioning CCS7 trunks

START
Add trunk endpoints via GWC Add new trunk group

Manager using PRI option name to table CLLI
See document
CS2000 Configuration
(NN10193-511) Capture Node and Add trunk group data
Terminal numbers for to table TRKGRP
D-channel and B-channels
Add trunk group data to table

TRKSGRP, inc. D-channel
Node and Terminal number
Captured Node and
Terminal numbers
Add trunks to table
TRKMEM using B-channel
Node and Terminal numbers
Add logical terminal data

N Is carrier to table LTGRP
already provisioned
on gateway
[Y/N]?
Add logical terminal data
Y to table LTDEF
Provision carrier
on gateway
(Carrier can be provisioned
in advance, before trunk Add logical terminal data
endpoints are added) to table LTMAP
Unlock carrier
on gateway Add logical terminal data
to table LTCALLS
BSY D-channel and

B-channel trunk
members on TMM
RTS D-channel and

B-channel trunk
members on TMM
FINISH
Figure 53: Provisioning PRI trunks

C2.4 Provisioning GWC Units

! SERVRINV
Server Inventory table, which defines the GWCs supported. Each entry in this table
provides information about a specific GWC, including the following:
" Server type and numeric ID, e.g. GWC 7
" Packet network type (IP or ATM)
" GWC IP address
Note: The last element of this address must be a multiple of four, because
four IP addresses are used by each GWC (see section B1.4.5.1 on page 60 for
details); the three IP addresses next in sequence are assigned automatically.
" The server exec(s) to be used, which determines the type of call processing to
be performed by the GWC. Two SRVREXEC types are supported in ISN07:
# DTCEX, which enables details of the TDM-side trunks controlled by
the GWC to be datafilled against it (in tables CLLI, TRKGRP,
TRKSGRP, TRKOPTS and TRKMEM) as if it were a TDM-side DTC
(Digital Trunk Controller)
# POTSEX, which enables details of gateway line groups and the lines
belonging to them to be datafilled in tables LGRPINV and LNINV.
Note: Only one type of server exec can be specified for a given GWC. Table
SERVRINV can have a maximum of 255 entries, of which up to 140 can be
for GWCs supporting trunk execs (i.e. DTCEX).
" Toneset to be used
Tones are actually provided by gateways, not by GWCs, so this field is always
set to the default value UK100.
See Chapter G2: CS2000 Support for Tones for information about the
different national tonesets supported in ISN07.
! SERVSINV
Server Subtending Node Inventory table, which lists logical nodes that subtend
GWC peripherals. These are not media gateways, but they are categorised as
gateways from a network architecture perspective. Two types are supported, each
controlling a different capability:
DPT Dynamic Packet Trunk control, i.e. SIP-T trunks for inter-CS communication.
AUD Audio control, i.e. announcements and bearer capabilities provided by the
UAS.
Each entry provides information about a subtending node, including:
" Node type and number, e.g. AUD 0
" Controlling GWC, identified by ID defined in table SERVRINV
" Number of terminals supported (2048)
" SIPT option (DPT only)

C2.5 Provisioning Gateways, Carriers and Trunk

Endpoints
This section describes the datafill that enables CS2000 to support trunk calls that
terminate on TDM-side trunks served by gateways.
C2.5.1 The CS2000 Core View

The DTCEX option of table SERVRINV enables details of the PSTN trunks controlled
by a GWC to be datafilled against it (in tables CLLI, TRKGRP, TRKSGRP, TRKOPTS
and TRKMEM) as if it were a TDM-side DTC (Digital Trunk Controller). See section
C2.2 on page 183 for details. These can then be identified and selected by CS2000 Core
call processing by means of a trunk TID (terminal identifier) as defined in table
TRKMEM, which the GWC maps on to an EID (endpoint identifier) that can be
recognised by the media gateway on which the trunk is physically terminated.
C2.5.2 The GWC View

GWCs and trunk media gateways are separately provisioned with the address information
they need to communicate with each other. For each media gateway controlled by a GWC,
GWC datafill specifies the gateway IP address for device control messaging, the UDP
port and the TDM-side endpoints available. Similarly, media gateway datafill specifies
information about its controlling GWC, including the UDP port numbers and IP addresses
to be used for device control messaging (and for Q.921 user signalling backhaul in the
case of ISDN trunks).
For each GWC, the GWC Manager is used to define how trunks are mapped on to the
carriers and endpoints on its subtending gateways. The endpoint name format depends on
the carrier type, as follows:
! For E1 carriers, the endpoint name format is:
<gateway>.E1_<card slot><card port>.<timeslot>
An example of a complete trunk endpoint name is PVG99.E1_403.27, which would
identify timeslot 27 on the E1 carrier terminated in slot 4, port 3 on gateway PVG99
(the port number is padded with a 0 but the card number is not).
! For STM-1 carriers, the endpoint name format is:
<gateway>.STM_<LP><port>01_VC4VC12_01<TUG-3><TUG-2><TU>.<timeslot>
An example of a complete trunk endpoint name is
PVG99.STM_020101_VC4VC12_01361.01.07, which would identify
gateway = PVG99, port = LP/2 SDH/1
link type = STM-1 with VC-4/VC-12/E1 multiplexing
TUG-3 number = 3, TUG-2 number = 6, TU number = 1, E1 timeslot = 07
After a trunk endpoint name has been specified to the GWC EM, the name can be used in
ASPEN or H.248 device/media control messages between the GWC and the gateway.
For information about the procedures for adding GWC, gateway and trunk endpoint
datafill, see the document CS2000 Configuration (NN10193-511).

C2.6 Provisioning Inter-CS Trunks

This section describes the datafill that enables CS2000 to support trunk calls that
terminate on DPTs (Dynamic Packet Trunks) to packet network destinations served by
other CS2000s. DPTs require datafill in two sets of tables:
! DPTs are datafilled via tables SERVRINV (GWC identification), SERVSINV
(allocation of GWC as SIP-T GWC), OFCENG (source hostname), CLLI,
TRKGRP, TRKSGRP (standard trunk group data), TRKOPTS (DPT trunk group
characteristics) and DPTRKMEM (allocation of SIP-T trunks to trunk groups). See
section C2.6.2 on page 192 for details.
! VRDNs are datafilled via tables SERVRINV (GWC identification), VRDNINV
(allocation of GWC as VRDN), MGCINV (remote MGC/CS served by VRDN) and
TELEPROF (telephony profile for remote MGC/CS). See section C2.6.3 on page
193 for details.
! Session Server datafill is provided by table SIPLINK. See section C2.6.4 on page
193.
Section C2.6.1 places the detailed information in context by providing a DPT overview.
C2.6.1 Overview
the duration of a given call, and is then returned to the pool for re-use.
Figure 13 on page 63 illustrates how DPT GWCs interact with these other units to support
inter-MGC communication via SIP / SIP-T.

DPTs do not use the static point code and circuit concepts on which CCS7 is based (OPC,
DPC and CIC); a DPT can handle a call to/from any other CS in the network. To enable
dynamic trunk provisioning, a telephony profile name is passed as part of the SIP-T
INVITE message used to set up an inter-CS call. This profile maps on to a set of trunk
subgroup characteristics, including protocol support, which are associated with a
particular trunk subgroup by means of CS2000 datafill.
Each CS2000 is identified by means of a unique hostname, which is specified as an office
parameter in table OFCENG. Each combination of source hostname, destination
hostname and telephony profile name is unique across the network. This makes it possible
for network operators to agree on the services and protocols to be supported between pairs
of CSs, and to ensure that datafill on different CSs is co-ordinated. The information
provided in the INVITE message ensures that the destination CS selects appropriate
resources to handle the incoming SIP-T call.
C2.6.2 Tables Used to Datafill DPTs

In addition to datafill in tables SERVRINV (GWC identification) and SERVSINV
(allocation of GWC as SIP-T GWC), DPT trunk provisioning requires the following
datafill:
! OFCENG
The source hostname to be used for a given CS2000 is specified via office parameter
HOST_MGCNAME in table OFCENG.
! TRKOPTS
For each trunk group defined to support SIP-T trunks, table TRKOPTS is used to
specify the following items of information:
" The DYNAMIC option to indicate that the trunk group consists of DPTs. The
following further information is provided about each DPT trunk group:
# The protocol to be used, which for SIP-T is SIPBCPT.
Note: ISUPPLUS denotes BICC, but this is not supported in ISN07.
# The signalling network type, which for SIP-T is IP
Note: For ISUPPLUS (BICC), the signalling network type is SS7.
# The bearer network type, which for SIP-T is IP.
# The application, which for SIP-T is DPT.
" A destination hostname with which the trunk group can communicate, as
defined in table MGCINV.
" A telephony profile name, as defined in table TELEPROF, to be used in
communicating with the destination hostname.
! DPTRKMEM
DPT Trunk Member table, which is used to allocate SIP-T trunks to trunk groups.
The DPTRKMEM entry for a trunk group specifies the trunk group name (as
defined in table CLLI) and the range of SIP-T trunks potentially available for that
trunk group. This range determines the maximum size of the trunk group, i.e. the
maximum number of simultaneous DPT calls that it can support. If the range
specified for a trunk group is 1 100, for example, that trunk group would be able to
support a maximum of 100 DPT calls.

C2.6.3 Tables Used to Datafill VRDNs

In addition to datafill in table SERVRINV (GWC identification), VRDNs require datafill
in the following tables:
! MGCINV
Media Gateway Controller Inventory table, which lists the remote MGCs (Media
Gateway Controllers) with which peer-to-peer communication is supported. Each
entry in this table provides information about a particular peer MGC (e.g. contact
information for a VRDN belonging to another CS2000), including the following:
" Domain name
" IP address
" Protocol to be used for communication (UDP or SCTP)
! VRDNINV
VRDN Inventory table, which lists the VRDN GWCs on the CS2000. Each entry in
this table provides information about a particular VRDN, including the following:
" Numeric VRDN ID, e.g. VRDN 2
" GWC configured as VRDN, identified by ID defined in table SERVRINV,
e.g. GWC 3
" List of one or more remote MGCs with which the VRDN is to communicate
(RMGCLIST)
! TELEPROF
Telephony Profile table, which lists telephony profiles. Each entry in this table
associates a telephony profile name with a remote MGC domain name (as specified
in table MGCINV). Telephony profile names defined in table TELEPROF can
subsequently be associated with SIP-T trunk definitions in table TRKOPTS, thus
indicating which CCS7 protocol variants can be dynamically provisioned against
them, and can be specified in SIP-T INVITE messages.
C2.6.4 Tables Used for Session Server Datafill

Table SIPLINK Contains the access link information that is used to direct calls to the
appropriate SIP server. This information is also used by Session Server devices for
mapping incoming calls.

C2.6.5 Trunk Provisioning Flowchart (Packet-Side)
START
Does
Add new N destination N
members to existing for new trunk group
SIP-T trunk group already exist
[Y/N]? [Y/N]?
Add new destination
Y Y (name of remote CS2000)
to table MGCINV
Add new trunk group
name to table CLLI
Is the
new destination N
Add trunk group data served by an existing
to table TRKGRP VRDN
[Y/N]?
Y
to table TRKSGRP Add new VRDN definition
to table VRDNINV

to table TRKOPTS Add remote MGC name
to RMGCLIST
in table VRDNINV
Are
the new trunks Y Add remote MGC name
required to increase to table TELEPROF
capacity
[Y/N]?
N Add new SIP-T GWC
definition to table
SERVSINV The decision about whether
Add new range of SIP-T to add a new SIP-T GWC or a
trunks to table DPTRKMEM new VRDN depends on the
BSY SIP-T pool from amount of capacity that
DPTTRM level of MAP needs to be engineered to
handle the traffic between
BSY SIP-T pool members two CS2000s (see section
from DPTMEM level of MAP B1.4.7 on page 66 for details)
RTS SIP-T pool from
DPTTRM level of MAP
RTS SIP-T pool members

from DPTMEM level of MAP
FINISH
Figure 54: Provisioning DPTs

C2.6.6 Defining Connection Roles for Packet Network Trunks

For each call routed through a CS2000, either the ingress agent or the egress agent must
be assigned the master role, and the other must be assigned the slave role. The slave agent
must obtain its endpoint information and send this to the master agent via a peer-to-peer
message. The master agent must wait for receipt of the slave agents endpoint
information, then send its own endpoint information back to the slave agent via a
peer-to-peer reply message, allowing the bearer path can be established.
ISN03 feature A59025876 defined an algorithm for dynamic assignment of connection
role (master or slave) to the ingress and egress agents involved in a call.
The algorithm enables DPTs to interwork with DPT, UAS and ISUP. DPT-to-DPT
interworking was previously not supported because all DPTs were assigned the master
role by default on restart. New default values:
! DPTs are source_slave
! UAS trunks are any_role
Both default values can be dynamically modified to master or slave, as required,
depending on the other agent type involved in a given call, in accordance with Table 18.
Table 18: Algorithm to determine the connection role for both agents
Default / preferred agent roles Result of dynamic role modification
Perm1 Perm2 Incoming GWC Outgoing GWC

slave_role source_slave ==> slave master
source_slave master_role ==> slave master
master_role source_slave ==> master slave
source_slave any_role ==> slave master
any_role source_slave ==> slave master
master_role slave_role ==> master slave
slave_role master_role ==> slave master
master_role any_role ==> master slave
any_role master ==> slave master
slave_role master_role ==> slave master
any_role slave_role ==> master slave
source_slave source_slave ==> slave master

C2.7 Provisioning Lines

CS2000 lines are supported by line gateways controlled by CS2000 GWCs. CS2000 has
no knowledge of the physical units on which the lines terminate. Depending on the type
of line to be supported, CS2000 perceives lines as belonging either to line groups
(MG9000 lines, customer LAN lines, cable lines and CentrexIP clients) or V5.2 interfaces
supporting V5.2 Access Networks (ANs).
Note: The term Access Network typically denotes a multiplexer or hub unit that houses
physical line cards. The abbreviation AN is therefore sometimes taken to mean Access
Node rather than Access Network, but this is incorrect.
Datafill is used to specify logical frame and unit identifiers that call processing can
interpret as if they defined the physical location of slots housing traditional line cards.
Before lines can be provisioned, it is essential to provision the GWC that is to control the
line group or V5.2 interface. This involves datafilling table SERVRINV, as described in
section C2.4 on page 189, and specifying POTSEX as the server exec type.
The next step is to provision the line group or V5.2 interface. Line group provisioning is
described in section C2.7.1 and V5.2 interface provisioning is described in section C2.7.2
on page 197.
The final step in provisioning lines is to provision individual lines. To ensure that
consistency is maintained between the different data schema tables that may be updated
to reflect the provisioning of a line, this is done using the SERVORD+ provisioning
utility. See section C2.7.3 on page 199 for further information.
C2.7.1 Line Group Provisioning (Non-V5.2 Lines)

Steps involved:
! Define LG (line group) as a host type in table SITE.
Note: This step is recommended, but is not mandatory.
! Use table LGRPINV (Logical Group Inventory) to store the following information
about the line group:
" GRPNO
Line group number comprising:
# Host identifier
LG if this has been datafilled in table SITE, otherwise HOST.
# Frame number (0-511)
# Unit number (0-9)
Note: For CS2000, these frame and unit numbers are purely logical
identifiers. They provide information equivalent to that used in defining the
physical location of slots housing traditional line cards.
" SRVRNAME
The name and number of the GWC controlling the line group, as previously
defined in table SERVRINV.
Note: Table LGRPINV also allows field GRPTYPE to be used to specify the group
configuration as S (single), M (multiple) or C (combined), but this capability is for
future use, and in ISN07 the value specified has no effect.

C2.7.2 V5.2 Interface Provisioning

This section describes V5.2 interface provisioning in terms of the tables used to store
interface data. These tables are not edited directly; they are updated to reflect information
provided via the V5.2 menus of the CS2000 Core Manager.
Table GPPTRNSL
Table GPPTRNSL [1] contains an entry for each V5.2 interface supported. Each entry
provides information via the following fields:
AMCNO This defines a four-character site identifier, together with frame and unit
numbers that together allow the interface to be identified.
Note: The information provided by the AMCNO field is equivalent to that
provided for line groups via the GRPNO field of table LGRPINV (see section
C2.7.1 on page 196), i.e. logical identifiers that call processing can interpret
as if they defined the physical location of slots housing traditional line cards
CSPMNO This specifies that the interface is hosted by a GWC, and provides the GWC
identifier as defined in table SERVRINV.
IP_V52 This has the following subfields:
V5LINKID Used to assign identifiers to each of the E1 carriers (up to 16) that
make up the V5.2 interface.
V5ID Unique identifier of the V5.2 interface.
V5PRID V5 provisioning set identifier corresponding to a particular way of
assigning the C-channels for the interface, as defined in table
V5PROV.
MAXLINES Maximum number of line endpoints (up to 2048) that can be supported
via the interface, i.e. the AN size.
Note: Although any size may be specified, only the AN types/sizes
listed below are fully supported. If an AN size other than one of these
is specified, the number of line endpoints actually reserved will be
rounded up to the next supported AN size, e.g. a size of 375 would be
accepted, but would cause 480 lines to be reserved.
Type Size Max. ANs Lines reserved
Small120 120 53 6360 [1]
Small240 240 26 6240 [1]
Small480 480 13 6240 [1]
Small 672 9 6048
Medium 1344 4 5376 [1]
Large 2048 3 6144 [1]
V5SIGID Signalling profile identifier corresponding to a set of signalling
characteristics, as defined in table V5SIG.
V5RING Flexible ringing cadence identifier corresponding to a ringing cadence
profile, as defined in table V5RING.
[1] This is the maximum number of V5.2 line endpoints that can be defined for a given
GWC using only ANs of this size without exceeding the GWC maximum of 6400
lines. Using a mix of AN sizes, the maximum number of V5.2 lines that can be
defined for a GWC is 6384.
[1] Table GPPTRNSL is so called for historical reasons, because V5.2 lines served by DMS-MMP switches are
terminated on GPP (Global Peripheral Platform) units. It can have a theoretical maximum of 1000 entries.

Table V5PROV
A V5 provisioning set defines the C-channel characteristics of a V5.2 interface, i.e. which
channels are used as C-channels and what type of signalling they convey. The
provisioning sets available are defined in table V5PROV, and each V5.2 interface
definition in table GPPTRNSL refers to one of these provisioning set definitions to
allocate C-channels. A given provisioning set definition can be used for any number of
V5.2 interface definitions that have the same C-channel characteristics.
Up to four C-channels (two active channels and two backup channels) can be allocated for
a given V5.2 interface via a provisioning set. Table V5PROV allows the following
information to be defined for each C-channel in a provisioning set:
CHNL_ID Logical channel identifier in the range 0-9
LNK Identifier of the link (PCM30 carrier) supporting the C-channel (1-16)
CHNL Identifier of the channel to be used for the C-channel (16 or 15)
CPATH The type of signalling to be conveyed over the link, which is one of:
CNTRL Control signalling (BCC, protection, link control)
PSTN PSTN signalling (LAP-V5 DL equivalents of analogue signals)
PROT1, PROT2
The links to be used as alternatives in the event of a failure.
Table V5SIG
Different national markets have different requirements for signalling. Table V5SIG
allows a set of signalling characteristics to be defined as a signalling profile, and
associated with a V5.2 interface by means of a reference to V5SIG from the interface
definition in table GPPTRNSL. Each CS2000 supports one predefined profile identified
as DEFAULT, and can also support up to 127 other named profiles defined in table V5SIG.
This powerful and flexible mechanism facilitates the rapid deployment of V5.2 interfaces
in new national markets.
Table V5RING
V5.2 allows up to 32 different ringing types or cadences to be identified in messages sent
to the AN. In a given market or network, ringing type 0 denotes national standard ringing,
while ringing types 1-31 can be used to denote distinctive ringing cadences required for
feature or service support.
The characteristics of the physical ringing associated with each ringing type are
determined by national standards and/or bilateral agreements. Physical ringing is
implemented by the AN, and is the responsibility of the AN supplier. The role of the V5.2
protocol is to use V5.2 to tell the AN which ringing type is required in a given scenario.
Table V5RING allows mappings to be defined between ringing cadences as known to the
AN (ring chars 0-15) and cadences as known to V5.2 call processing on the CS2000 Core
(ringing types 0-31). These mappings can then be assigned to one or more V5.2 interfaces
via table GPPTRNSL.

C2.7.3 Provisioning Individual Lines and their Attributes

The final step in provisioning lines is to define individual lines and their attributes, which
is done using the SERVORD+ provisioning utility. This section briefly describes the data
schema tables that are updated as a result of SERVORD+ provisioning (to ensure datafill
consistency, direct editing of these tables is not supported).
Analogue Line Provisioning
Table LNINV (Line Inventory) was originally designed to specify the type of line card
housed in a physical line slot, and to map this on to a DN. For each CS2000 line, the line
card type is specified by one of the following logical card codes in the CARDCODE field:
! GWLPOT for lines belonging to line groups
! V5LOOP for V5.2 PSTN lines
The SERVORD+ NEW command is used to define each line. The SERVORD utility is
accessed via the CS2000 line provisioning application. The NEW command requires the
following information to be provided, and uses it to update the LNINV and IBNLINES
tables (see A59029095 for details):
! The DN (Directory Number) to be assigned to the line.
! An LEN (Line Equipment Number) indicating where the line is physically
terminated. For a CS2000 line, the LEN comprises the identifier of a line group (as
previously defined in table LGRPINV) or a V5.2 interface (as previously defined in
table GPPTRNSL), plus numbers denoting a virtual shelf and slot.
For each line defined in table LNINV, table IBNLINES specifies the logical line type
(IBN), the DN, and other basic attributes of the line. Table IBNLINES also lists the
features assigned to each line by means of the SERVORD+ ADO (Add Option)
command. The more detailed options associated with each feature are recorded in table
IBNFEAT for each LEN.
CentrexIP Line Provisioning
CentrexIP lines serving remote clients are perceived by CS2000 as equivalent to legacy
business set lines. Table KSETINV specifies the logical line type for each line card slot
reserved for a business set or equivalent. For CentrexIP lines, the logical line type
corresponds to one of the four types of Etherset or soft client supported in ISN07:
I2001 i2001 Etherset
M6350 m6350 soft client
Table KSETLINE is used to store information equivalent to table IBNLINES (DN, LEN
and assigned features) and table KSETFEAT is used to store information equivalent to
table IBNFEAT (detailed feature-related information).
Provisioning Time Zone Information for Lines
For a CS2000 serving line gateways in two or more time zones, the date and time provided
by CS2000 Cores Time Of Day (TOD) clock is not valid for gateways in different time
zones. Timezone data for each alternative time zone is specified in table MULTITZ
relative to the Core TOD, and the MTZ (Multiple Time Zone) line option can be assigned
via SERVORD+ to ensure that a line uses the appropriate set of MULITZ-defined data..
This ensures that services such as WUCR (Wake Up Call Request) use the correct local
time. See A59038784 for details.

C2.8 Provisioning Gateways and Line Endpoints

This section describes the datafill that enables CS2000 to support calls that terminate on
lines served by media gateways.
C2.8.1 The CS2000 Core View

The POTSEX option of table SERVRINV enables details of lines belonging to gateway
line groups and V5.2 interfaces to be datafilled in tables LNINV and LGRPINV or
GPPTRNSL as if the lines terminated on line cards in the CS2000. See section C2.7 on
page 196 for details. These can then be identified and selected by CS2000 Core call
processing by means of a DN and an LEN (Line Equipment Number) indicating where
the line is physically terminated. For a CS2000 line, the LEN comprises the identifier of
a line group (as previously defined in table LGRPINV) or a V5.2 interface (as previously
defined in table GPPTRNSL), plus numbers denoting a virtual shelf and slot, which are
mapped at the GWC on to a physical endpoint on a media gateway.
C2.8.2 The GWC View

IP addresses for line media gateways are typically assigned via DHCP, and are obtained
by the GWC via DNS queries based on the gateways FQDN. A line media gateway
typically discovers the IP address of its GWC by querying an RMGC (Redirecting Media
Gateway Controller) as part of its initial configuration process.
A media gateway must be in the same IP address space as the GWC controlling it. In
ISN07, media gateways must not be behind NAT or NAPT devices. Nortel Sales
Engineering should be consulted for information about VPN extension techniques to
circumvent issues caused by NATs, packet filters, firewalls and so on.
For each line media gateway controlled by a GWC, GWC datafill specifies the following:
! FQDN (Fully Qualified Domain Name)
! IP address
Line gateway IP addresses are assigned via DHCP, and are obtained by the GWC
either via queries to a DNS server or via RMGC functionality on the GWC itself.
To indicate that the GWC should dynamically discover the IP address of a line
gateway by means of a DNS query based on the gateways FQDN, the IP address
specified in gateway datafill at the GWC should be 0.0.0.0.
If the mapping between a gateways FQDN and its IP address is static, the real IP
address can be specified directly in GWC datafill when the gateway is provisioned.
! Control protocol
! UDP port (2427)
! Gateway profile (codec and packetisation info).
The IP address of the GWC is provided to each line gateway when it is initialised.
For each GWC, the GWC Manager is used to define how logical lines are mapped on to
the physical endpoints on its subtending gateways. A line endpoint is identified to the
GWC Manager by means of the gateway name and the permanent termination name. An
MTA line gateway, for example, identifies its line endpoints as aaln/1 or aaln/2.

After a line endpoint has been identified to the GWC Manager, its name can be used in
device/media control messages exchanged by the GWC and the gateway. For an MTA
gateway controlled via NCS, an example of a fully qualified line endpoint name is
aaln/1@rgw-2567.whatever.net
For information about the procedures for adding GWC, gateway and trunk endpoint
datafill, see the document CS2000 Configuration (NN10193-511).
C2.8.3 Line Gateway Provisioning Example

This section describes the sequence of events involved in provisioning a line media
gateway attached to a cable access network. The elements involved are:
! Operating company craftsperson at Network Operation Centre
! CS2000 provisioning applications running on Sun Netra server on OAM&P VLAN
! CS2000 Core (and CS2000 Core Manager)
! GWC for MTA line media gateway (and GWC EM)
! Centralised CMTS / MTA management application controlling
" DNS (Domain Name Server)
" LDAP (Lightweight Directory Access Protocol) server
! CMTS at cable head-end, controlling servers for subtending MTAs
" DHCP (Dynamic Host Configuration Protocol) server
" TFTP (Trival File Transfer Protocol) server
! MTA line media gateway
Figure 55 is a simplified view of the network configuration and information flows for
MTA provisioning. See Table 19 on page 202 for explanations of the annotations.
Craftsperson 1
at NOC CMTS / MTA
management application
4a Central servers
3a 2 LDAP
CS2000 provisioning 8a server
applications on DNS
Sun Netra server server
8b
4b 3b 5c 6c
5b 6b
Cable access network
CMTS
GWC for DHCP TFTP

CS2000 MTA
Core server server
gateway
Backbone 5d 6d
packet 5a 6a
CS LAN (CallP VLAN) network
7 MTA
PP8600 gateway
routers
Figure 55: Information flows for MTA gateway provisioning

The sequence of events is summarised in the following table.
Table 19: Sequence of events for MTA gateway provisioning

Step From To Via Purpose / content
1 At NOC Craftsperson decides which GWC will host

MTA gateway
NOC provides gateway data to LDAP
LDAP
2 NOC LDAP server:
server
FQDN, profile, GWC IP address
CS2000 NOC provides gateway data to CS2000
3a NOC provisioning XML provisioning applications:
applications FQDN, IP address = 0.0.0.0
CS2000 CS2000 provisioning applications provision
3b provisioning GWC GWC EM GWC with gateway data:
applications FQDN, IP addr=0.0.0.0
CS2000 NOC provides line data to CS2000
4a NOC provisioning SERVORD+ provisioning applications:
applications DN and service information
CS2000 CS2000 provisioning applications provision
CS2000 Core
4b provisioning CS2000 Core with line data:
Core Manager
applications DN and service information
5a MTA DHCP DHCP On first activation, MTA gateway sends

server DHCP request to DHCP server on CMTS
DHCP server requests central DNS server
DHCP
5b DNS server DNS to update gateway data:
server
FQDN, IP address
DHCP DNS server sends response / confirmation
5c DNS server DNS
server to DHCP server
DHCP
5d MTA DHCP DHCP server sends IP address to MTA
server
TFTP MTA requests TFTP server to provide

6a MTA TFTP gateway configuration data:
server
gateway profile, GWC IP address
TFTP LDAP TFTP server requests central LDAP server

6b LDAP to provide gateway configuration data for
server server
MTA
LDAP TFTP LDAP server sends gateway configuration
6c LDAP
server server data for MTA to TFTP server
TFTP TFTP server creates configuration file and
6d MTA TFTP
server downloads it to the MTA gateway
MTA sends RSIP registration request to
7 MTA GWC RSIP
GWC
GWC requests DNS server to provide IP
8a GWC DNS server DNS
address corresponding to MTAs FQDN
DNS server sends IP address of MTA
8b DNS server GWC DNS
gateway to GWC

C2.9 Provisioning Tones and Announcements

Tones and announcements can be identified by CLLIs in the same way as trunk
destinations, which means that a call can be routed to terminate on a tone or
announcement by means of the translations and routing process described in Chapter C3:
Translations and Routing.
See Chapter G2: CS2000 Support for Tones for information about the datafill used to
define tones as trunk destinations.
See Chapter G3: CS2000 Support for Announcements for information about the datafill
used to define announcements as trunk destinations.

Chapter C3 Translations and Routing
The aim of translation is to analyse dialled numbers to determine the correct trunk route,
line termination or treatment to use for call completion. CS2000 uses two types of
translation process, each with its own set of translation tables:
! Universal translations for calls via the public network (see section C3.5)
! IBN translations, which support a range of facilities originally designed for business
use, such as feature codes and various types of abbreviated dialling (see section
C3.3)
CS2000 can use both types of translation on a given call, which makes more complex
number analysis possible. This chapter discusses CS2000 translations and routing under
the following headings:
! Section C3.1: Overview
! Section C3.2: NCOS Screening
! Section C3.3: IBN Translations
! Section C3.4: Indirect Access to Universal Translations
! Section C3.5: Universal Translations
! Section C3.6: Codec Selection via Translations
! Section C3.7: Routing
! Section C3.8: Support for CCD (Clear Channel Data) Calls
CS2000 also uses reverse translation to support the display of diallable calling party
numbers on called party terminals (see section F2.2.9.2 on page 544 for details).

Translations and Routing Software Communication Server Capabilities
C3.1 Overview
For calls via the public network, CS2000 uses universal translations for the analysis of
dialled numbers to determine the correct route to use for call completion. Dialled numbers
are not, however, presented directly to universal translations. CS2000 uses Centrex
software, which means that the following types of preliminary screening and translation
can be performed before numbers are passed to universal translations, which can thus
focus more efficiently on analysing numbers in terms of the PSTN numbering plan:
1 NCOS (Network Class Of Service) screening for direct subscriber access. The
NCOS value assigned to a line or incoming trunk determines the types of call that
can be made from that line or trunk. See section C3.2 for details.
2 IBN (Integrated Business Network) translations for direct subscriber access (and for
non-interconnect incoming trunks). These are responsible for feature (de)activation,
for access to emergency/assistance services, and to initiate digit modification for
local calls that require the area code added to the originating number for billing
purposes. Calls that pass screening are then passed to universal translations. See
section C3.3 for details.
3 Access and authorisation code checks for indirect access via network interconnect
services, which rely on the Centrex feature Meridian Off-Net Access (MONA) to
provide security. See section C3.4 for more information.
Figure 56 is an overview of the translation process for calls from various sources.
Direct subscriber access Incoming trunk Indirect subscriber access (to

access alternative operator network)
NCOS screening
IBN translations Access code and

Note: Within a private authorisation screening
network (e.g. Centrex dial
plan or VPN), some call
types may be handled
entirely by IBN translations
LINEATTR
Links between IBN translations and universal translations
Universal translations
Line served by Outgoing trunk

translating CS2000
Figure 56: Overview of CS2000 translations and routing for PSTN calls
Note: CS2000 supports indirect VPN access as well as indirect access to alternative
long-distance carriers. In this case, IBN translations are entered after authorisation
screening, not universal translations.

Communication Server Capabilities Translations and Routing
C3.2 NCOS Screening

Every CS2000 line and trunk belongs to a customer group, and every customer group is
assigned a list of Network Class Of Service (NCOS) values. An NCOS is a numeric code
that denotes a particular combination of call types that are permitted or barred. Table 20
shows a typical minimum list of NCOS values and associated combinations of call types
that could be defined for a customer group. For a typical customer group, this minimum
list would be augmented to allow about 50 combinations of call types to be identified by
means of NCOS values (since NCOS is a 1-byte field, the maximum is 256 identifiable
call type combinations for a customer group).
Table 20: Typical minimum list of NCOS values for a customer group
NCOS values (in the column for each NCOS value,
Type of call Y = call type permitted, N = call type to be barred)
0 1 2 3 4 5 6 7 8 9 10 11 12 13
Prem. Rate Adult Y N N N N N N N N Y N Y N Y
Prem. Rate Info. Y Y N N N N N N N Y Y Y Y Y
International Y Y Y N N N N Y N N N Y Y N
Mobile Y Y Y Y N N N N N Y Y N N N
Operator Y Y Y Y Y N N Y N Y Y Y Y Y
National Y Y Y Y Y N N Y Y Y Y Y Y Y
Local Y Y Y Y Y Y N Y Y Y Y Y Y Y
Free Y Y Y Y Y Y Y Y Y Y Y Y Y Y
The default NCOS value of 0 means that all call types are permitted, and that any required
barring is performed later in translation or by means of feature processing.
Because all lines and trunks belong to customer groups (see section C3.3.1), and are thus
assigned NCOS values, call originations can be screened on the basis of the associated
NCOS value before the call enters IBN translations. This screening can be implemented
in either of two ways:
! Direct CODEBLK screening
Table NCOS defines a Code Restriction Level (CRL) value for each NCOS,
indicating whether the combination of call types identified by that NCOS is to be
BLOCKED or ALLOWED. For each number prefix or special number that can be
dialled from a customer group, table CODEBLK lists all the CRLs that are to apply,
thus establishing a link between the NCOS value assigned to an incoming trunk and
the types of call that can be made from that trunk.
! Preliminary translator screening
Instead of directly specifying a CRL for every NCOS, table NCOS may instead
specify preliminary blocking translators for some NCOS values. Table CODEBLK
still controls screening for NCOS values with a directly associated CRL. For other
NCOS values, however, table IBNXLA is consulted to find the related preliminary
translators, each of which will specify blocking and routing to treatment for calls to
a given number prefix or special number. The set of blocking translators for a given
NCOS thus defines (by exception) the types of call that can be made from incoming
trunks with that NCOS value.

To simplify CS2000 administration, it is recommended that one of these methods is used

for all residential subscribers and the other for all business subscribers. Table CODEBLK
can contain only 256 entries, which means that direct CODEBLK screening can typically
be specified only for about five customer groups. It should therefore be used for
whichever type of subscriber is less common on a given CS2000, with preliminary
translator screening being used for the other.
Note: Call barring restrictions imposed by NCOS screening can be overridden by the
dialling of an authorisation code before the called party DN. The ACR option in tables
NCOS and IBNXLA determines whether this capability is available.
For multi-location customer groups linked by means of IBN7 ISUP trunks (including
IBN7 encapsulated in SIP-T), NCOS screening can take into account both the originating
line NCOS and the terminating line NCOS, because originating NCOS information can
be conveyed in the IAM.
C3.3 IBN Translations

Note: Customers are free to define and use whatever naming conventions are most
suitable for their network. The translator names used in this section are merely examples,
chosen to illustrate naming conventions that some CS2000 customers have found to be
convenient in practice for the classification and handling of different call types. Similarly,
customers are free to define how calls should proceed through translations; this section
merely illustrates the techniques involved.
C3.3.1 IBN Translators

IBN translations require every line and incoming trunk to belong to a customer group. For
each customer group, table CUSTHEAD has an entry that specifies the name of the
translator to be used by that group, and also defines some of its characteristics.
C3.3.1.1 Translator Names

IBN translations require every line and incoming trunk to belong to a customer group.
Associated with each customer group is a general-purpose translator name, which is
specified in table CUSTHEAD. These could have names of the following form:
! RESxxxIX for a residential customer group, e.g. RES118IX for residential customers
with an area code of 0118.
! BUSxxxIX for a business customer group.
where xxx is derived from the customer group name and uniquely identifies the group.
Large multi-location business customers could have translator names that indicate the
company and location instead of BUSxxx.
Special translator names can be used for quickly recognising and acting on feature codes.
Such names can be shared by all business or residential customer groups:
! RESFXLA and RESOXLA for * and # codes for all residential subscribers.
! BUSFXLA and BUSOXLA for * and # codes for all business subscribers.

C3.3.1.2 Digit Collection Schemes

Table CUSTHEAD defines the digit collection scheme to be used by a customer group
translator when analysing a called party number. CS2000 supports three basic schemes:
NDGT This is the most common scheme. No assumptions are made about the
structure of dialled numbers, and each digit is simply passed on to translations
as it is received.
POTS This is an office-wide scheme in which the number of digits collected before
being passed on to translations depends on the initial digits dialled, and is in
accordance with the public network numbering plan.
DIGCOL This is a type of scheme rather than a scheme name; DIGCOL scheme names
are actually defined in table DIGCOL. They allow alternative collection
strategies to be used depending on initial digits dialled, and are typically used
for business customer groups, to specify different collection schemes for
different types of call:
COL For calls made using a private numbering plan, digit collection can be
made to reflect the structure of the numbering plan, e.g. four digits
could be collected for calls to local extensions, and three prefix digits
could be collected for calls to other sites.
RPT For public network calls, digits can be reported when dialled.
C3.3.2 Tables IBNXLA and XLANAME

For public network calls, the primary function of the IBN translation tables IBNXLA and
XLANAME is to select an index number that can be used as a key into table LINEATTR
(see section C3.3.3), which in turn provides an appropriate entry point into universal
translations. Within a private network (e.g. Centrex dial plan or VPN), some call types
may be handled entirely by IBN translations
The source of a call determines its customer group, and table CUSTHEAD maps the
customer group on to its translator name, as listed in table XLANAME. Table
XLANAME maps the translator name directly on to a LINEATTR index number, but this
is a default index number that may not be appropriate for all calls. Translator names that
end in IX are (by convention) IBN translators, and indicate that table IBNXLA should be
consulted to determine whether there is a more appropriate index number for a given call.
Typically, there are IBNXLA entries for the following types of call:
! Local calls beginning with the dialled digits 2 to 9
For a customer group translator such as RES118IX, IBNXLA would contain the
entries RES118IX 2 to RES118IX 9, and would associate all of them with a
LINEATTR index number, which would in turn ensure that the appropriate area
code is prefixed to the calling number for billing purposes.
! Calls to national service numbers beginning with the dialled digit 1
These are associated with a LINEATTR index number by means of an entry such
as RES118IX 1, and this in turn ensures that a CS2000 identifier is appended to the
calling number for tracing purposes.
Because there is no IBNXLA entry beginning RES118IX 0, trunk calls and international
calls are dealt with via the default LINEATTR index number associated with the customer
group translator via table XLANAME.

Note: There are also entries in table IBNXLA for dealing with feature activation requests.
These entries are common to all customer groups and are not associated with a particular
customer group translator. They activate feature software without any further translation
or any reference to table LINEATTR. For example, an entry beginning RESFXLA 70 FEAT
CFWP would control Call Forward Programming.
C3.3.3 LINEATTR Contents and Functions

Entries in table IBNXLA contain index numbers that are used as keys into table
LINEATTR for the selection of universal translators such as:
! PSTNPXLA
Prefix translator for nodal and outgoing international calls
! xxxPXLA
Prefix translator for incoming calls to CS2000 identified by xxx.
! SRVCPXLA
Prefix translator for emergency/assistance calls.
! RESxxxPX
Preliminary translator for adding area code as prefix to originating number for
billing of local calls.
Note: These are not tables, but it can be convenient to regard a series of like-named
translators as a table performing a particular type of translation function.
C3.4 Indirect Access to Universal Translations

Indirect access to universal translations is provided via indirect access screening and
authorisation checks over network interconnect trunks, which are described in detail in
Chapter F11: Indirect Access.

C3.5 Universal Translations

Note: This section provides an overview of the translations process, with examples
chosen to illustrate the most important stages involved. It is not intended to be exhaustive.
C3.5.1 Stages in Translation

CS2000 univeral translations analyse the following dialled elements in turn:
1 Prefix
2 Country code
3 Area code
4 Office code and station number
In most cases, only some of these elements will need to be analysed for appropriate call
routing to take place. For an outgoing trunk call, for example, translation would stop as
soon as the destination area code was recognised; and for a nodal call only the station
number would need to be analysed.
C3.5.2 Translation Results

There are various possible results for the analysis/translation of a dialled number element,
of which the following are the most important for universal translations:
RTE Destination name has been found (though further digit collection may be
necessary)
CONT Continue translation using another translation table
DMOD Digit modification is required
TRMT Treatment for an exception or failure condition
Corresponding to each of these possible results is a selector that provides any further
information needed to implement the result, e.g. the name of a route list for RTE or the
name of a translator for CONT.
C3.5.3 Universal Translation Tables

Corresponding to each translation stage is a set of translation tables, as follows:
! Prefix translation tables
PXHEAD, PXCODE, PXRTE
! Country code translation tables
CTHEAD, CTCODE, CTRTE
! Area code translation tables (FA = foreign area)
FAHEAD, FACODE, FARTE
! Office code translation tables for numbers served by this CS2000
OFCHEAD, OFCCODE, OFCRTE

In each case, it is the CODE table that actually defines the translations to be performed.
Each entry in the CODE table is a translator that specifies the translation result for a given
digit range. If this translation result is the selection of a route (RTE), the CODE translator
also specifies a destination number corresponding to one of the entries in the RTE table.
Translation ends when a line or trunk route has been selected via the final RTE table to be
used.
There is only one CODE table and one RTE table for each translation stage. The HEAD
table provides an implicit structure for these CODE and RTE tables by defining the names
of CODE and RTE translators. For each translator name listed in a HEAD table, there is
a set of translators (table entries) with that name in the corresponding CODE table, and a
set of translators (table entries) with that name in the corresponding RTE table, as
summarised in Figure 57. The HEAD table also minimises datafill by specifying various
default options that apply to all the CODE and RTE translators with a given name.
HEAD table
GRP1XLA <default options>
GRP2XLA <default options>
CODE table
GRP1XLA <digit range> <translation result = CONT>
Multiple CODE GRP1XLA <digit range> <translation result = DMOD>
and RTE entries GRP1XLA <digit range> <translation result = RTE DEST 1>
(translators)
for each name RTE table
defined in the GRP1XLA <route reference = 1> <route selector>
HEAD table GRP1XLA <route reference = 2> <route selector>
Figure 57: Relationship between HEAD, CODE and RTE tables
HEAD Defines translator names to be used by sets of CODE and RTE translators. For
each name it defines, the HEAD table specifies:
- A default translation result (for use if there is no CODE translator
with a digit range covering the digits being translated)
- Default options (typically the name of the next set of translation
tables to use on a CONT result, e.g. FA after PX)
- Whether digits used to index the table are consumed (default no)
- Whether non-decadic digits may be used (e.g. * or # for features)
CODE Defines the translations to be performed for each translator named in the
HEAD table. There is a set of CODE translators for each translator name
defined in the HEAD table. Each one specifies the translation result for a
given digit range.
For prefix translation via table PXCODE, the typical result is CONT (go
directly to another translator) or DMOD (perform specified digit modification
and then go to another translator); PXCODE translation does not result in the
selection of a route.
For area code translation via table FACODE, the typical result is RTE (route
selected), and the options include a destination number corresponding to one
of the RTE translators.
RTE For each destination associated with an RTE result in the CODE table, this
lists either a CLLI or an index into a table (e.g. IBNRTE or OFRT).

The translation process is summarised in Figure 58.
Incoming trunk access Indirect subscriber access

Direct subscriber access ( trunks all assigned to (authorisation required)
default customer group)
Origin of call determines customer group Access code or carrier ID prefixed

CUSTHEAD identifies customer group translator to CdPA determines target network
XLANAME selects default universal translator via LINEATTR index
2 dialling
options for
5 dialling
direct access
Feature options for
(de)activation code direct access
Local number One-stage Two-stage

dialling dialling
identifies customer group translators)
Service number
IBN translations (table CUSTHEAD
Long-distance number Incoming calls Incoming calls

screened on screened on
subscriber CLI dialled authcode
International number
IBNXLA selects No IBNXLA entries for these Dialled CdPA determines

preliminary calls, so default XLANAME
translator via LINEATTR index is used call destination
LINEATTR index
LINEATTR
Access to PXCODE prefix translations
PXCODE service Prefix translation tables

translator appends CS2000
ID for service calls PXHEAD, PXCODE, PXRTE
PXCODE local
PSTN translators
insert area codes PXCODE national PSTN translator
for local calls
Country code translation tables

CTHEAD, CTCODE, CTRTE
Area code translation tables

FAHEAD, FACODE, FARTE
Office translation tables
OFCHEAD, OFCCODE, OFCRTE
IBNXLA
activates
appropriate IBNRTE OFRT, FARTE, CTRTE
feature Lists line routes Lists trunk routes
software Line selection by DN Trunk group selection by CLLI
Figure 58: Universal translation tables and their functions

C3.5.4 Modifying Translations on a Per-Call Basis

The translation selectors listed in section C3.5.2 on page 210 determine the destination of
a call on the basis of the digits in the called party number. CS2000 supports a number of
other selectors that can be used to modify the translations process on the basis of other
information provided in the IAM or SETUP message, as follows:
! Calling Party Category (CPC) routing
This feature provides the ability to route (translate) based on the CPC for the ETSI
ISUP protocol and supported CCS7 national variants. Routing is triggered by the
use of the CPCRTE option in IBN or Universal Translations, in association with
tables CPCCHAR, CPCIXLA and CPCUXLA.
! Routing / translation based on Called Party Number elements
This feature makes it possible to route (translate) based on elements of the Called
Party Number parameter. For ETSI PRI, the elements used are the NPI and TON;
for ETSI ISUP and supported CCS7 national variants, the NPI and NOA are used.
Routing is triggered by the use of the CDNRTE option in IBN or Universal
Translations, in association with tables CDNCHAR, CDNIXLA and CDNUXLA.
The feature also provides the ability to set either or both of the relevant parameter
elements in the outgoing message, using the SETCDN option in IBN or Universal
Translations in association with table CDNCHAR.
Feature functionality has been enhanced to allow the SETCDN option to be
available in table DIGMAN.
SETCDN can also be associated with entries for individual routelist elements in the
xxCODE and OFCRT tables.
! Charge category routing
The CATRTE selector in IBN and universal translations causes CS2000 to
determine the charge category of a call and route the call on this basis. Charge
categories are determined by the relationship between the charge groups of the
caller and destination number, where a charge group is a geographical area. For
example, calls within a charge group or between adjacent charge groups might be
deemed to be local calls. Entries in table CATUXLA map each charge category on
to a specific route or a point where translations should be re-entered.

C3.5.5 Call Control and Universal Screening

Call control and universal screening provide a framework for systematically enhancing
the power and flexibility of ISN04 (TDM) call processing and translations, as described
in A59028780, A59028782 and A59033687.
The call control table CALLCNTL supports access to up to fifteen universal screening
tables. Each of these allows calls to be screened, and allows call processing data to be
updated to influence further translation, on the basis of:
! Called party number digits
! Called party number length
! Network Class of Service (NCOS)
! Customer group
! User-defined variables
! Called party number NOA and NPI
! Calling party number digits
! Calling party number NOA
! Bearer capability
! Carrier Identification Code (CIC)
! Redirecting information
! ISDN Preference Indicator
! Calling Partys Category (CPC)
! FGD ISUP Originating Line Information (OLI)
! FGD ISUP CKT
The capabilities provided by CALLCNTL and the universal screening tables are similar
in principle to those provided by unversal translations, i.e. the screening process can
conclude successfully, continue or be abandoned. The difference is that CALLCNTL
already supports the screening and manipulation of a wider range of call processing data
than just called party number digits, and the framework it provides can easily be extended
to include many more types of data.
Entry into Universal Screening via table CALLCNTL can take place in three ways:
! On a trunk group basis
For a given trunk group, the CCNTLIDX option in table TRKOPTS can specify an
index into table CALLCNTL. Alternatively, to simplify service provisioning, it is
possible to group up to eight call control indexes into a profile defined in table
CCNTLGRP. If this is done, the CCNTLIDX option points to CCNTLGRP rather
than directly to CALLCNTL.
! From translations
The GBL (Global) selector in xxRTE tables can be used to support access to table
CALLCNTL. If GBL=CCNTLRX, the CCNTLIDX field of the CCNTLRX
selector provides an index into table CALLCNTL. See A59028782 for details.
! From enhanced CLI screening
For a call being screening on the basis of the callers CLI, the basic CLI screening
performed using table DNSCRN (see section F11.3.1.1 on page 636) can be
enhanced by means of service profiles defined in table CLISRVPF (see section
F11.3.1.4 on page 638), which can provide an index into table CALLCNTL.

Figure 59 illustrates the use of universal screening tables.
Entry to US via Entry to US on Entry to US from

enhanced CLI screening trunk group basis translations
Tables Table CCNTLRX

DNSCRN / TRKOPTS selector
CLISRVPF
Table
CCNTLGRP
IBNXLA
Table processing
DTMFSCRN
Table CALLCNTL
DIGMAN
Table manipulation
ACCTSCRN
Universal Screening Tables
Table Table Table Table Table Table

CGPNSCRN CDPNSCRN CDPNLSCR NCOSSCRN CGRPSCRN SINTSCRN
Screening Screening Screening Screening Screening Screening

based on based on based on based on based on based on
CgPN digits CdPN digits CdPN length NCOS customer user-defined
group variables
Table Table Table Table Table

CDNNSCRN NOASCRN BCSCRN CICSSCRN RDRISCRN
Screening Screening Screening Screening Screening

based on based on based on based on based on Table
CdPN NOA CgPN NOA BC CIC redirecting VARDEF
and NPI information
Variable
definitions
Table Table Table Table

CKTSCRN IPISCRN CPCNSCRN OLISCRN
Screening Screening Screening Screening

based on based on based on based on
FGD ISUP ISDN CPC FGD ISUP
CKT Pref. Ind. OLI
Figure 59: Interactions betwen translations and universal screening tables

C3.6 Codec Selection via Translations

The codec and packetisation rate used for a call are determined by a codec negotation
process that involving the originating and terminating media gateways and their GWCs.
The aim is that the codec used should be the codec that is highest in preference order and
supported by both gateways involved in the call. The capabilities of each media gateway
are conveyed to its GWC and to the far-end gateway in the form of an SDP (Session
Description Language) session description, and an appropriate codec is selected from the
intersections of both gateways sets of capabilities. See see section G4.3 on page 751 for
further information about codec negotiation, and section D4.6.1 on page 286 for some
examples of SDP relayed via ASPEN for this purpose.
The basic steps in the end-to-end codec negotiation process are as follows:
1 The initial CRCX (Create Connection) or equivalent command sent for a call
presents a list of codec / packetisation rate pairs to the first media gateway in order
of preference.
Note: If codec negotiation via translations, as described on the following page,
results in the selection of the network default codec specified by the SETCODEC
option, this default codec (typically G.711) will be the only option presented in the
first CRCX command. Selection of the network default will then be the forced result
of the end-to-end codec negotiation process.
2 The first media gateways acknowledgement of the initial CRCX returns a media
description line for each codec / packetisation rate pair that it can support (from the
list presented by the GWC).
3 The CRCX sent to the other media gateway involved in the call presents it with an
ordered list of codec / packetisation rate pairs that reflects the capabilities supported
by the first media gateway.
4 The second media gateways acknowledgement of the CRCX returns a media
description line for each codec / packetisation rate pair that it can support.
5 At this point, both media gateways and their GWCs are aware of the far-end GWCs
capabilities and preferences. The originating gateway then selects the codec that is
highest in its preference order and also supported by the terminating gateway.
When GWCs and media gateways are datafilled, GWC datafill specifies a preferred codec
and packetisation rate and a default codec and packetisation rate for each subtending
media gateway. Compression codecs such as G.729 use bandwidth more efficiently than
non-compressed codecs such as G.711. It is therefore typical for the preferred codec for a
media gateway to be a compression codec. To ensure interoperability between different
types of gateway, however, it is a Nortel requirement that all CS2000-controlled gateways
should support G.711.
If either gateway involved in a call detects an in-band fax or modem tone, e.g. 2100Hz, it
will initiate a transition to G.711 Voice-Band Data (VBD) for the call, regardless of what
the original result of the codec negoiation process was.

There are call scenarios in which a compression codec should not be used:
! Calls for which compression has already been performed on another leg of the
end-to-end bearer path (e.g. calls originating from a mobile network).
! Call for which the additonal latency of using a compressed codec would add too
much of a delay (e.g. international VoIP calls).
Such scenarios cannot be determined in advance and controlled statically via datafill.
Instead, they must be identified during translations or call screening so that appropriate
action can be taken. ISN05 feature A19012781 introduced the SETCODEC option, which
can be specified at various points in the translations process to allow a codec to be selected
on the basis of call-related criteria, as summarised in the following table.
SETCODEC specified in To enable codec selection based on
Table TRKOPTS Incoming or outgoing trunk group
IBN translations tables IBNXLA and XLANAME Called party digits
xxCODE tables in universal translations Called party digits or called party NOA)
CALLCNTL and Universal Screening tables [1] A variety of parameters
Screening table DNSCRN [2] CLI or calling party NOA
Service profile table CLISRVPF [3] Service profile associated with screened CLI
[1] See section C3.5.5 on page 214 for information about CALLCNTL and Universal Screening.
[2] See section F11.3.1.1 on page 636 for information about table DNSCRN.
[3] See section F11.3.1.4 on page 638 for information about table CLISRVPF.
The SETCODEC option specifies the CALLTYPE of the current call. This CALLTYPE
is an index into table CODEC, which in turn specifies the codec to be used for the call.
CS2000 Core communicates this alternative codec to the GWC during call setup. It takes
precedence over the codec(s) specified in GWC datafill, and is used by the GWC during
codec negotiation.
The following limitations apply to use of the SETCODEC option in ISN07:
! The only codec that can be selected via translations is the network default (G.711
a-law or G.711 -law, depending on network configuration).
! SETCODEC does not allow an alternative packetisation rate to be selected, only an
alternative codec.

C3.7 Routing
Routing begins when one of two possible route types has been selected via the final RTE
table to be used in universal translations:
! A line to a DN served by this CS2000 (see section C3.7.1)
! An outgoing trunk (see section C3.7.2)
In the event of a problem that prevents call establishment, a call may be routed to
treatment, as described in section C3.7.3.
C3.7.1 Line Routing and Selection

The OFC translation tables for calls to subscriber lines served by the translating CS2000
are used to ensure that these calls are sent to the IBN line routing table IBNRTE. To
achieve this, the OFCHEAD table includes a default translation result for each NNG, with
a translator name of the form xxxnOFLA; these all have result RTE with destination
DEST 1. The OFCCODE table is empty. The OFCRTE table defines a numbered IBN
route for each NNG. The IBNRTE table specifies that calls to these routes should go to
the dialled DN, from which the NPA and NNG digits have been stripped off (consumed)
as part of the PXHEAD/PXCODE translation, i.e. what remains is a 4-digit extension
number.
The IBNRTE line routing table selects the DN of an extension to receive an incoming call.
Table IBNLINES associates this with a virtual physical line card slot known as a LEN
(Line Equipment Number), and also specifies which services are assigned to the line
(which may affect the handling of the call). For a CS2000 line, the LEN comprises the
number of a line group or V5.2 AN interface, plus numbers denoting a virtual shelf and
slot. This information is defined as described in section C2.7 on page 196:
! Line groups (for customer LAN and cable lines) are defined via table LGRPINV.
! V5.2 AN interfaces are defined via table GPPTRNSL.

C3.7.2 Trunk Routing and Selection
C3.7.2.1 The Route List Mechanism

Trunk routing begins when the translations process has determined that the destination for
a call is served by a trunk.
The FA or CT translation tables for long-distance calls, calls to non-geographic codes, and
international calls are used to ensure that these calls are sent to the appropriate trunk
routing table (OFRT, FARTE or CTRTE). To achieve this, each PSTNFALA entry in
table FACODE (or PSTNCTLA entry in table CTCODE) defines a result RTE with a
DEST number. The DEST number, together with the current translation system (e.g. FA,
CT) and translator name (e.g. PSTNFALA, PSTNCTLA) provides access to the RTE
table that defines a route list.
A route list is a list of routes to a given destination. Each route is identified by means of
a Common Language Location Identifier (CLLI), and corresponding to each CLLI there
is a trunk group. CS2000 supports two types of trunk destination, for which the datafill
requirements are described in Chapter C2: Trunk and Line Datafill:
! TDM-side trunks served by gateways (see section C2.5 on page 190).
! DPTs (Dynamic Packet Trunks) to packet network destinations served by other
CS2000s (see section C2.6 on page 191). The interaction between SIP-T and VRDN
GWCs to support DPTs is described and illustrated in section B1.4.5.3 on page 62.
When a route is selected, the CS2000 searches the trunks in the corresponding trunk group
to find an idle trunk. The type of search is specified in the trunk group datafill, e.g.
ascending sequential, descending sequential or least recently used.
If an idle trunk is found, the CS2000 seizes it and begins the appropriate call establishment
procedures. If an idle trunk is not found in the trunk group corresponding to a given route,
the next route in the route list is selected and the process is repeated. If no idle trunk is
found in any trunk group associated with the route list, the call is routed to treatment; the
treatment to be applied is specified in the route list.
If the idle trunk seized for a call is a common channel trunk, it is then necessary to select
a signalling link for conveying call establishment messages. See section C2.3.1 on page
185 for information about the tables used in selecting CCS7 signalling links, and section
C2.3.2 on page 186 for information about the tables used in selecting ISDN signalling
links.
If a call setup attempt over a given trunk encounters a network problem, the CS2000 can
initiate rerouting rather than simply routing the call to treatment.
If the BLKOVLP option is specified for an RTE destination, no outpulsing actually takes
place until all called party number digits have been collected. This ensures that call
establishment will not fail if CS2000 uses overlap outpulsing but this is not supported by
the destination node over the route selected for a call (and the destination node would be
unable to complete the call using only the initial digits).

C3.7.2.2 Simple Routing

With simple routing, the order in which routes are tried is purely sequential.
The simplest case is where the route list selected via the routing table (OFRT, FARTE,
CTRTE) contains only one route. Either the CS2000 finds an idle trunk in the
corresponding trunk group, or the call is routed to treatment.
CS2000 supports a maximum of eight routes in a route list, which are listed in order of
preference. With simple routing, the preferred route is tried first, then the next preferred
route, and so on until an idle trunk is found or the route list is exhausted.
Note: Network operators or national regulators may impose a maximum of fewer than
eight routes in a route list. In the UK, for example, the BTUP specification BTNR 167
specifies a maximum of three routes.
C3.7.2.3 Special Route List Entries

In addition to CLLI routes, a route list can include the following special types of list entry:
! Entries that provide information
" An entry that provides not only a CLLI, but also additional information about
digits to be outpulsed, billing and so on.
! Entries that modify the simple sequential routing process:
" An entry that provides the index of a different route list, which causes the
CS2000 to go to that route list and begin the routing process again. This ability
to chain different route lists together makes it possible to define linked route
lists that together have more than the maximum of eight entries permitted in
a single route list. For example, an entry in table FARTE may point to an entry
in table OFRT.
" An entry that modifies or replaces the called party number and causes
translations to be re-entered.
Each of these special route list entries takes the place of a route in the route list, i.e. the
overall maximum number of entries is eight, regardless of whether they are simple routes
or special entries.

C3.7.2.4 Conditional Routing (Route List Manipulation)

The route list is a flexible tool that can be used to support powerful conditional routing
capabilities.
With conditional routing, a range of different criteria can be used to determine the order
in which the routes in a route list are tried. The most important criteria are:
! Static criteria
" Least Cost Routing (LCR)
With this capability, which is provided on a customer group basis, the tariffs
for different routes are stored in a data table, and routes are tried in increasing
order of cost.
" Time Of Day (TOD) routing
This capability enables cost-effective use of facilities by allowing or denying
route choices based on the time of day. The times can be set to take maximum
advantage of low tariffs. The route choices can also be based on the day of the
week to allow for weekends, or on the day of the year to allow for holidays.
Different time-of-day routing schemes can be implemented for different
customer groups. Each scheme supports up to 16 sets of routes categorised as
allowed or denied on the basis of the time of day and day of week/year.
This capability is normally used in conjunction with NCOS setting, making
the NCOS screening defined for certain routes time-dependent.
" Percentage / random conditional routing
Allows the network operator to specify that a certain percentage of traffic
should be sent via a particular route. Can be used to distribute calls evenly, or
in any chosen proportion, between two or more long-distance carriers.
" COS screening on a trunk group basis
TRKOPTS option COS can specify a COS value (0-1023) for a trunk group.
Table COSBLK specifies combinations of orginating trunk group COS and
terminating trunk group COS for which call completion will be permitted.
! Call-related criteria
" NCOS routing
Conditional routing based on NCOS allows for flexible screening of class of
service values at the routing stage of the call.
" Bearer Capability (BC) routing
BC routing ensures that the only routes tried are those that can support the
bearer capability required for the call. It is particularly important for Clear
Channel Data (CCD) calls, as described in section C3.8 on page 229.
" NRR (Network Re-Routing)
If a call routed out over an ETSI ISUP or IBN7 trunk encounters congestion
(indicated by receipt of a REL message with cause value 34 or 42), this option
allows CS2000 to make another attempt to route the call.
Note: Alternative names for NRR are Conditional Re-Routing and
Re-Routing on Congestion.
If the application of a given criterion results in a decision not to use the next route in the
route list, the following alternatives are available:
! To go to a different route list and begin the routing process again
! To skip a number of routes in the current route list

C3.7.2.5 Illustration of the Routing Process

The routing capabilities supported by CS2000 are summarised in Figure 60.
Translations
Route index
Special route list

entries allow a
new route to be
selected or
translations to be
re-entered
Routing
table
(OFCRT, Datafill determines
FARTE, whether to apply
CTRTE) conditional routing
criteria, e.g. Least Cost
Routing (LCR) or Time
Of Day (TOD) routing
Route list
CLLI Search for idle trunk in
coresponding trunk group using
specified search algorithm
Route list
contains up to Try next
eight entries. entry in Idle
route list No trunk
These are
typically CLLIs, found?
but special entries
are also
supported. Yes
Seize trunk
and initiate
call setup
Figure 60: The routing process
Note: It is possible to chain different route lists together to create a linked set of route
lists that together have more than the maximum of eight entries permitted in a single list.

C3.7.2.6 Trunk Identification in a Packet Architecture

CS2000 translations and routing identify trunks by means of TIDs (terminal identifiers)
defined in table TRKMEM. Historically, such a TID denotes a particular 64 Kb/s bearer
channel served by a DTC (Digital Trunk Controller) peripheral. In the CS2000
architecture, however, trunks terminate on media gateways controlled by CS2000, not on
CS2000 peripherals.
There are two possible ways in which a packet network trunk can be identified and
selected, depending on whether the destination is served by a TDM-side access trunk or
an inter-CS trunk:
! If the selected destination is a TDM-side trunk served by a media gateway, datafill
for the egress GWC provides the necessary mapping between the TID and an EID
(endpoint identifier) that will be recognised by the gateway. This is made possible
because the DTCEX option of table SERVRINV enables details of the PSTN trunks
controlled by a GWC to be datafilled against it (in tables CLLI, TRKGRP,
TRKSGRP, TRKOPTS and TRKMEM) as if it were a TDM-side DTC. The
resulting EID specifies a particular 64 Kb/s channel on a particular E1 carrier at the
media gateway.
! If the selected destination is a logical SIP-T trunk group to another CS2000, trunk
member details will not be available until a DPT (Dynamic Packet Trunk) on a
SIP-T GWC has been selected, dynamically provisioned, and assigned for the
duration of the outgoing call. Any DPT can be selected from the pool of trunks
supported by the SIP-T GWCs on the CS2000.
Trunk group data for a selected DPT, including CCS7 protocol to be used and
destination hostname is downloaded to its SIP-T GWC when the DPT is selected
and allocated. Once the DPT has been provisioned, its TID can be used by CS2000
Core call processing to set up the outgoing call. See Figure 13 on page 63 for an
overview of DPT selection and use.

C3.7.2.7 Dynamic Routing Control (Network Traffic Control Mechanisms)

Network traffic control mechanisms are used to limit and/or balance trunk traffic over
selected routes when this is required in order to handle special traffic circumstances, e.g.
network overload. This section provides an overview of the most important traffic control
mechanisms available for use with TDM trunks and/or DPTs.
Note: These features are specifically designed to be temporary overrides for traffic
management. They do not require or imply any permanent table provisioning updates.
Traffic control mechanisms use a variety of OMs and logs to provide feedback to the
network operator about when, where and how often specified limits have been hit and
which specific actions were taken as a result.
Trunk Traffic Controls Common to TDM Trunks and DPTs

! SKIP
Causes a specified percentage of traffic destined for a particular outgoing trunk
group to be overflowed to the next trunk group in the route list.
! CANT (Cancel To)
When applied to an outgoing or two-way trunk group, CANT causes a specified
percentage of calls offered to that group to be blocked and routed to treatment. The
control can be applied either to a percentage of alternate routed traffic (leaving all
direct routed traffic unaffected), or to all alternate routed traffic plus a percentage
of direct routed traffic.
! CANF (Cancel From)
When applied to an outgoing or two-way trunk group, CANF causes a specified
percentage of calls overflowing from that group to be blocked and routed to
treatment, rather than overflowing to the next trunk group in the route list.
! FRR IRR (Flexible ReRoute Immediate ReRoute)
When applied to an outgoing or two-way trunk group, FRR IRR causes all calls
destined for that group to be sent to an alternative trunk group or route, thus
overriding / bypassing the standard route list.
! FRR RRR (Flexible ReRoute Regular ReRoute)
When applied to an outgoing or two-way trunk group, FRR IRR causes all calls
overflowing from that group to be sent to an alternative trunk group or route rather
than to the next trunk group in the route list.
TDM-Specific Trunk Traffic Controls

The features described in this section are used to control traffic at the trunk group level.
! DRE (Directional Reservation Equipment)
Allows a specified number of trunks belonging to a two-way trunk group to be kept
idle so that they are available for use by incoming traffic. Outgoing traffic is
permitted via the trunk group only when the number of idle trunks available exceeds
the minimum reserved for incoming traffic. Otherwise, outgoing traffic is
overflowed to the next trunk group in the route list.
! PRE (Protection Reservation Equipment)
Allows a specified number of trunks belonging to an outgoing or two-way trunk
group to be kept idle so that they are available for use by direct routed traffic.
Alternate routed traffic is permitted to use the trunk group only when the number

of idle trunks available exceeds the minimum reserved for direct routed traffic.
Otherwise, alternate routed traffic is overflowed to the next trunk group in the route
list.
! CBK (Code Blocking)
When applied to an outgoing or two-way trunk group, CBK causes a specified
percentage of traffic with a specified destination code to be blocked and routed to
treatment. The destination code may be either a DN or a code type such as CCODE
(country code), ACODE (area code), NAC (non area code) or PFX (prefix).
! STR (Selective Trunk Reservation)
Allows traffic to be divided into four separately controlled categories on the basis
of:
" Whether it is direct routed or alternate routed.
" Whether it is destined for a code that has been designated as HTR (Hard To
Reach), e.g. for the purpose of a mass-calling event. A code designated as
HTR may be either a DN or a code type such as CCODE (country code),
ACODE (area code), NAC (non area code) or PFX (prefix).
Traffic control is applied at two levels on the basis of the following criteria:
" No blocking is applied when the number of idle trunks available in the trunk
group is less than the number specified as the threshold for Level 1 blocking.
" When the number of idle trunks drops below the Level 1 threshold but still
exceeds the Level 2 threshold, Level 1 blocking is applied. At Level 1, a
user-specified percentage x% of all traffic for HTR codes is blocked and
routed to treatment, while no blocking is applied to non-HTR traffic.
" When the number of idle trunks drops below the Level 2 threshold, Level 2
blocking is applied, as follows:
# 75% of direct route traffic for HTR codes is blocked.
# All Alternate Route traffic for HTR codes is blocked.
# x% of of direct route traffic for non-HTR codes is blocked.
# All Alternate Route traffic for non-HTR codes is blocked.
This is summarised in the table below.
Traffic Type Level 1 Level 2

HTR / direct route x% Blocked 75% Blocked
HTR / Alternate Route x% Blocked 100% Blocked
Other / direct route No effect x% Blocked
Other / Alternate Route No effect 100% Blocked
Assume, for example, that the Level 1 threshold is set to 50 idle trunks,the
Level 2 theshold is set to 10 idle trunks, and the user-specified blocking
percentage is set to 40%. This means that when there are fewer than 50 idle
trunks in the group, 40% of all HTR calls to that group are blocked. When
there are fewer than 10 idle trunks in the group, 75% of direct route HTR calls
are blocked, all alternate route HTR calls are blocked, 40% of other direct
route calls are blocked, and all other alternate route calls are blocked.

DPT-Specific Traffic Controls

! TID limit
Allows an overall maximum to be specified for the number of TIDs that can be
simultaneously in use on a CS2000. When the specified limit is exceeded, new calls
that attempt to use DPTs are handled as follows:
" Incoming calls are blocked.
" For outgoing calls, the next TDM route in the route list is selected for the call.
If there are no TDM routes in the route list, the call is routed to treatment.
! Bandwidth reservation
Ensures that a percentage of the total number of TIDs available on a CS2000 is
reserved for outgoing calls. This is typically used to ensure that calls can be made
out of an area affected by an emergency, while potentially reducing the flood of
incoming calls. Bandwidth reservation operates by blocking incoming DPT calls
when all non-reserved TIDs are in use (i.e. 100% of TID limit minus outgoing
reserved %).
! Bandwidth prioritisation
Allows call volume to be throttled on a trunk group basis. Associated with each
trunk group is a specified minimum percentage of idle DPT TIDs that must be
maintained if the trunk group is to be regarded as available. When the percentage of
idle DPT TIDs in the CS2000 as a whole drops below the minimum percentage
specified for a given trunk group, that trunk group is treated as being unavailable,
i.e. new calls that attempt to use DPTs associated with that trunk group are handled
as follows:
" Incoming calls are blocked.
" For outgoing calls, the next TDM route in the route list is selected for the call.
If there are no TDM routes in the route list, the call is routed to treatment.

C3.7.3 Routing to Treatment

When a call attempt fails, e.g. because of network congestion or the dialling of an invalid
number, CS2000 causes a treatment to be applied, in the form of an audible
tone/announcement or a backward message.
C3.7.3.1 Tones and Announcements

Because tones and announcements must be provided in-band, CS2000 does not support
them directly. Instead, it determines which tone or announcement should be provided,
then sends device control messages to the appropriate media gateway (in the case of a
tone) or the UAS (in the case of an announcement) specifying the tone or announcement
required.
Playing Tones
Tones are defined in device control protocols as signals. The H.248 and ASPEN 2.1
protocols organise tone signals into a number of packages, each comprising a number of
tones with related functions. The other device control protocols supported by CS2000, i.e.
NCS and MGCP, also organise tone signals into packages, but their packages can also
contain signals other than tones. In either case, a given tone is uniquely identified by the
combination of its Package ID and Tone ID (PID/TID).
CS2000 identifies tones by means of internal toneIDs that are recognised both by the Core
and by GWCs. CS2000 Core datafill maps these internal toneIDs on to CLLIs defined in
table TONES, while GWC software maps them on to the standard PID/TID tone
identifiers defined in the device control protocol (H.248, ASPEN 2.1, NCS or MGCP).
The need to play a tone can be determined either by the Core (in which case a proprietary
message specifying the required internal tone ID is sent by the Core to the GWC) or
autonomously by a GWC.
The PID/TID tone identifiers specified by GWCs in device control messages are purely
functional. They provide no information about the characteristics (frequency, level and
cadence) of the tones they identify. CS2000 does not need to know about market-specific
variations in tone characteristics; it merely requests the playing of a particular functional
tone and relies on the gateway to ensure that the tones characteristics are correct when it
is played, in accordance with the country and network in which the gateway is deployed.
A given CS2000 can therefore support gateways in a number of different countries.
Gateways apply tones in-band to TDM-side trunks or to lines. They do not provide tones
over the packet network.
For details, see Chapter G2: CS2000 Support for Tones.

Playing Announcements
Announcements are identified by a combination of a CLLI and an announcement number.
CS2000 datafill maps each announcement number on to an ordered list of the phrases that
make up the announcement, each phrase being identified by means of an external phrase
identifier. When CS2000 call processing determines that a particular announcement needs
to be played to a call party, it refers to this announcement datafill to find out the sequence
of specific phrases that must be assembled. CS2000 datafill provides 1:1 mapping
between the external phrase identifiers recorded in CS2000 announcement datafill and the
numeric audio identifiers used by the UAS to identify announcement phrases. This
enables the UAS to retrieve and play the correct announcement in response to a CS2000
request.
The UAS provides packetised announcements through the packet network to a specified
trunk or line endpoint on a media gateway. UAS announcements do not terminate in the
packet network.
Note: The UAS cannot generate tones, but it can be used to support tones if the required
tone samples are recorded as an announcement and set up as an announcement via datafill.
For details, see Chapter G3: CS2000 Support for Announcements.
C3.7.3.2 Backward Messages

For calls originating on a common channel trunk interface and terminating on an interface
of the same type, i.e. without interworking, table TMTMAP determines whether the
failure should be reported by means of a backward message (and if so, which message) or
by means of a tone or announcement specified by CLLI in table TMTCNTL.
For calls originating on a common channel trunk interface and terminating on a different
type of common channel interface, i.e. interworking is necessary, the CS2000 consults
table FAILMSG. For each supported protocol, this table defines how failure messages and
cause values are mapped on to the failure messages and cause values of all other supported
protocols. Consulting table FAILMSG enables the CS2000 to determine whether the
failure should be reported by means of a backward message (and if so, which message) or
by means of a tone or announcement specified by CLLI in table TMTCNTL.
Note: In the case of SIP-T trunks, failure is always reported via a backward message, as
provision of tones and announcements is not supported for SIP-T.

C3.8 Support for CCD (Clear Channel Data) Calls

Handling 64 Kb/s CCD calls originating in the TDM network, as used for ISDN data and
other data adaptations, is an issue for packet-based networks because buffering to absorb
delay variation (jitter) adds to the overall latency (packet delay), and because it is
necessary to allow for a certain amount of packet loss.
When the first setup message for a new incoming call (ISUP IAM or PRI SETUP) notifies
CS2000 that a CCD bearer channel is required, the ingress GWC uses ASPEN to ensure
that the originating gateway sets up an appropriate bearer connection across the packet
network. Specifically, the L (local connection options) parameter of the CRCX (create
connection) command indicates that the following characteristics are required:
a compression algorithm x-ccd (clear channel data)

e echo cancellation off
s silence suppression off
In addition, the gateway will not apply comfort noise or use a codec for such a call.
Note: As an alternative to emulating data circuits over the packet network, TDM
hairpinning could in theory be used for CCD calls, to re-route them within the TDM
domain. A hair-pinned connection is one that enters a gateway from the TDM side and is
routed out again immediately over another TDM-side connection. This requires the
gateway to have a TDM bus. As the PP7480 and PP15000 PVGs have ATM buses, not
TDM buses, they do not support hair-pinned connections for CCD calls.
C3.9 Order Codes for Translations and Routing

Software
Table 21: Order codes for translations and routing software

LOC00005 Dial Plan Translation Enhancements
IXLS0003 NCOS/CUST GRP allocation
IXLS0005 CPC Routing
IXLS0006 Called Number Parameter
IXLS0008 Charge Category Based Routing
IXLS0012 ISUP Reroute on Congestion
IXLS0014 Call Control
IXLS0015 Class of Service Screening
IXLS0016 CLI Delivery Control

Part D
Packet Telephony
Protocols
Chapter D1 Part D CS2000 International Product Description
Overview of Packet Telephony Protocols Packet Telephony Protocols Communication Server Capabilities
Chapter D1 Overview of Packet

Telephony Protocols
This chapter discusses the three types of signalling involved in setting up calls across the
packet network:
! Signalling between Gateway Controllers (GWCs) and media gateways:
" Device/media control signalling that allows the GWC to control the
characteristics of the packet network bearer connections on the media
gateway used for a call.
" Backhauled call control signalling (setup and clearing messages) for
non-CCS7 message-based interfaces such as PRI, QSIG and V5.2, for which
TDM-side signalling is terminated at the gateway.
" Combined media control and call control signalling for analogue lines.
! Network signalling between peer Communication Servers.
! Session description signalling, which is used to complement both GWC-gateway
signalling and inter-CS signalling by specifying bearer capabilities.
Note: This signalling is conveyed over IP even if an ATM backbone network is in use.
Specifically, IP / AAL5 / ATM is used over any ATM part of the packet backbone.
The chapter is organised into three sections:
! Section D1.1 on page 233 provides an illustrated view of the packet network
protocol stacks supported by CS2000 in ISN07.
! Section D1.2 on page 234 discusses transport protocols (UDP, TCP, SCTP, RUDP).
! Section D1.3 on page 239 describes SDP session descriptions.

CS2000 International Product Description Part D Chapter D1
Communication Server Capabilities Packet Telephony Protocols Overview of Packet Telephony Protocols
Each of the top-level protocols introduced in this chapter is described in more detail in
one of the other Part D chapters, as follows:
! Chapter D2: SIP and SIP-T
! Chapter D3: H.248
! Chapter D4: ASPEN
! Chapter D5: H.323
! Chapter D6: UniStim
! Chapter D7: NCS
! Chapter D8: MGCP
! Chapter D9: MPCP
! Chapter D10: IUA
! Chapter D11: V5UA
! Chapter D12: MTP Adaptation Protocols (M3UA and M2PA)
! Chapter D13: DSM-CC
! Chapter D14: OAM&P Protocols

233
Page
Overview
Chapter D1
D1.1
DMC for DMC for DMC+CC DMC+CC DMC+CC DMC+CC DMC+CC DMC+CC Back- Back- Encap- Peer-to- CCS7 Peer-to-
PVGs PVG for units for for cable for LAN for RTP for RAS hauled hauled sulated peer across peer
trunk controlled CentrexIP CPE CPE Media via CC for CC for CCS7 signalling CS LAN NCAS
DMC+CC gateways via H.323, remote gateways gateways Portal CVX1800 PRI, V5.2 between between between
for telco (super- e.g. clients (MTAs) QSIG off PVG CS2000s CS2000 CS2000s
gateways seded IP PBXs, off PVG and
Figure 61: Protocol stacks for packet network signalling
Packet Network Protocol Stacks

by routers MCS5200
DMC+CC H.248
for except
MS/UAS for QSIG)
H.248 ASPEN H.323 UniStim NCS MGCP MPCP DSM-CC Q.931 V5.2 SIP-T SIP CCS7 CCS7
Layer 3 Layer 3 (ISUP, (TCAP
(PRI, TUP, only)
(H.450 QSIG) CCS7 IBN7 TCAP)
and No SDP; (ISUP, ISUP
H.245 RTP TUP) emulation
over Media via
H.225 Portal MIME

CC not MTP3
based on involved
Nortel Networks
SDP SDP Q.931) SDP SDP in codec SDP SDP

PROPRIETARY
in-line in-line in-line in-line nego- via via

tiation IUA V5UA MIME MIME M3UA M2PA
Part D
UDP RUDP TCP (SS) TCP (SS)
UDP UDP (RAS) / UDP UDP UDP UDP SCTP SCTP / UDP / UDP SCTP SCTP
TCP (VRDN) (VRDN)
UDP
(CC)

IP IP IP IP IP IP IP IP IP IP IP IP IP IP

ASPEN Proprietary DMC protocol based on MGCP MSU Message Signal Unit
CC Call control MTP CCS7 Message Transfer Part
CPE Customer Premises Equipment MTP3 MTP Layer 3
DMC Device / media control NCAS Non Call Associated Signalling
DSM-CCDigital Storage Media Command and Control NCS Network-based Call Signalling
H.248 Joint ITU-T and IETF protocol for MGC - MG signalling RAS H.323 Registration, Admission and Status
H.323 ITU-T multi-protocol architecture for multimedia services RAS Remote Access Service
(comprises H.225 RAS and CC conveying H.450 and H.245 data) RUDP Reliable UDP (defined as appendix to UniStim)
IP Internet Protocol SCTP Stream Control Transmission Protocol (reliable transport)
17 August 2004
IUA ISDN User Adaptation SDP Session Description Protocol (for codec negotiation)
M2PA MTP2-User Peer-to-Peer Adaptation (for conveying MTP MSUs) SIP-T Session Initiation Protocol for Telephony
M3UA MTP Layer 3 User Adaptation (for conveying CCS7 messages) TCP Transaction Control Protocol (reliable transport)
MGCP IETF-defined Media Gateway Control Protocol UDP User Datagram Protocol (best-effort transport)
MIME Multi-purpose Internet Mail Extensions (encapsulation mechanism) UniStim Protocol for controlling CentrexIP remote clients
MPCP Media Proxy Control Protocol (for controlling RTP Media Portal) V5UA V5.2 User Adaptation
Communication Server Capabilities Packet Telephony Protocols Overview
D1.2 Transport Protocols

Transport protocols are used by device/media control protocols and call control protocols
to provide transport for signalling messages to be conveyed between packet network
endpoints, e.g. between an MGC and a media gateway. They operate at Layer 4
(Transport) of the standard OSI 7-layer model.
CS2000 supports the following transport protocols for packet network signalling:
! UDP (User Datagram Protocol), whch provides best-effort transport and is briefly
described in section D1.2.1.
! TCP (Transaction Control Protocol), whch provides reliable, ordered transport and
is briefly described in section D1.2.2.
! SCTP (Stream Control Transmission Protocol), whch provides reliable, ordered
transport for call control messaging and is described in section D1.2.3 on page 235.
! RUDP (Reliable UDP), whch provides best-effort transport and is described in
section D1.2.4 on page 238.
See Figure 61 on page 233 for an illustration of the transport protocol(s) used in each
signalling protocol stack supported by CS2000 in ISN07.
Note: The transport protocol used for IP bearer traffic (RTP / RTCP) is UDP.
D1.2.1 UDP (User Datagram Protocol)

UDP is a protocol that provides an unreliable, unordered data delivery between packet
network endpoints. It is a best-effort transport protocol that expects messages to be
acknowledged at the application layer, and expects the application layer to resend any
message that is not acknowledged before timer expiry. UDP itself therefore incorporates
no reliability or resend mechanisms, and is said to provide unreliable transport.
UDP is the transport protocol used in the vast majority of the signalling protocol stacks
supported by CS2000 in ISN07, as illustrated in Figure 61 on page 233. It is also the
transport protocol used for IP bearer traffic (RTP / RTCP).
D1.2.2 TCP (Transaction Control Protocol)

TCP guarantees delivery of data and also guarantees that packets will be delivered in the
same order in which they were sent. It is responsible for verifying the correct delivery of
data from client to server to ensure that data is not lost in the course of tranmsission across
the network. TCP provides mechanisms for detecting errors or lost data, and for triggering
retransmission until all data has been correctly and completely received.
In ISN07, TCP is used in CS2000 solutions for two purposes:
! As the transport protocol to support peer-to-peer SIP/SIP-T signalling, where this
terminates on the Session Server rather than on a DPT GWC, as explained in
Chapter D2: SIP and SIP-T.
! As the transport protocol to support H.225 call control signalling. This is a key
element of CS2000 support for the H.323 protocol architecture, as described in
Chapter D5: H.323.

Overview Packet Telephony Protocols Communication Server Capabilities
D1.2.3 SCTP (Stream Control Transmission Protocol)
D1.2.3.1 Purpose
SCTP is an IETF protocol defined in RFC2960. The CS2000 implementation is compliant
with draft version 5. In ISN07, CS2000 supports the use of SCTP for two main purposes:
! To provide reliable ordered transport for backhauled call control signalling via the
following protocol stacks (see :
" Q.931 or QSIG / IUA / SCTP / IP, as used for ISDN Layer 3 D-channel
backhaul.
" V5-PSTN / V5UA / SCTP / IP, as used for V5.2 Layer 3 signalling backhaul.
! To provide reliable ordered transport for CCS7 signalling via the following protocol
stacks:
" CCS7 / M3UA / SCTP / IP, as used for intra-CS2000 signalling over the CS
LAN.
" TCAP / SCCP / MTP3 / M2PA / SCTP / IP protocol stack, as used for NCAS
(Non Call Associated Signalling) between peer CS2000s.
SCTP is a reliable transport protocol designed by the IETF SIGTRAN workgroup as an
alternative to TCP and UDP for handling delay-sensitive payloads such as call control
signalling. It is an assured transfer type that will not allow call setup to succeed unless all
messages have been received in the correct order. Using SCTP as a transport protocol
instead of UDP means that no application-level reliability mechanisms are required or
supported by the top-level protocols in these protocol stacks.
SCTP offers the following services to its users:
! Acknowledged, error-free, non-duplicated transfer of user data.
! Data fragmentation to conform to the MTU (Maximum Transmission Unit) size
discovered for the transport path.
! Sequenced delivery of user messages within multiple streams, with an option for
order-of-arrival delivery of individual user messages.
! Optional bundling of multiple user messages into a single SCTP packet.
! Network-level fault tolerance via support of multi-homing at either or both ends of
an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance
to flooding and masquerade attacks. SCTP also allows the failure of MGCs (CS2000s)
within the packet network to be detected so that appropriate recovery action can be taken.

D1.2.3.2 Use of SCTP to Convey Backhauled Call Control Signalling

SCTP transport signalling is used to provide reliable ordered transport for the following
types of call control signalling between a GWC and a media gateway supporting trunk or
V5.2 line access:
! Q.921 user messaging
PRI signalling (Q.931 Layer 3) conveyed over IUA
! QSIG user messaging
QSIG Layer 3 signalling conveyed over IUA
! LAPV5 user messaging
V5.2 signalling (V5-PSTN Layer 3 messages) conveyed over V5UA
Figure 61 illustrates the use of SCTP in providing reliable transport for these different
types of signalling. In the handling of a given call, SCTP may be involved in one or more
of these roles.
CS2000
Trunk V5.2
GWC GWC
SCTP used to support access signalling

GWC - MG signalling for trunk or line access:
Two types of call control signalling, both
conveyed using SCTP transport:
- PRI signalling (Q.931 Layer 3) or QSIG
conveyed over IUA (Q.921 equivalent)
- V5.2 signalling (V5-PSTN Layer 3
messages) conveyed over V5UA
(LAPV5 equivalent)
Media control signalling via H.248 or
ASPEN (with SDP session description
commands in-line) conveyed over UDP / IP
Media Media
Gateway Gateway
For both types of gateway,
B-channels are mapped on
to packet network bearer
30B+D V5.2 AN commections; signalling is
PRI or QSIG interface backhauled to the CS2000
access (<16 E1s)
Digital PBX V5.2

or Access
PRI-enabled Network
device (AN)
Figure 61: Use of SCTP to provide reliable transport for backhauled call controlsignalling

D1.2.3.3 Use of SCTP to Convey CCS7 Signalling

SCTP is used to provide reliable transport for CCS7 signalling conveyed via the M3UA
(MTP Layer 3 User Adaptation) and M2PA (MTP2-User Peer-to-Peer Adaptation)
protocols.
M3UA is used to support intra-CS2000 signalling over the CS LAN between units that
share the same CCS7 point code, e.g. the Core and the USP; direct signalling between the
USP and GWCs is also supported.
M2PA is used to support TCAP NCAS (Non Call Associated Signalling) with remote
CS2000s across the backbone packet network between CS2000s that have different CCS7
point codes (specifically, between USPs belonging to such CS2000s).
Figure 62 illustrates USP support for CCS7 signalling via M3UA and M2PA.
CS2000
TCAP
ISUP TUP
SCCP TCAP
CS2000 M3UA USP SCCP IP control
Core SCTP MTP3 network over
backbone
IP M2PA
Other CS2000s,
packet network
peer MGCs
SCTP
IP
CS LAN
Figure 62: Use of SCTP to provide reliable transport for CCS7 signalling

D1.2.3.4 SCTP Characteristics

SCTP has the following key characteristics:
! Use of data chunks
This enables multiple applications to share the same connection, each application
using a dedicated transport stream.
! Selective acknowledgement
If a transmitter sends 10 transactions but transactions 6 and 8 are lost, the receiver
is able to acknowledge only the eight transactions it has received. The transmitter
then knows that transactions 6 and 8 must be resent.
! Cookie encryption
This allows secured connection establishment between two entities.
An SCTP packet comprises:
! Source port number
! Destination port number
! User data, which in a CS2000 context is one of the following:
" PRI / IUA message
" QSIG / IUA message
" V5-PSTN / V5UA message
! A 32-bit checksum
Upper layer protocols are required to adapt SCTP to the signalling protocol that has to be
transported, as follows:
! For Q.931 and QSIG, the protocol used is IUA (ISDN User Adaptation), which
provides capabilities similar to ISDN Layer 2 (Q.921 datalink) for the encapsulation
of protocols such as PRI Layer 3 messages (Q.931) and QSIG messages.
! For V5.2, the protocol used is V5UA (V5.2 User Adaptation), which provides
capabilities similar to V5 Layer 2 (LAPV5 datalink) for the encapsulation of V5.2
Layer 3 messages (V5-PSTN only in ISN07).
D1.2.4 RUDP (Reliable UDP)

RUDP is designed to complement the UniStim protocol used to control CentrexIP remote
clients, as described in Chapter D6: UniStim.
UniStim is a Nortel Networks protocol, but is available under licence to other equipment
vendors who wish to design and manufacture CentrexIP terminals that support
interoperability with Nortel Networks products such as CS2000. It is therefore capable of
supporting not only proprietary i200x Etherset terminals and PC-based soft clients, but
also compatible third-party terminals. It is formally defined in Nortel Interface
Specification (NIS) D201-1: UniStim Protocol Specification.
To provide reliable transport over UDP, UniStim uses a simple Go-Back-N scheme to
provides a suitable Reliable UDP layer for UniStim. This is also defined in NIS
D201-1.The protocol stack used for UniStim signalling is therefore UniStim / RUDP /
UDP / IP.

D1.3 Session Descriptions (SDP)

D1.3.1 Functional Overview
SDP (Session Description Protocol) session description signalling is used to complement
both GWC-gateway signalling and inter-CS signalling by specifying media stream
characteristics and address information, particularly for use in codec negotiation. SDP is
an IETF protocol defined in RFC2327.
For VoIP, SDP conveys IP address information as specified in RFC2327. For the CS2000
implementation of VoATM (VoAAL2 using PVGs), SDP conveys ATM address
information by means of SDP extensions defined in the following ID:
draft-rajeshkumar-mmusic-sdp-atm-01
This draft extends SDP to support ATM endpoint information instead of IP in setting up
an ATM communication path based on VoAAL2. With the implementation of this draft,
CS2000 need not be aware of the packet network differences between VoATM or VoIP.
SDP information is conveyed in one of two ways:
! When used to complement GWC-gateway signalling using H.248, ASPEN, NCS or
MGCP, SDP information is provided inside the device/media control messaging.
! When used to complement SIP / SIP-T inter-CS signalling, the MIME mechansism
used to encapsulate CCS7 messages (ISUP or TUP) in SIP-T messages is used in a
similar way to encapsulate SDP information. CCS7 and SDP can both be conveyed
(but separately packaged) within a given SIP-T message.
An SDP session description comprises:
! Information about the media stream(s) to be used in a call or conference
" Media type (e.g. audio, video, data)
" Transport protocol (e.g. UDP, RTP)
" Media format (e.g. A-law PCM, MPEG-2 video)
! Address information for the sending and receiving of packets by participants
" IP addresses and UDP port numbers
" ATM address information
A session description may also include timing information, e.g. start/stop times and
session repetition details.

D1.3.2 Network Role

SDP session description signalling is used to complement both GWC-gateway media
control signalling and inter-CS signalling, as follows:
! SDP with GWC-gateway media control signalling via H.248, ASPEN, NCS or
MGCP
SDP commands are provided in-line with device/media commands sent between
GWCs and media gateways. Typically, SDP commands sent by the GWC specify
the requirements for a call, while SDP commands sent by the media gateway
provide information about the capabilities available at the gateway.
! SDP with inter-CS signalling via SIP
SDP commands are encapsulated via the MIME mechanism and conveyed in SIP
messages. In the case of SIP-T, SDP is conveyed along with similarly but separately
encapsulated CCS7 messages. Typically, the originating CS passes on information
about requirements, as provided by the ingress TDM-side GWC to the egress
packet-side GWC, while the terminating CS returns information about capabilities
available.
Figure 63 illustrates the two different roles of SDP session description signalling. In the
handling of a given call, SDP may be involved in either or both roles.
CS2000 CS2000
DPT GWCs DPT GWCs
Trunk
or line and Session and Session
Gateway Server; Server;
Controller Egress Ingress
(GWC)
packet-side packet-side
A B
Scenario B:- SDP used to
Scenario A:- SDP used to complement inter-CS signalling
complement access signalling UDP transport conveys one or two
SDP session description types of signalling, separately
commands in-line with H.248, encapsulated in SIP messages
ASPEN, NCS or MGCP using the MIME mechanism:
commands conveyed over UDP/IP SDP session descriptions
Optional CCS7 messages
(ISUP or TUP)
Media SIP signalling terminates on
Gateway Session Server; CCS7 signalling
terminates on DPT GWC.
Figure 63: Use of SDP to complement access signalling and/or inter-CS signalling

D1.3.3 Command Syntax

SDP is a text protocol consisting of text lines of the format
type=value
where
type is a single letter
value is a text string whose format depends on type
A session description consists of a session-level description (details that apply to the
whole session and all media streams) and optionally several media-level descriptions
(details that apply only to a single media stream and override corresponding session-level
data). The session level description appears first, beginning with the v(ersion) type, and
is terminated when the first (or only) media level description appears. Each media
description starts with a m(edia name).
The order of the SDP text lines in a session description is fixed. Optional lines may be
omitted, but the lines included in a session description must always appear in the same
order. This simplifies parsing.
Table 22: SDP session description lines and their use

Type Meaning Format / content M/O
Information applicable to all media streams in a session
v Version SDP version number M
[1]
o Originator UserID and host address of session originator M [2]
s Session Session name M [2]
i Information Information about session (descriptive text string) O
u URI Universal Resource Identifier of session description O
e Email Email address of session originator O
c Connection [1] M
Target address
b Bandwidth Bandwidth information O
z Zone Time zone information O
k Key Encryption key O
Payload type (denoted by numeric identifier)
a Attributes O
and algorithm (e.g. G.711a for A-law PCM)
t Time Start time of session (0 for immediate start) M [2]
r Repetition Repetition information, e.g. initiate session weekly O
Information applicable to one media stream within a session (overriding session information)
Media stream description, comprising:
- Media type (typically audio in SNH01)
m Medium - Destination port M
- Transport protocol, e.g. UDP or RTP
- Media format (numeric identifier of payload type)
i Information Information about media stream (descriptive text string) O
c Connection [1] O
Target address

Table 22: SDP session description lines and their use

Type Meaning Format / content M/O
b Bandwidth Bandwidth information O
k Key Encryption key O
Payload type (denoted by numeric identifier)
a Attributes O
and algorithm (e.g. G.711a for A-law PCM)
[1] Address comprises network type, address type and address. For an IP network, these are IP, IP4
and IP address respectively. For an ATM network, address types NSAP (Ethernet), E164 and
GWID are supported.
[2] Although defined as mandatory in the SDP specification, this is not supported by CS2000.
The most important SDP types are described below.

Note: For VoIP, SDP conveys IP address information as specified in RFC2327. For the
CS2000 implementation of VoATM (VoAAL2 using PVGs), SDP conveys ATM address
information by means of SDP extensions defined in the following ID:
draft-rajeshkumar-mmusic-sdp-atm-01
This draft extends SDP to support ATM endpoint information instead of IP in setting up
an ATM communication path based on VoAAL2. With the implementation of this draft,
CS2000 need not be aware of the packet network differences between VoATM or VoIP.
O (Originator)
Identifies the originator of the session (username and users host address).
o=username session-id version network-type address-type address
where
username is the user's login at the originating host
address is the address of the host creating the session, and is of the type
specified by address-type
network-type is IN (meaning Internet)
C (Connection)
Identifies the address to which data is to be sent.
c=network-type address-type connection-address
where
network-type is IN (meaning Internet)
connection-address is the target address, and is of the type
specified by address-type
M (Medium)
Indicates the media format supported by the sender.
m=media port transport format-list
where
media is the media type (e.g. audio, video)
port is the port to which packets should be sent.
transport is transport protocol (e.g. UDP, RTP, H.320)
format-list gives the media format (e.g. A-law PCM, MPEG-2 video)

Chapter D2 SIP and SIP-T
D2.1 Purpose
CS2000 uses Session Initiation Protocol (SIP) or SIP for Telephony (SIP-T) to support
peer-to-peer signalling with other CS2000s and with compatible peer MGCs such as the
MCS5200. The difference between SIP and SIP-T is that SIP-T messages convey
encapsulated CCS7 messages while SIP messages do not. SIP-T therefore supports CCS7
signalling directly, by enabling CCS7 messages to be inserted in and extracted from SIP-T
messages. SIP does not provide direct CCS7 support, but SIP messages can be
interworked with CCS7 equivalents to provide indirect CCS7 support. In general,
references to SIP should be taken to include SIP-T unless this is otherwise indicated.
With effect from ISN07, CS2000 supports two implementations of SIP:
! In the preferred implementation, SIP functionality is provided by the Session
Server, while CCS7 functionality is provided by Dynamic Packet Trunk (DPT)
GWCs. Session Server support for SIP signalling and CCS7 encapsulation is
interoperability between call servers and other network elements.
! Prior to ISN07, CS2000 support for SIP was based on RFC2543 and other
pre-RFC3261 drafts. It was implemented by configuring GWCs as VRDNs (Virtual
Router Distibution Nodes) to provide initial points of contact for peer-to-peer SIP
signalling. In this implementation, DPT GWCs are responsible for terminating SIP
signalling as well as CCS7 signalling. This VRDN implementation is still
supported, but has now been superseded by the Session Server implementation.
SIP uses the MIME mechanism to convey encapsulated information. Specifically, SIP-T
separately encapsulates both CCS7 signalling and complementary Session Description
Protocol (SDP) session descriptions so that they can be conveyed transparently across the
packet network. SIP encapsulates and conveys only SDP. See section D1.3 on page 239
for information about CS2000 support for SDP, which allows packet network endpoints
to exchange information about the bearer capabilities they can support.
See section E2.2.3 on page 376 for an annotated call flow that illustrates the use of SIP-T
to support the networking of a CCS7 call.
Note: As an alternative to the encapsulation of ISUP messages using SIP-T, the ITU has
defined the BICC (Bearer-Independent Connection Control) protocol, which is essentially
ISUP with packet-related extensions. Nortel have defined an implementation of BICC
known as ISUP+, but the CS2000 international product does not support this in ISN07.

Communication Server Capabilities Packet Telephony Protocols SIP and SIP-T
D2.2 CS2000 Support for Dynamic Packet Trunks

the duration of a given call, and is afterwards returned to the pool for re-use. The fact that
trunk group data for a selected DPT is downloaded to its DPT GWC only when the DPT
is selected and allocated promotes efficiency in two ways:
! It is not necessary to provision inter-CS trunks statically, which would involve
estimating the proportion of traffic to be handled by each type of trunk, with the
consequent risks of under-provisioning (leading to unnecessary congestion) or
over-provisioning (with wasted capacity).
! It is not necessary for a CS2000 or peer MGC to know the IP addresses of all the
DPT GWCs on another CS2000 with which it may need to communicate, only a
single target IP address on each remote CS2000.
interacting with the Session Server. In this implementation, SIP functionality is
provided entirely by the Session Server Specifically, the Session Server terminates
SIP signalling and extracts CCS7 signalling for the use of the DPT GWC.
Once a DPT GWC has been selected and provisioned, that GWC can communicate
directly with:
! Session Server (co-ordination of messages with GWC is via call ID)
! Call processing, which can identify the trunk via a standard terminal ID (as if it had
been statically provisioned)
! The appropriate access GWC
Figure 64 on page 245 illustrates how DPT GWCs interact with these other units to
support inter-MGC communication via SIP / SIP-T.

SIP and SIP-T Packet Telephony Protocols Communication Server Capabilities
GWC support for inter-CS signalling using Session Server

DPT DPT
DPT Inter-CS DPT

GWC connection GWC
Access Session Session Access
GWC DPT Server Server DPT GWC
GWC GWC
DPT DPT
GWC GWC
Session Servers terminate

SIP / SIP-T signalling
Media Media
gateway gateway
DPT GWCs terminate CCS7 signalling
GWC support for inter-CS signalling using a VRDN
DPT DPT
Inter-CS
DPT connection DPT
GWC VRDN GWC
Access Access
GWC DPT A GWC DPT GWC
GWC GWC
No VRDN
DPT for call DPT
GWC origination B GWC
A Signalling for initial INVITE and redirection

response is between DPT GWC and VRDN
Media Media
gateway gateway
B All SIP / SIP-T signalling after redirection is between DPT GWCs
Figure 64: DPT GWC interaction with other units to support peer-to-peer SIP signalling

D2.3 SIP Characteristics

Figure 65 below illustrates the structure of a complete GWC-to-GWC message, showing
how SIP fits into the protocol stack and how a SIP/SIP-T message is used as an envelope
for other types of signalling. The example shows the use of ETSI ISUP V1, but SIP-T
can support the encapsulation of any CCS7 ISUP or TUP protocol supported in ISN07
(see Chapter E1: Overview of Support for Telephony Interfaces for details).
CCS7 message (ISUP or TUP)

Encapsulated CCS7
signalling (SIP-T only)
Envelope message
MIME information
Application = (e.g.) ETSI ISUP V1
SDP Information about packet
network bearer capabilities
(for codec negoitation
MIME information between endpoints)
Application = SDP
SIP header SIP message type indicates its
(msg type, source, dest, call ID, etc) function, and can be mapped on
to an IBN7 ISUP equivaloent
TCP (Transaction Control Protocol) (for SIP with no encapsulated
or UDP (User Datagram Protocol) CCS7)
IP TCP for Session Server;

UDP for VRDN / DPT GWC
Figure 65 Structure of a complete SIP/SIP-T inter-CS message
The characteristics of SIP-T can be summarised as follows:

! SIP conveys information primarily by means of the message type used, which
depends on the current state of the call and the call event being initiated or reported.
Message content is kept to a minimum. SIP-T relies on the encapsulated CCS7 user
part message to convey all the signalling information needed for call processing.
! SIP and SIP-T both rely on the Session Description Protocol (SDP) described in
section D1.3 on page 239 to convey information about the media streams to be used
in a session (call or conference) and the IP addresses of the participants.
! SIP-T messages are potentially able to convey any suitable user part messaging (e.g.
ISUP, TUP, Q.931, QSIG or DPNSS), though only ISUP and TUP encapsulation is
supported in ISN07.
! SIP-T ISUP encapsulation can include support for feature transparency, as follows:
" QFT (QSIG Feature Transparency) signalling conveyed via the ETSI ISUP
V3 APM (Application Transport Mechanism). See Chapter E5: QSIG VPN
Interface for information about CS2000 support for QSIG and QFT.
" DFT (DPNSS Feature Transparency) signalling conveyed via IBN7 ISUP
trunks. See Chapter E6: DPNSS Interface for information about CS2000
support for DPNSS and DFT.
! SIP-T cannot convey CCS7 TCAP signalling across the packet network. CS2000
supports TCAP Non Call Associated Signalling (NCAS) over an IP network by
means of a TCAP / SCCP / MTP3 / M2PA / SCTP / IP protocol stack terminated on
the Universal Signalling Point (USP), as described in Chapter D12: MTP
Adaptation Protocols (M3UA and M2PA). (The only alternative is to convey
TCAP via a standard CCS7 signalling network based on MTP Layers 1-3.)

! SIP uses the MIME (Multipurpose Internet Mail Extensions) protocol defined in
RFC2046 to identify other protocols conveyed in SIP messages. CS2000 supports
the following combinations of media type and sub-type:
" application/sdp
" application/isup
" application/tup
" multipart/mixed
The tup media sub-type is a Nortel extension for the transport of IUP/BTUP and
SSUTR2/FTUP payloads.
The multipart/mixed payload type allows both SDP and CCS7 information to be
separately encapsulated in a single SIP-T message. In this case, the application/sdp
and application/isup payload information is delimited by STANDARD BOUNDARY
lines within the command body, as shown in the INVITE message example in
section D2.4 on page 248.
For user part payloads encapsulated in SIP-T, three parameters can be used to
specify protocol variant information:
" Version, e.g. etsi121 (V1), etsi356 (V2), ansi88, gb_iup, fr_ssutr2.
" Specification, e.g. ETSI ISUP national variant such as es_etsi121 (Spanish
V1) or de_etsi356 (German V2).
" Compatibility, i.e. yes/no to indicate support for ETSI ISUP V2 compatibility
mechanism.
The MIME type specifies which CCS7 protocol is being used, but a mechanism
outside the CCS7 protocol is required to convey the sort of additional information
associated with trunk groups in the existing TDM telephony network, e.g. customer
group. This information is provided by the proprietary X-Nortel-Profile header in
the SIP INVITE message. This header contains a text string (maximum 32 bytes)
that represents a set of trunk characteristics (i.e. maps to a trunk group). If this
header does not appear in the message, a default trunk group will be chosen, based
on the CCS7 protocol being used and the source CS2000.
! SIP messages are conveyed using either TCP (Transaction Control Protocol) or
UDP (User Datagram Protocol) over IP. TCP is used by the recommended Session
Server implementation, while UDP is used by the VRDN / DPT GWC
implementation. Message structure is illustrated in Figure 65.

D2.4 SIP Message Types

The standard SIP-T message/response sequence used to set up inter-CS calls is as follows:
! Forward INVITE (IAM equivalent)
! Backward 100 TRYING (no ISUP equivalent)
! Backward 180 RINGING (ACM)
! Backward 200 OK (ANM)
This section describes the formats of the most important messages and responses.
Note: Because there are differences between the message formats defined in RFC3261
and RFC2543, two INVITE examples are provided.
INVITE Example (RFC3261 format, as used by Session Server)

An INVITE request is sent to invite a remote user to participate in a SIP session. INVITE
is always the first message sent in a session. The message body contains a description of
the session to which the called user is being invited. Specifically, the SDP payload
indicates which media types the calling user can handle and the address to which these
should be sent. The response to the INVITE message indicates which media types the
called user can handle and the address to which these should be sent.
INVITE sip:2461803@47.174.73.242 SIP/2.0
From:
<sip:9192461802@47.142.210.200>;tag=c8d28e2f-13c4-3f7776e3-160d-41
bac49c
To: <sip:2461803@47.174.73.242>
Call-ID: 0094.4609-28-17-05-18.82@MGCA
CSeq: 1 INVITE
User-agent: CS2000/7.0
Mime-Version: 1.0
Max-Forwards: 70
Supported: 100rel
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,NOTIFY,REFER
Via: SIP/2.0/TCP
47.142.210.200:5060;branch=z9hG4bK-3f7776e3-160d-11156ea5
Contact: <sip:9192461802@47.142.210.200>
Content-Type: multipart/mixed ;boundary=unique-boundary-1
Content-Length:358
--unique-boundary-1
c: application/SDP ;charset=ISO-10646
v=0
o=MGCP 0 0 IN IP4 47.174.73.241
s=MGCP Call
c=IN IP4 47.174.73.241
t=0 0
m=audio 5004 RTP/AVP 0 96
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:20
--unique-boundary-1
c: application/ISUP ;version=gr394 ;base=gr394

INVITE Example (RFC2543 format, as used by DPT/VRDN)

An INVITE request is sent to invite a remote user to participate in a SIP session. INVITE
is always the first message sent in a session. The message body contains a description of
the session to which the called user is being invited. Specifically, the SDP payload
indicates which media types the calling user can handle and the address to which these
should be sent. The response to the INVITE message indicates which media types the
called user can handle and the address to which these should be sent.
INVITE sip:1628457642@CS2000B.NORTEL.COM;user=phone SIP/2.0
X-Nortel-Profile:ETSIV2GROUP1
Call-ID:0037.4002-17:13:47:40.58@CS2000A.NORTEL.COM
CSeq:1 INVITE
To:<sip:1628457642@CS2000B.NORTEL.COM;user=phone>
From:<sip:1184977320@CS2000A.NORTEL.COM;user=phone>
MIME-Version:1.0
Content-Type:multipart/mixed; boundary=STANDARD_BOUNDARY
Content-Length: 272
--STANDARD_BOUNDARY
Content-Type:application/sdp;charset=ISO10646
v=0
c=IN IP4 47.113.186.10
m=audio 21790 RTP/AVP 0
--STANDARD_BOUNDARY
Content-Type:application/isup; version=etsi; compatibility=yes
01 00 60 00 0a 00 02 0a 08 03 90 53 02 18 60 00 f4 0a 07 03 13 81
81 01 06 10 3d 01 1f 31 02 00 00 39 04 3d c0 31 c0 00
--STANDARD_BOUNDARY--
INVITE Message Contents

Media stream information and address information for the media stream is specified using
the Session Description Protocol (SDP) described in section D1.3 on page 239, and is
encapsulated transparently in the body of the INVITE message.
The example shown is a SIP-T INVITE message that also contains an encapsulated CCS7
message. The table below lists the protocols supported as SIP-T Content-Types in ISN07.
Message body content Media type Base Version

ISUP (ETSI V1) application/ISUP etsi121 N/A
ISUP (Brazilian V1) application/ISUP etsi121 br_etsi121
ISUP (Czech V1) application/ISUP etsi121 cz_etsi121
ISUP (Danish V1) application/ISUP etsi121 da_etsi121
ISUP (Italian V1) application/ISUP etsi121 it_etsi121
ISUP (Malaysian V1) application/ISUP etsi121 ma_etsi121
ISUP (Mexican V1) application/ISUP etsi121 mx_etsi121
ISUP (Norwegian V1) application/ISUP etsi121 no_etsi121
ISUP (Portuguese V1) application/ISUP etsi121 pt_etsi121
ISUP (Spanish V1) application/ISUP etsi121 es_etsi121
ISUP (Telmex V1) application/ISUP etsi121 tm_etsi121

Message body content Media type Base Version

ISUP (Turkish V1) application/ISUP etsi121 tu_etsi121
ISUP (ETSI V2) application/ISUP etsi356 N/A
Australian ACIF G.500 I-ISUP application/ISUP etsi356 au_etsi356
Australian Telstra CA30 ISUP application/ISUP etsi356 au_etsi356
ISUP (Austrian V2) application/ISUP etsi356 os_etsi356
ISUP (Belgian V2) application/ISUP etsi356 bg_etsi356
ISUP (Chilean V2) application/ISUP etsi356 chl_etsi356
ISUP (Chinese V2) application/ISUP etsi356 ch_etsi356
ISUP (German V2) application/ISUP etsi356 de_etsi356
ISUP (German G-ISUP V2) application/ISUP etsi356 dg_etsi356
ISUP (Hong Kong V2) application/ISUP etsi356 hk_etsi356
ISUP (Hungarian V2) application/ISUP etsi356 hu_etsi356
ISUP (Israeli V2) application/ISUP etsi356 is_etsi356
ISUP (Italian V2) application/ISUP etsi356 it_etsi356
Japan I-ISUP application/ISUP etsi356 jp_etsi356
ISUP (Polish V2) application/ISUP etsi356 po_etsi356
ISUP (Singapore V2) application/ISUP etsi356 sg_etsi356
ISUP (Spanish V2) application/ISUP etsi356 es_etsi356
ISUP (Swedish V2) application/ISUP etsi356 sw_etsi356
ISUP (Turkish V2) application/ISUP etsi356 tu_etsi356
UK ISUP (ETSI V3) application/ISUP etsi356 gb_etsi356
French ETSI V3 (SPIROU) application/ISUP etsi356 fr_etsi356
ISUP (ANSI) application/ISUP ansi88 N/A
ISUP (ANSI FGD) application/ISUP ansi88 N/A
UK IUP / BTUP application/TUP gb_iup N/A
FTUP (SSUTR2) application/TUP fr_ssutr2 N/A
CTUP (China TUP) application/TUP ch_tup N/A

INVITE Responses
A series of response messages is normally received in response to an INVITE message.
These indicate the progress of call setup, and may also provide SDP address and media
stream information. The message format is:
<response-code> <progress-indication>
where
response-code is a three-digit numeric identifier beginning with 1 or 2. 2xx
codes indicate successful completion of a request; 1xx codes are used
to convey information.
progress-indication is a one-word indication of the progress of call setup
The most common responses are:

! 100 TRYING
This indicates that the far-end media gateway has received the INVITE message and
will try to select a terminating port to complete the call. No payload is sent in this
response.
! 183 SESSION PROGRESS
This indicates that an SDP session description from the far-end media gateway is
available in the body of the message.
! 180 RINGING
This indicates that ringing is being applied to the called partys line, and is sent
when a backward ACM has been received by the terminating CS2000. An SDP
session description from the far-end gateway can also be provided in the body of
this response.
! 200 OK
This indicates that the called party has answered, and is sent when a backward ANM
is received by the terminating CS2000. An SDP session description from the far-end
gateway can also be provided in the body of this response.
ACK
An ACK message is sent by the originating CS2000 to confirm that it has received the
final response to an INVITE message (typically a 200 OK message). If the definitive SDP
session description to be used by all parties differs from the one provided in the original
INVITE message, the modified session description is provided in the body of the ACK
message.
BYE
The BYE message is sent on behalf of a call party to indicate that the party wishes to
release the call. When CS2000 receives a BYE message, it terminates the transmission of
all media streams specifically directed at the party issuing the BYE request, and indicates
that it has done so by sending back a 200 OK response to the BYE.

INFO
The INFO message allows call progress and session description information to be
conveyed between call parties during an active call. It is a general-purpose mechanism for
conveying PSTN and SDP protocol information.
INFO is required in order to carry mid-call PSTN signalling from the originating PSTN
network through the SIP network to the destination PSTN network, e.g. ISUP messages
like INR, INF and PAM.
INFO messages are also used to convey encapsulated SAM messages if overlap signalling
is in use. An INFO message used for this purpose conveys the same CallID as the initial
INVITE message, but its CSeq number is incremented by 1 from the most recent setup
message for the call (the initial INVITE or a previous INFO ).
D2.5 SIP-T Message Parameters

SIP-T fields / parameters (see the INVITE example on page 249 for format details):
! Request URI
Indicates the destination user and CS2000 to which a request is being addressed.
URIs using schemes other than sip are not supported, and only the user and host
field is are currently utilised although the implementation of the SIP URL supports
user, password, host and port fields. URI parameter "user" with value "phone" is
also appended to the SIP URI to indicate that the username (pre-@) portion of the
SIP URI is that of a telephone subscriber. The format is therefore:
sip: username@host;user=phone
! Status line
Used in a response message to provide information about the progress or final
outcome of a request. Format:
Status-Line = SIP-version Status-Code Reason-Phrase
Status-Code is a 3-digit integer result code that indicates the outcome of the attempt
to satisfy the request. 2xx status codes indicate successful completion of a request,
while 1xx codes are used for information.
Reason-Phrase is intended to give a short textual description of the Status-Code.
The Status-Code is intended for use by automata, whereas the Reason-Phrase is
intended for the human user.
! Headers
Headers are composed of fields (comparable to parameters in ISUP). Each method
(message type) has mandatory and optional fields. The most important fields are
described below. Fields are encoded as given below.
<field_name>: <value>

! X-Nortel-Profile:ETSIV2GROUP1
A text string that represents a set of trunk characteristics (i.e. maps to a trunk group),
allowing an INVITE message to convey the sort of information associated with
trunk groups in the existing TDM telephony network, e.g. customer group. If no
X-Nortel-Profile header appears in an INVITE message, a default trunk group will
be chosen, based on the CCS7 protocol being used and the source CS2000.
! CallID
Together with the To and From headers, the CallID header uniquely identifies a
particular invitation (call setup attempt). On CS2000, it is used by the VRDN that
receives a SIP-T message to route the message to the right SIP-T GWC. The header
value is a character array up to 64 bytes in length, with three segments:
" A string uniquely identifying the hardware unit that generated the call.
" A timestamp consisting of five two-digit fields separated by colons. The fields
are: day:hour:minute:second:ABS(milli-second/10).
" The local host name, preceded by a @.
An example of a Call-ID header value appears below:
0057.4002-17:11:59:59.99@dcs.nortelnetworks.com
! CSeq
Clients add the CSeq (command sequence) field to every request. A CSeq field in a
request indicates the request method (SIP-T message type) and provides a decimal
sequence number that uniquely identifies the request within the context of a given
CallID. The sequence numbers of consecutive requests with the same CallID must
be contiguous. An ACK or CANCEL request must contain the same CSeq value as
the corresponding INVITE request; a BYE request cancelling an invitation must
have a sequence number greater then that of the INVITE (or the last INFO). Format:
CSeq: 1 INVITE
! To
Specifies the intended recipient of the request, i.e. the identity of the destination
CS2000 and user in SIP URL format.
! From
Indicates the originator of the request, i.e. the identity of the originating CS2000 and
user in SIP URL format.
! Content type
The Content-Type entity-header field indicates the media type of the message-body
sent to the recipient. e.g.
Content-Type: application/sdp
Content-Type: text/html; charset=ISO-8859-4

D2.6 Service Support Capabilities

D2.6.1 Remote Bearer Control (RBC)
The RBC mechanism enables call processing or service logic on one CS2000 to specify
what should happen to a bearer channel or media stream controlled by a remote CS2000.
The service request specifying the required media stream manipulation is conveyed
between the CS2000s by means of SIP-T signalling.
A backward service request from a terminating CS2000 is received by the egress SIP-T
GWC on the originating CS2000 and passed on to the GWC for the originating media
gateway. A simple service request such as the application of an in-band tone towards the
calling party (e.g. audible ringing) is conveyed to the originating media gateway by means
of device/media control signalling, e.g. via ASPEN.
Use of the RBC mechanism means that an originating media gateway provides service
support in essentially the same way regardless of whether the call in question terminates
locally or on a remote CS2000. There is no need for the terminating media gateway to be
involved, e.g. by having to provide a tone over a packet-side connection.
See section F1.2 on page 518 for a more detailed description of the RBC mechanism and
a discussion of the issues involved in using it. This section also deals with when it is
necessary to introduce a TDM looparound trunk into a call to provide access to packet
network media streams (e.g. for digit collection or tone insertion) for calls received by
ingress DPT GWCs.
D2.6.2 Audits
CS2000 uses two mechanisms to maintain the integrity of connections with other MGCs
and calls established over those connections:
! Connection audits
This is the mechanism used to verify the continuing availability of a remote MGC.
CS2000 uses heartbeat messaging based on sending a SIP-T OPTIONS message
every 20 seconds. If the (lack of) response indicates that the connection is down,
CS2000 initiates a call audit (see below).
! Call audits
CS2000 runs a call audit every 10 minutes to determine the status of calls to/from
other CS2000s. This involves sending a SIP-T INFO message, and releasing a call
if the message response indicates that it is no longer live. Such calls are not billed.
When a SIP-T GWC (or a VRDN if SCTP is in use) receives such a SIP-T INFO
message, it compares the call ID in the INFO message with its own call ID table. If
the call ID exists in the call ID table, the GWC returns a 200 OK message; if not,
the GWC sends back a 481 message response.
Note: If a SWACT takes place at a remote SIP-T GWC, the connection is maintained but
calls may be lost. This will be detected at the next call audit.

D2.6.3 Interworking with MCS5200

The MCS5200 Multimedia Communications Server is a peer MGC on a par with CS2000.
It can be deployed as a stand-alone solution in its own right. It can also, however, be
deployed as part of a complete Succession solution involving both MCS5200 and
CS2000. In this case, the MCS5200 LAN is typically co-located with the CS2000 CS
LAN and configured as an additional VLAN. See Chapter B6: Multimedia
Communication Server (MCS52000) for details.
as intermediaries between MCS5200 and remote clients of the following types:
! Remote IP telephony clients such as i2004 Ethersets.
! Remote Web clients to permit browser access to multimedia servers.
! Remote multimedia clients such as SIP PC clients and SIP IP phones.
Interworking with MCS5200 enables CS2000 to support calls to/from MCS5200 SIP
clients and to support selected services on those calls. In protocol terms, CS2000 and
MCS5200 are peer entities, and communicate with each other by means of SIP.
The version of SIP used for CS2000-MCS5200 communication has the following
characteristics:
! No encapsulated CCS7 messages are included in the SIP-T messages. Instead, the
CCS7 meaning of each SIP-T message must be inferred from the message header
and parameters. For this purpose, three parameter enhancements are supported:
" Support for Via: parameter that specifies the protocol stack used, originating
node name and branch identifier.
" Enhancement to the URL format used in To: and From: parameters to allow
a SIP URL consisting of a telephone number and user=phone to be specified.
The SIP URL is included in angle brackets to distinguish it from the
remainder of the parameter line, which allows other information to be
provided as well. This is referred to as "name-addr" functionality.
! The additional information associated with trunk groups in a TDM telephony
network, e.g. customer group, is provided by the proprietary X-Nortel-Profile
header in the SIP INVITE message. This header contains a text string that can be
mapped to a trunk group with an associated set of trunk characteristics.
! The only CCS7 protocol that can be emulated is IBN7 (ANSI ISUP+).
! TCP or UDP transport can be used
The message sequence used to set up calls between CS2000 and MCS5200 is as follows:
! Forward INVITE (IAM equivalent)
! Backward 100 TRYING (no ISUP equivalent)
! Backward 180 RINGING (ACM)
! Backward 200 OK (ANM)

Chapter D3 H.248
D3.1 Purpose
H.248 is a joint ITU-T / IETF protocol designed to support signalling between Media
Gateway Controllers and Media Gateways. It is defined in ITU-T Recommendation
H.248 "Gateway Control Protocol" and IETF Megaco RFC3015 "Gateway Control
Protocol". In a CS2000 context, H.248 is currently used for device/media control
signalling between CS2000 GWCs and the following types of unit:
! PVG configured as a trunk media gateway supporting CCS7 or PRI access to the
packet network, as described in section B2.3: PVG (Packet Voice Gateway)
Trunk Gateways on page 99.
Note: H.248 has superseded the use of the proprietary ASPEN protocol (see
Chapter D4: ASPEN) as the standard CS2000 protocol for control of trunk
gateways supporting CCS7 and PRI access to the packet network. Use of ASPEN
for this purpose is still supported for existing deployments. In addition, ASPEN is
currently the only protocol that has been verified for control of trunk gateways
supporting QSIG access. H.248 is based on a more flexible functional model than
ASPEN (see section D3.3 on page 260), which is designed to provide better support
for multimedia and conference capabilities.
! Mediant 2000 CPE trunk media gateway, as described in section B2.6: Mediant
2000 Trunk Gateway on page 116.
! PVG configured as a V5.2 gateway supporting V5.2 interfaces connected to V5.2
Access Networks (ANs) serving V5.2 PSTN lines, i.e. analogue subscriber lines, as
described in section B2.4: PVG as a V5.2 Gateway on page 111.
! High-capacity line media gateways located on operating company premises, as
described in section B2.8: Carrier-Located Line Media Gateways on page 119.
! An MS2000 or UAS media server used to provide:
" Packet-based announcement capabilities
" Packet-based conferencing (multi-party calls)
" BCT (Bearer Channel Tandem) functionality for LI (Lawful Intercept)
monitoring of packet network bearer connections
See Chapter B3: CS2000 Support for Media Servers for further information.
Note: To complement H.248, SDP session descriptions are conveyed in-line with H.248
commands and responses. See section D1.3 on page 239 for more information about SDP.

H.248 Packet Telephony Protocols Communication Server Capabilities
D3.2 Network Role

D3.2.1 H.248 Support for Trunk Access
CS2000 uses H.248 to support two types of trunk access, as follows:
! To support CCS7 turnks terminated on PVGs, H.248 is used for device/media
control signalling between GWC and PVG, to control the characteristics of packet
network bearer connections. The related call control signalling is groomed off and
conveyed via a conventional CCS7 signalling network to terminate on a USP or
FLPP at the CS2000; it does not trraverse the packet network.
! To support PRI trunks terminated on PVGs, two types of signalling are conveyed
between the PVG and its CS2000 GWC. H.248 is one of the two protocols used, as
follows:
" H.248 is used for device / media control signalling that allows the GWC to
control the characteristics of the packet network bearer connection used for a
call.
" Q.931 signalling, including call control messages, is backhauled to the GWC
so that call processing can take place at the CS2000. The protocol used for this
is IUA (ISDN User Adaptation), which is described in Chapter D10: IUA.
Figure 66 illustrates the network role of H.248 signalling in supporting both of these types
of trunk access.
CS2000 CS2000
Access Access
Gateway DPT GWC DPT GWC Gateway
Controller and Session and Session Controller
(GWC) Server; Server; (GWC)
TDM-side packet-side packet-side TDM-side
Inter-CS communication via

SIP-T encapsulation of CCS7
For CCS7 trunks,

H.248 is used for all For PRI access, H.248 is one of two
GWC-MG signalling protocols used for GWC-MG signalling.
(CCS7 signalling is Media control signalling uses H.248
groomed off, and (with SDP session description commands
does not traverse in-line) conveyed over UDP.
the packet network) Backhauled Q.931 Layer 3 call control
signalling is conveyed over IUA and SCTP
CCS7 PRI
Bearer connection
trunk trunk
gateway gateway
PSTN or other
TDM network PRI PBXs
Figure 66: Network role of H.248 signalling in supporting trunk access

Communication Server Capabilities Packet Telephony Protocols H.248
D3.2.2 H.248 Support for Line Access

CS2000 uses H.248 to support two types of line access, as follows:
! To support V5.2 lines off a PVG, two types of signalling are conveyed between the
PVG and its CS2000 GWC. H.248 is one of the two protocols used, as follows:
" H.248 is used for device / media control signalling that allows the GWC to
control the characteristics of the packet network bearer connection used for a
call.
" V5.2 signalling, including V5-PSTN messages for call control, is backhauled
to the GWC so that call processing can take place at the CS2000. The protocol
used for this is V5UA (V5 User Adaptation), which is described in Chapter
D11: V5UA.
! To support lines off a carrier-located line media gateway, H.248 is used both for
device/media control signalling and for call control signalling.
Figure 67 illustrates the network role of H.248 signalling in supporting both of these types
of line access.
CS2000 CS2000
Access Access
Gateway DPT GWC DPT GWC Gateway
Controller and Session and Session Controller

For V5.2 access, H.248 is one of two For MG9000

protocols used for GWC-MG signalling. lines, H.248
Media control signalling uses H.248 is used for all
(with SDP session description commands GWC-MG
in-line) conveyed over UDP. messaging
Backhauled V5.2 Layer 3 call control
signalling is conveyed over V5UA and SCTP
V5.2 Bearer connection MG9000

gateway gateway
V5.2 interface
consisting of
1-16 E1 carriers
Analogue
V5.2 Access subscriber lines
Network (AN) and ADSL lines
Figure 67: Network role of H.248 signalling in supporting line access

D3.2.3 H.248 Support for Media Server Capabilities

Figure 68 illustrates the network role of the H.248 protocol in supporting media server
capabilities via the MS2000 or UAS described in Chapter B3: CS2000 Support for
Media Servers.
CS2000
Audio
GWCs Controller
GWC
H.248 commands,
e.g. Add,
controlling
terminations and
contexts (calls)
Responses
Media gateways
supporting: Media
server
Trunks (MS2000
Lines or UAS)
Media server supports four types of connection across the packet

network (it does not support TDM-side terminations):
One-way connections for the delivery of packetised
announcements.
Two-way connections between call parties and conference ports.
Twin one-way connections replicating intercepted audio streams
for Lawful Interception. (Intercepted audio streams are tandemed
through the media server via internal two-way bearer channel
connections.)
Two-way connections for testing TDM-side trunks.
Figure 68: Network role of H.248 in supporting media server capabilities
H.248 signalling is conveyed over UDP.

The audio GWC and the MS2000/UAS media server are separately provisioned with the
address information they need to communicate with each other via H.248. Audio GWC
datafill specifies the media server IP address, UDP port and endpoints available.
Similarly, media server datafill (as defined via its EM) specifies the IP address and UDP
port of the Audio Controller GWC.
Note: For the MS2000/UAS media server, there is a level of abstraction between logical
endpoints known to the Audio Controller GWC and terminations supported by the media
server. The media server does not have any physical terminations, in the sense of statically
provisioned endpoints that could be addressed by the Audio Controller GWC. It does have
physical resources, i.e. ports on the DSP cards used to support announcements,
conferencing or bearer channel tandeming. The ports on MS2000/UAS DSP cards make
up a pool of resources for use by the GWC, but the GWC cannot identify or access specific
DSP ports or cards; instead, it specifies its requirements in terms of the logical
terminations required to set up a call, leaving it to the media server to ensure that the
appropriate type of physical resource is available for each termination.

D3.3 Functional Model

D3.3.1 Terminations and Contexts
The H.248 functional model is defined in terms of terminations and contexts, which are
supported at media gateways and can be manipulated by MGCs by means of H.248
commands.
! A termination sources and/or sinks one or more media streams (audio, data or
video).
! A context is an association between all the terminations involved in a given
conference. For example, a simple voice call is an association between two
terminations that sink/source audio.
A media stream exists only within a context; it has no independent existence.
A termination can correspond to a physical trunk or line endpoint served by a gateway
(e.g. an E1 timeslot or an RJ-11 port), or to a packet network bearer connection
represented by a transport address (typically IP address plus UDP port).
Physical terminations are statically defined by means of MGC and gateway datafill, and
exist regardless of whether they are actually in use. Terminations representing packet
network connections are said to be ephemeral because they exist only for the duration of
their use. Such an ephemeral termination is created by a gateway in response to a H.248
Add command that adds it to a context, and ceases to exist when a Subtract command is
received that removes it from a context.
Both types of termination can have signals applied to them. They can also be programmed
to detect events, the occurrence of which can trigger notification messages to the MGC or
action by the gateway itself.
Each termination is identified by a terminationID, which is unique within a given media
gateway. The terminationID assigned by a gateway to a dynamically created logical
termination is reported to the MGC when the termination is created so that it can be
specified in subsequent H.248 commands. The special terminationID ROOT represents a
complete media gateway.
A new context is created when the first termination is added to it, and an existing context
is deleted when the last remaining termination is removed from it. An active context is
identified by a contextID, which is unique within a given media gateway. The contextID
assigned by a gateway when it creates a new context is reported to the MGC when the
context is created so that it can be specified in subsequent H.248 commands. A
termination can belong to only one active context. Two special contextIDs are defined:
! NULL denotes a special context used to group all currently idle physical
terminations.
! UNSPECIFIED is used in an Add command that implicitly creates a new context
by adding the first termination to it.
Different types of gateway may support terminations that have widely differing
characteristics. Variations in termination capabilities are accommodated in the H.248
protocol by defining standard packages of optional termination properties, events, signals
and statistics. Typically, a termination supports a subset of the capability packages
available. An MGC can audit a termination to determine which capabilities it supports.

D3.3.2 MS2000/UAS Support for the H.248 Functional Model

For the MS2000/UAS media server, there is a level of abstraction between logical
endpoints known to the Audio Controller GWC and terminations supported by the media
server. The media server does not have any physical terminations, in the sense of statically
provisioned endpoints that could be addressed by the Audio Controller GWC. The ports
on MS2000/UAS DSP cards make up a pool of resources for use by the GWC, but the
GWC cannot identify or access specific DSP ports or cards; instead, it specifies its
requirements in terms of the logical terminations required to set up a call, leaving it to the
media server to ensure that the appropriate type of physical resource is available for each
termination.
The media server manages pools of resources for the following types of termination:
! Terminations for ephemeral connections
To add an ephemeral termination to a context, the GWC sends the media server an
Add=$ command, in response to which the media server dynamically assigns an
identifier of the form te/tepooln/n. The GWC can use this identifier in
subsequent commands, to denote a termination used for a packet network
connection with a call party.
! Audio terminations
To add an audio termination to a context, the GWC sends the media server an
Add=audio/$ command, in response to which the media server dynamically
assigns an identifier of the form audio/audiopooln/n. The GWC can use this
identifier in subsequent commands, to denote an audio termination used for the
playing of announcements.
! Conference terminations
Sets of conference terminations are used to support user conferences with up to 30
participants
To reserve a set of conference terminations for use in a context, the GWC uses the
ContextAttr (ctxr) package to specify that conferencing is required and indicate how
many ports should be reserved. This package is a proprietary addition to H.248, but
has been submitted for inclusion in the next version of the standard. It is specified
immediately after the Context=$ command used to open the context, and has the
form
ContextAttr{ctxr/type=type,ctxr/size=n,ctxr/res=reserve}
where type is conf for user conferencing or bct (bearer channel tandem) for LI.
Once this has been acknowledged by the media server, the GWC can send the media
server an Add=$ command for each conference participant.
! Monitoring terminations
Sets of conference terminations are used to support not only user conferences, but
also call monitoring for Lawful Interception (LI), which can be regarded as a special
type of conference in which packet network connections to the LEA (Law
Enforcement Agency) are passive participants.
To reserve a set of conference terminations for monitoring a call, the GWC uses the
ContextAttr (ctxr) package, as for a user conference, but specifies type as bct
(bearer channel tandem) for LI.

Resource usage is as follows for each type of service functionality supported by the media
server:
! Announcements
An audio termination for announcement provision, plus an ephemeral termination
for the call party to whom an announcement is to be played.
! Conferencing
A set of conference terminations, plus an ephemeral termination for each call party
who is to participate in the conference (matching the number of conference
terminations).
! LI
A set of conference terminations, plus an ephemeral termination for each party
participating in the monitored call, plus ephemeral LEA terminations (overall total
of ephemeral terminations matching the number of conference terminations).
An audio termination (or conference port) exists only in the abstract before it is added to
a context. It is the responsibility of the media server to assign a specific physical resource
from the pool of available resources, i.e. a logical port on a DSP card, to each audio
termination when it is added to a context. There is no permanent mapping between audio
terminations and resources, i.e. a given audio termination can be assigned a different
physical resource each time it is instantiated.
The requesting of physical resources by the GWC and their assignment by the media
server must be completed before the GWC can ask for the corresponding ephemeral
terminations to be added to a context.
D3.4 Commands Available

H.248 commands are grouped into transactions. Each transaction request is identified by
a transactionID that is unique within the scope of the sender (unique within the GWC in
the case of CS2000) and is used to correlate responses with requests.
A given transaction can include requests and responses that apply to multiple contexts
(and to multiple terminations within a context), but requests and responses that apply to a
given context must all belong to a single transaction.
The main H.248 commands are:
! Add
Sent from MGC to gateway to request it to add a termination to a context. In the case
of the first termination added to an UNSPECIFIED context, the Add command
implicitly creates the context. The media gateways response to an Add command
for a logical termination gives the transport address (e.g. IP address + UDP port).
Note: H.248 Add command supports negotiation for the following packet network
bearer path characteristics (see A59039029 for details):
" G.729a/b with RFC2833 for DTMF support
" T.38 for Group 3 fax
" Comfort noise insertion
! Subtract
Sent from MGC to gateway to request it to disconnect a termination from its
context. The Subtract command on the last termination in a context deletes the

context. The media gateways response to a Subtract command returns statistics on

the disconnected terminations participation in the context.
! Modify
Sent from MGC to media gateway to modify the properties, events and signals of a
termination, e.g. specifying events to be monitored and signals that can be applied.
! Notify
Sent from media gateway to MGC to report the detection of a monitored event.
! Move
Sent from MGC to media gateway to move a termination to a different context.
! AuditValue
Sent from media gateway to MGC to report the current state of termination
properties.
! AuditCapabilities
Sent from media gateway to MGC to report all the possible values currently
supported for termination properties.
! ServiceChange
Sent from media gateway to MGC to report that one or more terminations are about
to be taken out of service or have just been returned to service.
ServiceChange is also used by the media gateway to announce its availability to an
MGC (registration), and to notify the MGC of impending or completed restart of the
media gateway.
The MGC may announce a handover to the media gateway by sending it a
ServiceChange command.
All transaction requests and their responses are ASCII text messages.
D3.5 Descriptors (Command Parameters)

Command parameters are structured into a number of descriptors with the general form
DescriptorName=numericID { property1=value, property2=value, ... }
Properties may be fully specified, over-specified or under-specified, as follows:
! A fully specified property has a single, unambiguous value that must be used.
! An under-specified property allows the recipient of a command to choose any
property value that it can support.
! An over-specified property has a list of possible values in order of preference, from
which the recipient must choose the highest-ranked value that it can support.
Where the recipient of a command is allowed to choose a property value, the command
response indicates the value chosen.

The following table lists the most important Descriptors and their use.
Table 23: H.248 descriptors and their use

Descriptor Function
A list of media stream specifications to be sourced/sunk by a given
termination. Comprises one or more stream descriptors, each of which
Media consists of a streamID followed by values for stream properties such
as encoding and transport addresses. Within a context, streams that
have the same streamID are assumed to be connected.
Specifies properties that apply to a termination (rather than to a media
TerminationState
stream sourced/sunk by that termination), e.g. in or out of service
Stream A list of remote/local/localControl descriptors for a single stream
Media stream characteristics that apply to a stream received by the
Local
media gateway from a remote entity.
Media stream characteristics that apply to a stream sent by the media
Remote
gateway to a remote entity.
LocalControl Characteristics
of the control connection between the media gateway
and the MGC.
Specifies the direction(s) of media flow to be supported between
Topology terminations in a context.
Specifies signals to be applied to a termination. Signals can be
gateway-generated media streams such as tones and
announcements as well as line signals such as hook-flash. More
complex signals may include a sequence of simple signals
interspersed with and conditioned upon the receipt and analysis of
received data and signals.
Note: CS2000 also uses H.248 to convey H.248 equivalents of Media
Signals
Control Message Protocol (MCMP) data to the media server. MCMP
allows a language token and currency token to be provided to the
media server for use in assembling and playing a complex/variable
announcement. Initial aim is to allow INAP Price data specified via
PlayAnnouncement to be reformatted as MCMP Money data and sent
to media server. See A19012479 for details. Conversion of MCMP
messages to H.248 is performed by TAPI layer software in the GWC.
Specifies events to be monitored at a given termination, i.e. events
whose occurrence must be reported to the MGC. Can also be used to
specify the action the media gateway should take when it detects a
Events
monitored event.
Each Events descriptor has a RequestID that is used to correlate a
monitoring request with the notifications that it may trigger.

Table 23: H.248 descriptors and their use

Descriptor Function
A digit map is a dialing plan that is used by a media gateway in
analysing the digits received at a termination. A digit map may be
statically defined in gateway datafill and referenced by name, or may
be specified in a DigitMapdescriptor in a termination manipulation
command. The syntax used to define such a digit map is derived from
the UNIX GREP command.
The digit map capability can be used to collect not only called party
number digits, but also access codes, credit card numbers, and other
numbers requested by call control services.
Digits are buffered by the media gateway either until dialling is
complete, or until the gateway has determined that enough digits have
been collected, and are then provided to the GWC.
Assume, for example, that a terminal is to use the following dial plan:
0 Local operator
DigitMap 00 Long distance operator
xxxx Local extension number
8xxxxxxx Local number
#xxxxxxx Shortcut to local number at other corporate sites
*xx Star services
91xxxxxxxxxx Long distance number
9011 + up to 15 digits International number
This dial plan results in the following digit map:
(0| 00|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.)
Digit maps associated with the ROOT termination are global and can
be used on any termination in the gateway.
Note: The media server does not support H.248 digit maps, but can
support H.248-like digit maps via the Advanced Audio Server
Package.
Used in In Notify and AuditValue commands to report the occurrence
ObservedEvents
of a monitored event.
Packages can be used to simplify the assignment of property values. Each package
provides a complete set of default property values that can be assigned to a termination
when it is created. Thereafter, only non-default property values need to be explicitly
specified by using descriptors as parameters to H.248 termination commands.

D3.6 Command Usage

D3.6.1 H.248 Basic Call Setup for Trunks
For an incoming call over a TDM-side trunk, H.248 basic call setup begins when the
CS2000 Core receives either a CCS7 IAM or a Q.931 SETUP message from the GWC for
the originating trunk media gateway and uses this to perform translations and routing,
resulting in the selection of a terminating GWC and media gateway for the call.
To enable a bearer connection for the call to be set up between the two media gateways,
the GWC for the originating media gateway (and the GWC for the terminating media
gateway in the case of a trunk-to-trunk call) must initiate the following H.248 messaging
sequence:
1 GWC sends an Add command to the gateway, requesting it to add the specified
TDM-side trunk endpoint to an unspecified context.
2 Gateway creates a new context and adds the TDM-side trunk to it, then sends an
Add command response that provides the GWC with the context ID to be specified
in subsequent commands relating to this call.
3 GWC sends another Add command to the gateway, requesting it to add a logical
packet-side termination to the context.
4 Gateway adds logical termination to context, then sends an Add command response
that provides the GWC with the endpoint identifier (IP address) to use for this
logical termination, together with SDP description of bearer capabilities supported
(for use in codec negotiation with the gateway serving the remote endpoint).
To complete call setup, the GWC will subsequently send a series of Modify commands to
the gateway for the following purposes:
! Modify command providing gateway with updated SDP information for the packet
network bearer connection, reflecting the results of codec negotiation.
! Modify commands requesting gateway to apply ringback tone to originating
TDM-side trunk and (on called party answer) to open a two-way connection.
D3.6.2 H.248 Basic Call Setup for Lines

Figure 69 illustrates H.248 messaging for basic call setup on the originating side. This is
essentially the same for lines supported by an MG9000 carrier-located media gateway and
for V5.2 lines off PVGs. The only difference between the two scenarios is in how the
message sequence is initiated, as follows:
! When off-hook is detected on an MG9000 line, the gateway notifies the GWC by
sending a H.248 Notify command.
! For V5.2 lines off PVGs, the V5.2 AN provides off-hook notification by means of
a V5-PSTN ESTABLISH message, which the signalling gateway function on the
PVG relays to the CS2000 GWC using V5UA. The GWC then sends an V5-BCC
ALLOCATION message to the AN using V5UA. This additional V5.2 and V5UA
messaging is illustrated in Chapter D11: V5UA, in Figure 82 on page 337.
In both cases, the GWC responds to off-hook notification by sending a H.248 Modify
message requesting the gateway to apply dial tone and collect digits against a digit map.

Note: For simplicity, the diagram does not show messaging for PSTN feature support,
H.248 Ack messages or H.248 timers. Numbered references like (1) refer to example
H.248 message formats in Table 24 on page 268.
MG GWC
H.248 Notify command or

Caller V5UA (ESTABLISH)
goes
off-hook
H.248 Modify endpoint
(1) Apply dial tone
Dial tone Collect digits against digit map
1st
digit Dial tone
removed
H.248 Notify endpoint (2)
Digits Match against digit map
matching Onward
digit map call
H.248 Notify endpoint setup
Additional digit
(3) begins
More
digits
H.248 Add endpoint to context
Implicitly creates new context
H.248 Add packet port to context

Term-
ination
H.248 Modify packet port identified
SDP definition of port characteristics
H.248 Modify endpoint Apply

Ringback tone
(4) Apply ringback tone ringing
Stop digit collection

Mode=sendrecv
(5) H.248 Modify endpoint Off-hook /

Ringback tone Stop ringback tone answer
removed
Call in progress
Figure 69: H.248 call setup (originating side only)

Table 24: Example H.248 message formats for basic call setup
No. Description / format
(1) Apply dial tone, request digit collection via DigitMap, embedded is the request to continue
with single digit collection after DigitMap completion
Request (GWC to MG) Response (MG to GWC)
MEGACO/1 [47.174.66.80]:2944 MEGACO/1 [47.166.34.20]:2944
Transaction=62{ Reply=62{
Context=1002{ Context=1002{
Modify=E1/1/20/5{ Modify=E1/1/20/5
Events = 2223 { } }
dd/ce {DigitMap=Dialplan0 ,
Embed { Events = 2224
{dd/0,dd/1,dd/2,dd/3,
dd/4,dd/5,dd/6,dd/7,dd/8,dd/9} } } },
Signals {cg/dt},
DigitMap= Dialplan0 {
(0|00|[1-7]xxx|8xxxxxx
x|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.)
} } } }
(2) Notify DigitMap completion event
Request (MG to GWC) Response (GWC to MG)
MEGACO/1 [47.166.34.20]:2944 MEGACO/1 [47.174.66.80]:2944
Notify=E1/1/20/5{ Notify=E1/1/20/5
ObservedEvents =2223 { } }
19990729T22010001:dd/ce{ds="91613555121
2",Meth=FM }
} } } }
(3) Notify single DTMF event (e.g. DTMF digit 1)
MEGACO/1 [47.166.34.20]:2944 MEGACO/1 [47.174.66.80]:2944
ObservedEvents =2224 { } }
19990729T22010003:dd/d1 }
} } }
(4) Apply ringback tone and stop digit collection
MEGACO/1 [47.174.66.80]:2944 MEGACO/1 [47.166.34.20]:2944
Signals {cg/rt}, } }
Events
} } }
(5) Stop ringback tone
MEGACO/1 [47.174.66.80]:2944 MEGACO/1 [47.166.34.20]:2944
Signals { } } }
} }

D3.6.3 H.248 Support for Media Server Capabilities

This section uses some VoIP signalling examples to summarise how the media server uses
H.248 to support its main functions.
D3.6.3.1 Commands Used to Play an Announcement

Summary of most important commands used:
! Add command for the audio termination (DSP port) that is to provide the
announcement. For an announcement played during call setup, this Add command
will create a new context at the media server. The media server response to the Add
command will provide the audio termination ID and the context ID.
! Add command for the call party to whom the announcement is to be played. The
media server response to the Add command will provide the transport address (IP
address and UDP port) of the audio termination from which the announcement will
be sent across the packet network to the media gateway serving the call party.
! Announcement playback requested via Modify command with Signals descriptor.
Table 25: Example H.248 message formats for announcement playback
(1) Create a new context and add a new audio termination (both unidentified).
Response from media server provides a context ID and an audio termination ID, which is a logical
identifier that the GWC can use in subsequent commands to identify the logical port allocated.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Transaction=45{ Reply = 45 {
Context=${ Context = 9 {
Add=audio/$ Add = audio/audiopool0/2
} }
} }
(2) Add a new logical termination (ephemeral) to the context, i.e. in effect, connect a call leg (identified by IP
address) to the DSP port assigned to the audio termination previously aded to the context. The SDP in
the GWC command provides information about the media capabilities supported for the newly added call
leg.
The rersponse from the media server provides the GWC with an endpoint identifier that it can use for this
call leg in subsequent commands, and provides SDP information about the media server port attached
to the context.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Context=9{ Context = 9 {
Add=${ Add = te/tepool0/0 {
Media{ Media {
LocalControl{Mode=SendReceive}, Local {
Local{ v=0
v=0 c=IN IP4 47.174.66.103
c=IN IP4 $ m=audio 30216 RTP/AVP 0
m=audio $ RTP/AVP 0 a=ptime:10
a=ptime:10 }
}, }
Remote{ }
v=0 }
c=IN IP4 47.174.67.3 }
a=ptime:10
}}}}}

Table 25: Example H.248 message formats for announcement playback

(3) Execute a play signal of segment 640 on the audio termination, requesting notification
of completion and failure events. The response from the media server indicates that the signal is being
applied.
The media server sends a Notify message when when the play signal operation is complete, and this is
acknowledged by the GWC.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Modify=audio/audiopool0/2{ Modify = audio/audiopool0/2
Signals{ }
aasb/play{ }
an="sid=<http://localhost/640>"}
},
Events=33{
aass/audcomp,aass/audfail
}}}}
Response (GWC to media server) Message (media server to GWC)
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Reply=103{ Transaction = 103 {
Notify=audio/audiopool0/2 Notify = audio/audiopool0/2 {
}} ObservedEvents = 33 {
aass/audcomp
}
}
}
}
(4) Subtract the ephemeral from the context, requesting that no statistics be sent.
Request (GWC to UAS) Response (media server to GWC)
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Subtract=te/tepool0/0{ Subtract = te/tepool0/0
Audit{} }
}}} }
(5) Subtract the audio termination from the context, thus ending the call.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Modify=audio/audiopool0/2{ Modify = audio/audiopool0/2,
Media{ Subtract = audio/audiopool0/2
LocalControl{Mode=Inactive} }
}}, }
Subtract=audio/audiopool0/2{
Audit{}
}}}

D3.6.3.2 Commands Used to Set Up Conferences

! ContextAttr package for the set of conference terminations (DSP ports) that are to
provide connectivity for the conference. This command will create a new context at
the media server. The media server response to the Add command will provide the
context ID and confirm that the correct number of ports have been reserved.
! Add command for each call party who is to participate in the conference. Each Add
command adds a new ephemeral termination to the conference context. The media
server response to each Add command will provide a transport address (IP address
and UDP port) for the logical media server termination of the audio stream to/from
the media gateway serving the corresponding call party.
! Modify command for each ephemeral connection to a conference participant,
providing SDP session information about that connection.
Table 26: Example H.248 message formats for conferencing

(1) Reserve a context for this conference, with a size of 3. ContextAttr is a Nortel proprietary addition to
MEGACO 1.0, which has already been discussed for addition to the next version of the standard.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
ContextAttr{ ContextAttr {
ctxr/type=conf,ctxr/size=3,ctxr/res=reserve ctxr/type = conf,
}}} ctxr/size = 3,
ctxr/res = reserve
}
}
}
(2) Add ephemeral termination for conference participant 1 to the reserved context.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Media{ Media {
LocalControl{Mode=SendReceive}, Local {
Local{ v=0
v=0 c=IN IP4 47.174.66.103
a=ptime:10 }
}}}}} }
}
}
}
Request as for conferee 1, but with Transaction=6.
Acknowledgement as for conferee 1, but with Reply = 6 and m=audio 30236 RTP/AVP 0.
Request as for conferee 1, but with Transaction=7.
Acknowledgement as for conferee 1, but with Reply = 7 and m=audio 30234 RTP/AVP 0.


(5) Provide remote SDP for first ephemeral.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Modify=te/tepool0/0{ Modify = te/tepool0/0
Media{ }
LocalControl{Mode=SendReceive}, }
Remote{
v=0
c=IN IP4 47.174.67.5
a=ptime:10
}}}}}
(6) Provide remote SDP for second ephemeral.
Request as for first ephemeral, but with
Transaction=9
Modify=te/tepool0/1
m=audio 1090 RTP/AVP 0.
Acknowledgement as for first ephemeral, but with Reply = 9 and Modify=te/tepool0/1.
(7) Provide remote SDP for third ephemeral.
Request as for first ephemeral, but with
Transaction=10
Modify=te/tepool0/2
m=audio 1086 RTP/AVP 0.
Acknowledgement as for first ephemeral, but with Reply = 10 and Modify=te/tepool0/2.
(8) Optionally, request ringback on the third ephemeral. This would be done if ringing is still being applied tyo
the third participant in the conference. Ringback is applied into the context, mixed and played out to the
first and second participants. The media server indicates signal start.
The GWC subsequently sends a request to stop the ringback signal.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Signals{ }
bcg/brt{btd="internal"} }
}}}}
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Signals }
}}} }
(9) At the end of the conference, subtract the third ephemeral from the conference.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
Audit{} }
}}} }
(10) Subtract the second ephemeral from the conference.
Request as for third ephemeral, but with Transaction=14 and Subtract=te/tepool0/1.
Acknowledgement as for third ephemeral, but with Reply = 14 and Subtract = te/tepool0/1.


(11) Subtract the first leg (last remaining leg) from the conference and unreserve the conference resources.
Note: The unreserve could occur with any of the subtracts or even in a command by itself.
Acknowledgement from media server indicates that the context is now deleted since there are no more
terminations in the context and it has been unreserved.
MEGACO/1 [47.174.66.20]:2944 MEGACO/1 [47.174.66.102]:2427
ContextAttr{ctxr/res=release}, ContextAttr {
Subtract=te/tepool0/0{ ctxr/res = release
Audit{} },
}}} Subtract = te/tepool0/0
}
}
D3.6.3.3 Commands Used for Lawful Interception

See Figure 159 on page 699 for an illustration of the network configuration used to
support Lawful Interception.
! ContextAttr package for the set of conference terminations (DSP ports) that are to
be used to deliver call content to the LEA from the call being monitored. This
command will create a new context at the media server. The media server response
to the Add command will provide the context ID and confirm that the correct
number of ports have been reserved.
! Add command for the LI target. The media server response to the Add command
will provide a transport address (IP address and UDP port) for the logical media
server termination of the audio stream to/from the media gateway serving the LI
target.
! Add command for the call party connected to the LI target. This Add command will
add a new termination to the media server context created for the LI target. The
media server response to the Add command will provide a transport address for the
logical media server termination of the audio stream to/from the media gateway
serving the corresponding call party.
! Two Add commands for the LEA (Law Enforcement Agency) media gateway.
These Add commands create logical media server terminations for two outgoing
audio streams, one replicating the audio stream from the LI target and one
replicating the audio stream to the LI target. The media server response to each Add
command will provide a transport address for the logical media server termination
of the replicated audio stream.
Note: With effect from ISN06, CS2000 supports delivery of call content
(speech/data) via a single CC connection, instead of using a separate CC link for
each direction of voice/data transmission.
! Modify commands for the ephemeral connections to the LI conference, ensuring
that SDP session information for the monitored call has been synchronised.
! Topology commands for the ephemeral connections to the LI conference, ensuring
that a two-way connection exists between the call parties and that two one-way
connections have been set up to the LEA.

Table 27: Example H.248 message formats for Lawful Interception (LI)
(1) GWC tells media server to reserve a context for an LI call.
media server replies that the context has been reserved.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
ContextAttr{ ContextAttr {
ctxr/type=bct, ctxr/type = bct,
ctxr/size=4, ctxr/size = 4,
ctxr/res=reserve ctxr/res = reserve
}}} }
}
}
(2) GWC tells media server to add an ephemeral connection for the LI subject and proposes local SDP.
media server replies that an ephemeral connection has been added for the LI subject.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
TP{$,*,IS}, Add = te/tepool0/0 {
Add=${ Media {
Media{O{MO=SR}, Local {
L{ v=0
v=0 c=IN IP4 47.171.164.211
a=ptime:10 m=image 32001 udptl t38
}}}}} a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
}
}
}
}
}
(3) GWC asks media server to add an ephemeral connection for the LI associate, proposes local SDP, and
supplies LI subjects SDP.
media server replies that an ephemeral connection has been added for the associate.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
TP{$,*,IS}, Add = te/tepool0/1 {
Add=${ Media {
Media{O{MO=SR}, Local {
L{v=0 v=0
c=IN IP4 $ c=IN IP4 47.171.164.211
m=audio $ RTP/AVP 0 m=audio 30002 RTP/AVP 0
a=ptime:10 a=ptime:10
}, }
R{v=0 }
c=IN IP4 47.171.164.190 }
m=audio 20002 RTP/AVP 0 }
a=ptime:10 }
}}}}}

(4) GWC tells the media server to modify theSDP of the LI subjects termination with the associates SDP.
media server replies that the modification has been successful.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Media{O{MO=SR}, }
R{ }
v=0
c=IN IP4 47.171.164.190
a=ptime:10
}}}}}
(5) GWC asks the media server to change the topology between the subject's ephemeral connection and
the associate's ephemeral connection to both-way, establishing the speech path.
The media server replies that the topology has been modified.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
TP{ Topology {
te/tepool0/0, te/tepool0/0,
BW Bothway
}}} }
}
}
(6) GWC tells media server to add first LEA ephemeral connection LEA-1 to the context.
media server replies that the ephemeral connection has been added.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Context=1{TP{$,*,IS}, Context = 1 {
Media{O{MO=SR}, Media {
L{ Local {
v=0 v=0
c=IN IP4 $ c=IN IP4 47.171.164.211
m=audio $ RTP/AVP 0 m=audio 30004 RTP/AVP 0
a=ptime:10 a=ptime:20
}}}}} m=image 32003 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
}
}
}
}
}
(7) GWC tells media server to add second LEA ephemeral connection LEA-2 to the context.
Request as for LEA-1, but with Transaction=3006.
media server replies that the ephemeral connection has been added.
Acknowledgement as for LEA-2, but with
Reply = 3006
Add = te/tepool0/3
m=audio 30006 and m=image 32004

(8) GWC modifies ephemeral connection LEA-1 with the remote SDP from the LEA.
The media server replies that the Modify was successful.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Media{O{MO=SR}, }
R{ }
v=0
c=IN IP4 47.171.164.190
a=ptime:10
}}}}}
(9) GWC tells the media server to set the topology of the associate and LEA-1 to oneway, thereby
establishing the monitoring of the associate.
media server replies that the topology has been modified.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
TP{ Topology {
OW Oneway
}}} }
}
}
(10) GWC modifies ephemeral connection LEA-2 with the remote SDP from the LEA.
The media server replies that the Modify was successful.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Media{O{MO=SR}, }
R{ }
v=0
c=IN IP4 47.171.164.190
a=ptime:10
}}}}}
(11) GWC tells the media server to set the topology of the subject and LEA-2 to oneway, thereby establishing
the monitoring of the subject.
media server replies that the topology has been modified.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
TP{ Topology {
OW Oneway
}}} }
}
}

(12) When monitoring is over, GWC tells the media server to subtract each ephemeral connection in turn,
to beginning with subjects ephemeral connection (as shown in example).
(15) In each case, the media server replies that the Subtract was successful.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
AT{} }
}}} }
(16) GWC tells the media server to release the context.
The media server replies that the context has been released.
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
CT{ ContextAttr {
ctxr/res=release ctxr/res = release
}}} }
}
}

D3.6.4 H.248 Support for CLASS

H.248 is used to support CLASS functionality for V5.2 lines. This section provides an
overview. See A89007007 for details.
Modem functionality is used to send CLASS party information to the user terminal. This
can be done while the CLASS subscriber is on-hook, e.g. to download calling party
information when a new call is being set up (DDN, CND, CNAMD and CMWI features).
It can also be done while the CLASS subscriber is off-hook, e.g. to download calling
party information for a new incoming call when there is already a call in progress
(SCWID feature).
ETSI EN 300 659 defines procedures for both on-hook data transmission and off-hook
data transmission. Data download for on-hook data transmission may be associated with
ringing (e.g. using the first long silent interval in the ringing cadence) or not associated
with ringing. For both on-hook and off-hook data transmission, the maximum payload
that can be downloaded is 80 octets of data.
For CS2000 V5.2 lines, V.23 modem capabilities are provided by MG functionality in the
PVG, in response to H.248 commands sent by the CS2000 GWC. Because line signals are
handled by the V5.2 AN, the PVG is not aware of whether the analogue line state is
on-hook or off-hook. The GWC must therefore indicate to the PVG whether on-hook or
off-hook data transmission is required as well as providing the data to be downloaded.
Data download is initiated by a H.248 Modify endpoint command sent from the GWC to
the PVG, and its completion is indicated by a Notify command sent from the PVG to the
GWC. For on-hook data transmission, the Modify command includes an andisp/data
(analogue display data) parameter. The Modify command for off-hook data transmission
includes an andisp/dwa (analogue display with alerting) parameter.
For off-hook data transmssion, the Modify command requesting data download to the
terminating subscriber follows the H.248 Add and Modify commands used to set up a
two-way connection across the terminating PVG, and precedes the V5UA SIGNAL CR
command used to specify the ringing cadence to be used. Command format examples for
calling party information delivery are provided in Table 28 on page 279.
See A89007007 for information about the command formats and message flows used to
support other CLASS services.

Table 28: H.248 message formats for CLASS on-hook data transmission
Description / format
Send calling line information without DT-AS generation and with signal completion notification
MEGACO/1 [47.174.66.80]:2944 MEGACO/1 [47.166.34.20]:2944
Signals {andisp/data } }
{db=802001083035313831363135020A3931393535
353030303007084A6F686E20446F65D8, [1]
tas=nt,
NotifyCompletion={TimeOut}}
},
Events=1234{g/sc}
} } }
Signal completion notification
MEGACO/1 [47.166.34.20]:2944 MEGACO/1 [47.174.66.80]:2944
ObservedEvents=1234{ } }
20020318T10010000:g/sc
{SigID=andisp/data,Meth=TO}
} } } }
[1] The db parameter shall be coded as a hex string. The maximum length is 80 octets, comprising:
- Message type (= Call Setup)
- Message length
- Presentation Layer Message (Date&Time, Calling Line Identity, ..)
- Checksum
The tas parameter shall be set to nt (i.e. no Dual Tone Alerting Signal shall be sent).

Chapter D4 ASPEN
D4.1 Purpose
ASPEN is a Nortel-defined ASCII protocol based on the MGCP (Media Gateway Control
Protocol) IETF protocol defined in RFC3435 and described in Chapter D8: MGCP, and
also on SGCP. Like MGCP, ASPEN is designed to support signalling between GWCs
and the media gateways they control. It is a superset of MGCP, supporting essentially the
same range of connection control commands as MGCP, but also a number of additional
proprietary commands defined to provide extra maintenance functionality.
In releases prior to ISN07, ASPEN was used in CS2000 solutions primarily for
communication between GWCs and PVG trunk media gateways supporting CCS7 and
PRI access to the packet network. In this role, ASPEN has now been superseded by the
standard H.248 protocol jointly defined by the IETF and ITU, which is described in
Chapter D3: H.248. H.248 is based on a more flexible functional model than ASPEN,
which is designed to provide better support for multimedia and conference capabilities.
Use of ASPEN in support of CCS7 and PRI access is still supported for existing
deployments. In addition, ASPEN is currently the only protocol that has been verified for
control of trunk gateways supporting QSIG access.
The standard ASPEN version for ISN07 is ASPEN v2.1, as defined in the ASPEN
Protocol Specification, Version 2.1: Draft 8, October 2000.
Note: To complement ASPEN, SDP session descriptions are conveyed in-line with
ASPEN commands and responses. See section D1.3 on page 239 for more information.

ASPEN Packet Telephony Protocols Communication Server Capabilities
D4.2 Network Role

The main ASPEN commands used for call setup and clearing are sent by a GWC to a
media gateway. Each command is acknowledged by the media gateway. They are:
! CRCX (create connection)
! MDCX (modify connection)
! DLCX (delete connection)
Call setup commands and their acknowledgements can include SDP session descriptions
that provide address and media stream information for the call.
Since UDP may be subject to packet loss, an ASPEN application layer timer is started
when each command is sent, and the command will be resent if the timer expires without
an acknowledgement being received.
GWCs and trunk media gateways are separately provisioned with the address information
they need to communicate with each other via ASPEN. For each media gateway
controlled by a GWC, GWC datafill specifies the gateway IP address, UDP port and trunk
or line endpoints available (identified via physical terminations and timeslots). Similarly,
media gateway datafill (as defined via the media gateway EM) specifies the IP address
and UDP port of the controlling GWC.
ASPEN commands identify calls by means of GWC-assigned callIDs that are unique
across the entire network of media gateways.
Figure 70 illustrates the role of the ASPEN protocol in the CS2000 network architecture.
CS2000 CS2000
Trunk SIP-T and SIP-T and Trunk
Gateway VRDN VRDN Gateway
Controller GWCs; GWCs; Controller
(GWC) (GWC)
Ingress Egress Ingress Egress
ASPEN commands, ASPEN commands,

e.g. CRCX, e.g. CRCX,
some with in-line some with in-line
SDP service SDP service
descriptions descriptions
Acknow- Acknow-
ledgements ledgements
Media Media
gateway gateway
(PVG) (PVG)
Figure 70: Network role of ASPEN
Note: For a media gateway supporting Q.931/QSIG access, ASPEN is not the only
packet telephony protocol used between the GWC and the media gateway. ASPEN
provides device / media control functionality, but PRI/QSIG call control signalling is
conveyed using IUA, as described in Chapter D10: IUA.

Communication Server Capabilities Packet Telephony Protocols ASPEN

ASPEN comprises two types of command:
! Connection control commands
! Maintenance commands
The following table lists the commands available and summarises their functions.
Table 29: ASPEN commands supported by CS2000

Name Meaning Sent by Usage
Connection control commands
Sent to originating media gateway when CS2000
receives an incoming IAM or equivalent (e.g.
PRI/QSIG SETUP), to set up a receive-only bearer
connection and associate it with a specified media
Originating GWC /
gateway endpoint.
media gateway Also specifies callID used in all subsequent
connection control messages.
Acknowledged by 200 message with connection ID
and SDP session description for selected port.
CRCX Create GWC Sent to terminating media gateway selected via
connection translations and routing (of original incoming IAM or
equivalent, or of IAM encapsulated in SIP-T), to set
up a send-receive bearer connection and associate
it with a specified media gateway endpoint.
Terminating GWC / Includes SDP session description, as provided in
media gateway 200 acknowledgement of CRCX sent to originating
media gateway.
Acknowledged by 200 message with connection ID
and SDP session description including destination IP
or ATM address.
Sent to media gateway to modify an existing connection, e.g. to initiate a
change from recvonly to sendrecv. Examples:
[1] Sent to the media gateway that received the first CRCX for a call
when the second CRCX has been acknowledged by the other media
gateway, to set up a half-duplex bearer connection between the two
gateway endpoints.
Includes SDP session description with destination IP address.
Modify
MDCX connection GWC Acknowledged by 200 message with no parameters.
[2] Sent to originating and terminating media gateways when CS2000
receives a backward ACM or equivalent (e.g. PRI/QSIG ALERTING),
to set up a full duplex bearer connection between the two gateway
endpoints.
Acknowledged by 200 message with no parameters.
Note: No ASPEN command is sent when the CS2000 subsequently
receives an ANM or equivalent (e.g. PRI/QSIG CONNECT).
Sent to originating and terminating media gateways when CS2000
receives a REL message, to take down the bearer connection between the
Delete
DLCX connection GWC two gateway endpoints.
Acknowledged by 250 message with data about completed call, e.g.
packets/octets sent, packets/octets received, packets lost/discarded.
Sent by a media gateway when an endpoint connection is lost, e.g.
Delete Media because of carrier failure.
DRCX connection
gateway Causes host GWC to send a DLCX, and to request the far-end GWC to
request
send a DLCX to the other media gateway involved in the call.
Sent to a media gateway to request the playing of a tone over a specified
TDM-side circuit.
Request Can also be used to request a media gateway to initiate monitoring for the
RQNT notification GWC occurrence of specified endpoint events, e.g. receipt of dialled digits.
Receipt of message acknowledged by 200 message with no parameters.
Detection of event reported by media gateway via NTFY command.

Table 29: ASPEN commands supported by CS2000

Sent by a media gateway to report the detection of a monitored event
Media specified in a RQNT command. (Not sent when RQNT is used to specify
NTFY Notify
gateway the playing of a tone.)
Acknowledgements
Media
200 Success
gateway The requested transaction has been executed normally.
or GWC
Media
250 Success The connection has been deleted as requested.
gateway
Temporary Media
400-499 problem gateway The transaction could not be executed because of a transient error.
Permanent Media The transaction could not be executed because of a permanent error, e.g.
500-599
problem gateway endpoint unknown, protocol error.
Maintenance commands
Sent from a GWC to each of its media gateways when the GWC is brought
SVID Server GWC into service.
identification Sent from a GWC to a specific media gateway to restart it after a failure
(e.g. no response to BEAT messages).
Sent from an GWC to a media gateway if no messages have been
BEAT Heartbeat GWC received in a specified time period; acknowledgement indicates the
gateway is still in service.
Two uses:
- Sent from a media gateway in response to a STRT or SWCT,
Media following the STRT/SWCT acknowledgement, to indicate the status of
CHNG Change gateway the gateways endpoints.
- Independently sent from media gateway to GWC to report any
change in gateway endpoint status.
Resource
RINF information GWC Sent by GWC to query media gateway endpoint status
request
Notification Media
NINF of resource
gateway Sent by media gateway to report endpoint status
information
Restart in Media Sent by media gateway to report a gateway restart
RSIP
progress gateway
Notes on command usage:

! For calls served by two media gateways on the same CS2000, the first CRCX for a
call is as likely to be sent to the terminating gateway as to the originating gateway.
This is determined on the basis of which two gateways are involved. Every media
gateway is set up such that it will receive the first CRCX for calls involving 50% of
the other media gateways on the CS2000, but the other gateway will receive the first
CRCX if it is one of the remaining 50%. This configuration improves the caching
efficiency of connection-oriented bearer paths, and balances messaging and
workload between all the media gateways on the CS2000.
! The CRCX and MDCX commands are used by CS2000 to control the application
of echo cancellation to outgoing TDM-side CCS7 trunk circuits, as described in
section E2.2.4.1 on page 379.
! The RQNT command is used by CS2000 to control the generation and looping back
of CCS7 continuity test tones, as described in section E2.2.4.2 on page 380.

D4.4 Parameters
ASPEN command parameters are specified one per line, each line beginning with a
single-character parameter identifier. The most important parameters supported are listed
and briefly described below.
C Call identifier
Uniquely identifies a call (or session) within a network of media gateways.
Assigned by GWC in CRCX command used to initiate call setup.
I Connection identifier
Identifies a connection within the context of an endpoint and a call (call identifier
must be provided if connection identifier is provided). Assigned by media gateway
when connection is created in response to CRCX command, and notified to GWC
in 200 response to CRCX.
Z Endpoint identifier
Identifies an endpoint by means of an address based on the gateway / carrier /
channel hierarchy. For E1 carriers, the format is:
<media gateway name>.E1_<card slot><card port>.<timeslot>
An example is PVG99.E1_403.27, which would identify timeslot 27 on the E1
carrier terminated in slot 4, port 3 on gateway PVG99 (the port number is padded
with a 0 but the card number is not).
M Connection mode
Specifies the mode of operation of a connection. Specified by GWC in initial CRCX
command and subsequent MDCX commands. Possible values:
sendonly Media gateway should only send packets
recvonly Media gateway should only receive packets
sendrecv Media gateway can send and receive packets
inactive Media gateway should neither send nor receive packets
loopback Media gateway should place the circuit in loop-back mode
data Media gateway should use circuit for network access for data
tdmdata Media gateway should use circuit for TDM data (special value for
providing hairpinned clear channel between two TDM-side
endpoints served by same media gateway)
L Local connection options
Specifies the required characteristics of a packet network bearer connection.
Specified by GWC in initial CRCX command (can subsequently be modified by
MDCX commands). Characteristics that can be specified:
p packetisation interval (5ms, 10ms or 20ms)
a compression algorithm, e.g. G.711a (A-law) or x-ccd (clear channel data)
b bandwidth in kb/s
e echo cancellation on/off (off for data calls)
s silence suppression on/off (off for data calls)
P Connection parameters
Included in a DLCX acknowledgement or a DRCX command to provide
information about the concluded call, e.g. packets/octets sent, packets/octets
received, packets lost/discarded.
E Reason code
Included in DRCX command to indicate the cause of a gateway-initiated
disconnection.

R Requested events
Included in RQNT command to specify which event(s) the media gateway should
tell the GWC about.
O Observed events
Included in NTFY command to indicate which monitored events have occurred.
S Signal requests
Included in RQNT command to specify which signal(s) the media gateway should
tell the GWC about.
X Request identifier
Used for correlation between requested events and resulting event notifications.
D Digit map
Specifies a dialling plan to be used in collecting and reporting DTMF in-band digits
detected at a TDM-side endpoint, primarily to distinguish different types of call.
Included in RQNT command to complement Requested Events parameter. See
section D7.4.3 on page 314 for a discussion of digit map usage; this is for the NCS
protocol, but is equally applicable to ASPEN.
Note: When an ASPEN command such as CRCX, MDCX or 200 (acknowledgment)
includes an SDP session description, the SDP command lines, whose format is similar to
that of ASPEN parameter lines, are provided after the final ASPEN parameter line. See
section D1.3 on page 239 for more information. SDP command lines are not explicitly
distinguished from ASPEN parameter lines.
D4.5 Command Syntax

A complete ASPEN command consists of a main command line followed by a number of
parameter lines. A main command line has the format:
<command> <trID> <protocol version>
where
! <command> is either one of CRCX, MDCX or DLCX, or an acknowledgement code
such as 200 (normal transaction completion).
! <trID> is a transaction ID used to correlate a command and its acknowledgement.
! <protocol version> is ASPEN 2.1.
The standard ASPEN version for ISN07 is ASPEN v2.1, supported by the PVG
software load PCR2.3. Prior to general availability of ASPEN v2.1, ASPEN v2.06
was used for some initial deployments, and is still in use; ASPEN v2.06 is supported
by the PCR1.3 software load.
Each parameter line that follows a main command line has the format:
<X>: <parameter(s)>
Any SDP command lines that follow the final ASPEN parameter line have the format:
<x>=<parameter(s)>

D4.6 Examples
D4.6.1 Call Setup Commands
! Initial CRCX
CRCX 2 ASPEN 2.1
C: callid1
Z: mg-o.E1_1.1
M: recvonly
L: p: 10, a:G.726, p:20, a:G.729
The LocalConnectionOptions parameter presents a list of codec / packetisation rate
pairs to the media gateway in order of preference.
! 200 Acknowledgement of initial CRCX
200 2
I: C1
v=0
c=IN IP4 47.96.0.1
a=ptime:10
a=ptime:20
The media gateway examines the LocalConnectionOptions list and returns a media
description line for each codec / packetisation rate pair that it can support. Where
multiple packetisation periods can be used, an a=ptime line is included for each
one.
Note: Payload types are based on the definitions provided by the IETF's AVT
(Audio / Video Transport) working group. Payload type 2 denotes G.726 and
payload type 18 denotes G.729.
! Second CRCX (reflecting capabilities supported by first media gateway)
CRCX 4 ASPEN 2.1
C: callid1
Z: mg-t.E1_1.2
M: sendrecv
v=0
c=IN IP4 47.96.0.1
a=ptime:10
a=ptime:20
! 200 acknowledgement of second CRCX
200 4
I: C2
v=0
c=IN IP4 47.96.121.1
a=ptime:10
The second media gateway returns the first listed media description that it can
support (this is what will be used for the call).

! First MDCX (to first media gateway, when CRCX to second media gateway has
been acknowledged, setting up a connection with the agreed media characteristics)
MDCX 5 ASPEN 2.1
C: callid1
I: c1
Z: mg-o.E1_1.1
M: recvonly
v=0
c=IN IP4 47.96.121.1
a=ptime:10
! Second MDCX (to both media gateways, on receipt of ACM or CONNECT, to
establish a full-duplex connection)
MDCX 6 ASPEN 2.1
C: callid1
I: c1
Z: mg-o.E1_1.1
M: sendrecv
MDCX 7 ASPEN 2.1
C: callid1
I: c1
Z: mg-t.E1_1.2
M: sendrecv
D4.6.2 Call Clearing Commands

! DLCX
DLCX 8 ASPEN 2.1
Z: mg-o.E1_1.1
C: callid1
I: C1
! 250 Acknowledgement of DLCX (with statistics for completed call)
250 8 ASPEN 2.1
P: PS=50, OS=650, PR=78, OR=4599, PL=10, JI=27, LA=40

Chapter D5 H.323
D5.1 Purpose
implementation of multimedia services supporting the integration of voice, video and data
applications. It should be regarded as a framework or architecture rather then a protocol
in its own right, because it actually comprises a number of different protocols.
The underlying control protocol in the H.323 architecture is H.225, which provides
esentially the same range of call control messages as those defined in Q.931. More
importantly, H.225 allows other types of H.323 signalling to be conveyed in order to
support enhanced capabilities, as follows:
! H.225 defines RAS (Registration, Admission and Status) messages and procedures
for controlling access to the network. These allow H.323 endpoints to discover and
register with a H.323 gatekeeper, to provide information about their capabilities,
and to request the allocation of appropriate amounts of bandwidth.
! H.245 defines messages and procedures to be used in setting up and taking down
logical channels within the context of a H.225 call, e.g. an additional video or data
channel for the exchange of information. It allows endpoints to determine their
master/slave roles, to exchange information about their transmit and receive
capabilities, and to open and close end-to-end logical channels with characteristics
appropriate for the information being exchanged. Like H.450-defined data, H.245
signalling is tunnelled over H.323 in UUI IEs in H.225 call control messages.
! H.450 protocols are used to exchange signalling information for the control of
supplementary services. They provide service-related data definitions in ASN.1
format. H.450.1 defines a general-purpose signalling protocol that provides a
common basis for the definition of H.323 supplementary services. It is derived from
the generic functional protocol specified in ISO/IEC 11582 and used by QSIG, and
includes a mechanism for defining manufacturer-specific protocol extensions that
can be used to support proprietary services. H.450.1-defined data is tunnelled
(conveyed transparently) over H.323 interfaces in User-to-User Information (UUI)
IEs in H.225 call control messages.
Note: H.450.2 to H.450.13, which also belong to the H.323 architecture, provide
data definitions for use in supporting specific standardised supplementary services
such as Call Transfer, but these are not supported by CS2000 in ISN07.

Audio streams are encoded using protocols such as G.711 and G.729. Video streams are
encoded using H.261 and H.263. Audio and video payloads are both conveyed using RTP
over UDP transport, with RTCP being used for status and delivery monitoring. Data is
encoded using T.12x protocols and conveyed using X.224 over TCP transport.
Figure 71 provides a simplified view of the H.323 protocol architecture.
Video Audio
H.450.1 Call payload
Data H.245 Service- control payload
payload Logical protocols protocols
related (based RAS (H.26x)
protocols channel data on (G.7xx)
(T.12x) control definitions Q.931)
RTP RTCP
Media Delivery
packets monitoring
X.224 H.225
Media stream protocols
TCP (reliable transport) UDP (unreliable transport)
IP
Figure 71: H.323 protocol architecture
CS2000 supports H.323 Version 4, which was prepared by ITU-T Study Group 16
(2001-2004) and approved under the WTSA Resolution 1 procedure on 17 November
2000. Compliance with Version 4 of H.323 implies compliance with all of the mandatory
requirements of ITU Recommendation H.323 (2000), which references ITU-T Rec.
H.225.0 (2000) and H.245 (2000 or later). Version 4 products are identified by H.225.0
messages containing a protocolIdentifier = {itu-t (0) recommendation (0) h (8) 2250
version (0) 4} and H.245 messages containing a protocolIdentifier = {itu-t (0)
recommendation (0) h (8) 245 version (0) x}, where "x" is 7 or higher.
Basic H.323 capabilities supported by CS2000 include:
! H.225 RAS (Registration Admission and Status)
! H.225 fast start and slow start
! End-to-end H.245 support via tunnelling
! Gatekeeper-routed signalling
! G.711 a-law/-law (with PLC), G.729a
! Codec negotiation
! In-band DTMF support via RFC 2833
! DTMF out-of-band support (H.245 to in-band)
The software order code for H.323 functionality is CS2B0004.

D5.2 Network Role

D5.2.1 External H.323 Interface Presented by CS2000
In ISN07, CS2000 supports a wide variety of units via H.323. These are typically
deployed on customer premises in support of enterprise networks that support both voice
and data applications. Figure 72 illustrates CS2000 support for CPE units via H.323. See
Chapter B2: CS2000 Support for Media Gateways for further information about the
different units supported. See section D5.2.2 on page 291 for details of the signalling
involved in supporting H.323 and H.323 interoperability.
Full interworking via FT trunks

with H.323-controlled units
CS2000 served by other CS2000s
CS2000 Core
Basic interoperability via
non-FT trunks with units
served by other CS2000s
H.323 proxy H.323 Other
(GWC equivalent) proxy GWCs
Full interworking Basic

with other interoperability
H.323-controlled with non-H.323
H.323 signalling units served by units served by
(no bearer traffic) same CS2000 same CS2000
Business Communication
Proprietary Meridian 1 Call Server for
units IP PBX Manager Enterprise
(BCM) (CSE1000)
Cisco
access router / Westell
Third-party DPNSS gateway
units gatekeeper
(2600 / 3600 / (InterChange
7200) iQ203x)
Figure 72: The role of H.323 in a CS2000 network

D5.2.2 H.323 Interoperability and Tunnelling

The CS2000 Core does not support a H.323 call processing agent. Instead, H.323 support
is provided primaily by the H.323 proxy, which is a twin-card GWC unit that has been
configured to support H.323. The main H.323 functions provided by the H.323 proxy are:
! Support for H.225 RAS
H.225 defines RAS (Registration, Admission and Status) messages and procedures
for controlling access to the network. These allow H.323 endpoints to discover and
register with a H.323 gatekeeper, to provide information about their capabilities,
and to request the allocation of appropriate amounts of bandwidth. For details, see
section D5.3.1.1 on page 293.
RAS signalling is handled entirely by the H.323 proxy. Registration is controlled by
the state of the D-channel in the CS2000 Core.
! Support for H.225 call control
H.225 call control signalling makes use of essentially the same range of messages
as Q.931 (e.g. SETUP, ALERTING, CONNECT). It is discussed in section
D5.3.1.2 on page 295.
The H.323 proxy terminates H.225 call control signalling and maps incoming H.225
call control messages on to their QSIG equivalents to be conveyed to the CS2000
Core for call processing.
! Support for H.323 tunnelling (feature transparency)
Feature transparency involves the end-to-end tunnelling of H.323 information such
as H.450 service-related data and H.245 logical channel control messaging.
Services can thus be supported between H.323 endpoints even if the intermediate
nodes between those endpoints cannot understand the H.323 data being conveyed,
provided that they are capable of relaying it.
Information to be tunnelled is conveyed from a H.323 endpoint to the H.323 proxy
in a User-to-User Information IE in a H.225 call control message. The H.323 proxy
then encapsulates the content of the UUI IE in a Facility IE in a corresponding QSIG
call control message to be relayed to its destination.
Between two H.323 endpoints served by the same CS2000, the Facility IE with the
tunnelled information is conveyed from the QSIG interface serving the originating
H.323 proxy to the QSIG interface serving the terminating H.323 proxy.
Between two H.323 endpoints served by different CS2000s, the mechanism used to
convey tunnelled H.323 information is QSIG Feature Transparency (QFT). QFT
uses the ETSI ISUP V3 APM (Application Transport Mechanism) to encapsulate
and convey any service-related QSIG signalling that cannot be directly interworked
to ISUP. This enables services to be supported end-to-end even if the corresponding
signalling has to be routed via nodes that do not support QSIG functionality. QFT
across a packet backbone network involves two levels of encapsulation. First, QSIG
signalling is encapsulated in ETSI ISUP, and then ETSI ISUP is encapsulated in
SIP-T.
Note: In ISN07, feature transparency for DPNSS signalling tunnelled via H.323
and QSIG uses IBN7 DFT (DPNSS Feature Transparency) trunks rather than ETSI
ISUP V2+ QFT trunks for peer-to-peer connections. The mechanism used for
transparent carriage of information through transit nodes is the Network Transport
Parameter (NTP) defined in ANSI ISUP, which conveys the Nortel proprietary
Hybrid Network Information Parameter (HNIP). The NTP containing the HNIP can

be conveyed in ISUP call control messages, and can also be conveyed in an

unsolicited information message (INF) within a Pass-Along Message (PAM).
See section D5.3.3 on page 299 for information about H.450 signalling and its
encapsulation, and section D5.3.2 on page 298 for information about H.245.
Note: This CS2000 implementation of support for H.323 is intended for deployment in
international markets where QSIG is accepted as a standard VPN protocol. CS2000 also
supports an alternative H.323 implementation for deployment in North America, which is
based on mapping UUI IEs in H.225 messages on to UUI IEs in equivalent PRI messages.
Figure 73 illustrates the message mapping involved in H.323 tunnelling for intra-CS calls
and inter-CS calls using QFT or DFT trunks.
H.323 data to be H.323 data to be H.323 data to be

tunnelled end-to-end tunnelled end-to-end tunnelled end-to-end
(H.450 APDUs (H.450 APDUs (H.450 APDUs
and H.245 PDUs) and H.245 PDUs) and H.245 PDUs)
UUI IE Facility IE ETSI ISUP V2+ APP

in H.225 in QSIG or
message message IBN7 ISUP NTP(HNI)
CS2000
H.323 proxy H.323 proxy

CS2000
H.323 QSIG Core QSIG H.323
application interface interface application
H.323 H.323
CPE unit CPE unit
UUI IE Facility IE UUI IE

in H.225 in QSIG in H.225
message message message
H.323 data to be H.323 data to be H.323 data to be
tunnelled end-to-end tunnelled end-to-end tunnelled end-to-end
(H.450 APDUs (H.450 APDUs (H.450 APDUs
and H.245 PDUs) and H.245 PDUs) and H.245 PDUs)
Figure 73: Message mapping for H.323 tunnelling

D5.3 H.323 Characteristics

Sections D5.3.1 to D5.3.3 provide further information about each of the H.323 protocols
introduced in section D5.1 on page 288, including details of how specific protocol
capabilities are supported by the CS2000 international implementation of H.323.
D5.3.1 H.225 Protocol

The H.225 protocol specification defines two different types of signalling:
! H.225 RAS signalling, which allows H.323 endpoints to register with a H.323
gatekeeper and request the allocation of appropriate amounts of bandwidth.
Successful completion of RAS registration is a prerequisite for the use of H.225 call
control signaling. It is discussed in section D5.3.1.1.
! H.225 call control signalling, which makes use of essentially the same range of
messages as Q.931. It is discussed in section D5.3.1.2 on page 295.
D5.3.1.1 H.225 RAS Signalling

Registration, Admission and Status (RAS) is an essential preliminary for the setting up of
a H.323 call using H.225 call control signalling. The RAS channel is used to convey
messages used in the gatekeeper discovery and endpoint registration processes.
Gatekeeper discovery is the process whereby a H.323 endpoint determines the gatekeeper
with which it should be registered. The process may be manual or automatic.
With manual gatekeeper discovery, the endpoint is configured with the transport address
of its gatekeeper via datafill or an initialisation file, in which case the discovery process
involves no RAS messaging and is outside the scope of H.323.
With automatic gatekeeper discovery, the endpoint initiates the process by sending a
Gatekeeper Request (GRQ) message, asking "Who is my Gatekeeper?" to the well-known
Gatekeeper Discovery Multicast Address. One or more gatekeepers then respond with a
Gatekeeper Confirmation (GCF) message containing the transport address of the
gatekeeper's RAS channel.
Note: A H.323 unit supporting multiple endpoints must send a separate GRQ for each
one.
In the CS2000 implementation, H.323 gatekeeper functionality is provided by the H.323
proxy GWC.
Because RAS messages are transmitted on an unreliable channel (H.225 RAS over UDP),
timeouts and retry counts are used. An endpoint or gatekeeper that cannot respond to a
request within the specified timeout may use the Request in Progress (RIP) message to
indicate that it is still processing the request. An endpoint or gatekeeper receiving an RIP
can then reset its timeout timer and retry counter.

The information provided in GRQ and GCF messages is as follows:

! GatekeeperRequest (GRQ) message content
" rasAddress
The transport address of the originating H.323 endpoint.
" endpointType
Defines the capabilities of the originating endpoint, in particular:
# The supportedTunnelledProtocols field contains a prioritised list of
the tunnelled protocols that the endpoint can support, together with the
data rates supported for each protocol. the device supports.
# The callCapacity field indicates the endpoints maximum capacity and
currently available capacity for different types of call.
" gatekeeperIdentifier
Identifies the gatekeeper with which the endpoint wishes to register (a missing
or null string indicates that any available gatekeeper is acceptable).
" authenticationCapability
Indicates the authentication mechanisms suported by the endpoint.
! GatekeeperConfirm (GCF) message content
" rasAddress
The transport address of the H.323 gatekeeper
" authenticationMode
Indicates the authentication mechanism to be used (one of those supported by
the endpoint).
When a H.323 endpoint has discovered the transport address of the gatekeeper with which
it should be registered, it can proceed to register itself with that gatekeeper and request
admission to the backbone packet network. Table 30 lists and briefly describes the H.225
RAS messages used for these and other purposes.
Table 30: Important RAS messages

Message Function
RegistrationRequest Request from a terminal or gateway to register with a gatekeeper.
(RRQ) Gatekeeper either confirms or rejects (RCF or RRJ).
Request for access to packet network from terminal to gatekeeper.
AdmissionRequest (ARQ) Request may include indication of specific protocol to be tunnelled.
Gatekeeper either confirms or rejects (ACF or ARJ).
Request for changed bandwidth allocation, from terminal to
BandwidthRequest (BRQ) gatekeeper. Gatekeeper either confirms or rejects (BCF or BRJ).
DisengageRequest If sent from endpoint to gatekeeper, DRQ informs gatekeeper that

endpoint is being dropped; if sent from gatekeeper to endpoint, DRQ
(DRQ) forces call to be dropped.
InfoRequest (IRQ) Request for status information from gatekeeper to terminal.
InfoRequestResponse Response to IRQ. May be sent unsolicited by terminal to gatekeeper
(IRR) at predetermined intervals.
RAS timers and Request Recommended default timeout values for response to RAS
in Progress (RIP) messages and subsequent retry counts if response is not received.

D5.3.1.2 H.225 Call Control Signalling

H.225 call control signalling is based on Q.931. It uses a subset of of Q.931 message
types, all of which can include UUI IEs conveying encapsulated H.450 or H.245
signalling.
With the CS2000 implementation of H.323, the H.323 proxy GWC performs message
mapping between H.225 call control messages and equivalent QSIG messages. For H.323
tunnelling, this message mapping involves converting H.225 IEs conveying encapsulated
H.450 and H.245 signalling into QSIG Facility IEs conveying the same encapsulated
signalling unmodified.
Note: This CS2000 implementation of support for H.323 is intended for deployment in
international markets where QSIG is accepted as a standard VPN protocol. CS2000 also
supports an alternative H.323 implementation for deployment in North America, which is
based on mapping UUI IEs in H.225 messages on to UUI IEs in equivalent PRI messages.
Table 31 lists H.225 call messages and their QSIG equivalents, indicating for each QSIG
message whether it can include a Facility IE and therefore whether it can convey
encapsulated H.450 and H.245 signalling for H.323 tunnelling.
Table 31: H.225 call control messages and QSIG equivalents

H.323 message QSIG message
UUI IE Facility IE
Message Message
supported? supported?
Call establishment messages
SETUP Yes SETUP Yes
SETUP ACK Yes SETUP ACK No
INFORMATION Yes INFORMATION No
CALL PROCEEDING Yes CALL PROCEEDING No
ALERTING Yes ALERTING Yes
PROGRESS Yes PROGRESS Yes
CONNECT Yes CONNECT Yes
Not used CONNECT ACK No
Call clearing messages
Not used DISCONNECT Yes
Not used RELEASE Yes
RELEASE COMPLETE Yes RELEASE COMPLETE Yes
Miscellaneous messages
FACILITY Yes FACILITY Yes
NOTIFY Yes NOTIFY No
STATUS Yes STATUS No
STATUS ENQUIRY Yes STATUS ENQUIRY No
Note: H.323 employs a single-stage release mechanism, which consists of the reception
or sending of a RELEASE COMPLETE message without further acknowledgment. The
QSIG interface on the H.323 proxy generates or terminates the additional messages
required for the QSIG multi-stage release mechanism.

Figure 74 illustrates the messaging involved in H.323 call setup and clearing via the
H.323 proxy GWC.
H.225 signalling QSIG signalling

H.323 H.323 CS2000
CPE proxy Core
unit GWC
SETUPUUI SETUPFAC
SETUP ACK SETUP ACK

(Overlap
INFORMATION signalling INFORMATION
(1 or more) only) (1 or more)
CALL PROCEEDING CALL PROCEEDING
ALERTINGUUI ALERTINGFAC
CONNECTUUI CONNECTFAC
CONNECT ACK
Call in progress
UUI
RELEASE COMPLETE DISCONNECT
RELEASE
RELEASE COMPLETEFAC
Figure 74: Message mapping by the H.323 proxy GWC
Each H.323 entity must have at least one network address that uniquely identifies the
H.323 entity on the network. An endpoint may use different network addresses for
different channels within the same call. For each network address, each H.323 entity may
have several TSAP identifiers. These allow multiplexing of several channels sharing the
same network address.
An endpoint may tunnel a signalling protocol by including the
tunnelledSignallingMessage in a UUI IE in any H.225 call signalling message with
end-to-end significance. Signaslling should not be tunnelled in H.225 messages that are
not of end-to-end significance, such as CALL PROCEEDING, since the information may
not be received by the other end.
If an originating endpoint wishes call setup to proceed only if tunnelling is supported, it
should set the tunnellingRequired flag in the SETUP message. If an endpoint receives a
tunnelledSignallingMessage with the tunnellingRequired flag set in the SETUP
message and is not able to tunnel the protocol, it terminates the call by sending a
RELEASE COMPLETE message.
The tunnelled protocol information is included in the messageContent field and the
tunnelledProtocolID field identifies the protocol being tunnelled.
H.225 can be used to establish a call-independent signalling connection between H.323
endpoints. Tunnelling can be used in this case to provide bearer-independent signalling
for the tunnelled protocol; no H.245 control channel and no media channels are required.

D5.3.1.3 H.323 Tunnelling via H.225 User-to-User Information IEs

User information to be exchanged between H.323 endpoints is conveyed in the
User-to-User Information IE in appropriate H.225 call control messages, as described and
illustrated in section D5.3.1.2 on page 295. This UUI IE is based on the Q.931 definition
of the UUI IE, but incorporates some modifications and enhancements that are specific to
H.323, as explained in the remainder of this section.
Actual user-user information to be exchanged only between the involved terminals is
nested in the user-data field of the H323-UserInformation PDU. This is an ASN.1
structure that includes H.323 information as well as user data. The ASN.1 is encoded
using the aligned variant of the packed encoding rules as specified in ITU-T X.691.
The most important fields in the H323-UserInformation structure are:
! The h323-uu-pdu field of the H323-UserInformation structure contains the
following fields (note that not all fields are permitted in every H.225 message):
" h323-message-body
This field contains information specific to a particular Q.931 message.
" h4501SupplementaryService
This field carries a sequence of H4501SupplementaryService APDUs.
" h245Tunneling
This element is set to TRUE if tunnelling of H.245 messages is enabled.
Systems compliant with H.225.0 version 4 or higher shall set this element to
TRUE if the Fast Connect procedure is used to establish the call.
" h245Control
This field carries a sequence of tunnelled H.245 PDUs.
" callLinkage
The contents of this field are typically controlled by a call linkage service.
" tunnelledSignallingMessage
A tunnelled entire signalling message in its native format to support
additional end-to-end call control signalling. The tunnelledProtocolID field
identifies the protocol being tunnelled. The messageContent field is a
sequence of actual entire tunnelled messages in their native binary format; this
allows aggregation of tunnelled messages in one H.225 messsage. If the
tunnellingRequired field is set in the SETUP message, the call will proceed
only if tunnelling is supported.
" genericData
This field is a list of generic elements related to features that are defined
outside of the base H.225.0 specification. These parameters may be used, for
example, for tunnelling information transparently through H.225.0.
! The user-data field of the H323-UserInformation structure contains the following
fields, coded as defined in Q.931:
" protocol-discriminator
" user-information
Note: A H.323 UUI IE has a two-byte length field, i.e. it may be up to 65,535 bytes long,
while a QSIG Facility IE has a one-byte length field and can be no more than 255 bytes
long. If necessary, a H.323 UUI IE will be split and distributed between multiple QSIG
Facility IEs in the same QSIG message.

D5.3.2 H.245 Protocol

H.245 defines messages and procedures to be used in setting up and taking down logical
channels within the context of a H.225 call, e.g. an additional video or data channel for
the exchange of information. It allows endpoints to determine their master/slave roles, to
exchange information about their transmit and receive capabilities, and to open and close
end-to-end logical channels with characteristics appropriate for the information being
exchanged. Like H.450-defined data, H.245 PDUs are tunnelled over H.323 in UUI IEs
in H.225 call control messages, as described and illustrated in section D5.2.2 on page 291.
Each H.245 messages is categorised as a request, response, command or indication on the
basis of whether it requires a response, requests action or provides information:
! A Request message results in action and requires an immediate response.
! A Response message is the response to a Request message.
! A Command message results in action but requires no response.
! An Indication message provides information and requires no action or response.
H.245 messages are defined using ASN.1. They are grouped into a number of different
functional message sets. Table 32 provides brief descriptions of the most important
messages, which come from the Master-slave determination, terminal capability and
logical channel signalling message sets.
Table 32: Important H.245 messages

Message Function Possible replies
Master-Slave Determines which terminal is the master and which Acknowledge

Reject
Determination is the slave Release [1]
Commands the far-end terminal to indicate its
Send Terminal
transmit and receive capabilities by sending one or Terminal Capability
Capability Set more Terminal Capability Sets Set message(s)
Terminal Capability Contains information about a terminal's capability to Acknowledge

Reject
Set transmit and receive multimedia treams
Release [1]
Open Logical Opens a logical channel for transport of audiovisual Acknowledge
Reject
Channel and data information Confirm.
Close Logical
Closes a logical channel between two endpoints Acknowledge
Channel
Used by a receive terminal to request particular
Acknowledge
modes of transmission from a transmit terminal.
Request Mode General mode types include VideoMode, Reject
Release [1]
AudioMode, DataMode and Encryption Mode
Indicates the end of a H.245 session. After
End Session
transmission, the terminal will not send any more None
Command
H.245 messages.
[1] Used in the event of a timeout.

D5.3.3 H.450.1 Protocol

H.450 protocols are used to exchange signalling information for the control of
supplementary services. They provide service-related data definitions in ASN.1 format.
H.450 APDUs are tunnelled (conveyed transparently) between H.323 endpoints in UUI
IEs in H.225 call control messages, as described and illustrated in section D5.2.2 on page
291.
The H.450.1 specification defines a general-purpose signalling protocol that provides a
common basis for the definition of H.323 supplementary services. It is derived from the
generic functional protocol specified in ISO/IEC 11582 and used by QSIG, and includes
a mechanism for defining manufacturer-specific protocol extensions that can be used to
support proprietary services.
Note: H.450.2 to H.450.13 provide data definitions for use in supporting specific
standardised supplementary services such as Call Transfer, but these are not supported by
CS2000 in ISN07.
CS2000 can support the tunnelling of manufacturer-specific information carried in
H.450.1 supplementary service APDUs. Specifically, it can support the use of
manufacturer-specific operations defined by Westell for the tunnelling of DPNSS
signalling between Westell DPNSS gateways controlled by CS2000 via H.323.
The H.323 proxy GWC supports interworking between H.323 and QSIG. Between the
H.323 GWC and the CS2000 Core, QSIG messaging is used for call control. Because
H.225 and QSIG are both based on Q.931, H.225 messages can be mapped on to QSIG
equivalents. The H.450.1 APDUs containing DPNSS signalling are extracted from UUI
IEs in H.225 messages and encapsulated unmodified in Facility IEs in QSIG messages.
The CS2000 Core supports two types of interworking for DPNSS extracted from H.225
and encapulsated in QSIG:
! Direct interworking to DPNSS encapsulated in QSIG for other DPNSS PBXs
served by the same CS2000.
! Interworking to DPNSS Feature Transparency (DFT) trunks. A DFT trunk is an
IBN7 trunk that can convey encapsulated DPNSS signalling.
For further details, see Chapter E6: DPNSS Interface, and especially section E6.2.1 on
page 485.

Chapter D6 UniStim
D6.1 Purpose
UniStim is the protocol used by the CentrexIP Client Manager to communicate with
CentrexIP remote clients. As such clients are located on enterprise networks while the
CICM is located on the CS2000 CS LAN, UniStim signalling traverses the CS LAN, the
managed IP core network and enterprise networks, as shown in Figure 75 on page 301.
UniStim is a Nortel Networks protocol, but is available under licence to other equipment
vendors who wish to design and manufacture CentrexIP terminals that support
interoperability with Nortel Networks products such as CS2000. It is therefore capable of
supporting not only proprietary i200x Etherset terminals and PC-based soft clients, but
also compatible third-party terminals. It is formally defined in Nortel Interface
Specification (NIS) D201-1: UniStim Protocol Specification.
UniStim is a stimulus protocol whose command set enables a Network Intelligence (NI),
i.e. CICM, to control every aspect of the operation of a client Internet Terminal (IT).
To provide reliable transport over UDP, UniStim uses a simple Go-Back-N scheme to
provides a suitable Reliable UDP layer for UniStim. This is also defined in NIS
D201-1.The protocol stack used for UniStim signalling is therefore UniStim / RUDP /
UDP / IP.
RTP streams are used for voice transmission.
For further information about the CICM, see section B1.4.2 on page 55.
For further information about CentrexIP clients, see Chapter B4: CentrexIP Remote
Clients and the CentrexIP Client Manager (CICM).

UniStim Packet Telephony Protocols Communication Server Capabilities
D6.2 Network Role

UniStim signalling is used between the CentrexIP Client Manager (CICM) on the CS2000
CS LAN and the CentrexIP remote clients that it controls. As shown in Figure 75, it is one
of three types of signalling used by CS2000 to provide VoIP support for CentrexIP clients.
Within the CS LAN, P-phone signalling is used by the CS2000 Core to support call
processing for CentrexIP clients, and H.248 signalling is used between the CICM and the
GWC that controls it.
CS2000 Core CS2000 CS LAN
GWC GWC
for CICM for CICM
CentrexIP CentrexIP
Client Client
Manager H.248 P-Phone P-Phone H.248 Manager
(CICM) (CICM)
UniStim is one of
three types of
UniStim signalling used to UniStim
RUDP provide VoIP RUDP
UDP support for UDP
IP CentrexIP clients IP
IP core network
Firewall Firewall
Enterprise network Enterprise network
CentrexIP CentrexIP
Etherset Etherset
client CentrexIP client CentrexIP
(i200x): soft client (i200x): soft client
(m6350): (m6350):
Figure 75: Role of UniStim in supporting CentrexIP remote clients

Communication Server Capabilities Packet Telephony Protocols UniStim
D6.3 UniStim Characteristics

CentrexIP clients comprise a number of different functional element managers. Each
UniStim command is categorised on the basis of which of these element managers it
applies to, and of whether it is sent by the CICM or the client. The element managers
supported are:
! The Network Manager (see section D6.3.1) is responsible for configuring and
maintaining the network connections between the NI and the IT.
! The Audio Manager (see section D6.3.2 on page 303) controls the audio
configuration of the IT. It sets up voice paths, establish end-to-end voice
connections and handles tone configuration.
! The Key/Indicator Manager (see section D6.3.3 on page 305) is responsible for the
IT keys and indicators. It sets LEDs and icons, reacts to key depressions and detects
on-hook/off-hook.
! The Display Manager (see section D6.3.4 on page 305) is responsible for the
presentation of information sent by the NI, which means that the NI does not have
to know where information is physically presented or what language is used.
! The Broadcast Manager (see section D6.3.5 on page 306) is responsible for such
things as icon, character table and time/date downloading for both the IT and any
attached accessories.
! The Basic Manager (see section D6.3.6 on page 306) handles IT maintenance
functions such as self-testing.
D6.3.1 The Network Manager

The Network Manager is responsible for configuring and maintaining the network
connections between the NI and the IT.
! The most important CICM-to-client commands that apply to the Network Manager
are:
" Soft Reset
" Hard Reset
" Download Server Information (server ID, IP address and UDP port)
" Set RTCP Source Description Item (endpointID, name, phone number and
location)
" Transport Reliability Layer Parameters Download
" QoS Configuration
" Query Network Configuration Element (requests Network Configuration
Element Report from client)
" Query Network Manager (requests some or all of Sanity OK, Manager ID,
Manager Attributes, Manager Diagnostics, Manager Options or Server
Information from client)
" Download Software Upgrade

! The most important client-to-CICM commands that apply to the Network Manager
are:
" Soft Reset Ack (sent by client in response to Soft Reset)
" Resume Connection With Server (unsolicited command sent by client after
successful power-up or soft reset, to inform the CICM that it is ready to accept
commands)
" Suspend Connection With Server
" Network Configuration Element Report sent in response to Query Network
Configuration Element from CICM
" Some or all of Sanity OK, Manager ID, Manager Attributes, Manager
Diagnostics, Manager Options or Server Information sent in response to
Query Network Manager from CICM
D6.3.2 The Audio Manager

The Audio Manager controls the audio configuration of the IT. It sets up voice paths,
establishes end-to-end voice connections and handles tone configuration.
! The most important CICM-to-client commands that apply to the Audio Manager
are:
" Resolve Port Mapping
This command initiates a command sequence that provides the CICM with
information about the address mapping performed by the NAT device at the
edge of the edge of the enterprise address domain to which the CentrexIP
client belongs. This information will eventually be used in an Open Audio
Stream command.
The Resolve Port Mapping command provides the CentrexIP client with the
IP address and port of the far-end originating node, i.e. the CICM, and causes
the client to send a Port Mapping Discovery command to that far-end address.
The far-end address is provided in the body of the command to allow for the
possibility that the source IP address in the IP packet header may be modified
as the packet traverses the NAT device.
" Port Mapping Discovery Ack
This command is sent as part of a command sequence initiated by a Resolve
Port Mapping command, the aim of which is to provide the CICM with
information about the address mapping performed by the NAT device at the
edge of the edge of the CentrexIP clients address domain.
The Port Mapping Discovery Ack command informs the CentrexIP client of
the NAT device IP address and port via which the CICM is communicating
with the client. This information can then be included in the Resolve Port
Mapping Ack command sent by the client to conclude the RPM-initiated
sequence used by the CICM to find out about NAT address mapping.
" Open / Close Audio Stream
Opening an audio stream sets up a full- or half-duplex end-to-end RTP voice
session between the terminal and a remote endpoint. Information provided:
# Codec type
# Far-end IP address
# Local RTP/RTCP ports
# Remote RTP/RTCP ports

" Connect Transducer (establish connection betwen open audio stream and
local equipment: handset / headset / handsfree / all)
" Commands for configuring and controlling transducer-based tones (alerting /
pager / special tone):
# Tone configuration
# Tone cadence download
# Tone volume level
# Tone on / off
" Commands for configuring and controlling stream-based tones (to replace or
be added to an audio stream):
# Tone frequency component list download (up to four frequencies in list)
# Tone cadence download
# Tone on / off
" Commands for controlling Rx volume levels
" Mute / Unmute Audio Stream
" APB Download (an Audio Parameter Bank defines Tx/Rx audio
characteristics)
" Query RTCP Statistics / Session Descrption Information
" Query Audio Stream Status
" Query Audio Manager
! The most important client-to-CICM commands that apply to the Audio Manager
are:
" Port Mapping Discovery
This command is sent as part of a command sequence initiated by a Resolve
Port Mapping command from the CICM, the aim of which is to provide the
CICM with information about the address mapping performed by the NAT
device at the edge of the edge of the CentrexIP clients address domain.
The client sends the Port Mapping Discovery command to the far-end address
provided in the Resolve Port Mapping command, i.e. the CICM. The
command provides the CICM with the IP address and port of the originating
node, i.e. the CentrexIP client, and causes the CICM to send a Port Mapping
Discovery Ack command to that originating address. The clients address is
provided in the body of the command to allow for the possibility that the
source IP address in the IP packet header may be modified as the packet
traverses the NAT device.
" Resolve Port Mapping Ack
This command is sent to conclude a command sequence initiated by a Resolve
Port Mapping command from the CICM, the aim of which is to provide the
CICM with information about the address mapping performed by the NAT
device at the edge of the edge of the CentrexIP clients address domain.
The Resolve Port Mapping Ack command provides the CICM with the
following information:
# The IP address and port of the originating node, i.e. the CentrexIP client.
# The NAT device IP address and port via which the CICM is
communicating with the client, as previously provided in a Port
Mapping Discovery Ack command.

The combination of these items of information confirms that NAT mapping

has been correctly set up to permit communication between the CICM and the
CentrexIP client via the NAT device.
" Open Audio Stream Report (indicates status of audio stream that CICM asked
to be opened)
" Handset connected / disconnected
" Headset connected / disconnected
" Audio Manager Attributes Info (e.g. codecs supported)
" RTCP Statistics / Session Descrption Information Report
" Audio Stream Status Report
D6.3.3 The Key/Indicator Manager

The Key/Indicator Manager is responsible for the IT keys and indicators. It sets LEDs and
icons, reacts to key depressions and detects on-hook/off-hook.
! The most important CICM-to-client commands that apply to the Key/Indicator
Manager are:
" LED Update
" IT Icon Update
! The most important client-to-CICM commands that apply to the Key/Indicator
Manager are:
" Key Event (reports a key depression, key repeat or key release)
" On hook
" Off hook
D6.3.4 The Display Manager

The Display Manager is responsible for the presentation of information sent by the NI,
which means that the NI does not have to know where information is physically presented
or what language is used.
! The most important CICM-to-client commands that apply to the Display Manager
are:
" Set Default Character Table Configuration
" Highlight On/Off
" Clear / Restore Time and Date
" Clear / Disable Display Field
" Cursor Control
" Display Scroll with Data
" Time and Date Format
" Display Data Write
" Special Character Download

" Commands for controlling the functionality and appearance of layered

softkeys
! The client-to-CICM commands that apply to the Display Manager are used to
provide the CICM with information about the current status of varous aspects of the
CentrexIP clients display.
D6.3.5 The Broadcast Manager

The Broadcast Manager is responsible for such things as icon, character table and
time/date downloading for both the IT and any attached accessories.
! The most important CICM-to-client commands that apply to the Broadcast
Manager are:
" Accessory Sync Update
" Logical Icon Update
" Time and Date Download
" Set Default Character Table Configuration
! No client-to-CICM commands that apply to the Broadcast Manager are currently
defined.
D6.3.6 The Basic Manager

The Basic Manager handles IT maintenance functions such as self-testing.
! The most important CICM-to-client commands that apply to the Basic Manager are:
" Query Basic Manager
" Basic Manager Options
" EEprom Write
" Assign Terminal ID
" Encapsulate Command
! The most important client-to-CICM commands that apply to the Basic Manager are:
" Basic Manager Attributes Info
" Basic Manager Options Report
" F/W version
" IT Type
" Hardware ID
" Product Engineering Code
" Gray Market Info
" Encapsulate Command
" Reserved

D6.4 NAT Traversal for UniStim Signalling

For remote CentrexIP clients controlled via UniStim, the initial unsolicited command sent
by the CentrexIP client to the CICM is Resume Connection With Server, which informs
the CICM that the client is ready to accept commands. This leads to the following
command sequence:
! Resolve Port Mapping (CICM to client)
Provides the CentrexIP client with the IP address and port of the far-end originating
node, i.e. the CICM, and causes the client to send a Port Mapping Discovery
command to that far-end address. The far-end address is provided in the body of the
command.
! Port Mapping Discovery (client to CICM)
Sent to the far-end address provided in the Resolve Port Mapping command, i.e. the
CICM. The command provides the CICM with the IP address and port of the
originating node, i.e. the CentrexIP client, and causes the CICM to send a Port
Mapping Discovery Ack command to that originating address. The clients address
is provided in the body of the command to allow for NAT modification of the source
IP address in the IP packet header.
! Port Mapping Discovery Ack (CICM to client)
Informs the CentrexIP client of the NAT IP address and port via which the CICM
is communicating with the client. This information can then be included in the
Resolve Port Mapping Ack command sent by the client to conclude the
RPM-initiated command sequence.
! Resolve Port Mapping Ack (client to CICM)
Provides the CICM with the following information:
" The IP address and port of the originating node, i.e. the CentrexIP client.
" The NAT IP address and port via which the CICM is communicating with the
client, as previously provided in a Port Mapping Discovery Ack command.
The combination of these items of information confirms that NAT mapping has
been correctly set up to permit communication between the CICM and the
CentrexIP client via the NAT.
The command sequence initiated by the Resolve Port Mapping command provides the
CICM with information about the address mapping performed by the NAT device at the
edge of the edge of the enterprise address domain to which the CentrexIP client belongs.
This information will eventually be used in the Open Audio Stream command used to
set up a VoIP bearer connection.
As for customer LAN gateways controlled via MGCP, keep-alive messaging is used to
ensure that NAT bindings are maintained even when no call is in progress.

Chapter D7 NCS
D7.1 Purpose
NCS (Network-based Call Signalling) is an ASCII protocol that was originally based on
the MGCP (Media Gateway Control Protocol) IETF protocol defined in RFC3435 and
described in Chapter D8: MGCP. Like MGCP, NCS is designed to support signalling
between GWCs and the media gateways they control.
The purpose of NCS is to support embedded VoIP client devices in a PacketCable
environment, and the NCS profile has simplified and in some cases modified the base
MGCP 1.0 protocol accordingly. NCS 1.0 is defined in
PacketCable Network-Based Call Signaling Protocol Specification
PKT-SP-MGCP-I10-040402 (or later issue found at www.packetcable.com)
NCS is formally defined as a profile of MGCP for PacketCable embedded clients. It is
one layer of the PacketCable suite of specifications, and relies on other complementary
protocols to provide complete end-to-end PacketCable functionality.
In the CS2000 network architecture, NCS is carried end-to-end between CS2000 GWCs
and MTA (Multimedia Terminal Adapter) line gateways served by cable access networks,
using UDP at layer 4 and IP at layer 3. Between the MTA and the CMTS (Cable Modem
Termination System) at the head end of the cable access network, the Layer 2 datalink
layer and Layer 1 physical layer are as defined by EuroDOCSIS standards for a HFC
(Hybrid Fibre Coax) infrastructure. Between the CMTS and the CS2000 GWC, the Layer
2 and Layer 1 interfaces used depend on the architecture of the backbone packet network,
and may vary during the journey of an IP packet between the GWC and CMTS. These
changes in Layer 1 and Layer 2 are not visible to the CS2000 GWC.
Note: To complement NCS, SDP session descriptions are conveyed in-line with NCS
commands and responses. See section D1.3 on page 239 for more information.

NCS Packet Telephony Protocols Communication Server Capabilities
D7.2 Network Role

CS2000 uses NCS to control the operation of MTA (Multimedia Terminal Adapter) cable
line gateways supporting VoIP for analogue subscriber lines connected via HFC access
networks. A variety of hardware platforms can be used to support MTA line gateway
capabilities for CS2000 solutions (see section B2.10 on page 126 for more details). The
basic functionality provided is the same regardless of the MTA model and of whether
DOCSIS or EuroDOCSIS signalling is used betwen the MTA and the CMTS.
Figure 76 illustrates the role of the NCS protocol in the CS2000 network architecture.
CS2000
Call processing
Gateway Gateway
(GWC) (GWC)
for ingress for egress
gateway gateway
and MTA line gateway uses NCS

Signalling between CS2000 GWC
IP backbone network
Bearer connection
(packetised voice)
CMTS CMTS
HFC cable access networks

Signalling between CMTS and MTAs
Originating is based on (Euro)DOCSIS, and is not Terminating
Gateway visible to the CS2000 GWCs that
control the MTA gateways Gateway
(MTA) (MTA)
Signalling over the line interface

Call origination (except hook state changes and Call termination
ringing) uses in-band DTMF tones
Figure 76: Logical network role of NCS

Communication Server Capabilities Packet Telephony Protocols NCS
In a CS2000 context, NCS connections are initiated by the GWC under the control of
CS2000 call processing, i.e. CS2000 provides Call Agent functionality (also referred to
as Call Management Server functionality). Simple line media gateway functionality, i.e.
interfaces for line endpoints, is provided by the MTA. The CMTS has a twofold role:
! To relay NCS signalling between CS2000 GWCs and MTA line gateways. NCS is
carried end-to-end between GWCs and MTAs using UDP at layer 4 and IP at layer
3, but different Layer 2 and Layer 1 interfaces are used on either side of the CMTS.
The CMTS peforms Layer 1 and Layer 2 mapping to ensure that changes in Layer
1 and Layer 2 are not visible to the CS2000 GWC.
! To make HFC bandwidth available to MTA line endpoints as required. Both the IP
backbone network and the HFC access network support packet-based bearer
connections. Packet streams through the HFC access network (between CMTS and
MTA) are set up and controlled using (Euro)DOCSIS signalling. This is relevant
only within the access network, and is not visible to the CS2000 GWC.

NCS call control commands can be divided into two main categories (a full set of
maintenance commands is also supported):
" CRCX (create connection)
" MDCX (modify connection)
" DLCX (delete connection)
! Monitoring commands
" RQNT (request notification of event)
" NTFY (notification of event)
NCS makes extensive use of the RQNT and NTFY commands. This is because a line
gateway has to detect events and signalling on its lines, e.g. hook state changes and
in-band tones, and pass this information to the GWC using NCS. For example, when a
GWC and its subtending CMTSs and MTAs are brought into service and synchronised,
each MTA automatically begins to monitor its line endpoint(s) for the occurrence of an
off-hook event. NCS defines off-hook as a persistent event, which means that the MTA
watches out for it and will report it without being explicitly requested to do so.
When a subscriber goes off-hook to make a call, the MTA gateway sends a NTFY
message to tell CS2000 that an off-hook event has occurred, and CS2000 responds by
sending a CRCX (Create Connection Request). For an incoming call to a line, CS2000
sends a CRCX to the MTA when the terminating line gateway has been selected via
translations and routing, asking the MTA to set up an initially inactive bearer connection
for the selected line endpoint.
Call setup commands and their acknowledgements can include SDP session descriptions
that provide address and media stream information for the call. NCS commands identify
calls via GWC-assigned callIDs that are unique across the entire network of media
gateways.
NCS uses the UDP (User Datagram Protocol) transport protocol. Since UDP may be
subject to losses, an NCS application layer timer is started when each command is sent,
and the command is resent if the timer expires without receipt of an acknowledgement.

The following table lists the commands available and summarises their functions.
Table 33: NCS commands supported by CS2000

Connection control commands
Sent to a media gateway to request it to initiate monitoring for
the occurrence of specified endpoint events, e.g. receipt of
particular tones or dialled digits. Receipt of message
acknowledged by 200 message with no parameters.
Detection of monitored event is reported by gateway via
NTFY command.
RQNT Request GWC Also used to convey MWI+/MWI- signals to request
notification
activation / deactivation of Message Waiting Indicator on
subscriber terminal.
Note: Monitoring for persistent events is automatic, i.e. it
does not have to be explicitly requested. For example, NCS
defines off-hook as a persistent event, which means that the
MTA will report it without being explicitly requested to do so.
Sent by a media gateway to report the detection of a
monitored event. The event reported may be a persistent
NTFY Notify Gateway event that is automatically monitored (e.g. off-hook), or an
event explicitly specified in a RQNT command.
Sent to originating line gateway when
CS2000 has determined that a bearer
connection needs to be established (when
translations and routing are complete and
the terminating line is found tobe idle).
Originating CRCX sets up an initially inactive bearer
GWC / gateway connection for the line endpoint in question,
and specifies the callID to be used in all
subsequent connection control messages.
Acknowledged by 200 message with IP
Create address and SDP session description for
CRCX GWC line endpoint.
connection
Sent to terminating line gateway selected
via translations and routing, to set up an
initially inactive bearer connection for the
selected line endpoint.
Terminating Includes SDP session description, as
GWC / gateway provided in 200 acknowledgement of
CRCX sent to originating gateway.
Acknowledged by 200 message with
terminating IP address and SDP session
description.
Sent to a line media gateway to modify an existing
connection, e.g. to initiate a change from inactive or recvonly
to sendrecv. Examples:
[1] Sent to originating media gateway (after terminating
gateway acknowledges creation of connection) to
indicate to the originating endpoint the remote SDP
session description and IP address. Acknowledged by
MDCX Modify 200 message.
GWC [2] Sent to originating media gateway when ringing is
connection
being applied to call destination, asking gateway to apply
ringback tone and to provide notification if the caller
should hang up.
[3] Sent to originating media gateway when call has been
answered, to set up a full duplex bearer connection (mode
= sendrecv) between the two gateway endpoints.
MDCX acknowledged by 200 message with no parameters.

Table 33: NCS commands supported by CS2000

Sent to originating and terminating line media gateways when
CS2000 receives NTFY command indicating that one of the
call parties has gone on-hook . Causes the gateways to take
Delete down the bearer connection between the two gateway
DLCX GWC
connection endpoints.
Acknowledged by 250 message with Quality of Service data
for the completed call, e.g. packets/octets sent,
packets/octets received, packets lost.
Maintenance commands
Audit
AUEP endpoint GWC Sent by GWC to query media gateway endpoint status
status
Audit
AUCX connection Gateway Sent by media gateway to report gateway endpoint status
information
RSIP Restart in Gateway Sent by media gateway to report a gateway restart
progress
D7.4 Parameters
D7.4.1 Line Endpoint Names
GWCs and line media gateways are separately provisioned with the address information
they need to communicate with each other via NCS.
For each MTA gateway controlled by a GWC, GWC datafill specifies the following:
! FQDN (Fully Qualified Domain Name)
! IP address
Line gateway IP addresses are assigned via DHCP, and are obtained by the GWC
via DNS queries.
To indicate that the GWC should dynamically discover the IP address of a line
gateway by means of a DNS query based on the gateways FQDN, the IP address
specified in gateway datafill at the GWC should be 0.0.0.0.
address can be specified directly in GWC datafill when the gateway is provisioned.
! Control protocol (NCS 1.0)
! UDP port (2427)
! Gateway profile (codec and packetisation info).
The IP address of the GWC is provided to each MTA gateway by the CMTS management
system as part of the configuration information sent during MTA initialisation.
CS2000 datafill maps each logical line DN (Directory Number) on to a physical location.
In the case of cable media lines, CS2000 has no knowledge of the media gateways on
which the lines terminate, and DNs are mapped on to virtual physical locations. Line
endpoints are identified by means of virtual physical shelf and slot numbers associated
with line groups (see section C2.7 on page 196 for more information). Each line group
comprises up to 1023 lines; these may be supported by a number of different CMTSs, but
the entire line group is under the control of one GWC.

Endpoint names or identifiers have two components, both case-insensitive:

! he domain name of the media gateway managing the endpoint,
! local endpoint name within that media gateway
Endpoint names are therefore of the form
local-endpoint-name@domain-name
where domain-name is an absolute domain name as defined in RFC 1034.

Each embedded client may have one or more endpoints associated with it (e.g. one for
each telephone jack, and each of the endpoints is identified by a separate local endpoint
name. Associated with the local endpoint name is an endpoint-type that defines the type
of the endpoint, e.g. aaln for analogue line telephone. The endpoint type can be derived
from the local endpoint name. The local endpoint name is a hierarchical name, where the
least specific component of the name is the leftmost term and the most specific component
is the rightmost term. Example analogue access line local endpoint names are:
aaln/1 The first analogue access line on the embedded client in question.
aaln/2 The second analogue access line on the embedded client in question.
aaln/$ Any analogue access line on the embedded client in question.
aaln/* All analogue access lines on the embedded client in question.
D7.4.2 Entity Names

In the NCS/MGCP model, there is no fixed binding between entities and hardware
platforms or network interfaces. This is designed to enhance network reliability, e.g. by
allowing redundant or "fail-over" Call Agents to be implemented. In ISN07, CS2000 does
not support "fail-over" Call Agents for cable media lines in the sense defined by
PacketCable, because the CS2000 is in itself a fully redundant, carrier-grade Call Agent.
Call Agent names consist of two parts, like endpoint names. The local portion of the name
does not have any internal structure. An example Call Agent name is:
ca1@ca.whatever.net
Reliability is provided by the following mechanisms:

! Entities such as embedded clients (MTAs) or Call Agents (CS2000 GWCs) are
identified by their fully qualified domain name, not their network addresses. Several
addresses can be associated with a domain name. If a command cannot be
forwarded to a network address associated with a domain, CS2000 will retry the
transmission.
! The association between a logical name (domain name) and the platform actually
used by an entity are kept as records by the Domain Name Server (DNS). Call
Agents and media gateways must keep track of the records time-to-live read from
the DNS, and must query the DNS to refresh the information if the time-to-live has
expired. This makes it possible for entities to move between platforms.

D7.4.3 Digit Maps

A GWC can ask a media gateway to collect digits dialled by a subscriber. This facility can
be used to collect not only called party number digits, but also access codes, credit card
numbers, and other numbers requested by call control services.
Digits are buffered by the media gateway either until dialling is complete, or until the
gateway has determined that enough digits have been collected, and are then provided to
the GWC. To enable the media gateway to determine how many digits it needs to
accumulate before transmission, the GWC can provide a digit map to the gateway when
it instructs it to detect and report dialled digits. The syntax used to define such a digit map
is derived from the UNIX GREP command.
Assume, for example, that a telephone has access to the following dial plan:
0 Local operator
00 Long distance operator
xxxx Local extension number
8xxxxxxx Local number
#xxxxxxx Shortcut to local number at other corporate sites
*xx Star services
91xxxxxxxxxx Long distance number
9011 + up to 15 digits International number
This dial plan results in the following digit map:
(0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
D7.5 Command Syntax

A complete NCS command consists of a main command line followed by zero or more
<command> <trID> <endpointID> <protocol version>
where
! <command> is either a connection control or maintenance command, or an
acknowledgement code such as 200 (normal transaction completion).
! <protocol version> is NCS 1.0.
<X>: <parameter(s)>
When an NCS command such as CRCX, MDCX or 200 (acknowledgement) includes an
SDP session description, the SDP command lines are provided after the final NCS
parameter line, and separated from it by an empty line. See section D1.3 on page 239 for
more information. SDP command lines are not explicitly distinguished from NCS
parameter lines. They have the format:
<x>=<parameter(s)>

D7.6 Examples
See section E7.2.2.2 on page 494 for an annotated call flow showing the sequence of NCS
commands used to set up a call.
D7.6.1 RQNT (Request Notification)

Example 1
To apply ringing and await an off-hook event, i.e. terminate a call to a line:
RQNT 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
X: 0123456789AC
R: hd(N)
S: rg
Example 2
After being notified of an off-hook event via a NTFY from a media gateway, CS2000
requests the gateway to provide dial tone, ignore any hook flash, report immediately if an
on-hook event occurs, and accumulate dialled digits in accordance with the specified digit
map using the inter-digit timeout timer whose value is provisioned in the media gateway.
The media gateway is also instructed to report the "operation complete" event if the dial
tone signal times out without any digit being dialled or the subscriber going on-hook.
RQNT 1202 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
X: 921
D: (1XX|2XX|3XX|4XX|5XX|6XX|7XX|8XX|9XX|0XX|*|#)
S: dl
R: oc(N), hf(I), hu(N), [0-9]*#T](D)
D7.6.2 NTFY (Notification of Event)

Notification of "digits observed" event, including three digits of a number being dialled
by a subscriber. A transaction identifier correlating the NTFY with the RQNT it results
from is included.
NTFY 2002 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
X: 921
O: 0,8,8

D7.6.3 CRCX (Create Connection)

To create an inactive connection on a specified line endpoint as part of a specified CallId.
The LocalConnectionOptions specify that G.711 A-law will be the codec used and the
packetization period will be 10 ms.
CRCX 1204 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
C: 123
L: p:10, a:PCMA
M: inactive
Response indicating that the transaction was successful, and including a connection
identifier and an SDP session description for the new connection (preceded by a blank
line).
200 1204 OK
I: FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 8 a=ptime:0
D7.6.4 MDCX (Modify Connection)

Example 1
Setting the mode of a connection to send/receive, and simultaneously requesting the
media gateway to notify CS2000 immediately of a hook-flash event or a on-hook event.
The signal list is reset.
MDCX 1209 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
C: A3C47F21456789F0
I: FDE234C8
M: sendrecv
X: 944
R: hf(N), hu(N)
S:
Example 2
Passing a session description and including a notification request with an MDCX
command. The endpoint will start playing ringback tones to the user.
MDCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
C: A3C47F21456789F0
I: FDE234C8
M: inactive
X: 0123456789AE
S: rt
v=0
c=IN IP4 128.96.63.25
a=ptime:10

D7.6.5 DLCX (Delete Connection)

GWC instructs gateway to delete connection FDE234C8 on a specified endpoint.
DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
C: A3C47F21456789F0
I: FDE234C8
Response indicating successful deletion and providing connection parameters.

250 1210 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=0, LA=0
Note: Jitter and latency measurements require the MTA gateway to support RTCP.
MTAs that do not support RTCP will report jitter and latency as zero.
D7.6.6 AUEP (Audit Endpoint)

Example 1
To check whether an endpoint on a media gateway is still operational, CS2000 sends an
empty AUEP command. This is equivalent to a "ping" function.
AUEP 1200 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
The addressed endpoint acknowledges the "ping":

200 1200 OK
Example 2
To check whether the connection identifier in use for a particular endpoints connection
matches that recorded by CS2000, CS2000 sends the AUEP command with requested
information set to indicate "connection identifiers":
AUEP 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
F: I
The response indicates that the addressed endpoint on the media gateway has an
associated connection with connection identifier = 32F3:
200 1201 OK
I: 32F3
D7.7 DQoS for Cable Gateways

Congestion in the backbone packet network does not prevent new calls from being set up,
as it does in a TDM network. Instead, it increases packet loss, thus impairing voice quality
both for new calls and for existing calls. Call Admission Control (CAC) is a general term
for techniques that limit the number of calls permitted to a level at which the QoS is
acceptable. For CS2000 cable access solutions, CAC is supported by means of the DQoS
(Dynamic Quality of Service) protocol extensions defined in CableLabs specification
PKT-SP-DQOS-I09-040402 (or later issue found at www.packetcable.com).
DQoS provides mechanisms that enable the CMTS to reserve bandwidth in the HFC
access network (via RSVP) and to prioritise traffic in the backbone network (via
DiffServ). In addition to bandwidth allocation, DQoS helps prevent denial of service
attacks and illegal use of network resources.

Two types of signalling are used in implementing DQoS for the CS2000 IAC solution:
! COPS (Common Open Policy Service) gate control signalling over a TCP/IP
connection is used between the CS2000 GWC and the CMTS at the cable head end.
The CMTS acts as a COPS PEP (Policy Enforcement Point), while the GWC acts
as a PDP (Policy Decision Point). When a call is made, the GWC sends the CMTS
a COPS decision message indicating whether call setup is authorised, and (if so)
requesting the CMTS to allocate a gate with apropriate resources for the call.
The COPS gate control protocol is an extension of the COPS protocol defined in
RFC2748. The DQoS-specific extensions to COPS are defined in the PacketCable
DQoS specification.
Note: CMS (Call Management Server) is the COPS term used to denote the
functionality provided by the CS2000 Core and the GWC.
! The NCS protocol used between the MTA and the GWC allows the GateID
allocated for an authorised call to be conveyed as a parameter in call setup
messages.
When the CS2000 GWC is brought into service, it initiates a TCP connection to each
CMTS under its control. Once the TCP link is operational, it is used as follows:
1 When a new call is to be set up, the GWC sends a GATE-SET message to the
CMTS, authorising call setup and asking for a gate to be allocated.
2 The CMTS responds with a GATE-SET-ACK message conveying the GateID
assigned for the call.
NCS call setup signalling then proceeds in the normal way (see section D7.6 on page 315
for examples). The GateID to be used for the call is provided by the GWC to the MTA
gateway, either in the first CRCX message or in a subsequent MDCX message, and can
subsequently be used by the gateway in DOCSIS messages sent to the CMTS to set up
packet streams through the HFC access network.
The GateID is specified to the MTA gateway as a dq-gi (GateID) sub-parameter in the
Local Connection options parameter in a CRCX or MDCX message, as in the following
example:
L: p:10, a:PCMU, dq-gi: 1234
The gateway acknowledges receipt of the gateID by including a DQ-RI (ResourceID)

parameter in its 200 OK response to the CRCX, as in the following example:
DQ-RI: D32B8593
During normal call clearing, the CMTS sends the CMS (CS2000 GWC) a Gate Close
message to indicate that the gate has been deallocated and that there is no need for further
DQoS messaging for the call.
Gate status can be queried by the GWC via COPS GATE-INFO messages.
D7.8 Cable Security

PacketCable Security entails IPSec with Kerberos key management on the MTA/CMS
interface and IPSec with IKE (using pre-shared keys) on the CMS/CMTS interface. For
details, see PKT-SP-SEC-I10-040113 (or later issue found at www.packetcable.com).

Chapter D8 MGCP
D8.1 Purpose
MGCP (Media Gateway Control Protocol) is an IETF protocol designed to support
signalling between GWCs and the media gateways they control. It is defined in IETF
RFC3435. The version supported by CS2000 is MGCP 1.0bis - 00 January 2001.
In the CS2000 network architecture, MGCP signalling is used between a CS2000 GWC
and a customer LAN line gateway supporting analogue subscriber lines. See section B2.9
on page 123 for information about the gateway types and models supported.
The commands and capabilities provided by MGCP for the control of line media gateways
attached to customer LANs are very similar to those provided by the NCS protocol for the
control of line media gateways attached to cable access networks, as described in Chapter
D7: NCS. To avoid duplication, this chapter cross-refers where possible to sections in
Chapter D7 where these provide information that is equally applicable to NCS and
MGCP.
Note: To complement MGCP, SDP session descriptions are conveyed in-line with
MGCP commands and responses. See section D1.3 on page 239 for more information.

Communication Server Capabilities Packet Telephony Protocols MGCP
D8.2 Network Role

CS2000 uses MGCP signalling to control the operation of line media gateways attached
to customer LANs and supporting VoIP for analogue subscriber lines. A range of different
media gateway types are supported, as described in section B2.9 on page 123.
MGCP connections are initiated by a line GWC under the control of CS2000 call
processing, i.e. CS2000 provides Call Agent functionality.
IP addresses for MGCP-controlled line media gatewayes are assigned dynamically, as
described in section D8.4.
Figure 77 illustrates the role of MGCP in supporting customer LAN line gateways.
CS2000
Call processing
Gateway Gateway
(GWC) (GWC)
gateway gateway
customer LAN line gateway uses MGCP
customer LAN line gateway uses MGCP

Signalling between CS2000 GWC and
Signalling between CS2000 GWC and

IP backbone network
Bearer connection
(packetised voice)
Access Access
Customer LANs (Ethernet)

Line Line
media media
gateway gateway

Figure 77: Network role of MGCP in supporting customer LAN line gateways

MGCP Packet Telephony Protocols Communication Server Capabilities

MGCP comprises seven commands, which can be divided into three categories:
" CRCX (create connection)
" MDCX (modify connection)
" DLCX (delete connection)
Note: The MGCP CRCX command supports negotiation for the following packet
network bearer path characteristics (see A59039029 for details):
" G.729a/b with RFC2833 for DTMF support
" T.38 for Group 3 fax
" Comfort noice insertion
! Monitoring commands
" RQNT (request notification of event)
" NTFY (notification of event)
! Maintenance commands
" AUEP (audit endpoint status)
" RSIP (restart in progress)
Commands and command usage are essentially the same the same for MGCP as they are
for the NCS (Network-based Call Signalling) protocol described in Chapter D7: NCS,
which is based on MGCP. To avoid duplication, the detailed command descriptions
provided in section D7.3 on page 310 are not repeated in this chapter.

D8.4 IP Address Assignment for MGCP Line Gateways

D8.4.1 Address Assignment without NAT Involvement
GWCs and small CPE line media gateways controlled by MGCP obtain each others
address information dynamically. The basic sequence of events is:
5 For a customer LAN gateway controlled via MGCP, the IP address provided in the
downloaded configuration file is that of an Audio Controller GWC configured to
provide RMGC (Redirecting MGC) functionality. This responds to the RSIP by
sending back an MGCP message specifying the name and IP address of the GWC
that will actually control the gateway. This gateway then sends another RSIP to the
correct GWC.
Note: GWC support for RMGC functionality is described in A89008489. It
requires the GWC to maintain a local copy of the MG-to-MGC mapping database,
instead of querying the central network view database.
D8.4.2 Address Assignment Involving NAT

Two principles:
! Every CS2000 GWC, including the RMGC GWC, has an externally visible IP
address in the carriers public network.
! Every message from a media gateway to a GWC contains the FQDN (Fully
Qualified Domain Name) of the gateway.

MGCP Packet Telephony Protocols Communication Server Capabilities
For a line gateway attached to a customer LAN and controlled by MGCP, the address
binding process is as follows:
1 The gateway sends an RSIP (Reset In Progress) message to the public network
address of the CS2000 RMGC (Redirecting MGC) GWC. The RSIP message is
routed through the NAT, which creates a bind between the gateways private
network address and an externally visible address on the public network side of the
NAT.
2 The RMGC looks at the gateway FQDN conveyed in the RSIP message to
determine which gateway sent the message.
3 The RMGC sends the RSIP reply to the IP address and port from which it received
the RSIP message, which is an externally visible address on the public network side
of the NAT. This reply contains the IP address and port of the gateways GWC.
4 The NAT relays the RSIP reply to the media gateways private network address,
which is bound to the externally visible address on the public network side of the
NAT.
Note: This binding used by the RMGC will timeout and expire, as it is no longer
needed.
5 The gateway sends an RSIP message to the public network address of its, GWC, as
provided by the RMGC in the RSIP reply. The RSIP message is routed through the
NAT, which creates a bind between the gateways private network address and an
externally visible address on the public network side of the NAT.
6 The GWC looks at the gateway FQDN conveyed in the RSIP message to determine
which gateway sent the message. GWC datafill is then updated to establish an
association between the FQDN and the IP address and port from which the GWC
received the RSIP message, which is an externally visible address on the public
network side of the NAT.
The public IP address associated with the gateways FQDN will be used for
subsequent messages sent by the GWC to the gateway.
The GWC checks every incoming message for the embedded gateway FQDN. If the
source of a packet does not match the source of previous packets for that gateway,
i.e. the public IP address associated with the gateways FQDN, this indicates that
the address binding at the NAT has changed. In this case, GWC datafill is updated
to establish an association between the FQDN and the new IP address and port, and
this will then be used for subsequent messages.
It is a CS2000 requirement that the media gateway must send packets through the
NAT sufficiently often to keep the NAT address binding for the gateway alive. This
can be achieved by using a timer that is automatically reset whenever the gateway
sends a real message to the GWC, and causes the gateway to send a keep-alive
message if the timer expires without a real message being sent.

D8.5 Parameters
Parameters and parameter usage are essentially the same the same for MGCP as they are
for the NCS (Network-based Call Signalling) protocol described in Chapter D7: NCS,
which is based on MGCP. To avoid duplication, the detailed parameter descriptions
provided in section D7.4 on page 312 are not repeated in this chapter.
D8.6 Command Syntax

A complete MGCP command consists of a main command line followed by a number of
<command> <trID> <protocol version>
where
! <command> is either one of CRCX, RQNT or DLCX, or an acknowledgement code
such as 200 (normal transaction completion).
! <protocol version> is MGCP 1.0.
<X>: <parameter(s)>
When an MGCP command such as CRCX, MDCX or 200 (acknowledgment) includes an
SDP session description, the SDP command lines, whose format is similar to that of
MGCP parameter lines, are provided after the final MGCP parameter line. See section
D1.3 on page 239 for more information. SDP command lines are not explicitly
distinguished from MGCP parameter lines.
D8.7 Examples
See the NCS examples in section D7.6 on page 315. These are equally applicable to
MGCP except for the protocol version, which for MGCP is MGCP 1.0. rather than NCS
1.0.

Chapter D9 MPCP
D9.1 Purpose
MGCP (Media Gateway Control Protocol) is an IETF protocol designed to support
signalling between GWCs and the media gateways they control. It is defined in IETF
RFC3435.
MPCP (Media Proxy Control Protocol) is a simple proprietary protocol loosely based on
version 1.0 of the MGCP protocol. It uses a subset of MGCP messages, which have been
modified and extended with experimental parameters and proprietary interpretation of
existing parameters. It is used by a CS2000 GWC to control an RTP Media Portal
supporting NAPT (Network Address and Port Translation) for media streams
entering/leaving the CS LAN and NAT traversal for media streams between gateways in
different address domains.
Note: Unlike MGCP when used to control line media gateways attached to customer
LANs (see Chapter D8: MGCP), MPCP does not make use of SDP session descriptions
conveyed in-line with MPCP commands and responses. This is because the RTP Media
Portal is switched into calls to act as an intermediary between two media gateways, and it
is the responsibility of the gateways to perform codec negotiation to determine the
characteristics of the end-to-end media stream; the RTP Media Portal merely relays media
stream packets.

Communication Server Capabilities Packet Telephony Protocols MPCP
D9.2 Network Role of MPCP

CS2000 uses MPCP signalling to control the operation of RTP Media Portals. In ISN07,
the primary role of RTP Media Portals is to support NAPT (Network Address and Port
Translation) between different address domains, allowing media streams associated with
a call (multimedia session) to be routed between domains. See Chapter G5: IP
Addressing and Internet Transparency for a detailed discussion of NAT / NAPT. See
section B5.2 on page 156 for information about the RTP Media Portal.
There are two scenarios in which an RTP Media Portal needs to be switched into a call:
! For a call between two media gateways where one or both of the gateways belongs
to a private address domain behinad a NAT rather than to the carriers public
address domain, and NAT traversal is therefore required for the media stream.
Note: The carriers public network and public address domain are actually private,
but can be regarded as public because they support communication between private
customer and enterprise domains connected to the carriers network.
! For a call to/from the private VoIP address domain used for CS2000 solution
components, in which case the RTP Media Portal provides NAT/firewall
functionality for media streams entering and leaving the private VoIP domain, e.g.
to/from an MS2000/UAS media server or a carrier-located PVG.
When CS2000 call processing determines that a media stream needs to be set up between
address domains, it selects an RTP Media Portal from the pool available. Equal usage of
Media Portals is ensured by using a selection mechanism that cycles through all the RTP
Media Portals in the pool.
The GWC controlling the selected RTP Media Portal then sends an MPCP CRCX (Create
Connection) message to the portals host CPU. The host CPU selects one of its peripheral
cards to host the multimedia session, basing the selection on which card currently has
most ports available. Card selection determines which IP addresses are made available for
media streams, because each peripheral card has two static IP addresses: one on the
private internal network (the CS LAN), and one on the public external network.
Each peripheral card manages two pools of UDP ports, one for each of its IP addresses.
Ports are randomly allocated from one or both of these pools in response to MPCP
commands sent by the portals GWC to request resources for the multimedia session. As
ports are allocated, the count of available ports is updated accordingly, ensuring that a
peripheral card is not selected for a new session if all of its ports have already been
allocated.
When two ports on an RTP Media Portal peripheral card have been dynamically allocated
to a multimedia session, a media stream can be routed via those ports, either between two
public ports (for NAT traversal via the carriers public network between two private
domains) or between a private and a public port.

MPCP Packet Telephony Protocols Communication Server Capabilities
Figure 78 illustrates the network role of the RTP Media Portal in supporting NAT
traversal between two media gateways located in private networks behind NAT devices.
CS2000 Core
(call processing)
Control / signalling
Media stream
Line CentrexIP
GWC GWC
H.248
MPCP
Uni
CICM
Public address MGCP
discovery for
signalling UniStim
Enterprise network Media portal Enterprise network

(private address domain) controller (private address domain)
Private Public Public Private

RTP media
portal
Firewall Firewall
Line (NAT/NAPT) Media packet (NAT/NAPT) CentrexIP
gateway engine on client
on LAN peripheral card
Public address Two-way NAT
discovery for functionality for
media stream RTP/UDP
media stream NAPT-port@NAPT-address.
(IP address belongs to selected card; port is
dynamically assigned from pool for domain)
Figure 78: Network role of MPCP in controlling an RTP Media Portal

Communication Server Capabilities Packet Telephony Protocols MPCP

Nortels MPCP subset of MGCP consists of only four commands:
! Commands sent from GWC to RTP Media Portal
" CRCX (Create Connection) is used to initiate the setting up of a session via
the Media Portal on behalf of a specified endpoint.
" MDCX (Modify Connection) is used to modify an existing session, e.g. by
connecting an additional endpoint or a replacement endpoint.
" DLCX (Delete Connection) is used to delete connections from a session or to
terminate a session altogether.
The RTP Media Portal acknowledges each command and indicates its outcome by
sending a response back to the GWC. The response to a successful CRCX or
MDCX command provides the GWC with two items of information:
" Port number
A randomly assigned port number on the RTP Media Portal, associated with
a peripheral card IP address in the same domain as the endpoint specified in
the CRCX or MDCX command.
" Connection ID
This identifies the connection with which the asigned port number is
associated for one-way media, and can be used by the GWC in a subsequent
DLCX command to refer to (and delete) all of the endpoints associated with
a given connection.
! Command sent from RTP Media Portal to GWC
RSIP (Restart In Progress) provides the GWC with information about the status and
availability of the Media Portal. Depending on the parameters provided, it indicates
either that the Media Portal is now ready to handle requests, or that it can no longer
handle requests because all of its ports are in use.
The GWC does not acknowledge commands received from Media Portals.
One distinction that applies to all MPCP commands is that they do not make use of SDP
session descriptions conveyed in-line with MPCP commands and responses. Specifically,
this means that MPCP does not support the provision of SDP session description
information in response to a LocalConnectionOptions parameter specifying acceptable
media characteristics.

Chapter D10 IUA
D10.1 Purpose
IUA (ISDN User Adaptation) is a layer in the (Q.931 or QSIG) / IUA / SCTP protocol
stack designed to convey Q.921 user information between a GWC and a gateway
supporting ISDN PRI or QSIG access by providing both media gateway and signalling
gateway functionality.
IUA enables a gateway to provide signalling gateway functionality by supporting
signalling backhaul from the gateway to the GWC, enabling call processing to be
performed at the CS2000. IUA signalling backhaul is supported for two access protocols:
! ISDN PRI, for which call control signalling is defined in Q.931 or a specification
derived from Q.931.
! QSIG, for which Layer 3 call processing is defined in IS 11572. This is based on
DSS1 Layer 3, i.e. Q.931 / PRI.
For PRI, the recommended device/media control protocol used to complement call
control signalling between the GWC and gateway is the H.248 protocol described in
Chapter D3: H.248. For QSIG, the only complementary device/media control protocol
that has currently been verified is the ASPEN protocol described in Chapter D4: ASPEN.
For details of CS2000 support for PRI, including specification compliance and support for
national PRI variants, see Chapter E4: PRI Access Interface. For details of CS2000
support for QSIG, see Chapter E5: QSIG VPN Interface.
IUA provides adaptation between PRI/QSIG and the SCTP layer used to provide reliable
transport. Logically, it can be regarded as the equivalent of PRI Layer 2 (datalink), as
defined in ETS 300 402 in relation to Q.920 and Q.921. It provides capabilities similar to
ISDN Layer 2 for the encapsulation of Q.921 user information, i.e. PRI/QSIG Layer 3
messages. IUA over SCTP is described in RFC3057. It also gives the GWC remote
control over Q.921 link establishment and release at the gateway.
SCTP (Stream Control Transmission Protocol) is an IETF reliable transport protocol
designed as an alternative to TCP and UDP for handling delay-sensitive payloads such as
call control signalling. It is an assured transfer type that will not allow call setup to
succeed unless all messages have been received in the correct order. It is also secure.
SCTP is being driven in the IETF by the SIGTRAN workgroup; it is defined in RFC2960.
CS2000 support for SCTP is described in section D1.2.3 on page 235.

Communication Server Capabilities Packet Telephony Protocols IUA
D10.2 Network Role

CS2000 release ISN07 supports two types of trunk interface: CCS7 and ISDN PRI/QSIG.
For CCS7 calls, call control signalling (IAM etc) terminates on a USP or FLPP in the
CS2000; it is not terminated on the media gateway that handles the corresponding bearer
channel. For ISDN PRI/QSIG calls, however, the D-channel and the associated B-channel
both terminate on the same gateway, which must therefore support signalling gateway
functionality as well as media gateway functionality. Signalling gateway functionality for
PRI/QSIG means terminating ISDN D-channels and backhauling PRI/QSIG Layer 3
signalling (SETUP etc) across the packet network. This enables CS2000 to perform
PRI/QSIG call processing, and to initiate media control signalling sessions to control the
packet network bearer connections for PRI/QSIG calls.
The mechanism used is to encapsulate the PRI/QSIG Layer 3 signalling in IP packets so
that it can be conveyed between the gateway and a CS2000 GWC. The protocol stack used
for this purpose is Q.931 / IUA / SCTP / IP.
Figure 79 illustrates the network role of Q.931 / IUA / SCTP call control signalling.
CS2000 CS2000
Access DPT GWC DPT GWC Access
Gateway and Session and Session Gateway

Two types of GWC - gateway signalling:

Media control signalling control via H.248 (PRI) or
ASPEN (QSIG), with SDP session description
commands in-line
PRI/QSIG call control signalling (Q.931 Layer 3)
conveyed over IUA and SCTP
Originating Terminating
Gateway Gateway
30B+D 30B+D
PRI/QSIG PRI/QSIG
access access
(23B+D (23B+D
PRI also PRI also
supported) supported)
Figure 79: Network role of Q.931 / IUA / SCTP
See section E4.2.2 on page 451 for an overview of the process of setting up a PRI call
between two CS2000s across a backbone packet network, including an annotated call
flow.

IUA Packet Telephony Protocols Communication Server Capabilities
D10.3 Interface Characteristics

D10.3.1 Q.931 or QSIG / IUA / SCTP Protocol Stack
! Used for call control signalling between a GWC and a PP7480 or PP15000 PVG
supporting access via PRI/QSIG trunks for a digital PBX or other PRI-enabled
device.
! PRI/QSIG signalling encapsulation
PRI/QSIG Layer 3 messages (Q.931 or QSIG) such as SETUP are conveyed in IUA
messages in the same way that they are normally conveyed in Q.921 Layer 2
messages.
! Q.921 primitives enabling establishment and disconnection of the Q.921 layer in the
gateway are carried over IUA. This enables the GWC to exercise remote control
over the Q.921 layer in the gateway.
D10.3.2 PRI / QSIG

For details of CS2000 support for PRI, see Chapter E4: PRI Access Interface.
For details of CS2000 support for QSIG, see Chapter E5: QSIG VPN Interface.
D10.3.3 IUA
CS2000 GWCs and gateways are compliant with IUA as defined in IETF draft version 1
of RFC3057. Its main characteristics are:
! Capabilities similar to those of Q.921 Layer 2 (datalink)
! Messages used in Q.921 link establishment and release:
" Establish (corresponding to Q.921 DL-ESTABLISH)
" Release (corresponding to Q.921 DL-RELEASE)
! Messages used for the transport of Q.931 messages as data:
" Data (corresponding to Q.921 DL-DATA)
D10.3.4 SCTP
See section D1.2.3 on page 235 for information about SCTP.

Chapter D11 V5UA
D11.1 Purpose
V5UA (V5 User Adaptation) is used in supporting analogue subscriber lines served by the
V5.2 access interface described in Chapter E7: IBN Lines.
V5.2 can be used to support access to a backbone packet network for subscriber lines
connected to a V5.2 Access Network (AN). V5.2 backhaul supports the transport of V5.2
Layer 3 signalling protocols between a V5.2 AN and an MGC via a managed packet
network. The principle of signalling backhaul is to terminate the lower protocol layers of
a switched circuit network signalling stack at the signalling gateway (a
CS2000-controlled PVG in this case) and transport (backhaul) the higher protocol layers
to an MGC for processing.
For the CS2000 implementation supported in ISN07, the allocation of responsibilities is
as follows:
! AN functionality is provided by a multiplexer or hub, connected to a PVG by means
of an integrated V5.2 interface comprising up to 16 E1 carriers.
! The PVG provides signalling gateway functionality as well as media gateway
functionality. The V5.2 bearer channels on the TDM-side E1 carriers are mapped
on to bearer connections across the backbone packet network. For V5.2
communication channels (C-channels), Layer 1 and 2 functionality is terminated at
the PVG, and Layer 3 signalling, including call control signalling, is extracted and
routed to the CS2000 using V5UA. See section B2.4 on page 111 for further
information.
! MGC functionality is provided by CS2000
V5UA (V5.2 User Adaptation) is an IETF protocol defined in
draft-ietf-sigtran-v5ua-03.txt as an extension to the IUA protocol described in Chapter
D10: IUA. The CS2000 implementation of IUA is compliant with draft version 1 of IUA,
so V5UA as an extension to IUA is not fully compliant with draft-ietf-sigtran-v5ua-03.txt
where such compliance would conflict with IUAv1.

V5UA Packet Telephony Protocols Communication Server Capabilities
Figure 80 illustrates the protocol stacks used in supporting V5.2 access to a backbone
packet network.
V5.2 Access PVG supporting MGC

Network (AN) SG functionality (CS2000)
Layer 3 V5.2 messages

V5.2 V5.2
LAPV5 Bridging Backhaul
messages messages
V5UA V5UA
LAPV5 LAPV5 SCTP SCTP

LAPV5
terminated IP IP
Signalling data link Backhaul link
Figure 80: Protocol mapping for V5UA
As shown in Figure 80, CS2000 supports V5UA as a layer in the V5.2 / V5UA / SCTP
protocol stack. This is designed to convey V5.2 Layer 3 messages between a GWC and a
gateway supporting V5.2 analogue line access by providing both media gateway and
signalling gateway functionality.
V5UA provides adaptation between V5.2 signalling and the SCTP layer used to provide
reliable transport. Logically, it can be regarded as the equivalent of the ISDN datalink
layer, as it provides capabilities similar to ISDN Layer 2 for the encapsulation of LAPV5
user information, i.e. V5.2 Layer 3 messages.
The messages conveyed via V5UA can be categorised as follows:
! V5.2 Layer 3 call control messages
DTMF in-band signalling or standard POTS electrical signals. (The V5UA protocol
is capable of conveying Q.931 Layer 3 signalling as well as PSTN signalling, e.g.
for ISDN access, but this is not currently supported by CS2000.)
! V5.2 Layer 3 interface control messages
user port control.
! V5 system management messages for controlling interaction with V5.2 Layer 2 via
primitives, e.g. establishing or releasing a V5.2 C-channel.

Communication Server Capabilities Packet Telephony Protocols V5UA
primitives, e.g. link status queries and reports.
Note: Unlike the ISDN datalink layer, V5UA supports link status and link
identification messages because the V5 standards require V5.2 system management
to interact directly with V5.2 Layer 1 (including the Layer 1 FSM). Since these
entities may be physically separated in a V5 backhaul scenario, V5UA must provide
mechanisms for communication between them.
The term V5.2 signalling should be taken to include interface control and
management/maintenance signalling as well as call control. The term V5-PSTN
signalling specifically denotes call control signalling for PSTN (analogue) lines.
The protocol used for the device/media control signalling that complements V5-PSTN
Layer 3 call control signalling between the GWC and gateway is H.248, as described in
Chapter D3: H.248.
SCTP (Stream Control Transmission Protocol) is an IETF reliable transport protocol
designed as an alternative to TCP and UDP for handling delay-sensitive payloads such as
call control signalling. It is an assured transfer type that will not allow call setup to
succeed unless all messages have been received in the correct order. It is also secure.
SCTP is being driven in the IETF by the SIGTRAN workgroup; it is defined in RFC2960.
CS2000 support for SCTP is described in section D1.2.3 on page 235.
D11.2 Network Role

The V5.2 interface provides a mechanism for multiplexing different types of access
interface on to an integrated group of 2Mb/s PCM30 carriers (from 1 up to a maximum of
16). The signalling for the access interfaces is multiplexed on to one or more 64Kb/s
channels that have been designated as V5 communications channels (C-channels). Lines
and B-channels conveying the voice/data traffic for the access interfaces are mapped 1:1
on to 64Kb/s channels that have been designated as V5 bearer channels. A given V5.2
interface can provide a maximum of 480 bearer channels (16 carriers x 30 user channels).
One communications channel could in theory serve all the voice channels for an entire
V5.2 group.
The CS2000 implementation of the V5.2 protocol is based on ETSI V5.2 Standard
(Edition 1), as defined in:
! ETS 300 324-1 (1994) with Amendment ETS 300 324-1/A1 (1996)
CS2000 does not support Edition 2 of the ETSI V5.2 standard.
ETS 300 324 actually defines the V5.1 interface, which allows line interfaces to be
multiplexed on to a single E1 carrier, but sections of ETS 300 324 that also apply to ETS
300 347 are not reproduced in ETS 300 347. Functionally, V5.2 is a superset of V5.1, i.e.
V5.1 capabilities are the same as the capabilities of a V5.2 interface with only one carrier.
However, the ability to support single-carrier V5.2 interfaces should not be interpreted as
formal compliance with the V5.1 specification.
For V5.2 access to a packet backbone network, the C-channel and the associated
B-channel for a given call both terminate on the same gateway, which must therefore
support signalling gateway functionality as well as media gateway functionality.
Signalling gateway functionality for V5.2 means terminating V5.2 C-channels and

backhauling V5.2 Layer 3 signalling (ESTABLISH etc) across the packet network. This
enables CS2000 to perform V5.2 call processing, and to initiate media control signalling
sessions to control the packet network bearer connections for V5.2 calls.
The mechanism used is to encapsulate the V5.2 Layer 3 signalling in IP packets so that it
can be conveyed from the gateway to a CS2000 GWC. The protocol stack used for this
purpose is V5.2 / V5UA / SCTP / IP.
Figure 81 illustrates the network role of V5-PSTN / V5UA / SCTP call control signalling.
CS2000 CS2000
Access DPT GWC DPT GWC Access
Gateway and Session and Session Gateway

Two types of GWC - gateway signalling for V5.2 access:

Media control signalling control via H.248 (with SDP
session description commands in-line)
V5.2 call control signalling (V5.2 Layer 3 PSTN) conveyed
over V5UA and SCTP
V5.2 V5.2
gateway gateway
V5.2 interface V5.2 interface

comprising comprising
1-16 E1 carriers 1-16 E1 carriers
V5.2 Access V5.2 Access

Network (AN) Network (AN)
Figure 81: Network role of V5.2 / V5UA / SCTP

Communication Server Capabilities Packet Telephony Protocols V5UA

D11.3.1 V5.2 Layer 3 / V5UA / SCTP Protocol Stack
! Used for call control, interface control and management signalling between a GWC
and a PP7480 or PP15000 PVG supporting access for V5.2 lines via a V5.2 AN.
! Encapsulation of V5.2 call control signalling
Layer 3 V5 messages such as the V5-PSTN message ESTABLISH are conveyed in
V5UA messages in the same way that they are normally conveyed in LAPV5-DL
and LAPV5-EF messages. For PSTN lines, LAPV5-DL messages convey
equivalents of analogue line signals.
! Encapsulation of V5.2 interface control signalling
" Bearer Channel Control (BCC) protocol
" Common control protocol
" Protection protocol
" Link control protocol for maintenance access
! Support for V5 system management messages conveying primitives for interaction
with V5.2 Layer 2, allowing the GWC to control the data link layer in the gateway,
e.g. to establish or release a C-channel.
! Support for V5 system management messages conveying primitives for interaction
with V5.2 Layer 1, allowing the GWC to control the Layer 1 FSM in the gateway,
e.g. to obtain link status information.
D11.3.2 V5.2 Lines (V5.2 Signalling)

For details of CS2000 support for V5.2 lines, see Section E7.2.4: V5.2 PSTN Lines on
page 499.
D11.3.3 V5UA
CS2000 GWCs and gateways are compliant with V5UA as defined in
draft-ietf-sigtran-v5ua, except where such compliance would conflict with IUAv1, on
which the CS2000 implementation of V5UA is based. V5UA capabilities are similar to
those of Q.921 Layer 2 (datalink). It supports the following types of message:
! Messages used in link layer establishment and disconnection:
" MDL-ESTABLISH(corresponding to Q.921 DL-ESTABLISH)
" MDL-RELEASE(corresponding to Q.921 DL-DISCONNECT)
! Message used for the transport of V5-PSTN messages as data:
" DL-DATA (corresponding to Q.921 DL-DATA)
! Messages used for Layer 1 control and status inquiry:
" MPH-LINK-STATUS
" MPH-SA-BIT
! Message used for error reporting between V5 entities on GWC and GW:
" ERROR-INDICATION
D11.3.4 SCTP
See section D1.2.3 on page 235 for information about SCTP.

D11.4 Call Setup Example

Figure 82 illustrates V5.2 call setup on the originating side, showing the interaction
between V5.2, V5UA and H.248 signalling and also the dual MG/SG role of the PVG.
PVG CS2000
V5.2 MG SG GWC
AN
Caller
goes V5-PSTN: ESTABLISH V5UA Data Ind (ESTABLISH)
off-hook
V5-PSTN: ESTABLISH ACK V5UA Data Req (EST ACK)
V5-BCC: ALLOCATION V5UA Data Req (ALLOCATION)
V5-BCC: ALLOCATION COMP V5UA Data Ind (ALLOC COMP)
H.248 Add endpoint to context

Apply dial tone
Dial Dial tone Collect digits against digit map
tone
1st
digit Dial tone
removed
Digits H.248 Notify endpoint
matching Match against digit map Onward
digit map call
H.248 Notify endpoint setup
More Additional digit begins
digits
H.248 Modify physical endpoint
Stop digit collection
H.248 Add packet port to context

Term-
ination
H.248 Modify packet port identified
SDP definition of port characteristics
Apply
H.248 Modify endpoint ringing
RIngback RIngback tone Apply ringback tone
tone

Mode=sendrecv Off-hook /
Ringback tone Stop ringback tone answer
removed
Call in progress
Figure 82: V5.2 call setup (originating side only)

Chapter D12 MTP Adaptation Protocols
(M3UA and M2PA)
D12.1 Purpose
MTP User Adaptation is designed to support CCS7 signalling over an IP network.
Specifically, it allows CCS7 user part messages or MTP Message Signal Units (MSUs) to
be conveyed between packet network nodes.
Either of two types or levels of user adaptation can be used, depending on whether CCS7
signalling is to be conveyed between packet network nodes that share a CCS7 point code
or nodes that have separate CCS7 point codes. In CCS7 terms, conveying user part
messages between nodes with the same CCS7 point code is known as message
distribution, while conveying MSUs between nodes with diferent CCS7 point codes is
known as message routing. These two types of MTP user adaptation are:
! M3UA (MTP Layer 3 User Adaptation)
Within a distributed system whose components can be accessed via a single CCS7
point code, M3UA can be used to convey user part messages between those
components. Each incoming message is distributed to the appropriate component
and presented to the appropriate user part (ISUP, TUP, TCAP) exactly as if MTP
Layer 3 was doing the distribution rather than M3UA.
In a CS2000 that uses the USP to terminate CCS7 signalling, the USP and the Core
share the same point code, and the USP uses M3UA to distribute incoming CCS7
messages to the Core and GWCs. Use of M3UA over the CS2000 CS LAN between
USP and the Core makes it unnecessary for the Core to provide MTP3 functionality.
! M2PA (MTP2-User Peer-to-Peer Adaptation)
M2PA is used to convey CCS7 MSUs across the backbone packet network between
nodes with different CCS7 point codes. A CCS7 MSU is encapsulated in an M2PA
packet to be routed. On receipt, the M2PA packet is unwrapped and the MSU is
processed appropriately.
In a network of CS2000s that use USPs to terminate CCS7 signalling, each USP and
its Core share the same point code. MSUs can be conveyed between CS2000s
(strictly speaking, between USPs belonging to different CS2000s) using M2PA.
Note: In ISN07, CS2000 uses this functionality only for TCAP-based NCAS (Non
Call Associated Signalling). ISUP and TUP signalling between CS2000s is
conveyed encapsulated in SIP-T. NCAS is not supported by the USP-Compact.

MTP Adaptation Protocols Packet Telephony Protocols Communication Server Capabilities
D12.2 Network Role

Unlike the packet network protocols described in other Part D chapters, both M3UA and
M2PA are supported by the CS2000 Universal Signalling Point (USP) rather than by
GWCs. M3UA is used to support intra-CS2000 signalling over the CS LAN, especially
signalling between the Core and the USP; direct signalling between the USP and GWCs
is also supported. M2PA is used to support TCAP NCAS (Non Call Associated
Signalling) with remote CS2000s across the backbone packet network.
Note: TCAP NCAS over the packet network is not supported by the Compact version of
the USP.
Figure 83 illustrates USP support for CCS7 signalling via M3UA and M2PA.
CS2000
TDM-side switches,
TCAP
ISUP TUP
SCCP Conventional
SCPs, etc
TCAP CCS7
ISUP TUP MTP3
SCCP signalling
MTP2 network
M3UA
MTP1
SCTP
CS2000 IP USP
Core TCAP
SCCP
MTP3
M2PA
SCTP
Other CS2000s,
CS LAN IP
peer MGCs
IP control
network over
SIP-T SIP-T backbone
Sessioin packet network
DPT Server ISUP TUP
GWC or SDP SDP
VRDN
TCP or UDP
IP
See section B1.4.5.3 on page 62 for
with Session Server or VRDN
Figure 83: USP support for CCS7 signalling

Communication Server Capabilities Packet Telephony Protocols MTP Adaptation Protocols

D12.3.1 M3UA
M3UA (MTP Layer 3 User Adaptation) is an IETF protocol for communication between
distributed system components that share the same CCS7 point code. It is defined in
draft-ietf-sigtran-m3ua.
CS2000 supports M3UA as one layer in the CCS7 / M3UA / SCTP / IP protocol stack,
and uses it for intra-CS2000 signalling over the CS LAN, especially signalling between
the Core and the USP (Universal Signalling Point).
M3UA can be used to convey messages belonging to any CCS7 user part, either
circuit-oriented protocols such as ISUP and TUP or circuit-independent protocols such as
TCAP. As far as the user parts that send and receive messages are concerned, the facilities
provided by M3UA are identical to those provided by MTP Layer 3. Specifically, M3UA
supports the following primitives defined in Q.701:
MTP-TRANSFER request
MTP-TRANSFER indication
MTP-PAUSE indication
MTP-RESUME indication
MTP-STATUS indication
User data provided in an MTP-TRANSFER request primitive (i.e. a CCS7 user part
message) is encapsulated in an M3UA Payload Data Message (DATA) to be transferred.
On receipt, this user data is extracted and provided to the destination user part in an
MTP-TRANSFER indication primitive.
M3UA also supports messages of the following types:
! Management messages
! SS7 Signalling Network Management messages
! ASP State Maintenance messages
! ASP Traffic Maintenance messages
! Routing Key Management messages
See Chapter E2: CCS7 Interfaces for information about the specific CCS7 protocols and
protocol variants supported by CS2000.
D12.3.2 M2PA
M2PA (MTP2-User Peer-to-Peer Adaptation) is an IETF protocol for communication
over a packet network between IP Signalling Points (IPSPs). An IPSP is a CCS7 node
with an IP signalling connection. IPSPs connected via M2PA must have different CCS7
point codes. M2PA is defined in draft-ietf-sigtran-m2pa.
With effect from ISN07, CS2000 supports M2PA as one layer in the TCAP / SCCP /
MTP3 / M2PA / SCTP / IP protocol stack, and uses it for NCAS (Non Call Associated
Signalling) with remote CS2000s (strictly speaking, with USPs beonging to remote
CS2000s) via the backbone packet network. A CCS7 MSU is encapsulated in an M2PA
packet to be routed. On receipt, the M2PA packet is unwrapped and the MSU is processed
appropriately. The SCTP association acts as a CCS7 link between the IPSPs. It is the

MTP Adaptation Protocols Packet Telephony Protocols Communication Server Capabilities
responsibility of the M2PA layer to maintain a map of each of its CCS7 links to the
corresponding SCTP association.
CS2000 use of M2PA to support NCAS supersedes its use of M2UA (MTP Layer 2 User
Adaptation) for this purpose in releases prior to ISN07.
Note: TCAP NCAS over the packet network is not supported by the Compact version of
the USP.
M2PA is a general-purpose mechanism for conveying CCS7 signalling over an IP
network between IP Signalling Points (IPSPs). It is therefore potentially capable of
supporting ISUP or TUP signalling between CS2000s over MTP3 / M2PA / SCTP / IP,
but this capability is not used by the CS2000 international product. Inter-CS signalling via
ISUP and TUP is instead supported by DPT GWCs and Session Servers using SIP-T
encapsulation of CCS7 user part messages, as described in Chapter D2: SIP and SIP-T.
The primitives provided by M2PA for communication with MTP Layer 3 are the same as
those provided by MTP2 for MTP3. The most important of these are:
! Primitives sent from MTP3 to M2PA:
" Data Request
Used to send a Data Message for transmission.
" Start Request
Used to activate a link.
" Stop Request
Used to deactivate a link.
! Primitives sent from M2PA to MTP3:
" Data Indication
Used to deliver received Data Message to MTP3.
Only two messages are defined for peer-to-peer messaging at the M2PA layer:
! User Data messages convey data received by the M2PA layer from MTP3.
Specifically, they contain the following fields of the MTP MSU:
" Length Indicator (LI), including the two undefined bits between the SIO and
LI fields
Note: M2PA does not actually require message length information as MTP2
does. The LI octet is included because the two spare bits in the LI octet are
used by some national CCS7 variants to carry MTP3 information.
" Service Information Octet (SIO)
" Signaling Information Field (SIF)
M2PA User Data messages do not convey other components of the MTP MSU. In
particular, they do not convey MTP3 sequence numbering data, because M2PA
message headers contain a Forward Sequence Number (FSN) and Backward
Sequence Number (BSN) assigned at the M2PA layer.
! Link Status messages are sent between M2PA peers to indicate link status, thus
performing a function similar to that of MTP2 Link Status Signal Units (LSSU).

Chapter D13 DSM-CC
D13.1 Purpose
The Digital Storage Media Command and Control (DSM-CC) protocol is a toolkit for
developing control channels associated with MPEG-1 and MPEG-2 streams. In ISN07,
CS2000 solutions use DSM-CC to support:
! Remote Access Service (RAS) sessions for the transport of packet data to/from
private intranets and the public Internet
Note: DSM-CC is capable of supporting a wide variety of other media handling
functions, e.g. for controlling video reception via features equivalent to those
provided by VCR units (fast-forward, rewind, pause and so on), but these are not
used in CS2000 solutions in ISN07.
! VoIP calls
DSM-CC uses a client/server model connected via an underlying network (carried either
via the MPEG-2 multiplex or independently). It is defined in a series of standards, of
which the most important is MPEG-2 ISO/IEC 13818-6, i.e. Part 6 of the MPEG-2
standard: Extensions for DSM-CC.
In the CS2000 network architecture, DSM-CC Version 5.2 signalling is used between a
CS2000 GWC and a CVX1800 media gateway providing Universal Port capabilities, i.e.
supporting both RAS and VoIP for incoming calls over IUP/BTUP or UK ISUP.
DSM-CC Version 5.2 is used to instruct the CVX what media handling capabilities to
provide for each incoming call, e.g. to process each incoming RAS call by demodulating
it on one of the CVX modem resources.

DSM-CC Packet Telephony Protocols Communication Server Capabilities
D13.2 Network Role

CS2000 uses the CVX1800 media gateway described in section B2.11 on page 130 to
provide Universal Port (UP) capability. This means supporting RAS (Remote Access
Service) as well as VoIP voice calls. RAS means support for dial-up access to internet
and/or intranet sessions.
Note: CS2000 support for Universal Port capabilities has been tested and verified for
deployment only in a specific customer network, and is not generally available in ISN07.
tell the CVX1800 to terminate the call on one of its modem ports, and to specify the
internet / intranet destination (IP address and port number) with which a data session
should be initiated.
Figure 84 illustrates the network role of DSM-CC in supporting RAS calls. Its role in
supporting VoIP calls is essentially the same, the main difference being that the call
destination for VoIP is a terminating media gateway, not a server within the packet
network.
CCS7 signalling CS2000

Packet network control signalling Call processing
TDM bearer channels Access

CCS7 GWC for
Signalling
Packet network bearer connections gateway;
Gateway
(SG) Ingress
TDM-side
GWC-gateway
signalling
(DSM-CC) IP
core
PSTN CCS7 network
signalling
(IUP / ISUP)
Intranet data session
PSTN CVX1800
PSTN bearer channel RAS
media
gateway
Internet data session
Internet
Figure 84: Network role of DSM-CC in supporting RAS
See Chapter F17: RAS (Remote Access Service) for further information about CS2000
support for RAS.

Communication Server Capabilities Packet Telephony Protocols DSM-CC

DSM-CC messages are divided into functional categories. Within each category, each
message has a name that indicates not only its function but also its class, i.e. the direction
in which it is sent and whether it is a notification of action or a response to such
notification, as follows:
! message-nameIndication
Notification of action sent by CS2000 to CVX1800
! message-nameResponse
Acknowledgement (of Indication) sent by CVX1800 to CS2000
! message-nameRequest
Notification of action sent by CVX1800 to CS2000
! message-nameConfirm
Acknowledgement (of Request) sent by CS2000 to CVX1800
The remainder of this section lists DSM-CC message categories and the messages
belonging to each one.
Client Session Setup messages (UP Call Setup, i.e. RAS and VoIP)
ClientSessionSetupIndication
ClientSessionSetupResponse
ClientSessionSetupRequest
ClientSessionSetupConfirm
Client Update Messages (VoIP Call Setup)

ClientUpdateIndication
ClientUpdateResponse
Client Release Messages (UP Call Release, i.e. RAS and VoIP)
ClientReleaseIndication
ClientReleaseResponse
ClientReleaseRequest
ClientReleaseConfirm
Client Configuration Messages (Gateway Maintenance and Initialisation)

ClientConfigIndication
ClientConfigResponse (CVX1800 to CS2000, indicating card RTS)
ClientConfigRequest
ClientConfigConfirm
ClientConfigDetailIndication (CS2000 to CVX1800, requesting TID state alignment)
ClientConfigDetailResponse
ClientConfigHeartBeatIndication
ClientConfigHeartBeatResponse
ClientConfigDetailFragIndication (not supported for CS2000 solutions)

DSM-CC Packet Telephony Protocols Communication Server Capabilities
Client Connect Messages

Note: Not supported for CS2000 solutions.
ClientConnectRequest
ClientConnectConfirm
Client Status Messages

Note: Not supported for CS2000 solutions.
ClientStatusIndication
ClientStatusResponse
D13.4 Co-Ordination between DSM-CC and CCS7

Signalling
The following list summarises the use of DSM-CC messages in session initiation and
sesion termination, illustrating the co-ordination betwen DSM-CC and CCS7 signalling:
! Session initiation
1 When an incoming IAM is received by CS2000 for an incoming CCS7 trunk
terminated on a CVX1800, the CS2000 GWC sends the CVX1800 gateway a
DSM-CC CSSI (Client Session Setup Indication) command, requesting the
gateway to initiate a session with a specified packet network destination (IP
address and port number). For a VoIP call, the destination will be a
terminating media gateway. For a RAS call, the destination will be a remote
internet or intranet server accessible via the packet network.
2 The CVX1800 responds to the CSSI by sending a DSM-CC CSSR (Client
Session Setup Response) command back to the CS2000 GWC.
3 CS2000 responds to the CSSR by sending back an ACM and ANM over the
incoming CCS7 trunk on which the call originated.
! Session termination
1 When an incoming REL is received by CS2000 for an incoming CVX1800
CCS7 trunk on which there is an active call, CS2000 responds by sending
back an immediate RLC to complete call clearing.
2 The CS2000 GWC then sends the CVX1800 gateway a DSM-CC CRI
(Client Release Indication) command, requesting the gateway to terminate the
current session with the terminating media gateway or remote server.
3 The CVX1800 responds to the CRI by terminating the session and sending a
DSM-CC CRR (Client Release Response) command back to the CS2000
GWC.

Communication Server Capabilities Packet Telephony Protocols DSM-CC
! Overload control
The CVX1800 uses DMS-CC CCHR (ClientConfigHeartbeatResponse) and CCR
(ClientConfigResponse) messages to keep the GWC informed about the availability
If no RAS modems are available, the GWC will not initiate any new RAS calls, but
can continue to initiate VoIP calls. Similarly, if no VoIP modems are available, the
GWC will not initiate any new VoIP calls, but can continue to initiate RAS calls. If
no front-end processor is available, no new calls of either type will be initiated.
received by a CVX1800, CS2000 indicates this by sending back an REL message
with a release cause of CI_TEMPORARY_FAILURE (for a UK ISUP call) or

Chapter D14 OAM&P Protocols
The primary purpose of the chapters in Part D of the CS2000 Product Description is to
provide brief functional overviews of each of the IP protocols used in setting up and
controlling various types of call or session across the packet network. For completeness,
this chapter provides similar overviews of the IP protocols used for OAM&P purposes.
These are:
! SNMP (Simple Network Management Protocol), which is described in section
D14.1 on page 348.
! The complementary configuration protocols BOOTP (Bootstrap Protocol), DHCP
(Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol),
which are described in section D14.2 on page 352.

Communication Server Capabilities Packet Telephony Protocols OAM&P Protocols
D14.1 SNMP (Simple Network Management Protocol)

D14.1.1 Overview
SNMP is the protocol used for communication between most CS2000 network elements
and their EMs, e.g. between GWCs and the GWC EM. CS2000 EMs are server
applications that reside on the OAM&P VLAN of the CS2000 CS LAN. This VLAN has
trusted access to the call processing VLAN. The clients for CS2000 EMs do not have
direct access to the functional network elements controlled by those EMs, and can access
those elements only via their EMs.
SNMP enables operations to be performed on a collection of variables known as the
Management Information Base (MIB). There is a standard set of core SNMP MIB
variables, but this can be extended with vendor-specific and/or network-specific
variables. The MIB allows information about the functions, characteristics and status of
network elements to be captured in a standard structure and maintained. Up-to-date
information can be provided to network management workstations in response to
requests, and management and maintenance operations can be initiated from management
workstations by specifying changes to be applied to MIB variables.
Two types of SNMP communication are supported, as shown in Figure 85 on page 349:
! SNMP requests and responses are exchanged between EMs and EM clients.
! The SNMP Distributed Program Interface (DPI) allows requests and responses to
be exchanged between EMs and the network elements they control. Some of these
are equivalent to the SNMP requests and responses exchanged between EMs and
EM clients; in effect, they allow EMs to relay requests for information and
operations from network management workstations to network elements. Other DPI
requests allow a network element to provide the EM with information about itself
when a connection is opened between them.
The SNMP process that runs on the network element is referred to as a sub-agent.
Network management workstations communicate only with the SNMP agent, i.e. the EM,
and can thus control multiple network elements. They need not communicate directly with
individual network elements, and are not aware of the existence of sub-agents.
SNMP uses a simplified subset of ASN.1 to define the characteristics of managed objects
and to specify the protocol data units conveyed in SNMP requests in order to manage
those objects. Overall, the MIB data model has a hierarchical structure branching down
from a single root. The part of the model used to store information about a particular type
of network element is known as a MIB tree or sub-tree.

OAM&P Protocols Packet Telephony Protocols Communication Server Capabilities
Figure 85 illustrates the network role of SNMP and the SNMP DPI. Communication
between the GWC, the GWC EM server application, and the GWC EM client is used as
an example, but the same configuration and principles apply to the management of other
network elements.
SNMP SNMP DPI
Network management EM, Network element,

workstation e.g. GWC EM e.g. GWC
Open
SNMP-based SNMP process on EM Register SNMP process on
EM client (SNMP agent / network element
(command generator) command responder) (SNMP sub-agent )
Get
GetNext Get
GetBulk GetNext
Set Set
Client platform, Server platform,
e.g. Windows PC NE hardware,
GetResponse e.g. Sun Netra 240 Response e.g. GWC card
Note: To simplify the diagram,

not all DPI requests are shown.
NOC LAN OAM&P VLAN of Call processing VLAN

(access only to EMs, CS2000 CS LAN of CS2000 CS LAN
not to network (trusted access to (functional network
elements) network elements) elements)
Figure 85: Logical network role of SNMP

D14.1.2 SNMP Requests and Responses

D14.1.2.1 Connection Establishment and Termination
To enable SNMP management of a network element to take place, a logical connection
must exist between the SNMP sub-agent on that element and the SNMP agent (EM). The
requests used to control such logical connections are:
OPEN Sent by network element to initialise the logical connection with the SNMP
agent after the UDP transport connection has been set up. The OPEN request
uniquely identifies the sub-agent and passes some operational parameters to
the agent, e.g. the timeout the agent should use when waiting for a response
from the sub-agent.
The SNMP agent responds to DPI OPEN requests with a RESPONSE
indicating success or failure.
CLOSE When the sub-agent prepares to stop or cease operations, it first issues a
CLOSE to shut down the logical connection with the agent, then closes the
transport connection.
A CLOSE implicitly serves as an UNREGISTER request (see section
D14.1.2.2) for all registrations that exist for the DPI connection being closed.
The CLOSE packet is simply accepted by the agent. It closes the physical DPI
connection without sending a response.
The SNMP agent can also send a CLOSE request to a network element to
indicate that it is terminating the DPI connection.
ARE_YOU_THERE
A sub-agent can send an ARE_YOU_THERE request to verify that the logical
connection with the SNMP agent is still open. If so, the agent sends a
RESPONSE indicating no error.
D14.1.2.2 Registration
A sub-agent supports a collection of MIB variables or object identifiers (object IDs) that
constitute its MIB (sub)tree. Each object ID consists of a group ID and an instance ID.
The group ID is the root of a MIB sub-tree, and is the point of registration for that MIB
sub-tree in the SNMP agent's MIB tree. The instance ID is simply the piece of the object
ID that follows the group ID (registration point); it is not an instance in terms of the SNMP
definition of an instance.
REGISTERAfter sending an OPEN request to initialise the logical connection to the
SNMP agent (EM), as described in section D14.1.2.1, the sub-agent on a
network element sends one or more REGISTER requests to register its MIB
sub-tree(s) in the agent's MIB tree. With each registration request, the
sub-agent passes parameters such as requested priority and timeout value for
the sub-tree being registered.
The agent sends back a RESPONSE to indicate success or failure of each
registration request.
After successful registration, the sub-agentwaits for requests from the SNMP
agent or generates traps as required.
UNREGISTER
If the sub-agent wants to terminate management of a particular MIB sub-tree,
it sends a DPI UNREGISTER request to the SNMP agent. The agent sends a
response to each UNREGISTER request.
The SNMP agent may also send a DPI UNREGISTER request, e.g. if a
higher-priority registration comes in. The sub-agent sends a RESPONSE.

D14.1.2.3 Obtaining Information from Network Elements

The following requests may be sent by a network management workstation to obtain
network element information:
! GET
! GETNEXT
! GETBULK
GET and GETNEXT requests are relayed to the network element in question by the
SNMP agent (EM). A GETBULK request is relayed as a series of GETNEXT requests.
The information required is indicated by object IDs in ASN.1 notation.
The SNMP sub-agent on the network element responds to an information request by
returning a RESPONSE request. This conveys a string representing the object ID in
ASN.1 notation, plus the type, value length and current value of the object.
D14.1.2.4 Updating Network Element Information

The SNMP request sent by a network management workstation to update network
element information is SET, which is relayed to the network element by the SNMP agent
(EM). This conveys a string representing the target object ID in ASN.1 notation, plus the
type, value length and value to be assigned to the object.
The SNMP agent uses a two-phase commit scheme to confirm updates. After relaying a
SET request, the agent sends a DPI COMMIT request to the SNMP sub-agent on the
network element to confirm that the update is to be applied.
In the event of a problem, the SNMP can send a DPI UNDO request to cancel an update.
The SNMP sub-agent on the network element responds to a SET request by returning a
RESPONSE request. This conveys a string representing the object ID in ASN.1 notation,
plus the type, value length and new value of the object.
D14.1.2.5 Problem Reporting

Sent by network element to report a problem:
TRAP If the SNMP sub-agent on a network element needs to report an important
state change, it sends a DPI TRAP request to the SNMP agent. The agent
encodes it into an SNMP TRAP request and relays it to the network
management workstation. No information is returned to the sub-agent when
the agent accepts and forwards the TRAP request.

D14.2 Configuration Protocols (BOOTP, DHCP, TFTP)

D14.2.1 Introduction
This section describes the DHCP / BOOTP and TFTP protocols together because they are
complementary. They are used for the dynamic configuration of hardware units when they
are brought into service.
The unit being initialised uses BOOTP (Bootstrap Protocol) or DHCP (Dynamic Host
Configuration Protocol) to send an automated request to a server, which responds by
providing the name of a configuration file and the address from which it can be
downloaded. The unit then uses the TFTP (Trival File Transfer Protocol) to download the
configuration data it requires.
The main difference between BOOTP and DHCP is that DHCP can assign addresses for
a specified period rather than permanently. It is therefore appropriate for CPE units that
are allocated IP addresses from an address pool when required.
The IP addresses and other characteristics of the following CS2000 components are
assigned via BOOTP and TFTP servers on the CS LAN (CBM server or SDM platform):
! GWCs
! SAM21 SCs
! UAS
The IP addresses and other characteristics of some line media gateways are configured via
DHCP and TFTP servers, which are typically located in an access network rather than on
the CS LAN. See section D14.2.2 for further information.

D14.2.2 Line Media Gateway Configuration

GWCs and small CPE line media gateways obtain each others address information
dynamically. Details of the method used vary depending on the gateway type and on how
the CS2000 network has been designed to operate, but the basic sequence of events is:
5 Line media gateway sends the specified GWC an RSIP (Restart In Progress)
message to initiate registration. Depending on the gateway type and the
device/media control protocol in use, the GWC does one of the following:
" For a customer LAN gateway controlled via MGCP, the IP address provided
in the downloaded configuration file is that of an Audio GWC configured to
provide RMGC (Redirecting MGC) functionality. This responds to the RSIP
by sending back an MGCP message specifying the name and IP address of the
GWC that will actually control the gateway. The gateway then sends another
RSIP to the correct GWC.
GWC support for RMGC functionality is new in ISN07, and is described in
A89008489. It requires the GWC to maintain a local copy of the MG-to-MGC
mapping database, instead of querying the central network view database.
" For a cable gateway controlled via NCS, the IP address provided in the
configuration file is that of the correct GWC. On receipt of the RSIP, this
GWC contacts a central DNS (Domain Name Server) supporting mapping
between FQDNs (Fully Qualified Domain Names) and IP addresses. This
returns the IP address to use for the line media gateway in response to the
GWCs query specifying its FQDN. See section C2.8.3 on page 201 for a
more detaileed description.
DHCP and TFTP servers are not CS2000 components, and their type and location are a
matter for the network operator. Typically, they will be located remotely from the CS2000
at a point where traffic to/from many line media gateways is aggregated. Similarly, the
way in which DNS functionality is provided is a matter for the network operator.

D14.2.3 BOOTP (Bootstrap Protocol)

The Bootstrap Protocol allows a host to configure itself dynamically at boot time by
requesting configuration information from a central BOOTP server, typically on the same
LAN. It provides three specific services for BOOTP clients:
! IP address assignment
! Detection of the IP address for a serving machine
! The name of a file to be loaded and executed by the client machine
The protocol is defined in RFC951 and RFC1542.
BOOTP was developed to simplify configuring parameters on a pool of networked
equipment. Parameters are mainly IP-specific, but BOOTP is not limited to IP-specific
parameters. Equipment supporting BOOTP can request configuration information from a
central BOOTP server. Because groups of clients on a LAN segment normally have the
same configuration parameters except the IP address itself, the software is based on
profiles, where a profile is a set of configuration parameters for a group of clients. The
profile for a client is selected based on one of the following criteria:
! A known client identifier
! A known client hardware address
! The server interface receiving the client request
Note: BOOTP is designed only for delivering configuration information to a client, not
for remotely booting a client, i.e. it can tell the client the name and location of a boot
image, but requires another protocol to be used for downloading the image. This other
protocol is typically the Trival File Transfer Protocol decribed in section D14.2.5.
The IP addresses and other characteristics of some CS2000 components accessible via the
CS LAN are configured via a BOOTP server on the CS LAN. These include:
! GWCs
! SAM21 SCs
! UAS
BOOTP is a simple protocol with only two messages:
! BOOTREQUEST
Broadcast message sent by client at boot time. Message specifies hardware type of
client and provides client IP address and hardware address.
! BOOTRESPONSE
Message sent by server in response to BOOTREQUEST from client. Message
specifies name and location of boot file, and may also provide vendor-specific
information for client hardware.
See section D14.2.4 for information about DHCP (Dynamic Host Configuration
Protocol), which is effectively BOOTP enhanced to support the dynamic assignment of
IP addresses for a specified period rather than static IP address assignment.

D14.2.4 DHCP (Dynamic Host Configuration Protocol)

DHCP is used in CS2000 solutions (together with TFTP) to support the configuration of
IP addresses and other characteristics for small line media gateways, which are typically
located on customer premises. It is similar to the BOOTP protocol described in section
D14.2.3, but incorporates two specific enhancements:
! DHCP defines mechanisms through which clients can be assigned a network
address for a finite lease, allowing for serial reassignment of network addresses to
different clients. Second, DHCP provides the mechanism for a client to acquire all
of the IP configuration parameters that it needs in order to operate.
! DHCP introduces a small change in terminology intended to clarify the meaning of
one of the fields. What was the "vendor extensions" field in BOOTP has been
re-named the "options" field in DHCP. Similarly, the tagged data items that were
used inside the BOOTP "vendor extensions" field, which were formerly referred to
as "vendor extensions," are now referred to simply as "options".
The protocol is defined in RFC2131.
In functional terms, the protocol operates in the same way as BOOTP, and has only two
messages: DHCP_DISCOVER (request configuration information) and DHCP_OFFER
(provide configuration filename and address).
D14.2.5 TFTP (Trivial File Transfer Protocol)

TFTP complements the BOOTP and DHCP protocols (described in sections D14.2 and
D14.2.4 respectively) by allowing a BOOTP/DHCP client to download a boot image
whose filename and location has been obtained by means of a request / response sequence.
The protocol is defined in IEN133 and RFC1350. Use of TFTP in bootstrap downloading
is described in RFC906.
The sequence of events is:
1 Client uses BOOTP or DHCP to obtain IP address of TFTP server and filename of
boot image.
2 Client uses TFTP to request TFTP server to download boot image.
3 Client executes boot image and sends a RSIP (Restart In Progress) message to its
controller to indicate that it is available.
TFTP comprises six message types:
! RRQ (Read request)
! WRQ (Write request)
! DATA (read or write the next block of data)
! ACK (Acknowledgment)
! ERROR (Error message)
! OACK (Option acknowledgment)

Part E
Chapter E1 Part E CS2000 International Product Description
Overview Telephony Interfaces Communication Server Capabilities
Chapter E1 Overview of Support for

The telephony interfaces supported by CS2000 can be divided into a number of functional
categories. Summarised descriptions of these different interface types are provided in
sections E1.1 to E1.6. Each interface is then described in detail in a separate Part E
chapter. CS2000 supports the following interface types:
! CCS7 trunk interfaces (see section E1.1 and Chapter E2: CCS7 Interfaces)
" ISUP (ISDN User Part) variants
" TUP (Telephony User Part) variants
! Intelligent Network (IN) interface (see section E1.2 and Chapter E3: INAP)
" Intelligent Network Application Part (INAP)
! PBX access interfaces (see section E1.3 and Chapter E4: PRI Access Interface)
" ISDN Primary Rate Interface (PRI) variants
! VPN interfaces (see section E1.4)
" QSIG interface (see Chapter E5: QSIG VPN Interface)
" UK-specific DPNSS interface (see Chapter E6: DPNSS Interface)
! Line interfaces:
" Basic analogue subscriber lines (see section E1.5 and Chapter E7: IBN Lines)
# Lines supported via media gateways attached to cable access networks
# Lines supported via media gateways attached to customer LANs
# Lines supported via large carrier-located media gateways
# Lines supported via V5.2 Access Networks (ANs)
" CentrexIP lines (see section E1.6 and Chapter E8: CentrexIP Lines)
A matrix summarising the supported interworkings between the telephony interfaces
supported in ISN07 is provided in section A3.4 on page 25. See section E1.7 on page 364
for a discussion of what is involved in supporting interworkings between telephony
interfaces in a packet network environment.

CS2000 International Product Description Part E Chapter E1
Communication Server Capabilities Telephony Interfaces Overview
E1.1 CCS7 Trunk Interfaces

This section provides only a summary; see Chapter E2: CCS7 Interfaces for details.
Note: For each ISUP and TUP variant listed, CS2000 supports both a TDM-side
implementation (for access to the backbone packet network, e.g. from the PSTN) and a
packet-side implementation (for inter-CS signalling via SIP-T). In general, the
capabilities and interworkings supported by the two implementations of a given CCS7
interface are identical; any exceptions are noted explicitly.
! ETSI / ITU ISUP trunk interface
ISUP is an open interface for interconnecting networks and telephony switches that
may have different characteristics and capabilities. Although initially designed for
international interconnections between national networks, it is equally suitable for
interconnecting networks within a national regulatory regime, e.g. between an NLO
network and the national PSTN, and for use as an intra-network signalling system.
There are several versions (iterations) of the ITU and ETSI ISUP specifications,
each of which is supported by a different call processing agent on CS2000:
" ETSI ISUP Version 1 / CCITT (ITU) Blue Book ISUP
ETSI ISUP V1 is the subject of ETS 300 121 (1992), but this ETS merely
endorses the text of CCITT Recommendation Q.767 (1991) without any
modification. Q.767 defines ISUP in relation to CCITT Recommendations
Q.761 to Q.764 (1988, Blue Book).
CS2000 supports base/generic ETSI ISUP V1 plus national variants for:
- Brazil
- Czech Republic
- Denmark
- Italy
- Mexico (Telmex sub-variant also supported)
- Norway
- Portugal
- Spain
- Turkey
CS2000 also supports Malaysia ISUP V1, but this is implemented as a variant
of the IBN7-based AISUP agent, not as a variant of ETSI ISUP V1.
" ETSI ISUP Version 2 / ITU White Book
ETSI ISUP V2 is defined in ETS 300 356-1 (1995). This ETS is a very small
delta to ITU-T Recommendations Q.761 to Q.764 (1993, White Book).
CS2000 supports base/generic ETSI ISUP V2 plus national variants for:
- Belgium
- Chile
- China
- Germany (DTAG Gateway ISUP and Transit ISUP as well as German
ETSI ISUP V2)
- Hong Kong
- India
- Israel (civil and defence variants)
- Italy
- Russia
- Singapore
- Spain

- Sweden
- Turkey
Note: The CS2000 implementation of ETSI ISUP V2 is sometimes referred
to as V2+ because it supports some ETSI ISUP V3 capabilities.
ETSI ISUP V2 is also used as the base for ISUP variants used in:
# Australia:
$ ACIF G.500 Interconnect ISUP (I-ISUP)
$ Telstra CA30 ISUP, for use within the Telstra network
# Japan:
$ JI-ISUP (Japanese Interconnect ISUP), the interconnect standard
" ETSI ISUP V3 / ITU ISUP 97
These are backwards-compatible extensions to ETSI ISUP V2 / ITU White
Book, designed to support additional services such as feature transparency.
CS2000 implements ETSI ISUP V3 capabilities by providing datafill that
allows V3 services to be activated and supported by the ETSI ISUP V2 agent
(a capability sometimes referred to as ETSI ISUP V2+).
CS2000 does not support base/generic ETSI ISUP V3, but does support
national variants for:
- UK (UK ISUP)
- France (SPIROU)
In both cases, the V3 variant is intended as a replacement for an existing TUP
interconnect interface.
! IBN7 ISUP trunk interface (IBN stands for Integrated Business Network)
Enhanced ANSI ISUP, which is referred to as ANSI ISUP+ or IBN7, is a
proprietary implementation of ANSI ISUP, with extensions to support proprietary
features such as Networked Centrex. The primary role of IBN7 is to link CS2000s
to support networked services for business users.
ANSI ISUP is the North American standard for ISUP, as defined in ANSI
specification T1.113.1-4. Like the ITU and ETSI ISUP specifications, the ANSI
ISUP specification has undergone several revisions, with each successive version
incorporating new optional capabilities while remaining backwards-compatible
with previous versions. CS2000 can support many of these optional capabilities,
which are configured individually rather than being implicitly activated by
datafilling a specific version of ANSI ISUP.
Note: The IBN7 interface is not suitable for general use for interconnect to North
American LECs or IXCs. These interfaces generally require use of refinements of
ANSI ISUP defined by Telcordia (previously Bellcore), which add additional
service signalling capabilities not included in the ANSI ISUP specification. The
North American versions of the CS2000 and DMS product lines do fully support
these interfaces, and can interwork with the International CS2000 via IBN7 trunks.

! North American Feature Group D ISUP (FGD ISUP)

USA Feature Group D ISUP can be used in North America to support IXC
(Inter-Exchange Carrier functionality), i.e. communication with both Local
Exchange Carriers (LECs) and Inter-Exchange Carriers (IECs). FGD ISUP
supports not only basic CCS7 interconnection between networks, but also a set of
Equal Access features that allow subscribers to choose which carriers to use for
their calls.
Subscribers connected to the North American PSTN can use FGD ISUP to access
an alternative carriers network and services. Similarly, users outside North
America can be routed through such a network to terminate (via FGD ISUP) in the
North American PSTN.
The FGD ISUP protocol is based on the ANSI T1.113 ISUP specification, but also
includes additional IAM parameters that are either not included or defined as
optional in ANSI ISUP. FGD ISUP is defined by GR-317-CORE, Telcordia and
GR-394-CORE Telcordia.
The FGD ISUP protocol and its message flows are very similar to those of the IBN7
(ANSI ISUP+) interface.
! IUP / BTUP trunk interface
The UK Interconnect User Part (IUP) is a publicly owned version of the British
Telephony User Part (BTUP). It is being standardised by a committee under the
control of Oftel, and is in the process of superseding BTUP as the UK national
CCS7 standard for inter-network and intra-network connections between switches.
It is to be superseded by the UK ISUP variant of ETSI ISUP V3.
! SSUTR2 / FTUP trunk interface
The French Telephony User Part (FTUP) is the French national variant of CCS7
TUP as defined in ITU-T Recommendation Q.723. SSUTR2 is the French acronym
for FTUP. FTUP is the French national CCS7 standard for inter-network and
intra-network connections between switches. It is to be superseded by the SPIROU
variant of ETSI ISUP V3.
! Chinese TUP trunk interface
The Chinese Telephony User Part (CTUP) is the Chinese national variant of CCS7
TUP as defined in ITU-T Recommendation Q.723. It comprises a subset of Q.723
messages plus some China-specific messages.
E1.2 Intelligent Network Interfaces

This section provides only a summary; see Chapter E3: INAP for details.
! INAP IN trunk interface
The Intelligent Network Application Part (INAP) is used for peer-to-peer
communication between IN functional elements. The CS2000 SSP uses it to support
IN queries from the CS2000 SSP to an SCP across a CCS7 signalling network,
typically to allow IN service logic to be involved in call completion. INAP operates
at Layer 7 of the OSI 7-layer model, on top of a Blue Book or White Book TCAP
protocol stack.
Note: INAP cannot be conveyed across the backbone packet network in ISN07.
TCAP NCAS (Non Call Associated Signalling) is supported across the packet
network between peer CS2000s, but not between a CS2000 and an SCP.

E1.3 Access Interfaces

This section provides only a summary; see Chapter E4: PRI Access Interface for details.
The ISDN Primary Rate Interface (PRI) supports 30B+D network access via E1 carriers
(30 64Kb/s B-channels for voice/data and a 64Kb/s D-channel for signalling), and 23B+D
network access via T1 carriers. It is used primarily for point-to-point communication
between digital PBXs and CS2000 media gateways, but can also be used to support other
PRI-enabled devices such as IN Intelligent Peripherals (IPs).
ISDN PRI call control signalling is defined in Q.931 or a specification derived from
Q.931, such as the ETSI PRI standard ETS 300 403.
CS2000 supports base/generic ETSI PRI plus several national PRI variants.
National PRI variant Characteristics

Specification based on Q.931;
China 30B+D
implementtation based on ETSI PRI
Hong Kong (CS13) 23B+D Specification based on Q.931
Japan (INS1500) 23B+D Specification based on Q.931
Spain 30B+D Specification and implementation based on ETSI PRI
USA (ANSI PRI) 23B+D Defined in ANSI specification T1.607 (1990).

E1.4 VPN Interfaces

This section provides only a summary; see Chapter E5: QSIG VPN Interface and
Chapter E6: DPNSS Interface for details.
! QSIG VPN interface
QSIG is an ISDN network signalling system for peer-to-peer communication
between PBXs and/or switches. As an open interface, it can be used to link different
node types in a multi-vendor network. It can be used within a private network, or to
support Virtual Private Network (VPN) capabilities within a public network. QSIG
is also referred to as Private Signalling System No.1 (PSS1).
QSIG is so called because it specifies protocol requirements at the Q reference point
in the ISDN model. The Q reference point exists within a QSIG PINX. It defines the
mapping between QSIG signalling (at and above Layer 3 in the OSI model) and the
chosen Layer 2.
QSIG does not specify which Layer 1 and Layer 2 implementations should be used
to convey QSIG signalling between PINXs. However, QSIG basic call procedures
and the messages used to support them are very similar to those of PRI (Q.931 /
DSS1). For this reason, Nortel and other equipment vendors use PRI Layer 2
(Q.921) and PRI Layer 1 (ETS 300 011) as the Signalling Carriage Mechanism
(SCM) for QSIG signalling.
When used to support VPN (Virtual Private Networking), in which shared public
network trunks are used connect remote private networks, or to provide additional
capacity on demand when the dedicated private circuits of a corporate network are
busy, QSIG signalling is conveyed via QSIG Feature Transparency (QFT). QFT
uses the ETSI ISUP V3 APM (Application Transport Mechanism) to encapsulate
and convey any service-related QSIG signalling that cannot be directly interworked
to ISUP. This enables services to be supported end-to-end even if the corresponding
signalling has to be routed via nodes that do not support QSIG functionality.
! DPNSS VPN interface
DPNSS is a common channel signalling system for peer-to-peer communication
between digital PBXs and/or switches. It can be used within a private network, or
to support VPN capabilities within a public network; calls originating from the
PSTN can be routed via a DPNSS private network to terminate back on the PSTN.
As a UK standard interface, DPNSS can be used to link different node types in a
multi-vendor network.
For CS2000 solutions, DPNSS is supported via the Westell InterChange iQ2030
Series gateways. An iQ203x gateway provides one or two E1 carrier connections to
support DPNSS links with customer PBXs, and provides a 10/100BaseT Ethernet
connection with the packet network. It is controlled by a CS2000 GWC using
H.323. DPNSS signalling is tunneled over H.323 using Westell-defined
manufacturer-specific operations.
When used to support VPN, DPNSS signalling is conveyed via DPNSS Feature
Transparency (QFT). DFT uses IBN7 DFT (DPNSS Feature Transparency) trunks
for peer-to-peer connections. The mechanism used for transparent carriage of
information through transit nodes is the Network Transport Parameter (NTP)
defined in ANSI ISUP, which conveys the Nortel proprietary Hybrid Network
Information Parameter (HNIP).

E1.5 Basic Analogue Subscriber Line Interfaces

This section provides only a summary; see Chapter E7: IBN Lines for details.
The IBN line interface supports access to a CS2000 network for an individual subscriber.
In ISN07, the capabilities provided are equivalent to those available to conventional
POTS (Plain Ordinary Telephone Service) lines serving DTMF telephone sets. IBN
(Integrated Business Network) lines are so called because this is how they are datafilled
at the CS2000, and because they can be assigned a wide range of value-added services that
were originally developed for the use of business customers.
Basic signalling information is conveyed from the subscribers telephone set towards the
network by means of in-band signalling using DTMF tones or standard POTS electrical
signals. Signalling received by the subscribers telephone (tones, announcements and
standard POTS electrical signals) is also in-band.
In ISN07, CS2000 supports a number of different analogue subscriber line
implementations, as follows:
! Lines supported via large carrier-located media gateways.
! Lines supported via media gateways attached to customer LANs
! Lines supported via media gateways attached to cable access networks
! Lines supported via V5.2 Access Networks (ANs).
From an end user perspective, these offer essentially the same capabilities, but there are
significant differences between them in terms of access network architecture and the
protocols used by CS2000 to support line access.
E1.6 CentrexIP Lines

This description of CS2000 support for CentrexIP lines is only a summary; see Chapter
E8: CentrexIP Lines for details.
! Etherset clients
! Soft clients
a screen-based GUI.
gateways.
Each CICM subtends and is controlled by a CS2000 GWC. The GWC in turn
communicates with the CS2000 Core, which supports call processing for CentrexIP
clients as if they were legacy business sets controlled via the proprietary P-phone
interface.

E1.7 Interworking in a Packet Network Environment

E1.7.1 Interworking Issues
Interworking in a packet network environment is more complex than in a TDM network
environment because of the separation between signalling channels and bearer
connections. Interworking between call-processing agents takes place at the CS2000, but
bearer connections are through-connected by media gateways. Co-ordination between
interworked signalling and through-connected bearer connections is achieved by means
of GWC-gateway signalling across the packet network. (For TDM networks, the only
similar separation occurs in quasi- or non-associated CCS7 networks based on STPs, but
in this case the backbone network signalling is homogenous and interworking is not in
fact required.)
The interworking matrix in section A3.4 on page 25 summarises which interworkings
between call-processing agents are supported at the CS2000. This section discusses the
additional issues that arise because of the separation between signalling channels and
bearer connections.
There are two possible interworking scenarios for the handling of any given interworked
TDM call by CS2000:
! Incoming TDM half-call and outgoing TDM half-call are both served by media
gateways controlled by GWCs on the same CS2000. Only one interworking takes
place.
! Incoming TDM half-call arrives at a media gateway controlled by a GWC on an
originating CS2000, is interworked, and is then routed as an outgoing SIP-T call
across the packet network (via a DPT GWC and Session Server) to a different
CS2000. The call arrives at the second CS2000 as an incoming SIP-T packet
network call, is interworked, and then terminates on a media gateway controlled by
a GWC on the terminating CS2000. In this case, two interworkings take place, but
only one needs to be considered, as the packet/circuit interworking at the
terminating CS2000 is the mirror image of the circuit/packet interworking at the
originating CS2000. No more than two media gateways are ever required to handle
a basic two-party call.
Note: Because different documents use similar terminology to denote different
things, it is important to distinguish between the outward-looking nodal view of a
networked call, as seen by a transit/interworking CS2000, and the network view of
a call. A transit CS2000 sees the incoming half-call as a call origination and the
outgoing half-call as a call termination. From a network perspective, however, a call
between two CS2000 originates at one CS2000 (where the outgoing call attempt is
perceived as a call termination) and terminates at the other (where the incoming call
attempt is perceived as a call origination).

E1.7.2 Connectivity and Signalling Interworking for Selected Call Types

The figures on the following pages illustrate the connectivity and signalling interworking
requirements for four basic VoIP or VoATM call types supported by CS2000 in ISN07:
! CCS7-to-CCS7 call between two media gateways controlled by the same CS2000
(see Figure 86 on page 366)
! PRI-to-PRI call between two media gateways controlled by the same CS2000 (see
Figure 87 on page 366)
! CCS7 call networked via SIP-T to a different CS2000 (see Figure 88 on page 367)
! PRI call networked via SIP-T to a different CS2000 (see Figure 89 on page 367)
The call types illustrated are a subset of the call types supported by CS2000. The set of
examples is not intended to be exhaustive, only to illustrate the main issues involved.
The connectivity and signalling interworking requirements for most other call types can
be inferred from those illustrated, as summarised in the table below.
Figure to use
Interface Call type Modification(s)
as base
Figure 87 on Substitute QSIG for PRI at the top level of the
Intra-CS2000
page 366 PRI / IUA / SCTP / IP protocol stack
QSIG
Networked Figure 89 on Substitute QSIG for PRI at the top level of the
via SIP-T page 367 PRI / IUA / SCTP / IP protocol stack
Substitute V5.2 for PRI and V5UA for IUA at the
Intra-CS2000 Figure 87 on top two levels of the PRI / IUA / SCTP / IP
page 366 protocol stack; use of H.248 as media control
protocol instead of ASPEN is mandatory
V5.2 line
Substitute V5.2 for PRI and V5UA for IUA at the
Networked Figure 89 on top two levels of the PRI / IUA / SCTP / IP
via SIP-T page 367 protocol stack; use of H.248 as media control
protocol instead of ASPEN is mandatory
CCS7 encapsulation is not used for
CS2000-to-MCS5200 signalling.
The CCS7 meaning of each SIP-T message
Between CS2000 Figure 88 on must be inferred from the message header and
SIP-T
and MCS5200 page 367 parameters (see section D2.6.3 on page 255).
The X-Nortel-Profile parameter in the message
header provides trunk group information.
Use of UDP transport is mandatory.
For calls to/from line media gateways served by cable access networks or customer
LANs, the signalling interworking requirements are simpler because a single protocol
(NCS or MGCP) is used for both device/media control signalling and call control
signalling. It is therefore not necessary for CS2000 to co-ordinate signalling via two
different protocols. For a line-to-line call networked via SIP-T, two types of interworking
take place for each half call:
! Call control messages, e.g. requests to initiate a call to a dialled DN, are interworked
to appropriate CCS7 messages encapsulated via MIME, e.g. an ISUP or TUP IAM.
! Device/media control signalling conveyed in-line with NCS or MGCP packages,
e.g. SDP information used in codec and bearer capability negotiation, is
interworked to SDP information encapsulated via MIME.

Incoming half-call Outgoing half-call
Signalling: Signalling:
Call control signalling Call control signalling
ISUP ISUP
MTP MTP
Co-ordination Co-ordination
Media control signalling Media control signalling
H.248/lASPEN H.248/lASPEN
(SDP) (SDP)
UDP UDP
IP IP
Connections: Connections:
ISUP signalling terminated ISUP signalling terminated
on USP or FLPP on USP or FLPP

IP link between GWC and gateway IP link between GWC and gateway
(IP / AAL5 if backbone is ATM) (IP / AAL5 if backbone is ATM)
Figure 86: CCS7-to-CCS7 call between two gateways controlled by the same CS2000
Incoming half-call Outgoing half-call
PRI PRI
IUA/SCTP/IP IUA/SCTP/IP
Co-ordination Co-ordination
H.248/lASPEN H.248/lASPEN
(SDP) (SDP)
UDP UDP
IP IP
Connections: Connections:

Figure 87: PRI-to-PRI call between two gateways controlled by the same CS2000

Incoming half-call on originating CS2000 Outgoing half-call on originating CS2000
SIP-T
ISUP Session control
and encapsulation
MTP
Co-ordination
ISUP
Media control signalling Call control signalling
H.248/lASPEN SDP
(SDP) Media control signalling
UDP
IP UDP
Connections: IP

ISUP signalling terminated
on USP or FLPP Connections:
Media control signalling All signalling
IP link between GWC and gateway IP link between DPT GWCs
Figure 88: CCS7 call networked to a different CS2000
Incoming half-call on originating CS2000 Outgoing half-call on originating CS2000
SIP-T
PRI Session control
and encapsulation
IUA/SCTP/IP
Co-ordination
ISUP
Media control signalling Call control signalling
H.248/lASPEN SDP
(SDP) Media control signalling
UDP
IP UDP
Connections: IP

IP link between GWC and gateway
(IP / AAL5 if backbone is ATM) Connections:
Media control signalling All signalling
IP link between GWC and gateway IP link between DPT GWCs
Figure 89: PRI call networked to a different CS2000

Chapter E2 CCS7 Interfaces
E2.1 Introduction
Common Channel Signalling System No7 (CCS7) is a message-based network signalling
system that provides all the capabilities necessary for the following:
! Call establishment
! Call clearing
! Error handling
! Network operations and maintenance
! Database queries
It is a layered hierarchical system consisting of a number of parts that can be mapped on
to the OSI 7-Layer model. Message transfer functions are provided in a standardised way
at the lower levels of the hierarchy, while the messages to be transferred belong to one of
a number of user parts that occupy the higher layers of the hierarchy.
Note: The circuit-based message transfer functions defined in CCS7 standards are not
applicable in packet networks. For calls between CS2000s across the packet network,
CCS7 user part messages are not conveyed via MTP Layers 1-3. Instead, circuit-oriented
ISUP and TUP signalling is conveyed encapsulated in SIP-T, while TCAP NCAS (Non
Call Associated Signalling) is conveyed by means of M2PA (MTP2-User Peer-to-Peer
Adaptation).
The key to the efficiency of the system is that signalling, i.e. user part messaging, is
conveyed in dedicated signalling channels, which means that speech channel capacity
does not have to be used for this purpose. A single signalling channel is capable of
conveying the call setup and clearing messages for thousands of voice/data channels.
Note: Different standards bodies are involved in the definition of CCS7. North American
CCS7 standards are defined by the American National Standards Insitute (ANSI).
International standards are defined by the International Telecommunications Union
(ITU), the successor to CCITT. European CCS7 standards, which are typically defined in
relation to the corresponding ITU standards, are produced by the European
Telecommunications Standards Institute (ETSI). In addition, national standards bodies
define national CCS7 variants, typically using ITU or ETSI standards as the baseline. All
of these different standards bodies have the same general view of CCS7 parts and their
functions, but there are a number of detailed differences between individual
specifications, which are discussed where appropriate in the following sections.

CCS7 Interfaces Telephony Interfaces Communication Server Capabilities
Figure 90 illustrates the mapping of CCS7 parts on to the OSI 7-layer model. Brief
descriptions of the functions of each part are provided on the following pages.
OSI CCS7 Parts

Layers
Service
Database logic
IN database Direct
queries interaction Voice calls Simple
(interaction with service Supplementary services telephony
with SCP logic (e.g. ISDN data calls calls
via INAP) networked
CCBS)
INAP ISUP TUP
Layer 7
plus national variants of ETSI ISUP V2
plus national variants of ETSI ISUP V1

(Application) Networked NCAS services
ETSI ISUP V2 (White Book)
national variants of ETSI ISUP V3

ETSI ISUP V1 (Blue Book)
ITU/
IBN7
UK ISUP and SPIROU

ETSI
SSUTR2/FTUP in France
TCAP
IBN7 (ANSI ISUP+)
TCAP
IUP/BTUP in the UK
Different user parts

TCAP
CTUP in China
Layer 6
(Presentation)
Null layers
Layer 5
(Session)
Layer 4
(Transport)
SCCP (ITU/ANSI)
Circuit-independent or Circuit-oriented SCCP
Layer 3 connectionless SCCP (not supported by CS2000)
(Network)
Message transfer functions
Signalling network functions

common to all user parts
(message discrimination, distribution and routing)

MTP
Layer 2 (ITU / ANSI)
(Datalink) Signalling link functions
(extracting/inserting signal units)
Layer 1 Signalling datalink functions

(Physical) (providing reliable 64 Kb/s channel)
Note: For CCS7 calls across the packet network between peer CS2000, circuit-based MTP
capabilities are not used. Instead, circuit-oriented ISUP and TUP signalling is conveyed
encapsulated in SIP-T, while TCAP NCAS (Non Call Associated Signalling) is conveyed by
means of M2PA (MTP2-User Peer-to-Peer Adaptation).
Figure 90: CCS7 parts and the OSI 7-layer model

Communication Server Capabilities Telephony Interfaces CCS7 Interfaces
CCS7 parts and their functions can be categorised as follows:

! CCS7 parts that interact directly with users or applications at the top of the protocol
stack. These are:
" The Telephony User Part (TUP), which supports basic call.
CS2000 support for TUP is described in section E2.4 on page 406.
" The ISDN User Part (ISUP), which supports basic call and call-related
supplementary services.
CS2000 support for ISUP is described in section E2.3 on page 381.
" The Intelligent Network Application Part (INAP), which supports
circuit-independent database queries.
CS2000 support for INAP is separately described in Chapter E3: INAP.
Note: For some services, the Transaction Capabilities Application Part (TCAP)
that underlies INAP interacts directly with service logic by means of
service-specific application contexts and operations.
! CCS7 parts that support peer-to-peer comunication at lower levels of the protocol
stack. These are:
" The Message Transfer Part (MTP), which provides generic message-handling
capabilities both for telephony calls and for database queries.
" The Signalling Connection Control Part (SCCP), which supports call routing
for database queries.
" The Transaction Capabilities Application Part (TCAP), which provides
support for non-call-associated services such as Call Completion to Busy
Subscriber (CCBS). TCAP is also used to convey INAP (Intelligent Network
Application Part) signalling, which is used to support IN services via
circuit-independent database queries to an SCP.
CS2000 support for MTP, SCCP and TCAP is described in section E2.5 on page
416.
Note: For CCS7 calls across the packet network between peer Communication Servers,
circuit-based MTP capabilities are not used. Instead, circuit-oriented ISUP and TUP
signalling is conveyed encapsulated in SIP-T messages, while TCAP NCAS (Non Call
Associated Signalling) is conveyed by means of M2PA (MTP2-User Peer-to-Peer
Adaptation).

E2.2 TDM and Packet Network Implementations of

CCS7
CS2000 supports two different implementations of CCS7:
! The TDM implementation (see section E2.2.1) uses the complete CCS7 layered
model to provide an access interface between TDM network and the packet
network.
! The packet network implementation (see section E2.2.2) combines selected CCS7
user parts with packet network transport mechanisms to provide a network interface
between peer CS2000s across the packet network.
See section E2.2.3: Call Flow for Networked CCS7 VoIP or VoATM Call on page 376
for an annotated call flow that show how both implementations interact to support CCS7
call establishment across the packet network.
See section E2.2.4: Interworking TDM and Packet Implementations of CCS7 on page
379 for a discussion of some of the issues involved in interworking the TDM and packet
implementations, specifically echo cancellation and continuity checking.
E2.2.1 TDM Implementation (Access to Packet Network)
E2.2.1.1 Logical View

ISUP performs the functions of Layers 4 to 7, but in fact operates as a single layer, i.e. no
information is added or removed for the intermediate layers, and ISUP information has
exactly the same format at Level 7 as at Level 4. It uses the Message Transfer Part (MTP)
to support message transfer, i.e. ISUP messages are conveyed between nodes in MTP
Message Signal Units (MSUs), as illustrated in figure 91.
Call processing
(e.g. translations)
supported by CS2000 Core
OSI Layers
switch switch CCS7 protocol
supported via
Layer 7: Application static provisioning
CCS7 CCS7
user part Logical peer-to-peer user part
Layer 6: Presentation communication via
(ISUP, TUP, (ISUP, TUP, MTP Layer 3
Layer 5: Session TCAP) user part messages TCAP) message handing
provided by
Layer 4: Transport USP or FLPP
Layer 3: Network MTP MTP
Message Message
Layer 2: Datalink Transfer Transfer MTP Layer 2
Part Part functions provided
Layer 1: Physical
by CCS7 link
system node (USP)
User part messages conveyed between nodes or LIU7 (FLPP)
in MTP Message Signal Units (MSUs)
Figure 91: Peer-to-peer CCS7 messaging (TDM implementation)

E2.2.1.2 Configuration
In a TDM network, CCS7 trunks (bearer channels) and CCS7 signalling links are
typically 64Kb/s channels on 2Mb/s PCM30 carriers (E1s). Within the TDM network, a
given carrier can be dedicated to bearer channels, dedicated to signalling channels, or
support a mixture of both.
For CCS7 access from a TDM network to the packet network, signalling links are routed
over dedicated E1 carriers to a signalling gateway peripheral on the CS2000. Routing to
the CS2000 is direct for TDM carriers that are dedicated to signalling channels. For TDM
carriers that support bearer channels as well as signalling channels, the signalling links
must be groomed off before being routed to the CS2000. This grooming is typically done
by a separate multiplexer unit, logically independent of the media gateway but co-located
with it, but can alternatively be performed by a PVG itself.
The trunks corresponding to CCS7 signalling links terminate on media gateways, not on
the CS2000. The media gateways map the TDM-side bearer channels seamlessly on to
packet-based media streams. Co-ordination between signalling channels and bearer
channels is maintained via GWC-gateway media control signalling protocols. The two
protocols supported in ISN07 for device/media control signalling betwen GWCs and
PVGs are H.248 and ASPEN. Mediant 2000 gateways are controlled via H.248.
In ISN07, two alternative CS2000 signalling gateway peripherals are available to
terminate TDM-side CCS7 signalling:
TDM-side CCS7 user part messaging terminates on CCS7 link system nodes
in the USP, and the USP distributes messages to the CS2000 Core over the CS
LAN via a CCS7 / M3UA / SCTP / IP protocol stack. In CCS7 terms, the Core
and the USP share the same point code. As far as Core-resident CCS7 user
parts such as ISUP are concerned, M3UA allows messages to be sent and
received exactly as if MTP Layers 1-3 were in use, i.e. the user parts are not
aware that the USP is a separate LAN node.
FLPP Fiberised Link Peripheral Processor
TDM-side CCS7 user part messaging terminates on LIU7s (Link Interface
Units) in FLPP shelves, and the FLPP uses proprietary signalling to convey
messages to the CS2000 Core via the MS.
Use of the USP to support CCS7 signalling is recommended for all new CS2000
configurations. The FLPP is standard in existing TDM switches and in early CS2000
configurations, however, and it is expected that such FLPPs will be continure to be used
when the configurations are upgraded to ISN07.
See section B1.6 on page 72 for further information about the hardware configurations and
protocol stacks that can be used to support TDM-side CCS7 signalling.

E2.2.2 Packet Network Implementations of CCS7 Signalling

A CS2000 that uses the USP (Universal Signalling Point) to terminate TDM-side CCS7
signalling supports three different types of packet-based CCS7 signalling flow, two of
which involve the USP:
1 Signalling for inter-CS ISUP and TUP trunks (see section E2.2.2.1 on page 374)
2 Intra-CS2000 CCS7 signalling via the CS LAN (see section E2.2.2.2 on page 375)
3 TCAP NCAS (Non Call Associated Signalling) over the packet network (see
section E2.2.2.3 on page 375)
Note: Not supported by the USP Compact (see section B1.6.1.4 on page 77).
Figure 92 illustrates the protocol stack and configuration used for each of these types of
signalling flow. For completeness, it also shows the termination of TDM-side CCS7
signalling on the USP.
TDM-side switches,
CS2000 TCAP
ISUP TUP
SCPs, etc
TCAP SCCP Conventional
ISUP TUP CCS7
SCCP MTP3 signalling
MTP2 network
M3UA
SCTP MTP1
CS2000 USP
Core IP TCAP
2 3 SCCP
MTP3
Other CS2000s,
M2PA
peer MGCs
CS LAN SCTP
IP IP control
network over
Session backbone
DPT Server SIP-T SIP-T
GWC packet network
or 1 ISUP TUP
VRDN
SDP SDP
See section B1.4.5.3 on page 62 for TCP or UDP

with Session Server or VRDN IP
Figure 92: CS2000 support for CCS7 signalling flows across packet networks
A CS2000 that uses the FLPP (Fiberised Link Peripheral Processor) to terminate
TDM-side CCS7 signalling supports only one type of packet network signalling flow, i.e.
signalling for inter-CS ISUP and TUP trunks, which does not involve the FLPP. Intra-CS
CCS7 signalling uses the MS, and NCAS is supported only via a conventional CCS7
signalling network. The intra-CS (M3UA) and inter-CS NCAS (M2PA) protocol stacks
are not supported.

E2.2.2.1 Signalling for Inter-CS ISUP and TUP Trunks
Logical View
CCS7 user part messages (ISUP or TUP) are encapsulated in SIP-T session control
messages. These SIP-T messages are conveyed between nodes using either TCP or UDP
as the transport protocol, as illustrated in figure 93 and described in detail in Chapter D2:
SIP and SIP-T.
Call processing
(e.g. translations)
supported by CS2000 Core
OSI Layers
CS2000 Logical peer-to-peer CS2000 CCS7 protocol
communication via support provided
CCS7 messages by DPT GWC
Layer 7: Application ISUP / TUP ISUP / TUP
Layer 6: Presentation
SIP-T session SIP-T session
Layer 5: Session SIP-T SIP-T control provided
by Session Server
Layer 4: Transport TCP or UDP TCP or UDP
Layer 3: Network IP IP
UDP transport and
Layer 2: Datalink lower layer control
provided by
Layer 1: Physical Session Server
ISUP messages conveyed between nodes Note: If VRDN is used instead of

in packetised datagrams Session Server, DPT GWC
terminates SIP-T as well as CCS7
Figure 93: Peer-to-peer CCS7 messaging (packet network implementation)
Configuration
selected route, which is downloaded to the DPT GWC during call establishment.
For SIP-T, the telephony profile indicates the protocol characteristics of encapsulated
CCS7 signalling messages, which can be those of any supported ISUP or TUP variant.
The telephony profile itself is selected on the basis of the far-end host name, as determined
by translations and routing for an originating CS2000 or as indicated by the first incoming
message for a terminating CS2000.
between CS2000 and MCS5200. SIP does not provide direct CCS7 support, but SIP
For SIP, the telephony profile indicates the CCS7 protocol that is to be interworked with
SIP, which in ISN07 can only be IBN7 ISUP.
the duration of a given call, and is then returned to the pool for re-use.

See Figure 13 on page 63 for an illustration of how DPT GWCs interact with these other
units to support inter-MGC communication via SIP / SIP-T. See section E2.2.3: Call
Flow for Networked CCS7 VoIP or VoATM Call on page 376 for an annotated call
flow that illustrates CCS7 call establishment across the packet network using SIP-T.
Packet network bearer connections (media streams) corresponding to SIP-T signalling
sessions are established between media gateways under CS2000 control. They are not
directly handled by the CS2000, and are therefore outside the scope of this document.
CS2000 is, however, responsible for relaying SDP session descriptions between the
originating and terminating media gateways, and for controlling gateway operation via
device/media control signalling from the corresponding GWCs.
E2.2.2.2 Intra-CS2000 CCS7 Signalling via CS LAN

The USP distributes incoming CCS7 signalling to the CS2000 Core via the CS LAN. For
this purpose, CCS7 user part messages are conveyed over an M3UA / SCTP / IP protocol
stack. M3UA (MTP Layer 3 User Adaptation) is an IETF protocol for communication
between distributed system components that share the same CCS7 point code. Outgoing
CCS7 user part messages sent by the Core over M3UA / SCTP / IP are encapsulated by
the USP in standard MTP MSUs (Message Signalling Units) for routing over the CCS7
signalling network. A single CS2000 using a USP can have 31 point codes.
See Figure 92 on page 373 for an illustration of the protocol stack and configuration used
to support intra-CS CCS7 signalling via the CS LAN.
E2.2.2.3 NCAS (Non Call Associated Signalling) over the Packet Network
The USP also supports NCAS (Non Call Associated Signalling) with remote CS2000s
(strictly speaking, with USPs beonging to remote CS2000s) via the backbone packet
network. The protocol stack used for this purpose is TCAP / SCCP / MTP3 / M2PA /
SCTP / IP, where M2PA (MTP2-User Peer-to-Peer Adaptation) is an IETF protocol for
communication over a packet network between systems with different CCS7 point codes.
See Figure 92 on page 373 for an illustration of the protodcol stack and configuration used
to support TCAP NCAS with remote CS2000s.
Note: The USP could also support ISUP or TUP signalling between CS2000s over MTP3
/ M2PA / SCTP / IP, but this capability is not used by the CS2000 international product.
Inter-CS signalling via ISUP and TUP is instead supported by DPT GWCs and Session
Server or VRDN using SIP-T encapsulation of CCS7 user part messages, as described in
section E2.2.2.1 on page 374.

E2.2.3 Call Flow for Networked CCS7 VoIP or VoATM Call

This section provides an overview of the process of setting up a CCS7 call between two
CS2000s across a backbone packet network. It therefore deals with:
! The handling of incoming CCS7 calls at an originating CS2000
! Communication between two CS2000s to support the networking of CCS7 calls
! The handling of outgoing CCS7 calls at a terminating CS2000
The steps involved are numbered sequentially in the annotated network architecture
shown in Figure 94, and are described in order on the following page.
CCS7 signalling

Even if an ATM backbone
network is in use, signalling
to/from/between GWCs is TDM bearer channels
conveyed over IP
( IP / AAL5 / ATM over STM-1) Packet network bearer connections

4 15
3b 5a 5b 14 16a 16b
Access 8 DPT GWC DPT GWC 17 Access
CCS7 Gateway 26 and Session 11and Session Gateway CCS7
Signalling Controller 22 Controller Signalling
3a (GWC) 27 Server; 12 Server; (GWC) Gateway
Gateway
Ingress
(USP/FLPP) TDM-side 34 Egress 13 Ingress 32 Egress (USP/FLPP)
TDM-side
35 packet-side packet-side
2 6 9 10 25 18 20
28 29 38a Inter-CS signalling 33 31 21
23
(CCS7 signalling
37 36 24 38b 30
encapsulated in SIP-T)
PSTN CCS7 GWC-gateway GWC-gateway PSTN CCS7

signalling signalling signalling signalling
(e.g. ISUP) (H.248) (H.248) (e.g. ISUP)
7
Packet network 19
(ATM or IP)
media media
gateway gateway
Bearer connection
(packetised voice)
CCS7
signalling Mux Mux
groomed
off
Call origination 1 Call termination
PSTN
Figure 94: Setting up an ISUP VoIP or VoATM call between two CS2000s

Note: The messaging description below reflects two assumptions about protocol usage:
! It is assumed that the protocol used for device/media control signalling betwen
GWCs and PVGs is H.248. ASPEN continues to be supported as an alternative to
H.248 for trunk gateway control, but use of H.248 is recommended.
! It is assumed that the Session Server rather than a GWC configured as a VRDN is
used to terminate inter-CS packet network connections in the inter-CS part of the
call flow illustrated in Figure 94 on page 376. This implies that the Session Server
provides all SIP functionality, and that TCP rather than UDP is used as the inter-CS
transport protocol. See section D2.2: CS2000 Support for Dynamic Packet
Trunks on page 244 for further information.
1 Incoming call arrives at originating media gateway.
2 IAM for incoming call groomed off to terminate on CS2000 signalling gateway.
Signalling gateway (USP or FLPP) identifies ingress access GWC and media gateway
3a
3b and routes the IAM to the GWC. Ingress access GWC validates and processes IAM
and sends it on to the CS2000 Core.
CS2000 Core uses IAM to:
- Perform translations and routing, resulting in the selection of an outgoing trunk
group to another CS2000
- Select a DPT (Dynamic Packet Trunk) from the pool supported by DPT GWCs
4
- Allocate the selected DPT for the duration of the call
The DPT GWC selects a trunk profile for the DPT on the basis of the CCS7 protocol to
be used and the destination hostname, and passes the telephony profile index to the
Core.
See Figure 13 on page 62 for an illustration of how DPT GWCs interact with the
Session Server to support DPTs for inter-CS communication.
5a CS2000 Core sends FCM (Fabric Control Message) to ingress and egress GWCs to
5b enable direct communication between them
Ingress access GWC sends H.248 Add commands to originating media gateway to
establish mapping between TDM-side and packet-side terminations. First Add
6 command identifies TDM-side trunk and requests gateway to add it to a newly created
context. Second Add command asks gateway to reserve logical packet-side
termination in receive-only mode and add it to the same context.
Media gateway response to second Add command provides GWC with endpoint
7
identifier (IP address) to use for logical termination, together with SDP description of
bearer capabilities supported (for use in codec negotiation with the gateway serving
the remote endpoint).
8
Ingress access GWC passes media gateway IP address and SDP session description
to egress DPT GWC
Egress DPT GWC assembles outgoing IAM and forwards IAM to egress Session
Server. Egress Session Server encapsulates IAM in SIP-T INVITE message, together
9 with SDP session description including IP address of originating media gateway
endpoint; egress Session Server then sends INVITE message to Session Server on
terminating CS2000
10
Ingress Session Server on terminating CS2000 immediately acknowledges INVITE
message by sending back a SIP-T 100 TRYING message with no payload
Ingress Session Server selects an ingress DPT GWC that has an available DPT,
11
provides it with trunk profile information derived from the INVITE message.
See Figure 13 on page 63 for an illustration of how the Session Server and DPT GWCs
interact to support DPTs for inter-CS communication.
12
Ingress DPT GWC allocates selected DPT for the duration of the call and defines its
protocol characteristics in accordance with trunk profile from INVITE message.
13
Ingress Session Server forwards IAM extracted from INVITE message to selected DPT
on ingress DPT GWC
14
Ingress DPT GWC forwards IAM to CS2000 Core, requesting it to initiate call
processing

15
CS2000 Core uses IAM to perform translations and routing, and identifies the egress
access GWC and media gateway serving the destination
16a CS2000 Core sends FCM to ingress and egress GWCs to enable direct
16b communication between them
17
Ingress DPT GWC passes originating media gateway IP address and SDP session
description to egress access GWC
Egress access GWC sends H.248 Add commands to terminating media gateway to
18 command identifies TDM-side trunk identified via translations and routing, and
requests gateway to add it to a newly created context. Second Add command asks
gateway to reserve logical packet-side termination and add it to the same context.
19
bearer capabilities supported (for use in codec negotiation with the originating media
gateway serving the originating endpoint).
20 Outgoing IAM sent out from signalling gateway (USP or FLPP) on terminating CS2000
21 Backward ACM received by signalling gateway on terminating CS2000
Backward ACM routed to ingress DPT GWC on terminating CS2000 (directly or via the
22 Core, depending on CCS7 protocol types involved); ingress DPT GWC forwards ACM
to ingress Session Server
23
Ingress Session Server encapsulates outgoing ACM in a backward SIP-T 183
SESSION PROGRESS message, then sends message to originating CS2000
24
Ingress DPT GWC sends ingress Session Server a request for ringback tone to be
applied to originating TDM-side trunk.
25
Ingress Session Server conveys ringback tone request to originating CS2000 by
means of a backward SIP-T 180 RINGING message
Egress Session Server on originating CS2000 terminates SESSION PROGRESS and
26 RINGING messages, extracting backward ACM from SESSION PROGRESS
message and forwarding it to egress DPT GWC
27
Egress DPT GWC on originating CS2000 forwards ACM to ingress access GWC
(directly or via the Core, depending on CCS7 protocol types involved)
28 Backward ACM sent out from signalling gateway on originating CS2000
29
Ingress access GWC sends H.248 Modify message to originating media gateway,
asking gateway to apply ringback tone to originating TDM-side trunk
30
Backward ANM received by signalling gateway on terminating CS2000 and passed to
egress access GWC
31
Egress access GWC sends H.248 Modify message to terminating media gateway,
asking gateway to place the bearer connection in full duplex mode
Backward ANM routed to ingress DPT GWC on terminating CS2000 (directly or via the
32
Core, depending on CCS7 protocol types involved); ingress DPT GWC forwards ANM
to ingress Session Server, together with SDP description of bearer capabilities
supported by terminating media gateway endpoint
33
Ingress Session Server encapsulates outgoing ANM and associated SDP in a
backward SIP-T 200 OK message, then sends message to originating CS2000
34
Egress Session Server on originating CS2000 extracts ANM from SIP-T message and
forwards it to egress DPT GWC
35
Egress DPT GWC notifies ingress access GWC (directly or via the Core, depending on
CCS7 protocol types involved) of ANM arrival
36 completing codec negotiation process and asking gateway to remove ringback tone
and place the bearer connection in full duplex mode

Backward ANM sent out from signalling gateway on originating CS2000, thus
37 completing call setup for the packet network bearer connection between the two media
gateways
Forward SIP-T ACK message originated by egress Session Server on originating
38a
38b CS2000 to confirm receipt of final response to the original INVITE message, then sent
to ingress Session Server on terminating CS2000 to complete three-way handshake
E2.2.4 Interworking TDM and Packet Implementations of CCS7
E2.2.4.1 Echo Cancellation

CCS7 protocols allow the quality of a long-distance TDM speech path to be maintained
by using an echo cancellation device to ensure that no disconcerting echo is reflected from
the far end. To ensure that further echo cancellation is not applied by subsequent switches,
the IAM for a call indicates whether echo cancellation has already been applied in the
forward direction, and the ACM (or equivalent) indicates whether it has been applied in
the backward direction.
It is important to ensure that echo cancellation is not applied to bearer circuits used for
data calls (64Kb/s clear channel data, modem or fax), because it would corrupt the in-band
data.
Echo cancellation as such is clearly not applicable for bearer connections across a packet
network. However, CS2000 not only needs to support echo cancellation for its TDM-side
CCS7 trunks, but also needs to support EC-related signalling for DPTs. Specifically, the
IAM or ACM for a voice call across the packet network will always indicate that echo
cancellation has already been applied upstream.
When required, echo cancellation is applied to TDM-side circuits by trunk media
gateways in response to ASPEN or H.248 requests from CS2000 GWCs. Application of
echo cancellation is controlled at various levels, as follows:
! In the media gateway, echo cancellation is provisioned ON.
! In CS2000 datafill, the ECSTAT field of table TRKSGRP determines whether the
media gateway should activate echo cancellation for calls using the TDM-side trunk
circuit in question:
" ECSTAT=INTERNAL (the default) means that echo cancellation is ON, i.e.
that the internal echo cancellation capability of the trunk media gateway
should be applied.
" ECSTAT=EXTERNAL causes CS2000 to assume that echo cancellation has
been or will be applied externally.
! CCS7 signalling indicates whether echo cancellation is ruled out because:
" The call is a data call (indicated by TMR/USI bearer capability value in IAM).
" The call is a speech call, but echo cancellation has already been applied
(indicated by Nature of Connection field in IAM for incoming call; indicated
by Backward Call Indicator in ACM or equivalent for outgoing call).
If echo cancellation by the media gateway is permitted for a given TDM-side circuit and
is not ruled out for a particular call, the GWC will request the media gateway to apply it.
Note: If the media gateway independently determines that a call is a fax or modem call,
it will disregard CS2000 instructions and turn off ECAN for that call.

The following truth table indicates how different combinations of factors determine
whether echo cancellation is turned on or off for a call.
Fax tone detected by PVG Y NN N N N N N N N N N N N

Modem tone detected by PVG N YN N N N N N N N N N N N
ISUP message indicates no previous ECAN N/A N/A
Y Y Y Y Y Y Y Y N N N N
ISUP message indicates previous ECAN N/A N/A
N N N N N N N N Y Y Y Y
ECSTAT=INTERNAL in table TRKSGRP N/A N/A
Y Y N N Y Y N N Y Y N N
ECSTAT=EXTERNAL in table TRKSGRP N/A N/A
N N Y Y N N Y Y N N Y Y
CS2000 requests CCD N/A N/A
N N N N Y Y Y Y N N N N
ECAN provisioned always OFF in PVG N/A N/A
Y N Y N Y N Y N Y N Y N
ECAN provisioned ON by default in PVG N/A N/A
N Y N Y N Y N Y N Y N Y
e: e: e: e: e: e: e: e:
ASPEN local connection option N/A N/A on on N/A N/A N/A N/A off off off off
off off
Result: ECAN application by PVG OFF OFF OFF ON OFF OFF OFF OFF OFF OFF OFF OFF OFF OFF
See A59026177 and A59039615 for further information.
E2.2.4.2 Continuity Testing

CCS7 protocols allow the quality of the TDM speech path for a call to be tested by
transmitting an in-band tone, looping this tone back again, and comparing the
looped-back tone with the tone originally transmitted. This is known as Continuity
Testing (COT). Such continuity testing is clearly not applicable for bearer connections
across a packet network, but must be supported for TDM-side CCS7 trunks.
Continuity testing can be performed in the course of call establishment or independently
on demand, as follows:
! Per-call continuity testing is initiated by including a COT request in the IAM. A
COT message is subsequently sent in the forward direction to indicate that the
continuity test has been successful; this is relayed to the terminating switch, which
will not send back an ACM until it has received the COT message.
! On-demand continuity testing is initiated by sending a CCR (Continuity Check
Request) message, which asks the far-end switch to attach tone loopback equipment
to a specified circuit.
CS2000 supports both types of testing for its TDM-side CCS7 circuits. Outgoing
continuity test tones and looped-back tones are applied by PVG media gateways, not by
CS2000 itself. The gateway applies the tone in response to an ASPEN 2.1 RQNT
(Request Notification) command after the preliminary CCS7 messaging has taken place.
CS2000 supports per-call continuity testing for calls incoming to the packet network by:
! Recognising COT requests in received IAMs.
! Looping back in-band continuity tones when received. This capability is enabled by
setting the COTCHK field of table TRKSGRP to THRH (transmit high, receive
high) for the circuit in question.
! Relaying COT messages received to indicate successful continuity testing.
For outgoing TDM-side calls, CS2000 will initiate continuity checking on an outgoing
circuit x% of the time, where the percentage x is specified in the COTREQ field of the
table TRKSGRP entry for the circuit in question. See A59025979 for details.

E2.3 ISDN User Part (ISUP) Support

E2.3.1 Overview
The Integrated Services Digital Network (ISDN) User Part is the CCS7 user part that
supports not only basic telephony, but also ISDN data calls, and a range of supplementary
services based on the exchange of information using out-of-band messages.
Within ISUP there are two functional layers:
! Basic call procedures support call establishment and clearing
! Network services are built on top of basic call. They use extra ISUP messages, or
extra parameters in basic call messages, to support services such as the exchange of
calling and called party names for display. Most of the services currently available
are call-related, i.e. they are relevant only in the context of a successful call attempt.
Call-independent services do not depend on the existence of a connection, and use
TCAP messaging rather than ISUP.
ISUP can be used to support both telephony calls and data calls.
Figure 95 illustrates the messaging used to set up and clear a typical ISUP call.
switch switch
Caller goes
off-hook and
dials number IAM (Initial Address Message)
Optional - overlap signalling only

SAM (Subsequent Address Message)
Ringing Physical
tone ACM (Address Complete Message) ringing
Audible ringing in-band
Called party
ANM (Answer Message) answers
Speech path through-connected
Call in progress
REL (Release message)

Caller goes
on-hook to RLC (Release Complete message)
terminate call
Figure 95: ISUP messaging for call setup and clearing

E2.3.2 ISUP Standards and Variants
E2.3.2.1 Open Standards

There are three main sets of ISUP standards. National and proprietary ISUP variants are
normally defined in relation to one of these main standards sets. They are:
! ITU (previously CCITT) ISUP, of which there are several iterations (versions):
" 1988, Blue Book
CCITT Recommendations Q.761 to Q.764 (1988, Blue Book). These
Recommendations define ISUP for intra-network use (typically within a
national network).
CCITT Recommendation Q.767 (1991) specifies an ISUP subset suitable for
use as an international interface, i.e. between networks with different
characteristics, and defines it in relation to the 1988 CCITT Blue Book
Recommendations.
" 1993, White Book
ITU-T Recommendations Q.761 to Q.764 (1993, White Book). These
Recommendations define ISUP both for intra-network use (typically within a
national network) and for international use.
" ISUP 97
ITU-T Recommendations Q.761 to Q.764 (1997).
" ISUP 2000
ITU-T Recommendations Q.761 to Q.764 (2000).
! ETSI ISUP, of which there are also several iterations (versions):
" ETSI ISUP Version 1
ETSI ISUP V1 is the subject of ETS 300 121 (1992), but this ETS merely
endorses the text of CCITT Recommendation Q.767 (1991) without any
modification.
ETSI ISUP V2 is defined in ETS 300 356-1 (1995). This ETS is a delta to
ITU-T Recommendations Q.761 to Q.764 (1993, White Book). It defines an
ISUP subset suitable for use as an international interface, i.e. between
networks with different characteristics.
ETSI ISUP V2 is a superset of ETSI ISUP V1. It supports all capabilities
supported by ETSI ISUP V1, plus additional messages and parameters for
networked support of ISDN MoU2 services. ETSI ISUP V2 also supports
compatibility procedures that cause unrecognised parameters to be passed on
transparently, rather than being discarded as they would be with V1.
ETSI ISUP V3 is defined in EN 300 356 (1998) in relation to ITU-T
Recommendations Q.761 to Q.764 (1997).
To be defined in relation to ITU-T Recommendations Q.761 to Q.764 (2000).
! ANSI ISUP
This is the North American standard for ISUP. The CS2000 implementation is
based on Bellcore Technical Requirement TR-TSY-000317 (Issue 2, July 1989),
which should be read in conjunction with ANSI specification T1.113.1-4
(November 1989).

At a functional level, ANSI ISUP and ETSI ISUP are essentially the same, but at the
protocol level there are differences in the parameters and parameter values supported.
They also use different formats for the MTP routing label (as used on the TDM side).
E2.3.2.2 National Variants

Although ETSI ISUP (V1 and/or V2) can be used unmodified in a national network, it is
common for national regulators to define their own national variants. Such a variant is
typically characterised by requirements to provide parameter values, parameters, and
even messages in addition to those required by the basic ETSI ISUP specifications. These
additional protocol elements may be national-specific, or may be optional standard
elements that are regarded as mandatory by the regulator.
E2.3.2.3 CS2000 Implementation (Call Processing Agents and Variants)

CS2000 supports ISUP call processing agents for:
! ETSI ISUP V1 / ITU Blue Book
! ETSI ISUP V2 / ITU White Book
! ETSI ISUP V3
! IBN7 / ANSI ISUP+
The signalling characteristics of a given ISUP trunk, i.e. the particular ISUP variant to be
used, are primarily determined by datafill in table TRKSGRP. Details are provided in the
remainder of this section.
Call Processing Agent for ETSI ISUP V1 / ITU Blue Book

Table TRKSGRP identifies trunks using the ETSI ISUP V1 agent by means of a
signalling type of C7UP, an external protocol of Q767, and a protocol version selector of
100_BLUE.
The following variants are supported in ISN07:
! The generic variant, which is denoted as the BASE variant of 100_BLUE
! The Brazilian variant, which is denoted as the BRAZIL variant of 100_BLUE
! The Czech variant, which is denoted as the CZECH variant of 100_BLUE
! The Danish variant, which is denoted as the DENMARK variant of 100_BLUE
! The Italian variant, which is denoted as the ITALY variant of 100_BLUE
! The Mexico variant, which is denoted as the MEXICO variant of 100_BLUE
Note: CS2000 also supports Telmex ISUP V1, which is datafilled in TRKSGRP as
Mexico ISUP V1, and in table TRKOPTS as a sub-variant of Mexico ISUP V1.
! The Norwegian variant, which is denoted as the NORWAY variant of 100_BLUE
! The Portuguese variant, which is denoted as the PORTUGAL variant of 100_BLUE
! The Spanish variant, which is denoted as the SPAIN variant of 100_BLUE
! The Turkey variant, which is denoted as the TURKEY variant of 100_BLUE
CS2000 also supports Malaysian ISUP V1. This is defined as a variant of ETSI ISUP V1,
but is implemented using the AISUP call processing agent.

Note: The CS2000 implementation of FTUP / SSUTR2, which is described in section

E2.4.2 on page 410, is denoted internally as the FRANCE variant of 100_BLUE.
Call Processing Agent for ETSI ISUP V2 / ITU White Book

Note: The ETSI ISUP V2 call processing agent is sometimes referred to as V2+ because
it supports incorporates protocol extensions (additional messages and parameters) for
selected V3 capabilities, as described later in this section.
Table TRKSGRP identifies ETSI ISUP V2 trunks by means of a signalling type of C7UP,
an external protocol of Q767, and a protocol version selector of 100_WHITE. The
following variants are supported:
! The generic variant, which is denoted as the BASE variant of 100_WHITE.
! The Belgian variant, which is denoted as the BELGIUM variant of 100_WHITE.
! The Chilean variant, which is denoted as the CHILE variant of 100_WHITE.
! The Chinese variant, which is denoted as the CHINA variant of 100_WHITE.
! The German variant, which is denoted as the GERMANY variant of 100_WHITE.
! The Hong Kong variant, which is denoted as the HONGKONG variant of 100_WHITE.
! The Israeli variant, which is denoted as the ISRAEL variant of 100_WHITE.
! The Italian variant, which is denoted as the ITALY variant of 100_WHITE.
! The Russian variant, which is denoted as the RUSSIA variant of 100_WHITE.
! The Singapore variant, which is denoted as the SINGAPORE variant of 100_WHITE.
! The Spanish variant, which is denoted as the SPAIN variant of 100_WHITE.
! The Swedish variant, which is denoted as the SWEDEN variant of 100_WHITE.
! The Turkish variant, which is denoted as the TURKEY variant of 100_WHITE.
! Australian ACIF I-ISUP, which is denoted as the ACIF_AUSTRALIA variant of
100_WHITE. It is so called because its definition is controlled by the Signalling
Working Group of the Australian Communication Industry Forum (ACIF),
previously known as the Network Interworking Industry Forum (NIIF). ISN07
provides fully productised support for ACIF I-ISUP as a variant of ETSI ISUP V2.
ACIF I-ISUP is now the standard interconnection protocol in Australia, superseding
NIIF I-ISUP, AISUP and ATUP.
The capabilities of the ACIF I-ISUP implementation correspond to those defined in
the latest version of the interface definition, which is:
ACIF G.500 Signalling System No.7, Interconnection ISUP
The base for this is ITU-T Recommendation Q.764 (White Book).
! Telstra CA30 ISUP, which is denoted as the CA30_AUSTRALIA variant of
100_WHITE. It is used primarily for TDM-side connections with switches belonging
to the Telstra PSTN network, but can also be used across the packet network. It is
defined in Network Signalling Infrastructure Specification C.A.30 (ISUP),
Issue 1, 8/5/96.
! Japan Interconnect ISUP (JI-ISUP), which has been defined as the standard
interface to be used in all Japanese carrier interconnect scenarios where two or more
carriers are involved in handling a call. It is defined in Japan TTC specification
JJ-90.10 Version 2 (1999), and Interconnection Charge Billing Method, Second
Edition. JI-ISUP is intended as a single replacement for NCCI#7 (New Common
Carrier Interface No7) ISUP, different variants of which were previously used in
different interconnect scenarios.
The CS2000 implementation of ETSI ISUP V2 incorporates additional messages and
parameters for the V3 APM (Application Transport Mechanism) capability; for this
reason, it is sometimes referred to as ETSI ISUP V2+. APM is designed to support the

generic QFT (QSIG Feature Transparency) capability, and specific services such as
NAOC (Network Advice Of Charge), by means of ISUP and TCAP signalling. See
section E5.1.5 on page 469 for more information about QFT.
Call Processing Agent for ETSI ISUP V3
CS2000 does not yet support a base/generic ETSI ISUP V3 agent, but does support two
national variants of ETSI ISUP V3:
! UK ISUP, as described in section E2.3.5 on page 398
! SPIROU (French ISUP V3), as described in section E2.3.6 on page 400
Table TRKSGRP identifies ETSI ISUP V3 trunks by means of a signalling type of C7UP,
an external protocol of Q767, and a protocol version selector of EIV3_100.
Call Processing Agent for ANSI ISUP variants

Table TRKSGRP identifies trunks using the IBN7 ISUP agent by means of a signalling
type of ISUP and an external protocol of Q764.
This agent is used primarily to support enhanced ANSI ISUP, which is referred to as
ANSI ISUP+ or IBN7. IBN stands for Integrated Business Network, and IBN7 ISUP is a
proprietary implementation of ANSI ISUP with extensions to support proprietary features
such as Networked Centrex.
With effect from ISN07, CS2000 can also use the IBN7 ISUP agent to supportNorth
American Feature Group D (FGD) ISUP, which is based on ANSI ISUP but also includes
additional IAM parameters that are either not included or defined as optional in ANSI
ISUP.
For further information about ANSI ISUP variants, especially IBN7 / ANSI ISUP+, see
section E2.3.4 on page 395.

E2.3.3 CS2000 Support for ETSI / ITU ISUP

E2.3.3.1 ETSI ISUP Capabilities
Q.761 Capabilities
The following table indicates the support provided by the CS2000 implementation of
ETSI ISUP for the capabilities listed in Table 1 of Q.761. See section E2.3.3.2 on page
393 for information about ISDN service support over ETSI ISUP.
Basic call
Bearer capability: speech
Bearer capability: 3.1 KHz audio
Bearer capability: unrestricted digital information
Compatibility procedure (message and parameter compatibility only) [1]
Confusion procedure [2]
Echo control procedure (static and dynamic echo control)
Tones and announcements
MTP pause and resume
Access delivery information
Transportation of user teleservice information
Simple segmentation [3]
Generic procedures for supplementary service support
End-to-end signalling - Pass along method [4]
Generic number transfer [1]
Generic digit transfer [1]
Generic notification procedure [1]
[1] ETSI ISUP V2 only; not supported by ETSI ISUP V1.
[2] Fully supported by ETSI ISUP V2. CS2000 ETSI ISUP V1 does not support full confusion
procedures, but will send a CFN message on receipt of unrecognised information, which exceeds
the requirements specified in Q.767.
[3] ETSI ISUP V2 only. CS2000 provides full originating and terminating node support for IAM
segmentation. For segmentation of other messages, CS2000 provides only transit node support.
[4] Used only in Spanish ISUP V1.
Capabilities listed in Table 1 of Q.761 but not supported by the CS2000 implementation
of ETSI ISUP V1 or ETSI ISUP V2.
Basic call
Multirate connection types
Signalling procedures for connection type allowing fallback capability
User part availability control
Propagation delay determination procedure
Generic procedures for supplementary service support
End-to-end signallingSCCP Connection Oriented
End-to-end signallingSCCP Connectionless
Simple service activation procedure
Remote operations procedure
Network specific facility procedures

Message Support
CS2000 supports standard messages as summarised in the table below.
Address complete (ACM) Facility reject (FRJ) [9]

Answer (ANM) Facility request (FAR) [9]
Application Transport Message [1] Forward transfer (FOT) [6] [10]
Blocking (BLO) [2] Identification request (IDR) [11]
Blocking acknowledgment (BLA) [2] Identification response (IRS) [11]
Call progress (CPG) Information (INF) [11]
Charge (CRG) / Charging (CHG) [3] Information Request (INR) [11]
Circuit group blocking (CGB) [2] Initial address (IAM)
Circuit group blocking ack. (CGBA) [2] Loop prevention (LOP) [8]
Circuit group query (CQM) [4] Pre-Release Information (PRI) [1]
Circuit group query response (CQR) [4] Release (REL)
Circuit group reset (GRS) Release complete (RLC)
Circuit group reset acknowledgment (GRA) Reset circuit (RSC)
Circuit group unblocking (CGU) [2] Resume (RES) [12]
Circuit group unblocking ack. (CGUA) [2] Segmentation (SGM) [13]
Confusion (CFN) [5] [6] Subsequent address (SAM)
Connect (CON) Suspend (SUS) [12]
Continuity (COT) [7] Unblocking (UBL)
Continuity check request (CCR) Unblocking acknowledgment (UBA)
Facility (FAC) [8] Unequipped circuit ID code (UCIC) [14]
Facility accepted (FAA) [9] User-to-user information (USR) [9]
[1] ETSI ISUP V3 message supported by the CS2000 implementation of ETSI ISUP V2 for
conveying QFT and/or NAOC application information.
[2] Blocking procedures not supported on SIP-T ISUP trunks.
[3] CHG is supported only for JI-ISUP. It is received by CS2000 but rarely generated.
[4] Mexican and Brazilian ISUP only.
[5] Supported by CS2000 ETSI ISUP V1 although this is not required by Q.767.
[6] Not supported in Italian ISUP V1.
[7] CS2000 supports loopback of continuity test tone on incoming TDM-side calls, application of tone
on outgoing TDM-side calls, and relaying of COT messages (see section E2.2.4.2).
[8] German T-ISUP and Hungarian ISUP only.
[9] ETSI ISUP V2 only; not supported by ETSI ISUP V1.
[10]Not supported in Turkish ISUP V1.
[11]Used to request/provide caller info if this is not provided in the IAM. The IDR/IRS and INR/INF
mechanisms are supported on a trunk group basis for base/generic ETSI ISUP V1 and V2 and
selected national variants, e.g. INR/INF for Spanish ISUP V1 and Belgian ISUP V2.
[12]Originating / terminating support as well as tandem support.
[13]ETSI ISUP V2 only. Full originating and terminating node support for IAM segmentation. For
segmentation of other messages, CS2000 provides only transit node support.
[14]Polish ISUP only.
CS2000 also supports the following sets of national-specific messages:

! China-specific messages
" CCL (Calling Party Clear)
" MPM (Meter Pulse Message)
" OPR (Operator call)

! Czech-specific messages
" TON (Trunk Offering On)
" TOF (Trunk Offering Off)
! Messages specific to German T-ISUP
" Charging (CHG)
" Charging Extended (CHGE)
" Charging Extended Ack (CHGEA)
" Einhaengezeichen des A-Tl (EHZA)
" Facility Information (FIN)
" Nationale Nachricht (NANA)
" User Information (UIN)
! Israel-specific messages
" BCM (Backward Charge Message)
" TCM (Tariff Change Message)
" CAM (Charging Acknowledge Message)
! Mexico-specific messages:
" Offer
" Offer Cancellation
" Recall (not used in Telmex ISUP)
" False
! Russia-specific messages:
" CCL (Calling Line Clear) message for use with MCT
" RNG (Ring) message for operator requests to apply ringing
! Turkey-specific message used to support MCT:
" IDENT
The following messages are not supported, i.e. they are never generated by the CS2000.
If received, they are treated according to the message compatibility procedures of Q.764
(see also see also Handling Unrecognised Messages and Parameters on page 391).
Loop back acknowledgment (LPA) User part available (UPA)

Network resource management (NRM) User part test (UPT)
Overload (OLM)

Parameter Support
Parameters supported.
Access delivery information Location number

Access transport MCID request indicators
Additional CLI (ACLI) [1] MCID response indicators
Application transport [2] Message compatibility information [4]
Automatic congestion level [3] National forward call indicators [7]
Backward call indicators Nature of connection indicators
Call diversion information [4] Number of charge units [7]
Call reference [5] Optional backward call indicators
Call history information Optional forward call indicators
Called party number Original called number [4] [10]
Calling party number Parameter compatibility information [4]
Calling partys category Propagation delay counter
Carrier Selection Parameter (CSP) [6] Range and status
Cause indicators Redirecting number [4] [10]
CCBS parameter [4] Redirection information [4]
Charge band number [7] Redirection number [4] [10]
Circuit group supervision message type ind. Redirection number restriction [4]
Closed user group interlock code Service activation [4]
Connected number Signalling point code
Continuity indicators Subsequent number
End of optional parameters indicator Suspend/resume indicators
Event information Tariff [11]
Facility indicator [4] Transit network selection [6]
Forward call indicators Transmission medium requirement [12]
Generic digits [4] User service information [12]
Generic notification indicator [4] User teleservice information [4]
Generic number [4] [8] User-to-user indicators
Hop counter User-to-user information
Information indicators [9] VPN code [13]
Information request indicators [9]
[1] Singapore ISUP V2 only. Used to convey N2 (routing number) as well as Calling Party Number
for calls from ported-in LNP numbers.
[2] ETSI ISUP V3 parameter supported by CS2000 implementation of ETSI ISUP V2 for conveying
QFT information.
[3] Implemented for TDM-side ETSI ISUP by feature A59034132. A CS2000 alerts other switches to
congestion levels via automatic congestion level (ACL1 and ACL2) parameters in REL
messages, enabling them to activate any automatic congestion controls. For CS2000, the
control mechanism used on receipt of a REL message with an ACL parameter is to block the
circuit to outgoing calls for a period in the datafillable range 0-240s.
[4] ETSI ISUP V2 only; not defined for ETSI ISUP V1.
[5] This parameter is supported on a per trunk group basis via datafill. The procedure for adding /
transiting / removing the parameter is based on network-specific requirements. See A59023264.
[6] For use in carrier selection. TNS is a generic parameter for intra-network use; CSP is a German
national-specific parameter for inter-network use (enabling carrier selection via intermediate
networks).
[7] Used only in Czech ISUP V1.
[8] Used with NQI (Number Qualifier Indicator) indicating "additional calling party number" to support
the conveying of a Presentation Number, if available, in addition to the Network Number (which is
conveyed in the CgPN parameter).
[9] Spanish ISUP V1 only.

[10]ETSI ISUP V2 parameter supported in Mexico ISUP V1.

[11]Used only in Spanish ISUP V1 Charge (CRG) message.
[12]Spanish ISUP allows USI value to be relayed unchanged even if it is inconsistent with the TMR
value, even though this is not allowed by Q.767.
[13]Specific to Spanish ISUP.
! Parameters specific to JI-ISUP

The CS2000 also supports an extensive range of parameters that are specific to
JI-ISUP, primarily for use in Inter-Administration Acounting (IAA):
" Additional user type / Additional partys category
IAA parameter; received by CS2000 but never generated.
" Carrier information
IAA parameter generated in IAM, ACM and CPG (not in ANM). Conveys up
to four CICs identifying OLEC, TLEC, IEC and CIEC. For single-operator
switches, the appropriate CIC value to create/update is determined by office
parameter TELCO_ID. For multi-operator switches, but only for JI-ISUP
calls, the appropriate CIC value is determined by SUB_TELCO_ID datafill in
table IAACTRL (encountered during translations).
" Cause of no ID information (required for local service but not for tandem
calls)
" Charge area information (IAA parameter generated in IAM, ACM)
" Charging information
" Charging information delay indicator
" Charging information type/ID
" Contractor number (local service equivalent of contract subscriber number)
" Contract subscriber number (tandem equivalent of contractor number)
" Deferred delivery indicator (IAA parameter; received by CS2000 but never
generated)
" ISDN User Part indicator (IAA parameter)
" National redirection reason
" Personal HandySet (PHS) number
" Redirect capability
" Redirect counter
" SCF ID
" Terminating user number
! Parameters specific to German G-ISUP
" CALL_DIVERSION_TREATMENT_INDICATORS
" OPTIONAL_CALLED_IN_NUMBER
" CALL_OFFERING_TREATMENT_INDICATOR
" CONFERENCE_TREATMENT_INDICATORS
" ORIGINATING ISC POINT CODE
" FREEPHONE INDICATORS

The following parameters are not supported, i.e. they are never originated by CS2000. If
received, they are treated according to the compatibility procedures of Q.764, except that
the recommendations for unrecognised optional parameter values are not implemented
(see also Handling Unrecognised Messages and Parameters on page 391). At a transit
node, such values are not analysed, and will pass through transparently; at a terminating
node, the action taken depends on the interworking.
Call transfer number MLPP precedence

Call transfer reference Network specific facility
Circuit state indicator Origination ISC point code
Connection request Remote operations
Echo control information Transmission medium requirement prime
Freephone indicators Transmission medium used
Generic reference User service information prime
Loop prevention indicators
Handling Unrecognised Messages and Parameters

The ETSI ISUP V1 and V2 agents both respond to unrecognised messages by sending a
Confusion message with Cause value 97 (message type non-existent or not implemented).
This is as specified in Q.764, but not as specified in Q.767 (in which the Confusion
message is defined as not used), i.e. the capabilities of the CS2000 ETSI ISUP V1
implementation exceed those of the Q.767 specification.
The ETSI ISUP V1 and ETSI ISUP V2 agents differ in the way in which they handle
unrecognised parameters, as follows:
! Interworking to an outgoing ETSI ISUP V1 trunk
For ETSI ISUP V2 calls interworked to an outgoing ETSI ISUP V1 trunk,
parameters not supported by V1 will be discarded.
! Interworking to an outgoing ETSI ISUP V2 trunk
For calls interworked or transited to an outgoing ETSI ISUP V2 trunk, unrecognised
parameters will be passed on transparently unless modified by call processing at the
switch (e.g. in the case of routing information).
Miscellaneous Capabilities
Capabilities not explicitly listed in the standards:
! Call processing is based on EDCP (Event-Driven Call Processing), which means
that incoming ETSI ISUP calls (both TDM-side and SIP-T) can trigger as IN
(Intelligent Network) calls.
! Continuity checking
! Translations and routing based on:
" Bearer Capability
" Numbering Plan Indicator / Nature Of Address
" Calling Party Category
! Overlap outpulsing for all interworkings supporting overlap signalling, including
SIP-T carriage of ISUP.

! Full originating and terminating node support for suspend/resume functionality and
use of the reanswer timer T6.
! ISUP V2+ support for QFT (QSIG Feature Transparency)
Allows bearer-related QSIG information to be transparently transported across the
ETSI ISUP network using the generic APM (Application Transport Mechanism).
Support provided by ETSI ISUP V3 messages/parameters implemented by CS2000
as extensions to ETSI ISUP V2:
" An Application Transport Parameter (APP) that can be conveyed in the
existing ISUP message IAM, ACM, ANM, CON and CPG.
" An Application Transport Message (APM) that can be sent independently to
convey an APP.
" A Pre-Release Information (PRI) message that can be sent prior to a REL
message to convey an APP.
" APM-based segmentation and reassembly.
" APM-based overlap outpulsing of private digits.
See section E5.1.5 on page 469 for more information about QFT.
! ISUP V2+ support for NAOC (Network Advice Of Charge)
For NAOC, call charges are calculated centrally at a CDP (Charge Determination
Point), and call charge information is provided to an originating CGP (Charge
Generation Point) to be relayed back to the calling user over the access interface.
Charging information is conveyed from the CDP to the CGP using the ETSI ISUP
V2+ APM (Application Transport Mechanism).
! Ability to suppress timer T9 for FreePhone calls. Timer T9 is started at an
originating switch when an ACM is received, and causes the call to be released if it
expires before an ANM is received. RTE and CONT translation selectors can now
prevent this by specifying NO_ANSWER_TIMING.
! Rerouting on congestion
If a call routed out over an ETSI ISUP trunk encounters congestion (indicated by
receipt of a REL message with cause value 34 or 42), this option allows CS2000 to
make another attempt to route the call.
Note: Alternative names for rerouting on congestion are Conditional Re-Routing
and NRR (Network Re-Routing (NRR).
! Automatic Congestion Control (ACC), as described in A59034132
With ACC (as defined in Q.764 section 2.11), a congested switch alerts other
switches to congestion levels via automatic congestion level (ACL1 and ACL2)
parameters in REL messages, enabling them to activate any automatic congestion
controls. For TDM-side ETSI ISUP on CS2000, the control mechanism used on
receipt of a REL message with an ACL parameter is to block the circuit to outgoing
calls for a period in the datafillable range 0-240s.
Capabilities Specific to Australian ACIF G.500 I-ISUP

! Digit outpulsing
Maximum number of Called Party Number digits for ACIF I-ISUP is 30, as for
ETSI ISUP V2. However, it is a regulatory requirement that an ACIF I-ISUP IAM
should convey a maximum of 16 digits; any digits in excess of 16 will therefore be
conveyed in a SAM.
! CLI handling
Maximum number of CLI digits for ACIF I-ISUP is 24.

! Billable digits
Maximum number of digits for ACIF I-ISUP is 30, as for ETSI ISUP V2.
! CLI and CPC parameter values
These must be provided in the IAM for all Interconnect ISUP calls. This means that
ACIF I-ISUP does not need to support the use of INR/INF messages to request and
provide this information.
E2.3.3.2 Feature and Service Support
VPN Services
ETSI ISUP V1 and V2 (and national variants) both support the following VPN services:
! On-net routing
! Off-net routing
! Automatic route selection
! Time of day routing
! CLI-based screening for indirect and customer group access
! Virtual Facility Group support (SFG/NARS)
! ETSI ISUP V2 also supports the ETSI ISUP V3 APM (Application Transport
Mechanism), which allows it to provide networked support for private numbering
plans, and to support QSIG Feature Transparency (QFT) and DPNSS Feature
Transparency (DFT). QFT and DFT respectively allow QSIG and DPNSS
signalling information to be conveyed transparently over the network.
QFT is supported as described in section E5.1.5 on page 469.
Note: Since CS2000 does not support DPNSS as an access interface in ISN07,
support for DFT is limited to the relaying of encapsulated information originated in
the TDM network.
! Networked Centrex
Networked Centrex means extending the operational scope of Centrex services
beyond a single switch, e.g. forwarding a call to a line served by a different switch,
or distributing incoming calls between ACD groups on different switches.
This is accomplished by use of a proprietary Network Information (NETINFO)
parameter in call setup messages using the APM mechanism to provide the
following subscriber details for use in setting up translations:
" Customer group, which determines the availability to the subscriber of
services provisioned against the customer group.
" Network Class Of Service (NCOS), which determines the types of call that the
subscriber can make and receive (see section C3.2 on page 206 for details of
NCOS screening).
NETINFO makes it possible to support customer groups served by more than one
node. In a VPN context, it enables subscribers to have access to the same range of
services regardless of where a call is made from or where a given service
implementation resides.
It also allows ISUP trunks to be shared between multiple VPNs.

ISDN Supplementary Services

The table below summarises CS2000 support for the networking of ISDN supplementary
services via ETSI ISUP V1/V2 and national variant signalling encapsulated in SIP-T. See
Chapter F4: ISDN Supplementary Services for descriptions of the services supported.
An ISDN supplementary service is deemed to be supported if CS2000 supports it over
both the access interface (ETSI ISDN PRI) and the network interface (e.g. ETSI ISUP V2
over SIP-T), and also supports direct interworking between any service-related
parameters conveyed over both interfaces. Services that are not supported or not
applicable for PRI are simply not listed.
Networked support over

ISDN supplementary service
ETSI ISUP V1 ETSI ISUP V2
MoU Priority 1 services
CLIP Yes Yes
CLIR Yes Yes
[1]
DDI Yes Yes [1]
Advice Of Charge During Call (AOC-D) N/A [1] N/A [1]
Advice Of Charge at End of Call (AOC-E) N/A [1] N/A [1]
Closed User Group (CUG) Yes Yes
Connected Line Identification Presentation (COLP) No Yes
Connected Line Identification Restriction (COLR) No Yes
Malicious Call Identification (MCI) Yes Yes
Subaddressing (SUB) Yes Yes
[2]
User-to-User Signalling (UUS) Yes Yes [2]
Call Completion to Busy Subscriber (CCBS) No Yes [3]
Call Forward Unconditional (CFU) Yes [4] Yes [5]
Call Forward on Busy (CFB) Yes [4] Yes [5]
Call Forward on No Reply (CFNR) Yes [4] Yes [5]
Partial Rerouting (PRR) Yes [4] Yes [5]
Explicit Call Transfer (ECT) Yes Yes
Non-ETSI ISDN services (MoU3)
Network Advice Of Charge No Yes
Priority Class Of Service (PCOS) for Germany No Yes
Emergency Calls Yes Yes
[1]
Random and Circular Hunting for PRI Yes Yes [1]
[1] No additional network signalling required.
[2] UUS service 1 (implicit) only.
[3] TCAP NCAS (Non Call Associated Signalling) for CCBS is conveyed across the packet network
between CS2000 USPs by means of a TCAP / SCCP / MTP3 / M2PA / UDP / IP protocol stack.
[4] Forwarding node functionality supported, but no notification is provided back to caller or forward
to new called party. Such notifications are not defined for Q.767.
[5] Some limitations apply to CS2000 support for forwarding notifications to caller and new called
party (see service description in section F4.3 on page 567).

E2.3.4 CS2000 Support for ANSI ISUP Variants
E2.3.4.1 Overview of ANSI ISUP+ / IBN7 ISUP

Enhanced ANSI ISUP, which is referred to as ANSI ISUP+ or IBN7 (IBN stands for
Integrated Business Network), is a proprietary implementation of ANSI ISUP, with
extensions to support proprietary features such as Networked Centrex.
ANSI ISUP is the North American standard for ISUP, as defined in ANSI specification
T1.113.1-4. Like the ITU and ETSI ISUP specifications, the ANSI ISUP specification
has undergone several revisions, with each successive version incorporating new optional
capabilities while remaining backwards-compatible with previous versions. CS2000 can
support many of these optional capabilities, which are configured individually rather than
being implicitly activated by datafilling a specific version of ANSI ISUP.
Note: The IBN7 interface is not suitable for general use for interconnect to North
American LECs or IXCs. These interfaces generally require use of refinements of ANSI
ISUP defined by Telcordia (previously Bellcore), which add additional service signalling
capabilities not included in the ANSI ISUP specification. The North American versions
of the CS2000 and DMS product lines do fully support these interfaces, and can interwork
with the International CS2000 via IBN7 trunks.
The primary role of IBN7 is to link CS2000s to support various types of networked
services for business users. The linked CS2000s typically belong to one network operator.
IBN7 actually comprises the ISDN User Part (ISUP), the Transaction Capabilities
Application Part (TCAP), the Signalling Connection Control Part (SCCP), the Message
Transfer Part (MTP), and IBN7 network services. The term IBN7 can be used to denote
either ISUP on its own (ANSI ISUP+) or ISUP together with the other CCS7 parts that
support it. The intended meaning should be clear from the context.
E2.3.4.2 IBN7 Protocol Characteristics

! IBN7 uses the Network Information (NETINFO) parameter in call setup messages
to provide the following subscriber details for use in setting up translations:
subscriber can make and receive (see section C3.2 on page 206 for details of
NCOS screening).
! IBN7 supports the Party Information parameter, which is used to convey the name
of the far-end party in support of the Network Name Display (NND) service. It also
supports the Supplementary End-to-End Information Request parameter, which is
used to request name information, and the Supplementary End-to-End Information
Response parameter, which indicates that name information is being provided.

! IBN7 supports the proprietary Reconfiguration Progress Message (RPM), which is

used when a call is transferred, to notify the caller and the new called party that Call
Transfer has taken place.
! IBN7 supports DPNSS Feature Transparency (DFT), which allows DPNSS
signalling information to be conveyed transparently over the network.
Note: Since CS2000 does not support DPNSS as an access interface in ISN07,
support for this capability is limited to the relaying of encapsulated information
originated in the TDM network.
E2.3.4.3 IBN7 Feature and Service Support
Network Support for ISDN Supplementary Services

IBN7 provides network support (transit only) for the ISDN supplementary services
defined in the CEPT MoU on ISDN rollout for Europe: Memorandum of Understanding
on the Implementation of an European ISDN Service by 1992, as described in Chapter
F4: ISDN Supplementary Services.
Network Support for DPNSS Features

IBN7 trunks can network DPNSS features by conveying DPNSS service information
transparently across the network using DPNSS Feature Transparency (DFT). In a VPN
context, DFT is a key part of Networked PBX VPN.
DFT uses the general-purpose ANSI-defined Network Transport Parameter (NTP) to
convey the Nortel proprietary Hybrid Network Information Parameter (HNIP), which can
in turn convey encapsulated DPNSS signalling. See Chapter F6: DPNSS Features for
Networked Centrex
Networked Centrex means extending the operational scope of Centrex services beyond a
single switch, e.g. forwarding a call to a line served by a different switch, or distributing
incoming calls between ACD groups on different switches.
Support for Networked Centrex requires service-related information to be conveyed in
additional IBN7 ISUP parameters and messages. The NETINFO parameter conveyed in
every IBN7 IAM provides customer group and NCOS information that makes it possible
to determine whether a given call is a private network call, and thus determine which
services are available. Other parameters provide information such as the callers number
and name. For some services, support may also require switches to exchange information
and requests via circuit-independent IBN7 TCAP messaging.
Note: Although TCAP NCAS (Non Call Associated Signalling) across the packet
network is supported in ISN07, IBN7 services that rely on it (e.g. NRAG, feature
transparency) need to be productised before deployment.

E2.3.4.4 Support for North American Feature Group D (FGD) ISUP

With effect from ISN07, CS2000 can use the IBN7 ISUP call processing agent to support
North American Feature Group D (FGD) ISUP. The FGD ISUP protocol is based on the
ANSI T1.113 ISUP specification, but also includes additional IAM parameters that are
either not included or defined as optional in ANSI ISUP. FGD ISUP is defined by
GR-317-CORE, Telcordia and GR-394-CORE Telcordia.
USA Feature Group D ISUP can be used by a CS2000 running ISN07 to support IXC
(Inter-Exchange Carrier functionality), communicating with North American Local
Exchange Carriers (LECs) and Inter-Exchange Carriers (IECs). FGD ISUP supports not
only basic CCS7 interconnection between networks, but also a set of Equal Access
features that allow subscribers to choose which carriers to use for their calls.
Subscribers connected to the North American PSTN can use FGD ISUP to access an
alternative carriers DMS-based network and services. Similarly, users outside North
America can be routed through such a network to terminate (via FGD ISUP) in the North
American PSTN.
The network configuration is illustrated in Figure 96.
Gateway
Other
switch
CS2000
ANSI ISUP+ ETSI ISUP
Other
IXC FGD ISUP carriers/
CS2000 IECs
PSTN/ FGD ISUP running
LECs ISN07
ANSI PRI
or
USA R1 CAS
Corporate
network
Figure 96: Network configuration in which FGD ISUP is used
The FGD ISUP protocol and its message flows are very similar to those of the IBN7
(ANSI ISUP+). FGD ISUP trunks are therefore defined in table TRKGRP as trunks of
type IBN (IBNTO, IBNTI or IBNT2), with signalling type C7UP and external protocol
Q764. This is as for IBN7 ISUP trunks. The handling of optional IAM parameters,
including those that are FGD-specific, is controlled via datafill in tables TRKOPTS and
ISPARM.
For a detailed description of the ISN04 (TDM) implementation of FGD ISUP, see
A59036475.

E2.3.5 UK ISUP Support
E2.3.5.1 Variants
UK ISUP is intended to be the long-term replacement for IUP/BTUP (see section E2.4.1
on page 406) as the standard CCS7 trunk interface for use within and between networks
in the UK.
It has been designed as a national variant of ITU-T ISUP 97, which is expected to be the
basis for ETSI ISUP V3, i.e. the design intent is that UK ISUP should be compatible with
ETSI ISUP V3.
Because it has been designed as an ETSI ISUP variant, basic call functionality and call
estabishment for UK ISUP are essentially the same as for ETSI ISUP. UK ISUP and ETSI
ISUP V3 differ from ETSI ISUP V1/V2 in terms of the level of service support they
provide, as follows:
! UK ISUP supports the Application Transport Mechanism (APM) for transparently
conveying service-related information across the network. This allows switches to
provide transit support for services based on QSIG, DPNSS or other feature-rich
PBX protocols.
! UK ISUP supports a number of specific supplementary services in addition to the
MoU2 services supported by ETSI ISUP V2 (see section E2.3.5.2 on page 399 for
details).
UK ISUP is defined in PNO-ISC/SPEC/007 (Issue 2.1, April 1998), produced by the UK
Public Network Operators Interconnect Standards Committee (PNO-ISC) ISUP Working
Party. This document specifies the ISUP protocol required for the national interface
between public network operators in the UK.
The base for Issue 2 of the UK ISUP specification is ITU-T Recommendations
Q.761-764 (1997 edition), generally referred to as ISUP 97, extended to include
descriptions of additional functionality required for the UK.

Dynamic Routing Control

CS2000 supports Dynamic Routing Control (DRC) for UK ISUP calls. This prevents
circular routing of calls by allowing a transit node to specify whether the next node is
permitted to use alternate routing and/or continuous retry to complete a call.
Routing control is supported over UK ISUP by means of the RCI (Routing Control
Indicator) in the IAM, which has the following possible values (AR = alternative routing;
CR = continuous retry):
0 AR permitted from receiving node, CR permitted
1 AR not permitted from receiving node, CR permitted
2 AR permitted from receiving node, CR not permitted
3 AR not permitted from receiving node, CR not permitted
VPN Services
UK ISUP supports the following VPN services:
! On-net routing
! Off-net routing
UK ISUP also supports ETSI ISUP V3 APM (Application Transport Mechanism)
extensions, which enable it to provide networked support for private numbering plans.

UK ISUP supports the networking of the same set of ISDN supplementary services as
ETSI ISUP V2, as summarised in section E2.3.3.2 on page 393. See Chapter F4: ISDN
Supplementary Services for descriptions of the services supported.

E2.3.6 SPIROU (French ISUP) Support

E2.3.6.1 Variants
SPIROU is intended to be the long-term replacement for FTUP (see section E2.4.2 on
page 410) as the standard CCS7 trunk interface for use within and between networks in
France. It is based on the specification SPIROU 1998-00 produced by the French ART
(Autorit de Rgulation des Tlcommunications), which is in turn based on ITU-T
Recommendations Q.761 to Q.764 (1997) and ETSI ISUP V3.
Because it has been designed as an ETSI ISUP variant, basic call functionality and call
estabishment for SPIROU are essentially the same as for ETSI ISUP. SPIROU and ETSI
ISUP V3 differ from ETSI ISUP V1/V2 in terms of the level of service support they
provide, as follows:
! SPIROU supports the Application Transport Mechanism (APM) for transparently
conveying service-related information across the network. This provides transit
support for services based on QSIG or other feature-rich PBX protocols.
! SPIROU supports a number of specific supplementary services (see section
E2.3.6.2 for details).

VPN Services
SPIROU supports the following VPN services:
! On-net routing
! Off-net routing
SPIROU also supports the ETSI ISUP V3 APM (Application Transport Mechanism)
extensions, which enable it to provide networked support for private numbering plans.

SPIROU supports the networking of the same set of ISDN supplementary services as
ETSI ISUP V2, as summarised in section E2.3.3.2 on page 393. See Chapter F4: ISDN
Supplementary Services for descriptions of the services supported.
Backward Charging
SPIROU supports the ITX message (Message dimputation or Charge Unit message) and
the TXA message (Signal daccus de rception de taxation, or Charging
Acknowledgement message). The Backward Charging service allows a service provider
to send charging information backwards over the signalling system during the call to the
originating switch that performs the billing. This enables service providers to control the
billing of calls, e.g. to premium rate numbers.

E2.3.7 Interworking Support for ISUP Variants

Table 34 summarises CS2000 support for ISUP interworkings in the ISN07 release. ISUP
variants are listed in alphabetical order, and support for interworking between a given
ISUP variant and each other generic interface supported by CS2000 is specified as one of
the following:
Y Interworking supported.
N Interworking not supported.
X Interworking not relevant (e.g. between interfaces deployed in different
markets)
Table 34: Interworking support for ISUP variants
SIP (no CCS7) [3]

ISUP variant IBN lines
ETSI ISUP V1 [1]
ETSI ISUP V2 [1]

IBN7 ISUP
CentrexIP
DPNSS [6]
Cable MGs [8]

H.323 [5]
LAN MGs [7]
V5.2 MGs [9]

TUP [2]
PRI [4]
Implemen-
QSIG
INAP
tation
Country /
name Characteristics
Y
Australian ETSI ISUP V2 TDM Y [10] Y N Y Y Y Y N X N N Y N
ACIF I-ISUP variant
SIP-T Y Y Y N Y Y Y Y N X N N N N
Belgian ETSI ISUP V2 TDM Y Y Y N N N Y N N X N N N N

ISUP variant SIP-T Y Y Y N N N Y N N X N N N N
Brazilian ETSI ISUP V1 TDM Y Y Y N N N Y N N X N Y N Y

ISUP variant SIP-T Y Y N N N N Y N N X N N N Y
Chilean ETSI ISUP V2 TDM Y Y Y N N N Y N N X N N N N

TDM N Y Y Y Y Y
[11] [12] N Y [13] N N X N [14] N Y
Chinese ETSI ISUP V2
ISUP variant Y Y Y Y N Y
SIP-T [15] [15] [15] [12] Y [13] N N X N N N Y
TDM Y Y Y N N N Y N N X N N N N
V1 and V2
Czech ISUP
variants [16] SIP-T
[17] Y Y Y N N N Y N N X N N N N
Danish ETSI ISUP V1 TDM Y Y Y N N N N N N X N N N N

ISUP variant SIP-T Y Y Y N N N N N N X N N N N
Y Y
TDM Y Y Y [18] Y Y [19] Y Y N N Y Y Y
ETSI ISUP V1
(base / generic variant) Y Y
SIP-T Y Y Y [18] Y Y [20] Y Y N N Y Y Y

SIP (no CCS7) [3]

ETSI ISUP V1 [1]
ETSI ISUP V2 [1]

IBN7 ISUP
CentrexIP
DPNSS [6]
Cable MGs [8]

H.323 [5]
LAN MGs [7]
V5.2 MGs [9]

TUP [2]
PRI [4]
Implemen-
QSIG
INAP
tation
Country /
Y Y
TDM Y Y Y [18] Y Y [19] Y Y N N Y Y Y
ETSI ISUP V2
(base / generic variant) Y Y
SIP-T Y Y Y [18] Y Y [20] Y Y N N Y Y Y
ETSI ISUP V2 TDM Y Y Y N N N Y Y N X N N Y N

variant SIP-T Y Y Y N N N Y Y N X N N Y N
T-ISUP variant TDM Y
Y [21] N N N N N N N X N N N N
German of ETSI ISUP V2 only
ISUP
TDM Y N
Y [21] N N N N N N X N N N N
G-ISUP variant
of ETSI ISUP V2 Y
SIP-T Y [21] N N N N N N N X N N N N
Y
TDM Y Y Y N N N [22] N N X N Y N N
Hong Kong ETSI ISUP V2
ISUP variant Y N
SIP-T Y Y Y N N N [22] N X N Y N N
ANSI ISUP with TDM Y Y Y

Y Y [18] Y Y [23] Y Y Y Y N N N
IBN7 ISUP Nortel
proprietary SIP-T Y Y
extensions [24] Y Y Y [18] Y Y [25] Y Y Y Y N N N
ETSI ISUP V2 TDM N Y Y N N N N N N X N N N N

Indian ISUP
variant SIP-T N Y Y N N N N N N X N N N N
Israeli ETSI ISUP V2 TDM Y Y Y N N N Y Y N X N N N N

ISUP [26] variant SIP-T Y Y Y N N N Y Y N X N N N N
V1 and V2 TDM Y Y Y N N N Y N N X N N N N
Italian ISUP
variants [27] SIP-T Y Y Y N N N Y N N X N N N N
Japanese ETSI ISUP V2 TDM Y Y Y N Y N Y N N X N N N Y

JI-ISUP variant SIP-T Y Y Y N Y N Y N N X N N N Y
Capabilities TDM Y Y Y N N N Y N N X N N N N
Malaysian equivalent to
ISUP ETSI ISUP SIP-T Y Y Y N N N Y N N X N N N N
V1 [28]
Y Y
TDM [29] Y N N N Y N N X N N N Y
Mexican ETSI ISUP V1
ISUP variant Y
SIP-T [29] Y Y N N N Y N N X N N N Y

SIP (no CCS7) [3]

ETSI ISUP V1 [1]
ETSI ISUP V2 [1]

IBN7 ISUP
CentrexIP
DPNSS [6]
Cable MGs [8]

H.323 [5]
LAN MGs [7]
V5.2 MGs [9]

TUP [2]
PRI [4]
Implemen-
QSIG
INAP
tation
Country /
Norwegian ETSI ISUP V1 TDM Y Y Y N N N N N N X N N N N

ISUP variant SIP-T Y Y Y N N N N N N X N N N N
TDM Y Y Y N N N Y N N X N N Y N
Portuguese ETSI ISUP V1
ISUP variant Y
SIP-T Y Y Y N N N [30] N N X N N N N
Russian ETSI ISUP V2 TDM Y Y Y N N N Y N N X N Y N Y

ISUP variant SIP-T Y Y Y N N N Y N N X N Y N Y
Singapore ETSI ISUP V2 TDM Y Y Y N N N Y N N X N N N N

Y Y
TDM Y Y Y N Y N [33] [34] N X Y N Y N
Spanish V1 and V2
ISUP variants [31] [32] Y
SIP-T Y Y Y N Y N Y [34] N X Y N N N
SPIROU ETSI ISUP V3 TDM Y Y Y N N N Y Y N X N N N N

(France) variant [35] SIP-T Y Y Y N N N Y Y N X N N N N
Swedish ETSI ISUP V2 TDM Y Y Y N N N N N N X N N N N

ISUP variant [36] SIP-T Y Y Y N N N N N N X N N N N
TDM Y Y Y N N N Y N N X N N N Y
Telmex [29]
ISUP ETSI ISUP V1
(Mexico) [37] variant Y
SIP-T [29] Y Y N N N Y N N X N N N Y
Y Y
Telstra ETSI ISUP V2 TDM [38] [10] Y N Y Y Y N N X N Y N N
CA30 ISUP [38]
(Australia) variant
SIP-T Y Y Y N Y Y Y N N X N Y N N
Turkish V1 and V2 TDM N N N N N N Y N N X N N N N

[31] [39]
ISUP variants SIP-T N N N N N N Y N N X N N N N
Y
TDM Y Y Y [40] N Y Y Y Y N N N Y N
ETSI ISUP V3
UK ISUP
variant [35] Y
SIP-T Y Y Y [40] N N Y Y Y N N N N N
ANSI ISUP with TDM Y Y Y N N N N N N X N N N N

USA FGD extensions for
ISUP
equal access [41] SIP-T Y Y Y N N N N N N X N N N N

[1] Entries in these columns refer to interworking with base/generic ETSI ISUP. Each variant of ETSI
ISUP V1 and V2 can be interworked to itself as well as to base/generic ETSI ISUP.
[2] CS2000 does not support a base/generic TUP call processing agent, but supports three national TUP
variants for China (CTUP), France (SSUTR2 / FTUP) and the UK (IUP / BTUP). Y appears in this
column for ISUP variants that can be interworked to one or more of these national TUP variants.
[3] When communicating with an MGC or gateway that does not provide ISUP payload in the SIP
message (e.g. MCS5200), CS2000 generates an IBN7 ISUP payload based on SIP message type and
content.
[4] CS2000 supports a base/generic call processing agent for ETSI PRI (30B+D). It also supports two
national 30B+D PRI variants for China and Spain, and three national 23B+D PRI variants for the USA
(ANSI PRI), Hong Kong (CR13) and Japan (INS1500). Entries in this column apply to support for
interworking between ISUP variants and base/generic ETSI PRI. Footnotes are used to indicate
whether interworking is supported for a national PRI variant as well as (or instead of) base/generic
ETSI PRI.
[5] The international implementation of H.323 is based on mapping H.225 connection control messages
(SETUP etc) on to their QSIG equivalents, with APDUs being conveyed transparently in Facility IEs in
QSIG messages. Support for H.323 basic call interworking means support for H.225 call
establishment, and does not imply support for the handling of non-call-related information over the
interworking. Basic call interworkings supported are therefore as for QSIG.
[6] CS2000 support for DPNSS is based on the international implementation of H.323 (see footnote [5]).
Between the GWC and the Westell DPNSS gateway, DPNSS signalling is encapsulated in
Westell-defined manufacturer-specific operations in the H450.1 SupplementaryService data field of a
H323 message. For communication between the GWC and the Core, the GWC performs mapping
between these operations and QSIG Facility IEs.
[7] For IBN lines supported by media gateways attached to customer LANs, ISUP interworking means
interworking between ISUP signalling and MGCP signalling.
[8] For IBN lines supported by media gateways served by cable access networks, ISUP interworking
means interworking between ISUP signalling and NCS signalling.
[9] For IBN lines supported by V5.2 media gateways, ISUP interworking means interworking between
ISUP signalling and V5.2 Layer 3 signalling backhauled to CS2000 over a V5UA/SCTP/IP protocol
stack, together with co-ordination between ISUP signalling and H.248 device/media control signalling.
[10]Interworking is also supported between TDM-side ACIF I-ISUP and TDM-side Telstra CA30 ISUP.
[11]For TDM-side Chinese ISUP over SIP-T, interworking is supported with TDM-side IBN7 ISUP, but not
with IBN7 ISUP over SIP-T.
[12]Interworking between Chinese ISUP and Chinese TUP (CTUP) is supported.
[13]PRI interworking for Chinese ISUP is supported with Chinese PRI (23B+D) as well as base/generic
ETSI PRI.
[14]Interworking verified only for Askey gateways.
[15]For Chinese ISUP over SIP-T, interworking is supported with ETSI ISUP and IBN7 ISUP over SIP-T,
but not with TDM-side ETSI ISUP or IBN7 ISUP.
[16]Czech ISUP V1 is supported on the TDM side and over SIP-T. Czech ISUP V2 is supported only over
SIP-T.
[17]Czech ISUP V2 over SIP-T interworks only with itself and with Czech ISUP V1 (TDM and SIP-T). The
entries in this row apply to interworkings for Czech ISUP V1 over SIP-T.
[18]Interworking is supported with all three national TUP variants: CTUP, SSUTR2 / FTUP and IUP /
BTUP.
[19]For TDM-side ETSI ISUP, interworking is supported with all national PRI variants except China.
[20]For ETSI ISUP over SIP-T, interworking is supported with all national PRI variants, including China.
[21]Interworking supported with base/generic ETSI ISUP V2, T-ISUP and G-ISUP, but not with German
ETSI ISUP V2.
[22]Interworking supported with Hong Kong PRI (CR13) as well as base/generic ETSI PRI.
[23]TDM-side IBN7 ISUP can be interworked to all supported PRI variants except those for China and
Japan.
[24]Functionality equivalent to SIP-T with an encapsulated IBN7 ISUP payload is provided by SIP DPTs
with no ISUP payload. This enables CS2000 to communicate with an MGC or gateway that does not
provide ISUP payload in SIP message (e.g. MCS5200), by generating an IBN7 ISUP payload based
on SIP message type and content.
[25]IBN7 ISUP over SIP-T can be interworked to all supported PRI variants except Chinese PRI.
[26]In addition to the standard national version of Israeli ISUP, CS2000 supports an ISDEFO-AVNET
variant of ETSI ISUP V2 for use in the Israel Defence Forces network. Supported interworkings for this
variant are as shown for Israeli ISUP.
[27]Italian ISUP V1 is the standard national interconnect interface; CS2000 supports Italian ISUP V2 for
intra-network support of regulatory services. Interworking between the two variants is not supported.
Otherwise, supported interworkings are the same for both variants.

[28]Although it is defined as a variant of ETSI ISUP V1, Malaysian ISUP is implemented on CS2000 using
the AISUP agent.
[29]Interworking between Mexican ISUP and Telmex ISUP is also supported, except for interworking
between the two SIP-T implementations.
[30]For Portuguese ISUP, interworking is supported with Spanish PRI as well as base/generic ETSI PRI.
[31]V1 and V2 variants are both in use in the national network. CS2000 can support either variant for a
given trunk group, depending on the variant supported by the far-end switch. Supported interworkings
are the same for both variants except where explicitly stated otherwise.
[32]Interworking between the two variants of Spanish ISUP is also supported, but only between the
TDM-side implementation of one and the SIP-T implementation of the other.
[33]For Spanish ISUP, interworking is supported with Spanish PRI as well as base/generic ETSI PRI.
[34]Interworking with QSIG supported only for Spanish ISUP V1, not Spanish ISUP V2.
[35]CS2000 supports two national variants of ETSI ISUP V3, but does not support a base/generic V3 call
processing agent.
[36]Swedish ISUP is defined as a variant of ETSI ISUP V1, but is implemented on CS2000 as a variant of
ETSI ISUP V2.
[37]Telmex ISUP is implemented on CS2000 as a sub-variant of Mexican ISUP (NOM112) rather than an
ISUP variant in its own right.
[38]For TDM-side Telstra CA30 ISUP, interworking is supported only with ETSI ISUP over SIP-T, not with
TDM-side ETSI ISUP.
[39]Interworking between Turkish ISUP V1 and Turkish ISUP V2 is also supported, except for interworking
between the two SIP-T implementations.
[40]Interworking between UK ISUP and IUP/BTUP is supported.
[41]FGD ISUP trunks are implemented on CS2000 as IBN7 ISUP trunks, with the handling of
FGD-specific parameters controlled via datafill in tables TRKOPTS and ISPARM.
E2.3.8 Software Order Codes for ISUP

Table 35: Order codes for ISUP software
NSUP0002 ETSI ISUP V1
NSUP0003 ETSI ISUP V2
ISP70001 Base ISUP (ANSI IBN7)
NETK0041 ETSI ISUP V2 Hop Counter
NSUP0014 ETSI/UK ISUP Answer No Charge Support
NSUP0015 Bearer Capability Mapping
NSUP0018 Japan Unified ISUP

E2.4 Telephony User Part (TUP) Support

The Telephony User Part is devoted exclusively to the handling of telephony calls. Many
national TUP variants have been defined. TUP can be regarded as the lowest common
denominator for CCS7 signalling between different networks and different types of
switch.
CS2000 supports the following TUP variants:
! The UK Interconnect User Part (IUP), also referred to as the British Telephony User
Part (BTUP). The CS2000 implementation of BTUP is described in section E2.4.1
on page 406.
! The French Telephony User Part (FTUP), also referrred to as SSUTR2. The CS2000
implementation of FTUP is described in section E2.4.2 on page 410.
! The Chinese Telephony User Part (CTUP). The CS2000 implementation of CTUP
is described in section E2.4.2 on page 410.
E2.4.1 IUP / BTUP Support
E2.4.1.1 Variants
The UK Interconnect User Part (IUP) is a publicly owned version of the British Telephony
User Part (BTUP) that is being standardised by a committee under the control of Oftel. It
is intended to supersede BTUP as the UK national CCS7 standard for inter-network and
intra-network connections between switches.
The committee to which the IUP working party reports is known as PNO/ISC (the Public
Network Operators/Interconnect Standards Committee). The IUP specification is known
as PNO/ISC/SPEC006. It is a replacement for BTNR 167, which defines BTUP. It is not
yet complete, but section 2 (Message Types and Contents) and section 3 (Common
Procedures), which are available, provide a complete specification of basic call.
Two versions of IUP/BTUP are currently in general use in the UK:
! BTUP Version 3 (1987), the version to which IUP corresponds
Supports supplementary and network services, including delivery of CLI in
IAM/IFAM; also supports Nodal End-to-End (NEED) messaging used for BES and
VPN applications (similar to DPNSS Feature Transparency).
! BTUP Version 2 (1985)
Supports delivery of CLI on request.
BTUP Version 2 can currently be regarded as the lowest common denominator for CCS7
signalling between different networks and different types of switch. It has been largely
superseded by IUP / BTUP Version 3.
Table TRKSGRP identifies trunks using the BTUP agent by means of a signalling type of
TUP and an external protocol of BTUP. The CS2000 BTUP agent supports two variants
of IUP/BTUP, which are known within Nortel as BTUP V2 and V2+. A switch will use
only one variant for the outgoing calls that it originates, as specified in the office
parameter BTUP_VER_IND in table OFCENG. For transit calls, the CS2000 uses the
same BTUP variant on the outgoing call leg as is used on the incoming leg.

E2.4.1.2 IUP / BTUP Capabilities
Message Support
IUP/BTUP uses the H1H0 method of classifying mssages and assigning message header
codes, i.e. messages are grouped by message type (H0) with each message having a
unique identifier (H1) within that message type. The message types defined are shown in
the matrix below. CS2000 support for each message is summarised following the matrix.
H1
Message Group 0000 0001 0010 0011 0100 0101 0110 0111 1010 1011 1100 1101
H0
Forward Address
0000 IAM IFAM SAM FAM
Messages (FAM)
Forward Setup Messages
0001 ASI
(FSM)
Backward Setup Request
0010 SND SAD SASI
Messages (BSRM)
Backward Setup Info
0011 ACM CGN TCM CNA RA SEM SOO CDB
Messages (BSIM)
Call Supervision
Messages (CSM) 0100 ANS CLR RAN REL CFC OOR HLR EXC
Circuit Supervision
0101 CCTF BLO UBL BLA UBA OLM
Messages (CCM)
Service Information
0111 CFN ICSI SSM SRV ACI OCM UUD SWAP # UIS UIR
Messages (SIM)
Forward Address Messages (H0=0000)

IAM (H1=0000) Initial Address Message
IFAM (H1=0001) Initial And Final Address
SAM (H1=0010) Subsequent Address
FAM (H1=0011) Final Address
Forward Setup Messages (H0=0001)

ASI (H1=0100) Additional Setup Information
Backward Setup Request Messages (H0=0010)

SND (H1=0010) Send N Digits
Not generated.
SAD (H1=0011) Send All Digits
SASI (H1=0100) Send Additional Setup Information
Backward Setup Information Messages (H0=0011)

ACM (H1=0000) Address Complete (Number Received)
CGN (H1=0010) Congestion
TCM (H1=0011) Terminal Congestion (rerouting not possible)
CNA (H1=0100) Connection Not Admitted
RA (H1=0101) Repeat Attempt
SE (H1=0110) Subscriber Engaged
SOO (H1=0111) Subscriber Out Of Order
CDB (H1=1010) Call Drop Back
Transit support only. Not generated, and ignored if received.

Call Supervision Messages (H0=0100)

ANS (H1=0000) Answer
CLR (H1=0001) Clear
RAN (H1=0010) Re-answer
REL (H1=0011) Release
CFC (H1=0100) Coin And Fee Check
OOR (H1=0101) Operator Override (TKO)
Not generated. Appropriate action taken on receipt.
HLR (H1=0110) Howler
ECM (H1=0111) Extend Call
Circuit Supervision Messages (H0=0101)

CCTF (H1=0000) Circuit Free
BLO (H1=0001) Blocking
UBL (H1=0010) Unblocking
BLA (H1=0011) Blocking Acknowledge
UBA (H1=0100) Unblocking Acknowledge
OLM (H1=0101) Overload
Not generated. On receipt, CS2000 attempts to find an alternative
route for the call.
Service Information Messages (H0=0111)

CFN (H1=0000) Confusion
ICSI (H1=0001) ISDN Composite Service Information
Message accepted but not generated.
SSM (H1=0010) Send Service
Generation and transit support only. Receipt not supported.
SRV (H1=0011) Service
Message accepted but not generated.
ACI (H1=0100) Additional Call Information
OCM (H1=0101) Operator Condition
UUD (H1=0110) User-to-User Data
SWAP (H1=0111) Swap (between voice/data or different data modes)
Not generated. CFN (Confusion) message sent on receipt.
# (H1=1011) Nodal End-to-End Data Message
Generated only in support of CBWF. Receipt and transit also
supported.
UIS (H1=1100) User Initiated Suspend
UIR (H1=1101) User Initiated Resume

Call Setup and Clearing
Note: The scenarios illustrated are examples. They are

not intended to cover every possible messaging sequence.
Simplest scenario:- En-bloc signalling, CLI not required or provided in IFAM
switch switch
Caller goes
off-hook and
dials number IFAM (Initial and Final Address Message)
Ringing Physical
tone ACM (Address Complete Message) ringing
Called party
ANS (Answer Message) answers
Call in progress
REL (Release message)
Caller goes
on-hook to REL (Release message)
terminate call
Overlap signalling scenario:- Messages sent/received instead of single IFAM

IAM (Initial Address Message)
SAD (Send All Digits)
SAM (Subsequent Address Message)
FAM (Final Address Message)
CLI request scenarios:- Messages sent/received after IFAM / IAM

With overlap signalling, message exchange typically precedes SAD, but ACIs may be
exchanged at any stage of a call.
ACI Type 7 ACI (Additional
Non-interworked Call Information)
(all-CCS7) calls ACI Type 1 (full CLI) or 2 (partial CLI) messages
SASI (Send ASI) ASI (Additional

Interworked Setup Information)
calls ASI Type 2 (CLI typically partial) messages
SIM Type A SIMs (Service

ISDN call Information
originations SIM Type B Messages)
Figure 97: IUP / BTUP messaging for call setup and clearing


BTUP does not have a directly associated feature set, but as the standard interconnect
interface in the UK it provides network support for the following UK public network
features:
! Malicious Call Identification (MCI)
! Operator Override (OOR) / Network Barge-In
! Emergency Calls
! Dynamic Routing Control (DRC)
! Caller Confidentiality (141 service)
! Automatic Recall (1471 service)
! Ring Back When Free (BTUP equivalent of DPNSS Call Back When Free,
supported via NEED messaging)
CS2000 also supports the recording of BTUP CLIs in AMA records for use in
Inter-Administration Accounting (IAA).
Nodal End-to-End (NEED) messaging, as defined in BTNR 1023, allows DPNSS
messages to be conveyed transparently over BTUP trunks. It can therefore be used to
support BES and VPN services in the same way as DPNSS Feature Transparency over
IBN7 trunks. CS2000 can act as a transit node to relay such NEED messages.
E2.4.2 SSUTR2 / FTUP Support
E2.4.2.1 Variants
The French Telephony User Part (FTUP) is the French national variant of CCS7 TUP as
defined in ITU-T Recommendation Q.723. It is also referred to as SSUTR2, and is
formally defined in the following specification:
Specification du Sous-systeme Utilisateur SSUTR2
Functional Step VN4
ST/PAA/CER/SCS/2600
FTUP/SSUTR2 is the French national CCS7 standard for connecting central office
switches within the national PSTN and for interconnect between different network
operators in France.
Table TRKSGRP specifies the characteristics of trunks using FTUP signalling as
signalling type C7UP, external protocol Q767, version 100_BLUE and variant FRANCE.

E2.4.2.2 FTUP Capabilities
Message Support
FTUP uses the H1H0 method of classifying mssages and assigning message header codes,
i.e. messages are grouped by message type (H0) with each message having a unique
identifier (H1) within that message type. CS2000 support for FTUP/SSUTR2 message
types is summarised by the matrix below. In cases, where the French acronym differs from
the English acronym, the French acronym is shown in parentheses below the English one.
Message Group H1
0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1100
[FTUP abbrev.] H0 [1]
Call Charging
0000 CHT [2] ITX [2] TXA [2]
Messages [MT]
Forward Address SAM SAO
Messages [AD] 0001 (MSA) (MSS)
Forward Setup GSM [3] COT CCF
Messages [EA] 0010
(IFG) (CCP) (CCN)
Backward Setup [3]
Request Messages 0011 GRQ
(DEG)
[DE]
Successful Setup CHG [4]
Messages, 0100
Backward [SE] (TAX)
Unsuccessful SEC CGC NNC CFL SSB UNN LOS SST ACB MPR
Setup Messages, 0101
Backward [EE] (EEC) (EFC) (ERN) (ECH) (OCC) (NNU) (LHS) (TSI) (ACI) (INU)
Call Supervision 0110 RAN
Messages [SA] (NRP)
Circuit Group RLG UBL UBA CCR RSC
Supervision 0111 BLO BLA
Messages [SC] (LIG) (DBO) (DBA) (CCD) (RZC)
Network
Supervision 1000 GRS GRA
(RZG) (RZA)
Messages [SG]
End-to-end
1011 MUU [5] MCE [5]
messages [MB]
National Bward
Setup Successful 1100 ACF
Messages [EN]
National IAM for 1101 MIF
ISDN [ET]
National Bward
Setup Failure 1110 SND EAR
Messages [EC]
National Call
Supervision 1111 RIU RAU FIU
Messages [SN]
[1] No messages are defined for H0 = 1001 (9) or H0 = 1010 (10 / hex A).
[2] The CS2000 will acknowledge receipt of a CHT or ITX message by sending a TXA, but the information
contained in the ITX or CHT message will not be included in the AMA record.
[3] In response to a GRQ message, CS2000 sends a GSM message indicating that the requested information is not
available. CS2000 will never send a GRQ message.
[4] Charging information provided in CHG message is not included in the AMA record.
[5] Not supported by CS2000, i.e. the information is not transited end-to-end.

Call Setup and Clearing

Figure 98 illustrates the FTUP messages used to set up and clear a typical call.
Caller goes off-hook

Dialled digits MIF (National IAM)
ACF (National ACM) Ringing
RIU (National ANM) Called party answers
Call in progress
Caller goes on-hook FIU (National Clear Fwd)
RLG
Figure 98: FTUP call setup and clearing
Call clearing can also be initiated as a result of the called party going on-hook, which
causes an RAU (Clear Back) message to be sent back. Possible variations are:
! ISDN called party
FIU sent forward immediately on receipt of RAU.
FIU acknowledged by backward RLG(LIG).
! Analogue called party (national call)
FIU sent forward 3 seconds after receipt of RAU.
! Analogue called party (international call)
FIU sent forward 60 seconds after receipt of RAU (delay determined by T6).

FTUP does not have a directly associated feature set, but as the standard interconnect
interface in France it provides network support for French public network features. This
includes support for two CLIs (NDI and/or NDS) over certain interworkings.
CS2000 allows calls to be billed to the user-provided Designated Supplementary Number
(NDS) rather than the NDI. The NDI is captured in the base AMA record, while the NDS
is captured in an appended type 046 module with source of charge = 5. Controlled by
RBIL0007.

E2.4.3 CTUP Support

CTUP is a variant of the CCS7 TUP (Telephony User Part), as specified in ITU Blue Book
Recommendations Q.721 to Q.725. Requirements specific to China are defined in the
following documents:
! GF 001-9001 Technical Specifications of Signalling System No.7 for the National
Telephone Network of China
! GF 001-9001 Technical Specifications of Signalling System No.7 for the National
Telephone Network of China - Supplementary
Table TRKSGRP identifies trunks using the CTUP agent by means of a signalling type of
C7UP and an external protocol of CTUP.
The following subsections provide a summary of the characteristics and capabilities of the
CS2000 implementation of CTUP. For details, see A89008212.
E2.4.3.1 Message Support

CTUP uses the H1H0 method of classifying mssages and assigning message header
codes, i.e. messages are grouped by message type (H0) with each message having a
unique identifier (H1) within that message type. The message types defined are shown in
the matrix below. CS2000 support for each message is summarised following the matrix.
H1
Message Group 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011
H0
FAM 0001 IAM IAI SAM SAO
FSM 0010 GSM COT CCF
BSM 0011 GRQ
SBM 0100 ACM
UBM 0101 SEC CGC ADI CFL UNN LOS SST ACB DPN
CSM 0110 ANC ANN CBK CLF RAN CCL
CCM 0111 RLG BLO BLA UBL UBA RSC
GRM 1000 MGB MBA MGU MUA HGB HBA HGU HUA GRS GRA
NSB 1100 MPM
NCB 1101 OPR
NUB 1110 SLB STB
NAM 1111 MAL

Forward Address Messages (H0=0001)

IAM (H1=0001) Initial Address Message
IFAM (H1=0010) Initial Address Message with Information
SAM (H1=0011) Subsequent Address Message
SAO (H1=0100) Subsequent Address Message with One Digit
An IAI is used to provide the Calling Line Identity (CLI). The Calling Party Category
(CPC) is included in both IAM and IAI.
Forward Setup Messages (H0=0010)

GSM (H1=0001) General Forward Set-up Information Message
Provides calling party information in response to a backward GRQ.
Backward Setup Messages (H0=0011)

GRQ (H1=0001) General Backward Information Request
Requests calling party information.
Successful Backward Setup Messages (H0=0100)

ACM (H1=0001) Address Complete Message
Unsuccessful Backward Setup Messages (H0=0101)

SEC (H1=0001) Switching Equipment Congestion Message
CGC (H1=0010) Circuit Group Congestion Message
ADI (H1=0100) Address Incomplete Message
CFL (H1=0101) Call Failure Message
UNN (H1=0111) Unallocated Number Message
LOS (H1=1000) Line out of service Message
SST (H1=1001) Send Special Information Tone Message
ACB (H1=0010) Access Barred message
DPN (H1=1011) Digital Path Not provided message
Call Supervision Messages (H0=0110)

ANC (H1=0001) Answer Message with Charge
ANN (H1=0010) Answer Message with No Charge
CBK (H1=0011) Clear Back Message
CLF (H1=0100) Clear Forward Message
RAN (H1=0101) Reanswer Message
CCL (H1=0111) Calling Party Clear Message
Circuit Supervision Messages (H0=0111)

RLG (H1=0001) Release Guard Message
BLO (H1=0010) Blocking Message
BLA (H1=0011) Blocking Acknowledgement Message
UBL (H1=0100) Unblocking Message
UBA (H1=0101) Unblocking Acknowledgement Message
RSC (H1=0111) Reset Circuit Message
Circuit Group Supervision Messages (H0=1000)

MGB (H1=0001) Maintenance Group Blocking
MBA (H1=0010) Maintenance Blocking Ack
MGU (H1=0011) Maintenance Group Unblocking
MUA (H1=0100) Maintenance Group Unblocking Ack
HGB (H1=0101) Hardware failure Group Blocking
HBA (H1=0110) Hardware failure Blocking Ack

HGU (H1=0111) Hardware failure Group Unblocking

HUA (H1=1000) Hardware failure Unblocking Ack
GRS (H1=1001) Group Reset
GRA (H1=1010) Group Reset Acknowledgement
National Successful Backward Set-up Messages (H0=1100)

MPM (H1=0010) Meter Pulse Message
Used to convey meter counts from a generating switch back to the originating switch,
where they are used to update the software meter associated with the calling partys line.
Generation, tandeming and reception of MPMs is supported as described in A89008378.
National Call Supervision Messages (H0=1101)

OPR (H1=0001) Operator Message (tandem support only by CS2000)
National Unsuccessful Backward Set-up Messages (H0=1110)

SLB (H1=0001) Subscriber Local Busy Message
STB (H1=0010) Subscriber Toll Busy Message
E2.4.3.2 Supported Interworkings

Like Chinese ISUP, CS2000 supports both TDM-side and packet-side implementations
of CTUP. Interworking between all four implementations (two ISUP, two TUP) is fully
supported. Interworking is also supported between CTUP and the following:
! IBN lines supported by Askey customer LAN gateways)
! IBN7 ISUP
! China PRI
! SIP without encapsulated CCS7, as used between CS2000 and MCS5200
E2.4.3.3 Service Support

CTUP supports the following supplementary services:
! Calling Number Delivery (CND)
! Diallable Number Delivery (DDN)
! Calling Number Delivery Restriction (SUPPRESS)
E2.4.4 Software Order Codes for TUP

Table 36: Order codes for TUP software
NSUP0021 TUP Variants
PNTK0001 BTUP Version 2
PNTK0002 BTUP Version 2+ (IUP)
PNTK0004 BTUP CLI for AMA
PNTK0008 BTUP Interworking with INAP
PNTK0009 PBX BI Control
PNTK0010 BTUP BC Routing
NSUP0013 SSUTR2 Charge Message Interworking to ISDN

E2.5 MTP, SCCP and TCAP Support

E2.5.1 Message Transfer Part (MTP)
E2.5.1.1 MTP in TDM and Packet Networks

In a TDM network, CCS7 messages (ISUP or TUP) are conveyed between nodes in MTP
Message Signal Units (MSUs), in which MTP protocol information serves as an envelope
around user part messages. The Message Transfer Part performs the functions of Layers
1 to 3, i.e. adding or removing MTP protocol information as required. See section E2.2.1
on page 371 for an illustrated description.
In the packet network, either MTP is not used at all, or MTP User Adaptation (UA)
primitives are used to allow MTP MSUs to be conveyed over the packet network. Three
different types of packet-based CCS7 signalling flow are supported, as described in
section E2.2.2 on page 373 and illustrated in Figure 92 on page 373. To avoid duplication,
the information is not repeated in full here, merely summarised. The three types of
signalling flow supported by CS2000 are:
! Signalling for Inter-CS ISUP and TUP Trunks (see section E2.2.2.1 on page 374)
CCS7 signalling is encapsulated in SIP-T messages to be conveyed across the
packet backbone network. The transport protocol used is either TCP, or UDP with
redirection.
! Intra-CS2000 CCS7 signalling via the CS LAN (see section E2.2.2.2 on page 375)
CCS7 user part messages (ISUP, TUP or TCAP) are conveyed between the USP and
the CS2000 Core using a CCS7 / M3UA / SCTP / IP protocol stack.
! TCAP NCAS (Non Call Associated Signalling) over the packet network (see
section E2.2.2.3 on page 375)
TCAP signalling is conveyed between USPs on peer CS2000s. The protocol stack
used is TCAP / SCCP / MTP3 / M2PA / SCTP / IP.
E2.5.1.2 TDM-side MTP

In a conventional TDM-based CCS7 signalling network, all three MTP layers are used to
support message discrimination, distribution and routing. The functions of each MTP
Layer are as follows:
! OSI Layer 1 / MTP Level 1
Ensuring that bits are transmitted and received at the correct rate (64 Kb/s)
! OSI Layer 2 / MTP Level 2
Ensuring that signalling units are correctly extracted from and inserted into 64 Kb/s
bitstreams, and monitoring the error performance and availability of the link.
! OSI Layer 3 / MTP Level 3 (and optional SCCP)
There are three message handling functions within Level 3 of the MTP:
" Message discrimination
The discrimination function checks all incoming messages to find out
whether they are true incoming messages, i.e. destined for this node.
" Message distribution
The discrimination function passes incoming messages destined for this node

to the distribution function for transfer up to the appropriate user part for
interpretation, e.g. directly to ISUP or TUP, or via the SCCP to TCAP.
" Message routing
The routing function ensures that each outgoing message has the routing
information it needs to reach its destination, then passes it down to Level 2 to be
packaged into a signal unit ready for transmission.
Note: MTP Level 3 Signalling traffic generated at a given node, such as
network management, test and maintenance messages, is also delivered to the
routing function for outward transfer.
SCCP is involved if global title translation is required or in the case of requests for
circuit-independent services. MTP Level 3 and SCCP together are known as the
Network Service Part (NSP).
MTP Level 3 is also responsible for routeset management and linkset management
functions, which detect problems, minimise their impact on the network, and take
appropriate recovery action.
In ISN07, two alternative CS2000 signalling gateway peripherals are available to
terminate TDM-side CCS7 signalling:
TDM-side CCS7 user part messaging terminates on CCS7 link system nodes
in the USP, and the USP distributes messages to the CS2000 Core over the CS
LAN via a CCS7 / M3UA / SCTP / IP protocol stack. In CCS7 terms, the Core
and the USP share the same point code. As far as Core-resident CCS7 user
parts such as ISUP are concerned, M3UA allows messages to be sent and
received exactly as if MTP Layers 1-3 were in use, i.e. the user parts are not
aware that the USP is a separate LAN node.
FLPP Fiberised Link Peripheral Processor
TDM-side CCS7 user part messaging terminates on LIU7s (Link Interface
Units) in FLPP shelves, and the FLPP uses proprietary signalling to convey
messages to XA-Core via the MS.
TDM-side MTP functions are distributed between CS2000 components as follows:
! If the USP is used for CCS7 support, MTP functions are distributed as follows:
" Level 1 and Level 2 functions are provided in the USP by a CCS7 link system
node.
" Level 3 functions are divided between the USP and the Core. All message
handling functions (discrimination, distribution and routing) and some linkset
management functions are supported by the USP. Routeset management
functions and most linkset management functions are provided by the Core.
! If the FLPP is used for CCS7 support, MTP functions are distributed as follows:
" Level 1 functions are provided in the FLPP by a V.35 paddleboard.
" Level 2 functions are provided by the LIU7 in the FLPP.
" Level 3 functions are divided between the LPP and XA-Core. All message
handling functions (discrimination, distribution and routing) and some linkset
management functions are supported by the FLPP. Routeset management
functions and most linkset management functions are provided by XA-Core.

MTP routing capabilities are based on the use of point codes. Each node in a CCS7
signalling network is uniquely identified by means of such a point code. The MTP routing
label of every CCS7 message contains the Originating Point Code (OPC) of the sending
node and the Destination Point Code (DPC) of the receiving node. The Service
Information Octet (SIO) in the MTP routing label contains a 2-bit Network Indicator (NI).
This defines four types of point code domain:
00 International network
01 Spare (for international use only)
10 National network
11 Reserved for national use
CCS7 signalling points (nodes) can exchange MTP Message Signal Units (MSUs) only if
the nodes have different point codes and belong to the same point code domain.
CS2000 supports the MPC (Multiple Point Code) capability, which allows a node to be
assigned up to 31 point codes, which may be all in a single domain or distributed betwen
the four domains. This makes it possible for a CS2000 belonging to a network operator
may also handle traffic for one or more capacity resellers. Assigning a different point code
for each supported reseller allows a single switch to provide several logical Points Of
Interconnect (PoIs).
Typically, a CS2000 belongs to a national public network under the control of a regulator.
Its point code in this network, which corresponds to the point code domain with NI = 10
(national) is assigned by the regulator. Use of point codes in the other point code domains
is typically not regulated. This can include point codes in the domain with NI = 00
(international), which is regulated only for switches used as gateways to the international
public network.
Point code information is datafilled in the following tables:
! Table C7NETWRK
This lists the network appearances supported by the switch, where a network
appearance is defined in one of the four NI-defined point code domains. Up to 16
entries can be defined, with any combination of NI and network types. For each
one, the table defines the network type (CCITT7 or ANSI7 [1]), and specifies the
point code used to identify this node within that network.
Note: The format of the point code specified in C7NETWRK depends on the
network type. ITU identifies signalling points (nodes) by means of 14-bit point
codes in the routing label, while ANSI uses 3-octet / 24-bit point codes. For ITU
point codes, several point code formats are available for interpreting the 14-bit field
(BASIC, INTL, AUSTRIA, CHINA, or GERMAN), but these formats are used only
for point code entry and display. Routing is always performed using all 14 bits.
! Table C7RTESET
This table define two types of mapping for route set names, as obtained from table
ISUPDEST:
" Maps route set on to destination point code.
" Associates route set with network name as defined in table C7NETWRK, thus
making originating point code information available.
[1] Three other network types (NTC7, JPN7 and TTC7) have been defined for use in Japan, but these are not
expected to be used in ISN07.

! Table ISUPDEST
This maps trunk groups on to the route sets used to convey the CCS7 signalling for
those trunk groups.
Figure 99 shows how point code information is obtained from these tables and used to
create the routing label for an outgoing TDM-side message.
Table ISUPDEST
Trunk
group Trunk group CLLI
selected
Route set name
Outgoing message
DPC OPC NI
Table C7RTESET
Route set name
Network name
Destination point code
Table C7NETWRK
Network name
Own NI and point code
Figure 99: Use of MTP datafill in creating outgoing TDM-side message
For each incoming message, the USP or FLPP on the CS2000 compares the DPC of the
message with the point code datafilled in C7NETWRK for the network (point code
domain) in question to decide whether the MSU is destined for the CS2000.
CS2000 compliance with North American MTP standards is defined in the PLS
documents TR82COMP and TR24COMP (these being the numbers of the relevant
Bellcore requirements). CS2000 compliance with ITU-T Recommendations Q.701 to
Q.710 on the MTP is fully documented in Nortel Technical Letter TL96-0026, which is
available in PLS FMDOC under the name MTPCOMP. PLS is an internal Nortel library
and cannot be directly accessed by customers, but documents from it can be made
available in response to customer requests provided that a non-disclosure agreement is in
place.

E2.5.2 Signalling Connection Control Part (SCCP)

The Signalling Connection Control Part complements the MTP by performing some
Layer 3 functions for certain types of calls and service requirements, as follows:
! To support circuit-independent services implemented via TCAP messaging. Service
logic is addressed by means of a PC and SSN (Subsystem Number).
! When the MTP receives SCCP messages from the SS7 network. These messages
are passed to the SCCP so that it can perform Global Title Translation if required,
and the messages are then passed to the appropriate SCCP users.
Note that CS2000 supports only SCCP connectionless messaging (Class 0 or 1), not
SCCP connection-oriented messaging (Classes 2-4). Connection-oriented messaging is
used to establish an end-to-end connection between two users for the transparent
exchange of information between them.
CS2000 compliance with ITU-T Recommendations Q.711 - Q.716 on the SCCP is fully
documented in Nortel Technical Letter TL96-0028, which is available in PLS FMDOC
under the name SCCPCOMP. PLS is an internal Nortel library and cannot be directly
accessed by customers, but documents from it can be made available in response to
customer requests provided that a non-disclosure agreement is in place.

E2.5.3 Transaction Capabilities Application Part (TCAP)

TCAP interfaces with application processes at the top of the protocol stack. Strictly
speaking, it operates only at Layer 7 (as shown in Figure 90 on page 369), but because
Layers 4 to 6 are currently null (i.e. no information is added or removed as data passes
through them) it could also be regarded as straddling Layers 4 to 7. CS2000 uses it to
support circuit-independent services such as database queries, as follows:
! Interaction with Intelligent Network (IN) applications via the IN Application Part
(INAP), for which INAP operations are exchanged in TCAP components and
messages. This involves communication between a CS2000 SSP and a central
Service Control Point, typically to obtain routing information to complete a call.
The protocol used is CS-1R INAP over an ITU-T Blue Book protocol stack.
! Direct interaction with application-specific logic for supplementary services:
" Communication between CS2000 and other switch types via ITU-T TCAP to
support open implementations of services such as Call Completion to Busy
Subscriber (CCBS).
" Communication between two CS2000s via ANSI TCAP to support
proprietary implementations of services such as Networked Automatic Call
Distribution (NACD) and network MWI for voice mail.
The protocol stack used for TCAP signalling over a conventional CCS7 signalling
network is TCAP / SCCP / MTP1-3. CS2000 can support the termination of such
signalling either via the USP or the FLPP.
The protocol stack used for TCAP signalling over the packet network is TCAP / SCCP /
MTP3 / M2PA / SCTP / IP. CS2000 can support this only via the USP. There must be a
dedicated Ethernet connection between the USPs on the peer CS2000s. See section
E2.2.2.3 on page 375 for further information.
Note: Although TCAP NCAS (Non Call Associated Signalling) across the packet
network is supported in ISN07, services that rely on it must be productised before
deployment. INAP over TCAP is not supported over the packet network.
The following table summarises the differences between the ITU-T and ANSI definitions
of TCAP.
TCAP variant Messages/Packages Components Numbers
Invoke, Variable-length
ITU-T TCAP BEGIN, CONTINUE, END, ABORT Return Result,
Return Error, Reject numbers
QUERY (+ Permission to terminate), As for ITU-T, but both Fixed-length

CONVERSATION Invoke and Return 10-digit
ANSI TCAP (+ Permission to terminate), Result may be (Last) or numbers
RESPONSE, ABORT (Not Last) (as in NA)
CS2000 TCAP support is summarised in document N7TCACMP in PLS FMDOC. PLS

is an internal Nortel library and cannot be directly accessed by customers, but documents
from it can be made available in response to customer requests provided that a
non-disclosure agreement is in place.

Chapter E3 INAP
E3.1 Functional Description

E3.1.1 IN Functional Elements
INAP signalling is used for peer-to-peer communication over a CCS7 signalling network
between the following IN functional elements:
SCF Service Control Function
IN services are implemented by means of service logic and a database under SCF
control. The SCF responds to service requests from the SSF, e.g. by providing
routing information to complete a call. The SCF resides on an SCP (Service Control
Point) node. The CS2000 SSP can support interaction either with SCF functionality
provided by a third-party SCP or with the SCF component of the Nortel
ServiceBuilderTM range of integrated IN products.
SSF Service Switching Function
The SSF provides the interface between the PSTN and the IN. It is responsible for
recognising PSTN calls that require IN service processing, and for interacting with
CCF call processing and SCF service logic to ensure that those calls are successfully
completed. The SSF resides on an SSP (Service Switching Point) node such as the
CS2000, which performs both IN and switching tasks.
IN triggering is supported both for incoming SIP-T calls and for TDM-side calls.
SRF Specialised Resource Function
The SRF provides any specialised resources that are required for interaction with
the end user, either to provide information or to obtain it. Information is typically
provided in the form of announcements or tones, and is typically collected as dialled
digits. The SRF resides on an Intelligent Peripheral (IP). In the CS2000 network
architecture, IP capabilities can be provided as follows:
" By an integrated IP belonging to the CS2000 SSP:
# Announcements are provided by an MS2000/UAS media server
# Tones are provided by media gateways under CS2000 control
These separate nodes are perceived by the SCP as integral to the CS2000 SSP.
" By a completely separate external IP.
CCF Call Control Function
The CCF is not an IN functional element, but a standard Basic Call State Machine
(BCSM) for which trigger criteria are defined that determine the conditions under

INAP Telephony Interfaces Communication Server Capabilities
which a given call requires IN service access. Because it interacts closely with the
SSF, the CCF resides with the SSF in an SSP node.
Another node type involved in handling IN is the STP (Signalling Transfer Point). No IN
functions are allocated to STPs, but IN traffic between SSPs and SCPs may be relayed via
STPs. Figure 100 illustrates IN node types and functional elements.
IN SCP SCP
SCF SCF
Node types: IN functions:

SCP Service Control Point SCF Service Control Function
SSP Service Switching Point SSF Service Switching Function
IP Intelligent Peripheral STP STP SRF Specialised Resource Function
STP Signalling Transfer Point CCF Call Control Function
SSP SSP SSP External IP SSP

Integrated Integrated Integrated
SSF IP SSF IP SSF SSF IP
SRF
SRF SRF SRF
CCF CCF CCF CCF
PSTN
Note: The integrated IP is a separate node, not a CS2000 component, but this is not visible to the
SCP. Packetised announcements are provided across the packet network by the MS2000 or UAS,
which is an independent media server, but from the perspective of the SCP all INAP operations
intended for the integrated IP are sent to and handled by the CS2000 SSP. When the SCP issues
instructions for the integrated IP to collect digits, in-band digit collection (supported only over ISUP
and PRI in ISN07) is performed by the originating media gateway.
Figure 100: CCS7 Node Types and IN Functional Elements
E3.1.2 INAP Specifications

The CS2000 SSP implementation of INAP is based on CS-1R INAP as defined in ITU-T
Recommendation Q.1218, issue 10/95. This specification defines the format and content
of INAP operations (using ASN.1 notation), and specifies when and why operations
should be sent. It also defines each IN functional element as a state machine (or an
integrated set of state machines), and describes how the sending and receiving of
operations affects the state machines involved.
The CS-1R BCSM supported by the CS2000 SSP is defined in Q.1214.
Call party handling capabilities are CS-2 capabilities defined in Q.1224 (the CS-2
equivalent of Q.1214) and Q.1228 (the CS-2 equivalent of Q.1218).
The subset of CS-1R INAP supported by the CS2000 SSP is also compatible with ETSI
Core INAP, as defined in ETS 300 374.

Communication Server Capabilities Telephony Interfaces INAP
In addition to standard CS-1R INAP, the CS2000 SSP supports a number of national
INAP variants. These are typically distinguished by having different requirements for
network-specific operations such as ApplyChargingReport, which can be used by the
SCP to control the billing performed by the SSP. The INAP variant in use on a given
CS2000 is determined by OFCENG parameter INAP_VARIANT, which can be set to
DFLTINAP (the default), CHINESE, TELEFONICA (Spain), TINAP (German) or
INDIAN.
E3.1.3 Peer-to-Peer Communication using INAP

INAP resides at the Application Layer (Layer 7) of the OSI 7-Layer model, and is
supported by other protocols at lower layers. Peer-to-peer communication between INAP
functional elements, e.g. the SSF and the SCF, is based on exchanging INAP operations.
The other protocols involved are:
! Transaction Capabilities Application Part (TCAP)
! Signalling Connection Control Part (SCCP)
! Message Transfer Part (MTP)
Each new INAP operation is contained in a TCAP Invoke component. One or more
Invoke components may be packaged into a TCAP message. Typically, the SSP uses a
BEGIN message to initiate a dialogue with the SCP, and subsequent operations are
exchanged in CONTINUE messages. A dialogue may come to a prearranged end or be
terminated by means of an explicit END message.
Each TCAP message is packaged into an SCCP UNITDATA message, and this is in turn
packaged into an MTP Message Signal Unit (MSU) to be conveyed between nodes. The
complete protocol stack is illustrated in figure 101 on the following page. See Chapter E2:
CCS7 Interfaces for general information about CS2000 support for CCS7.
Note: INAP cannot be conveyed across the backbone packet network in ISN07. TCAP
NCAS (Non Call Associated Signalling) is supported across the packet network between
peer CS2000s, but not between a CS2000 and an SCP. The information in this section
therefore applies only to CS2000 support for TDM-side TCAP.
Even if an STP is involved in relaying IN operations, it is simpler and more convenient to
regard the SSP as communicating directly with the SCP, because no IN processing takes
place at the STP.
For the CS2000 SSP, communication between the SSF and the SRF does not involve
exchanging INAP operations. There are two scenarios:
! Integrated IP
SRF functionality is provided as follows:
" Announcements are provided by an MS2000/UAS media server
" Tones are provided by media gateways under CS2000 control
These separate nodes are perceived by the SCP as integral to the CS2000 SSP.
Although the media server and media gateways are separate packet network nodes,
this is not visible to the SCP. From the perspective of the SCP, all INAP operations
intended for the integrated IP are sent to and handled by the CS2000 SSP.
When the CS2000 SSF receives an INAP SRF operation from the SCP requesting
the playing of a tone or announcement, it initiates an appropriate non-IN request for
this to be played. For an announcement, a request to the media server is made via

H.248. For a tone, a request to the appropriate media gateway is made via a
device-media control protocol such as ASPEN.
When the SCP issues instructions for the integrated IP to collect digits, in-band digit
collection (supported only over ISUP and PRI in ISN07) is performed by the
originating media gateway.
! External IP
SRF functionality provided by a completely separate TDM-side node. The CS2000
SSP first uses PRI, ETSI ISUP, IBN7 or BTUP to establish a connection with the
external IP. INAP operations are then exchanged directly by the SCF and SRF, with
no SSP involvement.
Figure 101 illustrates the protocol stack used for peer-to-peer communication between IN
functions on different nodes.
SSP SCP
Logical peer-to-peer
OSI Layers SSF protocol stack communication SCF protocol stack
INAP INAP
Intelligent Network Intelligent Network
Application Part INAP operations Application Part
Component sub-layer Component sub-layer

TCAP components
Layer 7 (Invoke, Return Result,
Application TCAP TCAP
Transaction Return Error, Reject) Transaction
Capabilities Capabilities
Application Application
Part Part
TCAP messages
Transaction sub-layer (BEGIN, CONTINUE, END, ABORT) Transaction sub-layer
Layer 6
Presentation
Layer 5
Session
Layer 4
Transport
SCCP SCCP
Layer 3 Signalling Connection Signalling Connection
Control Part SCCP UNITDATA messages Control Part
Network
Layer 2 MTP MTP

Datalink Message Transfer Message Signal Units (MSUs) Message Transfer
Part Part
Layer 1
Physical
IN signalling link
Physical node-to-node communication
Figure 101: Peer-to-peer communication between IN nodes

E3.1.4 Interaction between Call Processing and IN

E3.1.4.1 IN Triggering and Query Handling
For IN purposes, the call processing performed by the CCF is modelled by means of a
standard Basic Call State Machine (BCSM). This defines all the possible stages in the
processing of a call, which are known as Points In Call (PICs). It also defines all the
possible transitions between stages and the events that cause these transitions.
Two different BCSMs have been defined:
! The Originating BCSM (O_BCSM) models call processing for call originations that
trigger as IN calls.
! The Terminating BCSM (T_BCSM) models call processing for terminating calls
that trigger as IN calls.
Some BCSM events are potentially visible to the SSF. These are known as Detection
Points (DPs). They can be armed in either of two ways to support interaction between call
processing and IN:
! A DP can be armed as a Trigger Detection Point (TDP) by means of static
datafill-defined trigger criteria. Such TDPs are used to select certain calls, e.g.
incoming calls to numbers beginning with 0800, for IN call handling. If a trigger
criterion is matched during the processing of a call, the call is said to have triggered;
call processing is then suspended while the SSF initiates a dialogue with the SCF to
find out how to handle the call.
! A DP can be armed as an Event Detection Point (EDP) at the request of the SCF.
Such EDPs are used to detect call processing events, e.g. successful or unsuccessful
completion of an IN-routed call, and report them to the SCF.
When call processing is interrupted at a DP, the SSF informs the SCF by sending it an
INAP operation, enabling the SCF to determine what should be done next. See section
E3.2.1 on page 430 for information about the INAP operations supported by the CS2000
SSP. See section E3.2.2 on page 438 for information about CS2000 SSP support for DPs.

Figure 102 provides an overview of triggering and query handling for the simplest type
of query (single-stage call setup triggered on full CdPA).
CCF / BCSM) SSF SCF

INAP operation
Calling party parameters
Dialled digits
(out-of-band) Digit manipulation
via CS2000
translations
IN query triggered SSF sends

on translated CdPA InitialDP Mandatory service key,
optional CdPA
Result of IN query SCF sends

used to manipulate Connect
Mandatory
CdPA: DestinationRoutingAddress (DRA),
Complete optional CutAndPaste to replace prefix
replacement of
CdPA by DRA
Cut-and-paste
replacement of
CdPA prefix by
DRA
Called party
Onward Digit manipulation
routing via CS2000
translations
Figure 102: Overview of IN query handling
In ISN07, IN triggering via the O_BCSM is supported for the following types of call
origination:
! Incoming ISUP and TUP calls (TDM-side and SIP-T)
! Incoming PRI and QSIG calls
! Incoming calls from analogue lines
IN triggering via the T_BCSM is supported for calls terminating on analogue lines.

E3.1.4.2 Interactions between Software Entities at the SSP

The CS2000 SSP can support interaction either with call originations or with call
terminations, as described in the following subsections.
This view of interaction between software entities applies to single-segment calls, with
one leg back to the caller and one leg on to the called party. The CS2000 SSP implements
selected Call Party Handling (CPH) capabilities that allow calls with two segments to be
created and manipulated. For such calls, the interactions between software entities is more
complex. See section E3.2.1.6 on page 435 for a discussion of CPH capabilities, and
Figure 105 on page 436 for an illustration of the impact of CPH on the interaction between
software entities.
IN Triggering and Call handling for Call Originations

Figure 103 provides a functional view of the handling of a call origination that triggers as
a CS-1R IN call at the CS2000 SSP, showing the interactions between the software
entities involved.
SCP
SCF
INAP operations
SSF
(SSF FSM) CS2000 SSP
INAP
interworking
CCF
(O_BCSM)
Originating Basic call Terminating

agent interworking agent
Incoming call Onward routing
Leg 1 of call Leg 2 of call
(before triggering) (onward routing)
Figure 103: Basic IN triggering and call handling for call originations
Points to note:
! Call processing for call originations is modelled using the O_BCSM.
! Information about leg 2 of a call is obtained via the basic call interworking, and
provided to the SSF via the O_BCSM.

! The controlling leg of the call is the leg on which IN triggering took place, i.e. the
leg back to the caller.
IN Triggering and Call Handling for Call Terminations

Figure 104 provides a functional view of the handling of a call termination that triggers
as a CS-1R IN call at the CS2000 SSP, showing the interactions between the software
entities involved.
SCP
SCF
INAP operations
SSF
(SSF FSM)
CS2000 SSP
INAP
interworking
CCF
(T_BCSM)

Incoming call Call completion
(initially non-IN) (after triggering)
Figure 104: Basic IN triggering and call handling for call terminations
Points to note:
! Call processing for call terminations is modelled using the T_BCSM.
! Information about leg 1 of a call is obtained via the basic call interworking, and
provided to the SSF via the T_BCSM.
! The controlling leg of the call is the leg on which IN triggering took place, i.e. the
leg to the called party.
Note: If IN processing results in the onward routing of a call, the T_BCSM for the
original destination reverts to being an O_BCSM associated with the call origination.

E3.2 CS2000 Implementation

E3.2.1 INAP Operation Support
E3.2.1.1 SIngle-Stage Call Setup Operations
Simple Call Completion with SCP-Provided Number

Operations involved in the most basic type of successful IN query, from the initial
recognition that IN assistance is required to the provision of routing information.
! InitialDP
Asks the SCF to provide the routing information needed to complete a call.
In ISN07, InitialDP can be used to report IN triggering for incoming ISUP and TUP
calls (TDM-side and SIP-T), PRI calls, and calls from analogue lines supported off
customer LAN gateways or V5.2 ANs.
! Connect
Tells the SSF to route a call to a specified destination, thus successfully completing
an IN query.
The following subsections discuss INAP operations that could be received by the CS2000
SSP during single-stage call setup, as additions or alternatives to the simple InitialDP /
Connect sequence.
Continuation of Call Processing with the Original Called Number

There are some types of IN-based screening service for call originations after which call
establishment continues using the number originally dialled by the caller. Examples are
CLI screening, where the aim of the IN service is simply to check that the caller is
authorised, and Local Number Portability (LNP) screening, after which calls to
non-ported numbers require no rerouting.
In such cases, the SCF sends a Continue operation instead of a Connect, which causes the
SSP to return control to the CCF/BCSM so that call processing can resume from where it
was interrupted.
A Continue operation is also sent instead of a Connect when IN triggering takes place for
a call termination.
Call Clearing
When the SCF processes an IN query initiated by InitialDP, it may decide that that the call
cannot or should not be completed. In this case, it sends a ReleaseCall operation instead
of a Connect, which causes the SSP to clear the call.

Call Completion after Call Termination Triggering

When IN triggering occurs for a call termination, routing information is not required from
the SCP provided that the call can be completed to its intended destination. Instead, the
aim of initiating interaction with the SCP is to allow it to provide caller information to the
called party using mechanisms that are not available via standard call processing. In
ISN07, for example, the SCP can present caller information to the called party on the
screen of a digital TV, and the called party can accept the call in the usual way, or can use
the interactive capabilities of the TV to reject or forward the call.
The mechanism used to support this is that the SCP sends a Continue operation after
triggering takes place. This returns control to the CCF/BCSM so that the call can be
presented to the called partys phone at the same time as the caller information is
displayed on the TV.
If the called party rejects the call via the digital TV, the SCP sends a ReleaseCall
operation to terminate the dialogue with the SSP. If the called party forwards the call, the
SCP sends a DisconnectLeg operation to disconnect the original called party, followed
by a Connect operation specifying the forward-to number.
Note: If IN processing results in the onward routing of a call, the T_BCSM for the
original destination reverts to being an O_BCSM associated with the call origination.
Billing
AMA base records and appended modules are used as follows for IN calls:
! The x051x base AMA record stores the called party number as modified/provided
by Connect.
! An appended module stores the digits dialled by the calling party. The type of
module to be appended is determined by service datafill, typically on the basis of
the number of dialled digits to be stored: type 28 module (up to 15 digits), type 40
module (up to 24 digits), or type 612 module (up to 30 digits).
! An appended type 611 module can store an IN billing correlation ID to enable
different billing records for an IN call connected to a sequence of terminations
(follow-on calls) to be correlated.
! Up to 200 bytes of billing data conveyed in one or more
FurnishChargingInformation (FCI) operations can be stored in type 199
modules appended to the base record. Each type 199 module can contain up to 20
bytes of billing data, and up to ten type 199 modules can be appended to an AMA
record. There is a proprietary Nortel-defined format for billing information
provided in an FCI operation, but the CS2000 SSP will also accept FCI billing
information in any required third-party format (in which case the data is simply
repackaged and relayed).
The CS2000 SSP also supports the use of the SendChargingInformation (SCI)
operation, which is sent by the SCP to the SSP to tell it to provide information to be used
in billing a specified call leg. The charging information provided by the SCP can be either
a charge band to be included in an ISUP message or an instruction that a certain number
of metering pulses should be generated. Support for the SCI operation is a generic INAP
capability, but was initially implemented by ISN07 feature A00004934 to meet
India-specific charging requirements for IN calls.

The CS2000 SSP also supports operations that allows the SCP to provide billing
instructions and be informed of the charges actually applied:
! ApplyCharging (AC)
Sent from the SCF to the SSF to provide billing instructions for a given IN call.
Can also be used to specify a maximum conversation time, e.g. if only a limited
amount is left on a calling card. This causes the SSP to play a warning tone or
announcement before the timer expires.
! ApplyChargingReport (ACR)
Sent from the SSF to the SCF to provide information about the AC-specified
charges applied to that call.
Note: The CS-1R INAP specification does not specify the information to be requested
via ApplyCharging and provided via ApplyChargingReport. The ApplyCharging formats
and behaviour to be supported in a given network are specified by the regulator or the
network operator. CS2000 supports a range of ApplyCharging formats to meet the
requirements of a range of national markets.
Miscellaneous Control Operations

These enable the SCF to exercise closer control over the handling of a call attempt. They
can be used in conjunction with single-stage or two-stage call setup, and also with call
monitoring.
! ResetTimer
Sent from the SCF to the SSF to reset the SSF guard timer, avoiding the possibility
of timer expiry interfering with service logic, e.g. during prolonged user interaction
or during SCF referral of a query to another SCF.
! ActivityTest (AT)
Sent from the SCF to to SSF to verify that a dialogue is still active, in which case
the SSF sends a Return Result to the SCF as confirmation.

E3.2.1.2 Two-Stage Call Setup Operations (In-Band Interaction with the Caller)
Operations sent by the SCF to initiate and control direct in-band interaction between the
calling party and the SRF, typically the playing of a tone or announcement. There are
three stages:
1 Setting up the connection between the SRF and the user
" ConnectToResource (connect to integrated IP / originating media gateway)
" EstablishTemporaryConnection (connect to external IP via PRI, ETSI
ISUP, IBN7 or BTUP)
2 SCF-controlled user interaction (operations handled by CS2000 only for user
interaction via the integrated IP)
" PlayAnnouncement (play specified tone or announcement), optionally
followed by SpecializedResourceReport when tone/announcement has been
played.
CS2000 can convert Price data specified by the SCP in a PA operation into
MCMP Money data to be conveyed from the audio GWC to the UAS via
H.248. This enables CS2000 to provide language and currency tokens for use
in assembling complex/variable announcements. See A19012479.
" PromptAndCollectUserInformation (play specified tone or announcement
and collect digits), followed by ReturnResult(P&C) to return collected digits
Note: Digit collection is supported only for ISUP and PRI call originations.
Integrated IP functionality is provided by separate packet network nodes, not by
CS2000 components, but this is not visible to the SCP. Responsibilities are:
" Tones are played by the appropriate media gateway
" Announcements are played by the UAS
" Digits are collected by the originating media gateway.
When the CS2000 SSF receives a PA or P&CUI operation from the SCP, it initiates
a non-IN request to the UAS for an announcement to be played. After a PA, it can
send a SpecialisedResourceReport operation back to the SCP to report that the
announcement has been played. After a P&CUI, it sends a Return Result to provide
the dialled DTMF digits collected by the originating media gateway.
The CS2000 SSP supports the use of the Cancel operation, which the SCP can use
to request the SSP to cancel a specified outstanding PA or P&CUI request. This is
a generic INAP capability, but was initially implemented by ISN07 feature
A00004934 to meet Indian requirements.
3 Taking down the connection between the SRF and the user
" DisconnectForwardConnection
Note: The DMS SSP also supports SRF-initiated disconnect, in which the SRF
notifies the SSF when user interaction has finished, and there is no need for an
explicit DFC operation from the SCF.
If required, the CS2000 SSP can create or update a billing record for the part of a call when
user interaction takes place.

E3.2.1.3 Monitoring Control Operations

Operations for requesting and providing information about the outcome of a call attempt.
Two types of monitoring are supported:
! Monitoring the outcome of a call attempt for the occurrence of specified call
processing events (e.g. successful completion or line busy), so that appropriate
action can be taken depending on the result. Operations used:
" RequestReportBCSMEvent (report specified event when it occurs)
" Event ReportBCSM (specified event has occurred)
! Monitoring a call attempt until the call is finished or until the attempt has failed,
then providing specified information about it (e.g. call setup time or call connection
time). Operations used:
" CallInformationRequest (provide specified information)
" CallInformationReport (specified information included)
The CS2000 SSP supports the use of the Cancel operation, which the SCP can use to
request the SSP to cancel all outstanding monitoring requests (RRBEs, CIRQs and
ACRs). This is a generic INAP capability, but was initially implemented by ISN07 feature
A00004934 to meet Indian requirements.
E3.2.1.4 Operations for Controlling Digit Collection

In an overlap signalling scenario, particularly for VPN calls using a fixed-length private
number plan, the SCP can tell the SSP how many digits it needs to collect in order to
complete a call. This means that call completion can proceed as soon as the required
number of digits have been collected, rather than having to wait for an end-of-number
indication or inter-digit timeout expiry. Post-dial delay is therefore reduced.
Initial triggering takes place on the basis of a partial called number (typically a VPN
prefix or location code), and is notified to the SCP via InitialDP. The SCP then sends a
RequestReportBCSMEvent operation to specify the required number of digits, followed
by a CollectInformation operation to tell the SSP to resume call processing. When the
required number of digits have been collected, they are conveyed to the SCP in an
EventReportBCSM, and it can respond with a Connect.
The effect is to reduce the post-dial delay attached to IN calls that originate on trunks
using overlap signalling, as routing can take place before dialling is finished. This
functionality is supported on all IN triggering agents that support overlap inpulsing, i.e.
all agents except IBN7.

E3.2.1.5 Call-Independent Operations

These operations enable the SCF to delegate IN call handling to the SSF and be informed
of results.
! ActivateServiceFiltering
Tells the SSF to handle all calls of a specified type, e.g. all calls to a particular range
of numbers, and to record how many calls are made to each number.
! ServiceFilteringResponse
Tells the SCF how many calls have been made to each number in a range.
! CallGap
Sent from the SCF to to SSF to delegate control (slow down rate of call arrival).
Call gapping prevents overload by limiting the number of calls made to a particular
destination or from a particular origin. The SCF sends the SSF a CallGap operation
to tell it which calls to intercept and how to handle them, and to specify the call
gapping interval.
While call gapping is active, the SSF checks calls against the specified gap criteria.
Only one call that matches the gap criteria is allowed through to the SCF in each
gap interval. Calls not allowed through to the SCF are routed to treatment (typically
a tone or announcement).
The capability of limiting the number of calls handled in a specified period can be
used either to manage short-term traffic peaks or to ensure that a given level of
service is maintained.
E3.2.1.6 Call Party Handling (CPH) Operations

These enable the SCF to control the connectivity and processing of an IN call.
In the simplest type of IN call, there is one controlling leg (back to the caller) and one
passive leg (on to the called party), as described and illustrated in section E3.1.4.2 on page
428. The CS2000 SSP implements selected Call Party Handling (CPH) capabilities that
allow calls with two segments to be created and manipulated. For such calls, the
interaction between software entities is more complex.
Assume, for example, that a caller wishes to interrupt an IN call to set up a second call to
a third party. To allow the second call to be set up, the existing call is split into two
segments, one for the active caller and one for the original called party who has been put
on hold. In terms of interaction between software entities, the characteristics of such a
two-segment call are as follows:
! Two segments
! Segments linked in a Call Segment Association (CSA)
! Two O_BCSMs
! Two SSF FSMs

Figure 105 provides a functional view of the handling of a two-segment IN call at the
CS2000 SSP, showing the interactions between the software entities involved.
SCP
SCF
INAP
operations
Target SSF FSM for INAP
operations from SCP is
determined by legID or
csID parameter
CSA
Two SSF FSMs,
one for each SSF FSM SSF FSM CS2000 SSP
call segment
Second SSF FSM and
O_BCSM created when INAP INAP
leg is split off from interworking interworking
stable call
Terminating
Two O_BCSMs, Leg 3 of call
one for each O_BCSM O_BCSM
agent
(added later)
call segment
Basic call
interworking

Incoming call Onward routing
(before triggering) (onward routing)
Figure 105: Interactions between software entities for a two-segment IN call

The CS2000 SSP supports Call Party Handling capabilities in the following ways:
! By recognising a # or * dialled by the caller as an interrupt signal (this is
implemented by using RequestReportBCSMEvent to request monitoring for an
O_Mid_Call event).
! By supporting three CS-2 CPH operations that explicitly control the connectivity of
a call:
" SplitLeg
Tells the SSF to detach one call party from an existing call into a new, separate
call segment.
" MergeCallSegments
Tells the SSF to combine two call segments into a single call.
" DisconnectLeg
Tells the SSF to disconnect a specified call party from a call, leaving the call
to continue with the other parties involved.
" CreateCallSegmentAssociation
Sent from the SCF to the SSF to a create a new, null CSA in which an
SCP-initiated call attempt can be set up.
" InitiateCallAttempt
Sent from the SCF to the SSF to initiate a new call instance, either in a newly
created null CSA or within the context of an existing call (typically to verify
that an IN call can be successfully completed before the caller is connected to
the destination).
! By allowing other operations to specify a legID and/or csID parameter to indicate
which leg or segment is to be affected by the operation.
! By supporting CS-2 variants of operations whose CS-1R variants do not allow a
legID or csID parameter to be specified. There are two of these:
" DFCWithArgument (DFCWA)
Tells the SSF to disconnect the SRF connection for a call segment.
" ContinueWithArgument (CWA)
Tells the SSF to resume normal call processing for a call segment.

E3.2.2 Detection Point Support
E3.2.2.1 DPs and BCSMs

Detection Points (DPs) are points where the processing of a call can be interrupted to
allow IN interaction to take place. Call processing is modelled either by the Originating
BCSM (O_BCSM) or by the Terminating BCSM (T_BCSM) depending on whether IN
involvement is triggered for a call origination or a call termination. Each of these BCSMs
has a set of DPs that determine where the call processing modelled by that BCSM can be
interrupted, as summarised in Table 37.
Note: Some call processing events can in theory be detected via either BCSM, in which
case the DP used would depend on whether the O_BCSM or T_BCSM is in use. The
CS2000 SSP, however, does not support T_BCSM EDPs in ISN07.
Table 37: CS2000 SSP support for O_BCSM and T_BCSM DPs
Can be detected / reported via
Call processing event
O_BCSM DP T_BCSM DP
Trigger Detection Points (TDPs) used to initiate IN interaction
Dialled digits available TDP-2
(Collected_Info)
TDP-3
Translated digits available
(Analyzed_Info)
No route available TDP-4
(e.g. network congestion) (Route_Select_Failure)
Call termination authorised TDP-12
(Term_Attempt_Authorized)
Event Detection Points (TDPs) used to detect and report monitored events
EDP-2
Dialled digits available (Collected_Info)
No route available EDP-4
(e.g. network congestion) (Route_Select_Failure)
EDP-13
EDP-5
Called party found to be busy (O_Busy) (T_Busy)
Not supported in ISN07
EDP-14
EDP-6
No answer from called party (T_No_Answer)
(O_No_Answer)
EDP-7 EDP15
Called party answers (T_Answer)
(O_Answer)
EDP-16
Call party interrupts EDP-8
(T_Mid_Call)
active call (O_Mid_Call)
EDP-17
Call party disconnects EDP-9
after call is answered (O_Disconnect) (T_Disconnect)
EDP-18
Caller hangs up EDP-10
(T_Abandon)
before call is answered (O_Abandon) Not supported in ISN07

E3.2.2.2 Trigger Detection Point (TDP) Support
IN Triggering for Call Originations

The CS2000 SSP supports the arming of three O_BCSM DPs as TDPs:
! TDP-2 (Collected_Info), which is encountered before translations. Criteria that
may be associated with TDP-2 for conditional triggering are:
Specific digit string
Feature code
It is also possible for calls to trigger unconditionally at TDP-2.
! TDP-3 (Analyzed_Info), which is encountered after translations. The criterion
associated with TDP-3 for conditional triggering is:
Specific called party number string
Screening is performed on translated dialled digits. The most significant N digits are
compared against datafilled trigger criteria.
! TDP-4 (Route_Select_Failure), which is encountered when a release indication is
received from the network. Triggering must be conditional, on the basis of the cause
value in a REL message received over an ETSI ISUP trunk. In ISN07, triggering at
TDP-4 cannot be caused by RELs for other trunk types or by internal routing failure.
Trigger criteria can be specified at two levels for TDPs:
! Switch
All incoming calls are checked against common trigger criteria.
! Trunk group
All incoming calls on a given trunk group are checked against specified trigger
criteria.
IN Triggering for Call Terminations

The CS2000 SSP supports the arming of one T_BCSM DP as aTrigger Detection Point
(TDP):
! TDP-12 (Term_Attempt_Authorized), which is encountered when a call is
presented to a subscriber line and IN triggering has been specified for calls
terminating to that line.

E3.2.2.3 Event Detection Point (EDP) Support
Arming of EDPs
EDPs are set up (dynamically armed) in response to a request from the SCF. The request
is made via an RequestReportBCSMEvent operation specifying:
! One of two monitoring modes:
" NotifyAndContinue
This causes the EDP to be armed as an EDP-N, i.e. call processing will
continue after the SCF has been notified that the event has taken place.
" Interrupted
This causes the EDP to be armed as an EDP-R, i.e. call processing will await
further instructions from the SCF (e.g. connect to alternative number) after it
has been notified that the event has taken place.
! The call leg for which the EDP is to be armed, which is one of:
" The controlling leg, typically the call leg back to the caller (leg 1)
" The passive leg, typically the call leg to the called party (leg 2)
O_BCSM EDPs Supported

The CS2000 SSP supports monitoring requests for the following O_BCSM EDPs:
! EDP-2 (Collected_Info) armed as an EDP-R for leg 1
! EDP-4 (Route_Select_Failure) armed as an EDP-R or EDP-N for leg 2
! EDP-5 (O_Busy) armed as an EDP-R or EDP-N for leg 2
! EDP-6 (O_No_Answer) armed as an EDP-R or EDP-N for leg 2
! EDP-7 (O_Answer) armed as an EDP-N for leg 2
! EDP-8 (O_Mid_Call) armed as an EDP-R or EDP-N either leg 1 or leg 2 (but not
for both)
The only event that can be detected is an interrupt tone, resulting from a call party
pressing the * or # key to request SCF intervention in the call. The interrupt tone
can be followed by IN service code digits that indicate where a call should be
routed.
! EDP-9 (O_Disconnect) armed as an EDP-R or EDP-N for leg 1 or leg 2
! EDP-10 (O_Abandon) armed as an EDP-R or EDP-N for leg 1
T_BCSM EDPs Supported

The CS2000 SSP does not support T_BCSM EDPs.

E3.2.3 Support for Application Context Negotiation

With effect from ISN07, the CS2000 supports Application Context Negotiation (ACN) as
part of the process of establishing a TCAP dialogue for the purpose of IN interaction.
CS2000 ACN capabilities are initially intended for deployment in China (see A00002754)
and in the T-INAP network in Germnay (see A00002907), but ACN is a generic capability
that is potentially available for other networks and customers.
An Application Context (AC) comprises one or more Application Service Elements
(ASEs), each of which defines a sequence of one or more operations used to perform a
particular task. An AC can therefore be used to define the set of tasks and task-related
operations used to support an IN service. Given such an AC-based service definition,
Application Context Negotiation can be used to screen incoming TCAP packages and
INAP operations to check that they are associated with a valid AC, and to abort the TCAP
dialogue if they do not.
The establishment of an INAP dialogue involves two application processes, one defined
as the dialogue initiator and one defined as the dialogue responder. The dialogue initiator
ecncodes the appropriate ACN value into the TC-BEGIN package used to begin the
dialogue. TCAP processing of the TC-BEGIN package by the dialogue responder will
succeed only if the responder supports the encoded ACN value; otherwise, the dialogue
will be aborted.
While a dialogue remains active, each INAP operation received by either participant is
checked against the list of operations defined by the AC. If an operation is received that
is not associated with the correct AC, the dialogue is aborted.
ACN rules supported by the CS2000 SSP for SSP-initiated dialogues:
! When SSP sends TC-BEGIN package to initiate dialogue, it encodes the correct
ACN into the package and stores the ACN value.
! When SSP receives the first response from SCP in TC-CONTINUE / TC-END
package, TCAP component processing proceeds only if the ACN value matches the
ACN value of the previous TC-BEGIN. Otherwise, the SSP aborts the dialogue.
! If the first response received from the SCP is a TC-U-ABORT package, the SSP
releases the dialogue.
The CS2000 SSP can also support SCP-initiated dialogues. The ACN rules are:
! When SSP receives a TC-BEGIN package to initiate dialogue, TCAP component
processing proceeds only if the ACN value is supported. Otherwise, the SSP aborts
the dialogue.
Note: T-INAP requires the CS2000 SSP to support only SSP-initiated dialogues,
not dialogues initiated by TC-BEGIN from SCP. The SSP therefore responds to a
TC-BEGIN package from the SCP by aborting the dialogue.
! If TCAP component processing encounters an INAP operation that is not associated
with the AC, the SSP aborts the dialogue. Otherwise, processing continues.

E3.3 INAP Signalling Interworkings

Two types of interworking are involved in the handling of a CS-1R IN call, as discussed
in this section and illustrated in figure 103 on page 428.
E3.3.1 Incoming Call Interworking (INAP Triggering)

When triggering occurs for a call, interworking takes place at the CS2000 SSP between
the incoming trunk interface and INAP. INAP operations are then exchanged between the
CS2000 SSP and the SCP. This process is illustrated in figure 106 for an IN call incoming
over a TDM-side ETSI ISUP trunk (triggering is also supported for ISUP over SIP-T).
OSI Layers
CS2000 SSP SCP
CCF protocol stack SSF/SRF protocol stack SCF protocol stack
INAP INAP
Intelligent Network Intelligent Network
Layer 7 Application Part Application Part
Application
TCAP TCAP
ETSI ISUP Transaction Capabilities Transaction Capabilities
ISDN Application Part Application Part
Layer 6 User Part
Presentation
Layer 5
Session
Layer 4
Transport
SCCP SCCP
Layer 3 Signalling Connection Signalling Connection
Network Control Part Control Part
Layer 2 MTP
Datalink MTP Message Transfer
Message Transfer Part Part
Layer 1
Physical
Call from PSTN IN signalling link
Figure 106: IN-related signalling interactions

IN queries can be triggered via the O_BCSM for incoming calls over the following
interfaces:
! ETSI ISUP (V1 and V2), including most national ETSI ISUP variants
! IBN7 / ANSI ISUP+
! UK ISUP
! SPIROU (French ISUP)
! Australian ISUP variants (ACIF I-ISUP and Telstra CA30)
! BTUP
! SSUTR2 / FTUP
! ISDN PRI
! QSIG
! Analogue subscriber lines
Note: Triggering is supported for call attempts initiated by features such as RAG.
Triggering is also supported for features that allow a multi-leg call, e.g. CFwd and
3WC, provided that any existing IN dialogue is taken down first.
IN queries can also be triggered via the T_BCSM for calls terminating on analogue
subscriber lines.
E3.3.2 Outgoing Call Interworking (IN Onward Routing)

After IN interaction, an IN call can be interworked to any interface with which the
originating agent can interwork. This second interworking does not directly involve
INAP. Even if the SCP has requested monitoring of call completion by arming EDPs, the
corresponding call processing events are detected by the O_BCSM and reported to the
SCP via the interworking between the originating agent and INAP.
The combination of originating and terminating agents for an onward-routed IN call has
implications for the level of call monitoring that can be supported for that call. Some of
these implications are common to more than one interworking:
! Overlap outpulsing is not supported for the second leg of an IN call for which
monitoring has been requested.
! EDP-4 (Route_Select_Failure) can be detected within the CS2000 SSP before a
terminating agent is selected, and can in this case be detected and reported
regardless of what the terminating agent might have been.

E3.4 Overview of Feature Set Support

INAP is a general-purpose platform for the support of IN services, as described in Chapter
F12: IN Services.
Chapter F6 also provides information about interactions between IN and non-IN features
and services, i.e. which features can be activated for an IN call.
E3.5 Order Codes for INAP

Table 38: Order codes for INAP software
DSSP0001 Basic CS-1R SSP
ISSP0002 IN Trigger Processing
ISSP0005 Originating Basic Call State Machine EDPs
INAP0002 INAP Interworking with Lines
INAP0003 INAP Interworking with IBN7 ISUP
INAP0004 INAP Interworking with ETSI ISUP
INAP0005 INAP Interworking with PRI
DSSP0007 Trunk Trigger Subscription
DSSP0008 CS-1R Service Filtering
DSSP0010 AMA FCI
DSSP0013 Call Information Request and Report
DSSP0014 CS-1R TDP2
DSSP0015 Call Party Handling
DSSP0017 CS-1R Call Gapping
DSSP0018 Point of Re-entry Control
DSSP0019 CS-1R Correlation ID
DSSP0021 SSP - Strip Leading Digits
DSSP0022 SSP - OCI Retention and Capture in AMA for Follow-on Calls
DSSP0028 Apply Charging

Chapter E4 PRI Access Interface

E4.1.1 PRI Support for PBX Access
The ISDN Primary Rate Interface supports 30B+D network access (30 64Kb/s B-channels
for voice/data and a 64Kb/s D-channel for signalling) via E1 carriers at the T reference
point. (There are also 23B+D PRI variants, supported via T1 carriers.) PRI was originally
designed for point-to-point communication between digital PBXs and local exchanges.
For PRI access to a packet network, the point-to-point interface is provided between the
PBX and a gateway controlled by a CS2000 GWC. A media gateway used to support PRI
access in this way must also support signalling gateway functionality, as follows:
! Media gateway functionality for PRI means mapping ISDN B-channels on to packet
network media streams. CS2000 controls this functionality by means of H.248
(recommended) or ASPEN, as used to control bearer channel mapping for CCS7.
! Signalling gateway functionality for PRI means terminating ISDN D-channels and
backhauling PRI Layer 3 signalling across the packet network so that call
processing can take place at the CS2000. The packet network protocol stack used
for this purpose is Q.931 / IUA / SCTP.
For convenience, this chapter simply uses the term gateway rather than media/signalling
gateway. Figure 107 illustrates the configuration used by CS2000 to support PRI access.
PBX implements user side IP or ATM

of access interface; CS2000 backbone network CS2000
implements network side
Combined SIP-T
Q.931 / IUA / SCTP
NT2 PRI trunk media and (call control) GWC CCS7
S Digital PBX
T access signalling
gateway
(CTR4) (30B+D (PVG or H.248 or ASPEN
Terminals or 23B+D) Mediant over UDP
2000) (media control)
Packet network media streams
Figure 107: ETSI ISDN PRI access to a CS2000 network

Communication Server Capabilities Telephony Interfaces PRI Access Interface
With effect from ISN07, CS2000 offers a choice of gateway types for supporting PRI
access to the packet network:
! Packet Voice Gateway (PVG) described in section B2.3 on page 99
! Audiocodes Mediant 2000 gateway described in section B2.6 on page 116
Functionally, both types of gateway support ISDN PRI in the same way, as illustrated in
Figure 107 on page 445. The differences between them are to do with capacity and
deployment options rather than functionality, as follows:
! The PVG is a high-capacity gateway that is typically owned and operated by the
operating company and located on telco premises.
! The Mediant 2000 is a compact gateway that is typically owned and operated by an
enterprise and located on customer premises. It is designed to provide cost-effective
support for remote deployment of a relatively small number of PRI-enabled PBXs
PRI is an asymmetrical interface, i.e. the protocol and procedures defined for the local
exchange (CS2000 gateway) end of the interface are not identical to those defined for the
PBX end of the interface. Typically, a Communication Server such as CS2000 supports
PRI in network or master mode, while the PBX supports it in user or slave mode.
The ETSI PRI specifications listed in section E4.1.3 always use the terms sending and
receiving from the viewpoint of the PBX. Overlap sending, for example, means overlap
signalling from the PBX to the gateway; overlap receiving means overlap signalling from
the gateway to the PBX. Nortel documentation, however, uses the terms inpulsing and
outpulsing from the perspective of the gateway. Overlap inpulsing is therefore equivalent
to ETSI overlap sending , and overlap outpulsing is equivalent to ETSI overlap receiving.
E4.1.2 Alternative Roles for PRI

The primary role of PRI is to support access to the backbone packet network for digital
PBXs, as described in section E4.1.1 on page 445, but CS2000 also supports the use of
PRI in a number of alternative network roles. The most important of these are:
! External IP support
CS2000 can use PRI to communicate with an IN external IP (Intelligent Peripheral)
providing Specialised Resource Function (SRF) capabilities for interaction with end
users, either to provide or to obtain information, as described in Chapter E3: INAP.
! Multimedia support
PRI connections between a PVG and an MCS5200 SIP / PRI gateway (sometimes
referred to as a SimRing PRI blender) can be used to provide multimedia support
for blended users, as described in Chapter F15: Multimedia Services for Blended
Users.

PRI Access Interface Telephony Interfaces Communication Server Capabilities
E4.1.3 Specifications
E4.1.3.1 ETSI Specifications

ETSI ISDN PRI is defined in the following specifications:
! ETS 300 403, which defines the layer 3 protocol for basic call control. It is a delta
document to ITU-T Recommendation Q.931 (White Book).
Note: Support for ETS 300 403 implies support for its predecessor ETS 300 102,
which is based on the Blue Book version of Q.931.
! ETS 300 402, which defines the layer 2 data link protocol. It is a delta document to
ITU-T Recommendations Q.920 and Q.921 (White Book).
Note: Support for ETS 300 402 implies support for its predecessor ETS 300 125,
which is based on the Blue Book version of Q.920/Q.921.
! ETS 300 011, which defines the physical layer (layer 1).
E4.1.3.2 National Variants of ETSI PRI

Although ETSI ISDN PRI can be used unmodified in a national network, some national
regulators have defined their own national variants. Such a variant is typically
characterised by differences in messages, information elements or call processing
procedures.
The following national ETSI PRI variants have been defined for countries in which
CS2000 deployment is currently planned:
! Spanish PRI, which is defined in
Spain PRI Specification: ISDN User-Network Interface Layer 3
(a subset of ETS 300 102)
! Chinese PRI, which is defined in
China MPT standard YDN034: ISDN User-Network Interface (1997) is defined in
relation to Q.931, but the CS2000 implementation is based on ETSI PRI.

E4.1.3.3 Other National PRI Variants
Hong Kong PRI (CR13)

Hong Kong PRI (CR13) is a 23B+D interface supported over 1.5Mb/s T1 carriers.
Hong Kong PRI supports overlap sending (inpulsing), but not overlap receiving
(outpulsing).
Maximum size of called party number is 19 digits. This is as specified in HKTA 2015,
another Hong Kong PRI specification that is an almost exact copy of CR13.
Japan PRI (INS1500)

Japan PRI (INS1500) is a 23B+D interface supported over 1.5Mb/s T1 carriers.
The Japan PRI protocol supports only en-bloc sending and receiving of called party digits.
It does not support overlap sending or receiving.
The CS2000 implementation of INS1500 has been enhanced to ensure that neither receipt
of non-supported IEs or nor requests for non-supported services causes calls to be taken
down or affects CLIP/CLIR functionality (see A59013405).
ANSI PRI
ANSI PRI is a 23B+D interface supported over 1.5Mb/s T1 carriers. It is defined in ANSI
specification T1.607 (1990).
The ANSI PRI protocol supports only en-bloc sending and receiving of called party digits.
It does not support overlap sending or receiving.

E4.1.4 ISDN Service Categories

ISDN service categories and priorities are defined in the CEPT MoU (Memorandum of
Understanding), which is a requirement for all CEPT member PTTs offering ISDN.
The CEPT MoU lists the telecommunication services that are to be implemented by
member PTTs within a certain timeframe. Services are denoted as Priority 1, 2 or 3,
depending on the urgency with which they must be introduced. Priority 1 services are to
be introduced first and priority 3 last.
The ETSI ISDN telecommunication services (i.e. those listed in the MoU) are divided into
three categories: bearer services, teleservices and supplementary services. These
categories are distinguishable by the service attributes that may be applied to them.
Service attributes, as defined in CCITT Blue Book Recommendation I.210, may be high
or low layer. Low layer attributes are those used to describe the type of information being
carried (prior to conversion to 64 Kb/s data). High layer attributes describe the functional
characteristics of a service.
The attributes applicable to each service category are as follows:
! Bearer services
Low layer attributes only
! Teleservices
Both low and high layer attributes
! Supplementary Services
High layer attributes only
Figure 108 illustrates these service categories in relation to the end-to-end handling of an
ISDN call routed across the packet network.
IP or ATM backbone network

GWC CS2000
GWC CS2000
User User
phones phones
and and
terminals terminals
PRI(T) ASPEN SIP-T ASPEN PRI(T)
access CCS7 access
Gateway
Gateway
PTNX trunks Q.931 trunks PTNX

(digital Q.931 (digital
PBX) U N N U PBX)
A bearer service or bearer capability provides a particular type of link between two points, e.g.
speech or unrestricted data; bearer capabilities must be compatible between end points
A teleservice provides a particular type of end-to-end communication, e.g. telephony or fax
A supplementary service enhances a teleservice,

e.g. by providing extra information or event notification.
Figure 108: Bearer services, teleservices and supplementary services


The CS2000 implementation of the ETSI PRI protocol is formally defined in
NIS A261-1: ETSI PRI(T) Specification
ETSI ISDN Primary Rate Interface at the T Reference Point.
ISN06 and ISN06 (TDM) Implementations
E4.2.1 PRI Access to the Packet Network

CS2000 release ISN07 supports two basic types of trunk interface: CCS7 and PRI/QSIG.
For CCS7 calls, user part call control signalling (IAM etc) terminates on a dedicated
signalling peripheral in the CS2000; it is not terminated on the media gateway that
handles the corresponding bearer channel. For ISDN PRI calls, however, the D-channel
and the associated B-channel both terminate on the same gateway, which must therefore
support signalling gateway functionality as well as media gateway functionality.
Signalling gateway functionality for PRI means terminating ISDN D-channels and
backhauling PRI Layer 3 signalling (SETUP etc) across the packet network. This enables
CS2000 to perform PRI call processing, and to initiate media control signalling sessions
to control the packet network bearer connections for PRI calls.
The mechanism used is to encapsulate the PRI Layer 3 signalling in IP packets so that it
can be conveyed from the gateway to a CS2000 GWC. The protocol stack used for this
purpose is Q.931 / IUA / SCTP / IP, as described in Chapter D10: IUA and summarised
below.
Q.931 / IUA / SCTP / IP protocol stack characteristics:
! Used for Layer 3 signalling between a GWC and a PP7480 or PP15000 PVG
supporting PBX access over ETSI PRI trunks. CS2000 GWCs and gateways are
compliant with IUA as defined in IETF draft version 1 of RFC3057.
! PRI signalling encapsulation
PRI Layer 3 messages (Q.931) such as SETUP are conveyed in IUA messages in
the same way that they are normally conveyed in Q.921 Layer 2 messages.
! IUA characteristics:
" Capabilities similar to those of Q.921 Layer 2 (datalink)
" Messages used in Q.921 link establishment and release:
Establish (corresponding to Q.921 DL-ESTABLISH)
Release (corresponding to Q.921 DL-RELEASE)
" Message used for Q.931 message transport:
Data (corresponding to Q.921 DL-DATA)
! SCTP characteristics:
SCTP (Stream Control Transmission Protocol) provides reliable ordered transport
for Q.931 messaging, which means that no application-level reliability mechanisms
are required or supported. SCTP is defined in RFC2960. The gateway and GWC are
compliant with draft version 5. Briefly, an SCTP packet comprises:
- Source port number.
- Destination port number.
- User data, i.e. PRI / IUA message in chunks
- A 32-bit checksum

E4.2.2 Call Flow for Networked PRI Call

This section provides an overview of the process of setting up a PRI call between two
CS2000s across a backbone packet network. It therefore deals with:
! The handling of incoming PRI calls at an originating CS2000
! Communication between two CS2000s to support the networking of PRI calls
! The handling of outgoing PRI calls at a terminating CS2000
shown in Figure 109, and are described in order on the following page.
ISDN signalling
Packet network control signalling (2 types)

Even if an ATM backbone
network is in use, signalling
to/from/between GWCs is TDM bearer channels
conveyed over IP
( IP / AAL5 / ATM over STM-1) Packet network bearer connections

3 4 15
5a 5b 11 12 13 14 16a 16b
Access 8 DPT GWCs DPT GWCs Access
Gateway Gateway
Controller 27 and Session and Session
22 Controller
Ingress 34 Egress Ingress 32 Egress
TDM-side 35 packet-side packet-side TDM-side
36 6 9 10 38b 18 31
37 28 26 Inter-CS signalling 23 20
29 38a (CCS7 signalling 24 21
Two types of encapsulated in SIP-T) 25 Two types of
signalling: signalling:
Media control Media control
via H.248 via H.248
Call control via Call control via
PRI/IUA/SCTP PRI/IUA/SCTP
Packet network
2 7 (ATM or IP) 19
Gateway Gateway
Bearer connection
(packetised voice)
PRI access PRI access

(30B+D or (30B+D or
23B+D) 23B+D)
Call origination 1 Call termination
PSTN or private network
Figure 109: Setting up a networked PRI call between two CS2000s

Note: The messaging description below reflects two assumptions about protocol usage:
! It is assumed that the protocol used for device/media control signalling betwen
GWCs and PVGs is H.248. ASPEN continues to be supported as an alternative to
H.248 for trunk gateway control, but use of H.248 is recommended.
! It is assumed that the Session Server rather than a GWC configured as a VRDN is
used to terminate inter-CS packet network connections in the inter-CS part of the
call flow illustrated in Figure 109 on page 451. This implies that the Session Server
provides all SIP functionality, and that TCP rather than UDP is used as the inter-CS
transport protocol. See section D2.2: CS2000 Support for Dynamic Packet
Trunks on page 244 for further information.
1 Q.931 SETUP message for incoming call arrives at originating gateway
2 SETUP for incoming call encapsulated using IUA / SCTP and conveyed to GWC
3 Ingress GWC processes SETUP and sends it on to the CS2000 Core.
CS2000 Core call processing uses SETUP to:
- Perform translations and routing, resulting in the selection of an outgoing trunk
group to another CS2000
- Select a DPT (Dynamic Packet Trunk) from the pool supported by DPT GWCs
4 - Allocate the selected DPT for the duration of the call
The DPT GWC selects a trunk profile on the basis of the CCS7 protocol to be used and
the destination hostname, and passes the telephony profile index to the Core.
See Figure 13 on page 62 for an illustration of how DPT GWCs interact with the
Session Server to support DPTs for inter-CS communication.
5a CS2000 Core sends FCM (Fabric Control Message) to ingress and egress GWCs to
5b enable direct communication between them
Ingress access GWC sends H.248 Add commands to originating media gateway to
6 command identifies TDM-side trunk and requests gateway to add it to a newly created
context. Second Add command asks gateway to reserve logical packet-side
termination in receive-only mode and add it to the same context.
7
bearer capabilities supported (for use in codec negotiation with the gateway serving
the remote endpoint).
8
Ingress access GWC passes gateway IP address and SDP session description to
egress DPT GWC
Egress DPT GWC assembles outgoing IAM and forwards IAM to egress Session
Server. Egress Session Server encapsulates IAM in SIP-T INVITE message, together
9 with SDP session description including IP address of originating media gateway
endpoint; egress Session Server then sends INVITE message to Session Server on
terminating CS2000
10
Ingress Session Server on terminating CS2000 immediately acknowledges INVITE
message by sending back a SIP-T 100 TRYING message with no payload
Ingress Session Server selects an ingress DPT GWC that has an available DPT and
11
provides it with trunk profile information derived from the INVITE message.
See Figure 13 on page 63 for an illustration of how the Session Server and DPT GWCs
interact to support DPTs for inter-CS communication.
12
Ingress DPT GWC allocates selected DPT for the duration of the call and defines its
protocol characteristics in accordance with trunk profile from INVITE message.
13
Ingress Session Server forwards IAM extracted from INVITE message to selected DPT
on ingress DPT GWC
14
Ingress DPT GWC forwards IAM to CS2000 Core, requesting it to initiate call
processing
15
CS2000 Core uses IAM to perform translations and routing, and identifies the egress
access GWC and gateway serving the destination
16a CS2000 Core sends FCM to ingress and egress GWCs to enable direct
16b communication between them

17
Ingress DPT GWC passes originating gateway IP address and SDP session
description to egress access GWC
Egress access GWC sends H.248 Add commands to terminating media gateway to
18 command identifies TDM-side trunk identified via translations and routing, and
requests gateway to add it to a newly created context. Second Add command asks
gateway to reserve logical packet-side termination and add it to the same context.
19
bearer capabilities supported (for use in codec negotiation with the originating media
gateway serving the originating endpoint).
20
Outgoing SETUP created, encapsulated using IUA / SCTP, and sent out by terminating
GWC
21 Backward ALERTING (encapsulated using IUA) received by terminating egress GWC
CS2000 Core receives the ALERTING as a progress message and passes an ACM to
22
ingress DPT GWC on terminating CS2000 (directly or via the Core, depending on
CCS7 protocol types involved); ingress DPT GWC forwards ACM to ingress Session
Server
23
Ingress Session Server encapsulates outgoing ACM in a backward SIP-T 183
SESSION PROGRESS message, then sends message to originating CS2000
24
Ingress DPT GWC sends ingress Session Server a request for ringback tone to be
applied to originating TDM-side trunk.
25
Ingress Session Server conveys ringback tone request to originating CS2000 by
means of a backward SIP-T 180 RINGING message
Egress Session Server on originating CS2000 terminates SESSION PROGRESS and
26 RINGING messages, extracting backward ACM from SESSION PROGRESS
message and forwarding it to egress DPT GWC
27
Egress DPT GWC on originating CS2000 passes a message to the Core, which in turn
passes an ALERTING message to the ingress access GWC
28
Ingress GWC encapsulates ALERTING message using IUA/SCTP and sends it to
originating gateway
29
asking gateway to apply ringback tone to originating TDM-side trunk
30 Backward CONNECT (encapsulated using IUA) received by terminating egress GWC
31
Egress access GWC sends H.248 Modify message to terminating media gateway,
asking gateway to place the bearer connection in full duplex mode
CS2000 Core receives the CONNECT as a progress message and passes an ANM tto
ingress DPT GWC on terminating CS2000 (directly or via the Core, depending on
32 CCS7 protocol types involved); ingress DPT GWC forwards ANM to ingress Session
Server, together with SDP description of bearer capabilities supported by terminating
media gateway endpoint
33
Ingress Session Server encapsulates outgoing ANM and associated SDP in a
backward SIP-T 200 OK message, then sends message to originating CS2000
34
Egress Session Server on originating CS2000 extracts ANM from SIP-T message and
forwards it to egress DPT GWC
35
Egress DPT GWC on originating CS2000 passes ANM to the Core, which in turn
passes a CONNECT message to the ingress access GWC
36 completing codec negotiation process and asking gateway to remove ringback tone
and place the bearer connection in full duplex mode
Ingress GWC sends PRI CONNECT message (encapsulated using IUA / SCTP) to
37 originating gateway, thus completing call setup for the packet network bearer
connection between the two access gateways
Forward SIP-T ACK message originated by egress Session Server on originating
38a
38b CS2000 to confirm receipt of final response to the original INVITE message, then sent
to ingress Session Server on terminating CS2000 to complete three-way handshake

E4.2.3 Datafill
Signalling links for ISDN PRI are provisioned using table TRKSGRP, as used to define
the signalling characteristics of a given trunk group. A PRI trunk group has no subgroups
as such, but table TRKSGRP defines the signalling characteristics of the D-channel that
conveys the ISDN signalling for the B-channels in the group:
! Signalling type ISDN
! Protocol version 87Q931
! Configuration PT_PT
In conceptual terms, there is a logical terminal (LT) at either end of an ISDN PRI trunk
LTDEF and LTMAP, as described in section C2.3.2 on page 186 and illustrated in Figure
53 on page 188.
The version of PRI to be used is identified by means of a unique Protocol Version Control
(PVC) value generated from the values of the VARIANT and ISSUE fields in the table
LTDEF entry.
A variant is a separate call processing agent. CS2000 currently supports the following
variants of PRI:
! Base / generic ETSI PRI
! Hong Kong PRI (CR13)
! Japanese PRI (INS1500)
! ANSI PRI
! QSIG (described in Chapter E5: QSIG VPN Interface)
An issue is a refinement of a variant that implements minor variations in protocol and/or
procedures. In ISN07, CS2000 supports two national-specific issues of the base ETSI PRI
variant: Spanish PRI and Chinese PRI. The QSIG variant has two issues: ISO1996 and
ETSI1993. The other supported PRI variants have only one issue each.
Note: This PRI usage of the term variant reflects the names of the fields in table LTDEF,
but differs from how the term is used for other interfaces such as CCS7. Spanish ISUP,
for example, is defined as a variant of the ETSI ISUP agent, while Spanish PRI is defined
as an issue of the ETSI PRI variant of PRI.
LTDEF datafill options can be summarised as follows:
Protocol version VARIANT field ISSUE field

Base ETSI PRI ETSIPRI 1990
Spanish PRI ETSIPRI SPAIN1
Chinese PRI ETSIPRI CHINA1
Hong Kong PRI (CR13) HKPRI V1
Japanese PRI (INS1500 Version 5) INSPRI V2
ANSI PRI ANSI V1
QSIG (ISO / 1996) QSIGPRI ISO1996
QSIG (ETSI / 1993) QSIGPRI ETSI1993

E4.3 Capabilities Supported

E4.3.1 Message Support
Supported in
ETS
Message
Message name 300 403 ETSI variant issues Hong Japan
category USA
section Kong (INS (ANSI)
Base Spain China (CR13) 1500)
ALERTING 3.1.1 Y Y Y Y Y Y
CALL PROCEEDING 3.1.2 Y Y Y Y Y Y
CONNECT 3.1.3 Y Y Y Y Y Y
Call
establishment CONNECT ACK 3.1.4 Y Y Y Y Y Y
messages
PROGRESS 3.1.8 Y Y Y Y Y [1] Y
SETUP 3.1.14 Y Y Y Y Y Y
[2] [2] [3]
SETUP ACK 3.1.15 Y Y Y Y N N [3]
RESUME [4] 3.1.11 N N N N N N
RESUME ACK [4] 3.1.12 N N N N N N
Call
information RESUME REJECT [4] 3.1.13 N N N N N N
phase
SUSPEND [4] 3.1.18 N N N N N N
messages
SUSPEND ACK [4] 3.1.19 N N N N N N
SUSPEND REJECT [4] 3.1.20 N N N N N N
DISCONNECT 3.1.5 Y Y Y Y Y Y
Call clearing
messages
RELEASE 3.1.9 Y Y Y Y Y Y
RELEASE COMPLETE 3.1.10 Y Y Y Y Y Y
[2] [2] [3]
INFORMATION 3.1.8 Y Y Y Y N N [3]
NOTIFY 3.1.9 Y Y Y Y Y [5] Y
Miscellaneous SEGMENT 3.5.1 N [6] N [6] N [6] N [6] N [6] N [6]
messages STATUS 3.1.16 Y Y Y Y Y Y
STATUS ENQUIRY 3.1.17 Y Y Y Y Y Y
FACILITY N/A Y [7] Y [7] N N Y [7] N
RESTART 3.4.1 Y Y Y Y Y Y
Global call RESTART ACK 3.4.2 Y Y Y Y Y Y
reference
messages STATUS 3.4.3 Y Y Y Y Y Y
[6] [6] [6] [6] [6]
SEGMENT 3.5.1 N N N N N N [6]
[1] Supported only in the network-to-user direction.
[2] Spanish PRI and Hong Kong PRI support only overlap sending (PBX to gateway, not overlap
receiving (gateway to PBX). Trunk group datafill must be used to disable overlap outpulsing from
CS2000.
[3] Used only for overlap signalling, and therefore not supported (all INS1500 and ANSI PRI
signalling is en-bloc).
[4] Not applicable for PRI, only for BRI.
[5] Supported only in the user-to-network direction.
[6] Message segmentation is not required, as no supported message is long enough to need it.
[7] Used to provide generic support for supplementary services, e.g. AOC-D.

E4.3.2 Information Element Support

Supported in
ETS Max.
IE name 300 403 length ETSI variant issues Hong Japan
USA
section (octets) Kong (INS
Base Spain China (CR13) (ANSI)
1500)
Bearer Capability 4.5.5 12 Y Y Y [1] Y Y [2] Y
[3]
Call Identity 4.5.6 10 N N N N N N
Call State 4.5.7 3 Y Y Y Y Y [4] Y [4]
[1]
Called Party Number 4.5.8 23 Y Y Y Y Y Y
Called Party Subaddress 4.5.9 23 Y Y Y Y Y N
Calling Party Number 4.5.10 24 Y Y Y [1] Y Y Y
Calling Party Subaddress 4.5.11 23 Y Y Y Y Y N
Cause [5] 4.5.12 32 Y Y Y [1] Y Y [6] Y
[7] [1]
Channel Identification 4.5.13 34 Y Y Y Y Y [8] [9] Y
Date/time 4.5.15 8 N N N N N N
Display 4.5.16 82 N N N Y N N
Facility N/A Y [10] Y [10] N N Y [10] N
High Layer Compatibility 4.5.17 5 Y Y Y Y Y Y
Keypad Facility 4.5.18 34 Y Y N N Y N
Low Layer Compatibility 4.5.19 18 Y Y Y Y Y Y
Network Specific Facilities 4.5.21 N N N N N N
Notification Indicator 4.5.22 3 Y Y Y Y Y N
Progress Indicator [11] 4.5.23 4 Y Y Y [1] Y Y Y
Restart Indicator 4.5.25 3 Y Y Y Y Y Y
Segmented Message 4.5.26 N [12] N [12] N [12] N [12] N [12] N [12]
Sending Complete 4.5.27 1 Y Y Y Y N N
Transit Network Selection 4.5.29 N N N N N N
User-to-User Information N/A 128 [13] Y [14] Y [14] Y [14] N Y [14] N
[1] Partial compliance with requirements as specified in YDN034. See A59039647.
[2] Japan PRI supports a User Information Layer 1 Protocol Identifier of Recommendation G.711
-Law whereas ETSI PRI supports Recommendation G.711 A-Law. Japan PRI also supports User
Information Layer 2 Protocol and User Information Layer 3 Protocol information elements where
ETSI PRI does not.
[3] Not applicable for PRI (used only for suspend / resume).
[4] Call State values Overlap Sending and Overlap Receiving are not supported.
[5] Customers can use datafill to define a customised set of cause-to-treatment mappings (choice of
tone/announcement) for treatments provided over PRI. Cause value is provided in PROGRESS
messages transmited on call failure.
[6] Japan PRI supports the Diagnostics field while ETSI PRI does not.
[7] CS2000 sends a RESTART ACK indicating which channels have been returned to idle if a
multi-channel RESTART is received but not all channels can be returned to idle. This functionality
is as specified in ETS 300 403 5.5.2.
[8] Japan PRI supports use of the Interface Identifier IE for explicit interface identification. It also
supports slot map channel identification while ETSI PRI does not.
[9] Supported in both directions in ALERTING and CONNECT messages for symmetrical call control.
[10]Used to provide generic support for supplementary services.
[11]Two PIs in a message supported.
[12]Message segmentation is not required, as no supported message is long enough to need it.
[13]This is the maximum amount of user data; the maximum size of the IE is 131 octets.
[14]Used to support the UUS supplementary service (UUS1 implicit or explicit).

E4.3.3 Service Support

The ETSI-defined ISDN services that have been implemented and are available over the
CS2000 ETSI PRI interface are shown in Table 39. For descriptions of the supplementary
services listed, see Chapter F4: ISDN Supplementary Services.
Note: Services that are not supported are not listed. This includes services that cannot be
assigned to PRI users (e.g. Call Hold, Call Waiting). Some services (Call Forward
variants CFU, CFB and CFNR) are listed because CS2000 supports the resulting call
reconfiguration, but service functionality is actually provided by the PBX and is not the
responsibility of CS2000.
Table 39: CS2000 Implementation of ETSI-defined Services
Service Type Service Name
Circuit mode speech bearer service
Bearer Services Circuit mode 3.1kHz audio bearer service [1]
Circuit mode 64Kb/s unrestricted digital information [2]
3.1 KHz telephony
Telefax Group 4 [3]
Teleservices
Teletex [3]
Videotex [3]
MoU1 Calling Line Identification Presentation (CLIP)
supplementary Calling Line Identification Restriction (CLIR)
services Direct Dialling In (DDI)
Advice Of Charge During Call (AOC-D)
Advice Of Charge at End of Call (AOC-E)
Closed User Group (CUG)
Connected Line Identification Presentation (COLP)
Connected Line Identification Restriction (COLR)
Malicious Call Identification (MCI)
MoU2 Subaddressing (SUB)
supplementary
services User-to-User Signalling (UUS)
Call Completion to Busy Subscriber (CCBS)
Call Forward Unconditional (CFU) [4]
Call Forward on Busy (CFB) [4]
Call Forward on No Reply (CFNR) [4]
Partial Rerouting (PRR) [5]
Explicit Call Transfer (ECT)
[1] This bearer capability can support facsimile group 2/3 calls.
[2] Referred to as CCD (Clear Channel Data) in a CS2000 context. See section C3.8 on page 229
for information about the implications of supporting CCD calls across a packet backbone.
[3] Since this teleservice needs the unrestricted digital information bearer service, it is subject to the
general considerations that apply to supporting CCD across a packet network.
[4] Service functionality provided is primarily by the PBX, not by CS2000. CS2000 supports the
service in the sense that it supports the resulting call reconfiguration, but it does not notify the
caller that forwarding has taken place.
[5] This is not an MoU2 supplementary service in its own right; it forms part of the Call Diversion
supplementary services defined in ETS 300 207.

CS2000 also supports a number of non-ETSI services over PRI, i.e. services supported
over ISDN interfaces but not defined by ETSI. These are of two types:
! Generic non-ETSI services that can be deployed in any national network:
" Random and circular hunting for PRI trunk groups
This makes it possible to ensure that calls to a given set of trunk groups (a
super-group) are evenly distributed between their B-channels. This is
particularly useful for CS2000s connected to Internet Service Providers (ISP),
where a large number of outgoing-only trunk groups are assigned to the same
dialled number and call hold times are long.
! National non-ETSI services that are specific to a particular national network. Three
of these have been defined for use in Germany:
" Priority Class Of Service (PCOS)
" Emergency Calls
" Network Advice Of Charge (NAOC)
E4.3.3.1 Circuit Switched Call Control Procedures

The CS2000 implementation of ETSI PRI supports the following circuit-switched call
control procedures:
! Call establishment at the originating interface, including
" En-bloc sending
" Overlap sending (i.e. overlap signalling in the PBX-to-switch direction)
Note: Not supported by Japan PRI or ANSI PRI.
" B-channel negotiation
Note: Transit network selection is not supported.
! Bearer capability billing for call originations via an AMA type 071 module
appended to the base AMA record.
! Network tones support
For an originating PBX or key system that cannot provide tones, CS2000 can
request the originating media gateway to provide the following backward tones:
" A backward dial tone on the selected B-channel when it receives a SETUP
message with no dialled digits. The tone is removed when the first
INFORMATION message with dialled digits is received.
" Ring tone back to the caller when ringing is being applied to the destination
terminal.
" Failure tones indicating why call establishment has not been successful.
CS2000 can also support tone provision from the originating media gateway for
calls terminating on a PRI PBX that cannot provide backward tones.
For a networked call, backward tones are applied in response to SIP-T Remote
Bearer Control (RBC) requests from the far-end CS2000.

! Call establishment at the destination interface, including

En-bloc receiving
Overlap receiving (overlap signalling in the switch-to-PBX direction)
Note: Not supported by Spanish PRI, Hong Kong PRI, Japan PRI or ANSI
PRI.
B-channel negotiation
Note: Random and circular hunting for PRI trunk groups makes it possible
to ensure that calls to a given set of trunk groups (a super-group) are evenly
distributed between their B-channels.
E4.3.3.2 Miscellaneous Capabilities

! Extension billing
BILL_FROM_CPN option in table LTDATA enables operators to have calls billed
to the Calling Party Number as received in the incoming SETUP message, rather
than to the CgPN after it has been screened and/or edited.
! Cause value enhancements
" Cause values passed transparently over PRI-to-PRI interworkings.
" Default set of cause value mappings for agents that interwork with PRI.
" Default set of cause-to-treatment mappings for PRI, plus flexibility in how
cause values are mapped to treatments provided over PRI.
" Cause value IE in PROGRESS messages transmitted on call failure.
! Two Progress Indicators
CS2000 supports two Progress Indicator (PI) IEs in a message, and maps these over
PRI/ISUP and ISUP/PRI interworkings as described in Q.699.
! Overlap outpulsing/inpulsing control via TRKSGRP datafill
The OVLOPOFF option switches off outpulsing, causing CS2000 to store up
incoming digits and send them to the called party in en-bloc mode.
The OVLIPOFF option switches off overlap inpulsing, causing CS2000 to respond
with a RELEASE COMPLETE instead of a SETUP ACK if it receives a SETUP
message that does not provide enough digits to route a call. The RLC indicates
incomplete address (cause #28).
! Echo control
For PRI, echo control is always used for non-data calls, on the assumption that the
gateway is close to the point of reflection and is therefore the best place to apply
echo cancellation. The use of ISUP signalling procedures ensures that the
possibility of introducing multiple echo cancellers is minimised.

E4.4 Limitations
! CS2000 does not support the following call control procedures:
" Signalling procedures for bearer capability selection
" Signalling procedures for high layer compatibility selection
" Circuit-mode multirate procedures (N x 64Kb/s)
" Transit network selection
" Network specific facility selection
" Message segmentation procedures
! A maximum of 29 digits can be outpulsed for a called party number. This exceeds
the 20-digit limit specified in ETS 300 403.
! Because CS2000 supports PRI as a trunk access agent, it has no mechanism either
to route calls to a specific timeslot or to associate a particular subscriber with a
specific timeslot.
! CS2000 does not support the "Case B" packet-switched data services described in
ETS 300 007.
! CS2000 does not support PRI user mode.
! CS2000 supports only service 1 of the UUS supplementary service, not services 2
and 3.

PRI supports all of the CEPT MoU Priority 1 supplementary services with the exception
of Multiple Subscriber Number and Terminal Portability, neither of which are applicable
to PRI. It also supports a number of Priority 2 supplementary services.
See section E4.3.3 for a list of supported services, and Chapter F4: ISDN Supplementary
Services for details.
E4.6 Order Codes for PRI
Table 40: Order codes for PRI software

PRIT0002 ETSI PRI / PRI Services
PRIT0011 INS1500 Japanese PRI
PRIT0004 PRI DN Billing

Chapter E5 QSIG VPN Interface

E5.1.1 QSIG Concepts and Terminology
QSIG is an ISDN network signalling system for peer-to-peer communication between
PBXs and/or switches. As an open interface, it can be used to link different node types in
a multi-vendor network. It can be used within a private network, or to support telephony
Virtual Private Network (VPN) capabilities within a public network. QSIG is also referred
to as Private Signalling System No.1 (PSS1).
QSIG specifications use the term PINX (Private Integrated Services Network Exchange)
instead of the term PBX or PTNX (Private Telecommunication Network Exchange). They
also use the term PISN (Private Integrated Services Network) instead of the term PTN
(Private Telecommunication Network). A CS2000 supporting QSIG is a virtual PINX.
The following different types of functionality may be used in handling calls between
PINXs across a QSIG network:
! An end PINX that handles a call origination from a directly connected line is
providing Originating PINX functionality.
! A gateway PINX that handles a call origination from an incoming trunk is providing
Incoming Gateway PINX functionality.
! An end PINX that handles a call termination to a directly connected line is providing
Terminating PINX functionality.
! A gateway PINX that handles a call termination to an outgoing trunk is providing
Outgoing Gateway PINX functionality.
! A PINX that relays a call between two other PINXs is providing Transit PINX
functionality.
QSIG is so called because it specifies protocol requirements at the Q reference point in
the ISDN model. The Q reference point exists within a QSIG PINX. It defines the
mapping between QSIG signalling (at and above Layer 3 in the OSI model) and the
chosen Layer 2.
QSIG does not specify which Layer 1 and Layer 2 implementations should be used to
convey QSIG signalling between PINXs. However, QSIG basic call procedures and the
messages used to support them are very similar to those of PRI (Q.931 / DSS1). For this

Communication Server Capabilities Telephony Interfaces QSIG VPN Interface
reason, Nortel and other equipment vendors use PRI Layer 2 (Q.921) and PRI Layer 1
(ETS 300 011) as the Signalling Carriage Mechanism (SCM) for QSIG signalling.
Chapter 110 illustrates the architecture of a QSIG network at a logical level and explains
the terminology used in describing QSIG capabilities.
End PINX providing End PINX providing

originating PINX functionality terminating PINX functionality
for directly connected lines Transit PINX for directly connected lines
or or
Gateway PINX providing Gateway PINX providing
incoming gateway PINX outgoing gateway PINX
functionality for incoming functionality for outgoing
trunks trunks
Switching and Switching and Switching and

service logic service logic service logic
Mapping and Mapping and Mapping and

physical physical physical
terminations terminations terminations
QSIG protocol stack

Directly Directly
Incoming connected connected Outgoing
trunk caller called party trunk
QSIG
QSIG Generic
Functional
Procedures for
service support
(IS 11582)
Q reference point
exists within PINX; QSIG Layer 3
it defines the call processing
mapping between (IS 11572)
QSIG signalling Based on
(Layer 3+) and the DSS1 Layer 3,
chosen Layer 2 i.e. Q.931 / PRI
Q
DSS1 Layer 2
(Q.921) C reference point
As for PRI exists between
PINXs; it defines
PRI Layer 1 the chosen Layer 1
(ETS 300 011)
2Mb/s 30B+D
C
Figure 110: QSIG logical network architecture and terminology

QSIG VPN Interface Telephony Interfaces Communication Server Capabilities
E5.1.2 QSIG in a Packet Network

QSIG is designed for peer-to-peer communication within a private network, i.e. dedicated
QSIG trunks between PINXs can be used to support value-added services for corporate
users.
QSIG can also be used to support VPN (Virtual Private Networking), in which shared
public network trunks are used to provide additional capacity on demand when the
dedicated private circuits of a corporate network are busy. The capability used to support
QSIG signalling over shared trunks is QSIG Feature Transparency (QFT). QFT uses the
ETSI ISUP V3 APM (Application Transport Mechanism) to encapsulate and convey any
service-related QSIG signalling that cannot be directly interworked to ISUP. This enables
services to be supported end-to-end even if the corresponding signalling has to be routed
via nodes that do not support QSIG functionality.
Note: Although the APM is an ETSI ISUP V3 mechanism, it is supported by the CS2000
implementation of ETSI ISUP V2, which is therefore referred to as ETSI ISUP V2+.
The APM can also be used to support QFT across a packet backbone network, in which
case two levels of encapsulation are involved. First, QSIG signalling is encapsulated in
ETSI ISUP, and then ETSI ISUP is encapsulated in SIP-T.
Note: For simplicity, this overview deals only with bearer QFT, not with non-bearer
QFT, which involves TCAP rather than ISUP. Both types of QFT are described in more
detail in section E5.1.5 on page 469.
Figure 111 shows how a private TDM network interfaces to a CS2000 packet network
configuration.
IP backbone network
QFT over SIP-T

GWC CS2000 CS2000 GWC
GWC-MG GWC-MG
control QSIG QSIG control
signalling backhaul backhaul signalling
(ASPEN) (ASPEN)
Bearer connection (packetised voice)

Gateway Gateway
QSIG QSIG
PINX PINX
Figure 111: QSIG over a packet network

Since the primary point of using a packet backbone network is to avoid the need for
dedicated physical connections, QSIG as such (i.e. the IS11582 / IS11572 / Q.921 /
30B+D protocol stack) is not supported across the packet network. Support for QSIG in
a packet network environment means support for the following:
! Support for QSIG access signalling.
! Support for QFT across the packet network.
! Support for interworking between QSIG access signalling and QFT (direct QSIG to
QSIG interworking occurs only between gateways controlled by the same CS2000).
Note: Interworking with QFT is also supported for PRI access interfaces and
analogue lines, but this is outside the scope of this QSIG chapter. See section F5.4
on page 579 for details, and especially Figure 138 on page 581, which illustrates the
access configurations involved and explains the type of QSIG virtual PINX
functionality that CS2000 is providing in each scenario.
! Support for the QFT information model, which allows information provided over
an access interface (or provisioned against it) to be mapped on to QFT signalling.
The information that can be conveyed via the ETSI ISUP APM depends on the
application context.
Each application context has an associated information model that determines the
data types or parameters that can be conveyed via that context. Open application
contexts are defined by standards bodies, while proprietary application contexts
allow equipment vendors and network operators to define information models to
support their own services.
The most important open application context is application context 1 (PSS1), which
is used for QFT. The QFT information model provides definitions for a range of
common data types that are widely used in supporting services. CS2000 uses QFT
data types to support generic VPN capabilities such as business groups and private
numbering plans, and also to support specific Centrex services for subscriber lines.

Figure 112 illustrates the different protocol stacks involved in supporting QSIG access to
the backbone network and QFT across the backbone network, with CS2000 providing
virtual transit PINX functionality.
CS2000
QSIG / IUA / SCTP QFT / APM / ISUPv2 / SIP-T

Combined (call control) GWC (basic call and service control)
PBX QSIG media and
signalling
gateway ASPEN over UDP
Note: Direct QSIG to (PVG) (media control)
QSIG interworking
occurs only between
gateways controlled Packet network media streams
by the same CS2000
Figure 112: QSIG access configurations and virtual PINX functionality provided by CS2000
Note: Although QSIG as such is not used across packet networks, CS2000 uses QSIG
internally, for signalling across the CS LAN between the Core and H.323 GWCs. The
H.323 GWC performs message mapping between H.225 call control messages and
equivalent QSIG messages. For H.323 tunnelling, this message mapping involves
converting H.225 IEs conveying encapsulated H.450 and H.245 signalling into QSIG
Facility IEs conveying the same encapsulated signalling unmodified. See Chapter D5:
H.323 for further information. Also see Chapter E6: DPNSS Interface, as this
H.323/QSIG mapping capability is used to support DPNSS signalling and DPNSS
Feature Transparency (DFT) for DPNSS PBXs connected to Westell gateways and
controlled via H.323.

E5.1.3 QSIG Components and their Interaction

This section provides a more detailed description of the QSIG protocol stack illustrated
in Figure 110 on page 462.
QSIG is so called because it defines the interface to be provided at the Q reference point,
which exists within a node. This interface comprises U (user) channels and a D-channel
for signalling. These are logical channels, independent of any physical implementation,
but QSIG allows them to be mapped on to appropriate physical adaptations, typically the
30B+D 64Kb/s channels provided by a 2Mb/s ISDN Primary Rate Interface. External
interface capabilities are provided at the C reference point.
QSIG incorporates not only basic call control procedures, but also generic functional
procedures for the control of supplementary services at the Q reference point. The Generic
Functional Transport (GFT) entity comprises a number of different functions:
! The Co-ordination Function operates at the Application Layer to co-ordinate the
operation of basic call control, service-specific supplementary service control
(SS-Control), and any of the following elements that are used to support a
supplementary service:
" The Remote Operations Service Element (ROSE), which is used to invoke
ROSE operations.
" The Association Control Service Element (ACSE), which is used to establish
explicit application associations.
" The Dialogue Service Element (DSE), which is used to create and control
dialogues between peer SS-Control entities for the exchange of ROSE and
ACSE Application Protocol Data Units (APDUs).
! GFT-Control provides the following network layer services for communication
between peer SS-Control entities in different nodes:
" Establishing call-independent signalling connections for transporting ROSE,
ACSE and DSE APDUs.
" Unconfirmed transport of ROSE, ACSE and DSE APDUs.
" Event notification.
! Protocol Control, which serves basic call control as well as GFT, is the network
layer mechanism whereby service-related information is mapped on to messages
and parameters sent over the external interface. Two information elements are
defined for this purpose:
" The Facility IE, which is used to convey APDUs, and comprises:
# Protocol Profile, indicating ROSE, ACSE or DSE. (CS2000 currently
supports only ROSE.)
# Network Facility Extension, indicating the node for which the Facility
IE is destined. Facility IE octets after the NFE can simply be relayed
unchanged by intermediate transit nodes.
# Network Protocol Profile, indicating the specific protocol used to
encode the service APDU.
# Interpretation APDU, indicating what should be done if the service
APDU is not recognised, e.g. reject or discard the APDU, or clear the
call.
# Service APDU, containing service-related information.
A Facility IE may be conveyed as an extra parameter in a call setup or clearing
message, or may be conveyed in a FACILITY message.

" The Notification IE, which is used to convey notifications.

A Notify IE may be conveyed as an extra parameter in a call setup or clearing
message, or may be conveyed in a NOTIFY message.
Figure 113 illustrates the relationships between the functional elements of QSIG, and the
way in which they interact to support peer-to-peer comunication at different levels.
Supplementary Supplementary
service control service control
(service-specific) (service-specific)
GFT GFT
Layer 7: Application
Co-ordination
Co-ordination
ROSE ROSE
function
function
Basic call ACSE ACSE Basic call

control control
DSE DSE
APDUs
GFT control GFT control
Layer 3: Network
Protocol control Protocol control

Messages and
parameters
Signalling Carriage Mechanism Signalling Carriage Mechanism
Data Link Layer (Layer 2) Data Link Layer (Layer 2)
Physical Layer (Layer 1) Physical Layer (Layer 1)
Physical connection: 2Mb/s PCM30 carrier
Figure 113: QSIG functional elements and peer-to-peer communication
QSIG supports the sending of APDUs by means of two types of signalling:

! Call-associated signalling, in which APDUs are sent in the context of a speech or
data call (or call attempt) set up over an associated bearer channel.
! Non-call-associated signalling (circuit-oriented), which has no associated bearer
channel. Instead, a call-independent signalling connection is established using a
subset of the standard call establishment messages. This connection or virtual call
is assigned a call reference number, which is quoted in each message conveying an
APDU for the connection.

E5.1.4 Call Setup and Clearing

Figure 114 illustrates the messaging involved in QSIG call setup and clearing. As
mentioned already, the QSIG message flows are essentially the same as for PRI call setup
and clearing (see section E4.2.2 on page 451 for an annotated call flow). The main point
to note is that many QSIG messages can convey Facility and/or Notification IEs with
service-related information.
QSIG QSIG QSIG

originating or transit terminating or
gateway node node gateway node
PINX SETUP * PINX SETUP * PINX
SETUP ACK SETUP ACK

(Overlap
INFORMATION signalling INFORMATION
(1 or more) only) (1 or more)
CALL PROCEEDING CALL PROCEEDING
ALERTING* ALERTING*
CONNECT * CONNECT *
CONNECT ACK CONNECT ACK
Call in progress
DISCONNECT * DISCONNECT *
RELEASE * RELEASE *
RELEASE COMPLETE * RELEASE COMPLETE *
* Message capable of conveying Facility and/or Notification IE

Figure 114: QSIG call setup and clearing
Table 41: Support for Facility and Notification IEs in QSIG messages
Support for
QSIG message
Facility IE Notification IE
SETUP Yes Yes
ALERTING Yes Yes
CONNECT Yes Yes
DISCONNECT Yes Yes
RELEASE Yes No
RELEASE COMPLETE Yes No
FACILITY Yes Yes
NOTIFY No Yes
PROGRESS Yes Yes

E5.1.5 QSIG Feature Transparency

A VPN (Virtual Private Network) is a private network in which some parts of the network
are non-dedicated and provided on demand by the PSTN. An interface such as QSIG
needs to convey additional service-related information in order to support VPN. Because
public network protocols do not directly support such information, some mechanism is
required to ensure that information is not lost when a VPN call is routed through the public
network.
QSIG services already use generic protocol elements for transporting service-related
information, so feature transparency for most QSIG services can be achieved by
transporting those elements over the public network. The mechanism used to support
VPN calls is to take service-specific APDUs conveyed in QSIG Facility IEs and
FACILITY messages, and to encapsulate them in messages that can be conveyed over the
public network. Two protocols are used:
! ETSI ISUP messages are used to encapsulate APDUs from call-associated QSIG
messages and thus support bearer QFT, as described in section E5.1.5.1.
! TCAP messages are used to encapsulate APDUs from non-call-associated
(circuit-oriented) QSIG messages and thus support non-bearer QFT, as described
in section E5.1.5.2.
E5.1.5.1 Bearer QFT

Figure 115 is a conceptual view of peer-to-peer communication at the application level
for bearer QFT.
Peer-to-peer communication
APM APM APM
ISUP ISUP ISUP
SIP-T SIP-T SIP-T
PINX ISUP V2 network PINX ISUP V2 network PINX
Figure 115: Peer-to-peer communication for bearer QFT
The ability to convey QSIG information between peer applications is provided by the
Application Transport Mechanism (APM), which adds the following extensions to ETSI
ISUP (these are ETSI ISUP V3 messages/parameters, but CS2000 supports them as
extensions to ETSI ISUP V2):
! An Application Transport Parameter (APP) that can be conveyed in the existing
ISUP call control messages IAM, ACM, ANM, CON and CPG.
A message may convey up to five APPs, but each must be for a different application
context; it is a protocol error if there are two APPs for any context.
! An Application Transport Message (APM) that can be sent independently to convey
an APP.

! A Pre-Release Information (PRI) message that can be sent prior to a REL message
to convey an APP.
The IAM sent to initiate a bearer QFT call conveys two number parameters:
! The CdPN conveys the public routing number of the destination node.
! The APP conveys the private destination number, as received in the incoming
SETUP message.
Up to 2K octets of information can be transported via a segmentation mechanism.
APM can support a number of different applications, each identified via a Context
Identifier. On receipt of an APP whose Context ID is not understood, the APM
mechanism relays the information if possible. This allows peer applications to
communicate even via intermediate nodes that do not provide application support.
Figure 116 illustrates the messaging involved in bearer QFT call setup and clearing. As
mentioned already, the QSIG message flows are essentially the same as for PRI call setup
and clearing (see section E4.2.2 on page 451 for an annotated call flow). The main point
to note is that many QSIG messages can convey Facility and/or Notification IEs with
service-related information, and that QFT can convey this across the network.
QSIG
packet network, QSIG INFORMATION messages

For a basic non-QFT ISUP call over the backbone
QSIG
originating or
QSIG call setup transit node, QFT call setup
are interworked to ISUP SAMs, not APMs

gateway node, e.g. CS2000
e.g. PBX
PINX * PINX
SETUP IAM *
SETUP ACK APM *
(Overlap
INFORMATION signalling
(1 or more) only) APM * (1 or more)
CALL PROCEEDING ACM *

ALERTING * CPG *
CONNECT * ANM *
CONNECT ACK
Call in progress
DISCONNECT * REL
RELEASE * RLC
RELEASE COMPLETE *
* QSIG message capable of conveying * ISUP V2+ message capable of

Faclity and/or Notification IE conveying APP for QFT
Figure 116: Bearer QFT call setup and clearing

E5.1.5.2 Non-Bearer QFT

Figure 117 is a conceptual view of peer-to-peer communication at the application level
for non-bearer QFT.
Peer-to-peer communication
TCAP TCAP
SCCP SCCP SCCP
MTP3 MTP3 MTP3
M2PA M2PA M2PA
PINX SCCP network PINX SCCP network PINX
Figure 117: Peer-to-peer communication for non-bearer QFT
For non-bearer QFT, information flows are defined using a set of generic PSS1 primitives,
which map on to QSIG messages on the one hand and to TCAP components and
operations on the other. They are:
PSS1 Primitive TCAP equivalent QSIG message
PSS1_SETUP (request) BEGIN [SETUP.Invoke] SETUP
PSS1_SETUP (response) CONTINUE [SETUP.ReturnResult] CALL PROCEEDING
PSS1_SETUP
CONTINUE [CONNECT.Invoke] CONNECT
(confirmation)
No QSIG equivalent
PSS1_REJECT CONTINUE [SETUP.ReturnResult]
(call setup fails)
PSS1_FACILITY CONTINUE [FACILITY.Invoke] FACILITY
PSS1_RELEASE END [RELEASE.Invoke] RELEASE

E5.1.5.3 QFT Signalling Associations

When information is exchanged between applications, an association is said to exist
between them. The association is set up by the first exchange of QFT information and
remains in place for the remainder of the call. The target node is identified by the Called
Party Number in the IAM or SETUP message.
Once an association is set up, information is exchanged directly between the two end
nodes. Any intermediate nodes simply relay it.
The node that first sends QFT information is known as the Public Initiating Node (PIN)
and the destination node for the information is known as the Public Addressed Node
(PAN).
In an overlap signalling scenario, the setting up of the signalling association is completed
by the backward SETUP ACK message sent to request more digits. In this case, the first
QFT message sent by the PIN is an IAM conveying two numbers:
! The CdPN conveys the public routing number of the PAN.
! The APP conveys the first digits of the private destination number, as received in
the incoming SETUP message.
No further digits are sent until the PIN receives a SETUP ACK message conveyed in an
APP in an APM. Digits received in INFO messages in the meantime are stored at the PIN
awaiting the SETUP ACK, then sent together in an APM (they cannot be sent in ISUP
SAMs because an intermediate node might then add them to the public routing number).
For digits received subsequently, each INFO message is mapped immediately on to an
onward APM.
At the PAN, the CdPN is discarded, and the private digits in the APP are used as the CdPN
in an onward SETUP message. Further digits received in APMs, which will not be
received until after the backward SETUP ACK has been sent, are mapped immediately on
to onward INFO messages.
PIN/PAN relationships on different legs of a call may be chained as shown in figure 118.
This scenario can occur when PINX A can determine only that the call should be routed
to PINX B, although this is not its final destination. At PINX B, the application has access
to further information that allows it to determine the next node to which the call should
be routed (PINX C).
Application Application Application
PIN PAN PIN PIN
ISUP V2 network ISUP V2 network

PINX A or PINX B or PINX C
SCCP network SCCP network
Figure 118: Chaining PIN/PAN relationships

E5.1.5.4 Business Group Identifier (BGID)

In order to support VPN information flow across a public network, a business group
identifier (BGID) is used as a unique identifier for each private network known to the
public network. The BGID is defined as a series of up to 12 bytes, the first of which
provide the E.164 country code digits of the country where the business group was
initially assigned. This means that every BGID is globally unique, and that each private
network is assigned only one BGID, even though it may have public network PoPs (Points
of Presence) in many different countries.
QSIG is defined in the following specifications.
! Basic call control procedures are defined in ISO standard IS 11572.
! ETSI modifications to ISO/IEC 11572 (1994) are specified in ETS 300 172:
Private Integrated Services Network (PISN)
Inter-exchange signalling protocol
Circuit-mode basic services
! Generic functional procedures for the control of supplementary services are defined
in ISO standard IS 11582.
! ETSI modifications to ISO 11582 are specified in ETS 300 239.
! The Remote Operations Service Element (ROSE) is defined in CCITT
Recommendation X.219.
! The Association Control Service Element (ACSE) is defined in CCITT
Recommendation X.217.
! Data link layer requirements for ISDN PRI are defined in ITU-T Recommendations
Q.920 and Q.921, as modified by ETS 300 402.
! Physical layer requirements for ISDN PRI are defined in ETS 300 011, which is
based on ITU-T Recommendations I.431 and G.703-G.706.
! Logical/physical mapping is specified in ECMA 226 and IS 14474.
! ISUP and TCAP support for QFT is defined in Q.765.1 (also known as Q.vpn).
! The Application Transport Mechanism (APM) extensions to ISUP are defined in
Q.765 (also known as Q.apm).


The CS2000 implementation of the QSIG protocol is formally defined in NIS A219-1,
QSIG Interface Specification at the Q and C Reference Points.
E5.2.1 QSIG Access to the Packet Network

CS2000 supports QSIG over E1 carriers terminated on PVG trunk media gateways. QSIG
signalling is backhauled to the CS2000 GWC using IUA, as for PRI. Control signalling
between the GWC and gateway is ASPEN.
For QSIG calls, the D-channel and the associated B-channel both terminate on the same
gateway, which must therefore support signalling gateway functionality as well as media
gateway functionality. Signalling gateway functionality for QSIG means terminating
ISDN D-channels and backhauling QSIG Layer 3 signalling (SETUP etc) across the
packet network. This enables CS2000 to perform QSIG call processing, and to initiate
media control signalling sessions to control the packet network bearer connections for
QSIG calls.
The mechanism used is to encapsulate the QSIG Layer 3 signalling in IP packets so that
it can be conveyed from the gateway to a CS2000 GWC. The protocol stack used for this
purpose is QSIG (Q.931) / IUA / SCTP / IP, as described in Chapter D10: IUA and
summarised below.
QSIG / IUA / SCTP / IP protocol stack characteristics:
! Used for backhauling Layer 3 signalling to a CS2000 GWC from a PP7480 or
PP15000 PVG supporting PINX access over QSIG trunks. CS2000 GWCs and
gateways are compliant with IUA as defined in IETF draft version 1 of RFC3057.
! QSIG signalling encapsulation
QSIG Layer 3 messages (IS 11572) such as SETUP are conveyed in IUA messages
in the same way that they are normally conveyed in Q.921 Layer 2 messages.
! IUA characteristics:
" Capabilities similar to those of Q.921 Layer 2 (datalink)
" Messages used in Q.921 link establishment and release:
Establish (corresponding to Q.921 DL-ESTABLISH)
Release (corresponding to Q.921 DL-RELEASE)
" Message used for Q.931 message transport:
Data (corresponding to Q.921 DL-DATA)
! SCTP characteristics:
SCTP (Stream Control Transmission Protocol) provides reliable ordered transport
for QSIG messaging, which means that no application-level reliability mechanisms
are required or supported. SCTP is defined in RFC2960. The gateway and GWC are
compliant with draft version 5. Briefly, an SCTP packet comprises:
- Source port number.
- Destination port number.
- User data, i.e. QSIG / IUA message in chunks
- A 32-bit checksum

E5.2.2 Software Support
E5.2.2.1 Datafill and Call Processing

The QSIG call processing agent on CS2000 has been built on the International PRI base,
and is datafilled using the Protocol Version Control (PVC) mechanism defined for PRI.
In conceptual terms, there is a logical terminal (LT) at either end of a QSIG or PRI
LTDEF and LTMAP, as described in section C2.3.2 on page 186 and illustrated in Figure
53 on page 188.
Table LTDEF also specifies the version of PRI to be used over a given interface, which is
identified by means of a unique PVC value generated from the values of the VARIANT and
ISSUE fields in the table LTDEF entry, as follows:
! A variant is a separate call processing agent built on the International PRI base.
QSIG is denoted as variant QSIGPRI.
! An issue is a refinement of a variant that implements minor variations in protocol
and/or procedures. Two issues are currently defined for QSIG:
ISO1996 ISO 1996 QSIG, as defined in ISO 11572/11582 (BC/GF)
ETSI1993 ETSI 1993 QSIG, as defined in ETS 300 172/239 (BC/GF)
Both of these issues can coexist on the same CS2000 and even on the same media
gateway, but a given D-channel and all its associated B-channels must must be
dedicated to one issue or the other.
Note: This QSIG/PRI usage of the term variant reflects the names of the fields in table
LTDEF, but differs from how the term is used for other interfaces such as CCS7. Spanish
ISUP, for example, is defined as a variant of the ETSI ISUP agent, while ISO 1996 QSIG
is defined as an issue of the QSIG PRI variant of PRI.
LTDEF datafill options for QSIG can be summarised as follows:
Protocol version VARIANT field ISSUE field

ISO 1996 QSIG QSIGPRI ISO1996
ETSI 1993 QSIG QSIGPRI ETSI1993
QSIG is also distinguished from ETSI PRI by means of the following datafill:
! Table TRKSGRP
Option 96ISOQSIG for field VERSION. Field PARMNAME used to assign
name/index (e.g. QSIG1) for QSIG entries in table ISDNPARM, which specify
parameters whose values are to be conveyed transparently (e.g. HLC and LLC in
SETUP).
! Table ISDNPROT
Key field PROTVAR has new value QSIGPRI.
The QSIG agent uses Event-Driven Call Processing (EDCP), which means that incoming
QSIG calls (but not virtual calls) can trigger in CS2000 as Intelligent Network (IN) calls.

E5.2.2.2 Message Segmentation

Message segmentation allows a large QSIG message to be broken up into smaller
segments for transfer from an originating node, then reassembled at the terminating node.
A large message is one in which the maximum size of the QSIG SCM (Signalling
Carriage Mechanism) information field would be exceeded. Such a large message may be
required in order to convey a large amount of proprietary data provided by a PBX.
Each part of a segmented message is identified as a SEGMENT message, and begins with
a Segmented Message IE. This IE includes an indication of the number of octets
remaining to be sent and the type of QSIG message that is being segmented, e.g. SETUP
or FACILITY. Following the Segmented Message IE are the IEs conveying the message
content. The first SEGMENT message conveys message content octets beginning with
the octet following the message type octet. The second and subsequent SEGMENT
messages convey further message content octets, beginning in each case with the octet
following the last octet conveyed in the previous SEGMENT message.
Segmentation in CS2000 occurs for outgoing QSIG messages, forward or backward, that
exceed the SCM maximum message size of 260 octets. The outgoing QSIG messages for
which segmentation is supported are listed in the table below.
Messages in the forward direction Messages in the backward direction
SETUP PROGRESS
PROGRESS ALERTING
FACILITY CONNECT
NOTIFY FACILITY
DISCONNECT [1] NOTIFY
RELEASE [1] DISCONNECT [1]
RELEASE COMPLETE [1] RELEASE [1]
RELEASE COMPLETE [1]
[1] Only the first clearing message sent by CS2000 in a call release sequence can be segmented.
The maximum number of segments is eight, making the maximum message size 260 x 8
= 2080 octets. If more than eight segments would be needed and the message to be
segmented is a call control message, the call is released. Otherwise, the message is
discarded. Once the first segment of a segmented message has been transmitted, all
remaining segments of that message shall be sent (in order) before any other message is
sent on that connection.
Notes:
! Message segmentation is not supported for messages that cannot include Facility or
Notify IEs.
! CS2000 may also need to add some extra data bytes to an outgoing message, e.g. to
support AOC, in which case additional complete IEs can be added to the segmented
message subject to the 2080-byte overall limit on message size.
! CS2000 also supports ISUP message segmentation for ETSI ISUP V2+ IAMs, both
on the TDM side and for ISUP encapsulated in SIP-T. For an ISUP message
conveying QFT information using the ISUP APM, the QSIG and ISUP
segmentation/re-assembly procedures are completely decoupled from each other,
i.e. the number of received/transmitted QSIG SEGMENT messages may not equal
the number of transmitted/received ISUP APM messages. Similarly, the number of
QSIG SEGMENT messages may not equal the number of SCCP XUDT messages
for non-bearer QFT calls.

E5.2.2.3 QSIG Feature Transparency (QFT)

CS2000 supports both bearer and non-bearer QFT, as described in section E5.1.5, and
uses them to support VPN capabilities. The CS2000 implementation of the APM
extensions to ETSI ISUP, as used to support QFT, is defined in detail in NIS A246-1bis.
The CS2000 implementation of QFT is defined in detail in NIS A246-1ter.
Non-bearer QFT VPN is supported by a Q.VPN TCAP application in CS2000. This
application uses the existing ISDNSS (ISDN supplementary services) subsystem number,
which it shares with other ISDNSS-based TCAP services such as CCBS (Call Completion
to Busy Subscriber). The VPN TCAP application is connection-oriented, and uses a
TCAP dialogue to transport VPN information over the public signalling network.
Note: In ISN07, CS2000 supports TCAP signalling for non-bearer QFT only via a
conventional CCS7 signalling network. TCAP / SCCP / MTP3 / M2PA is not supported
for non-bearer QFT.
Originating Node Capabilities

As an originating node, i.e. the node providing a VPN service to a PINX connected to it
via QSIG, a CS2000 can route an incoming QSIG call over ETSI ISUP (for bearer-related
calls) or SCCP (for non-bearer calls) using QFT. In this role, the CS2000 is the entry point
to the public network, and is referred to as a Public Initiating Node (PIN), as defined in
section E5.1.5.3 on page 472. Figure 119 provides a simplified view of the configuration.
CS2000
QSIG Virtual ISUP with QFT
PINX transit ISUP v2 network
PINX
QFT TC protocol Destination:

assumed to
SCCP network support QFT
Figure 119: Originating node capabilities
CS2000 assumes that routing datafill has been correctly set up so that the call will be
routed to another MGC that supports the QSIG Feature Transparency protocol. Additional
translations support is provided to allow both QFT and non-QFT bearer calls to use the
same ETSI ISUP trunks.
Non-bearer calls use the same translations as bearer calls. If the route determined by
translations is an ISUP one, then for non-bearer calls the QFT protocol will be used over
TCAP/SCCP. Standard translations yield a Called Party Number which is used as the
Global Title to route the QFT non-bearer call.
If, subsequent to call setup, an indication is received that the addressed node does not
support QFT, then the call will be cleared.

Terminating Node Capabilities

CS2000 behaviour as a terminating node depends on whether the incoming call is
intra-group or inter-group. This is determined by comparing the customer group of the
caller (derived from the BGID received in the incoming message) and the customer group
of the termination (from table TRKGRP).
If the customer groups match, the call is deemed to be private. In the case of QSIG access,
CS2000 will pass the QSIG information received over ISUP to the access, performing the
functions of a Virtual Transit PINX. In this role, the CS2000 is the re-entry point to the
private network, and is referred to as a Public Addressed Node (PAN), as defined in
section E5.1.5.3 on page 472. Once a QFT signalling association is set up, information is
exchanged directly between the PIN and PAN. Any intermediate nodes simply relay it.
If the customer groups do not match, the call is deemed to be public, and CS2000 will
perform the functions of a Virtual Gateway PINX. CS2000 supports only basic call
gateway functions, so all QSIG IEs except the Called Party Number and Facility IE are
immediately discarded. The Facility IE is discarded after being processed in accordance
with the GFT to determine whether the call should be cleared or allowed to continue. The
Called Party Number IE is available for use by translations if the call is allowed to
continue.
QFT Translation Options

Four translations options have been introduced in order to support QSIG Feature
Transparency calls.
! QFT option
The QFT option can be added to CONT and RTE selectors in xxCODE tables, or to
the default route (DFLT) or default option (DFOP) in xxHEAD tables. It indicates
that a given route supports QFT capabilities, and causes customer group comparison
to be performed for outgoing calls on that route.
! VPNPAN option
The VPNPAN option can be added to CONT and RTE selectors in xxCODE tables,
or to the default route (DFLT) or default option (DFOP) in xxHEAD tables. It
causes the PAN flag to be set, to indicate that the PINX is to act as the PAN (Public
Addressed Node) for an outgoing route.
! VPNREPL option
This option can be associated with the DMOD (digit modification) selector within
universal translations. It causes CS2000 to begin translating the digits encapsulated
in the QFT message instead of the digits currently being translated, and to update
the NoA/NPI of the called party number.
! VPNXLT option
This option can be associated with the DMOD selector within universal translations.
It causes CS2000 to continues translations with a new translations system and
translator name (XLASYS and XLANAME). The BGID received in the incoming
QFT message is used as an index to retrieve this new system and name from table
BGIDMAP.
The PAN flag set by the VPNPAN option can also be set by the DMOD options
VPNREPL and VPNXLT, in which case the VPNPAN option need not be used. In case
of a public numbering plan, the VPNPAN option must be used to set the PAN flag because
the VPNREPL and VPNXLT options are not used.

Business Group Identifier (BGID)

The Business Group Identitier (BGID) of the calling party is always included in the initial
setup message for a QFT call (bearer or non-bearer). Within CS2000, each BGID is
mapped 1:1 on to a customer group by means of table BGIDMAP This table also specifies
the translation system and translator name (XLASYS and XLANAME) to be used for that
customer group when the QFT translation option VPNXLT is encountered. If a BGID is
received that is not found in table BGIDMAP, the call is cleared.
E5.2.3 Compliance with Specifications

The CS2000 implementation of QSIG is defined in detail in the following Nortel Strategic
Interface Management (SIM) specifications:
! QSIG Interface Specification at the Q and C Reference Points
NIS number: A219-1
! ETSI ISUP version 2+
ISN Implementation of the Application Transport Mechanism (APM)
NIS number: A246-1bis
! ETSI ISUP version 2+
ISN Implementation of QSIG Feature Transparency (QFT)
NIS number: A246-1ter
! EndPINX Specification
NIS number: A246-1quat
Compliance of the CS2000 implementation with the specifications listed in section E5.1.6
is as follows:
! Compliant with IS 11572 (and ETS 300 172) with regard to basic call control and
protocol, except as noted in the SIM specification.
! Compliant with IS 11582 (and ETS 300 239) with regard to generic functional
procedures for the control of supplementary services, i.e. GFT functionality is
supported. The following generic ROSE APDUs are supported:
" InvokePDU
" ReturnResultPDU
" ReturnErrorPDU
" RejectPDU
This means that the CS2000 implementation is compliant with ROSE as defined in
ITU Recommendation X.219. It is not compliant with ACSE as defined in X.217.
! Compliant with TCAP support for non-bearer QFT as defined in Q.765.1 and with
ISUP support for bearer QFT as defined in Q.765, except as noted in A246-1bis and
A246-1ter.

! Compliant with ECMA 226 and IS 14474 for logical/physical mapping, subject to
the use of PRI as the supporting physical adaptation. This implies the following:
" Data link layer compliant with ISDN PRI as defined in ITU-T
Recommendations Q.920 and Q.921, as modified by ETS 300 402.
" Physical layer compliant with ISDN PRI as defined in ETS 300 011, which is
based on ITU-T Recommendations I.431 and G.703-G.706.
Note: The QSIG SIM Specification incorporates an annotated version of ECMA
226 as its Section B, Part 2, to describe logical/physical mapping. For completeness,
Nortel has also produced an alternative Section B, Part 2 consisting of an annotated
version of ISO/IEC 14474 (which deals with the same subject as ECMA 226); this
is available as a free-standing document.
! Compliant with IS 15049 / ECMA 211 and IS 15050 / ECMA 212 for the AOC
supplementary service, except as noted in the QSIG SIM specification.
! Compliant with E.164 for support of Open Dial Plans (ODPs)
E5.2.4 ISDN Services Supported

The services that have been implemented and are available over the CS2000 QSIG
interface are shown in Table 42.
Table 42: CS2000 Implementation of ETSI-Defined Services
Service Type Service Name

Circuit mode speech bearer service
Circuit mode 64kbit/s unrestricted bearer service
Bearer Services
Circuit mode 3.1kHz audio bearer service
Circuit mode rate adapted 56kbit/s data
3.1 KHz telephony
Telefax Group 4
Teleservices
Teletex
Videotex
Calling Line Identification Presentation (CLIP) [1]
Calling Line Identification Restriction (CLIR) [1]
Supplementary services
Advice Of Charge During Call (AOC-D)
Advice Of Charge at End of Call (AOC-E)
Call Completion on No Reply (CCNR)
Additional Network Features Transit Counter
[1] Implemented as part of QSIG basic call, not as a supplementary service involving additional
signalling.
QSIG also supports the German public network features Priority Class Of Service
(PCOS), Emergency Calls, Carrier Selection and Network Advice Of Charge (NAOC).

E5.2.5 Summary of Capabilities

Both issues of QSIG (ISO1996 and ETSI1993) support the following circuit-switched
basic call control procedures:
! Basic call control procedures, including:
- Call establishment
- Call clearing
- Call collision recovery
- Overlap sending and receiving
Note: A maximum of 29 digits can be outpulsed for a called party number. This
exceeds the 20-digit limit specified in ETS 300 403.
! Support for the following QSIG PINX functionality:
- Transit PINX
- Gateway PINX (incoming and outgoing) supporting interworking with
non-QSIG trunks
- Originating or terminating End PINX supporting interworking with directly
connected lines.
! QSIG GFT
! QSIG NCAS (Non Call Associated Signalling) via a conventional CCS7 signalling
network
! QSIG segmentation
! QSIG Feature Transparency (bearer and non-bearer)
! Transparent transport of High Layer Compatibility (HLC), Low layer compatibility
(LLC), and Calling/Called Party Subaddress
! Bearer Capability routing
! Transparent transport of release cause values
! Services
- CLIP / CLIR
- AOC supplementary service
- CCBS / CCNR supplementary services
- Transit Counter additional network feature
! Echo control
As for PRI, echo control is always used for QSIG non-data calls, on the assumption
that the gateway is close to the point of reflection and is therefore the best place to
apply echo cancellation. The use of ISUP signalling procedures ensures that the
Note: Although QSIG as such is not used across packet networks, CS2000 uses the
ISP1996 issue QSIG internally, for signalling across the CS LAN between the Core and
H.323 GWCs. The H.323 GWC performs message mapping between H.225 call control
messages and equivalent QSIG messages. For H.323 tunnelling, this message mapping
involves converting H.225 IEs conveying encapsulated H.450 and H.245 signalling into
QSIG Facility IEs conveying the same encapsulated signalling unmodified. See Chapter
D5: H.323 for further information. Also see Chapter E6: DPNSS Interface, as this
H.323/QSIG mapping capability is used to support DPNSS signalling and feature
transparency for DPNSS PBXs connected to Westell gateways and controlled via H.323.

E5.3 Limitations
! The CS2000 implementation of QSIG does not support the following call control
procedures:
" Signalling procedures for high layer compatibility selection
" Circuit-mode multirate (64 kbit/s base rate) procedures
! Facility IEs received in a second or third call clearing message (i.e. RELEASE or
RELEASE COMPLETE) in a call takedown sequence are not examined or acted on
by the CS2000 QSIG GF implementation, and will not be transited through a
CS2000 acting as a transit PINX.

QSIG feature set support can be categorised as follows:
! Features supported as part of basic call
Calling Line Identification Presentation (CLIP)
CLI Restriction (CLIR)
! Support for QSIG Additional Network Features (ANFs)
Transit Counter
! VPN support via QSIG Feature Transparency (bearer and non-bearer)
! Support for specific ETSI ISDN supplementary services
Advice Of Charge (AOC)
! Support for public network features (all German)
Priority Class Of Service (PCOS)
Emergency Calls
German Carrier Selection
Network Advice Of Charge (NAOC)
See Chapter F5: QSIG Services for more details.
E5.5 Order Codes for QSIG
Table 43: Order codes for QSIG software

PRIT0012 QSIG
VPNW0004 QFT over ETSI ISUP

Chapter E6 DPNSS Interface

E6.1.1 Conceptual Network Role
DPNSS is a common channel signalling system for peer-to-peer communication between
digital PBXs and/or switches. It can be used within a private network, or to support
Virtual Private Network (VPN) capabilities within a public network; calls originating
from the PSTN can be routed via a DPNSS private network to terminate back on the
PSTN. As a UK standard interface, DPNSS can be used to link different node types in a
Figure 120 is a schematic illustration of the network role of DPNSS and the different
types of DPNSS functionality that may be provided.
Lines Lines
End node PBX or End node
functionality switch, functionality
e.g.
CS2000
PBX or PBX or
switch, DPNSS Transit node DPNSS switch,
e.g. functionality e.g.
CS2000 CS2000
Non-DPNSS Non-DPNSS
trunk Gateway Gateway trunk
functionality functionality
Figure 120: The network role of DPNSS

Communication Server Capabilities Telephony Interfaces DPNSS Interface
E6.1.2 Protocol
The DPNSS interface presented by a CS2000 network to the PBXs it serves is defined as
a layered protocol with the following structure:
! Level 1 corresponds to Layer 1 (Physical) of the OSI 7-layer model. Physical
DPNSS links between PBXs and the network are provided by 2Mb/s PCM30
carriers. Each carrier supports 30 64Kb/s traffic channels for speech or data, and one
64Kb/s signalling channel (TS16).
! Level 2 corresponds to Layer 2 (Data link) of the OSI 7-layer model. The data link
uses the Link Access Protocol (LAP) defined in Section 3 of BTNR 188 to support
30 real signalling channels, each associated with a traffic channel, and 30 virtual
signalling channels.
! Level 3 is the network/application layer, and encompasses the functions of Layer
3-7 of the OSI 7-layer model. It provides the call handling function by sending and
receiving DPNSS messages over the signalling channels provided by the data link.
Messages are conveyed in HDLC (High-level Data Link Control) frames that
identify the related traffic channel (if any) and use serial numbers to avoid loss of
frames (which are resent until acknowledged).
Within a CS2000 network, in which 30B+D carriers are by definition not used, DPNSS
Level 3 signalling is conveyed via a number of different lower-level protocols, as
explained in section E6.2 on page 485.
E6.1.3 Call Setup and Clearing

Figure 121 illustrates the messaging involved in the setting up and clearing of a typical
DPNSS real call. A real call, e.g. a normal person-to-person call, has an associated traffic
channel. This is seized when the ISRM is sent, through-connected when the CCM is
received, and remains connected until a CRM has been sent.
node node
Caller goes
off-hook and
dials number ISRM (Initial Service Request Message)
Ringing Physical
tone NAM (Number Acknowledgement Message) ringing
Called party
CCM (Call Connect Message) answers
Call in progress
CRM (Clear Request Message)

Caller goes
on-hook to CIM (Clear Indication Message)
terminate call
Figure 121: DPNSS call setup and clearing
DPNSS also supports virtual calls, which allow features to be activated without using an
associated speech or data path. The messaging involved in call setup and clearing is
similar, but no traffic channel is seized. Virtual call setup is initiated by an ISRM and call

DPNSS Interface Telephony Interfaces Communication Server Capabilities
clearing involves CRM and CIM messages, as for real calls, but messages related to
in-band activity, e.g. NAM and CCM, are not required.
DPNSS is defined in BTNR 188. Interworking to other UK signalling standards (e.g.
DASS2) is defined in BTNR 189.

E6.2.1 Network Configuration
The external DPNSS interface presented by a CS2000 network to PBXs is supported on
E1 carriers. Each TDM-side carrier is terminated on a Westell iQ2030 Series gateway
(30-channel iQ2030 with one E1 or 60-channel iQ2032 with two E1s), which is controlled
by a H.323 proxy GWC located on the CS2000 CS LAN. Within the CS2000 network,
DPNSS Level 3 signalling is conveyed via a number of different lower-level protocols, as
illustrated in Figure 122 on page 486 and explained in the following list:
! The Westell gateway supports interworking between TDM DPNSS and H.323.
Between the Westell gateway and the GWC, H.225 messaging is used for call
control. DPNSS Layer 3 messages are mapped on to H.225 equivalents, with
DPNSS information that has no unique H.225 equivalent being conveyed
transparently in Westell-defined manufacturer-specific H.450.1 operations
encapsulated in User-to-User Information IEs in H.225 messages.
! The H.323 proxy GWC supports interworking between H.323 and QSIG. Between
the H.323 GWC and the CS2000 Core, QSIG messaging is used for call control.
Because H.225 and QSIG are both based on Q.931, H.225 messages can be mapped
on to QSIG equivalents. The H.450.1 APDUs containing DPNSS signalling are
extracted from UUI IEs in H.225 messages and encapsulated unmodified in Facility
IEs in QSIG messages.
! The CS2000 Core supports two types of interworking for DPNSS encapulsated in
QSIG:
" Direct interworking to DPNSS encapsulated in QSIG for other DPNSS PBXs
served by the same CS2000.
" Interworking to DPNSS Feature Transparency (DFT) trunks. A DFT trunk is
an IBN7 trunk with option CFT datafilled against it in table IBNRTE and the
DFT option datafilled in table NCOS. It uses the general-purpose
ANSI-defined Network Transport Parameter (NTP) to convey the Nortel
proprietary Hybrid Network Information Parameter (HNIP), which can in
turn convey encapsulated DPNSS signalling. Depending on how it is
configured, such a DFT trunk can enable DPNSS signalling to/from a DPNSS
PBX to be interworked with any of the following:
# A TDM-side DFT trunk can support connections with a circuit-based
DPNSS VPN.
# A DFT packet trunk (IBN7 encapsulated in SIP-T) can support
connections with DPNSS terminations served by other CS2000s.
# A looparound DFT packet trunk can support intra-CS2000 connections
with IBN lines to which DPNSS features have been assigned at the
customer group level.

Figure 122 illustrates the network configuration used by CS2000 to support DPNSS
signalling.
CS2000 DPNSS over DFT trunks To/from other

(NTP[HNIP] in IBN7 messages) CS2000s
CS LAN
CS2000
Core
To/from TDM VPNs
Looparounds for
interoperability
with IBN lines
H.323 H.323
proxy proxy
GWC DPNSS over QSIG GWC
(in QSIG Facility IEs)
DPNSS DPNSS
over H.323 over H.323
(in H.225 (in H.225
UUI IEs) UUI IEs)
IP core network
DPNSS DPNSS
over E1 over E1
carriers Westell Westell carriers
Digital iQ203x iQ203x Digital
PBX Bearer connections PBX
gateway gateway
Figure 122: CS2000 support for DPNSS signalling

E6.2.2 Different Types of DPNSS Functionality

Note: For simplicity, the illustrations in this section show CS2000 as a single node. This
should be taken to include all of the network elements involved in presenting the external
DPNSS interface to a PBX, i.e. the CS2000 Core, the H.323 proxy GWC and the Westell
iQ203x gateway. From the perspective of the DPNSS PBX and for the purpose of
explaining the different types of DPNSS functionality being provided, the fact that
multiple network elements are involved is irrelevant.
E6.2.2.1 DPNSS Transit Node Functionality

DPNSS transit node functionality means acting as an intermediary between two DPNSS
PBXs, connecting them by direct interworking as if there were a direct DPNSS link
between then, as illustrated in Figure 123. This scenario is supported by CS2000. For the
CS2000 Core, the interworking actually involves the transparent relaying of DPNSS
signalling encapsulated in H.450.1 APDUs between two QSIG interfaces.
Transit node functionality means CS2000

involvement in call is transparent
DPNSS DPNSS
PBX PBX
CS2000
DPNSS DPNSS
features features
Figure 123: DPNSS transit node functionality
In addition to supporting DPNSS transit node functionality for two PBXs served by the
same CS2000, CS2000 can support transit node functionality for two PBXs served by
different CS2000s. In this scenario, two or more CS2000s serve as a single logical DPNSS
transit node, with connections between them being provided by IBN7 trunks that support
DFT (DPNSS Feature Transparency). DFT involves encapsulating DPNSS information
in ISUP or TCAP messages and transporting it transparently across the network. CS2000
supports transit node functionality both when interworking DPNSS to a DFT trunk and
when interworking two DFT trunks, as shown in Figure 124.
Transit node functionality
PBX DPNSS DFT DFT DPNSS PBX

CS2000 CS2000 CS2000
DPNSS DPNSS
features features
Figure 124: Transit node functionality provided by DFT trunks
Inter-CS DFT trunks used to support DPNSS transit node functionality may be either
DPTs between GWCs on different CS2000s or circuit-based trunks between TDM-side
endpoints on PVG trunk gateways controlled by different CS2000s.
CS2000 supports DFT using two types of proprietary IBN7 signalling:
! IBN7 ISUP for real DPNSS calls
The Network Transport Parameter (NTP) conveys the Nortel proprietary Hybrid
Network Information Parameter (HNIP).
! ANSI TCAP for DPNSS virtual calls with no associated bearer circuit

The principle underlying DFT support is that end nodes must be able to reconstitute the
DPNSS information they receive and provide DPNSS functionality. This means:
! DPNSS parameters that can be uniquely mapped are interworked.
! Parameters that cannot be uniquely mapped are conveyed transparently.
! As far as ISUP call setup is concerned, DFT information is optional, and will be
discarded if it cannot be recognised.
See section F6.2.2 on page 594 for more information about DFT support.
E6.2.2.2 DPNSS End Node Functionality

DPNSS end node functionality means acting as an intermediary between an IBN line
interface and a DPNSS PBX. It involves using customer group datafill to make an
appropriate subset of DPNSS features available to lines, such that they can use DPNSS
features on calls to or from the PBX. It thus implies support for DPNSS services on
interworking to a DFT line (an IBN line with the DFT option datafilled in table NCOS).
For a call involving DPNSS end node functionality, one of the end nodes is a PBX
connected to a CS2000 switch via DPNSS, and the other is the CS2000 itself (actually, a
CS2000-controlled line gateway), providing DPNSS services to its IBN lines.
Because the CS2000 Core does not support direct interworking between QSIG and DFT
lines for support of DPNSS services, an IBN7 DFT looparound trunk (normally a SIP-T
DPT) must be used as an intermediary in the call.
Note: A SIP-T looparound is not a direct physical link, but a logical connection between
two DPT GWC ports controlled by the same CS2000.
Figure 125 illustrates the configuration used for a nodal call involving DPNSS end node
functionality.
End node functionality means

availability of DPNSS features
to IBN line user
DPNSS
PBX CS2000 line interface
DPNSS DFT DPNSS
features features
looparound
Figure 125: DPNSS end node functionality
Lines that are to be interworked to DFT in this way must have the DFT option datafilled
in table NCOS.

E6.2.2.3 DPNSS Gateway Functionality

DPNSS gateway node functionality means the interworking of DPNSS signalling with a
non-DPNSS or non-DFT trunk, as shown in Figure 126. Only basic call support is
guaranteed, not necessarily support for DPNSS features; feature support depends on the
specific interworking and service.
In the CS2000 implementation of DPNSS, DPNSS gateway functionality is provided by
first interworking DPNSS to QSIG via the Westell gateway and the H.323 GWC, as
illustrated in Figure 122 on page 486. The level of feature support is therefore determined
by what is supported for QSIG interworking to the non-DPNSS interface, e.g. many
Centrex services can be supported.
Figure 126 is a simplified view of the configuration used to provide DPNSS gateway
functionality.
CS2000
DPNSS QSIG Non-DPNSS trunk i/f

PBX I/W
DPNSS
features
Figure 126: DPNSS gateway functionality (provided via QSIG)
E6.2.3 Compliance with Specifications

The CS2000 implementation of DPNSS is fully compliant with all the mandatory parts of
sections 0 to 5 of BTNR 188 Issue 4. It is also fully compliant with all requirements for a
simple telephony call, as specified in BTNR 188 Issue 5 Section 6.
Sections 7 to 48 of BTNR 188 define requirements for support of DPNSS features.
CS2000 support for DPNSS features is discussed in Chapter F6: DPNSS Features.
E6.3 Order Codes for DPNSS
Table 44: Order codes for DPNSS software

SW Order Code Description
PBXA0002 DPNSS base
PBXA0019 DPNSS to IBN7 (ANSI ISUP+) interworking
CS2B0004 H.323 support

Chapter E7 IBN Lines

The IBN line interface supports access to a CS2000 network for individual users. The
capabilities provided are equivalent to those available to conventional POTS lines serving
DTMF telephone sets. IBN (Integrated Business Network) lines are so called because this
is how they are datafilled at the CS2000, and because they can be assigned a wide range
of value-added services that were originally developed for the use of business customers.
IBN lines can also be assigned the CEPT line option; this allows CEPT services and CEPT
versions of proprietary services to be assigned to them.
Basic signalling information is conveyed from the subscribers telephone set towards the
network by means of in-band signalling using DTMF tones or standard POTS electrical
signals. Signalling received by the subscribers telephone (tones, announcements and
standard POTS electrical signals) is also in-band.
In ISN07, CS2000 supports the following different analogue subscriber line
implementations, each of which is described in a separate section of this chapter:
! Lines supported via large carrier-located line gateways (see section E7.2.1 on page
491).
! Lines supported via cable access networks (see section E7.2.2 on page 493).
! Lines supported via gateways attached to customer LANs (see section E7.2.3 on
page 497).
! Lines supported via V5.2 Access Networks (see section E7.2.4 on page 499).
protocols used by CS2000 to support line access.
IBN line usage on CS2000 is controlled via SOC option ILIN0100. When a new
GWC-hosted IBN line is provisioned on the Core, ILIN0100 usage is updated. The limit
for ILIN0100 is set by purchasing line usage through Nortel customer service, subject to
the overall maximum of 130,000 CS2000 lines. SOC logs will be generated if the agreed
limit on line numbers is exceeded. See A59040404 for details.

IBN Lines Telephony Interfaces Communication Server Capabilities

E7.2.1 Lines off Large Carrier-Located Gateways
E7.2.1.1 Functional Overview

Carrier-located line media gateways provide essentially the same functionality as CPE
line gateways attached to cable acess networks or customer LANs, as described in
sections E7.2.2 and E7.2.3 respectively, i.e. access to the packet backbone network for
VoIP and data. The main difference is that carrier-located gateways are significantly
larger, such that a given gateway can support access for hundreds or even thousands of
end users.
This increases the range of deployment options that a carrier network can offer its
customers. Specifically, it enables customers who do not wish to own and maintain their
own access networks to lease capacity from the carier network instead.
Typically, a carrier located line media gateway supports both VoIP and high-speed data
access for subscribers. Figure 127 provides a simplified functional view of the capabilities
provided.
CS2000 CS LAN
CS2000 Core
MS2000
GWC
GWC-gateway
Dual PP8600s signalling (H.248)
Core Bearer connections for VoIP

network
Bearer connections for data
are independent of
MG9000 CS2000-controlled VoIP connections
Lines and ADSL
Figure 127: Functional view of capabilities provided by carrier located line media gateways

Communication Server Capabilities Telephony Interfaces IBN Lines
E7.2.1.2 Specific Gateway Types Supported (MG9000)

In ISN07, CS2000 supports the deployment of the MG9000 as a carrier-located line media
gateway. The remainder of this section briefly describes MG9000 capabilities. For
configuration details, see section B2.8 on page 119.
MG9000 shelves are housed in four-shelf frames. Each shelf provides up to 16 Service
Module (SM) slots for cards supporting multiple line interfaces, as follows:
! POTS-32 card providing 32 terminations for basic analogue lines (Type A POTS)
! POTS+ADSL card providing terminations for 8 analogue lines and 8 ADSL lines
A single-shelf MG9000 unit can provide gateway functionality for up to 406 POTS lines
or 104 POTS lines together with 104 ADSL lines. Different types of service module card
can be mixed in a shelf.
To make the most efficient use of the STM-1 connection with the backbone network, an
MG9000 typically comprises one master shelf and one or more subtending shelves. A
fully equipped four-shelf frame in which only the master shelf has a packet network
connection is regarded as one logical MG9000 unit. This configuration offers 61 service
module slots per frame (13 on the master shelf and 16 on each subtending shelf), and thus
supports the following access network capacity:
! 1952 POTS lines per frame
! 488 POTS+ADSL lines per frame
E7.2.1.3 GWC - Gateway Signalling

To support analogue subscriber lines off a carrier-located media gateway, H.248 is used
for all signalling between GWC and MG. See section D3.6.2 on page 266 for a description
(including an annotated call flow) of the H.248 messaging involved in basic call setup for
MG9000 lines.

E7.2.2 Cable Lines off MTA Gateways

E7.2.2.1 Access Configuration
In ISN07, CS2000 analogue subscriber lines can be supported by MTA (Multimedia
Terminal Adapter) media gateways. An MTA line gateway is not directly connected to the
IP backbone network. Instead, it is connected to a HFC (Hybrid Fibre Coax) cable access
network, which is in turn connected to the IP backbone network via a CMTS (Cable
Modem Termination System) and an edge router. IP packets sent from the MTA are
conveyed over the HFC network, through the CMTS and into the IP backbone network.
Communication between CMTS and MTA is based on DOCSIS 1.1 (Data Over Cable
System Interface Specification) or EuroDOCSIS 1.1 signalling, but this is relevant only
within the access network and is not visible to the CS2000 GWC.
A variety of hardware platforms can be used to support MTA line gateway capabilities
for CS2000 solutions (see section B2.10 on page 126 for more details). The basic
functional elements are the same regardless of the MTA model and of whether DOCSIS
or EuroDOCSIS signalling is used betwen the MTA and the CMTS. They are:
! RJ-11 terminations for analogue subscriber lines
! An Ethernet / USB port for PC access
Note: CS2000 is not involved in supporting this functionality.
! Codecs (G.711 A-law, 10ms packetisation rate)
! A HFC (Hybrid Fibre Coax) termination supporting access to the IP backbone
network via a cable access network
Figure 128 illustrates the logical configuration of the access network used by MTA line
gateways. Communication between CS2000 GWCs and MTA line media gateways
involves both the IP backbone network and the HFC cable access network. Media control
and call control are both supported by NCS (Network-based Call Signalling) between the
GWC and the MTA, as shown. NCS is described in Chapter D7: NCS..
Three types of information flow take place over the HFC

network:
NCS control connections between CS2000 GWC and
MTA (NCS signalling routed/relayed via CMTS and edge IP backbone network
router)
DOCSIS control connections between CMTS and MTA
(terminated at CMTS)
Bearer connections (DOCSIS packet flows converted
to/from IP packet flows at CMTS)
HFC cable access network
Multimedia Terminal Adaptor
HFC
Two RJ-11 CMTS
Codecs cable modem NCS
terminations supporting supporting
for analogue analogue / access to the (Euro)DOCSIS Edge
subscriber digital IP backbone router
lines (also an network via a Bearer flows
conversion
Ethernet/USB (G.711 A-law) cable access
port for a PC) network
Figure 128: Logical configuration of an MTA line gateway

E7.2.2.2 Call Flow for VoIP Call between Two CS2000 Cable Lines
This section provides an overview of the process of setting up a call between two CS2000
lines served by the same CS2000. It therefore deals with:
! The handling of an incoming call from a CS2000-controlled line
! The handling of an outgoing call to a CS2000-controlled line
shown in Figure 129, and are described in order on the following pages.
Analogue subscriber lines
Packet network bearer connections
CS2000
Call processing
6
2 5 7a 7b
Gateway 10 Gateway
(GWC) 13 (GWC)
gateway 20 gateway
3 8a 14 17 21 11 15 19

IP backbone network
Bearer connection
(packetised voice)
CMTS CMTS
1 9 12 18
4 22a HFC cable access networks 16 22b
Signalling between CMTS and MTAs
Originating is based on (Euro)DOCSIS, and is Terminating
Gateway not visible to the CS2000 GWCs that
control the MTA gateways Gateway
(MTA) (MTA)

Figure 129: Setting up a VoIP call between two CS2000 lines

1
MTA line gateway sends NCS NTFY (offhook) to ingress GWC to report subscriber
going off-hook; GWC acknowledges NTFY by sending NCS 200 OK to gateway
2 Ingress GWC sends an origination message to the CS2000 Core.
Ingress GWC sends RQNT to MTA gateway, instructing it to:

3 - Provide dial tone
- Collect DTMF digits in accordance with a digit map
MTA gateway accumulates dialled digits in accordance with the digit map; when a digit
map match occurs, gateway sends NCS NTFY (digits) to GWC to convey the digits
4 collected; GWC acknowledges NTFY by sending NCS 200 OK to gateway. Depending
on the dial plan, the GWC may send further digit maps, e.g. to switch to reporting each
digit as it is dialled.
5 Ingress GWC passes received digits on to the Core
6
The Core uses received digits to perform translations and routing, resulting in the
identification of the egress GWC and MTA gateway serving the destination line
The Core sends FCM (Fabric Control Message) to the ingress and egress GWCs to
7a
7b initiate establishment of bearer path connection between the MTAs, and to set up
communication between the two GWCs.
Ingress GWC sends CRCX to originating MTA line gateway, instructing it to set up an
8
initially inactive bearer connection for the line endpoint in question, specifying:
- The callID to be used in all subsequent connection control messages
- Local connection options set to PCM A-law with 10ms packetisation
MTA gateway acknowledges CRCX and provides the SDP session description to be
used for receiving audio data, including information such as:
- IP address at which the gateway is ready to receive audio data
9
- Transport protocol, i.e. RTP
- Audio profile, i.e. AVP
- RTP port identifier
- Payload type as defined in RFC 1890, i.e. 8 (corresponding to G.711 A-law)
- Packetisation period of 10ms
10
Ingress GWC passes originating gateways SDP session description (including IP
address) to egress GWC
Egress GWC sends CRCX to terminating MTA line gateway:

- Instructing the gateway to create an initially inactive bearer connection for the
11
selected line endpoint, with local connection options set to PCM A-law with 10ms
packetisation
- Passing on the SDP session description provided by the originating MTA line
gateway
Terminating gateway sends NCS 200 OK to egress GWC in response to CRCX; this
12 includes the terminating SDP service description (including IP address), which will be
the one used for the call.
13 Egress GWC provides terminating SDP session description to ingress GWC
14
Ingress GWC sends MDCX with terminating SDP session description to the originating
MTA line gateway

Egress GWC sends RQNT to terminating MTA line gateway, instructing the gateway
15 to apply ringing to the terminating subscriber line and to report the called party going
off-hook (at which point ringing will stop)
16
Terminating MTA gateway sends NCS 200 OK to indicate that ringing is being applied
to the called party line
17
Ingress GWC sends RQNT to originating MTA line gateway, instructing the gateway
to apply ringback tone
18
Terminating MTA gateway sends NCS NTFY (offhook) to egress GWC to report called
party going off-hook; GWC acknowledges NTFY by sending NCS 200 OK to gateway
Egress GWC sends NCS MDCX to terminating MTA line gateway, instructing the
19
gateway to place the bearer connection in send/receive mode, and to report the
subscriber going on-hook again; MTA gateway acknowledges RQNT by sending NCS
200 OK to GWC
20 Egress GWC notifies ingress GWC that call has been answered
Ingress GWC sends MDCX to originating MTA gateway, instructing it to place the
21 bearer connection in full duplex mode (mode = sendrecv), stop applying ringback tone,
and provide notification of the subscriber going on-hook again
22a The call is fully established when both the originating and teminating MTA gateways
22b have responded with an NCS 200 OK to the request to provide on-hook notification
DQoS (Dynamic Quality of Service) for cable gateways involves additional signalling
during call setup to ensure that network congestion and resulting packet loss is avoided.
DQoS provides mechanisms that enable the CMTS to reserve bandwidth in the HFC
access network (via RSVP) and to prioritise traffic in the backbone network (via
DiffServ). In addition to bandwidth allocation, DQoS helps prevent denial of service
attacks and illegal use of network resources. See section D7.7 on page 317 for further
information.

E7.2.3 Customer LAN Lines

A customer LAN line gateway consists of a gateway software load running on a dedicated
hardware platform to support VoIP. Specifically, it supports voice-only access to an IP
backbone network for analogue subscriber lines.
A customer LAN line gateway is not directly connected to the IP backbone network.
Instead, it is connected to an Ethernet LAN, which is in turn connected to the IP backbone
network (a variety of access mechanisms are available). The gateway is typically located
on customer premises. A range of technology options are available for implementing the
customer LAN and enabling it to access the backbone packet network; the most
appropriate technology to use in a given CS2000 network configuration should be
A variety of hardware platforms can be used to support customer LAN line gateway
capabilities for CS2000 solutions (see section B2.9 on page 123 for more details), but the
basic functional elements are the same regardless of the media gateway model. They are:
The three main functional elements in any customer LAN line gateway are:
! RJ-11 or RJ-21X terminations for analogue subscriber lines
! Ethernet LAN interface
! Codec supporting analogue / digital conversion for bearer connections
Figure 130 illustrates these gateway components and their functions at a logical level.
Customer LAN
Customer LAN Gateway
MGCP
RJ-11 or Codecs LAN interface MGCP
RJ-21X supporting supporting Alternative IP
terminations analogue / access to the access
for analogue digital IP backbone technologies
backbone
subscriber conversion network via a Bearer flows available network
lines (G.711, G.729) customer LAN
Bearer flow
Figure 130: Logical configuration of a customer LAN line gateway

E7.2.3.2 GWC-Gateway Signalling

The protocol used to provide media and call control signalling for customer LAN line
gateways is MGCP, as described in Chapter D8: MGCP. Commands supported:
CRCX Create connection
MDCX Modify connection
DLCX Delete connection
RQNT Request notification
NTFY Notify
This is essentially the same range of commands as the NCS protocol used for MTA line
gateways, which is based on MGCP. The call flow for calls to/from LAN gateway lines
is therefore essentially the same as the MTA cable line call flow illustrated and described
in section E7.2.2.2 on page 494.
E7.2.3.3 Network Address Translation (NAT) Issues for Customer LAN Gateways
Typically, customer LANs supporting line media gateways use a firewall / NAT (Network
Address Translator) to provide security. To support NAT traversal for signalling traffic,
media gateways and other hosts that are located behind a NAT must:
Dynamic address discovery for signalling is described in detail in section D8.4 on page
322.
Address discovery is also a requirement for bearer connections across the packet
backbone network. This involves the use of a media proxy, as described in section
B5.1.2.2 on page 155.

E7.2.4 V5.2 PSTN Lines

E7.2.4.1 Overview
The V5.2 interface provides a mechanism for multiplexing different types of access
interface on to an integrated group of 2Mb/s PCM30 carriers (from 1 up to a maximum of
16). The signalling for the access interfaces is multiplexed on to one or more 64Kb/s
channels that have been designated as V5 communications channels (C-channels). Lines
and B-channels conveying the voice/data traffic for the access interfaces are mapped 1:1
on to 64Kb/s channels that have been designated as V5 bearer channels. A given V5.2
interface can provide a maximum of 480 bearer channels (16 carriers x 30 user channels).
One communications channel could in theory serve all the voice channels for an entire
V5.2 group.
Note: Although a single PCM30 carrier can be used to provide a V5.2 access interface,
the standards recommend that a minimum of two carriers should be used. This allows a
backup C-channel to be defined on a separate carrier to provide redundancy and thus
maximise the robustness of the interface.
V5.2 can be used to support access to a backbone packet network for subscriber lines
connected to a V5.2 Access Network (AN). V5.2 backhaul supports the transport of V5.2
Layer 3 signalling protocols between a V5.2 AN and an MGC via a managed packet
network. Signalling backhaul means terminating the lower layers of a circuit-based
protocol stack at the signalling gateway (a CS2000-controlled PVG in this case) and
transporting (backhauling) the higher protocol layers to an MGC for processing.
For the CS2000 implementation supported in ISN07, the allocation of responsibilities is
as follows:
! AN functionality is provided by a multiplexer or hub, connected to a PVG by means
of an integrated V5.2 interface comprising up to 16 E1 carriers.
! The PVG provides signalling gateway functionality as well as media gateway
functionality. The V5.2 bearer channels on the TDM-side E1 carriers are mapped
on to bearer connections across the backbone packet network. For V5.2
communication channels (C-channels), Layer 1 and 2 functionality is terminated at
the PVG, and Layer 3 signalling, including call control signalling, is extracted and
routed to the CS2000 using V5UA.
! MGC functionality is provided by CS2000
E7.2.4.2 Standards
The CS2000 implementation of the V5.2 protocol is based on ETSI V5.2 Standard
(Edition 1), as defined in:
CS2000 does not support Edition 2 of the ETSI V5.2 standard.
ETS 300 324 actually defines the V5.1 interface, which allows line interfaces to be
multiplexed on to a single E1 carrier, but sections of ETS 300 324 that also apply to ETS
300 347 are not reproduced in ETS 300 347. Functionally, V5.2 is a superset of V5.1, i.e.
V5.1 capabilities are the same as the capabilities of a V5.2 interface with only one carrier.
However, the ability to support single-carrier V5.2 interfaces should not be interpreted as
formal compliance with the V5.1 specification.


A PVG can support V5.2 access (PSTN/POTS only) for analogue subscriber lines.
As for PRI access to the packet network, a PVG that supports V5.2 access must provide
signalling gateway functionality as well as media gateway functionality, to provide
mapping and conversion between the following:
! TDM-side 64Kb/s channels configured as V5.2 communication channels
(C-channels) conveying V5.2 Layer 3 messages over a LAPV5 Layer 2 datalink.
! Packet network connections supporting a V5.2 / V5UA / SCTP / IP protocol stack.
V5UA (V5.2 User Adaptation) is designed to convey V5.2 Layer 3 messages
between a GWC and a gateway. V5UA provides adaptation between V5.2
signalling and the SCTP layer used to provide reliable transport. See Chapter D11:
V5UA for further information.
The messages conveyed via V5UA can be categorised as follows:
! V5.2 Layer 3 call control messages
DTMF in-band signalling or standard POTS electrical signals. (The V5UA protocol
is capable of conveying Q.931 Layer 3 signalling as well as PSTN signalling, e.g.
for ISDN access, but this is not supported by CS2000 in ISN07.)
The protocol used for the device/media control signalling that complements V5.2
call control signalling between the GWC and gateway is H.248, as described in
Chapter D3: H.248.
Note: Prior to ISN06, ASPEN was was used as the device/media control protocol
for PVGs configured as V5.2 gateways. ASPEN has been superseded for this
purpose by H.248, and existing deployed V5.2 interfaces must be upgraded to use
H.248. See A89007007 and A89007026.
! V5.2 Layer 3 interface control messages
user port control.
primitives, e.g. establishing or releasing a V5.2 C-channel.
primitives, e.g. link status queries and reports.
Note: Unlike the ISDN datalink layer, V5UA supports link status and link
identification messages because the V5 standards require V5.2 system management
to interact directly with V5.2 Layer 1 (including the Layer 1 FSM). Since these
entities may be physically separated in a V5 backhaul scenario, V5UA must provide
mechanisms for communication between them.

The term V5.2 signalling should be taken to include control and maintenance signalling
as well as call control. The term V5-PSTN signalling specifically denotes call control
signalling for PSTN (analogue) lines.
The distinguishing characteristic of a PVG configured to support V5.2 lines is that its
TDM-side E1 carriers are logically grouped into one or more integrated V5.2 interfaces
controlled by a V5.2 GWC, each interface serving a V5.2 Access Network (AN). The
maximum number of E1 carriers per interface is 16. Each V5.2 interface consists of bearer
channels and shared C-channels. The maximum number of line endpoints that can be
supported over a given V5.2 interface is 2048. No more than 6,384 V5.2 lines can be
supported by a given line GWC. The number of line endpoints defined and the number of
bearer channels available at the PVG determine the concentration that takes place
between the V5.2 AN and the gateway.
To avoid duplication, this section does not repeat information provided elsewhere in this
document about CS2000 support for the V5.2 line interface, as follows:
! See section B2.3 on page 99 for information about the architecture and physical
characteristics of a PVG configured to support V5.2 lines, which are the same as for
PVGs used to support CCS7 and/or PRI access.
! See section B2.4.2 on page 112 for information about the capacity and configuration
of a V5.2 AN interface.
! See section B2.4.3 on page 114 for information about V5.2 robustness and
protection switching.
! See section C2.7.2 on page 197 for information about the datafill used to define a
V5.2 AN interface.
! See Chapter D11: V5UA for information about how V5.2 signalling backhaul is
supported using V5UA / SCTP / IP.
Detailed information about some aspects of V5.2 operation is provided in the following
FNs:
! V5.2 flow control procedures implemented at the GWC are documented in
A59038965. These include:
" V5 system overload detection
" V5 system overload handling (by throttling new call attempts)
" GW overload detection
- based on loss of PSTN messages
- via V5UA Error Indication message with Reason=Overload
" GW overload handling (by protection switching of C-channels)
! V5 alarms generated at the GWC are documented in A59038943
! V5.2 audits invoked on the Core or the GWC are documented in A59038943. These
include:
" V5CC Audit, invoked on Core to check for V5 state mismatches between
GWC and Central Control (CC) on Core.
" BCC Audit, invoked on GWC.
" Virtual Layer 1 Audit between GWC and GW, invoked on GWC

E7.2.4.4 V5-PSTN Signalling for Basic Call

Figure 131 illustrates the V5.2 signalling involved in V5.2 PSTN call setup and clearing.
See Figure 82 on page 337 for an illustration of V5.2 call setup on the originating side,
that shows the interaction between V5.2, V5UA and H.248 signalling, and also the dual
MG/SG role of the PVG.
V5-PSTN Layer 3 messaging is conveyed unmodified between V5.2 AN and CS2000;

Layer 2 signalling is LAPV5 between AN and gateway, and V5UA between gateway and CS20000
LAPV5 V5UA V5UA LAPV5
access node CS2000 access node
Caller AN LE AN
goes ESTABLISH
off-hook (SS: off-hook)
EST ACK
Bearer channel connected
Dial tone
ESTABLISH
DTMF (CR: type 0) Ringing
dialling
Ringing tone EST ACK
Called party
SIGNAL
(SS: off-hook) goes off-hook
Active call
Caller
goes SIGNAL
on-hook (SS: on-hook)
DISCONNECT Treatment
SIGNAL Called party

DISCONNECT (SS: on-hook) goes on-hook
COMPLETE
DISCONNECT
DISCONNECT
COMPLETE
Figure 131: V5.2 PSTN call setup and clearing

E7.2.4.5 CS2000 Support for V5.2 Signalling Procedures

This section summarises CS2000 support for specific V5.2 signalling procedures. Support
for some of these procedures required only verification on CS2000 of capabilities
previously supported by the DMS implementation of the V5.2 interface. Some
development was needed for general CS2000 support of V5.2, and recently to support
additional ETSI V5 Edition 1 line signals required by Chinese V5.2 specification YDN
021-1996 (see A59038988 for details).
Variations in Call Setup

! Line Reversal On Answer (LROA)
Line reversal swaps the polarities of the A and B leads of a line. When applied to a
line serving equipment such as a coin telephone, answering machine or fax
machines, a line reversal is used to trigger an appropriate action, e.g. dropping coins
or waking up a fax or answering machine. Use of line reversal during call setup
is controlled by the LROA field in table V5SIG.
CS2000 supports LROA by sending the AN a Signal SS: reversed polarity message
for the originating line when the called party goes off-hook. In response, the AN
applies reversed power feed to the line and the call enters the active phase; this
reversal is applied until the call is disconnected.
Option LROA in table V5SIG controls the availability of LROA for all V5.2 lines
on the CS2K. It can have any of three values:
Y LROA is enabled for all V5.2 lines on the CS2K.
N LROA is not enabled for any V5.2 lines on the CS2K.
CHKLN
LROA availability is controlled on a per-line basis. For a given line, LROA
is enabled if the LROA line option has been provisioned against that line.
See A59012598 for details.
! Line Reversal On Seizure and Forward Disconnect (LROS / FD)
The LROSFD field in table V5SIG is a boolean that controls the availability of two
complementary V5 line options for the CS2000 as a whole:
" Line Reversal on Seizure (LROS)
On calls terminating to a V5 residential line, LROS causes reversal to be
applied on seizure of the line (the AN is sent a Signal SS: reversed polarity
message), followed by ringing. This reversal is maintained until answer, at
which point the line is returned to the normal polarity.
" Forward Disconnect (FD)
On calls terminating to a V5 residential line, FD causes the switch to send a
Forward Disconnect signalling message to the AN if the calling party
disconnects first and leaves the V5 called party still off-hook. The switch then
releases the communication path. See also the discussion of EOC signalling.
! Parked Line Feed (PLF)
Parked line feed functionality is used during unsuccessful call set up, to reduce the
power supply to locked-out lines. Its use is controlled by the PLF field in table
V5SIG.
CS2000 supports PLF for a line that has been put into the Permanent Lock Out
(PLO) state by sending a Signal SS: Reduced Battery message to the AN, requesting
it to reduce the power feed to that line.

! Provisionable ring type

CS2000 allows the ring type associated with a signalling profile to be specified via
the RNGTYPE field of table V5SIG, to ensure that the correct ringing cadence is
applied. Currently supported ring types are C5B, C3C, C3D, C6F, C5I and C6R.
! Flexible distinctive ringing
Distinctive ringing allows a subscriber to distinguish different types of incoming
call on the basis of the ringing cadence applied. V5.2 interfaces allow up to 32
different ringing cadences (ringing types 0-31) to be distinguished. Ringing type 0
denotes national standard ringing. Use of other ringing types depends on the
features to be supported.
The characteristics of the physical ringing associated with each ringing type are
specified by national standards and/or bilateral agreements. For V5.2, ringing
cadences are implemented by ANs.
Table V5RING allows mappings to be defined between ringing cadences as known
to the CS2000 (ring chars 0-15) and cadences as known to the V5.2 interface
(ringing types 0-31). These mappings can then be assigned to one or more V5.2
interfaces using table GPPTRNSL. See 59007882 for details.
Note: Certain ANs are capable of handling only a subset of the ringing types that
can be sent to them.
! Attenuation
Attenuation adjustments are applied on a per-call basis to control echo in
accordance with a national loss-level plan. The application of attenuation for V5.2
interfaces is controlled by the ATTEN field in table V5SIG.
The loss values that should be inserted to control echo are specified in table
PADDATA. CS2000 assumes that a line card can support up to a 7dB loss. The
value in table PADDATA is therefore split into two parts for application. Up to 7dB
is sent to the peripheral to be applied, while the remainder is processed in the
network. For V5.2, additional attenuation is processed in the GWC, and can be
applied either as digital attenuation by the media gateway or as analogue attenuation
at an AN line card, as follows.
" Digital attenuation applied by the media gateway
Per-call digital attenuation should be applied by the media gateway in
respsonse to a H.248 message from the GWC, but this capability is not
supported by the PVG in ISN07. Instead, the ingress gain and egress gain to
be applied can be set for each E1 carrier by means of PMDM provisioning
commands.
" Analogue attenuation applied at an AN line card
The V5.2 requests the application of analogue attenuation by sending the AN
an Attenuation IE specifying the loss to be inserted in the analogue interface
to control echo. The AN must be able to handle the attenuation IE.
The possible values for the ATTEN field in table V5SIG are:
" V5_NONE
No additional attenuation should be applied.
" V5_DIGITAL
Additional attenuation should be applied by the media gateway.
Note: Application of additional attenuation on a per-call basis is not
supported by the PVG in ISN07, so specifying this value for the ATTEN field
currently has no effect.

" V5_ANALOG
Additional attenuation should be applied by the AN line card.
Variations in Call Clearing

! Disconnect by remote party (with calling party control)
" CS2000 sends Signal SS: on-hook message to AN to indicate disconnection.
" If AN sends Signal SS: on-hook message to CS2000 in response, CS2000
initiates bearer channel deallocation and call disconnection.
If AN does not respond before expiry of timer T1, possibilities are:
# Early deallocation
CS2000 applies treatment (e.g. congestion tone). If AN does not
respond before expiry of timer T2, CS2000 initiates bearer channel
deallocation. Call disconnection is initiated when Signal SS: on-hook
message is eventually received from AN.
# Application of Parked Line Feed (PLF)
CS2000 applies treatment (e.g. congestion tone). If AN does not
respond before expiry of timer T2, CS2000 sends Signal SS: reduced
battery message to AN to request reduction of power feed to locked-out
subscriber line from 48V to 24V.
! Re-answer procedure (with calling party control)
When call control by calling party is in effect and CS2000 receives a Signal SS:
on-hook message for the calling party, timer T1 is started. CS2000 will not initiate
call clearing if it receives a Signal SS: off-hook message for the calling party before
expiry of timer T1.
! Called party control
Call control by the called party is typically used by Fire, Police and Emergency
stations. If the caller goes on-hook, the active call is not cleared, no re-answer timer
is started, and the early deallocation procedure does not apply. Only the called party
can clear the call.
! End Of Call (EOC) Signalling and Cut-Off on Disconnect (COD)
EOC/COD signalling means CS2000 sending the AN an indication that the far-end
party in a call has cleared. The indication given may be a treatment and/or a V5.2
signal, and enables the AN to release terminals such as fax or answering machines.
CS2000 implements EOC signalling by sending a Signal PS: pulsed no battery
message to the AN, then applying disconnect treatment, e.g. congestion tone. The
AN responds with a Signal (SS: On Hook) message, which causes CS2000 to initiate
normal disconnect procedures.
EOC signalling for V5.2 PSTN lines is selected globally by means of the GCOD
(GLOBAL_CUTOFF_ON_DISCONNECT) parameter in table OFCENG. When
this parameter is set, all V5.2 interfaces on the switch will provide EOC signalling,
provided that EOC is also datafilled in table V5SIG. If the GCOD parameter is set
but a line also has COD datafilled in table IBNLINES, however, the actions
associated with the COD line option take precedence over the EOC actions
associated with the OFCENG parameter. The COD line option causes CS2000 to
idle the line rather than applying treatment, i.e. it permits reorigination, effectively
disabling EOC signalling.

! Stop ringing on disconnect

If the calling party clears a call attempt while ringing is being applied to the called
partys line, CS2000 notifies the AN of the disconnection by sending a Disconnect
SS: stop ringing message. The AN responds by sending back a Disconnect
Complete message to complete call clearing.
Variations in Service Operation

! Digit-1 as Hook Flash / Register Recall
A hook flash (register recall as it is referred to in the UK and some other markets)
can be used during an active call to initiate feature activation.
In some markets, the duration of the disconnect pulse for a hook flash overlaps with
that of a pulse-dialled Digit-1. The signal is therefore conveyed over the V5.2
interface in a SIGNAL (DS=1) message.
For a given signalling profile, the DS1FLASH field of table V5SIG can be used to
specify whether the SIGNAL (DS=1) message should be ignored when it is received
during an active call (DS1FLASH=N), or processed as a hook flash
(DS1FLASH=Y).
Note: During digit collection, i.e. when the switch is expecting dialled digits, the
SIGNAL (DS=1) message will not be interpreted as a hook flash, regardless of the
setting of theDS1FLASH field.
! Suppression control
Suppression control is used to determine which conditions, if any, will cause pulse
generation to be stopped in a V5.2 access network. The capability is used in support
of CLASS services. It is controlled via the SUPPIND field in table V5SIG, which
defines the conditions for suppression as one of:
LE_SUPP Pulse generation stopped in response to a new message from the
switch, e.g. receipt of a disconnect signal before pulsing is complete.
TE_SUPP Pulse generation stopped in response to a change in the status of the
subscriber line, e.g. subscriber going on-hook before pulsing has
completed.
LE_TE_SUPP Either of the above.
NO_SUPP None of the above (no suppression).
! Pulse duration type
Field PLSDUR of table V5SIG can be used to specify the required duration of the
ring splash to precede CLASS data download over V5.2 lines. The PLSDUR field
can take any value in the range 0 to 31. The default value is 1, meaning 300ms.
Maintenance
! Accelerated Port Alignment (APA)
A given V5.2 interface comprises a number of ports for PSTN bearer channels. The
port states at the CS2000 must align with (match) the port states at the AN.
Accelerated Port Alignment (APA) allows port alignment to be achieved for all the
ports of a V5.2 interface by means of a single unblock-all-ports handshake
sequence, making it unnecessary to send a separate message for each port. APA
requirements and messaging are defined in ETS 300 347-1 A1. The APA feature is
assigned to a V5.2 interface via the boolean APA field in table V5SIG.

E7.3 Line Provisioning

CS2000 lines are supported by line gateways controlled by CS2000 GWCs. CS2000 has
no knowledge of the physical units on which the lines terminate. Depending on the type
of line to be supported, CS2000 perceives lines as belonging either to line groups
(customer LAN and cable lines) or V5.2 interfaces.
CS2000 datafill is used to specify logical frame and unit identifiers that call processing
can interpret as if they defined the physical location of slots housing traditional line cards.
The steps involved are as follows:
! Before lines can be provisioned, it is essential to provision the GWC that is to
control the line group or V5.2 interface. This involves datafilling table SERVRINV,
as described in section C2.4 on page 189, and specifiying POTSEX as the server
exec type.
! The next step is to provision the line group or V5.2 interface. Line group
provisioning is described in section C2.7.1 on page 196, and V5.2 interface
provisioning is described in section C2.7.2 on page 197.
! The final step is to provision individual lines. and their attributes. This part of the
process is described in section C2.7.3 on page 199.
It is also necessary to provide each line access GWC with information about the line
media gateways it is to control, and about the line endpoints supported by those gateways.
For large gateways, this is done via via provisioning applications and the GWC Element
Manager (EM). GWC and Core datafill is co-ordinated as follows:
! When the GWC EM is used to add a new GWC, an entry for that GWC is
automatically added to table SERVRINV in the CS2000 Core.
! When the GWC EM is used to associate a new line gateway with a GWC, table
LGRPINV in the CS2000 Core is automatically updated.
Small CPE gateways are dynamically configured using DHCP and TFTP when they are
brought into service, as a result of which they are provided with the IP address of their
controlling GWC.

IBN line support for services is as described in Chapter F2: Analogue Subscriber Line
Services.
E7.5 Order Codes for Analogue Lines
Table 45: Order codes for analogue lines software

ILIN0100 IBN Line Usage
ACSI0003 V5.2 Lines
CS2Q0001 DQoS Support for Cable

Chapter E8 CentrexIP Lines

! Etherset clients
! Soft clients
a screen-based GUI.
gateways.
Each CICM subtends and is controlled by a CS2000 GWC. The GWC in turn
communicates with the CS2000 Core, which supports call processing for CentrexIP
clients as if they were legacy business sets controlled via the proprietary P-phone
interface.
See section E8.2 on page 509 for information about CentrexIP clients and their
capabilities.
See section E8.3 on page 512 for an illustrated description of the network architecture
used to support packet network access for CentrexIP remote clients.
See Chapter F3: Feature Support for CentrexIP Clients for information about the
features available to users served by CentrexIP lines.

CentrexIP Lines Telephony Interfaces Communication Server Capabilities
E8.2 CentrexIP Clients and their Capabilities

This section describes the characteristics and capabilities of the CentrexIP remote clients
supported by CS2000 in ISN07. It is organised as follows:
! Section E8.2.1 describes the characteristics and capabilities of Etherset clients,
which are IP-enabled Ethernet phones.
! Section E8.2.2 on page 510 describes the characteristics and capabilities of
PC-based soft clients.
! Section E8.2.3 on page 511 describes characteristics and capabilities that are
common to both types of CentrexIP client.
E8.2.1 i200x Etherset Characteristics and Capabilities

An Etherset is an IP-enabled Ethernet phone. It uses a large display and programmable
softkeys to support quick and easy access to capabilities such as multiple directories,
multimedia mailboxes and voice recognition.
Three types of Nortel Networks Etherset are supported in ISN07:
! i2001
! i2002
! i2004
These all support the same basic functions, but the specific capabilities they offer (number
of function keys, size of screen display, menus) increase from the low-cost, entry-level
i2001 to the fully featured i2004. In addition, the range of function keys supported by a
i2002 or i2004 can be further extended by equipping it with a key expansion module.
The CICM controls i200x Ethersets by means of the UniStim protocol defined in NIS
D201-1. This is a Nortel Networks protocol, but is available under licence to other
equipment vendors who wish to design and manufacture CentrexIP terminals that support
interoperability with Nortel Networks products such as CS2000.
The basic functions common to all types of i200x Etherset are as follows:
! Ethernet connectivity
The users desktop Etherset and PC are connected to the network using a single port.
The i200x has a built-in Ethernet 10/100BaseT Layer 2 switch that splits the
network cable into separate feeds, providing an additional RJ-45 port for the PC
connection. The internal Ethernet switch gives fixed, hardware-based priority to the
voice port to ensure that high-quality voice service is always available. (The i2001
does not have an integrated switch.)
! Establishing communication with the CICM
To enable an i200x terminal to provide services for a particular end user, that user
must log in. When a terminal is powered on or reset, it sends an unsolicited UniStim
message to the CICM to open a pinhole in the enterprise NAT/firewall, which
enables the CICM to discover the public NAT/firewall address that it needs to use
to send return packets to the terminal. The login process then determines the DN for
which the i200x is to provide VoIP support, and causes the CICM to configure the
terminals capabilities in accordance with the profile of the logged-in user, e.g. by

Communication Server Capabilities Telephony Interfaces CentrexIP Lines
E8.2.2 Soft Client Characteristics and Capabilities

The purpose of a PC-based CentrexIP soft client is to make advanced telephony features
available to end users at their desktops via the same PC they use for other tasks. Speech
transmission and reception is supported via a headset attached to the PC, while incoming
and outgoing calls are controlled via a screen-based GUI provided by a telephony client
application running on the PC. Use of a USB headset is recommended, to ensure that
voice quality is consistent regardless of the PCs sound card and audio configuration.
Incoming ringing and ring-splash are implemented in two ways simultaneously:
! A pop-up dialogue box
! An audio prompt on the client PC
The capabilities available to the end user are the same as those available to users of the
i200x terminals discussed in section E8.2.1 on page 509, but they are controlled by
pointing and clicking in a dedicated PC window rather than by means of physical keys.
Figure 132 indicates the capabilities provided via a soft client GUI window.
Display, e.g.
for CLI of
incoming call
Feature keys
with
dynamically
Standard assigned
numeric functons
keypad for
point-and-click
dialling
Figure 132: CentrexIP soft client user interface (as displayed in PC window)
The primary purpose of a PC-based soft client is to complement a users desktop phone
by providing point-and-click control over call handling. Typically, however, the speech
path is routed through the users telephone set, as this offers a quality of service superior
to that of a PC.
A further advantage of a PC-based soft client is that it can be used to extend the
capabilities of a business users desktop line to wherever that user may be. For example,
a user can log in to the corporate telephone network from a hotel room using a laptop, or
from a desktop PC at home. In either case, the fact that the soft client is provisioned with
the same telephone number as the desktop phone means that incoming calls will
automatically be redirected to the CentrexIP soft client, and that outgoing calls will be
handled in exactly the same way as if they originated from the desktop phone. The
standard set of non-VoIP capabilities supported by the corporate network is also available,
e.g. email.
The login process establishes an IP connection with the CICM, determines the DN for
which the soft client is to provide VoIP support, and causes the CICM to configure the
clients capabilities in accordance with the profile of the logged-in user, e.g. by

Support for the standard TAPI interface makes it possible for CentrexIP soft clients to be
connected to TAPI-aware applications such as contact databases or customer care
systems, and to use these to make calls.
E8.2.3 Common Characteristics and Capabilities

The following list describes characteristics and capabilities that are common to the i200x
clients described in section E8.2.1 on page 509 and the PC-based soft clients described in
! Control protocol
The protocol used by the CICM to control CentrexIP client operations is UniStim,
as described in Chapter D6: UniStim. This runs over UDP with a reliability layer.
! Dynamic IP addressing with a standard DHCP server
Dynamic endpoint duscovery is supported for CentrexIP clients. The CICM
automatically detects the network association for each terminal that is connected to
it, which allows users to roam across different networks and still obtain service.
When a terminal connects to the CICM from behind a NAT, the source IP address
of packets from the terminal will be the public address of that NAT, which can be
used by the CICM to associate the terminal with the subnetwork to which that NAT
belongs. The GWC can then be notified of the endpoint to subnetwork mapping via
H.248, which enables it to make decisions about media proxy requirements.
! Codec support for media streams:
" G.711 (A-law and/or -law)
" G.729 a/b
! Tone generation
Audible tones to be played back to the user, e.g. dialtone and ring tone, are
generated by i200x terminals themselves.
Each tone available for playback is stored by the i200x terminal as an audio stream.
The stream content comprises up to four frequency pairs and cadences. An i200x
terminal can store up to 16 tone streams, each with its own stream ID.
Tone information is stored at the CICM in the form of administrator-defined tone
profiles, each comprising a complete set of tones. The tone set to be made available
to a given user is determined by the tone profile associated with that user.
When CS2000 determines that a tone needs to be played, H.248 signalling from the
GWC determines the tone ID, the CICM selects the appropriate tone profile, and the
i2000x terminal plays the appropriate audio stream.
! Dynamic feature key assignment
It is the CICM that determines which capabilities are available via i2000x function
keys. As the range of capabilities varies depending on the state of the terminal, the
only features with lamps on are those that can be activated in the current state.
Features are categorised as follows:
" DN features that control active/idle status, e.g. keys for Primary / Secondary
DN or automatic DOD line.
" Features that can be used only when there is an active call, e.g. Call Transfer.
" Features that can be used only when there is not an active call, e.g. Call
Forward.
" Features that are always usable regardless of whether there is an active call.

Communication Server Capabilities Telephony Interfaces CentrexIP Lines
E8.3 Network Configuration for CentrexIP Client

Access
CS2000 provides VoIP support for two types of CentrexIP client (see section E8.2 on
page 509 for a more detailed description):
! Etherset clients
! Soft clients
a screen-based GUI.
gateways, but the CICM is not a media gateway in MEGACO terms because it handles
only signalling traffic, not media streams. It can be regarded as a terminal server, and its
role is similar to that of a GWC controlling multiple small CPE line gateways. CICMs are
connected to the CS2000 CS LAN, and communicate with their CentrexIP clients over the
packet backbone network using the UniStim protocol described in Chapter D6: UniStim.
See section B4.3 on page 149 for a more detailed description of the CICM.
Each CICM subtends and is controlled by a CS2000 GWC, which communicates with the
CICM via the CS LAN by means of the H.248 protocol described in Chapter D3: H.248.
The GWC in turn communicates with the CS2000 Core, which supports call processing
for CentrexIP clients as if they were legacy business sets controlled via the proprietary
P-phone interface.
Table KSETINV specifies the logical line type for each line card slot reserved for a
business set or equivalent. For CentrexIP lines providing business set capabilities, the
logical line type corresponds to one of the four types of Etherset or soft client supported
in ISN07, as follows:
Table KSETLINE specifies the DN for each logical line card slot reserved for a CentrexIP
line, and also lists the features assigned to the line.
Note: Tables KETINV and KSETLINE are not edited directly, but automatically updated
when a CentrexIP line is provisioned via SERVORD+.
As a large line gateway, a CICM can share a GWC with other gateways of the same type,
i.e. another CICM or an MG9000, but not with small CPE line gateways.

Figure 133 illustrates the network configuration used by CS2000 to provide VoIP support
for CentrexIP clients.
CS2000 exercises control over CS2000 CS2000 Core

remote CentrexIP clients using three CS LAN
types of signalling:
Signalling between CS2000 Core
and the GWC that controls the
CICM emulates P-phone
signalling for business sets.
H.248 signalling is used between GWC
the CICM GWC and the CICM. for CICM
UniStim signalling is used
between CICM and remote
CentrexIP clients.
CentrexIP Client
Manager (CICM)
Perceived by
CS2000 as
large gateway
Etherset client (i200x):
IP-enabled Ethernet
phone with display
and function keys H.248 P-Phone
Dual PP8600s
Enterprise network IP core network

UniStim
Bearer connections for additional media

streams , e.g. to/from MCS5200, can be
co-ordinated with VoIP for multimedia
CentrexIP soft client (m6350):
Speech transmission and Bearer connections for
reception via headset. non-VoIP-related data sessions
Call control via CentrexIP client are independent of CS2000
application GUI.
Figure 133: CS2000 support for CentrexIP line access

Part F
Chapter F1 Part F CS2000 International Product Description
Feature Support Overview Features and Services Communication Server Capabilities
Chapter F1 Feature Support Overview
F1.1 Feature Sets Currently Supported

The following list summarises the support provided by CS2000 for feature sets and
service platforms:
! Analogue subscriber line services
(see Chapter F2: Analogue Subscriber Line Services for details)
Analogue subscriber line services are designed to simplify the process of making
calls (e.g. speed calling), to increase the likelihood of successful call completion
(e.g. call waiting, call forward, call transfer), to provide information (e.g. caller
number/name delivery) and to make new types of call possible (e.g. three-way
calls). In ISN07, they can be assigned to four different types of IBN line:
" Lines supported by MG9000 carrier-located line media gateways.
" Lines supported via media gateways attached to cable access networks.
" Lines supported via media gateways attached to customer LANs.
" Lines supported via V5.2 Access Networks (ANs).
! CentrexIP line services
(see Chapter F3: Feature Support for CentrexIP Clients for details)
Remote CentrexIP clients served by CentrexIP lines have access to an extensive
range of features, including most of the analogue subscriber line services described
in Chapter F2. For CentrexIP clients, service operation is enhanced by capabilities
such as the integrated client display, and function keys are available to simplifiy
service activation and control.
! ETSI ISDN services
(see Chapter F4: ISDN Supplementary Services for details)
ISDN supplementary services are ETSI-defined additional capabilities designed as
an increment to basic call. They use extra messages, or extra parameters in standard
basic call messages, to convey information and/or to provide notification of call
processing events to call parties. CS2000 supports them nodally over the ISDN
PRI(T) interface used to support access from digital PBXs to combined media and
signalling gateways under CS2000 control. Networked support for a selected range
of services is provided by ETSI ISUP over inter-CS trunks using SIP-T
encapsulation.

CS2000 International Product Description Part F Chapter F1
Communication Server Capabilities Features and Services Feature Support Overview
! QSIG services
(see Chapter F5: QSIG Services for details)
The QSIG VPN interface supports Generic Functional Transport (GFT)
functionality, which allows QSIG signalling to be conveyed transparently across the
network to support QSIF Feature Transparency for real calls (bearer QFT) and
virtual calls (non-bearer QFT).
In addition, QSIG supports a number of ISDN supplementary services and QSIG
Additional Network Features (ANFs).
! DPNSS services
(see Chapter F6: DPNSS Features for more details)
DPNSS features are PBX features for the use of business subscribers. DPNSS
enables different types of PBX to communicate via a common peer-to-peer
signalling system (DPNSS). A number of PBXs connected in this way can serve as
a single large PBX, offering the same features and services to subscribers regardless
of the type of PBX to which they are connected.
! Feature Transparency
(see Chapter F7: APM Feature Transparency for more details)
The ETSI ISUP V3 APM (Application Transport Mechanism) has been defined by
the ITU-T to serve as a general-purpose service support mechanism for conveying
service-related information across the network. Use of the APM means that ISUP
does not need to understand the information being conveyed, only to relay it
between two access interfaces that do understand it. This is known as feature
transparency.
! Virtual Private Networking (VPN)
(see Chapter F8: VPN for details)
Telephony VPN (Virtual Private Networking) is not strictly speaking a feature set
in its own right, but a mechanism for making existing feature sets more widely
available. Specifically, it denotes the use of hybrid networks that combine the
advantages of private and public networks for the benefit of business customers who
need to comunicate between multiple locations. It includes open implementations
based on ISDN access signalling and SIP-T encapsulation of ETSI ISUP network
signalling, and semi-proprietary implementations involving SIP-T encapsulation of
IBN7 ISUP.
! Voice mail
(see Chapter F9: Voice Mail for details)
Voice mail allows a user to have incoming calls forwarded to a message desk, to be
notified that recorded messages are waiting, and to retrieve and play back those
messages later.
! Conferencing support
(see Chapter F10: Conferencing for details)
CS2000 uses the UAS to support three types of conferencing:
" Three-way call set up on an ad-hoc basis.
" Station-controlled conferencing, i.e. ad-hoc conferences with more more than
three participants.
" Meet-me conferencing, i.e. prearranged dial-in conferences with up to 30
participants.

! Indirect access (network interconnect) services

(see Chapter F11: Indirect Access for details)
Indirect access services enable licensed alternative operators to compete with the
established national network by allowing subscribers with PTT lines to request
access to their networks from the PTT network for the completion of long-distance
calls.
! Intelligent Network (IN) services
(see Chapter F12: IN Services for details)
An Intelligent Network (IN) is not strictly speaking a feature set in its own right, but
a platform for the centralised provision of services. The protocol used for defining
services is the Intelligent Network Application Part (INAP). It can support Number
Translation Services (NTSs) such as Indirect Access, FreePhone and Premium Rate
Services.
! Call party information services
(see Chapter F13: Providing Call Party Information for more details)
Call party information services provide information about one party involved in a
call to another party involved in the call. The most common example is CLI (Calling
Line Identification), which is the provision of the calling partys number to the
called party for display. Such services are described in a separate chapter because
they are not associated with any particular interface, and are supported to some
extent not only by almost every interface supported by CS2000, but also over
interworkings between interfaces.
! Regulatory services
(see Chapter F14: Regulatory Services for details)
Regulatory services are features that are not associated with a particular network
operator or signalling system, but are specified by a regulatory body and must be
supported throughout the public network regulated by that body. Some of them are
CEPT (Conference of European Post and Telecommunications Administrations)
services or have CEPT equivalents; others are specific to a particular country.
! Multimedia services
(see Chapter F15: Multimedia Services for Blended Users for more details)
Multimedia services enable blended users to have screen-based interactive access
to databases and media sources while simultaneously participating in a VoIP phone
call. The interactive access and use of the phone are co-ordinated. In the case of a
call between two blended users, interactive collaboration is possible because both
users are operating in the context of the same multimedia session.
! ADSL
(see Chapter F16: ADSL Data Sessions for more details)
CS2000 supports ADSL (Asymmetrical Digital Subscriber Line) access to the
backbone packet network for data sessions with private intranets and/or the public
internet. ADSL support is provided by large carrier-located line media gateways
(MG9000s)
! Dial-up data access via RAS
(see Chapter F17: RAS (Remote Access Service) for details)
RAS (Remote Access Service) means support for dial-up access to internet and/or
intranet sessions. CS2000 supports it by means of TDM-side CCS7 trunks
terminated on the CVX1800 media gateway.

F1.2 Feature Support in a Packet Network Environment

The separation of signalling and bearer connections in a packet network gives rise to
issues with regard to support for capabilities such as in-band interaction and call
reconfiguration. This section discusses mechanisms that have been devised for addressing
these issues. Figure 134 illustrates the mechanisms supported by CS2000 in ISN07.
Mechanism A:- Remote Bearer Control (RBC)

In-band interaction supported by originating media gateway in response to
requests conveyed via SIP-T
CS2000 CS2000
GWC SIP-T SIP-T signalling SIP-T GWC

for media DPT DPT for media
gateway GWC GWC gateway
Service requests
GWC-MG GWC-MG
signalling signalling
Media stream
Media Media
gateway gateway
Mechanism B:- TDM-side looparound trunks

PVG supporting TDM-side looparound is switched into call via translations when required, allowing
service-related in-band interaction, which is not supported by DPT GWCs, to take place via the looparound
CS2000 CS2000
GWC Egress SIP-T signalling Ingress GWC

for media DPT Trunk
DPT for media
gateway GWC GWC
GWC gateway
Service requests
GWC-MG GWC-MG
signalling signalling
Media stream PVG with

Media Media
gateway TDM-side
gateway
looparounds
Media stream relayed

through PVG via
TDM-side looparound
Figure 134: Mechanisms used to support services in a packet network environment

Note: Figure 134 is a simplified view of the architecture used to support services in a
packet network environment (Session Server, media server and TDM-side CCS7 are not
shown).
F1.2.1 Remote Bearer Control

With the RBC mechanism, call processing or service logic on one CS2000 specifies what
should happen to a bearer channel or media stream controlled by a remote CS2000. The
service request specifying the required media stream manipulation is conveyed between
the CS2000s by means of standard SIP-T signalling. A backward service request from a
terminating CS2000 is received by the egress SIP-T GWC on the originating CS2000 and
passed on to the GWC for the originating media gateway. A simple service request such
as the application of an in-band tone towards the calling party is conveyed to the
originating media gateway by means of device/media control signalling, e.g. via H.248.
The SIP-T protocol used for inter-CS signalling is well suited to relaying RBC service
requests for the backward application of in-band tones (including audible ringing).Use of
the RBC mechanism means that the originating media gateway provides service support
in essentially the same way regardless of whether the call in question terminates locally
or on a remote CS2000. There is no need for the terminating media gateway to be
involved, e.g. by having to provide a tone over a packet-side connection.
The following issues must be considered when determining whether RBC requests for a
given service-related action can be supported by an originating gateway, its GWC and the
device/media control protocol between them:
! No speech clipping, i.e. no loss of speech, as a tone is being removed on answer.
! Availability of required tones at the originating gateway (typically only an issue for
a network of CS2000s hosting media gateways in several countries).
! For a service that potentially involves multiple endpoints, e.g. MADN, ability to
apply a given tone to more than one endpoint, or to determine which endpoint it
sahould be applied to.
! Ability to prioritise or arbitrate between different service requests contending for a
given bearer channel if attempts are made to activate other services at the
originating gateway.
! Support for call reconfiguration, e.g. connecting a new endpoint instead of a
currently connected endpoint. Typically, a gateway will do this by deleting an
existing connection and establishing a new one, but call context information must
somehow be preserved when this is done.
F1.2.2 Support for In-Band Interaction for Calls Involving DPTs

Pending the planned availability in a future release of a DPT Media Server with internal
support for RTP-to-RTP switching and access to RTP media streams, workarounds must
be used in order to enable CS2000 solutions to provide transparent support for service
scenarios in which tone application or digit collection is required for a call over a DPT.
Supported workarounds include the following:
! For many services that require the application of a tone such as audible ringback (or
music on hold), this can be achieved by requesting the application of a treatment for
which the associated tone (or audio sample) is defined as an announcement, in
which case it can be provided by a media server.

! For tones that cannot be reconfigured to be supported via announcements,

translations can be used to switch a trunk media gateway into the call, such that the
bearer path terminates on a TDM-side CCS7 looparound trunk. Capabilities such as
digit collection and tone application and digit application can then be requested by
means of standard signalling between the trunk GWC and the media gateway.
Looparound capabilities can be provided by any PVG type (PP15000 or PP20000
equipped with VSP3 or VSP2, or PP7480 equipped with VSP2). The existence of
such looparounds between TDM-side endpoints is not visible to the controlling
GWC, which perceives both ends as separately addressable endpoints.
Some trunk group options may require a CCS7 looparound to be inserted for every call.
Examples of trunk groups for which such insertion is necessary are trunk groups used to
support indirect access, which require users to provide authentication and authorisation
information. Where such trunk group options are required, they must be specified for the
CCS7 looparound rather than for the DPT. Translations and routing must then be set up
to ensure that calls to the DPT will always terminate on a looparound with the required
capabilities.
For other services, the insertion of a CCS7 looparound into calls to/from a DPT trunk
group may be selective, i.e. in-band interaction may not be required for every call. Such
selective insertion is based on dialled digits. For example, DISA service is triggered by
the dialling of a particular directory number. A call received on a DPT trunk to a DISA
DN can use the DISA DN digits (in translations) to route to the CCS7 looparound trunk,
and that looparound trunk then provides the capabilities required by the DISA service.
Note: Use of TDM-side looparounds to support access to packet network media streams
is an interim solution with some specific drawbacks, e.g. it uses up E1 ports. In a future
release, the DPT Media Server will provide internal support for RTP-to-RTP switching
and access to RTP media streams.
Depending on the service-related action to be performed, it may be possible in some cases
to use the RBC mechanism rather than inserting a TDM looparound. This is preferable
because it optimises hardware usage and reduces packet traffic, but the inherent
limitations of the RBC mechanism mean that it must be thoroughly assessed before being
used for a given service.
To ensure seamless operation of services when a TDM-side looparound has been
switched into a call via translations, care must be taken to ensure that the characteristics
of the looparound, as specified via trunk group and subgroup datafill, are an appropriate
match for those of the DPT from which calls are rerouted to the looparound. For CS2000
international solutions, this implies the following specific requirements:
! IBN7 TDM-side looparounds should be used for calls rerouted from DPTs
supporting IBN7 encapsulated in SIP-T or SIP emulating IBN7.
! Base / generic ETSI ISUP V1 or V2 TDM-side looparounds should be used for calls
rerouted from DPTs supporting base / generic ETSI ISUP encapsulated in SIP-T.
! National-variant CCS7 TDM-side looparounds (e.g. ETSI ISUP variants, BTUP,
FTUP) should be used for calls rerouted from DPTs supporting national-variant
CCS7 encapsulated in SIP-T.
Note: A CS2000 that makes use of CCS7 looparounds requires at least one additional
CCS7 point code to be defined for this purpose (since the OPC and DPC of a CCS7 trunk
must be different).

F1.2.3 Support for DPT Interaction with Different Types of Service

This section consists of a number of tables that indicate whether bearer interaction is
required for calls involving different types of service functionality, and (for each service
for which in-band interaction may be required) provides further information about
whether a workaround is required and available in ISN07.
The tables provided are as follows:
! Table 46: DPT interaction support for system features and capabilities on page
521
! Table 47: DPT interaction support for analogue subscriber line services and
options on page 522
! Table 48: DPT interaction support for ACD base services on page 527
! Table 49: DPT interaction support for ACD agent services on page 528
! Table 50: DPT interaction support for regulatory servicess on page 529
Table 46: DPT interaction support for system features and capabilities
Supported Bearer
over SIP-T DPT bearer interaction Details
Service or capability (including restrictions
/ with interaction workaround
SIP-T available? and comments)
SIP-T trunks cannot apply tones

as part of a local treatment.
Work-around is to create an
ISUP loop-around, route the
treatment to this ISUP
Route to local treatment
No Yes Yes loop-around trunk providing a
(busy, reorder, etc) known digit string, then routing
on the incoming loop-around
directly to a tone (which would
be on a PVG or other TDM trunk
device).
Hold tone must be turned off on
a per-switch basis if SIP-T trunks
CEPT Hold tone No Yes No are present in the switch.
Callp interactions on line
gateway cause issue if APG
cannot be inserted.
Can use translations to forward
Single-stage Indirect Access No Yes Yes call to TDM looparound trunk
via DISA and provide service there
Authcode-based Indirect Access No Yes Yes call to TDM looparound trunk
and provide service there
Indirect Access,
No Yes Yes call to TDM looparound trunk
Account Code Required
Indirect Access, Can use translations to forward
MONA via ambiguous No Yes Yes call to TDM looparound trunk
translations and provide service there

Table 46: DPT interaction support for system features and capabilities
Supported Bearer
Details
over SIP-T DPT bearer interaction
Service or capability / with
(including restrictions
interaction workaround
Must insert TDM looparound

trunk after the SIP-T leg of the
Call re-origination No Yes Yes
call in order to enable
reorigination
Call-Forward Remote Activation
No Yes Yes call to TDM looparound trunk
(CFRA)
(IN) CS-1R INAP Yes Yes No Detection of mid-call events (* or

#) not supported for SIP-T trunks
Table 47: DPT interaction support for analogue subscriber line services and options
Supported Bearer Details
Service or option / with interaction workaround
and comments)
SIP-T available?
3-Way Call (3WC) Yes No n/a
Add On Yes No n/a
Announcement before Routing (ABR) Yes No n/a
Provision treatment as
Anonymous Call Rejection (ACRJ) Yes Yes Yes announcement or backward
release with cause
Authorisation Code Yes No n/a
Automatic Call Back Yes No n/a
Automatic Collect Call (ACC) Yes Yes No
ACC Blocking (ACCB) Yes Yes No
Automatic Line (AUL)) Yes No n/a
Automatic Recall (AR) Yes No n/a
Automatic Recall of Dialable
Yes No n/a
Directory Number (ARDDN)
Basic Call with ODP Yes No n/a
Bridged Night Number (BNN) Yes No n/a
Call Completion to Busy Subscriber
(CCBS) Yes No n/a
Call Forward Busy (CFB) Yes No n/a

Call Forward Call Waiting Calls
Yes No n/a
(CFCW)
Call Forward on Don't Answer (CFD) Yes No n/a
CFD with Variable Timing (CFDVT) Yes No n/a
Call Forward Indication (CFIND) Yes No n/a
Call Forward Intragroup
Yes No n/a
(CFI/CBI/CDI))

Supported Bearer
Details
Service or option / with
Call Forward Remote Activation Must use XLA to route to

No Yes Yes
(CFRA) looparound trunk
Call Forward Unconditional (CFU) Yes No n/a
Call Forward Validation (CFWVAL) Yes No n/a
Call Forward with Announcement
Yes No n/a
(CFWANN)
Configure music on hold
Call Hold (CHD) Yes Yes Yes using announcement,
instead of audible ringback
Call Park (PRK) Yes Yes Yes using announcement,
Call Pickup (CPU) Yes No n/a
Call Restrict Area (CRA) Yes No n/a
Audible ringback is not
Call Transfer (CXR) Yes Yes Yes heard in case of blind call
transfer
Call Waiting (CWT) Yes No n/a
CWR requires special
audible ringback, which
cannot be provided over
Call Waiting Ringback (CWR) No Yes No SIP-T because the SIP-T
spec defines no way of
indicating this
Calling Line Flash (CLF) [for
Yes No n/a
malicious call identification]
Calling Name Delivery (CNAMD) Yes No n/a
Calling Name Delivery Blocking
Yes No n/a
(CNAB)
Calling Number Delivery (CND) Yes No n/a
Calling Number Delivery Blocking
Yes No n/a
(CNDB)
Calling Number Delivery Blocking
Yes No n/a
Override (CNDBO)
Cancel Call Waiting (CCW) Yes No n/a
Carrier Selection Yes No n/a
Call Completion to Busy Subscriber
Yes No n/a
(CCBS)
CEPT Call Forward Features Yes n/a
CEPT Call Forward Remote Access Yes No n/a
CEPT Call Transfer (ICT) Yes No n/a
CEPT Hot Line/Warm Line Yes No n/a

Supported Bearer
Details

CEPT International Call Waiting
Yes Yes Yes using announcement (hold
(ICWT)
tone not supported)
CEPT International Three Way Call
Yes Yes Yes using announcement (hold
including Consultation Hold (I3WC)
tone not supported)
CEPT Memo Box: Yes No n/a
Call FWD to Voice Mail
CEPT International Line Restrictions Yes No n/a
CEPT SUPPRESS
Yes No n/a
(permanent CLI blocking)
CEPT Visual Message Waiting
Yes No n/a
Indicator
CEPT International Wake Up Call
Yes No n/a
(IWUC)
Circular Hunting (CIR) Yes No n/a
Code Restrictions
Yes No n/a
(NCOS based call barring)
Conference Call Chaining (3-Port) Yes No n/a
Delivery of Dialable Number (DDN) Yes No n/a
Denied Incoming Call Forwarding Yes No n/a
Denied Origination (DOR) Yes No n/a
Denied Termination (DTM) Yes Yes Yes announcement or backward
release with cause
Direct Inward Dialing (DID) Yes No n/a
Direct Outward Dialing (DOD) Yes No n/a
Direct System Inward Access (DISA) No Yes n/a
Directed Call Park (DCPK) Yes Yes Yes using announcement,
Directed Call Pickup (DCPU) Yes No n/a
Directory Numer Hunting (DNH) Yes No n/a
Distinctive Ringing (DRING) n/a No n/a
Distinctive Ringing / Call Waiting
Yes No n/a
(DRCW)
Do Not Disturb (DND) Yes Yes Yes announcement or backward
release with cause
Emergency Call Routing Yes No n/a
Enhanced Secondary DN (ESDN) Yes No n/a
Essential Line (ELN) Yes No n/a

Supported Bearer
Details
Group Intercom n/a No n/a

Hong Kong 999 & Malicious Call Hold Yes No n/a
Hong Kong Call Forwarding
Yes No n/a
Prevention
Hong Kong Calling Number Delivery
Yes No n/a
Enhancements
Japan Automatic Recall Yes No n/a
Japan Denied Malicious Call
n/a No n/a
Termination (DMCT)
Japan Dialable Directory Number
Yes No n/a
(DDN)
Japan MALO/MALT (Malicious Call
n/a No n/a
Trace for Origination & Termination)
Japan Time-of-Day Broadcast
Yes No n/a
Service (ACD Groups)
Last Number Redial (LNR) Yes No n/a
Lawful Intercept Interaction with IN Yes No n/a
Line Overflow to DN (LOD) Yes No n/a
Line Overflow to Route (LOR) Yes No n/a
Line Reversal on Answer (LROA) Yes No n/a
Local Number Portability, non-IN Yes No n/a
MADN Multiple Call Arrangement Yes No n/a
MADN Single Call Arrangement Yes No n/a
Make Set Busy (MSB) Yes No n/a
Meet-me Conference (6 pty) Yes No n/a
Meet-me-Conference (30 pty) Yes No n/a
Message Waiting Indicator - Audible
Yes No n/a
(MWT, STD sub-option only)
Message Waiting Indicator - Visual Yes No n/a
Multi Line Hunting (MLH) Yes No n/a
Multicarrier (CARR) Yes No n/a
Use announcement on
Music on Hold Yes No n/a media server as audio
source
Networked CNAM
Yes No n/a
via QFT / Wide Area Centrex
Networked Centrex (customer groups
Yes No n/a
dispersed over multiple CS2000s)
Notification of Payment Ceiling Yes No n/a
Permanent Hold (HLD) Yes No n/a

Supported Bearer
Details
Plug Up (PLP) Yes Yes # Yes announcement or backward
release with cause
Preferential Hunting (PRF) Yes No n/a
Preset Conference Yes No n/a
Priority Class of Service (PCOS),
Yes No n/a
Germany only
Private Numbering Plan (PNP) Yes No n/a
Requested Suspend Service (RSUS) Yes Yes # Yes announcement or backward
release with cause
Ring Again (RAG) Yes No n/a
Secondary DN / Teen Service (SDN) Yes No n/a
Secondary Language (SL) Yes No n/a
Selective Call Acceptance (SCA) Yes Yes # Yes announcement or backward
release with cause
Selective Call Forward (SCF) Yes Yes # Yes announcement or backward
release with cause
Selective Call Rejection (SCRJ) Yes Yes # Yes announcement or backward
release with cause
Simultaneous Ring (SIMRING) Yes No n/a
Speed Calling, User Group List
(SCU) Yes No n/a
Speed Calling, Individual Long List

Yes No n/a
(SCL)
Speed Calling, Individual Short List Yes No n/a
(SCS)
Spontaneous Call Waiting with
Yes No n/a
Identification (SCWID)
Station Controlled Conference Yes No n/a
(30 party)
Station Controlled Conference
Yes No n/a
(6 party)
Sub Community Routing for
Yes No n/a
Emergency Calls
Subscriber Activated Call Barring
Yes No n/a
(SACB)
Suspend/Resume (SUS/RES) Yes No n/a
Universal Call Distribution (UCD) Yes No n/a

Supported Bearer
Details
Voice Band Data

Yes No n/a
(Group 3 Fax and Modem)
Wake-Up Call Request (WUCR) Yes No n/a
Warm Line (WML) Yes No n/a
Table 48: DPT interaction support for ACD base services

Supported Bearer
over SIP-T DPT bearer interaction Details
Service or option (including restrictions
/ with interaction workaround
Abandon Call Clearing n/a No n/a

ACD Call Transfer with time Yes No n/a
Use announcement on media
ACD specific Music on Delay Yes No n/a server as audio source, not
audible ringback
Automatic Not Ready & Overflow Yes No n/a
Call Delay Annc Yes No n/a
Call Forcing Yes No n/a
Call queue slots n/a No n/a
Delay & Force Announcements Yes No n/a
Incoming Call queue Yes Yes Yes server as audio source, not
audible ringback
Night service (recorded
Yes No n/a
announcement and forwarding)
Multiple Queue Status display n/a No n/a
Night Service n/a No n/a
Overflow of enqueued calls to a Yes No n/a
DN
Priority promotion and overflow Yes No n/a
Queue to make set busy Yes No n/a
Ring Threshold Yes No n/a
Second and Third Delay
Yes No n/a announcement or backward
announcements
release with cause
Time Delay & Basic overflow Yes No n/a
Variable wrap up n/a No n/a)

Table 49: DPT interaction support for ACD agent services

Supported Bearer
Details
Service or option / with interaction workaround
ACD Not Ready (Key for EBS

n/a No n/a
and Set Not Ready for analog)
ACD Not Ready non-immediate
n/a No n/a
cut off option
AEMK Answer Emergency Key n/a No n/a
Agent Login No n/a
Agent Queue Yes Yes Yes server as audio source, not
audible ringback
Agent Status lamp & indicators n/a No n/a
Agent Status Lamp (ASL) n/a No n/a
Answer Agent key n/a No n/a
Call Agent key n/a No n/a
Call Park by ACD agent Yes Yes Yes server as audio source, not
audible ringback
Call Source identification n/a No n/a
Call Supervisor key n/a No n/a
Called Name/Number Display n/a No n/a
Camp-on calls to in-calls Yes Yes n/a server as audio source, not
audible ringback
Control of Night Service Key
n/a No n/a
(NGTSRVCE)
Controlled Interflow n/a No n/a
Display Agent Status (DASK) n/a No n/a
Display agents & queue status
n/a No n/a
summary
Display Queue Status (DQS) n/a No n/a
Display Queue Threshold (DQT) n/a No n/a
Emergency key n/a No n/a
Emergency key backup n/a No n/a
Enhanced Agent Login n/a No n/a
Forced Agent Availability Key
n/a No n/a
(FAA)
Forced Night Service n/a No n/a
In-Calls key n/a No n/a
Line of business code key n/a No n/a
NR on SDN n/a No n/a

Table 49: DPT interaction support for ACD agent services

Supported Bearer
Details
Observe agent n/a No n/a

Observe from analogue handset n/a No n/a
Observe Warning Tone n/a No n/a
Observer Agent Restriction n/a No n/a
Secondary DNs n/a No n/a
Supervisor option SUPR n/a No n/a
UCD n/a No n/a
UCD Login Keys n/a No n/a
Walkaway closed key n/a No n/a
Table 50: DPT interaction support for regulatory servicess

Supported Bearer Details
Service description / with interaction workaround
and comments)
SIP-T available?
Carrier Selection Yes No n/a
Emergency Call Routing Yes No n/a
Lawful Intercept Yes No n/a
Local Number Portability, non-IN Yes No n/a
Malicious Call Hold (MCH) Yes No n/a

Chapter F2 Analogue Subscriber Line
Services
F2.1 Introduction
Analogue subscriber line services are designed to simplify the process of making calls
(e.g. speed calling), to increase the likelihood of successful call completion (e.g. call
waiting, call forward, call transfer), to provide information (e.g. caller number/name
delivery) and to make new types of call possible (e.g. three-way calls).
This chapter lists and describes the services that can be assigned to CS2000 analogue
subscriber lines in ISN07.
Note: CS2000 supports four different analogue line implementations in ISN07. In
general, a supported service can be assigned to any of these line types. See section F2.4
on page 552 for information about restrictions that may apply to a particular line type.
F2.1.1 Assigning Services to Lines

A service is associated with a specific line via the SERVORD+ provisioning utility.
Table LNINV (Line Inventory) was originally designed to specify the type of line card
housed in a physical line slot, and to map this on to a DN. For a CS2000-controlled
analogue line, the line card type is the logical line card code GWLPOT (customer LAN
and cable lines) or V5LOOP (V5.2), and the DN and LEN are as specified via SERVORD.
For each line defined in table LNINV, table IBNLINES specifies the logical line type
(IBN), the DN, and other basic attributes of the line. Table IBNLINES also lists the
features assigned to each line by means of the SERVORD ADO (Add Option) command.
The more detailed options associated with each feature are recorded in table IBNFEAT
for each LEN.
See section C2.7 on page 196 for further information about datafilling lines
All IBN lines belong to customer groups, and the scope and operation of a given service
may be affected by the customer group to which a subscriber line belongs, e.g. restrictions
can be placed on the types of external call that can be made or accepted. Table CUSTSTN
is used for service-related datafill at the customer group level. A given CS2000 can
support a maximum of 4,095 customer groups.

Analogue Subscriber Line Services Features and Services Communication Server Capabilities
F2.1.2 Service Packaging

The analogue subscriber line services supported by CS2000 in ISN07 are packaged as
follows:
! Standard line features, available via software order code ILIN0002.
! CLASS (Custom Local Area Signalling Services) line features, available via
software order code ILIN0003.
! Enhanced line features, available via software order code ILIN0004.
! Network line features, available via software order code ILIN0005.
! Voice mail support, available via software order code ILIN0006.
! Automatic Call Distribution (ACD) support, available via software order codes
SACD0002 and SACD0006.
CS2000 also supports regulatory services for analogue subscriber lines. Regulatory
services are features that are not associated with a particular network operator or
signalling system, but are specified by a regulatory body and must be supported
throughout the public network regulated by that body. Some of them are generic (e.g.
emergency calls), while others are specific to a particular country. This chapter has a
section dealing with CS2000 support for regulatory services that are explicitly assigned
to subscriber lines; CS2000 support for regulatory services that are generally available
without explicit assignment is described in Chapter F14: Regulatory Services. The
software order code for regulatory service support is ILIN0009.
Many of the services described in this chapter are referred to as Centrex services.
Historically, Centrex services were defined as switch-based equivalents of PBX services,
and were originally developed for business users. Now, however, they are also available
to residential subscribers. Similarly, CLASS services were originally developed for
residential subscribers but now also available for business users.
From a CS2000 perspective, the distinction between Centrex and CLASS is not
significant, because a service such as Call Forward is equally applicable for business or
residential use. A given CS2000 line can be assigned services of either or both types,
depending on the needs of the subscriber in question. It is, however, important to be
familiar with the terminology, as it is frequently used in detailed service documentation.
CS2000 also supports selected CEPT (Conference of European Post and
Telecommunications Administrations) services for subscribers served by IBN lines.
There is considerable functional overlap between CEPT services and their Centrex or
CLASS equivalents. To avoid confusion, CS2000 requires the CEPT line option to be
specified for any line that is to be assigned CEPT services. This has two specific purposes:
! It prevents CEPT services from being assigned to non-CEPT lines.
! Where there are CEPT and non-CEPT versions of a service that both have the same
name, the CEPT line option ensures that the CEPT version is used. Typically,
service logic is the same, but the CEPT service presents a different interface for end
user administration of the service and has different billing requirements.
See section F2.3 on page 550 for further information about CS2000 support for CEPT
services and the CEPT line option.

Communication Server Capabilities Features and Services Analogue Subscriber Line Services
F2.2 Service Categories and Services Available

This section organises the services available into functional categories. Each section
dealing with a functional service category provides brief descriptions of the services
available. The abbreviation at the start of each service description is the acronym used
within the SERVORD line provisioning utility to assign the corresponding service to a
particular subscriber line.
F2.2.1 Call Barring and Restrictions

DOR Denied Origination
Prevents calls from being originated from a line. An attempt to make a call
from a DOR line will encounter originating suspended service (ORSS)
treatment.
DTM Denied Termination
Prevents calls from terminating on a line. An attempt to make a call to a DTM
line will encounter denied terminating (DNTR) treatment.
DCF Deny Call Forwarding
Prevents any incoming call that has been forwarded from terminating on a
line. Denied terminating (DNTR) treatment is applied.
PLP Plug Up
Blocks incoming calls to a specified DN, such that incoming call attempts are
cleared without any busy tone. Outgoing calls can still be originated.
SUS/RES Suspend / Resume
The SERVORD SUS option causes all service to be denied to a line, i.e. no
calls can be originated from or terminated on the line. When this option is
removed from a suspended line, normal telephony service is resumed.
RSUS Requested Suspension
As for SUS, but initiated at the subscribers request.
NCOS Network Class Of Service Screening
Every CS2000-controlled line belongs to a customer group, and every
customer group is assigned a list of NCOS values. An NCOS is a numeric
code that denotes a combination of call types that are permitted or barred. For
example, a particular NCOS value might indicate that local and national calls
are permitted but that premium rate and international calls are barred.
NCOS values for up to 256 combinations of call types can be associated with
a customer group, and each line belonging to the customer group is assigned
one of those NCOS value. Call originations from a given line can therefore be
screened on the basis of the lines NCOS before the call enters translations, to
determine whether the call type being attempted is permitted or barred.
MSB Make Set Busy
Allows subscriber to make own station appear busy (and thus bar incoming
calls).
DND Do Not Disturb
Allows attendant to make subscribers station appear busy (and thus bar
incoming calls).

SACB Subscriber Activated Call Barring

Allows a subscriber to (de)activate call blocking for certain types of outgoing
call. The call types to be blocked are defined using SERVORD. Thereafter,
the subscriber can (de)activate the blocking by entering the SACB access
code. If blocking is in effect, the subscriber can override it for a particular call
by dialling a PIN before dialling the destination number.
SACB can be separately assigned to each secondary member of a MADN
group, to support blocking schemes that are independent of any scheme in
effect for the primary MADN member (see A00001351).
F2.2.2 Speed Calling Services

AUL Automatic Line
Causes subscriber to be automatically connected to a specified destination
(usually the attendant) on going off-hook, with no dialling.
WML Warm Line
Causes subscriber to be automatically connected to a specified DN without
dialling, by going off-hook and dialling # or waiting for a warm line timeout.
The subscribers telephone can be used to program the warm line DN.
LNR Last Number Redial
Allows a subscriber to redial the last number dialled by entering an access
code instead of the full number .
SCS Speed Calling, Individual Short List
Single-digit speed calling to <10 numbers on short list defined by user.
SCL Speed Calling, Individual Long List
Two-digit speed calling to <70 numbers on long list defined by user.
SCU Speed Calling, User Group List
Two-digit speed calling to <70 numbers on shared long list defined by group
controller.
GIC Group Intercom
Provides Group Intercom capabilities to support abbreviated extension
dialling within customer group.
F2.2.3 Call Forward Services

Call forward services allow calls to a subscriber line to be rerouted to another DN.
Different call forward variants are available depending on the circumstances in which
incoming calls are to be rerouted, as follows:
CFU Call Forward Unconditional
If CFU is in effect, all incoming calls are rerouted immediately.
CFI (CFU Intra-group) supports forwarding only within a customer group.
CFU is programmable, i.e. the subscriber defines the forward-to number.
CFF Call Forward Fixed
Like CFU, but non-programmable, i.e. the subscriber can (de)activate the
service but the forward-to number is defined by administration staff.

CFB Call Forward on Busy

If CFB is in effect, all incoming calls are rerouted immediately if the
subscriber line is found to be busy.
CBI (CFB Intra-group) supports forwarding only within a customer group.
CFD Call Forward on Doesnt Answer
If CFD is in effect, an incoming call will be rerouted if it has not been
answered within a prefined period.
CDI (CFD Intra-group) supports forwarding only within a customer group.
Note: CFD is sometimes referred to as Call Forward on No Answer or Call
Forward on No Reply (CFNA or CFNR).
CFWANN Call Forward with Announcement
Causes a forwarding announcement to be played to the caller before
forwarding actually takes place.
CFWVAL Call Forward Validation
Provides two ways of verifying that forwarded-to DN entered on CFwd
activation is valid. Routing validation checks that call can be routed to DN.
Terminating validation actually calls DN before activation.
CFDVT Call Forward on Doesnt Answer Variable Timing
Allows subscriber to specify the CFD timer value, i.e. how long ringing
should continue before CFD rerouting takes place.
CFCW Call Forward of Call Waiting Calls
If CFD and CW are assigned, CFCW causes incoming CW calls to be
forwarded to the CFD number if they are not answered.
CFRA Call Forward Remote Activation
Allows subscriber to (de)activate Call Forward and enter the forward-to
number by remotely dialling a DISA number and entering a PIN.
CFIND (Call Forward Indication) functionality can be used to provide an indication tone
as a reminder when call forwarding is active and the forwarding subscriber goes off-hook,
as described in A89008956.
CFB and CFD service options determine whether the service can be (de)activated by the
subscriber rather than via datafill or service order, as follows:
! P (programmable) option allows subscriber to (de)activate service and program the
forward-to number.
! F (fixed) allows subscriber only to (de)activate service.
! N (normal) does not allow direct subscriber control over the service.

F2.2.4 Call Handling

CWT Call Waiting
Notifies a busy subscriber of a new incoming call. The subscriber can reject
the new call, or can put the other party on hold and answer the new call. Hook
flashes can subsequently be used to toggle between the other two parties,
making the held party active and putting the active party on hold. If the CWR
(Call Waiting Ringback) option is assigned to the CW subscriber, distinctive
ringback is used to notify the caller that CW has been encountered.
SCWID Spontaneous Call Waiting with Identification
Calling party information for an incoming CW call received appears on the
subscribers CPE display after the first ringing tone, allowing the subscriber
to accept or ignore the waiting call based on the information displayed.
CCW Cancel Call Waiting
Allows user to prevent Call Waiting notification from interrupting calls. The
subscriber can activate CCW before making a call or during an active call.
CCW is often used to ensure that a fax or modem call is not interrupted.
CHD Call Hold
Allows a subscriber to put an active call on hold, to be resumed later. The
subscriber can make other calls while the call is being held.
HLD Permanent Hold
Allows user to put an active call on hold, to be resumed later. The subscriber
cannot make other calls while the call is being held.
CXR Call Transfer
Allows a subscriber to transfer a call by:
- Putting the other party in an active call on hold.
- Calling a second party.
- Using a hook flash to bring the held party into the call when the second
party answers.
- Hanging up and leaving the other two parties connected.
3WC Three-Way Call
As for call transfer, except that the subscriber remains connected to the call
after the third party has been brought in. The Consultation Hold option of
3WC (not to be confused with the Call Hold feature) allows the subscriber to
put a call on hold and talk privately to the third party before setting up a
three-way call. 3WC chaining allows a non-controlling party in a three-way
call to transfer the call or link in someone else, in effect linking two three-way
calls.
SCC6 Station-Controlled Conferencing
Ablity to set up ad-hoc conferences with more more than three participants.
The subscriber first dials a conference code to find out whether there is a
conference bridge available. If so, the subscriber is connected to the bridge
and a special dial tone is played. The subscriber can then add additional
parties to the bridge one at a time, simply by dialling their numbers in
response to the special dial tone.
CPU Call Pickup
When users are defined as belonging to a CPU group, an unanswered
incoming call to any group members DN can be picked up and answered by
any other group member who dials the CPU feature activation code.

DCPU Directed Call Pickup

Incoming call can be answered by any station in call pickup group.
PRK Call Park
Allows a subscriber to park an active call against his/her own DN for
subsequent retrieval. Other calls can continue to be made to/from that DN.
The parked call can be retrieved either from the PRK DN or from another
station (by requesting Call Park Retrieve and dialling the PRK DN).
DPCK Directed Call Park
Allows a subscriber to park a call against another DN for later retrieval.
SIMRING Simultaneous Ringing
SimRing allows a user-defined group of up to five DNs to be alerted
simultaneously when the Pilot DN (PDN) of the group is called.
F2.2.5 Hunt Groups

A hunt group allows an incoming call to be offered to each line in the hunt group in turn,
which increases the likelihood of successful call completion.
DNH Directory Number Hunting
Each line in the hunt group has its own DN. When one of these DNs is rung
and found to be busy, the call is offered in turn to either to every DN after the
rung DN in the group DN sequence (sequential hunting), or to every other DN
in the group DN sequence, regardless of the starting point (circular hunting).
MLH Multi-Line Hunting
Only one pilot DN is defined for all the lines in the group. Hunting for an idle
line is sequential, starting with the first line assigned to the pilot DN and
ending with the last.
PRH Preferential Hunting
A PRH hunt group is a subset of the members of a DNH hunt group. If the
pilot DN of the PRH group is rung and found to be busy, hunting for an lidle
line starts with the lines in the PRH group, and continues with the lines in the
DNH group only if no idle line is found in the PRH group.
If a hunt fails to find an idle line, the incoming call receives busy tone unless Line
Overflow to a Route (LOR) or Line Overflow to a DN (LOD) has been specified as the
overflow treatment for the group.
F2.2.6 Uniform Call Distribution (UCD)

UCD Uniform Call Distribution
Distributes incoming calls evenly between the stations belonging to a UCD
group. Such a UCD group has a primary DN that is typically used as a single
point of contact for a service desk with multiple agent stations. If no agent is
free when a call is received, an announcement is played to the caller and the
call is queued.

F2.2.7 Automatic Call Distribution (ACD)
F2.2.7.1 Introduction
Automatic Call Distribution (ACD) is a set of capabilities for the support of call centres.
It provides organisations with a mechanism for evenly distributing incoming calls to a
given DN between a number of agent positions to be answered. It thus ensures that the
calls are handled efficiently and that the operator workload is distributed fairly.
The call distribution mechanism is based on the use of two queues, one for queueing calls
as they arrive and one for queueing agent positions as they become idle. Calls are retrieved
from the call queue and dealt with in order of their arrival, and the next call to be answered
is presented to the idle agent position that has waited longest in the agent queue. If no calls
are queued when a call comes in, it is presented immediately to the agent position that has
been idle longest.
Figure 135 is a functional illustration of the operation of an ACD group.
CS2000
ACD presents ACD agent
longest-queued call positions
to longest-idle agent
Incoming position to be answered
calls
ACD group supervisor

can listen in on calls to
monitor call handling
Call Agent
Incoming queue queue
calls added
to call queue
when no Agent positions added
agent is free to agent queue when idle
Figure 135: Functional overview of ACD
The operation of a basic ACD group can be enhanced in the following ways:
! Multiple DNs
The call-handling capacity of an ACD group can be increased by allowing it to
handle calls for several DNs rather than just one. Calls for different DNs may be
separated into different call queues or pooled, as required.
Note: An agent position can be assigned a secondary DN for non-ACD calls.
! Multistage queues with prioritisation
Four different priority levels (0 to 3) may be assigned to the calls in a call queue on
the basis of the DN they call and whether the call comes in on a line or a trunk. The
principle is that all the calls with a given priority will be answered before any call
with a lower priority is answered, which allows preferential treatment for selected
customers. The highest priority is 0.

F2.2.7.2 ACD Supergroups

It is possible to define a supergoup that encompasses a number of smaller ACD groups
served by the same CS2000. Each of these groups may have its own DN(s) and its own
call types (based on origin) to answer as a primary function, but can provide overflow
capacity for the other groups in the supergroup.
Two customer-defined parameters for each group determine whether incoming calls to a
given group are queued against that group or immediately overflowed to one of the other
groups:
! The queue threshold, which determines the maximum number of calls that can be
queued.
! The wait threshold, which causes a newly arrived call to be overflowed if the
longest-queued call has already been in the queue for longer than the specified
threshold period.
If both of these parameters are set to zero, each incoming call is routed to the agent who
has been idle longest, regardless of group membership. If no agent is idle, the call is
queued against the group that is likely to answer most quickly. This decision is based on
a comparison of the Resource Index (RI) values for all the groups in the supergroup. These
RI values are regularly calculated by ACD service logic on the basis of the following
factors:
! Number of active agents
! Number of free agents
! Number of calls in call queue
! Maximum size of call queue
! Average waiting time for call to be answered
! Average hold time for answered calls
Note: If a groups call queue is full, no further calls will be routed to it.
Customers can influence the immediate rerouting of incoming calls to an ACD
supergroup in two ways:
! Via the queue and wait thresholds specified for its constituent groups, which affect
each groups RI.
! By specifying Preference Waiting Factors (PWFs) that reflect inter-group routing
preferences. PWFs and RIs are both taken into account by ACD service logic when
it makes routing decisions.
ACD service logic regularly reviews the call queue for each group to check whether there
is any queued priority 0 call that has been waiting for longer than the specified wait
threshold. If so, timed overflow is initiated. The call is moved from the call queue to the
overflow out queue for the group, and ACD service logic creates a logical entry for it in
the overflow in queue of another group that is likely to answer it more quickly, e.g. a
group where new agents have logged on to accept calls since the call was first received.
Note: A time-overflowed call is not physically routed to its new target group until an
agent is available to answer it.

Figure 136 is a functional illustration of an ACD supergroup, showing the use made of
different queues.
ACD Supergroup
CS2000
ACD Group A
Incoming call
to ACD Group A Call Overflow Overflow
queue out queue in queue
Option 1:-
Call queued
against original
target group
1
ACD Group B
Call Overflow Overflow
Option 2:-
queue out queue in queue
Call immediately
overflowed to
alternative group
2 3a
Option 3:- ACD Group C

Call time-overflowed Call Overflow Overflow
to another group
(remains physically queue out queue in queue
queued against
alternative group
until agent free)
3b
Figure 136: Queues used by an ACD supergroup

F2.2.7.3 Specific ACD Features
Queue Management
! Incoming Call Queues
Supports the use of four call queues with priorities 0 to 3 to determine the order in
which calls are answered.
! Agent Queue Management
Management of agent queue to ensure even distribution of incoming calls.
! Overflow of Queued Calls
Allows calls to be routed to an overflow queue after waiting for a specified time.
! Automatic Overflow
Allows customer to specify maximum number of queued calls (queue threshold)
and maximum queueing period (wait threshold) for any call, after which call is
rerouted.
! Call Transfer with Time
Allows a caller transferred from one ACD agent to another to have priority in
second queue determined by total time since first queued.
! Abandoned Call Clearing
Automatic clearing of connection if queued caller abandons call.
! Multiple Directory Numbers
Supports the assignment of up to 63 supplementary DNs to an ACD group to
complement the groups primary DN, as a mechanism for organising incoming
calls. A priority level (range 0-3) can be specified for each DN.
This feature also supports the assignment of one or more Secondary DNs (SDNs) to
an individual ACD agent for non-ACD calls.
! Queue Slot Allocation
Allows operating company to control the allocation of queue slots, recorded
announcements and music selections to ACD groups (and thus to charge for them).
Treatments
! Call Delay Announcement
Allows customer to specify acceptable call-delay period, and to have new incoming
calls hear an appropriate announcement if calls are already having to wait longer.
! Forced Announcement for New / Overflowed Calls
Forces an announcement to be played to each new caller, regardless of the current
queue state.
! Music on Delay
Supports playback of music to queued callers during extended delays.
! 2nd and 3rd Recorded Announcements
Provides control over delays between announcements and what caller hears while
waiting (ringing, silence or music).
! Night Service
Allows customer to specify what happens when all agents are logged out. Typical
night service treatments are rerouting to another number or playback of an
appropriate announcement.

! Night Service Recorded Announcement

Causes an appropriate announcement to be played to a caller before night service
treatment starts.
Call Handling
! Call Forcing
Increases the speed of ACD call handling by presenting queued calls to agents
automatically instead of waiting for an agent request.
! Variable Wrap-Up Time
Allows customer to vary the interval that elapses between call completion and new
call presentation such that different intervals can be used for different agents and
groups.
Agent Features
! Agent Login / Logout
Support for agents logging in at the start of a shift and logging out at its end. A
password can be requested when an agent logs in, and ACD service logic can check
that an agent terminal is associated with the same customer group as the login
identification number provided.
! Agent Not Ready
Allows agent to dial an access code to make set appear busy, thus preventing calls
from being routed to it.
! Called Name / Number Display for ACD Agents
DDN and CNAMD functionality for incoming calls presented to ACD agents.
! Call Park by ACD Agent
Allows an ACD agent to park an active call against his/her own DN for subsequent
retrieval.
Supervisor Features
! Observe Agent from Analogue Set
Allows supervisor to use an anlogue set to perform basic audio monitoring of calls
to to agent positions.

F2.2.8 Voice Mail

Voice mail allows a subscriber to have unanswered incoming calls forwarded to a
message desk, to be notified that recorded messages are waiting, and to retrieve and play
back those messages later. Notification of waiting messages is provided by means of a
stuttered dial tone or lamp on the subscribers telephone. Having been notified, the
subscriber can retrieve and play back the recorded messages later by dialling the message
desk centre. The service is automatically deactivated when the last message has been
retrieved. See Chapter F9: Voice Mail for further information.
Voice mail service is assigned to subscriber lines by means of the following line option:
MWT Message Waiting
The mechanism used to notify the subscriber is referred to as
MWI Message Waiting Indication
MWT sub-options determine the notification method to be used. STD (Stuttered Dial
Tone) causes a stuttered dial tone to be applied to the line when the subscriber goes
off-hook, while CLASS Message Waiting Indication (CMWI) provides notification of
waiting messages by means of a lamp or other indicator on the subscriber's CPE.
For CS2000 lines, notification of MWI (de)activation must be provided from the GWC to
the media gateway serving the subscribers line by means of device/media control
signalling, e.g. NCS (cable access), MGCP (customer LAN access) or H.248 (V5.2 lines).
It is then the responsibility of the media gateway to apply the appropriate notification
method to the subscriber line.
In ISN07, the VMS (Voice Mail System) configuration supported by CS2000 uses
TDM-side ETSI ISUP V2 connectivity to the CS2000. An incoming call that encounters
voice mail is forwarded to the VMS over a TDM-side ETSI ISUP V2 trunk so that the
caller can leave a recorded message. The VMS then uses ETSI TCAP signalling (ETSI
TCAP MWI activation) to notify CS2000 that a message has been left for the voice mail
subscriber. Finally, the CS2000 GWC sends an NCS or MGCP message to request the
media gateway to activate MWI on the subscribers terminal.
In some markets, it may be a regulatory requirement that voice mail systems should
support the LI (Lawful Interception) service described in section F14.2.2 on page 699.
This means that the VMS must allow LI (Lawful Interception) of recorded messages when
either the caller or the VM subscriber is a target for LI call monitoring.

F2.2.9 Party Information Services

F2.2.9.1 Providing Party Information
By delivering the callers number and/or name for display, number and name delivery
features enable the recipient of a call to determine who is calling, decide whether to
answer, and prepare an appropriate response before picking up the handset.
Party information services are based on the use of modem functionality in the line media
gateway to provide digital service-related information (e.g. caller name and number) over
an analogue line, allowing the user to benefit from digital services without having an
ISDN line.
Note: For V5.2 lines, V.23 modem capabilities are provided by MG functionality in the
PVG, in response to H.248 commands sent by the CS2000 GWC, as described in section
D3.6.4 on page 278.
The following specific features are available:
DDN Delivery of Diallable Number delivers the caller's number to the subscriber's
terminal for display. Reverse translations (see section F2.2.9.2) are used to
provide the exact digits that the subscriber would have to dial in order to reach
the caller. DDN supports variable-length DNs with up to 24 digits, and is
therefore appropriate for use across the public network.
CND Like DDN, Calling Number Delivery delivers the callers number to the
subscribers CPE for display. The number delivered is a 10-digit or 7-digit DN
in standard North American format. CND therefore tends to be used with
fixed-length numbering plans, e.g. within virtual private networks.
CNAMD Calling Name Delivery delivers the callers name to the subscribers CPE for
display, provided that both parties are served by the same CS2000, or by
CS2000s linked in either of two ways:
# Via ETSI ISUP V2+
The callers name is conveyed over the network from the originating
switch to that of the CNAMD subscriber using QFT (QSIG Feature
Transparency) and the APM (Application Transport Mechanism). See
A59039741.
# Via IBN7
Proprietary parameters in the IAM are used to convey the callers name
over the network from the originating switch to that of the CNAMD
subscriber.
SCWID Spontaneous Call Waiting Identification presents the subscriber with the
name and DN of the calling party when a new call arrives while the subscriber
is busy. The display appears after the signal (call waiting tone) used to alert
the subscriber that there is an incoming call. See A59040478.
The date and time of the incoming call are also displayed along with the callers number
and/or name.
For information about CS2000 compliance with ETSI CLASS requirements for party
information services, see the CLASS Modem Interface SIM Specification (NIS
S118-1).
Number / name display features enhanced in ISN07.0 to include L in the display to
indicate a long-distance call (see A00002558).

F2.2.9.2 Reverse Translations

Reverse translations can be used in a private network to ensure that the number displayed
on a called partys set for an incoming call is the number that should actually be used if
returning the call. Typically, this means removing any excess prefix digits from the
number provided, to make it conform to the called partys dial plan. For public network
calls, the number provided is a fully qualified public network DN.
Reverse translations are controlled by the following tables at the terminating node:
CUSTNTWKFor each customer group, identifies the reverse translator(s) to be used for
incoming calls to group members. Residential subscribers have a single
translator for the public network. DNREVXLA supports reverse
translations for numbers with up to 24 digits.
DNREGIONLists all the regions known to the switch, and defines each one in terms of
the range of numbers that are considered to belong to it.
DNREVXLAEach DNREVXLA entry defines translation results for calls from CLIs
within a given digit range. Each result specifies a region name, followed
by digit manipulation (e.g. deletion of prefix digits) to be performed if both
caller and called party belong to the same region.
If required, the appropriate international or national long-distance prefix (e.g. 00 or 0
respectively in Europe) can be inserted at the start of the number displayed, as described
in A59022041.
Figure 137 summarises the reverse translation process.
Table DNREVXLA
Reverse translator name
from table CUSTNTWK RXLANAME
Calling number FROMDIGS

TODIGS
Use next
RESULT in list RESULTS:
List of up to 20 Table DNREGION
consisting of:
REGION REGION
DELDIGS
PRFXDIGS FROMDIGS
OPTRFX TODIGS
Yes
Is there another No Calling number
RESULT on list of within a REGION Use DELDIGS,
RESULTS? digit range? PRFXDIGS,
Yes and OPTPRFX
No
to format CLI
Called number into diallable
Calling Number Yes
within same form for
unchanged No region? called party
Figure 137: Overview of reverse translations

F2.2.10 Data Download

Modem functionality in the line media gateway is used to send party information to the
user terminal. ETSI EN 300 659 specifies that this can be done either during or prior to
the application of the ringing cadence to the line, as follows:
! The first long silent interval in the ringing cadence can be used for the data
transmission provided that it is long enough.
! To allow for markets in which the long silent interval of the ringing cadence is not
long enough for data transmission, the media gateway can instead apply a
500ms-800ms ring splash as a terminal alerting signal before sending the data, then
apply the standard ringing cadence when data transmission is complete.
Modem functionality and the application of ringing cadences to analogue subscriber lines
are the responsibility of the line gateway. The responsibility of the CS2000 is limited to
using GWC-gateway signalling to provide the party information to be displayed and
specify the ringing cadence to be applied.
In the case of an MTA line gateway, for example, the CS2000 instructs the MTA line
gateway by sending a single NCS message containing the desired ring signal ("rg" or one
of the distinctive ring signals defined by PacketCable) along with the Caller ID signal
("ci"). It is the responsibility of the MTA line gateway to use configuration information
in the MTA to determine the nature of the terminal alerting signal and how best to deliver
the name and/or number information via the modem burst in the silent interval.
S118-1).
F2.2.10.1 Blocking the Delivery of Party Information

Corresponding to the number and name delivery features described in section F2.2.9.1 on
page 543 are blocking features that can be used by callers to prevent their numbers or
names being displayed.
CNDB If Calling Number Delivery Blocking is in effect when a subscriber makes a
call, the subscriber's number is not provided to the called party's CPE for
display; a "number withheld" indication is displayed instead.
CNAB If Calling Name Blocking is in effect when a subscriber makes a call, the
subscriber's name is not provided to the called party's CPE for display; a
"name withheld" indication is displayed instead.
SUPPRESSPermanent suppression of calling party number information (cannot be
overridden by the subscriber).
Note: The CNDBO (CND Blocking Override) feature can be assigned to privileged
called parties to enable them to display CLI information even if it is restricted.
CS2000 supports blocking in two ways:
! Static control of network access via datafill:
- Via table NETNAMES for all access from a given switch.
- Via table DNGRPS for all access from a given customer group.
- Via table DNATTRS for all access from a given line.
! Dynamic control via feature activation codes
Subscribers can control number delivery and blocking on a per-call basis by means

of CNDB and CNAB feature activation codes. The access codes to be used for this
purpose are typically specified by national regulators, e.g. the feature activation
code used for CNDB and CNAB in the UK is 141. An announcement notifies the
subscriber of successful feature activation.
Static office-wide suppression of party information delivery takes precedence over
per-call activation or deactivation of the name blocking feature.
F2.2.11 Screening Services

Screening features allow subscribers to have certain types of call rejected. One feature of
this type is required in many national markets as a public network feature:
ACRJ Anonymous Call Rejection allows a subscriber to have calls rejected unless
the caller's name and/or number is provided for display. Rejected calls are
routed to an explanatory announcement.
Note: It is possible to create billing records for calls rejected as a result of
ACRJ screening rather than treating them as incomplete calls, the call
duration being the duration of the ACRJ announcement. This ensures that a
carrier network operator that presents such a call to a subscriber served by an
alternative operator does not suffer any loss of revenue as a result. It is a
regulatory requirement in some markets.
As a mechanism for screening specific calling numbers (as opposed to simply checking
for calling number availability), CS2000 support screening lists. Incoming calls to a
subscriber are checked against a screening list to determine whether call completion is
permitted for the caller in question. This mechanism is used to support the following
CS2000 screening services:
SCRJ Selective Call Rejection (the screening list determines whether an incoming
call is accepted or rejected; calls from numbers on the list are rejected).
SCA Selective Call Acceptance (the screening list determines whether an incoming
call is accepted or rejected; calls from numbers on the list are accepted).
SCF Selective Call Forward (the screening list determines whether an incoming
call is accepted or forwarded).
SLE Screening List Editing
Allows the subscriber to edit a screening list by entering information via a
telephone set.
Note: This is not a service in its own right, but a prerequisite for editing the
screening lists associated with SCRJ, SCA and SCF.
The following restrictions apply to CS2000 support for screening lists in ISN07:
! A subscriber to SCRJ, SCA, or SCF may only add numbers (CLIs) to the screening
list that are less than or equal to 10 digits in length.
! A subscriber activating the SCRJ, SCA, or SCF service must have a DN of exactly
10 digits in length.

F2.2.12 Call Completion / Call Return

CCBS Call Completion to Busy Subscriber
CCBS is an ETSI-defined ISDN supplementary service that enables a
subscriber who encounters a busy destination to dial an access code and have
the call automatically completed when the destination becomes free, without
having to make a new call attempt. It can be made available to analogue lines
by means of a FEATXLA translator that specifies a 1-digit or 2-digit number
(e.g. 37) as the access code for the CCBSA (CCBS Activation) option. The
ISDN service can then be activated as if it were an analogue subscriber
service, by dialling *37 when busy tone is heard.
AR Automatic Recall / Call Return
Allows a subscriber to find out the originating DN of the last incoming call
attempt, and to set up a return call if required.
Both the access code used to access the AR feature and the digit used to set
up a return call are defined via translations datafill, which means that CS2000
can support whatever codes are required in a given national market. In the
UK, for example, the feature activation code used is 1471 and the call-return
digit is 3.
Two activation methods are supported:
# Two-stage activation
Simply dialling the access code causes the originating DN of the last
incoming call attempt to be voiced back, together with the date and time
when it was received. The call-return digit can then be dialled to set up
a return call attempt.
Note: The subscriber can delete the last calling number after the AR
announcement has been played, instead of the number remaining stored
until it is overwritten on the next incoming call.
# One-stage activation
If the call-return digit is dialled immediately after the access code, e.g.
14713 in the UK example, the return call attempt is made immediately,
with no announcement being played.
ARDDN Automatic Recall of Diallable Directory Number
This variant of AR uses reverse translations (see section F2.2.9.2 on page 544)
to deliver a diallable DN to the subscriber instead of the received CLI.
RAG Ring Again
Notification provided to caller when busy called party becomes free.
ACB Automatic Call Back
Enables a subscriber to place a call to the DN that he/she last called, regardless
of whether the DN called was busy or idle and whether the call was answered
or unanswered. If the subscriber completes the ACB activation procedure and
the terminating line is idle, call setup is attempted. If the call cannot be
completed immediately because the line is busy, the call is queued and call
completion is attempted when TCAP monitoring indicates that both stations
are idle.

F2.2.13 Regulatory Services

CLF Calling Line Flash (MCID)
Allows a subscriber to have the connection for an incoming malicious call
held at the CS2000 so that it can be traced. The subcriber activates CLF by
means of a hook flash (hook flash with feature activation code on a line with
more than one hook-flash feature assigned). CLF functionality is similar to
the ISDN supplementary service MCID (Malicious Call Identification).
ELN Essential Line
Allows a line to originate non-local calls when its serving CS2000 has
network protection (NETPROT) active, i.e. when a CS2000 has been set into
catastrophe state by a craftsperson because of a network problem. When
NETPROT is active, non-ELN subscribers can make only local calls.
PCA Payment Ceiling Advice
German regulatory feature that causes an announcement to be played to the
subscriber after dialling if the charges already incurred in the current billing
period are 80% or more of an agreed payment ceiling. A different
announcement is played if the payment ceiling has already been reached, or if
it is reached in the course of a call. Service logic uses information provided
by the NAOC (Network Advice Of Charge) feature. See section F14.3.1 on
page 703 for a more detailed description.
CS Carrier Selection
Allows a subscriber to choose a default preferred carrier to be used for all
outgoing calls, or a different preferred carrier for each type of outgoing call.
An alternative carrier can be selected for a particular call by means of an
explicitly dialled Carrier Identification Code (CIC).
ACC Automatic Collect Call)
Feature specific to the Brazilian market. An Automatic Collect Call (ACC) is
a PSTN call paid for by the called party rather than the caller. To make an
ACC call, the caller first dials the ACC access code and then the PSTN
destination number; operator assistance is not required. When the called party
answers, an announcement is played to indicate that the call is an ACC call.
The called party accepts the call by remaining off-hook for a certain period
(e.g. nine seconds) after answering, whereupon the caller is
through-connected and the switch creates a billing record for the call.
ACCB Automatic Collect Call Blocking
Prevents ACC calls being made to a subscriber line.
These regulatory services can be assigned as line features. See Chapter F14: Regulatory
Services for information about CS2000 support for other regulatory services such as LI
(Lawful Interception) and LNP (Local Number Portability).

F2.2.14 Miscellaneous Services

SDN Secondary Directory Number / Teen Service
Allows up to three secondary DNs to be assigned to a line, such that callers
can use either the existing DN or an SDN to reach that line. To allow the
subscriber to distinguish between calls to these different DNs, calls to an
SDN cause a distinctive ringing cadence to be applied to the line.
ESDN Enhanced Secondary Directory Number / Teen Service
Enhances the SDN service as follows:
# Up to six SDNs can be assigned.
# Each SDN can have its own set of options.
# Calls can be originated from an SDN and billed separately.
WUCR Wake-Up Call Request
Used to have an automated wake-up call made to a subscriber line at a
specified time. The time at which the call is to be made is programmed via the
subscribers telephone.
Causes announcements to be provided to the subscriber in the CS2000s
secondary language rather than its primary language. The primary and
secondary languages for a given CS2000 are defined at the the office
parameter level.
ABR Announcement Before Routing
Causes a specified announcement to be played on a subscriber line each time
a call is made. Announcement is played before call is routed.
COD Cut-Off On Disconnect
Causes an indication to be provided over a subscriber line when the far-end
party in a call has cleared. The indication given may be a treatment such as a
tone, which enables the release of terminal equipment such as a fax or
answering machines.

F2.3 CEPT Services and the CEPT Line Option

CEPT services are designed for use with analogue subscriber lines served by public
telephone networks. They are so called because they are defined in the Handbook on
Services produced by the Conference of European Post and Telecommunications
Administrations (now superseded by ETSI).
The definition of a given CEPT service specifies not only service functionality, but also
the dialling sequences to be used for (de)activating the service and querying its status.
There is considerable functional overlap between CEPT services and the services defined
in section F2.2 on page 532. Some services offer equivalent functionality under slightly
different service names, while in other cases the same name is used to denote and invoke
service implementations with slightly different functionality.
Services that can be assigned to CEPT lines, i.e. IBN lines with the CEPT line option, can
be categorised as follows:
! CEPT services denoted by a CEPT-specific name
! CEPT services for which there is an equivalent IBN service with the same name
! IBN services for which there is no CEPT equivalent
See Table 51 on page 552 for a complete list of supported analogue subscriber line
services that indicates for each service whether it can be assigned to a CEPT line.
To avoid duplication, this chapter does not provide functional overviews for CEPT
services. For information about the operation of a given CEPT service, please refer to the
description provided for its IBN equivalent in sections F2.2.1 to F2.2.14.
F2.3.1 CEPT Services Denoted by a CEPT-Specific Name

These services are typically assigned to lines by specifying the CEPT service name in
table IBNLINES, as for an IBN service.
CEPT service IBN equivalent

Functionality provided by Code Restrictions
ILR (International Line Restriction) (NCOS screening) and Subscriber-Activated
Call Barring (SACB).
ICWT (International Call Waiting) CWT
I3WC (International Three Way Call, including 3WC
Consultation Hold)
ICT (International Call Transfer) CXR
IWUC (International Wake-Up Call WUCR
CDTA (Call Diversion To Announcement) CFWANN
The CEPT Call Back (CCB) service is implemented on CS2000 via AR.
There is also a CEPT service with the name Memo Box. This is simply voice mail, and is
implemented on CS2000 by combining the MWT service with an appropriate Call
Forward variant.

F2.3.2 CEPT Services with the Same Name as an IBN Equivalent

These services are assigned to lines by specifying the name of the equivalent IBN service
in table IBNLINES (together with additional options in some cases); CEPT-specific
functionality such as service interrogation capabilities is triggered via the CEPT line
option.
CEPT service IBN equivalent (as specified in IBNLINES)

CFU (Call Forward Universal Programmable) CFU
CFF (Call Forward Fixed) CFF
CFBP (Call Forward Busy Programmable) CFB with P (programmable) option
CFBF (Call Forward Busy Fixed) CFB with F (fixed) option
CFDP (Call Forward Dont Answer
CFD with P (programmable) option
Programmable)
CFDF (Call Forward Dont Answer Fixed) CFD with F (fixed) option
SUPPRESS (permanent suppression of party SUPPRESS
information)
CFRA (Call Forward Remote Activation) CFRA
CND (Calling Number Delivery CND
CNDB (Calling Number Delivery Blocking) CNDB
CNDBO (Calling Number Delivery Blocking
CNDBO
Override)
SCWID (Spontaneous Call Waiting with
SCWID
Identification)
ACRJ (Anonymous Call Rejection) ACRJ
[1]
CCBS (Call Completion to Busy Subscriber) [1] (N)RAG
[1] CCBS is an ETSI-defined ISDN supplementary service that provides functionality equivalent to
the Centrex RAG feature. RAG datafill is now merged/co-ordinated with datafill used for CCBS.
F2.3.3 IBN Services with No CEPT Equivalent

Because CEPT lines are IBN lines, it is possible to assign non-CEPT IBN services to them
as well as CEPT services, provided that service operation is not affected by the
assignment of the CEPT option to the line. This is assessed on a per-service basis.
A list of IBN services that cannot be assigned to CEPT lines is specified via the CEPT
option in table OPTOPT. Checks are then applied during CEPT line provisioning to
prevent such assignment.

F2.4 Service Availability with Different Line Types

In ISN07, CS2000 supports four different analogue subscriber line implementations:
! Lines supported by MG9000 carrier-located line media gateways.
! Lines supported via cable access networks.
Note: For cable lines served by MTA gateways, testing of supported services was
done under activities A59033132 and A59035140. The feature documentation for
these activities provides an extensive list of references for more detailed
information about particular services.
! Lines supported via media gateways attached to customer LANs. ISN07 supports
Ambit, Askey and Mediatrix customer LAN gateways.
! Lines supported via V5.2 Access Networks (ANs).
protocols used by CS2000 to support line access, as described in Chapter E7: IBN Lines.
For each service described in this chapter, Table 51 indicates its availability for each of
these line types as one of:
Yes Can be assigned to lines of this type either as a feature, requiring datafill in table
IBNFEAT as well as LNINV, or as an option, requiring datafill only in table
LNINV.
No Definitely not supported with this line type.
Note: If a table cell is left empty, it means that a given service has not been explicitly
tested with the line type in question, or that testing has not been documented. The service
may in practice work with that line type, but this is not formally supported.
Table 51: Service availability for different types of analogue line

Availability with line type
Service MG9K MTA / cable CPE LAN V5.2 PSTN
IBN CEPT IBN CEPT IBN CEPT IBN CEPT
Call Barring and Restrictions
DOR (Denied Origination) Yes Yes Yes Yes Yes Yes Yes Yes
DTM (Denied Termination) Yes Yes Yes Yes Yes Yes Yes Yes
DCF (Deny Call Forwarding) Yes Yes Yes
PLP (Plug Up) Yes No Yes Yes No Yes No
SUS/RES (Suspend / Resume) Yes Yes Yes Yes
RSUS (Requested Suspension) Yes No Yes No Yes No No
NCOS (Network Class Of Service Screening)
Yes Yes Yes Yes Yes Yes Yes Yes
aka Code Restrictions
Yes Yes Yes Yes
MSB (Make Set Busy) Yes [1] Yes [1] Yes [1] Yes [1]
DND (Do Not Disturb) Yes No Yes Yes

[2] [2] [2]
SACB (Subscriber Activated Call Barring) Yes No Yes No Yes No Yes No [2]


Speed Calling Services
AUL (Automatic Line) Yes Yes Yes Yes Yes Yes Yes Yes
WML (Warm Line) Yes Yes Yes Yes Yes Yes Yes Yes
LNR (Last Number Redial) Yes Yes Yes Yes Yes Yes Yes Yes
SCS (Speed Calling, Individual Short List) Yes Yes Yes Yes Yes Yes Yes Yes
SCL (Speed Calling, Individual Long List) Yes Yes Yes Yes Yes Yes Yes Yes
SCU (Speed Calling, User Group List) No No Yes No Yes No Yes No
GIC (Group Intercom) No No [3] No [3] Yes No [3] No No [3]
Call Forward Services
CFU (Call Forward Unconditional), inc. CFI Yes Yes Yes Yes Yes Yes Yes Yes
CFF (Call Forward Fixed) Yes Yes Yes Yes Yes Yes Yes Yes
CFB (Call Forward on Busy), inc. CBI Yes Yes Yes Yes Yes Yes Yes Yes
CFD (Call Forward on Doesnt Answer),
aka CFNA / CFNR, inc. CDI
Yes Yes
CFWANN (Call Forward with Announcement) No No [4] No No No [4] No
CFWVAL (Call Forward with Validation) Yes No Yes No Yes No Yes No
CFDVT (CFD Variable Timing) Yes Yes Yes Yes Yes Yes Yes Yes
CFCW (Call Forward of Call Waiting Calls) Yes No [5] Yes No [5] Yes No [5] Yes No [5]
CFRA (Call Forward Remote Activation) [6] Yes Yes Yes Yes Yes Yes Yes Yes
Call Handling
CWT (Call Waiting) Yes No [7] Yes No [7] Yes No [7] Yes No [7]
SCWID (Spontaneous Call Waiting with
Identification)
CCW (Cancel Call Waiting) Yes Yes Yes Yes Yes Yes Yes Yes
CHD (Call Hold) Yes No [3] Yes No [3] Yes No [3] No No [3]
HLD (Permanent Hold) Yes No [3] Yes No [3] Yes No [3] No No [3]
CXR (Call Transfer) Yes No [8] Yes No [8] Yes No [8] Yes No [8]
3WC (Three-Way Call) Yes No [9] Yes No [9] Yes No [9] Yes No [9]
CNF (Station-Controlled Conference, 3 ports) Yes Yes
SCC6 (Station-Controlled Conference, 6 ports) Yes No No Yes No No No
CPU (Call Pick Up) Yes Yes Yes Yes Yes Yes Yes Yes
DCPU (Directed Call Pick Up) Yes Yes Yes Yes Yes Yes
PRK (Call Park) Yes No [3] Yes No [3] No No [3]
DPCK (Directed Call Park) Yes No [3] Yes No [3] No No [3]
SIMRING (Simultaneous Ringing) Yes No Yes No No No
Hunt Groups
DNH (Directory Number Hunting) Yes Yes Yes Yes Yes Yes Yes Yes
CIR (Circular Hunting within DNH group) Yes Yes Yes Yes Yes Yes Yes Yes
PRH (Preferential Hunting within DNH group) Yes Yes Yes Yes Yes Yes Yes Yes
DLH (Directory Line Hunting) Yes Yes Yes Yes Yes Yes Yes Yes
MLH (Multi-Line Hunting) Yes Yes Yes Yes Yes Yes Yes Yes


LOD (Line Overflow to DN for hunt group) Yes Yes Yes Yes Yes Yes Yes Yes
LOR (Line Overflow to Route for hunt group) Yes Yes Yes Yes Yes Yes Yes Yes
BNN (Bridged Night Number for DLH group) Yes Yes Yes Yes Yes Yes Yes Yes
Multiple Appearance Directory Number
MADN SCA (Single Call Arrangement) Yes No Yes No No No
MADN SCA (Single Call Arrangement) Yes No Yes No No No
Call Distribution
UCD (Uniform Call Distribution) No No [3] Yes No [3] No No [3] No No [3]
ACD (Automatic Call Distribution) Yes No [3] No [3] Yes No [3] No [3]
Voice Mail
MWT (Message Waiting) with Stuttered Dial Yes Yes Yes Yes Yes Yes Yes Yes
Tone (SDT)
MWT (Message Waiting) with CLASS Message
Yes No Yes Yes Yes No Yes No
Waiting Indication (CMWI)
Party Information Services
DDN (Delivery of Diallable Number) Yes Yes Yes Yes Yes Yes Yes Yes
CND (Calling Number Delivery) Yes Yes Yes Yes Yes Yes Yes Yes
CNAMD (Calling Name Delivery) Yes Yes Yes Yes Yes Yes Yes Yes
CNDB (Calling Number Delivery Blocking) Yes Yes Yes Yes Yes Yes Yes Yes
CNAB (Calling Name Blocking) Yes Yes Yes Yes Yes Yes Yes Yes
SUPPRESS (permanent suppression of party Yes Yes Yes Yes Yes Yes Yes Yes
information)
CNDBO (Calling Number Delivery Blocking
Override)
Screening Services
ACRJ (Anonymous Call Rejection) Yes Yes Yes Yes Yes Yes Yes Yes
SCRJ (Selective Call Rejection) Yes Yes Yes Yes Yes Yes Yes Yes
SCA (Selective Call Acceptance) Yes No Yes No Yes No Yes No
SCF (Selective Call Forward) Yes Yes Yes Yes Yes Yes Yes Yes
SLE (Screening List Editing) [10] Yes Yes Yes No No
Call Completion / Call Return
CCBS (Call Completion to Busy Subscriber) Yes Yes Yes Yes Yes Yes Yes Yes
Yes Yes Yes Yes
CLASS AR (Automatic Recall / Call Return) Yes [11] Yes [11] Yes [11] Yes [11]
CLASS ARDDN (Automatic Recall of Diallable

Directory Number)
No No No No
RAG (Ring Again) Yes [12] [12] Yes [12] Yes [12]
CLASS ACB (Automatic Call Back) Yes Yes Yes Yes Yes Yes Yes
Regulatory Services
CLF (Calling Line Flash for MCID) Yes Yes Yes Yes Yes Yes Yes Yes
ELN (Essential Line) Yes Yes No
PCA (Payment Ceiling Advice) Yes Yes Yes


CS (Carrier Selection) Yes Yes
ACC (Automatic Collect Call) Yes Yes
ACCB (Automatic Collect Call Blocking) Yes Yes
Miscellaneous Services
SDN (Secondary Directory Number),
aka Teen Service Yes No Yes Yes Yes No Yes No
ESDN (Enhanced SDN) Yes No Yes No No
WUCR (Wake-Up Call Request) Yes No Yes Yes Yes No Yes No
SL (Secondary Language) Yes Yes Yes Yes Yes Yes Yes Yes
ABR (Announcement Before Routing) Yes Yes Yes Yes
COD (Cut-Off On Disconnect) Yes No Yes No Yes No Yes No
CEPT services
ILR International Line Restriction) No Yes No Yes No Yes No Yes
ICWT (International Call Waiting) No Yes No Yes No Yes No Yes
I3WC (International Three Way Call, including
Consultation Hold) No Yes No Yes No Yes No Yes
ICT (International Call Transfer) No Yes No Yes No Yes No Yes
IWUC (International Wake-Up Call No Yes No Yes No Yes
CDTA (Call Diversion To Announcement) No Yes No Yes No Yes
[1] Used instead of CDND (CEPT Do Not Disturb), which is not supported.
[2] ILR (International Line Restrictions) is used instead for CEPT lines.
[3] Deliberately not supported for CEPT lines.
[4] Supported only for intra-CS2000 calls. Only one CFWANN announcement can be provisioned per CS2000.
[5] No need for separate service, as CFCW functionality is built in to CEPT Call Forward services.
[6] IBN and CEPT versions of service cannot both be in use on a given CS2000, as only one set of CFRA
announcements can be provisioned.
[7] ICWT (international Call Waiting) is used instead for CEPT lines.
[8] ICT (International Call Transfer) is used instead for CEPT lines.
[9] I3WC (International Three Way Call) is used instead for CEPT lines.
[10]Supported only for 10-digit calling numbers.
[11]AR is used to provide capabilities equivalent to the CEPT Call Back (CCB) service.
[12]CCBS (Call Completion to Busy Subscriber) is used instead for CEPT lines.

F2.5 Service Support on Interworking

The analogue subscriber line services described in this chapter can be assigned to IBN
lines of the types described in Chapter E7: IBN Lines. The services operate correctly
when interworking occurs between IBN lines and:
! Other IBN lines
! ETSI ISUP (TDM-side and SIP-T), as described in Chapter E2: CCS7 Interfaces.
! ETSI PRI, as described in Chapter E4: PRI Access Interface.
F2.6 Order Codes for Analogue Line Services
Table 52: Order codes for analogue line services software

ILIN0002 Standard Line Features
ILIN0003 CLASS Line Features
ILIN0004 Enhanced Line Features
ILIN0005 Network Line Features
ILIN0006 Voice Mail Support
ILIN0009 Regulatory Line Features
SACD0002 ACD Base Features
SACD0006 ACD Agent Features


Chapter F3 Feature Support for
CentrexIP Clients
F3.1 Feature Categories Supported

This chapter provides information about the features available to users with remote
CentrexIP clients served by CentrexIP lines as described in Chapter E8: CentrexIP
Lines. The following types of feature are supported for CentrexIP lines:
! Basic end user features
End user features are designed to simplify the process of making calls (e.g. speed
calling, direct dialling), to increase the likelihood of successful call completion (e.g.
call waiting, call forward, call transfer), and to make new types of call possible (e.g.
three-way calls).
! Business set user features
Many business set user features are functional equivalents of the features available
to end users with DTMF sets, but can be directly activated via function keys. Other
business set features make use of capabilities such as integrated displays.
! Custom Local Area Subscriber Services (CLASS) features
CLASS features are designed to complement Centrex features, in particular by
supporting the delivery and display of calling or called party information.
! System features
System features reflect the capabilities of the switch rather than those of individual
terminals, and are implicitly available rather than being explicitly assigned to lines.
! Automatic Call Distribution (ACD) features
ACD evenly distributes incoming calls to a given DN between a number of agent
positions to be answered. It thus ensures that the calls are handled efficiently and
that the operator workload is distributed fairly.
Section F3.2 on page 559 discusses feature assignment and activation for CentrexIP lines.
Section F3.3 on page 560 provides a single aphabetically ordered list of the features and
options available to CentrexIP users. Brief functional descriptions of most of these
features are provided in Chapter F2: Analogue Subscriber Line Services; to avoid
duplication, the descriptions are not repeated in this chapter.

Feature Support for CentrexIP Clients Features and Services Communication Server Capabilities
F3.2 Feature Assignment and Activation for CentrexIP

Clients
F3.2.1 Feature Assignment
CS2000 perceives and manages lines serving CentrexIP clients as if they were lines
serving legacy business sets equipped with displays and function keys.
For each line card slot reserved for a business set or equivalent, table KSETINV specifies
the logical line type. For CentrexIP lines providing business set capabilities, the logical
line type corresponds to one of the four types of Etherset or soft client supported in ISN07,
as follows:
Table KSETLINE specifies the DN for each logical line card slot reserved for a CentrexIP
line. It also lists the features assigned to the line, i.e. table KSETLINE is the mechanism
for explicitly associating an end user feature with a specific line.
For features that require additional information, e.g. a forward-to number for Call
Forward, this aditional information is provided in table KSETFEAT.
All CS2000 lines belong to customer groups, and the scope and operation of a given
service may be affected by the customer group to which a subscriber line belongs, e.g.
restrictions can be placed on the types of external call that can be made or accepted. Table
CUSTSTN is used for service-related datafill at the customer group level. A given
CS2000 can support a maximum of 4,095 customer groups.
Note: Additions and changes to switch datafill are made via the SERVORD+ interface,
not by directly editing tables.
System features reflect the capabilities of the switch rather than those of individual
terminals, and are implicitly available to lines without having to be explicitly assigned.
F3.2.2 Feature Activation

With a standard DTMF telephone set, the user makes feature-related requests via switch
hook flash and/or the dialling of feature access codes, and receives instructions and
information via audible tones and announcements.
With a CentrexIP client that provides business set capabilities, feature-related requests
can be made either by dialling or via programmable function keys, and information and
instructions can be provided via lamps and/or a display instead of announcements.
Business set features can be divided into two categories:
! Equivalents of the station features available to end users with DTMF sets.
Typically, these equivalents simply provide the additional capabilities required to
access and use the features from a business set (e.g. additional switch datafill for
assigning programmable function keys).
! New features that make use of the more flexible user/switch interaction capabilities
available to end users with business sets, e.g. integrated displays.

Communication Server Capabilities Features and Services Feature Support for CentrexIP Clients
F3.3 Features and Options Supported
Table 53: Features available to CentrexIP lines

Acronym Feature or option name
3WC Three-Way Calling
ACCB Automatic Collect Call Barring
ACD Automatic Call Distribution
ACD - AAK Answer Agent Key
ACD - ACDNR Automatic Call Distribution Not Ready
ACD - AEMK Answer Emergency Key
ACD - ASL Agent Status Lamp
ACD - CAG Call Agent
ACD - CIF Controlled Interflow
ACD - CLSUP Call Supervisor
ACD - DASK Display Agent Status
ACD - DQS Display Queue Status
ACD - DQT Display Queue Threshold
ACD - ECM / ICM Extended Call Management
ACD - EMK Emergency Key
ACD - FAA Forced Agent Availability
ACD - LOB Line of Business
ACD - NGTSRVCE Night Service
ACD - OBS Observe Agent
ACD - SUPR Supervisor
ACRJ Anonymous Caller Rejection
AMATEST Automatic Message Accounting Test Call Capability
AMSGDENY Access to Messaging Deny
AR Automatic Recall
ARDDN Automatic Recall Dialable Directory Number
ARLNA Automatic Recall Last Number Announcement
ATC Automatic Time and Charges
AUD Automatic Dial
AUL Automatic Line
AUTODISP Automatic Display
AVT AUTOVON Termination
BLF Busy Lamp Field for Meridian Business Sets
BNN Bridged Night Number
CBE Call Forwarding Busy Internal Calls Only
CBI Call Busy Intragroup or Channel Bus Interface
CBU Call Forwarding Busy Unrestricted
CCBS Call Completion Busy Subscriber
CCW Cancel Call Waiting
CDC Customer Data Change
CDE Exclude External Calls from Call Forwarding
CDI Exclude Intragroup Calls from Call Forwarding
CDU Call Forwarding Do Not Answer Unrestricted
CFB Call Forwarding Busy


CFCW Call Forward Call Waiting Calls
CFD Call Forwarding Do Not Answer (Business Sets)
CFDVT Call Forwarding Do Not Answer Variable Timer
CFF Call Forwarding Fixed
CFGD Call Forwarding Do Not Answer for Hunt Group
CFI Call Forwarding Intragroup
CFK Call Forwarding on a Per Key Basis
CFMDN Call Forwarding MADN Secondary Member
CFRA Call Forwarding Remote Access
CFS Call Forwarding Simultaneous/Screening
CFTB Call Forward Timed for CFB
CFTD Call Forward Timed for CFD
CFU Call Forwarding Universal
CFWVAL Call Forwarding Validation
CID (NTS_CID) Calling Party Identification
CIR Circular Hunt
CLI Calling Line Identification
CMCF Control Multiple Call Forwarding
CNDBO Calling Number Delivery Blocking Override
CNF Station Controlled Conference
COT Customer Originated Trace
COTAMA Customer Originated Trace with AMA
CPU Call Pickup
CTD Carrier Toll Denied
CTW Call Transfer Warning
CWD Dial Call Waiting
CWI Call Waiting Intragroup
CWO Call Waiting Originating
CWR Call Waiting Ringback
CWT Call Waiting
CWX Call Waiting Exempt
CXR Call Transfer
DCBI Directed Call Pickup Barge-In
DCBX Directed Call Pickup Barge-In Exempt
DCF Denied Call Forwarding
DCPK Directed Call Park
DCPU Directed Call Pickup
DCPX Directed Call Pickup Exempt
DENYISA Deny In-Session Activation
DID Direct Inward Dialing
DIN Denied Incoming Calls
DISA Direct System Inward Access
DISP Display
DLH Distributed Line Hunt
DND Do Not Disturb
DNH Directory Number Hunt
DMCT Deny Malicious Call Termination


DNID (NTS_DNID) Dialed Number Identification Delivery
DOD Direct Outward Dialing
DOR Denied Origination
DRCW Distinctive Ringing/Call Waiting
DRING Distinctive Ringing
DTM Denied Termination
EBO Executive Busy Override
EBX Executive Busy Override Exempt
ELN Essential Line
Intl Emergency Call International Emergency Call Routing
EMW Executive Message Waiting
EXT Extension Add-On
FCTDINT Full Carrier Toll Deny for International Carriers
FCTDNTER InTER-LATA Full Carrier Toll Denied
FCTDNTRA Intra-LATA Full Carrier Toll Denied
FGA Feature Group A
FNT Free Number Terminating
FTRGRP Feature Group
FTRKEYS Feature Keys
FXR Fast Transfer
ICSDEACT In Call Service Deactivation
IECFB Internal/External Call Forwarding Busy
IECFD Internal/External Call Forwarding Do Not Answer
ILB Inhibit Line Busy
IN (CS-X) Intelligent Networks (CS-x)
INSPECT Inspect Key
INTPIC International Primary Carrier
IRR Inhibit Ring Reminder
JOIN Conference Join
KSH Key Short Hunt
KSMOH Key Set Music on Hold
LCDR Local Call Detail Recording
LI Lawful Intercept
LMOH Line Music on Hold
LRN (INTL LNP) International Local Number Portability
LNR Last Number Redial
LNRA Last Number Redial Associated with Set
LOD Line Overflow to DN
LOR Line Overflow to Route
LPIC IntraLATA PIC
LVM Leave Message
MBK Make Busy Key
MBSCAMP Meridian Business Set Station Camp-On
MCH Malicious Call Hold
MADN (Multiple Appearance Directory Number) Multiple Call
MDN MCA
Arrangement
MADN (Multiple Appearance Directory Number) Single Call
MDN SCA
Arrangement


MDNNAME MADN Member Name
MEETME Meet-Me Conference
MEMDISP MDN Member Display
MLAMP MDN Lamp
MLH Multi-Line Hunt
MOT Music on Transfer
MREL MDN Release
MRF MDN Ring Forwarding
MRFM MADN Ring Forwarding Manual
MSB Make Set Busy
MSBI Make Set Busy Intragroup
MWIDC Message Waiting Indication
MWINK MADN Message waiting indicator
MWQRY Message Waiting Query
MWT Message Waiting
NAME Name Display
NOH No Receiver Off-Hook Tone
NTAIT Network Translated Address Indicator Termination
OLS Originating Line Select
ONI Operator Number Identification
OP Operator Services Access
PBL Private Business Line
PCI Preselect Carrier Identification
PCOS Proirity Class of Service
PCWT Precedence Call Waiting Termination
PDO Prevent Delete Option
PF Power Features
PIC Primary InterLATA Carrier
PILOT Pilot DN Billing
PLP Plug-Up (Trouble Intercept)
PNP Private Numbering Plan
PORT 10 digit unconditional LNP trigger
PPL PVN Priority Line
PREMTBL Call Preemption
PRESET CONF Preset Conference
PRH Preferential Hunting
PRK Call Park
PRL Privacy Release
PRV Privacy for MADN
QBS Query Busy Station
QCK Quick Conference Key
QTD Query Time and Date
RAG Ring Again
RCF/RCFEA Remote Call Forwarding (Access to)
RCVD Received Digits Billing
REASDSP Reason Display
RESL Restricted Line


RPA Repeated Alert
RSP Restricted Sent Paid
RSUS Requested Suspension
SACB Subscriber Activated Call Blocking
SBLF Set Based Lamp Field
SCA Selective Call Acceptance
SCF Selective Call Forwarding
SCI Serving Carrier Identification
SCL Speed Calling Long
SCMP Series Completion
SCRJ Selective Call Rejection
SCS Speed Calling Short
SCU Speed Calling User
SDSDENY Special Delivery Service Deny
SDY Line Study
SEC Security
SETMODEL Set Model
SIMRING Simultaneous Ringing
SLQ Single-line Queuing
SLU Subscriber Line Usage
SMDI Simplified Message Desk Interface
SMDR Station Message Detail Recording
SOR Station Origination Restriction
SORC Station Origination Restrictions Controller
SPB Special Billing
SPR Selective Supression of MDCR/SMDR
SSAC Station Specific Authorization Codes
SUBCOM Subcommunity routing for Emergency Calls
SUPPRESS Suppress Line Identification Information
SUS Suspended Service
SVCGRP Service Group
TBO Terminating Billing Option
TERM Terminating DN Billing
TES Toll Essential
TFO Terminating Fault Option
TLS Terminating Line Select
TollFree Tollfree Services
UCD Uniform Call Distribution
UCDLG Uniform Call Distribution Login
VOW Virtual Office Worker
VOWDN Virtual Office Worker DN
WAC Wide Area Centrex
WC Who's Calling
WML Warm Line
WUCR Wake up call ring timeout

Chapter F4 ISDN Supplementary
Services
F4.1 Introduction
ISDN supplementary services can be divided into the following categories:
! MoU Priority 1 services, i.e. supplementary services specified as Priority 1 services
in the CEPT Memorandum of Understanding (MoU) on ISDN rollout for Europe:
Memorandum of Understanding on the Implementation of an European ISDN
Service by 1992. Support for these MoU1 services is discussed in section F4.2.
! MoU Priority 2 services, i.e. supplementary services not specified as Priority 1
services in the MoU. Support for these MoU2 services is discussed in section F4.3.
! Non-ETSI ISDN services, which are services not specified in the MoU or defined
by ETSI, but which are either defined as requirements by other bodies, e.g. national
regulatory bodies, or defined by Nortel for general use. See section F4.4 for details.
Non-ETSI ISDN services are sometimes referred to as MoU3 services.
This chapter describes support for ISDN supplementary services over the CS2000
implementation of ETSI ISDN PRI at the T reference point, a point-to-point interface
serving digital PBXs as described in Chapter E4: PRI Access Interface.

Communication Server Capabilities Features and Services ISDN Supplementary Services
F4.2 MoU1 Service Support

The table below lists the MoU1 ISDN services supported by CS2000 over PRI.
Descriptions of all the services supported are provided following the table.
Service Supported over PRI

Calling Line Identification Presentation (CLIP) Y
Calling Line Identification Restriction (CLIR) Y
Direct Dialling In (DDI) Y
Note: The MoU1 services Multiple Subscriber Number (MSN) and Terminal Portability
(TP) are not relevant for PRI, and are therefore not listed or described.
! Calling Line Identification Presentation (CLIP)
The CLIP service provides the called party with the ISDN number of the calling
party in a form sufficient to allow the returning of the call (i.e. a subscriber number,
a national number or an international number, together with a subaddress if
provided by the calling user).
Service defined in ETS 300 089 (stage 1) and ETS 300 092 (stage 3).
! Calling Line Identification Restriction (CLIR)
The CLIR service restricts presentation of the calling users ISDN number and
subaddress to the called user.
When the CLIR supplementary service is applicable and activated, the originating
network notifies the destination network that the calling users ISDN number and
subaddress information (if provided by the calling user) are not allowed to be
presented to the called user.
! Direct Dialling IN (DDI)
The DDI service enables the user to establish a call to a destination, without the
assistance of an operator, using a DDI number sent en-bloc or by overlap sending
from the network to the user. The DDI supplementary service is based on the use of
the ISDN number, and does not include subaddressing.
In a network with an open numbering plan, the length of DDI numbers need not be
known to the serving CS2000.

ISDN Supplementary Services Features and Services Communication Server Capabilities
F4.3 MoU2 Service Support

The table below lists the MoU2 ISDN services supported by CS2000 over PRI.
Descriptions of all the services supported are provided following the table.
Note: Services that are not supported are neither listed nor described. This includes
services that cannot be assigned to PRI users (e.g. Call Hold, Call Waiting). Some
services (Call Forward variants CFU, CFB and CFNR) are listed and described because
CS2000 supports the resulting call reconfiguration, but service functionality is actually
provided by the PBX and is not the responsibility of CS2000.
Service Supported over PRI

Advice Of Charge During Call (AOC-D) Y
Advice Of Charge at End of Call (AOC-E) Y
Closed User Group (CUG) Y
Connected Line Identification Presentation (COLP) Y [1]
Connected Line Identification Restriction (COLR) Y [1]
Malicious Call Identification (MCID) Y
Subaddressing (SUB) Y
User-to-User Signalling (UUS) Y [2]
Call Completion to Busy Subscriber (CCBS) Y
Call Forward Unconditional (CFU) Y [3]
Call Forward on Busy (CFB) Y [3]
Call Forward on No Reply (CFNR) Y [3]
Partial Rerouting (PRR) Y [4] [5]
Explicit Call Transfer (ECT) Y
[1] Presentation Number (PN) can be provided instead of Network Number (NN).
[2] UUS Service 1 (implicit and explicit) only.
[4] Service functionality is provided primarily by the PBX, not by CS2000, but CS2000 can support
the resulting call reconfiguration and provide notification back to the caller.
[5] PRR is not a supplementary service in its own right, but a capability associated with the Call
Forward and Call Deflection services.
Most MoU2 services rely on information being conveyed in FACILITY or NOTIFY

messages or Facility/Notify IEs in other messages, in accordance with the generic
functional protocol described in ETS 300 196.

! Advice Of Charge During Call (AOC-D)

The AOC-D service enables the user to be informed of the recorded charges for a
call during the active phase of the call. The network supports this by sending
FACILITY messages at intervals of 5 seconds (or multiples of 5 seconds) while the
call is active, each containing a Facility IE with charging information. A final
Facility IE is also included in the DISCONNECT (clearing by network) or
RELEASE (clearing by user) message sent to the user during call clearing.
Office parameters determine the currency unit and the monetary cost of each charge
unit. Service logic consults tariff, TOD and discount tables to determine applicable
charges, and can convey these to the user either in monetary form or as a number of
units. CS2000 can support national AOC variants, e.g. for Germany, as well as the
standard ETSI-defined service.
! Advice Of Charge at End of Call (AOC-E)
The AOC-E service enables the user to be informed of the recorded charges for a
call at the end of the call. The network supports this by including a Facility IE with
charging information in the DISCONNECT (clearing by network) or RELEASE
(clearing by user) message sent to the user during call clearing.
The metering mechanism used is as for AOC-D (see above).
! Closed User Group (CUG)
The CUG service allows users to be organised into groups to and from which access
is restricted. The members of a given group can communicate among themselves,
but usually not with users outside the group. A given user may be a member of more
than one group. Call attempts are checked to determine whether they are subject to
CUG restrictions. If so, the call attempt will succeed only if it is
- to/from another member of the same CUG
- from a CUG member who is permitted outgoing access
- to a CUG member who is permitted incoming access.
CUG information is carried in the Facility information element in the SETUP
message.
! Connected Line Identification Presentation (COLP)
The COLP service allows the calling party to be presented with information about
the identity of the called party, provided in the backward CONNECT message at the
end of call establishment. This service is primarily useful when a call has been
diverted, as prior to diversion the called party number is the number dialled, and is
therefore already known to the calling party.
A Presentation Number (PN) can be provided instead of the called partys Network
Number (NN/CLI). CS2000 datafill for the PRI termination determines whether the
user-provided number is treated as a PN or NN and whether it is screened before
being passed on. Table LTDATA also allows a default PN to be datafilled for a PRI
termination as well as a default NN, for use if no PN is provided or if the PN
provided fails screening. For the originating CS2000, the connected PN will be
provided to the PRI caller instead of the NN if office parameter PN_SUPPORTED
is specified and a PN is available.

! Connected Line Identification Restriction (COLR)

The COLR service allows the called party to prevent his or her ISDN number from
being provided to the calling party via the COLP service. The network conveys the
number to the originating exchange even if it is not to be provided to the caller.
See COLP description for information about support for PN instead of NN for
COLP/COLR.
! Malicious Call Identification (MCID)
The MCID service enables the network to identify an incoming call and record the
Calling Party Number, Called Party Number, Last Forwarding Number (if
applicable), date amd time.
MCID can be invoked either manually by the subscriber, or automatically by the
network for all unanswered calls. It can be requested during the active phase of a
call, or in the call takedown phase after receipt of DISCONNECT.
MCID information is carried in a Facility IE in a FACILITY message. If the calling
party number is not available due to interworking, the CLLI of the incoming trunk
is recorded.
! Subaddressing (SUB)
The SUB service allows up to 20 octets of extra addressing information to be
provided on calls to a user. This information can be used at the called partys
network address (ISDN number) to identify an extension number, device or process
to be accessed. The called party subaddress is provided in the SETUP message as
part of basic call establishment, and is passed transparently through the network
from the originating to the destination interface.
! User-to-User Signalling (UUS)
UUS allows either party in a call to provide up to 128 octets of free-format
information to the other party. There are three service variants, only one of which
is supported by CS2000:
" UUS Service 1 supports the exchange of information via UUI parameters in
standard call setup and clearing messages such as SETUP.
" UUS Services 2 and 3 support the exchange of information via USER
INFORMATION messages.
CS2000 PRI supports only UUI Service 1, either implicitly requested by the
provision of a UUI parameter, or explicitly requested by means of a Facility IE.

! Call Completion to Busy Subscriber (CCBS)

The CCBS supplementary service enables a user (A) who encounters a busy
destination (B) to have the call completed when B becomes free, without having to
make a new call attempt. Sequence of events:
1 User A (a CCBS subscriber) encounters busy destination B, and is informed
during call clearing that CCBS would be possible.
2 User A requests CCBS service. The originating CS2000 uses TCAP to convey
the CCBS request to the terminating CS2000 (unless A and B are served by
the same CS2000). TCAP NCAS (Non Call Associated Signalling) is
conveyed across the packet network between CS2000 USPs by means of a
TCAP / SCCP / MTP3 / M2PA / SCTP / IP protocol stack. Alternatively, it
can be conveyed over a conventional CCS7 signalling network.
If the terminating CS2000 uses an Open Dial Plan (ODP) in which both
variable-length DNs and fixed-length padded DNs are used, an office
parameter specifies an appropriate entry point into translations to ensure that
the CCBS target number is correctly translated.
3 The terminating CS2000 monitors Bs line, and uses TCAP to inform the
originating CS2000 when B becomes free.
4 The originating CS2000 sends CCBS-T-RemoteUserFree, causing A to be
recalled.
5 A then initiates a call to B. The SETUP message for this second call attempt
includes a Facility IE conveying CCBS-T-Call.
CS2000 supports both originating and terminating CCBS functionality.
ETSI ISUP V2 is used for call setup and clearing across the network.
Circuit-independent messaging for CCBS uses a White Book TCAP protocol stack;
SCCP subsystem number 11 (ISDNSS) is dedicated to ISDN supplementary
services.
! Call Forward (CFU, CFB, CFNR)
The Call Forward service allows incoming calls to be forwarded to an alternative
number to be answered. There are three variants:
" Call Forward Unconditional (CFU) causes all incoming calls to a given
number to be forwarded immediately to an alternative number.
" Call Forward on Busy (CFB) causes an incoming call to a given number to be
forwarded immediately to an alternative number if it encounters an engaged
tone.
" The Call Forward on No Reply (CFNR) causes an incoming call to a given
number to be forwarded to an alternative number if it is not answered within
a specified time.
In all cases, the PI (Presentation Indicator) of the Redirecting Number in the
rerouted call setup message should reflect that of the forwarding party.

(Call Forward description - continued)

Callers, called parties and forwarded-to parties can be PRI users, but PRI users
cannot have the service assigned to them at the CS2000. For PRI users, the
signalling for service activation, deactivation and interrogation is handled entirely
within the PBX, and does not involve CS2000.
For a terminating PBX served by a PRI trunk, CS2000 support for Call Forward
reconfiguration and notification requirements is as follows:
" Case A Call forwarded within PBX
Call reconfiguration handled entirely by PBX; no action required from
CS2000; CS2000 compliant with reconfiguration requirements.
Notification of forwarding provided by PBX to CS2000; CS2000 should relay
notification back to caller; CS2000 not compliant with notification
requirements.
Signalling summary:
1 SETUP from CS2000 to PBX
2 Facility IE from PBX to CS2000, in FACILITY, PROGRESS or
ALERTING message
3 Facility IE discarded by CS2000; no backward notification of Call
Forward is provided
4 Standard call setup continues
" Case B Call forwarded from PBX to some other trunk or line
Call reconfiguration handled partly by PBX and partly by CS2000; CS2000
compliant with reconfiguration requirements.
Notification of forwarding provided by PBX to CS2000; CS2000 should relay
notification back to caller and forward to forwarded-to party. CS2000 does
not support backward notification to caller, and is therefore not fully
compliant with notification requirements.
Signalling summary:
2 Second SETUP (with Facility IE) from PBX to CS2000, in effect
initiating a second call
3 Standard call setup continues, resulting in call tromboned through PBX;
CS2000 sees tromboned call as two separate calls
For a call forwarded to an ETSI PRI trunk, CS2000 provides the redirecting
number in the SETUP message used to initiate call setup to the forwarded-to
party. The redirecting number can be conveyed in either of two ways (see
A89008946 for a more detailed description):
# In a Redirecting Number (RgN) IE
# In a DivertingLegInfo2 component in a Facility IE
For intra-CS2000 calls forwarded to ETSI PRI, the Facility IE method is
always used. For calls redirected by a different network, i.e. redirected to
CS2000, redirecting information in the incoming ISUP IAM is interworked to
an ETSI PRI RgN IE if SERV option REDIR_INFO_IN_RGN is specified in
table LTDATA; otherwise, a Facility IE is used.
When a call has been redirected more than once before terminating on ETSI
PRI, two redirecting numbers are provided. The first redirecting number is
provided in the first Facility IE or RgN IE; the last redirecting number is
provided in the second Facility IE or RgN IE.

! Partial Rerouting (PRR)

Partial Rerouting is not a supplementary service in its own right, but a capability
associated with the Call Forward service (all variants) and the Call Deflection
service. Capability defined in section 10.5 of ETS 300 207.
Partial Rerouting (PRR) for a terminating PBX served by a PRI trunk is a
refinement of the Call Forward Case B scenario described on the previous page, the
objective of which is to eliminate tromboning through the PBX for a call forwarded
to some other trunk or line.
Call reconfiguration is handled partly by the PBX and partly by CS2000; CS2000 is
compliant with reconfiguration requirements.
Request for forwarding with PRR is provided by the PBX to CS2000; if successful,
CS2000 should provide forwarding notification back to caller and
forward to forwarded-to party; CS2000 is compliant with notification
requirements, but only for PRI call parties.
Two variants of PRR have been defined by ETSI: Late Release and Early Release.
Both variants can be supported by CS2000. The method used in a given case
depends on the type of forwarding that has taken place.
PRR Late Release signalling summary:
2 Facility IE in FACILITY message from PBX to CS2000, requesting PRR
3 CS2000 responds to request by initiating setup for new leg of forwarded call,
e.g. by sending a new SETUP message
4 CS2000 provides notification of Call Forward as follows:
- FACILITY message sent back to caller, with Notification IE
specifying new called party as Redirection Number.
- NOTIFY message sent forward, with Notification IE
specifying Call Forward subscriber as Redirecting Number.
5 On completion of call setup, original incoming call is through-connected
directly to new outgoing call leg
6 CS2000 sends DISCONNECT to initiate clearing of original outgoing call
leg; DISCONNECT conveys Facility IE with Return Result for PRR request
PRR Early Release signalling summary-
1 SETUP from CS2000 to PBX.
2 Facility IE in FACILITY message from PBX to CS2000, requesting PRR
3 CS2000 sends DISCONNECT to initiate clearing of original outgoing call
leg; DISCONNECT conveys Facility IE with a Call Rerouting Return Result.
4 CS2000 responds to request by initiating setup for new leg of forwarded call
by sending a new SETUP message

! Explicit Call Transfer (ECT)

The ECT supplementary service enables an ISDN user who is involved in two calls
to drop out of both calls and have the other parties connected directly to each other.
The ECT subscribers bearer connections with CS2000 (two channels on a PRI PBX
carrier) are then freed and are available for re-use.
Call reconfiguration is handled partly by the PBX and partly by CS2000. CS2000
is compliant with reconfiguration requirements.
ECT-related requests are provided from user to CS2000 via PRI. There is no
requirement to provide notification of ECT, but CS2000 provides notification
to the newly through-connected parties if they are directly connected via PRI.
Explicit service activation (the only method available to PRI users) involves the
following sequence of events (beginning with two separate existing calls):
1 Facility IE in FACILITY message from PBX to CS2000 for either call,
requesting link ID used for other call.
2 Facility IE in FACILITY message from CS2000 to PBX, providing requested
link ID.
3 Facility IE in FACILITY message from PBX to CS2000, requesting ECT and
providing link ID used for other call.
4 CS2000 responds to request by through-connecting the other two parties.
CS2000 also provides notification of ECT to these parties if they are directly
connected via PRI.
5 CS2000 sends two DISCONNECT messages to initiate clearing of the
CS2000-to-PBX links used by the ECT subscriber; the DISCONNECT for the
link on which the ECT request was received conveys a Facility IE with a
Return Result for the ECT request.

F4.4 Non-ETSI ISDN Services

The table below summarises CS2000 support for non-ETSI ISDN services over PRI.
These are either ISDN services defined by a national regulatory body (e.g. for the German
network) or proprietary services defined by Nortel for general use. Descriptions of all the
services are provided following the table.
Service Supported for PRI

Network Advice Of Charge (NAOC) Y
Priority Class Of Service (PCOS) for Germany Y
Emergency Calls Y
Random and Circular Hunting for PRI Y
! Network Advice Of Charge (NAOC)

For NAOC, call charges are calculated centrally at a Charge Determination Point
(CDP), and call charge information is then passed to the originating node to be
relayed back to the calling user over the access interface. The originating node is
referred to as a Charge Generation Point (CGP). The primary purpose of NAOC is
to allow the user to be notified of call charges even if these are calculated at a
different node (typically when the user has selected an alternative carrier for a call,
in which case CDP functionality is provided by that carriers network).
CDP and CGP functionality can be implemented on separate nodes or on the same
node. If they are on separate nodes, charging information is conveyed from the CDP
back to the CGP using the ETSI ISUP V2+ Application Transport Mechanism
(APM); the CGP supports APM/AOC interworking for PRI call originations. If the
CDP and CGP are on the same node, internal messaging is used. CS2000 can be
used as a CDP only, a CGP only, or a combined CDP/CGP; translations determines
which role is required on a per-call basis.
AOC subscriber datafill determines whether information is provided over the access
interface in the form of monetary values (with a choice of currency units) or pulse
counts. Subscribers who receive AOC information in the form of currency units can
choose to use the BNS (billing to the nearest second) charging method.
! PCOS (Priority Class of Service) for Germany
PCOS allows selected users to have privileged access to the network in the event of
catastrophes. After a CS2000 is set into catastrophe state by a craftsperson,
unrestricted calls are possible only from PRI accesses with the PCOS option.
Restrictions and/or service degradations may apply to calls from other lines.
! Emergency Calls (110/112 and 115)
An emergency call is marked as a priority call via the priority indicator in the
onward IAM. The dialed emergency number is specially translated to route the call
to the nearest emergency bureau. This translation functionality is designed for use
in Germany, but is not German-specific.
! Random and Circular Hunting
This makes it possible to ensure that calls to a given set of trunk groups (a
super-group) are evenly distributed between their B-channels. This is particularly
useful for CS2000s connected to Internet Service Providers (ISP), where a large
number of outgoing-only trunk groups are assigned to the same dialled number and
call hold times are long.

F4.5 Networked Support for Supplementary Services

This section summarises CS2000 support for the networking of ISDN supplementary
services in ISN07. An ISDN supplementary service is deemed to be supported if CS2000
supports it over both the access interface (ETSI ISDN PRI) and the network interface (e.g.
ETSI ISUP V2 over SIP-T), and also supports direct interworking between any
service-related parameters conveyed over both interfaces. Services that are not supported
or not applicable for PRI are simply not listed.
Networked support over

ISDN supplementary service ETSI ISUP ETSI ISUP IBN7 /
V1 V2 ANSI ISUP
CLIP Yes Yes Yes
CLIR Yes Yes Yes
DDI Yes [1] Yes [1] Yes [1]
Advice Of Charge During Call (AOC-D) N/A [1] N/A [1] N/A [1]
Advice Of Charge at End of Call (AOC-E) N/A [1] N/A [1] N/A [1]
Closed User Group (CUG) Yes Yes No
Connected Line Identification Presentation (COLP) No Yes No
Connected Line Identification Restriction (COLR) No Yes No
Malicious Call Identification (MCID) Yes Yes No
Subaddressing (SUB) Yes Yes Yes
User-to-User Signalling (UUS) Yes [2] Yes [2] Yes
Call Completion to Busy Subscriber (CCBS) No Yes [3] No
Call Forward Unconditional (CFU) [4] Yes [5] Yes [6] Yes
Call Forward on Busy (CFB) [4] Yes [5] Yes [6] Yes
[5] [6]
Call Forward on No Reply (CFNR) [4] Yes Yes Yes
Partial Rerouting (PRR) [7] [8] Yes [5] Yes [6] Yes
Explicit Call Transfer (ECT) Yes Yes No
Non-ETSI ISDN services
Network Advice Of Charge No Yes No
Priority Class Of Service (PCOS) for Germany No Yes No
Emergency Calls Yes Yes No
Random and Circular Hunting for PRI Yes [1] Yes [1] Yes [1]
[1] No additional network signalling required.
[2] UUS service 1 (implicit and explicit) only.
[3] TCAP NCAS (Non Call Associated Signalling) for CCBS can be conveyed across the packet
network between CS2000 USPs by means of a TCAP / SCCP / MTP3 / M2PA / SCTP / IP
protocol stack. Alternatively, it can be conveyed over a conventional CCS7 signalling network.
[5] Forwarding node functionality supported, but no notification is provided back to caller or forward
to new called party. Such notifications are not defined for Q.767.
[6] Some limitations apply to CS2000 support for forwarding notifications to caller and new called
party (see service description in section F4.3).
[7] Service functionality is provided primarily by the PBX, not by CS2000, but CS2000 can support
the resulting call reconfiguration and provide notification back to the caller.
[8] PRR is not a supplementary service in its own right, but a capability associated with the Call
Forward and Call Deflection services.

F4.6 Order Codes for ISDN Supplementary Services
Table 54: Order codes for ISDN supplementary services software

PRIT0003 ETSI PRI MoU 1 & 2 Basic Services
PRIT0008 COLP/COLR
PRIT0006 PRI Non-ETSI Services
PBXT0011 PRI Advice of Charge
NETK0024 ISUP Network Advice Of Charge (NAOC)

Chapter F5 QSIG Services
F5.1 Overview
QSIG incorporates not only basic call control procedures, but also generic functional
procedures for the control of supplementary services at the Q reference point. For an
overview of the Generic Functional Transport (GFT) entity, see section E5.1.3 on page
466.
QSIG feature set support can be categorised as follows:
! Features supported as part of basic call
Calling Line Identification Presentation (CLIP)
CLI Restriction (CLIR)
! Support for QSIG Additional Network Features (ANFs)
Transit Counter
! VPN support via QSIG Feature Transparency (bearer and non-bearer)
! Support for specific ETSI ISDN supplementary services
Advice Of Charge (AOC)
! Support for public network features (all German)
Priority Class Of Service (PCOS)
Emergency Calls
German Carrier Selection
Network Advice Of Charge (NAOC)
Support for the services in these categories is described in sections F5.2 to F5.6
respectively.
Note: In addition to providing service support over the externally visible QSIG interface,
CS2000 uses QSIG internally, for signalling across the CS LAN between the Core and
H.323 GWCs. The H.323 GWC performs message mapping between H.225 call control
messages and equivalent QSIG messages. For H.323 tunnelling, this message mapping

Communication Server Capabilities Features and Services QSIG Services
involves converting H.225 IEs conveying encapsulated H.450 and H.245 signalling into
QSIG Facility IEs conveying the same encapsulated signalling unmodified. See Chapter
D5: H.323 for further information. Also see Chapter E6: DPNSS Interface and Chapter
F6: DPNSS Features, as this H.323/QSIG mapping capability is used to support DPNSS
signalling and DPNSS Feature Transparency (DFT) for DPNSS PBXs connected to
Westell gateways and controlled via H.323.
F5.2 Features Supported as Part of QSIG Basic Call

CS2000 provides full originating, terminating and transit node support for the following
ISDN supplementary services as part of QSIG basic call:
! Calling Line Identification Presentation (CLIP)
The CLIP service provides the called party with the ISDN number of the calling
party in a form sufficient to allow the returning of the call (i.e. a subscriber number,
a national number or an international number, together with a subaddress if
provided by the calling user).
! Calling Line Identification Restriction (CLIR)
The CLIR service restricts presentation of the calling users ISDN number and
subaddress to the called user.
When the CLIR supplementary service is applicable and activated, the originating
network notifies the destination network that the calling users ISDN number and
subaddress information (if provided by the calling user) are not allowed to be
presented to the called user.
F5.3 QSIG Additional Network Features

F5.3.1 Transit Counter
CS2000 also provides transit node support for the Transit Call additional network feature
defined in ISO/IEC DIS-15056 (see AX0218 for details). Transit Counter limits the
number of transit nodes that a call setup request may be routed through, in order to protect
the network against indefinite looping. CS2000 implements it by means of the office
parameter TRANSIT_COUNTER_LIMIT, which specifies the maximum number of
transit nodes through which a call may be routed. The Transit Counter IE in each
incoming SETUP message is compared with the datafilled limit, and if the IE value equals
or exceeds the limit the call is rejected. If an incoming SETUP message does not have a
Transit Counter IE, CS2000 inserts one with a value of 1 in the outgoing SETUP message.

QSIG Services Features and Services Communication Server Capabilities
F5.4 VPN Support via QSIG Feature Transparency

(QFT)
F5.4.1 QFT for QSIG Access Interfaces
A VPN (Virtual Private Network) is a private network in which some parts of the network
are non-dedicated and provided on demand by the PSTN. An interface such as QSIG
needs to convey additional service-related information in order to support VPN. Public
network protocols, however, do not directly support such information. Some mechanism
is therefore required to ensure that information is not lost when a VPN call is routed
through the public network.
The two key elements to be conveyed transparently are:
! Private network number
! Business group identifier (BGID)
QSIG services already use generic protocol elements for transporting service-related
information, so feature transparency for most QSIG services can be achieved by
transporting those elements over the public network. The mechanism used to support
VPN calls is to take service-specific APDUs conveyed in QSIG Facility IEs and
FACILITY messages, and to encapsulate them in messages that can be conveyed over the
public network. Two protocols are used:
! ETSI ISUP messages are used to encapsulate APDUs from call-associated QSIG
messages and thus support bearer QFT.
! TCAP messages are used to encapsulate APDUs from non-call-associated
(circuit-oriented) QSIG messages and thus support non-bearer QFT
CS2000 supports both bearer and non-bearer QFT, as described in section E5.1.5 on page
469, and uses them to support VPN capabilities. The CS2000 implementation of the APM
extensions to ETSI ISUP, as used to support QFT, is defined in detail in TR 97-8001 and
in AJ4986 and AU3074. The CS2000 implementation of QFT is defined in detail in TR
97-8002, AJ4986 (bearer QFT) and AF7185 (non-bearer QFT).
F5.4.2 The QFT Information Model

The information that can be conveyed via the ETSI ISUP APM depends on the
application context. Each application context has an associated information model that
determines the data types or parameters that can be conveyed via that context. Open
application contexts are defined by standards bodies, while proprietary application
contexts allow equipment vendors and network operators to define information models to
support their own services.
The most important open application context is application context 1 (PSS1), which is
used for QFT. The QFT information model provides definitions for a range of common
data types that are widely used in supporting services. CS2000 uses QFT data types to
support generic VPN capabilities such as business groups and private numbering plans. It
also uses QFT data types to support selected Centrex services for subscriber lines (see
section : Use of APM with Proprietary Access Interfaces and Services on page 616 for
a list).

F5.4.3 QFT Support for Conveying Proprietary Information

Proprietary application contexts allow equipment vendors and network operators to
define information models to support their own services. Such proprietary application
contexts are used when the service-related information to be conveyed cannot be mapped
on to data types in the QFT information model. The QFT option must, however, be
assigned to the trunks used.
The UK regulator has reserved application context 124 for Nortel use. In ISN07,
application ID 3 in this context is used to support NETINFO. The Network Information
(NETINFO) parameter can be included in call setup messages to provide the following
subscriber details for use in setting up translations:
! Customer group, which determines the availability to the subscriber of services
provisioned against the customer group.
! Network Class Of Service (NCOS), which determines the types of call that the
subscriber can make and receive (see section C3.2 on page 206 for details).
NETINFO makes it possible to support customer groups served by more than one node.
In a VPN context, it enables subscribers to have access to the same range of services
regardless of where a call is made from or where a given service implementation resides.
NETINFO is a proprietary alternative to the the QFT BGID (Business Group ID)
parameter, which can convey only customer group information, not NCOS values.
For more information about QFT and VPN, see Chapter E5: QSIG VPN Interface and
Chapter F8: VPN.
F5.4.4 Access to QFT via Non-QSIG Interfaces

Interworking with QFT is supported not only for QSIG access interfaces, but also for:
! PRI access
! Analogue line access
See Figure 138 on page 581 for illustrations of the access configurations involved,
together with explanations of the type of QSIG virtual PINX functionality that CS2000 is
providing in each scenario. Only call originations are shown, but corresponding
functionality is supported for call terminations.

Figure 138 illustrates different types of QFT access configuration, and explains which
type of virtual PINX functionality CS2000 is providing in each case (see section E5.1.1
on page 461 for definitions of different types of PINX functionality).
Scenario A:- CS2000 provides virtual transit

PINX functionality for QSIG access CS2000
QSIG / IUA / SCTP QFT / APM / ISUPv2 / SIP-T

PBX QSIG media and
signalling
gateway H.248 or ASPEN
(PVG) overUDP
Note: Direct QSIG to (media control)
QSIG interworking
occurs only between
gateways controlled Packet network media streams
by the same CS2000
Scenario B:- CS2000 provides virtual incoming

gateway PINX functionality for PRI access CS2000
Q.931 / IUA / SCTP QFT / APM / ISUPv2 / SIP-T

PRI media and
PBX
signalling
gateway H.248 or ASPEN
(PVG) overUDP
(media control)
Scenario C:- CS2000 provides virtual

originating PINX functionality for V5.2 lines CS2000
V5.2 / V5UA / SCTP QFT / APM / ISUPv2 / SIP-T

V5.2 media and
AN
signalling
gateway H.248 / UDP
(PVG) (media control)
Scenario D:- CS2000 provides virtual

originating PINX functionality for analogue lines CS2000
QFT / APM / ISUPv2 / SIP-T

Line GWC (basic call and service control)
Analogue media Combined call and
subscriber gateway media control:
lines (in-band (cable or " NCS (cable)
customer
signalling)
LAN) " MGCP (LAN)
Figure 138: QFT support for different access configurations

F5.5 ISDN Supplementary Services

F5.5.1 Connected Party Number (COLP/COLR)
CS2000 supports the COLP and COLR supplementary services:
! Connected Line Identification Presentation (COLP)
The COLP service allows the calling party to receive information about the identity
of the called party, provided in the backward CONNECT message before call
completion. This service is primarily useful when a call has been diverted, as prior
to diversion the called party number is the number dialled, and is therefore already
known to the calling party.
A Presentation Number (PN) can be provided instead of called partys Network
Number (NN/CLI). Switch datafill for the QSIG termination determines whether
the user-provided number is treated as a PN or NN and whether it is screened before
being passed on. Table LTDATA also allows a default PN to be datafilled for a
QSIG termination as well as a default NN, for use if no PN is provided or if the PN
provided fails screening. For the originating switch, the connected PN will be
provided to the QSIG caller instead of the NN if office parameter
PN_SUPPORTED is specified and a PN is available.
! Connected Line Identification Restriction (COLR)
The COLR service allows the called party to prevent his or her ISDN number from
being provided to the calling party via the COLP service. The network conveys the
number to the originating exchange even if it is not to be provided to the calling
party.
F5.5.2 Advice of Charge (AOC)

CS2000 supports two variants of the Advice Of Charge (AOC) supplementary service
over QSIG:
! Advice Of Charge During Call (AOC-D)
The AOC-D service enables the user to be informed of the recorded charges for a
call during the active phase of the call. The network supports this by sending one or
more FACILITY messages while the call is active, each containing a Facility IE
with charging information.
! Advice Of Charge at End of Call (AOC-E)
The AOC-E service enables the user to be informed of the recorded charges for a
call at the end of the call. The network supports this by including a Facility IE with
charging information in the RELEASE message sent to the user during call clearing.
Charging information is provided by an AOC currency units message, which is
transported in a Facility IE as part of the FACILITY, RELEASE, RELEASE
COMPLETE and DISCONNECT messages as defined in ISO 11582. The format of the
AOC currency units messages for both AOC-D and AOC-E is as defined in ISO
15049/ECMA-211 and ISO 15050/ECMA-212. For more details, see AJ7344.

CS2000 also supports the Network Advice Of Charge (NAOC) service. For NAOC, call
charges are calculated centrally at a Charge Determination Point (CDP) node, and call
charge information is then passed to the originating node to be relayed back to the calling
user over the QSIG access interface. See 59007987, 59008229 and 59007780 for details.
F5.5.3 Call Completion (CCBS / CCNR)

Call Completion to Busy Subscriber (CCBS) enables a user (A) who encounters a busy
destination (B) to have the call completed when B becomes free, without having to make
a new call attempt. Call Completion on no Reply (CCNR) enables a user (A) who gets no
reply from a call destination (B) to have the call completed when B next becomes
available, without having to make a new call attempt.
CS2000 supports CCBS/CCNR functionality for public calls entering or leaving a private
network based on QSIG. A public call is a call between two parties that belong to different
customer groups, or that both belong only to the default PUBLIC customer group. This
means that a user in the public network can invoke CCBS/CCNR against a QSIG user in
a private network, and that a QSIG user in a private network can invoke CCBS/CCNR
against a user in the public network.
Interworking with QSIG in support for CCBS/CCNR is supported for calls entering or
leaving a QSIG network over the following interfaces:
! ISDN access interfaces (QSIG gateway functionality)
" ETSI PRI
Feature A59023584 provided support for interworking between QSIG and ISDN
PRI in support of CCBS and CCNR. Such interworking is necessary because there
are differences between the PSS1 CCBS/CCNR specifications, as used by QSIG,
and the DSS1 CCBS/CCNR specifications, as used by ISDN PRI.
! Analogue line interfaces (QSIG EndPINX functionality)
" Basic IBN lines supported via line media gateways
" IBN lines supported over V5.2
Feature A59027747 provides support for interworking between QSIG and analogue
lines in support of CCBS and CCNR.
CS2000 not only supports direct interworking between QSIG and access interfaces in
support of CCBS/CCNR for public calls, but also networked/indirect interworking via a
QFT signalling backbone based on ETSI ISUP V2+ and ETSI TCAP.

F5.6 German Network Features

CS2000 supports the following German public network features over QSIG:
! PCOS (Priority Class of Service) for Germany
PCOS allows selected users to have privileged access to the network in the event of
catastrophes. After a switch is set into catastrophe state by a craftsperson,
unrestricted calls are possible only from QSIG accesses with the PCOS option.
Restrictions and/or service degradations may apply to other calls.
! Emergency Calls (110/112 and 115)
An emergency call is marked as a priority call via the priority indicator in the
onward IAM. The dialed emergency number is specially translated to route the call
to the nearest emergency bureau. This translation functionality is designed for use
in Germany, but is not German-specific.
! German Carrier Selection
Carrier selection allows a subscriber to choose a preferred carrier to route
long-distance calls. Every network provider is assigned a unique Carrier
Identification Code (CIC) by the regulatory authority. SERVORD is used to assign
a CIC to a subscribers directory number (DN). The subscribers long-distance calls
will then always be routed over this carrier, unless a different carrier is selected for
a particular call by the explicit dialling of a Carrier Access Code.
The CS2000 implementation of QSIG also supports Open Dial Plan capabilities as
defined in E.164 ODP. Such ODPs permit the usage of free-format DNs with up to13
digits (national numbers) and up to 15 digits (international numbers) as described in
section G1.1.1.2 on page 725. The ODP capability is enabled for the CS2000 as a whole
by the office parameter NATIONAL_COUNTRY_CODE, rather than as a service for
particular users. For Germany, the number of supported ODP digits is equal to 13.

F5.7 Service Support on Interworking

Trunk interworking means not only direct interworking between QSIG and other trunk
interfaces (QSIG gateway node functionality), but also interworking between QFT trunks
and other trunk interfaces (QFT gateway functionality). Support for QSIG services on
interworking to trunk interfaces is as as follows:
! CLIP and CLIR are supported over all trunk interworkings for which QSIG basic
call interworking is supported, i.e. QSIG, PRI, ETSI ISUP, IBN7 and INAP. Transit
Counter is not supported except for QSIG-to-QSIG transit calls.
! By definition, features implemented via QSIG Feature Transparency as described
in section F5.4 are fully supported on interworking to QSIG or to ETSI ISUP V2,
but are not supported on interworking with other trunk types.
! Signalling for the Advice Of Charge (AOC) supplementary service involves only
the originating QSIG access interface, and is not affected by QSIG interworking to
trunks.
The NAOC service, however, currently depends on the German variants of ETSI
ISUP V2 to transport charging information via the APM.
F5.8 Order Codes for QSIG Services
Table 55: Order codes for QSIG services software

PBXT0036 QSIG COLP/COLR

Chapter F6 DPNSS Features
F6.1 Functional Description

F6.1.1 Introduction
DPNSS features are PBX features for the use of business subscribers. DPNSS enables
different types of PBX to communicate via a common peer-to-peer signalling system
(DPNSS). A number of PBXs connected in this way can serve as a single large PBX,
offering the same features and services to subscribers regardless of the type of PBX to
which they are connected. DPNSS services are defined in sections 7 to 48 of the base UK
DPNSS specification BTNR 188.
For details of the CS2000 implementation of DPNSS, see Chapter E6: DPNSS Interface.
F6.1.2 Levels of Support (DPNSS Nodal Functions)

In supporting a DPNSS feature, a PBX or switch supports one of three types of DPNSS
functionality, as illustrated in Figure 139.
Lines Lines
End node PBX or End node
functionality switch, functionality
e.g.
CS2000
PBX or PBX or
switch, DPNSS Transit node DPNSS switch,
e.g. functionality e.g.
CS2000 CS2000
Non-DPNSS Non-DPNSS
trunk Gateway Gateway trunk
functionality functionality
Figure 139: Conceptual network role of DPNSS

DPNSS Features Features and Services Communication Server Capabilities
CS2000 can support DPNSS features in the following ways:

! As a DPNSS transit node (see section F6.1.2.1) for a line served by a PBX.
! As a DPNSS end node (see section F6.1.2.2) for an IBN line served by a
CS2000-controlled gateway and interworked to an IBN7 trunk supporting DPNSS
Feature Transparency (DFT).
Note: The range of DPNSS features that CS2000 can support as a DPNSS end node
is smaller than the range it can support as a DPNSS transit node. See section F6.1.3
for details.
! As a DPNSS gateway node (see section F6.1.2.3) for a non-DPNSS trunk
interworked to DPNSS via QSIG.
Note: For simplicity, the illustrations in this section show CS2000 as a single node. This
should be taken to include all of the network elements involved in presenting the external
DPNSS interface to a PBX, i.e. the CS2000 Core, the H.323 proxy GWC and the Westell
iQ203x gateway, interconnected as illustrated in Figure 122 on page 486. From the
perspective of the DPNSS PBX and for the purpose of explaining the different types of
DPNSS functionality being provided, the fact that multiple network elements are involved
is irrelevant.
F6.1.2.1 CS2000 Support for Transit Node Functionality

DPNSS transit node functionality means acting as an intermediary between two DPNSS
PBXs, connecting them by direct interworking as if there were a direct DPNSS link
between then, as illustrated in Figure 140. This scenario is supported by CS2000. For the
CS2000 Core, the interworking actually involves the transparent relaying of DPNSS
signalling encapsulated in H.450.1 APDUs between two QSIG interfaces.
Transit node functionality means CS2000

involvement in call is transparent
DPNSS DPNSS
PBX PBX
CS2000
DPNSS DPNSS
features features
Figure 140: DPNSS transit node functionality
In addition to supporting DPNSS transit node functionality for two PBXs served by the
same CS2000, CS2000 can support transit node functionality for two PBXs served by
different CS2000s. In this scenario, two or more CS2000s serve as a single logical DPNSS
transit node, with connections between them being provided by IBN7 trunks that support
DFT (DPNSS Feature Transparency). DFT involves encapsulating DPNSS information
in ISUP or TCAP messages and transporting it transparently across the network. CS2000
supports transit node functionality both when interworking DPNSS to a DFT trunk and
when interworking two DFT trunks, as shown in Figure 141.
PBX DPNSS DFT DFT DPNSS PBX

CS2000 CS2000 CS2000
DPNSS DPNSS
features features
Figure 141: Transit node functionality provided by DFT trunks

Communication Server Capabilities Features and Services DPNSS Features
Inter-CS DFT trunks used to support DPNSS transit node functionality may be either
DPTs between GWCs on different CS2000s or circuit-based trunks between TDM-side
endpoints on PVG trunk gateways controlled by different CS2000s.
CS2000 supports DFT using two types of proprietary IBN7 signalling:
! IBN7 ISUP for real DPNSS calls
The Network Transport Parameter (NTP) conveys the Nortel proprietary Hybrid
Network Information Parameter (HNIP).
! ANSI TCAP for DPNSS virtual calls with no associated bearer circuit
See section F6.2.2 on page 594 for more information about DFT support.
See AE0923 for more details of IBN7 DFT transit node functionality.
F6.1.2.2 CS2000 Support for End Node Functionality

DPNSS end node functionality means acting as an intermediary between an IBN line
interface and a DPNSS PBX. It involves using customer group datafill to make an
appropriate subset of DPNSS features available to lines, such that they can use DPNSS
features on calls to or from the PBX. It thus implies support for DPNSS services on
interworking to a DFT line (an IBN line with the DFT option datafilled in table NCOS).
For a call involving DPNSS end node functionality, one of the end nodes is a PBX
connected to a CS2000 switch via DPNSS, and the other is the CS2000 itself (actually, a
CS2000-controlled line gateway), providing DPNSS services to its IBN lines.
Because the CS2000 Core does not support direct interworking between QSIG and DFT
lines for support of DPNSS services, an IBN7 DFT looparound trunk (normally a SIP-T
DPT) must be used as an intermediary in the call.
Note: A SIP-T looparound is not a direct physical link, but a logical connection between
two DPT GWC ports controlled by the same CS2000.
Figure 142 illustrates the configuration used for a nodal call involving DPNSS end node
functionality.
End node functionality means

availability of DPNSS features
to IBN line user
DPNSS
PBX CS2000 line interface
DPNSS DPNSS
features DFT features
looparound
Figure 142: DPNSS end node functionality
Lines that are to be interworked to DFT in this way must have the DFT option datafilled
in table NCOS.
See AE1011 for more details of IBN7 DFT end node functionality.
Note: In cases where there is an Centrex equivalent for a given DPNSS feature,
providing end node support for the DPNSS feature may involve feature-to-feature
interworking with the Centrex equivalent. See section F6.3 on page 596 for details.

F6.1.2.3 CS2000 Support for Gateway Functionality

DPNSS gateway node functionality means the interworking of DPNSS signalling with a
non-DPNSS or non-DFT trunk, as shown in Figure 143. Only basic call support is
guaranteed, not necessarily support for DPNSS features; feature support depends on the
specific interworking and service.
In the CS2000 implementation of DPNSS, DPNSS gateway functionality is provided by
first interworking DPNSS to QSIG via the Westell gateway and the H.323 GWC, as
illustrated in Figure 122 on page 486. The level of feature support is therefore determined
by what is supported for QSIG interworking to the non-DPNSS interface, e.g. many
Centrex services can be supported.
Figure 143 is a simplified view of the configuration used to provide DPNSS gateway
functionality.
CS2000
DPNSS QSIG Non-DPNSS trunk i/f

PBX I/W
DPNSS
features
Figure 143: DPNSS gateway functionality (provided via QSIG)

F6.1.3 Features Supported

DPNSS features are defined in sections 7 to 48 of the DPNSS specification BTNR 188.
Table 56 lists the DPNSS features available and the corresponding BTNR 188 section
numbers, provides brief descriptions of the most important features, and indicates whether
each feature is fully supported (Y), partially supported (y), or not supported (N) by
DPNSS as a transit node or end node. For more detailed information about CS2000
compliance with BNTR 188 feature definitions, see the Nortel DPNSS SIM
Specification (NIS A247-1).
Table 56: DPNSS feature support on CS2000

BTNR 188
CS2000 as CS2000 as
section
Transit Node End Node

DPNSS Feature (DPNSS/DFT to (DPNSS/DFT
DPNSS/DFT) to line)
CLI Display (AE0839, AE1383, AJ4201)
Makes Originating Line Identifier (OLI) available to called
Y Y
party and/or Terminating Line Identifier (TLI) available to
calling party, for display on business set or equivalent.
Busy Information (NC0259)
Busy Information string returned in Clear Request
Y Y
Message (CRM) when busy is encountered, to indicate
availability of CO, EI and/or CBWF at terminating node.
Circuit Switched Data (NC0291, AE1011)
Supports data calls at rates from 64 Kb/s down to 50 b/s,
7 N [1] N
in accordance with BTNR 188. Rate indicated by Service
Indicator Code (SIC) value.
Swap (AE0284)
8 Allows transmission requirements of call to be changed N [1] N
(via new SIC) while call is in progress.
Call Back When Free (AE0328, AE0440, AG4664, AR1928)
9 Allows user who encounters busy line to have call Y Y
completed when line becomes free (like Centrex RAG).
Executive Intrusion (NC0352, AE1384, AG5061)
10 Enables selected users to intrude on established Y N
conversations if they encounter busy (like Centrex EBO).
Call Diversion (AE0782 and AJ5066)
Allows incoming calls to be diverted unconditionally, on
busy or on no answer (like Centrex CFU, CFB,
11 CFNA/CFD). Differs from Centrex CFx because of Y Y
dropback, which allows call to be rerouted to new
destination from originating node (or from I/W node when
I/W encountered).
Call Hold (NC0252)
12 Allows party to put other party on hold and do something Y y
else (implemented as part of 3PC)
Three Party Call (NC0252)
Allows a party engaged in a call to set up another call to a
13 Y Y
third party, then to link both calls (add-on), switch between
the calls (shuttle), or to link the other two parties (transfer).
Call Offer (AE0781)
Allows user who encounters busy line to notify called party
14 of new call (like Centrex DCW). Options for called party are Y Y
as for CW (called party need not have CW; 3WC is enough
to support hook-flash).

BTNR 188
CS2000 as CS2000 as
section
DPNSS/DFT) to line)
Non-Specified Information
Enables DPNSS to convey unspecified information
15 Y Y [2]
required for the implementation of network-specific
features and functions.
Service-Independent Strings
Enables DPNSS to convey supplementary information
16 Y y [3]
strings without affecting the operation of DPNSS basic
calls or suplementary services.
Call Waiting (AG4586)
17 Notification of new incoming call provided during active Y y [4]
call.
Bearer Service Selection (AE0284, AF6453) [5]
Allows requirement or preference for transmission
18 capability to be specified in ISRM (in addition to SIC). If N [6] N
capability not available, call rejected if capability required,
or proceeds as voice call if capability preferred.
Route Optimisation (AR4940, AJ4220, AJ5366)
Where call uses non-optimum route (e.g. after call
transfer), it can be re-established via the preferred route
19 without affecting the parties involved in the call. This Y Y
service cannot be used during data calls.
For information about the billing of route-optimised calls,
see A59017058 and A59022458.
Extension Status
20 Offers the capability of determining, on request, the status Y N
of an extension (free, busy, out of service, diverted, etc)
without calling the extension.
Controlled Diversion
Allows a caller who encounters Call Diversion either to
21 Y N
allow the diversion to proceed or to specify an alternative
method of completing the call.
Redirection (NC0351)
Allows a call transferred by an operator or subscriber to
22 Y y
another extension to be automatically redirected to the
transferrer on timeout or failure.
Series Call (AR1611)
Caller asks called party (operator) to make two or more
23 Y Y
calls, and is reconnected to the operator after each call to
make the next call in the series.
Three Party Takeover (NC0252)
In conjunction with Three Party service, this service allows
the party currently connected to the controlling party in a
24 three party situation to become the controlling party. The Y N
new controlling party remains connected to the original
controlling party. The held party remains on hold but for the
new controlling party.
Night Service (AR1754, AR1823)
Provides alternative answering arrangements for calls to
25 operators at times when normal operator positions are Y y [7]
unattended.
Centralised Operator
26 Allows a single position to provide operator services for Y y [8]
multiple PBXs.

BTNR 188
CS2000 as CS2000 as
section
DPNSS/DFT) to line)
Traffic Channel Maintenance
27 Maintenance functions for a traffic channel on a single N N
DPNSS link between two adjacent PBXs.
Remote Alarm Reporting
28 Provides a network with the capability of reporting to a Y N
central point alarms raised by any PBX in the network.
Add-On Conference
Permits the controller of a Three Party Service conference
29 Y N [9]
to expand it to four or more parties, depending on the
capacity of the conference bridge in use.
Time Synchronisation
30 Allows time and date to be synchronised between different Y N
PBXs.
Call Back When Next Used (CBWNU)
31 Allows user whose call is unanswered to have call
Y N
completed when the called extension is next free after
being used.
Do Not Disturb
32 Offers the possibility of giving a busy indication to callers Y N [10]
when an extension user wishes not to be disturbed.
Remote Registration of Diversion
33 Allows
an extension or operator on one PBX to set or
Y N
cancel diversion at an extension on another PBX in the
DPNSS network.
Remote Registration of Do Not Disturb
34 Enables operator or privileged extension to invoke or Y N
remove the Do Not Disturb condition on extensions.
Priority Breakdown
35 Enables users of selected extensions who encounter Y N
congestion or busy to break down existing connections in
order to complete their own calls.
Call Back Messaging
36 Allows a caller to indicate to the called party that the calling Y N
party wishes to be called back.
Loop Avoidance
37 y [11] N
Rejection of calls that transit too many legs.
Forced Release
38 Offers an intruding party the possibility of forcing the Y N
release of an unwanted party.
Text Message
Permits an extension user to send textual information to
39 another extension user without the need to occupy a traffic Y N
channel.
Charge Reporting
Allows details of call cost and associated information to be
passed between the parties involved in the DPNSS call,
40 where the call has been made from a DPNSS extension to Y N
a destination which causes the terminating PBX to be
charged for the call, on or after answer.

BTNR 188
CS2000 as CS2000 as
section
DPNSS/DFT) to line)
Network Address Extension
Allows the specification of an address beyond a particular
41 destination within a DPNSS network. This subaddress Y N
represents an entity that can be accessed via that
destination.
Call Park
Allows a caller to be placed on on-hook hold at another
extension, or on immediate hold with warning given to the
42 called party if the called party is busy. It also allows the Y N [12]
calling party subsequently to transfer its own held party to
the called party using signalling defined for the Three Party
service.
Call Distribution
Makes it possible to have calls automatically distributed
43 Y N [13]
among a group of associated users spread over more than
one PBX.
Route Capacity Control
Allows a call to be progressed over a route on which all
44 Y N
allocated capacity is in use, by making use of additional
unallocated capacity, typically at extra cost.
Wait on Busy
45 Enables caller who encounters busy to remain connected Y N
to PBX until called party becomes free.
Call Pick-Up
46 Enables subscriber to answer a call awaiting answer at Y N [14]
another extension.
Travelling Class of Service
47 Enables subscriber away from usual phone to make use of Y N
Class Of Service associated with usual phone.
Number Presentation Restriction
48 Enables subscriber to restrict presentation of identity. Y N
[1] 64K clear channel data calls are not currently supported by the CS2000 implementation of
DPNSS.
[2] Nortel-specific NSI string supported for proprietary networked Message Waiting Indication
service with Meridian Mail voicemail system.
[3] Supported only for busy information
[4] Works functionally but no DPNSS signalling at present and normal ring tone to caller.
[5] Supported for a trunk interworking node (gateway), e.g. ISUP to DPNSS.
[6] Signal is relayed but not acted on to ensure required bearer capability is obtained. Bearer
capability requested may not be provided due to ECAN and/or compression codec.
[7] Supported via call diversion. Registration of Night Service number at originating node (CS2000)
is not supported.
[8] Only mandatory services (Three Party, Call Offer, Redirection, Executive Intrusion, Busy
Information) are supported, and only when CS2000 is not the operator position.
[9] Centrex 3/6 party conferencing provides equivalent capabilities without DPNSS signalling.
[10]Centrex DND provides equivalent capabilities without DPNSS signalling.
[11]Message passed on unchanged, so an extra PBX is transited before message is rejected.
[12]Centrex Call Park provides equivalent capabilities without DPNSS signalling.
[13]Centrex ACD/UCD provides equivalent capabilities without DPNSS signalling.
[14]Centrex Call Pickup provides equivalent capabilities without DPNSS signalling.

F6.2 DPNSS Feature Support Mechanisms

F6.2.1 Direct Support
The only interface that supports DPNSS features directly is the DPNSS peer-to-peer PBX
trunk interface used to connect DPNSS PBXs with Westell gateways controlled by
CS2000 via H.323, as described in Chapter E6: DPNSS Interface. DPNSS features are
made available to customer groups via table CUSTNTWK; they cannot be assigned
directly to lines.
F6.2.2 Support via DPNSS Feature Transparency (DFT)
F6.2.2.1 Overview and Rationale

DPNSS features can be indirectly supported via DPNSS Feature Transparency (DFT),
using two types of signalling:
! DPNSS real calls (circuit-dependent) are supported over ISUP trunks, using a
combination of message/parameter mapping and transparent conveyance of DPNSS
information.
! DPNSS virtual call (circuit-independent) are supported over TCAP trunks using the
TCAP Transaction Sublayer (TSL) and the Signalling Connection Control Part
(SCCP)
The main requirement for DFT is to be able to completely reconstitute the DPNSS
information at the CCS7 ISUP/TCAP end nodes so that full DPNSS functionality is
provided. The mechanism used adheres to the following principles:
! Any information that can be uniquely mapped between DPNSS and CCS7
messages, and therefore can be completely reconstituted, should be interworked at
a CCS7 end node.
! Any DPNSS information that cannot be uniquely mapped, but that can be used to
set appropriate CCS7 parameters, should be used for this purpose, but should also
be carried transparently within the CCS7 message.
! Any DPNSS information that has no relevance at all to the CCS7 message should
be carried transparently within the CCS7 message.
CS2000 supports DFT over the proprietary IBN7 ISUP trunk interface described in

F6.2.2.2 Proprietary DFT via IBN7

For DPNSS real calls, the mechanism used for transparent carriage of information through
transit nodes is the Network Transport Parameter (NTP) defined in ANSI ISUP. This
conveys the Nortel proprietary Hybrid Network Information Parameter (HNIP). As an
optional parameter, this can simply be discarded if an end node does not recognise it.
The NTP containing the HNIP can be conveyed in ISUP call control messages. It can also
be conveyed in an unsolicited information message (INF) within a Pass-Along Message
(PAM). An originating node implicitly indicates its support for DFT by including a HNIP
parameter in a forward call setup message such as an IAM; similarly, a terminating node
implicitly indicates its support by including a HNIP parameter in a backward message.
Up to 139 octets of DPNSS information can be included in the contents field of the HNIP.
This comprises up to 135 octets of selection/indication block information and up to four
DPNSS message group and type header octets.
The IBN7 trunk to transport the DPNSS information must have option CFT datafilled
against it in table IBNRTE and the DFT option datafilled in table NCOS.
For a detailed formal definition of DPNSS feature support via IBN7 DFT trunks, see the
Nortel Networks SIM specification DPNSS IBN7 Feature Transparency (NIS A267-1).
F6.2.2.3 CS2000 Support for DPNSS Access to IBN7 DFT Trunks

E1 carriers. These carriers are terminated on a Westell iQ2030 Series gateway under the
control of a H.323 proxy GWC located on the CS2000 CS LAN. Within the CS2000
network, DPNSS Level 3 signalling is conveyed via a number of different lower-level
protocols, as follows:
DPNSS information conveyed transparently in Westell-defined operations
on to QSIG equivalents. The operations containing DPNSS signalling are extracted
from H.225 UUI IEs and encapsulated unmodified in QSIG Facility IEs.
! For nodal support of DPNSS Feature Transparency, the CS2000 Core uses
QSIG-to-QSIG interworking to support direct interworking of encapsulated
DPNSS for two PBXs served by the same CS2000. For networked DFT support, the
Core interworks QSIG and DFT trunks and maps QSIG Facility IEs on to Nortel
HNIPs conveyed in ANSI-defined NTPs, thus enabling DPNSS signalling to be
conveyed transparently across the QSIG/DFT interworking.
See section E6.2.1 on page 485 for a detailed, illustrated description of the network
configuration.

F6.3 DPNSS / Centrex Feature Interactions

Although DPNSS can be used to support private networks consisting entirely of DPNSS
PBXs, one of its greatest strengths is that it can also be deployed in a hybrid VPN (Virtual
Private Network) that supports subscriber lines as well as PBXs. Such a hybrid network
can support both DPNSS features and Centrex features for its end users, which leads to
the following scenarios:
! A given call may involve the use of either or both types of feature.
! Both a DPNSS feature and its Centrex equivalent are available to a line, and the
CS2000 needs to determine which to use on a call.
In both cases, CS2000 attempts to ensure that appropriate feature functionality is provided
end-to-end.
Where a given call involves the use of DPNSS and Centrex features that are functionally
equivalent, CS2000 reverts to the Centrex version of the service. End-to-end service
support is then possible if the PBX is capable of providing functional support for Centrex
service operation.
In the situation in which both a DPNSS feature and its Centrex equivalent are available to
a line, CS2000 needs to determine which to use on a call.
DPNSS features are made available to customer groups via table CUSTNTWK; they
cannot be assigned directly to lines. It is, however, possible to assign the Centrex
equivalent of a DPNSS feature to a line, and in some cases this is essential to enable the
DPNSS feature to operate. When handling a call (or feature activation) to/from a line that
has both types of feature available, the switch uses the call context to determine whether
the DPNSS feature or the Centrex feature should be active.
The scenario is illustrated in Figure 144.
DPNSS features
available to
customer group
CS2000
IBN line
Call context determines Centrex features

which feature is active assigned to line
Figure 144: DPNSS/Centrex feature interworking
Note: Where an Centrex feature must be assigned to a line in order for its DPNSS
equivalent to operate correctly, the DPNSS feature takes on the characteristics of the
Centrex feature. This is the case for EI and EBO. The CS2000 implementation of the
DPNSS EI feature therefore supports only two levels of intrusion, as supported by the
Centrex EBO feature, not the four levels defined for EI in the BTNR.

CS2000 supports interworking between MADN lines (SCA and MCA) and the DPNSS
CBWF feature, as follows (see AJ5403 for a detailed description):
! A DPNSS or DFT caller who encounters a busy MADN group can invoke the
CBWF feature. Free notification is sent back to the caller when any MADN group
member becomes free (MCA) or when the line becomes free (SCA).
! A MADN group member who enounters a busy DPNSS line can invoke the CBWF
feature. Free notification is sent back when the busy called party beomes free, and
causes the MADN callers line to be rung (not all MADN group members lines).
F6.4 Order Codes for DPNSS Services

Table 57: Order codes for DPNSS services
SW Order Code Description
PBXA0004 DPNSS executive intrusion
PBXA0005 DPNSS Series Call
PBXA0007 DPNSS Night Service
PBXA0009 DPNSS route optimisation
PBXA0002 DPNSS base
PBXA0004 DPNSS executive intrusion
PBXA0005 DPNSS series call
PBXA0007 DPNSS night service
PBXA0010 DPNSS diversion billing
PBXA0014 DPNSS diversion billing enhancements
PBXA0015 DPNSS DDI CLI
PBXA0017 DPNSS CLI Blocking
PBXA0018 Route Optimisation - Interaction with Mgmt Reporting
PBXA0021 BTUP provision of CLI to DPNSS
VPNW0008 DPNSS feature transparency

Chapter F7 APM Feature Transparency
F7.1 Overview
Historically, ISUP network services have been built on top of basic call setup and
clearing. Extra ISUP messages, or extra parameters in basic call messages, are used to
convey service-related information across the backbone network, e.g. calling/called party
information for display. This model of service provision, however, requires
service-specific interworkings to be developed between ISUP and the access interface(s)
for every service supported.
The alternative to developing multiple service-specific interworkings is to provide a
general-purpose ISUP mechanism for conveying service-related information across the
network. With this approach, ISUP does not need to understand the information being
conveyed, only to relay it between two access interfaces that do understand it. This is
known as feature transparency.
The FACILITY and NOTIFY messages and Facility and Notification IEs provide a
generic mechanism for conveying service-related information, but only for ISDN
supplementary services and ISDN access interfaces. They cannot be used to convey
information for proprietary services implemented by PBXs or Centrex switches.
The ETSI ISUP V3 APM (Application Transport Mechanism) has been defined by the
ITU-T to serve as a general-purpose service support mechanism. This is supported by the
CS2000 implementation of ETSI ISUP V2 (which is therefore sometimes referred to as
ETSI ISUP V2+). It comprises the following ISUP protocol elements (there are similar
TCAP elements for circuit-independent calls):
an APP.
to convey an APP.

APM Feature Transparency Features and Services Communication Server Capabilities
The information that can be conveyed in an APP depends on the application context.
Each application context has an associated information model that determines the data
types or parameters that can be conveyed in an APP for that context. There are two types
of application context:
! Open application contexts defined by standards bodies. The most important of these
is application context 1 (PSS1), which is used for QFT (QSIG Feature
Transparency). The QFT information model provides definitions for a range of
common data types that are widely used in supporting services; it is not restricted
to providing network support for features supported over QSIG access interfaces.
CS2000 uses QFT data types to support some Centrex services (see section F7.2.1).
! Proprietary application contexts, which allow equipment vendors and network
operators to define information models to support their own services. The UK
regulator has reserved application context 124 for Nortel use, and CS2000 uses it to
support services based on the use of data types that are not defined in the QFT
information model (see section F7.2.3).
Before the ETSI ISUP V2+ APM was available, CS2000 supported the networking of
proprietary services only via the proprietary IBN7 interface, typically by conveying
service-related information in additional IBN7 ISUP parameters and messages. This
implementation of Networked Centrex, however, requires a CCS7 network with an IBN7
signalling backbone. Use of the APM enables network operators to offer Centrex
services to their customers without having to deploy a proprietary signalling backbone.
Note: Use of an IBN7 backbone network is a prerequisite for support of DPNSS Feature
Transparency (DFT). See Chapter F6: DPNSS Features and Chapter E6: DPNSS
Interface for details.

Communication Server Capabilities Features and Services APM Feature Transparency
F7.2 Application Contexts Supported by CS2000

F7.2.1 Services Supported via APM Application Context 1 (PSS1)
CS2000 uses APM application context 1 (PSS1) to support two types of service:
! Services supported over the QSIG VPN interface.
! Centrex services for which all the service-related information to be conveyed can
be mapped on to data types defined in the QFT information model.
Note: For the purposes of this section, the term Centrex should be taken to include
CLASS services as well as Centrex.
Service-related signalling information is encapsulated in accordance with the principles
and rules defined in Q.765.1 and EN 301 062-1 (sometimes refered to a the Q.vpn
standards).
F7.2.1.1 Networked QSIG Services

! ETSI ISDN supplementary services
- Call Completion to Busy Subscriber (CCBS)
- Call Completion on No Reply (CCNR)
! QSIG Additional Network Features
- Transit Counter
- Path Replacement
! Public network features (all German)
- Priority Class Of Service (PCOS)
- Emergency Calls
- German Carrier Selection
F7.2.1.2 Networked Centrex Services

Figure 145 provides an overview of how QFT capabilities can deliver networked service
capabilities both for individual lines and for QSIG-compatible PBXs.
QFT QFT QSIG PBX

CS2000 CS2000 CS2000
Centrex
features
End node functionality
Figure 145: Overview of QFT capabilities
To use the QSIG terminology defined in Chapter E5: QSIG VPN Interface, a DMS
switch that uses QFT to support the networking of VPN services for its directly
connected subscriber lines is providing End PINX functionality. For a detailed
description, see the SIM specifications ETSI ISUP V2+ Application Transport
Mechanism (NIS A246-1bis), QSIG Feature Transparency (NIS A246-1ter) and
ETSI ISUP V2+ EndPINX Functionality (NIS A246-1quat).

For Centrex services with ETSI-defined equivalents (e.g. NRAG/CBWF), QFT carries
any proprietary information that is not required for the ETSI service.
The following table lists and briefly describes the open implementations of Networked
Centrex services that are curently available, indicating for each service which IBN7
feature(s) the open service implementation can replace.
Feature Functionality IBN7 Feature(s) [1]

Networked intra-group calls
Private Numbering Plan NETINFO [3]
using private dial plan [2]
Display private CLI on networked Calling Number Display
Calling Number Display
call Call information Display
Connected Number Display Display private connected Connected Number Display

number on answer Call Pickup
Display calling name to called Network Name Display
Calling Name Display
party Call Information Display
Called Name Display Display name of called party on Network Name Display
alerting
Connected Name Display Display name of connected party Network Name Display
on answer Call Pickup
Display name of called party
Busy Name Display Network Name Display
when call encounters busy line
Networked Message Waiting Notify subscriber that voice mail Networked MWI Activation
Indicator message has been left
Network Ring Again
(open equivalent is Repeat call automatically set up if
Call Completion first call encounters busy Network Ring Again
to Busy Subscriber)
[1] Notify called party that call has Call Forward Universal
been forwarded, indicating Call Forward on Busy
reason and displaying both Call Forward on No Reply
callers number and forwarding
Call Forward partys number. Note: Centrex equivalence,
i.e. conveying private network
[2] Notify caller that call has been numbers, is supported via
forwarded, indicating reason and interaction with NETINFO (see
displaying forwarded-to number. A59022911).

Feature Functionality IBN7 Feature(s) [1]

Blind Transfer
[1] Notify called party that call has 3WC / Call Transfer
been transferred, and display
both callers number and Note: Centrex equivalence,
transferring partys number. i.e. determining whether
Call Transfer
transfer is permitted and
[2] Notify caller that call has been conveying private network
transferred and display numbers, is supported via
transferred-to number. interaction with NETINFO (see
A59023180).
Attendant Camp On
[1] Notify called party that call has Camp On with Music
been transferred by attendant
Attendant Automatic Recall
and display callers number.
Attendant Call Completion Attendant recalled if call not Note: Centrex equivalence,
(Call Transfer, Camp On, answered.
i.e. attendant access and
Recall on Timeout) conveying private network
[2] Notify caller that call has been numbers, is supported via
transferred and display
interaction with NETINFO (see
transferred-to number. A59022994 and A59023001).
[1] For brief functional descriptions of the Centrex services listed, see Chapter F2.
[2] The CdPN in the IAM conveys the public routing number of the destination node; the APP
conveys the private destination number.
[3] QFT supports the Business Group ID parameter, which can be used to convey Centrex customer
group information and thus determine whether a given call is private (intra-group) or public
(inter-group). BGID is not, however, fully equivalent to NETINFO, because it cannot convey the
NCOS (Network Class Of Service) information used by IBN translations to determine permissible
call types, as described insection C3.2 on page 206. Full support for NETINFO via ETSI ISUP
V2+ is provided via the proprietary application context 124 (application ID 3), as summarised on
page 603 and described in detail in A59023093.
See A59028106 for systematic comparisons between these open ETSI ISUP V2+ APM
service implementations and the original proprietary IBN7 implementations.
F7.2.2 Services Supported via APM Application Context 3 (AOC)

CS2000 uses APM application context 3 (AOC) to support the ETSI ISDN supplementary
service Advice Of Charge (AOC).
Service-related signalling information is encapsulated in accordance with the principles
and rules defined in Q.765.1 and EN 301 062-1.

F7.2.3 Services Supported via APM Application Context 124 (Nortel)

CS2000 uses APM application context 124 (Nortel) to provide support for NETINFO, as
follows:
Application ID Service / Feature

3 NETINFO Support
The proprietary application context is used because the service-related information to be

conveyed cannot be mapped on to data types in the QFT information model. The QFT
option must, however, be assigned to the trunks used.
The Network Information (NETINFO) parameter can be included in call setup messages
to provide the following subscriber details for use in setting up translations:
! Customer group, which determines the availability to the subscriber of services
provisioned against the customer group.
! Network Class Of Service (NCOS), which determines the types of call that the
subscriber can make and receive (see section C3.2 on page 206 for details of NCOS
screening).
NETINFO is a proprietary parameter, and used to be supported only via IBN7 ISUP. This
meant that full support for NETINFO VPN capabilities required the use of a proprietary
IBN7 signalling backbone, as the QFT BGID (Business Group ID) parameter could
convey only customer group information, not NCOS values. With the availability of APP
context identifier 124, to support proprietary Nortel Networks applications, application
ID 3 has been reserved for NETINFO support.
NETINFO allows the following information to be conveyed across the network:
! Party Selection Code (PSC)
Indicates that the business group information provided applies to:
" calling party
" connected party
" called party
! NETID
Specifies a unique identifier (0 to 255) assigned in the NETNAMES table for each
business group in the network (a business group is a collection of various customer
groups.).
! NETCGID
Specifies a unique network customer group ID (0 to 4095) defined for the customer
group within the network identified by the NETID. This name is assigned and
maintained by the customer and numerically unique only within the network
identified by the NETID.
! NCOS
Contains an integer (0 to 255) that specifies the NCOS of the customer group.

For a more detailed description of NETINFO support via the ETSI ISUP V2+ APM, see
A59023093.
For a CS2000 using CS2000 to provide transit PINX functionality, NETINFO parameter
handling is as follows:
! PINX functionality is invoked at a transit node if a call encounters the
VPNXLT/VPNREPL option in table PXHEAD during translations.
! If PINX functionality is not invoked, the node behaves as a standard ETSI ISUP
transit node, and simply relays all feature transparency information without
processing it.
! If PINX functionality is invoked and the incoming IAM does not contain
NETINFO, the transit PINX creates a NETINFO parameter and adds it to the
outgoing IAM.
! If PINX functionality is invoked and the incoming IAM already contains
NETINFO, IBN private network translations are triggered at the transit PINX.
See A59028096 for a full description of the possible scenarios for translation and
NETINFO generation.
For a CS2000 supporting indirect access over non-QFT trunks to a network with an ETSI
ISUP V2+ signalling backbone, the ongoing IAM is populated with NETINFO
information as a result of the screening process. See Chapter F11: Indirect Access for a
full description of indirect access, and A59028079 for information about specific
NETINFO capabilities verified with an ETSI ISUP V2+ backbone.

Chapter F8 VPN
This chapter provides an overview of CS2000 support for packet-based VPNs (Virtual
Private Networks) that support both voice and data. It begins with a general discussion of
the rationale for such VPNs, then goes on to describe specific VPN telephony services
supported by the VoIP and VoATM applications in ISN07.
F8.1 Introduction
Virtual Private Networking (VPN) is a generic term describing a corporate network
consisting of a combination of public facilities (provided by a network operator) and
private networking facilities owned or leased by the customer. Its primary aim is to use
public network facilities to complement private network facilities, thus enabling
corporate customers to benefit from the advantages of both.
F8.1.1 VPN Infrastructure Options and Benefits

TDM-based telephony VPNs have been available for a number of years as an alternative
to private corporate voice networks based entirely on dedicated PBXs and dedicated
physical connections. They provide flexibility by supporting bandwidth on demand,
allowing the number of 64 Kb/s trunk circuits between each pair of customer sites to
fluctuate between agreed minimum and maximum levels. The customer saves money by
paying for additional circuits only when they are needed. The network operator can
support a given customer base with a smaller infrastructure, because circuits that are not
in use are potentially available to any customer. An additional benefit is that multiple sites
can make use of a single dial plan.
The VPN rationale can also be applied to corporate data networks. It makes sense to
provide a certain amount of dedicated capacity between different sites, but the best way
of avoiding the twin traps of over-provisioning and under-provisioning/congestion is to
complement the dedicated capacity with extra capacity paid for only when it is needed.
Enterprise customers achieve this by running their packet networks between sites using a
service providers packet backbone network that has been segregated into a number of
data VPNs. A number of techniques are available for doing this, but these are outside the
scope of this document; Nortel Sales Engineering should be consulted for the most
appropriate technique to use in a given scenario.

Communication Server Capabilities Features and Services VPN
Packet-based VPNs that support both voice and data represent the next stage in network
evolution. They offer the following advantages to network operators, which translate into
cost savings for corporate customers:
! Network capacity is used more efficiently because bandwidth on demand is
provided primarily in terms of packets rather than in terms of circuits. A given
physical circuit is not just potentially available to different customers at different
times; it can simultaneously convey packet data from different customers.
! Network configuration and management are simplified because a single backbone
network is used for voice and data.
! Some or all of the sites in a network can support integrated access to both voice and
data networks. For example, line media gateways supporting telephony can be
attached to the same customer LANs that support other data services, i.e. telephony
can be handled as another data service.
A business may be able to take advantage of VPN even if it could not justify the cost of
private leased lines. VPN can also benefit businesses that are already using a leased-line
network; they can use VPN either to replace their private leased lines completely, or as an
additional option for routing traffic and expanding their network to locations not served
by their leased lines. In the case of a business that already has a corporate data network,
use of integrated access allows a telephony VPN to be built on top of that network.
F8.1.2 VPN Access Options and Benefits

There are three main types of access to a CS2000-based telephony VPN:
! Integrated access
Users can be served by line media gateways attached to customer LANs, in which
case acess to the telephony VPN is supported via the LAN as another data service.
! Direct access
This means VPN access via a dedicated physical connection between a PBX and the
TDM side of a CS2000 media gateway. The connection is typically an E1 carrier
supporting private trunk signalling such as PRI or QSIG. A single shared link may
be used to carry both VPN calls and PSTN calls between the PBX and the media
gateway, or there may be two separate dedicated links.
! Switched access
VPN access for end users who are not directly connected to a PBX can be supported
using either of two switched access mechanisms, which means that it is not
necessary to provide dedicated access for all users. The mechanisms are:
" Registered site access allows end users to access the VPN from a registered
location, typically a regional office not directly connected to the corporate
network. The user accesses the VPN by dialling a Freephone number or a
VPN access code, and access is authorised on the basis of the Calling Line
Identity (CLI) provided during call setup.
" Remote access is designed for roaming VPN users. It allows them to access
the VPN while away from their workplace, e.g. by calling from a hotel or
mobile telephone. The user accesses the VPN by dialling a Freephone
number or a VPN access code, then entering an authorisation code and PIN
when prompted to do so.
In both cases, successful completion of the authorisation procedure gives the user
access to the same VPN dial plan options as users served by PBX lines.

VPN Features and Services Communication Server Capabilities
F8.2 VPN Telephony Overview

F8.2.1 VPN Functional Elements
The minimum functional elements of a telephony VPN are:
! Translation support for private numbering plans (see section G1.2 on page 731 for
details). This enables VPN to mix public and private facilities seamlessly for the
convenience of end users and the benefit of the customer organisation. There is no
fixed format for private numbering plans, but two rules generally apply:
" All the numbers in a given VPN are of the same length. Each number is
considered to consist of a location code plus an extension number. The
location code may identify a physical node such as a PBX, or may simply be
a prefix that indicates a logical grouping of extensions. A common scheme is
to use 7-digit numbers comprising a 3-digit location code followed by a
4-digit extension number.
" The VPN extension number of a given terminal should correspond to the last
digits of the PSTN directory number for that terminal, which is typically a
PSTN Direct Dial Inward (DDI) number.
! Routing capabilities that automatically use dedicated bearer capacity if possible and
public capacity when no dedicated capacity is available. VPN bearer capacity is
defined and reserved by means of trunk group datafill at the CS2000 (see section
C2.2 on page 183 for details). This datafill is the same for TDM-side trunks and for
DPTs (Dynamic Packet Trunks) across the backbone packet network, but the
resources actually reserved differ, as follows:
" On the TDM side, for access to the packet-based network backbone, the
resources reserved are physical trunk circuits. The datafill for each CS2000
GWC maps the individual trunks defined in CS2000 Core datafill on to
specified channels on the carriers (E1s or STM-1s) that terminate on the
media gateways it controls.
Note: Access to packet-based VPNs is also supported for lines.
" On the packet side, for connections with other CS2000s and compatible
MGCs such as MCS5200, the resources reserved are logical trunks belonging
to the common CS2000 pool of DPTs. No bearer connection is reserved for a
DPT until it has been selected and allocated as a result of translations and
routing. Only then is a bearer connection set up at a media gateway. This
means that the allocation of bearer capacity across the packet network
backbone is significantly more dynamic and efficient than it can be in a TDM
network.
! Support for shared trunking, i.e. allowing traffic for multiple customers to be
conveyed over the same trunks but still be billed separately. The billing can be
flat-rate (charging for a virtual trunk in the same way as for a dedicated trunk, but
at a lower rate) or based on the level of usage.
These minimum capabilities are system capabilities rather than end user capabilities.
They are available to VPN users, but are typically not provisioned against individual users
or customer groups. VPNs may also support value-added user features, depending on:
! An access signalling system that makes advanced features available and allows
subscribers to be charged for their use.
! A network signalling system with the ability to convey feature-related information
and thus provide end-to-end networked support for features.

F8.2.2 VPN Call Types

The following are the call types that provide basic VPN connectivity:
! On-net to on-net call
This is the most common VPN call type. End users dial other end users using the
common private numbering plan. Local users can be accessed simply by dialling an
extension number. For calls to remote users, a VPN prefix digit (typically 7) is
dialled before the location code and extension number, to indicate that the private
numbering plan is being used.
! On-net to off-net call
This means an on-net VPN user calling a public network number. In either case, a
PSTN prefix digit (typically 9) is dialled before the number, to indicate that the
public numbering plan is being used.
! Direct Dialling Inward (DDI)
This allows an off-net PSTN user to call an on-net VPN user directly, without
operator assistance, by dialling a public network number. This requires the public
network administrator to assign a range of PSTN numbers to a VPN site. The last
digits of the PSTN directory number for a given terminal correspond to the VPN
extension number for that terminal.
The following advanced call types use VPN routing capabilities to minimise call charges:
! Forced on-net call
This happens when a VPN user calls another VPN user by dialling a public network
number, e.g. because the VPN number is not known. The VPN recognises that the
call can be completed on-net and retranslates the public number to an on-net number
for re-routing.
! Virtual on-net call
This call type allows registered sites to be incorporated seamlessly into a private
numbering plan, even if they are actually off-net. A VPN user can call an off-net
registered site using an on-net number. The VPN retranslates the on-net number to
a public number and routes the call accordingly.
! Direct termination overflow
If no trunks are free on the final VPN link to a PBX for a call to an on-net number,
the VPN can retranslate the on-net number to a public number and route the call out
to the public network to make the final connection, provided that the PBX has a
separate link for PSTN traffic.
! Far-end break-out
This ensures that a call from a VPN user to a public network number is routed out
into the PSTN from the CS2000 closest to the destination. If one CS2000 recognises
that another CS2000 is closer to the public network destination of a call, the call is
routed through the VPN before breaking out into the PSTN at the closer CS2000.
! Far-end break-in
This call type uses dedicated DDI numbers to provide virtual VPN Points of
Presence on PSTN switches, typically for call centres. When an external caller dials
such a DDI number, the PSTN switch serving the caller routes the call to the nearest
CS2000, which then routes the call through the VPN to the real destination.

F8.2.3 VPN Services

! Speed calling
Speed calling allows a VPN end user to enter a short code to call a frequently dialled
number, instead of having to dial the entire directory number. A common list of
codes can be defined for a department, and individuals can maintain their own lists.
! Centralised attendant
A VPN serving a number of different locations can be served by a single operator
position rather than by a number of separate switchboard operators.
CS2000 supports centralised attendant call-handling capabilities via translations
and routing, e.g. defining 0 as a standard operator access code for a VPN, such that
any user on any site could dial 0 and be put through to a remote centralised attendant
with access to a complete private number directory for the VPN.
! Voice mail
Voice mail allows callers whose calls are not answered to record a message for the
called party, which can later be played back and responded to. This is preferable to
the caller having to ring again, or leave a message with someone unfamiliar with the
subject of the call. A user who is away from the office can dial in to the message
desk number to retrieve voicemails remotely.
! Conference calls
Conference calls allow a number of people at different locations, off-net at well as
on-net, to dial into a conference bridge and have a conference without the need to
travel to a meeting.
! Virtual sites
A collection of end users in the PSTN can be made to appear to be an on-net site,
by giving them a common prefix in the private numbering plan. This applies to
origination from the virtual site into a private site, and also from private sites to the
virtual site end users.
! Closed User Groups (CUGs)
Many VPN services are provisioned at a user group level rather than being assigned
to specific line terminations. This means that services can be seamlessly supported
across a range of different access types, and can be made available to authorised
users regardless of their usual or current location.
CS2000 supports both the ISDN CUG supplementary service and the proprietary
customer group mechanism. Each trunk belongs to a customer group; for calls
incoming over a trunk, the default customer group information can be overridden
with information conveyed across the network via an IBN7 or ETSI ISUP V2 trunk.

! Call screening
Call screening enables end-users to implement restrictions on the types of call that
can be made and received by departments and by individual department members,
e.g. to allow only internal calls to be made.
CS2000 supports call screening by associating a Network Class Of Service (NCOS)
value with every customer group. An NCOS value is a number in the range 0-511,
which corresponds to a particular combination of permitted incoming and outgoing
call types. Because every trunk belongs to a customer group, all call originations
from a given trunk can be screened on the basis of the associated NCOS value
before the call even enters translations (see section C3.2 on page 206 for details).
Typically, call screening is used to ensure that an end user belonging to a particular
customer group is allowed to make on-net calls only to end users in the same
customer group.
! Feature transparency
A VPN is a private network in which some parts of the network are non-dedicated
and provided on demand by the network operator. A private network interface may
need to convey additional information in order to support VPN services. Public
network protocols, however, do not directly support such information. To ensure
that VPN information is not lost when a VPN call is routed through a public
network, the service-specific information conveyed in private network messages is
encapsulated in messages that can be conveyed over the public network. ISUP
messages are used to encapsulate information from call-associated messages.
TCAP messages are used to encapsulate information from non-call-associated
messages (virtual calls).
This mechanism is called feature transparency. In ISN07, CS2000 supports two
types of feature transparency:
" QSIG Feature Transparency (QFT) is used to support a range of VPN services
for users served by QSIG End PINXs (Private Integrated Services Network
Exchanges). Over the backbone packet network, bearer QFT (for real calls) is
supported by ETSI ISUP V2+ signalling encapsulated in SIP-T, while
non-bearer QFT (for virtual calls) is supported by TCAP NCAS
(Non-Call-Associated Signalling) conveyed between CS2000 USPs using
TCAP / SCCP / MTP3 / M2PA / SCTP / IP.
" DPNSS Feature Transparency (DFT) is used to support VPN services based
on PBXs served by the UK VPN interface DPNSS, as described in Chapter
E6: DPNSS Interface. DPNSS signalling is encapsulated in
manufacturer-specific operations at the Westell gateway that controls the
DPNSS PBX, and is conveyed over the backbone network using IBN7 ISUP
trunks for which the DFT option has been specified.

F8.2.4 Flexible Translations and Routing

F8.2.4.1 Modifying Translations on a Per-Call Basis
CS2000 not only supports translation selectors that determine the destination of a call on
the basis of the digits in the called party number, but also a number of other selectors that
can be used to modify the translations process on the basis of other information provided
in the IAM or SETUP message, as follows:
! Calling Party Category (CPC) routing
! Routing / translation based on Called Party Number elements
This feature makes it possible to route (translate) based on elements of the Called
Party Number parameter. For PRI and QSIG, the elements used are the NPI and
TON; for ISUP and TUP, the NPI and NOA are used.
! Charge category routing
CS2000 can determine the charge category of a call and route the call on this basis.
See section C3.5.4 on page 213 for a more detailed description.
F8.2.4.2 Conditional Routing (Route List Manipulation)

CS2000 route lists support conditional routing on the basis of the following criteria (see
section C3.7.2 on page 219 for a more detailed description):
! Static criteria
" Least Cost Routing (LCR)
Routes are tried in increasing order of cost.
" Time Of Day (TOD) routing
This capability allows or denies route choices based on the time of day, to take
maximum advantage of low tariffs. Route choices can also be based on the
day of the week or the day of the year.
" Percentage / random conditional routing
Allows a network operator to distribute calls in any chosen proportion,
between two or more different long-distance carriers.
! Call-related criteria
" NCOS (Network Class Of Service) routing
Conditional routing based on customer group NCOS allows for flexible
screening of class of service values at the routing stage of the call.
" Bearer Capability (BC) routing
This ensures that the only routes tried are those that can support the bearer
capability required for the call.
" NRR (Network Re-Routing)
If a call routed out over an ETSI ISUP or IBN7 trunk encounters congestion,
NRR allows CS2000 to make another attempt to route the call.
See section C3.7.2.4 on page 221 for a more detailed description.
F8.2.4.3 Codec Selection via Translations

CS2000 allows the codec used for a call to be determined during translations, as described
in section C3.6 on page 216.

F8.3 Protocols Used for VPN

F8.3.1 Access Signalling Support
F8.3.1.1 Direct PBX Access

CS2000 supports direct access to packet-based telephony VPNs via a dedicated physical
connection between a PBX and a media gateway under CS2000 control. A
CS2000-controlled media gateway can support either of two direct access configurations
for the PBXs it serves:
! Two links, one supporting PSTN access for the PBX and one dedicated to VPN
calls. With dedicated VPN access, no changes are required to the customer's
existing PBX network to switch from a private leased line configuration to using a
VPN service. For incoming calls to the PBX, the PSTN link can be used as an
overflow when all VPN circuits are busy.
! A single link, providing shared access for both VPN and PSTN call traffic. With
shared access, end users who could not previously afford private leased lines can do
so by sharing their existing PSTN access trunks with VPN traffic.
CS2000 supports direct PBX access to VPNs over the following interfaces:
! ISDN access via the ISDN Primary Rate Interface described in Chapter E4: PRI
Access Interface. For details of the services that can be supported over PRI and
networked over ETSI ISUP, see Chapter F4: ISDN Supplementary Services.
! QSIG access via the QSIG interface described in Chapter E5: QSIG VPN
Interface. QSIG incorporates the Generic Functional Protocol (GFT), which
provides generic support for conveying service-specific Application Protocol Data
Units (APDUs), and is used in QSIG Feature Transparency (QFT).
! DPNSS access via the DPNSS interface described in Chapter E6: DPNSS
Interface. For details of the services that can be supported over DPNSS and
networked over IBN7 DFT (DPNSS Feature Transparency) trunks, see Chapter F6:
DPNSS Features.
F8.3.1.2 H.323 Access

implementation of multimedia services supporting the integration of voice, video and data
applications. It is important because, as an open interface, it enables such multimedia
services to be implemented in multi-vendor networks. See Chapter D5: H.323 for a
detailed description.
In ISN07, CS2000 can use H.323 to support VPN access for end users served by a variety
of CPE gateways and similar units, including third-party units, as follows:
! IP-enabled Meridian 1 PBXs
! IP-enabled Business Call Manager (BCM) PBXs
! CSE1000 Call Server for Enterprise
! Westell DPNSS gateways (for VPN access from DPNSS PBXs)
! Cisco 2600/3600 access routers

F8.3.1.3 CentrexIP Remote Client Access

CS2000 supports access to VPNs for CentrexIP remote clients controlled by the
CentrexIP Client Manager (CICM) as described in Chapter B4: CentrexIP Remote
Clients and the CentrexIP Client Manager (CICM). Two types of client are supported:
! Etherset clients
! Soft clients
a screen-based GUI.
Both types of CentrexIP client are connected to customer LANs or enterprise networks by
means of an Ethernet connection that supports both VoIP and data access. The ability to
support telephony over customer LANs makes it possible to define a telephony VPN as
an overlay on top of a corporate data VPN, using the LAN as a single delivery vehicle for
integrated voice and data services.
F8.3.1.4 Line Access

In addition to supporting VPN for users served by PBXs, CS2000 supports Centrex,
which makes the full functionality of a large PBX available to lines served by CS2000 line
media gateways. This offers the following advantages to customers:
! No need to invest in the installation and maintenance of PBX hardware.
! The ability to choose an appropriate set of features from a much wider range than
even large PBXs can support.
! Automatically benefiting from upgrades to CS2000 capabilities.
! Integrated access
Users can be served by line media gateways attached to customer LANs, in which
case the telephony VPN is handled as another data service and there is a single
access connection.
Centrex VPN can provide Centrex feature transparency across the lines and remote sites
served by a single CS2000. See Chapter F2: Analogue Subscriber Line Services for
descriptions of the features available. Selected Centrex features can also be networked
using IBN7 (ANSI ISUP+) or ETSI ISUP V2 trunks.
CS2000 supports the following types of analogue line access in ISN07:
! Lines supported via large carrier-located line gateways
In ISN07, CS2000 supports the MG9000 as a high-capacity media gateway for
analogue lines and ADSL (Asymmetrical Digital Subscriber Line) access.
! Lines supported via gateways attached to customer LANs
Note: The ability to support telephony over customer LANs makes it possible to
define a telephony VPN as an overlay on top of a corporate data VPN, using the
LAN as a single delivery vehicle for integrated voice and data services.
! Lines supported via MTA line gateways attached to cable access networks
! Lines supported via V5.2 Access Networks subtending PVGs configured as V5.2
gateways

A CS2000 running ISN07 can support Centrex as well as PBX-based VPN capabilities,
allowing customers to choose the solution best suited to their requirements for
connectivity and advanced services. A given customer may use both VPN and Centrex to
implement a hybrid VPN. In this case, integration between VPN and Centrex capabilities
is provided by the customer group mechanism. Basic VPN capabilities are provisioned at
a customer group level; additional Centrex services can be provisioned either for
customer groups or for individual users.
F8.3.1.5 Switched Access (Indirect Access)

For end users who do not have a direct PBX or line connection, CS2000 supports switched
access to packet-based telephony VPNs via the following types of CCS7 trunk:
! ETSI ISUP (V1, V2 and national variants of both)
! Australian ACIF G.500 I-ISUP and Telstra CA30 ISUP
! Japanese Interconnect ISUP (JI-ISUP)
! UK ISUP (based on ETSI ISUP V3)
! SPIROU (French ISUP V3)
! IUP / BTUP
! SSUTR2 / FTUP
For further information about these interfaces, see Chapter E2: CCS7 Interfaces.
Access can be authorised either on the basis of the CLI provided for the incoming call or
on the basis of an explicitly dialled authorisation code (authcode), as summarised below
and described in detail in Chapter F11: Indirect Access.
! For users who always access VPN services from the same location, VPN access can
be screened on the basis of the Calling Line Identification (CLI) of the calling
telephone. If the CLI is registered, CS2000 will allow calls to be made.
The caller enters a short VPN access code followed by a destination DN. At the
CS2000, the CLI is checked against table DNSCRN to determine whether VPN
access is permitted. Once access has been authorised, business group data is
populated with the CUSTGRP and NCOS datafilled against the CLI in table
DNSCRN. Retranslation then takes place based on the new CUSTGRP and NCOS.
! The Authcode method of indirect VPN access can be used to support roaming
access. The Authcode and PIN can be entered from any public telephone, allowing
a corporate VPN to be accessed from anywhere in the world.
When the user dials a unique VPN access code from any telephone, the call is routed
by the PSTN to the nearest VPN node. At this point, the user is presented with a
second dial tone. Using a DTMF telephone or a hand-held tone generator, the user
dials an authorisation code (user ID) and personal identification code (password).
Successful authorisation gives the caller access to the appropriate VPN dial plan.

F8.3.2 Network Signalling Support

The packet network implementation of CCS7, which is described in section E2.2.2 on
page 373, combines selected CCS7 user parts with packet network transport mechanisms
to provide a network interface between peer CS2000s across the packet network. MTP is
not used. Instead, ISUP and TUP messages are conveyed encapsulated in SIP-T messages.
A CS2000 with a USP can also support TCAP NCAS (Non Call Associated Signalling)
with remote CS2000s via the backbone packet network. The protocol stack used for this
is TCAP / SCCP / MTP3 / M2PA / SCTP / IP. This allows services that rely on such
messaging (e.g. CCBS) to be supported. See Figure 92 on page 373 for an illustration of
the protocol stack and configuration used to support TCAP NCAS with remote CS2000s.
Packet network bearer connections (media streams) corresponding to SIP-T signalling
sessions are established between media gateways controlled by originating and
terminating CS2000s. They are not directly handled by the CS2000, and are therefore
outside the scope of this document. CS2000 GWCs are, however, responsible for relaying
SDP session descriptions between the originating and terminating media gateways, and
for controlling gateway operation via device/media control signalling.
F8.3.2.1 Open Interface Support: ETSI ISUP

CS2000 supports open VPN trunk signalling based on ETSI ISUP V2+ and ITU TCAP.
Over the backbone packet network, ETSI ISUP V2+ signalling is encapsulated in SIP-T,
while TCAP NCAS (Non-Call-Associated Signalling) is conveyed between CS2000
USPs using TCAP / SCCP / MTP3 / M2PA / SCTP / IP.
The ETSI ISUP Application Transport Mechanism (APM)

The ETSI ISUP V3 APM (Application Transport Mechanism) has been defined by the
ITU-T to serve as a general-purpose service support mechanism. This is supported by the
CS2000 implementation of ETSI ISUP V2 (which is therefore sometimes referred to as
ETSI ISUP V2+). It provides support for the key VPN capability of private numbering
plans, and also allows service-related information to be conveyed transparently across the
network.
The ETSI ISUP V2+ APM comprises the following ISUP protocol elements (there are
similar TCAP elements for circuit-independent calls):
an APP.
to convey an APP.

Use of APM with Proprietary Access Interfaces and Services

The information that can be conveyed in an APP depends on the application context,
! Open application contexts defined by standards bodies.
The most important open application context is QFT (QSIG Feature Transparency),
which is defined as application context 1 (PSS1). The QFT information model
provides definitions for a range of common data types that are widely used in
supporting services. Use of the APM with QSIG is referred to as bearer QFT (QSIG
Feature Transparency). CS2000 uses QFT data types not only to support the
networking of QSIG services, but also to support equivalents of the following
Centrex services:
" Calling Number Display
" Connected Number Display
" Call Pickup
" Calling Name Display
" Called Name Display
" Networked Message Waiting Indicator
" Network Ring Again
" Call Forward
" Call Transfer
" Call Completion via Attendant
CS2000 also uses APM application context 3 (AOC) to support the ETSI ISDN
supplementary service Advice Of Charge (AOC). AOC-related signalling
information is encapsulated in accordance with the principles and rules defined in
Q.765.1 and EN 301 062-1.
operators to define information models to support their own services. Such
proprietary application contexts are used when the service-related information to be
conveyed cannot be mapped on to data types in the QFT information model. The
QFT option must, however, be assigned to the trunks used.
The UK regulator has reserved application context 124 for Nortel use. In ISN07,
application ID 3 in this context is used to support NETINFO. The Network
Information (NETINFO) parameter can be included in call setup messages to
provide the following subscriber details for use in setting up translations:
subscriber can make and receive (see section C3.2 on page 206 for details).
NETINFO is a proprietary alternative to the the QFT BGID (Business Group ID)
parameter, which can convey only customer group information, not NCOS values.

Use of APM with ISDN Access Interfaces

The ETSI ISUP V2+ APM provides support for the key VPN capability of private
numbering plans, and also allows service-related information (typically provided in
Facility or Notification IEs over the access interface) to be conveyed transparently across
the network.
For each incoming call over QSIG or PRI, CS2000 analyses the CdPN IE in the SETUP
message to determine whether it conveys a public network number or a private number.
The decision can be based on either of two criteria:
! Prefix digits, specifically the absence of a PSTN breakout prefix digit or
trunk/international prefix digit.
! The value of the Numbering Plan Indicator (NPI) field in the CdPN IE, which
should indicate E.164 (public network number) or private (private numbering plan,
i.e. VPN).
If the CdPN identifies a private network number served by another node, the call is
handled as a VPN call. CS2000 seizes an outgoing ETSI ISUP V2 trunk, and initiates
bearer QFT call setup by sending an IAM with the following number parameters:
! The CdPN conveys the public routing number of the destination node; the CgPN
conveys the public network CLI of the calling party (which may be a
datafill-defined default).
! The APP conveys the private destination number and the private calling party
number, as received in the incoming SETUP message. The APP also conveys the
calling partys business group ID.
The destination node completes the call using the private destination number in the APP.
If CLIP is active for the called party, the private calling party number in the APP is
provided if both parties belong to the same business group; otherwise, the public network
CLI is provided.
The ACM sent back in response to the IAM also contains an APP. This conveys no user
information, but its presence in the ACM indicates that the terminating CS2000 can
support feature transparency.
Subsequent messages can use the ETSI ISUP V2+ APM to convey service-related
information (typically provided in Facility or Notification IEs over the access interface)
transparently across the network to support supplementary services.

Figure 146 illustrates the message flow for a call made from an PRI originator to a private
number. The originating CS2000 recognises this as a VPN number served by another
CS2000. An ETSI ISUP V2+ call is therefore set up to link the two CS2000s and convey
the private information.
Originating Originating Terminating Terminating

PBX CS200 CS200 PBX
ETSI PRI or QSIG ETSI ISUP V2+ signalling ETSI PRI or QSIG
signalling for QFT support signalling
Terminating CS2000
determines whether
originating and terminating
CdPN in IAM is the result of translations. PBXs belong to the same
CgPN in IAM is the result of screening. business group, i.e. have
the same BGID
SETUP IAM with APP
CdPN = 565123
NPI = private CdPN = 7545960000 SETUP
TON = unknown NPI = private
TON = unknown CdPN = 565123
CgPN = 424242 NPI = private
NPI = E.164 CgPN = 691234242
TON = unknown
TON = national NPI =E.164
TON = national CgPN = 424242
NPI = E.164
APP TON = national
CdPN = 565123
NPI = private Because originating and
CdPN and CgPN TON = unknown terminating BGIDs match,
in APP are those CdPN and CgPN
provided by the PBX CgPN = 424242 in SETUP are those
NPI = E.164 provided by originating PBX
TON = national
BGID is obtained
from CS2000 datafill BGID = 87654321
CALL PROCEEDING
ACM with APP
CALL PROCEEDING
APP
APP with no user
info sent to indicate
support for VPN FT
ALERTING
CPG
ALERTING
CONNECT
ANM
CONNECT
Figure 146: ETSI ISUP V2+ support for VPN private numbering

F8.3.2.2 Semi-Proprietary Support: IBN7 ISUP
NETINFO
IBN7 ISUP supports the use of the Network Information (NETINFO) parameter in call
setup messages to provide the following VPN information:
! The customer group to which the caller belongs, which determines the availability
of services provisioned against the customer group.
! The Network Class Of Service (NCOS) of the customer, which determines the types
of call that the subscriber can make and receive (see section C3.2 on page 206 for
details of NCOS screening).
DPNSS Feature Transparency (DFT)

DPNSS features can be indirectly supported via DPNSS Feature Transparency (DFT),
using two types of signalling:
! DPNSS real calls (circuit-dependent) are supported over ISUP trunks
! DPNSS virtual call (circuit-independent) are supported over TCAP trunks
The main requirement for DFT is to be able to completely reconstitute the DPNSS
information at the CCS7 ISUP/TCAP end nodes so that full DPNSS functionality is
provided. Any information that can be uniquely mapped between DPNSS and CCS7
messages, and therefore can be completely reconstituted, is interworked. Any DPNSS
information that cannot be uniquely mapped, but that can be used to set appropriate CCS7
parameters, is used for this purpose, but is also carried transparently within the CCS7
message. Any DPNSS information that has no relevance at all to the CCS7 message is
carried transparently within the CCS7 message.
optional parameter, this can simply be discarded if an end node does not recognise it. The
NTP containing the HNIP can be conveyed in ISUP call control messages. It can also be
conveyed in an unsolicited information message (INF) within a Pass-Along Message
(PAM).
E1 carriers. These carriers are terminated on a Westell iQ2030 Series gateway under the
control of a H.323 proxy GWC located on the CS2000 CS LAN. Within the CS2000
network, DPNSS Level 3 signalling is conveyed via a number of different lower-level
protocols, as follows:
DPNSS information conveyed transparently in Westell-defined operations

on to QSIG equivalents. The operations containing DPNSS signalling are extracted
from H.225 UUI IEs and encapsulated unmodified in QSIG Facility IEs.
! For nodal support of DPNSS Feature Transparency, the CS2000 Core uses
QSIG-to-QSIG interworking to support direct interworking of encapsulated
DPNSS for two PBXs served by the same CS2000. For networked DFT support, the
Core interworks QSIG and DFT trunks and maps QSIG Facility IEs on to Nortel
HNIPs conveyed in ANSI-defined NTPs, thus enabling DPNSS signalling to be
conveyed transparently across the QSIG/DFT interworking.
See section E6.2.1 on page 485 for a detailed, illustrated description of the network
configuration. For a detailed formal definition of DPNSS feature support via IBN7 DFT
trunks, see the Nortel Networks SIM specification DPNSS IBN7 Feature Transparency
(NIS A267-1).
Virtual Facility Groups (VFGs)

IBN7 VFGs (Virtual Facility Groups) are a mechanism for allowing customer groups to
share their dedicated capacity, such that one groups outgoing calls can make use of a
related groups capacity if all their dedicated capacity is busy. This reduces the amount of
dedicated capacity that has to be provided for each customer group, and minimises the
amount of traffic that incurs call charges because it has to make use of public capacity.
VFGs can be defined to connect customer groups on the same CS2000, or to make use of
shared trunk groups supporting distributed customer groups, as follows:
! VFGs for customer groups on one CS2000
A number of related customer groups served by the same CS2000 can be linked by
means of VFGs (each link is actually a pair of one-way VFGs). At an originating
node, such VFGs make LCR available to the groups; this enables one group to use
another groups leased capacity for the long-distance part of the call. At a
terminating CS2000, such VFGs allow LCR to be used to break out into the PSTN
from the customer group that is nearest to the destination and therefore cheapest.
! VFGs using shared trunks
A VFG can be mapped on to a shared trunk group between CS2000s. Such trunk
groups are defined as DPTs (Dynamic Packet Trunks) served by SIP-T GWCs. The
DPT selected for a VFG call is dynamically provisioned as a SIP-T IBN7 trunk
when selected. Two types of VFG trunk route can be set up:
" A route corresponding to packet network capacity reserved for a VPNs, which
provides bandwidth with no per-call billing for VPN traffic.
" A route corresponding to the spare capacity associated with the shared trunk
group, which is used to provide extra bandwidth on demand for VPN traffic
that overflows when the reserved capacity has been used. Calls are still routed
within the VPN, and IBN7 ISUP signalling is still available to provide
networked service support, but each call is billed individually.
When a call is to be routed out over a VFG using shared IBN7 trunks, the NETINFO
option in table VIRTGRPS determines whether the customer group / NCOS of the VFG
group is used in the NETINFO parameter in the IAM instead of those associated with the
call origination. Using the VFG data will enable the terminating node to identify the VFG
used to route the call.

F8.3.3 Summary of VPN Trunk and Access Signalling Options

Table 58: ISN07 support for VPN capabilities using different
combinations of access interfaces and backbone network signalling
ETSI ISUP V2+ with ETSI ISUP V2+ with only

Backbone networks AC=124 (Nortel) AC=1 (QFT/PSS1)
IBN7 ISUP
Can convey customer Can convey customer

Can convey customer
Access group and NCOS via
group (but not NCOS) via
group and NCOS via
interfaces NETINFO [1] parameter NETINFO parameter in
BGID [1] parameter
conveyed via AppID=3 call setup messages
IBN line Interworking supported

Customer group and Interworking supported Interworking supported
(analogue, Selected Centrex features
NCOS from datafill Full Centrex support Full Centrex support
V5.2 PSTN) supported
Interworking supported
CentrexIP Customer group and Interworking supported Interworking supported
client NCOS from datafill Selected Centrex features
Full Centrex support Full Centrex support
supported
Customer group and Interworking supported Interworking supported
PRI Some supp. services
NCOS from datafill Supp. services supported Supp. services supported
supported
Interworking supported Interworking supported
Customer group and Some supp. services
QSIG Supp. services supported Supp. services supported
NCOS from datafill supported
QFT supported QFT supported
QFT not supported
Customer group and Interworking Interworking Supplementary services
DPNSS
NCOS from datafill not supported not supported supported
DFT supported
CLI-based indirect access

Customer group and Interworking not supported
NETINFO correctly NETINFO correctly
NCOS determined by table
generated generated
DNSCRN
Indirect Authcode access

access via Customer group and
NETINFO correctly Interworking not supported NETINFO correctly
ETSI ISUP, NCOS determined by table
BTUP, generated generated
AUTHCDE
FTUP
Calling card access via
MCCS (EISUP V2 only) Interworking supported Interworking supported
Customer group and NETINFO correctly Interworking not supported NETINFO correctly
NCOS determined by table generated generated
TCNFAST
[1] The NETINFO option in universal translations tables xxCODE/xxHEAD causes AC=124 to be used and
NETINFO to be generated, instead of AC=1 and BGID.

F8.4 Interaction with MCS5200 to Support VPN

F8.4.1 MCS5200 Overview
The MCS5200 Multimedia Communications Server is a peer MGC on a par with CS2000.
It can be deployed as a stand-alone solution in its own right. It can also, however, be
deployed as part of a complete Succession solution involving both MCS5200 and
CS2000. In this case, the MCS5200 LAN is typically co-located with the CS2000 CS
LAN and configured as a pair of additional VLANs. See Chapter B6: Multimedia
Communication Server (MCS52000) for details.
as intermediaries between MCS5200 and remote clients of the following types:
! Remote IP telephony clients such as i2004 Ethersets.
! Remote Web clients to permit browser access to multimedia servers.
! Remote multimedia clients such as SIP PC clients and SIP IP phones.
Interworking with MCS5200 enables CS2000 to support calls to/from MCS5200 SIP
clients and to support selected services on those calls. In protocol terms, CS2000 and
MCS5200 are peer entities, and communicate with each other by means of SIP.
From a VPN perspective, all MCS5200 clients directly connected to the MCS5200 LAN
can be viewed as having direct access to VPN capabilities. MCS5200 clients accessing
the LAN/WAN remotely (via a modem) are treated as having direct access once the data
connection has been established. SIP subscribers roaming to another location (e.g. other /
foreign site LAN) and remotely registering with their home SIP proxy server are also be
treated in the same way. SIP clients are assumed to be part of a VPN customer group (IP
domain). Indirect access to CS2000 VPNs by SIP clients is not supported.
F8.4.2 Communication between CS200 and MCS5200

Communication between CS2000 and MCS5200 is based on a version of SIP with the
following characteristics:
! No encapsulated CCS7 messages are included in the SIP messages. Instead, the
CCS7 meaning of each SIP message must be inferred from the message header and
parameters. For this purpose, three parameter enhancements are supported:
" Support for Via: parameter that specifies the protocol stack used, originating
node name and branch identifier.
" Enhancement to the URL format used in To: and From: parameters to allow
a SIP URL consisting of a telephone number and user=phone to be specified.
The SIP URL is included in angle brackets to distinguish it from the
remainder of the parameter line, which allows other information to be
provided as well. This is referred to as "name-addr" functionality.
! The only CCS7 protocol that can be emulated is IBN7 (ANSI ISUP+).
See Chapter D2: SIP and SIP-T for further information.

F8.4.3 Common CS2000 / MCS5200 Dial Plans

Support for VPNs based on both CS2000 and MCS5200 implies support for common dial
plans. These must be separately provisioned on CS2000 and MCS5200.
Each dial plan is based on a customer group. CS2000 and MCS5200 inform each other of
the customer group by means of the X-Nortel-Profile header. In the CS2000, the header
maps to a trunk group, while in the MCS5200 it maps to a domain.
Because there is no physical limitation on number of calls per trunk over the packet
network, CS2000 can be provisioned to have only one customer group per trunk group.
As the X-Nortel-Profile header is set to the trunk group for the outgoing call, translations
for calls from CS2000 to MCS5200 must ensure that calls from a particular customer
group are routed to the MCS5200 via a SIP trunk group with the same customer group.
The X-Nortel-Profile header does not carry NCOS information, so if different NCOSs
are required they must be implemented by means of different customer groups. In
practice, this may not be necessary if the call server originating the call checks that the
user has permission to access the dialled number prior to routing the call over SIP-T.
If no X-Nortel-Profile header is present for a call, the dialled number is taken to be a
public number.
Note: As MCS5200 is not aware of the location of its clients, the dial plan is based on the
home location of the subscriber. This means that subscribers with different countries or
even towns as their home location must be in different customer groups to allow correct
translations to be achieved.
F8.5 Order Codes for VPN
Table 59: Order codes for VPN software

VPNW0002 VPN over ETSI ISUP
VPNW0003 VPN over IBN7 ISUP

Chapter F9 Voice Mail
F9.1 Overview
Voice mail allows a user to have incoming calls forwarded to a message desk, to be
notified that recorded messages are waiting, and to retrieve and play back those messages
later. Its operation is illustrated in Figure 147 and summarised below:
! Leaving a message
" An incoming call to a voice mail subscriber is forwarded to the message desk,
e.g. because there is no answer.
" The caller is connected to a recording device and leaves a message.
" The message desk uses the voice mail datalink to activate the Message
Waiting Indicator (MWI) feature on the subscribers line.
! Retrieving a message
" The message waiting indicator (e.g. stuttered dial tone on basic phone) tells
the subscriber that there is a message.
" The subscriber dials a CRR (Call Retrieval Request) code to ask for the
message to be retrieved.
" If CRR billing is active, the switch generates an AMA record for the retrieval
request.
" The switch uses the voice mail datalink to send a retrieval message.
" The subscriber is connected to the message desk recording device via an
message desk voice port, and plays back the message.
" The message desk uses the voice mail datalink to deactivate the MWI feature
on the subscribers line.

Voice Mail Features and Services Communication Server Capabilities
Message desk
Stage 1:- Leaving a message interface
Message desk
CS2000
1 Incoming
call Bearer
Voice
ports
paths Recording
Speech path device
through-connected;
caller leaves
3 message
2
No answer or busy;
call forwarded
to voice mail
Voice mail
termination
termination
termination
subscriber
Voice mail datalink
Link
Link
Line
5 4
Message desk sends
Message waiting message waiting ON
indicator (e.g. notification to line
stuttered dial tone)
is activated
Stage 2:- Retrieving a message Message desk

interface
Message desk
CS2000
Voice
ports
Bearer
paths Recording
device
8 Speech path
through-connected;
message played
to subscriber
Subscriber
6 interacts with
switch to request 7 Retrieval message
message retrieval sent to message desk
termination
Voice mail
termination
termination
Line
subscriber
Voice mail datalink
Link
Link
9
Message waiting Message desk sends
indicator is message waiting OFF
10 deactivated notification to line
Figure 147: Functional overview of voice mail

Communication Server Capabilities Features and Services Voice Mail
F9.2 Voice Mail Interfaces

F9.2.1 Message Desk Interface
The message desk interface between the voice mail message desk and the switch serving
the voice mail subscriber is a dual interface that supports two types of connection:
! Voice bearer paths for the recording and playing back of messages
! A datalink for the exchange of call-independent control messages, i.e. MWI
(de)activation and message retrieval
There are a number of possible implementations for the message desk interface:
! Line / datalink implementation
" The voice bearer paths are a group of dedicated lines terminated on voice
ports at the message desk
" The datalink is an RS232-based SMDI (Simplified Message Desk Interface)
with a dedicated link termination
! ISDN PRI implementation
" The voice bearer paths are ISDN B-channels
" The control interface is provided by signalling over the ISDN D-channel,
specifically Facility IEs conveyed in call setup and clearing messages or
call-independent FACILITY messages
! Network interface implementation
" The voice bearer paths are ISUP trunks
" The control interface is provided by TCAP signalling
Note: The network interface implementation is also used to complement the other
implementations by providing networked voice mail support, i.e. to support voice
mail for subscribers served by Node A when the message desk is directly connected
to Node B.
In ISN07, CS2000 supports only the network interface implementation, and only on the
TDM-side. This means message desks connected to the TDM side of PVG trunk gateways
by means of ETSI ISUP trunks, with control signalling conveyed between CS2000 and
the message desk using TCAP signalling over a conventional CCS7 signalling network.
F9.2.2 Subscriber Interface

Like the message desk interface, the subscriber interface for voice mail must support a
voice bearer path for playing back messages and mechanisms that support MWI
(de)activation signalling and message retrieval requests.
In ISN07, CS2000 supports voice mail for all analogue subscriber line interfaces. MWI
(de)activation signalling is supported via the device/media control signalling for the line
media gateway, e.g. NCS for cable MTAs and MGCP for customer LAN gateways.
Message retrieval is achieved by the subscriber initiating a return call to the message desk
number, i.e. it does not involve explicit CRR signalling.
The method used to notify the subscriber of MWI activation is terminal-dependent. For
basic analogue subscriber lines, the standard notification method is to provide a stuttered
dial tone when the subscriber goes off-hook to make a call.

Voice Mail Features and Services Communication Server Capabilities
F9.3 Features Available to Voice Mail Subscribers

CS2000 supports a range of specific features for the use of voice mail subscribers. These
are controlled by dialling DTMF digits to select menu options and/or enter data when a
connection with the message desk has been established. They are:
! Alternative methods of message desk access:
" By dialling DN of message desk (available to all subscriber interfaces)
" Via hook-flash then feature activation code on basic analogue line, in
response to activated MWI (stuttered dial tone)
! Dialling an access code to activate immediate forwarding of all incoming calls to
message desk
! Play message (or message envelope, i.e. CLI and date/time received) from caller
! Reply to message from caller (reply all for received bulletin)
! Forward message from caller
! Delete recorded message
! Compose a greeting message to be played to callers
! Compose an outgoing message
! Create distribution list with multiple destination DNs for voice-mail bulletin
! Change password
! Context-sensitive audible help, e.g. listing options available
F9.4 Order Codes for Voice Mail
Table 60: Order codes for voice mail software

ILIN0006 Voice Mail Support

Chapter F10 Conferencing
F10.1 Overview
CS2000 supports three types of conferencing:
! Setting up three-way calls on an ad-hoc basis. Three-Way Calling (3WC) is
supported as a service in its own right. Three-way calling is also used as an
underlying capability by many other services available to residential and business
subscribers. These include Call Hold, Call Waiting, Call Transfer with Consultation
Hold, Three Way Call and Call Park.
! Setting up ad-hoc conferences with more more than three participants (this is known
as station-controlled conferencing). A subscriber who wishes to initiate a
conference first dials a conference code to find out whether there is a conference
bridge available. If so, the subscriber is connected to the bridge and a special dial
tone is played. The subscriber can then add additional parties to the bridge one at a
time, simply by dialling their numbers in response to the special dial tone.
! Setting up prearranged conferences (this is known as meet-me conferencing). A
subscriber who wishes to organise a conference contacts an adminstrator to make a
booking for a conference bridge with required number of ports. The booking
confirmation specifies the number to dial in order to join the conference, and
provides a passcode. Each participant then dials the conference number and enters
the passcode at the prearranged time.
CS2000 supports conference calls with up to 30 participants.

Conferencing Features and Services Communication Server Capabilities
F10.2 Network Configuration for Conferencing

In a CS2000 network, conferencing capabilities are provided by a media server, either the
MS2000 described in section B3.2 on page 135 or the UAS (Universal Audio Server)
described in section B3.3 on page 138. The media server provides logical conference ports
on DSP (Digital Signal Processor) cards.
For each call party who participates in a conference call, a two-way connection is set up
across the packet network between a media server port and the media gateway serving that
call partys line or trunk. When CS2000 call processing determines that a conference port
connection is required, the the Audio Controller GWC requests the media server to set up
the connection by sending it a H.248 Add command.
The first Add command for a conference call implicitly creates a new context at the media
server. Each subsequent Add command adds a new termination to this context. The media
server response to each Add command will provide a transport address (IP address and
UDP port) for the logical termination of the audio stream to/from the media gateway
serving the corresponding call party. See Chapter D3: H.248 for more information about
H.248 and its use, and especially section D3.6.3.2 on page 271, which includes examples
of H.248 commands used to set up conferences.
Figure 148 illustrates the network configuration used to support conference capabilities.
CS2000
Audio
Trunk / Controller
line (AC)
GWCs GWC
H.248 commands,
e.g. Add,
controlling
terminations and
contexts (calls)
Responses
Media gateways
supporting: Media
Trunks server
Lines
Media server supports two-way connections
across the packet network between call
parties and server conference ports
Figure 148: Network role of H.248 in supporting UAS capabilities
The maximum number of parts on a DSP card is 120. This may be less depending on
factors such as packetisation interval. For information about media servers and
conferencing capacity, see Chapter B3: CS2000 Support for Media Servers.

Communication Server Capabilities Features and Services Conferencing
F10.3 Using Conferencing Capabilities

Conferencing capabilities for calls with up to three participants can be made available to
analogue subscriber lines either explicitly (asignment of 3WC feature) or implicitly
(assignment of Call Hold, Call Waiting, Call Transfer with Consultation Hold, Three Way
Call, Call Park features). See Chapter F2: Analogue Subscriber Line Services for further
information.
Conferencing capabilities for calls with more than three participants is based on the use
of logical conference bridges, and is controlled at an administrative level.
F10.4 Order Codes for Conference Services
Table 61: Order codes for conference services software

ILIN0005 Network Line Features

Chapter F11 Indirect Access
F11.1 The Purpose of Indirect Access

Indirect access services enable alternative national operators to provide long-distance
carrier capability in competition with the PTT (or its privatised successor). Such operators
can thus compete with the PTT, by guaranteeing lower long-distance charges for both
business customers and residential subscribers, and by making value-added services
available. Indirect access is therefore extremely important in enabling alternative national
operators to establish themselves in deregulated telecommunications markets.
Indirect access is based on the principle that subscribers attached to the PTT network can
explicitly request access to the alternative operators network for the completion of their
calls. Because subscribers use existing physical connections, the alternative operator does
not have to create a complete access network.
Indirect access differs from simple network interconnect because extra call processing is
required for the following purposes:
! To verify that callers attempting to access the network are authorised to do so (see
section F11.3 for details of different types of authorisation checks).
! To ensure that the operator of the alternative network receives appropriate revenues
from calls routed through it on request (see section F11.5).
Indirect access can also be used to enable roaming or remote users to dial in to a corporate
VPN and have free or low-cost access to its standard world-wide dial plan.
To complement trunks used to support indirect access, alternative national operators use
network interconnect trunks for calls where authorisation checks are not required, e.g.
calls originating in the alternative network and terminating in the PTT network. Section
F11.2 describes possible call completion scenarios, and indicates whether indirect access
and/or network interconnect is used in each case.
Network interconnect trunks are also used by alternative local operators, typically cable
TV companies, who provide direct line and PBX connections for residential and business
subscribers in competition with the PTT. Such operators must support access to a national
long-distance network for their customers, and for this purpose they negotiate bilateral
network interconnect agreements with national operators. Such local operators do not
require indirect access services, and their use of interconnects is outside the scope of this
chapter.

Communication Server Capabilities Features and Services Indirect Access
F11.2 Call Completion Scenarios

Figure 149 illustrates possible call completion scenarios for an alternative national
operator using CS2000 indirect access capabilities to compete with the established PTT.
Network A
Call Default network, e.g. PTT
origination Call
termination
Call routed Transit
to B only if Terminating
switch switch
requested
Requested Default ingress, Egress for calls

ingress with typically for calls terminating to
authorisation terminating network A lines
checks within network B
Network B
Alternative national operator
using IP or ATM packet backbone
Media Media
gateway gateway
Ingress CS2000 Egress or

checks terminating
authorisation CS2000
CS2000 CS2000
Media Media
Call gateway gateway Call
origination termination
Figure 149: Call completion scenarios for an alternative national operator
The scenario illustrated in figure 149 and described in section F11.2.1 assumes that the
equipment belonging to a given alternative network operator is dedicated to carrying that
operators traffic and generating revenue for that operator. In some regulatory regimes,
however, it is possible for a network operator to set up a virtual network, without
equipment, by buying capacity from other operators and reselling it. CS2000s deployed
in such a regulatory regime must be able to support carrier selection, as described in
section F11.2.2, even if they are only providing transit functionality.
Note: It is also possible to support indirect access as an IN (Intelligent Network) service.
In this case, a database of user details and authorisation information is maintained
centrally by an SCP, and CS2000 initiates an IN query to the SCP when it recognises an
incoming indirect access call.

Indirect Access Features and Services Communication Server Capabilities
F11.2.1 Simple Scenarios: Indirect Access Involving One AO

For the simple network configuration illustrated in Figure 149 on page 632, the following
list describes each call completion scenario in turn, indicating in each case whether it
involves indirect access and/or network interconnect. Beginning with the most complex
and important, the scenarios are as follows:
! Call originated on default national network.
" Caller requests routing via alternative network.
" Call routed directly into alternative network on ingress interconnect, to
CS2000 that checks authorisation and performs call routing.
" If call needs to leave alternative network to reach termination, it does so on
egress interconnect to PSTN switch serving terminating line.
" Alternative network performs billing and receives most call revenue.
This is the key scenario for indirect access, involving extra signalling over the
ingress interconnect trunk to allow caller authorisation to be checked; there is no
extra signalling over the egress interconnect trunk.
! Call originated on default national network.
" No specific routing request, so call routed through default network.
" Call needs to enter alternative network to reach termination (e.g. PBX directly
connected to AO network media gateway), and is eventually routed into
alternative network on ingress interconnect, to CS2000 serving called party.
" Default national network performs billing and receives most call revenue.
There is no extra signalling over this type of ingress interconnect trunk.
! Call originated on alternative network and routed through it.
" Call needs to leave alternative network to reach termination, and does so on
egress interconnect to PSTN switch serving terminating line.
" Alternative network performs billing and receives most call revenue.
There is no extra signalling over the egress interconnect trunk.

F11.2.2 Carrier Pre-Selection (CPS): Support for Multiple AOs

In a national network where there is more than one AO, and where the capacity of a given
CS2000 may be shared between AOs, carrier preselection mechanisms are required to
ensure that every CS2000 can identify the operator who should handle a given call, and
can route and bill the call accordingly.
CS2000 supports a number of generic carrier (pre)selection capabilities for use in national
markets where this functionality is a regulatory requirement, as follows:
! Carriers are identified by means of Carrier Identification Codes (CICs) assigned by
the regulator.
! Each Communication Server has a default carrier for call originations. For CS2000,
this is specified by an office parameter.
! Each carrier selection subscriber chooses a preferred carrier, to be used as a default
for outgoing calls. For subscribers served by CS2000, default carriers can be
assigned via datafill on a trunk group or customer group basis, and can also be
assigned to individual IBN lines via the CS option. It is also possible to specify
different preferred carriers for national and international calls.
! A carrier selection subscriber can select an alternative carrier for any call by dialling
the national Carrier Access Code (CAC), then a CIC, and finally the destination
number. The dialled CIC overrides the default CIC for the line.
! CS2000 allows network operators to define up to seven different CPS call types
(plus the default/generic call type ALL). A subscriber can then choose which carrier
to use for each call type. The call type of each outgoing call is determined during
translations, which causes the appropriate CIC to be retrieved and used.
! For a call origination from a carrier selection subscriber, the IAM used to set up the
call conveys the CIC as a prefix to the Called Party Number.
Note: In some national networks (e.g. Germany), the CIC is conveyed in a separate
IAM parameter, not as a prefix to the CdPN. If the call is routed to another CS2000
in the same network, the parameter used is the Transit Network Selection (TNS)
parameter. If the call is routed to a Communication Server or switch in a different
network, the parameter used is the Carrier Selection Parameter (CSP).
! An incoming carrier selection call is routed on the basis of the CIC in its IAM. A
call may be routed in this way more than once, which allows intermediate networks
to be used in routing the call to the destination network.
When the call reaches the destination network, it is screened using the CLI
provided. Both white list screening and black list screening are supported. If
screening is successful, the call is routed through the destination network using the
original CdPN (without CIC prefix).
! The CIC is stored in a billing record.

F11.3 Different Types of Indirect Access

CS2000 supports a number of different types of indirect access. These can be categorised
on the basis of the following criteria:
! Whether access is authorised on the basis of the callers Calling Line Identification
(CLI) or on the basis of an explicitly dialled authorisation code (authcode).
! Which items of information have to be provided by the caller.
! How the caller is prompted to provide information.
A caller is prompted to provide additional information by the playing of a tone. For
TDM-side access, tones are applied in-band to the incoming TDM-side bearer channel by
the originating media gateway.
Note: In ISN07, it is not possible for indirect access services to prompt the user for
additional information by means of announcements provided by a media server.
In both cases, additional information provided by a caller when prompted is collected as
in-band DTMF digits. These are collected by the originating media gateway (or via a
TDM-side looparound), and H.248 is then used to pass the information on to the GWC.
The categorisation of indirect access services is summarised in the table below. The
different types of access are discussed in section F11.3.1 and section F11.3.2.
CLI Initial 2nd Further

Access method Table used information tone information Main advantage
checked?
provided ? provided
Access code Speed / convenience
Single- DNSCRN Yes + destination No N/A for voice calls;
stage
number support for data calls
Carrier Carrier ID + Speed / convenience
CLI- selection DNSCRN Yes destination No N/A for voice calls;
based screening number support for data calls
acces Account Account code Account code billing
s code DNSCRN Yes Access code Yes + destination for business
required number customers
MONA via Confirmation of
Destination
ambiguous DNSCRN Yes Access code Yes access to alternative
number [1]
translations network
Authorisation Support for roaming
code +
Authcode access AUTHCDE No Access code Yes access; more
destination powerful screening
number [2]
[1] The MONA feature can be set up to collect additional information, e.g. authorisation code and/or account code.
[2] Optional PIN and/or account code can also be collected between the authorisation code and the destination
number.
Note: The types of screening described above can be complemented by standard COS
screening on a trunk group basis, as follows:
! TRKOPTS option COS can specify a COS value (0-1023) for a trunk group.
! Table COSBLK specifies combinations of orginating trunk group COS and
terminating trunk group COS for which call completion will be permitted.

F11.3.1 CLI Checking via Table DNSCRN

Access to table DNSCRN is triggered when the VALIDATE feature selector is
encountered in an xxCODE or xxHEAD table in translations, e.g. PXCODE. A number
of different access codes can be used for access to a given network.
F11.3.1.1 DNSCRN Datafill

Table DNSCRN can be regarded as an on-switch database that can be easily edited to
reflect new or changed user details. It lists up to eight million CLIs for which access is
permitted [1]. For each CLI, table DNSCRN may specify:
! The name of a customer group to be associated with the incoming call, superseding
the default customer group associated with the incoming trunk. [2]
! An NCOS to be associated with the incoming call. [2]
! Whether a tone burst should be provided to the caller when an indirect access call
is answered, to indicate the start of billing. This is the Tone Burst On Answer
(TBOA) capability. For a PVG controlled by ASPEN, the in-band tone provided to
the caller is the warning tone within the call progress tone package (cp/wt), which
must therefore be defined with the correct TBOA tone characteristics.
! Validation information:
" UNPAID (CLI not in good standing)
" BLCKCALL (the subscriber is recognised, but is not permitted access)
! Carrier selection information
The DNSCRN entry for a Carrier Selection subscriber can list the carrier IDs that
the subscriber is allowed to use. Call completion is permitted only if the CIC in the
IAM matches one of the carrier IDs in this list.
! Whether an account code is required, what its length should be (maximum 18
digits), and the secondary tone to be used to prompt for it.
Note: Account codes are also referred to as Cost Centre Codes (CCCs).
Refinements to DNSCRN screening are supported by means of other tables, as described
in sections F11.3.1.4 and F11.3.1.5.
[1] Additional tables DNSCRN2 to DNSCRN7 can be used to increase the capacity of the CLI screening database.
Table DNSCRMAP determines which table is used. See section F11.3.1.6 on page 640 for details.
[2] To ensure that a replacement customer group and NCOS datafilled in table DNSCRN will come into effect for
post-screening translations, the IBNRX selector in table IBNRTE must be used to initiate retranslation (see
AJ4156 for more details).

F11.3.1.2 Indirect Access Screening Options

Three types of CLI-based indirect access have been defined. One of these is a single-stage
process; the others are refinements in which further information is collected after the CLI
has been checked. They are:
! Single-stage CLI-based access
Single-stage access is so called because the calling party provides the access code
and destination number by means of a single operation, and need not provide any
Note: This is the only type of indirect access that can support data calls, because it
is the only one that requires no in-band interaction with the caller.
! Account code required
With this method, the DNSCRN table entry for the callers CLI specifies that an
account code must be provided as well as the destination number.
! Meridian Off-Net Access (MONA) via ambiguous translations
With this method, the caller initially dials only the access code, which permits the
CLI to be checked. Translations then activates MONA, which provides a second
dial tone and collects destination digits. MONA can also be set up to collect other
information, e.g. an authorisation code and/or account code.
Access is authorised on the basis of the CLI, which is automatically provided by the
originating switch, either by default or in response to a request from the ingress CS2000;
no action is required from the calling party. See section F11.4.1 on page 644 for call flow
diagrams illustrating the signalling involved. Calls that fail CLI screening are routed to
"VPN Service Not Allowed" treatment.
Note: CLI-based access can be supported only if the calling party address is available,
i.e. if no analogue switches have been encountered before the call reaches the ingress
CS2000. If the originating switch is unable to provide the CLI because interworking has
occurred, this will be indicated in the first call setup message, and CS2000 will route the
call to treatment.
F11.3.1.3 Carrier Selection Screening

Carrier selection screening complements the single-stage CLI screening process based on
table DNSCRN, as follows:
! Each incoming carrier selection call is routed on the basis of the CIC in its IAM. If
this specifies a "foreign" carrier, i.e. it does not identify the network operator or one
of its resellers, no CLI screening takes place and the call is routed onward towards
the destination network. If the specified carrier is the network operator or one of its
resellers, CLI screening takes place because the call has reached its destination
network.
! If CLI screening is successful, carrier selection screening can be used to determine
whether the caller is permitted to have access to the specified carrier. The CS option
in a table DNSCRN entry indicates that the corresponding subscriber is a Carrier
Selection customer, and can list the carriers IDs that the subscriber is allowed to use.
Carrier selection screening compares the CIC in the IAM against the carrier IDs in
this list. If there is a match, the call is routed through the destination network using
the original CdPN (without any CIC prefix). If not, the call is routed to treatment.
As with other DNSCRN options, wildcarding is supported for the CS option, i.e. a
DNSCRN entry that provides only the first digits of a DN is taken to apply to all
DNs beginning with those digits, which makes it possible to identify a group of DDI
extensions by means of a single entry.

F11.3.1.4 Screening Services and Service Profiles

In addition to the indirect access screening options based on table DNSCRN, CS2000
supports enhanced screening based on screening services and service profiles. CLI
screening services, triggered by the CLISERV option of the VALIDATE selector, can
specify a screening service and service profile to be used in handling a call, as follows:
! Table CLISERV defines screening services, specifying a name, number and service
options for each one. Service options include:
" Partial / wildcard screening
" Route to a specified translator on screening failure
" Generate AMA record on screening failure
" Include screening information in AMA record
" Trigger service screening
Call is allowed to proceed only if CLI entry in DNSCRN includes CLISERV
option, and only if one of the services listed in the associated service profile
(see below) matches the service in the VALIDATE selector
" Use enhanced screening capabilities provided by table CLICNTL (see section
F11.3.1.5 on page 639)
" Trigger use of multiple screening tables (see section F11.3.1.6 on page 640)
" Trigger account code collection (see section F11.4.1.2 on page 645)
The maximum number of CLISERV-defined services is 32,767.
! Table CLISRVPF defines service profiles. Such a profile can list up to 16 services
and map each one on to a destination route.
Table CLISRVPF also allows the customer group, NCOS and trunk group COS
used for a screened call to be modified on a per-CLI / per-service basis, as follows:
" The CUSTMOD option specifies the customer group and NCOS to be used in
translating a screened call.
" The COS option specifies a COS value to be used in COS screening instead
of the TRKOPTS COS value.
Table CLISRVPF can also be used to trigger account code collection (see section
F11.4.1.2 on page 645).

F11.3.1.5 Enhanced Screening via Table CLICNTL

A number of screening enhancements are available via table CLICNTL. An index into
table CLICNTL can be specified either as a service option in table CLISERV or in table
TRKOPTS against the originating trunk. Each entry in table CLICNTL can be used to
control the following screening capabilities:
! Screening can be based on a number other than the CLI. The CLISCRN_OPTIONS
field of an entry in table CLICNTL can specify a list of one or more of the following
types of number in order of preference (otherwise the CLI is used by default):
" Calling Line Identity (CLI)
" Redirecting number (RDN)
" Charge number (CHARGE)
" Contractor number (CONTRACTOR)
" Generic number (GENERIC_NO)
" Presentation Number (PN)
The first specified number type that is included in the IAM (or equivalent message)
for a call is used to screen that call against table DNSCRN.
! A number other than the CLI can be captured in the billing record for a call. The
BILLING_OPTIONS field of an entry in table CLICNTL can specify a list of one
or more of the following types of number in order of preference:
" Screening number (SCRN_NUM), i.e. whatever number has been used for
screening, as selected via CLISCRN_OPTIONS
The first specified number type that is included in the IAM (or equivalent message)
for a call is captured in a type 612 module appended to the AMA record. This will
contain the actual digits plus the associated NPI and NOA.
! CLI delivery for a call can be controlled. The CLIDELV field of an entry in table
CLICNTL can specify whether a CLI should (Y) or should not (N) be delivered for
a screened call. If the CLI is to be delivered, it is possible to replace it with a list of
number types in order of preference. The list is specified in the
OUTPULSE_OPTIONS field of a separate CLICNTL entry, indexed by the
CLIOUTP option against the terminating trunk (table TRKOPTS). The number
types that can be listed are as for the BILLING_OPTIONS and the first available in
the IAM (or equivalent) will be outpulsed in place of the CLI.
Note: Table TRKOPTS can also be used to control CLI delivery directly rather than
via table CLICNTL. The CLIDELV option can be specified for a trunk termination
to indicate whether a CLI should (Y) or should not (N) be delivered, or whether
delivery should depend on the setting of the setting of the Presentation Indicator
(SCRN_PI).

F11.3.1.6 Use of Multiple DNSCRN Tables

It is possible to define and use more than one DNSCRN table, as follows:
! Additional tables DNSCRN2 to DNSCRN7 can be used to increase the capacity of
the screening database.
! The DNSCRNx tables to use in screening a call can be selected on the basis of the
type of number to be screened, as indicated by its NOA (or equivalent).
Use of these enhancements is controlled via table DNSCRMAP, each entry in which
comprises the following:
! Number type (SUB, NAT, INTL or UNKN)
Note: These are the possible values of an ISUP NOA. For other protocols, mapping
is performed to determine an appropriate NOA value.
! List of tables to be used in screening numbers of this type (DNSCRN or DNSCRNx)
! Index into table DIGMAN (optional), if digit manipulation is to be performed
before screening
Table DNSCRMAP is accessed via table CLISERV (see section F11.3.1.4 on page 638).
Note: Note: Access to table DNSCRMAP is restricted to calls where the screening
number (as defined in section F11.3.1.5 on page 639) has an NPI of E164. For all other
calls, only table DNSCRN will be used for screening.
F11.3.2 Authcode Checking via Table AUTHCDE
F11.3.2.1 Digit Collection

Authcode access is a two-stage process. The calling party provides the access code and
destination number in two separate operations. Providing the access code initiates an
authorisation sequence in which the ingress CS2000 opens a speech path back to the
calling party so that authorisation information and the destination number can be provided
in-band. See section F11.4.2 on page 649 for a call flow diagram illustrating the signalling
involved.
The authorisation code service uses the access code to select the Meridian Off-Net Access
(MONA) feature via a translations table (IBNXLA or DNROUTE). This table also
specifies the name of the dial plan to be used.
Three methods of dial plan digit collection are supported:
! DESTONLY
Only destination digits are collected
! AUTHONLY FIRST
Authcode digits are collected first, optionally followed by an account code and/or
security digits, and finally the destination digits.
! AUTHONLY LAST
Destination digits are collected first, followed by authcode digits, which are in turn
optionally followed by an account code and/or security digits.

F11.3.2.2 Dial Plan Options

For each dial plan, table DIALPLAN specifies that cut-through access is permitted only
on authorisation, and specifies the secondary tone that should be used to prompt the user
for authorisation information as Carrier Dial Tone (CDT) or Dial Tone (DT). Additional
options that may be specified for a given dial plan are:
! AUTHRAN
Allows variable-length authcodes (2-14 digits)
! AUTHPART
Allows the authcode partition associated with the callers customer group to be
overridden
! PARTIAL
Allows partial authcode screening
! CONFTONE
Causes a confirmation tone to be played to the caller after successful authcode
screening
! CUSTGRP / NCOS
Allows the csutomer group and/or NCOS associated with the caller to be overridden
! MASK
Allows authcode digits that would normally appear in the AMA record to be
masked
F11.3.2.3 The Screening Process

For two-stage access, the access code in the initial setup message may be followed by one
of the following:
! A 5-digit NNGP (National Number Group Plus) code identifying the originating
exchange. This provides a secondary level of checking to prevent fraud. If the
AUTHCDE table entry for the authorisation code provided (see below) also
specifies an NNGP code, the call attempt will be rejected if this does not match the
NNGP in the IAM or if the IAM contains no NNGP.
! A single-digit Inter-Administration Accounting Single Digit (IAASD) code
indicating the interconnect tariff band that applies to the call attempt. This is not
verified by the CS2000.
Before examining the authorisation information, CS2000 verifies that there are 5
(NNGP), 1 (IAASD) or 0 (neither NNGP nor IAASD) digits after the access code.
The authorisation code provided on a call attempt is used as a key into table AUTHCDE.
An authcode is a number of between 2 and 14 digits in length. For a given partition (or
access code), authcodes can be variable in length if the AUTHRAN option is specified in
table DIALPLAN; otherwise, they must have the same fixed length. The maximum
number of authcodes allowable per partition (access code) is 1 million.

Authorisation is successful only if there is an entry for the authorisation code provided
and only if the other items of authorisation information provided match those that are
specified as required in that AUTHCDE entry. The following types of screening are
possible:
! PIN verification (security digits)
The SECDIGS field can be used to specify a Personal Identification Number (PIN)
of up to 4 digits that must be provided. This must exactly match the PIN provided
by the subscriber.
! Account code or Customer Cost Centre (CCC) code screening
The ACCT field specifies whether a Customer Cost Centre (CCC) code of up to 18
digits (to be placed in the billing record) must be provided. If provided, a CCC is
checked for length, and may also be screened via table ACCTSCRN.
! Hotline number
The HOTLINE option and the HOTLN_NUM field can be used to specify a hotline
number for automatic connection.
Additional options that may be specified in table AUTHCDE are:
! CUSTGRP / NCOS
Allows the customer group and/or NCOS associated with the caller to be overridden
! CALLBLK
Allows calls to be blocked in spite of successful screening (e.g. if the subscribers
bill has not been paid). If required, an IBN110 log can be generated to log such a
blocked call attempt.
Two other types of screening may be enforced on a call attempt, though not directly by
table AUTHCDE:
! Region code screening
A customer group may be assigned (and thus restricted) to a particular region.
! Restricted usage screening
The Time Of Day (TOD) routing feature may be used to implement call restrictions
based on date, day or time of day.

F11.4 Supporting Interfaces and Call Flows

This section indicates which trunk interfaces can be used to support indirect access
services, and provides call flow diagrams [1] to illustrate the signalling sequences. CS2000
supports indirect access for incoming calls over:
! ETSI ISUP V1 and V2 (including national variants)
! UK ISUP
! SPIROU (French ISUP)
! Australian ACIF G.500 I-ISUP (Interconnect ISUP)
! Japanese Interconnect ISUP (JI-ISUP)
! IUP / BTUP
! SSUTR2 / FTUP
See Chapter C3: Translations and Routing for information about how dialled numbers
are translated after indirect access has been authorised.
[1] Call flow diagrams are provided only for ETSI ISUP in each case, as this is sufficient to illustrate the principles
involved.

F11.4.1 Call Flows for CLI-Based Indirect Access
F11.4.1.1 Single-Stage CLI-Based Indirect Access

Figure 150 illustrates the ETSI ISUP signalling involved in single-stage CLI-based access
to an alternative operators network over a TDM-side ETSI ISUP ingress trunk (V1 or
V2). For simplicity, only ISUP signalling is shown, not SIP-T nor GWC-gateway packet
network messaging.
Default network AO network

(TDM-based) (packet-based)
Note: One IAM
Originating shown for simplicity. Ingress
Subscriber switch Could be IAM CS2000 Onward signalling
goes off-hook followed by SAM(s). is en-bloc
PSTN dial tone

IAM (CdPN = IAM (AC discarded
AC + dest. digits) from CdPN)
USP or FLPP
Called Party
DPT GWCs and SS

Number (CdPN)
comprising Access ACM ACM
Code (AC) and ANM
destination digits ANM
ISUP messages
encapsulated
Access
GWC
Ingress in SIP-T
Network path through-connected media
gateway
Optional TBOA
Call in progress
Figure 150: Single-stage CLI-based access over TDM-side ETSI ISUP ingress trunk

F11.4.1.2 Account Code Required Access

Account code collection is initiated if it is specified as required via one of the following:
! The CLI entry in table DNSCRN
! The CLI service entry in table CLISERV
! The CLI service profile entry in table CLISRVPF
To initiate account code collection, CS2000 sends an early answer message and
through-connects a backwards speech path to collect the account code from the user
in-band. An account code is a number with up to 18 digits. The number provided is used
to support Customer Dialled Account Recording (CDAR). Other points to note:
! The answer message received by the PSTN originating switch is not generated by
the terminating node, but by a transit node (the ingress CS2000), i.e. the CS2000
performs terminating exchange functions.
! The two legs of the call (from the caller to the ingress CS2000, and from the CS2000
to the called party) are handled as two separate calls.
! The real ACM and ANM/ANS messages received from the destination exchange
are not passed on by the CS2000 when received (though they are processed by the
CS2000, e.g. to obtain the answer message charge indicator).
The FAIL2STG table allows failed two-stage calls to be handled differently from failed
single-stage calls. For example, CS2000 can provide busy notification to the caller if a
busy line is encountered on the second leg of a call, even though the first leg of the call is
in the post-ANM state.
Because this type of access requires an early answer message, it loses many of the benefits
of single-stage CLI-based access, such as fast call setup. It also means that any service
whose operation depends on the information received from the called party in the
backward direction will not function.
Figure 151 on page 646 illustrates the signalling involved in account code required access
to an alternative operators network over a TDM-side ETSI ISUP ingress trunk (V1 or
V2). For simplicity, only ISUP signalling is shown, not SIP-T nor GWC-gateway packet
network messaging.


Originating Ingress
Subscriber switch Note: One IAM CS2000
goes off-hook shown for simplicity.
Could be IAM
PSTN dial tone followed by SAM(s).
USP or FLPP
Subscriber IAM (CdPN = AC)
dials Access
Code (AC) Early ACM
DPT GWCs and Session Server

Early ANM
Network path through-connected

Ingress Onward signalling
media is en-bloc
Access GWC
Information provided in-band: gateway
Account code (CCC)
Called Party Address IAM (real CdPN)
ACM
Optional TBOA ANM
ISUP messages
encapsulated
in SIP-T
Call in progress
Figure 151: Account code required access over TDM-side ETSI ISUP ingress trunk

F11.4.1.3 MONA via Ambiguous Translations

The authorisation sequence is triggered by post-dial delay after the access code has been
dialled. The initial carrier identification digits are stripped off, and the remaining digits
trigger ambiguous translations and cause the MONA feature to be activated. The switch
sends an early answer message and uses MONA to collect dialled digits from the user
in-band. Other points to note:
! The answer message received by the PSTN originating switch is not generated by
the terminating node, but by a transit node (the ingress CS2000), i.e. the CS2000
performs terminating exchange functions.
! The two legs of the call (from the caller to the ingress CS2000, and from the CS2000
to the called party) are handled as two separate calls.
! The real ACM and ANM/ANS messages received from the destination exchange
are not passed on by the CS2000 when received (though they are processed by the
CS2000, e.g. to obtain the answer message charge indicator).
The FAIL2STG table allows failed two-stage calls to be handled differently from failed
single-stage calls. For example, CS2000 can provide busy notification to the caller if a
busy line is encountered on the second leg of a call, even though the first leg of the call is
in the post-ANM state.
Because this type of access requires an early answer message, it loses many of the benefits
of single-stage CLI-based access, such as fast call setup. It also means that any service
whose operation depends on the information received from the called party in the backward
direction will not function.
Figure 152 on page 648 illustrates the signalling involved in CLI-based MONA access
access to an alternative operators network over a TDM-side ETSI ISUP ingress trunk (V1
or V2). For simplicity, only ISUP signalling is shown, not SIP-T nor GWC-gateway
packet network messaging.


Originating Ingress
Could be IAM
IAM (CdPN = AC)
USP or FLPP
Subscriber
dials Access MONA
Code (AC) Early ACM activated
Early ANM

Ingress
DPT GWCs and SS

Onward signalling
media is en-bloc
Access GWC
Information provided in-band: gateway
Called Party Number
(other information may also be collected) IAM (real CdPN)
ACM
Optional TBOA ANM
ISUP messages
encapsulated
in SIP-T
Call in progress
Figure 152: CLI-based MONA access over TDM-side ETSI ISUP ingress trunk

F11.4.2 Call Flow for Authcode Access

Figure 153 illustrates the signalling involved in two-stage authcode access to an
alternative operators network over a TDM-side ETSI ISUP ingress trunk (V1 or V2). For
simplicity, only ISUP signalling is shown, not SIP-T nor GWC-gateway packet network
messaging.

Originating Ingress
Could be IAM
Subscriber IAM (CdPN = AC)
USP or FLPP
dials Access MONA
Code (AC) Early ACM activated
Early ANM

Ingress
media
DPT GWCs and Session Server

gateway
Authcode prompt
(secondary dial tone)
Access GWC
Authorisation information provided in-band: Onward signalling
Authorisation code is en-bloc
Optional Personal Identification Number (PIN)
Optional Customer Cost Centre (CCC) code
Called Party Number IAM (real CdPN)
ACM
Optional TBOA ANM
ISUP messages
encapsulated
in SIP-T
Call in progress
Figure 153: Two-stage authcode access over TDM-side ETSI ISUP ingress trunk
The two legs of the call (from the caller to the ingress CS2000, and from the CS2000 to
the called party) are handled as two separate calls. CS2000 sends an early ACM/ANM to
complete backward call setup and obtain the authorisation information. It then initiates
onward call setup, but does not pass on the real ACM and ANM messages received from
the destination exchange when they are received (though they are processed by the
CS2000, e.g. to obtain the ANM charge indicator).

F11.5 Indirect Access Billing

F11.5.1 Indirect Access AMA Billing
For AMA billing of indirect access to an AO network, basic call information is collected
in the x051x base record for the call for use in Inter-Administration Accounting (IAA),
as follows:
! The destination address is stored in the Terminating Open Digits field.
! If a full CLI has been received for an incoming call and an AMA record is generated
for that call, the CLI is stored in the Originating Open Digits field.
! The call connect time is stored in the Connect Time field.
! The elapsed time for the call is stored in the ElapsedTime field.
Additional AMA modules may be appended to the base AMA record for CLI-based
indirect access, as follows:
! An AMA type 046 module is appended to store either the CLI or the network point
of entry, depending on office datafill:
" Generated if option AMACLID is datafilled against the indirect access trunk.
Contains CLI of the calling party (source of charge number = 1).
" Generated if ENTRYID is datafilled against a DISA station in DNROUTE or
against a VFG in table VIRTGRPS. Contains the point of entry to the network
(source of charge number = 2).
Two module 046 records may be generated for a single call if both conditions are
met (they can be distinguished by the source of charge number).
! An AMA type 611 module with context identifier 80026 can be appended for calls
that have been screened via table CLISERV (see section F11.3.1.4 on page 638).
! For CLI-based indirect access, an AMA type 612 module with context identifier
80041 can be appended to store either the CLI or one of the other numbers specified
in section F11.3.1.5 on page 639, depending on datafill in table CLICNTL.
F11.5.2 Carrier Selection AMA Billing

Carrier selection requires an x0512 base structure record to be used. This provides a
number of additional fields (Bellcore-defined) to contain carrier selection information.
The ability to generate an x0512 record is provided by setting the office parameter
PRESEL_DEACT_X0512_BILLING (in table OFCENG) to N. An x0512 record will
then be generated for every call on which carrier selection is active. The extra fields used
for carrier selection information are:
! Originating Preselect Carrier ID
! Outgoing Preselect Carrier ID
! Significant Digits in Next Field
! Overflow Dialled Digits
! Sent Service Digits
For a carrier selection call, a type 611 AMA module with context identifier 80080 can be
appended to the base record to capture the CIC for the call, if this is specified via option
PCIBILL in tables PCIXLA and PCITRK.

F11.5.3 Network Advice Of Charge (NAOC)

NAOC implements call tariffing across network boundaries. It is designed for use in a
multi-carrier environment, where the originating node may not know the tariff that will
be applied to a given call, and must therefore retrieve this information over the network
from the node where the tariff database is located.
NAOC comprises two types of functionality:
CDP The Charge Determination Point determines the tariff to be applied to a given call.
CDP functionality is provided by the carrier network selected for the call.
CGP The Charge Generation Point, which is typically the originating node serving the
calling subscriber converts the charging information provided by the CDP into a
format that can be delivered to the subscriber.
CDP and CGP functionality can be implemented on separate nodes or on the same node.
If they are on separate nodes, charging information is conveyed from the CDP back to the
CGP using the ETSI ISUP V2+ Application Transport Mechanism (APM); the CGP
supports APM/AOC interworking for PRI call originations. If the CDP and CGP are on
the same node, internal messaging is used.
CS2000 can be used as a CDP only, a CGP only, or a combined CDP/CGP; translations
determines which role is required on a per-call basis.
Figure 154 illustrates the network configuration used to support NAOC.
Originating Selected
carrier Terminating
subscriber subscriber
network network
network
NAOC
tariff
database
CGP CDP
AOC info ISUP charge info
Figure 154: Network configuration for NAOC (separate CDP and CGP)
F11.6 Order Codes for Indirect Access

Table 62: Order codes for indirect access software
ILIN0009 Regulatory Line Features (includes Carrier Pre-Selection)
IXLS0007 ETSI ISUP V2 Carrier Selection and Preselection
CLDN0004 CLI Screening Via Translations
CLDN0003 PBX CLI Management
ILIN0005 Network Line Features (includes Authcode Access)
IIND0004 Tone Burst on Answer for Indirect Access

Chapter F12 IN Services
F12.1 Introduction
Intelligent Network (IN) standards define a number of functions (logical entities) and the
way in which they should communicate to support IN services. They do not define what
services should be provided, nor do they define (except at a conceptual level) how
services should be implemented, deployed and managed.
An IN is therefore not a feature set in its own right, but a platform for the centralised
provision of services. It allows new services to be implemented more quickly and
efficiently, since direct support needs to be provided only by a central Service Control
Point (SCP), not by every local exchange.
The protocol used for supporting services is the Intelligent Network Application Part
(INAP), which is fully described in Chapter E3: INAP. INAP operations are used to
convey service-related information across a CCS7 signalling network, between the
CS2000 Service Switching Point (SSP) and the SCP where the service logic and data
reside.
In the IN model of service provision, it is the responsibility of independent service
providers to identify what customers want, and the role of network operators is to enable
them to meet customer requirements. In practice, many network operators will choose to
design and deploy their own IN services to complement or compete with those developed
by service providers. In either case, network operators must not only support IN as defined
in the standards, but also support the rapid and efficient definition, implementation,
deployment and management of IN services. Nortel enables operators to achieve these
dual goals via CS2000 SSP support for the open INAP interface.

IN Services Features and Services Communication Server Capabilities
F12.2 Service Support Capabilities

The following sections describe different types of capability provided by the CS2000 SSP
for the support of IN services, and give some examples of services that could be
implemented using each type of capability (note that different capabilities can be
combined to support more complex services and service variants). See Chapter E3: INAP
for descriptions of the INAP operations referred to in the descriptions.
F12.2.1 Call Setup Capabilities and Potential Services

When the CS2000 SSP recognises an IN call (because the called party address is
associated with an IN service), it sends an INAP InitialDP operation asking the SCP for
assistance in completing the call. The SCP typically sends back a Connect operation
containing a complete alternative number or a replacement prefix for the number
originally dialled. Such single-stage call setup could be used to support IN
implementations of services such as Premium Rate, FreePhone and RAS (Remote Access
Service for dial-up-data).
There are some types of IN-based screening service after which call establishment
continues using the number originally dialled by the caller. Examples are CLI screening,
where the aim of the IN service is to simply check that the caller is authorised, and Local
Number Portability (LNP) screening, after which calls to non-ported numbers require no
rerouting. In such cases, the SCF sends a Continue operation instead of a Connect, which
causes the SSP to return control to the CCF/BCSM so that call processing can resume
from where it was interrupted.
If the SCP requires further information in order to complete a call (e.g. a PIN for
authorisation), it can initiate interaction with the caller in order to obtain it, e.g. by means
of a PromptAndCollectUserInformation operation. In this case, the SCP does not send the
Connect operation to complete the call until the user interaction has provided all the
information required. Two-stage call setup with authorisation information provided by
the user could be used to support Account Card Calling and Indirect Access (to an
alternative carrier or to a VPN). CS2000 support for in-band interaction with the caller is
involves the playing of announcements by an MS2000/UAS in response to CS2000
requests, and the collection of dialled DTMF digits by the originating media gateway.
F12.2.2 Announcement Services

IN services on CS2000 can play announcements at appropriate stages in the handling of
a call. If IN is being used for CLI-based call screening, for example, INAP can be used to
request the playing of an appropriate announcement if a call fails screening.
Callers can also be connected to automated services based on announcements. Variable
announcements, which are created ad-hoc from pre-recorded elements such as numbers,
could be used to support services such as balance queries for on-line banking. INAP
PlayAnnouncement operations can carry variable numerical data such as Price(1999).
Numerical data can be combined with a currency token (as defined in ISO4217) and a
language token (as defined in ISO639-2/T) and reformatted as Media Control Message
Protocol (MCMP) Money data, for use in assembling and playing an announcement that
specifies the appropriate currency and uses the appropriate language. See A19012479.

Communication Server Capabilities Features and Services IN Services
F12.2.3 Charging Control and Related Services

The ApplyCharging (AC) sent from the SCF to the SSF to provide instructions about how
billing should be performed for a given IN call can also be used to specify a maximum
conversation time, e.g. if only a limited amount is left on a calling card. This causes the
SSP to play a warning tone or announcement before the timer expires.
F12.2.4 Monitoring Capabilities and Potential Services

Before sending a Connect operation to the SSP, the SCP can send one or more
RequestReportBCSMEvent operations, each asking the SSP to monitor a specified call
processing event (e.g. routing failure, call answered, line busy, no answer). If a monitored
event occurs, the SSP sends an EventReportBCSM operation to inform the SCP. The SCP
can then take appropriate action, e.g. sending another Connect with a different destination
address. This monitoring capability could be used to support a range of call completion
services, automatically rerouting calls that encounter busy lines or are not answered.
It is also possible to monitor a completed IN call for the occurrence of a mid-call event,
specifically a call party pressing the * or # key. When this happens, the current call is
interrupted. This could allow the caller to initiate another call (call reorigination) without
the authorisation process having to be repeated.
F12.2.5 Call Party Handling Capabilities and Potential Services

The CS2000 SSP supports selected CS-2 call party handling capabilities in addition to
CS-1R IN capabilities. These allow the SCP to control the connectivity of an IN call and
the call processing of individual call legs by means of the following operations:
! DisconnectLeg
To disconnect a specified call party from a call, leaving the call to continue with the
other parties involved.
! SplitLeg
To detach a call party from an existing call into a new, separate call segment.
! MergeCallSegments
To combine two call segments into a single call.
These capabilities could be used to support call reorigination (follow-on call). If a
completed IN call is being monitored for the occurrence of a mid-call event (see section
F12.2.4), an authorised calling party can press the * or # key to interrupt the current call
and request assistance. The SCP can then allow the caller to make another call, without
the authorisation process having to be repeated. The original called party can either be
simply disconnected (basic call reorigination), or split off into a separate call segment that
can later be merged again.

Specific CPH-based services supported by the CS2000 SSP are:

! Call queueing
The SCP can request the SSP to initiate a new call attempt by sending an
InitiateCallAttempt (ICA) operation to the SSP. This general-purpose capability
is used to confirm that an IN call can be successfully completed before the caller is
connected to the destination. In the original call segment, the caller is connected to
an IP, which can provide an announcement or music on hold. Meanwhile, the
ICA-initated call attempt is made in a second call segment; if it is successful, the IP
is disconnected from the call, and the caller is connected to the destination by
merging the two segments into a single call. See A59027538.
! Call completion
Support for call interruption by the called party makes it possible for the caller to be
put on hold (typically connected to an IP providing music or an announcement)
while a call centre agent initiates routing of the call to its final destination. See
A59027538.
! Consultative call transfer
This allows a call centre agent to answer an incoming call and put the caller on hold
while another call centre agent is consulted about the handling of the call. When the
two agents have finished speaking, the first agent drops out of the call and the caller
is connected to the second agent. See A59033614.
F12.2.6 SCP-Initiated Calls and Related Services

In addition to handling calls routed to it from the SSP, it is possible for the SCP to request
the SSP to initiate a new call attempt. It does this by sending an InitiateCallAttempt
(ICA) operation to the SSP. This specifies the destination for the new call attempt, and
initiates monitoring for call completion so that appropriate action can be taken in the event
of failure.
There are two possible scenarios:
! Initiation of a call attempt in a new, null CSA created for the purpose
This is a general-purpose capability that can be used for services such as wake-up
calls, and Click2Call services that allow a user to initiate a call by clicking on a
button in a Web browser window. See A59033614 for details.
! Initiation of a call attempt within the context of an existing call
The CS2000 SSP uses this capability only in a Call Party Handling context to
support call queueing, as described in section F12.2.5.

F12.2.7 Controlling Digit Collection to Minimise Post-Dial Delay

In an overlap signalling scenario, particularly for VPN calls using a fixed-length private
number plan, the SCP can tell the SSP how many digits it needs to collect in order to
complete a call.
Initial triggering takes place on the basis of a partial called number (typically a VPN
prefix or location code), and is notified to the SCP via InitialDP. The SCP then sends a
RequestReportBCSMEvent operation to specify the required number of digits, followed
by a CollectInformation operation to tell the SSP to resume call processing. When the
required number of digits have been collected, they are conveyed to the SCP in an
EventReportBCSM, and it can respond with a Connect.
The effect is to reduce the post-dial delay attached to IN calls that originate on trunks
using overlap signalling, as routing can take place before dialling is finished.
F12.2.8 Service Filtering / Overload Control and Potential Services

The call filtering capability supported by the ActivateServiceFiltering and
ServiceFilteringReport operations allows the SCP to delegate the handling of filtered calls
to the SSP. The SSP periodically reports results to the SCP, in the form of counts of calls
made to specified numbers.
This capability could be used to support mass calling services such as TeleVoting, where
callers are invited to ring one of a range of numbers to record a preference. The numbers
are allocated temporarily and publicised, typically via TV or radio.
The related call gapping capability prevents SCP overload by limiting the number of calls
made to a particular destination or from a particular origin. This ability to limit the number
of calls handled in a specified period can be used either to manage short-term traffic peaks
or to ensure that a given level of service is maintained.
F12.2.9 Re-Triggering
The CS2000 SSP allows a call to trigger more than once as an IN call, e.g. when
translations are re-entered after initial IN call rerouting. This allows more than one IN
service to be provided for a given call.
Note: To prevent conflicts, only one SCP dialogue may be active for a given call. If
retriggering is attempted for a call when there is already a dialogue, the call will not
retrigger and will be routed to treatment.
F12.3 Creating and Deploying Services

Because CS-1R INAP, as supported on the CS2000 SSP, is a standardised open interface,
the CS2000 SSP can be used in a multi-vendor IN in which it communicates with a
non-proprietary SCP.

F12.4 Interaction between IN and Non-IN Features

Table 63 provides information about interactions between IN and non-IN features and
services, i.e. which features can be activated for an IN call.
Table 63: IN Feature Interactions

Abb. Feature Name FN Ref Notes / Restrictions
TDP2 not supported on third leg of 3WC.Three
3WC Three-Way Calling A59033609 parties cannot be in conference and have IN
active.
ACD Automatic Call Distribution A59023666 Post Answer EDPs are not supported
Automatic Call Distribution Not
ACDNR A59023666 Post Answer EDPs are not supported
Ready
ACRJ Anonymous Caller Rejection
AIN Advanced Intelligent Network
AINDN Advanced Intelligent Network DN A59039605
AR Automatic Recall A59033609
Any IN dialogue associated with the original call
Automatic Recall of Diallable
ARDDN A59038655 attempt is automatically cleared, which means
Directory Number that the return call attempt can trigger as an IN
call
AUL Automatic Line A59014056
Call Forwarding Busy Internal
CBE Calls Only A59033609
Call Forwarding Busy

CBU A59033609
Unrestricted
Call Completion to Busy
A59038655 If
the original call attempt triggered as an IN call,
CCBS
Subscriber the repeat call will also trigger
Exclude External Calls from Call
CDE Forwarding A59033609
Exclude Intragroup Calls from

CDI A59033609
Call Forwarding
Call Forwarding Do Not Answer
CDU A59033609 TDP2 not supported on any forwarded calls
Unrestricted
CFB Call Forwarding Busy A59033609 TDP2 not supported on any forwarded calls
CFD A59033609 TDP2 not supported on any forwarded calls
(Business Sets)
CFDA A59033609
(Residential)
CFDVT A59033609
Variable Timer
CFF Call Forwarding Fi A59033609
CFI Call Forwarding Intragroup A59033609 TDP2 not supported on any forwarded calls
CFIND Call Forward Indication A59033609
Call Forwarding on a Per Key
CFK A59033609
Basis
CFNR Call Forwarding No Reply A59033609 Comprises CFD and OFCENG parameter


CFRA Call Forwarding Remote Access A59033609
CFS Call Forwarding A59033609

Simultaneous/Screening
CFTANN Call Forward to Announcement A59033609
CFTB Call Forward Timed for CFB A59033609
CFTD Call Forward Timed for CFD A59033609
CFU Call Forwarding Unconditional A59033609 TDP2 not supported
CFU Call Forwarding Universal A59033609 TDP2 not supported
Feature activation supported for non-IN call, but
CHD Call Hold A59038655 not permitted for existing IN-controlled call
CLI Calling Line Identification A59010596

CMCF Control Multiple Call Forwarding A59033609
CNAMD Calling Name Delivery A59010596
CND Calling Number Delivery A59010596
CNDB Calling Number Delivery Blocking A59010596
New leg added to existing non-IN call can trigger
CNF Six-Port Conference A59038655 as an IN call. Triggering for a new leg added to
an existing IN-controlled call is permitted only if
the existing IN dialogue is first taken down.
CPS Carrier Pre-Selection
CPU Call Pickup
Reverse translations via Reverse translations can be invoked within digit
CUSTMOD CUSTMOD A00003467 analysis phase of call
CWT Call Waiting IN Dialogue aborted when call wait is activated
CXR Call Transfer A59033609 IN feature cannot co-exist with three parties all in
conference
DCF Denied Call Forwarding A59033609
DDN Dialable Directory Number
DGT Digitone
DISA Direct Inward System Access
DLH Distributed Line Hunt A59010596
DNH Directory Number Hunt A59010596
HLD Permanent Hold
HOLD ETSI Call HOLD
IECFB Internal/External Call Forwarding A59033609 TDP2 not supported for Call Forward leg
Busy
Internal/External Call Forwarding
IECFD A59033609 TDP2 not supported for Call Forward leg
Do Not Answer
LI Lawful Intercept
Although IN call must be completed before LNR
LNR Last Number Redial A59010596 works, if a call triggers and then is hung up,
previous number is used
MCH Malicious Call Hold A59010596


MCT Malicious Call Trace
MLH Multiline Hunt A59010596
Feature activation supported for non-IN call, but
MMC Meet-Me Conference A59038655
not permitted for existing IN-controlled call
MSB Make Set Busy
MSBI Make Set Busy Intragroup
MSG
Message Deactivation
DEACT
MWIDC Message Waiting Indication
MWT Message Waiting A59010596
NCOS Code Restrictions / Call Barring
PCOS Priority Class Of Service Tested for PRI only
PRK Call Park
QTD Query Time and Date
RAG Ring Again A59033609
If TDP2 is used & MDC < access code, call
SC1 Speed Calling Short List A59014056 triggers instead of activating feature
SC2 Speed Calling Long List L30 A59014056

SC3 Speed Calling Long List L50 A59014056
SCA Selective Call Acceptance A59014056
SCF Selective Call Forwarding A59014056
SCI Serving Carrier ID
SCL Speed Calling Long A59014056
SCRJ Selective Call Rejection A59010596
SCS Speed Calling Short A59010596
SDN Secondary Directory Number A59010596 Enhanced SDN (ESDN) not supported
SIMRING Simultaneous Ringing 59027838
UCD Uniform Call Distribution A59023666 Post Answer EDPs not supported
UCDLG Uniform Call Distribution Login A59023666 Post Answer EDPs not supported
Uniform Call Distribution Login
UCDLI A59023666 Post Answer EDPs not supported
Indication
WML Warm Line A59014056
F12.5 Order Codes for IN Services

Because IN services are defined by service providers or network operators, there are no
standard Nortel software order codes for them. The software order codes for the INAP
capabilities that underly IN service implementations are listed in section E3.5 on page
444.

Chapter F13 Providing Call Party
Information (CLI and
Related Services)
This chapter discusses call party information services, i.e. services that provide
information about one party involved in a call to another party involved in the call. The
most common example is CLI (Calling Line Identification), which is the provision of the
calling partys number to the called party for display. Such services are described in this
separate chapter because they are not associated with any particular interface, and are
supported to some extent not only by almost every interface supported by CS2000, but
also over interworkings between interfaces.
Note: The chapter is not intended to provide a detailed description of Malicious Call
Identification (MCI), which enables network operators to obtain calling party information
for use in dealing with nuisance calls. Although MCI uses the same mechanisms that are
used to provide calling party information for called parties, it is a regulatory service with
different national implementations, which are discussed in Chapter F14: Regulatory
Services.
The chapter is organised into the following sections:
! Section F13.1: Terminology and Basic Concepts
! Section F13.2: Party Information Services
! Section F13.3: Functional Overviews
! Section F13.4: Parameters for Conveying Party Information
! Section F13.5: Delivery of Party Information for Display
! Section F13.6: CS2000 Provisioning
! Section F13.7: Per-Interface Summary of Capabilities

Party Information Services Features and Services Communication Server Capabilities
F13.1 Terminology and Basic Concepts

This section introduces and briefly defines the most important terms and acronyms used
in the remainder of this chapter (and particularly in the functional overviews provided in
section F13.3 on page 666) to categorise and describe number/name delivery capabilities.
Note: The names and acronyms for specific party information services are separately
listed in section F13.2 on page 664.
F13.1.1 Public and Private Numbers

It is a regulatory requirement for virtually every PSTN that the Network Number (NN) of
the calling party should be available at the terminating switch. This is primarily to allow
emergency calls and malicious calls to be traced. For this reason, if the true calling party
number is not available, some alternative must be provided, e.g. a PBX attendant number
or the default number assigned to an incoming trunk.
Availability of the calling party number at the terminating switch makes it possible for
network operators to provide it to the called party for display. Such number provision is
typically offered as a chargeable service. Depending on the capabilities of the originating
switch and the network signalling system, it may be possible to provide a Presentation
Number (PN) to the terminating switch as well as the NN. A PN is the public network
number to which return calls should be made. To enhance the number provision service,
the terminating switch may therefore provide the PN to the called party for display instead
of the NN.
Note: The NN is always required at the terminating switch for regulatory purposes. If
only one number can be provided for a public network call, e.g. because the network
signalling system can convey only one number, it must be the NN.
For a VPN call, the number to which return calls should be made is the private network
number, even if the return call may in practice be routed out over a shared public network
trunk. Public network signalling systems do not support private number parameters, but
may support general-purpose parameters that can encapsulate and convey private network
numbers. The IAM for a VPN call could therefore make three types of number available
at the terminating switch:
! The NN, which must be available for regulatory purposes
! The PN, which would be available for display to a public network called party
! An encapsulated private number, which would be available for display to a VPN
called party
CS2000 allows default calling numbers to be defined for incoming trunks. This allows for
situations where no calling number is received or where the number received has to be
overridden for any reason. A number of different mechanisms are available for defining
default calling numbers for PBX trunks, as this is essential for regulatory reasons, e.g. the
DEFLTCLI option for PRI trunks. As a standardised alternative to these, feature
A59028834 provides a general-purpose mechanism that can be used to define default
calling numbers for a wide range of incoming trunk types (all ISUP variants, all PRI
variants, DPNSS and BTUP) and a variety of purposes (NN, PN, charge number).

Communication Server Capabilities Features and Services Party Information Services
F13.1.2 Party Information

Party information may be any of the following:
! Network number (NN)
An NN is an E.164 number that uniquely identifies an NTP (Network Termination
Point) involved in a call. It may be
" A subscriber DN
" The DDI (Direct Dial Inward) number of a user served by a PBX
" Default number of private network, e.g. DDI number of PBX attendant
! Presentation number (PN)
A PN is an E.164 number that uniquely identifies the NTP to which any return call
should be made. This may be the same as the NN, but the ability to specify a
different PN makes it possible to support scenarios such as:
" A calling salesperson who wishes to display a freephone number, in order to
provide the incentive of a free call when a purchase is made.
" A doctor calling from home who wishes to display the surgery number, so that
return calls are directed to the surgery, not to the home number.
Network operators control the assignment of PNs to their subscribers, and may offer
PN provision as a chargeable service.
Note: PN may be non-geographic number, e.g. FreePhone number for company
! Diallable Directory Number (DDN)
Similar to a PN, in that it is the number that should be dialled to return a call. The
difference is that a DDN may be a private network number, for a call between two
members of the same customer group.
Note: Only trunk interfaces designed specifically for VPN use (e.g. IBN7) provide
direct support for conveying private numbers over the network. Private numbers
can, however, be made available at the far end via reverse translation of public
network numbers. To convey private numbers over the public network using an
open interface such as ETSI ISUP, it is necessary to use an encapsulation
mechanism, e.g. the ETSI ISUP V2+ APM (Application Transport Mechanism)
used to support QFT (QSIG Feature Transparency) and proprietary services.
! Routing Number (LRN / N2)
Specific to the LNP service. An LRN allows calls to be returned directly to the
recipient switch serving a ported number. See A59034058.
! Name
Delivery and display of a party name with up to 15 characters is a proprietary
capability, and is directly supported only over proprietary interfaces. As with
private numbers, however, party names can be conveyed across the network using
the ETSI ISUP V2+ APM.
Network number may be categorised as:
! Network provided (NP), also known as default number
Note: An NP number may be a network number or a presentation number
! User provided and verified (UPV), i.e. the most significant part is provided by the
network, while the least significant part is provided by the user, but has been
checked by the network for length and range
! User provided, not verified (UPNV)

Party information may be categorised as:

A Available
W Withheld, i.e. not available for presentation because the party has requested
confidentiality (but physically present, and available for regulatory purposes)
NA Not Available, e.g. due to interworking (sometimes called Network Withheld)
Note: Some form of number must be provided in this case for regulatory purposes,
typically the number of the switch where interworking took place.
Network Numbers can be A, W or NA; Presentation Numbers can only be A or W.
Note: Not all network signalling systems can distinguish between numbers that are
Witheld and numbers that are Unavailable / Network Witheld. UK ISUP and BTUP
support this capability at present; ETSI ISUP will support it in the future. Where this
distinction is not available, care must be taken to ensure that services such as Anonymous
Caller Rejection do not erroneously reject Unavailable calls.
F13.1.3 Call Parties

Information can be provided about the following call parties (see section F13.3 on page
666 for illustrated functional overviews of what is involved):
! The caller or calling party
Terms used:
CLI Calling Line Identification
Caller ID Calling Line Identification
OLI Originating Line Identification
CgPN Calling Party Number
CGN Calling Number (ISDN)
LRN Local Routing Number (LNP)
Note: These terms all refer to numbers; no acronym for calling party name is in
general use.
! The called or connected party (the distinction is that the connected party, who
actually answers a call, may not be the original called party)
Terms used:
CdPN Called Party Number
COL Connected Line Identification
TLI Terminating Line Identification
CNN Connected Number (ISDN)
! A redirecting party, i.e. an original called party for whom a service such as Call
Forward or Call Transfer is activated.
After redirection, the following terms are used (there are no corresponding
acronyms):
" Redirecting number, which is the number originally called
" Redirection number, which is the new called number to which the call is
redirected

F13.2 Party Information Services

There are three types of party information service:
! Internationally standardised (typically by ETSI)
! Standardised by national regulatory bodies
! Proprietary (for CS2000, this includes Centrex and CLASS features)
The following list defines acronyms used to identify some specific implementations of
different types of party information service:
! Number delivery:
CLIP Calling Line Identity Presentation (generic / ETSI)
COLP Connected Line Identity Presentation (ETSI)
CND CLASS Calling Number Delivery (fixed-length 10-digit number)
DDN CLASS Diallable Number Delivery (up to 24 digits)
! Number blocking (permanent and per-call):
CLIR Calling Line Identity Restriction (generic / ETSI)
COLR Connected Line Identity Restriction (ETSI)
CNDB CLASS Calling Number (and Name) Delivery Blocking
CNDBO Calling Number Delivery Blocking Override
Not a residential feature; intended for administrative purposes.
! Name delivery:
CNIP Calling Name Identification Presentation (generic / ECMA)
CONP Connected Name Identification Presentation (generic / ECMA)
CNAMD CLASS Calling Name Delivery
! Name blocking (permanent):
CNAB CLASS Calling Name Delivery Blocking
! Call return service:
AR Automatic Recall
! Delivery / blocking status query service
! Anonymous call rejection service:
ACRJ CLASS Anonymous Call Rejection

Information may be:

! Available permanently
! Available permanently, but withheld for a particular call (per-call blocking)
! Withheld permanently
! Withheld permanently, but provided for a particular call (per-call unblocking)
Note: ETSI uses the term temporary mode support to refer to party information
(un)blocking that can be overridden.
Principles (mandatory in European Guidelines):
! Party information shall not be sent unless the sender has had the chance to withhold
it.
! If party information has been withheld, an indication of this fact shall be provided
instead of the party information.
Note: Similarly, an indication shall be provided if party information is not
available.
! The default / minimum level of blocking available shall be per-call blocking.
! Unnecessary activation of per-call blocking, e.g. on a line with permanent blocking,
shall not impede a call attempt.
Objectives (encouraged in European Guidelines):
! It shall be possible to query the current state of blocking on a line, by
" Dialling a service number to find out the permanent status
" Dialling a per-call (un)blocking code followed by a service number to find out
the status as modified by the (un)blocking code
! It shall be possible for subscribers to reject incoming calls for which party
information has been withheld, i.e. anonymous call rejection
Note: There is no objection to this is in principle, but it is not to be made mandatory
until/unless withheld information can always be distinguished from unavailable
information. If there is any chance that information is simply unavailable rather than
withheld, the call should be allowed to complete.
Per-call control of services is typically provided by means of dialled prefix digits defined
by the national regulator. Although the capabilities provided are essentially the same, the
particular digit strings used vary from country to country. In the UK, for example, the digit
strings defined for per-call control of party information services are:
141 Per-call CLI blocking for numbers that are available by default
1470 Per-call unblocking for numbers that are suppressed by default
1471 Call return service (anouncement gives last calling number and allows a
return call to be initiated by means of a single recall digit)

F13.3 Functional Overviews

F13.3.1 Providing Caller Information (CLI/OLI)
Figure 155 is a simplified view of the provision of calling party information.
Call origination Originating Outgoing call Terminating Call termination

switch switch
Incoming call
Party information about caller
Figure 155: Providing calling party information
F13.3.1.1 Obtaining Calling Party Information

See Table 65 on page 688 for a summary of the CLI/OLI capabilities provided for call
originations for each supported interface.
Public Network Calls

At the originating node, the issues are:
! Whether calling party information can be obtained (Y / N). If Y, then
" Type of information
# Unique CLI / NN
# PN as alternative to NN
# Non-unique / default CLI
# Name
" Derivation of information
# Provided over interface
# Obtained from switch datafill
" Control of information provision
# Permanent / default control
# Per-call control
" Support for explicit backward requests for information (Y/N)
" Support for user queries about service status
VPN Calls
The description above applies to a residential subscriber making a call over the public
network.
For VPN callers, private information may be available to complement the public network
NN/PN information.

F13.3.1.2 Delivering Calling Party Information

See Table 66 on page 691 for a summary of the CLI/OLI capabilities provided for call
terminations for each supported interface.
Public Network Calls

At the terminating node, the issues are:
! Whether calling party information can be provided (Y / N). If Y, then
# Number (as received, or reverse-translated)
# Name (as received, or derived from CLI)
" Mechanism for providing information
" Control of information provision (including support for anonymous call
rejection)
" Support for explicit backward requests for information (Y/N)
" Support for call return service (Y/N)
VPN Calls
The description above applies to a residential subscriber receiving a call over the public
network.
For VPN users, private information may be available as an alternative to the public
network NN/PN information.
F13.3.1.3 Conveying Calling Party Information through the Network

For the trunk interface, the issue for public network calls is whether the interface has a
mechanism for conveying party information (NN/PN) and any related blocking
information. For VPN calls, the issue is whether the interface supports any encapsulation
mechanism for private network information.

F13.3.2 Providing Called/Connected Party Information (COL/TLI)

Figure 156 is a simplified view of the provision of called party information.
Call origination Originating Outgoing call Terminating Call termination

switch switch
Incoming call
Party information about called party
Figure 156: Providing called party information
Logically, this is simply the inverse of the CLI scenario, but fewer interfaces support
COL-type services, so the potential capabilities of a given interface (in terms of its ability
to convey information) are often not used. This is primarily because obtaining called party
information is not vital unless some form of redirection takes place (see section F13.3.3),
because until then the number dialled identifies the called party, and this can simply be
echoed back to the caller.
Note: In some cases, e.g. IBN7 support for connected number display, no information is
provided backwards until / unless redirection takes place.
See Table 66 on page 691 for a summary of the COL/TLI capabilities provided for call
terminations for each supported interface. At the terminating node, the issues are:
! Whether connected party information can be obtained (Y / N). If Y (which implies
support for some type of COL service), then
# Unique CLI / NN
# PN as alternative to NN
# Non-unique / default CLI
# Name
" Derivation of information
# Provided over interface
# Obtained from switch datafill
See Table 65 on page 688 for a summary of the COL/TLI capabilities provided for call
originations for each supported interface. At the originating node, the issues are:
! Whether called party information can be provided (Y / N). If Y, then
# Number (as provided, or reverse-translated)
# Name (as provided, or derived from number provided)
" Mechanism for providing information
For the trunk interface, the issue for public network calls is whether the interface has a
mechanism for conveying party information (NN/PN) and any related blocking
information. For VPN calls, the issue is whether the interface supports any encapsulation
mechanism for private network information.

F13.3.3 Providing Party Information after Redirection

Figure 157 is a simplified view of the provision of party information after a call has been
redirected on encountering a feature such as Call Forward or Call Transfer.
Originating Redirecting Terminating

switch switch switch
Origination Termination
Fwd/Xfer
Info about caller
Info about redirecting party Info about caller and

and new called party redirecting party
Figure 157: Providing party information after redirection
Twin capabilities:
! Providing calling party information forward, as per section F13.3.1 on page 666,
plus indicating that redirection has occurred and providing equivalent information
for the redirecting party
Note: After redirection, the information provided for the calling party remains the
same, i.e. if a PN is provided it is this PN that will be presented to the new called
party. For the redirecting party, however, the number provided will always be the
NN rather than the PN.
! Providing connected party information backward, as per section F13.3.2 on page
668, plus indicating that redirection has occurred and providing equivalent
information for the redirecting party
A distinction must be made between support for forwarding / redirection functionality,
which is supported over most interworkings, and the provision of information about the
forwarding, for which support is more limited. In particular, it must be noted that full
interworking between Centrex and ISDN call redirection services is not supported, e.g.
notification of ISDN forwarding will not be provided over IBN7 trunks, and notification
of Centrex forwarding will not be provided over ETSI ISUP trunks.

F13.4 Parameters for Conveying Party Information

F13.4.1 ISUP
F13.4.1.1 Generic Capabilities

Calling Party Number parameter format is:
Bit
8 7 6 5 4 3 2 1
Octet
Odd/even
1 ind.
Nature of address ind.
2 NI ind. Numbering plan ind. Presentation ind. Screening ind.

3 2nd address signal 1st address signal

n Filler (if necessary) nth address signal
This format is also used for Connected Number, Original Called Number, Redirecting
Number and Redirection Number. The main functional elements are:
NOA Subscriber number
National significant number
Unknown (relay only)
NPI E.164 (only accepted value for ETSI ISUP on CS2000)
Private (not in ETSI ISUP, relay only in IBN7)
Unknown (not in ETSI ISUP, relay only in IBN7)
Note: Only trunks with VPN capabilities (e.g. IBN7) provide direct support
for conveying private numbers over the network. Private numbers can,
however, be made available at the far end via reverse translation of public
network numbers. Indirect support for conveying private numbers over the
public network requires some sort of encapsulation mechanism, e.g. QFT.
PI Presentation allowed
Presentation restricted
Address not available (not in EISUP V1, relay only in IBN7)
SI Network provided (NP)
User provided, verified and passed (UPVP)
User provided, verified and failed (not in EISUP V1, relay only in V2)
User provided, not verified (relay only in EISUP V2)
(Note: SI bits are Spare in IBN7)

F13.4.1.2 Additions Common to IBN7 and ETSI ISUP V2

ETSI ISUP V2 supports the use of the Generic Number parameter to convey an additional
number associated with a call party. Its format is:
Bit
8 7 6 5 4 3 2 1
Octet
1 Number qualifier indicator (NQI)
Odd/even
2 ind.
Nature of address ind.
3 NI ind. Numbering plan ind. Presentation ind. Screening ind.


This is identical to the Calling Party Number parameter format, except for the extra octet
at the start, which indicates the type of additional number being provided.
NQI Additional called number
Additional connected number
Additional calling party number
Additional original called number
Additional redirecting number
Additional redirection number
IBN7 and ETSI ISUP V2 use this parameter with NQI indicating "additional calling party
number" to support the conveying of a Presentation Number, if available, in addition to
the Network Number (which is conveyed in the CgPN parameter).
F13.4.1.3 IBN7 ISUP Additions

IBN7 Party Information parameter format (proprietary) is:
Bit
8 7 6 5 4 3 2 1
Octet
1 Name element indicator (NEI)
2 Name element length
3
Name information
IA5 / ASCII characters, 1 per octet
n
NEI Calling party name

Connected party name
Redirecting party name (first base station)

F13.4.1.4 Encapsulation Mechanisms
QSIG Feature Transparency (ETSI ISUP Encapsulation)

The ability to convey QSIG information between peer applications is provided by the
Application Transport Mechanism (APM), which adds the following extensions to ETSI
ISUP (these are ETSI ISUP V3 messages/parameters, but CS2000 supports them as
extensions to ETSI ISUP V2):
A message may convey up to five APPs, but each must be for a different application
context; it is a protocol error if there are two APPs for any context.
! An Application Transport Message (ATM) that can be sent independently to convey
an APP.
to convey an APP.
The IAM sent to initiate a bearer QFT call, for example, conveys two number parameters:
! The CdPN conveys the public routing number of the destination node.
! The APP conveys the private destination number, as received in the incoming
SETUP message.
Up to 2K octets of encapsulated information can be conveyed by means of a segmentation
mechanism.
The information that can be conveyed in an APP depends on the application context,
! Open application contexts defined by standards bodies. The most important of these
is QFT (QSIG Feature Transparency), which is defined as application context 1.
The QFT information model provides definitions for a range of common data types
that are widely used in supporting services. CS2000 uses QFT data types to support
some Centrex services.
operators to define information models to support their own services. The UK
regulator has reserved application context 124 for Nortel use, and CS2000 uses it to
support services such as DFT (DPNSS Feature Transparency) and NACD
(Networked Automatic Call Distribution), which use data types that are not defined
in the QFT information model.
Before the ETSI ISUP V2+ APM was available, CS2000 supported the networking of
proprietary services only via the proprietary IBN7 interface, typically by conveying
service-related information in additional IBN7 ISUP parameters and messages. This
existing implementation of Networked Centrex, however, requires a CCS7 network with
an IBN7 signalling backbone. Use of the APM enables network operators to offer Centrex
services to their customers without having to deploy a proprietary signalling backbone.

DPNSS Feature Transparency (IBN7 Encapsulation)

optional parameter, this can simply be discarded if an end node does not recognise it.
The NTP containing the HNIP can be conveyed in ISUP call control messages. It can also
be conveyed in an unsolicited information message (INF) within a Pass-Along Message
(PAM). For calls using DFT, the originating node provides an explicit forward indication
of this by means of a bit in the ISUP optional Forward Call Indicators parameter. The
terminating node provides an explicit backward indication of DFT support by means of a
bit in the ISUP optional Backward Call Indicators parameter.
Up to 139 octets of DPNSS information can be included in the contents field of the HNIP.
This comprises up to 135 octets of selection/indication block information and up to four
DPNSS message group and type header octets.
F13.4.1.5 UK ISUP Additions

UK ISUP has three aditional parameters for conveying party information:
! Presentation Number
! Last Diverting Line Identity
! Partial Calling Line Identity (PCLI)

F13.4.2 TUP
F13.4.2.1 BTUP / IUP

Line identity parameter format is:
Bit
8 7 6 5 4 3 2 1
Octet
Message indicators
1 Number of address signals D C B A
IQ IA ind. NOA ind.

Message indicators are:

NOA (Nature Of Address)
National significant number
IA (Incomplete Address)
Complete address
Incomplete address
IQ (Identity Qualifier)
Line identity may be released for display
Line identity may not be released for display
Type of line identity, e.g. calling / last diverting, is indicated elsewhere in the conveying
message.

Party information functionality for BTUP is also affected by some fields of the
IAM/IFAM Message Indicators parameter, which has the following format:
Bit
8 7 6 5 4 3 2 1
Octet
1 Reserved EDI Calling Party Category (CPC)
Message indicators
2 H G F E D C B A
Prot. ind. MDG Reserved PA ind. I/W ind. Int. ind. CBI CLI ind.
3 Message indicators I to L Service Handling Protocol (SHP)
4 Interconnect-Specific Information (ISI) Message indicators M to P
5 PNI Call Path Indicator Routing Control Indicator
The relevant fields are:

CLI Calling Line Identity included
Calling Line Identity not included
CBI (CLI Blocking Indicator)
CLI blocking was available to the caller; NN available for display
No indication; NN not available for display
Note: This may mean that the caller did not have access to CLI blocking.
Alternatively, as a subscriber option, the caller may have a PN marked as
Presentation Allowed even if the NN is withheld, in which case the NN will
appear as unavailable on networks that do not recognise the PN. See
59008843 for details.
PNI (Presentation Number Indicator)
Presentation Number available (can be requested via ACI)
Presentation Number not included
F13.4.2.2 FTUP / SSUTR2

An SSUTR2 MIF message (national IAM) may include either or both of the following
types of calling party information:
NDI Designated Installation Number generated by the network
The NDI is contained in the Calling Line Identity (CLI) parameter in the MIF
message (national IAM), and comprises the following elements (ISUP
equivalent element given in parantheses in each case):
# Type of Calling Subscriber Address (NOA)
# CLI Status (SI)
# Disclosure Indicator (PI)
# Calling Line Address Signals (address signals)
NDS Designated Supplementary Number (NDS) provided by the user
The NDS is contained in the Access Information Domain parameter in the
MIF message, and comprises the following elements (ISUP equivalent
element given in parentheses in each case):
# Numbering Plan Identification (NPI)
# Number Type (NOA)
# Check (SI)
# Presentation (PI)
# Address Digits (address signals)

F13.4.3 ISDN
F13.4.3.1 Direct Support for Party Information

Calling Party Number IE format is:
Bit
8 7 6 5 4 3 2 1
Octet
1 Ext. ind. Type of number Numbering plan identification
2 Ext. ind. Presentation ind. Spare Screening ind.
3
Number information
IA5 / ASCII characters, 1 per octet
n
This format is also used for Connected Number, Original Called Number, Redirecting
Number and Redirection Number. The main functional elements are:
TON Subscriber number
National number
Network-specific number (e.g. operator)
Unknown
NPI E.164
Private
Unknown
PI Presentation allowed
Presentation restricted
Address not available
SI Network provided
User provided, verified and passed
User provided, not verified
Note: French ISDN (Numeris) allows two calling party numbers to be conveyed in a
SETUP message.

F13.4.3.2 Encapsulation of Private Party Information using the ETSI ISUP APM
The capability that underlies CS2000 support for open VPN implementations is the ETSI
ISUP Application Transport Mechanism (APM). This is an ETSI ISUP V3 capability, but
CS2000 implements it by means of extensions to ETSI ISUP V2; the extended version of
ETSI ISUP V2 is referred to as ETSI ISUP V2+.
APM provides support for the key VPN capability of private numbering plans, and also
allows service-related information (typically provided in Facility or Notification IEs over
the access interface) to be conveyed transparently across the network. Specifically, the
Application Transport Parameter (APP) can be conveyed in existing ETSI ISUP V2
messages or in an Application Transport Message (APM).
Note: Use of the APM with QSIG is referred to as bearer QFT (QSIG Feature
Transparency).
ISDN Call Originations

For each incoming call over QSIG and PRI, CS2000 analyses the CdPN IE in the SETUP
message to determine whether it conveys a public network number or a private number.
The decision can be based on either of two criteria:
! Prefix digits, specifically the absence of a PSTN breakout prefix digit or
trunk/international prefix digit.
! The value of the Numbering Plan Indicator (NPI) field in the CdPN IE, which
should indicate E.164 (public network number) or private numbering plan.
If the CdPN identifies a private network number served by another node, the call is
handled as a VPN call. CS2000 seizes an outgoing ETSI ISUP V2 trunk, and initiates
bearer QFT call setup by sending an IAM with the following number parameters (see
AJ5158 for details):
! The CdPN conveys the public routing number of the destination node; the CgPN
conveys the public network CLI of the calling party (which may be a
datafill-defined default).
! The APP conveys the private destination number and the private calling party
number, as received in the incoming SETUP message. The APP also conveys the
calling partys business group ID.
The destination node completes the call using the private destination number in the APP.
If CLIP is active for the called party, the private calling party number in the APP is
provided if both parties belong to the same business group; otherwise, the public network
CLI from the IAM is provided.

IBN Line Call Originations

QSIG Feature Transparency (QFT) can be used to convey private party information for
VPN calls from IBN lines, as described in AJ5360.
! Private calling party information conveyed in APPs in the IAM, provided that the
outgoing ISUP trunk is provisioned with the QFT ON option to enable the sending
out of VPN information:
" Private CLI (NPI=private and TON=unknown) obtained from table
DNATTRS.
" Customer group BGID retrieved from table BGIDMAP.
" Private called number (NPI=private and TON=unknown) consisting of the
original dialled digits.
" Calling name and associated presentation/restriction indicator provisioned
against originating line in table DNATTRS.
! Terminating node confirms ability to handle QFT information by sending back an
ISUP APM as a handshake message. Originating node responds to this with a
forward APM, which provides any information not included in the original IAM
because of segmentation.
! Private called party information conveyed in APPs in first backward mesage (ACM
or ANM). Information obtained via inverse of calling number/name provision
mechanism:
" Private connected party number (NPI=private and TON=unknown) and
associated presentation/restriction indicator provisioned against terminating
line in table DNATTRS.
" Connected name and associated presentation/restriction indicator provisioned
against terminating line in table DNATTRS.
The called party name can be displayed if the call encounters a busy line. (see
59013135) In this case, the name is conveyed in a backward Pre-Release
Information (PRI) message.
Name provision corresponds to ECMA 164, but name format (within ISUP APP) is as for
proprietary IBN7 CNAMD service.

F13.4.4 DPNSS
The mandatory OLI in the incoming ISRM is always the private network number, e.g.
PBX prefix plus extension, not the public DN. Because the private number can be
guaranteed to be unique only within the private network, it cannot be used directly as a
public network CLI. It is handled as follows:
! The SCREEN option of table TRKGRP can be used to reformat the incoming
private number into a public network CLI, and to check the validity of the resulting
number against table DNSCRN (see AH5121).
! If screening/reformatting is not requested (or if the reformatted CLI fails screening),
the user-provided OLI is discarded. A default PN will then be obtained from table
TRKGRP if one has been specified via DEFLTPN. Otherwise, the default CLI from
table TRKGRP is the only CLI available.
! If screening is successful, the SCRNPN option in TRKGRP determines whether the
user-provided number is treated as a PN or an NN:
" If SCRNPN is specified, the user-provided number is treated as a PN. The NN
is obtained from table TRKGRP option DEFLTCLI.
" If SCRNPN is not specified, the user-provided number is treated as an NN. A
default PN will be obtained from table TRKGRP if one has been specified via
DEFLTPN.
PI and CLIP datafill in TRKGRP determines whether the PN/NN is available for display
or suppressed. If the release/suppress status is a default rather than a permanent setting, it
can be overridden on a per-call basis via dialled prefix digits (see AJ5429).
The caller information provided for the outgoing call depends partly on whether the call
remains within the private network or is routed through the public network, and partly on
the capabilities of the outgoing interface, as follows:
! Public / private call
For a call that remains within the private network (DPNSS<->DPNSS direct or via
DFT), the user-provided private network number is provided as the OLI in the
(encapsulated) onward ISRM. Otherwise, it is discarded.
! Interface capabilities
" If the interface can handle both a PN and an NN, both are provided if
available.
" If the interface can handle only one CgPN parameter, the PN is provided in
preference to the NN if both are available.
For private network calls, DPNSS also supports the provision of the private called number
by means of the Connected Line Identifier (CLI) in the backward NAM.

F13.5 Delivery of Party Information for Display

F13.5.1 CLASS Information Display
CLASS features require the ability to convey digital information over an analogue line.
Modem functionality in the line media gateway is used to send party information to the
user terminal. ETSI EN 300 659 specifies that this can be done either during or prior to
the application of the ringing cadence to the line, as follows:
! The first long silent interval in the ringing cadence can be used for the data
transmission provided that it is long enough.
! To allow for markets in which the long silent interval of the ringing cadence is not
long enough for data transmission, the media gateway can instead apply a
500ms-800ms ring splash as a terminal alerting signal before sending the data, then
apply the standard ringing cadence when data transmission is complete.
Note: For V5.2 lines, V.23 modem capabilities are provided by MG functionality in the
PVG, in response to H.248 commands sent by the CS2000 GWC, as described in section
D3.6.4 on page 278.
Modem functionality and the application of ringing cadences to analogue subscriber lines
are the responsibility of the line gateway. The responsibility of the CS2000 is limited to
using GWC-gateway signalling to provide the party information to be displayed and
specify the ringing cadence to be applied.
In the case of an MTA line gateway, for example, the CS2000 instructs the MTA line
gateway by sending a single NCS message containing the desired ring signal ("rg" or one
of the distinctive ring signals defined by PacketCable) along with the Caller ID signal
("ci"). It is the responsibility of the MTA line gateway to use configuration information
in the MTA to determine the nature of the terminal alerting signal and how best to deliver
the name and/or number information via the modem burst in the silent interval.
S118-1).

F13.5.2 Reverse Translations

Reverse translations ensure that the number displayed on a called partys set for an
incoming call is the number that should be used if returning the call. This implies:
! That excess prefix digits should not be provided.
! That the number format used should conform to the called partys dial plan, i.e.
private format for VPN calls or public format for PSTN calls.
Reverse translations are controlled by the following tables at the terminating node:
CUSTNTWKFor each customer group, identifies the reverse translator(s) to be used for
incoming calls to group members. Residential subscribers have a single
translator for the public network.VPN business users have two translators,
one each for the public network and the VPN. Subfield NUMDIGS of field
DNREVXLA enhanced in EUR010 to support up to 15 digits (see AU3224).
DNREGIONLists all the regions known to the switch, and defines each one in terms of
the range of numbers that are considered to belong to it.
DNREVXLAEach DNREVXLA entry defines translation results for calls from CLIs
within a given digit range. Each result specifies a region name, followed by
digit manipulation (e.g. deletion of prefix digits) to be performed if both caller
and called party belong to the same region.
Figure 158 summarises the reverse translation process.
Table DNREVXLA
Reverse translator name
from table CUSTNTWK RXLANAME
Calling number FROMDIGS

TODIGS
Use next
RESULT in list RESULTS:
List of up to 20 Table DNREGION
consisting of:
REGION REGION
DELDIGS
PRFXDIGS FROMDIGS
OPTRFX TODIGS
Yes
Calling number
Is there another No within a REGION
RESULT on list of Use DELDIGS,
digit range?
RESULTS? PRFXDIGS,
No Yes and OPTPRFX
to format CLI
Called number into diallable
Calling Number Yes
in same form for
unchanged No region? called party
Figure 158: Overview of reverse translations

F13.6 CS2000 Provisioning

F13.6.1 Party Information for Lines
In the event of a conflict between DNATTRS and DNGRPS, the line information in
DNATTRS overrides the DN range information in DNGRPS.
Table DNATTRS
! KEY is DN (SNPA / NNX / DEFGDIGS)
! NETNAME is logical network name as defined in table NETNAMES (DN
attributes for PUBLIC may differ from those for a named private network) with the
following options (list not exhaustive):
" SUPPRESS (suppress DN and/or NAME information for calls to named
network)
" NAME (station name is as defined by DNAME refinement)
" PN (Presentation Number with up to 13 digits, for use as an alternative to the
datafilled DN / NN, in the PUBLIC network only)
Table DNGRPS
! KEY is DN range (AREACODE / OFCCODE / FROMDIGS / TODIGS)
Note: A DN range normally corresponds to a customer group. A customer group
may comprise two or more DN ranges, but these would typically have the same
attributes. The DN range whose attributes are specified by a DNGRPS entry would
not encompass more than one customer group.
! NETNAME is logical network name as defined in table NETNAMES (DN
attributes for PUBLIC may differ for those for a named private network) with the
following options (list not exhaustive):
" ADDRESS (specifies any differences between the network-specific DN and
the datafilled DN; specified as 10 digits with the structure NPA / OFC / DIGS,
where a digit 0-9 takes precedence over the corresponding datafilled DN digit,
N means use the default DN digit, and D means delete the corresponding
datafilled digit; typical use is to specify a different OFC code to identify the
DN range within a private network, as opposed to the datafilled OFC code that
allows those numbers to be reached as DDI numbers from the public network,
and to delete the NPA code to leave a 7-digit VPN number)
" DNTYPE (PRIVDN or PUBDN)
" PADDING (a vector such as PNNNNNNNNN, where each P indicates that
the corresponding digit in the datafilled DN is a zero used for padding)
" SUPPRESS (suppress DN and/or NAME information for calls to named
network)
" NAME (station name is as defined by DNAME refinement)
" PN (Presentation Number with up to 13 digits, for use as an alternative to the
datafilled DN / NN, in the PUBLIC network only)

F13.6.2 Party Information Services

Table CUSTSTN lists the station options that can be assigned to customer groups.
Depending on the feature, assignment at the customer group level may be enough to make
it available to all the lines in the customer group. Alternatively, it may also be necessary
to add a feature option to each lines entry in IBNLINES or KSETLINE. Options related
to the provision of party information are:
! CND
Calling Number Delivery (fixed-length 10-digit number)
! DDN
Diallable Number Delivery (up to 24 digits)
! CNAMD
Calling Name Delivery
! CNDB
Calling Number (and Name) Delivery Blocking
! CNDBO
Calling Number Delivery Blocking Override
! CNAB
Calling Name Delivery Blocking
! NAMEDISP
Name Display

F13.6.3 Party Information for Network Trunks

! Interfaces that provide direct support for party information parameters:
" ISUP (ETSI ISUP V1, ETSI ISUP V2, IBN7, national ISUP variants)
" TUP (IUP / BTUP, SSUTR2 / FTUP, ITU TUP)
! Interfaces that can convey private party information by means of encapsulation (in
addition to public party information conveyed in standard parameters):
" QSIG Feature Transparency (QFT), i.e. party information in QSIG form
conveyed transparently via the ETSI ISUP V2+ Application Transport
Mechanism (APM), as described in AJ5360.
Private calling party information conveyed in APPs in the IAM, provided that
the outgoing ISUP trunk is provisioned with the QFT ON option to enable the
sending out of VPN information:
# Private CLI (NPI=private and TON=unknown) obtained from table
DNATTRS.
# Customer group BGID retrieved from table BGIDMAP.
# Private called number (NPI=private and TON=unknown) consisting of
the original dialed digits.
# Calling name and associated presentation/restriction indicator
provisioned against originating line in table DNATTRS.
Terminating node confirms ability to handle QFT information by sending
back an ISUP APM as a handshake message. Originating node responds to
this with a forward APM, which provides any information not included in the
original IAM because of segmentation.
Private called party information conveyed in APPs in first backward mesage
(ACM or ANM). Information obtained via inverse of calling number/name
provision mechanism:
# Private connected party number (NPI=private and TON=unknown) and
associated presentation/restriction indicator provisioned against
terminating line in table DNATTRS.
# Connected name and associated presentation/restriction indicator
provisioned against terminating line in table DNATTRS.
Name provision corresponds to ECMA 164, but name format (within ISUP
APP) is as for proprietary IBN7 CNAMD service.
" DPNSS Feature Transparency (DFT), i.e. party information in DPNSS form
conveyed transparently via IBN7.
The only private party information that can be conveyed is the private calling
party number, i.e. the OLI in the incoming ISRM. For a call that remains
within the private network (DPNSS<->DPNSS direct or via DFT), this
user-provided private number is provided as the OLI in the (encapsulated)
onward ISRM.
F13.6.4 Party Information for Access and VPN Trunks

Interfaces that provide direct support for party information parameters:
! ISDN PRI (CgPN IE in SETUP; CdPN in CONNECT)

! QSIG (CgPN IE in SETUP; CdPN in CONNECT)

! DPNSS (OLI in ISRM)
! DASS2 (OLI in ISRM)
Alternative mechanisms that are also available:
! Table LTDATA can be used to provision a CLI and PN against a PRI or QSIG
logical terminal.
! Table TRKGRP can be used to provision a CLI and PN against an incoming DPNSS
trunk.
" Option DEFLTCLI specifies CLI
" Option DEFLTPN specifies PN
F13.6.5 Defining Default/Overriding Calling Numbers in Table DEFNUM

CS2000 allows default calling numbers and number-related attributes (NOA, NPI, PI, SI)
to be defined in table DEFNUM for use in various circumstances. This makes it possible
to provide a default number if no calling number is received, or to override a received
calling number and/or some of its attributes for any reason.
A number of different mechanisms are available for defining default calling numbers for
PBX trunks, as this is essential for regulatory reasons, e.g. the DEFLTCLI option for PRI
trunks. As a standardised alternative to these, feature A59028834 provides a
general-purpose DEFNUM mechanism that can be used to define defaults for a variety of
number types (NN, PN, charge number, contractor number) and a wide range of incoming
trunk types (all ISUP variants, all PRI variants, DPNSS, BTUP).
Entries in table DEFNUM can be used to define default calling numbers. The definition
of such a default number can apply to a CLI (NN or PN), charge number or contractor
number, and can comprise any or all of the following:
! Default digit string with up to 24 digits
! Default NOA
! Default NPI
! Default PI
! Default SI
The basic principle is that, if table DEFNUM is consulted for an incoming call, the default
values it specifies will be used for the corresponding fields of the CLI (or charge number
or contractor number), overriding the corresponding field values in the number actually
received (if any). Option DEFOPT in table DEFNUM determines the circumstances
under which the default number is used. Fields for which no default has been specified in
table DEFNUM will be left unchanged. This mechanism for updating selected fields in a
received number can be regarded as a basic CLI editing capability.
A DEFNUM entry will be consulted in the following circumstances:
! The DEFNUM option can be specified in table TRKOPTS for a trunk group, to
indicate that there is a table DEFNUM entry that should be consulted for all
incoming calls to that trunk group.
! The DEFNUM option can be specified in universal screening tables (see section
C3.5.5: Call Control and Universal Screening on page 214 for details), to indicate
that there is a table DEFNUM entry that should be consulted for calls matching
specific criteria.

F13.7 Per-Interface Summary of Capabilities

This section summarises the support provided for call party information services by each
interface implemented on CS2000. The section comprises four tables:
! Table 64: Summary of interface support for the provision of NN and/or PN
! Table 65: Summary of originating agent capabilities
! Table 66: Summary of terminating agent capabilities
! Table 67: Support for party information over specific interworkings
Generic Mechanisms for Controlling CLI Delivery

Feature A59023300 implemented two generic mechanisms for the control of CLI
provision over trunk interfaces, i.e. mechanisms that do not depend on the trunk protocol
in use (see section F13.6.5 on page 685 for information about protocol-independent
control of default CLI functionality):
! CLI control via the CLIDELV option of table CLICNTL, as used to support
enhanced screening for incoming indirect access calls. An index into table
CLICNTL can be specified either as a service option in table CLISERV or in table
TRKOPTS. The CLIDELV field of an entry in table CLICNTL can specify whether
a CLI should (Y) or should not (N) be delivered for a screened call. If Y, the
OUTPULSE_OPTIONS field can specify a list of number types in order of
preference, to indicate what type of number should be delivered. The possible
number types are:
" Screening number (SCRN_NUM), i.e. whatever number has been used for
screening
! CLI control via the CLIDELV option of table TRKOPTS
The CLIDELV option can be specified for a trunk termination to indicate whether
a CLI should (Y) or should not (N) be delivered, or whether delivery should depend
on the setting of the setting of the Presentation Indicator (SCRN_PI). For
CLIDELV=SCRN_PI, the CLI is delivered only if PI=00 (Allowed); otherwise, the
PI is delivered but no CLI. See A59040499.
Option SCC in table TRKOPTS allows a country code with 1-4 digits to be associated
with a trunk group. This can be used as a prefix to convert an incoming CLI into an
international number, or used in stripping off an unnecessary international CLI prefix for
a non-international call. See A59023331.
Table DEFNUM can be used to specify default calling number attributes (digit string,
NOA, NPI, PI, SI) values to be used for each incoming call to a trunk group, overriding
the corresponding field values in the number actually received (if any). This mechanism
for updating selected fields in a received number can be regarded as a basic CLI editing
capability. See section F13.6.5 on page 685 and A59028834.

Table 64 is a matrix summarising support for the provision of call party information
across interworkings. It includes three types of cross-reference for more details:
! Cross-references to Table 65 for originating agent information (refs o1, o2 etc)
! Cross-references to Table 66 for terminating agent information (refs t1, t2 etc)
! For information about specific interworkings, the matrix cell is shaded to indicate
that there is a corresponding interworking note in Table 67.
Note: Provision of party names in addition to PN and/or NN is supported only for
proprietary interfaces (IBN lines and IBN7 trunks).
Table 64: Summary of interface support for the provision of NN and/or PN

Terminating
IBN7 ISUP t8
EISUP V1 t6
EISUP V2 t7
UK ISUP t9
IBN line t1
DPNSS t5
agent
BTUP t10
FTUP t11
Originating
QSIG t4
ACD t2
PRI t3
agent
IBN line o1 Y Y Y Y y y Y Y Y Y y
ISDN PRI o2 Y Y Y Y Y y Y Y Y Y Y
QSIG o3 Y N Y Y N y Y Y N N N
DPNSS o4 y Y Y N y y Y Y Y Y N
ETSI ISUP V1 o5 y y y y y y y y y y N
ETSI ISUP V2 o6 Y Y Y Y Y y Y Y Y Y N
IBN7 ISUP o7 Y Y Y Y Y y Y Y Y Y Y
UK ISUP o8 Y Y Y N N y Y Y Y Y N
IUP / BTUP o9 Y Y Y N Y y Y Y Y Y N
SSUTR2 / FTUP o10 y N Y Y N y Y Y N N Y
Provision of
party
Provision of No support
Legend Y = NN and/or PN y = information N = for CLI
partly
fully supported supported
provision
(NN, not PN)

Table 65: Summary of originating agent capabilities

Note Interface Capabilities
IBN line means analogue line datafilled in table IBNLINES (standard IBN line, CAS mux line,
V5.2 PSTN line).
Providing caller information:
Datafill in DNATTRS/DNGRPS determines availability and permanent release/suppress status
of NN (from IBNLINES), PN and party name, as described in section F13.6.1 on page 682, and
o1 IBN line can reformat number provided on a per-network basis, e.g. to provide VPN number for private
network.
Permanent release/suppress status can be overridden on a per-call basis.
Displaying connected party information:
As for IBN line terminating agent (see note t1 in Table 66).
CgPN IE in SETUP message can provide CLI, and is handled as follows.
User-provided number can be screened against table DNSCRN datafill, after which full
padded number is obtained from table LTDATA. INSNAC option can be used to add access
code digits as prefix (see AJ5098).
Screening takes place unless NOSCRN option is specified in table LTDATA. If a
user-provided number fails screening, it is discarded. A default PN will then be obtained from
table LTDATA if one has been specified via DEFLTPN. Otherwise, the default CLI from table
LTDATA is the only CLI available.
If the NOSCRN option is used to bypass screening, or if screening is successful, the
SCRNPN option in LTDATA determines whether the user-provided number is treated as a
PN or an NN:
- If SCRNPN is specified, the user-provided number is treated as a PN. The NN is obtained
from table LTDATA.
- If SCRNPN is not specified, the user-provided number is treated as an NN. A default PN
will be obtained from table LTDATA if one has been specified via DEFLTPN.
Note: The net effect of specifying both NOSRCN and SCRNPN is that a user-provided
number will be used unmodified as a PN.
If no CgPN IE is provided in the SETUP mesage, a default PN will be obtained from table
LTDATA if one has been specified via DEFLTPN. Otherwise, the default CLI from table LTDATA
is the only CLI available.
o2 ISDN PRI Per-call CLI blocking can be requested via dialled prefix digits (see AU2802).
The caller information provided for the outgoing call depends partly on the capabilities of the
selected interface and partly on whether it is a public network interface or an access/VPN
interface, as follows:
If the interface can handle both a PN and an NN, both are provided if available.
For a public network interface that can handle only one CgPN parameter, the NN must be
provided.
For an access/VPN interface that can handle only one CgPN parameter, the PN is provided
in preference to the NN if both are available.
If call forwarding has taken place at the originating PBX and redirecting numbers are included
in the SETUP message, these can also be screened at the switch (see A59034151). This
applies to Redirecting Number IE, Redirecting Number in DivertingLegInfo2 (Facility IE), and
Last Rerouting Number in Call Re-Routing operation during invocation of Partial Re-route
(Facility IE).
COLP supplementary service must be assigned to originating interface via table LTDATA.
Connected number is then provided to caller via CNN IE in backward CONNECT.
Feature A590124931 iimplemented two new table LTDATA options to enhance COLP:
SCRN_CNN_PN causes the user-provided connected number to be treated as a PN rather
than an NN.
CNN_NOSCRN causes the user-provided connected number to be passed on without
editing or screening.
As for PRI originating agent (see note o2).
o3 QSIG
As for PRI originating agent (see note o2).


OLI in ISRM is mandatory. This is always the private network number, e.g. PBX prefix plus
extension, not the public DN. Because the private number can be guaranteed to be unique only
within the private network, it cannot be used directly as a public network CLI. It is handled as
follows:
The SCREEN option of table TRKGRP can be used to reformat the incoming private number
into a public network CLI, and to check the validity of the resulting number against table
DNSCRN (see AH5121 and 59013159).
If screening/reformatting is not requested (or if the reformatted CLI fails screening), the
user-provided OLI is discarded. A default PN will then be obtained from table TRKGRP if
one has been specified via DEFLTPN. Otherwise, the default CLI from table TRKGRP is the
only CLI available.
If screening is successful, the SCRNPN option in TRKGRP determines whether the
user-provided number is treated as a PN or an NN:
- If SCRNPN is specified, the user-provided number is treated as a PN. The NN is obtained
from table TRKGRP option DEFLTCLI.
- If SCRNPN is not specified, the user-provided number is treated as an NN. A default PN
will be obtained from table TRKGRP if one has been specified via DEFLTPN.
PI datafill in TRKSGRP and CLIP datafill in TRKGRP determine whether the PN/NN is available
o4 DPNSS for display or suppressed. If the release/suppress status is a default rather than a permanent
setting, it can be overridden on a per-call basis via dialled prefix digits (see AJ5429 and
59013159).
The caller information provided for the outgoing call depends partly on whether the call remains
within the private network or is routed through the public network, and partly on the capabilities
of the outgoing interface, as follows:
Public / private call
For a call that remains within the private network (DPNSS<->DPNSS direct or via DFT), the
user-provided private network number is provided as the OLI in the (encapsulated) onward
ISRM. Otherwise, it is discarded.
Interface capabilities
- If the interface can handle both a PN and an NN, both are provided if available.
- For a public network interface that can handle only one CgPN parameter, the NN must
be provided.
- For an access/VPN interface that can handle only one CgPN parameter, the PN is
provided in preference to the NN if both are available.
TLI in backward NAM is mandatory for a call that has remained within the private network, but
is not supported for a call that has been routed through the public network.
The TLI provided for a private network call will be the private number.
Parameters available for conveying party information in forward direction:
Calling Party Number (optional, but always provided if available).
See section F13.4.1.1 on page 670 for parameter format.
o5 ETSI ISUP V1
Parameters available for conveying party information in backward direction:
Connected Number.
Calling Party Number (optional, but always provided if available), Original Called Number,
Redirecting Number.
Generic Number parameter containing Additional Calling Party Number is used to convey PN if
available.
o6 ETSI ISUP V2 Application Transport Mechanism (APM) can be used to encapsulate and convey private party
information from ISDN and Centrex call originations, as described in section F13.4.3.2 on page
677.
Singapore ISUP V2 supports an ACLI (Additional CLI) parameter for conveying the routing
number for a an LNP ported DN in AIMs sent from the recipient switch (see A59034058).
Connected Number, Redirection Number.


Redirecting Number.
For an outgoing IBN7 trunk, options CLID in table CUSTNTWK and RCGLI in table TRKSGRP
can be used to ensure that CLI is requested from the incoming interface (if not already available)
before call setup proceeds.
Generic Number parameter containing Additional Calling Party Number is used to convey PN if
available.
Proprietary Party Information parameter for caller name (see section F13.4.1.3).
For an outgoing IBN7 trunk, caller name is provided if it is available (datafilled in
o7 IBN7 ISUP DNATTRS/DNGRPS, for proprietary line types only), if NAMEDISP is assigned to the customer
group via table CUSTSTN, and if the NMDSP option is specified for the network in table
NETNAMES.
DPNSS Feature Transparency (DFT) can be used to encapsulate and convey private calling
number from DPNSS calls, as described in section F13.4.4 on page 679.
Proprietary Party Information parameter for caller name (see section F13.4.1.3).
Called party name is requested if NAMEDISP is assigned to the customer group via table
CUSTSTN, and if the NMDSP option is specified for the network in table NETNAMES. The
request mechanism is the proprietary Supplementary End-to-End Information Request
parameter.
Redirecting Number.
o8 UK ISUP Also Presentation Number, Last Diverting Line Identity, Partial Calling Line Identity (see section
F13.4.1.5).
Line Identity.
In BTUP V2, caller information is explicitly requested. There are three scenarios:
For non-interworked (all-CCS7) calls, the request is made via a backward ACI Request and
the CLI is returned in a forward ACI Response. Information Indicator Code in each ACI
indicates whether number requested/conveyed is NN or PN.
For interworked calls, the request is made via a backward SASI Request and the CLI is
returned in a forward ASI Response. The CLI is usually partial because of the interworking,
o9 IUP / BTUP i.e. it identifies the exchange rather than the party, but the DEFLTCLI option can be used to
provide a full default CLI instead.
For ISDN call originations, CLI is obtained via an exchange of SIMs.
BTUP V2+ supports BTUP V2 capabilities, and can also provide NN in IFAM/IAM by default, as
an alternative to providing it on request.
Line Identity.
For non-interworked (all-CCS7) calls, BTUP can provide TLI (in backward ACI Response) in
response to request (in forward ACI Request).
MIF (national IAM) message parameters available for conveying party information in forward
direction:
CLI parameter conveying NDI (Designated Installation Number) generated by the network.
This is optional, but always provided if available.
Access Information Domain parameter conveying NDS (Designated Supplementary
o10 SSUTR2 / FTUP Number) provided by an ISDN user.
Calling Party Number (), Original Called Number, Redirecting Number.
No mechanism available for conveying party information in backward direction.

Table 66: Summary of terminating agent capabilities

Providing caller information for display:
Line must be assigned display service(s), i.e. DDN or CDN, with CNAMD as optional extra, and
be equipped with appropriate terminal, i.e. CLASS terminal with display. Party information can
then be provided for display as described in section F13.5.1 on page 680.
t1 IBN line Called party who has been assigned CNDBO can have suppressed info displayed.
Providing connected party information:
Info available is as for IBN line originating agent (see note o1 in Table 65), but info is not provided
backwards unless redirection takes place.
As for IBN line terminating agent (see note t1).
t2 ACD Primary DN of ACD group can be obtained from datafill and made available, but info is not
provided backwards unless redirection out of ACD group takes place.
Note: Secondary DN of individual ACD group member is provided only for non-ACD calls
originated by that member, as for an IBN line originating agent.
Trunk must be assigned CLIP supplementary service. CLI is then provided to user via CgPN IE
in SETUP message. Either NN or PN is accepted as CLI; if both are available, PN is preferred
to NN.
Table CGPNBLDR (Calling Party Number Builder), accessed via TRKOPTS, provides
t3 ISDN PRI datafill-controlled mapping of CLI PI (Presentation Indicator). See A59040499.
Note: French PRI (Numeris VN4) allows both NDI (NN) and NDS (PN) to be provided.
Info available is as for PRI originating agent (see note o2 in Table 65), except that user-provided
number is conveyed in CNN IE in backward CONNECT. Mechanism is COLP supplementary
service.
As for PRI terminating agent (see note t3).
t4 QSIG
As for PRI terminating agent (see note t3).
OLI in ISRM is mandatory. This will be the terminating private network number for a call that has
remained within the private network. For a call that has been routed through the public network,
t5 DPNSS it will be the PN if one is available or the NN otherwise.
Info available is as for DPNSS originating agent (see note o4 in Table 65), except that
user-provided number is conveyed in mandatory TLI in backward NAM.
t6 ETSI ISUP V1 As described in note o5 in Table 65.
t7 ETSI ISUP V2 As described in note o6 in Table 65.
t8 IBN7 ISUP As described in note o7 in Table 65.
t9 UK ISUP As described in note o8 in Table 65.
t10 IUP / BTUP As described in note o9 in Table 65.
t11 SSUTR2 / FTUP As described in note o10 in Table 65.
Table 67: Support for party information over specific interworkings

Interworking Capabilities
IBN line to DPNSS Number passed may be private network number.
CgN in SETUP mapped to CLI in onward IAM if screening succeeds or is not needed;
presentation indicator from PRI honoured.
If SETUP message contains either an NPI value of "Private", or a TON (Type of Number) value
of "Network Specific", the outgoing ISUP Screening Indicator will be set to "Network Provided
PRI to ISUP and the default number from table LTDATA will be sent, with PI set to "Allowed".
Default CLI from LTDATA mapped to CLI in onward IAM if no CgN included in SETUP.
Per-call (un)blocking supported by means of datafill-defined diallable prefixes, e.g. 141 / 1470
for the UK. See AU2802 for details.

Table 67: Support for party information over specific interworkings

CgN in SETUP mapped to CgN in onward ACI if screening succeeds or is not needed. Default
CLI from LTDATA mapped to CgN in onward ACI if no CgN in SETUP or screening fails. See
PRI to BTUP AG5046 for details.
Per-call (un)blocking supported by means of datafill-defined diallable prefixes, e.g. 141 / 1470
for the UK. See AU2802 for details.
DPNSS to IBN line Number passed may be private network number.
For interworking between any combination of ANSI ISUP+ and ETSI ISUP V1/V2, the CLI
(including Presentation Indicator) is passed on unchanged if available.
From EUR008, the EDITCLI option in TRKSGRP can be used to determine whether the number
ISUP to ISUP passed on over an outgoing trunk is passed on transparently, converted to international format
(in which case the NoA is changed appropriately), or deleted (no Calling Party Number in
outward message). See AJ4877 for details.
ETSI ISUP to FTUP ETSI ISUP I/W to FTUP:
Treated as international call; no CLI information in resulting MIF
Full CLI included in ISUP IAM if available (e.g. in BTUP V2+ IAM/IFAM).
If not available, BTUP ACI exchange is needed to request and provide CLI.
TRKSGRP options RCGLI and AMDIN_CLI enable ISUP to request CLI.
RCGLI option specifies that CLI should be requested, but takes effect only if BI marks number
as available; IQ controls presentation of CLI, as usual.
BTUP to ISUP ADMIN_CLI allows BI to be overriden for admin purposes; if both RCGLI and AMDIN_CLI are
set, CLI is requested regardless of BI setting
If CLI is requested, sending of ISUP IAM is delayed until ACI exchange is complete and CLI is
available.
For details of this functionality, refer to AE1542.
Blocking Indicator (BI) will be honoured depending on incoming value. Similarly, CS2000 will not
BTUP to BTUP change either the restriction indicator or the Presentation number indicator.
FTUP I/W to ETSI ISDN:
Only one CgPN IE can be passed on
If NDI and NDS are both provided, NDS is mapped to CgPN IE if its SI indicates UPVP;
FTUP to ISDN otherwise, NDI is mapped to CgPN IE and NDS is discarded.
NDI mapped to CgPN if only NDI is provided.
Default CgPN mapped to CgPN if no CLI provided.
FTUP I/W to ETSI ISUP V1:
FTUP to ETSI ISUP V1 NDI -> CgPN
NDS discarded
FTUP I/W to ETSI ISUP V2:
FTUP to ETSI ISUP V2 NDI -> CgPN
NDS -> Generic Number (Additional CgPN)
Table 68: Support for party information on redirection

Support for information about redirecting and redirection parties when call is forwarded depends
General on the interfaces involved in the interworking.
Notification of forwarding provided back to caller only for nodal Centrex calls or incoming IBN7
calls. For IBN7 calls, notification mechanism is Call Progress Message (CPG) with Event
Incoming call to Information and Redirection Number parameters.
IBN line
is redirected Notification of forwarding provided forward to new called party only for nodal Centrex calls or
calls rerouted via IBN7. For IBN7 calls, notification mechanism is additional parameters in
outgoing IAM: Redirection Indicators, Original Called Number, Redirecting Number.

Chapter F14 Regulatory Services
Regulatory services are features that are not associated with a particular network operator
or signalling system, but are specified by a regulatory body and must be supported
throughout the public network regulated by that body. Some of them are CEPT
(Conference of European Post and Telecommunications Administrations) services or
have CEPT equivalents; others are specific to a particular country.
! Section F14.1: Special Call Types
! Section F14.2: Call Tracking and Supervision Features
! Section F14.3: Charging and Billing Features
! Section F14.4: Network Interconnect Features
! Section F14.5: Miscellaneous Features
Note: Some ISDN supplementary services can also be regarded as public network
features, either because they provide ISDN equivalents of public network features (e.g.
MCID) or because (as in the case of AOC) support for them is a regulatory or de-facto
regulatory requirement in some national markets. For information about CS2000 support
for such ISDN services, see Chapter F4: ISDN Supplementary Services.

Communication Server Capabilities Features and Services Regulatory Services
F14.1 Special Call Types

F14.1.1 Emergency Calls
F14.1.1.1 Functional View (Generic)

Depending on country, emergency calls, e.g. calls to the standard European emergency
number 112, have some or all of the following characteristics
! They must be marked as emergency calls, which gives
" Protection
Cannot be force-released
" High priority
Cannot be rejected because of congestion
Alternative routes must be provided, with continuous retry of all routes until
a free route is found
! Called party control by the operator
Control of the call passes to the operator when the call has been answered, i.e. when
the ANM message has been sent back. This means that the call cannot be cleared
except by the operator. The connection remains in place even if the caller goes
on-hook to terminate the call. If the caller goes on-hook and subsequently goes
off-hook again, he or she is reconnected to the operator.
! Selection of nearest operator for multi-site groups
For a multi-site customer group, emergency calls must be answered by the operator
nearest the originating site. This is achieved via translations, so that the route
eventually selected is the one to the nearest operator.
F14.1.1.2 Emergency Call Implementations for Specific National Markets
Emergency Call Implementation for Germany

In the German network, emergency calls are supported via the Priority Class of Service
(PCOS) capability described in section F14.1.2 on page 696. Translations associates
CLASS EMRG with the dialled numbers 110/112/115, so an emergency call is recognised
when someone dials 110 for Police/Emergency Services or 112 for Fire Department.
An IAM generated for an emergency call is encoded as follows:
! The Called Party Address (CdPA) must be replaced with a new digit stream
identifying the required emergency bureau. This must begin with the following:
" The German area code (ONKZ or Ortsnetzkennzahl)
" The office code of the originating exchange
" Two overdecadic digits (hexadecimal representation of 12)
The CdPA is then completed by one of the following:
" The dialled Emergency Number, i.e. 110, 112 or 115
" The dialled Emergency Number followed by another hex 12 and the identifier
of the NLO network, if applicable
" Short emergency number (0/2), followed by the Emergency Centre Identifier
of the nearest emergency bureau
! The outgoing IAM must include the PCOS parameter set to indicate Subscriber
with Priority (see section F14.1.2).

Regulatory Services Features and Services Communication Server Capabilities
Emergency Call Implementation for Belgium

Emergency calls that originate from CS2000-controlled lines and are handled by a
Belgacom switch must be routed to the emergency station nearest to the sub-community
to which the lines belong. This is achieved by adding a sub-community identifier as a
prefix to the dialled number. Line datafill specifies the sub-community to which each line
belongs, and table EMSUBCOM maps sub-community names on to prefixes, which are
inserted during translations. See A59018251 for details.
Emergency Call Implementation for China

Enhancements to existing called party control functionality to support emergency line and
re-ring / ring back functionality over China ISUP for operator call services, in accordance
with China ISUP specification YDN038-1997 (see A59040141 for details):
! For emergency calls or calls made to an operator, for which called party control is
in effect, China ISUP requires a forward CCL (Calling Party Cleared) message to
be sent if the calling party goes on-hook. If an operator needs to re-establish contact
with the caller or the called party, this is implemented by the sending of a backward
OPR (Operator) message to initiate ring-back in response to the CCL.
! For calls set up by the operator, a forward OPR (Operator) message can be sent to
initiate ring-back if the called party goes on-hook prematurely (indicated by a SUS
message).
ISN06 feature A89008399 implemented the following additional enhancements to the
CS2000 implementation of emergency call functionality for China:
! Line option ESG (Emergency Service Group) can be assigned to the pilot member
of a Distributed Line Hunt (DLH) group or Multi-Line Hunt (MLH) group, which
makes ESG capabilities available to all members of the hunt group.
! Treatment (silence or an announcement) can be applied to the callers line before
ringing is applied to an ESG hunt group, allowing subscribers who have misdialled
or changed their mind to hang up before terminating on a ESG attendant.
! Called party control for emergency calls from lines.
! Re-ring capability is provided for situations when the caller hangs up but the ESG
attendant needs to continue the conversation.
! Alarm generation for ESG calls if office parameter ESG_ALARM is set to Y.
! Support for ESG logs ESG100, ESG101 and ESG103.

F14.1.2 Priority Calls

Priority Class Of Service (PCOS) is a feature specific to the German market.
The PCOS capability is an optional parameter contained in the IAM, which identifies a
given call as a priority call and indicates that it should be allowed to complete in the case
of a catastrophe. This capability is also known as Catastrophe Handling.
The bit values for the National Parameter FE (NP.FE), as supported by the German variant
of ETSI ISUP V2, are as follows:
0 Subscriber without priority
1 Subscriber with priority
The PCOS parameter is always included in the IAM. For a call from a subscriber
designated as a Subscriber with priority, or an Emergency Call, the indicator is set to
Subscriber with priority. In all other cases, the indicator is set to Subscriber without
priority. An IBN line is designated as a Subscriber with priority, when the ELN
(Essential Line) option is associated with the line via SERVORD. A PRI access is
designated as a "Subscriber with priority" when the PCOS option is provisioned against it.
If an IAM is received without a PCOS parameter, it is interpreted as an IAM with PCOS
set to Subscriber without priority.

F14.2 Call Tracking and Supervision Features
F14.2.1 Malicious Call Identification (MCID)
F14.2.1.1 Functional View

Malicious Call Identification (MCID) allows a subscriber to activate tracing for an
incoming call. This causes information such as the calling and called party number, the
calling party category, and the time and date of an incoming malicious call to be recorded
at the terminating local exchange so that appropriate action can be taken. MCID makes
use of the following related features:
! Calling Line Identification (CLI)
This is what makes the calling party number available at the terminating exchange.
! Called Party Control / Last Party Release
These ensure that a malicious call connection is not dropped until tracing is
complete, even if the caller hangs up.
F14.2.1.2 Generic CS2000 Support

CS2000 support for MCID assignment and activation is as follows:
! For analogue lines, MCID is made available by assigning the CLF (Calling Line
Flash) option via SERVORD. CLF is activated by dialling an activation code. The
called party can hang up after activating the feature, but the calling party may not
(the backward connection is held to permit identification).
! For PBX users served by PRI, the ISDN supplementary service MCID can be
invoked either manually by the subscriber, or automatically by the network for all
unanswered calls. CS2000 allows it to be requested by a PRI user during the active
phase of a call, or in the call takedown phase after receipt of DISCONNECT.

F14.2.1.3 MCID Implementations for Specific National Markets
MCID Implementation for Germany

The MCID supplementary service for Germany enables an incoming call to a PRI user to
be identified and registered by the network. Information to be captured is:
! Calling party number
! Called party number
! Last forwarding number if any call forwarding applies
! Date
! Time
The invocation of the MCID supplementary service can either be manually from the
served user, or automatically by the network for all unanswered calls. Manual
identification of the calling user is possible during the active phase (state N10) of the call
and in the call takedown phase after receiving DISCONNECT message (state N12).
An analogue version of the ISDN MCID service is also supported for analogue IBN cable
lines in Germany for incoming calls from ETSI ISUP, ETSI PRI and other IBN lines,
provided that CLF has been assigned as a line option to the terminating line.
If the calling party number is not available due to interworking, the identification of the
incoming trunk is registered (i.e. the incoming trunk CLLI).
MCID Implementation for Hong Kong

MCID enhancements to meet Hong Kong requirements (see A59040504 for details):
! Generation of MCT Presentation log MCT105 for calls over IBN7 (ANSI ISUP+),
trunks (previously supported only for ETSI ISUP and variants).
! Support for generation of enhanced MCT106 log when backward INR message
with "hold" is received via Hong Kong ISUP. The enhanced MCT106 log contains
the new Calling Party Category (CPC) field.
! Support for immediate release of call at terminating exchange when forward DRS
(Delayed Release) message is received via Hong Kong ISUP indicating completion
of MCT actions.

F14.2.2 Lawful Interception (LI)
F14.2.2.1 Functional View

Lawful Interception allows selected calls to be intercepted and monitored by a national
Law Enforcement Agency (LEA) subject to the constraints of national law. In certain
regulatory regimes, all network operators may be required to support such interception.
The principle is that incoming calls to, and outgoing calls from, a specific access interface
can be monitored without the parties involved being aware of this. Two types of
information may be obtained and provided to the LEA as a result:
! Call content, i.e. voice and/or in-band data, which is delivered to the LEA via a
dedicated Call Content Channel (CCC) comprising one or two CC links.
! Call-related data, e.g. calling/called numbers and call start/stop times, which is
delivered to the LEA via a dedicated Call Data Channel (CDC).
These channels use different interfaces and transit networks, as shown in Figure 159.
Packet network
LI
target
Monitored call CS2000
Media
gateway GWC
Media server GWC

Other Call processing Call-related data LI service logic
party Media (CS2000 Core) (on SDM)
gateway
GWC
CDC
Call content FTAM / FTP
(voice or data) LI service initiates monitoring of initiator
packet network bearer connection (on SDM)
GWC
LEA media and sets up TDM call towards LEA
gateway to relay intercepted call content Call-
related
ETSI ISUP V2 data
(or national
equivalent)
Logical Call Content Channel (CCC)
comprising either one physical CC X.25 / IP
link or two (one per direction)
Transit networks
PSTN/ISDN PSPDN
Links to LEA site
(PRI, BRI or analogue) X.31 X.25 / IP
Law
Enforcement FTAM / FTP
responder
Agency (LEA)
Recorders
Figure 159: Network configuration used to support Lawful Interception

F14.2.2.2 Generic CS2000 Support

This section discusses the characteristics and use of the Lawful Interception channels used
by CS2000 to deliver intercepted call content and call-related data to the LEA:
! Call Content Channel (CCC) for packetised voice
! Call Data Channel (CDC) for call-related data
Characteristics and use of the CCC:
! Call content is intercepted by means of Centralised Replicator (CR) functionality
provided by the UAS. A monitored call is routed through the CR, which copies the
call content and uses the CCC to relay it from the UAS to the LEA.
! A CCC for intercepting voice and in-band data comprises either a single physical
CC link or two separate CC links, one for the transmitting packet network speech
path and one for the receiving path.
! The logical CCC between the UAS and the LEA comprises three physical segments:
" A connection across the packet network between the UAS and a media
gateway supporting interconnection with the LEA-facing transit network.
" One or two dial-up connections across the PSTN. For each CC link, the LI
service initiates call setup from the LEA media gateway towards the LEA
using a TDM-side CCS7 trunk, e.g. ETSI ISUP or a national CCS7 variant.
" The final segment of the connection for each CC link, between the PSTN and
the LEA site, is provided by an access interface connected to recording
equipment at the LEA site. This LEA access interface can be PRI, BRI or
analogue lines. In general, this segment is not connected to or controlled by
CS2000.
Characteristics and use of the CDC:
! Call-related data is delivered towards the LEA via an X.25 switched virtual circuit
(SVC) or a TCP/IP connection set up by the LI service.
! The X.25 circuit or TCP/IP connection for the CDC is provided by the SDM
(SuperNode Data Manager) platform co-located with the CS2000.
! Call-related data is downloaded in either of two ways:
" Over the X.25 circuit, using the FTAM (File Transfer Access and
Management) protocol on top of X.25.
" Over the TCP/IP connection, using the FTP (File Transfer Protocol).
In both cases, the transit network is a packet-switched public data network
(PSPDN).
! The final part of the connection for the CDC link, between the PSPDN and the LEA
site, is provided via an X.25 PSPDN access circuit, via a TCP/IP PSPDN
connection, or via X.31 ISDN access (i.e. a BRI line).
! For each relevant event occuring during an intercepted call, a CDR (Call Data
Record) is generated, formatted and transmitted to the LEA via the CDC.
Depending on the type of event, the CDR may be a BEGIN, CONTINUE, END or
REPORT record. If there are transmission problems, CDRs are buffered so that
re-transmission can be attempted.

Feature activation while a call is being monitored is appropriately reflected via the CCC
and CDC. If a party being monitored is put on hold, for example, the CCC recording
would register silence, and a CDR CONTINUE record would be generated to record Call
Hold activation. The LI service can also be used to monitor the (de)activation and
interrogation of services by an LI target.
The service logic for Lawful Interception is distributed between the CS2000 Core, the
SDM and the UAS, i.e. each of these network elements implements a different part of the
LI application.
Specially authorised operators at the telco site use the LI provisioning interface on the
CS2000 to provision monitoring orders against a target, i.e. to specify access interfaces to
be monitored. At the CS2000, the LI application then sets up a CCC and CDC whenever
there is a call to or from a target. As an option, operators can limit monitoring to the
delivery of call-related data, with no recording of call content, or vice versa.
The table below summarises the access interfaces for which CS2000 allows Lawful
Interception to be specified in ISN07, and the other interfaces for which interception of
calls to/from a monitored access interface is supported. See A59024510 for more details.
IBN line ETSI ETSI

Monitoring supported
Can be for calls to / from (Centrex PRI ISUP ISUP SIP-T
specified for or CEPT) [1] V2 V1
Lawful Interception
IBN line
Yes Yes Yes Yes Yes
(Centrex or CEPT) [1]
PRI access Yes Yes Yes Yes Yes

[1] LI supported for IBN lines supported by the following gateway types:
- MTA (cable access)
- Customer LAN access
- V5.2
Note: Lawful Interception is supported not only for calls between two media gateways
served by the same CS2000, but also for calls interworked to another CS2000 by means
of ISUP signalling encapsulated in SIP-T. See A59035246 for further information.

F14.2.2.3 Generic ETSI Requirements for LI

With effect from ISN07, the CS2000 implementation of LI has been enhanced to make it
compliant with the ETSI LI requirements specified in ETSI TS 101 331 and ETSI ES 201
671. ETSI defines three logically separate Handover Interfaces (HIs) to be used for
providing information to the LEA. Requirements are also specified for the information to
be collected for basic calls and service interactions. The ETSI-defined HIs are:
! HI1 Interface
A bidirectional interface used to pass requests from LEA to NWO/AP/SvPs. The
information passed includes LI monitor order activation and deactivation.
! HI2 Interface
A unidirectional interface used to pass Intercept Related Information (IRI), e.g. data
associated with the communication service of the target and standard network
signalling information from the NWO/AP/SvPs IIF to LEMF. This corresponds to
the Call Data Channel (CDC) in the Nortel implementation.
! HI3 Interface
A bi-directional interface used to pass call content of intercepted service to LEMF.
This corresponds to the Call Content Channel (CCC) in the Nortel implementation.
A00002965 delivers SDM aspects of ETSI compliance for LI by implementing the HI1
and HI2 interfaces. Its main focus is on how LI on the SDM will deliver ETSI IRIs to the
LEAs. It implements ETSI-provided definitions of operations to be used to pass IRI.
A00003514 delivers Core aspects of ETSI compliance for LI by implementingETSI ISUP
protocol changes (to the layout of Calling and Called Party Subaddressing) necessary to
set up call content delivery for targeted calls (the HI3 interface) and to provide required
information about monitored calls and about service interactions for such calls.
F14.2.2.4 LI Implementations for Specific National Markets

Different countries have different requirements with respect to specific aspects of LI
functionality. The LI service base was initially developed to meet German regulatory
requirements, but its modular design comprises a number of different functional
components, and the service can be easily tailored for deployment in any other country by
enabling or disabling these components as required.

F14.3 Charging and Billing Features

F14.3.1 Network Advice of Charge (NAOC)
For NAOC, call charges are calculated centrally at a Charge Determination Point (CDP),
and call charge information is then passed to the originating node to be relayed back to
the calling user over the access interface. The originating node is referred to as a Charge
Generation Point (CGP). The primary purpose of NAOC is to allow the user to be notified
of call charges even if these are calculated at a different node (typically when the user has
selected an alternative carrier for a call, in which case CDP functionality is provided by
that carriers network).
ISN06 feature A89007454 extended the existing NAOC implementation as follows:
! Improved support for all call types
" Allows the handling of an increased number of tariff indices (up to 1022) and
tariffs (datafilled in tables TARFINDX and TARFDATA).
" Allows the handling of an increased number of NAOC zones (up to 1022)
that can be used for all zoning tables (TARFINDX, NATLZONE,
LOCLZONE, SERVZONE, and INTLZONE).
! Improved support for service calls
" Allows the handling of an increased number digits (up to 24 digits) for the DN
used with service calls (table SERVZONE).
" Allows the handling of an increased number of service numbers (up to
4,194,303 tuples) per CS2000.
" Introduces the support of discounted service calls.
! Improved support for international calls
" Allows the support of a finer zoning model with up to 9 tuples per
Carrier/Reseller and up to 163 entries per tuple
! Improved tariffing support
" Allows the handling of an increased number of Tariff Changeovers (up to 30)
per CS2000
" Allows the handling of an increased number (up to 204) resellers per CS2000
node
! Improving NAOC/PCA essential functionality
" Extends NAOC essential functionality to support calls from all NAOC
originators to any supported terminating agent
" Extends PCA essential functionality to support from all PCA originators to
any supported terminating agent
CS2000 can provide AOC information only for PRI and QSIG originations; the Payment
Ceiling Advice (PCA) feature was developed as an alternative to track monthly bills for
CS2000 subscribers. PCA (see section F14.3.2) extends the NAOC functionality and can
make use of the improvements listed before.

F14.3.2 Payment Ceiling for Analogue Lines (PCA)

PCA is used in conjuction with NAOC to support:
! Prepaid services
! Tracking the subscribers phone bill
! Discount notifications
PCA allows network operators to meet German regulatory requirement TKV18.
An analogue line subscriber with Line Class Code (LCC) IBN may request that the PCA
option be added to his or her primary directory number (DN). When ordering this service,
the subscriber must specify the payment ceiling amount to be applied to each billing
period (the billing cycle is generally every 29-32 days, i.e. monthly, but as far as the PCA
feature is concerned it can be any period of the year). The PCA feature impacts the
subscriber in three different ways:
! If call charges incurred to date in the billing period amount to 80% or more of the
payment ceiling, an announcement to this effect is played to the subscriber when he
or she originates a non-emergency call attempt. The announcement is played after
all digits have been collected but before call routing. Following the announcement,
the call is routed as usual.
! If call charges incurred to date in the billing period reach 100% of the payment
ceiling while a call is in progress, an announcement to this effect is played to the
subscriber during the call. This announcement is not audible to the other party, and
the call remains connected after the announcement has been played.
! If call charges incurred to date in the billing period amount to 100% or more of the
payment ceiling, an announcement to this effect is played to the subscriber when he
or she originates a non-emergency call attempt. The announcement is played after
all digits have been collected but before call routing. Following the announcement,
the call is routed as usual.
The payment ceiling counter is automatically reset back to the provisioned payment
ceiling limit at the beginning of each billing cycle.
The payment ceiling counter, payment ceiling limit, reset group, and timing calculations
are done by CS2000. Call charge information is extracted from Network Advice of
Charge (NAOC) data available in the own network (combined CGP/CDP scenario) or
received from another operator via a ISUP APM message (separate CGP and CDP nodes).
Announcements are provided by the Universal Audio Server (UAS).

ISN06 feature A89007461 extended the existing PCA implementation to eliminate some
limitations and restrictions and be fully compliant to the German Telecommunication
Decree TKV 18. Specific enhancements:
! Mid-call announcement support
" Playing a mid-call announcement if the payment ceiling limit is reached
during a call.
! Selective forced release
" Selective forced release functionality (call setup) to disconnect
limit-exceeded subscribers for specific call classes at the beginning of a call
" Selective forced release functionality (mid-call) to disconnect limit-exceeded
subscribers for specific call classes during an active call
! Improved scalability
" Allowing PCA call charges to be tracked for multiple lines / DNs against one
PCA base DN.
" Introducing PCA support for charge-free numbers.
" Introducing support for all world currencies types
! Improved agent support
" For the nodal version (combined CGP/CDP tariffing source), PCA
functionality is enhanced to support interworking with all ETSI ISUP agents,
including national variants.
" PCA functionality available to V5.2 IBN originating agents.
F14.3.3 Notification of Time and Charge (NTC)

Notification of Time and Charge is a service provided over JI-ISUP trunks for IDC
residential subscribers in Japan.
A call can be registered as an NTC call in either of two ways:
! The subscriber can enter the NTC activation code before dialling destination digits.
! The call can encounter the NTC feature during translations.
The effect of a call being registered as an NTC call is that the subscriber will automatically
be called back after the call has been cleared, and an announcement will then be played to
provide the subscriber with information such as the destination address digits, the duration
of the original call and the amount charged. The English version of the announcement is
as follows (the language actually used will reflect the subscribers location and
preferences):
This is IDC. The international call you have just made to A the number B was C
hours D minutes E seconds long and cost F yen. Repeat, C hours, D minutes, E
seconds long and cost F yen. Thank you for using IDC. This is a recording.
The return call is made over JI-ISUP, and the information provided in the announcement
is derived from the AMA record for the original NTC call.
See A00002756 for a more detailed description.

F14.4 Network Interconnect Features

Network interconnect features allow alternative operators to compete with the PTT (or its
privatised successor) in a deregulated national market. See Chapter F11: Indirect Access
for a detailed discussion of the capabilities summarised in sections F14.4.1 to F14.4.3.
F14.4.1 Basic Interconnect

Alternative national operators use network interconnect trunks for calls where
authorisation checks are not required, e.g. calls originating in the alternative network and
terminating in the PTT network.
Network interconnect trunks are also used by alternative local operators, typically cable
TV companies, who provide direct line and PBX connections for residential and business
subscribers in competition with the PTT. Such operators must support access to a national
long-distance network for their customers, and for this purpose they negotiate bilateral
network interconnect agreements with national operators.
F14.4.2 Indirect Access

Indirect access services enable alternative national operators to provide long-distance
carrier capability in competition with the PTT (or its privatised successor), and to compete
with the PTT by guaranteeing lower long-distance charges for business customers and
residential subscribers. They are therefore extremely important in enabling alternative
national operators to establish themselves in deregulated telecommunications markets.
F14.4.3 Carrier Selection

In a national network where there is more than one AO, and where the capacity of a given
CS2000 may be shared between AOs, carrier preselection mechanisms are required to
ensure that every CS2000 can identify the operator who should handle a given call, and
can route and bill the call accordingly. This functionality is a regulatory requirement in
markets such as Germany.
Generic CS2000 carrier (pre)selection capabilities allow network operators to define up
to seven different carrier pre-selection call types (plus the default/generic call type ALL).
A subscriber can then choose which carrier to use for each call type. The call type of each
outgoing call is determined during translations, which causes the appropriate CIC (Carrier
Identification Code) to be retrieved and used.
F14.4.4 Carrier Name Notification (CNN)

Carrier Name Notification is a Japanese regulatory service that complements carrier
selection by playing back a confirmation announcement to the caller when a CPS call
reaches the selected carrier network, as specified in the Transit Network Selection (TNS)
parameter of the JI-ISUP IAM used to set up the call. See A00002756 for a more detailed
description.
F14.4.5 Account Code (ACCT)

ACCT is a Japanese regulatory service that complements indirect access by causing a
subscriber to be prompted to provide an account code before a call being set up using
JI-ISUP is allowed to continue. The CS2000 that receives the IAM for the call uses the
customer group and NCOS for the call to determine whether an account code is required.
See A00002756 for more details.

F14.4.6 Number Portability
F14.4.6.1 Overview
Number portability allows a subscriber to change network operators, i.e. to be served by
a CS2000 belonging to a different operator, while retaining the same Directory Number
(DN) as before the move. Support for number portability is a critical factor in enabling
alternative network operators to attract both business and residential customers from the
established national network.
Numbers moved between network operators in this way are referred to as ported
numbers. Such ported numbers may be geographic numbers identifying individual lines
or PBXs, or non-geographic numbers identifying Freephone or special-rate services. The
porting of geographic numbers is referred to as Local Number Portability (LNP).
A CS2000 that is to support number portability must have access to a database that
provides the following information:
! A list of ported numbers.
! For each ported number, the identity of the network that currently serves the ported
number.
! Information about how to route calls to each network serving porting numbers.
The CS2000 must also have some mechanism for determining when ported number
database queries should be made.
Figure 160 illustrates the operation of the number portability service at a logical level, for
a CS2000 with its own number portability database.
Incoming Database Onward Outgoing

call leg query routing call leg
Number portability
database
Three functions:
To identify any number that has
been ported.
To indicate which network
currently serves the ported
number.
To route calls to ported numbers
to the appropriate network.
Figure 160: Logical operation of the number portability service
Note: It is also possible to support number portability as an IN (Intelligent Network)

service. In this case, the database of ported numbers is maintained centrally by an SCP,
and CS2000 initiates an IN query to the SCP when it recognises a number as ported.

F14.4.6.2 CS2000 Implementation of NP (PNSCRN/PNINFO)

CS2000 supports a generic number portability implementation that can be adapted to meet
different national requirements.
Figure 161 summarises this generic CS2000 implementation of the number portability
service, showing the two tables that make up the local database and the different methods
of triggering number portability queries for incoming calls. The implementation is
described in more detail on the following pages.
CS2000
Two ways to trigger queries:

PNRF selector encountered in translations.
NICRF selector encountered in translations
(NIC already known, e.g. for transit call)
NICRF
Incoming
call leg PNRF Onward Outgoing
routing call leg
Table PNSCRN
Ported
DN in/out NIC
Table PNINFO
NIC XLA Options
Figure 161: CS2000 implementation of the number portability service

The CS2000 number portability database comprises two tables:

! PNSCRN (8 million tuples)
Table PNSCRN can contain up to 8 million entries, each providing the following
information about a ported number or a ported range of numbers.
" DN
The number or range of numbers to which the information applies. A range of
numbers can be specified by means of its most significant digits, which allows
information about a block of numbers such as the DDI numbers for a PBX to
be specified by means of a single entry.
" Ported in/out
An indication of whether the range of numbers has been
# Ported out of this network
# Ported in to this network
# Ported between two other networks
Ported numbers are also identified as geographic numbers or non-geographic
service numbers.
" NIC
A Network Identification Code (NIC) for use in routing a call to a ported
number on to the network that now serves the ported number. NIC is a Nortel
term; the equivalent ITU term is Network Routing Number (NRN). An
NIC/NRN identifies an entity to which a call should be routed, which may be
a network, a switch, or a point of interconnection. For the outgoing call leg, it
is typically provided as a prefix to the called party number. The information
to be provided by an NIC is determined by the national regulator, e.g. it might
simply identify a network operator or it could specify a particular switch
belonging to an operator.
CS2000 supports NICs with up to nine digits. A digit may be a digit in the
range 0 to 9, or one of the over-decadic digits B to F. Over-decadic digits are
used in some markets to identify ported calls. CS2000 therefore supports
translations for numbers beginning with over-decadic digits other than A.
The NIC for a ported (range of) numbers provides a pointer into table
PNINFO to retrieve call routing iunformation.
! PNINFO (1 million tuples)
Table PNINFO can contain up to 1 million entries, each providing routing
information for a particular NIC. Specifically, each entry identifies a translation
system and translator to be used for handling rerouted number portability calls.
In addition, the following options may be associated with PNINFO entries:
" RTEIDX, which specifies a new DEST, overwriting the DEST option from
the xxHEAD/xxCODE tuple that triggered the number portability query.
Together with the specified translator, this provides an index into table
xxRTE. (RTEIDX is mutually exclusive with XLA.)
" XLA, which initiates retranslation for a ported call via tables
xxHEAD/xxCODE, using the specified universal translator. (XLA is
mutually exclusive with RTEIDX.)
" RESCHECK, which allows calls to be routed to ported-in numbers served by
the CS2000 itself.

" SETCDN, which allows called party number characteristics (e.g. NOA) to be
modified for the outgoing call leg.
" NONICPFX, which prevents the NIC from being prefixed to the called party
number in translations, or captured in the Terminating Open Digits field of the
AMA record for the call.
" NICOUT, which delays the prefixing of the NIC to the called party number
until immediately prior to digit outpulsing. This also prevents the NIC being
captured in the Terminating Open Digits field of the AMA record for the call.
" AMAXLAID, which specifies an index into table AMAXLAID that can be
used, for example, to trigger an AMA record or change the call code.
" NPBILL, which causes the NIC and related number portability information to
be stored in a Type 611 AMA module.
Note: Table PNSCRN should have entries for every ported DN that a given operators
switches may encounter. Its contents should therefore be identical for all the
Communication Servers owned by a given operator, and it is expected that this will be
achieved by frequent co-ordinated downloads. The contents of table PNINFO, on the
other hand, will vary from CS2000 to CS2000 because routing information is
node-specific; this information, however, is relatively stable.
Database queries can be triggered in either of two ways:
! PNRF selector encountered in translations
Table PNSCRN is checked when the PNRF selector is enountered in an xxHEAD
or xxCODE table during translations.
The INSNNG (Insert National Numbering Group) refinement of PNRF allows calls
originating from local lines to be prefixed with the National Numbering Group (also
referred to as the Area Code) prior to the search of table PNSCRN. If a match is
found in table PNSCRN for the prefixed number, the prefix is retained for the
remainder of translations.
! NICRF selector encountered in translations
If the NIC for a call to a ported number is already known, it is possible to bypass
table PNSCRN and proceed directly to the retrieval of routing information from
table PNINFO. This would typically be the case with a transit call, where a
preceding switch has already determined that the called party number is a ported
number and prefixed it with the correct NIC. Such direct access to table PNINFO is
triggered when the NICRF selector is enountered in an xxHEAD or xxCODE table
(RTE or CONT selectors) during translations.

F14.5 Miscellaneous Features

F14.5.1 Call Forward Restrictions for Hong Kong
Capabilities introduced to meet Hong Kong requirements for restrictions on forwarded
calls and Call Forward programming (see A59040509 for details):
! TRKOPTS option CFR (Call Forward Restriction) causes an incoming ETSI ISUP
or IBN7 (ANSI ISUP+) call to be routed to NACK treatment if it has been
forwarded, i.e. if the IAM contains Original Called Number, Redirecting Number
or Redirection Information.
! Table LNCFPBAR can be used to define sets of leading digits that will not be
accepted if an attempt is made to enter a DN beginning with those digits as a number
to which calls should be forwarded.
F14.6 Order Codes for Regulatory Services
Table 69: Order codes for regulatory services software

ILIN0009 Regulatory Line Features
INLI0002 International Lawful Interception
NETK0019 Network Advice of Charge
NETK0024 Network AOC Tariff
NETK0028 CGP Network AOC
IXLS0007 ETSI ISUP V2 Carrier Selection and Preselection
IXLS0002 Service Number Portability and Number Portability Provisioning
NSUP0016 CCBS SCCP Support for Local Number Portability
NSUP0017 Payment Ceiling Advice (PCA)
NSUP0020 NAOC / PCA Enhancements

Chapter F15 Multimedia Services for
Blended Users
F15.1 Introduction
Multimedia services enable blended users to have screen-based interactive access to
databases and media sources while simultaneously participating in a VoIP phone call. The
interactive access and use of the phone are co-ordinated. In the case of a call between two
blended users, interactive collaboration is possible because both users are operating in the
context of the same multimedia session.
The following list summarises some of the multimedia service capabilities that can be
made available to blended users.
! For a call between two blended users, e.g. between two users belonging to the same
enterprise network, various types of interactive collaboration are possible:
" File transfer
" Web push
" Whiteboard sharing
" Clipboard transfer
" Instant messaging
! For a call from a non-blended user to a blended user, e.g. an incoming call to a
multimedia-enabled call centre, the call centre agent is connected to a multimedia
session. Capabilities available include being able to check on-line databases for
information about the caller or information that would enable answers to be
provided to queries from the caller.
! For a call from a blended user to a non-blended user, e.g. a call from a
multimedia-enabled sales centre to a potential customer, the sales agent is
connected to a multimedia session. Capabilities available include being able to
check on-line databases for detailed product and service information, information
about the called party or information that might be of interest to the called party.

Multimedia Services for Blended Users Features and Services Communication Server Capabilities
F15.2 CS2000 Blended User Configuration

In ISN07, multimedia services for CS2000 solutions are provided by the MCS5200
described in Chapter B6: Multimedia Communication Server (MCS52000).
Multimedia sessions hosted by the MCS5200 Application Server enable blended users to
have screen-based interactive access to databases and media sources while
simultaneously participating in a VoIP phone call established via CS2000.
Multimedia services are supported by a MCS5200 RAIDer client on the end users
terminal. When a blended user receives an incoming voice call from CS2000, a client
window pops up on the blended users screen at the same time as ringing is applied to
his/her telephone. The called party can then use this client window to initiate a multimedia
session with MCS5200. If the call is from another blended user, MCS5200 will initiate a
connection to the callers RAIDer client, allowing multimedia collaboration by both users
to take place.
The SimRing feature is used as an underlying blender mechanism to ensure that the
RAIDer client and the telephone are alterted simultaneously.
Support for blender services requires MCS5200 to be connected to CS2000 via a SIP / PRI
gateway (sometimes referred to as a SimRing PRI blender). On the CS2000 side, this is
connected to a PVG gateway via PRI; on the MCS5200 side, the SIP / PRI gateway is
configured as a SIP client. A call to a blended user terminates on the pilot DN ofthe
SimRing group (the subscribers DN), causing CS2000 to apply ringing to the subscriber
line and set up a PRI call to MCS5200. MCS5200 then activates the RAIDer client.
Note: An alternative mechanism is Succession blending via SIP-T, but this is not
formally supported in ISN07. With this, CS2000 responds to an incoming call to a
blended user by using SIP-T to notify MCS5200. MCS5200 then activates the
subscribers RAIDer client and initiates a SIP-T call back to CS2000 so that call setup to
the subscribers line can proceed.
This section provides only an overview. For a more detailed description, see A89008119.

Communication Server Capabilities Features and Services Multimedia Services for Blended Users
Figure 162 illustrates the logical configuration used by CS2000 to give blended users
access to multimedia services.
CS2000 MCS5200
Call processing
GWC GWC RTP

for for DPT SIP Media SIP
trunk line GWC Application Portal PRI
media media Module (media gateway
gateway gateway proxy)
PRI
SIP-T
Backbone packet network
Signalling to/from MCS5200 (SIP)
Multimedia streams to/from MCS5200
Voice bearer connection

across backbone network
PVG
Note: In ISN07, SIP-T signalling between
PRI CS2000 and MCS5200 is not involved in
Access
network supporting multimedia services for
blended users. Call setup between
CS2000 and MCS5200 uses PRI.
Gateway Platform for RAIDer

client can be directly
connected to gateway or
connected independently
(e.g. to customer LAN)
Access to multimedia
services via RAIDer
client window
Blended user
Figure 162: Blended user configuration

F15.3 Call Setup Sequences

F15.3.1 Call between Two Blended Users
Call setup sequence for a call between two blended users, e.g. between two users
belonging to the same enterprise network:
1 Blended user A goes off-hook and dials blended user Bs number (normal call
setup)
2 CS2000 call processing identifies DN of called party B (assumed to be on same
CS2000 as A for simplicity). As B is a blended user, this DN is the pilot DN of a
SimRing group. CS2000 therefore does two things simultaneously:
" Applies ringing to blended user Bs phone (normal call completion)
" Sends a PRI SETUP message to MCS5200 (via PVG and SIP PRI gateway),
requesting it to activate blended user Bs RAIDer client.
Logging and screening are applied to the incoming call, to determine whether call
completion is permitted and provide a record of the call attempt.
3 MCS5200 responds to PRI SETUP message (converted to SIP by the SIP PRI
gateway) by using SIP to open a RAIDer client window (with alerting) on blended
user Bs screen
4 Blended user B uses RAIDer window to initiate multimedia session with MCS5200
5 MCS5200 uses SIP signalling to initiate collaborative call-back to blended user A,
resulting in As RAIDer window opening and alerting. There is no CS2000
involvement in this step.
When the call setup sequence is complete, connectivity is as follows:
! There is a VoIP connection via CS2000 between user As phone and user Bs
phone.
! User A and user B are both have RAIDer window connections to a multimedia
session hosted by MCS5200. Capabilities available to them include:
" File transfer
" Web push
" Instant messaging

F15.3.2 Call from Non-Blended User to Blended User

Call setup sequence for a call from a non-blended user to a blended user, e.g. an incoming
call to a multimedia-enabled call centre:
1 Non-blended user A goes off-hook and dials blended user Bs number (normal call
setup)
CS2000 as A for simplicity). As B is a blended user, this DN is the pilot DN of a
SimRing group. CS2000 therefore does two things simultaneously:
" Applies ringing to blended user Bs phone (normal call completion)
requesting it to activate blended user Bs RAIDer client.
Logging and screening are applied to the incoming call, to determine whether call
completion is permitted and provide a record of the call attempt.
user Bs screen
4 Blended user B uses RAIDer window to initiate multimedia session with MCS5200
phone.
! User B has a RAIDer window connection to a multimedia session hosted by
MCS5200. Capabilities available include being able to check on-line databases for
information about the caller or information that would enable answers to be
provided to queries from the caller. Collaboration is not established between user A
and user B, however, so capabilities such as file transfer and instant messaging are
not available.

F15.3.3 Call from Blended User to Non-Blended User

Call setup sequence for a call from a blended user to a non-blended user, e.g. a call from
a multimedia-enabled sales centre to a potential customer:
1 Blended user A goes off-hook and dials non-blended user Bs number (normal call
setup)
CS2000 as A for simplicity). CS2000 then:
" Applies ringing to user Bs phone (normal call completion)
requesting it to activate blended user As RAIDer client.
user As screen. There is no CS2000 involvement in this step.
phone.
! User A has a RAIDer window connection to a multimedia session hosted by
MCS5200. Capabilities available include being able to check on-line databases for
information about the called party or information that might be of interest to the
called party. Collaboration is not established between user A and user B, however,
so capabilities such as file transfer and instant messaging are not available.

F15.4 Specific Services Supported

Specific multimedia services supported in ISN07:
! MCS5200 personal agent
The subscriber can use the RAIDer client to define rules for the handling of
incoming calls, e.g. to specify that CLI or TOD screening should be applied before
call completion is attempted.
! Dynamic call handling
The subscriber can use the RAIDer client to specify what should be done with a
particular incoming call when alerting takes place, e.g. redirect, ignore or transfer.
! Presence management
The subscriber can use the RAIDer client to tell MCS5200 whether he/she is present
and available to answer calls, e.g. the MCS5200 presence indicator can be set to
ensure that incoming calls will not interrupt a meeting. As a refinement, the
subscriber can create a "buddy list" of numbers from which calls will be accepted
regardless of the setting of the MCS5200 presence indicator.
! Incoming call logging
Call logging preserves information about all incoming calls, including unanswered
calls. The subscriber can use the RAIDer client to retrieve call information and take
appropriate action, e.g. add caller information to address book or click to initiate a
return call.
! Picture Calling Line Identification (PCLI)
MCS5200 can be used to maintain a list of callers for whom images are stored on
the subscribers PC for used in picture-based caller identification. When there is an
incoming call from someone on the subscribers PCLI list, the stored image for that
caller is presented on the subscribers screen.
Note: A PCLI calling party must not be a blended user.
! Collaboration
" File transfer
" Web push
" Instant messaging
Note: In ISN07, MCS5200 must be provisioned with a list of the IP addresses of
the blended users with whom each subscriber can collaborate.

Chapter F16 ADSL Data Sessions
With effect from ISN07, CS2000 supports ADSL (Asymmetrical Digital Subscriber Line)
access to the backbone packet network for data sessions with private intranets and/or the
public internet.
ADSL support is provided by large carrier-located line media gateways (MG9000s), as
described in section B2.8 on page 119.
Digital Subscriber Line technology exploits unused frequencies to support simultaneous
transmission of voice and high-speed data over conventional copper telephone lines. The
service is "always on", meaning that subscribers don't need to dial in or wait for call
set-up.
ADSL is so called because it allows data to be downloaded much faster than it can be
uploaded (6Mb/s downloading vs 640Kb/s uploading), reflecting what users typically
require. ADSL is defined in ITU-T Recommendation G.992.1 and ANSI Standard
T1.413-1998.

Chapter F17 RAS (Remote Access
Service)
F17.1 Overview
RAS (Remote Access Service) means support for dial-up access to internet and/or intranet
sessions. CS2000 supports it by means of TDM-side CCS7 trunks terminated on the
CVX1800 media gateway described in section B2.11 on page 130. Because CVX1800
can also support VoIP voice calls, it is said to provide Universal Port (UP) capability.
Note: CS2000 support for UP capabilities has been tested and verified for deployment
only in a specific customer network, and is not generally available in ISN07.
The protocol used for RAS signalling between the GWC and the CVX1800 UP gateway
is DSM-CC version 5.2, as described in Chapter D13: DSM-CC.
tell the CVX1800 to terminate the call on one of its modem ports, and to specify the
internet / intranet destination (IP address and port number) with which a data session
should be initiated.
RAS functionality is provisioned by datafilling the RAS access code (ISP DN) on the FTR
selector of a customer group in table IBNXLA.
Note: RAS calls are single-ended, i.e. only the originating CVX1800 gateway is
involved.
Pre-authorisation is performed by a CVX Policy Manager (CPM) attached to the
CVX1800. Caller authentication and authorisation is performed by a Remote Access
Dial-In User Services (RADIUS) server connected to the internet / intranet destination.
When a session has been established, a dial-up user can download and upload data, send
and receive email, and make use of shared resources. When a session is complete, the
RADIUS server provides call accounting information to the network operator or ISP.

RAS (Remote Access Service) Features and Services Communication Server Capabilities
Figure 163 illustrates the logical network configuration used to provide RAS support for
a CS2000 solution. RAS bearer traffic from the PSTN terminates on a modem port in the
CVX1800, from which a connection is set up to the customers IP network or to the public
internet. Network signalling between the PSTN and CS2000 can be either IUP (BTUP) or
UK ISUP.
CCS7 signalling CS2000

Packet network control signalling Call processing
TDM bearer channels Access

CCS7 GWC for
Signalling
Packet network bearer connections gateway;
Gateway RADIUS
(SG) Ingress
TDM-side server
GWC-gateway
signalling
(DSM-CC)
CVX
Policy RAS authentication
PSTN CCS7 Manager
signalling (CPM)
(IUP / ISUP)
IP core network
Intranet data session
PSTN CVX1800
PSTN bearer channel RAS
media
gateway
Internet data session
Internet
Figure 163: CS2000 support for RAS via CVX1800 gateway
The CVX1800 uses DMS-CC messages to keep the GWC informed about the availability
If no RAS modems are available, the GWC will not initiate any new RAS calls, but can
continue to initiate VoIP calls. Similarly, if no VoIP modems are available, the GWC will
not initiate any new VoIP calls, but can continue to initiate RAS calls. If no front-end
processor is available, no new calls of either type will be initiated.
received by a CVX1800, CS2000 indicates this by sending back an REL message with a
release cause of CI_TEMPORARY_FAILURE (for a UK ISUP call) or

Communication Server Capabilities Features and Services RAS (Remote Access Service)
F17.2 Virtual Points of Presence (VPOPs)

The closer a CVX1800 supporting RAS can be deployed to the dial-up users it serves, the
greater are the savings it can offer those users because dial-up data calls are billed at local
phone rates. A CVX1800 deployed remotely from the CS2000 but close to a group of
users is referred to as a Point Of Presence (POP) for that CS2000. Network operators who
are planning to offer RAS should deploy their CVX1800s in locations where there are
enough local subscribers to justify the cost of the equipment.
A further refinement is the use of Virtual Points Of Presence (VPOPs). A CVX1800 can
be partitioned into a number of virtual remote access switches or VPOPs, each dedicated
to the use of a particular ISP. A network operator or ISP wholesaler can thus use a single
CVX1800 to provide leased RAS capabilities for a number of different ISPs.
Configuring a VPOP involves providing the following information:
! Details of the RADIUS server to be used for authorisation and accounting
! The maximum number of concurrent sessions to be supported
As a result of the configuration process, each VPOP is assigned a unique VPOP ID and a
pool of IP addresses that can be dynamically assigned to dial-up users.
When a dial-up user connects to a CVX1800, the CVX1800 initiates a session that
connects the customer to a specific VPOP. Typically, the user is mapped on to the
appropriate VPOP by means of the number he/she has dialled. In the case of a CVX1800
configured to support pre-authentication, the CVX1800 sends the dialled number (as a
user name) directly to an authentication server before accepting the call. If the dialled
number matches, the authentication server returns the corresponding VPOP ID in the
response and a call is set up to that VPOP. The RADIUS server associated with that VPOP
will prompt the user to provide a user name and password before allowing the call to be
completed.

Part G
Network Fit
CS2000 International Product Description Part G Chapter G1
Communication Server Capabilities Network Fit Numbering Plan
Chapter G1 Numbering Plan

G1.1 Public Numbering Plan
G1.1.1 Support for Geographic Numbers
CS2000 supports translations and routing for normal geographic numbers, i.e. PSTN
numbers that reflect subscriber locations, as described in Chapter C3: Translations and
Routing on page 204. Either of two types of numbering plan may be used:
! Plans in which numbers have no more than 10 digits (see section G1.1.1.1).
! Open Dial Plans (ODPs) in which subscriber numbers may have different lengths
and may have more than 10 digits (see section G1.1.1.2 on page 725).
G1.1.1.1 Numbering Plans with up to 10 Digits

CS2000 supports numbering plans with up to 10 significant digits (i.e. omitting the trunk
prefix digit 0).
CS2000 translations and routing were originally based on the North American (NA)
number format. NA numbers all have 10 digits, and consist of the following elements:
! The Numbering Plan Area (NPA) code, which has three digits.
! The Office Code (NXX), which has three digits.
! The extension number, which has four digits.
NA subscriber DNs are all seven digits long, and consist of the office code plus the
extension number.
This fixed-length 10-digit numbering plan can be adapted for use in any international
market, provided that no number has more than 10 digits. The mechanisms available are:
! For national networks where all numbers are the same length, e.g. 8 or 9 digits, all
numbers can be automatically padded out to 10 digits by means of a digit (typically
0) specified via the office parameter DN_PADDING_DIGIT.
! For national networks where number length may vary, each number can be
individually padded out to 10 digits when it is datafilled.

Chapter G1 Part G CS2000 International Product Description
Numbering Plan Network Fit Communication Server Capabilities
G1.1.1.2 Open Dial Plans (ODPs)

CS2000 supports Open Dial Plans based on the E.164 numbering scheme defined by the
ITU-T. This specifies that international numbers may have up to 15 digits, consisting of
a Country Code (1-3 digits) followed by a National Significant Number (12-14 digits).
The NSN is further broken down as follows:
! National Dialling Code (NDC) with 1-7 digits
! Subscriber Number (SN) with 1-13 digits, comprising
" Office code with 0-7 digits
" Station code with 1-8 digits
The table below compares the variable-length E.164 number format with the fixed-length
10-digit NA format.
E.164 number format North American number format

Digits Element Element Digits
1-3 Country code Country code 1-3
1-7 National dialling code Area code 3
0-7 Office code Office code 3
1-8 Station code Extendsion number 4
2 < 14 National Significant Number. National number 10
3 < 15 International number International number 11 - 13
Note: It is important to understand the difference between a numbering plan (datafilled

DNs) and a dialling plan (numbers used in translations and routing). Dialling plan
numbers can be longer than datafilled DNs because they can include prefix digits such as:
! 0/00 for national/international numbers
! NIC for LNP (can be up to 9 digits in some countries)
! CIC for CPS (up to 6 digits)
! Access codes for services or indirect access
! Information prefixed for routing purposes
Such prefix digits are only used only in routing a call; they are not part of the actual
destination phone number. They are only used during translations and routing, and are
discarded before routing to the final DN. CS2000 supports translations and routing for
numbers with up to 30 digits.
Availability of ODP support is controlled via SOC option NPE00003. It is implemented
by means of standard line datafill, as follows:
! Serving NPA (SNPA) codes are defined in tables HNPACONT and SNPANAME.
Up to 128 SNPAs can be defined on a given CS2000.
! Each line is assigned a DN either in table IBNLINES.
! The IBNLINES entry that assigns the DN also specifies the SNPA to which the line
belongs.
Variable-length E.164 DNs can also be defined for PBX users served by PRI DDI trunks.
Support for variable-length E.164 numbers also implies that features and services should
work correctly on calls to/from subscribers with E.164 numbers. Nortel is committed to
an extensive testing program to verify that this is the case. See section G1.1.6 on page 728
for a list of services whose operation has been verified for ODP compatibility.

G1.1.2 Non-Geographic Numbers and Services

In addition to subscribers whose numbers reflect their location, the CS2000 must be
capable of serving a number of special non-geographic numbers. The most important
types of non-geographic number are listed below.
! Non-chargeable network services, e.g. 112 as the EU standard for emergency calls
! Chargeable network services, e.g. operator services and directory enquiries
! Access to alternative operators networks
! Access to cellular/mobile networks
! Freephone services
! Cheap access services (all calls billed as local)
! Chargeable radio paging
! Premium Rate Services (e.g. chatlines)
CS2000 provides support for non-geographic number services such as FreePhone by
means of standard translation and routing capabilities. An incoming call with a
non-geographic prefix such as 0800 (FreePhone) or 0891 (UK Premium Rate) is
recognised during translations and routed to a node that actually implements the service.
CS2000 is not responsible for service logic or service-related billing functionality
(although a billing record will be created).
CS2000 Intelligent Network (IN) capabilities can also be used to support IN-based
implementations of Number Translation Services (NTS) such as FreePhone. As with
non-IN service implementations, CS2000 does not provide the service logic. Instead, it
recognises such calls on the basis of the dialled prefix, and sends a query to a central IN
Service Control Point (SCP) to find out where they should be routed. See Chapter E3:
INAP for more information.
G1.1.3 International Calls

International calls require an international prefix, then a country code and destination
digits. In Europe, for example, the international prefix 00 is used for voice calls and the
IEC prefix 000 is used for direct-dialled international ISDN calls.
International numbers may have up to 15 digits, consisting of a Country Code (1-3 digits)
followed by a National Significant Number (12-14 digits).
CS2000 support for international numbers is fully compliant with International Direct
Dialled Digits (IDDD) requirements and with ITU-T Recommendation E.164.

G1.1.4 CS2000 Inpulsing/Outpulsing Capacity

CS2000 accommodates the 15-digit International Direct Digit Dialling (IDDD) capability
and provides some extra capacity for additional digits by means of the following
inpulsing and outpulsing capabilities:
Interface Maximum inpulsed digits Maximum outpulsed digits

ISUP 30 30
[1]
ACIF G.500 I-ISUP 30 30 [1]
IUP / BTUP 24 [2] 24 [2]
PRI 30 29
QSIG (en-bloc signalling) 30 29
QSIG (overlap signalling) 29 20
[1] ACIF (NIIF) recommendations specify that the maximum number of digits allowed in the CdPN
parameter of an ISUP IAM should be be 16. To support 30-digit CdPNs without exceeding this
limit, CS2000 breaks down any CdPN with more than 16 digits, sending the first 16 digits in an
IAM and the remaining digits in a SAM.
[2] The PNO-ISC specification for IUP specifies a maximum of 20 digits for the Called Party
Address (CdPA) field of an IFAM or IAM. To support 24-digit CdPAs without exceeding this
IUP limit, CS2000 breaks down any CdPA with more than 20 digits, sending the first 20 digits
in an IAM and the remaining digits in a FAM.
G1.1.5 Number Portability

Number portability is a network capability or feature that allows a subscriber to change
network operators, i.e. to be served by a switch or Communication Server belonging to a
different operator, while retaining the same Directory Number (DN) as before the move.
Support for number portability is a critical factor in enabling alternative network
operators to attract both business and residential customers from the established national
network.
Numbers moved between network operators in this way are referred to as ported
numbers. Such ported numbers may be geographic numbers identifying individual lines
or PBXs, or non-geographic numbers identifying Freephone or special-rate services. The
porting of geographic numbers is referred to as Local Number Portability (LNP).
CS2000 supports a generic number portability implementation, which is described in
section F14.4.6 on page 707.

G1.1.6 ODP and Services

Table 70 lists analogue subscriber line services whose operation has been tested for ODP
compatibility. Services not listed may or may not be ODP-compatible, but have not been
explicitly tested.
For CS2000, ODP testing was done using MTA cable lines. The results are believed to be
equally applicable for other line types because ODP issues are related to call processing,
translations and routing in the CS2000 Core, not to specific line access configurations.
Unless there is an explicit statement to the contrary, ODP compatibility has been verified
for numbers with up to 30 digits. The statement that a given feature is compatible implies
that feature (de)activation and programming (if applicable) are also compatible.
Table 70: Service compatibility with an Open Dial Plan (ODP)

Compatible
Service Notes
with ODP?
Call Barring and Restrictions
DOR (Denied Origination) Y
DTM (Denied Termination) Y
PLP (Plug Up) Y
SUS/RES (Suspend / Resume) Y
RSUS (Requested Suspension) Y
NCOS (Network Class Of Service Screening) Y
MSB/DND (Make Set Busy / Do Not Disturb) Y
SACB (Subscriber Activated Call Barring) Y
DMCT (Deny Malicious Call Termination) Y
Speed Calling Services
AUL (Automatic Line) Y Max. 18 digits
WML (Warm Line) Y Max. 18 digits
LNR (Last Number Redial) Y
SCS (Speed Calling, Individual Short List) Y
SCL (Speed Calling, Individual Long List) Y
Call Forward Services
CFU (Call Forward Unconditional) Y
CFB (Call Forward on Busy) Y
CFD (Call Forward on Doesnt Answer), Y
CFWANN (Call Forward with Announcement) Y
CFWVAL (Call Forward with Validation) Y
CFDVT (CFD Variable Timing) Y
CFCW (Call Forward of Call Waiting Calls) Y
Call Handling
Includes Call Waiting
CWT (Call Waiting) Y
Conference (CWTC)
CCW (Cancel Call Waiting) Y
CHD (Call Hold) Y


Compatible
Service with ODP? Notes
CXR (Call Transfer) Y

3WC (Three-Way Call) Y Includes Consultation Hold
3WC Chaining Y Max. 27 digits
CPU (Call Pick Up) Y
PRK (Call Park) Y
Hunt Groups
DNH (Directory Number Hunting) Y
CIR (Circular Hunting for DNH group) Y
PRH (Preferential Hunting within DNH group) Y
DLH (Directory Line Hunting) Y
MLH (Multi-Line Hunting) Y
LOD (Line Overflow to DN for hunt group) Y
LOR (Line Overflow to Route for hunt group) Y Max. 23 digits
BNN (Bridged Night Number for DLH group) Y
Call Distribution
UCD (Uniform Call Distribution) N
Voice Mail
MWI (Message Waiting Indicator) Y ODP compatible for
Stuttered dial tone for analogue lines line-to-line calls.
Party Information Services
CLASS DDN (Delivery of Diallable Number) Y Max. 24 digits [1]
CLASS CND (Calling Number Delivery) Y Max. 10 digits [1]
CLASS CNAMD (Calling Name Delivery) Y
CLASS CNDB (Calling Number Delivery
Y
Blocking)
CLASS CNAB (Calling Name Blocking) Y CND must be suppressed
CLASS SUPPRESS (number/name
confidentiality)
Screening Services
ACRJ (Anonymous Call Rejection) Y
SCRJ (Selective Call Rejection) N
SCA (Selective Call Acceptance) N
SCF (Selective Call Forward) N
Call Completion / Call Return
ISDN CCBS (Call Completion to Busy
Y
Subscriber)
AR can be assigned to lines
CLASS AR (Automatic Recall / Call Return) Y with DNs 2-15 digits in
length; CLIs to be called
CLASS ARDDN (Automatic Recall of Diallable back can have up to 18
Y
Directory Number) digits. See A59038837.


Compatible
Service with ODP? Notes
Regulatory Services
Centrex CLF (Calling Line Flash for MCID) Y
ELN (Essential Line) Y
CS (Carrier Selection) Y CIC plus 30-digit DN
LNP (Local Number Portability) Y
Network Services
DID (Direct Inward Dialling) Y
DOD (Direct Outward Dialling) Y
DISA number plus 30-digit
DISA (Direct Inward System Access) Y
DN
Miscellaneous Services
SDN (Secondary Directory Number) Y See A59034400
WUCR (Wake-Up Call Request) Y
CEPT services
ICWT (International Call Waiting) Y
I3WC (International Three Way Call, including
Consultation Hold) Y
CFU (Call Forward Universal) Y Max. 18 digits

CFB (Call Forward Busy) Y Max. 18 digits
CFD (Call Forward on Doesnt Answer) Y Max. 18 digits
CFRA (Call Forward Remote Access) Y
CCBS (call Completion to Busy Subscriber) Y
MWI (Message Waiting Indication) Y
SCWID (Spontaneous CW with Identification) Y
[1] Limit imposed by service logic, not ODP-related.
G1.1.7 Order Codes for Open Dial Plan Support

Table 71: Order codes for ODP software
NPE00001 Number Plan Evolution 1
NPE00002 Number Plan Evolution 2
NPE00003 E.164 NPE
NPE00004 Enhanced Multiple NPA Support

G1.2 Private Numbering Plans

Each Virtual Private Network (VPN) has its own private numbering plan. There is no
fixed format for private numbering plans, because the flexibility of CS2000 translations
makes it possible to support any required scheme for VPN numbers ranging from 2 to 7
digits in length. Two simple rules generally apply:
! All the numbers in a given VPN are of the same length. Each number is considered
to consist of a prefix plus an extension number. The prefix (location code) may may
identify a physical node, such as a PBX or a Centrex node, or may simply indicate
a logical grouping of extensions.
! The VPN extension number of a given terminal should correspond to the last digits
of the PSTN directory number for that terminal, which is typically a PSTN Direct
Dial Inward (DDI) number.
A user at a VPN terminal normally has the following options available (in addition to
special options such as feature activation codes):
! Dialling a VPN extension number served by the same node (PBX or Centrex node)
and with the same location code, in which case the call is intra-switched with no
PSTN or customer network involvement.
! Dialling a VPN number served by another node, or served by the same node but
with a different location code (the difference is not apparent to the calling user). In
this case, the user must first dial a VPN access digit (typically 6 or 7), then the target
location code, and finally the required extension number.
! Dialling a PSTN number. In this case, the user must first dial a PSTN access digit
(typically 9), then the PSTN number required.
! Dialling 0 to request assistance from an operator or attendant.
Indirect access to a VPN is also possible. In this case, the calling party must dial the VPN
access code and go through any required access authorisation checks (e.g. CLI screening).
When the checks have been successfully completed, the caller has access to the same dial
plan as a directly connected user who has dialled the VPN access digit.
This illustrates the distinction between numbering plans and dialling plans. A numbering
plan defines the national network address of a user. A dialling plan defines the options
available to a user, which will typically include mechanisms for accessing at least one
numbering plan. The distinction is important for VPN users, whose dial plans support
access to two or more networks, each with its own numbering plan, and also a wide range
of special features. It is less important for PSTN users, who are connected to only one
network with one numbering plan, and usually have access to a very limited range of
features.

Figure 164 summarises VPN access and the relationship between private and public
numbering plans.
PSTN
PSTN numbering plan defined by regulator within E.164 framework.
Numbers have three elements:
Area code, i.e. Numbering Plan Area (NPA) or National Number Group (NNG)
Local Exchange Code (LEC)
Local Number identifying subscriber line, PBX or PBX/Centrex DDI extension
Indirect access based on CLI or

dialled authcode is also supported
VPN
No fixed rules for VPN numbering plans.
CS2000 supports numbers with standard length of 2-7 digits,
typically with two elements:
Prefix (location code) identifying node (e.g. PBX) or logical group of lines
Extension number identifying PBX extension or Centrex line
Operator / Operator /
attendant attendant
Originating node Originating node

(PBX or Centrex node) (PBX or Centrex node)
Extension on Extension on
same node same node
and with same and with same
location code location code
Dials Dials Dials Dials Identified by Identified Identified

PSTN VPN operator extension extension by VPN by NNG +
access access assistance only, e.g. only, e.g. prefix + LEC +
code, code, code, e.g. 4567 4567 extension extension
e.g. 9 e.g. 6 0
VPN extension usually matches
last digits of PSTN number (DN)
Making calls Receiving calls
Figure 164: Relationship between public and private numbering plans

Chapter G2 CS2000 Support for Tones
This chapter is organised as follows:

! Section G2.1: Overview on page 734
! Section G2.2: Classifying and Identifying Tones on page 735
! Section G2.3: CS2000 Implementation on page 738
! Section G2.4: Media Gateway Support for Tones on page 739

Communication Server Capabilities Network Fit CS2000 Support for Tones
G2.1 Overview
A toneset is a complete set of the tones required to enable a CS2000 and its media
gateways to fulfill a particular network role. Such a toneset comprises the following
elements:
! Tones used in dialling and call setup, for which three international standards have
been defined:
" DTMF (Dual-Tone Multi-Frequency) tones
" MF (Multi-Frequency) tones
" MFC (Multi-Frequency Compelled) tones
Note: There are no applications supported in ISN07 that use MF or MFC tones.
! Event indication tones (also referred to as supervisory tones or audible tones),
which are are provided in-band to indicate the occurrence of call processing events,
e.g. dial tone, ringing tone and busy tone. Although international standards have
been defined, there are national variations in:
" The range of tones that must be supported in each national network.
" The characteristics of the supported tones, i.e. their frequency, level and
cadence.
In the CS2000 network architecture, tones are generated by media gateways rather than
by the CS2000 itself. They are played over TDM-side trunks or analogue lines in response
to requests initiated by CS2000 call processing, using the GWC to send appropriate
device control messages to the media gateway handling the bearer connections for the
call. No packet network media resources are used.
Note: Tones can also be generated by a media server such as the UAS (Universal Audio
Server). Although the UAS is primarily designed to support announcements, it can be also
used to support tones by recording them as announcements on the UAS and datafilling
them as announcements on the CS2000.

CS2000 Support for Tones Network Fit Communication Server Capabilities
G2.2 Classifying and Identifying Tones

Tones are defined in device control protocols as signals. The H.248 and ASPEN 2.1
protocols organise tone signals into a number of packages, each comprising a number of
tones with related functions. The other device control protocols supported by CS2000, i.e.
NCS and MGCP, also organise tone signals into packages, but their packages can also
contain signals other than tones. In either case, a given tone is uniquely identified by the
combination of its Package ID and Tone ID (PID/TID).
It is a requirement for media gateways that support for a given package means support for
all the tones in that package, i.e. packages cannot be subdivided.
G2.2.1 H.248 Support for Tones

Annex E of H.248, the ITU-T Recommendation for Gateway Control Protocol, specifies
the following packages for tone generation:
! Tone Generator Package (core capabilities)
! Basic DTMF Generator Package
! Call Progress Tones
Additional tones that need to be supported have been arranged into logical packages of
4-10 tones based on the purposes for which they are used. These are now part of an
Internet Draft titled "Supplemental Tones Packages for Megaco/H.248"which can be
obtained at:
http://www.ietf.org/internet-drafts/draft-boyle-megaco-tonepkgs-05.txt
The tone packages defined in this draft are:
! Basic Call Progress Tones Generator with Directionality
! Expanded Call Progress Tones
! Basic Services Tones
! Expanded Services Tones
! Conferencing Tones
! Diagnostics Tones
! Carrier Tones
! Intrusion Tones
! Business Tones
The tone package strategy has been applied to, and has succeeded in mapping, all the
tones defined in GR-506 LSSGR Signalling for Analog Interfaces, ITU-T E.180/Q.35
Tones in National Signalling Systems, and ITU-T E.182 Tones in National Signalling
Systems. Analysing tones from a functional perspective revealed that a number of tones
that were apparently different were actually used for the same purpose. Similarly, it has
been determined that many tones that appeared to be specific to a particular country or
market specific merely had a different name for the same thing; there are in fact no tones
that are market/country specific.

G2.2.2 ASPEN Support for Tones

The following tones packages defined for H.248 have been imported by ASPEN 2.1 and
are supported by PVGs:
! Basic Call Progress Tones Generator with Directionality
! Expanded Call Progress Tones
! Basic Services Tones
The tones included in these packages are specified in Table 72.
Table 72: Tones provided in standard packages defined for H.248

Package Tone Tone ID
Call Progress Tones Dial Tone dt
(package ID: cg)
Ringing Tone rt
Busy Tone bt
Congestion Tone ct
Special Information Tone sit
Warning Tone wt [1]
Payphone Recognition Tone pt
Call Waiting Tone cw
Caller Waiting Tone cr
Expanded Call Progress Tones Comfort Tone cmft
(package ID: xcg)
Off-hook Warning Tone roh
Negative Acknowledge Tone nack
Vacant Number Tone vac
Special Conditions Dial Tone spec
Basic Services Tones Recall Dial Tone rdt
(package ID: srvtn)
Confirmation Tone conf
Held Tone ht
Message Waiting Tone mwt
[1] Used to support TBOA (Tone Burst On Answer) for indirect access.

G2.2.3 NCS Support for Tones

CS2000 uses NCS to provide tone support for MTA cable line gateways.
Tones are defined as signals in the Line Package of the NCS protocol specification
PKT-SP-MGCP-I10-040402 (or later issue found at www.packetcable.com).
G2.2.4 MGCP Support for Tones

CS2000 uses MGCP to provide tone support for customer LAN line gateways (Ambit,
Askey and Mediatrix).
Tones are defined as signals in the various MGCP packages specified in:
http://www.ietf.org/rfc/rfc2705.txt
CS2000 supports the tones specified in the following packages:
! DTMF Package
! Generic Media Package
! Line Package
G2.2.5 Dealing with Market-Specific Variations

Although in functional terms the set of tones to be supported in a given market is the same,
the characteristics of the individual tones (frequency, level and cadence) vary from market
to market. To accommodate these variations, the definitions of the functional tones
included in a package can be configured at the media gateway. CS2000 call processing
therefore does not need to know about market-specific variations; it merely requests the
playing of a particular functional tone and relies on the media gateway to ensure that the
tones characteristics are correct when it is played.

G2.3 CS2000 Implementation

G2.3.1 Identifying Tones
Most tones known to CS2000 call processing software are defined in table TONES, in
which they are identified by CLLI. Such CLLIs are used in CS2000 call processing to
denote logical call destinations. Calls can thus terminate on tones as result of the
translation and routing process described in Chapter C3: Translations and Routing.
A new standard range of internal tone IDs has been defined for CS2000, to be used by all
GWCs. GWC software maps these on to the functional PID/TID tone identifiers defined
for use in device control protocols. BUSYTONE, for example, is mapped to cg/bt for
H.248 and ASPEN 2.1, and mapped to L/bz for NCS and MGCP.
CS2000 identifies tones by means of internal toneIDs that are recognised both by the
CS2000 Core and GWCs. Core datafill maps these internal toneIDs on to CLLIs defined
in table TONES (table STN for some tones), while GWC software maps them on to the
standard PID/TID tone identifiers defined in the device control protocol (H.248, ASPEN
2.1, NCS or MGCP). The need to play a tone can be determined either by the Core (in
which case a proprietary message specifying the required internal tone ID is sent by the
Core to the GWC) or autonomously by a GWC. See A59022704 for further information.
G2.3.2 Requesting the Playing of a Tone

Requests for the playing of tones are conveyed from CS2000 GWC to media gateway
using an IP media control protocol. The Nortel strategy for CS2000 support of tones has
focused primarily on the H.248 protocol, but ISN07 provides tone support via ASPEN
(see section G2.2.2), NCS (see section G2.2.3) and MGCP (see section G2.2.4).
CS2000 does not need to know about market-specific variations in tone characteristics; it
merely requests the playing of a particular functional tone and relies on the media gateway
to ensure that the tones characteristics are correct when it is played, based on the country
in which the gateway is deployed.
When call processing determines that a particular tone needs to be played, the sequence
of events is:
! Either a proprietary message specifying the required internal tone ID is sent by the
CS2000 Core to the TDM-side GWC handling the call, or the GWC determines
autonomously that a specific tone ID needs to be played.
! The GWC performs the necessary mapping between the CS2000 tone ID and the
packet network functional PID/TID tone identifier.
! The GWC sends an ASPEN, NCS or MGCP RQNT (Request Notification)
command to the media gateway, specifying the tone to be played by means of its
PID/TID.
If CS2000 determines that a tone needs to be applied to an incoming SIP-T call, it sends
a SIP-T RBC (Remote Bearer Control) request back to the originating CS2000, specifying
the tone that needs to be played. The originating CS2000 then requests the originating
media gateway to apply the tone on behalf of the terminating SIP-T GWC. See section
F1.2 on page 518 for more information about RBC.

G2.4 Media Gateway Support for Tones

G2.4.1 General Requirements
PP7480 and PP15000 PVGs support tones via ASPEN. The MTA cable line gateway
supports tones via NCS. Customer LAN line gateways (Ambit, Askey and Mediatrix)
support tones via MGCP.
Specific requirements for tone support capabilities on media gateways include:
! Ability to play tones consisting of two simultaneously combined frequencies
(frequency modulated).
! Ability to play a continuous tone for a specified duration or maximum duration, or
until a specified condition is met.
! Ability to play tone cadences with up to 4 segments, and with different frequencies
in different segments.
! Ability to repeat tones up to 40 times.
G2.4.2 Support for Tone Packages

Table 73 lists the tone packages defined for H.248 and ASPEN 2.1, and indicates the level
of support provided for them (via ASPEN) by CS2000 trunk gateways in ISN07.
Table 73: CS2000 media gateway support for tone packages in ISN07
Tone package PP7480 and PP15000 PVG support
Tone Generator Package Yes
Basic DTMF Generator Package Yes
Call Progress Tones Yes
Expanded Call Progress Tones Yes
Basic Services Tones Yes
Expanded Services Tones No
Operator Tones No
Conferencing Tones No
Expanded Conferencing Tones No
Diagnostics Tones No
Carrier Tones No
Intrusion Tones No
Business Tones No
MTA cable line gateways support tones defined as signals in the Line Package of the NCS
protocol specification.
Customer LAN line gateways (Ambit, Askey and Mediatrix) support the tones specified
in the DTMF Package, Generic Media Package and Line Package of MGCP.

G2.4.3 Support for Market-Specific Variations

Media gateways are responsible for mapping functional PID/TID tone identifiers, as
specified in requests from the GWC, on to tone definitions that have the correct
market-specific characteristics (frequency, level and cadence).
The following table lists all of the market-specific tonesets that can be supported by
CS2000-controlled media gateways in ISN07.
Table 74: Media gateway support for market-specific tonesets in ISN07

Ambit / Mediatrix Askey
Country / market PVG support MTA support
support support
Australia Yes No Yes No
Brazil Yes No No No
Chile Yes No No No
China Yes No No Yes
Czech Republic Yes No Yes No
France Yes No No No
Germany Yes Yes No No
Hong Kong Yes No No No
India Yes No No No
Ireland Yes No No No
Israel Yes No Yes No
Japan Yes Yes Yes No
Korea Yes No No No
Malaysia Yes No No No
Mexico Yes No No No
Netherlands Yes No No No
New Zealand Yes No No No
Portugal Yes Yes No No
Romania Yes No No No
Russia Yes No No No
Singapore Yes No No No
Switzerland Yes No No No
Turkey Yes No No No
UK Yes No No No

G2.4.4 Provisioning
The ultimate aim is for the provisioning of tones in a CS2000 network to be based on the
co-ordinated downloading of tone packages to media gateways from a central database,
but in ISN07 the following restrictions apply:
! All tonesets supported by the PVG are hard-coded, i.e. pre-defined in the PVG
software load. Tonesets can be separately provisioned on an E1 carrier basis, or one
toneset can be provisioned for the media gateway as a whole.
! Tonesets supported by customer LAN and cable line gateways are hard-coded.
! Tones supported are those that can be datafilled in table TONES, plus the following
tones datafilled in table STN:
" Call Waiting
" Distinctive Call Waiting
" Teen Service/Enhanced Call Waiting
For more information, see A59022704.

Chapter G3 CS2000 Support for
Announcements
This chapter is organised into the following sections:

! Section G3.1: Announcement Characteristics on page 743
! Section G3.2: The Role of the MS2000/UAS Media Server on page 744
! Section G3.3: GWC - Media Server Communication via H.248 on page 745
! Section G3.4: Announcement Capacity on page 746
! Section G3.5: Announcement Datafill on page 746
! Section G3.6: The Audio Provisioning Server (APS) on page 747

CS2000 Support for Announcements Network Fit Communication Server Capabilities
G3.1 Announcement Characteristics

A CS2000 announcement can comprise up to 16 separate phrases played in sequence. A
given phrase can be used in many different announcements, which makes it possible to
assemble hundreds of different announcements from a base of phrases whose total
duration may be only a few minutes.
Each complete announcement is identified by the combination of a CLLI and an
announcement number. CS2000 datafill maps each announcement number on to an
ordered list of the phrases that make up the announcement, each phrase being identified
by means of an external phrase identifier. When CS2000 call processing determines that
a particular announcement needs to be played to a call party, it refers to this announcement
datafill to find out the sequence of specific phrases that must be assembled.
Variables can be included in announcements in the same way as phrases, allowing
announcements to include dynamically determined data values such as monetary
amounts, dates and times.
Because announcements are identified by CLLIs in the same way as trunk group
destinations, calls can terminate on announcements as result of the translation and routing
process described in Chapter C3: Translations and Routing.
CS2000 permits network operators great flexibility in defining, recording and deploying
the announcements they require. This document therefore does not attempt to list specific
announcements supported by CS2000.
Some standard mechanisms are available for customising announcements for different
markets. These include ISO-defined language and currency tokens that can be
dynamically associated with an announcement when it is to be played. This allows the
logical content of an announcement to remain independent of how it is presented, such
that it is not necessary for CS2000 to support multiple versions of an announcement in
different languages.

Communication Server Capabilities Network Fit CS2000 Support for Announcements
G3.2 The Role of the MS2000/UAS Media Server

In the CS2000 network architecture, announcement support is provided by a media server,
not by CS2000 itself.
In ISN07, CS2000 supports two types of media server:
! AudioCodes MS2000 Series media servers:
" The MS2010, which is for use in VoIP solutions
" The MS2020, which is for use in VoATM (VoAAL2) solutions
! UAS (Universal Audio Server)
MS2000 Series media servers have been introduced in ISN07 as compact, enhanced
replacements for the Universal Audio Server (UAS). Deployed UASs are still supported,
but MS2000 Series units are to be used for all new media server deployment. Both types
of media server are described in Chapter B3: CS2000 Support for Media Servers.
Although logically and functionally a media server is a centralised resource, the
MS2000/UAS is in practice co-located with the CS2000 and connected to the CS2000 CS
LAN.
In terms of CS2000 network architecture, an MS2000/UAS media server subtends a GWC
in the same way as a media gateway. It is controlled by a dedicated Audio Controller (AC)
GWC, which uses H.248 to tell the MS2000/UAS media server which announcement to
play and the IP host or ATM endpoint to which it should be sent.
The need to provide an announcement to a call party is determined during translations,
and the specific announcement to be played is identified by a CLLI (in effect, a trunk
destination). On CS2000, this CLLI is used to set up a packet network call to the media
server as if it were a media gateway serving a called party, i.e. the call terminates on the
media server. When call setup is complete, a packet network bearer connection is
established between the calling party and the media server (via the media gateway
terminating the TDM-side connection with the call party), and the media server provides
a packetised version of the required announcement.
Media servers are primarily designed to support announcements, but could also be used
to support tones if required.

G3.3 GWC - Media Server Communication via H.248

The protocol used by the CS2000 audio GWC to request the playing of announcements is
H.248, as described in Chapter D3: H.248.
H.248 supports the use of abstract audio identifiers, which allow announcement
characteristics to be determined at execution time by the media server. These
characteristics can include language, customer-specific variations and codec to be used.
The announcement request from the CS2000 MGC to the media server needs only to
include an abstract audio identifier and one or more qualifiers. Service logic at the
CS2000 does not need to know the details of how the media server will customise the
announcement when it is transmitted.
Specific characteristics that can be communicated to the media server via Media Control
Message Protocol (MCMP) data in H.248 messages are language (specified via language
tokens defined in ISO639-2/T) and currency (specified via currency tokens defined in
ISO4217). See A19012479 for details. Price data conveyed in INAP PlayAnnouncement
operations can be reformatted to MCMP Money data.
H.248 also supports composite audio identifiers, which specify a sequence of
announcement components to be assembled into a complete announcement. This permits
common words and phrases to be reused in many different announcements, minimising
the recording time and amount of storage required.
Announcements are stored on media server local storage. When a request is received to
play an announcement, the media server CPU retrieves and assembles the elements of the
announcement, then sends it to be processed. It is then transmitted over the backbone
network to the appropriate media gateway for in-band TDM-side delivery to the call
party.
In ISN07, CS2000 supports (via the media server) announcement sets customised for the
following national markets:
! Australia
! Chile
! China
! Czech Republic
! France
! Hong Kong
! Israel
! Japan
! Korea
! Malaysia
! Mexico
! New Zealand
! Romania
! Portugal
! Singapore
! Spain
! Switzerland
! Turkey
! UK

Communication Server Capabilities Network Fit CS2000 Support for Announcements
G3.4 Announcement Capacity

Media server capacity depends on the type of media server in use and on whether the
backbone network is IP or ATM, as follows:
! Maximum number of simultaneous announcements:
" MS2000 Series
# MS2010 (VoIP): 240 announcements
# MS2020 (VoATM): 480 announcements
" UAS:
# 468 VoIP announcements (6 CG6000 cards * 78)
# 640 VoATM announcements (5 AG4000 cards * 128)
There is also an overall limit of 1280 on the maximum number of UAS resources
that can be controlled by an Audio Controller GWC.
! Maximum BHCA:
" MS2000 Series
# 80,000 (MS2010)
# 60,000 (MS2020)
" 60,000 (UAS)
G3.5 Announcement Datafill

The media server and its controlling audio GWC are datafilled using the following tables
(see section C2.9 on page 203):
! The SERVRINV Server Inventory table defines the GWCs supported.
! The SERVSINV Server Subtending Node Inventory table, which lists logical nodes
that subtend GWC peripherals. The media server is defined as a node of type AUD.
Announcements are identified by a CLLI and an announcement number. The tables used
to define them are:
! Table CLLI
Defines a logical Common Lanaguage Location Identifier (CLLI) for each
announcement on which a call can terminate. It also specifies the trunk group size
(number of members) for each announcement CLLI.
! Table ANNS
For each announcement, table ANNS defines the CLLI used in routing calls to that
announcement (e.g. ATTBUSY or MUSIC). It also specifies the cycle time of the
announcement.
! Table ANNMEMS
An announcement CLLI is a logical destination. As with a trunk group CLLI, it is
necessary to provide physical paths to that destination. For announcements
provided by the media server, the MEMINFO field in table ANNMEMS provides
two items of information:
" A numeric phrase list index into table ANNPHLST for locating the phrase(s)
that comprise the announcement.
" The identifier of the media server where the announcement resides, as defined
in SERVSINV, e.g. AUD 0.

! Table ANNPHLST
This is the mechanism used to assemble complete announcements from separate
phrases and variables. An announcement may consist of up to 16 phrases, which are
listed in order in table ANNPHLST using the names assigned to them when
recorded. The CLLI of an announcement and the ANNMEMS phrase list index are
used to retrieve the names of its consituent phrases from table ANNPHLST.
! Table ANNAUDID
Because the media server does not recognise the CS2000 names for announcement
phrases, table ANNAUDID maps the phrase identifiers datafilled on CS2000 to the
audio segment identifiers that have been separately provisioned on the media server.
This enables the media server to retrieve, assemble and play the correct
announcement in response to a CS2000 request.
See A19013546 for a detailed description of announcement datafill, including ISN06
enhancements designed to simplify and standardise the datafill process.
G3.6 The Audio Provisioning Server (APS)

The Audio Provisioning Server (APS) is a centralised audio management tool for the
provisioning of audio segments, e.g. announcements or announcement phrases, on the
media servers belonging to a CS2000 network. It provides a user-friendly web-based
interface that supports the following functions:
! Storing recorded audio segments in a database, together with indexing information
that allows them to be retrieved.
! Searching the audio database using a wide variety of criteria to retrieve sets of audio
segments and package them for export.
! Exporting integrated packages of audio segments to media servers for use in
assembling announcements.
Audio segments are typically recorded in a sound studio. When recording is complete, the
resulting files can be easily added to the audio database via the APS user interface. The
interface makes it possible to capture not only the recording itself, but also contextual
information such as date, name of voice talent, title and wording.
The APS is an Oracle database application that runs on a NEBS-compliant Sun Netra 240
server. The database can store any kind of audio file, but in ISN07 the media server
requires files to be stored in PCM format (either A-law or -law).
Search and sort capability is provided for database fields, including two customer-defined
fields, to make selecting and using the audio in the database more manageable. Access to
the database can be password limited via these search and sort fields. This allows
customers to view and select from their own unique audio rather than the complete set of
audio in the database.
The web-based APS interface makes it possible to add, delete and replace audio segments
managed by the APS, and to configure and assemble audio announcements for download
to the media server. The APS reduces the cost and complexity of changing or adding
announcements within a network, as changes can be made centrally and exported to
multiple media servers. This guarantees network-wide consistency in audio IDs, ensuring
that, no matter what node in the network is requested by a service engine to play a specific
prompt, the result will always be the same.

Chapter G4 Network Integration Issues
G4.1 CS2000 Solutions

This Product Description describes the complete portfolio of CS2000 capabilities
available for deployment in international markets. No customer network will deploy
every capability described. To allow customers to select the subset of capabilities that best
meets their requirements, CS2000 capabilities are packaged into predefined solutions on
the basis of the type of backbone packet network to be used and of the connectivity and
services to be supported.
The main characteristics of the five currently supported CS2000 solutions can be
summarised as follows (note that elements of different solutions may be combined to meet
customer requirements):
Table 75: CS2000 solutions and their characteristics

Solution
IAW
PToIP VToATM [1] (international IAC Carrier-Hosted
(Packet Trunking (Voice Trunking (International
Access Services (CHS)
over IP) over ATM) Access Cable)
Wireline)
Backbone IP ATM IP IP IP
network (AAL2)
CCS7 CCS7 CCS7 CCS7 CCS7
PRI PRI PRI PRI PRI
Trunk access QSIG QSIG QSIG QSIG
(all off PVGs) (both off PVGs) (all off PVGs) (all off PVGs) (all off PVGs)
Lines off
customer LAN Lines off cable
Lines off
gateways (IADs) access network customer LAN
Line access N/A N/A gateways
gateways (IADs)
V5.2 lines off (MTAs)
PVGs
CentrexIP
Enterprise N/A N/A N/A N/A H.323
service access
DPNSS
[1] VToATM is also referred to as VToAAL2, because it uses AAL2 (ATM Adaptation Layer 2) bearer connections.

Network Integration Issues Network Fit Communication Server Capabilities
G4.2 International Deployment Considerations

G4.2.1 International Gateway Functionality
CS2000 can support international gateway functionality, specifically:
! Handling inbound and outbound traffic at the national/international network
boundary. This involves supporting interworking between the interface used on the
international side, which is typically ETSI ISUP V1 as defined in Q.767, and the
national standard interconnect interface, which is typically a national variant of
ETSI ISUP V1/V2 or TUP.
! Routing of transit traffic (typically ETSI ISUP V1) between other international
gateways.
The network configuration is illustrated in Figure 165.
International network
International signalling, typically ETSI ISUP V1 (Q.767)
CS2000 CS2000 CS2000

supporting supporting supporting
international international international
gateway transit gateway
functionality functionality functionality
National signalling, e.g. national variant of ETSI ISUP V1/V2 or TUP
National National
network A network B
Figure 165: CS2000 support for international gateway functionality
In ISN07, CS2000 supports international trunks only on the TDM side. They are
distinguished by setting COFFTYPE = INTL in table TRKGRP.
Table 76: Order codes for international gateway software

SGAT0002 International CLI Screening
SGAT0003 Serving Country Code

Communication Server Capabilities Network Fit Network Integration Issues
G4.2.2 Support for Multiple Timezones

For a CS2000 serving line gateways in two or more time zones, the date and time provided
by CS2000 Cores Time Of Day (TOD) clock is not valid for gateways in different time
zones. Timezone data for each alternative time zone is specified in table MULTITZ
relative to the Core TOD, and the MTZ (Multiple Time Zone) line option can be assigned
via SERVORD+ to ensure that a line uses the appropriate set of MULITZ-defined data..
This ensures that services such as WUCR (Wake Up Call Request) use the correct local
time. See A59038784 for details.
G4.2.3 MCCS (Multi-Country Call Server) Capability

For historical reasons, some CS2000 behaviour is governed by the office parameter
MARKET_OF_OFFICE. To support the Multi-Country Call Server (MCCS) capability,
which allows one CS2000 to support media gateways in a number of countries, market of
office decoupling is necessary.
ISN06 feature A89009671 enables a single CS2000 to provide trunk / transit support
between PVGs located in and serving different national markets. This generic capability
has been verified using a test configuration comprising Germany as host country and UK,
France, Austria and Switzerland as satellites.
New office parameter MULTI_NETWORK_CALLSERVER has been introduced in
table OFCENG. Country-specific behaviour is datafilled by defining logical networks,
where a logical network consists of a set of customer groups with a common set of
network characteristics. Table MNETOFC (Multi Network Office Parameter) allows
office parameter values to be specified for each logical network, overriding those
specified for the CS2000 as a whole.
National-specific call processing requirements are now controlled by the originators
network ID, as specified by the MC_NWID field in table CUSTENG.

G4.3 Bearer Capability Mapping

G4.3.1 End-to-End Codec Negotiation
The codec and packetisation rate used for a call are determined by a codec negotation
process that involving the originating and terminating media gateways and their GWCs.
The aim is that the codec used should be the codec that is highest in preference order and
supported by both gateways involved in the call. The capabilities of each media gateway
are conveyed to its GWC and to the far-end gateway in the form of an SDP (Session
Description Language) session description, and an appropriate codec is selected from the
intersections of both gateways sets of capabilities. See section D4.6.1 on page 286 for
some examples of SDP relayed via ASPEN for this purpose.
The basic steps in the end-to-end codec negotiation process are as follows:
1 The initial CRCX (Create Connection) or equivalent command sent for a call
presents a list of codec / packetisation rate pairs to the first media gateway in order
of preference.
Note: If codec negotiation via translations, as described in section G4.3.2 on page
752, results in the selection of the network default codec specified by the
SETCODEC option, this default codec (typically G.711) will be the only option
presented in the first CRCX command. Selection of the network default will then be
the forced result of the end-to-end codec negotiation process.
2 The first media gateways acknowledgement of the initial CRCX returns a media
description line for each codec / packetisation rate pair that it can support (from the
list presented by the GWC).
3 The CRCX sent to the other media gateway involved in the call presents it with an
ordered list of codec / packetisation rate pairs that reflects the capabilities supported
by the first media gateway.
4 The second media gateways acknowledgement of the CRCX returns a media
description line for each codec / packetisation rate pair that it can support.
5 At this point, both media gateways and their GWCs are aware of the far-end GWCs
capabilities and preferences. The originating gateway then selects the codec that is
highest in its preference order and also supported by the terminating gateway.
When GWCs and media gateways are datafilled, GWC datafill specifies a preferred codec
and packetisation rate and a default codec and packetisation rate for each subtending
media gateway. Compression codecs such as G.729 use bandwidth more efficiently than
non-compressed codecs such as G.711. It is therefore typical for the preferred codec for a
media gateway to be a compression codec. To ensure interoperability between different
types of gateway, however, it is a Nortel requirement that all CS2000-controlled gateways
should support G.711.
If either gateway involved in a call detects an in-band fax or modem tone, e.g. 2100Hz, it
will initiate a transition to G.711 Voice-Band Data (VBD) for the call, regardless of what
the original result of the codec negoiation process was.

G4.3.2 Codec Negotiation via Translations

There are call scenarios in which codec selection cannot be determined in advance and
controlled statically on the basis of gateway capabilities. For example, there are calls for
which a compression codec should not be used even if it is the gateway default:
! Calls for which compression has already been performed on another leg of the
end-to-end bearer path (e.g. calls originating from a mobile network).
! Call for which the additonal latency of using a compressed codec would add too
much of a delay (e.g. international VoIP calls).
Such scenarios must be identified during translations or call screening so that appropriate
action can be taken. ISN05 feature A19012781 introduced the SETCODEC option, which
can be specified at various points in the translations process to allow a codec to be selected
on the basis of call-related criteria, as summarised in the following table.
SETCODEC specified in To enable codec selection based on

Table TRKOPTS Incoming or outgoing trunk group
IBN translations tables IBNXLA and XLANAME Called party digits
xxCODE tables in universal translations Called party digits or called party NOA
CALLCNTL and Universal Screening tables [1] A variety of parameters
Screening table DNSCRN [2] CLI or calling party NOA
Service profile table CLISRVPF [3] Service profile associated with screened CLI
[1] See section C3.5.5 on page 214 for information about CALLCNTL and Universal Screening.
[2] See section F11.3.1.1 on page 636 for information about table DNSCRN.
[3] See section F11.3.1.4 on page 638 for information about table CLISRVPF.
The SETCODEC option specifies the CALLTYPE of the current call. This CALLTYPE
is an index into table CODEC, which in turn specifies the codec to be used for the call.
CS2000 Core communicates this alternative codec to the GWC during call setup. It takes
precedence over the codec(s) specified in GWC datafill, and is used by the GWC during
codec negotiation.
The following limitations apply to use of the SETCODEC option in ISN07:
! The only codec that can be selected via translations is the network default (G.711
a-law or G.711 -law, depending on network configuration).
! SETCODEC does not allow an alternative packetisation rate to be selected, only an
alternative codec.

G4.3.3 CS2000 Support for RFC2833, T.38 and Comfort Noise (CN)
CS2000 allows GWCs to request the use of RFC2833, T.38 or Comfort Noise (CN)
insertion on calls to/from a media gateway provided that the far-end media gateway also
supports it.
! RFC2833 is an IETF-defined standard for the transparent transport of DTMF tones
over IP.
! T.38 is an ITU-defined standard for the transparent transport of Group 3 fax calls
over IP.
! Comfort Noise is random noise that is applied to a connection to reassure the user
that it is still alive when use of silence suppression means that no voice packets are
being received.
These capabilities are supported for the following media gateway types:
! PVG
! MG9000
! Customer LAN gateways
! Cable gateways
The GWC requests the use of a given capability (RFC2833, T.38 or CN) by including
appropriate information in the LCO (Local Connection Options) parameter of the initial
CRCX (Create Connection) command sent for a call. The SDP included in the gateways
response indicates that it can support the requested capability. If the same process at the
far-end gateway indicates that it too can support the requested capability, it will be used
for the call. The process is a refinement of the codec negotiation process described in
section G4.3.1 on page 751.

G4.4 Packet / Circuit Interworking

G4.4.1 Echo Cancellation
CCS7 protocols allow the quality of a long-distance TDM speech path to be maintained
by using an echo cancellation device to ensure that no disconcerting echo is reflected from
the far end. To ensure that further echo cancellation is not applied by subsequent switches,
the IAM for a call indicates whether echo cancellation has already been applied in the
forward direction, and the ACM (or equivalent) indicates whether it has been applied in
the backward direction.
It is important to ensure that echo cancellation is not applied to bearer circuits used for
data calls (64Kb/s clear channel data, modem or fax), because it would corrupt the in-band
data.
Echo cancellation as such is clearly not applicable for bearer connections across a packet
network. However, CS2000 not only needs to support echo cancellation for its TDM-side
CCS7 trunks, but also needs to support EC-related signalling for DPTs. Specifically, the
IAM or ACM for a voice call across the packet network will always indicate that echo
cancellation has already been applied upstream. When required, echo cancellation is
applied to TDM-side circuits by trunk media gateways in response to ASPEN or H.248
requests from CS2000 GWCs. See section E2.2.4.1 on page 379 for a detailed discussion
of the criteria and mechanisms that determine whether echo cancellation is applied for a
given call over a given outgoing TDM-side CCS7 circuit.
For PRI and QSIG, echo cancellation is always used for QSIG non-data calls, on the
assumption that the gateway is close to the point of reflection and is therefore the best
place to apply echo cancellation. The use of ISUP signalling procedures ensures that the

G4.4.2 Continuity Testing

CCS7 protocols allow the quality of the TDM speech path for a call to be tested by
transmitting an in-band tone, looping this tone back again, and comparing the
looped-back tone with the tone originally transmitted. This is known as Continuity
Testing (COT). Such continuity testing is clearly not applicable for bearer connections
across a packet network, but must be supported for TDM-side CCS7 trunks.
Continuity testing can be performed in the course of call establishment or independently
on demand, as follows:
! Per-call continuity testing is initiated by including a COT request in the IAM. A
COT message is subsequently sent in the forward direction to indicate that the
continuity test has been successful; this is relayed to the terminating switch, which
will not send back an ACM until it has received the COT message.
! On-demand continuity testing is initiated by sending a CCR (Continuity Check
Request) message, which asks the far-end switch to attach tone loopback equipment
to a specified circuit.
CS2000 supports both types of testing for its TDM-side CCS7 circuits. Outgoing
continuity test tones and looped-back tones are applied by PVG media gateways, not by
CS2000 itself. The gateway applies the tone in response to an ASPEN 2.1 RQNT
(Request Notification) command after the preliminary CCS7 messaging has taken place.
CS2000 supports per-call continuity testing for calls incoming to the packet network by:
! Recognising COT requests in received IAMs.
! Looping back in-band continuity tones when received. This capability is enabled by
setting the COTCHK field of table TRKSGRP to THRH (transmit high, receive
high) for the circuit in question.
! Relaying COT messages received to indicate successful continuity testing.
For outgoing TDM-side calls, CS2000 will initiate continuity checking on an outgoing
circuit x% of the time, where the percentage x is specified in the COTREQ field of the
table TRKSGRP entry for the circuit in question.

Chapter G5 IP Addressing and Internet
Transparency
G5.1 Public and Private IP Addresses

Private IP addresses are used to increase the effective number of IP addresses that are
available. In so doing, they provide a solution to the problem that globally unique IP
addresses are a finite resource that is subject to depletion. Use of private IP addresses also
makes it possible to simplify network structuring and management.
The principle is that private IP addresses are used only within a private network and are
not visible outside it. External access to the elements of a private network is achieved via
public network addresses that are translated or mapped on to private network addresses at
the edge of the private network. NAT means mapping or binding private network
addresses on to externally visible public network addresses. Typically, a relatively small
number of public addresses is used to support public network access for many private
network hosts.
Note: The term public network is used in this section to denote a network that can be
accessed from different private networks and supports communication between different
private address domains. From the perspective of these private domains, the DMZ is
perceived as a public network, but it is actually another private network belonging to the
cerrier network operator.
Because private network addresses are not visible outside a private network, two or more
different private networks can use the same range of private IP addresses provided that
there is no direct contact between hosts on different networks.
The Internet Assigned Numbers Authority (IANA) has reserved the following three
ranges of IP addresses for private address domains, as described in RFC1918:
! From 10.0.0.0 to 10.255.255.255 (10.0.0.0/8 prefix)
This block can yield 224 or 16M independent IP addresses.
! From 172.16.0.0 to 172.31.255.255 (172.16.0.0/12 prefix)
This block can yield 220 or 1M independent IP addresses.
! From 192.168.0.0 to 192.168.255.255 (192.168.0.0/16 prefix)
This block can yield 216 or 64K independent IP addresses.

IP Addressing and Internet Transparency Network Fit Communication Server Capabilities
G5.2 Communication between Address Domains

The implementation of a CS2000 solution may involve communication between a number
of different networks, each with its own IP address domain. These include:
! The VoIP address domain of the TSP (Telecommunications Service Provider),
which comprises the CS LAN and large telco-located gateways such as PVGs. This
is a private domain that must be kept secure from non-VoIP traffic.
! Private enterprise networks with their own address domains.
! The DMZ (Demilitarised Zone) that supports communication between private
address domains. From the perspective of these private domains, the DMZ is
perceived as a public network, but it is actually another private network belonging
to the TSP.
! The public Internet.
Communication between different networks and address domains, i.e. the transfer of
media and signalling packets across network boundaries, is controlled by devices that are
collectively known as middleboxes. The two most important functions these provide are:
! Firewall functionality
A firewall protects a private network against unauthorised access from a public
network to which the private network is connected. It achieves this by examining
incoming packets and rejecting them if they are not authorised, e.g. if they originate
from an unknown source.
! Network Address Translation (NAT)
NAT means mapping or binding private network addresses on to externally visible
public network addresses. Because only a subset of private network hosts require
links with the public network at any given moment, NAT allows a relatively small
pool of addresses to support public network access for many private network hosts.
Private IP addresses are used for internal communication, but these are not visible
to the public network, which enhances network security. NAT mapping between
public and private address domains is shown in Figure 166.
Public address domain Private address domain

(e.g. carrier network) (e.g. enterprise network)
Public addresses
NAT / NAPT
provide externally device Private addresses visible
visible points of contact only within private network
Mapping table
NAT / NAPT device treats
public addresses as a At a given moment, only a
pool of resources to be subset of private network
dynamically assigned and hosts have a link with the
mapped as required public network
NAPT enables a small number of public addresses to be

used for access to a large number of private addresses
Figure 166:Functional overview of NAT / NAPT

Communication Server Capabilities Network Fit IP Addressing and Internet Transparency
For simplicity, it is common to refer to firewalls and to NATs as if they were devices, but
in practice both types of functionality are often provided by a single device, e.g. many
firewalls also provide NAT functionality.
Figure 167 is a simplified network diagram that illustrates the different types of
communication involved in an enterprise VoIP solution.
Non-IP
VoIP address domain, addressing PSTN
including CS LAN and PVGs
Middlebox
Demilitarised Zone (DMZ), Middlebox Public

i.e. "public" network for TSP Internet
Middlebox Middlebox Middlebox
Middlebox Middlebox Middlebox
Enterprise Enterprise Enterprise

address domain address domain address domain
A B C
Figure 167: Different types of IP address domain
As shown in Figure 167, the carrier network must be connected to multiple enterprise
networks, each secured by a firewall and typically also by a NAT. These networks must
be connected to the carriers managed IP network, which is in turn secured by the carriers
firewall. The network containing VoIP components (the CS LAN and large telco-located
media gateways) is also connected to the carriers managed IP network; this connection
may be direct, or may involve additional firewalls, but does not involve additional NAT.
In order for VoIP connections to be set up across these various networks, both signalling
and RTP media streams must traverse these firewalls and NATs transparently.
By default, the need to traverse firewalls and NATs would make it impossible to support
VoIP across network boundaries, which would prevent direct VoIP interworking between
carrier and enterprise networks. To enable TSPs to deliver enterprise VoIP solutions,
therefore, it is necessary to devise mechanisms that permit firewall and NAT traversal for
signalling and media streams without impairing the security of TSP or enterprise
networks.

G5.3 Network Address and Port Translation

Network Address Translation (NAT) is a method of binding IP addresses in one address
domain to IP addresses in another domain, enabling transparent routing to take place
between end points belonging to different address domains. Network Address and Port
Translation (NAPT) extends NAT by also translating transport identifiers such as UDP
port numbers; it thereby allows several end points to share a public address and allows a
large number of private addresses to be served using a small number of public addresses.
The public addresses may be assigned dynamically and translated as required to meet the
changing demands of the private address domains.
One-way NAT allows end points in a private address domain to access end points in the
public address domain. Because the addresses of end points in a private address domain
are unique only within that address domain and may not be valid in the public address
domain, NAT does not advertise private addresses to the public address domain, but does
allow public addresses be used in the private address domain.
Two-way NAT translates addresses and ports in both directions, in order to prevent
address collisions between a private address domain and the public address domain. Such
collisions might arise, for example, if the private address domain has improperly
numbered internal nodes using public addresses.
Figure 8 illustrates one-way and two-way NAT.
Address translation for one-way NAT

Outgoing packet Source address translated
Private DA pb B:b SA pr A:a NAT DA pb B:b SA pb X:x Public
network network
host host
Address DA pr A:a SA pb B:b Binding: DA pb X:x SA pb B:b Address
pr A:a prA - pbX pb B:b
Destination address translated Incoming packet
Public network endpoint is visible to private network endpoint,

but private network endpoint is not visible to public network endpoint
Address translation for two-way NAT

Outgoing packet Both addresses translated
Private DA pr Z:z SA pr A:a NAT DA pb B:b SA pb X:x Public
network network
host host
Address Binding: Address
DA pr A:a SA pr Z:z prA - pbX DA pb X:x SA pb B:b
pr A:a pb B:b
prZ - pbB
Both addresses translated Incoming packet
Bost endpoints are visible only to NAT, not to each other

Figure 168: One-way and two-way NAT
NAT address binding is typically dynamic, and is done at the start of a session. A given
address binding may support multiple sessions. Once a local address is bound to a global
address, all subsequent sessions originating from the same local address or directed to the
same local address will use the same binding. When the last session using an address
binding is terminated, the binding is released so that the public address can be re-used.

G5.4 NAT Traversal

G5.4.1 NAT Traversal for Signalling
See section D8.4.2 on page 322 for information about the message sequence used to
support NAT traversal for the MGCP signalling used to control customer LAN gateways.
See section D6.4 on page 307 for information about the command sequence used to
support NAT traversal for the UniStim signalling used to control remote CentrexIP
clients.
G5.4.2 NAT Traversal for Bearer Traffic

For VoIP, bearer connections across the packet network are established between
RTP/RTCP endpoints, i.e. ports on media gateways. During call establishment, each
gateway uses device/media control signalling to inform its GWC of the bearer capabilities
it can support, e.g. codecs and packetisation rates. It also tells the GWC the IP address and
RTP port number to which bearer packets destined for it should be sent.
Bearer capability and media address information is conveyed embedded in device/media
control signalling, either in SDP session description lines in MGCP messages or in
UniStim commands. A problem arises if NAT is in use, however, because media address
information embedded in signalling packets is of no use to a remote terminating endpoint
that receives it; it identifies the originating endpoint by means of a private address to
which the terminating endpoint has no access.
NAT traversal for media streams requires knowledge not only of what media gateways
can be accessed via a network, but also of which NAT (if any) needs to be traversed to
reach a given gateway. Specifically, being able to send media packets to a given gateway
requires knowledge of the public NAT address that is bound to the gateways private
address. However, the public NAT address for a media stream cannot be discovered by a
GWC in the same way as the public NAT address for a signalling connection, because
media packets are by definition not sent by a gateway to its GWC. And RTP/RTCP
provides no address discovery mechanism that can be used to set up a two-way connection
between media gateways.
The Nortels Networks solution to this problem is to use a media proxy (see Chapter B5:
Media Proxies for details). A media proxy is a network element that acts as an
intermediary in a call between two packet network endpoints when NAT traversal is
required for the calls media stream. The media proxy examines incoming packets on each

of its ports to determine their origin, and can thus work out the destination to which return
packets in the other direction should be sent. Two media proxy ports are used in handling
a typical call, each presenting an interface to one of the endpoints involved in the call, and
there is a connection across the media proxy between the two ports to support end-to-end
communication between the two packet network endpoints.
If a GWC knows that a given gateway is behind a NAT, it can insert a media proxy into
a call as a destination for media packets from that gateway, and the media proxy can then
discover the public NAT address from which those media packets are being sent. The
media proxy can then receive media packets from the far-end gateway and send them to
the correct public address on the NAT, which uses the previously created NAT bind to
send the media to the private network endpoint behind the NAT. Two-way media streams
for calls involving media gateways behind NATs can thus be set up, provided that media
packets are routed via the media proxy.
To enable CS2000 GWCs to determine whether a media proxy needs to be inserted in a
given call, each GWC stores the following data:
! Information about all the middleboxes in the network, including NATs.
! Information about each media proxy available to the GWC.
! Information about which middlebox(es), if any, need to be traversed to reach each
gateway or remote CentrexIP client in the network.
Using a GWC-controlled media proxy to support NAT traversal for media streams means
that no changes are required to media gateway or NAT functionality. In particular, it does
not require gateways to be aware of network topology and middlebox deployment. It is a
scalable solution with no dependencies on factors outside the network operators control.
G5.4.3 MIDCOM
Nortel Networks is an active participant in the IETF Middlebox Communications
(MIDCOM) working group, whose goal is to provide a standards-based solution for NAT
traversal problems. This involves the definition of a protocol to allow an application such
as a Call Server, SIP Prox, or Media Endpoint to control and obtain information from a
middlebox such as a NAT or firewall. This control function would, for example, make it
possible to have firewall pinholes determined on a per-flow basis, or to obtain
dynamically allocated NAT bindings.
This solution, however, is still some time away. The MIDCOM working group is still in
the protocol definition stage. Once defined, the protocol will need to be implemented,
then deployed via upgrades to currently deployed NATs and firewalls.
There is, however, an immediate need to deploy networks in existing environments,
complete with a wide range of different types of NAT and firewalls. This is the rationale
for Nortels implementation of a media proxy solution that solves NAT traversal
problems today, in a Pre-MIDCOM environment.

G5.5 IP Addressing Example for CS2000 Solutions

Nortel Networks imposes no rigid IP addressing rules for CS2000 solutions. Any IP
addressing strategy can be adopted, subject to the following basic requirements:
! That the private VoIP address domain can reach and be reached from the network
operators public address domain.
! That the network operators public address domain can reach and be reached from
the private address domains of customers.
Some service providers may already have devised and deployed IP addressing strategies
that they wish to retain; others will not have done so. For service providers who have not
already devised their own addressing rules, Nortel Networks suggests the following:
! Call processing elements located in the signalling VLAN(s) of the CS2000 CS LAN
can be addressed by:
" Subnetting the 172.16.0.0/12 subnet with a 19-bit mask
" Subnetting each block with a 23-bit mask to address the CallP VLAN for a
given CS2000
! OAM&P elements located in the OAM&P VLAN of the CS2000 CS LAN can be
addressed by reserving a /26 public subnet.
! OAM&P elements located in the NOC and/or OSS LANs.
Typically, a NOC already exists in a customers network before Succession is
deployed. If a NOC is not already present, Nortel Networks recommends reserving
a /27 public subnet to address the NOC/OSS subnet.
! If the network operator uses out-of-band management (typically to add extra
reliability to network management), it can be based on:
" Using the 192.168.0.0/16 subnet for out-of-band management
" Resubnetting this subnet according to the number of elements that need to be
managed and their physical location.
! The details of media gateway addressing depend on the particular network
configuration to be supported, but the following initial steps are likely to be suitable
for all solutions:
" Using the 10.0.0.0/8 subnet
" Resubnetting this subnet with a 9-bit subnet mask (255.128.0.0)
" Resubnetting the resulting subnets with a 15-bit mask

Figure 169 summarises the application of the example addressing strategy.
Typically already present before

OSS & NOC VoIP network is created; if not,
LANs reserve /27 public subnet
OAM&P VLAN Reserve /26 public subnet
CS2000 Subnet 172.16.0.0/12 with 19-bit

Signalling VLAN(s) mask; subnet each block with 23-bit
CS LAN
mask to address each CS LAN
UAS bearer VLAN
Core
network
Distribution
network
PVGs
Access
network
In 10.0.0.0 block. Subnet 15-bit

subnet with 21-bit mask. Use one Use 10.0.0.0/8 subnet for line MGs.
resulting subnet to address all PVGs. Use public addresses for
subscribers PCs. Use 192.168.0.0
blocks for out-of-band management.
Figure 169: IP addressing example for Succession solutions

Chapter G6 CAC (Call Admission
Control)
G6.1 The Need for Call Admission Control
Call Admission Control (CAC) is necessary in packet networks to address problems that
might otherwise be caused by network congestion.
In a TDM network, the effect of congestion is that new calls cannot be set up across the
network because local exchanges at the edge of the network are unable to seize trunk
circuits. Accepting that some new calls will not be set up is the price of maintaining voice
quality for existing calls. The Grade of Service (GoS) for a TDM network is the likelihood
of being able to set up a call. It is given by the probability of encountering blocking at a
switch operating under normal load, and is typically in the range 0.1% to 0.5%.
In an IP network without CAC, the effect of congestion is that packet loss increases across
the whole network, which means that voice quality is impaired both for existing calls and
for newly set up calls. Accepting some degradation in voice quality is the price of placing
no restrictions on the setting up of new calls.
To achieve PSTN equivalence for VoIP calls over a packet network, devices at the edge
of the packet network must perform a function similar to that of local exchanges in a TDM
network, i.e. they must determine whether new calls should be set up. In so doing, they
provide a point where the probability of blocking can be measured and where appropriate
trade-offs can be made between GoS and QoS targets. A variety of mechanisms can be
used for this purpose. These are collectively referred to as Call Admission Control.
CAC is applied to call attempts that would encounter bandwidth restrictions, and that
should therefore not be set up in the first place.
Ensuring the availability of sufficient bandwidth in a carriers core network is a network
engineering task, and is the responsibility of the network operator. For the purposes of this
document, it is assumed that bandwidth in the core network is effectively unlimited.
Typically, however, there will be access and enterprise networks connected to the core
network. It is not the responsibility of the network operator to engineer these subsidiary
networks, but it is essential for the network operator to have knowledge of how they have
been engineered in order to guarantee the performance of the core network. Aggregation
takes place between access/enterprise networks and the core to ensure that links to and
between core network routers operate at the same high capacity. Admission control
depends on knowing how the overall network is structured in terms of the
routing/aggregation hierarchy, and on being able to apply this knowledge to determine
whether calls should be set up.

CAC (Call Admission Control) Network Fit Communication Server Capabilities
G6.2 CS2000 Support for Virtual Call Admission

Control
Two things are necessary in order to enable CS2000 to support Virtual Call Admission
Control:
! A logical model of the overall network structure, identifying which Limited
Bandwidth Links (LBLs), if any, must be traversed to reach a given media gateway
endpoint.
! A mechanism for capturing this network structure information in a standardised
way and making it available to CS2000 GWCs, enabling them to decide whether
call setup should proceed if LBL traversal is involved.
The effect is that CS2000 can cancel post-dial, pre-ringing calls that would overload a
segment of the packet network.
G6.2.1 Logical Network Model

Access and enterprise networks can be viewed as radiating out from the core network. The
routing/aggregation hierarchy for a given network begins with the links between the core
network and the Customer Edge (CE) router. Behind the CE router is a hierarchy of links
connecting the sites where media gateways are located, as shown in Figure 170.
Core network
(bandwidth assumed to be unlimited)
Link 1 Link 5
Enterprise Enterprise
network A network B
Link 2 Link 6
Site A1 Site B1
Link 3 Link 7
Media gateways Media gateways
Site A2 Site B2
Link 4 Link 8
Site A3 Site B3
Figure 170: Example network topology with LBLs

Communication Server Capabilities Network Fit CAC (Call Admission Control)
The logical model that VCAC uses is based on the links between the sites. Gateways are
described as being behind a particular link. So, in Enterprise A in Figure 170, a gateway
at Site A3 is behind link 4, which is behind link 2, which in turn is behind link 1.
A link with restricted bandwidth is refered to as a Limited Bandwidth Link (LBL). The
bandwidth restriction may be physical (e.g. an ADSL line running at 500Kb/s) or
contractual (e.g. a subscriber who has purchased a maximum of 1Mb/s of simultaneous
VoIP calls). In either case, the capacity available to reach LBL can be defined (see Section
G6.2.2: GWC Support for LBL Traversal and VCAC on page 767 for more details).
The logical network model is a tree structure made up of LBLs in accordance with the
following rules:
! A top level LBL must be connected to a non-bandwidth constrained "core network".
! An LBL can have only one parent, either an LBL closer to the core network or the
core network itself.
! An LBL can have any number of children (subject to the maximum number of LBLs
that may be datafilled per GWC).
These rules mean that:
! There can be no circular network paths
! There can only be one route from a particular LBL back to the core network
! Any gateway will have a single path through the model to the core network, and to
any other gateway that is within the model
Gateways can be added to any LBL in the logical model. An LBL can have any number
of gateways hanging off it. This is usually described as having gateway leaves on the
LBL tree.
Note: PVG and UAS/AMS GWs are assumed to be within the core network. Similarly,
SIP-T trunks are assumed to start/finish in the core network
Once a call is made, the CS2K identifies the LBLs and NATs along the speech path
between the two endpoints, and calculates if there are sufficient resources available on all
the LBLs not to exceed the provisioned limits. If all the LBLs can handle the new call,
then the call progresses as normal. If one or more LBLs cannot handle the call the
originator receives a treatment provisioned by the carrier. The terminator has not reached
a ringing stage so is unaware of the call attempt.
Take, for example, a call between a gateway on Site A3 and a gateway on Site A2. This
call will use resources on links, 2, 3 and 4, but not on link 1 as the call doesnt leave the
enterprise. An insufficient resources failure on any of links 2, 3 or 4 would result in the
call going to treatment.

CAC (Call Admission Control) Network Fit Communication Server Capabilities
G6.2.2 GWC Support for LBL Traversal and VCAC

LBL traversal for media streams requires knowledge not only of what media gateways can
be accessed via a network, but also of which LBL(s), if any, need to be traversed to reach
a given gateway. To enable CS2000 GWCs to determine whether bandwidth limitations
mean that CAC should be applied for a call attempt, each GWC stores the following data:
! Information about all the LBLs in the network.
! Information about which LBL(s), if any, need to be traversed to reach each gateway
or remote CentrexIP client in the network.
The situation for determining whether CAC should be applied for a call attempt is very
similar to the situation for determining whether a media proxy needs to be inserted in a
call to support NAT traversal. LBLs and NATs can both be regarded as types of
middlebox whose involvement in a call has an impact on call establishment at the GWC.
See section B5.1.2.2 on page 155 for further information.
VCAC works by calculating the path between the originating and terminating GWs,
looking at the negotiated codec and ptime for the call and checking that each LBL in the
path has sufficient resources for the call to be set up. If so, the call proceeds as normal, if
not the call is released and a user provisionable treatment (which must be a tone) is applied
to the originator. The terminator has not reached a ringing stage. Each LBL has the
following set of properties:
! Resource Usage Factor
A value, based on the real, negotiated bearer characteristics for the call (codec and
packatisation rate). The term resource, rather than bandwidth is used because the
value may be normalised, or an engineering factor may be applied to
increase/decrease the value away from the real bits on the wire value. This also
allows a customer to simply count calls on a LBL (all codec/ptime pairs use 1 unit
of resource).
The resource usage is per LBL not common across the whole network because it can
relate to a real network element (e.g. a layer 3 value for a codec/ptime pair will be
consistent across the network, but the layer 2 values will vary).
! Maximum Count - This is the maximin amount of resources on the LBL in the same
units the RU Factor is in.
Note: VCAC uses the .
Related features:
A00002739 Virtual Call Admissions Control (VCAC) on CS2000
A00002512 VCAC provisioning for the GWC EM
A00004981 VCAC support for CICM GW
A00003568 E911 location support for CICM
G6.3 Order Codes for VCAC

Table 77: Order codes for VPN software
CS2Q0002 Virtual Call Admission Control (VCAC)

Part H
OAM&P
Chapter H1 Part H CS2000 International Product Description
Overview of OAM&P for CS2000 Solutions OAM&P Communication Server Capabilities
Chapter H1 Overview of OAM&P for

CS2000 Solutions
This chapter describes how OAM&P capabilities are provided for CS2000 and the other
elements of a CS2000-based solution by means of Element Managers and OAM&P
management applications. It is organised as follows:
! Section H1.1: Logical OAM&P Architecture on page 770
! Section H1.2: Physical OAM&P Architecture on page 774
! Section H1.3: Access to EMs and Management Applications on page 782
The other chapters in this Part of the Product Description provide more detailed
descriptions of the OAM&P capabilities provided by Element Managers and management
applications under the functional headings of the standard FCAPS OAM&P model, as
follows:
! Chapter H2: Fault Management
! Chapter H3: Configuration
! Chapter H4: Accounting
! Chapter H5: Performance Management
! Chapter H6: Security (OAM&P Access Control)

CS2000 International Product Description Part H Chapter H1
Communication Server Capabilities OAM&P Overview of OAM&P for CS2000 Solutions
H1.1 Logical OAM&P Architecture

H1.1.1 The Telecommunications Management Network (TMN) Hierarchy
OAM&P functionality (Operations, Administration, Management and Provisioning) for
CS2000 networks is provided by a range of specialised applications running on a number
of different hardware platforms. These applications can be thought of as belonging to a
hierarchy, as follows:
! At the very lowest level of the Telecommunications Management Network (TMN)
hierarchy are the functional Network Elements (NEs) to be managed. These belong
to the Network Element layer (NEL)
! Above the NEL, at the lowest management level, there is an Element Manager (EM)
application for each type of network element or device. Each EM provides
management and maintenance capabilities customised for the requirements and
characteristics of a specific type of device, e.g. a GWC. EMs belong to the Element
Management Layer (EML).
! Above the EML is the Network Management Layer (NML), which is concerned
with the management of the network as a whole rather than individual functional
elements, e.g. monitoring overall network performance.
! Above the NML are the Service Management Layer (SML) and the Business
Management Layer (BML) which abstract the NML view of the network. The SML
provides a customer interface to the network, e.g. the ability to add new subscribers.
At the highest level, the BML is concerned with network planning, e.g. monitoring
network service level agreements.
Nortel provides EMs for CS2000 components and a number of NML applications that are
multi-node in scope, e.g. for trunk and line provisioning.
With effect from ISN07, Nortel also provides the Integrated Element Management
System (IEMS) for integration and correlation purposes. This has two main purposes:
! It aggregates northbound data streams from individual EMs and management
applications, e.g. for fault reporting and performance measurements, and presents
these to OSS applications using standard formats and interfaces.
! It provides a single access point for browsing the topology of CS2000
configurations and for launching EMs and management applications.
For higher-level functions and for integrated network management at the SML and BML
levels, Nortel does not offer standard applications. Instead, such integration is supported
by third-party applications and third-party correlation and browsing tools. The allocation
of responsibilities is as follows:
! Nortel-provided network elements and their EMs present information to the NML
(via IEMS or directly) using open interfaces, public domain protocols and data
models that conform to industry standards.
! Third-party integration applications at the NML provide an interface between the
information provided by Nortel EMs and the information required by OSS
applications at the Service Management Level (SML), which typically run at a
centralised management site.
The integration applications to be used for a given network are commissioned by the
network operator and customised for the requirements of the network in question. They
are therefore outside the scope of this CS2000 Product Description. Their maintenance is
typically the responsibility of a system integrator.

H1.1.2 EMs and Management Applications Supported

Proprietary EMs
The following proprietary Element Managers are supported in ISN07:
! CS2000 Core Manager
! SAM21 Manager
! GWC Manager
! USP Manager
! STORM (Storage Manager) Manager
! PP8600 Device Manager
! UAS Manager
! APS Manager for the UAS Audio Provisioning Server
! MCS Manager for the RTP Media Portal
! Element Manager for the CentrexIP Client Manager
! PMDM (Preside Multi-service Data Manager) for PVG media gateways
! MG9000 Manager for MG9000 media gateways
Non-Proprietary EMs
Small line media gateways deployed on customer premises (MTAs and IADs) are
third-party units. Customised management applications are available for each gateway
type. It is a condition of accepting a given gateway type for deployment as part of a
CS2000 solution that it is provided with a compatible third-party Element Manager.
Details of communication between these EMs and the NML are customer-specific, and
are outside the scope of this CS2000 Product Description.
Note: For MTA cable gateways, the management application manages the CMTS at the
cable head-end as well as the MTAs themselves. The management application used
depends on the CMTS type.

OAM&P Applications
The following OAM&P applications are supported in ISN07:
! CS2000 Core Manager applications:
" SuperNode Billing Application (SBA)
" Event reporting (logs and OMs)
! Trunk provisioning and maintenance applications:
" Trunk provisioning application
" Nodes provisioning application (also used for line provisioning)
" Optional Trunk Maintenance Manager (TMM)
! Line provisioning and maintenance applications:
" Line provisioning application
" Nodes provisioning application (also used for trunk provisioning)
" V5.2 configuration and management application
" Line Test Manager (LTM)
" Optional Line Maintenance Manager (LMM)
! APS provisioning application for the UAS
! Management Data Provider (MDP) for PMDM
! QoS Collector Application (QCA) for aggregating end-of-call QoS statistics
provided by GWCs
! Network Patch Manager (NPM) for co-ordinated distribution / application of
software updates
Note: The OSSGate application is also supported. This provides a single access point for
CS2000 provisioning applications, ensuring that configuration changes made by the node,
trunk and line provisioning applications are co-ordinated.

Integrated Element Management Management centre
773
Page
System (IEMS) provides:
Aggregated northbound data
streams in standard formats GUI
Chapter H1
Single access point for browsing tape

and application launching disk printer
OSS applications
IEMS IEMS
Network
For simplicity, Patch
trunk/line Manager
provisioning apps are (NPM)
not shown individualy
Trunk
Overview of OAM&P for CS2000 Solutions
provisioning Line APS Management

and provisioning provisioning Data
(SBA)
Billing
maintenance and application Provider
maintenance (MDP)
applications
Management
Event reporting
(Logs and OMs)
QoS Third-party units
Collector must be provided
Application
Part H
with a compatible
OAM&P
(QCA) third-party EM
PROPRIETARY
Nortel Networks
CS2000 USP PP8600 UAS APS MCS5200 CICM MG9000 Third-
SAM21 GWC
(EMs)
Core STORM Device PMDM
Manager Manager Manager Manager Mgr. Mgr. Mgr. EM Mgr. party
Manager Manager gateway
EMs
Element Managers
Figure 171: Logical OAM&P architecture for a CS2000 network

CS2000 Audio
Core USP PP8600 MS2000 Provis- RTP PVG
(if SAM21 or MG9000 Third-
(also SCs GWCs routing ioning media CICM V5.2 party
only)
FLPP, used) switch UAS Server portal MGs MGs
STORM
gateways
(Compact
if used)
(NEs)
(APS)
CS2000 components
Network Elements
Proprietary gateways
Figure 171 provides a logical view of the OAM&P architecture for a CS2000 network.

17 August 2004
H1.2 Physical OAM&P Architecture

This section discusses the physical network architecture used for CS2000 OAM&P under
the following headings:
! Trusted access to NEs via the OAM&P VLAN of the CS LAN (see section H1.2.1)
! Access to the OAM&P VLAN from outside the CS2000 CS LAN (see section
H1.2.2 on page 776)
! Software packaging and hardware platforms for EMs and management applications
(see section H1.2.3 on page 777)
H1.2.1 Trusted Access to NEs via the OAM&P VLAN of the CS LAN
The OAM&P VLAN of the CS LAN interconnects the EMS (Element Management
System) servers supporting the EMs (Element Managers) for functional network
elements. These EMs are the only entities that are permitted to access the functional
CS2000 NEs on the signalling VLANs. The EMS servers belonging to the OAM&P
VLANperform a dual role:
! They have trusted access to the CS2000 network elements on the signalling VLAN,
for which purpose they can use the private IP address space of the signalling VLAN.
! They support controlled access from external entities.
The EMS servers on the OAM&P VLAN can be accessed by:
! Appropriately authenticated entities on the NOC LAN, e.g. NOC desktop clients
and Higher Level Management (HML) application servers.
! Appropriately filtered and authenticated external users in Operating Company
intranets, e.g. from the OSS LAN.
Other users in the NOC LAN and Operating Company intranets can access CS2000
network elements only via the EMS interfaces. They have no direct IP route to the CS2000
network elements. No extension of the OAM&P VLAN to other servers or services is
permitted, as this would compromise the security of the CS2000 network elements.
Figure 172 on page 775 illustrates the network architecture.

Nortel
OSS LAN / OC corporate internet Remote
(centralised OAM&P applications) Access
HLM PC clients for EMs and

applications management applications Contivity 600
secure gateway
Enterprise Secure
servers tunneling
NOC LAN
RA to OAM&P VLAN
Untrusted indirect
access to NEs via EMs
RA to CS2000
Element Managers
(trusted access to Network Elements)
Firewall /
perimeter IEMS /
network CBM Other
CMT EMs/apps
PP8600
CS2000
Sun server Sun server Sun server DM CS LAN
EMS servers
CS LAN (OAM&P VLAN)
EM
functionality
for 3rd-party
media Telco SAM21 SS USP
router CS2000 (inc.
gateways Core CICM (inc. MS2010
SC GWC inc. EM EM) EM)
CS LAN can comprise

multiple signalling
VLANs, as illustrated CS LAN (signalling VLANs)
in Figure 8 on page 44;
this diagram simplifies
the network structure (not needed for VoATM)
in order to focus on
OAM&P access PP8600 CS LAN (bearer VLAN)
routers
PVG
Packet backbone network gateways
Line
gateways
Figure 172: Physical OAM&P architecture

H1.2.2 Access to the OAM&P VLAN from outside the CS2000 CS LAN
H1.2.2.1 The NOC (Network Operations Centre) LAN

Network elements and their EMs are managed either from client desktops or indirectly via
higher level management application servers. Depending on the network architecture,
these clients and applications may reside either on a dedicated Network Operations Centre
(NOC) LAN, or elsewhere in the operating companys intranet. The key point is that they
do not reside in the CS LAN. In a given CS2000 network, a higher-level management
application may be responsible for one or more CS2000s.
These entities are regarded as untrusted and may only access management functionality
via the EMS servers on the OAM&P VLAN, which implement user authentication to
control access. Once appropriately authenticated, the clients and higher level management
applications are able to access various OAM&P functions to control CS2000 NEs.
To ensure security for operating company access to the Network Operations Centre
(NOC) LAN, a perimeter network or firewall must be configured between the NOC LAN
entities and other operating company sites.
H1.2.2.2 The Operating Company Intranet and OSS LAN

Access to functional elements and EMs is required by various external entities within the
operating companys main corporate intranet. This includes desktop client applications
outside the NOC LAN, and OSSs that typically reside on an OSS LAN. Such applications
may be centralised and communicate with one or more signaling VLANs.
Because of the external nature of these LANs, these external entities are regarded as
completely untrusted. Security needs to be provided by deploying a perimeter network or
firewall between the CS2000 NOC LAN entities and the operating companys intranet
and OSS LANs. The way in which this perimeter network is implemented is outside the
scope of this CS2000 Product Description. Once appropriately authenticated, these higher
level applications/clients are able to access various OAM&P functions on the EMSs to
control CS2000 NEs.
H1.2.2.3 Emergency and Remote Access


H1.2.3 Software Packaging for EMs and Management Applications

CS2000 EMS OAM&P functionality can be divided into the following categories:
! Core Manager capabilities provided by the CS2000 Core Manager running on the
Call and Billing Manager (CBM) server or SuperNode Data Manager (SDM)
platform. See section H1.2.3.1 on page 778.
! Non-Core management capabilities provided by Non-CM Loads (NCLs) hosted by
the CMT (CS2000 Management Tools) server. Of these, the most important are:
" The CS2M (CS2000 Management) NCL comprising EMs and management
applications for most CS2000 components.
" The Integrated Element Management System (IEMS) NCL, which provides a
single integrated desktop environment for access to all CS2000 EMs and
management applications.
See section H1.2.3.2 on page 779.
! Capabilities provided by non-CMT-resident EMs
Note: The software that supports these capabilities is not integrated in a
CMT-resident NCL, e.g. it may be hosted by an NE or embedded in an NE load, but
integrated access to it is supported via IEMS. See section H1.2.3.3 on page 780.
Figure 173 illustrates how the IEMS provides integrated access to OAM&P capabilities
hosted on different platforms.
Clients for
EMs and HLM applications
management on enterprise
applications servers
NOC LAN
IEMS provides one OAM&P VLAN

externally visible
IP address for
access to all EMs
IEMS
Non-CMT-resident EMs,
e.g. for Session Server,
USP, CICM EM
EMs and mgmt
apps, e.g. GWC
Core Manager EM, SAM21 EM,
applications configuration apps
CBM server or SDM CMT server Non-CMT-resident EMs

(e.g. NE-hosted or embedded)
Figure 173: Integrated access to OAM&P capabilities via IEMS

H1.2.3.1 CS2000 Core Manager on CBM Server or SDM

The CS2000 Core Manager comprises the following specific applications:
! SuperNode Billing Application (SBA)
Reliable storage and forwarding of Core billing records using FTP or FTAM.
! Event reporting, including:
" Log delivery service supporting consolidation of Core and SDM logs into
SCC2/STD log feeds to IEMS for onward delivery to OSS.
" OM delivery service providing Core OMs in CSV files to IEMS for onward
delivery to OSS.
" Passport log streamer for consolidation of PVG logs from the MDM EMS into
the log delivery feeds.
! Support for services based on standard protocols:
" FTP Proxy
Ability to FTP directly to the Core from a client machine.
" SSH Core File Transfer
SSH Secured File Transfer to the Core directly from a client machine.
" BOOTP Loading Service
Standard BOOTP/TFTP service for other components on the CS LAN.
! Base Maintenance Interface
A generic maintenance interface for Core-maintained components (e.g. the FLPP),
allowing operations staff to:
" Receive notification of state changes
" Query states
" Request maintenance actions
! Lawful Intercept
Provides detailed call information (call-related data and relayed call content) for the
use of law enforcement officials.
In ISN07, management capabilities for the CS2000 Core can be delivered in either of two
ways:
! By the Core and Billing Manager (CBM), which is implemented by means of the
CBM software package running on a Sun Netra 240 server.
! By the SuperNode Data Manager (SDM), which is implemented by means of the
CS2E software package on a Motorola PowerPC Series FX system running AIX.
Prior to ISN07, the Core Manager ran only on the SDM AIX platform. This platform is
still supported in ISN07, but supporting the Core Manager on a Sun Netra 240 server
potentially makes it possible to support all CS2000 OAM&P in a single Sun frame. For
an XA-Core configuration using an FLPP, CBM/CS2E software also comprises EM
functionality for the FLPP.
The CBM communicates with the Core only via the OAM&P signalling VLAN of the CS
LAN.

The SDM is co-located with the CS2000. In a CS2000-Compact configuration, it

communicates with the Core via the OAM&P VLAN of the CS LAN. In a standard
XA-Core configuration, it uses the OAM&P VLAN to support BOOTP/TFTP services for
other CS2000 components; for communication with XA-Core, it has a dedicated DS-512
interface with the Message Switch (MS).
The Core Manager for each CS2000 in a network communicates with a central network
management site by means of a managed IP network. Core Manager applications are
based on the client/server model. The application servers run on the CBM/SDM platform,
while application clients run on the operating companys workstations or Operations
Support System (OSS) computers at the central site.
H1.2.3.2 Software Hosted by the CS2000 Management Tools (CMT) Server

The CS2000 Management Tools (CMT) server is a Sun Netra 240 server housed in a
PTE2000 cabinet and attached to the OAM&P VLAN. It hosts a number of Non-Core
Loads (NCLs) that provide management capabilities for CS2000 components. These
NCLs are:
! The CS2M (CS2000 Management Components) NCL, which comprises the
following software packages:
" SESM (Succession Element and Sub-Network Manager)
# GWC Manager
# Node Configuration
# Trunk Configuration
# Carrier Endpoint Configuration
# Line Configuration (SERVORD+)
# LMM (Lines Maintenance Manager)
# V5.2 Configuration
# V5.2 Maintenance
# Media server management
# Media server configuration
# APS Manager
# Common Launch Point (CLP) for CS2000 Management Tools
" SAM21 SC EM
The software package that contains the CS 2000 SAM21 Manager application
for the SAM21 Shelf controller.
The software package that contains the QoS collector application for per-call
QoS records sent from the CS2000 GWC.
! IEMS (Integrated Element Management System)
The NCL that provides a single integrated desktop environment for access to most
other (eventually all) CS2000 EMs and management applications. Specifically, the
IEMS provides:
" Graphical topology and inventory relationships between NEs and EMs.
" Aggregation of all EMS/NE fault data.
" Integrated fault streams to NML.

" Customer choice of OSS fault interfaces (SCC2, SYSLOG, NT STD and
SNMP)
" Centralised fault viewer with filtering capability
" Context-sensitive launching for EMs, management applications and CLUIs
(Command Line User Interfaces) supporting access to NEs.
" Enhanced security via more centralised administration of user accounts and
passwords for PAM-enabled systems.
See section H1.3.1 on page 782 for further information about IEMS support for
access to management capabilities for other CS2000 components.
! APS (Audio Provisioning Server)
! SSPFS (Succession Server Platform Foundation Software)
The NCL software package that contains base operating system and common tools,
libraries and server functions used by EML applications. These include:
" EMS proxy services supporting access to embedded server software,
including:
# Call Agent Manager for the Call Agent platform
# STORM Manager embedded in STORM software load
# Client for USP Manager embedded in USP software load
" PM Poller
" NPM (Network Patch Manager) for GWCs
" Generic services and protocols such as BOOTP, DHCP, TFTP and KDC
H1.2.3.3 Non-CMT-Resident EMs

The following EMs are not resident on the CMT server, but can be accessed via IEMS if
they are co-located with CS2000 and connected to the CS LAN:
! PP8600 Device Manager
PP8600 Device Manager is a Java-based client application that interfaces directly
with PP8600s without a server. It can run either on a Windows PC or on a Sun
workstation.
! USP Manager server software embedded in USP load.
! Call Agent platform manager software.
! STORM software embedded in the STORM software load (STM04).
! Session Server web server software running on Session Server to provide
provisioning and maintenance web pages.
! CICM Manager
CICM EM capabilities are provided by server software embedded in the software
load of a CICM EM card housed in a SAM21 shelf, controlled by a management
client that is implemented as an Explorer browser.

! PMDM (Preside Multiservice Device Manager) for PVGs

PMDM runs on a dedicated Sun server. The NCL name is PCR. In addition to
PMDM itself, the server hosts
" MDP (Management Data Provider) application
" MDM client server
The recommended server for PMDM is the Sun N480. This is typically located on
the NOC LAN rather than the CS LAN, in which case the customer (operating
company) is responsible for supplying it. It can, however, be supplied by Nortel and
connected to the CS LAN if this is requested by the customer.
Note: The decision about where to locate the PMDM server(s) is a matter for the
operating company. It depends on a number of factors, including:
" The number of PVGs in the network
" Whether PVGs are co-located with CS2000
" Whether PMDM is to be accessed via IEMS
In theory, up to 30 PVGs can be managed from a single PMDM server, but in
practice the number of PVGs managed by a given PMDM server is likely to be
significantly less than this. Network-specific capacity studies should be used to
determine an appropriate practical limit. If the PVGs in a network are widely
distributed and all of them can be managed by a single PMDM server, it makes
sense for this to be centrally located. In networks where PVGs and CS2000 are
co-located, however, it may be best for the PMDM server to be co-located as well.
Co-location of PMDM and IEMS is a prerequisite for IEMS-controlled integration
of PVG management with that of other network elements.
! MG9000 Manager
Runs on a Sun server. NCL name is 9KEM.
! MCS Manager comprising
" Management Module
" Database Module
" Accounting Module
MCS System Manager running on Sun server. NCL names are IMSC and IMSD.
Provides EM functionality for RTP Media Portal.

H1.3 Access to EMs and Management Applications

H1.3.1 The Integrated Element Management System (IEMS)
With effect from ISN07, CS2000 supports the use of the Integrated Element Management
System (IEMS) for access to EMs and management applications. This runs on the same
Sun Netra 240 server as CMT. It provides a tree-like expandable Integrated EMS
Topology menu to represent and support drill-down access to:
! Network Elements
" CS2000 Core (XA-Core or Compact)
" STORM
" PP8600
" GWC
" SAM21
" CICM
" Session Server
" USP
" MS2000 or UAS
" PVG
" MG9000
" MCS5200
" RTP Media Portal
! Element Managers
" GWC Manager
" SAM21 Manager
" CICM Manager
" USP Manager
" UAS Manager
" APS Manager
" MCS System Manager
" Preside MDM
! EMS Platforms such as
" CBM or SDM
" SSPFS
" MDM
" CICM Manager platform
" MCS Manager platform
! EMS Applications such as
" OSSGate (access to Node Configuration, Trunk Configuration, Carrier
Endpoint Configuration, Line Configuration via SERVORD+, V5.2
Configuration, V5.2 Maintenance)
" TMM (Trunk Maintenance Manager)
" LMM (Line Maintenance Manager)
" LTM (Line Test Manager)
" APS
" NPM (Network Patch Manager)

H1.3.2 User Access to IEMS, EMs and Management Applications

The number of users who can have simultaneous management access to CS2000 NEs and
EMs is controlled at various levels. Limits are imposed in order to ensure that system
performance and response times are acceptable. As summarised in Table 78, limits are
imposed not only by IEMS but also at lower levels, by some of the EMs and applications
that can be accessed via IEMS.
Table 78: Simultaneous user access to CS2000 NEs and EMs

Component / application Number of simultaneous users
40 Java clients [1]

IEMS
22 HTML clients [1]
SDM 32 desktops
CS2000 Management Tools (GWC EM, UAS EM, node
provisioning, trunk provisioning, line provisioning) [2] 10 [3]
APS 5
USP Manager Proxy 5
LMM 4
TMM 4
NPM 3
PP8600 Device Manager 1
STORM 1
MG9000 Manager 64
[1] IEMS can support more Java clients than HTML clients because Java clients work on
downloaded raw data, while HTML clients require the server to perform data processing.
[2] Also comprises PMDM and MDP is PVGs are managed via the CS2000 OAM&P VLAN rather
than from a central location.
[3] OSSGate provides a single access point for Succession provisioning applications, and applies its
own limits, as discussed in section H3.6 on page 802.
Some desktop applications can access multiple network elements, subject to the limits
summarised in Table 79.
Table 79: Simultaneous access to multiple network elements

Application Number of network elements
SDM Configurable
APS Several simultaneously, no limit defined
USP Manager Proxy Several simultaneously, no limit defined
PP8600 Device Manager Several, one at a time
STORM Several simultaneously, no limit defined
MG9000 Manager 4
PMDM and MDP Configurable

Chapter H2 Fault Management
H2.1 Summary of Fault Management Capabilities
IEMS aggregates all EMS/NE fault Format of single consolidated

data for CS2000 Core, STORM, fault feed can be any of:
PP8600, USP, SAM21, GWC, SCC2
MS2000/UAS, MCS5200, CICM, PVG NT STD
(if PMDM on CS LAN) and MG9000 SNMP
communication with NML

Custlog
responsible for details of

IEMS IEMS
GW supplier is
SNMP
SNMP
SNMP
SNMP
Corba
Corba
Corba
SCC2
SCC2
SNMP (alarms) and Syslog (logs)
CS2000 UAS 3rd-pty

PP8600 Core MCS MG gateways
USP SAM21 GWC Mgr. PMDM 9000
Device Mgr. and 5200 must have
Mgr. Mgr. Mgr. Mgr. Mgr.
(SDM or APS Mgr. compatible
CBM) 3rd-pty EM
Fault
reporting
ASCII ASCII must be
SNMP
SNMP
SNMP
SNMP
SNMP
SNMP
SNMP
via via trapped /

TCP TCP OFF
CS2000
Core USP RTP
PP8600 SAM21 media CICMs MG 3rd-pty
routers (also (if GWCs UAS PVGs
SCs portal (if 9000s gateways
FLPP, used) used)
if used)
CS2000 components
Figure 174: Overview of support for fault management in a CS2000 network

Fault Management OAM&P Communication Server Capabilities
H2.1.1 Providing Fault Management Information

There are four aspects to CS2000 support for fault management:
! Alarm reporting (see section H2.2 on page 788)
Alarms are the primary fault reporting mechanism, providing real-time notification
of faults that have occurred so that appropriate action can be taken. Alarms are
complemented by logs, which provide more detailed information. This can be used
not only in solving specific problems but in systematic analysis of when and why
faults occur.
! Fault reporting via logs (see section H2.3 on page 789)
" Supported for the CS2000 Core
Logs are generated in Nortel STD (standard format) by the Core, then
converted into SCC2 (Switching Control Centre 2) format. SCC2 is a Bellcore
standard for integrating logs generated by different vendors equipment in a
" Supported by the PMDM (Preside Multi-service Data Manager) used to
manage PVGs. Alarm and status reports provided by PMDM are mapped on
to logs and converted into SCC2 format via the SDM-provided SLG API.
Logs are ultimately sent to the network operators OSS by IEMS.
! Other fault reporting mechanisms (see section H2.4 on page 793)
Network elements that do not generate logs also need to provide notification of
alarms and status changes. The mechanisms used are summarised in the table
below.
Reporting mechanism
Network Notes
element From element to To present
information to
EM
IEMS
In addition to reporting GWC faults,

GWC SNMP Corba GWCs controlling PVGs provide
gateway state reports.
Direct feed from CICM to IEMS,

CICM using SNMP (alarms)
and Syslog (logs)
In releases prior to ISN06, the

SAM21 EM ran on the SDM platform.
SAM21 SC SNMP Corba It is now supported on the same Sun
Netra server platform as the GWC
EM.
USP SNMP SNMP
PP8600 SNMP SNMP
The UAS runs on the same server as

UAS SNMP Corba the APS and the GWC and SAM21
EMs.

Communication Server Capabilities OAM&P Fault Management
Reporting mechanism
Network
element To present Notes
From element to information to
EM
IEMS
RTP Media
SNMP SNMP
Portal
PVGs use ASCII

over TCP to
provide PMDM PVG state changes are also reported
PVG Corba
with the via their GWCs.
information used
to create logs
MG9000 SNMP SNMP
Third-party gateways must come with

Third-party a compatible third-party Element
media Typically SNMP Vendor-specific Manager. Faults are not reported by
gateways CS2000 to the NML on behalf of
these gateway types.
! Fault isolation and correction (see section H2.5 on page 794)

" Fault isolation and correction is carried out via the EM for the network
element in question, e.g. the Core Manager or the GWC EM.
" In addition, CS2000 supports two optional management applications for trunk
and line maintenance:
# TMM (Trunk Management and Maintenance)
# LMM (Line Management and Maintenance)

H2.1.2 Integrated Handling of Fault Management Information

With effect from ISN07, the Integrated Element Management System (IEMS) can be used
to integrate all fault data provided by the following NEs and their EMs:
! CS2000 Core
! STORM
! PP8600
! USP
! SAM21 SC
! GWC
! MS2000/UAS
! MCS5200
! CICM
! PVG (if PMDM on CS LAN)
! MG9000
A single consolidated northbound fault feed can be provided in any of the following
formats:
! SCC2
! NT STD
! SNMP
! Custlog
Third-party integration applications at the NML provide an interface between the
information provided via IEMS and the information required by other NML applications
and by OSS applications at the Service Management Level (SML), which typically run at
a centralised management site. For fault management, the primary functions of such
integration applications are:
! Browsing and correlation
Providing user interfaces at the NML level that allow maintenance staff to focus on
faults at any required level of detail, and to determine whether there are correlations
or interdependencies between separately reported faults.
! Filtering
! Root cause analysis
! Trouble ticketing

H2.2 Alarm Reporting

Typically, alarm information is provided to administrative staff via the IEMS Alarm
Manager GUI, and is relayed to the carrier 's OSS in the customers preferred format.
H2.2.1 Alarm Categories

Each alarm is allocated to one of four categories depending on its severity:
! Critical
! Major
! Minor
! Warning
The Alarm Manager GUI is provided with a count of the number of reported alarms and
acknowledgments belonging to each category.
H2.2.2 Alarm Attributes

A list of relevant attributes is provided for each reported alarm, as follows:
! NE name
! Alarm type
! Reason
! Severity
! Time
H2.2.3 Alarm Details

For each reported alarm, the Alarm Manager GUI creates a record with the following
information:
! NE name (user label)
! Alarm ID (notification id)
! Alarm type (communications, quality, process, equipment or environment)
! Probable cause
! Equipment type
! Reason
! User ID of the user who acknowledged the alarm
! Hostname/display address where the alarm was acknowledged
! Time when the alarm was acknowledged
H2.2.4 Responding to Alarms

Users can use the Alarm Manager GUI to perform the following alarm-related actions:
! Acknowledge an alarm
! Unacknowledge a previously acknowledged alarm
! Clear an alarm manually.
Note: When a new alarm arriving at the IEMS has been acknowledged by one user via
the IEMS Alarm Manager GUI, other users of the Alarm Manager GUI will no longer see
that alarm unless they have the "Show Acknowledged" check box turned on. This
prevents duplication of effort.

H2.3 Fault Reporting via Logs

H2.3.1 Log Generation
A log report is a message output to indicate the occurrence of a significant event in a
system or an individual hardware unit. Log reports include status and activity reports on
hardware and software faults, test results, changes in state and other events or conditions
likely to affect system performance of the CS2000. Log reports are typically generated
automatically in acordance with specified criteria, but they may also be generated as a
result of a manual operation.
In a CS2000 network, fault reporting via logs is supported for
! CS2000 Core
! SAM21 SC
! CICM
! PVGs
H2.3.2 Logs for CS2000 Core and SAM21

Log Report Format
A log report consists of a one-line log header that provides summarised information,
followed by a log body whose format is defined and controlled by the specific application
that generated the log.
CS2000 can generate log reports with either of two types of header (both are very similar):
! Nortel proprietary STD (standard) header.
! SCC2 (Switching Control Centre 2) format, which supports the integration of logs
generated by different vendors equipment in a multi-vendor network.
The header line of every log report contains the following elements:
! Header
Typically identifies the switching node and component being reported on. This
information reflects customer data schema datafill.
! Event type
An abbreviation indicating the event or condition being reported (e.g. SYSB, TBL).
! Event description
A string containing one or more of the following fields:
" Event Identification
This is constant for every log report of the same name and number. For
example, the event identification for a Line101 log report is always
LINE_DIAG.
" Equipment Identification
This is variable. It may identify hardware or software. For example, it could
identify a peripheral and its location, or line equipment and an associated
directory number.
" Reason Codes
These are variable, depending on application.
The event description may be left blank.

! In a system that includes multiple log-generating nodes, such as a CS2000 equipped

with XA-Core, the log header can use the ECORE (Enhanced CORE) option to
distinguish between them.
Refer to the document LOGSPEC for detailed information about the similarities and
differences between STD and SCC2 field definitions and formats.
SCC2 format is formally defined in Bellcore document TR-190-23140-84-01.
Log Generation Criteria (Threshold Parameters)

The types of event reported and the frequency with which reporting takes place are
controlled by the CS2000 Manager running on the CBM server or SDM.
Specific criteria that can be specified to control log generation include:
! Criteria based on time of day and date.
! Criteria based on traffic volumes.
! Criteria based on the severity level of exceptions.
Criteria can be component-based (controlling log reporting for a specific unit) or
system-based (controlling log reporting for the CS2000 as a whole).
Management capabilities
The CS2000 Core Manager allows the operational characteristics of the log reporting for
a CS2000 to be checked and modified interactively. Specific capabilities:
! Routing of selected logs in real time to specific OSS applications or remote devices
! Temporarily overriding datafill-defined parameters, e.g. to turn log reports off
! Viewing log generation criteria (threshold parameters)
! Modifying the set of log reports to be provided
! Undoing the last change or reverting to stored log generation criteria
! Saving files containing customised log generation criteria for subsequent re-use
! Broadcasting log generation criteria to multiple CS2000s

H2.3.3 Logs for PVGs

SLG (SDM Log Generation) is an SDM subsystem that provides APIs for the generation
of logs that can be read by IEMS
PVG log generation makes use of an SLG API called gen_cust_log(), which is
defined as follows:
gen_cust_log
(char *reportName,
int reportNum,
int alarmValue,
int eventType,
char *label,
char *textFormat,
...)
where
reportName
A log report name consisting of 2 to 4 non-blank characters, e.g. PM.
reportNum
A log report number in the range 0 to 999.
alarmValue
The severity level of the log report. Possible enumerated values are:
cCRIT = critical alarm
cMAJOR=major alarm
cMINOR = minor alarm
cNONE= no alarm
eventType
A log report event type, as defined by the log generation application. Existing
possible values include:
cNONE cUNEQ cCBSY cEXC cFAIL cFLT cNFO cINIT cLO cMANB
cOFFL cPASS cPBSY' cRTS cSUMM cSYSB cTBL cTRAN cTRAP
label
A variable length character string that represents an application specific event
description. (padded with one space if empty). This field is currently
overriden by the Log System and output as part of the restoflog field if used.
textFormat
A printf()-style format string that specifies the layout and format of the
remainder of the log (the log body lines).
...
A variable number of arguments with the layout specified in the textFormat
variable.
The information provided from PMDM to CBM/SDM via this SLG API is converted into
the BSL (Bar-Separated Log) format used internally by IEMS, and finally converted into
the required log format (typically SCC2) required by the network operators OSS.

H2.3.4 Log Delivery System

The Log Delivery System (LDS) is a Core Manager application that delivers log reports
to IEMS. It uses the Generic Data Delivery (GDD) framework for data delivery.
Delivering data involves a number of complex steps (configuration, registration,
acquisition, formatting, distribution), but requires no knowledge or understanding of
content.
GDD can be regarded as a storage mechanism for logs. All customer logs are stored for
30 days on a permanent storage device in the /gdd volume.
From the Log Delivery Systems point of view, logs are sent to devices. Devices
supported are:
! FILE (local file storage)
! TCP (a TCP connection to a specified IP address and port number)
! TCPIN (a TCP connection to a specified IP address and port number, with the
connection initiated by the receiver)
The subset of log reports to be delivered is specified in a configuration file.
The Log Delivery System assigns a sequence number for each delivered log. This is a
four-digit number that starts at 0000 and increments to 9999, then restarts at zero. If Log
Delivery is BSYed and RTSed, the sequence number is reset to zero.
Log reports can be provided to the NML by IEMS in any of the following formats:
! Nortel proprietary STD (standard) header.
! SCC2 (Switching Control Centre 2) format, which supports the integration of logs
generated by different vendors equipment in a multi-vendor network. SCC2 format
is formally defined in Bellcore document TR-190-23140-84-01.
! SNMP
! Custlog
Figure 175 summarises the operation of the log delivery mechanism.
802.3
TCP/IP IEMS
delivery Format of single
consolidated fault
feed can be any
logs Log of:
Formatting SCC2
NT STD
OSS
SNMP
ASCII
Printer stream
Custlog
delivery
Configuration files
Printer
Figure 175: Log delivery mechanism

H2.4 Other Fault Reporting Mechanisms

Network elements that do not generate logs use the mechanisms listed below to provide
notification of alarms and status changes to IEMS for onward delivery to the NML:
! GWCs
GWCs report faults to the GWC EM via SNMP (Simple Network Management
Protocol).
The GWC EM uses the standard Common Object Request Broker Architecture
(Corba) to present information to IEMS.
Note: In addition to reporting GWC faults, GWCs controlling PVGs provide
gateway state reports.
! SAM21 SCs
SAM21 SCs report faults to the GWC EM via SNMP (Simple Network
Management Protocol).
The SAM21 EM uses Corba to present information to IEMS.
! USP
For the USP, SNMP is used both for the reporting of faults to the USP EM and for
the presentation of information to IEMS.
! PP8600 router
For the PP8600 router, SNMP is used both for the reporting of faults to the PP8600
Device Manager and for the presentation of information to to IEMS.
! UAS
The UAS reports faults to the UAS EM via SNMP (Simple Network Management
Protocol).
The UAS EM uses Corba to present information to to IEMS
Note: Typically, the UAS runs on the same Sun Netra server as the APS and the
GWC EM, and information is presented to the NML on behalf of all three in a single
merged stream of Corba data.
! RTP media portal
For the RTP media portal, SNMP is used both for the reporting of faults to the MCS
Manager and for the presentation of information to to IEMS.
! Gateways
" PVGs
PVGs use ASCII over TCP to provide PMDM with the information used to
create logs.
PVG state changes are also reported via their GWCs.
" MG9000
For the MG9000, SNMP is used both for the reporting of faults to the
MG9000 Manager and for the presentation of information to IEMS.
" Third-party media gateways, e.g. cable and customer LAN line gateways
Third-party gateways are accepted for deployment with CS2000 only if they
are equipped with a compatible third-party Element Manager. Typically, the
gateway communicates with its EM using SNMP. Details of communication
between the EM and the NML are vendor-specific. Faults are not reported to
the NML by CS2000 on behalf of these gateway types, i.e. it is the
responsibility of the gateway supplier to ensure that faults are trapped and
routed elsewhere for treatment.

H2.5 Fault Isolation and Correction (Maintenance)

Fault isolation and correction is carried out via the EM for the network element in
question, e.g. the Core Manager or the GWC EM, which is launched and controlled via
IEMS.
In addition, CS2000 supports two optional management applications for trunk and line
maintenance:
! TMM (Trunk Management and Maintenance)
! LMM (Line Management and Maintenance)
If used, the TMM and LMM applications are installed on the CMT server and controlled
via IEMS.
Specific maintenance capabilities supported via TMM and LMM are:
! Trunk maintenance via TMM
" POST specific trunk
" BSY specific trunk
" RTS specific trunk
" FRLS specific trunk
" BSY trunks by gateway
" RTS trunks by gateway
" ISUP continuity testing.
" PRI support
# Trunk states DMB and DFL
# POST D-channel
! Line maintenance via LMMs
" POST specific line
" POST by group for V5.2 lines
" BSY specific line
" RTS specific line
" FRLS specific line
" BSY INB
" CPD
" Cancel CPD
" BSY lines by gateway
" RTS lines by gateway
TMM and LMM can also be used to support trunk and line provisioning, as described in
Chapter H3: Configuration.

Chapter H3 Configuration
H3.1 Summary of Configuration Capabilities

H3.1.1 Commissioning
IEMS provides a single access point

for browsing the topology of CS2000 Note: IEMS not involved
configurations and for launching EMs for carrier-located MGs
and management applications. managed from central site
IEMS IEMS
Auto-configuration via DHCP and TFTP

when gateway is activated / initialised
ASCII ASCII
SNMP
SNMP
SNMP
SNMP
Corba
Corba
Corba
SNMP
via via
TCP TCP
CS2000 UAS
PP8600 Core MCS MG
USP SAM21 GWC Mgr. CICM PMDM 9000
Device Mgr. and 5200
Mgr. Mgr. Mgr. Mgr. Mgr. Mgr.
(SDM or APS Mgr.
CBM)
ASCII
DCOM
ASCII
SNMP
SNMP
SNMP
SNMP
SNMP
SNMP
SNMP
via via
TCP TCP
CS2000
Core USP RTP
FLPP, used) used)
if used)
CS2000 components Gateway provisioning is independent;

co-ordination with CS2000 Core and
GWCs is achieved via endpoint naiming
Figure 176: Overview of support for NE commissioning in a CS2000 network

Communication Server Capabilities OAM&P Configuration
H3.1.2 Service Activation

Trunk and line provisioning for service activation is a multi-step process that requires
information to be provided to the CS2000 Core, GWCs, media gateways and (depending
on the interface in question) other nodes such as the USP and CICM.
To ensure that NE updates are co-ordinated, the OSSGate application is used to support
integrated provisioning. This provides a single user interface for access to:
! Trunk provisioning application
! Line provisioning application
! Node provisioning application
! V5.2 provisioning applications
These applications and OSSGate itself are included in the SESM software package that
resides on the CMT server as part of the CS2M NCL.
IEMS does not provide provisioning capabilities, but can be used to launch the OSSGate
application. Once launched, OSSGate runs as an independent server, waiting for clients
to access it and provide provisioning input, either in the form of XML or (for line
provisioning only) via the SERVORD+ provisioning interface.
Figure 177 provides an overview of how trunk provisioning for service activation is
supported in a CS2000 network.
API XML
EM
APIs
Integrated provisioning
OSSGate for integrated provisioning applications on
CMT server
Node Trunk Line V5.2 Network

provisioning provisioning provisioning provisioning view
application application application application database
ASCII
Corba
via
SNMP
ASCII
TCP via
TCP
CS2000
Core PMDM
USP Mgr. GWC
Mgr. (SDM or Mgr.
CBM)
ASCII ASCII
SNMP
SNMP
via via
TCP TCP
CS2000
Core 3rd-pty
USP PVGs gateways
(if (also GWCs
used) FLPP,
if used)
Gateway provisioning is independent; co-ordination with
CS2000 components CS2000 Core and GWCs is achieved via endpoint naiming
Figure 177: Trunk provisioning overview

Configuration OAM&P Communication Server Capabilities
Figure 178 provides an overview of how line provisioning for service activation is
supported in a CS2000 network.
EM
SERVORD+ XML APIs
Integrated provisioning
OSSGate for integrated provisioning applications on
CMT server
Auto-configuration via DHCP and TFTP

when gateway is activated / initialised
Node Trunk Line V5.2 Network
provisioning provisioning provisioning provisioning view
application application application applications database
ASCII
SNMP
ASCII
Corba
via
SNMP
TCP via
TCP
CS2000
Core MG
Mgr. GWC CICM 9000 PMDM
(SDM or Mgr. Mgr. Mgr.
CBM)
DCOM
ASCII ASCII
SNMP
SNMP
via via
TCP TCP
CICMs MG 3rd-pty
CS2000 (if 9000s PVGs gateways
Core GWCs
used)
CS2000 components Provisioning for PVG V5.2 gateways and

3rd-party gateways is independent;
co-ordination with CS2000 Core and
GWCs is achieved via endpoint naiming
Figure 178: Line provisioning overview

H3.2 Hardware Commissioning

Commissioning of hardware units for installation is achieved via the Local Craft Interface
and EM for the unit. This applies to:
! CS2000 Core
! GWCs
! CICM
! SAM21 card cages
! USP
! PP8600s
! SAM16 UAS
! PVGs
Note: Third-party units, e.g. cable and customer LAN line gateways, use a variety of
methods for configuration and provisioning. These typically involve the use of DHCP
(Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol) for
auto-loading when the gateway is first activated and initialised. See section D14.2.2: Line
Media Gateway Configuration on page 353 for more details.
Interface and protocol usage for hardware unit configuration is as follows:
! CS2000 Core configuration via CS2000 Manager using ASCII over TCP
! GWC configuration via GWC EM using SNMP
The operation of GWCs with subtending units is controlled by SNMP MIBs
(Management Information Bases) stored by the GWCs. SNMP (Simple Network
Management Protocol) is an IETF protocol designed for communication between
Element Managers and the network elements they control. A MIB is an
object-oriented data structure designed to capture provisioning information in a
standardised way. The GWC Manager uses SNMP to populate each GWCs MIB
with the information it requires to perform its network role.
! SAM21 configuration via SAM21 EM using SNMP
! USP configuration via USP Manager using SNMP
! PP8600 configuration via PP8600 Device Manager using SNMP
! UAS
" SAM16 configuration via UAS Comand-Line Interface (CLI) using SNMP
" UAS audio service configuration via APS using SNMP
" Automatic discovery of UAS hardware to UAS EM
! PVG configuration and provisioning via PMDM GUI using ASCII over TCP
interface
! Primary TFTP (Trivial File Transfer Protocol) server configured on CS LAN to
support load retrieval for GWCs and SAM21 SCs

H3.3 Trunk Provisioning

Trunk provisioning requires updates to be made to the data stored by some or all of:
! CS2000 Core
! GWCs
! Trunk media gateways
! USP (if used)
Two applications are provided to help ensure that these separate updates are co-ordinated:
! Trunk provisioning application
! Nodes provisioning application (also used in line provisioning)
These applications and the OSSGate application used to access them are included in the
SESM software package that resides on the CMT server as part of the CS2M NCL. The
provisioning server also hosts a database that provides an integrated view of the network
as a whole, combining the separate views of different network nodes. It can also host the
optional Trunk Maintenance Manager (TMM) application, which provides maintenance
capabilities.
The trunk provisioning and node provisioning applications both provide XML
(Extensible Markup Language) interfaces for handling provisioning data. Each
application uses this XML input to generate two types of output:
! ASCII over TCP, which is provided to the CS2000 Core Manager on the SDM and
used by it to update CS2000 Core datafill.
! Corba data, which is provided to the GWC EM and used by it to update GWC data.
See Chapter C2: Trunk and Line Datafill for information about the trunk data stored by
CS2000 Core and GWCs.
Trunk provisioning is a two-stage process:
! The first stage is to use carrier provisioning to map the CS2000 Cores view of a
trunk, i.e. a trunk Terminal ID (TID), to an endpoint on a gateway.
! The second stage is to datafill the CS2000 Cores trunk tables.
Both of these functions can be accessed by a provisioning system through OSSGate,
which provides a single access point for Succession provisioning applications. OSSGate
monitors input ports and allows clients to connect via Telnet. It provides
connection/session management and authentication, and supports both XML and CI
(interactive) mode for input. For XML input, OSSGate performs basic syntactic checks to
validate the input before sending it to the nodes being provisioned.
For PVG media gateways supporting physical trunks, trunk provisioning is independent
of the Core / GWC provisioning process. Manual co-ordination is therefore required
between gateway data and Core / GWC data. This is achieved by ensuring that endpoint
naming is consistent between the three different types of node. PVG trunk provisioning is
carried out using the PMDM GUI, which supports communication with the PVG using
ASCII over TCP.

If CCS7 functionality for a CS2000 is provided by the USP, CCS7 routesets and linksets
are datafilled on the USP rather than the Core. The USP sends the Core the routeset
information it needs to populate its tables, and also keeps the Core informed about
routeset availability. (If CCS7 functionality is provided by the FLPP, the necessary tables
are automatically datafilled as part of the trunk provisioning process for the CS2000
Core.) USP provisioning is carried out using the USP EM GUI, which supports
communication with the USP using SNMP.
H3.4 Line Provisioning

Line provisioning requires updates to be made to the data stored by some or all of:
! CS2000 Core
! GWCs
! Line media gateways
! PVGs configured to support V5.2 interfaces
The following applications are provided to help ensure that these separate updates are
co-ordinated:
! Line provisioning application
! Nodes provisioning application (also used in trunk provisioning)
! V5.2 provisioning application
These applications and the OSSGate application used to access them are included in the
SESM software package that resides on the CMT server as part of the CS2M NCL. The
provisioning server server also hosts a database that provides an integrated view of the
network as a whole, combining the separate views of different network nodes. It can also
host the optional Line Maintenance Manager (LMM) application, which provides
additional provisioning and maintenance capabilities.
The line provisioning and node provisioning applications support different interfaces for
handling provisioning data.
! The lines provisioning application supports the proprietary SERVORD+ (Service
Order) interface. The SERVORD+ NEW command specifies the following for each
line:
" The DN (Directory Number) to be assigned to the line.
" The gateway endpoint servingthe line.
The SERVORD+ ADO (Add Option) command is used to assign features to lines.
Note: V5.2 line provisioning also involves the V5.2 provisioning applications
described in section H3.5 on page 801.
! The nodes provisioning application supports an XML (Extensible Markup
Language) interface.
The lines and nodes povisioning applications can both be accessed by a provisioning
system through OSSGate, which provides a single access point for Succession
provisioning applications. OSSGate monitors input ports and allows clients to connect via
Telnet. It provides connection/session management and authentication, and supports both
XML and CI (interactive) mode for input. For XML input, OSSGate performs basic
syntactic checks to validate the input before sending it to the nodes being provisioned.

Each application uses line provisioning input to generate two types of output:
! ASCII over TCP, which is provided to the CS2000 Manager on the SDM and used
by it to update CS2000 Core datafill.
! Corba data, which is provided to the GWC EM and used by it to update GWC data.
See Chapter C2: Trunk and Line Datafill for information about the line data stored by
CS2000 Core and GWCs.
For a cable or customer LAN line gateway, datafill is provided as follows:
! GWC datafill via GWC EM
GWC EM specifies FQDN (Fully Qualified Domain Name) of gateway.
address can also be specified.
Typically, however, line gateway IP addresses are assigned via DHCP (Dynamic
Host Configuration Protocol), and the GWC discovers the IP address of a line
gateway dynamically.
! Gateway datafill
Cable and customer LAN line gateways are third-party units that use a variety of
methods for configuration and provisioning. These typically involve the use of
DHCP (Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer
Protocol) for auto-loading when the gateway is first activated and initialised. See
section C2.8.3 on page 201 for an illustrated explanation of the network
configuration and information flows involved in configuring a line media gateway.
For media gateways supporting lines, line provisioning is independent of the Core / GWC
provisioning process. Manual co-ordination is therefore required between gateway data
and Core / GWC data. This is achieved by ensuring that endpoint naming is consistent
between the three different types of node.
H3.5 V5.2 Provisioning

Two applications are provided for the provisioning of V5.2 lines supported off PVG
media gateways:
! V5.2 management application
This supports an XML interface for the provisioning of the tables that define the
characteristics of each V5.2 interface.
! V5.2 maintenance application
This maps V5.2 interfaces on to E1 carriers terminated on the TDM side of a PVG.
As for trunk and line provisioning, OSSGate is used to provide a single access point for
these V5.2 provisioning applications.

H3.6 Connections to Provisioning Applications

OSSGate provides a single access point for CS2000 provisioning applications. There are
limits to the maximum number of users who can use each provisioning application
simultaneously via OSSGate. These limits vary depending on whether the application in
question is being run in isolation, i.e. with no other provisioning application being active,
or is being run at the same time as other provisioning applications. The limits that apply
are summarised in Table 80.
Table 80: Limits on simultaneous access to provisioning applications
Maximum number of simultaneous users

Application
Application run in isolation Other applicationsalso active
Node provisioning [1] 10 [2] 5
Line provisioning 30 30
Carrier provisioning 4 4
Trunk provisioning 5 2
LMM 10 2
TMM 10 2
[1] This includes add/delete/query operations for gateways.

[2] Maximum 5 users from the CS2K Management Tools GUI.
Note: System response time increases as the number of simultaneous users increases.

Chapter H4 Accounting
H4.1 Summary of Accounting Capabilities

Downstream processing of billing records by OSS
Up to 16 file feeds by FTP push

Unlimited file feeds by FTP pull
Each feed can be DNS or DIRP
Manual transfer requests via IEMS
100BaseT End-of-call QoS statistics
Ethernet SBA on SDM/CBM stores provided by GWCs to the
AMA records in files with QoS Collector Application
one of two formats: (QCA) can be co-ordinated
AMADNS (AMA and with billing records
SMDR records)
DIRP (AMA records
only)
CS2000 UAS 3rd-pty
USP SAM21 GWC Mgr. CICM PMDM 9000
Device Mgr. and 5200 must have
Mgr. Mgr. Mgr. Mgr. Mgr. Mgr.
(SDM or APS Mgr. compatible
CBM) 3rd-pty EM
AMA and SMDR records

(up to 1.2 million per hour)
transmitted in near real
time from SuperNode
Core performs Billing Application (SBA)
all billing using client on Core to SBA
info from other server on SDM/CBM
components
CS2000 components
CS2000
Core USP RTP
FLPP, used) used)
if used)
Figure 179: Overview of support for accounting in a CS2000 network

Communication Server Capabilities OAM&P Accounting
H4.2 CS2000 Core Support for Billing

H4.2.1 Call Recording Formats Supported
CS2000 supports billing by automatically generating call records to capture information
such as call start time, call duration and calling party number. These records are
periodically downloaded to the network operators administrative centre for processing.
They provide the operator with all the information necessary to bill subscribers for calls
made.
The call recording formats supported are:
! AMA (Automatic Message Accounting)
With AMA, call information is captured by means of standard-format base records,
extended with special-purpose modules to provide further information about the
facilities used by a given call. The AMA variant used in international markets is
Universal AMA, which uses a subset of the EBAF (Extended BellCore AMA
Format) record structures, modified to support open numbering plans. As its name
suggests, EBAF was originally defined in a BellCore TR (Technical Requirement)
for use in North American networks.
! SMDR : Station Message Detail Recording
SMDR complements standard billing by collecting extra call information to meet
customer requirements, e.g. for billing internal departments or determining basic
call and service usage patterns. It is intended for use in collecting data for Centrex
customers.
Note: SMDR is primarily used to collect information about service usage by
subscribers served by Centrex lines, but can also be used to collect information at a
customer group level.
Sections H4.2.2 and H4.2.3 respectively describe the AMA and SMDR billing systems
available for use in international markets. Section H4.2.4 on page 819 discusses the
creation and transfer of billing records. Section H4.2.5 on page 820 provides an overview
of how the generation of billing records is controlled via translations.

Accounting OAM&P Communication Server Capabilities
H4.2.2 Automatic Message Accounting (AMA)

CS2000 uses a flexible variant of Extended Bellcore AMA Format (EBAF) AMA records
for AMA billing. This variant, Universal AMA, uses a subset of the standard EBAF
structures, modified to support open numbering plans. AMA records are created at the
CS2000, then downloaded and processed externally to produce subscriber bills. The
following sections describe the structure of AMA records; section H4.2.4 describes the
transfer method used for downloading.
Note: This sections provides only an overview of Universal AMA structures and
modules. For a more detailed formal definition, see the AMA Reference Guide
(297-9051-800).
Dates and times in AMA records are based on the CS2000 Core TOD (Time Of Day)
clock.
H4.2.2.1 BellCore AMA Record Types and their Generation

This section discusses the main types of record that are typically generated by BellCore
AMA.
Records Generated as a Result of Call Handling

Generation of these records is triggered in the course of translating and routing a call (see
section H4.2.5 on page 820 for further information). This type of record must provide the
following information in order to allow the charges incurred for a call to be calculated:
! Originating subscriber number
! Terminating number or digits
! Time and date of origination
! Duration (conversation time) of call
Sections H4.2.2.2 to H4.2.2.6 describe the corresponding record and module structures.
Records Generated as a Result of Administrative Activity

These types of record are typically produced to inform the downstream processor of
events and measurements occurring on the CS2000 at the time the recording is taking
place. The following events will typically result in AMA record generation:
! Closing an active recording file
! Opening a new active recording file
Section H4.2.2.7 describes the corresponding record structures.

H4.2.2.2 AMA Base Record Structures Supported

CS2000 supports the generation of five different AMA record types for logging call
events. These are distinguished by the following factors:
! The maximum number of called party digits that can be stored, which can be 18 or
30 digits.
! Whether the record includes an additional field that indicates which of the following
types of call completion was encountered:
" Normal answer
" Call abandoned (clear down during ringing)
" Busy treatment
" Any other treatment
" Abnormal or unknown completion (any other reason)
! Whether the record includes carrier selection information.
For records without carrier selection information, the base record structure to be used on
a given CS2000 is determined by means of Software Optionality Control options, as
summarised in the following table.
SOC option BILL0009 (call completion reason)

Option IDLE Option ON
Base structure x0510 Base structure x0511
Option IDLE Maximum 18 digits Maximum 18 digits
SOC option RBIL0013 No call completion reason Call completion reason
(30 digit support) Base structure x0513 Base structure x0514
Option ON Maximum 30 digits Maximum 30 digits
No call completion reason Call completion reason
The x at the start of the base record structure code is either 0 for a self-contained base
structure record, or 4 if additional modules are appended to the base structure. 00510 and
40513 are examples of complete structure codes.
Carrier selection requires an x0512 base structure record to be used instead of the one of
the base structure records listed in the table above. This provides a number of additional
fields (Bellcore-defined) to contain carrier selection information. The ability to generate
an x0512 record is provided by setting the office parameter
PRESEL_DEACT_X0512_BILLING (in table OFCENG) to N. An x0512 record will
then be generated for every call on which carrier selection is active.

H4.2.2.3 Contents of AMA Base Record Structures

The following table lists the fields that may be included in an AMA base structure record.
Table 81: Fields in AMA Base Record Structure

Information Field no. Number of BCD characters [1]
Record Descriptor Word 000 8

Hexadecimal Identifier 00 2
Structure Code [2] 0 6
Call Type Code [3] 1 4
Sensor Type 2 4
Sensor Identification 3 8
Recording Office Type 4 4
Recording Office Identification 5 8
Date 6 6
Timing Indicator 7 6
Study Indicator 8 8
Called Party Off-Hook 9 2
Service Observed, Traffic Sampled 10 2
Operator Action 11 2
Service Feature [3] [4] 12 4
Significant Digits In Next Field 55 4
Originating Open Digits 1 [5] [6] 500 12
Originating Open Digits 2 [5] [6] 501 10
Originating Charge Information [3] 504 4
Domestic/International Indicator 505 2
Significant Digits In Next Field 55 4
Terminating Open Digits 1 [5] [7] [8] 12 (x0510, x0511, x0512)
502 16 (x0512, x0513, x0514)
[5] [7] [8] 10 (x0510, x0511, x0512)
Terminating Open Digits 2 503 16 (x0512, x0513, x0514)
Connect Time 18 8
Elapsed Time 19 10
Call completion reason [9] 280 4
Module Data [10] 88 4
Originating Preselect Carrier ID [11] 543 6
Outgoing Preselect Carrier ID [11] 543 6
Significant Digits in Next Field [11] 55 4
Overflow Dialled Digits [11] 33 14

Table 81: Fields in AMA Base Record Structure

Information Field no. Number of BCD characters [1]
Sent Service Digits [11] 803 6

Originating Serving Carrier ID [11] [12] 544 6
Terminating Serving Carrier ID [11] [12] 544 6
[1] To calculate the size of a field in bytes, divide the number of BCD characters by two, as two
BCD characters fit in one byte. The final character in each field is a # sign (hex C).
[2] The structure code identifies the type of base record structure being used. Digits 2-5 are 0510,
0511, 0512, 0513 or 0514, as appropriate. The first digit indicates whether modules are appended
to the base structure, as in the following examples for x0510:
00510 Base structure only, no modules appended
40510 Base structure plus appended modules
[3] Value obtained via translations. For an IN call that triggers at TDP-3 and re-enters translations
before onward routing, service datafill determines whether the value recorded in the billing
record is the value for the incoming call leg or the onward-routed call leg.
[4] This is the field used to mark a billing record as being for a call initiated via the NEED-based
BTUP Call Back When Free (CBWF) feature. This enables both the call charge and CBWF
usage to be recorded in a single AMA record. This functionality is activated via option
BT_CBWF_BILL in table AMAOPTS.
[5] These fields support billing for open numbering schemes (other Bellcore AMA structures use
fixed 10-digit numbers). The Originating Open Digits field contains the calling party number,
and the Terminating Open Digits field contains the called party number.
[6] If a full CLI has been received for an incoming indirect access call and an AMA record is
generated for that call, the full CLI is stored in the Originating Open Digits fields of the AMA
record. This is primarily intended for use in Inter-Administration Accounting (IAA).
[7] Structure codes X0510 and x0511 can store a maximum of 18 terminating digits. Structure codes
x0513 and x0514 can store a maximum of 30 terminating digits. In structure codes x0513 and
x0514, the fields are therefore referred to as Extended Terminating Open Digits.
[8] For an IN call, these fields (normally used to store translated called party number digits) are
filled with hexadecimal Fs (1111). These will eventually be overwritten with the final called
party number, as modified/provided by Connect.
[9] Structure codes x0511 and x0514 only.
[10]See section H4.2.2.4 for details of module types that can be appended to an AMA record.
[11]Structure code x0512 only. Field for carrier selection information.
[12]Field has no significance for CS2000 carrier selection, and is filled with zeroes.

H4.2.2.4 Modules Appended to Provide Further Information

In some cases, more information is required on a call type than can be provided via the
base structure. In this event, modules of data can be appended to the base record. Each
module is identified by a unique Module Code, with a Module Code of 000 terminating
the module code list appended onto the record. The following table describes the modules
that CS2000 may append to Universal Centrex AMA records.
Module Code Contents

For IN calls in the DTAG (Deutsche Telekom AG) network, this module records
the date and time of:
Receipt of the first FCI operation
008 Seizure of the outgoing circuit
Seizure of the incoming circuit
In order for these modules to be included, the AMAOPTS table entry
INAP_CAPT_FCIRECEIPT must be turned ON
Long duration call record information. Module appended to each intermediate
long call record to record the date and time of the audit, and appended to the
022 final long call record to record the date and time of disconnection (see section
H4.2.2.6).
The circuit release date and time for unanswered calls. Appended only to
025
records generated for unanswered calls.
Records call type code and dialled digits for VPN calls.
All digits in overlap calls are recorded for calls originating on ETSI ISUP, IBN7
026 ISUP, BTUP and ETSI PRI. For calls originating on other agents, only the
digits contained in the initial call setup message are recorded.
Availability of capability is controlled via SOC option BILL0004.
Appended to the base structure for an IN call if this has been specified by
028 [1] service data in table SERVINFO. The type 28 module can record up to 15
dialled digits.
030 Contains Basic Service (BS) information for ISDN calls.
Appended to the base structure for an IN call if this has been specified by
040 [1] service data in table SERVINFO. The type 40 module can record up to 24
dialled digits in its Dialled Digits 1 and Dialled Digits 2 fields.
042 A unique Call Record Sequence Number for the AMA record it is appended to.
Table 82: Modules that can be appended to AMA records


A generic module used for a variety of purposes. The purpose for which a given
module instance has been used is indicated by the source of charge value in
the module (this allows type 046 modules to be distinguished if more than one
is appended for a given call).
Uses currently supported by CS2000 are:
If option AMACLID is datafilled against an incoming or two-way IBN ISUP
trunk in table AMATKOPT then this module will be appended and will
contain the calling line ID (source of charge number = 1). Can be used to
046 support call billing to user-provided CLI for PRI calls.
If ENTRYID is datafilled against a DISA station in table DNROUTE or
against a VFG in table VIRTGRPS then this module will be appended and
will contain the point of entry for the network (source of charge number = 2).
To contain an NDS (Designated Subscriber Number) provided over FTUP
or SPIROU (source of charge number = 5). Requires USERCLI to be
specified in table AMATKOPT and SOC option RBIL0007.
To contain an unmodified incoming CLI if IC_CLI is specified in table
AMATKOPTS (source of charge number = 6).
The calling name/number delivery module, which is used to support Subscriber
049 Usage Sensitive Pricing (SUSP) for the CLASS display features CND/DDN
and CNAMD (see section H4.2.2.5 on page 816).
The ISDN Core Module, which records the requested bearer capability,
interworking indication, supplementary service usage and release cause.
To enable production of module 070, ISDNCIRCUIT must be set to ON in table
070 AMAOPTS. Depending on trunk type, other SOC codes and AMA options may
be applicable, i.e. SOC code NETK0005 for ETSI ISUP and option
APPEND_PRI_MODULE in table AMAOPTS.
The abbreviated ISDN Core Module, which records the requested bearer
capability, interworking indication and release cause for ISDN calls if there is
no supplementary service information.
To enable production of module 070, ISDNCIRCUIT must be set to ON in table
AMAOPTS. Depending on trunk type, other SOC codes and AMA options may
071
be applicable, i.e. SOC code NETK0005 for ETSI ISUP and option
APPEND_PRI_MODULE in table AMAOPTS.
Primarily used to support Bearer Capability billing.
Can be used to support bearer capability billing for calls routed through a VFG,
even if billing is triggered after routing through the VFG.
The terminating user service module, which serves two purposes:
073 To record information equivalent to module 070 for call terminations.
To record the carrier used for a call.
Used to capture carrier connect time and thus permit more accurate billing of
098 interconnect calls. Carrier connect time is based on circuit seizure (sending or
receipt of IAM) rather than call completion (ACM/ANM).
The Business Group Feature Module is appended to the AMA records when
the MDRRAO feature is active for the customer group and SMDR is turned on
100 in translations.Used in conjunction with AMA, this module is intended to
replace SMDR as a means of call recording. It is mutually exclusive with SMDR
on a per customer group basis.
Contains authorisation code entered by subscriber.
102
Controlled by option AUTHAMA in table CUSTSMDR.


Records a customer-dialled account number with up to 14 digits for use in
CDAR (Customer-Dialled Account Recording). Activated by AMAOPTS option
103
CDAR. Numbers with 15-18 digits must be stored in a type 850 module (see
A59034042).
Contains information about a trunk circuit used in a chargeable call. Identifies
the Trunk Group Number in addition to the Trunk Member Number for either
104
the originating trunk, terminating trunk or both. Controlled by option TRKINFO
in table AMATKOPT.
Contains information required to calculate the time taken to answer a call. (Line
115 terminations only.) Controlled by option AMATTA in table CUSTSMDR and by
SOC BILL0007.
Contains original dialled digits for redirected calls.
For calls that are redirected before being answered, this module enables the
116
capture of redirection reason and redirection number. Controlled by option
AMREDIR in CUSTSMDR and by SOC BILL0008.
120 Module contains the number that has been datafilled in field GROUPID of table
CUSTENG for the originating customer group.
Module used for rejected or failed calls, to record whichever of the following is
appropriate:
Information about the treatment applied, including treatment origin and
treatment application.
ITU release reason (available only if no non-CCS7 trunks have been
130
involved in call setup).
Produced only in conjunction with module 025 (unanswered call), because a
rejected or failed call is by definition unanswered.
Capability controlled via SOC option BILL0003 and the Flexible AMA option
FLEXRJCT. Also controlled by option AMREDIR in table AMAOPTS.
The E.164 / X.121 number module, which records:
Type of number
164 Country
Digits
Module contains the ISDN channel identifier for ISDN call orginations
180 terminating on ISDN. Capability activated by setting option
APPEND_ISDN_CKT_ID to ON in table AMAOPTS.
181 Module contains the incoming trunk identifier for trunk calls terminated to PRI,.
Activated by AMAOPTS option APPEND_ISDN_CKT_ID (as for 180).
Appended to the base structure for an IN call when this is requested by a
FurnishChargingInformation operation from the SCP. This module type
199
contains any required operator-defined data coded as BCD digits (up to 20
bytes / 40 digits).
306 Module contains a three digit Originating Line Information parameter (OLIP).
Module holds details of any time changes (initiated by SETDATE or SETTIME)
504
that have taken place during a call.
SUSP billing module, which records the feature codes of the features last
509 activated by the call originator and terminator. It is appended to a call when
FTRCODE in table AMAOPTS is set to ON.


Contains the following information about a trunk circuit used in a chargeable
call:
Trunk CLLI Name in EBCDIC format (32 digits for 16 characters).
513 Trunk Facility ID containing trunk direction (IC/OG), trunk group and trunk
member numbers.
Produced instead of module 104 if CLLI_FOR_TRKINFO is ON in table
AMAOPTS and if option TRKINFO is ON in table AMATKOPT.
Module Codes 611 and 612 are defined as Generic Context modules for
recording network- or operator-specific information. Their format is similar, but
MC611 can contain 15 digits while MC612 can contain 30 digits. The content
of a particular instance of a 611/612 module is indicated by the context
identifier in the module.
CS2000 supports the following uses for type 611 modules:
Type 611 module with context identifier 80005
Additional Billing Information, including:
- Payphone indicator
- Mobile phone indicator
- Personal HandyPhone indicator
- ISDN indicator
- Charge indicator
- Bearer capability
- National / international call indicator
Carrier Information
Additional Partys Category
User-to-User Information (UUI) Parms
611 Independent Common Carrier Proprietary Data Group
IN Service Information
Charge Area Information
To record Facility IE counts (in forward and backward directions) for QSIG
GFT billing.
CLI screening information for screening based on table CLISERV.
To capture protocol indicator, Calling Party Category and ISDN Access
Indicator information.
To indicate what type of number portability rerouting has taken place on a
call:
- Routing using the NIC and the NICRF option
- PNRF Onward Routing using the PNRF option
- LNP QOR Routing
See A59013186 and A59027497 (QoR).
Network-specific call reference for use in correlating billing records for a
call. Activated by STORE_CALLREF option of AMAOPTS. See
A59023264.


To capture a protocol indicator, number indicator, and pre-translations NPI
and NOA/TON for a call on which the NPI and NOA/TON may have been
changed in translations. See 59014037 for details. A type 611 module used
for this purpose also captures the PI (Presentation Indicator) setting of the
number, as described in A59022630. Enhanced to support NPI and
NOA/TON capture for R2 CAS (inc. FDCP), RB-TUP, Brazil TUP and
Japan PRI (INS1500), as described in A59034042.
- The most recent service code associated with a call via
universal screening tables encountered duringtranslations.
- CLI delivery indicator
See A59034042.
To capture an IN billing record correlation ID. Service datafill can be used
to ensure that the same correlation ID is used for all the billing records
associated with a given IN call, allowing related records to be identified
easily. See AG5524 for details.
To capture information for use in Subscriber Usage-Sensitive Pricing
(SUSP), as described in section H4.2.2.5 on page 816.
To capture a national/international call indicator for calls incoming over
NCCI ISUP and IBN7 trunks. See AU3511 for details.
611 Type 611 module with context identifier 80080
To capture a Carrier Identification Code (CIC) for a Carrier Pre-Selection
(continued) (CPS) call if this is specified via option PCIBILL in tables PCIXLA and
PCITRK. See 59012694 for details.
Indicates that a call has gone through network translation. Appended for an
NTAI call if NTAI is specified in table AMAOPTS. CS2000 role in call
(setting/transit/terminating) will also be recorded. See A59022245.
To capture any or all of the following information for a call:
- Completion code (release code / treatment / disconnect)
- COS index of originating trunk
- Satellite Indicator value
Functionality triggered by AMAOPTS options CAPTURE_COMPL_CODE,
CAPTURE_CLASS_SERV and CAPTURE_SAT_IND. See A59027758.
To capture either or both of the following parameters for a call, for use in
IAA:
- FCI (Forward Call Indicators)
- BCI (Backward Call Indicators)
Functionality triggered by AMAOPTS option CALL_IND. See A59027776.
Used for a number of purposes for IN calls in the DTAG network:
- To record a Disconnecting Party Indicator and Charge Band Number
(CHBN)
- To record ISUP information (Transmission Medium Requirement,
Service Type, and Cause Indicator)


Module Codes 611 and 612 are defined as Generic Context modules for
recording network- or operator-specific information. Their format is similar, but
MC611 can contain 15 digits while MC612 can contain 30 digits (which equires
SOC option BILL0013 (30 digit support) to be active). The content of a
particular instance of a 611/612 module is indicated by the context identifier in
the module.
CS2000 supports the following uses for type 612 modules:
Independent Common Carrier Proprietary Data Group
Charge Rate Information
For a VPN call (context identifier 80011), a type 612 module is equivalent
to a type 026 module. Functionality activated via SOC option BILL0004;
option BILL0013 determines which module is used. Capability available for
PRI calls as described in AJ5089, and for QSIG calls as described in
59012767.
For an IN call (context identifier 80011), a type 612 module is equivalent to
a type 028 or 040 module [1]. Service data in SERVINFO determines which
module is used. See AJ4957.
A type 612 module with context identifier 80015 can be used to capture an
additional billing number if one is available. Additional number types
currently supported:
- Presentation Number (PN), as described in A59022608.
- Original Called Number for use in IAA (see A59027776).
- Redirection Number for use in IAA (see A59027776).
- Singapore LNP routing number (see A59034058).
612 - JI-ISUP Redirection Number (see A59034042).
Charge Rate Information
Carrier Information with POI Category
Dialled digits received from incoming agent
For a screened indirect access call for which table CLICNTL specifies that
a number other than the CLI should be used for billing, the alternative
number can be captured in a type 612 module. See A59023556.
To capture a QoS (Quality of Service) correlation ID. If GWC collection of
end-of-call QoS statistics is enabled, such a correlation ID can be used to
associate the AMA billing record for a call with the QoS data record
provided by the GWC to the QCA (QoS Collector Application). See
A89007781 for details.
For a call on which the called party number is changed during translations
and routing, this can capture the untranslated number (see 59014037).
Enhanced to support untranslated dialled digits capture for R2 CAS (inc.
FDCP), RB-TUP, Brazil TUP and Japan PRI (INS1500), as described in
A59034042.
Type 612 modules are used in Turkey to record call information specific to
that market, e.g. metering pulse counts. The information is stored in two
generic digit strings, each comprising 15 BCD digits. See 59013592 (CAMA
functionality) and A59011950 (metering information).


Records a customer-dialled account number with up to 18 digits for use in
CDAR (Customer-Dialled Account Recording). Activated by AMAOPTS option
850
CDAR_EXTENDED. Numbers with up to 14 digits can alternatively be stored
in a type 103 module.

[1] Any of three module types may be used to record the digits dialled by an IN caller: a type 28
module (up to 15 digits), a type 40 module (up to 24 digits), or a type 612 module (up to 30 digits).
The choice is specified by service data in table SERVINFO. There are two scenarios:
In the case of en-bloc signalling, or of overlap signalling where the number of digits to be
collected is not specified by the SCP, the digits recorded are the dialled digits available when the
call triggered as an IN call, i.e. the same digits conveyed in the InitialDP calledPartyNumber
parameter. These are untranslated digits for triggering at TDP-2 or translated digits for
triggering at TDP-3.
In the case of overlap signalling where the SCP uses RRBE to specify the number of digits to be
collected, the digits recorded are those provided to the SCP in the ERB sent when EDP-2
(Collected_Info) is encountered after CollectInformation. These consist of the digits available
when the call triggered together with any overlap digits received between triggering and EDP-2
detection. Overlap digits received since triggering are always untranslated, while the digits
available when the call triggered may be either translated digits (if triggering originally took
place at TDP-3) or untranslated digits (if triggering originally took place at TDP-2).

H4.2.2.5 Subscriber Usage-Sensitive Pricing (SUSP) for Feature Usage

SUSP can be used for the features listed in the table below.
Feature Billing summary

Call Module
Acronym Name Structure code appended Description
CFUx Call Forward Universal Structure 614 is generated for

CFFx Call Forward Fixed the activation of these features.
Structure code 096 is generated
Call Forward on for the deactivation of these
CFDx 614,
Doesnt Answer 031 611 features.
096
Module code 611 is appended
to these structure codes to
CFBx Call Forward on Busy indicate exactly which feature is
being billed.
Station Controlled Module code 509 is appended

CNF 510 006 509 to the 510 structure code to
Conference indicate use of the CNF feature
CXR Call Transfer Structure code 076 with call
code 026 will be generated
whenever a three port
510, 006, conference circuit is accessed.
076 026 None Both CXR and 3WC require a
3WC Three Way Calling
three port conference circuit
whenever they are invoked by
the subscriber.
Subscriber Activated
SACB Structure code 510 with call
Call Blocking
code 006 will have the module
WUCR Wake Up Service 510 006 611 code 611 appended whenever
these features are activated or
Station Activated Do
MSB deactivated
Not Disturb
Calling Number Structure code 110 with call
CND
Delivery code 264 is generated during
AMA audits or when either
feature is removed from the
110 264 49 line.
CNAMD Calling Name Delivery Module code 49 is appended
when both CND and CNAMD
are active on the same line.
Calling Number Structure code 1030 with call
CNDB
Delivery Blocking code 330 is generated when
these features are used [1]
ACB Automatic Callback 1030 330 None
Module code 611 is appended
for calls initated by AR (see
AR Automatic Recall
A59039985).
Selective Call
SCF
Forwarding
Structure code 1030 with call
Selective Call code 330 is generated when the
SCA 1030 330 None
Acceptance screening lists for these
features are modified [1]
Selective Call
SCRJ Rejection
[1] Code 1030 records contain 10-digit originating/terminating numbers. In networks using
fixed-length numbers with fewer than 10 digits, numbers are padded by default with the
DN_PADDING_DIGIT. Alternatively, REPLACE_PADDING_DIGIT can be used to specify that
Nil, B, C, D, E or F should be used for padding instead. See A59017328. AR numbers with more
than 10 digits are truncated, as explained in A59039985.

Note: SUSP uses North American structure codes, and can therefore be used only on
switches that can support North American structure codes.
Module code 611 is appended to the base AMA record for a call as a result of pay-per-use
billing. This allows the billing record for a call attempt initiated by a feature to be
co-ordinated with the feature usage record generated on feature activation.
A type 611 module is a generic module with a one-digit string format. For SUSP, this
module contains a generic context identifier and a digit string:
! The generic context identifier assigned by Bellcore for subscriber usage recording
is 80024.
! The digit string is used to indicate which feature was accessed. For example, a digit
string of 8386A4000000040C indicates that the CFU (Call Forward Universal)
feature was accessed.
" The first twelve characters serve as the service identifier, which represents the
feature acronym in EBCDIC format. In this case 83 = c, 86 = f, A4 =
u, and the remaining six characters of the first twelve are represented with
zeros, since there are only three letters in the feature acronym.
" The next two characters, 04, represent the service event. In this case 04
maps to subscriber programming.
" The last two characters of the digit string are 0C. 0 is an unused character
and C is the SIGN indicating the end of the digit string.

H4.2.2.6 AMA Records for Long Calls

Long calls result in the generation of more than one AMA record.
Support for the long call audit process is controlled by AMAOPTS option LONGCALL.
The office parameter AMA_LONG_DUR_AUDIT_INTERVAL specifies the threshold
value that determines whether a call is regarded as a long call. The value is an integer in
the range 1-24, and denotes a number of whole hours. If the value is set to 1, for example,
any AMA-billed call that lasts more than one hour will be treated as a long call.
The long call audit process runs at regular intervals to check whether there are long calls
in progress. (The audit interval typically corresponds to the long call threshold value.) The
audit process also generates a partial billing record for each active long call. Three types
of partial billing record may be generated, as follows:
! A first part bill record is generated for a call on the first occasion when the audit
process finds it to be still in progress with a call duration greater than the threshold
value. With a 1-hour threshold value, for example, a part bill record would be
generated for a call with a duration of 1:01, but no action would be taken for a call
with a duration of 0:59. The first part bill record for a long call record has no
modules appended.
! An intermediate record is generated on each subsequent occasion when the audit
process finds that an already-identified long call is still active. Each intermediate
record has an AMA type 022 module appended to it giving the date and time of the
audit.
! A completion of long call record is generated when the call is finally released. This
final record has an AMA type 022 module appended to it giving the date and time
of call disconnect.
Note: It is important to distinguish between long calls, on which both agents are still
active, and hung calls, on which one of the trunk agents involved has remained connected
after call clearing because of some technical problem. The CCBHNG maintenance tool
runs at predefined intervals to check for hung calls and to provide notification of them so
that appopriate action can be taken.
H4.2.2.7 Miscellaneous Record Structures

The following section describes the additional record structures used in AMA to reflect
non-call-related event information.
! Structure Code 09000: Time Change Entry
When a SETTIME or SETDATE is performed on the switch, and the
TIMECHANGE tuple of table AMAOPTS is ON, a Time Change Record is
produced to record the date and time before and after the change.
Note: The recommended alternative to the use of 09000 records is to append a type
504 module to the AMA record of every call that is active when a SETDATE or
SETTIME command is executed. This requested by setting the CALL_TIMECHG
option in table AMAOPTS to ON.
! Structure Code 09013: Transfer In
Placed at the start of each new AMA call recording file in DIRP format.
! Structure Code 09014: Transfer Out
Placed at the end of an AMA file in DIRP format just before closing it. Includes
record and clock counts for the file.
! Structure Code 09049: Hourly Tracer Record

H4.2.3 Station Message Detail Recording (SMDR)

In a VPN context, customers may wish to collect additional information about calls as
well as the information required for billing, e.g. to build up a profile of calls made and
received per customer group. The SMDR system can record details of billable and
non-billable calls for each call leg. The SMDR system uses the AMA subsystem to collect
the call data and record it on a data storage device for subsequent downloading.
Note: SMDR is primarily used to collect information about service usage by subscribers
served by Centrex lines, but can also be used to collect information at customer group
level.
SMDR records provide information such as the following:
CLLI or customer group
Calling number or special billing number
Called number
Operator console number (if applicable)
DISA number (if applicable)
Authorisation code
Account code
Feature code
Connect time
Time and date of call
SMDR capabilities are provided as part of the Centrex Standard software identified by
option code MDC00003 in the CCM DRU. Specific SMDR features include:
! F0245 Station Message Detail Recording (SMDR)
! F2368 Separate Output Files for SMDR and AMA
! F2399 Separate SMDR Files per Customer Group
! G0119 SMDR Data in AMA Stream
H4.2.4 Creation and Transfer of Billing Records by the Core

All CS2000 billing records are created by the AMA subsystem on the CS2000 Core.
AMA (and optionally SMDR) records are created in response to notification of call
processing events (see section H4.2.5 on page 820 for further information). The
SuperNode Billing Application (SBA) client on the CS2000 Core immediately transmits
newly created billing records to the SBA server running on the Core Manager platform
(CBM or SDM). In normal operation, up to 1.2 million records per hour can be transmitted
in near real time to the Core Manager SBA, where they are stored in files for subsequent
transfer to a downstream billing system, as described in section H4.3 on page 823.
Possible operating modes for SBA on the CS2000 Core:
! Normal mode
Records are generated on the CS2000 Core and transmitted immediately to the Core
Manager.
! Backup mode
If the CS2000 Core and Billing Manager becomes unavailable, the SBA on the Core
goes into backup mode and writes billing files to backup volumes on the Core itself.
! Recovery
When the CS2000 Core Manager becomes available again, the SBA on the Core
goes into recovery mode and sends all backup files from the Core to the Core
Manager.

H4.2.5 Controlling the Generation of Billing Records

The creation of an AMA record for a call is triggered during translations. Translation and
call processing events also cause subsequent updates such as changes to base structure
record fields and the appending of additional modules. This section provides an overview
of the main mechanisms that can be used to trigger and control billing record generation.
Note: This section provides only an overview of the options available. For a more
detailed formal definition, see the AMA Reference Guide (297-9051-800).
The simplest and most common method of triggering AMA record generation is to specify
a translation class as an option in an xxCODE table entry (see section C3.5.3 on page 210
for information about Universal Translations and xxCODE tables). Specifying CLASS
NATL, for example, indicates that a call is a national call and will cause an AMA record
to be created for it. The AMA record generated will contain appropriate values for all the
fields in the base structure record, including originating and terminating numbers and call
duration (see Table 81 on page 807 for a detailed description of base structure records).
Note: By default, AMA records are generated only for successfully completed calls.
Additional action needs to be taken to generate AMA records for calls that are not
answered or routed to treatment.
For many operators, the AMA base structure record will provide all the information they
need to bill most calls. The AMA subsystem is extremely powerful and flexible, however,
and can be used to collect additional information for all calls or for selected call types.
Such additional information can be used for other purposes as well as billing, e.g. for
detailed analysis of the mix of call types that a given CS2000 is actually supporting.
The following tables allow additional billing options to be controlled at various levels:
! The AMAOPTS table controls AMA record generation for the CS2000 as a whole.
Examples of call events for which record generation can be specified are:
" The UNANS_TOLL option causes AMA records to be generated for
unanswered calls.
" The CAPTURE_INAP_CPC option causes the appending of a type 611
module with context ID 80027 containing the INAP Calling Party Category.
" The CLLI_FOR_TRK_INFO option causes a type 513 module containing the
trunk CLLI used for a call to be appended to the AMA record.
! The CUSTSMDR table controls AMA record generation on a customer group basis.
Examples of options that can be specified at this level are:
" The AMAREQD option causes AMA records to be generated for all calls
from a customer group even if normal AMA trgigering does not take place.
" The AMATTA option causes the time taken to answer a call to be recorded in
a type 115 module appended to the AMA record of the line terminating
portion of the call.
! The AMATKTOPT table controls AMA record generation on a trunk group basis.
Examples of information that can be collected in AMA records for options specified
at this level are:
" Append type 046 module containing incoming CLI.
" Append type 612 module with context ID 80015.
The AMA module descriptions in section H4.2.2.4 on page 809 include information about
the datafill that causes them to be appended.

H4.2.6 Metering / Advice Of Charge (AOC)
H4.2.6.1 Software Metering

Software metering is a mechanism for recording the accumulating charges incurred for a
call in a software register associated with the originating agent. Charges are recorded as a
count of charge units used. The rate at which charge units are used for a given call varies
depending on the tariff in effect, which is determined by factors such as the distance, the
time of day, and any applicable subscriber discounts.
The software metering mechanism can provide information about call charges over the
originating interface. Some regulators and standards bodies have formally defined charge
notification services. One example is the ISDN supplementary service AOC (Advice Of
Charge) defined by ETSI for ISDN call originations.
Metering functionality is activated by setting office parameter ENABLE_METERING to
Y. If a given CS2000 is not required to provide metering support as part of its network
role, metering functionality can be disabled by setting ENABLE_METERING to N. This
improves real-time performance of the switch.
H4.2.6.2 Control of Metering for Trunk Interfaces

CS2000 supports software metering for ISUP and PRI trunks. Metering is activated on a
trunk group basis by means of the MOG (Metering Origination Group) capability, which
is assigned by specifying the ICMOG or OGMOG option in table TRKOPTS (ICMOG
for incoming trunks, OGMOG for outgoing trunks, either or both for two-way trunks). On
a given CS2000, software meters can be enabled for up to 8192 trunk groups.
A given trunk can be assigned up to four meters for recording charge units used, one each
for local, rural, national and international calls. Fewer than four meters need to be
assigned if two or more call types share a given meter, e.g. all call types could share a
single meter.
H4.2.6.3 Nodal AOC

The nodal ISDN AOC supplementary service uses World Metering functionality. CS2000
supports two variants of this service, which provides call charge information for PRI call
originations:
! For Advice Of Charge at End of Call (AOC-E), CS2000 includes a Facility IE with
charging information in the RELEASE message sent to the user during call clearing.
! For Advice Of Charge During Call (AOC-D), CS2000 sends one or more
FACILITY messages at 5-second intervals while the call is active, each containing
a Facility IE with charging information. A final Facility IE is also included in the
RELEASE message sent to the user during call clearing.
World Metering functionality is used to determine the charges that have been incurred,
and thus the content of the Facility IE(s) sent back to the calling user. The charge
notification mechanism is not affected.

H4.2.7 Order Codes for Accounting Support

Table 83: Order codes for CS2000 accounting support
BILL0001 Billing
BILL0002 Carrier Connect AMA
BILL0003 AMA Reject Calls
BILL0004 VPN AMA Billing
BILL0006 SMDR DE Extension
BILL0007 AMA Time to Answer
BILL0008 AMA Redirection Information
BILL0009 AMA Call Completion Reason
BILL0010 AMA Generation Management Reports
BILL0012 Bearer Capability Billing for BTUP
BILL0013 AMA Support for Numbers with up to 30 Digits
IBIL0002 Australasia Billing Enhancements
IBIL0003 VPN AMA Enhancements
IBIL0004 NOA/NPI Capture in AMA
IBIL0005 SSUTR2 IC Charge Message Billing
IBIL0006 CPC AMA
OAMI0006 Long Call Audit
RBIL0005 Usage Sensitive Billing
RBIL0007 NDS Billing - Indirect Subscribers
RBIL0008 NDS Billing - Direct Subscribers
NSUP0006 BC Billing for ETSI ISUP
SMET0002 Software Metering

H4.3 Core Manager SBA Support for Billing

H4.3.1 Overview
All AMA records generated by the CS2000 Core are transmitted immediately to the Core
Managers SuperNode Billing Application (SBA) to be formatted and stored, which
means that it is not necessary for these tasks to be performed on the CS2000. The files
created by the Core Manager SBA for the storage of billing records can have either of two
formats:
! AMA Data Networking System (AMADNS) file format, which can be used to store
both AMA and SMDR records.
! Device-Independent Recording Package (DIRP) format, which can be used to store
only AMA records; this is the same format used by DMS switches for AMA records
sent to an on-switch IOM or IOC port.
The basic billing architecture is illustrated in Figure 180 and discussed in more detail in
the remainder of this section.
Transfer of billing files for downstream

processing:
AMA and SMDR records Up to 16 file feeds by FTP push
(up to 1.2 million per hour) Unlimited file feeds by FTP pull
transmitted in near real Each feed can be DNS or DIRP
time from SuperNode Manual transfer requests via IEMS
Billing Application (SBA)
client on Core to SBA
server on SDM/CBM
SBA client SBA server 100BaseT
Ethernet
CS2000 Core Core Manager

(CBM or SDM)
DNS files
SBA on SDM/CBM stores available 5
AMA subsystem on CS2000 Core AMA records in files with one mins after call
performs all billing using info from of two formats: completion
other components, creating AMA AMADNS (AMA and DIRP files
and SMDR records in response to SMDR records) available 30
notification of call processing events DIRP (AMA records only) seconds after
call completion
Figure 180: Creation, storage and transfer of billing records
The multiple file feeds presented for downstream processing need not be identical. The
SBA can filter the records presented to it on the basis of the value of any valid field in an
AMA record (and can use wildcards to filter on the basis of partial field values). This
filtering capability makes it easy to separate billing records into different streams for
different purposes, e.g. it is possible to filter the incoming stream of records and output
answered call records to one mediation system and unanswered call records to another.
Further filtering can be performed using the SBA AMADUMP tool described in section
H4.3.5 on page 825.

H4.3.2 Closing Billing Files Ready for Transfer

While an AMA file is open and records are being stored, it has a status of active. When
the AMA file reaches a certain limit in terms of number of records, file size or age (see
below), the file is closed and its status changed to primary. No further AMA records can
be stored in a closed primary file. When a primary AMA file has been downloaded from
the SDM to a remote destination, its status is changed to secondary. Once an AMA file
has been marked as secondary, the Core Manager may delete it to make room for newer
AMA files.
The file closure limits are controlled by the network operator via the MIB (Management
Information Base) of the Core Manager. AMA files may also be explicitly closed via the
RMI (Remote Maintenance Interface) to allow clients immediate access to AMA records.
Current clients include AMADUMP, the Data Processing and Management System
(DPMS) Agent and DAT backup, which are described in section H4.3.3.
Billing files created by the Core Manager SBA are closed and available for transfer when
one of the following criteria is satisfied :
! The maximum file size in bytes is reached:
" From 1 to 20 Mbytes (default 20 Mbytes) for AMA records using EBAF
(Extended BellCore AMA Format) record structures
" From 100 Kbytes to 20 Mbytes (default 20 Mbytes) for SMDR records
! The maximum file size in records is reached:
" From 10,000 to 500,000 records (default 500,000) for EBAF
" From 1000 to 500,000 records (default 500,000) for SMDR
! The file close time is reached
A file close timer is started when a new billing file is opened, and the file is closed
if that timer expires, even if the billing file has not reached its maximum file size in
bytes or in records (hex As are appended for padding). The default timer value is
120 minutes, but alternative values can be specified subject to minimum timer
values of 5 minutes for DNS format files and 30 seconds for DIRP format files.
H4.3.3 File Transfer Options

The following options are available for the transfer of billing files for downstream
processing:
! Up to 16 file feeds can be supported by FTP push
! Unlimited file feeds can be supported by FTP pull
! A given file feed can be either DNS or DIRP
! Manual transfer requests via IEMS SendFile command
H4.3.3.1 Downloading AMADNS AMA Files

The SBA enables primary AMADNS AMA files on the SDM to be downloaded from the
SDM via either FTP (using the DPMS agent) or DAT backup. In the event of transmission
failure, alarms and logs are generated.
! DPMS agent transfer
The DPMS Agent can be used to transfer AMA primary files from the SDM to the

DPMS using FTP. The transfer can be initiated from the RMI or can be scheduled
to occur periodically. If the transfer is successful, the status of the AMA files is
changed to secondary. If the transfer fails, the fact is logged and the transfer is
reattempted up to a given definable number of attempts. If the reattempt limit is
exceeded, an alarm is set.
! DAT backup
If the teleprocessing system (DPMS Agent) fails and disk utilisation becomes high,
resulting in alarms being raised, the operating company can back up the primary
AMA files to DAT tapes, allowing them to be deleted from SDM so that disk space
can be recovered. The DAT backup must be manually initiated from the RMI. When
the backup completes successfully, the status of the AMA files is changed to
secondary.
! Alarms and logs
SDM Billing Alarms are sent to the CS2000 and can be displayed from the SDM
Billing MAP CI level. SDM Billing Logs can either be sent to the CS2000 log
buffer system and then output, or be sent directly to the SDM Log Delivery system,
depending on a user-defined parameter.
In the event of an SDM outage, the AMADNS application redirects AMA records to
temporary files on the CM and retransmits them automatically when the SDM recovers.
H4.3.3.2 Downloading DIRP AMA Files

AMA records in DIRP format can be downloaded from the SDM to a downstream billing
device using FTP over TCP/IP (note that this is not supported for AMADNS AMA files).
H4.3.4 File Transfer Performance

For billing files in DNS format, billing records are available for downstream processing
in near real time. Under normal operating conditions, near real time billing is presentation
of AMA records at the SDM within five minutes of call completion.
For billing files in DIRP format, billing records can be available for downstream
processing in real time if the real-time billing application is used in conjunction with the
SBA. Real time billing is presentation of AMA records at the SDM within an average of
30 seconds after call completion.
H4.3.5 AMA Search via AMADUMP

The SBA allows closed AMADNS AMA files on the SDM to be searched for specific
AMA records using the AMADUMP tool. The search criteria can include filename and
record age. AMADUMP can access primary and secondary AMA files, but not active files
(these must first be closed and made primary using RMI commands). It can display all
records, or can apply a user-defined filter.
The AMADUMP tool allows multiple users to access the tool simultaneously, and
multiple access to the same file.

Chapter H5 Performance Management
H5.1 Summary of Performance Monitoring Capabilities
OMs in OMs in Aggregated Consolidated

XML PMs in CSV feed in CSV
CSV TR740/
format TR746 format via FTP or XML
QoS PMs in
via FTP format Collector CSV
Application format
AMA (QCA) SNMP,
via TCP IEMS via FTP
HTML
or XML
PMs in Collector
PMs in PM Poller running on
SSV running on PMs in BDF
PMs CSV format same server
format CMT server as Mgr
in .txt via FTP format via FTP
format
CS2000 3rd-pty
Device USP GWC SAM21 PMDM 9000
Mgr. Mgr. 5200 must have
Mgr. (SDM or Mgr. Mgr. Mgr. Mgr. compatible
CBM) 3rd-pty EM
SNMP (PMs on
OMs (ASCII/TCP)
SNMP demand to EM)

AMA records
SNMP
PMs (ASCII
on demand
(OMs at
at intervals
SNMP
via TCP)
intervals PMs in (OMs at

SNMP
SSV SNMP (PMs at intervals (PMs

and on intervals to poller) only on
demand) format and on
via FTP demand) demand)
CS2000
Core USP RTP
routers (also (if GWCs MS PVGs
FLPP, used) 20x0 used)
if used)
CS2000 components
Media gateways provide end-of-call QoS data to GWCs via

device/media control protocol (H.248, ASPEN, MGCP, NCS)
Figure 181: Overview of support for performance monitoring in a CS2000 network

Performance Management OAM&P Communication Server Capabilities
H5.1.1 Providing Performance Monitoring Information

Network operators need to be able to monitor and maintain the performance of nodes in
their networks. To support such monitoring, each network node collects performance data
in one or more of the following forms:
! Operational Measurements (OMs)
OMs are standard measurements originally defined by Bellcore for the collection of
performance data in circuit-based telephony networks, many of which are also
applicable for packet networks supporting VoIP or VoATM.
! Performance Measurements (PMs)
PMs are used to collect performance data for packet network nodes, and the set of
PMs collected for a given type of node tends to be node-specific.
! QoS (Quality of Service) data
These are statistics that allow voice quality to be measured for VoIP calls.
CS2000 networks use OMs and PMs as follows:
OMs, PMs and QoS data are provided to the network operators Operations Support
Systems (OSS) via EMs or some other intermediary.
Note: Some network operators also use selected billing records in performance
monitoring, as these make it possible to track specific types of call.
Operational Measurements (OMs)

Performance monitoring via OMs (see section H5.2 on page 830) is supported for the
CS2000 Core and the FLPP, if used. It may be complemented by the use of selected AMA
records to monitor performance.
! OMs are collected by the CS2000 Core and provided to the CS2000 Core Manager
running on the SDM using ASCII over TCP. The Core Manager provides OMs to
the Network Management Layer (NML) in two formats:
" Standard subsets of OMs are sent at predefined intervals using the standard
Bellcore-defined TR740 and TR746 interfaces (see section H5.2.1 on page
830).
" OMs are assembled into files in CSV (Comma-Separated Value) format and
transferred via FTP.
! Billing records to be used in performance monitoring are presented to the NML
using ASCII over TCP. See Chapter H4: Accounting for information about
supported billing record formats.

Communication Server Capabilities OAM&P Performance Management
Performance Measurements (PMs)

For performance monitoring via PMs (see section H5.3 on page 835), the table below
summarises the way in which CS2000 network elements other than the CS2000 collect
PMs for presentation to the NML.
Reporting mechanism
Network element
From element to To present
Intermediary
intermediary information to NML
GWC SNMP
PM Poller running on same
Aggregated PMs in
SAM21 SNMP server as GWC EM, SAM21
CSV format via FTP
EM, UAS EM and APS
UAS SNMP
CICM SNMP
Direct to IEMS
MS20x0 SNMP Consolidated feed
Via PP8600 Device from IEMS
PP8600 SNMP in CSV or XML
Manager to IEMS
RTP media portal SNMP Via MCS Manager to IEMS
PMs in SSV format PMs in SSV format
USP via FTP USP EM via FTP
PMs in BDF format
PVG ASCII over TCP PMDM
via FTP
Stand-alone Performance
PMs in CSV format Collector / Formatter PMs in CSV format
MG9000
via FTP application running on same via FTP
server as MG9000 Manager
Third-party SNMP Poller task, Typically SNMP,
gateways e.g. on EM HTML or XML
QoS (Quality of Service) Data

For QoS monitoring (see section H5.4 on page 836), media gateways controlled via
H.248, ASPEN, MGCP or NCS collect the following statistics for use in measuring voice
quality for VoIP calls:
! Packets sent
! Packets received
! Packet loss
! Octets sent
! Octets received
! Inter-arrival latency
! Jitter
Each gateway provides end-of-call QoS statistics to its GWC using the same
device/media control protocol used in setting up and clearing calls. The GWC passes them
on to a device hosting a QoS Collector Application (QCA), which is turn relays them to
a customer OSS for analysis.
Each QoS report contains a Correlation ID (CID) that can be used to correlate it with the
billing record for the call.

H5.1.2 Integrated Handling of Performance Monitoring Information

With effect from ISN07, Nortel provides the Integrated Element Management System
(IEMS) to consolidate performance data from the following NEs into a single integrated
northbound feed in either CSV or XML format:
! PP8600
! Media server
! STORM-XTS
! CICM
! Session Server
! MCS5200
In ISN08, IEMS is to be enhanced to consolidate performance data from the following
management platforms as well:
! Core and Billing Manager
! CS2000 Management Tools server
! PMDM
Pending availability of this enhanced version of IEMS, the integrated handling of
performance reporting and management for a CS2000 network at the Network
Management Level (NML) must be supported by third-party fault collectors and
third-party tools for reporting, analysis and management. The allocation of
responsibilities is as follows:
! Nortel-provided network elements and their EMs present performance monitoring
information to the NML using open interfaces, public domain protocols and data
models that conform to industry standards.
! A third-party integration application at the NML provides an interface between the
performance data provided by Nortel EMs and the information required by OSS
applications at the Service Management Level (SML), which typically run at a
centralised management site. Such an application is referred to as a performance
data collector. It relays performance data provided by network elements and EMs,
performing whatever intermediate reformatting and reorganisation the network
operator requires.
! Reporting, analysis and management applications at the SML, including
applications for:
" Report generation
" Trend analysis
" Traffic management
The integration applications to be used for a given network are commissioned by
the network operator and customised for the requirements of the network in
question. They are maintained by the application supplier.
Because some capabilities and requirements are common to different networks,
third-party suppliers may offer general-purpose integration applications that can be
tailored to individual requirements.

H5.2 Performance Monitoring via OMs

H5.2.1 OM Formats
The standard Bellcore model defines two main types of OSS for handling OMs provided
by switching nodes:
! Data Collection Operational System (DCOS)
! Network Traffic Management Operation System (NTMOS).
These OSSs, the switching node interface and the protocol used over this interface are
sometimes collectively referred to as EADAS (Engineering and Administrative Data
Aquisition System). EADAS is widely deployed in North American telecoms networks
as part of the Telcordia OSS suite. It is not widely used outside North America, although
CS2000 is capable of supporting the EADAS interfaces if required.
H5.2.1.1 DCOS / TR740 OMs

Switching nodes collect raw performance data in the form of two types of OM:
! Event counts, or event pegs, where registers are incremented individually every
time an event occurs.
! Usage counts, where equipment items are scanned at regular intervals, and registers
are incremented when the scan detects that the equipment is in use.
The OMs collected by a given node reflect criteria specified by the network operator, and
are typically a subset of the full set of available OMs.
DCOS OMs are divided into three different classes of data on the basis of how frequently
they are sent from the switching node to the DCOS. The intervals specified for
transmitting collected data are:
! Every 30 minutes
! Every hour
! Every 24 hours
Each class of data to be transmitted at one of these set intervals is subdivided into up to
256 sections, and each section can include up to 32K types of OM. The DCOS uses the
data provided to generate reports that enable the network operator to identify and resolve
problems such as traffic bottlenecks and non-optimal line configurations.
The protocol used over the interface between the switching node and the DCOS is
specified by Bellcore standard TR740.
H5.2.1.2 NTMOS / TR746 Near Real Time OMs

The NTMOS analyses trunk usage data collected and transmitted in near real-time, and
may take action as a result of this analysis, e.g. by applying controls to trunks or trunk
groups to improve traffic handling.
Like DCOS OMs, NTMOS OMs are divided into different classes of data on the basis of
how frequently they are sent from the switching node to the NTMOS. The intervals
specified for transmitting collected data are:
! Every 30 seconds
! Every 5 minutes

These two NTMOS data classes are much smaller than the three DCOS data classes.
The protocol used over the interface between the switching node and the NTMOS is
specified by Bellcore standard TR746.
H5.2.2 Trunk OMs and their Use

This section lists some of the trunk OMs collected by CS2000 for the purpose of
performance measurements, and briefly discusses how they can be used.
The following registers are used to collect traffic statistics for each trunk group.
Register Meaning / content

NWCCT Number of working circuits
INCATOT Total number of incoming calls
INFAIL Number of incoming calls that failed
NATTMPT Total number of outgoing calls attempted
PRERTEAB Number of outgoing calls abandoned before routing
NOVFLATB Number of calls overflowed
OUTFAIL Number of outgoing calls that failed
CONNECT Number of outgoing calls successfully connected
ANSWER Number of outgoing calls answered.
TRU Traffic usage in CCS [1]
SBU System-busy usage in CCS [1], i.e. unplanned SB time out of service
MBU Maintenance-busy usage in CCS [1], i.e. unplanned MB time out of service
TOTU Total usage (should be TRU + SBU +MBU)
[1] 1 CCS = 100 call-seconds of traffic; 1 Erlang = 1 call-hour per hour = 3600 call-seconds = 36
CCS. To obtain Erlang figures for 15-minute intervals, divide CCS statistics by 9.
These statistics can be used directly in assessing network performance. They can also be
used as input to a number of standard calculations that provide other measurements of
network performance, as follows:
! OOS (Out Of Service) threshold
The OOS value for a route is the number of out-of-service circuits for that route
divided by the number of working circuits, which is:
(SBU+MBU) / NWCCT
An OOS value of 0 indicates that all circuits are in service and that there are no
problems with the route. Up to five OOS threshold values can be defined to trigger
different levels of alarm.
! GOS(Grade Of Service) threshold
The GOS value for a route measures the probability of losing a call, it is a function
of the total number of circuits in service and the total traffic carried, and can be
expressed as:
f ( (NWCCT-SBU-MBU), TRU )
Up to five GOS threshold values can be defined to trigger different levels of alarm.

! ABR(Answer Bid Ratio) threshold

The ABR for a trunk group is the number of answered calls divided by the total
number of outgoing call attempts, which is:
ANSWER / NATTMPT
Up to five ABR threshold values can be defined to distinguish different ratios of
calls answered relative to outgoing call attempts, and to trigger different levels of
alarm when the ABR drops below a given threshold value.
! ASR(Answer Seize Ratio) threshold
The ASR for a trunk group is the number of answered calls divided by the total
number of connections / seizures made, which is:
ANSWER / CONNECT
Up to five ASR threshold values can be defined to distinguish different levels of
calls answered relative to connections / seizures made, and to trigger different levels
of alarm when the ASR drops below a given threshold value.
Note: If ASR remains stable when ABR drops for inter-network calls, this suggests
that the problem causing the ABR drop is downstream in another network. If ASR
drops along with ABR for inter-network calls, this suggests a problem within the
network.
! BCH(Bids per Circuit Hour) threshold
The BCH for a trunk group is the total number of outgoing call attempts divided by
the total number of in-service circuits, which is:
NATTMPT / (NWCCT-SBU-MBU)
Up to five BCH threshold values can be defined to distinguish different ratios of call
attempts to in-service circuits, and to trigger different levels of alarm when the BCH
drops below a given threshold value.
! SCH(Seizures per Cicuit Hour) threshold
The SCH for a trunk group is the number of connections / seizures made divided
by the total number of in-service circuits, which is:
CONNECT / (NWCCT-SBU-MBU)
Up to five SCH threshold values can be defined to distinguish different ratios of
connections / seizures made relative to in-service circuits, and to trigger different
levels of alarm when the SCH drops below a given threshold value.
! Traffic thresholds
Traffic thresholds cause alarms to be generated when the level of traffic is less than
the low traffic threshold value or more than a high traffic threshold value.
Typically, there is a single low traffic threshold value, which can be expressed in
either of two ways:
" low traffic threshold percentage * 90% * NWCCT
" TRU / NWCCT < low traffic threshold percentage * 90%
A high traffic threshold value is calculated using two values:
" Total traffic carried (TRU)
" The critical limit on circuit numbers, which can be specified either on the
number of working circuits (NWCCT) or on the number of in-service circuits
(NWCCT-SBU-MBU)
The basis for high traffic threshold comparisons is:
( ( TRU / critical-limit ) - 1.0 ) * 100%
Up to five high traffic threshold values can be defined to distinguish different high
levels of traffic, and to trigger different levels of alarm when the traffic level
exceeds a given threshold value.

H5.2.3 CS2000 Core Support for OMs

The CS2000 Core collects performance data by performing regular scans of hardware
components and software activities. OMs provide peg counts of how often events occur,
or indicate whether a given resource was or was not in use when a scan took place.
The CS2000 Core acts as a focal point for the collection of OMs for all subtending units.
This includes information provided by GWCs where this is equivalent to the OM
information that would be provided by trunk and line peripherals in a TDM switch, e.g.
information about TDM-side trunk interfaces or access interfaces.
OMs are sent from the Core to the Core Manager running on the SDM using ASCII over
TCP, which passes them on to the network operators OSS using the TR740 and TR746
interfaces.
OM information is used as a tool in the administration and maintenance of the CS2000,
and specifically for the following CS2000 administration activities:
! Traffic provisioning.
Information on equipment load is collected, permitting the calculation of load on a
per unit basis. This data is used to forecast future equipment load and determine
required equipment quantities.
! Service monitoring
Some OMs indicate service levels in a CS2000. If service is degraded, analysis of
additional data will help to determine appropriate corrective action, e.g. equipment
repair.
! Division of revenue
Some measurements assist in the traffic separation task, permitting the allocation of
revenues to different groups.
! Feature activation
Some measurements provide information on how often features are activated on the
CS2000, allowing operating companies to use the information to determine the need
for additional equipment or capabilities.
! Subscriber line usage
To assess the need for additional customer equipment.
! Problem identification
OMs are also used to display the results of machine diagnostic and testing activity.
This information identifies potential problem areas in the CS2000.
Table 84: Order codes for CS2000 OM support
OAMI0002 Interconnect OMs and Answer OM Enhancements
OAMI0003 Interconnect OMs
OAMI0004 Equal Access - Serving Carrier ID
OAMI0006 Long Call Audit

H5.2.4 Core Manager Support for OMs

Operational Measurements (OMs) allow various aspects of CS2000 performance and
usage to be monitored and reported on. They are held on the CS2000 Core, from which
OSS applications can access them via the Core Manager running on the SDM platform.
Requests for OM information are made via the OM Application API; the requests are
handled at the SDM by the Core Managers OM Access Server. The SDM OM Access
API has five components:
! The API manager interface, which is used to initialise and terminate the API.
! The OM reporting interface, which is used to specify which OM groups and tuples
are to be reported to the OSS application. OM reporting is supported for five-minute
and office-transfer periods.
! The OM change notification object interface, which allows the OSS application to
be asynchronously notified of any changes to specified OM groups, i.e. the addition,
deletion or alteration of OM group tuples
! The OM query operations interface, which allows the OSS application to retrieve
the following OM-related information:
" A list of OM tuples
" The office transfer period
" The CS2000 software release number
! The OM tuple interface, which
" Allows the OSS application to access individual fields in a CS2000 OM tuple
(e.g. key field, information field, register values).
" Perform format conversion between the binary format that CS2000 uses for
OM tuples and the ASCII format that the OSS application uses.
The OM Access Server is responsible for routing OM-related messages between Core
Manager applications and the Core. It is the single bridge between applications and the
Core for OM-related traffic. It handles all the link management activities between the
SDM and the Core, and acts as a server process for multiple applications that reside on the
SDM (using session management to provide message routing).
Two data dictionaries are used:
! The SDM data dictionary, which is used to validate OM group names and to support
conversions of OM tuple data between CM-binary and ASCII
! The SDM OM schema dictionary, which corresponds to the CS2000 OM schema
data dictionary and is used in notifying OSS applications about OM group changes.
A data dictionary manager process is used to synchronise these data dictionaries with each
other and with the OM schema data on the CS2000. It is is notified asynchronously of
changes to OM groups on the CS2000.
The Performance Management capabilities include the ability to store selected OMs in
Comma Separated Values (CSV) format for use by spreadsheets and databases. The
Secure File Transfer application can be used to send CSV files to multiple IP addresses.

H5.3 Performance Monitoring via PMs

! GWCs
GWC performance data is collected at regular intervals by the PM Poller, which is
a software task running on the CMT server alongside the GWC EM, UAS EM and
APS. The PM Poller uses SNMP to interrogate GWC MIBs and collect PMs. It then
formats the PMs provided into CSV (Comma-Separated Value) files, and uses FTP
to convey these to the NML.
Note: The PM Poller also collects PMs for the Sun Netra 240 server on which the
GWC EM runs.
! SAM21
As for GWCs (PMs collected by PM Poller).
! UAS
As for GWCs (PMs collected by PM Poller).
! USP
USP performance data is collected and stored on the USP, in the form of PMs
formatted into SSV (Semicolon-Separated Value) files. These files are FTPed from
the USP to the USP EM and then from the USP EM to the NML.
! PP8600
PP8600 performance is monitored by the PP8600 Device Manager. The results can
be exported via SNMP, and to IEMS as PMs in .txt format.
! RTP Media Portal
RTP portal performance data is provided to the MCS Manager via SNMP. The MCS
Manager formats the PMs provided into CSV (Comma-Separated Value) files, and
uses FTP to convey these to the NML.
! PVG
PVG performance data is provided to the PMDM using ASCII over TCP. The
PMDM formats the PMs provided into BCF (Binary Distribution Format) files, and
uses FTP to convey these to the NML.
! MG9000
MG9000 performance data can be provided on demand to the MG9000 Manager via
SNMP. MG9000 PMs are also collected via FTP at regular intervals from each
MG9000 by the MG9000 Performance Collector / Formatter, which is a stand-alone
application running on same server as the MG9000 Manager. This application
formats the PMs provided into CSV (Comma-Separated Value) files, and uses FTP
to convey these to the NML.
! Cable and customer LAN line gateways
These gateway types are third-party units. Line gateways are accepted for
deployment with CS2000 only if they are equipped with a compatible third-party
Element Manager. Typically, the gateway communicates with its EM using SNMP.
Details of communication between the EM and the NML are vendor-specific.
The EM for a line gateway will be able to interrogate the gateways MIBs to obtain
performance data if required, but performance management is not likely to be a
priority for a small line gateway.

H5.4 QoS Monitoring

Media gateways collect QoS statistics for use in measuring voice quality for VoIP calls.
Each gateway provides these statistics to its GWC at the end of each call, using the same
device/media control protocol used in setting up and clearing calls. The statistics provided
are bi-directional, e.g. counts are provided of packets and octets received as well as
packets and octets sent.
The GWC passes QoS statistics on to a device hosting a QoS Collector Application
(QCA), which is turn relays them to a customer OSS. See A89007781 for further
information about the QCA, and A89007725 for details of QoS OMs for trunk groups.
The customer OSS can use QoS data for the following purposes:
! Network engineering
! Trend analysis
! Trouble-shooting network problems
! Service Level Agreement (SLA) validation
Note: In order to achieve Service Level Agreements (SLA) validation, QoS reports
may be correlated with appropriate billing records so that the QoS of billed calls can
be determined. Each QoS report forwarded by a GWC contains a Correlation ID
(CID) that can be used to correlate it with the billing record for the call.
The QCA accepts QoS reports from the GWCs and stores them in a flat file in XML
format.
GWCs are enabled for QoS monitoring via the GWC Manager GUI. The GWC Manager
allows the customer to manage a pool of QCAs and assign them to GWCs. The GWC
Manager GUI can display a list of all the QCAs currently enabled for a given CS2000, and
supports the addition of new QCAs and the deletion of existing QCAs from the list.
Enabled QCAs can be assigned to GWCs via the Provisioning GUI of the GWC Manager.

Chapter H6 Security (OAM&P Access
Control)
This chapter describes the mechanisms used to control management access to the network
elements and applications comprised in CS2000 solutions. Security functionality is
implemented in:
! The functional Network Elements (NEs) involved in call processing and service
provision for end users
! Element Managers (EMs)
! The Integrated Element Management System (IEMS) used to provide a single
desktop environment for access to for access to CS2000 EMs and management
applications.
! Higher-Level Management (HLM) applications
Security mechanisms are designed to protect CS2000 network elements from
unauthorised viewing and / or modification of data, and from denial-of-service attacks.
! Section H6.1: Network Architecture for Security on page 838
! Section H6.2: Security Overview on page 838
! Section H6.3: User Authentication and Account Administration on page 840
! Section H6.4: Secure Remote Access on page 841
The following aspects of Succession security are not discussed in this chapter:
! Security of signalling and bearer paths from remote media gateways.
! Security for third-party components and for components provided by the network
operator, e.g. OSSs. This is outside the scope of a CS2000 Product Description.

Communication Server Capabilities OAM&P Security (OAM&P Access Control)
H6.1 Network Architecture for Security

Appropriate configuration of the CS2000 network infrastructure is an important part of
the solution for providing secure access to OAM&P functionality. The network for a
CS2000 solution is therefore partitioned into a number of LANs and VLANs, as described
and illustrated in section H1.2 on page 774. Section H1.2 discusses the physical network
architecture used for CS2000 OAM&P under the following headings:
! Trusted access to NEs via the OAM&P VLAN of the CS LAN
! Access to the OAM&P VLAN from outside the CS2000 CS LAN
To avoid duplication, this discussion is not repeated here.
H6.2 Security Overview

CS2000 solutions assume that the carriers VoIP network, including the CS2000 CS
LAN, is secure. IEMS provides secure access to all Nortel elements via SSH and PAM,
which are provided by Nortel as part of a CS2000 solution. SSH clients are provided for
access to CBM/SDM and CM/MAPCI and associated applications. These clients include
Telnet-like applications that replace ATA, ETA and SFTP.
Other security servers may be used via Pluggable Authentication Module (PAM)
technology. PAM is an evolving standard that has already been adopted by Sun, IBM, HP
and Microsoft (for NT). PAM allows integration of various authentication technologies
such as SSH, UNIX, RSA, INEO Passwerks, DCE, Radius, LDAP, SecureID, Skey,
Kerberos, PKI, and DCE into system entry services such as login, passwd, rlogin, telnet,
ftp and su without changing any of these services. PAM is integrated into Solaris 2.6 and
above.
If an alternative security server is required, providing it is the responsibility of the
customer, and a PAM-compatible security application must be installed on the network.
Operators should select the security system server after discussing the features with the
various vendors. It is recommended that a back-up server be installed for carrier grade
solutions. MAPCI direct access to the switch and CBM/SDM via the CBM/SDM element
manager is also possible via Passwerks, which must also be provided by the customer if
required.

Security (OAM&P Access Control) OAM&P Communication Server Capabilities
HTTPS is used for Java GUI launching and HTML based tools for CS2000 solutions.
For HTTPS to function, the end customer must obtain and install SSL keys into the web
servers. SSL keys are generated on a per machine basis and must be obtained and installed
as part of the installation procedure once the machine name, location and IP addresses are
available. HTTPS is used automatically by the web browsers which are used to access
these tools (Netscape and Internet Explorer).
Point to note:
! An HTTPS certificate is preserved over an SSPFS (ie the SW residing on the CMT)
upgrade. Therefore, It is therefore not necessary to perform this procedure
following an upgrade if an HTTPS certificate was already installed.
! The domain name service (DNS) must be enabled on the CS 2000 Management
Tools (CMT) server to allow the security certificates to work, and must be enabled
prior to the installation of the certificate. Refer to procedure Configuring Domain
Name Service in the document Solution-level Security and Admininstration,
NN10402-600.
! The customer must obtain an X.509 certificate. The customer may purchase a
certificate from a third-party Certificate Authority such as VeriSign. Nortel
Networks recommends the installation of a unique certificate for each host.
ITU-T Recommendation X.509 (which has been implemented as a de facto
standard) defines a framework for the provision of authentication services. Once a
certificate is held by a user, it can be used for all internet authentications, although
Nortel Networks recommends one per host. A convenient list of compatible
certificates is located at http://www.apache-ssl.org. Choose the digital certificates
link to see a list of potential vendors.
Note: The name of the certificate should match the host name of the server. A
separate file contains the key, and should not have an associated password.
! Make sure all GUI screens are closed before installing the certificate.
! The RSA key for the HTTPS certificate must not have a password.
! The certificate must be created with the fully qualified domain name (FQDN) of the
server on which the certificate will be installed.

Communication Server Capabilities OAM&P Security (OAM&P Access Control)
H6.3 User Authentication and Account Administration

H6.3.1 User Accounts for EMS and HLM Applications and Platforms
The Integrated Element Management System (IEMS) introduced in ISN07 to standardise
access to EMs provides support for centralised OAM&P security administration via
IEMS, including:
! Authentication for IEMS itself.
! Authorisation with support for groups and detailed permissions
! Audit trails
! Consolidated audit logs and security logs
! SSH sessions during CLUI launches
Below IEMS, the primary interface for access to OAM&P functions for CS2000 NEs is
provided by the EMS servers belonging to the OAM&P VLAN. Access to the EMS
servers, and to the higher level management protocols for GUI/CLUI clients and
machine-machine interfaces, is secured by some or all of the following:
! Use of UID and password user authentication
! Optional use of secure protocols
! The network architecture described in section H6.1
In order to ensure adequate security, a robust user authentication mechanism is required.
It is also desirable that integrated user authentication should be supported. This means
using a unified user database and administration system for multiple managment
applications in order to reduce the administrative overhead involved in managing user
accounts (UIDs, passwords and so on).
Integrated user authentication is supported by Pluggable Authentication Module (PAM)
technology, especially for Sun Netra platforms. PAM is an evolving standard that has
already been adopted by Sun, IBM, HP and Microsoft (for NT). Use of PAM allows
integration of Succession security with a number of industry-standard Security
authentication and adminstration mechanisms such as DCE, Unix, Radius, LDAP and
SecureID. PAM-based security of UNIX accounts is used to access the following
management applications:
! GWC EM
! CICM EM
! SAM 21 EM
! USP EM
! UAS EM
! APS EM
! LMM
! TMM
! NPM
! MDP
! PMDM
! PP8600 DM (on Sun)
! Node provisioning
! Trunk provisioning
! Line provisioning

Security (OAM&P Access Control) OAM&P Communication Server Capabilities
For the Series FX platform used for the SDM, Succession solutions can support INEO
Passwerks Security. Passwerks provides integration with security mechanisms including
DCE, ACE and LDAP. Access to the CS2000 EM (and hence CS2000 Core) is provided
by the Passwerks GUI and CLUI.
Management applications that use Windows 2000/NT accounts support Windows
authentication mechanisms, which include NTLM and Kerberos. These include the
PP8600 Device Manager (on Windows).
H6.3.2 Network Element User Account Administration

The CS2000 security architecture is such that CS2000 NEs are accessed predominantly
by trusted EMSs. This means that each NE typically needs to support only one user
account (or at most a limited number), as shown in Table 85. In general, security
provisioning for a given NE is performed via its EMS server.
Table 85: Network Element User Accounts
Account & Administration

NE
CS2000 Core Privclass (administered via MAPCI or Passwerks)
GWC 1 fixed Local Craft Interface account
SAM21 1 fixed Local Craft Interface account (no password)
CICM Windows 2000 account
UAS Windows 2000 account
USP Windows 2000 account
PP8600 Local P8600 CLUI account
PVG Local [1] Passport CLUI account

[1] Local indicates that administration is done per NE, rather than centrally
H6.4 Secure Remote Access


Appendices
Appendix A Appendices CS2000 International Product Description
ISN07 Release Contents Communication Server Capabilities
Appendix A ISN07 Release Contents
This appendix describes the incremental content of the ISN07 release in relation to the
previous ISN06.0 release. Because the CS2000 International Product Description was not
updated for the two 2003 dot releases, this appendix covers ISN06.1 and ISN06.2 content
that was not previously documented as well as content that is actually new in ISN07.
The summary of release content provided in this appendix is organised in the same way
as the body of the Product Description, i.e. under the following headings:
! Overview
! Hardware
! Software
! Packet telephony protocols
! Telephony interfaces
! Features and services
! Network fit
! OAM&P
Under each heading, there is a list of the main enhancements together with a brief
description of each one (typically a single paragraph).
Where feature documentation is available that provides more detailed information about
the implementation of a given enhancement, a reference number is provided that can be
used to retrieve this documentation from the PLS FMDOC library. Except where
otherwise noted, this is the activity reference number, as quoted in planning and
monitoring documents such as the Plan of Record (PoR), prefixed with an A, e.g.
A00002916 for activity 00002916.
See Appendix B: Summary of Product Description Updates for ISN07 for a table
summarising the updates that are to be made to individual chapters and sections of the
International Product Description in order to reflect ISN07 content.

CS2000 International Product Description Appendices Appendix A
Communication Server Capabilities ISN07 Release Contents
A.1 Overview
! CS2000 capacity increases
CS2000 support for 2.0M BHCA and 200,000 ISUP ports using an XA-Core 3+1
Atlas configuration using USP as signalling gateway. All necessary OAM&P
changes also supported, including increase in max size of table C7TRKMEM from
165,000 to 200,000.
FN reference: A00003485
A.2 Hardware
CS2000 Hardware
! CS2000-Compact message controller
Introduction of Interphase ATM MM PMC as CS2000-Compact Message
Controller card, replacing obsolescent IDT PMC.
! CS2000-Compact support for IW-SPM
Support for IW-SPM in CS2000-Compact hybrid configurations (initially for China
only)
! Hardware enhancements for CS LAN PP8600s
" Introduction of dual CPU/SF cards to support hitless equipment protection
and software upgrades.
# Dual 8692s mandatory for new shipments and recommended for 8691
upgrades.
# Existing single 8691s still supported, also upgrades to dual 8691s.
# No mixing of 8691s and 8692s.
" Support for additional link types, blades and functions:
# 8616SXE
# 2-Port DS3 ATM
# PoS WAN Links
# 10Gig Ethernet WAN Links
# M-Modules instead of E-Modules for gateway sites
# BootP Relay function for SDM
" Potential use of Alteon Switched Firewall for additional security
! Hardware enhancements for GWCs housed in SAM21 shelf, including new types of
GWC-equivalent unit
" Support for H.323 proxy as twin-card unit in SAM21 shelf, providing GWC
capabilities and H.323 gatekeeper functionality for CPE gateways and
3rd-party units. For H.323 access to CS2000, H.225 is used for establishing
connections and H.245 is used for establishing media sessions (audio / video
/ data) within the context of a H.225 connection. Supported units:
# IP-enabled Meridian 1s
# IP-enabled BCM PBXs
# CSE1000 for non-IP-enabled PBXs
# Westell DPNSS gateways
# Cisco 2600/3600 access routers

" Support for CICM (CentrexIP Client Manager) as twin-card unit in SAM21
shelf, providing GWC capabilities for remote IP clients controlled via
UniStim, which include:
# i2001, i2002 and i2004 Ethersets
# m6350 soft clients
Implementation details:
# CICM subtends GWC and is controlled by H.248 (check that this still
applies to twin-card CICM, not just SAM16 CICM)
# 3050 users off twin-card CICM unit
# Failover for active calls
# CICM EM in same SAM21 as CICM itself
Twin-card implementation replaces initial ISN06.x implementation of CICM
as SAM16 unit connected to CS LAN and controlled by GWC via H.248 (like
UAS), supporting up to 1,000 users per shelf.
" GWC support for up to 5,920 endpoints for large line gateways (MG9000).
FN reference: A00004236.
" AC GWC support for up to 1280 simultaneous announcements (up from 300)
! Current implementation of VRDN as twin-card GWC unit in SAM21 shelf, while
still supported, is to be superseded by Session Server (see below) based on
HP-CC3310.
! NGSS (Next-Generation Session Server), superseding VRDN
Support for an RFC3261-compliant SIP interface for open interoperability with call
servers, application servers and proxy servers, replacing the current proprietary
implementation based on early SIP drafts. The Session Server converts SIP
messaging into messages understandable by the CS2000. It is a platform for
delivery of multiple applications, of which the SIP Gateway application (also
supported in ISN07) is the first.
The Session Server consists of a NEBS Level 3 compliant hardware platform plus
a software framework and architecture for developing carrier-grade applications
and services. The hardware platform is the Hewlett Packard HP-CC3310, which
provides processing, memory, and disk capacity for STORM, SIP and SIP
applications. The base layer of Session Server Software uses NCGL (Nortel Carrier
Grade Linux) layer, which includes the Linux kernel. The Session Server
supersedes use of VRDNs. Once it has been installed in a CS2000, the VRDN must
be removed.
! USP hardware upgrades
New 1GB/3GB PP5 link cards as replacements for CEx and LEx cards, addressing
component obsolescence and hardware cost issues. PP5 includes integral PMC disk
to replace the separate single-slot RTC ST12CA SCSI disk. USP can support a mix
of 1GB PP4 and 1GB/3GB PP5 cards in the same shelf, and can also support a mix
of PP5 link cards with the previous LE2,LE3 and LE4 cards.
! Support for Interworking SPM (IW-SPM)
Initially believed to be outside the scope of the main CS2000 Product Description,
as support was restricted to hybrid configurations for use in China, but now churned
in to International for cable, so must be covered.

Media Gateways
! PVG hardware enhancements:
" Support for carrier-grade GigE uplinks to core network
" 4-port GigE FP
" Carrier-grade Virtual Router on VSP3, supporting hitless equipment
protection and software migration
" VSP3-O with integrated OC3/STM-1 Interface
FN references: CD2771, CD2397
" Recycle of PVG TDM FP cards to address component obsolescence
FN reference: CD2762
" Carrier-grade H.248 for PVG control
FN reference: A00003015, CD3183
! AusioCodes Mediant 2000 CPE gateway supporting PRI.
! CPE gateways and 3rd-party units controlled by CS2000 H.323 proxy (GWC
equivalent) via H.323 / H.225 / H.245:
" IP-enabled Meridian 1s
" IP-enabled BCM PBXs
" CSE1000 for non-IP-enabled PBXs
" Westell DPNSS gateways
" Cisco 2600/3600 access routers
CS2000 H.323 media proxy provides H.323 gatekeeper functionality, i.e. it
provides address translation and controls access to the network for H.323 terminals,
gateways and MCUs. It may also provide other services such as bandwidth
management. Gatekeepers are typically used as interconnect points between
network boundaries, but gatekeepers can also provide services to other endpoints
such as terminals where it supports network access for those endpoints, e.g. in an
enterprise environment. CS2000 can support up to 1024 simultaneous calls on a
H.323 GWC.
ISN07 provides CS2000 support for interoperability via H.323 with:
" Cisco 36xx and 72xx gatekeepers (Cisco IOS load 12.2.13 or later)
" CSE1000 Gatekeeper
" MCS5200 SIP clients (SIP PRI GW, PC client, Web client, i2004/i2002,
conferencing server)
Interoperability for CS2000 H.323 devices (M1 Rls 26, BCM Rls 3.5, Cisco
2600/3600, Westell liQ2032) and:
" CICM clients (i2004, i2002, M6350)
" Mediatrix line gateway (1124)
" UAS
" PVG
" CSE1000
Support for communication between CS2000, which uses GK-routed signalling,
and H.323 GKs that use direct messaging (which requires all gateways in a network
to support H.323). To make such communication possible, a Session Border
Controller (SBC) is used to:
" Tandem H.323 RAS and call control signaling between IP address spaces.
" Maintain minimal state information and provide ALG capability.
The SBC supports both direct messaging and GK-routed signalling. It behaves as a
back-to-back agent, perceived by CS2000 as a gateway but by the rest of the

network as a GK. The SBC is visible to both of the networks it is between, and the
NATs/FWs on both sides are visible to the SBC.
! MG9000 high-capacity (up to 5,920 lines) telco-located line gateway supporting
three types of line card:
" POTS-32 card (NY50AA) providing 32 terminations for basic analogue lines.
" 8X8 ADSL card (NY52AA) providing 8 ADSL terminations and 8 analogue
line terminations.
A fully equipped four-shelf frame is regarded as one logical MG9000 unit, and can
support the following access network capacity:
" 1952 POTS or GLC lines per frame
" 488 POTS+ADSL lines per frame
MG9000 lines can interwork with MCS5200 clients, CICM clients and Mediatrix
IAD.
MG9000 NTNY45 Series SuperCore motherboard enhanced in ISN07:
" ABI motherboard and DSP daughtercard combined into single card that does
either ATM or IP depending on software load.
" ECAN functionality provided by TI Janus DSP instead of Coherent
daughtercard.
MG9000 overload controls to ensure that the MG9000 survives, no MG9000
resources go SYSB, and the MG9000 and its resources continue to respond to EM
requests.
! Askey VG201 enhancement
Data port support enabled.
! Ambit 1-port LG001S IAD (16-port and 32-port gateways are also supported)
Cost-effective CPE (cheaper than i200x Ethersets) designed to complement
MCS5200 solutions, which can provide SIP client services for residential users.
Connectivity and capabilities:
" Two RJ45 jacks for Ethernet 10/100 BaseT
" Two RJ11 jacks for analogue phones
" Support for G.711 (a-law, u-law), G.729A/B and G.723.1 (5.3K)
" Support for modem, T.38 fax, in-band and out-of-band DTMF (RFC2833)
" Support for Layer 3 DiffServ marking
" Support for selected voice call features
! Westell DPNSS gateway
Gateway supporting DPNSS trunks to/from digital PBXs. Gateway is controlled by
CS2000 GWC using H.323 and QSIG, with DPNSS being encapsulated in QSIG
messages at the gateway to be conveyed across the network.
! Arris MTA
Arris gateway for use in cable access networks.
Media Servers
! MS2000 Series media servers as enhanced replacements for UAS
MS2010 (VoIP) is a 1U chassis built on AudioCodes IPM-1610; MS2020
(VoATM) is a 2U chassis built on AudioCodes TP-6310. Both consist of two
logically separate media gateway modules, each with its own MAC address and IP
address and each supporting up to 120 ports. Both modules share a redundant LAN
connection through an internal Ethernet switch.

Software load AMS 4.4 provides all the capabilities of UAS08, as supported in
ISN06, plus enhancements such as increased system density.
! UAS / MS2000 enhancements:
" Elimination of local UAS console
" 30-port conference resource management enhancement
" Security enhancements
Peer MGCs
! IMS rebranded as MCS5200
Media Proxies
! RTP Media Portal providing media proxy functionality
A media proxy can support both NAT (Network Address Translation) functionality
to control media stream access to a private address domain, or twice-NAT
functionality to permit NAT traversal between endpoints in different address
domains. In a CS2000 context, it is used for two main purposes:
" To support secure interoperability between endpoints in the Succession
domain (e.g. packet-side media streams to/from PVG and UAS/MS2000
ports) and endpoints in access or enterprise networks behind NAT devices
(e.g. IADs, H.323 gateways, CentrexIP clients).
" To support NAT traversal for secure interoperability between endpoints
behind different NAT devices, e.g. endpoints belonging to different access or
enterprise networks or served by a different network operator.
A media proxy is switched into a call when required, i.e. when call processing
determines that a NAT device is or will be involved, and is controlled by one of the
GWCs that is already involved in the call (i.e. controlling a participating trunk or
line). To allow the media stream for the call to flow through the NAT device, the
media proxy discovers which public address and port on the NAT device should be
used as the destination for packets to be sent to endpoints behind the NAT device.
For CS2000, the unit first used to provide media proxy functionality was the
SAM16-based RTP Media Portal (RMP). Signalling between the controlling GWC
and the RMP uses the MPCP protocol.
Remote Clients
! Support for remote Etherset (or equivalent) clients controlled by CICM using
UniStim. Specific terminals:
" i2001 as low-cost entry-level CPE unit
" i2002
" i2204
" i200x Phase 2 terminal
" Third-party terminal devices
" Key expansion module for i2002 and i2004 sets, providing physical button /
lamp capability for attendant (no need for PC).
! Support for m6350 remote PC softclients controlled by CICM using UniStim.

A.3 Software
Datafill
! Allows Servord commands ADO, DEO and CLN to manipulate the table LNINV
GND option for lines (including GWLPOT lines). If GND=Y, the line will be a
ground start line.
! MG9000 preprovisioning support:
" Format of MG9K LEN reflects physical location.
" When IEMS provisions an MG9K node, table LNINV will be automatically
datafilled with the available circuits.
! Ability to increase/decrease the number of endpoints assigned to an operational
H.323 gateway via either IEMS or XML, without any impact on active calls.
Translations
! MCDN (Meridian Customer-Defined Networking), including UDP (Universal Dial
Plan) with network-unique numbers and CDP (Co-ordinated Dial Plan) with
domain-unique numbers and multiple domains
A.4 Packet Telephony Protocols

! Integration / productisation of signalling security for CMTS/MTA
GWC security enhancements in the following areas:
" Kerberos Key Management
# SA lifetime management
# Traffic and DoS attacks support
# DNS interactions when FLEX policy is used
" IPSec
# Memory re-architecture
# Deletion of policies
# Key schedules
# Traffic and DoS attacks support
# Removal of code linked to HW SAs
Initial testing and integration using Arris TTM and Arris CMTS.
! Session Server support for RFC3261-compliant SIP interface
The current proprietary SIP-T implementation based on early SIP drafts is to be
replaced with an RFC3261-compliant SIP interface for open interoperability with
call servers, application servers and proxy servers. This new SIP implementation is
to be supported by Session Server, superseding VRDN.
The Session Server and SIP Gateway application are to be delivered in four drops
in the ISN07 timeframe. The Session Server converts SIP messaging into messages
understandable by the CS2000. It is a platform for delivery of multiple applications,
of which the SIP Gateway application is the first.

! Message tracing for SIP-T calls (RazoR gateway functionality)

Enables the Core to activate termtrce for SIP-T calls even though the SIP-T GWC
is not known in advance and is dynamically selected. Message tracing can thus be
turned on for a selected SIP-T trunk group when the translations and routing
software decides which SIP-T GWC to use.
! CS2000 support for H.323
In the H.323 multimedia architecture, H.225 is used for establishing connections
and H.245 is used for establishing media sessions (audio / video / data) within the
context of a H.225 connection. CS2000 H.323 proxy (GWC) terminates H.225 and
H.245 signalling to / from CPE units. VPN site gateways use H.225 RAS and call
control signalling to contact CS2000 GWC for call setup. CS2000 thus provides
H.225 gatekeeper functionality. Basic H.323 capabilities supported by CS2000:
" Support for H.323 v4
" H.225 fast start and slow start
" H.245 support via tunneling
" G.711 a-law/mu-law (with PLC), G.729a, G.729a/b
" Codec negotiation
" DTMF out of band support (H.245 to in-band) for H.323-H.323 calls or
H.323-PVG calls
" Support of active call failover and warm upgrades
" H.225 RAS (Registration Admission and Status)
" Multiple zone management per gatekeeper (within an enterprise)
" Gatekeeper-routed signalling
" In-band DTMF support via RFC 2833
! H.323 functionality via QSIG (ISO1996 version) trunks
Support for provisioning of H.323 using SERV option PRI_IP_PROT against an
LTID in table LTDATA. Support for DMS/CS2K International VPN services via
H.323 (including UDP and CDP dialplan support).
! H.323 interworking with UniStim signalling
! H.323 tunnelling
Support for tunnelling H.323 messages through a CS2000 Succession network, thus
connecting remote sections of VPNs. Allows H.323 components to be
carrier-hosted, with message tunneling done via QSIG. Components that are
currently envisioned as registering with the GWC are:
" BCM
" Meridian M1
Feature supports basic call and provides basic support for CAS and NCAS calls. No
supplementary services are supported.
Signalling interworkings supported for H.323:
" IBN7 ISUP
" IBN7 DFT
" ETSI ISUP V1/V2
" ETSI PRI
" UK ISUP

! T.38 FAX Support for International H.323
This activity provides CS2000-controlled switchover to T.38 mode for H.323 calls.
T.38 fax interworking is supported on calls between H.323 GWs (e.g. Meridian,
Cisco) and H.248 GWs (e.g. PVG) or MGCP GWs (e.g. Mediatrix). At least one
involved agent must be H.323. T.38 fax interworking is provided over Session
Initiation Protocol (SIP-T).
! UniStim
Proprietary interface used by CICM to communicate with remote CentrexIP clients.
UniStim is a stimulus protocol whose command set enables a Netqwork Intelligence
(NI), i.e. CICM, to control every aspect of the operation of a client Internet Terminal
(IT) such as an Etherset or soft client. RTP streams are used for voice transmission.
To provide reliable transport over UDP, UniStim makes use of Reliable UDP The
lower layer protocols are UDP and IP.
UniStim commands are categorised on the basis of which of the following
functional element managers they control:
" The Key/Indicator Manager is responsible for the IT keys and indicators. It
sets LEDs and icons, reacts to key depressions and detects on-hook/off-hook.
" The Audio Manager controls the audio configuration of the IT. It sets up voice
paths, establish end-to-end voice connections and handles tone configuration.
" The Display Manager is responsible for the presentation of information sent
by the NI, which means that the NI does not have to know where information
is physically presented or what language is used.
" The Basic Manager handles IT maintenance functions such as self-testing.
" The Network Manager is responsible for configuring and maintaining the
network connections between the NI and the IT.
" The Broadcast Manager is responsible for such things as icon, character table
and time/date downloading for both the IT and any attached accessories.
! MPCP
Proprietary variant of MGCP used to control SAM16-based RTP Media Portal.
! M2PA
Use of M2PA (MTP-User Peer-to-Peer Adaptation) instead of M2UA (MTP Layer
2 User Adaptation) to convey TCAP NCAS (Non Call Associated Signalling)
across the backbone packet network between CS2000s with different point codes
(strictly speaking, between USPs belonging to different CS2000s).

A.5 Telephony Interfaces

CCS7 Interfaces
! T-ISUP
Support for TISUP variant of ETSI ISUP V2, implementing Transit-ISUP interface
used by Deutsche Telekom as a national transit network interface.
" Standard ETSI ISUP messages newly supported by CS2000:
# Facility message (FAC)
# Loop Prevention message (LOP)
# (APM and PRI already supported)
" DTAG national-specific messages:
# Charging (CHG)
# Charging Extended (CHGE)
# Charging Extended Ack (CHGEA)
# Einhaengezeichen des A-Tl (EHZA)
# Facility Information (FIN)
# Nationale Nachricht (NANA)
# User Information (UIN)
Procedures for handling new messages and parameters, including charging and and
NP.SPV / NP.FE parameters. Also support for Congestion Control (new MTP pause
timer), modifications to procedures for completion of speech path and hop counter,
and support for ECT, TMR, Suspend and ROs.
! G-ISUP
Support for GISUP variant of ETSI ISUP V2, implementing Gateway-ISUP
interface used by Deutsche Telekom as an interface to international networks.
" New parameters
# CALL_DIVERSION_TREATMENT_INDICATORS
# OPTIONAL_CALLED_IN_NUMBER
# CALL_OFFERING_TREATMENT_INDICATOR
# CONFERENCE_TREATMENT_INDICATORS
# ORIGINATING ISC POINT CODE
# FREEPHONE INDICATORS
" Additional DTAG requirements:
# Additional Timer T39A for IDR-IRS.
# Congestion Control (new MTP pause timer).
# International gateway functionality covering Gateway definitions (in
case of one agent being SIP-T), Number Adaptation, handling
Originating ISC Point Code.
# Procedures for handling new parameters.
# Modifications to procedures for completion of speech path and hop
counter, and support for ECT, TMR, Suspend and ROs.
! G-ISUP routing enhancements
Routing based on NP.UKK, including setup of NP.UKK for incoming calls from
international networks. Also implements calls counter on a per originating ISC
Point Code basis.

! Interworkings between German R2 and T-ISUP, G-ISUP, SIP-T(G-ISUP)

Verification of interworking between G-ISP and T-ISUP and German R2 CAS
(German R2 is delivered by a protocol converter).
! Support for Indian ISUP
! Support for Russian ISUP and interworkings
! Enhancements to Spanish ETSI ISUP V2 to provide optional support for additional
capabilities used within the Telefonica network
FN references: A00002713, A00002935.
! ETSI ISUP FAILMSG mapping
Causes AISUP to be used as the key to access tables FAILMSG and TRTMTMAP
for interworked ACIF I-ISUP calls that encounter call setup problems. This is the
same key used by the older AISUP-based implementation of I-ISUP. ACIF I-ISUP
previously used Q767 as the key for accessing these tables, which meant that it
could not be distinguished from base ETSI ISUP V2 (except for PRI interworkings).
! Support for ANSI ISUP FGD trunks
Provides ANSI ISUP FGD (Feature Group D) support on CS2000 by porting the
functionality of TDM feature A59036475. This enables a CS2000 with ISN07 load
to directly interconnect to Inter Exchange Carriers (IEC) in NA. Only the following
interworkings are verified for CS2000:
" ANSI ISUP FGD to/from ANSI ISUP FGD
" ANSI ISUP FGD to/from ETSI ISUP V1
! MPC (Multiple Point Code) support for TCAP

INAP
! T-INAP support
Implementation of a subset of the CS-1 INAP extensions specified in 163 TR 78.96
and used by DTAG to support Universal International Freephone Service (UIFS):
" Implement T-INAP Application Context negotiation
" Enhance InitDP operation to handle T-INAP national parameters
# highLayerCompatibility
# additionalCallingPartyNumber
# sFEncountered
# gapInterval
# natCallingPartysCategory
# iNContainer
" Enhance Connect operation to handle T-INAP national parameters
# redirectingPartyID
# redirectionInformation
# natServiceInteractionIndicators
# iNContainer
# userUser
! T-INAP interworkings
IN triggering to T-INAP for G-ISUP, T-ISUP and ETSI ISUP V1, and specifically
parameter mapping for the following:
" IAM -> InitDP Interworking
" Connect -> IAM Interworking
! IN services for Telefonica
IN enhancement to meet Telefonica requirements, some specific to Telefonica and
some generic and reusable:
" TDP4 QoR (Query on Release) triggering
" CPC criteria triggering
" FCI handling
" ASF enhancements
" Overdecadic digits in Connect CLI parm
! China IN enhancements
Support for the following INAP capabilities:
" Enhancement to gapInterval parm of CallGap
" Support for multiple CallGaps
" Enhancement to timerValue parm of ResetTimer
" Enhancements to legID, calledAddress and release parms of CIRQ/CIRP
" Enhancement to sfBillingRecordCharacteristics parm of
ActiveServiceFiltering
" Support for ApplicationContextName negotiation.
" Enhancement to conversation time measurement for ApplyChargingReport
" Support CS-1R InitiateCallAttempt

! China ISUP connection to external IP

Support for direct China ISUP connection between SCP and external IP, making
assisting SSP functionality unnecessary. Implications:
" Enhance EstablishTemporaryConnection
" Enhance InitialDP by supporting parms iPAvailable and iPSSPCapabilities
" Using ApplyCharging to charge for the temporary connection to the external
IP
" Several scenarios of unsuccessful connection to external IP are enhanced to
comply with China requirement.
" Map the post-answer CISUP ANM(CON) to CPG
" Feature also supports up to three ApplyCharging operations (and ACRs) for
an IN call.
QSIG
! QSIG support for DPNSS
Westell DPNSS gateway supporting DPNSS trunks to/from digital PBXs. Gateway
is controlled by CS2000 GWC using H.323 and QSIG, with DPNSS being
encapsulated in QSIG messages at the gateway to be conveyed across the network.
DPNSS
! DPNSS support
Westell DPNSS gateway supporting DPNSS trunks to/from digital PBXs. Gateway
is controlled by CS2000 GWC using H.323, with DPNSS being encapsulated in
QSIG messages via GWC mapping between H.323 and QSIG so that it can be
conveyed across the network.
Basic Analogue Lines

! Basic analogue lines now also supported via:
" MG9000 gateways
" Ambit 1-port LG001S IAD and 16-port / 32-port gateways
" Arris MTA
" Gateways supported using H.323 (e.g. Meridian 1, BCM)
CentrexIP
! Support for CentrexIP lines serving i200x Ethersets and m6350 soft clients,
controlled by CICM using proprietary UniStim protocol.
See UniStim list item on page 851 for further information.

A.6 Features and Services

Analogue Line Services (inc. CEPT, CLASS)
! Support for additional analogue line services:
" China line services (full DMS-100i equivalence)
# Enhancements to IBN line services to comply with the China PSTN line
service requirements in the China specification YDN065 and YDT1128
(partial) for CS2000-Compact IAD IP solution. Also delivers new
downloadable China toneset CHINALGC. Services tested (mostly
CEPT) are SC, WML, ILR, CDND, CLF, IWUC, CFU, CFD, CFB,
CDTA, ICWT, SCWID, CCBS, I3WC, I6WC, CND, CNDB,
SUPPRESS and AUL, also the PW and RA options associated with
various services.
# Enhanced Meet-Me Conference service, including access control via
passwords instead of simply by dialling conference bridge DN.
" CEPT supplementary services
# CEPT CCB support ed as CLASS AR
(Note: PoR item also mentions CNP)
Support for CEPT Call Back to Last Received Call. This is essentially
MMP AR but with a different user interface and billing requirements.
# ACRJ support
(Note: PoR item also mentions CNP)
Support for CEPT ACRJ, which is essentially MMP ACRJ but with the
CEPT interface, PIN protection optionality, and CEPT billing.
# CEPT features CFF, CDTA, WML, SCS, SCL, CCBS, WUC and DTM
# Enhancements to existing CEPT ICWT service.
# Services enhanced/provided on CEPT lines:
- Concurrent Call Forwarding
- Denied Call Forwarding
- Subscriber programmable ringing for CFNA
- Call Pickup
- Directed Call Pickup
# Enhancements to CEPT ILR service.
# Enhancements to CEPT 3WC and Call Transfer.
! ANATEL 252 Compliance
Support for Call Waiting Ringback Tone plus others

! ACRJ functionality for HK

Enhances ACRJ functionality by allowing incoming HK ISUP V2 calls not to be
rejected if they provide a calling party number, even if the NI (Number Incomplete)
indicator is set to 1 (incomplete).
! LDI Display for CLASS phones
Enhances CND, CNAMD and DDN features that use the Multiple Data Message
(MDM) format by allowing the LDI (Long Distance Indicator) to be conveyed to
the subscriber terminal, causing L to be displayed.
! Support for appropriate selection of analogue line services over newly supported
analogue line implementations:
" Services supported by MG9000 gateways
" Services supported by Arris MTA
# End-to-end support for selected services for calls between CS2000 and
Cisco H.323 gatekeepers, subject to endpoint capabilities and
intermediate tunnelling capabilities.
# End-to-end support for selected services for calls between CS2000 and
CSE1000 gatekeeper, subject to endpoint capabilities and intermediate
tunnelling capabilities.
# FN reference: A00003629.
" Services supported by Ambit gateways / IADs
! Support for additional line services over existing analogue line implementations:
" Verification of V5.2 support for a wide range of additional services (also
confirmation of lack of V5.2 support for a subset of services).
! MCDN feature transparency
MCDN feature transparency for calls involving one or multiple call servers, using
tunneling and interworking. A subset of existing MCDN services supported on IBN
lines are supported.
A00003626 allows MCDN-based PBXs to interconnect with selected line gateways
for use in networked VPNs. Service interworking is supported and verified between
CSE1000 or BCM (H.323 GWs) on one call leg and CICM (H.248 GW) or
Mediatrix IAD (MGCP GW) on the other leg. Interworking supported nodally and
via SIP-T (ETSI ISUP V2+ QFT).
Network configuration:
" H.323 GWs are connected via H.323 to CS2000. MCDN data is transported
in non-standard data field within UUI IE in H.225 messages. IP phones are
connected via UniStim to the H.323 GW.
" CICM is connected via H.248 to CS2000 GWC. The IP phones are connected
to CICM via UniStim, and are provisioned on CS2000 as M5216 EBS lines.
" Mediatrix GW is connected to CS2000 via MGCP. Analogue phone agents
are provisioned on CS2000 as IBN lines.

" Inter-CS transport mechanism is SIP-T (ETSI ISUP V2+) with QSIG Feature
Transparency (QFT) option. The MCDN data is transported in Facility IEs
within ETSI ISUP V2+ Application Transport Parameter (APP).
Private data retrieved from MCDN tunneled information is propagated only for
private calls, with terminator and originator in the same customer group. The
mechanism used to identify private calls is based on existing QSIG functionality.
For calls breaking out into the PSTN, private information (MCDN data) is dropped.

No services newly supported in ISN07.
QSIG Services
! QSIG support for H.323
! QSIG support for DPNSS
Indirect Access
No enhancements in ISN07.
VPN
! Support for new types of VPN access:
" Westell DPNSS gateway supporting DPNSS trunks to/from digital PBXs.
" MG9000 gateways
" Ambit gateways and IADs
" Arris MTA
" CentrexIP lines serving i200x Ethersets and m6350 soft clients
! Support for new feature sets:
" DPNSS Feature Transparency
" Multimedia / blended user services
IN Services
See INAP section on page 854 for details and FN references.
! IN services for DTAG via T-INAP.
! IN services for Telefonica.
! IN services for China.
Regulatory Services
! Emergency call tracing
CS2000 Core Manager command to support call traces for established inter-office
emergency calls involving SIP-T DPTs, which displays the SIP Call ID of the
associated packet trunk when a TDM trunk is posted, and displays the TDM trunk
when the SIP Call ID is used to post the packet trunk.

! ETSI compliance for LI

In ISN07, the CS2000 implementation of LI is enhanced to make it compliant with
the ETSI LI requirements specified in ETSI TS 101 331 and ETSI ES 201 671. ETSI
defines three logically separate Handover Interfaces (HIs) to be used for providing
information to the LEA. Requirements are also specified for the information to be
collected for basic calls and service interactions. The ETSI-defined HIs are:
" HI1 Interface
A bidirectional interface used to pass requests from LEA to NWO/AP/SvPs.
The information passed includes LI monitor order activation and deactivation.
" HI2 Interface
A unidirectional interface used to pass Intercept Related Information (IRI),
e.g. data associated with the communication service of the target and standard
network signalling information from the NWO/AP/SvPs IIF to LEMF. This
corresponds to the Call Data Channel (CDC) in the Nortel implementation.
" HI3 Interface
A bi-directional interface used to pass call content of intercepted service to
LEMF. This corresponds to the Call Content Channel (CCC) in the Nortel
implementation.
A00002965 delivers SDM aspects of ETSI compliance for LI by implementing the
HI1 and HI2 interfaces. Its main focus is on how LI on the SDM will deliver ETSI
IRIs to the LEAs. It implements ETSI-provided definitions of operations to be used
to pass IRI.
A00003514 delivers Core aspects of ETSI compliance for LI by implementingETSI
ISUP protocol changes (to the layout of Calling and Called Party Subaddressing)
necessary to set up call content delivery for targeted calls (the HI3 interface) and to
provide required information about monitored calls and about service interactions
for such calls.
! LI and Internet transparency
Verification that LI operation is not affected by involvement of internet
transparency capabilities such as NAT in a monitored call. Requirement verified for
CICM, IADs, MTAs and "intra-switched calls".

! Japan trunk services

Direct CS2000 support for Japan trunk services (previously TDM side only):
" Notification of Time and Charge (NTC)
" Carrier Name Notification (CNN)
" Account Code (ACCT)
Conferencing
Voice Mail
RAS for Dial-Up Access

CentrexIP Services
! CentrexIP support for Centrex business set features
! CentrexIP support for multimedia services
DPNSS Services and DFT

! DPNSS Feature Transparency (DFT)
Support for DPNSS Feature Transparency (DFT), and specifically for:
" DFT via tunneling between call servers
" DFT interworking to PSTN
Ability to connect DPNSS PBXs to a CS2000 and provide carrier-hosted VPN
service to such PBXs by networking DPNSS signalling between PBX extensions
and CS2000 lines. The implementation uses a Westell iQ203x gateway on customer
premises to interface to TDM DPNSS trunks from the PBX and tunnel the DPNSS
signalling over a H.323 IP connection to the CS2000. This DPNSS signalling is then
tunneled transparently by the CS2000 to:
" Another DPNSS PBX connected to the CS2K via a Westell H.323 gateway.
" An IBN7 trunk supporting DFT.

Multimedia Services
! Capabilities available to blended users
Multimedia services enable blended users to have screen-based interactive access
to databases and media sources while simultaneously participating in a VoIP phone
call. The interactive access and use of the phone are co-ordinated. In the case of a
call between two blended users, interactive collaboration is possible because both
users are operating in the context of the same multimedia session. Examples:
" For a call between two blended users, e.g. between two users on the same
enterprise network, various types of interactive collaboration are possible:
# File transfer
# Web push
# Whiteboard sharing
# Clipboard transfer
# Instant messaging
" For a call from a non-blended user to a blended user, e.g. an incoming call to
a multimedia-enabled call centre, the call centre agent can check on-line
databases for information about the caller or information to be provided.
" For a call from a blended user to a non-blended user, e.g. a call from a
multimedia-enabled sales centre to a potential customer, the sales agent can
check on-line databases for detailed product and service information or
information that might be of interest to the called party.
! Multimedia service integration via SimRing
Multimedia services for blended users involve both the CS2000 (for voice services)
and the MCS5200 (for multimedia services).
Multimedia services are supported by a MCS5200 RAIDer client on the end users
terminal. When an incoming voice call is received from CS2000, a client window
pops up on the blended users screen at the same time as ringing is applied to his/her
telephone. The called party can then use this client window to initiate a multimedia
session with MCS5200. If the call is from another blended user, MCS5200 will
initiate a connection to the callers RAIDer client, allowing multimedia
collaboration by both users to take place.
The SimRing feature is used as an underlying blender mechanism to ensure that the
RAIDer client and the telephone are alterted simultaneously.
Support for blender services requires MCS5200 to be connected to CS2000 via a
SIP / PRI gateway (sometimes referred to as a SimRing PRI blender). On the
CS2000 side, this is connected to a PVG gateway via PRI; on the MCS5200 side,
the SIP / PRI gateway is configured as a SIP client. A call to a blended user
terminates on pilot DN of SimRing group (the subscribers DN), causing CS2000
to apply ringing to the subscriber line and set up a PRI call to MCS5200. MCS5200
then activates the RAIDer client.

ADSL Services
! CS2000 support for ADSL
ADSL (Asymmetrical Digital Subscriber Line) access to the backbone packet
network for data sessions with private intranets and/or the public internet is
supported by the MG9000 high-capacity line media gateway. DSL technology
exploits unused frequencies to support simultaneous transmission of voice and
high-speed data over conventional copper telephone lines. The service is "always
on", meaning that subscribers don not need to dial in or wait for call set-up. ADSL
is so called because it allows data to be downloaded much faster than it can be
uploaded (up to 6Mb/s downloading vs 640Kb/s uploading), reflecting what users
typically require. ADSL is defined in ITU-T Recommendation G.992.1 and ANSI
Standard T1.413-1998.
A.7 Network Fit

Numbering Plan
No ISN07 enhancements.
Tones
! CICM support for Australian tones
! PVG support for Russian tones
! PVG support for Indian tones
Announcements
! Media Server 2000 (MS2000) as enhanced replacement for UAS (see Media
Servers section on page 847 for details).
Network Integration Issues

! GWC support for Gateway Inter-Machine Trunk (GWIMT) on PVG
The IMT Global trunk agent on CS2000 enhanced to support a limited set of
gateway services and partial compliance with Q.767 and international use of White
Book Q.764. Such gateway trunks can also be interworked to a set of existing UCS
(Universal Carrier Services), which are NA-specific national trunk agencies. Net
effect is that CS2000 can act as an international gateway for switches connected to
it via NA trunks.

Internet Transparency
! Media proxy support for NAT
Network Address Translation (NAT) binds IP addresses in one domain to IP
addresses in another domain, enabling routing to take place between hosts
belonging to different address domains. Basic NAT allows hosts in a private
network to access hosts in a public network. Twice-NAT prevents address collisions
between private and public networks. For CS2000, twice-NAT functionality is
provided by a media proxy with two specific capabilities:
" It enables media streams to traverse NAT devices and firewalls controlling
access to customer networks.
" It acts as a firewall to control the entry of media streams into the private VoIP
address domain containing the CS LAN and carrier-located gateways.
A media proxy is inserted in a call when call processing determines that a media
stream has endpoints in different address domains (at least one of them is behind a
NAT device) or that it crosses the boundary between the private VoIP address
domain and a public address domain. The media proxy then performs NAT on the
IP addresses specified in the source and destination fields of each incoming packet.
Media proxies should be located as close as possible to the media gateways for
which they are to provide proxy functionality. Typical configurations are:
" Media proxy located on the CS LAN.
" Media proxy co-located with carrier-located gateways.
" Media proxy co-located with a broadband remote access server connected to
customer-located gateways.
! Intelligent media proxy insertion, i.e. ability to insert proxy via slave side GWC, as
required for networks with relatively few proxies:
" Media proxy needs to be provisioned only for GWCs that support gateways
outside the Succession domain and those that host SIP-T trunks.
" Media proxy provisioning is optional for GWCs that control PVGs, UASs,
MG9Ks and cable gateways
! Support for the provisioning of a given media proxy on multiple CS2000s. Calls
between gateways that are provisioned on different CS2000s but behind the same
proxy need not route calls through the proxy (unless NAT is required).
Call Admission Control (CAC)

! Virtual Call Admissions Control (VCAC) on CS2000
VCAC is a QoS mechanism that allows CS2000 to cancel post-dial, pre-ringing
calls that would overload a segment of the packet network. When a call is made, the
CS2000 identifies the Limited Bandwidth Links (LBLs) along the speech path
between the two endpoints, and calculates whether there are sufficient resources
available on all these LBLs not to exceed provisioned limits. If all the LBLs can
handle the new call, the call progresses as normal. If one or more LBLs cannot
handle the call, the originator receives a treatment (tone) provisioned by the carrier.

A.8 OAM&P
Overview
! Integrated Element Management System (IEMS)
Main OAM&P change in ISN07 is IEMS for single integrated interface supporting
drill-down access to NEs, EMs, EMS platforms and EMS applications. Ultimate
aim is support for OAM&P via a single frame. IEMS can coexist with existing
OAM&P applications on the high-availability next-generation standard platform
(Netra 240). Key to single OAM frame objective is migration of SDM applications
from AIX platform.
IEMS provides tree-like expandable Integrated EMS Topology menu to represent
and support access to:
" Network Elements
# CS2000 Core (XA-Core or Compact)
# STORM
# PP8600
# GWC
# SAM21
# CICM
# Session Server
# USP
# MS2000 or UAS
# PVG
# MG9000
# MCS5200
# RTP Media Portal
" Element Managers
# CS2000 Core Manager
# GWC Manager
# SAM21 Manager
# CICM Manager
# USP Manager
# UAS Manager
# APS Manager
# MCS System Manager
# Preside MDM
" EMS Platforms such as
# SDM
# SSPFS
# MDM
# CICM Manager platform
# MCS Manager platform

" EMS Applications such as

# OSSGate (access to Node Configuration, Trunk Configuration, Carrier
Endpoint Configuration, Line Configuration via SERVORD+, V5.2
Configuration, V5.2 Maintenance)
# LMM (Line Maintenance Manager)
# APS
# QCA (QoS Collector Application)
# NPM (Network Patch Manager)
! Packaging and integration of EMs and management applications in ISN07
Delivered via the CS2E software package (SDM) or the CBM software
package (Netra 240), which is independent of the Sun-resident CS2M
package used to deliver management tools for CS2000 components other than
the Core. Prior to ISN07, the Core Manager ran only on the SDM AIX
platform. This platform is still supported in ISN07, but the Core Manager can
now alternatively run on a Sun Netra 240 server, which potentially makes it
possible to support all CS2000 OAM&P in a single Sun frame. The
Sun-resident application is referred to as the Core and Billing Manager
(CBM). For an XA-Core configuration using an FLPP, CS2E/CBM software
also comprises EM functionality for the FLPP.
" CS2M (CS2000 Management Components) is an NCL software package that
resides on the CS2000 Management Tools server. It includes the following
Sun packages:
# SESM (Succession Element and Sub-Network Manager)
$ GWC Manager
$ Node Configuration
$ Trunk Configuration
$ Carrier Endpoint Configuration
$ Line Configuration (SERVORD+)
$ TMM (Trunk Maintenance Manager)
$ LMM (Lines Maintenance Manager)
$ LTM (Line Test Manager)
$ V5.2 Configuration
$ V5.2 Maintenance
$ UAS Manager
$ MS2000 Configuration Tool
$ APS Manager
$ Common Launch Point (CLP) for CS2000 Management Tools
# SAM21EM (CS 2000 SAM21 Manager)
The software package that contains the CS2000 SAM21 Manager
application for the SAM21 Shelf Controller (SC).
# QCA (QoS Collector Application)
The software package that contains the QoS collector application for
QoS records sent from the GWC.

" APS (Audio Provisioning Server)

" SSPFS (Succession Server Platform Foundation Software)
The NCL software package that contains base operating system and common
tools, libraries and server functions used by EML applications. These include:
# EMS proxy services supporting access to embedded server software,
including:
$ Call Agent Manager for the Call Agent platform.
$ STORM Manager for the STORM software embedded in the
STORM software load (STM04).
$ Client for USP Manager embedded in USP software load (client
supported on separate PC prior to ISN07 integration with SSPFS).
# PM Poller
# NPM (Network Patch Manager)
Sun package (moved from the CS2M NCL) that contains the patch
management application for GWC and MG9000 NEs (each of which
has a Local Patch Manager as a client side target for NPM).
# Generic non-proprietary services and protocols such as BOOTP,
DHCP, TFTP and KDC.
" Embedded server software
# USP Manager server software embedded in USP load.
# Call Agent platform manager software.
# STORM software embedded in the STORM software load (STM04).
! EMs that are not packaged with other CS2000 Management Tools, but that can be
accessed via IEMS:
" PP8600 Device Manager
PP8600 Device Manager is a client application that interfaces directly with
PP8600s without a server. It can run either on a Windows PC or on a Sun
workstation.
" PMDM (Preside Multiservice Device Manager) for PVGs
Runs on a Sun server. NCL name is PCR.
# MDP (Management Data Provider) application
# PMDM mid-tier server
Check whether MDP and mid-tier server are the same entity (both are referred
to in different docs, but no single doc refers to both).
" MG9000 Manager
Runs on a Sun server. NCL name is 9KEM.
" CICM Manager
CICM element manager software is embedded in CICM NCL CICE.
" MCS Manager comprising
# Management Module
# Database Module
# Accounting Module

MCS System Manager running on Sun server. NCL names are IMSC and
IMSD. Provides EM functionality for RTP Media Portal, so must be used if
RMP is used, even if CS LAN configuration does not include MCS5200.
! MG9000 Manager capacity expanded to support:
" 110,000 lines
" 75 nodes
Fault Management
! Integrated fault stream to NML via IEMS
IEMS aggregates all EMS/NE fault data for CS2000 Core, PP8600, MG9000, USP,
PVG, GWC, STORM, SAM21, MCS, media server, CICM and Session Server, and
provides a single consolidated fault feed in any of the following formats:
" SCC2
" NT STD
" SNMP
" Custlog
! SDM log delivery enhancements (SCC2)
Use of the Log Delivery application to:
" Provide a single consolidated northbound log feed for all the components in a
node.
" Implement the initial phase of lost log detection for non-CM logs.
" Enhance the lost log indication mechanism for CM logs.
" Enhance the Log Delivery applications capacity to handle bursty traffic of
logs.
" Make Logroute tool more user friendly and remove redundant processing.
! Logs for SIP / SIP-T
This feature integrates two sources of Session Server logs by providing a CLUI (a
Log Client) to control which combination of modules and filters is activated in
Radvision CallP software and it also filters Session Server internal logs.
Configuration
! Wizard for adding NEs, EMSs, EMS Platforms or EMS Applications to IEMS.
! Provisioning templates for PVG
Main MDM nodal provisioning screen provides component tree on the left side,
and allows user to add and modify components by selecting the desired component.
On the right hand side of the screen, the user can select the appropriate service
template. When user drags and drops required template to the selected component,
a template GUI pops up allowing user to set and modify appropriate parameters.
! Dynamic changes to size of H.323 gateway
Ability to change (increase/decrease) the number of endpoints assigned to an H.323
gateway via both IEMS and XML.
! CICM flowthrough provisioning and hitless in-service upgrades.
! IEMS support for UAS/MS2000 configuration requirements
Configuration via a common configuration template with Nortel-provided defaults:
" Data backup and restore (image files on TFTP server)

" Upgrade and patching (integration with NPM)

" Flow-through provisioning interface (XML)
" Ability to import common configuration from a template or a "master" unit
Accounting
! AMA capture of software metering information for NAOC and PCA
Enhancements to NAOC and PCA services to support capture of software metering
information in an AMA type 612 module.
! AMA enhancements for DTAG international gateway
Support for recording the following DTAG requirements in AMA records:
" Receipt date and time for first FCI operation recorded in a module code 098
for IN calls in the DTAG network.
" Disconnecting Part Indicator (DPI) captured in type 611 module along with
CHBN to indicate which party released call.
" Charge Band Number (CHBN) captured along with DPI in type 611 module
with context ID 80085.
" Additional ISUP information (Transmission Medium Requirement, Service
Type, Cause Indicator) captured in type 611 module with context ID 80100.
(Requirements doc, but not FN, says long duration call AMA records must be
generated for calls longer than 30 minutes. Current minimum duration for long call
is 1 hour.)
! SBA real-time billing robustness.
! SBA billing integrity maintained even in the event of catastrophic failure.
! Auto-closure of billing files
If the Core SBA application is unable to send billing data to the SDM SBA
applications, it changes its state to backup mode and stores billing data in backup
storage. When communication is restored, the backed-up data is sent to the SDM in
recovery mode and the SBA then returns to normal mode. This feature
automatically closes billing files on exit from recovery mode.
! SBA support for electronic file delivery
Reduces the size of SBA and AFT libraries by separating library content from
executables, thus permitting electronic download via IP instead of software delivery
on tape.
! MG9000 support for hardware metering
Line hardware metering involves the generation of hardware pulses to provide call
charge information to the CPE of the call originator. In Succession, the hardware
pulses are generated from the MG9000 gateway that controls the subscriber line
(terminated on GLC32 line card). Pulsing information is sent to the MG9000 from
its GWC using the amet (automatic metering) tone package defined in the Megaco
Enhanced Analogue Line Packages document. Metering support requires AOC to
be specified for the GWC in table SERVRINV.

! CS2000 metering enhancements for tariff model compliance

Line hardware metering functionality enhanced to support a range of charging
intervals ranging from 1 to 720 seconds (instead of only per minute or per second).
! Telefonica lines/trunks AMA billing integration
! CS2K NAOC trunk metering enhancements for Spain
Enables eceived Spanish ISUP charging messages (&TAR) to be processed within
the NAOC framework, making it possible to:
" Convert received charging messages into NAOC tariff format
" Trigger tariff updates and AMA record generation based on the received info
Performance Management
! PM integration
IEMS support for a single consolidated performance feed for PP8600, media server,
STORM-XTS, CICM, Session Server, MCS.
! Capacity increase for SDM OM delivery application (OMDD)
Enables SDM OMDD application to transfer 12000 OM tuples (with up to 32
registers each) from the Core to the OSS can be done in less than 2.5 minutes,
compared with the previous time of more than 3.5 minutes.
! 5 and 30 minute OM data pull for the PVG
Ability for PVG to provide PMs to MDM and from there to OSS for use in PVG
monitoring, planning and engineering:
" PMs provided at 5-minute intervals for real-time monitoring.
" PMs provided at 30-minute intervals for further analysis.
! IEMS support for AMS07 performance management requirements
Performance data requirements (preferred mechanism is PMPoller):
" CPU occupancy, memory utilization, interface level communication metrics
(MIB-2), QoS, call volume/type metrics
" Gateway must deliver end of call QoS data to the GWC.
! Performance measurements for CICM
Integration of CICM-generated PMs and OMs with the PMs and OMs of other
network elements for reporting to OSSs.
Security
! IEMS security
Support for centralised OAM&P security administration via IEMS, including:
" Authentication for IEMS itself.
" Authorisation with support for groups and detailed permissions
" Audit trails
" Consolidated audit logs and security logs
" SSH sessions during CLUI launches
! Security enhancements: client firewall compatibility and strong authentication.

! Centralisation of authentication database for PAM/Radius based EMSs

! Support for customer plug-ins for external authentication databases (e.g. SecurID,
LDAP)
! Use of SNMPv3 with USM and encryption for PP8600 communication
! FTP proxy for CBM and SDM
Provides a non-DCE option for secure FTP that allows secure FTP access to the
Core via CBM (Solaris-based Core and Billing Manager) or SDM. Provides SSH
(Secure Shell) security so that the Core will not be compromised by illegal users.
! UniStim security enhancements to encrypt messaging between:
" CICM gateway and i200x terminals
" CICM gateway and soft clients (m6350)
! Web access for CICM enterprise administration and end user control
" Each enterprise has web access to CICM management for service changes.
" Each CICM user has web access to the user-assigned data for their set's
features.
! Security for GWC EM and SAM21 EM
" SAM21 Manager support for user authorisation
" CLUI access to commands for GWC EM and SAM21 EM
! Remote LCI for secure access to MG9000.
! Security for UAS, MS2000 and APS
Same EM and APS used for access to UAS and MS2000. Specific capabilities:
" Audit trail at the NE.
" Use of PAM for user accounts on the NE
" Multiple user groups and user accounts
" No hardcoded accounts or passwords

Appendix B Summary of Product
Description Updates for
ISN07
The following table summarises the updates that are to be made to individual chapters and
sections of the International Product Description in order to reflect the ISN07 content
described in Appendix A: ISN07 Release Contents.
Part / Chapter Related Features and Other Implications

A: Introduction
A1: Market Overview
Rework network overview to reflect newly supported capabilities (new
A2: Network Overview gateway types, media proxy, remote clients)
Update to reflect newly supported interfaces and services; XA-Core support
A3: Product Overview for 2.0M BHCA and 200,000 ISUP ports (A00003485)
A3.2: Interworking Matrix Update matrix to reflect newly supported interfaces and interworkings
B: Hardware
HW enhancements for CS2000-Compact; HW enhancements fo PP8600;
New section on CICM providing GWC capabilities for CentrexIP clients,
describing initial SAM16 implementation and enhanced twin-card
implementation; New section on H.323 proxy providing GWC capabilities
for gateways controlled via H.323 / H.225 / H.245; New section on
Next-Generation Session Server replacing VRDN SIP capabilities
(A00003933); Up to 8,200 endpoints on GWC controlling large line
B1: CS2000 Hardware
gateways (A00004236); AC GWC support for up to 1280 simultaneous
announcements (up from 300); USP hardware upgrades; New section on
support for legacy interworkings, reflecting newly supported IW-SPM and
existing looparound trunk capabilities (information previously provided only
in hybrid configuration document); Update OAM&P hardware section to
reflect enhancements and repackaging, especially availability of IEMS and
of CBM as Netra-based replacement for AIX-based SDM

CS2000 International Product Description Appendix B
Communication Server Capabilities Summary of Product Description Updates for ISN07

HW enhancements for PVG, including FP with 4 GigE ports (A00002818),
VSP3o with integrated STM-1 (CD2771, CD2397) and carrier-grade H.248
(A00003015); New section describing CPE media gateway supported via
H.323, including IP-enabled Meridian 1 PBXs, IP-enabled BCM PBXs,
Cisco 2600 / 3600 access routers, and CSE1000 for non-IP-enabled PBXs;
B2: Media Gateways New section describing high-capacity MG9000 line media gateways
supporting analogue lines and ADSL; New section describing Westell
DPNSS gateways, which provide an interface between DPNSS trunks and
DPNSS / QSIG / H.323 interface with GWC; New section describing Ambit
gateways and IADs; New section describing Arris cable gateway; Data port
support enabled on Askey VG201
B3: Media Servers New section on MS2000 as enhanced replacement for UAS; UAS/MS2000
enhancements
New chapter describing remote CentrexIP clients controlled by CICM using
UniStim (CICM itself contrtolled by GWC using H.248); Support for remote
B4 (new): Remote Clients i200x Ethersets (or equivalent), including key expansion module to provide
physical button / lamp capability for attendant; Support for remote PC
m6350 softclients with co-ordinated session capability
New chapter describing CS2000 support for media proxy functionality, i.e.
public adress discovery, NAT, twice-NAT and NAT traversal for media
B5 (new): Media Proxy streams; Section on SAM16-based RTP Media Portal (RMP) unit first used
to provide media proxy functionality, controlled by GWC using MPCP
(A89007985)
B6 (was B4): MCS5200 Rework chapter to reflect IMS rebranding as MCS5200 and increased
support for integration between MCS52000 and CS2000 for multimedia
C: Software
Update/add load names and versions to reflect software packaging for
C1: Software Loads
ISN07.0
Updates and additions to reflect support for new types of interface; Servord
manipulation of LNINV GND option for lines (A00002555); MG9000
C2: Trunk and Line Datafill
preprovisioning support (A00002252); Dynamic modification of number of
endpoints assigned to an operational H.323 gateway
MCDN (Meridian Customer-Defined Networking), including UDP (Universal
C3: Translations and Routing Dial Plan) with network-unique numbers and CDP (Co-ordinated Dial Plan)
with domain-unique numbers and multiple domains
D: Packet Telephony Protocols
Updates and additions to reflect new and enhanced protocols, inc. H.323,
UniStim, MPCP, RFC3261 SIP; New section on transport protocols
D1: Overview
(replacing separate chapter D2 on SCTP only); New section on SDP
(replacing separate chapter D3)
Session Server (VRDN replacement) support for an RFC3261-compliant
SIP interface for open interoperability with call servers, application servers
D2 (was D9): SIP / SIP-T and proxy servers, replacing the current proprietary implementation based
on early SIP drafts (A00003933); Message tracing for SIP-T calls (RazoR
gateway functionality)
Updates and additions to reflect H.248 enhancements; Carrier-grade H.248
D3 (was D5): H.248
for PVGs (A00003015)
D4: ASPEN

Appendix B CS2000 International Product Description
Summary of Product Description Updates for ISN07 Communication Server Capabilities

Major new chapter on support for open H.323 architecture and
H.225/H.245; Basic H.323 capabilities (A0001895); H.323 functionality via
QSIG (ISO1996 version) trunks (A00002255); H.323 interworking with
D5 (new): H.323 UniStim signalling; H.323 tunneling through a CS2000 network via QSIG,
thus connecting remote sections of VPNs and allowing H.323 components
to be carrier-hosted (A00002358); CS2000-controlled switchover to T.38
mode for H.323 fax calls (A00003627)
New chapter describing proprietary UniStim protocol and its use by CICM
D6 (new): UniStim
to control remote CentrexIP clients, including UniStim encryption
D7: NCS Integration / productisation of signalling security for CMTS/MTA, including

Kerberos key management and IPSec (A00003575)
D8: MGCP
New chapter describing proprietary protocol based on MGCP (no SDP)
D9 (new): MPCP used to control RTP Media Portal
D10 (was D8): IUA
D11 (was D10): V5UA
Use of M2PA instead of M2UA to convey TCAP NCAS (Non Call Associated
D12 (was D11): MTP Adaptation Signalling) across the backbone packet network between CS2000s
D13 (was D12): DSM-CC

D14 (was D13): OAM&P
protocols
E: TDM Telephony Interfaces
E1: Overview Updates and additions to reflect new and enhanced protocols
Transit-ISUP interface used by Deutsche Telekom implemented as TISUP
variant of ETSI ISUP V2 (A0002909); Gateway-ISUP interface used by
Deutsche Telekom implemented as GISUP variant of ETSI ISUP V2
(A0002908); G-ISUP routing enhancements (A00003696); Interworkings
E2: CCS7 Interfaces between German R2 and T-ISUP, G-ISUP, SIP-T(G-ISUP); Support for
Indian ISUP (A00004931); Russian ISUP and interworkings (A00005164);
Enhancements to Spanish ETSI ISUP V2 (A00002713, A00002935); ETSI
ISUP FAILMSG mapping (A00002794); Support for ANSI ISUP FGD trunks
(A00003695, A59036475); MPC (Multiple Point Code) support for TCAP
T-INAP extensions to CS-1 INAP, as used by DTAG to support FreePhone
E3: INAP (A00002907); T-INAP interworkings (A00002934); IN services for
Telefonica (A00002678); China IN enhancements (A00002754); China
ISUP connection to external IP (A00002900)
E4: PRI
Internal use of QSIG to support H.323 tunneling across CS LAN between
E5: QSIG
H.323 GWC and Core (inc. DFT)
Support for Westell gateway supporting DPNSS trunks to/from digital PBXs,
E6 (new): DPNSS controlled by CS2000 GWC using H.323 and QSIG, with DPNSS being
encapsulated in QSIG messages at the gateway
Basic analogue lines now also supported via MG9000 gateways, Ambit
E7 (was E6): Analogue
GWs/IADs, Arris MTA, gateways supported using H.323 (e.g. Meridian 1,
Subscriber Lines
BCM)
E8 (new): CentrexIP Support for CentrexIP lines serving i200x Ethersets and m6350 soft clients,
controlled by CICM using proprietary UniStim protocol


F: Features and Services
F1: Overview Updates and additions to reflect new and enhanced services
IBN line service enhancements to comply with China PSTN line service
requirements (A00002755); Enhanced Meet-Me Conference service for
China (A00002901); CEPT CCB support ed as CLASS AR (A00002654);
ACRJ support (A00002655); CEPT features CFF, CDTA, WML, SCS, SCL,
CCBS, WUC and DTM (A00002610); Enhancements to existing CEPT
ICWT service (A00002639); Concurrent Call Forwarding, Denied Call
Forwarding, Subscriber programmable ringing for CFNA, Call Pickup,
Directed Call Pickup services enhanced or newly supported on CEPT lines
(A00002640); Enhancements to CEPT ILR service (A00002641);
F2: Analogue Subscriber Line Enhancements to CEPT 3WC and Call Transfer (A00002642); ANATEL
Services 252 Compliance, including support for Call Waiting Ringback Tone
(A00002365); ACRJ functionality for HK (A00002761); LDI Display for
CLASS phones (A00002558); Support for appropriate selection of analogue
line services over newly supported analogue line implementations;
Verification of V5.2 support for a wide range of additional services
(A00002330); MCDN feature transparency using tunneling and
interworking for a subset of existing MCDN services supported on IBN lines,
allowing MCDN-based PBXs to interconnect with selected line gateways for
use in networked VPNs (A00003626)
New chapter listing features available to remote clients served by CentrexIP
F3 (new): CentrexIP Services
lines
F4 (was F3): ISDN
Supplementary Services
F5 (was F4): QSIG Services QSIG support for H.323; QSIG support for DPNSS and DFT
New chapter describing DPNSS Feature Transparency (DFT), i.e. nodal
F6 (new): DPNSS Services and networks support for DPNSS services via H.323 and QSIG
encapsulation of DPNSS signalling (A00001965)
F7 (new): APM Feature New chapter (edited version of TDM PD equivalent) describing networked
Transparency support for services via ETSi ISUP V2+ APM
VPN access for Westell DPNSS gateways, MG9000 gateways, Ambit
gateways/IADs, Arris MTAs, H.323 gateways, CentrexIP lines; Support for
F8 (was F6): VPN
DPNSS Feature Transparency; Support for multimedia / blended user
services
F9 (was F10): Voice Mail
F10 (was F9): Conferencing
F11 (was F5): Indirect Access
IN services for DTAG (A00002907); IN services for Telefonica
F12 (was F7): IN Services
(A00002678); IN services for China (A00002754, A00002900)
F13 (new): Party Information New chapter (edited version of TDM PD equivalent) providing one-stop
Services summarised description of support for number/name transport and display
Emergency call tracing; ETSI compliance for LI (A00002965, A00003514);
F14 (was F8): Regulatory
LI operation not affected by internet transparency; Japan trunk services
Services
(A00002756)
Multimedia services enabling blended users to have screen-based
interactive access to databases and media sources while simultaneously
F15 (new): Multimedia Services participating in a VoIP phone call, with co-ordination between the interactive
access and use of the phone; Section on Multimedia service integration via
SimRing (A89008119)

Appendix B CS2000 International Product Description
Summary of Product Description Updates for ISN07 Communication Server Capabilities

ADSL (Asymmetrical Digital Subscriber Line) access to the backbone
F16 (new): ADSL packet network for data sessions with private intranets and/or the public
internet, as supported by large carrier-located line media gateways
F17 (was F11): RAS
G: Network Fit
G1: Numbering Plan
G2: Tones
G3: Announcements MS2000 Series as enhanced replacement for UAS
GWC support for Gateway Inter-Machine Trunk (GWIMT) on PVG
G4: Network Integration
(A00003711)
Overview of public/private IP addresses and their use, including NAT,
twice-NAT and NAT traversal; Intelligent media proxy insertion, i.e. ability to
insert proxy via slave side GWC, as required for networks with relatively few
G5 (new): Internet Transparency proxies; Support for insertion of media proxy for NAT traversal into calls that
require TDM-side looparounds s on speech path, including notification of
looparound insertion to other side of call; Support for the provisioning of a
given media proxy on multiple CS2000s
Virtual Call Admission Control (VCAC) on CS2000, a QoS mechanism that
allows CS2000 to cancel calls that would overlaod provisioned limits on one
G6 (new): Call Admission Control or more Limited Bandwidth Links (LBLs) along the speech path
(A00002739)
H: OAM&P
Updated throughout to reflect increased integration and repackaging of
existing OAM&P capabilities, plus provision of OAM&P capabilities for
newly supported NEs; IEMS for single integrated interface supporting
drill-down access to NEs, EMs, EMS platforms and EMS applications,
coexisting with existing OAM&P applications either on current server
H1: Overview platform (T1400) or high-availability next-generation platform (Netra 240);
Availability of high-availability CBM (Core and Billing Manager) on Netra
240 platform as replacement for SDM on AIX platform; USP Manager client
supported on SSPFS instead of separate PC; NPM moved from CS2M to
SSPFS; Newly supported MG900 Manager; Newly supported CICM
Manager
IEMS aggregation of all EMS/NE fault data for CS2000 Core, PP8600,
MG9000, USP, PVG, GWC, STORM, SAM21, MCS, MS2000, CICM and
H2: Fault Management Session Server to provide a single consolidated fault feed; SDM log delivery
enhancements (A00001743); Integration of two sources of Session Server
logs (A00003280)
Wizard for adding NEs, EMSs, EMS platforms or EMS applications to IEMS;
H3: Configuration Provisioning templates for PVG; Dynamic changes to size of H.323
gateway; CICM flowthrough provisioning and hitless in-service upgrades;
IEMS support for UAS/MS2000 configuration requirements
AMA module 612 capture of software metering information for NAOC and
PCA (A00002638); AMA enhancements for DTAG international gateway
(A00003007); SBA real-time billing robustness; Auto-closure of billing files
(A00002744); SBA support for electronic file delivery (A00001650);
H4: Accounting MG9000 support for hardware metering (A00001927); Line hardware
metering functionality enhanced to support a range of charging intervals
ranging from 1 to 720 seconds (A00002625); CS2K NAOC trunk metering
enhancements for Spain (A00002637)


Single consolidated performance feed for PP8600, MS2000, STORM-XTS,
CICM, Session Server, MCS; Capacity increase for SDM OM delivery
H5: Performance Monitoring application (A00001742); 5 and 30 minute OM data pull for the PVG; IEMS
support for UAS/MS2000 performance management requirements;
Performance measurements for CICM
Centralised OAM&P security administration via IEMS; Security
enhancements via client firewall compatibility and strong authentication;
Centralisation of authentication database for PAM/Radius based EMSs;
Support for customer plug-ins for external authentication databases; Use of
SNMPv3 with USM and encryption for PP8600 communication; Non-DCE
option for secure FTP that allows secure FTP access to the Core via CBM
H6: Security
or SDM; UniStim security enhancements to encrypt messaging between
CICM gateway and remote clients; Web access for CICM enterprise
administration and end user control; SAM21 Manager support for user
authorisation; CLUI access to commands for GWC EM and SAM21 EM;
Remote LCI for secure access to MG9000; Same EM and APS used for
access to UAS and MS2000
Appendices
Release Contents Create new Appendix to summarise new ISN07 content in relation to ISN05.
Summary of Product Description Create new Appendix to summarise changes to be made to PD chapters
Updates and sections in order to reflect new ISN07 content.
Add references to additional relevant documents, especially ITU / IETF
References
specifications and Nortel FNs.

Appendix C References
C.1 Nortel Interface Specifications

ASPEN Protocol Specification, Version 2.1: Draft 8, October 2000
NIS D365-1 CS2000 SIP-T Network Interface Specification
NIS A246-1 ETSI ISUP V2 Compliance Statement
NIS A246-1bis APM (ETSI ISUP V2+)
NIS A246-1ter QFT over ETSI ISUP V2+
NIS A246-1quater ETSI ISUP V2+ End PINX Support
NIS A258-1 ETSI ISUP V1 Compliance Statement
NIS A215-1 PRI SIM Specification
NIS A219-1 QSIG SIM Specification
NIS A247-1 DPNSS SIM Specification
NIS D201-1 UniStim SIM Specification
NIS A245-1 IUP (BTUP) SIM Specification
NIS V208-1 V5.2 Interface Specification for CS2000
TR 94-8008 CS-1R INAP SIM Specification

CS2000 International Product Description Appendix C
Communication Server Capabilities References
C.2 Standards
IETF RFCs and IDs
RFC1157 SNMP
RFC1889 RTP
RFC2030 SNTP
RFC2045-9 MIME
RFC2327 SDP
Plus related draft:
ID draft-rajeshkumar-mmusic-sdp-atm-01
RFC2543 SIP
Plus related drafts:
ID draft-camarillo-sip-isup-bcp-00
ID draft-ietf-sip-isup-mime-00
ID draft-ietf-sip-info-method-02
ID draft-ietf-sip-183-00
ID draft-ietf-sip-privacy-02
RFC3435 MGCP
(CS2000 supports MGCP 1.0bis - 00 January 2001)
RFC2960 SCTP
Plus related draft:
ID draft-ietf-sigtran-sctp-05
RFC3015 H.248
RFC3057 IUA
Plus related draft:
ID draft-ietf-sigtran-iua-01
V5UA draft-ietf-sigtran-v5ua-03
M3UA draft-ietf-sigtran-m3ua-10
M2PA draft-ietf-sigtran-m2pa-10
PacketCable Specifications
PacketCable Network-Based Call Signaling Protocol Specification (NCS)
PKT-SP-MGCP-I10-040402 (or later issue found at www.packetcable.com)
PacketCable DQoS
PKT-SP-DQOS-I09-040402 (or later issue found at www.packetcable.com)
PacketCable Security
PKT-SP-SEC-I10-0401132 (or later issue found at www.packetcable.com)
ITU Standards
E.164 Open Dial Plan
G.703 to G.705 PCM30 carriers
G.732 PCM30 multiframe structure
H.323 Umbrella specification
H.225 Call processing for H.323
H.245 Connection control for H.323
H.450.1 Tunnelling for H.323
I.431 Physical layer requirements for ISDN PRI
Q.50 Annex A Digital Circuit Multiplication Equipment Interface
Q.701-Q.704 Message Transfer Part (MTP)
Q.711-Q.716 Signalling Connection Control Part (SCCP)
Q.723 Telephony User Part (TUP)

Appendix C CS2000 International Product Description
References Communication Server Capabilities
Q.761-Q.764 ISDN User Part (ISUP)

Q.765 ISUP and TCAP Support for QSIG Feature Transparency
Q.767 ISUP for International Use
Q.771-Q.775 Transaction Capabilities Application Part (TCAP)
Q.920-Q.921 DSS1 / ISDN Layer 2 (Data Link)
Q.931 DSS1 / ISDN Layer 3 (Basic Call Control)
Q.1214 Distributed Functional Plane for CS-1R IN
Q.1218 CS-1R Intelligent Network Application Part (INAP)
Q.1224 Distributed Functional Plane for CS-2 IN
Q.1228 CS-2 Intelligent Network Application Part (INAP)
ETSI Standards
ETS 300 356 ETSI ISUP
ETS 300 374 ETSI Core INAP
ETS 300 324 V5.1
ETS 300 347 V5.2
CEPT MoU Memorandum of Understanding on European ISDN
ETS 300 011 ETSI ISDN PRI Layer 1 (physical)
ETS 300 125 ETSI ISDN Layer 2 protocol (datalink) [Blue Book]
ETS 300 402 ETSI ISDN Layer 2 protocol (datalink) [White Book]
ETS 300 102 ETSI ISDN Layer 3 protocol (basic call control) [Blue Book]
ETS 300 403 ETSI ISDN Layer 3 protocol (basic call control) [White Book]
ETS 300 089 Calling Line Identification Presentation (CLIP) (stage 1)

ETS 300 092 Calling Line Identification Presentation (CLIP) (stage 3)
ETS 300 090 Calling Line Identification Restriction (CLIR) (stage 1)
ETS 300 093 Calling Line Identification Restriction (CLIR) (stage 3)
ETS 300 062 Direct Dialling In (DDI) (stage 1)
ETS 300 064 Direct Dialling In (DDI) (stage 3)
ETS 300 179 Advice of Charge during call (AOC-D) (stage 1)
ETS 300 180 Advice of Charge at end of call (AOC-E) (stage 1)
ETS 300 182-1 Advice of charge (AOC) (stage 3)
ETS 300 136 Closed User Group (CUG) (stage 1)
ETS 300 138-1 Closed User Group (CUG) (stage 3)
ETS 300 094 Connected Line Identification Presentation (COLP) (stage 1)
ETS 300 097-1 Connected Line Identification Presentation (COLP) (stage 3)
ETS 300 095 Connected Line Identification Restriction (COLR) (stage 1)
ETS 300 098-1 Connected Line Identification Restriction (COLR) (stage 3)
ETS 300 128 Malicious Call Identification (MCID) (stage 1)
ETS 300 130-1 Malicious Call Identification (MCID) (stage 3)
ETS 300 059 Subaddressing (SUB) (stage 1)
ETS 300 061 Subaddressing (SUB) (stage 3)
ETS 300 284 User-to-User Signalling (UUS) (stage 1)
ETS 300 286 User-to-User Signalling (UUS) (stage 3)
ETS 300 357 Call Completion on Busy Subscriber (CCBS) (stage 1)
ETS 300 359-1 Call Completion on Busy Subscriber (CCBS) (stage 3)
ETS 300 200 Call Forwarding Unconditional (CFU) (stage 1)
ETS 300 199 Call Forwarding Busy (CFB) (stage 1)
ETS 300 201 Call Forwarding No Reply (CFNR) (stage 1)
ETS 300 367 Explicit Call Transfer (ECT) (stage 1)
ETS 300 369 Explicit Call Transfer (ECT) (stage 3)

ISO Standards
IS 11572 QSIG Basic Call Control Procedures
IS 11582 QSIG Generic Functional Procedures for Supplementary Services
IS 14474 QSIG Logical/Physical Mapping
DEN/SPS-01032-1 ISUP and TCAP support for QFT (also known as Q.vpn)
DEN/SPS-01042-1 APM extensions to ISUP (also known as Q.apm)
ISO4217 MCMP Currency Tokens
ISO639-2/T MCMP Language Tokens
National Standards
PNO-ISC 006 IUP (BTUP replacement, corresponding to BTUP Version 3)
PNO-ISC 007 UK ISUP (based on ETSI ISUP V3)
BTNR 167 BTUP
TR-TSY-000317 Bellcore ISUP
T1.113.1-4 ANSI ISUP
ACIF I-ISUP ACIF G500 Signalling System No.7, Interconnection ISUP
Telstra CS30 ISUP Network Signalling Infrastructure Specification C.A.30 (ISUP)
SPIROU ART Specification SPIROU 1998-00
SSUTR2/FTUP Specification du Sous-systeme Utilisateur SSUTR2 VN4 (ST/PAA/CER/SCS/2600)
Brazilian ISUP Telebras Practice 220-250-732, ISDN - ISUP CCS7 Signalling System"
Czech ISUP National Specification of MTP and ISUP for Czech Republic and Slovak Republic
JI-ISUP Japan TTC specification JJ-90.10 Version 2 (1999)
HKTA2015 Hong Kong PRI (CR13)
YDN 021-1996 Chinese V5.2
YDN 034 Chinese PRI
BTNR 188 DPNSS

C.3 Nortel Design Documents (FNs)

Note: Within each functional category, design documents are listed by their activity
numbers. In cases where the PLS name of a design document is not the activity ID of the
corresponding software feature prefixed by A, both the PLS name and the activity ID are
provided.
General
A19012781 Codec Selection Enhancement (selection via Xlations)
A59025876 Connection Roles for Inter MGC
A59032166 Simple Network Time Protocol Support on XA-Core
A59032687 E1/T1 Coexistence
A59034587 Coexistence of UAS with EDRAM
A59038784 Multi timezone support
A59039029 G.729 a/b with RFC2833 for support of DTMF tones and T.38 fax
A59040404 International IBN Lines SOC
A89007180 UAS Capacity Increased from 150 to 300 Announcements
A89007340 Route List Conditional Selector based upon Network Fabric
A89008121 Uniport on CS2000 (RAS via CVX1800)
A89008489 RMGC Capability Ported to GWC
A00003485 CS2000 capacity increases
A00004236. GWC support for up to 5,920 endpoints for large line gateways (MG9000)
A00003933 NGSS (Next-Generation Session Server), superseding VRDN
A00002818 4-port GigE FP for PVG
CD2771, CD2397 VSP3-o with integrated OC3/STM-1 Interface
CD2762 Recycle of PVG TDM FP cards to address component obsolescence
A00003015, CD3183Carrier-grade H.248 for PVG control
A89007985 RTP Media Portal providing media proxy functionality
A00002555 Allows Servord manipulation of table LNINV GND option
A00002252 MG9000 preprovisioning support
A00003711 GWC support for Gateway Inter-Machine Trunk (GWIMT) on PVG
A00002739 Virtual Call Admissions Control (VCAC) on CS2000

A59031163 SIP-T Support for RBC (Remote Bearer Control) requests
A59032553 SIP-T to SIP-T Interworking (FN included in A59025876)
A59036800 SIP-T Enhancements (SIP-T over UDP, Interworking with MCS5200, call audits)
A89007007 CLASS Services on V5.2 with H.248
A89007026 CS2000 V5.2 with H.248 Protocol
A89008654 NCS PacketCable Compliance
A00001895 H.323 Base Application
A00003626 H.323 Support for MCDN Services
A00003627 T.38 Fax Support for International H.323
A00003575 Integration / productisation of signalling security for CMTS/MTA
A00001895 CS2000 support for H.323
A00002255 H.323 functionality via QSIG (ISO1996 version) trunks
A00002358 H.323 tunnelling
A00003627 T.38 FAX Support for International H.323
TDM Telephony Interfaces

CCS7 trunks
A59025979 SN03 ASPEN 2.1 Continuity Testing
A59026177 Per-call Echo Cancellation of CS2K CCS7 trunks
A59026201 Portuguese, Mexican, Turkish, Danish, Brazilian, Saudi and Japanese ISUP variants
A59027873 Integration and Interworking of TMX ISUPs with MMP ISUPs
A59028026 CA30 ISUP
A59029292 CS2000 Support for Czech ISUP
A59029294 Eurotrunks Enhancements (ECAN and CCD for additional ISUP variants)
A59029963 Voice-Law Indication in IAMs

A59035734 Euro Trunks Enhancements 2 (CCD, ECAN, SIP-T, COT, G.729)

A59035762 Carrier Maintenance (Group Messaging) for Multiple ISUP Variants on a Single GWC
A59036503 Telmex ISUP
A59036343 Chinese ISUP
A59039663 Hong Kong ISUP on T1/E1 including IBN line interworking
A59040486 China ISUP Interworking with ETSI ISUP
A59040657 China ISUP Interworking with IBN7 ISUP
A89008177 Brazil ISUP Enhancements and Support for Singapore ISUP and Chile ISUP
A89008212 Chinese TUP (CTUP)
A89008378 CTUP Metering
A89008404 CTUP Interworkings
A00002909 T-ISUP support
A00002908 G-ISUP support
A00003696 G-ISUP routing enhancements
A00004931 Indian ISUP
A00005164 Support for Russian ISUP and interworkings
A00002713, A00002935Enhancements to Spanish ETSI ISUP V2
A00002794 ETSI ISUP FAILMSG mapping for ACIF I-ISUP
A00003695 Support for ANSI ISUP FGD trunks
INAP
A59025340 In-Band Digit Collection Control (PRI) for INAP
A59028269 INAP oMidCall Support, SIP-T Triggering, Feature Interactions
A59033609 Line Triggering Interactions for 3WC/CFW
A59033629 INAP Support for Context Identification, Auto Continue, SCCP segmentation
A59033637 INAP SII (ServiceInteractionsIndicator) Interworking
A59034387 CM based INAP Prompt & Collect on PRI
A19012479 CS1R: CTR in Monitoring, Pre-Paid Services, Complex Announcements
A59038655 CS1R: Line Triggering Enhancements (including CCBS support)
A59039729 CS1R: Prepaid Services on China ISUP
A89008338 CS-1R Charging Enhancements
A00002907 T-INAP support
A00002934 T-INAP interworkings
A00002678 IN services for Telefonica
A00002754 China IN enhancements
A00002900 China ISUP connection to external IP
PRI
A59020206 International PRI Supported on Call Server
A59026186 PRI Echo Control based on Bearer Capabilities and ISUP Interworking
A59039647 China PRI off PVG with interworking to China ISUP
A59039128 Japan PRI (INS1500) off PVG T1 carriers with interworking to JI-ISUP
A59039654 Hong Kong PRI on T1 including IBN line interworking
A89008422 China ISDN on CS2K hybrid switch
QSIG
A59038835 QSIG on CS2000
Analogue Subscriber Lines

A59034339 V5.2 Control
A59038965 V5.2 flow control
A59038943 V5.2 Audits and Alarms
A59038988 V5.2 ETSI Enhancements (for China) and Signaling Procedure Verification
A89009559 CS2000 V5.2 Interface and Link Enhancements

Analogue Subscriber Line Features
A00001351 SACB Support for MADN Secondary Members
A00000439 UAS Support for DMCT (Denied Malicious Call Termination) Service
A59033132 Succession Analogue Services II on Motorola MTAs
A59034339 Services: V5.2 Line Services
A59034502 CEPT Line Features

A59035140 Cable Analogue Services II

A59038854 CCBS support for cable lines
A59039130 CFRA support for cable lines
A59039138 VMWI via NCS for cable lines
A59039741 Networked CNAMD support for cable lines
A59040478 SCWID on CEPT lines
A59038837 Open Dial Plan enhancements on CS2000 (AR support)
A89007007 CLASS Services on V5.2 with H.248
A89008399 China Line Features
A89008956 Call Forwarding Indication (CFIND) for Succession Lines
A00002755 China line services (full DMS-100i equivalence)
A00002901 Enhanced Meet-Me Conference service
A00002654 CEPT CCB support ed as CLASS AR
A00002655 CEPT ACRJ support
A00002610 CEPT features CFF, CDTA, WML, SCS, SCL, CCBS, WUC and DTM
A00002639 Enhancements to existing CEPT ICWT service
A00002640 Services enhanced/provided on CEPT lines
A00002641 Enhancements to CEPT ILR service
A00002642 Enhancements to CEPT 3WC and Call Transfer
A00002365 Call Waiting Ringback Tone (ANATEL 252 Compliance)
A00002761. ACRJ functionality for HK
A00002558 LDI Display for CLASS phones
A00003629 Service support for gateways supported using H.323
A00002330 Verification of V5.2 support for additional services
A00003626 MCDN feature transparency

A89008946 Redirecting Number Enhancements for ETSI PRI
DPNSS
A00001965 DPNSS Feature Transparency (DFT)
Indirect Access
A59037739 Tone Burst On Answer for Indirect Access
A59034387 CM based Prompt & Collect on PRI for 2-Stage Indirect Access
Regulatory Services
A59024510 DNBD (LI) on CS2000
A59024902 LI (Lawful Interception) support for Incremental Services - Completion
A59028707 CS2000 LI support for incremental services - Phase 2
A59030731 German National Regulatory Services
A59034497 Payment Ceiling for Analogue Lines
A59035246 LI Enhancements for Packet Network Calls
A59036326 LI for CEPT Services (CW, CHD, 3PTY,CFU, CFB, CFNR)
A59040499 Hong Kong regulatory features (CLI enhancements)
A59040504 Hong Kong regulatory features (MCT enhancements)
A59040509 Hong Kong regulatory features (CFwd restriction/prevention)
A59040141 China ISUP Handling of Operator Calls and Emergency Calls
A89007355 LI Call Content in Mono Mode
A89007360 Call Data Delivery via FTP TCP/IP
A89007454 NAOC (Network Advice of Charge) Regulatory Enhancements
A89007461 PCA (Payment Ceiling Advice) Regulatory Enhancements
A00002965 SDM aspects of ETSI compliance for LI (HI1 and HI2 interfaces)
A00003514 Core aspects of ETSI compliance for LI (ISUP protocol changes for subaddressing)
A00002756 Japan trunk services
Multimedia Services
A89008119 Multimedia service integration via SimRing

Network Fit
Tones
A19009891 Complex Periodic Tone Flexibility for ISUP
A19012781 Codec Selection via Translations
A19013546 Simplification / Standardisdation of Announcement Datafill
A59022704 Table TONES Enhancement
A89009351 Market of Office Decoupling for Japan
A89009671 Market of Office Removal Phase I
OAM&P
A59029095 International Auto-Provisioning of LNINV
A59039985 Subscriber Usage Billing enhancements for AR/ARDDN
A59040148 China Trunk Metering
A89009303 SERVORD+ Support for CHG and EXB Commands
A89007725 QoS OMs for Trunk Groups
A89007781 Quality of Service (QoS) Reporting Provisioning
A89008458 China-Specific OMs on ISN06
A00002638 AMA capture of software metering information for NAOC and PCA
A00003007 AMA enhancements for DTAG international gateway
A00002744 Auto-closure of billing files
A00001650 SBA support for electronic file delivery
A00001927. MG9000 support for hardware metering
A00002625 CS2000 metering enhancements for tariff model compliance
A00002637 CS2K NAOC trunk metering enhancements for Spain
A00001742 Capacity increase for SDM OM delivery application (OMDD)
A00001743 SDM log delivery enhancements (SCC2)
A00003280 Logs for SIP / SIP-T


Cs2000 Mega

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cs2000 Mega

Uploaded by

Copyright:

Available Formats

International Succession Networks

CS2000 International Product Description

Issue ISN07_v3 (approved), 17 August 2004

The ISN07 Product

Issue ISN07_v3 (approved) PROPRIETARY Page

Document Purpose and Structure

Relationship with Other Documents

Issue ISN07_v3 (approved) PROPRIETARY Page

Chapter A1 Market Overview 2

Chapter A2 Network Overview 3

Chapter A3 Product Overview 21

Issue ISN07_v3 (approved) PROPRIETARY Page

Chapter B1 CS2000 Hardware 29

Chapter B2 CS2000 Support for Media Gateways 96

Chapter B3 CS2000 Support for Media Servers 133

Issue ISN07_v3 (approved) PROPRIETARY Page

Chapter B5 Media Proxies 153

Chapter B6 Multimedia Communication Server (MCS52000) 165

Chapter C1 Software Loads 172

Chapter C2 Trunk and Line Datafill 182

Chapter C3 Translations and Routing 204

Page PROPRIETARY Issue ISN07_v3 (approved)

Chapter D1 Overview of Packet Telephony Protocols 231

Chapter D2 SIP and SIP-T 243

Chapter D3 H.248 256

Chapter D4 ASPEN 280

Chapter D5 H.323 288

Chapter D6 UniStim 300

Chapter D7 NCS 308

Chapter D8 MGCP 319

Chapter D9 MPCP 325

Chapter D10 IUA 329

Chapter D11 V5UA 332

Chapter D12 MTP Adaptation Protocols (M3UA and M2PA) 338

Chapter D13 DSM-CC 342

Chapter D14 OAM&P Protocols 347

Issue ISN07_v3 (approved) PROPRIETARY Page

Chapter E1 Overview of Support for Telephony Interfaces 357

Chapter E2 CCS7 Interfaces 368

Chapter E3 INAP 422

Chapter E4 PRI Access Interface 445

Page PROPRIETARY Issue ISN07_v3 (approved)

E4.5 Overview of Feature Set Support 460

Chapter E5 QSIG VPN Interface 461

Chapter E6 DPNSS Interface 483

Chapter E7 IBN Lines 490

Chapter E8 CentrexIP Lines 508

Chapter F1 Feature Support Overview 515

Chapter F2 Analogue Subscriber Line Services 530

Issue ISN07_v3 (approved) PROPRIETARY Page

F2.2.6 Uniform Call Distribution (UCD) 536

Chapter F3 Feature Support for CentrexIP Clients 558

Chapter F4 ISDN Supplementary Services 565

Chapter F5 QSIG Services 577

Chapter F6 DPNSS Features 586

Page PROPRIETARY Issue ISN07_v3 (approved)

Chapter F7 APM Feature Transparency 598

Chapter F8 VPN 605

Chapter F9 Voice Mail 624

Chapter F10 Conferencing 628

Chapter F11 Indirect Access 631

Issue ISN07_v3 (approved) PROPRIETARY Page

Chapter F12 IN Services 652