Top Banner
Signalling Transport over IP (M3UA and IUA) DN01141526 Issue 7-0 en # Nokia Siemens Networks 1 (81) 00055783-1.0 Nokia Siemens Networks GSM/EDGE BSS, rel. RG10(BSS), operating documentation, issue 02
81
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: dn01141526_6_SIGTRAN

Signalling Transport over IP(M3UA and IUA)

DN01141526Issue 7-0 en

# Nokia Siemens Networks 1 (81)

00055783-1.0Nokia Siemens Networks GSM/EDGE BSS, rel.RG10(BSS), operating documentation, issue 02

Page 2: dn01141526_6_SIGTRAN

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

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products are given “as is” and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer. However,Nokia Siemens Networks has made all reasonable efforts to ensure that the instructionscontained in the document are adequate and free of material errors and omissions. NokiaSiemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues whichmay not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NOEVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, THAT MAYARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN IT.

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

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia 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. All rights reserved.

2 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 3: dn01141526_6_SIGTRAN

Contents

Contents 3

List of tables 5

List of figures 6

Summary of changes 7

1 Signalling transport over IP (M3UA and IUA) 91.1 Association 101.1.1 SCTP multi-homing 111.1.2 SCTP stream 141.2 Association set 151.3 SGP - ASP communication 171.4 IPSP-IPSP communication 181.5 Signalling over IP statistics 19

2 Use of M3UA stack 232.1 SGP-ASP communication 232.1.1 Example of M3UA usage 252.2 IPSP-IPSP communication 262.2.1 Use of IPSP-IPSP example at the M3UA 272.3 Routing key and routing context 282.4 Signalling Point Management Cluster 292.5 Message structure of M3UA 30

3 Use of IUA 333.1 Message structure of IUA 34

4 Basic structures of M3UA network 37

5 Planning site configuration for signalling 41

6 Planning M3UA network 49

7 Creating M3UA configuration 51

8 Planning IUA network 57

9 Creating IUA configuration 59

10 Modifying Sigtran parameters 6310.1 Modifying association set level parameters of M3UA 6310.2 Modifying SCTP association level parameters 66

11 Deleting IP signalling links 7311.1 Deleting M3UA signalling links 7311.2 Deleting IUA connections 73

DN01141526Issue 7-0 en

# Nokia Siemens Networks 3 (81)

Contents

Page 4: dn01141526_6_SIGTRAN

12 Signalling transport over IP troubleshooting 7512.1 IP signalling link activation fails 7512.2 D-channel activation failed 7712.3 SCTP association failed 7912.4 Path of SCTP association failed 8012.5 List of debugging commands in a failure case 80

4 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 5: dn01141526_6_SIGTRAN

List of tables

Table 1. Summary of suggested parameter sets 68

DN01141526Issue 7-0 en

# Nokia Siemens Networks 5 (81)

List of tables

Page 6: dn01141526_6_SIGTRAN

List of figures

Figure 1. Association between two network elements 11

Figure 2. SCTP retransmission when both primary and secondary paths fail 12

Figure 3. Symmetric network layout 13

Figure 4. Asymmetric network layout 13

Figure 5. Example of an IP type SS7 signalling link 15

Figure 6. Association set 16

Figure 7. An example of SGP-ASP communication 18

Figure 8. An example of a basic IPSP-IPSP configuration with a point to pointconnection inside the IP network 19

Figure 9. An example of SGP-ASP communication 23

Figure 10. An example of a Signalling Gateway between two network elements indifferent protocols 25

Figure 11. An example of combined Signalling Gateway and IPSP-IPSP 27

Figure 12. An example of Signalling Point Management Cluster 30

Figure 13. Message structure of M3UA 32

Figure 14. IUA protocol 33

Figure 15. Message structure of IUA 35

Figure 16. Basic example of a network that uses IP 37

Figure 17. An example of an M3UA network with SCCP relay function 38

Figure 18. Avoiding number of point-to-point IP route 43

6 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 7: dn01141526_6_SIGTRAN

Summary of changes

Changes between document issues are cumulative. Therefore, the latestdocument issue contains all changes made to previous issues.

Changes made between issues 7–0 and 6-0

. Command Group (Q6) for IPv6 does not exist anymore. IPconfiguration for IPv4 and IPv6 is now managed with one MMLcommand (QR).

A network Interface configuration (QRA) is now a mandatoryoperation before any IP address can be added to a unit networkInterface (QRN).

The Redundant IP address backup interface can be configured nowwith one command (QRN).

The changes have influence on the chapters Planning siteconfiguration and Signalling transport over IP Troubleshooting.

. The example 'Configuring asymmetric SCTP multi-homing' isremoved from chapter 'Planning site configuration for signalling',because it contained only redundant information.

. Link corrections.

Changes made between issues 6–0 and 5-0

Editorial changes and link corrections.

Figure 'Message structure of IUA' corrected.

Changes made between issues 5–0 and 4-4

New feature 'Interrogate Average CPU load' added.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 7 (81)

Summary of changes

Page 8: dn01141526_6_SIGTRAN

Links to MML commands have been improved in all chapters.

8 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 9: dn01141526_6_SIGTRAN

1 Signalling transport over IP (M3UA andIUA)

The information in this document relates to DX200 and IPA 2800–basedproducts.

Signalling transport over IP (SIGTRAN) contains several user adaptationlayers, two of which are described here: the MTP3 User Adaptation Layer(M3UA) and the Q.921 User Adaptation Layer (IUA).

M3UA is a protocol for supporting the transport of any SS7 MTP3-Usersignalling (for example, ISDN user part (ISUP) and Signalling ConnectionControl Part SCCP messages) over IP using the services of the StreamControl Transmission Protocol (SCTP). Also, provision is made forprotocol elements that enable a seamless operation of the MTP3-Userpeers in the SS7 and IP domains.

IUA is a protocol supporting the transport of Q.921 user signalling over IP.It uses the services of the SCTP. The IUA adaptation enables an MSScontrolling a Private Automatic Branch Exchange (PBX) even if the MSSdoes not have Pulse Code Modulation (PCM) connectivity.

Both protocols are to be used between a Signalling Gateway (SG) and aMedia Gateway Controller (MGC). It is assumed that the SG receives SS7signalling or Link Access Procedure on the D-channel (LAPD) signallingover a standard E1 or T1 interface. SS7 signalling can also be receivedover ATM interface using the SS7 Message Transfer Part (MTP) to providetransport.

Signalling transport over IP offers almost similar quality of service as TDM-based signalling connection. This can be achieved by using modifiedSCTP transport parameters. In an IP signalling network planning phase, aused WAN and/or transmission network capacity and quality of serviceitems shall be taken into account. It is very important especially when theSCTP parameters in use have been defined.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 9 (81)

Signalling transport over IP (M3UA and IUA)

Page 10: dn01141526_6_SIGTRAN

1.1 Association

An SCTP association is a relationship between two communicating peers.Application of an SCTP is establishing and maintaining an association.Configuration of an SCTP association is done in the application level. Ifboth communicating peers are based on our system, the SCTPassociation has been established between two signalling units by clientpeer. The SCTP association uses the following address parameters:source port number, list of source IP addresses, destination port number,and list of destination IP addresses. If one of those address parameters isdifferent, it means that a new association should be established. Anassociation can have several logical paths (source and destination IPaddress pair); that kind of connection is called multi-homed connection.SCTP can use multi-homed connection but a TCP does not know that kindof architecture. For this reason, an SCTP association is much more faulttolerant than a TCP connection.

For the above mentioned Signalling adaptations to work as solidly as theirexamples (Q.921 and Q.704), the SCTP has been used in implementationas the data link layer. SCTP offers similar certification capacities as can beexpected when using a traditional TDM connection. To meet the traditionalquality requirements when using the SCTP, the retransmission parametersof the SCTP must be adjusted so that the criteria will be met also whenusing the IP-net. When readjusting SCTP retransmission parameters youneed to take into account the method of implementation of the IP-net(either LAN or WAN) as well as the quality of service it provides. The mostcrucial criteria of these is the transit time delay.

The Client peer establishes an association. The system supports twodestination IP addresses; primary destination IP address and secondarydestination IP address. During the association establishing phase theClient normally sends an SCTP initialize message to the primarydestination IP address. If the primary destination IP address does notresponse to anything, the Client tries to establish an association to thesecondary destination IP address. When the network failure in the primarynetwork is over, the system changes a configuration so that signallingtraffic is running over the primary network and the secondary network isrunning a backup mode.

10 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 11: dn01141526_6_SIGTRAN

Figure 1. Association between two network elements

1.1.1 SCTP multi-homing

In the IP terminology, a host is called multi-homed if it can be addressed bymultiple IP addresses. To make full use of the SCTP multi-homing, thehost also needs to support multiple network interfaces, each of which hasto be configured to work in a different sub-network. The SCTP multi-homing is used only for recovering from network failures. It is not used, forexample, for load balancing. The SCTP implementation supports twopaths per association. Normally data is sent through the primary path. If anetwork failure occurs in the primary network, SCTP resendsunacknowledged data through the secondary path automatically. Theapplication cannot see which path is used and it does not affect sending ofdata traffic in application level either. In this case, the SCTP stack takescare of all the details.

The SCTP association works normally so that data runs through theprimary path and SCTP heartbeat runs through the secondary path. Ifsomething unexpected happens in the primary path, the SCTP usually hasan alternative path available. The SCTP monitors a condition of thesecondary path all the time by using a heartbeat message. The followingfigure describes how the SCTP retransmission works when both the

MSS

SIGU signallingend point

ESB20

ESB20

Association

DN01141526Issue 7-0 en

# Nokia Siemens Networks 11 (81)

Signalling transport over IP (M3UA and IUA)

Page 12: dn01141526_6_SIGTRAN

primary and the secondary paths failed. The retransmission procedurestarts always the same way; the first retransmission is done through thesecondary path. The example above is based on the following SCTPparameters:

. Retransmission time-out, RTO.min 300 ms

. RTO.max 500 ms

. Path.max.retrans 2

. Assoc.max.retrans 4

For more information about SCTP parameters, refer to chapter ModifyingSCTP association level parameters.

