Signaling Solution

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

Overview
page 1/55
2009 Tieto Corporation signaling solution overview v1 0.docx
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson Copyright Copyright 2012 Tieto Sweden AB. MAM 100 1000-105/101 V1.0 Public rd October 3 2012
Disclaimer The contents of this document are subject to revision without notice, due to continued progress in methodology, design and manufacturing. Tieto shall have no liability for any errors or damages of any kind resulting from the use of this document.
Trademark List Tieto is a trademark of Tieto Corporation in the United States and other countries.
Product Information Document Number: MAM 100 1000-105/101 Revision: V.1.0 Date: October 3rd 2012
Validity Please note that this document is subject to change without notice. This document includes details on both basic and optional products. General availability of the products is subject to discretion of Tieto.
Abstract All trademarks or registered trademarks are property of their respective owners.
page 2/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson MAM 100 1000-105/101 V1.0 Public rd October 3 2012
Table of Contents
1 Scope of Document ........................................................................................................................................ 5 1.1 Signaling Solutions Overview ...................................................................................................................... 5 2 Signaling Stacks & Protocols ......................................................................................................................... 7 2.1 Horizontal Distribution ................................................................................................................................. 7 2.2 Application Programming Interface - API ................................................................................................... 10 2.2.1 C/C++ Programming Interfaces ....................................................................................................... 10 2.2.2 Java Programming interfaces .......................................................................................................... 11 2.3 Portable Architecture ................................................................................................................................ 12 2.4 Supported Signaling Protocols .................................................................................................................. 13 2.4.1 SS7 protocols .................................................................................................................................. 13 2.4.2 SIGTRAN protocols ......................................................................................................................... 15 2.4.3 Radio Network Protocols ................................................................................................................. 15 2.4.4 IMS Protocols .................................................................................................................................. 16 2.4.5 LTE protocols .................................................................................................................................. 18 2.5 Packaged Products................................................................................................................................... 19 2.5.1 Stack-on-a-Card (SoaC) .................................................................................................................. 20 2.5.2 Stack-in-a-Box (SiaB) ...................................................................................................................... 21 2.5.3 Signaling for Linux ........................................................................................................................... 21 2.5.4 Signaling for Solaris SPARC ......................................................................................................... 22 2.5.5 Signaling for Solaris x86 ............................................................................................................... 22 2.5.6 Signaling for IBM AIX POWER ........................................................................................................ 23 2.5.7 Signaling for AdvancedTCA ............................................................................................................. 23 2.5.8 Communication Controllers.............................................................................................................. 23 2.5.9 Available types of package licenses................................................................................................. 24 3 Application Enablers..................................................................................................................................... 25 3.1 Device Detection Application (DDA) .......................................................................................................... 25 3.1.1 Application Programming Interface .................................................................................................. 27 3.2 SMS Component ...................................................................................................................................... 27 3.2.1 Application Programming Interface .................................................................................................. 28 3.3 SS7 Monitor.............................................................................................................................................. 28 3.3.1 Application Programming Interface .................................................................................................. 29 3.4 SIP B2BUA Component ............................................................................................................................ 29 3.4.1 Application Programming Interface .................................................................................................. 30 3.5 Diameter Signaling Controller ................................................................................................................... 30 3.5.1 Application Programming Interface .................................................................................................. 33 4 Tieto Gateway Platform ................................................................................................................................ 34 4.1 Protocol Gateways.................................................................................................................................... 35 4.1.1 Signaling Gateway (SGW) ............................................................................................................... 35 4.2 Legacy Voice Gateways............................................................................................................................ 36 4.2.1 ISDN/PRI - ISUP Gateway (IGW-P) ................................................................................................. 36 4.3 Unified Communication Gateways ............................................................................................................ 38 4.3.1 SIP UC Gateway and Session Border Controller.............................................................................. 38 5 Common Tools for Operation, Maintenance and Support for Tieto Signaling Products ........................... 44 5.1 Signaling Manager (GUI/CLI) .................................................................................................................... 44 page 3/55
5.2 TvTool Trace Viewer Tool ...................................................................................................................... 47 5.3 SNMP....................................................................................................................................................... 48 5.4 Alarm GUI Viewer ..................................................................................................................................... 50 6 Professional Services ................................................................................................................................... 52 6.1 Installation ................................................................................................................................................ 52 6.2 Training .................................................................................................................................................... 52 6.3 Expert Consulting ..................................................................................................................................... 52 6.4 Maintenance & Support ............................................................................................................................ 52 7 Contacts ........................................................................................................................................................ 53 8 Acronyms and abbreviations ....................................................................................................................... 54
page 4/55
1 Scope of Document
The purpose of this document is to provide a technical overview of Tieto Signaling Solutions and Products on open platforms. It also provides an overview of signaling network evolution and technologies in relation to Tieto Signaling Product offerings.
1.1 Signaling Solutions Overview

Tieto Signaling Solutions supplies signaling products in several areas, ranging from pure protocol stacks to complete network nodes, delivered as black box solutions with hardware, software, documentation and support in accordance with the SLA. Due to the modular architecture, new products may easily be developed and delivered with short Time-To-Market. All software may run on a variety of hardware platforms and interface boards. Depending on customer requirements, hardware can be provided by Tieto and shipped world-wide from our logistics centre.
Tieto Signaling product survey Products are provided within three main areas; Signaling Protocol Stacks, refer to chapter 2. Application Enablers, refer to chapter 3. Gateways, refer to chapter 4. All product areas are built upon modular software architecture, including common tools for operation and maintenance. The common operation and maintenance tools are described in chapter 5. page 5/55
High availability middleware is necessary when providing world class Carrier Grade products. The chosen components for this vary among the different products areas and are sometimes in-house developed products, 3rd party sourced products, open source products or combinations thereof. The HW middleware used for each product is described within each product area. A wide range of hardware components are supported within the modularized hardware platform. The platform is used within the different product areas. Through a well-built eco-system of both products developed inhouse and by 3rd party suppliers, Tieto is able to support leading hardware technologies. Supported hardware is described within each product area.
page 6/55
2 Signaling Stacks & Protocols

Tieto Signaling Stacks is a complete range of signaling products and services. The product line is an important component for equipment manufacturers, software houses, system integrators, computer vendors and network operators implementing solutions for telecoms networks. Signaling stacks provide a base for Tieto and our partners product platforms for, inter alia, 2G, 2.5G, 3G and 4G IMS and LTE networks. With more than 25,000 installations worldwide, Tieto is a leading supplier of signaling solutions to industry. Signaling solutions provide a turnkey signaling stack platform for integration in e.g. Location-based solutions, Messaging solutions, Prepaid solutions, Charging solutions, Voice over IP solutions, Device Detection solutions, Softswitch solutions and Application Servers. It is compliant with all major standards; ITU, ANSI, TTC and Chinese standards for traditional SS7 signaling. For IP-based network technologies such as SIGTRAN, LTE and IMS, it is compliant with standards from IETF and 3GPP. Tieto Signaling stacks guarantee scalability, high capacity, high availability, flexibility and a small footprint. In addition, they are easy to upgrade as demands for capacity and redundancy rise. APIs for integration with customer applications are designed for a reliable and efficient development of customer solutions and, together with the operation and maintenance tools provided, minimize the amount of integration work required. Tieto supports most major open operating systems & platforms as off-the-shelf products, refer to chapter 2.5.
2.1 Horizontal Distribution

