signaling solution description

Signaling Solution Description

Telecom & Media, TGT Telecom MAM 100 1000-105/101 V1.0Signaling Products & Solutions PublicAnders G Karlsson October 3rd 2012

page 1/55

© 2009Tieto Corporation signaling solution overview v1 0.docx


Overview



page 2/55


Copyright

Copyright © 2012 Tieto Sweden AB.

Disclaimer

The contents of this document are subject to revision without notice, due to continued progress inmethodology, design and manufacturing.

Tieto shall have no liability for any errors or damages of any kind resulting from the use of this document.

Trademark List

Tieto™ is a trademark of Tieto Corporation in the United States and other countries.

Product Information

Document Number: MAM 100 1000-105/101

Revision: V.1.0

Date: October 3rd 2012

Validity

Please note that this document is subject to change without notice. This document includes details on bothbasic 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 3/55


Table of Contents

1 Scope of Document ........................................................................................................................................ 51.1 Signaling Solutions Overview ...................................................................................................................... 5

2 Signaling Stacks & Protocols ......................................................................................................................... 72.1 Horizontal Distribution ................................................................................................................................. 72.2 Application Programming Interface - API ................................................................................................... 10

2.2.1 C/C++ Programming Interfaces ....................................................................................................... 102.2.2 Java Programming interfaces .......................................................................................................... 11

2.3 Portable Architecture ................................................................................................................................ 122.4 Supported Signaling Protocols .................................................................................................................. 13

2.4.1 SS7 protocols .................................................................................................................................. 132.4.2 SIGTRAN protocols ......................................................................................................................... 152.4.3 Radio Network Protocols ................................................................................................................. 152.4.4 IMS Protocols .................................................................................................................................. 162.4.5 LTE protocols .................................................................................................................................. 18

2.5 Packaged Products ................................................................................................................................... 192.5.1 Stack-on-a-Card (SoaC) .................................................................................................................. 202.5.2 Stack-in-a-Box (SiaB) ...................................................................................................................... 212.5.3 Signaling for Linux ........................................................................................................................... 212.5.4 Signaling for Solaris® SPARC ......................................................................................................... 222.5.5 Signaling for Solaris® x86 ............................................................................................................... 222.5.6 Signaling for IBM AIX POWER ........................................................................................................ 232.5.7 Signaling for AdvancedTCA ............................................................................................................. 232.5.8 Communication Controllers.............................................................................................................. 232.5.9 Available types of package licenses ................................................................................................. 24

3 Application Enablers..................................................................................................................................... 253.1 Device Detection Application (DDA) .......................................................................................................... 25

3.1.1 Application Programming Interface .................................................................................................. 273.2 SMS Component ...................................................................................................................................... 27

3.2.1 Application Programming Interface .................................................................................................. 283.3 SS7 Monitor .............................................................................................................................................. 28

3.3.1 Application Programming Interface .................................................................................................. 293.4 SIP B2BUA Component ............................................................................................................................ 29

3.4.1 Application Programming Interface .................................................................................................. 303.5 Diameter Signaling Controller ................................................................................................................... 30

3.5.1 Application Programming Interface .................................................................................................. 33

4 Tieto Gateway Platform ................................................................................................................................ 344.1 Protocol Gateways .................................................................................................................................... 35

4.1.1 Signaling Gateway (SGW) ............................................................................................................... 354.2 Legacy Voice Gateways............................................................................................................................ 36

4.2.1 ISDN/PRI - ISUP Gateway (IGW-P) ................................................................................................. 364.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 ........................... 445.1 Signaling Manager (GUI/CLI) .................................................................................................................... 44



page 4/55


5.2 TvTool – Trace Viewer Tool ...................................................................................................................... 475.3 SNMP ....................................................................................................................................................... 485.4 Alarm GUI Viewer ..................................................................................................................................... 50

6 Professional Services ................................................................................................................................... 526.1 Installation ................................................................................................................................................ 526.2 Training .................................................................................................................................................... 526.3 Expert Consulting ..................................................................................................................................... 526.4 Maintenance & Support ............................................................................................................................ 52

7 Contacts ........................................................................................................................................................ 53

8 Acronyms and abbreviations ....................................................................................................................... 54



page 5/55


1 Scope of DocumentThe purpose of this document is to provide a technical overview of Tieto Signaling Solutions and Products onopen platforms. It also provides an overview of signaling network evolution and technologies in relation to TietoSignaling Product offerings.

1.1 Signaling Solutions OverviewTieto Signaling Solutions supplies signaling products in several areas, ranging from pure protocol stacks tocomplete network nodes, delivered as black box solutions with hardware, software, documentation and supportin accordance with the SLA. Due to the modular architecture, new products may easily be developed anddelivered with short Time-To-Market. All software may run on a variety of hardware platforms and interfaceboards. Depending on customer requirements, hardware can be provided by Tieto and shipped world-widefrom our logistics centre.

Tieto Signaling product survey

Products are provided within three main areas;

Signaling Protocol Stacks, refer to chapter 2. Application Enablers, refer to chapter 3. Gateways, refer to chapter 4.

All product areas are built upon modular software architecture, including common tools for operation andmaintenance. The common operation and maintenance tools are described in chapter 5.



page 6/55


High availability middleware is necessary when providing world class Carrier Grade products. The chosencomponents for this vary among the different products areas and are sometimes in-house developed products,3rd party sourced products, open source products or combinations thereof. The HW middleware used for eachproduct is described within each product area.

A wide range of hardware components are supported within the modularized hardware platform. The platformis used within the different product areas. Through a well-built eco-system of both products developed in-house and by 3rd party suppliers, Tieto is able to support leading hardware technologies.

Supported hardware is described within each product area.



page 7/55


2 Signaling Stacks & ProtocolsTieto Signaling Stacks is a complete range of signaling products and services. The product line is an importantcomponent for equipment manufacturers, software houses, system integrators, computer vendors and networkoperators 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 and4G IMS and LTE networks. With more than 25,000 installations worldwide, Tieto is a leading supplier ofsignaling 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 Detectionsolutions, 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 asSIGTRAN, 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. Inaddition, 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 ofcustomer solutions and, together with the operation and maintenance tools provided, minimize the amount ofintegration work required.

Tieto supports most major open operating systems & platforms as off-the-shelf products, refer to chapter 2.5.

2.1 Horizontal DistributionHorizontal Distribution (HD) is a deployment architecture that provides the option of deploying multiplesignaling servers all sharing the same network appearance e.g. signaling point code. With HD, Tieto is able tooffer systems with:

Extreme Performance – Performance is scaled linearly using multiple servers in a system. It is furtherscalable 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 distributedover 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 theapplication(s) always maintain(s) contact with the network via alternative servers. The signaling traffic is loadshared between available signaling servers.

The complete HD architecture acts as a single node in the operator network architecture, thus simplifyingnetwork configuration and deployment.



page 8/55


Signaling Horizontal Distribution Architecture