Figure 2. SCTP retransmission when both primary and secondary paths fail

The SCTP sends data first through the primary path. It starts theretransmission timer and starts to wait for the SACK message from theremote peer. If the retransmission timer expires, the SCTP re-sends datathrough the secondary path and restarts the retransmission timer again byusing the same value as before. If the remote peer does not send anySACK before the retransmission timer expires again, the sending peer re-sends data packets through the primary path and doubled the value of theretransmission timer. If new retransmission timer value is greater than theRTO.max value, the SCTP starts using the value of the RTO.maxparameter as a new retransmission timer. If both paths are totally out oforder, the remote peer does not send any SACK. Sending peers try to re-send data as many times as they are allowed to try. The maximum amount

End Point A End Point B

Primary Path

Secondary Path300ms

300msPrimary Path

Secondary Path500ms

500ms

Primary pathUnavailable

Abort

12 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 13: dn01141526_6_SIGTRAN

of retransmission per association is the same as the value of the assoc.max.retrans parameter. When error counter is equal to or greater than thevalue of assoc.max.retrans, the sending peer stops trying to resend dataand closes an association by sending an ABORT message to remote peer.

There are two types of SCTP multi-homing.

Figure 3. Symmetric network layout

The first type is symmetric SCTP multi-homing where both peers have twoor more external Ethernet interfaces available and connection is madebetween them. Each signalling unit contains two Ethernet Interfaces innetwork element. The SCTP can use both interfaces in such a way thatone is working as a primary and the other one as a secondary path. TheSCTP ensures that none of the messages can get lost if only one path isbroken at the same time. Each Ethernet port should belong to a differentsubnetwork of the signalling unit, otherwise multi-homed connections donot work as expected.

Figure 4. Asymmetric network layout

HOST A HOST B

HOST A HOST B

DN01141526Issue 7-0 en

# Nokia Siemens Networks 13 (81)

Signalling transport over IP (M3UA and IUA)

Page 14: dn01141526_6_SIGTRAN

The second type is asymmetric multi-homing where a configuration alsohas two separate paths but Host A has only one Ethernet port in use. If theonly Ethernet port of Host A or the gateway router where it is connectedfails, then multi-homing does not help. If Host A is assigned to a secondnetwork, then the resiliency of the network can be improved. Thisadditional address of Host A should be taken into account in the networkconfiguration of the routers as well. As a result of this modification, in caseof any kind of network failure, multi-homing helps to avoid association loss.

Description of how asymmetric SCTP multi-homing configuration shouldbe configured is described in the chapter Creation of SCTP configuration.

1.1.2 SCTP stream

SCTP provides multiple stream function within an SCTP association.SCTP uses streaming for message ordering. Each independently orderedmessage sequence is called a stream. Stream is unidirectional, whichmeans that the number of outbound streams and the number of inboundstreams can be different. The number of data streams can vary from one tothousands. The main purpose of the stream is to avoid so called head ofline blocking situation, especially when only one SCTP association is inuse between network elements. Alternatively, this can be avoided by usingmultiple associations. Used number of outbound streams depends onSCTP applications because application should tag each of its outboundmessages with a stream identifier. Outbound stream number 0 might beused for special purpose. For example in IUA and M3UA user adaptationsare required that only management message is allowed to use a stream 0and therefore the first data stream is 1.

In M3UA implementation it is possible to use multiple streams for datamessages. Management messages are always sent to stream 0. It ispossible to configure with an association set parameter whether the datastream is 0 or 1. It is recommended to use multiple data streams; in thatcase the first data stream is always 1. Number of streams per associationis 16 in the M3UA, except when remote end supports fewer streams thanlocal end wants to use. In that case the system is using lower number ofstreams automatically.

In IUA implementation it is possible to use multiple outbound streams.There each D-channel uses own stream identifier so that within singleassociation should be supported as many streams as D-channels aresupporting. The maximum number is 64.

14 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 15: dn01141526_6_SIGTRAN

1.2 Association set

A system is based on a distributed architecture so that there are severalcomputer units which can do same kinds of tasks. M3UA has beenplanned to work in such a system. In that way system resources can beused more efficiently.

SCTP association is a point-to-point connection between two end points(see the following figure). In our system, an IP end point is a signalling unit.A network element may contain tens of signalling units. If more signallingcapacity is needed between two network elements, signalling capacity canbe increased by adding more SCTP associations to the association set. Inthis case, it is assumed that each SCTP association is created to differentsignalling unit. By using multiple signalling units in one association set(one association per signalling unit), you share the load among more thanone computer units and at the same time make the signalling connectionredundant. One signalling unit can be connected to multiple associationsets if the network element also needs to communicate with other peers.

Figure 5. Example of an IP type SS7 signalling link

Additionally, when there is a multiple association set between two networkelements, it is recommended that the signalling unit is only connected toone association set. For example, if support of multiple SS7 networks isrequired in the network planning then more than one association setbetween two network elements must be created. In some case it might be

MSS (client)

SIGU 0

SIGU 1

SIGU 2

IP network

MGW (server)

ISU 0

ISU 1

ISU 2

association set /SS7 signalling link set

association

ISU 3 SIGU 3

DN01141526Issue 7-0 en

# Nokia Siemens Networks 15 (81)

Signalling transport over IP (M3UA and IUA)

Page 16: dn01141526_6_SIGTRAN

necessary to create multiple associations, which are connected to thesame signalling unit, in the association set. That is not recommended but itis possible to do when the network planning has not been able to do inother way.

On the M3UA, each IP signalling link is associated with an association setconsisting of up to 32 SCTP associations. However, for orderedmessages, for which the SLS is used for load sharing, traffic is shared to amaximum of 16 first activated SCTP associations. Up to 32 activeassociations can be used for a case where unordered messages are used.Unordered message mode is possible only with an interface where SCCPprotocol class 0 has been used. The state of a signalling link follows thestate of the association set; when at least one SCTP association is activeinside the association set, the signalling link is active.

Figure 6. Association set

Used load sharing method of the M3UA depends on a signalling traffic. Ifsignalling traffic requires an ordered delivery, then SLS value is used forload sharing. That means that all signalling messages with same SLS aredelivered through the same association inside the association set. In case

Signalling route set

Signalling link

Signalling link set

Association

Association

Association

Association set

16 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 17: dn01141526_6_SIGTRAN

of association failure, it is necessary to update the routing table ofassociation set. When association failure is over, the content ofassociation set routing table is required to be exactly the same as it wasbefore the failure.

Note

Association set is related to Nokia distributed architecture, and it is aNokia Specific concept. Association set concept is only used in M3UAconnections.

Each association inside an association set can be in the following states:

. DOWN-BY-USER

. SCTP_DOWN

. UP-PROCEEDING

. ASP-DOWN

. ASP-INACTIVE

. ASP-ACTIVE

1.3 SGP - ASP communication

Signalling Gateway process is a signalling agent that sends and receivestelecom signalling traffic at the edge of IP network. Signalling Gateway asa signalling converter where TDM or ATM based signalling connection isterminated.

Application server is a some kind of virtual database or call controlelement, which can serve a specific routing key. As mentioned earlier,DPC is used as a routing key at the solution. According to IETF-RFC 2719:Framework Architecture for Signaling Transport , Framework Architecturefor signalling transport, SGP-ASP communication based on IP network astransportation. ASP-SGP concept is described in the following figure.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 17 (81)

Signalling transport over IP (M3UA and IUA)

Page 18: dn01141526_6_SIGTRAN

Figure 7. An example of SGP-ASP communication

The example above describes the ASP-SGP connection in case of M3UA.

1.4 IPSP-IPSP communication

In case of IPSP-IPSP communication, the services of a SignallingGateway node are not needed, since both peers exist in the IP domain. Agroup of IPSPs form an Application server at both ends of the signallingconnection. The message exchange in an IPSP-IPSP connection issingle-ended by default, where only one endpoint sends ASPmanagement messages. The other possibility is the dual-ended mode,where both endpoints send ASP management messages.

MTP2 SCTP

MTP1 IPv4/IPv6

MTP3 M3UA

CAP/MAP/...

TCAP BSSAP

BICC/ISUP SCCP

M3UA

SCTP

IPv4/IPv6

CAP/MAP/...

TCAP BSSAP

BICC/ISUP SCCP

MTP3

MTP2

MTP1

SG

SEP/STP ASP

18 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 19: dn01141526_6_SIGTRAN

Figure 8. An example of a basic IPSP-IPSP configuration with a point to pointconnection inside the IP network

1.5 Signalling over IP statistics

IUA-specific statistics are not available yet. In the signalling unit level, theSigtran traffic can be monitored from the SCTP stack counters. The SCTPstatistics counters offer overall number of SCTP traffic in the signallingunit. Those counters contain traffic from all SCTP user adaptations, andtherefore those counters are not so useful if one is interested only in thetraffic of specific SCTP user adaptation. The SCTP statistics counters arepossible to see by using QRS.

The Interrogate Average M3UA CPU Load, OYQ MML command helps indimensioning the network. It also enables more efficient troubleshootingand network management.

With the OYQ MML it is possible to monitor the amount of M3UA traffic thatis handled by a signalling unit, which is useful as there are capacity limitsfor the traffic. Thus it helps to monitor, if the congestion is affected due tothe IP backbone or lack of CPU capacity, to handle M3UA traffic.

M3UA Association Set Measurement (295H/661) can be used to monitorM3UA traffic. It gives information on traffic through put and quality of M3UAconnections. The measurement measures M3UA traffic from M3UA layerand SCTP layer. The M3UA Association Set measurement can be started

Applications

AdaptationLayers

SCTP

IP

Applications

AdaptationLayers

SCTP

IP

IPSP-IPSP

DN01141526Issue 7-0 en

# Nokia Siemens Networks 19 (81)

Signalling transport over IP (M3UA and IUA)

Page 20: dn01141526_6_SIGTRAN

and stopped with the MML commands of the T2 command group. Formore information on the M3UA Association Set Measurement, see NSSStatistics, Reports (Part 3), Operating Instructions and NSS Statistics,Operating Instructions.

