Solution Overview - Willow Eaton Cherrywillowcherry.com/wp-content/uploads/2013/12/411-2231-014.02.07.pdf · Solution Overview GSM18/MGW18 ... Figure 4-7 MF signaling ... Table 7-2

411-2231-014

GSM / UMTS

R4 MSCSolution Overview

GSM18/MGW18 Standard 02.07 May 2006

test

GSM / UMTS


Document number: 411-2231-014Product release: GSM18/MGW18Document version: Standard 02.07 Date: May 2006

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright © 2003–2006 Nortel Networks, All Rights Reserved

Originated in the United States of America

NORTEL NETWORKS CONFIDENTIAL

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

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

* Nortel Networks, the Nortel Networks logo, the Globemark HOW the WORLD SHARES IDEAS, and Unified Networks are trademarks of Nortel Networks. DMS, DMS-HLR, DMS-MSC, MAP, and SuperNode are trademarks of Nortel Networks. GSM is a trademark of GSM MOU Association. Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.

iiNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

411-2231-014 Standard 02.07 May 2006

iiiNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

Publication historyMay 2006

GSM18/MGW18, Standard, 02.07.

February 2006

GSM18/MGW18, Preliminary, 02.06.

October 2005


October 2005


September 2005

GSM18/MGW18, Draft, 02.03.

February 2005


December 2004


October 2004

GSM17/MGW17, Standard, 01.11.

September 2004

GSM17/MGW17, Standard, 01.10. This release includes the addition of review comments.

August 2004

GSM17/MGW17, Standard, 01.09. This release includes updates to the information on Media Gateways and BICC functionality.

GSM / UMTS R4 MSC Solution Overview GSM18/MGW18

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

April 2004

GSM17/MGW17, Preliminary, 01.08. This release includes updates to the information on Media Gateways and BICC functionality.

February 2004

GSM17/MGW17, Standard, 01.07. This release includes updates to the information on Media Gateways.

November 2003

GSM17/MGW17, Preliminary, 01.06. This release includes the additional information on trunk state transitions and restrictions and limitations.

October 2003

GSM17/MGW17, Preliminary, 01.05. This release includes the addition of GSM ANSI Bearer Independent Call Control (BICC) functionality and review comments.

September 2003

GSM17/MGW17, Preliminary, 01.04. This release includes the addition of review comments.

July 2003

GSM17/MGW17, Preliminary, 01.03. This release includes the addition of review comments.

June 2003


May 2003

GSM17/MGW17, Draft, 01.01. This is the first release of this document.

411-2231-014 Standard 02.07 May 2006

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

Contents 1

About this document ixAudience for this document ixOrganization of this document ix

Indication of hypertext links xSoftware release applicability x

GSM18/UMTS04 product computing module loads xRelated documents xi

Solution overview 1-1Restrictions and limitations 1-3

Solution components 2-1(G)MSC switch + server 2-1

XACore 2-1Message switch 2-2Enhanced network 2-2Digital trunk controller 2-2Spectrum peripheral module 2-3(C)ISME and components 2-3(F)LPP 2-3Ethernet routing switch 8600 2-5USP 2-6Multi-service switch 7000 2-8GPP IWF 2-8

Media gateway 2-10MGW personalities 2-11MGW hardware 2-13

Aggregation node 2-14Connection fabric interworking function 2-15Optera metro 3500/4200 2-16OA&M components 2-17

Core element manager 2-19Network services platform 2-203GPP FM building block 2-213GPP PM XML data interface 2-21System management 2-21Supernode data manager 2-21Core billing manager 2-22Multi-service data manager 2-22Multi-service data provider 2-23Audio provisioning server 2-23

Packet network 3-1CO LAN/router 3-1

IP routing 3-1


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

Interconnectivity 3-3MSS virtual routers 3-3IP addresses and subnets 3-4

Ethernet routing switch 8600 3-5XACore 3-7GPP IWF 3-10USP 3-10MSS 15000 3-10MSS 7000 3-13SDM/FT 3-13CBM 3-13CEM server 3-14W-NMS main server 3-14W-NMS performance server 3-15Core network subnet summary 3-15

ATM core network 3-16ATM routing via PNNI 3-17ATM addressing and connections 3-17ATM service categories 3-18ATM network recommendations 3-19

Quality of service 3-19QoS in UMTS access networks 3-19QoS in the CO LAN/router 3-19QoS in ATM core networks 3-20

Signaling protocols 4-1SS7 signaling 4-1

GSM A-interface 4-1UMTS Iu-CS' (non-BICN) interface 4-3UMTS Iu-CS interface 4-4ISUP 4-5BICC 4-6D-channel based protocols 4-6CAS 4-6MAP 4-8

Mc interface protocols 4-9Application level framing 4-10

MIP 4-10User plane signaling protocols 4-11

Q.2630 4-11Iu/Nb UP 4-12

Services 5-1Supplementary services 5-1Tones 5-3

Out of band DTMF 5-3Announcements 5-5Circuit switched data 5-5Conferencing 5-11Lawful Intercept 5-14

411-2231-014 Standard 02.07 May 2006

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

Global text telephony 5-17

OAM&P 6-1FCAPS strategy 6-1

Fault management 6-1Configuration management 6-4Performance management 6-4Accounting management 6-5Security management 6-5

Provisioning walkthroughs 6-5System-level 6-5Trunk provisioning 6-6

OSS Interfaces 6-6

Scalability and capacity 7-1Scalability 7-1

(G)MSC server 7-1MSS 15000 7-2MSS 7000 7-2Ethernet routing switch 8600 7-3USP 7-3

Capacity 7-4(G)MSC server 7-4Media gateway 7-4USP capacity 7-6OA&M components 7-10

Security 8-1User security 8-1Security protocols 8-1Firewalls 8-1Ethernet routing switch 8600 filtering 8-1

List of terms and definitions A-1

