Sig Tran

GSM/EDGE BSS, Rel. RG20(BSS), Operating Documentation, Issue 10

Signaling Transport over IP (M3UA and IUA)

DN01141526

Issue 14-0

Confidential

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their compo-nents.

If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Siemens Networks for any additional information.

2 DN01141526


Id:0900d805809528d3Confidential

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

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

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

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

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

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

Copyright © Nokia Siemens Networks 2012. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal, Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-satzes.

DN01141526 3



Table of contentsThis document has 52 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Signaling transport over IP (M3UA and IUA) . . . . . . . . . . . . . . . . . . . . . . 81.1 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.1 SCTP multi-homing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.2 SCTP stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Association set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 SGP-ASP communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4 IPSP-IPSP communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5 Signaling over IP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Use of M3UA stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1 SGP-ASP communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.1 Example of M3UA usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 IPSP-IPSP communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 Use of IPSP-IPSP example at the M3UA . . . . . . . . . . . . . . . . . . . . . . . 212.3 Routing key and routing context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4 Signaling Point Management Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5 Message structure of M3UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Use of IUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Message structure of IUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Basic structures of M3UA network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Planning site configuration for signaling . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Planning M3UA network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Creating M3UA configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Planning IUA network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9 Creating IUA configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

10 Modifying SIGTRAN parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4210.1 Modifying association set level parameters of M3UA . . . . . . . . . . . . . . 4210.2 Modifying SCTP association level parameters . . . . . . . . . . . . . . . . . . . 44

11 Deleting IP signaling links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4811.1 Deleting M3UA signaling links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4811.2 Deleting IUA connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

12 Signaling transport over IP troubleshooting. . . . . . . . . . . . . . . . . . . . . . 4912.1 IP signaling link activation fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4912.2 D-channel activation failed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5012.3 SCTP association failed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5112.4 Path of SCTP association failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5112.5 List of debugging commands in a failure case. . . . . . . . . . . . . . . . . . . . 52

4 DN01141526



List of figuresFigure 1 Association between two network elements . . . . . . . . . . . . . . . . . . . . . . . 9Figure 2 SCTP retransmission when both primary and secondary paths fail . . . . 10Figure 3 Symmetric network layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 4 Asymmetric network layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 5 Example of an IP type SS7 signaling link . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 6 Association set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 7 An example of SGP-ASP communication. . . . . . . . . . . . . . . . . . . . . . . . 15Figure 8 An example of a basic IPSP-IPSP configuration with a point to point con-

nection inside the IP network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Figure 9 An example of SGP-ASP communication. . . . . . . . . . . . . . . . . . . . . . . . 18Figure 10 An example of an SG between two network elements in different protocols