M3UA layer counters tell the payload of the SCTP connection. From thecounters of the SCTP layer, the operator can retrace the traffic of theSCTP layer used by M3UA association. The SCTP layer counters give theoperator more accurate information on the real load required for sendingM3UA traffic through SCTP by including the number of retransmittedSCTP packets and SCTP header.

Unavailability counters can be used for monitoring, for example if theassociation is in ASP-INACTIVE state.

Measurement is configured by using common statistics interface T2 MMLcommand group commands.

Supported counters are the following:

M3UA association set counters:

Duration of M3UA association set has been unavailable

Number of times M3UA association set has been unavailable

M3UA association counters:

Duration of M3UA association has been unavailable

Number of times M3UA association has been unavailable

Number of received packets on M3UA association

Number of sent packets on M3UA association

Number of octets received on M3UA association

Number of octets sent on M3UA association

SCTP counters used by M3UA:

Number of SCTP packets received

Number of SCTP packets sent

Number of SCTP octets received

20 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 21: dn01141526_6_SIGTRAN

Number of SCTP octets sent

Number of retransmitted SCTP packets

Number of duplicated TSN received

For more information on the M3UA and the SCTP layer counters, seeSection M3UA Association Set measurement report (661/295H) in NSSStatistics, Reports (Part 3), Operating Instructions..

If the M3UA-specific statistics are not available, the M3UA traffic can bemonitored by using the MTP3 level matrix measurements. The MTP3matrix measurement is based on using an OPC, DPC, and SI matrix. Thematrix defines a connection which traffic will be measured. Thismeasurement shows an amount of specific signalling traffic between twosignalling points. Service Indicator (SI) defines a concerned signallingtraffic and OPC and DPC parameters tell which ones of the signallingpoints belong to a measurement. The MTP3 matrix measurement can beconfigured by using OI MML command group commands.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 21 (81)

Signalling transport over IP (M3UA and IUA)

Page 22: dn01141526_6_SIGTRAN

22 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 23: dn01141526_6_SIGTRAN

2 Use of M3UA stack

This section describes the use of M3UA stack.

2.1 SGP-ASP communication

The signalling gateway process - application server process (SGP-ASP)communication is needed when communicating between the MTP-3 peersin SS7 and IP domains. To enable the communication, a seamlessinterworking function is needed in the SG at the M3UA layer for the MTP3-User peers in the SS7 and IP domains. In the SGP-ASP communicationthe related concepts are AS, ASP, SG, and SGP.

Figure 9. An example of SGP-ASP communication

SGAS

SGP

SGP

ASP

ASP

ASP

DN01141526Issue 7-0 en

# Nokia Siemens Networks 23 (81)

Use of M3UA stack

Page 24: dn01141526_6_SIGTRAN

A group of ASPs connected to an signalling gateway process (SGP) andserving a specific routing key is called an application server (AS). Whenthe SGP routes the message, it selects an AS by comparing theinformation in the message with a provisioned Routing Key (DPC+NI).After that an active ASP inside that AS is selected. The way the selectionis done depends on the traffic handling mode used. When the traffichandling mode is load-share, an active ASP is selected from the list ofactive ASPs: if the traffic handling mode is over-ride, there is only oneactive ASP on the list at the time.

Each ASP inside an AS can be connected to several SGPs. A group ofSGPs form an SG. When routing the message at ASP, the SG is firstselected based on information in the message, for example, DPC+NA, andan SGP is selected inside that SG. The SGPs inside an SG all have thesame availability view of the SS7 network.

Each ASP can belong to more than one AS, each AS serving its ownrouting key. When the ASP (in this case) wants to indicate to an SGP that itis active for handling specific routing key traffic, it needs to use the routingcontext value to indicate to the SGP which routing key traffic the ASPwants to be actively handled. There are two possibilities in routing contextvalue determination: either static configured or determined dynamic byrouting key registration. Dynamic routing key registration procedure isused by default. Using of routing key registration is not mandated if otherpeer does not support this optional feature.

In communication between Nokia network elements, the AS and SGconcepts are mapped to network elements, for example, AS = MSS, SG =MGW. Furthermore, the signalling units in those network elements aremapped to ASPs inside the MSS and SGPs inside the MGW.

When a signalling message arrives to the signalling gateway from an SS7link, the M3UA routing function determines first the association set basedon comparing the information in the message with a provisioned RoutingKey (DPC+NI). Inside the association set an association is selected,based on the SLS value, and the signalling message is forwarded to thesignalling unit where the association exists. With IETF concepts, in theNokia routing function the SGP (the signalling unit) and the ASP(association) from that SGP are selected at once based on the routing key,that is, DPC+NI and the SLS value. When there is a Nokia networkelement at the peer, it is recommended that there is only one association inone signalling unit inside one association set. See also Association set.

In a strict IETF sense, the AS concept applies in each SGP separately.The association set concept, however, is valid for the whole networkelement collecting all ASPs connected to each SGP (signalling unit).

24 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 25: dn01141526_6_SIGTRAN

In Nokia implementation each association can carry only the signallingtraffic related to one routing key. That is why it is not necessary toconfigure a routing context. The static configuration of the routing contextis necessary and it might be needed in some compatibility cases.

However, if the registration parameter is used inside the association set,the routing context gets its value during routing key registration. That valueis saved to a work file for possible further use in ASPTM messages.

2.1.1 Example of M3UA usage

Signalling messages from the PSTN are addressed to the server networkelement. A signalling route goes via the signalling gateway, where aprotocol change from SS7 to SIGTRAN is done. Signalling messages fromthe server are destined to the SCCP in the PSTN network element. Asignalling route goes via the signalling gateway, where a protocol changefrom SIGTRAN to SS7 is done. There may have STP points in the SS7path between the SG and the destination PSTN network element.

Figure 10. An example of a Signalling Gateway between two network elementsin different protocols

PSTN Signalling Gateway server

MAP MAP

MTP

SCCP

TC

MTP

M3UA

SCTP

IP

M3UA

SCTP

IP

TC

SCCP

DN01141526Issue 7-0 en

# Nokia Siemens Networks 25 (81)

Use of M3UA stack

Page 26: dn01141526_6_SIGTRAN

When the SG-ASP communication is used, signalling messages from thePSTN are destined to the server with SPC addressing. A signalling routegoes via the signalling gateway, where the protocol changes from SS7 toSIGTRAN. This is similar to the previous example, where the messagedoes not go to the SCCP level in the signalling gateway.

Signalling messages from the server are destined to the signallinggateway with SPC addressing. A signalling route goes via the signallinggateway, where the protocol changes from SIGTRAN to SS7. This issimilar to the previous example, where the message does not go to theSCCP level in the signalling gateway.

2.2 IPSP-IPSP communication

The IPSP-IPSP (IP server process) communication and the ASP-SGPcommunication are not different except for the fact that the signallinggateway functionality is not needed at either endpoint. The configuration,association, and the IPSP activation are the same. The IPSP-IPSP is twokind of functional mode. If the dual ended mode of the IPSP-IPSPconfiguration is wanted, the 'ASP MESSAGES IN IPSP' and the 'ASPMESSAGES' parameters should have the value 'Y' at both endpoints ofthe signalling link. In single ended mode, only the 'ASP MESSAGES'parameter should have the value 'Y' at both endpoints. If both parametershave the value 'N', the applications erver process state maintenancemessage (ASPSM) and application server process traffic manintenancemessage (ASPTM) messages are not exchanged at all.

The IPSP-IPSP connection can be used point-to-point between the M3UAusers. For example, when the Signalling Gateway is able to do the GTtranslation or when there is an SCCP relay in the IP network, the followingconnection is IPSP-IPSP.

26 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 27: dn01141526_6_SIGTRAN

2.2.1 Use of IPSP-IPSP example at the M3UA

Figure 11. An example of combined Signalling Gateway and IPSP-IPSP

In the example above, both the IPSP-IPSP and the SGP-ASPcommunication is possible.

When the IPSP-IPSP communication is used, signalling messages fromthe public switched telephone network (PSTN) are destined to thesignalling gateway with GT addressing. The GTT in the signallingconnection control part (SCCP) of the signalling gateway gives as a resultthe SCCP peer located in the IP network. The signalling messages fromthe server are destined to the signalling gateway with global title (GT)addressing. The global title translation (GTT) in the SCCP of the signallinggateway gives as a result the SCCP peer locating in the SS7 network. Inthis case, the connection between the signalling gateway and the server isan IPSP-IPSP connection.

PSTN Signalling Gateway server

MAP MAP

MTP

SCCP

TC

MTP

M3UA

SCTP

IP

SCCP

IPSP-IPSPor SG-ASP

M3UA

SCTP

IP

TC

SCCP

DN01141526Issue 7-0 en

# Nokia Siemens Networks 27 (81)

Use of M3UA stack

Page 28: dn01141526_6_SIGTRAN

2.3 Routing key and routing context

The distribution of the SS7 messages between the SGP and theApplication Servers is determined by the routing keys and their associatedrouting contexts.

Routing key is a part of the message header. The Internet EngineeringTask Force (IETF) standard for M3UA determines a group of SS7parameters that can be used as an identifier for an AS. These parameterscan be DPC (Destination Point Code), NA (Network Appearance), SI(Service Indicator), OPC list (Originating Point Code), or certain valuedomains of the number space of CIC (Circuit Identification Code). Theparameter DPC is obligatory because it is the SPC address used by theAS. Either one or several of these parameters as an identifier for an AScan be used as a routing key.

The DPC and network appearance together form the only routing key thatis supported. Both are also mandatory parameters in the routing key. Thenetwork appearance maps to a network indicator. The networkappearance parameter is included in the association set parameters. Theother parameters: SI, SSN, or CIC are not included in the routing keybecause it is expected that the network element operating as an AS canhandle the message distributing function itself. This especially applies tothe SGP when there is a Nokia network element at the peer.

