You are on page 1of 908

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

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

iii

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

iv

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

vi

CS2000 International Product Description

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

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

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

viii

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

xii

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

xv

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

xvii

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

xix

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

xxi

CS2000 International Product Description

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description

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)

Issue ISN07_v3 (approved) 17 August 2004

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Chapter A2 Network Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

A2.2

CS2000 Implementation of MEGACO Architecture


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

Page

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A2 Network 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

Chapter A2 Network Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A2 Network 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

Chapter A2 Network Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A2 Network 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

"

"

"

"

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

10

Chapter A2 Network Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

"

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A2 Network 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

12

Chapter A2 Network Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

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

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A2 Network 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

14

Chapter A2 Network Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

"

"

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A2 Network 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

16

Chapter A2 Network Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A2 Network 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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

18

Chapter A2 Network Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

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.
Page PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004

19

Nortel Networks

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A2 Network 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.

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

21

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

22

Chapter A3 Product Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

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

Spain China USA (ANSI PRI) Hong Kong (CR13) Japan (INS1500)

! !

QSIG VPN interface DPNSS VPN interface for the UK

Page

23

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part A Overview

Chapter A3 Product Overview

Basic analogue subscriber lines implemented/supported in the following ways: " Lines served by high-capacity telco-located line media gateways " Lines served by small CPE media gateways attached to customer LANs " Lines served by small CPE media gateways attached to cable access networks " V5.2 PSTN lines served by PVGs Lines served by gateways, PBXs and other units connected to CS2000 via H.323 CentrexIP lines serving IP-enabled Ethersets and PC-based soft clients

! !

See Part ETelephony Interfaces for descriptions of these interfaces. See the interworking matrix on page 26 for a summary of the supported interworkings between interfaces. CS2000 also supports ADSL (Asymmetrical Digital Subscriber Line) lines for high-speed, always-on access to enterprise networks or the public Internet.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

24

Chapter A3 Product Overview

Part A Overview

CS2000 International Product Description Communication Server Capabilities

A3.4

Interworkings between Telephony Interfaces


This section provides an interworking matrix that summarises all of the possible basic call interworkings between the telephony interfaces supported by CS2000. Each interworking between two interfaces is represented by a cell in the table. The table cell representing an interworking contains one of the following, to indicate the level of support for the interworking: Y 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

Issue ISN07_v3 (approved) 17 August 2004

ISUP

CCS7

TUP

Access / VPN

Q.931 / IUA

Basic analogue lines (IBN)

Lines

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

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

Chapter A3 Product Overview

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

Chapter A3 Product Overview

[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

Issue ISN07_v3 (approved) 17 August 2004

Part B Hardware

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

Chapter B1

CS2000 Hardware

This chapter describes the hardware of the CS2000 itself, and is organised into the following sections: ! ! ! ! ! ! ! ! ! Section B1.1: Overview on page 30 Section B1.2: Processor Complex (Core) on page 34 Section B1.3: Internal Communication (CS LAN and MS) on page 42 Section B1.4: Gateway Controllers (GWCs) on page 53 Section B1.5: Session Server on page 71 Section B1.6: CCS7 Signalling Terminations on page 72 Section B1.7: OAM&P Hardware on page 81 Section B1.8: CS2000 Interworking with Legacy Peripherals on page 89 Section B1.9: Hardware Packaging on page 93

ISN software can also be installed on the DMS-100 hardware platform to provide circuit-based switching and service support capabilities, in which case it is referred to as ISN (TDM). ISN software can even be installed in a hybrid configuration that comprises CS2000-specific and DMS-specific hardware as well as hardware that is common to both. Such a hybrid configuration can support circuit-based and packet-based capabilities simultaneously, as described in section B1.8 on page 89. This Product Description provides detailed descriptions only of CS2000 components and of DMS hardware components that are common to DMS and CS2000 and may be included in a non-hybrid CS2000 configuration. For a systematic description of all DMS hardware, including components for which hybrid configuration interworking is supported, refer to the separate ISN07 (TDM) Product Description.

Page

29

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 Hardware

B1.1

Overview
To meet the needs of different types of customer, a range of different CS2000 hardware configurations are supported in ISN07. These can be categorised in two main ways: ! In terms of the type of processor complex used: " Standard CS2000 configuration Note: A standard configuration is a CS2000 that uses the XA-Core processor complex. The term can denote either a full SuperNode configuration or a streamlined SNSE (SuperNode Size Enhanced) configuration. " CS2000-Compact configuration with minimised system footprint ! In terms of the extent to which they incorporate DMS hardware as well as CS2000 hardware, the possibilities being: " Configurations consisting entirely of CS2000 hardware " Configurations that use DMS hardware for selected functions " Hybrid configurations that support interworking between CS2000 and DMS trunk and line peripherals These configuration options are illustrated in Figures 3 to 5. A CS2000 is a distributed system comprising a number of different functional elements. The main functional elements are common to all types of CS2000 configuration, but there are some differences between configurations in terms of the hardware components used to implement certain functions. These differences are summarised on page 32 and discussed in more detail in the sections dealing with particular components. Physically, a CS2000 configuration consists of circuit packs housed in slots in shelves, which are in turn packaged into cabinets to form a cabinet lineup. See section B1.9 on page 93 for information about CS2000 hardware packaging and illustrations of some typical cabinet lineups.

USP supports CCS7 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

30

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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
H.323 GWC Line GWC RMGC GWC DPT GWC Session Server

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

32

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

34

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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).

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

