common channel signalling (mtp, sccp and tc)

Common Channel Signalling

(MTP, SCCP and TC)

DN98792452

Issue 12-0

2 DN98792452Issue 12-0

Common Channel Signalling (MTP, SCCP and TC)

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright Nokia Siemens Networks 2009/5/29. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangslufig bestimmte Teile der Gerte unter Span-nung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverlet-zungen und Sachschden fhren.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.

DN98792452Issue 12-0

3


Id:0900d8058052f12c

Table of ContentsThis document has 150 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 SS7 signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1 SS7 signalling network concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 SS7 signalling configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 SS7 signalling hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 SS7 network planning principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 SS7 network structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1 MTP level signalling network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 SCCP level signalling network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Creating MTP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.1 Activating MTP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Setting MTP level signalling traffic load sharing . . . . . . . . . . . . . . . . . . . . . 444.3 Creating large capacity signalling link (optional feature). . . . . . . . . . . . . . . 45

5 Creating SCCP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.1 Activating SCCP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Optimising MTP configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.1 Modifying MTP level 3 signalling parameters . . . . . . . . . . . . . . . . . . . . . . . 516.2 Modifying SS7 signalling network parameters . . . . . . . . . . . . . . . . . . . . . . 516.3 Modifying the values of signalling link parameter set . . . . . . . . . . . . . . . . . 526.4 Creating new signalling link parameter set . . . . . . . . . . . . . . . . . . . . . . . . . 536.5 Modifying the values of signalling route set parameter set . . . . . . . . . . . . . 546.6 Creating new signalling route set parameter set. . . . . . . . . . . . . . . . . . . . . 556.7 Setting and modifying MTP level signalling traffic restrictions . . . . . . . . . . 566.8 Modifying MTP level signalling traffic load sharing . . . . . . . . . . . . . . . . . . . 576.9 Using the signalling link set of another signalling network . . . . . . . . . . . . . 586.10 Removing MTP signalling point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Optimising SCCP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.1 Modifying SCCP signalling point parameter set . . . . . . . . . . . . . . . . . . . . . 627.2 Creating new SCCP signalling point parameter set . . . . . . . . . . . . . . . . . . 627.3 Defining SCCP signalling point and/or subsystem to own signalling point . 647.4 Removing SCCP signalling point and/or subsystem from own signalling point

657.5 Modifying the values of SCCP subsystem parameter set. . . . . . . . . . . . . . 667.6 Creating new SCCP subsystem parameter set . . . . . . . . . . . . . . . . . . . . . 677.7 Setting and modifying broadcasts of local SCCP subsystem . . . . . . . . . . . 687.8 Setting and modifying SCCP level signalling traffic restrictions . . . . . . . . . 697.8.1 Signalling point based traffic restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . 697.8.2 Calling GT checking based traffic restrictions. . . . . . . . . . . . . . . . . . . . . . . 707.8.3 GT based traffic restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.9 Creating and modifying called GT translation result and GT modification . 777.10 Creating global title analysis for called GT . . . . . . . . . . . . . . . . . . . . . . . . . 78

4 DN98792452Issue 12-0


Id:0900d8058052f12c

7.11 Creating calling GT routing configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8 Monitoring signalling network objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.1 Interrogating SS7 network configuration and signalling route set state . . . . 818.2 Interrogating and modifying signalling route state . . . . . . . . . . . . . . . . . . . . 818.3 Interrogating signalling link set state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.4 Interrogating and modifying signalling link state . . . . . . . . . . . . . . . . . . . . . 828.5 Interrogating MTP level load sharing and MTP level STP traffic restrictions828.6 Interrogating and modifying SCCP signalling point state . . . . . . . . . . . . . . . 838.7 Interrogating and modifying SCCP subsystem state . . . . . . . . . . . . . . . . . . 838.8 Interrogating SCCP subsystem broadcast status . . . . . . . . . . . . . . . . . . . . 84

9 SS7 troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859.1 Signalling link stays in state UA-INS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859.2 Failures in the signalling link terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879.3 Signalling route goes to or stays in state UA-INR . . . . . . . . . . . . . . . . . . . . 889.4 Signalling link fails occasionally or there is an unexpected reset of AS7. . . 899.5 Signalling link is in state UA-INS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899.6 Signalling link activation succeeds but traffic fails . . . . . . . . . . . . . . . . . . . . 909.7 All MTP and SCCP level objects are in state available (AV) but location update

fails or mobile calls are cut frequently after 4.5 min . . . . . . . . . . . . . . . . . . . 919.8 Global title translation fails although translation exists and the global transla-

tion result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919.9 State of all subsystems in the remote network element is unavailable (UA) al-

though MTP route set is in state available-executing (AV-EX) . . . . . . . . . . 949.10 Some remote subsystems do not recover after route set unavailability. . . . 949.11 A signalling point parameter or a subsystem parameter does not take effect as

described . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959.12 After updating DX software, the SCCP of own signalling point is in state un-

available (UA), although everything else is in state available (AV) . . . . . . . 959.13 SCCP screening does not come into effect . . . . . . . . . . . . . . . . . . . . . . . . . 969.14 TC sends an abort message with error code 03 "Incorrect transaction portion"

to the received dialogue request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969.15 Large capacity signalling link creation or modification fails . . . . . . . . . . . . . 979.16 Allowing of link activation and initialisation of signalling terminal fail . . . . . . 979.17 Activation of large capacity signalling link fails. . . . . . . . . . . . . . . . . . . . . . . 989.18 Bit rates of the signalling links in the same link set . . . . . . . . . . . . . . . . . . . 99

10 States of SS7 signalling network objects . . . . . . . . . . . . . . . . . . . . . . . . . . 10110.1 States of signalling route sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10110.2 States of signalling routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10110.3 States of signalling link sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10210.4 States of signalling links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10210.5 States of SCCP signalling points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10510.6 States of SCCP subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

11 Error messages of MTP commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10811.1 MTP command major errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10811.2 MTP command minor errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

DN98792452Issue 12-0

5


Id:0900d8058052f12c

12 SS7 signalling network parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12012.1 MTP level 3 parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12212.2 SS7 signalling network parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12612.3 Signalling link parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12912.4 Signalling route set parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13812.5 SCCP signalling point parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14412.6 SCCP subsystem parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

6 DN98792452Issue 12-0


Id:0900d8058052f12c

List of FiguresFigure 1 Example of two signalling end points (SEP) which transfer the signalling

messages through two signalling transfer points (STP) . . . . . . . . . . . . . 10Figure 2 The functional parts of the Nokia signalling system . . . . . . . . . . . . . . . . 11Figure 3 Signalling between two network elements and the STP in between. . . . 11Figure 4 Example of a signalling point which belongs to three different signalling net-

works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 5 Example of TDM-based signalling links . . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 6 The Transaction Capabilities scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 7 Signalling hardware used in different network elements. . . . . . . . . . . . . 14Figure 8 Basic mesh network structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 9 Case A: Two out of four inter-STP link sets deleted . . . . . . . . . . . . . . . . 20Figure 10 Case B: Link sets between STPs of the same pair deleted . . . . . . . . . . 20Figure 11 Case C: All the four inter-STP link sets between STPs of the same pair de-

leted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Figure 12 The example network (STP = Signalling Transfer Point, SEP = Signalling

End Point) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 13 Example of a message loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figure 14 Example network of the scenario for one directional signalling . . . . . . . 23Figure 15 Example network of the possible negative consequences of using load

sharing between routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 16 Two network elements with different SCCP subsystems . . . . . . . . . . . . 31Figure 17 Example of SS7 SCCP routing and global title analysis in the case of loca-