Routing context is a value that uniquely identifies a routing key. The routingcontext parameter is a 4-byte value (integer) which is associated to thatrouting key in a 1-to-1 relationship. Therefore, the routing context can beviewed as an index into a sending node's Message Distribution Table,containing the routing key entries. An application server process may beconfigured to process signalling traffic related to more than one ApplicationServer, over a single SCTP Association. In ASP Active and ASP Inactivemanagement messages, the signalling traffic to be started or stopped isselected by the routing context parameter. At an ASP, the routing contextparameter uniquely identifies the range of signalling traffic associated witheach Application Server that the ASP is configured to receive.

Routing context values are either configured using a configurationmanagement interface, or by using specific procedures of routing keymanagement. In case of static configuration, the operator can configurethe value of the routing context manually. Dynamic Routing Keyregistration is used by default, but if you want to have a static configurationfor some reason (for example, insure compatibility against other vendors'product), refer to SCTP Configuration Handling .

28 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 29: dn01141526_6_SIGTRAN

2.4 Signalling Point Management Cluster

Signalling Point Management Cluster (SPMC) is an example of aconfiguration where two network elements share a Signalling Point Code(SPC). The SPMC is an entity which consists of the SG and ApplicationNode, but is visible to other network elements only with one signallingpoint identity, that of the Application Node. MTP level 2 connections andother MTP functionalities of an SPMC are in the Signalling Gateway, whilethe User Part functionality of the cluster is in the Application Node. Whenthe MTP of the Signalling Gateway receives a User Part messagedestined to the management cluster, it forwards the message to theApplication Node.

A signalling management cluster is applicable when a signalling pointbecomes an Application Node as it is connected to a Signalling Gateway,and therefore stripped of its MTP level 2 connections to other networkelements. Then other network elements need no configuration changes,as they see nothing from the management cluster but the same oldsignalling point code. One practical example of transition from signallingpoints to signalling management clusters is the migration from MobileSwitching Centers to MSC Servers and Multimedia Gateways. Themigration can be done without configuration changes to PSTN or publicland mobile network (PLMN) network elements by the managementcluster.

A management cluster may also be needed with the MSC Server conceptin IU- or A-interface, because some radio network controllerimplementation supports only associated signalling mode. However, it isnot mandatory to use the management cluster in MSC Server migration.Nokia recommends that with the MSC Server concept the quasi-associated signalling mode is used, that is, MGW is used as an STP, whichmakes it possible to design a signalling network more redundant.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 29 (81)

Use of M3UA stack

Page 30: dn01141526_6_SIGTRAN

Figure 12. An example of Signalling Point Management Cluster

Note

Signalling Point Management Cluster shall be used only between oneMSC Server and one MGW. Signalling Point Management Cluster doesnot work according to the specifications if more than one MGW isconfigured.

2.5 Message structure of M3UA

The basic overhead on SIGTRAN contains the following messageheaders: IP, SCTP, and M3UA.

TMSC

DPC=123,NI=8

TDM SG ASPM3UA

30 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 31: dn01141526_6_SIGTRAN

. The size of the IP header depends on what version of the IP stack isused, IPv4 or IPv6. The length of the IPv4 header can vary between20 and 60 bytes. 20 bytes is the length of the basic IP address inIPv4. The remaining 40 bytes is the length of the option field. Optionsare not commonly used on the IPv4. The length of the IPv6 header is40 bytes + options fields. Usually some of those option fields areincluded in the message when it is using IPv6.

. The SCTP header should contain a Common header, Chunkdescription, and Payload identifier. The length of the Commonheader is 12 bytes. The length of Chunk Description is 4 bytes. Thelength of Payload identifier is 12 bytes. The total SCTP header sizeis 28 bytes.

. The size of the Common Message header of the M3UA is 8 bytes.The Common message header exists in every M3UA message. Themain part of the bit rate is generated from the payload datamessages. Therefore, an example describes only the structure ofthe payload data. The optional Network Appearance parameter isused in M3UA. Its size is 8 bytes. The Routing label of the MTP3message is encoded in separate fields. The OPC and DPC fields areboth 4 bytes long and the rest of the routing label parameters like SI,NI, Message Priority, and SLS are encoded in one dword (4 bytes).The total length of the M3UA message header is 24 bytes in thePayload Data message.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 31 (81)

Use of M3UA stack

Page 32: dn01141526_6_SIGTRAN

Figure 13. Message structure of M3UA

0 31

Fragment Offset

Total lengthType of serviceHeaderlength

Identification

Time to live Protocol Checksum

Flags

Ver.

Source IP address

Destination IP address

Options (variable length, usually this field is not used)

Source Port Number Destination Port Number

Verification Tag

Checksum

Chunk Type Chunk Flags Chunk Length

TSN

Stream Identifier Stream Sequence Number

Payload Protocol Identifier

LengthTag=210

SI NI MP SLS

protocol data of the M3UA users (Variable Length)

Message length

Originating Point Code

Destination Point Code

Version Reserved Message Class Message Type

32 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 33: dn01141526_6_SIGTRAN

3 Use of IUA

IUA provides a solution for Standalone MSC Server to control PBXconnections over the IP network. In this solution, D-channels areterminated into the Signalling Gateway (for example MGW). The ControlPlane of the PBX connection is transported between MGW and MSS overthe IP network by using the IUA protocol. The solution comes from theIETF working group (SIGTRAN). The IUA protocol is needed in case anMSC Server has only IP interfaces available.

IUA uses the ASP-SG mode where MGW works as a Signalling Gatewayand MSS works as an AS. This mode is similar to the M3UA ASP-SGmode. Here, Q921 protocol is terminated in the SG. The application whichcontrols the PBX connection is located in the MSS.

Figure 14. IUA protocol

Q.931

Q.921 Q.921

IUA

SCTP

IP

IUA

SCTP

IP

Q.931

PBX MSS

MGW(SG)

ISDN IP

DN01141526Issue 7-0 en

# Nokia Siemens Networks 33 (81)

Use of IUA

Page 34: dn01141526_6_SIGTRAN

3.1 Message structure of IUA

The basic overhead on SIGTRAN contains the following messageheaders: IP, SCTP, and IUA.

. The size of the IP header depends on what version of the IP stack isused, IPv4 or IPv6. The length of the IPv4 header can vary between20 and 60 bytes. 20 bytes is the length of the basic IP address inIPv4. The remaining 40 bytes is the length of the option field. Optionsare not commonly used on the IPv4. The length of the IPv6 header is40 bytes + options fields. Usually some option fields are included inthe message when it is using IPv6.

. The SCTP header should contain a Common header, a Chunkdescription, and a Payload identifier. The length of the Commonheader is 12 bytes. The length of the Chunk Description is 4 bytes.The length of the Payload identifier is 16 bytes. The total SCTPheader size is 28 bytes.

. The IUA message starts a Common message header. The size ofthe Common header is 8 bytes. Immediately after the Commonheader is the IUA message header. RFC 3057 defines integer basedor text based IUA message headers. Nokia product supports onlythe integer based IUA header, and its fixed length is 16 bytes. A tagafter an IUA message header indicates what message is in question.The message below describes a protocol data message structure.The total length of the IUA message header is 28 bytes.

34 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 35: dn01141526_6_SIGTRAN

Figure 15. Message structure of IUA

Header length Type of serviceVer.

Identification

Time to Live Protocol Checksum

Fragment OffsetFlags

Total length

Source IP address

Destination IP address

Options (variable length, usually this field is not used)

Source Port Number Destination Port Number

Verification Tag

Checksum

Chunk Type Chunk Flags Chunk Length

TSN

Stream Identifier Stream Sequence Number

Payload Protocol Identifier

Version Reserved Message Class Message Type

Message Length

Tag = 0x1 Length

Length

Interface Identifier (Integer)

Tag = 0x5 Length = 8

DLCI Spare

Tag = 0xE

protocol data of the IUA users (Variable Length)

IPversion4header

SCTPCommonheader

andpayloaddata

IUAcommonheaders

andprotocoldata

0 31

DN01141526Issue 7-0 en

# Nokia Siemens Networks 35 (81)

Use of IUA

Page 36: dn01141526_6_SIGTRAN

36 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 37: dn01141526_6_SIGTRAN

4 Basic structures of M3UA network

When the IP transport is used in the signalling network, the SEP networkelement is usually in the IP network. The separator (SEP) network elementacts as an AS; it is connected to the time-division multiplexing (TDM)network via an SG, that is, a network element working in both networktypes. The AS can be a server or a database, but also any other networkelement where signalling is transported via the IP network.

Figure 16. Basic example of a network that uses IP

In the example figure, there are two SGs. If one of them is unavailable, theother can be used as a backup.

When the IP connection is used, the signalling unit must have anETHERNET port, through which it can be connected to the networkelement internal LAN.

SEP

STP

STP

SG

SG

SEPIP

DN01141526Issue 7-0 en

# Nokia Siemens Networks 37 (81)

Basic structures of M3UA network

Page 38: dn01141526_6_SIGTRAN

In the IP network, M3UA signalling is implemented as point-to-pointsignalling. The M3UA specification does not describe the M3UA level STPfunctionality; however, the STP functionality is implemented in the DX200-and IPA2800-based network elements according to the ITU-T Q704recommendations.

Figure 17. An example of an M3UA network with SCCP relay function

SS7 message routing can also be based on an SCCP GT address. If theGT is used for routing, there can also be an SCCP level STP inside the IPnetwork. The SG routes messages to the STP point, which is an AS fromthe SG's point of view. In that node, the SCCP finds out the next signallingpoint where the message has to be sent. The message is then passed onto the next signalling point through an IPSP-IPSP type M3UA connection.

Use of STPs

To save bandwidth in the IP network, it would be optimal to create a full-mesh network of logical connections between SIGTRAN elements.However, as M3UA uses associations between SEPs, the implementationand O&M work required for maintaining a full-mesh network in largenetworks would require too much effort. Here the use of SIGTRAN STPsbecomes possible. In the networks which already have STPs, some ofthem will probably be used also as an SG when implementing SIGTRAN.An SG can work as an STP as in the MTP3 network if SGs are connectedto each other via TDM or ATM-based connections. At least where SRRi is

TMSC

MSS

HLR

SCP

SMSC

IPSP - IPSP

IPMSC

SRRi

SRRiTMSC MGW

MGW

38 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 39: dn01141526_6_SIGTRAN

used for free numbering or mobile number portability, the signalling has togo via the SRRi. In that case, the SRRi can work as an SCCP level STP(or SCCP relay) inside the IP network. This has an effect when calculatingthe bit rate offered to the IP backbone as each message has to travelseveral times via the backbone (unless it is intra-site). There shouldalways be at least two STPs in physically separate sites to allowredundancy.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 39 (81)

Basic structures of M3UA network

Page 40: dn01141526_6_SIGTRAN

40 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 41: dn01141526_6_SIGTRAN

5 Planning site configuration for signalling

This procedure lists the things you need to consider when planning the siteconfiguration for signalling over IP solutions. It may not be necessary to dothe steps in the order they are presented here.

The SIGTRAN is not supported with a network element of the sub trackmechanics. TCP/IP stacks support setting DSCP. In case of M3UA, DSCPcan be set using known (M3UA server) port 2905. In case of IUA, DSCPcan be set using its well known port 9900. The DiffServ code can also beset to each SCTP association individually, but this requires configuring aspecific port number to client associations, and also using that specific portnumber with the DiffServ configuration.

It is recommended that the same DiffServ is used for all SCTPassociations in the association set in the M3UA. The settings of theDiffServ code used for M3UA signalling are common to all thoseapplications whose traffic goes via the same SCTP association.

The maximum delay that is allowed between the network elements is notspecified. See Q706 ITU-T recommendation for reference. An applicationof the M3UA sets real limits. The M3UA does not contain for examplesignalling link switchover within signalling link set, and therefore it cannotachieve the same service level as MTP3 in message transport. Packetloss may happen in the M3UA as on MTP level 3.

The LAN infrastructure, such as the point-to-point capacity of the LAN,should be known when planning the site configuration. Tunable SCTPparameters are necessary for the associations to function according to theQ706 ITU-T recommendation.

You can either plan a redundant LAN and the redundancy of associationsor plan the LAN using SCTP multi-homing. Choose one of the alternativesdescribed in the first step below. Redundancy of associations can behandled on several levels:

DN01141526Issue 7-0 en

# Nokia Siemens Networks 41 (81)

Planning site configuration for signalling

Page 42: dn01141526_6_SIGTRAN

. on the network element level: If signalling units are configured withlogical IP addresses (which is highly recommended), it is possible todo a signalling unit switchover procedure so that the current M3UAconfiguration is recovered.

. on the unit level

Before you start

1. IP addresses should be logical.

This enables making a unit switchover so that IP addresses remainthe same.

2. Static IP routes should be logical.

This helps to make a static IP-route configuration and ensure thatafter the unit switchover signalling connection works as before theunit switchover.

Note

SCTP multi-homing configuration is required to configure two IP sub-networks to each signalling unit. For this reason, the number of IProutes increases rapidly in each peer. Good IP addressing and good IPnetwork design is a key issue to avoid such a situation.

One example of how number of point-to-point IP route can beavoided:

42 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 43: dn01141526_6_SIGTRAN

Figure 18. Avoiding number of point-to-point IP route

3. Signalling over IP connection should be designed by using multi-homed connections if possible.

In this case, EL0 and EL1 should belong to different sub-networks.This kind of configuration ensures that the primary path is separatedfrom the secondary path.

4. Point-to-point message travelling time should be explored.

IP Backbone 1(133.40.0.0/16)

IP Backbone 2(132.30.0.0/16)

Site B

MSS B1:net 133.40.4.0/24net 132.30.4.0/24

MGW B2(A4.3 platform)net 133.40.6.0/24net 132.30.6.0/24

Site C MGW C1:(A4.3 platform)net 133.40.9.0/24net 132.30.9.0/24

MSS C2:net 133.40.11.0/24net 132.30.11.0/24

Site A

MSS A1:net 133.40.2.0/24net 132.30.2.0/24

DN01141526Issue 7-0 en

# Nokia Siemens Networks 43 (81)

Planning site configuration for signalling

Page 44: dn01141526_6_SIGTRAN

If the failure detection time has been planned, it is important toreduce it to the same level as that of the SS7 network by tuning theSCTP parameters.

Steps

If the system is taken into use for the first time, you should create the IPconfiguration before creating the SCTP association. Creation of logical IPaddress in the signalling unit changes the unit automatically from SP-EXstate to WO-EX state.

Note

Please note the difference between the concepts of redundant LAN andSCTP multi-homing. The redundant LAN means that the systemcontains a standby Ethernet Interface. In the redundant LANconfiguration both Ethernet ports of signaling unit have the same logicalIP address but only one of them is in active state. In the SCTP multi-homing configuration both Ethernet ports of signaling unit have ownlogical IP address from different IP subnetworks, so that both EthernetInterfaces are active simultaneously.

1. a)