The Application Host(s) is a/are server(s) that host the customer application(s) that integrate the providedsignaling APIs and management tools for interaction with the HD Signaling Subsystem. The HD Signaling Systemimplements the signaling protocol stacks and architectural support software to assure high availability and simplifyoperation and maintenance.

The Signaling Protocol APIs are fully distributed and allow several different applications, in several differentapplication CPUs, to access the signaling subsystem. Load sharing can be applied on both outgoing andincoming signaling traffic. All communication between the signaling API and the signaling protocol stackimplementation is hidden from the application user by the provided signaling middleware, Common Parts, whichuses IP as the bearer for messages between the applications and signaling subsystem.



page 9/55


The Signaling protocol APIs are provided for C, C++ and Java application development. Different programminglanguages may be mixed within the same signaling solution, having Java implementations running side by sidewith C implementations. As an option, High Level APIs are available which hide the under-lying distributedarchitecture of HD for application developers. All protocol APIs work in a similar ways for the chosen programminglanguage, 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, easingthe integration and reducing time-to-market. Signaling Manager, an easy-to-use GUI and CLI is provided for theconfiguration and control of the signaling subsystem. The Signaling Manager may also be loaded as an appletinto a standard web browser such as Windows Explorer, Firefox, etc. Log daemons are provided for printingdebug and signaling trace information to log files. The generated log files can be loaded into the provided LogViewer, TvTool, where it is presented with signaling flows and in a human readable format. Finally, an SNMPAgent is included for the generation of SNMP Traps in the event of failures within the signaling subsystem. Formore details on the tools provided, refer to chapter 5.

Operation and management APIs are provided for easy integration of customer applications with proprietarymanagement solutions. The API’s management application can control the system, monitor alarms and retrievestatistics from the signaling subsystem. The OAM APIs can be used together with the tools provided to createcustomer-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/M3UAand above (e.g. SCCP, TCAP, MAP, etc.). Back End Process serves as a signaling message router for protocoluser data between the Signaling Protocol APIs used by customer applications and the different supportedbearers, i.e. Signaling Front Ends. The signaling subsystem supports multiple Back Ends, which may bedistributed over several servers, as well as co-located on the same server. The Back Ends interact with SS7 FrontEnd Processes.

SS7 Front End Process (SS7 FEP) – The SS7 Front End processes come in different flavours depending on thelow 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. SS7over IP) traffic. It may also be used as a bearer for SIP and Diameter traffic. SCTP uses standard Ethernetinterfaces for IP connectivity.

MTPL2 Front End implements support for traditional MTPL2 narrowband signaling over E1/T1/J1 telecominterfaces. It also supports High Speed Signaling broadband links that are compliant with G.703. It requiresspecific communication controller boards for E1/T1/J1 terminations2.5.8 for available supported boards andform factors (e.g. PCI Express, PMC, etc.)

NNI-SAAL Front End implements support for signaling over ATM, i.e. SSCOP over AAL5. It requires specificcommunication controller boards for the E1/T1/J1 terminations. Refer to chapter 2.5.8 for available boardsand form factors (e.g. PCI Express, PMC, etc.).

M2PA Front End implements support for MTPL2 signaling over SCTP. M2PA replaces the MTPL1 E1/T1/J1termination with standard Ethernet interfaces for IP connectivity to achieve higher performance and simplifythe low level transmission architecture.



page 10/55


Diameter Front End Process (DIA FEP) - The Diameter Front End Processes implement support for the Diameterprotocol. The Diameter protocol uses standard Ethernet interfaces for connectivity. It may use TCP, UDP or SCTPas 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. TheSIP protocol uses standard Ethernet interfaces for connectivity. It may use TCP, UDP or SCTP as a bearer (SCTPFront End). Security options, such as TLS and IPSec, are supported.

Network Management Process (NMP) – The Network Management Process implements the common signalingnetwork 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 asone 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 andensure high availability and successful recovery upon failures in the signaling subsystem. Each Execution Controlinstance has the role as a Master (ECM) or Slave (ECS). In case of failure of the Master, any one of the Slavesmay 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 accesspoint for external management and control of the subsystem. It is accessed through the OAM API for customer-developed applications and the Signaling Manager GUI/CLI. It serves as a router of management requests anddirect messages to the appropriate receiver within the subsystem. Through the OAM interface, a user of thesubsystem 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 controllersis 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 thechosen server hardware supplier. These may either be fixed interfaces at the server hardware or mounted inavailable expansion slots.

2.2 Application Programming Interface - APIThe signaling products are designed to make it easy to build a system that utilizes the underlying signalingprotocols. 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 providedmiddleware Common Parts. The actual communication implementation is transparent to the applicationprogrammer. For most supported platforms, the majority of middleware communication is based on usingInternet sockets over TCP. Several application instances can simultaneously connect to a specific signalingprotocol and multiple protocols may be used from the same protocol instance.

2.2.1 C/C++ Programming InterfacesFor applications developed in C/C++, developers access the signaling protocols by using function calls througha well-defined Application Programming Interface (API).

Each signaling protocol layer has its own API, containing functions and call-back definitions for all protocolprimitives and system functions. Requests/Confirmations are sent to the stack by calling predefined functionswhich encode provided structures with parameter data and transport it via the middleware to the appropriate



page 11/55


receiver in the signaling subsystem. Reception of messages and events is done using call-back functionswhere the function prototype is defined by the API and customer application developer completes the codeaccording to their need.