36

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

38

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.
"

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

40

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

! ! ! ! !

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

42

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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
H.323 GWC Line GWC RMGC GWC DPT GWC Session Server

Signalling VLAN Client signalling VLAN External signalling VLAN Bearer VLAN OAM&P VLAN

Dual PP8600s

Router/firewall controlling access to/from NOC LAN

Figure 8:

Virtual LANs supported by the CS2000 CS LAN


PROPRIETARY Page

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

44

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

46

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

48

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

50

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

52

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

54

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

56

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

58

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

60

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

62

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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
CS2000 Core Call processing DPT provisioning

Access GWC

DPT GWC DPT GWC DPT GWC

Session Server

Inter-CS connection

Session Server

DPT GWC DPT GWC DPT GWC

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
CS2000 Core Call processing DPT provisioning

Access GWC

DPT GWC DPT GWC DPT GWC No VRDN for call origination

A B

VRDN GWC

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

"

"

" "

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

64

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

"

"

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

66

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

" "

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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).
"

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

68

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

70

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

TCAP SCCP Conventional CCS7 signalling network

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

See section B1.4.5.3 on page 62 for information about DPT GWC interaction with Session Server or VRDN

TCP or UDP IP

IP control network over backbone packet network

Figure 14: Alternative methods of supporting CCS7 on CS2000

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Other CS2000s, MCS5200s, etc


Page

SIP-T SIP-T

TDM-side switches, SCPs, etc

Message Switch (CS2000 bus)

Other CS2000s, MCS5200s, etc

TDM-side switches, SCPs, etc

72

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

74

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

76

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

78

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Message Switch (CS2000 bus)

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

80

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

82

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

84

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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)

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

86

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

88

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Packet backbone network


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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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)

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


Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

90

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

92

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B1 CS2000 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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

94

Chapter B1 CS2000 Hardware

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

96

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

High-capacity line media gateways, typically located on operating company premises. In ISN07, CS2000 supports the MG9000 as a high-capacity media gateway for analogue lines and ADSL (Asymmetrical Digital Subscriber Line) access. The MG9000 is described in section B2.8 on page 119. Line media gateways located on customer premises and connected to an Ethernet LAN. A number of different customer LAN gateway types are available to support VoIP for analogue subscriber lines. As the main characteristics of these different gateway types are essentially the same from a CS2000 perspective, they are all listed and briefly described in one section, section B2.9 on page 123. MTA (Multimedia Terminal Adapter) line media gateways located on customer premises and connected to a cable access network to support VoIP for analogue subscriber lines. Several different MTA gateway types are available to support VoIP for analogue subscriber lines. As the main characteristics of these different gateway types are essentially the same from a CS2000 perspective, they are all listed and briefly described in one section, section B2.10 on page 126. CVX1800 Universal Port media gateways providing TDM-side trunk terminations to support two types of access to the packet network: " RAS (Remote Access Service), i.e. dial-up access to internet / intranet sessions " VoIP voice calls CVX1800 media gateways are described in section B2.11 on page 130. Note: CS2000 support for RAS has been tested and verified for deployment only in a specific customer network, and is not generally available in ISN07.

Note: Although it is not possible to describe CS2000 operation and capabilities without also referring to the capabilities of the gateways it supports, gateways are not part of the CS2000 product. For detailed, definitive information about the capabilities of a given gateway type, it is necessary to refer to its product documentation. In the event of any discrepancy between statements made in this chapter and statements made in a gateways product documentation, the gateway product documentation should take precedence.

Page

97

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

98

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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 (IP or ATM)


Packet network terminations support both bearer connections and H.248 or ASPEN control connections with GWC

TDM or access network

TDM FP (Function Processors) supporting TDM-side terminations

VSP (Voice Service Processor) supporting TDM/packet conversion

Integral GigE port

Direct GigE support of IP

Configuration C: Integral STM-1/OC-3 packet-side ports on VSP3-o

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 FP or 4pGE IP FP

TDM or access network

Integral STM-1 port

VSP (Voice Service Processor) supporting TDM/packet conversion

Dedicated FP (IP or ATM) supporting packet-side terminations

Figure 33: Logical configuration of a PVG

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

100

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

102

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

104

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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)

IP PP15000 with VSP2 ATM (AAL2)

IP PP7480 with VSP2 ATM (AAL2)

Reliability and quality of service are carrier grade, even in a non-redundant configuration in which E1 carriers are not duplicated.
Page PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004

105

Nortel Networks

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

106

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

108

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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.
Page PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004

109

Nortel Networks

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

110

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

112

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

114

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

116

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

B2.6.2

Summary of Characteristics

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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)

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

118

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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)

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

H.248 control connection with CS2000 GWC


Page

Service Module (SM) cards supporting access network connections

MG9000 media gateway

120

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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

Summary of Characteristics

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

122

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

124

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

B2.9.3

Summary of Characteristics
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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

126

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

128

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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)
Page PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004

129

Nortel Networks

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

130

Chapter B2 CS2000 Support for Media Gateways

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B2 CS2000 Support for Media Gateways

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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

133

CS2000 International Product Description Communication Server Capabilities

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

134