tion update (LOC.UPD.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figure 18 The points where the global tile translation is made (GTT 15) . . . . . . . 32Figure 19 The parts of the global title used in different global title translations . . . 32Figure 20 Use Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 21 Use Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 22 Example network where one network element belongs to two signalling

networks (NA0 and NA1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figure 23 Example network where the SCCP level signalling traffic restrictions is con-

figured. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

DN98792452Issue 12-0

7


Id:0900d8058052f12c

List of TablesTable 1 The services, their recommended names and parameter values given in

the NPC command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Table 2 States of the signalling routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Table 3 States of the signalling links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Table 4 States of SCCP signalling points . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Table 5 States of SCCP subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Table 6 Parameter levels, affected parts, and the MML commands to handle them

120Table 7 Signalling levels and their predefined parameter sets . . . . . . . . . . . . 121Table 8 Parameter files and their contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Table 9 MTP level 3 parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Table 10 CCS7 signalling network-specific parameters . . . . . . . . . . . . . . . . . . 126Table 11 Signalling link parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Table 12 Signalling route set parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Table 13 SCCP signalling point parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Table 14 SCCP subsystem parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

8 DN98792452Issue 12-0


Id:0900d8058052f12c

DN98792452Issue 12-0

9

Common Channel Signalling (MTP, SCCP and TC) Summary of changes

Id:0900d8058052f04b

Summary of changesChanges between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

Changes between issues 12-0 and 11-0In chapter SS7 Signalling Network Parameters, explanation about parameter C7 has been added.

Changes between issues 11-0 and 10-0In chapter SS7 Signalling Network Parameters, table Signalling route set parameters, the parameters D7 and D8 have been corrected, and parameter C7 has been added.

Changes between issues 10-0 and 9-1As the STP (SRRi) signalling routing is now based on SCCP CgPA, a new Section SCCP support for Feature 1679: Handling of forward-SMs in SRRi has been added to Chapter SCCP level signalling network.

10 DN98792452Issue 12-0


Id:0900d805802d3d5e

SS7 signalling

1 SS7 signallingAny transfer of data that enables speech and data connections between users is signal-ling. SS7 signalling has become the primary mode for signalling and information transfer in today's wireless and wireline networks. Information elements like calling party number, routing information related to 800 numbers, and current location information for roaming wireless subscriber are all carried over SS7 signalling networks.

In the Public Switched Telephone Network (PSTN), signalling is needed for call estab-lishing, call release, and call maintaining. In the wireless system, signalling can also be independent from speech. The different functions of signalling are call control, control of services, and charging control. Wireless networks have some special functions, such as location update, handover, subscriber administration, and short message service.

It is also possible to use SS7 signalling for non-call related signalling. In wireless systems, this feature is needed because the system has functions that are not con-nected to calls (for example, location updates and short message service). Furthermore, the operator can route signalling differently than in the case of a related call.

SS7 signalling provides also signalling error message handling. Error detection is done by including and interpreting a checksum within the message.

1.1 SS7 signalling network conceptsSignalling point (SP), signalling transfer point (STP) and signalling end point (SEP)A signalling point is a network element which sends and receives signalling messages. A network element can also operate as a Signalling Transfer Point (STP), which means that signalling traffic goes through the signalling transfer point towards the destination signalling point. There can be several signalling transfer points between two Signalling End Points (SEP).

Figure 1 Example of two signalling end points (SEP) which transfer the signalling messages through two signalling transfer points (STP)

The implementation of a signalling system in a Nokia network element consists of differ-ent functional parts. The main idea is that all functional parts offer their services to the other parts. In the following figure, the functional parts that are under some other part serve the part above. For example, the Operations, Maintenance and Administration Part (OMAP) uses the services of the Transaction Capabilities (TC), the TC uses the services provided by the Signalling Connection Control Part (SCCP), and the SCCP uses the services of the MTP.

SEP SEPSTP STP

DN98792452Issue 12-0

11

Common Channel Signalling (MTP, SCCP and TC) SS7 signalling

Id:0900d805802d3d5e

Figure 2 The functional parts of the Nokia signalling system

All parts do not necessarily exist in every network element. A signalling transfer point does not need to have all the functional parts that signalling end points have. Two dif-ferent network elements can exchange SS7 signalling even when only the minimum configuration exists in both elements.

For example, if network element A has MAP and operates with network element B, then both elements have to have an MAP, TC, SCCP and MTP configuration, but in the STP between A and B there can be only an MTP, or an MTP and an SCCP configuration.

Figure 3 Signalling between two network elements and the STP in between

Signalling network and signalling point code (SPC)A network element can operate in a maximum of 4 signalling networks. Every network element has a signalling point code in every network it belongs to. The signalling point code (the number given to the signalling point) itself can be the same in each network. The following is an example where one network element belongs to three signalling net-works. In the example, there is a different signalling point code for each network.

OMAPBSSAP

SCCP

TUP/ISUP/PUP/PUPX

INAP

MAP

TC

MTP

Network element A Signalling transfer point Network element B

RNSAP

SCCP

MTP

SCCP

MTP

RNSAP

SCCP

MTP

12 DN98792452Issue 12-0


Id:0900d805802d3d5e

SS7 signalling

Figure 4 Example of a signalling point which belongs to three different signalling networks

Signalling linkSignalling points are connected together with PCM circuits. One PCM has 32 time slots (TSL). Each signalling link reserves one time slot from one PCM.

Figure 5 Example of TDM-based signalling links

1.2 SS7 signalling configurations

Message transfer part (MTP)The Message Transfer Part can be divided into three levels:

Signalling Data Link level (level 1) defines the physical, electrical, and functional characteristics and the physical interface towards the transmission media.

Signalling Link level (level 2) defines the functions considering message transfer between two adjacent network elements through a signalling link. It defines the message structure, framing, error detection and correction, alignment procedures, and so on.

Signalling Network level (level 3) can be divided into two parts: message handling, which includes message routing and distribution to the respective user part, and network management, which provides all the necessary procedures for using the signalling network in an optimal way.

NA1IN0

NA0

IN0:SP=

80122

NA1:SP=80001

IN0:SP=80125

NA0:SP=80101

NA1:SP=

80005

NA0:SP=

80105

PCM=75, TSL=1

PCM=77, TSL=1

NA1:SP=

80115

NA1:SP=

80125

DN98792452Issue 12-0

13


Id:0900d805802d3d5e

When configuring and using MTP in a Nokia network element, you do not need to rec-ognise the levels at all.

Signalling connection controlling part (SCCP)The Signalling Connection Control Part provides two different services, the connection-oriented and the connectionless services for other applications. The SCCP itself uses the MTP as a service.

The connection-oriented network service is used for virtual connections between network elements and it provides the procedures for the establishment and release of those virtual connections.

The connectionless network service enables non-call related communication between network elements which have to exchange information only for short periods. Furthermore, the connectionless service provides a global title translation function, which enables communication with network elements in other signalling networks.

For example, in the MSC/HLR the Mobile Application Part (MAP) uses the connection-less service of the SCCP and Base Station Application Part (BSSAP) uses the connec-tion-oriented service of the SCCP.

Transaction capabilities (TC)The purpose of Transaction Capabilities (TC) is to offer logical connections, that is, transactions, to TC users. These transactions are used to transfer the components by which the TC conveys a request to perform an operation, or a reply, between two TC users situated in different network elements. A TC user uses the network services of the signalling system through the TC. From the point of view of network services, the TC is a direct tube between a TC user and the SCCP.

The TC protocol is implemented in the Nokia network element through two different pro-cesses: one which complies with the ITU-T Q.771 - Q.775 recommendations and another one which complies with the ANSI T1.114 recommendations. The programs can operate in a network element simultaneously or individually.

The TC realises the services by using the network services provided by the SCCP in the common channel signalling system. Only the transfer mode using connectionless network services is specified for the TC. Both the segmenting and the non-segmenting SCCPs can be used.

The TC is part of the protocol but you do not have to configure it separately since the TC is used automatically when needed.

Note that the use of the TC does not need any configuration or other actions by the oper-ator.

Figure 6 The Transaction Capabilities scheme

SCCP

MAP INAP OMAP

ITU-T TC ANSI TC

14 DN98792452Issue 12-0


Id:0900d805802d3d5e

SS7 signalling

Operations, Maintenance and Administration Part (OMAP)The Operations, Maintenance and Administration Part (OMAP) is defined in the ITU-T recommendation Q.795, Q.750-Q755 and in the ANSI Recommendation T1.116. The OMAP makes it possible to set regular signalling network tests between specified sig-nalling points.

The MTP Routing Verification Test (MRVT) procedure has been implemented in the Nokia network element. This makes it possible to check if message routing functions properly in the signalling points. In the MRVT procedure, the system sends test messages to a destination signalling point by using different signalling routes. The test messages can pass through signalling transfer points (STPs). A test is conducted suc-cessfully if replies to the sent messages are received within the specified time. If the test fails, the system produces a report that explains the reason for the failure.

1.3 SS7 signalling hardwareThe hardware used by signalling consists of signalling units, signalling link terminals, and Common Channel Signalling Management Units. Signalling units take care of the actual signalling, which is then transmitted to the trunk circuits by the signalling link ter-minals.

Signalling unitA signalling unit is dependent on the type of the network element. On a fixed network element (PSTN), the Common Channel Signalling Unit (CCSU) is used as the signalling unit. The signalling unit of a Mobile Switching Centre (MSC) is a CCSU unit in the fixed network direction and a Base Station Signalling Unit (BSU) in the direction of the Base Station Controller (BSC). The signalling unit used by the Base Station Controller (BSC) is a Base Station Controller Signalling Unit (BCSU).

Figure 7 Signalling hardware used in different network elements

Signalling link terminalA signalling link terminal is an entity composed of hardware and software, and it imple-ments MTP level 2 functions. There are several types of signalling link terminals avail-able: they are the different variants of AS7 plug-in units. There are different types of AS7

PSTN

CCSU

CCMU

HLR

CCSU

CCMU

BSC

BCSU

MCMU

MSC

CCSU

CCMU

BSU

DN98792452Issue 12-0

15


Id:0900d805802d3d5e

variants of DMC-bus and PCI-bus based network elements. AS7 types with large capacity (for example, AS7V, AS7A, and AS7C) support also large capacity links (optional feature), that is, speed up to 1984 kbit/s. Signalling link terminals are linked to the signalling unit, and there can be several terminals per unit.

Common channel signalling management unitThere are two different common channel signalling management units used in different Nokia network elements. The Common Channel Signalling Management Unit (CCMU) is used in fixed switching (PSTN) and mobile switching (MSC/HLR) network elements and the Marker and Cellular Management Unit (MCMU) is used in the Base Station Con-troller (BSC).

Small network elements do not necessarily need a separate CCMU, but the tasks can be divided between the central memory (CM) and the statistical unit (STU). In small network elements, the management data on the common channel signalling can be stored in the central memory.

Common Channel Signalling Unit (CCSU)There are two different common channel signalling management units used in different Nokia network elements. The Common Channel Signalling Unit (CCSU) is used in fixed switching (PSTN) and mobile switching (MSC/HLR) network elements and the Marker and Cellular Management Unit (MCMU) is used in the Base Station Controller (BSC). Small network elements do not necessarily need a separate CCMU, but the tasks can be divided between the Central Memory (CM) and the Statistical Unit (STU). In small network elements, the management data on common channel signalling can be stored in the central memory.

Base Station Signalling Unit (BSU)The BSU controls mobile and base station signalling (Base Station System Applcation Part, BSSAP), takes care of the decentralised functions of the Message Transfer Part (MTP) and the Signalling Connection Control Part (SCCP) of the signalling system, and is responsible for handling the signalling messages and functions related to the signal-ling channels connected to it.

The BSU is backed up using the N+1 method, which means that several BSUs can be linked to the same back-up unit. In fault situations, the spare unit takes over the tasks of the failing unit.

Common Channel Signalling Management Unit (CCMU)The CCMU implements the functions of the Message Transfer Part (MTP) and the Sig-nalling Connection Control Part (SCCP) in the CCS signalling network of the Nokia system built in accordance with the ITU-T specifications concerning signalling system number 7.

The CCMU is backed up with a spare unit that is in hot stand-by mode, so that the changeover to the spare unit does not disturb the functions of the other parts in the sig-nalling network.

Base Station Controller Signalling Unit (BCSU)The BCSU implements the functions of the Message Transfer Part (MTP) and the Sig-nalling Connection Control Part (SCCP) in the CCS signalling network of the Nokia system built in accordance with the ITU-T specifications concerning signalling system

16 DN98792452Issue 12-0


Id:0900d805802d3d5e

SS7 signalling

number 7. It also implements the needed signalling functions towards the base station (BTS).

Central memory (CM)The main memory is a unit in the control part of the Nokia network element. The main memory (of the microcomputer) stores the subscriber data, charging and billing data, signalling data, and configuration data of the network element as semi-permanent files.

DN98792452Issue 12-0

17

Common Channel Signalling (MTP, SCCP and TC) SS7 network planning principles

Id:0900d8058026efb3

2 SS7 network planning principlesRequired information for planning SS7 signalling networkTo plan a whole signalling network you have to have experience in telecommunications and professional knowledge about signalling systems.

Before the SS7 configuration is created, the whole signalling network has to be planned carefully. The following issues have to be defined before the SS7 signalling configura-tion can be created:

signalling point code allocation scheme from telecommunications administration, that is, the signalling point codes to be used in the own signalling network

format of signalling point code (SPC): length 14, 16, or 24 bits, and if the signalling point code should be allocated into subfields, for example, 3-8-3 bit or 8-8-8 bit format (see ITU-T Q.708)

physical transmission paths between different network elements Signalling Link Code (SLC) and time slot (TSL) mapping to identify the signalling

links within a link set type and amount of signalling traffic in order to define the link set size between two

network elements if there are any restrictions concerning other vendors' interconnecting network

elements (if they are compatible with, for example, the ITU-T, ANSI, or JAPAN spec-ifications.)

connection management and circuit supervision messages (CCM) network structure concerning Signalling End Points (SEP) and Signalling Transfer

Points (STP) if there is a need for policing (screening) if there is an SCCP network configured in the MTP network, and the requirements

set by it which are the network elements in the signalling network where the SCCP exists what applications (SCCP subsystems) exist in different network elements and what

kind of addressing (GT or SPC and SSN) is used to send messages to them what kind of global titles are used (for example, if roaming agreements and used IN

services affect global titles) if there are any restrictions concerning timer values, address field of messages or

management procedures for interconnected network elements made by other vendors

18 DN98792452Issue 12-0


Id:0900d805803e7764

SS7 network structures

3 SS7 network structuresThe signalling system can be used with different types of signalling network structures. The choice between the different types of signalling network structures can be influ-enced by factors, such as administrative aspects and the structure of the telecommuni-cation network to be served by the signalling system.

If the provision of the signalling system is planned on a per signalling relation basis, the result is a signalling network largely based on associated signalling, typically supple-mented by a limited degree of quasi-associated signalling for low volume signalling rela-tions. The structure of such a signalling network is mainly determined by the patterns of the signalling relations.

Another approach is to consider the signalling network as a common resource that has to be planned according to the total needs of common channel signalling. The high capacity of digital signalling links in combination with the needs of redundancy for reli-ability typically leads to a signalling network based on a high degree of quasi-associated signalling with some provision for associated signalling for high volume signalling rela-tions. The latter approach to signalling network planning is more likely to allow exploita-tion of the potential of common channel signalling to support network features that require communication for purposes other than switching of connections.

The signalling network structures presented in this section is based on ITUT Recom-mendations Q.705Q.706, Blue Book.

Availability of the networkThe signalling network structure must be selected to meet the most stringent availability requirements of any user part served by a specific network. The availability of the indi-vidual components of the network (signalling links, signalling points, and signalling transfer points) must be considered in determining the network structure (for more infor-mation, see ITUT Recommendation Q.709).

Pay attention to the STP routing tables to ensure that circular routing does not occur.

Message transfer delayWhen structuring a particular signalling network, the overall number of signalling links (where there are a number of signalling relations in tandem) related to a particular user transaction (for example, to a specific call in the telephone application) has to be con-sidered (for more information, see ITUT Recommendation Q.706).

There must be as few signalling transfer points as possible in the signalling network.

Signalling link loadWhen estimating the need for signalling links, it is recommended that one signalling link load does not overrun 0,2 Erl (Erlang is the unit of measure of the carried traffic inten-sity). In satellite links, the signalling link load has to be under 0,06 Erl. For an example, on calculating the signalling link load, see Section Measuring signalling link load in NSS Statistics.

Message sequence controlFor all messages for the same transaction (for example, a telephone call), the MTP maintains the same routing if the connection remains functional, provided that the same signalling link selection code is used. However, a transaction does not necessarily have to use the same signalling route for both forward and backward messages.

DN98792452Issue 12-0

19

Common Channel Signalling (MTP, SCCP and TC) SS7 network structures

Id:0900d805803e7764

Number of signalling links used in load sharingThe number of signalling links used to share the load of a given flow of signalling traffic typically depends on the following:

the total traffic load the availability of links the required availability of the path between the two signalling points concerned the bit rate of the signalling linksLoad sharing requires at least two signalling links for all bit rates, but more links are nec-essary at lower bit rates.

When two links are used, each of them has to be able to carry all the signalling traffic in case the other link fails.

Basic network structuresThis is an example of the basic mesh network structure and three simplified versions derived from it. More complex signalling networks can be built by using these models as building components.

Figure 8 Basic mesh network structure

In this example network, each signalling point with level 4 functions is connected by two link sets to two signalling transfer points. Each pair of signalling transfer points is con-nected to every other pair by four link sets. There is a link set between the two signalling transfer points in each pair. The simplified versions (A, B, and C cases) of the basic sig-nalling network are obtained by deleting the following, respectively:

in the case of A, two out of the four inter-signalling transfer point link sets in the case of B, the link sets between the signalling transfer points of the same pair in the case of C, two out of the four inter-signalling transfer point link sets and the

link sets between signalling transfer points of the same pair

In connection with the availability of a given signalling link, it is considered that the more signalling link sets are removed from the basic signalling network (going from the basic mesh network to the A, B, and C cases), the lower the availability of the signalling network is. However, an increase in the availability of the simplified signalling network can be attained by adding one or more parallel signalling links to each of the remaining signalling link sets.

SEP signalling end point

STP signalling transfer point

SEP

STP STP

STPSTP

SEP

20 DN98792452Issue 12-0


Id:0900d805803e7764


Figure 9 Case A: Two out of four inter-STP link sets deleted

Figure 10 Case B: Link sets between STPs of the same pair deleted

Figure 11 Case C: All the four inter-STP link sets between STPs of the same pair deleted







SEP

STP STP

STPSTP

SEP

SEP

STP STP

STPSTP

SEP

SEP

STP STP

STPSTP

SEP

DN98792452Issue 12-0

21


Id:0900d805803e7764

3.1 MTP level signalling networkBasic structuresThe MTP gives you many possibilities to configure the network. It is possible to create up to eight signalling routes to each destination and these routes can work in load sharing mode or backup mode. Consider carefully whether it is necessary to use more than three routes because, in this case, the management of the whole network becomes very complex. The use of load sharing between signalling routes also needs careful planning because it affects the adjacent signalling points and their opportunities to use alternative routing. Typically, load sharing between signalling routes is used in Sig-nalling End Points (SEP) if it is used in the Signalling Transfer Points (STP). The risk of message loops increases especially in larger networks if the network topology has not been planned carefully.

When signalling routes are defined, it must be understood that the whole path across the network cannot be defined at the originating signalling point. Only the destination point and the adjacent signalling transfer point are defined. The adjacent STP further routes the messages according to its own routing rules. The message originator cannot determine it. For example, in Figure The example network (STP = Signalling Transfer Point, SEP = Signalling End Point), when the signalling routes from SP A to SP D are defined, SP A does not know how SP B is routing the messages originated from A further to D: either directly to D or through some STP X.

Figure 12 The example network (STP = Signalling Transfer Point, SEP = Signalling End Point)

MTP load sharingLoad sharing between signalling routes is defined when the signalling route set is created, and it can be modified afterwards with the NRB command. Route priority is important in load sharing (priority varies from 0 to 7; 7 is the highest priority). The route with the highest priority carries the traffic. If there are two or more routes with the same

SEPA

STPC

SEPD

STPB

STPX

22 DN98792452Issue 12-0


Id:0900d805803e7764


priority, they work with load sharing if it is allowed. If load sharing is denied, each priority must be defined only for one route, because if the same priority is defined for several routes, it is not possible to know, which route becomes active (the route that becomes available first enters state AV-EX and the others enter state AV-SP). Within a link set, signalling traffic is always shared across all the available signalling links, so the priority of the signalling link has no effect there (according to Signalling Link Selection Field (SLS) values).

As a general rule, the highest priority is assigned to the direct route (the route using the link set which connects the originating signalling point to the destination signalling point) and the second highest priority is assigned to the route which is selected to be the primary alternative if the direct route fails, and so on. If there is no direct route (only routes through the STP), it is useful to choose the priorities so that the signalling rela-tions in both directions use the same path (Example Scenario for message loop). Oth-erwise, you can end up with one-direction-signalling (Example Scenario for one directional signalling) which can cause more disturbance than no signalling at all.

Example: Scenario for message loop

Figure 13 Example of a message loop

Configuration in the example network:

Route set from A to D: direct route with priority 7 and indirect route through STP B with priority 7.

Route set from B to D: direct route with priority 7 and indirect route through STP C with priority 7, load sharing allowed.

Route set from C to D: direct route with priority 7 and indirect route through STP A with priority 7, load sharing allowed.

Problem:

In a configuration, when a message comes to any of the STP points (A, B, C), the result is a message loop C A B C .... for certain parts of the traffic (messages with certain SLS codes).

STPC

SEPD

STPB

STPA

loopprior.=7

prior.=7

prior.=7

prior.=7

prior.=7prior.=7 STPC

SEPD

STPB

STPA

1) 2)