Before the application may send or receive messages, the middleware is initiated and inter-processcommunication (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 servereach process executes, are managed by the middleware, which allows applications to dynamically add and/orremove signaling subsystem processes without taking down the complete system.

Several application instances can simultaneously connect to a specific signaling protocol, and multipleprotocols may be used from the same protocol instance. As an option, High Level APIs are available, whichhide the underlying distributed architecture of HD for application developers even further by also managing thedistribution and load sharing of traffic over available Back Ends.

Signaling API architecture

All APIs are thread-safe and support numerous different operating systems, refer to chapter 2.5 for availableoff-the-shelf products.

2.2.2 Java Programming interfacesThe Java Standard Edition (J2SE) APIs provide the interfaces and classes required to connect to and receiveprimitives from signaling protocols within the signaling subsystem. The APIs contain functionality to parse andextract information from the received primitives.

The application Java program uses the API to connect to one or more instances of signaling subsystemprocesses through sockets. The Provider class handles the connection to the signaling subsystem and is usedfor sending/receiving events to/from the signaling subsystem.



page 12/55


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 aresubclasses of the java.util.EventObject class.

Each primitive has its own method with a specific set of parameters implemented as member variables in thecorresponding event classes used when encoding/decoding messages.

2.3 Portable ArchitectureAll components of the signaling subsystem are easy to adapt to nearly any type of customer-specifichardware/software platform. This is made possible by the highly modular and portable software architecture.

Portable Signaling Architecture

The main principle of the signaling architecture is to distil all platform dependent interfaces to a set of commonfunctions.

The OS Interface Middleware distils all OS service functions required by a signaling protocol layer. This makesthe signaling protocol layer software platform independent, and the same source code can be used on allplatforms.

The Lower Interface is the integration point for any software module or hardware module that providessignaling services to the specific protocol layer. In many cases, the lower interface is directly connected to oneof 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 itsown accompanying API, allowing the user to get easy access from their application.



page 13/55


There is a common Management Interface used by all protocol layers within the signaling subsystem thatinterface with the Operation and Maintenance process used for external management access. This enableseasier adaptation to different management solutions as the management of each protocol layer follows thesame architecture and principles provided by the internal management interface.

2.4 Supported Signaling ProtocolsThe sub-chapters below give an overview of signaling protocols currently available in the Tieto Signalingproducts range. New protocols are added on regular basis and incorporated into the portfolio.

2.4.1 SS7 protocolsThe following SS7 protocols and major standards are currently supported. Additional standard support isadded on regular basis. For details of latest supported versions, please refer to the product sheet for eachprotocol.

Protocol Name Standard ComplianceMTPL1 – Message Transfer Part Layer 1

AAL-5 – ATM Adaptation Layer 5

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

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

ANSI: T1.111

TTC: JT-Q.703, NTT-Q.703

MTPL3 - Message Transfer Part Layer 3 ETSI: ETSI 300 008-1, (01/97), ETSI EN 301 004-1, V1.1.3(02/98)

ITU-T: Q.701 (03/93), Q.704 (07/96), Q.705 (03/93), Q.707(11/88), Q.752 (06/97), Q.2210 (07/96)

ANSI: T1.111.4-1996, T1.115-1990

China: GF 001 9001, (08/90), GF 001 9001 Supplement 1 –3 (10/91)

TTC: JT-Q701 (version 2, 11/90), JT-Q704 (version 3,04/92), JT-Q707 (version 2, 11/90), JT-Q2210 (version 1,04/96)

SCCP - Signaling Connection ControlPart

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


ETSI: ETS 300 287-1 (11/96)

TTC: JT-Q.771–JT-Q.774 (1997)

China: P.R.C., 1994.10

ANSI: T1.114-1996, T1.115-1990

MAP – Mobile Application Part ETSI: GSM 09.02 (V3.11.0, 04/95), GSM 09.02 (V5.3.0,08/96), 3G TS 29.002 (V7.4.0, 06/2006), 3G TS 29.002(V6.10.0, 06/2005)

ANSI: ANSI-41.1-D, (12/97), ANSI -41.3-D, (12/97), ANSI -41.5-D, (12/97), ANSI -41.6-D, (12/97), TR-45, IS-725-A(PN-4173), TIA/EIA-41-D, (03/99), TR-45, IS-751 (PN-3892), TIA/EIA-41-D (V7), TR-45, J-STD-036: EnhancedWireless 9-1-1 Phase 2, (07/00), TR-45, IS-730, IS-136(DCCH) Support in IS-41, (07/97), TR-45, IS-771, WINTIA/EIA-41-C modifications, (07/99), TR-45, IS-764 (PN-4103), (06/98), TR-45, IS-826 (PN-4287), (05/00), IS-841Based Network Enhancements for MDN Based MessageCentres, TDMA Forum, Interim Over-the-Air-Activationspecification, (12/96), V1.1, TIA/EIA IS-848 (10/00)

Ericsson MAP (EMAP): GSM 03.03, 03.32, 09.02 (version6.1.0, 08/98), GSM 03.38, 03.40 (version 3.5.0), GSM04.11, 04.08, ITU-T Q.771–Q.775 (06/97), ITU-T X.208–X.209 (1988)

INAP - Intelligent Network ApplicationProtocol

ETSI/ITU: ETS 300 374-1 (09/94), ETS 300 403-1 ITU-TQ.931 (1993), ETS 300 356-1, EN 301 140-1 INAP Ca-pability 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.0Release 1998, 3GPP TS 29.078 V4.8.0 (2003-03)

BSSAP – Base Station SystemApplication Part

ANSI: T1.111-T1.112, 1996

ETSI: 3GPP TS 49.031 V7.6.0 (2008-03), 3GPP TS 48.071V7.2.0 (2007-06), 3GPP TS 48.008 (MSC-BSS) InterfaceLayer 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),



page 15/55


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 300356-17, ETS 300 356-20, 1998, ETS 300 356-31 – ETS300 356-36 1998

TTC: JT-Q.762 – Q.764 (09/99)

+ many national variants of ISUP

SSCOP – Service Specific ConnectionControl Protocol

ITU: Q.2100, Q.2140(02/95), Q.2130(07/94), Q.2110(07/94)

ANSI: T1.645 (1995), T1.637 (1994), T1.652 (1996)

TTC: JT-Q.2140 (04/95), JT-Q.2130 (07/94), JT-Q.2110(02/96), JT-Q.2144

NNI-SSCF – Network Node InterfaceService Specific Coordination Protocol

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

ANSI: T1.645 (1995)

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

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

Protocol Name Standard ComplianceSCTP – 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 ProtocolsThe following Radio Access Network (RAN) protocols are available:

Protocol Name Standard ComplianceRANAP 3GPP Release 99

NBAP 3GPP Release 99

ALCAP 3GPP Release 99

RLC 3GPP Release 99

SSCOP – Service Specific Connection ControlProtocol

ITU: Q.2100, Q.2140(02/95), Q.2130(07/94),Q.2110 (07/94)



page 16/55


ANSI: T1.645 (1995), T1.637 (1994), T1.652 (1996)

TTC: JT-Q.2140 (04/95), JT-Q.2130 (07/94), JT-Q.2110 (02/96), JT-Q.2144

NNI-SSCF – Network Node Interface ServiceSpecific Coordination Protocol

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

ANSI: T1.645 (1995)

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

UNI- SAAL – User Network Interface ServiceSpecific Coordination Protocol

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

ANSI: T1.645 (1995)

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

2.4.4 IMS ProtocolsThe following IMS protocols are available:

Protocol Name Standard Compliance Bearer supportSIP RFC 3261, RFC3262

RFC 2617 - HTTP Authentication

RFC 2976 - SIP INFO Method

RFC 3262 - SIP PRACK Method

RFC 3265 - SIPSUBSCRIBE/NOTIFY methods

RFC 3310 - HTTP DigestAuthentication

RFC 3311 - SIP UPDATE method

RFC 3313 - Extensions for MediaAuthorisation

RFC 3323 - Privacy Mechanism

RFC 3324 - Network AssertedIdentity

RFC 3325 - Asserted Identity inTrusted Networks

RFC 3326 - Reason Header field

RFC 3327 - Extension Headerfield

RFC 3329 - Security MechanismAgreement

UDP, TCP and/or SCTP

TLS, IPSec, SigComp*



page 17/55


RFC 3372 - SIP-T

RFC 3398 - ISUP-SIP Mapping