20Figure 11 An example of combined SG and IPSP-IPSP. . . . . . . . . . . . . . . . . . . . . 21Figure 12 An example of Signaling Point Management Cluster . . . . . . . . . . . . . . . 23Figure 13 Message structure of M3UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 14 IUA protocol (SGP-ASP mode). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 15 IUA protocol (IPSP-IPSP mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 16 Message structure of IUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 17 Basic example of a network that uses IP . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 18 An example of an M3UA network with SCCP relay function. . . . . . . . . . 29Figure 19 Avoiding large number of point-to-point IP routes. . . . . . . . . . . . . . . . . . 31

DN01141526 5



List of tablesTable 1 Summary of suggested parameter sets . . . . . . . . . . . . . . . . . . . . . . . . 45

6 DN01141526



DN01141526 7

Signaling Transport over IP (M3UA and IUA) Summary of changes

Id:0900d8058095290fConfidential

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

Changes made between issues 14-0 and 13-0Command for removing the unused association has been changed in section Deleting IUA connections, and a note has been added.

Changes made between issues 13-0 and 12-0A restriction on using of the same source port number on the server side has been added to section Association set and chapter Creating M3UA configuration.

Changes made between issues 12-0 and 11-0Added three SCTP parameter sets AFAST, AMEDI, and ASATEL to section Modifying SCTP association level parameters.

8 DN01141526


Id:0900d8058093c42dConfidential

Signaling transport over IP (M3UA and IUA)

1 Signaling transport over IP (M3UA and IUA)Signaling transport over IP (SIGTRAN) contains several user adaptation layers, 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-User signaling, for example ISDN user part (ISUP) and Signaling Connection Control Part (SCCP) mes-sages, over IP using the services of the Stream Control Transmission Protocol (SCTP). Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains.

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

g The Nokia Siemens Networks MSS product based upon the Advanced Telecommunica-tion Computing Architecture (ATCA) hardware is the Open Mobile Softswitch (Open MSS).

Both protocols are to be used between a signaling gateway (SG) and a media gateway controller (MGC). It is assumed that the SG receives SS7 signaling or Link Access Pro-cedure on the D-channel (LAPD) signaling over a standard E1 or T1 interface. SS7 sig-naling can also be received over ATM interface using the SS7 Message Transfer Part (MTP) to provide transport.

In a Base Station Controller (BSC), IUA can be used for the Abis interface (BSC-BTS interface). This so-called Packet Abis interface can be used as an alternative for LAPD-based Abis D-channels.

Signaling transport over IP offers almost similar quality of service as TDM-based signal-ing connection. This can be achieved by using modified SCTP transport parameters. In the planning phase of an IP signaling network, a used WAN and/or transmission network capacity and quality of service items shall be taken into account. It is very important especially when the SCTP parameters in use have been defined.

1.1 AssociationAn 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. If both communicating peers are based on our system, the SCTP association has been established between two signaling units by client peer. 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 is different, it means that a new associ-ation should be established. An association can have several logical paths (source and destination IP address pair); that kind of connection is called multi-homed connection. SCTP can use multi-homed connection but a TCP does not know that kind of architec-ture. For this reason, an SCTP association is much more fault tolerant than a TCP con-nection.

For the above mentioned Signaling adaptations to work as solidly as their examples (Q.921 and Q.704), the SCTP has been used in implementation as the data link layer. SCTP offers similar certification capacities as can be expected when using a traditional

DN01141526 9

Signaling Transport over IP (M3UA and IUA) Signaling transport over IP (M3UA and IUA)


TDM connection. To meet the traditional quality requirements when using the SCTP, the retransmission parameters of the SCTP must be adjusted so that the criteria will be met also when using the IP-net. When readjusting SCTP retransmission parameters you need 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 most crucial criteria of these is the transit time delay.

The Client peer establishes an association. The system supports two destination IP addresses; primary destination IP address and secondary destination IP address. During the association establishing phase the Client normally sends an SCTP initialize message to the primary destination IP address. If the primary destination IP address does not respond to anything, the Client tries to establish an association to the second-ary destination IP address. When the network failure in the primary network is over, the system changes a configuration so that signaling traffic is running over the primary network and the secondary network is running a backup mode.

Figure 1 Association between two network elements

1.1.1 SCTP multi-homingIn the IP terminology, a host is called multi-homed if it can be addressed by multiple IP addresses. To make full use of the SCTP multi-homing, the host also needs to support multiple network interfaces, each of which has to 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, for example, for load balancing. The SCTP implementation supports two paths per association. Normally data is sent through the primary path. If a network failure occurs in the primary network, SCTP resends unacknowledged data through the sec-ondary path automatically. The application cannot see which path is used and it does not affect sending of data traffic in application level either. In this case, the SCTP stack takes care of all the details.

The SCTP association works normally so that data runs through the primary path and SCTP heartbeat runs through the secondary path. If something unexpected happens in the primary path, the SCTP usually has an alternative path available. The SCTP

OpenMSS

GISU Signalingend point

AHUB3-A

AHUB3-A

Association

10 DN01141526




monitors a condition of the secondary path all the time by using a heartbeat message. The following figure describes how the SCTP retransmission works when both the primary and the secondary paths failed. The retransmission procedure starts always the same way; the first retransmission is done through the secondary path. The example above is based on the following SCTP parameters:

• 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 Modifying SCTP associ-ation level parameters.

Figure 2 SCTP retransmission when both primary and secondary paths fail

The SCTP sends data first through the primary path. It starts the retransmission timer and starts to wait for the SACK message from the remote peer. If the retransmission timer expires, the SCTP re-sends data through the secondary path and restarts the retransmission timer again by using the same value as before. If the remote peer does not send any SACK before the retransmission timer expires again, the sending peer re-sends data packets through the primary path and doubled the value of the retransmis-sion timer. If new retransmission timer value is greater than the RTO.max value, the SCTP starts using the value of the RTO.max parameter as a new retransmission timer. If both paths are totally out of order, 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 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 the value of assoc.max.retrans, the sending peer stops trying to resend data and closes an asso-ciation by sending an ABORT message to remote peer.

There are two types of SCTP multi-homing.

End Point A End Point B

Primary Path

Secondary Path300ms

300msPrimary Path

Secondary Path500ms

500ms

Primary pathUnavailable

Abort

DN01141526 11



Figure 3 Symmetric network layout

The first type is symmetric SCTP multi-homing where both peers have two or more external Ethernet interfaces available and connection is made between them. Each sig-naling unit contains two Ethernet Interfaces in network element. The SCTP can use both interfaces in such a way that one is working as a primary and the other one as a sec-ondary path. The SCTP ensures that none of the messages can get lost if only one path is broken at the same time. Each Ethernet port should belong to a different subnetwork of the signaling unit, otherwise multi-homed connections do not work as expected.

Figure 4 Asymmetric network layout

The second type is asymmetric multi-homing where the configuration also has two separate paths but Host A has only one Ethernet port in use. Two IP addresses should be assigned to the only Ethernet port of Host A. This additional address of Host A should be taken into account in the network configuration of the routers as well.

If Host A is assigned to a second network, then the resiliency of the network can be improved. As a result of this modification, in case of any kind of network failure, multi-homing helps to avoid association loss. But not even this helps if the only Ethernet port of Host A or the gateway router where it is connected to fails.

g Optimally, the SCTP multi-homing configuration is symmetric, but it can also be asym-metric. However, asymmetric configuration is not recommended since it does not offer entire end-to-end path redundancy. Sometimes it has to be done for interoperability reason.

1.1.2 SCTP streamSCTP provides multiple stream function within an SCTP association. SCTP uses streaming for message ordering. Each independently ordered message sequence is called a stream. Stream is unidirectional, which means that the number of outbound streams and the number of inbound streams can be different. The number of data streams can vary from one to thousands. The main purpose of the stream is to avoid so

HOST A HOST B

HOST A HOST B

12 DN01141526




called head of line blocking situation, especially when only one SCTP association is in use between network elements. Alternatively, this can be avoided by using multiple associations. Used number of outbound streams depends on SCTP applications because application should tag each of its outbound messages with a stream identifier. Outbound stream number 0 might be used for special purpose. For example in IUA and M3UA user adaptations are required that only management message is allowed to use a stream 0 and therefore the first data stream is 1.

In M3UA implementation it is possible to use multiple streams for data messages. Man-agement messages are always sent to stream 0. It is possible to configure with an asso-ciation set parameter whether the data stream is 0 or 1. It is recommended to use multiple data streams; in that case the first data stream is always 1. Number of streams per association is 16 in the M3UA, except when remote end supports fewer streams than local end wants to use. In that case the system is using lower number of streams automatically.

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

1.2 Association setA system is based on a distributed architecture so that there are several computer units which can do same kinds of tasks. M3UA has been planned to work in such a system. In that way, system resources can be used more efficiently.

SCTP association is a point-to-point connection between two end points (see the follow-ing figure). In our system, an IP end point is a signaling unit. A network element may contain tens of signaling units. If more signaling capacity is needed between two network elements, signaling capacity can be increased by adding more SCTP associa-tions to the association set. In this case, it is assumed that each SCTP association is created to different signaling unit. By using multiple signaling units in one association set (one association per signaling unit), you share the load among more than one computer units and at the same time make the signaling connection redundant. One signaling unit can be connected to multiple association sets if the network element also needs to com-municate with other peers.

DN01141526 13



Figure 5 Example of an IP type SS7 signaling link

Additionally, when there are multiple association sets between two network elements, it is recommended that the signaling unit is only connected to one association set. For example, if support of multiple SS7 networks is required in the network planning, then more than one association set between two network elements must be created. In some case it might be necessary to create multiple associations, which are connected to the same signaling unit, in the association set. That is not recommended but it is possible to do when the network planning has not been able to do in other way.

In that case, the source port (client) and the destination port (server) must be other than ephemeral, using some unambiguous port number not used in any other association. That is because the server end maps an upcoming association to an association set based on:

• own signaling unit having association • destination port • destination IP address

If those all are identical for more than one server association in different association sets, then the M3UA layer cannot map the corresponding association to the association set unambiguously, when the M3UA layer receives notification of a new active associa-tion from SCTP.

There is a restriction on the server side that the same source port number (e.g. the default 2905) cannot be used for two server associations residing in the same signaling unit, if the source IP addresses used are different for those server associations in the same unit. So if different source IP addresses are needed for two server associations residing in the same signaling unit, then you also need to configure different source ports for those associations. Note also that under the same port number there cannot be both single-homed and multi-homed associations.

On the M3UA, each IP signaling link is associated with an association set consisting of up to 32 SCTP associations. However, for ordered messages, for which the SLS is used for load sharing, traffic is shared to a maximum of 16 first activated SCTP associations. Up to 32 active associations can be used for a case where unordered messages are used. Unordered message mode is possible only with an interface where SCCP protocol

Open MSS (client)

GISU 0

GISU 1

GISU 2

IP network

MGW (server)

ISU 0

ISU 1

ISU 2

Association set /SS7 signaling link set

Association

ISU 3 GISU 3

14 DN01141526




class 0 has been used. The state of a signaling link follows the state of the association set; when at least one SCTP association is active inside the association set, the signal-ing link is active.

Figure 6 Association set

Used load sharing method of the M3UA depends on a signaling traffic. If signaling traffic requires an ordered delivery, then SLS value is used for load sharing. That means that all signaling messages with same SLS are delivered through the same association inside the association set. In case of association failure, it is necessary to update the routing table of association set. When association failure is over, the content of associ-ation set routing table is required to be exactly the same as it was before the failure.

g Association set is related to Nokia Siemens Networks distributed architecture, and it is a Nokia Siemens Networks specific concept. Association set concept is only used in M3UA connections.

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 communicationSignaling gateway process (SGP) is a signaling agent that sends and receives telecom signaling traffic at the edge of the IP network. Signaling gateway (SG) is as a signaling converter where TDM or ATM based signaling connection is terminated.

Signaling route set

Signaling link

Signaling link set

Association

Association

Association

Association set

DN01141526 15



Application server is a kind of virtual database or call control element, which can serve a specific routing key. As mentioned earlier, DPC is used as a routing key in the solution. According to IETF-RFC 2719: Framework Architecture for Signaling Transport , Frame-work Architecture for signaling transport, SGP-ASP communication based on IP network as transportation. The SGP-ASP concept is described in figure An example of SGP-ASP communication.

Figure 7 An example of SGP-ASP communication

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

1.4 IPSP-IPSP communicationIn the case of IPSP-IPSP communication, the services of an SG node are not needed, since both peers exist in the IP domain. A group of IPSPs form an Application server at both ends of the signaling connection. The message exchange in an IPSP-IPSP con-nection is single-ended by default, where only one endpoint sends ASP management messages. The other possibility is the dual-ended mode, where both endpoints send ASP management messages.

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

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

Applications

AdaptationLayers

SCTP

IP

Applications

AdaptationLayers

SCTP

IP

IPSP-IPSP

16 DN01141526




1.5 Signaling over IP statisticsIUA-specific statistics are not available yet. In the signaling unit level, the Sigtran traffic can be monitored from the SCTP stack counters. The SCTP statistics counters offer overall number of SCTP traffic in the signaling unit. Those counters contain traffic from all SCTP user adaptations, and therefore those counters are not so useful if one is inter-ested only in the traffic of specific SCTP user adaptation. The SCTP statistics counters are possible to see by using the QRS MML command.

The Interrogate Average M3UA CPU Load, OYQ MML command helps in dimensioning the network. It also enables more efficient troubleshooting and network management.

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

M3UA Association Set Measurement (295H/661) can be used to monitor M3UA traffic. It gives information on traffic through put and quality of M3UA connections. The mea-surement measures M3UA traffic from M3UA layer and SCTP layer. The M3UA Associ-ation Set measurement can be started and stopped with the MML commands of the T2 command group. For more information on the M3UA Association Set Measurement, see NSS Statistics, Reports (Part 3), Operating Instructions and NSS Statistics, Operating Instructions.

M3UA layer counters tell the payload of the SCTP connection. From the counters of the SCTP layer, the operator can retrace the traffic of the SCTP layer used by M3UA asso-ciation. The SCTP layer counters give the operator more accurate information on the real load required for sending M3UA traffic through SCTP by including the number of retransmitted SCTP packets and SCTP header.

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

Measurement is configured by using the common statistics interface T2 MML com-mands.

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 and IUA for Packet Abis:Number of SCTP packets received

Number of SCTP packets sent

DN01141526 17



Number of SCTP octets received

Number of SCTP octets sent

Number of retransmitted SCTP packets

Number of duplicated TSN received (not supported in IUA for Packet Abis)

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

If the M3UA-specific statistics are not available, the M3UA traffic can be monitored by using the MTP3 level matrix measurements. The MTP3 matrix measurement is based on using an OPC, DPC, and SI matrix. The matrix defines a connection which traffic will be measured. This measurement shows an amount of specific signaling traffic between two signaling points. Service Indicator (SI) defines a concerned signaling traffic and OPC and DPC parameters tell which ones of the signaling points belong to a measure-ment. The MTP3 matrix measurement can be configured by using the OI MML com-mands.

18 DN01141526


Id:0900d805808cbe44Confidential

Use of M3UA stack

2 Use of M3UA stackThis section describes the use of M3UA stack.

2.1 SGP-ASP communicationThe signaling gateway process-application server process (SGP-ASP) communication is needed when communicating between the MTP3 peers in SS7 and IP domains. To enable the communication, a seamless interworking 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 com-munication the related concepts are AS, ASP, SG, and SGP.

Figure 9 An example of SGP-ASP communication

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

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

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

SGAS

SGP

SGP

ASP

ASP

ASP

DN01141526 19

Signaling Transport over IP (M3UA and IUA) Use of M3UA stack


In communication between Nokia Siemens Networks network elements, the AS and SG concepts are mapped to network elements, for example, AS = MSS, SG = Multimedia Gateway (MGW). Furthermore, the signaling units in those network elements are mapped to ASPs inside the MSS and SGPs inside the MGW.

When a signaling message arrives to the SG from an SS7 link, the M3UA routing function determines first the association set based on comparing the information in the message with a provisioned Routing Key (DPC+NI). Inside the association set an asso-ciation is selected, based on the SLS value, and the signaling message is forwarded to the signaling unit where the association exists. With IETF concepts, in the Nokia Siemens Networks routing function the SGP (the signaling unit) and the ASP (associa-tion) 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 Siemens Networks network element at the peer, it is recommended that there is only one association in one signaling 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 network element collecting all ASPs con-nected to each SGP (signaling unit).

In Nokia Siemens Networks implementation each association can carry only the signal-ing traffic related to one routing key. That is why it is not necessary to configure a routing context. The static configuration of the routing context is 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 value is saved to a work file for possible further use in ASPTM messages.

2.1.1 Example of M3UA usageSignaling messages from the PSTN are addressed to the server network element. A sig-naling route goes via the SG, where a protocol change from SS7 to SIGTRAN is done. Signaling messages from the server are destined to the SCCP in the PSTN network element. A signaling route goes via the SG, where a protocol change from SIGTRAN to SS7 is done. There may have STP points in the SS7 path between the SG and the des-tination PSTN network element.

20 DN01141526



Use of M3UA stack

Figure 10 An example of an SG between two network elements in different protocols

When the SGP-ASP communication is used, signaling messages from the PSTN are destined to the server with SPC addressing. A signaling route goes via the SG, where the protocol changes from SS7 to SIGTRAN. This is similar to the previous example, where the message does not go to the SCCP level in the SG.

Signaling messages from the server are destined to the SG with SPC addressing. A sig-naling route goes via the SG, where the protocol changes from SIGTRAN to SS7. This is similar to the previous example, where the message does not go to the SCCP level in the SG.

2.2 IPSP-IPSP communicationThe IPSP-IPSP (IP server process) communication and the SGP-ASP communication are not different except for the fact that the SG functionality is not needed at either end-point. The configuration, association, and the IPSP activation are the same. The IPSP-IPSP is two kind of functional mode. If the dual ended mode of the IPSP-IPSP configu-ration is wanted, the 'ASP MESSAGES IN IPSP' and the 'ASP MESSAGES' parameters should have the value 'Y' at both endpoints of the signaling link. In single ended mode, only the 'ASP MESSAGES' parameter should have the value 'Y' at both endpoints. If both parameters have the value 'N', the applications erver process state maintenance message (ASPSM) and application server process traffic manintenance message (ASPTM) messages are not exchanged at all.

The IPSP-IPSP connection can be used point-to-point between the M3UA users. For example, when the SG is able to do the GT translation or when there is an SCCP relay in the IP network, the following connection is IPSP-IPSP.

PSTN Signaling gateway Server

MAP MAP

MTP

SCCP

TC

MTP

M3UA

SCTP

IP

M3UA

SCTP

IP

TC

SCCP

DN01141526 21



2.2.1 Use of IPSP-IPSP example at the M3UA

Figure 11 An example of combined SG and IPSP-IPSP

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

When the IPSP-IPSP communication is used, signaling messages from the public switched telephone network (PSTN) are destined to the SG with GT addressing. The GTT in the signaling connection control part (SCCP) of the SG gives as a result the SCCP peer located in the IP network. The signaling messages from the server are destined to the SG with global title (GT) addressing. The global title translation (GTT) in the SCCP of the SG gives as a result the SCCP peer located in the SS7 network. In this case, the connection between the SG and the server is an IPSP-IPSP connection.

2.3 Routing key and routing contextThe distribution of the SS7 messages between the SGP and the Application Servers is determined by the routing keys and their associated routing contexts.

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

The DPC and network appearance together form the only routing key that is supported. Both are also mandatory parameters in the routing key. The network appearance maps to a network indicator. The network appearance parameter is included in the association set parameters. The other parameters: SI, SSN, or CIC are not included in the routing key because it is expected that the network element operating as an AS can handle the

PSTN Signaling gateway Server

MAP MAP

MTP

SCCP

TC

MTP

M3UA

SCTP

IP

SCCP

IPSP-IPSPor SGP-ASP

M3UA

SCTP

IP

TC

SCCP

22 DN01141526



Use of M3UA stack

message distributing function itself. This especially applies to the SGP when there is a Nokia Siemens Networks network element at the peer.

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

Routing context values are either configured using a configuration management inter-face, or by using specific procedures of routing key management. In the case of static configuration, the operator can configure the value of the routing context manually. Dynamic Routing Key registration is used by default, but if you want to have a static con-figuration for some reason (for example, insure compatibility against other vendors' product), refer to MML commands of the OY command group.

2.4 Signaling Point Management ClusterSignaling Point Management Cluster (SPMC) is an example of a configuration where two network elements share a Signaling Point Code (SPC). The SPMC is an entity which consists of the SG and Application Node, but is visible to other network elements only with one signaling point identity, that of the Application Node. MTP level 2 connections and other MTP functionalities of an SPMC are in the SG, while the User Part function-ality of the cluster is in the Application Node. When the MTP of the SG receives a User Part message destined to the management cluster, it forwards the message to the Appli-cation Node.

A signaling management cluster is applicable when a signaling point becomes an Appli-cation Node as it is connected to an SG, and therefore stripped of its MTP level 2 con-nections to other network elements. Then other network elements need no configuration changes, as they see nothing from the management cluster but the same old signaling point code. One practical example of transition from signaling points to signaling man-agement clusters is the migration from Mobile Switching Centers (MSCs) to MSSs and MGWs. The migration can be done without configuration changes to PSTN or public land mobile network (PLMN) network elements by the management cluster.

A management cluster may also be needed with the MSS concept in IU- or A-interface, because some radio network controller implementation supports only associated signal-ing mode. However, it is not mandatory to use the management cluster in the MSS migration. Nokia Siemens Networks recommends that with the MSS concept the quasi-associated signaling mode is used, that is, MGW is used as an STP, which makes it possible to design a signaling network more redundant.

DN01141526 23



Figure 12 An example of Signaling Point Management Cluster

g Signaling Point Management Cluster shall be used only between one MSS and one MGW. Signaling Point Management Cluster does not work according to the specifica-tions if more than one MGW is configured.

2.5 Message structure of M3UAThe basic overhead on SIGTRAN contains the following message headers: IP, SCTP, and M3UA.

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

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

• The size of the Common Message header of the M3UA is 8 bytes. The Common message header exists in every M3UA message. The main part of the bit rate is gen-erated from the payload data messages. Therefore, an example describes only the structure of the payload data. The optional Network Appearance parameter is used in M3UA. Its size is 8 bytes. The Routing label of the MTP3 message is encoded in separate fields. The OPC and DPC fields are both 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 the Payload Data message.

TMSC

DPC=123,NI=8

TDM SG ASPM3UA

24 DN01141526



Use of M3UA stack

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

DN01141526 25

Signaling Transport over IP (M3UA and IUA) Use of IUA

Id:0900d805808cbf34Confidential

3 Use of IUAIUA provides a solution for standalone MSS to control PBX connections over the IP network. In this solution, D-channels are terminated into the SG, for example MGW. The Control Plane of the PBX connection is transported between MGW and MSS over the IP network by using the IUA protocol. The solution comes from the IETF working group (SIGTRAN). The IUA protocol is needed in case an MSS has only IP interfaces avail-able.

IUA uses the SGP-ASP mode where MGW works as an SG and MSS works as an AS. This mode is similar to the M3UA SGP-ASP mode. Here, Q.921 protocol is terminated in the SG. The application which controls the PBX connection is located in the MSS.

Figure 14 IUA protocol (SGP-ASP mode)

In BSC, IUA can be used for the Packet Abis interface.

Figure 15 IUA protocol (IPSP-IPSP mode)

3.1 Message structure of IUAThe basic overhead on SIGTRAN contains the following message headers: IP, SCTP, and IUA.

Q.931

Q.921 Q.921

IUA

SCTP

IP

IUA

SCTP

IP

Q.931

PBX MSS

MGW(SG)

ISDN IP

IUA

SCTP

IP

ABIS

BTS

IP

IUA

SCTP

IP

ABIS

BSC

26 DN01141526



Use of IUA

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

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

• The IUA message starts a Common message header. The size of the Common header is 8 bytes. Immediately after the Common header is the IUA message header. RFC 3057 defines integer based or text based IUA message headers. Nokia Siemens Networks product supports only the integer based IUA header, and its fixed length is 16 bytes. A tag after 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.

DN01141526 27

Signaling Transport over IP (M3UA and IUA) Use of IUA


Figure 16 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)

IPve

rsio

n4

he

ad

er

SC

TP

Com

mon

header

and

paylo

ad

data

IUA

co

mm

on

he

ad

ers

an

dp

roto

co

ld

ata

0 31

28 DN01141526


Id:0900d805808cbf7aConfidential

Basic structures of M3UA network

4 Basic structures of M3UA networkWhen the IP transport is used in the signaling network, the SEP network element is usually in the IP network. The separator (SEP) network element acts as an AS; it is con-nected to the time-division multiplexing (TDM) network via an SG, that is, a network element working in both network types. The AS can be a server or a database, but also any other network element where signaling is transported via the IP network.

Figure 17 Basic example of a network that uses IP

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

When the IP connection is used, the signaling unit must have an Ethernet port, through which it can be connected to the network element internal LAN.

In the IP network, M3UA signaling is implemented as point-to-point signaling. The M3UA specification does not describe the M3UA level STP functionality; however, the STP functionality is implemented in the network elements according to the ITU-T Q.704 rec-ommendation.

SEP

STP

STP

SG

SG

SEPIP

DN01141526 29

Signaling Transport over IP (M3UA and IUA) Basic structures of M3UA network

Id:0900d805808cbf7aConfidential

Figure 18 An example of an M3UA network with SCCP relay function

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

Use of STPsTo 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 associa-tions between SEPs, the implementation and O&M work required for maintaining a full-mesh network in large networks would require too much effort. Here the use of SIGTRAN STPs becomes possible. In the networks which already have STPs, some of them 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 connected to each other via TDM or ATM-based connections. At least where SRRi is used for free numbering or mobile number portability, the signaling has to go 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 calculating the bit rate offered to the IP backbone as each message has to travel several times via the backbone (unless it is intra-site). There should always be at least two STPs in physically separate sites to allow redundancy.

TMSC

MSS

HLR

SCP

SMSC

IPSP - IPSP

IPMSC

SRRi

SRRiTMSC MGW

MGW

30 DN01141526


Id:0900d805808cbf8eConfidential

Planning site configuration for signaling

5 Planning site configuration for signalingThis procedure lists the things you need to consider when planning the site configuration for signaling over IP solutions. It may not be necessary to do the steps in the order they are presented here.

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

It is recommended that the same DiffServ is used for all SCTP associations in the asso-ciation set in the M3UA. The settings of the DiffServ code used for M3UA signaling are common to all those applications whose traffic goes via the same SCTP association.

The maximum delay that is allowed between the network elements is not specified. See Q.706 ITU-T recommendation for reference. An application of the M3UA sets real limits. The M3UA does not contain for example signaling link switchover within signaling link set, and therefore it cannot achieve the same service level as MTP3 in message trans-port. Packet loss 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 SCTP parameters are necessary for the associations to function according to the Q.706 ITU-T recommendation.

You can either plan a redundant LAN and the redundancy of associations or plan the LAN using SCTP multi-homing. Choose one of the alternatives described in the first step below. Redundancy of associations can be handled on several levels:

• on the network element level: If signaling units are configured with logical IP addresses (which is highly recommended), it is possible to do a signaling unit swi-tchover procedure so that the current M3UA configuration 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 remain the same.

2. Static IP routes should be logical.This helps to make a static IP-route configuration and ensure that after the unit swi-tchover signaling connection works as before the unit switchover.

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

One example of how large number of point-to-point IP routes can be avoided:

DN01141526 31

Signaling Transport over IP (M3UA and IUA) Planning site configuration for signaling


Figure 19 Avoiding large number of point-to-point IP routes3. Signaling 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 con-figuration ensures that the primary path is separated from the secondary path.

g If a signaling computer unit needs to have both single-homed and multi-homed server associations, it is not allowed to use same IP address and same source port number for both associations. For example, it is recommended to use different source port number for each association.

4. Point-to-point message travelling time should be explored.If the failure detection time has been planned, it is important to reduce it to the same level as that of the SS7 network by tuning the SCTP parameters.

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

32 DN01141526




StepsIf the system is taken into use for the first time, you should create the IP configuration before creating the SCTP association. Creation of logical IP address in the signaling unit changes the unit automatically from the SP-EX state to the WO-EX state.

g Please note the difference between the concepts of redundant LAN and SCTP multi-homing. The redundant LAN means that the system contains a standby Ethernet Inter-face. In the redundant LAN configuration both Ethernet ports of signaling unit have the same logical IP address but only one of them is in active state. In the SCTP multi-homing configuration both Ethernet ports of signaling unit have own logical IP address from dif-ferent IP subnetworks, so that both Ethernet Interfaces 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 the recommended redundancy mode for sig-naling. It is recommended to use a symmetric configuration in the case of SCTP multi-homing. For more information on SCTP configurations, see section SCTP multi-homing.ORb)Plan the configuration using redundant LAN and the redundancy of associations.This mode should only be used when SCTP multi-homing cannot be used. EL0 and EL1 should get the same logical IP address. Associations are redundant in one sig-naling unit, so that if the primary Ethernet port (for example, EL0) fails, another Ethernet port (EL1) can take the responsibility for the failed one. This gives redun-dancy only against Ethernet port failure or another HW failure in the network element.This concept does not guarantee that none of the signaling messages are lost during a short LAN failure. For more information, refer to the Control LAN descriptions in the network element engineering descriptions.

