cs2000PDISN07 07 03

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. The VToATM (Voice Trunking over ATM) solution is based on an ATM backbone network with AAL2 (ATM Adaptation Layer 2) bearer connections.
VoATM
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) 17 August 2004 PROPRIETARY Page
Nortel Networks
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: Part B: Part C: Part D: Part E: Part F: Part G: Part H: Introduction Hardware Software Packet Telephony Protocols TDM Telephony Interfaces Features and Services Network Fit 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.
Issue ISN07_v3 (approved) 17 August 2004
Nortel Networks
PROPRIETARY
Page
ii
Table of Contents
Part A Overview
Chapter A1 Chapter A2 Market Overview Network Overview A2.1 MEGACO Network Architecture A2.2 CS2000 Implementation of MEGACO Architecture A2.3 CS2000 Support for Network Architecture A2.3.1 Hardware Support A2.3.2 Software Support A2.4 The Backbone Packet Network A2.4.1 Network Characteristics A2.4.2 PSTN Equivalence for Packet Networks Product Overview A3.1 Configurations Available A3.2 Capacity A3.3 Telephony Interfaces Supported A3.4 Interworkings between Telephony Interfaces 2 3 3 5 7 7 13 19 19 19 21 21 22 22 25
Chapter A3
Nortel Networks
PROPRIETARY
Page
iii
Part B Hardware
Chapter B1 CS2000 Hardware B1.1 Overview B1.2 Processor Complex (Core) B1.2.1 XA-Core B1.2.2 Processor Complex for CS2000-Compact B1.3 Internal Communication (CS LAN and MS) B1.4 Gateway Controllers (GWCs) B1.5 Session Server B1.6 CCS7 Signalling Terminations B1.6.1 USP (Universal Signalling Point) B1.6.2 FLPP Signalling Peripheral B1.7 OAM&P Hardware B1.8 CS2000 Interworking with Legacy Peripherals B1.8.1 Hybrid Configurations using Looparound Trunks B1.8.2 Hybrid Configurations using the IW-SPM B1.9 Hardware Packaging B1.9.1 CS2000 Cabinets B1.9.2 Typical Cabinet Lineups CS2000 Support for Media Gateways B2.1 Introduction B2.2 Categorising Media Gateway Capabilities B2.3 PVG (Packet Voice Gateway) Trunk Gateways B2.4 PVG as a V5.2 Gateway B2.5 H.323 Gateways B2.6 Mediant 2000 Trunk Gateway B2.7 Westell DPNSS Gateway B2.8 Carrier-Located Line Media Gateways B2.9 Line Media Gateways on Customer LANs B2.10 Line Media Gateways on Cable Access Networks B2.11 CVX1800 Media Gateway for RAS CS2000 Support for Media Servers B3.1 Introduction B3.2 AudioCodes MS2000 Series (MS2010 / MS2020) B3.3 Universal Audio Server (UAS) CentrexIP Remote Clients and the CentrexIP Client Manager B4.1 Network Configuration for CentrexIP Client Access B4.2 CentrexIP Clients and their Capabilities B4.3 CentrexIP Client Manager (CICM) 29 30 34 34 38 42 53 71 72 73 78 81 89 89 90 93 93 94 96 96 98 99 111 115 116 118 119 123 126 130 133 133 135 138 144 144 146 149
Chapter B2
Chapter B3
Chapter B4
Nortel Networks
PROPRIETARY
Page
iv
Chapter B5
Media Proxies B5.1 Media Proxy Functions B5.1.1 Network Address Translation (NAT) B5.1.2 NAT Traversal B5.2 RTP Media Portal Multimedia Communication Server (MCS52000) B6.1 Network Role of MCS5200 B6.2 MCS5200 Components B6.3 MCS5200 Connectivity B6.4 CS2000 / MCS5200 Combined Configuration
153 153 153 154 156 165 165 166 169 170
Chapter B6
Part C Software
Chapter C1 Software Loads C1.1 CS2000 Core Load C1.2 Loads for Other CS2000 Components C1.3 Loads for Media Gateways and Servers C1.4 OAM&P Software Trunk and Line Datafill C2.1 The Purpose of Datafill C2.2 Trunk Group Provisioning C2.3 Signalling Link Provisioning C2.4 Provisioning GWC Units C2.5 Provisioning Gateways, Carriers and Trunk Endpoints C2.6 Provisioning Inter-CS Trunks C2.7 Provisioning Lines C2.8 Provisioning Gateways and Line Endpoints C2.9 Provisioning Tones and Announcements Translations and Routing C3.1 Overview C3.2 NCOS Screening C3.3 IBN Translations C3.4 Indirect Access to Universal Translations C3.5 Universal Translations C3.6 Codec Selection via Translations C3.7 Routing C3.7.1 Line Routing and Selection C3.7.2 Trunk Routing and Selection C3.7.3 Routing to Treatment C3.8 Support for CCD (Clear Channel Data) Calls C3.9 Order Codes for Translations and Routing Software 172 173 176 178 179 182 182 183 185 189 190 191 196 200 203 204 205 206 207 209 210 216 218 218 219 227 229 229
Chapter C2
Chapter C3
Page
Nortel Networks
PROPRIETARY
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 SIP and SIP-T H.248 ASPEN H.323 UniStim NCS MGCP MPCP IUA V5UA MTP Adaptation Protocols (M3UA and M2PA) DSM-CC OAM&P Protocols D14.1 SNMP (Simple Network Management Protocol) D14.2 Configuration Protocols (BOOTP, DHCP, TFTP) 243 256 280 288 300 308 319 325 329 332 338 342 347 348 352
Chapter D2 Chapter D3 Chapter D4 Chapter D5 Chapter D6 Chapter D7 Chapter D8 Chapter D9 Chapter D10 Chapter D11 Chapter D12 Chapter D13 Chapter D14
Nortel Networks
PROPRIETARY
Page
vi
Part E Telephony Interfaces

Chapter E1 Overview of Support for Telephony Interfaces E1.1 CCS7 Trunk Interfaces E1.2 Intelligent Network Interfaces E1.3 Access Interfaces E1.4 VPN Interfaces E1.5 Basic Analogue Subscriber Line Interfaces E1.6 CentrexIP Lines E1.7 Interworking in a Packet Network Environment CCS7 Interfaces E2.1 Introduction E2.2 TDM and Packet Network Implementations of CCS7 E2.3 ISDN User Part (ISUP) Support E2.3.1 Overview E2.3.2 ISUP Standards and Variants E2.3.3 CS2000 Support for ETSI / ITU ISUP E2.3.4 CS2000 Support for ANSI ISUP Variants E2.3.5 UK ISUP Support E2.3.6 SPIROU (French ISUP) Support E2.3.7 Interworking Support for ISUP Variants E2.3.8 Software Order Codes for ISUP E2.4 Telephony User Part (TUP) Support E2.4.1 IUP / BTUP Support E2.4.2 SSUTR2 / FTUP Support E2.4.3 CTUP Support E2.4.4 Software Order Codes for TUP E2.5 MTP, SCCP and TCAP Support INAP E3.1 357 358 360 361 362 363 363 364 368 368 371 381 381 382 386 395 398 400 401 405 406 406 410 413 415 416 422 422 422 423 424 426 430 430 438 441 442 444 444 445 445 450 455 460
Chapter E2
Chapter E3
E3.2
E3.3 E3.4 E3.5 Chapter E4
Functional Description E3.1.1 IN Functional Elements E3.1.2 INAP Specifications E3.1.3 Peer-to-Peer Communication using INAP E3.1.4 Interaction between Call Processing and IN CS2000 Implementation E3.2.1 INAP Operation Support E3.2.2 Detection Point Support E3.2.3 Support for Application Context Negotiation INAP Signalling Interworkings Overview of Feature Set Support Order Codes for INAP
PRI Access Interface E4.1 Functional Description E4.2 CS2000 Implementation E4.3 Capabilities Supported E4.4 Limitations
Page
vii
Nortel Networks
PROPRIETARY
E4.5 E4.6 Chapter E5
Overview of Feature Set Support Order Codes for PRI
460 460 461 461 474 482 482 482 483 483 485 489 490 490 491 491 493 497 499 507 507 507 508 508 509 512
QSIG VPN Interface E5.1 Functional Description E5.2 CS2000 Implementation E5.3 Limitations E5.4 Overview of Feature Set Support E5.5 Order Codes for QSIG DPNSS Interface E6.1 Functional Description E6.2 CS2000 Implementation E6.3 Order Codes for DPNSS IBN Lines E7.1 Functional Description E7.2 CS2000 Implementation E7.2.1 Lines off Large Carrier-Located Gateways E7.2.2 Cable Lines off MTA Gateways E7.2.3 Customer LAN Lines E7.2.4 V5.2 PSTN Lines E7.3 Line Provisioning E7.4 Overview of Feature Set Support E7.5 Order Codes for Analogue Lines CentrexIP Lines E8.1 Functional Description E8.2 CentrexIP Clients and their Capabilities E8.3 Network Configuration for CentrexIP Client Access
Chapter E6
Chapter E7
Chapter E8
Part F Features and Services

Chapter F1 Feature Support Overview F1.1 Feature Sets Currently Supported F1.2 Feature Support in a Packet Network Environment Analogue Subscriber Line Services F2.1 Introduction F2.1.1 Assigning Services to Lines F2.1.2 Service Packaging F2.2 Service Categories and Services Available F2.2.1 Call Barring and Restrictions F2.2.2 Speed Calling Services F2.2.3 Call Forward Services F2.2.4 Call Handling F2.2.5 Hunt Groups
PROPRIETARY
515 515 518 530 530 530 531 532 532 533 533 535 536
Page
Chapter F2
Nortel Networks
viii
F2.3 F2.4 F2.5 F2.6 Chapter F3
F2.2.6 Uniform Call Distribution (UCD) F2.2.7 Automatic Call Distribution (ACD) F2.2.8 Voice Mail F2.2.9 Party Information Services F2.2.10 Data Download F2.2.11 Screening Services F2.2.12 Call Completion / Call Return F2.2.13 Regulatory Services F2.2.14 Miscellaneous Services CEPT Services and the CEPT Line Option Service Availability with Different Line Types Service Support on Interworking Order Codes for Analogue Line Services
536 537 542 543 545 546 547 548 549 550 552 556 556 558 558 559 560 565 565 566 567 574 575 576 577 577 578 578 578 579 582 582 582 583 584 585 585
Feature Support for CentrexIP Clients F3.1 Feature Categories Supported F3.2 Feature Assignment and Activation for CentrexIP Clients F3.3 Features and Options Supported ISDN Supplementary Services F4.1 Introduction F4.2 MoU1 Service Support F4.3 MoU2 Service Support F4.4 Non-ETSI ISDN Services F4.5 Networked Support for Supplementary Services F4.6 Order Codes for ISDN Supplementary Services QSIG Services F5.1 Overview F5.2 Features Supported as Part of QSIG Basic Call F5.3 QSIG Additional Network Features F5.3.1 Transit Counter F5.4 VPN Support via QSIG Feature Transparency (QFT) F5.5 ISDN Supplementary Services F5.5.1 Connected Party Number (COLP/COLR) F5.5.2 Advice of Charge (AOC) F5.5.3 Call Completion (CCBS / CCNR) F5.6 German Network Features F5.7 Service Support on Interworking F5.8 Order Codes for QSIG Services
Chapter F4
Chapter F5
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
Page
ix
Nortel Networks
PROPRIETARY
Chapter F7
APM Feature Transparency F7.1 Overview F7.2 Application Contexts Supported by CS2000 F7.2.1 Services Supported via APM AC 1 (PSS1) F7.2.2 Services Supported via APM AC 3 (AOC) F7.2.3 Services Supported via APM AC 124 (Nortel) VPN F8.1 F8.2
598 598 600 600 602 603 605 605 605 606 607 607 608 609 611 612 612 615 621 622 623 624 624 626 626 626 627 628 628 629 630 630 631 631 632 635 636 640 643 644 649 650 651
Chapter F8
F8.3
F8.4 F8.5 Chapter F9
Introduction F8.1.1 VPN Infrastructure Options and Benefits F8.1.2 VPN Access Options and Benefits VPN Telephony Overview F8.2.1 VPN Functional Elements F8.2.2 VPN Call Types F8.2.3 VPN Services F8.2.4 Flexible Translations and Routing Protocols Used for VPN F8.3.1 Access Signalling Support F8.3.2 Network Signalling Support F8.3.3 Trunk and Access Signalling Options Interaction with MCS5200 to Support VPN Order Codes for VPN
Voice Mail F9.1 Overview F9.2 Voice Mail Interfaces F9.2.1 Message Desk Interface F9.2.2 Subscriber Interface F9.4 Order Codes for Voice Mail Conferencing F10.1 Overview F10.2 Network Configuration for Conferencing F10.3 Using Conferencing Capabilities F10.4 Order Codes for Conference Services Indirect Access F11.1 The Purpose of Indirect Access F11.2 Call Completion Scenarios F11.3 Different Types of Indirect Access F11.3.1 CLI Checking via Table DNSCRN F11.3.2 Authcode Checking via Table AUTHCDE F11.4 Supporting Interfaces and Call Flows F11.4.1 Call Flows for CLI-Based Indirect Access F11.4.2 Call Flow for Authcode Access F11.5 Indirect Access Billing F11.6 Order Codes for Indirect Access
Chapter F10
Chapter F11
Nortel Networks
PROPRIETARY
Page
Chapter F12
IN Services F12.1 Introduction F12.2 Service Support Capabilities F12.3 Creating and Deploying Services F12.4 Interaction between IN and Non-IN Features F12.5 Order Codes for IN Services
652 652 653 656 657 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 Regulatory Services F14.1 Special Call Types F14.1.1 Emergency Calls F14.1.2 Priority Calls F14.2 Call Tracking and Supervision Features F14.2.1 Malicious Call Identification (MCID) F14.2.2 Lawful Interception (LI) F14.3 Charging and Billing Features F14.3.1 Network Advice of Charge (NAOC) F14.3.2 Payment Ceiling for Analogue Lines (PCA) F14.3.3 Notification of Time and Charge (NTC) F14.4 Network Interconnect Features F14.4.1 Basic Interconnect F14.4.2 Indirect Access F14.4.3 Carrier Selection F14.4.4 Carrier Name Notification (CNN) F14.4.5 Account Code (ACCT) F14.4.6 Number Portability F14.5 Miscellaneous Features F14.5.1 Call Forward Restrictions for Hong Kong F14.6 Order Codes for Regulatory Services Multimedia Services for Blended Users F15.1 Introduction F15.2 CS2000 Blended User Configuration F15.3 Call Setup Sequences F15.4 Specific Services Supported ADSL Data Sessions RAS (Remote Access Service) F17.1 Overview F17.2 Virtual Points of Presence (VPOPs) 693 694 694 696 697 697 699 703 703 704 705 706 706 706 706 706 706 707 711 711 711 712 712 713 715 718 719 720 720 722
Chapter F14
Chapter F15
Chapter F16 Chapter F17
Page
xi
Nortel Networks
PROPRIETARY
Part G Network Fit

Chapter G1 Numbering Plan G1.1 Public Numbering Plan G1.1.1 Support for Geographic Numbers G1.1.2 Non-Geographic Numbers and Services G1.1.3 International Calls G1.1.4 CS2000 Inpulsing/Outpulsing Capacity G1.1.5 Number Portability G1.1.6 ODP and Services G1.1.7 Order Codes for Open Dial Plan Support G1.2 Private Numbering Plans CS2000 Support for Tones G2.1 Overview G2.2 Classifying and Identifying Tones G2.3 CS2000 Implementation G2.3.1 Identifying Tones G2.3.2 Requesting the Playing of a Tone G2.4 Media Gateway Support for Tones CS2000 Support for Announcements G3.1 Announcement Characteristics G3.2 The Role of the MS2000/UAS Media Server G3.3 GWC - Media Server Communication via H.248 G3.4 Announcement Capacity G3.5 Announcement Datafill G3.6 The Audio Provisioning Server (APS) 724 724 724 726 726 727 727 728 730 731 733 734 735 738 738 738 739 742 743 744 745 746 746 747
Chapter G2
Chapter G3
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 IP Addressing and Internet Transparency G5.1 Public and Private IP Addresses G5.2 Communication between Address Domains G5.3 Network Address and Port Translation G5.4 NAT Traversal 756 756 757 759 760
Chapter G5
Nortel Networks
PROPRIETARY
Page
xii
G5.5 Chapter G6
IP Addressing Example for CS2000 Solutions
762 764 764 765 765 767 767
CAC (Call Admission Control) G6.1 The Need for Call Admission Control G6.2 CS2000 Support for Virtual Call Admission Control G6.2.1 Logical Network Model G6.2.2 GWC Support for LBL Traversal and VCAC G6.3 Order Codes for VCAC
Part H OAM&P
Chapter H1 Overview of OAM&P for CS2000 Solutions H1.1 Logical OAM&P Architecture H1.1.1 The TMN Hierarchy H1.1.2 EMs and Management Applications Supported H1.2 Physical OAM&P Architecture H1.2.1 Trusted Access to NEs via the OAM&P VLAN H1.2.2 External cccess to the OAM&P VLAN H1.2.3 Software Packaging for EMs and Applications H1.3 Access to EMs and Management Applications H1.3.1 IEMS H1.3.2 User Access to IEMS, EMs and Applications Fault Management H2.1 Summary of Fault Management Capabilities H2.2 Alarm Reporting H2.3 Fault Reporting via Logs H2.4 Other Fault Reporting Mechanisms H2.5 Fault Isolation and Correction (Maintenance) Configuration H3.1 Summary of Configuration Capabilities H3.1.1 Commissioning H3.1.2 Service Activation H3.2 Hardware Commissioning H3.3 Trunk Provisioning H3.4 Line Provisioning H3.5 V5.2 Provisioning H3.6 Connections to Provisioning Applications Accounting H4.1 Summary of Accounting Capabilities H4.2 CS2000 Core Support for Billing H4.2.1 Call Recording Formats Supported H4.2.2 Automatic Message Accounting (AMA) H4.2.3 Station Message Detail Recording (SMDR) H4.2.4 Creation and Transfer of Billing Records H4.2.5 Controlling the Generation of Billing Records
PROPRIETARY
769 770 770 771 774 774 776 777 782 782 783 784 784 788 789 793 794 795 795 795 796 798 799 800 801 802 803 803 804 804 805 819 819 820
Chapter H2
Chapter H3
Chapter H4
Page
xiii
Nortel Networks
H4.3
H4.2.6 Metering / Advice Of Charge (AOC) H4.2.7 Order Codes for Accounting Support Core Manager SBA Support for Billing H4.3.1 Overview H4.3.2 Closing Billing Files Ready for Transfer H4.3.3 File Transfer Options H4.3.4 File Transfer Performance H4.3.5 AMA Search via AMADUMP
821 822 823 823 824 824 825 825 826 826 830 835 836 837 838 838 840 841
Chapter H5
Performance Management H5.1 Summary of Performance Monitoring Capabilities H5.2 Performance Monitoring via OMs H5.3 Performance Monitoring via PMs H5.4 QoS Monitoring Security (OAM&P Access Control) H6.1 Network Architecture for Security H6.2 Security Overview H6.3 User Authentication and Account Administration H6.4 Secure Remote Access
Chapter H6
Appendices
Appendix A ISN07 Release Contents A.1 Overview A.2 Hardware A.3 Software A.4 Packet Telephony Protocols A.5 Telephony Interfaces A.6 Features and Services A.7 Network Fit A.8 OAM&P Summary of Product Description Updates for ISN07 References C.1 Nortel Interface Specifications C.2 Standards C.3 Nortel Design Documents (FNs) 843 844 844 849 849 852 856 862 864 871 877 877 878 881
Appendix B Appendix C
Nortel Networks
PROPRIETARY
Page
xiv
Abbreviations
3PC 3WC AC ACRJ AAL AAL2 AAL5 ACIF ADSL AISUP A-law AMA ANF ANSI AO AOC API APM APS AR ARDDN ARP ASN ASPEN ATA ATM AUL AVT AXU BCP BCT BDF BHCA BICC BML BNS Third-Party Core (Motorola N765 processors used by CS2000-Compact) Three-Way Call (line service) Audio Controller (GWC for UAS) Anonymous Call Rejection (line service) ATM Adaptation Layer ATM Adaptation Layer for VBR real-time traffic; can be used for voice ATM Adaptation Layer for lightweight VBR data traffic (also called SEAL) Australian Communication Industry Forum (standards body) Asymmetrical Digital Subscriber Line Australian ISUP (IBN7-based agent used to support Malaysian ISUP V1) International PCM standard used for speech path encoding/companding Automatic Message Accounting (for billing calls) Additional Network Feature (type of QSIG service) American National Standards Institute Alternative Operator (competing with an established PTT) Advice Of Charge (ISDN service) Application Program Interface (for standard calls to software functionality) Application Transport Mechanism (for feature transparency) Audio Provisioning Server (for UAS provisioning) Automatic Recall Automatic Recall of Diallable Directory Number Address Resolution Protocol (finding the Ethernet address for an IP address) Abstract Syntax Notation Proprietary device control protocol used to control PVG media gateways ASCII Terminal Access (OAM&P application) Asynchronous Transfer Mode Automatic Line (line service) Audio / Video Transport (IETF working group) Alarm Cross-Connect Unit (connectivity for optional OAU) Best Common Practice Bearer Channel Tandeming (for LI) Binary Distribution Format Busy Hour Call Attempts Bearer Independent Connection Control (ISUP with packet extensions) Buriness Management Layer (in TMN hierarchy) Billing to the Nearest Second (for NAOC)
PROPRIETARY Page
Nortel Networks
xv
BOOTP BSL CAC CBM CBR CC CCB CCBS CCD CCF CCF CCITT CCS7 CCW CDP CEM CES CFB CFD CFDVT CFNA CFNR CFU CG4500E CGP CHD CIC CIC CICM CID CLASS CIEC CLF CLI CLLI CLUI CM CMT CMTS CNAB CNAMD CND CNDB CO LAN COPS CORBA cPCI CPE CPS CR CRCX CRR CRR
Bootstrap Protocol Bar-Separated Log Connection Admission Control Core and Billing Manager (successor / alternative to SDM) Constant Bit Rate Call Control CEPT Call Back (implemented via AR) Call Completion to Busy Subscriber Clear Channel Data (as used for ISDN data calls) Call Control Function (call processing model used for IN) Call Control Frame (PTE2000 housing CS2000-Compact Core) Consultative Committee for International Telephone / Telegraph (now ITU) Common Channel Signalling System No. 7 (also called SS7) Cancel Call Waiting (line service) Charge Determination Point (for NAOC) Common Equipment Module (IW-SPM controller card) Circuit Emulation Service Call Forward on Busy (line service) Call Forward on DoesntAnswer (line service) Call Forward on DoesntAnswer with Variable Timer (line service) Call Forward on No Answer (see CFD) Call Forward on No Reply (see CFD) Call Forward Unconditional (line service) Hardware platform for MTA line gateway Charge Generation Point (for NAOC) Call Hold (line service) Carrier Identification Code (as used in IA carrier selection) Circuit Identification Code (in MTP routing label) CentrexIP Client Manager Correlation ID Custom Local Area Signalling Services Chosen Intermediate Exchange Carrier Calling Line Flash (MCID) Calling Line Identification (caller number) Common Local Language Identifier (identifying trunk destination) Command Line User Interface Computing Module (alternative name for XA-Core or Compact 3PC) CS2000 Management Tools Cable Modem Termination System Calling Name Delivery Blocking (line service) Calling Name Delivery (line service) Calling Number Delivery (line service, 10-digit CLIs only) Calling Number Delivery Blocking (line service) Central Office LAN (name previously used for CS LAN) Common Open Policy Service (GWC - CMTS signalling for CAC) Common Object Request Broker Architecture (as used by PMSS) Compact Personal Computer Interface Customer Premises Equipment Carrier Pre-Selection (as used in indirect access) Centralised Replicator (used to implement LI BCT for packet network calls) Create Connection (ASPEN message) Conditional Re-Routing (of ISUP call if congestion is encountered) Call Retrieval Request (for voice mail)
Page
xvi
Nortel Networks
PROPRIETARY
CSP CS CS CS LAN CS2000 CS2E CS2M CSP CSV CUG CWT CXR DCE DCOS DCP DDMS DDN DHCP DLCX DM DMC DMZ DNS DN DOCSIS DOR DPNSS DPT DQoS DS DSLAM DSM-CC DSS1 DSP DTC DTD DTM DTMF
Communication Services Platform (CS2000 Base / Telecom layer software) Call server (alternative name for Communication Server) Comunication Server Communication Server LAN (as used to connect CS2000 components) Nortel Networks Communication Server described in this document SDM software load supporting CS2000 Core Manager CS2000 Management Tools (Sun server load supporting EMs) Carrier Selection Parameter (for inter-network use) Comma-Separated Values (format for data file) Closed User Group Call Waiting (line service) Call Transfer (line service) Distributed Computing Environment Data Collection Operations System (passive collection of performance OMs) Device Control Protocol DMS Data Management System (OAM&P application) Delivery of Diallable Number (line service) Dynamic Host Configuration Protocol Delete Connection (ASPEN message) Domain Management Device / Media Control (signalling between GWC and gateway) Demilitarised Zone (network supporting public address domain) Domain Name Server Directory Number Data Over Cable System Interface Specification (CMTS - MTA signalling) Denied Origination (outgoing call barring) Digital Private Network Signalling System Dynamic Packet Trunk (for inter-CS communication via SIP-T or BICC) Dynamic Quality of Service Data Store (XA-Core memory used to store customer data) Digital Subscriber Line Access Multiplexer Digital Storage Media Command and Control (protocol used for RAS) Digital Signalling System No1 (Q.931) Digital Signal Processor Digital Trunk Controller Document Type Definition (for XML file) Denied Termination (incoming call barring) 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
Nortel Networks
PROPRIETARY
Page
xvii
FCM FLPP FP FQDN FSM G.703 G.711 G.726 G.729 GARP GEM GigE GoS GUI GW GWC H.248 H.323 HFC HIOP HLM IA IAC IAD IAM IAW IBL IBN IBN7 ICE ID IE IEC IEMS IETF I-ISUP IMS IN INAP IOM IOP IP IP IPSP ISDN ISM ISN ISN07 ISP ISUP
Fabric Control Message (used to co-ordinate GWCs) Fiberised Link Peripheral Processor (SG terminating CCS7 signalling links) Function Processor Fully Qualified Domain Name (identifies an IP network host) Finite State Machine ITU-T standard for PCM30 interface (E1 carriers) ITU-T standard for A-law and m-law PCM of speech transported at 64Kb/s Compression codec supported for VoAAL2 solutions Compression code supported with effect from ISN05 Gratuitous ARP (broadcast indicating change in IP/MAC address mapping) Gigabit Ethernet Module (packet-side interface for IW-SPM) Gigabit Ethernet Grade of Service (resilience / availability of packet network) Graphical User Interface Gateway Gateway Controller (CS2000 peripheral housed in SAM21) Standard device control protocol for media gateway control (used for UAS) Set of ITU-defined IP protocols for conveying voice and other media types Hybrid Fibre Coax (used to support digital cable access networks) High-capacity XA-Core IOP supporting Ethernet (standard since ISN03) Higher-Level Management (OAM&P applications covering multiple NEs) Indirect Access Integrated Access Cable (network solution supported by CS2000) Integrated Access Device (combined line media gateway and WAN access device on customer premises) Initial Address Message (initiating ISUP or TUP call) Integrated Access Wireline (network solution supported by CS2000) Initial Boot Load (for GWC to notify GWC EM when installed) Integrated Business Network (support for proprietary value-added services) Proprietary variant of ANSI CCS7, providing networked support for IBN IPConnect Call Engine (alternative name for SoftSwitch or CS3000 TSS) Internet Draft (proposed IETF standards document) Information Element (ISDN parameter) Inter-Exchange Carrier Integrated Element Management System Internet Engineering Task Force (standards body for internet protocols) Interconnect ISUP Interactive Multimedia Server (pre-ISN07 name for MCS5200) Intelligent Networking Intelligent Networks Application Part (CCS7 protocol) Input-Output Module (datalink used to bring CS2000 into service) Input-Output Processor (XA-Core component) Internet Protocol Intelligent Peripheral (supports IN SRF functionality) IP Signalling Point (CCS7 node with IP signalling connection) Integrated Services Digital Network Integrated Service Module (used to house IOMs) International Succession Networks International Succession Networks Release 07 (described in this document) Internet Service Provider ISDN User Part (CCS7 protocol)
Page
xviii
Nortel Networks
PROPRIETARY
ITU-T ITX IU IUA IVR IW-SPM Kb/s L2TP LAN LCI LCR LDAP LEA LEN LI LIS LMM LNP LNR LTM M2PA M2UA M3UA MAC Mb/s MCCS MCID MCMP MCS5200 MDCX MEGACO
International Telecommunication Union-Telecommunications Internet Telephony Extender (links between MG9000 shelves) Interface Unit (generic term for LIU and EIU) ISDN User Adaptation (IETF protocol to carry Q.921 user info, e.g. Q.931) Interactive Voice Response Interworking SPM Kilobits per second Layer 2 Tunneling Protocol (as used for RAS calls through packet network) Local Area Network Local Craft Interface Least Cost Routing Lightweight Directory Access Protocol Law Enforcement Agency Line Equipment Number (virtual physical address associated with line DN) Lawful Interception (regulatory service allowing an LEA to monitor calls) Link Interface Shelf (in FLPP) Line Maintenance Manager Local Number Portability Last Number Redial (line service) Line Test Manager
MTP2-User Peer-to-Peer Adaptation (for CCS7 messaging over IP network) MTP Layer 2 User Adaptation (superseded in ISN07 by M2PA) MTP Layer 3 User Adaptation (for CCS7 messaging via CS2000 CS LAN) Media Access Control (a MAC address is a Layer 2 network address) Megabits per second Multi-Country Call Server (one CS2000 with gateways in several countries) Malicious Call Identification Media Control Message Protocol (for specifying currency/language to UAS) Multimedia Communication Server 5200 Modify Connection (ASPEN message) 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 NAPT Network Advice Of Charge (ISDN service) Network Address and Port Translation
PROPRIETARY Page
Nortel Networks
xix
NAT NCAS NCL NCOS NCS NDND NE NEL NEBS NFS NIC NIIF NLO NM NML NNSC NP NPM NRN NRR NSP NTFY NTMOS OAM&P OC OC-3 ODP OLEC OSS OSSDI PAM PBX PCL PCM PDP PE PEC PEEL PEP PID PLC PM PMDM POTS PP PP7480 PP8600 PP15000 PPVM PRI PS PSS1
Network Address Translation Non Call Associated Signalling (e.g. TCAP) Non-CM Load Network Class Of Service (mechanism for call screening) Network-based Call Signalling (between CS2000 GWC and MTA) Non-DMS Name Delivery Network Element Network Element Layer (in TMN hierarchy) Network Equipment Building System Network File Server (as used by CS2000-Compact) Network Identification Code (Nortel term for NRN, as used in NP) Network Interworking Industry Forum (predecessor to ACIF) New Licensed Operator (competing with an established PTT) Network Management Network Management Layer (in TMN hierarchy) Nortel Networks Service Class (for marking and prioritising traffic) Number Portability Network Patch Manager Network Routing Number (as used in NP) Network Re-Routing (of ISUP call if congestion is encountered) Network Services Platform (OAM&P desktop) Notify (ASPEN/NCS message indicating occurrence of monitored event) Network Traffic Management Operation System (near real-time trunk OMs) Operations, Administration, Maintenance and Provisioning Optical Carrier (SONET optical signal format) OC Level 3 (155 Mb/s, North American equivalent to STM-1) Open Dial Plan Originating Local Exchange Carrier Operations Support System (centralised OAM&P application) OSS Data Interface Pluggable Authentication Module Private Branch Exchange Product CM Load Pulse Code Modulation (as used to digitise speech) Policy Decision Point (for COPS-based CAC) Processor Element (XA-Core component) Product Engineering Code (Nortel hardware idenifier) Protel Environment Emulation Layer Policy Enforcement Point (for COPS-based CAC) Package Identifier (part of PID/TID used to denote a tone) Packet Loss Concealment (used to camoflage gaps in packetised speech) Peripheral Module Preside Multi-service Data Manager (for management of PVGs) Plain Ordinary Telephone System (basic telephony) Passport (family of ATM and IP switches and media gateways) Passport 7000 PVG Passport 8600 routing switch on which the CS2000 CS LAN is based Passport 15000 PVG Peripheral Processor Virtual Machine (CS2000 internal protocol) Primary Rate Interface (ISDN) Program Store (XA-Xore memory used to hold executable code) Private Signaling System No1 (QSIG)
Page
xx
Nortel Networks
PROPRIETARY
PSTN PTE PTE2000 PTM PVC PVC PVG QCA QoS
Public Switched Telephone Network Packet Telephony Equipment Frame used to house SAM21 shelves for GWCs and CS2000-Compact Packet Telephony Manager (old name for SSPFS / SESM) Permanent Virtual Circuit (statically allocated AAL2 or AAL5 channel) Protocol Version Control (used to distinguish PRI variants and issues) Packet Voice Gateway (PP7480 or PP15000 supporting VoIP or VoATM)) QoS Collector Application (for end-of-call QoS data provided by GWCs) 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 SAM SAM16 SAM21 SAPI SBC SCA SCC2 SCF SCF SCL SCP SCS SCSI Subscriber Activated Call Barring (line service) Service Application Module 16-slot CS2000 SAM used as UAS 21-slot CS2000 SAM used to house GWCs Service Access Point Identifier (for ISDN Layer 2/3 communication) Single-Board Computer Selective Call Acceptance (screening service for lines) Switching Control Centre 2 (format used to standardise multi-vendor logs) Service Control Function (for IN) Selective Call Forward (screening service for lines) Speed Calling, Individual Long List (line service) Service Control Point (for IN) Speed Calling, Individual Short List (line service) Small Computer System Interface
PROPRIETARY Page
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 TEI Time Division Multiplexing (traditional telephony switching) Terminal Endpoint Identifier (for ISDN)
Page
xxii
Nortel Networks
PROPRIETARY
TFTP TID TID TLEC TMM TMN TNS TR740 TR746 TSS TUP UA UAS UDP UP URI USP VBD VBR VLAN VM VME VoATM VoIP VRDN VRRP VSP WAN WML WUCR X.25 XA XAI XML
Trivial File Transfer Protocol Terminal Identifier (as used by XA-Core call processing to identify a trunk) Tone Identifier (part of PID/TID used to denote a tone) Terminating Local Exchange Carrier Trunk Maintenance Manager Telecommunications Management Network Transit Network Selection (CSP for intra-network use) Bellcore standard for DCOS performance data Bellcore standard for NTMOS performance data Telephony Soft Switch (e.g. CS2000) Telephony User Part (CCS7 protocol) User Adaptation Universal Audio Server (proprietary media server used by CS2000) User Datagram Protocol (unreliable / best-try protocol running over IP) Universal Port (gateway supporting dial-up RAS as well as VoIP) Uniform Resource Identifier (as used in SIP-T) Universal Signalling Point Voice Band Data Variable Bit Rate Virtual LAN (as supported by PP8600 routers) Voice Mail (line service) Versa Module Europe (industry hardware standards) Voice over ATM Voice over IP Virtual Routing Distribution Node (GWC supporting DPTs) Virtual Router Redundancy Protocol (as used between CS LAN PP8600s) Voice Service Processor (PVG component for circuit/packet conversion) Wide Area Network Warm Line (line service) Wake-Up Call Request (line service) ITU-T packet-switching standard Extended Architecture (as in XA-Core) Extended Architecture Interconnect (XA-Core internal comms links) Extensible Markup Language (data self-description via DTD and tags)
Nortel Networks
PROPRIETARY
Page
xxiii
Part A Overview
CS2000 International Product Description Communication Server Capabilities
Part A Overview
Chapter A1 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.
Nortel Networks
Chapter A2
A2.1
Network Overview
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.
Nortel Networks
PROPRIETARY
Page
Part A Overview
Chapter A2 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 Gateway Controller (MGC) Media Gateway Controller (MGC)
Core network (packet backbone)

MGC-to-MGC signalling
MGC-MG signalling:
PSTN CCS7 signalling (e.g. ISUP) Device/media control Backhauled call control Media server Announcements, conferencing Media Gateway (MG) Media stream, e.g. packetised voice
MGC-MG signalling:
Device/media control Backhauled call control PSTN CCS7 signalling (e.g. ISUP) Page
Media Gateway (MG)
3 2 1
Different types of access (list not exhaustive): (1) CCS7 (trunk media gateway terminates TDM bearer channels only) (2) PRI PBXs, e.g. PRI (combined media and signalling gateway terminates bearer channels and supports backhaul of call control signalling to MGC) (3) Analogue lines (line media gateway terminates bearer channel and in-band DTMF)
3 2 1
PBX
PBX
TDM network, e.g. PSTN

Figure 1: Generic view of MEGACO network archiecture
Nortel Networks
PROPRIETARY
Part A Overview
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.)
Page
Nortel Networks
PROPRIETARY
Part A Overview
Figure 2 provides a schematic view of CS2000 network architecture for VoIP (OAM&P units omitted for simplicity).
CS2000 Core supports: Call processing Translations / routing Service logic Core and GWCs together support MGC functionality. GWCs individually configured to support: Device/media control for MGs Backhauled call control for MGs H.323 access CICM control DPTs between CS2000s Media server control Media proxy control RMGC functionality Media server switched into calls to support: Announcements Conferencing BCT for LI USP supports CCS7 signalling to/from TDM networks via dedicated signalling links (not via packet network)
Session Server supports SIP signalling to/from peer MGCs
Media proxy switched into calls to support NAT traversal for media streams between IP address domains
CICM provides services for remote CentrexIP clients
CS2000 CS LAN
CS2000 Core MS2000 GWCs CICM USP Session Server Session Server
CS2000 CS LAN
CS2000 Core
GWCs
MS2000
CICM
USP
Dual PP8600s
Media proxies
Dual PP8600s
Core network
PVG PVG PVG MG9000 Customer Edge (CE) router CCS7 trunks PRI or QSIG PBX V5.2 H.323 access to core network for: M1 IP PBX BCM CSE1000 Cisco routers DPNSS GW Customer Edge (CE) router
Access or enterprise network
Enterprise network
V5.2 AN Lines and ADSL
CentrexIP clients Low-capacity media gateways, e.g. IAD, MTA
PSTN or other TDM network
Figure 2:
CS2000 network architecture

PROPRIETARY Page
Nortel Networks
Part A Overview
A2.3
A2.3.1
CS2000 Support for Network Architecture

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.
Page
Nortel Networks
PROPRIETARY
Part A Overview
"
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. 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. ! 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
PROPRIETARY Page
Nortel Networks
Part A Overview
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.
Page
Nortel Networks
PROPRIETARY
Part A Overview
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.
PROPRIETARY Page
"
"
"
"
Nortel Networks
10
Part A Overview
"
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.
Page
11
Nortel Networks
PROPRIETARY
Part A Overview
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.
Nortel Networks
PROPRIETARY
Page
12
Part A Overview
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.
Page PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004
13
Nortel Networks
Part A Overview
"
"
"
"
"
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.
Nortel Networks
PROPRIETARY
Page
14
Part A Overview
"
"
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.
Page
15
Nortel Networks
PROPRIETARY
Part A Overview
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.
Nortel Networks
PROPRIETARY
Page
16
Part A Overview
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.
Page
17
Nortel Networks
PROPRIETARY
Part A Overview
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. 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).
RAS
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.
Nortel Networks
18
Part A Overview
A2.4
A2.4.1
The Backbone Packet Network

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.
19
Nortel Networks
Part A Overview
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.
Nortel Networks
PROPRIETARY
Page
20
Chapter A3
A3.1
Product Overview
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.
Nortel Networks
PROPRIETARY
Page
21
Part A Overview
Chapter A3 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
Nortel Networks
PROPRIETARY
Page
22
Part A Overview
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
Page
23
Nortel Networks
PROPRIETARY
Part A 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.
Nortel Networks
PROPRIETARY
Page
24
Part A Overview
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 N The interworking is supported. 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. 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.
Page
25
Nortel Networks
PROPRIETARY
ISUP
CCS7
TUP
Access / VPN
Q.931 / IUA
Basic analogue lines (IBN)
Lines
CS2000 support for basic call interworkings in ISN07 Y = Supported N = Not supported [1]
X = Not relevant (e.g. not for the same market)
SIP ISUP (with CCS7) (no CCS7) EISUP V1 EISUP V2 UK ISUP SPIROU
CCS7 TUP FGD ISUP CTUP BTUP FTUP IBN7
IN INAP
H.323 DPNSS H.323
Access / VPN Q.931 / IUA ANSI PRI ETSI PRI INS1500 HK PRI QSIG
IBN lines
CentrexIP
LAN MG
MG9000
MTA
V5.2
I/F type SIP
Interface
SIP (no CCS7) SIP-T (encapsulating CCS7) Base / generic ETSI ISUP V1 and national V1 variants [3] Base / generic ETSI ISUP V2 and national V2 variants2 [4] UK ISUP (V3) [5] SPIROU (French V3) [5] IBN7 (ANSI ISUP+) US FGD ISUP IUP / BTUP SSUTR2 (FTUP) China TUP (CTUP) IN INAP H.323 / QSIG [6] H.323 DPNSS / H.323 / QSIG [7] QSIG Base / generic ETSI PRI and national 30B+D variants [8] ANSI PRI Hong Kong PRI (CR13) Japan PRI (INS1500) Uni- CentrexIP remote clients Stim Telco-located gateways MG9000 V5.2 PSTN off PVG CPE gateways Customer LAN MGs [9] Cable MTAs [10]
Interworkings supported for CCS7 conveyed in SIP-T are in general as for the CCS7 protocol conveyed [2] Y Y Interworkings for CCS7 in SIP-T are as for the CCS7 protocol conveyed [2] Y N Y N Y N Y N Y N N Y N N N Y Y Y Y Y Y Y Y Y N Y Y N Y Y Y Y Y N Y Y Y Y Y N Y Y Y Y Y N Y Y Y Y Y N Y Y Y X Y X Y X X N Y N Y Y X X X N Y Y X Y Y X X N X N N N Y Y X X X N Y Y Y Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y N X X N Y X X X N N X N X N X X N Y Y Y X Y X Y X X Y N N N Y X X X Y Y Y X N Y X X Y X Y N X N Y X X X N N Y X X Y X X X Y N N X N N X X X N Y Y N N Y N Y Y N X N N Y Y N N N N Y Y Y N Y N N N N N Y N Y Y N N N Y N N N X Y X N X X N N Y N N X X X N Y Y Y Y Y N N N N Y Y N Y Y N N N N Y Y Y Y Y X Y Y N Y Y N Y Y N Y N N Y Y X X Y N X X X N N X N N Y X X N Y Y X X Y X X X X N N X N Y X Y X N Y Y X X Y X X X X N N X N N X X Y N N N N N Y N Y N N N Y N N N N N N Y N N N N Y N N N N N N N N N N N N Y Y Y N N N N N N N Y Y Y Y Y N N N N Y Y N N N N N N Y Y Y N N Y N Y N Y Y Y N N N N N
Nortel Networks 26
PROPRIETARY Page
Part A Overview
N N Y N N N Y N N N N
Y Y Y Y
N Y Y Y
N Y Y Y
N N N N
N N N N
Y N N N
N N N N
N N N N
N N N N
N N Y N
N Y Y Y
N Y Y N
N Y N N
N Y N N
N Y Y Y
N N N N
N N Y N
N N N N
Y N N N
Y Y Y N
Y Y Y Y
Y Y Y N
N Y N Y
27
Page PROPRIETARY
[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 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. [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, 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.
Nortel Networks
Part A Overview CS2000 International Product Description Communication Server Capabilities
Part B Hardware
Chapter B1 CS2000 Hardware
Part B Hardware
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.
Page
29
Nortel Networks
PROPRIETARY
Part B 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 signalling to/from TDM networks via dedicated signalling links (not via packet network) Media server switched into calls to support: Announcements Conferencing BCT for LI
CS2000 Core (XA-Core or Compact) supports: Call processing Translations / routing Service logic Core and GWCs together support MGC functionality.
GWCs individually configured to support: Device/media control for MGs Backhauled call control for MGs H.323 access DPTs between CS2000s Media server control CICM control Media proxy control RMGC functionality Session Server CICM provides supports SIP signalling services for remote to/from peer MGCs CentrexIP clients
CS2000 Core USP MS2000
CS2000 CS LAN
Trunk GWC CICM GWC AC GWC CICM
OAM&P servers
H.323 GWC Line GWC RMGC GWC DPT GWC Session Server
UAS can be used instead of MS2000
Dual PP8600s
GWC configured as VRDN can be used instead of Session Server
Figure 3:
CS2000 configuration with no legacy hardware
Nortel Networks
PROPRIETARY
Page
30
Part B Hardware
Input / Output Office Module supports Alarms datalinks Unit IOM in ISM MS Fiberised Link Peripheral FLPP Processor supports CCS7 links OAU
ENET switching matrix ENET Message Switch (bus) supports internal communication SuperNode Data Manager supports OAM&P for CS2000 Core and FLPP
MS
SDM
CS2000 CS LAN
CS2000 Core MS2000 Trunk GWC CICM GWC AC GWC CICM
OAM&P servers
Dual PP8600s
Figure 4:
CS2000 configuration using DMS hardware for selected functions
IOM in ISM MS
Legacy trunk peripherals OAU ENET Legacy line peripherals IW-SPM
Trunks (including looparounds)
MS
Lines
FLPP
SDM
Two mechanisms for interworking betweeen circuit and packet environments: Looparound trunks connecting legacy peripherals with TDM side of PVG trunk gateway Interworking SPM (IW-SPM) connected both to legacy peripherals (via ENET) and to media gateways (via CS LAN and packet backbone network)
CS2000 Core MS2000
CS2000 CS LAN
Trunk GWC CICM GWC
OAM&P servers
AC GWC CICM H.323 GWC Line GWC RMGC GWC DPT GWC Session Server
Dual PP8600s
Figure 5:
Hybrid configuration with interworking between CS2000 and DMS peripherals
Page
31
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
32
Part B Hardware
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. 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. 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.
Page
33
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
34
Part B Hardware
Logical Architecture Figure 6 shows XA-Core architecture. Subsystems are described in sections B1.2.1.2 to B1.2.1.4.
CS2000
XA-Core
XAI comms links Disk Processor Elements (PEs) I/O Processors (IOPs) Terminal MS used only if configuration includes DMS hardware (see Figures 4 and 5) OC-3 links 100BaseT Ethernet links CS LAN Shared memory (SM) Tape
Message Switch (CS2000 bus)
Links to FLPP, SDM, IOM, ENET Figure 6: XA-Core architecture
Links to USP and GWCs
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.
Page
35
Nortel Networks
PROPRIETARY
Part B Hardware
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).
Nortel Networks
PROPRIETARY
Page
36
Part B Hardware
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
! !
Page
37
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
38
Part B Hardware
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.
Second shelf (optional)
Main shelf (mandatory)
One or two SAM21 Call Agent shelves housing: 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 - AC for UAS 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)
Page
39
Nortel Networks
PROPRIETARY
Part B Hardware
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.
"
Nortel Networks
PROPRIETARY
Page
40
Part B Hardware
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.
Page
41
Nortel Networks
PROPRIETARY
Part B Hardware
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.
! ! ! ! !
Nortel Networks
PROPRIETARY
Page
42
Part B Hardware
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
Page
43
Nortel Networks
PROPRIETARY
Part B Hardware
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 Core USP MS2000
CS2000 CS LAN
Trunk GWC CICM GWC AC GWC CICM
OAM&P servers
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

PROPRIETARY Page
Nortel Networks
44
Part B Hardware
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:
"
"
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.
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.
Page
45
Nortel Networks
PROPRIETARY
Part B Hardware
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 IP Ethernet 100BaseT CS LAN Intra-PP8600 links signalling IP Ethernet GigE
signalling IP Ethernet GigE
PP8600
Uplinks to backbone network
IP backbone packet network
PVG
bearer IP Ethernet GigE
Scenario B:- Connectivity for an ATM backbone network

signalling IP Ethernet GigE signalling IP Ethernet 100BaseT CS LAN Intra-PP8600 links signalling IP AAL5 ATM STM-x
PP8600
Uplinks to backbone network
ATM backbone packet network
signalling IP AAL5 ATM STM-x
PVG
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.
Nortel Networks
46
Part B Hardware
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 8010co chassis Function Provisioning
Centre slots (5 and 6) reserved for 8691 cards. Provides 10 slots for housing Other slots (1-4 and 7-10) available for I/O 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: 4 GigE ports are used for fully redundant inter-chassis communication via at least 2 GigE links. For VoIP, at least two 2 GigE ports are used for uplinks to the packet backbone network (4 can be used if required)
8632TXE
Supports: 32 Ethernet 100BaseT ports 2 Gigabit Ethernet ports
8608GBE
8608SXE
Provides 8 slots for GBIC (Gigabit Interface Converter) modules Each GigE port requires a dedicated GBIC module or connection to provide its physical and optical interface characteristics. At least one Equivalent to 8608GBE, 8608 card is therefore required per PP8600. but uses fixed GBIC connections instead of GBIC modules Provides two slots for MDA Mandatory for VoATM. (Media-Dependent 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 Ethernet ports (RJ-45) Used to provide additional 100BaseT ports for CS LAN connectivity if required
8672ATME
8648TXE
Page
47
Nortel Networks
PROPRIETARY
Part B Hardware
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
Component CS2000 Core XA-Core LX04 HIOP cards in XA-Core shelf Redundancy provided by independent connections with both routers. Each HIOP is connected to one PP8600 but not to the other. During normal operation, both HIOPs are active and operate in load-balancing mode. Redundancy provided by independent connections with both routers. Two ports per processor card, each connected to one of the dual PP8600 routers. Six IP addresses: Two floating logical 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). 100BaseT terminations provided by Connection characteristics IP addressing [1]
3PC Call Agent
Two Ethernet ports on N765 processor cards, one in each SAM21 Call Agent shelf
Ten IP addresses in all, including two floating logical addresses for the active interfaces.
Ethernet ports Redundancy provided by GWCs in SAM21 on GWC cards independent connections chassis with both routers. (connectivity One port per GWC card, identical for all GWC therefore two for a GWC types) pair. Each card is connected to one of the dual PP8600 routers. SAM21 SCs Ethernet ports on SC cards Redundancy provided by independent connections with both routers. One port per SC card, therefore two for an SC pair. Each card is connected to one of the dual PP8600 routers.
Four IP addresses per GWC: One externally visible floating logical address for the active unit. One floating logical address for the inactive unit. Two static addresses for OAM&P / physical access to each card Four IP addresses per SC: One externally visible floating logical address for the active unit. One floating logical address for the inactive unit. Two static addresses for OAM&P / physical access to each card. Four IP addresses per Session Server: One externally visible floating logical address for the active unit. One floating logical address for the inactive unit. Two static addresses for OAM&P / physical access to each unit
Session Server
Ethernet ports Redundancy provided by on HP-CC3310 independent connections with both routers. platform Two ports per HP-CC3310, each connected to one of the dual PP8600 routers.
Nortel Networks
PROPRIETARY
Page
48
Part B Hardware
Table 2: CS LAN connections supported by PP8600 dual routers

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

Component IEMS PMDM [4] 100BaseT terminations provided by Connection characteristics IP addressing [1]
Shares Sun server platform (and Ethernet connections) with CBM or CS2M Ethernet ports on Sun server platform Redundancy provided by independent connections with both routers. Each port is connected to one of the PP8600 routers but not the other. Each functional OAM&P element on Sun server requires three IP addresses for redundancy. There is one logical IP address, and two physical addresses referred to as 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 Default VLAN 192.168.0.2/22 Running VRRP VRRP/IP 192.168.0.1 PP8600/1 Default VLAN 192.168.0.3/22 Running VRRP VRRP/IP 192.168.0.1
GWCs
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
GWCs
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
192.168.x.x/22
3PC blade Core 3PC blade

192.168.x.x/22
MS2010/0 192.168.x.x/22 MS2010/1 192.168.x.x/22 MS2010/2 192.168.x.x/22 MS2010/3 192.168.x.x/22
USP 192.168.x.x/22
CBM 192.168.x.x/22
Netra cluster 192.168.x.x/22 Netra cluster 192.168.x.x/22
Figure 10: Example of CS LAN connectivity
Nortel Networks
PROPRIETARY
Page
50
Part B Hardware
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.
Page
51
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
52
Part B Hardware
B1.4
B1.4.1
Gateway Controllers (GWCs)

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.
Page
53
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
54
Part B Hardware
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: " 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. 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.
Page
55
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
56
Part B Hardware
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.
Page
57
Nortel Networks
PROPRIETARY
Part B Hardware
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: ! ! ,
Up to 8 Gateway Controllers (GWCs) DPT GWCs for trunks to/from peer CSs Intra-CS links to CS200 Core, Session Server and other GWCs
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.
Ethernet CS LAN
GWCs for trunk and line media gateways, e.g. PVG
H.323 proxy GWC
Audio Controller (AC) GWC for media server
CICM controlled by line GWC
Dual PP8600 routers
Note: Each GWC actually consists of a pair of cards operating in hot standby mode, as explained in detail in section B1.4.5 on page 60, but for simplicity this hardware duplication is not shown. Similarly, the SC comprises two cards. Shelf Controller (SC)
Managed IP or ATM network
Media gateways and other CS2000s
SAM21 card cage
The packet network backbone can be either IP or ATM; if an ATM backbone network is in use, signalling to/from CS2000 is via IP / AAL5 / ATM (AAL5 added/removed by PP8600 routers))
Figure 11: Logical view of different GWC types and their interaction
Nortel Networks
PROPRIETARY
Page
58
Part B Hardware
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.
System slots 7 and 9 house SC cards
Up to three SAM21 card cages per cabinet, one per shelf
I/O slots (1-6) for GWC cards
I/O slots (11-20) 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.
Page
59
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
60
Part B Hardware
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 2 Line media gateway is booted up and automatically broadcasts a DHCP (Dynamic Host Configuration Protocol) message requesting configuration data. 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. Line media gateway sends the specified server a TFTP request to download the required configuration file. TFTP server responds by downloading a file containing configuration data, including the IP address of the GWC with which the gateway should register itself. 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. 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.
3 4 5
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).
Page
61
Nortel Networks
PROPRIETARY
Part B Hardware
B1.4.5.3 Selection and Use of GWCs 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. 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 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. 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. 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), 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
Nortel Networks
PROPRIETARY
Page
62
Part B Hardware
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
CS2000 Core Call processing DPT provisioning
Terminating CS2000
Access GWC
DPT GWC DPT GWC DPT GWC
Session Server
Inter-CS connection
Session Server
Access GWC
Session Servers terminate SIP / SIP-T signalling Media gateway DPT GWCs terminate CCS7 signalling Media gateway
GWC support for inter-CS signalling using a VRDN

Originating CS2000
CS2000 Core Call processing DPT provisioning Inter-CS connection
Terminating CS2000
Access GWC
DPT GWC DPT GWC DPT GWC No VRDN for call origination
A B
VRDN GWC
Access GWC
A
Media gateway
Signalling for initial INVITE and redirection response is between DPT GWC and VRDN Media gateway
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
Page
63
Nortel Networks
PROPRIETARY
Part B Hardware
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.
"
"
" "
Nortel Networks
PROPRIETARY
Page
64
Part B Hardware
"
"
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.
"
Page
65
Nortel Networks
PROPRIETARY
Part B Hardware
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 determined in consultation with Nortel Sales Engineering. ! 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.
Nortel Networks
PROPRIETARY
Page
66
Part B Hardware
" "
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.
Page
67
Nortel Networks
PROPRIETARY
Part B Hardware
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).
"
Nortel Networks
PROPRIETARY
Page
68
Part B Hardware
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
Page
69
Nortel Networks
PROPRIETARY
Part B Hardware
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)
PROPRIETARY Page
Nortel Networks
70
Part B Hardware
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. CS2000 supports peer-to-peer signalling with other CS2000s and with compatible peer 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 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. 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. 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.
Page
71
Nortel Networks
PROPRIETARY
Part B Hardware
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)
CS2000
ISUP TUP M3UA CS2000 Core SCTP IP USP TCAP SCCP
ISUP
TUP MTP3 MTP2 MTP1 TCAP SCCP MTP3 M2PA SCTP IP
TCAP SCCP Conventional CCS7 signalling network
CS LAN DPT GWC Session Server or VRDN
SIP-T SIP-T
ISUP SDP TUP SDP
IP control network over backbone packet network
See section B1.4.5.3 on page 62 for information about DPT GWC interaction with Session Server or VRDN
TCP or UDP IP
Scenario B:- CCS7 support provided by FLPP (Fiberised Link Peripheral Processor)
CS2000
ISUP
Proprietary messaging
TUP MTP3
XA-Core
FLPP
MTP2 MTP1
CS LAN Session Server or VRDN
Note: No packet network support for NCAS (Non Call Associated Signalling) with FLPP-based configuration
DPT GWC
ISUP SDP
TUP SDP
TCP or UDP IP
Figure 14: Alternative methods of supporting CCS7 on CS2000
Nortel Networks
PROPRIETARY
Other CS2000s, MCS5200s, etc

Page
SIP-T SIP-T
TDM-side switches, SCPs, etc
Other CS2000s, MCS5200s, etc
TDM-side switches, SCPs, etc
72
Part B Hardware
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.
Page
73
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
74
Part B Hardware
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.
Page
75
Nortel Networks
PROPRIETARY
Part B Hardware
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 main shelf
USP extension shelf
USP extension shelf
USP extension shelf
Figure 15: USP hardware packaging
Nortel Networks
PROPRIETARY
Page
76
Part B Hardware
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 CCS7 signalling network ISUP TUP MTP3 MTP2 MTP1 Figure 16: Signalling supported by the USP-Compact TCAP SCCP Intra-CS2000 signalling over CS LAN ISUP TUP M3UA SCTP IP TCAP SCCP
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
Page
77
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
78
Part B Hardware
LIS and LIM units are housed in C42 cabinets as illustrated in figure 17. A CS2000 configuration can include up to six LPP cabinets.
Link Interface Module
LPP LMS 0 LPP LMS 1
LMS functions: To terminate SR128 links to/from the MS (CS2000 bus). To support communication between IUs/ASUs
Link Interface Shelf 1 LISs provide slots for IUs/ASUs, e.g. LIU7s
Link Interface Shelf 2
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
Link Peripheral Link Processor Interface (FLPP) Unit (LIU7) V.35 External mux 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
Integrated ASU Processor and F-Bus Interface (IPF) ASU processor F-Bus Interface To/from F-Bus Figure 19: Components of an LIU7 External CCS7 link Processor bus
MS
9X76
Signalling Terminal (ST) supporting Layer 2 datalink functions for one CCS7 link
9X77
CCS7 Interface paddleboard
Page
79
Nortel Networks
PROPRIETARY
Part B Hardware
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.
CS2000
FLPP LMS
XA-Core (CS2000 central processing engine)
F-Bus
LIU7s used as external routers CCS7 network
LIU7s terminating CCS7 signalling
Figure 20:
Use of LIU7 external routers to select CCS7 signalling links
Nortel Networks
PROPRIETARY
Page
80
Part B Hardware
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.
Page
81
Nortel Networks
PROPRIETARY
Part B Hardware
OSS LAN / OC corporate internet (centralised OAM&P applications) HLM applications PC clients for EMs and management applications
Nortel Remote Access
Contivity 600 secure gateway Secure tunneling
Enterprise servers NOC LAN Untrusted indirect access to NEs via EMs Element Managers (trusted access to Network Elements) Firewall / perimeter network CBM
Sun server
RA to OAM&P VLAN
IEMS / CMT
Sun server
Other EMs/apps Sun server PP8600 DM
RA to CS2000
CS2000 CS LAN
EMS servers EM functionality for 3rd-party media gateways CS LAN (OAM&P VLAN)
Telco router
CS2000 Core
SAM21 SC GWC inc. EM CICM
SS (inc. EM)
USP (inc. EM)
MS2010
CS LAN can comprise multiple signalling VLANs, as illustrated in Figure 8 on page 44; this diagram simplifies the network structure in order to focus on OAM&P access
CS LAN (signalling VLANs) (not needed for VoATM) CS LAN (bearer VLAN)
PP8600 routers
Packet backbone network
PVG gateways
Line gateways
Figure 21: Physical OAM&P architecture
Nortel Networks
PROPRIETARY
Page
82
Part B Hardware
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.
Page
83
Nortel Networks
PROPRIETARY
Part B Hardware
B1.7.3
Hardware Platforms used for EMs and Management Applications

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.
B1.7.3.1 OAM&P Packaging and Integration
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 management applications
HLM applications on enterprise servers NOC LAN IEMS provides one externally visible IP address for access to all EMs OAM&P VLAN
IEMS Non-CMT-resident EMs, e.g. for Session Server, USP, CICM EM EMs and mgmt apps, e.g. GWC EM, SAM21 EM, configuration apps
Core Manager applications
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
Nortel Networks
PROPRIETARY
Page
84
Part B Hardware
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
Page
85
Nortel Networks
PROPRIETARY
Part B Hardware
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)
Nortel Networks
PROPRIETARY
Page
86
Part B Hardware
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.
Bulkhead with standard sockets 4-wire DS-30 cable Local/ remote device
IOM
EMPC
Port
4-wire DS-30 Port cables
Smart connector
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.
Page
87
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
88
Part B Hardware
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
IOM in ISM MS
OAU
ENET
Legacy trunk peripherals
Legacy trunks
TDM side of PVG Packet side of PVG
Looparound trunks connecting legacy peripherals with TDM side of PVG trunk gateway Lines
MS Legacy line peripherals
FLPP
SDM

Dual PP8600s
CS2000 Core MS2000 Trunk GWC
CS2000 CS LAN
CICM GWC AC GWC CICM
OAM&P servers
H.323 GWC Line GWC RMGC GWC Session DPT Server GWC
Figure 24: Hybrid configuration interworking via looparound trunks
Page
89
Nortel Networks
PROPRIETARY
Part B Hardware
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.
IOM in ISM MS
Legacy trunk peripherals OAU ENET Legacy line peripherals IW-SPM
Legacy trunks
PVG TDM side of PVG Packet side of PVG
MS
Legacy lines
FLPP
SDM
Interworking SPM (IW-SPM) connected both to legacy peripherals (via ENET) and to media gateways (via CS LAN and packet backbone network)

Dual PP8600s
CS2000 Core MS2000 Trunk GWC CICM GWC
OAM&P servers
AC GWC CICM H.323 GWC
CS2000 CS LAN
Line GWC RMGC GWC Session DPT Server GWC
Figure 25: Hybrid configuration interworking via the IW-SPM

Nortel Networks
90
Part B Hardware
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 fibre link to ENET switching matrix Circuit-based interface with ENET Four DS-512 links (2048 64 Kb/s channels) DS-512 fibre link to ENET switching matrix Common Equipment Module (CEM) CEM duplicated for reliability Common Equipment Module (CEM) Gigabit Ethernet Module (GEM) GEM terminates physical interface and provides all DSP functionality Gigabit Ethernet Module (GEM)
GigE packet-side interface with CS LAN PP8600s (one active link, one for protection switching)
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.
Page
91
Nortel Networks
PROPRIETARY
Part B Hardware
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 unit), and is housed in a customised four-shelf system frame as shown in Figure 27. Two IW-SPM units can be housed in a given frame. The dimensions of IW-SPM 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.
IW-SPM #1
IW-SPM frame housing two double-height (twin-shelf) IW-SPM units
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 Figure 27: IW-SPM hardare packaging for Resource Modules 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.
Nortel Networks
92
Part B Hardware
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 Dimensions: 71 cm wide x 183 cm high x 71 cm deep (28 x 72 x 28) Used to house: SDM ISM / IOM PTE2000 equipment cabinet (NTTD35AA) Dimensions: 61 cm wide x 213 cm high x 61 cm deep (24 x 84 x 24) 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.
Page
93
Nortel Networks
PROPRIETARY
Part B Hardware
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 media servers
Session Server
OAM&P servers frame
183cm
USP main PP 8600
Depth 71cm
SAM21 shelves housing GWCs XA-Core 107cm 61cm 61cm 61cm
213cm Depth 61cm
PP 8600
USP ext.
61cm
61cm
61cm
Figure 28: Example Lineup A:- XA-Core configuration with no legacy hardware
Session Server
Call Control Frame
SAMF expansion frame
USP frame
OAM&P servers frame
MX20x0 media servers SAM21 Call Agent shelves housing: 3PC Call Agent card (main shelf) GWCs
USP main CA1 USP ext. PP 8600
213cm Depth 61cm
PP 8600
CA0 61cm 61cm
61cm
61cm
61cm
Figure 29: Example Lineup B:- Compact configuration with no legacy hardware
Nortel Networks
PROPRIETARY
Page
94
Part B Hardware
XA-Core / MS cabinet
FLPP cabinet
ENET cabinet
213cm SAM21 shelves housing GWCs Depth 61cm 61cm 61cm SS OAU AXU MS CMT on Sun PP 8600 Depth 61cm 213cm 213cm Depth 61cm PP 8600 61cm 61cm 61cm SS MS CMT on Sun SDM on Series FX PP 8600 PP 8600 61cm 61cm 61cm Issue ISN07_v3 (approved) 17 August 2004
183cm
MS 0 MS 1
LMS LIS 0 LIS 1
ENET 0 ENET 1
Depth 71cm
XA-Core 107cm
LIS 2 107cm 107cm
SDM on Series FX
ISM shelves for IOMs 71cm
71cm
Figure 30: Example Lineup C:- XA-Core configuration with selected legacy hardware
Combined Core cabinet

183cm
MS LIS ENET SAM21s with GWCs
OAU AXU ISM shelves for IOMs 71cm
Depth 71cm
XA-Core 107cm 61cm
71cm
Figure 31: Example Lineup D:- XA-Core SNSE configuration with selected legacy hardware
Page
95
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
96
Chapter B2 CS2000 Support for Media Gateways
Part B Hardware
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.
Page
97
Nortel Networks
PROPRIETARY
Part B Hardware
B2.2
Categorising Media Gateway Capabilities

Packet network control signalling TDM bearer channels Packet network bearer connections
GWC-gateway signalling path, described in terms of: Gateway port/termination characteristics Media control signalling for bearer connections - H.248 (or ASPEN) for PVGs supporting CCS7 and/or PRI access - H.248 for PVGs supporting V5.2 access - NCS for MTA line gateways - MGCP for CPE LAN line gateways - DSM-CC for CVX1800 RAS gateways Call control signalling (where gateway provides SG functionality as well as MG functionality) - N/A for CCS7 access - Q.931 or QSIG over IUA/SCTP/IP for PRI or QSIG access - V5-PSTN over V5UA/SCTP/IP for V5.2 access - H.323 for H.323 gateways - NCS for MTA cable lines - MGCP for CPE LAN lines
CS2000
Gateway Controller (GWC)
Packet
k or tw ne
(ATM or IP)
Access network (e.g. PSTN, ISDN, V5.2 AN, analogue lines)
Media gateway
Far-end gateway
Access network connections, described in terms of: Physical circuits and terminations used to support access Types of bearer channel to/from access network - 64 Kb/s bearer circuits for CCS7 - ISDN PRI B-channels - V5.2 B-channels - Analogue lines - ADSL Signalling terminations (where gateway provides SG functionality as well as MG functionality) - N/A for CCS7 - Q.921 user D-channel terminations - LAP-V5 user C-channel terminations - In-band DTMF for lines
Packet-side bearer connections, described in terms of: Termination characteristics Packet network backbone type (IP or ATM)
Figure 32: Categorising gateway capabilities
Nortel Networks
PROPRIETARY
Page
98
Part B Hardware
B2.3
B2.3.1
PVG (Packet Voice Gateway) Trunk Gateways

See section B2.4 on page 111 for information about using PVGs to support V5.2 access.
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.
Page
99
Nortel Networks
PROPRIETARY
Part B Hardware
Figure 33 illustrates PVG components and their functions at a logical level. Configuration A: Capabilities provided by separate cards
PVG
Packet network (IP or ATM)

Packet network terminations support both bearer connections and H.248 or ASPEN control connections with GWC STM-x ATM FPs support ATM directly, and support IP by means of AAL5
TDM or access network
TDM FP (Function Processors) supporting TDM-side terminations
VSP (Voice Service Processor) supporting TDM/packet conversion
Dedicated FP (IP or ATM) supporting packet-side terminations
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
PVG

Packet network terminations support both bearer connections and H.248 or ASPEN control connections with GWC
TDM FP (Function Processors) supporting TDM-side terminations
Integral GigE port
Direct GigE support of IP
Configuration C: Integral STM-1/OC-3 packet-side ports on VSP3-o
PVG

Packet network terminations support both bearer connections and H.248 or ASPEN control connections with GWC STM-x ATM FP or 4pGE IP FP
Integral STM-1 port
Dedicated FP (IP or ATM) supporting packet-side terminations
Figure 33: Logical configuration of a PVG
Nortel Networks
PROPRIETARY
Page
100
Part B Hardware
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 VSP type PP 15000 or 20000 Yes Yes Yes PP 7480 No No Yes TDM-side terminations STM-1 E1 FP FP (32 (4 x 62 E1s) E1 ports) No Yes Yes No Yes Yes T1 FP (56 T1s) No Yes Yes Packet network terminations GigE IP GigE IP STM-4 STM-1 ports ports on ATM FP ATM FP on VSP 4pGE FP 622 Mb/s 155 Mb/s No Yes No Yes Yes No Yes Yes Yes Yes Yes Yes
VSP3-o VSP3 VSP2
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.
Page
101
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
102
Part B Hardware
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 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 / 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 control signalling is H.248 / UDP / IP / RFC2684 / AAL5 / ATM " 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.
Page
103
Nortel Networks
PROPRIETARY
Part B Hardware
ATM 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 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 / 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
Nortel Networks
104
Part B Hardware
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).
PVG type Network type Codec type G.711 (10ms) G.711 (20ms) G.729a/b (10ms + digit collection) G.729a/b (20ms + digit collection) G.711 (5ms) G.726-32 (5ms) G.726-32 (10ms) G.729a/b (10ms) G.711 (10ms) G.711 (20ms) G.729a/b (10ms + digit collection) G.729a/b (20ms + digit collection) G.711 (5ms) G.711 (5ms + digit collection) G.726-32 (10ms) G.726-32 (10ms + digit collection) G.729a/b (10ms) G.711 (10ms) G.711 (20ms) G.729a/b (10ms + digit collection) G.729a/b (20ms + digit collection) G.711 (5ms) G.711 (5ms + digit collection) G.726-32 (10ms) G.726-32 (10ms + digit collection) G.729a/b (10ms + digit collection) Max. 64Kb/s channels / DS0s per VSP 2,016 2,016 1,512 1,512 2,016 2,016 2,016 1,512 1,120 1,120 800 800 1,120 960 1,120 960 1,512 1,008 1,008 720 720 1,008 864 1,008 864 720
IP PP15000 with VSP3 ATM (AAL2)
Reliability and quality of service are carrier grade, even in a non-redundant configuration in which E1 carriers are not duplicated.
105
Nortel Networks
Part B Hardware
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).
Nortel Networks
PROPRIETARY
Page
106
Part B Hardware
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.
Page
107
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
108
Part B Hardware
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.
109
Nortel Networks
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
110
Part B Hardware
B2.4
B2.4.1
PVG as a V5.2 Gateway

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
Page
111
Nortel Networks
PROPRIETARY
Part B Hardware
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 VSP type VSP3 VSP2 PVG type PP15000 PP15000 PP7480 64 37 33 E1 capacity [1] [2] G.711 G.729 50 26 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.
Nortel Networks
PROPRIETARY
Page
112
Part B Hardware
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 Small120 Small240 Small480 Small Medium Large Size 120 240 480 672 1344 2048 Max. no. ANs 53 26 13 9 4 3 Reserved capacity 6360 [1] 6240 [1] 6240 [1] 6048 5376 [1] 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 VSP type VSP3 VSP2 PVG type PP15000 PP15000 PP7480 C-channel capacity [1] 64 [2] 40 40 B-channel capacity G.711 2016 [2] 1120 1008 G.729 1512 [2] 800 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.
Page
113
Nortel Networks
PROPRIETARY
Part B Hardware
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. AN PVG
Shelf 1 VSP-A
V5.2 C-path Primary E1-Link Bearer
GWC
SG Packet Network V5UA MG RTP VSP-B Managed Call control
V5.2 C-path Secondary E1-Link Bearer
SG RTP MG
H.248
Media control
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.
Nortel Networks
PROPRIETARY
Page
114
Part B Hardware
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 served by other CS2000s CS2000 Core Basic interoperability via non-FT trunks with units served by other CS2000s
CS2000
H.323 proxy (GWC equivalent)
H.323 proxy
Other GWCs
H.323 signalling (no bearer traffic)
Full interworking with other H.323-controlled units served by same CS2000
Basic interoperability with non-H.323 units served by same CS2000
Proprietary units
Meridian 1 IP PBX
Business Call Manager (BCM)
Communication Server for Enterprise (CSE1000)
Third-party units
Cisco access router / gatekeeper (2600 / 3600 / 7200)
Westell DPNSS gateway (InterChange iQ203x)
Figure 35: The role of H.323 in a CS2000 network
Page
115
Nortel Networks
PROPRIETARY
Part B Hardware
B2.6
B2.6.1
Mediant 2000 Trunk Gateway

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.
Nortel Networks
PROPRIETARY
Page
116
Part B Hardware
B2.6.2
B2.6.2.1 Applications Supported ! VoIP
B2.6.2.2 GWC-Gateway Signalling Physical connections for VoIP ! ! GWC termination 100BaseT Ethernet terminated on GWC card in SAM21 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) B2.6.2.4 Packet Network Bearer Connections 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
Page
117
Nortel Networks
PROPRIETARY
Part B Hardware
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 CS LAN
DPNSS over DFT trunks (NTP[HNIP] in IBN7 messages) CS2000 Core Looparounds for interoperability with IBN lines
To/from other CS2000s To/from TDM VPNs
H.323 proxy GWC
DPNSS over QSIG (in QSIG Facility IEs)
H.323 proxy GWC
DPNSS over H.323 (in H.225 UUI IEs)
IP core network
DPNSS over E1 carriers Westell iQ203x gateway Westell iQ203x gateway DPNSS over E1 carriers
Digital PBX
Bearer connections
Digital PBX
Figure 36: CS2000 support for DPNSS signalling
Nortel Networks
PROPRIETARY
Page
118
Part B Hardware
B2.8
B2.8.1
Carrier-Located Line Media Gateways

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
Dual PP8600s
GWC-gateway signalling (H.248) Bearer connections for VoIP Bearer connections for data are independent of CS2000-controlled VoIP connections
Core network
MG9000
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.
Page
119
Nortel Networks
PROPRIETARY
Part B Hardware
B2.8.2
MG9000 Media Gateway

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.
B2.8.2.1 Overview
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.
POTS-32 cards (each supporting 32 Type A POTS lines)
Internet Telephony Processor (ITP) providing media gateway functionality 25 Mb/s links between ITP and ITX Internet Telephony Extender (ITX) links to subtending shelves (master shelf only)
SuperCore STM-1c network interface
Bearer connections
POTS+ADSL cards (each supporting 8 Type A POTS ports plus 8 ADSL ports)
200 Mb/s links between network interface and ITX
Backbone packet network
25 Mb/s links between ITX and subtending shelves Figure 38: Logical configuration of an MG9000 media gateway (master shelf)
Nortel Networks
PROPRIETARY
H.248 control connection with CS2000 GWC

Page
Service Module (SM) cards supporting access network connections
MG9000 media gateway
120
Part B Hardware
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.
Page
121
Nortel Networks
PROPRIETARY
Part B Hardware
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.
B2.8.3
B2.8.3.1 Applications Supported ! ! VoIP ADSL data sessions
B2.8.3.2 GWC-Gateway Signalling Physical connections for VoIP ! ! GWC termination 100BaseT Ethernet terminated on GWC card in SAM21 Gateway termination " 155 Mb/s STM-1 interface
Device / media control signalling: ! ! 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
B2.8.3.4 Packet Network Bearer Connections 155 Mb/s STM-1 interface supporting RTP / RTCP bearer flows over IP / AAL5 / ATM.
Nortel Networks
PROPRIETARY
Page
122
Part B Hardware
B2.9
B2.9.1
Line Media Gateways on Customer LANs

Functional Overview
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 Gateway

RJ-11 or RJ-21X terminations for analogue subscriber lines Codecs supporting analogue / digital conversion (G.711, G.729) LAN interface supporting access to the IP backbone network via a customer LAN
Customer LAN MGCP
MGCP
Alternative access technologies available
Bearer flows
Bearer flow
IP backbone network
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).
Page
123
Nortel Networks
PROPRIETARY
Part B Hardware
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 Ambit Model name 1101M 1116M 1132M Askey [1] 1104S 1130S Customer LAN gateway type 1-port LG001S IAD 16-port gateway 32-port LG132E gateway VG201 with 4 RJ-11 ports (previously known as RT-132) VG601 with 30 RJ-21X ports MGCP MGCP Protocol
[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.
Nortel Networks
PROPRIETARY
Page
124
Part B Hardware
B2.9.3
Listed characteristics apply equally to Askey, Ambit and Mediatrix gateways except where explicitly noted otherwise.
B2.9.3.1 Applications Supported ! VoIP
B2.9.3.2 GWC-Gateway Signalling Physical connections for VoIP ! ! GWC termination 100BaseT Ethernet terminated on GWC card in SAM21 Gateway termination Ethernet connection terminated on LAN interface card in gateway
Device / media control signalling: ! MGCP / UDP / IP Note: MGCP is also used for dynamic address discovery, as described in section D8.4 on page 322.
Call control signalling: ! MGCP 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.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
B2.9.3.4 Packet Network Bearer Connections 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).
Page
125
Nortel Networks
PROPRIETARY
Part B Hardware
B2.10 Line Media Gateways on Cable Access Networks

B2.10.1 Functional Overview
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 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)
IP backbone network
HFC cable access network
Multimedia Terminal Adaptor

Two RJ-11 terminations for analogue subscriber lines (also an Ethernet/USB port for a PC) Codecs supporting analogue / digital conversion (G.711 A-law) HFC cable modem supporting access to the IP backbone network via a cable access network
NCS (Euro)DOCSIS Bearer flows
CMTS Edge router
Figure 40: Logical configuration of an MTA line gateway
Nortel Networks
PROPRIETARY
Page
126
Part B Hardware
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.
Page
127
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
128
Part B Hardware
B2.10.3 Summary of Characteristics

Listed characteristics apply equally to Motorola and Arris MTAs. B2.10.3.1 Applications Supported ! VoIP
B2.10.3.2 GWC-Gateway Signalling Physical connections for VoIP ! GWC termination 100BaseT Ethernet terminated on GWC card in SAM21 ! Gateway termination HFC cable connection terminated on HFC port in MTA Note: Interface between HFC cable and IP backbone is provided by CMTS. Device / media control signalling: ! NCS / UDP / IP Call control signalling: ! NCS 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.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. B2.10.3.4 Packet Network Bearer Connections 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)
129
Nortel Networks
Part B Hardware
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
CCS7 trunks to/from TDM network Packet network
DACs (Digital Access Cards) supporting TDM-side E1 terminations MACs (Modem Access Cards) supporting modem ports SCC (System Control Card) supporting Ethernet links with packet network
4 x 1Gb/s packet bus 800 Mb/s TDM bus Four 18-slot CVX1800 shelves can be housed in a frame
Packet network terminations support both bearer connections and DSM-CC control connections with GWC
Figure 41: Logical configuration of a CVX1800
Nortel Networks
PROPRIETARY
Page
130
Part B Hardware
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).
Page
131
Nortel Networks
PROPRIETARY
Part B Hardware
B2.11.4 Summary of CVX1800 Characteristics

B2.11.4.1 Applications Supported ! ! RAS VoIP
B2.11.4.2 GWC-Gateway Signalling Physical connections for VoIP ! ! GWC termination 100BaseT Ethernet terminated on GWC card in SAM21 Gateway termination 10/100BaseT Ethernet terminated on SCC in MG9000
Device / media control signalling: ! ! DSM-CC / UDP / IP
Call control signalling: 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
B2.11.4.4 Packet Network Bearer Connections ! 10/100 Mb/s Ethernet interface terminated on SCC in CVX1800
Nortel Networks
PROPRIETARY
Page
132
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.
Nortel Networks
PROPRIETARY
Page
133
Part B Hardware
Chapter B3 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.
Nortel Networks
PROPRIETARY
Page
134
Part B Hardware
B3.2
B3.2.1
AudioCodes MS2000 Series (MS2010 / MS2020)

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 Shape and size Logical modules per chassis Technology MS2010 (for VoIP) 1U (1.75") chassis MS2020 (for VoATM) 2U (3.5") chassis
Designed for horizontal mounting in standard 19" frame Two logically separate media server modules, each with its own IP address and MAC address AudioCodes IPM-1610 Up to six MS2010s in CS2000-Compact CCF; up to ten MS2010s in SAMF PTE2000 frame (XA-Core configuration or additional capacity for CS2000-Compact) AudioCodes TP-6310 Up to five MS2020s in SAMF PTE2000 frame (CS2000-Compact and XA-Core configurations)
CS2000 housing
H.248 signalling to/from AC GWC via Ethernet connections with CS LAN PP8600s Connections Bearer connections with backbone network via Ethernet connections with CS LAN PP8600s 120 ports per module; 240 ports per chassis Capacity 240 simultaneous announcements [1] 80,000 BHCA Software load [2] Software order code MS200070 AMS 4.4 MS2A0070 Terminations for direct STM-1 carrier corrections with backbone network for bearer traffic using AAL2 / ATM 240 ports per module; 480 ports per chassis 480 simultaneous announcements [1] 60,000 BHCA
[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.
Page
135
Nortel Networks
PROPRIETARY
Part B Hardware
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 bearer connections IPM-1610 cPCI board supporting two logical media server modules
Module 0 Dual redundant 100BaseT Ethernet ports connected to CS LAN PP8600s for: H.248 signalling to/from Audio Controller GWC via signalling VLAN Bearer connections via bearer VLAN
Local storage for approx. 40 minutes of audio
Module 1
MS2020 media server (as used in VoAAL2 solutions)

Logical ports (240 per module) for terminating packetised bearer connections TP-6310 cPCI board supporting two logical media server modules
Module 0 Local storage for approx. 40 minutes of audio
Dual redundant 100BaseT Ethernet ports connected to CS LAN PP8600s for H.248 signalling to/from Audio Controller GWC via signalling VLAN
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
Nortel Networks
PROPRIETARY
Page
136
Part B Hardware
B3.2.2
B3.2.2.1 Applications Supported ! VoIP B3.2.2.2 GWC-MS2000 Signalling Physical connections: ! Dual redundant 10/100BaseT Ethernet connection between GWC and media server Media / bearer control protocols: ! H.248 Call control protocols: ! N/A B3.2.2.3 PSTN / TDM Access 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. B3.2.2.4 Packet Network Bearer Connections 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)
Page
137
Nortel Networks
PROPRIETARY
Part B Hardware
B3.3
B3.3.1
Universal Audio Server (UAS)

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.
Nortel Networks
PROPRIETARY
Page
138
Part B Hardware
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.
Page
139
Nortel Networks
PROPRIETARY
Part B Hardware
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 bearer connections
CG6000 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) for terminating packetised bearer connections
AG4000 DSPs
PA200 card set PA200 card R200 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)
Nortel Networks
PROPRIETARY
Page
140
Part B Hardware
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.
Page
141
Nortel Networks
PROPRIETARY
Part B Hardware
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.
B3.3.5
B3.3.5.1 Applications Supported ! VoIP ! VoATM B3.3.5.2 GWC-UAS Signalling Physical connections: ! 10/100BaseT Ethernet connection between GWC and gateway Media / bearer control protocols: ! H.248 Call control protocols: ! N/A
Nortel Networks
PROPRIETARY
Page
142
Part B Hardware
B3.3.5.3 PSTN / TDM Access 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. B3.3.5.4 Packet Network Bearer Connections 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.
B3.3.5.7 Feature Support 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)
Page
143
Nortel Networks
PROPRIETARY
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. 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 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
Nortel Networks
PROPRIETARY
Page
144
Chapter B4 CentrexIP Remote Clients
Part B Hardware
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 remote CentrexIP clients using three 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 the CICM GWC and the CICM. UniStim signalling is used between CICM and remote CentrexIP clients.
CS2000 CS LAN
CS2000 Core
GWC for CICM
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 UniStim
IP core network
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 reception via headset. Call control via CentrexIP client application GUI.
Bearer connections for non-VoIP-related data sessions are independent of CS2000
Figure 44: CS2000 support for CentrexIP line access
Page
145
Nortel Networks
PROPRIETARY
Part B Hardware
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.
PROPRIETARY Page
Nortel Networks
146
Part B Hardware
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
Standard numeric keypad for point-and-clic k dialling
Feature keys with dynamically assigned functons
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 downloading an appropriate set of feature key assignments.
147
Nortel Networks
Part B Hardware
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.
PROPRIETARY Page
Nortel Networks
148
Part B Hardware
B4.3
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
Page
149
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
150
Part B Hardware
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.
Page
151
Nortel Networks
PROPRIETARY
Part B Hardware
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 CICM audio profile G.729 only G.729 then G.711 G.711 then G.729 G.711 only G.729 only G.729 then G.711 G.711 then G.729 G.711 only
[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.
Codec choice indicated by GWC
Result of negotiation (codec used for call) Call attempt cleared G.711 G.711 G.711 G.729 G.729 then G.711 [2] G.711 G.711
G.711 only
G.729 then G.711 [1]
Nortel Networks
PROPRIETARY
Page
152
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
B5.1.1
Media Proxy Functions

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.
Nortel Networks
PROPRIETARY
Page
153
Part B Hardware
Chapter B5 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: ! ! 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).
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.
Nortel Networks
PROPRIETARY
Page
154
Part B Hardware
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.
Page
155
Nortel Networks
PROPRIETARY
Part B Hardware
B5.2
B5.2.1
RTP Media Portal

Functional Overview
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 GWC
CentrexIP GWC MPCP H.248 Uni CICM
Public address discovery for signalling Enterprise network (private address domain) Private Public
MGCP UniStim Enterprise network (private address domain) Public Private
Media portal controller
RTP media portal

Media packet engine on peripheral card Two-way NAT functionality for RTP/UDP media stream
Line gateway on LAN
Firewall (NAT/NAPT)
Public address discovery for media stream
Firewall (NAT/NAPT)
CentrexIP client
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
Nortel Networks
PROPRIETARY
Page
156
Part B Hardware
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 Private VoIP domain Public domain / DMZ MP with one private VoIP I/F and one public I/F direct to gateway Enterprise domain MP with one private VoIP I/F and one public I/F to enterprise NAT device MP with two public I/Fs, one direct to gateway and one to enterprise NAT device No MP if both GWs in same domain; otherwise, MP with two public I/Fs to enterprise NAT devices
Location of originating media gateway
No MP required
Public domain / DMZ
MP with one private VoIP I/F and one public I/F direct to gateway
No MP required
Enterprise domain
MP with MP with two public I/Fs, one private VoIP I/F one direct to gateway and one public I/F to and one to enterprise NAT device enterprise NAT device
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.
Page
157
Nortel Networks
PROPRIETARY
Part B Hardware
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
Call processing and service logic (CS2000 Core) GWCs for media gateways GWCs for DPTs to/from peer MGCs
CS2000
Call processing and service logic (CS2000 Core) GWCs for DPTs to/from peer MGCs GWCs for media gateways
MG in VoIP address domain (private)
MG in VoIP address domain (private)
TSPs VoIP address domain (private) Private addresses
Media Portal (MP)

Public addresses
MG in public / common address domain (no NAT)
Public / common address domain (DMZ)
MG in public / common address domain (no NAT)
Public addresses
Public addresses
NAT
Private addresses
NAT
Private addresses
MG in enterprise address domain (behind NAT)
Other private address domains, e.g. for enterprise VPNs
MG in enterprise address domain (behind NAT)
Figure 47: Media gateway locations in terms of address domains
Nortel Networks
PROPRIETARY
Page
158
Part B Hardware
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.
Page
159
Nortel Networks
PROPRIETARY
Part B Hardware
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 Transparency Application (ITA)
Gateway topology data
Connection broker
MB lookup (Middlebox data)
GWC
Gateway control engine (MGCP or H.248) MPCP engine (for RMP)
Line gateway or CICM
Media portal
Figure 48: Interaction between GWC components to for media portal control
Nortel Networks
PROPRIETARY
Page
160
Part B Hardware
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.
Page
161
Nortel Networks
PROPRIETARY
Part B Hardware
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 Two RTP media portal units per SAM16 shelf Each unit comprises a host CPU card, and up to six peripheral cards supporting media packet engines Peripheral cards with media packet engines
Host CPU card has two 100BaseT Ethernet ports, but uses only one Connection with CS LAN PP8600 for MPCP signalling to/from GWC, and for OAM&P signalling to/from MCS Manager
Logical UDP ports for terminating packetised bearer connections for which NAPT functionality is provided
Each peripheral card has two 100BaseT Ethernet ports for RTP streams. These ports face different address domains, enabling the RTP portal to act as a bridge between those domains. 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.
Nortel Networks
PROPRIETARY
Page
162
Part B Hardware
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.
Page
163
Nortel Networks
PROPRIETARY
Part B Hardware
B5.2.6
B5.2.6.1 Applications Supported ! VoIP B5.2.6.2 GWC-MP Signalling Physical connections: ! 10/100BaseT Ethernet connection between GWC and gateway Media / bearer control protocols: ! MPCP Call control protocols: ! N/A B5.2.6.3 PSTN / TDM Access The RTP Media Portal does not have to support PSTN / TDM access directly. It communicates only with packet network endpoints. B5.2.6.4 Packet Network Bearer Connections 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 B5.2.6.6 Feature Support ! ! Controlled NAT functionality for media stream traversal of address domain boundaries Controlled firewall functionality for VoIP private address domain
Nortel Networks
PROPRIETARY
Page
164
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.
Nortel Networks
PROPRIETARY
Page
165
Part B Hardware
Chapter B6 Multimedia Communication Server (MCS52000)
B6.2
B6.2.1
MCS5200 Components
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.
"
Nortel Networks
PROPRIETARY
Page
166
Part B Hardware
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.
Page
167
Nortel Networks
PROPRIETARY
Part B Hardware
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.
Nortel Networks
PROPRIETARY
Page
168
Part B Hardware
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 private VLAN Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No MCS5200 public VLAN Yes No No No Yes Yes Yes Yes No No No No No Backbone network Yes [1] No No No Yes [1] Yes [1] Yes [1] Yes [1] No No Yes Yes Yes
MCS5200 Application Module MCS5200 Database Module MCS5200 Accounting Module MCS5200 Management Module MCS5200 Provisioning Module IP Client Manager (IPCM) Web Client Manager (WCM) RTP Media Portal Audio Server SIP PRI Gateway Remote IP client Remote Web client Remote SIP multimedia client
[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.
Page
169
Nortel Networks
PROPRIETARY
Part B Hardware
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) SDM EMs on Sun servers EMs on PCs MCS5200 private VLAN Database Module Mgmt Module
CS2000 bearer VLAN Media server DSPs Media server USP Core Media server CPU GWCs
Private VLAN
Accounting Module
Provisioning Module
MCS5200 Audio Server
SIP PRI Gateway
CS2000 call processing VLAN (signalling only)
MCS5200 Application Module
IP Client Manager
Web Client Manager
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 entering/leaving CS LAN. NAT traversal makes communication possible between different private domains. CS2000 portal is controlled by a GWC. MCS5200 portal is controlled by the MCS5200 AM. CS2000-related signalling across the core network between: GWCs and remote media gateways CS2000 Core and peer MGCs
Dual PP8600s MCS5200-related signalling across the core network between: IP Client Manager and remote IP telephony clients such as i2004 Ethersets Web Client Manager and remote Web clients to permit browser access to multimedia servers MCS5200 Application Server and remote multimedia clients such as SIP PC clients and SIP IP phones
RTP Media Portal
RTP Media Portal
Packet backbone network Figure 50: Logical configuration of MCS5200 deployed alongside CS2000
Nortel Networks
PROPRIETARY
Page
170
Part C Software
Part C Software
Chapter C1 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
Nortel Networks
PROPRIETARY
Page
172
Part C Software
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.
Page
173
Nortel Networks
PROPRIETARY
Part C Software
Figure 51 illustrates the layered structure of the software in the CS2000 Core software load used by CS2000 in ISN07.
Product Layer
World Trade DRU (WT20), comprising market-specific custom software and general-purpose international software Common software (CCM20)
(lines software applicable both internationally and in Nth America)
TOPS DRU (TOPS20), comprising operator services software. (in load, but functionality is not supported in ISN07)
MSH (Multi-Service Hub) DRU (MSH20), supporting CS2000-related connectivity)
Shared Library (SHR20)

(software applicable for other Nortel products as well as CS2000)
Call processing support
CSP20 Platform
Telecom Layer (TL20)
Peripheral support
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.
Nortel Networks
PROPRIETARY
Page
174
Part C Software
Table 8: Order codes for base capabilities provided by CS2000 Core

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

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
GWC (Gateway Controller) SC (SAM21 Shelf Controller)
Software Load
GC070 SCU10
C1.2.2
Signalling Peripheral Software Loads

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

Table 11: ISN07 miscellaneous component loads Peripheral
PP8600 router Session Server ISM IOM ENET (optional, for use with OAU) OAU (optional) MS
Software Load
Rel 3.7 NGSS07 MTMKA02 IOMR ENC17 MTMKA02 MUC20
Nortel Networks
PROPRIETARY
Page
176
Part C Software
C1.2.4
Firmware Loads
Table 12: ISN07 firmware loads Peripheral
XA IOP (OC-3) HIOP (100BaseT Ethernet) 6X17BA Ethernet packlet for IOP GWC firmware MS (Port Card)
Firmware Load
XAIO01AK XHIO02 EP14DO03 RM07 MPF17
C1.2.5
Software Order Codes

Table 13: Order codes for base capabilities provided by other CS2000 components
Order code GWCW0070 SAM20070 CICM0070 NGSS0070 RMPx0070 MS200070 MS2A0070 UASA0008 GSS00033 GSSB0002 GSSB0003 GSSB0004 GSSB0006 APS00007 APSB0007 USP00090 USPL0090 SSAS0001 SSAS0002 SSAS0004 SSAS0005 SSAS0007 SSAS0011 SSAS0012 SSAS0013 SSAS0014 Name / description Gateway Controller NCL (inc. RMGC) Service Application Module NCL CentrexIP Client Manager Session Server RTP Media Portal MS2010 MS2020 Universal Audio Server NCL Global Server SW Rel 3.2 NCL for UAS 3rd Party MS Windows 2000 OS 3rd Party MS Windows 2000 Res kit Windows Terminal Services Client Ghost Enterprise Software Audio Provisioning Server NCL 3rd Party AdventNet 4.1 Universal Signalling Point Server NCL Basic Universal Signalling Point - Compact SSAS Basic Platform Basic OAM&P IP High Speed Link SSOMs GUI Workstation Routeset 256 to 511 Routeset 512 to 767 Routeset 768 to 1023 Routeset 1024 to 1279
Page
177
Nortel Networks
PROPRIETARY
Part C Software
Table 13: Order codes for base capabilities provided by other CS2000 components
Order code SSAS0015 SSAS0016 SSAS0017 SSAS0018 SSAS0019 SSAS0021 Name / description Routeset 1280 to 1535 Routeset 1536 to 1791 Routeset 1792 to 2047 Routeset 2048 to 4000 ITU High Speed Link OSS Electronic CLI
C1.3
C1.3.1
Loads for Media Gateways and Servers

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

Table 15: Media server loads available for deployment with ISN07 Unit
MS2000 Series (MS2010 and MS2020) UAS
Load
AMS 4.4. UAS08MR
Nortel Networks
PROPRIETARY
Page
178
Part C Software
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
CS2000 Core Manager CS2000 Management Components [1] IEMS PP8600 Manager APS PMDM (PVG) MG9000 EM Cuda Provisioning Manager
Platform
CBM (Core and Billing Manager) on Netra 240 SDM (SuperNode Data Manager) on Series FX (AIX) Sun Netra 240 Sun Netra 240 (shared) Windows PC / Sun workstation Sun Netra 240 Sun Netra 240 Sun Netra 240
Load
CBM00070 CS2E07 CS2M07 IEMS0070 Device Manager Version 5.7 APS09 PMDM 15.1 9KEM0070 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.
Page
179
Nortel Networks
PROPRIETARY
Part C Software
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. QCA (QoS Collector Application) 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
Nortel Networks
PROPRIETARY
Page
180
Part C Software
C1.4.3
Software Order Codes

Table 17: Order codes for OAM&P software
Order code CBM00070 CS2E0070 ATA00001 CNCD0004 CNCD0006 CNOM0001 CNOM0002 ENTA0001 SBM00001 SBM00003 SBM00006 SFT00001 CS2M0070 SAMM0021 UASM0001 CICE0070 SPFS0070 LCS00015 LCS00019 LCS00020 NSW00007 Name / description CS2000 Core Manager NCL (CBM) CS2000 Core Manager NCL (SDM) ASCII Terminal Access Gateway CNCD RTB OFT Billing Filtering CNOM PH 1 CNOM OM 02 Enhanced Terminal Access Billing Appl Base AMADNS DDI I/F SBA-SMDR Secure File Transfer CS2000 Management Components (GWC, UAS, APS, SAM21) SAM21 EMS Universal Audio Server EMS CICM EM Succession Solutions Platform Software 3rd Party NCL Oracle Enterprise 817 3rd Party License AdventNet SNMP V3 Platform 3rd Party License ILOG JView Platform 3rd Party License ISN07 Non-Resident Load NCL
Page
181
Nortel Networks
PROPRIETARY
Chapter C2
C2.1
Trunk and Line Datafill
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.
Nortel Networks
PROPRIETARY
Page
182
Chapter C2 Trunk and Line Datafill
Part C Software
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).
Page
183
Nortel Networks
PROPRIETARY
Part C
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).
"
Nortel Networks
PROPRIETARY
Page
184
Part C Software
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).
Page
185
Nortel Networks
PROPRIETARY
Part C
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)
Nortel Networks
PROPRIETARY
Page
186
Part C Software
C2.3.3
Trunk Provisioning Flowcharts (TDM-Side)

See document CS2000 Configuration (NN10193-511)
START Add trunk endpoints via GWC Manager Capture Node and Terminal numbers
Add new trunk group name to table CLLI Add trunk group data to table TRKGRP N Add trunk group data to table TRKSGRP Add trunk group data to table TRKOPTS
Captured Node and Terminal numbers
Is carrier already provisioned on gateway [Y/N]? Y
Provision carrier on gateway

(Carrier can be provisioned in advance, before trunk endpoints are added)
Does trunk group already exist [Y/N]? Y
Does N CCS7 route for new trunk group already exist [Y/N]? Add CCS7 link/route and Y destination data to associated dependent tables
Add trunks to table TRKMEM using captured Node and Terminal numbers 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 (optional) RTS trunk members on TMM FINISH Figure 52: Provisioning CCS7 trunks
Add CCS7 destination information to table ISUPDEST
Running COT test from far-end switch verifies provisioning and hardware connections before traffic is allowed
Page
187
Nortel Networks
PROPRIETARY
Part C
START
Add trunk endpoints via GWC Manager using PRI option

See document CS2000 Configuration (NN10193-511)
Add new trunk group name to table CLLI
Capture Node and Terminal numbers for D-channel and B-channels
Add trunk group data to table TRKGRP 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
Is carrier already provisioned on gateway [Y/N]? Y
Add logical terminal data to table LTGRP
Provision carrier on gateway

(Carrier can be provisioned in advance, before trunk endpoints are added)
Add logical terminal data to table LTDEF
Add logical terminal data 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
Nortel Networks
PROPRIETARY
Page
188
Part C Software
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)
Page
189
Nortel Networks
PROPRIETARY
Part C
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).
Nortel Networks
PROPRIETARY
Page
190
Part C Software
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
Dynamic Packet Trunks for inter-CS signalling 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. 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. 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), 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.
Page
191
Nortel Networks
PROPRIETARY
Part C
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.
Nortel Networks
PROPRIETARY
Page
192
Part C Software
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.
Page
193
Nortel Networks
PROPRIETARY
Part C
C2.6.5
Trunk Provisioning Flowchart (Packet-Side)

START
Add new members to existing SIP-T trunk group [Y/N]? Y
Does destination for new trunk group already exist [Y/N]? Y
Add new destination (name of remote CS2000) to table MGCINV
Add new trunk group name to table CLLI Is the new destination served by an existing VRDN [Y/N]? Y Add trunk group data to table TRKSGRP Add new VRDN definition to table VRDNINV N
Add trunk group data to table TRKGRP
Add trunk group data to table TRKOPTS
Add remote MGC name to RMGCLIST in table VRDNINV
Are the new trunks required to increase capacity [Y/N]? N
Add remote MGC name to table TELEPROF
Add new SIP-T GWC definition to table SERVSINV
Add new range of SIP-T trunks to table DPTRKMEM BSY SIP-T pool from DPTTRM level of MAP BSY SIP-T pool members from DPTMEM level of MAP
The decision about whether to add a new SIP-T GWC or a new VRDN depends on the amount of capacity that needs to be engineered to handle the traffic between two CS2000s (see section 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
Nortel Networks
PROPRIETARY
Page
194
Part C Software
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 Perm1 slave_role source_slave master_role source_slave any_role master_role slave_role master_role any_role slave_role any_role source_slave Perm2 source_slave master_role source_slave any_role source_slave slave_role master_role any_role master master_role slave_role source_slave ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> Result of dynamic role modification Incoming GWC slave slave master slave slave master slave master slave slave master slave Outgoing GWC master master slave master master slave master slave master master slave master
Page
195
Nortel Networks
PROPRIETARY
Part C
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.
PROPRIETARY Page
Nortel Networks
196
Part C Software
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.
Page
197
Nortel Networks
PROPRIETARY
Part C
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.
Nortel Networks
PROPRIETARY
Page
198
Part C Software
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 I2002 i2001 Etherset I2004 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.
199
Nortel Networks
Part C
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.
Nortel Networks
PROPRIETARY
Page
200
Part C Software
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 at NOC
1
CMTS / MTA management application Central servers LDAP server DNS server
5c 5b 6b 6c
4a
3a 8a 8b
CS2000 provisioning applications on Sun Netra server

4b 3b
CS2000 Core
GWC for MTA gateway Backbone packet network
DHCP server
5d 5a
TFTP server
6d 6a
CS LAN (CallP VLAN) PP8600 routers
MTA gateway
Figure 55: Information flows for MTA gateway provisioning
Page
201
Nortel Networks
PROPRIETARY
Cable access network
CMTS
Part C
The sequence of events is summarised in the following table. Table 19: Sequence of events for MTA gateway provisioning
Step 1 2 NOC From To At NOC LDAP server CS2000 provisioning applications GWC LDAP Via Purpose / content Craftsperson decides which GWC will host MTA gateway NOC provides gateway data to LDAP server: FQDN, profile, GWC IP address NOC provides gateway data to CS2000 provisioning applications: FQDN, IP address = 0.0.0.0 CS2000 provisioning applications provision GWC with gateway data: FQDN, IP addr=0.0.0.0
3a
NOC CS2000 provisioning applications NOC CS2000 provisioning applications MTA DHCP server DNS server DHCP server MTA TFTP server LDAP server TFTP server MTA GWC DNS server
XML
3b
GWC EM
4a
CS2000 NOC provides line data to CS2000 provisioning SERVORD+ provisioning applications: applications DN and service information CS2000 Core DHCP server DNS server DHCP server MTA TFTP server LDAP server TFTP server MTA GWC DNS server GWC Core Manager DHCP DNS DNS DHCP TFTP CS2000 provisioning applications provision CS2000 Core with line data: DN and service information On first activation, MTA gateway sends DHCP request to DHCP server on CMTS DHCP server requests central DNS server to update gateway data: FQDN, IP address DNS server sends response / confirmation to DHCP server DHCP server sends IP address to MTA MTA requests TFTP server to provide gateway configuration data: gateway profile, GWC IP address TFTP server requests central LDAP server to provide gateway configuration data for MTA LDAP server sends gateway configuration data for MTA to TFTP server TFTP server creates configuration file and downloads it to the MTA gateway MTA sends RSIP registration request to GWC GWC requests DNS server to provide IP address corresponding to MTAs FQDN DNS server sends IP address of MTA gateway to GWC
4b 5a 5b 5c 5d 6a
6b 6c 6d 7 8a 8b
LDAP LDAP TFTP RSIP DNS DNS
Nortel Networks
PROPRIETARY
Page
202
Part C Software
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.
Page
203
Nortel Networks
PROPRIETARY
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).
Nortel Networks
PROPRIETARY
Page
204
Chapter C3 Translations and Routing
Part C Software
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. 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. 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 NCOS screening IBN translations Note: Within a private 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 Access code and authorisation screening Incoming trunk access Indirect subscriber access (to alternative operator network)
Universal translations
Line served by translating CS2000
Outgoing trunk
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.
Page
205
Nortel Networks
PROPRIETARY
Part C
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 Type of call Prem. Rate Adult Prem. Rate Info. International Mobile Operator National Local Free 0 Y Y Y Y Y Y Y Y NCOS values (in the column for each NCOS value, Y = call type permitted, N = call type to be barred) 1 2 3 4 5 6 7 8 9 10 11 12 N N N N N N N N Y N Y N Y N N N N N N N Y Y Y Y Y Y N N N N Y N N N Y Y Y Y Y N N N N N Y Y N N Y Y Y Y N N Y N Y Y Y Y Y Y Y Y N N Y Y Y Y Y Y Y Y Y Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
13 Y Y N N 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.
Nortel Networks
PROPRIETARY
Page
206
Part C Software
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.
Page
207
Nortel Networks
PROPRIETARY
Part C
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. 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.
POTS
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.
Nortel Networks
PROPRIETARY
Page
208
Part C Software
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.
Page
209
Nortel Networks
PROPRIETARY
Part C
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 2 3 4 Prefix Country code Area code 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 CONT DMOD TRMT Destination name has been found (though further digit collection may be necessary) Continue translation using another translation table Digit modification is required 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
Nortel Networks
PROPRIETARY
Page
210
Part C Software
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 GRP2XLA CODE table GRP1XLA GRP1XLA Multiple CODE GRP1XLA and RTE entries (translators) for each name RTE table defined in the GRP1XLA HEAD table GRP1XLA
<default options> <default options> <digit range> <digit range> <digit range> <translation result = CONT> <translation result = DMOD> <translation result = RTE DEST 1> <route selector> <route selector>
<route reference = 1> <route reference = 2>
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) 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. 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).
CODE
RTE
Page
211
Nortel Networks
PROPRIETARY
Part C
The translation process is summarised in Figure 58.

Direct subscriber access Incoming trunk access ( trunks all assigned to default customer group) Indirect subscriber access (authorisation required)
Origin of call determines customer group CUSTHEAD identifies customer group translator XLANAME selects default universal translator via LINEATTR index
Access code or carrier ID prefixed to CdPA determines target network 2 dialling options for direct access
Feature (de)activation code Local number IBN translations (table CUSTHEAD identifies customer group translators)
5 dialling options for direct access
Service number Long-distance number International number
One-stage dialling Incoming calls screened on subscriber CLI
Two-stage dialling
Incoming calls screened on dialled authcode
IBNXLA selects preliminary translator via LINEATTR index
No IBNXLA entries for these calls, so default XLANAME LINEATTR index is used
Dialled CdPA determines call destination
LINEATTR Access to PXCODE prefix translations
PXCODE service translator appends CS2000 ID for service calls PXCODE local PSTN translators insert area codes for local calls
Prefix translation tables PXHEAD, PXCODE, PXRTE
PXCODE national PSTN translator
Country code translation tables CTHEAD, CTCODE, CTRTE Area code translation tables FAHEAD, FACODE, FARTE Office translation tables OFCHEAD, OFCCODE, OFCRTE IBNXLA activates appropriate feature software
IBNRTE Lists line routes Line selection by DN
OFRT, FARTE, CTRTE Lists trunk routes Trunk group selection by CLLI
Figure 58: Universal translation tables and their functions
Nortel Networks
PROPRIETARY
Page
212
Part C Software
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.
Page
213
Nortel Networks
PROPRIETARY
Part C
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.
Nortel Networks
PROPRIETARY
Page
214
Part C Software
Figure 59 illustrates the use of universal screening tables.

Entry to US via enhanced CLI screening Tables DNSCRN / CLISRVPF Entry to US on trunk group basis Table TRKOPTS Entry to US from translations CCNTLRX selector
Table CCNTLGRP IBNXLA processing
Table DTMFSCRN
Table CALLCNTL
Table ACCTSCRN
DIGMAN manipulation
Universal Screening Tables
Table CGPNSCRN Screening based on CgPN digits
Table CDPNSCRN Screening based on CdPN digits
Table CDPNLSCR Screening based on CdPN length
Table NCOSSCRN Screening based on NCOS
Table CGRPSCRN Screening based on customer group
Table SINTSCRN Screening based on user-defined variables
Table CDNNSCRN Screening based on CdPN NOA and NPI
Table NOASCRN Screening based on CgPN NOA
Table BCSCRN Screening based on BC
Table CICSSCRN Screening based on CIC
Table RDRISCRN Screening based on redirecting information
Table VARDEF Variable definitions
Table CKTSCRN Screening based on FGD ISUP CKT
Table IPISCRN Screening based on ISDN Pref. Ind.
Table CPCNSCRN Screening based on CPC
Table OLISCRN Screening based on FGD ISUP OLI
Figure 59: Interactions betwen translations and universal screening tables
Page
215
Nortel Networks
PROPRIETARY
Part C
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. 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). 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. The second media gateways acknowledgement of the CRCX returns a media description line for each codec / packetisation rate pair that it can support. 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.
2 3 4 5
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.
Nortel Networks
PROPRIETARY
Page
216
Part C Software
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 Table TRKOPTS IBN translations tables IBNXLA and XLANAME xxCODE tables in universal translations CALLCNTL and Universal Screening tables [1] Screening table DNSCRN [2] Service profile table CLISRVPF [3] To enable codec selection based on Incoming or outgoing trunk group Called party digits Called party digits or called party NOA) A variety of parameters CLI or calling party NOA 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.
Page
217
Nortel Networks
PROPRIETARY
Part C
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.
Nortel Networks
PROPRIETARY
Page
218
Part C Software
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).
Page
219
Nortel Networks
PROPRIETARY
Part C
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.
Nortel Networks
PROPRIETARY
Page
220
Part C Software
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
Page
221
Nortel Networks
PROPRIETARY
Part C
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, FARTE, CTRTE)
Datafill determines whether to apply conditional routing criteria, e.g. Least Cost Routing (LCR) or Time Of Day (TOD) routing CLLI Route list contains up to eight entries. These are typically CLLIs, but special entries are also supported. Search for idle trunk in coresponding trunk group using specified search algorithm Try next entry in route list
Route list
No
Idle trunk found? 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.
Nortel Networks
PROPRIETARY
Page
222
Part C Software
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.
Page
223
Nortel Networks
PROPRIETARY
Part C
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
PROPRIETARY Page
Nortel Networks
224
Part C Software
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 HTR / direct route HTR / Alternate Route Other / direct route Other / Alternate Route Level 1 x% Blocked x% Blocked No effect No effect Level 2 75% Blocked 100% Blocked x% Blocked 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.
Page
225
Nortel Networks
PROPRIETARY
Part C
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.
Nortel Networks
PROPRIETARY
Page
226
Part C Software
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.
Page
227
Nortel Networks
PROPRIETARY
Part C
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.
Nortel Networks
PROPRIETARY
Page
228
Part C Software
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 e s compression algorithm echo cancellation silence suppression x-ccd (clear channel data) off 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
Order code LOC00005 IXLS0003 IXLS0005 IXLS0006 IXLS0008 IXLS0012 IXLS0014 IXLS0015 IXLS0016 Name / description Dial Plan Translation Enhancements NCOS/CUST GRP allocation CPC Routing Called Number Parameter Charge Category Based Routing ISUP Reroute on Congestion Call Control Class of Service Screening CLI Delivery Control
Page
229
Nortel Networks
PROPRIETARY
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.
Page
231
Nortel Networks
PROPRIETARY
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
Nortel Networks
PROPRIETARY
Page
232
233
Page
Chapter D1 Overview
D1.1
DMC for PVG trunk DMC+CC gateways for telco (supergateways seded by DMC+CC H.248 for except MS/UAS for QSIG) H.248 ASPEN
DMC for PVGs
DMC+CC DMC+CC DMC+CC DMC+CC DMC+CC DMC+CC for units for for cable for LAN for RTP for RAS controlled CentrexIP CPE CPE Media via via H.323, remote gateways gateways Portal CVX1800 e.g. clients (MTAs) IP PBXs, routers
Backhauled CC for PRI, QSIG off PVG
Backhauled CC for V5.2 off PVG
EncapPeer-tosulated peer CCS7 signalling between between CS2000s CS2000 and MCS5200
CCS7 across CS LAN
Peer-topeer NCAS between CS2000s
Figure 61: Protocol stacks for packet network signalling
Packet Network Protocol Stacks
H.323 (H.450 and H.245 over H.225 CC based on Q.931)
UniStim
NCS
MGCP
MPCP
DSM-CC
Q.931 Layer 3 (PRI, QSIG)
V5.2 Layer 3
SIP-T CCS7 (ISUP, TUP) via MIME SDP via MIME
SIP IBN7 ISUP emulation
CCS7 (ISUP, TUP, TCAP)
CCS7 (TCAP only)
SDP in-line
SDP in-line
SDP in-line
SDP in-line
No SDP; RTP Media Portal not involved in codec negotiation
Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities
MTP3 SDP via MIME
Nortel Networks
PROPRIETARY
IUA
V5UA
M3UA
M2PA
UDP
UDP
UDP (RAS) / TCP (CC) IP
RUDP UDP
UDP
UDP
UDP
UDP
SCTP
SCTP
TCP (SS) TCP (SS) / UDP / UDP (VRDN) (VRDN)
SCTP
SCTP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
ASPEN Proprietary DMC protocol based on MGCP CC Call control CPE Customer Premises Equipment DMC Device / media control DSM-CCDigital Storage Media Command and Control H.248 Joint ITU-T and IETF protocol for MGC - MG signalling H.323 ITU-T multi-protocol architecture for multimedia services (comprises H.225 RAS and CC conveying H.450 and H.245 data) IP Internet Protocol IUA ISDN User Adaptation M2PA MTP2-User Peer-to-Peer Adaptation (for conveying MTP MSUs) M3UA MTP Layer 3 User Adaptation (for conveying CCS7 messages) MGCP IETF-defined Media Gateway Control Protocol MIME Multi-purpose Internet Mail Extensions (encapsulation mechanism) MPCP Media Proxy Control Protocol (for controlling RTP Media Portal)
MSU Message Signal Unit MTP CCS7 Message Transfer Part MTP3 MTP Layer 3 NCAS Non Call Associated Signalling NCS Network-based Call Signalling RAS H.323 Registration, Admission and Status RAS Remote Access Service RUDP Reliable UDP (defined as appendix to UniStim) SCTP Stream Control Transmission Protocol (reliable transport) SDP Session Description Protocol (for codec negotiation) SIP-T Session Initiation Protocol for Telephony TCP Transaction Control Protocol (reliable transport) UDP User Datagram Protocol (best-effort transport) UniStim Protocol for controlling CentrexIP remote clients V5UA V5.2 User Adaptation
CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols
Chapter D1 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.
Nortel Networks
PROPRIETARY
Page
234
Chapter D1 Overview
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.
Page
235
Nortel Networks
PROPRIETARY
Chapter D1 Overview
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 GWC V5.2 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 Gateway
Media Gateway For both types of gateway, B-channels are mapped on to packet network bearer commections; signalling is backhauled to the CS2000
30B+D PRI or QSIG access Digital PBX or PRI-enabled device
V5.2 AN interface (<16 E1s) V5.2 Access Network (AN)
Figure 61: Use of SCTP to provide reliable transport for backhauled call controlsignalling
Nortel Networks
PROPRIETARY
Page
236
Chapter D1 Overview
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
ISUP CS2000 Core
TUP M3UA SCTP IP
TCAP SCCP USP TCAP SCCP MTP3 M2PA SCTP IP IP control network over backbone packet network
CS LAN
Figure 62: Use of SCTP to provide reliable transport for CCS7 signalling
Page
237
Nortel Networks
PROPRIETARY
Other CS2000s, peer MGCs
Chapter D1 Overview
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.
Nortel Networks
PROPRIETARY
Page
238
Chapter D1 Overview
D1.3
D1.3.1
Session Descriptions (SDP)

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.
Page
239
Nortel Networks
PROPRIETARY
Chapter D1 Overview
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
Trunk or line Gateway Controller (GWC) DPT GWCs and Session Server; Egress packet-side
CS2000
DPT GWCs and Session Server; Ingress packet-side
A
Scenario A:- SDP used to complement access signalling SDP session description commands in-line with H.248, ASPEN, NCS or MGCP commands conveyed over UDP/IP
Media Gateway
B
Scenario B:- SDP used to complement inter-CS signalling UDP transport conveys one or two types of signalling, separately encapsulated in SIP messages using the MIME mechanism: SDP session descriptions Optional CCS7 messages (ISUP or TUP) SIP signalling terminates on Session Server; CCS7 signalling terminates on DPT GWC.
Figure 63: Use of SDP to complement access signalling and/or inter-CS signalling
Nortel Networks
PROPRIETARY
Page
240
Chapter D1 Overview
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 v o s i u e c b z k a t r Meaning Version Originator Session Information URI Email Connection Bandwidth Zone Key Attributes Time Repetition Format / content SDP version number UserID and host address
[1]
M/O M M [2] M [2] O O O M O O O O M [2] O
Information applicable to all media streams in a session
of session originator
Session name Information about session (descriptive text string) Universal Resource Identifier of session description Email address of session originator Target address
[1]
Bandwidth information Time zone information Encryption key Payload type (denoted by numeric identifier) and algorithm (e.g. G.711a for A-law PCM) Start time of session (0 for immediate start) Repetition information, e.g. initiate session weekly Media stream description, comprising: - Media type (typically audio in SNH01) - Destination port - Transport protocol, e.g. UDP or RTP - Media format (numeric identifier of payload type) Information about media stream (descriptive text string) Target address
[1]
Information applicable to one media stream within a session (overriding session information)
Medium
i c
Information Connection
O O
Page
241
Nortel Networks
PROPRIETARY
Chapter D1 Overview
Table 22: SDP session description lines and their use

Type b k a Meaning Bandwidth Key Attributes Format / content Bandwidth information Encryption key Payload type (denoted by numeric identifier) and algorithm (e.g. G.711a for A-law PCM) M/O O O O
[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, specified by address-type network-type is IN (meaning Internet)
and is of the type
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, specified by address-type
and is of the 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)
Page
Nortel Networks
PROPRIETARY
242
Chapter D2
D2.1 Purpose
SIP and SIP-T
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. Typically, SIP-T is used for signalling between CS2000s, while SIP is used for signalling between CS2000 and MCS5200. 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 designed to be compliant with RFC3261, which defines a SIP interface for open 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.
Nortel Networks
243
Chapter D2 SIP and SIP-T
D2.2
CS2000 Support for Dynamic Packet Trunks

Dynamic Packet Trunks for inter-CS signalling 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. 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. 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 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. 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. 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. ! 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. 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.
Nortel Networks
PROPRIETARY
Page
244
GWC support for inter-CS signalling using Session Server

Originating CS2000
Terminating CS2000
Access GWC
Session Server
Inter-CS connection
Session Server
Access GWC
Session Servers terminate SIP / SIP-T signalling Media gateway DPT GWCs terminate CCS7 signalling Media gateway
GWC support for inter-CS signalling using a VRDN

Originating CS2000
CS2000 Core Call processing DPT provisioning Inter-CS connection
Terminating CS2000
Access GWC
DPT GWC DPT GWC DPT GWC No VRDN for call origination
A B
VRDN GWC
Access GWC
A
Media gateway
Signalling for initial INVITE and redirection response is between DPT GWC and VRDN Media gateway
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
Page
245
Nortel Networks
PROPRIETARY
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) Envelope message MIME information Application = (e.g.) ETSI ISUP V1 SDP MIME information Application = SDP SIP header (msg type, source, dest, call ID, etc) TCP (Transaction Control Protocol) or UDP (User Datagram Protocol) IP Figure 65
Encapsulated CCS7 signalling (SIP-T only)
Information about packet network bearer capabilities (for codec negoitation between endpoints) SIP message type indicates its function, and can be mapped on to an IBN7 ISUP equivaloent (for SIP with no encapsulated CCS7) TCP for Session Server; UDP for VRDN / DPT GWC
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.)
Nortel Networks
PROPRIETARY
Page
246
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.
Page
247
Nortel Networks
PROPRIETARY
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
Nortel Networks
PROPRIETARY
Page
248
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 ISUP (ETSI V1) ISUP (Brazilian V1) ISUP (Czech V1) ISUP (Danish V1) ISUP (Italian V1) ISUP (Malaysian V1) ISUP (Mexican V1) ISUP (Norwegian V1) ISUP (Portuguese V1) ISUP (Spanish V1) ISUP (Telmex V1) Media type application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP Base etsi121 etsi121 etsi121 etsi121 etsi121 etsi121 etsi121 etsi121 etsi121 etsi121 etsi121 Version N/A br_etsi121 cz_etsi121 da_etsi121 it_etsi121 ma_etsi121 mx_etsi121 no_etsi121 pt_etsi121 es_etsi121 tm_etsi121
Page
249
Nortel Networks
PROPRIETARY
Message body content ISUP (Turkish V1) ISUP (ETSI V2) Australian ACIF G.500 I-ISUP Australian Telstra CA30 ISUP ISUP (Austrian V2) ISUP (Belgian V2) ISUP (Chilean V2) ISUP (Chinese V2) ISUP (German V2) ISUP (German G-ISUP V2) ISUP (Hong Kong V2) ISUP (Hungarian V2) ISUP (Israeli V2) ISUP (Italian V2) Japan I-ISUP ISUP (Polish V2) ISUP (Singapore V2) ISUP (Spanish V2) ISUP (Swedish V2) ISUP (Turkish V2) UK ISUP (ETSI V3) French ETSI V3 (SPIROU) ISUP (ANSI) ISUP (ANSI FGD) UK IUP / BTUP FTUP (SSUTR2) CTUP (China TUP)
Media type application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/ISUP application/TUP application/TUP application/TUP
Base etsi121 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 etsi356 ansi88 ansi88 gb_iup fr_ssutr2 ch_tup
Version tu_etsi121 N/A au_etsi356 au_etsi356 os_etsi356 bg_etsi356 chl_etsi356 ch_etsi356 de_etsi356 dg_etsi356 hk_etsi356 hu_etsi356 is_etsi356 it_etsi356 jp_etsi356 po_etsi356 sg_etsi356 es_etsi356 sw_etsi356 tu_etsi356 gb_etsi356 fr_etsi356 N/A N/A N/A N/A N/A
Nortel Networks
PROPRIETARY
Page
250
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.
Page
251
Nortel Networks
PROPRIETARY
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>
Nortel Networks
PROPRIETARY
Page
252
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
Page
253
Nortel Networks
PROPRIETARY
D2.6
D2.6.1
Service Support Capabilities

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.
Nortel Networks
PROPRIETARY
Page
254
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. MCS5200 delivers multimedia servers for SIP clients, including client managers who act 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)
Page
255
Nortel Networks
PROPRIETARY
Chapter D3
D3.1 Purpose
H.248
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.
Nortel Networks
256
Chapter D3 H.248
D3.2
D3.2.1
Network Role
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
Access Gateway Controller (GWC) TDM-side DPT GWC and Session Server; packet-side Inter-CS communication via SIP-T encapsulation of CCS7
CS2000
DPT GWC and Session Server; packet-side Access Gateway Controller (GWC) TDM-side
For CCS7 trunks, H.248 is used for all GWC-MG signalling (CCS7 signalling is groomed off, and does not traverse the packet network)
CCS7 trunk gateway
For PRI access, H.248 is one of two protocols used for GWC-MG signalling. Media control signalling uses H.248 (with SDP session description commands in-line) conveyed over UDP. Backhauled Q.931 Layer 3 call control signalling is conveyed over IUA and SCTP Bearer connection
PRI trunk gateway
PSTN or other TDM network Figure 66: Network role of H.248 signalling in supporting trunk access
PRI PBXs
Page
257
Nortel Networks
PROPRIETARY
Chapter D3 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
Access Gateway Controller (GWC) TDM-side DPT GWC and Session Server; packet-side Inter-CS communication via SIP-T encapsulation of CCS7
CS2000
DPT GWC and Session Server; packet-side Access Gateway Controller (GWC) TDM-side
For V5.2 access, H.248 is one of two protocols used for GWC-MG signalling. Media control signalling uses H.248 (with SDP session description commands in-line) conveyed over UDP. Backhauled V5.2 Layer 3 call control signalling is conveyed over V5UA and SCTP
V5.2 gateway
For MG9000 lines, H.248 is used for all GWC-MG messaging
Bearer connection
MG9000 gateway
V5.2 interface consisting of 1-16 E1 carriers
V5.2 Access Network (AN)
Analogue subscriber lines and ADSL lines
Figure 67: Network role of H.248 signalling in supporting line access
Nortel Networks
PROPRIETARY
Page
258
Chapter D3 H.248
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
GWCs Audio Controller GWC
H.248 commands, e.g. Add, controlling terminations and contexts (calls) Responses Media gateways supporting: Trunks Lines
Media server (MS2000 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.
Page
259
Nortel Networks
PROPRIETARY
Chapter D3 H.248
D3.3
D3.3.1
Functional Model
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.
Nortel Networks
260
Chapter D3 H.248
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.
Page
261
Nortel Networks
PROPRIETARY
Chapter D3 H.248
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
Nortel Networks
PROPRIETARY
Page
262
Chapter D3 H.248
! ! ! ! ! !
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.
Page
263
Nortel Networks
PROPRIETARY
Chapter D3 H.248
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 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 stream sourced/sunk by that termination), e.g. in or out of service A list of remote/local/localControl descriptors for a single stream Media stream characteristics that apply to a stream received by the media gateway from a remote entity. Media stream characteristics that apply to a stream sent by the media gateway to a remote entity.
Media
TerminationState Stream Local Remote
LocalControl Characteristics of the control connection between the media gateway and the MGC. Topology Specifies the direction(s) of media flow to be supported between 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 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 monitored event. Each Events descriptor has a RequestID that is used to correlate a monitoring request with the notifications that it may trigger.
Signals
Events
Nortel Networks
PROPRIETARY
Page
264
Chapter D3 H.248
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 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 of a monitored event.
DigitMap
ObservedEvents
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.
Page
265
Nortel Networks
PROPRIETARY
Chapter D3 H.248
D3.6
D3.6.1
Command Usage
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 2 GWC sends an Add command to the gateway, requesting it to add the specified TDM-side trunk endpoint to an unspecified context. 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. GWC sends another Add command to the gateway, requesting it to add a logical packet-side termination to the context. 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).
3 4
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.
Nortel Networks
266
Chapter D3 H.248
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
H.248 Notify command or V5UA (ESTABLISH) H.248 Modify endpoint Apply dial tone Collect digits against digit map
GWC
Caller goes off-hook

Dial tone
(1)
1st digit Digits matching digit map More digits
Dial tone removed
H.248 Notify endpoint Match against digit map H.248 Notify endpoint Additional digit
(2)
(3)
Onward call setup begins
H.248 Add endpoint to context Implicitly creates new context H.248 Add packet port to context H.248 Modify packet port SDP definition of port characteristics H.248 Modify endpoint Apply ringback tone Stop digit collection H.248 Modify endpoint Mode=sendrecv
Termination identified Apply ringing
Ringback tone
(4)
Ringback tone removed
(5)
H.248 Modify endpoint Stop ringback tone
Off-hook / answer
Call in progress
Figure 69: H.248 call setup (originating side only)
Page
267
Nortel Networks
PROPRIETARY
Chapter D3 H.248
Table 24: Example H.248 message formats for basic call setup
No. Description / format with single digit collection after DigitMap completion Request (GWC to MG)
MEGACO/1 [47.174.66.80]:2944 Transaction=62{ Context=1002{ 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.) } } } }
(1) Apply dial tone, request digit collection via DigitMap, embedded is the request to continue
Response (MG to GWC)
MEGACO/1 [47.166.34.20]:2944 Reply=62{ Context=1002{ Modify=E1/1/20/5 } }
(2) Notify DigitMap completion event

Request (MG to GWC)
MEGACO/1 [47.166.34.20]:2944 Transaction=22{ Context=1002{ Notify=E1/1/20/5{ ObservedEvents =2223 { 19990729T22010001:dd/ce{ds="91613555121 2",Meth=FM } } } } }
Response (GWC to MG)

MEGACO/1 [47.174.66.80]:2944 Reply=22{ Context=1002{ Notify=E1/1/20/5 } }
(3) Notify single DTMF event (e.g. DTMF digit 1)

Request (MG to GWC)
MEGACO/1 [47.166.34.20]:2944 Transaction=23{ Context=1002{ Notify=E1/1/20/5{ ObservedEvents =2224 { 19990729T22010003:dd/d1 } } } }

(4) Apply ringback tone and stop digit collection

Request (GWC to MG)
MEGACO/1 [47.174.66.80]:2944 Transaction=65{ Context=1002{ Modify=E1/1/20/5{ Signals {cg/rt}, Events } } }

(5) Stop ringback tone

Request (GWC to MG)
MEGACO/1 [47.174.66.80]:2944 Transaction=66{ Context=1002{ Modify=E1/1/20/5{ Signals { } } }

Nortel Networks
PROPRIETARY
Page
268
Chapter D3 H.248
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
No. Description / format 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 Transaction=45{ Context=${ Add=audio/$ } } MEGACO/1 [47.174.66.102]:2427 Reply = 45 { Context = 9 { Add = audio/audiopool0/2 } }
(1)
(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. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [47.174.66.20]:2944 Transaction=46{ Context=9{ Add=${ Media{ LocalControl{Mode=SendReceive}, Local{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=ptime:10 }, Remote{ v=0 c=IN IP4 47.174.67.3 m=audio 1086 RTP/AVP 0 a=ptime:10 }}}}} MEGACO/1 [47.174.66.102]:2427 Reply = 46 { Context = 9 { Add = te/tepool0/0 { Media { Local { v=0 c=IN IP4 47.174.66.103 m=audio 30216 RTP/AVP 0 a=ptime:10 } } } } }
Page
269
Nortel Networks
PROPRIETARY
Chapter D3 H.248
Table 25: Example H.248 message formats for announcement playback

No. Description / format 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. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [47.174.66.20]:2944 Transaction=47{ Context=9{ Modify=audio/audiopool0/2{ Signals{ aasb/play{ an="sid=<http://localhost/640>"} }, Events=33{ aass/audcomp,aass/audfail }}}} MEGACO/1 [47.174.66.102]:2427 Reply = 47 { Context = 9 { Modify = audio/audiopool0/2 } }
(3) Execute a play signal of segment 640 on the audio termination, requesting notification
Response (GWC to media server)

MEGACO/1 [47.174.66.20]:2944 Reply=103{ Context=9{ Notify=audio/audiopool0/2 }}
Message (media server to GWC)

MEGACO/1 [47.174.66.102]:2427 Transaction = 103 { Context = 9 { 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)
MEGACO/1 [47.174.66.20]:2944 Transaction=48{ Context=9{ Subtract=te/tepool0/0{ Audit{} }}}
Response (media server to GWC)

MEGACO/1 [47.174.66.102]:2427 Reply = 48 { Context = 9 { Subtract = te/tepool0/0 } }
(5) Subtract the audio termination from the context, thus ending the call.
Request (GWC to media server)
MEGACO/1 [47.174.66.20]:2944 Transaction=49{ Context=9{ Modify=audio/audiopool0/2{ Media{ LocalControl{Mode=Inactive} }}, Subtract=audio/audiopool0/2{ Audit{} }}}

MEGACO/1 [47.174.66.102]:2427 Reply = 49 { Context = 9 { Modify = audio/audiopool0/2, Subtract = audio/audiopool0/2 } }
Nortel Networks
PROPRIETARY
Page
270
Chapter D3 H.248
D3.6.3.2 Commands Used to Set Up Conferences Summary of most important commands used: ! 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
No. Description / format MEGACO 1.0, which has already been discussed for addition to the next version of the standard. 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=4{ Reply = 4 { Context = 1 { Context=${ ContextAttr { ContextAttr{ ctxr/type=conf,ctxr/size=3,ctxr/res=reserve ctxr/type = conf, }}} ctxr/size = 3, ctxr/res = reserve } } }
(1) Reserve a context for this conference, with a size of 3. ContextAttr is a Nortel proprietary addition to
(2) Add ephemeral termination for conference participant 1 to the reserved context.
MEGACO/1 [47.174.66.20]:2944 Transaction=5{ Context=1{ Add=${ Media{ LocalControl{Mode=SendReceive}, Local{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=ptime:10 }}}}}

MEGACO/1 [47.174.66.102]:2427 Reply = 5 { Context = 1 { Add = te/tepool0/0 { Media { Local { v=0 c=IN IP4 47.174.66.103 m=audio 30238 RTP/AVP 0 a=ptime:10 } } } } }
(3) Add ephemeral termination for conference participant 2 to the reserved context. (4)
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. Add ephemeral termination for conference participant 3 to the reserved context. 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.
Page
271
Nortel Networks
PROPRIETARY
Chapter D3 H.248
Table 26: Example H.248 message formats for conferencing

No. Description / format Request (GWC to media server)
MEGACO/1 [47.174.66.20]:2944 Transaction=8{ Context=1{ Modify=te/tepool0/0{ Media{ LocalControl{Mode=SendReceive}, Remote{ v=0 c=IN IP4 47.174.67.5 m=audio 1088 RTP/AVP 0 a=ptime:10 }}}}}
(5) Provide remote SDP for first ephemeral.

MEGACO/1 [47.174.66.102]:2427 Reply = 8 { Context = 1 { Modify = te/tepool0/0 } }
(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. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [47.174.66.20]:2944 Transaction=11{ Context=9{ Modify=te/tepool0/2{ Signals{ bcg/brt{btd="internal"} }}}} MEGACO/1 [47.174.66.102]:2427 Reply = 11 { Context = 1 { Modify = te/tepool0/2 } }

MEGACO/1 [47.174.66.20]:2944 Transaction=12{ Context=9{ Modify=te/tepool0/2{ Signals }}}

(9) At the end of the conference, subtract the third ephemeral from the conference.
MEGACO/1 [47.174.66.20]:2944 Transaction=13{ Context=1{ Subtract=te/tepool0/2{ Audit{} }}}

MEGACO/1 [47.174.66.102]:2427 Reply = 13 { Context = 1 { Subtract = te/tepool0/2 } }
(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.
Nortel Networks
PROPRIETARY
Page
272
Chapter D3 H.248
Table 26: Example H.248 message formats for conferencing

No. Description / format 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. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [47.174.66.20]:2944 Transaction=15{ Context=1{ ContextAttr{ctxr/res=release}, Subtract=te/tepool0/0{ Audit{} }}} MEGACO/1 [47.174.66.102]:2427 Reply = 15 { Context = 1 { ContextAttr { ctxr/res = release }, Subtract = te/tepool0/0 } }
(11) Subtract the first leg (last remaining leg) from the conference and unreserve the conference resources.
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. Summary of most important commands used: ! 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.
! !
Page
273
Nortel Networks
PROPRIETARY
Chapter D3 H.248
Table 27: Example H.248 message formats for Lawful Interception (LI)
No. Description / format media server replies that the context has been reserved. Request (GWC to media server)
MEGACO/1 [192.136.141.118]:2427 Transaction=3000{ Context=${ ContextAttr{ ctxr/type=bct, ctxr/size=4, ctxr/res=reserve }}}
(1) GWC tells media server to reserve a context for an LI call.

MEGACO/1 [47.171.164.21]:2945 Reply = 3000 { Context = 1 { ContextAttr { ctxr/type = bct, ctxr/size = 4, 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. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 Transaction=3001{ Context=1{ TP{$,*,IS}, Add=${ Media{O{MO=SR}, L{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=ptime:10 }}}}} MEGACO/1 [47.171.164.21]:2945 Reply = 3001 { Context = 1 { Add = te/tepool0/0 { Media { Local { v=0 c=IN IP4 47.171.164.211 m=audio 30000 RTP/AVP 0 a=ptime:20 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. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 Transaction=3002{ Context=1{ TP{$,*,IS}, Add=${ Media{O{MO=SR}, L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=ptime:10 }, R{v=0 c=IN IP4 47.171.164.190 m=audio 20002 RTP/AVP 0 a=ptime:10 }}}}} MEGACO/1 [47.171.164.21]:2945 Reply = 3002 { Context = 1 { Add = te/tepool0/1 { Media { Local { v=0 c=IN IP4 47.171.164.211 m=audio 30002 RTP/AVP 0 a=ptime:10 } } } } }
Nortel Networks
PROPRIETARY
Page
274
Chapter D3 H.248
No. Description / format media server replies that the modification has been successful. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 Transaction=3003{ Context=1{ Modify=te/tepool0/0{ Media{O{MO=SR}, R{ v=0 c=IN IP4 47.171.164.190 m=audio 20000 RTP/AVP 0 a=ptime:10 }}}}} MEGACO/1 [47.171.164.21]:2945 Reply = 3003 { Context = 1 { Modify = te/tepool0/0 } }
(4) GWC tells the media server to modify theSDP of the LI subjects termination with the associates SDP.
(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. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 Transaction=3004{ Context=1{ TP{ te/tepool0/0, te/tepool0/1, BW }}} MEGACO/1 [47.171.164.21]:2945 Reply = 3004 { Context = 1 { Topology { te/tepool0/0, te/tepool0/1, Bothway } } }
(6) GWC tells media server to add first LEA ephemeral connection LEA-1 to the context.
MEGACO/1 [192.136.141.118]:2427 Transaction=3005{ Context=1{TP{$,*,IS}, Add=${ Media{O{MO=SR}, L{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=ptime:10 }}}}}
media server replies that the ephemeral connection has been added. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [47.171.164.21]:2945 Reply = 3005 { Context = 1 { Add = te/tepool0/2 { Media { Local { v=0 c=IN IP4 47.171.164.211 m=audio 30004 RTP/AVP 0 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
Page
275
Nortel Networks
PROPRIETARY
Chapter D3 H.248
No. Description / format The media server replies that the Modify was successful. Request (GWC to media server)
MEGACO/1 [192.136.141.118]:2427 Transaction=3007{ Context=1{ Modify=te/tepool0/2{ Media{O{MO=SR}, R{ v=0 c=IN IP4 47.171.164.190 m=audio 20004 RTP/AVP 0 a=ptime:10 }}}}}
(8) GWC modifies ephemeral connection LEA-1 with the remote SDP from the LEA.
(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. Request (GWC to media server)
MEGACO/1 [192.136.141.118]:2427 Transaction=3008{ Context=1{ TP{ te/tepool0/1, te/tepool0/2, OW }}}
MEGACO/1 [47.171.164.21]:2945 Reply = 3008 { Context = 1 { Topology { te/tepool0/1, te/tepool0/2, Oneway } } }
(10) GWC modifies ephemeral connection LEA-2 with the remote SDP from the LEA.
The media server replies that the Modify was successful. Request (GWC to media server)
MEGACO/1 [192.136.141.118]:2427 Transaction=3009{ Context=1{ Modify=te/tepool0/3{ Media{O{MO=SR}, R{ v=0 c=IN IP4 47.171.164.190 m=audio 20006 RTP/AVP 0 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. Request (GWC to media server)
MEGACO/1 [192.136.141.118]:2427 Transaction=3010{ Context=1{ TP{ te/tepool0/0, te/tepool0/3, OW }}}
MEGACO/1 [47.171.164.21]:2945 Reply = 3010 { Context = 1 { Topology { te/tepool0/0, te/tepool0/3, Oneway } } }
Nortel Networks
PROPRIETARY
Page
276
Chapter D3 H.248
No. Description / format
(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.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 Transaction=3011{ Context=1{ Subtract=te/tepool0/0{ AT{} }}} MEGACO/1 [47.171.164.21]:2945 Reply = 3011 { Context = 1 { Subtract = te/tepool0/0 } }
(16) GWC tells the media server to release the context.

MEGACO/1 [192.136.141.118]:2427 Transaction=3015{ Context=1{ CT{ ctxr/res=release }}}
The media server replies that the context has been released. Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [47.171.164.21]:2945 Reply = 3015 { Context = 1 { ContextAttr { ctxr/res = release } } }
Page
277
Nortel Networks
PROPRIETARY
Chapter D3 H.248
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.
Nortel Networks
PROPRIETARY
Page
278
Chapter D3 H.248
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 Request (GWC to MG) Response (MG to GWC)
MEGACO/1 [47.174.66.80]:2944 Transaction=62{ Context=1002{ Modify=E1/1/20/5{ Signals {andisp/data {db=802001083035313831363135020A3931393535 353030303007084A6F686E20446F65D8, [1] tas=nt, NotifyCompletion={TimeOut}} }, Events=1234{g/sc} } } } MEGACO/1 [47.166.34.20]:2944 Reply=62{ Context=1002{ Modify=E1/1/20/5 } }
Signal completion notification Request (MG to GWC)

MEGACO/1 [47.166.34.20]:2944 Transaction=24{ Context=1002{ Notify=E1/1/20/5{ 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).
Page
279
Nortel Networks
PROPRIETARY
Chapter D4
D4.1 Purpose
ASPEN
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.
Nortel Networks
PROPRIETARY
Page
280
Chapter D4 ASPEN
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
Trunk Gateway Controller (GWC) Ingress TDM-side ASPEN commands, e.g. CRCX, some with in-line SDP service descriptions Acknowledgements Media gateway (PVG) Acknowledgements Media gateway (PVG) SIP-T and VRDN GWCs; Egress packet-side
CS2000
SIP-T and VRDN GWCs; Ingress packet-side Trunk Gateway Controller (GWC) Egress TDM-side ASPEN commands, e.g. CRCX, some with in-line SDP service descriptions
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.
Page
281
Nortel Networks
PROPRIETARY
Chapter D4 ASPEN
D4.3
Commands Available
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 Connection control commands
Usage
CRCX
Create connection
MDCX
Modify connection
DLCX
Delete connection Delete connection request
DRCX
RQNT
Request notification
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. Sent to terminating media gateway selected via GWC 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. Acknowledged by 200 message with no parameters. GWC [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 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. Media because of carrier failure. gateway Causes host GWC to send a DLCX, and to request the far-end GWC to 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. Can also be used to request a media gateway to initiate monitoring for the 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.
Nortel Networks
PROPRIETARY
Page
282
Chapter D4 ASPEN
Table 29: ASPEN commands supported by CS2000

Name NTFY Meaning Notify Usage 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 gateway the playing of a tone.) Acknowledged by 200 message with no parameters. The requested transaction has been executed normally. The connection has been deleted as requested. The transaction could not be executed because of a transient error. The transaction could not be executed because of a permanent error, e.g. endpoint unknown, protocol error. Sent by
Acknowledgements Media gateway or GWC Media 250 Success gateway Temporary Media 400-499 problem gateway Permanent Media 500-599 problem gateway Maintenance commands 200 Success SVID Server identification Heartbeat GWC
BEAT
CHNG
Change
Sent from a GWC to each of its media gateways when the GWC is brought into service. 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 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, following the STRT/SWCT acknowledgement, to indicate the status of Media the gateways endpoints. gateway - Independently sent from media gateway to GWC to report any change in gateway endpoint status. GWC Sent by GWC to query media gateway endpoint status
RINF NINF RSIP
Resource information request Notification of resource information Restart in progress
Media gateway Sent by media gateway to report endpoint status Media Sent by media gateway to report a gateway restart 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.
Page
283
Nortel Networks
PROPRIETARY
Chapter D4 ASPEN
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. 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. 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). 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) 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) 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. Reason code Included in DRCX command to indicate the cause of a gateway-initiated disconnection.
Nortel Networks
PROPRIETARY
Page
284
Chapter D4 ASPEN
Requested events Included in RQNT command to specify which event(s) the media gateway should tell the GWC about. Observed events Included in NTFY command to indicate which monitored events have occurred. Signal requests Included in RQNT command to specify which signal(s) the media gateway should tell the GWC about. Request identifier Used for correlation between requested events and resulting event notifications. 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.
O S
X D
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)>
Page
285
Nortel Networks
PROPRIETARY
Chapter D4 ASPEN
D4.6
D4.6.1
Examples
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 m=audio 1111 RTP/AVP 2 a=ptime:10 m=audio 1111 RTP/AVP 18 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 m=audio 1111 RTP/AVP 2 a=ptime:10 m=audio 1111 RTP/AVP 18 a=ptime:20
200 acknowledgement of second CRCX

200 4 I: C2 v=0 c=IN IP4 47.96.121.1 m=audio 2222 RTP/AVP 2 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).
Nortel Networks
PROPRIETARY
Page
286
Chapter D4 ASPEN
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 m=audio 2222 RTP/AVP 2 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
Page
287
Nortel Networks
PROPRIETARY
Chapter D5
D5.1 Purpose
H.323
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. 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.
PROPRIETARY Page
Nortel Networks
288
Chapter D5 H.323
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.
Data payload protocols (T.12x)
H.245 Logical channel control
H.450.1 Servicerelated data definitions
Call control (based on Q.931)
RAS
Video payload protocols (H.26x)
Audio payload protocols (G.7xx)
X.224
H.225
RTP Media packets
RTCP Delivery monitoring
Media stream protocols TCP (reliable transport) IP Figure 71: H.323 protocol architecture UDP (unreliable transport)
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.
Page
289
Nortel Networks
PROPRIETARY
Chapter D5 H.323
D5.2
D5.2.1
Network Role
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 served by other CS2000s CS2000 Core Basic interoperability via non-FT trunks with units served by other CS2000s
CS2000
H.323 proxy (GWC equivalent)
H.323 proxy
Other GWCs
H.323 signalling (no bearer traffic)
Full interworking with other H.323-controlled units served by same CS2000
Basic interoperability with non-H.323 units served by same CS2000
Proprietary units
Meridian 1 IP PBX
Business Call Manager (BCM)
Communication Server for Enterprise (CSE1000)
Third-party units
Cisco access router / gatekeeper (2600 / 3600 / 7200)
Westell DPNSS gateway (InterChange iQ203x)
Figure 72: The role of H.323 in a CS2000 network
Nortel Networks
PROPRIETARY
Page
290
Chapter D5 H.323
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
Page
291
Nortel Networks
PROPRIETARY
Chapter D5 H.323
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 tunnelled end-to-end (H.450 APDUs and H.245 PDUs)
UUI IE in H.225 message
Facility IE in QSIG message
ETSI ISUP V2+ APP or IBN7 ISUP NTP(HNI)
CS2000
H.323 proxy
H.323 application QSIG interface
H.323 proxy CS2000 Core

QSIG interface H.323 application
H.323 CPE unit
H.323 CPE unit

Facility IE in QSIG message


Figure 73: Message mapping for H.323 tunnelling
Nortel Networks
PROPRIETARY
Page
292
Chapter D5 H.323
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.
Page
293
Nortel Networks
PROPRIETARY
Chapter D5 H.323
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 RegistrationRequest (RRQ) Function Request from a terminal or gateway to register with a gatekeeper. 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 (DRQ) InfoRequest (IRQ) InfoRequestResponse (IRR) If sent from endpoint to gatekeeper, DRQ informs gatekeeper that endpoint is being dropped; if sent from gatekeeper to endpoint, DRQ forces call to be dropped. Request for status information from gatekeeper to terminal. Response to IRQ. May be sent unsolicited by terminal to gatekeeper 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.
Nortel Networks
PROPRIETARY
Page
294
Chapter D5 H.323
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 Message Call establishment messages SETUP SETUP ACK INFORMATION CALL PROCEEDING ALERTING PROGRESS CONNECT Not used Call clearing messages Not used Not used RELEASE COMPLETE Miscellaneous messages FACILITY NOTIFY STATUS STATUS ENQUIRY Yes Yes Yes Yes FACILITY NOTIFY STATUS STATUS ENQUIRY Yes No No No Yes DISCONNECT RELEASE RELEASE COMPLETE Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes SETUP SETUP ACK INFORMATION CALL PROCEEDING ALERTING PROGRESS CONNECT CONNECT ACK Yes No No No Yes Yes Yes No UUI IE supported? QSIG message Message Facility IE supported?
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.
Page
295
Nortel Networks
PROPRIETARY
Chapter D5 H.323
Figure 74 illustrates the messaging involved in H.323 call setup and clearing via the H.323 proxy GWC.
H.225 signalling H.323 CPE unit
SETUPUUI SETUP ACK INFORMATION (1 or more) CALL PROCEEDING ALERTINGUUI CONNECTUUI
QSIG signalling H.323 proxy GWC CS2000 Core

SETUPFAC
SETUP ACK (Overlap signalling INFORMATION only) (1 or more) CALL PROCEEDING ALERTINGFAC CONNECTFAC CONNECT ACK
Call in progress RELEASE COMPLETE

UUI
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.
Nortel Networks
PROPRIETARY
Page
296
Chapter D5 H.323
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.
297
Nortel Networks
Chapter D5 H.323
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 Set message(s) more Terminal Capability Sets 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 Reject General mode types include VideoMode, 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.
Nortel Networks
PROPRIETARY
Page
298
Chapter D5 H.323
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.
Page
299
Nortel Networks
PROPRIETARY
Chapter D6
D6.1 Purpose
UniStim
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).
Nortel Networks
PROPRIETARY
Page
300
Chapter D6 UniStim
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 for CICM
GWC for CICM
H.248
P-Phone
P-Phone
H.248
UniStim RUDP UDP IP
UniStim is one of three types of signalling used to provide VoIP support for CentrexIP clients
UniStim RUDP UDP IP
IP core network
Bearer connections for VoIP are routed across the core network; they are not handled by the CICM
Firewall Firewall
Enterprise network
Enterprise network
CentrexIP Etherset client (i200x):
CentrexIP Etherset client (i200x):
Figure 75: Role of UniStim in supporting CentrexIP remote clients
Page
301
Nortel Networks
PROPRIETARY
Chapter D6 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
Nortel Networks
PROPRIETARY
Page
302
Chapter D6 UniStim
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
Page
303
Nortel Networks
PROPRIETARY
Chapter D6 UniStim
" "
"
" " " " " "
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.
Nortel Networks
PROPRIETARY
Page
304
Chapter D6 UniStim
" " " " " "
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
Page
305
Nortel Networks
PROPRIETARY
Chapter D6 UniStim
"
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
Nortel Networks
PROPRIETARY
Page
306
Chapter D6 UniStim
D6.4
NAT Traversal for UniStim Signalling

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). 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.
Page
307
Nortel Networks
PROPRIETARY
Chapter D7
D7.1 Purpose
NCS
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.
Nortel Networks
PROPRIETARY
Page
308
Chapter D7 NCS
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 Controller (GWC) for ingress gateway
Gateway Controller (GWC) for egress gateway
Signalling between CS2000 GWC and MTA line gateway uses NCS
IP backbone network
Bearer connection (packetised voice) CMTS HFC cable access networks
Originating Gateway (MTA) Signalling between CMTS and MTAs is based on (Euro)DOCSIS, and is not visible to the CS2000 GWCs that control the MTA gateways Terminating Gateway (MTA)
CMTS
Call origination
Signalling over the line interface (except hook state changes and ringing) uses in-band DTMF tones
Call termination
Figure 76: Logical network role of NCS
Page
309
Nortel Networks
PROPRIETARY
Chapter D7 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.
D7.3
Commands Available
NCS call control commands can be divided into two main categories (a full set of maintenance commands is also supported): ! Connection control commands " 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.
Nortel Networks
PROPRIETARY
Page
310
Chapter D7 NCS
The following table lists the commands available and summarises their functions. Table 33: NCS commands supported by CS2000
Name Meaning Sent by Usage 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. GWC Also used to convey MWI+/MWI- signals to request 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 Gateway event that is automatically monitored (e.g. off-hook), or an event explicitly specified in a RQNT command. Acknowledged by 200 message with no parameters. 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). CRCX sets up an initially inactive bearer Originating 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 address and SDP session description for GWC line endpoint. Sent to terminating line gateway selected via translations and routing, to set up an initially inactive bearer connection for the selected line endpoint. Includes SDP session description, as Terminating 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 200 message. GWC [2] Sent to originating media gateway when ringing is 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.
RQNT
Request notification
NTFY
Notify
CRCX
Create connection
MDCX
Modify connection
Page
311
Nortel Networks
PROPRIETARY
Chapter D7 NCS
Table 33: NCS commands supported by CS2000

Name Meaning Sent by Usage 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 down the bearer connection between the two gateway endpoints. Acknowledged by 250 message with Quality of Service data for the completed call, e.g. packets/octets sent, packets/octets received, packets lost.
DLCX
Delete connection
GWC
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 Restart in Gateway Sent by media gateway to report a gateway restart RSIP progress
D7.4
D7.4.1
Parameters
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. 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 (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.
Nortel Networks
PROPRIETARY
Page
312
Chapter D7 NCS
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
local-endpoint-name@domain-name
Endpoint names are therefore of the form 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.
Page
313
Nortel Networks
PROPRIETARY
Chapter D7 NCS
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 parameter lines. A main command line has the format: <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). <trID> is a transaction ID used to correlate a command and its acknowledgement. <protocol version> is NCS 1.0.
Each parameter line that follows a main command line has the format: <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)>
Nortel Networks
PROPRIETARY
Page
314
Chapter D7 NCS
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
Page
315
Nortel Networks
PROPRIETARY
Chapter D7 NCS
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 m=audio 3456 RTP/AVP 8 a=ptime:10
Nortel Networks
PROPRIETARY
Page
316
Chapter D7 NCS
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)

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
Example 1
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.
Page
317
Nortel Networks
PROPRIETARY
Chapter D7 NCS
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 2 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. 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).
Nortel Networks
PROPRIETARY
Page
318
Chapter D8
D8.1 Purpose
MGCP
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.
Nortel Networks
PROPRIETARY
Page
319
Chapter D8 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 Controller (GWC) for ingress gateway Signalling between CS2000 GWC and customer LAN line gateway uses MGCP
Gateway Controller (GWC) for egress gateway Signalling between CS2000 GWC and customer LAN line gateway uses MGCP Page
IP backbone network
Bearer connection (packetised voice) Access Access
Customer LANs (Ethernet)

Line media gateway Line media gateway
Call origination
Call termination
Figure 77: Network role of MGCP in supporting customer LAN line gateways
Nortel Networks
PROPRIETARY
320
Chapter D8 MGCP
D8.3
Commands Available
MGCP comprises seven commands, which can be divided into three categories: ! Connection control commands " 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.
Page
321
Nortel Networks
PROPRIETARY
Chapter D8 MGCP
D8.4
D8.4.1
IP Address Assignment for MGCP Line Gateways

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: 1 2 Line media gateway is booted up and automatically broadcasts a DHCP (Dynamic Host Configuration Protocol) message requesting configuration data. 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. Line media gateway sends the specified server a TFTP request to download the required configuration file. TFTP server responds by downloading a file containing configuration data, including the IP address of the GWC with which the gateway should register itself. 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. 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.
3 4 5
D8.4.2
Address Assignment Involving NAT

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).
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.
PROPRIETARY Page
Nortel Networks
322
Chapter D8 MGCP
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. The RMGC looks at the gateway FQDN conveyed in the RSIP message to determine which gateway sent the message. 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. 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. 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. 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.
2 3
Page
323
Nortel Networks
PROPRIETARY
Chapter D8 MGCP
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 parameter lines. A main command line has the format: <command> <trID> <protocol version> where ! ! ! <command> is either one of CRCX, RQNT 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 MGCP 1.0.
Each parameter line that follows a main command line has the format: <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.
Nortel Networks
PROPRIETARY
Page
324
Chapter D9
D9.1 Purpose
MPCP
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.
Nortel Networks
PROPRIETARY
Page
325
Chapter D9 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.
Nortel Networks
PROPRIETARY
Page
326
Chapter D9 MPCP
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.
Control / signalling Media stream Line GWC
CS2000 Core (call processing)
CentrexIP GWC MPCP H.248 Uni CICM
Public address discovery for signalling Enterprise network (private address domain) Private Public
MGCP UniStim Enterprise network (private address domain) Public Private
Media portal controller
RTP media portal

Media packet engine on peripheral card Two-way NAT functionality for RTP/UDP media stream
Line gateway on LAN
Firewall (NAT/NAPT)
Public address discovery for media stream
Firewall (NAT/NAPT)
CentrexIP client
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
Page
327
Nortel Networks
PROPRIETARY
Chapter D9 MPCP
D9.3
Commands Available
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.
Nortel Networks
PROPRIETARY
Page
328
Chapter D10
D10.1 Purpose
IUA
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.
Nortel Networks
329
Chapter D10 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
Access Gateway Controller (GWC) Ingress TDM-side DPT GWC and Session Server; Egress packet-side
CS2000
DPT GWC and Session Server; Ingress packet-side Access Gateway Controller (GWC) Egress TDM-side
Inter-CS communication via SIP-T encapsulation of CCS7
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 Gateway
Terminating Gateway 30B+D PRI/QSIG access (23B+D PRI also supported)
30B+D PRI/QSIG access (23B+D PRI also 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.
Nortel Networks
PROPRIETARY
Page
330
Chapter D10 IUA
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.
Page
331
Nortel Networks
PROPRIETARY
Chapter D11
D11.1 Purpose
V5UA
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.
Nortel Networks
PROPRIETARY
Page
332
Chapter D11 V5UA
Figure 80 illustrates the protocol stacks used in supporting V5.2 access to a backbone packet network.
V5.2 Access Network (AN) PVG supporting SG functionality Layer 3 V5.2 messages V5.2 LAPV5 messages LAPV5 Bridging V5UA LAPV5 SCTP IP Backhaul link Backhaul messages V5.2 V5UA SCTP IP MGC (CS2000)
LAPV5 terminated Signalling data 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 For analogue lines, V5-PSTN call control messages convey the equivalents of 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 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. V5 system management messages for controlling interaction with V5.2 Layer 2 via primitives, e.g. establishing or releasing a V5.2 C-channel.
Page
333
Nortel Networks
PROPRIETARY
Chapter D11 V5UA
V5 system management messages for controlling interaction with V5.2 Layer 1 via 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) ETS 300 347-1 (1994) with Amendment ETS 300 347-1/A1 (1997)
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
Nortel Networks
334
Chapter D11 V5UA
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
Access Gateway Controller (GWC) Ingress TDM-side DPT GWC and Session Server; Egress packet-side
CS2000
DPT GWC and Session Server; Ingress packet-side Access Gateway Controller (GWC) Egress TDM-side
Inter-CS communication via SIP-T encapsulation of CCS7
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
Originating V5.2 gateway V5.2 interface comprising 1-16 E1 carriers
Terminating V5.2 gateway V5.2 interface comprising 1-16 E1 carriers
V5.2 Access Network (AN) Figure 81: Network role of V5.2 / V5UA / SCTP
V5.2 Access Network (AN)
Page
335
Nortel Networks
PROPRIETARY
Chapter D11 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.
Nortel Networks
336
Chapter D11 V5UA
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
V5.2 AN Caller goes off-hook
V5-PSTN: ESTABLISH
CS2000
SG GWC
MG
V5UA Data Ind (ESTABLISH) V5UA Data Req (EST ACK) V5UA Data Req (ALLOCATION) V5UA Data Ind (ALLOC COMP) H.248 Add endpoint to context Apply dial tone Collect digits against digit map
V5-PSTN: ESTABLISH ACK V5-BCC: ALLOCATION V5-BCC: ALLOCATION COMP
Dial tone 1st digit Digits matching digit map More digits
Dial tone
Dial tone removed
H.248 Notify endpoint Match against digit map H.248 Notify endpoint Additional digit H.248 Modify physical endpoint Stop digit collection H.248 Add packet port to context H.248 Modify packet port SDP definition of port characteristics
Onward call setup begins
Termination identified Apply ringing
RIngback tone
RIngback tone
H.248 Modify endpoint Apply ringback tone
Ringback tone removed
H.248 Modify endpoint Mode=sendrecv Stop ringback tone
Off-hook / answer
Call in progress
Figure 82: V5.2 call setup (originating side only)
Page
337
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
338
Chapter D12 MTP Adaptation Protocols
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.
TDM-side switches, SCPs, etc Other CS2000s, peer MGCs
CS2000
ISUP TUP M3UA SCTP CS2000 Core IP USP TCAP SCCP
ISUP
TUP MTP3 MTP2 MTP1 TCAP SCCP MTP3 M2PA SCTP IP
CS LAN
DPT GWC
Sessioin Server or VRDN
SIP-T SIP-T
ISUP SDP TUP SDP
TCP or UDP IP
Figure 83: USP support for CCS7 signalling
Page
339
Nortel Networks
PROPRIETARY

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
Nortel Networks
PROPRIETARY
Page
340
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).
Page
341
Nortel Networks
PROPRIETARY
Chapter D13
D13.1 Purpose
DSM-CC
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.
Nortel Networks
PROPRIETARY
Page
342
Chapter D13 DSM-CC
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. 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 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 Packet network control signalling TDM bearer channels Packet network bearer connections
CS2000
Call processing CCS7 Signalling Gateway (SG) Access GWC for gateway; Ingress TDM-side
GWC-gateway signalling (DSM-CC)
PSTN CCS7 signalling (IUP / ISUP)
IP core network
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.
Page
343
Nortel Networks
PROPRIETARY
Chapter D13 DSM-CC
D13.3 Commands Available

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)
Nortel Networks
PROPRIETARY
Page
344
Chapter D13 DSM-CC
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.
Page
345
Nortel Networks
PROPRIETARY
Chapter D13 DSM-CC
Overload control The CVX1800 uses DMS-CC CCHR (ClientConfigHeartbeatResponse) and CCR (ClientConfigResponse) 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).
Nortel Networks
PROPRIETARY
Page
346
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.
Nortel Networks
PROPRIETARY
Page
347
Chapter D14 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.
Nortel Networks
PROPRIETARY
Page
348
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 Network management workstation SNMP-based EM client (command generator) EM, e.g. GWC EM SNMP process on EM (SNMP agent / command responder) Open Register SNMP DPI Network element, e.g. GWC SNMP process on network element (SNMP sub-agent )
Get GetNext GetBulk Set GetResponse
Get GetNext Set Server platform, e.g. Sun Netra 240 Response NE hardware, e.g. GWC card
Client platform, e.g. Windows PC
Note: To simplify the diagram, not all DPI requests are shown. NOC LAN (access only to EMs, not to network elements) OAM&P VLAN of CS2000 CS LAN (trusted access to network elements) Call processing VLAN of CS2000 CS LAN (functional network elements)
Figure 85: Logical network role of SNMP
Page
349
Nortel Networks
PROPRIETARY
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.
Nortel Networks
350
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.
Page
351
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
352
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: 1 2 Line media gateway is booted up and automatically broadcasts a DHCP (Dynamic Host Configuration Protocol) message requesting configuration data. 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. Line media gateway sends the specified server a TFTP request to download the required configuration file. TFTP server responds by downloading a file containing configuration data, including the IP address of the GWC with which the gateway should register itself. 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:
"
3 4 5
"
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.
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.
Page
353
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
354
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 2 3 Client uses BOOTP or DHCP to obtain IP address of TFTP server and filename of boot image. Client uses TFTP to request TFTP server to download boot image. 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)
Page
355
Nortel Networks
PROPRIETARY
Chapter E1 Overview
Chapter E1
Overview of Support for Telephony Interfaces
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.
Page
357
Nortel Networks
PROPRIETARY
Chapter E1 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
Nortel Networks
PROPRIETARY
Page
358
Chapter E1 Overview
"
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.
Page
359
Nortel Networks
PROPRIETARY
Chapter E1 Overview
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.
Nortel Networks
PROPRIETARY
Page
360
Chapter E1 Overview
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 China Hong Kong (CS13) Japan (INS1500) Spain USA (ANSI PRI) 30B+D 23B+D 23B+D 30B+D 23B+D Characteristics Specification based on Q.931; implementtation based on ETSI PRI Specification based on Q.931 Specification based on Q.931 Specification and implementation based on ETSI PRI Defined in ANSI specification T1.607 (1990).
Page
361
Nortel Networks
PROPRIETARY
Chapter E1 Overview
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).
Nortel Networks
PROPRIETARY
Page
362
Chapter E1 Overview
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. 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. 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.
Page
363
Nortel Networks
PROPRIETARY
Chapter E1 Overview
E1.7
E1.7.1
Interworking in a Packet Network Environment

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).
Nortel Networks
PROPRIETARY
Page
364
Chapter E1 Overview
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.
Interface Call type Intra-CS2000 QSIG Networked via SIP-T Intra-CS2000 V5.2 line Networked via SIP-T Figure 89 on page 367 Figure to use as base Figure 87 on page 366 Figure 89 on page 367 Figure 87 on page 366 Modification(s) Substitute QSIG for PRI at the top level of the PRI / IUA / SCTP / IP protocol stack Substitute QSIG for PRI at the top level of the PRI / IUA / SCTP / IP protocol stack Substitute V5.2 for PRI and V5UA for IUA at the top two levels of the PRI / IUA / SCTP / IP protocol stack; use of H.248 as media control protocol instead of ASPEN is mandatory Substitute V5.2 for PRI and V5UA for IUA at the top two levels of the PRI / IUA / SCTP / IP 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 must be inferred from the message header and 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.
SIP-T
Between CS2000 and MCS5200
Figure 88 on page 367
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.
Page
365
Nortel Networks
PROPRIETARY
Chapter E1 Overview
Incoming half-call Signalling:

Call control signalling ISUP MTP Co-ordination Co-ordination
Outgoing half-call Signalling:

Call control signalling ISUP MTP
Media control signalling H.248/lASPEN (SDP) UDP IP
Connections:
Call control signalling ISUP signalling terminated on USP or FLPP Media control signalling IP link between GWC and gateway (IP / AAL5 if backbone is ATM)
Connections:
Figure 86: CCS7-to-CCS7 call between two gateways controlled by the same CS2000
Incoming half-call Signalling:

Call control signalling PRI IUA/SCTP/IP Co-ordination Co-ordination
Outgoing half-call Signalling:

Call control signalling PRI IUA/SCTP/IP
Connections:
Call control signalling IP link between GWC and gateway (IP / AAL5 if backbone is ATM) Media control signalling IP link between GWC and gateway (IP / AAL5 if backbone is ATM)
Connections:
Figure 87: PRI-to-PRI call between two gateways controlled by the same CS2000
Nortel Networks
PROPRIETARY
Page
366
Chapter E1 Overview
Incoming half-call on originating CS2000 Signalling:

Call control signalling ISUP MTP Co-ordination
Outgoing half-call on originating CS2000 Signalling: SIP-T

Session control and encapsulation ISUP Call control signalling SDP Media control signalling UDP IP
Connections:
Connections:
All signalling IP link between DPT GWCs (IP / AAL5 if backbone is ATM)
Figure 88: CCS7 call networked to a different CS2000
Incoming half-call on originating CS2000 Signalling:

Call control signalling PRI IUA/SCTP/IP Co-ordination
Outgoing half-call on originating CS2000 Signalling: SIP-T

Session control and encapsulation ISUP Call control signalling SDP Media control signalling UDP IP
Connections:
Connections:
All signalling IP link between DPT GWCs (IP / AAL5 if backbone is ATM)
Figure 89: PRI call networked to a different CS2000
Page
367
Nortel Networks
PROPRIETARY
Chapter E2
E2.1 Introduction
CCS7 Interfaces
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.
Nortel Networks
368
Chapter E2 CCS7 Interfaces
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 Layers
Database Service logic Direct interaction with service logic (e.g. networked CCBS)
CCS7 Parts
IN database queries (interaction with SCP via INAP)
Voice calls Supplementary services ISDN data calls
Simple telephony calls
INAP
Layer 7 (Application) Networked NCAS services
ISUP
plus national variants of ETSI ISUP V2 plus national variants of ETSI ISUP V1
TUP
ETSI ISUP V2 (White Book)
UK ISUP and SPIROU
SSUTR2/FTUP in France
IBN7 (ANSI ISUP+)
IUP/BTUP in the UK
Layer 6 (Presentation) Null layers
Layer 5 (Session)
Layer 4 (Transport)
SCCP (ITU/ANSI)
Layer 3 (Network) Circuit-independent or connectionless SCCP Circuit-oriented SCCP (not supported by CS2000) Message transfer functions common to all user parts
Signalling network functions (message discrimination, distribution and routing) Layer 2 (Datalink)
MTP
(ITU / ANSI)
Signalling link functions (extracting/inserting signal units)
Layer 1 (Physical)
Signalling datalink functions (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
Page
369
Nortel Networks
PROPRIETARY
CTUP in China
TCAP
Different user parts
ITU/ ETSI TCAP
IBN7 TCAP
national variants of ETSI ISUP V3
ETSI ISUP V1 (Blue Book)
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).
Nortel Networks
PROPRIETARY
Page
370
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
E2.2.1.1
TDM Implementation (Access to Packet Network)

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

Layer 7: Application Layer 6: Presentation Layer 5: Session Layer 4: Transport Layer 3: Network Layer 2: Datalink Layer 1: Physical MTP Message Transfer Part MTP Message Transfer Part CCS7 user part (ISUP, TUP, TCAP) Logical peer-to-peer communication via user part messages
Terminating switch
CCS7 user part (ISUP, TUP, TCAP)
CCS7 protocol supported via static provisioning MTP Layer 3 message handing provided by USP or FLPP MTP Layer 2 functions provided by CCS7 link system node (USP) or LIU7 (FLPP)
User part messages conveyed between nodes in MTP Message Signal Units (MSUs)
Figure 91: Peer-to-peer CCS7 messaging (TDM implementation)
Page
371
Nortel Networks
PROPRIETARY
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: USP Universal Signalling Point 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. 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.
FLPP
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.
Nortel Networks
PROPRIETARY
Page
372
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 2 3 Signalling for inter-CS ISUP and TUP trunks (see section E2.2.2.1 on page 374) Intra-CS2000 CCS7 signalling via the CS LAN (see section E2.2.2.2 on page 375) 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, SCPs, etc Other CS2000s, peer MGCs
CS2000
ISUP TUP M3UA CS2000 Core SCTP IP
2
ISUP TCAP SCCP
TUP MTP3 MTP2 MTP1
USP
3
CS LAN DPT GWC Session Server or VRDN
TCAP SCCP MTP3 M2PA SCTP IP SIP-T SIP-T
ISUP SDP
TUP SDP
TCP or UDP 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.
Page
373
Nortel Networks
PROPRIETARY
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 Originating CS2000

Layer 7: Application Layer 6: Presentation Layer 5: Session Layer 4: Transport Layer 3: Network Layer 2: Datalink Layer 1: Physical SIP-T TCP or UDP IP ISUP / TUP Logical peer-to-peer communication via CCS7 messages SIP-T session
Terminating CS2000
ISUP / TUP SIP-T TCP or UDP IP
CCS7 protocol support provided by DPT GWC SIP-T session control provided by Session Server UDP transport and lower layer control provided by Session Server
ISUP messages conveyed between nodes in packetised datagrams
Note: If VRDN is used instead of Session Server, DPT GWC terminates SIP-T as well as CCS7
Figure 93: Peer-to-peer CCS7 messaging (packet network implementation)
Configuration Dynamic Packet Trunks for inter-CS signalling 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. 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. Typically, SIP-T is used for signalling between CS2000s, while SIP is used for signalling between CS2000 and MCS5200. SIP does not provide direct CCS7 support, but SIP messages can be interworked with CCS7 equivalents to provide indirect CCS7 support. 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 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.
Nortel Networks
PROPRIETARY
Page
374
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), 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 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. Note: Not supported by the USP Compact (see section B1.6.1.4 on page 77). 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.
Page
375
Nortel Networks
PROPRIETARY
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 conveyed over IP ( IP / AAL5 / ATM over STM-1)
Packet network control signalling TDM bearer channels Packet network bearer connections
Originating CS2000
Call processing 4 3b 5a 5b Access 8 DPT GWC CCS7 Gateway 26 and Session Controller Signalling 3a (GWC) 27 Server; Gateway Ingress (USP/FLPP) TDM-side 34 Egress 35 packet-side 2 28 37 6 29 36 9 38a
Terminating CS2000
Call processing 15 14 16a 16b DPT GWC 17 Access CCS7 Gateway 11 and Session Signalling 22 Controller 12 Server; (GWC) Gateway 13 Ingress 32 Egress (USP/FLPP) TDM-side packet-side 10 23 24 25 33 38b 18 31 20 21 30
Inter-CS signalling (CCS7 signalling encapsulated in SIP-T)
PSTN CCS7 signalling (e.g. ISUP)
GWC-gateway signalling (H.248)

7
GWC-gateway signalling (H.248)
PSTN CCS7 signalling (e.g. ISUP)
Packet network (ATM or IP)

Bearer connection (packetised voice)
19 Terminating media gateway
Originating media gateway
CCS7 signalling Mux groomed off Call origination
Mux
Call termination
PSTN
Figure 94: Setting up an ISUP VoIP or VoATM call between two CS2000s
Nortel Networks
376
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 2 3a 3b
5a 5b
10
11
12 13 14
Incoming call arrives at originating media gateway. IAM for incoming call groomed off to terminate on CS2000 signalling gateway. Signalling gateway (USP or FLPP) identifies ingress access GWC and media gateway 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 - 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. CS2000 Core sends FCM (Fabric Control Message) to ingress and egress GWCs to 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 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 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). 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 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 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, 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. 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. Ingress Session Server forwards IAM extracted from INVITE message to selected DPT on ingress DPT GWC Ingress DPT GWC forwards IAM to CS2000 Core, requesting it to initiate call processing
Page
377
Nortel Networks
PROPRIETARY
15 16a 16b 17
18
19 20 21 22 23 24 25 26 27 28 29 30 31
32
33 34 35 36
CS2000 Core uses IAM to perform translations and routing, and identifies the egress access GWC and media gateway serving the destination CS2000 Core sends FCM to ingress and egress GWCs to enable direct communication between them 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 establish mapping between TDM-side and packet-side terminations. First Add 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. Media gateway response to second Add command provides GWC with endpoint identifier (IP address) to use for logical termination, together with SDP description of bearer capabilities supported (for use in codec negotiation with the originating media gateway serving the originating endpoint). Outgoing IAM sent out from signalling gateway (USP or FLPP) on terminating CS2000 Backward ACM received by signalling gateway on terminating CS2000 Backward ACM routed to 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 Ingress Session Server encapsulates outgoing ACM in a backward SIP-T 183 SESSION PROGRESS message, then sends message to originating CS2000 Ingress DPT GWC sends ingress Session Server a request for ringback tone to be applied to originating TDM-side trunk. 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 RINGING messages, extracting backward ACM from SESSION PROGRESS message and forwarding it to egress DPT GWC Egress DPT GWC on originating CS2000 forwards ACM to ingress access GWC (directly or via the Core, depending on CCS7 protocol types involved) Backward ACM sent out from signalling gateway on originating CS2000 Ingress access GWC sends H.248 Modify message to originating media gateway, asking gateway to apply ringback tone to originating TDM-side trunk Backward ANM received by signalling gateway on terminating CS2000 and passed to egress access GWC 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 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 Ingress Session Server encapsulates outgoing ANM and associated SDP in a backward SIP-T 200 OK message, then sends message to originating CS2000 Egress Session Server on originating CS2000 extracts ANM from SIP-T message and forwards it to egress DPT GWC Egress DPT GWC notifies ingress access GWC (directly or via the Core, depending on CCS7 protocol types involved) of ANM arrival Ingress access GWC sends H.248 Modify message to originating media gateway, completing codec negotiation process and asking gateway to remove ringback tone and place the bearer connection in full duplex mode
Nortel Networks
PROPRIETARY
Page
378
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
E2.2.4.1
Interworking TDM and Packet Implementations of CCS7

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.
Page
379
Nortel Networks
PROPRIETARY
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 Modem tone detected by PVG ISUP message indicates no previous ECAN ISUP message indicates previous ECAN ECSTAT=INTERNAL in table TRKSGRP ECSTAT=EXTERNAL in table TRKSGRP CS2000 requests CCD ECAN provisioned always OFF in PVG ECAN provisioned ON by default in PVG ASPEN local connection option N N N N Y Y N N Y Y N N N N Y N N Y e: e: N/A N/A on on OFF OFF OFF ON Y N N/A N/A N/A N/A N/A N/A N/A N Y N/A N/A N/A N/A N/A N/A N/A N N N N N N Y Y Y N N N N N Y Y Y N N N Y Y N Y N Y N e: e: N/A off off N N N N N N N N N N N N Y Y Y Y Y Y N N N N Y Y N N N N Y N Y N N Y N Y e: e: e: e: N/A N/A N/A off off off off N N Y N Y N Y N Y N N Y N N Y Y Y N N N Y N N Y Y N Y
Result: ECAN application by PVG
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.
Nortel Networks
PROPRIETARY
Page
380
E2.3
E2.3.1
ISDN User Part (ISUP) Support

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.
Originating switch Caller goes off-hook and dials number Terminating switch
IAM (Initial Address Message) Optional - overlap signalling only SAM (Subsequent Address Message)
Ringing tone
ACM (Address Complete Message) Audible ringing in-band ANM (Answer Message) Speech path through-connected
Physical ringing Called party answers
Call in progress
REL (Release message) Caller goes on-hook to terminate call RLC (Release Complete message)
Figure 95: ISUP messaging for call setup and clearing
Page
381
Nortel Networks
PROPRIETARY
E2.3.2
E2.3.2.1
ISUP Standards and Variants

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 Version 2 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 Version 3 ETSI ISUP V3 is defined in EN 300 356 (1998) in relation to ITU-T Recommendations Q.761 to Q.764 (1997). " ETSI ISUP Version 4 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).
Nortel Networks
PROPRIETARY
Page
382
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.
Page
383
Nortel Networks
PROPRIETARY
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
Nortel Networks
384
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.
Page
385
Nortel Networks
PROPRIETARY
E2.3.3
E2.3.3.1
CS2000 Support for ETSI / ITU ISUP

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
Nortel Networks
PROPRIETARY
Page
386
Message Support CS2000 supports standard messages as summarised in the table below.
Address complete (ACM) Answer (ANM) Application Transport Message [1] Blocking (BLO) [2] Blocking acknowledgment (BLA) [2] Call progress (CPG) Charge (CRG) / Charging (CHG) [3] Circuit group blocking (CGB) [2] Circuit group blocking ack. (CGBA) [2] Circuit group query (CQM) [4] Circuit group query response (CQR) [4] Circuit group reset (GRS) Circuit group reset acknowledgment (GRA) Circuit group unblocking (CGU) [2] Circuit group unblocking ack. (CGUA) [2] Confusion (CFN) [5] [6] Connect (CON) Continuity (COT) [7] Continuity check request (CCR) Facility (FAC) [8] Facility accepted (FAA) [9] Facility reject (FRJ) [9] Facility request (FAR) [9] Forward transfer (FOT) [6] [10] Identification request (IDR) [11] Identification response (IRS) [11] Information (INF) [11] Information Request (INR) [11] Initial address (IAM) Loop prevention (LOP) [8] Pre-Release Information (PRI) [1] Release (REL) Release complete (RLC) Reset circuit (RSC) Resume (RES) [12] Segmentation (SGM) [13] Subsequent address (SAM) Suspend (SUS) [12] Unblocking (UBL) Unblocking acknowledgment (UBA) Unequipped circuit ID code (UCIC) [14] 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)
Page
387
Nortel Networks
PROPRIETARY
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) Network resource management (NRM) Overload (OLM) User part available (UPA) User part test (UPT)
Nortel Networks
PROPRIETARY
Page
388
Parameter Support Parameters supported.

Access delivery information Access transport Additional CLI (ACLI) [1] Application transport [2] Automatic congestion level [3] Backward call indicators Call diversion information [4] Call reference [5] Call history information Called party number Calling party number Calling partys category Carrier Selection Parameter (CSP) [6] Cause indicators CCBS parameter [4] Charge band number [7] Circuit group supervision message type ind. Closed user group interlock code Connected number Continuity indicators End of optional parameters indicator Event information Facility indicator [4] Forward call indicators Generic digits [4] Generic notification indicator [4] Generic number [4] [8] Hop counter Information indicators [9] Information request indicators [9] Location number MCID request indicators MCID response indicators Message compatibility information [4] National forward call indicators [7] Nature of connection indicators Number of charge units [7] Optional backward call indicators Optional forward call indicators Original called number [4] [10] Parameter compatibility information [4] Propagation delay counter Range and status Redirecting number [4] [10] Redirection information [4] Redirection number [4] [10] Redirection number restriction [4] Service activation [4] Signalling point code Subsequent number Suspend/resume indicators Tariff [11] Transit network selection [6] Transmission medium requirement [12] User service information [12] User teleservice information [4] User-to-user indicators User-to-user information VPN code [13]
[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.
Page
389
Nortel Networks
PROPRIETARY
[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
Nortel Networks
PROPRIETARY
Page
390
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 Call transfer reference Circuit state indicator Connection request Echo control information Freephone indicators Generic reference Loop prevention indicators MLPP precedence Network specific facility Origination ISC point code Remote operations Transmission medium requirement prime Transmission medium used User service information prime
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.
! !
Page
391
Nortel Networks
PROPRIETARY
! !
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.
Nortel Networks
PROPRIETARY
Page
392
! !
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.
Page
393
Nortel Networks
PROPRIETARY
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 MoU Priority 1 services CLIP CLIR DDI MoU Priority 2 services 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) Subaddressing (SUB) User-to-User Signalling (UUS) Call Completion to Busy Subscriber (CCBS) Call Forward Unconditional (CFU) Call Forward on Busy (CFB) Call Forward on No Reply (CFNR) Partial Rerouting (PRR) Explicit Call Transfer (ECT) Non-ETSI ISDN services (MoU3) Network Advice Of Charge Priority Class Of Service (PCOS) for Germany Emergency Calls Random and Circular Hunting for PRI No No Yes Yes
[1]
ETSI ISUP V2 Yes Yes Yes [1] N/A [1] N/A [1] Yes Yes Yes Yes Yes Yes [2] Yes [3]
Yes [5] Yes [5] Yes [5] Yes [5] Yes
Yes Yes Yes

[1]
N/A [1] N/A [1] Yes No No Yes Yes Yes

[2]
No
Yes [4] Yes [4] Yes [4] Yes [4] Yes
Yes Yes 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).
Nortel Networks
PROPRIETARY
Page
394
E2.3.4
E2.3.4.1
CS2000 Support for ANSI ISUP Variants

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: " 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. ! 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.
Page
395
Nortel Networks
PROPRIETARY
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 further information. 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.
Nortel Networks
PROPRIETARY
Page
396
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 switch
Other CS2000
ANSI ISUP+
ETSI ISUP
IXC
PSTN/ LECs
FGD ISUP
CS2000 running ISN07
FGD ISUP
Other carriers/ IECs
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.
Page
397
Nortel Networks
PROPRIETARY
E2.3.5
E2.3.5.1
UK ISUP Support
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.
Nortel Networks
PROPRIETARY
Page
398
E2.3.5.2
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 1 2 3 VPN Services UK ISUP supports 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) AR permitted from receiving node, CR permitted AR not permitted from receiving node, CR permitted AR permitted from receiving node, CR not permitted AR not permitted from receiving node, CR not permitted
UK ISUP also supports ETSI ISUP V3 APM (Application Transport Mechanism) extensions, which enable it to provide networked support for private numbering plans. ISDN Supplementary Services 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.
Page
399
Nortel Networks
PROPRIETARY
E2.3.6
E2.3.6.1
SPIROU (French ISUP) Support

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).
! E2.3.6.2
VPN Services SPIROU supports 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)
SPIROU also supports the ETSI ISUP V3 APM (Application Transport Mechanism) extensions, which enable it to provide networked support for private numbering plans. ISDN Supplementary Services 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.
Nortel Networks
PROPRIETARY
Page
400
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
ETSI ISUP V1 [1] ETSI ISUP V2 [1] ISUP variant Implementation SIP (no CCS7) [3] IBN lines CentrexIP DPNSS [6] Cable MGs [8] Y N N N N N N N N N N N N N Y Y H.323 [5] LAN MGs [7] V5.2 MGs [9] N N N N Y Y N N Y Y N N N N Y Y PRI [4] Y Y Y Y Y Y Y Y
[13]
IBN7 ISUP
TUP [2]
Country / name
Characteristics
Australian ETSI ISUP V2 ACIF I-ISUP variant Belgian ISUP Brazilian ISUP Chilean ISUP
TDM
[10]
Y Y Y Y Y N Y Y Y
N N N N N N N N Y
Y Y N N N N N N N
Y Y N N N N N N Y Y N N N N Y Y
QSIG Y Y N N N N N N N N N N N N Y Y
INAP
N N N N N N N N N N N N N N Y Y
X X X X X X X X X X X X X X N N
N N N N N N N N N N N N N N N N
N N N N Y N N N
[14]
SIP-T Y
Y Y Y Y Y Y Y Y
ETSI ISUP V2 TDM Y variant SIP-T Y ETSI ISUP V1 TDM Y variant SIP-T Y ETSI ISUP V2 TDM Y variant SIP-T Y ETSI ISUP V2 variant TDM N
Chinese ISUP
[11] [12]
Y Y
Y Y Y Y SIP-T [15] [15] [15] [12] N TDM SIP-T

[17]
[13]
N N N N N Y Y
Czech ISUP
V1 and V2 variants [16]
Y Y
Y Y Y Y Y Y
Y Y Y Y Y Y
N N N N
[18]
N N N N Y Y
Y Y N N
[19]
Danish ISUP
ETSI ISUP V1 TDM Y variant SIP-T Y TDM Y
Y Y
ETSI ISUP V1 (base / generic variant)
SIP-T Y
[18]
[20]
Page
401
Nortel Networks
PROPRIETARY
Table 34: Interworking support for ISUP variants

ETSI ISUP V1 [1] ETSI ISUP V2 [1] ISUP variant Implementation SIP (no CCS7) [3] IBN lines CentrexIP DPNSS [6] Cable MGs [8] Y Y Y Y N N N N N N N N N N N N N N N N N N N H.323 [5] LAN MGs [7] V5.2 MGs [9] Y Y N N N N N N N N N N N N N N N Y Y N N Y Y PRI [4] Y Y QSIG Y Y Y Y N N N N IBN7 ISUP
TUP [2] Y
Country / name
Characteristics
INAP Y Y N N N N N N N Y Y N N N N N N Y Y N N N N
ETSI ISUP V2 (base / generic variant)
TDM
Y Y Y Y
[21]
Y Y Y Y N
[18]
Y Y N N N N N N
[19]
Y Y N N N N N N N Y Y N N N N N N N N N N N N
N N X X X X X X X Y Y X X X X X X X X X X X X
N N N N N N N N N Y Y N N N N N N N N N N N N
Y Y N N N N N Y Y N N N N N N N N N N N N N N
SIP-T Y
[18]
[20]
ETSI ISUP V2 TDM Y variant SIP-T Y German ISUP T-ISUP variant TDM of ETSI ISUP V2 only G-ISUP variant of ETSI ISUP V2 TDM Y
N N N N N N N
[18]
Y Y N N N
[22]
Y Y [21] N
Y SIP-T Y [21] N TDM Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Hong Kong ISUP
ETSI ISUP V2 variant
SIP-T Y
Y N [22] N Y Y N N N N N N N N N N N N
[23]
ANSI ISUP with TDM Y Nortel IBN7 ISUP proprietary SIP-T Y [24] extensions Indian ISUP Israeli ISUP [26] Italian ISUP Japanese JI-ISUP Malaysian ISUP ETSI ISUP V2 TDM N variant SIP-T N ETSI ISUP V2 TDM Y variant SIP-T Y V1 and V2 variants [27] TDM Y
Y Y
Y Y N N Y Y N N N N N N N N
[18]
[25]
N N N N N N N N N N N N
N N Y Y Y Y Y Y Y Y Y Y
SIP-T Y
ETSI ISUP V2 TDM Y variant SIP-T Y Capabilities equivalent to ETSI ISUP V1 [28] ETSI ISUP V1 variant TDM Y
SIP-T Y
Mexican ISUP
Y TDM [29] Y Y SIP-T [29] Y
Nortel Networks
PROPRIETARY
Page
402
Table 34: Interworking support for ISUP variants

ETSI ISUP V1 [1] ETSI ISUP V2 [1] ISUP variant Implementation SIP (no CCS7) [3] IBN lines CentrexIP DPNSS [6] Cable MGs [8] N N Y N N N N N Y N N N N N N N N N N N Y N N N H.323 [5] LAN MGs [7] V5.2 MGs [9] N N N N Y Y N N N N N N N N Y Y N N N N N N N N PRI [4] N N Y
[30]
IBN7 ISUP
TUP [2]
Country / name
Characteristics
Norwegian ISUP Portuguese ISUP Russian ISUP Singapore ISUP
ETSI ISUP V1 TDM Y variant SIP-T Y TDM Y ETSI ISUP V1 variant SIP-T Y ETSI ISUP V2 TDM Y variant SIP-T Y ETSI ISUP V2 TDM Y variant SIP-T Y V1 and V2 variants [31] [32] TDM Y
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
N N N N N N N N N N N N N N N N N N N N
[40]
N N N N N N N N Y Y N N N N N N Y Y N N N N N N
N N N N N N N N N N N N N N N N Y Y N N Y N N N
N N N N N N N N Y
QSIG
INAP
N N N N N N N N N N N N N N N N N N N N Y Y N N
X X X X X X X X X X X X X X X X X X X X N N X X
N N N N N N N N Y Y N N N N N N N N N N N N N N
N N N N Y Y N N N N N N N N N N Y Y N N N N N N
Y Y Y Y Y
Spanish ISUP
[33] [34]
SIP-T Y
Y Y Y N N Y Y Y Y Y Y Y Y N N
[34]
SPIROU (France) Swedish ISUP
ETSI ISUP V3 TDM Y variant [35] SIP-T Y ETSI ISUP V2 TDM Y variant [36] SIP-T Y
[29]
Y Y N N N N N N N N Y Y N N
TDM Telmex ETSI ISUP V1 ISUP variant (Mexico) [37] SIP-T Telstra CA30 ISUP (Australia) Turkish ISUP
[29]
ETSI ISUP V2 variant
Y Y TDM [38] [10] Y

[38]
SIP-T Y TDM N V1 and V2 [31] [39] variants SIP-T N ETSI ISUP V3 variant [35] TDM Y
Y N N Y Y Y Y
Y N N Y Y Y Y
UK ISUP
SIP-T Y
[40]
USA FGD ISUP
ANSI ISUP with TDM Y extensions for equal access [41] SIP-T Y
N N
Page
403
Nortel Networks
PROPRIETARY
[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.
Nortel Networks
PROPRIETARY
Page
404
[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
Order code NSUP0002 NSUP0003 ISP70001 NETK0041 NSUP0014 NSUP0015 NSUP0018 Name / description ETSI ISUP V1 ETSI ISUP V2 Base ISUP (ANSI IBN7) ETSI ISUP V2 Hop Counter ETSI/UK ISUP Answer No Charge Support Bearer Capability Mapping Japan Unified ISUP
Page
405
Nortel Networks
PROPRIETARY
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
E2.4.1.1
IUP / BTUP Support

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.
Nortel Networks
PROPRIETARY
Page
406
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 H0 0000 0001 0010 0011 0100 0101 0111
ACM ANS CLR SND CGN RAN UBL SSM SAD
Message Group Forward Address Messages (FAM) Forward Setup Messages (FSM) Backward Setup Request Messages (BSRM) Backward Setup Info Messages (BSIM) Call Supervision Messages (CSM) Circuit Supervision Messages (CCM) Service Information Messages (SIM)
0000 0001 0010

IAM IFAM SAM
0011 0100 0101 0110

FAM ASI SASI RA SEM HLR
0111 1010 1011 1100 1101
TCM CNA REL BLA SRV
SOO EXC
CDB
CFC OOR UBA OLM
CCTF BLO CFN ICSI
ACI OCM UUD SWAP
UIS
UIR
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.
Page
407
Nortel Networks
PROPRIETARY
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 Transit support only. Not generated, and ignored if received. OOR (H1=0101) Operator Override (TKO) Not generated. Appropriate action taken on receipt. HLR (H1=0110) Howler Transit support only. Not generated, and ignored if received. ECM (H1=0111) Extend Call Transit support only. Not generated, and ignored if received. 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 Transit support only. Not generated, and ignored if received. 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 Transit support only. Not generated, and ignored if received. UIR (H1=1101) User Initiated Resume Transit support only. Not generated, and ignored if received.
Nortel Networks
PROPRIETARY
Page
408
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 Originating switch Caller goes off-hook and dials number Ringing tone Terminating switch
IFAM (Initial and Final Address Message) Physical ringing Called party answers
ACM (Address Complete Message) Audible ringing in-band ANS (Answer Message) Speech path through-connected
Call in progress
REL (Release message) Caller goes on-hook to terminate call REL (Release message)
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. Non-interworked (all-CCS7) calls
ACI Type 7 ACI Type 1 (full CLI) or 2 (partial CLI) SASI (Send ASI) ASI Type 2 (CLI typically partial) SIM Type A SIM Type B
ACI (Additional Call Information) messages
Interworked calls
ASI (Additional Setup Information) messages SIMs (Service Information Messages)
ISDN call originations
Figure 97: IUP / BTUP messaging for call setup and clearing
Page
409
Nortel Networks
PROPRIETARY
E2.4.1.3
Feature and Service Support 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
E2.4.2.1
SSUTR2 / FTUP Support

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.
Nortel Networks
PROPRIETARY
Page
410
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 [FTUP abbrev.] H0 [1] Call Charging 0000 Messages [MT] Forward Address Messages [AD] 0001 Forward Setup GSM [3] 0010 Messages [EA] (IFG) Backward Setup [3] Request Messages 0011 GRQ (DEG) [DE] Successful Setup CHG [4] Messages, 0100 (TAX) Backward [SE] Unsuccessful SEC CGC Setup Messages, 0101 (EEC) (EFC) Backward [EE] Call Supervision 0110 Messages [SA] Circuit Group RLG Supervision 0111 BLO (LIG) Messages [SC] Network Supervision 1000 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 Messages [SN]
0011
0100
0101
0110
0111
1000 TXA [2]
1001
1010
1100
CHT [2] ITX [2] SAM SAO (MSA) (MSS) COT CCF (CCP) (CCN)
NNC (ERN)
CFL SSB UNN LOS (ECH) (OCC) (NNU) (LHS) RAN (NRP)
SST ACB MPR (TSI) (ACI) (INU)
BLA
UBL UBA CCR RSC (DBO) (DBA) (CCD) (RZC) GRS GRA (RZG) (RZA)
FIU
[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.
Page
411
Nortel Networks
PROPRIETARY
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) RIU (National ANM)
Ringing 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. FIU acknowledged by backward RLG(LIG). Analogue called party (international call) FIU sent forward 60 seconds after receipt of RAU (delay determined by T6). FIU acknowledged by backward RLG(LIG).
E2.4.2.3
Feature and Service Support 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.
Nortel Networks
PROPRIETARY
Page
412
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 H0 FAM FSM BSM SBM UBM CSM CCM GRM NSB NCB NUB NAM 0001 0010 0011 0100 0101 0110 0111 1000 1100 1101 1110 1111 OPR SLB STB MAL IAM GSM GRQ ACM SEC CGC ADI CFL UNN LOS SST ACB DPN CCL RSC IAI SAM SAO COT CCF 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011
ANC ANN CBK CLF RAN RLG BLO BLA UBL UBA
MGB MBA MGU MUA HGB HBA HGU HUA GRS GRA MPM
Page
413
Nortel Networks
PROPRIETARY
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
Nortel Networks
414
HGU (H1=0111) HUA (H1=1000) GRS (H1=1001) GRA (H1=1010)
Hardware failure Group Unblocking Hardware failure Unblocking Ack Group Reset 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
Order code NSUP0021 PNTK0001 PNTK0002 PNTK0004 PNTK0008 PNTK0009 PNTK0010 NSUP0013 TUP Variants BTUP Version 2 BTUP Version 2+ (IUP) BTUP CLI for AMA BTUP Interworking with INAP PBX BI Control BTUP BC Routing SSUTR2 Charge Message Interworking to ISDN Name / description
Page
415
Nortel Networks
PROPRIETARY
E2.5
E2.5.1
E2.5.1.1
MTP, SCCP and TCAP Support

Message Transfer Part (MTP)
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. Note: Not supported by the USP Compact (see section B1.6.1.4 on page 77).
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
PROPRIETARY Page
Nortel Networks
416
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: USP Universal Signalling Point 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. 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.
FLPP
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.
Page
417
Nortel Networks
PROPRIETARY
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 01 10 11 International network Spare (for international use only) National network 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.
Nortel Networks
PROPRIETARY
Page
418
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 selected Trunk group CLLI Route set name Outgoing message Table C7RTESET Route set name Network name Destination point code DPC OPC NI
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.
Page
419
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
420
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 ITU-T TCAP Messages/Packages BEGIN, CONTINUE, END, ABORT Components Invoke, Return Result, Return Error, Reject Numbers Variable-length numbers Fixed-length 10-digit numbers (as in NA)
ANSI TCAP
QUERY (+ Permission to terminate), As for ITU-T, but both CONVERSATION Invoke and Return (+ Permission to terminate), Result may be (Last) or RESPONSE, ABORT (Not Last)
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.
Page
421
Nortel Networks
PROPRIETARY
Chapter E3
E3.1
E3.1.1
INAP
Functional Description
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
Nortel Networks
PROPRIETARY
Page
422
Chapter E3 INAP
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 SCF
SCP SCF
Node types: SCP Service Control Point SSP Service Switching Point IP Intelligent Peripheral STP Signalling Transfer Point
STP
STP
IN functions: SCF Service Control Function SSF Service Switching Function SRF Specialised Resource Function CCF Call Control Function
SSP SSF
Integrated IP
SSP SSF
Integrated IP
SSP SSF
External IP
SSP SSF IP CCF

Integrated
SRF
SRF CCF CCF
SRF CCF
SRF
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.
Page
423
Nortel Networks
PROPRIETARY
Chapter E3 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
Nortel Networks
PROPRIETARY
Page
424
Chapter E3 INAP
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
OSI Layers
SSF protocol stack INAP Intelligent Network Application Part Component sub-layer Layer 7 Application TCAP Transaction Capabilities Application Part Transaction sub-layer Layer 6 Presentation Layer 5 Session Layer 4 Transport SCCP Signalling Connection Control Part SCCP Signalling Connection Control Part TCAP components (Invoke, Return Result, Return Error, Reject)
Logical peer-to-peer communication
SCP
SCF protocol stack INAP Intelligent Network Application Part Component sub-layer TCAP Transaction Capabilities Application Part Transaction sub-layer
INAP operations
TCAP messages (BEGIN, CONTINUE, END, ABORT)
Layer 3 Network Layer 2 Datalink Layer 1 Physical
SCCP UNITDATA messages
MTP Message Transfer Part
Message Signal Units (MSUs)
IN signalling link
Physical node-to-node communication
Figure 101: Peer-to-peer communication between IN nodes
Page
425
Nortel Networks
PROPRIETARY
Chapter E3 INAP
E3.1.4
E3.1.4.1
Interaction between Call Processing and IN

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.
Nortel Networks
PROPRIETARY
Page
426
Chapter E3 INAP
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) Calling party Dialled digits (out-of-band) Digit manipulation via CS2000 translations IN query triggered on translated CdPA SSF sends InitialDP Mandatory service key, optional CdPA SSF INAP operation parameters SCF
Result of IN query used to manipulate CdPA: Complete replacement of CdPA by DRA Cut-and-paste replacement of CdPA prefix by DRA Called party Onward routing
Mandatory DestinationRoutingAddress (DRA), optional CutAndPaste to replace prefix
SCF sends Connect
Digit manipulation 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.
Page
427
Nortel Networks
PROPRIETARY
Chapter E3 INAP
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 agent Incoming call Leg 1 of call (before triggering)
Basic call interworking
Terminating agent Onward routing Leg 2 of call (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.
PROPRIETARY Page
Nortel Networks
428
Chapter E3 INAP
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)
Originating agent Incoming call Leg 1 of call (initially non-IN)
Terminating agent Call completion Leg 2 of call (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.
Page
429
Nortel Networks
PROPRIETARY
Chapter E3 INAP
E3.2
E3.2.1
E3.2.1.1
CS2000 Implementation
INAP Operation Support
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.
Nortel Networks
PROPRIETARY
Page
430
Chapter E3 INAP
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.
Page
431
Nortel Networks
PROPRIETARY
Chapter E3 INAP
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.
Nortel Networks
PROPRIETARY
Page
432
Chapter E3 INAP
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) 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.
Page
433
Nortel Networks
PROPRIETARY
Chapter E3 INAP
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.
Nortel Networks
PROPRIETARY
Page
434
Chapter E3 INAP
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
Page
435
Nortel Networks
PROPRIETARY
Chapter E3 INAP
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 call segment
Second SSF FSM and O_BCSM created when leg is split off from stable call
SSF FSM
SSF FSM
CS2000 SSP
INAP interworking
INAP interworking Terminating agent
Two O_BCSMs, one for each call segment
O_BCSM
O_BCSM Basic call interworking
Leg 3 of call (added later)
Originating agent Incoming call Leg 1 of call (before triggering)
Terminating agent Onward routing Leg 2 of call (onward routing)
Figure 105: Interactions between software entities for a two-segment IN call
Nortel Networks
PROPRIETARY
Page
436
Chapter E3 INAP
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.
Page
437
Nortel Networks
PROPRIETARY
Chapter E3 INAP
E3.2.2
E3.2.2.1
Detection Point Support

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 O_BCSM DP T_BCSM DP Trigger Detection Points (TDPs) used to initiate IN interaction TDP-2 Dialled digits available (Collected_Info) TDP-3 Translated digits available (Analyzed_Info) No route available TDP-4 (e.g. network congestion) (Route_Select_Failure) TDP-12 Call termination authorised (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 (T_Busy) (O_Busy) Not supported in ISN07 EDP-14 EDP-6 No answer from called party (T_No_Answer) (O_No_Answer) Not supported in ISN07 EDP15 EDP-7 Called party answers (T_Answer) (O_Answer) Not supported in ISN07 EDP-16 Call party interrupts EDP-8 (T_Mid_Call) active call (O_Mid_Call) Not supported in ISN07 EDP-17 Call party disconnects EDP-9 (T_Disconnect) after call is answered (O_Disconnect) Not supported in ISN07 EDP-18 Caller hangs up EDP-10 (T_Abandon) before call is answered (O_Abandon) Not supported in ISN07 Call processing event
Nortel Networks
PROPRIETARY
Page
438
Chapter E3 INAP
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.
Page
439
Nortel Networks
PROPRIETARY
Chapter E3 INAP
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.
Nortel Networks
PROPRIETARY
Page
440
Chapter E3 INAP
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.
Page
441
Nortel Networks
PROPRIETARY
Chapter E3 INAP
E3.3
E3.3.1
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.
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
CCF protocol stack SSF/SRF protocol stack INAP Intelligent Network Application Part ETSI ISUP ISDN User Part TCAP Transaction Capabilities Application Part
SCP
SCF protocol stack INAP Intelligent Network Application Part TCAP Transaction Capabilities Application Part
Layer 7 Application
Layer 6 Presentation Layer 5 Session Layer 4 Transport Layer 3 Network
SCCP Signalling Connection Control Part
SCCP Signalling Connection Control Part
Layer 2 Datalink Layer 1 Physical
Call from PSTN
IN signalling link
Figure 106: IN-related signalling interactions
Nortel Networks
PROPRIETARY
Page
442
Chapter E3 INAP
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.
Page
443
Nortel Networks
PROPRIETARY
Chapter E3 INAP
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
Order code DSSP0001 ISSP0002 ISSP0005 INAP0002 INAP0003 INAP0004 INAP0005 DSSP0007 DSSP0008 DSSP0010 DSSP0013 DSSP0014 DSSP0015 DSSP0017 DSSP0018 DSSP0019 DSSP0021 DSSP0022 DSSP0028 Basic CS-1R SSP IN Trigger Processing Originating Basic Call State Machine EDPs INAP Interworking with Lines INAP Interworking with IBN7 ISUP INAP Interworking with ETSI ISUP INAP Interworking with PRI Trunk Trigger Subscription CS-1R Service Filtering AMA FCI Call Information Request and Report CS-1R TDP2 Call Party Handling CS-1R Call Gapping Point of Re-entry Control CS-1R Correlation ID SSP - Strip Leading Digits SSP - OCI Retention and Capture in AMA for Follow-on Calls Apply Charging Name / description
Nortel Networks
PROPRIETARY
Page
444
Chapter E4
E4.1
E4.1.1
PRI Access Interface
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 of access interface; CS2000 implements network side
NT2 T Digital PBX (CTR4) IP or ATM backbone network Combined
CS2000
SIP-T CCS7
S
Terminals
PRI trunk media and access signalling gateway (30B+D (PVG or or 23B+D) Mediant
2000)
Q.931 / IUA / SCTP (call control) H.248 or ASPEN over UDP (media control)
GWC
Packet network media streams
Figure 107: ETSI ISDN PRI access to a CS2000 network
Nortel Networks
PROPRIETARY
Page
445
Chapter E4 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.
Nortel Networks
PROPRIETARY
Page
446
E4.1.3
E4.1.3.1
Specifications
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.
Page
447
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
448
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
User phones and terminals Gateway PTNX (digital PBX) U PRI(T) access trunks ASPEN Q.931 N
GWC CS2000
User phones and terminals ASPEN Gateway Q.931 N PRI(T) access trunks PTNX (digital U PBX)
SIP-T CCS7
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
Page
449
Nortel Networks
PROPRIETARY
E4.2
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
Nortel Networks
PROPRIETARY
Page
450
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
The steps involved are numbered sequentially in the annotated network architecture shown in Figure 109, and are described in order on the following page.
ISDN signalling
Even if an ATM backbone network is in use, signalling to/from/between GWCs is conveyed over IP ( IP / AAL5 / ATM over STM-1)
Packet network control signalling (2 types) TDM bearer channels Packet network bearer connections
Originating CS2000
Call processing 3 4 5a 5b Access 8 DPT GWCs Gateway Controller 27 and Session Server; (GWC) Ingress 34 Egress TDM-side 35 packet-side 36 6 37 28 29 Two types of signalling: Media control via H.248 Call control via PRI/IUA/SCTP 2 7 9 26 38a
Terminating CS2000
Call processing 15 11 12 13 14 16a 16b Access DPT GWCs Gateway and Session 22 Controller Server; (GWC) Ingress 32 Egress TDM-side packet-side 10 38b 23 24 25 18 20 21 31
Inter-CS signalling (CCS7 signalling encapsulated in SIP-T)
Packet network (ATM or IP)
Two types of signalling: Media control via H.248 Call control via PRI/IUA/SCTP 19 Terminating Gateway
Originating Gateway
Bearer connection (packetised voice)

PRI access (30B+D or 23B+D) PRI access (30B+D or 23B+D)
Call origination
Call termination
PSTN or private network

Figure 109: Setting up a networked PRI call between two CS2000s
Page
451
Nortel Networks
PROPRIETARY
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 2 3
5a 5b
10
11
12 13 14 15 16a 16b
Q.931 SETUP message for incoming call arrives at originating gateway SETUP for incoming call encapsulated using IUA / SCTP and conveyed to GWC 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 - 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. CS2000 Core sends FCM (Fabric Control Message) to ingress and egress GWCs to 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 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 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). 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 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 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 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. 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. Ingress Session Server forwards IAM extracted from INVITE message to selected DPT on ingress DPT GWC Ingress DPT GWC forwards IAM to CS2000 Core, requesting it to initiate call processing CS2000 Core uses IAM to perform translations and routing, and identifies the egress access GWC and gateway serving the destination CS2000 Core sends FCM to ingress and egress GWCs to enable direct communication between them
Nortel Networks
PROPRIETARY
Page
452
17
18
19
20 21 22
23 24 25 26 27 28 29 30 31
32
33 34 35 36
37 38a 38b
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 establish mapping between TDM-side and packet-side terminations. First Add 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. Media gateway response to second Add command provides GWC with endpoint identifier (IP address) to use for logical termination, together with SDP description of bearer capabilities supported (for use in codec negotiation with the originating media gateway serving the originating endpoint). Outgoing SETUP created, encapsulated using IUA / SCTP, and sent out by terminating GWC Backward ALERTING (encapsulated using IUA) received by terminating egress GWC CS2000 Core receives the ALERTING as a progress message and passes an ACM to 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 Ingress Session Server encapsulates outgoing ACM in a backward SIP-T 183 SESSION PROGRESS message, then sends message to originating CS2000 Ingress DPT GWC sends ingress Session Server a request for ringback tone to be applied to originating TDM-side trunk. 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 RINGING messages, extracting backward ACM from SESSION PROGRESS message and forwarding it to egress DPT GWC Egress DPT GWC on originating CS2000 passes a message to the Core, which in turn passes an ALERTING message to the ingress access GWC Ingress GWC encapsulates ALERTING message using IUA/SCTP and sends it to originating gateway Ingress access GWC sends H.248 Modify message to originating media gateway, asking gateway to apply ringback tone to originating TDM-side trunk Backward CONNECT (encapsulated using IUA) received by terminating egress GWC 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 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 Ingress Session Server encapsulates outgoing ANM and associated SDP in a backward SIP-T 200 OK message, then sends message to originating CS2000 Egress Session Server on originating CS2000 extracts ANM from SIP-T message and forwards it to egress DPT GWC Egress DPT GWC on originating CS2000 passes ANM to the Core, which in turn passes a CONNECT message to the ingress access GWC Ingress access GWC sends H.248 Modify message to originating media gateway, 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 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 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
Page
453
Nortel Networks
PROPRIETARY
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 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 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 Base ETSI PRI Spanish PRI Chinese PRI Hong Kong PRI (CR13) Japanese PRI (INS1500 Version 5) ANSI PRI QSIG (ISO / 1996) QSIG (ETSI / 1993) VARIANT field ETSIPRI ETSIPRI ETSIPRI HKPRI INSPRI ANSI QSIGPRI QSIGPRI ISSUE field 1990 SPAIN1 CHINA1 V1 V2 V1 ISO1996 ETSI1993
Nortel Networks
PROPRIETARY
Page
454
E4.3
E4.3.1
Capabilities Supported
Message Support
Supported in Message category Message name ETS 300 403 section 3.1.1 3.1.2 3.1.3 3.1.4 3.1.8 3.1.14 3.1.15 3.1.11 3.1.12 3.1.13 3.1.18 3.1.19 3.1.20 3.1.5 3.1.9 3.1.10 3.1.8 3.1.9 3.5.1 3.1.16 3.1.17 N/A 3.4.1 3.4.2 3.4.3 3.5.1 ETSI variant issues Base
ALERTING CALL PROCEEDING
Hong Japan USA Kong (INS (ANSI) Spain China (CR13) 1500) Y Y Y Y Y Y Y
[2]
Y Y Y Y Y Y Y N N N N N N Y Y Y Y Y N [6] Y Y Y [7] Y Y Y N
[6]
Y Y Y Y Y Y Y N N N N N N Y Y Y Y Y N [6] Y Y N Y Y Y N
[6]
Y Y Y Y Y Y Y
[2]
Y Y Y Y Y [1] Y N
[3]
Y Y Y Y Y Y N [3] N N N N N N Y Y Y N [3] Y N [6] Y Y N Y Y Y N [6]
Call establishment messages
CONNECT CONNECT ACK PROGRESS SETUP SETUP ACK RESUME [4] RESUME ACK [4]
N N N N N N Y Y Y Y
[2]
N N N N N N Y Y Y Y
[2]
N N N N N N Y Y Y N
[3]
Call information phase messages
RESUME REJECT [4] SUSPEND [4] SUSPEND ACK [4] SUSPEND REJECT [4] DISCONNECT
Call clearing messages
RELEASE RELEASE COMPLETE INFORMATION NOTIFY
Y N [6] Y Y Y [7] Y Y Y N
[6]
Y N [6] Y Y N Y Y Y N
[6]
Y [5] N [6] Y Y Y [7] Y Y Y N

[6]
Miscellaneous messages
SEGMENT STATUS STATUS ENQUIRY FACILITY RESTART
Global call reference messages
RESTART ACK STATUS SEGMENT
[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.
Page
455
Nortel Networks
PROPRIETARY
E4.3.2
Information Element Support

IE name Bearer Capability Call Identity Call State Called Party Number Called Party Subaddress Calling Party Number Calling Party Subaddress Cause [5] Channel Identification Date/time Display Facility High Layer Compatibility Keypad Facility Low Layer Compatibility Network Specific Facilities Notification Indicator Progress Indicator [11] Restart Indicator Segmented Message
[7] [3]
ETS Max. 300 403 length section (octets) 4.5.5 4.5.6 4.5.7 4.5.8 4.5.9 4.5.10 4.5.11 4.5.12 4.5.13 4.5.15 4.5.16 N/A 4.5.17 4.5.18 4.5.19 4.5.21 4.5.22 4.5.23 4.5.25 4.5.26 1 128 [13] 5 34 18 3 4 3 12 10 3 23 23 24 23 32 34 8 82
Supported in ETSI variant issues Hong Kong Base Spain China (CR13) Y N Y Y Y Y Y Y Y N N Y [10] Y Y Y N Y Y Y N [12] Y N Y [14] Y N Y Y Y Y Y Y Y N N Y [10] Y Y Y N Y Y Y N [12] Y N Y [14] Y [1] N Y Y Y Y [1] Y Y [1] Y
[1] [1]
Japan (INS 1500) Y [2] N Y [4] Y Y Y Y Y [6] Y [8] [9] N N Y [10] Y Y Y N Y Y Y N [12] N N Y [14]
USA (ANSI) Y N Y [4] Y N Y N Y Y N N N Y N Y N N Y Y N [12] N N N
Y N Y Y Y Y Y Y Y N Y N Y N Y N Y Y Y N [12] Y N N
N N N Y N Y N Y Y [1] Y N [12] Y N Y [14]
Sending Complete 4.5.27 Transit Network Selection 4.5.29 User-to-User Information N/A
[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).
Nortel Networks
PROPRIETARY
Page
456
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 Teleservices Telefax Group 4 [3] Teletex [3] Videotex [3] MoU1 supplementary services Calling Line Identification Presentation (CLIP) Calling Line Identification Restriction (CLIR) 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 supplementary services Subaddressing (SUB) 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.
Page
457
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
458
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.
Page
459
Nortel Networks
PROPRIETARY
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.
! !
! ! !
E4.5

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
Order code PRIT0002 PRIT0011 PRIT0004 Name / description ETSI PRI / PRI Services INS1500 Japanese PRI PRI DN Billing
Nortel Networks
PROPRIETARY
Page
460
Chapter E5
E5.1
E5.1.1
QSIG VPN Interface
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
Nortel Networks
461
Chapter E5 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 originating PINX functionality for directly connected lines or Gateway PINX providing incoming gateway PINX functionality for incoming trunks Switching and service logic
Transit PINX
End PINX providing terminating PINX functionality for directly connected lines or Gateway PINX providing outgoing gateway PINX functionality for outgoing trunks Switching and service logic
Switching and service logic
Mapping and physical terminations
Incoming trunk
Directly connected caller
QSIG protocol stack
Directly connected called party
QSIG
QSIG Generic Functional Procedures for service support (IS 11582) Q reference point exists within PINX; it defines the mapping between QSIG signalling (Layer 3+) and the chosen Layer 2 QSIG Layer 3 call processing (IS 11572) Based on DSS1 Layer 3, i.e. Q.931 / PRI DSS1 Layer 2 (Q.921) As for PRI PRI Layer 1 (ETS 300 011) 2Mb/s 30B+D
Outgoing trunk
Q
C reference point exists between PINXs; it defines the chosen Layer 1
Figure 110: QSIG logical network architecture and terminology
Nortel Networks
PROPRIETARY
Page
462
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
GWC-MG control signalling (ASPEN)
CS2000 GWC
GWC-MG control signalling (ASPEN)
QSIG backhaul
QSIG backhaul
Bearer connection (packetised voice) Gateway Gateway
QSIG PINX
QSIG PINX
Figure 111: QSIG over a packet network
Page
463
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
464
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 Combined (call control) media and signalling gateway ASPEN over UDP (media control) (PVG) QFT / APM / ISUPv2 / SIP-T (basic call and service control)
PBX
QSIG
GWC
Note: Direct QSIG to QSIG interworking occurs only between gateways controlled 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.
Page
465
Nortel Networks
PROPRIETARY
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.
PROPRIETARY Page
Nortel Networks
466
"
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 service control (service-specific) Supplementary service control (service-specific)
GFT
Co-ordination function ROSE ACSE DSE
Layer 7: Application ROSE ACSE DSE
GFT
Co-ordination function
Basic call control
Basic call control
GFT control
APDUs
GFT control
Layer 3: Network Protocol control Protocol control
Messages and parameters
Signalling Carriage Mechanism Data Link Layer (Layer 2) Physical Layer (Layer 1)
Signalling Carriage Mechanism Data Link Layer (Layer 2) 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.
Page
467
Nortel Networks
PROPRIETARY
E5.1.4

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 originating or gateway node
PINX SETUP
QSIG transit node
QSIG terminating or gateway node

SETUP
*
SETUP ACK
PINX
PINX
INFORMATION (1 or more) CALL PROCEEDING ALERTING
SETUP ACK (Overlap signalling INFORMATION only) (1 or more) CALL PROCEEDING ALERTING
* CONNECT *
* CONNECT *
CONNECT ACK
CONNECT ACK Call in progress
DISCONNECT
*
RELEASE
DISCONNECT
*
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 SETUP ALERTING CONNECT DISCONNECT RELEASE RELEASE COMPLETE FACILITY NOTIFY PROGRESS Yes Yes Yes Yes Yes Yes Yes No Yes Notification IE Yes Yes Yes Yes No No Yes Yes Yes
Nortel Networks
PROPRIETARY
Page
468
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 Application APM ISUP SIP-T APM ISUP SIP-T Application APM ISUP 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.
Page
469
Nortel Networks
PROPRIETARY
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 transit node, e.g. CS2000 PINX SETUP ACK INFORMATION (1 or more) CALL PROCEEDING ALERTING For a basic non-QFT ISUP call over the backbone packet network, QSIG INFORMATION messages are interworked to ISUP SAMs, not APMs Page QSIG originating or gateway node, e.g. PBX PINX
QSIG call setup *
QFT call setup

IAM
SETUP
*
APM *
(Overlap signalling only)
APM * (1 or more) ACM * CPG * ANM *
* CONNECT *
CONNECT ACK Call in progress DISCONNECT
*
RELEASE
REL
RLC
RELEASE COMPLETE
* *
ISUP V2+ message capable of conveying APP for QFT
QSIG message capable of conveying Faclity and/or Notification IE
Figure 116: Bearer QFT call setup and clearing
Nortel Networks
PROPRIETARY
470
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 Application TCAP SCCP MTP3 M2PA SCCP MTP3 M2PA Application TCAP SCCP MTP3 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 PSS1_SETUP (request) PSS1_SETUP (response) PSS1_SETUP (confirmation) PSS1_REJECT PSS1_FACILITY PSS1_RELEASE TCAP equivalent BEGIN [SETUP.Invoke] CONTINUE [SETUP.ReturnResult] CONTINUE [CONNECT.Invoke] CONTINUE [SETUP.ReturnResult] CONTINUE [FACILITY.Invoke] END [RELEASE.Invoke] QSIG message SETUP CALL PROCEEDING CONNECT No QSIG equivalent (call setup fails) FACILITY RELEASE
Page
471
Nortel Networks
PROPRIETARY
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 PIN ISUP V2 network or SCCP network
Application PAN PIN ISUP V2 network or SCCP network
Application PIN
PINX A
PINX B
PINX C
Figure 118: Chaining PIN/PAN relationships
Nortel Networks
PROPRIETARY
Page
472
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.
E5.1.6
Specifications
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).
! ! ! ! ! ! ! ! !
Page
473
Nortel Networks
PROPRIETARY
E5.2
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
Nortel Networks
PROPRIETARY
Page
474
E5.2.2
E5.2.2.1
Software Support
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 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 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 ISO 1996 QSIG ETSI 1993 QSIG VARIANT field QSIGPRI QSIGPRI ISSUE field ISO1996 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.
Page
475
Nortel Networks
PROPRIETARY
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 SETUP PROGRESS FACILITY NOTIFY DISCONNECT [1] RELEASE [1] RELEASE COMPLETE [1] Messages in the backward direction PROGRESS ALERTING CONNECT FACILITY NOTIFY DISCONNECT [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.
PROPRIETARY Page
Nortel Networks
476
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
PINX
QSIG Virtual transit PINX ISUP with QFT
ISUP v2 network
QFT TC protocol
SCCP network Figure 119: Originating node capabilities
Destination: assumed to support QFT
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.
Page
477
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
478
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.
Page
479
Nortel Networks
PROPRIETARY
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 Bearer Services Circuit mode 64kbit/s unrestricted bearer service Circuit mode 3.1kHz audio bearer service Circuit mode rate adapted 56kbit/s data 3.1 KHz telephony Teleservices Telefax Group 4 Teletex Videotex Calling Line Identification Presentation (CLIP) [1] Calling Line Identification Restriction (CLIR) [1] Connected Line Identification Presentation (COLP) Supplementary services Connected Line Identification Restriction (COLR) Advice Of Charge During Call (AOC-D) Advice Of Charge at End of Call (AOC-E) Call Completion to Busy Subscriber (CCBS) 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).
Nortel Networks
480
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 possibility of introducing multiple echo cancellers is minimised.
! ! ! ! ! ! ! !
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.
Page
481
Nortel Networks
PROPRIETARY
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.
E5.4

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 Connected Line Identification Presentation (COLP) Connected Line Identification Restriction (COLR) Advice Of Charge (AOC) Call Completion to Busy Subscriber (CCBS) Call Completion on No Reply (CCNR) 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
Order code PRIT0012 VPNW0004 QSIG QFT over ETSI ISUP Name / description
Nortel Networks
PROPRIETARY
Page
482
Chapter E6
E6.1
E6.1.1
DPNSS Interface
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 multi-vendor network. Figure 120 is a schematic illustration of the network role of DPNSS and the different types of DPNSS functionality that may be provided.
Lines End node functionality PBX or switch, e.g. CS2000 Non-DPNSS trunk Gateway functionality DPNSS PBX or switch, e.g. CS2000 Transit node functionality DPNSS Lines End node functionality PBX or switch, e.g. CS2000 Gateway functionality Non-DPNSS trunk
Figure 120: The network role of DPNSS
Nortel Networks
PROPRIETARY
Page
483
Chapter E6 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

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.
Originating node Caller goes off-hook and dials number ISRM (Initial Service Request Message) Ringing tone Terminating node
NAM (Number Acknowledgement Message) Audible ringing in-band CCM (Call Connect Message) Speech path through-connected
Physical ringing Called party answers
Call in progress
CRM (Clear Request Message) Caller goes on-hook to terminate call CIM (Clear Indication Message)
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
Nortel Networks
484
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.
E6.1.4
Specifications
DPNSS is defined in BTNR 188. Interworking to other UK signalling standards (e.g. DASS2) is defined in BTNR 189.
E6.2
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.
Page
485
Nortel Networks
PROPRIETARY
Figure 122 illustrates the network configuration used by CS2000 to support DPNSS signalling.
CS2000 CS LAN
DPNSS over DFT trunks (NTP[HNIP] in IBN7 messages) CS2000 Core Looparounds for interoperability with IBN lines
To/from other CS2000s To/from TDM VPNs
H.323 proxy GWC
DPNSS over QSIG (in QSIG Facility IEs)
H.323 proxy GWC
IP core network
DPNSS over E1 carriers Westell iQ203x gateway Westell iQ203x gateway DPNSS over E1 carriers
Digital PBX
Bearer connections
Digital PBX
Figure 122: CS2000 support for DPNSS signalling
Nortel Networks
PROPRIETARY
Page
486
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
PBX
DPNSS features
DPNSS
DPNSS
CS2000
PBX
DPNSS 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 features
DPNSS
CS2000
DFT
CS2000
DFT
CS2000
DPNSS
PBX
DPNSS 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
Page
487
Nortel Networks
PROPRIETARY
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
PBX
DPNSS features
DPNSS
CS2000 DFT looparound
line interface DPNSS features
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.
Nortel Networks
PROPRIETARY
Page
488
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 PBX
DPNSS features DPNSS QSIG I/W Non-DPNSS trunk i/f
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 PBXA0002 PBXA0019 CS2B0004 DPNSS base DPNSS to IBN7 (ANSI ISUP+) interworking H.323 support Description
Page
489
Nortel Networks
PROPRIETARY
Chapter E7
E7.1
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). 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. 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.
Nortel Networks
PROPRIETARY
Page
490
Chapter E7 IBN Lines
E7.2
E7.2.1
E7.2.1.1
Lines off Large Carrier-Located Gateways
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
Dual PP8600s
GWC-gateway signalling (H.248) Bearer connections for VoIP Bearer connections for data are independent of CS2000-controlled VoIP connections
Core network
MG9000
Lines and ADSL
Figure 127: Functional view of capabilities provided by carrier located line media gateways
Page
491
Nortel Networks
PROPRIETARY
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: ! ! E7.2.1.3 1952 POTS lines per frame 488 POTS+ADSL lines per frame
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.
Nortel Networks
PROPRIETARY
Page
492
E7.2.2
E7.2.2.1
Cable Lines off MTA Gateways

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 router) DOCSIS control connections between CMTS and MTA (terminated at CMTS) Bearer connections (DOCSIS packet flows converted to/from IP packet flows at CMTS)
IP backbone network
HFC cable access network
Multimedia Terminal Adaptor

Two RJ-11 terminations for analogue subscriber lines (also an Ethernet/USB port for a PC) Codecs supporting analogue / digital conversion (G.711 A-law) HFC cable modem supporting access to the IP backbone network via a cable access network
NCS (Euro)DOCSIS Bearer flows
CMTS Edge router
Figure 128: Logical configuration of an MTA line gateway
Page
493
Nortel Networks
PROPRIETARY
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
The steps involved are numbered sequentially in the annotated network architecture shown in Figure 129, and are described in order on the following pages.
Packet network control signalling Analogue subscriber lines Packet network bearer connections
CS2000
2 5 Call processing 6 7a 10 13 20 7b Gateway Controller (GWC) for egress gateway
Gateway Controller (GWC) for ingress gateway
IP backbone network
Bearer connection (packetised voice) CMTS
1 9 4 22a Originating Gateway (MTA)
CMTS HFC cable access networks

Signalling between CMTS and MTAs is based on (Euro)DOCSIS, and is not visible to the CS2000 GWCs that control the MTA gateways 12 18 16 22b Terminating Gateway (MTA)
Call origination
Call termination
Figure 129: Setting up a VoIP call between two CS2000 lines
Nortel Networks
PROPRIETARY
Signalling between CS2000 GWC and MTA line gateway uses NCS Page
3 8a 14 17 21
11 15 19
494
1 2
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 Ingress GWC sends an origination message to the CS2000 Core. Ingress GWC sends RQNT to MTA gateway, instructing it to: - 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 6
Ingress GWC passes received digits on to the Core 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 communication between the two GWCs.
7a 7b initiate establishment of bearer path connection between the MTAs, and to set up
Ingress GWC sends CRCX to originating MTA line gateway, instructing it to set up an initially inactive bearer connection for the line endpoint in question, specifying: 8 - 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 - Transport protocol, i.e. RTP 9 - 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 selected line endpoint, with local connection options set to PCM A-law with 10ms 11 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
Page
495
Nortel Networks
PROPRIETARY
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 Ingress GWC sends RQNT to originating MTA line gateway, instructing the gateway to apply ringback tone 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
17
18
Egress GWC sends NCS MDCX to terminating MTA line gateway, instructing the gateway to place the bearer connection in send/receive mode, and to report the 19 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.
Nortel Networks
PROPRIETARY
Page
496
E7.2.3
E7.2.3.1
Customer LAN Lines

Access Configuration 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 determined in consultation with Nortel Sales Engineering. 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 Gateway

RJ-11 or RJ-21X terminations for analogue subscriber lines Codecs supporting analogue / digital conversion (G.711, G.729) LAN interface supporting access to the IP backbone network via a customer LAN
Customer LAN MGCP
MGCP
Alternative access technologies available
Bearer flows
Bearer flow
IP backbone network
Figure 130: Logical configuration of a customer LAN line gateway
Page
497
Nortel Networks
PROPRIETARY
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: ! ! 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.
Nortel Networks
PROPRIETARY
Page
498
E7.2.4
E7.2.4.1
V5.2 PSTN Lines

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: ! ! ETS 300 324-1 (1994) with Amendment ETS 300 324-1/A1 (1996) ETS 300 347-1 (1994) with Amendment ETS 300 347-1/A1 (1997)
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.
Page
499
Nortel Networks
PROPRIETARY
E7.2.4.3
Access Configuration 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 For analogue lines, V5-PSTN call control messages convey the equivalents of 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 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. V5 system management messages for controlling interaction with V5.2 Layer 2 via primitives, e.g. establishing or releasing a V5.2 C-channel. V5 system management messages for controlling interaction with V5.2 Layer 1 via 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.
PROPRIETARY Page
! !
Nortel Networks
500
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
Page
501
Nortel Networks
PROPRIETARY
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 Originating access node Caller goes off-hook AN
V5UA
V5UA
LAPV5 Terminating access node AN
CS2000 LE
ESTABLISH (SS: off-hook)
EST ACK
Bearer channel connected Dial tone DTMF dialling Ringing tone ESTABLISH (CR: type 0) EST ACK SIGNAL (SS: off-hook) Active call Caller goes on-hook Called party goes off-hook
Ringing
SIGNAL (SS: on-hook)
DISCONNECT
Treatment SIGNAL (SS: on-hook) Called party goes on-hook
DISCONNECT COMPLETE
DISCONNECT
DISCONNECT COMPLETE
Figure 131: V5.2 PSTN call setup and clearing
Nortel Networks
PROPRIETARY
Page
502
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.
Page
503
Nortel Networks
PROPRIETARY
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.
Nortel Networks
504
"
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.
Page
505
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
506
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.
E7.4

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
Order code ILIN0100 ACSI0003 CS2Q0001 IBN Line Usage V5.2 Lines DQoS Support for Cable Name / description
Page
507
Nortel Networks
PROPRIETARY
Chapter E8
E8.1
CentrexIP Lines
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. 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.
Nortel Networks
PROPRIETARY
Page
508
Chapter E8 CentrexIP Lines
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 downloading an appropriate set of feature key assignments.
Page
509
Nortel Networks
PROPRIETARY
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
Standard numeric keypad for point-and-click dialling
Feature keys with dynamically assigned functons
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 downloading an appropriate set of feature key assignments.
Nortel Networks
510
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 section E8.2.2 on page 510. ! 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.
PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004
Page
511
Nortel Networks
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 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 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: I2001 i2001 Etherset I2002 i2001 Etherset I2004 i2001 Etherset M6350 m6350 soft client 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.
Nortel Networks
PROPRIETARY
Page
512
Figure 133 illustrates the network configuration used by CS2000 to provide VoIP support for CentrexIP clients.
CS2000 exercises control over remote CentrexIP clients using three 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 the CICM GWC and the CICM. UniStim signalling is used between CICM and remote CentrexIP clients.
CS2000 CS LAN
CS2000 Core
GWC for CICM
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 UniStim
IP core network
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

Speech transmission and reception via headset. Call control via CentrexIP client application GUI.
Bearer connections for non-VoIP-related data sessions are independent of CS2000
Figure 133: CS2000 support for CentrexIP line access
Page
513
Nortel Networks
PROPRIETARY
Chapter F1 Feature Support Overview
Chapter F1
F1.1
Feature Support Overview
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.
Page
515
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
516
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.
Page
517
Nortel Networks
PROPRIETARY
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
Call processing and service logic GWC for media gateway SIP-T DPT GWC
CS2000
Call processing and service logic
SIP-T signalling
SIP-T DPT GWC
GWC for media gateway
Service requests
GWC-MG signalling
Media gateway
GWC-MG signalling Media stream

Media 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
Call processing and service logic GWC for media gateway Egress DPT GWC
CS2000
Call processing and service logic
SIP-T signalling
GWC-MG signalling
Service requests
Ingress DPT GWC
Trunk GWC
GWC for media gateway
GWC-MG signalling
Media gateway
Media stream
PVG with TDM-side looparounds
Media gateway
Media stream relayed through PVG via TDM-side looparound
Figure 134: Mechanisms used to support services in a packet network environment
Nortel Networks
PROPRIETARY
Page
518
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.
Page
519
Nortel Networks
PROPRIETARY
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).
Nortel Networks
PROPRIETARY
Page
520
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
Service or capability Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? Details (including restrictions 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 loop-around trunk providing a 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 are present in the switch. Callp interactions on line gateway cause issue if APG cannot be inserted. Can use translations to forward call to TDM looparound trunk and provide service there Can use translations to forward call to TDM looparound trunk and provide service there Can use translations to forward call to TDM looparound trunk and provide service there Can use translations to forward call to TDM looparound trunk and provide service there
Route to local treatment (busy, reorder, etc)
No
Yes
Yes
CEPT Hold tone
No
Yes
No
Single-stage Indirect Access via DISA Authcode-based Indirect Access Indirect Access, Account Code Required Indirect Access, MONA via ambiguous translations
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
Page
521
Nortel Networks
PROPRIETARY
Table 46: DPT interaction support for system features and capabilities
Service or capability Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? No Yes Yes Details (including restrictions and comments) Must insert TDM looparound trunk after the SIP-T leg of the call in order to enable reorigination Can use translations to forward call to TDM looparound trunk and provide service there Detection of mid-call events (* or #) not supported for SIP-T trunks
Call re-origination
Call-Forward Remote Activation (CFRA) (IN) CS-1R INAP
No Yes
Yes Yes
Yes No
Table 47: DPT interaction support for analogue subscriber line services and options
Service or option 3-Way Call (3WC) Add On Announcement before Routing (ABR) Anonymous Call Rejection (ACRJ) Authorisation Code Automatic Call Back Automatic Collect Call (ACC) ACC Blocking (ACCB) Automatic Line (AUL)) Automatic Recall (AR) Automatic Recall of Dialable Directory Number (ARDDN) Basic Call with ODP Bridged Night Number (BNN) Call Completion to Busy Subscriber (CCBS) Call Forward Busy (CFB) Call Forward Call Waiting Calls (CFCW) Call Forward on Don't Answer (CFD) CFD with Variable Timing (CFDVT) Call Forward Indication (CFIND) Call Forward Intragroup (CFI/CBI/CDI)) Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No Yes No No Yes Yes No No No No No No No No No No No No n/a n/a n/a Yes n/a n/a No No n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a Provision treatment as announcement or backward release with cause Details (including restrictions and comments)
Nortel Networks
PROPRIETARY
Page
522
Service or option Call Forward Remote Activation (CFRA) Call Forward Unconditional (CFU) Call Forward Validation (CFWVAL) Call Forward with Announcement (CFWANN) Call Hold (CHD) Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? No Yes Yes Yes Yes Yes No No No Yes Yes n/a n/a n/a Yes Configure music on hold using announcement, instead of audible ringback Configure music on hold using announcement, instead of audible ringback Details (including restrictions and comments) Must use XLA to route to looparound trunk
Call Park (PRK) Call Pickup (CPU) Call Restrict Area (CRA) Call Transfer (CXR) Call Waiting (CWT)
Yes Yes Yes Yes Yes
Yes No No Yes No
Yes n/a n/a Yes n/a
Audible ringback is not heard in case of blind call transfer CWR requires special audible ringback, which cannot be provided over SIP-T because the SIP-T spec defines no way of indicating this
Call Waiting Ringback (CWR)
No
Yes
No
Calling Line Flash (CLF) [for malicious call identification] Calling Name Delivery (CNAMD) Calling Name Delivery Blocking (CNAB) Calling Number Delivery (CND) Calling Number Delivery Blocking (CNDB) Calling Number Delivery Blocking Override (CNDBO) Cancel Call Waiting (CCW) Carrier Selection Call Completion to Busy Subscriber (CCBS) CEPT Call Forward Features CEPT Call Forward Remote Access CEPT Call Transfer (ICT) CEPT Hot Line/Warm Line
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
No No No No No No No No No
n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a
No No No
n/a n/a n/a
Page
523
Nortel Networks
PROPRIETARY
Service or option Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? Yes Yes Yes Details (including restrictions and comments) Configure music on hold using announcement (hold tone not supported) Configure music on hold using announcement (hold tone not supported)
CEPT International Call Waiting (ICWT) CEPT International Three Way Call including Consultation Hold (I3WC) CEPT Memo Box: Call FWD to Voice Mail CEPT International Line Restrictions CEPT SUPPRESS (permanent CLI blocking) CEPT Visual Message Waiting Indicator CEPT International Wake Up Call (IWUC) Circular Hunting (CIR) Code Restrictions (NCOS based call barring) Conference Call Chaining (3-Port) Delivery of Dialable Number (DDN) Denied Incoming Call Forwarding Denied Origination (DOR) Denied Termination (DTM) Direct Inward Dialing (DID) Direct Outward Dialing (DOD) Direct System Inward Access (DISA) Directed Call Park (DCPK) Directed Call Pickup (DCPU) Directory Numer Hunting (DNH) Distinctive Ringing (DRING) Distinctive Ringing / Call Waiting (DRCW) Do Not Disturb (DND) Emergency Call Routing Enhanced Secondary DN (ESDN) Essential Line (ELN)
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes n/a Yes Yes Yes Yes Yes
Yes No No No No No No No No No No No Yes No No Yes Yes No No No No Yes No No No
Yes n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a Yes n/a n/a n/a Yes n/a n/a n/a n/a Yes n/a n/a n/a
Provision treatment as announcement or backward release with cause
Configure music on hold using announcement, instead of audible ringback
Provision treatment as announcement or backward release with cause
Nortel Networks
PROPRIETARY
Page
524
Service or option Group Intercom Hong Kong 999 & Malicious Call Hold Hong Kong Call Forwarding Prevention Hong Kong Calling Number Delivery Enhancements Japan Automatic Recall Japan Denied Malicious Call Termination (DMCT) Japan Dialable Directory Number (DDN) Japan MALO/MALT (Malicious Call Trace for Origination & Termination) Japan Time-of-Day Broadcast Service (ACD Groups) Last Number Redial (LNR) Lawful Intercept Interaction with IN Line Overflow to DN (LOD) Line Overflow to Route (LOR) Line Reversal on Answer (LROA) Local Number Portability, non-IN MADN Multiple Call Arrangement MADN Single Call Arrangement Make Set Busy (MSB) Meet-me Conference (6 pty) Meet-me-Conference (30 pty) Message Waiting Indicator - Audible (MWT, STD sub-option only) Message Waiting Indicator - Visual Multi Line Hunting (MLH) Multicarrier (CARR) Music on Hold Networked CNAM via QFT / Wide Area Centrex Networked Centrex (customer groups dispersed over multiple CS2000s) Notification of Payment Ceiling Permanent Hold (HLD) Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? n/a Yes Yes Yes Yes n/a Yes n/a Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No No No No No No No No No No No No No No No No No No No No No No No n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a Use announcement on media server as audio source Details (including restrictions and comments)
Page
525
Nortel Networks
PROPRIETARY
Service or option Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes # No No No No Yes # No No No Yes # Yes n/a n/a n/a n/a Yes n/a n/a n/a Yes Provision treatment as announcement or backward release with cause Provision treatment as announcement or backward release with cause Provision treatment as announcement or backward release with cause Provision treatment as announcement or backward release with cause Details (including restrictions and comments) Provision treatment as announcement or backward release with cause
Plug Up (PLP) Preferential Hunting (PRF) Preset Conference Priority Class of Service (PCOS), Germany only Private Numbering Plan (PNP) Requested Suspend Service (RSUS) Ring Again (RAG) Secondary DN / Teen Service (SDN) Secondary Language (SL) Selective Call Acceptance (SCA)
Selective Call Forward (SCF)
Yes
Yes #
Yes
Selective Call Rejection (SCRJ) Simultaneous Ring (SIMRING) Speed Calling, User Group List (SCU) Speed Calling, Individual Long List (SCL) Speed Calling, Individual Short List (SCS) Spontaneous Call Waiting with Identification (SCWID) Station Controlled Conference (30 party) Station Controlled Conference (6 party) Sub Community Routing for Emergency Calls Subscriber Activated Call Barring (SACB) Suspend/Resume (SUS/RES) Universal Call Distribution (UCD)
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Yes # No No No No No No No No No No No
Yes n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a
Nortel Networks
PROPRIETARY
Page
526
Service or option Voice Band Data (Group 3 Fax and Modem) Wake-Up Call Request (WUCR) Warm Line (WML) Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? Yes Yes Yes No No No n/a n/a n/a Details (including restrictions and comments)
Table 48: DPT interaction support for ACD base services

Service or option Abandon Call Clearing ACD Call Transfer with time ACD specific Music on Delay Automatic Not Ready & Overflow Call Delay Annc Call Forcing Call queue slots Delay & Force Announcements Incoming Call queue Night service (recorded announcement and forwarding) Multiple Queue Status display Night Service Overflow of enqueued calls to a DN Priority promotion and overflow Queue to make set busy Ring Threshold Second and Third Delay announcements Time Delay & Basic overflow Variable wrap up Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? n/a Yes Yes Yes Yes Yes n/a Yes Yes Yes n/a n/a Yes Yes Yes Yes Yes Yes n/a No No No No No No No No Yes No No No No No No No No No No n/a n/a n/a n/a n/a n/a n/a n/a Yes n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a) Provision treatment as announcement or backward release with cause Use announcement on media server as audio source, not audible ringback Use announcement on media server as audio source, not audible ringback Details (including restrictions and comments)
Page
527
Nortel Networks
PROPRIETARY
Table 49: DPT interaction support for ACD agent services

Service or option ACD Not Ready (Key for EBS and Set Not Ready for analog) ACD Not Ready non-immediate cut off option AEMK Answer Emergency Key Agent Login Agent Queue Agent Status lamp & indicators Agent Status Lamp (ASL) Answer Agent key Call Agent key Call Park by ACD agent Call Source identification Call Supervisor key Called Name/Number Display Camp-on calls to in-calls Control of Night Service Key (NGTSRVCE) Controlled Interflow Display Agent Status (DASK) Display agents & queue status summary Display Queue Status (DQS) Display Queue Threshold (DQT) Emergency key Emergency key backup Enhanced Agent Login Forced Agent Availability Key (FAA) Forced Night Service In-Calls key Line of business code key NR on SDN Yes n/a n/a n/a n/a Yes n/a n/a n/a Yes n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? n/a n/a n/a No No No No Yes No No No No Yes No No No Yes No No No No No No No No No No No No No No n/a n/a n/a n/a Yes n/a n/a n/a n/a Yes n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a Use announcement on media server as audio source, not audible ringback Use announcement on media server as audio source, not audible ringback Use announcement on media server as audio source, not audible ringback Details (including restrictions and comments)
Nortel Networks
PROPRIETARY
Page
528
Table 49: DPT interaction support for ACD agent services

Service or option Observe agent Observe from analogue handset Observe Warning Tone Observer Agent Restriction Secondary DNs Supervisor option SUPR UCD UCD Login Keys Walkaway closed key Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? n/a n/a n/a n/a n/a n/a n/a n/a n/a No No No No No No No No No n/a n/a n/a n/a n/a n/a n/a n/a n/a Details (including restrictions and comments)
Table 50: DPT interaction support for regulatory servicess

Service description Carrier Selection Emergency Call Routing Lawful Intercept Local Number Portability, non-IN Malicious Call Hold (MCH) Supported Bearer over SIP-T DPT bearer interaction / with interaction workaround SIP-T available? Yes Yes Yes Yes Yes No No No No No n/a n/a n/a n/a n/a Details (including restrictions and comments)
Page
529
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
530
Chapter F2 Analogue Subscriber Line Services
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.
Page
531
Nortel Networks
PROPRIETARY
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).
Nortel Networks
PROPRIETARY
Page
532
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. 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. Last Number Redial Allows a subscriber to redial the last number dialled by entering an access code instead of the full number . Speed Calling, Individual Short List Single-digit speed calling to <10 numbers on short list defined by user. Speed Calling, Individual Long List Two-digit speed calling to <70 numbers on long list defined by user. Speed Calling, User Group List Two-digit speed calling to <70 numbers on shared long list defined by group controller. Group Intercom Provides Group Intercom capabilities to support abbreviated extension dialling within customer group.
WML
LNR
SCS SCL SCU
GIC
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. 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.
CFF
Page
533
Nortel Networks
PROPRIETARY
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. 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).
CFD
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. 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. 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.
CFCW
CFRA
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.
Nortel Networks
PROPRIETARY
Page
534
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. 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. 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. 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. 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. 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. 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. 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. 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.
SCWID
CCW
CHD
HLD
CXR
3WC
SCC6
CPU
Page
535
Nortel Networks
PROPRIETARY
DCPU PRK
Directed Call Pickup Incoming call can be answered by any station in call pickup group. 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). Directed Call Park Allows a subscriber to park a call against another DN for later retrieval.
DPCK
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). 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. 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.
MLH
PRH
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.
Nortel Networks
PROPRIETARY
Page
536
F2.2.7
F2.2.7.1
Automatic Call Distribution (ACD)

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 longest-queued call to longest-idle agent position to be answered ACD agent positions
Incoming calls
ACD group supervisor can listen in on calls to monitor call handling
Incoming calls added to call queue when no agent is free
Call queue
Agent queue
Agent positions added 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.
Page
537
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
538
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
Option 1:Call queued against original target group
Call queue
Overflow out queue
Overflow in queue
ACD Group B
Option 2:Call immediately overflowed to alternative group
Call queue
Overflow out queue
Overflow in queue
3a
Option 3:Call time-overflowed to another group (remains physically queued against alternative group until agent free)
ACD Group C
Call queue Overflow out queue Overflow in queue
3b
Figure 136: Queues used by an ACD supergroup
Page
539
Nortel Networks
PROPRIETARY
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.
! !
Nortel Networks
PROPRIETARY
Page
540
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.
Page
541
Nortel Networks
PROPRIETARY
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 MWI Message Waiting Message Waiting Indication The mechanism used to notify the subscriber is referred to as
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.
Nortel Networks
PROPRIETARY
Page
542
F2.2.9
F2.2.9.1
Party Information Services

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. 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. 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. 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.
CND
CNAMD
SCWID
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).
543
Nortel Networks
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.
Reverse translator name from table CUSTNTWK Calling number Use next RESULT in list
Table DNREVXLA
RXLANAME FROMDIGS TODIGS RESULTS: List of up to 20 consisting of: REGION DELDIGS PRFXDIGS OPTRFX
Table DNREGION
REGION FROMDIGS TODIGS
Yes Is there another RESULT on list of RESULTS? No Calling Number unchanged No Calling number within a REGION digit range? Yes Called number within same region? Yes Use DELDIGS, PRFXDIGS, and OPTPRFX to format CLI into diallable form for called party
No
Figure 137: Overview of reverse translations

Nortel Networks
544
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. For information about CS2000 compliance with ETSI CLASS requirements for party information services, see the CLASS Modem Interface SIM Specification (NIS 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
Page
545
Nortel Networks
PROPRIETARY
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 SCA SCF SLE Selective Call Rejection (the screening list determines whether an incoming call is accepted or rejected; calls from numbers on the list are rejected). Selective Call Acceptance (the screening list determines whether an incoming call is accepted or rejected; calls from numbers on the list are accepted). Selective Call Forward (the screening list determines whether an incoming call is accepted or forwarded). 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.
Nortel Networks
PROPRIETARY
Page
546
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. 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. 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. Ring Again Notification provided to caller when busy called party becomes free. 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.
AR
ARDDN
RAG ACB
Page
547
Nortel Networks
PROPRIETARY
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). 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. 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. 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). 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. Automatic Collect Call Blocking Prevents ACC calls being made to a subscriber line.
ELN
PCA
CS
ACC
ACCB
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).
Nortel Networks
PROPRIETARY
Page
548
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. 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. 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. Secondary Language 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. 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. 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.
ESDN
WUCR
SL
ABR
COD
Page
549
Nortel Networks
PROPRIETARY
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 ILR (International Line Restriction) ICWT (International Call Waiting) IBN equivalent Functionality provided by Code Restrictions (NCOS screening) and Subscriber-Activated Call Barring (SACB). CWT
I3WC (International Three Way Call, including 3WC Consultation Hold) ICT (International Call Transfer) IWUC (International Wake-Up Call CDTA (Call Diversion To Announcement) CXR WUCR 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.
Nortel Networks
PROPRIETARY
Page
550
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 CFF (Call Forward Fixed) CFBP (Call Forward Busy Programmable) CFBF (Call Forward Busy Fixed) CFDP (Call Forward Dont Answer Programmable) CFDF (Call Forward Dont Answer Fixed) IBN equivalent (as specified in IBNLINES) CFF CFB with P (programmable) option CFB with F (fixed) option CFD with P (programmable) option CFD with F (fixed) option
CFU (Call Forward Universal Programmable) CFU
SUPPRESS (permanent suppression of party SUPPRESS information) CFRA (Call Forward Remote Activation) CND (Calling Number Delivery CNDB (Calling Number Delivery Blocking) CNDBO (Calling Number Delivery Blocking Override) SCWID (Spontaneous Call Waiting with Identification) ACRJ (Anonymous Call Rejection) CFRA
CND
CNDB CNDBO SCWID 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.
Page
551
Nortel Networks
PROPRIETARY
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).
! !
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, 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 Call Barring and Restrictions DOR (Denied Origination) DTM (Denied Termination) DCF (Deny Call Forwarding) PLP (Plug Up) SUS/RES (Suspend / Resume) RSUS (Requested Suspension) NCOS (Network Class Of Service Screening) aka Code Restrictions MSB (Make Set Busy) DND (Do Not Disturb) SACB (Subscriber Activated Call Barring) MG9K MTA / cable CPE LAN V5.2 PSTN
IBN CEPT IBN CEPT IBN CEPT IBN CEPT Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No Yes Yes
[1]
Yes Yes Yes Yes Yes Yes Yes Yes
Yes Yes
No Yes Yes
[1]
Yes Yes Yes Yes Yes Yes Yes Yes
Yes Yes No No Yes Yes

[1]
Yes Yes Yes Yes Yes Yes
Yes Yes No No Yes Yes

[1]
Yes No Yes Yes [2] [2] [2] Yes No Yes No Yes No Yes No [2]
Nortel Networks
PROPRIETARY
Page
552
Table 51: Service availability for different types of analogue line

Availability with line type Service Speed Calling Services AUL (Automatic Line) WML (Warm Line) LNR (Last Number Redial) SCS (Speed Calling, Individual Short List) SCL (Speed Calling, Individual Long List) SCU (Speed Calling, User Group List) GIC (Group Intercom) Call Forward Services CFU (Call Forward Unconditional), inc. CFI CFF (Call Forward Fixed) CFB (Call Forward on Busy), inc. CBI CFD (Call Forward on Doesnt Answer), aka CFNA / CFNR, inc. CDI CFWANN (Call Forward with Announcement) CFWVAL (Call Forward with Validation) CFDVT (CFD Variable Timing) CFCW (Call Forward of Call Waiting Calls) CFRA (Call Forward Remote Activation) [6] Call Handling CWT (Call Waiting) SCWID (Spontaneous Call Waiting with Identification) CCW (Cancel Call Waiting) CHD (Call Hold) HLD (Permanent Hold) CXR (Call Transfer) 3WC (Three-Way Call) CNF (Station-Controlled Conference, 3 ports) SCC6 (Station-Controlled Conference, 6 ports) CPU (Call Pick Up) DCPU (Directed Call Pick Up) PRK (Call Park) DPCK (Directed Call Park) SIMRING (Simultaneous Ringing) Hunt Groups DNH (Directory Number Hunting) CIR (Circular Hunting within DNH group) PRH (Preferential Hunting within DNH group) DLH (Directory Line Hunting) MLH (Multi-Line Hunting) MG9K MTA / cable CPE LAN V5.2 PSTN
IBN CEPT IBN CEPT IBN CEPT IBN CEPT Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No No [3] Yes Yes Yes Yes No Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No [3] Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes No [3] Yes Yes Yes Yes No Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No [3] Yes Yes Yes Yes Yes
[4]
Yes Yes Yes Yes Yes

[4]
Yes Yes Yes Yes No
Yes No Yes Yes Yes No [5] Yes Yes
Yes No [7] Yes No [7] Yes No [7] Yes No [7] Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No [3] No [3] No [8] No [9] Yes Yes Yes Yes Yes Yes Yes Yes No [3] No [3] No [8] No [9] No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Yes Yes Yes No [3] No No [3] No [3] No No [3] No [8] Yes No [8] No [9] Yes No [9] No No No Yes Yes Yes Yes Yes Yes No [3] No No [3] No [3] No No [3] No No No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
No Yes Yes Yes No [3] No [3] No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes
Page
553
Nortel Networks
PROPRIETARY

Availability with line type Service LOD (Line Overflow to DN for hunt group) LOR (Line Overflow to Route for hunt group) BNN (Bridged Night Number for DLH group) Multiple Appearance Directory Number MADN SCA (Single Call Arrangement) MADN SCA (Single Call Arrangement) Call Distribution UCD (Uniform Call Distribution) ACD (Automatic Call Distribution) Voice Mail MWT (Message Waiting) with Stuttered Dial Tone (SDT) MWT (Message Waiting) with CLASS Message Waiting Indication (CMWI) Party Information Services DDN (Delivery of Diallable Number) CND (Calling Number Delivery) CNAMD (Calling Name Delivery) CNDB (Calling Number Delivery Blocking) CNAB (Calling Name Blocking) SUPPRESS (permanent suppression of party information) CNDBO (Calling Number Delivery Blocking Override) Screening Services ACRJ (Anonymous Call Rejection) SCRJ (Selective Call Rejection) SCA (Selective Call Acceptance) SCF (Selective Call Forward) SLE (Screening List Editing) [10] Call Completion / Call Return CCBS (Call Completion to Busy Subscriber) CLASS AR (Automatic Recall / Call Return) CLASS ARDDN (Automatic Recall of Diallable Directory Number) RAG (Ring Again) CLASS ACB (Automatic Call Back) Regulatory Services CLF (Calling Line Flash for MCID) ELN (Essential Line) PCA (Payment Ceiling Advice) MG9K Yes Yes Yes Yes Yes Yes Yes Yes No No MTA / cable Yes Yes Yes Yes Yes Yes CPE LAN Yes Yes Yes Yes Yes Yes Yes Yes No No V5.2 PSTN Yes Yes Yes No No No Yes Yes Yes No No No [3] No [3] Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes No Yes Yes
[11]
IBN CEPT IBN CEPT IBN CEPT IBN CEPT
No No [3] Yes No [3] No No [3] Yes No [3] No [3] Yes No [3] Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes
[11]
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes No Yes
Yes Yes
[11]
Yes Yes Yes Yes Yes Yes
Yes Yes
[11]
Yes No
[12]
Yes
[12]
Yes
[12]
Yes
[12]
No
No
No
Yes Yes Yes Yes Yes
Yes Yes
Yes Yes
Yes Yes
Nortel Networks
PROPRIETARY
Page
554

Availability with line type Service CS (Carrier Selection) ACC (Automatic Collect Call) ACCB (Automatic Collect Call Blocking) Miscellaneous Services SDN (Secondary Directory Number), aka Teen Service ESDN (Enhanced SDN) WUCR (Wake-Up Call Request) SL (Secondary Language) ABR (Announcement Before Routing) COD (Cut-Off On Disconnect) CEPT services ILR International Line Restriction) ICWT (International Call Waiting) I3WC (International Three Way Call, including Consultation Hold) ICT (International Call Transfer) IWUC (International Wake-Up Call CDTA (Call Diversion To Announcement)
[1] [2] [3] [4] [5] [6]
MG9K Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No No No Yes No Yes Yes Yes Yes Yes Yes
MTA / cable Yes
CPE LAN
V5.2 PSTN
IBN CEPT IBN CEPT IBN CEPT IBN CEPT Yes Yes Yes Yes Yes Yes Yes No No No No Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No No No Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No No No Yes No Yes Yes Yes Yes Yes Yes
Used instead of CDND (CEPT Do Not Disturb), which is not supported. ILR (International Line Restrictions) is used instead for CEPT lines. Deliberately not supported for CEPT lines. Supported only for intra-CS2000 calls. Only one CFWANN announcement can be provisioned per CS2000. No need for separate service, as CFCW functionality is built in to CEPT Call Forward services. 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.
Page
555
Nortel Networks
PROPRIETARY
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
Order code ILIN0002 ILIN0003 ILIN0004 ILIN0005 ILIN0006 ILIN0009 SACD0002 SACD0006 Name / description Standard Line Features CLASS Line Features Enhanced Line Features Network Line Features Voice Mail Support Regulatory Line Features ACD Base Features ACD Agent Features
Nortel Networks
PROPRIETARY
Page
556
Page
557
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
558
Chapter F3 Feature Support for CentrexIP Clients
F3.2
F3.2.1
Feature Assignment and Activation for CentrexIP Clients

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: I2001 i2001 Etherset I2002 i2001 Etherset I2004 i2001 Etherset M6350 m6350 soft client 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.
Page
559
Nortel Networks
PROPRIETARY
F3.3
Features and Options Supported

Table 53: Features available to CentrexIP lines
Acronym 3WC ACB ACCB ACD ACD - AAK ACD - ACDNR ACD - AEMK ACD - ASL ACD - CAG ACD - CIF ACD - CLSUP ACD - DASK ACD - DQS ACD - DQT ACD - ECM / ICM ACD - EMK ACD - FAA ACD - LOB ACD - NGTSRVCE ACD - OBS ACD - SUPR ACRJ AMATEST AMSGDENY AR ARDDN ARLNA ATC AUD AUL AUTODISP AVT BLF BNN CBE CBI CBU CCBS CCW CDC CDE CDI CDU CFB Feature or option name Three-Way Calling Automatic Call Back Automatic Collect Call Barring Automatic Call Distribution Answer Agent Key Automatic Call Distribution Not Ready Answer Emergency Key Agent Status Lamp Call Agent Controlled Interflow Call Supervisor Display Agent Status Display Queue Status Display Queue Threshold Extended Call Management Emergency Key Forced Agent Availability Line of Business Night Service Observe Agent Supervisor Anonymous Caller Rejection Automatic Message Accounting Test Call Capability Access to Messaging Deny Automatic Recall Automatic Recall Dialable Directory Number Automatic Recall Last Number Announcement Automatic Time and Charges Automatic Dial Automatic Line Automatic Display AUTOVON Termination Busy Lamp Field for Meridian Business Sets Bridged Night Number Call Forwarding Busy Internal Calls Only Call Busy Intragroup or Channel Bus Interface Call Forwarding Busy Unrestricted Call Completion Busy Subscriber Cancel Call Waiting Customer Data Change Exclude External Calls from Call Forwarding Exclude Intragroup Calls from Call Forwarding Call Forwarding Do Not Answer Unrestricted Call Forwarding Busy
Nortel Networks
PROPRIETARY
Page
560

Acronym CFCW CFD CFDVT CFF CFGD CFI CFK CFMDN CFRA CFS CFTB CFTD CFU CFWVAL CID (NTS_CID) CIR CLI CMCF CNDBO CNF COT COTAMA CPU CTD CTW CWD CWI CWO CWR CWT CWX CXR DCBI DCBX DCF DCPK DCPU DCPX DENYISA DID DIN DISA DISP DLH DND DNH DMCT Feature or option name Call Forward Call Waiting Calls Call Forwarding Do Not Answer (Business Sets) Call Forwarding Do Not Answer Variable Timer Call Forwarding Fixed Call Forwarding Do Not Answer for Hunt Group Call Forwarding Intragroup Call Forwarding on a Per Key Basis Call Forwarding MADN Secondary Member Call Forwarding Remote Access Call Forwarding Simultaneous/Screening Call Forward Timed for CFB Call Forward Timed for CFD Call Forwarding Universal Call Forwarding Validation Calling Party Identification Circular Hunt Calling Line Identification Control Multiple Call Forwarding Calling Number Delivery Blocking Override Station Controlled Conference Customer Originated Trace Customer Originated Trace with AMA Call Pickup Carrier Toll Denied Call Transfer Warning Dial Call Waiting Call Waiting Intragroup Call Waiting Originating Call Waiting Ringback Call Waiting Call Waiting Exempt Call Transfer Directed Call Pickup Barge-In Directed Call Pickup Barge-In Exempt Denied Call Forwarding Directed Call Park Directed Call Pickup Directed Call Pickup Exempt Deny In-Session Activation Direct Inward Dialing Denied Incoming Calls Direct System Inward Access Display Distributed Line Hunt Do Not Disturb Directory Number Hunt Deny Malicious Call Termination
Page
561
Nortel Networks
PROPRIETARY

Acronym DNID (NTS_DNID) DOD DOR DRCW DRING DTM EBO EBX ELN Intl Emergency Call EMW EXT FCTDINT FCTDNTER FCTDNTRA FGA FNT FTRGRP FTRKEYS FXR ICSDEACT IECFB IECFD ILB IN (CS-X) INSPECT INTPIC IRR JOIN KSH KSMOH LCDR LI LMOH LRN (INTL LNP) LNR LNRA LOD LOR LPIC LVM MBK MBSCAMP MCH MDN MCA MDN SCA Feature or option name Dialed Number Identification Delivery Direct Outward Dialing Denied Origination Distinctive Ringing/Call Waiting Distinctive Ringing Denied Termination Executive Busy Override Executive Busy Override Exempt Essential Line International Emergency Call Routing Executive Message Waiting Extension Add-On Full Carrier Toll Deny for International Carriers InTER-LATA Full Carrier Toll Denied Intra-LATA Full Carrier Toll Denied Feature Group A Free Number Terminating Feature Group Feature Keys Fast Transfer In Call Service Deactivation Internal/External Call Forwarding Busy Internal/External Call Forwarding Do Not Answer Inhibit Line Busy Intelligent Networks (CS-x) Inspect Key International Primary Carrier Inhibit Ring Reminder Conference Join Key Short Hunt Key Set Music on Hold Local Call Detail Recording Lawful Intercept Line Music on Hold International Local Number Portability Last Number Redial Last Number Redial Associated with Set Line Overflow to DN Line Overflow to Route IntraLATA PIC Leave Message Make Busy Key Meridian Business Set Station Camp-On Malicious Call Hold MADN (Multiple Appearance Directory Number) Multiple Call Arrangement MADN (Multiple Appearance Directory Number) Single Call Arrangement
Nortel Networks
PROPRIETARY
Page
562

Acronym MDNNAME MEETME MEMDISP MLAMP MLH MOT MREL MRF MRFM MSB MSBI MWIDC MWINK MWQRY MWT NAME NOH NTAIT OLS ONI OP PBL PCI PCOS PCWT PDO PF PIC PILOT PLP PNP PORT PPL PREMTBL PRESET CONF PRH PRK PRL PRV QBS QCK QTD RAG RCF/RCFEA RCVD REASDSP RESL Feature or option name MADN Member Name Meet-Me Conference MDN Member Display MDN Lamp Multi-Line Hunt Music on Transfer MDN Release MDN Ring Forwarding MADN Ring Forwarding Manual Make Set Busy Make Set Busy Intragroup Message Waiting Indication MADN Message waiting indicator Message Waiting Query Message Waiting Name Display No Receiver Off-Hook Tone Network Translated Address Indicator Termination Originating Line Select Operator Number Identification Operator Services Access Private Business Line Preselect Carrier Identification Proirity Class of Service Precedence Call Waiting Termination Prevent Delete Option Power Features Primary InterLATA Carrier Pilot DN Billing Plug-Up (Trouble Intercept) Private Numbering Plan 10 digit unconditional LNP trigger PVN Priority Line Call Preemption Preset Conference Preferential Hunting Call Park Privacy Release Privacy for MADN Query Busy Station Quick Conference Key Query Time and Date Ring Again Remote Call Forwarding (Access to) Received Digits Billing Reason Display Restricted Line
Page
563
Nortel Networks
PROPRIETARY

Acronym RPA RSP RSUS SACB SBLF SCA SCF SCI SCL SCMP SCRJ SCS SCU SDSDENY SDY SEC SETMODEL SIMRING SL SLQ SLU SMDI SMDR SOR SORC SPB SPR SSAC SUBCOM SUPPRESS SUS SVCGRP TBO TERM TES TFO TLS TollFree UCD UCDLG VOW VOWDN WAC WC WML WUCR Feature or option name Repeated Alert Restricted Sent Paid Requested Suspension Subscriber Activated Call Blocking Set Based Lamp Field Selective Call Acceptance Selective Call Forwarding Serving Carrier Identification Speed Calling Long Series Completion Selective Call Rejection Speed Calling Short Speed Calling User Special Delivery Service Deny Line Study Security Set Model Simultaneous Ringing Secondary Language Single-line Queuing Subscriber Line Usage Simplified Message Desk Interface Station Message Detail Recording Station Origination Restriction Station Origination Restrictions Controller Special Billing Selective Supression of MDCR/SMDR Station Specific Authorization Codes Subcommunity routing for Emergency Calls Suppress Line Identification Information Suspended Service Service Group Terminating Billing Option Terminating DN Billing Toll Essential Terminating Fault Option Terminating Line Select Tollfree Services Uniform Call Distribution Uniform Call Distribution Login Virtual Office Worker Virtual Office Worker DN Wide Area Centrex Who's Calling Warm Line Wake up call ring timeout
Nortel Networks
PROPRIETARY
Page
564
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.
Nortel Networks
PROPRIETARY
Page
565
Chapter F4 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 Calling Line Identification Presentation (CLIP) Calling Line Identification Restriction (CLIR) Direct Dialling In (DDI) Supported over PRI Y Y 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. Service defined in ETS 300 090 (stage 1) and ETS 300 093 (stage 3). 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. Service defined in ETS 300 062 (stage 1) and ETS 300 064 (stage 3).
Nortel Networks
PROPRIETARY
Page
566
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 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 (MCID) Subaddressing (SUB) User-to-User Signalling (UUS) Call Completion to Busy Subscriber (CCBS) Call Forward Unconditional (CFU) Call Forward on Busy (CFB) Call Forward on No Reply (CFNR) Partial Rerouting (PRR) Explicit Call Transfer (ECT) Supported over PRI Y Y Y Y [1] Y [1] Y Y Y [2] Y Y [3] Y [3] Y [3] Y [4] [5] Y
[1] Presentation Number (PN) can be provided instead of Network Number (NN). [2] UUS Service 1 (implicit and explicit) only. [3] 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. [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.
Page
567
Nortel Networks
PROPRIETARY
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. Service defined in ETS 300 180 (stage 1) and ETS 300 182 (stage 3). 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). Service defined in ETS 300 180 (stage 1) and ETS 300 182 (stage 3). 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. Service defined in ETS 300 136 (stage 1) and ETS 300 138 (stage 3). 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. Service defined in ETS 300 094 (stage 1) and ETS 300 097 (stage 3).
Nortel Networks
PROPRIETARY
Page
568
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. Service defined in ETS 300 095 (stage 1) and ETS 300 098 (stage 3). 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. Service defined in ETS 300 128 (stage 1) and ETS 300 130 (stage 3). 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. Service defined in ETS 300 059 (stage 1) and ETS 300 061 (stage 3). 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. Service defined in ETS 300 284 (stage 1) and ETS 300 286 (stage 3).
Page
569
Nortel Networks
PROPRIETARY
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. Service defined in ETS 300 357 (stage 1) and ETS 300 359 (stage 3). 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. Service defined in ETS 300 200 (stage 1) and ETS 300 207 (stage 3). 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. Service defined in ETS 300 199 (stage 1) and ETS 300 207 (stage 3). " 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. Service defined in ETS 300 201 (stage 1) and ETS 300 207 (stage 3). In all cases, the PI (Presentation Indicator) of the Redirecting Number in the rerouted call setup message should reflect that of the forwarding party.
"
Nortel Networks
PROPRIETARY
Page
570
(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: 1 SETUP from CS2000 to PBX 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.
Page
571
Nortel Networks
PROPRIETARY
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: 1 SETUP from CS2000 to PBX 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 summary1 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
Nortel Networks
PROPRIETARY
Page
572
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. Service defined in ETS 300 367 (stage 1) and ETS 300 369 (stage 3). 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.
Page
573
Nortel Networks
PROPRIETARY
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 Network Advice Of Charge (NAOC) Priority Class Of Service (PCOS) for Germany Emergency Calls Random and Circular Hunting for PRI Supported for PRI Y Y Y 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.
Nortel Networks
PROPRIETARY
Page
574
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 MoU Priority 1 services CLIP CLIR DDI MoU Priority 2 services 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 (MCID) Subaddressing (SUB) 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) [7] [8] Explicit Call Transfer (ECT) Non-ETSI ISDN services Network Advice Of Charge Priority Class Of Service (PCOS) for Germany Emergency Calls Random and Circular Hunting for PRI Yes Yes Yes [1] N/A [1] N/A [1] Yes No No Yes Yes Yes [2] No
Yes [5] Yes [5] Yes
[5]
ETSI ISUP ETSI ISUP IBN7 / V1 V2 ANSI ISUP Yes Yes Yes [1] N/A [1] N/A [1] Yes Yes Yes Yes Yes Yes [2] Yes [3]
Yes [6] Yes [6] Yes
[6]
Yes Yes Yes [1] N/A [1] N/A [1] No No No No Yes Yes No
Yes Yes Yes Yes No
Yes [5] Yes
Yes [6] Yes
No No Yes Yes [1]
Yes Yes Yes Yes [1]
No No No 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. [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] 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.
Page
575
Nortel Networks
PROPRIETARY
F4.6
Order Codes for ISDN Supplementary Services

Table 54: Order codes for ISDN supplementary services software
Order code PRIT0003 PRIT0008 PRIT0006 PBXT0011 NETK0024 COLP/COLR PRI Non-ETSI Services PRI Advice of Charge ISUP Network Advice Of Charge (NAOC) Name / description ETSI PRI MoU 1 & 2 Basic Services
Nortel Networks
PROPRIETARY
Page
576
Chapter F5
F5.1 Overview
QSIG Services
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 Connected Line Identification Presentation (COLP) Connected Line Identification Restriction (COLR) Advice Of Charge (AOC) Call Completion to Busy Subscriber (CCBS) Call Completion on No Reply (CCNR) 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
Nortel Networks
PROPRIETARY
Page
577
Chapter F5 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). 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. Service defined in ETS 300 090 (stage 1) and ETS 300 093 (stage 3).
F5.3
F5.3.1
QSIG Additional Network Features

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.
Nortel Networks
PROPRIETARY
Page
578
F5.4
F5.4.1
VPN Support via QSIG Feature Transparency (QFT)

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).
Page
579
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
580
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
QSIG / IUA / SCTP (call control) H.248 or ASPEN overUDP (media control) Packet network media streams
CS2000
QFT / APM / ISUPv2 / SIP-T (basic call and service control)
PBX
QSIG
Note: Direct QSIG to QSIG interworking occurs only between gateways controlled by the same CS2000
Combined media and signalling gateway (PVG)
GWC
Scenario B:- CS2000 provides virtual incoming gateway PINX functionality for PRI access
Q.931 / IUA / SCTP Combined (call control) media and signalling gateway H.248 or ASPEN overUDP (PVG) (media control)
CS2000
PBX
PRI
GWC
Scenario C:- CS2000 provides virtual originating PINX functionality for V5.2 lines
V5.2 / V5UA / SCTP (call control) H.248 / UDP (media control)
CS2000
AN
V5.2
Combined media and signalling gateway (PVG)
GWC
Scenario D:- CS2000 provides virtual originating PINX functionality for analogue lines
CS2000
Analogue subscriber lines (in-band signalling)
Line media Combined call and gateway media control: (cable or " NCS (cable) customer " MGCP (LAN) LAN)
GWC
Figure 138: QFT support for different access configurations
Page
581
Nortel Networks
PROPRIETARY
F5.5
F5.5.1
ISDN Supplementary Services

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. Service defined in ETS 300 094 (stage 1) and ETS 300 097 (stage 3). 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. Service defined in ETS 300 095 (stage 1) and ETS 300 098 (stage 3).
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. Service defined in ETS 300 179 (stage 1) and ETS 300 182 (stage 3). 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. Service defined in ETS 300 180 (stage 1) and ETS 300 182 (stage 3).
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.
Nortel Networks
PROPRIETARY
Page
582
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.
Page
583
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
584
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
Order code PBXT0036 VPNW0004 QSIG COLP/COLR QFT over ETSI ISUP Name / description
Page
585
Nortel Networks
PROPRIETARY
Chapter F6
F6.1
F6.1.1
DPNSS Features
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 End node functionality PBX or switch, e.g. CS2000 Non-DPNSS trunk Gateway functionality DPNSS PBX or switch, e.g. CS2000 Transit node functionality DPNSS Lines End node functionality PBX or switch, e.g. CS2000 Non-DPNSS trunk Gateway functionality
Figure 139: Conceptual network role of DPNSS
Nortel Networks
PROPRIETARY
Page
586
Chapter F6 DPNSS Features
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
PBX
DPNSS features
DPNSS
DPNSS
CS2000
PBX
DPNSS 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 features
DPNSS
CS2000
DFT
CS2000
DFT
CS2000
DPNSS
PBX
DPNSS features
Figure 141: Transit node functionality provided by DFT trunks
Page
587
Nortel Networks
PROPRIETARY
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
PBX
DPNSS features
DPNSS
CS2000 DFT looparound
line interface DPNSS features
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.
Nortel Networks
588
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 PBX
DPNSS features DPNSS QSIG I/W Non-DPNSS trunk i/f
Figure 143: DPNSS gateway functionality (provided via QSIG)
Page
589
Nortel Networks
PROPRIETARY
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 section DPNSS Feature CLI Display (AE0839, AE1383, AJ4201) Makes Originating Line Identifier (OLI) available to called 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 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, in accordance with BTNR 188. Rate indicated by Service Indicator Code (SIC) value. Swap (AE0284) Allows transmission requirements of call to be changed (via new SIC) while call is in progress. Call Back When Free (AE0328, AE0440, AG4664, AR1928) Allows user who encounters busy line to have call completed when line becomes free (like Centrex RAG). Executive Intrusion (NC0352, AE1384, AG5061) Enables selected users to intrude on established 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, CFNA/CFD). Differs from Centrex CFx because of 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) Allows party to put other party on hold and do something else (implemented as part of 3PC) Three Party Call (NC0252) Allows a party engaged in a call to set up another call to a 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 of new call (like Centrex DCW). Options for called party are as for CW (called party need not have CW; 3WC is enough to support hook-flash). CS2000 as CS2000 as Transit Node End Node (DPNSS/DFT to (DPNSS/DFT DPNSS/DFT) to line) Y Y
N [1]
8 9 10
N [1] Y Y
N Y N
11
12
13
14
Nortel Networks
PROPRIETARY
Page
590
Table 56: DPNSS feature support on CS2000

BTNR 188 section DPNSS Feature Non-Specified Information Enables DPNSS to convey unspecified information required for the implementation of network-specific features and functions. Service-Independent Strings Enables DPNSS to convey supplementary information strings without affecting the operation of DPNSS basic calls or suplementary services. Call Waiting (AG4586) Notification of new incoming call provided during active call. Bearer Service Selection (AE0284, AF6453) [5] Allows requirement or preference for transmission capability to be specified in ISRM (in addition to SIC). If 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 without affecting the parties involved in the call. This service cannot be used during data calls. For information about the billing of route-optimised calls, see A59017058 and A59022458. Extension Status Offers the capability of determining, on request, the status 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 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 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 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 three party situation to become the controlling party. The 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 operators at times when normal operator positions are unattended. Centralised Operator Allows a single position to provide operator services for multiple PBXs. CS2000 as CS2000 as Transit Node End Node (DPNSS/DFT to (DPNSS/DFT DPNSS/DFT) to line) Y Y [2]
15
16
y [3]
17
y [4]
18
N [6]
19
20
21
22
23
24
25
y [7]
26
y [8]
Page
591
Nortel Networks
PROPRIETARY

BTNR 188 section DPNSS Feature CS2000 as CS2000 as Transit Node End Node (DPNSS/DFT to (DPNSS/DFT DPNSS/DFT) to line) N Y N N
Traffic Channel Maintenance 27 Maintenance functions for a traffic channel on a single DPNSS link between two adjacent PBXs. Remote Alarm Reporting 28 Provides a network with the capability of reporting to a central point alarms raised by any PBX in the network. Add-On Conference Permits the controller of a Three Party Service conference 29 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 PBXs. Call Back When Next Used (CBWNU) to have call 31 Allows user whose call is unansweredis next free after completed when the called extension being used. Do Not Disturb 32 Offers the possibility of giving a busy indication to callers when an extension user wishes not to be disturbed. Remote Registration of Diversion operator to set 33 Allows an extension orextension on one PBXPBX inor cancel diversion at an on another the DPNSS network. Remote Registration of Do Not Disturb 34 Enables operator or privileged extension to invoke or remove the Do Not Disturb condition on extensions. Priority Breakdown of selected extensions who 35 Enables usersbusy to break down existing encounter in congestion or connections order to complete their own calls. Call Back Messaging 36 Allows a caller to indicate to the called party that the calling party wishes to be called back. Loop Avoidance 37 Rejection of calls that transit too many legs. Forced Release 38 Offers an intruding party the possibility of forcing the 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 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 a destination which causes the terminating PBX to be charged for the call, on or after answer.
N [9]
N [10]
Y y [11] Y
N N N
Nortel Networks
PROPRIETARY
Page
592

BTNR 188 section DPNSS Feature Network Address Extension Allows the specification of an address beyond a particular destination within a DPNSS network. This subaddress 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 called party if the called party is busy. It also allows the 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 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 allocated capacity is in use, by making use of additional unallocated capacity, typically at extra cost. Wait on Busy Enables caller who encounters busy to remain connected to PBX until called party becomes free. Call Pick-Up Enables subscriber to answer a call awaiting answer at another extension. Travelling Class of Service Enables subscriber away from usual phone to make use of Class Of Service associated with usual phone. Number Presentation Restriction Enables subscriber to restrict presentation of identity. CS2000 as CS2000 as Transit Node End Node (DPNSS/DFT to (DPNSS/DFT DPNSS/DFT) to line)
41
42
N [12]
43
N [13]
44
45 46 47 48
Y Y Y Y
N N [14] N 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.
Page
593
Nortel Networks
PROPRIETARY
F6.2
F6.2.1
DPNSS Feature Support Mechanisms

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
F6.2.2.1
Support via DPNSS Feature Transparency (DFT)

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 section E2.3.4 on page 395.
Nortel Networks
PROPRIETARY
Page
594
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 The external DPNSS interface presented by a CS2000 network to PBXs is supported on 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: ! 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 conveyed transparently in Westell-defined 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 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.
Page
595
Nortel Networks
PROPRIETARY
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 which feature is active Figure 144: DPNSS/Centrex feature interworking
Centrex features assigned to line
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.
Nortel Networks
PROPRIETARY
Page
596
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 PBXA0004 PBXA0005 PBXA0007 PBXA0009 PBXA0002 PBXA0004 PBXA0005 PBXA0007 PBXA0010 PBXA0014 PBXA0015 PBXA0017 PBXA0018 PBXA0021 VPNW0008 DPNSS Series Call DPNSS Night Service DPNSS route optimisation DPNSS base DPNSS executive intrusion DPNSS series call DPNSS night service DPNSS diversion billing DPNSS diversion billing enhancements DPNSS DDI CLI DPNSS CLI Blocking Route Optimisation - Interaction with Mgmt Reporting BTUP provision of CLI to DPNSS DPNSS feature transparency Description DPNSS executive intrusion
Page
597
Nortel Networks
PROPRIETARY
Chapter F7
F7.1 Overview
APM Feature Transparency
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 Application Transport Parameter (APP) that can be conveyed in the existing ISUP call control messages 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.
Nortel Networks
PROPRIETARY
Page
598
Chapter F7 APM Feature Transparency
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.
Page
599
Nortel Networks
PROPRIETARY
F7.2
F7.2.1
Application Contexts Supported by CS2000

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 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.
F7.2.1.2
CS2000
Centrex features End node functionality
QFT
CS2000
QFT
CS2000
QSIG
PBX
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).
Nortel Networks
PROPRIETARY
Page
600
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 Private Numbering Plan Calling Number Display Functionality Networked intra-group calls using private dial plan [2] Display private CLI on networked call IBN7 Feature(s) [1] NETINFO [3] Calling Number Display Call information Display Connected Number Display Call Pickup Network Name Display Call Information Display Network Name Display Network Name Display Call Pickup Network Name Display Networked MWI Activation
Connected Number Display Display private connected number on answer Calling Name Display Called Name Display Connected Name Display Busy Name Display Display calling name to called party Display name of called party on alerting Display name of connected party on answer Display name of called party when call encounters busy line
Networked Message Waiting Notify subscriber that voice mail Indicator message has been left Network Ring Again (open equivalent is Call Completion to Busy Subscriber) Repeat call automatically set up if first call encounters busy
Network Ring Again
Call Forward
Call Forward Universal [1] Notify called party that call has Call Forward on Busy been forwarded, indicating Call Forward on No Reply reason and displaying both callers number and forwarding Note: Centrex equivalence, partys number. 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).
Page
601
Nortel Networks
PROPRIETARY
Feature
Functionality
IBN7 Feature(s) [1]
Call Transfer
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 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 recalled if call not Note: Centrex equivalence, answered. i.e. attendant access and 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).
Attendant Call Completion (Call Transfer, Camp On, Recall on Timeout)
[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.
Nortel Networks
PROPRIETARY
Page
602
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 3 Service / Feature 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 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 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.
Page
603
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
604
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.
Nortel Networks
PROPRIETARY
Page
605
Chapter F8 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.
PROPRIETARY Page
Nortel Networks
606
Chapter F8 VPN
F8.2
F8.2.1
VPN Telephony Overview

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.
Page
607
Nortel Networks
PROPRIETARY
Chapter F8 VPN
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.
Nortel Networks
PROPRIETARY
Page
608
Chapter F8 VPN
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.
Page
609
Nortel Networks
PROPRIETARY
Chapter F8 VPN
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.
Nortel Networks
PROPRIETARY
Page
610
Chapter F8 VPN
F8.2.4
F8.2.4.1
Flexible Translations and Routing

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.
Page
611
Nortel Networks
PROPRIETARY
Chapter F8 VPN
F8.3
F8.3.1
F8.3.1.1
Protocols Used for VPN

Access Signalling Support
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 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 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
Nortel Networks
PROPRIETARY
Page
612
Chapter F8 VPN
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 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.
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
Page
613
Nortel Networks
PROPRIETARY
Chapter F8 VPN
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.
Nortel Networks
PROPRIETARY
Page
614
Chapter F8 VPN
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 Application Transport Parameter (APP) that can be conveyed in the existing ISUP call control messages 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.
Page
615
Nortel Networks
PROPRIETARY
Chapter F8 VPN
Use of APM with Proprietary Access Interfaces and Services 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 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. Proprietary application contexts, which 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.
Nortel Networks
PROPRIETARY
Page
616
Chapter F8 VPN
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.
Page
617
Nortel Networks
PROPRIETARY
Chapter F8 VPN
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 PBX Originating CS200 ETSI ISUP V2+ signalling for QFT support Terminating CS200 Terminating PBX
ETSI PRI or QSIG signalling
ETSI PRI or QSIG signalling
CdPN in IAM is the result of translations. CgPN in IAM is the result of screening.
SETUP
CdPN = 565123 NPI = private TON = unknown CgPN = 424242 NPI = E.164 TON = national
Terminating CS2000 determines whether originating and terminating PBXs belong to the same business group, i.e. have the same BGID
IAM with APP

CdPN = 7545960000 NPI = private TON = unknown CgPN = 691234242 NPI =E.164 TON = national APP CdPN = 565123 NPI = private TON = unknown CgPN = 424242 NPI = E.164 TON = national BGID = 87654321
SETUP
CdPN = 565123 NPI = private TON = unknown CgPN = 424242 NPI = E.164 TON = national Because originating and terminating BGIDs match, CdPN and CgPN in SETUP are those provided by originating PBX
CdPN and CgPN in APP are those provided by the PBX
BGID is obtained from CS2000 datafill
CALL PROCEEDING ACM with APP CALL PROCEEDING

APP APP with no user info sent to indicate support for VPN FT
ALERTING CONNECT
CPG ANM
ALERTING CONNECT
Figure 146: ETSI ISUP V2+ support for VPN private numbering
Nortel Networks
PROPRIETARY
Page
618
Chapter F8 VPN
F8.3.2.2 NETINFO
Semi-Proprietary Support: IBN7 ISUP
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).
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. 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. 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). The external DPNSS interface presented by a CS2000 network to PBXs is supported on 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: ! 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 conveyed transparently in Westell-defined 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.
619
Nortel Networks
Chapter F8 VPN
Because H.225 and QSIG are both based on Q.931, H.225 messages can be mapped 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.
Nortel Networks
PROPRIETARY
Page
620
Chapter F8 VPN
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
Backbone networks
ETSI ISUP V2+ with AC=124 (Nortel) Can convey customer group and NCOS via NETINFO [1] parameter conveyed via AppID=3 Interworking supported Full Centrex support ETSI ISUP V2+ with only AC=1 (QFT/PSS1) Can convey customer group (but not NCOS) via BGID [1] parameter Interworking supported Selected Centrex features supported Interworking supported Selected Centrex features supported Interworking supported IBN7 ISUP Can convey customer group and NCOS via NETINFO parameter in call setup messages Interworking supported Full Centrex support
Access interfaces
IBN line (analogue, V5.2 PSTN)
Customer group and NCOS from datafill
CentrexIP client
Interworking supported Full Centrex support
Interworking supported Full Centrex support Interworking supported Some supp. services supported Interworking supported Some supp. services supported QFT not supported Interworking supported
PRI
Interworking supported
Supp. services supported Supp. services supported
Interworking supported QSIG Customer group and NCOS from datafill
Interworking supported
Supp. services supported Supp. services supported QFT supported QFT supported
DPNSS
Interworking not supported
Interworking not supported
Supplementary services supported DFT supported
CLI-based indirect access Customer group and NCOS determined by table DNSCRN Authcode access Indirect access via Customer group and ETSI ISUP, NCOS determined by table BTUP, AUTHCDE FTUP Calling card access via MCCS (EISUP V2 only) Customer group and NCOS determined by table TCNFAST
Interworking supported NETINFO correctly generated Interworking not supported
Interworking supported NETINFO correctly generated
[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.
Page
621
Nortel Networks
PROPRIETARY
Chapter F8 VPN
F8.4
F8.4.1
Interaction with MCS5200 to Support VPN

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. MCS5200 delivers multimedia servers for SIP clients, including client managers who act 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.
Nortel Networks
PROPRIETARY
Page
622
Chapter F8 VPN
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
Order code VPNW0002 VPNW0003 VPNW0004 Name / description VPN over ETSI ISUP VPN over IBN7 ISUP QFT over ETSI ISUP
Page
623
Nortel Networks
PROPRIETARY
Chapter F9
F9.1 Overview
Voice Mail
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.
Nortel Networks
PROPRIETARY
Page
624
Chapter F9 Voice Mail
Stage 1:- Leaving a message CS2000

1 Incoming
call Bearer paths
Message desk interface Message desk

Voice ports
Recording device
Speech path through-connected; caller leaves 3 message
2
No answer or busy; call forwarded to voice mail
Line termination
Link termination
Voice mail datalink
Link termination
Voice mail subscriber
5
Message waiting indicator (e.g. stuttered dial tone) is activated
Message desk sends message waiting ON notification to line
Stage 2:- Retrieving a message CS2000

Bearer paths
Message desk interface Message desk

Voice ports
Recording device
8 Speech path
through-connected; message played to subscriber Subscriber 6 interacts with switch to request message retrieval Voice mail subscriber Line termination
7 Retrieval message
sent to message desk Link termination Link termination
Voice mail datalink
9
Message waiting indicator is 10 deactivated Message desk sends message waiting OFF notification to line
Figure 147: Functional overview of voice mail
Page
625
Nortel Networks
PROPRIETARY
F9.2
F9.2.1
Voice Mail Interfaces

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.
Nortel Networks
PROPRIETARY
Page
626
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
Order code ILIN0006 Name / description Voice Mail Support
Page
627
Nortel Networks
PROPRIETARY
Chapter F10
F10.1 Overview
Conferencing
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.
Nortel Networks
PROPRIETARY
Page
628
Chapter F10 Conferencing
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
Trunk / line GWCs Audio Controller (AC) GWC
H.248 commands, e.g. Add, controlling terminations and contexts (calls) Responses
Media gateways supporting: Trunks Lines
Media server 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.
Page
629
Nortel Networks
PROPRIETARY
Chapter F10 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
Order code ILIN0005 Name / description Network Line Features
Nortel Networks
PROPRIETARY
Page
630
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.
Nortel Networks
PROPRIETARY
Page
631
Chapter F11 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 Default network, e.g. PTT Call routed to B only if requested Transit switch Terminating switch
Call origination
Call termination
Requested ingress with authorisation checks
Default ingress, typically for calls terminating within network B Network B Alternative national operator using IP or ATM packet backbone Media gateway Media gateway
Egress for calls terminating to network A lines
Ingress CS2000 checks authorisation
Egress or terminating CS2000
CS2000
CS2000
Call origination
Media gateway
Media gateway
Call 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.
Nortel Networks
PROPRIETARY
Page
632
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.
"
Page
633
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
634
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.
Access method Singlestage CLIbased acces s Carrier selection screening Account code required MONA via ambiguous translations Authcode access Table used Initial CLI information checked? provided Yes Access code + destination number Carrier ID + destination number Access code 2nd tone ? No Further information provided N/A Main advantage Speed / convenience for voice calls; support for data calls Speed / convenience for voice calls; support for data calls Account code billing for business customers Confirmation of access to alternative network Support for roaming access; more powerful screening
DNSCRN
DNSCRN
Yes
No
N/A Account code + destination number Destination number [1] Authorisation code + destination number [2]
DNSCRN
Yes
Yes
DNSCRN
Yes
Access code
Yes
AUTHCDE
No
Access code
Yes
[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.
Page
635
Nortel Networks
PROPRIETARY
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).
Nortel Networks
PROPRIETARY
Page
636
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 further information. 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.
637
Nortel Networks
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).
Nortel Networks
PROPRIETARY
Page
638
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 " 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 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).
Page
639
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
640
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.
Page
641
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
642
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.
Page
643
Nortel Networks
PROPRIETARY
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 (TDM-based)
Subscriber goes off-hook PSTN dial tone Called Party Number (CdPN) comprising Access Code (AC) and destination digits Note: One IAM Originating shown for simplicity. switch Could be IAM followed by SAM(s). IAM (CdPN = AC + dest. digits) ACM ANM
AO network (packet-based) Ingress CS2000

Onward signalling is en-bloc IAM (AC discarded from CdPN) DPT GWCs and SS ACM ANM ISUP messages encapsulated in SIP-T
Network path through-connected
Ingress media gateway
Optional TBOA Call in progress
Figure 150: Single-stage CLI-based access over TDM-side ETSI ISUP ingress trunk
Nortel Networks
PROPRIETARY
Access GWC
USP or FLPP
Page
644
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.
Page
645
Nortel Networks
PROPRIETARY
Default network (TDM-based) Subscriber goes off-hook PSTN dial tone Subscriber dials Access Code (AC) Originating switch Note: One IAM shown for simplicity. Could be IAM followed by SAM(s). IAM (CdPN = AC) Early ACM Early ANM
AO network (packet-based)
Ingress CS2000
USP or FLPP
Network path through-connected Information provided in-band: Account code (CCC) Called Party Address
Access GWC
DPT GWCs and Session Server
Onward signalling is en-bloc IAM (real CdPN) ACM ANM ISUP messages encapsulated in SIP-T
Optional TBOA
Call in progress
Figure 151: Account code required access over TDM-side ETSI ISUP ingress trunk
Nortel Networks
PROPRIETARY
Page
646
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.
Page
647
Nortel Networks
PROPRIETARY
Default network (TDM-based) Subscriber goes off-hook PSTN dial tone Subscriber dials Access Code (AC) Originating switch Note: One IAM shown for simplicity. Could be IAM followed by SAM(s). IAM (CdPN = AC) Early ACM Early ANM
AO network (packet-based)
Ingress CS2000
USP or FLPP
MONA activated
Network path through-connected Information provided in-band: Called Party Number (other information may also be collected)
DPT GWCs and SS
Access GWC
Optional TBOA
Call in progress
Figure 152: CLI-based MONA access over TDM-side ETSI ISUP ingress trunk
Nortel Networks
PROPRIETARY
Page
648
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.
Default network (TDM-based) Subscriber goes off-hook PSTN dial tone Subscriber dials Access Code (AC) Originating switch Note: One IAM shown for simplicity. Could be IAM followed by SAM(s). IAM (CdPN = AC) Early ACM Early ANM AO network (packet-based)
Ingress CS2000
USP or FLPP
MONA activated
Network path through-connected
Authcode prompt (secondary dial tone) Authorisation information provided in-band: Authorisation code Optional Personal Identification Number (PIN) Optional Customer Cost Centre (CCC) code Called Party Number Access GWC
DPT GWCs and Session Server
Optional TBOA
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).
Page
649
Nortel Networks
PROPRIETARY
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.
Nortel Networks
650
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 subscriber network Selected carrier network NAOC tariff database Terminating subscriber network
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
Order code ILIN0009 IXLS0007 CLDN0004 CLDN0003 ILIN0005 IIND0004 Name / description Regulatory Line Features (includes Carrier Pre-Selection) ETSI ISUP V2 Carrier Selection and Preselection CLI Screening Via Translations PBX CLI Management Network Line Features (includes Authcode Access) Tone Burst on Answer for Indirect Access
Page
651
Nortel Networks
PROPRIETARY
Chapter F12
F12.1 Introduction
IN Services
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.
Nortel Networks
PROPRIETARY
Page
652
Chapter F12 IN Services
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.
Page
653
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
654
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.
Page
655
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
656
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. 3WC ACB ACD ACDNR ACRJ AIN AINDN AR ARDDN AUL CBE CBU CCBS CDE CDI CDU CFB CFD CFDA CFDVT CFF CFI CFIND CFK CFNR Feature Name Three-Way Calling Automatic Call Back Automatic Call Distribution Automatic Call Distribution Not Ready Anonymous Caller Rejection Advanced Intelligent Network Advanced Intelligent Network DN A59039605 Automatic Recall Automatic Recall of Diallable Directory Number Automatic Line Call Forwarding Busy Internal Calls Only Call Forwarding Busy Unrestricted Call Completion to Busy Subscriber Exclude External Calls from Call Forwarding Exclude Intragroup Calls from Call Forwarding Call Forwarding Do Not Answer Unrestricted Call Forwarding Busy Call Forwarding Do Not Answer (Business Sets) Call Forwarding Do Not Answer (Residential) Call Forwarding Do Not Answer Variable Timer Call Forwarding Fi Call Forwarding Intragroup Call Forward Indication Call Forwarding on a Per Key Basis Call Forwarding No Reply A59033609 Any IN dialogue associated with the original call A59038655 attempt is automatically cleared, which means that the return call attempt can trigger as an IN call A59014056 A59033609 A59033609 A59038655 If the original call attempt triggered as an IN call, the repeat call will also trigger A59033609 A59033609 A59033609 TDP2 not supported on any forwarded calls A59033609 TDP2 not supported on any forwarded calls A59033609 TDP2 not supported on any forwarded calls A59033609 A59033609 A59033609 A59033609 TDP2 not supported on any forwarded calls A59033609 A59033609 A59033609 Comprises CFD and OFCENG parameter A59023666 Post Answer EDPs are not supported A59023666 Post Answer EDPs are not supported FN Ref Notes / Restrictions
TDP2 not supported on third leg of 3WC.Three A59033609 parties cannot be in conference and have IN active.
Page
657
Nortel Networks
PROPRIETARY
Table 63: IN Feature Interactions

Abb. CFRA CFS CFTANN CFTB CFTD CFU CFU CHD CLI CMCF CNAMD CND CNDB CNF CPS CPU CUSTMOD CWT CXR DCF DDN DGT DISA DLH DNH HLD HOLD IECFB IECFD LI LNR MCH Feature Name Call Forwarding Remote Access Call Forwarding Simultaneous/Screening Call Forward to Announcement Call Forward Timed for CFB Call Forward Timed for CFD Call Forwarding Unconditional Call Forwarding Universal Call Hold Calling Line Identification Control Multiple Call Forwarding Calling Name Delivery Calling Number Delivery FN Ref A59033609 A59033609 A59033609 A59033609 A59033609 A59033609 TDP2 not supported A59033609 TDP2 not supported Feature activation supported for non-IN call, but A59038655 not permitted for existing IN-controlled call A59010596 A59033609 A59010596 A59010596 New leg added to existing non-IN call can trigger 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. Notes / Restrictions
Calling Number Delivery Blocking A59010596 Six-Port Conference Carrier Pre-Selection Call Pickup Reverse translations via CUSTMOD Call Waiting Call Transfer Denied Call Forwarding Dialable Directory Number Digitone Direct Inward System Access Distributed Line Hunt Directory Number Hunt Permanent Hold ETSI Call HOLD Internal/External Call Forwarding A59033609 TDP2 not supported for Call Forward leg Busy Internal/External Call Forwarding A59033609 TDP2 not supported for Call Forward leg Do Not Answer Lawful Intercept Last Number Redial Malicious Call Hold Although IN call must be completed before LNR A59010596 works, if a call triggers and then is hung up, previous number is used A59010596 A59010596 A59010596 Reverse translations can be invoked within digit A00003467 analysis phase of call IN Dialogue aborted when call wait is activated A59033609 IN feature cannot co-exist with three parties all in conference A59033609
Nortel Networks
PROPRIETARY
Page
658
Table 63: IN Feature Interactions

Abb. MCT MLH MMC MSB MSBI MSG DEACT MWIDC MWT NCOS PCOS PRK QTD RAG SC1 SC2 SC3 SCA SCF SCI SCL SCRJ SCS SDN SIMRING UCD UCDLG UCDLI WML Feature Name Malicious Call Trace Multiline Hunt Meet-Me Conference Make Set Busy Make Set Busy Intragroup Message Deactivation Message Waiting Indication Message Waiting Code Restrictions / Call Barring Priority Class Of Service Call Park Query Time and Date Ring Again Speed Calling Short List Speed Calling Long List L30 Speed Calling Long List L50 Selective Call Acceptance Selective Call Forwarding Serving Carrier ID Speed Calling Long Selective Call Rejection Speed Calling Short Secondary Directory Number Simultaneous Ringing Uniform Call Distribution Uniform Call Distribution Login Uniform Call Distribution Login Indication Warm Line A59014056 A59010596 A59010596 A59010596 Enhanced SDN (ESDN) not supported 59027838 A59023666 Post Answer EDPs not supported A59023666 Post Answer EDPs not supported A59023666 Post Answer EDPs not supported A59014056 A59033609 If TDP2 is used & MDC < access code, call A59014056 triggers instead of activating feature A59014056 A59014056 A59014056 A59014056 Tested for PRI only A59010596 A59010596 A59038655 Feature activation supported for non-IN call, but not permitted for existing IN-controlled call FN Ref Notes / Restrictions
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.
Page
659
Nortel Networks
PROPRIETARY
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
Nortel Networks
PROPRIETARY
Page
660
Chapter F13 Party Information Services
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).
Page
661
Nortel Networks
PROPRIETARY
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)
PROPRIETARY Page
Nortel Networks
662
Party information may be categorised as: A W Available 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
Page
663
Nortel Networks
PROPRIETARY
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
! ! ! !
Nortel Networks
PROPRIETARY
Page
664
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 1470 1471 Per-call CLI blocking for numbers that are available by default Per-call unblocking for numbers that are suppressed by default Call return service (anouncement gives last calling number and allows a return call to be initiated by means of a single recall digit)
Page
665
Nortel Networks
PROPRIETARY
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 switch
Incoming call
Terminating switch
Call termination
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.
Nortel Networks
PROPRIETARY
Page
666
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 " Type of information # 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.
Page
667
Nortel Networks
PROPRIETARY
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 switch
Incoming call
Terminating switch
Call termination
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 " 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
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 " Type of information # 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.
Nortel Networks
668
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 switch Redirecting switch Terminating switch
Origination
Fwd/Xfer
Termination
Info about caller
Info about redirecting party and new called party
Info about caller and 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.
Page
669
Nortel Networks
PROPRIETARY
F13.4 Parameters for Conveying Party Information

F13.4.1 ISUP
F13.4.1.1 Generic Capabilities Calling Party Number parameter format is:
Bit Octet 8 Odd/even ind. NI ind. Numbering plan ind. 2nd address signal Filler (if necessary) 7 6 5 4 3 2 1
1 2 3 n
Nature of address ind. Presentation ind. Screening ind.
1st address signal 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 International number Unknown (relay only) 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. Presentation allowed Presentation restricted Address not available (not in EISUP V1, relay only in IBN7) 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)
NPI
PI
SI
Nortel Networks
PROPRIETARY
Page
670
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 Octet 8 7 6 5 4 3 2 1
1 2 3 4 n
Odd/even ind. NI ind.
Number qualifier indicator (NQI) Nature of address ind. Numbering plan ind. 2nd address signal Filler (if necessary) Presentation ind. Screening ind.
1st address signal nth address signal
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 Octet 8 7 6 5 4 3 2 1
1 2 3 n NEI
Name element indicator (NEI) Name element length Name information IA5 / ASCII characters, 1 per octet
Calling party name Connected party name Redirecting party name (first base station)
Page
671
Nortel Networks
PROPRIETARY
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): ! 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 (ATM) 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, 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, 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 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. 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 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.
Nortel Networks
PROPRIETARY
Page
672
DPNSS Feature Transparency (IBN7 Encapsulation) 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). 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)
Page
673
Nortel Networks
PROPRIETARY
F13.4.2 TUP
F13.4.2.1 BTUP / IUP Line identity parameter format is:
Bit Octet 8 7 6 5 4 3 2 1
1 2 n
Number of address signals 2nd address signal Filler (if necessary)
D IQ
Message indicators C B A IA ind. NOA ind. 1st address signal nth address signal
Message indicators are: NOA (Nature Of Address) National significant number International number (Incomplete Address) Complete address Incomplete address (Identity Qualifier) Line identity may be released for display Line identity may not be released for display
IA
IQ
Type of line identity, e.g. calling / last diverting, is indicated elsewhere in the conveying message.
Nortel Networks
PROPRIETARY
Page
674
Party information functionality for BTUP is also affected by some fields of the IAM/IFAM Message Indicators parameter, which has the following format:
Bit Octet 8 Reserved H Prot. ind. 7 EDI G MDG 6 5 4 3 2 1
1 2 3 4 5
Calling Party Category (CPC) Message indicators F E D Reserved PA ind. I/W ind. C Int. ind. B CBI A CLI ind.
Message indicators I to L Interconnect-Specific Information (ISI) PNI Call Path Indicator
Service Handling Protocol (SHP) Message indicators M to P Routing Control Indicator
The relevant fields are: CLI CBI Calling Line Identity included Calling Line Identity not included (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. (Presentation Number Indicator) Presentation Number available (can be requested via ACI) Presentation Number not included
PNI
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) 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)
NDS
Page
675
Nortel Networks
PROPRIETARY
F13.4.3 ISDN
F13.4.3.1 Direct Support for Party Information Calling Party Number IE format is:
Bit Octet 8 Ext. ind. Ext. ind. 7 6 Type of number Presentation ind. 5 4 3 2 1
1 2 3 n
Numbering plan identification Spare Screening ind.
Number information IA5 / ASCII characters, 1 per octet
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 International number Network-specific number (e.g. operator) Unknown E.164 Private Unknown Presentation allowed Presentation restricted Address not available Network provided User provided, verified and passed User provided, not verified
NPI
PI
SI
Note: French ISDN (Numeris) allows two calling party numbers to be conveyed in a SETUP message.
Nortel Networks
PROPRIETARY
Page
676
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.
Page
677
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
678
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.
Page
679
Nortel Networks
PROPRIETARY
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. For information about CS2000 compliance with ETSI CLASS requirements for party information services, see the CLASS Modem Interface SIM Specification (NIS S118-1).
Nortel Networks
PROPRIETARY
Page
680
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.
Reverse translator name from table CUSTNTWK Calling number Use next RESULT in list
Table DNREVXLA
RXLANAME FROMDIGS TODIGS RESULTS: List of up to 20 consisting of: REGION DELDIGS PRFXDIGS OPTRFX
Table DNREGION
REGION FROMDIGS TODIGS
Yes Is there another RESULT on list of RESULTS? No Calling Number unchanged No Calling number within a REGION digit range? Yes Called number in same region? Yes Use DELDIGS, PRFXDIGS, and OPTPRFX to format CLI into diallable form for called party
No
Figure 158: Overview of reverse translations
Page
681
Nortel Networks
PROPRIETARY
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)
" " " " "
Nortel Networks
PROPRIETARY
Page
682
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
Page
683
Nortel Networks
PROPRIETARY
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)
Nortel Networks
PROPRIETARY
Page
684
! ! ! ! !
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.
685
Nortel Networks
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 Calling Line Identity (CLI) Redirecting number (RDN) Charge number (CHARGE) Contractor number (CONTRACTOR) Generic number (GENERIC_NO) Presentation Number (PN)
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.
Nortel Networks
PROPRIETARY
Page
686
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
IBN7 ISUP t8 EISUP V1 t6 EISUP V2 t7 UK ISUP t9 IBN line t1 DPNSS t5 BTUP t10 Y Y N Y y Y Y Y Y N Originating agent FTUP t11 y Y N N N N Y N N Y QSIG t4 Y Y Y N y Y Y N N Y ACD t2 Y Y N Y y Y Y Y Y N Terminating agent
IBN line o1 ISDN PRI o2 QSIG o3 DPNSS o4 ETSI ISUP V1 o5 ETSI ISUP V2 o6 IBN7 ISUP o7 UK ISUP o8 IUP / BTUP o9 SSUTR2 / FTUP o10
Y Y Y y y Y Y Y Y y
PRI t3 Y Y Y Y y Y Y Y Y Y
y Y N y y Y Y N Y N
y y y y y y y y y y
Y Y Y Y y Y Y Y Y Y
Y Y Y Y y Y Y Y Y Y
Y Y N Y y Y Y Y Y N
Legend
Provision of = NN and/or PN fully supported
Provision of party = information partly supported (NN, not PN)
No support = for CLI provision
Page
687
Nortel Networks
PROPRIETARY
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 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). Providing caller information: 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. 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). Displaying connected party information: 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. Providing caller information: As for PRI originating agent (see note o2). Displaying connected party information: As for PRI originating agent (see note o2).
o1
IBN line
o2
ISDN PRI
o3
QSIG
Nortel Networks
PROPRIETARY
Page
688

Providing caller information: 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 for display or suppressed. If the release/suppress status is a default rather than a permanent DPNSS 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. Displaying connected party information: 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. ETSI ISUP V1 Parameters available for conveying party information in backward direction: Connected Number. See section F13.4.1.1 on page 670 for parameter format. Parameters available for conveying party information in forward direction: Calling Party Number (optional, but always provided if available), Original Called Number, Redirecting Number. See section F13.4.1.1 on page 670 for parameter format. Generic Number parameter containing Additional Calling Party Number is used to convey PN if available. See section F13.4.1.2 on page 671 for parameter format. 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). Parameters available for conveying party information in backward direction: Connected Number, Redirection Number. See section F13.4.1.1 on page 670 for parameter format.
o4
o5
o6
Page
689
Nortel Networks
PROPRIETARY

Parameters available for conveying party information in forward direction: Calling Party Number (optional, but always provided if available), Original Called 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. See section F13.4.1.1 on page 670 for parameter format. Generic Number parameter containing Additional Calling Party Number is used to convey PN if available. See section F13.4.1.2 on page 671 for parameter format. 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. Parameters available for conveying party information in backward direction: Connected Number, Redirection Number. See section F13.4.1.1 on page 670 for parameter format. 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. Parameters available for conveying party information in forward direction: Calling Party Number (optional, but always provided if available), Original Called Number, Redirecting Number. See section F13.4.1.1 on page 670 for parameter format. Also Presentation Number, Last Diverting Line Identity, Partial Calling Line Identity (see section o8 UK ISUP F13.4.1.5). Parameters available for conveying party information in backward direction: Connected Number, Redirection Number. See section F13.4.1.1 on page 670 for parameter format. Parameters available for conveying party information in forward direction: Line Identity. See section F13.4.2.1 on page 674 for parameter format. 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, i.e. it identifies the exchange rather than the party, but the DEFLTCLI option can be used to o9 IUP / BTUP 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. Displaying connected party information: Line Identity. See section F13.4.2.1 on page 674 for parameter format. 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. See section F13.4.2.2 on page 675 for parameter format. Displaying connected party information: No mechanism available for conveying party information in backward direction.
Nortel Networks
PROPRIETARY
Page
690
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. Providing caller information for display: As for IBN line terminating agent (see note t1). Providing connected party information: 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. Providing caller information for display: 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 datafill-controlled mapping of CLI PI (Presentation Indicator). See A59040499. t3 ISDN PRI Note: French PRI (Numeris VN4) allows both NDI (NN) and NDS (PN) to be provided. Providing connected party information: 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. Providing caller information for display: As for PRI terminating agent (see note t3). t4 QSIG Providing connected party information: As for PRI terminating agent (see note t3). Providing caller information for display: 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, it will be the PN if one is available or the NN otherwise. t5 DPNSS Providing connected party information: 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. As described in note o8 in Table 65. t9 UK ISUP 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 IBN line to DPNSS Capabilities
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 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.
PRI to ISUP
Page
691
Nortel Networks
PROPRIETARY
Table 67: Support for party information over specific interworkings

Interworking Capabilities
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 AG5046 for details. PRI to BTUP 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. I/W to FTUP: ETSI ISUP to FTUP ETSI ISUP international call; no CLI information in resulting MIF Treated as 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

Interworking General Incoming call to IBN line is redirected Capabilities
Support for information about redirecting and redirection parties when call is forwarded depends 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 Information and Redirection Number parameters. 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.
Nortel Networks
PROPRIETARY
Page
692
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. The chapter is organised into the following sections: ! ! ! ! ! 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.
Nortel Networks
PROPRIETARY
Page
693
Chapter F14 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).
Nortel Networks
694
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.
! ! ! !
Page
695
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
696
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.
Page
697
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
698
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

Media gateway Monitored call GWC
CS2000
Media server Other party

Media gateway Call content (voice or data)
GWC Call processing Call-related data (CS2000 Core) GWC CDC FTAM / FTP initiator (on SDM) Callrelated data LI service logic (on SDM)
GWC LEA media gateway ETSI ISUP V2 (or national equivalent)
LI service initiates monitoring of packet network bearer connection and sets up TDM call towards LEA to relay intercepted call content
Logical Call Content Channel (CCC) comprising either one physical CC link or two (one per direction)
X.25 / IP
PSTN/ISDN
Links to LEA site (PRI, BRI or analogue)
Transit networks
PSPDN
X.25 / IP FTAM / FTP responder
X.31
Law Enforcement Agency (LEA)
Recorders
Figure 159: Network configuration used to support Lawful Interception
Page
699
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
700
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 (Centrex or CEPT) [1]
Monitoring supported for calls to / from Can be specified for Lawful Interception
PRI
ETSI ISUP V2
ETSI ISUP V1
SIP-T
IBN line (Centrex or CEPT) [1] PRI access
Yes Yes
Yes Yes
Yes 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.
Page
701
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
702
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.
Page
703
Nortel Networks
PROPRIETARY
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).
Nortel Networks
PROPRIETARY
Page
704
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.
Page
705
Nortel Networks
PROPRIETARY
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.
Nortel Networks
706
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 call leg
Database query
Onward routing
Outgoing 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.
Page
707
Nortel Networks
PROPRIETARY
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 routing
Outgoing call leg
Table PNSCRN Ported DN NIC in/out
Table PNINFO NIC XLA Options
Figure 161: CS2000 implementation of the number portability service
Nortel Networks
PROPRIETARY
Page
708
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.
Page
709
Nortel Networks
PROPRIETARY
" "
"
" "
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.
Nortel Networks
PROPRIETARY
Page
710
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
Order code ILIN0009 INLI0002 NETK0019 NETK0024 NETK0028 IXLS0007 IXLS0002 NSUP0016 NSUP0017 NSUP0020 Name / description Regulatory Line Features International Lawful Interception Network Advice of Charge Network AOC Tariff CGP Network AOC ETSI ISUP V2 Carrier Selection and Preselection Service Number Portability and Number Portability Provisioning CCBS SCCP Support for Local Number Portability Payment Ceiling Advice (PCA) NAOC / PCA Enhancements
Page
711
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
712
Chapter F15 Multimedia Services for Blended Users
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.
Page
713
Nortel Networks
PROPRIETARY
Figure 162 illustrates the logical configuration used by CS2000 to give blended users access to multimedia services.
CS2000
Call processing GWC for trunk media gateway GWC for line media gateway DPT GWC SIP Application Module
MCS5200
RTP Media Portal (media proxy)
SIP PRI gateway
PRI SIP-T
Backbone packet network

Signalling to/from MCS5200 (SIP) Multimedia streams to/from MCS5200 Voice bearer connection across backbone network PVG PRI Access network Note: In ISN07, SIP-T signalling between CS2000 and MCS5200 is not involved in supporting multimedia services for blended users. Call setup between CS2000 and MCS5200 uses PRI. Platform for RAIDer client can be directly connected to gateway or connected independently (e.g. to customer LAN)
Gateway
Access to multimedia services via RAIDer client window Blended user
Figure 162: Blended user configuration
Nortel Networks
PROPRIETARY
Page
714
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 2 Blended user A goes off-hook and dials blended user Bs number (normal call setup) 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. 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 Blended user B uses RAIDer window to initiate multimedia session with MCS5200 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.
4 5
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 Whiteboard sharing Clipboard transfer Instant messaging
Page
715
Nortel Networks
PROPRIETARY
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 2 Non-blended user A goes off-hook and dials blended user Bs number (normal call setup) 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. 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 Blended user B uses RAIDer window to initiate multimedia session with MCS5200
4 ! !
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 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.
Nortel Networks
PROPRIETARY
Page
716
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 2 Blended user A goes off-hook and dials non-blended user Bs number (normal call setup) CS2000 call processing identifies DN of called party B (assumed to be on same CS2000 as A for simplicity). CS2000 then: " Applies ringing to 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 As RAIDer client. 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 As screen. 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 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.
Page
717
Nortel Networks
PROPRIETARY
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 Whiteboard sharing
Clipboard transfer " 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.
Nortel Networks
PROPRIETARY
Page
718
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.
Nortel Networks
PROPRIETARY
Page
719
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. 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 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.
Nortel Networks
PROPRIETARY
Page
720
Chapter F17 RAS (Remote Access Service)
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 Packet network control signalling TDM bearer channels Packet network bearer connections
CS2000
Call processing CCS7 Signalling Gateway (SG) Access GWC for gateway; Ingress TDM-side
RADIUS server
PSTN CCS7 signalling (IUP / ISUP)
CVX Policy Manager (CPM)
GWC-gateway signalling (DSM-CC) RAS authentication
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 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).
Page
721
Nortel Networks
PROPRIETARY
Chapter F17 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.
Nortel Networks
PROPRIETARY
Page
722
Part G Network Fit
Part G Network Fit
Chapter G1 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.
Nortel Networks
PROPRIETARY
Page
724
Part G Network Fit
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 Digits 1-3 1-7 0-7 1-8 2 < 14 3 < 15 Element Country code National dialling code Office code Station code National Significant Number. International number North American number format Element Country code Area code Office code Extendsion number National number International number Digits 1-3 3 3 4 10 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.
Page
725
Nortel Networks
PROPRIETARY
Part G Network Fit
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.
Nortel Networks
PROPRIETARY
Page
726
Part G Network Fit
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 ISUP ACIF G.500 I-ISUP IUP / BTUP PRI QSIG (en-bloc signalling) QSIG (overlap signalling) Maximum inpulsed digits Maximum outpulsed digits 30 30
[1]
30 30 [1] 24 [2] 29 29 20
24 [2] 30 30 29
[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.
Page
727
Nortel Networks
PROPRIETARY
Part G Network Fit
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)
Service Call Barring and Restrictions DOR (Denied Origination) DTM (Denied Termination) PLP (Plug Up) SUS/RES (Suspend / Resume) RSUS (Requested Suspension) NCOS (Network Class Of Service Screening) MSB/DND (Make Set Busy / Do Not Disturb) SACB (Subscriber Activated Call Barring) DMCT (Deny Malicious Call Termination) Speed Calling Services AUL (Automatic Line) WML (Warm Line) LNR (Last Number Redial) SCS (Speed Calling, Individual Short List) SCL (Speed Calling, Individual Long List) Call Forward Services CFU (Call Forward Unconditional) CFB (Call Forward on Busy) CFD (Call Forward on Doesnt Answer), CFWANN (Call Forward with Announcement) CFWVAL (Call Forward with Validation) CFDVT (CFD Variable Timing) CFCW (Call Forward of Call Waiting Calls) Call Handling CWT (Call Waiting) CCW (Cancel Call Waiting) CHD (Call Hold) Y Y Y Includes Call Waiting Conference (CWTC) Y Y Y Y Y Y Y Y Y Y Y Y Max. 18 digits Max. 18 digits Y Y Y Y Y Y Y Y Y Compatible with ODP? Notes
Nortel Networks
PROPRIETARY
Page
728
Part G Network Fit
Table 70: Service compatibility with an Open Dial Plan (ODP)

Service CXR (Call Transfer) 3WC (Three-Way Call) 3WC Chaining CPU (Call Pick Up) PRK (Call Park) Hunt Groups DNH (Directory Number Hunting) CIR (Circular Hunting for DNH group) PRH (Preferential Hunting within DNH group) DLH (Directory Line Hunting) MLH (Multi-Line Hunting) LOD (Line Overflow to DN for hunt group) LOR (Line Overflow to Route for hunt group) BNN (Bridged Night Number for DLH group) Call Distribution UCD (Uniform Call Distribution) Voice Mail MWI (Message Waiting Indicator) Stuttered dial tone for analogue lines Party Information Services CLASS DDN (Delivery of Diallable Number) CLASS CND (Calling Number Delivery) CLASS CNAMD (Calling Name Delivery) CLASS CNDB (Calling Number Delivery Blocking) CLASS CNAB (Calling Name Blocking) CLASS SUPPRESS (number/name confidentiality) Screening Services ACRJ (Anonymous Call Rejection) SCRJ (Selective Call Rejection) SCA (Selective Call Acceptance) SCF (Selective Call Forward) Call Completion / Call Return ISDN CCBS (Call Completion to Busy Subscriber) CLASS AR (Automatic Recall / Call Return) CLASS ARDDN (Automatic Recall of Diallable Directory Number) Y Y Y AR can be assigned to lines with DNs 2-15 digits in length; CLIs to be called back can have up to 18 digits. See A59038837. Y N N N Y Y Y Y Y CND must be suppressed Max. 24 digits [1] Max. 10 digits [1] Y ODP compatible for line-to-line calls. N Y Y Y Y Y Y Y Y Max. 23 digits Compatible with ODP? Y Y Y Y Y Includes Consultation Hold Max. 27 digits Notes
Page
729
Nortel Networks
PROPRIETARY
Part G Network Fit
Table 70: Service compatibility with an Open Dial Plan (ODP)

Service Regulatory Services Centrex CLF (Calling Line Flash for MCID) ELN (Essential Line) CS (Carrier Selection) LNP (Local Number Portability) Network Services DID (Direct Inward Dialling) DOD (Direct Outward Dialling) DISA (Direct Inward System Access) Miscellaneous Services SDN (Secondary Directory Number) WUCR (Wake-Up Call Request) CEPT services ICWT (International Call Waiting) I3WC (International Three Way Call, including Consultation Hold) CFU (Call Forward Universal) CFB (Call Forward Busy) CFD (Call Forward on Doesnt Answer) CFRA (Call Forward Remote Access) CCBS (call Completion to Busy Subscriber) MWI (Message Waiting Indication) SCWID (Spontaneous CW with Identification)
[1] Limit imposed by service logic, not ODP-related.
Compatible with ODP? Y Y Y Y Y Y Y
Notes
CIC plus 30-digit DN
DISA number plus 30-digit DN See A59034400
Y Y Y Y Y Y Y Y Y Y Y
Max. 18 digits Max. 18 digits Max. 18 digits
G1.1.7
Order Codes for Open Dial Plan Support

Table 71: Order codes for ODP software
Order code NPE00001 NPE00002 NPE00003 NPE00004 Name / description Number Plan Evolution 1 Number Plan Evolution 2 E.164 NPE Enhanced Multiple NPA Support
Nortel Networks
PROPRIETARY
Page
730
Part G Network Fit
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.
Page
731
Nortel Networks
PROPRIETARY
Part G Network Fit
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 / attendant
Operator / attendant
Originating node (PBX or Centrex node)
Originating node (PBX or Centrex node)
Extension on same node and with same location code
Extension on same node and with same location code
Dials PSTN access code, e.g. 9
Dials Dials Dials VPN operator extension access assistance only, e.g. code, code, e.g. 4567 e.g. 6 0
Identified by extension only, e.g. 4567
Identified Identified by VPN by NNG + prefix + LEC + extension extension
VPN extension usually matches last digits of PSTN number (DN) Making calls Receiving calls
Figure 164: Relationship between public and private numbering plans
Nortel Networks
PROPRIETARY
Page
732
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
Nortel Networks
PROPRIETARY
Page
733
Part G Network Fit
Chapter G2 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.
Nortel Networks
PROPRIETARY
Page
734
Part G Network Fit
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.
Page
735
Nortel Networks
PROPRIETARY
Part G Network Fit
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 Call Progress Tones (package ID: cg) Tone Dial Tone Ringing Tone Busy Tone Congestion Tone Special Information Tone Warning Tone Payphone Recognition Tone Call Waiting Tone Caller Waiting Tone Expanded Call Progress Tones (package ID: xcg) Comfort Tone Off-hook Warning Tone Negative Acknowledge Tone Vacant Number Tone Special Conditions Dial Tone Basic Services Tones (package ID: srvtn) Recall Dial Tone Confirmation Tone Held Tone Message Waiting Tone
[1] Used to support TBOA (Tone Burst On Answer) for indirect access.
Tone ID dt rt bt ct sit wt [1] pt cw cr cmft roh nack vac spec rdt conf ht mwt
Nortel Networks
PROPRIETARY
Page
736
Part G Network Fit
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.
Page
737
Nortel Networks
PROPRIETARY
Part G Network Fit
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.
Nortel Networks
PROPRIETARY
Page
738
Part G Network Fit
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 Tone Generator Package Basic DTMF Generator Package Call Progress Tones Expanded Call Progress Tones Basic Services Tones Expanded Services Tones Operator Tones Conferencing Tones Expanded Conferencing Tones Diagnostics Tones Carrier Tones Intrusion Tones Business Tones PP7480 and PP15000 PVG support Yes Yes Yes Yes Yes No No No No No No No 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.
Page
739
Nortel Networks
PROPRIETARY
Part G Network Fit
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
Country / market Australia Brazil Chile China Czech Republic France Germany Hong Kong India Ireland Israel Japan Korea Malaysia Mexico Netherlands New Zealand Portugal Romania Russia Singapore Switzerland Turkey UK PVG support Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes MTA support No No No No No No Yes No No No No Yes No No No No No Yes No No No No No No Ambit / Mediatrix support Yes No No No Yes No No No No No Yes Yes No No No No No No No No No No No No Askey support No No No Yes No No No No No No No No No No No No No No No No No No No No
Nortel Networks
PROPRIETARY
Page
740
Part G Network Fit
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.
! !
Page
741
Nortel Networks
PROPRIETARY
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
Nortel Networks
PROPRIETARY
Page
742
Chapter G3 CS2000 Support for Announcements
Part G Network Fit
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.
Page
743
Nortel Networks
PROPRIETARY
Part G Network Fit
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.
Nortel Networks
PROPRIETARY
Page
744
Part G Network Fit
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
Page
745
Nortel Networks
PROPRIETARY
Part G Network Fit
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.
Nortel Networks
PROPRIETARY
Page
746
Part G Network Fit
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.
Page
747
Nortel Networks
PROPRIETARY
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 PToIP VToATM [1] (Packet Trunking (Voice Trunking over IP) over ATM) Backbone network IP CCS7 PRI QSIG (all off PVGs) ATM (AAL2) CCS7 PRI (both off PVGs) IAW (international Access Wireline) IP CCS7 PRI QSIG (all off PVGs) IAC (International Access Cable) IP CCS7 PRI QSIG (all off PVGs) Carrier-Hosted Services (CHS) IP CCS7 PRI QSIG (all off PVGs)
Trunk access
Line access
N/A
N/A
Lines off Lines off cable customer LAN Lines off gateways (IADs) access network customer LAN gateways gateways (IADs) (MTAs) V5.2 lines off PVGs N/A N/A CentrexIP H.323 DPNSS
Enterprise service access
N/A
N/A
[1] VToATM is also referred to as VToAAL2, because it uses AAL2 (ATM Adaptation Layer 2) bearer connections.
Nortel Networks
PROPRIETARY
Page
748
Chapter G4 Network Integration Issues
Part G Network Fit
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
supporting international gateway functionality
CS2000
supporting international transit functionality
CS2000
supporting international gateway functionality
National signalling, e.g. national variant of ETSI ISUP V1/V2 or TUP
National network A
National 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
Order code SGAT0002 SGAT0003 Name / description International CLI Screening Serving Country Code
Page
749
Nortel Networks
PROPRIETARY
Part G Network Fit
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.
Nortel Networks
PROPRIETARY
Page
750
Part G Network Fit
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. 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). 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. The second media gateways acknowledgement of the CRCX returns a media description line for each codec / packetisation rate pair that it can support. 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.
2 3 4 5
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.
Page
751
Nortel Networks
PROPRIETARY
Part G Network Fit
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 Table TRKOPTS IBN translations tables IBNXLA and XLANAME xxCODE tables in universal translations CALLCNTL and Universal Screening tables [1] Screening table DNSCRN [2] Service profile table CLISRVPF [3] To enable codec selection based on Incoming or outgoing trunk group Called party digits Called party digits or called party NOA A variety of parameters CLI or calling party NOA 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.
Nortel Networks
PROPRIETARY
Page
752
Part G Network Fit
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.
Page
753
Nortel Networks
PROPRIETARY
Part G Network Fit
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 possibility of introducing multiple echo cancellers is minimised.
Nortel Networks
PROPRIETARY
Page
754
Part G Network Fit
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.
Page
755
Nortel Networks
PROPRIETARY
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.
Nortel Networks
PROPRIETARY
Page
756
Chapter G5 IP Addressing and Internet Transparency
Part G Network Fit
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 (e.g. carrier network) Public addresses provide externally visible points of contact NAT / NAPT device treats public addresses as a pool of resources to be dynamically assigned and mapped as required Private address domain (e.g. enterprise network)
NAT / NAPT device

Mapping table
Private addresses visible only within private network
At a given moment, only a subset of private network hosts have a link with the 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
Page
757
Nortel Networks
PROPRIETARY
Part G Network Fit
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.
VoIP address domain, including CS LAN and PVGs
Non-IP addressing
PSTN
Middlebox Demilitarised Zone (DMZ), i.e. "public" network for TSP Middlebox Public Internet
Middlebox
Middlebox
Middlebox
Middlebox Enterprise address domain A
Middlebox Enterprise address domain B
Middlebox Enterprise address domain 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.
Nortel Networks
758
Part G Network Fit
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 Private network host Address pr A:a DA pb B:b SA pr A:a SA pb B:b Source address translated
NAT
Binding: prA - pbX
DA pb B:b
SA pb X:x SA pb B:b
DA pr A:a
DA pb X:x
Public network host Address 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 Private network host Address pr A:a DA pr Z:z SA pr A:a SA pr Z:z Both addresses translated
NAT
Binding: prA - pbX prZ - pbB
DA pb B:b
SA pb X:x SA pb B:b
DA pr A:a
DA pb X:x
Public network host Address pb B:b
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.
Page
759
Nortel Networks
PROPRIETARY
Part G Network Fit
G5.4 NAT Traversal

G5.4.1 NAT Traversal for Signalling
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).
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
Nortel Networks
PROPRIETARY
Page
760
Part G Network Fit
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.
Page
761
Nortel Networks
PROPRIETARY
Part G Network Fit
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
Nortel Networks
PROPRIETARY
Page
762
Part G Network Fit
Figure 169 summarises the application of the example addressing strategy.

Typically already present before VoIP network is created; if not, reserve /27 public subnet
OSS & NOC LANs
OAM&P VLAN CS2000 CS LAN Signalling VLAN(s) UAS bearer VLAN
Reserve /26 public subnet Subnet 172.16.0.0/12 with 19-bit mask; subnet each block with 23-bit mask to address each CS LAN
Core network
Distribution network
PVGs
Access network Use 10.0.0.0/8 subnet for line MGs. Use public addresses for subscribers PCs. Use 192.168.0.0 blocks for out-of-band management.
In 10.0.0.0 block. Subnet 15-bit subnet with 21-bit mask. Use one resulting subnet to address all PVGs.
Figure 169: IP addressing example for Succession solutions
Page
763
Nortel Networks
PROPRIETARY
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.
Nortel Networks
764
Chapter G6 CAC (Call Admission Control)
Part G Network Fit
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 network A
Enterprise network B
Link 2 Site A1
Media gateways
Link 6 Link 3 Site B1

Media gateways
Link 7
Site A2 Link 4 Site A3

Media gateways Media gateways
Site B2 Link 8 Site B3

Media gateways Media gateways
Figure 170: Example network topology with LBLs
Page
765
Nortel Networks
PROPRIETARY
Part G Network Fit
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.
Nortel Networks
PROPRIETARY
Page
766
Part G Network Fit
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 A00002512 A00004981 A00003568 Virtual Call Admissions Control (VCAC) on CS2000 VCAC provisioning for the GWC EM VCAC support for CICM GW E911 location support for CICM
G6.3 Order Codes for VCAC

Table 77: Order codes for VPN software
Order code CS2Q0002 Name / description Virtual Call Admission Control (VCAC)
Page
767
Nortel Networks
PROPRIETARY
Part H OAM&P
Chapter H1 Overview of OAM&P for CS2000 Solutions
Part H OAM&P
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)
Page
769
Nortel Networks
PROPRIETARY
Part H OAM&P
H1.1
H1.1.1
Logical OAM&P Architecture

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.
Nortel Networks
PROPRIETARY
Page
770
Part H OAM&P
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.
Page
771
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
Nortel Networks
PROPRIETARY
Page
772
773
Management centre GUI disk OSS applications IEMS
For simplicity, trunk/line provisioning apps are not shown individualy Trunk provisioning and maintenance Line provisioning and maintenance APS provisioning application QoS Collector Application (QCA) Management Data Provider (MDP) Third-party units must be provided with a compatible third-party EM Network Patch Manager (NPM)
Page
Integrated Element Management System (IEMS) provides: Aggregated northbound data streams in standard formats Single access point for browsing and application launching tape printer
IEMS
Billing (SBA)
Event reporting (Logs and OMs)
Management applications
Part H OAM&P
Figure 171: Logical OAM&P architecture for a CS2000 network
Figure 171 provides a logical view of the OAM&P architecture for a CS2000 network.
Nortel Networks
SAM21 Manager GWC Manager PP8600 Device Manager UAS Mgr. APS Mgr. MCS5200 Mgr. CICM EM SAM21 SCs GWCs PP8600 routing switch MS2000 or UAS Audio Provisioning Server (APS) RTP media portal CICM
PROPRIETARY
Element Managers (EMs)
CS2000 Core Manager
STORM Manager
USP Manager
PMDM
MG9000 Mgr.
Thirdparty gateway EMs
STORM (Compact only)
CS2000 Core (also FLPP, if used)
USP (if used)
PVG V5.2 MGs
MG9000 MGs
Thirdparty gateways
Network Elements (NEs)
CS2000 components
Proprietary gateways
Part H OAM&P
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 Networks
PROPRIETARY
Page
774
Part H OAM&P
OSS LAN / OC corporate internet (centralised OAM&P applications) HLM applications PC clients for EMs and management applications
Nortel Remote Access
Contivity 600 secure gateway Secure tunneling
Enterprise servers NOC LAN Untrusted indirect access to NEs via EMs Element Managers (trusted access to Network Elements) Firewall / perimeter network CBM
Sun server
RA to OAM&P VLAN
IEMS / CMT
Sun server
Other EMs/apps Sun server PP8600 DM
RA to CS2000
CS2000 CS LAN
EMS servers EM functionality for 3rd-party media gateways CS LAN (OAM&P VLAN)
Telco router
CS2000 Core
SAM21 SC GWC inc. EM CICM
SS (inc. EM)
USP (inc. EM)
MS2010
CS LAN can comprise multiple signalling VLANs, as illustrated in Figure 8 on page 44; this diagram simplifies the network structure in order to focus on OAM&P access
CS LAN (signalling VLANs) (not needed for VoATM) CS LAN (bearer VLAN)
PP8600 routers
PVG gateways
Line gateways
Figure 172: Physical OAM&P architecture
Page
775
Nortel Networks
PROPRIETARY
Part H OAM&P
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 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.
Nortel Networks
PROPRIETARY
Page
776
Part H OAM&P
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 management applications
HLM applications on enterprise servers NOC LAN IEMS provides one externally visible IP address for access to all EMs OAM&P VLAN
IEMS Non-CMT-resident EMs, e.g. for Session Server, USP, CICM EM EMs and mgmt apps, e.g. GWC EM, SAM21 EM, configuration apps
Core Manager applications
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
Page
777
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
Nortel Networks
PROPRIETARY
Page
778
Part H OAM&P
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) 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. QCA (QoS Collector Application) 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.
Page
779
Nortel Networks
PROPRIETARY
Part H OAM&P
"
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) 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
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.
Nortel Networks
PROPRIETARY
Page
780
Part H OAM&P
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.
! !
Page
781
Nortel Networks
PROPRIETARY
Part H OAM&P
H1.3
H1.3.1
Access to EMs and Management Applications

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 " CS2000 Core Manager " 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 " QCA (QoS Collector Application) " NPM (Network Patch Manager)
Nortel Networks
PROPRIETARY
Page
782
Part H OAM&P
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 IEMS SDM CS2000 Management Tools (GWC EM, UAS EM, node provisioning, trunk provisioning, line provisioning) [2] APS USP Manager Proxy LMM TMM NPM PP8600 Device Manager STORM MG9000 Manager Number of simultaneous users 40 Java clients [1] 22 HTML clients [1] 32 desktops 10 [3] 5 5 4 4 3 1 1 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 SDM APS USP Manager Proxy PP8600 Device Manager STORM MG9000 Manager PMDM and MDP Number of network elements Configurable Several simultaneously, no limit defined Several simultaneously, no limit defined Several, one at a time Several simultaneously, no limit defined 4 Configurable
Page
783
Nortel Networks
PROPRIETARY
Chapter H2
H2.1
Fault Management
Summary of Fault Management Capabilities

IEMS aggregates all EMS/NE fault data for CS2000 Core, STORM, PP8600, USP, SAM21, GWC, MS2000/UAS, MCS5200, CICM, PVG (if PMDM on CS LAN) and MG9000 Format of single consolidated fault feed can be any of: SCC2 NT STD SNMP Custlog
IEMS
IEMS
SNMP (alarms) and Syslog (logs)
PP8600 Device Mgr.
CS2000 Core Mgr. (SDM or CBM)
USP Mgr.
SAM21 Mgr.
GWC Mgr.
UAS Mgr. and APS
MCS 5200 Mgr.
PMDM
MG 9000 Mgr.
3rd-pty gateways must have compatible 3rd-pty EM Fault reporting must be trapped / OFF
SNMP
SNMP
SNMP
SNMP
SNMP
SNMP
PP8600 routers
USP (if used)
SAM21 SCs
GWCs
UAS
RTP media portal
SNMP
ASCII via TCP
ASCII via TCP
CICMs (if used)
PVGs
MG 9000s
3rd-pty gateways
CS2000 components Figure 174: Overview of support for fault management in a CS2000 network
Nortel Networks
PROPRIETARY
GW supplier is responsible for details of communication with NML Page
SNMP
SNMP
SNMP
SNMP
Corba
Corba
Corba
SCC2
SCC2
784
Chapter H2 Fault Management
Part H OAM&P
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 multi-vendor network.
"
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 element From element to EM To present information to IEMS Notes
GWC
SNMP
Corba
In addition to reporting GWC faults, GWCs controlling PVGs provide gateway state reports.
CICM
Direct feed from CICM to IEMS, using SNMP (alarms) and Syslog (logs) In releases prior to ISN06, the SAM21 EM ran on the SDM platform. It is now supported on the same Sun Netra server platform as the GWC EM.
SAM21 SC
SNMP
Corba
USP PP8600 UAS
SNMP SNMP SNMP
SNMP SNMP Corba The UAS runs on the same server as the APS and the GWC and SAM21 EMs.
Page
785
Nortel Networks
PROPRIETARY
Part H OAM&P
Reporting mechanism Network element From element to EM To present information to IEMS SNMP Notes
RTP Media Portal
SNMP PVGs use ASCII over TCP to provide PMDM with the information used to create logs SNMP
PVG
Corba
PVG state changes are also reported via their GWCs.
MG9000 Third-party media gateways
SNMP Third-party gateways must come with a compatible third-party Element Manager. Faults are not reported by CS2000 to the NML on behalf of these gateway types.
Typically SNMP
Vendor-specific
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)
Nortel Networks
PROPRIETARY
Page
786
Part H OAM&P
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
! ! !
Page
787
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
Nortel Networks
788
Part H OAM&P
H2.3
H2.3.1
Fault Reporting via Logs

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

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.
Log Report Format
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.
! !
Page
789
Nortel Networks
PROPRIETARY
Part H OAM&P
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
Nortel Networks
PROPRIETARY
Page
790
Part H OAM&P
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.
Page
791
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
TCP/IP delivery logs Log Formatting Printer delivery

Configuration files
802.3
IEMS
OSS ASCII stream Printer
Format of single consolidated fault feed can be any of: SCC2 NT STD SNMP Custlog
Figure 175: Log delivery mechanism
Nortel Networks
PROPRIETARY
Page
792
Part H OAM&P
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.
Page
793
Nortel Networks
Part H OAM&P
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.
Nortel Networks
PROPRIETARY
Page
794
Chapter H3
H3.1
H3.1.1
Configuration
Summary of Configuration Capabilities

Commissioning
IEMS provides a single access point for browsing the topology of CS2000 configurations and for launching EMs and management applications.
Note: IEMS not involved for carrier-located MGs managed from central site Auto-configuration via DHCP and TFTP when gateway is activated / initialised 3rd-pty gateways Page
IEMS
SNMP ASCII via TCP CS2000 Core Mgr. (SDM or CBM) ASCII via TCP ASCII via TCP SNMP SNMP SNMP Corba Corba Corba
IEMS
SNMP MG 9000 Mgr. MG 9000s SNMP
PP8600 Device Mgr.
USP Mgr.
SAM21 Mgr.
GWC Mgr.
UAS Mgr. and APS
MCS 5200 Mgr.
CICM Mgr.
PMDM
DCOM
SNMP
SNMP
SNMP
SNMP
SNMP
PP8600 routers
USP (if used)
SAM21 SCs
GWCs
UAS
RTP media portal
SNMP
ASCII via TCP
CICMs (if used)
PVGs
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
Nortel Networks
PROPRIETARY
795
Part H OAM&P
Chapter H3 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 Integrated provisioning applications on CMT server Network view database
EM APIs
OSSGate for integrated provisioning

Node provisioning application Trunk provisioning application Line provisioning application V5.2 provisioning application
SNMP
Corba
ASCII via TCP
ASCII via TCP
USP Mgr.
CS2000 Core Mgr. (SDM or CBM) ASCII via TCP CS2000 Core (also FLPP, if used)
GWC Mgr.
PMDM
SNMP
SNMP
ASCII via TCP
USP (if used)
GWCs
PVGs
3rd-pty gateways
CS2000 components
Gateway provisioning is independent; co-ordination with CS2000 Core and GWCs is achieved via endpoint naiming
Figure 177: Trunk provisioning overview

Nortel Networks
796
Part H OAM&P
Figure 178 provides an overview of how line provisioning for service activation is supported in a CS2000 network.
EM APIs
Integrated provisioning applications on CMT server Network view database Auto-configuration via DHCP and TFTP when gateway is activated / initialised 3rd-pty gateways
SERVORD+
XML
OSSGate for integrated provisioning

Node provisioning application Trunk provisioning application Line provisioning application V5.2 provisioning applications
SNMP
Corba
CS2000 Core Mgr. (SDM or CBM) ASCII via TCP
SNMP
ASCII via TCP
ASCII via TCP
GWC Mgr.
CICM Mgr.
MG 9000 Mgr.
PMDM
DCOM
SNMP
CS2000 Core
GWCs
CICMs (if used)
MG 9000s
SNMP
ASCII via TCP
PVGs
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
Page
797
Nortel Networks
PROPRIETARY
Part H OAM&P
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
Nortel Networks
PROPRIETARY
Page
798
Part H OAM&P
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.
Page
799
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
Nortel Networks
PROPRIETARY
Page
800
Part H OAM&P
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. If the mapping between a gateways FQDN and its IP address is static, the real IP 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.
Page
801
Nortel Networks
PROPRIETARY
Part H OAM&P
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 Node provisioning [1] Line provisioning Carrier provisioning Trunk provisioning LMM TMM 10 [2] 30 4 5 10 10 Other applicationsalso active 5 30 4 2 2 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.
Nortel Networks
PROPRIETARY
Page
802
Chapter H4
H4.1
100BaseT Ethernet
Accounting
Summary of Accounting Capabilities

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 SBA on SDM/CBM stores AMA records in files with one of two formats: AMADNS (AMA and SMDR records) DIRP (AMA records only) CS2000 Core Mgr. (SDM or CBM) USP Mgr. SAM21 Mgr. GWC Mgr. End-of-call QoS statistics provided by GWCs to the QoS Collector Application (QCA) can be co-ordinated with billing records
Downstream processing of billing records by OSS
PP8600 Device Mgr.
UAS Mgr. and APS
MCS 5200 Mgr.
CICM Mgr.
PMDM
MG 9000 Mgr.
3rd-pty gateways must have compatible 3rd-pty EM
Core performs all billing using info from other components
AMA and SMDR records (up to 1.2 million per hour) transmitted in near real time from SuperNode Billing Application (SBA) client on Core to SBA server on SDM/CBM
CS2000 components
PP8600 routers CS2000 Core (also FLPP, if used) USP (if used) SAM21 SCs RTP media portal CICMs (if used) MG 9000s 3rd-pty gateways
GWCs
UAS
PVGs
Figure 179: Overview of support for accounting in a CS2000 network
Nortel Networks
PROPRIETARY
Page
803
Part H OAM&P
Chapter H4 Accounting
H4.2
H4.2.1
CS2000 Core Support for Billing

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.
Nortel Networks
PROPRIETARY
Page
804
Part H OAM&P
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.
Page
805
Nortel Networks
PROPRIETARY
Part H OAM&P
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 IDLE SOC option RBIL0013 (30 digit support) Option ON Base structure x0510 Maximum 18 digits No call completion reason Base structure x0513 Maximum 30 digits No call completion reason Option ON Base structure x0511 Maximum 18 digits Call completion reason Base structure x0514 Maximum 30 digits 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.
Nortel Networks
PROPRIETARY
Page
806
Part H OAM&P
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 Record Descriptor Word Hexadecimal Identifier Structure Code [2] Call Type Code [3] Sensor Type Sensor Identification Recording Office Type Recording Office Identification Date Timing Indicator Study Indicator Called Party Off-Hook Service Observed, Traffic Sampled Operator Action Service Feature [3] [4] Significant Digits In Next Field Originating Open Digits 1 [5] [6] Originating Open Digits 2 [5] [6] Originating Charge Information [3] Domestic/International Indicator Significant Digits In Next Field Terminating Open Digits 1 Terminating Open Digits 2
[5]
Field no. Number of BCD characters 000 00 0 1 2 3 4 5 6 7 8 9 10 11 12 55 500 501 504 505 55 502 503 18 19 280 88 543 543 55 33 8 2 6 4 4 8 4 8 6 6 8 2 2 2 4 4 12 10 4 2 4 12 (x0510, x0511, x0512) 16 (x0512, x0513, x0514) 10 (x0510, x0511, x0512) 16 (x0512, x0513, x0514) 8 10 4 4 6 6 4 14
[1]
[7] [8]
[5] [7] [8]
Connect Time Elapsed Time Call completion reason [9] Module Data [10] Originating Preselect Carrier ID [11] Outgoing Preselect Carrier ID [11] Significant Digits in Next Field [11] Overflow Dialled Digits [11]
Page
807
Nortel Networks
PROPRIETARY
Part H OAM&P
Table 81: Fields in AMA Base Record Structure Information Sent Service Digits [11] Originating Serving Carrier ID [11] [12] Terminating Serving Carrier ID [11] [12] Field no. Number of BCD characters 803 544 544 6 6 6
[1]
[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.
Nortel Networks
PROPRIETARY
Page
808
Part H OAM&P
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 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 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 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 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 service data in table SERVINFO. The type 28 module can record up to 15 dialled digits. Contains Basic Service (BS) information for ISDN calls. Appended to the base structure for an IN call if this has been specified by 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. A unique Call Record Sequence Number for the AMA record it is appended to.
008
022
025
026
028 [1] 030 040 [1] 042
Table 82: Modules that can be appended to AMA records
Page
809
Nortel Networks
PROPRIETARY
Part H OAM&P
Module Code
Contents
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 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 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 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 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: 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 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 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. Controlled by option AUTHAMA in table CUSTSMDR.
046
049
070
071
073
098
100
102
Nortel Networks
PROPRIETARY
Page
810
Part H OAM&P
Module Code
103
Contents
Records a customer-dialled account number with up to 14 digits for use in CDAR (Customer-Dialled Account Recording). Activated by AMAOPTS option 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 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 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 capture of redirection reason and redirection number. Controlled by option AMREDIR in CUSTSMDR and by SOC BILL0008. 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 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 Country Digits Module contains the ISDN channel identifier for ISDN call orginations terminating on ISDN. Capability activated by setting option APPEND_ISDN_CKT_ID to ON in table AMAOPTS. 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 contains any required operator-defined data coded as BCD digits (up to 20 bytes / 40 digits). Module contains a three digit Originating Line Information parameter (OLIP). Module holds details of any time changes (initiated by SETDATE or SETTIME) that have taken place during a call. SUSP billing module, which records the feature codes of the features last activated by the call originator and terminator. It is appended to a call when FTRCODE in table AMAOPTS is set to ON.
104
115
116
120
130
164
180 181
199 306 504 509
Page
811
Nortel Networks
PROPRIETARY
Part H OAM&P
Module Code
Contents
Contains the following information about a trunk circuit used in a chargeable call: Trunk CLLI Name in EBCDIC format (32 digits for 16 characters). 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 Type 611 module with context identifier 80006 Carrier Information Type 611 module with context identifier 80008 Additional Partys Category Type 611 module with context identifier 80009 User-to-User Information (UUI) Parms Type 611 module with context identifier 80010 Independent Common Carrier Proprietary Data Group Type 611 module with context identifier 80014 IN Service Information Type 611 module with context identifier 80016 Charge Area Information To record Facility IE counts (in forward and backward directions) for QSIG GFT billing. Type 611 module with context identifier 80026 CLI screening information for screening based on table CLISERV. Type 611 module with context identifier 80027 To capture protocol indicator, Calling Party Category and ISDN Access Indicator information. Type 611 module with context identifier 80030 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). Type 611 module with context identifier 80035 Network-specific call reference for use in correlating billing records for a call. Activated by STORE_CALLREF option of AMAOPTS. See A59023264.
513
611
Nortel Networks
PROPRIETARY
Page
812
Part H OAM&P
Module Code
Contents
Type 611 module with context identifier 80050 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. Type 611 module with context identifier 80058 - 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. Type 611 module with context identifier 80080 To capture a Carrier Identification Code (CIC) for a Carrier Pre-Selection (CPS) call if this is specified via option PCIBILL in tables PCIXLA and PCITRK. See 59012694 for details. Type 611 module with context identifier 9050001 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)
611 (continued)
Page
813
Nortel Networks
PROPRIETARY
Part H OAM&P
Module Code
Contents
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: Type 612 module with context identifier 80003 Independent Common Carrier Proprietary Data Group Type 612 module with context identifier 80007 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). - JI-ISUP Redirection Number (see A59034042). Type 612 module with context identifier 80020 Charge Rate Information Type 612 module with context identifier 80023 Carrier Information with POI Category Type 612 module with context identifier 80033 Dialled digits received from incoming agent Type 612 module with context identifier 80041 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. Type 612 module with context identifier 80051 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).
612
Nortel Networks
PROPRIETARY
Page
814
Part H OAM&P
Module Code
850
Contents
Records a customer-dialled account number with up to 18 digits for use in CDAR (Customer-Dialled Account Recording). Activated by AMAOPTS option 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).
Page
815
Nortel Networks
PROPRIETARY
Part H OAM&P
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 Acronym CFUx CFFx CFDx CFBx Name Call Forward Universal Call Forward Fixed Call Forward on Doesnt Answer Call Forward on Busy Station Controlled Conference Call Transfer 510, 076 006, 026 614, 096 031 611 Billing summary Call Module Structure code appended Description Structure 614 is generated for the activation of these features. Structure code 096 is generated for the deactivation of these features. Module code 611 is appended to these structure codes to indicate exactly which feature is being billed. Module code 509 is appended to the 510 structure code to indicate use of the CNF feature Structure code 076 with call code 026 will be generated whenever a three port conference circuit is accessed. Both CXR and 3WC require a three port conference circuit whenever they are invoked by the subscriber. Structure code 510 with call code 006 will have the module code 611 appended whenever these features are activated or deactivated Structure code 110 with call code 264 is generated during AMA audits or when either feature is removed from the line. Module code 49 is appended when both CND and CNAMD are active on the same line. Structure code 1030 with call code 330 is generated when these features are used [1] Module code 611 is appended for calls initated by AR (see A59039985). Structure code 1030 with call code 330 is generated when the screening lists for these features are modified [1]
CNF CXR
510
006
509
3WC
Three Way Calling
None
SACB WUCR MSB CND
Subscriber Activated Call Blocking Wake Up Service Station Activated Do Not Disturb Calling Number Delivery 110 264 49 510 006 611
CNAMD Calling Name Delivery
CNDB ACB AR SCF SCA SCRJ
Calling Number Delivery Blocking Automatic Callback Automatic Recall Selective Call Forwarding Selective Call Acceptance Selective Call Rejection 1030 330 None 1030 330 None
[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.
Nortel Networks
PROPRIETARY
Page
816
Part H OAM&P
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.
Page
817
Nortel Networks
PROPRIETARY
Part H OAM&P
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
Nortel Networks
818
Part H OAM&P
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 F2368 F2399 G0119 Station Message Detail Recording (SMDR) Separate Output Files for SMDR and AMA Separate SMDR Files per Customer Group 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.
Page
819
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
Nortel Networks
820
Part H OAM&P
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.
Page
821
Nortel Networks
PROPRIETARY
Part H OAM&P
H4.2.7
Order Codes for Accounting Support

Table 83: Order codes for CS2000 accounting support
Order code BILL0001 BILL0002 BILL0003 BILL0004 BILL0006 BILL0007 BILL0008 BILL0009 BILL0010 BILL0012 BILL0013 IBIL0002 IBIL0003 IBIL0004 IBIL0005 IBIL0006 OAMI0006 RBIL0005 RBIL0007 RBIL0008 NSUP0006 SMET0002 Billing Carrier Connect AMA AMA Reject Calls VPN AMA Billing SMDR DE Extension AMA Time to Answer AMA Redirection Information AMA Call Completion Reason AMA Generation Management Reports Bearer Capability Billing for BTUP AMA Support for Numbers with up to 30 Digits Australasia Billing Enhancements VPN AMA Enhancements NOA/NPI Capture in AMA SSUTR2 IC Charge Message Billing CPC AMA Long Call Audit Usage Sensitive Billing NDS Billing - Indirect Subscribers NDS Billing - Direct Subscribers BC Billing for ETSI ISUP Software Metering Name / description
Nortel Networks
PROPRIETARY
Page
822
Part H OAM&P
H4.3
H4.3.1
Core Manager SBA Support for Billing

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: 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
AMA and SMDR records (up to 1.2 million per hour) transmitted in near real time from SuperNode Billing Application (SBA) client on Core to SBA server on SDM/CBM
SBA client
SBA server Core Manager (CBM or SDM)

SBA on SDM/CBM stores AMA records in files with one of two formats: AMADNS (AMA and SMDR records) DIRP (AMA records only)
100BaseT Ethernet
CS2000 Core
AMA subsystem on CS2000 Core performs all billing using info from other components, creating AMA and SMDR records in response to notification of call processing events
DNS files available 5 mins after call completion DIRP files available 30 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.
Page
823
Nortel Networks
PROPRIETARY
Part H OAM&P
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
Nortel Networks
824
Part H OAM&P
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.
Page
825
Nortel Networks
PROPRIETARY
Chapter H5
H5.1
OMs in CSV format via FTP
Performance Management
Summary of Performance Monitoring Capabilities

OMs in TR740/ TR746 format AMA via TCP PMs in SSV format via FTP
XML
QoS Collector Application (QCA)
Aggregated PMs in CSV format via FTP
Consolidated feed in CSV or XML
IEMS
PM Poller running on CMT server PMs in BDF format via FTP
PMs in CSV format via FTP Collector running on same server as Mgr
SNMP, HTML or XML
PMs in .txt format
PMs in CSV format
PP8600 Device Mgr.
CS2000 Core Mgr. (SDM or CBM)
USP Mgr.
GWC Mgr.
SAM21 Mgr.
MCS 5200 Mgr.
PMDM
MG 9000 Mgr.
3rd-pty gateways must have compatible 3rd-pty EM
AMA records
PMs (ASCII via TCP)
on demand SNMP at intervals MG 9000s
SNMP (OMs at intervals and on demand)
OMs (ASCII/TCP)
SNMP (PMs on demand to EM) PMs in SSV format via FTP SNMP (PMs at intervals to poller)
SNMP (OMs at intervals and on demand)
SNMP (PMs only on demand)
PP8600 routers
USP (if used)
GWCs
SAM21 SCs
MS 20x0
RTP media portal
CICMs (if used)
PVGs
3rd-pty gateways
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

Nortel Networks
826
Chapter H5 Performance Management
Part H OAM&P
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.
Page
827
Nortel Networks
PROPRIETARY
Part H OAM&P
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 intermediary SNMP SNMP SNMP SNMP SNMP SNMP SNMP PMs in SSV format via FTP ASCII over TCP Intermediary PM Poller running on same server as GWC EM, SAM21 EM, UAS EM and APS To present information to NML Aggregated PMs in CSV format via FTP
GWC SAM21 UAS CICM MS20x0 PP8600 RTP media portal USP PVG
Direct to IEMS Via PP8600 Device Manager to IEMS Via MCS Manager to IEMS USP EM PMDM PMs in SSV format via FTP PMs in BDF format via FTP PMs in CSV format via FTP Typically SNMP, HTML or XML Consolidated feed from IEMS in CSV or XML
MG9000 Third-party gateways
Stand-alone Performance PMs in CSV format Collector / Formatter via FTP application running on same server as MG9000 Manager SNMP Poller task, e.g. on EM
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.
Nortel Networks
828
Part H OAM&P
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.
Page
829
Nortel Networks
PROPRIETARY
Part H OAM&P
H5.2
H5.2.1
Performance Monitoring via OMs

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
PROPRIETARY Page
Nortel Networks
830
Part H OAM&P
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 NWCCT INCATOT INFAIL NATTMPT PRERTEAB NOVFLATB OUTFAIL CONNECT ANSWER TRU SBU MBU TOTU Meaning / content Number of working circuits Total number of incoming calls Number of incoming calls that failed Total number of outgoing calls attempted Number of outgoing calls abandoned before routing Number of calls overflowed Number of outgoing calls that failed Number of outgoing calls successfully connected Number of outgoing calls answered. Traffic usage in CCS [1] System-busy usage in CCS [1], i.e. unplanned SB time out of service Maintenance-busy usage in CCS [1], i.e. unplanned MB time out of service 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.
Page
831
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
Nortel Networks
PROPRIETARY
Page
832
Part H OAM&P
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
Order code OAMI0002 OAMI0003 OAMI0004 OAMI0006 Interconnect OMs Equal Access - Serving Carrier ID Long Call Audit Name / description Interconnect OMs and Answer OM Enhancements
Page
833
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
Nortel Networks
PROPRIETARY
Page
834
Part H OAM&P
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.
! ! !
Page
835
Nortel Networks
PROPRIETARY
Part H OAM&P
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.
Nortel Networks
PROPRIETARY
Page
836
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. The chapter is organised into the following sections: ! ! ! ! ! ! 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.
Nortel Networks
PROPRIETARY
Page
837
Part H OAM&P
Chapter H6 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.
Nortel Networks
PROPRIETARY
Page
838
Part H OAM&P
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.
! ! !
Page
839
Nortel Networks
PROPRIETARY
Part H OAM&P
H6.3
H6.3.1
User Authentication and Account Administration

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
Nortel Networks
PROPRIETARY
Page
840
Part H OAM&P
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
NE CS2000 Core GWC SAM21 CICM UAS USP PP8600 PVG Account & Administration Privclass (administered via MAPCI or Passwerks) 1 fixed Local Craft Interface account 1 fixed Local Craft Interface account (no password) Windows 2000 account Windows 2000 account Windows 2000 account Local P8600 CLUI account Local [1] Passport CLUI account
[1] Local indicates that administration is done per NE, rather than centrally
H6.4
Secure 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.
Page
841
Nortel Networks
PROPRIETARY
Appendices
Appendix A ISN07 Release Contents
Appendices
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.
Page
843
Nortel Networks
PROPRIETARY
Appendices
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
Nortel Networks
PROPRIETARY
Page
844
Appendices
"
" "
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. FN reference: A00003933 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.
Page
845
Nortel Networks
PROPRIETARY
Appendices
Media Gateways ! PVG hardware enhancements: " Support for carrier-grade GigE uplinks to core network " 4-port GigE FP FN reference: A00002818 " 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
Nortel Networks
PROPRIETARY
Page
846
Appendices
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.
Page
847
Nortel Networks
PROPRIETARY
Appendices
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. FN reference: A89007985. 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.
Nortel Networks
PROPRIETARY
Page
848
Appendices
A.3
Datafill
Software
! 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. FN reference: A00002555. 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. FN reference: A00002252. 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. FN reference: A00003575. 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.
Page
849
Nortel Networks
PROPRIETARY
Appendices
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 FN reference: A00001895. 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). FN reference: A00002255. 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
! !
Nortel Networks
PROPRIETARY
Page
850
Appendices
FN reference: A00002358. ! 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). FN reference: A00003627. 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).
! !
Page
851
Nortel Networks
PROPRIETARY
Appendices
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. FN reference: A00002909. ! 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. FN reference: A00002908. 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. FN reference: A00003696.
PROPRIETARY Page
Nortel Networks
852
Appendices
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 FN reference: A00004931. Support for Russian ISUP and interworkings FN reference: A00005164. 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). FN reference: A00002794. 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 FN reference: A00003695. MPC (Multiple Point Code) support for TCAP
! ! !
Page
853
Nortel Networks
PROPRIETARY
Appendices
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 FN reference: A00002907. 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 FN reference: A00002934. 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 FN reference: A00002678. 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 FN reference: A00002754.
Nortel Networks
PROPRIETARY
Page
854
Appendices
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. FN reference: A00002900.
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.
Page
855
Nortel Networks
PROPRIETARY
Appendices
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. FN reference: A00002755. # Enhanced Meet-Me Conference service, including access control via passwords instead of simply by dialling conference bridge DN. FN reference: A00002901. " 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. FN reference: A00002654. # 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. FN reference: A00002655. # CEPT features CFF, CDTA, WML, SCS, SCL, CCBS, WUC and DTM FN reference: A00002610 # Enhancements to existing CEPT ICWT service. FN reference: A00002639 # Services enhanced/provided on CEPT lines: Concurrent Call Forwarding Denied Call Forwarding Subscriber programmable ringing for CFNA Call Pickup Directed Call Pickup FN reference: A00002640 # Enhancements to CEPT ILR service. FN reference: A00002641 # Enhancements to CEPT 3WC and Call Transfer. FN reference: A00002642 ! ANATEL 252 Compliance Support for Call Waiting Ringback Tone plus others FN reference: A00002365.
Nortel Networks
PROPRIETARY
Page
856
Appendices
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). FN reference: A00002761. 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. FN reference: A00002558. Support for appropriate selection of analogue line services over newly supported analogue line implementations: " Services supported by MG9000 gateways " Services supported by Arris MTA
"
"
Gateways supported using H.323 (e.g. Meridian 1, BCM) # 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). FN reference: A00002330. 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.
Page
857
Nortel Networks
PROPRIETARY
Appendices
"
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. FN reference: A00003626. ISDN Supplementary Services 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 Gateways supported using H.323 (e.g. Meridian 1, BCM) 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.
Nortel Networks
PROPRIETARY
Page
858
Appendices
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".
Page
859
Nortel Networks
PROPRIETARY
Appendices
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) FN reference: A00002756.
Conferencing No enhancements in ISN07. Voice Mail No enhancements in ISN07. RAS for Dial-Up Access No enhancements in ISN07. 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. FN reference: A00001965.
Nortel Networks
PROPRIETARY
Page
860
Appendices
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. FN reference: A89008119.
Page
861
Nortel Networks
PROPRIETARY
Appendices
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
No ISN07 enhancements.
Numbering Plan
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. FN reference: A00003711.
Nortel Networks
PROPRIETARY
Page
862
Appendices
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. FN reference: A00002739.
Page
863
Nortel Networks
PROPRIETARY
Appendices
A.8
Overview
OAM&P
! 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
PROPRIETARY Page
Nortel Networks
864
Appendices
"
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 # QCA (QoS Collector Application) # NPM (Network Patch Manager)
Packaging and integration of EMs and management applications in ISN07 " CS2000 Core Manager 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) 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 $ 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.
Page
865
Nortel Networks
PROPRIETARY
Appendices
"
"
"
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 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
Nortel Networks
PROPRIETARY
Page
866
Appendices
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. FN reference: A00001743. 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. FN reference: A00003280.
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)
! !
Page
867
Nortel Networks
Appendices
" " "
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. FN reference: A00002638. 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.) FN reference: A00003007 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. FN reference: A00002744. 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. FN reference: A00001650. 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. FN reference: A00001927.
! ! !
Nortel Networks
PROPRIETARY
Page
868
Appendices
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). FN reference: A00002625. 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 FN reference: A00002637.
! !
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. FN reference: A00001742. 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.
Page
869
Nortel Networks
PROPRIETARY
Appendices
! ! ! !
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
! !
Nortel Networks
PROPRIETARY
Page
870
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 A: Introduction A1: Market Overview A2: Network Overview A3: Product Overview A3.2: Interworking Matrix 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 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 Rework network overview to reflect newly supported capabilities (new gateway types, media proxy, remote clients) Update to reflect newly supported interfaces and services; XA-Core support for 2.0M BHCA and 200,000 ISUP ports (A00003485) Update matrix to reflect newly supported interfaces and interworkings Related Features and Other Implications
B1: CS2000 Hardware
Nortel Networks
PROPRIETARY
Page
871
Appendix B Summary of Product Description Updates for ISN07
Part / Chapter
Related Features and Other Implications 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; 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 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 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 streams; Section on SAM16-based RTP Media Portal (RMP) unit first used to provide media proxy functionality, controlled by GWC using MPCP (A89007985) Rework chapter to reflect IMS rebranding as MCS5200 and increased support for integration between MCS52000 and CS2000 for multimedia Update/add load names and versions to reflect software packaging for ISN07.0 Updates and additions to reflect support for new types of interface; Servord manipulation of LNINV GND option for lines (A00002555); MG9000 preprovisioning support (A00002252); Dynamic modification of number of endpoints assigned to an operational H.323 gateway 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 Updates and additions to reflect new and enhanced protocols, inc. H.323, UniStim, MPCP, RFC3261 SIP; New section on transport protocols (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 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 for PVGs (A00003015)
B2: Media Gateways
B3: Media Servers
B4 (new): Remote Clients
B5 (new): Media Proxy
B6 (was B4): MCS5200 C: Software C1: Software Loads
C2: Trunk and Line Datafill
C3: Translations and Routing D: Packet Telephony Protocols D1: Overview
D2 (was D9): SIP / SIP-T
D3 (was D5): H.248 D4: ASPEN
Nortel Networks
PROPRIETARY
Page
872
Part / Chapter
Related Features and Other Implications 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 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 to control remote CentrexIP clients, including UniStim encryption Integration / productisation of signalling security for CMTS/MTA, including Kerberos key management and IPSec (A00003575) New chapter describing proprietary protocol based on MGCP (no SDP) used to control RTP Media Portal
D5 (new): H.323
D6 (new): UniStim D7: NCS D8: MGCP D9 (new): MPCP 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 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 (A00002907); T-INAP interworkings (A00002934); IN services for Telefonica (A00002678); China IN enhancements (A00002754); China ISUP connection to external IP (A00002900) Internal use of QSIG to support H.323 tunneling across CS LAN between H.323 GWC and Core (inc. DFT) Support for Westell gateway supporting DPNSS trunks to/from digital PBXs, 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 GWs/IADs, Arris MTA, gateways supported using H.323 (e.g. Meridian 1, BCM) Support for CentrexIP lines serving i200x Ethersets and m6350 soft clients, controlled by CICM using proprietary UniStim protocol
E2: CCS7 Interfaces
E3: INAP E4: PRI E5: QSIG E6 (new): DPNSS E7 (was E6): Analogue Subscriber Lines E8 (new): CentrexIP
Page
873
Nortel Networks
PROPRIETARY
Part / Chapter F: Features and Services F1: Overview
Related Features and Other Implications 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); Enhancements to CEPT 3WC and Call Transfer (A00002642); ANATEL 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 lines
F2: Analogue Subscriber Line Services
F3 (new): CentrexIP Services F4 (was F3): ISDN Supplementary Services F5 (was F4): QSIG Services F6 (new): DPNSS Services F7 (new): APM Feature Transparency F8 (was F6): VPN F9 (was F10): Voice Mail F10 (was F9): Conferencing F11 (was F5): Indirect Access F12 (was F7): IN Services F13 (new): Party Information Services F14 (was F8): Regulatory Services
QSIG support for H.323; QSIG support for DPNSS and DFT New chapter describing DPNSS Feature Transparency (DFT), i.e. nodal and networks support for DPNSS services via H.323 and QSIG encapsulation of DPNSS signalling (A00001965) New chapter (edited version of TDM PD equivalent) describing networked 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 DPNSS Feature Transparency; Support for multimedia / blended user services
IN services for DTAG (A00002907); IN services for Telefonica (A00002678); IN services for China (A00002754, A00002900) New chapter (edited version of TDM PD equivalent) providing one-stop summarised description of support for number/name transport and display Emergency call tracing; ETSI compliance for LI (A00002965, A00003514); LI operation not affected by internet transparency; Japan trunk 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)
Nortel Networks
PROPRIETARY
Page
874
Part / Chapter F16 (new): ADSL F17 (was F11): RAS G: Network Fit G1: Numbering Plan G2: Tones G3: Announcements G4: Network Integration
Related Features and Other Implications ADSL (Asymmetrical Digital Subscriber Line) access to the backbone packet network for data sessions with private intranets and/or the public internet, as supported by large carrier-located line media gateways
MS2000 Series as enhanced replacement for UAS GWC support for Gateway Inter-Machine Trunk (GWIMT) on PVG (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 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 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; 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); 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)
H1: Overview
H2: Fault Management
H3: Configuration
H4: Accounting
Page
875
Nortel Networks
PROPRIETARY
Part / Chapter
Related Features and Other Implications Single consolidated performance feed for PP8600, MS2000, STORM-XTS, CICM, Session Server, MCS; Capacity increase for SDM OM delivery 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 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 Create new Appendix to summarise new ISN07 content in relation to ISN05.
H5: Performance Monitoring
H6: Security
Appendices Release Contents 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. References Add references to additional relevant documents, especially ITU / IETF specifications and Nortel FNs.
Nortel Networks
PROPRIETARY
Page
876
Appendix C
C.1
References
Nortel Interface Specifications

ASPEN Protocol Specification, Version 2.1: Draft 8, October 2000 NIS D365-1 NIS A246-1 NIS A246-1bis NIS A246-1ter NIS A246-1quater NIS A258-1 NIS A215-1 NIS A219-1 NIS A247-1 NIS D201-1 NIS A245-1 NIS V208-1 TR 94-8008 CS2000 SIP-T Network Interface Specification ETSI ISUP V2 Compliance Statement APM (ETSI ISUP V2+) QFT over ETSI ISUP V2+ ETSI ISUP V2+ End PINX Support ETSI ISUP V1 Compliance Statement PRI SIM Specification QSIG SIM Specification DPNSS SIM Specification UniStim SIM Specification IUP (BTUP) SIM Specification V5.2 Interface Specification for CS2000 CS-1R INAP SIM Specification
Nortel Networks
PROPRIETARY
Page
877
Appendix C References
C.2
Standards
RFC1157 RFC1889 RFC2030 RFC2045-9 RFC2327 Plus related draft: ID RFC2543 Plus related drafts: ID ID ID ID ID RFC3435 RFC2960 Plus related draft: ID RFC3015 RFC3057 Plus related draft: ID V5UA M3UA M2PA SNMP RTP SNTP MIME SDP draft-rajeshkumar-mmusic-sdp-atm-01 SIP draft-camarillo-sip-isup-bcp-00 draft-ietf-sip-isup-mime-00 draft-ietf-sip-info-method-02 draft-ietf-sip-183-00 draft-ietf-sip-privacy-02 MGCP (CS2000 supports MGCP 1.0bis - 00 January 2001) SCTP draft-ietf-sigtran-sctp-05 H.248 IUA draft-ietf-sigtran-iua-01 draft-ietf-sigtran-v5ua-03 draft-ietf-sigtran-m3ua-10 draft-ietf-sigtran-m2pa-10
IETF RFCs and IDs
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 G.703 to G.705 G.732 H.323 H.225 H.245 H.450.1 I.431 Q.50 Annex A Q.701-Q.704 Q.711-Q.716 Q.723 Open Dial Plan PCM30 carriers PCM30 multiframe structure Umbrella specification Call processing for H.323 Connection control for H.323 Tunnelling for H.323 Physical layer requirements for ISDN PRI Digital Circuit Multiplication Equipment Interface Message Transfer Part (MTP) Signalling Connection Control Part (SCCP) Telephony User Part (TUP)
Nortel Networks
PROPRIETARY
Page
878
Q.761-Q.764 Q.765 Q.767 Q.771-Q.775 Q.920-Q.921 Q.931 Q.1214 Q.1218 Q.1224 Q.1228
ISDN User Part (ISUP) ISUP and TCAP Support for QSIG Feature Transparency ISUP for International Use Transaction Capabilities Application Part (TCAP) DSS1 / ISDN Layer 2 (Data Link) DSS1 / ISDN Layer 3 (Basic Call Control) Distributed Functional Plane for CS-1R IN CS-1R Intelligent Network Application Part (INAP) Distributed Functional Plane for CS-2 IN CS-2 Intelligent Network Application Part (INAP)
ETSI Standards
ETS 300 356 ETS 300 374 ETS 300 324 ETS 300 347 CEPT MoU ETS 300 011 ETS 300 125 ETS 300 402 ETS 300 102 ETS 300 403 ETS 300 089 ETS 300 092 ETS 300 090 ETS 300 093 ETS 300 062 ETS 300 064 ETS 300 179 ETS 300 180 ETS 300 182-1 ETS 300 136 ETS 300 138-1 ETS 300 094 ETS 300 097-1 ETS 300 095 ETS 300 098-1 ETS 300 128 ETS 300 130-1 ETS 300 059 ETS 300 061 ETS 300 284 ETS 300 286 ETS 300 357 ETS 300 359-1 ETS 300 200 ETS 300 199 ETS 300 201 ETS 300 367 ETS 300 369 ETSI ISUP ETSI Core INAP V5.1 V5.2 Memorandum of Understanding on European ISDN ETSI ISDN PRI Layer 1 (physical) ETSI ISDN Layer 2 protocol (datalink) [Blue Book] ETSI ISDN Layer 2 protocol (datalink) [White Book] ETSI ISDN Layer 3 protocol (basic call control) [Blue Book] ETSI ISDN Layer 3 protocol (basic call control) [White Book] Calling Line Identification Presentation (CLIP) (stage 1) Calling Line Identification Presentation (CLIP) (stage 3) Calling Line Identification Restriction (CLIR) (stage 1) Calling Line Identification Restriction (CLIR) (stage 3) Direct Dialling In (DDI) (stage 1) Direct Dialling In (DDI) (stage 3) Advice of Charge during call (AOC-D) (stage 1) Advice of Charge at end of call (AOC-E) (stage 1) Advice of charge (AOC) (stage 3) Closed User Group (CUG) (stage 1) Closed User Group (CUG) (stage 3) Connected Line Identification Presentation (COLP) (stage 1) Connected Line Identification Presentation (COLP) (stage 3) Connected Line Identification Restriction (COLR) (stage 1) Connected Line Identification Restriction (COLR) (stage 3) Malicious Call Identification (MCID) (stage 1) Malicious Call Identification (MCID) (stage 3) Subaddressing (SUB) (stage 1) Subaddressing (SUB) (stage 3) User-to-User Signalling (UUS) (stage 1) User-to-User Signalling (UUS) (stage 3) Call Completion on Busy Subscriber (CCBS) (stage 1) Call Completion on Busy Subscriber (CCBS) (stage 3) Call Forwarding Unconditional (CFU) (stage 1) Call Forwarding Busy (CFB) (stage 1) Call Forwarding No Reply (CFNR) (stage 1) Explicit Call Transfer (ECT) (stage 1) Explicit Call Transfer (ECT) (stage 3)
Page
879
Nortel Networks
PROPRIETARY
ISO Standards
IS 11572 IS 11582 IS 14474 DEN/SPS-01032-1 DEN/SPS-01042-1 ISO4217 ISO639-2/T QSIG Basic Call Control Procedures QSIG Generic Functional Procedures for Supplementary Services QSIG Logical/Physical Mapping ISUP and TCAP support for QFT (also known as Q.vpn) APM extensions to ISUP (also known as Q.apm) MCMP Currency Tokens MCMP Language Tokens
National Standards
PNO-ISC 006 PNO-ISC 007 BTNR 167 TR-TSY-000317 T1.113.1-4 IUP (BTUP replacement, corresponding to BTUP Version 3) UK ISUP (based on ETSI ISUP V3) BTUP Bellcore ISUP 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 SSUTR2/FTUP Brazilian ISUP Czech ISUP JI-ISUP HKTA2015 YDN 021-1996 YDN 034 BTNR 188 ART Specification SPIROU 1998-00 Specification du Sous-systeme Utilisateur SSUTR2 VN4 (ST/PAA/CER/SCS/2600) Telebras Practice 220-250-732, ISDN - ISUP CCS7 Signalling System" National Specification of MTP and ISUP for Czech Republic and Slovak Republic Japan TTC specification JJ-90.10 Version 2 (1999) Hong Kong PRI (CR13) Chinese V5.2 Chinese PRI DPNSS
Nortel Networks
PROPRIETARY
Page
880
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
Packet Telephony Protocols

A59031163 A59032553 A59036800 A89007007 A89007026 A89008654 A00001895 A00003626 A00003627 A00003575 A00001895 A00002255 A00002358 A00003627 SIP-T Support for RBC (Remote Bearer Control) requests SIP-T to SIP-T Interworking (FN included in A59025876) SIP-T Enhancements (SIP-T over UDP, Interworking with MCS5200, call audits) CLASS Services on V5.2 with H.248 CS2000 V5.2 with H.248 Protocol NCS PacketCable Compliance H.323 Base Application H.323 Support for MCDN Services T.38 Fax Support for International H.323 Integration / productisation of signalling security for CMTS/MTA CS2000 support for H.323 H.323 functionality via QSIG (ISO1996 version) trunks H.323 tunnelling T.38 FAX Support for International H.323
TDM Telephony Interfaces CCS7 trunks

A59025979 A59026177 A59026201 A59027873 A59028026 A59029292 A59029294 A59029963 SN03 ASPEN 2.1 Continuity Testing Per-call Echo Cancellation of CS2K CCS7 trunks Portuguese, Mexican, Turkish, Danish, Brazilian, Saudi and Japanese ISUP variants Integration and Interworking of TMX ISUPs with MMP ISUPs CA30 ISUP CS2000 Support for Czech ISUP Eurotrunks Enhancements (ECAN and CCD for additional ISUP variants) Voice-Law Indication in IAMs
Page
881
Nortel Networks
PROPRIETARY
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 A59028269 A59033609 A59033629 A59033637 A59034387 A19012479 A59038655 A59039729 A89008338 A00002907 A00002934 A00002678 A00002754 A00002900 In-Band Digit Collection Control (PRI) for INAP INAP oMidCall Support, SIP-T Triggering, Feature Interactions Line Triggering Interactions for 3WC/CFW INAP Support for Context Identification, Auto Continue, SCCP segmentation INAP SII (ServiceInteractionsIndicator) Interworking CM based INAP Prompt & Collect on PRI CS1R: CTR in Monitoring, Pre-Paid Services, Complex Announcements CS1R: Line Triggering Enhancements (including CCBS support) CS1R: Prepaid Services on China ISUP CS-1R Charging Enhancements T-INAP support T-INAP interworkings IN services for Telefonica China IN enhancements China ISUP connection to external IP International PRI Supported on Call Server PRI Echo Control based on Bearer Capabilities and ISUP Interworking China PRI off PVG with interworking to China ISUP Japan PRI (INS1500) off PVG T1 carriers with interworking to JI-ISUP Hong Kong PRI on T1 including IBN line interworking China ISDN on CS2K hybrid switch QSIG on CS2000 V5.2 Control V5.2 flow control V5.2 Audits and Alarms V5.2 ETSI Enhancements (for China) and Signaling Procedure Verification CS2000 V5.2 Interface and Link Enhancements
PRI
A59020206 A59026186 A59039647 A59039128 A59039654 A89008422
QSIG
A59038835 A59034339 A59038965 A59038943 A59038988 A89009559
Analogue Subscriber Lines
Features and Services Analogue Subscriber Line Features

A00001351 A00000439 A59033132 A59034339 A59034502 SACB Support for MADN Secondary Members UAS Support for DMCT (Denied Malicious Call Termination) Service Succession Analogue Services II on Motorola MTAs Services: V5.2 Line Services CEPT Line Features
Nortel Networks
PROPRIETARY
Page
882
A59035140 A59038854 A59039130 A59039138 A59039741 A59040478 A59038837 A89007007 A89008399 A89008956 A00002755 A00002901 A00002654 A00002655 A00002610 A00002639 A00002640 A00002641 A00002642 A00002365 A00002761. A00002558 A00003629 A00002330 A00003626 A89008946
Cable Analogue Services II CCBS support for cable lines CFRA support for cable lines VMWI via NCS for cable lines Networked CNAMD support for cable lines SCWID on CEPT lines Open Dial Plan enhancements on CS2000 (AR support) CLASS Services on V5.2 with H.248 China Line Features Call Forwarding Indication (CFIND) for Succession Lines China line services (full DMS-100i equivalence) Enhanced Meet-Me Conference service CEPT CCB support ed as CLASS AR CEPT ACRJ support CEPT features CFF, CDTA, WML, SCS, SCL, CCBS, WUC and DTM Enhancements to existing CEPT ICWT service Services enhanced/provided on CEPT lines Enhancements to CEPT ILR service Enhancements to CEPT 3WC and Call Transfer Call Waiting Ringback Tone (ANATEL 252 Compliance) ACRJ functionality for HK LDI Display for CLASS phones Service support for gateways supported using H.323 Verification of V5.2 support for additional services MCDN feature transparency Redirecting Number Enhancements for ETSI PRI DPNSS Feature Transparency (DFT) Tone Burst On Answer for Indirect Access CM based Prompt & Collect on PRI for 2-Stage Indirect Access DNBD (LI) on CS2000 LI (Lawful Interception) support for Incremental Services - Completion CS2000 LI support for incremental services - Phase 2 German National Regulatory Services Payment Ceiling for Analogue Lines LI Enhancements for Packet Network Calls LI for CEPT Services (CW, CHD, 3PTY,CFU, CFB, CFNR) Hong Kong regulatory features (CLI enhancements) Hong Kong regulatory features (MCT enhancements) Hong Kong regulatory features (CFwd restriction/prevention) China ISUP Handling of Operator Calls and Emergency Calls LI Call Content in Mono Mode Call Data Delivery via FTP TCP/IP NAOC (Network Advice of Charge) Regulatory Enhancements PCA (Payment Ceiling Advice) Regulatory Enhancements SDM aspects of ETSI compliance for LI (HI1 and HI2 interfaces) Core aspects of ETSI compliance for LI (ISUP protocol changes for subaddressing) Japan trunk services Multimedia service integration via SimRing
ISDN Supplementary Services DPNSS

A00001965
Indirect Access
A59037739 A59034387 A59024510 A59024902 A59028707 A59030731 A59034497 A59035246 A59036326 A59040499 A59040504 A59040509 A59040141 A89007355 A89007360 A89007454 A89007461 A00002965 A00003514 A00002756 A89008119
Regulatory Services
Multimedia Services
Page
883
Nortel Networks
PROPRIETARY
Network Fit Tones

A19009891 A19012781 A19013546 A59022704 A89009351 A89009671 Complex Periodic Tone Flexibility for ISUP Codec Selection via Translations Simplification / Standardisdation of Announcement Datafill Table TONES Enhancement Market of Office Decoupling for Japan Market of Office Removal Phase I
OAM&P
A59029095 A59039985 A59040148 A89009303 A89007725 A89007781 A89008458 A00002638 A00003007 A00002744 A00001650 A00001927. A00002625 A00002637 A00001742 A00001743 A00003280 International Auto-Provisioning of LNINV Subscriber Usage Billing enhancements for AR/ARDDN China Trunk Metering SERVORD+ Support for CHG and EXB Commands QoS OMs for Trunk Groups Quality of Service (QoS) Reporting Provisioning China-Specific OMs on ISN06 AMA capture of software metering information for NAOC and PCA AMA enhancements for DTAG international gateway Auto-closure of billing files SBA support for electronic file delivery MG9000 support for hardware metering CS2000 metering enhancements for tariff model compliance CS2K NAOC trunk metering enhancements for Spain Capacity increase for SDM OM delivery application (OMDD) SDM log delivery enhancements (SCC2) Logs for SIP / SIP-T
Nortel Networks
PROPRIETARY
Page
884

cs2000PDISN07 07 03

Uploaded by

Document Information

Original Description:

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

cs2000PDISN07 07 03

Uploaded by

Copyright:

Available Formats

International Succession Networks

CS2000 International Product Description

Issue ISN07_v3 (approved), 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Part D Packet Telephony Protocols

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Part E Telephony Interfaces

E3.3 E3.4 E3.5 Chapter E4

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

E4.5 E4.6 Chapter E5

Overview of Feature Set Support Order Codes for PRI

Part F Features and Services

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

F2.3 F2.4 F2.5 F2.6 Chapter F3

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

F8.4 F8.5 Chapter F9

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

652 652 653 656 657 659

Chapter F16 Chapter F17

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Part G Network Fit

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

IP Addressing Example for CS2000 Solutions

762 764 764 765 765 767 767

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

PSTN PTE PTE2000 PTM PVC PVC PVG QCA QoS

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Chapter A1 Market Overview

MEGACO Network Architecture