RFC 3428 - SIP MESSAGEMethod RFC 3455 - PrivateHeader for 3GPP

RFC 3515 - SIP REFER Method

RFC 3578 - Mapping ISUPOverlap Signaling to SIP

RFC 3608 - Extension Headerfield for Service Route Discovery

RFC 3725 - 3pcc in SIP

RFC 3841 - Caller Preferences

RFC 3892 - Referred-ByMechanism

RFC 3903 - SIP PUBLISH Method

RFC 3911 - “Join” Header

RFC 4028 - Session Timers

RFC 4117 - Transcoding ServicesInvocation using 3pcc

RFC 4244 - Extension for RequestHistory Header Information

RFC 4457 - P-User-DatabasePrivate Header

Diameter IETF RFC 3588, Diameter Base

IETF RFC 3539, AAA TransportProfile

IETF RFC 4006, Diameter Credit-Control App.

IETF RFC 4005, AAA AccessServer App.

IETF RFC 4072, Extensible Auth.Protocol App.

IETF RFC 4740, Diameter SIPApp.

IETF RFC 5447, NAS to DiameterInteraction

3GPP TS 29.109, Zh & Zn


TLS, IPSec



page 18/55


Interfaces

3GPP TS 29.140, MM10 Interface3GPP TS 29.172, SLg Interface

3GPP TS 29.173, SLh Interface

3GPP TS 32.225, Ro & RfInterface

3GPP TS 29.228, Cx & DxInterface

3GPP TS 29.229, Cx & DxInterface

3GPP TS 29.272, S13 & S13’Interface

3GPP TS 29.272, S6a & S6dInterface

3GPP TS 29.213 S9 Interface

3GPP TS 29.328, Sh & DhInterface

3GPP TS 29.329, Sh & DhInterface

3GPP TS.32.251, Gy Interface

3GPP TS.29.212, Gx Interface

SCTP – Stream ControlTransmission Protocol

IETF RFC 4460 (04/2006), RFC4960 (09/2007)

IP

H.248 MEGACO* - -

*available upon customer request

2.4.5 LTE protocolsThe following LTE Protocols are available:

Protocol Name Standard Compliance Bearer supportDiameter Diameter Base acc. to IETF RFC

3588. In addition, various IETFand 3GPP interface and standardadditions are also supported.


TLS, IPSec

SCTP – Stream ControlTransmission Protocol

IETF RFC 4460 (04/2006), RFC4960 (09/2007)

IP



page 19/55


PCAP - Positioning CalculationApplication Part

3GPP TS 25.453 V7.12.0 SCTP

LCSAP – Location ServiceApplication Protocol

3GPP TS 29.171 V9.1.0 SCTP

2.5 Packaged ProductsTieto provides signaling protocol packages as off-the-shelf products for various operating systems and HWarchitectures.

Depending on customer requirements, Tieto provides hardware - ranging from communication controllers forE1/T1 termination to complete Stack-in-a-Box (SiaB) solutions. SiaB solutions include chassis, server bladesmounted in chassis (Stack-on-a-Card - SoaC) and communication controllers for signaling interfaces (E1/T1/J1and/or Ethernet RJ-45).

Common features for all packaged products are:

Concurrent support for SS7, SIGTRAN, IMS and LTE protocols IMS and LTE protocols can execute simultaneously with SS7 protocols in the same signaling subsystem

and be accessed from the same customer application

Horizontal Distribution Architecture High capacity Scalability Redundancy

Mixed interface support SIGTRAN, MTPL2 E1/T1/J1 and High Speed Signaling Links (G.703 and AAL5) in one product

Full standard support within the same delivery Configurable options to run as ANSI, ITU, TTC or Chinese Mixed standards; ANSI on top of ITU, ITU on top of ANSI, etc.

Distributed and thread-safe APIs for C/C++ and Java Applications may be co-located on the same servers as the signaling subsystem

or be distributed over a different set of servers

Mixed operating system environment Applications may run under a different operating system than the signaling subsystem Applications may run under different operating system while accessing the same signaling subsystem,

e.g. Windows applications may co-exist with Linux applications

Common Tools for Operation and Maintenance Signaling Manager GUI and CLI tool for configuration and control TvTool Logviewer for interpreting signaling traces and debug info SNMP Agent for monitoring

Supplied with warranty, support and maintenance in accordance with defined SLAs. Phone and email support by signaling help desk



page 20/55


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 whoare 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 closedenvironment 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 21/55


The latest generation of Stack-on-a-Card, equippedwith 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 newtelecom nodes.

The main benefit of the Stack-in-a-Box product is that all signaling protocol software executes in a closedenvironment and does not affect the customer’s application environment and/or platform, and vice versa. Thismeans that signaling capacity and availability can be guaranteed. SiaB solutions are offered using 1U up to 4Uchassis 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 SoaCfeatures.

SiaB 1U chassis

2.5.3 Signaling for LinuxSignaling for Linux is a server-based signaling solution for Linux systems, consisting of software with optionalhardware communication controller interface boards for telecom interfaces (E1/T1/J1) to be mounted in theLinux servers.

It is designed for system integrators, application developers and network operators implementing SS7, SIP orDiameter connectivity in a Linux server environment. It supports all major hardware vendors using Intelarchitecture for single and multi-core CPUs. This includes, but is not limited to HP, Dell, IBM BladeCenter, etc.


Ability to execute in virtualised environments, such as: VMware ESX 4.0



page 22/55


RedHat Virtualisation 6.1

Supported operating system for the signaling subsystem and application hosts are: RedHat Enterprise Linux 5 and 6 SUSE 11 MontaVista CGE 5

Additional application host-only support for various operating systems. Sun Solaris® 9 +10 HP-UX®11i Microsoft® Windows® Server AIX 7

Support for several form factors for communication controller interface boards PCI Express PMC PCI

2.5.4 Signaling for Solaris® SPARCSignaling for Solaris SPARC is a server-based signaling solution for Solaris SPARC architectures, consistingof software with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1)to be mounted in Solaris SPARC servers.

It is designed for system integrators, application developers and network operators implementing SS7, SIP orDiameter connectivity in a SPARC server environment.


Supported operating system for the signaling subsystem and application hosts is: Sun Solaris® 9 +10

Support for several form factors for communication controller interface boards PCI Express PMC PCI

2.5.5 Signaling for Solaris® x86Signaling for Solaris x86 is a server-based signaling solution for Solaris Intel architectures, consisting ofsoftware with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) tobe mounted in Solaris Intel servers.

It is designed for system integrators, application developers and network operators implementing SS7, SIP orDiameter connectivity in a Solaris server environment.


Supported operating system for the signaling subsystem and application hosts is: Sun Solaris® 9 +10

Support for several form factors for communication controller interface boards PCI Express PMC



page 23/55


PCI

2.5.6 Signaling for IBM AIX POWERSignaling for IBM AIX POWER 7 architecture is a server-based signaling solution for IBM POWERarchitectures, consisting of software with optional hardware communication controller interface boards fortelecom interfaces (E1/T1/J1) to be mounted in the servers.