2. Tune the SCTP parameters.By tuning the SCTP parameters, a failure detection time of association could be reduced to the same level as that of the SS7 network or LAPD required. For more information on SCTP parameters, refer to section Modifying association parame-ters.

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 protocol classification to each of them individually.

6. Configure the LAN.Configure the lower level LAN. For more information, refer to Site Connectivity Guidelines.

DN01141526 33

Signaling Transport over IP (M3UA and IUA) Planning site configuration for signaling


Example:

1. First configure a network interface(s) to unit(s).ZQRA:GISU,0::EL0;ZQRA:GISU,0::EL1;ZQRA:GISU,1::EL0;ZQRA:GISU,1::EL1;ZQRA:GISU,2::EL0;ZQRA:GISU,2::EL1;

2. Configure VLAN interfaces (if desired).Example ZQRA:GISU,0::VLAN27,27,EL0;

3. Assign an IP address to each available Ethernet interface.ZQRN:GISU,0::EL0:"131.228.40.10",24,L; ZQRN:GISU,0::EL1:"131.228.41.10",24,L;AndZQRN:GISU,1::EL0:"131.228.40.11",24,L; ZQRN:GISU,1::EL1:"131.228.41.11",24,L; AndZQRN:GISU,2::EL0:"131.228.40.12",24,L;ZQRN:GISU,2::EL1:"131.228.41.12",24,L;