Plan the configuration using SCTP multi-homing.

EL0 and EL1 should belong to different sub-networks. SCTP multi-homing enables better redundancy and therefore it is therecommended redundancy mode for signalling. It is recommendedto use a symmetric configuration in the case of SCTP multi-homing.For more information on SCTP configurations, see section SCTPmulti-homing.

OR

b)

Plan the configuration using redundant LAN and the redundancy ofassociations.

44 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 45: dn01141526_6_SIGTRAN

This mode should only be used when SCTP multi-homing cannot beused. EL0 and EL1 should get the same logical IP address.Associations are redundant in one signalling unit, so that if theprimary Ethernet port (for example, EL0) fails, another Ethernet port(EL1) can take the responsibility for the failed one. This givesredundancy only against Ethernet port failure or another HW failurein the network element.

This concept does not guarantee that none of the signallingmessages are lost during a short LAN failure. For more information,refer to the Control LAN descriptions in the network elementengineering descriptions.

2. Tune the SCTP parameters.

By tuning the SCTP parameters, a failure detection time ofassociation could be reduced to the same level as that of the SS7network or LAPD required. For more information on SCTPparameters, refer to section Modifying association parameters.

3. Plan IP addresses management and configuration.

Logical IP addresses should be used.

4. Create static IP routes (QKC).

Use logical static IP route configuration.

5. Configure port-based classification and marking (Q8N).

With this command, the operator can define protocol by protocolclassification to each of them individually.

6. Configure the LAN.

Configure the lower level LAN. For more information, refer to SiteConnectivity Guidelines.

Example

1. First configure a network interface(s) to unit(s).

ZQRA:SIGU,0::EL0;

ZQRA:SIGU,0::EL1;

ZQRA:SIGU,1::EL0;

DN01141526Issue 7-0 en

# Nokia Siemens Networks 45 (81)

Planning site configuration for signalling

Page 46: dn01141526_6_SIGTRAN

ZQRA:SIGU,1::EL1;

ZQRA:SIGU,2::EL0;

ZQRA:SIGU,2::EL1;

2. Configure VLAN interfaces (if desired).

Example ZQRA:SIGU,0::VLAN27,27,EL0;

3. Assign an IP address to the each available Ethernet interface.

ZQRN:SIGU,0::EL0:"131.228.40.10",24,L;

ZQRN:SIGU,0::EL1:"131.228.41.10",24,L;

And

ZQRN:SIGU,1::EL0:"131.228.40.11",24,L;

ZQRN:SIGU,1::EL1:"131.228.41.11",24,L;

And

ZQRN:SIGU,2::EL0:"131.228.40.12",24,L;

ZQRN:SIGU,2::EL1:"131.228.41.12",24,L;

4. Configure static routes.

ZQKC:SIGU,0::"132.228.45.0",24:"131.228.40.1":LOG:;

ZQKC:SIGU,0::"132.228.46.0",24:"131.228.41.1":LOG:;

And

ZQKC:SIGU,1::"132.228.45.0",24:"131.228.40.1":LOG:;

ZQKC:SIGU,1::"132.228.46.0",24:"131.228.41.1":LOG:;

And

ZQKC:SIGU,2::"132.228.45.0",24:"131.228.40.1":LOG:;

ZQKC:SIGU,2::"132.228.46.0",24:"131.228.41.1":LOG:;

46 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 47: dn01141526_6_SIGTRAN

5. Configure the DiffServ code value as '0' for the default SCTP port2905 (M3UA) and 9900 (IUA)

ZQ8N:132::2905:0;

ZQ8N:132::9900:0;

6. Modify MTU size if necessary.

If tunnelled connection is used, MTU size might be needed toreduce. Use ZQRA command for modification, e.g.

ZQRA:SIGU,0::EL0:1400;

Example

Using the redundant LAN concept to do the SCTP configuration.

1. Configure the VLAN interfaces (if desired).

2. Assign the same logical IP address to each available Ethernetinterface, one redundant pair is configured with one MML-command.

ZQRN:SIGU,0::EL0,EL1:"131.228.40.10",24,L;

And

ZQRN:SIGU,1::EL0,EL1:"131.228.40.11",24,L;

And

ZQRN:SIGU,2::EL0,EL1:"131.228.40.12",24,L;

3. Configure static routes.

ZQKC:SIGU,0::"132.228.45.0",24:"131.228.40.1":LOG:;

And

ZQKC:SIGU,1::"132.228.45.0",24:"131.228.40.1":LOG:;

And

ZQKC:SIGU,2::"132.228.45.0",24:"131.228.40.1":LOG:;

4. Configure the DiffServ code value as '0' for the default SCTP port2905 (M3UA) and 9900 (IUA).

ZQ8N:132::2905:0;

DN01141526Issue 7-0 en

# Nokia Siemens Networks 47 (81)

Planning site configuration for signalling

Page 48: dn01141526_6_SIGTRAN

ZQ8N:132::9900:0;

5. Modify the MTU size if necessary.

If a tunneled connection is used, then the MTU size might need to bereduced.

48 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 49: dn01141526_6_SIGTRAN

6 Planning M3UA network

Note

Remember to check if the association set and SCTP associationparameters you plan to use are compatible with the other end. For moreinformation, refer to section Modifying association set level parametersof M3UA and Modifying SCTP association parameters

Steps

1. Plan the redundancy of connections.