Chapter B3 CS2000 Support for Media Servers

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B3 CS2000 Support for Media Servers

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

136

Chapter B3 CS2000 Support for Media Servers

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

B3.2.2

Summary of Characteristics

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B3 CS2000 Support for Media Servers

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

138

Chapter B3 CS2000 Support for Media Servers

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B3 CS2000 Support for Media Servers

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)

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

140

Chapter B3 CS2000 Support for Media Servers

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B3 CS2000 Support for Media Servers

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

Summary of Characteristics

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

142

Chapter B3 CS2000 Support for Media Servers

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

144

Chapter B4 CentrexIP Remote Clients

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

CS2000 exercises control over 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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B4 CentrexIP Remote Clients

B4.2

CentrexIP Clients and their Capabilities


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

B4.2.1

i200x Etherset Characteristics and Capabilities


An Etherset is an IP-enabled Ethernet phone. It uses a large display and programmable softkeys to support quick and easy access to capabilities such as multiple directories, multimedia mailboxes and voice recognition. Three types of Nortel Networks Etherset are supported in ISN07: ! ! ! i2001 i2002 i2004

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

146

Chapter B4 CentrexIP Remote Clients

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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.
Page PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004

147

Nortel Networks

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B4 CentrexIP Remote Clients

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

148

Chapter B4 CentrexIP Remote Clients

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

B4.3
B4.3.1

CentrexIP Client Manager (CICM)


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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B4 CentrexIP Remote Clients

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

150

Chapter B4 CentrexIP Remote Clients

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B4 CentrexIP Remote Clients

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]

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

153

CS2000 International Product Description Communication Server Capabilities

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

154

Chapter B5 Media Proxies

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Using a GWC-controlled media proxy to support NAT traversal for media streams means that no changes are required to media gateway or NAT functionality. In particular, it does not require gateways to be aware of network topology and middlebox deployment. It is a scalable solution with no dependencies on factors outside the network operators control. The situation for determining whether a media proxy needs to be inserted in a call to support NAT traversal is very similar to the situation for determining whether CAC should be applied. NATs and Limited Bandwidth Links (LBLs) can both be regarded as types of middlebox whose involvement in a call has an impact on call establishment at the GWC. See Chapter G6: CAC (Call Admission Control) for further information.

Page

155

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B5 Media Proxies

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

156

Chapter B5 Media Proxies

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B5 Media Proxies

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

158

Chapter B5 Media Proxies

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B5 Media Proxies

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

160

Chapter B5 Media Proxies

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B5 Media Proxies

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

162

Chapter B5 Media Proxies

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B5 Media Proxies

B5.2.6

Summary of Characteristics

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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

165

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

166

Chapter B6 Multimedia Communication Server (MCS52000)

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

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

Page

167

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B6 Multimedia Communication Server (MCS52000)

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

168

Chapter B6 Multimedia Communication Server (MCS52000)

Part B Hardware

CS2000 International Product Description Communication Server Capabilities

B6.3

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part B Hardware

Chapter B6 Multimedia Communication Server (MCS52000)

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

170

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

172

Chapter C1 Software Loads

Part C Software

CS2000 International Product Description Communication Server Capabilities

C1.1

CS2000 Core Load


This section describes the structure of the CS2000 Core software load required to make a CS2000 operational. The Core software load is known as the Product Computing-Module Load (PCL). The ISN07 load installed in the 3PC in Compact configurations supports the same call processing and service functionality as the load installed in XA-Core in standard configurations. The XA-Core load is formally referred to as PSNWC07 (order code SW000007); the 3PC load is formally referred to as CSNWC07 (order code SWC00007). Note: Other CS2000 units have their own software loads, as described in the other sections of this chapter. These include the GWC, the USP, the FLPP and the Core and Billing Manager (CBM) or SuperNode Data Manager (SDM) used as the platform for the CS2000 Core Manager. CS2000 is a layered product, with ownership of the layers defined and a clear understanding of the allocation of functions to layers and the dependencies between layers. The main layers are: ! ! Base, which comprises basic computing functions such as processing, memory management and hardware diagnostics. Telecom, which supports the peripheral types used by CS2000 and provides call processing support functions such as translations and routing. Note: The combination of Base layer software and Telecom layer software is known as the Communication Services Platform (CSP). Product, which supports call processing applications and services by means of reusable software objects and generic agents. The Product Layer also includes any software required to customise a Communication Server for use in a particular market, e.g. the software used to customise CS2000 for European and Australasian markets. For example, the base capabilities required to implement an interface such as ETSI ISUP are typically provided by means of a generic call processing agent, and variants of this agent are made available to meet the requirements of specific national markets.

To allow development to proceed independently for different parts of the system, the complete software configuration for a Communication Server is assembled from separately delivered Development Release Units (DRUs). A DRU may be a complete software layer or a set of integrated software within a layer. It cannot straddle layers, and is always delivered and included in the switch configuration as a whole. Note: Some software is also made available as part of a library, which is a collection of self-contained software components for re-use by different products. The difference between a library and a DRU is that it is possible to select a subset of software from a library for inclusion in a PCL rather than including the library as a whole.

Page

173

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C Software

Chapter C1 Software Loads

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

174

Chapter C1 Software Loads

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C Software

Chapter C1 Software Loads

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

176

Chapter C1 Software Loads

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C Software