DN98792452Issue 12-0

23


Id:0900d805803e7764

Example: Scenario for one directional signalling

Figure 14 Example network of the scenario for one directional signalling


Route set from A to D: direct route with priority 7 and indirect route through STP B with priority 6.

Route set from D to A: direct route with priority 7 and indirect route through STP C with priority 6.

Problem:

If link set A-D fails, the SP A routes messages destined to D through B and the SP D routes messages destined to A through C. If link set C-D fails (or alternatively, SP C sends a transfer prohibited (TFP) message to SP D concerning SP A), link set A still routes messages destined to D through B, but D can no longer reach A.

STPC

SEPD

STPB

STPA

STPC

SEPD

STPB

STPA

1) 2)

prior.=7

prior.=7

prior.=6

prior.=6

24 DN98792452Issue 12-0


Id:0900d805803e7764


Example: Possible negative consequences of using load sharing between routes

Figure 15 Example network of the possible negative consequences of using load sharing between routes


Route set from A to D: direct route with priority 7 and indirect route through STP B also with priority 7, load sharing mode allowed in the route set.

Route set from D to A: direct route with priority 7 and indirect route through STP B with priority 7, load sharing mode allowed in the route set.

Problem:

This kind of configuration (stage 1) causes a short unnecessary break in the signalling traffic from B to D.