Spread M3UA associations to as many signalling units as possibleconsidering the number of units in both ends of the association set.Remember that 4-bit Signalling Link Selection (SLS) is used for loadsharing between associations, and that the number of associationsin an association set should be 2, 4, 8, or 16; otherwise, the load ineach association is not even and the unit load will not be even either.If an association set contains more than one SCTP association,each association can take care of the others' traffic if some of themfail.

The recommended number of SGs is two. For more information,refer to section MTP level signalling network in Common ChannelSignalling (MTP, SCCP and TC).

2. Plan what kind of a connection is used.

You should determine whether you are using an ASP-SGP or anIPSP-IPSP connection. For more information, refer to Use of M3UAstack.

3. Plan if Signalling Point Management Cluster is used or not.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 49 (81)

Planning M3UA network

Page 50: dn01141526_6_SIGTRAN

SPMC can be used if for some reason it is not possible to giveseparate SPC addresses to the SG and the network elementfunctioning as an ASP. SPMC configuration can also be used whendifferent M3UA configurations need to be used together. SPMC is aspecial configuration, through which it is not possible to direct trafficdestined to another DPC (STP traffic), but it is capable of receivingand handling the signalling traffic destined to the SPMC.

4. Plan the signalling route set parameters carefully.

The basic rule is that with signalling route set between MSS andMWG the IETF signalling route parameter set is used in case ofM3UA connection. All signalling route sets which are available viaMGW shall be configured so that a used signalling route parameterset is based on some of the MTP3 standards. That kind of parametersets are for example ITU-T and ANSI parameter sets.Thisrecommendation should be followed also with signalling route setswhich are leading to the BSC or RNC via MGW.

Note

Signalling route parameter set for A-interface (parameter set 1 listed byNNI MML command) shall be used only when signalling route set leadsdirectly to an adjacent signalling point.

5. Plan the SCCP level signalling network. Proceed with planningaccording to section SCCP level signalling network in CommonChannel Signalling (MTP, SCCP, and TC).

50 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 51: dn01141526_6_SIGTRAN

7 Creating M3UA configurationBefore you start

Create first the LAN configuration. For more information, refer to sectionPlanning site configuration for signalling.

Note

You should always use the logical IP address of the unit and logicalstatic route configuration when possible. Otherwise, there may beproblems after unit switchover.

Steps

1. Create an association set (OYC).

Remember to check if the association set parameters are correct.For more information, refer to section Modifying association set levelparameters of M3UA.

2. Add associations to the association set (OYA).

Note

By default, the number of stream in the M3UA association is 16. Itshould be noted that if other peer cannot support as many inboundstreams as the client has assigned an outbound stream, then SCTPprotocol establishes an association by using lower value of number ofstream. This should be taken into account when considering theresources of the client.

3. Configure transport addresses of SCTP association (OYP).

DN01141526Issue 7-0 en

# Nokia Siemens Networks 51 (81)

Creating M3UA configuration

Page 52: dn01141526_6_SIGTRAN

In this phase the operator defines the source and destination portnumbers and source and destination IP addresses for the SCTPassociation.

4. Check the associations (OYI).

Verify that the associations were created correctly and that theyhave correct IP addresses by using the OYI command.

5. Create IP type SS7 signalling link and link set (NSP).

In this step, the operator creates a signalling link set to destinationpoint. A network indicator value and signalling point code address ofdestination point are defined explicitly where the association set isconnected.

6. Create the SS7 signalling route set (NRC).

7. Activate the SCTP associations of the association set (OYS).

8. Activate the signalling network configuration.

The activation procedure is the same as when you create a non-IPconnection. When you activate an SS7 signalling link, the systemautomatically attempts to activate all the associations belonging tothe association set. The SS7 signalling link is active if at least oneassociation belonging to its association set is active. To interrogatethe states of the associations, use the OYI command. For moreinformation, refer to section Activating MTP configuration inCommon Channel Signalling (MTP, SCCP, and TC).

Further information:

Example: Creating IP configuration between MSS (client) and MGW(server).

Note

This is only one example of the M3UA usage. The configurationexample can be applied to all environments where the M3UA is plannedto be used.

The SIGU units of the MSS (MSS10) are as follows:

SIGU 0

EL0 131.228.40.10

EL1 131.228.41.10

52 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 53: dn01141526_6_SIGTRAN

SIGU 1

EL0 131.228.40.11

EL1 131.228.41.11

SIGU 2

EL0 131.228.40.12

EL1 131.228.41.12

The ISU units of the MGW (MGW400) are as follows:

ISU 0

EL0 132.228.45.4

EL1 132.228.46.4

ISU 1

EL0 132.228.45.5

EL1 132.228.46.5

ISU 2

EL0 132.228.45.6

EL1 132.228.46.6

Creating M3UA configuration in the MSS

Use these MML commands when creating M3UA configuration in theMSS.

1. Create an association set called MGW400.

ZOYC:MGW400:C;

2. Add three associations to the association set MGW400.

ZOYA:MGW400:SIGU,0,:SS7:;

ZOYA:MGW400:SIGU,1,:SS7:;

ZOYA:MGW400:SIGU,2,:SS7:;

3. Add SCTP transport addresses to the association.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 53 (81)

Creating M3UA configuration

Page 54: dn01141526_6_SIGTRAN

ZOYP:M3UA:MG-W400,0:"131.228.40.10","131.228.41.10":"131.228.4-5.4",24,"132.228.46.4",24,;

ZOYP:M3UA:MG-W400,1:"131.228.40.11","131.228.41.11":"131.228.4-5.5",24,"132.228.46.5",24,;

ZOYP:M3UA:MG-W400,2:"131.228.40.12","131.228.41.12":"131.228.4-5.6",24,"132.228.46.6",24,;

4. Verify the IP addresses in the association set MGW400.

ZOYI:NAME=MGW400:A;

5. Create an SS7 signalling link set to use the association setMGW400.

ZNSP:NA0,<signalling link set point code>,<signalling link set name>,<signalling link number>,:MGW400;

6. Create the SS7 signalling route set with the NRC command.

ZNRC:NA0:<signalling point code>, <signalling routeset name>;

7. Activate the SCTP associations.

ZOYS:M3UA:MGW400,0:ACT;

ZOYS:M3UA:MGW400,1:ACT;

ZOYS:M3UA:MGW400,2:ACT;

8. Activate the signalling links.

ZNLA:<signalling link number>;

ZNLC:<signalling link number>, ACT;

9. Activate Signalling route sets.

ZNVA:NA0,>signalling point code>:,;

ZNVC:NA0,<signalling point code>:,:ACT;

10. Interrogate Average M3UA CPU Load caused by M3UA connectionin the SIGU units during last 5 minutes period.

ZOYQ:SIGU,:;

54 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 55: dn01141526_6_SIGTRAN

The Average M3UA CPU Load can be interrogated if licence hasbeen purchased.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 55 (81)

Creating M3UA configuration

Page 56: dn01141526_6_SIGTRAN

56 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 57: dn01141526_6_SIGTRAN

8 Planning IUA network

Note

Remember to check if the SCTP association parameters you plan touse are compatible with the other end. For more information, refer tosection Modifying SCTP association parameters.

Steps

1. Plan the redundancy of connections.

Spread IUA associations to as many signalling units as possibleconsidering the number of units in both ends.

2. Plan D-channel configuration.

IUA connection always uses ASP-SGP configuration. The maximumnumber of D-Channel within SCTP association depends on thenumber of streams. For more information, refer to Use of IUA.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 57 (81)

Planning IUA network

Page 58: dn01141526_6_SIGTRAN

58 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 59: dn01141526_6_SIGTRAN

9 Creating IUA configurationBefore you start

Create first the LAN configuration. For more information, refer to sectionPlanning site configuration for signalling.

Note

You should always use the logical IP address of the unit and logicalstatic route configuration when possible. Otherwise, there may beproblems after unit switchover.

Steps

1. Create an association (OYX).

Remember to check if the SCTP association parameters are correct.For more information, refer to section Modifying SCTP associationparameters.

2. Configure SCTP association transport addresses (OYP)

ZOYP:IUA:MG-W400:"131.32.43.432","132.32.43.432":"131.21.23.2-34",24,"132.21.23.234",24,;

3. Check the associations (OYV).

Verify that the associations were created correctly and that theyhave correct IP addresses by using the OYV command.

4. Create D-channels (DWC).

5. Activate the association (OYS).

6. Activate the D-channel configuration (DWE).

DN01141526Issue 7-0 en

# Nokia Siemens Networks 59 (81)

Creating IUA configuration

Page 60: dn01141526_6_SIGTRAN

The activation procedure is the same as when you create a non-IPconnection. When you activate a D-channel, the systemautomatically attempts to activate the association. To interrogate thestates of the associations, use the OYV command.

Further information:

Example: Creating IP configuration for PBX between MSS (client) andMGW (server).

Note

Note that this is only one example of the IUA usage.

The SIGU units of the MSS (MSS10) are as follows:

SIGU 0

EL0 131.228.40.10

EL1 131.228.41.10

SIGU 1

EL0 131.228.40.11

EL1 131.228.41.11

SIGU 2

EL0 131.228.40.12

EL1 131.228.41.12

The ISU units of the MGW (MGW400) are as follows:

ISU 0

EL0 132.228.45.4

EL1 132.228.46.4

ISU 1

60 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 61: dn01141526_6_SIGTRAN

EL0 132.228.45.5

EL1 132.228.46.5

ISU 2

EL0 132.228.45.6

EL1 132.228.46.6

Creating an IUA configuration in the MSS

Use these MML commands when creating an IUA configuration in theMMS.

1. Create an association called MGW400.

ZOYX:MGW400:IUA:C:SIGU,0:IETF:;

2. Add SCTP transport addresses to the association.

ZOYP:IUA:MG-W400:"131.228.40.10","131.228.41.10":"131.228.45.-4",24,"132.228.46.4",24,;

3. Verify the IP addresses in the association MGW400.

ZOYV:NAME=MGW400:A;

4. Create the D-channels with the DWC command.

DWC:PBX2,2:SIGU,0:MGW400;

5. Activate the association.

ZOYS:IUA:MGW400:ACT;

6. Activate the D-channel.

ZDWE:PBX2:WO;

DN01141526Issue 7-0 en

# Nokia Siemens Networks 61 (81)