Chapter C1 Software Loads

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

178

Chapter C1 Software Loads

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C Software

Chapter C1 Software Loads

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

180

Chapter C1 Software Loads

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

182

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

C2.2

Trunk Group Provisioning


This section lists and briefly describes the CS2000 Core data schema tables used to provision trunk groups and destinations to support the trunk routing functionality described in Chapter C3: Translations and Routing. See section C2.3 on page 185 for information about the tables used to provision signalling links, which convey the messages used by the Core to translate and determine the destination of a call so that an appropriate trunk can be selected. CS2000 supports the following types of trunk destination, for which the datafill requirements are described in other sections in this chapter: ! ! TDM-side trunks served by media gateways (see section C2.5 on page 190). DPTs (Dynamic Packet Trunks) to packet network destinations served by other CS2000s (see section C2.6 on page 191).

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

Page

183

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

Table TRKMEM (also table C7TRKMEM for CCS7 trunks) Assigns individual trunks to trunk groups. Also used in mapping individual trunks on to physical locations and carrier timeslots (virtual locations and timeslots in the case of CS2000, which does not physically terminate trunk bearer channels). Table TRKMEM defines the TIDs (terminal identifiers) used by CS2000 Core call processing to identify and select specific trunks. Media gateways identify the TDM-side trunks they support by means of EIDs (endpoint identifiers) specifying a particular 64 Kb/s channel on a particular E1 carrier. Mapping between TIDs and EIDs is provided by GWC datafill, as summarised in section C2.5.2 on page 190. Table TRKOPTS Defines additional options for trunk groups, e.g. trunk group options used to support Carrier Selection. These include:
"

"

The DYNAMIC option, which is used in provisioning the DPT GWCs used to terminate CCS7 signalling encapsulated in SIP-T messages, as described in section C2.6.2 on page 192. The VOICELAW option, which indicates the companding voice-law used on bearer connections (g711_a_law or g711_mu_law). This information is conveyed in the IAM USI parameter for outgoing calls made via the trunk group. See A59029963 for more information. Note: CS2000 has no way of verifying that the voice-law provisioned and signalled in the IAM is the voice-law actually used by the gateway. This must be ensured by co-ordinating CS2000 and gateway datafill.

Table SIPLINK (Session Server implementation of SIP/SIP-T) Contains the access link information that is used to direct calls to the appropriate SIP server. This information is also used by Session Server devices for mapping incoming calls. Table LTDATA (ISDN trunks only) Datafilled with the LTID, data type and logical terminal values of the trunk group. Can also include options for provisioning services, including:
" "

The DN option, which is used in provisioning the default directory number. The CLI option, which is used in provisioning CLI-related ISDN features such as CLIR (Calling Line Identity Restriction) and 2CLI (Two Calling Party Number Delivery). The SERV option, which is used in provisioning ISDN supplementary services such as MCID (Malicious Call Identification) and UUS1 (User-To-User Information Service Type 1).

"

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

184

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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)

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

186

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

188

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

190

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

192

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

194

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

196

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

198

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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.
Page PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004

199

Nortel Networks

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

200

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

Cable access network

CMTS

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C2 Trunk and Line Datafill

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

202

Chapter C2 Trunk and Line Datafill

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

204

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

C3.1

Overview
For calls via the public network, CS2000 uses universal translations for the analysis of dialled numbers to determine the correct route to use for call completion. Dialled numbers are not, however, presented directly to universal translations. CS2000 uses Centrex software, which means that the following types of preliminary screening and translation can be performed before numbers are passed to universal translations, which can thus focus more efficiently on analysing numbers in terms of the PSTN numbering plan: 1 NCOS (Network Class Of Service) screening for direct subscriber access. The NCOS value assigned to a line or incoming trunk determines the types of call that can be made from that line or trunk. See section C3.2 for details. 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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

C3.2

NCOS Screening
Every CS2000 line and trunk belongs to a customer group, and every customer group is assigned a list of Network Class Of Service (NCOS) values. An NCOS is a numeric code that denotes a particular combination of call types that are permitted or barred. Table 20 shows a typical minimum list of NCOS values and associated combinations of call types that could be defined for a customer group. For a typical customer group, this minimum list would be augmented to allow about 50 combinations of call types to be identified by means of NCOS values (since NCOS is a 1-byte field, the maximum is 256 identifiable call type combinations for a customer group). Table 20: Typical minimum list of NCOS values for a customer group 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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

206

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

208

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

210

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

212

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

214

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

216

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

218

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

220

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

222

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

224

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

226

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part C

Chapter C3 Translations and Routing

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

228

Chapter C3 Translations and Routing

Part C Software

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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

Issue ISN07_v3 (approved) 17 August 2004

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

Issue ISN07_v3 (approved) 17 August 2004

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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

234

Chapter D1 Overview

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

D1.2.3

SCTP (Stream Control Transmission Protocol)