Horizontal Distribution (HD) is a deployment architecture that provides the option of deploying multiple signaling servers all sharing the same network appearance e.g. signaling point code. With HD, Tieto is able to offer systems with: Extreme Performance Performance is scaled linearly using multiple servers in a system. It is further scalable within each server, thereby taking advantage of multi-core server architecture Scalability - The system is easily scalable by adding more servers and traffic load is automatically distributed over the available servers Software and Hardware Redundancy - Redundancy can be provided by using at least two hardware servers Unmatched In-Service-Performance (ISP) - With HD it is possible to add or remove servers dynamically without bringing the whole system down Customer applications may be co-located on the same server as the signaling software, or distributed over different servers Many different operating systems are supported for customer application integration, and it is also possible to mix different operating systems within the same signaling system solution Support for virtualised environments, such as VMware and RedHat, provides even further deployment options Even if a failure occurs in one of the signaling servers in the signaling node cluster, HD ensures that the application(s) always maintain(s) contact with the network via alternative servers. The signaling traffic is load shared between available signaling servers. The complete HD architecture acts as a single node in the operator network architecture, thus simplifying network configuration and deployment.
page 7/55
Signaling Horizontal Distribution Architecture The Application Host(s) is a/are server(s) that host the customer application(s) that integrate the provided signaling APIs and management tools for interaction with the HD Signaling Subsystem. The HD Signaling System implements the signaling protocol stacks and architectural support software to assure high availability and simplify operation and maintenance. The Signaling Protocol APIs are fully distributed and allow several different applications, in several different application CPUs, to access the signaling subsystem. Load sharing can be applied on both outgoing and incoming signaling traffic. All communication between the signaling API and the signaling protocol stack implementation is hidden from the application user by the provided signaling middleware, Common Parts, which uses IP as the bearer for messages between the applications and signaling subsystem.
page 8/55
The Signaling protocol APIs are provided for C, C++ and Java application development. Different programming languages may be mixed within the same signaling solution, having Java implementations running side by side with C implementations. As an option, High Level APIs are available which hide the under-lying distributed architecture of HD for application developers. All protocol APIs work in a similar ways for the chosen programming language, which enables fast and cost-efficient development, refer to chapter 2.2 for further details. A full set of management tools is provided for the operation and maintenance of the signaling subsystem, easing the integration and reducing time-to-market. Signaling Manager, an easy-to-use GUI and CLI is provided for the configuration and control of the signaling subsystem. The Signaling Manager may also be loaded as an applet into a standard web browser such as Windows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace information to log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presented with signaling flows and in a human readable format. Finally, an SNMP Agent is included for the generation of SNMP Traps in the event of failures within the signaling subsystem. For more details on the tools provided, refer to chapter 5. Operation and management APIs are provided for easy integration of customer applications with proprietary management solutions. The APIs management application can control the system, monitor alarms and retrieve statistics from the signaling subsystem. The OAM APIs can be used together with the tools provided to create customer-specific solutions. The HD Signaling subsystem consists of the following main processes (threads): Back End Process (BEP) The Back End Processes implement high level signaling protocols from MTPL3/M3UA and above (e.g. SCCP, TCAP, MAP, etc.). Back End Process serves as a signaling message router for protocol user data between the Signaling Protocol APIs used by customer applications and the different supported bearers, i.e. Signaling Front Ends. The signaling subsystem supports multiple Back Ends, which may be distributed over several servers, as well as co-located on the same server. The Back Ends interact with SS7 Front End Processes. SS7 Front End Process (SS7 FEP) The SS7 Front End processes come in different flavours depending on the low level bearer type to be used for higher level protocols. SCTP Front End implements support for the SCTP protocol and is used as the bearer for SIGTRAN (i.e. SS7 over IP) traffic. It may also be used as a bearer for SIP and Diameter traffic. SCTP uses standard Ethernet interfaces for IP connectivity. MTPL2 Front End implements support for traditional MTPL2 narrowband signaling over E1/T1/J1 telecom interfaces. It also supports High Speed Signaling broadband links that are compliant with G.703. It requires specific communication controller boards for E1/T1/J1 terminations2.5.8 for available supported boards and form factors (e.g. PCI Express, PMC, etc.) NNI-SAAL Front End implements support for signaling over ATM, i.e. SSCOP over AAL5. It requires specific communication controller boards for the E1/T1/J1 terminations. Refer to chapter 2.5.8 for available boards and form factors (e.g. PCI Express, PMC, etc.). M2PA Front End implements support for MTPL2 signaling over SCTP. M2PA replaces the MTPL1 E1/T1/J1 termination with standard Ethernet interfaces for IP connectivity to achieve higher performance and simplify the low level transmission architecture.
page 9/55
Diameter Front End Process (DIA FEP) - The Diameter Front End Processes implement support for the Diameter protocol. The Diameter protocol uses standard Ethernet interfaces for connectivity. It may use TCP, UDP or SCTP as a bearer (SCTP Front End). Security options, such as TLS and IPSec, are supported. SIP Front End Process (SIP FEP) - The SIP Front End Processes implements support for the SIP protocol. The SIP protocol uses standard Ethernet interfaces for connectivity. It may use TCP, UDP or SCTP as a bearer (SCTP Front End). Security options, such as TLS and IPSec, are supported. Network Management Process (NMP) The Network Management Process implements the common signaling network management procedures for the signaling subsystem. This includes control of links, route-set status, subsystem status and associations to adjacent nodes. It thereby ensures that the signaling subsystem appears as one network node, although multiple Back Ends may be distributed over several servers. Execution Control (ECM/ECS) - The Execution Control processes act as signaling subsystem supervisors and ensure high availability and successful recovery upon failures in the signaling subsystem. Each Execution Control instance has the role as a Master (ECM) or Slave (ECS). In case of failure of the Master, any one of the Slaves may take over as Master. Monitoring of subsystem processes (threads) is performed on process Id (thread Id), combined with heartbeats for monitoring connectivity between processes. Operation and Maintenance Process (OAMP) - The Operation and Maintenance Process serves as the access point for external management and control of the subsystem. It is accessed through the OAM API for customerdeveloped applications and the Signaling Manager GUI/CLI. It serves as a router of management requests and direct messages to the appropriate receiver within the subsystem. Through the OAM interface, a user of the subsystem may perform control operations (orders), request and receive alarms, and collect measurement data (statistics). Communication Controllers (E1/T1/J1) A range of in-house developed and third party communication controllers is supported. Refer to chapter 2.5.8, Communication Controllers, for further information. Ethernet Controllers (RJ-45) The signaling subsystem uses standard Ethernet controllers available from the chosen server hardware supplier. These may either be fixed interfaces at the server hardware or mounted in available expansion slots.
2.2 Application Programming Interface - API

The signaling products are designed to make it easy to build a system that utilizes the underlying signaling protocols. For the chosen programming language, the structure of the different protocol APIs is the same. The Signaling APIs are fully distributed and communicate with the signaling subsystem by using the provided middleware Common Parts. The actual communication implementation is transparent to the application programmer. For most supported platforms, the majority of middleware communication is based on using Internet sockets over TCP. Several application instances can simultaneously connect to a specific signaling protocol and multiple protocols may be used from the same protocol instance.
2.2.1 C/C++ Programming Interfaces

For applications developed in C/C++, developers access the signaling protocols by using function calls through a well-defined Application Programming Interface (API). Each signaling protocol layer has its own API, containing functions and call-back definitions for all protocol primitives and system functions. Requests/Confirmations are sent to the stack by calling predefined functions which encode provided structures with parameter data and transport it via the middleware to the appropriate page 10/55
receiver in the signaling subsystem. Reception of messages and events is done using call-back functions where the function prototype is defined by the API and customer application developer completes the code according to their need. Before the application may send or receive messages, the middleware is initiated and inter-process communication (IPC) channels to the signaling subsystem are set up, which each protocol uses for registration (bind) with the subsystem and for transporting protocol data. The actual whereabouts, i.e. on which server each process executes, are managed by the middleware, which allows applications to dynamically add and/or remove signaling subsystem processes without taking down the complete system. Several application instances can simultaneously connect to a specific signaling protocol, and multiple protocols may be used from the same protocol instance. As an option, High Level APIs are available, which hide the underlying distributed architecture of HD for application developers even further by also managing the distribution and load sharing of traffic over available Back Ends.
Signaling API architecture
All APIs are thread-safe and support numerous different operating systems, refer to chapter 2.5 for available off-the-shelf products.
2.2.2 Java Programming interfaces

The Java Standard Edition (J2SE) APIs provide the interfaces and classes required to connect to and receive primitives from signaling protocols within the signaling subsystem. The APIs contain functionality to parse and extract information from the received primitives. The application Java program uses the API to connect to one or more instances of signaling subsystem processes through sockets. The Provider class handles the connection to the signaling subsystem and is used for sending/receiving events to/from the signaling subsystem.
page 11/55
The application is necessary in order to implement the methods of a Listener class, which allows primitives (events) to be received from the signaling subsystem, by registering itself as a listener in a Provider class. All primitives received by the Listener in the Java API are implemented as Java Events, i.e. they are subclasses of the java.util.EventObject class. Each primitive has its own method with a specific set of parameters implemented as member variables in the corresponding event classes used when encoding/decoding messages.
2.3 Portable Architecture

All components of the signaling subsystem are easy to adapt to nearly any type of customer-specific hardware/software platform. This is made possible by the highly modular and portable software architecture.
Portable Signaling Architecture The main principle of the signaling architecture is to distil all platform dependent interfaces to a set of common functions. The OS Interface Middleware distils all OS service functions required by a signaling protocol layer. This makes the signaling protocol layer software platform independent, and the same source code can be used on all platforms. The Lower Interface is the integration point for any software module or hardware module that provides signaling services to the specific protocol layer. In many cases, the lower interface is directly connected to one of the available signaling protocol layers. In such instance no adaptation is required. The Upper API is the service access point for the customers application. Each signaling protocol layer has its own accompanying API, allowing the user to get easy access from their application.
page 12/55
There is a common Management Interface used by all protocol layers within the signaling subsystem that interface with the Operation and Maintenance process used for external management access. This enables easier adaptation to different management solutions as the management of each protocol layer follows the same architecture and principles provided by the internal management interface.
2.4 Supported Signaling Protocols

The sub-chapters below give an overview of signaling protocols currently available in the Tieto Signaling products range. New protocols are added on regular basis and incorporated into the portfolio.
2.4.1 SS7 protocols