Creating IUA configuration

Page 62: dn01141526_6_SIGTRAN

62 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 63: dn01141526_6_SIGTRAN

10 Modifying Sigtran parameters

This section describes how to modify Sigtran parameters.

10.1 Modifying association set level parameters ofM3UA

Association set level parameters

NAME ASSOCIATION SET NAME

Symbolic name of the association set.

ROLE ASSOCIATION SET ROLE

The role of the association set (SERVER/CLIENT). Ifthe role of the association set is “Client”, then the ownpeer initializes all SCTP associations of thatassociation set. This parameter also controls functionof M3UA management. If the role is “client”, theexchange starts to ASP state managementprocedures and other peer only send anacknowledgement message in both ASP and IPSPcases.

VERSION M3UA SPECIFICATION VERSION

Used version of the M3UA specification. If otherpeers support a different version of the M3UA, thenthe version parameter should be changed to thesame version as that of the remote peer. The defaultis M3UA version 1.0 (RFC).

Supported versions are as follows:

5 ... M3UA SPECIFICATION VERSION 05 (DRAFT)

7 ... M3UA SPECIFICATION VERSION 07 (DRAFT)

9 ... M3UA SPECIFICATION VERSION 09 (DRAFT)

DN01141526Issue 7-0 en

# Nokia Siemens Networks 63 (81)

Modifying Sigtran parameters

Page 64: dn01141526_6_SIGTRAN

16 ... M3UA SPECIFICATION VERSION 1.0 (RFC)

Note

By default, Version 1.0 is used. Normally, there is no need to modify thisparameter except in very special cases.

TRAFFIC TRAFFIC MODE

Traffic mode of the association set. Two types oftraffic modes are supported: over-ride and loadsharing (default). This parameter controls how trafficis routed between SCTP associations into theassociation set.

ASP ASP MESSAGES

The parameter controls if ASP managementmessages (ASPTM and ASPSM) are used or not inthe association set. By default, ASP managementmessages are in use when the version 1.0 of theM3UA is used.

REG REGISTRATION REQUEST

The parameter controls if dynamic routing keyregistration is in use or not. By default, dynamicrouting key registration is used. However, if dynamicrouting key registration is not an option in thereceiving party's M3UA, this procedure may bedenied.

SSNM SSNM MESSAGES NEED TO BE BROADCASTEDTO ALL ASPS

The parameter controls the broadcast of the SSNMmessages. The broadcast of the SSNM messages toall active ASPs are not used normally.

If remote peer's implementation does not supportcentralized ASP management in the AS, the SSNMmessages may be needed to broadcast to eachactive ASPs. That feature can be used only withLoadsharing mode.

NETWORK NETWORK APPEARANCE

Network appearance which is used in the associationset in question. This is an optional parameter, andtherefore not necessarily supported in all M3UAimplementations. If not supported, Network

64 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 65: dn01141526_6_SIGTRAN

Appearance can be removed from SSNM messageswith the NNM command (Parameter Group D,parameter USE_OF_M3UA_NW_APP). From Datamessage Network Appearance can be removed sothat its value is modified as a maximum one.

0 - 4294967294 Range of Network Appearanceparameter value

4294967295 Network Appearance is not used in datamessage

IPSP SENDING OF ASP MESSAGES IN IPSPCONNECTION

The parameter controls the sending of ASPmanagement messages in the IPSP mode. When thisparameter is set on, the server also starts the ASPTMand ASPSM management sequences. In otherwords, the system works so called double endedIPSP-IPSP mode.

ROUTING ROUTING CONTEXT

The parameter is the defined value of the RoutingContext. The value of the Routing Context can beconfigured only when the registration requestparameter is inactive. This parameter needs to bemodified only in case of static configuration or in casewhen the remote peer does not support RoutingContext parameter. Routing Context parameter canget the following values:

0 - 4294967294 Range of Routing Context parametervalue

4294967295 Routing Context is not supported

FIRST FIRST DATA STREAM NUMBER

The parameter is defined as the number of the firstdata stream. Normally, the first data stream number is1. When M3UA version 1.0 is used, the first datastream must be 1.

The first data stream number might only be needed tobe modified in case where remote peer supportssome earlier M3UA draft specification.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 65 (81)

Modifying Sigtran parameters

Page 66: dn01141526_6_SIGTRAN

Each association set has its own parameters. In many cases, it is notnecessary to change the parameters. However, you may need to changethe parameters if the remote peer supports a different version of the M3UAspecification or the remote peer does not support all the optional M3UAfunctionalities.

The association set level parameters can be modified by using the OYMcommand. All of those parameters are related to the M3UA.

Note

The above parameters can be modified only when the association set isdeactivated. The association set can be deactivated by deactivating asignalling link which is using that association set.

Before you start

Steps

1. Check whether the parameters have suitable values (OYI).

The association set parameters can be interrogated with the OYIcommand.

2. Change the parameter values (OYM).

Find out the reason why and which parameters need to be changed.You can change the parameter values with the OYM command.

10.2 Modifying SCTP association level parameters

The SCTP association level parameters are the following. Theseparameters control how the SCTP association is working.

RTO.min The minimum value of retransmission time-out. If theRTO is computed to a lower value than RTO.min has,the RTO is rounded up to the value of the RTO.min.

This parameter is normally used to monitor the timeused in retransmitting. If the delay time of a SACKmessage from peer which acknowledges a sendingdata message exceeds the value of RTO.minrepeatedly, this value needs to be re-adjusted to LAN

66 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 67: dn01141526_6_SIGTRAN

capacity. If the message average Round-Trip Time(RTT) is less than 70 ms, the predefined parameterset (called SS7) can be used. Default value of RTO.min parameter is 150 ms in the SS7 parameter set.

Note

The value of RTO.min parameter should be at least twice bigger thanthe RTT value. By following this rule, unnecessary messageretransmissions are avoided.

RTO.max The maximum value of the retransmission time-out.The signalling common transport protocol (SCTP)increases the re-transmission time supervisionexponentially after each re-transmission attempt.When the computational RTO exceeds the value ofthe RTO.max parameter, the SCTP employs theRTO.max to monitor re-transmission.

Default value of the RTO.max parameter is 200 ms inthe predefined SS7 parameter set.

RTO.initial This parameter is used as default RTO value justafter an SCTP association is established. Thisparameter is used only for secondary path until thefirst heartbeat sequence is gone through.

SACK period A maximum delay which message receiver shall waitfor another data chunk until it shall send SACKmessage for an acknowledgement of a received datamessage.

The default value of the SACK period is 200 ms. TheSACK period can never be more than 500 ms.

HB.Interval This parameter is the basic value of the heartbeatinterval. The heartbeat interval in real life is the sumof the following parameters: HB.interval value, RTO.min, and the value of small random jitter. Used HB.interval value and the value of RTO.min come fromthe parameter set, but the value of jitter can be variedbetween networks and network elements.

Path.Max.Retrans This parameter defines a maximum number ofunacknowledged transmissions (includingheartbeats) per path. When this threshold value isreached, path is marked inactive.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 67 (81)

Modifying Sigtran parameters

Page 68: dn01141526_6_SIGTRAN

Association.Max.RetransThis parameter defines a maximum number ofunacknowledged transmissions (includingheartbeats) per association. When this thresholdvalue is reached, association is aborted.

CHECKSUM This parameter controls which Checksum method isused in an association.

The Adler-32 or the CRC32c method can be used,but the CRC32c checksum is recommended.CRC32c is used by default.

BUNDLING This parameter controls if the user application allowsor does not allow more than one chunk within theSCTP packet. By default bundling is used in thesystem.

Each user message occupies its own DATA chunk ifbundling is not allowed.

Note

Even if the bundling option is not set on, the SCTP stack might send theSCTP control message and data message within one datagram. Alsoretransmitted messages are allowed to send within one datagram evenif bundling parameter is denied that.

The SCTP parameters should be uniform at both ends of the SCTPassociation. The system includes two pre-packaged SCTP parametergroups. The first one contains the IETF compliant parameters, and thesecond one contains a pre-tuned parameter to ensure that the MTPperformance requirements of an SS7 network are met. The following tablesummarizes the differences of predefined parameter sets.

Table 1. Summary of suggested parameter sets

IETF SS7 GENERAL SATELLITE

RTO.min 1 s 150 ms 250 ms 750 ms

RTO.max 60 s 200 ms 400 ms 1.5 s

RTO.init 3 s 200 ms 200 ms 1 s

HB.interval 30 s 1 s 1 s 2 s

SACK.period 200 ms 110 ms 200 ms 200 ms

68 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 69: dn01141526_6_SIGTRAN

Table 1. Summary of suggested parameter sets (cont.)

IETF SS7 GENERAL SATELLITE

Path.Max.Retrans 5 2 2 2

Assoc.Max.Retrans 10 4 4 4

Check Sum CRC32c CRC32c CRC32c CRC32c

Bundling Yes Yes Yes Yes

Note

The pre-packaged parameters cannot be modified with the OYTcommand.

The IETF parameter set is offered the RFC 2960 comliant parameters forSCTP stack. This parameter set is not feasible for telecom signalingpurpose. It is more feasible with data oriented application like wwwbrowsing.

The SS7 parameter set is offered pre-tuned parameter for MTP3 likeconnection. This parameter set is designed to meet high performancerequirements of MSC Server System. It can be used with a connectionbetween Nokia MSS and MGW. Using SS7 parameter sets an exactingrequirement for WAN environment. For this reason, this parameter set isnot the best choice in all cases where traditional TDM-based connection isreplaced with signaling over IP system. It should be remembered that inboth peers this parameter set shall be used.

The General parameter set is designed for a case where Nokia system isused with the third party system. This parameter set takes into account adelay caused by a satellite.

It should be remembered that the pre-defined parameter sets are only oneexample of possible combinations of the SCTP parameters. Thatparameter set helps to start signalling transport over IP configuration.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 69 (81)

Modifying Sigtran parameters

Page 70: dn01141526_6_SIGTRAN

Note

