Signaling Solution Description

Transcription

Telecom & Media, TGT Telecom
Signaling Products & Solutions
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Overview
page 1/55
© 2009
Tieto Corporation
signaling solution overview v1 0.docx
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Copyright
Copyright © 2012 Tieto Sweden AB.
Disclaimer
The contents of this document are subject to revision without notice, due to continued progress in
methodology, design and manufacturing.
Tieto shall have no liability for any errors or damages of any kind resulting from the use of this document.
Trademark List
Tieto™ is a trademark of Tieto Corporation in the United States and other countries.
Product Information
Document Number: MAM 100 1000-105/101
Revision: V.1.0
Date: October 3rd 2012
Validity
Please note that this document is subject to change without notice. This document includes details on both
basic and optional products. General availability of the products is subject to discretion of Tieto.
Abstract
All trademarks or registered trademarks are property of their respective owners.
page 2/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Table of Contents
1 Scope of Document ........................................................................................................................................ 5
1.1 Signaling Solutions Overview ...................................................................................................................... 5
2 Signaling Stacks & Protocols ......................................................................................................................... 7
2.1 Horizontal Distribution ................................................................................................................................. 7
2.2 Application Programming Interface - API ................................................................................................... 10
2.2.1 C/C++ Programming Interfaces ....................................................................................................... 10
2.2.2 Java Programming interfaces .......................................................................................................... 11
2.3 Portable Architecture ................................................................................................................................ 12
2.4 Supported Signaling Protocols .................................................................................................................. 13
2.4.1 SS7 protocols .................................................................................................................................. 13
2.4.2 SIGTRAN protocols ......................................................................................................................... 15
2.4.3 Radio Network Protocols ................................................................................................................. 15
2.4.4 IMS Protocols .................................................................................................................................. 16
2.4.5 LTE protocols .................................................................................................................................. 18
2.5 Packaged Products................................................................................................................................... 19
2.5.1 Stack-on-a-Card (SoaC) .................................................................................................................. 20
2.5.2 Stack-in-a-Box (SiaB) ...................................................................................................................... 21
2.5.3 Signaling for Linux ........................................................................................................................... 21
2.5.4 Signaling for Solaris® SPARC ......................................................................................................... 22
2.5.5 Signaling for Solaris® x86 ............................................................................................................... 22
2.5.6 Signaling for IBM AIX POWER ........................................................................................................ 23
2.5.7 Signaling for AdvancedTCA ............................................................................................................. 23
2.5.8 Communication Controllers.............................................................................................................. 23
2.5.9 Available types of package licenses................................................................................................. 24
3 Application Enablers..................................................................................................................................... 25
3.1 Device Detection Application (DDA) .......................................................................................................... 25
3.1.1 Application Programming Interface .................................................................................................. 27
3.2 SMS Component ...................................................................................................................................... 27
3.3 SS7 Monitor.............................................................................................................................................. 28
3.4 SIP B2BUA Component ............................................................................................................................ 29
3.5 Diameter Signaling Controller ................................................................................................................... 30
4 Tieto Gateway Platform ................................................................................................................................ 34
4.1 Protocol Gateways.................................................................................................................................... 35
4.1.1 Signaling Gateway (SGW) ............................................................................................................... 35
4.2 Legacy Voice Gateways............................................................................................................................ 36
4.2.1 ISDN/PRI - ISUP Gateway (IGW-P) ................................................................................................. 36
4.3 Unified Communication Gateways ............................................................................................................ 38
4.3.1 SIP UC Gateway and Session Border Controller.............................................................................. 38
5 Common Tools for Operation, Maintenance and Support for Tieto Signaling Products ........................... 44
5.1 Signaling Manager (GUI/CLI) .................................................................................................................... 44
page 3/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
5.2 TvTool – Trace Viewer Tool ...................................................................................................................... 47
5.3 SNMP....................................................................................................................................................... 48
5.4 Alarm GUI Viewer ..................................................................................................................................... 50
6 Professional Services ................................................................................................................................... 52
6.1 Installation ................................................................................................................................................ 52
6.2 Training .................................................................................................................................................... 52
6.3 Expert Consulting ..................................................................................................................................... 52
6.4 Maintenance & Support ............................................................................................................................ 52
7 Contacts ........................................................................................................................................................ 53
8 Acronyms and abbreviations ....................................................................................................................... 54
page 4/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
1 Scope of Document
The purpose of this document is to provide a technical overview of Tieto Signaling Solutions and Products on
open platforms. It also provides an overview of signaling network evolution and technologies in relation to Tieto
Signaling Product offerings.
1.1 Signaling Solutions Overview
Tieto Signaling Solutions supplies signaling products in several areas, ranging from pure protocol stacks to
complete network nodes, delivered as black box solutions with hardware, software, documentation and support
in accordance with the SLA. Due to the modular architecture, new products may easily be developed and
delivered with short Time-To-Market. All software may run on a variety of hardware platforms and interface
boards. Depending on customer requirements, hardware can be provided by Tieto and shipped world-wide
from our logistics centre.
Tieto Signaling product survey
Products are provided within three main areas;
Signaling Protocol Stacks, refer to chapter 2.
Application Enablers, refer to chapter 3.
Gateways, refer to chapter 4.
All product areas are built upon modular software architecture, including common tools for operation and
maintenance. The common operation and maintenance tools are described in chapter 5.
page 5/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
High availability middleware is necessary when providing world class Carrier Grade products. The chosen
components for this vary among the different products areas and are sometimes in-house developed products,
3rd party sourced products, open source products or combinations thereof. The HW middleware used for each
product is described within each product area.
A wide range of hardware components are supported within the modularized hardware platform. The platform
is used within the different product areas. Through a well-built eco-system of both products developed inhouse and by 3rd party suppliers, Tieto is able to support leading hardware technologies.
Supported hardware is described within each product area.
page 6/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
2 Signaling Stacks & Protocols
Tieto Signaling Stacks is a complete range of signaling products and services. The product line is an important
component for equipment manufacturers, software houses, system integrators, computer vendors and network
operators implementing solutions for telecoms networks.
Signaling stacks provide a base for Tieto and our partner’s product platforms for, inter alia, 2G, 2.5G, 3G and
4G IMS and LTE networks. With more than 25,000 installations worldwide, Tieto is a leading supplier of
signaling solutions to industry.
Signaling solutions provide a turnkey signaling stack platform for integration in e.g. Location-based solutions,
Messaging solutions, Prepaid solutions, Charging solutions, Voice over IP solutions, Device Detection
solutions, Softswitch solutions and Application Servers. It is compliant with all major standards; ITU, ANSI,
TTC and Chinese standards for traditional SS7 signaling. For IP-based network technologies such as
SIGTRAN, LTE and IMS, it is compliant with standards from IETF and 3GPP.
Tieto Signaling stacks guarantee scalability, high capacity, high availability, flexibility and a small footprint. In
addition, they are easy to upgrade as demands for capacity and redundancy rise.
APIs for integration with customer applications are designed for a reliable and efficient development of
customer solutions and, together with the operation and maintenance tools provided, minimize the amount of
integration work required.
Tieto supports most major open operating systems & platforms as off-the-shelf products, refer to chapter 2.5.
2.1 Horizontal Distribution
Horizontal Distribution (HD) is a deployment architecture that provides the option of deploying multiple
signaling servers all sharing the same network appearance e.g. signaling point code. With HD, Tieto is able to
offer systems with:
Extreme Performance – Performance is scaled linearly using multiple servers in a system. It is further
scalable within each server, thereby taking advantage of multi-core server architecture
Scalability - The system is easily scalable by adding more servers and traffic load is automatically distributed
over the available servers
Software and Hardware Redundancy - Redundancy can be provided by using at least two hardware servers
Unmatched In-Service-Performance (ISP) - With HD it is possible to add or remove servers dynamically
without bringing the whole system down
Customer applications may be co-located on the same server as the signaling software, or distributed over
different servers
Many different operating systems are supported for customer application integration, and it is also possible to
mix different operating systems within the same signaling system solution
Support for virtualised environments, such as VMware and RedHat, provides even further deployment options
Even if a failure occurs in one of the signaling servers in the signaling node cluster, HD ensures that the
application(s) always maintain(s) contact with the network via alternative servers. The signaling traffic is load
shared between available signaling servers.
The complete HD architecture acts as a single node in the operator network architecture, thus simplifying
network configuration and deployment.
page 7/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Signaling Horizontal Distribution Architecture
The Application Host(s) is a/are server(s) that host the customer application(s) that integrate the provided
signaling APIs and management tools for interaction with the HD Signaling Subsystem. The HD Signaling System
implements the signaling protocol stacks and architectural support software to assure high availability and simplify
operation and maintenance.
The Signaling Protocol APIs are fully distributed and allow several different applications, in several different
application CPUs, to access the signaling subsystem. Load sharing can be applied on both outgoing and
incoming signaling traffic. All communication between the signaling API and the signaling protocol stack
implementation is hidden from the application user by the provided signaling middleware, Common Parts, which
uses IP as the bearer for messages between the applications and signaling subsystem.
page 8/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
The Signaling protocol APIs are provided for C, C++ and Java application development. Different programming
languages may be mixed within the same signaling solution, having Java implementations running side by side
with C implementations. As an option, High Level APIs are available which hide the under-lying distributed
architecture of HD for application developers. All protocol APIs work in a similar ways for the chosen programming
language, which enables fast and cost-efficient development, refer to chapter 2.2 for further details.
A full set of management tools is provided for the operation and maintenance of the signaling subsystem, easing
the integration and reducing time-to-market. Signaling Manager, an easy-to-use GUI and CLI is provided for the
configuration and control of the signaling subsystem. The Signaling Manager may also be loaded as an applet
into a standard web browser such as Windows Explorer, Firefox, etc. Log daemons are provided for printing
debug and signaling trace information to log files. The generated log files can be loaded into the provided Log
Viewer, TvTool, where it is presented with signaling flows and in a human readable format. Finally, an SNMP
Agent is included for the generation of SNMP Traps in the event of failures within the signaling subsystem. For
more details on the tools provided, refer to chapter 5.
Operation and management APIs are provided for easy integration of customer applications with proprietary
management solutions. The API’s management application can control the system, monitor alarms and retrieve
statistics from the signaling subsystem. The OAM APIs can be used together with the tools provided to create
customer-specific solutions.
The HD Signaling subsystem consists of the following main processes (threads):
Back End Process (BEP) – The Back End Processes implement high level signaling protocols from MTPL3/M3UA
and above (e.g. SCCP, TCAP, MAP, etc.). Back End Process serves as a signaling message router for protocol
user data between the Signaling Protocol APIs used by customer applications and the different supported
bearers, i.e. Signaling Front Ends. The signaling subsystem supports multiple Back Ends, which may be
distributed over several servers, as well as co-located on the same server. The Back Ends interact with SS7 Front
End Processes.
SS7 Front End Process (SS7 FEP) – The SS7 Front End processes come in different flavours depending on the
low level bearer type to be used for higher level protocols.
SCTP Front End implements support for the SCTP protocol and is used as the bearer for SIGTRAN (i.e. SS7
over IP) traffic. It may also be used as a bearer for SIP and Diameter traffic. SCTP uses standard Ethernet
interfaces for IP connectivity.
MTPL2 Front End implements support for traditional MTPL2 narrowband signaling over E1/T1/J1 telecom
interfaces. It also supports High Speed Signaling broadband links that are compliant with G.703. It requires
specific communication controller boards for E1/T1/J1 terminations2.5.8 for available supported boards and
form factors (e.g. PCI Express, PMC, etc.)
NNI-SAAL Front End implements support for signaling over ATM, i.e. SSCOP over AAL5. It requires specific
communication controller boards for the E1/T1/J1 terminations. Refer to chapter 2.5.8 for available boards
and form factors (e.g. PCI Express, PMC, etc.).
M2PA Front End implements support for MTPL2 signaling over SCTP. M2PA replaces the MTPL1 E1/T1/J1
termination with standard Ethernet interfaces for IP connectivity to achieve higher performance and simplify
the low level transmission architecture.
page 9/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Diameter Front End Process (DIA FEP) - The Diameter Front End Processes implement support for the Diameter
protocol. The Diameter protocol uses standard Ethernet interfaces for connectivity. It may use TCP, UDP or SCTP
as a bearer (SCTP Front End). Security options, such as TLS and IPSec, are supported.
SIP Front End Process (SIP FEP) - The SIP Front End Processes implements support for the SIP protocol. The
SIP protocol uses standard Ethernet interfaces for connectivity. It may use TCP, UDP or SCTP as a bearer (SCTP
Front End). Security options, such as TLS and IPSec, are supported.
Network Management Process (NMP) – The Network Management Process implements the common signaling
network management procedures for the signaling subsystem. This includes control of links, route-set status,
subsystem status and associations to adjacent nodes. It thereby ensures that the signaling subsystem appears as
one network node, although multiple Back Ends may be distributed over several servers.
Execution Control (ECM/ECS) - The Execution Control processes act as signaling subsystem supervisors and
ensure high availability and successful recovery upon failures in the signaling subsystem. Each Execution Control
instance has the role as a Master (ECM) or Slave (ECS). In case of failure of the Master, any one of the Slaves
may take over as Master. Monitoring of subsystem processes (threads) is performed on process Id (thread Id),
combined with heartbeats for monitoring connectivity between processes.
Operation and Maintenance Process (OAMP) - The Operation and Maintenance Process serves as the access
point for external management and control of the subsystem. It is accessed through the OAM API for customerdeveloped applications and the Signaling Manager GUI/CLI. It serves as a router of management requests and
direct messages to the appropriate receiver within the subsystem. Through the OAM interface, a user of the
subsystem may perform control operations (orders), request and receive alarms, and collect measurement data
(statistics).
Communication Controllers (E1/T1/J1) – A range of in-house developed and third party communication controllers
is supported. Refer to chapter 2.5.8, Communication Controllers, for further information.
Ethernet Controllers (RJ-45) – The signaling subsystem uses standard Ethernet controllers available from the
chosen server hardware supplier. These may either be fixed interfaces at the server hardware or mounted in
available expansion slots.
2.2 Application Programming Interface - API
The signaling products are designed to make it easy to build a system that utilizes the underlying signaling
protocols. For the chosen programming language, the structure of the different protocol APIs is the same.
The Signaling APIs are fully distributed and communicate with the signaling subsystem by using the provided
middleware Common Parts. The actual communication implementation is transparent to the application
programmer. For most supported platforms, the majority of middleware communication is based on using
Internet sockets over TCP. Several application instances can simultaneously connect to a specific signaling
protocol and multiple protocols may be used from the same protocol instance.
2.2.1 C/C++ Programming Interfaces
For applications developed in C/C++, developers access the signaling protocols by using function calls through
a well-defined Application Programming Interface (API).
Each signaling protocol layer has its own API, containing functions and call-back definitions for all protocol
primitives and system functions. Requests/Confirmations are sent to the stack by calling predefined functions
which encode provided structures with parameter data and transport it via the middleware to the appropriate
page 10/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
receiver in the signaling subsystem. Reception of messages and events is done using call-back functions
where the function prototype is defined by the API and customer application developer completes the code
according to their need.
Before the application may send or receive messages, the middleware is initiated and inter-process
communication (IPC) channels to the signaling subsystem are set up, which each protocol uses for registration
(bind) with the subsystem and for transporting protocol data. The actual whereabouts, i.e. on which server
each process executes, are managed by the middleware, which allows applications to dynamically add and/or
remove signaling subsystem processes without taking down the complete system.
Several application instances can simultaneously connect to a specific signaling protocol, and multiple
protocols may be used from the same protocol instance. As an option, High Level APIs are available, which
hide the underlying distributed architecture of HD for application developers even further by also managing the
distribution and load sharing of traffic over available Back Ends.
Signaling API architecture
All APIs are thread-safe and support numerous different operating systems, refer to chapter 2.5 for available
off-the-shelf products.
2.2.2 Java Programming interfaces
The Java Standard Edition (J2SE) APIs provide the interfaces and classes required to connect to and receive
primitives from signaling protocols within the signaling subsystem. The APIs contain functionality to parse and
extract information from the received primitives.
The application Java program uses the API to connect to one or more instances of signaling subsystem
processes through sockets. The Provider class handles the connection to the signaling subsystem and is used
for sending/receiving events to/from the signaling subsystem.
page 11/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
The application is necessary in order to implement the methods of a Listener class, which allows primitives
(events) to be received from the signaling subsystem, by registering itself as a listener in a Provider class.
All primitives received by the Listener in the Java API are implemented as Java Events, i.e. they are
subclasses of the java.util.EventObject class.
Each primitive has its own method with a specific set of parameters implemented as member variables in the
corresponding event classes used when encoding/decoding messages.
2.3 Portable Architecture
All components of the signaling subsystem are easy to adapt to nearly any type of customer-specific
hardware/software platform. This is made possible by the highly modular and portable software architecture.
Portable Signaling Architecture
The main principle of the signaling architecture is to distil all platform dependent interfaces to a set of common
functions.
The OS Interface Middleware distils all OS service functions required by a signaling protocol layer. This makes
the signaling protocol layer software platform independent, and the same source code can be used on all
platforms.
The Lower Interface is the integration point for any software module or hardware module that provides
signaling services to the specific protocol layer. In many cases, the lower interface is directly connected to one
of the available signaling protocol layers. In such instance no adaptation is required.
The Upper API is the service access point for the customer’s application. Each signaling protocol layer has its
own accompanying API, allowing the user to get easy access from their application.
page 12/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
There is a common Management Interface used by all protocol layers within the signaling subsystem that
interface with the Operation and Maintenance process used for external management access. This enables
easier adaptation to different management solutions as the management of each protocol layer follows the
same architecture and principles provided by the internal management interface.
2.4 Supported Signaling Protocols
The sub-chapters below give an overview of signaling protocols currently available in the Tieto Signaling
products range. New protocols are added on regular basis and incorporated into the portfolio.
2.4.1 SS7 protocols
The following SS7 protocols and major standards are currently supported. Additional standard support is
added on regular basis. For details of latest supported versions, please refer to the product sheet for each
protocol.
Protocol Name
Standard Compliance
MTPL1 – Message Transfer Part Layer 1
ITU-T: G.703, G.704, G.706 and G.823
AAL-5 – ATM Adaptation Layer 5
ANSI: T1.102, T1.403, AT&T TR62-411
TTC: JT-G.703, JT-G.704, JT-I431-a
MTPL2 - Message Transfer Part Layer 2
ITU-T: Q.703
ANSI: T1.111
TTC: JT-Q.703, NTT-Q.703
MTPL3 - Message Transfer Part Layer 3
ETSI: ETSI 300 008-1, (01/97), ETSI EN 301 004-1, V1.1.3
(02/98)
ITU-T: Q.701 (03/93), Q.704 (07/96), Q.705 (03/93), Q.707
(11/88), Q.752 (06/97), Q.2210 (07/96)
ANSI: T1.111.4-1996, T1.115-1990
China: GF 001 9001, (08/90), GF 001 9001 Supplement 1 –
3 (10/91)
TTC: JT-Q701 (version 2, 11/90), JT-Q704 (version 3,
04/92), JT-Q707 (version 2, 11/90), JT-Q2210 (version 1,
04/96)
SCCP - Signaling Connection Control
Part
ETSI: ETSI 300 009-1 V1.4.3 (2001 - 02)
ITU-T: Q.711 – Q.714 (07/96), Q752 (06/97)
ANSI: T.112 (1996), T1.116.2 (1996)
China: P.R.C. 1994:10
TTC: JT-Q.711, Q.712, Q.714 (04/97), JT-Q.713 (04/2000)
TCAP - Transaction Application Part
page 13/55
© 2009
Tieto Corporation
ITU-T: Q.752 (06/97), Q.771–Q.775 (06/97)
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
ETSI: ETS 300 287-1 (11/96)
TTC: JT-Q.771–JT-Q.774 (1997)
China: P.R.C., 1994.10
ANSI: T1.114-1996, T1.115-1990
MAP – Mobile Application Part
ETSI: GSM 09.02 (V3.11.0, 04/95), GSM 09.02 (V5.3.0,
08/96), 3G TS 29.002 (V7.4.0, 06/2006), 3G TS 29.002
(V6.10.0, 06/2005)
ANSI: ANSI-41.1-D, (12/97), ANSI -41.3-D, (12/97), ANSI 41.5-D, (12/97), ANSI -41.6-D, (12/97), TR-45, IS-725-A
(PN-4173), TIA/EIA-41-D, (03/99), TR-45, IS-751 (PN3892), TIA/EIA-41-D (V7), TR-45, J-STD-036: Enhanced
Wireless 9-1-1 Phase 2, (07/00), TR-45, IS-730, IS-136
(DCCH) Support in IS-41, (07/97), TR-45, IS-771, WIN
TIA/EIA-41-C modifications, (07/99), TR-45, IS-764 (PN4103), (06/98), TR-45, IS-826 (PN-4287), (05/00), IS-841
Based Network Enhancements for MDN Based Message
Centres, TDMA Forum, Interim Over-the-Air-Activation
specification, (12/96), V1.1, TIA/EIA IS-848 (10/00)
Ericsson MAP (EMAP): GSM 03.03, 03.32, 09.02 (version
6.1.0, 08/98), GSM 03.38, 03.40 (version 3.5.0), GSM
04.11, 04.08, ITU-T Q.771–Q.775 (06/97), ITU-T X.208–
X.209 (1988)
INAP - Intelligent Network Application
Protocol
ETSI/ITU: ETS 300 374-1 (09/94), ETS 300 403-1 ITU-T
Q.931 (1993), ETS 300 356-1, EN 301 140-1 INAP Capability Set 2 (CS2) v1.3.4 (1999-06), GSM 09.02, 02.03,
03.03, 03.32, 03.78, 04.08, 09.78, 3GPP TS 29.078 V4.8.0
(03/03) CAMEL Phase 3; CAP Specification (Release 4),
Q.1218 (1993), Q.850 (1993), Q.1214 (1993), X.208 (1988),
X.209 (1988), X.219 (1988), Q.773 (03/93), Q.1228 (09/97)
Ericsson INAP CS1+
CAP - CAMEL Application Protocol
ITU: GSM 09.78 (TS 101 046), GSM 09.78 version 7.1.0
Release 1998, 3GPP TS 29.078 V4.8.0 (2003-03)
BSSAP – Base Station System
Application Part
ANSI: T1.111-T1.112, 1996
ISUP – ISDN User Part
ANSI: T1.111, T1.112, T1.114 (1996), T1.113 (1995),
T1.115 (1990)
ETSI: 3GPP TS 49.031 V7.6.0 (2008-03), 3GPP TS 48.071
V7.2.0 (2007-06), 3GPP TS 48.008 (MSC-BSS) Interface
Layer 3 Specification
ITU-T: Q.724 (11/98), Q.730-Q.735 (09/97), Q.752 (09/97),
page 14/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Q.761-Q.764 (09/97), Q.767 (02/91), Q.850 (05/98)
ETSI: ETS 300 356-1 – ETS 300 356-12, 1998, ETS 300
356-17, ETS 300 356-20, 1998, ETS 300 356-31 – ETS
300 356-36 1998
TTC: JT-Q.762 – Q.764 (09/99)
+ many national variants of ISUP
SSCOP – Service Specific Connection
Control Protocol
ITU: Q.2100, Q.2140(02/95), Q.2130(07/94), Q.2110
(07/94)
ANSI: T1.645 (1995), T1.637 (1994), T1.652 (1996)
TTC: JT-Q.2140 (04/95), JT-Q.2130 (07/94), JT-Q.2110
(02/96), JT-Q.2144
NNI-SSCF – Network Node Interface
Service Specific Coordination Protocol
ITU: Q.2100, Q.2140 (02/95)
ANSI: T1.645 (1995)
TTC: JT-Q.2140 (04/95)
2.4.2 SIGTRAN protocols
The following SIGTRAN (SS7 over IP) protocols and standards are available:
Protocol Name
SCTP – Stream Control Transmission Protocol
M3UA – MTP3 User Adaptation
M2PA - MTP2 User Peer-to-Peer Adaptation Layer
M2UA - MTP2 User Adaptation*
SUA - SCCP User Adaptation*
Standard Compliance
IETF RFC 4460 (04/2006), RFC 4960 (09/2007)
IETF RFC 4666 (09/06)
IETF RFC 4165 (05/09)
-
*available upon customer request
2.4.3 Radio Network Protocols
The following Radio Access Network (RAN) protocols are available:
Protocol Name
Standard Compliance
RANAP
3GPP Release 99
NBAP
3GPP Release 99
ALCAP
3GPP Release 99
RLC
3GPP Release 99
SSCOP – Service Specific Connection Control
Protocol
ITU: Q.2100, Q.2140(02/95), Q.2130(07/94),
Q.2110 (07/94)
page 15/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
ANSI: T1.645 (1995), T1.637 (1994), T1.652 (1996)
TTC: JT-Q.2140 (04/95), JT-Q.2130 (07/94), JTQ.2110 (02/96), JT-Q.2144
NNI-SSCF – Network Node Interface Service
Specific Coordination Protocol
ITU: Q.2100, Q.2140 (02/95)
ANSI: T1.645 (1995)
TTC: JT-Q.2140 (04/95)
UNI- SAAL – User Network Interface Service
Specific Coordination Protocol
ITU: Q.2100, Q.2140 (02/95)
ANSI: T1.645 (1995)
TTC: JT-Q.2140 (04/95)
2.4.4 IMS Protocols
The following IMS protocols are available:
Protocol Name
Standard Compliance
Bearer support
SIP
RFC 3261, RFC3262
UDP, TCP and/or SCTP
RFC 2617 - HTTP Authentication
TLS, IPSec, SigComp*
RFC 2976 - SIP INFO Method
RFC 3262 - SIP PRACK Method
RFC 3265 - SIP
SUBSCRIBE/NOTIFY methods
RFC 3310 - HTTP Digest
Authentication
RFC 3311 - SIP UPDATE method
RFC 3313 - Extensions for Media
Authorisation
RFC 3323 - Privacy Mechanism
RFC 3324 - Network Asserted
Identity
RFC 3325 - Asserted Identity in
Trusted Networks
RFC 3326 - Reason Header field
RFC 3327 - Extension Header
field
RFC 3329 - Security Mechanism
Agreement
page 16/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
RFC 3372 - SIP-T
RFC 3398 - ISUP-SIP Mapping
RFC 3428 - SIP MESSAGE
Method RFC 3455 - Private
Header for 3GPP
RFC 3515 - SIP REFER Method
RFC 3578 - Mapping ISUP
Overlap Signaling to SIP
RFC 3608 - Extension Header
field for Service Route Discovery
RFC 3725 - 3pcc in SIP
RFC 3841 - Caller Preferences
RFC 3892 - Referred-By
Mechanism
RFC 3903 - SIP PUBLISH Method
RFC 3911 - “Join” Header
RFC 4028 - Session Timers
RFC 4117 - Transcoding Services
Invocation using 3pcc
RFC 4244 - Extension for Request
History Header Information
RFC 4457 - P-User-Database
Private Header
Diameter
IETF RFC 3588, Diameter Base
IETF RFC 3539, AAA Transport
Profile
TLS, IPSec
IETF RFC 4006, Diameter CreditControl App.
IETF RFC 4005, AAA Access
Server App.
IETF RFC 4072, Extensible Auth.
Protocol App.
IETF RFC 4740, Diameter SIP
App.
IETF RFC 5447, NAS to Diameter
Interaction
3GPP TS 29.109, Zh & Zn
page 17/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Interfaces
3GPP TS 29.140, MM10 Interface
3GPP TS 29.172, SLg Interface
3GPP TS 29.173, SLh Interface
3GPP TS 32.225, Ro & Rf
Interface
3GPP TS 29.228, Cx & Dx
Interface
3GPP TS 29.229, Cx & Dx
Interface
3GPP TS 29.272, S13 & S13’
Interface
3GPP TS 29.272, S6a & S6d
Interface
3GPP TS 29.213 S9 Interface
3GPP TS 29.328, Sh & Dh
Interface
3GPP TS 29.329, Sh & Dh
Interface
3GPP TS.32.251, Gy Interface
3GPP TS.29.212, Gx Interface
SCTP – Stream Control
Transmission Protocol
IETF RFC 4460 (04/2006), RFC
4960 (09/2007)
IP
H.248 MEGACO*
-
-
*available upon customer request
2.4.5 LTE protocols
The following LTE Protocols are available:
Protocol Name
Standard Compliance
Bearer support
Diameter
Diameter Base acc. to IETF RFC
3588. In addition, various IETF
and 3GPP interface and standard
additions are also supported.
IETF RFC 4460 (04/2006), RFC
4960 (09/2007)
IP
SCTP – Stream Control
Transmission Protocol
page 18/55
© 2009
Tieto Corporation
TLS, IPSec
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
PCAP - Positioning Calculation
Application Part
3GPP TS 25.453 V7.12.0
SCTP
LCSAP – Location Service
Application Protocol
3GPP TS 29.171 V9.1.0
SCTP
2.5 Packaged Products
Tieto provides signaling protocol packages as off-the-shelf products for various operating systems and HW
architectures.
Depending on customer requirements, Tieto provides hardware - ranging from communication controllers for
E1/T1 termination to complete Stack-in-a-Box (SiaB) solutions. SiaB solutions include chassis, server blades
mounted in chassis (Stack-on-a-Card - SoaC) and communication controllers for signaling interfaces (E1/T1/J1
and/or Ethernet RJ-45).
Common features for all packaged products are:
Concurrent support for SS7, SIGTRAN, IMS and LTE protocols
IMS and LTE protocols can execute simultaneously with SS7 protocols in the same signaling subsystem
and be accessed from the same customer application
Horizontal Distribution Architecture
High capacity
Scalability
Redundancy
Mixed interface support
SIGTRAN, MTPL2 E1/T1/J1 and High Speed Signaling Links (G.703 and AAL5) in one product
Full standard support within the same delivery
Configurable options to run as ANSI, ITU, TTC or Chinese
Mixed standards; ANSI on top of ITU, ITU on top of ANSI, etc.
Distributed and thread-safe APIs for C/C++ and Java
Applications may be co-located on the same servers as the signaling subsystem
or be distributed over a different set of servers
Mixed operating system environment
Applications may run under a different operating system than the signaling subsystem
Applications may run under different operating system while accessing the same signaling subsystem,
e.g. Windows applications may co-exist with Linux applications
Common Tools for Operation and Maintenance
Signaling Manager GUI and CLI tool for configuration and control
TvTool Logviewer for interpreting signaling traces and debug info
SNMP Agent for monitoring
Supplied with warranty, support and maintenance in accordance with defined SLAs.
Phone and email support by signaling help desk
page 19/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Access to support website with software patches , maintenance releases and FAQ
For provided hardware, Tieto offers RMA handling and shipment world-wide.
Currently available off- the-shelf signaling protocol stack products are:
Stack-on-a-Card (SoaC), refer to chapter 2.5.1
Stack-in-a-Box (SiaB), refer to chapter 2.5.2
Signaling for Linux, refer to chapter 2.5.3
Signaling for Solaris® SPARC, refer to chapter 2.5.4
Signaling for Solaris® x86, refer to chapter 2.5.5
Signaling for IBM AIX POWER, refer to chapter 2.5.6
Signaling for AdvancedTCA, refer to chapter 2.5.7
2.5.1 Stack-on-a-Card (SoaC)
Stack-on-a-Card is a fully “Signaling Black Box”-embedded hardware and software solution for CompactPCI
(cPCI)-based systems. It is designed for system integrators, application developers and network operators who
are implementing SS7 connectivity in a cPCI system.
The key benefit of the Stack-on-a-Card product is that all SS7 signaling protocol software executes in a closed
environment and does not affect the customer’s application environment and/or platform, and vice versa.
This means that signaling capacity and availability can be guaranteed.
Other benefits of the product are:
High availability with HD configuration, using up to 16 SoaC boards in a single system
Designed for high availability, 99.999%
Up to eight 1.5/2 Mbps E1, T1 and J1 front-panel interfaces with up to 128 links per controller board or up to
eight 2 Mbps High Speed Links over ITU Q.703 Annexe A
Up to eight Gigabit Ethernet interfaces on front panel
Three Gigabit Ethernet interfaces per board for management and application server connectivity (using
Signaling APIs)
High capacity:
60,000 TCAP transactions/second per SoaC board
25 million ISUP BHCA per SoaC board
2 000 SIP sessions/second per SoaC board
50 000 Diameter transactions/second per SoaC board
Hot swap support
Small footprint
Support various operating systems for the application hosts. Among these are;
Sun Solaris® 9 +10
HP-UX®11i
RedHat Enterprise Linux™ Version 5 and 6
SUSE 11
MontaVista® CGE Linux™ 5
Microsoft® Windows® Server
page 20/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
The latest generation of Stack-on-a-Card, equipped
with E1/T1 terminations and SIGTRAN RJ-45 ports.
2.5.2 Stack-in-a-Box (SiaB)
The Stack-in-a-Box product provides a complete signaling interface unit with built-in cooling and power supply.
The product is supplied as a standard 19-inch rack-mounted unit, ready to be installed in existing or new
telecom nodes.
The main benefit of the Stack-in-a-Box product is that all signaling protocol software executes in a closed
environment and does not affect the customer’s application environment and/or platform, and vice versa. This
means that signaling capacity and availability can be guaranteed. SiaB solutions are offered using 1U up to 4U
chassis with integrated switches. The chassis may be interconnected to scale even further. The Stack-on-aCard is mounted in the chassis slots as signaling server blades; refer to chapter 2.5.1 for description of SoaC
features.
SiaB 1U chassis
2.5.3 Signaling for Linux
Signaling for Linux is a server-based signaling solution for Linux systems, consisting of software with optional
hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to be mounted in the
Linux servers.
It is designed for system integrators, application developers and network operators implementing SS7, SIP or
Diameter connectivity in a Linux server environment. It supports all major hardware vendors using Intel
architecture for single and multi-core CPUs. This includes, but is not limited to HP, Dell, IBM BladeCenter, etc.
Ability to execute in virtualised environments, such as:
VMware ESX 4.0
page 21/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
RedHat Virtualisation 6.1
Supported operating system for the signaling subsystem and application hosts are:
RedHat Enterprise Linux 5 and 6
SUSE 11
MontaVista CGE 5
Additional application host-only support for various operating systems.
Sun Solaris® 9 +10
HP-UX®11i
AIX 7
Support for several form factors for communication controller interface boards
PCI Express
PMC
PCI
2.5.4 Signaling for Solaris® SPARC
Signaling for Solaris SPARC is a server-based signaling solution for Solaris SPARC architectures, consisting
of software with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1)
to be mounted in Solaris SPARC servers.
Diameter connectivity in a SPARC server environment.
Supported operating system for the signaling subsystem and application hosts is:
Sun Solaris® 9 +10
PCI Express
PMC
PCI
2.5.5 Signaling for Solaris® x86
Signaling for Solaris x86 is a server-based signaling solution for Solaris Intel architectures, consisting of
software with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to
be mounted in Solaris Intel servers.
Diameter connectivity in a Solaris server environment.
Supported operating system for the signaling subsystem and application hosts is:
Sun Solaris® 9 +10
PCI Express
PMC
page 22/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
PCI
2.5.6 Signaling for IBM AIX POWER
Signaling for IBM AIX POWER 7 architecture is a server-based signaling solution for IBM POWER
architectures, consisting of software with optional hardware communication controller interface boards for
telecom interfaces (E1/T1/J1) to be mounted in the servers.
Diameter connectivity in a Solaris server environment.
Supported operating systems for the signaling subsystem and application hosts are:
AIX 7
SUSE 11
MontaVista CGE 5
Sun Solaris® 9 +10
HP-UX®11i
2.5.7 Signaling for AdvancedTCA
Signaling for AdvancedTCA architecture is a server-based signaling solution for ATCA architectures, software
with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to be
mounted in servers. The solution is integrated by Tieto on the ATCA blades chosen by the customer in a
customized solution.
2.5.8 Communication Controllers
Tieto provides a full set of Signaling Communication Controllers for various form factors and system
architectures used as part of our signaling protocol products. This chapter gives a brief overview of available
controllers.
2.5.8.1 ISR – PCIe
The Tieto ISR-PCIe low profile communication controller for PCI Express bus is a high-density controller for
SS7 signaling. It provides complete on-board Message Transfer Part Layer 2 protocol support with E1, T1 and
J1 network interfaces. It supports four E1/T1/J1 ports with up to 64 x 64kbps LSL or up to 4 x HSSL 1.5/2
Mbit/s ATM.
2.5.8.2 ISR – PMC
The Tieto ISR-PMC (PCI Mezzanine Card) communication controller for PCI bus is a high-density controller for
SS7 signaling. It provides complete on-board Message Transfer Part Layer 2 protocol support with E1, T1 and
J1 network interfaces. It supports four E1/T1/J1 ports with up to 64 x 64kbps LSL or up to 4 x HSSL 1.5/2
Mbit/s ATM up to 4 x HSL ITU-T Q.703, Annex A.
2.5.8.3 ISR-PMC / PCI Adapter
The Tieto ISR-PMC (PCI Mezzanine Card) with PCI Adapter communication controller for PCI bus is a highdensity controller for SS7 signaling. Mounting the ISR-PMC board on the PCI adapter ensures that only legacy
servers with PCI bus are supported; refer to chapter 2.5.8.2 for a description of the PMC board. The adapter
also provides support for HSL ITU-T Q.703, Annex A, on PCI architecture.
page 23/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
2.5.8.4 ISR-PMC / PCI Express Adapter
The Tieto ISR-PMC (PCI Mezzanine Card) with PCI Adapter communication controller for PCI Express bus is
a high-density controller for SS7 signaling. Mounting the ISR-PMC board on a PCI Express adapter provides
support for HSL ITU-T Q.703, Annex A; refer to chapter 2.5.8.2 for description of the PMC board.
2.5.8.5 ADAX HDC3 - 8 Trunk SS7 Signaling Controller
The HDC3 provides industry-leading SS7/ATM performance and capacity for Next Generation and IMS
networks. Designed to exceed your system requirements, the HDC3 provides superior scalability, flexibility and
price performance ratios, making it the perfect choice for your SS7/ATM signaling needs.
It supports up to 8 software-selectable trunks of full E1, T1, or J1 per card, with up to 248 LSL MTP2 links per
card with high line utilisation or up to 8 HSL MTP2 links per card.
It is available for the following form factors:
PMC
AMC
PCI/X
PCIe (Full height, Low-Profile and Express Module) board formats
2.5.9 Available types of package licenses
The signaling products are packaged for rapid installation, configuration, application development, deployment
and extensions.
The following packages are available:
Run-time package - For use in live networks. Includes license for usage, basic capacity licensing device
driver, load module for protocols, statement of compliance, configuration guide and installation guide.
Test and demo packages - For use in lab and development environments for development and testing.
Includes license for usage, C/C++/Java API library, API header files, load module for protocols, device
drivers, developers guide, API specification, statement of compliance, configuration guide and installation
guide.
Extension packages - Additional licenses for capacity expansion.
page 24/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
3 Application Enablers
The Application Enabler product family is a set of add-on products that are designed to hide the complexity of
signaling networks and protocols from the user applications and thereby significantly reduce Time-To-Market
and development costs. They are high-level applications on top of the Signaling Protocol stacks and multiple
applications can be combined within the same platform. Depending on the enabler usage some come with high
level APIs for integration with customer applications while others are complete black-box solutions with welldefined standard interfaces.
Tieto provides Application Enablers in the areas of:
Automatic Device Management and Authorization – The Device Detection Application (DDA) provides
interfaces for signaling network-based detection of devices and implementation of equipment identity registers
(EIRs); refer to chapter 3.1.
Short Message Services - The SMS component is the natural starting point for applications requiring SMS
transport and reception over SS7; refer to chapter 3.2.
Network Monitoring - The SS7 Monitor provides non-intrusive monitoring of signaling traffic and filter
mechanism to catch messages of interest to the user applications; refer to chapter 3.3.
IMS and VoIP services - The SIP B2BUA Component can act as a mediator between different SIP
implementations by providing header manipulation and service routing, e.g. forking of calls, routing to different
SIP servers, location of voice mail boxes, etc. It can also be the base for developing various application
services requiring SIP signaling; refer to chapter 3.4
LTE and IMS routing services - The Diameter Signaling Controller provides flexible routing capabilities, i.e.
acting as Diameter Proxy and/or Relay Agents between LTE/IMS network elements. It reduces the network
configuration complexity, cuts integration costs, increases scalability and provides topology hiding of operator
networks. The Diameter Signaling Controller supports the Diameter Router Agent (DRA), as defined by
3GPP; refer to chapter 3.5.
A full set of management tools is provided for the operation and maintenance of the Application Enablers.
Signaling Manager, an easy-to-use GUI and CLI is provided for configuration and control of the signaling
subsystem. The Signaling Manager may also be loaded as an applet into a standard web browser such as
Windows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace information
to log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presented
with signaling flows and a human readable format. Finally, a SNMP Agent is included for generation of SNMP
Traps in the event of failures within the signaling subsystem. For more details on the provided tools, refer to
chapter 5.
3.1 Device Detection Application (DDA)
The Device Detection Application (DDA) Enabler provides support for the development of device management
applications that rely upon signaling network-based detection of new devices, or to implement Advice of
Charge or Welcome SMS solutions that rely upon network-based device detection. It may also act in
authorization mode and, as such, serve as a high level interface for equipment registers. The DDA detects
when a handset enters the network, allowing it to be automatically configured by the device management
application using normal over-the-air-activation mechanisms such as SMS or USSD.
page 25/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
The DDA receives MAP CheckIMEI message over the SS7 network from the MSC and/or SGSN containing
the IMSI and IMEI combination. The MSC issues the MAP messages at IMSI attach (Phone Power On) or at
location update (a mobile device is moving in the network). The DDA converts the MAP CheckIMEI message
into high level API format, and passes it to the user application for further processing.
The DDA can also fetch the MSISDN from the HLR if requested by application or enabled through
configuration.
The “triplet” i.e. IMEI, IMSI and MSISDN is presented to the application over the high level API interface.
When the application has received the necessary information, it can configure the device using normal overthe-air-activation with SMS MAP. This can be done either by using an external SMSC interface, the SS7 MAP
API or, preferably, by incorporating the SMS component into the solution; refer to chapter 3.2.
The DDA API may also serve in authorization mode where the DDA user application informs DDA of the
equipment status for the phone, i.e. white, grey or black listed. Using authorization mode, customers may
rapidly develop an EIR without having to consider the complexity of SS7 protocols.
DDA interfaces
DDA is able to serve several PLMNs concurrently and support various deployment modes in operator
networks, where operators may or may not already have EIRs in operation.
page 26/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
It is used together with the Signaling Protocol Stack and is managed through the Common Tools for operation
and maintenance, refer to chapter 5.
3.1.1 Application Programming Interface
DDA APIs and OAM APIs are available for C/++ and Java. The implementation follows the same principles as
the C/C++ and Java APIs for the signaling protocol stacks, refer to chapter 2.2.1 and 2.2.2.
3.2 SMS Component
Tieto SMS Component provides the highest level of functionality for building a Short Message Service Centre
(SMS-C).
It is designed for application developers that require SMS-C features to be a part of their offered solution.
The main benefit of the SMS Component is to cut development time & costs for applications requiring SMS
functionality.
It is built using the same architecture as Tieto Signaling products and pre-integrated with Tieto signaling
protocol stacks, guaranteeing signaling interoperability with major network suppliers.
It can be used as a base for development of a full SMS-C and to develop SMS-based features such as:
Device Configuration solutions
Welcome message solutions
Tariff information systems
Advertising solutions
VAS services (carbon copy, forwarding etc.)
The ETSI MAP SS7 signaling interface is supported and an SMPP interface is provided for user applications.
The SMS Component comes in two flavours - Fire and Forget, i.e. SMPP datagram mode only, and/or Store
and Forward mode. Store and Forward mode also includes a database for persistent storage of short
messages to be retransmitted or pending delivery to end-users.
The SMS-C interacts with the following other network nodes:
MSC-S - The interface between the SMS-C and the MSC, using the MAP protocol. MSC can act both as a
submitter and receiver of short messages.
SGSN - The interface between SMS-C and SGSN, using the MAP protocol. SGSN can act both as a
submitter and receiver of short messages.
HLR - The interface between SMS-C and HLR, using the MAP protocol. HLR is used by SMS-C to query the
location of the mobile.
ESME - The interface between SMS-C and ESME, using the SMPP protocol. An ESME acts as a submitter of
short messages.
page 27/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
SMS-C interfaces
The SMS Component is implemented as an application on top of the Tieto Signaling Stack and the ETSI MAP
protocol. It supports a full set of different SS7 bearers, such as SIGTRAN, MTP E1/T1 and HSL. For a general
description of the Signaling Stack, refer to chapter 2.
The SMS Component offers SMPP protocol as the interface for applications. SMPP client library is not part of
the delivery. Several 3rd party libraries are available on the market, either as open source or commercial
versions, which can be used in customer applications. O&M APIs are available for Java. The implementation
follows the same principles as the Java APIs for the signaling protocol stacks, refer to chapter 2.2.2.
3.3 SS7 Monitor
The SS7 Monitor is an SS7 monitoring subsystem that can be used for non-intrusive monitoring of the SS7
signaling traffic. The SS7 Monitor can also be used together with signaling stacks for applications requiring
active connections to the SS7 network. The SS7 monitor provides a configurable message filter, which allows
the applications to select only the SS7 messages that are of interest. Messages that match the filter settings
are sent to the applications through easy-to-use APIs.
It supports the most common SS7 protocols, e.g. MTP, SCCP, TCAP, MAP, ANSI-41, Ericsson MAP, INAP,
CAP v1/v2, BSSAP-LE and ISUP.
The SS7 Monitor is a distributed and scalable solution where multiple monitors may be part of the same
system solution and all accessible from the same application instance. Communication controllers with E1
interfaces for connecting the tap equipment are mounted in standard PCI Express slots in standard Solaris or
Linux servers.
page 28/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
SS7 Monitor interfaces
The non-intrusive communication controller supports up to 64 links per board and multiple boards can be
combined to build larger monitor solutions.
The SS7 monitor re-uses common tools and O&M implementation from the Tieto Signaling stacks. This allows
the SS7 Monitor to run in parallel with Signaling stack users, sharing one common O&M interface.
Signaling Monitor APIs and O&M APIs are available for Java. The implementation follows the same principles
as the Java APIs for the signaling protocol stacks; refer to chapter 2.2.2.
3.4 SIP B2BUA Component
The SIP B2BUA Component provides functionality to quickly develop SIP and IMS functions such as proxies,
registrars and B2BUA for service-specific adaptations and access to external applications for development of
value-added service solutions. It provides features such as SIP Header manipulation, call redirection and
routing services for SIP-to-SIP calls. Using the SIP B2BUA component as the foundation for development of
new features or interworking functions for increased user experience, costs can be cut and time-to-market
assured.
The implementation conforms to SIP according to RFC 3261 with a number of additions, including:
Reliable Responses PRACK (RFC 3262)
P-Asserted Identity (IETF RFC 3428)
page 29/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
INFO (IETF RFC 2976)
Session Timer (IETF RFC 4028)
Answering Modes (RFC5373)
The following main features are implemented in the SIP B2BUA to decrease the time and effort for
development of new services;
SIP Registrar
Authentication of SIP users
Persistent storage of user credentials in SQL database
Conversion of To and From headers using regular expressions
Call services
Call redirection upon busy or no answer
SIP 302 and diversion headers
Call forking
Call forking list for each user with groups
Forking order according to priority
Dynamic forking based on SIP registration
Forking based on provisioned lists
Dial plan routing through regular expressions
Call admission control
Customised service adaptation option
The SIP B2BUA re-uses common tools and O&M implementation from Tieto signaling stacks. This allows the
B2BUA to run in parallel with signaling stack users, sharing one common O&M interface. The SIP B2BUA is
scalable, with up to ten concurrent B2BUA instances within the same signaling subsystem.
The SIP B2BUA is a Java 2 Standard Edition Implementation which allows for portability across various
environments supporting a JVM.
Include O&M management Java 2SE API option for integration with 3rd party management systems. B2BUA
API for service implementation is offered upon request.
3.5 Diameter Signaling Controller
Tieto Diameter Signaling Controller provides a flexible, robust and secure solution for reduced overall signaling
load, simplified network configuration scenarios at roll-out and upgrade as well as secure and efficient intranetwork connectivity.
Through its flexible routing capabilities, i.e. acting as Diameter Proxy and/or Relay Agent between LTE/IMS
network elements, it reduces network configuration complexity, cuts integration costs, increases scalability and
provides topology hiding of operator networks. The Diameter Signaling Controller supports the Diameter
Router Agent (DRA) as defined by 3GPP.
page 30/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Diameter Signaling Controller interfaces
The Tieto Diameter Signaling Controller is based on the company’s world-class signaling products and is built on
the same robust and carrier grade architecture as other Tieto Signaling solutions for applications such as the
traditional SS7 and SIP.
The solution is built for industry standard Linux servers, such as IBM BladeCenter.
The following main features are supported:
May act as number of different nodes:
Diameter Routing Agent (DRA)
Diameter Edge Agent (DEA)
page 31/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Diameter Load Balancer
Diameter Proxy Agent
Diameter Relay Agent
Diameter Redirect Agent
Generic routing abilities
Routing on Realms, Host ID, Application ID
AVP Content based routing e.g. IMSI, IP Address, etc.
Load sharing (round-robin) or priority-based destination routing
Forking of messages to multiple destinations
Stateless and stateful (session stickiness) routing
Configurable modification of message content
Configurable Dictionary for proprietary Vendors, Commands and AVPs implementations
Transport protocols:
SCTP (IETF RFC 2960)
TCP
IPv4 & IPv6
TLS
IPSec
The Diameter Signaling Controller is developed in accordance with the following standards:
IETF RFC 3588, Diameter Base
IETF RFC 3539, AAA Transport Profile
IETF RFC 4006, Diameter Credit-Control App.
IETF RFC 4005, AAA Access Server App.
IETF RFC 4072, Extensible Auth. Protocol App.
IETF RFC 4740, Diameter SIP App.
IETF RFC 5447, NAS to Diameter Interaction
3GPP TS 29.109, Zh & Zn Interfaces
3GPP TS 29.140, MM10 Interface
3GPP TS 29.172, SLg Interface
3GPP TS 29.173, SLh Interface
3GPP TS 32.225, Ro & Rf Interface
3GPP TS 29.212, Gx interface
3GPP TS 32.251, Gy interface
3GPP TS 29.228, Cx & Dx Interface
3GPP TS 29.229, Cx & Dx Interface
3GPP TS 29.272, S13 & S13’ Interface
3GPP TS 29.328, Sh & Dh Interface
3GPP TS 29.329, Sh & Dh Interface
3GPP TS 29.213, S9 interface
3GPP TS 29.272, S6a & S6d interface
IMS ready, supports all 3GPP specific identities, command codes and results codes defined in 3GPP TS
29.230 (2007-09)
More than 120,000 Diameter messages per second using a quad-core Intel Xeon¨2.4GHz processor
page 32/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
The DSC reuses common tools and O&M implementation from Tieto signaling stacks. This allows the DSC to
run in parallel with signaling stack users, sharing a single common O&M interface. The DSC is scalable with up
to 10 running concurrently within the same signaling subsystem.
The DSC is also able to act as a Diameter end node (server or client) with C/C++ and Java J2SE APIs for
customer application integration.
For O&M there are Java 2SE API and C/C++ options for integration with 3rd party management systems.
page 33/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
4 Tieto Gateway Platform
With its Gateway Platform offering, Tieto provides gateways to significantly shorten network integration lead
times and reduce costs. Its complete set of components allows to not only provide off-the-shelf gateways but
also to provide customized solutions. The Gateway Platform is a hardware and software platform solution that
can also be used for building signaling and/or media gateways. It affords fast and effective development of
customer-specific gateway solutions with carrier grade characteristics.
The short TTM and cost efficiency afforded by re-using the building blocks provides a financially favourable
option to use the result as either a “gap-filler” or a permanent solution. The product and its total lifecycle are
managed by Tieto.
Tieto Gateway Platform components
Based on the Gateway Platform, the following gateways are available off-the-shelf:
Protocol gateways
Legacy voice gateways
Unified communication gateways
With the network evolution and convergence, the Gateway Platform is well suited to serve as the basis for
developing gateways to bridge the gap between the latest network technologies and existing legacy networks.
page 34/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
There are numerous areas where gateways may be necessary in order to provide seamless service
interaction, e.g. SMS interworking with IMS and CAP/IN service interworking with IMS.
A full set of management tools is provided for the operation and maintenance of the Tieto gateway platform.
Signaling Manager, an easy-to-use GUI and CLI is provided for configuration and control of the signaling
subsystem. The signaling manager may also be loaded as an applet into a standard web browser such as
with signaling flows and a human readable format. Finally, an SNMP Agent is included for the generation of
SNMP Traps in the event of failures within the signaling subsystem. For more details about the tools provided,
refer to chapter 5.
4.1 Protocol Gateways
4.1.1 Signaling Gateway (SGW)
Tieto SGW is a complete carrier-grade signaling interface solution that provides interconnectivity between
legacy SS7 domains and SIGTRAN domains. The Tieto Signaling Gateway is a distributed solution based on
the Horizontal Distribution (HD) concept.
Tieto SGW provides a signaling solution containing both hardware and software, targeting the following
situations:
Providing IP access to legacy SS7 nodes
Providing legacy SS7 access for SIGTRAN-only nodes
IP back-haul
STP & SRP replacement
Signaling Gateway interfaces
This is an “all-in-one” Black Box solution built using carrier grade SW and HW components to ensure high
availability and scalability. The hardware used in the SGW is based on CompactPCI build set and consists of
the Stack-On-a-Card blades and Stack-in-a-Box family of chassis.
By adding multiple SGW blades, higher traffic loads can be managed. Scaling over several blades is close to
linear, the scaling factor being approx. 1.8 times/SGW Blade.
page 35/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
The Tieto SGW delivers exceptionally high in-service performance, reaching 99.999% availability when using
at least two SGW Blades either in separate 1U chassis or in a single 2U chassis.
The Tieto Signaling Gateway product includes the following:
SS7 Signaling Protocol Stack with support for IETF, ANSI, Chinese, ITU and TTC Standards.
SGW Application SW
Management and configuration tool able to run as standalone applications or within a web browser.
SNMP support
Hardware
4.1.1.1 Signaling Gateway (SGW) Architecture
The Signaling Gateway is built on the horizontal distribution (HD) SW architecture and is packaged as a
standalone black box solution using Stack-on-a-Card and Stack-in-a-Box hardware, refer to chapter 2.5.1 and
2.5.2. For a description of software architecture, refer to chapter 2.1.
4.1.1.2 Application Programming Interface
O&M management C/C++ and Java 2SE API for integration with 3rd party management systems is available
upon request.
4.2 Legacy Voice Gateways
Tieto Legacy Voice Gateways are a set of gateways that provide protocol interworking for legacy SS7
networks and the access network.
4.2.1 ISDN/PRI - ISUP Gateway (IGW-P)
The ISDN/PRI – ISUP Gateway (IGW-P) acts as a protocol converter for basic call services between ISDN PRI
accesses (e.g. PBXs) and SS7 ISUP interfaces.
The IGW-P can, for instance, be used for providing ISDN PRI access for core network nodes (e.g. MSC,
MGW, etc.), which provide support for ISUP SS7 voice trunks. The actual voice paths over B-channels and
SS7-controlled voice trunks are separated from the signaling timeslots through multiplexor (MUX) equipment,
which may be an integrated part of adjacent nodes, such as MGW or MSC, or separate external equipment.
The MUXs extract the protocol data sent over the SS7 ISUP signaling links from the voice channels and PRI
D-channel signaling from B-channel data into separate timeslots sent over an E1/T1 or SIGTRAN interface to
the IGW-P for protocol conversion. After conversion, the protocol data is multiplexed back into the proper
timeslots for forwarding to the ISDN equipment (e.g. PBX) and SS7 network node. Tone generation and
detection, as well as routing number analysis, is performed by the PBXs and the adjacent SS7 exchange.
For PRI ISDN, up to 248 D-channels may be converted using up to 8 E1/T1 PCM interface ports (31 Dchannels per E1, 24 D-channels per T1). The narrowband SS7 network access supports up to 4 E1/T1 PCM
interface ports (max 31 per E1 port, 24 per T1 port) and 64 signaling links in total.
The IGW-P hardware is based on the Compact PCI form factor.
page 36/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
IGW-P interfaces
IGW-P HW
A full set of management tools is provided for the operation and maintenance of the IGW-P. Signaling
Manager, an easy-to-use GUI and CLI, is provided for the configuration and control of the signaling subsystem.
The signaling manager may also be loaded as an applet into a standard web browser such as Windows
Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace information to log files.
The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presented with
signaling flows and in a human readable format. Finally, an SNMP Agent is included to generate SNMP Traps
in the event of failures within the signaling subsystem. For more details about the tools provided, refer to
chapter 5.
All software is packaged as RPM packages for easy installation and SW upgrade.
page 37/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
The IGW-P is a black box solution. MIBs are provided for integration with SNMP Manager and GUI/CLI for
controlling the system. O&M management C/C++ and Java 2SE API for integration with 3rd party management
systems is available upon request.
4.3 Unified Communication Gateways
The Unified Communication Gateways provide a complete system solution to allow interconnection between
SIP-based enterprise network PBXs and operator networks. They can use either IMS network and/or legacy
SS7 network as the integration point. The UC gateways are compliant with Microsoft OCS R2 and Lync
Mediation Server for Unified Communications integration with operator networks and may easily be integrated
with various PBXs, providing a SIP Trunk interface. The gateways come in two main flavours:
SIP UC Gateway – An all in one package, providing a SIP Trunk interface to PBXs with the ability to also
integrate with legacy SS7 and ISDN networks, i.e. perform SIP – SS7/ISDN protocol and media conversions.
It can also integrate with IMS networks and combine IMS and legacy integration.
SIP UC Session Border Controller (SBC) – An all-IP gateway acting as a session border controller between
SIP Trunks and providing necessary security mechanism towards enterprise SIP Trunks, as well as protocol
and media conversion between different flavours of SIP Trunk and the IMS integration point.
4.3.1 SIP UC Gateway and Session Border Controller
The SIP UC Gateway product provides a complete system solution to allow interconnection between SIPbased enterprise network PBXs and operator networks. It can use IMS networks and/or legacy SS7/ISDN
networks as the integration point. It is compliant with Microsoft OCS R2 and Lync Mediation Server for Unified
Communications integration with operator networks, but can also be integrated with various PBXs, providing a
SIP Trunk and/or ISDN interface.
SIP-UC gateway interfaces.
page 38/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Depending on network integration scenario, the SIP UC gateway may include several components. The
principle ones being:
Media Gateway Controller (MGC), refer to chapter 4.3.1.1.1
Media Getaway (MGW), refer to chapter 4.3.1.1.2
SIP Back 2 Back User Agent (B2BUA), refer to chapter 4.3.1.1.3
SIP Session Border Controller (SBC), refer to chapter 4.3.1.1.4
SIP Telephony Announcement Server, refer to chapter 4.3.1.1.5
3rd party Call control Telephony Interface (CTI), refer to chapter 4.3.1.1.6
By combining the components a wide range of features are provided. Among these features are:
SIP to/from SS7 ISUP protocol conversion according to RFC 3398 and ITU Q.1912.5
Multiple SS7 interface options:
IETF SIGTRAN
SS7 TDM Narrowband Links
SS7 High Speed Links
SIP signaling standard:
SIP transport over UDP, TCP and TLS
IETF RFC 3261
IETF RFC 3262 (i.e. reliable responses)
IETF RFC 3264 (i.e. offer/answer)
IETF RFC 3515 (i.e. REFER)
IETF RFC 4028 (i.e. timer)
IETF RFC 4566
IETF RFC 5373 (Answer modes)
DTMF Info-Event Package draft-kaplan-sipping-dtmf-package-00. Provide DTMF using SIP INFO
Call Services:
User Authentication i.e. SIP Registrar
User credentials stored permanently in database
SIP REGISTER support with MD5 Digest authentication
Call Redirection upon busy or no answer
SIP 302 and diversion headers
Call forking
Call forking list for each user with groups
Forking order according to priority
Dynamic forking based on SIP registration
Forking based on provisioned lists
Dial Plan routing through regular expressions
MS Lync integration option
Header adaptation and suppression of unsupported SIP methods when integrating operator network
with MS Lync
Call Admission Control
Customised service adaptation option
3rd party call control
Playing and recording of announcements
Media protocols:
H.248 for controlling MGW
page 39/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
TDM E1/T1 PCM
RTP/RTCP per RFC 3550/3551
SRTP per RFC 3711
DTMF over RTP per RFC 2833
DTMF over SIP INFO
Comfort Noise (RFC3389)
Silent Suppression
Voice coding:
G.711, G.723.1, G.729A/B, G.726, G.727, GSM-FR, GSM-EFR, EVRC, NB-AMR, iLBC, RT Audio
Wideband coders, including G.722 and AMR
Echo cancellation:
G.168-2002 compliant, up to 128ms configurable tail lengths
In-band signaling:
DTMF, MF detection & generation
Call Progress tones detection & generation
Playing and recording of announcements
Security:
VLAN tagging IEEE 802
TLS
SRTP
SSH
Secure and hardened OS
Media capacity:
Up to 2016 media ports per media blade (capacity depending on codec)
Up to 42 * E1/T1 interfaces per media blade
Up to two STM-1/OC3 in automatic protection mode per media blade
Built on standard 19-inch rack mount chassis
Up to 4U height chassis
Two slots for Signaling & Media Controller blades
Up to 5 slots available for Media blades
One 4U unit can handle up to 9765 ports & 210 E1/T1 interfaces
Dual Ethernet switches
Redundant power supplies (AC or DC)
Hot swap (blades, PS and fans)
A full set of management tools is provided for the operation and maintenance of the SIP UC Gateway.
Signaling Manager, an easy-to-use GUI and CLI is provided for the configuration and control of the signaling
subsystem. The signaling manager may also be loaded as an applet into a standard web browser such as
with signaling flows and in a human readable format. Finally, an SNMP Agent is included for the generation of
SNMP Traps in the event of failures within the signaling subsystem. For more details about the tools provided,
refer to chapter 5.
page 40/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
4.3.1.1 SIP UC Gateway Architecture
SIP UC gateways share a common architecture and platform, and the software can be easily ported to various
hardware environments. The hardware supplied by Tieto is built on industry-standard CompactPCI
components with carrier-grade Linux OS, or on rack-mounted Linux servers.
It consists of four principle HW components;
Application Blade(s) – Run-time environment for application signaling software and service control. These are
Intel-based CPU architecture blades running MontaVista Carrier Grade Edition (CGE) 5 Linux. The Stack-ona-Card PP512 is the most common HW used as application blades.
Media Gateway Blade(s) – Provides media features, e.g. transcoding between codecs or RTP/SRTP,
announcement and tone generation. The media blades also provide legacy interfaces for TDM and/or STM-1
terminations. The media blades are controlled from the application blades using H.248.
IP Switching Blade(s) – IP is used as the transport mechanism for communication between different
application blades, control of media blades and between different media blades. The gateways may be
ordered using integrated switches for switching traffic using the chassis backplane. For this, PICMG 2.16 is
supported with up to 1 Gbit/s in the chassis backplane. Redundant layer 2 or layer 3 switches are supported
depending on customer requirements.
Chassis - Various sizes of chassis are available, ranging from 2U (4 slots) up to 4U (8 slots) chassis with
integrated switches.
The smallest configuration consists of one application blade and one media blade. Several chassis can be
interconnected to build larger systems
4U chassis with cPSB/Dual 6U Switch PICMG 2.16, 2 application blades,
2 Media Gateway blades and 1 IP Switch blade.
The following sub-chapters give a brief overview of the different system components.
4.3.1.1.1 Media Gateway Controller (MGC)
The MGC provides SIP and SS7 ISUP protocol interworking in accordance with RFC 3398 and ITU Q.1912,
with various standard additions. It controls one or several Media Gateways using H.248. It is implemented as
an application on top of the Tieto signaling stack, which provides the necessary signaling protocols and
interfaces. For a general description of the signaling stack, refer to chapter 2. It executes on the application
blades.
page 41/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
4.3.1.1.2 Media Gateway (MGW)
The MGW function is sourced through 3rd party suppliers, but as the MGW is controlled by the MGC using
H.248, various suppliers’ products can easily be integrated. Tieto has currently integrated with the following
MGW boards, which are available as off-the-shelf products and are pre-integrated in our chassis or standard
PCs.
AudioCodes TP-series – TP-260, TP-1610, TP-6310 and TP-8410.
AudioCodes IPM-series – IPM-260, IPM-1610, IPM-6310 and IPM-8410.
The range of boards enables the provision of 120 ports up to 2016 ports per board with support for E1, T1 and
STM-1 interfaces. Multiple boards can be co-located within the same chassis or distributed over several
chassis to create larger system configurations.
MGW blade, AudioCodes IPM-6310 series
4.3.1.1.3 SIP Back 2 Back User Agent (B2BUA)
In the context of UC Gateways, the B2BUA provides additional features, such as call routing, call forking and
user authentication by acting as a Registrar for SIP UA terminals or PBXs. User credentials and forking lists
are administered using the DB provided. It is the SIP integration point for the enterprise SIP Trunk and IMS
network, and interfaces the MGC for legacy interworking. It allows for customized service development, such
as header conversion and redirection services and executes on the application blades.
SIP B2BUA features are described in chapter 3.4.
4.3.1.1.4 Session Border Controller (SBC)
The SBC option is a specialized version of the SIP B2BUA component that also has media control, providing
SBC features for integrating enterprise SIP Trunks with IMS networks i.e. acting as an IP – IP gateway. In SBC
mode, the SIP B2BUA also controls MGWs using H.248 and thereby provides media features such as
transcoding and encrypted media using SRTP. The SBC is also able to handle various flavours of SIP Trunk,
such as the Microsoft Lync-supported subset of the SIP protocol. It executes on the application blades.
page 42/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
4.3.1.1.5 SIP Telephony Announcement Server (TAS)
SIP Telephony Announcement Server (TAS) gateways allow users to record announcements and play
announcements that are to be invoked in calls. The announcements are recorded on network-mounted disks
and played via NFS streaming. Announcements may be stored on a customer-specific server or locally on the
gateway. The announcement server is controlled via SIP. Announcement client SW may be included upon
request.
4.3.1.1.6 3rd Party Call Control Telephony Interface (CTI)
Using the 3rd party call control telephony interface (CTI), application call control may be carried out for SIP UAs
registered with the gateway via an API. The interface is uaCSTA-inspired and provides the following
operations:
Alternate Call – Places an existing call on hold and retrieves a previously held call at a UA.
Answer Call – Answers an alerting call at a UA.
Clear Connection – Clears a connection at a UA.
Consultation Call – Places an existing call on hold at the UA and initiates a new call from the UA.
Deflect Call – Moves a connection away from the deflecting UA. The deflecting UA is no longer involved with
the call after the Deflect Call service is completed.
Hold Call – Holds a call at the holding UA.
Make Call – Makes a call from an originating UA.
Reconnect Call – Clears an existing connected call and retrieves a call on hold at a UA.
Retrieve Call – Retrieves a call at a retrieving UA.
Single Step Transfer – Transfers a connected call to another device without placing the call on hold. The
transferring UA is no longer involved with the call after this service is completed.
Transfer Call – Merges two calls at the UA into one call. Following the transfer, the device is no longer
involved with the call.
Monitor Start – Establishes a device-type monitor on a UA.
Monitor Stop – Terminates an existing monitor.
UC gateways are black box solutions. MIBs are provided for integration with SNMP Manager and GUI/CLI for
controlling the system. O&M management, C/C++ and Java 2SE API for integration with 3rd party
management systems are available upon request. User administration is performed by interfacing the provided
SQL DB. SIP B2BUA and SBC API for service implementation are available upon request.
page 43/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
5 Common Tools for Operation, Maintenance and Support for Tieto Signaling Products
The following sub-chapters provide an overview description of the supplied tools and their features.
The diagram gives a high level overview of the common tools for Operation, Maintenance and Support for all
Tieto Signaling Products that provide the same look and feel when combining multiple products.
High level overview of the common tools
5.1 Signaling Manager (GUI/CLI)
Signaling Manager is a node management tool that is used to configure and control Tieto Signaling Products.
The Signaling Manager provides a Graphical User Interface (GUI) and a Command Line Interface (CLI) for the
configuration and operation of the signaling system. The GUI can be executed, both as a standalone
application and as an applet in a browser. The Command Line Interface (CLI) with command completion can
be started as a standalone tool or run from within the GUI.
page 44/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Through in-depth checking, customer problems can easily be resolved, thereby improving customer care and
reducing configuration time. The main task of the Signaling Manager is to create/modify and manage signaling
system configurations and provide an interface for controlling the system through commands (Actions).
It can be started in both online and offline mode. In offline mode, users can prepare and create configuration
files, perform validation and generate configuration data without access to a complete signaling system. In
online mode, a connection to the signaling subsystem is set up and used. Configurations can be created,
validated and stored in the local file system or in a remote file system using FTP or SFTP.
Signaling Manager snapshot
Title Bar Shows the title, system standard and current file name.
Menu Bar Provides access to basic Signaling Manager functions, such as creating, opening, saving and
exporting configurations.
Navigation Pane Contains all Elements that make up the configuration. It is built up as an easy navigation
tree with automatic element names and search features.
Operation Pane Consists of:
Properties tab to view and edit properties. All properties have default values that reduce the number of
configuration parameters that can be set manually.
page 45/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Actions tab to select and perform Actions (Orders) for an Element.
Statistics tab to select and retrieve counters and statistical information.
CLI tab to perform MML commands. CLI may also run as a standalone function.
Information Pane Consists of:
Description tab for viewing the description of a selected property.
Log tab for logging information when debug is enabled.
Results tab for viewing the result of a validation or search.
Action Results for viewing the result of the performed action.
Alarm for viewing current alarms and alarm notifications.
Status Bar Displays status information about the connection to the signaling subsystem and overall
subsystem status.
Help Built-in online help.
Alarms to be activated are set using configuration settings
Alarm Tab Overview
page 46/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Statistics Tab Overview
Audit logs are supported where all user commands and changes to configurations are logged to file system
and may be viewed in the GUI.
Audit log
In addition, support is also provided for different user access levels and these can be configured to prevent
certain users gaining access to specific features. Each access level defines a particular set of SM capabilities.
These are ordered from the minimum to the maximum, with each subsequent access level including access to
the previous one.
5.2 TvTool – Trace Viewer Tool
page 47/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
The Trace Viewer Tool, TvTool, provides full protocol decoding of the Signaling trace files produced by Tieto
signaling products. It simplifies your analysis and shows the contents of your signaling log files in human
readable format. It includes sophisticated message filtering functions, a message viewer for detailed
information about all parameters in a selected protocol message, user-defined colour coding and an adaptable
graphical user interface.
It can be used offline or online to view an existing log file or view a log file from an executing stack with
continuous real-time updates. It presents different types of event; Messages, Error, Trace / State & Event and
Timers using different colours, messages to/from signaling network and internal messages are shown with
arrows. Click on an arrow and the message is decoded in the decoding panel.
It also provides a set of search functions to reduce the amount of work required to pinpoint problems using the
system trace as input.
TvTool snapshot.
5.3 SNMP
The Signaling SNMP support consists of the master agent, Signaling SNMP System Monitor (3SM), as well as
OS sub agents (Net-SNMP 5.1.2). The master agent “listens” for alarms from the Signaling system and
processes/converts these into SNMP traps. The master agent also serves as a proxy for the OS sub agent,
page 48/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
with one sub agent being run on each Signaling host. Any external SNMP Manager only connects to the 3SM
agent.
SNMP traps handling.
Fault management can be split into alarms and events. Alarms are defined as error states that can be cleared.
Alarms are reported using SNMP Traps.
Errors that cannot be cleared, but instead only occur at an instant of time, are called Events.
Events are only recorded in the event log. The log file contains time and date of the event, the level of severity
and the message describing the event.
Example;
26-Jun-2006 08:46:46 - [SEVERE] - SCTP Layer - Module is not started.
26-Jun-2006 08:46:51 - [CLEAR] - SCTP Layer - Module is started.
Alarms in the system are modelled using the framework outlined in ALARM-MIB, RFC3877. The concept is
based on a table, alarmModelTable, storing a set of alarm lists. Each alarm can have multiple states
(severities). An alarm represents an error state that can be cleared. When an alarm is active, an entry is added
to the alarmActiveTable, and the alarm variables are added to alarmActiveVariableTable. When an alarm is
cleared, it is moved to alarmClearTable.
The alarm models use generic notifications - alarmActiveState and alarmClearState. When an alarm is raised,
an alarmActiveState SNMP trap is issued. When the corresponding alarm is cleared, alarmClearState is
issued. Note that alarms can have multiple severities (states). A transition from one state to another is also
signalled using alarmActiveState.
page 49/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Alarm handling tables
An extension to the alarm MIB has been created, AlarmMibExt. This represents an extra conceptual column in
the alarm model table. It is used to store a flag indicating whether the alarm should be enabled (on) or disabled
(off). By setting this to 0 (off), the traps for a specific alarm are turned off.
The NET-SNMP OS sub-agents support DISMAN-EVENT-MIB. They are configured to report four alarms.
The traps sent out are received by the master agent and then forwarded to the trap listener. The source of the
traps can be identified by inspecting the SNMP community string in the traps. The community strings have the
name used by each Signaling host.
The following alarms are pre-configured:
CPU idle less than 5% (cleared when above 10%)
Memory available less than 128MB (cleared when above 160MB)
Disk use more than 80% (cleared when less than 70%)
Network interface up/down (linkUp/linkDown)
The SNMP Master Agent is a Java implementation. The alarm information presented in each trap reuses the
naming convention created during system configuration using the Signaling Manager GUI/CLI. For this
purpose, the SNMP Master agent accesses the configuration file(s) generated by Signaling Manager.
5.4 Alarm GUI Viewer
The Alarm Viewer GUI is a graphical tool for displaying active alarms received as SNMP Traps from the SNMP
Master Agent.
The tool displays all alarms that can occur in the system by connecting to the Signaling SNMP System Monitor
agent
ALARM-MIB alarms are displayed in a tree hierarchy. An additional list shows the different OS alarms received
from the OS sub-agents
page 50/55
© 2009
Tieto Corporation
Anders G Karlsson
Alarm GUI Viewer
The SNMP agent is implemented in Java and as a standalone application.
page 51/55
© 2009
Tieto Corporation
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
6 Professional Services
6.1 Installation
Tieto can assist and give customers’ organization a quick start when using Signaling Products, providing
installation and run-time environment configuration services.
6.2 Training
To achieve a better and faster understanding of Tieto Signaling products, we provide standard or tailored
training to our customers. Our standard training sessions cover areas such as general Signaling (SS7,
SIGTRAN), installation, configuration and application programming. Most of our training sessions feature both
theoretical and practical (exercises) elements.
Tieto can also provide training on request, and courses can be tailored to a customer’s specific criteria.
6.3 Expert Consulting
Tieto has the expertise and procedures to assist in specific questions regarding Signaling Solutions.
Sometimes, top-level expert advice is required. Tieto can provide this for shorter periods to assist in:
Solutions specifications
Presentations
Design reviews - participating in technical discussions
Customer discussions
Interoperability tests are often required as part of an acceptance procedure. Tieto has the expertise and
procedures to assist in or perform interoperability tests in labs or on site in conjunction with customers.
6.4 Maintenance & Support
Tieto’s Customer Support Centre provides a single point of contact for support and maintenance and offers the
following services in accordance with the terms and conditions set out in Maintenance & Support Agreements:
Basic Support – telephone support, advice, and active participation in system problem analysis during normal
business hours defined as Monday – Friday 8:00 am to 5:00 pm CET.
Repair or replacement of faulty hardware components, such as communications controllers.
Correction of software and documentation errors.
Distribution of maintenance releases.
Customer web login for easy access to Signaling Products.
Extended support outside normal business hours, e.g. helpdesk access on a 24/7/365 basis.
On-site assistance.
page 52/55
© 2009
Tieto Corporation
Anders G Karlsson
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
7 Contacts
Please do not hesitate to contact us if you have any questions. We will be happy to assist you.
E-mail: [email protected]
Website: http://www.tieto.com/signaling
Our office:
Tieto Sweden AB
P.O. Box 1038
SE-651 15 Karlstad
Sweden
Phone: +46 (0)10 481 0000
page 53/55
© 2009
Tieto Corporation
Anders G Karlsson
8 Acronyms and abbreviations
ANSI
ANSI-41
API
ATM
AXE
BICC
BSC
BSSAP
CAMEL
CAP
CDMA
cPCI
CPU
CS1
ETSI
FPGA
GSM
GUI
HA
HLR
IETF
IN
INAP
IP
ISR
ISDN
ISUP
ITU
M3UA
MAP
Mbps
MGCP
MSC
MTP
PCI
PMC
PSTN
SCCP
SCP
SCTP
SIGTRAN
SIP
SMS
SMSC
TCAP
TDMA
TTC
American National Standards Institute
ANSI standard 41 (Previously known as IS-41)
Application Programming Interface
Asynchronous Transfer Mode
Ericsson switching platform
Bearer Independent Call Control
Base Station Controller
Base Station System Application Part
Customised Applications for Mobile network Enhanced Logic
CAMEL Application Part
Code Division Multiple Access
CompactPCI
Central Processing Unit
Capability Set 1
European Telecom Standards Institute
Field Programmable Grid Array
Global System for Mobile communications
Graphical User Interface
High Availability
Home Location Register
Internet Engineering Task Force
Intelligent Network
Intelligent Network Application Protocol
Internet Protocol
In System Reconfigurable (hardware)
Integrated Services Digital Network
ISDN User Part
International Telecommunications Union
MTP-L3 User Adaptation Layer
Mobil Application Part
Megabit per second
Media Gateway Control Protocol
Mobile Services Switching Centre
Message Transfer Part
Peripheral Component Interconnect
PCI Mezzanine Card
Public Switched Telephone Network
Signaling Connection Control Part
Service Control Point
Stream Control Transport Protocol
Signaling Transport
Session Initiation Protocol
Short Message Service
Short Message Service Centre
Transaction Capabilities Application Part
Time Division Multiple Access
Telecommunications Technology Committee
(Japanese standardisation body)
page 54/55
© 2009
Tieto Corporation
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012
Anders G Karlsson
UMTS
VoIP
Universal Mobile Telecommunications System
Voice over IP
page 55/55
© 2009
Tieto Corporation
MAM 100 1000-105/101 V1.0
Public
rd
October 3 2012

Signaling Solution Description

Transcription

Similar documents

Buschke-Ollendorf Syndrome: Report of a Case and a Brief

SMG2000 Datasheet, Ver 1.0

SMG Integrated Media Gateway

neuronal plasticity

slides

Avaya Communication Server 1000E

Signal Aspect

Poster - MIT Computational Biology Group

Arbor Networks MNA Data Sheet