D1.2.3.1 Purpose SCTP is an IETF protocol defined in RFC2960. The CS2000 implementation is compliant with draft version 5. In ISN07, CS2000 supports the use of SCTP for two main purposes: ! To provide reliable ordered transport for backhauled call control signalling via the following protocol stacks (see : " Q.931 or QSIG / IUA / SCTP / IP, as used for ISDN Layer 3 D-channel backhaul. " V5-PSTN / V5UA / SCTP / IP, as used for V5.2 Layer 3 signalling backhaul. To provide reliable ordered transport for CCS7 signalling via the following protocol stacks:
" "

CCS7 / M3UA / SCTP / IP, as used for intra-CS2000 signalling over the CS LAN. TCAP / SCCP / MTP3 / M2PA / SCTP / IP protocol stack, as used for NCAS (Non Call Associated Signalling) between peer CS2000s.

SCTP is a reliable transport protocol designed by the IETF SIGTRAN workgroup as an alternative to TCP and UDP for handling delay-sensitive payloads such as call control signalling. It is an assured transfer type that will not allow call setup to succeed unless all messages have been received in the correct order. Using SCTP as a transport protocol instead of UDP means that no application-level reliability mechanisms are required or supported by the top-level protocols in these protocol stacks. SCTP offers the following services to its users: ! ! ! ! ! Acknowledged, error-free, non-duplicated transfer of user data. Data fragmentation to conform to the MTU (Maximum Transmission Unit) size discovered for the transport path. Sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages. Optional bundling of multiple user messages into a single SCTP packet. Network-level fault tolerance via support of multi-homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. SCTP also allows the failure of MGCs (CS2000s) within the packet network to be detected so that appropriate recovery action can be taken.

Page

235

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

236

Chapter D1 Overview

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

Other CS2000s, peer MGCs

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

238

Chapter D1 Overview

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

240

Chapter D1 Overview

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

243

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

244

Chapter D2 SIP and SIP-T

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

GWC support for inter-CS signalling using Session Server


Originating CS2000
CS2000 Core Call processing DPT provisioning

Terminating CS2000
CS2000 Core Call processing DPT provisioning

Access GWC

DPT GWC DPT GWC DPT GWC

Session Server

Inter-CS connection

Session Server

DPT GWC DPT GWC DPT GWC

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
CS2000 Core Call processing DPT provisioning

Access GWC

DPT GWC DPT GWC DPT GWC No VRDN for call origination

A B

VRDN GWC

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D2 SIP and SIP-T

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

246

Chapter D2 SIP and SIP-T

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D2 SIP and SIP-T

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

248

Chapter D2 SIP and SIP-T

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D2 SIP and SIP-T

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

250

Chapter D2 SIP and SIP-T

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D2 SIP and SIP-T

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>

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

252

Chapter D2 SIP and SIP-T

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D2 SIP and SIP-T

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

254

Chapter D2 SIP and SIP-T

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

256

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

258

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

260

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

262

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

! ! ! ! ! !

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

264

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

266

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Response (GWC to MG)


MEGACO/1 [47.174.66.80]:2944 Reply=23{ Context=1002{ Notify=E1/1/20/5 } }

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

Response (MG to GWC)


MEGACO/1 [47.166.34.20]:2944 Reply=65{ Context=1002{ Modify=E1/1/20/5 } }

(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 { } } }

Response (MG to GWC)


MEGACO/1 [47.166.34.20]:2944 Reply=66{ Context=1002{ Modify=E1/1/20/5 } }

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

268

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Response (media server to GWC)


MEGACO/1 [47.174.66.102]:2427 Reply = 49 { Context = 9 { Modify = audio/audiopool0/2, Subtract = audio/audiopool0/2 } }

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

270

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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.
Request (GWC to media server)
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 }}}}}

Response (media server to GWC)


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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.


Response (media server to GWC)
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 } }

Request (GWC to media server)


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

Response (media server to GWC)


MEGACO/1 [47.174.66.102]:2427 Reply = 12 { Context = 1 { Modify = te/tepool0/2 } }

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

Response (media server to GWC)


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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

272

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.


Response (media server to GWC)
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 } } } } }

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

274

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

Table 27: Example H.248 message formats for Lawful Interception (LI)
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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D3 H.248

Table 27: Example H.248 message formats for Lawful Interception (LI)
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.
Response (media server to GWC)
MEGACO/1 [47.171.164.21]:2945 Reply = 3007 { Context = 1 { Modify = te/tepool0/2 } }

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

Response (media server to GWC)

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

Response (media server to GWC)

MEGACO/1 [47.171.164.21]:2945 Reply = 3009 { Context = 1 { Modify = te/tepool0/3 } }

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

Response (media server to GWC)

MEGACO/1 [47.171.164.21]:2945 Reply = 3010 { Context = 1 { Topology { te/tepool0/0, te/tepool0/3, Oneway } } }

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

276

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

Table 27: Example H.248 message formats for Lawful Interception (LI)
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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

278

Chapter D3 H.248

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Response (GWC to MG)


MEGACO/1 [47.174.66.80]:2944 Reply=24{ Context=1002{ Notify=E1/1/20/5 } }

