Signaling Solution

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;

x Signaling Protocol Stacks, refer to chapter 2.x Application Enablers, refer to chapter 3.x 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 partners 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:

x 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

x Scalability - The system is easily scalable by adding more servers and traffic load is automatically distributedover the available servers

x Software and Hardware Redundancy - Redundancy can be provided by using at least two hardware serversx Unmatched In-Service-Performance (ISP) - With HD it is possible to add or remove servers dynamically

without bringing the whole system downx Customer applications may be co-located on the same server as the signaling software, or distributed over

different serversx 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 solutionx Support for virtualised environments, such as VMware and RedHat, provides even further deployment optionsEven 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 APIs 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.

x 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.

x 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.)

x 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.).

x 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 customers 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.771Q.775 (06/97)



page 14/55


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

TTC: JT-Q.771JT-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.771Q.775 (06/97), ITU-T X.208X.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 & S13Interface

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:

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

and be accessed from the same customer application

x Horizontal Distribution Architecturex High capacityx Scalabilityx Redundancy

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

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

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

or be distributed over a different set of servers

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

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

x Common Tools for Operation and Maintenancex Signaling Manager GUI and CLI tool for configuration and controlx TvTool Logviewer for interpreting signaling traces and debug infox SNMP Agent for monitoring

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



page 20/55


x Access to support website with software patches , maintenance releases and FAQ

x For provided hardware, Tieto offers RMA handling and shipment world-wide.Currently available off- the-shelf signaling protocol stack products are:

x Stack-on-a-Card (SoaC), refer to chapter 2.5.1x Stack-in-a-Box (SiaB), refer to chapter 2.5.2x Signaling for Linux, refer to chapter 2.5.3x Signaling for Solaris SPARC, refer to chapter 2.5.4x Signaling for Solaris x86, refer to chapter 2.5.5x Signaling for IBM AIX POWER, refer to chapter 2.5.6x 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 customers application environment and/or platform, and vice versa.

This means that signaling capacity and availability can be guaranteed.

Other benefits of the product are:

x High availability with HD configuration, using up to 16 SoaC boards in a single systemx Designed for high availability, 99.999%x 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 Ax Up to eight Gigabit Ethernet interfaces on front panelx Three Gigabit Ethernet interfaces per board for management and application server connectivity (using

Signaling APIs)x High capacity:x 60,000 TCAP transactions/second per SoaC boardx 25 million ISUP BHCA per SoaC boardx 2 000 SIP sessions/second per SoaC boardx 50 000 Diameter transactions/second per SoaC board

x Hot swap supportx Small footprintx Support various operating systems for the application hosts. Among these are;x Sun Solaris 9 +10x HP-UX11ix RedHat Enterprise Linux Version 5 and 6x SUSE 11x MontaVista CGE Linux 5x 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 customers 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.


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



page 22/55


x RedHat Virtualisation 6.1

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

x Additional application host-only support for various operating systems.x Sun Solaris 9 +10x HP-UX11ix Microsoft Windows Serverx AIX 7

x Support for several form factors for communication controller interface boardsx PCI Expressx PMCx 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.


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

x Support for several form factors for communication controller interface boardsx PCI Expressx PMCx 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.


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

x Support for several form factors for communication controller interface boardsx PCI Expressx PMC



page 23/55


x 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:x AIX 7x SUSE 11x MontaVista CGE 5x Sun Solaris 9 +10x HP-UX11ix 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:

x PMCx AMCx PCI/Xx 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:

x 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.

x 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.

x 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:

x 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.

x Short Message Services - The SMS component is the natural starting point for applications requiring SMStransport and reception over SS7; refer to chapter 3.2.

x 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.

x 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

x 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:

x Device Configuration solutionsx Welcome message solutionsx Tariff information systemsx Advertising solutionsx 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:

x 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.

x SGSN - The interface between SMS-C and SGSN, using the MAP protocol. SGSN can act both as asubmitter and receiver of short messages.

x HLR - The interface between SMS-C and HLR, using the MAP protocol. HLR is used by SMS-C to query thelocation of the mobile.

x 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:

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



page 30/55


x INFO (IETF RFC 2976)x Session Timer (IETF RFC 4028)x Answering Modes (RFC5373)

The following main features are implemented in the SIP B2BUA to decrease the time and effort fordevelopment of new services;

x SIP Registrarx Authentication of SIP usersx Persistent storage of user credentials in SQL database

x Conversion of To and From headers using regular expressions

x Call servicesx Call redirection upon busy or no answerx SIP 302 and diversion headers

x Call forkingx Call forking list for each user with groupsx Forking order according to priorityx Dynamic forking based on SIP registrationx Forking based on provisioned lists

x Dial plan routing through regular expressionsx Call admission control

x 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 companys 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:

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



page 32/55


x Diameter Load Balancerx Diameter Proxy Agentx Diameter Relay Agentx Diameter Redirect Agent

x Generic routing abilitiesx Routing on Realms, Host ID, Application IDx AVP Content based routing e.g. IMSI, IP Address, etc.x Load sharing (round-robin) or priority-based destination routingx Forking of messages to multiple destinationsx Stateless and stateful (session stickiness) routingx Configurable modification of message content