4. Configure static routes.ZQKC:GISU,0::"132.228.45.0",24:"131.228.40.1":LOG:;ZQKC:GISU,0::"132.228.46.0",24:"131.228.41.1":LOG:;AndZQKC:GISU,1::"132.228.45.0",24:"131.228.40.1":LOG:;ZQKC:GISU,1::"132.228.46.0",24:"131.228.41.1":LOG:; AndZQKC:GISU,2::"132.228.45.0",24:"131.228.40.1":LOG:;ZQKC:GISU,2::"132.228.46.0",24:"131.228.41.1":LOG:;

5. Configure the DiffServ code value as '0' for the default SCTP port 2905 (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 need to be reduced. Use the ZQRA command for modification, e.g.ZQRA:GISU,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 Ethernet interface, one redun-

dant pair is configured with one MML-command.ZQRN:GISU,0::EL0,EL1:"131.228.40.10",24,L; AndZQRN:GISU,1::EL0,EL1:"131.228.40.11",24,L; AndZQRN:GISU,2::EL0,EL1:"131.228.40.12",24,L;

34 DN01141526




3. Configure static routes.ZQKC:GISU,0::"132.228.45.0",24:"131.228.40.1":LOG:;AndZQKC:GISU,1::"132.228.45.0",24:"131.228.40.1":LOG:;AndZQKC:GISU,2::"132.228.45.0",24:"131.228.40.1":LOG:;

4. Configure the DiffServ code value as '0' for the default SCTP port 2905 (M3UA) and 9900 (IUA).ZQ8N:132::2905:0;ZQ8N:132::9900:0;

5. Modify the MTU size if necessary.If a tunneled connection is used, then the MTU size might need to be reduced.

g • For the Open MSS, the signaling unit is the Generic Signaling Unit (GISU). • For the Flexi NS - SGSN, the signaling unit is the Signaling and Mobility Manage-

ment Unit (SMMU). • For the classic BSC, the signaling unit is the Base Station Controller Signaling Unit

(BCSU). • For the multicontroller BSC (mcBSC), the signaling unit is the Multicontroller BSC

Signaling Unit (BCXU).

DN01141526 35

Signaling Transport over IP (M3UA and IUA) Planning M3UA network

Id:0900d805808cbfa0Confidential

6 Planning M3UA network

g Remember to check if the association set and SCTP association parameters you plan to use are compatible with the other end. For more information, refer to sections Modi-fying association set level parameters of M3UA and Modifying SCTP association level parameters.

Steps

1. Plan the redundancy of connections.Spread M3UA associations to as many signaling units as possible considering the number of units in both ends of the association set. Remember that 4-bit Signaling Link Selection (SLS) is used for load sharing between associations, and that the number of associations in an association set should be 2, 4, 8, or 16; otherwise, the load in each 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 them fail.The recommended number of SGs is two. For more information, refer to section MTP level signaling network in Common Channel Signaling (MTP, SCCP and TC).

2. Plan what kind of a connection is used.You should determine whether you are using an SGP-ASP or an IPSP-IPSP con-nection. For more information, refer to Use of M3UA stack.

3. Plan if Signaling Point Management Cluster is used or not.SPMC can be used if for some reason it is not possible to give separate SPC addresses to the SG and the network element functions as an ASP. SPMC config-uration can also be used when different M3UA configurations need to be used together. SPMC is a special configuration, through which it is not possible to direct traffic destined to another DPC (STP traffic), but it is capable of receiving and handling the signaling traffic destined to the SPMC.

4. Plan the signaling route set parameters carefully.The basic rule is that with signaling route set between MSS and MGW, the IETF sig-naling route parameter set is used in the case of M3UA connection. All signaling route sets which are available via MGW shall be configured so that a used signaling route parameter set is based on some of the MTP3 standards. That kind of param-eter sets are for example ITU-T and ANSI parameter sets.This recommendation should be followed also with signaling route sets which are leading to the BSC or RNC via MGW.

g Signaling route parameter set for A-interface (parameter set 1 listed by the NNI MML command) shall be used only when signaling route set leads directly to an adjacent signaling point.

5. Plan the SCCP level signaling network. Proceed with planning according to section SCCP level signaling network in Common Channel Signaling (MTP, SCCP, and TC).

36 DN01141526


Id:0900d80580938ef6Confidential

Creating M3UA configuration

7 Creating M3UA configurationBefore you startCreate first the LAN configuration. For more information, refer to section Planning site configuration for signaling.

g You should always use the logical IP address of the unit and logical static route config-uration when possible. Otherwise, there may be problems after unit switchover.

Steps

1. Create an association set (OYC).Remember to check if the association set parameters are correct. For more informa-tion, refer to section Modifying association set level parameters of M3UA.

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

g By default, the number of streams in the M3UA association is 16. It should be noted that if other peer cannot support as many inbound streams as the client has assigned an outbound stream, then SCTP protocol establishes an association by using lower value of number of streams. This should be taken into account when considering the resources of the client.

3. Configure transport addresses of SCTP association (OYP).In this phase the operator defines the source and destination port numbers and source and destination IP addresses for the SCTP association. There is a restriction on the server side that the same source port number (e.g. the default 2905) cannot be used for two server associations residing in the same signaling unit, if the source IP addresses used are different for those server associations in the same unit. So if different source IP addresses are needed for two server associations residing in the same signaling unit, then you also need to configure different source ports for those associations. Note also that under the same port number there cannot be both single-homed and multi-homed associations.

4. Check the associations (OYI).Verify that the associations were created correctly and that they have correct IP addresses by using the OYI command.

5. Create IP type SS7 signaling link and link set (NSP).In this step, the operator creates a signaling link set to destination point. A network indicator value and signaling point code address of destination point are defined explicitly where the association set is connected.

6. Create the SS7 signaling route set (NRC).7. Activate the SCTP associations of the association set (OYS).8. Activate the signaling network configuration.

The activation procedure is the same as when you create a non-IP connection. When you activate an SS7 signaling link, the system automatically attempts to activate all the associations belonging to the association set. The SS7 signaling link is active if at least one association belonging to its association set is active. To inter-rogate the states of the associations, use the OYI command. For more information, refer to section Activating MTP configuration in Common Channel Signaling (MTP, SCCP, and TC).

DN01141526 37

Signaling Transport over IP (M3UA and IUA) Creating M3UA configuration


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

g This is only one example of the M3UA usage. The configuration example can be applied to all environments where the M3UA is planned to be used.

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

GISU 0

EL0 131.228.40.10

EL1 131.228.41.10

GISU 1

EL0 131.228.40.11

EL1 131.228.41.11

GISU 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 MSSUse these MML commands when creating M3UA configuration in the MSS.

1. Create an association set called MGW400.ZOYC:MGW400:C;

2. Add three associations to the association set MGW400.ZOYA:MGW400:GISU,0,:SS7:;ZOYA:MGW400:GISU,1,:SS7:;ZOYA:MGW400:GISU,2,:SS7:;

3. Add SCTP transport addresses to the association.ZOYP:M3UA:MGW400,0:"131.228.40.10","131.228.41.10":"131.228.45.4",24,"132.228.46.4",24,;ZOYP:M3UA:MGW400,1:"131.228.40.11","131.228.41.11":"131.228.45.5",24,"132.228.46.5",24,;ZOYP:M3UA:MGW400,2:"131.228.40.12","131.228.41.12":"131.228.45.6",24,"132.228.46.6",24,;

4. Verify the IP addresses in the association set MGW400.ZOYI:NAME=MGW400:A;

38 DN01141526



Creating M3UA configuration

5. Create an SS7 signaling link set to use the association set MGW400.ZNSP:NA0,<signalling link set point code>,<signalling link set name>,<signalling link number>,:MGW400;

6. Create the SS7 signaling route set with the NRC command.ZNRC:NA0:<signalling point code>,<signalling route set name>,<parameter set number>,,:,,,<signalling route priority>;

7. Activate the SCTP associations.ZOYS:M3UA:MGW400,0:ACT;ZOYS:M3UA:MGW400,1:ACT;ZOYS:M3UA:MGW400,2:ACT;

8. Activate the signaling links.ZNLA:<signalling link number>;ZNLC:<signalling link number>,ACT;

9. Activate signaling route sets.ZNVA:NA0,<signalling point code>:,;ZNVC:NA0,<signalling point code>:,:ACT;

10. Interrogate Average M3UA CPU Load caused by M3UA connection in the GISU units during last 5 minutes period. ZOYQ:GISU,:;The Average M3UA CPU Load can be interrogated if license has been purchased.

DN01141526 39

Signaling Transport over IP (M3UA and IUA) Planning IUA network

Id:0900d805808cbfb2Confidential

8 Planning IUA network

g Remember to check if the SCTP association parameters you plan to use are compatible with the other end. For more information, refer to section Modifying SCTP association level parameters.

Steps

1. Plan the redundancy of connections.Spread IUA associations to as many signaling units as possible considering the number of units in both ends.

2. Plan D-channel configuration.IUA connection always uses SGP-ASP configuration. The maximum number of D-channels within SCTP association depends on the number of streams. For more information, refer to Use of IUA.

40 DN01141526


Id:0900d805808cbfd2Confidential

Creating IUA configuration

9 Creating IUA configurationBefore you startCreate first the LAN configuration. For more information, refer to section Planning site configuration for signaling.

g You should always use the logical IP address of the unit and logical static route config-uration when possible. Otherwise, there may be problems after unit switchover.

The procedures of creating IUA configuration for PBX support and Packet Abis differ slightly.

Creating IUA configuration for PBX support

Steps

1. Create an association (OYX).Remember to check if the SCTP association parameters are correct. For more infor-mation, refer to section Modifying SCTP association parameters.

2. Configure SCTP association transport addresses (OYP)ZOYP:IUA:MGW400:"131.32.43.432","132.32.43.432":"131.21.23.234",24,"132.21.23.234",24,;

3. Check the associations (OYV).Verify that the associations were created correctly and that they have 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).

