Professional Documents
Culture Documents
potentially available to any network operator regardless of backbone network type, and
that there is an easy migration path to a packet-based next-generation network
architecture. The aim is to realise the Nortel Networks vision of Unified Networks that
can convey voice, data and multimedia traffic with equal ease.
Part A
Overview
Part B
Hardware
Chapter B4 CentrexIP Remote Clients and the CentrexIP Client Manager 144
B4.1 Network Configuration for CentrexIP Client Access 144
B4.2 CentrexIP Clients and their Capabilities 146
B4.3 CentrexIP Client Manager (CICM) 149
Part C
Software
Part D
Packet Telephony Protocols
Part E
Telephony Interfaces
Part F
Features and Services
Chapter F13 Providing Call Party Information (CLI and Related Services) 660
F13.1 Terminology and Basic Concepts 661
F13.2 Party Information Services 664
F13.3 Functional Overviews 666
F13.4 Parameters for Conveying Party Information 670
F13.5 Delivery of Party Information for Display 680
F13.6 CS2000 Provisioning 682
F13.7 Per-Interface Summary of Capabilities 686
Part G
Network Fit
Part H
OAM&P
Appendices
H.248 Standard device control protocol for media gateway control (used for UAS)
H.323 Set of ITU-defined IP protocols for conveying voice and other media types
HFC Hybrid Fibre Coax (used to support digital cable access networks)
HIOP High-capacity XA-Core IOP supporting Ethernet (standard since ISN03)
HLM Higher-Level Management (OAM&P applications covering multiple NEs)
IA Indirect Access
IAC Integrated Access Cable (network solution supported by CS2000)
IAD Integrated Access Device (combined line media gateway and WAN access
device on customer premises)
IAM Initial Address Message (initiating ISUP or TUP call)
IAW Integrated Access Wireline (network solution supported by CS2000)
IBL Initial Boot Load (for GWC to notify GWC EM when installed)
IBN Integrated Business Network (support for proprietary value-added services)
IBN7 Proprietary variant of ANSI CCS7, providing networked support for IBN
ICE IPConnect Call Engine (alternative name for SoftSwitch or CS3000 TSS)
ID Internet Draft (proposed IETF standards document)
IE Information Element (ISDN parameter)
IEC Inter-Exchange Carrier
IEMS Integrated Element Management System
IETF Internet Engineering Task Force (standards body for internet protocols)
I-ISUP Interconnect ISUP
IMS Interactive Multimedia Server (pre-ISN07 name for MCS5200)
IN Intelligent Networking
INAP Intelligent Networks Application Part (CCS7 protocol)
IOM Input-Output Module (datalink used to bring CS2000 into service)
IOP Input-Output Processor (XA-Core component)
IP Internet Protocol
IP Intelligent Peripheral (supports IN SRF functionality)
IPSP IP Signalling Point (CCS7 node with IP signalling connection)
ISDN Integrated Services Digital Network
ISM Integrated Service Module (used to house IOMs)
ISN International Succession Networks
ISN07 International Succession Networks Release 07 (described in this document)
ISP Internet Service Provider
ISUP ISDN User Part (CCS7 protocol)
L2TP Layer 2 Tunneling Protocol (as used for RAS calls through packet network)
LAN Local Area Network
LCI Local Craft Interface
LCR Least Cost Routing
LDAP Lightweight Directory Access Protocol
LEA Law Enforcement Agency
LEN Line Equipment Number (virtual physical address associated with line DN)
LI Lawful Interception (regulatory service allowing an LEA to monitor calls)
LIS Link Interface Shelf (in FLPP)
LMM Line Maintenance Manager
LNP Local Number Portability
LNR Last Number Redial (line service)
LTM Line Test Manager
QCA QoS Collector Application (for end-of-call QoS data provided by GWCs)
QoS Quality of Service
UA User Adaptation
UAS Universal Audio Server (proprietary media server used by CS2000)
UDP User Datagram Protocol (unreliable / best-try protocol running over IP)
UP Universal Port (gateway supporting dial-up RAS as well as VoIP)
URI Uniform Resource Identifier (as used in SIP-T)
USP Universal Signalling Point
[1] This working group was also responsible for specifying the H.248 protocol defined in RFC3015.
Figure 1 provides a generic view of the MEGACO network architecture, illustrating the
key principle on which it is based, i.e. the separation of media streams and signalling.
Media streams are handled in accordance with MGC instructions, but are not handled
directly by MGCs, only by media gateways and media servers.
See Figure 2 on page 6 for an illustration of how this generic network architecture is
implemented for a VoIP solution based on CS2000.
Media Media
Gateway Gateway
Controller Controller
(MGC) (MGC)
Core network
(packet backbone)
MGC-to-MGC signalling
MGC-MG MGC-MG
signalling: signalling:
Device/media Device/media
control Media control
Backhauled server Backhauled
call control call control
Announcements,
PSTN CCS7 signalling (e.g. ISUP)
Media Media
Media stream, e.g. packetised voice
Gateway Gateway
(MG) (MG)
Figure 2 provides a schematic view of CS2000 network architecture for VoIP (OAM&P
units omitted for simplicity).
MS2000
GWCs MS2000
GWCs
Session
CICM Server Session
Server CICM USP
USP
Core network
supporting a CS2000 solution, each media proxy has two connections, one
with the private VoIP network and one with the carriers public network. This
enables it to support two specific capabilities:
# It supports communication with and between private address domains,
e.g. for enterprise networks hosting line media gateways and CentrexIP
clients, by enabling media streams that traverse NATs to be routed
across the carriers public network.
# It can act as a firewall to control the traversal of media streams into the
private VoIP address domain used for the CS2000 CS LAN and large
telco-located gateways.
! A GWC can be configured to support Redirecting Media gateway Controller
(RMGC) functionality, which enables line gateways to discover the address of their
controlling GWC.
The hardware characteristics of all types of GWC are essentially the same. CS2000
datafill is used to specify the intended function of each GWC and ensure that its software
load is configured appropriately.
From an IP network perspective, a GWC is an independent host with a Layer 3 IP address
that is externally visible, i.e. reachable from the carriers public network, plus other IP
addresses for CS2000 use. Other CS2000 components that have externally visible IP
addresses are:
! USP
! Session Server
! CICM
! Media servers (not strictly speaking CS2000 components, but typically on the CS
LAN)
! RTP Media Portal (not strictly speaking a CS2000 component, but can be on the CS
LAN)
The IP addresses of the CS2000 Core are not externally visible. The FLPP (if used)
supports only TDM-side functionality, and has no IP address.
" Universal Port (UP) gateways that support RAS dial-up access to internet
and/or intranet data sessions via CCS7 trunks, as well as VoIP voice calls. The
gateway type used for this purpose in ISN07 is the CVX1800.
Note: CS2000 support for RAS has been tested and verified for deployment
only in a specific customer network, and is not generally available in ISN07.
! Remote CentrexIP clients controlled by the CentrexIP Client Manager (CICM)
CS2000 provides VoIP support for two types of CentrexIP client:
" Etherset clients
IP-enabled Ethernet telephone sets with a large display and programmable
softkeys.
" Soft clients
PCs running a telephony client application, with speech transmission and
reception supported via a headset attached to the PC and call control
capabilities provided by a screen-based GUI.
CentrexIP clients are controlled by the CentrexIP Client Manager (CICM). CS2000
perceives the CICM as a large gateway and CentrexIP clients as lines served by
CICM gateways, but the CICM is not a media gateway in MEGACO terms because
it handles only signalling traffic, not media streams. It can be regarded as a terminal
server, and its role is similar to that of a GWC controlling multiple small CPE line
gateways. CICMs are connected to the CS2000 CS LAN, and communicate with
their remote CentrexIP clients over the managed IP network. Each CICM subtends
and is controlled by a CS2000 GWC.
! MS2000 Series media server or Universal Audio Server (UAS)
MS2000 Series media servers are enhanced, compact versions of the UAS available
with effect from ISN07, though deployed UASs continue to be supported. Both
types of unit provide essentially the same media server capabilities, as follows:
" Packetised announcements provided to call parties in response to CS2000
requests.
Note: In general, tones are provided by gateways directly to their TDM-side
trunks and lines, not by a media server.
" Conference circuits for multi-party calls across the packet network.
" Bearer Channel Tandeming (BCT) functionality for the LI (Lawful
Interception) regulatory service, which allows packet network bearer
connections to be monitored by an LEA (Law Enforcement Agency).
MS2010 media servers for VoIP are housed in a 1U chassis designed to be mounted
horizontally in a standard 19" frame; MS2020 media servers for VoATM are
housed in a 2U chassis. UASs are housed in 16-slot SAM16 shelves. Media servers
are co-located with the CS2000 and connected to the CS LAN. In terms of CS2000
network architecture, however, a media server subtends a GWC, although it cannot
be categorised as a media gateway because it has no TDM-side connections.
A3.2 Capacity
Note: All figures quoted are general, and are subject to variation depending on the
network call model and capacity requirements. Network-specific estimates should be
determined in consultation with Nortel Sales Engineering.
! Call processing
" Maximum 2.0 million BHCA (Busy Hour Call Attempts)
Note: For the CS2000-Compact, the maximum is 1 million BHCA.
" Maximum 100,000 simultaneous calls
! Overall maximum of 200,000 trunk and/or line endpoints. Within this, the limits
that apply to different endpoint types are:
" 200,000 CCS7 trunks
" 81,860 SIP-T Dynamic Packet Trunks (DPTs)
" 48,000 PRI or QSIG trunks
" 130,000 analogue subscriber lines
! Maximum number of CCS7 signalling links is 328 (USP) or 180 (FLPP)
(with CCS7)
Y = Supported N = Not supported [1]
(no CCS7)
CentrexIP
FGD ISUP
EISUP V1
EISUP V2
ANSI PRI
ETSI PRI
LAN MG
UK ISUP
SPIROU
MG9000
INS1500
HK PRI
X = Not relevant (e.g. not for the same market)
DPNSS
CTUP
BTUP
FTUP
H.323
QSIG
INAP
MTA
IBN7
V5.2
I/F type Interface
Interworkings for CCS7 in SIP-T are as for the CCS7 protocol conveyed [2]
UK ISUP (V3) [5] Y Y Y Y X Y X Y X X N Y N Y Y X X X N N N N N
CCS7
IUP / BTUP Y Y Y Y X Y X Y X X Y N N N Y X X X Y N N N N
TUP
Overview
SSUTR2 (FTUP) N Y Y X N Y X X Y X Y N X N Y X X X N N N N N
Part A
China TUP (CTUP) Y N Y X X Y X X X Y N N X N N X X X N N N Y N
IN INAP N Y Y N N Y N Y Y N X N N Y Y N N N N N Y Y Y
H.323 / QSIG [6] Y Y Y Y N Y N N N N N Y N Y Y N N N Y N Y Y N
H.323
DPNSS / H.323 / QSIG [7] N N N N N Y X N X X N N Y N N X X X N N Y N N
QSIG N Y Y Y Y Y N N N N Y Y N Y Y N N N N N Y N N
Access / VPN
Q.931 / IUA
Product Overview
Basic analogue
MG9000 Y N N N N Y N N N N N N N N N N N N Y Y Y Y N
lines (IBN)
Lines
Chapter A3
CPE gateways
Customer LAN MGs [9] Y Y Y N N N N N N Y Y Y N N Y N Y N N Y Y Y N
Page
Y Y Y N N N N N N N Y N N N Y N N N N N Y N Y
27
Page
Product Overview
Chapter A3
[1] Interworkings are deemed not to be supported if they have not been explicitly documented or tested. This applies even to interworkings that are expected
to work (i.e. design work is not believed to be necessary), and for which support will eventually be provided by an FMA, or by a test-only activity in a future
release.
[2] For details, refer to Table 34: Interworking support for ISUP variants on page 401.
[3] In addition to base/generic ETSI ISUP V1, CS2000 supports national variants of ETSI ISUP V1 for deployment in Brazil, the Czech Republic, Denmark,
Italy (standard national interconnect interface), Malaysia, Mexico (including Telmex subvariant), Norway, Portugal, Spain and Turkey.
In general, the supported interworkings for such a national variant are as for base/generic ETSI ISUP V1, plus interworkings with appropriate national
interfaces such as the corresponding national variant of ETSI PRI, but minus interworkings with interfaces and interface variants that are specific to other
markets.
For details, refer to Table 34: Interworking support for ISUP variants on page 401.
[4] In addition to base/generic ETSI ISUP V2, CS2000 supports national variants of ETSI ISUP V2 for deployment in Australia (ACIF G.500 I-ISUP and Telstra
CA30 ISUP), Belgium, Chile, China, the Czech Republic, Germany (DTAG T-ISUP and G-ISUP variants as well as German ETSI ISUP V2), Hong Kong,
India, Israel (variants for civil and military use), Italy (intra-network support of regulatory services), Japan (JI-ISUP), Russia, Singapore, Spain, Sweden (V1
implemented as V2 variant) and Turkey.
In general, the supported interworkings for such a national variant are as for base/generic ETSI ISUP V2, plus interworkings with appropriate national
interfaces such as the corresponding national variant of ETSI PRI, but minus interworkings with interfaces and interface variants that are specific to other
markets.
For details, refer to Table 34: Interworking support for ISUP variants on page 401.
[5] ISN07 supports two national variants of ETSI ISUP V3, but does not support a base/generic V3 call processing agent.
[6] The international implementation of H.323 is based on mapping H.225 connection control messages (SETUP etc) on to their QSIG equivalents, with
APDUs being conveyed transparently in Facility IEs in QSIG messages. Support for H.323 basic call interworking means support for H.225 call
Nortel Networks
establishment, and does not imply support for the handling of non-call-related information over the interworking. Basic call interworkings supported are
PROPRIETARY
Overview
[7] CS2000 support for DPNSS is based on the international implementation of H.323 (see footnote [6]). Between the GWC and the Westell DPNSS gateway,
Part A
DPNSS signalling is encapsulated in Westell-defined manufacturer-specific operations in the H450.1 SupplementaryService data field of a H323 message.
For communication between the GWC and the Core, the GWC performs mapping between these operations and QSIG Facility IEs.
[8] In addition to base/generic ETSI PRI, CS2000 supports national variants of 30B+D PRI for deployment in China and Spain.
In general, the supported interworkings for such a national variant are as for base/generic ETSI PRI, plus interworking with the corresponding national
variant of ETSI ISUP, but minus interworkings with interfaces and interface variants that are specific to other markets.
[9] CS2000 supports three types of customer LAN media gateway: Ambit, Askey and Mediatrix. All three use the MGCP device-media control protocol. A
given interworking is shown as supported if it has been verified for any of these three gateway types.
[10]CS2000 supports two types of MTAs for cable access networks: Motorola and Arris. Both use the NCS device-media control protocol. A given interworking
This chapter describes the hardware of the CS2000 itself, and is organised into the
following sections:
! Section B1.1: Overview on page 30
! Section B1.2: Processor Complex (Core) on page 34
! Section B1.3: Internal Communication (CS LAN and MS) on page 42
! Section B1.4: Gateway Controllers (GWCs) on page 53
! Section B1.5: Session Server on page 71
! Section B1.6: CCS7 Signalling Terminations on page 72
! Section B1.7: OAM&P Hardware on page 81
! Section B1.8: CS2000 Interworking with Legacy Peripherals on page 89
! Section B1.9: Hardware Packaging on page 93
ISN software can also be installed on the DMS-100 hardware platform to provide
circuit-based switching and service support capabilities, in which case it is referred to as
ISN (TDM). ISN software can even be installed in a hybrid configuration that comprises
CS2000-specific and DMS-specific hardware as well as hardware that is common to both.
Such a hybrid configuration can support circuit-based and packet-based capabilities
simultaneously, as described in section B1.8 on page 89.
This Product Description provides detailed descriptions only of CS2000 components and
of DMS hardware components that are common to DMS and CS2000 and may be
included in a non-hybrid CS2000 configuration. For a systematic description of all DMS
hardware, including components for which hybrid configuration interworking is
supported, refer to the separate ISN07 (TDM) Product Description.
B1.1 Overview
To meet the needs of different types of customer, a range of different CS2000 hardware
configurations are supported in ISN07. These can be categorised in two main ways:
! In terms of the type of processor complex used:
" Standard CS2000 configuration
Note: A standard configuration is a CS2000 that uses the XA-Core processor
complex. The term can denote either a full SuperNode configuration or a
streamlined SNSE (SuperNode Size Enhanced) configuration.
" CS2000-Compact configuration with minimised system footprint
! In terms of the extent to which they incorporate DMS hardware as well as CS2000
hardware, the possibilities being:
" Configurations consisting entirely of CS2000 hardware
" Configurations that use DMS hardware for selected functions
" Hybrid configurations that support interworking between CS2000 and DMS
trunk and line peripherals
These configuration options are illustrated in Figures 3 to 5.
A CS2000 is a distributed system comprising a number of different functional elements.
The main functional elements are common to all types of CS2000 configuration, but there
are some differences between configurations in terms of the hardware components used
to implement certain functions. These differences are summarised on page 32 and
discussed in more detail in the sections dealing with particular components.
Physically, a CS2000 configuration consists of circuit packs housed in slots in shelves,
which are in turn packaged into cabinets to form a cabinet lineup. See section B1.9 on
page 93 for information about CS2000 hardware packaging and illustrations of some
typical cabinet lineups.
USP supports CCS7 CS2000 Core (XA-Core or GWCs individually configured to support:
signalling to/from Compact) supports: Device/media control for MGs
TDM networks via Call processing Backhauled call control for MGs
dedicated signalling Translations / routing H.323 access
links (not via packet Service logic DPTs between CS2000s
network) Core and GWCs together Media server control
support MGC functionality. CICM control
Media server switched Media proxy control
into calls to support: RMGC functionality
Announcements CICM provides Session Server
Conferencing services for remote supports SIP signalling
BCT for LI CentrexIP clients to/from peer MGCs
Dual PP8600s
CS2000 OAM&P
CS LAN servers
CS2000 Core
Session
MS2000 CICM Server
Trunk CICM AC H.323 Line RMGC DPT
GWC GWC GWC GWC GWC GWC GWC
Dual PP8600s
Figure 5: Hybrid configuration with interworking between CS2000 and DMS peripherals
! The Session Server has been introduced in ISN07 as the new standard platform for
communication across the managed IP core network between peer MGCs. CCS7 is
supported using DPTs (Dynamic Packet Trunks) terminated on DPT GWCs. CCS7
signalling is conveyed encapsulated in SIP (Session Initiation Protocol) messages.
SIP signalling is terminated on the Session Server, which extracts the CCS7
signalling and passes it on to the DPT GWC.
Note: Session Server support for SIP signalling and CCS7 encapsulation is
designed to be compliant with RFC3261, which defines a SIP interface for open
interoperability between call servers and other network elements. Prior to the ISN07
introduction of the Session Server implementation, CS2000 support for SIP was
based on pre-RFC3261 drafts and implemented by configuring GWCs as VRDNs
(Virtual Router Distibution Nodes) to provide initial points of contact for
peer-to-peer SIP signalling. This VRDN implementation is still supported, but has
now been superseded by the Session Server implementation.
! Terminations for CCS7 signalling links.
" Since ISN04, the recommended unit for terminating CCS7 signalling links
has been the Universal Signalling Point (USP) described in section B1.6.1 on
page 73. This is available for use with both standard and Compact
configurations.
Note: A Compact version of the USP is available for use in CS2000-Compact
configurations that have limited requirements for CCS7 signalling links.
" As an alternative to the USP, a standard CS2000 configuration can include a
Fiberised Link Peripheral Processor (FLPP), as described in section B1.6.2 on
page 78.
! For configurations with no legacy hardware, Sun Netra 240 servers can be used as
the standard platform for OAM&P applications. CS2000 Core Manager capabilities
are provided by Core and Billing Manager (CBM) applications running on a
dedicated CBM server, while Element Managers (EMs) for most other components
run on a dedicated CS2000 Management Tools (CMT) server. For configurations
that include legacy hardware, Core Manager capabilities are instead provided by
SuperNode Data Manager (SDM) applications running on a PowerPC / AIX
platform. Use of the CBM and standardisation on Sun servers is recommended with
effect from ISN07, but deployed SDMs continue to be supported. CBM and SDM
application capabilities are equivalent. See section B1.7 on page 81 for more details
of OAM&P hardware.
Note: The configurations illustrated in Figures 3 to 5 all include an MS2000 Series media
server supporting announcements, conferencing and BCT for LI. The MS2000 is typically
located on the CS2000 CS LAN, but in terms of CS2000 network architecture it is an
independent media server that does not logically belong to the CS2000 configuration. It
is therefore described separately, in Chapter B3: CS2000 Support for Media Servers.
Chapter B3 also describes the UAS (Universal Audio Server), which provided media
server functionality before the ISN07 introduction of the MS2000 Series, and is still
supported.
Many CS2000 components are duplicated for reliability. Others operate in load-sharing
mode using N+1 sparing. In both cases the aim is that a functional element can survive
the failure of one of its constituent hardware units. Because the primary aim of this chapter
is to provide a functional view of hardware operation, the illustrations do not show
hardware component duplication or sparing.
B1.2.1 XA-Core
B1.2.1.1 Overview
Subsystems
XA-Core design is based on the principle of using independently scalable subsystems to
deliver call processing capacity. Such subsystems can be incrementally tailored to meet
customer requirements, instead of replacements and upgrades being required. The
XA-Core subsystems are:
! Processor subsystem
! Shared memory
! Input/output processors
Links between subsystems (bus capabilities) are provided by a set of independent
communication links known as the XAI (Extended Architecture Interconnect).
Physical Implementation
Physically, each type of subsystem is implemented as a circuit pack. XA-Core as a whole
consists of a single shelf that provides slots for inserting these circuit packs and is housed
in a SuperNode C42 cabinet
The XA-Core shelf can be packaged in a cabinet along with the MS, with the FLPP and
ENET (if used) in separate cabinets. Alternatively, it can be packaged in a SNSE
Combined Core Cabinet along with streamlined versions of the MS, LPP and ENET. The
shelf is identical in both cabinets.
See section B1.9.2 on page 94 for illustrations of how the XA-Core shelf can be packaged
in some typical cabinet lineups.
Logical Architecture
Figure 6 shows XA-Core architecture. Subsystems are described in sections B1.2.1.2 to
B1.2.1.4.
CS2000
Shared memory
XA-Core (SM)
Tape
Disk
Terminal
MS used only if configuration 100BaseT
includes DMS hardware OC-3 links
(see Figures 4 and 5) Ethernet links
Message Switch (CS2000 bus) CS LAN
NATs and firewalls, e.g. customer LAN media gateways, IP-enabled PBXs and
remote CentrexIP clients. These NEs include H.323 GWCs, line GWCs, CICM and
GWCs configured to provide RMGC functonality.
! OAM&P VLAN
This interconnects the EMS (Element Management System) servers supporting the
EMs (Element Managers) for functional network elements. These EMs are the only
entities that are permitted to access the functional CS2000 NEs on the signalling
VLANs. The EMS servers belonging to the OAM&P VLANperform a dual role:
" They have trusted access to the CS2000 network elements on the signalling
VLAN, for which purpose they can use the private IP address space of the
signalling VLAN.
" They support controlled access from external entities, for which purpose they
are assigned IP addresses in the address space of the carriers intranet.
Note: These IP addresses are sometimes referred to as public addresses. This
means only that they are external to the VoIP address domain to which
functional NEs belong, not that they are public Internet addresses. In practice,
a carriers OAM&P intranet will also be a private network.
! Bearer VLAN
If the backbone packet network is IP, an MS2000/UAS bearer VLAN is configured
to handle audio bearer traffic (the CS LAN otherwise handles only signalling). This
is not necessary for an ATM backbone network, as the UAS can support direct
ATM bearer connections that bypass the CS LAN PP8600s.
The CS2000 CS LAN cannot be split between different geographic sites.
Figure 8 illustrates how the CS LAN is structured into different VLANs for different
purposes.
Signalling VLAN
Bearer VLAN
OAM&P VLAN
Figure 9: Connectivity provided by the PP8600 router / switch for the CS LAN
100BaseT
Connection
Component terminations
characteristics IP addressing [1]
provided by
CS2000 Core
XA-Core LX04 HIOP Redundancy provided by Six IP addresses:
cards in independent connections Two floating logical addresses for the
XA-Core shelf with both routers. active interfaces.
Each HIOP is connected One address for the maintenance
to one PP8600 but not to interface on each HIOP (two in all).
the other. One address for the physical interface
During normal operation, on each HIOP (two in all).
both HIOPs are active and
operate in load-balancing
mode.
3PC Call Two Ethernet Redundancy provided by Ten IP addresses in all, including two
Agent ports on N765 independent connections floating logical addresses for the active
processor with both routers. interfaces.
cards, one in Two ports per processor
each SAM21 card, each connected to
Call Agent one of the dual PP8600
shelf routers.
GWCs in SAM21 Ethernet ports Redundancy provided by Four IP addresses per GWC:
chassis on GWC cards independent connections One externally visible floating logical
(connectivity with both routers. address for the active unit.
identical for all GWC One port per GWC card, One floating logical address for the
types) therefore two for a GWC inactive unit.
pair. Each card is Two static addresses for OAM&P /
connected to one of the physical access to each card
dual PP8600 routers.
SAM21 SCs Ethernet ports Redundancy provided by Four IP addresses per SC:
on SC cards independent connections One externally visible floating logical
with both routers. address for the active unit.
One port per SC card, One floating logical address for the
therefore two for an SC inactive unit.
pair. Each card is Two static addresses for OAM&P /
connected to one of the physical access to each card.
dual PP8600 routers.
Session Server Ethernet ports Redundancy provided by Four IP addresses per Session Server:
on HP-CC3310 independent connections One externally visible floating logical
platform with both routers. address for the active unit.
Two ports per One floating logical address for the
HP-CC3310, each inactive unit.
connected to one of the Two static addresses for OAM&P /
dual PP8600 routers. physical access to each unit
100BaseT
Connection
Component terminations
characteristics IP addressing [1]
provided by
USP (if used) Ethernet USP houses two or four IP Four to six IP addresses:
Transition system nodes, which Two or four CS-LAN IP addresses are
Module (TM) operate in active/active required for the IP system nodes,
for IP system load-sharing mode and which operate in active/active
node are redundantly load-sharing mode.
connected to the PP8600 Two static addresses for OAM&P /
routers. physical access to each system node.
These IP addresses, as used for
communication with the Core and GWCs,
can be private. (The USP also requires a
public IP address for communication with
the Networks Operations Centre.)
Media server (MS2000/UAS) [2]
H.248 Dual Ethernet Redundancy provided by One externally visible IP address for
signalling ports on independent connections dual-port network interface configured in
connections MS20x0 or on with both routers. active/standby mode. If the link terminated
UAS processor Each port is connected to on the primary port fails, the standby port
card. one of the PP8600 routers becomes active and the IP address is
but not the other. transparently switched to it.
Bearer Dual Ethernet Redundancy provided by One externally visible IP address per
connections ports on independent connections MS2010 or per UAS CG6000, for
(VoIP only [3] MS2010 or on with both routers. dual-port network interface configured in
each UAS Each port is connected to active/standby mode. If the link terminated
CG6000. one of the PP8600 routers on the primary port fails, the standby port
but not the other. becomes active and the IP address is
transparently switched to it.
CS2000 Core Manager
CBM Ethernet ports Redundancy provided by The CBM requires two IP addresses:
on Sun server independent connections One address for the signalling VLAN.
platform with both routers. One address for the OAM&P VLAN.
Each port is connected to It utilises two links to each PP8600 (one
one of the PP8600 routers signalling, one OAM&P), i.e. four PP8600
but not the other. links in all.
SDM NTRX50NK Redundancy provided by The SDM requires three IP addresses:
UMFIO independent connections One address for the signalling VLAN.
Personality with both routers. One address for the OAM&P VLAN.
Module (PM) SDM houses two PM One address for the DS-512 link to the
cards in SDM cards, each connected to MS.
shelf. one of the PP8600 routers It utilises two links to each PP8600 (one
but not the other. signalling, one OAM&P), i.e. four PP8600
links in all.
Other OAM&P nodes
CS2M Ethernet ports Redundancy provided by Each functional OAM&P element on Sun
comprising: on Sun server independent connections server requires three IP addresses for
SESM platform with both routers. redundancy.
APS Each port is connected to There is one logical IP address,
SSPF one of the PP8600 routers and two physical addresses referred to as
but not the other. test IP addresses.
100BaseT
Connection
Component terminations
characteristics IP addressing [1]
provided by
IEMS Shares Sun server platform (and Ethernet connections) with CBM or CS2M
PMDM [4] Ethernet ports Redundancy provided by Each functional OAM&P element on Sun
on Sun server independent connections server requires three IP addresses for
platform with both routers. redundancy.
Each port is connected to There is one logical IP address,
one of the PP8600 routers and two physical addresses referred to as
but not the other. test IP addresses.
[1] All of the IP addresses for a given unit are consecutive. The first address is explicitly specified when configuring
the unit. The subsequent addresses are then assigned automatically.
[2] On CS LAN, but not a CS2000 component.
[3] VoATM bearer connections are supported over direct ATM / STM-x connections to the packet backbone
network, terminated on MS2020 or on UAS P200.
[4] PMDM is typically located on the NOC LAN rather than the CS LAN, in which case the customer (operating
company) is responsible for supplying it. It can, however, be supplied by Nortel and connected to the CS LAN if
this is requested by the customer.
PP8600/0 PP8600/1
Default VLAN Default VLAN
192.168.0.2/22 192.168.0.3/22
Running VRRP GWCs GWCs Running VRRP
VRRP/IP 0 1 0 1 VRRP/IP
192.168.0.1 0 1 0 1 192.168.0.1
0 1 0 1
0 1 0 1
0 1 0 1
192.168.x.x/22 0 1 0 1 MS2010/0
3PC blade 0 1 0 1 192.168.x.x/22
0 1 0 1
Core 0 1 0 1 MS2010/1
0 1 0 1 192.168.x.x/22
3PC blade 0 1 0 1
192.168.x.x/22 0 1 0 1 MS2010/2
0 1 0 1 192.168.x.x/22
0 1 0 1
0 1 0 1 MS2010/3
USP 0 1 0 1 192.168.x.x/22
192.168.x.x/22 0 1 0 1
0 1 0 1
0 1 0 1
0 1 0 1 Netra cluster
192.168.x.x/22
CBM
192.168.x.x/22 Netra cluster
192.168.x.x/22
MS Hardware
The bus consists of two identical load-sharing planes called Message Switches (MSs),
each with the capacity and connectivity to support the full internal messaging load if the
other plane fails. Each Message Switch plane comprises the following:
! A 32-bit Motorola 68000 Series control processor with on-board memory.
! Two buses for communication:
" The Transaction Bus (T-Bus) carries the messaging payload, i.e. the messages
sent from one CS2000 component to another via the MS. The Transaction Bus
operates at 128 Mb/s, with a typical throughput of 250,000 64-byte messages
per second and an average port-to-port delay of less than 100s.
" The Processor Bus (P-Bus) carries internal messages to control MS operation.
! A mapper subsystem that converts physical addresses (port numbers within the MS)
to/from the logical addresses of switch components.
Figure 11 summarises which GWCs and other units are housed in a SAM21, and
illustrates how they use the CS LAN to communicate with each other and with other
CS2000 and packet network components.
Notes:
! Communication between SCs and GWCs via the cPCI bus is not illustrated.
! Not all types of GWC or GWC equivalent are shown, e.g. the configuration
illustrated does not show a VRDN or a CICM EM.
,
Ethernet CS LAN
e.g. PVG peer CSs server
Dual
PP8600
routers
Figure 11: Logical view of different GWC types and their interaction
Up to three
SAM21 card cages
System slots per cabinet,
7 and 9 house one per shelf
SC cards
Figure 12: SAM21 card cages and GWCs housed in a dedicated PTE2000 cabinet
A PTE2000 cabinet need not be dedicated to housing SAM21 card cages and GWCs, as
follows:
! Units other than GWCs may be housed in a SAM21 card cage. In the main Call
Control Frame of a CS2000-Compact configuration, for example, SAM21s are used
to house not only GWCs, but also 3PC processor cards, as illustrated in Figure 7 on
page 39.
! Units other than SAM21s can be housed in a PTE2000 cabinet. For example, the
main Call Control Frame of a CS2000-Compact configuration can house up to six
MS2010 media server units instead of a third SAM21.
PTE2000 cabinets housing three SAM21s containing only GWCs are typically used either
to increase capacity or in standard configurations where XA-Core is housed in a separate
cabinet.
between call servers and other network elements. The VRDN implementation was based
on pre-RFC3261 drafts and has now been superseded by the Session Server
implementation. See Chapter D2: SIP and SIP-T for more details.
DPT DPT
provisioning provisioning
Inter-CS
DPT connection DPT
GWC VRDN GWC
Access Access
GWC DPT A GWC DPT GWC
GWC GWC
No VRDN
DPT for call DPT
GWC origination B GWC
Figure 13: DPT GWC interaction with other units to support peer-to-peer SIP signalling
TDM-side switches,
CS2000 TCAP
ISUP TUP
SCPs, etc
TCAP SCCP Conventional
ISUP TUP CCS7
SCCP MTP3 signalling
MTP2 network
M3UA
SCTP MTP1
CS2000 USP
Core IP TCAP
SCCP
MTP3
Other CS2000s,
MCS5200s, etc
M2PA
CS LAN SCTP
IP IP control
network over
Session backbone
DPT Server SIP-T SIP-T
GWC packet network
or ISUP TUP
VRDN
SDP SDP
See section B1.4.5.3 on page 62 for TCP or UDP
information about DPT GWC interaction
with Session Server or VRDN IP
Scenario B:- CCS7 support provided by FLPP (Fiberised Link Peripheral Processor)
CS2000
Message Switch (CS2000 bus)
TDM-side switches,
TCAP
ISUP TUP
SCCP Conventional
CCS7 SCPs, etc
Proprietary messaging MTP3
signalling
XA-Core FLPP MTP2 network
MTP1
DPT Server
GWC ISUP TUP IP control
or
VRDN network over
SDP SDP backbone
TCP or UDP packet network
See section B1.4.5.3 on page 62 for
information about DPT GWC interaction IP
with Session Server or VRDN
USP USP
main extension
shelf shelf
USP USP
extension extension
shelf shelf
LIS and LIM units are housed in C42 cabinets as illustrated in figure 17. A CS2000
configuration can include up to six LPP cabinets.
LMS functions:
Link Interface Module To terminate SR128 links
to/from the MS (CS2000 bus).
LPP LMS 0 LPP LMS 1 To support communication
between IUs/ASUs
Link Interface Shelf 1
LISs provide
Link Interface Shelf 2 slots for
IUs/ASUs,
e.g. LIU7s
CS2000
V.35
Link
Peripheral Link External
Processor Interface mux
MS
Figure 18: LPP support for CCS7 terminations using an external multiplexer
Figure 18 provides a more detailed view of an individual LIU7, showing its components
and the interaction between them.
To/from External
F-Bus CCS7 link
All 12 slots on each FLPP shelf are available for LIU7s terminating external CCS7
signalling links, which means that one FLPP cabinet can support a maximum of 36
signalling links. A CS2000 can support up to 180 CCS7 signalling links (slightly fewer if
some LIU7s are used as external routers, as described in the following section).
LIU7s used as
external routers
F-Bus
CCS7
LIU7s terminating network
CCS7 signalling
Figure 20: Use of LIU7 external routers to select CCS7 signalling links
B1.7.1 Trusted Access to NEs via the OAM&P VLAN of the CS LAN
The OAM&P VLAN of the CS LAN interconnects the EMS (Element Management
System) servers supporting the EMs (Element Managers) for functional network
elements. These EMs are the only entities that are permitted to access the functional
CS2000 NEs on the signalling VLANs. The EMS servers belonging to the OAM&P
VLANperform a dual role:
! They have trusted access to the CS2000 network elements on the signalling VLAN,
for which purpose they can use the private IP address space of the signalling VLAN.
! They support controlled access from external entities.
The EMS servers on the OAM&P VLAN can be accessed by:
! Appropriately authenticated entities on the NOC LAN, e.g. NOC desktop clients
and Higher Level Management (HML) application servers.
! Appropriately filtered and authenticated external users in Operating Company
intranets, e.g. from the OSS LAN.
Other users in the NOC LAN and Operating Company intranets can access CS2000
network elements only via the EMS interfaces. They have no direct IP route to the CS2000
network elements. No extension of the OAM&P VLAN to other servers or services is
permitted, as this would compromise the security of the CS2000 network elements.
Figure 21 on page 82 illustrates the network architecture.
Nortel
OSS LAN / OC corporate internet Remote
(centralised OAM&P applications) Access
Enterprise Secure
servers tunneling
NOC LAN
RA to OAM&P VLAN
Untrusted indirect
access to NEs via EMs
RA to CS2000
Element Managers
(trusted access to Network Elements)
Firewall /
perimeter IEMS /
network CBM Other
CMT EMs/apps
PP8600
CS2000
Sun server Sun server Sun server DM CS LAN
EMS servers
CS LAN (OAM&P VLAN)
EM
functionality
for 3rd-party
media Telco SAM21 SS USP
router CS2000 (inc.
gateways Core CICM (inc. MS2010
SC GWC inc. EM EM) EM)
PVG
Packet backbone network gateways
Line
gateways
B1.7.2 Access to the OAM&P VLAN from outside the CS2000 CS LAN
Clients for
EMs and HLM applications
management on enterprise
applications servers
NOC LAN
IEMS
Non-CMT-resident EMs,
e.g. for Session Server,
USP, CICM EM
EMs and mgmt
apps, e.g. GWC
Core Manager EM, SAM21 EM,
applications configuration apps
4-wire
standard sockets
DS-30 Local/
Bulkhead with
The IOM CC can also support two SCSI ports, which are used for connections to a
two-slot Storage Media Card (SMC) supporting a 1-Gbyte DDU and a 1.3-Gbyte DAT.
The DDU can be used to store billing data, backup images and software loads.
PVG
Legacy Legacy trunks TDM side
trunk of PVG
IOM OAU ENET peripherals
in ISM Looparound trunks connecting
legacy peripherals with TDM Packet
side of PVG trunk gateway side of
MS MS PVG
Legacy
Lines
line
FLPP SDM peripherals Packet
backbone
network
Dual PP8600s
CS2000 OAM&P
CS LAN servers
CS2000 Core
Session
MS2000 CICM
Trunk CICM AC H.323 Line RMGC DPT Server
GWC GWC GWC GWC GWC GWC GWC
Legacy Legacy
trunk trunks PVG
peripherals
IOM OAU ENET
in ISM TDM
side of
Legacy Legacy PVG
MS MS line lines Packet
peripherals side of
PVG
FLPP SDM
IW-SPM
OAM&P CS2000
servers CS LAN
CS2000 Core
Session
MS2000 CICM
Trunk CICM AC H.323 Line RMGC DPT Server
GWC GWC GWC GWC GWC GWC GWC
IW-SPM
IW-SPM Capacity
On the packet-side, an IW-SPM supports one active GigE link that operates in the range
of 400 Mb/s, plus a second GigE link for protection switching. These GigE links are
connected to the PP8600 routers of the CS2000 CS LAN, and via them to the backbone
packet network.
On the circuit side, an IW-SPM can supported up to 2,048 64Kb/s user channels provided
by four DS-512 link with ENETs.
There is no concentration at the IW-SPM. Media streams to/from other packet network
hosts are mapped 1:1 on to 64Kb/s user channels.
Note: Although technically feasible, use of the SPM as a trunk traffic peripheral in a
CS2000 SNSE configuration is not recommended. This is primarily because it allows
trunk capacity to be increased only in 2,000-trunk steps, which is not an appropriate level
of granularity for increasing the trunk capacity of small switches.
An SPM system frame is always configured with two units, even if only one is to be used
initially. This makes it possible to accommodate subsequent system expansion merely by
adding circuit packs and cabling.
MX20x0 OAM&P
media Session servers
servers Server frame
PP
213cm
8600
183cm
USP
main
PP
SAM21 shelves 8600 Depth
Depth USP
housing GWCs ext. 61cm
71cm
XA-Core
Figure 28: Example Lineup A:- XA-Core configuration with no legacy hardware
PP
213cm
MX20x0
media 8600
servers
USP
main
SAM21 Call Agent CA1
shelves housing: PP
3PC Call 8600 Depth
Agent card USP
ext. 61cm
(main shelf) CA0
GWCs
Figure 29: Example Lineup B:- Compact configuration with no legacy hardware
213cm
183cm
MS 0 LMS ENET 0
MS 1 LIS 0 ENET 1
SS
PP
213cm
8600
OAU MS
CMT
AXU on Sun
SDM PP
ISM
on shelves 8600 Depth
Series FX for 61cm
IOMs
Figure 30: Example Lineup C:- XA-Core configuration with selected legacy hardware
Combined
Core cabinet
SS
PP
213cm
8600
183cm
MS OAU MS
LIS CMT
AXU on Sun
SAM21s SDM PP
ENET with ISM
Depth shelves on 8600 Depth
GWCs Series FX
71cm for 61cm
XA-Core IOMs
Figure 31: Example Lineup D:- XA-Core SNSE configuration with selected legacy
hardware
B2.1 Introduction
In order to perform its network role, a CS2000 must be deployed along with one or more
media gateways for handling packet network bearer connections. A media gateway
provides an interface for bearer connections, e.g. mapping a packet-based media stream
on to a circuit-based media stream, seamlessly providing any required format conversion
while maintaining content integrity. Depending on the telephony interface to be
supported, a media gateway may also provide signalling gateway functionality. A
signalling gateway terminates legacy network signalling on one side and packet network
signalling on the other, and supports interpretation and conversion between the two.
This chapter provides a brief functional overview of each type of gateway that can be
deployed with an ISN07 CS2000. First, section B2.2 discusses how to categorise and
assess the capabilities of different types of gateway; the remaining sections of this chapter
then deal with specific gateway types. For ISN07, the gateway types supported [1] are:
! PVG (Packet Voice Gateway) trunk gateways, which can support both VoIP and
VoATM. The Passport PP7480, PP15000 and PP20000 PVGs supported in ISN07
are described in section B2.3 on page 99.
! PVGs configured to support V5.2 access to IP networks for analogue subscriber
lines, as described in section B2.4 on page 111.
! CPE gateways and 3rd-party units controlled by CS2000 H.323 proxy GWC via
H.323 / H.225 / H.245. See section B2.5 on page 115.
! Audiocodes Mediant 2000 gateways supporting PRI or CCS7. See section B2.6 on
page 116.
! Westell DPNSS gateways. See section B2.7 on page 118.
[1] Gateways are independent units with their own release schedules. The range of supported gateways may
therefore change within the lifecycle of a given CS2000 release.
ne
- Q.931 or QSIG over
tw
IUA/SCTP/IP for PRI or
or
k
QSIG access
- V5-PSTN over
(ATM or IP)
V5UA/SCTP/IP for V5.2
access
- H.323 for H.323 gateways
- NCS for MTA cable lines
- MGCP for CPE LAN lines
Access network
(e.g. PSTN, ISDN, Media Far-end
V5.2 AN, analogue gateway gateway
lines)
B2.3.1 Overview
A PVG consists of a gateway software load (PCR 6.1 for ISN07) running on a Passport
hardware platform to support VoIP or VoATM. The platforms supported in ISN07 are the
PP15000, PP20000 and PP7480. All three types of PVG provide essentially the same
capabilities. The main difference between them is that the PP7480 houses a smaller range
of functional elements and supports less capacity. The PP15000 and PP20000 can both
house the same range of hardware components and are functionally identical. To avoid
duplication and repetition, the remainder of this section refers only to the PP15000, but
all PP15000 references should be taken to apply equally to the PP20000.
The functional elements that can be housed in a PVG are as follows:
! Voice Service Processor (VSP) supporting TDM/packet conversion
Each VSP housed in a PVG is actually a separate gateway. A given PVG can house
multiple VSPs, each independently performing circuit/packet conversion. See the
following page for further information, and for details of the VSP types supported.
! Terminations for TDM-side carriers
TDM-side terminations can be provided in either of two ways:
" By dedicated Function Processor (FP) cards. The following types of
TDM-side FP are supported in ISN07:
# STM-1 FP with 4 ports, each supporting 63 E1 terminations (PP15000
only)
Note: The STM-1 FP can also be configured to support OC-3 with DS1
channelisation.
# E1 FP with two ports (16 E1s can be multiplexed into each port, which
means that an E1 FP can support a total of 32 E1s)
# T1 FP with two DS3 ports (28 DS1s can be multiplexed into each DS3
port, which means that a T1 FP can support a total of 56 T1s)
" By means of integrated TDM-side ports on the VSP (PP15000 only)
The VSP3-o available with effect from ISN07 provides an STM-1/OC-3 port
supporting 63 E1 terminations.
! Terminations for packet network connections
Packet network terminations can be provided in either of two ways:
" By dedicated Function Processor (FP) cards. The following types of
packet-side FP are supported in ISN07:
# 4pGE card providing 4 Gigabit Ethernet (GigE) ports for access to IP
backbone networks (PP15000 only).
# By dedicated 155Mb/s STM-1 or 622Mb/s STM-4 ATM FPs
ATM FPs support direct access to ATM backbone networks, and can
support access to IP backbone networks using AAL5 (which is added /
removed by an edge device). ATM FPs are supported by all PVG types.
" By means of integrated packet-side ports on the VSP (PP15000 only)
The VSP3 available since ISN05 provides two GigE ports (one active, one
standby) for access to IP backbone networks.
Dedicated FP
TDM FP (Voice Service Processor) (IP or ATM)
(Function
network
TDM FP VSP
(Function Integral
network
VSP
Integral (Voice Service (IP or ATM)
network
The trunks on a given TDM-side carrier are all assigned to a particular VSP and are not
available to any other VSP. For access to the packet network, however, FPs and even ports
may be shared by different VSPs.
From a network perspective, each VSP is an independent unit with its own IP addresses [1].
If more than one VSP is housed in a PVG shelf, the GWC perceives each one as a separate
media gateway entity. This in turn means that a PVG is not itself a gateway, as multiple
VSPs, each providing gateway functionality, can be housed in a given PVG.
Three generations of VSP technology are supported. These can be distinguished on the
basis of capacity and configuration, as follows:
VSP PP STM-1
type 15000 PP FP E1 FP T1 FP GigE IP GigE IP STM-4 STM-1
(32 (56 ports ports on ATM FP ATM FP
or 7480 (4 x 62
20000 E1 ports) E1s) T1s) on VSP 4pGE FP 622 Mb/s 155 Mb/s
A given VSP can support both E1 and T1 TDM-side terminations provided that these are
served by different TDM-side FPs, as follows:
! A VSP2 or VSP3 can support connections with multiple TDM-side FPs of different
types, and can therefore can support both E1 and T1 endpoints.
! A VSP3-o has a single integrated STM-1 port, and therefore cannot support
different endpoint types. Two VSP3-o cards in a given shelf can, however, support
different endpoint types.
See the table in section B2.3.2.2 on page 104 for information about the maximum number
of E1s/DS0s that can be supported by different VSP configurations. Note that this varies
depending on the backbone network type (IP or ATM) and the codec used.
VSP and FP cards are housed in 16-slot Passport shelves. Intra-shelf communication is
based on an ATM switching fabric with capacity of 40 Gb/s (PP15000) or 800 Mb/s
(PP7480). Two shelves can be housed in a cabinet.
PP7480 and PP15000 PVGs are managed by the Preside MultiService Data Manager
(PMDM). A PMDM is typically co-located with each CS2000 supporting PVGs.
[1] A VSP supports up to three IP hosts, each with its own IP address. Every VSP has separate IP hosts for bearer
connections and device/media control signalling. VSPs supporting PRI also have an IP host for Q.931
signalling backhaul.
ATM FPs
ATM FPs terminate packet network connections both for ATM backbone networks and
IP backbone networks. Two types of physical termination are supported:
! 155Mb/s ATM packet network connection terminated on an STM-1 FP card
! 622Mb/s ATM packet network connection terminated on an STM-4 FP card
An ATM FP terminates not only packet network bearer connections, but also the packet
network connections used for GWC-gateway control signalling (device/media control
signalling for CCS7, PRI and QSIG access; call control signalling as well for PRI/QSIG
access). Packet network connections are handled differently depending on whether the
packet network backbone is IP or ATM, as follows:
! IP backbone network
" Device / media control connections:
# For CCS7 and PRI access, the recommended protocol stack for
device/media control signalling is
H.248 / UDP / IP / RFC2684 / AAL5 / ATM
ASPEN continues to be supported as an alternative to H.248.
# For QSIG access, the only protocol stack supported for device/media
control signalling is
ASPEN / UDP / IP / RFC2684 / AAL5 / ATM
Verification testing of H.248 is required before it can supersede ASPEN
as the recommended device/media control protocol for use with QSIG.
# For a PVG configured to support V5.2 line acess as described in section
B2.4 on page 111, the only protocol stack supported for device/media
control signalling is
H.248 / UDP / IP / RFC2684 / AAL5 / ATM
" Call control connections (signalling backhaul; not applicable for CCS7):
# For PRI and QSIG access, the protocol stacks for backhauled call
control signalling are
Q.931 / IUA / SCTP / IP / RFC2684 / AAL5 / ATM
QSIG / IUA / SCTP / IP / RFC2684 / AAL5 / ATM
# For a PVG configured to support V5.2 line acess as described in section
B2.4 on page 111, the protocol stack for backhauled call control
signalling is
V5.2 / V5UA / SCTP / IP / RFC2684 / AAL5 / ATM
" Bearer connections
RTP / UDP / IP / RFC2684 / AAL5 / ATM / STM-x
RTCP / UDP / IP / RFC2684 / AAL5 / ATM / STM-x
Note: T.38 / UDP / IP is also supported.
For an IP backbone network not based on ATM, AAL5 must be removed by an edge
device, but this is not necessary if the entire backbone network uses IP over ATM.
independent of the PVG but typically co-located with it. As an alternative to this
configuration, it is possible for such grooming to be performed by the PVG itself, as
follows:
! For channelised carriers terminated on 4-port STM-1 FPs, the AAL1 CES (Circuit
Emulation Service) can be used to establish a connection between two specified
TDM-side DS0s.
! For a channelised carrier terminated on the integrated STM-1/OC-3 port of a
VSP3-o, selected channels can be groomed off via the TimeslotRelay feature (note
that this is not a CES function).
Both mechanisms make it possible to groom off signalling channels and consolidate them
on to a dedicated E1 port for presentation to the CS2000.
The trunks on a given TDM-side E1 carrier are all assigned to a particular VSP and are
not available to any other VSP. E1 carriers terminated on a given dedicated STM-1 or E1
TDM-side FP can be assigned to different VSPs, but E1 carriers terminated on the
integrated STM-1/OC-3 port of a VSP3-o cannot be asigned to another VSP.
The table below gives the overall maximum number of 64Kb/s bearer connections or
DS0s that can be supported by various PVG configurations (the numbers will be less if
redundancy is in use).
Max. 64Kb/s
Network
PVG type Codec type channels / DS0s
type per VSP
G.711 (10ms) 2,016
G.711 (20ms) 2,016
IP
G.729a/b (10ms + digit collection) 1,512
PP15000 with G.729a/b (20ms + digit collection) 1,512
VSP3 G.711 (5ms) 2,016
G.726-32 (5ms) 2,016
ATM (AAL2)
G.726-32 (10ms) 2,016
G.729a/b (10ms) 1,512
G.711 (10ms) 1,120
G.711 (20ms) 1,120
IP
G.729a/b (10ms + digit collection) 800
G.729a/b (20ms + digit collection) 800
PP15000 with
G.711 (5ms) 1,120
VSP2
G.711 (5ms + digit collection) 960
ATM (AAL2) G.726-32 (10ms) 1,120
G.726-32 (10ms + digit collection) 960
G.729a/b (10ms) 1,512
G.711 (10ms) 1,008
G.711 (20ms) 1,008
IP
G.729a/b (10ms + digit collection) 720
G.729a/b (20ms + digit collection) 720
PP7480 with
G.711 (5ms) 1,008
VSP2
G.711 (5ms + digit collection) 864
ATM (AAL2) G.726-32 (10ms) 1,008
G.726-32 (10ms + digit collection) 864
G.729a/b (10ms + digit collection) 720
Reliability and quality of service are carrier grade, even in a non-redundant configuration
in which E1 carriers are not duplicated.
The VSP responds to GWC requests made via H.248 or ASPEN to make and break
narrow-band connections between TDM trunks and packet bearer connections (either
RTP or AAL2). It also supports specific voice services, as follows:
! Tone generation
When CS2000 determines that a tone needs to be applied, the GWC sends an
ASPEN command to the PVG, specifying the logical identifier of the tone. CS2000
does not need to know about market-specific variations in tone characteristics; it
relies on the gateway to ensure that the tones characteristics are correct when it is
played, based on the country in which the gateway is deployed.
! Silence suppression
! Comfort noise insertion
! Echo cancellation
The PVG can apply echo cancellation to its TDM-side circuits when this is required
to maintain voice quality.
! COT (Continuity Testing)
The PVG can apply continuity tones and loop-back tones on its TDM-side circuits
when required for CCS7 continuity testing.
! In-band digit collection and generation
! CLASS support
The PVG can provide V.23 modem capabilities to support CLASS data download
functionality for CS2000 V5.2 lines.
Up to three codecs can be provisioned for a given VSP: a compression codec and two
G.711 codecs. Supported codec capabilities:
! G.711, packet size 10ms or 20ms (VoIP) or 5ms (VoATM)
! G.729a and G.729b, packet size 10ms or 20ms (VoIP) or 10ms (VoATM)
! G.726 (VoATM only), packet size 10ms (VSP3 and VSP3-o also support 5ms
packetisation)
! In-band DTMF tone capabilities supported by VSP3 but not VSP2:
" RFC2833 is supported for G.711 and G.729
" For VoAAL2, VSP3 supports DTMF transport using I.366-1 Annex K
! Group 3 fax between two PVGs (VoIP or VoATM), with auto-change to G.711
! T.38 fax (VSP3 and VSP3-o VoIP only)
! Modem between two PVGs (VoIP or VoATM), with auto-change to G.711
! Text telephone between two PVGs (VoIP or VoATM), with auto-change to G.711
Codec negotiation takes place between the media gateways involved in a call to determine
the correct codec to use. The aim is that the codec used should be the codec that is highest
in preference order and supported by both gateways. The capabilities of each media
gateway are conveyed to its GWC and to the far-end gateway in the form of an SDP
(Session Description Language) session description, and an appropriate codec is selected
from the intersections of both gateways sets of capabilities. See see section G4.3 on page
751 for further information about codec negotiation, and section D4.6.1 on page 286 for
some examples of SDP relayed via ASPEN.
transparent to the PVG. The maximum number of E1 carriers per interface is 16. Each
V5.2 interface consists of bearer channels and shared C-channels.
The maximum number of line endpoints that can be supported over a given V5.2 interface
is 2048. No more than 6,384 V5.2 lines can be supported by a given line GWC. The
number of line endpoints defined and the number of bearer channels available at the PVG
determine the concentration that takes place between the V5.2 AN and the gateway. All
of the lines belonging to a given interface, and all the gateways (VSPs) serving that
interface, must be supported by one GWC.
! Bearer channels
The maximum number of B-channels per E1 carrier is from 29 to 31, depending on
whether TS16 and TS15 are defined as C-channels (TS31 is not available for use as
a C-channel). The maximum number of bearer channels available for a complete
V5.2 interface is approximately 480 (16 E1s with an average of 30 B-channels),
while the maximum number of bearer channels for a line GWC is 3,840. The
number of line endpoints defined (see below) and the number of bearer channels
available at the PVG determine the concentration that takes place between the V5.2
AN and the gateway.
PVG
AN Shelf 1 GWC
VSP-A
V5.2 C-path
Primary E1-Link
SG
Call
Packet Network
V5UA
Bearer MG control
Managed
RTP
VSP-B
V5.2 C-path H.248 Media
Secondary E1-Link SG control
RTP
Bearer MG
Shelf 2
Figure 34: V5.2 configuration with redundant VSPs
V5.2 protection switching ensures that V5.2 signalling continues over the secondary V5.2
link in the event of a failure. Use of the recommended configuration illustrated in Figure
34 ensures that continuity of service is maintained when either the primary V5.2 link or
the VSP card fails. What happens is as follows:
! Existing calls on the unaffected links are maintained. Calls on the affected link will
drop, but users can re-originate immediately. V5.2 signalling immediately switches
to the protection link for call and interface control, and new (reorginated) calls will
use B-channels on unaffected E1s terminated on either VSP.
! Calls on other V5.2 interfaces served by VSP-A signalling links are unaffected.
V5.2 protection switching and its operation are completely transparent to the V5.2 AN
connected to the V5.2 interface.
The AN sizes being used must be taken into account when V5.2 interfaces and the VSPs
used to support them are configured. For example, use of small ANs with line sizes of 120
or 240 lines makes it possible to maximise GWC line capacity, but may cause VSP
capacity to be exceeded if only two VSPs are used, depending on the VSP BHCA capacity
and the traffic model for the lines being served. See A89009559 and the separate Nortel
document IAW Engineering Guidelines for details.
[1] PVG software upgrades are performed shelf by shelf, and the entire shelf is out of service for the duration of the
upgrade. The only way to avoid service outage during upgrades is therefore to ensure that the VSPs used for a
given V5.2 interface are in separate shelves. These may be in the same PVG frame or in different frames.
CS2000 Core
Basic interoperability via
non-FT trunks with units
served by other CS2000s
H.323 proxy H.323 Other
(GWC equivalent) proxy GWCs
Business Communication
Proprietary Meridian 1 Call Server for
units IP PBX Manager Enterprise
(BCM) (CSE1000)
Cisco
access router / Westell
Third-party DPNSS gateway
units gatekeeper
(2600 / 3600 / (InterChange
7200) iQ203x)
H.323 H.323
proxy proxy
GWC DPNSS over QSIG GWC
(in QSIG Facility IEs)
DPNSS DPNSS
over H.323 over H.323
(in H.225 (in H.225
UUI IEs) UUI IEs)
IP core network
DPNSS DPNSS
over E1 over E1
carriers Westell Westell carriers
Digital iQ203x iQ203x Digital
PBX Bearer connections PBX
gateway gateway
CS2000 CS LAN
CS2000 Core
MS2000
GWC
GWC-gateway
Dual PP8600s signalling (H.248)
In ISN07, CS2000 supports the deployment of the MG9000 as a carrier-located line media
gateway. It is described in section B2.8.2 on page 120.
A fully equipped four-shelf frame in which only the master shelf has a packet network
connection is regarded as one logical MG9000 unit. This configuration offers 61 service
module slots per frame (13 on the master shelf and 16 on each subtending shelf), and thus
supports the following access network capacity:
! 1952 POTS lines per frame
! 488 POTS+ADSL lines per frame
Multi-frame MG9000 configurations are also supported. There is a single master shelf for
the configuration as a whole, subtended by all the other shelves in the same frame and in
different frames. In ISN07, the largest MG9000 configuration supported is one with three
frames, which can support up to 5,920 POTS lines. A multi-frame configuration can be
equipped with a second packet network connection if this is believed to be necessary to
provide sufficient capacity for the expected traffic profile. Such a second packet network
connection is also housed in the master shelf of the configuration.
Customer LAN
Customer LAN Gateway
MGCP
RJ-11 or Codecs LAN interface MGCP
RJ-21X supporting supporting Alternative IP
terminations analogue / access to the access
for analogue digital IP backbone technologies
backbone
subscriber conversion network via a Bearer flows available network
lines (G.711, G.729) customer LAN
Bearer flow
Typically, customer LANs supporting line media gateways use a firewall / NAT (Network
Address Translator) to provide security. To support NAT traversal for signalling traffic,
media gateways and other hosts that are located behind a NAT must:
! Initiate communication with their GWCs (a GWC cannot initiate communication
with a gateway behind a NAT).
! Provide their GWCs with address information embedded in signalling packets,
which the GWC can then map on to the source address in the packet header (which
is that of the NAT rather than the gateway).
! Use keep-alive messaging to ensure that communication with their GWCs is
maintained when no call is in progress (the GWC will otherwise be unable to send
setup messages for calls incoming to the gateway).
Dynamic address discovery for signalling is described in detail in section D8.4 on page
322.
Address discovery is also a requirement for bearer connections across the packet
backbone network. This involves the use of a media proxy, as described in section
B5.1.2.2 on page 155.
Support is also provided for Mediatrix 1124 customer LAN gateways under the Nortel
Business Partner Program. The Mediatrix 1124 supports up to 24 analogue subscriber
lines by means of a 50-pin RJ-21X connector.
A variety of hardware platforms can be used to support MTA line gateway capabilities
for CS2000 solutions. The basic functionality provided is the same regardless of the MTA
model. Depending on the market for deployment, an MTA may use either of two versions
of the DOCSIS (Data Over Cable System Interface Specification) protocol, as follows:
! MTAs for deployment in Europe use EuroDOCSIS 1.1 or 2.0.
! MTAs for deployment in Australia, Japan and CALA use DOCSIS 1.1 or 2.0.
The MTA model and the DOCSIS version used involve only the MTA and the CMTS,
and are transparent to the CS2000 GWC. To avoid repetition, this section uses the name
DOCSIS to denote both DOCSIS and EuroDOCSIS (except where the difference between
them is significant), and uses the generic name MTA to denote any MTA type.
CVX1800
Packet network
CCS7 trunks to/from
TDM network
B3.1 Introduction
A media server is a centralised resource for the delivery, management and manipulation
of packet-based media streams and services over the backbone network.
Note: This CS2000 Product Description is not intended to be the primary source of
information about supported media servers and their capabilities. Media servers are
products in their own right, and for detailed, definitive information about the capabilities
of a given server type it is necessary to refer to its product documentation. In the event of
any discrepancy between statements made in this chapter and statements made in a media
servers product documentation, the server product documentation should take
precedence.
In ISN07, CS2000 supports the following types of media server:
! AudioCodes MS2000 Series media servers, which are described in section B3.2 on
page 135. Two models are available:
" The MS2010, which is for use in VoIP solutions
" The MS2020, which is for use in VoATM (VoAAL2) solutions
! UAS (Universal Audio Server), which is described in section B3.3 on page 138.
MS2000 Series media servers have been introduced in ISN07 as compact, enhanced
replacements for the Universal Audio Server (UAS). Deployed UASs are still supported,
but MS2000 Series units are to be used for all new media server deployment.
Although logically and functionally a media server is a centralised resource, the
MS2000/UAS is in practice co-located with the CS2000 and connected to the CS2000 CS
LAN.
Figure 42 illustrates the physical and logical configuration of MS2000 Series MS2010
and MS2020 media servers.
Module 0
Figure 42: Physical and logical configuration of MS2000 Series media servers
B3.2.2.5 OAM&P
! Provisioning via APS (Audio Provisioning Server). One APS can support
co-ordinated provisioning for multiple media servers.
! Management/control via CLUI (Command Line Uer Interface) provided by CS2000
IEMS (Integrated Element Management System). The IEMS can provide
management capabilities for all the media servers belonging to a CS2000.
Figure 43 illustrates the alternative UAS configurations used for IP and ATM.
CPU
Connection with PP8600 for
signalling over the CS LAN
(e.g. H.248 to/from the
audio GWC)
CPU
Connection with PP8600 for
signalling over the CS LAN
(e.g. H.248 to/from the
audio GWC)
PA200 R200
card TM Direct STM-1 bearer
connection with the external
backbone packet network
The UAS is built on the Nortel SAM16 platform, which is so called because it is a
single-shelf Service Application Module (SAM) with 16 slots for housing PCI-based
cards. A SAM16 consists of two 8-slot subsystems or domains, each of which is organised
as follows to provide UAS functionality:
! One slot for the host controller CPU (700MHz 5370 processor)
! One slot for a Hot Swap Controller (HSC)
! The remaining slots are available for cPCI I/O cards providing DSP functionality
and/or interface terminations for bearer connections. Assuming the 5370 processor
is used, these are used as follows:
" For IP, all six slots are available for CG6000 DSPs
" For ATM, one slot is used for a PA200 STM-1 card, leaving five slots
available for AG4000 DSPs
B3.3.5.5 OAM&P
! Provisioning via APS (Audio Provisioning Server). One APS can support
co-ordinated provisioning for multiple UASs.
! Management/control via UAS Manager, which provides logs, alarms, OMs,
configuration management and state indications. One UAS Manager can serve as
the Device Manager for all the UASs beonging to a CS2000.
This chapter describes the hardware used to provide VoIP support for remote CentrexIP
clients served by CS2000. It is organised into the following sections:
! Section B4.1: Network Configuration for CentrexIP Client Access
! Section B4.2: CentrexIP Clients and their Capabilities on page 146
! Section B4.3: CentrexIP Client Manager (CICM) on page 149
for CentrexIP clients as if they were legacy business sets controlled via the proprietary
P-phone interface.
As a large line gateway, a CICM can share a GWC with other gateways of the same type,
i.e. another CICM or an MG9000, but not with small CPE line gateways.
Figure 44 illustrates the network configuration used by CS2000 to provide VoIP support
for CentrexIP clients.
CentrexIP Client
Manager (CICM)
Perceived by
CS2000 as
large gateway
Etherset client (i200x):
IP-enabled Ethernet
phone with display
and function keys H.248 P-Phone
Dual PP8600s
Display, e.g.
for CLI of
incoming call
Feature keys
with
dynamically
Standard assigned
numeric functons
keypad for
point-and-clic
k dialling
Figure 45: CentrexIP soft client user interface (as displayed in PC window)
The primary purpose of a PC-based soft client is to complement a users desktop phone
by providing point-and-click control over call handling. Typically, however, the speech
path is routed through the users telephone set, as this offers a quality of service superior
to that of a PC.
A further advantage of a PC-based soft client is that it can be used to extend the
capabilities of a business users desktop line to wherever that user may be. For example,
a user can log in to the corporate telephone network from a hotel room using a laptop, or
from a desktop PC at home. In either case, the fact that the soft client is provisioned with
the same telephone number as the desktop phone means that incoming calls will
automatically be redirected to the CentrexIP soft client, and that outgoing calls will be
handled in exactly the same way as if they originated from the desktop phone. The
standard set of non-VoIP capabilities supported by the corporate network is also available,
e.g. email.
The login process establishes an IP connection with the CICM, determines the DN for
which the soft client is to provide VoIP support, and causes the CICM to configure the
clients capabilities in accordance with the profile of the logged-in user, e.g. by
downloading an appropriate set of feature key assignments.
Support for the standard TAPI interface makes it possible for CentrexIP soft clients to be
connected to TAPI-aware applications such as contact databases or customer care
systems, and to use these to make calls.
B1.4.5.1: GWC Configuration and Operation on page 60. For CICM, the mechanism
referred to as Dual Node Redundancy (DNR) and the process as hitless failover.
The hardware characteristics of the Motorola 5385 controller cards used as the platform
for the CICM are as follows:
! 1.2GHz Pentium processor
! Up to 2Gbytes of 266MHz double data rate (DDR) SDRAM
! PCI-X internal bus for high speed on-board communication
! Dual GigE interfaces
B4.3.2 Capacity
One CICM can support up to 3050 CentrexIP clients. These are provisioned on the
CS2000 Core as lines served by large line media gateways and belonging to line groups.
In call processing terms, the CS2000 Core perceives CentrexIP clients as equivalent to
lines serving business sets, and controls their operation by means of the proprietary
P-phone signalling described in NIS S106-2.
As described in section C2.7.1 on page 196, the line group mechanism permits the
definition of logical frame and unit numbers for use in identifying lines. These provide
information equivalent to that used in defining the physical location of slots housing
traditional line cards.
The maximum number of lines in a line group is 1024. At least three line groups must
therefore be defined to support access to the maximum number of 3050 CentrexIP clients
that can be supported by a CICM. All the line groups used to support access to a given
CICMs clients must be controlled by a single GWC.
A given CICM line group can support access to CentrexIP clients belonging to different
enterprise networks. The CICM automatically detects the network association for each
terminal that is connected to it, which allows users to roam across different networks and
still obtain service. See section B4.3.3 for more details.
A media proxy (strictly speaking, a media transport proxy) is a network element that
terminates and re-originates the transport layer for media traffic. It acts as an intermediary
in a call between two packet network endpoints when the media stream for the call is
routed through one or more Network Address Translators and NAT traversal is therefore
required. Section B5.1 discusses media proxy functionality and NAT traversal in generic
terms. Section B5.2 on page 156 describes the capabilities of the RTP Media Portal, which
is the media proxy implementation supported by CS2000 in ISN07.
CS2000 Core
(call processing)
Control / signalling
Media stream
Line CentrexIP
GWC GWC
H.248
MPCP
Uni
CICM
Public address MGCP
discovery for
signalling UniStim
Table 6: Rules for inserting a media portal in a call between two media gateways
Location of terminating media gateway
MP with MP with
Private VoIP one private VoIP I/F one private VoIP I/F
No MP required
originating media gateway
No MP if both GWs in
MP with MP with two public I/Fs,
same domain;
Enterprise one private VoIP I/F one direct to gateway
otherwise, MP with
domain and one public I/F to and one to
two public I/Fs to
enterprise NAT device enterprise NAT device
enterprise NAT devices
Note: In terms of whether a media proxy needs to be inserted in a call, inter-CS calls
between media gateways controlled by different CS2000s are handled in the same way as
calls between gateways controlled by the same CS2000, provided that both CS2000s
belong to the same VoIP address domain. See section B5.2.4.4 on page 161 for
information about how calls between CS2000s belonging to different address domains are
handled.
Figure 47 illustrates the three possible locations for CS2000 media gateways in terms of
the address domains or VPNs to which they belong, and indicates how the RTP media
portal may be involved in supporting different types of connections between media
gateways.
CS2000 CS2000
Call processing Call processing
and service logic and service logic
(CS2000 Core) (CS2000 Core)
MG in VoIP MG in VoIP
address domain address domain
(private) (private)
Private addresses
Public addresses
MG in MG in
public / common Public / common address domain (DMZ) public / common
address domain address domain
(no NAT) (no NAT)
NAT NAT
MG in MG in
enterprise Other private address domains, e.g. for enterprise VPNs enterprise
address domain address domain
(behind NAT) (behind NAT)
Internet Gateway
Transparency topology
Application data
(ITA)
Connection MB lookup
broker (Middlebox
data)
GWC
Gateway control MPCP
engine (MGCP engine
or H.248) (for RMP)
Figure 48: Interaction between GWC components to for media portal control
When an RTP media portal is to be inserted in a call, the GWC controlling the selected
media portal sends the portals host CPU an MPCP message requesting a media portal
connection. The host CPU selectes one of its peripheral cards to host the multimedia
session, basing the selection on which card currently has most ports available. Card
selection determines which IP addresses are made available for media streams, because
each peripheral card has two static IP addresses: one on the private internal network (the
Succession address domain), and one on the public external network.
Each peripheral card manages two pools of UDP ports, one for each of its IP addresses.
Ports are randomly allocated from one or both of these pools in response to MPCP
commands sent by the MP GWC to request resources for the multimedia session. As ports
are allocated, the count of available ports is updated accordingly, ensuring that a
peripheral card is not selected for a new session if all of its ports have already been
allocated.
When two ports on a peripheral card have been dynamically allocated to a multimedia
session, a media stream can be routed across the media portal via those ports. There are
two possible scenarios:
! Media stream using one private and one public port on the media portal to traverse
the boundary between the private VoIP address domain and the external public
address domain.
! Media stream using two public ports on the media portal to traverse the boundary
between two external address domains, e.g. two private domains belonging to
different enterprise VPNs.
The two RTP media portals in a SAM16 shelf are independent active units.
One or two SAM16 shelves housing two or four RTP media portal units can be housed in
a dedicated PTE2000 frame.
One CS2000 GWC can control up to 20 RTP media portals. Together, these provide a
pool of resources (IP addresses and UDP ports) for the use of the GWC.
Equal usage of media portals is ensured by using a selection mechanism that cycles
through all the RTP media portals in the pool available.
Each peripheral card has two IP addresses, one from the private Succession domain and
one from the public domain. Each peripheral card also has a number of UDP ports (half
private, half public) determined when it is configured. When a GWC determines that a call
requires media portal capabilities, it selects and uses whichever peripheral card has most
free UDP ports. Redundancy is achieved by provisioning more UDP ports than strictly
necessary for the expected traffic flow.
B5.2.6.5 OAM&P
! Provisioning, management and control via MCS Manager EM application
! The SIP Audio Server provides conferencing for MCS5200. It uses the same
platform as the UAS described in section B3.3: Universal Audio Server (UAS) on
page 138. Like the UAS, it provides ports for the termination of media flows to/from
conference participants.
! The RTP Media Portal supports Network Address and Port Translation (NAPT),
which enables it to acts as a firewall and media portal for RTP/RTCP media flows
between endpoints in the private MCS5200 LAN and endpoints on the managed IP
backbone network. It is controlled by the SIP Application Module. NAPT can be
performed both on the destination IP address and port and on the source IP address
and port for each IP packet that traverses the media portal . The portal can thus relay
packets between two endpoints located in different networks and using different IP
address domains.
! The SIP PRI Gateway provides media gateway functionality between a
circuit-based access network and the packet-based MCS5200 LAN. On the access
network side, the SIP PRI gateway supports ISDN PRI connections (30B+D or
24B+D), while on the MCS5200 LAN side it supports SIP signalling and RTP
bearer connections. The gateway performs mapping between PRI (Q.931)
signalling and SIP signalling, and is responsible for the conversion of packet-based
voice streams to circuit-based voice streams.
The BPSs of the MCS5200 LAN rely on an appropriate routing switch such as PP8600 to
provide connections with the core network. GigE links are used between the BPSs and the
routing switches.
This chapter describes the software loads that are required for the various constituent units
of a CS2000 in order to create a complete operational system.
It also lists the software loads for complementary non-CS2000 components such as media
gateways, and for OAM&P units supporting Element Managers (EMs).
It is organised as follows:
! Section C1.1: CS2000 Core Load on page 173
! Section C1.2: Loads for Other CS2000 Components on page 176
! Section C1.3: Loads for Media Gateways and Servers on page 178
! Section C1.4: OAM&P Software on page 179
Figure 51 illustrates the layered structure of the software in the CS2000 Core software
load used by CS2000 in ISN07.
TOPS DRU
World Trade DRU (WT20), (TOPS20),
comprising comprising MSH
market-specific operator (Multi-Service Hub)
Product Layer custom software services DRU (MSH20),
and general-purpose software. supporting
international software (in load, but CS2000-related
functionality connectivity)
is not
Common software (CCM20) supported
(lines software applicable both in ISN07)
internationally and in Nth America)
Shared Library (SHR20)
(software applicable for other Nortel
products as well as CS2000)
Base
(BASE20) Basic computing functionality
(processor support, memory management, etc)
Figure 51: DRUs and libraries included in the ISN07 Core load (XA-Core or 3PC)
ISN software loads can support dual working configurations in which conventional
circuit-based trunk and line peripherals are used as well as trunk and line media gateways,
allowing TDM and packet capabilities to be supported in parallel. Looparound trunks are
used to support call interworking between the TDM and packet environments, as
described in section B2.3.2.5 on page 107.
Table 13: Order codes for base capabilities provided by other CS2000 components
Order code Name / description
GWCW0070 Gateway Controller NCL (inc. RMGC)
SAM20070 Service Application Module NCL
CICM0070 CentrexIP Client Manager
NGSS0070 Session Server
RMPx0070 RTP Media Portal
MS200070 MS2010
MS2A0070 MS2020
UASA0008 Universal Audio Server NCL
GSS00033 Global Server SW Rel 3.2 NCL for UAS
GSSB0002 3rd Party MS Windows 2000 OS
GSSB0003 3rd Party MS Windows 2000 Res kit
GSSB0004 Windows Terminal Services Client
GSSB0006 Ghost Enterprise Software
APS00007 Audio Provisioning Server NCL
APSB0007 3rd Party AdventNet 4.1
USP00090 Universal Signalling Point Server NCL
USPL0090 Basic Universal Signalling Point - Compact
SSAS0001 SSAS Basic Platform
SSAS0002 Basic OAM&P
SSAS0004 IP High Speed Link
SSAS0005 SSOMs
SSAS0007 GUI Workstation
SSAS0011 Routeset 256 to 511
SSAS0012 Routeset 512 to 767
SSAS0013 Routeset 768 to 1023
SSAS0014 Routeset 1024 to 1279
Table 13: Order codes for base capabilities provided by other CS2000 components
Order code Name / description
SSAS0015 Routeset 1280 to 1535
SSAS0016 Routeset 1536 to 1791
SSAS0017 Routeset 1792 to 2047
SSAS0018 Routeset 2048 to 4000
SSAS0019 ITU High Speed Link
SSAS0021 OSS Electronic CLI
[1] Comprises Succession Server Platform Foundation Software (SSPFS) platform, line / trunk
provisioning applications, GWC EM, SAM21 EM, UAS EM, LMM, TMM, NPM and QCA.
CNOM0001 CNOM PH 1
CNOM0002 CNOM OM 02
SBM00006 SBA-SMDR
CICE0070 CICM EM
See document
START CS2000 Configuration
(NN10193-511)
Unlock carrier
on gateway
BSY trunk
members on TMM
RTS trunk
members on TMM
FINISH
START
Unlock carrier
on gateway Add logical terminal data
to table LTCALLS
FINISH
C2.6.1 Overview
Dynamic Packet Trunks for inter-CS signalling are supported by DPT GWCs with no
subtending units. DPTs are so called because trunk characteristics such as the ISUP
protocol variant to be used are determined on the basis of the telephony profile of the
selected route, which is downloaded to the DPT GWC during call establishment. For
SIP-T, the telephony profile indicates the protocol characteristics of encapsulated CCS7
signalling messages, which can be those of any supported ISUP or TUP variant. For SIP,
the telephony profile indicates the CCS7 protocol that is to be interworked with SIP,
which in ISN07 can only be IBN7 ISUP. The telephony profile itself is selected on the
basis of the far-end host name, as determined by translations and routing for an originating
CS2000 or as indicated by the first incoming message for a terminating CS2000.
Typically, SIP-T is used for signalling between CS2000s, while SIP is used for signalling
between CS2000 and MCS5200.
The DPT GWCs on a CS2000 provide a pool of resources that can be used for connections
to any peer CS2000 or compatible MGC. A DPT GWC is selected and allocated only for
the duration of a given call, and is then returned to the pool for re-use.
To support inter-CS signalling, the operation of DPT GWCs is co-ordinated with that of
one or other of the following unit types:
! The preferred implementation with effect from ISN07 is based on DPT GWCs
interacting with the Session Server. SIP signalling is terminated on the Session
Server, which extracts the CCS7 signalling and passes it on to the DPT GWC.
! Prior to ISN07 (and still supported), the standard implementation was based on a
DPT GWC interacting with another GWC configured as a VRDN (Virtual Router
Distibution Node) to provide an externally visible IP address as a point of initial
contact for its host CS2000. In this implementation, DPT GWCs were responsible
for terminating SIP signalling and extracting CCS7.
Figure 13 on page 63 illustrates how DPT GWCs interact with these other units to support
inter-MGC communication via SIP / SIP-T.
DPTs do not use the static point code and circuit concepts on which CCS7 is based (OPC,
DPC and CIC); a DPT can handle a call to/from any other CS in the network. To enable
dynamic trunk provisioning, a telephony profile name is passed as part of the SIP-T
INVITE message used to set up an inter-CS call. This profile maps on to a set of trunk
subgroup characteristics, including protocol support, which are associated with a
particular trunk subgroup by means of CS2000 datafill.
Each CS2000 is identified by means of a unique hostname, which is specified as an office
parameter in table OFCENG. Each combination of source hostname, destination
hostname and telephony profile name is unique across the network. This makes it possible
for network operators to agree on the services and protocols to be supported between pairs
of CSs, and to ensure that datafill on different CSs is co-ordinated. The information
provided in the INVITE message ensures that the destination CS selects appropriate
resources to handle the incoming SIP-T call.
START
Does
Add new N destination N
members to existing for new trunk group
SIP-T trunk group already exist
[Y/N]? [Y/N]?
Add new destination
Y Y (name of remote CS2000)
to table MGCINV
Add new trunk group
name to table CLLI
Is the
new destination N
Add trunk group data served by an existing
to table TRKGRP VRDN
[Y/N]?
Y
Add trunk group data
to table TRKSGRP Add new VRDN definition
to table VRDNINV
Are
the new trunks Y Add remote MGC name
required to increase to table TELEPROF
capacity
[Y/N]?
N Add new SIP-T GWC
definition to table
SERVSINV The decision about whether
Add new range of SIP-T to add a new SIP-T GWC or a
trunks to table DPTRKMEM new VRDN depends on the
BSY SIP-T pool from amount of capacity that
DPTTRM level of MAP needs to be engineered to
handle the traffic between
BSY SIP-T pool members two CS2000s (see section
from DPTMEM level of MAP B1.4.7 on page 66 for details)
RTS SIP-T pool from
DPTTRM level of MAP
FINISH
Table 18: Algorithm to determine the connection role for both agents
Default / preferred agent roles Result of dynamic role modification
Table GPPTRNSL
Table GPPTRNSL [1] contains an entry for each V5.2 interface supported. Each entry
provides information via the following fields:
AMCNO This defines a four-character site identifier, together with frame and unit
numbers that together allow the interface to be identified.
Note: The information provided by the AMCNO field is equivalent to that
provided for line groups via the GRPNO field of table LGRPINV (see section
C2.7.1 on page 196), i.e. logical identifiers that call processing can interpret
as if they defined the physical location of slots housing traditional line cards
CSPMNO This specifies that the interface is hosted by a GWC, and provides the GWC
identifier as defined in table SERVRINV.
IP_V52 This has the following subfields:
V5LINKID Used to assign identifiers to each of the E1 carriers (up to 16) that
make up the V5.2 interface.
V5ID Unique identifier of the V5.2 interface.
V5PRID V5 provisioning set identifier corresponding to a particular way of
assigning the C-channels for the interface, as defined in table
V5PROV.
MAXLINES Maximum number of line endpoints (up to 2048) that can be supported
via the interface, i.e. the AN size.
Note: Although any size may be specified, only the AN types/sizes
listed below are fully supported. If an AN size other than one of these
is specified, the number of line endpoints actually reserved will be
rounded up to the next supported AN size, e.g. a size of 375 would be
accepted, but would cause 480 lines to be reserved.
Type Size Max. ANs Lines reserved
Small120 120 53 6360 [1]
Small240 240 26 6240 [1]
Small480 480 13 6240 [1]
Small 672 9 6048
Medium 1344 4 5376 [1]
Large 2048 3 6144 [1]
V5SIGID Signalling profile identifier corresponding to a set of signalling
characteristics, as defined in table V5SIG.
V5RING Flexible ringing cadence identifier corresponding to a ringing cadence
profile, as defined in table V5RING.
[1] This is the maximum number of V5.2 line endpoints that can be defined for a given
GWC using only ANs of this size without exceeding the GWC maximum of 6400
lines. Using a mix of AN sizes, the maximum number of V5.2 lines that can be
defined for a GWC is 6384.
[1] Table GPPTRNSL is so called for historical reasons, because V5.2 lines served by DMS-MMP switches are
terminated on GPP (Global Peripheral Platform) units. It can have a theoretical maximum of 1000 entries.
Table V5PROV
A V5 provisioning set defines the C-channel characteristics of a V5.2 interface, i.e. which
channels are used as C-channels and what type of signalling they convey. The
provisioning sets available are defined in table V5PROV, and each V5.2 interface
definition in table GPPTRNSL refers to one of these provisioning set definitions to
allocate C-channels. A given provisioning set definition can be used for any number of
V5.2 interface definitions that have the same C-channel characteristics.
Up to four C-channels (two active channels and two backup channels) can be allocated for
a given V5.2 interface via a provisioning set. Table V5PROV allows the following
information to be defined for each C-channel in a provisioning set:
CHNL_ID Logical channel identifier in the range 0-9
LNK Identifier of the link (PCM30 carrier) supporting the C-channel (1-16)
CHNL Identifier of the channel to be used for the C-channel (16 or 15)
CPATH The type of signalling to be conveyed over the link, which is one of:
CNTRL Control signalling (BCC, protection, link control)
PSTN PSTN signalling (LAP-V5 DL equivalents of analogue signals)
PROT1, PROT2
The links to be used as alternatives in the event of a failure.
Table V5SIG
Different national markets have different requirements for signalling. Table V5SIG
allows a set of signalling characteristics to be defined as a signalling profile, and
associated with a V5.2 interface by means of a reference to V5SIG from the interface
definition in table GPPTRNSL. Each CS2000 supports one predefined profile identified
as DEFAULT, and can also support up to 127 other named profiles defined in table V5SIG.
This powerful and flexible mechanism facilitates the rapid deployment of V5.2 interfaces
in new national markets.
Table V5RING
V5.2 allows up to 32 different ringing types or cadences to be identified in messages sent
to the AN. In a given market or network, ringing type 0 denotes national standard ringing,
while ringing types 1-31 can be used to denote distinctive ringing cadences required for
feature or service support.
The characteristics of the physical ringing associated with each ringing type are
determined by national standards and/or bilateral agreements. Physical ringing is
implemented by the AN, and is the responsibility of the AN supplier. The role of the V5.2
protocol is to use V5.2 to tell the AN which ringing type is required in a given scenario.
Table V5RING allows mappings to be defined between ringing cadences as known to the
AN (ring chars 0-15) and cadences as known to V5.2 call processing on the CS2000 Core
(ringing types 0-31). These mappings can then be assigned to one or more V5.2 interfaces
via table GPPTRNSL.
After a line endpoint has been identified to the GWC Manager, its name can be used in
device/media control messages exchanged by the GWC and the gateway. For an MTA
gateway controlled via NCS, an example of a fully qualified line endpoint name is
aaln/1@rgw-2567.whatever.net
For information about the procedures for adding GWC, gateway and trunk endpoint
datafill, see the document CS2000 Configuration (NN10193-511).
Craftsperson 1
at NOC CMTS / MTA
management application
4a Central servers
3a 2 LDAP
CS2000 provisioning 8a server
applications on DNS
Sun Netra server server
8b
4b 3b 5c 6c
5b 6b
Cable access network
CMTS
The aim of translation is to analyse dialled numbers to determine the correct trunk route,
line termination or treatment to use for call completion. CS2000 uses two types of
translation process, each with its own set of translation tables:
! Universal translations for calls via the public network (see section C3.5)
! IBN translations, which support a range of facilities originally designed for business
use, such as feature codes and various types of abbreviated dialling (see section
C3.3)
CS2000 can use both types of translation on a given call, which makes more complex
number analysis possible. This chapter discusses CS2000 translations and routing under
the following headings:
! Section C3.1: Overview
! Section C3.2: NCOS Screening
! Section C3.3: IBN Translations
! Section C3.4: Indirect Access to Universal Translations
! Section C3.5: Universal Translations
! Section C3.6: Codec Selection via Translations
! Section C3.7: Routing
! Section C3.8: Support for CCD (Clear Channel Data) Calls
CS2000 also uses reverse translation to support the display of diallable calling party
numbers on called party terminals (see section F2.2.9.2 on page 544 for details).
C3.1 Overview
For calls via the public network, CS2000 uses universal translations for the analysis of
dialled numbers to determine the correct route to use for call completion. Dialled numbers
are not, however, presented directly to universal translations. CS2000 uses Centrex
software, which means that the following types of preliminary screening and translation
can be performed before numbers are passed to universal translations, which can thus
focus more efficiently on analysing numbers in terms of the PSTN numbering plan:
1 NCOS (Network Class Of Service) screening for direct subscriber access. The
NCOS value assigned to a line or incoming trunk determines the types of call that
can be made from that line or trunk. See section C3.2 for details.
2 IBN (Integrated Business Network) translations for direct subscriber access (and for
non-interconnect incoming trunks). These are responsible for feature (de)activation,
for access to emergency/assistance services, and to initiate digit modification for
local calls that require the area code added to the originating number for billing
purposes. Calls that pass screening are then passed to universal translations. See
section C3.3 for details.
3 Access and authorisation code checks for indirect access via network interconnect
services, which rely on the Centrex feature Meridian Off-Net Access (MONA) to
provide security. See section C3.4 for more information.
Figure 56 is an overview of the translation process for calls from various sources.
LINEATTR
Links between IBN translations and universal translations
Universal translations
Note: CS2000 supports indirect VPN access as well as indirect access to alternative
long-distance carriers. In this case, IBN translations are entered after authorisation
screening, not universal translations.
Table 20: Typical minimum list of NCOS values for a customer group
NCOS values (in the column for each NCOS value,
Type of call Y = call type permitted, N = call type to be barred)
0 1 2 3 4 5 6 7 8 9 10 11 12 13
Prem. Rate Adult Y N N N N N N N N Y N Y N Y
Prem. Rate Info. Y Y N N N N N N N Y Y Y Y Y
International Y Y Y N N N N Y N N N Y Y N
Mobile Y Y Y Y N N N N N Y Y N N N
Operator Y Y Y Y Y N N Y N Y Y Y Y Y
National Y Y Y Y Y N N Y Y Y Y Y Y Y
Local Y Y Y Y Y Y N Y Y Y Y Y Y Y
Free Y Y Y Y Y Y Y Y Y Y Y Y Y Y
The default NCOS value of 0 means that all call types are permitted, and that any required
barring is performed later in translation or by means of feature processing.
Because all lines and trunks belong to customer groups (see section C3.3.1), and are thus
assigned NCOS values, call originations can be screened on the basis of the associated
NCOS value before the call enters IBN translations. This screening can be implemented
in either of two ways:
! Direct CODEBLK screening
Table NCOS defines a Code Restriction Level (CRL) value for each NCOS,
indicating whether the combination of call types identified by that NCOS is to be
BLOCKED or ALLOWED. For each number prefix or special number that can be
dialled from a customer group, table CODEBLK lists all the CRLs that are to apply,
thus establishing a link between the NCOS value assigned to an incoming trunk and
the types of call that can be made from that trunk.
! Preliminary translator screening
Instead of directly specifying a CRL for every NCOS, table NCOS may instead
specify preliminary blocking translators for some NCOS values. Table CODEBLK
still controls screening for NCOS values with a directly associated CRL. For other
NCOS values, however, table IBNXLA is consulted to find the related preliminary
translators, each of which will specify blocking and routing to treatment for calls to
a given number prefix or special number. The set of blocking translators for a given
NCOS thus defines (by exception) the types of call that can be made from incoming
trunks with that NCOS value.
Note: There are also entries in table IBNXLA for dealing with feature activation requests.
These entries are common to all customer groups and are not associated with a particular
customer group translator. They activate feature software without any further translation
or any reference to table LINEATTR. For example, an entry beginning RESFXLA 70 FEAT
CFWP would control Call Forward Programming.
In each case, it is the CODE table that actually defines the translations to be performed.
Each entry in the CODE table is a translator that specifies the translation result for a given
digit range. If this translation result is the selection of a route (RTE), the CODE translator
also specifies a destination number corresponding to one of the entries in the RTE table.
Translation ends when a line or trunk route has been selected via the final RTE table to be
used.
There is only one CODE table and one RTE table for each translation stage. The HEAD
table provides an implicit structure for these CODE and RTE tables by defining the names
of CODE and RTE translators. For each translator name listed in a HEAD table, there is
a set of translators (table entries) with that name in the corresponding CODE table, and a
set of translators (table entries) with that name in the corresponding RTE table, as
summarised in Figure 57. The HEAD table also minimises datafill by specifying various
default options that apply to all the CODE and RTE translators with a given name.
HEAD table
GRP1XLA <default options>
GRP2XLA <default options>
CODE table
GRP1XLA <digit range> <translation result = CONT>
Multiple CODE GRP1XLA <digit range> <translation result = DMOD>
and RTE entries GRP1XLA <digit range> <translation result = RTE DEST 1>
(translators)
for each name RTE table
defined in the GRP1XLA <route reference = 1> <route selector>
HEAD table GRP1XLA <route reference = 2> <route selector>
HEAD Defines translator names to be used by sets of CODE and RTE translators. For
each name it defines, the HEAD table specifies:
- A default translation result (for use if there is no CODE translator
with a digit range covering the digits being translated)
- Default options (typically the name of the next set of translation
tables to use on a CONT result, e.g. FA after PX)
- Whether digits used to index the table are consumed (default no)
- Whether non-decadic digits may be used (e.g. * or # for features)
CODE Defines the translations to be performed for each translator named in the
HEAD table. There is a set of CODE translators for each translator name
defined in the HEAD table. Each one specifies the translation result for a
given digit range.
For prefix translation via table PXCODE, the typical result is CONT (go
directly to another translator) or DMOD (perform specified digit modification
and then go to another translator); PXCODE translation does not result in the
selection of a route.
For area code translation via table FACODE, the typical result is RTE (route
selected), and the options include a destination number corresponding to one
of the RTE translators.
RTE For each destination associated with an RTE result in the CODE table, this
lists either a CLLI or an index into a table (e.g. IBNRTE or OFRT).
2 dialling
options for
5 dialling
direct access
Feature options for
(de)activation code direct access
Service number
IBN translations (table CUSTHEAD
LINEATTR
Access to PXCODE prefix translations
PXCODE local
PSTN translators
insert area codes PXCODE national PSTN translator
for local calls
IBNXLA
activates
appropriate IBNRTE OFRT, FARTE, CTRTE
feature Lists line routes Lists trunk routes
software Line selection by DN Trunk group selection by CLLI
Table
CCNTLGRP
IBNXLA
Table processing
DTMFSCRN
Table CALLCNTL
DIGMAN
Table manipulation
ACCTSCRN
There are call scenarios in which a compression codec should not be used:
! Calls for which compression has already been performed on another leg of the
end-to-end bearer path (e.g. calls originating from a mobile network).
! Call for which the additonal latency of using a compressed codec would add too
much of a delay (e.g. international VoIP calls).
Such scenarios cannot be determined in advance and controlled statically via datafill.
Instead, they must be identified during translations or call screening so that appropriate
action can be taken. ISN05 feature A19012781 introduced the SETCODEC option, which
can be specified at various points in the translations process to allow a codec to be selected
on the basis of call-related criteria, as summarised in the following table.
xxCODE tables in universal translations Called party digits or called party NOA)
Service profile table CLISRVPF [3] Service profile associated with screened CLI
[1] See section C3.5.5 on page 214 for information about CALLCNTL and Universal Screening.
[2] See section F11.3.1.1 on page 636 for information about table DNSCRN.
[3] See section F11.3.1.4 on page 638 for information about table CLISRVPF.
The SETCODEC option specifies the CALLTYPE of the current call. This CALLTYPE
is an index into table CODEC, which in turn specifies the codec to be used for the call.
CS2000 Core communicates this alternative codec to the GWC during call setup. It takes
precedence over the codec(s) specified in GWC datafill, and is used by the GWC during
codec negotiation.
The following limitations apply to use of the SETCODEC option in ISN07:
! The only codec that can be selected via translations is the network default (G.711
a-law or G.711 -law, depending on network configuration).
! SETCODEC does not allow an alternative packetisation rate to be selected, only an
alternative codec.
C3.7 Routing
Routing begins when one of two possible route types has been selected via the final RTE
table to be used in universal translations:
! A line to a DN served by this CS2000 (see section C3.7.1)
! An outgoing trunk (see section C3.7.2)
In the event of a problem that prevents call establishment, a call may be routed to
treatment, as described in section C3.7.3.
Translations
Route index
Routing
table
(OFCRT, Datafill determines
FARTE, whether to apply
CTRTE) conditional routing
criteria, e.g. Least Cost
Routing (LCR) or Time
Of Day (TOD) routing
Route list
CLLI Search for idle trunk in
coresponding trunk group using
specified search algorithm
Route list
contains up to Try next
eight entries. entry in Idle
route list No trunk
These are
typically CLLIs, found?
but special entries
are also
supported. Yes
Seize trunk
and initiate
call setup
Note: It is possible to chain different route lists together to create a linked set of route
lists that together have more than the maximum of eight entries permitted in a single list.
of idle trunks available exceeds the minimum reserved for direct routed traffic.
Otherwise, alternate routed traffic is overflowed to the next trunk group in the route
list.
! CBK (Code Blocking)
When applied to an outgoing or two-way trunk group, CBK causes a specified
percentage of traffic with a specified destination code to be blocked and routed to
treatment. The destination code may be either a DN or a code type such as CCODE
(country code), ACODE (area code), NAC (non area code) or PFX (prefix).
! STR (Selective Trunk Reservation)
Allows traffic to be divided into four separately controlled categories on the basis
of:
" Whether it is direct routed or alternate routed.
" Whether it is destined for a code that has been designated as HTR (Hard To
Reach), e.g. for the purpose of a mass-calling event. A code designated as
HTR may be either a DN or a code type such as CCODE (country code),
ACODE (area code), NAC (non area code) or PFX (prefix).
Traffic control is applied at two levels on the basis of the following criteria:
" No blocking is applied when the number of idle trunks available in the trunk
group is less than the number specified as the threshold for Level 1 blocking.
" When the number of idle trunks drops below the Level 1 threshold but still
exceeds the Level 2 threshold, Level 1 blocking is applied. At Level 1, a
user-specified percentage x% of all traffic for HTR codes is blocked and
routed to treatment, while no blocking is applied to non-HTR traffic.
" When the number of idle trunks drops below the Level 2 threshold, Level 2
blocking is applied, as follows:
# 75% of direct route traffic for HTR codes is blocked.
# All Alternate Route traffic for HTR codes is blocked.
# x% of of direct route traffic for non-HTR codes is blocked.
# All Alternate Route traffic for non-HTR codes is blocked.
This is summarised in the table below.
Assume, for example, that the Level 1 threshold is set to 50 idle trunks,the
Level 2 theshold is set to 10 idle trunks, and the user-specified blocking
percentage is set to 40%. This means that when there are fewer than 50 idle
trunks in the group, 40% of all HTR calls to that group are blocked. When
there are fewer than 10 idle trunks in the group, 75% of direct route HTR calls
are blocked, all alternate route HTR calls are blocked, 40% of other direct
route calls are blocked, and all other alternate route calls are blocked.
Playing Tones
Tones are defined in device control protocols as signals. The H.248 and ASPEN 2.1
protocols organise tone signals into a number of packages, each comprising a number of
tones with related functions. The other device control protocols supported by CS2000, i.e.
NCS and MGCP, also organise tone signals into packages, but their packages can also
contain signals other than tones. In either case, a given tone is uniquely identified by the
combination of its Package ID and Tone ID (PID/TID).
CS2000 identifies tones by means of internal toneIDs that are recognised both by the Core
and by GWCs. CS2000 Core datafill maps these internal toneIDs on to CLLIs defined in
table TONES, while GWC software maps them on to the standard PID/TID tone
identifiers defined in the device control protocol (H.248, ASPEN 2.1, NCS or MGCP).
The need to play a tone can be determined either by the Core (in which case a proprietary
message specifying the required internal tone ID is sent by the Core to the GWC) or
autonomously by a GWC.
The PID/TID tone identifiers specified by GWCs in device control messages are purely
functional. They provide no information about the characteristics (frequency, level and
cadence) of the tones they identify. CS2000 does not need to know about market-specific
variations in tone characteristics; it merely requests the playing of a particular functional
tone and relies on the gateway to ensure that the tones characteristics are correct when it
is played, in accordance with the country and network in which the gateway is deployed.
A given CS2000 can therefore support gateways in a number of different countries.
Gateways apply tones in-band to TDM-side trunks or to lines. They do not provide tones
over the packet network.
For details, see Chapter G2: CS2000 Support for Tones.
Playing Announcements
Announcements are identified by a combination of a CLLI and an announcement number.
CS2000 datafill maps each announcement number on to an ordered list of the phrases that
make up the announcement, each phrase being identified by means of an external phrase
identifier. When CS2000 call processing determines that a particular announcement needs
to be played to a call party, it refers to this announcement datafill to find out the sequence
of specific phrases that must be assembled. CS2000 datafill provides 1:1 mapping
between the external phrase identifiers recorded in CS2000 announcement datafill and the
numeric audio identifiers used by the UAS to identify announcement phrases. This
enables the UAS to retrieve and play the correct announcement in response to a CS2000
request.
The UAS provides packetised announcements through the packet network to a specified
trunk or line endpoint on a media gateway. UAS announcements do not terminate in the
packet network.
Note: The UAS cannot generate tones, but it can be used to support tones if the required
tone samples are recorded as an announcement and set up as an announcement via datafill.
For details, see Chapter G3: CS2000 Support for Announcements.
In addition, the gateway will not apply comfort noise or use a codec for such a call.
Note: As an alternative to emulating data circuits over the packet network, TDM
hairpinning could in theory be used for CCD calls, to re-route them within the TDM
domain. A hair-pinned connection is one that enters a gateway from the TDM side and is
routed out again immediately over another TDM-side connection. This requires the
gateway to have a TDM bus. As the PP7480 and PP15000 PVGs have ATM buses, not
TDM buses, they do not support hair-pinned connections for CCD calls.
This chapter discusses the three types of signalling involved in setting up calls across the
packet network:
! Signalling between Gateway Controllers (GWCs) and media gateways:
" Device/media control signalling that allows the GWC to control the
characteristics of the packet network bearer connections on the media
gateway used for a call.
" Backhauled call control signalling (setup and clearing messages) for
non-CCS7 message-based interfaces such as PRI, QSIG and V5.2, for which
TDM-side signalling is terminated at the gateway.
" Combined media control and call control signalling for analogue lines.
! Network signalling between peer Communication Servers.
! Session description signalling, which is used to complement both GWC-gateway
signalling and inter-CS signalling by specifying bearer capabilities.
Note: This signalling is conveyed over IP even if an ATM backbone network is in use.
Specifically, IP / AAL5 / ATM is used over any ATM part of the packet backbone.
The chapter is organised into three sections:
! Section D1.1 on page 233 provides an illustrated view of the packet network
protocol stacks supported by CS2000 in ISN07.
! Section D1.2 on page 234 discusses transport protocols (UDP, TCP, SCTP, RUDP).
! Section D1.3 on page 239 describes SDP session descriptions.
Each of the top-level protocols introduced in this chapter is described in more detail in
one of the other Part D chapters, as follows:
! Chapter D2: SIP and SIP-T
! Chapter D3: H.248
! Chapter D4: ASPEN
! Chapter D5: H.323
! Chapter D6: UniStim
! Chapter D7: NCS
! Chapter D8: MGCP
! Chapter D9: MPCP
! Chapter D10: IUA
! Chapter D11: V5UA
! Chapter D12: MTP Adaptation Protocols (M3UA and M2PA)
! Chapter D13: DSM-CC
! Chapter D14: OAM&P Protocols
Overview
Chapter D1
D1.1
DMC for DMC for DMC+CC DMC+CC DMC+CC DMC+CC DMC+CC DMC+CC Back- Back- Encap- Peer-to- CCS7 Peer-to-
PVGs PVG for units for for cable for LAN for RTP for RAS hauled hauled sulated peer across peer
trunk controlled CentrexIP CPE CPE Media via CC for CC for CCS7 signalling CS LAN NCAS
DMC+CC gateways via H.323, remote gateways gateways Portal CVX1800 PRI, V5.2 between between between
for telco (super- e.g. clients (MTAs) QSIG off PVG CS2000s CS2000 CS2000s
gateways seded IP PBXs, off PVG and
Figure 61: Protocol stacks for packet network signalling
Part D
UDP RUDP TCP (SS) TCP (SS)
UDP UDP (RAS) / UDP UDP UDP UDP SCTP SCTP / UDP / UDP SCTP SCTP
TCP (VRDN) (VRDN)
UDP
(CC)
DSM-CCDigital Storage Media Command and Control NCS Network-based Call Signalling
H.248 Joint ITU-T and IETF protocol for MGC - MG signalling RAS H.323 Registration, Admission and Status
H.323 ITU-T multi-protocol architecture for multimedia services RAS Remote Access Service
(comprises H.225 RAS and CC conveying H.450 and H.245 data) RUDP Reliable UDP (defined as appendix to UniStim)
IP Internet Protocol SCTP Stream Control Transmission Protocol (reliable transport)
17 August 2004
IUA ISDN User Adaptation SDP Session Description Protocol (for codec negotiation)
M2PA MTP2-User Peer-to-Peer Adaptation (for conveying MTP MSUs) SIP-T Session Initiation Protocol for Telephony
M3UA MTP Layer 3 User Adaptation (for conveying CCS7 messages) TCP Transaction Control Protocol (reliable transport)
MGCP IETF-defined Media Gateway Control Protocol UDP User Datagram Protocol (best-effort transport)
MIME Multi-purpose Internet Mail Extensions (encapsulation mechanism) UniStim Protocol for controlling CentrexIP remote clients
MPCP Media Proxy Control Protocol (for controlling RTP Media Portal) V5UA V5.2 User Adaptation
CS2000 International Product Description Part D Chapter D1
Communication Server Capabilities Packet Telephony Protocols Overview
D1.2.3.1 Purpose
SCTP is an IETF protocol defined in RFC2960. The CS2000 implementation is compliant
with draft version 5. In ISN07, CS2000 supports the use of SCTP for two main purposes:
! To provide reliable ordered transport for backhauled call control signalling via the
following protocol stacks (see :
" Q.931 or QSIG / IUA / SCTP / IP, as used for ISDN Layer 3 D-channel
backhaul.
" V5-PSTN / V5UA / SCTP / IP, as used for V5.2 Layer 3 signalling backhaul.
! To provide reliable ordered transport for CCS7 signalling via the following protocol
stacks:
" CCS7 / M3UA / SCTP / IP, as used for intra-CS2000 signalling over the CS
LAN.
" TCAP / SCCP / MTP3 / M2PA / SCTP / IP protocol stack, as used for NCAS
(Non Call Associated Signalling) between peer CS2000s.
SCTP is a reliable transport protocol designed by the IETF SIGTRAN workgroup as an
alternative to TCP and UDP for handling delay-sensitive payloads such as call control
signalling. It is an assured transfer type that will not allow call setup to succeed unless all
messages have been received in the correct order. Using SCTP as a transport protocol
instead of UDP means that no application-level reliability mechanisms are required or
supported by the top-level protocols in these protocol stacks.
SCTP offers the following services to its users:
! Acknowledged, error-free, non-duplicated transfer of user data.
! Data fragmentation to conform to the MTU (Maximum Transmission Unit) size
discovered for the transport path.
! Sequenced delivery of user messages within multiple streams, with an option for
order-of-arrival delivery of individual user messages.
! Optional bundling of multiple user messages into a single SCTP packet.
! Network-level fault tolerance via support of multi-homing at either or both ends of
an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance
to flooding and masquerade attacks. SCTP also allows the failure of MGCs (CS2000s)
within the packet network to be detected so that appropriate recovery action can be taken.
CS2000
Trunk V5.2
GWC GWC
Media Media
Gateway Gateway
For both types of gateway,
B-channels are mapped on
to packet network bearer
30B+D V5.2 AN commections; signalling is
PRI or QSIG interface backhauled to the CS2000
access (<16 E1s)
Figure 61: Use of SCTP to provide reliable transport for backhauled call controlsignalling
CS2000
TCAP
ISUP TUP
SCCP TCAP
CS2000 M3UA USP SCCP IP control
Core SCTP MTP3 network over
backbone
IP M2PA
Other CS2000s,
packet network
peer MGCs
SCTP
IP
CS LAN
Figure 62: Use of SCTP to provide reliable transport for CCS7 signalling
CS2000 CS2000
DPT GWCs DPT GWCs
Trunk
or line and Session and Session
Gateway Server; Server;
Controller Egress Ingress
(GWC)
packet-side packet-side
A B
Scenario B:- SDP used to
Scenario A:- SDP used to complement inter-CS signalling
complement access signalling UDP transport conveys one or two
SDP session description types of signalling, separately
commands in-line with H.248, encapsulated in SIP messages
ASPEN, NCS or MGCP using the MIME mechanism:
commands conveyed over UDP/IP SDP session descriptions
Optional CCS7 messages
(ISUP or TUP)
Media SIP signalling terminates on
Gateway Session Server; CCS7 signalling
terminates on DPT GWC.
Figure 63: Use of SDP to complement access signalling and/or inter-CS signalling
O (Originator)
Identifies the originator of the session (username and users host address).
o=username session-id version network-type address-type address
where
username is the user's login at the originating host
address is the address of the host creating the session, and is of the type
specified by address-type
network-type is IN (meaning Internet)
C (Connection)
Identifies the address to which data is to be sent.
c=network-type address-type connection-address
where
network-type is IN (meaning Internet)
connection-address is the target address, and is of the type
specified by address-type
M (Medium)
Indicates the media format supported by the sender.
m=media port transport format-list
where
media is the media type (e.g. audio, video)
port is the port to which packets should be sent.
transport is transport protocol (e.g. UDP, RTP, H.320)
format-list gives the media format (e.g. A-law PCM, MPEG-2 video)
DPT DPT
provisioning provisioning
Inter-CS
DPT connection DPT
GWC VRDN GWC
Access Access
GWC DPT A GWC DPT GWC
GWC GWC
No VRDN
DPT for call DPT
GWC origination B GWC
Figure 64: DPT GWC interaction with other units to support peer-to-peer SIP signalling
MIME information
Application = (e.g.) ETSI ISUP V1
SDP Information about packet
network bearer capabilities
(for codec negoitation
MIME information between endpoints)
Application = SDP
SIP header SIP message type indicates its
(msg type, source, dest, call ID, etc) function, and can be mapped on
to an IBN7 ISUP equivaloent
TCP (Transaction Control Protocol) (for SIP with no encapsulated
or UDP (User Datagram Protocol) CCS7)
! SIP uses the MIME (Multipurpose Internet Mail Extensions) protocol defined in
RFC2046 to identify other protocols conveyed in SIP messages. CS2000 supports
the following combinations of media type and sub-type:
" application/sdp
" application/isup
" application/tup
" multipart/mixed
The tup media sub-type is a Nortel extension for the transport of IUP/BTUP and
SSUTR2/FTUP payloads.
The multipart/mixed payload type allows both SDP and CCS7 information to be
separately encapsulated in a single SIP-T message. In this case, the application/sdp
and application/isup payload information is delimited by STANDARD BOUNDARY
lines within the command body, as shown in the INVITE message example in
section D2.4 on page 248.
For user part payloads encapsulated in SIP-T, three parameters can be used to
specify protocol variant information:
" Version, e.g. etsi121 (V1), etsi356 (V2), ansi88, gb_iup, fr_ssutr2.
" Specification, e.g. ETSI ISUP national variant such as es_etsi121 (Spanish
V1) or de_etsi356 (German V2).
" Compatibility, i.e. yes/no to indicate support for ETSI ISUP V2 compatibility
mechanism.
The MIME type specifies which CCS7 protocol is being used, but a mechanism
outside the CCS7 protocol is required to convey the sort of additional information
associated with trunk groups in the existing TDM telephony network, e.g. customer
group. This information is provided by the proprietary X-Nortel-Profile header in
the SIP INVITE message. This header contains a text string (maximum 32 bytes)
that represents a set of trunk characteristics (i.e. maps to a trunk group). If this
header does not appear in the message, a default trunk group will be chosen, based
on the CCS7 protocol being used and the source CS2000.
! SIP messages are conveyed using either TCP (Transaction Control Protocol) or
UDP (User Datagram Protocol) over IP. TCP is used by the recommended Session
Server implementation, while UDP is used by the VRDN / DPT GWC
implementation. Message structure is illustrated in Figure 65.
--unique-boundary-1
c: application/SDP ;charset=ISO-10646
v=0
o=MGCP 0 0 IN IP4 47.174.73.241
s=MGCP Call
c=IN IP4 47.174.73.241
t=0 0
m=audio 5004 RTP/AVP 0 96
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:20
--unique-boundary-1
c: application/ISUP ;version=gr394 ;base=gr394
INVITE Responses
A series of response messages is normally received in response to an INVITE message.
These indicate the progress of call setup, and may also provide SDP address and media
stream information. The message format is:
<response-code> <progress-indication>
where
response-code is a three-digit numeric identifier beginning with 1 or 2. 2xx
codes indicate successful completion of a request; 1xx codes are used
to convey information.
progress-indication is a one-word indication of the progress of call setup
ACK
An ACK message is sent by the originating CS2000 to confirm that it has received the
final response to an INVITE message (typically a 200 OK message). If the definitive SDP
session description to be used by all parties differs from the one provided in the original
INVITE message, the modified session description is provided in the body of the ACK
message.
BYE
The BYE message is sent on behalf of a call party to indicate that the party wishes to
release the call. When CS2000 receives a BYE message, it terminates the transmission of
all media streams specifically directed at the party issuing the BYE request, and indicates
that it has done so by sending back a 200 OK response to the BYE.
INFO
The INFO message allows call progress and session description information to be
conveyed between call parties during an active call. It is a general-purpose mechanism for
conveying PSTN and SDP protocol information.
INFO is required in order to carry mid-call PSTN signalling from the originating PSTN
network through the SIP network to the destination PSTN network, e.g. ISUP messages
like INR, INF and PAM.
INFO messages are also used to convey encapsulated SAM messages if overlap signalling
is in use. An INFO message used for this purpose conveys the same CallID as the initial
INVITE message, but its CSeq number is incremented by 1 from the most recent setup
message for the call (the initial INVITE or a previous INFO ).
! X-Nortel-Profile:ETSIV2GROUP1
A text string that represents a set of trunk characteristics (i.e. maps to a trunk group),
allowing an INVITE message to convey the sort of information associated with
trunk groups in the existing TDM telephony network, e.g. customer group. If no
X-Nortel-Profile header appears in an INVITE message, a default trunk group will
be chosen, based on the CCS7 protocol being used and the source CS2000.
! CallID
Together with the To and From headers, the CallID header uniquely identifies a
particular invitation (call setup attempt). On CS2000, it is used by the VRDN that
receives a SIP-T message to route the message to the right SIP-T GWC. The header
value is a character array up to 64 bytes in length, with three segments:
" A string uniquely identifying the hardware unit that generated the call.
" A timestamp consisting of five two-digit fields separated by colons. The fields
are: day:hour:minute:second:ABS(milli-second/10).
" The local host name, preceded by a @.
An example of a Call-ID header value appears below:
0057.4002-17:11:59:59.99@dcs.nortelnetworks.com
! CSeq
Clients add the CSeq (command sequence) field to every request. A CSeq field in a
request indicates the request method (SIP-T message type) and provides a decimal
sequence number that uniquely identifies the request within the context of a given
CallID. The sequence numbers of consecutive requests with the same CallID must
be contiguous. An ACK or CANCEL request must contain the same CSeq value as
the corresponding INVITE request; a BYE request cancelling an invitation must
have a sequence number greater then that of the INVITE (or the last INFO). Format:
CSeq: 1 INVITE
! To
Specifies the intended recipient of the request, i.e. the identity of the destination
CS2000 and user in SIP URL format.
! From
Indicates the originator of the request, i.e. the identity of the originating CS2000 and
user in SIP URL format.
! Content type
The Content-Type entity-header field indicates the media type of the message-body
sent to the recipient. e.g.
Content-Type: application/sdp
Content-Type: text/html; charset=ISO-8859-4
D2.6.2 Audits
CS2000 uses two mechanisms to maintain the integrity of connections with other MGCs
and calls established over those connections:
! Connection audits
This is the mechanism used to verify the continuing availability of a remote MGC.
CS2000 uses heartbeat messaging based on sending a SIP-T OPTIONS message
every 20 seconds. If the (lack of) response indicates that the connection is down,
CS2000 initiates a call audit (see below).
! Call audits
CS2000 runs a call audit every 10 minutes to determine the status of calls to/from
other CS2000s. This involves sending a SIP-T INFO message, and releasing a call
if the message response indicates that it is no longer live. Such calls are not billed.
When a SIP-T GWC (or a VRDN if SCTP is in use) receives such a SIP-T INFO
message, it compares the call ID in the INFO message with its own call ID table. If
the call ID exists in the call ID table, the GWC returns a 200 OK message; if not,
the GWC sends back a 481 message response.
Note: If a SWACT takes place at a remote SIP-T GWC, the connection is maintained but
calls may be lost. This will be detected at the next call audit.
D3.1 Purpose
H.248 is a joint ITU-T / IETF protocol designed to support signalling between Media
Gateway Controllers and Media Gateways. It is defined in ITU-T Recommendation
H.248 "Gateway Control Protocol" and IETF Megaco RFC3015 "Gateway Control
Protocol". In a CS2000 context, H.248 is currently used for device/media control
signalling between CS2000 GWCs and the following types of unit:
! PVG configured as a trunk media gateway supporting CCS7 or PRI access to the
packet network, as described in section B2.3: PVG (Packet Voice Gateway)
Trunk Gateways on page 99.
Note: H.248 has superseded the use of the proprietary ASPEN protocol (see
Chapter D4: ASPEN) as the standard CS2000 protocol for control of trunk
gateways supporting CCS7 and PRI access to the packet network. Use of ASPEN
for this purpose is still supported for existing deployments. In addition, ASPEN is
currently the only protocol that has been verified for control of trunk gateways
supporting QSIG access. H.248 is based on a more flexible functional model than
ASPEN (see section D3.3 on page 260), which is designed to provide better support
for multimedia and conference capabilities.
! Mediant 2000 CPE trunk media gateway, as described in section B2.6: Mediant
2000 Trunk Gateway on page 116.
! PVG configured as a V5.2 gateway supporting V5.2 interfaces connected to V5.2
Access Networks (ANs) serving V5.2 PSTN lines, i.e. analogue subscriber lines, as
described in section B2.4: PVG as a V5.2 Gateway on page 111.
! High-capacity line media gateways located on operating company premises, as
described in section B2.8: Carrier-Located Line Media Gateways on page 119.
! An MS2000 or UAS media server used to provide:
" Packet-based announcement capabilities
" Packet-based conferencing (multi-party calls)
" BCT (Bearer Channel Tandem) functionality for LI (Lawful Intercept)
monitoring of packet network bearer connections
See Chapter B3: CS2000 Support for Media Servers for further information.
Note: To complement H.248, SDP session descriptions are conveyed in-line with H.248
commands and responses. See section D1.3 on page 239 for more information about SDP.
CS2000 CS2000
Access Access
Gateway DPT GWC DPT GWC Gateway
Controller and Session and Session Controller
(GWC) Server; Server; (GWC)
TDM-side packet-side packet-side TDM-side
CCS7 PRI
Bearer connection
trunk trunk
gateway gateway
PSTN or other
TDM network PRI PBXs
CS2000 CS2000
Access Access
Gateway DPT GWC DPT GWC Gateway
Controller and Session and Session Controller
(GWC) Server; Server; (GWC)
TDM-side packet-side packet-side TDM-side
V5.2 interface
consisting of
1-16 E1 carriers
Analogue
V5.2 Access subscriber lines
Network (AN) and ADSL lines
CS2000
Audio
GWCs Controller
GWC
H.248 commands,
e.g. Add,
controlling
terminations and
contexts (calls)
Responses
Media gateways
supporting: Media
server
Trunks (MS2000
Lines or UAS)
Resource usage is as follows for each type of service functionality supported by the media
server:
! Announcements
An audio termination for announcement provision, plus an ephemeral termination
for the call party to whom an announcement is to be played.
! Conferencing
A set of conference terminations, plus an ephemeral termination for each call party
who is to participate in the conference (matching the number of conference
terminations).
! LI
A set of conference terminations, plus an ephemeral termination for each party
participating in the monitored call, plus ephemeral LEA terminations (overall total
of ephemeral terminations matching the number of conference terminations).
An audio termination (or conference port) exists only in the abstract before it is added to
a context. It is the responsibility of the media server to assign a specific physical resource
from the pool of available resources, i.e. a logical port on a DSP card, to each audio
termination when it is added to a context. There is no permanent mapping between audio
terminations and resources, i.e. a given audio termination can be assigned a different
physical resource each time it is instantiated.
The requesting of physical resources by the GWC and their assignment by the media
server must be completed before the GWC can ask for the corresponding ephemeral
terminations to be added to a context.
The following table lists the most important Descriptors and their use.
LocalControl Characteristics
of the control connection between the media gateway
and the MGC.
Specifies the direction(s) of media flow to be supported between
Topology terminations in a context.
Specifies signals to be applied to a termination. Signals can be
gateway-generated media streams such as tones and
announcements as well as line signals such as hook-flash. More
complex signals may include a sequence of simple signals
interspersed with and conditioned upon the receipt and analysis of
received data and signals.
Note: CS2000 also uses H.248 to convey H.248 equivalents of Media
Signals
Control Message Protocol (MCMP) data to the media server. MCMP
allows a language token and currency token to be provided to the
media server for use in assembling and playing a complex/variable
announcement. Initial aim is to allow INAP Price data specified via
PlayAnnouncement to be reformatted as MCMP Money data and sent
to media server. See A19012479 for details. Conversion of MCMP
messages to H.248 is performed by TAPI layer software in the GWC.
Specifies events to be monitored at a given termination, i.e. events
whose occurrence must be reported to the MGC. Can also be used to
specify the action the media gateway should take when it detects a
Events
monitored event.
Each Events descriptor has a RequestID that is used to correlate a
monitoring request with the notifications that it may trigger.
Packages can be used to simplify the assignment of property values. Each package
provides a complete set of default property values that can be assigned to a termination
when it is created. Thereafter, only non-default property values need to be explicitly
specified by using descriptors as parameters to H.248 termination commands.
Note: For simplicity, the diagram does not show messaging for PSTN feature support,
H.248 Ack messages or H.248 timers. Numbered references like (1) refer to example
H.248 message formats in Table 24 on page 268.
MG GWC
1st
digit Dial tone
removed
H.248 Notify endpoint (2)
Digits Match against digit map
matching Onward
digit map call
H.248 Notify endpoint setup
Additional digit
(3) begins
More
digits
H.248 Add endpoint to context
Implicitly creates new context
Call in progress
Table 24: Example H.248 message formats for basic call setup
No. Description / format
(1) Apply dial tone, request digit collection via DigitMap, embedded is the request to continue
with single digit collection after DigitMap completion
Request (GWC to MG) Response (MG to GWC)
MEGACO/1 [47.174.66.80]:2944 MEGACO/1 [47.166.34.20]:2944
Transaction=62{ Reply=62{
Context=1002{ Context=1002{
Modify=E1/1/20/5{ Modify=E1/1/20/5
Events = 2223 { } }
dd/ce {DigitMap=Dialplan0 ,
Embed { Events = 2224
{dd/0,dd/1,dd/2,dd/3,
dd/4,dd/5,dd/6,dd/7,dd/8,dd/9} } } },
Signals {cg/dt},
DigitMap= Dialplan0 {
(0|00|[1-7]xxx|8xxxxxx
x|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.)
} } } }
(2) Notify DigitMap completion event
Request (MG to GWC) Response (GWC to MG)
MEGACO/1 [47.166.34.20]:2944 MEGACO/1 [47.174.66.80]:2944
Transaction=22{ Reply=22{
Context=1002{ Context=1002{
Notify=E1/1/20/5{ Notify=E1/1/20/5
ObservedEvents =2223 { } }
19990729T22010001:dd/ce{ds="91613555121
2",Meth=FM }
} } } }
(3) Notify single DTMF event (e.g. DTMF digit 1)
Request (MG to GWC) Response (GWC to MG)
MEGACO/1 [47.166.34.20]:2944 MEGACO/1 [47.174.66.80]:2944
Transaction=23{ Reply=23{
Context=1002{ Context=1002{
Notify=E1/1/20/5{ Notify=E1/1/20/5
ObservedEvents =2224 { } }
19990729T22010003:dd/d1 }
} } }
(4) Apply ringback tone and stop digit collection
Request (GWC to MG) Response (MG to GWC)
MEGACO/1 [47.174.66.80]:2944 MEGACO/1 [47.166.34.20]:2944
Transaction=65{ Reply=65{
Context=1002{ Context=1002{
Modify=E1/1/20/5{ Modify=E1/1/20/5
Signals {cg/rt}, } }
Events
} } }
(5) Stop ringback tone
Request (GWC to MG) Response (MG to GWC)
MEGACO/1 [47.174.66.80]:2944 MEGACO/1 [47.166.34.20]:2944
Transaction=66{ Reply=66{
Context=1002{ Context=1002{
Modify=E1/1/20/5{ Modify=E1/1/20/5
Signals { } } }
} }
Table 27: Example H.248 message formats for Lawful Interception (LI)
No. Description / format
(1) GWC tells media server to reserve a context for an LI call.
media server replies that the context has been reserved.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3000{ Reply = 3000 {
Context=${ Context = 1 {
ContextAttr{ ContextAttr {
ctxr/type=bct, ctxr/type = bct,
ctxr/size=4, ctxr/size = 4,
ctxr/res=reserve ctxr/res = reserve
}}} }
}
}
(2) GWC tells media server to add an ephemeral connection for the LI subject and proposes local SDP.
media server replies that an ephemeral connection has been added for the LI subject.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3001{ Reply = 3001 {
Context=1{ Context = 1 {
TP{$,*,IS}, Add = te/tepool0/0 {
Add=${ Media {
Media{O{MO=SR}, Local {
L{ v=0
v=0 c=IN IP4 47.171.164.211
c=IN IP4 $ m=audio 30000 RTP/AVP 0
m=audio $ RTP/AVP 0 a=ptime:20
a=ptime:10 m=image 32001 udptl t38
}}}}} a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
}
}
}
}
}
(3) GWC asks media server to add an ephemeral connection for the LI associate, proposes local SDP, and
supplies LI subjects SDP.
media server replies that an ephemeral connection has been added for the associate.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3002{ Reply = 3002 {
Context=1{ Context = 1 {
TP{$,*,IS}, Add = te/tepool0/1 {
Add=${ Media {
Media{O{MO=SR}, Local {
L{v=0 v=0
c=IN IP4 $ c=IN IP4 47.171.164.211
m=audio $ RTP/AVP 0 m=audio 30002 RTP/AVP 0
a=ptime:10 a=ptime:10
}, }
R{v=0 }
c=IN IP4 47.171.164.190 }
m=audio 20002 RTP/AVP 0 }
a=ptime:10 }
}}}}}
Table 27: Example H.248 message formats for Lawful Interception (LI)
No. Description / format
(4) GWC tells the media server to modify theSDP of the LI subjects termination with the associates SDP.
media server replies that the modification has been successful.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3003{ Reply = 3003 {
Context=1{ Context = 1 {
Modify=te/tepool0/0{ Modify = te/tepool0/0
Media{O{MO=SR}, }
R{ }
v=0
c=IN IP4 47.171.164.190
m=audio 20000 RTP/AVP 0
a=ptime:10
}}}}}
(5) GWC asks the media server to change the topology between the subject's ephemeral connection and
the associate's ephemeral connection to both-way, establishing the speech path.
The media server replies that the topology has been modified.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3004{ Reply = 3004 {
Context=1{ Context = 1 {
TP{ Topology {
te/tepool0/0, te/tepool0/0,
te/tepool0/1, te/tepool0/1,
BW Bothway
}}} }
}
}
(6) GWC tells media server to add first LEA ephemeral connection LEA-1 to the context.
media server replies that the ephemeral connection has been added.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3005{ Reply = 3005 {
Context=1{TP{$,*,IS}, Context = 1 {
Add=${ Add = te/tepool0/2 {
Media{O{MO=SR}, Media {
L{ Local {
v=0 v=0
c=IN IP4 $ c=IN IP4 47.171.164.211
m=audio $ RTP/AVP 0 m=audio 30004 RTP/AVP 0
a=ptime:10 a=ptime:20
}}}}} m=image 32003 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
}
}
}
}
}
(7) GWC tells media server to add second LEA ephemeral connection LEA-2 to the context.
Request as for LEA-1, but with Transaction=3006.
media server replies that the ephemeral connection has been added.
Acknowledgement as for LEA-2, but with
Reply = 3006
Add = te/tepool0/3
m=audio 30006 and m=image 32004
Table 27: Example H.248 message formats for Lawful Interception (LI)
No. Description / format
(8) GWC modifies ephemeral connection LEA-1 with the remote SDP from the LEA.
The media server replies that the Modify was successful.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3007{ Reply = 3007 {
Context=1{ Context = 1 {
Modify=te/tepool0/2{ Modify = te/tepool0/2
Media{O{MO=SR}, }
R{ }
v=0
c=IN IP4 47.171.164.190
m=audio 20004 RTP/AVP 0
a=ptime:10
}}}}}
(9) GWC tells the media server to set the topology of the associate and LEA-1 to oneway, thereby
establishing the monitoring of the associate.
media server replies that the topology has been modified.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3008{ Reply = 3008 {
Context=1{ Context = 1 {
TP{ Topology {
te/tepool0/1, te/tepool0/1,
te/tepool0/2, te/tepool0/2,
OW Oneway
}}} }
}
}
(10) GWC modifies ephemeral connection LEA-2 with the remote SDP from the LEA.
The media server replies that the Modify was successful.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3009{ Reply = 3009 {
Context=1{ Context = 1 {
Modify=te/tepool0/3{ Modify = te/tepool0/3
Media{O{MO=SR}, }
R{ }
v=0
c=IN IP4 47.171.164.190
m=audio 20006 RTP/AVP 0
a=ptime:10
}}}}}
(11) GWC tells the media server to set the topology of the subject and LEA-2 to oneway, thereby establishing
the monitoring of the subject.
media server replies that the topology has been modified.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3010{ Reply = 3010 {
Context=1{ Context = 1 {
TP{ Topology {
te/tepool0/0, te/tepool0/0,
te/tepool0/3, te/tepool0/3,
OW Oneway
}}} }
}
}
Table 27: Example H.248 message formats for Lawful Interception (LI)
No. Description / format
(12) When monitoring is over, GWC tells the media server to subtract each ephemeral connection in turn,
to beginning with subjects ephemeral connection (as shown in example).
(15) In each case, the media server replies that the Subtract was successful.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3011{ Reply = 3011 {
Context=1{ Context = 1 {
Subtract=te/tepool0/0{ Subtract = te/tepool0/0
AT{} }
}}} }
(16) GWC tells the media server to release the context.
The media server replies that the context has been released.
Request (GWC to media server) Response (media server to GWC)
MEGACO/1 [192.136.141.118]:2427 MEGACO/1 [47.171.164.21]:2945
Transaction=3015{ Reply = 3015 {
Context=1{ Context = 1 {
CT{ ContextAttr {
ctxr/res=release ctxr/res = release
}}} }
}
}
Table 28: H.248 message formats for CLASS on-hook data transmission
Description / format
Send calling line information without DT-AS generation and with signal completion notification
Request (GWC to MG) Response (MG to GWC)
MEGACO/1 [47.174.66.80]:2944 MEGACO/1 [47.166.34.20]:2944
Transaction=62{ Reply=62{
Context=1002{ Context=1002{
Modify=E1/1/20/5{ Modify=E1/1/20/5
Signals {andisp/data } }
{db=802001083035313831363135020A3931393535
353030303007084A6F686E20446F65D8, [1]
tas=nt,
NotifyCompletion={TimeOut}}
},
Events=1234{g/sc}
} } }
Signal completion notification
Request (MG to GWC) Response (GWC to MG)
MEGACO/1 [47.166.34.20]:2944 MEGACO/1 [47.174.66.80]:2944
Transaction=24{ Reply=24{
Context=1002{ Context=1002{
Notify=E1/1/20/5{ Notify=E1/1/20/5
ObservedEvents=1234{ } }
20020318T10010000:g/sc
{SigID=andisp/data,Meth=TO}
} } } }
[1] The db parameter shall be coded as a hex string. The maximum length is 80 octets, comprising:
- Message type (= Call Setup)
- Message length
- Presentation Layer Message (Date&Time, Calling Line Identity, ..)
- Checksum
The tas parameter shall be set to nt (i.e. no Dual Tone Alerting Signal shall be sent).
D4.1 Purpose
ASPEN is a Nortel-defined ASCII protocol based on the MGCP (Media Gateway Control
Protocol) IETF protocol defined in RFC3435 and described in Chapter D8: MGCP, and
also on SGCP. Like MGCP, ASPEN is designed to support signalling between GWCs
and the media gateways they control. It is a superset of MGCP, supporting essentially the
same range of connection control commands as MGCP, but also a number of additional
proprietary commands defined to provide extra maintenance functionality.
In releases prior to ISN07, ASPEN was used in CS2000 solutions primarily for
communication between GWCs and PVG trunk media gateways supporting CCS7 and
PRI access to the packet network. In this role, ASPEN has now been superseded by the
standard H.248 protocol jointly defined by the IETF and ITU, which is described in
Chapter D3: H.248. H.248 is based on a more flexible functional model than ASPEN,
which is designed to provide better support for multimedia and conference capabilities.
Use of ASPEN in support of CCS7 and PRI access is still supported for existing
deployments. In addition, ASPEN is currently the only protocol that has been verified for
control of trunk gateways supporting QSIG access.
The standard ASPEN version for ISN07 is ASPEN v2.1, as defined in the ASPEN
Protocol Specification, Version 2.1: Draft 8, October 2000.
Note: To complement ASPEN, SDP session descriptions are conveyed in-line with
ASPEN commands and responses. See section D1.3 on page 239 for more information.
CS2000 CS2000
Trunk SIP-T and SIP-T and Trunk
Gateway VRDN VRDN Gateway
Controller GWCs; GWCs; Controller
(GWC) (GWC)
Ingress Egress Ingress Egress
TDM-side packet-side packet-side TDM-side
Media Media
gateway gateway
(PVG) (PVG)
Note: For a media gateway supporting Q.931/QSIG access, ASPEN is not the only
packet telephony protocol used between the GWC and the media gateway. ASPEN
provides device / media control functionality, but PRI/QSIG call control signalling is
conveyed using IUA, as described in Chapter D10: IUA.
D4.4 Parameters
ASPEN command parameters are specified one per line, each line beginning with a
single-character parameter identifier. The most important parameters supported are listed
and briefly described below.
C Call identifier
Uniquely identifies a call (or session) within a network of media gateways.
Assigned by GWC in CRCX command used to initiate call setup.
I Connection identifier
Identifies a connection within the context of an endpoint and a call (call identifier
must be provided if connection identifier is provided). Assigned by media gateway
when connection is created in response to CRCX command, and notified to GWC
in 200 response to CRCX.
Z Endpoint identifier
Identifies an endpoint by means of an address based on the gateway / carrier /
channel hierarchy. For E1 carriers, the format is:
<media gateway name>.E1_<card slot><card port>.<timeslot>
An example is PVG99.E1_403.27, which would identify timeslot 27 on the E1
carrier terminated in slot 4, port 3 on gateway PVG99 (the port number is padded
with a 0 but the card number is not).
M Connection mode
Specifies the mode of operation of a connection. Specified by GWC in initial CRCX
command and subsequent MDCX commands. Possible values:
sendonly Media gateway should only send packets
recvonly Media gateway should only receive packets
sendrecv Media gateway can send and receive packets
inactive Media gateway should neither send nor receive packets
loopback Media gateway should place the circuit in loop-back mode
data Media gateway should use circuit for network access for data
tdmdata Media gateway should use circuit for TDM data (special value for
providing hairpinned clear channel between two TDM-side
endpoints served by same media gateway)
L Local connection options
Specifies the required characteristics of a packet network bearer connection.
Specified by GWC in initial CRCX command (can subsequently be modified by
MDCX commands). Characteristics that can be specified:
p packetisation interval (5ms, 10ms or 20ms)
a compression algorithm, e.g. G.711a (A-law) or x-ccd (clear channel data)
b bandwidth in kb/s
e echo cancellation on/off (off for data calls)
s silence suppression on/off (off for data calls)
P Connection parameters
Included in a DLCX acknowledgement or a DRCX command to provide
information about the concluded call, e.g. packets/octets sent, packets/octets
received, packets lost/discarded.
E Reason code
Included in DRCX command to indicate the cause of a gateway-initiated
disconnection.
R Requested events
Included in RQNT command to specify which event(s) the media gateway should
tell the GWC about.
O Observed events
Included in NTFY command to indicate which monitored events have occurred.
S Signal requests
Included in RQNT command to specify which signal(s) the media gateway should
tell the GWC about.
X Request identifier
Used for correlation between requested events and resulting event notifications.
D Digit map
Specifies a dialling plan to be used in collecting and reporting DTMF in-band digits
detected at a TDM-side endpoint, primarily to distinguish different types of call.
Included in RQNT command to complement Requested Events parameter. See
section D7.4.3 on page 314 for a discussion of digit map usage; this is for the NCS
protocol, but is equally applicable to ASPEN.
Note: When an ASPEN command such as CRCX, MDCX or 200 (acknowledgment)
includes an SDP session description, the SDP command lines, whose format is similar to
that of ASPEN parameter lines, are provided after the final ASPEN parameter line. See
section D1.3 on page 239 for more information. SDP command lines are not explicitly
distinguished from ASPEN parameter lines.
D4.6 Examples
D4.6.1 Call Setup Commands
! Initial CRCX
CRCX 2 ASPEN 2.1
C: callid1
Z: mg-o.E1_1.1
M: recvonly
L: p: 10, a:G.726, p:20, a:G.729
The LocalConnectionOptions parameter presents a list of codec / packetisation rate
pairs to the media gateway in order of preference.
! 200 Acknowledgement of initial CRCX
200 2
I: C1
v=0
c=IN IP4 47.96.0.1
m=audio 1111 RTP/AVP 2
a=ptime:10
m=audio 1111 RTP/AVP 18
a=ptime:20
The media gateway examines the LocalConnectionOptions list and returns a media
description line for each codec / packetisation rate pair that it can support. Where
multiple packetisation periods can be used, an a=ptime line is included for each
one.
Note: Payload types are based on the definitions provided by the IETF's AVT
(Audio / Video Transport) working group. Payload type 2 denotes G.726 and
payload type 18 denotes G.729.
! Second CRCX (reflecting capabilities supported by first media gateway)
CRCX 4 ASPEN 2.1
C: callid1
Z: mg-t.E1_1.2
M: sendrecv
v=0
c=IN IP4 47.96.0.1
m=audio 1111 RTP/AVP 2
a=ptime:10
m=audio 1111 RTP/AVP 18
a=ptime:20
! 200 acknowledgement of second CRCX
200 4
I: C2
v=0
c=IN IP4 47.96.121.1
m=audio 2222 RTP/AVP 2
a=ptime:10
The second media gateway returns the first listed media description that it can
support (this is what will be used for the call).
! First MDCX (to first media gateway, when CRCX to second media gateway has
been acknowledged, setting up a connection with the agreed media characteristics)
MDCX 5 ASPEN 2.1
C: callid1
I: c1
Z: mg-o.E1_1.1
M: recvonly
v=0
c=IN IP4 47.96.121.1
m=audio 2222 RTP/AVP 2
a=ptime:10
! Second MDCX (to both media gateways, on receipt of ACM or CONNECT, to
establish a full-duplex connection)
MDCX 6 ASPEN 2.1
C: callid1
I: c1
Z: mg-o.E1_1.1
M: sendrecv
MDCX 7 ASPEN 2.1
C: callid1
I: c1
Z: mg-t.E1_1.2
M: sendrecv
D5.1 Purpose
H.323 is an ITU-defined umbrella specification for use in the definition and
implementation of multimedia services supporting the integration of voice, video and data
applications. It should be regarded as a framework or architecture rather then a protocol
in its own right, because it actually comprises a number of different protocols.
The underlying control protocol in the H.323 architecture is H.225, which provides
esentially the same range of call control messages as those defined in Q.931. More
importantly, H.225 allows other types of H.323 signalling to be conveyed in order to
support enhanced capabilities, as follows:
! H.225 defines RAS (Registration, Admission and Status) messages and procedures
for controlling access to the network. These allow H.323 endpoints to discover and
register with a H.323 gatekeeper, to provide information about their capabilities,
and to request the allocation of appropriate amounts of bandwidth.
! H.245 defines messages and procedures to be used in setting up and taking down
logical channels within the context of a H.225 call, e.g. an additional video or data
channel for the exchange of information. It allows endpoints to determine their
master/slave roles, to exchange information about their transmit and receive
capabilities, and to open and close end-to-end logical channels with characteristics
appropriate for the information being exchanged. Like H.450-defined data, H.245
signalling is tunnelled over H.323 in UUI IEs in H.225 call control messages.
! H.450 protocols are used to exchange signalling information for the control of
supplementary services. They provide service-related data definitions in ASN.1
format. H.450.1 defines a general-purpose signalling protocol that provides a
common basis for the definition of H.323 supplementary services. It is derived from
the generic functional protocol specified in ISO/IEC 11582 and used by QSIG, and
includes a mechanism for defining manufacturer-specific protocol extensions that
can be used to support proprietary services. H.450.1-defined data is tunnelled
(conveyed transparently) over H.323 interfaces in User-to-User Information (UUI)
IEs in H.225 call control messages.
Note: H.450.2 to H.450.13, which also belong to the H.323 architecture, provide
data definitions for use in supporting specific standardised supplementary services
such as Call Transfer, but these are not supported by CS2000 in ISN07.
Audio streams are encoded using protocols such as G.711 and G.729. Video streams are
encoded using H.261 and H.263. Audio and video payloads are both conveyed using RTP
over UDP transport, with RTCP being used for status and delivery monitoring. Data is
encoded using T.12x protocols and conveyed using X.224 over TCP transport.
Figure 71 provides a simplified view of the H.323 protocol architecture.
Video Audio
H.450.1 Call payload
Data H.245 Service- control payload
payload Logical protocols protocols
related (based RAS (H.26x)
protocols channel data on (G.7xx)
(T.12x) control definitions Q.931)
RTP RTCP
Media Delivery
packets monitoring
X.224 H.225
Media stream protocols
IP
CS2000 supports H.323 Version 4, which was prepared by ITU-T Study Group 16
(2001-2004) and approved under the WTSA Resolution 1 procedure on 17 November
2000. Compliance with Version 4 of H.323 implies compliance with all of the mandatory
requirements of ITU Recommendation H.323 (2000), which references ITU-T Rec.
H.225.0 (2000) and H.245 (2000 or later). Version 4 products are identified by H.225.0
messages containing a protocolIdentifier = {itu-t (0) recommendation (0) h (8) 2250
version (0) 4} and H.245 messages containing a protocolIdentifier = {itu-t (0)
recommendation (0) h (8) 245 version (0) x}, where "x" is 7 or higher.
Basic H.323 capabilities supported by CS2000 include:
! H.225 RAS (Registration Admission and Status)
! H.225 fast start and slow start
! End-to-end H.245 support via tunnelling
! Gatekeeper-routed signalling
! G.711 a-law/-law (with PLC), G.729a
! Codec negotiation
! In-band DTMF support via RFC 2833
! DTMF out-of-band support (H.245 to in-band)
The software order code for H.323 functionality is CS2B0004.
CS2000 Core
Basic interoperability via
non-FT trunks with units
served by other CS2000s
H.323 proxy H.323 Other
(GWC equivalent) proxy GWCs
Business Communication
Proprietary Meridian 1 Call Server for
units IP PBX Manager Enterprise
(BCM) (CSE1000)
Cisco
access router / Westell
Third-party DPNSS gateway
units gatekeeper
(2600 / 3600 / (InterChange
7200) iQ203x)
CS2000
H.323 H.323
CPE unit CPE unit
Note: H.323 employs a single-stage release mechanism, which consists of the reception
or sending of a RELEASE COMPLETE message without further acknowledgment. The
QSIG interface on the H.323 proxy generates or terminates the additional messages
required for the QSIG multi-stage release mechanism.
Figure 74 illustrates the messaging involved in H.323 call setup and clearing via the
H.323 proxy GWC.
ALERTINGUUI ALERTINGFAC
CONNECTUUI CONNECTFAC
CONNECT ACK
Call in progress
UUI
RELEASE COMPLETE DISCONNECT
RELEASE
RELEASE COMPLETEFAC
Each H.323 entity must have at least one network address that uniquely identifies the
H.323 entity on the network. An endpoint may use different network addresses for
different channels within the same call. For each network address, each H.323 entity may
have several TSAP identifiers. These allow multiplexing of several channels sharing the
same network address.
An endpoint may tunnel a signalling protocol by including the
tunnelledSignallingMessage in a UUI IE in any H.225 call signalling message with
end-to-end significance. Signaslling should not be tunnelled in H.225 messages that are
not of end-to-end significance, such as CALL PROCEEDING, since the information may
not be received by the other end.
If an originating endpoint wishes call setup to proceed only if tunnelling is supported, it
should set the tunnellingRequired flag in the SETUP message. If an endpoint receives a
tunnelledSignallingMessage with the tunnellingRequired flag set in the SETUP
message and is not able to tunnel the protocol, it terminates the call by sending a
RELEASE COMPLETE message.
The tunnelled protocol information is included in the messageContent field and the
tunnelledProtocolID field identifies the protocol being tunnelled.
H.225 can be used to establish a call-independent signalling connection between H.323
endpoints. Tunnelling can be used in this case to provide bearer-independent signalling
for the tunnelled protocol; no H.245 control channel and no media channels are required.
D6.1 Purpose
UniStim is the protocol used by the CentrexIP Client Manager to communicate with
CentrexIP remote clients. As such clients are located on enterprise networks while the
CICM is located on the CS2000 CS LAN, UniStim signalling traverses the CS LAN, the
managed IP core network and enterprise networks, as shown in Figure 75 on page 301.
UniStim is a Nortel Networks protocol, but is available under licence to other equipment
vendors who wish to design and manufacture CentrexIP terminals that support
interoperability with Nortel Networks products such as CS2000. It is therefore capable of
supporting not only proprietary i200x Etherset terminals and PC-based soft clients, but
also compatible third-party terminals. It is formally defined in Nortel Interface
Specification (NIS) D201-1: UniStim Protocol Specification.
UniStim is a stimulus protocol whose command set enables a Network Intelligence (NI),
i.e. CICM, to control every aspect of the operation of a client Internet Terminal (IT).
To provide reliable transport over UDP, UniStim uses a simple Go-Back-N scheme to
provides a suitable Reliable UDP layer for UniStim. This is also defined in NIS
D201-1.The protocol stack used for UniStim signalling is therefore UniStim / RUDP /
UDP / IP.
RTP streams are used for voice transmission.
For further information about the CICM, see section B1.4.2 on page 55.
For further information about CentrexIP clients, see Chapter B4: CentrexIP Remote
Clients and the CentrexIP Client Manager (CICM).
GWC GWC
for CICM for CICM
CentrexIP CentrexIP
Client Client
Manager H.248 P-Phone P-Phone H.248 Manager
(CICM) (CICM)
UniStim is one of
three types of
UniStim signalling used to UniStim
RUDP provide VoIP RUDP
UDP support for UDP
IP CentrexIP clients IP
IP core network
Bearer connections for VoIP are
routed across the core network;
they are not handled by the CICM
Firewall Firewall
CentrexIP CentrexIP
Etherset Etherset
client CentrexIP client CentrexIP
(i200x): soft client (i200x): soft client
(m6350): (m6350):
! The most important client-to-CICM commands that apply to the Network Manager
are:
" Soft Reset Ack (sent by client in response to Soft Reset)
" Resume Connection With Server (unsolicited command sent by client after
successful power-up or soft reset, to inform the CICM that it is ready to accept
commands)
" Suspend Connection With Server
" Network Configuration Element Report sent in response to Query Network
Configuration Element from CICM
" Some or all of Sanity OK, Manager ID, Manager Attributes, Manager
Diagnostics, Manager Options or Server Information sent in response to
Query Network Manager from CICM
" Connect Transducer (establish connection betwen open audio stream and
local equipment: handset / headset / handsfree / all)
" Commands for configuring and controlling transducer-based tones (alerting /
pager / special tone):
# Tone configuration
# Tone cadence download
# Tone volume level
# Tone on / off
" Commands for configuring and controlling stream-based tones (to replace or
be added to an audio stream):
# Tone frequency component list download (up to four frequencies in list)
# Tone cadence download
# Tone on / off
" Commands for controlling Rx volume levels
" Mute / Unmute Audio Stream
" APB Download (an Audio Parameter Bank defines Tx/Rx audio
characteristics)
" Query RTCP Statistics / Session Descrption Information
" Query Audio Stream Status
" Query Audio Manager
! The most important client-to-CICM commands that apply to the Audio Manager
are:
" Port Mapping Discovery
This command is sent as part of a command sequence initiated by a Resolve
Port Mapping command from the CICM, the aim of which is to provide the
CICM with information about the address mapping performed by the NAT
device at the edge of the edge of the CentrexIP clients address domain.
The client sends the Port Mapping Discovery command to the far-end address
provided in the Resolve Port Mapping command, i.e. the CICM. The
command provides the CICM with the IP address and port of the originating
node, i.e. the CentrexIP client, and causes the CICM to send a Port Mapping
Discovery Ack command to that originating address. The clients address is
provided in the body of the command to allow for the possibility that the
source IP address in the IP packet header may be modified as the packet
traverses the NAT device.
" Resolve Port Mapping Ack
This command is sent to conclude a command sequence initiated by a Resolve
Port Mapping command from the CICM, the aim of which is to provide the
CICM with information about the address mapping performed by the NAT
device at the edge of the edge of the CentrexIP clients address domain.
The Resolve Port Mapping Ack command provides the CICM with the
following information:
# The IP address and port of the originating node, i.e. the CentrexIP client.
# The NAT device IP address and port via which the CICM is
communicating with the client, as previously provided in a Port
Mapping Discovery Ack command.
D7.1 Purpose
NCS (Network-based Call Signalling) is an ASCII protocol that was originally based on
the MGCP (Media Gateway Control Protocol) IETF protocol defined in RFC3435 and
described in Chapter D8: MGCP. Like MGCP, NCS is designed to support signalling
between GWCs and the media gateways they control.
The purpose of NCS is to support embedded VoIP client devices in a PacketCable
environment, and the NCS profile has simplified and in some cases modified the base
MGCP 1.0 protocol accordingly. NCS 1.0 is defined in
PacketCable Network-Based Call Signaling Protocol Specification
PKT-SP-MGCP-I10-040402 (or later issue found at www.packetcable.com)
NCS is formally defined as a profile of MGCP for PacketCable embedded clients. It is
one layer of the PacketCable suite of specifications, and relies on other complementary
protocols to provide complete end-to-end PacketCable functionality.
In the CS2000 network architecture, NCS is carried end-to-end between CS2000 GWCs
and MTA (Multimedia Terminal Adapter) line gateways served by cable access networks,
using UDP at layer 4 and IP at layer 3. Between the MTA and the CMTS (Cable Modem
Termination System) at the head end of the cable access network, the Layer 2 datalink
layer and Layer 1 physical layer are as defined by EuroDOCSIS standards for a HFC
(Hybrid Fibre Coax) infrastructure. Between the CMTS and the CS2000 GWC, the Layer
2 and Layer 1 interfaces used depend on the architecture of the backbone packet network,
and may vary during the journey of an IP packet between the GWC and CMTS. These
changes in Layer 1 and Layer 2 are not visible to the CS2000 GWC.
Note: To complement NCS, SDP session descriptions are conveyed in-line with NCS
commands and responses. See section D1.3 on page 239 for more information.
CS2000
Call processing
Gateway Gateway
Controller Controller
(GWC) (GWC)
for ingress for egress
gateway gateway
IP backbone network
Bearer connection
(packetised voice)
CMTS CMTS
In a CS2000 context, NCS connections are initiated by the GWC under the control of
CS2000 call processing, i.e. CS2000 provides Call Agent functionality (also referred to
as Call Management Server functionality). Simple line media gateway functionality, i.e.
interfaces for line endpoints, is provided by the MTA. The CMTS has a twofold role:
! To relay NCS signalling between CS2000 GWCs and MTA line gateways. NCS is
carried end-to-end between GWCs and MTAs using UDP at layer 4 and IP at layer
3, but different Layer 2 and Layer 1 interfaces are used on either side of the CMTS.
The CMTS peforms Layer 1 and Layer 2 mapping to ensure that changes in Layer
1 and Layer 2 are not visible to the CS2000 GWC.
! To make HFC bandwidth available to MTA line endpoints as required. Both the IP
backbone network and the HFC access network support packet-based bearer
connections. Packet streams through the HFC access network (between CMTS and
MTA) are set up and controlled using (Euro)DOCSIS signalling. This is relevant
only within the access network, and is not visible to the CS2000 GWC.
The following table lists the commands available and summarises their functions.
D7.4 Parameters
D7.4.1 Line Endpoint Names
GWCs and line media gateways are separately provisioned with the address information
they need to communicate with each other via NCS.
For each MTA gateway controlled by a GWC, GWC datafill specifies the following:
! FQDN (Fully Qualified Domain Name)
! IP address
Line gateway IP addresses are assigned via DHCP, and are obtained by the GWC
via DNS queries.
To indicate that the GWC should dynamically discover the IP address of a line
gateway by means of a DNS query based on the gateways FQDN, the IP address
specified in gateway datafill at the GWC should be 0.0.0.0.
If the mapping between a gateways FQDN and its IP address is static, the real IP
address can be specified directly in GWC datafill when the gateway is provisioned.
! Control protocol (NCS 1.0)
! UDP port (2427)
! Gateway profile (codec and packetisation info).
The IP address of the GWC is provided to each MTA gateway by the CMTS management
system as part of the configuration information sent during MTA initialisation.
CS2000 datafill maps each logical line DN (Directory Number) on to a physical location.
In the case of cable media lines, CS2000 has no knowledge of the media gateways on
which the lines terminate, and DNs are mapped on to virtual physical locations. Line
endpoints are identified by means of virtual physical shelf and slot numbers associated
with line groups (see section C2.7 on page 196 for more information). Each line group
comprises up to 1023 lines; these may be supported by a number of different CMTSs, but
the entire line group is under the control of one GWC.
D7.6 Examples
See section E7.2.2.2 on page 494 for an annotated call flow showing the sequence of NCS
commands used to set up a call.
Example 2
After being notified of an off-hook event via a NTFY from a media gateway, CS2000
requests the gateway to provide dial tone, ignore any hook flash, report immediately if an
on-hook event occurs, and accumulate dialled digits in accordance with the specified digit
map using the inter-digit timeout timer whose value is provisioned in the media gateway.
The media gateway is also instructed to report the "operation complete" event if the dial
tone signal times out without any digit being dialled or the subscriber going on-hook.
RQNT 1202 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
X: 921
D: (1XX|2XX|3XX|4XX|5XX|6XX|7XX|8XX|9XX|0XX|*|#)
S: dl
R: oc(N), hf(I), hu(N), [0-9]*#T](D)
Response indicating that the transaction was successful, and including a connection
identifier and an SDP session description for the new connection (preceded by a blank
line).
200 1204 OK
I: FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 8 a=ptime:0
Example 2
Passing a session description and including a notification request with an MDCX
command. The endpoint will start playing ringback tones to the user.
MDCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
C: A3C47F21456789F0
I: FDE234C8
M: inactive
X: 0123456789AE
S: rt
v=0
c=IN IP4 128.96.63.25
m=audio 3456 RTP/AVP 8
a=ptime:10
Note: Jitter and latency measurements require the MTA gateway to support RTCP.
MTAs that do not support RTCP will report jitter and latency as zero.
Example 2
To check whether the connection identifier in use for a particular endpoints connection
matches that recorded by CS2000, CS2000 sends the AUEP command with requested
information set to indicate "connection identifiers":
AUEP 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0 NCS 1.0
F: I
The response indicates that the addressed endpoint on the media gateway has an
associated connection with connection identifier = 32F3:
200 1201 OK
I: 32F3
Two types of signalling are used in implementing DQoS for the CS2000 IAC solution:
! COPS (Common Open Policy Service) gate control signalling over a TCP/IP
connection is used between the CS2000 GWC and the CMTS at the cable head end.
The CMTS acts as a COPS PEP (Policy Enforcement Point), while the GWC acts
as a PDP (Policy Decision Point). When a call is made, the GWC sends the CMTS
a COPS decision message indicating whether call setup is authorised, and (if so)
requesting the CMTS to allocate a gate with apropriate resources for the call.
The COPS gate control protocol is an extension of the COPS protocol defined in
RFC2748. The DQoS-specific extensions to COPS are defined in the PacketCable
DQoS specification.
Note: CMS (Call Management Server) is the COPS term used to denote the
functionality provided by the CS2000 Core and the GWC.
! The NCS protocol used between the MTA and the GWC allows the GateID
allocated for an authorised call to be conveyed as a parameter in call setup
messages.
When the CS2000 GWC is brought into service, it initiates a TCP connection to each
CMTS under its control. Once the TCP link is operational, it is used as follows:
1 When a new call is to be set up, the GWC sends a GATE-SET message to the
CMTS, authorising call setup and asking for a gate to be allocated.
2 The CMTS responds with a GATE-SET-ACK message conveying the GateID
assigned for the call.
NCS call setup signalling then proceeds in the normal way (see section D7.6 on page 315
for examples). The GateID to be used for the call is provided by the GWC to the MTA
gateway, either in the first CRCX message or in a subsequent MDCX message, and can
subsequently be used by the gateway in DOCSIS messages sent to the CMTS to set up
packet streams through the HFC access network.
The GateID is specified to the MTA gateway as a dq-gi (GateID) sub-parameter in the
Local Connection options parameter in a CRCX or MDCX message, as in the following
example:
L: p:10, a:PCMU, dq-gi: 1234
During normal call clearing, the CMTS sends the CMS (CS2000 GWC) a Gate Close
message to indicate that the gate has been deallocated and that there is no need for further
DQoS messaging for the call.
Gate status can be queried by the GWC via COPS GATE-INFO messages.
D8.1 Purpose
MGCP (Media Gateway Control Protocol) is an IETF protocol designed to support
signalling between GWCs and the media gateways they control. It is defined in IETF
RFC3435. The version supported by CS2000 is MGCP 1.0bis - 00 January 2001.
In the CS2000 network architecture, MGCP signalling is used between a CS2000 GWC
and a customer LAN line gateway supporting analogue subscriber lines. See section B2.9
on page 123 for information about the gateway types and models supported.
The commands and capabilities provided by MGCP for the control of line media gateways
attached to customer LANs are very similar to those provided by the NCS protocol for the
control of line media gateways attached to cable access networks, as described in Chapter
D7: NCS. To avoid duplication, this chapter cross-refers where possible to sections in
Chapter D7 where these provide information that is equally applicable to NCS and
MGCP.
Note: To complement MGCP, SDP session descriptions are conveyed in-line with
MGCP commands and responses. See section D1.3 on page 239 for more information.
CS2000
Call processing
Gateway Gateway
Controller Controller
(GWC) (GWC)
for ingress for egress
gateway gateway
customer LAN line gateway uses MGCP
Figure 77: Network role of MGCP in supporting customer LAN line gateways
For a line gateway attached to a customer LAN and controlled by MGCP, the address
binding process is as follows:
1 The gateway sends an RSIP (Reset In Progress) message to the public network
address of the CS2000 RMGC (Redirecting MGC) GWC. The RSIP message is
routed through the NAT, which creates a bind between the gateways private
network address and an externally visible address on the public network side of the
NAT.
2 The RMGC looks at the gateway FQDN conveyed in the RSIP message to
determine which gateway sent the message.
3 The RMGC sends the RSIP reply to the IP address and port from which it received
the RSIP message, which is an externally visible address on the public network side
of the NAT. This reply contains the IP address and port of the gateways GWC.
4 The NAT relays the RSIP reply to the media gateways private network address,
which is bound to the externally visible address on the public network side of the
NAT.
Note: This binding used by the RMGC will timeout and expire, as it is no longer
needed.
5 The gateway sends an RSIP message to the public network address of its, GWC, as
provided by the RMGC in the RSIP reply. The RSIP message is routed through the
NAT, which creates a bind between the gateways private network address and an
externally visible address on the public network side of the NAT.
6 The GWC looks at the gateway FQDN conveyed in the RSIP message to determine
which gateway sent the message. GWC datafill is then updated to establish an
association between the FQDN and the IP address and port from which the GWC
received the RSIP message, which is an externally visible address on the public
network side of the NAT.
The public IP address associated with the gateways FQDN will be used for
subsequent messages sent by the GWC to the gateway.
The GWC checks every incoming message for the embedded gateway FQDN. If the
source of a packet does not match the source of previous packets for that gateway,
i.e. the public IP address associated with the gateways FQDN, this indicates that
the address binding at the NAT has changed. In this case, GWC datafill is updated
to establish an association between the FQDN and the new IP address and port, and
this will then be used for subsequent messages.
It is a CS2000 requirement that the media gateway must send packets through the
NAT sufficiently often to keep the NAT address binding for the gateway alive. This
can be achieved by using a timer that is automatically reset whenever the gateway
sends a real message to the GWC, and causes the gateway to send a keep-alive
message if the timer expires without a real message being sent.
D8.5 Parameters
Parameters and parameter usage are essentially the same the same for MGCP as they are
for the NCS (Network-based Call Signalling) protocol described in Chapter D7: NCS,
which is based on MGCP. To avoid duplication, the detailed parameter descriptions
provided in section D7.4 on page 312 are not repeated in this chapter.
D8.7 Examples
See the NCS examples in section D7.6 on page 315. These are equally applicable to
MGCP except for the protocol version, which for MGCP is MGCP 1.0. rather than NCS
1.0.
D9.1 Purpose
MGCP (Media Gateway Control Protocol) is an IETF protocol designed to support
signalling between GWCs and the media gateways they control. It is defined in IETF
RFC3435.
MPCP (Media Proxy Control Protocol) is a simple proprietary protocol loosely based on
version 1.0 of the MGCP protocol. It uses a subset of MGCP messages, which have been
modified and extended with experimental parameters and proprietary interpretation of
existing parameters. It is used by a CS2000 GWC to control an RTP Media Portal
supporting NAPT (Network Address and Port Translation) for media streams
entering/leaving the CS LAN and NAT traversal for media streams between gateways in
different address domains.
Note: Unlike MGCP when used to control line media gateways attached to customer
LANs (see Chapter D8: MGCP), MPCP does not make use of SDP session descriptions
conveyed in-line with MPCP commands and responses. This is because the RTP Media
Portal is switched into calls to act as an intermediary between two media gateways, and it
is the responsibility of the gateways to perform codec negotiation to determine the
characteristics of the end-to-end media stream; the RTP Media Portal merely relays media
stream packets.
Figure 78 illustrates the network role of the RTP Media Portal in supporting NAT
traversal between two media gateways located in private networks behind NAT devices.
CS2000 Core
(call processing)
Control / signalling
Media stream
Line CentrexIP
GWC GWC
H.248
MPCP
Uni
CICM
Public address MGCP
discovery for
signalling UniStim
D10.1 Purpose
IUA (ISDN User Adaptation) is a layer in the (Q.931 or QSIG) / IUA / SCTP protocol
stack designed to convey Q.921 user information between a GWC and a gateway
supporting ISDN PRI or QSIG access by providing both media gateway and signalling
gateway functionality.
IUA enables a gateway to provide signalling gateway functionality by supporting
signalling backhaul from the gateway to the GWC, enabling call processing to be
performed at the CS2000. IUA signalling backhaul is supported for two access protocols:
! ISDN PRI, for which call control signalling is defined in Q.931 or a specification
derived from Q.931.
! QSIG, for which Layer 3 call processing is defined in IS 11572. This is based on
DSS1 Layer 3, i.e. Q.931 / PRI.
For PRI, the recommended device/media control protocol used to complement call
control signalling between the GWC and gateway is the H.248 protocol described in
Chapter D3: H.248. For QSIG, the only complementary device/media control protocol
that has currently been verified is the ASPEN protocol described in Chapter D4: ASPEN.
For details of CS2000 support for PRI, including specification compliance and support for
national PRI variants, see Chapter E4: PRI Access Interface. For details of CS2000
support for QSIG, see Chapter E5: QSIG VPN Interface.
IUA provides adaptation between PRI/QSIG and the SCTP layer used to provide reliable
transport. Logically, it can be regarded as the equivalent of PRI Layer 2 (datalink), as
defined in ETS 300 402 in relation to Q.920 and Q.921. It provides capabilities similar to
ISDN Layer 2 for the encapsulation of Q.921 user information, i.e. PRI/QSIG Layer 3
messages. IUA over SCTP is described in RFC3057. It also gives the GWC remote
control over Q.921 link establishment and release at the gateway.
SCTP (Stream Control Transmission Protocol) is an IETF reliable transport protocol
designed as an alternative to TCP and UDP for handling delay-sensitive payloads such as
call control signalling. It is an assured transfer type that will not allow call setup to
succeed unless all messages have been received in the correct order. It is also secure.
SCTP is being driven in the IETF by the SIGTRAN workgroup; it is defined in RFC2960.
CS2000 support for SCTP is described in section D1.2.3 on page 235.
CS2000 CS2000
Access DPT GWC DPT GWC Access
Gateway and Session and Session Gateway
Controller Controller
(GWC) Server; Server; (GWC)
Ingress Egress Ingress Egress
TDM-side packet-side packet-side TDM-side
Originating Terminating
Gateway Gateway
30B+D 30B+D
PRI/QSIG PRI/QSIG
access access
(23B+D (23B+D
PRI also PRI also
supported) supported)
See section E4.2.2 on page 451 for an overview of the process of setting up a PRI call
between two CS2000s across a backbone packet network, including an annotated call
flow.
D10.3.3 IUA
CS2000 GWCs and gateways are compliant with IUA as defined in IETF draft version 1
of RFC3057. Its main characteristics are:
! Capabilities similar to those of Q.921 Layer 2 (datalink)
! Messages used in Q.921 link establishment and release:
" Establish (corresponding to Q.921 DL-ESTABLISH)
" Release (corresponding to Q.921 DL-RELEASE)
! Messages used for the transport of Q.931 messages as data:
" Data (corresponding to Q.921 DL-DATA)
D10.3.4 SCTP
See section D1.2.3 on page 235 for information about SCTP.
D11.1 Purpose
V5UA (V5 User Adaptation) is used in supporting analogue subscriber lines served by the
V5.2 access interface described in Chapter E7: IBN Lines.
V5.2 can be used to support access to a backbone packet network for subscriber lines
connected to a V5.2 Access Network (AN). V5.2 backhaul supports the transport of V5.2
Layer 3 signalling protocols between a V5.2 AN and an MGC via a managed packet
network. The principle of signalling backhaul is to terminate the lower protocol layers of
a switched circuit network signalling stack at the signalling gateway (a
CS2000-controlled PVG in this case) and transport (backhaul) the higher protocol layers
to an MGC for processing.
For the CS2000 implementation supported in ISN07, the allocation of responsibilities is
as follows:
! AN functionality is provided by a multiplexer or hub, connected to a PVG by means
of an integrated V5.2 interface comprising up to 16 E1 carriers.
! The PVG provides signalling gateway functionality as well as media gateway
functionality. The V5.2 bearer channels on the TDM-side E1 carriers are mapped
on to bearer connections across the backbone packet network. For V5.2
communication channels (C-channels), Layer 1 and 2 functionality is terminated at
the PVG, and Layer 3 signalling, including call control signalling, is extracted and
routed to the CS2000 using V5UA. See section B2.4 on page 111 for further
information.
! MGC functionality is provided by CS2000
V5UA (V5.2 User Adaptation) is an IETF protocol defined in
draft-ietf-sigtran-v5ua-03.txt as an extension to the IUA protocol described in Chapter
D10: IUA. The CS2000 implementation of IUA is compliant with draft version 1 of IUA,
so V5UA as an extension to IUA is not fully compliant with draft-ietf-sigtran-v5ua-03.txt
where such compliance would conflict with IUAv1.
Figure 80 illustrates the protocol stacks used in supporting V5.2 access to a backbone
packet network.
As shown in Figure 80, CS2000 supports V5UA as a layer in the V5.2 / V5UA / SCTP
protocol stack. This is designed to convey V5.2 Layer 3 messages between a GWC and a
gateway supporting V5.2 analogue line access by providing both media gateway and
signalling gateway functionality.
V5UA provides adaptation between V5.2 signalling and the SCTP layer used to provide
reliable transport. Logically, it can be regarded as the equivalent of the ISDN datalink
layer, as it provides capabilities similar to ISDN Layer 2 for the encapsulation of LAPV5
user information, i.e. V5.2 Layer 3 messages.
The messages conveyed via V5UA can be categorised as follows:
! V5.2 Layer 3 call control messages
For analogue lines, V5-PSTN call control messages convey the equivalents of
DTMF in-band signalling or standard POTS electrical signals. (The V5UA protocol
is capable of conveying Q.931 Layer 3 signalling as well as PSTN signalling, e.g.
for ISDN access, but this is not currently supported by CS2000.)
! V5.2 Layer 3 interface control messages
In addition to call control signalling, V5.2 C-channels support the following
protocols for controlling and maintaining the channels of the V5.2 interface:
" A Bearer Channel Control (BCC) protocol is used to assign bearer channels
dynamically, as required.
" A common control protocol is used to provide common control functions and
user port control.
" A protection protocol is used to switch a logical C-channel to an alternative
physical C-channel if there is a failure on the current physical C-channel.
" A link control protocol is used to support maintenance access to individual
carriers (referred to as links in V5 terminology) within a V5.2 interface.
! V5 system management messages for controlling interaction with V5.2 Layer 2 via
primitives, e.g. establishing or releasing a V5.2 C-channel.
! V5 system management messages for controlling interaction with V5.2 Layer 1 via
primitives, e.g. link status queries and reports.
Note: Unlike the ISDN datalink layer, V5UA supports link status and link
identification messages because the V5 standards require V5.2 system management
to interact directly with V5.2 Layer 1 (including the Layer 1 FSM). Since these
entities may be physically separated in a V5 backhaul scenario, V5UA must provide
mechanisms for communication between them.
The term V5.2 signalling should be taken to include interface control and
management/maintenance signalling as well as call control. The term V5-PSTN
signalling specifically denotes call control signalling for PSTN (analogue) lines.
The protocol used for the device/media control signalling that complements V5-PSTN
Layer 3 call control signalling between the GWC and gateway is H.248, as described in
Chapter D3: H.248.
SCTP (Stream Control Transmission Protocol) is an IETF reliable transport protocol
designed as an alternative to TCP and UDP for handling delay-sensitive payloads such as
call control signalling. It is an assured transfer type that will not allow call setup to
succeed unless all messages have been received in the correct order. It is also secure.
SCTP is being driven in the IETF by the SIGTRAN workgroup; it is defined in RFC2960.
CS2000 support for SCTP is described in section D1.2.3 on page 235.
backhauling V5.2 Layer 3 signalling (ESTABLISH etc) across the packet network. This
enables CS2000 to perform V5.2 call processing, and to initiate media control signalling
sessions to control the packet network bearer connections for V5.2 calls.
The mechanism used is to encapsulate the V5.2 Layer 3 signalling in IP packets so that it
can be conveyed from the gateway to a CS2000 GWC. The protocol stack used for this
purpose is V5.2 / V5UA / SCTP / IP.
Figure 81 illustrates the network role of V5-PSTN / V5UA / SCTP call control signalling.
CS2000 CS2000
Access DPT GWC DPT GWC Access
Gateway and Session and Session Gateway
Controller Controller
(GWC) Server; Server; (GWC)
Ingress Egress Ingress Egress
TDM-side packet-side packet-side TDM-side
Originating Terminating
V5.2 V5.2
gateway gateway
D11.3.3 V5UA
CS2000 GWCs and gateways are compliant with V5UA as defined in
draft-ietf-sigtran-v5ua, except where such compliance would conflict with IUAv1, on
which the CS2000 implementation of V5UA is based. V5UA capabilities are similar to
those of Q.921 Layer 2 (datalink). It supports the following types of message:
! Messages used in link layer establishment and disconnection:
" MDL-ESTABLISH(corresponding to Q.921 DL-ESTABLISH)
" MDL-RELEASE(corresponding to Q.921 DL-DISCONNECT)
! Message used for the transport of V5-PSTN messages as data:
" DL-DATA (corresponding to Q.921 DL-DATA)
! Messages used for Layer 1 control and status inquiry:
" MPH-LINK-STATUS
" MPH-SA-BIT
! Message used for error reporting between V5 entities on GWC and GW:
" ERROR-INDICATION
D11.3.4 SCTP
See section D1.2.3 on page 235 for information about SCTP.
PVG CS2000
V5.2 MG SG GWC
AN
Caller
goes V5-PSTN: ESTABLISH V5UA Data Ind (ESTABLISH)
off-hook
V5-PSTN: ESTABLISH ACK V5UA Data Req (EST ACK)
1st
digit Dial tone
removed
Digits H.248 Notify endpoint
matching Match against digit map Onward
digit map call
H.248 Notify endpoint setup
More Additional digit begins
digits
H.248 Modify physical endpoint
Stop digit collection
Apply
H.248 Modify endpoint ringing
RIngback RIngback tone Apply ringback tone
tone
Call in progress
D12.1 Purpose
MTP User Adaptation is designed to support CCS7 signalling over an IP network.
Specifically, it allows CCS7 user part messages or MTP Message Signal Units (MSUs) to
be conveyed between packet network nodes.
Either of two types or levels of user adaptation can be used, depending on whether CCS7
signalling is to be conveyed between packet network nodes that share a CCS7 point code
or nodes that have separate CCS7 point codes. In CCS7 terms, conveying user part
messages between nodes with the same CCS7 point code is known as message
distribution, while conveying MSUs between nodes with diferent CCS7 point codes is
known as message routing. These two types of MTP user adaptation are:
! M3UA (MTP Layer 3 User Adaptation)
Within a distributed system whose components can be accessed via a single CCS7
point code, M3UA can be used to convey user part messages between those
components. Each incoming message is distributed to the appropriate component
and presented to the appropriate user part (ISUP, TUP, TCAP) exactly as if MTP
Layer 3 was doing the distribution rather than M3UA.
In a CS2000 that uses the USP to terminate CCS7 signalling, the USP and the Core
share the same point code, and the USP uses M3UA to distribute incoming CCS7
messages to the Core and GWCs. Use of M3UA over the CS2000 CS LAN between
USP and the Core makes it unnecessary for the Core to provide MTP3 functionality.
! M2PA (MTP2-User Peer-to-Peer Adaptation)
M2PA is used to convey CCS7 MSUs across the backbone packet network between
nodes with different CCS7 point codes. A CCS7 MSU is encapsulated in an M2PA
packet to be routed. On receipt, the M2PA packet is unwrapped and the MSU is
processed appropriately.
In a network of CS2000s that use USPs to terminate CCS7 signalling, each USP and
its Core share the same point code. MSUs can be conveyed between CS2000s
(strictly speaking, between USPs belonging to different CS2000s) using M2PA.
Note: In ISN07, CS2000 uses this functionality only for TCAP-based NCAS (Non
Call Associated Signalling). ISUP and TUP signalling between CS2000s is
conveyed encapsulated in SIP-T. NCAS is not supported by the USP-Compact.
CS2000
TDM-side switches,
TCAP
ISUP TUP
SCCP Conventional
SCPs, etc
TCAP CCS7
ISUP TUP MTP3
SCCP signalling
MTP2 network
M3UA
MTP1
SCTP
CS2000 IP USP
Core TCAP
SCCP
MTP3
M2PA
SCTP
Other CS2000s,
CS LAN IP
peer MGCs
IP control
network over
SIP-T SIP-T backbone
Sessioin packet network
DPT Server ISUP TUP
GWC or SDP SDP
VRDN
TCP or UDP
IP
See section B1.4.5.3 on page 62 for
information about DPT GWC interaction
with Session Server or VRDN
D12.3.2 M2PA
M2PA (MTP2-User Peer-to-Peer Adaptation) is an IETF protocol for communication
over a packet network between IP Signalling Points (IPSPs). An IPSP is a CCS7 node
with an IP signalling connection. IPSPs connected via M2PA must have different CCS7
point codes. M2PA is defined in draft-ietf-sigtran-m2pa.
With effect from ISN07, CS2000 supports M2PA as one layer in the TCAP / SCCP /
MTP3 / M2PA / SCTP / IP protocol stack, and uses it for NCAS (Non Call Associated
Signalling) with remote CS2000s (strictly speaking, with USPs beonging to remote
CS2000s) via the backbone packet network. A CCS7 MSU is encapsulated in an M2PA
packet to be routed. On receipt, the M2PA packet is unwrapped and the MSU is processed
appropriately. The SCTP association acts as a CCS7 link between the IPSPs. It is the
responsibility of the M2PA layer to maintain a map of each of its CCS7 links to the
corresponding SCTP association.
CS2000 use of M2PA to support NCAS supersedes its use of M2UA (MTP Layer 2 User
Adaptation) for this purpose in releases prior to ISN07.
Note: TCAP NCAS over the packet network is not supported by the Compact version of
the USP.
M2PA is a general-purpose mechanism for conveying CCS7 signalling over an IP
network between IP Signalling Points (IPSPs). It is therefore potentially capable of
supporting ISUP or TUP signalling between CS2000s over MTP3 / M2PA / SCTP / IP,
but this capability is not used by the CS2000 international product. Inter-CS signalling via
ISUP and TUP is instead supported by DPT GWCs and Session Servers using SIP-T
encapsulation of CCS7 user part messages, as described in Chapter D2: SIP and SIP-T.
The primitives provided by M2PA for communication with MTP Layer 3 are the same as
those provided by MTP2 for MTP3. The most important of these are:
! Primitives sent from MTP3 to M2PA:
" Data Request
Used to send a Data Message for transmission.
" Start Request
Used to activate a link.
" Stop Request
Used to deactivate a link.
! Primitives sent from M2PA to MTP3:
" Data Indication
Used to deliver received Data Message to MTP3.
Only two messages are defined for peer-to-peer messaging at the M2PA layer:
! User Data messages convey data received by the M2PA layer from MTP3.
Specifically, they contain the following fields of the MTP MSU:
" Length Indicator (LI), including the two undefined bits between the SIO and
LI fields
Note: M2PA does not actually require message length information as MTP2
does. The LI octet is included because the two spare bits in the LI octet are
used by some national CCS7 variants to carry MTP3 information.
" Service Information Octet (SIO)
" Signaling Information Field (SIF)
M2PA User Data messages do not convey other components of the MTP MSU. In
particular, they do not convey MTP3 sequence numbering data, because M2PA
message headers contain a Forward Sequence Number (FSN) and Backward
Sequence Number (BSN) assigned at the M2PA layer.
! Link Status messages are sent between M2PA peers to indicate link status, thus
performing a function similar to that of MTP2 Link Status Signal Units (LSSU).
D13.1 Purpose
The Digital Storage Media Command and Control (DSM-CC) protocol is a toolkit for
developing control channels associated with MPEG-1 and MPEG-2 streams. In ISN07,
CS2000 solutions use DSM-CC to support:
! Remote Access Service (RAS) sessions for the transport of packet data to/from
private intranets and the public Internet
Note: DSM-CC is capable of supporting a wide variety of other media handling
functions, e.g. for controlling video reception via features equivalent to those
provided by VCR units (fast-forward, rewind, pause and so on), but these are not
used in CS2000 solutions in ISN07.
! VoIP calls
DSM-CC uses a client/server model connected via an underlying network (carried either
via the MPEG-2 multiplex or independently). It is defined in a series of standards, of
which the most important is MPEG-2 ISO/IEC 13818-6, i.e. Part 6 of the MPEG-2
standard: Extensions for DSM-CC.
In the CS2000 network architecture, DSM-CC Version 5.2 signalling is used between a
CS2000 GWC and a CVX1800 media gateway providing Universal Port capabilities, i.e.
supporting both RAS and VoIP for incoming calls over IUP/BTUP or UK ISUP.
DSM-CC Version 5.2 is used to instruct the CVX what media handling capabilities to
provide for each incoming call, e.g. to process each incoming RAS call by demodulating
it on one of the CVX modem resources.
GWC-gateway
signalling
(DSM-CC) IP
core
PSTN CCS7 network
signalling
(IUP / ISUP)
Intranet data session
PSTN CVX1800
PSTN bearer channel RAS
media
gateway
Internet data session
Internet
Figure 84: Network role of DSM-CC in supporting RAS
See Chapter F17: RAS (Remote Access Service) for further information about CS2000
support for RAS.
Client Session Setup messages (UP Call Setup, i.e. RAS and VoIP)
ClientSessionSetupIndication
ClientSessionSetupResponse
ClientSessionSetupRequest
ClientSessionSetupConfirm
Client Release Messages (UP Call Release, i.e. RAS and VoIP)
ClientReleaseIndication
ClientReleaseResponse
ClientReleaseRequest
ClientReleaseConfirm
! Overload control
The CVX1800 uses DMS-CC CCHR (ClientConfigHeartbeatResponse) and CCR
(ClientConfigResponse) messages to keep the GWC informed about the availability
of RAS modems, VoIP modems and HDLC terminations.
If no RAS modems are available, the GWC will not initiate any new RAS calls, but
can continue to initiate VoIP calls. Similarly, if no VoIP modems are available, the
GWC will not initiate any new VoIP calls, but can continue to initiate RAS calls. If
no front-end processor is available, no new calls of either type will be initiated.
When packet network call setup cannot be completed for an incoming call attempt
received by a CVX1800, CS2000 indicates this by sending back an REL message
with a release cause of CI_TEMPORARY_FAILURE (for a UK ISUP call) or
NTWK_OUT_OF_ORDER (for a BTUP call).
The primary purpose of the chapters in Part D of the CS2000 Product Description is to
provide brief functional overviews of each of the IP protocols used in setting up and
controlling various types of call or session across the packet network. For completeness,
this chapter provides similar overviews of the IP protocols used for OAM&P purposes.
These are:
! SNMP (Simple Network Management Protocol), which is described in section
D14.1 on page 348.
! The complementary configuration protocols BOOTP (Bootstrap Protocol), DHCP
(Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol),
which are described in section D14.2 on page 352.
Figure 85 illustrates the network role of SNMP and the SNMP DPI. Communication
between the GWC, the GWC EM server application, and the GWC EM client is used as
an example, but the same configuration and principles apply to the management of other
network elements.
D14.1.2.2 Registration
A sub-agent supports a collection of MIB variables or object identifiers (object IDs) that
constitute its MIB (sub)tree. Each object ID consists of a group ID and an instance ID.
The group ID is the root of a MIB sub-tree, and is the point of registration for that MIB
sub-tree in the SNMP agent's MIB tree. The instance ID is simply the piece of the object
ID that follows the group ID (registration point); it is not an instance in terms of the SNMP
definition of an instance.
REGISTERAfter sending an OPEN request to initialise the logical connection to the
SNMP agent (EM), as described in section D14.1.2.1, the sub-agent on a
network element sends one or more REGISTER requests to register its MIB
sub-tree(s) in the agent's MIB tree. With each registration request, the
sub-agent passes parameters such as requested priority and timeout value for
the sub-tree being registered.
The agent sends back a RESPONSE to indicate success or failure of each
registration request.
After successful registration, the sub-agentwaits for requests from the SNMP
agent or generates traps as required.
UNREGISTER
If the sub-agent wants to terminate management of a particular MIB sub-tree,
it sends a DPI UNREGISTER request to the SNMP agent. The agent sends a
response to each UNREGISTER request.
The SNMP agent may also send a DPI UNREGISTER request, e.g. if a
higher-priority registration comes in. The sub-agent sends a RESPONSE.
- Sweden
- Turkey
Note: The CS2000 implementation of ETSI ISUP V2 is sometimes referred
to as V2+ because it supports some ETSI ISUP V3 capabilities.
ETSI ISUP V2 is also used as the base for ISUP variants used in:
# Australia:
$ ACIF G.500 Interconnect ISUP (I-ISUP)
$ Telstra CA30 ISUP, for use within the Telstra network
# Japan:
$ JI-ISUP (Japanese Interconnect ISUP), the interconnect standard
" ETSI ISUP V3 / ITU ISUP 97
These are backwards-compatible extensions to ETSI ISUP V2 / ITU White
Book, designed to support additional services such as feature transparency.
CS2000 implements ETSI ISUP V3 capabilities by providing datafill that
allows V3 services to be activated and supported by the ETSI ISUP V2 agent
(a capability sometimes referred to as ETSI ISUP V2+).
CS2000 does not support base/generic ETSI ISUP V3, but does support
national variants for:
- UK (UK ISUP)
- France (SPIROU)
In both cases, the V3 variant is intended as a replacement for an existing TUP
interconnect interface.
! IBN7 ISUP trunk interface (IBN stands for Integrated Business Network)
Enhanced ANSI ISUP, which is referred to as ANSI ISUP+ or IBN7, is a
proprietary implementation of ANSI ISUP, with extensions to support proprietary
features such as Networked Centrex. The primary role of IBN7 is to link CS2000s
to support networked services for business users.
ANSI ISUP is the North American standard for ISUP, as defined in ANSI
specification T1.113.1-4. Like the ITU and ETSI ISUP specifications, the ANSI
ISUP specification has undergone several revisions, with each successive version
incorporating new optional capabilities while remaining backwards-compatible
with previous versions. CS2000 can support many of these optional capabilities,
which are configured individually rather than being implicitly activated by
datafilling a specific version of ANSI ISUP.
Note: The IBN7 interface is not suitable for general use for interconnect to North
American LECs or IXCs. These interfaces generally require use of refinements of
ANSI ISUP defined by Telcordia (previously Bellcore), which add additional
service signalling capabilities not included in the ANSI ISUP specification. The
North American versions of the CS2000 and DMS product lines do fully support
these interfaces, and can interwork with the International CS2000 via IBN7 trunks.
Figure to use
Interface Call type Modification(s)
as base
Figure 87 on Substitute QSIG for PRI at the top level of the
Intra-CS2000
page 366 PRI / IUA / SCTP / IP protocol stack
QSIG
Networked Figure 89 on Substitute QSIG for PRI at the top level of the
via SIP-T page 367 PRI / IUA / SCTP / IP protocol stack
Substitute V5.2 for PRI and V5UA for IUA at the
Intra-CS2000 Figure 87 on top two levels of the PRI / IUA / SCTP / IP
page 366 protocol stack; use of H.248 as media control
protocol instead of ASPEN is mandatory
V5.2 line
Substitute V5.2 for PRI and V5UA for IUA at the
Networked Figure 89 on top two levels of the PRI / IUA / SCTP / IP
via SIP-T page 367 protocol stack; use of H.248 as media control
protocol instead of ASPEN is mandatory
CCS7 encapsulation is not used for
CS2000-to-MCS5200 signalling.
The CCS7 meaning of each SIP-T message
Between CS2000 Figure 88 on must be inferred from the message header and
SIP-T
and MCS5200 page 367 parameters (see section D2.6.3 on page 255).
The X-Nortel-Profile parameter in the message
header provides trunk group information.
Use of UDP transport is mandatory.
For calls to/from line media gateways served by cable access networks or customer
LANs, the signalling interworking requirements are simpler because a single protocol
(NCS or MGCP) is used for both device/media control signalling and call control
signalling. It is therefore not necessary for CS2000 to co-ordinate signalling via two
different protocols. For a line-to-line call networked via SIP-T, two types of interworking
take place for each half call:
! Call control messages, e.g. requests to initiate a call to a dialled DN, are interworked
to appropriate CCS7 messages encapsulated via MIME, e.g. an ISUP or TUP IAM.
! Device/media control signalling conveyed in-line with NCS or MGCP packages,
e.g. SDP information used in codec and bearer capability negotiation, is
interworked to SDP information encapsulated via MIME.
Signalling: Signalling:
Call control signalling Call control signalling
ISUP ISUP
MTP MTP
Co-ordination Co-ordination
Media control signalling Media control signalling
H.248/lASPEN H.248/lASPEN
(SDP) (SDP)
UDP UDP
IP IP
Connections: Connections:
Call control signalling Call control signalling
ISUP signalling terminated ISUP signalling terminated
on USP or FLPP on USP or FLPP
Figure 86: CCS7-to-CCS7 call between two gateways controlled by the same CS2000
Signalling: Signalling:
Call control signalling Call control signalling
PRI PRI
IUA/SCTP/IP IUA/SCTP/IP
Co-ordination Co-ordination
Media control signalling Media control signalling
H.248/lASPEN H.248/lASPEN
(SDP) (SDP)
UDP UDP
IP IP
Connections: Connections:
Call control signalling Call control signalling
IP link between GWC and gateway IP link between GWC and gateway
(IP / AAL5 if backbone is ATM) (IP / AAL5 if backbone is ATM)
Figure 87: PRI-to-PRI call between two gateways controlled by the same CS2000
Signalling: Signalling:
Call control signalling
SIP-T
ISUP Session control
and encapsulation
MTP
Co-ordination
ISUP
Media control signalling Call control signalling
H.248/lASPEN SDP
(SDP) Media control signalling
UDP
IP UDP
Connections: IP
Signalling: Signalling:
Call control signalling
SIP-T
PRI Session control
and encapsulation
IUA/SCTP/IP
Co-ordination
ISUP
Media control signalling Call control signalling
H.248/lASPEN SDP
(SDP) Media control signalling
UDP
IP UDP
Connections: IP
E2.1 Introduction
Common Channel Signalling System No7 (CCS7) is a message-based network signalling
system that provides all the capabilities necessary for the following:
! Call establishment
! Call clearing
! Error handling
! Network operations and maintenance
! Database queries
It is a layered hierarchical system consisting of a number of parts that can be mapped on
to the OSI 7-Layer model. Message transfer functions are provided in a standardised way
at the lower levels of the hierarchy, while the messages to be transferred belong to one of
a number of user parts that occupy the higher layers of the hierarchy.
Note: The circuit-based message transfer functions defined in CCS7 standards are not
applicable in packet networks. For calls between CS2000s across the packet network,
CCS7 user part messages are not conveyed via MTP Layers 1-3. Instead, circuit-oriented
ISUP and TUP signalling is conveyed encapsulated in SIP-T, while TCAP NCAS (Non
Call Associated Signalling) is conveyed by means of M2PA (MTP2-User Peer-to-Peer
Adaptation).
The key to the efficiency of the system is that signalling, i.e. user part messaging, is
conveyed in dedicated signalling channels, which means that speech channel capacity
does not have to be used for this purpose. A single signalling channel is capable of
conveying the call setup and clearing messages for thousands of voice/data channels.
Note: Different standards bodies are involved in the definition of CCS7. North American
CCS7 standards are defined by the American National Standards Insitute (ANSI).
International standards are defined by the International Telecommunications Union
(ITU), the successor to CCITT. European CCS7 standards, which are typically defined in
relation to the corresponding ITU standards, are produced by the European
Telecommunications Standards Institute (ETSI). In addition, national standards bodies
define national CCS7 variants, typically using ITU or ETSI standards as the baseline. All
of these different standards bodies have the same general view of CCS7 parts and their
functions, but there are a number of detailed differences between individual
specifications, which are discussed where appropriate in the following sections.
Figure 90 illustrates the mapping of CCS7 parts on to the OSI 7-layer model. Brief
descriptions of the functions of each part are provided on the following pages.
IN database Direct
queries interaction Voice calls Simple
(interaction with service Supplementary services telephony
with SCP logic (e.g. ISDN data calls calls
via INAP) networked
CCBS)
Layer 7
SSUTR2/FTUP in France
TCAP
IBN7 (ANSI ISUP+)
TCAP
IUP/BTUP in the UK
CTUP in China
Layer 6
(Presentation)
Null layers
Layer 5
(Session)
Layer 4
(Transport)
SCCP (ITU/ANSI)
Circuit-independent or Circuit-oriented SCCP
Layer 3 connectionless SCCP (not supported by CS2000)
(Network)
Message transfer functions
Note: For CCS7 calls across the packet network between peer CS2000, circuit-based MTP
capabilities are not used. Instead, circuit-oriented ISUP and TUP signalling is conveyed
encapsulated in SIP-T, while TCAP NCAS (Non Call Associated Signalling) is conveyed by
means of M2PA (MTP2-User Peer-to-Peer Adaptation).
Call processing
(e.g. translations)
supported by CS2000 Core
OSI Layers
Originating Terminating
switch switch CCS7 protocol
supported via
Layer 7: Application static provisioning
CCS7 CCS7
user part Logical peer-to-peer user part
Layer 6: Presentation communication via
(ISUP, TUP, (ISUP, TUP, MTP Layer 3
Layer 5: Session TCAP) user part messages TCAP) message handing
provided by
Layer 4: Transport USP or FLPP
Layer 3: Network MTP MTP
Message Message
Layer 2: Datalink Transfer Transfer MTP Layer 2
Part Part functions provided
Layer 1: Physical
by CCS7 link
system node (USP)
User part messages conveyed between nodes or LIU7 (FLPP)
in MTP Message Signal Units (MSUs)
E2.2.1.2 Configuration
In a TDM network, CCS7 trunks (bearer channels) and CCS7 signalling links are
typically 64Kb/s channels on 2Mb/s PCM30 carriers (E1s). Within the TDM network, a
given carrier can be dedicated to bearer channels, dedicated to signalling channels, or
support a mixture of both.
For CCS7 access from a TDM network to the packet network, signalling links are routed
over dedicated E1 carriers to a signalling gateway peripheral on the CS2000. Routing to
the CS2000 is direct for TDM carriers that are dedicated to signalling channels. For TDM
carriers that support bearer channels as well as signalling channels, the signalling links
must be groomed off before being routed to the CS2000. This grooming is typically done
by a separate multiplexer unit, logically independent of the media gateway but co-located
with it, but can alternatively be performed by a PVG itself.
The trunks corresponding to CCS7 signalling links terminate on media gateways, not on
the CS2000. The media gateways map the TDM-side bearer channels seamlessly on to
packet-based media streams. Co-ordination between signalling channels and bearer
channels is maintained via GWC-gateway media control signalling protocols. The two
protocols supported in ISN07 for device/media control signalling betwen GWCs and
PVGs are H.248 and ASPEN. Mediant 2000 gateways are controlled via H.248.
In ISN07, two alternative CS2000 signalling gateway peripherals are available to
terminate TDM-side CCS7 signalling:
USP Universal Signalling Point
TDM-side CCS7 user part messaging terminates on CCS7 link system nodes
in the USP, and the USP distributes messages to the CS2000 Core over the CS
LAN via a CCS7 / M3UA / SCTP / IP protocol stack. In CCS7 terms, the Core
and the USP share the same point code. As far as Core-resident CCS7 user
parts such as ISUP are concerned, M3UA allows messages to be sent and
received exactly as if MTP Layers 1-3 were in use, i.e. the user parts are not
aware that the USP is a separate LAN node.
FLPP Fiberised Link Peripheral Processor
TDM-side CCS7 user part messaging terminates on LIU7s (Link Interface
Units) in FLPP shelves, and the FLPP uses proprietary signalling to convey
messages to the CS2000 Core via the MS.
Use of the USP to support CCS7 signalling is recommended for all new CS2000
configurations. The FLPP is standard in existing TDM switches and in early CS2000
configurations, however, and it is expected that such FLPPs will be continure to be used
when the configurations are upgraded to ISN07.
See section B1.6 on page 72 for further information about the hardware configurations and
protocol stacks that can be used to support TDM-side CCS7 signalling.
TDM-side switches,
CS2000 TCAP
ISUP TUP
SCPs, etc
TCAP SCCP Conventional
ISUP TUP CCS7
SCCP MTP3 signalling
MTP2 network
M3UA
SCTP MTP1
CS2000 USP
Core IP TCAP
2 3 SCCP
MTP3
Other CS2000s,
M2PA
peer MGCs
CS LAN SCTP
IP IP control
network over
Session backbone
DPT Server SIP-T SIP-T
GWC packet network
or 1 ISUP TUP
VRDN
SDP SDP
Figure 92: CS2000 support for CCS7 signalling flows across packet networks
A CS2000 that uses the FLPP (Fiberised Link Peripheral Processor) to terminate
TDM-side CCS7 signalling supports only one type of packet network signalling flow, i.e.
signalling for inter-CS ISUP and TUP trunks, which does not involve the FLPP. Intra-CS
CCS7 signalling uses the MS, and NCAS is supported only via a conventional CCS7
signalling network. The intra-CS (M3UA) and inter-CS NCAS (M2PA) protocol stacks
are not supported.
Logical View
CCS7 user part messages (ISUP or TUP) are encapsulated in SIP-T session control
messages. These SIP-T messages are conveyed between nodes using either TCP or UDP
as the transport protocol, as illustrated in figure 93 and described in detail in Chapter D2:
SIP and SIP-T.
Call processing
(e.g. translations)
supported by CS2000 Core
OSI Layers
Originating Terminating
CS2000 Logical peer-to-peer CS2000 CCS7 protocol
communication via support provided
CCS7 messages by DPT GWC
Layer 7: Application ISUP / TUP ISUP / TUP
Layer 6: Presentation
SIP-T session SIP-T session
Layer 5: Session SIP-T SIP-T control provided
by Session Server
Layer 4: Transport TCP or UDP TCP or UDP
Layer 3: Network IP IP
UDP transport and
Layer 2: Datalink lower layer control
provided by
Layer 1: Physical Session Server
Configuration
Dynamic Packet Trunks for inter-CS signalling are supported by DPT GWCs with no
subtending units. DPTs are so called because trunk characteristics such as the ISUP
protocol variant to be used are determined on the basis of the telephony profile of the
selected route, which is downloaded to the DPT GWC during call establishment.
For SIP-T, the telephony profile indicates the protocol characteristics of encapsulated
CCS7 signalling messages, which can be those of any supported ISUP or TUP variant.
The telephony profile itself is selected on the basis of the far-end host name, as determined
by translations and routing for an originating CS2000 or as indicated by the first incoming
message for a terminating CS2000.
Typically, SIP-T is used for signalling between CS2000s, while SIP is used for signalling
between CS2000 and MCS5200. SIP does not provide direct CCS7 support, but SIP
messages can be interworked with CCS7 equivalents to provide indirect CCS7 support.
For SIP, the telephony profile indicates the CCS7 protocol that is to be interworked with
SIP, which in ISN07 can only be IBN7 ISUP.
The DPT GWCs on a CS2000 provide a pool of resources that can be used for connections
to any peer CS2000 or compatible MGC. A DPT GWC is selected and allocated only for
the duration of a given call, and is then returned to the pool for re-use.
To support inter-CS signalling, the operation of DPT GWCs is co-ordinated with that of
one or other of the following unit types:
! The preferred implementation with effect from ISN07 is based on DPT GWCs
interacting with the Session Server. SIP signalling is terminated on the Session
Server, which extracts the CCS7 signalling and passes it on to the DPT GWC.
! Prior to ISN07 (and still supported), the standard implementation was based on a
DPT GWC interacting with another GWC configured as a VRDN (Virtual Router
Distibution Node) to provide an externally visible IP address as a point of initial
contact for its host CS2000. In this implementation, DPT GWCs were responsible
for terminating SIP signalling and extracting CCS7.
See Figure 13 on page 63 for an illustration of how DPT GWCs interact with these other
units to support inter-MGC communication via SIP / SIP-T. See section E2.2.3: Call
Flow for Networked CCS7 VoIP or VoATM Call on page 376 for an annotated call
flow that illustrates CCS7 call establishment across the packet network using SIP-T.
Packet network bearer connections (media streams) corresponding to SIP-T signalling
sessions are established between media gateways under CS2000 control. They are not
directly handled by the CS2000, and are therefore outside the scope of this document.
CS2000 is, however, responsible for relaying SDP session descriptions between the
originating and terminating media gateways, and for controlling gateway operation via
device/media control signalling from the corresponding GWCs.
E2.2.2.3 NCAS (Non Call Associated Signalling) over the Packet Network
The USP also supports NCAS (Non Call Associated Signalling) with remote CS2000s
(strictly speaking, with USPs beonging to remote CS2000s) via the backbone packet
network. The protocol stack used for this purpose is TCAP / SCCP / MTP3 / M2PA /
SCTP / IP, where M2PA (MTP2-User Peer-to-Peer Adaptation) is an IETF protocol for
communication over a packet network between systems with different CCS7 point codes.
Note: Not supported by the USP Compact (see section B1.6.1.4 on page 77).
See Figure 92 on page 373 for an illustration of the protodcol stack and configuration used
to support TCAP NCAS with remote CS2000s.
Note: The USP could also support ISUP or TUP signalling between CS2000s over MTP3
/ M2PA / SCTP / IP, but this capability is not used by the CS2000 international product.
Inter-CS signalling via ISUP and TUP is instead supported by DPT GWCs and Session
Server or VRDN using SIP-T encapsulation of CCS7 user part messages, as described in
section E2.2.2.1 on page 374.
CCS7 signalling
2 6 9 10 25 18 20
28 29 38a Inter-CS signalling 33 31 21
23
(CCS7 signalling
37 36 24 38b 30
encapsulated in SIP-T)
PSTN
Figure 94: Setting up an ISUP VoIP or VoATM call between two CS2000s
Note: The messaging description below reflects two assumptions about protocol usage:
! It is assumed that the protocol used for device/media control signalling betwen
GWCs and PVGs is H.248. ASPEN continues to be supported as an alternative to
H.248 for trunk gateway control, but use of H.248 is recommended.
! It is assumed that the Session Server rather than a GWC configured as a VRDN is
used to terminate inter-CS packet network connections in the inter-CS part of the
call flow illustrated in Figure 94 on page 376. This implies that the Session Server
provides all SIP functionality, and that TCP rather than UDP is used as the inter-CS
transport protocol. See section D2.2: CS2000 Support for Dynamic Packet
Trunks on page 244 for further information.
1 Incoming call arrives at originating media gateway.
2 IAM for incoming call groomed off to terminate on CS2000 signalling gateway.
Signalling gateway (USP or FLPP) identifies ingress access GWC and media gateway
3a
3b and routes the IAM to the GWC. Ingress access GWC validates and processes IAM
and sends it on to the CS2000 Core.
CS2000 Core uses IAM to:
- Perform translations and routing, resulting in the selection of an outgoing trunk
group to another CS2000
- Select a DPT (Dynamic Packet Trunk) from the pool supported by DPT GWCs
4
- Allocate the selected DPT for the duration of the call
The DPT GWC selects a trunk profile for the DPT on the basis of the CCS7 protocol to
be used and the destination hostname, and passes the telephony profile index to the
Core.
See Figure 13 on page 62 for an illustration of how DPT GWCs interact with the
Session Server to support DPTs for inter-CS communication.
5a CS2000 Core sends FCM (Fabric Control Message) to ingress and egress GWCs to
5b enable direct communication between them
Ingress access GWC sends H.248 Add commands to originating media gateway to
establish mapping between TDM-side and packet-side terminations. First Add
6 command identifies TDM-side trunk and requests gateway to add it to a newly created
context. Second Add command asks gateway to reserve logical packet-side
termination in receive-only mode and add it to the same context.
Media gateway response to second Add command provides GWC with endpoint
7
identifier (IP address) to use for logical termination, together with SDP description of
bearer capabilities supported (for use in codec negotiation with the gateway serving
the remote endpoint).
8
Ingress access GWC passes media gateway IP address and SDP session description
to egress DPT GWC
Egress DPT GWC assembles outgoing IAM and forwards IAM to egress Session
Server. Egress Session Server encapsulates IAM in SIP-T INVITE message, together
9 with SDP session description including IP address of originating media gateway
endpoint; egress Session Server then sends INVITE message to Session Server on
terminating CS2000
10
Ingress Session Server on terminating CS2000 immediately acknowledges INVITE
message by sending back a SIP-T 100 TRYING message with no payload
Ingress Session Server selects an ingress DPT GWC that has an available DPT,
11
provides it with trunk profile information derived from the INVITE message.
See Figure 13 on page 63 for an illustration of how the Session Server and DPT GWCs
interact to support DPTs for inter-CS communication.
12
Ingress DPT GWC allocates selected DPT for the duration of the call and defines its
protocol characteristics in accordance with trunk profile from INVITE message.
13
Ingress Session Server forwards IAM extracted from INVITE message to selected DPT
on ingress DPT GWC
14
Ingress DPT GWC forwards IAM to CS2000 Core, requesting it to initiate call
processing
15
CS2000 Core uses IAM to perform translations and routing, and identifies the egress
access GWC and media gateway serving the destination
16a CS2000 Core sends FCM to ingress and egress GWCs to enable direct
16b communication between them
17
Ingress DPT GWC passes originating media gateway IP address and SDP session
description to egress access GWC
Egress access GWC sends H.248 Add commands to terminating media gateway to
establish mapping between TDM-side and packet-side terminations. First Add
18 command identifies TDM-side trunk identified via translations and routing, and
requests gateway to add it to a newly created context. Second Add command asks
gateway to reserve logical packet-side termination and add it to the same context.
Media gateway response to second Add command provides GWC with endpoint
19
identifier (IP address) to use for logical termination, together with SDP description of
bearer capabilities supported (for use in codec negotiation with the originating media
gateway serving the originating endpoint).
20 Outgoing IAM sent out from signalling gateway (USP or FLPP) on terminating CS2000
21 Backward ACM received by signalling gateway on terminating CS2000
Backward ACM routed to ingress DPT GWC on terminating CS2000 (directly or via the
22 Core, depending on CCS7 protocol types involved); ingress DPT GWC forwards ACM
to ingress Session Server
23
Ingress Session Server encapsulates outgoing ACM in a backward SIP-T 183
SESSION PROGRESS message, then sends message to originating CS2000
24
Ingress DPT GWC sends ingress Session Server a request for ringback tone to be
applied to originating TDM-side trunk.
25
Ingress Session Server conveys ringback tone request to originating CS2000 by
means of a backward SIP-T 180 RINGING message
Egress Session Server on originating CS2000 terminates SESSION PROGRESS and
26 RINGING messages, extracting backward ACM from SESSION PROGRESS
message and forwarding it to egress DPT GWC
27
Egress DPT GWC on originating CS2000 forwards ACM to ingress access GWC
(directly or via the Core, depending on CCS7 protocol types involved)
28 Backward ACM sent out from signalling gateway on originating CS2000
29
Ingress access GWC sends H.248 Modify message to originating media gateway,
asking gateway to apply ringback tone to originating TDM-side trunk
30
Backward ANM received by signalling gateway on terminating CS2000 and passed to
egress access GWC
31
Egress access GWC sends H.248 Modify message to terminating media gateway,
asking gateway to place the bearer connection in full duplex mode
Backward ANM routed to ingress DPT GWC on terminating CS2000 (directly or via the
32
Core, depending on CCS7 protocol types involved); ingress DPT GWC forwards ANM
to ingress Session Server, together with SDP description of bearer capabilities
supported by terminating media gateway endpoint
33
Ingress Session Server encapsulates outgoing ANM and associated SDP in a
backward SIP-T 200 OK message, then sends message to originating CS2000
34
Egress Session Server on originating CS2000 extracts ANM from SIP-T message and
forwards it to egress DPT GWC
35
Egress DPT GWC notifies ingress access GWC (directly or via the Core, depending on
CCS7 protocol types involved) of ANM arrival
Ingress access GWC sends H.248 Modify message to originating media gateway,
36 completing codec negotiation process and asking gateway to remove ringback tone
and place the bearer connection in full duplex mode
Backward ANM sent out from signalling gateway on originating CS2000, thus
37 completing call setup for the packet network bearer connection between the two media
gateways
Forward SIP-T ACK message originated by egress Session Server on originating
38a
38b CS2000 to confirm receipt of final response to the original INVITE message, then sent
to ingress Session Server on terminating CS2000 to complete three-way handshake
The following truth table indicates how different combinations of factors determine
whether echo cancellation is turned on or off for a call.
Originating Terminating
switch switch
Caller goes
off-hook and
dials number IAM (Initial Address Message)
Call in progress
At a functional level, ANSI ISUP and ETSI ISUP are essentially the same, but at the
protocol level there are differences in the parameters and parameter values supported.
They also use different formats for the MTP routing label (as used on the TDM side).
generic QFT (QSIG Feature Transparency) capability, and specific services such as
NAOC (Network Advice Of Charge), by means of ISUP and TCAP signalling. See
section E5.1.5 on page 469 for more information about QFT.
Call Processing Agent for ETSI ISUP V3
CS2000 does not yet support a base/generic ETSI ISUP V3 agent, but does support two
national variants of ETSI ISUP V3:
! UK ISUP, as described in section E2.3.5 on page 398
! SPIROU (French ISUP V3), as described in section E2.3.6 on page 400
Table TRKSGRP identifies ETSI ISUP V3 trunks by means of a signalling type of C7UP,
an external protocol of Q767, and a protocol version selector of EIV3_100.
Basic call
Bearer capability: speech
Bearer capability: 3.1 KHz audio
Bearer capability: unrestricted digital information
Compatibility procedure (message and parameter compatibility only) [1]
Confusion procedure [2]
Echo control procedure (static and dynamic echo control)
Tones and announcements
MTP pause and resume
Access delivery information
Transportation of user teleservice information
Simple segmentation [3]
Generic procedures for supplementary service support
End-to-end signalling - Pass along method [4]
Generic number transfer [1]
Generic digit transfer [1]
Generic notification procedure [1]
[1] ETSI ISUP V2 only; not supported by ETSI ISUP V1.
[2] Fully supported by ETSI ISUP V2. CS2000 ETSI ISUP V1 does not support full confusion
procedures, but will send a CFN message on receipt of unrecognised information, which exceeds
the requirements specified in Q.767.
[3] ETSI ISUP V2 only. CS2000 provides full originating and terminating node support for IAM
segmentation. For segmentation of other messages, CS2000 provides only transit node support.
[4] Used only in Spanish ISUP V1.
Capabilities listed in Table 1 of Q.761 but not supported by the CS2000 implementation
of ETSI ISUP V1 or ETSI ISUP V2.
Basic call
Multirate connection types
Signalling procedures for connection type allowing fallback capability
User part availability control
Propagation delay determination procedure
Generic procedures for supplementary service support
End-to-end signallingSCCP Connection Oriented
End-to-end signallingSCCP Connectionless
Simple service activation procedure
Remote operations procedure
Network specific facility procedures
Message Support
CS2000 supports standard messages as summarised in the table below.
! Czech-specific messages
" TON (Trunk Offering On)
" TOF (Trunk Offering Off)
! Messages specific to German T-ISUP
" Charging (CHG)
" Charging Extended (CHGE)
" Charging Extended Ack (CHGEA)
" Einhaengezeichen des A-Tl (EHZA)
" Facility Information (FIN)
" Nationale Nachricht (NANA)
" User Information (UIN)
! Israel-specific messages
" BCM (Backward Charge Message)
" TCM (Tariff Change Message)
" CAM (Charging Acknowledge Message)
! Mexico-specific messages:
" Offer
" Offer Cancellation
" Recall (not used in Telmex ISUP)
" False
! Russia-specific messages:
" CCL (Calling Line Clear) message for use with MCT
" RNG (Ring) message for operator requests to apply ringing
! Turkey-specific message used to support MCT:
" IDENT
The following messages are not supported, i.e. they are never generated by the CS2000.
If received, they are treated according to the message compatibility procedures of Q.764
(see also see also Handling Unrecognised Messages and Parameters on page 391).
Parameter Support
Parameters supported.
The following parameters are not supported, i.e. they are never originated by CS2000. If
received, they are treated according to the compatibility procedures of Q.764, except that
the recommendations for unrecognised optional parameter values are not implemented
(see also Handling Unrecognised Messages and Parameters on page 391). At a transit
node, such values are not analysed, and will pass through transparently; at a terminating
node, the action taken depends on the interworking.
Miscellaneous Capabilities
Capabilities not explicitly listed in the standards:
! Call processing is based on EDCP (Event-Driven Call Processing), which means
that incoming ETSI ISUP calls (both TDM-side and SIP-T) can trigger as IN
(Intelligent Network) calls.
! Continuity checking
! Translations and routing based on:
" Bearer Capability
" Numbering Plan Indicator / Nature Of Address
" Calling Party Category
! Overlap outpulsing for all interworkings supporting overlap signalling, including
SIP-T carriage of ISUP.
! Full originating and terminating node support for suspend/resume functionality and
use of the reanswer timer T6.
! ISUP V2+ support for QFT (QSIG Feature Transparency)
Allows bearer-related QSIG information to be transparently transported across the
ETSI ISUP network using the generic APM (Application Transport Mechanism).
Support provided by ETSI ISUP V3 messages/parameters implemented by CS2000
as extensions to ETSI ISUP V2:
" An Application Transport Parameter (APP) that can be conveyed in the
existing ISUP message IAM, ACM, ANM, CON and CPG.
" An Application Transport Message (APM) that can be sent independently to
convey an APP.
" A Pre-Release Information (PRI) message that can be sent prior to a REL
message to convey an APP.
" APM-based segmentation and reassembly.
" APM-based overlap outpulsing of private digits.
See section E5.1.5 on page 469 for more information about QFT.
! ISUP V2+ support for NAOC (Network Advice Of Charge)
For NAOC, call charges are calculated centrally at a CDP (Charge Determination
Point), and call charge information is provided to an originating CGP (Charge
Generation Point) to be relayed back to the calling user over the access interface.
Charging information is conveyed from the CDP to the CGP using the ETSI ISUP
V2+ APM (Application Transport Mechanism).
! Ability to suppress timer T9 for FreePhone calls. Timer T9 is started at an
originating switch when an ACM is received, and causes the call to be released if it
expires before an ANM is received. RTE and CONT translation selectors can now
prevent this by specifying NO_ANSWER_TIMING.
! Rerouting on congestion
If a call routed out over an ETSI ISUP trunk encounters congestion (indicated by
receipt of a REL message with cause value 34 or 42), this option allows CS2000 to
make another attempt to route the call.
Note: Alternative names for rerouting on congestion are Conditional Re-Routing
and NRR (Network Re-Routing (NRR).
! Automatic Congestion Control (ACC), as described in A59034132
With ACC (as defined in Q.764 section 2.11), a congested switch alerts other
switches to congestion levels via automatic congestion level (ACL1 and ACL2)
parameters in REL messages, enabling them to activate any automatic congestion
controls. For TDM-side ETSI ISUP on CS2000, the control mechanism used on
receipt of a REL message with an ACL parameter is to block the circuit to outgoing
calls for a period in the datafillable range 0-240s.
! Billable digits
Maximum number of digits for ACIF I-ISUP is 30, as for ETSI ISUP V2.
! CLI and CPC parameter values
These must be provided in the IAM for all Interconnect ISUP calls. This means that
ACIF I-ISUP does not need to support the use of INR/INF messages to request and
provide this information.
VPN Services
ETSI ISUP V1 and V2 (and national variants) both support the following VPN services:
! On-net routing
! Off-net routing
! Automatic route selection
! Time of day routing
! CLI-based screening for indirect and customer group access
! Virtual Facility Group support (SFG/NARS)
! ETSI ISUP V2 also supports the ETSI ISUP V3 APM (Application Transport
Mechanism), which allows it to provide networked support for private numbering
plans, and to support QSIG Feature Transparency (QFT) and DPNSS Feature
Transparency (DFT). QFT and DFT respectively allow QSIG and DPNSS
signalling information to be conveyed transparently over the network.
QFT is supported as described in section E5.1.5 on page 469.
Note: Since CS2000 does not support DPNSS as an access interface in ISN07,
support for DFT is limited to the relaying of encapsulated information originated in
the TDM network.
! Networked Centrex
Networked Centrex means extending the operational scope of Centrex services
beyond a single switch, e.g. forwarding a call to a line served by a different switch,
or distributing incoming calls between ACD groups on different switches.
This is accomplished by use of a proprietary Network Information (NETINFO)
parameter in call setup messages using the APM mechanism to provide the
following subscriber details for use in setting up translations:
" Customer group, which determines the availability to the subscriber of
services provisioned against the customer group.
" Network Class Of Service (NCOS), which determines the types of call that the
subscriber can make and receive (see section C3.2 on page 206 for details of
NCOS screening).
NETINFO makes it possible to support customer groups served by more than one
node. In a VPN context, it enables subscribers to have access to the same range of
services regardless of where a call is made from or where a given service
implementation resides.
It also allows ISUP trunks to be shared between multiple VPNs.
Networked Centrex
Networked Centrex means extending the operational scope of Centrex services beyond a
single switch, e.g. forwarding a call to a line served by a different switch, or distributing
incoming calls between ACD groups on different switches.
Support for Networked Centrex requires service-related information to be conveyed in
additional IBN7 ISUP parameters and messages. The NETINFO parameter conveyed in
every IBN7 IAM provides customer group and NCOS information that makes it possible
to determine whether a given call is a private network call, and thus determine which
services are available. Other parameters provide information such as the callers number
and name. For some services, support may also require switches to exchange information
and requests via circuit-independent IBN7 TCAP messaging.
Note: Although TCAP NCAS (Non Call Associated Signalling) across the packet
network is supported in ISN07, IBN7 services that rely on it (e.g. NRAG, feature
transparency) need to be productised before deployment.
Gateway
Other
switch
CS2000
Other
IXC FGD ISUP carriers/
CS2000 IECs
PSTN/ FGD ISUP running
LECs ISN07
ANSI PRI
or
USA R1 CAS
Corporate
network
The FGD ISUP protocol and its message flows are very similar to those of the IBN7
(ANSI ISUP+). FGD ISUP trunks are therefore defined in table TRKGRP as trunks of
type IBN (IBNTO, IBNTI or IBNT2), with signalling type C7UP and external protocol
Q764. This is as for IBN7 ISUP trunks. The handling of optional IAM parameters,
including those that are FGD-specific, is controlled via datafill in tables TRKOPTS and
ISPARM.
For a detailed description of the ISN04 (TDM) implementation of FGD ISUP, see
A59036475.
E2.3.5.1 Variants
UK ISUP is intended to be the long-term replacement for IUP/BTUP (see section E2.4.1
on page 406) as the standard CCS7 trunk interface for use within and between networks
in the UK.
It has been designed as a national variant of ITU-T ISUP 97, which is expected to be the
basis for ETSI ISUP V3, i.e. the design intent is that UK ISUP should be compatible with
ETSI ISUP V3.
Because it has been designed as an ETSI ISUP variant, basic call functionality and call
estabishment for UK ISUP are essentially the same as for ETSI ISUP. UK ISUP and ETSI
ISUP V3 differ from ETSI ISUP V1/V2 in terms of the level of service support they
provide, as follows:
! UK ISUP supports the Application Transport Mechanism (APM) for transparently
conveying service-related information across the network. This allows switches to
provide transit support for services based on QSIG, DPNSS or other feature-rich
PBX protocols.
! UK ISUP supports a number of specific supplementary services in addition to the
MoU2 services supported by ETSI ISUP V2 (see section E2.3.5.2 on page 399 for
details).
UK ISUP is defined in PNO-ISC/SPEC/007 (Issue 2.1, April 1998), produced by the UK
Public Network Operators Interconnect Standards Committee (PNO-ISC) ISUP Working
Party. This document specifies the ISUP protocol required for the national interface
between public network operators in the UK.
The base for Issue 2 of the UK ISUP specification is ITU-T Recommendations
Q.761-764 (1997 edition), generally referred to as ISUP 97, extended to include
descriptions of additional functionality required for the UK.
VPN Services
UK ISUP supports the following VPN services:
! On-net routing
! Off-net routing
! Automatic route selection
! Time of day routing
! CLI-based screening for indirect and customer group access
! Virtual Facility Group support (SFG/NARS)
UK ISUP also supports ETSI ISUP V3 APM (Application Transport Mechanism)
extensions, which enable it to provide networked support for private numbering plans.
Backward Charging
SPIROU supports the ITX message (Message dimputation or Charge Unit message) and
the TXA message (Signal daccus de rception de taxation, or Charging
Acknowledgement message). The Backward Charging service allows a service provider
to send charging information backwards over the signalling system during the call to the
originating switch that performs the billing. This enables service providers to control the
billing of calls, e.g. to premium rate numbers.
CentrexIP
DPNSS [6]
PRI [4]
Implemen-
QSIG
INAP
tation
Country /
name Characteristics
Y
Australian ETSI ISUP V2 TDM Y [10] Y N Y Y Y Y N X N N Y N
ACIF I-ISUP variant
SIP-T Y Y Y N Y Y Y Y N X N N N N
TDM N Y Y Y Y Y
[11] [12] N Y [13] N N X N [14] N Y
Chinese ETSI ISUP V2
ISUP variant Y Y Y Y N Y
SIP-T [15] [15] [15] [12] Y [13] N N X N N N Y
TDM Y Y Y N N N Y N N X N N N N
V1 and V2
Czech ISUP
variants [16] SIP-T
[17] Y Y Y N N N Y N N X N N N N
CentrexIP
DPNSS [6]
PRI [4]
Implemen-
QSIG
INAP
tation
Country /
name Characteristics
Y Y
TDM Y Y Y [18] Y Y [19] Y Y N N Y Y Y
ETSI ISUP V2
(base / generic variant) Y Y
SIP-T Y Y Y [18] Y Y [20] Y Y N N Y Y Y
Y
TDM Y Y Y N N N [22] N N X N Y N N
Hong Kong ETSI ISUP V2
ISUP variant Y N
SIP-T Y Y Y N N N [22] N X N Y N N
V1 and V2 TDM Y Y Y N N N Y N N X N N N N
Italian ISUP
variants [27] SIP-T Y Y Y N N N Y N N X N N N N
CentrexIP
DPNSS [6]
PRI [4]
Implemen-
QSIG
INAP
tation
Country /
name Characteristics
TDM Y Y Y N N N Y N N X N N N Y
Telmex [29]
ISUP ETSI ISUP V1
(Mexico) [37] variant Y
SIP-T [29] Y Y N N N Y N N X N N N Y
Y Y
Telstra ETSI ISUP V2 TDM [38] [10] Y N Y Y Y N N X N Y N N
CA30 ISUP [38]
(Australia) variant
SIP-T Y Y Y N Y Y Y N N X N Y N N
[1] Entries in these columns refer to interworking with base/generic ETSI ISUP. Each variant of ETSI
ISUP V1 and V2 can be interworked to itself as well as to base/generic ETSI ISUP.
[2] CS2000 does not support a base/generic TUP call processing agent, but supports three national TUP
variants for China (CTUP), France (SSUTR2 / FTUP) and the UK (IUP / BTUP). Y appears in this
column for ISUP variants that can be interworked to one or more of these national TUP variants.
[3] When communicating with an MGC or gateway that does not provide ISUP payload in the SIP
message (e.g. MCS5200), CS2000 generates an IBN7 ISUP payload based on SIP message type and
content.
[4] CS2000 supports a base/generic call processing agent for ETSI PRI (30B+D). It also supports two
national 30B+D PRI variants for China and Spain, and three national 23B+D PRI variants for the USA
(ANSI PRI), Hong Kong (CR13) and Japan (INS1500). Entries in this column apply to support for
interworking between ISUP variants and base/generic ETSI PRI. Footnotes are used to indicate
whether interworking is supported for a national PRI variant as well as (or instead of) base/generic
ETSI PRI.
[5] The international implementation of H.323 is based on mapping H.225 connection control messages
(SETUP etc) on to their QSIG equivalents, with APDUs being conveyed transparently in Facility IEs in
QSIG messages. Support for H.323 basic call interworking means support for H.225 call
establishment, and does not imply support for the handling of non-call-related information over the
interworking. Basic call interworkings supported are therefore as for QSIG.
[6] CS2000 support for DPNSS is based on the international implementation of H.323 (see footnote [5]).
Between the GWC and the Westell DPNSS gateway, DPNSS signalling is encapsulated in
Westell-defined manufacturer-specific operations in the H450.1 SupplementaryService data field of a
H323 message. For communication between the GWC and the Core, the GWC performs mapping
between these operations and QSIG Facility IEs.
[7] For IBN lines supported by media gateways attached to customer LANs, ISUP interworking means
interworking between ISUP signalling and MGCP signalling.
[8] For IBN lines supported by media gateways served by cable access networks, ISUP interworking
means interworking between ISUP signalling and NCS signalling.
[9] For IBN lines supported by V5.2 media gateways, ISUP interworking means interworking between
ISUP signalling and V5.2 Layer 3 signalling backhauled to CS2000 over a V5UA/SCTP/IP protocol
stack, together with co-ordination between ISUP signalling and H.248 device/media control signalling.
[10]Interworking is also supported between TDM-side ACIF I-ISUP and TDM-side Telstra CA30 ISUP.
[11]For TDM-side Chinese ISUP over SIP-T, interworking is supported with TDM-side IBN7 ISUP, but not
with IBN7 ISUP over SIP-T.
[12]Interworking between Chinese ISUP and Chinese TUP (CTUP) is supported.
[13]PRI interworking for Chinese ISUP is supported with Chinese PRI (23B+D) as well as base/generic
ETSI PRI.
[14]Interworking verified only for Askey gateways.
[15]For Chinese ISUP over SIP-T, interworking is supported with ETSI ISUP and IBN7 ISUP over SIP-T,
but not with TDM-side ETSI ISUP or IBN7 ISUP.
[16]Czech ISUP V1 is supported on the TDM side and over SIP-T. Czech ISUP V2 is supported only over
SIP-T.
[17]Czech ISUP V2 over SIP-T interworks only with itself and with Czech ISUP V1 (TDM and SIP-T). The
entries in this row apply to interworkings for Czech ISUP V1 over SIP-T.
[18]Interworking is supported with all three national TUP variants: CTUP, SSUTR2 / FTUP and IUP /
BTUP.
[19]For TDM-side ETSI ISUP, interworking is supported with all national PRI variants except China.
[20]For ETSI ISUP over SIP-T, interworking is supported with all national PRI variants, including China.
[21]Interworking supported with base/generic ETSI ISUP V2, T-ISUP and G-ISUP, but not with German
ETSI ISUP V2.
[22]Interworking supported with Hong Kong PRI (CR13) as well as base/generic ETSI PRI.
[23]TDM-side IBN7 ISUP can be interworked to all supported PRI variants except those for China and
Japan.
[24]Functionality equivalent to SIP-T with an encapsulated IBN7 ISUP payload is provided by SIP DPTs
with no ISUP payload. This enables CS2000 to communicate with an MGC or gateway that does not
provide ISUP payload in SIP message (e.g. MCS5200), by generating an IBN7 ISUP payload based
on SIP message type and content.
[25]IBN7 ISUP over SIP-T can be interworked to all supported PRI variants except Chinese PRI.
[26]In addition to the standard national version of Israeli ISUP, CS2000 supports an ISDEFO-AVNET
variant of ETSI ISUP V2 for use in the Israel Defence Forces network. Supported interworkings for this
variant are as shown for Israeli ISUP.
[27]Italian ISUP V1 is the standard national interconnect interface; CS2000 supports Italian ISUP V2 for
intra-network support of regulatory services. Interworking between the two variants is not supported.
Otherwise, supported interworkings are the same for both variants.
[28]Although it is defined as a variant of ETSI ISUP V1, Malaysian ISUP is implemented on CS2000 using
the AISUP agent.
[29]Interworking between Mexican ISUP and Telmex ISUP is also supported, except for interworking
between the two SIP-T implementations.
[30]For Portuguese ISUP, interworking is supported with Spanish PRI as well as base/generic ETSI PRI.
[31]V1 and V2 variants are both in use in the national network. CS2000 can support either variant for a
given trunk group, depending on the variant supported by the far-end switch. Supported interworkings
are the same for both variants except where explicitly stated otherwise.
[32]Interworking between the two variants of Spanish ISUP is also supported, but only between the
TDM-side implementation of one and the SIP-T implementation of the other.
[33]For Spanish ISUP, interworking is supported with Spanish PRI as well as base/generic ETSI PRI.
[34]Interworking with QSIG supported only for Spanish ISUP V1, not Spanish ISUP V2.
[35]CS2000 supports two national variants of ETSI ISUP V3, but does not support a base/generic V3 call
processing agent.
[36]Swedish ISUP is defined as a variant of ETSI ISUP V1, but is implemented on CS2000 as a variant of
ETSI ISUP V2.
[37]Telmex ISUP is implemented on CS2000 as a sub-variant of Mexican ISUP (NOM112) rather than an
ISUP variant in its own right.
[38]For TDM-side Telstra CA30 ISUP, interworking is supported only with ETSI ISUP over SIP-T, not with
TDM-side ETSI ISUP.
[39]Interworking between Turkish ISUP V1 and Turkish ISUP V2 is also supported, except for interworking
between the two SIP-T implementations.
[40]Interworking between UK ISUP and IUP/BTUP is supported.
[41]FGD ISUP trunks are implemented on CS2000 as IBN7 ISUP trunks, with the handling of
FGD-specific parameters controlled via datafill in tables TRKOPTS and ISPARM.
E2.4.1.1 Variants
The UK Interconnect User Part (IUP) is a publicly owned version of the British Telephony
User Part (BTUP) that is being standardised by a committee under the control of Oftel. It
is intended to supersede BTUP as the UK national CCS7 standard for inter-network and
intra-network connections between switches.
The committee to which the IUP working party reports is known as PNO/ISC (the Public
Network Operators/Interconnect Standards Committee). The IUP specification is known
as PNO/ISC/SPEC006. It is a replacement for BTNR 167, which defines BTUP. It is not
yet complete, but section 2 (Message Types and Contents) and section 3 (Common
Procedures), which are available, provide a complete specification of basic call.
Two versions of IUP/BTUP are currently in general use in the UK:
! BTUP Version 3 (1987), the version to which IUP corresponds
Supports supplementary and network services, including delivery of CLI in
IAM/IFAM; also supports Nodal End-to-End (NEED) messaging used for BES and
VPN applications (similar to DPNSS Feature Transparency).
! BTUP Version 2 (1985)
Supports delivery of CLI on request.
BTUP Version 2 can currently be regarded as the lowest common denominator for CCS7
signalling between different networks and different types of switch. It has been largely
superseded by IUP / BTUP Version 3.
Table TRKSGRP identifies trunks using the BTUP agent by means of a signalling type of
TUP and an external protocol of BTUP. The CS2000 BTUP agent supports two variants
of IUP/BTUP, which are known within Nortel as BTUP V2 and V2+. A switch will use
only one variant for the outgoing calls that it originates, as specified in the office
parameter BTUP_VER_IND in table OFCENG. For transit calls, the CS2000 uses the
same BTUP variant on the outgoing call leg as is used on the incoming leg.
Message Support
IUP/BTUP uses the H1H0 method of classifying mssages and assigning message header
codes, i.e. messages are grouped by message type (H0) with each message having a
unique identifier (H1) within that message type. The message types defined are shown in
the matrix below. CS2000 support for each message is summarised following the matrix.
H1
Message Group 0000 0001 0010 0011 0100 0101 0110 0111 1010 1011 1100 1101
H0
Forward Address
0000 IAM IFAM SAM FAM
Messages (FAM)
Forward Setup Messages
0001 ASI
(FSM)
Backward Setup Request
0010 SND SAD SASI
Messages (BSRM)
Backward Setup Info
0011 ACM CGN TCM CNA RA SEM SOO CDB
Messages (BSIM)
Call Supervision
Messages (CSM) 0100 ANS CLR RAN REL CFC OOR HLR EXC
Circuit Supervision
0101 CCTF BLO UBL BLA UBA OLM
Messages (CCM)
Service Information
0111 CFN ICSI SSM SRV ACI OCM UUD SWAP # UIS UIR
Messages (SIM)
Ringing Physical
tone ACM (Address Complete Message) ringing
Audible ringing in-band
Called party
ANS (Answer Message) answers
Speech path through-connected
Call in progress
REL (Release message)
Caller goes
on-hook to REL (Release message)
terminate call
Figure 97: IUP / BTUP messaging for call setup and clearing
E2.4.2.1 Variants
The French Telephony User Part (FTUP) is the French national variant of CCS7 TUP as
defined in ITU-T Recommendation Q.723. It is also referred to as SSUTR2, and is
formally defined in the following specification:
Specification du Sous-systeme Utilisateur SSUTR2
Functional Step VN4
ST/PAA/CER/SCS/2600
FTUP/SSUTR2 is the French national CCS7 standard for connecting central office
switches within the national PSTN and for interconnect between different network
operators in France.
Table TRKSGRP specifies the characteristics of trunks using FTUP signalling as
signalling type C7UP, external protocol Q767, version 100_BLUE and variant FRANCE.
Message Support
FTUP uses the H1H0 method of classifying mssages and assigning message header codes,
i.e. messages are grouped by message type (H0) with each message having a unique
identifier (H1) within that message type. CS2000 support for FTUP/SSUTR2 message
types is summarised by the matrix below. In cases, where the French acronym differs from
the English acronym, the French acronym is shown in parentheses below the English one.
Message Group H1
0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1100
[FTUP abbrev.] H0 [1]
Call Charging
0000 CHT [2] ITX [2] TXA [2]
Messages [MT]
Forward Address SAM SAO
Messages [AD] 0001 (MSA) (MSS)
Forward Setup GSM [3] COT CCF
Messages [EA] 0010
(IFG) (CCP) (CCN)
Backward Setup [3]
Request Messages 0011 GRQ
(DEG)
[DE]
Successful Setup CHG [4]
Messages, 0100
Backward [SE] (TAX)
Unsuccessful SEC CGC NNC CFL SSB UNN LOS SST ACB MPR
Setup Messages, 0101
Backward [EE] (EEC) (EFC) (ERN) (ECH) (OCC) (NNU) (LHS) (TSI) (ACI) (INU)
Call Supervision 0110 RAN
Messages [SA] (NRP)
Circuit Group RLG UBL UBA CCR RSC
Supervision 0111 BLO BLA
Messages [SC] (LIG) (DBO) (DBA) (CCD) (RZC)
Network
Supervision 1000 GRS GRA
(RZG) (RZA)
Messages [SG]
End-to-end
1011 MUU [5] MCE [5]
messages [MB]
National Bward
Setup Successful 1100 ACF
Messages [EN]
National IAM for 1101 MIF
ISDN [ET]
National Bward
Setup Failure 1110 SND EAR
Messages [EC]
National Call
Supervision 1111 RIU RAU FIU
Messages [SN]
[1] No messages are defined for H0 = 1001 (9) or H0 = 1010 (10 / hex A).
[2] The CS2000 will acknowledge receipt of a CHT or ITX message by sending a TXA, but the information
contained in the ITX or CHT message will not be included in the AMA record.
[3] In response to a GRQ message, CS2000 sends a GSM message indicating that the requested information is not
available. CS2000 will never send a GRQ message.
[4] Charging information provided in CHG message is not included in the AMA record.
[5] Not supported by CS2000, i.e. the information is not transited end-to-end.
Call in progress
RLG
Call clearing can also be initiated as a result of the called party going on-hook, which
causes an RAU (Clear Back) message to be sent back. Possible variations are:
! ISDN called party
FIU sent forward immediately on receipt of RAU.
FIU acknowledged by backward RLG(LIG).
! Analogue called party (national call)
FIU sent forward 3 seconds after receipt of RAU.
FIU acknowledged by backward RLG(LIG).
! Analogue called party (international call)
FIU sent forward 60 seconds after receipt of RAU (delay determined by T6).
FIU acknowledged by backward RLG(LIG).
H1
Message Group 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011
H0
UBM 0101 SEC CGC ADI CFL UNN LOS SST ACB DPN
GRM 1000 MGB MBA MGU MUA HGB HBA HGU HUA GRS GRA
to the distribution function for transfer up to the appropriate user part for
interpretation, e.g. directly to ISUP or TUP, or via the SCCP to TCAP.
" Message routing
The routing function ensures that each outgoing message has the routing
information it needs to reach its destination, then passes it down to Level 2 to be
packaged into a signal unit ready for transmission.
Note: MTP Level 3 Signalling traffic generated at a given node, such as
network management, test and maintenance messages, is also delivered to the
routing function for outward transfer.
SCCP is involved if global title translation is required or in the case of requests for
circuit-independent services. MTP Level 3 and SCCP together are known as the
Network Service Part (NSP).
MTP Level 3 is also responsible for routeset management and linkset management
functions, which detect problems, minimise their impact on the network, and take
appropriate recovery action.
In ISN07, two alternative CS2000 signalling gateway peripherals are available to
terminate TDM-side CCS7 signalling:
USP Universal Signalling Point
TDM-side CCS7 user part messaging terminates on CCS7 link system nodes
in the USP, and the USP distributes messages to the CS2000 Core over the CS
LAN via a CCS7 / M3UA / SCTP / IP protocol stack. In CCS7 terms, the Core
and the USP share the same point code. As far as Core-resident CCS7 user
parts such as ISUP are concerned, M3UA allows messages to be sent and
received exactly as if MTP Layers 1-3 were in use, i.e. the user parts are not
aware that the USP is a separate LAN node.
FLPP Fiberised Link Peripheral Processor
TDM-side CCS7 user part messaging terminates on LIU7s (Link Interface
Units) in FLPP shelves, and the FLPP uses proprietary signalling to convey
messages to XA-Core via the MS.
TDM-side MTP functions are distributed between CS2000 components as follows:
! If the USP is used for CCS7 support, MTP functions are distributed as follows:
" Level 1 and Level 2 functions are provided in the USP by a CCS7 link system
node.
" Level 3 functions are divided between the USP and the Core. All message
handling functions (discrimination, distribution and routing) and some linkset
management functions are supported by the USP. Routeset management
functions and most linkset management functions are provided by the Core.
! If the FLPP is used for CCS7 support, MTP functions are distributed as follows:
" Level 1 functions are provided in the FLPP by a V.35 paddleboard.
" Level 2 functions are provided by the LIU7 in the FLPP.
" Level 3 functions are divided between the LPP and XA-Core. All message
handling functions (discrimination, distribution and routing) and some linkset
management functions are supported by the FLPP. Routeset management
functions and most linkset management functions are provided by XA-Core.
MTP routing capabilities are based on the use of point codes. Each node in a CCS7
signalling network is uniquely identified by means of such a point code. The MTP routing
label of every CCS7 message contains the Originating Point Code (OPC) of the sending
node and the Destination Point Code (DPC) of the receiving node. The Service
Information Octet (SIO) in the MTP routing label contains a 2-bit Network Indicator (NI).
This defines four types of point code domain:
00 International network
01 Spare (for international use only)
10 National network
11 Reserved for national use
CCS7 signalling points (nodes) can exchange MTP Message Signal Units (MSUs) only if
the nodes have different point codes and belong to the same point code domain.
CS2000 supports the MPC (Multiple Point Code) capability, which allows a node to be
assigned up to 31 point codes, which may be all in a single domain or distributed betwen
the four domains. This makes it possible for a CS2000 belonging to a network operator
may also handle traffic for one or more capacity resellers. Assigning a different point code
for each supported reseller allows a single switch to provide several logical Points Of
Interconnect (PoIs).
Typically, a CS2000 belongs to a national public network under the control of a regulator.
Its point code in this network, which corresponds to the point code domain with NI = 10
(national) is assigned by the regulator. Use of point codes in the other point code domains
is typically not regulated. This can include point codes in the domain with NI = 00
(international), which is regulated only for switches used as gateways to the international
public network.
Point code information is datafilled in the following tables:
! Table C7NETWRK
This lists the network appearances supported by the switch, where a network
appearance is defined in one of the four NI-defined point code domains. Up to 16
entries can be defined, with any combination of NI and network types. For each
one, the table defines the network type (CCITT7 or ANSI7 [1]), and specifies the
point code used to identify this node within that network.
Note: The format of the point code specified in C7NETWRK depends on the
network type. ITU identifies signalling points (nodes) by means of 14-bit point
codes in the routing label, while ANSI uses 3-octet / 24-bit point codes. For ITU
point codes, several point code formats are available for interpreting the 14-bit field
(BASIC, INTL, AUSTRIA, CHINA, or GERMAN), but these formats are used only
for point code entry and display. Routing is always performed using all 14 bits.
! Table C7RTESET
This table define two types of mapping for route set names, as obtained from table
ISUPDEST:
" Maps route set on to destination point code.
" Associates route set with network name as defined in table C7NETWRK, thus
making originating point code information available.
[1] Three other network types (NTC7, JPN7 and TTC7) have been defined for use in Japan, but these are not
expected to be used in ISN07.
! Table ISUPDEST
This maps trunk groups on to the route sets used to convey the CCS7 signalling for
those trunk groups.
Figure 99 shows how point code information is obtained from these tables and used to
create the routing label for an outgoing TDM-side message.
Table ISUPDEST
Trunk
group Trunk group CLLI
selected
Route set name
Outgoing message
DPC OPC NI
Table C7RTESET
Route set name
Network name
Destination point code
Table C7NETWRK
Network name
Own NI and point code
For each incoming message, the USP or FLPP on the CS2000 compares the DPC of the
message with the point code datafilled in C7NETWRK for the network (point code
domain) in question to decide whether the MSU is destined for the CS2000.
CS2000 compliance with North American MTP standards is defined in the PLS
documents TR82COMP and TR24COMP (these being the numbers of the relevant
Bellcore requirements). CS2000 compliance with ITU-T Recommendations Q.701 to
Q.710 on the MTP is fully documented in Nortel Technical Letter TL96-0026, which is
available in PLS FMDOC under the name MTPCOMP. PLS is an internal Nortel library
and cannot be directly accessed by customers, but documents from it can be made
available in response to customer requests provided that a non-disclosure agreement is in
place.
Invoke, Variable-length
ITU-T TCAP BEGIN, CONTINUE, END, ABORT Return Result,
Return Error, Reject numbers
which a given call requires IN service access. Because it interacts closely with the
SSF, the CCF resides with the SSF in an SSP node.
Another node type involved in handling IN is the STP (Signalling Transfer Point). No IN
functions are allocated to STPs, but IN traffic between SSPs and SCPs may be relayed via
STPs. Figure 100 illustrates IN node types and functional elements.
IN SCP SCP
SCF SCF
PSTN
Note: The integrated IP is a separate node, not a CS2000 component, but this is not visible to the
SCP. Packetised announcements are provided across the packet network by the MS2000 or UAS,
which is an independent media server, but from the perspective of the SCP all INAP operations
intended for the integrated IP are sent to and handled by the CS2000 SSP. When the SCP issues
instructions for the integrated IP to collect digits, in-band digit collection (supported only over ISUP
and PRI in ISN07) is performed by the originating media gateway.
Figure 100: CCS7 Node Types and IN Functional Elements
In addition to standard CS-1R INAP, the CS2000 SSP supports a number of national
INAP variants. These are typically distinguished by having different requirements for
network-specific operations such as ApplyChargingReport, which can be used by the
SCP to control the billing performed by the SSP. The INAP variant in use on a given
CS2000 is determined by OFCENG parameter INAP_VARIANT, which can be set to
DFLTINAP (the default), CHINESE, TELEFONICA (Spain), TINAP (German) or
INDIAN.
H.248. For a tone, a request to the appropriate media gateway is made via a
device-media control protocol such as ASPEN.
When the SCP issues instructions for the integrated IP to collect digits, in-band digit
collection (supported only over ISUP and PRI in ISN07) is performed by the
originating media gateway.
! External IP
SRF functionality provided by a completely separate TDM-side node. The CS2000
SSP first uses PRI, ETSI ISUP, IBN7 or BTUP to establish a connection with the
external IP. INAP operations are then exchanged directly by the SCF and SRF, with
no SSP involvement.
Figure 101 illustrates the protocol stack used for peer-to-peer communication between IN
functions on different nodes.
SSP SCP
Logical peer-to-peer
OSI Layers SSF protocol stack communication SCF protocol stack
INAP INAP
Intelligent Network Intelligent Network
Application Part INAP operations Application Part
Layer 6
Presentation
Layer 5
Session
Layer 4
Transport
SCCP SCCP
Layer 3 Signalling Connection Signalling Connection
Control Part SCCP UNITDATA messages Control Part
Network
IN signalling link
Figure 102 provides an overview of triggering and query handling for the simplest type
of query (single-stage call setup triggered on full CdPA).
Called party
Onward Digit manipulation
routing via CS2000
translations
In ISN07, IN triggering via the O_BCSM is supported for the following types of call
origination:
! Incoming ISUP and TUP calls (TDM-side and SIP-T)
! Incoming PRI and QSIG calls
! Incoming calls from analogue lines
IN triggering via the T_BCSM is supported for calls terminating on analogue lines.
SCP
SCF
INAP operations
SSF
(SSF FSM) CS2000 SSP
INAP
interworking
CCF
(O_BCSM)
Figure 103: Basic IN triggering and call handling for call originations
Points to note:
! Call processing for call originations is modelled using the O_BCSM.
! Information about leg 2 of a call is obtained via the basic call interworking, and
provided to the SSF via the O_BCSM.
! The controlling leg of the call is the leg on which IN triggering took place, i.e. the
leg back to the caller.
SCP
SCF
INAP operations
SSF
(SSF FSM)
CS2000 SSP
INAP
interworking
CCF
(T_BCSM)
Points to note:
! Call processing for call terminations is modelled using the T_BCSM.
! Information about leg 1 of a call is obtained via the basic call interworking, and
provided to the SSF via the T_BCSM.
! The controlling leg of the call is the leg on which IN triggering took place, i.e. the
leg to the called party.
Note: If IN processing results in the onward routing of a call, the T_BCSM for the
original destination reverts to being an O_BCSM associated with the call origination.
Call Clearing
When the SCF processes an IN query initiated by InitialDP, it may decide that that the call
cannot or should not be completed. In this case, it sends a ReleaseCall operation instead
of a Connect, which causes the SSP to clear the call.
Billing
AMA base records and appended modules are used as follows for IN calls:
! The x051x base AMA record stores the called party number as modified/provided
by Connect.
! An appended module stores the digits dialled by the calling party. The type of
module to be appended is determined by service datafill, typically on the basis of
the number of dialled digits to be stored: type 28 module (up to 15 digits), type 40
module (up to 24 digits), or type 612 module (up to 30 digits).
! An appended type 611 module can store an IN billing correlation ID to enable
different billing records for an IN call connected to a sequence of terminations
(follow-on calls) to be correlated.
! Up to 200 bytes of billing data conveyed in one or more
FurnishChargingInformation (FCI) operations can be stored in type 199
modules appended to the base record. Each type 199 module can contain up to 20
bytes of billing data, and up to ten type 199 modules can be appended to an AMA
record. There is a proprietary Nortel-defined format for billing information
provided in an FCI operation, but the CS2000 SSP will also accept FCI billing
information in any required third-party format (in which case the data is simply
repackaged and relayed).
The CS2000 SSP also supports the use of the SendChargingInformation (SCI)
operation, which is sent by the SCP to the SSP to tell it to provide information to be used
in billing a specified call leg. The charging information provided by the SCP can be either
a charge band to be included in an ISUP message or an instruction that a certain number
of metering pulses should be generated. Support for the SCI operation is a generic INAP
capability, but was initially implemented by ISN07 feature A00004934 to meet
India-specific charging requirements for IN calls.
The CS2000 SSP also supports operations that allows the SCP to provide billing
instructions and be informed of the charges actually applied:
! ApplyCharging (AC)
Sent from the SCF to the SSF to provide billing instructions for a given IN call.
Can also be used to specify a maximum conversation time, e.g. if only a limited
amount is left on a calling card. This causes the SSP to play a warning tone or
announcement before the timer expires.
! ApplyChargingReport (ACR)
Sent from the SSF to the SCF to provide information about the AC-specified
charges applied to that call.
Note: The CS-1R INAP specification does not specify the information to be requested
via ApplyCharging and provided via ApplyChargingReport. The ApplyCharging formats
and behaviour to be supported in a given network are specified by the regulator or the
network operator. CS2000 supports a range of ApplyCharging formats to meet the
requirements of a range of national markets.
E3.2.1.2 Two-Stage Call Setup Operations (In-Band Interaction with the Caller)
Operations sent by the SCF to initiate and control direct in-band interaction between the
calling party and the SRF, typically the playing of a tone or announcement. There are
three stages:
1 Setting up the connection between the SRF and the user
" ConnectToResource (connect to integrated IP / originating media gateway)
" EstablishTemporaryConnection (connect to external IP via PRI, ETSI
ISUP, IBN7 or BTUP)
2 SCF-controlled user interaction (operations handled by CS2000 only for user
interaction via the integrated IP)
" PlayAnnouncement (play specified tone or announcement), optionally
followed by SpecializedResourceReport when tone/announcement has been
played.
CS2000 can convert Price data specified by the SCP in a PA operation into
MCMP Money data to be conveyed from the audio GWC to the UAS via
H.248. This enables CS2000 to provide language and currency tokens for use
in assembling complex/variable announcements. See A19012479.
" PromptAndCollectUserInformation (play specified tone or announcement
and collect digits), followed by ReturnResult(P&C) to return collected digits
Note: Digit collection is supported only for ISUP and PRI call originations.
Integrated IP functionality is provided by separate packet network nodes, not by
CS2000 components, but this is not visible to the SCP. Responsibilities are:
" Tones are played by the appropriate media gateway
" Announcements are played by the UAS
" Digits are collected by the originating media gateway.
When the CS2000 SSF receives a PA or P&CUI operation from the SCP, it initiates
a non-IN request to the UAS for an announcement to be played. After a PA, it can
send a SpecialisedResourceReport operation back to the SCP to report that the
announcement has been played. After a P&CUI, it sends a Return Result to provide
the dialled DTMF digits collected by the originating media gateway.
The CS2000 SSP supports the use of the Cancel operation, which the SCP can use
to request the SSP to cancel a specified outstanding PA or P&CUI request. This is
a generic INAP capability, but was initially implemented by ISN07 feature
A00004934 to meet Indian requirements.
3 Taking down the connection between the SRF and the user
" DisconnectForwardConnection
Note: The DMS SSP also supports SRF-initiated disconnect, in which the SRF
notifies the SSF when user interaction has finished, and there is no need for an
explicit DFC operation from the SCF.
If required, the CS2000 SSP can create or update a billing record for the part of a call when
user interaction takes place.
Figure 105 provides a functional view of the handling of a two-segment IN call at the
CS2000 SSP, showing the interactions between the software entities involved.
SCP
SCF
INAP
operations
Target SSF FSM for INAP
operations from SCP is
determined by legID or
csID parameter
CSA
Two SSF FSMs,
one for each SSF FSM SSF FSM CS2000 SSP
call segment
Second SSF FSM and
O_BCSM created when INAP INAP
leg is split off from interworking interworking
stable call
Terminating
Two O_BCSMs, Leg 3 of call
one for each O_BCSM O_BCSM
agent
(added later)
call segment
Basic call
interworking
The CS2000 SSP supports Call Party Handling capabilities in the following ways:
! By recognising a # or * dialled by the caller as an interrupt signal (this is
implemented by using RequestReportBCSMEvent to request monitoring for an
O_Mid_Call event).
! By supporting three CS-2 CPH operations that explicitly control the connectivity of
a call:
" SplitLeg
Tells the SSF to detach one call party from an existing call into a new, separate
call segment.
" MergeCallSegments
Tells the SSF to combine two call segments into a single call.
" DisconnectLeg
Tells the SSF to disconnect a specified call party from a call, leaving the call
to continue with the other parties involved.
" CreateCallSegmentAssociation
Sent from the SCF to the SSF to a create a new, null CSA in which an
SCP-initiated call attempt can be set up.
" InitiateCallAttempt
Sent from the SCF to the SSF to initiate a new call instance, either in a newly
created null CSA or within the context of an existing call (typically to verify
that an IN call can be successfully completed before the caller is connected to
the destination).
! By allowing other operations to specify a legID and/or csID parameter to indicate
which leg or segment is to be affected by the operation.
! By supporting CS-2 variants of operations whose CS-1R variants do not allow a
legID or csID parameter to be specified. There are two of these:
" DFCWithArgument (DFCWA)
Tells the SSF to disconnect the SRF connection for a call segment.
" ContinueWithArgument (CWA)
Tells the SSF to resume normal call processing for a call segment.
Table 37: CS2000 SSP support for O_BCSM and T_BCSM DPs
Can be detected / reported via
Call processing event
O_BCSM DP T_BCSM DP
Trigger Detection Points (TDPs) used to initiate IN interaction
Dialled digits available TDP-2
(Collected_Info)
TDP-3
Translated digits available
(Analyzed_Info)
No route available TDP-4
(e.g. network congestion) (Route_Select_Failure)
Call termination authorised TDP-12
(Term_Attempt_Authorized)
Event Detection Points (TDPs) used to detect and report monitored events
EDP-2
Dialled digits available (Collected_Info)
No route available EDP-4
(e.g. network congestion) (Route_Select_Failure)
EDP-13
EDP-5
Called party found to be busy (O_Busy) (T_Busy)
Not supported in ISN07
EDP-14
EDP-6
No answer from called party (T_No_Answer)
(O_No_Answer)
Not supported in ISN07
EDP-7 EDP15
Called party answers (T_Answer)
(O_Answer)
Not supported in ISN07
EDP-16
Call party interrupts EDP-8
(T_Mid_Call)
active call (O_Mid_Call)
Not supported in ISN07
EDP-17
Call party disconnects EDP-9
after call is answered (O_Disconnect) (T_Disconnect)
Not supported in ISN07
EDP-18
Caller hangs up EDP-10
(T_Abandon)
before call is answered (O_Abandon) Not supported in ISN07
Arming of EDPs
EDPs are set up (dynamically armed) in response to a request from the SCF. The request
is made via an RequestReportBCSMEvent operation specifying:
! One of two monitoring modes:
" NotifyAndContinue
This causes the EDP to be armed as an EDP-N, i.e. call processing will
continue after the SCF has been notified that the event has taken place.
" Interrupted
This causes the EDP to be armed as an EDP-R, i.e. call processing will await
further instructions from the SCF (e.g. connect to alternative number) after it
has been notified that the event has taken place.
! The call leg for which the EDP is to be armed, which is one of:
" The controlling leg, typically the call leg back to the caller (leg 1)
" The passive leg, typically the call leg to the called party (leg 2)
OSI Layers
CS2000 SSP SCP
CCF protocol stack SSF/SRF protocol stack SCF protocol stack
INAP INAP
Intelligent Network Intelligent Network
Layer 7 Application Part Application Part
Application
TCAP TCAP
ETSI ISUP Transaction Capabilities Transaction Capabilities
ISDN Application Part Application Part
Layer 6 User Part
Presentation
Layer 5
Session
Layer 4
Transport
SCCP SCCP
Layer 3 Signalling Connection Signalling Connection
Network Control Part Control Part
Layer 2 MTP
Datalink MTP Message Transfer
Message Transfer Part Part
Layer 1
Physical
IN queries can be triggered via the O_BCSM for incoming calls over the following
interfaces:
! ETSI ISUP (V1 and V2), including most national ETSI ISUP variants
! IBN7 / ANSI ISUP+
! UK ISUP
! SPIROU (French ISUP)
! Australian ISUP variants (ACIF I-ISUP and Telstra CA30)
! BTUP
! SSUTR2 / FTUP
! ISDN PRI
! QSIG
! Analogue subscriber lines
Note: Triggering is supported for call attempts initiated by features such as RAG.
Triggering is also supported for features that allow a multi-leg call, e.g. CFwd and
3WC, provided that any existing IN dialogue is taken down first.
IN queries can also be triggered via the T_BCSM for calls terminating on analogue
subscriber lines.
With effect from ISN07, CS2000 offers a choice of gateway types for supporting PRI
access to the packet network:
! Packet Voice Gateway (PVG) described in section B2.3 on page 99
! Audiocodes Mediant 2000 gateway described in section B2.6 on page 116
Functionally, both types of gateway support ISDN PRI in the same way, as illustrated in
Figure 107 on page 445. The differences between them are to do with capacity and
deployment options rather than functionality, as follows:
! The PVG is a high-capacity gateway that is typically owned and operated by the
operating company and located on telco premises.
! The Mediant 2000 is a compact gateway that is typically owned and operated by an
enterprise and located on customer premises. It is designed to provide cost-effective
support for remote deployment of a relatively small number of PRI-enabled PBXs
PRI is an asymmetrical interface, i.e. the protocol and procedures defined for the local
exchange (CS2000 gateway) end of the interface are not identical to those defined for the
PBX end of the interface. Typically, a Communication Server such as CS2000 supports
PRI in network or master mode, while the PBX supports it in user or slave mode.
The ETSI PRI specifications listed in section E4.1.3 always use the terms sending and
receiving from the viewpoint of the PBX. Overlap sending, for example, means overlap
signalling from the PBX to the gateway; overlap receiving means overlap signalling from
the gateway to the PBX. Nortel documentation, however, uses the terms inpulsing and
outpulsing from the perspective of the gateway. Overlap inpulsing is therefore equivalent
to ETSI overlap sending , and overlap outpulsing is equivalent to ETSI overlap receiving.
E4.1.3 Specifications
ANSI PRI
ANSI PRI is a 23B+D interface supported over 1.5Mb/s T1 carriers. It is defined in ANSI
specification T1.607 (1990).
The ANSI PRI protocol supports only en-bloc sending and receiving of called party digits.
It does not support overlap sending or receiving.
GWC CS2000
User User
phones phones
and and
terminals terminals
PRI(T) ASPEN SIP-T ASPEN PRI(T)
access CCS7 access
Gateway
Gateway
A bearer service or bearer capability provides a particular type of link between two points, e.g.
speech or unrestricted data; bearer capabilities must be compatible between end points
ISDN signalling
36 6 9 10 38b 18 31
37 28 26 Inter-CS signalling 23 20
29 38a (CCS7 signalling 24 21
Two types of encapsulated in SIP-T) 25 Two types of
signalling: signalling:
Media control Media control
via H.248 via H.248
Call control via Call control via
PRI/IUA/SCTP PRI/IUA/SCTP
Packet network
2 7 (ATM or IP) 19
Originating Terminating
Gateway Gateway
Bearer connection
(packetised voice)
Note: The messaging description below reflects two assumptions about protocol usage:
! It is assumed that the protocol used for device/media control signalling betwen
GWCs and PVGs is H.248. ASPEN continues to be supported as an alternative to
H.248 for trunk gateway control, but use of H.248 is recommended.
! It is assumed that the Session Server rather than a GWC configured as a VRDN is
used to terminate inter-CS packet network connections in the inter-CS part of the
call flow illustrated in Figure 109 on page 451. This implies that the Session Server
provides all SIP functionality, and that TCP rather than UDP is used as the inter-CS
transport protocol. See section D2.2: CS2000 Support for Dynamic Packet
Trunks on page 244 for further information.
1 Q.931 SETUP message for incoming call arrives at originating gateway
2 SETUP for incoming call encapsulated using IUA / SCTP and conveyed to GWC
3 Ingress GWC processes SETUP and sends it on to the CS2000 Core.
CS2000 Core call processing uses SETUP to:
- Perform translations and routing, resulting in the selection of an outgoing trunk
group to another CS2000
- Select a DPT (Dynamic Packet Trunk) from the pool supported by DPT GWCs
4 - Allocate the selected DPT for the duration of the call
The DPT GWC selects a trunk profile on the basis of the CCS7 protocol to be used and
the destination hostname, and passes the telephony profile index to the Core.
See Figure 13 on page 62 for an illustration of how DPT GWCs interact with the
Session Server to support DPTs for inter-CS communication.
5a CS2000 Core sends FCM (Fabric Control Message) to ingress and egress GWCs to
5b enable direct communication between them
Ingress access GWC sends H.248 Add commands to originating media gateway to
establish mapping between TDM-side and packet-side terminations. First Add
6 command identifies TDM-side trunk and requests gateway to add it to a newly created
context. Second Add command asks gateway to reserve logical packet-side
termination in receive-only mode and add it to the same context.
Media gateway response to second Add command provides GWC with endpoint
7
identifier (IP address) to use for logical termination, together with SDP description of
bearer capabilities supported (for use in codec negotiation with the gateway serving
the remote endpoint).
8
Ingress access GWC passes gateway IP address and SDP session description to
egress DPT GWC
Egress DPT GWC assembles outgoing IAM and forwards IAM to egress Session
Server. Egress Session Server encapsulates IAM in SIP-T INVITE message, together
9 with SDP session description including IP address of originating media gateway
endpoint; egress Session Server then sends INVITE message to Session Server on
terminating CS2000
10
Ingress Session Server on terminating CS2000 immediately acknowledges INVITE
message by sending back a SIP-T 100 TRYING message with no payload
Ingress Session Server selects an ingress DPT GWC that has an available DPT and
11
provides it with trunk profile information derived from the INVITE message.
See Figure 13 on page 63 for an illustration of how the Session Server and DPT GWCs
interact to support DPTs for inter-CS communication.
12
Ingress DPT GWC allocates selected DPT for the duration of the call and defines its
protocol characteristics in accordance with trunk profile from INVITE message.
13
Ingress Session Server forwards IAM extracted from INVITE message to selected DPT
on ingress DPT GWC
14
Ingress DPT GWC forwards IAM to CS2000 Core, requesting it to initiate call
processing
15
CS2000 Core uses IAM to perform translations and routing, and identifies the egress
access GWC and gateway serving the destination
16a CS2000 Core sends FCM to ingress and egress GWCs to enable direct
16b communication between them
17
Ingress DPT GWC passes originating gateway IP address and SDP session
description to egress access GWC
Egress access GWC sends H.248 Add commands to terminating media gateway to
establish mapping between TDM-side and packet-side terminations. First Add
18 command identifies TDM-side trunk identified via translations and routing, and
requests gateway to add it to a newly created context. Second Add command asks
gateway to reserve logical packet-side termination and add it to the same context.
Media gateway response to second Add command provides GWC with endpoint
19
identifier (IP address) to use for logical termination, together with SDP description of
bearer capabilities supported (for use in codec negotiation with the originating media
gateway serving the originating endpoint).
20
Outgoing SETUP created, encapsulated using IUA / SCTP, and sent out by terminating
GWC
21 Backward ALERTING (encapsulated using IUA) received by terminating egress GWC
CS2000 Core receives the ALERTING as a progress message and passes an ACM to
22
ingress DPT GWC on terminating CS2000 (directly or via the Core, depending on
CCS7 protocol types involved); ingress DPT GWC forwards ACM to ingress Session
Server
23
Ingress Session Server encapsulates outgoing ACM in a backward SIP-T 183
SESSION PROGRESS message, then sends message to originating CS2000
24
Ingress DPT GWC sends ingress Session Server a request for ringback tone to be
applied to originating TDM-side trunk.
25
Ingress Session Server conveys ringback tone request to originating CS2000 by
means of a backward SIP-T 180 RINGING message
Egress Session Server on originating CS2000 terminates SESSION PROGRESS and
26 RINGING messages, extracting backward ACM from SESSION PROGRESS
message and forwarding it to egress DPT GWC
27
Egress DPT GWC on originating CS2000 passes a message to the Core, which in turn
passes an ALERTING message to the ingress access GWC
28
Ingress GWC encapsulates ALERTING message using IUA/SCTP and sends it to
originating gateway
29
Ingress access GWC sends H.248 Modify message to originating media gateway,
asking gateway to apply ringback tone to originating TDM-side trunk
30 Backward CONNECT (encapsulated using IUA) received by terminating egress GWC
31
Egress access GWC sends H.248 Modify message to terminating media gateway,
asking gateway to place the bearer connection in full duplex mode
CS2000 Core receives the CONNECT as a progress message and passes an ANM tto
ingress DPT GWC on terminating CS2000 (directly or via the Core, depending on
32 CCS7 protocol types involved); ingress DPT GWC forwards ANM to ingress Session
Server, together with SDP description of bearer capabilities supported by terminating
media gateway endpoint
33
Ingress Session Server encapsulates outgoing ANM and associated SDP in a
backward SIP-T 200 OK message, then sends message to originating CS2000
34
Egress Session Server on originating CS2000 extracts ANM from SIP-T message and
forwards it to egress DPT GWC
35
Egress DPT GWC on originating CS2000 passes ANM to the Core, which in turn
passes a CONNECT message to the ingress access GWC
Ingress access GWC sends H.248 Modify message to originating media gateway,
36 completing codec negotiation process and asking gateway to remove ringback tone
and place the bearer connection in full duplex mode
Ingress GWC sends PRI CONNECT message (encapsulated using IUA / SCTP) to
37 originating gateway, thus completing call setup for the packet network bearer
connection between the two access gateways
Forward SIP-T ACK message originated by egress Session Server on originating
38a
38b CS2000 to confirm receipt of final response to the original INVITE message, then sent
to ingress Session Server on terminating CS2000 to complete three-way handshake
E4.2.3 Datafill
Signalling links for ISDN PRI are provisioned using table TRKSGRP, as used to define
the signalling characteristics of a given trunk group. A PRI trunk group has no subgroups
as such, but table TRKSGRP defines the signalling characteristics of the D-channel that
conveys the ISDN signalling for the B-channels in the group:
! Signalling type ISDN
! Protocol version 87Q931
! Configuration PT_PT
In conceptual terms, there is a logical terminal (LT) at either end of an ISDN PRI trunk
interface. Each logical terminal has an identifier and belongs to a logical terminal group.
On CS2000, logical terminal attributes are datafilled in tables LTGRP, PRIPROF,
LTDEF and LTMAP, as described in section C2.3.2 on page 186 and illustrated in Figure
53 on page 188.
The version of PRI to be used is identified by means of a unique Protocol Version Control
(PVC) value generated from the values of the VARIANT and ISSUE fields in the table
LTDEF entry.
A variant is a separate call processing agent. CS2000 currently supports the following
variants of PRI:
! Base / generic ETSI PRI
! Hong Kong PRI (CR13)
! Japanese PRI (INS1500)
! ANSI PRI
! QSIG (described in Chapter E5: QSIG VPN Interface)
An issue is a refinement of a variant that implements minor variations in protocol and/or
procedures. In ISN07, CS2000 supports two national-specific issues of the base ETSI PRI
variant: Spanish PRI and Chinese PRI. The QSIG variant has two issues: ISO1996 and
ETSI1993. The other supported PRI variants have only one issue each.
Note: This PRI usage of the term variant reflects the names of the fields in table LTDEF,
but differs from how the term is used for other interfaces such as CCS7. Spanish ISUP,
for example, is defined as a variant of the ETSI ISUP agent, while Spanish PRI is defined
as an issue of the ETSI PRI variant of PRI.
LTDEF datafill options can be summarised as follows:
CS2000 also supports a number of non-ETSI services over PRI, i.e. services supported
over ISDN interfaces but not defined by ETSI. These are of two types:
! Generic non-ETSI services that can be deployed in any national network:
" Random and circular hunting for PRI trunk groups
This makes it possible to ensure that calls to a given set of trunk groups (a
super-group) are evenly distributed between their B-channels. This is
particularly useful for CS2000s connected to Internet Service Providers (ISP),
where a large number of outgoing-only trunk groups are assigned to the same
dialled number and call hold times are long.
! National non-ETSI services that are specific to a particular national network. Three
of these have been defined for use in Germany:
" Priority Class Of Service (PCOS)
" Emergency Calls
" Network Advice Of Charge (NAOC)
E4.4 Limitations
! CS2000 does not support the following call control procedures:
" Signalling procedures for bearer capability selection
" Signalling procedures for high layer compatibility selection
" Circuit-mode multirate procedures (N x 64Kb/s)
" Transit network selection
" Network specific facility selection
" Message segmentation procedures
! A maximum of 29 digits can be outpulsed for a called party number. This exceeds
the 20-digit limit specified in ETS 300 403.
! Because CS2000 supports PRI as a trunk access agent, it has no mechanism either
to route calls to a specific timeslot or to associate a particular subscriber with a
specific timeslot.
! CS2000 does not support the "Case B" packet-switched data services described in
ETS 300 007.
! CS2000 does not support PRI user mode.
! CS2000 supports only service 1 of the UUS supplementary service, not services 2
and 3.
reason, Nortel and other equipment vendors use PRI Layer 2 (Q.921) and PRI Layer 1
(ETS 300 011) as the Signalling Carriage Mechanism (SCM) for QSIG signalling.
Chapter 110 illustrates the architecture of a QSIG network at a logical level and explains
the terminology used in describing QSIG capabilities.
IP backbone network
GWC-MG GWC-MG
control QSIG QSIG control
signalling backhaul backhaul signalling
(ASPEN) (ASPEN)
QSIG QSIG
PINX PINX
Since the primary point of using a packet backbone network is to avoid the need for
dedicated physical connections, QSIG as such (i.e. the IS11582 / IS11572 / Q.921 /
30B+D protocol stack) is not supported across the packet network. Support for QSIG in
a packet network environment means support for the following:
! Support for QSIG access signalling.
! Support for QFT across the packet network.
! Support for interworking between QSIG access signalling and QFT (direct QSIG to
QSIG interworking occurs only between gateways controlled by the same CS2000).
Note: Interworking with QFT is also supported for PRI access interfaces and
analogue lines, but this is outside the scope of this QSIG chapter. See section F5.4
on page 579 for details, and especially Figure 138 on page 581, which illustrates the
access configurations involved and explains the type of QSIG virtual PINX
functionality that CS2000 is providing in each scenario.
! Support for the QFT information model, which allows information provided over
an access interface (or provisioned against it) to be mapped on to QFT signalling.
The information that can be conveyed via the ETSI ISUP APM depends on the
application context.
Each application context has an associated information model that determines the
data types or parameters that can be conveyed via that context. Open application
contexts are defined by standards bodies, while proprietary application contexts
allow equipment vendors and network operators to define information models to
support their own services.
The most important open application context is application context 1 (PSS1), which
is used for QFT. The QFT information model provides definitions for a range of
common data types that are widely used in supporting services. CS2000 uses QFT
data types to support generic VPN capabilities such as business groups and private
numbering plans, and also to support specific Centrex services for subscriber lines.
Figure 112 illustrates the different protocol stacks involved in supporting QSIG access to
the backbone network and QFT across the backbone network, with CS2000 providing
virtual transit PINX functionality.
CS2000
Figure 112: QSIG access configurations and virtual PINX functionality provided by CS2000
Note: Although QSIG as such is not used across packet networks, CS2000 uses QSIG
internally, for signalling across the CS LAN between the Core and H.323 GWCs. The
H.323 GWC performs message mapping between H.225 call control messages and
equivalent QSIG messages. For H.323 tunnelling, this message mapping involves
converting H.225 IEs conveying encapsulated H.450 and H.245 signalling into QSIG
Facility IEs conveying the same encapsulated signalling unmodified. See Chapter D5:
H.323 for further information. Also see Chapter E6: DPNSS Interface, as this
H.323/QSIG mapping capability is used to support DPNSS signalling and DPNSS
Feature Transparency (DFT) for DPNSS PBXs connected to Westell gateways and
controlled via H.323.
Supplementary Supplementary
service control service control
(service-specific) (service-specific)
GFT GFT
Layer 7: Application
Co-ordination
Co-ordination
ROSE ROSE
function
function
APDUs
GFT control GFT control
Layer 3: Network
ALERTING* ALERTING*
CONNECT * CONNECT *
Call in progress
DISCONNECT * DISCONNECT *
RELEASE * RELEASE *
RELEASE COMPLETE * RELEASE COMPLETE *
Table 41: Support for Facility and Notification IEs in QSIG messages
Support for
QSIG message
Facility IE Notification IE
SETUP Yes Yes
ALERTING Yes Yes
CONNECT Yes Yes
DISCONNECT Yes Yes
RELEASE Yes No
RELEASE COMPLETE Yes No
FACILITY Yes Yes
NOTIFY No Yes
PROGRESS Yes Yes
Peer-to-peer communication
Application Application
The ability to convey QSIG information between peer applications is provided by the
Application Transport Mechanism (APM), which adds the following extensions to ETSI
ISUP (these are ETSI ISUP V3 messages/parameters, but CS2000 supports them as
extensions to ETSI ISUP V2):
! An Application Transport Parameter (APP) that can be conveyed in the existing
ISUP call control messages IAM, ACM, ANM, CON and CPG.
A message may convey up to five APPs, but each must be for a different application
context; it is a protocol error if there are two APPs for any context.
! An Application Transport Message (APM) that can be sent independently to convey
an APP.
! A Pre-Release Information (PRI) message that can be sent prior to a REL message
to convey an APP.
The IAM sent to initiate a bearer QFT call conveys two number parameters:
! The CdPN conveys the public routing number of the destination node.
! The APP conveys the private destination number, as received in the incoming
SETUP message.
Up to 2K octets of information can be transported via a segmentation mechanism.
APM can support a number of different applications, each identified via a Context
Identifier. On receipt of an APP whose Context ID is not understood, the APM
mechanism relays the information if possible. This allows peer applications to
communicate even via intermediate nodes that do not provide application support.
Figure 116 illustrates the messaging involved in bearer QFT call setup and clearing. As
mentioned already, the QSIG message flows are essentially the same as for PRI call setup
and clearing (see section E4.2.2 on page 451 for an annotated call flow). The main point
to note is that many QSIG messages can convey Facility and/or Notification IEs with
service-related information, and that QFT can convey this across the network.
QSIG
PINX * PINX
SETUP IAM *
SETUP ACK APM *
(Overlap
INFORMATION signalling
(1 or more) only) APM * (1 or more)
CONNECT ACK
Call in progress
DISCONNECT * REL
RELEASE * RLC
RELEASE COMPLETE *
Peer-to-peer communication
Application Application
TCAP TCAP
For non-bearer QFT, information flows are defined using a set of generic PSS1 primitives,
which map on to QSIG messages on the one hand and to TCAP components and
operations on the other. They are:
PSS1_SETUP
CONTINUE [CONNECT.Invoke] CONNECT
(confirmation)
No QSIG equivalent
PSS1_REJECT CONTINUE [SETUP.ReturnResult]
(call setup fails)
E5.1.6 Specifications
QSIG is defined in the following specifications.
! Basic call control procedures are defined in ISO standard IS 11572.
! ETSI modifications to ISO/IEC 11572 (1994) are specified in ETS 300 172:
Private Integrated Services Network (PISN)
Inter-exchange signalling protocol
Circuit-mode basic services
! Generic functional procedures for the control of supplementary services are defined
in ISO standard IS 11582.
! ETSI modifications to ISO 11582 are specified in ETS 300 239.
! The Remote Operations Service Element (ROSE) is defined in CCITT
Recommendation X.219.
! The Association Control Service Element (ACSE) is defined in CCITT
Recommendation X.217.
! Data link layer requirements for ISDN PRI are defined in ITU-T Recommendations
Q.920 and Q.921, as modified by ETS 300 402.
! Physical layer requirements for ISDN PRI are defined in ETS 300 011, which is
based on ITU-T Recommendations I.431 and G.703-G.706.
! Logical/physical mapping is specified in ECMA 226 and IS 14474.
! ISUP and TCAP support for QFT is defined in Q.765.1 (also known as Q.vpn).
! The Application Transport Mechanism (APM) extensions to ISUP are defined in
Q.765 (also known as Q.apm).
! A variant is a separate call processing agent built on the International PRI base.
QSIG is denoted as variant QSIGPRI.
! An issue is a refinement of a variant that implements minor variations in protocol
and/or procedures. Two issues are currently defined for QSIG:
ISO1996 ISO 1996 QSIG, as defined in ISO 11572/11582 (BC/GF)
ETSI1993 ETSI 1993 QSIG, as defined in ETS 300 172/239 (BC/GF)
Both of these issues can coexist on the same CS2000 and even on the same media
gateway, but a given D-channel and all its associated B-channels must must be
dedicated to one issue or the other.
Note: This QSIG/PRI usage of the term variant reflects the names of the fields in table
LTDEF, but differs from how the term is used for other interfaces such as CCS7. Spanish
ISUP, for example, is defined as a variant of the ETSI ISUP agent, while ISO 1996 QSIG
is defined as an issue of the QSIG PRI variant of PRI.
LTDEF datafill options for QSIG can be summarised as follows:
QSIG is also distinguished from ETSI PRI by means of the following datafill:
! Table TRKSGRP
Option 96ISOQSIG for field VERSION. Field PARMNAME used to assign
name/index (e.g. QSIG1) for QSIG entries in table ISDNPARM, which specify
parameters whose values are to be conveyed transparently (e.g. HLC and LLC in
SETUP).
! Table ISDNPROT
Key field PROTVAR has new value QSIGPRI.
The QSIG agent uses Event-Driven Call Processing (EDCP), which means that incoming
QSIG calls (but not virtual calls) can trigger in CS2000 as Intelligent Network (IN) calls.
The maximum number of segments is eight, making the maximum message size 260 x 8
= 2080 octets. If more than eight segments would be needed and the message to be
segmented is a call control message, the call is released. Otherwise, the message is
discarded. Once the first segment of a segmented message has been transmitted, all
remaining segments of that message shall be sent (in order) before any other message is
sent on that connection.
Notes:
! Message segmentation is not supported for messages that cannot include Facility or
Notify IEs.
! CS2000 may also need to add some extra data bytes to an outgoing message, e.g. to
support AOC, in which case additional complete IEs can be added to the segmented
message subject to the 2080-byte overall limit on message size.
! CS2000 also supports ISUP message segmentation for ETSI ISUP V2+ IAMs, both
on the TDM side and for ISUP encapsulated in SIP-T. For an ISUP message
conveying QFT information using the ISUP APM, the QSIG and ISUP
segmentation/re-assembly procedures are completely decoupled from each other,
i.e. the number of received/transmitted QSIG SEGMENT messages may not equal
the number of transmitted/received ISUP APM messages. Similarly, the number of
QSIG SEGMENT messages may not equal the number of SCCP XUDT messages
for non-bearer QFT calls.
CS2000
QSIG Virtual ISUP with QFT
PINX transit ISUP v2 network
PINX
CS2000 assumes that routing datafill has been correctly set up so that the call will be
routed to another MGC that supports the QSIG Feature Transparency protocol. Additional
translations support is provided to allow both QFT and non-QFT bearer calls to use the
same ETSI ISUP trunks.
Non-bearer calls use the same translations as bearer calls. If the route determined by
translations is an ISUP one, then for non-bearer calls the QFT protocol will be used over
TCAP/SCCP. Standard translations yield a Called Party Number which is used as the
Global Title to route the QFT non-bearer call.
If, subsequent to call setup, an indication is received that the addressed node does not
support QFT, then the call will be cleared.
! Compliant with ECMA 226 and IS 14474 for logical/physical mapping, subject to
the use of PRI as the supporting physical adaptation. This implies the following:
" Data link layer compliant with ISDN PRI as defined in ITU-T
Recommendations Q.920 and Q.921, as modified by ETS 300 402.
" Physical layer compliant with ISDN PRI as defined in ETS 300 011, which is
based on ITU-T Recommendations I.431 and G.703-G.706.
Note: The QSIG SIM Specification incorporates an annotated version of ECMA
226 as its Section B, Part 2, to describe logical/physical mapping. For completeness,
Nortel has also produced an alternative Section B, Part 2 consisting of an annotated
version of ISO/IEC 14474 (which deals with the same subject as ECMA 226); this
is available as a free-standing document.
! Compliant with IS 15049 / ECMA 211 and IS 15050 / ECMA 212 for the AOC
supplementary service, except as noted in the QSIG SIM specification.
! Compliant with E.164 for support of Open Dial Plans (ODPs)
QSIG also supports the German public network features Priority Class Of Service
(PCOS), Emergency Calls, Carrier Selection and Network Advice Of Charge (NAOC).
E5.3 Limitations
! The CS2000 implementation of QSIG does not support the following call control
procedures:
" Signalling procedures for high layer compatibility selection
" Circuit-mode multirate (64 kbit/s base rate) procedures
! Facility IEs received in a second or third call clearing message (i.e. RELEASE or
RELEASE COMPLETE) in a call takedown sequence are not examined or acted on
by the CS2000 QSIG GF implementation, and will not be transited through a
CS2000 acting as a transit PINX.
Lines Lines
End node PBX or End node
functionality switch, functionality
e.g.
CS2000
PBX or PBX or
switch, DPNSS Transit node DPNSS switch,
e.g. functionality e.g.
CS2000 CS2000
Non-DPNSS Non-DPNSS
trunk Gateway Gateway trunk
functionality functionality
E6.1.2 Protocol
The DPNSS interface presented by a CS2000 network to the PBXs it serves is defined as
a layered protocol with the following structure:
! Level 1 corresponds to Layer 1 (Physical) of the OSI 7-layer model. Physical
DPNSS links between PBXs and the network are provided by 2Mb/s PCM30
carriers. Each carrier supports 30 64Kb/s traffic channels for speech or data, and one
64Kb/s signalling channel (TS16).
! Level 2 corresponds to Layer 2 (Data link) of the OSI 7-layer model. The data link
uses the Link Access Protocol (LAP) defined in Section 3 of BTNR 188 to support
30 real signalling channels, each associated with a traffic channel, and 30 virtual
signalling channels.
! Level 3 is the network/application layer, and encompasses the functions of Layer
3-7 of the OSI 7-layer model. It provides the call handling function by sending and
receiving DPNSS messages over the signalling channels provided by the data link.
Messages are conveyed in HDLC (High-level Data Link Control) frames that
identify the related traffic channel (if any) and use serial numbers to avoid loss of
frames (which are resent until acknowledged).
Within a CS2000 network, in which 30B+D carriers are by definition not used, DPNSS
Level 3 signalling is conveyed via a number of different lower-level protocols, as
explained in section E6.2 on page 485.
Originating Terminating
node node
Caller goes
off-hook and
dials number ISRM (Initial Service Request Message)
Ringing Physical
tone NAM (Number Acknowledgement Message) ringing
Audible ringing in-band
Called party
CCM (Call Connect Message) answers
Speech path through-connected
Call in progress
DPNSS also supports virtual calls, which allow features to be activated without using an
associated speech or data path. The messaging involved in call setup and clearing is
similar, but no traffic channel is seized. Virtual call setup is initiated by an ISRM and call
clearing involves CRM and CIM messages, as for real calls, but messages related to
in-band activity, e.g. NAM and CCM, are not required.
E6.1.4 Specifications
DPNSS is defined in BTNR 188. Interworking to other UK signalling standards (e.g.
DASS2) is defined in BTNR 189.
Figure 122 illustrates the network configuration used by CS2000 to support DPNSS
signalling.
H.323 H.323
proxy proxy
GWC DPNSS over QSIG GWC
(in QSIG Facility IEs)
DPNSS DPNSS
over H.323 over H.323
(in H.225 (in H.225
UUI IEs) UUI IEs)
IP core network
DPNSS DPNSS
over E1 over E1
carriers Westell Westell carriers
Digital iQ203x iQ203x Digital
PBX Bearer connections PBX
gateway gateway
In addition to supporting DPNSS transit node functionality for two PBXs served by the
same CS2000, CS2000 can support transit node functionality for two PBXs served by
different CS2000s. In this scenario, two or more CS2000s serve as a single logical DPNSS
transit node, with connections between them being provided by IBN7 trunks that support
DFT (DPNSS Feature Transparency). DFT involves encapsulating DPNSS information
in ISUP or TCAP messages and transporting it transparently across the network. CS2000
supports transit node functionality both when interworking DPNSS to a DFT trunk and
when interworking two DFT trunks, as shown in Figure 124.
Inter-CS DFT trunks used to support DPNSS transit node functionality may be either
DPTs between GWCs on different CS2000s or circuit-based trunks between TDM-side
endpoints on PVG trunk gateways controlled by different CS2000s.
CS2000 supports DFT using two types of proprietary IBN7 signalling:
! IBN7 ISUP for real DPNSS calls
The Network Transport Parameter (NTP) conveys the Nortel proprietary Hybrid
Network Information Parameter (HNIP).
! ANSI TCAP for DPNSS virtual calls with no associated bearer circuit
The principle underlying DFT support is that end nodes must be able to reconstitute the
DPNSS information they receive and provide DPNSS functionality. This means:
! DPNSS parameters that can be uniquely mapped are interworked.
! Parameters that cannot be uniquely mapped are conveyed transparently.
! As far as ISUP call setup is concerned, DFT information is optional, and will be
discarded if it cannot be recognised.
See section F6.2.2 on page 594 for more information about DFT support.
Lines that are to be interworked to DFT in this way must have the DFT option datafilled
in table NCOS.
CS2000
DPNSS
features
CS2000 CS LAN
CS2000 Core
MS2000
GWC
GWC-gateway
Dual PP8600s signalling (H.248)
Figure 127: Functional view of capabilities provided by carrier located line media gateways
E7.2.2.2 Call Flow for VoIP Call between Two CS2000 Cable Lines
This section provides an overview of the process of setting up a call between two CS2000
lines served by the same CS2000. It therefore deals with:
! The handling of an incoming call from a CS2000-controlled line
! The handling of an outgoing call to a CS2000-controlled line
The steps involved are numbered sequentially in the annotated network architecture
shown in Figure 129, and are described in order on the following pages.
CS2000
Call processing
6
2 5 7a 7b
Gateway 10 Gateway
Controller Controller
(GWC) 13 (GWC)
for ingress for egress
gateway 20 gateway
3 8a 14 17 21 11 15 19
IP backbone network
Bearer connection
(packetised voice)
CMTS CMTS
1 9 12 18
4 22a HFC cable access networks 16 22b
Signalling between CMTS and MTAs
Originating is based on (Euro)DOCSIS, and is Terminating
Gateway not visible to the CS2000 GWCs that
control the MTA gateways Gateway
(MTA) (MTA)
1
MTA line gateway sends NCS NTFY (offhook) to ingress GWC to report subscriber
going off-hook; GWC acknowledges NTFY by sending NCS 200 OK to gateway
MTA gateway accumulates dialled digits in accordance with the digit map; when a digit
map match occurs, gateway sends NCS NTFY (digits) to GWC to convey the digits
4 collected; GWC acknowledges NTFY by sending NCS 200 OK to gateway. Depending
on the dial plan, the GWC may send further digit maps, e.g. to switch to reporting each
digit as it is dialled.
6
The Core uses received digits to perform translations and routing, resulting in the
identification of the egress GWC and MTA gateway serving the destination line
The Core sends FCM (Fabric Control Message) to the ingress and egress GWCs to
7a
7b initiate establishment of bearer path connection between the MTAs, and to set up
communication between the two GWCs.
Ingress GWC sends CRCX to originating MTA line gateway, instructing it to set up an
8
initially inactive bearer connection for the line endpoint in question, specifying:
- The callID to be used in all subsequent connection control messages
- Local connection options set to PCM A-law with 10ms packetisation
MTA gateway acknowledges CRCX and provides the SDP session description to be
used for receiving audio data, including information such as:
- IP address at which the gateway is ready to receive audio data
9
- Transport protocol, i.e. RTP
- Audio profile, i.e. AVP
- RTP port identifier
- Payload type as defined in RFC 1890, i.e. 8 (corresponding to G.711 A-law)
- Packetisation period of 10ms
10
Ingress GWC passes originating gateways SDP session description (including IP
address) to egress GWC
Terminating gateway sends NCS 200 OK to egress GWC in response to CRCX; this
12 includes the terminating SDP service description (including IP address), which will be
the one used for the call.
14
Ingress GWC sends MDCX with terminating SDP session description to the originating
MTA line gateway
Egress GWC sends RQNT to terminating MTA line gateway, instructing the gateway
15 to apply ringing to the terminating subscriber line and to report the called party going
off-hook (at which point ringing will stop)
16
Terminating MTA gateway sends NCS 200 OK to indicate that ringing is being applied
to the called party line
17
Ingress GWC sends RQNT to originating MTA line gateway, instructing the gateway
to apply ringback tone
18
Terminating MTA gateway sends NCS NTFY (offhook) to egress GWC to report called
party going off-hook; GWC acknowledges NTFY by sending NCS 200 OK to gateway
Egress GWC sends NCS MDCX to terminating MTA line gateway, instructing the
19
gateway to place the bearer connection in send/receive mode, and to report the
subscriber going on-hook again; MTA gateway acknowledges RQNT by sending NCS
200 OK to GWC
20 Egress GWC notifies ingress GWC that call has been answered
Ingress GWC sends MDCX to originating MTA gateway, instructing it to place the
21 bearer connection in full duplex mode (mode = sendrecv), stop applying ringback tone,
and provide notification of the subscriber going on-hook again
22a The call is fully established when both the originating and teminating MTA gateways
22b have responded with an NCS 200 OK to the request to provide on-hook notification
DQoS (Dynamic Quality of Service) for cable gateways involves additional signalling
during call setup to ensure that network congestion and resulting packet loss is avoided.
DQoS provides mechanisms that enable the CMTS to reserve bandwidth in the HFC
access network (via RSVP) and to prioritise traffic in the backbone network (via
DiffServ). In addition to bandwidth allocation, DQoS helps prevent denial of service
attacks and illegal use of network resources. See section D7.7 on page 317 for further
information.
Customer LAN
Customer LAN Gateway
MGCP
RJ-11 or Codecs LAN interface MGCP
RJ-21X supporting supporting Alternative IP
terminations analogue / access to the access
for analogue digital IP backbone technologies
backbone
subscriber conversion network via a Bearer flows available network
lines (G.711, G.729) customer LAN
Bearer flow
E7.2.3.3 Network Address Translation (NAT) Issues for Customer LAN Gateways
Typically, customer LANs supporting line media gateways use a firewall / NAT (Network
Address Translator) to provide security. To support NAT traversal for signalling traffic,
media gateways and other hosts that are located behind a NAT must:
! Initiate communication with their GWCs (a GWC cannot initiate communication
with a gateway behind a NAT).
! Provide their GWCs with address information embedded in signalling packets,
which the GWC can then map on to the source address in the packet header (which
is that of the NAT rather than the gateway).
! Use keep-alive messaging to ensure that communication with their GWCs is
maintained when no call is in progress (the GWC will otherwise be unable to send
setup messages for calls incoming to the gateway).
Dynamic address discovery for signalling is described in detail in section D8.4 on page
322.
Address discovery is also a requirement for bearer connections across the packet
backbone network. This involves the use of a media proxy, as described in section
B5.1.2.2 on page 155.
E7.2.4.2 Standards
The CS2000 implementation of the V5.2 protocol is based on ETSI V5.2 Standard
(Edition 1), as defined in:
! ETS 300 324-1 (1994) with Amendment ETS 300 324-1/A1 (1996)
! ETS 300 347-1 (1994) with Amendment ETS 300 347-1/A1 (1997)
CS2000 does not support Edition 2 of the ETSI V5.2 standard.
ETS 300 324 actually defines the V5.1 interface, which allows line interfaces to be
multiplexed on to a single E1 carrier, but sections of ETS 300 324 that also apply to ETS
300 347 are not reproduced in ETS 300 347. Functionally, V5.2 is a superset of V5.1, i.e.
V5.1 capabilities are the same as the capabilities of a V5.2 interface with only one carrier.
However, the ability to support single-carrier V5.2 interfaces should not be interpreted as
formal compliance with the V5.1 specification.
The term V5.2 signalling should be taken to include control and maintenance signalling
as well as call control. The term V5-PSTN signalling specifically denotes call control
signalling for PSTN (analogue) lines.
The distinguishing characteristic of a PVG configured to support V5.2 lines is that its
TDM-side E1 carriers are logically grouped into one or more integrated V5.2 interfaces
controlled by a V5.2 GWC, each interface serving a V5.2 Access Network (AN). The
maximum number of E1 carriers per interface is 16. Each V5.2 interface consists of bearer
channels and shared C-channels. The maximum number of line endpoints that can be
supported over a given V5.2 interface is 2048. No more than 6,384 V5.2 lines can be
supported by a given line GWC. The number of line endpoints defined and the number of
bearer channels available at the PVG determine the concentration that takes place
between the V5.2 AN and the gateway.
To avoid duplication, this section does not repeat information provided elsewhere in this
document about CS2000 support for the V5.2 line interface, as follows:
! See section B2.3 on page 99 for information about the architecture and physical
characteristics of a PVG configured to support V5.2 lines, which are the same as for
PVGs used to support CCS7 and/or PRI access.
! See section B2.4.2 on page 112 for information about the capacity and configuration
of a V5.2 AN interface.
! See section B2.4.3 on page 114 for information about V5.2 robustness and
protection switching.
! See section C2.7.2 on page 197 for information about the datafill used to define a
V5.2 AN interface.
! See Chapter D11: V5UA for information about how V5.2 signalling backhaul is
supported using V5UA / SCTP / IP.
Detailed information about some aspects of V5.2 operation is provided in the following
FNs:
! V5.2 flow control procedures implemented at the GWC are documented in
A59038965. These include:
" V5 system overload detection
" V5 system overload handling (by throttling new call attempts)
" GW overload detection
- based on loss of PSTN messages
- via V5UA Error Indication message with Reason=Overload
" GW overload handling (by protection switching of C-channels)
! V5 alarms generated at the GWC are documented in A59038943
! V5.2 audits invoked on the Core or the GWC are documented in A59038943. These
include:
" V5CC Audit, invoked on Core to check for V5 state mismatches between
GWC and Central Control (CC) on Core.
" BCC Audit, invoked on GWC.
" Virtual Layer 1 Audit between GWC and GW, invoked on GWC
Originating Terminating
access node CS2000 access node
Caller AN LE AN
goes ESTABLISH
off-hook (SS: off-hook)
EST ACK
Dial tone
ESTABLISH
DTMF (CR: type 0) Ringing
dialling
Called party
SIGNAL
(SS: off-hook) goes off-hook
Active call
Caller
goes SIGNAL
on-hook (SS: on-hook)
DISCONNECT Treatment
DISCONNECT
COMPLETE
" V5_ANALOG
Additional attenuation should be applied by the AN line card.
Maintenance
! Accelerated Port Alignment (APA)
A given V5.2 interface comprises a number of ports for PSTN bearer channels. The
port states at the CS2000 must align with (match) the port states at the AN.
Accelerated Port Alignment (APA) allows port alignment to be achieved for all the
ports of a V5.2 interface by means of a single unblock-all-ports handshake
sequence, making it unnecessary to send a separate message for each port. APA
requirements and messaging are defined in ETS 300 347-1 A1. The APA feature is
assigned to a V5.2 interface via the boolean APA field in table V5SIG.
Display, e.g.
for CLI of
incoming call
Feature keys
with
dynamically
Standard assigned
numeric functons
keypad for
point-and-click
dialling
Figure 132: CentrexIP soft client user interface (as displayed in PC window)
The primary purpose of a PC-based soft client is to complement a users desktop phone
by providing point-and-click control over call handling. Typically, however, the speech
path is routed through the users telephone set, as this offers a quality of service superior
to that of a PC.
A further advantage of a PC-based soft client is that it can be used to extend the
capabilities of a business users desktop line to wherever that user may be. For example,
a user can log in to the corporate telephone network from a hotel room using a laptop, or
from a desktop PC at home. In either case, the fact that the soft client is provisioned with
the same telephone number as the desktop phone means that incoming calls will
automatically be redirected to the CentrexIP soft client, and that outgoing calls will be
handled in exactly the same way as if they originated from the desktop phone. The
standard set of non-VoIP capabilities supported by the corporate network is also available,
e.g. email.
The login process establishes an IP connection with the CICM, determines the DN for
which the soft client is to provide VoIP support, and causes the CICM to configure the
clients capabilities in accordance with the profile of the logged-in user, e.g. by
downloading an appropriate set of feature key assignments.
Support for the standard TAPI interface makes it possible for CentrexIP soft clients to be
connected to TAPI-aware applications such as contact databases or customer care
systems, and to use these to make calls.
Figure 133 illustrates the network configuration used by CS2000 to provide VoIP support
for CentrexIP clients.
CentrexIP Client
Manager (CICM)
Perceived by
CS2000 as
large gateway
Etherset client (i200x):
IP-enabled Ethernet
phone with display
and function keys H.248 P-Phone
Dual PP8600s
! QSIG services
(see Chapter F5: QSIG Services for details)
The QSIG VPN interface supports Generic Functional Transport (GFT)
functionality, which allows QSIG signalling to be conveyed transparently across the
network to support QSIF Feature Transparency for real calls (bearer QFT) and
virtual calls (non-bearer QFT).
In addition, QSIG supports a number of ISDN supplementary services and QSIG
Additional Network Features (ANFs).
! DPNSS services
(see Chapter F6: DPNSS Features for more details)
DPNSS features are PBX features for the use of business subscribers. DPNSS
enables different types of PBX to communicate via a common peer-to-peer
signalling system (DPNSS). A number of PBXs connected in this way can serve as
a single large PBX, offering the same features and services to subscribers regardless
of the type of PBX to which they are connected.
! Feature Transparency
(see Chapter F7: APM Feature Transparency for more details)
The ETSI ISUP V3 APM (Application Transport Mechanism) has been defined by
the ITU-T to serve as a general-purpose service support mechanism for conveying
service-related information across the network. Use of the APM means that ISUP
does not need to understand the information being conveyed, only to relay it
between two access interfaces that do understand it. This is known as feature
transparency.
! Virtual Private Networking (VPN)
(see Chapter F8: VPN for details)
Telephony VPN (Virtual Private Networking) is not strictly speaking a feature set
in its own right, but a mechanism for making existing feature sets more widely
available. Specifically, it denotes the use of hybrid networks that combine the
advantages of private and public networks for the benefit of business customers who
need to comunicate between multiple locations. It includes open implementations
based on ISDN access signalling and SIP-T encapsulation of ETSI ISUP network
signalling, and semi-proprietary implementations involving SIP-T encapsulation of
IBN7 ISUP.
! Voice mail
(see Chapter F9: Voice Mail for details)
Voice mail allows a user to have incoming calls forwarded to a message desk, to be
notified that recorded messages are waiting, and to retrieve and play back those
messages later.
! Conferencing support
(see Chapter F10: Conferencing for details)
CS2000 uses the UAS to support three types of conferencing:
" Three-way call set up on an ad-hoc basis.
" Station-controlled conferencing, i.e. ad-hoc conferences with more more than
three participants.
" Meet-me conferencing, i.e. prearranged dial-in conferences with up to 30
participants.
CS2000 CS2000
Call processing Call processing
and service logic and service logic
Service requests
GWC-MG GWC-MG
signalling signalling
Media stream
Media Media
gateway gateway
CS2000 CS2000
Call processing Call processing
and service logic and service logic
GWC-MG GWC-MG
signalling signalling
Note: Figure 134 is a simplified view of the architecture used to support services in a
packet network environment (Session Server, media server and TDM-side CCS7 are not
shown).
Table 46: DPT interaction support for system features and capabilities
Supported Bearer
over SIP-T DPT bearer interaction Details
Service or capability (including restrictions
/ with interaction workaround
SIP-T available? and comments)
Table 46: DPT interaction support for system features and capabilities
Supported Bearer
Details
over SIP-T DPT bearer interaction
Service or capability / with
(including restrictions
interaction workaround
SIP-T available? and comments)
Table 47: DPT interaction support for analogue subscriber line services and options
Supported Bearer Details
over SIP-T DPT bearer interaction
Service or option / with interaction workaround
(including restrictions
and comments)
SIP-T available?
3-Way Call (3WC) Yes No n/a
Add On Yes No n/a
Announcement before Routing (ABR) Yes No n/a
Provision treatment as
Anonymous Call Rejection (ACRJ) Yes Yes Yes announcement or backward
release with cause
Authorisation Code Yes No n/a
Automatic Call Back Yes No n/a
Automatic Collect Call (ACC) Yes Yes No
ACC Blocking (ACCB) Yes Yes No
Automatic Line (AUL)) Yes No n/a
Automatic Recall (AR) Yes No n/a
Automatic Recall of Dialable
Yes No n/a
Directory Number (ARDDN)
Basic Call with ODP Yes No n/a
Bridged Night Number (BNN) Yes No n/a
Call Completion to Busy Subscriber
(CCBS) Yes No n/a
Table 47: DPT interaction support for analogue subscriber line services and options
Supported Bearer
Details
over SIP-T DPT bearer interaction
Service or option / with
(including restrictions
interaction workaround
SIP-T available? and comments)
Table 47: DPT interaction support for analogue subscriber line services and options
Supported Bearer
Details
over SIP-T DPT bearer interaction
Service or option / with
(including restrictions
interaction workaround
SIP-T available? and comments)
Table 47: DPT interaction support for analogue subscriber line services and options
Supported Bearer
Details
over SIP-T DPT bearer interaction
Service or option / with
(including restrictions
interaction workaround
SIP-T available? and comments)
Table 47: DPT interaction support for analogue subscriber line services and options
Supported Bearer
Details
over SIP-T DPT bearer interaction
Service or option / with
(including restrictions
interaction workaround
SIP-T available? and comments)
Provision treatment as
Plug Up (PLP) Yes Yes # Yes announcement or backward
release with cause
Preferential Hunting (PRF) Yes No n/a
Preset Conference Yes No n/a
Priority Class of Service (PCOS),
Yes No n/a
Germany only
Private Numbering Plan (PNP) Yes No n/a
Provision treatment as
Requested Suspend Service (RSUS) Yes Yes # Yes announcement or backward
release with cause
Ring Again (RAG) Yes No n/a
Secondary DN / Teen Service (SDN) Yes No n/a
Secondary Language (SL) Yes No n/a
Provision treatment as
Selective Call Acceptance (SCA) Yes Yes # Yes announcement or backward
release with cause
Provision treatment as
Selective Call Forward (SCF) Yes Yes # Yes announcement or backward
release with cause
Provision treatment as
Selective Call Rejection (SCRJ) Yes Yes # Yes announcement or backward
release with cause
Simultaneous Ring (SIMRING) Yes No n/a
Speed Calling, User Group List
(SCU) Yes No n/a
Table 47: DPT interaction support for analogue subscriber line services and options
Supported Bearer
Details
over SIP-T DPT bearer interaction
Service or option / with
(including restrictions
interaction workaround
SIP-T available? and comments)
F2.1 Introduction
Analogue subscriber line services are designed to simplify the process of making calls
(e.g. speed calling), to increase the likelihood of successful call completion (e.g. call
waiting, call forward, call transfer), to provide information (e.g. caller number/name
delivery) and to make new types of call possible (e.g. three-way calls).
This chapter lists and describes the services that can be assigned to CS2000 analogue
subscriber lines in ISN07.
Note: CS2000 supports four different analogue line implementations in ISN07. In
general, a supported service can be assigned to any of these line types. See section F2.4
on page 552 for information about restrictions that may apply to a particular line type.
F2.2.7.1 Introduction
Automatic Call Distribution (ACD) is a set of capabilities for the support of call centres.
It provides organisations with a mechanism for evenly distributing incoming calls to a
given DN between a number of agent positions to be answered. It thus ensures that the
calls are handled efficiently and that the operator workload is distributed fairly.
The call distribution mechanism is based on the use of two queues, one for queueing calls
as they arrive and one for queueing agent positions as they become idle. Calls are retrieved
from the call queue and dealt with in order of their arrival, and the next call to be answered
is presented to the idle agent position that has waited longest in the agent queue. If no calls
are queued when a call comes in, it is presented immediately to the agent position that has
been idle longest.
Figure 135 is a functional illustration of the operation of an ACD group.
CS2000
ACD presents ACD agent
longest-queued call positions
to longest-idle agent
Incoming position to be answered
calls
The operation of a basic ACD group can be enhanced in the following ways:
! Multiple DNs
The call-handling capacity of an ACD group can be increased by allowing it to
handle calls for several DNs rather than just one. Calls for different DNs may be
separated into different call queues or pooled, as required.
Note: An agent position can be assigned a secondary DN for non-ACD calls.
! Multistage queues with prioritisation
Four different priority levels (0 to 3) may be assigned to the calls in a call queue on
the basis of the DN they call and whether the call comes in on a line or a trunk. The
principle is that all the calls with a given priority will be answered before any call
with a lower priority is answered, which allows preferential treatment for selected
customers. The highest priority is 0.
Figure 136 is a functional illustration of an ACD supergroup, showing the use made of
different queues.
ACD Supergroup
CS2000
ACD Group A
Incoming call
to ACD Group A Call Overflow Overflow
queue out queue in queue
Option 1:-
Call queued
against original
target group
1
ACD Group B
Call Overflow Overflow
Option 2:-
queue out queue in queue
Call immediately
overflowed to
alternative group
2 3a
Queue Management
! Incoming Call Queues
Supports the use of four call queues with priorities 0 to 3 to determine the order in
which calls are answered.
! Agent Queue Management
Management of agent queue to ensure even distribution of incoming calls.
! Overflow of Queued Calls
Allows calls to be routed to an overflow queue after waiting for a specified time.
! Automatic Overflow
Allows customer to specify maximum number of queued calls (queue threshold)
and maximum queueing period (wait threshold) for any call, after which call is
rerouted.
! Call Transfer with Time
Allows a caller transferred from one ACD agent to another to have priority in
second queue determined by total time since first queued.
! Abandoned Call Clearing
Automatic clearing of connection if queued caller abandons call.
! Multiple Directory Numbers
Supports the assignment of up to 63 supplementary DNs to an ACD group to
complement the groups primary DN, as a mechanism for organising incoming
calls. A priority level (range 0-3) can be specified for each DN.
This feature also supports the assignment of one or more Secondary DNs (SDNs) to
an individual ACD agent for non-ACD calls.
! Queue Slot Allocation
Allows operating company to control the allocation of queue slots, recorded
announcements and music selections to ACD groups (and thus to charge for them).
Treatments
! Call Delay Announcement
Allows customer to specify acceptable call-delay period, and to have new incoming
calls hear an appropriate announcement if calls are already having to wait longer.
! Forced Announcement for New / Overflowed Calls
Forces an announcement to be played to each new caller, regardless of the current
queue state.
! Music on Delay
Supports playback of music to queued callers during extended delays.
! 2nd and 3rd Recorded Announcements
Provides control over delays between announcements and what caller hears while
waiting (ringing, silence or music).
! Night Service
Allows customer to specify what happens when all agents are logged out. Typical
night service treatments are rerouting to another number or playback of an
appropriate announcement.
Call Handling
! Call Forcing
Increases the speed of ACD call handling by presenting queued calls to agents
automatically instead of waiting for an agent request.
! Variable Wrap-Up Time
Allows customer to vary the interval that elapses between call completion and new
call presentation such that different intervals can be used for different agents and
groups.
Agent Features
! Agent Login / Logout
Support for agents logging in at the start of a shift and logging out at its end. A
password can be requested when an agent logs in, and ACD service logic can check
that an agent terminal is associated with the same customer group as the login
identification number provided.
! Agent Not Ready
Allows agent to dial an access code to make set appear busy, thus preventing calls
from being routed to it.
! Called Name / Number Display for ACD Agents
DDN and CNAMD functionality for incoming calls presented to ACD agents.
! Call Park by ACD Agent
Allows an ACD agent to park an active call against his/her own DN for subsequent
retrieval.
Supervisor Features
! Observe Agent from Analogue Set
Allows supervisor to use an anlogue set to perform basic audio monitoring of calls
to to agent positions.
Table DNREVXLA
Reverse translator name
from table CUSTNTWK RXLANAME
Yes
Is there another No Calling number
RESULT on list of within a REGION Use DELDIGS,
RESULTS? digit range? PRFXDIGS,
Yes and OPTPRFX
No
to format CLI
Called number into diallable
Calling Number Yes
within same form for
unchanged No region? called party
of CNDB and CNAB feature activation codes. The access codes to be used for this
purpose are typically specified by national regulators, e.g. the feature activation
code used for CNDB and CNAB in the UK is 141. An announcement notifies the
subscriber of successful feature activation.
Static office-wide suppression of party information delivery takes precedence over
per-call activation or deactivation of the name blocking feature.
The CEPT Call Back (CCB) service is implemented on CS2000 via AR.
There is also a CEPT service with the name Memo Box. This is simply voice mail, and is
implemented on CS2000 by combining the MWT service with an appropriate Call
Forward variant.
CLASS ACB (Automatic Call Back) Yes Yes Yes Yes Yes Yes Yes
Regulatory Services
CLF (Calling Line Flash for MCID) Yes Yes Yes Yes Yes Yes Yes Yes
ELN (Essential Line) Yes Yes No
PCA (Payment Ceiling Advice) Yes Yes Yes
F4.1 Introduction
ISDN supplementary services can be divided into the following categories:
! MoU Priority 1 services, i.e. supplementary services specified as Priority 1 services
in the CEPT Memorandum of Understanding (MoU) on ISDN rollout for Europe:
Memorandum of Understanding on the Implementation of an European ISDN
Service by 1992. Support for these MoU1 services is discussed in section F4.2.
! MoU Priority 2 services, i.e. supplementary services not specified as Priority 1
services in the MoU. Support for these MoU2 services is discussed in section F4.3.
! Non-ETSI ISDN services, which are services not specified in the MoU or defined
by ETSI, but which are either defined as requirements by other bodies, e.g. national
regulatory bodies, or defined by Nortel for general use. See section F4.4 for details.
Non-ETSI ISDN services are sometimes referred to as MoU3 services.
This chapter describes support for ISDN supplementary services over the CS2000
implementation of ETSI ISDN PRI at the T reference point, a point-to-point interface
serving digital PBXs as described in Chapter E4: PRI Access Interface.
Note: The MoU1 services Multiple Subscriber Number (MSN) and Terminal Portability
(TP) are not relevant for PRI, and are therefore not listed or described.
! Calling Line Identification Presentation (CLIP)
The CLIP service provides the called party with the ISDN number of the calling
party in a form sufficient to allow the returning of the call (i.e. a subscriber number,
a national number or an international number, together with a subaddress if
provided by the calling user).
Service defined in ETS 300 089 (stage 1) and ETS 300 092 (stage 3).
! Calling Line Identification Restriction (CLIR)
The CLIR service restricts presentation of the calling users ISDN number and
subaddress to the called user.
When the CLIR supplementary service is applicable and activated, the originating
network notifies the destination network that the calling users ISDN number and
subaddress information (if provided by the calling user) are not allowed to be
presented to the called user.
Service defined in ETS 300 090 (stage 1) and ETS 300 093 (stage 3).
! Direct Dialling IN (DDI)
The DDI service enables the user to establish a call to a destination, without the
assistance of an operator, using a DDI number sent en-bloc or by overlap sending
from the network to the user. The DDI supplementary service is based on the use of
the ISDN number, and does not include subaddressing.
In a network with an open numbering plan, the length of DDI numbers need not be
known to the serving CS2000.
Service defined in ETS 300 062 (stage 1) and ETS 300 064 (stage 3).
F5.1 Overview
QSIG incorporates not only basic call control procedures, but also generic functional
procedures for the control of supplementary services at the Q reference point. For an
overview of the Generic Functional Transport (GFT) entity, see section E5.1.3 on page
466.
QSIG feature set support can be categorised as follows:
! Features supported as part of basic call
Calling Line Identification Presentation (CLIP)
CLI Restriction (CLIR)
! Support for QSIG Additional Network Features (ANFs)
Transit Counter
! VPN support via QSIG Feature Transparency (bearer and non-bearer)
! Support for specific ETSI ISDN supplementary services
Connected Line Identification Presentation (COLP)
Connected Line Identification Restriction (COLR)
Advice Of Charge (AOC)
Call Completion to Busy Subscriber (CCBS)
Call Completion on No Reply (CCNR)
! Support for public network features (all German)
Priority Class Of Service (PCOS)
Emergency Calls
German Carrier Selection
Network Advice Of Charge (NAOC)
Support for the services in these categories is described in sections F5.2 to F5.6
respectively.
Note: In addition to providing service support over the externally visible QSIG interface,
CS2000 uses QSIG internally, for signalling across the CS LAN between the Core and
H.323 GWCs. The H.323 GWC performs message mapping between H.225 call control
messages and equivalent QSIG messages. For H.323 tunnelling, this message mapping
involves converting H.225 IEs conveying encapsulated H.450 and H.245 signalling into
QSIG Facility IEs conveying the same encapsulated signalling unmodified. See Chapter
D5: H.323 for further information. Also see Chapter E6: DPNSS Interface and Chapter
F6: DPNSS Features, as this H.323/QSIG mapping capability is used to support DPNSS
signalling and DPNSS Feature Transparency (DFT) for DPNSS PBXs connected to
Westell gateways and controlled via H.323.
Figure 138 illustrates different types of QFT access configuration, and explains which
type of virtual PINX functionality CS2000 is providing in each case (see section E5.1.1
on page 461 for definitions of different types of PINX functionality).
CS2000 also supports the Network Advice Of Charge (NAOC) service. For NAOC, call
charges are calculated centrally at a Charge Determination Point (CDP) node, and call
charge information is then passed to the originating node to be relayed back to the calling
user over the QSIG access interface. See 59007987, 59008229 and 59007780 for details.
Lines Lines
End node PBX or End node
functionality switch, functionality
e.g.
CS2000
PBX or PBX or
switch, DPNSS Transit node DPNSS switch,
e.g. functionality e.g.
CS2000 CS2000
Non-DPNSS Non-DPNSS
trunk Gateway Gateway trunk
functionality functionality
In addition to supporting DPNSS transit node functionality for two PBXs served by the
same CS2000, CS2000 can support transit node functionality for two PBXs served by
different CS2000s. In this scenario, two or more CS2000s serve as a single logical DPNSS
transit node, with connections between them being provided by IBN7 trunks that support
DFT (DPNSS Feature Transparency). DFT involves encapsulating DPNSS information
in ISUP or TCAP messages and transporting it transparently across the network. CS2000
supports transit node functionality both when interworking DPNSS to a DFT trunk and
when interworking two DFT trunks, as shown in Figure 141.
Inter-CS DFT trunks used to support DPNSS transit node functionality may be either
DPTs between GWCs on different CS2000s or circuit-based trunks between TDM-side
endpoints on PVG trunk gateways controlled by different CS2000s.
CS2000 supports DFT using two types of proprietary IBN7 signalling:
! IBN7 ISUP for real DPNSS calls
The Network Transport Parameter (NTP) conveys the Nortel proprietary Hybrid
Network Information Parameter (HNIP).
! ANSI TCAP for DPNSS virtual calls with no associated bearer circuit
See section F6.2.2 on page 594 for more information about DFT support.
See AE0923 for more details of IBN7 DFT transit node functionality.
Lines that are to be interworked to DFT in this way must have the DFT option datafilled
in table NCOS.
See AE1011 for more details of IBN7 DFT end node functionality.
Note: In cases where there is an Centrex equivalent for a given DPNSS feature,
providing end node support for the DPNSS feature may involve feature-to-feature
interworking with the Centrex equivalent. See section F6.3 on page 596 for details.
CS2000
DPNSS
features
CS2000 as CS2000 as
section
BTNR 188
CS2000 as CS2000 as
section
Transit Node End Node
DPNSS Feature (DPNSS/DFT to (DPNSS/DFT
DPNSS/DFT) to line)
Non-Specified Information
Enables DPNSS to convey unspecified information
15 Y Y [2]
required for the implementation of network-specific
features and functions.
Service-Independent Strings
Enables DPNSS to convey supplementary information
16 Y y [3]
strings without affecting the operation of DPNSS basic
calls or suplementary services.
Call Waiting (AG4586)
17 Notification of new incoming call provided during active Y y [4]
call.
Bearer Service Selection (AE0284, AF6453) [5]
Allows requirement or preference for transmission
18 capability to be specified in ISRM (in addition to SIC). If N [6] N
capability not available, call rejected if capability required,
or proceeds as voice call if capability preferred.
Route Optimisation (AR4940, AJ4220, AJ5366)
Where call uses non-optimum route (e.g. after call
transfer), it can be re-established via the preferred route
19 without affecting the parties involved in the call. This Y Y
service cannot be used during data calls.
For information about the billing of route-optimised calls,
see A59017058 and A59022458.
Extension Status
20 Offers the capability of determining, on request, the status Y N
of an extension (free, busy, out of service, diverted, etc)
without calling the extension.
Controlled Diversion
Allows a caller who encounters Call Diversion either to
21 Y N
allow the diversion to proceed or to specify an alternative
method of completing the call.
Redirection (NC0351)
Allows a call transferred by an operator or subscriber to
22 Y y
another extension to be automatically redirected to the
transferrer on timeout or failure.
Series Call (AR1611)
Caller asks called party (operator) to make two or more
23 Y Y
calls, and is reconnected to the operator after each call to
make the next call in the series.
Three Party Takeover (NC0252)
In conjunction with Three Party service, this service allows
the party currently connected to the controlling party in a
24 three party situation to become the controlling party. The Y N
new controlling party remains connected to the original
controlling party. The held party remains on hold but for the
new controlling party.
Night Service (AR1754, AR1823)
Provides alternative answering arrangements for calls to
25 operators at times when normal operator positions are Y y [7]
unattended.
Centralised Operator
26 Allows a single position to provide operator services for Y y [8]
multiple PBXs.
BTNR 188
CS2000 as CS2000 as
section
Transit Node End Node
DPNSS Feature (DPNSS/DFT to (DPNSS/DFT
DPNSS/DFT) to line)
Traffic Channel Maintenance
27 Maintenance functions for a traffic channel on a single N N
DPNSS link between two adjacent PBXs.
Remote Alarm Reporting
28 Provides a network with the capability of reporting to a Y N
central point alarms raised by any PBX in the network.
Add-On Conference
Permits the controller of a Three Party Service conference
29 Y N [9]
to expand it to four or more parties, depending on the
capacity of the conference bridge in use.
Time Synchronisation
30 Allows time and date to be synchronised between different Y N
PBXs.
Call Back When Next Used (CBWNU)
31 Allows user whose call is unanswered to have call
Y N
completed when the called extension is next free after
being used.
Do Not Disturb
32 Offers the possibility of giving a busy indication to callers Y N [10]
when an extension user wishes not to be disturbed.
Remote Registration of Diversion
33 Allows
an extension or operator on one PBX to set or
Y N
cancel diversion at an extension on another PBX in the
DPNSS network.
Remote Registration of Do Not Disturb
34 Enables operator or privileged extension to invoke or Y N
remove the Do Not Disturb condition on extensions.
Priority Breakdown
35 Enables users of selected extensions who encounter Y N
congestion or busy to break down existing connections in
order to complete their own calls.
Call Back Messaging
36 Allows a caller to indicate to the called party that the calling Y N
party wishes to be called back.
Loop Avoidance
37 y [11] N
Rejection of calls that transit too many legs.
Forced Release
38 Offers an intruding party the possibility of forcing the Y N
release of an unwanted party.
Text Message
Permits an extension user to send textual information to
39 another extension user without the need to occupy a traffic Y N
channel.
Charge Reporting
Allows details of call cost and associated information to be
passed between the parties involved in the DPNSS call,
40 where the call has been made from a DPNSS extension to Y N
a destination which causes the terminating PBX to be
charged for the call, on or after answer.
BTNR 188
CS2000 as CS2000 as
section
Transit Node End Node
DPNSS Feature (DPNSS/DFT to (DPNSS/DFT
DPNSS/DFT) to line)
Network Address Extension
Allows the specification of an address beyond a particular
41 destination within a DPNSS network. This subaddress Y N
represents an entity that can be accessed via that
destination.
Call Park
Allows a caller to be placed on on-hook hold at another
extension, or on immediate hold with warning given to the
42 called party if the called party is busy. It also allows the Y N [12]
calling party subsequently to transfer its own held party to
the called party using signalling defined for the Three Party
service.
Call Distribution
Makes it possible to have calls automatically distributed
43 Y N [13]
among a group of associated users spread over more than
one PBX.
Route Capacity Control
Allows a call to be progressed over a route on which all
44 Y N
allocated capacity is in use, by making use of additional
unallocated capacity, typically at extra cost.
Wait on Busy
45 Enables caller who encounters busy to remain connected Y N
to PBX until called party becomes free.
Call Pick-Up
46 Enables subscriber to answer a call awaiting answer at Y N [14]
another extension.
Travelling Class of Service
47 Enables subscriber away from usual phone to make use of Y N
Class Of Service associated with usual phone.
Number Presentation Restriction
48 Enables subscriber to restrict presentation of identity. Y N
[1] 64K clear channel data calls are not currently supported by the CS2000 implementation of
DPNSS.
[2] Nortel-specific NSI string supported for proprietary networked Message Waiting Indication
service with Meridian Mail voicemail system.
[3] Supported only for busy information
[4] Works functionally but no DPNSS signalling at present and normal ring tone to caller.
[5] Supported for a trunk interworking node (gateway), e.g. ISUP to DPNSS.
[6] Signal is relayed but not acted on to ensure required bearer capability is obtained. Bearer
capability requested may not be provided due to ECAN and/or compression codec.
[7] Supported via call diversion. Registration of Night Service number at originating node (CS2000)
is not supported.
[8] Only mandatory services (Three Party, Call Offer, Redirection, Executive Intrusion, Busy
Information) are supported, and only when CS2000 is not the operator position.
[9] Centrex 3/6 party conferencing provides equivalent capabilities without DPNSS signalling.
[10]Centrex DND provides equivalent capabilities without DPNSS signalling.
[11]Message passed on unchanged, so an extra PBX is transited before message is rejected.
[12]Centrex Call Park provides equivalent capabilities without DPNSS signalling.
[13]Centrex ACD/UCD provides equivalent capabilities without DPNSS signalling.
[14]Centrex Call Pickup provides equivalent capabilities without DPNSS signalling.
DPNSS features
available to
customer group
CS2000
IBN line
Note: Where an Centrex feature must be assigned to a line in order for its DPNSS
equivalent to operate correctly, the DPNSS feature takes on the characteristics of the
Centrex feature. This is the case for EI and EBO. The CS2000 implementation of the
DPNSS EI feature therefore supports only two levels of intrusion, as supported by the
Centrex EBO feature, not the four levels defined for EI in the BTNR.
CS2000 supports interworking between MADN lines (SCA and MCA) and the DPNSS
CBWF feature, as follows (see AJ5403 for a detailed description):
! A DPNSS or DFT caller who encounters a busy MADN group can invoke the
CBWF feature. Free notification is sent back to the caller when any MADN group
member becomes free (MCA) or when the line becomes free (SCA).
! A MADN group member who enounters a busy DPNSS line can invoke the CBWF
feature. Free notification is sent back when the busy called party beomes free, and
causes the MADN callers line to be rung (not all MADN group members lines).
F7.1 Overview
Historically, ISUP network services have been built on top of basic call setup and
clearing. Extra ISUP messages, or extra parameters in basic call messages, are used to
convey service-related information across the backbone network, e.g. calling/called party
information for display. This model of service provision, however, requires
service-specific interworkings to be developed between ISUP and the access interface(s)
for every service supported.
The alternative to developing multiple service-specific interworkings is to provide a
general-purpose ISUP mechanism for conveying service-related information across the
network. With this approach, ISUP does not need to understand the information being
conveyed, only to relay it between two access interfaces that do understand it. This is
known as feature transparency.
The FACILITY and NOTIFY messages and Facility and Notification IEs provide a
generic mechanism for conveying service-related information, but only for ISDN
supplementary services and ISDN access interfaces. They cannot be used to convey
information for proprietary services implemented by PBXs or Centrex switches.
The ETSI ISUP V3 APM (Application Transport Mechanism) has been defined by the
ITU-T to serve as a general-purpose service support mechanism. This is supported by the
CS2000 implementation of ETSI ISUP V2 (which is therefore sometimes referred to as
ETSI ISUP V2+). It comprises the following ISUP protocol elements (there are similar
TCAP elements for circuit-independent calls):
! An Application Transport Parameter (APP) that can be conveyed in the existing
ISUP call control messages IAM, ACM, ANM, CON and CPG.
! An Application Transport Message (APM) that can be sent independently to convey
an APP.
! A Pre-Release Information (PRI) message that can be sent prior to a REL message
to convey an APP.
The information that can be conveyed in an APP depends on the application context.
Each application context has an associated information model that determines the data
types or parameters that can be conveyed in an APP for that context. There are two types
of application context:
! Open application contexts defined by standards bodies. The most important of these
is application context 1 (PSS1), which is used for QFT (QSIG Feature
Transparency). The QFT information model provides definitions for a range of
common data types that are widely used in supporting services; it is not restricted
to providing network support for features supported over QSIG access interfaces.
CS2000 uses QFT data types to support some Centrex services (see section F7.2.1).
! Proprietary application contexts, which allow equipment vendors and network
operators to define information models to support their own services. The UK
regulator has reserved application context 124 for Nortel use, and CS2000 uses it to
support services based on the use of data types that are not defined in the QFT
information model (see section F7.2.3).
Before the ETSI ISUP V2+ APM was available, CS2000 supported the networking of
proprietary services only via the proprietary IBN7 interface, typically by conveying
service-related information in additional IBN7 ISUP parameters and messages. This
implementation of Networked Centrex, however, requires a CCS7 network with an IBN7
signalling backbone. Use of the APM enables network operators to offer Centrex
services to their customers without having to deploy a proprietary signalling backbone.
Note: Use of an IBN7 backbone network is a prerequisite for support of DPNSS Feature
Transparency (DFT). See Chapter F6: DPNSS Features and Chapter E6: DPNSS
Interface for details.
To use the QSIG terminology defined in Chapter E5: QSIG VPN Interface, a DMS
switch that uses QFT to support the networking of VPN services for its directly
connected subscriber lines is providing End PINX functionality. For a detailed
description, see the SIM specifications ETSI ISUP V2+ Application Transport
Mechanism (NIS A246-1bis), QSIG Feature Transparency (NIS A246-1ter) and
ETSI ISUP V2+ EndPINX Functionality (NIS A246-1quat).
For Centrex services with ETSI-defined equivalents (e.g. NRAG/CBWF), QFT carries
any proprietary information that is not required for the ETSI service.
The following table lists and briefly describes the open implementations of Networked
Centrex services that are curently available, indicating for each service which IBN7
feature(s) the open service implementation can replace.
Called Name Display Display name of called party on Network Name Display
alerting
Connected Name Display Display name of connected party Network Name Display
on answer Call Pickup
Display name of called party
Busy Name Display Network Name Display
when call encounters busy line
Networked Message Waiting Notify subscriber that voice mail Networked MWI Activation
Indicator message has been left
Network Ring Again
(open equivalent is Repeat call automatically set up if
Call Completion first call encounters busy Network Ring Again
to Busy Subscriber)
[1] Notify called party that call has Call Forward Universal
been forwarded, indicating Call Forward on Busy
reason and displaying both Call Forward on No Reply
callers number and forwarding
Call Forward partys number. Note: Centrex equivalence,
i.e. conveying private network
[2] Notify caller that call has been numbers, is supported via
forwarded, indicating reason and interaction with NETINFO (see
displaying forwarded-to number. A59022911).
See A59028106 for systematic comparisons between these open ETSI ISUP V2+ APM
service implementations and the original proprietary IBN7 implementations.
For a more detailed description of NETINFO support via the ETSI ISUP V2+ APM, see
A59023093.
For a CS2000 using CS2000 to provide transit PINX functionality, NETINFO parameter
handling is as follows:
! PINX functionality is invoked at a transit node if a call encounters the
VPNXLT/VPNREPL option in table PXHEAD during translations.
! If PINX functionality is not invoked, the node behaves as a standard ETSI ISUP
transit node, and simply relays all feature transparency information without
processing it.
! If PINX functionality is invoked and the incoming IAM does not contain
NETINFO, the transit PINX creates a NETINFO parameter and adds it to the
outgoing IAM.
! If PINX functionality is invoked and the incoming IAM already contains
NETINFO, IBN private network translations are triggered at the transit PINX.
See A59028096 for a full description of the possible scenarios for translation and
NETINFO generation.
For a CS2000 supporting indirect access over non-QFT trunks to a network with an ETSI
ISUP V2+ signalling backbone, the ongoing IAM is populated with NETINFO
information as a result of the screening process. See Chapter F11: Indirect Access for a
full description of indirect access, and A59028079 for information about specific
NETINFO capabilities verified with an ETSI ISUP V2+ backbone.
This chapter provides an overview of CS2000 support for packet-based VPNs (Virtual
Private Networks) that support both voice and data. It begins with a general discussion of
the rationale for such VPNs, then goes on to describe specific VPN telephony services
supported by the VoIP and VoATM applications in ISN07.
F8.1 Introduction
Virtual Private Networking (VPN) is a generic term describing a corporate network
consisting of a combination of public facilities (provided by a network operator) and
private networking facilities owned or leased by the customer. Its primary aim is to use
public network facilities to complement private network facilities, thus enabling
corporate customers to benefit from the advantages of both.
Packet-based VPNs that support both voice and data represent the next stage in network
evolution. They offer the following advantages to network operators, which translate into
cost savings for corporate customers:
! Network capacity is used more efficiently because bandwidth on demand is
provided primarily in terms of packets rather than in terms of circuits. A given
physical circuit is not just potentially available to different customers at different
times; it can simultaneously convey packet data from different customers.
! Network configuration and management are simplified because a single backbone
network is used for voice and data.
! Some or all of the sites in a network can support integrated access to both voice and
data networks. For example, line media gateways supporting telephony can be
attached to the same customer LANs that support other data services, i.e. telephony
can be handled as another data service.
A business may be able to take advantage of VPN even if it could not justify the cost of
private leased lines. VPN can also benefit businesses that are already using a leased-line
network; they can use VPN either to replace their private leased lines completely, or as an
additional option for routing traffic and expanding their network to locations not served
by their leased lines. In the case of a business that already has a corporate data network,
use of integrated access allows a telephony VPN to be built on top of that network.
! Call screening
Call screening enables end-users to implement restrictions on the types of call that
can be made and received by departments and by individual department members,
e.g. to allow only internal calls to be made.
CS2000 supports call screening by associating a Network Class Of Service (NCOS)
value with every customer group. An NCOS value is a number in the range 0-511,
which corresponds to a particular combination of permitted incoming and outgoing
call types. Because every trunk belongs to a customer group, all call originations
from a given trunk can be screened on the basis of the associated NCOS value
before the call even enters translations (see section C3.2 on page 206 for details).
Typically, call screening is used to ensure that an end user belonging to a particular
customer group is allowed to make on-net calls only to end users in the same
customer group.
! Feature transparency
A VPN is a private network in which some parts of the network are non-dedicated
and provided on demand by the network operator. A private network interface may
need to convey additional information in order to support VPN services. Public
network protocols, however, do not directly support such information. To ensure
that VPN information is not lost when a VPN call is routed through a public
network, the service-specific information conveyed in private network messages is
encapsulated in messages that can be conveyed over the public network. ISUP
messages are used to encapsulate information from call-associated messages.
TCAP messages are used to encapsulate information from non-call-associated
messages (virtual calls).
This mechanism is called feature transparency. In ISN07, CS2000 supports two
types of feature transparency:
" QSIG Feature Transparency (QFT) is used to support a range of VPN services
for users served by QSIG End PINXs (Private Integrated Services Network
Exchanges). Over the backbone packet network, bearer QFT (for real calls) is
supported by ETSI ISUP V2+ signalling encapsulated in SIP-T, while
non-bearer QFT (for virtual calls) is supported by TCAP NCAS
(Non-Call-Associated Signalling) conveyed between CS2000 USPs using
TCAP / SCCP / MTP3 / M2PA / SCTP / IP.
" DPNSS Feature Transparency (DFT) is used to support VPN services based
on PBXs served by the UK VPN interface DPNSS, as described in Chapter
E6: DPNSS Interface. DPNSS signalling is encapsulated in
manufacturer-specific operations at the Westell gateway that controls the
DPNSS PBX, and is conveyed over the backbone network using IBN7 ISUP
trunks for which the DFT option has been specified.
A CS2000 running ISN07 can support Centrex as well as PBX-based VPN capabilities,
allowing customers to choose the solution best suited to their requirements for
connectivity and advanced services. A given customer may use both VPN and Centrex to
implement a hybrid VPN. In this case, integration between VPN and Centrex capabilities
is provided by the customer group mechanism. Basic VPN capabilities are provisioned at
a customer group level; additional Centrex services can be provisioned either for
customer groups or for individual users.
Figure 146 illustrates the message flow for a call made from an PRI originator to a private
number. The originating CS2000 recognises this as a VPN number served by another
CS2000. An ETSI ISUP V2+ call is therefore set up to link the two CS2000s and convey
the private information.
ETSI PRI or QSIG ETSI ISUP V2+ signalling ETSI PRI or QSIG
signalling for QFT support signalling
Terminating CS2000
determines whether
originating and terminating
CdPN in IAM is the result of translations. PBXs belong to the same
CgPN in IAM is the result of screening. business group, i.e. have
the same BGID
SETUP IAM with APP
CdPN = 565123
NPI = private CdPN = 7545960000 SETUP
TON = unknown NPI = private
TON = unknown CdPN = 565123
CgPN = 424242 NPI = private
NPI = E.164 CgPN = 691234242
TON = unknown
TON = national NPI =E.164
TON = national CgPN = 424242
NPI = E.164
APP TON = national
CdPN = 565123
NPI = private Because originating and
CdPN and CgPN TON = unknown terminating BGIDs match,
in APP are those CdPN and CgPN
provided by the PBX CgPN = 424242 in SETUP are those
NPI = E.164 provided by originating PBX
TON = national
BGID is obtained
from CS2000 datafill BGID = 87654321
CALL PROCEEDING
ACM with APP
CALL PROCEEDING
APP
APP with no user
info sent to indicate
support for VPN FT
ALERTING
CPG
ALERTING
CONNECT
ANM
CONNECT
Figure 146: ETSI ISUP V2+ support for VPN private numbering
NETINFO
IBN7 ISUP supports the use of the Network Information (NETINFO) parameter in call
setup messages to provide the following VPN information:
! The customer group to which the caller belongs, which determines the availability
of services provisioned against the customer group.
! The Network Class Of Service (NCOS) of the customer, which determines the types
of call that the subscriber can make and receive (see section C3.2 on page 206 for
details of NCOS screening).
NETINFO makes it possible to support customer groups served by more than one node.
In a VPN context, it enables subscribers to have access to the same range of services
regardless of where a call is made from or where a given service implementation resides.
Because H.225 and QSIG are both based on Q.931, H.225 messages can be mapped
on to QSIG equivalents. The operations containing DPNSS signalling are extracted
from H.225 UUI IEs and encapsulated unmodified in QSIG Facility IEs.
! For nodal support of DPNSS Feature Transparency, the CS2000 Core uses
QSIG-to-QSIG interworking to support direct interworking of encapsulated
DPNSS for two PBXs served by the same CS2000. For networked DFT support, the
Core interworks QSIG and DFT trunks and maps QSIG Facility IEs on to Nortel
HNIPs conveyed in ANSI-defined NTPs, thus enabling DPNSS signalling to be
conveyed transparently across the QSIG/DFT interworking.
See section E6.2.1 on page 485 for a detailed, illustrated description of the network
configuration. For a detailed formal definition of DPNSS feature support via IBN7 DFT
trunks, see the Nortel Networks SIM specification DPNSS IBN7 Feature Transparency
(NIS A267-1).
Interworking supported
CentrexIP Customer group and Interworking supported Interworking supported
client NCOS from datafill Selected Centrex features
Full Centrex support Full Centrex support
supported
Interworking supported
Customer group and Interworking supported Interworking supported
PRI Some supp. services
NCOS from datafill Supp. services supported Supp. services supported
supported
Interworking supported
Interworking supported Interworking supported
Customer group and Some supp. services
QSIG Supp. services supported Supp. services supported
NCOS from datafill supported
QFT supported QFT supported
QFT not supported
Interworking supported
Customer group and Interworking Interworking Supplementary services
DPNSS
NCOS from datafill not supported not supported supported
DFT supported
Customer group and NETINFO correctly Interworking not supported NETINFO correctly
NCOS determined by table generated generated
TCNFAST
[1] The NETINFO option in universal translations tables xxCODE/xxHEAD causes AC=124 to be used and
NETINFO to be generated, instead of AC=1 and BGID.
F9.1 Overview
Voice mail allows a user to have incoming calls forwarded to a message desk, to be
notified that recorded messages are waiting, and to retrieve and play back those messages
later. Its operation is illustrated in Figure 147 and summarised below:
! Leaving a message
" An incoming call to a voice mail subscriber is forwarded to the message desk,
e.g. because there is no answer.
" The caller is connected to a recording device and leaves a message.
" The message desk uses the voice mail datalink to activate the Message
Waiting Indicator (MWI) feature on the subscribers line.
! Retrieving a message
" The message waiting indicator (e.g. stuttered dial tone on basic phone) tells
the subscriber that there is a message.
" The subscriber dials a CRR (Call Retrieval Request) code to ask for the
message to be retrieved.
" If CRR billing is active, the switch generates an AMA record for the retrieval
request.
" The switch uses the voice mail datalink to send a retrieval message.
" The subscriber is connected to the message desk recording device via an
message desk voice port, and plays back the message.
" The message desk uses the voice mail datalink to deactivate the MWI feature
on the subscribers line.
Message desk
Stage 1:- Leaving a message interface
Message desk
CS2000
1 Incoming
call Bearer
Voice
ports
paths Recording
Speech path device
through-connected;
caller leaves
3 message
2
No answer or busy;
call forwarded
to voice mail
Voice mail
termination
termination
termination
subscriber
Voice mail datalink
Link
Link
Line
5 4
Message desk sends
Message waiting message waiting ON
indicator (e.g. notification to line
stuttered dial tone)
is activated
Bearer
paths Recording
device
8 Speech path
through-connected;
message played
to subscriber
Subscriber
6 interacts with
switch to request 7 Retrieval message
message retrieval sent to message desk
termination
Voice mail
termination
termination
Line
subscriber
Voice mail datalink
Link
Link
9
Message waiting Message desk sends
indicator is message waiting OFF
10 deactivated notification to line
F10.1 Overview
CS2000 supports three types of conferencing:
! Setting up three-way calls on an ad-hoc basis. Three-Way Calling (3WC) is
supported as a service in its own right. Three-way calling is also used as an
underlying capability by many other services available to residential and business
subscribers. These include Call Hold, Call Waiting, Call Transfer with Consultation
Hold, Three Way Call and Call Park.
! Setting up ad-hoc conferences with more more than three participants (this is known
as station-controlled conferencing). A subscriber who wishes to initiate a
conference first dials a conference code to find out whether there is a conference
bridge available. If so, the subscriber is connected to the bridge and a special dial
tone is played. The subscriber can then add additional parties to the bridge one at a
time, simply by dialling their numbers in response to the special dial tone.
! Setting up prearranged conferences (this is known as meet-me conferencing). A
subscriber who wishes to organise a conference contacts an adminstrator to make a
booking for a conference bridge with required number of ports. The booking
confirmation specifies the number to dial in order to join the conference, and
provides a passcode. Each participant then dials the conference number and enters
the passcode at the prearranged time.
CS2000 supports conference calls with up to 30 participants.
CS2000
Audio
Trunk / Controller
line (AC)
GWCs GWC
H.248 commands,
e.g. Add,
controlling
terminations and
contexts (calls)
Responses
Media gateways
supporting: Media
Trunks server
Lines
Media server supports two-way connections
across the packet network between call
parties and server conference ports
The maximum number of parts on a DSP card is 120. This may be less depending on
factors such as packetisation interval. For information about media servers and
conferencing capacity, see Chapter B3: CS2000 Support for Media Servers.
Network A
Call Default network, e.g. PTT
origination Call
termination
Call routed Transit
to B only if Terminating
switch switch
requested
Network B
Alternative national operator
using IP or ATM packet backbone
Media Media
gateway gateway
CS2000 CS2000
Media Media
Call gateway gateway Call
origination termination
The scenario illustrated in figure 149 and described in section F11.2.1 assumes that the
equipment belonging to a given alternative network operator is dedicated to carrying that
operators traffic and generating revenue for that operator. In some regulatory regimes,
however, it is possible for a network operator to set up a virtual network, without
equipment, by buying capacity from other operators and reselling it. CS2000s deployed
in such a regulatory regime must be able to support carrier selection, as described in
section F11.2.2, even if they are only providing transit functionality.
Note: It is also possible to support indirect access as an IN (Intelligent Network) service.
In this case, a database of user details and authorisation information is maintained
centrally by an SCP, and CS2000 initiates an IN query to the SCP when it recognises an
incoming indirect access call.
Note: The types of screening described above can be complemented by standard COS
screening on a trunk group basis, as follows:
! TRKOPTS option COS can specify a COS value (0-1023) for a trunk group.
! Table COSBLK specifies combinations of orginating trunk group COS and
terminating trunk group COS for which call completion will be permitted.
[1] Additional tables DNSCRN2 to DNSCRN7 can be used to increase the capacity of the CLI screening database.
Table DNSCRMAP determines which table is used. See section F11.3.1.6 on page 640 for details.
[2] To ensure that a replacement customer group and NCOS datafilled in table DNSCRN will come into effect for
post-screening translations, the IBNRX selector in table IBNRTE must be used to initiate retranslation (see
AJ4156 for more details).
Authorisation is successful only if there is an entry for the authorisation code provided
and only if the other items of authorisation information provided match those that are
specified as required in that AUTHCDE entry. The following types of screening are
possible:
! PIN verification (security digits)
The SECDIGS field can be used to specify a Personal Identification Number (PIN)
of up to 4 digits that must be provided. This must exactly match the PIN provided
by the subscriber.
! Account code or Customer Cost Centre (CCC) code screening
The ACCT field specifies whether a Customer Cost Centre (CCC) code of up to 18
digits (to be placed in the billing record) must be provided. If provided, a CCC is
checked for length, and may also be screened via table ACCTSCRN.
! Hotline number
The HOTLINE option and the HOTLN_NUM field can be used to specify a hotline
number for automatic connection.
Additional options that may be specified in table AUTHCDE are:
! CUSTGRP / NCOS
Allows the customer group and/or NCOS associated with the caller to be overridden
! CALLBLK
Allows calls to be blocked in spite of successful screening (e.g. if the subscribers
bill has not been paid). If required, an IBN110 log can be generated to log such a
blocked call attempt.
Two other types of screening may be enforced on a call attempt, though not directly by
table AUTHCDE:
! Region code screening
A customer group may be assigned (and thus restricted) to a particular region.
! Restricted usage screening
The Time Of Day (TOD) routing feature may be used to implement call restrictions
based on date, day or time of day.
[1] Call flow diagrams are provided only for ETSI ISUP in each case, as this is sufficient to illustrate the principles
involved.
USP or FLPP
Called Party
Access
GWC
Ingress in SIP-T
Network path through-connected media
gateway
Optional TBOA
Call in progress
Figure 150: Single-stage CLI-based access over TDM-side ETSI ISUP ingress trunk
USP or FLPP
Subscriber IAM (CdPN = AC)
dials Access
Code (AC) Early ACM
Access GWC
Information provided in-band: gateway
Account code (CCC)
Called Party Address IAM (real CdPN)
ACM
Optional TBOA ANM
ISUP messages
encapsulated
in SIP-T
Call in progress
Figure 151: Account code required access over TDM-side ETSI ISUP ingress trunk
USP or FLPP
Subscriber
dials Access MONA
Code (AC) Early ACM activated
Early ANM
Access GWC
Information provided in-band: gateway
Called Party Number
(other information may also be collected) IAM (real CdPN)
ACM
Optional TBOA ANM
ISUP messages
encapsulated
in SIP-T
Call in progress
Figure 152: CLI-based MONA access over TDM-side ETSI ISUP ingress trunk
USP or FLPP
dials Access MONA
Code (AC) Early ACM activated
Early ANM
ACM
ISUP messages
encapsulated
in SIP-T
Call in progress
Figure 153: Two-stage authcode access over TDM-side ETSI ISUP ingress trunk
The two legs of the call (from the caller to the ingress CS2000, and from the CS2000 to
the called party) are handled as two separate calls. CS2000 sends an early ACM/ANM to
complete backward call setup and obtain the authorisation information. It then initiates
onward call setup, but does not pass on the real ACM and ANM messages received from
the destination exchange when they are received (though they are processed by the
CS2000, e.g. to obtain the ANM charge indicator).
Originating Selected
carrier Terminating
subscriber subscriber
network network
network
NAOC
tariff
database
CGP CDP
Figure 154: Network configuration for NAOC (separate CDP and CGP)
F12.1 Introduction
Intelligent Network (IN) standards define a number of functions (logical entities) and the
way in which they should communicate to support IN services. They do not define what
services should be provided, nor do they define (except at a conceptual level) how
services should be implemented, deployed and managed.
An IN is therefore not a feature set in its own right, but a platform for the centralised
provision of services. It allows new services to be implemented more quickly and
efficiently, since direct support needs to be provided only by a central Service Control
Point (SCP), not by every local exchange.
The protocol used for supporting services is the Intelligent Network Application Part
(INAP), which is fully described in Chapter E3: INAP. INAP operations are used to
convey service-related information across a CCS7 signalling network, between the
CS2000 Service Switching Point (SSP) and the SCP where the service logic and data
reside.
In the IN model of service provision, it is the responsibility of independent service
providers to identify what customers want, and the role of network operators is to enable
them to meet customer requirements. In practice, many network operators will choose to
design and deploy their own IN services to complement or compete with those developed
by service providers. In either case, network operators must not only support IN as defined
in the standards, but also support the rapid and efficient definition, implementation,
deployment and management of IN services. Nortel enables operators to achieve these
dual goals via CS2000 SSP support for the open INAP interface.
F12.2.9 Re-Triggering
The CS2000 SSP allows a call to trigger more than once as an IN call, e.g. when
translations are re-entered after initial IN call rerouting. This allows more than one IN
service to be provided for a given call.
Note: To prevent conflicts, only one SCP dialogue may be active for a given call. If
retriggering is attempted for a call when there is already a dialogue, the call will not
retrigger and will be routed to treatment.
CXR Call Transfer A59033609 IN feature cannot co-exist with three parties all in
conference
DCF Denied Call Forwarding A59033609
DDN Dialable Directory Number
DGT Digitone
DISA Direct Inward System Access
DLH Distributed Line Hunt A59010596
DNH Directory Number Hunt A59010596
HLD Permanent Hold
HOLD ETSI Call HOLD
IECFB Internal/External Call Forwarding A59033609 TDP2 not supported for Call Forward leg
Busy
Internal/External Call Forwarding
IECFD A59033609 TDP2 not supported for Call Forward leg
Do Not Answer
LI Lawful Intercept
Although IN call must be completed before LNR
LNR Last Number Redial A59010596 works, if a call triggers and then is hung up,
previous number is used
MCH Malicious Call Hold A59010596
This chapter discusses call party information services, i.e. services that provide
information about one party involved in a call to another party involved in the call. The
most common example is CLI (Calling Line Identification), which is the provision of the
calling partys number to the called party for display. Such services are described in this
separate chapter because they are not associated with any particular interface, and are
supported to some extent not only by almost every interface supported by CS2000, but
also over interworkings between interfaces.
Note: The chapter is not intended to provide a detailed description of Malicious Call
Identification (MCI), which enables network operators to obtain calling party information
for use in dealing with nuisance calls. Although MCI uses the same mechanisms that are
used to provide calling party information for called parties, it is a regulatory service with
different national implementations, which are discussed in Chapter F14: Regulatory
Services.
The chapter is organised into the following sections:
! Section F13.1: Terminology and Basic Concepts
! Section F13.2: Party Information Services
! Section F13.3: Functional Overviews
! Section F13.4: Parameters for Conveying Party Information
! Section F13.5: Delivery of Party Information for Display
! Section F13.6: CS2000 Provisioning
! Section F13.7: Per-Interface Summary of Capabilities
VPN Calls
The description above applies to a residential subscriber making a call over the public
network.
For VPN callers, private information may be available to complement the public network
NN/PN information.
VPN Calls
The description above applies to a residential subscriber receiving a call over the public
network.
For VPN users, private information may be available as an alternative to the public
network NN/PN information.
Logically, this is simply the inverse of the CLI scenario, but fewer interfaces support
COL-type services, so the potential capabilities of a given interface (in terms of its ability
to convey information) are often not used. This is primarily because obtaining called party
information is not vital unless some form of redirection takes place (see section F13.3.3),
because until then the number dialled identifies the called party, and this can simply be
echoed back to the caller.
Note: In some cases, e.g. IBN7 support for connected number display, no information is
provided backwards until / unless redirection takes place.
See Table 66 on page 691 for a summary of the COL/TLI capabilities provided for call
terminations for each supported interface. At the terminating node, the issues are:
! Whether connected party information can be obtained (Y / N). If Y (which implies
support for some type of COL service), then
" Type of information
# Unique CLI / NN
# PN as alternative to NN
# Non-unique / default CLI
# Name
" Derivation of information
# Provided over interface
# Obtained from switch datafill
See Table 65 on page 688 for a summary of the COL/TLI capabilities provided for call
originations for each supported interface. At the originating node, the issues are:
! Whether called party information can be provided (Y / N). If Y, then
" Type of information
# Number (as provided, or reverse-translated)
# Name (as provided, or derived from number provided)
" Mechanism for providing information
For the trunk interface, the issue for public network calls is whether the interface has a
mechanism for conveying party information (NN/PN) and any related blocking
information. For VPN calls, the issue is whether the interface supports any encapsulation
mechanism for private network information.
Origination Termination
Fwd/Xfer
Twin capabilities:
! Providing calling party information forward, as per section F13.3.1 on page 666,
plus indicating that redirection has occurred and providing equivalent information
for the redirecting party
Note: After redirection, the information provided for the calling party remains the
same, i.e. if a PN is provided it is this PN that will be presented to the new called
party. For the redirecting party, however, the number provided will always be the
NN rather than the PN.
! Providing connected party information backward, as per section F13.3.2 on page
668, plus indicating that redirection has occurred and providing equivalent
information for the redirecting party
A distinction must be made between support for forwarding / redirection functionality,
which is supported over most interworkings, and the provision of information about the
forwarding, for which support is more limited. In particular, it must be noted that full
interworking between Centrex and ISDN call redirection services is not supported, e.g.
notification of ISDN forwarding will not be provided over IBN7 trunks, and notification
of Centrex forwarding will not be provided over ETSI ISUP trunks.
This format is also used for Connected Number, Original Called Number, Redirecting
Number and Redirection Number. The main functional elements are:
NOA Subscriber number
National significant number
International number
Unknown (relay only)
NPI E.164 (only accepted value for ETSI ISUP on CS2000)
Private (not in ETSI ISUP, relay only in IBN7)
Unknown (not in ETSI ISUP, relay only in IBN7)
Note: Only trunks with VPN capabilities (e.g. IBN7) provide direct support
for conveying private numbers over the network. Private numbers can,
however, be made available at the far end via reverse translation of public
network numbers. Indirect support for conveying private numbers over the
public network requires some sort of encapsulation mechanism, e.g. QFT.
PI Presentation allowed
Presentation restricted
Address not available (not in EISUP V1, relay only in IBN7)
SI Network provided (NP)
User provided, verified and passed (UPVP)
User provided, verified and failed (not in EISUP V1, relay only in V2)
User provided, not verified (relay only in EISUP V2)
(Note: SI bits are Spare in IBN7)
This is identical to the Calling Party Number parameter format, except for the extra octet
at the start, which indicates the type of additional number being provided.
NQI Additional called number
Additional connected number
Additional calling party number
Additional original called number
Additional redirecting number
Additional redirection number
IBN7 and ETSI ISUP V2 use this parameter with NQI indicating "additional calling party
number" to support the conveying of a Presentation Number, if available, in addition to
the Network Number (which is conveyed in the CgPN parameter).
F13.4.2 TUP
Party information functionality for BTUP is also affected by some fields of the
IAM/IFAM Message Indicators parameter, which has the following format:
Bit
8 7 6 5 4 3 2 1
Octet
1 Reserved EDI Calling Party Category (CPC)
Message indicators
2 H G F E D C B A
Prot. ind. MDG Reserved PA ind. I/W ind. Int. ind. CBI CLI ind.
3 Message indicators I to L Service Handling Protocol (SHP)
4 Interconnect-Specific Information (ISI) Message indicators M to P
5 PNI Call Path Indicator Routing Control Indicator
F13.4.3 ISDN
This format is also used for Connected Number, Original Called Number, Redirecting
Number and Redirection Number. The main functional elements are:
TON Subscriber number
National number
International number
Network-specific number (e.g. operator)
Unknown
NPI E.164
Private
Unknown
PI Presentation allowed
Presentation restricted
Address not available
SI Network provided
User provided, verified and passed
User provided, not verified
Note: French ISDN (Numeris) allows two calling party numbers to be conveyed in a
SETUP message.
F13.4.3.2 Encapsulation of Private Party Information using the ETSI ISUP APM
The capability that underlies CS2000 support for open VPN implementations is the ETSI
ISUP Application Transport Mechanism (APM). This is an ETSI ISUP V3 capability, but
CS2000 implements it by means of extensions to ETSI ISUP V2; the extended version of
ETSI ISUP V2 is referred to as ETSI ISUP V2+.
APM provides support for the key VPN capability of private numbering plans, and also
allows service-related information (typically provided in Facility or Notification IEs over
the access interface) to be conveyed transparently across the network. Specifically, the
Application Transport Parameter (APP) can be conveyed in existing ETSI ISUP V2
messages or in an Application Transport Message (APM).
Note: Use of the APM with QSIG is referred to as bearer QFT (QSIG Feature
Transparency).
F13.4.4 DPNSS
The mandatory OLI in the incoming ISRM is always the private network number, e.g.
PBX prefix plus extension, not the public DN. Because the private number can be
guaranteed to be unique only within the private network, it cannot be used directly as a
public network CLI. It is handled as follows:
! The SCREEN option of table TRKGRP can be used to reformat the incoming
private number into a public network CLI, and to check the validity of the resulting
number against table DNSCRN (see AH5121).
! If screening/reformatting is not requested (or if the reformatted CLI fails screening),
the user-provided OLI is discarded. A default PN will then be obtained from table
TRKGRP if one has been specified via DEFLTPN. Otherwise, the default CLI from
table TRKGRP is the only CLI available.
! If screening is successful, the SCRNPN option in TRKGRP determines whether the
user-provided number is treated as a PN or an NN:
" If SCRNPN is specified, the user-provided number is treated as a PN. The NN
is obtained from table TRKGRP option DEFLTCLI.
" If SCRNPN is not specified, the user-provided number is treated as an NN. A
default PN will be obtained from table TRKGRP if one has been specified via
DEFLTPN.
PI and CLIP datafill in TRKGRP determines whether the PN/NN is available for display
or suppressed. If the release/suppress status is a default rather than a permanent setting, it
can be overridden on a per-call basis via dialled prefix digits (see AJ5429).
The caller information provided for the outgoing call depends partly on whether the call
remains within the private network or is routed through the public network, and partly on
the capabilities of the outgoing interface, as follows:
! Public / private call
For a call that remains within the private network (DPNSS<->DPNSS direct or via
DFT), the user-provided private network number is provided as the OLI in the
(encapsulated) onward ISRM. Otherwise, it is discarded.
! Interface capabilities
" If the interface can handle both a PN and an NN, both are provided if
available.
" If the interface can handle only one CgPN parameter, the PN is provided in
preference to the NN if both are available.
For private network calls, DPNSS also supports the provision of the private called number
by means of the Connected Line Identifier (CLI) in the backward NAM.
Table DNREVXLA
Reverse translator name
from table CUSTNTWK RXLANAME
Yes
Calling number
Is there another No within a REGION
RESULT on list of Use DELDIGS,
digit range?
RESULTS? PRFXDIGS,
No Yes and OPTPRFX
to format CLI
Called number into diallable
Calling Number Yes
in same form for
unchanged No region? called party
Table 64 is a matrix summarising support for the provision of call party information
across interworkings. It includes three types of cross-reference for more details:
! Cross-references to Table 65 for originating agent information (refs o1, o2 etc)
! Cross-references to Table 66 for terminating agent information (refs t1, t2 etc)
! For information about specific interworkings, the matrix cell is shaded to indicate
that there is a corresponding interworking note in Table 67.
Note: Provision of party names in addition to PN and/or NN is supported only for
proprietary interfaces (IBN lines and IBN7 trunks).
IBN7 ISUP t8
EISUP V1 t6
EISUP V2 t7
UK ISUP t9
IBN line t1
DPNSS t5
agent
BTUP t10
FTUP t11
Originating
QSIG t4
ACD t2
PRI t3
agent
IBN line o1 Y Y Y Y y y Y Y Y Y y
ISDN PRI o2 Y Y Y Y Y y Y Y Y Y Y
QSIG o3 Y N Y Y N y Y Y N N N
DPNSS o4 y Y Y N y y Y Y Y Y N
ETSI ISUP V1 o5 y y y y y y y y y y N
ETSI ISUP V2 o6 Y Y Y Y Y y Y Y Y Y N
IBN7 ISUP o7 Y Y Y Y Y y Y Y Y Y Y
UK ISUP o8 Y Y Y N N y Y Y Y Y N
IUP / BTUP o9 Y Y Y N Y y Y Y Y Y N
Provision of
party
Provision of No support
Legend Y = NN and/or PN y = information N = for CLI
partly
fully supported supported
provision
(NN, not PN)
Regulatory services are features that are not associated with a particular network operator
or signalling system, but are specified by a regulatory body and must be supported
throughout the public network regulated by that body. Some of them are CEPT
(Conference of European Post and Telecommunications Administrations) services or
have CEPT equivalents; others are specific to a particular country.
The chapter is organised into the following sections:
! Section F14.1: Special Call Types
! Section F14.2: Call Tracking and Supervision Features
! Section F14.3: Charging and Billing Features
! Section F14.4: Network Interconnect Features
! Section F14.5: Miscellaneous Features
Note: Some ISDN supplementary services can also be regarded as public network
features, either because they provide ISDN equivalents of public network features (e.g.
MCID) or because (as in the case of AOC) support for them is a regulatory or de-facto
regulatory requirement in some national markets. For information about CS2000 support
for such ISDN services, see Chapter F4: ISDN Supplementary Services.
Packet network
LI
target
Monitored call CS2000
Media
gateway GWC
Transit networks
PSTN/ISDN PSPDN
Links to LEA site
(PRI, BRI or analogue) X.31 X.25 / IP
Law
Enforcement FTAM / FTP
responder
Agency (LEA)
Recorders
Feature activation while a call is being monitored is appropriately reflected via the CCC
and CDC. If a party being monitored is put on hold, for example, the CCC recording
would register silence, and a CDR CONTINUE record would be generated to record Call
Hold activation. The LI service can also be used to monitor the (de)activation and
interrogation of services by an LI target.
The service logic for Lawful Interception is distributed between the CS2000 Core, the
SDM and the UAS, i.e. each of these network elements implements a different part of the
LI application.
Specially authorised operators at the telco site use the LI provisioning interface on the
CS2000 to provision monitoring orders against a target, i.e. to specify access interfaces to
be monitored. At the CS2000, the LI application then sets up a CCC and CDC whenever
there is a call to or from a target. As an option, operators can limit monitoring to the
delivery of call-related data, with no recording of call content, or vice versa.
The table below summarises the access interfaces for which CS2000 allows Lawful
Interception to be specified in ISN07, and the other interfaces for which interception of
calls to/from a monitored access interface is supported. See A59024510 for more details.
IBN line
Yes Yes Yes Yes Yes
(Centrex or CEPT) [1]
Note: Lawful Interception is supported not only for calls between two media gateways
served by the same CS2000, but also for calls interworked to another CS2000 by means
of ISUP signalling encapsulated in SIP-T. See A59035246 for further information.
ISN06 feature A89007461 extended the existing PCA implementation to eliminate some
limitations and restrictions and be fully compliant to the German Telecommunication
Decree TKV 18. Specific enhancements:
! Mid-call announcement support
" Playing a mid-call announcement if the payment ceiling limit is reached
during a call.
! Selective forced release
" Selective forced release functionality (call setup) to disconnect
limit-exceeded subscribers for specific call classes at the beginning of a call
" Selective forced release functionality (mid-call) to disconnect limit-exceeded
subscribers for specific call classes during an active call
! Improved scalability
" Allowing PCA call charges to be tracked for multiple lines / DNs against one
PCA base DN.
" Introducing PCA support for charge-free numbers.
" Introducing support for all world currencies types
! Improved agent support
" For the nodal version (combined CGP/CDP tariffing source), PCA
functionality is enhanced to support interworking with all ETSI ISUP agents,
including national variants.
" PCA functionality available to V5.2 IBN originating agents.
F14.4.6.1 Overview
Number portability allows a subscriber to change network operators, i.e. to be served by
a CS2000 belonging to a different operator, while retaining the same Directory Number
(DN) as before the move. Support for number portability is a critical factor in enabling
alternative network operators to attract both business and residential customers from the
established national network.
Numbers moved between network operators in this way are referred to as ported
numbers. Such ported numbers may be geographic numbers identifying individual lines
or PBXs, or non-geographic numbers identifying Freephone or special-rate services. The
porting of geographic numbers is referred to as Local Number Portability (LNP).
A CS2000 that is to support number portability must have access to a database that
provides the following information:
! A list of ported numbers.
! For each ported number, the identity of the network that currently serves the ported
number.
! Information about how to route calls to each network serving porting numbers.
The CS2000 must also have some mechanism for determining when ported number
database queries should be made.
Figure 160 illustrates the operation of the number portability service at a logical level, for
a CS2000 with its own number portability database.
Number portability
database
Three functions:
To identify any number that has
been ported.
To indicate which network
currently serves the ported
number.
To route calls to ported numbers
to the appropriate network.
CS2000
NICRF
Incoming
call leg PNRF Onward Outgoing
routing call leg
Table PNSCRN
Ported
DN in/out NIC
Table PNINFO
NIC XLA Options
" SETCDN, which allows called party number characteristics (e.g. NOA) to be
modified for the outgoing call leg.
" NONICPFX, which prevents the NIC from being prefixed to the called party
number in translations, or captured in the Terminating Open Digits field of the
AMA record for the call.
" NICOUT, which delays the prefixing of the NIC to the called party number
until immediately prior to digit outpulsing. This also prevents the NIC being
captured in the Terminating Open Digits field of the AMA record for the call.
" AMAXLAID, which specifies an index into table AMAXLAID that can be
used, for example, to trigger an AMA record or change the call code.
" NPBILL, which causes the NIC and related number portability information to
be stored in a Type 611 AMA module.
Note: Table PNSCRN should have entries for every ported DN that a given operators
switches may encounter. Its contents should therefore be identical for all the
Communication Servers owned by a given operator, and it is expected that this will be
achieved by frequent co-ordinated downloads. The contents of table PNINFO, on the
other hand, will vary from CS2000 to CS2000 because routing information is
node-specific; this information, however, is relatively stable.
Database queries can be triggered in either of two ways:
! PNRF selector encountered in translations
Table PNSCRN is checked when the PNRF selector is enountered in an xxHEAD
or xxCODE table during translations.
The INSNNG (Insert National Numbering Group) refinement of PNRF allows calls
originating from local lines to be prefixed with the National Numbering Group (also
referred to as the Area Code) prior to the search of table PNSCRN. If a match is
found in table PNSCRN for the prefixed number, the prefix is retained for the
remainder of translations.
! NICRF selector encountered in translations
If the NIC for a call to a ported number is already known, it is possible to bypass
table PNSCRN and proceed directly to the retrieval of routing information from
table PNINFO. This would typically be the case with a transit call, where a
preceding switch has already determined that the called party number is a ported
number and prefixed it with the correct NIC. Such direct access to table PNINFO is
triggered when the NICRF selector is enountered in an xxHEAD or xxCODE table
(RTE or CONT selectors) during translations.
F15.1 Introduction
Multimedia services enable blended users to have screen-based interactive access to
databases and media sources while simultaneously participating in a VoIP phone call. The
interactive access and use of the phone are co-ordinated. In the case of a call between two
blended users, interactive collaboration is possible because both users are operating in the
context of the same multimedia session.
The following list summarises some of the multimedia service capabilities that can be
made available to blended users.
! For a call between two blended users, e.g. between two users belonging to the same
enterprise network, various types of interactive collaboration are possible:
" File transfer
" Web push
" Whiteboard sharing
" Clipboard transfer
" Instant messaging
! For a call from a non-blended user to a blended user, e.g. an incoming call to a
multimedia-enabled call centre, the call centre agent is connected to a multimedia
session. Capabilities available include being able to check on-line databases for
information about the caller or information that would enable answers to be
provided to queries from the caller.
! For a call from a blended user to a non-blended user, e.g. a call from a
multimedia-enabled sales centre to a potential customer, the sales agent is
connected to a multimedia session. Capabilities available include being able to
check on-line databases for detailed product and service information, information
about the called party or information that might be of interest to the called party.
Figure 162 illustrates the logical configuration used by CS2000 to give blended users
access to multimedia services.
CS2000 MCS5200
Call processing
PRI
SIP-T
Access to multimedia
services via RAIDer
client window
Blended user
With effect from ISN07, CS2000 supports ADSL (Asymmetrical Digital Subscriber Line)
access to the backbone packet network for data sessions with private intranets and/or the
public internet.
ADSL support is provided by large carrier-located line media gateways (MG9000s), as
described in section B2.8 on page 119.
Digital Subscriber Line technology exploits unused frequencies to support simultaneous
transmission of voice and high-speed data over conventional copper telephone lines. The
service is "always on", meaning that subscribers don't need to dial in or wait for call
set-up.
ADSL is so called because it allows data to be downloaded much faster than it can be
uploaded (6Mb/s downloading vs 640Kb/s uploading), reflecting what users typically
require. ADSL is defined in ITU-T Recommendation G.992.1 and ANSI Standard
T1.413-1998.
F17.1 Overview
RAS (Remote Access Service) means support for dial-up access to internet and/or intranet
sessions. CS2000 supports it by means of TDM-side CCS7 trunks terminated on the
CVX1800 media gateway described in section B2.11 on page 130. Because CVX1800
can also support VoIP voice calls, it is said to provide Universal Port (UP) capability.
Note: CS2000 support for UP capabilities has been tested and verified for deployment
only in a specific customer network, and is not generally available in ISN07.
The protocol used for RAS signalling between the GWC and the CVX1800 UP gateway
is DSM-CC version 5.2, as described in Chapter D13: DSM-CC.
When a CVX1800 receives an incoming call over a TDM-side CCS7 trunk (IUP/BTUP
or UK ISUP), CS2000 translations determine whether the call is a voice call or a RAS call.
In the case of a voice call, the terminating media gateway is identified and call setup
proceeds in the usual way. In the case of a RAS call, the CS2000 GWC uses DSM-CC to
tell the CVX1800 to terminate the call on one of its modem ports, and to specify the
internet / intranet destination (IP address and port number) with which a data session
should be initiated.
RAS functionality is provisioned by datafilling the RAS access code (ISP DN) on the FTR
selector of a customer group in table IBNXLA.
Note: RAS calls are single-ended, i.e. only the originating CVX1800 gateway is
involved.
Pre-authorisation is performed by a CVX Policy Manager (CPM) attached to the
CVX1800. Caller authentication and authorisation is performed by a Remote Access
Dial-In User Services (RADIUS) server connected to the internet / intranet destination.
When a session has been established, a dial-up user can download and upload data, send
and receive email, and make use of shared resources. When a session is complete, the
RADIUS server provides call accounting information to the network operator or ISP.
Figure 163 illustrates the logical network configuration used to provide RAS support for
a CS2000 solution. RAS bearer traffic from the PSTN terminates on a modem port in the
CVX1800, from which a connection is set up to the customers IP network or to the public
internet. Network signalling between the PSTN and CS2000 can be either IUP (BTUP) or
UK ISUP.
GWC-gateway
signalling
(DSM-CC)
CVX
Policy RAS authentication
PSTN CCS7 Manager
signalling (CPM)
(IUP / ISUP)
IP core network
Intranet data session
PSTN CVX1800
PSTN bearer channel RAS
media
gateway
Internet data session
Internet
Figure 163: CS2000 support for RAS via CVX1800 gateway
The CVX1800 uses DMS-CC messages to keep the GWC informed about the availability
of RAS modems, VoIP modems and HDLC terminations.
If no RAS modems are available, the GWC will not initiate any new RAS calls, but can
continue to initiate VoIP calls. Similarly, if no VoIP modems are available, the GWC will
not initiate any new VoIP calls, but can continue to initiate RAS calls. If no front-end
processor is available, no new calls of either type will be initiated.
When packet network call setup cannot be completed for an incoming call attempt
received by a CVX1800, CS2000 indicates this by sending back an REL message with a
release cause of CI_TEMPORARY_FAILURE (for a UK ISUP call) or
NTWK_OUT_OF_ORDER (for a BTUP call).
Regulatory Services
Centrex CLF (Calling Line Flash for MCID) Y
ELN (Essential Line) Y
CS (Carrier Selection) Y CIC plus 30-digit DN
LNP (Local Number Portability) Y
Network Services
DID (Direct Inward Dialling) Y
DOD (Direct Outward Dialling) Y
DISA number plus 30-digit
DISA (Direct Inward System Access) Y
DN
Miscellaneous Services
SDN (Secondary Directory Number) Y See A59034400
WUCR (Wake-Up Call Request) Y
CEPT services
ICWT (International Call Waiting) Y
I3WC (International Three Way Call, including
Consultation Hold) Y
Figure 164 summarises VPN access and the relationship between private and public
numbering plans.
PSTN
PSTN numbering plan defined by regulator within E.164 framework.
Numbers have three elements:
Area code, i.e. Numbering Plan Area (NPA) or National Number Group (NNG)
Local Exchange Code (LEC)
Local Number identifying subscriber line, PBX or PBX/Centrex DDI extension
VPN
No fixed rules for VPN numbering plans.
CS2000 supports numbers with standard length of 2-7 digits,
typically with two elements:
Prefix (location code) identifying node (e.g. PBX) or logical group of lines
Extension number identifying PBX extension or Centrex line
Operator / Operator /
attendant attendant
Extension on Extension on
same node same node
and with same and with same
location code location code
G2.1 Overview
A toneset is a complete set of the tones required to enable a CS2000 and its media
gateways to fulfill a particular network role. Such a toneset comprises the following
elements:
! Tones used in dialling and call setup, for which three international standards have
been defined:
" DTMF (Dual-Tone Multi-Frequency) tones
" MF (Multi-Frequency) tones
" MFC (Multi-Frequency Compelled) tones
Note: There are no applications supported in ISN07 that use MF or MFC tones.
! Event indication tones (also referred to as supervisory tones or audible tones),
which are are provided in-band to indicate the occurrence of call processing events,
e.g. dial tone, ringing tone and busy tone. Although international standards have
been defined, there are national variations in:
" The range of tones that must be supported in each national network.
" The characteristics of the supported tones, i.e. their frequency, level and
cadence.
In the CS2000 network architecture, tones are generated by media gateways rather than
by the CS2000 itself. They are played over TDM-side trunks or analogue lines in response
to requests initiated by CS2000 call processing, using the GWC to send appropriate
device control messages to the media gateway handling the bearer connections for the
call. No packet network media resources are used.
Note: Tones can also be generated by a media server such as the UAS (Universal Audio
Server). Although the UAS is primarily designed to support announcements, it can be also
used to support tones by recording them as announcements on the UAS and datafilling
them as announcements on the CS2000.
Table 73: CS2000 media gateway support for tone packages in ISN07
Tone package PP7480 and PP15000 PVG support
Tone Generator Package Yes
Basic DTMF Generator Package Yes
Call Progress Tones Yes
Expanded Call Progress Tones Yes
Basic Services Tones Yes
Expanded Services Tones No
Operator Tones No
Conferencing Tones No
Expanded Conferencing Tones No
Diagnostics Tones No
Carrier Tones No
Intrusion Tones No
Business Tones No
MTA cable line gateways support tones defined as signals in the Line Package of the NCS
protocol specification.
Customer LAN line gateways (Ambit, Askey and Mediatrix) support the tones specified
in the DTMF Package, Generic Media Package and Line Package of MGCP.
G2.4.4 Provisioning
The ultimate aim is for the provisioning of tones in a CS2000 network to be based on the
co-ordinated downloading of tone packages to media gateways from a central database,
but in ISN07 the following restrictions apply:
! All tonesets supported by the PVG are hard-coded, i.e. pre-defined in the PVG
software load. Tonesets can be separately provisioned on an E1 carrier basis, or one
toneset can be provisioned for the media gateway as a whole.
! Tonesets supported by customer LAN and cable line gateways are hard-coded.
! Tones supported are those that can be datafilled in table TONES, plus the following
tones datafilled in table STN:
" Call Waiting
" Distinctive Call Waiting
" Teen Service/Enhanced Call Waiting
For more information, see A59022704.
! Table ANNPHLST
This is the mechanism used to assemble complete announcements from separate
phrases and variables. An announcement may consist of up to 16 phrases, which are
listed in order in table ANNPHLST using the names assigned to them when
recorded. The CLLI of an announcement and the ANNMEMS phrase list index are
used to retrieve the names of its consituent phrases from table ANNPHLST.
! Table ANNAUDID
Because the media server does not recognise the CS2000 names for announcement
phrases, table ANNAUDID maps the phrase identifiers datafilled on CS2000 to the
audio segment identifiers that have been separately provisioned on the media server.
This enables the media server to retrieve, assemble and play the correct
announcement in response to a CS2000 request.
See A19013546 for a detailed description of announcement datafill, including ISN06
enhancements designed to simplify and standardise the datafill process.
(all off PVGs) (both off PVGs) (all off PVGs) (all off PVGs) (all off PVGs)
Lines off
customer LAN Lines off cable
Lines off
gateways (IADs) access network customer LAN
Line access N/A N/A gateways
gateways (IADs)
V5.2 lines off (MTAs)
PVGs
CentrexIP
Enterprise N/A N/A N/A N/A H.323
service access
DPNSS
[1] VToATM is also referred to as VToAAL2, because it uses AAL2 (ATM Adaptation Layer 2) bearer connections.
International network
National National
network A network B
In ISN07, CS2000 supports international trunks only on the TDM side. They are
distinguished by setting COFFTYPE = INTL in table TRKGRP.
Service profile table CLISRVPF [3] Service profile associated with screened CLI
[1] See section C3.5.5 on page 214 for information about CALLCNTL and Universal Screening.
[2] See section F11.3.1.1 on page 636 for information about table DNSCRN.
[3] See section F11.3.1.4 on page 638 for information about table CLISRVPF.
The SETCODEC option specifies the CALLTYPE of the current call. This CALLTYPE
is an index into table CODEC, which in turn specifies the codec to be used for the call.
CS2000 Core communicates this alternative codec to the GWC during call setup. It takes
precedence over the codec(s) specified in GWC datafill, and is used by the GWC during
codec negotiation.
The following limitations apply to use of the SETCODEC option in ISN07:
! The only codec that can be selected via translations is the network default (G.711
a-law or G.711 -law, depending on network configuration).
! SETCODEC does not allow an alternative packetisation rate to be selected, only an
alternative codec.
G4.3.3 CS2000 Support for RFC2833, T.38 and Comfort Noise (CN)
CS2000 allows GWCs to request the use of RFC2833, T.38 or Comfort Noise (CN)
insertion on calls to/from a media gateway provided that the far-end media gateway also
supports it.
! RFC2833 is an IETF-defined standard for the transparent transport of DTMF tones
over IP.
! T.38 is an ITU-defined standard for the transparent transport of Group 3 fax calls
over IP.
! Comfort Noise is random noise that is applied to a connection to reassure the user
that it is still alive when use of silence suppression means that no voice packets are
being received.
These capabilities are supported for the following media gateway types:
! PVG
! MG9000
! Customer LAN gateways
! Cable gateways
The GWC requests the use of a given capability (RFC2833, T.38 or CN) by including
appropriate information in the LCO (Local Connection Options) parameter of the initial
CRCX (Create Connection) command sent for a call. The SDP included in the gateways
response indicates that it can support the requested capability. If the same process at the
far-end gateway indicates that it too can support the requested capability, it will be used
for the call. The process is a refinement of the codec negotiation process described in
section G4.3.1 on page 751.
Public addresses
NAT / NAPT
provide externally device Private addresses visible
visible points of contact only within private network
Mapping table
NAT / NAPT device treats
public addresses as a At a given moment, only a
pool of resources to be subset of private network
dynamically assigned and hosts have a link with the
mapped as required public network
For simplicity, it is common to refer to firewalls and to NATs as if they were devices, but
in practice both types of functionality are often provided by a single device, e.g. many
firewalls also provide NAT functionality.
Figure 167 is a simplified network diagram that illustrates the different types of
communication involved in an enterprise VoIP solution.
Non-IP
VoIP address domain, addressing PSTN
including CS LAN and PVGs
Middlebox
As shown in Figure 167, the carrier network must be connected to multiple enterprise
networks, each secured by a firewall and typically also by a NAT. These networks must
be connected to the carriers managed IP network, which is in turn secured by the carriers
firewall. The network containing VoIP components (the CS LAN and large telco-located
media gateways) is also connected to the carriers managed IP network; this connection
may be direct, or may involve additional firewalls, but does not involve additional NAT.
In order for VoIP connections to be set up across these various networks, both signalling
and RTP media streams must traverse these firewalls and NATs transparently.
By default, the need to traverse firewalls and NATs would make it impossible to support
VoIP across network boundaries, which would prevent direct VoIP interworking between
carrier and enterprise networks. To enable TSPs to deliver enterprise VoIP solutions,
therefore, it is necessary to devise mechanisms that permit firewall and NAT traversal for
signalling and media streams without impairing the security of TSP or enterprise
networks.
NAT address binding is typically dynamic, and is done at the start of a session. A given
address binding may support multiple sessions. Once a local address is bound to a global
address, all subsequent sessions originating from the same local address or directed to the
same local address will use the same binding. When the last session using an address
binding is terminated, the binding is released so that the public address can be re-used.
of its ports to determine their origin, and can thus work out the destination to which return
packets in the other direction should be sent. Two media proxy ports are used in handling
a typical call, each presenting an interface to one of the endpoints involved in the call, and
there is a connection across the media proxy between the two ports to support end-to-end
communication between the two packet network endpoints.
If a GWC knows that a given gateway is behind a NAT, it can insert a media proxy into
a call as a destination for media packets from that gateway, and the media proxy can then
discover the public NAT address from which those media packets are being sent. The
media proxy can then receive media packets from the far-end gateway and send them to
the correct public address on the NAT, which uses the previously created NAT bind to
send the media to the private network endpoint behind the NAT. Two-way media streams
for calls involving media gateways behind NATs can thus be set up, provided that media
packets are routed via the media proxy.
To enable CS2000 GWCs to determine whether a media proxy needs to be inserted in a
given call, each GWC stores the following data:
! Information about all the middleboxes in the network, including NATs.
! Information about each media proxy available to the GWC.
! Information about which middlebox(es), if any, need to be traversed to reach each
gateway or remote CentrexIP client in the network.
Using a GWC-controlled media proxy to support NAT traversal for media streams means
that no changes are required to media gateway or NAT functionality. In particular, it does
not require gateways to be aware of network topology and middlebox deployment. It is a
scalable solution with no dependencies on factors outside the network operators control.
G5.4.3 MIDCOM
Nortel Networks is an active participant in the IETF Middlebox Communications
(MIDCOM) working group, whose goal is to provide a standards-based solution for NAT
traversal problems. This involves the definition of a protocol to allow an application such
as a Call Server, SIP Prox, or Media Endpoint to control and obtain information from a
middlebox such as a NAT or firewall. This control function would, for example, make it
possible to have firewall pinholes determined on a per-flow basis, or to obtain
dynamically allocated NAT bindings.
This solution, however, is still some time away. The MIDCOM working group is still in
the protocol definition stage. Once defined, the protocol will need to be implemented,
then deployed via upgrades to currently deployed NATs and firewalls.
There is, however, an immediate need to deploy networks in existing environments,
complete with a wide range of different types of NAT and firewalls. This is the rationale
for Nortels implementation of a media proxy solution that solves NAT traversal
problems today, in a Pre-MIDCOM environment.
Core
network
Distribution
network
PVGs
Access
network
Core network
(bandwidth assumed to be unlimited)
Link 1 Link 5
Enterprise Enterprise
network A network B
Link 2 Link 6
Site A1 Site B1
Link 3 Link 7
Media gateways Media gateways
Site A2 Site B2
Media gateways Media gateways
Link 4 Link 8
Site A3 Site B3
Media gateways Media gateways
The logical model that VCAC uses is based on the links between the sites. Gateways are
described as being behind a particular link. So, in Enterprise A in Figure 170, a gateway
at Site A3 is behind link 4, which is behind link 2, which in turn is behind link 1.
A link with restricted bandwidth is refered to as a Limited Bandwidth Link (LBL). The
bandwidth restriction may be physical (e.g. an ADSL line running at 500Kb/s) or
contractual (e.g. a subscriber who has purchased a maximum of 1Mb/s of simultaneous
VoIP calls). In either case, the capacity available to reach LBL can be defined (see Section
G6.2.2: GWC Support for LBL Traversal and VCAC on page 767 for more details).
The logical network model is a tree structure made up of LBLs in accordance with the
following rules:
! A top level LBL must be connected to a non-bandwidth constrained "core network".
! An LBL can have only one parent, either an LBL closer to the core network or the
core network itself.
! An LBL can have any number of children (subject to the maximum number of LBLs
that may be datafilled per GWC).
These rules mean that:
! There can be no circular network paths
! There can only be one route from a particular LBL back to the core network
! Any gateway will have a single path through the model to the core network, and to
any other gateway that is within the model
Gateways can be added to any LBL in the logical model. An LBL can have any number
of gateways hanging off it. This is usually described as having gateway leaves on the
LBL tree.
Note: PVG and UAS/AMS GWs are assumed to be within the core network. Similarly,
SIP-T trunks are assumed to start/finish in the core network
Once a call is made, the CS2K identifies the LBLs and NATs along the speech path
between the two endpoints, and calculates if there are sufficient resources available on all
the LBLs not to exceed the provisioned limits. If all the LBLs can handle the new call,
then the call progresses as normal. If one or more LBLs cannot handle the call the
originator receives a treatment provisioned by the carrier. The terminator has not reached
a ringing stage so is unaware of the call attempt.
Take, for example, a call between a gateway on Site A3 and a gateway on Site A2. This
call will use resources on links, 2, 3 and 4, but not on link 1 as the call doesnt leave the
enterprise. An insufficient resources failure on any of links 2, 3 or 4 would result in the
call going to treatment.
This chapter describes how OAM&P capabilities are provided for CS2000 and the other
elements of a CS2000-based solution by means of Element Managers and OAM&P
management applications. It is organised as follows:
! Section H1.1: Logical OAM&P Architecture on page 770
! Section H1.2: Physical OAM&P Architecture on page 774
! Section H1.3: Access to EMs and Management Applications on page 782
The other chapters in this Part of the Product Description provide more detailed
descriptions of the OAM&P capabilities provided by Element Managers and management
applications under the functional headings of the standard FCAPS OAM&P model, as
follows:
! Chapter H2: Fault Management
! Chapter H3: Configuration
! Chapter H4: Accounting
! Chapter H5: Performance Management
! Chapter H6: Security (OAM&P Access Control)
Non-Proprietary EMs
Small line media gateways deployed on customer premises (MTAs and IADs) are
third-party units. Customised management applications are available for each gateway
type. It is a condition of accepting a given gateway type for deployment as part of a
CS2000 solution that it is provided with a compatible third-party Element Manager.
Details of communication between these EMs and the NML are customer-specific, and
are outside the scope of this CS2000 Product Description.
Note: For MTA cable gateways, the management application manages the CMTS at the
cable head-end as well as the MTAs themselves. The management application used
depends on the CMTS type.
OAM&P Applications
The following OAM&P applications are supported in ISN07:
! CS2000 Core Manager applications:
" SuperNode Billing Application (SBA)
" Event reporting (logs and OMs)
! Trunk provisioning and maintenance applications:
" Trunk provisioning application
" Nodes provisioning application (also used for line provisioning)
" Optional Trunk Maintenance Manager (TMM)
! Line provisioning and maintenance applications:
" Line provisioning application
" Nodes provisioning application (also used for trunk provisioning)
" V5.2 configuration and management application
" Line Test Manager (LTM)
" Optional Line Maintenance Manager (LMM)
! APS provisioning application for the UAS
! Management Data Provider (MDP) for PMDM
! QoS Collector Application (QCA) for aggregating end-of-call QoS statistics
provided by GWCs
! Network Patch Manager (NPM) for co-ordinated distribution / application of
software updates
Note: The OSSGate application is also supported. This provides a single access point for
CS2000 provisioning applications, ensuring that configuration changes made by the node,
trunk and line provisioning applications are co-ordinated.
773
Page
System (IEMS) provides:
Aggregated northbound data
streams in standard formats GUI
Chapter H1
OSS applications
IEMS IEMS
Network
For simplicity, Patch
trunk/line Manager
provisioning apps are (NPM)
not shown individualy
Trunk
Overview of OAM&P for CS2000 Solutions
(SBA)
Billing
maintenance and application Provider
maintenance (MDP)
applications
Management
Event reporting
(Logs and OMs)
QoS Third-party units
Collector must be provided
Application
Part H
with a compatible
OAM&P
(QCA) third-party EM
PROPRIETARY
Nortel Networks
CS2000 USP PP8600 UAS APS MCS5200 CICM MG9000 Third-
SAM21 GWC
(EMs)
Core STORM Device PMDM
Manager Manager Manager Manager Mgr. Mgr. Mgr. EM Mgr. party
Manager Manager gateway
EMs
Element Managers
only)
FLPP, used) switch UAS Server portal MGs MGs
STORM
gateways
(Compact
if used)
(NEs)
(APS)
CS2000 components
Network Elements
Proprietary gateways
Figure 171 provides a logical view of the OAM&P architecture for a CS2000 network.
CS2000 International Product Description
H1.2.1 Trusted Access to NEs via the OAM&P VLAN of the CS LAN
The OAM&P VLAN of the CS LAN interconnects the EMS (Element Management
System) servers supporting the EMs (Element Managers) for functional network
elements. These EMs are the only entities that are permitted to access the functional
CS2000 NEs on the signalling VLANs. The EMS servers belonging to the OAM&P
VLANperform a dual role:
! They have trusted access to the CS2000 network elements on the signalling VLAN,
for which purpose they can use the private IP address space of the signalling VLAN.
! They support controlled access from external entities.
The EMS servers on the OAM&P VLAN can be accessed by:
! Appropriately authenticated entities on the NOC LAN, e.g. NOC desktop clients
and Higher Level Management (HML) application servers.
! Appropriately filtered and authenticated external users in Operating Company
intranets, e.g. from the OSS LAN.
Other users in the NOC LAN and Operating Company intranets can access CS2000
network elements only via the EMS interfaces. They have no direct IP route to the CS2000
network elements. No extension of the OAM&P VLAN to other servers or services is
permitted, as this would compromise the security of the CS2000 network elements.
Figure 172 on page 775 illustrates the network architecture.
Nortel
OSS LAN / OC corporate internet Remote
(centralised OAM&P applications) Access
Enterprise Secure
servers tunneling
NOC LAN
RA to OAM&P VLAN
Untrusted indirect
access to NEs via EMs
RA to CS2000
Element Managers
(trusted access to Network Elements)
Firewall /
perimeter IEMS /
network CBM Other
CMT EMs/apps
PP8600
CS2000
Sun server Sun server Sun server DM CS LAN
EMS servers
CS LAN (OAM&P VLAN)
EM
functionality
for 3rd-party
media Telco SAM21 SS USP
router CS2000 (inc.
gateways Core CICM (inc. MS2010
SC GWC inc. EM EM) EM)
PVG
Packet backbone network gateways
Line
gateways
H1.2.2 Access to the OAM&P VLAN from outside the CS2000 CS LAN
Clients for
EMs and HLM applications
management on enterprise
applications servers
NOC LAN
IEMS
Non-CMT-resident EMs,
e.g. for Session Server,
USP, CICM EM
EMs and mgmt
apps, e.g. GWC
Core Manager EM, SAM21 EM,
applications configuration apps
" Customer choice of OSS fault interfaces (SCC2, SYSLOG, NT STD and
SNMP)
" Centralised fault viewer with filtering capability
" Context-sensitive launching for EMs, management applications and CLUIs
(Command Line User Interfaces) supporting access to NEs.
" Enhanced security via more centralised administration of user accounts and
passwords for PAM-enabled systems.
See section H1.3.1 on page 782 for further information about IEMS support for
access to management capabilities for other CS2000 components.
! APS (Audio Provisioning Server)
The NCL software package that contains the APS application for provisioning
announcements on the UAS and MS2000 Series.
! SSPFS (Succession Server Platform Foundation Software)
The NCL software package that contains base operating system and common tools,
libraries and server functions used by EML applications. These include:
" EMS proxy services supporting access to embedded server software,
including:
# Call Agent Manager for the Call Agent platform
# STORM Manager embedded in STORM software load
# Client for USP Manager embedded in USP software load
" PM Poller
" NPM (Network Patch Manager) for GWCs
" Generic services and protocols such as BOOTP, DHCP, TFTP and KDC
APS 5
USP Manager Proxy 5
LMM 4
TMM 4
NPM 3
PP8600 Device Manager 1
STORM 1
MG9000 Manager 64
[1] IEMS can support more Java clients than HTML clients because Java clients work on
downloaded raw data, while HTML clients require the server to perform data processing.
[2] Also comprises PMDM and MDP is PVGs are managed via the CS2000 OAM&P VLAN rather
than from a central location.
[3] OSSGate provides a single access point for Succession provisioning applications, and applies its
own limits, as discussed in section H3.6 on page 802.
Some desktop applications can access multiple network elements, subject to the limits
summarised in Table 79.
GW supplier is
SNMP
SNMP
SNMP
SNMP
Corba
Corba
Corba
SCC2
SCC2
SNMP (alarms) and Syslog (logs)
SNMP
SNMP
SNMP
SNMP
SNMP
SNMP
CS2000
Core USP RTP
PP8600 SAM21 media CICMs MG 3rd-pty
routers (also (if GWCs UAS PVGs
SCs portal (if 9000s gateways
FLPP, used) used)
if used)
CS2000 components
Reporting mechanism
Network Notes
element From element to To present
information to
EM
IEMS
Reporting mechanism
Network
element To present Notes
From element to information to
EM
IEMS
RTP Media
SNMP SNMP
Portal
Management capabilities
The CS2000 Core Manager allows the operational characteristics of the log reporting for
a CS2000 to be checked and modified interactively. Specific capabilities:
! Routing of selected logs in real time to specific OSS applications or remote devices
! Temporarily overriding datafill-defined parameters, e.g. to turn log reports off
! Viewing log generation criteria (threshold parameters)
! Modifying the set of log reports to be provided
! Undoing the last change or reverting to stored log generation criteria
! Saving files containing customised log generation criteria for subsequent re-use
! Broadcasting log generation criteria to multiple CS2000s
802.3
TCP/IP IEMS
delivery Format of single
consolidated fault
feed can be any
logs Log of:
Formatting SCC2
NT STD
OSS
SNMP
ASCII
Printer stream
Custlog
delivery
Configuration files
Printer
SNMP
SNMP
SNMP
Corba
Corba
Corba
SNMP
via via
TCP TCP
CS2000 UAS
PP8600 Core MCS MG
USP SAM21 GWC Mgr. CICM PMDM 9000
Device Mgr. and 5200
Mgr. Mgr. Mgr. Mgr. Mgr. Mgr.
(SDM or APS Mgr.
CBM)
ASCII
DCOM
ASCII
SNMP
SNMP
SNMP
SNMP
SNMP
SNMP
SNMP
via via
TCP TCP
CS2000
Core USP RTP
PP8600 SAM21 media CICMs MG 3rd-pty
routers (also (if GWCs UAS PVGs
SCs portal (if 9000s gateways
FLPP, used) used)
if used)
API XML
EM
APIs
Integrated provisioning
OSSGate for integrated provisioning applications on
CMT server
ASCII
Corba
via
SNMP
ASCII
TCP via
TCP
CS2000
Core PMDM
USP Mgr. GWC
Mgr. (SDM or Mgr.
CBM)
ASCII ASCII
SNMP
SNMP
via via
TCP TCP
CS2000
Core 3rd-pty
USP PVGs gateways
(if (also GWCs
used) FLPP,
if used)
Gateway provisioning is independent; co-ordination with
CS2000 components CS2000 Core and GWCs is achieved via endpoint naiming
Figure 178 provides an overview of how line provisioning for service activation is
supported in a CS2000 network.
EM
SERVORD+ XML APIs
Integrated provisioning
OSSGate for integrated provisioning applications on
CMT server
ASCII
SNMP
ASCII
Corba
via
SNMP
TCP via
TCP
CS2000
Core MG
Mgr. GWC CICM 9000 PMDM
(SDM or Mgr. Mgr. Mgr.
CBM)
DCOM
ASCII ASCII
SNMP
SNMP
via via
TCP TCP
CICMs MG 3rd-pty
CS2000 (if 9000s PVGs gateways
Core GWCs
used)
If CCS7 functionality for a CS2000 is provided by the USP, CCS7 routesets and linksets
are datafilled on the USP rather than the Core. The USP sends the Core the routeset
information it needs to populate its tables, and also keeps the Core informed about
routeset availability. (If CCS7 functionality is provided by the FLPP, the necessary tables
are automatically datafilled as part of the trunk provisioning process for the CS2000
Core.) USP provisioning is carried out using the USP EM GUI, which supports
communication with the USP using SNMP.
Each application uses line provisioning input to generate two types of output:
! ASCII over TCP, which is provided to the CS2000 Manager on the SDM and used
by it to update CS2000 Core datafill.
! Corba data, which is provided to the GWC EM and used by it to update GWC data.
See Chapter C2: Trunk and Line Datafill for information about the line data stored by
CS2000 Core and GWCs.
For a cable or customer LAN line gateway, datafill is provided as follows:
! GWC datafill via GWC EM
GWC EM specifies FQDN (Fully Qualified Domain Name) of gateway.
If the mapping between a gateways FQDN and its IP address is static, the real IP
address can also be specified.
Typically, however, line gateway IP addresses are assigned via DHCP (Dynamic
Host Configuration Protocol), and the GWC discovers the IP address of a line
gateway dynamically.
! Gateway datafill
Cable and customer LAN line gateways are third-party units that use a variety of
methods for configuration and provisioning. These typically involve the use of
DHCP (Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer
Protocol) for auto-loading when the gateway is first activated and initialised. See
section C2.8.3 on page 201 for an illustrated explanation of the network
configuration and information flows involved in configuring a line media gateway.
For media gateways supporting lines, line provisioning is independent of the Core / GWC
provisioning process. Manual co-ordination is therefore required between gateway data
and Core / GWC data. This is achieved by ensuring that endpoint naming is consistent
between the three different types of node.
Line provisioning 30 30
Carrier provisioning 4 4
Trunk provisioning 5 2
LMM 10 2
TMM 10 2
Note: System response time increases as the number of simultaneous users increases.
The x at the start of the base record structure code is either 0 for a self-contained base
structure record, or 4 if additional modules are appended to the base structure. 00510 and
40513 are examples of complete structure codes.
Carrier selection requires an x0512 base structure record to be used instead of the one of
the base structure records listed in the table above. This provides a number of additional
fields (Bellcore-defined) to contain carrier selection information. The ability to generate
an x0512 record is provided by setting the office parameter
PRESEL_DEACT_X0512_BILLING (in table OFCENG) to N. An x0512 record will
then be generated for every call on which carrier selection is active.
120 Module contains the number that has been datafilled in field GROUPID of table
CUSTENG for the originating customer group.
Module used for rejected or failed calls, to record whichever of the following is
appropriate:
Information about the treatment applied, including treatment origin and
treatment application.
ITU release reason (available only if no non-CCS7 trunks have been
130
involved in call setup).
Produced only in conjunction with module 025 (unanswered call), because a
rejected or failed call is by definition unanswered.
Capability controlled via SOC option BILL0003 and the Flexible AMA option
FLEXRJCT. Also controlled by option AMREDIR in table AMAOPTS.
The E.164 / X.121 number module, which records:
Type of number
164 Country
Digits
Module contains the ISDN channel identifier for ISDN call orginations
180 terminating on ISDN. Capability activated by setting option
APPEND_ISDN_CKT_ID to ON in table AMAOPTS.
181 Module contains the incoming trunk identifier for trunk calls terminated to PRI,.
Activated by AMAOPTS option APPEND_ISDN_CKT_ID (as for 180).
Appended to the base structure for an IN call when this is requested by a
FurnishChargingInformation operation from the SCP. This module type
199
contains any required operator-defined data coded as BCD digits (up to 20
bytes / 40 digits).
306 Module contains a three digit Originating Line Information parameter (OLIP).
Module holds details of any time changes (initiated by SETDATE or SETTIME)
504
that have taken place during a call.
SUSP billing module, which records the feature codes of the features last
509 activated by the call originator and terminator. It is appended to a call when
FTRCODE in table AMAOPTS is set to ON.
Note: SUSP uses North American structure codes, and can therefore be used only on
switches that can support North American structure codes.
Module code 611 is appended to the base AMA record for a call as a result of pay-per-use
billing. This allows the billing record for a call attempt initiated by a feature to be
co-ordinated with the feature usage record generated on feature activation.
A type 611 module is a generic module with a one-digit string format. For SUSP, this
module contains a generic context identifier and a digit string:
! The generic context identifier assigned by Bellcore for subscriber usage recording
is 80024.
! The digit string is used to indicate which feature was accessed. For example, a digit
string of 8386A4000000040C indicates that the CFU (Call Forward Universal)
feature was accessed.
" The first twelve characters serve as the service identifier, which represents the
feature acronym in EBCDIC format. In this case 83 = c, 86 = f, A4 =
u, and the remaining six characters of the first twelve are represented with
zeros, since there are only three letters in the feature acronym.
" The next two characters, 04, represent the service event. In this case 04
maps to subscriber programming.
" The last two characters of the digit string are 0C. 0 is an unused character
and C is the SIGN indicating the end of the digit string.
The multiple file feeds presented for downstream processing need not be identical. The
SBA can filter the records presented to it on the basis of the value of any valid field in an
AMA record (and can use wildcards to filter on the basis of partial field values). This
filtering capability makes it easy to separate billing records into different streams for
different purposes, e.g. it is possible to filter the incoming stream of records and output
answered call records to one mediation system and unanswered call records to another.
Further filtering can be performed using the SBA AMADUMP tool described in section
H4.3.5 on page 825.
DPMS using FTP. The transfer can be initiated from the RMI or can be scheduled
to occur periodically. If the transfer is successful, the status of the AMA files is
changed to secondary. If the transfer fails, the fact is logged and the transfer is
reattempted up to a given definable number of attempts. If the reattempt limit is
exceeded, an alarm is set.
! DAT backup
If the teleprocessing system (DPMS Agent) fails and disk utilisation becomes high,
resulting in alarms being raised, the operating company can back up the primary
AMA files to DAT tapes, allowing them to be deleted from SDM so that disk space
can be recovered. The DAT backup must be manually initiated from the RMI. When
the backup completes successfully, the status of the AMA files is changed to
secondary.
! Alarms and logs
SDM Billing Alarms are sent to the CS2000 and can be displayed from the SDM
Billing MAP CI level. SDM Billing Logs can either be sent to the CS2000 log
buffer system and then output, or be sent directly to the SDM Log Delivery system,
depending on a user-defined parameter.
In the event of an SDM outage, the AMADNS application redirects AMA records to
temporary files on the CM and retransmits them automatically when the SDM recovers.
CS2000 3rd-pty
PP8600 Core MCS MG gateways
Device USP GWC SAM21 PMDM 9000
Mgr. Mgr. 5200 must have
Mgr. (SDM or Mgr. Mgr. Mgr. Mgr. compatible
CBM) 3rd-pty EM
SNMP (PMs on
OMs (ASCII/TCP)
SNMP
PMs (ASCII
on demand
(OMs at
at intervals
SNMP
via TCP)
CS2000
Core USP RTP
PP8600 SAM21 media CICMs MG 3rd-pty
routers (also (if GWCs MS PVGs
SCs portal (if 9000s gateways
FLPP, used) 20x0 used)
if used)
CS2000 components
Reporting mechanism
Network element
From element to To present
Intermediary
intermediary information to NML
GWC SNMP
PM Poller running on same
Aggregated PMs in
SAM21 SNMP server as GWC EM, SAM21
CSV format via FTP
EM, UAS EM and APS
UAS SNMP
CICM SNMP
Direct to IEMS
MS20x0 SNMP Consolidated feed
Via PP8600 Device from IEMS
PP8600 SNMP in CSV or XML
Manager to IEMS
RTP media portal SNMP Via MCS Manager to IEMS
PMs in SSV format PMs in SSV format
USP via FTP USP EM via FTP
PMs in BDF format
PVG ASCII over TCP PMDM
via FTP
Stand-alone Performance
PMs in CSV format Collector / Formatter PMs in CSV format
MG9000
via FTP application running on same via FTP
server as MG9000 Manager
Third-party SNMP Poller task, Typically SNMP,
gateways e.g. on EM HTML or XML
These two NTMOS data classes are much smaller than the three DCOS data classes.
The protocol used over the interface between the switching node and the NTMOS is
specified by Bellcore standard TR746.
These statistics can be used directly in assessing network performance. They can also be
used as input to a number of standard calculations that provide other measurements of
network performance, as follows:
! OOS (Out Of Service) threshold
The OOS value for a route is the number of out-of-service circuits for that route
divided by the number of working circuits, which is:
(SBU+MBU) / NWCCT
An OOS value of 0 indicates that all circuits are in service and that there are no
problems with the route. Up to five OOS threshold values can be defined to trigger
different levels of alarm.
! GOS(Grade Of Service) threshold
The GOS value for a route measures the probability of losing a call, it is a function
of the total number of circuits in service and the total traffic carried, and can be
expressed as:
f ( (NWCCT-SBU-MBU), TRU )
Up to five GOS threshold values can be defined to trigger different levels of alarm.
This chapter describes the mechanisms used to control management access to the network
elements and applications comprised in CS2000 solutions. Security functionality is
implemented in:
! The functional Network Elements (NEs) involved in call processing and service
provision for end users
! Element Managers (EMs)
! The Integrated Element Management System (IEMS) used to provide a single
desktop environment for access to for access to CS2000 EMs and management
applications.
! Higher-Level Management (HLM) applications
Security mechanisms are designed to protect CS2000 network elements from
unauthorised viewing and / or modification of data, and from denial-of-service attacks.
The chapter is organised into the following sections:
! Section H6.1: Network Architecture for Security on page 838
! Section H6.2: Security Overview on page 838
! Section H6.3: User Authentication and Account Administration on page 840
! Section H6.4: Secure Remote Access on page 841
The following aspects of Succession security are not discussed in this chapter:
! Security of signalling and bearer paths from remote media gateways.
! Security for third-party components and for components provided by the network
operator, e.g. OSSs. This is outside the scope of a CS2000 Product Description.
HTTPS is used for Java GUI launching and HTML based tools for CS2000 solutions.
For HTTPS to function, the end customer must obtain and install SSL keys into the web
servers. SSL keys are generated on a per machine basis and must be obtained and installed
as part of the installation procedure once the machine name, location and IP addresses are
available. HTTPS is used automatically by the web browsers which are used to access
these tools (Netscape and Internet Explorer).
Point to note:
! An HTTPS certificate is preserved over an SSPFS (ie the SW residing on the CMT)
upgrade. Therefore, It is therefore not necessary to perform this procedure
following an upgrade if an HTTPS certificate was already installed.
! The domain name service (DNS) must be enabled on the CS 2000 Management
Tools (CMT) server to allow the security certificates to work, and must be enabled
prior to the installation of the certificate. Refer to procedure Configuring Domain
Name Service in the document Solution-level Security and Admininstration,
NN10402-600.
! The customer must obtain an X.509 certificate. The customer may purchase a
certificate from a third-party Certificate Authority such as VeriSign. Nortel
Networks recommends the installation of a unique certificate for each host.
ITU-T Recommendation X.509 (which has been implemented as a de facto
standard) defines a framework for the provision of authentication services. Once a
certificate is held by a user, it can be used for all internet authentications, although
Nortel Networks recommends one per host. A convenient list of compatible
certificates is located at http://www.apache-ssl.org. Choose the digital certificates
link to see a list of potential vendors.
Note: The name of the certificate should match the host name of the server. A
separate file contains the key, and should not have an associated password.
! Make sure all GUI screens are closed before installing the certificate.
! The RSA key for the HTTPS certificate must not have a password.
! The certificate must be created with the fully qualified domain name (FQDN) of the
server on which the certificate will be installed.
For the Series FX platform used for the SDM, Succession solutions can support INEO
Passwerks Security. Passwerks provides integration with security mechanisms including
DCE, ACE and LDAP. Access to the CS2000 EM (and hence CS2000 Core) is provided
by the Passwerks GUI and CLUI.
Management applications that use Windows 2000/NT accounts support Windows
authentication mechanisms, which include NTLM and Kerberos. These include the
PP8600 Device Manager (on Windows).
This appendix describes the incremental content of the ISN07 release in relation to the
previous ISN06.0 release. Because the CS2000 International Product Description was not
updated for the two 2003 dot releases, this appendix covers ISN06.1 and ISN06.2 content
that was not previously documented as well as content that is actually new in ISN07.
The summary of release content provided in this appendix is organised in the same way
as the body of the Product Description, i.e. under the following headings:
! Overview
! Hardware
! Software
! Packet telephony protocols
! Telephony interfaces
! Features and services
! Network fit
! OAM&P
Under each heading, there is a list of the main enhancements together with a brief
description of each one (typically a single paragraph).
Where feature documentation is available that provides more detailed information about
the implementation of a given enhancement, a reference number is provided that can be
used to retrieve this documentation from the PLS FMDOC library. Except where
otherwise noted, this is the activity reference number, as quoted in planning and
monitoring documents such as the Plan of Record (PoR), prefixed with an A, e.g.
A00002916 for activity 00002916.
See Appendix B: Summary of Product Description Updates for ISN07 for a table
summarising the updates that are to be made to individual chapters and sections of the
International Product Description in order to reflect ISN07 content.
A.1 Overview
! CS2000 capacity increases
CS2000 support for 2.0M BHCA and 200,000 ISUP ports using an XA-Core 3+1
Atlas configuration using USP as signalling gateway. All necessary OAM&P
changes also supported, including increase in max size of table C7TRKMEM from
165,000 to 200,000.
FN reference: A00003485
A.2 Hardware
CS2000 Hardware
! CS2000-Compact message controller
Introduction of Interphase ATM MM PMC as CS2000-Compact Message
Controller card, replacing obsolescent IDT PMC.
! CS2000-Compact support for IW-SPM
Support for IW-SPM in CS2000-Compact hybrid configurations (initially for China
only)
! Hardware enhancements for CS LAN PP8600s
" Introduction of dual CPU/SF cards to support hitless equipment protection
and software upgrades.
# Dual 8692s mandatory for new shipments and recommended for 8691
upgrades.
# Existing single 8691s still supported, also upgrades to dual 8691s.
# No mixing of 8691s and 8692s.
" Support for additional link types, blades and functions:
# 8616SXE
# 2-Port DS3 ATM
# PoS WAN Links
# 10Gig Ethernet WAN Links
# M-Modules instead of E-Modules for gateway sites
# BootP Relay function for SDM
" Potential use of Alteon Switched Firewall for additional security
! Hardware enhancements for GWCs housed in SAM21 shelf, including new types of
GWC-equivalent unit
" Support for H.323 proxy as twin-card unit in SAM21 shelf, providing GWC
capabilities and H.323 gatekeeper functionality for CPE gateways and
3rd-party units. For H.323 access to CS2000, H.225 is used for establishing
connections and H.245 is used for establishing media sessions (audio / video
/ data) within the context of a H.225 connection. Supported units:
# IP-enabled Meridian 1s
# IP-enabled BCM PBXs
# CSE1000 for non-IP-enabled PBXs
# Westell DPNSS gateways
# Cisco 2600/3600 access routers
" Support for CICM (CentrexIP Client Manager) as twin-card unit in SAM21
shelf, providing GWC capabilities for remote IP clients controlled via
UniStim, which include:
# i2001, i2002 and i2004 Ethersets
# m6350 soft clients
Implementation details:
# CICM subtends GWC and is controlled by H.248 (check that this still
applies to twin-card CICM, not just SAM16 CICM)
# 3050 users off twin-card CICM unit
# Failover for active calls
# CICM EM in same SAM21 as CICM itself
Twin-card implementation replaces initial ISN06.x implementation of CICM
as SAM16 unit connected to CS LAN and controlled by GWC via H.248 (like
UAS), supporting up to 1,000 users per shelf.
" GWC support for up to 5,920 endpoints for large line gateways (MG9000).
FN reference: A00004236.
" AC GWC support for up to 1280 simultaneous announcements (up from 300)
! Current implementation of VRDN as twin-card GWC unit in SAM21 shelf, while
still supported, is to be superseded by Session Server (see below) based on
HP-CC3310.
! NGSS (Next-Generation Session Server), superseding VRDN
Support for an RFC3261-compliant SIP interface for open interoperability with call
servers, application servers and proxy servers, replacing the current proprietary
implementation based on early SIP drafts. The Session Server converts SIP
messaging into messages understandable by the CS2000. It is a platform for
delivery of multiple applications, of which the SIP Gateway application (also
supported in ISN07) is the first.
The Session Server consists of a NEBS Level 3 compliant hardware platform plus
a software framework and architecture for developing carrier-grade applications
and services. The hardware platform is the Hewlett Packard HP-CC3310, which
provides processing, memory, and disk capacity for STORM, SIP and SIP
applications. The base layer of Session Server Software uses NCGL (Nortel Carrier
Grade Linux) layer, which includes the Linux kernel. The Session Server
supersedes use of VRDNs. Once it has been installed in a CS2000, the VRDN must
be removed.
FN reference: A00003933
! USP hardware upgrades
New 1GB/3GB PP5 link cards as replacements for CEx and LEx cards, addressing
component obsolescence and hardware cost issues. PP5 includes integral PMC disk
to replace the separate single-slot RTC ST12CA SCSI disk. USP can support a mix
of 1GB PP4 and 1GB/3GB PP5 cards in the same shelf, and can also support a mix
of PP5 link cards with the previous LE2,LE3 and LE4 cards.
! Support for Interworking SPM (IW-SPM)
Initially believed to be outside the scope of the main CS2000 Product Description,
as support was restricted to hybrid configurations for use in China, but now churned
in to International for cable, so must be covered.
Media Gateways
! PVG hardware enhancements:
" Support for carrier-grade GigE uplinks to core network
" 4-port GigE FP
FN reference: A00002818
" Carrier-grade Virtual Router on VSP3, supporting hitless equipment
protection and software migration
" VSP3-O with integrated OC3/STM-1 Interface
FN references: CD2771, CD2397
" Recycle of PVG TDM FP cards to address component obsolescence
FN reference: CD2762
" Carrier-grade H.248 for PVG control
FN reference: A00003015, CD3183
! AusioCodes Mediant 2000 CPE gateway supporting PRI.
! CPE gateways and 3rd-party units controlled by CS2000 H.323 proxy (GWC
equivalent) via H.323 / H.225 / H.245:
" IP-enabled Meridian 1s
" IP-enabled BCM PBXs
" CSE1000 for non-IP-enabled PBXs
" Westell DPNSS gateways
" Cisco 2600/3600 access routers
CS2000 H.323 media proxy provides H.323 gatekeeper functionality, i.e. it
provides address translation and controls access to the network for H.323 terminals,
gateways and MCUs. It may also provide other services such as bandwidth
management. Gatekeepers are typically used as interconnect points between
network boundaries, but gatekeepers can also provide services to other endpoints
such as terminals where it supports network access for those endpoints, e.g. in an
enterprise environment. CS2000 can support up to 1024 simultaneous calls on a
H.323 GWC.
ISN07 provides CS2000 support for interoperability via H.323 with:
" Cisco 36xx and 72xx gatekeepers (Cisco IOS load 12.2.13 or later)
" CSE1000 Gatekeeper
" MCS5200 SIP clients (SIP PRI GW, PC client, Web client, i2004/i2002,
conferencing server)
Interoperability for CS2000 H.323 devices (M1 Rls 26, BCM Rls 3.5, Cisco
2600/3600, Westell liQ2032) and:
" CICM clients (i2004, i2002, M6350)
" Mediatrix line gateway (1124)
" UAS
" PVG
" CSE1000
Support for communication between CS2000, which uses GK-routed signalling,
and H.323 GKs that use direct messaging (which requires all gateways in a network
to support H.323). To make such communication possible, a Session Border
Controller (SBC) is used to:
" Tandem H.323 RAS and call control signaling between IP address spaces.
" Maintain minimal state information and provide ALG capability.
The SBC supports both direct messaging and GK-routed signalling. It behaves as a
back-to-back agent, perceived by CS2000 as a gateway but by the rest of the
network as a GK. The SBC is visible to both of the networks it is between, and the
NATs/FWs on both sides are visible to the SBC.
! MG9000 high-capacity (up to 5,920 lines) telco-located line gateway supporting
three types of line card:
" POTS-32 card (NY50AA) providing 32 terminations for basic analogue lines.
" 8X8 ADSL card (NY52AA) providing 8 ADSL terminations and 8 analogue
line terminations.
A fully equipped four-shelf frame is regarded as one logical MG9000 unit, and can
support the following access network capacity:
" 1952 POTS or GLC lines per frame
" 488 POTS+ADSL lines per frame
MG9000 lines can interwork with MCS5200 clients, CICM clients and Mediatrix
IAD.
MG9000 NTNY45 Series SuperCore motherboard enhanced in ISN07:
" ABI motherboard and DSP daughtercard combined into single card that does
either ATM or IP depending on software load.
" ECAN functionality provided by TI Janus DSP instead of Coherent
daughtercard.
MG9000 overload controls to ensure that the MG9000 survives, no MG9000
resources go SYSB, and the MG9000 and its resources continue to respond to EM
requests.
! Askey VG201 enhancement
Data port support enabled.
! Ambit 1-port LG001S IAD (16-port and 32-port gateways are also supported)
Cost-effective CPE (cheaper than i200x Ethersets) designed to complement
MCS5200 solutions, which can provide SIP client services for residential users.
Connectivity and capabilities:
" Two RJ45 jacks for Ethernet 10/100 BaseT
" Two RJ11 jacks for analogue phones
" Support for G.711 (a-law, u-law), G.729A/B and G.723.1 (5.3K)
" Support for modem, T.38 fax, in-band and out-of-band DTMF (RFC2833)
" Support for Layer 3 DiffServ marking
" Support for selected voice call features
! Westell DPNSS gateway
Gateway supporting DPNSS trunks to/from digital PBXs. Gateway is controlled by
CS2000 GWC using H.323 and QSIG, with DPNSS being encapsulated in QSIG
messages at the gateway to be conveyed across the network.
! Arris MTA
Arris gateway for use in cable access networks.
Media Servers
! MS2000 Series media servers as enhanced replacements for UAS
MS2010 (VoIP) is a 1U chassis built on AudioCodes IPM-1610; MS2020
(VoATM) is a 2U chassis built on AudioCodes TP-6310. Both consist of two
logically separate media gateway modules, each with its own MAC address and IP
address and each supporting up to 120 ports. Both modules share a redundant LAN
connection through an internal Ethernet switch.
Software load AMS 4.4 provides all the capabilities of UAS08, as supported in
ISN06, plus enhancements such as increased system density.
! UAS / MS2000 enhancements:
" Elimination of local UAS console
" 30-port conference resource management enhancement
" Security enhancements
Peer MGCs
! IMS rebranded as MCS5200
Media Proxies
! RTP Media Portal providing media proxy functionality
A media proxy can support both NAT (Network Address Translation) functionality
to control media stream access to a private address domain, or twice-NAT
functionality to permit NAT traversal between endpoints in different address
domains. In a CS2000 context, it is used for two main purposes:
" To support secure interoperability between endpoints in the Succession
domain (e.g. packet-side media streams to/from PVG and UAS/MS2000
ports) and endpoints in access or enterprise networks behind NAT devices
(e.g. IADs, H.323 gateways, CentrexIP clients).
" To support NAT traversal for secure interoperability between endpoints
behind different NAT devices, e.g. endpoints belonging to different access or
enterprise networks or served by a different network operator.
A media proxy is switched into a call when required, i.e. when call processing
determines that a NAT device is or will be involved, and is controlled by one of the
GWCs that is already involved in the call (i.e. controlling a participating trunk or
line). To allow the media stream for the call to flow through the NAT device, the
media proxy discovers which public address and port on the NAT device should be
used as the destination for packets to be sent to endpoints behind the NAT device.
For CS2000, the unit first used to provide media proxy functionality was the
SAM16-based RTP Media Portal (RMP). Signalling between the controlling GWC
and the RMP uses the MPCP protocol.
FN reference: A89007985.
Remote Clients
! Support for remote Etherset (or equivalent) clients controlled by CICM using
UniStim. Specific terminals:
" i2001 as low-cost entry-level CPE unit
" i2002
" i2204
" i200x Phase 2 terminal
" Third-party terminal devices
" Key expansion module for i2002 and i2004 sets, providing physical button /
lamp capability for attendant (no need for PC).
! Support for m6350 remote PC softclients controlled by CICM using UniStim.
A.3 Software
Datafill
! Allows Servord commands ADO, DEO and CLN to manipulate the table LNINV
GND option for lines (including GWLPOT lines). If GND=Y, the line will be a
ground start line.
FN reference: A00002555.
! MG9000 preprovisioning support:
" Format of MG9K LEN reflects physical location.
" When IEMS provisions an MG9K node, table LNINV will be automatically
datafilled with the available circuits.
FN reference: A00002252.
! Ability to increase/decrease the number of endpoints assigned to an operational
H.323 gateway via either IEMS or XML, without any impact on active calls.
Translations
! MCDN (Meridian Customer-Defined Networking), including UDP (Universal Dial
Plan) with network-unique numbers and CDP (Co-ordinated Dial Plan) with
domain-unique numbers and multiple domains
FN reference: A00002358.
! T.38 FAX Support for International H.323
This activity provides CS2000-controlled switchover to T.38 mode for H.323 calls.
T.38 fax interworking is supported on calls between H.323 GWs (e.g. Meridian,
Cisco) and H.248 GWs (e.g. PVG) or MGCP GWs (e.g. Mediatrix). At least one
involved agent must be H.323. T.38 fax interworking is provided over Session
Initiation Protocol (SIP-T).
FN reference: A00003627.
! UniStim
Proprietary interface used by CICM to communicate with remote CentrexIP clients.
UniStim is a stimulus protocol whose command set enables a Netqwork Intelligence
(NI), i.e. CICM, to control every aspect of the operation of a client Internet Terminal
(IT) such as an Etherset or soft client. RTP streams are used for voice transmission.
To provide reliable transport over UDP, UniStim makes use of Reliable UDP The
lower layer protocols are UDP and IP.
UniStim commands are categorised on the basis of which of the following
functional element managers they control:
" The Key/Indicator Manager is responsible for the IT keys and indicators. It
sets LEDs and icons, reacts to key depressions and detects on-hook/off-hook.
" The Audio Manager controls the audio configuration of the IT. It sets up voice
paths, establish end-to-end voice connections and handles tone configuration.
" The Display Manager is responsible for the presentation of information sent
by the NI, which means that the NI does not have to know where information
is physically presented or what language is used.
" The Basic Manager handles IT maintenance functions such as self-testing.
" The Network Manager is responsible for configuring and maintaining the
network connections between the NI and the IT.
" The Broadcast Manager is responsible for such things as icon, character table
and time/date downloading for both the IT and any attached accessories.
! MPCP
Proprietary variant of MGCP used to control SAM16-based RTP Media Portal.
! M2PA
Use of M2PA (MTP-User Peer-to-Peer Adaptation) instead of M2UA (MTP Layer
2 User Adaptation) to convey TCAP NCAS (Non Call Associated Signalling)
across the backbone packet network between CS2000s with different point codes
(strictly speaking, between USPs belonging to different CS2000s).
INAP
! T-INAP support
Implementation of a subset of the CS-1 INAP extensions specified in 163 TR 78.96
and used by DTAG to support Universal International Freephone Service (UIFS):
" Implement T-INAP Application Context negotiation
" Enhance InitDP operation to handle T-INAP national parameters
# highLayerCompatibility
# additionalCallingPartyNumber
# sFEncountered
# gapInterval
# natCallingPartysCategory
# iNContainer
" Enhance Connect operation to handle T-INAP national parameters
# redirectingPartyID
# redirectionInformation
# natServiceInteractionIndicators
# iNContainer
# userUser
FN reference: A00002907.
! T-INAP interworkings
IN triggering to T-INAP for G-ISUP, T-ISUP and ETSI ISUP V1, and specifically
parameter mapping for the following:
" IAM -> InitDP Interworking
" Connect -> IAM Interworking
FN reference: A00002934.
! IN services for Telefonica
IN enhancement to meet Telefonica requirements, some specific to Telefonica and
some generic and reusable:
" TDP4 QoR (Query on Release) triggering
" CPC criteria triggering
" FCI handling
" ASF enhancements
" Overdecadic digits in Connect CLI parm
FN reference: A00002678.
! China IN enhancements
Support for the following INAP capabilities:
" Enhancement to gapInterval parm of CallGap
" Support for multiple CallGaps
" Enhancement to timerValue parm of ResetTimer
" Enhancements to legID, calledAddress and release parms of CIRQ/CIRP
" Enhancement to sfBillingRecordCharacteristics parm of
ActiveServiceFiltering
" Support for ApplicationContextName negotiation.
" Enhancement to conversation time measurement for ApplyChargingReport
" Support CS-1R InitiateCallAttempt
FN reference: A00002754.
QSIG
! QSIG support for DPNSS
Westell DPNSS gateway supporting DPNSS trunks to/from digital PBXs. Gateway
is controlled by CS2000 GWC using H.323 and QSIG, with DPNSS being
encapsulated in QSIG messages at the gateway to be conveyed across the network.
DPNSS
! DPNSS support
Westell DPNSS gateway supporting DPNSS trunks to/from digital PBXs. Gateway
is controlled by CS2000 GWC using H.323, with DPNSS being encapsulated in
QSIG messages via GWC mapping between H.323 and QSIG so that it can be
conveyed across the network.
CentrexIP
! Support for CentrexIP lines serving i200x Ethersets and m6350 soft clients,
controlled by CICM using proprietary UniStim protocol.
See UniStim list item on page 851 for further information.
" Inter-CS transport mechanism is SIP-T (ETSI ISUP V2+) with QSIG Feature
Transparency (QFT) option. The MCDN data is transported in Facility IEs
within ETSI ISUP V2+ Application Transport Parameter (APP).
Private data retrieved from MCDN tunneled information is propagated only for
private calls, with terminator and originator in the same customer group. The
mechanism used to identify private calls is based on existing QSIG functionality.
For calls breaking out into the PSTN, private information (MCDN data) is dropped.
FN reference: A00003626.
QSIG Services
! QSIG support for H.323
! QSIG support for DPNSS
Indirect Access
No enhancements in ISN07.
VPN
! Support for new types of VPN access:
" Westell DPNSS gateway supporting DPNSS trunks to/from digital PBXs.
" MG9000 gateways
" Ambit gateways and IADs
" Arris MTA
" Gateways supported using H.323 (e.g. Meridian 1, BCM)
" CentrexIP lines serving i200x Ethersets and m6350 soft clients
! Support for new feature sets:
" DPNSS Feature Transparency
" Multimedia / blended user services
IN Services
See INAP section on page 854 for details and FN references.
! IN services for DTAG via T-INAP.
! IN services for Telefonica.
! IN services for China.
Regulatory Services
! Emergency call tracing
CS2000 Core Manager command to support call traces for established inter-office
emergency calls involving SIP-T DPTs, which displays the SIP Call ID of the
associated packet trunk when a TDM trunk is posted, and displays the TDM trunk
when the SIP Call ID is used to post the packet trunk.
Conferencing
No enhancements in ISN07.
Voice Mail
No enhancements in ISN07.
CentrexIP Services
! CentrexIP support for Centrex business set features
! CentrexIP support for multimedia services
Multimedia Services
! Capabilities available to blended users
Multimedia services enable blended users to have screen-based interactive access
to databases and media sources while simultaneously participating in a VoIP phone
call. The interactive access and use of the phone are co-ordinated. In the case of a
call between two blended users, interactive collaboration is possible because both
users are operating in the context of the same multimedia session. Examples:
" For a call between two blended users, e.g. between two users on the same
enterprise network, various types of interactive collaboration are possible:
# File transfer
# Web push
# Whiteboard sharing
# Clipboard transfer
# Instant messaging
" For a call from a non-blended user to a blended user, e.g. an incoming call to
a multimedia-enabled call centre, the call centre agent can check on-line
databases for information about the caller or information to be provided.
" For a call from a blended user to a non-blended user, e.g. a call from a
multimedia-enabled sales centre to a potential customer, the sales agent can
check on-line databases for detailed product and service information or
information that might be of interest to the called party.
! Multimedia service integration via SimRing
Multimedia services for blended users involve both the CS2000 (for voice services)
and the MCS5200 (for multimedia services).
Multimedia services are supported by a MCS5200 RAIDer client on the end users
terminal. When an incoming voice call is received from CS2000, a client window
pops up on the blended users screen at the same time as ringing is applied to his/her
telephone. The called party can then use this client window to initiate a multimedia
session with MCS5200. If the call is from another blended user, MCS5200 will
initiate a connection to the callers RAIDer client, allowing multimedia
collaboration by both users to take place.
The SimRing feature is used as an underlying blender mechanism to ensure that the
RAIDer client and the telephone are alterted simultaneously.
Support for blender services requires MCS5200 to be connected to CS2000 via a
SIP / PRI gateway (sometimes referred to as a SimRing PRI blender). On the
CS2000 side, this is connected to a PVG gateway via PRI; on the MCS5200 side,
the SIP / PRI gateway is configured as a SIP client. A call to a blended user
terminates on pilot DN of SimRing group (the subscribers DN), causing CS2000
to apply ringing to the subscriber line and set up a PRI call to MCS5200. MCS5200
then activates the RAIDer client.
FN reference: A89008119.
ADSL Services
! CS2000 support for ADSL
ADSL (Asymmetrical Digital Subscriber Line) access to the backbone packet
network for data sessions with private intranets and/or the public internet is
supported by the MG9000 high-capacity line media gateway. DSL technology
exploits unused frequencies to support simultaneous transmission of voice and
high-speed data over conventional copper telephone lines. The service is "always
on", meaning that subscribers don not need to dial in or wait for call set-up. ADSL
is so called because it allows data to be downloaded much faster than it can be
uploaded (up to 6Mb/s downloading vs 640Kb/s uploading), reflecting what users
typically require. ADSL is defined in ITU-T Recommendation G.992.1 and ANSI
Standard T1.413-1998.
Tones
! CICM support for Australian tones
! PVG support for Russian tones
! PVG support for Indian tones
Announcements
! Media Server 2000 (MS2000) as enhanced replacement for UAS (see Media
Servers section on page 847 for details).
Internet Transparency
! Media proxy support for NAT
Network Address Translation (NAT) binds IP addresses in one domain to IP
addresses in another domain, enabling routing to take place between hosts
belonging to different address domains. Basic NAT allows hosts in a private
network to access hosts in a public network. Twice-NAT prevents address collisions
between private and public networks. For CS2000, twice-NAT functionality is
provided by a media proxy with two specific capabilities:
" It enables media streams to traverse NAT devices and firewalls controlling
access to customer networks.
" It acts as a firewall to control the entry of media streams into the private VoIP
address domain containing the CS LAN and carrier-located gateways.
A media proxy is inserted in a call when call processing determines that a media
stream has endpoints in different address domains (at least one of them is behind a
NAT device) or that it crosses the boundary between the private VoIP address
domain and a public address domain. The media proxy then performs NAT on the
IP addresses specified in the source and destination fields of each incoming packet.
Media proxies should be located as close as possible to the media gateways for
which they are to provide proxy functionality. Typical configurations are:
" Media proxy located on the CS LAN.
" Media proxy co-located with carrier-located gateways.
" Media proxy co-located with a broadband remote access server connected to
customer-located gateways.
! Intelligent media proxy insertion, i.e. ability to insert proxy via slave side GWC, as
required for networks with relatively few proxies:
" Media proxy needs to be provisioned only for GWCs that support gateways
outside the Succession domain and those that host SIP-T trunks.
" Media proxy provisioning is optional for GWCs that control PVGs, UASs,
MG9Ks and cable gateways
! Support for the provisioning of a given media proxy on multiple CS2000s. Calls
between gateways that are provisioned on different CS2000s but behind the same
proxy need not route calls through the proxy (unless NAT is required).
A.8 OAM&P
Overview
! Integrated Element Management System (IEMS)
Main OAM&P change in ISN07 is IEMS for single integrated interface supporting
drill-down access to NEs, EMs, EMS platforms and EMS applications. Ultimate
aim is support for OAM&P via a single frame. IEMS can coexist with existing
OAM&P applications on the high-availability next-generation standard platform
(Netra 240). Key to single OAM frame objective is migration of SDM applications
from AIX platform.
IEMS provides tree-like expandable Integrated EMS Topology menu to represent
and support access to:
" Network Elements
# CS2000 Core (XA-Core or Compact)
# STORM
# PP8600
# GWC
# SAM21
# CICM
# Session Server
# USP
# MS2000 or UAS
# PVG
# MG9000
# MCS5200
# RTP Media Portal
" Element Managers
# CS2000 Core Manager
# GWC Manager
# SAM21 Manager
# CICM Manager
# USP Manager
# UAS Manager
# APS Manager
# MCS System Manager
# Preside MDM
" EMS Platforms such as
# SDM
# SSPFS
# MDM
# CICM Manager platform
# MCS Manager platform
MCS System Manager running on Sun server. NCL names are IMSC and
IMSD. Provides EM functionality for RTP Media Portal, so must be used if
RMP is used, even if CS LAN configuration does not include MCS5200.
! MG9000 Manager capacity expanded to support:
" 110,000 lines
" 75 nodes
Fault Management
! Integrated fault stream to NML via IEMS
IEMS aggregates all EMS/NE fault data for CS2000 Core, PP8600, MG9000, USP,
PVG, GWC, STORM, SAM21, MCS, media server, CICM and Session Server, and
provides a single consolidated fault feed in any of the following formats:
" SCC2
" NT STD
" SNMP
" Custlog
! SDM log delivery enhancements (SCC2)
Use of the Log Delivery application to:
" Provide a single consolidated northbound log feed for all the components in a
node.
" Implement the initial phase of lost log detection for non-CM logs.
" Enhance the lost log indication mechanism for CM logs.
" Enhance the Log Delivery applications capacity to handle bursty traffic of
logs.
" Make Logroute tool more user friendly and remove redundant processing.
FN reference: A00001743.
! Logs for SIP / SIP-T
This feature integrates two sources of Session Server logs by providing a CLUI (a
Log Client) to control which combination of modules and filters is activated in
Radvision CallP software and it also filters Session Server internal logs.
FN reference: A00003280.
Configuration
! Wizard for adding NEs, EMSs, EMS Platforms or EMS Applications to IEMS.
! Provisioning templates for PVG
Main MDM nodal provisioning screen provides component tree on the left side,
and allows user to add and modify components by selecting the desired component.
On the right hand side of the screen, the user can select the appropriate service
template. When user drags and drops required template to the selected component,
a template GUI pops up allowing user to set and modify appropriate parameters.
! Dynamic changes to size of H.323 gateway
Ability to change (increase/decrease) the number of endpoints assigned to an H.323
gateway via both IEMS and XML.
! CICM flowthrough provisioning and hitless in-service upgrades.
! IEMS support for UAS/MS2000 configuration requirements
Configuration via a common configuration template with Nortel-provided defaults:
" Data backup and restore (image files on TFTP server)
Accounting
! AMA capture of software metering information for NAOC and PCA
Enhancements to NAOC and PCA services to support capture of software metering
information in an AMA type 612 module.
FN reference: A00002638.
! AMA enhancements for DTAG international gateway
Support for recording the following DTAG requirements in AMA records:
" Receipt date and time for first FCI operation recorded in a module code 098
for IN calls in the DTAG network.
" Disconnecting Part Indicator (DPI) captured in type 611 module along with
CHBN to indicate which party released call.
" Charge Band Number (CHBN) captured along with DPI in type 611 module
with context ID 80085.
" Additional ISUP information (Transmission Medium Requirement, Service
Type, Cause Indicator) captured in type 611 module with context ID 80100.
(Requirements doc, but not FN, says long duration call AMA records must be
generated for calls longer than 30 minutes. Current minimum duration for long call
is 1 hour.)
FN reference: A00003007
! SBA real-time billing robustness.
! SBA billing integrity maintained even in the event of catastrophic failure.
! Auto-closure of billing files
If the Core SBA application is unable to send billing data to the SDM SBA
applications, it changes its state to backup mode and stores billing data in backup
storage. When communication is restored, the backed-up data is sent to the SDM in
recovery mode and the SBA then returns to normal mode. This feature
automatically closes billing files on exit from recovery mode.
FN reference: A00002744.
! SBA support for electronic file delivery
Reduces the size of SBA and AFT libraries by separating library content from
executables, thus permitting electronic download via IP instead of software delivery
on tape.
FN reference: A00001650.
! MG9000 support for hardware metering
Line hardware metering involves the generation of hardware pulses to provide call
charge information to the CPE of the call originator. In Succession, the hardware
pulses are generated from the MG9000 gateway that controls the subscriber line
(terminated on GLC32 line card). Pulsing information is sent to the MG9000 from
its GWC using the amet (automatic metering) tone package defined in the Megaco
Enhanced Analogue Line Packages document. Metering support requires AOC to
be specified for the GWC in table SERVRINV.
FN reference: A00001927.
Performance Management
! PM integration
IEMS support for a single consolidated performance feed for PP8600, media server,
STORM-XTS, CICM, Session Server, MCS.
! Capacity increase for SDM OM delivery application (OMDD)
Enables SDM OMDD application to transfer 12000 OM tuples (with up to 32
registers each) from the Core to the OSS can be done in less than 2.5 minutes,
compared with the previous time of more than 3.5 minutes.
FN reference: A00001742.
! 5 and 30 minute OM data pull for the PVG
Ability for PVG to provide PMs to MDM and from there to OSS for use in PVG
monitoring, planning and engineering:
" PMs provided at 5-minute intervals for real-time monitoring.
" PMs provided at 30-minute intervals for further analysis.
! IEMS support for AMS07 performance management requirements
Performance data requirements (preferred mechanism is PMPoller):
" CPU occupancy, memory utilization, interface level communication metrics
(MIB-2), QoS, call volume/type metrics
" Gateway must deliver end of call QoS data to the GWC.
! Performance measurements for CICM
Integration of CICM-generated PMs and OMs with the PMs and OMs of other
network elements for reporting to OSSs.
Security
! IEMS security
Support for centralised OAM&P security administration via IEMS, including:
" Authentication for IEMS itself.
" Authorisation with support for groups and detailed permissions
" Audit trails
" Consolidated audit logs and security logs
" SSH sessions during CLUI launches
! Security enhancements: client firewall compatibility and strong authentication.
The following table summarises the updates that are to be made to individual chapters and
sections of the International Product Description in order to reflect the ISN07 content
described in Appendix A: ISN07 Release Contents.
B3: Media Servers New section on MS2000 as enhanced replacement for UAS; UAS/MS2000
enhancements
New chapter describing remote CentrexIP clients controlled by CICM using
UniStim (CICM itself contrtolled by GWC using H.248); Support for remote
B4 (new): Remote Clients i200x Ethersets (or equivalent), including key expansion module to provide
physical button / lamp capability for attendant; Support for remote PC
m6350 softclients with co-ordinated session capability
New chapter describing CS2000 support for media proxy functionality, i.e.
public adress discovery, NAT, twice-NAT and NAT traversal for media
B5 (new): Media Proxy streams; Section on SAM16-based RTP Media Portal (RMP) unit first used
to provide media proxy functionality, controlled by GWC using MPCP
(A89007985)
B6 (was B4): MCS5200 Rework chapter to reflect IMS rebranding as MCS5200 and increased
support for integration between MCS52000 and CS2000 for multimedia
C: Software
Update/add load names and versions to reflect software packaging for
C1: Software Loads
ISN07.0
Updates and additions to reflect support for new types of interface; Servord
manipulation of LNINV GND option for lines (A00002555); MG9000
C2: Trunk and Line Datafill
preprovisioning support (A00002252); Dynamic modification of number of
endpoints assigned to an operational H.323 gateway
MCDN (Meridian Customer-Defined Networking), including UDP (Universal
C3: Translations and Routing Dial Plan) with network-unique numbers and CDP (Co-ordinated Dial Plan)
with domain-unique numbers and multiple domains
D: Packet Telephony Protocols
Updates and additions to reflect new and enhanced protocols, inc. H.323,
UniStim, MPCP, RFC3261 SIP; New section on transport protocols
D1: Overview
(replacing separate chapter D2 on SCTP only); New section on SDP
(replacing separate chapter D3)
Session Server (VRDN replacement) support for an RFC3261-compliant
SIP interface for open interoperability with call servers, application servers
D2 (was D9): SIP / SIP-T and proxy servers, replacing the current proprietary implementation based
on early SIP drafts (A00003933); Message tracing for SIP-T calls (RazoR
gateway functionality)
Updates and additions to reflect H.248 enhancements; Carrier-grade H.248
D3 (was D5): H.248
for PVGs (A00003015)
D4: ASPEN
E8 (new): CentrexIP Support for CentrexIP lines serving i200x Ethersets and m6350 soft clients,
controlled by CICM using proprietary UniStim protocol
C.2 Standards
IETF RFCs and IDs
RFC1157 SNMP
RFC1889 RTP
RFC2030 SNTP
RFC2045-9 MIME
RFC2327 SDP
Plus related draft:
ID draft-rajeshkumar-mmusic-sdp-atm-01
RFC2543 SIP
Plus related drafts:
ID draft-camarillo-sip-isup-bcp-00
ID draft-ietf-sip-isup-mime-00
ID draft-ietf-sip-info-method-02
ID draft-ietf-sip-183-00
ID draft-ietf-sip-privacy-02
RFC3435 MGCP
(CS2000 supports MGCP 1.0bis - 00 January 2001)
RFC2960 SCTP
Plus related draft:
ID draft-ietf-sigtran-sctp-05
RFC3015 H.248
RFC3057 IUA
Plus related draft:
ID draft-ietf-sigtran-iua-01
V5UA draft-ietf-sigtran-v5ua-03
M3UA draft-ietf-sigtran-m3ua-10
M2PA draft-ietf-sigtran-m2pa-10
PacketCable Specifications
PacketCable Network-Based Call Signaling Protocol Specification (NCS)
PKT-SP-MGCP-I10-040402 (or later issue found at www.packetcable.com)
PacketCable DQoS
PKT-SP-DQOS-I09-040402 (or later issue found at www.packetcable.com)
PacketCable Security
PKT-SP-SEC-I10-0401132 (or later issue found at www.packetcable.com)
ITU Standards
E.164 Open Dial Plan
G.703 to G.705 PCM30 carriers
G.732 PCM30 multiframe structure
H.323 Umbrella specification
H.225 Call processing for H.323
H.245 Connection control for H.323
H.450.1 Tunnelling for H.323
I.431 Physical layer requirements for ISDN PRI
Q.50 Annex A Digital Circuit Multiplication Equipment Interface
Q.701-Q.704 Message Transfer Part (MTP)
Q.711-Q.716 Signalling Connection Control Part (SCCP)
Q.723 Telephony User Part (TUP)
ETSI Standards
ETS 300 356 ETSI ISUP
ETS 300 374 ETSI Core INAP
ETS 300 324 V5.1
ETS 300 347 V5.2
CEPT MoU Memorandum of Understanding on European ISDN
ETS 300 011 ETSI ISDN PRI Layer 1 (physical)
ETS 300 125 ETSI ISDN Layer 2 protocol (datalink) [Blue Book]
ETS 300 402 ETSI ISDN Layer 2 protocol (datalink) [White Book]
ETS 300 102 ETSI ISDN Layer 3 protocol (basic call control) [Blue Book]
ETS 300 403 ETSI ISDN Layer 3 protocol (basic call control) [White Book]
ISO Standards
IS 11572 QSIG Basic Call Control Procedures
IS 11582 QSIG Generic Functional Procedures for Supplementary Services
IS 14474 QSIG Logical/Physical Mapping
DEN/SPS-01032-1 ISUP and TCAP support for QFT (also known as Q.vpn)
DEN/SPS-01042-1 APM extensions to ISUP (also known as Q.apm)
ISO4217 MCMP Currency Tokens
ISO639-2/T MCMP Language Tokens
National Standards
PNO-ISC 006 IUP (BTUP replacement, corresponding to BTUP Version 3)
PNO-ISC 007 UK ISUP (based on ETSI ISUP V3)
BTNR 167 BTUP
TR-TSY-000317 Bellcore ISUP
T1.113.1-4 ANSI ISUP
ACIF I-ISUP ACIF G500 Signalling System No.7, Interconnection ISUP
Telstra CS30 ISUP Network Signalling Infrastructure Specification C.A.30 (ISUP)
SPIROU ART Specification SPIROU 1998-00
SSUTR2/FTUP Specification du Sous-systeme Utilisateur SSUTR2 VN4 (ST/PAA/CER/SCS/2600)
Brazilian ISUP Telebras Practice 220-250-732, ISDN - ISUP CCS7 Signalling System"
Czech ISUP National Specification of MTP and ISUP for Czech Republic and Slovak Republic
JI-ISUP Japan TTC specification JJ-90.10 Version 2 (1999)
HKTA2015 Hong Kong PRI (CR13)
YDN 021-1996 Chinese V5.2
YDN 034 Chinese PRI
BTNR 188 DPNSS
General
A19012781 Codec Selection Enhancement (selection via Xlations)
A59025876 Connection Roles for Inter MGC
A59032166 Simple Network Time Protocol Support on XA-Core
A59032687 E1/T1 Coexistence
A59034587 Coexistence of UAS with EDRAM
A59038784 Multi timezone support
A59039029 G.729 a/b with RFC2833 for support of DTMF tones and T.38 fax
A59040404 International IBN Lines SOC
A89007180 UAS Capacity Increased from 150 to 300 Announcements
A89007340 Route List Conditional Selector based upon Network Fabric
A89008121 Uniport on CS2000 (RAS via CVX1800)
A89008489 RMGC Capability Ported to GWC
A00003485 CS2000 capacity increases
A00004236. GWC support for up to 5,920 endpoints for large line gateways (MG9000)
A00003933 NGSS (Next-Generation Session Server), superseding VRDN
A00002818 4-port GigE FP for PVG
CD2771, CD2397 VSP3-o with integrated OC3/STM-1 Interface
CD2762 Recycle of PVG TDM FP cards to address component obsolescence
A00003015, CD3183Carrier-grade H.248 for PVG control
A89007985 RTP Media Portal providing media proxy functionality
A00002555 Allows Servord manipulation of table LNINV GND option
A00002252 MG9000 preprovisioning support
A00003711 GWC support for Gateway Inter-Machine Trunk (GWIMT) on PVG
A00002739 Virtual Call Admissions Control (VCAC) on CS2000
INAP
A59025340 In-Band Digit Collection Control (PRI) for INAP
A59028269 INAP oMidCall Support, SIP-T Triggering, Feature Interactions
A59033609 Line Triggering Interactions for 3WC/CFW
A59033629 INAP Support for Context Identification, Auto Continue, SCCP segmentation
A59033637 INAP SII (ServiceInteractionsIndicator) Interworking
A59034387 CM based INAP Prompt & Collect on PRI
A19012479 CS1R: CTR in Monitoring, Pre-Paid Services, Complex Announcements
A59038655 CS1R: Line Triggering Enhancements (including CCBS support)
A59039729 CS1R: Prepaid Services on China ISUP
A89008338 CS-1R Charging Enhancements
A00002907 T-INAP support
A00002934 T-INAP interworkings
A00002678 IN services for Telefonica
A00002754 China IN enhancements
A00002900 China ISUP connection to external IP
PRI
A59020206 International PRI Supported on Call Server
A59026186 PRI Echo Control based on Bearer Capabilities and ISUP Interworking
A59039647 China PRI off PVG with interworking to China ISUP
A59039128 Japan PRI (INS1500) off PVG T1 carriers with interworking to JI-ISUP
A59039654 Hong Kong PRI on T1 including IBN line interworking
A89008422 China ISDN on CS2K hybrid switch
QSIG
A59038835 QSIG on CS2000
DPNSS
A00001965 DPNSS Feature Transparency (DFT)
Indirect Access
A59037739 Tone Burst On Answer for Indirect Access
A59034387 CM based Prompt & Collect on PRI for 2-Stage Indirect Access
Regulatory Services
A59024510 DNBD (LI) on CS2000
A59024902 LI (Lawful Interception) support for Incremental Services - Completion
A59028707 CS2000 LI support for incremental services - Phase 2
A59030731 German National Regulatory Services
A59034497 Payment Ceiling for Analogue Lines
A59035246 LI Enhancements for Packet Network Calls
A59036326 LI for CEPT Services (CW, CHD, 3PTY,CFU, CFB, CFNR)
A59040499 Hong Kong regulatory features (CLI enhancements)
A59040504 Hong Kong regulatory features (MCT enhancements)
A59040509 Hong Kong regulatory features (CFwd restriction/prevention)
A59040141 China ISUP Handling of Operator Calls and Emergency Calls
A89007355 LI Call Content in Mono Mode
A89007360 Call Data Delivery via FTP TCP/IP
A89007454 NAOC (Network Advice of Charge) Regulatory Enhancements
A89007461 PCA (Payment Ceiling Advice) Regulatory Enhancements
A00002965 SDM aspects of ETSI compliance for LI (HI1 and HI2 interfaces)
A00003514 Core aspects of ETSI compliance for LI (ISUP protocol changes for subaddressing)
A00002756 Japan trunk services
Multimedia Services
A89008119 Multimedia service integration via SimRing
Network Fit
Tones
A19009891 Complex Periodic Tone Flexibility for ISUP
A19012781 Codec Selection via Translations
A19013546 Simplification / Standardisdation of Announcement Datafill
A59022704 Table TONES Enhancement
A89009351 Market of Office Decoupling for Japan
A89009671 Market of Office Removal Phase I
OAM&P
A59029095 International Auto-Provisioning of LNINV
A59039985 Subscriber Usage Billing enhancements for AR/ARDDN
A59040148 China Trunk Metering
A89009303 SERVORD+ Support for CHG and EXB Commands
A89007725 QoS OMs for Trunk Groups
A89007781 Quality of Service (QoS) Reporting Provisioning
A89008458 China-Specific OMs on ISN06
A00002638 AMA capture of software metering information for NAOC and PCA
A00003007 AMA enhancements for DTAG international gateway
A00002744 Auto-closure of billing files
A00001650 SBA support for electronic file delivery
A00001927. MG9000 support for hardware metering
A00002625 CS2000 metering enhancements for tariff model compliance
A00002637 CS2K NAOC trunk metering enhancements for Spain
A00001742 Capacity increase for SDM OM delivery application (OMDD)
A00001743 SDM log delivery enhancements (SCC2)
A00003280 Logs for SIP / SIP-T