The following SS7 protocols and major standards are currently supported. Additional standard support is added on regular basis. For details of latest supported versions, please refer to the product sheet for each protocol. Protocol Name MTPL1 Message Transfer Part Layer 1 AAL-5 ATM Adaptation Layer 5 Standard Compliance 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 Control Part ETSI: ETSI 300 009-1 V1.4.3 (2001 - 02) ITU-T: Q.711 Q.714 (07/96), Q752 (06/97) ANSI: T.112 (1996), T1.116.2 (1996) China: P.R.C. 1994:10 TTC: JT-Q.711, Q.712, Q.714 (04/97), JT-Q.713 (04/2000) TCAP - Transaction Application Part ITU-T: Q.752 (06/97), Q.771Q.775 (06/97)
page 13/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson 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 (PN3892), TIA/EIA-41-D (V7), TR-45, J-STD-036: Enhanced Wireless 9-1-1 Phase 2, (07/00), TR-45, IS-730, IS-136 (DCCH) Support in IS-41, (07/97), TR-45, IS-771, WIN TIA/EIA-41-C modifications, (07/99), TR-45, IS-764 (PN4103), (06/98), TR-45, IS-826 (PN-4287), (05/00), IS-841 Based Network Enhancements for MDN Based Message Centres, TDMA Forum, Interim Over-the-Air-Activation specification, (12/96), V1.1, TIA/EIA IS-848 (10/00) Ericsson MAP (EMAP): GSM 03.03, 03.32, 09.02 (version 6.1.0, 08/98), GSM 03.38, 03.40 (version 3.5.0), GSM 04.11, 04.08, ITU-T Q.771Q.775 (06/97), ITU-T X.208 X.209 (1988) INAP - Intelligent Network Application Protocol ETSI/ITU: ETS 300 374-1 (09/94), ETS 300 403-1 ITU-T Q.931 (1993), ETS 300 356-1, EN 301 140-1 INAP Capability Set 2 (CS2) v1.3.4 (1999-06), GSM 09.02, 02.03, 03.03, 03.32, 03.78, 04.08, 09.78, 3GPP TS 29.078 V4.8.0 (03/03) CAMEL Phase 3; CAP Specification (Release 4), Q.1218 (1993), Q.850 (1993), Q.1214 (1993), X.208 (1988), X.209 (1988), X.219 (1988), Q.773 (03/93), Q.1228 (09/97) Ericsson INAP CS1+ CAP - CAMEL Application Protocol ITU: GSM 09.78 (TS 101 046), GSM 09.78 version 7.1.0 Release 1998, 3GPP TS 29.078 V4.8.0 (2003-03) ANSI: T1.111-T1.112, 1996 ETSI: 3GPP TS 49.031 V7.6.0 (2008-03), 3GPP TS 48.071 V7.2.0 (2007-06), 3GPP TS 48.008 (MSC-BSS) Interface Layer 3 Specification 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), MAM 100 1000-105/101 V1.0 Public rd October 3 2012
BSSAP Base Station System Application Part
ISUP ISDN User Part
page 14/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson MAM 100 1000-105/101 V1.0 Public rd October 3 2012 Q.761-Q.764 (09/97), Q.767 (02/91), Q.850 (05/98) ETSI: ETS 300 356-1 ETS 300 356-12, 1998, ETS 300 356-17, ETS 300 356-20, 1998, ETS 300 356-31 ETS 300 356-36 1998 TTC: JT-Q.762 Q.764 (09/99) + many national variants of ISUP SSCOP Service Specific Connection Control Protocol ITU: Q.2100, Q.2140(02/95), Q.2130(07/94), Q.2110 (07/94) ANSI: T1.645 (1995), T1.637 (1994), T1.652 (1996) TTC: JT-Q.2140 (04/95), JT-Q.2130 (07/94), JT-Q.2110 (02/96), JT-Q.2144 NNI-SSCF Network Node Interface Service Specific Coordination Protocol ITU: Q.2100, Q.2140 (02/95) ANSI: T1.645 (1995) TTC: JT-Q.2140 (04/95)
2.4.2 SIGTRAN protocols

The following SIGTRAN (SS7 over IP) protocols and standards are available: Protocol Name SCTP Stream Control Transmission Protocol M3UA MTP3 User Adaptation M2PA - MTP2 User Peer-to-Peer Adaptation Layer M2UA - MTP2 User Adaptation* SUA - SCCP User Adaptation* *available upon customer request Standard Compliance IETF RFC 4460 (04/2006), RFC 4960 (09/2007) IETF RFC 4666 (09/06) IETF RFC 4165 (05/09) -
2.4.3 Radio Network Protocols

The following Radio Access Network (RAN) protocols are available: Protocol Name RANAP NBAP ALCAP RLC SSCOP Service Specific Connection Control Protocol page 15/55
Standard Compliance 3GPP Release 99 3GPP Release 99 3GPP Release 99 3GPP Release 99 ITU: Q.2100, Q.2140(02/95), Q.2130(07/94), Q.2110 (07/94)
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson MAM 100 1000-105/101 V1.0 Public rd October 3 2012 ANSI: T1.645 (1995), T1.637 (1994), T1.652 (1996) TTC: JT-Q.2140 (04/95), JT-Q.2130 (07/94), JTQ.2110 (02/96), JT-Q.2144 NNI-SSCF Network Node Interface Service Specific Coordination Protocol ITU: Q.2100, Q.2140 (02/95) ANSI: T1.645 (1995) TTC: JT-Q.2140 (04/95) UNI- SAAL User Network Interface Service Specific Coordination Protocol ITU: Q.2100, Q.2140 (02/95) ANSI: T1.645 (1995) TTC: JT-Q.2140 (04/95)
2.4.4 IMS Protocols

The following IMS protocols are available: Protocol Name SIP Standard Compliance RFC 3261, RFC3262 RFC 2617 - HTTP Authentication RFC 2976 - SIP INFO Method RFC 3262 - SIP PRACK Method RFC 3265 - SIP SUBSCRIBE/NOTIFY methods RFC 3310 - HTTP Digest Authentication RFC 3311 - SIP UPDATE method RFC 3313 - Extensions for Media Authorisation RFC 3323 - Privacy Mechanism RFC 3324 - Network Asserted Identity RFC 3325 - Asserted Identity in Trusted Networks RFC 3326 - Reason Header field RFC 3327 - Extension Header field RFC 3329 - Security Mechanism Agreement page 16/55
Bearer support UDP, TCP and/or SCTP TLS, IPSec, SigComp*
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson RFC 3372 - SIP-T RFC 3398 - ISUP-SIP Mapping RFC 3428 - SIP MESSAGE Method RFC 3455 - Private Header for 3GPP RFC 3515 - SIP REFER Method RFC 3578 - Mapping ISUP Overlap Signaling to SIP RFC 3608 - Extension Header field for Service Route Discovery RFC 3725 - 3pcc in SIP RFC 3841 - Caller Preferences RFC 3892 - Referred-By Mechanism RFC 3903 - SIP PUBLISH Method RFC 3911 - Join Header RFC 4028 - Session Timers RFC 4117 - Transcoding Services Invocation using 3pcc RFC 4244 - Extension for Request History Header Information RFC 4457 - P-User-Database Private Header Diameter IETF RFC 3588, Diameter Base IETF RFC 3539, AAA Transport Profile IETF RFC 4006, Diameter CreditControl App. IETF RFC 4005, AAA Access Server App. IETF RFC 4072, Extensible Auth. Protocol App. IETF RFC 4740, Diameter SIP App. IETF RFC 5447, NAS to Diameter Interaction 3GPP TS 29.109, Zh & Zn page 17/55
MAM 100 1000-105/101 V1.0 Public rd October 3 2012
UDP, TCP and/or SCTP TLS, IPSec
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson Interfaces 3GPP TS 29.140, MM10 Interface 3GPP TS 29.172, SLg Interface 3GPP TS 29.173, SLh Interface 3GPP TS 32.225, Ro & Rf Interface 3GPP TS 29.228, Cx & Dx Interface 3GPP TS 29.229, Cx & Dx Interface 3GPP TS 29.272, S13 & S13 Interface 3GPP TS 29.272, S6a & S6d Interface 3GPP TS 29.213 S9 Interface 3GPP TS 29.328, Sh & Dh Interface 3GPP TS 29.329, Sh & Dh Interface 3GPP TS.32.251, Gy Interface 3GPP TS.29.212, Gx Interface SCTP Stream Control Transmission Protocol H.248 MEGACO* IETF RFC 4460 (04/2006), RFC 4960 (09/2007) IP MAM 100 1000-105/101 V1.0 Public rd October 3 2012
*available upon customer request
2.4.5 LTE protocols

The following LTE Protocols are available: Protocol Name Diameter Standard Compliance Diameter Base acc. to IETF RFC 3588. In addition, various IETF and 3GPP interface and standard additions are also supported. IETF RFC 4460 (04/2006), RFC 4960 (09/2007) Bearer support UDP, TCP and/or SCTP TLS, IPSec
SCTP Stream Control Transmission Protocol
IP
page 18/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson PCAP - Positioning Calculation Application Part LCSAP Location Service Application Protocol 3GPP TS 25.453 V7.12.0 MAM 100 1000-105/101 V1.0 Public rd October 3 2012 SCTP
3GPP TS 29.171 V9.1.0
SCTP
2.5 Packaged Products

Tieto provides signaling protocol packages as off-the-shelf products for various operating systems and HW architectures. Depending on customer requirements, Tieto provides hardware - ranging from communication controllers for E1/T1 termination to complete Stack-in-a-Box (SiaB) solutions. SiaB solutions include chassis, server blades mounted in chassis (Stack-on-a-Card - SoaC) and communication controllers for signaling interfaces (E1/T1/J1 and/or Ethernet RJ-45). Common features for all packaged products are: Concurrent support for SS7, SIGTRAN, IMS and LTE protocols IMS and LTE protocols can execute simultaneously with SS7 protocols in the same signaling subsystem and be accessed from the same customer application Horizontal Distribution Architecture High capacity Scalability Redundancy Mixed interface support SIGTRAN, MTPL2 E1/T1/J1 and High Speed Signaling Links (G.703 and AAL5) in one product Full standard support within the same delivery Configurable options to run as ANSI, ITU, TTC or Chinese Mixed standards; ANSI on top of ITU, ITU on top of ANSI, etc. Distributed and thread-safe APIs for C/C++ and Java Applications may be co-located on the same servers as the signaling subsystem or be distributed over a different set of servers Mixed operating system environment Applications may run under a different operating system than the signaling subsystem Applications may run under different operating system while accessing the same signaling subsystem, e.g. Windows applications may co-exist with Linux applications Common Tools for Operation and Maintenance Signaling Manager GUI and CLI tool for configuration and control TvTool Logviewer for interpreting signaling traces and debug info SNMP Agent for monitoring Supplied with warranty, support and maintenance in accordance with defined SLAs. Phone and email support by signaling help desk page 19/55
Access to support website with software patches , maintenance releases and FAQ For provided hardware, Tieto offers RMA handling and shipment world-wide. Currently available off- the-shelf signaling protocol stack products are: Stack-on-a-Card (SoaC), refer to chapter 2.5.1 Stack-in-a-Box (SiaB), refer to chapter 2.5.2 Signaling for Linux, refer to chapter 2.5.3 Signaling for Solaris SPARC, refer to chapter 2.5.4 Signaling for Solaris x86, refer to chapter 2.5.5 Signaling for IBM AIX POWER, refer to chapter 2.5.6 Signaling for AdvancedTCA, refer to chapter 2.5.7
2.5.1 Stack-on-a-Card (SoaC)