The activation procedure is the same as when you create a non-IP connection. When you activate a D-channel, the system automatically attempts to activate the association. To interrogate the states of the associations, use the OYV command.

Creating IUA configuration for Packet Abis

Steps

1. Create an association (OYX).Remember to check if the SCTP association parameters are correct. For more infor-mation, refer to section Modifying SCTP association parameters.

2. Configure SCTP association transport addresses (OYP)ZOYP:IUA:MGW400:"131.32.43.432","132.32.43.432":"131.21.23.234",24,"132.21.23.234",24,;

3. Check the associations (OYV).Verify that the associations were created correctly and that they have correct IP addresses by using the OYV command.

4. Create D-channels (DWP).5. Activate the association (OYS).

D-channels become active when the association is up and the Base Station Control Functions (BCF) initialize interface identifier for D-channels.

Further information:Example: Creating IP configuration for PBX between MSS (client) and MGW (server).

DN01141526 41

Signaling Transport over IP (M3UA and IUA) Creating IUA configuration

Id:0900d805808cbfd2Confidential

g This is only one example of the IUA usage.

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

GISU 0

EL0 131.228.40.10

EL1 131.228.41.10

GISU 1

EL0 131.228.40.11

EL1 131.228.41.11

GISU 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 an IUA configuration in the MSSUse these MML commands when creating an IUA configuration in the MSS.