It is designed for system integrators, application developers and network operators implementing SS7, SIP orDiameter connectivity in a Solaris server environment.

Supported operating systems for the signaling subsystem and application hosts are: AIX 7 SUSE 11 MontaVista CGE 5 Sun Solaris® 9 +10 HP-UX®11i Microsoft® Windows® Server

2.5.7 Signaling for AdvancedTCASignaling for AdvancedTCA architecture is a server-based signaling solution for ATCA architectures, softwarewith optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to bemounted in servers. The solution is integrated by Tieto on the ATCA blades chosen by the customer in acustomized solution.

2.5.8 Communication ControllersTieto provides a full set of Signaling Communication Controllers for various form factors and systemarchitectures used as part of our signaling protocol products. This chapter gives a brief overview of availablecontrollers.

2.5.8.1 ISR – PCIeThe Tieto ISR-PCIe low profile communication controller for PCI Express bus is a high-density controller forSS7 signaling. It provides complete on-board Message Transfer Part Layer 2 protocol support with E1, T1 andJ1 network interfaces. It supports four E1/T1/J1 ports with up to 64 x 64kbps LSL or up to 4 x HSSL 1.5/2Mbit/s ATM.

2.5.8.2 ISR – PMCThe Tieto ISR-PMC (PCI Mezzanine Card) communication controller for PCI bus is a high-density controller forSS7 signaling. It provides complete on-board Message Transfer Part Layer 2 protocol support with E1, T1 andJ1 network interfaces. It supports four E1/T1/J1 ports with up to 64 x 64kbps LSL or up to 4 x HSSL 1.5/2Mbit/s ATM up to 4 x HSL ITU-T Q.703, Annex A.

2.5.8.3 ISR-PMC / PCI AdapterThe Tieto ISR-PMC (PCI Mezzanine Card) with PCI Adapter communication controller for PCI bus is a high-density controller for SS7 signaling. Mounting the ISR-PMC board on the PCI adapter ensures that only legacyservers with PCI bus are supported; refer to chapter 2.5.8.2 for a description of the PMC board. The adapteralso provides support for HSL ITU-T Q.703, Annex A, on PCI architecture.



page 24/55


2.5.8.4 ISR-PMC / PCI Express AdapterThe Tieto ISR-PMC (PCI Mezzanine Card) with PCI Adapter communication controller for PCI Express bus isa high-density controller for SS7 signaling. Mounting the ISR-PMC board on a PCI Express adapter providessupport 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 ControllerThe HDC3 provides industry-leading SS7/ATM performance and capacity for Next Generation and IMSnetworks. Designed to exceed your system requirements, the HDC3 provides superior scalability, flexibility andprice 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 percard 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 licensesThe signaling products are packaged for rapid installation, configuration, application development, deploymentand extensions.

The following packages are available:

Run-time package - For use in live networks. Includes license for usage, basic capacity licensing devicedriver, 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, devicedrivers, developers guide, API specification, statement of compliance, configuration guide and installationguide.

Extension packages - Additional licenses for capacity expansion.



page 25/55


3 Application EnablersThe Application Enabler product family is a set of add-on products that are designed to hide the complexity ofsignaling networks and protocols from the user applications and thereby significantly reduce Time-To-Marketand development costs. They are high-level applications on top of the Signaling Protocol stacks and multipleapplications can be combined within the same platform. Depending on the enabler usage some come with highlevel APIs for integration with customer applications while others are complete black-box solutions with well-defined standard interfaces.

Tieto provides Application Enablers in the areas of:

Automatic Device Management and Authorization – The Device Detection Application (DDA) providesinterfaces 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 SMStransport and reception over SS7; refer to chapter 3.2.

Network Monitoring - The SS7 Monitor provides non-intrusive monitoring of signaling traffic and filtermechanism 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 SIPimplementations by providing header manipulation and service routing, e.g. forking of calls, routing to differentSIP servers, location of voice mail boxes, etc. It can also be the base for developing various applicationservices 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 networkconfiguration complexity, cuts integration costs, increases scalability and provides topology hiding of operatornetworks. The Diameter Signaling Controller supports the Diameter Router Agent (DRA), as defined by3GPP; 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 signalingsubsystem. The Signaling Manager may also be loaded as an applet into a standard web browser such asWindows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace informationto log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presentedwith signaling flows and a human readable format. Finally, a SNMP Agent is included for generation of SNMPTraps in the event of failures within the signaling subsystem. For more details on the provided tools, refer tochapter 5.

3.1 Device Detection Application (DDA)The Device Detection Application (DDA) Enabler provides support for the development of device managementapplications that rely upon signaling network-based detection of new devices, or to implement Advice ofCharge or Welcome SMS solutions that rely upon network-based device detection. It may also act inauthorization mode and, as such, serve as a high level interface for equipment registers. The DDA detectswhen a handset enters the network, allowing it to be automatically configured by the device managementapplication using normal over-the-air-activation mechanisms such as SMS or USSD.



page 26/55


The DDA receives MAP CheckIMEI message over the SS7 network from the MSC and/or SGSN containingthe IMSI and IMEI combination. The MSC issues the MAP messages at IMSI attach (Phone Power On) or atlocation update (a mobile device is moving in the network). The DDA converts the MAP CheckIMEI messageinto 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 throughconfiguration.

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 over-the-air-activation with SMS MAP. This can be done either by using an external SMSC interface, the SS7 MAPAPI 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 theequipment status for the phone, i.e. white, grey or black listed. Using authorization mode, customers mayrapidly develop an EIR without having to consider the complexity of SS7 protocols.

DDA interfaces

DDA is able to serve several PLMNs concurrently and support various deployment modes in operatornetworks, where operators may or may not already have EIRs in operation.



page 27/55


It is used together with the Signaling Protocol Stack and is managed through the Common Tools for operationand maintenance, refer to chapter 5.

3.1.1 Application Programming InterfaceDDA APIs and OAM APIs are available for C/++ and Java. The implementation follows the same principles asthe C/C++ and Java APIs for the signaling protocol stacks, refer to chapter 2.2.1 and 2.2.2.

3.2 SMS ComponentTieto 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 SMSfunctionality.

It is built using the same architecture as Tieto Signaling products and pre-integrated with Tieto signalingprotocol 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 Storeand Forward mode. Store and Forward mode also includes a database for persistent storage of shortmessages 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 asubmitter and receiver of short messages.

SGSN - The interface between SMS-C and SGSN, using the MAP protocol. SGSN can act both as asubmitter 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 thelocation of the mobile.

ESME - The interface between SMS-C and ESME, using the SMPP protocol. An ESME acts as a submitter ofshort messages.



page 28/55


SMS-C interfaces

The SMS Component is implemented as an application on top of the Tieto Signaling Stack and the ETSI MAPprotocol. It supports a full set of different SS7 bearers, such as SIGTRAN, MTP E1/T1 and HSL. For a generaldescription of the Signaling Stack, refer to chapter 2.