Stack-on-a-Card is a fully Signaling Black Box-embedded hardware and software solution for CompactPCI (cPCI)-based systems. It is designed for system integrators, application developers and network operators who are implementing SS7 connectivity in a cPCI system. The key benefit of the Stack-on-a-Card product is that all SS7 signaling protocol software executes in a closed environment and does not affect the 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: 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-UX11i RedHat Enterprise Linux Version 5 and 6 SUSE 11 MontaVista CGE Linux 5 Microsoft Windows Server
page 20/55
The latest generation of Stack-on-a-Card, equipped with E1/T1 terminations and SIGTRAN RJ-45 ports.
2.5.2 Stack-in-a-Box (SiaB)

The Stack-in-a-Box product provides a complete signaling interface unit with built-in cooling and power supply. The product is supplied as a standard 19-inch rack-mounted unit, ready to be installed in existing or new telecom nodes. The main benefit of the Stack-in-a-Box product is that all signaling protocol software executes in a closed environment and does not affect the customers application environment and/or platform, and vice versa. This means that signaling capacity and availability can be guaranteed. SiaB solutions are offered using 1U up to 4U chassis with integrated switches. The chassis may be interconnected to scale even further. The Stack-on-aCard is mounted in the chassis slots as signaling server blades; refer to chapter 2.5.1 for description of SoaC features.
SiaB 1U chassis
2.5.3 Signaling for Linux

Signaling for Linux is a server-based signaling solution for Linux systems, consisting of software with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to be mounted in the Linux servers. It is designed for system integrators, application developers and network operators implementing SS7, SIP or Diameter connectivity in a Linux server environment. It supports all major hardware vendors using Intel architecture for single and multi-core CPUs. This includes, but is not limited to HP, Dell, IBM BladeCenter, etc. Other benefits of the product are: Ability to execute in virtualised environments, such as: VMware ESX 4.0 page 21/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson 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-UX11i Microsoft Windows Server AIX 7 Support for several form factors for communication controller interface boards PCI Express PMC PCI MAM 100 1000-105/101 V1.0 Public rd October 3 2012
2.5.4 Signaling for Solaris SPARC

Signaling for Solaris SPARC is a server-based signaling solution for Solaris SPARC architectures, consisting of software with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to be mounted in Solaris SPARC servers. It is designed for system integrators, application developers and network operators implementing SS7, SIP or Diameter connectivity in a SPARC server environment. Other benefits of the product are: 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 x86

Signaling for Solaris x86 is a server-based signaling solution for Solaris Intel architectures, consisting of software with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to be mounted in Solaris Intel servers. It is designed for system integrators, application developers and network operators implementing SS7, SIP or Diameter connectivity in a Solaris server environment. Other benefits of the product are: 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 22/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson PCI MAM 100 1000-105/101 V1.0 Public rd October 3 2012
2.5.6 Signaling for IBM AIX POWER

Signaling for IBM AIX POWER 7 architecture is a server-based signaling solution for IBM POWER architectures, consisting of software with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to be mounted in the servers. It is designed for system integrators, application developers and network operators implementing SS7, SIP or Diameter connectivity in a Solaris server environment. Supported operating systems for the signaling subsystem and application hosts are: AIX 7 SUSE 11 MontaVista CGE 5 Sun Solaris 9 +10 HP-UX11i Microsoft Windows Server
2.5.7 Signaling for AdvancedTCA

Signaling for AdvancedTCA architecture is a server-based signaling solution for ATCA architectures, software with optional hardware communication controller interface boards for telecom interfaces (E1/T1/J1) to be mounted in servers. The solution is integrated by Tieto on the ATCA blades chosen by the customer in a customized solution.
2.5.8 Communication Controllers

Tieto provides a full set of Signaling Communication Controllers for various form factors and system architectures used as part of our signaling protocol products. This chapter gives a brief overview of available controllers.
2.5.8.1 ISR PCIe

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

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

The Tieto ISR-PMC (PCI Mezzanine Card) with PCI Adapter communication controller for PCI bus is a highdensity controller for SS7 signaling. Mounting the ISR-PMC board on the PCI adapter ensures that only legacy servers with PCI bus are supported; refer to chapter 2.5.8.2 for a description of the PMC board. The adapter also provides support for HSL ITU-T Q.703, Annex A, on PCI architecture.
page 23/55
2.5.8.4 ISR-PMC / PCI Express Adapter

The Tieto ISR-PMC (PCI Mezzanine Card) with PCI Adapter communication controller for PCI Express bus is a high-density controller for SS7 signaling. Mounting the ISR-PMC board on a PCI Express adapter provides support for HSL ITU-T Q.703, Annex A; refer to chapter 2.5.8.2 for description of the PMC board.
2.5.8.5 ADAX HDC3 - 8 Trunk SS7 Signaling Controller

The HDC3 provides industry-leading SS7/ATM performance and capacity for Next Generation and IMS networks. Designed to exceed your system requirements, the HDC3 provides superior scalability, flexibility and price performance ratios, making it the perfect choice for your SS7/ATM signaling needs. It supports up to 8 software-selectable trunks of full E1, T1, or J1 per card, with up to 248 LSL MTP2 links per card with high line utilisation or up to 8 HSL MTP2 links per card. It is available for the following form factors: PMC AMC PCI/X PCIe (Full height, Low-Profile and Express Module) board formats
2.5.9 Available types of package licenses

The signaling products are packaged for rapid installation, configuration, application development, deployment and extensions. The following packages are available: Run-time package - For use in live networks. Includes license for usage, basic capacity licensing device driver, load module for protocols, statement of compliance, configuration guide and installation guide. Test and demo packages - For use in lab and development environments for development and testing. Includes license for usage, C/C++/Java API library, API header files, load module for protocols, device drivers, developers guide, API specification, statement of compliance, configuration guide and installation guide. Extension packages - Additional licenses for capacity expansion.
page 24/55
3 Application Enablers
The Application Enabler product family is a set of add-on products that are designed to hide the complexity of signaling networks and protocols from the user applications and thereby significantly reduce Time-To-Market and development costs. They are high-level applications on top of the Signaling Protocol stacks and multiple applications can be combined within the same platform. Depending on the enabler usage some come with high level APIs for integration with customer applications while others are complete black-box solutions with welldefined standard interfaces. Tieto provides Application Enablers in the areas of: Automatic Device Management and Authorization The Device Detection Application (DDA) provides interfaces for signaling network-based detection of devices and implementation of equipment identity registers (EIRs); refer to chapter 3.1. Short Message Services - The SMS component is the natural starting point for applications requiring SMS transport and reception over SS7; refer to chapter 3.2. Network Monitoring - The SS7 Monitor provides non-intrusive monitoring of signaling traffic and filter mechanism to catch messages of interest to the user applications; refer to chapter 3.3. IMS and VoIP services - The SIP B2BUA Component can act as a mediator between different SIP implementations by providing header manipulation and service routing, e.g. forking of calls, routing to different SIP servers, location of voice mail boxes, etc. It can also be the base for developing various application services requiring SIP signaling; refer to chapter 3.4 LTE and IMS routing services - The Diameter Signaling Controller provides flexible routing capabilities, i.e. acting as Diameter Proxy and/or Relay Agents between LTE/IMS network elements. It reduces the network configuration complexity, cuts integration costs, increases scalability and provides topology hiding of operator networks. The Diameter Signaling Controller supports the Diameter Router Agent (DRA), as defined by 3GPP; refer to chapter 3.5. A full set of management tools is provided for the operation and maintenance of the Application Enablers. Signaling Manager, an easy-to-use GUI and CLI is provided for configuration and control of the signaling subsystem. The Signaling Manager may also be loaded as an applet into a standard web browser such as Windows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace information to log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presented with signaling flows and a human readable format. Finally, a SNMP Agent is included for generation of SNMP Traps in the event of failures within the signaling subsystem. For more details on the provided tools, refer to chapter 5.
3.1 Device Detection Application (DDA)