[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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

280

Chapter D4 ASPEN

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

D4.2

Network Role
The main ASPEN commands used for call setup and clearing are sent by a GWC to a media gateway. Each command is acknowledged by the media gateway. They are: ! ! ! CRCX (create connection) MDCX (modify connection) DLCX (delete connection)

Call setup commands and their acknowledgements can include SDP session descriptions that provide address and media stream information for the call. Since UDP may be subject to packet loss, an ASPEN application layer timer is started when each command is sent, and the command will be resent if the timer expires without an acknowledgement being received. GWCs and trunk media gateways are separately provisioned with the address information they need to communicate with each other via ASPEN. For each media gateway controlled by a GWC, GWC datafill specifies the gateway IP address, UDP port and trunk or line endpoints available (identified via physical terminations and timeslots). Similarly, media gateway datafill (as defined via the media gateway EM) specifies the IP address and UDP port of the controlling GWC. ASPEN commands identify calls by means of GWC-assigned callIDs that are unique across the entire network of media gateways. Figure 70 illustrates the role of the ASPEN protocol in the CS2000 network architecture. CS2000
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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

282

Chapter D4 ASPEN

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

284

Chapter D4 ASPEN

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

286

Chapter D4 ASPEN

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

288

Chapter D5 H.323

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

290

Chapter D5 H.323

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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)

H.323 data to be tunnelled end-to-end (H.450 APDUs and H.245 PDUs)

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

UUI IE in H.225 message


H.323 data to be tunnelled end-to-end (H.450 APDUs and H.245 PDUs)

Facility IE in QSIG message


H.323 data to be tunnelled end-to-end (H.450 APDUs and H.245 PDUs)

UUI IE in H.225 message


H.323 data to be tunnelled end-to-end (H.450 APDUs and H.245 PDUs)

Figure 73: Message mapping for H.323 tunnelling

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

292

Chapter D5 H.323

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

294

Chapter D5 H.323

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

296

Chapter D5 H.323

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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.
Page PROPRIETARY Issue ISN07_v3 (approved) 17 August 2004

297

Nortel Networks

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

298

Chapter D5 H.323

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

300

Chapter D6 UniStim

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

D6.2

Network Role
UniStim signalling is used between the CentrexIP Client Manager (CICM) on the CS2000 CS LAN and the CentrexIP remote clients that it controls. As shown in Figure 75, it is one of three types of signalling used by CS2000 to provide VoIP support for CentrexIP clients. Within the CS LAN, P-phone signalling is used by the CS2000 Core to support call processing for CentrexIP clients, and H.248 signalling is used between the CICM and the GWC that controls it.

CS2000 Core

CS2000 CS LAN
GWC for CICM

GWC for CICM

CentrexIP Client Manager (CICM)

H.248

P-Phone

P-Phone

H.248

CentrexIP Client Manager (CICM)

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 soft client (m6350):

CentrexIP Etherset client (i200x):

CentrexIP soft client (m6350):

Figure 75: Role of UniStim in supporting CentrexIP remote clients

Page

301

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

302

Chapter D6 UniStim

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

304

Chapter D6 UniStim

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

" " " " " "

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

306

Chapter D6 UniStim

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

308

Chapter D7 NCS

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

D7.2

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

Gateway 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

Issue ISN07_v3 (approved) 17 August 2004

Signalling between CS2000 GWC and MTA line gateway uses NCS

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

310

Chapter D7 NCS

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

312

Chapter D7 NCS

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

314

Chapter D7 NCS

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

316

Chapter D7 NCS

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

319

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Signalling over the line interface (except hook state changes and ringing) uses in-band DTMF tones

Call termination

Figure 77: Network role of MGCP in supporting customer LAN line gateways

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

320

Chapter D8 MGCP

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

322

Chapter D8 MGCP

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

For a line gateway attached to a customer LAN and controlled by MGCP, the address binding process is as follows: 1 The gateway sends an RSIP (Reset In Progress) message to the public network address of the CS2000 RMGC (Redirecting MGC) GWC. The RSIP message is routed through the NAT, which creates a bind between the gateways private network address and an externally visible address on the public network side of the NAT. 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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

325

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

326

Chapter D9 MPCP

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

Figure 78 illustrates the network role of the RTP Media Portal in supporting NAT traversal between two media gateways located in private networks behind NAT devices.

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

329

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

330

Chapter D10 IUA

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

D10.3 Interface Characteristics


D10.3.1 Q.931 or QSIG / IUA / SCTP Protocol Stack
! Used for call control signalling between a GWC and a PP7480 or PP15000 PVG supporting access via PRI/QSIG trunks for a digital PBX or other PRI-enabled device. PRI/QSIG signalling encapsulation PRI/QSIG Layer 3 messages (Q.931 or QSIG) such as SETUP are conveyed in IUA messages in the same way that they are normally conveyed in Q.921 Layer 2 messages. Q.921 primitives enabling establishment and disconnection of the Q.921 layer in the gateway are carried over IUA. This enables the GWC to exercise remote control over the Q.921 layer in the gateway.

D10.3.2 PRI / QSIG


For details of CS2000 support for PRI, see Chapter E4: PRI Access Interface. For details of CS2000 support for QSIG, see Chapter E5: QSIG VPN Interface.

D10.3.3 IUA
CS2000 GWCs and gateways are compliant with IUA as defined in IETF draft version 1 of RFC3057. Its main characteristics are: ! ! Capabilities similar to those of Q.921 Layer 2 (datalink) Messages used in Q.921 link establishment and release: " Establish (corresponding to Q.921 DL-ESTABLISH) " Release (corresponding to Q.921 DL-RELEASE) Messages used for the transport of Q.931 messages as data: " Data (corresponding to Q.921 DL-DATA)

D10.3.4 SCTP
See section D1.2.3 on page 235 for information about SCTP.

Page

331

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

332

Chapter D11 V5UA

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