3.2.1 Application Programming InterfaceThe SMS Component offers SMPP protocol as the interface for applications. SMPP client library is not part ofthe delivery. Several 3rd party libraries are available on the market, either as open source or commercialversions, which can be used in customer applications. O&M APIs are available for Java. The implementationfollows the same principles as the Java APIs for the signaling protocol stacks, refer to chapter 2.2.2.

3.3 SS7 MonitorThe SS7 Monitor is an SS7 monitoring subsystem that can be used for non-intrusive monitoring of the SS7signaling traffic. The SS7 Monitor can also be used together with signaling stacks for applications requiringactive connections to the SS7 network. The SS7 monitor provides a configurable message filter, which allowsthe applications to select only the SS7 messages that are of interest. Messages that match the filter settingsare 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 samesystem solution and all accessible from the same application instance. Communication controllers with E1interfaces for connecting the tap equipment are mounted in standard PCI Express slots in standard Solaris orLinux servers.



page 29/55


SS7 Monitor interfaces

The non-intrusive communication controller supports up to 64 links per board and multiple boards can becombined to build larger monitor solutions.

The SS7 monitor re-uses common tools and O&M implementation from the Tieto Signaling stacks. This allowsthe SS7 Monitor to run in parallel with Signaling stack users, sharing one common O&M interface.

3.3.1 Application Programming InterfaceSignaling Monitor APIs and O&M APIs are available for Java. The implementation follows the same principlesas the Java APIs for the signaling protocol stacks; refer to chapter 2.2.2.

3.4 SIP B2BUA ComponentThe 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 ofvalue-added service solutions. It provides features such as SIP Header manipulation, call redirection androuting services for SIP-to-SIP calls. Using the SIP B2BUA component as the foundation for development ofnew features or interworking functions for increased user experience, costs can be cut and time-to-marketassured.

The implementation conforms to SIP according to RFC 3261 with a number of additions, including:

Reliable Responses PRACK (RFC 3262) P-Asserted Identity (IETF RFC 3428)



page 30/55


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 fordevelopment 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 theB2BUA to run in parallel with signaling stack users, sharing one common O&M interface. The SIP B2BUA isscalable, 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 variousenvironments supporting a JVM.

3.4.1 Application Programming InterfaceInclude O&M management Java 2SE API option for integration with 3rd party management systems. B2BUAAPI for service implementation is offered upon request.

3.5 Diameter Signaling ControllerTieto Diameter Signaling Controller provides a flexible, robust and secure solution for reduced overall signalingload, simplified network configuration scenarios at roll-out and upgrade as well as secure and efficient intra-network connectivity.

Through its flexible routing capabilities, i.e. acting as Diameter Proxy and/or Relay Agent between LTE/IMSnetwork elements, it reduces network configuration complexity, cuts integration costs, increases scalability andprovides topology hiding of operator networks. The Diameter Signaling Controller supports the DiameterRouter Agent (DRA) as defined by 3GPP.



page 31/55


Diameter Signaling Controller interfaces

The Tieto Diameter Signaling Controller is based on the company’s world-class signaling products and is built onthe same robust and carrier grade architecture as other Tieto Signaling solutions for applications such as thetraditional SS7 and SIP.The solution is built for industry standard Linux servers, such as IBM BladeCenter.

The following main features are supported:

May act as number of different nodes: Diameter Routing Agent (DRA) Diameter Edge Agent (DEA)



page 32/55


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)TCPIPv4 & IPv6TLS

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


The DSC reuses common tools and O&M implementation from Tieto signaling stacks. This allows the DSC torun in parallel with signaling stack users, sharing a single common O&M interface. The DSC is scalable with upto 10 running concurrently within the same signaling subsystem.

3.5.1 Application Programming InterfaceThe DSC is also able to act as a Diameter end node (server or client) with C/C++ and Java J2SE APIs forcustomer application integration.

For O&M there are Java 2SE API and C/C++ options for integration with 3rd party management systems.



page 34/55


4 Tieto Gateway PlatformWith its Gateway Platform offering, Tieto provides gateways to significantly shorten network integration leadtimes and reduce costs. Its complete set of components allows to not only provide off-the-shelf gateways butalso to provide customized solutions. The Gateway Platform is a hardware and software platform solution thatcan also be used for building signaling and/or media gateways. It affords fast and effective development ofcustomer-specific gateway solutions with carrier grade characteristics.

The short TTM and cost efficiency afforded by re-using the building blocks provides a financially favourableoption to use the result as either a “gap-filler” or a permanent solution. The product and its total lifecycle aremanaged by Tieto.

Tieto Gateway Platform components

Based on the Gateway Platform, the following gateways are available off-the-shelf:

Protocol gateways Legacy voice gateways Unified communication gateways

With the network evolution and convergence, the Gateway Platform is well suited to serve as the basis fordeveloping gateways to bridge the gap between the latest network technologies and existing legacy networks.



page 35/55


There are numerous areas where gateways may be necessary in order to provide seamless serviceinteraction, 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 signalingsubsystem. The signaling manager may also be loaded as an applet into a standard web browser such asWindows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace informationto log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presentedwith signaling flows and a human readable format. Finally, an SNMP Agent is included for the generation ofSNMP 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 betweenlegacy SS7 domains and SIGTRAN domains. The Tieto Signaling Gateway is a distributed solution based onthe Horizontal Distribution (HD) concept.

Tieto SGW provides a signaling solution containing both hardware and software, targeting the followingsituations:

Providing IP access to legacy SS7 nodes Providing legacy SS7 access for SIGTRAN-only nodes IP back-haul STP & SRP replacement

Signaling Gateway interfaces

This is an “all-in-one” Black Box solution built using carrier grade SW and HW components to ensure highavailability and scalability. The hardware used in the SGW is based on CompactPCI build set and consists ofthe 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 tolinear, the scaling factor being approx. 1.8 times/SGW Blade.



page 36/55


The Tieto SGW delivers exceptionally high in-service performance, reaching 99.999% availability when usingat 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) ArchitectureThe Signaling Gateway is built on the horizontal distribution (HD) SW architecture and is packaged as astandalone black box solution using Stack-on-a-Card and Stack-in-a-Box hardware, refer to chapter 2.5.1 and2.5.2. For a description of software architecture, refer to chapter 2.1.

4.1.1.2 Application Programming InterfaceO&M management C/C++ and Java 2SE API for integration with 3rd party management systems is availableupon request.