If link set B-D fails, STP B sends a TFP message (concerning D, stage 2) to STP A. After a forced rerouting (stage 3), SEP A sends a TFA message (concerning D, stage 4) to STP B, and then STP B can access SEP D.

MTP level STP traffic restrictionsWith the MTP level STP traffic restrictions, you can define how unauthorised STP messages are identified and how they are treated. Messages are either transferred further or destroyed. It is also possible to define if an alarm indication is set.

Administrators can make bilateral agreements on how to operate SS7 signalling between their networks. These agreements can replace restrictions on the SS7 messages authorised for one administrator to send to the other. Restrictions can be made, for example, because of network security or as a result of service restrictions. Unauthorised signalling traffic can be, for example, STP traffic for calls set up through networks other than the one containing the STP, which has not been agreed bilaterally.

An administrator making an agreement on restrictions can wish to identify and provide special treatment to unauthorised SS7 messages.

SEPD

STPB

STPA

1)

prior.=7

prior.=7

prior.=7 prior.=7

SEPD

STPB

STPA

2)

SEPD

STPB

STPA

3)

TFA(conc. D)

SEPD

STPB

STPA

4)

TFP(conc. D)

FR

DN98792452Issue 12-0

25


Id:0900d805803e7764

Allocation of signalling point codesUsually, the national telecommunications authorities allocate a certain range of signal-ling point codes for each of you, and you can use those point codes within your own networks as you wish. It is also possible to use some other network indicators apart from the PSTN network within your own network and it enables to have more network elements connected (for example, in the GSM network BSCs are working in the NA1 network, while the signalling point codes of the NA0 network are allocated only for MSCs and HLRs).