Figure 80 illustrates the protocol stacks used in supporting V5.2 access to a backbone packet network.
V5.2 Access 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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

334

Chapter D11 V5UA

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D11 V5UA

D11.3 Interface Characteristics


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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

336

Chapter D11 V5UA

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

338

Chapter D12 MTP Adaptation Protocols

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

D12.2 Network Role


Unlike the packet network protocols described in other Part D chapters, both M3UA and M2PA are supported by the CS2000 Universal Signalling Point (USP) rather than by GWCs. M3UA is used to support intra-CS2000 signalling over the CS LAN, especially signalling between the Core and the USP; direct signalling between the USP and GWCs is also supported. M2PA is used to support TCAP NCAS (Non Call Associated Signalling) with remote CS2000s across the backbone packet network. Note: TCAP NCAS over the packet network is not supported by the Compact version of the USP. Figure 83 illustrates USP support for CCS7 signalling via M3UA and M2PA.
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

TCAP SCCP Conventional CCS7 signalling network

CS LAN

DPT GWC

Sessioin Server or VRDN

SIP-T SIP-T
ISUP SDP TUP SDP

IP control network over backbone packet network

TCP or UDP IP
See section B1.4.5.3 on page 62 for information about DPT GWC interaction with Session Server or VRDN

Figure 83: USP support for CCS7 signalling

Page

339

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D12 MTP Adaptation Protocols

D12.3 Interface Characteristics


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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

340

Chapter D12 MTP Adaptation Protocols

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

responsibility of the M2PA layer to maintain a map of each of its CCS7 links to the corresponding SCTP association. CS2000 use of M2PA to support NCAS supersedes its use of M2UA (MTP Layer 2 User Adaptation) for this purpose in releases prior to ISN07. Note: TCAP NCAS over the packet network is not supported by the Compact version of the USP. M2PA is a general-purpose mechanism for conveying CCS7 signalling over an IP network between IP Signalling Points (IPSPs). It is therefore potentially capable of supporting ISUP or TUP signalling between CS2000s over MTP3 / M2PA / SCTP / IP, but this capability is not used by the CS2000 international product. Inter-CS signalling via ISUP and TUP is instead supported by DPT GWCs and Session Servers using SIP-T encapsulation of CCS7 user part messages, as described in Chapter D2: SIP and SIP-T. The primitives provided by M2PA for communication with MTP Layer 3 are the same as those provided by MTP2 for MTP3. The most important of these are: ! Primitives sent from MTP3 to M2PA:
" " "

Data Request Used to send a Data Message for transmission. Start Request Used to activate a link. Stop Request Used to deactivate a link.

Primitives sent from M2PA to MTP3: " Data Indication Used to deliver received Data Message to MTP3.

Only two messages are defined for peer-to-peer messaging at the M2PA layer: ! User Data messages convey data received by the M2PA layer from MTP3. Specifically, they contain the following fields of the MTP MSU: " Length Indicator (LI), including the two undefined bits between the SIO and LI fields Note: M2PA does not actually require message length information as MTP2 does. The LI octet is included because the two spare bits in the LI octet are used by some national CCS7 variants to carry MTP3 information.
"

Service Information Octet (SIO) " Signaling Information Field (SIF) M2PA User Data messages do not convey other components of the MTP MSU. In particular, they do not convey MTP3 sequence numbering data, because M2PA message headers contain a Forward Sequence Number (FSN) and Backward Sequence Number (BSN) assigned at the M2PA layer. ! Link Status messages are sent between M2PA peers to indicate link status, thus performing a function similar to that of MTP2 Link Status Signal Units (LSSU).

Page

341

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

342

Chapter D13 DSM-CC

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

D13.2 Network Role


CS2000 uses the CVX1800 media gateway described in section B2.11 on page 130 to provide Universal Port (UP) capability. This means supporting RAS (Remote Access Service) as well as VoIP voice calls. RAS means support for dial-up access to internet and/or intranet sessions. Note: CS2000 support for Universal Port capabilities has been tested and verified for deployment only in a specific customer network, and is not generally available in ISN07. 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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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)

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

344

Chapter D13 DSM-CC

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

Client Connect Messages Note: Not supported for CS2000 solutions. ClientConnectRequest ClientConnectConfirm Client Status Messages Note: Not supported for CS2000 solutions. ClientStatusIndication ClientStatusResponse

D13.4 Co-Ordination between DSM-CC and CCS7 Signalling


The following list summarises the use of DSM-CC messages in session initiation and sesion termination, illustrating the co-ordination betwen DSM-CC and CCS7 signalling: ! Session initiation 1 When an incoming IAM is received by CS2000 for an incoming CCS7 trunk terminated on a CVX1800, the CS2000 GWC sends the CVX1800 gateway a DSM-CC CSSI (Client Session Setup Indication) command, requesting the gateway to initiate a session with a specified packet network destination (IP address and port number). For a VoIP call, the destination will be a terminating media gateway. For a RAS call, the destination will be a remote internet or intranet server accessible via the packet network. 2 The CVX1800 responds to the CSSI by sending a DSM-CC CSSR (Client Session Setup Response) command back to the CS2000 GWC. 3 CS2000 responds to the CSSR by sending back an ACM and ANM over the incoming CCS7 trunk on which the call originated. Session termination 1 When an incoming REL is received by CS2000 for an incoming CVX1800 CCS7 trunk on which there is an active call, CS2000 responds by sending back an immediate RLC to complete call clearing. 2 The CS2000 GWC then sends the CVX1800 gateway a DSM-CC CRI (Client Release Indication) command, requesting the gateway to terminate the current session with the terminating media gateway or remote server. 3 The CVX1800 responds to the CRI by terminating the session and sending a DSM-CC CRR (Client Release Response) command back to the CS2000 GWC.