4.2 Legacy Voice GatewaysTieto Legacy Voice Gateways are a set of gateways that provide protocol interworking for legacy SS7networks 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 PRIaccesses (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 andSS7-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 PRID-channel signaling from B-channel data into separate timeslots sent over an E1/T1 or SIGTRAN interface tothe IGW-P for protocol conversion. After conversion, the protocol data is multiplexed back into the propertimeslots for forwarding to the ISDN equipment (e.g. PBX) and SS7 network node. Tone generation anddetection, 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 D-channels per E1, 24 D-channels per T1). The narrowband SS7 network access supports up to 4 E1/T1 PCMinterface 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 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. SignalingManager, 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 WindowsExplorer, 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 withsignaling flows and in a human readable format. Finally, an SNMP Agent is included to generate SNMP Trapsin the event of failures within the signaling subsystem. For more details about the tools provided, refer tochapter 5.

All software is packaged as RPM packages for easy installation and SW upgrade.

4.2.1.1 Application Programming Interface



page 38/55


The IGW-P is a black box solution. MIBs are provided for integration with SNMP Manager and GUI/CLI forcontrolling the system. O&M management C/C++ and Java 2SE API for integration with 3rd party managementsystems is available upon request.

4.3 Unified Communication GatewaysThe Unified Communication Gateways provide a complete system solution to allow interconnection betweenSIP-based enterprise network PBXs and operator networks. They can use either IMS network and/or legacySS7 network as the integration point. The UC gateways are compliant with Microsoft OCS R2 and LyncMediation Server for Unified Communications integration with operator networks and may easily be integratedwith 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 alsointegrate 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 betweenSIP Trunks and providing necessary security mechanism towards enterprise SIP Trunks, as well as protocoland 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 SIP-based enterprise network PBXs and operator networks. It can use IMS networks and/or legacy SS7/ISDNnetworks as the integration point. It is compliant with Microsoft OCS R2 and Lync Mediation Server for UnifiedCommunications integration with operator networks, but can also be integrated with various PBXs, providing aSIP Trunk and/or ISDN interface.

SIP-UC gateway interfaces.



page 39/55


Depending on network integration scenario, the SIP UC gateway may include several components. Theprinciple ones being:

Media Gateway Controller (MGC), refer to chapter 4.3.1.1.1 Media Getaway (MGW), refer to chapter 4.3.1.1.2 SIP Back 2 Back User Agent (B2BUA), refer to chapter 4.3.1.1.3 SIP Session Border Controller (SBC), refer to chapter 4.3.1.1.4 SIP Telephony Announcement Server, refer to chapter 4.3.1.1.5 3rd party Call control Telephony Interface (CTI), refer to chapter 4.3.1.1.6

By combining the components a wide range of features are provided. Among these features are:

SIP to/from SS7 ISUP protocol conversion according to RFC 3398 and ITU Q.1912.5 Multiple SS7 interface options:

IETF SIGTRAN SS7 TDM Narrowband Links SS7 High Speed Links

SIP signaling standard: SIP transport over UDP, TCP and TLS IETF RFC 3261 IETF RFC 3262 (i.e. reliable responses) IETF RFC 3264 (i.e. offer/answer) IETF RFC 3515 (i.e. REFER) IETF RFC 4028 (i.e. timer) IETF RFC 4566 IETF RFC 5373 (Answer modes) DTMF Info-Event Package draft-kaplan-sipping-dtmf-package-00. Provide DTMF using SIP INFO

Call Services: User Authentication i.e. SIP Registrar

User credentials stored permanently in database SIP REGISTER support with MD5 Digest authentication

Call Redirection upon busy or no answer SIP 302 and diversion headers

Call forking Call forking list for each user with groups Forking order according to priority Dynamic forking based on SIP registration Forking based on provisioned lists

Dial Plan routing through regular expressions MS Lync integration option

Header adaptation and suppression of unsupported SIP methods when integrating operator networkwith MS Lync

Call Admission Control Customised service adaptation option 3rd party call control Playing and recording of announcements

Media protocols: H.248 for controlling MGW



page 40/55


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 signalingsubsystem. The signaling manager may also be loaded as an applet into a standard web browser such asWindows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace informationto log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presentedwith signaling flows and in a human readable format. Finally, an SNMP Agent is included for the generation ofSNMP Traps in the event of failures within the signaling subsystem. For more details about the tools provided,refer to chapter 5.



page 41/55


4.3.1.1 SIP UC Gateway ArchitectureSIP UC gateways share a common architecture and platform, and the software can be easily ported to varioushardware environments. The hardware supplied by Tieto is built on industry-standard CompactPCIcomponents 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 areIntel-based CPU architecture blades running MontaVista Carrier Grade Edition (CGE) 5 Linux. The Stack-on-a-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-1terminations. 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 differentapplication blades, control of media blades and between different media blades. The gateways may beordered using integrated switches for switching traffic using the chassis backplane. For this, PICMG 2.16 issupported with up to 1 Gbit/s in the chassis backplane. Redundant layer 2 or layer 3 switches are supporteddepending on customer requirements.

Chassis - Various sizes of chassis are available, ranging from 2U (4 slots) up to 4U (8 slots) chassis withintegrated switches.

The smallest configuration consists of one application blade and one media blade. Several chassis can beinterconnected 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 asan application on top of the Tieto signaling stack, which provides the necessary signaling protocols andinterfaces. For a general description of the signaling stack, refer to chapter 2. It executes on the applicationblades.



page 42/55


4.3.1.1.2 Media Gateway (MGW)The MGW function is sourced through 3rd party suppliers, but as the MGW is controlled by the MGC usingH.248, various suppliers’ products can easily be integrated. Tieto has currently integrated with the followingMGW boards, which are available as off-the-shelf products and are pre-integrated in our chassis or standardPCs.

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 andSTM-1 interfaces. Multiple boards can be co-located within the same chassis or distributed over severalchassis to create larger system configurations.

MGW blade, AudioCodes IPM-6310 series

4.3.1.1.3 SIP Back 2 Back User Agent (B2BUA)In the context of UC Gateways, the B2BUA provides additional features, such as call routing, call forking anduser authentication by acting as a Registrar for SIP UA terminals or PBXs. User credentials and forking listsare administered using the DB provided. It is the SIP integration point for the enterprise SIP Trunk and IMSnetwork, and interfaces the MGC for legacy interworking. It allows for customized service development, suchas 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, providingSBC features for integrating enterprise SIP Trunks with IMS networks i.e. acting as an IP – IP gateway. In SBCmode, the SIP B2BUA also controls MGWs using H.248 and thereby provides media features such astranscoding and encrypted media using SRTP. The SBC is also able to handle various flavours of SIP Trunk,such as the Microsoft Lync-supported subset of the SIP protocol. It executes on the application blades.



page 43/55


4.3.1.1.5 SIP Telephony Announcement Server (TAS)SIP Telephony Announcement Server (TAS) gateways allow users to record announcements and playannouncements that are to be invoked in calls. The announcements are recorded on network-mounted disksand played via NFS streaming. Announcements may be stored on a customer-specific server or locally on thegateway. The announcement server is controlled via SIP. Announcement client SW may be included uponrequest.

4.3.1.1.6 3rd Party Call Control Telephony Interface (CTI)Using the 3rd party call control telephony interface (CTI), application call control may be carried out for SIP UAsregistered with the gateway via an API. The interface is uaCSTA-inspired and provides the followingoperations:

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.