You have to take the national instructions into account when allocating the signalling point codes in your signalling network.

Signalling parameters and parameter setsThere can be some network elements in the network which work according to some older specifications or which have some restrictions on their functions (for example, it is forbidden to send a Traffic Restart Allowed (TRA) message to an adjacent network ele-ment), and these cases must be examined before the network is configured. In a Nokia network element, it is possible to define parameters which are related to signalling network, signalling route sets, or signalling links. With proper settings, a Nokia network element is compatible with most network elements.

With the signalling parameters, it is possible to control and modify certain functions of the signalling network. The signalling parameters are divided into six different levels, depending on which part of the signalling system they affect.

For some levels, it is possible to define a number of special parameter sets. The param-eter sets can be connected so that different parts of the signalling system use different parameter sets, that is, it is possible to use different kinds of signalling in different direc-tions.

For example, there can be two different signalling link parameter sets defined, one con-nected to the signalling links leading to network element X and another connected to the signalling links leading to network element Y. In this case, signalling functions are differ-ent towards network element X, than towards network element Y.

In the Nokia system, there are some parameter sets predefined for different SS7 signal-ling standards (for example, ITU-T, ANSI, JAPAN). It is recommended to use these parameter sets or at least to start with them. If there is a need to change them, it is rea-sonable to create a new one on the basis of the predefined one.

Additional signalling point codesUsually, the national telecommunications authorities allocate a certain range of signal-ling point codes for each of you and you can use those point codes within your own network. Though you have to take into account the national restrictions when allocating the signalling point codes in your networks, it is possible to use some unused network indicators within your own networks. But even when this is not possible, there are usually free signalling point codes available to bring additional value to you. Nokia Siemens Networks has implemented the Additional Own Signalling Point Codes func-tionality designed to increase the signalling capacity between two (or more) network ele-ments.

The Additional Own Signalling Point Codes functionality is implemented on the MTP level. Since the functionality has not been implemented on the SCCP level, it offers only

26 DN98792452Issue 12-0


Id:0900d805803e7764


limited value to applications using SCCP addresses in DPC format. But since very few applications are tied to using SCCP addresses in DPC format, the majority of SCCP users can benefit from the feature when routing their messages based on Global Title (as subsystem states, and so on, maintained by SCCP management have no effect). The fact that each additional own signalling point code occupies one out of the 1000 DPCs supported is also a real limitation to very few applications (if any).

The MTP level supports four different types of additional own signalling point codes:

Reception Additional Point Code User Part Additional Point Code Interworking Function Additional Point Code Private View Additional Point Code In the receiving direction, all the additional own signalling point code definitions above make the MTP recognise the concerned signalling point code as an address of the own network element. In the outgoing direction, each DPC can be connected to one addi-tional own signalling point code, other than Reception Additional Point Code. Such def-initions guide the MTP to replace the originating point codes of User Part messages sent towards the DPCs with the additional own signalling point codes.

There are also other types of signalling point codes which make the MTP alter the OPC field of signalling messages and which are connected to additional own signalling point codes:

Test Routing Signalling Point Code Management Cluster Signalling Point Code Inverted View Signalling Point CodeThey have been designed to bring additional functionality to the operator networks, but not necessarily to increase signalling capacity between two (or more) network elements.

Additional own signalling point code operationThe four types of additional own signalling point codes that the Nokia Siemens Networks system supports have been designed to bring additional value as follows:

User Part Additional Point Code makes it possible to create more than 4096 speech channels between two network elements.

Interworking Function Additional Point Code makes it possible to create two (or more) signalling link sets between two network elements if the capacity of the 16 sig-nalling links is not enough.

Private View Additional Point Code makes it possible to create more than 4096 speech channels and more than 16 signalling links between two network elements even if the partner NE offers nothing special to help in these respects.

Reception Additional Point Code makes it possible to have the MTP share the load of signalling destined to the STP pair both (or all) of whose members deliver the messages to the appropriate User Parts for further actions (such as GT analyses).

Inverted view signalling point code operationFor example, in the SRRi the user part keeps contacting the register which processes its database query and updates messages. If this register has an HLR as a backup NE, both members of the mated pair HLR have this processing capability but only one of them is active at a time. The active register which receives the User Part database update messages keeps its database up-to-date and transfers the updates to the redun-

DN98792452Issue 12-0

27


Id:0900d805803e7764

dant register through the NEMU functionality. The redundant register becomes active only when the connection between its pair and the SRRi is lost.

The mated pair HLR can recover from failure and can change the direction of register updates automatically. In order to support this, the MTP does not need to provide only the Reception type additional point code functionality, but also the Inverted View signal-ling route sets. In a redundant HLR, the MTP notices from received signalling that the connection between the active HLR and the SRRi is lost and indicates this to the signal-ling route states in the Inverted View signalling route set. The NEMU functionality keeps inquiring the states of objects related to the Inverted View signalling route set from the MTP functionality, so it can make the previously redundant register active and can change the direction of register updates soon after the failure.

Management cluster operationThe signalling management cluster is an entity which consists of Signalling Gateway and Application Node but is visible to other network elements only with the Application Node signalling point identity. The MTP level 2 connections and other MTP functional-ities of a signalling management cluster are in the Signalling Gateway, while the User Part functionality of the cluster is in the Application Node. When the MTP of the Signal-ling Gateway receives a User Part message destined to the management cluster, it forwards the message to the Application Node.

The signalling management cluster is recommended when a signalling point becomes an Application Node as it is connected to a Signalling Gateway and, therefore, stripped of its MTP level 2 connections to other network elements. Then, other network elements need no configuration changes as they see nothing from the management cluster but the same old signalling point code. One practical example of transition from signalling points to signalling management clusters is the migration from Mobile Switching Services Centres to MSC Servers and Multimedia Gateways.

