Signaling Solution Description - Tieto

Signaling Solution Description 

Telecom & Media, TGT Telecom MAM 100 1000-105/101 V1.0 

Signaling Products & Solutions Public 

Anders G Karlsson October 3 rd 2012 

page 1/55 

© 2009 

Tieto Corporation signaling solution overview v1 0.docx 


Overview





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 3 rd 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 signaling solution overview v1 0.docx





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 






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 






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. 

page 5/55 

© 2009 


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.





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, 

3 rd 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 3 rd party suppliers, Tieto is able to support leading hardware technologies. 

Supported hardware is described within each product area. 

page 6/55 

© 2009 






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 






page 8/55 

© 2009 


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.





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 






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 






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. 

page 11/55 

© 2009 


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.





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. 

page 12/55 

© 2009 


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.





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 

AAL-5 – ATM Adaptation Layer 5 

MTPL2 - Message Transfer Part Layer 2 ITU-T: Q.703 

page 13/55 

© 2009 


ITU-T: G.703, G.704, G.706 and G.823 

ANSI: T1.102, T1.403, AT&T TR62-411 

TTC: JT-G.703, JT-G.704, JT-I431-a 

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) 

SCCP - Signaling Connection Control 

Part 

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) 

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 ITU-T: Q.752 (06/97), Q.771–Q.775 (06/97)





page 14/55 

© 2009 


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) 

INAP - Intelligent Network Application 

Protocol 

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

3892), 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 (PN- 

4103), (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) 

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 

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 

ISUP – ISDN User Part ANSI: T1.111, T1.112, T1.114 (1996), T1.113 (1995), 

T1.115 (1990) 

ITU-T: Q.724 (11/98), Q.730-Q.735 (09/97), Q.752 (09/97),





SSCOP – Service Specific Connection 

Control Protocol 

NNI-SSCF – Network Node Interface 

Service Specific Coordination Protocol 

2.4.2 SIGTRAN protocols 

page 15/55 

© 2009 


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 

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 

ITU: Q.2100, Q.2140 (02/95) 

ANSI: T1.645 (1995) 

TTC: JT-Q.2140 (04/95) 

The following SIGTRAN (SS7 over IP) protocols and standards are available: 


SCTP – Stream Control Transmission Protocol IETF RFC 4460 (04/2006), RFC 4960 (09/2007) 

M3UA – MTP3 User Adaptation IETF RFC 4666 (09/06) 

M2PA - MTP2 User Peer-to-Peer Adaptation Layer IETF RFC 4165 (05/09) 

M2UA - MTP2 User Adaptation* 

- 

SUA - SCCP User Adaptation* - 

*available upon customer request 

2.4.3 Radio Network Protocols 

The following Radio Access Network (RAN) protocols are available: 


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)





NNI-SSCF – Network Node Interface Service 

Specific Coordination Protocol 

UNI- SAAL – User Network Interface Service 

Specific Coordination Protocol 

2.4.4 IMS Protocols 

The following IMS protocols are available: 

page 16/55 

© 2009 


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 

ITU: Q.2100, Q.2140 (02/95) 

ANSI: T1.645 (1995) 

TTC: JT-Q.2140 (04/95) 

ITU: Q.2100, Q.2140 (02/95) 

ANSI: T1.645 (1995) 

TTC: JT-Q.2140 (04/95) 

Protocol Name Standard Compliance Bearer support 

SIP RFC 3261, RFC3262 

RFC 2617 - HTTP Authentication 

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 

UDP, TCP and/or SCTP 

TLS, IPSec, SigComp*





page 17/55 

© 2009 


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 

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 


TLS, IPSec





SCTP – Stream Control 

Transmission Protocol 

page 18/55 

© 2009 


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 

IETF RFC 4460 (04/2006), RFC 

4960 (09/2007) 

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. 

SCTP – Stream Control 

Transmission Protocol 

IETF RFC 4460 (04/2006), RFC 

4960 (09/2007) 

IP 


TLS, IPSec 

IP





PCAP - Positioning Calculation 

Application Part 

LCSAP – Location Service 

Application Protocol 

2.5 Packaged Products 

page 19/55 

© 2009 