x Configurable Dictionary for proprietary Vendors, Commands and AVPs implementations

x Transport protocols:x SCTP (IETF RFC 2960)x TCPx IPv4 & IPv6x TLSx IPSec

x The Diameter Signaling Controller is developed in accordance with the following standards:x IETF RFC 3588, Diameter Basex IETF RFC 3539, AAA Transport Profilex IETF RFC 4006, Diameter Credit-Control App.x IETF RFC 4005, AAA Access Server App.x IETF RFC 4072, Extensible Auth. Protocol App.x IETF RFC 4740, Diameter SIP App.x IETF RFC 5447, NAS to Diameter Interactionx 3GPP TS 29.109, Zh & Zn Interfacesx 3GPP TS 29.140, MM10 Interfacex 3GPP TS 29.172, SLg Interfacex 3GPP TS 29.173, SLh Interfacex 3GPP TS 32.225, Ro & Rf Interfacex 3GPP TS 29.212, Gx interfacex 3GPP TS 32.251, Gy interfacex 3GPP TS 29.228, Cx & Dx Interfacex 3GPP TS 29.229, Cx & Dx Interfacex 3GPP TS 29.272, S13 & S13 Interfacex 3GPP TS 29.328, Sh & Dh Interfacex 3GPP TS 29.329, Sh & Dh Interfacex 3GPP TS 29.213, S9 interfacex 3GPP TS 29.272, S6a & S6d interfacex IMS ready, supports all 3GPP specific identities, command codes and results codes defined in 3GPP TS

29.230 (2007-09)

x More than 120,000 Diameter messages per second using a quad-core Intel Xeon2.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:

x Protocol gatewaysx Legacy voice gatewaysx Unified communication gatewaysWith 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:

x Providing IP access to legacy SS7 nodesx Providing legacy SS7 access for SIGTRAN-only nodesx IP back-haulx 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:

x SS7 Signaling Protocol Stack with support for IETF, ANSI, Chinese, ITU and TTC Standards.x SGW Application SWx Management and configuration tool able to run as standalone applications or within a web browser.x SNMP supportx 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:

x 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.

x 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:

x Media Gateway Controller (MGC), refer to chapter 4.3.1.1.1x Media Getaway (MGW), refer to chapter 4.3.1.1.2x SIP Back 2 Back User Agent (B2BUA), refer to chapter 4.3.1.1.3x SIP Session Border Controller (SBC), refer to chapter 4.3.1.1.4x SIP Telephony Announcement Server, refer to chapter 4.3.1.1.5x 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:

x SIP to/from SS7 ISUP protocol conversion according to RFC 3398 and ITU Q.1912.5x Multiple SS7 interface options:x IETF SIGTRANx SS7 TDM Narrowband Linksx SS7 High Speed Links

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

x Call Services:x User Authentication i.e. SIP Registrarx User credentials stored permanently in databasex SIP REGISTER support with MD5 Digest authentication

x Call Redirection upon busy or no answerx SIP 302 and diversion headers

x Call forkingx Call forking list for each user with groupsx Forking order according to priorityx Dynamic forking based on SIP registrationx Forking based on provisioned lists

x Dial Plan routing through regular expressionsx MS Lync integration optionx Header adaptation and suppression of unsupported SIP methods when integrating operator network

with MS Lyncx Call Admission Controlx Customised service adaptation optionx 3rd party call controlx Playing and recording of announcements

x Media protocols:x H.248 for controlling MGW



page 40/55


x TDM E1/T1 PCMx RTP/RTCP per RFC 3550/3551x SRTP per RFC 3711x DTMF over RTP per RFC 2833x DTMF over SIP INFOx Comfort Noise (RFC3389)x Silent Suppression

x Voice coding:x G.711, G.723.1, G.729A/B, G.726, G.727, GSM-FR, GSM-EFR, EVRC, NB-AMR, iLBC, RT Audiox Wideband coders, including G.722 and AMR

x Echo cancellation:x G.168-2002 compliant, up to 128ms configurable tail lengths

x In-band signaling:x DTMF, MF detection & generationx Call Progress tones detection & generationx Playing and recording of announcements

x Security:x VLAN tagging IEEE 802x TLSx SRTPx SSHx Secure and hardened OS

x Media capacity:x Up to 2016 media ports per media blade (capacity depending on codec)x Up to 42 * E1/T1 interfaces per media bladex Up to two STM-1/OC3 in automatic protection mode per media blade

x Built on standard 19-inch rack mount chassisx Up to 4U height chassisx Two slots for Signaling & Media Controller bladesx Up to 5 slots available for Media bladesx One 4U unit can handle up to 9765 ports & 210 E1/T1 interfacesx Dual Ethernet switchesx Redundant power supplies (AC or DC)x 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;

x 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.

x 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.

x 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.

x 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.

x AudioCodes TP-series TP-260, TP-1610, TP-6310 and TP-8410.x 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 Gat

Signaling Solution

Documents

Transcript of Signaling Solution