Loop signalling route conceptA network element can simulate several network elements by using Test Routing sig-nalling route sets. A Test Routing signalling route set consists of a direct route through a link set the messages of which are looped either physically or by a software. If the loop is physical, the route set is called L-LOOP and the signalling links in the direct route have to be in active state, whereas loop by software (T-LOOP) does not require concerned links to be in service. In a Test Routing route set like this, the signalling messages are transferred from one signalling unit to another along a message bus. You can select any free address from the signalling destination point range used by the signalling network and define it as the loop route point address. The number of loop signalling route sets is not restricted.

The loopback feature used by the TUP/ISUP needs two loop signalling route sets in call setup. The initial messages of a call are sent to the first loop signalling route set and the same message returns to the home network element with the point code of the other loop signalling route set as its originating point code. This gives the user an impression that the own point starts a call to the first point and the second point starts a call to the own point.

The loopback feature is activated and the type of the loop is chosen when the signalling route set is created with the commands of the NR Command Group.

28 DN98792452Issue 12-0


Id:0900d805803e7764


Signalling cluster concept and partial routingIn the ANSI signalling network, several nodes of the same signalling network can be gathered from a cluster in MTP-level routing when the point codes of the nodes share the same initial part. The whole cluster is referred to with a point code, in which, after the same initial part, the rest consists only of zeros. The length of the common initial part can be 8 or 16 bits. The length of the signalling point code is 24 bits.

The ANSI signalling network can use a destination point that belongs to a cluster, so that the common routing regulations are determined for the members of the cluster. An STP network element of the MTP level can route forward a signalling message even if it does not identify the destination of the message, provided that the route to the cluster that includes the destination point has been given to the network element.

In the Nokia system, the cluster is divided into three parts. The clusters are categorised according to the restrictions based on their locations:

cluster E (end-point view of remote cluster) Cluster E is a collection of routes without priorities, on the basis of which the CCDESM transforms the received network management messages addressed to the whole cluster into messages addressed to the individual members of this cluster. Cluster E can only be accessed through STPs and the full point identifier of the members of the cluster must be known. The own point handles a cluster of type E without notifying its adjacent points of the changes in states concerning cluster E or the availability of the cluster. The adjacent points are notified of changes in the states and the availability of the individual members of the cluster. Clusters of type E can be created in the Signalling End Points (SEP) and in the Signalling Transfer Points (STP). The signalling route set to cluster E is created by creating a route through the actual own point of an STP pair to its alias point. Messages cannot be sent to the members of cluster E by means of partial routing.

cluster C (cluster of another STP) When partial routing is used, a signalling route set of cluster C must be created. In this case, there is no need to know the full signalling point code of an individual signalling point of a cluster, and messages can be sent to this signalling point, provided that cluster C is available. It is not allowed to determine any full signalling point codes of a signalling point that is a member of cluster C. Changes in states of cluster C that are determined in an STP are notified in the TCP and TCA messages.

cluster B (broadcast address of local cluster) Cluster B means that an own signalling point functions as one part of an STP pair and with its pair, recognises all the members of the cluster. A member of an STP pair notifies the availability of the cluster with TCP and TCA messages when the last member of the cluster becomes unavailable or when the first member of the cluster becomes available. If either member of the STP pair notices that it can no longer access any member of cluster B, it sends the adjacent points a TCP message concerning the cluster. This means that cluster B is not available for its adjacent points, even if the members of cluster B were available through another STP pair. A TCA message is sent when the STP pair that has sent the TCP message has accessed the first member of the cluster. However, the TCA message is sent even if one half of the pair has not accessed any of the members of the same cluster.

DN98792452Issue 12-0

29


Id:0900d805803e7764

g The Nokia system does not support clusters of type B.The signalling clusters are not shown to the user part, which is not notified of the changes in the states of clusters, either.

In the ANSI signalling network, the message routing software investigates first all the 24 bits in the initial part of the point code of the destination address. If the address is unknown, they investigate only the first 16 bits and, finally, only the first 8 bits. This kind of routing is called partial routing. If partial routing results in an address that does not belong to any of the signalling cluster types, the address of that message is regarded as faulty.

Use of the link set of another networkIf there is a need to use more than one network indicator (for example, NA0 and NA1), and the signalling traffic in the other one is very low, it is possible to use the signalling link set of another network. This means that there is physically only one link set between two network elements but there are two route sets using that link set.

g Using the feature is possible only between two Nokia network elements.

Large capacity links (optional feature)The large capacity SS7 link feature (optional) provides more signalling capacity than conventional 64 kbit/s SS7 links. A large capacity link provides capacities from 64 kbit/s up to 1984 kbit/s.

When there is a need for a large amount of signalling capacity between two network ele-ments, it is difficult to manage it with the conventional 64 kbit/s signalling links. Only 16 signalling links can be created into a signalling link set. And only one link set per signal-ling network is allowed between two network elements. With this feature, it is possible to create less signalling links which have larger capacity. It provides an easier way to handle large amounts of signalling capacity. For example, one 512 kbit/s link can replace eight conventional 64 kbit/s links.

A large capacity SS7 link uses more than one time slot, as in the conventional 64 kbit/s signalling link. The support for large capacity signalling links is implemented into AS7-V, AS7-VA, AS7-A, and AS7-C types of signalling link terminals.

The functionality of the large capacity SS7 signalling link is the same as in the conven-tional 64 kbit/s links, but the capacity is larger. A large capacity signalling link is not com-patible with 64 kbit/s links, that is, both ends of a signalling link have to support large capacity signalling links. Signalling links with different capacities cannot be created into the same signalling link set or signalling route set.

g Using the feature is possible only between two Nokia network elements.

3.2 SCCP level signalling networkWhen you are planning the SCCP network, remember that the SCCP network is config-ured on the MTP network, and that there must be a route set on the MTP level to all Sig-nalling Points (SP) known by the SCCP.

The SCCP has to be configured locally in the network elements which have mobile appli-cations, IN applications, or which perform SCCP global title translations. The SCCP has to be configured also for those of the remote network elements to which SCCP messages are sent. The SCCP does not need to be configured in MTP level STP network elements if the SCCP messages are only sent through them and not to them.

30 DN98792452Issue 12-0


Id:0900d805803e7764


Applications that use SCCP services are defined as subsystems which are identified by a Subsystem Number (SSN). The subsystems can be SCCP management (SCMG), MSC MAP, VLR MAP, HLR MAP, INAP, OMAP, and possibly some network-specific subsystems, like Base Station System Application Part (BSSAP).

The SCMG is located in all signalling points that are known by the SCCP. The MSC MAP, VLR MAP, and BSSAP are located in MSC/VLRs and the HLR MAP can be found in HLRs. The INAP is located in IN SSPs and SCPs, but also in MSCs.

How the subsystems are defined in the SCCP network depends on what kind of addresses are used in signalling message transfer.

SCCP addressing (GT or SPC/SSN)There are two different types of addresses which are used for routing in the SCCP. Routing can be based on the Signalling Point Code (SPC) and Subsystem Number (SSN) addresses, which means that the SCCP has to know all the signalling points and subsystems to which it can send messages because SCCP routing checks the status of the called SPC and SSN before sending a message to the MTP. Routing can also be based on the Global Title (GT). In this case, the SCCP needs to know much less about the network because it only checks the status of the signalling point to which a message is sent for the next Global Title Translation (GTT).

All local subsystems have to be defined for the SCCP because the SCCP checks their status before it passes incoming messages to them. The SCCP and SCMG subsystems have to be defined in remote nodes if any SCCP messages are sent to the SCCP. The subsystems to which the messages are sent with the SPC and SSN addresses also have to be defined in the remote nodes. This is the case with the A interface. In the MSC, all the BSSAPs in the BSCs have to be defined, and in the BSCs, the BSSAP of the MSC has to be defined. Elsewhere in a GSM network, it is always possible to use the GT for addressing. When roaming to or from another operator's network, the GT has to be used, but inside one operator's networks it is also possible to use the SPC and SSN.