4.3.1.2 Application Programming InterfaceUC gateways are black box solutions. MIBs are provided for integration with SNMP Manager and GUI/CLI forcontrolling the system. O&M management, C/C++ and Java 2SE API for integration with 3rd partymanagement systems are available upon request. User administration is performed by interfacing the providedSQL DB. SIP B2BUA and SBC API for service implementation are available upon request.



page 44/55


5 Common Tools for Operation, Maintenance and Support for Tieto Signaling ProductsThe 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 allTieto Signaling Products that provide the same look and feel when combining multiple products.

High level overview of the common tools

5.1 Signaling Manager (GUI/CLI)Signaling Manager is a node management tool that is used to configure and control Tieto Signaling Products.The Signaling Manager provides a Graphical User Interface (GUI) and a Command Line Interface (CLI) for theconfiguration and operation of the signaling system. The GUI can be executed, both as a standaloneapplication and as an applet in a browser. The Command Line Interface (CLI) with command completion canbe started as a standalone tool or run from within the GUI.



page 45/55


Through in-depth checking, customer problems can easily be resolved, thereby improving customer care andreducing configuration time. The main task of the Signaling Manager is to create/modify and manage signalingsystem 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 configurationfiles, perform validation and generate configuration data without access to a complete signaling system. Inonline mode, a connection to the signaling subsystem is set up and used. Configurations can be created,validated and stored in the local file system or in a remote file system using FTP or SFTP.

Signaling Manager snapshot

Title Bar Shows the title, system standard and current file name.

Menu Bar Provides access to basic Signaling Manager functions, such as creating, opening, saving andexporting configurations.

Navigation Pane Contains all Elements that make up the configuration. It is built up as an easy navigationtree 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 ofconfiguration parameters that can be set manually.



page 46/55


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 overallsubsystem status.

Help Built-in online help.

Alarms to be activated are set using configuration settings

Alarm Tab Overview



page 47/55


Statistics Tab Overview

Audit logs are supported where all user commands and changes to configurations are logged to file systemand 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 preventcertain 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 tothe previous one.

5.2 TvTool – Trace Viewer Tool



page 48/55


The Trace Viewer Tool, TvTool, provides full protocol decoding of the Signaling trace files produced by Tietosignaling products. It simplifies your analysis and shows the contents of your signaling log files in humanreadable format. It includes sophisticated message filtering functions, a message viewer for detailedinformation about all parameters in a selected protocol message, user-defined colour coding and an adaptablegraphical user interface.

It can be used offline or online to view an existing log file or view a log file from an executing stack withcontinuous real-time updates. It presents different types of event; Messages, Error, Trace / State & Event andTimers using different colours, messages to/from signaling network and internal messages are shown witharrows. 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 thesystem trace as input.

TvTool snapshot.

5.3 SNMPThe Signaling SNMP support consists of the master agent, Signaling SNMP System Monitor (3SM), as well asOS sub agents (Net-SNMP 5.1.2). The master agent “listens” for alarms from the Signaling system andprocesses/converts these into SNMP traps. The master agent also serves as a proxy for the OS sub agent,



page 49/55


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

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 severityand 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 isbased 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 addedto the alarmActiveTable, and the alarm variables are added to alarmActiveVariableTable. When an alarm iscleared, 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 isissued. Note that alarms can have multiple severities (states). A transition from one state to another is alsosignalled using alarmActiveState.



page 50/55


Alarm handling tables

An extension to the alarm MIB has been created, AlarmMibExt. This represents an extra conceptual column inthe 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 thetraps can be identified by inspecting the SNMP community string in the traps. The community strings have thename 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 thenaming convention created during system configuration using the Signaling Manager GUI/CLI. For thispurpose, the SNMP Master agent accesses the configuration file(s) generated by Signaling Manager.

5.4 Alarm GUI ViewerThe Alarm Viewer GUI is a graphical tool for displaying active alarms received as SNMP Traps from the SNMPMaster Agent.

The tool displays all alarms that can occur in the system by connecting to the Signaling SNMP System Monitoragent

ALARM-MIB alarms are displayed in a tree hierarchy. An additional list shows the different OS alarms receivedfrom the OS sub-agents



page 51/55


Alarm GUI Viewer

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



page 52/55


6 Professional Services

6.1 InstallationTieto can assist and give customers’ organization a quick start when using Signaling Products, providinginstallation and run-time environment configuration services.

6.2 TrainingTo achieve a better and faster understanding of Tieto Signaling products, we provide standard or tailoredtraining 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 boththeoretical 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 ConsultingTieto 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 andprocedures to assist in or perform interoperability tests in labs or on site in conjunction with customers.

6.4 Maintenance & SupportTieto’s Customer Support Centre provides a single point of contact for support and maintenance and offers thefollowing 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 normalbusiness 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 53/55


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

E-mail: [email protected]

Website: http://www.tieto.com/signaling

Our office:

Tieto Sweden ABP.O. Box 1038SE-651 15 KarlstadSweden

Phone: +46 (0)10 481 0000



page 54/55


8 Acronyms and abbreviations

ANSI American National Standards InstituteANSI-41 ANSI standard 41 (Previously known as IS-41)API Application Programming InterfaceATM Asynchronous Transfer ModeAXE Ericsson switching platformBICC Bearer Independent Call ControlBSC Base Station ControllerBSSAP Base Station System Application PartCAMEL Customised Applications for Mobile network Enhanced LogicCAP CAMEL Application PartCDMA Code Division Multiple AccesscPCI CompactPCICPU Central Processing UnitCS1 Capability Set 1ETSI European Telecom Standards InstituteFPGA Field Programmable Grid ArrayGSM Global System for Mobile communicationsGUI Graphical User InterfaceHA High AvailabilityHLR Home Location RegisterIETF Internet Engineering Task ForceIN Intelligent NetworkINAP Intelligent Network Application ProtocolIP Internet ProtocolISR In System Reconfigurable (hardware)ISDN Integrated Services Digital NetworkISUP ISDN User PartITU International Telecommunications UnionM3UA MTP-L3 User Adaptation LayerMAP Mobil Application PartMbps Megabit per secondMGCP Media Gateway Control ProtocolMSC Mobile Services Switching CentreMTP Message Transfer PartPCI Peripheral Component InterconnectPMC PCI Mezzanine CardPSTN Public Switched Telephone NetworkSCCP Signaling Connection Control PartSCP Service Control PointSCTP Stream Control Transport ProtocolSIGTRAN Signaling TransportSIP Session Initiation ProtocolSMS Short Message ServiceSMSC Short Message Service CentreTCAP Transaction Capabilities Application PartTDMA Time Division Multiple AccessTTC Telecommunications Technology Committee

(Japanese standardisation body)



page 55/55


UMTS Universal Mobile Telecommunications SystemVoIP Voice over IP

signaling solution description

Documents