The Device Detection Application (DDA) Enabler provides support for the development of device management applications that rely upon signaling network-based detection of new devices, or to implement Advice of Charge or Welcome SMS solutions that rely upon network-based device detection. It may also act in authorization mode and, as such, serve as a high level interface for equipment registers. The DDA detects when a handset enters the network, allowing it to be automatically configured by the device management application using normal over-the-air-activation mechanisms such as SMS or USSD. page 25/55
The DDA receives MAP CheckIMEI message over the SS7 network from the MSC and/or SGSN containing the IMSI and IMEI combination. The MSC issues the MAP messages at IMSI attach (Phone Power On) or at location update (a mobile device is moving in the network). The DDA converts the MAP CheckIMEI message into high level API format, and passes it to the user application for further processing. The DDA can also fetch the MSISDN from the HLR if requested by application or enabled through configuration. The triplet i.e. IMEI, IMSI and MSISDN is presented to the application over the high level API interface. When the application has received the necessary information, it can configure the device using normal overthe-air-activation with SMS MAP. This can be done either by using an external SMSC interface, the SS7 MAP API or, preferably, by incorporating the SMS component into the solution; refer to chapter 3.2. The DDA API may also serve in authorization mode where the DDA user application informs DDA of the equipment status for the phone, i.e. white, grey or black listed. Using authorization mode, customers may rapidly develop an EIR without having to consider the complexity of SS7 protocols.
DDA interfaces
DDA is able to serve several PLMNs concurrently and support various deployment modes in operator networks, where operators may or may not already have EIRs in operation.
page 26/55
It is used together with the Signaling Protocol Stack and is managed through the Common Tools for operation and maintenance, refer to chapter 5.
3.1.1 Application Programming Interface

DDA APIs and OAM APIs are available for C/++ and Java. The implementation follows the same principles as the C/C++ and Java APIs for the signaling protocol stacks, refer to chapter 2.2.1 and 2.2.2.
3.2 SMS Component

Tieto SMS Component provides the highest level of functionality for building a Short Message Service Centre (SMS-C). It is designed for application developers that require SMS-C features to be a part of their offered solution. The main benefit of the SMS Component is to cut development time & costs for applications requiring SMS functionality. It is built using the same architecture as Tieto Signaling products and pre-integrated with Tieto signaling protocol stacks, guaranteeing signaling interoperability with major network suppliers. It can be used as a base for development of a full SMS-C and to develop SMS-based features such as: Device Configuration solutions Welcome message solutions Tariff information systems Advertising solutions VAS services (carbon copy, forwarding etc.) The ETSI MAP SS7 signaling interface is supported and an SMPP interface is provided for user applications. The SMS Component comes in two flavours - Fire and Forget, i.e. SMPP datagram mode only, and/or Store and Forward mode. Store and Forward mode also includes a database for persistent storage of short messages to be retransmitted or pending delivery to end-users. The SMS-C interacts with the following other network nodes: MSC-S - The interface between the SMS-C and the MSC, using the MAP protocol. MSC can act both as a submitter and receiver of short messages. SGSN - The interface between SMS-C and SGSN, using the MAP protocol. SGSN can act both as a submitter and receiver of short messages. HLR - The interface between SMS-C and HLR, using the MAP protocol. HLR is used by SMS-C to query the location of the mobile. ESME - The interface between SMS-C and ESME, using the SMPP protocol. An ESME acts as a submitter of short messages.
page 27/55
SMS-C interfaces The SMS Component is implemented as an application on top of the Tieto Signaling Stack and the ETSI MAP protocol. It supports a full set of different SS7 bearers, such as SIGTRAN, MTP E1/T1 and HSL. For a general description of the Signaling Stack, refer to chapter 2.

The SMS Component offers SMPP protocol as the interface for applications. SMPP client library is not part of the delivery. Several 3rd party libraries are available on the market, either as open source or commercial versions, which can be used in customer applications. O&M APIs are available for Java. The implementation follows the same principles as the Java APIs for the signaling protocol stacks, refer to chapter 2.2.2.
3.3 SS7 Monitor

The SS7 Monitor is an SS7 monitoring subsystem that can be used for non-intrusive monitoring of the SS7 signaling traffic. The SS7 Monitor can also be used together with signaling stacks for applications requiring active connections to the SS7 network. The SS7 monitor provides a configurable message filter, which allows the applications to select only the SS7 messages that are of interest. Messages that match the filter settings are sent to the applications through easy-to-use APIs. It supports the most common SS7 protocols, e.g. MTP, SCCP, TCAP, MAP, ANSI-41, Ericsson MAP, INAP, CAP v1/v2, BSSAP-LE and ISUP. The SS7 Monitor is a distributed and scalable solution where multiple monitors may be part of the same system solution and all accessible from the same application instance. Communication controllers with E1 interfaces for connecting the tap equipment are mounted in standard PCI Express slots in standard Solaris or Linux servers.
page 28/55
SS7 Monitor interfaces
The non-intrusive communication controller supports up to 64 links per board and multiple boards can be combined to build larger monitor solutions. The SS7 monitor re-uses common tools and O&M implementation from the Tieto Signaling stacks. This allows the SS7 Monitor to run in parallel with Signaling stack users, sharing one common O&M interface.

Signaling Monitor APIs and O&M APIs are available for Java. The implementation follows the same principles as the Java APIs for the signaling protocol stacks; refer to chapter 2.2.2.
3.4 SIP B2BUA Component

The SIP B2BUA Component provides functionality to quickly develop SIP and IMS functions such as proxies, registrars and B2BUA for service-specific adaptations and access to external applications for development of value-added service solutions. It provides features such as SIP Header manipulation, call redirection and routing services for SIP-to-SIP calls. Using the SIP B2BUA component as the foundation for development of new features or interworking functions for increased user experience, costs can be cut and time-to-market assured. The implementation conforms to SIP according to RFC 3261 with a number of additions, including: Reliable Responses PRACK (RFC 3262) P-Asserted Identity (IETF RFC 3428) page 29/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson INFO (IETF RFC 2976) Session Timer (IETF RFC 4028) Answering Modes (RFC5373) The following main features are implemented in the SIP B2BUA to decrease the time and effort for development of new services; SIP Registrar Authentication of SIP users Persistent storage of user credentials in SQL database Conversion of To and From headers using regular expressions Call services Call redirection upon busy or no answer SIP 302 and diversion headers Call forking Call forking list for each user with groups Forking order according to priority Dynamic forking based on SIP registration Forking based on provisioned lists Dial plan routing through regular expressions Call admission control Customised service adaptation option The SIP B2BUA re-uses common tools and O&M implementation from Tieto signaling stacks. This allows the B2BUA to run in parallel with signaling stack users, sharing one common O&M interface. The SIP B2BUA is scalable, with up to ten concurrent B2BUA instances within the same signaling subsystem. The SIP B2BUA is a Java 2 Standard Edition Implementation which allows for portability across various environments supporting a JVM. MAM 100 1000-105/101 V1.0 Public rd October 3 2012

Include O&M management Java 2SE API option for integration with 3rd party management systems. B2BUA API for service implementation is offered upon request.
3.5 Diameter Signaling Controller

Tieto Diameter Signaling Controller provides a flexible, robust and secure solution for reduced overall signaling load, simplified network configuration scenarios at roll-out and upgrade as well as secure and efficient intranetwork connectivity. Through its flexible routing capabilities, i.e. acting as Diameter Proxy and/or Relay Agent between LTE/IMS network elements, it reduces network configuration complexity, cuts integration costs, increases scalability and provides topology hiding of operator networks. The Diameter Signaling Controller supports the Diameter Router Agent (DRA) as defined by 3GPP.
page 30/55
Diameter Signaling Controller interfaces The Tieto Diameter Signaling Controller is based on the companys world-class signaling products and is built on the same robust and carrier grade architecture as other Tieto Signaling solutions for applications such as the traditional SS7 and SIP. The solution is built for industry standard Linux servers, such as IBM BladeCenter. The following main features are supported: May act as number of different nodes: Diameter Routing Agent (DRA) Diameter Edge Agent (DEA) page 31/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson Diameter Load Balancer Diameter Proxy Agent Diameter Relay Agent Diameter Redirect Agent Generic routing abilities Routing on Realms, Host ID, Application ID AVP Content based routing e.g. IMSI, IP Address, etc. Load sharing (round-robin) or priority-based destination routing Forking of messages to multiple destinations Stateless and stateful (session stickiness) routing Configurable modification of message content Configurable Dictionary for proprietary Vendors, Commands and AVPs implementations Transport protocols: SCTP (IETF RFC 2960) TCP IPv4 & IPv6 TLS IPSec The Diameter Signaling Controller is developed in accordance with the following standards: IETF RFC 3588, Diameter Base IETF RFC 3539, AAA Transport Profile IETF RFC 4006, Diameter Credit-Control App. IETF RFC 4005, AAA Access Server App. IETF RFC 4072, Extensible Auth. Protocol App. IETF RFC 4740, Diameter SIP App. IETF RFC 5447, NAS to Diameter Interaction 3GPP TS 29.109, Zh & Zn Interfaces 3GPP TS 29.140, MM10 Interface 3GPP TS 29.172, SLg Interface 3GPP TS 29.173, SLh Interface 3GPP TS 32.225, Ro & Rf Interface 3GPP TS 29.212, Gx interface 3GPP TS 32.251, Gy interface 3GPP TS 29.228, Cx & Dx Interface 3GPP TS 29.229, Cx & Dx Interface 3GPP TS 29.272, S13 & S13 Interface 3GPP TS 29.328, Sh & Dh Interface 3GPP TS 29.329, Sh & Dh Interface 3GPP TS 29.213, S9 interface 3GPP TS 29.272, S6a & S6d interface IMS ready, supports all 3GPP specific identities, command codes and results codes defined in 3GPP TS 29.230 (2007-09) More than 120,000 Diameter messages per second using a quad-core Intel Xeon2.4GHz processor MAM 100 1000-105/101 V1.0 Public rd October 3 2012
page 32/55
The DSC reuses common tools and O&M implementation from Tieto signaling stacks. This allows the DSC to run in parallel with signaling stack users, sharing a single common O&M interface. The DSC is scalable with up to 10 running concurrently within the same signaling subsystem.