For example, in Figure Two network elements with different SCCP subsystems, in network element A, the MAP application of B must be defined. In network element B, the MAP application of A must be defined. The INAP application of network element A does not necessarily need to be defined in network element B because there is no need for changing messages.

DN98792452Issue 12-0

31


Id:0900d805803e7764

Figure 16 Two network elements with different SCCP subsystems

The GTs that have to be defined in a GSM network depend on the roaming agreements you make. How and where the translations have to be defined depends on the structure of the network.

For example, it is possible to have one or two gateway STPs that handle all the outgoing and incoming signalling traffic. In that case, all the GTs of outgoing messages are trans-lated so that the messages are sent to those STPs for further translation. In the STPs, the outgoing GTs can be translated to international gateways or to other operator's gateway STPs.

Figure 17 Example of SS7 SCCP routing and global title analysis in the case of location update (LOC.UPD.)

This is what happens in each network element.

MSC1 Local BSC indicates a location update of a Mobile Station (MS). The MSC/VLR sends a location update message to the HLR. This message is sent as a UDT message and the GT of the called party address of the message is derived from the IMSI number of the MS. The country code

MTP

SCCP

MTP

SCCP

Network element A Network element B

RANAP RNSAP RNSAP

PSTN2IN0SP=1102HNA0SP=102H

PSTN1NA0SP=101H

MSC1/VLRNA0SP=301H

PSTNXIN0SP=1XNA0SP=X

HLRZNA0SP=Z

IN0

MSCYNA0SP=Y

DPC=102/NA0route=GT

DPC=1X/IN0route=GT

DPC=Y/NA0route=GT

DPC=Z/NA0route=GT

DPC=301/NA0route=GT

DPC=1102/IN0route=GT

DPC=X/NA0route=GT

DPC=Y/NA0route=GT

ATM Module

IN0

NA0 NA0

RNC

32 DN98792452Issue 12-0


Id:0900d805803e7764


part of the GT is translated in the MSC1 to find out the MTP address of the international gateway node and the message is sent to it.

PSTN1 PSTN1 transfers the messages through the MTP to PSTN2.

PSTN2 A UDT message is received from a national network. After a GT trans-lation where only the header information and country code of the called GT is translated, the message is passed to the international gateway of the destination network.

PSTNX PSTNX receives a UDT message from an international network and after the GT translation of the header information, country code, and operator code, it passes the message to the gateway MSC of the des-tination operator in the national network.

MSCY MSCY gets messages and makes a GT translation to find out the des-tination node of the message in your network.

HLRZ HLRZ makes the last GT translation (if it has not been done in the MSCY) to find out if the message is coming to it. The SCCP passes the UDT message to the local subsystem.

Figure 18 The points where the global tile translation is made (GTT 15)

Figure 19 The parts of the global title used in different global title translations

With an IN application, the first message is most often received from the local subsystem with an address including the GT. The rest of the signalling can use SPC and SSN addressing. If SPC and SSN addressing are used, the IN SSP has to know all the SCPs that it can use and the other way around, and the GT used by the IN subsystem is imme-diately translated to the SPC and SSN of the SCP subsystem. If the STP is used

CC country code

NDC national destination code

MSIN mobile subscriber identification number

VLRMAP

TC

SCCP

MTP MTP

SCCP

MTP

SCCP

MTP

SCCP

MTP

HLRMAP

TC

SCCP

MTP

GTT2

GTT1

GTT3 GTT4

MSC1 PSTN1 PSTN2 PSTNX MSCY HLRZ

GTT5

GTT1 CC NDC MSIN

GTT2 CC NDC MSIN

GTT3 CC NDC MSIN

GTT4 CC NDC MSIN

GTT5 CC NDC MSIN

DN98792452Issue 12-0

33


Id:0900d805803e7764

between the SSP and SCP, the GTT can lead to the STP and, if GTs are used for addressing throughout the signalling, the SSP does not need to know about the SCP and the other way around.

SCCP routing based on Calling Party global titleThis is an optional feature.

SCCP can base routing on calling global title (GT). There is an attribute in the called GT result named ACGT (Analyse Calling GT). If the analysis of the called GT in the signal-ling message leads to a called GT result where the attribute is on, the calling GT analysis is made.

If the calling GT analysis leads to a calling GT result where the destination is available, the signalling message is routed to that destination. If the destination in the calling GT result is not available, or there is no analysis defined for the calling GT in the signalling message, the destination in the called GT result is used.

The calling GT analyses are stored in a different table than the called GT analyses.

The following two use cases describe the feature:

Figure 20 Use Case 1

The SCCP level STP and the GW1, GW2, and GW3 are all SCCP level STP points. The routing based on SCCP CgPA functionality is implemented in the network element named SCCP level STP in the figure. The operator can use that network element as a common SCCP level STP point, and can route messages with some called GTs in a dif-ferent way based on where the message comes from. Therefore, in Figure Use Case 1, the message arrives to an SCCP level STP with certain GT in an SCCP called party address. With this same called GT, the message has to be routed to:

GW1 if the calling GT is the GT of Src NE1 GW2 if the calling GT is the GT of Src NE2 GW3 if the calling GT is the GT of Src NE3

SCCP CdPA = Destination NESCCP CgPA = Src NE3MTP DPC = SCCP level STP

DestinationNE

SCCP level STP

GW2

GW2

GW3

Src NE3


GW2

Src NE2

GW1

Src NE1

SCCP level STP


DestinationNE

34 DN98792452Issue 12-0


Id:0900d805803e7764


Figure 21 Use Case 2

It is important for an operator to protect the network against spam SMSS. All SMSS orig-inated from a secure source, for example, from the operator's own network have to be routed normally (see DEST in Figure Use Case 2). Other SMSS have to be routed to a control center. The SMS is routed in a different way based on where it comes from. The called GT analysis result holds the SPC of the control center. The calling GT analysis is created for the trusted originators so that they lead to the normal destination (see DEST in Figure Use case 2). If there is no analysis for the calling GT (possible spam), the SPC in the called GT analysis result is used.

SCCP servicesThe SCCP has two different message handling services. The connectionless service is used for database inquires, for broadcast-like services, as well as for the passing of SCCP management messages. The connection-oriented service is currently used only between the MSC and the BSC for call signalling.

Needed SCCP subsystemsIn a local node, all the subsystems that are used have to be defined in the SCCP, which means that there always has to be an SCMG. The MSC needs the MSC MAP, VLR MAP, and BSSAP and in some cases also the INAP. In the HLR, there has to be an HLR MAP and possibly an Equipment Identity Register (EIR) MAP, and an AC. In the BSC, there is a BSSAP. In the IN, the SSPs, and the SCPs, there are INAPs.

In remote nodes, there always have to be an SCMG and those subsystems to which messages are sent with SPC and SSN addressing. In the MSC, all the BSSAPs in the BSCs have to be defined, and in all the BSCs, the BSSAP of the MSC has to be defined. Otherwise, the definition depends on how addressing is used.

Global titles of SCCPIn the GSM network, the GTs used for roaming are derived from the IMSI numbers of mobile subscribers by replacing the E.212 number Mobile Country Code (MCC) and Mobile Network Code (MNC) with the E.164 number country code and network code, so that the result is an E.214 number.

The depth of translation must not be more than what is needed to distinguish the SP to which the message is sent.

Distribution of status data (broadcast)There are two types of broadcast: 'to network' and 'local' broadcast.

To network:

Controlcenter