The values of the Path.Max.Retrans and Association.Max.Retransparameters can be configured independently, but carelessconfiguration can lead an association to the state where all thedestination addresses of the peer are unreachable (so called dormantstate), but the peer stays in a reachable state. To avoid this situation,the user should avoid setting the value of the Association.Max.Retransparameter higher than the total sum of the values of Path.Max.Retransfor all the destination addresses of the peer.

When the capacity of the LAN is well-known and a better performanceof recovery is required, the operator can tune how the SCTPassociation is wanted to be worked by using the SCTP association levelparameters.

To modify the SCTP association level parameters, follow the steps below.

Modifying SCTP association level parameters

1. Create a new parameter set (OYE).

If you need to change the value of some SCTP parameters, create anew parameter set for this purpose.

ZOYE:TEST1:IETF:;

2. Check the value of the parameters (OYO).

Current parameter values can be interrogated with the OYOcommand.

3. Change the value of the parameters (OYT).

Change the value of the parameters if the correct parameters to bemodified and also the new values of these parameters are found.Change the parameter value with the OYT command.

4. Deactivate the association (OYS) or deactivate the association onassociation set one by one (OYS).

To deactivate the association, use the OYS command.

5. Change the parameter set of association set (OYM).

SCTP parameter set of M3UA association set can be changed withthe OYM command.

70 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 71: dn01141526_6_SIGTRAN

6. Change the parameter set of association (OYW).

SCTP parameter set of the IUA connection can be modified with theOYW command.

7. Activate the association (OYS).

Activate the association or associations of association set by usingthe OYS command.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 71 (81)

Modifying Sigtran parameters

Page 72: dn01141526_6_SIGTRAN

72 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 73: dn01141526_6_SIGTRAN

11 Deleting IP signalling links

This section describes how to delete the IP signalling links.

11.1 Deleting M3UA signalling links

Before you start

Remove first the SCCP and MTP3 levels. For more information, refer tosection Removing MTP signalling point in Common Channel Signalling(MTP, SCCP and TC).

Steps

1. Delete the signalling link set (NSD).

Delete the signalling link set with the NSD command.

2. Remove the unused association set (OYD).

ZOYD:<association set name>;

11.2 Deleting IUA connections

Steps

1. Delete the D-channels (DWD).

Delete the D-channel with the DWD command.

2. Remove the unused association (OYD).

ZOYD:<association set name>;

DN01141526Issue 7-0 en

# Nokia Siemens Networks 73 (81)

Deleting IP signalling links

Page 74: dn01141526_6_SIGTRAN

74 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 75: dn01141526_6_SIGTRAN

12 Signalling transport over IPtroubleshooting

This section describes what to do in different error situations.

12.1 IP signalling link activation fails

The procedure for checking IP type signalling links is different fromchecking ordinary signalling links. Follow the procedure if you have notbeen able to activate the IP signalling link you have created, and thesignalling link stays in the state UA-INS. For more information on the topic,refer to sectionSS7 troubleshooting in Common Channel Signalling (MTP,SCCP and TC).

Steps

1. Check the alarms (AHO).

a. Check the following alarms with the AHO command: 1273, 2069,3156, 3159, and 3155.

b. If there are any alarms, follow the alarm instructions.

2. Check the states and parameters of the association sets (OYI).

For more information, refer to Modifying association set levelparameters of M3UA.

a. Check the states and parameters of the association sets with theOYI command.

b. Check the SCTP level parameters. Checking is especiallyimportant in case of retransmission and also if the SCTP associationgoes down, but there is no LAN failure.

3. Check the signalling link parameter set and testing of links (NCI,NSI).

DN01141526Issue 7-0 en

# Nokia Siemens Networks 75 (81)

Signalling transport over IP troubleshooting

Page 76: dn01141526_6_SIGTRAN

Note

You need to complete this step only if the far end of the link is anothervendor's product or any of the following Nokia products: SCP, SMSC,3G-SGSN, or FlexiServer.

a. Check the signalling link parameter set with the NCI command.

The default value is 0.

b. Change the value to 7 with the NCL command.

c. Check with the NSI command if the testing of the link set is denied. Ifit is not, deny it with the NST command. The default testing of the M3UAlink set is denied.

4. Check if the IP addresses of the local signalling unit are correct

a. Check if the IP addresses of the local signalling unit are correctwith the QRIcommand.

b. Compare the IP addresses to the IP addresses assigned to theassociations at the far end.

c. Check possible error counters to IP stack with the QRS command.

For example:

ZQRS:<unit>::PRO;

d. Check possible errors from the POSIX kernel log with the PKLcommand.

Note

Connect a service terminal to the correct computer unit. Add thePOMOXIGX service terminal extension. You can use for example theletter P:

ZLP:P,POM

ZPKL

5. Check if source IP addresses of the association are correct.

a. Check the source IP addresses with the OYI command in case ofM3UA connection problem.

b. Check the static IP route configuration with the QKB command.

76 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 77: dn01141526_6_SIGTRAN

6. Check if correct checksum is used.

Checking whether correct checksum is used is especially importantwhen the DX200- or IPA-based network element works as a clientand a server comes from a third party.

Check the possible SCTP bad checksum counters with QRScommand.

7. Check the availability of the peer IP address with PING

Check the availability of the peer IP address with PING by using theQRX command.

8. Check the LAN cables.

Check the LAN cables and their connections.

9. Check the IP network configuration.

Check the router configuration and the site level LAN switchconfiguration. Pay attention to the following possible sources offailure:. MTU size. The default value is 1500 bytes. If tunnelled

connection is used, tuning the MTU size might be needed.. Bandwidth limit or packet rate limit. Check from core IP routers

if some bandwidth limits are set.. Check IP network settings such as speed and duplex mode

(these parameters will be the same in both ends of the link. Bydefault between ESB and DX200-based network element useauto-negotiation mode).

. Check STP/RSTP/MSTP setting in the layer 2 network.

. Check possible bottlenecks in the IP back bone.

. Check that the software version of routers and switches arecompliant.

10. Monitoring a failed connection with some IP network analyzer.

Good monitoring tools are for example DPDUMP or some Ethernetmonitoring tool. The last one is freeware software.

12.2 D-channel activation failed

Steps

1. Check the alarms (AHO).

a. Check the following alarms with the AHO command: 3159

DN01141526Issue 7-0 en

# Nokia Siemens Networks 77 (81)

Signalling transport over IP troubleshooting

Page 78: dn01141526_6_SIGTRAN

b. If there are any alarms, follow the alarm instructions.

2. Check the state of association and source and destination IPaddresses (OYV).

3. Check SCTP error counters and SCTP statistics (QRS).

4. Check the static IP route configuration.

Check the static IP route configuration with the QKB command.

5. Check if the IP addresses of the local signalling unit are correct

a. Check if the IP addresses of the local signalling unit are correct byusing the QRI command.

b. Compare the IP addresses to the IP addresses assigned for theassociations at the far end.

c. Check possible error counters to IP stack with the QRS command.

For example:

ZQRS:<unit>::PRO;

d. Check possible errors from the POSIX kernel log with the PKLcommand.

Note

Connect a service terminal to the correct computer unit. Add thePOMOXIGX service terminal extension. You can use for example theletter P:

ZLP:P,POM

ZPKL

6. Check the availability of the peer IP address with PING

Check the availability of the peer IP address with PING by using theQRX command.

7. Check the LAN cables.

Check the LAN cables and their connections.

8. Check the IP network configuration.

Check the router configuration and the site level LAN switchconfiguration. For more information, refer to section IP signalling linkactivation fails.

78 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 79: dn01141526_6_SIGTRAN

9. Check the D-channel configuration

Check the D-channel configuration from both peers (MSS andMGW). If the configuration is correct but is still not working, you cancheck the LAPD error counters from the MGW by using the DWNcommand.

12.3 SCTP association failed

Steps

1. Check the alarms (AHO).

a. Check the following alarm with the AHO command: 3159.

b. If there are any alarms, follow the alarm instructions.

2. Check the state of association and association set.

3. Check the SCTP error counters and SCTP statistics (QRS).

4. Check the static IP route configuration.

Check the static IP route configuration with the QKB command.

5. Check the availability of the peer IP address with PING

Check the availability of the peer IP address with PING by using theQRX command.

6. Check the LAN cables.

Check the LAN cables and their connections.

7. Check the IP network configuration.

Check the router configuration and the site level LAN switchconfiguration. For more information, refer to section IP signalling linkactivation fails.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 79 (81)

Signalling transport over IP troubleshooting

Page 80: dn01141526_6_SIGTRAN

12.4 Path of SCTP association failed

Steps

1. Check the alarms (AHO).

a. Check the following alarm with the AHO command:SCTP_path_failure_a (3379).

b. If there are any alarms, follow the alarm instructions.

2. Check the state of association or associations set.

3. Check the SCTP error counters and SCTP statistics (QRS).

4. Check the static IP route configuration.

Check the static IP route configuration with the QKB command.

5. Check the availability of the peer IP address via failed path withPING

Check the availability of the peer IP address with PING by using theQRX command.

6. Check the LAN cables.

Check the LAN cables and their connections.

7. Check the IP network configuration.

Check the router configuration and the site level LAN switchconfiguration. For more information, refer to section IP signalling linkactivation fails.

8. Check the used SCTP parameters in both peers.

a. Check the value of the SCTP parameters with OYO command.

b. If the SCTP parameters are different between peers, the value ofthe SCTP parameters should be harmonized in both ends.

12.5 List of debugging commands in a failure case

If the maintenance people cannot solve the failure by themselves andneed to contact NSNs customer care, the following information will help tofind out the root cause:

80 (81) # Nokia Siemens Networks DN01141526Issue 7-0 en

Signalling Transport over IP (M3UA and IUA)

Page 81: dn01141526_6_SIGTRAN

1. IP configuration (QRI)

2. Static IP route configuration (QKB)

3. SCTP association for M3UA (OYI)

4. IUA configuration (OYV)

5. SCTP parameters (OYO)

6. SCTP error counters (QRS with ALL and PRO)

7. DPDUMP monitoring or other monitoring from the ESB switches ifpossible.

DN01141526Issue 7-0 en

# Nokia Siemens Networks 81 (81)

Signalling transport over IP troubleshooting