The DSC is also able to act as a Diameter end node (server or client) with C/C++ and Java J2SE APIs for customer application integration. For O&M there are Java 2SE API and C/C++ options for integration with 3rd party management systems.
page 33/55
4 Tieto Gateway Platform

With its Gateway Platform offering, Tieto provides gateways to significantly shorten network integration lead times and reduce costs. Its complete set of components allows to not only provide off-the-shelf gateways but also to provide customized solutions. The Gateway Platform is a hardware and software platform solution that can also be used for building signaling and/or media gateways. It affords fast and effective development of customer-specific gateway solutions with carrier grade characteristics. The short TTM and cost efficiency afforded by re-using the building blocks provides a financially favourable option to use the result as either a gap-filler or a permanent solution. The product and its total lifecycle are managed by Tieto.
Tieto Gateway Platform components
Based on the Gateway Platform, the following gateways are available off-the-shelf: Protocol gateways Legacy voice gateways Unified communication gateways With the network evolution and convergence, the Gateway Platform is well suited to serve as the basis for developing gateways to bridge the gap between the latest network technologies and existing legacy networks.
page 34/55
There are numerous areas where gateways may be necessary in order to provide seamless service interaction, e.g. SMS interworking with IMS and CAP/IN service interworking with IMS. A full set of management tools is provided for the operation and maintenance of the Tieto gateway platform. Signaling Manager, an easy-to-use GUI and CLI is provided for configuration and control of the signaling subsystem. The signaling manager may also be loaded as an applet into a standard web browser such as Windows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace information to log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presented with signaling flows and a human readable format. Finally, an SNMP Agent is included for the generation of SNMP Traps in the event of failures within the signaling subsystem. For more details about the tools provided, refer to chapter 5.
4.1 Protocol Gateways 4.1.1 Signaling Gateway (SGW)

Tieto SGW is a complete carrier-grade signaling interface solution that provides interconnectivity between legacy SS7 domains and SIGTRAN domains. The Tieto Signaling Gateway is a distributed solution based on the Horizontal Distribution (HD) concept. Tieto SGW provides a signaling solution containing both hardware and software, targeting the following situations: Providing IP access to legacy SS7 nodes Providing legacy SS7 access for SIGTRAN-only nodes IP back-haul STP & SRP replacement
Signaling Gateway interfaces
This is an all-in-one Black Box solution built using carrier grade SW and HW components to ensure high availability and scalability. The hardware used in the SGW is based on CompactPCI build set and consists of the Stack-On-a-Card blades and Stack-in-a-Box family of chassis. By adding multiple SGW blades, higher traffic loads can be managed. Scaling over several blades is close to linear, the scaling factor being approx. 1.8 times/SGW Blade. page 35/55
The Tieto SGW delivers exceptionally high in-service performance, reaching 99.999% availability when using at least two SGW Blades either in separate 1U chassis or in a single 2U chassis. The Tieto Signaling Gateway product includes the following: SS7 Signaling Protocol Stack with support for IETF, ANSI, Chinese, ITU and TTC Standards. SGW Application SW Management and configuration tool able to run as standalone applications or within a web browser. SNMP support Hardware
4.1.1.1 Signaling Gateway (SGW) Architecture

The Signaling Gateway is built on the horizontal distribution (HD) SW architecture and is packaged as a standalone black box solution using Stack-on-a-Card and Stack-in-a-Box hardware, refer to chapter 2.5.1 and 2.5.2. For a description of software architecture, refer to chapter 2.1.
4.1.1.2 Application Programming Interface

O&M management C/C++ and Java 2SE API for integration with 3rd party management systems is available upon request.
4.2 Legacy Voice Gateways

Tieto Legacy Voice Gateways are a set of gateways that provide protocol interworking for legacy SS7 networks and the access network.
4.2.1 ISDN/PRI - ISUP Gateway (IGW-P)

The ISDN/PRI ISUP Gateway (IGW-P) acts as a protocol converter for basic call services between ISDN PRI accesses (e.g. PBXs) and SS7 ISUP interfaces. The IGW-P can, for instance, be used for providing ISDN PRI access for core network nodes (e.g. MSC, MGW, etc.), which provide support for ISUP SS7 voice trunks. The actual voice paths over B-channels and SS7-controlled voice trunks are separated from the signaling timeslots through multiplexor (MUX) equipment, which may be an integrated part of adjacent nodes, such as MGW or MSC, or separate external equipment. The MUXs extract the protocol data sent over the SS7 ISUP signaling links from the voice channels and PRI D-channel signaling from B-channel data into separate timeslots sent over an E1/T1 or SIGTRAN interface to the IGW-P for protocol conversion. After conversion, the protocol data is multiplexed back into the proper timeslots for forwarding to the ISDN equipment (e.g. PBX) and SS7 network node. Tone generation and detection, as well as routing number analysis, is performed by the PBXs and the adjacent SS7 exchange. For PRI ISDN, up to 248 D-channels may be converted using up to 8 E1/T1 PCM interface ports (31 Dchannels per E1, 24 D-channels per T1). The narrowband SS7 network access supports up to 4 E1/T1 PCM interface ports (max 31 per E1 port, 24 per T1 port) and 64 signaling links in total. The IGW-P hardware is based on the Compact PCI form factor.
page 36/55
IGW-P interfaces
IGW-P HW
A full set of management tools is provided for the operation and maintenance of the IGW-P. Signaling Manager, an easy-to-use GUI and CLI, is provided for the configuration and control of the signaling subsystem. The signaling manager may also be loaded as an applet into a standard web browser such as Windows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace information to log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presented with signaling flows and in a human readable format. Finally, an SNMP Agent is included to generate SNMP Traps in the event of failures within the signaling subsystem. For more details about the tools provided, refer to chapter 5. All software is packaged as RPM packages for easy installation and SW upgrade.
page 37/55
The IGW-P is a black box solution. MIBs are provided for integration with SNMP Manager and GUI/CLI for controlling the system. O&M management C/C++ and Java 2SE API for integration with 3rd party management systems is available upon request.
4.3 Unified Communication Gateways

The Unified Communication Gateways provide a complete system solution to allow interconnection between SIP-based enterprise network PBXs and operator networks. They can use either IMS network and/or legacy SS7 network as the integration point. The UC gateways are compliant with Microsoft OCS R2 and Lync Mediation Server for Unified Communications integration with operator networks and may easily be integrated with various PBXs, providing a SIP Trunk interface. The gateways come in two main flavours: SIP UC Gateway An all in one package, providing a SIP Trunk interface to PBXs with the ability to also integrate with legacy SS7 and ISDN networks, i.e. perform SIP SS7/ISDN protocol and media conversions. It can also integrate with IMS networks and combine IMS and legacy integration. SIP UC Session Border Controller (SBC) An all-IP gateway acting as a session border controller between SIP Trunks and providing necessary security mechanism towards enterprise SIP Trunks, as well as protocol and media conversion between different flavours of SIP Trunk and the IMS integration point.
4.3.1 SIP UC Gateway and Session Border Controller

The SIP UC Gateway product provides a complete system solution to allow interconnection between SIPbased enterprise network PBXs and operator networks. It can use IMS networks and/or legacy SS7/ISDN networks as the integration point. It is compliant with Microsoft OCS R2 and Lync Mediation Server for Unified Communications integration with operator networks, but can also be integrated with various PBXs, providing a SIP Trunk and/or ISDN interface.
SIP-UC gateway interfaces.
page 38/55
Depending on network integration scenario, the SIP UC gateway may include several components. The principle ones being: Media Gateway Controller (MGC), refer to chapter 4.3.1.1.1 Media Getaway (MGW), refer to chapter 4.3.1.1.2 SIP Back 2 Back User Agent (B2BUA), refer to chapter 4.3.1.1.3 SIP Session Border Controller (SBC), refer to chapter 4.3.1.1.4 SIP Telephony Announcement Server, refer to chapter 4.3.1.1.5 3rd party Call control Telephony Interface (CTI), refer to chapter 4.3.1.1.6 By combining the components a wide range of features are provided. Among these features are: SIP to/from SS7 ISUP protocol conversion according to RFC 3398 and ITU Q.1912.5 Multiple SS7 interface options: IETF SIGTRAN SS7 TDM Narrowband Links SS7 High Speed Links SIP signaling standard: SIP transport over UDP, TCP and TLS IETF RFC 3261 IETF RFC 3262 (i.e. reliable responses) IETF RFC 3264 (i.e. offer/answer) IETF RFC 3515 (i.e. REFER) IETF RFC 4028 (i.e. timer) IETF RFC 4566 IETF RFC 5373 (Answer modes) DTMF Info-Event Package draft-kaplan-sipping-dtmf-package-00. Provide DTMF using SIP INFO Call Services: User Authentication i.e. SIP Registrar User credentials stored permanently in database SIP REGISTER support with MD5 Digest authentication Call Redirection upon busy or no answer SIP 302 and diversion headers Call forking Call forking list for each user with groups Forking order according to priority Dynamic forking based on SIP registration Forking based on provisioned lists Dial Plan routing through regular expressions MS Lync integration option Header adaptation and suppression of unsupported SIP methods when integrating operator network with MS Lync Call Admission Control Customised service adaptation option 3rd party call control Playing and recording of announcements Media protocols: H.248 for controlling MGW page 39/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson 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) MAM 100 1000-105/101 V1.0 Public rd October 3 2012
A full set of management tools is provided for the operation and maintenance of the SIP UC Gateway. Signaling Manager, an easy-to-use GUI and CLI is provided for the configuration and control of the signaling subsystem. The signaling manager may also be loaded as an applet into a standard web browser such as Windows Explorer, Firefox, etc. Log daemons are provided for printing debug and signaling trace information to log files. The generated log files can be loaded into the provided Log Viewer, TvTool, where it is presented with signaling flows and in a human readable format. Finally, an SNMP Agent is included for the generation of SNMP Traps in the event of failures within the signaling subsystem. For more details about the tools provided, refer to chapter 5. page 40/55
4.3.1.1 SIP UC Gateway Architecture