NE1

DESTNE2

STP

DN98792452Issue 12-0

35


Id:0900d805803e7764

There is no absolute need for the definition of a broadcast to network because the response method is always active and all the necessary status data are delivered to the network. Normally, this only takes a little time. The broadcast can be set, for example, to inform some SCCP-level STPs about the status of the subsystems to which the STP sends messages with the SPC and SSN address.

Local:

Currently, the only subsystem that needs local broadcast is the BSSAP. In the MSC, the local BSSAP has to know the status data of the BSSAPs located in the BSCs, and in the BSC, the local BSSAP has to know the BSSAP in the MSC.

SCCP level STP traffic restrictionsWith the SCCP level signalling traffic restrictions feature, it is possible to set restrictions concerning SCCP level STP signalling traffic.

The system supports the following types of SCCP level STP traffic restrictions, that is, SCCP screening:

SCCP signalling point-based screening GT screening calling GT checking and screeningThese types restrict the traffic of all subsystems. You cannot use them to restrict the traffic of a given subsystem. The signalling point screening and the GT screening can be switched off separately from each other. Both can be off or on, either one can be off while the other is on.

The calling GT checks are always done independently from the signalling point and GT screening status.

In the case of SCCP signalling point-based screening, there are two methods to define SCCP level screening:

OPC/DPC method, where the screening method is set for messages coming from a certain signalling network and Originating Point Code (OPC) addressed to a certain signalling network and Destination Point Code (DPC).

Linkset/DPC method, where the screening method is set for messages coming from a certain signalling link set and addressed to a certain signalling network and DPC.

In the case of SCCP signalling point-based screening, it is also possible to copy the existing MTP policing (STP access) to correspond to the SCCP level. However, it is not possible to copy an unauthorised type of MTP policing to correspond to the SCCP level.

In the case of GT screening, the calling GT is analysed and the screening method can be defined between the calling GT result and the called GT result. If some GT modifica-tion is defined in the GTT result, for example, adding or deleting digits of called or calling GT, the modification is done after the GT screening.

For SCCP signalling point-specific screening and GT screening, the screening method can be set so that the message is simply deleted. In addition, an alarm can be set for the deleted message or the alarm can be set without deleting the message. An alarm is set only once, even if the alarm can be set more than once for the message. The priority order for setting the alarm is the following:

1. Linkset/DPC2. OPC/DPC3. GT screening

36 DN98792452Issue 12-0


Id:0900d805803e7764


The order is then decided by the traceability, the incoming link set is the strictest way to trace the message.

The available alarms are alarm 1029 SCCP STP MESSAGE PREVENTION for signal-ling point screening and alarm 1293 SCCP GT SCREENING APPLIED for GT.

The message is deleted if any of the three screening methods indicate it. For example, if the Linkset/DPC screening method indicates that only the alarm should be set and the GT screening method indicates that the message must be deleted, the alarm is gener-ated according to the Linkset/DPC method and later on deleted according to the GT screening method.

In the case of Calling GT checking, there are two methods to define SCCP level screen-ing:

Restrictions according to the calling Global Title Indicator (GTI): it is possible to define a set of allowed GTI values which are transmitted.

Restrictions according to the calling GT translator selector values (calling GT root). It is possible to set the screening so that messages with known GT translator selector values are transmitted. This analysis is based on the existing called GT analysis.

If any of the above two Calling GT checking methods show that the message must be deleted, alarm 1029 SCCP STP MESSAGE PREVENTION is set for the message.

The SCCP level STP messages that are screened cause the registration of statistical information in the network element. There are no screening-specific statistical counters, so all the information is seen as 'unqualified' counters. You can see these routing failure events with the OTR command. This concerns SCCP signalling point based screening and calling GT checking, but not GT screening.

For more information, see Section Setting and modifying SCCP level signalling traffic restrictions.

SCCP support for Feature 1679: Handling of forward-SMs in SRRiThis is an optional feature.

The feature includes short message rerouting and rejection, that means, screening func-tionalities for SMs. The main functionality is at the application level. SCCP and TC layers provide support so that certain messages can be delivered to an application that makes decision whether:

the messages is sent as suchor

the message is sent to a new destinationor

the message is rejectedThe trigger for inspecting the message at the application layer can be both in the called GT analysis result and in the calling GT analysis result. Both the called GT analysis result and the calling GT analysis result hold an attribute TCC (TC Checking) for that purpose.

SCCP backupsOn the SCCP level, backups (replicas) can be those of either signalling points or sub-systems. Signalling point backups are, in practice, GTT backups. This means that

DN98792452Issue 12-0

37


Id:0900d805803e7764

messages are normally sent to one primary STP for GTT, but in the case of a failure, another STP capable of the same GTT can be used.

Currently, the only relevant backups for subsystems can be databases (that is, IN SCPs). Backups can be defined for SPs, subsystems, and also for GTT results.

Only one backup is active, so when a GTT result has a backup, other possible backups are not used.

SCCP load sharingOn the SCCP level, it is possible to define load sharing for up to 16 destinations. Each load sharing destination has destination priority. Priority value 1 presents the highest pri-ority, priority value 2 presents the lower priority. By priority value, the primary-backup concept can be incorporated into the GT load sharing. It means that the traffic is shared between the primary destinations, that is, priority value 1 destinations, as long as there is at least one primary destination available. If there is no primary destination available, the traffic is shared between the backup destinations, that is, destinations with priority value 2. Fallback to the primary destinations is done when at least one primary destina-tion becomes available.

SCCP routing selects the destination based on different methods for protocol class 0 messages and protocol class 1 messages. The selection is made among the available destinations with the highest priority; if there is not a highest priority destination avail-able, the selection is done among the lower priority destinations that are available.

For protocol class 0 messages, SCCP routing selects the destinations according to the order in the result. SCCP routing keeps track of which the next destination to be selected is. If there are, for example, four available priority value 1 destinations (that is, highest priority destination) in the result, they are selected in 1, 2, 3, 4, 1, 2, 3, 4, order and so on.

For protocol class 1 messages, SCCP routing selects the destination according to the SLS value in the incoming message. The incoming SLS is not used directly, but an internal SLS value is calculated based on the incoming SLS and the OPC. The selection of the destination index is done by mapping the internal SLS value to a destination index. Mapping is based on the SLS value range division into as many parts as many destina-tions are in a result. The destination count is the amount of available highest priority des-tinations in the result; if none, the available lower priority destinations are used in load sharing.

If there are two destinations in the GT result, and load sharing is not used, the secondary result is used as a normal backup destination of the primary result.

Load sharing is taken into use when creating or modifying GTT results with the NAC or NAM command.

In addition, on the SCCP level, MTP load sharing can be used when messages are sent to the STPs for GTT. This can be done so that in the STP nodes a common MTP alias point code is defined for them, and in the sending node, a route set using the two STPs with load sharing, is defined for the alias point. SCCP is also defined for that alias point in the sending node and GTT is defined so that it leads to the alias point. In this case, messages are sent to these two STPs through load sharing.

38 DN98792452Issue 12-0


Id:0900d805803154dc

Creating MTP configuration

4 Creating MTP configurationIn most cases, the MTP needs to be configured in the network element. Before config-uring the MTP, the signalling network has to be planned with great care.

Before you startCheck if the network element has all the necessary equipment and software.

If you are sure that all equipment and software needed for signalling already exists on the network element, you can continue with Create SS7 services.

Steps

1 Check if a signalling unit has been created in the network element (WTI)Depending on the type of your network element, the CCSU, BSU or BCSU can act as the signalling unit. Notice that the network element can have sever

common channel signalling (mtp, sccp and tc)

Documents

safety instructions

product names

mentioned hardware

common channel signalling

applicable safety standards

tcthe information

customer comments

software products