1. Create an association called MGW400.ZOYX:MGW400:IUA:C:GISU,0:IETF:;

2. Add SCTP transport addresses to the association.ZOYP:IUA:MGW400:"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:IUA:NAME=MGW400:A;

4. Create the D-channels with the DWC command.DWC:PBX2,2:GISU,0:MGW400;

5. Activate the association.ZOYS:IUA:MGW400:ACT;

6. Activate the D-channel.ZDWE:PBX2:WO;

42 DN01141526


Id:0900d8058091c339Confidential

Modifying SIGTRAN parameters

10 Modifying SIGTRAN parametersThis section describes how to modify SIGTRAN parameters.

10.1 Modifying association set level parameters of M3UAAssociation set level parametersNAME ASSOCIATION SET NAME

Symbolic name of the association set.

ROLE ASSOCIATION SET ROLE

The role of the association set (SERVER/CLIENT). If the role of the association set is “client”, then the own peer initializes all SCTP associ-ations of that association set. This parameter also controls function of M3UA management. If the role is “client”, the exchange starts to ASP state management procedures and other peer only send an acknowl-edgement message in both ASP and IPSP cases.

VERSION M3UA SPECIFICATION VERSION

Used version of the M3UA specification. If other peers support a differ-ent version of the M3UA, then the version parameter should be changed to the same version as that of the remote peer. The default is M3UA version 1.0 (RFC).