3GPP TS 25.453 V7.12.0 SCTP 

3GPP TS 29.171 V9.1.0 SCTP 

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





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 






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

Card is mounted in the chassis slots as signaling server blades; refer to chapter 2.5.1 for description of SoaC 

features. 

2.5.3 Signaling for Linux 

page 21/55 

SiaB 1U chassis 

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 

© 2009 






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. 


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: 



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: 



PCI Express 

PMC 

page 22/55 

© 2009 






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 


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 






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 






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 






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. 

page 26/55 

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. 

© 2009 






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 






page 28/55 

© 2009 


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 3 rd 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 29/55 

© 2009 


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)





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 






page 31/55 

© 2009 


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)





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 






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 






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. 

page 34/55 

© 2009 


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.





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 

page 35/55 

© 2009 


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.





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 






page 37/55 

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. 


© 2009 






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. 

page 38/55 

© 2009 


SIP-UC gateway interfaces.





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 

3 rd 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 

3 rd party call control 

Playing and recording of announcements 

Media protocols: 

H.248 for controlling MGW 

page 39/55 

© 2009 






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 






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 






4.3.1.1.2 Media Gateway (MGW) 

The MGW function is sourced through 3 rd 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. 

page 42/55 

© 2009 


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.





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 3 rd Party Call Control Telephony Interface (CTI) 

Using the 3 rd 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 






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. 

5.1 Signaling Manager (GUI/CLI) 

page 44/55 

© 2009 


High level overview of the common tools 

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.





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. 

page 45/55 

© 2009 


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.





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 

page 46/55 

© 2009 


Alarm Tab Overview





page 47/55 

© 2009 


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





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. 

5.3 SNMP 

page 48/55 

© 2009 


TvTool snapshot. 

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,





with one sub agent being run on each Signaling host. Any external SNMP Manager only connects to the 3SM 

agent. 

page 49/55 

© 2009 


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 50/55 

© 2009 


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 51/55 

© 2009 


Alarm GUI Viewer 

The SNMP agent is implemented in Java and as a standalone application.





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 






7 Contacts 

Please do not hesitate to contact us if you have any questions. We will be happy to assist you. 

E-mail: signaling@tieto.com 

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 






8 Acronyms and abbreviations 

ANSI American National Standards Institute 

ANSI-41 ANSI standard 41 (Previously known as IS-41) 

API Application Programming Interface 

ATM Asynchronous Transfer Mode 

AXE Ericsson switching platform 

BICC Bearer Independent Call Control 

BSC Base Station Controller 

BSSAP Base Station System Application Part 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CAP CAMEL Application Part 

CDMA Code Division Multiple Access 

cPCI CompactPCI 

CPU Central Processing Unit 

CS1 Capability Set 1 

ETSI European Telecom Standards Institute 

FPGA Field Programmable Grid Array 

GSM Global System for Mobile communications 

GUI Graphical User Interface 

HA High Availability 

HLR Home Location Register 

IETF Internet Engineering Task Force 

IN Intelligent Network 

INAP Intelligent Network Application Protocol 

IP Internet Protocol 

ISR In System Reconfigurable (hardware) 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

ITU International Telecommunications Union 

M3UA MTP-L3 User Adaptation Layer 

MAP Mobil Application Part 

Mbps Megabit per second 

MGCP Media Gateway Control Protocol 

MSC Mobile Services Switching Centre 

MTP Message Transfer Part 

PCI Peripheral Component Interconnect 

PMC PCI Mezzanine Card 

PSTN Public Switched Telephone Network 

SCCP Signaling Connection Control Part 

SCP Service Control Point 

SCTP Stream Control Transport Protocol 

SIGTRAN Signaling Transport 

SIP Session Initiation Protocol 

SMS Short Message Service 

SMSC Short Message Service Centre 

TCAP Transaction Capabilities Application Part 

TDMA Time Division Multiple Access 

TTC Telecommunications Technology Committee 

(Japanese standardisation body) 

page 54/55 

© 2009 






UMTS Universal Mobile Telecommunications System 

VoIP Voice over IP 

page 55/55 

© 2009

Signaling Solution Description - Tieto

Create successful ePaper yourself

Delete template?

Save as template?