SIP UC gateways share a common architecture and platform, and the software can be easily ported to various hardware environments. The hardware supplied by Tieto is built on industry-standard CompactPCI components with carrier-grade Linux OS, or on rack-mounted Linux servers. It consists of four principle HW components; Application Blade(s) Run-time environment for application signaling software and service control. These are Intel-based CPU architecture blades running MontaVista Carrier Grade Edition (CGE) 5 Linux. The Stack-ona-Card PP512 is the most common HW used as application blades. Media Gateway Blade(s) Provides media features, e.g. transcoding between codecs or RTP/SRTP, announcement and tone generation. The media blades also provide legacy interfaces for TDM and/or STM-1 terminations. The media blades are controlled from the application blades using H.248. IP Switching Blade(s) IP is used as the transport mechanism for communication between different application blades, control of media blades and between different media blades. The gateways may be ordered using integrated switches for switching traffic using the chassis backplane. For this, PICMG 2.16 is supported with up to 1 Gbit/s in the chassis backplane. Redundant layer 2 or layer 3 switches are supported depending on customer requirements. Chassis - Various sizes of chassis are available, ranging from 2U (4 slots) up to 4U (8 slots) chassis with integrated switches.
The smallest configuration consists of one application blade and one media blade. Several chassis can be interconnected to build larger systems
4U chassis with cPSB/Dual 6U Switch PICMG 2.16, 2 application blades, 2 Media Gateway blades and 1 IP Switch blade.
The following sub-chapters give a brief overview of the different system components.
4.3.1.1.1 Media Gateway Controller (MGC)

The MGC provides SIP and SS7 ISUP protocol interworking in accordance with RFC 3398 and ITU Q.1912, with various standard additions. It controls one or several Media Gateways using H.248. It is implemented as an application on top of the Tieto signaling stack, which provides the necessary signaling protocols and interfaces. For a general description of the signaling stack, refer to chapter 2. It executes on the application blades.
page 41/55
4.3.1.1.2 Media Gateway (MGW)

The MGW function is sourced through 3rd party suppliers, but as the MGW is controlled by the MGC using H.248, various suppliers products can easily be integrated. Tieto has currently integrated with the following MGW boards, which are available as off-the-shelf products and are pre-integrated in our chassis or standard PCs. AudioCodes TP-series TP-260, TP-1610, TP-6310 and TP-8410. AudioCodes IPM-series IPM-260, IPM-1610, IPM-6310 and IPM-8410. The range of boards enables the provision of 120 ports up to 2016 ports per board with support for E1, T1 and STM-1 interfaces. Multiple boards can be co-located within the same chassis or distributed over several chassis to create larger system configurations.
MGW blade, AudioCodes IPM-6310 series
4.3.1.1.3 SIP Back 2 Back User Agent (B2BUA)

In the context of UC Gateways, the B2BUA provides additional features, such as call routing, call forking and user authentication by acting as a Registrar for SIP UA terminals or PBXs. User credentials and forking lists are administered using the DB provided. It is the SIP integration point for the enterprise SIP Trunk and IMS network, and interfaces the MGC for legacy interworking. It allows for customized service development, such as header conversion and redirection services and executes on the application blades. SIP B2BUA features are described in chapter 3.4.
4.3.1.1.4 Session Border Controller (SBC)

The SBC option is a specialized version of the SIP B2BUA component that also has media control, providing SBC features for integrating enterprise SIP Trunks with IMS networks i.e. acting as an IP IP gateway. In SBC mode, the SIP B2BUA also controls MGWs using H.248 and thereby provides media features such as transcoding and encrypted media using SRTP. The SBC is also able to handle various flavours of SIP Trunk, such as the Microsoft Lync-supported subset of the SIP protocol. It executes on the application blades. page 42/55
4.3.1.1.5 SIP Telephony Announcement Server (TAS)

SIP Telephony Announcement Server (TAS) gateways allow users to record announcements and play announcements that are to be invoked in calls. The announcements are recorded on network-mounted disks and played via NFS streaming. Announcements may be stored on a customer-specific server or locally on the gateway. The announcement server is controlled via SIP. Announcement client SW may be included upon request.
4.3.1.1.6 3rd Party Call Control Telephony Interface (CTI)

Using the 3rd party call control telephony interface (CTI), application call control may be carried out for SIP UAs registered with the gateway via an API. The interface is uaCSTA-inspired and provides the following operations: Alternate Call Places an existing call on hold and retrieves a previously held call at a UA. Answer Call Answers an alerting call at a UA. Clear Connection Clears a connection at a UA. Consultation Call Places an existing call on hold at the UA and initiates a new call from the UA. Deflect Call Moves a connection away from the deflecting UA. The deflecting UA is no longer involved with the call after the Deflect Call service is completed. Hold Call Holds a call at the holding UA. Make Call Makes a call from an originating UA. Reconnect Call Clears an existing connected call and retrieves a call on hold at a UA. Retrieve Call Retrieves a call at a retrieving UA. Single Step Transfer Transfers a connected call to another device without placing the call on hold. The transferring UA is no longer involved with the call after this service is completed. Transfer Call Merges two calls at the UA into one call. Following the transfer, the device is no longer involved with the call. Monitor Start Establishes a device-type monitor on a UA. Monitor Stop Terminates an existing monitor.

UC gateways are black box solutions. MIBs are provided for integration with SNMP Manager and GUI/CLI for controlling the system. O&M management, C/C++ and Java 2SE API for integration with 3rd party management systems are available upon request. User administration is performed by interfacing the provided SQL DB. SIP B2BUA and SBC API for service implementation are available upon request.
page 43/55
5 Common Tools for Operation, Maintenance and Support for Tieto Signaling Products
The following sub-chapters provide an overview description of the supplied tools and their features. The diagram gives a high level overview of the common tools for Operation, Maintenance and Support for all Tieto Signaling Products that provide the same look and feel when combining multiple products.
High level overview of the common tools
5.1 Signaling Manager (GUI/CLI)

Signaling Manager is a node management tool that is used to configure and control Tieto Signaling Products. The Signaling Manager provides a Graphical User Interface (GUI) and a Command Line Interface (CLI) for the configuration and operation of the signaling system. The GUI can be executed, both as a standalone application and as an applet in a browser. The Command Line Interface (CLI) with command completion can be started as a standalone tool or run from within the GUI.
page 44/55
Through in-depth checking, customer problems can easily be resolved, thereby improving customer care and reducing configuration time. The main task of the Signaling Manager is to create/modify and manage signaling system configurations and provide an interface for controlling the system through commands (Actions). It can be started in both online and offline mode. In offline mode, users can prepare and create configuration files, perform validation and generate configuration data without access to a complete signaling system. In online mode, a connection to the signaling subsystem is set up and used. Configurations can be created, validated and stored in the local file system or in a remote file system using FTP or SFTP.
Signaling Manager snapshot Title Bar Shows the title, system standard and current file name. Menu Bar Provides access to basic Signaling Manager functions, such as creating, opening, saving and exporting configurations. Navigation Pane Contains all Elements that make up the configuration. It is built up as an easy navigation tree with automatic element names and search features. Operation Pane Consists of: Properties tab to view and edit properties. All properties have default values that reduce the number of configuration parameters that can be set manually. page 45/55
Actions tab to select and perform Actions (Orders) for an Element. Statistics tab to select and retrieve counters and statistical information. CLI tab to perform MML commands. CLI may also run as a standalone function. Information Pane Consists of: Description tab for viewing the description of a selected property. Log tab for logging information when debug is enabled. Results tab for viewing the result of a validation or search. Action Results for viewing the result of the performed action. Alarm for viewing current alarms and alarm notifications. Status Bar Displays status information about the connection to the signaling subsystem and overall subsystem status. Help Built-in online help.
Alarms to be activated are set using configuration settings
Alarm Tab Overview
page 46/55
Statistics Tab Overview
Audit logs are supported where all user commands and changes to configurations are logged to file system and may be viewed in the GUI.
Audit log In addition, support is also provided for different user access levels and these can be configured to prevent certain users gaining access to specific features. Each access level defines a particular set of SM capabilities. These are ordered from the minimum to the maximum, with each subsequent access level including access to the previous one.
5.2 TvTool Trace Viewer Tool