Figures Figure 1-1 3GPP BICN reference architecture 1-1Figure 1-2 VoAAL2 BICN detailed network architecture 1-2Figure 2-1 GPP IWF connectivity (centralized/baseline configuration 2-10Figure 2-2 CFIWF components and bearer path 2-16Figure 2-3 Standalone CEM server OA&M component connectivity 2-18Figure 2-4 W-NMS OA&M component connectivity 2-19Figure 3-1 ERS 8600 VLAN example 3-6Figure 3-2 Table CMIPADDR example 3-9Figure 4-1 BSSAP signaling path - AAL1 CES backhaul 4-2Figure 4-2 BSSAP signaling path - M2UA backhaul for ATM CN 4-3Figure 4-3 PER-decoded RANAP signaling path 4-4Figure 4-4 RANAP signaling path - M2UA backhaul for ATM CN 4-5Figure 4-5 ISUP quasi associated signaling path 4-6Figure 4-6 MF signaling - AAL1 CES 4-7


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

Figure 4-7 MF signaling - H.248 control in ATM core network 4-7Figure 4-8 MAP signaling 4-8Figure 4-9 CAP signaling 4-9Figure 4-10 H.248 signaling path - ATM CN 4-9Figure 4-11 MIP signaling path prior to CSD migration 4-10Figure 4-12 MIP signaling path after CSD migration 4-11Figure 4-13 Q.2630 signaling path (F-links) 4-12Figure 4-14 Q.2630 signaling path (A-links and STP) 4-12Figure 5-1 Out of band DTMF via BICC 5-4Figure 5-2 Out of band DTMF with G.711 on Nb 5-4Figure 5-3 CSD architecture with DTC-hosted GPP IWF 5-6Figure 5-4 CSD architecture with MGW-hosted GPP IWF 5-7Figure 5-5 Remote GPP IWF and MIP over ATM 5-8Figure 5-6 Alternating between speech and data/fax 5-10Figure 5-7 Conferencing architecture with CTMs 5-12Figure 5-8 Conferencing-capable MGW architecture 5-13Figure 5-9 Architecture with ENET tapping 5-15Figure 5-10 LI architecture with MGW tapping - separate CCC 5-16Figure 5-11 LI architecture with MGW tapping - combined CCC 5-17Figure 5-12 UMTS BICN support for CTM 5-18Figure 5-13 GSM BICN support for CTM 5-18Figure 6-1 Standalone CEM fault management architecture 6-2Figure 6-2 W-NMS fault management architecture 6-3

Tables Table 2-1 Standalone CEM OA&M hardware platforms 2-17Table 2-2 W-NMS OA&M hardware platforms 2-17Table 2-3 Common OA&M hardware platforms 2-18Table 3-1 Layer 1-3 interconnectivity 3-3Table 3-2 Subnet summary 3-15Table 5-1 Common supplementary services supported in BICNs 5-1Table 5-2 Supported GSM CSD bearer services 5-8Table 5-3 Supported UMTS CSD bearer services requiring IWF 5-10Table 5-4 Supported UMTS CSD bearer services not requiring IWF 5-11Table 7-1 (G)MSC Server Component Scalability 7-1Table 7-2 MSS 15000 Component Scalability 7-2Table 7-3 MSS 7000 Component Scalability 7-2Table 7-4 ERS 8600 Component Scalability 7-3Table 7-5 USP Component Scalability 7-3Table 7-6 MG18 I/O Capacities 7-4Table 7-7 LI targets per 4pVSP4e 7-5Table 7-8 SS7 message throughput (@56kbps) 7-7Table 7-9 SS7 message throughput (@64kbps) 7-7Table 7-10 Link system node MSUs at maximum engineering rate (on 56kbps

link) 7-8Table 7-11 Link system node MSUs at maximum engineering rate (on 64kbps

link) 7-8Table 7-12 DS0A equivalencies for ATM HSLs 7-9Table 7-13 DS0A equivalencies for IP HSLs 7-9

411-2231-014 Standard 02.07 May 2006

ixNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

About this document 2This publication describes the nature and characteristics of Nortel’s R4 solution for the evolution of the Core Networks within both GSM and UMTS. 3GPP R4 is a solution to eliminate inefficient bearer resource usage. Nortel’s R4 solution is based on the Bearer Independent Core Network (BICN) which separates the node that handles bearer function (Media Gateway) from the one that handles the call control function (Call Server).

Audience for this document 2This document is intended for Nortel’s external customers. It is assumed that the reader has a general familiarity with the 3GPP UMTS Release 99 (R99) and Release 4 (R4) networks and standards. In many cases in this document, references will be made to external documents rather than duplicating or paraphrasing the information in line—in order to prevent the introduction or propagation of errors.

Organization of this document 2This section provides a brief overview of this guide. Each major section of the document is described below:

• Chapter 1, “Solution overview” covers the basics of Nortel’s R4 solution.

• Chapter 2, “Solution components” describes the different hardware components.

• Chapter 3, “Packet network” describes the details and recommendations for the packet network(s).

• Chapter 4, “Signaling protocols” describes the different signaling protocols and interfaces.

• Chapter 5, “Services” provides basic information on the different GSM/UMTS services and their implementation in a BICN architecture.

• Chapter 6, “OAM&P” provides general information about the FCAPS strategy and OSS interfaces.

• Chapter 7, “Scalability and capacity” contains scalability and capacity information for different R4 solution components.


x About this documentNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

• Chapter 8, “Security” provides basic information on the various security aspects included in Nortel’s R4 solution.

Indication of hypertext linksHypertext links in this document are indicated in blue. If viewing a PDF version of this document, click on the blue text to jump to the associated section or page.

Software release applicability 2Nortel software releases for the Wireless product are developed and identified by the product lines. GSM product lines software is identified by the letters GSM and a two-digit number, such as GSM18, signifying the current release in the GSM software stream.

This documentation is applicable to the DMS-MSC Family offices that have the NSS18/MG18 software release. Unless this publication is revised, it also applies to offices that have software releases greater than GSM18/UMTS04.

GSM18/UMTS04 product computing module loadsThe NSS18 software load consists of GSM18 (MSC & HLR), GEM18 (SDM & CEM), and MG18 (Media Gateway) software.

Before GSM05, software loads were package-based loads. GSM05 was the first DMS-MSC Product Computing Module Load (PCL). PCLs are composed of layers of software, or Delivery Receivable Units (DRUs). The NSS18 software load is comprised of the following PCLs:

• DMS CSP20 (BASE21, TL20, SHR20)

• XPM20

• CBM18

ATTENTION:During the installation of the Audio Provisioning Server, the SSPFS Base gives the user the following statement regarding the license agreement:

“This CD contains software that under the terms of your license agreement with Nortel is licensed for use only on Succession OAM & P.

This statement is incorrect. Instead, the following statement is accurate:

“This CD contains software that under the terms of your license agreement with Nortel is licensed for use only on Nortel OAM&P servers.”

411-2231-014 Standard 02.07 May 2006

About this document xiNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

• USP10.0

• SN07

• Passport v3.7• SP21 (North America market)• SP17.2 (International market)• Media Gateway (MG) PCR6.1• GSM18/UMTS04 DRUs

Related documents 2NTP 411-2231-330, R4 Media Gateway Operations and Reference Guide

NTP 411-2231-331, R4 Media Gateway OAM and Troubleshooting Guide

Some publications of the DMS-100 Family contain information that may relate to the subjects in this publication. For current listing of DMS-100 NTPs, refer to 297-8991-001, DMS-10 and DMS-100 Product Documentation Directory.


xii About this documentNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

411-2231-014 Standard 02.07 May 2006

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

Solution overview 1The NSS17/MG17 BICN solution introduced a new distributed architecture as a step towards full implementation of the 3GPP BICN reference architecture, introduced in the 3GPP Release 4 specifications and carried forward in subsequent 3GPP releases. The BICN reference architecture is shown in the following diagram.

Figure 1-1 3GPP BICN reference architecture

However, the initial BICN release was limited in scope. The NSS18 release expands the scope of Nortel's GSM/UMTS BICN product with the introduction of the following:

• Support for the VSP platform (4pVSP4e)

• R4 Core Network support for UMTS access

• Packetized bearer between (G)MSC Servers (i.e. support of the Nc and Nb interfaces)


1-2 Solution overviewNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

• Core Network support of voice compression

• Support for MGW-based services (conferencing, lawful intercept replication, circuit switched data trunks)

• Support for a signaling platform (USP) which provides a wide suite of signaling transport options

• Support for the ETSI market

The following diagram shows a system-level view of this solution and its main components.

Figure 1-2 VoAAL2 BICN detailed network architecture

There is a degree of flexibility in the network components used for different functions. For example, operators could use only SPMs, only (P)DTCs or a combination of the two (as shown above). Each provides TDM trunking facilities, but on different physical facilities and with slightly different capabilities. The placement of MUXes in the network depends on how each peripheral is used. MUXes are supported between the MGWs and peer nodes that support only electrical T1 interfaces. Also, some of the components

411-2231-014 Standard 02.07 May 2006

Solution overview 1-3Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

shown above are mutually exclusive with other components, and thus will not coexist.

Restrictions and limitations 1The following are critical solution-level restrictions and limitations:

1. PRI trunks require legacy TDM PMs.

2. PTS trunks (other than MF Type 2C and POI-T8) require legacy TDM PMs.

3. The Mc interface is not open and does not support multi-vendor interoperability.

4. CAMEL and CS-1R Intelligent Peripherals (IPs) are interconnected via TDM ports on DTCs/SPMs or on MGWs - no direct packet connections are supported.

5. Test trunks (e.g. T10x) are not supported on MGW-based trunks.

6. CSD is not supported "in-skin". This will continue to be handled by the GPP IWF which hangs off MGW-based TDM trunks.

7. NSS18 is the last software release for which Periphonics VSP Platform is supported as CAMEL Intelligent Peripheral (IP) node.

8. NSS18 is the last supported release for SDM.

9. NSS18 is the last supported release for standalone CEM.


1-4 Solution overviewNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

411-2231-014 Standard 02.07 May 2006


Solution components 2(G)MSC switch + server 2

The (G)MSC Switch + Server is a functional entity that combines the roles of the legacy (G)MSC Switch and the (G)MSC Server. The (G)MSC Switch + Server comprises the call control and mobility control functions. It remains integrated with a VLR to hold the mobile subscriber's service data and CAMEL related data. It provides the signaling interface to the mobile access network (BSS or UTRAN), peer MSCs, the HLR, SCPs and the PSTN/PLMN.

The difference in Switch vs. Server functionality lies in how the bearer path is managed and where it is located.

• (G)MSC Switch - maintains the ability to switch calls through the legacy PMs and internal TDM switching fabric (ENET). This is done for calls using incoming/outgoing trunks that terminate on PMs or that require special treatment that is only supported in the PMs or ENET.

• (G)MSC Server - adds the ability to manage a distributed packet bearer network. Specifically, the (G)MSC Server controls Media Gateways (MGWs) via H.248 signaling to switch the bearer. The bearer path for these calls no longer has to traverse the internal TDM switching fabric (ENET).

The (G)MSC Switch + Server simultaneously supports both functions, which is the likely configuration during a migration to the BICN architecture. In some scenarios, a single call will traverse both the MGW and the ENET.

The (G)MSC Switch + Server is made up of a number of physical nodes that are discussed below.

XACoreThe main call processing component of the (G)MSC Server is the eXtended Architecture Core (XACore).


2-2 Solution componentsNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

From a hardware perspective, the XACore shelf is made up of the following main components:

• Shared Memory (SM)

• Processing Elements (PEs)

• Input/Output Processors (IOPs)

— High Performance IOPs (HIOPs) - The HIOPs host a 100bT ethernet port for the purpose of providing IP connectivity for the XACore.

— High Performance Computing Module Interface Card (HCMIC) - The HCMIC hosts one 100bT ethernet port, two CMIC ports and two RS232/CL Serial I/F Packlet (RTIF) ports.

A maximum of only two Ethernet links can be active at any given time. The XACore treats all of these Ethernet links equally and makes no distinction between HIOP vs. HCMIC when links are brought into service or when activity switches from one link to another.

The XACore software structuring for this release is as follows:

• NSS18 + CSP20 (TL20 + BAS21)

Message switchThe Message Switch (MS), also known as the DMS Bus, is a high-speed transaction bus that provides message transport functions for the distributed processors. The MS supports control messaging between the XACore and all peripherals (PMs, FLPPs, SDM, etc.).

Enhanced networkThe Enhanced Network (ENET) plays a legacy role as a TDM switch for bearer at the (G)MSC Switch. The ENET is not involved in (G)MSC Server calls as this role is played by the MGWs and the packet network. An exception to this is hybrid calls that require the insertion of a Connection Fabric InterWorking Function (CFIWF).

The ENET also plays a role for channelized CCS7 signaling at the (G)MSC Server for signaling links supported by the LIU7. Channelized CCS7 signaling backhauled from the MGWs to the (G)MSC Server site via AAL1 CES can still be sent to/from the LIU7s via the SPM/ENET/NIUs.

As (P)DTC/SPM ports as well as CTM functionality are migrated to MGWs, fewer ENET ports will be required.

Digital trunk controllerThe Digital Trunk Controller (DTC) family of products support different densities of electrical T1 or E1 carriers capable of carrying a voice channel or signaling. However, (P)DTCs are supported and can be used to present an

411-2231-014 Standard 02.07 May 2006

Solution components 2-3Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

electrical (T1) trunking interface. Additionally, DTCs provide a means of supporting MF trunks and GPP IWF connectivity, although both of these functions are also supported by the MGW in this release and are expected to migrate there. DTCs also support PRI trunks.

Spectrum peripheral moduleThe Spectrum Peripheral Module (SPM) provides an evolution from the DTC for footprint and power improvements. The SPM also provides a 1+1 redundant optical carrier (OC-3 or STM-1) trunking interface for the (G)MSC Switch. The individual DS0s from the optical carrier are then fed directly to the ENET via a DS-512 interface. SPMs are installed in a dual-shelf configuration, which allow for two SPMs per frame.

A MUX must be used to convert the OC-3/STM-1 trunking interface of the SPM to an electrical (T1/E1) interface wherever this is required (e.g. BSS, IWF, and PSTN). The SPM does not support connectivity to GPP IWFs, this requires a (P)DTC or a MGW.

(C)ISME and componentsCabinetized Integrated Services Module Equipment (CISME) cabinets hold components that are used for trunk testing and maintenance, tone generation, announcements, conferencing, alarms, I/O and data storage/retrieval.

Note: Some functions of the CISME components are also supported on the MGW (e.g. conferencing).

(F)LPPThe Link Peripheral Processor (LPP) or Fiberized Link Peripheral Processor (FLPP) is a cabinet that hosts a number of functions for the (G)MSC Switch + Server.

Some (F)LPP functions (LIU7 and NIU) are potentially migrated to other network elements in this release (USP and Multi-Service Switch 7000 respectively). The LIU7 and USP cannot coexist as an SS7 signaling interface except during the cutover window. Once all SS7 interfaces have migrated to the USP, the (F)LPP may only contain MMUs and EIUs.

The different Application Specific Units (ASUs) hosted by (F)LPP are the following:

• Link Interface Unit #7 (LIU7)

• Mobility Management Unit (MMU)

• Ethernet Interface Unit (EIU)

• Network Interface Unit (NIU)



LIU7LIU7s provide connectivity to the SS7 network. Each Link LIU7 provides a single link to the SS7 network. The (F)LPP supports Low Speed Links (LSLs); High Speed Links (HSLs) are not supported.

There are two main types of Link LIU7s:

• Basic LIU7s, which support quasi-associated signaling. Up to 12 Basic LIU7s can be configured per LIS.

• Channelized LIU7s, which support facility-associated signaling. Up to 10 Channelized LIU7s can be configured per LIS (two NIUs per LIS are required to support channelized signaling).

LIU7s take on added functionality for BICN calls, specifically the responsibility for ISUP and BICC overload controls and message routing enhancements to allow direct FTS messaging to the Core.

GSM NSS18 introduces the USP as an evolved signaling platform to optionally replace the LIU7s. The LIU7s continue to support some, but not all, NSS18 BICN configurations. Specifically, LIU7s must be replaced by the USP in order to support either of the following functionalities:

• UMTS access at the MGW (i.e. "UMTS BICN")

• ATM or IP HSLs

The USP and LIU7s can only coexist during the cutover period.

Note: The USP must be used as the SS7 interface for new (G)MSCs.

MMUThe Mobility Management Unit (MMU) is a FLPP ASU that allows the (G)MSC Switch + Server to achieve scalable mobility management. Mobility management and VLR functionality can run on the MMU which off loads significant processing from the XACore. Up to 14 MMUs can be installed per (G)MSC Switch + Server. Once the USP has replaced LIU7s as the SS7 signaling interface, all MMUs can be placed into a single FLPP frame.

EIUThe Ethernet Interface Unit (EIU) provides a single 10bT Ethernet link used for MIP signaling to the GSM on Passport Interworking Function (GPP IWF), which handles circuit switched data (CSD). EIU-based signaling to the GPP IWF is only valid for GPP IWFs that are connected to DTCs. Prior to migrating GPP IWF connectivity to the MGWs, MIP signaling must be migrated to the HIOPs/HCMICs. Once this is done, EIUs can be decommissioned and removed.

411-2231-014 Standard 02.07 May 2006


NIUThe Network Interface Unit (NIU) is an FLPP ASU that is used in conjunction with channelized LIU7s to provide channelized CCS7 access. This allows the LIU7 to send/receive CCS7 signaling via DS0s from the DTC/SPM and ENET. NIUs are deployed in pairs for redundancy. Each (F)LIS shelf can have at most two NIUs. The NIU and ENET have a DS30 connection between them.

The NIU is not used for signaling links terminated on the USP, so any operators that migrate their signaling from LIU7s to the USP will be able to decommission their NIUs.

Ethernet routing switch 8600The Central Office (CO) requires a carrier grade switch/router function for a number of reasons:

• To switch and/or route signaling traffic between the numerous components in the CO which must communicate with each other. Different operators will have different routing requirements, thus this function must be flexible and provide a rich suite of capabilities.

• To provide the ability to detect and gracefully route around failures in the network and in the components connected to the LAN.

• To provide the ability to segregate different types of traffic via techniques such as VLANs or subnetting.

This CO LAN/router functionality is provided by dual Ethernet Routing Switch 8600s.

The supported modules of the ERS 8600 are:

• 8691SF CPU/Switching Fabric module - This card is the heart of the ERS 8600, providing the core switching fabric, a CPU subsystem and a real-time clock. The core switching fabric is used to switch all traffic through the other modules. The CPU subsystem manages the switching fabric and all other I/O modules.

• I/O modules - These cards provide 10/100bT Ethernet interfaces, Gigabit Ethernet interfaces, or a combination of the two. The number and type of I/O modules depends on the connectivity requirements of the system.

This ERS 8600 configuration supports the storage of 32,000 records, where a record can include:

• a MAC (Media Access Control) entry

• a VLAN (Virtual Local Area Network) entry

• a multicast entry

• an ARP (Address Resolution Protocol) entry



• An IP route entry

• An IP filter rule

• An IPX (Internetwork Packet Exchange) network entry

The following is a list of NEs that could require one or more 10/100bT terminations on the ERS 8600s:

• XACore HIOPs and/or HCMICs

• USP PSE TMs (used with RTCs, IPS7 Gateway Nodes and IP HSLs)

• Local MSS 7000 and 15000 CP3 cards

• Local MSS 15000 2p GP Dsk cards

• Local GPP IWFs

• SDM/FT or CBM

• Any other local OA&M equipment

For ATM Core Networks, the ERS 8600 provides 10/100bT Ethernet links to a MSS 15000 Aggregation Node, which in turn provides the ATM WAN interface.

This release uses ERS 8600 software version 3.7.6.

USPThe Universal Signaling Point (USP) provides the platform upon which Nortel's next generation of signaling applications are based. This release provides support for migrating SS7 access from the (F)LPP (LIU7, NIU) to the USP. The LIU7 and USP cannot coexist as an SS7 signaling interface except during the migration window.

The USP provides two main functions for the BICN network:

• Signaling Gateway (SG) - In this configuration, the USP replaces the LIU7s and provides the SS7 interface(s) for the (G)MSC Server.

• STP (Signaling Transfer Point) - In this configuration, the USP performs SS7 message routing.

A single USP can provide both SG and STP functionalities as long as different point codes are used.

The USP uses a shelf structure that can host a number of different types of System Nodes:

• CAM Controllers (CCs) System Node - These nodes provide dual internal ATM planes to each CAM shelf, facilitating SS7 and OAM&P data transfer between the cards. The CC System Node also distributes the

411-2231-014 Standard 02.07 May 2006


composite clock to all SS7 Link Nodes on the CAM shelf. Each CAM shelf has two CC System Nodes.

• Real-Time Controllers (RTCs) System Node - These nodes provide system boot/recovery/maintenance for of all resident CAM shelf cards. They also provide log, alarm, OM and HMI management. Two RTC System Nodes are required in the CAM Control shelf in an active/standby configuration. Both RTC System Nodes simultaneously process each event and store a complete record of all USP system data for redundancy purposes.

• SS7 Link Nodes - These nodes provide the SS7 interface(s) on behalf of the MSC. The USP supports a maximum of 126 SS7 Link Nodes, although only a total of 512 SS7 links is supported. The following SS7 Link Node types are supported:

— Narrowband SS7 (MTP3) V.35 links

— Narrowband SS7 (MTP3) on channelized E1/T1 links

— Narrowband SS7 (MTP3) DS0A

— Narrowband SS7 (MTP3) on ATM HSLs (on E1/T1)

— Broadband SS7 (MTP3b) on ATM HSLs (on E1/T1)

— M2UA IP HSLs

— M3UA IP HSLs

• IPS7 Gateway Nodes - These nodes provide the interface between the USP and XACore (via the ERS 8600 or equivalent CO LAN/router). All SS7 signaling between the XACore and USP traverses an IPS7 Gateway Node, regardless of the actual SS7 Link Node type the message is received from or sent to. These nodes are applicable only to USPs playing a SG role. The USP supports a maximum of 16 IPS7 Gateway Nodes.

A number of other components might also be required with the USP:

• E1 Timing Signal Generator (TSG) - This component derives the required independent primary and secondary composite clock outputs from an E1 signal reference and feeds these to the two CAM Controllers in each CAM Shelf. The TSG can be used for the following SS7 Link Nodes:

— Channelized E1

— E1 MTP2 High Speed Link (HSL)

• Balun Converter - This line and impedance converter is required for European markets requiring coax cabling terminations.

• Remote Access Server (RAS) - The RAS provides a direct dial interface to the USP for the purposes of technical support and assistance. The recommended RAS is the Contivity 600 in order to align with the HLR 200 product, although the Contivity 100 and 1100 are also supported.



This release uses USP software version USP10.

Multi-service switch 7000The Multi-Service Switch (MSS) 7000, formerly known as Passport 7000 provides DS0 grooming and ATM Interface MUX.

This release uses software version PCR6.1.

DS0 GroomingWhen the LIU7 is replaced by the USP, the MSS 7000 can be used to strip signaling timeslots from T1/E1 carriers carrying bearer so that they can be sent to the USP with up to eight DS0s of signaling per T1/E1. This function is referred to as DS0 grooming.

DS0 grooming is required from the time an operator moves the first channelized signaling link from the LIU7 to the USP up until the time that all channelized and Iu-CS signaling is entering a 4pVSP4e (and thus using M2UA signaling backhaul to reach the USP).

ATM interface MUXThe MSS 7000 performs ATM switching between electrical (T1/E1) and optical (OC-3/STM-1) interfaces if the USP is acting as a broadband STP for ALCAP signaling on the Nb interface (ATM core networks only).

GPP IWFThe GSM on Passport Interworking Function (GPP IWF) provides support for circuit switched data (CSD) services, serving as a translation and conversion point in a digital mobile network. The GPP IWF allows an end-to-end connection between a mobile subscriber and a remote device, such as a dial-up modem. The GPP IWF provides the required rate adaptation, radio link protocol, and modems for interfacing the mobile to the PSTN or ISDN.

The GPP IWF is supported on the Passport 8380G platform and consists of the following components:

• Control Processors - These cards provide shelf management.

• Ethernet FPs - These cards each provide six 10bT Ethernet links which are used for both call control and OA&M. Only one of these Ethernet links is actually used.

• DS1C/E1C FPs - These cards provide a single T1/E1 port for connectivity to the (G)MSC or MGW and handle the necessary digital protocol conversion and processing required to interwork to the mobile and to the ISDN.

• DS1/E1 Multipurpose Voice Platform FPs - These cards provide a single T1/E1 port for connectivity to the (G)MSC or MGW and provide the modem pool and support 24 (T1) or 30 (E1) data/facsimile connections.

411-2231-014 Standard 02.07 May 2006


There is not a 1:1 relationship between MSCs and GPP IWFs; a single GPP IWF can serve up to six MSCs.

Any MSCs upgraded to NSS18 will have GPP IWF(s) connected via (P)DTCs for bearer on T1/E1 trunks and EIUs for MIP signaling over Ethernet links. If the GPP IWF is remote from the MSC, the MIP signaling will already be routed over an IP network.

This release allows the GPP IWF to be hosted off MGW-based TDM trunks, which eliminates the need for (P)DTCs to provide the mobile- and network-side Universal Interworking Trunks (UIT). Prior to moving the GPP IWF, the EIU must be replaced by HIOP/HCMIC as the MIP signaling interface. The TDM trunks of the GPP IWF are then migrated from the (P)DTC to the MGW, with an intermediate MUX being required to convert between the optical TDM ports of the MGW and the electrical TDM ports of the GPP IWF. GPP IWF functionality is not affected by these changes. This GPP IWF relocation cannot occur until all trunks are MGW-based as CFIWF use is no longer supported.

Although not a requirement, it is expected that the TDM interfaces of the GPP IWF will typically be hosted off a MGW that is co-located with a XACore at the Central Office (i.e. centralized configuration). In this scenario, the GPP IWF's Ethernet links are connected to the ERS 8600. This is illustrated in Figure 2-1.

However, remote configurations are allowed as well, whereby the TDM interfaces of the GPP IWF can be hosted off remote MGWs or whereby a GPP IWF is controlled by a remote MSC. In this scenario, two signaling configurations are possible:

• The operator can continue to use the existing IP network that is carrying the MIP signaling from a MSC and a remote GPP IWF. The signaling interface to that existing network could change from EIU to HIOP/ERS 8600.

• The GPP IWF's Ethernet links are connected to a remote Aggregation Node, with the MIP signaling routed over the ATM Core Network via ATM MPE.

This is a legacy device whose configuration does not require any changes in this release, so any existing configuration can be maintained.



Figure 2-1 GPP IWF connectivity (centralized/baseline configuration

Note: No other IWF is supported off the MGW.

Media gateway 2The BICN architecture distributes the bearer path away from the (G)MSC and its PMs to Media Gateways (MGWs), which are controlled by the (G)MSC Server via H.248 signaling. The MGW provides media adaptation (AAL2-AAL2 or AAL2-TDM), voice quality features, voice compression and subscriber services. The MGW also plays a Signaling Gateway role on behalf of the (G)MSC Server. For more detailed information on MGW functionality, refer to NTP 411-2231-330, R4 Media Gateway Operations and Reference Guide, and NTP 411-2231-331, R4 Media Gateway OAM and Troubleshooting Guide.

The MGW supports the following voice quality features:

• Echo Canceller (ECAN)

• Comfort Noise Generator for Echo Canceller (ECNG)

• Mobile Echo Control (MEC)

411-2231-014 Standard 02.07 May 2006


• Automatic Gain Control (AGC)

• Background Noise Reduction (BNR)

• Background Noise Conditioning (BNC)

• Packet-to-packet Mobile Echo Control (Pkt-MEC)

• Packet-to-packet Automatic Gain Control (Pkt-AGC)

• Packet-to-packet Background Noise Conditioning (Pkt-BNC)

• Artifact Concealment

MGW personalitiesThere are numerous different MGW personalities and interfaces supported in this release, which are described in the subsequent sections.

A-interface MGWThese MGWs service the 2G wireless access network, or specifically the GSM A-interface. They support TDM to AAL2 conversion on the uplink, and the reverse on the downlink. AMR transcoding can also be applied here for Core Network compressed speech.

Because the A-interface signaling is channelized, A-interface MGWs also act as Signaling Gateways on behalf of the MSC, backhauling the BSSAP signaling via either AAL1 CES or the M2UA SIGTRAN protocol.

This personality can coexist on a 4pVSP4e FP with all others except the Conferencing and Lawful Intercept personalities.

Iu-interface MGWThese MGWs service the 3G UTRAN, or specifically the UMTS Iu interface. These MGWs support the ATM-based Iu interface and have the ability to maintain the AAL2-based bearer for the Core Network (Nb' interface). AMR transcoding can also be applied here for scenarios where G.711 speech must be provided to the Core Network, although in most scenarios compressed speech will be maintained in the Core Network.

The MGW has the ability to insert a CTM modem upon instruction from the (G)MSC Server. The MGW also acts as a Signaling Gateway on behalf of the MSC, backhauling the RANAP signaling over the M2UA SIGTRAN protocol to the USP.


PSTN MGWThese MGWs service the PSTN/PLMN network, e.g. ISUP trunks to other (G)MSCs or wireline switches. They support TDM to AAL2 conversion



similar to the A-interface MGW. Transcoding to G.711 is performed here for scenarios where the Core Network speech is compressed.

For markets where PSTN SS7 signaling is channelized, these MGWs also act as Signaling Gateways on behalf of the MSC, backhauling the ISUP signaling via either AAL1 CES or the M2UA SIGTRAN protocol.

These MGWs can also provide a maximum of one T1 dedicated as a Multi-Frequency (MF) trunk that connects to PSAPs or e911 Tandems. The North American MF signaling is terminated here and is converted to/from H.248 signaling exchanged with the (G)MSC Server.


CFIWF MGWThese MGWs service trunks that connect to SPMs or DTCs (via a MUX) for CFIWF functionality. They support TDM to AAL2 conversion similar to other MGW personalities. Transcoding to G.711 is performed here for scenarios where the Core Network speech is compressed.


Nb-interface MGWThese MGWs present the open Nb interface to the network, for interfacing to other Nortel MGWs controlled by other (G)MSC Servers or perhaps MGWs from another 3GPP vendor. These MGWs interwork between the open AAL2 Nb interface and Nortel's proprietary AAL2 Nb' interface, which runs between MGWs controlled by the same (G)MSC Server. AMR transcoding may or may not be applied here, depending on the results of codec negotiation between (G)MSC Servers.


CSD MGWThese MGWs service the Universal Interworking Trunks that connect to the GPP IWF for CSD functionality.

This personality can only coexist on a 4pVSP4e FP with all others except the Conferencing and Lawful Intercept personalities.

Conferencing MGWThis MGW provides 3- and 6-port conference bridges for the Multiparty service. This is a packet-to-packet (AAL2) MGW that does not utilize TDM

411-2231-014 Standard 02.07 May 2006


ports. Conferencing of G.711 or compressed AMR/AMR2 speech is supported.

Also, for LI scenarios where combined Call Content Channels (CCC) are required, a conferencing bridge is used to combine the target and associate bearer streams prior to delivery to the Law Enforcement Agency (LEA).

This personality can coexist on a 4pVSP4e FP only with the Lawful Intercept personality.

Lawful intercept MGWThis MGW provides bearer stream replication for calls targeted for Lawful Intercept (LI). This replication is performed separately for the target and associate bearer streams.

This personality can coexist on a 4pVSP4e FP only with the Conferencing personality.

MGW hardwareThe MGW is implemented on MSS 15000 hardware which provides hardware and software modularity as well as a highly reliable multi-processor architecture. Each MSS 15000 MGW shelf contains 16 slots for Control Processors (CP) and Function Processors (FP), as well as fabric cards and a common backplane which provide highly reliable and redundant intrashelf I/O:

• Control Processor (CP) - Each MSS 15000 MGW shelf contains two CP3 cards which provide shelf and node management, monitor and process alarms, provide the network synchronization component and are also responsible for spooling announcements to each 4pVSP4e.

• 2p GP Dsk - The 2-port General Processor with Disk (2p GP Dsk) FP is an optional component that provides the MGW shelf with Ethernet I/O capabilities. Each FP provides two 100bT Ethernet links with Ethernet line protection switching.

• ATM FP - The MSS 15000 MGW shelf may contain multiple ATM FPs to provide ATM I/O and services, including ATM encapsulation of IP packets. The number of ATM FPs required in a MGW shelf depends on the applications running in that shelf. A minimum of a single pair of ATM FPs are required per shelf, but some shelves might require an additional pair to support the number of 4pVSP4e cards in the shelf.

• 4-port Voice Services Processor 4 (4pVSP4e) - The 4pVSP4e cards provide the core MGW functionality. Refer to “4-port voice services processor 4” on page 2-14 for more information.

• TDM FP - The 4-port OC-3/STM-1TDM FP is the only type of TDM FP supported. It provides I/O capabilities, AAL1 Circuit Emulation Service



(CES) in the MGW for DTAP/BSSMAP messaging between the GSM BSS and MSC, RANAP messaging between the RNC and MSC, ISUP messaging between the PSTN and MSC Server, and MF trunk support. This FP does not support TDM bearer traffic, which instead uses the OC-3/STM-1 TDM port on the Vsp4 FP. The 4p OC-3 TDM FP and 4pVSP4e cards coexist in a MG18 MGW shelf.

4-port voice services processor 4Each MGW shelf can contain multiple 4-port VSP4e (4pVSP4e) cards which provide the bulk of the MGW functionality including:

• Converting circuit bearer traffic (voice or data) between the formats used on TDM and AAL2 packet interfaces

• Performing transcoding between G.711 and AMR/AMR2 @ 12.2kbps, per instruction from the (G)MSC Server

• Providing a number of voice quality features (AGC, MEC, ECAN, BNR, etc.)

• Insertion of a CTM modem, per instruction from the (G)MSC Server

• Tone and announcement insertion into the bearer path

• MF signaling termination

• Autonomous upspeeding from AMR to G.711 upon detection of a voice band data tone

Note: The (G)MSC Server sees each 4pVSP4e as an individual MGW; it does not see the entire shelf as a MGW.

Aggregation node 2The Aggregation Node (AN) is a MSS 15000 shelf loaded with a standard MSS software load. The AN shelf may be used at the CO and at remote MGW sites, but its use is optional at both of these geographic locations (i.e. the AN functionality can be merged within a MGW shelf). The AN aggregates all ATM traffic.

When deployed, the AN is responsible for:

• All inter-shelf I/O between MGW shelves, providing adequate and deterministic communication characteristics such as connectivity, routing, redundancy, and latency.

• I/O aggregation to maximize I/O port utilization at the network edge.

Additionally, when deployed at the CO the AN is also responsible for:

• Providing the ATM WAN interface for other CO components (e.g. XACore, USP).

411-2231-014 Standard 02.07 May 2006


• Providing the AAL1 CES function at the CO and providing the channelized signaling interface with the DTC/SPM.

The AN at the CO contains a pair of 2p GP Dsk FPs which connect to the ERS 8600s. These FPs aggregate the IP-based H.248 signaling and (optionally) M2UA signaling from the (G)MSC Server and USP respectively. The AN provides encapsulation of the IP traffic into AAL5/ATM cells for transport to the MGWs over the packet network.

The AN also may contain the 4p OC-3/STM-1 TDM FPs for AAL1 CES. This CO function is only required if the USP has not been deployed. Putting the TDM FPs in the AN helps maximize the capacity of the co-resident MGW shelves.

The AN is provisioned for redundancy, which requires equipment sparing on all CPs and FPs.

Connection fabric interworking function 2There are scenarios where a MGW-based trunk must be connected to an ENET-based trunk to complete a bearer connection. However, the MGW does not support the DS-512 interface required for ENET connectivity and the PMs (DTC/PDTC/SPMs) do not support AAL2 bearer. When such a hybrid connection is required, the (G)MSC Switch + Server will detect this and insert a Connection Fabric Interworking Function (CFIWF).

The Connection Fabric Interworking Function (CFIWF) is often referred to as if it was a singular component in the BICN architecture. In fact, it is a singular functional component that is made up of a number of the following physical components:

• A 4pVSP4e to terminate the AAL2 bearer and put this back onto an OC-3/STM-1 TDM trunk. This MGW personality was discussed in “CFIWF MGW” on page 2-12.

• An SPM to terminate the OC-3/STM-1 TDM trunk from the CFIWF MGW and present the bearer to the ENET. This SPM need not be dedicated to CFIWF traffic - it can also be used for A-interface and PSTN trunks.

Note: A (P)DTC can be used in place of an SPM, but this requires a MUX between the (P)DTC and the OC-3/STM-1 TDM FP of the MSS 15000. Therefore all CFIWF examples will assume an SPM is used.

• The OC-3/STM-1 TDM facility between the CFIWF MGW and the SPM. Because both the 4pVSP4e and SPM can support other types of traffic, selection of which trunks are used for CFIWF supports DS0 granularity.



Figure 2-2 CFIWF components and bearer path

In some scenarios, multiple CFIWF functions might need to be inserted for a single call.

On calls where CFIWF circuits are necessary, and none are available, the MSC takes down the call. Due to the timing of the takedown, such unsuccessful calls may get as far as the alerting state and may or may not have treatment applied before the MSC takes down the call completely.

Optera metro 3500/4200 2Multiplexer (MUX) equipment is shown in diagrams throughout this document in order to add-drop multiplex between T1 and OC-3 TDM carriers. For North American Nortel turnkey solutions, the Optera Metro 3500 provides this MUX function. For ETSI markets, the Optera Metro 4200 is used.

The MUX is required for the following functions:

• To multiplex between T1/E1 and OC-3/STM-1. This is required between the MGW (4p OC-3/STM-1 TDM FP or 4pVSP4e) and any peer device that cannot present an OC-3/STM-1 interface, e.g. BSC, PSTN, DTC or GPP IWF.

• To groom T1/E1s within OC-3/STM-1 carriers on the 4p OC-3/STM-1 TDM FP and 4pVSP4e. This could also be used in a MUX that sits between SPMs and MGW/AN shelves at the CO.

411-2231-014 Standard 02.07 May 2006


OA&M components 2The Core Element Manager (CEM) has been the primary element manager supported in previous NSS releases. In NSS18, customers are expected to migrate to the Wireless Network Management System (W-NMS) as CEM standalone will no longer be supported as of NSS19. Hence, this section actually describes two OAM solutions: CEM standalone and W-NMS.

The following table lists the OA&M components specific to the standalone CEM, mapping these to hardware platforms.

W-NMS is based on a dual server architecture (a "Main Server" and a "Performance Server"). The following table lists the mapping of OA&M components to these two hardware platforms.

Table 2-1 Standalone CEM OA&M hardware platforms

OAM component Hardware platform

Core Element Manager (CEM) CEM Server (Sun V880)

Multi-service Data Manager (MDM) CEM Server (Sun V880)

Multi-service Data Provider (MDP) CEM Server (Sun V880)

Table 2-2 W-NMS OA&M hardware platforms

OAM component Hardware platform

Network Services Platform (NSP) Main Server

3GPP Building Block Main Server

Core Element Manager (CEM) Main Server

Multi-service Data Manager (MDM) Main Server

System Management Main Server

Multi-service Data Provider (MDP) Performance Server

3GPP PM XML Data Interface Performance Server



W-NMS OAM4.2 supports a wide variety of hardware platforms, depending largely on the size of the network and its capacity requirements:

• SunFire V4800 and V4900 (new installs) support large networks and are intended for managing both core and access networks.

• SunFire V880 and V890 (new installs) support medium sized network designed specifically for the voice core solution.

• SunFire 250 and SunFire 240 (new installs) support smaller networks.

The table below maps OA&M components (common to both solutions) to hardware platforms.

Connectivity among these platforms (including the standalone CEM Server) and the network elements (NEs) is shown in Figure 2-3.

Figure 2-3 Standalone CEM server OA&M component connectivity

Table 2-3 Common OA&M hardware platforms

OAM Component Hardware Platform

Supernode Data Manager (SDM) SDM/FT

Core Billing Manager 850 (CBM850) 1 pair of Sun Netra 240 servers

Audio Provisioning Server (APS) Sun Netra 240 server

411-2231-014 Standard 02.07 May 2006


In W-NMS deployments, connectivity among these platforms (including the Main and Performance Servers) and the network elements (NEs) is shown in the figure below.

Figure 2-4 W-NMS OA&M component connectivity

Core element managerCore Element Manager (CEM) is the overall element manager for the core network. MSC (and HLR) are managed directly. MSS 15000- and 7000-based nodes and SNMP-based nodes (ERS 8600 and APS) are managed via integration with MDM.

The GEM18 load for CEM is used in NSS18.

CEM provides a range of fault, performance, and configuration management applications:

• CEM provides a sub-component viewer for all core NEs.

• The USP may be managed either as a subcomponent of the (G)MSC or as a standalone NE.

• CEM provides a consolidated alarm list for all core NEs; the alarm list supports alarm acknowledgement and (when needed) manual alarm clear. In addition, it is possible to link from an alarm to the affected node in the subcomponent viewer.

• CEM supports a table editor graphical user interface (GUI) by which any DMS table may be viewed and edited.



• Sub-component viewer supports an "info window" for display of component-specific details (NE datafill and other OA&M attributes).

• CEM provides BICN-specific wizards for adding/deleting H.248 MGWs, adding/deleting BICN trunk groups/members, and wizards for migration of an existing legacy (G)MSC Switch to a (G)MSC Server. In addition, wizards are available for adding/removing legacy trunk groups/members and SS7 links/linksets/routesets.

• An audit wizard is provided to audit consistency of MSC datafill (MGW nodal and trunks) with MGW datafill.

• Performance manager supports viewing operational measurement (OM) data graphically for all DMS-based NEs, the MG and the AN. Threshold management is supported for these devices as well.

• CEM provides security features for user login and access control. Login is validated via a customer-provided LDAP.

The CEM GUI client is supported on Windows NT/2000/XP PCs and Sun (Solaris 8) workstations.

For more information on CEM, refer to the following:

• NTP 411-8111-503 GSM NSS / UMTS Voice Core Network OAM User Guide

• NTP 411-8111-803 GSM NSS / UMTS Voice Core Network OAM Reference Manual

Network services platformNetwork Services Platform (NSP) provides the following functionality:

• A common desktop for the various W-NMS OAM applications.

• A resource browser, which provides the network wide view of NEs managed within W-NMS.

• Common fault management applications (active alarm list and archival/query of historical alarms).

• Alarm management rulesets, providing basic correlation capabilities which can be used for alarm severity re-assignment, management of toggling alarms and thresholding of alarms.

• Interface to an external trouble ticketing system.

The NSP load used for NSS18 is the Framework 3.2 load. This is part of the OAM 4.2 load of W-NMS.

411-2231-014 Standard 02.07 May 2006


3GPP FM building blockThe 3GPP Fault Management (FM) Building Block provides mediation between the NSP fault management applications and an OSS; the interface is a CORBA interface that supports:

• Retrieval of the list of NEs being managed.

• Asynchronous notification of alarms to an OSS.

• Manual alarm clear and alarm acknowledgement synchronization between W-NMS and an OSS.

• Alarm re-synchronization between W-NMS and an OSS.

Up to 6 OSS clients are supported.

The 3GPP FM Building Block is part of the OAM 4.2 load of W-NMS, which is used for NSS18.

3GPP PM XML data interfaceThe 3GPP Performance Management (PM) XML Data Interface (xDI) provides mediation between the PM data storage in CEM and the standard 3GPP performance management XML file format. The xDI software resides on the W-NMS Performance Server. The resulting XML files are stored on the Performance Server and may be retrieve by an OSS through FTP.

The 3GPP PM XML Data Interface is part of the OAM 4.2 load of W-NMS, which is used for NSS18.

System managementSystem Management (SMG) is built on top of Sun Management Center. SMG provides supervision of the OAM applications on the W-NMS Main and Performance Servers, and also monitors hardware and OS-level problems on these servers.

W-NMS backup and restore capabilities also support backup and restore to a centralized Veritas backup server.

Supernode data managerSDM includes base SDM APIs for communication with the MSC (for table access, log access, OM access) and GEM applications. The GEM applications include "store-and-forward" processes that allow the CEM to communicate with the SDM APIs and the SDM Billing Application (SBA). All telnet and FTP signaling to/from the XACore must pass through the SDM-FT via the DS-512 links to the MS.

The SuperNode Data Manager-Fault Tolerant (SDM-FT) is a UNIX-based computing platform on which a variety of services and applications can be hosted to provide DMS OAM&P services. The SDM-FT includes DS-512



fiber connectivity to the MSC. The SDM-FT uses the IBM AIX operating system.

The SDM-FT utilizes the Motorola Series FX housed in a C28 Model B DMS Streamlined Cabinet. The SDM-FT base configuration contains hardware redundant packs making it fault tolerant.

Core billing managerThe Core Billing Manager (CBM) 850 is the next generation evolution of the SDM-FT, functionally equivalent at the application layer. CBM is a carrier grade and fully redundant SUN/Solaris-based OAM&P platform, consisting of two Netra 240 servers that reside in a COAM cabinet. The CBM 850 has four Gigabit Ethernet interfaces (10/100/1000Mbps auto-sensing) for connection to both the CO LAN/Router and to each other.

The CBM 850 has high-availability software which enables a cluster of two N240 servers to appear as one, including heartbeating, system-level monitoring, data replication across the servers and resource migration from one server to the other.

Multi-service data managerMDM is the element manager for MSS 15000- and 7000-based devices and SNMP-based nodes (ERS 8600 and APS). It supports a range of fault and configuration management applications, which includes:

• Network Viewer - displays a real-time graphic network map that includes device components, trunks and links.

• Component Information Viewer - performs diagnostic analysis of components that were first identified by other MDM first-alert surveillance toolsets. It can be used as a diagnostic tool that queries the port level.

• Circuit Viewer - a surveillance toolset that is closely integrated with other MDM circuit management and provisioning toolsets. The Circuit Viewer is the primary tool for displaying specific information about a circuit or network component that is stored in MDM's circuit management database.

• MDM Nodal Provisioning - a GUI application for provisioning Passport components and selected services. The Passport nodal provisioning application provides the following capabilities: forms-based component provisioning, forms-based service provisioning, and drag-and-drop service provisioning templates.

In addition, MDM provides a data-driven ("cartridge") facility to allow fault management integration of SNMP devices. Cartridges are used to integrate faults from the ERS 8600 and APS.

411-2231-014 Standard 02.07 May 2006


The MDM GUI applications may be launched "in-context" from the CEM GUI.

NSS18 requires MDM 15.1.

For more information on MDM, refer to NTP 241-6001-801 Preside Multiservice Data Manager Overview.

Multi-service data providerPreside MDM Management Data Provider is used to collect statistics data for the MSS 15000- and 7000-based nodes. MDP converts these counters from Falcon Management Information Protocol (FMIP) format into Bulk Data format (BDF). These BDF files are then imported into CEM's performance management applications.

For more information on the MDP, refer to the NTP 241-6001-309 Preside MDM Management Data Provider User Guide. For information on MSS 15000 data collection, refer to the Passport 7400, 15000 Data Collection Guide.

Audio provisioning serverThe Audio Provisioning Server (APS) provides web based interfaces for customers to configure and administer audio into the MGW. The APS may be launched from the CEM GUI. Through the APS interface the customer may add, delete, and replace audio managed by the APS for that customer as well as exporting the created audio package to selected MGWs. For each announcement, the announcement ID provisioned on both the APS and XACore must match.

APS provides a centralized location and Graphical User Interface (GUI) for configuring and administrating the audio database and audio files used by the MGW. It supports:

• Data entry using the GUI provisioning tool.

• Immediate audio distribution to a MGW node when initiated by a user from the APS GUI.

The platform is a carrier grade compatible, Solaris-based server. This platform is based upon the NEBS-3 compliant Sun Microsystem Netra 240 (DC power) server using Solaris 8. Existing deployments may continue to use the older hardware platform, the Netra t1400.

NSS18 uses APS09.

For more information on the APS, refer to NTP 295-5071-309 Audio Provisioning Server.



411-2231-014 Standard 02.07 May 2006


Packet network 3This chapter describes the details of and recommendations for the packet network(s). The two network components that bear the majority of the burden of routing are discussed separately - the Central Office LAN/router and the MSS Virtual Routers. The IP and ATM networks required by this solution are then each discussed separately.

CO LAN/router 3The BICN solution requires a Captive Office (CO) LAN/router function for layer 2 (Ethernet) switching and layer 3 (IP) routing between the various CO components that must communicate with each other. Dual ERS 8600s comprise this router function and sit at the heart of the CO LAN. The CO LAN also consists of the XACore, USP, the local MSS 15000 Aggregation Node and/or MGW shelves and any co-resident OA&M components.

To allow for full redundancy, each CO LAN component should have dual Ethernet links, one to each ERS 8600. The Virtual Router Redundancy Protocol (VRRP) and Multi-Link Trunking (MLT) are used between the ERS 8600s to provide carrier grade reliability.

IP routingRouting IP packets between components in this release is provided by the following supported techniques and protocols:

• Static Routes

• Virtual Router Redundancy Protocol (VRRP)

• Gratuitous Address Resolution Protocol (GARP)

• ATM Multi-Protocol Encapsulation (ATM MPE)

Static routesThe use of static routes is recommended for this release, due to the relative simplicity of the CO LAN and the use of only a single pair of redundant ERS 8600s for routing purposes. Therefore the routing table in the ERS 8600 must be statically provisioned.


3-2 Packet networkNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

Virtual router redundancy protocolThe Virtual Router Redundancy Protocol (VRRP) eliminates a single point of failure by providing multi-homed connectivity in a routed environment.

VRRP must be enabled on all VLANs configured on the ERS 8600s. Each ERS 8600 is set up as a VRRP router and "controls" the IP addresses for half of the devices (load sharing) on the network, i.e. it is the VRRP Master for some links and the VRRP Backup for other links. VRRP provides for dynamic failover in the forwarding responsibility should the master VRRP router for a particular IP address become unavailable. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.

VRRP runs over redundant Gigabit Ethernet links running between the two ERS 8600s. These links are referred to as Multi-Link Trunks (MLT). Multi-Link Trunking is a point-to-point connection that aggregates multiple ports so that they logically act like a single port with the aggregated bandwidth.

Furthermore, VRRP Fast Advertisement should be enabled on all ERS 8600s. This decreases the VRRP advertisement time to 200ms, which allows for faster failure detection.

Gratuitous address resolution protocolThe Gratuitous Address Resolution Protocol (GARP) is not really a new protocol, but instead refers to an ARP reply that is sent without ever first receiving an ARP request. Such an ARP reply is referred to as a GARP message. This GARP message updates the ARP cache (IP address - MAC address mapping) at the receiving router. The HIOP/HCMIC sends a GARP message every time it comes in-service or takes over for a failed HIOP/HCMIC. In the NSS18 BICN solution, the ERS 8600 is the only device that needs to process the GARP message.

ATM multi-protocol encapsulationATM Multi-Protocol Encapsulation (MPE) is a protocol that allows IP encapsulation in ATM AAL5 Virtual Circuits. The ATM MPE service is used by the MSS 15000 components to allow IP packets (e.g. carrying H.248, M2UA, OA&M, etc.) to be transmitted across the ATM Core Network. Specifically, ATM MPE runs at:

• the AN or MGW that bridges the IP-routed CO LAN with the ATM Core Network, and

• the MGW

For IP packets from the MSC to the MGW, ATM MPE is used at the AN or MGW to resolve the destination IP address to an ATM address (SPVC or PVC). The reverse occurs for IP packets received from the MGW.

411-2231-014 Standard 02.07 May 2006

Packet network 3-3Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

InterconnectivityThe following table describes the connectivity between the ERS 8600 and various CO components at protocol layers 1 through 4:

MSS virtual routers 3The MSS Virtual Router (VR) provides a software emulation of physical routers. A VR has two main functions:

• Construction of routing tables describing the paths to networks or subnetworks.

• Forwarding or switching packets to the final destination network or subnetwork.

Table 3-1 Layer 1-3 interconnectivity

Component Layer 1 Layer 2 Layer 3

XACore (HIOP/HCMIC) 100bT Ethernet (Cat 5) Ethernet (MAC) IP

EIU 10bT Ethernet (Cat 5) Ethernet (MAC) IP

GPP IWF 10bT Ethernet (Cat 5) Ethernet (MAC) IP

AN (2p GP DSK) 100bT Ethernet (Cat 5) Ethernet (MAC) IP

USP (RTC) 100bT Ethernet (Cat 5) Ethernet (MAC) IP

SNMP

USP (IPS7 Gateway) 100bT Ethernet (Cat 5) Ethernet (MAC) IP

USP (IP HSL) 100bT Ethernet (Cat 5) Ethernet (MAC) IP

CEM Server 100bT Ethernet (Cat 5) Ethernet (MAC) IP

SNMP

APS 100bT Ethernet (Cat 5) Ethernet (MAC) IP

CBM 100bT Ethernet (Cat 5) Ethernet (MAC) IP

SDM-FT 100bT Ethernet (Cat 5) Ethernet (MAC) IP

W-NMS Main Server 100bT Ethernet (Cat 5) Ethernet (MAC) IP

W-NMS Performance Server 100bT Ethernet (Cat 5) Ethernet (MAC) IP

MGW/AN (CP3) 100bT Ethernet (Cat 5) Ethernet (MAC) IP

ERS 8600 Gigabit Ethernet Ethernet (MAC) IP



VRs on a MSS node can perform the functions of independent physical routers, forwarding packets to the correct destination, while isolating traffic from other VRs in the same way that physical routers do. VRs also have independent IP routing tables that are isolated from each other.

The VR has logical ports, called Protocol Ports (PP), which link their own subnet and are assigned one or more IP addresses.

Because the PCR6.1 MSS load is used in this release, inter-VR routing can only be achieved via ATM hairpins that leave and reenter the shelf.

IP addresses and subnets 3IP addresses are required by many devices in this architecture, and multiple subnets are required to provide full IP connectivity for various types of signaling (e.g. call processing vs. OA&M). This section will discuss the IP address and subnet requirements of each component, and provide a recommended system configuration.

The number of IP addresses consumed will depend on the size of each subnet, which itself is likely to vary among operators. Each operator must consider factors such as future network expansion when configuring subnet sizes to facilitate this growth and minimize the impact future expansion has on the network.

The following terminology is used:

• Public IP address - an IP address that will be seen from another PLMN or from some other public network.

• Private IP address - an IP address taken from a private address range (see below). The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

— From 10.0.0.0 to 10.255.255.255 (10.0.0.0 /8 prefix) - this is a single class A network number, which provides 16,777,214 usable addresses.

— From 172.16.0.0 to 172.31.255.255 (172.16.0.0 /12 prefix) - this is a set of 16 contiguous class B network numbers, each providing 65,534 usable addresses.

— From 192.168.0.0 to 192.168.255.255 (192.168.0.0 /16 prefix) - this is a set of 256 contiguous class C network numbers, each providing 254 usable addresses.

• Internal IP address - an IP address used only inside a node. It should be unique within that node but can be reused as an internal IP address at other nodes. Private IP addresses should be used here.

• Routable IP address - an IP address that will be routed in the PLMN (i.e. outside the individual nodes) but will not be seen from outside or public

411-2231-014 Standard 02.07 May 2006


networks. It must be unique within the PLMN and can be a public or private IP address, although private IP addresses should be used wherever possible.

It is recommended to use these classes in this solution to provide a scalable network design. The use of public IP addresses is also certainly possible, but not required.

Ethernet routing switch 8600As discussed previously, dual ERS 8600s provide the IP routing and Ethernet switching function for the Central Office (CO). Each CO component should have direct connectivity to each ERS 8600 for redundancy.

While this document provides recommendations, the number of subnets/VLANs configured might differ between operators. So a few basic rules for the ERS 8600 are defined:

• Each VLAN requires a separate VRRP instance and VRRP IP address.

• A single MLT group must be defined on each ERS 8600 and added to all VLANs.

• IEEE 802.1q VLAN tagging must be enabled on the MLTs, which allows VLANs to span across both ERS 8600 routers.

• Spanning Tree Protocol (STP) must be enabled at the box level but disabled on all ERS 8600 ports/interfaces.

The number of IP addresses required by the pair of ERS 8600s can be summarized as follows:

• One per ERS 8600 for the Management Interface (i.e. out of band OA&M subnet). Since this interface is routable, it should be configured with an IP address from a subnet that is not in the ERS 8600's routing table.

• One per ERS 8600 (physical) for each of the configured VLANs.

• One per VRRP logical IP address per VLAN pair (also known as the default gateway address). By convention this is typically the first non-zero IP address in a subnet

All of these IP addresses can be private. This is illustrated with a simple example, where dual ERS 8600s provide VRRP service for two edge hosts. Two VLANs are defined, along with two subnets, one larger /24 subnet (subnet mask 255.255.255.0) and one smaller /28 subnet (subnet mask 255.255.255.240) with Class A private addresses 10.x.x.x.



Figure 3-1 ERS 8600 VLAN example

Each edge host sends traffic to the appropriate VLAN's VRRP IP address, not to the ERS 8600's physical IP address. Thus the edge host does not need to be aware of which ERS 8600 is VRRP master.

Call processing and OA&M traffic should be segregated onto separate VLANs and subnets due to the IP address/subnet configuration currently being used by operators with HIOPs already in place. This is because complete HIOP/HCMIC outages occur when trying to increase the size of the HIOP/HCMIC subnet; therefore operators might opt to split the call processing VLAN/subnet into multiple smaller VLANs/subnets if a small HIOP/HCMIC subnet is already in place.

Where a particular IP address can be included in the call processing VLAN/subnet or in its own unique VLAN/subnet, this will be noted.

Subnet configurations could differ.

411-2231-014 Standard 02.07 May 2006


XACoreEIU and DS-512 interfaceNew IP applications on the XACore use the HIOP/HCMIC interface. However, the following legacy applications might not use the HIOP/HCMIC interface for at least a period of time in this release:

• MIP signaling with the GPP IWF, which uses the EIU prior to migrating this signaling to the HIOP/HCMIC.

• Data management signaling, which uses the DS-512 interface of the Message Switch prior to migrating this functionality from the SDM/FT to the CBM.

For these applications, the XACore requires a single IP address in table IPNETWRK. In addition, despite its use of the HIOP/HCMIC as the signaling interface, the CBM has created some dependencies on IPNETWRK datafill.

This signaling between the XACore and EIU, and between the XACore and SDM/FT, shares a common subnet referred to in this document as the legacy DMS subnet. This legacy DMS software does not understand a subnet mask as do Ethernet LANs and external routers. As a result, the following rules must be met for a subnet and an IP address to be accepted in table IPNETWRK:

• The number of subnet bits cannot be 0.

• The host bits overlapping the subnet bits cannot be all zeros or all ones (this is due to strict adherence to outdated IETF RFC 950).

• The IP address assigned in this table to CMIPADDR (i.e. IRM active address) must be divisible by 8.

Each EIU requires two routable IP addresses datafilled in table IPHOST, which in turn must belong to two different subnets.

• The EIU's c-side IP address (subfield SNADDR) should belong to the same subnet as the XACore's IP address datafilled in table IPNETWRK, i.e. the legacy DMS subnet. This subnet should already exist if EIUs are already in place.

• The EIU's p-side IP address (subfield LANADDR) should belong to the same subnet as the GPP IWF's IP address, referred to in this document as the GPP IWF subnet. This subnet should already exist if the GPP IWF is already in place.

This is true for all EIUs and GPP IWFs at a given MSC. The size of the subnets thus depends on the number of EIUs and GPP IWFs.

HIOP/HCMIC interfaceThe XACore will require one or two pairs of HIOP or HCMIC cards. In the NSS17 BICN solution, it was recommended that the XACore's HIOPs be put



into a separate subnet from other CO components. Due to the fact that the HIOP subnets cannot be changed or increased without a total outage of all HIOPs and also because the HIOPs/HCMICs will now be responsible for both call processing and OA&M signaling, this paradigm can continue for these existing solutions.

Six IP addresses are required by the first HIOP/HCMIC pair, provisioned in table CMIPADDR:

• Two per pair for the floating active interfaces (CHMOST tuple)

• One per HIOP/HCMIC for the maintenance interface (ETHRLNK tuple)

• One per HIOP/HCMIC for the physical interface (ETHRLNK tuple)

When an additional pair of HIOP/HCMICs is added, four additional IP addresses are required:

• One per HIOP/HCMIC for the maintenance interface (ETHRLNK tuple)

• One per HIOP/HCMIC for the physical interface (ETHRLNK tuple)

For existing BICN solutions where the HIOP subnet cannot be increased, all of these IP addresses should be put into the HIOP subnet for the reasons discussed above. This will force routing between the HIOP/HCMIC and all other components.

In new BICN deployments or in offices which already possess a sufficiently large subnet defined, these IP addresses should be put into the larger CallP subnet, shared with other CO call processing components. This lessens, but does not altogether eliminate, the need for IP routing at the CO.

In order for the HIOPs/HCMICs to communicate reliably, auto-negotiation must be enabled on the ports of the remote end device (ERS 8600 or equivalent) to which they are connected. This will cause both ends to automatically negotiate to 100bT full duplex.

The IP addresses associated with the HIOPs/HCMICs are provisioned in table CMIPADDR, as shown in the following example depicting a single pair of cards.

411-2231-014 Standard 02.07 May 2006


Figure 3-2 Table CMIPADDR example

As stated above, an additional pair of cards would result in an additional pair of ETHRLNK tuples in table CMIPADDR. However, no additional CMHOST tuples are required since a maximum of two active links are supported. The CMHOST tuples represent the IP addresses of the MSC Server as seen by external nodes (e.g. MGW, USP). For nodes that require the MSC Server address to be statically provisioned, the IP addresses in the CMHOST tuples should be used evenly, e.g. half of the 4pVSP4e FPs should be provisioned with CMHOST0 and half with CMHOST1.

One important restriction deserves mention. The CBM has a dependency between the HIOP/HCMIC and legacy EIU interfaces. Specifically, the CBM requires that the HIOP/HCMIC's IP address be provisioned in the EIU provisioning table (IPNETWRK) as an IRM address. This imposes the same outdated restrictions mentioned earlier upon the HIOP/HCMIC addresses. Specifically, the following rules apply to the HIOP/HCMIC addresses before the CBM can be provisioned:

• The HIOP/HCMIC must exist on a network that is the same class (A, B or C) as the EIU.

• The HIOP/HCMIC must utilize different subnets with the same subnetwork mask, irrespective of network class.

• The subnetwork defined for use by the HIOPs/HCMICs must not be the first or last subnet of the specified subnet size within the class of network



used. In other words, the subnetwork portion of the address (not including the network bits as defined by the network class) must not be all zeros or all ones when described as a binary number.

GPP IWFOne IP address is required per MIP host, i.e. per MSS 7000 shelf providing GPP IWF functionality. This IP address should belong in the same subnet as the EIUs' p-side IP address, i.e. the GPP IWF subnet, which should already exist. When the MIP signaling is migrated from the EIU to the HIOP/HCMIC interface, the GPP IWF can be put onto the CallP subnet if desired, since the EIUs will be decommissioned and the GPP IWF would be the only remaining host on the GPP IWF subnet.

It should also be noted that the GPP IWF uses a provisioned IP address when sending MIP replies to the MSC; it does not use the source IP address in the L3 header of the MIP request. Therefore when the GPP IWF is migrated from EIU connectivity to HIOP/HCMIC connectivity, this provisioned attribute will have to be changed to reflect one of the HIOP/HCMIC IP addresses.

The GPP IWF also requires a MVR for OA&M. The IP address assigned here can be put into the OA&M subnet.

USPThe USP requires the following IP addresses:

• One per RTC (two total) in the OA&M subnet

• One per OA&M workstation in the OA&M subnet

• One per IPS7 Gateway Node or IP HSL Link System Node, in the CallP subnet

• One per ICCM (two total, if ICCMs are required), in the OA&M subnet

• One for the RAS (optional), in the OA&M subnet

IP addresses are not required for other SS7 System Node types.

In order for the USP nodes to communicate reliably, auto-negotiation must be enabled on the ports of the remote end device (ERS 8600 or equivalent) to which they are connected. This will cause both ends to automatically negotiate to 100bT full duplex.

MSS 15000The following sections describe the IP addresses required by the MSS 15000 AN and MGW components. There is some degree of flexibility in how the VRs are used.

411-2231-014 Standard 02.07 May 2006


The following types of VRs are defined for this release:

• Management VR (MVR) - This VR provides a single point of external entry into the Passport node, typically used for OA&M. You can use the management VR to manage all customer VRs that reside on the MSS node. The first VR created on a MSS node becomes, by default, the MVR. Every MSS 15000 shelf (AN or MGW) requires a MVR.

• MTP3b VR - This VR is used for SAAL-NNI and MTP3b signaling. Every MGW shelf running MTP3b requires this VR.

• SIGTRAN VR - This VR is used for M2UA signaling traffic which runs between the MGW shelf the USP. The AN at the CO as well as every MGW shelf running M2UA requires this VR.

• H.248 VR - This VR is used for H.248 signaling traffic which runs between the MGW shelf the XACore. The AN at the CO as well as every MGW shelf requires this VR.

The H.248 VR and SIGTRAN VR are shown separately for security reasons. However, they can be combined into a single VR. For example, at the CO where the AN sends/receives both SIGTRAN and H.248 traffic to/from the ERS 8600, a single VR can be used.

Management VROA&M uses the Management Virtual Router (MVR) as discussed previously. The IP addresses assigned to the MVR of each MSS 15000 shelf should be put into the OA&M subnet.

MTP3b VRThis VR has Protocol Ports (PPs) responsible for routing between the following:

• The SAAL-NNI component on the ATM FPs.

• The Q.2630 component on the 4pVSP4e PDC, for any 4pVSP4e that supports the Iu or Nb interface.

• The SIGTRAN VR for MTP3b traffic carrying RANAP signaling. This inter-VR routing requires external loop-around ATM links.

Each PP requires its own IP address.

SAAL-NNI uses the Generic IP Server (GIPS) software. Each 1:1 ATM FP pair running SAAL-NNI requires one IP address as well as one PP on the MTP3b VR. These are all internal private IP addresses. A unique SAAL-NNI subnet should be configured for each PP and its associated ATM FP pair running SAAL-NNI.

ALCAP uses MTP3b for transport and must be routed to the PDC on the 4pVSP4e. Like SAAL-NNI, MTP3b uses GIPS. Every 4pVSP4e running



ALCAP requires its own PP on the MTP3b VR as well as its own IP address for this signaling. A unique MTP3b subnet should be configured for each PP and its associated 4pVSP4e.

A unique inter-VR subnet should also be configured for the inter-VR routing between the MTP3b VR and the SIGTRAN VR.

SIGTRAN VRThis VR has PPs responsible for routing between the following:

• The MTP3b VR for MTP3b traffic carrying RANAP signaling. This inter-VR routing requires external loop-around ATM links

• All 4pVSP4e SSMs on the shelf which are responsible for M2UA signaling backhaul.

• The ATM MPE component which routes the ATM-encapsulated SIGTRAN traffic.

The inter-VR PP and subnet is the same as discussed in the previous section.

The 4pVSP4e FPs which run M2UA on the MGW shelf require only a single common PP on the SIGTRAN VR. Each 4pVSP4e SSM also requires an IP address. These are routable IP addresses that can all share a common subnet per shelf, referred to as the SIGTRAN subnet.

An additional PP is required on the SIGTRAN VR for ATM MPE. This routable IP address should be put into a separate subnet, shared with all other ATM MPE components in the network. This is referred to as the ATM MPE subnet.

H.248 VRThis VR has PPs responsible for routing between the following:

• All 4pVSP4e SPMs on the shelf.

• The ATM MPE component which routes the ATM-encapsulated H.248 traffic.

The 4pVSP4e FPs on the MGW shelf require only a single common PP on the SIGTRAN VR. Each 4pVSP4e SPM also requires an IP address. These are routable IP addresses that can all share a common subnet per shelf, referred to as the H.248 subnet.

An additional PP is required on the H.248 VR for ATM MPE. This routable IP address should be put into the common ATM MPE subnet discussed previously.

411-2231-014 Standard 02.07 May 2006


Combined H.248 and SIGTRAN VRThe AN at the Central Office provides the bridge between the CO LAN (XACore and USP) and the ATM WAN. All H.248 and SIGTRAN signaling from the XACore and USP respectively must traverse this AN.

The H.248 and SIGTRAN VRs at the AN can be combined into one. This VR has PPs responsible for routing between the following:

• The ATM MPE component which routes the ATM-encapsulated H.248 and SIGTRAN traffic.

• The 2p GP Dsk component providing the CO LAN interface.

The PP for ATM MPE requires its own routable IP address that can be included in the ATM MPE subnet, shared with all other ATM MPE PPs.

The PP for the CO LAN interface should be put into the CallP subnet with the other CO components.

Similarly, the H.248 and SIGTRAN VRs at each MGW shelf can also be combined.

MSS 7000If the MSS 7000 is used for either of the functions discussed in “Multi-service switch 7000” on page 2-8, a MVR will be defined with an IP address in the OA&M subnet. AAL1 CES does not require any IP addressing.

SDM/FTThe SDM/FT requires the following IP addresses:

• One for the DS-512 interface, in the Legacy DMS subnet

• One for network management access, in the OA&M subnet

CBMThe CBM 850 requires the following logical floating IP addresses to be configured on the OA&M subnet:

• One for each CBM unit (two total), which float from one active Ethernet port to another. These are used for node specific maintenance actions.

• One for the CBM cluster (i.e. both servers) which represents the active CBM unit (i.e. the active CBM node can always be addressed via this IP address).

Two additional IP addresses are required for inter-CBM communication. These internal IP addresses are private and exist on the private interconnect LAN that runs between CBM units.



The CBM 850 will use only one of the HIOP/HCMIC IP addresses for all traffic between the XACore and CBM 850. A fixed route is added on the core side to ensure that packets leaving the CBM will use the appropriate IP address.

Unlike other components which communicate with the XACore via the HIOP/HCMICs, the CBM requires a tuple in table IPNETWRK which references the table CMIPADDR IP address that will be used. Unfortunately this creates a dependency between tables IPNETWRK and CMIPADDR, which in turn requires that the IP addresses in these two respective tables use the same IP address class and subnet size.

Note: If the CBM is added to a XACore that already has in-service HIOP/HCMICs whose IP addresses differ (either in class or subnet size) with the EIUs, then reconfiguration of IP addresses is required. This would result in component outages either to the HIOP/HCMICs or to the EIUs and SDM.

In addition to the OA&M LAN, the CBM must also communicate with the CallP LAN (specifically the XACore) on the same physical interfaces. IP policy filtering is required on the ERS 8600 to ensure that these packets are only sent on the Ethernet ports connecting the HIOPs.

CEM serverCEM Server uses IP Multi-Path (IPMP), whereby each interface has one external-routable and two internal IP addresses. CEM Server has a single interface, therefore a total of three IP addresses are required.

All addresses should belong to the OA&M subnet, although the internal IP addresses can come from any private address space.

W-NMS main serverLike CEM Server, the W-NMS Main Server uses IPMP. However, there are three distinct interfaces on the Main Server:

• One for connectivity to the NEs

• One used for backup and restore

• One used for GUI and OSS traffic

Each interface has three IP addresses: one external and two internal. Therefore, a total of nine IP addresses are required. All addresses should belong to the OA&M subnet, although the internal IP addresses can come from any private address space.

411-2231-014 Standard 02.07 May 2006


W-NMS performance serverThe IP address requirements of the W-NMS Performance Server are identical to those of the Main Server. A total of nine IP addresses are required.

Core network subnet summaryThe following table simply summarizes the subnet configurations discussed in the previous sections.

Table 3-2 Subnet summary

Subnet Location Components included

Legacy DMS One per MSC XACore (for EIU and DS-512 interface) C-side interface of EIUs SDM/FT DS-512 interface

HIOP One per MSC (Note 1) HIOP/HCMICs

CallP One per MSC HIOP/HCMIC (Note 2) 2p GP Dsk FPs PP on AN's H.248/SIGTRAN VR USP IPS7 Gateway Nodes USP IP HSLs GPP IWF (Note 3)

GPP IWF One per GPP IWF (Note 3) GPP IWF P-side interface of EIUs

ATM MPE One per MSC (shared between AN and all MGWs)

All AN/MGW ATM MPE endpoints (i.e. ATM MPE PPs at H.248 and SIGTRAN VRs)

H.248 (Note 4) One per MGW shelf One for AN at the CO

SPM of each 4pVSP4e in the shelf PP on H.248 VR

SIGTRAN (Note 4) One per MGW shelf supporting M2UA One for AN at the CO

SSM of each 4pVSP4e in the shelf running M2UA PP on SIGTRAN VR

SAAL-NNI One per ATM FP pair supporting SAAL-NNI

SAAL-NNI GIPS PP PP on MTP3b VR

MTP3b One per 4pVSP4e supporting MTP3b (Iu, Nb)

MTP3b GIPS PP PP on MTP3b VR

Inter-VR One per MGW shelf supporting RANAP

PP on MTP3b VR PP on SIGTRAN VR

—sheet 1 of 2—



Note 1: A unique HIOP subnet is used only if it already exists. For new HIOP/HCMIC deployments, this subnet is folded into the CallP subnet.

Note 2: New HIOP/HCMICs will be put into the CallP subnet. Existing HIOP/HCMICs should remain in their current subnet to avoid an outage.

Note 3: After GPP IWF migration to the HIOP/HCMIC interface, it can be rehosted in the CallP subnet if desired. Prior to this migration, it should exist in its own subnet.

Note 4: H.248 and SIGTRAN subnets can be combined MGW and/or AN.

ATM core network 3The packet backbone is a collection of inter-connected ATM nodes that are responsible for the transport of ATM WAN traffic. This includes AAL1 CES traffic, AAL5-encapsulated IP traffic (H.248, M2UA and OA&M), and AAL2 bearer traffic. In the Nortel BICN solution, the MSS 15000 (MGW and/or AN) provides the ATM WAN interface on behalf of other components. This interface can be either OC-3/STM-1 (baseline) or DS3 (variant) at the physical layer.

MSS fiber-based ATM FPs (4p or 16p OC-3/STM-1) support Automatic Protection Switching (APS). In APS, a protection line is provisioned against the primary line and carries the same data as the primary line. Upon failure of the primary line, the data path is switched over the sparing bus to the same bus interface previously used on the card that had the line failure. This data path switch-over takes less than 50 ms, but data and control messages in transit are lost on a switch-over.

OA&M One per PLMN MSS 7000 (incl. GPP IWF) and 15000 MVRs ERS 8600 management interface USP RTCs USP ICCMs USP RAS USP OA&M workstation SDM/FT management interface CBM cluster and individual units CEM Server W-NMS Performance Server W-NMS Main Server

Table 3-2 Subnet summary

Subnet Location Components included

—sheet 2 of 2—

411-2231-014 Standard 02.07 May 2006


APS is not supported on DS3 ATM interfaces. Equipment sparing on DS3 ATM interfaces required additional sparing panels to be installed.

ATM routing via PNNIThe MSS node supports dynamic routing over Private Network-to-Network Interfaces (PNNI).

MSS PNNI Version 1.0 standard protocol is used between ATM switches, and groups of private ATM switches. MSS PNNI includes two categories of protocols:

• A protocol defined for distributing topology information between switches and clusters of switches.

• A protocol defined for signaling and used to establish point-to-point and point-to-multipoint connections across the ATM network.

PNNI uses source routing. The first node in a connection decides the route that the call takes, and subsequent nodes forward the call setup message along this pre-determined route. If a subsequent node rejects the connection, call setup retraces the path to the originating node. The originating node uses alternate routing information and re-attempts call setup.

PNNI is utilized by the AN in the following situations:

• Inter-shelf communication utilizing SVCs.

• Inter-shelf communication when used in conjunction with Soft PVCs.

ATM addressing and connectionsATM end station addressesIn this address, ATM End Station Addresses (AESA) are supported in NSAP format only. Each 4pVSP4e is provisioned with its own unique AESA.

Permanent virtual channels and pathsA MSS permanent virtual connection is the combination of a permanent virtual path (PVP) and a permanent virtual channel (PVC). A permanent connection has a predefined static route that provides a permanently configured connection between the customer premise equipment and the ATM networks. Permanent connections are set up using predetermined user requirements for bandwidth and the duration of the connection.

Switched virtual connectionsA MSS switched virtual connection (SVC) supports the same functionality as permanent connections and provides dynamic provisioning for each node along the connection route. The connection route is automatically selected. MSS switched connections do not require configuration, but network nodes must be configured for ATM routing. MSS 15000 ATM switches in the ATM WAN relay existing connections; they do not originate or terminate them. The



4pVSP4e and 4p OC-3/STM-1 TDM FP can originate or terminate them. MSS nodes support point-to-point and point-to-multipoint connections which are dynamically set up and taken down on a call-by-call basis.

Soft permanent virtual circuitsMSS soft permanent connections (SPVPs and SPVCs) support the same functionality as permanent connections, but eliminate the need to manually provision each node along the connection. The end point is provisioned, but the route is automatically selected. Soft permanent connections support automatic route selection, connection establishment and re-establishment.

There are two main advantages of Soft PVCs over PVCs:

• Reduction of provisioning. The end points must be provisioned but any ATM switched in the network do not as they would for PVCs.

• Connectivity resiliency via dynamic rerouting upon ATM link/nodal failure.

SPVC and SPVP connections also support automatic route selection and connection establishment as well as re-establishment. In addition, for IPoATM traffic, SPVCs are only supported with PNNI. Therefore, only PNNI is supported with Soft PVC.

ATM service categoriesThe ATM Forum has defined a number of Service Categories, and the four most widely used are defined here.

Constant bit rateThe Constant Bit Rate (CBR) service category is used by connections that request a static amount of bandwidth that is continuously available during the connection lifetime. This amount of bandwidth is characterized by a Peak Cell Rate (PCR) value. The source can emit cells at the PCR at any time and for any duration and the QoS commitments still pertain. CBR service is intended to support real-time applications requiring tightly constrained delay variation (e.g., voice, video, circuit emulation).

Real-time variable bit rateThe Real-time Variable Bit Rate (rt-VBR) service category is intended for real-time applications, i.e., those requiring tightly constrained delay and delay variation, as would be appropriate for voice and video applications. rt-VBR connections are characterized in terms of a PCR, Sustainable Cell Rate (SCR), and Maximum Burst Size (MBS). Sources are expected to transmit at a rate that varies with time. Equivalently the source can be described as "bursty".

411-2231-014 Standard 02.07 May 2006


Non-real-time variable bit rateThe Non-real-time Variable Bit Rate (nrt-VBR) service category is intended for non-real-time applications which have bursty traffic characteristics and which are characterized in terms of a PCR, SCR, and MBS. For those cells which are transferred within the traffic contract, the application expects a low cell loss ratio. Non-real-time VBR service may support statistical multiplexing of connections. No delay bounds are associated with this service category.

Unspecified bit rateThe Unspecified Bit Rate (UBR) service category is intended for non-real-time applications, i.e., those not requiring tightly constrained delay and delay variation. Examples of such applications are traditional computer communications applications, such as file transfer and email. UBR service does not specify traffic related service guarantees. No numerical commitments are made with respect to the CLR experienced by a UBR connection, or as to the CTD experienced by cells on the connection. The UBR service is indicated by use of the Best Effort Indicator in the ATM User Cell Rate Information Element.

ATM network recommendationsWith respect to the ATM virtual circuit types and service categories used for signaling and bearer, Nortel makes the following recommendations:

• AAL2 bearer should be configured to use dynamic SVCs and the rt-VBR service category.

• AAL5 signaling (i.e. encapsulated IP signaling) should be configured to use SPVCs and the nrt-VBR service category.

• AAL1 CES backhaul of signaling should be configured to use PSVCs and the CBR service category.

• Q.2630 should be configured to use PVCs and the nrt-VBR service category.

Quality of service 3QoS in UMTS access networks

UMTS defines four traffic classes: conversational, streaming, interactive and background. However, most of these apply to packet domain services. The UMTS call server domain (and thus this BICN solution) assigns the conversational traffic class to all RABs.

QoS in the CO LAN/routerThis release supports best effort Quality of Service (QoS) for the ERS 8600 and all CO components.



QoS in ATM core networksQoS in the MGWThe MSS 15000 platform provides the base ATM services for the Nortel's MGW. As such, the MGW is able to take advantage of the advanced ATM Traffic Management capabilities of the MSS 15000, including:

• Compliance to ATM Forum Traffic Management 4.0

• Advanced queuing and scheduling, including inter-class, intra-class, and sub-connection scheduling

• Buffer management with features such as Weighted Fair Queuing, Random Early Discard, Partial Packet Discard, and per-VC Queuing

• Policing and Traffic Shaping

• Provisionable ATM Service Categories to emission priorities mapping

• Minimum Bandwidth Guarantees to avoid VC starvation

The MSS 15000 supports the four ATM Service Categories discussed in “ATM service categories” on page 3-18. ATM QoS is maximized via the recommendations provided in “ATM network recommendations” on page 3-19.

ATM Call Admission Control (CAC)ATM provides simplistic CAC mechanisms in the following manner:

• Provisioned VCCs are assigned traffic parameters based on call type (G.711 or AMR) and the maximum number of CICs. As long as the aggregate bandwidth consumed by these provisioned trunks carried over a particular interface does not exceed the bandwidth of the interface, there is no chance of overloading the link. New calls are blocked once the VCCs are fully utilized. This is very similar to TDM trunk selection.

• When using dynamic SVCs (dSVCs), the network must validate whether this is sufficient bandwidth available to meet the requested traffic parameters of the new trunk as each SVC is established. If bandwidth limits are exceeded, the SVC setup is rejected. This is facilitated by allowing only one CID per SVC on certain interfaces as discussed in the previous sections.

However, these mechanisms are made more complex by the support of compression and upspeeding in this release. For example, an AMR call could be admitted based on its bandwidth requirements, yet a subsequent upspeed to G.711 could exceed the bandwidth limits. This release adds the ability to provision the bandwidth allotted to each ATM network (based on NSAP address prefix) and to block new calls which would exceed this bandwidth. Calls requiring upspeeding will be allowed to exceed this allotted bandwidth, which fits the overall strategy of giving priority to existing calls over new calls.

411-2231-014 Standard 02.07 May 2006


The MGW performs CAC checks anytime a H.248 termination is added as well as any time the termination undergoes a codec change. If bandwidth is exhausted when the termination is added, the H.248 command will be rejected. If an upspeeding attempt results in the available bandwidth being exceeded, the upspeeding is still allowed. However, the new bandwidth requirements are used for subsequent H.248 termination additions.

The MGW is aware of its own bandwidth (between the Header Translator and AAL2 FPGA) and resource congestion (DSP availability). The MGW reports its congestion level to the (G)MSC Server. This allows the (G)MSC Server to avoid MGWs that are reporting 100% congestion due to bandwidth exhaustion.



411-2231-014 Standard 02.07 May 2006


Signaling protocols 4SS7 signaling 4

GSM A-interfaceThe BICN architecture in this release makes no changes to the actual BSSAP (BSSMAP and DTAP) application layer signaling carried over the A-interface. However, changes are made to the path this signaling takes when it first enters a MGW.

The GSM A-interface supports channelized signaling where the facility-associated SS7 F-links carrying the BSSAP signaling are transported in a timeslot in the same carrier with bearer channels. In legacy MSC Switch configurations the ENET/NIU is used to extract these SS7 signaling channels from the TDM trunks in the DTC/SPM and deliver them to the LIU7s terminating the SS7 links. This configuration is still supported at the (G)MSC Switch + Server for A-interface trunks hosted by DTCs/SPMs. However, this presents a problem for A-interface trunks hosted by MGWs, where there is an intervening packet network between the termination point of these TDM carriers (MGW) and the SS7 termination point at the MSC Server (LIU7 or USP).

For MGW-hosted A-interface trunks, there are two methods for backhauling this signaling from the physical A-interface POP to the MSC.

AAL1 CES backhaulThis solution applies only to ATM Core Networks which have deployed MG18 (4pVSP4e) prior to migrating the MSC's signaling interface from the FLPP/LIU7 to the USP.

The solution is to leverage the AAL1 basic structured Circuit Emulation Service (CES) capabilities of the 4p OC-3/STM-1 TDM FP that terminates the TDM carriers at the MGW. Up to 8 DS0s/timeslots per T1/E1 can be designated as carrying SS7 signaling and targeted for structured CES backhaul over the ATM network. This signaling is transported over the ATM network to the Central Office (CO), where the AAL1 CES is terminated and placed back on an OC-3/STM-1 TDM trunk then fed into an SPM. The ENET and NIUs are then used to connect to the LIU7s terminating the SS7 links.


4-2 Signaling protocolsNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

The MGW only terminates MTP1 on the A-interface and does no processing on any other layers in the protocol stack (MTP2 and above continue to terminate at the LIU7). MTP2 FISUs and HDLC flags flow unchecked and unimpeded from the BSS to the LIU7 via this same path. Therefore, failures in the ATM network or AAL1 SPVC loss will be detected via MTP2 timers at the BSS and LIU7.

Furthermore, once the 4p OC-3/STM-1 TDM FP has extracted the signaling timeslot for CES backhaul, the remaining bearer timeslots are looped back out of the card and fed into a 4pVSP4e for normal bearer processing.

The signaling flow and protocols involved at each node are illustrated in the following diagram. This example assumes an SPM is used at the CO, but a DTC could also be used (with a MUX between the (P)DTC and MGW shelf).

Figure 4-1 BSSAP signaling path - AAL1 CES backhaul

This method of signaling backhaul still requires the ENET and SPM or (P)DTC for channelized signaling purposes, even through the 4pVSP4e (MG18) has been deployed.

M2UA backhaulThis solution applies only to all ATM Core Networks which have deployed both MG18 (4pVSP4e) as well as the USP.

The solution is to leverage the M2UA capabilities of the 4pVSP4e and USP. The 4pVSP4e card terminates both MTP1 and MTP2 and backhauls MTP3 over SIGTRAN protocol M2UA (RFC 3331). The IP packet is encapsulated into ATM and routed over the Core Network to the CO, where the ERS 8600 will route the packet to an IP HSL (M2UA) card of the USP. The USP terminates MTP3 and routes the SCCP layer and above to the XACore.

411-2231-014 Standard 02.07 May 2006

Signaling protocols 4-3Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

Figure 4-2 BSSAP signaling path - M2UA backhaul for ATM CN

For M2UA, the USP is the SCTP client and the MGW is the SCTP server.

UMTS Iu-CS' (non-BICN) interfaceWhile this is not a BICN architecture, changes must be made to the RANAP signaling path in order to upgrade to a UMTS BICN architecture.

The legacy R99 UMTS architecture terminates the Iu interface at the MG3.0.2 MGW (sometimes referred to as the Wireless Gateway). This MGW performs the ASN.1 PER decoding/encoding of RANAP signaling and exchanges a proprietary Iu-CS' interface with the XACore which was sent on facility associated SS7 links. To the MSC, this appears very similar to the legacy GSM A-interface signaling.

For operators who want to migrate to UMTS BICN, migrating signaling to the USP is a prerequisite step. In this scenario, the following architecture is required.



Figure 4-3 PER-decoded RANAP signaling path

This architecture also applies to any operator who simply wants to evolve the signaling interface from the FLPP/LIU7 to the USP.

UMTS Iu-CS interfaceThe BICN architecture makes changes to the RANAP signaling, in terms of signaling path, transport protocols and encoding/decoding points.

With UMTS BICN, the ASN.1 PER decoding/encoding is moved to the XACore/MMU and the MG3.0.2 MGW is no longer involved in the signaling path. UMTS BICN requires the USP as the SS7 interface.

The solution leverages the M2UA capabilities of the 4pVSP4e and USP. The 4pVSP4e card terminates both layer one and two (Q.2140/AAL5/ATM) and then backhauls MTP3b over SIGTRAN protocol M2UA (RFC 3332). The IP packet is routed over the Core Network to the CO, where the ERS 8600 will route the packet to an IP HSL (M2UA) card of the USP. The USP terminates MTP3b and routes SCCP and above to the XACore.

411-2231-014 Standard 02.07 May 2006


Figure 4-4 RANAP signaling path - M2UA backhaul for ATM CN

For M2UA, the USP is the SCTP client and the MGW is the SCTP server.

ISUPSimilar to BSSAP, ISUP signaling can be carried on fully-associated T1/E1 trunks that share physical facilities with bearer. The options for how to carry this signaling to the MSC are similar to BSSAP (AAL1 CES or M2UA backhaul) shown in Figure 4-1 and Figure 4-2.

However, in North America quasi-associated signaling is more common. In this technique, the (G)MSC Switch + Server, acting as a Service Switching Point (SSP), accesses the SS7 network via one or more Signal Transfer Points (STPs), which are effectively routers for the SS7 network. SS7 links which connect SSPs to STPs are called A-links. The trunks which connect to the STPs carry only signaling and no bearer, thus these trunks will not feed into a MGW. They will connect directly to the MSC's SS7 interface.

The USP can offer a wide variety of ISUP signaling transport protocols, as shown in the following diagram.



Figure 4-5 ISUP quasi associated signaling path

For M3UA, the USP can be either the SCTP client or server.

BICCBICC is the signaling protocol used on the Nc interface in a BICN architecture when VoAAL2 is supported between MGWs controlled by different (G)MSC Servers, i.e. over the Nb interface. The signaling transport options for BICC are the same as ISUP, as shown in Figure 4-5.

BICC also introduces the ability to transport DTMF tones out of band between (G)MSC Servers when received via DTAP signaling from a mobile. For more information, please refer to “Out of band DTMF” on page 5-3.

D-channel based protocolsD-Channel based protocols (e.g. PRI) are not supported on MGW-based trunks. The BICN architecture does not change the support for D-channel based protocols at (P)DTC/SPM-based trunks.

CASThe CAS trunk supported on MGWs in this release is Multi-Frequency (MF). The method in which MF is supported depends on whether the TDM carrier enters the 4p OC-3 TDM FP or the 4pVSP4e card.

A T1 carrier must be entirely dedicated to MF. This T1 carrier cannot be shared with other trunk types.

AAL1 CES backhaulThis solution applies only to ATM Core Networks which have deployed MG18 (4pVSP4e) prior to upgrading the MSC to NSS18, or which still utilize DTC-based MF trunks for any reason after the NSS18 upgrade.

The solution is to leverage the AAL1 Unstructured clear-pipe (Ucp) Circuit Emulation Service (CES) capabilities of the 4p OC-3 TDM FP that terminates the physical MF trunk at the MGW. In this instance, AAL1 CES is used as a

411-2231-014 Standard 02.07 May 2006


transmission link. This signaling is transported over the ATM network to the Central Office (CO). At the CO, the AAL1 CES is terminated and placed back on an OC-3 TDM trunk, where it is then fed into a MUX and then to a DTC. Since MF is only supported on DTCs (not SPMs), the MUX is required to present a T1 interface to the DTC.

With Ucp CES, the framing signal is transported along with the T1 data as payload (no data link is extracted). The MGW does not do any processing on the MF payload. The signaling flow and protocols involved at each node are illustrated in the following diagram.

Figure 4-6 MF signaling - AAL1 CES

Note: The entire T1 must be dedicated to MF signaling, no fractional T1 configuration is allowed.

MGW termination and H.248 controlThis solution applies to all Core Networks which have deployed or upgraded to both MG18 (4pVSP4e) as well as the NSS18 on the MSC. In this configuration, the MF trunks can connect directly to the OC-3 TDM port on the 4pVSP4e to leverage its new MF functionality. The MF signaling is processed by the MGW, and MF signals, events and state information is exchanged between the MGW and MSC using H.248 packages.

Figure 4-7 MF signaling - H.248 control in ATM core network



This release supports MF on the BICN architecture for the sole purpose of e911 support. Specifically MF Type 2C signaling (models A, B, D and E) as well as POI-T8 signaling are supported.

The engineering limit for a 4pVSP4e card is 16 CAS trunks. They can be provisioned in a single, or multiple, T1 in the same 4pVSP4e card, but the total maximum is 16 CAS trunks in the VSP4e card.

MAPMAP-E signaling (between MSCs) could be channelized and share physical facilities with inter-MSC bearer. In this case, the MAP signaling could enter a MGW, where it would have to be backhauled via M2UA as shown previously.

The other MAP interfaces (C, D, etc.) typically use quasi-associated signaling links, as described in “ISUP” on page 4-5. In this case, the signaling path and transport protocol options are shown below.

Figure 4-8 MAP signaling

CAP signaling (between MSCs and SCPs) could be channelized and share physical facilities with inter-MSC bearer. In this case, the CAP signaling could enter a MGW, where it would have to be backhauled via M2UA as shown previously.

CAP signaling can also run separately from bearer. In this case, the signaling path and transport protocol options are shown in Figure 4-9.

411-2231-014 Standard 02.07 May 2006


Figure 4-9 CAP signaling

Mc interface protocols 4The BICN architecture decouples the control and user planes whereby PMs and the ENET are replaced by distributed Media Gateways (MGWs) and an ATM network. The (G)MSC Server controls the MGWs via Mc interface. The Mc interface allows the (G)MSC Server and MGW to exchange both call processing and non-call processing (maintenance) messages via an open interface.

Note: The Mc interface signaling is commonly referred to as "H.248."

The H.248 protocol is implemented on the XACore as well as the 4pVSP4e card of the MGW. Only UDP/IP transport is supported in this release.

The H.248 signaling leaves the XACore via the HIOP's/HCMIC's Ethernet interface. The ERS 8600 will then route the packet to a Aggregation Node (AN), which encapsulates the IP packet into ATM via Multi-Protocol Encapsulation (MPE).

Figure 4-10 H.248 signaling path - ATM CN

MGW shelves at the CO might have direct Ethernet interfaces and thus might not require the AN or intervening ATM WAN.



Application level framingLoss of H.248 messages can result in lost calls. In longer and more severe outages message loss can cause a loss of heartbeat with the MGW. Thus care must be taken to ensure message loss is minimized along the signaling path shown above, and that failures along the path are corrected as quickly as possible.

Parts of Application Level Framing (ALF) are supported in both the XACore and 4pVSP4e to provide enhanced reliability for H.248 transport.

MIP 4MSC/IWF Interface Protocol (MIP) is a proprietary signaling protocol used by the (G)MSC to control the GPP IWF for CSD services.

The GPP IWF supports only MIP v3. The path that this signaling takes depends on the architecture. In the legacy non-BICN architecture, EIUs provide the signaling interface for the (G)MSC as shown in the following diagram.

Figure 4-11 MIP signaling path prior to CSD migration

Once the CSD service has been migrated to the BICN architecture and the GPP IWF is directly connected to the MGW, HIOPs/HCMICs provide the signaling interface for the (G)MSC as shown in the following diagram.

411-2231-014 Standard 02.07 May 2006


Figure 4-12 MIP signaling path after CSD migration

User plane signaling protocols 4There are a few signaling protocols that are associated with both the Iu and Nb user plane interfaces.

Q.2630This ITU-T defined protocol, also known as ALCAP, supports the dynamic establishment and release of point-to-point AAL2 connections. Q.2630 is the BCP (Bearer Control Protocol) required on the Nb interface when BICC is the call control protocol that is being used on Nc to setup an AAL2 connection between two MGWs. Q.2630 signaling is used between MGWs controlled by different (G)MSC Servers, but not between MGWs controlled by the same (G)MSC Server.

Q.2630 is also used on the Iu interface, between the Core Network and the RNC.



Figure 4-13 Q.2630 signaling path (F-links)

Q.2630 is an SS7 protocol (MTP3b user) that is supported on both SS7 F-links and A-links. When F-links are used, each MGW on the Nb interface requires a point-to-point F-link to every other Nb MGW in the network that it might connect to. In large networks, an operator might prefer to use A-links and utilize a broadband SS7 STP (i.e. USP) to route this signaling, as shown in the following diagram.

Figure 4-14 Q.2630 signaling path (A-links and STP)

Iu/Nb UPWhile the Iu UP and Nb UP protocols have messages that are exchanged between certain network elements, they are carried inside the user plane connection after it has been established.

Iu UPIu UP is carried in-band once the Iu-CS bearer connection has been established via Q.2630. Iu UP runs between the RNC and the MGW that terminates the Iu interface.

411-2231-014 Standard 02.07 May 2006


This release supports the following Iu UP versions:

• Iu UP support mode version 1 for R99 RNCs

• Iu UP support mode versions 1 and 2 for R4 RNCs

• Iu UP transparent mode version 1 for all RNCs

Iu UP is used for four main functions: initialization, rate control, user data transfer, time alignment and error event reporting.

The MSC informs the RNC of what RAB Subflow Combinations (RFCs) are allowed for a call, and these RFCs are included in the Iu UP initialization message sent to the Core Network in the Iu user plane. For transparent mode data calls, the Iu UP is setup in transparent mode and therefore no RFCs are initialized on Iu.

The MGW will check for payload CRC errors for all voice calls. These are summed up and reported through the DSP call statistics report message. When received or generated, the DSP will generate internal voice quality degradation alarms.

Nb UPThis protocol very similar to Iu UP. It is carried in-band once the Nb/Nb' bearer connection has been established via Q.2630. Nb UP runs between any two MGWs in the Core Network, including what is sometimes referred to as the Nb' interface which runs between MGWs controlled by the same (G)MSC Server.

This release supports Nb UP mode version 2 for all calls.



411-2231-014 Standard 02.07 May 2006


Services 5This section does not provide details on every GSM/UMTS service and its implementation in a BICN architecture. Focus is given to the major bearer-related functionality and services that have been migrated to the MGW.

Supplementary services 5The majority of the supplementary services supported in legacy GSM/UMTS networks are also supported in BICNs. The table below summarizes this support for the more common supplementary services. The table columns indicate whether the service runs at GMSC Servers, VMSC Servers or across multiple GVMSC Servers.

Table 5-1 Common supplementary services supported in BICNs

Service GMSC VMSC Multi-MSC

Call Offering Services

Call Forwarding, Unconditional (CFU) X

Call Forwarding, Busy (CFB) X

Call Forwarding, No Reply (CFNRY) X

Call Forwarding, Not Reachable (CFNRC) X X

Call Forward Notification

Optimal Routing X X X

Explicit Call Transfer X

Call Completion Services

Call Waiting X

Call Hold / Call Retrieve X

—sheet 1 of 2—


5-2 ServicesNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

Multi Party X

Extension Services X

Call Intercept X X

Call Restriction Services

Anonymous Call Rejection (ACRJ) X

Barring of all Outgoing Calls (BAOC) X

Barring of Outgoing International Calls (BOIC) X

Barring of Outgoing International Calls except those directed to HPLMN (BAOC-exHC)

X

Barring of Outgoing Calls when roaming outside the HPLMN (BAOC-roam)

X

Barring of all Incoming Calls (BAIC) X

Barring of all Incoming Calls when roaming outside the HPLMN (BAIC-roam)

X

Barring of Outgoing Premium Rate Calls X

Barring of Supplementary Services Management X

Call Barring Notification to Calling MS X

Call Forwarding Fraud Detection X

Local Calls Only (LCO) X

Local Call Detection (LCD) X X

Operator Determined Barring (ODB) X X

Supplementary Services Barring X

IN

IP Interaction X X

Call Re-origination X X

Table 5-1 Common supplementary services supported in BICNs

Service GMSC VMSC Multi-MSC

—sheet 2 of 2—

411-2231-014 Standard 02.07 May 2006

Services 5-3Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

Tones 5The MGW supports the ability to play a finite number of tones towards any TDM or AAL2 port, per H.248 instruction from the (G)MSC Server.

Downloadable tones are not supported. The MGW maintains an internal tone table where tones and all characteristics must be statically provisioned. The (G)MSC Server identifies the tone to be played via the appropriate H.248 package. Only the following tones are supported at the MGW in this release:

• All DTMF tones

• Ringing tone

• Busy tone

• Congestion tone

• Special Information tone

• Held tone

• High tone

• Call Limit tone

• Vacant tone

• Comfort

• Continuity

• NACK

• Apply Charging tone

• CAMEL Prepaid Warning tone

In the previous BICN release, tones were subject to audible distortion due to having to be restarted during a handover. This release fixes this behavior and removes any negative impact of handover upon tone play.

Tone detection is not reported by the MGW. If tone detection is required for a particular service, a connection must be setup to an Intelligent Peripheral (IP).

The MGW is capable of detecting baudot tones (for TTY) and fax/modem tones and will upspeed to G.711 if necessary.

There is no change to tone generation on PMs.

Out of band DTMFDTMF tones deserve special mention as this release supports the ability to send and receive DTMF tone information out of band on the Nc interface via BICC signaling.



DTMF Start and Stop signals are already received out of band from the mobile on the A and Iu interfaces. In previous releases, the MSC or MSC Server which received the DTMF Start/Stop signals would apply these locally at a PM or MGW respectively. However, with the introduction of BICNs and Core Network compression, BICC has defined a method of carrying the DTMF signaling around the compressed speech so that it can be inserted into the user plane at the point where G.711 transcoding occurs. This is because packet loss and AMR transcoding can impact DTMF integrity

Figure 5-1 Out of band DTMF via BICC

It should be noted that the BICC specification allows a duration to be specified with a DTMF Start signal. If received, the (G)MSC Server will set the appropriate timer and order the MGW to stop the DTMF tone when the timer expires; no Stop Signal via BICC is expected. The Nortel MSC Server will never send the duration value; it will always send an explicit Stop Signal via BICC.

If codec negotiation results in G.711 being used on the Nb interface, then BICC is not used to carry any DTMF tone information. Tone insertion occurs at the same place as NSS17/MG17 as illustrated in the diagram below.

Figure 5-2 Out of band DTMF with G.711 on Nb

411-2231-014 Standard 02.07 May 2006


Furthermore, while mobile terminated DTMF is labeled as For Further Study in 3GPP specifications, DTMF tones will be played in the downlink direction from an A-interface or Iu-interface termination in this release if applicable (e.g. for a mobile-to-mobile call).

Announcements 5The MGW supports the ability to play simple non-broadcast announcements towards any TDM or AAL2 port. Therefore the need to play an announcement does not require any changes to the bearer connection topology or the insertion of an announcement server.

Announcements are created on the Audio Provisioning Server (APS) and sent via FTP to the CP3 cards of each MSS 15000 shelf that hosts 4pVSP4e FPs. Once an announcement is provisioned on a MGW, the announcement is sent from the CP3 to local memory on the SSM processor of the 4pVSP4e. Once the MGW (specifically the SPM of the 4pVSP4e) receives H.248 signaling instructing to play an announcement, the SSM is instructed to spool the announcement to the appropriate DSP for insertion into the media stream.

The following restrictions and limitations exist for MGW-based announcements in this solution:

• Each MGW can support storage for up to 120 minutes of announcements.

• Each MGW can support the provisioning of 2048 different announcements.

• Each MGW can play no more than 200 announcements simultaneously.

• The following are not supported: audio variables, announcements made up of multiple audio segments or prompt and collect.

In the previous BICN release, announcements were subject to audible distortion due to having to be restarted during a handover. This release fixes this behavior and removes any negative impact of handover upon announcement play.

Circuit switched data 5For CSD in a BICN architecture, the GPP IWF continues to exist only on the Passport 8380G platform. However, this release supports the migration of the GPP IWF trunks off of DTC-hosted T1 trunks and onto MGW-hosted trunks. Furthermore, MIP signaling to control the GPP IWF is migrated off the EIU and onto the HIOP/HCMIC. This removes the CSD dependencies on a number of legacy components: EIU, DTC and ENET.

For a period of time after the upgrade to NSS18, CSD will continue to function as it did in the NSS17 BICN release. In this architecture, GPP IWF trunks are connected to (PDTCs and MIPv3 signaling is sent via EIUs. For



any CSD calls involving parties on MGW-hosted trunks, CFIWF insertion is required to interwork to the ENET-hosted DTC that provides the mobile- or network-side Universal Interworking Trunk (UIT). The following diagram shows a 2G CSD call between a MGW-hosted trunk and an SPM-hosted PSTN trunk.

Figure 5-3 CSD architecture with DTC-hosted GPP IWF

The new CSD architecture supported in this release removes dependencies upon the EIU, DTC and ENET.

Only a small subset of the 4pVSP4e FPs is expected to have GPP IWF connectivity and it is recommended that these components be co-located to minimize the UIT TDM trunking facilities required.

411-2231-014 Standard 02.07 May 2006


Figure 5-4 CSD architecture with MGW-hosted GPP IWF

Note: The mobile- and network-side UITs are shown on the same MGW, but they may be on separate MGWs depending on provisioning.

It should be noted that CFIWF insertion is not supported on the new CSD architecture. Therefore this migration from (P)DTC connectivity to MGW connectivity cannot occur until all other trunks are MGW-based.

It should also be noted that up to six MSCs can share a single GPP IWF. In this configuration, at least some of the MSCs will not be co-located with the GPP IWF and the MIP signaling is sent over an IP WAN. This release allows continued use of whatever IP WAN is currently in place in the operator's network, with the only requirement being the migration of this signaling from the EIU to HIOP/HCMIC. Alternatively, the MIP signaling can be encapsulated in the ATM network as shown in the following diagram.



Figure 5-5 Remote GPP IWF and MIP over ATM

When multiple MSCs support a single GPP IWF, each MSC must have dedicated TDM trunks connecting to the GPP IWF.

The BICN architecture supports the following bearer services for GSM access, whereby "T" indicates transparent and "NT" indicates non-transparent. All of these CSD call types require GPP IWF insertion.

Table 5-2 Supported GSM CSD bearer services

Bearer Service Description 3.1kHz Fax Grp 3

T NT T NT

14400 bit/s asynchronous X

—sheet 1 of 2—

411-2231-014 Standard 02.07 May 2006


Note: For all alternate speech and data or fax services, the data or fax portion of the call is 3.1kHz only by definition of the GSM specifications. Furthermore, DTAP is the only protocol which defines an ITC (Information Transfer Capability) for fax.

For the "dual services" (i.e. alternate speech and data, speech followed by data, alternate speech and fax), the GPP IWF is switched into and out of the bearer path as the user alternates between speech and data/fax. The UITs remain allocated throughout the life of the call, even when operating in speech mode. The MSC Server initiates H.248 commands to change the bearer configuration between the two topologies shown below.

300 bit/s asynchronous X X





Alternate speech and data X X

Alternate speech and fax X X

Fax Group 3 X X

Speech followed by data X X

Table 5-2 Supported GSM CSD bearer services

Bearer Service Description 3.1kHz Fax Grp 3

T NT T NT

—sheet 2 of 2—



Figure 5-6 Alternating between speech and data/fax

The BICN architecture supports the following bearer services for UMTS access, although not all require the use if a GPP IWF.

Table 5-3 Supported UMTS CSD bearer services requiring IWF

Bearer Service Description 3.1 kHz UDI

T NT T NT


411-2231-014 Standard 02.07 May 2006


For the latter scenario where no GPP IWF is required, the bearer topology is the same as that of a voice call.

Conferencing 5The BICN architecture makes no functional changes to conferencing, and the following multiparty specific functionality is still supported:

• Multiparty Hold

• Multiparty Split

• Multiparty Retrieve

• Multiparty Add

However, this release supports the migration of the conference circuits off of the ENET-based Conference Trunk Modules (CTM) and onto conferencing capable MGWs. This removes the multiparty service's dependencies on a number of legacy components: CTM and ENET.

For a period of time after the upgrade to NSS18, conferencing will continue to function as it did in the NSS17 BICN release until conferencing-capable MGWs are provisioned and brought into service. In this architecture, 3-port or 6-port conference bridge resources on the CTM are utilized. For any multiparty calls involving parties on MGW-hosted trunks, CFIWF insertion is required to interwork to the ENET-hosted CTM that provides the conference bridge. The following diagram shows a 3-port conference between two MGW hosted trunks (each requiring a CFIWF) and one ENET-hosted trunk.

Table 5-4 Supported UMTS CSD bearer services not requiring IWF

Bearer Service Description 3.1 kHz UDI

T NT T NT

64 kbit/s asynchronous X



Figure 5-7 Conferencing architecture with CTMs

It should be noted that for conferencing, any required CFIWFs are inserted mid-call when the multiparty feature is invoked. From zero to six CFIWFs could be required.

The new conferencing architecture supported in this release removes dependencies upon the CTM and ENET. The MGW-hosted conference bridges support both 3-port and 6-port conferencing capabilities. Only a small subset of the 4pVSP4e FPs is expected to have conferencing capabilities, and these are identified via (G)MSC Server provisioning. The following diagram shows a 3-port conference between three MGW hosted trunks.

411-2231-014 Standard 02.07 May 2006


Figure 5-8 Conferencing-capable MGW architecture

Both CTM- and MGW-based conference circuits are allowed to co-exist. The type of conference bridge allocated is based on the connection fabric type of the pathend seen by the MPTY software as well as availability of a conferencing-capable MGW. Four scenarios exist:

• Pure TDM - All trunks joining the conference are on ENET-hosted trunks. A CTM-based conference circuits is used and no CFIWFs are required.

• Pure packet - All trunks joining the conference are on MGW-hosted trunks. A MGW-based conference circuit is used and no CFIWFs are required.

• Mixed fabric with TDM controller - There is a fabric type mismatch between trunks joining the conference, but the MPTY controller is on a ENET-hosted trunk as seen by the MPTY software (i.e. this could be a PM-hosted access trunk, or a MGW-hosted access trunk with a CFIWF inserted on its network side). A CTM-based conference bridge is used. Any other conference parties on MGW-hosted trunks require CFIWF insertion. If no CTM-based conference bridge is available, the MPTY service will fail



• Mixed fabric with packet controller - There is a fabric type mismatch between trunks joining the conference, but the MPTY controller is on a MGW-hosted trunk as seen by the MPTY software (i.e. this could be a MGW-hosted access trunk, or a PM-hosted access trunk with a CFIWF inserted on its network side). A MGW-based conference bridge is used. Any other conference parties on ENET-hosted trunks require CFIWF insertion. If a MGW-based conference bridge is not available, fallback to a CTM-based conference bridge is supported.

MGW-based conferencing is supported with both uncompressed G.711 speech as well as compressed AMR/AMR2 speech.

It should also be noted that conferencing capable MGWs are also used by the Lawful Intercept service. For more information, please refer to “Lawful Intercept” on page 5-14.

Lawful Intercept 5The BICN architecture makes no functional changes to Lawful Intercept (LI). However, this release supports the migration of the bearer path tapping and replication functionality off of the ENET and onto MGWs. This removes the LI service's dependencies on a number of legacy components: ENET and DTC/SPM.

Initially after the upgrade to NSS18, LI will continue to function as it did in the NSS17 BICN release. For any calls targeted for LI which involve a target or associate on MGW-hosted trunks, CFIWF insertion is required to interwork to the ENET which remains responsible for multicasting the bearer path to Law Enforcement Agency (LEA) trunks. The following diagram shows the architecture required for the ENET to tap a LI target and associate party both on MGW-hosted trunks. The diagram assumes separate Call Content Channels (CCCs) and shows only a single tap for target and associate parties, but there could be many.

411-2231-014 Standard 02.07 May 2006


Figure 5-9 Architecture with ENET tapping

The new LI architecture supported in this release removes dependencies upon the PMs (DTC or SPM) and ENET. Three different MGW functions are required for LI:

• LI bicast - This refers to the bicast (i.e. tapping) of the target and associate bearer paths. This tapping function typically occurs in the MGW closest to the target party's access trunk, although certain service interactions change this. These bearer taps are passed on to the LI fanout function.

• LI fanout - This refers to bearer fanout (i.e. replication) of the tapped target and associate bearer streams. Replication of target and associate streams occur separately, although they may occur in the same MGW. The size of each fanout depends on the number of LI target types (IMSI, MSISDN, IMEI) and the number of LEAs. For each target type, a maximum of five LEAs can be provisioned. However, the number of replications is limited to 15 in this release, with IMSI and MSISDN target types getting priority over IMEI. MGWs capable of fanout are provisioned at the (G)MSC Server. The replicated bearer streams are passed to MGWs hosting the physical trunk to the LEA (for separate CCC) or to the LI combining function (for combined CCC).

• LI combining - This refers to the combining of target and associate bearer streams for combined CCCs, which enables the full duplex speech conversation to be delivered to the LEA on a single physical circuit. Separate CCC does not use this function. Conferencing MGWs handle this function on behalf of LI and are provisioned at the (G)MSC Server.

It should be noted that LI combining (i.e. conferencing) and LI fanout can be supported at the same MGW by provisioning a single MGW with both



capabilities. However, these functions cannot coexist with any other MGW type. The following diagrams depict the new LI architecture for Separate and Combined CCC respectively.

Figure 5-10 LI architecture with MGW tapping - separate CCC

411-2231-014 Standard 02.07 May 2006


Figure 5-11 LI architecture with MGW tapping - combined CCC

Global text telephony 5Global Text Telephony (GTT) is a service used by the hearing- and speech-impaired. The FCC of the U.S. government has mandated the use of the ITU-T V.18 standard for 911 calls from mobiles connected to a GTT device. However, AMR transcoding corrupts the frequencies used by ITU-T V.18. 3GPP has defined a new modulation scheme called Cellular Text Telephone Modem (CTM) for use on AMR-compressed paths. The CTM modem translates between baudot characters defined by ITU-T V.18 and a modulation scheme compatible with AMR.

For UMTS calls, indication that CTM is enabled is carried in DTAP signaling. When received by the MSC Server, it will instruct the MGW terminating the Iu interface to insert a Cellular text Telephone Modem (CTM). Every MGW DSP is capable of this CTM modem function. Furthermore, any MGW in the call will be able to detect baudot tones on its G.711 endpoints and disable all voice quality features for the life of the call if and when a baudot tone is detected. This prevents corruption of the baudot tone.



Figure 5-12 UMTS BICN support for CTM

For GSM calls, the conversion to baudot is performed in the BSS, so a CTM is not required in the A-interface MGW. CTM-capable CIC pools are provisioned on the MSC. The MGW employs a baudot detector for all G.711 encoded terminations and disables voice quality features when a baudot tone is detected.

Figure 5-13 GSM BICN support for CTM

411-2231-014 Standard 02.07 May 2006


GTT is not supported for R'99 UMTS calls connected to a MG3.0.2 MGW, as there is no support for inserting a CTM modem in the Core Network.

Additionally, some legacy signaling protocols such as BICC and ISUP cannot indicate that baudot tones will be present in the user plane. As mentioned previously, all MGWs will be able to detect incoming baudot tones on G.711-encoded bearer paths. Once detected, if that MGW is performing AMR/AMR2 transcoding, the MGW will autonomously upspeed to G.711 to allow safe transmission of the baudot tone.



411-2231-014 Standard 02.07 May 2006


OAM&P 6FCAPS strategy 6

Fault managementThe strategy for fault management is to consolidate the faults for the MSC, MGWs (and CFIWF), the Audio Provisioning Server (APS), (optionally) the MSS 15000 ATM backbone NEs, and ERS 8600 CO LAN devices into the Core Element Manager (CEM). The CEM provides a single alarm list for viewing faults from these NEs and provides a sub-component viewer, which is populated via CEM's auto-discovery capability.

To manage the MSC, the CEM connects to the SDM or CBM 850 (co-located with each MSC) to perform resource discover and to collect DMS logs. DMS logs are mapped in to a common TMN-based alarm format on the CEM.

Multi-service Data Manager (MDM) is the element manager for the MSS family of products, and has been integrated into CEM for management of the MGW, CFIWF and any other MSS 15000 or 7000 nodes. MDM also allows fault management of SNMP devices via device integration "cartridges". An existing cartridge for the ERS 8600 is used to enable fault monitoring of the CO LAN. A new cartridge was developed, specifically for BICN, to allow fault monitoring of APS.

CEM uses MDM's ASCII APIs to perform resource discovery and fault monitoring of MDM-managed devices.

The following diagram illustrates this architecture in standalone CEM Server deployments.

Note: NSS18 is the last supported release for standalone CEM.


6-2 OAM&PNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

Figure 6-1 Standalone CEM fault management architecture

In W-NMS, the CEM processes described above integrate into the NSP fault management applications and through NSP into the 3GPP FM CORBA interface. The NSP fault applications provide archival and browsing of at least 30 days of active and cleared historical alarms. In addition, basic alarm correlation capabilities in NSP support capabilities including alarm severity modification, management of toggling alarms and thresholding of alarms.

The following diagram illustrates this architecture in W-NMS server deployments.

411-2231-014 Standard 02.07 May 2006

OAM&P 6-3Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

Figure 6-2 W-NMS fault management architecture

Fault detection is performed by the alarm reporting mechanisms within CEM: an operator may monitor the alarm list for new alarms; as well, the alarm status (most severe alarm level) is displayed for each subcomponent in the subcomponent viewer. Both of these serve as a "first-alert" mechanism.

A number of mechanisms facilitate fault isolation. First, it is possible to filter the alarm list to show only alarms for a selected sub-component (or for itself and children). Second, the subcomponent viewer often allows one to see visually relationships among components which may be affected by the fault. This may be a parent-child relationship, or among "sibling" subcomponents at the same level. As well, CEM can for certain components, allow navigation directly to "associated nodes."

Alarms for the DMS-MSC are specified in NTP 411-2231-510, GSM MSC / UMTS CCN CS Log Reference Manual. MG, and all MSS alarms, are



documented in NTP 241-5701-500 Passport 6400, 7400, 15000, 20000 Alarms.

Configuration managementConfiguration management for BICN has several components:

• Bulk provisioning of the MSC is expected to be performed by conventional mechanisms, such as DMOPRO scripts created by engineering to support the commissioning of a new switch.

• For incremental changes to configuration on the DMS, CEM provides a graphical table editor, allowing viewing and editing of any DMS table. This requires the operator to have a DMS login id/password.

• MGW and CFIWF provisioning can be performed via MDM Nodal Provisioning templates. These templates are supplied by Nortel, but may be edited by the customer. Templates are invoked to provisioning a specific MSS through the MDM Nodal Provisioning GUI application. For mass provisioning, it is more efficient to use CDL. For more information on CDL, refer to NTP 411-2231-331, R4 Media Gateway OAM and Troubleshooting Guide.

• Announcement files in the MGW are provisioned via APS.

• For tasks requiring coordination of datafill between the (G)MSC Server and the MGW, CEM provides graphical "wizards" to add or remove an H.248 MGW in the (G)MSC Server in table GWINV, to add or remove R4 trunk groups/members, and to audit consistency between the (G)MSC Server datafill and the MGW datafill.

• CEM also provides wizards to support the migration of an existing MSC to BICN: to create or delete CFIWF trunk groups/members and the migrate existing trunks from a (P)DTC or SPM to a MGW.

• CEM has wizards for tasks not specific to BICN: adding or removing SS7 links/linksets/routesets and for adding or removing (P)DTC or SPM-based trunk groups/members.

Performance managementThe goal is integration of performance management for all devices via CEM:

• CEM collects MSC operational measurements (OMs) via connection to the SDM or CBM 850. OMs are collected on each switch transfer period, typically 15 minutes.

• CEM collects MGW and AN counters via MDP. This is used to collect base LP (Logical Processor) and ATM counters from the MGW.

• The 3GPP XML Data Interface on the W-NMS Performance Server formats the counters collected by CEM into 3GPP XML format files, which may be retrieved by an OSS through FTP.

411-2231-014 Standard 02.07 May 2006


• MDM Perf Viewer is used to view operational counters on the MGW. This is due to a limitation in MGW software that no collected statistics are available for the VSP card, only operational statistics.

• CEM provides an ability to query data over time, with presentation of the data as a graph or text.

• Thresholds may be set against counters, to allow an alarm to be raised or cleared when a threshold is crossed. Multiple thresholds may be set to allow reporting of alarms at different severities. For BICN, thresholding is supported for:

— MSC

— MGW

— AN

Accounting managementBilling records are transferred from the MSC to the SBA (SDM Billing Application) application on the SDM or CBM 850. SBA allows transfer of the CDRs in files to a Billing System over FTP. If the DS-512 link to the SDM is down, if CBM cannot communicate with the XACore via the HIOP/HCMIC links or if the SBA application falls behind or is not running, billing records are buffered on the switch.

Security managementUser security is provided in the OA&M applications. A user must login with a valid user id and password, validated via LDAP, and the group a user is a member of restricts the operations a user can perform in the CEM GUI (e.g. if a user is only an observer, can acknowledge and clear alarms, can make configuration changes, etc.). Within the W-NMS solution, the LDAP server is internal to the W-NMS servers; for the standalone CEM server, the customer must supply an external LDAP server.

As well, both the DMS (mapci) and MSS require a user id and password. Within CEM, configuration management, table access and the wizards, will require a user to have a DMS password, and for the BICN wizards, a Passport password as well.

Provisioning walkthroughs 6System-level

From an OAM perspective, the following steps must occur in provisioning a (G)MSC Server:

1. (G)MSC Server must be provisioned (all non-BICN-specific configuration).

2. CEM Server or W-NMS and APS server should be installed.



3. CO LAN must be installed and configured. OAM traffic should be segregated into a separate VLAN from call processing traffic.

4. MGW/AN shelves (local and remote) must be installed, and connected to the OA&M LAN/WAN (CO LAN, for the local MGW/AN shelves).

5. Provisioning of the MGW shelves is performed via MDM. At this point, the MGWs can be fully managed via MDM and CEM.

6. Use CEM wizards to add H.248 MGWs to table GWINV in the MSC.

This wizard coordinates the provisioning of the MGW's MID, ensuring that this field in table GWINV is consistent with the MID provisioned on the Passport.

A naming convention for the MID has been established: the MID shall contain the MSS shelf name (the NE name in MDM and CEM) plus the instance number of the nsta component on the VSP card. This convention is enforced by the CEM’s "Add MG" wizard and by CEM's audit wizard.

7. CFIWF trunk groups and members must be created using the CEM wizards.

8. Use CEM wizards for migration of existing trunks from DTC/SPM to MGW.

9. Use CEM wizards to add new MGW-based trunk groups/members.

Trunk provisioningThe preconditions for using the "Add BICN trunk group" and "Add BICN trunk member" wizards are:

• The MGW has been fully configured via MDM (using the Nodal Provisioning Templates).

• The 4pVSP4e cards (MGWs) have been added to table GWINV.

Detailed steps on using the CEM BICN trunk provisioning wizards are provided in NTP 411-8111-503, GSM / UMTS Voice Core Network OAM User Guide.

No special wizard is provided for provisioning of MF trunks supported via AAL1CES on a MGW.

OSS Interfaces 6CEM provides two Operations Support System (OSS) interfaces:

• OSS Converter ASCII interface - The ASCII interface allows an external system to connect to CEM via a TCP/IP socket to perform resource discovery, alarm re-synchronization, and to receive asynchronous notifications of alarms, object creation/deletes, and state changes. The

411-2231-014 Standard 02.07 May 2006


interface also allows manual alarm clearing and alarm acknowledgements.

• Performance Management Mass Export - Mass export allows periodic transfer of OM data files via FTP to an external system.

These interfaces are described in the NTP 411-8111-503, GSM / UMTS Voice Core Network OAM User Guide.

W-NMS supports the following OSS interfaces:

• 3GPP CORBA Fault management and Basic CM Integration Reference Point (IRP) interfaces, which allow alarm delivery, alarm resynchronization, and reporting the set of NEs being managed

• 3GPP Performance Management XML



411-2231-014 Standard 02.07 May 2006


Scalability and capacity 7Scalability 7

(G)MSC serverThe following table summarizes the scalability of the (G)MSC Server components.

Note 1: Refer to “XACore” on page 2-1 for information on the rules governing whether HIOPs and/or HCMICs are required.

Note 2: The (G)MSC Switch + Server allows for 2048 CIWF and 2048 MIWF trunk groups to be provisioned (each CFIWF requires both a CIWF and MIWF). Given that each trunk group allows a maximum of

Table 7-1 (G)MSC Server Component Scalability

Component Scalability Information

PE Up to 10 supported in a 9+1 Atlas configuration for VMSC or GVMSC. Up to 6 supported in a 5+1 Atlas configuration for dedicated GMSC.

SM Up to 10 supported.

HIOP Single pair supported (optional). See Note 1.

HCMIC Single pair supported (optional). See Note 1.

FLPP Up to 7 supported.

LIU7 Up to 180 supported.

MMU Up to 14 supported, after which XACore-based Virtual MMU is used.

ENET Up to 128K ports supported.

PMs/SPMs Limit based solely on ENET ports.

CFIWF Up to 2048 supported. See Note 2.


7-2 Scalability and capacityNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

2048 trunk members to be provisioned, the number of CFIWFs is limited only by the number of MG ports available to dedicate to CFIWF traffic.

MSS 15000The following table summarizes the scalability of the MSS 15000 components.

Note: Up to 255 total MGWs can be provisioned on the (G)MSC Server.

MSS 7000The following table summarizes the scalability of the MSS 7000 components:

Table 7-2 MSS 15000 Component Scalability


4pVSP4e Up to 255 supported per (G)MSC Server (see Note)

Up to eight supported per MGW shelf

Up to four SCTP connections per 4pVsp4e

Up to 84 T1s or 63 E1s per 4pVSP4e

AN 1 at CO (optional) and 1 at each remote site (optional)

VCCs 4096 VCCs per 4pVsp4e

500 PVCs per 4pVSP4e

Table 7-3 MSS 7000 Component Scalability


MSA32 FP Up to 7 supported per shelf (this assumes two-slot cards are used).

CES service instances Up to 500 are supported per MSA32.

411-2231-014 Standard 02.07 May 2006

Scalability and capacity 7-3Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

Ethernet routing switch 8600The following table summarizes the scalability of the ERS 8600 components:

USPThe following table summarizes the scalability of the USP components:

Note: The combined number of HSLs cannot exceed 124.

Table 7-4 ERS 8600 Component Scalability


ERS 8600/8010co Exactly 2 required per (G)MSC Server

8691SF CPU/Switch Exactly 1 required per 8010co

8632TXE Exactly 2 required per 8010co

8648TXE 0 to 6 supported per 8010co, per 10/100bT port requirements

Table 7-5 USP Component Scalability


CAM shelf 1 to 8 supported

RTC system node 2 mandatory

CC system node 2 to 16 supported (2 per CAM shelf)

Application nodes (SS7 link, IPS7 gateway)

Up to 126 supported

SS7 link system nodes Up to 126 supported

ATM HSLs Up to 124 supported. See Note.

IP HSLs Up to 124 supported. See Note.

E1 MTP2 HSLs Up to 124 supported. See Note.

IPS7 gateway nodes Up to 16 supported

ICCM 2 are mandatory for USP configurations requiring 3 or more CAM shelves



Capacity 7(G)MSC server

HIOP capacity is not expected to be a bottleneck, although certain high capacity configurations require the installation of both a pair of HIOPs and a pair of HCMICs.

BICN has no impact on MMU capacity.

Media gatewayA MG18 capacity tool exists to compute 4pVSP4e BHCA under a specific call model with blocking probability assumptions. In addition, the user can specify the network configuration as well as the coexisting MGW personalities.

MGW I/O capacitiesThe following table summarizes the supported capacity of the various I/O cards supported in this release. For each card, the channel capacity is provided, which for I/O is equivalent to the number of G.711 or AMR (12.2kbps is always assumed) bit streams that can be simultaneously carried. The equivalent BHCA, assuming the Nortel UMTS Standard Call Model (NUSCM) version 4.5, is also given.

Table 7-6 MG18 I/O Capacities

Component Capacity

4p OC-3/STM-1 ATM FP 1,412 G.711 channels/port

5,648 G.711 channels/FP

6,788 AMR channels/port

27,152 AMR channels/FP

16p OC-3/STM-1 ATM FP 1,412 G.711 channels/port




411-2231-014 Standard 02.07 May 2006


4pVSP4e capacityThe capacity of a 4pVSP4e is dependent on numerous factors: interface types supported (Iu, Nb, A, Ai, CFIWF, MF), number of transcodings, number of handovers, etc. 4pVSP4e capacities in this release are based on 52 DSPs/FP with 2 DSPs in IDLE mode. There is an additional limit of 42 transcoding channels/DSP.

Conferencing capacityThere is a maximum of 300 conference bridges available per 4pVSP4e.

Lawful intercept target capacityThe following table presents a summary of the LI targets supported per 4pVSP4e assuming 15 LI replications (5 each for IMSI, MS-ISDN and IMEI), based on various rations of Combined Call Content Channels (CCCs) and Separate CCCs. This assumes the 4pVSP4e is dedicated to LI replication.

12p DS3 ATM FP 384 G.711 channels/port




4p OC-3/STM-1 TDM FP 2,016 TDM channels/port

8,064 TDM channels/FP

2p GP Dsk 2.4M BHCA/FP

Table 7-7 LI targets per 4pVSP4e

Separate CCC % Combined CCC % LI Targets

0 100 21 (G.711)

84 (AMR)

25 75 26 (G.711)

104 (AMR)

Table 7-6 MG18 I/O Capacities

Component Capacity



In addition to the 4pVSP4e that handles the LI replication fanout, there is a limit on the number of LI taps that can be established at the access MGW. This limit is 600 taps per 4pVSP4e.

Announcement capacityThe 4pVSP4e supports a maximum of 200 simultaneous announcements.

USP capacityThe USP has the following capacity related restrictions:

• Support for both HSLs and LSLs on the same linkset is restricted to the cutover from LSL to HSL. Such supported is not provided during normal operations, nor is it provided during software upgrades.

• The provisioning of ATM HSLs and IP HSLs (M2UA, M3UA) on the same linkset is not allowed.

• The provisioning of M3UA IP HSLs with any other link type in the same linkset is not allowed.

The USP supports a maximum of 126 SS7 Link Nodes, although only a total of 512 SS7 links is supported. Therefore, all SS7 Link Nodes cannot be fully utilized. Furthermore, only 126 of the 512 SS7 links supported can be HSLs.

A maximum of 16 links per linkset is supported for all link types.

40 60 31 (G.711)

122 (AMR)

50 50 35 (G.711)

138 (AMR)

60 40 41 (G.711)

162 (AMR)

100 0 103 (G.711)

240 (AMR)

Table 7-7 LI targets per 4pVSP4e

Separate CCC % Combined CCC % LI Targets

411-2231-014 Standard 02.07 May 2006


Low speed link capacityThe following factors determine the maximum supported traffic in a SS7 Link System Node:

• Number of SS7 links supported

• Link speed (56kbps vs. 64kbps)

• Number of messages per second

• Average message size

The tables below capture the message throughput of the USP as a function of number of SS7 links, message size, link speed and link occupancy. Note that in all tables, message throughput counts only incoming messages to avoid "double counting".

Table 7-8 SS7 message throughput (@56kbps)

480 SS7 links 0.4 E 0.8E

100% 25 byte 193.54 387

100% 40 byte 121 242

100% 80 byte 60.6 121

100% 279 byte 17.34 34.68

Table 7-9 SS7 message throughput (@64kbps)

480 SS7 links 0.4 E 0.8 E

100% 25 byte 190.68 381.36

100% 40 byte 138.24 276.48

100% 80 byte 69.12 138.24

100% 279 byte 19.82 39.64



The 8-link Channelized E1/T1 card has the capacity of eight LSLs.

ATM HSL capacityThe following table shows the relationship between the message length, number of ATM cells, and the engineering limits (messages per second) for the ATM HSL. The table also provides the DS0A equivalency between the ATM HSL and a LSL.

Table 7-10 Link system node MSUs at maximum engineering rate (on 56kbps link)

Avg Msg Length (Bytes)

MSUs per SS7 Link System Node

MSUs per SS7 Link

25 1792 224

40 1120 140

80 560 70

279 160 20

Table 7-11 Link system node MSUs at maximum engineering rate (on 64kbps link)

Avg Msg length (Bytes)

MSUs per SS7 Link System Node

MSUs per SS7 link

29 1760 220

40 1280 160

80 640 80

279 176 22

411-2231-014 Standard 02.07 May 2006


Note: In order to go beyond 273 bytes, the ATM link must have MTP3b enabled.

IP HSL capacityThe following table shows the relationship between the message length, the engineering limits (messages per second) and the DS0A equivalency of an SS7 IP HSL (M2UA or M3UA).

Table 7-12 DS0A equivalencies for ATM HSLs

Message Length (Bytes)

ATM Cells Messages per second

Equivalent DS0As (56 Kbit/s)

25 - 36 1 1792 8.0 - 11.5

37 - 84 2 1440 9.5 - 21.6

85 - 132 3 960 14.5 - 22.6

133 - 180 4 720 17.1 - 23.1

181 - 228 5 576 18.6 - 23.4

229 - 273 6 480 19.6 - 23.4

MTP3b ENABLED

… … … N/A

1381-1428 30 120 N/A

… … … N/A

4069-4116 86 42 N/A

Table 7-13 DS0A equivalencies for IP HSLs

Message Length (bytes)

Messages per Second

Equivalent DS0As (56 Kbit/s)

25 1792 8

29 1792 9.2

40 1792 12.8

80 1792 25.6

120 1792 38.4



IPS7 gateway node capacityThe IPS7 Gateway Node supports 1792 messages per second, regardless of message size.

OA&M componentsSBA capacityThe SDM Billing Application (SBA) is engineered to support the maximum NSS18 XA-Core MSC BHCA capacity on both the SDM and CBM 850 platforms.

CEM server capacityThe CEM Server (SunFire V880) with 4 CPU and 8GB RAM supports 20 MSC or HLR nodes (with an average 1M BHCA per switch).

The CEM Server with 8 CPU and 16GB RAM supports 40 MSC or HLR nodes with an average 1M BHCA per switch.

W-NMS capacityThe W-NMS capacities vary by hardware platform. The SunFire V880/V890 supported capacity is 30 MSCs per Main Server, 60 MSCs per Performance Server.

411-2231-014 Standard 02.07 May 2006


Security 8User security 8

User security is provided in CEM applications. A user must login with a valid user id and password, validated via a customer-supplied LDAP server, and the group a user is a member of restricts the operations a user can perform in the CEM GUI. If a user only an observer, they can acknowledge and clear alarms, can make configuration changes, etc.

As well, both the DMS (mapci) and MSS require a user id and password. Within CEM, configuration management (table access and the wizards) will require a user to have a DMS password, and for the R4 wizards, a MSS password as well.

Security protocols 8No specific security protocols or encryption algorithms (e.g. IPSec, IKE, etc.) are supported in the packet networks. The BICN project makes no changes to authentication and ciphering algorithms used on the A-interface or Iu interface.

Firewalls 8Optional firewalls could be included between the CO LAN and OA&M LANWAN and also between CEM clients and the OA&M LAN/WAN.

Ethernet routing switch 8600 filtering 8The CBM 850 in the CBM20 release uses a secured call processing LAN as the premise for security. The Ethernet traffic traveling between the CBM and the XACore, and the CBM and the OSSs, is not on a physically separate LAN and is not authenticated or encrypted. Utilizing "IP Policy Filtering" in the connecting Ethernet fabric (ERS 8600s) will ensure these packets are only transferred on the cables connected between the CBM and the XA-Core Ethernet interfaces.


8-2 SecurityNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

411-2231-014 Standard 02.07 May 2006

A-1Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

List of terms and definitions A3G

Third Generation

3GPPThird Generation Partnership Project

4pVSP4eFour port Voice Services Processor 4

AAL 2\5ATM Adaptation Layer Type 2 \ Type 5

AESAATM End Station Address

AGCAutomatic Gain Control

AMRAdaptive Multi-Rate

ANAggregation Node

APSAutomatic Protection Switching

APSAudio Provisioning Server

ATMAsynchronous Transfer Mode

BHCABusy Hour Call Attempts


A-2 List of terms and definitionsNortel Networks Confidential Copyright © 2003–2006 Nortel Networks

BICCBearer Independent Call Control

BICNBearer Independent Core Network

BNRBackground Noise Reduction

BSCBase Station Controller

BSSBase Station Subsystem

CACCall Admission Control

CAMELCustomized Applications of Mobile-network Enhanced Logic

CASChannel Associated Signaling

CBMCore Billing Manager

CEMCore Element Manager

CIDChannel Identifier

CLRCell Loss Ratio

CNCore Network

CPControl Processor

CPUCentral Processing Unit

411-2231-014 Standard 02.07 May 2006

List of terms and definitions A-3Nortel Networks Confidential Copyright © 2003–2006 Nortel Networks

CSCall Server, Circuit Service

CSDCircuit Switched Data

DMSDigital Multiplex Switch

ECANEcho Canceller

EIUEthernet Interface Unit

ENETEnhanced Network

FLPPFiberized Link Peripheral Processor

FPFunctional Processor

GEMGSM Element Manager

(G)MSCGateway MSC. Whether talking about the (G)MSC Server or (G)MSC Switch + Server, the term (G)MSC implies that the node could be a Gateway MSC (GMSC) or a Visited MSC (VMSC, or simply MSC for short). When this term is used, the functional role the node is playing (GMSC vs. VMSC) is independent of the topic being discussed.

(G)MSC ServerThis is a 3GPP term that refers to the functional entity that provides the call and mobility control functions in addition to the media gateway control function. Architecturally this refers to the XACore, its SS7 interface (FLPP), and its I/O components required for all signaling. This also includes Central Office (CO) LAN components that provide device connectivity and the WAN interface. This also includes the required OA&M components (element managers, billing, etc.).

(G)MSC Switch + ServerThis refers to the (G)MSC Server in addition to the legacy TDM switching components (legacy PMs and TDM switching fabric) and the Circuit Switched Data



(CSD) Interworking Function (IWF). A (G)MSC Switch + Server is able to setup calls that use the external packet fabric (ATM), the internal TDM switching fabric (ENET) or a combination of the two. The (G)MSC Switch + Server is located at what is referred to as the Central Office (CO).

GSMGlobal System for Mobile Communications

GTTGlobal Text Telephony (referred to as TTY in North America)

GVMSCGateway + Visited MSC. A server that houses both GMSC and VMSC. GVMSC servers can have gateway functionalities.

HIOP InterfaceA function performed by a pair of 2pGpDsk FPs in the Multiservice Switch (MSS) 15000 that is local to the MSC Server. The 2pGpDsk FPs provide an Ethernet interface to the MSC Server, with both port and FP redundancy, and forward the H.248/UDP/IP traffic to the ATM I/O for encapsulation into AAL5/ATM cells for transport to the G-MGs via the packet data network.

HLRHome Location Register

HzHertz

IETFInternet Engineering Task Force

IPInternet Protocol

IPoATMIP over ATM

IPSecIP Security

ITUInternational Telecommunication Union

IWFInter-Working Function

411-2231-014 Standard 02.07 May 2006


kbpskilo-bits per second, where k = 1000 bits

LDAPLightweight Directory Access Protocol

LISLink Interface Shelf

LIU7Link Interface Unit CCS7

Load SharingLoad Sharing is a technique for providing N+M redundancy. N corresponds to the minimum number of equipment required to perform an engineered task but the system load is shared among N+M elements. Each unit runs up to N/(N+M) of its maximum capacity. If the load exceeds N, the additional element can handle this extra-load and allows the system to support up to N+M. When an element fails the overall capacity is limited until the failed unit is replaced. Note that in the most optimal solution, M=1.

MACMedia Access Control

MDMMulti-Service Data Manager

MDPManagement Data Provider

MECMobile Echo Control

MGWGSM/UMTS Media Gateway. A collection of Multi-Service Switch (MSS) 1500 shelves hosting various function processors (FP) for I/O connectivity and 4pVSP4e FPs running Voice Gateway Server (VGS) applications for media services support. When "MGW" is prefaced with "PSTN", "A-interface", "Iu", "Nb", "CFIWF", etc. then it is the function (and not a physical entity) that is being described.

MMUMobility Management Unit

MPEMulti-Protocol Encapsulation



MSMobile Station, Mobile Subscriber, Message Switch

MSCMobile-services Switching Center

MSSMulti-Service Switch (Passport re-branded)

Nb' InterfaceThis interface runs between MGWs controlled by the same (G)MSC Server. Q.2630 is not used to setup/manage/take down AAL2 connections, as is required on the open and interoperable Nb interface. Instead, MGWs exchange the AAL2 connection parameters (NSAP, VPVC and CID) through the (G)MSC Server via H.248 signaling.

NEBSNetwork Equipment Building System

NUSCMNortel UMTS Standard Call Model

OA&MOperations, Administration, and Maintenance

OSOperating System

OSSOperations Support System

Out-of-Band OA&MThis refers to architectures where the OA&M traffic is routed via physical interfaces which are separate from other traffic (i.e. call processing user and control planes).

PCRPeak Cell Rate

PDCProcessor Daughter Card

PEProtocol Engine

411-2231-014 Standard 02.07 May 2006


PLMNPublic Land Mobile Network

PMPeripheral Module. This term is used generically to refer to any legacy peripheral - series 1 (CTM, MTM, etc.), series 2 (DTC, PDTC) or the SPM. The term "ENET-hosted trunk" is also used and synonymous with a trunk on a PM.

PNNIPrivate Network-to-Network Interface

PSTNPublic Switched Telephone Network

PVCPermanent Virtual Circuit

QoSQuality of Service

RedundancyDuplication or repetition of elements in electronic or mechanical equipment to provide alternative functional channels in case of failure.

RNCRadio Network Controller

SBASupernode Billing Application

SDMSupernode Data Manager

SMSingle Mode, Shared Memory

SPMSignal Processing Module

SPVCSoft PVC

SS7Signaling System #7



STPSignaling Transfer Point

TCPTransmission Control Protocol

TDMTime Division Multiplexing

TTYText Telephony

U-PlaneBearer plane, see UP

UDIUnrestricted Digital Information

UDPUser Datagram Protocol

UMTSUniversal Mobile Terrestrial System

UPUser Plane, see U-Plane

USPUniversal Signaling Point

UTRANUniversal Terrestrial Radio Access Network. This refers to the Access Network serving the UMTS network, and consists of Radio Network Controllers (RNC) and Node-B units (radio equipment). The UTRAN communicates with both the circuit network (MSC and MGW) and packet network (SGSN) through the Iu interface.

VCVirtual Circuit

VCCVirtual Channel Connection

VLRVisitor Location Register

411-2231-014 Standard 02.07 May 2006


VGSVoice Gateway Server. An application that runs on a Voice Services Processor 4 (4pVSP4e) FP in the Media Gateway that provides bearer traffic connection, media adaptation (TDM and AAL2), and voice quality services (echo cancellation, background noise reduction, mobile echo control, and automatic gain control). The VGS also terminates the Mc interface from the MSC Server.

VMSCVisited MSC

VRVirtual Router

W-NMSWireless Network Management System

XACoreExtended Architecture Core



411-2231-014 Standard 02.07 May 2006

test

Family Product Manual Contacts Copyright Confidentiality Legal

GSM / UMTS


To order documentation from Nortel Networks Global Wireless Knowledge Services, call (1) (877) 662-5669

To report a problem in this document, call (1) (877) 662-5669 or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site at http://www.nortelnetworks.com/td

Copyright © 2003–2006 Nortel Networks, All Rights Reserved

NORTEL NETWORKS CONFIDENTIAL

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

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

* Nortel Networks, the Nortel Networks logo, the Globemark HOW the WORLD SHARES IDEAS, and Unified Networks are trademarks of Nortel Networks. DMS, DMS-HLR, DMS-MSC, MAP, and SuperNode are trademarks of Nortel Networks. GSM is a trademark of GSM MOU Association. Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.Document number: 411-2231-014Product release: GSM18/MGW18Document version: Standard 02.07Date: May 2006Originated in the United States of America

Documents

Solution Overview - Willow Eaton Cherrywillowcherry.com/wp-content/uploads/2013/12/411-2231-014.02.07.pdf · Solution Overview GSM18/MGW18 ... Figure 4-7 MF signaling ... Table 7-2