Page

345

Nortel Networks

PROPRIETARY

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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

Issue ISN07_v3 (approved) 17 August 2004

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

347

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

348

Chapter D14 OAM&P Protocols

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

Figure 85 illustrates the network role of SNMP and the SNMP DPI. Communication between the GWC, the GWC EM server application, and the GWC EM client is used as an example, but the same configuration and principles apply to the management of other network elements.
SNMP 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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D14 OAM&P Protocols

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

350

Chapter D14 OAM&P Protocols

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D14 OAM&P Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

352

Chapter D14 OAM&P Protocols

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Part D Communication Server Capabilities Packet Telephony Protocols

Chapter D14 OAM&P Protocols

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

354

Chapter D14 OAM&P Protocols

Part D CS2000 International Product Description Packet Telephony Protocols Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

Part E Telephony Interfaces

Chapter E1 Overview

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part E Telephony Interfaces

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

358

Chapter E1 Overview

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

"

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part E Telephony Interfaces

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

360

Chapter E1 Overview

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part E Telephony Interfaces

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

362

Chapter E1 Overview

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part E Telephony Interfaces

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

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

364

Chapter E1 Overview

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part E Telephony Interfaces

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

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

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

Media control signalling H.248/lASPEN (SDP) UDP IP

Media control signalling H.248/lASPEN (SDP) UDP 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:
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)

Figure 87: PRI-to-PRI call between two gateways controlled by the same CS2000

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

366

Chapter E1 Overview

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

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

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

Media control signalling H.248/lASPEN (SDP) UDP 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:
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

Issue ISN07_v3 (approved) 17 August 2004

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.
Issue ISN07_v3 (approved) 17 August 2004 PROPRIETARY Page

Nortel Networks

368

Chapter E2 CCS7 Interfaces

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

Figure 90 illustrates the mapping of CCS7 parts on to the OSI 7-layer model. Brief descriptions of the functions of each part are provided on the following pages. OSI 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

Issue ISN07_v3 (approved) 17 August 2004

CTUP in China

TCAP

Different user parts

ITU/ ETSI TCAP

IBN7 TCAP

national variants of ETSI ISUP V3

ETSI ISUP V1 (Blue Book)

CS2000 International Product Description Communication Server Capabilities

Part E Telephony Interfaces

Chapter E2 CCS7 Interfaces

CCS7 parts and their functions can be categorised as follows: ! CCS7 parts that interact directly with users or applications at the top of the protocol stack. These are:
"

The Telephony User Part (TUP), which supports basic call. CS2000 support for TUP is described in section E2.4 on page 406. " The ISDN User Part (ISUP), which supports basic call and call-related supplementary services. CS2000 support for ISUP is described in section E2.3 on page 381. " The Intelligent Network Application Part (INAP), which supports circuit-independent database queries. CS2000 support for INAP is separately described in Chapter E3: INAP. Note: For some services, the Transaction Capabilities Application Part (TCAP) that underlies INAP interacts directly with service logic by means of service-specific application contexts and operations. ! CCS7 parts that support peer-to-peer comunication at lower levels of the protocol stack. These are: " The Message Transfer Part (MTP), which provides generic message-handling capabilities both for telephony calls and for database queries. " The Signalling Connection Control Part (SCCP), which supports call routing for database queries. " The Transaction Capabilities Application Part (TCAP), which provides support for non-call-associated services such as Call Completion to Busy Subscriber (CCBS). TCAP is also used to convey INAP (Intelligent Network Application Part) signalling, which is used to support IN services via circuit-independent database queries to an SCP. CS2000 support for MTP, SCCP and TCAP is described in section E2.5 on page 416.

Note: For CCS7 calls across the packet network between peer Communication Servers, circuit-based MTP capabilities are not used. Instead, circuit-oriented ISUP and TUP signalling is conveyed encapsulated in SIP-T messages, while TCAP NCAS (Non Call Associated Signalling) is conveyed by means of M2PA (MTP2-User Peer-to-Peer Adaptation).

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

370

Chapter E2 CCS7 Interfaces

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part E Telephony Interfaces

Chapter E2 CCS7 Interfaces

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

372

Chapter E2 CCS7 Interfaces

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

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

TCAP SCCP Conventional CCS7 signalling network

USP
3

CS LAN DPT GWC Session Server or VRDN

TCAP SCCP MTP3 M2PA SCTP IP 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

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

Issue ISN07_v3 (approved) 17 August 2004

CS2000 International Product Description Communication Server Capabilities

Part E Telephony Interfaces

Chapter E2 CCS7 Interfaces

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.

Issue ISN07_v3 (approved) 17 August 2004

Nortel Networks

PROPRIETARY

Page

374

Chapter E2 CCS7 Interfaces

Part E Telephony Interfaces

CS2000 International Product Description Communication Server Capabilities

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 me