page 47/55
The Trace Viewer Tool, TvTool, provides full protocol decoding of the Signaling trace files produced by Tieto signaling products. It simplifies your analysis and shows the contents of your signaling log files in human readable format. It includes sophisticated message filtering functions, a message viewer for detailed information about all parameters in a selected protocol message, user-defined colour coding and an adaptable graphical user interface. It can be used offline or online to view an existing log file or view a log file from an executing stack with continuous real-time updates. It presents different types of event; Messages, Error, Trace / State & Event and Timers using different colours, messages to/from signaling network and internal messages are shown with arrows. Click on an arrow and the message is decoded in the decoding panel. It also provides a set of search functions to reduce the amount of work required to pinpoint problems using the system trace as input.
TvTool snapshot.
5.3 SNMP
The Signaling SNMP support consists of the master agent, Signaling SNMP System Monitor (3SM), as well as OS sub agents (Net-SNMP 5.1.2). The master agent listens for alarms from the Signaling system and processes/converts these into SNMP traps. The master agent also serves as a proxy for the OS sub agent,
page 48/55
with one sub agent being run on each Signaling host. Any external SNMP Manager only connects to the 3SM agent.
SNMP traps handling. Fault management can be split into alarms and events. Alarms are defined as error states that can be cleared. Alarms are reported using SNMP Traps. Errors that cannot be cleared, but instead only occur at an instant of time, are called Events. Events are only recorded in the event log. The log file contains time and date of the event, the level of severity and the message describing the event. Example;
26-Jun-2006 08:46:46 - [SEVERE] - SCTP Layer - Module is not started. 26-Jun-2006 08:46:51 - [CLEAR] - SCTP Layer - Module is started.
Alarms in the system are modelled using the framework outlined in ALARM-MIB, RFC3877. The concept is based on a table, alarmModelTable, storing a set of alarm lists. Each alarm can have multiple states (severities). An alarm represents an error state that can be cleared. When an alarm is active, an entry is added to the alarmActiveTable, and the alarm variables are added to alarmActiveVariableTable. When an alarm is cleared, it is moved to alarmClearTable. The alarm models use generic notifications - alarmActiveState and alarmClearState. When an alarm is raised, an alarmActiveState SNMP trap is issued. When the corresponding alarm is cleared, alarmClearState is issued. Note that alarms can have multiple severities (states). A transition from one state to another is also signalled using alarmActiveState.
page 49/55
Alarm handling tables An extension to the alarm MIB has been created, AlarmMibExt. This represents an extra conceptual column in the alarm model table. It is used to store a flag indicating whether the alarm should be enabled (on) or disabled (off). By setting this to 0 (off), the traps for a specific alarm are turned off. The NET-SNMP OS sub-agents support DISMAN-EVENT-MIB. They are configured to report four alarms. The traps sent out are received by the master agent and then forwarded to the trap listener. The source of the traps can be identified by inspecting the SNMP community string in the traps. The community strings have the name used by each Signaling host. The following alarms are pre-configured: CPU idle less than 5% (cleared when above 10%) Memory available less than 128MB (cleared when above 160MB) Disk use more than 80% (cleared when less than 70%) Network interface up/down (linkUp/linkDown) The SNMP Master Agent is a Java implementation. The alarm information presented in each trap reuses the naming convention created during system configuration using the Signaling Manager GUI/CLI. For this purpose, the SNMP Master agent accesses the configuration file(s) generated by Signaling Manager.
5.4 Alarm GUI Viewer

The Alarm Viewer GUI is a graphical tool for displaying active alarms received as SNMP Traps from the SNMP Master Agent. The tool displays all alarms that can occur in the system by connecting to the Signaling SNMP System Monitor agent ALARM-MIB alarms are displayed in a tree hierarchy. An additional list shows the different OS alarms received from the OS sub-agents
page 50/55
Alarm GUI Viewer The SNMP agent is implemented in Java and as a standalone application.
page 51/55
6 Professional Services 6.1 Installation

Tieto can assist and give customers organization a quick start when using Signaling Products, providing installation and run-time environment configuration services.
6.2 Training
To achieve a better and faster understanding of Tieto Signaling products, we provide standard or tailored training to our customers. Our standard training sessions cover areas such as general Signaling (SS7, SIGTRAN), installation, configuration and application programming. Most of our training sessions feature both theoretical and practical (exercises) elements. Tieto can also provide training on request, and courses can be tailored to a customers specific criteria.
6.3 Expert Consulting

Tieto has the expertise and procedures to assist in specific questions regarding Signaling Solutions. Sometimes, top-level expert advice is required. Tieto can provide this for shorter periods to assist in: Solutions specifications Presentations Design reviews - participating in technical discussions Customer discussions Interoperability tests are often required as part of an acceptance procedure. Tieto has the expertise and procedures to assist in or perform interoperability tests in labs or on site in conjunction with customers.
6.4 Maintenance & Support

Tietos Customer Support Centre provides a single point of contact for support and maintenance and offers the following services in accordance with the terms and conditions set out in Maintenance & Support Agreements: Basic Support telephone support, advice, and active participation in system problem analysis during normal business hours defined as Monday Friday 8:00 am to 5:00 pm CET. Repair or replacement of faulty hardware components, such as communications controllers. Correction of software and documentation errors. Distribution of maintenance releases. Customer web login for easy access to Signaling Products. Extended support outside normal business hours, e.g. helpdesk access on a 24/7/365 basis. On-site assistance.
page 52/55
7 Contacts
Please do not hesitate to contact us if you have any questions. We will be happy to assist you.
E-mail: signaling@tieto.com Website: http://www.tieto.com/signaling

Our office: Tieto Sweden AB P.O. Box 1038 SE-651 15 Karlstad Sweden Phone: +46 (0)10 481 0000
page 53/55
8 Acronyms and abbreviations

ANSI ANSI-41 API ATM AXE BICC BSC BSSAP CAMEL CAP CDMA cPCI CPU CS1 ETSI FPGA GSM GUI HA HLR IETF IN INAP IP ISR ISDN ISUP ITU M3UA MAP Mbps MGCP MSC MTP PCI PMC PSTN SCCP SCP SCTP SIGTRAN SIP SMS SMSC TCAP TDMA TTC American National Standards Institute ANSI standard 41 (Previously known as IS-41) Application Programming Interface Asynchronous Transfer Mode Ericsson switching platform Bearer Independent Call Control Base Station Controller Base Station System Application Part Customised Applications for Mobile network Enhanced Logic CAMEL Application Part Code Division Multiple Access CompactPCI Central Processing Unit Capability Set 1 European Telecom Standards Institute Field Programmable Grid Array Global System for Mobile communications Graphical User Interface High Availability Home Location Register Internet Engineering Task Force Intelligent Network Intelligent Network Application Protocol Internet Protocol In System Reconfigurable (hardware) Integrated Services Digital Network ISDN User Part International Telecommunications Union MTP-L3 User Adaptation Layer Mobil Application Part Megabit per second Media Gateway Control Protocol Mobile Services Switching Centre Message Transfer Part Peripheral Component Interconnect PCI Mezzanine Card Public Switched Telephone Network Signaling Connection Control Part Service Control Point Stream Control Transport Protocol Signaling Transport Session Initiation Protocol Short Message Service Short Message Service Centre Transaction Capabilities Application Part Time Division Multiple Access Telecommunications Technology Committee (Japanese standardisation body) page 54/55
Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson UMTS VoIP Universal Mobile Telecommunications System Voice over IP MAM 100 1000-105/101 V1.0 Public rd October 3 2012
page 55/55

Signaling Solution

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Signaling Solution

Uploaded by

Copyright:

Available Formats

Signaling Solution Description Telecom & Media, TGT Telecom Signaling Products & Solutions Anders G Karlsson MAM

100 1000-105/101 V1.0 Public rd October 3 2012

Signaling Solution Description

1.1 Signaling Solutions Overview

2 Signaling Stacks & Protocols

2.1 Horizontal Distribution

2.2 Application Programming Interface - API

2.2.1 C/C++ Programming Interfaces

Signaling API architecture

2.2.2 Java Programming interfaces

2.3 Portable Architecture

2.4 Supported Signaling Protocols

2.4.1 SS7 protocols

BSSAP Base Station System Application Part

ISUP ISDN User Part

2.4.2 SIGTRAN protocols

2.4.3 Radio Network Protocols

2.4.4 IMS Protocols

Bearer support UDP, TCP and/or SCTP TLS, IPSec, SigComp*

MAM 100 1000-105/101 V1.0 Public rd October 3 2012

UDP, TCP and/or SCTP TLS, IPSec

*available upon customer request

2.4.5 LTE protocols

SCTP Stream Control Transmission Protocol

3GPP TS 29.171 V9.1.0

2.5 Packaged Products

2.5.1 Stack-on-a-Card (SoaC)

2.5.2 Stack-in-a-Box (SiaB)

2.5.3 Signaling for Linux

2.5.4 Signaling for Solaris SPARC

2.5.5 Signaling for Solaris x86

2.5.6 Signaling for IBM AIX POWER

2.5.7 Signaling for AdvancedTCA

2.5.8 Communication Controllers

2.5.8.1 ISR PCIe

2.5.8.2 ISR PMC

2.5.8.3 ISR-PMC / PCI Adapter

2.5.8.4 ISR-PMC / PCI Express Adapter

2.5.8.5 ADAX HDC3 - 8 Trunk SS7 Signaling Controller

2.5.9 Available types of package licenses

3.1 Device Detection Application (DDA)

3.1.1 Application Programming Interface

3.2 SMS Component

3.2.1 Application Programming Interface

3.3 SS7 Monitor

SS7 Monitor interfaces

3.3.1 Application Programming Interface

3.4 SIP B2BUA Component

3.4.1 Application Programming Interface

3.5 Diameter Signaling Controller

3.5.1 Application Programming Interface

4 Tieto Gateway Platform

Tieto Gateway Platform components

4.1 Protocol Gateways 4.1.1 Signaling Gateway (SGW)

Signaling Gateway interfaces

4.1.1.1 Signaling Gateway (SGW) Architecture

4.1.1.2 Application Programming Interface

4.2 Legacy Voice Gateways

4.2.1 ISDN/PRI - ISUP Gateway (IGW-P)

4.2.1.1 Application Programming Interface

4.3 Unified Communication Gateways

4.3.1 SIP UC Gateway and Session Border Controller

SIP-UC gateway interfaces.

4.3.1.1 SIP UC Gateway Architecture