Supported versions are as follows:

5 ... M3UA SPECIFICATION VERSION 05 (DRAFT)



16 ... M3UA SPECIFICATION VERSION 1.0 (RFC)

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

TRAFFIC TRAFFIC MODE

Traffic mode of the association set. Two types of traffic modes are sup-ported: over-ride and load sharing (default). This parameter controls how traffic is routed between SCTP associations into the association set.

ASP ASP MESSAGES

The parameter controls if ASP management messages (ASPTM and ASPSM) are used or not in the association set. By default, ASP man-agement messages are in use when the version 1.0 of the M3UA is used.

REG REGISTRATION REQUEST

The parameter controls if dynamic routing key registration is in use or not. By default, dynamic routing key registration is used. However, if dynamic routing key registration is not an option in the receiving party's M3UA, this procedure may be denied.

SSNM SSNM MESSAGES NEED TO BE BROADCASTED TO ALL ASPS

DN01141526 43

Signaling Transport over IP (M3UA and IUA) Modifying SIGTRAN parameters


The parameter controls the broadcast of the SSNM messages. The broadcast of the SSNM messages to all active ASPs are not used nor-mally.

If remote peer's implementation does not support centralized ASP man-agement in the AS, the SSNM messages may be needed to broadcast to each active ASPs. That feature can be used only with Loadsharing mode.

NETWORK NETWORK APPEARANCE

Network appearance which is used in the association set in question. This is an optional parameter, and therefore not necessarily supported in all M3UA implementations. If not supported, Network Appearance can be removed from SSNM messages with the NNM command (Parameter Group D, parameter USE_OF_M3UA_NW_APP). From Data message Network Appearance can be removed so that its value is modified as a maximum one.

0 - 4294967294 Range of Network Appearance parameter value

4294967295 Network Appearance is not used in data message

IPSP SENDING OF ASP MESSAGES IN IPSP CONNECTION

The parameter controls the sending of ASP management messages in the IPSP mode. When this parameter is set on, the server also starts the ASPTM and ASPSM management sequences. In other words, the system works in the so called double ended IPSP-IPSP mode.

ROUTING ROUTING CONTEXT

The parameter is the defined value of the Routing Context. The value of the Routing Context can be configured only when the registration request parameter is inactive. This parameter needs to be modified only in the case of static configuration or when the remote peer does not support Routing Context parameter. Routing Context parameter can get the following values:

0 - 4294967294 Range of Routing Context parameter value

4294967295 Routing Context is not supported

FIRST FIRST DATA STREAM NUMBER

The parameter is defined as the number of the first data stream. Nor-mally, the first data stream number is 1. When M3UA version 1.0 is used, the first data stream must be 1.

The first data stream number might only be needed to be modified in the case where remote peer supports some earlier M3UA draft specifica-tion.

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

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

44 DN01141526




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

Before you startSteps

1. Check whether the parameters have suitable values (OYI).The association set parameters can be interrogated with the OYI command.

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 parametersThe SCTP association level parameters are the following. These parameters control how the SCTP association is working.

RTO.min The minimum value of retransmission time-out. If the RTO 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 time used in retransmit-ting. If the delay time of a SACK message from peer which acknowl-edges a sending data message exceeds the value of RTO.min repeatedly, this value needs to be re-adjusted to LAN capacity. If the message average Round-Trip Time (RTT) is less than 70 ms, the pre-defined parameter set (called SS7) can be used. Default value of RTO.min parameter is 150 ms in the SS7 parameter set.

g The value of RTO.min parameter should be at least twice bigger than the RTT value. By following this rule, unnecessary message retransmis-sions are avoided.

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

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

RTO.initial This parameter is used as default RTO value just after an SCTP asso-ciation is established. This parameter is used only for secondary path until the first heartbeat sequence is gone through.

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

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

HB.Interval This parameter is the basic value of the heartbeat interval. The heart-beat interval in real life is the sum of the following parameters: HB.inter-val value, RTO.min, and the value of small random jitter. Used

DN01141526 45



HB.interval value and the value of RTO.min come from the parameter set, but the value of jitter can be varied between networks and network elements.

Path.Max.Retrans This parameter defines a maximum number of unacknowledged transmissions (including heartbeats) per path. When this threshold value is reached, path is marked inactive.

Association.Max.Retrans This parameter defines a maximum number of unacknowl-edged transmissions (including heartbeats) per association. When this threshold value is reached, association is aborted.

CHECKSUM This parameter controls which Checksum method is used in an associ-ation.

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

BUNDLING This parameter controls if the user application allows or does not allow more than one chunk within the SCTP packet. By default bundling is used in the system.

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

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

The SCTP parameters should be uniform at both ends of the SCTP association. The system includes five pre-packaged SCTP parameter groups. The first one contains the IETF compliant parameters, and the second one contains a pre-tuned parameter to ensure that the MTP performance requirements of an SS7 network are met. Parameter sets AFAST, AMEDI, and ASATEL are for Packet Abis IUA usage, between BSC and BTS. The following table summarizes the differences of predefined parameter sets.

g The pre-packaged parameters cannot be modified with the OYT MML command.

IETF SS7 AFAST AMEDI ASATEL GENERAL SATELLITE

RTO.min 1 s 150 ms 150 ms 300 ms 750 ms 250 ms 750 ms

RTO.max 60 s 200 ms 400 ms 750 ms 2 s 400 ms 1.5 s

RTO.init 3 s 200 ms 200 ms 500 ms 1 s 200 ms 1 s

HB.interval 30 s 1 s 1 s 1 s 1 s 1 s 2 s

SACK.period 200 ms 110 ms 120 ms 200 ms 200 ms 200 ms 200 ms

Path.Max.Retrans 5 2 4 4 5 2 2

Assoc.Max.Retrans 10 4 5 5 5 4 4

Check Sum CRC32 CRC32 CRC32 CRC32 CRC32 CRC32 CRC32

Bundling Yes Yes Yes Yes Yes Yes Yes

Table 1 Summary of suggested parameter sets

46 DN01141526




The IETF parameter set is offered the RFC 2960 comliant parameters for SCTP stack. This parameter set is not feasible for telecom signaling purpose. It is more feasible with data oriented application like www browsing.

The SS7 parameter set is offered pre-tuned parameter for MTP3 like connection. This parameter set is designed to meet high performance requirements of MSS System. It can be used with a connection between Nokia Siemens Networks MSS and MGW. Using SS7 parameter sets an exacting requirement for WAN environment. For this reason, this parameter set is not the best choice in all cases where traditional TDM-based connection is replaced with signaling over IP system. It should be remembered that in both peers this parameter set shall be used.

The AFAST parameter set has tighter retransmission timer values than the AMEDI parameter set, so AFAST notices the IP connectivity failures quicker, but it may result in obsolete path failures if the RTT between BSC and BTS may be bigger in some situa-tions. Ping command (QRX) could be used to determine the RTT value during different times of day to figure out the RTT and which parameter set (AFAST or AMEDI) to use.

The ASATEL parameter set takes into account the delay caused by satellite in the Packet Abis interface.

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

It should be remembered that the pre-defined parameter sets are only one example of possible combinations of the SCTP parameters. That parameter set helps to start sig-naling transport over IP configuration.

g The values of the Path.Max.Retrans and Association.Max.Retrans parameters can be configured independently, but careless configuration can lead an association to the state where all the destination addresses of the peer are unreachable (so called dormant state), but the peer stays in a reachable state. To avoid this situation, the user should avoid setting the value of the Association.Max.Retrans parameter higher than the total sum of the values of Path.Max.Retrans for all the destination addresses of the peer.

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

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 a new parameter set for this purpose.ZOYE:TEST1:IETF:;

2. Check the value of the parameters (OYO).Current parameter values can be interrogated with the OYO command.

3. Change the value of the parameters (OYT).Change the value of the parameters if the correct parameters to be modified and also the new values of these parameters are found. Change the parameter value with the OYT command.

DN01141526 47



4. Deactivate the association (OYS) or deactivate the association on association 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 with the OYM command.

6. Change the parameter set of association (OYW).SCTP parameter set of the IUA connection can be modified with the OYW command.

7. Activate the association (OYS).Activate the association or associations of association set by using the OYS command.

g It is also possible to modify SCTP parameters that are already in an active association. You can modify the parameters with the OYT command. But in order to bring the param-eter change into effect, you need to take one of the following actions:

• Deactivate the M3UA link with the NLC command and then activate the M3UA link again with the NLC command.

• Deactivate the SCTP association with the OYS command and then activate the SCTP association again with the OYS command.

48 DN01141526



Deleting IP signaling links

11 Deleting IP signaling linksThis section describes how to delete the IP signaling links.

11.1 Deleting M3UA signaling linksBefore you startRemove first the SCCP and MTP3 levels. For more information, refer to section Removing MTP signaling point in Common Channel Signaling (MTP, SCCP and TC).

Steps

1. Delete the signaling link set (NSD).Delete the signaling link set with the NSD command.

2. Remove the unused association set (OYD).ZOYD:<association set name>;

11.2 Deleting IUA connectionsSteps

1. Delete the D-channels (DWD).Delete the D-channel with the DWD command.

2. Remove the unused association (OYY).ZOYY:<SCTP user>:<SCTP association name>;

g The association state shown in the execution printout of the OYY command is always SCTP_DOWN.

DN01141526 49

Signaling Transport over IP (M3UA and IUA) Signaling transport over IP troubleshooting

Id:0900d805808cc026Confidential

12 Signaling transport over IP troubleshootingThis section describes what to do in different error situations.

12.1 IP signaling link activation failsThe procedure for checking IP type signaling links is different from checking ordinary signaling links. Follow the procedure if you have not been able to activate the IP signal-ing link you have created, and the signaling link stays in the state UA-INS. For more information on the topic, refer to section SS7 troubleshooting in Common Channel Sig-naling (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 level parameters of M3UA.a. Check the states and parameters of the association sets with the OYI command.b. Check the SCTP level parameters. Checking is especially important in case of retransmission and also if the SCTP association goes down, but there is no LAN failure.

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

g You need to complete this step only if the far end of the link is another vendor's product or any of the following Nokia Siemens Networks products: SCP, SMSC, 3G-SGSN, or FlexiServer.a. Check the signaling 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. If it is not, deny it with the NST command. The default testing of the M3UA link set is denied.

4. Check if the IP addresses of the local signaling unit are correcta. Check if the IP addresses of the local signaling unit are correct with the QRI command.b. Compare the IP addresses to the IP addresses assigned to the associations 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 PKL command.

g Connect a service terminal to the correct computer unit. Add the POMOXIGX service terminal extension. You can use for example the letter P:ZLP:P,POMZPKL

50 DN01141526



Signaling transport over IP troubleshooting

5. Check if source IP addresses of the association are correct.a. Check the source IP addresses with the OYI command in case of M3UA connec-tion problem.b. Check the static IP route configuration with the QKB command.

6. Check if correct checksum is used.Checking whether correct checksum is used is especially important when the Nokia Siemens Networks network element works as a client and a server comes from a third party.Check the possible SCTP bad checksum counters with the QRS command.

7. Check the availability of the peer IP address with PINGCheck the availability of the peer IP address with PING by using the QRX 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 switch configuration. Pay attention to the following possible sources of failure: • 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 band-

width 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. By default between ESB and DX 200-based network element use auto-negotiation mode).

• Check 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 are compliant.

10. Monitoring a failed connection with some IP network analyzer.Good monitoring tools are for example DPDUMP or some Ethernet monitoring tool. The last one is freeware software.

12.2 D-channel activation failedSteps

1. Check the alarms (AHO).a. Check the following alarms with the AHO command: 3159b. If there are any alarms, follow the alarm instructions.

2. Check the state of association and source and destination IP addresses (OYV).3. Check SCTP error counters and SCTP statistics (QRS).4. Check the static IP route configuration (QKB).5. Check if the IP addresses of the local signaling unit are correct

a. Check if the IP addresses of the local signaling unit are correct by using the QRI command.b. Compare the IP addresses to the IP addresses assigned for the associations 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 PKL command.

DN01141526 51

Signaling Transport over IP (M3UA and IUA) Signaling transport over IP troubleshooting


g Connect a service terminal to the correct computer unit. Add the POMOXIGX service terminal extension. You can use for example the letter P:ZLP:P,POMZPKL

6. Check the availability of the peer IP address with PING (QRX).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 switch configuration. For more information, refer to section IP signaling link activation fails.

9. Check the D-channel configurationCheck the D-channel configuration from both peers (MSS and MGW). If the config-uration is correct but is still not working, you can check the LAPD error counters from the MGW by using the DWN command.

12.3 SCTP association failedSteps

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 (OYV and OYI).3. Check the SCTP error counters and SCTP statistics (QRS).4. Check the static IP route configuration (QKB).5. Check the availability of the peer IP address with PING (QRX).6. Check the LAN cables.



12.4 Path of SCTP association failedSteps

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 (OYV and OYI).3. Check the SCTP error counters and SCTP statistics (QRS).4. Check the static IP route configuration (QKB).5. Check the availability of the peer IP address via failed path with PING (QRX).6. Check the LAN cables.



52 DN01141526



Signaling transport over IP troubleshooting

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 of the SCTP parameters should be harmonized in both ends.

12.5 List of debugging commands in a failure caseIf the maintenance people cannot solve the failure by themselves and need to contact NSNs customer care, the following information will help to find out the root cause:

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 switches if possible.

Sig Tran

Documents