Issue 12

Issue 12

Dialogic

®

SS7 Protocols

MTP2 Programmer’s Manual

www.dialogic.com

Copyright© 2004-2010 Dialogic Corporation. All Rights Reserved. You may not reproduce this document in whole or in part without permission in writing from Dialogic Corporation at the address provided below.

All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a commitment on the part of Dialogic Corporation or its subsidiaries ("Dialogic").

Reasonable effort is made to ensure the accuracy of the information contained in the document. However,

Dialogic does not warrant the accuracy of this information and cannot accept responsibility for errors, inaccuracies or omissions that may be contained in this document.

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC

®

PRODUCTS. NO LICENSE,

EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED

BY THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC,

DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED

WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR

WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF

ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY.

Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications.

Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific countries, and thus may not function properly in other countries. You are responsible for ensuring that your use of such products occurs only in the countries where such use is suitable. For information on specific products, contact Dialogic Corporation at the address indicated below or on the web at www.dialogic.com.

It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in marketing collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectual property rights owned by third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic products other than a license to use such product in accordance with intellectual property owned or validly licensed by Dialogic and no such licenses are provided except pursuant to a signed agreement with Dialogic. More detailed information about such intellectual property is available from Dialogic's legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec,

Canada H4M 2V9. Dialogic encourages all users of its products to procure all necessary intellectual property licenses required to implement any concepts or applications and does not condone or encourage any intellectual property infringement and disclaims any responsibility related thereto.

These intellectual property licenses may differ from country to country and it is the responsibility of those who develop the concepts or applications to be aware of and comply with different national license requirements.

Dialogic, Dialogic Pro, Brooktrout, Diva, Diva ISDN, Making Innovation Thrive, Video is the New Voice, Diastar,

Cantata, TruFax, SwitchKit, SnowShore, Eicon, Eicon Networks, NMS Communications, NMS (stylized),

Eiconcard, SIPcontrol, TrustedVideo, Exnet, EXS, Connecting to Growth, Fusion, Vision, PacketMedia,

NaturalAccess, NaturalCallControl, NaturalConference, NaturalFax and Shiva, among others as well as related logos, are either registered trademarks or trademarks of Dialogic Corporation or its subsidiaries. Dialogic's trademarks may be used publicly only with permission from Dialogic. Such permission may only be granted by

Dialogic's legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9. Any authorized use of Dialogic's trademarks will be subject to full respect of the trademark guidelines published by

Dialogic from time to time and any use of Dialogic's trademarks requires proper acknowledgement.

The names of actual companies and products mentioned herein are the trademarks of their respective owners.

Publication Date: May 2010

Document Number: 05-2331-003, Issue 12

2

SS7 Protocols MTP2 Programmer’s Manual Issue 12

Contents

1

2

3

4

5

Introduction ............................................................................................................. 6

1.1

Applicability ....................................................................................................... 6

1.2

Related Information ............................................................................................ 6

Functional Overview ................................................................................................. 7

2.1

MTP2 Module Overview........................................................................................ 7

2.2

Feature Overview................................................................................................ 7

2.3

General Description............................................................................................. 8

2.4

Physical Layer Configuration................................................................................10

Message Reference ..................................................................................................11

3.1

Protocol Requests from MTP3 to MTP2 ..................................................................11

3.1.1

API_MSG_TX_REQ – Message for Transmission Request ...............................13

3.1.2

SS7_MSG_START – MTP2 Start Request.....................................................14

3.1.3

SS7_MSG_STOP – MTP2 STOP Request......................................................15

3.1.4

SS7_MSG_EMGCY – MTP2 Set Emergency Request......................................16

3.1.5

SS7_MSG_EMGCY_CLRD – MTP2 Cancel Emergency Request ........................17

3.1.6

SS7_MSG_RTV_BSNT – MTP2 BSNT Retrieval Request .................................18

3.1.7

SS7_MSG_RTVL_REQ – MTP2 Retrieval Request..........................................19

3.1.8

SS7_MSG_LOC_PR_OUT – MTP2 LPO Request ............................................20

3.1.9

SS7_MSG_LOC_PR_OK – MTP2 LPO Recovered Request ...............................21

3.1.10 SS7_MSG_L3_FAIL – MTP2 Level 3 Failure Request .....................................22

3.1.11 SS7_MSG_FLUSH – MTP2 Flush Request ....................................................23

3.1.12 SS7_MSG_CONTINUE – MTP2 Continue Request .........................................24

3.2

Protocol Indications from MTP2 to MTP3................................................................25

3.2.1

API_MSG_RX_IND – Received Message Indication .......................................26

3.2.2

SS7_MSG_IN_SVC – MTP2 In Service Indication .........................................27

3.2.3

SS7_MSG_OUT_SVC – MTP2 Out of Service Indication.................................28

3.2.4

SS7_MSG_REM_PR_OUT – MTP2 RPO Indication .........................................29

3.2.5

SS7_MSG_REM_PR_OK – MTP2 RPO Cleared Indication ...............................30

3.2.6

SS7_MSG_RXD_BSNT – MTP2 BSNT Indication ...........................................31

3.2.7

API_MSG_RTVD_MSG – MTP2 Retrieved Message Indication .........................32

3.2.8

SS7_MSG_RTVL_COMPL – MTP2 Retrieval Complete Indication .....................33

3.2.9

SS7_MSG_RTVL_NOT_POS – MTP2 Retrieval Failure Indication......................34

3.2.10 MTP_MSG_LINK_CONG – MTP2 Link Congested Indication............................35

3.2.11 MTP_MSG_LINK_UNCONG – MTP2 Congestion Cleared Indication ..................36

3.2.12 MTP_MSG_FLUSH_ACK – MTP2 Flush Acknowledgement Indication................37

3.3

Management Requests Sent to MTP2 ....................................................................38

3.3.1

SS7_MSG_RESET – MTP2 Module Reset Request .........................................39

3.3.2

SS7_MSG_CONFIG – MTP2 Link Configuration Request ................................40

3.3.3

SS7_MSG_END_LINK – MTP2 End Link Request ..........................................43

3.3.4

SS7_MSG_TRACE_MASK – MTP2 Trace Mask Set Request.............................44

3.3.5

SS7_MSG_R_STATE – MTP2 Read Link State Request ..................................47

3.3.6

SS7_MSG_R_STATS – MTP2 Read Link Statistics Request .............................48

3.3.7

GEN_MSG_MOD_IDENT – Read Module Version Request ..............................49

3.4

Management Indications Issued by MTP2 ..............................................................50

3.4.1

MGT_MSG_EVENT_IND – Error Indication ..................................................51

3.4.2

MGT_MSG_TRACE_EV – Trace Event Indication ...........................................52

3.4.3

MGT_MSG_SS7_STATE – MTP2 Link State Indication ...................................53

3.4.4

MGT_MSG_SS7_EVENT – MTP2 Q791 Event Indication.................................54

3.5

Message Summary Table ....................................................................................55

Internal Interfaces ..................................................................................................57

Typical Configuration Values ....................................................................................60

Glossary...................................................................................................................62

3

Contents

Figures

1 MTP2 Context Diagram............................................................................................... 9

2 MTP2 Output Event Mask (Per Link) ............................................................................45

3 MTP2 Input Event Mask (Per Link) ..............................................................................45

4 MTP2 Management Event Mask (Per link) .....................................................................46

Tables

1 Message Summary Table ...........................................................................................55

2 Typical Configuration Values.......................................................................................60

3 Default Timer Value ..................................................................................................61

4

SS7 Protocols MTP2 Programmer’s Manual Issue 12

Revision History

Issue No.

12

11

10

Part No.

05-2331-003

05-2331-002

05-2331-002

8

7

6

5

Not applicable

Not applicable

Not Applicable

Date

09-Apr-10

20-Apr-07

29-Apr-04

19-Apr-04

10-Apr-01

01-Jun-98

19-Jan-96

Description of Changes

Included support for High Speed Signaling Links.

Changed to Dialogic format.

Improved PDF file browsind and navigation capabilities.

Manual now references specific SS7 boards. Applicable to MTP2 software core revision V5.xx

Minor typographical updates.

Preventive Cyclic Retransmission (PCR) method of error correction added.

Ability to generate 2 octet LSSUs added as an option.

Ability to operate in receive only mode for monitoring applications added.

Applicable to MTP2 software core revision V4.xx.

Primitive indications to MTP3 (the upper module) now contain the l3_link_id instead of the l2_llid.

CLEAR_GARBAGE action request removed and Congestion statistics added to the READ_STATISTICS message.

Multiple congestion thresholds added and SL_FAILURE message changed to L2_Q791_EVENT with additional S7G_ events.

No longer uses the Global Configuration Table for data storage area.

Document format revised.

Applicable to MTP2 software core revision V3.xx.

Applies to MTP2 software core revision V2.xx.

Not Applicable 06-Nov-93

Note: The latest released issue of this guide can be found at: http://www.dialogic.com/support/helpweb/signaling

5

Chapter 1 Introduction

Chapter 1: Introduction

Signaling System Number 7 (SS7), as defined by the ITU-T and other national standards bodies, defines a

Message Transfer Part (MTP) for the reliable transfer of messages between different nodes within a telephony network.

The Signaling Data Link part of the MTP is known as MTP Level 2, as specified in ITU-T recommendation

Q.703, ANSI T1.111.3, and as used by many other national and international standards bodies. It provides reliable point-to-point communication over typically 64kbit/s physical signaling links.

This manual relates to the MTP2 software implementation used on Dialogic to the following boards: Dialogic

®

®

DSI SS7 Boards. It is applicable

DSI SS7MD Network Interface Boards, Dialogic

®

DSI SS7HD Network

Interface Boards and Dialogic

®

DSI SPCI Network Interface Boards.

The manual is intended for use by developers who are intending to use the SS7 board level products in conjunction with message-based configuration.

This manual is not applicable to DSI SS7 board users that utilize the s7_mgt protocol configuration utility or for users of the following Dialogic

®

DSI Components: Dialogic

®

DSI SS7G3x Signaling Servers, Dialogic

®

DSI SS7G2x Signaling Servers.

1.1

Applicability

This document details the interface to the MTP2 module, including full details of all run-time configuration options. It applies to revisions of the MTP2 module commencing with a major revision number of 5 (for

example, V5.00 and later). The module version can be read back using the GEN_MSG_MOD_IDENT

message described later in this manual.

1.2

Related Information

Refer to the following documents for related information:

Dialogic

®

Distributed Signaling Interface Components -Software Environment Programmer’s Manual –

U10SSS

Dialogic

®

DSI SS7HD Network Interface Boards Programmer’s Manual – 05-2063-xxx

Dialogic

®

DSI SPCI Network Interface Boards Programmer's – U03HSP

ITU-T Recommendation Q.703

ITU-T Recommendation Q.791

ANSI T1.111.3

For more information on the SS7 products provided by Dialogic, visit http://www.dialogic.com/support/helpweb/signaling/.

6

SS7 Protocols MTP2 Programmer’s Manual Issue 12

Chapter 2: Functional Overview

2.1

MTP2 Module Overview

The functions within MTP2 can be divided into two categories:

The high level functions include Link State Control, Initial Alignment Control, Transmission Control and

Reception Control.

The low level functions include signal unit delimitation and alignment, error detection, and signal unit error monitoring.

High Level Functions

The MTP2 module is a full implementation of the high level functions, including:

Link alignment (normal and emergency)

Generation of level 2 header information

Buffering transmission and retransmission of Message Signal Units (MSU)

Validation and acknowledgement of received signal units

Generation and transmission of Link Status Signal Units (LSSU)

Congestion control

The MTP2 module services MTP3 requests and issues indications to MTP3 and to management. The module supports the level 2 monitoring and measurement features defined in ITU-T Recommendation Q.791. The

MTP2 module is common to all Dialogic

®

DSI SS7 boards to which this manual applies.

Low Level Functions

The low level functions are provided by a combination of dedicated hardware and the associated device drivers that are completely embedded within the DSI SS7 board and that vary slightly between the different board types. The features implemented within the driver and dedicated hardware include:

Signal unit delimitation and alignment

CRC generation and checking

Octet counting

Link Status Signal Unit (LSSU) repetition

Fill In Signal Unit (FISU) generation

Length indicator checking

Signal unit error rate monitoring.

2.2

Feature Overview

Features of the MTP2 implementation include:

Full implementation of ITU-T Recommendation Q.703 (1988 to 1996).

Support for ANSI T1.111.3 operation.

Support for Japan NTT/TTC operation.

Support for multiple signaling links, each operating independently.

Support for Signaling Information Field (SIF) lengths up to 272 octets.

Support for both Basic and PCR methods of error correction.

Support for single and multiple congestion levels.

Message oriented interface.

Flexible per-link run-time configuration capabilities.

Comprehensive trace options for selectively reporting to system management each primitive issued to or by the MTP2 module on a per link basis.

Run-time per-link timer value configuration

7

Chapter 2 Functional Overview

Automatic link performance statistics accumulation.

Management monitoring and measurements in accordance with Q.791.

2.3

General Description

The interface to the MTP2 module is entirely message based using the structured messages documented in the Software Environment Programmer's Manual. The module is capable of working in conjunction with an

MTP3 module running either on the same DSI SS7 board or running on the host processor. Furthermore, using the interface specified in this manual, MTP2 can be used in conjunction with third party MTP3 implementations if required.

Figure 1

provides an overview of the MTP2 module showing the various interfaces.

The MTP2 module supports multiple physical channels, each supporting one SS7 Signaling Link. Each link is maintained independently of the others. Links are identified by a level 2 logical link identifier (l2_llid). The l2_llid values run from 0 to one less than the number of links supported and are used to identify the link in all messages sent to the MTP2 module. At configuration time, a level 3 link identifier is associated with each link and this is used in indications issued to the MTP3 module.

8

SS7 Protocols MTP2 Programmer’s Manual Issue 12

Figure 1. MTP2 Context Diagram

M T P 3

I n t e r f a c e

A P I _ M S G _ T X _ R E Q

S S 7 _ M S G _ S T A R T

S S 7 _ M S G _ S T O P

S S 7 _ M S G _ E M G C Y

S S 7 _ M S G _ E M G C Y _ C L R D

S S 7 _ M S G _ R T V _ B S N T

S S 7 _ M S G _ R T V L _ R E Q

S S 7 _ M S G _ L O C _ P R _ O U T

S S 7 _ M S G _ L O C _ P R _ O K

S S 7 _ M S G _ L 3 _ F A I L

S S 7 _ M S G _ F L U S H

S S 7 _ M S G _ C O N T I N U E

S S 7 _ M S G _ R E S E T

S S 7 _ M S G _ C O N F I G

S S 7 _ M S G _ E N D _ L I N K

S S 7 _ M S G _ T R A C E _ M A S K

S S 7 _ M S G _ R _ S T A T E

S S 7 _ M S G _ R _ S T A T S

G E N _ M S G _ M O D _ I D E N T

M a n a g e m e n t

I n t e r f a c e

M G T _ M S G _ E V E N T _ I N D

M G T _ M S G _ T R A C E _ E V

M G T _ M S G _ S S 7 _ S T A T E

M G T _ M S G _ S S 7 _ E V E N T

S S 7 _ M S G _ T X _ R E Q

R T P

S S 7 _ M S G _ R E P _ N E X T _ S U

S S 7 _ M S G _ S U E R M _ S T A R T

S S 7 _ M S G _ S U E R M _ S T O P

S S 7 _ M S G _ S U E R M _ C H E C K

S S 7 _ M S G _ A E R M _ S T A R T

S S 7 _ M S G _ A E R M _ S T O P

M T P 2

M o d u l e

A P I _ M S G _ R X _ I N D

S S 7 _ M S G _ I N _ S V C

S S 7 _ M S G _ O U T _ S V C

S S 7 _ M S G _ R E M _ P R _ O U T

S S 7 _ M S G _ R E M _ P R _ O K

S S 7 _ M S G _ R X D _ B S N T

A P I _ M S G _ R T V D _ M S G

S S 7 _ M S G _ R T V L _ C O M P L

M T P _ M S G _ R T V L _ N O T _ P O S

M T P _ M S G _ L I N K _ C O N G

M T P _ M S G _ L I N K _ U N C O N G

M T P _ M S G _ F L U S H _ A C K

T I M _ M S G _ K E E P _ T I M E

O n - B o a r d

S e r v i c e s

S S 7 _ M S G _ T M _ E X P

S S 7 _ M S G _ F A S T _ T I C K

S S 7 _ M S G _ R X _ I N D

S S 7 _ M S G _ R X _ E R R

S S 7 _ B U S Y _ I N D

S S 7 _ M S G _ D V R _ R D Y

S S 7 _ M S G _ S U E R M _ F A I L

S S 7 _ M S G _ A E R M _ F A I L

O n - B o a r d

H D L C D e v i c e

D r i v e r

P h y s i c a l

I n t e r f a c e

9

Chapter 2 Functional Overview

2.4

Physical Layer Configuration

Proper operation of the MTP2 module requires correct configuration of the underlying physical layer. This varies depending on the DSI SS7 board type in use. For details, refer to the Programmer's Manual for the specific DSI SS7 board type.

All DSI SS7 boards use the Board Configuration request (MGT_MSG_CONFIG0) to set up basic physical configuration such as clocking and the CT bus. Dialogic

®

DSI SPCI Network Interface Boards also use this message to configure per-link (up to a maximum of four links) Layer 1 parameters such as, data rate, physical source, timeslot, clocking. Dialogic

®

DSI SS7HD Network Interface Boards use a separate per-link message (MGT_MSG_L1_CONFIG) for configuration of all Layer 1 parameters. In all cases, Layer 1 configuration should take place prior to configuring a link at MTP2.

10

SS7 Protocols MTP2 Programmer’s Manual Issue 12

Chapter 3: Message Reference

This section describes the individual messages and associated parameters that may be sent to or received from an Dialogic

®

DSI SS7 board when interfacing to the MTP2 module running on the board. The interface is a message-based interface using messages of type MSG as defined in the Software Environment

Programmer's Manual.

These messages are used for the primitive protocol interface with the MTP3 module and for the non-primitive interface to management for the purposes of configuring and managing MTP2 signaling links.

The messages are grouped into the following categories:

Protocol Requests from MTP3 to MTP2

Protocol Indications from MTP2 to MTP3

Management Requests Sent to MTP2

Management Indications Issued by MTP2

3.1

Protocol Requests from MTP3 to MTP2

Primitive protocol requests are sent from MTP3 to MTP2 in accordance with published MTP2 recommendations. The primitive names used for the MTP2 module are closely aligned with the terminology used in ITU-T Recommendation Q.703.

This section of the manual is applicable only to users intending to write or interface to their own MTP3 implementation. When using MTP3 from the Dialogic

®

DSI SS7 Product Range, this interface is already implemented within the MTP3 module.

The list of protocol requests sent from MTP3 to MTP2 includes:

API_MSG_TX_REQ – Message for Transmission Request

SS7_MSG_START – MTP2 Start Request

SS7_MSG_STOP – MTP2 STOP Request

SS7_MSG_EMGCY – MTP2 Set Emergency Request

SS7_MSG_EMGCY_CLRD – MTP2 Cancel Emergency Request

SS7_MSG_RTV_BSNT – MTP2 BSNT Retrieval Request

SS7_MSG_RTVL_REQ

MTP2 Retrieval Request

SS7_MSG_LOC_PR_OUT – MTP2 LPO Request

SS7_MSG_LOC_PR_OK – MTP2 LPO Recovered Request

SS7_MSG_L3_FAIL – MTP2 Level 3 Failure Request

SS7_MSG_FLUSH – MTP2 Flush Request

SS7_MSG_CONTINUE – MTP2 Continue Request

When sending messages to MTP2, the user should ensure that the message is sent to the correct board_id, the correct module_id and the correct Layer 2 Logical Link ID (l2_llid).

Prior to sending any message to the board, the application should call the GCT_set_instance( ) library function to select the board to which the message is to be sent.

The hdr->dst field of the message should be initialized to the correct MTP2 module_id for the board in use.

DSI SS7HD boards have multiple signaling processors, each running its own MTP2 instance that uses a different module_id. Other boards have only one MTP2 instance and therefore use a single MTP2 module_id.

The hdr->id field of the message should be set to the correct l2_llid, which is in the range of 0 to one less than the number of signaling links supported by each MTP2 instance.

11

Chapter 3 Message Reference

The hdr->rsp_req field may optionally be used to request a confirmation. If requested, the MTP2 module confirms acceptance of the primitive by sending the message back to its originator with bit 14 cleared in the type field of the message. This mechanism is described in detail in the Software Environment Programmer’s

Manual.

Note: Normal MTP3 operation does not require a response from MTP2 for these primitives. However, the mechanism is useful for debugging an application.

12

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.1.1

API_MSG_TX_REQ – Message for Transmission Request

Synopsis

Message issued to board by MTP3 containing SS7 Message Signal Unit (MSU) for transmission to the network on specified signaling link.

Message Format type id src dst rsp_req hclass status err_info len

0

Field Name

OFFSET len

SIZE

Message Header

Meaning

API_MSG_TX_REQ (0xcf00) l2_llid

Originating module_id

MTP2 module ID

0

0

0

0

Number of octets in Message Signal Unit (MSU)

Parameter Area

NAME

MSU data in binary format commencing with the Service Information

Octet (SIO).

13

Chapter 3 Message Reference

3.1.2

SS7_MSG_START – MTP2 Start Request

Synopsis

Primitive issued by MTP3 to request MTP2 to start the initial alignment procedure for the specified link.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_START (0xc204) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued by MTP3 to request that MTP2 commence the initial alignment procedure. If the procedure is successful, an In Service indication is issued; if alignment fails, an Out of Service indication is issued.

If an EMERGENCY condition exists, then MTP3 should send an SS7_MSG_EMGCY

message to MTP2 prior to sending the Start Request.

Changes of EMERGENCY condition can be notified by MTP3 to MTP2 both prior to sending the Start request and during Link Alignment.

Note: Receipt of a confirmation message (if requested) does not imply that the initial alignment procedure has been completed, merely that MTP2 has recognized the request to start the procedure.

14

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.1.3

SS7_MSG_STOP – MTP2 STOP Request

Synopsis

Primitive issued by MTP3 to request MTP2 to stop a signaling link.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_STOP (0xc205) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued by MTP3 to request that MTP2 stops the operation of a signaling link. The link is taken to the out of service state without further indications being issued to MTP3.

Once a link has been stopped, MTP3 may request BSNT and initiate message retrieval if required.

15

Chapter 3 Message Reference

3.1.4

SS7_MSG_EMGCY – MTP2 Set Emergency Request

Synopsis

Primitive issued by MTP3 to request that MTP2 use the emergency proving period on the next attempt at link alignment.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_EMGCY (0xc207) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued by MTP3 prior to issuing the Start request or during initial alignment to cause the next attempt at link alignment to use the emergency proving period instead of the normal proving period.

16

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.1.5

SS7_MSG_EMGCY_CLRD – MTP2 Cancel Emergency Request

Synopsis

Primitive issued by MTP3 to cancel a previous Emergency request.

Message Format type id src dst rsp_req hclass status len

Field Name

Message Header

Meaning

SS7_MSG_EMGCY_CLRD (0xc208) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

Description

This primitive is issued by MTP3 prior to cancelling any previous Emergency requests and causes the next attempt at link alignment to use the normal proving period.

17

Chapter 3 Message Reference

3.1.6

SS7_MSG_RTV_BSNT – MTP2 BSNT Retrieval Request

Synopsis

Primitive issued by MTP3 to MTP2 requesting the Backward Sequence Number Transmitted (BSNT).

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_RTV_BSNT (0xc209) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued by MTP3 to request the sequence number of the last signal unit to be acknowledged,

that is, the BSNT. The response is issued by MTP2 as an SS7_MSG_RXD_BSNT indication.

18

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.1.7

SS7_MSG_RTVL_REQ – MTP2 Retrieval Request

Synopsis

Primitive issued by MTP3 to MTP2 requesting retrieval of unacknowledged messages.

Message Format

0

1

2 type id src dst rsp_req hclass status err_info len

Field Name

OFFSET

1

1

4

SIZE

Message Header

Meaning

SS7_MSG_RTVL_REQ (0xc20a) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

1 or 6

Parameter Area

NAME

FSNC

Reserved (set to zero)

Extended FSNC

Description

This primitive is issued by MTP3 to request retrieval of all unacknowledged messages from the retransmission buffer and the transmission buffer, commencing with the message containing a sequence number immediately following the Forward Sequence Number Confirmed (FSNC) provided in the parameter area of the message. These messages can then be retransmitted by MTP3 over an alternative signaling link.

MTP2 responds with zero, one, or more API_MSG_RTVD_MSG indications, followed by an

SS7_MSG_RTVL_COMPL indication. Only messages with an FSN greater than the given FSNC are retrieved.

For high speed links using 12 bit sequence numbers, the extended FSNC field should be set to the required sequence number and FSNC set to 0x80.

19

Chapter 3 Message Reference

3.1.8

SS7_MSG_LOC_PR_OUT – MTP2 LPO Request

Synopsis

Primitive issued by MTP3 (or management) to notify MTP2 of a local processor outage condition.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_LOC_PR_OUT (0xc20b) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued either by MTP3 or by management to notify MTP2 of a local processor outage condition and to request that MTP2 take the appropriate action to deal with such a condition.

20

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.1.9

SS7_MSG_LOC_PR_OK – MTP2 LPO Recovered Request

Synopsis

Primitive issued by MTP3 (or management) to notify MTP2 that the local processor outage condition has cleared.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_LOC_PR_OK (0xc20c) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued either by MTP3 or by management to notify MTP2 that the local processor outage condition has cleared and to request that MTP2 take the appropriate action to deal with such a condition.

21

Chapter 3 Message Reference

3.1.10

SS7_MSG_L3_FAIL – MTP2 Level 3 Failure Request

Synopsis

Primitive issued by management to notify MTP2 of a failure of the MTP3 process.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_L3_FAIL (0xc20d) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued by management to advise MTP2 of a failure condition either within MTP3 or within the communications leading to MTP3 and to request that MTP2 take the appropriate action to deal with such a condition.

Within MTP2, the action taken on receipt of this message is identical to that on receipt of

SS7_MSG_LOC_PR_OUT .

22

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.1.11

SS7_MSG_FLUSH – MTP2 Flush Request

Synopsis

Primitive issued by MTP3 to MTP2 during processor outage to flush out messages from the transmit and retransmit buffers.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_FLUSH (0xc212) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued by MTP3 during a period of remote processor outage if MTP3 timer T1 expires. It causes MTP2 to discard any messages currently stored in the transmit and retransmit buffers.

On completion of buffer flushing, MTP2 responds by sending MTP_MSG_FLUSH_ACK

to MTP3 and expects

MTP3 to issue an SS7_MSG_CONTINUE message to allow normal operation to resume.

23

Chapter 3 Message Reference

3.1.12

SS7_MSG_CONTINUE – MTP2 Continue Request

Synopsis

Primitive issued by MTP3 to MTP2 following a period of processor outage to instruct MTP2 to continue normal operation.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_CONTINUE (0xc211) l2_llid

Originating module_id

MTP2 module_id

Sending layer's bit set if response required.

0

0

0

0

Description

This primitive is issued by MTP3 following a period of processor outage to instruct MTP2 to continue normal operation. It may be sent either during the period that MTP3 timer T1 is still running as a result of processor

outage clearing or on expiry of T1 after MTP3 has first issued SS7_MSG_FLUSH and received an

MTP_MSG_FLUSH_ACK message in response from MTP2.

24

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.2

Protocol Indications from MTP2 to MTP3

Primitive protocol indications are sent from MTP2 to MTP3 in accordance with published MTP2 recommendations. The primitive names used for the MTP2 module are closely aligned with the terminology used in ITU-T Recommendation Q.703.

This section of the manual is applicable only to users intending to write or interface to their own MTP3 implementation. When using the Dialogic

®

DSI MTP3 Layer, this interface is already implemented within the

MTP3 module.

The list of protocol requests sent from MTP2 to MTP3 includes:

API_MSG_RX_IND - Received Message Indication

SS7_MSG_IN_SVC - MTP2 In Service Indication

SS7_MSG_OUT_SVC - MTP2 Out of Service Indication

SS7_MSG_REM_PR_OUT

-

MTP2 RPO Indication

SS7_MSG_REM_PR_OK

-

MTP2 RPO Cleared Indication

SS7_MSG_RXD_BSNT - MTP2 BSNT Indication

API_MSG_RTVD_MSG

-

MTP2 Retrieved Message Indication

SS7_MSG_RTVL_COMPL - MTP2 Retrieval Complete Indication

SS7_MSG_RTVL_NOT_POS

-

MTP2 Retrieval Failure Indication

MTP_MSG_LINK_CONG

-

MTP2 Link Congested Indication

MTP_MSG_LINK_UNCONG - MTP2 Congestion Cleared Indication

MTP_MSG_FLUSH_ACK

-

MTP2 Flush Acknowledgement Indication

All primitives generated by the MTP2 module are sent to the upper module as defined at configuration time for each link; this should be set to the correct module_id for the MTP3 module.

The hdr->id field is always set to the l3_link_id, as configured for the link at configuration time. Note that this need not be the same as the l2_llid. The use of the l3_link_id means that it is not necessary for the receiving module (for example, MTP3) to examine the sending module_id or the board_id from which the message was received.

The MTP3 (or upper) module is responsible for releasing the message using the relm( ) library function.

25

Chapter 3 Message Reference

3.2.1

API_MSG_RX_IND – Received Message Indication

Synopsis

Message generated by MTP2 containing received Message Signal Unit (MSU) destined to MTP3.

Message Format

Message Header

Field Name Meaning id l3_link_id src dst rsp_req

MTP2 module_id upper module_id (for example, MTP3)

0 hclass status

0

0 err_info len

0

Number of octets in MSU

Parameter Area

0

Offset len

Size Name

MSU data in binary format commencing with the Service Information

Octet (SIO).

26

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.2.2

SS7_MSG_IN_SVC – MTP2 In Service Indication

Synopsis

Primitive issued by MTP2 to MTP3 to indicate that the signaling link is in service.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

0

0

0

0

SS7_MSG_IN_SVC (0x8303) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Description

This primitive is issued by MTP2 to the upper module to indicate the successful completion of the link alignment procedure.

Note: The id field of this message (and all indications to the upper module) contains the l3_link_id, which is a configuration parameter for the link and need not be the same as the l2_llid, which is used in messages sent to MTP2.

27

Chapter 3 Message Reference

3.2.3

SS7_MSG_OUT_SVC – MTP2 Out of Service Indication

Synopsis

Primitive issued by MTP2 to MTP3 to indicate that the signaling link has failed.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

0

0

0

0

SS7_MSG_OUT_SVC (0x8304) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Description

This primitive is issued by MTP2 to the upper module to indicate that the signaling link is out of service, either due to an excessive error rate or a failure to complete the alignment operation.

28

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.2.4

SS7_MSG_REM_PR_OUT – MTP2 RPO Indication

Synopsis

Primitive issued by MTP2 to MTP3 to indicate a Remote Processor Outage (RPO) condition.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

0

0

0

0

SS7_MSG_REM_PR_OUT (0x8305) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Description

This primitive is issued by MTP2 to the upper module to indicate that a Remote Processor Outage condition has been detected (that is, SIPO has been received on the signaling link).

29

Chapter 3 Message Reference

3.2.5

SS7_MSG_REM_PR_OK – MTP2 RPO Cleared Indication

Synopsis

Primitive issued by MTP2 to MTP3 to indicate the clearing of a Remote Processor Outage (RPO) condition.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

0

0

0

0

SS7_MSG_REM_PR_OK (0x8306) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Description

This primitive is issued by MTP2 to the upper module to indicate that a signaling link that was previously in the Remote Processor Outage condition has now recovered.

30

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.2.6

SS7_MSG_RXD_BSNT – MTP2 BSNT Indication

Synopsis

Primitive issued by MTP2 to MTP3 containing the Backware Sequence Number Transmitted (BSNT).

Message Format

0

1

2 type id src dst rsp_req hclass status err_info len

Offset

Field Name

1

1

4

Size

Message Header

Meaning

SS7_MSG_RXD_BSNT (0x8307) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

0

0

0

1 or 6

Parameter Area

Name

BSNT

Reserved (set to zero)

Extended BSNT

Description

This primitive is issued by MTP2 in response to a BSNT Retrieval request. It contains the BSNT in the parameter area of the message.

For high speed links using 12 bit sequence numbers, the BSNT field is set to 0x80 and the backwards sequence number is returned in the extended BSNT field.

31

Chapter 3 Message Reference

3.2.7

API_MSG_RTVD_MSG – MTP2 Retrieved Message Indication

Synopsis

Message sent from MTP2 to MTP3 containing the next MSU retrieved from the transmission/retransmission buffer.

Message Format type id src dst rsp_req hclass status err_info len

0

Offset

Field Name

1

Size

Message Header

Meaning

API_MSG_RTVD_MSG (0x8f08) l3_link_id

MTP2 module_id

Destination module (MTP2 upper_id)

0

0

0

0

Number of octets in MSU

Parameter Area

Name

MSU data in binary format commencing with the Service Information

Octet (SIO).

32

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.2.8

SS7_MSG_RTVL_COMPL – MTP2 Retrieval Complete Indication

Synopsis

Primitive issued by MTP2 to MTP3 to indicate the completion of the message retrieval procedure.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

0

0

0

0

SS7_MSG_RTVL_COMPL (0x8309) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Description

This primitive is issued by MTP2 to the upper module to indicate that any messages for retrieval have been conveyed using Retrieved Message Indications so the retrieval procedure is complete.

33

Chapter 3 Message Reference

3.2.9

SS7_MSG_RTVL_NOT_POS – MTP2 Retrieval Failure Indication

Synopsis

Primitive issued by MTP2 to MTP3 to indicate that it is not possible to carry out message retrieval.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

0

0

0

0

MTP_MSG_RTVL_NOT_POS (0x8315) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Description

This primitive is issued by MTP2 to the upper module to indicate that for some reason it is not possible to carry out or complete the message retrieval procedure. Any retrieved messages issued to MTP3 should therefore be discarded. The message is issued instead of a Retrieval Complete Indication.

34

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.2.10

MTP_MSG_LINK_CONG – MTP2 Link Congested Indication

Synopsis

Primitive issued by MTP2 to MTP3 to notify of signaling link congestion.

Message Format type id src dst rsp_req hclass status err_info len

0

Offset

Field Name

1

Size

Message Header

Meaning

0

0

0

1

MTP_MSG_LINK_CONG (0x8312) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Parameter Area

Name

Congestion status

Description

This primitive is issued by MTP2 on detection of link congestion or a change in the congestion status of a link.

Congestion is detected when the total number of messages stored in the transmit and retransmit buffers exceeds a configurable congestion onset threshold. The module can be configured with either a single congestion threshold or multiple congestion onset thresholds.

The level of congestion is indicated in the parameter field of the message. For single congestion levels, this is either 0 (no congestion) or 1 (congested). For multiple congestion levels, this is 0 (no congestion) or 1, 2 or

3 (indicating increasing levels of congestion).

35

Chapter 3 Message Reference

3.2.11

MTP_MSG_LINK_UNCONG – MTP2 Congestion Cleared Indication

Synopsis

Primitive issued by MTP2 to MTP3 to notify the clearing of link congestion.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

0

0

0

0

MTP_MSG_LINK_UNCONG (0x8313) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Description

This primitive is issued by MTP2 when a link which has been congested returns to the uncongested state.

36

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.2.12

MTP_MSG_FLUSH_ACK – MTP2 Flush Acknowledgement Indication

Synopsis

Primitive issued by MTP2 to MTP3 to acknowledge completion of buffer flushing.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

0

0

0

0

MTP_MSG_FLUSH_ACK (0x8316) l3_link_id

MTP2 module_id upper module_id (for example, MTP3)

0

Description

This primitive is issued by MTP2 in response to an SS7_MSG_FLUSH message after all messages have been

flushed by MTP2 from the transmission and retransmission buffers.

37

Chapter 3 Message Reference

3.3

Management Requests Sent to MTP2

In addition to the primitives defined at the MTP2/MTP3 interface, the MTP2 module supports a non-primitive interface for configuration and maintenance.

The non-primitive interface is used to support requests by the user for initialization, configuration and diagnostic purposes and to allow MTP2 to report protocol-based and software error events to the local system management module.

This section describes the formats of all the messages used in the non-primitive interface. The full list of management requests sent to MTP2 includes:

SS7_MSG_RESET - MTP2 Module Reset Request

SS7_MSG_CONFIG - MTP2 Link Configuration Request

SS7_MSG_END_LINK - MTP2 End Link Request

SS7_MSG_TRACE_MASK

-

MTP2 Trace Mask Set Request

SS7_MSG_R_STATE - MTP2 Read Link State Request

SS7_MSG_R_STATS

-

MTP2 Read Link Statistics Request

GEN_MSG_MOD_IDENT - Read Module Version Request

When sending messages to MTP2, the user should ensure that the message is sent to the correct board_id, the correct module_id and the correct Layer 2 Logical Link ID (l2_llid).

Prior to sending any message to the board, the application should call the GCT_set_instance( ) library function to select the board to which the message is to be sent.

The hdr->dst field of the message should be initialized to the correct MTP2 module_id for the board in use.

Some boards (for example, DSI SS7HD Boards) have multiple signaling processors, each running its own

MTP2 instance and using a different module_id.

The hdr->id field of the message should be set to the correct l2_llid (for all link specific messages or zero otherwise); this runs from zero to one less than the number of signaling links supported by each MTP2 instance.

The hdr->rsp_req field may optionally be used to request a confirmation. If requested, the MTP2 module confirms acceptance of the primitive by sending the message back to its originator with bit 14 cleared in the type field of the message. This mechanism is described in detail in the Software Environment Programmer's

Manual.

When the MTP2 module is requested to return a confirmation message, the returned message contains a status value from the following table:

Mnemonic

SUCCESS

S7E_BAD_LLID

S7E_BAD_PRIM

Value

0

0x3a

0x39

Description

Success

Invalid l2_llid

Unrecognized or unexpected primitive

38

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.3.1

SS7_MSG_RESET – MTP2 Module Reset Request

Synopsis

Message issued by management to MTP2 to initialize the module for operation.

Message Format

6

8

0

4 type id src dst rsp_req hclass status err_info len

Offset

Field Name

2

2

4

2

Size

Message Header

Meaning

SS7_MSG_RESET (0x7200)

0

Originating module_id

MTP2 module_id

0

0

Sending layer’s bit set if response required

0

10

Parameter Area

Name

Reserved, must be set to 0 num_links - Numberin of links to support tx_pool_len - Transmit pool size timer_res - Timer resolution

Description

This message is used to initialize the MTP2 module. All messages received by the module before the

SS7_MSG_RESET message are discarded. The module can only be reset once.

Note: This message is generated on-board the Dialogic

®

DSI SS7 board at startup and should not be generated by the user.

Parameters

The SS7_MSG_RESET message includes the following parameters:

• num_links

Maximum number of SS7 signaling links to support. This may range from 1 to one less than the number of links supported, depending on how many signaling links the user wishes to use. It is not necessary to always use this number of links.

• tx_pool_len

Number of frames in the MTP2 transmit pool. It is used for generation of Link Status Signal Units (LSSUs) and Fill In Signal Units (FISUs).

• timer_res

Reserved for future use. This field must always be set to 1

39

Chapter 3 Message Reference

3.3.2

SS7_MSG_CONFIG – MTP2 Link Configuration Request

Synopsis

Message issued by management to MTP2 to configure an individual signaling link for operation.

Message Format

52

54

56

58

44

46

48

50

36

38

40

42

28

30

32

34

20

22

24

26

12

14

16

18

5

6

8

10

3

4

0

2 type id src dst rsp_req hclass status err_info len

Offset

Field Name

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

1

2

1

1

2

1

Size

Message Header

Meaning

SS7_MSG_CONFIG (0x7203) l2_llid

Originating module_id

MTP2 module_id

0

0

Sending layer’s bit set if response required

0

38, 42 or 60 (see below)

Parameter Area

Name options - Run-time options upper_id - (for example, MTP3 module_id) lower_id - (for example, Driver module_id) mgmt_id - Module_id of management module monitor_id – Reserved, set to 0.

max_SIF_len - (for example, 62 or 272) cong_onset - Congestion onset threshold cong_abate - Congestion abatement threshold pcr_n1 - PCR N1 threshold pcr_n2 - PCR N2 threshold rtv_attempts - Maximum number of retrieval attempts t1 - Timer T1 value t2 - Timer T2 value t3 - Timer T3 value t4n - Timer T4 normal value t4e - Timer T4 emergency value t5 - Timer T5 value t6 - Timer T6 value t7 - Timer T7 value t_suerm - Period between SUERM checks t_rtv - Period between retrieval attempts/ cong_discard - Congestion discard threshold l3_link_id - MTP3 link id co1 - Congestion onset threshold 1 co2 - Congestion onset threshold 2 co3 - Congestion onset threshold 3 ca1 - Congestion abatement threshold 1 ca2 - Congestion abatement threshold 2 ca3 - Congestion abatement threshold 3 cd1 - Congestion discard threshold 1 cd2 - Congestion discard threshold 2 cd3 - Congestion discard threshold 3

40

SS7 Protocols MTP2 Programmer’s Manual Issue 12

Description

This message is used to configure the operational parameters for an individual signaling link and cause the power up action defined in Q.703 to be executed. One such message must be issued to MTP2 (after the

SS7_MSG_RESET

message has been issued) for each link to be used. Subsequent SS7_MSG_CONFIG messages may be issued to the MTP2 module to modify timer configuration parameters; however, these messages do not affect SS7 operation (that is, the power up sequence is not be re-executed, but the parameters are modified).

For backwards compatibility, the MTP2 module accepts messages with three different parameter area lengths: 38, 42 or 60 bytes. If the length is less than 42 the cong_discard parameter is set to 0 so that congestion discard does not take place, and the l3_link_id parameter is set to the same value as the l2_llid. If the length is less than 60, then the use of single congestion thresholds is assumed.

Note: To use multiple congestion thresholds it is necessary to set the S7C_MCONG bit (bit 3) in the options field in addition to supplying a full length parameter area.

• options

This field is used to convey run-time options to the module as shown in the following table:

0

3

5

6

7

8

9

11

12

Bit Meaning

Set to 1 to enable the Preventive Cyclic Retransmission of error correction or set to 0 to enable the Basic Method of error correction.

Set to 1 to enable the Multiple Congestion States and Multiple Message Priority option.

This option should always be enabled when running in ANSI mode.

Set to 1 to cause generated LSSUs to have a 2 octet status field; otherwise, LSSUs are generated with a single octet status field.

Set to 1 if it is required that MTP2 wait for a Continue Request from MTP3 prior to resuming normal operation prior to a period of processor outage.

Set to 1 to invoke special MTP2 operation for use in Japanese networks.

Only significant when bit 9 is also set to 1; otherwise, it should be set to 0. When bit 9 is also set, setting bit 8 to 1 allows FISU to be reported to the user as part of monitor operation otherwise FISU are not sent to the user. Note: Identical FISU are filtered and not reported to the user.

Set to 1 to cause the link to operate in receive only mode for use in monitoring applications.

Set to 1 to enable high speed link processing in accordance with Q.703 Annex A.

Only significant when bit 11 is also set to 1; otherwise, it should be set to 0.

Set to 1 to enable 12 bit sequence numbers or set to 0 to enable 7 bit.

Reserved for future use and must be set to 0. Others

• upper_id

The module ID of the upper layer module. This is the module to which all MTP2/MTP3 indications are to be issued and is typically the module ID of the MTP3 module.

• lower_id

The module ID of the on-board driver module that interfaces with the physical interface. This must always be set to 0.

• mgmt_id

The module ID of the management module to which all trace messages, event indications and state change messages are to be sent.

• max_SIF_len

The maximum length of signaling Information Field (SIF) to support. This should be set to either 62 or

272 in accordance with Q.703.

• cong_onset

The congestion onset threshold for use with the single congestion threshold mode of operation.

Congestion is indicated when the total number of messages in the transmit and retransmit buffers equals this value.

41

Chapter 3 Message Reference

• cong_abate

The congestion abatement threshold for use with the single congestion threshold mode of operation. Link uncongested is indicated when the total number of messages in the transmit and retransmit buffers equals this value.

• pcr_n1

The N1 threshold for use with the Preventive Cyclic Retransmission method of error correction. This is typically set to 127 although it may be set to a lower value to limit the maximum number of messages in the retransmission buffer.

• pcr_n2

The N2 threshold for use with the Preventive Cyclic Retransmission method of error correction. This should typically be set to approximately 8 times the loop delay in ms for 64 kbit/s operation or 7 times the loop delay in ms for 56 kbit/s operation. If set to 0, the MTP2 module assumes a value of 400.

• t1, t2, t3, t4n, t4e, t5, t6, t7

Values for the protocol timers as defined in Q.703. These should be set to the number of

(tick * timer_res) intervals required for the timer. The timers are checked for expiry every timer_res number of ticks. The value given for t1, t2 etc. is the number of times that the timer is checked before indicating expiry.

• t_suerm

The time interval between issuing check SUERM commands to the driver. Specified in the same manner as the protocol timers t1, t2 etc. This should always be set to 10.

• t_rtv

The time interval between retrieval attempts specified in the same manner as the protocol timers t1, t2 etc. Retrieval can only take place once the driver has released all messages queued for transmission.

This timer determines the period between successive attempts. This should always be set to 1.

• cong_discard

The congestion discard threshold for use with the single message priority mode of operation. If the number of messages in the transmit and retransmit buffers exceeds this threshold, then further MSU’s are discarded.

• l3_link_id

The value to use in the id field of all indications issued to the upper module (that is, MTP3). For single signaling processor systems, this is typically the same as the l2_llid. However, when a system contains more than one MTP2 processor this may not be so.

• co1, co2, co3, ca1, ca2, ca3, cd1, cd2, cd3

Congestion onset, abatement and discard thresholds for use when the Multiple Congestion Thresholds mode of operation is selected.

42

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.3.3

SS7_MSG_END_LINK – MTP2 End Link Request

Synopsis

Message issued by management to remove configuration of a link at MTP2.

Note: This operation is currently only supported on DSI SS7HD boards. Other board types do not permit the removal of an MTP2 link.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

SS7_MSG_END_LINK (0x7212) l2_llid

Originating module_id

MTP2 module_id

0

0

Sending layer’s bit set if response required

0

0

Description

This message is issued to MTP2 to remove configuration of an existing signaling link allowing, for example, the link to be reconfigured with different operating parameters.

To change MTP2 parameters, the following sequence should be used (note that currently this operation is supported only by DSI SS7HD boards):

1. Deactivate the link at MTP3 (causing MTP3 to issue a Stop request to MTP2).

2. Send SS7_MSG_END_LINK

to MTP2.

3. Send MGT_MSG_L1_END to the board. See the Dialogic

®

DSI SS7HD Network Interface Boards

Programmer's Manual for detailed information about this message.

4. Send MGT_MSG_L1_CONFIG to the board. See the Dialogic

®

DSI SS7HD Network Interface Boards

Programmer's Manual for detailed information about this message.

5. Send SS7_MSG_CONFIG

to MTP2.

6. Activate the link.

43

Chapter 3 Message Reference

3.3.4

SS7_MSG_TRACE_MASK – MTP2 Trace Mask Set Request

Synopsis

Message issued to MTP2 to cause per-link tracing of protocol primitives.

Message Format

0

2

4 type id src dst rsp_req hclass status err_info len

Offset

Field Name

2

2

2

Size

Message Header

Meaning

SS7_MSG_TRACE_MASK (0x5213) l2_llid

Originating module_id

MTP2 module_id

0

0

Sending layer’s bit set if response required

0

6

Parameter Area

Name op_evt_mask - Output event trace mask.

ip_evt_mask - Input event trace mask.

mgmt_evt_mask - Management event mask.

Description

The MTP2 module supports comprehensive tracing options on a per-link and per-primitive basis. The module can be configured to trace any message received or transmitted and a number of management events. This message is used to selectively enable tracing of events. It can be used at any time during operation and continues to be effective until the next Trace Mask Set Request is received for the same link.

Traced events are indicated to the management module using the

MGT_MSG_TRACE_EV

Event Indication.

Parameters

The SS7_MSG_TRACE_MASK message includes the following parameters:

• op_evt_mask

The output event trace mask. This is a 16-bit value with bits set to 1 to cause a trace message to be sent to the management module whenever a message is issued by MTP2. Care should be taken when tracing messages because the system throughput may be reduced. The fields in the trace mask cause the events indicated in

Figure 2

to be traced.

44

SS7 Protocols MTP2 Programmer’s Manual Issue 12

Figure 2. MTP2 Output Event Mask (Per Link)

Bit 15

RTVL FAIL

Bit 14

REPORT

SU

Bit 6

Bit 13

LINK

UNCONG

Bit 5

Bit 12

LINK

CONG

Bit 4

Bit 11

SUERM

CHECK

Bit 3

Bit 10

SUERM

STOP

Bit 2

Bit 9

SUERM

STOP

Bit 1

Bit 8

XMIT

Bit 7 Bit 0

RTVL

COMPL

RTVD MSG RXD BSNT RPO CLRD

Key:

• RTVL_FAIL - Retrieval not possible indication

• REPORT_SU - Report next SU request

• LINK_UNCONG - Link uncongested indication

• LINK_CONG - Link congested indication

• SUERM_CHECK - SUERM Check request

• SUERM_STOP - SUERM Stop request and Stop

AERM request

• SUERM_START - SUERM Start request and

Start AERM request

• XMIT - Transmit request

RPO OUT SVC IN SVC RXD MSG

RTVL_COMPL - Retrieval Complete indication

RTVD_MSG - Retrieved message indication

RXD_BSNT - Received BSNT indication

• RPO CLRD - RPO ceases indication and Flush

ACK indication

RPO - RPO indication

OUT_SVC - Out of service indication

IN_SVC - In service indication

RXD_MSG - Received message indication

Note: The shaded boxesrelate to internal events within the board and are of limited use to the user.

• ip_evt_mask

The input event trace mask. This is a 16-bit value with bits set to 1 to cause a trace message to be sent to the management module whenever a message is received by MTP2. Care should be taken when tracing messages as system throughput is reduced. The fields in the trace mask cause the events

indicated in Figure 3 to be traced.

Figure 3. MTP2 Input Event Mask (Per Link)

Bit 15

SUERM

FAIL

Bit 7

Bit 14

DVR RDY

Bit 13

FLUSH

Bit 12

LPO CLRD

Bit 11

LPO

Bit 10

RTVL REQ

Bit 9

RTV BSNT

Bit 8

EMGCY

CLRD

Bit 0 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1

EMGCY RX ERR STOP START BUSY IND TM EXP RX IND

MSG FOR

TX

• Key:

• SUERM_FAIL - SUERM failure indication and

AERM failure indication

• DVR_RDY - Driver ready indication

• FLUSH - Continue request and Flush request

• LPO CLRD - Local processor outage ceases indication

• LPO - Local processor outage indication and

MTP failure request

• RTVL_REQ - Retrieval request

• RTV_BSNT - Retrieve BSNT request

• EMGCY_CLRD - Emergency cleared indication

EMGCY - Emergency indication

RX_ERR - Receive error indication

STOP - Stop request

START - Start request

BUSY_IND - Busy indication

TM_EXP - Timer expiry indication

RX_IND - Receive message indication

• MSG_FOR_TX - Message for transmission request

Note: The shaded boxes relate to internal events within the board and are of limited use to the user.

• mgmt_evt_mask

The management event trace mask. This is a 16-bit value with bits set to 1 to cause an event indication message to be sent to the management module for the events shown. The fields in the trace mask cause

the events indicated in Figure 4 to be traced. By default the SL_FAIL, SL_CONG, ERROR and STATE bits

are set.

45

Chapter 3 Message Reference

Note: Take care when sending trace mask set requests. Failure to set bits 0, 1 2 and 3 prevents the generation of

MGT_MSG_SS7_STATE state change indications and

MGT_MSG_SS7_EVENT

Q.791 event indications.

Figure 4. MTP2 Management Event Mask (Per link)

Bit 15

0

Bit 14

0

Bit 13

0

Bit 12

0

Bit 7 Bit 6 Bit 5 Bit 4

0 0 SL PROV SL TEXP

Key:

• SL_PROV - Report AERM proving failures

• SL_TEXP - Report T1/T2/T3 expiry events

• SL_CONG - Report Q.791 congestion events

• SL_FAIL - Report Q.791 reasons for link failure

• ERROR - Report errors

• STATE - Trace changes of link state

Bit 11

0

Bit 3

SL CONG

Bit 10

0

Bit 2

SL FAIL

Bit 9

0

Bit 1

ERROR

Bit 8

0

Bit 0

STATE

46

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.3.5

SS7_MSG_R_STATE – MTP2 Read Link State Request

Synopsis

Message issued to MTP2 to read the current internal state of the link.

Message Format

2

4

0

1 type id src dst rsp_req hclass status err_info len

Offset

Field Name

2

2

1

1

Size

Message Header

Meaning

SS7_MSG_R_STATE (0x6215) l2_llid

Originating module_id

MTP2 module_id

0

0

Sending layer’s bit set if response required

0

6

Parameter Area

Name lsc_state - Current Link State control state cong_status - Current congestion status.

num_msgs - Total number of buffered MSU’s.

num_rtx_msgs - Number of MSU’s in retransmit buffer.

Description

This message is issued to the MTP2 module to read the current internal state of the link and the number of

MSU’s currently buffered. The results are written into the parameter area of the message and the message is returned to the sender.

Parameters

• lsc_state

Value State

5

6

3

4

0

1

2

7

8

9

10

11

IDLE in service out of service

Initial Alignment

Aligned / Not ready

Aligned ready

Processor Outage

Not aligned

Proving

Aligned

Monitoring

Layer 2 congestion

47

Chapter 3 Message Reference

3.3.6

SS7_MSG_R_STATS – MTP2 Read Link Statistics Request

Synopsis

Message issued to MTP2 to read per-link Q.791 performance statistics.

Message Format type id src dst rsp_req hclass status err_info len

30

34

38

42

46

50

14

18

22

26

0

4

6

10

54

Offset

Field Name

4

4

4

4

4

4

4

4

4

4

4

4

4

2

4

Size

Message Header

Meaning

SS7_MSG_R_STATS (0x6214) l2_llid

Originating module_id

MTP2 module_id

Sending layer’s bit must be set.

0

0 = Leave statistics unchanged

1 = Reset statistics after reading

0

58 (or 54 or 38 for backwards compatibility)

Parameter Area

Name insvc_duration - Duration of link in service state.

align_failures - Number of failed alignment attempts.

SU_err_count - Number of signal units in error.

NACK_count - Count of negative acknowledgements received.

busy_duration - Duration of local busy condition.

txd_octets - Number of SIF and SIO octets transmitted.

rtx_octets - Number of octets re-transmitted.

tx_msu_count - Number of MSU’s transmitted.

rxd_octets - Number of SIF and SIO octets received.

rx_msu_count - Number of MSU’s received.

cong_count - Number of congestion events.

cong_duration - Duration of link congestion.

discard_count - Number of MSU’s discarded due to congestion.

discard_events - Number of congestion events leading to MSU discard.

period – Period during which the measurements have been collected (in multiples of 100ms).

Description

This message is issued to the MTP2 module to read the Q.791 statistics for the link. The statistics are written into the parameter area of the message and the message is returned to the sender. The internal statistics can be reset or left unchanged depending on the setting of the status field.

48

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.3.7

GEN_MSG_MOD_IDENT – Read Module Version Request

Synopsis

Message issued to any module to read the module type and core revision number.

Message Format

0

2

3

4 type id src dst rsp_req hclass status err_info len

Offset

Field Name

2

1

1

24

Size

Message Header

Meaning

GEN_MSG_MODE_IDENT (0x6111)

0

Originating module_id

Target module_id

0

0

Sending layer’s bit set must be set

0

28

Parameter Area

Name type – Reserved for future use maj_rev – Major revision number.

min_rev – Minor revision number.

text – Null terminated test string identifying the module (for example,

“SS7 MTP2”).

Description

This message can be issued to any module to determine the module type and the core revision number of the internal software.

The confirmation message contains the major and minor revision numbers and a text string identifying the module.

49

Chapter 3 Message Reference

3.4

Management Indications Issued by MTP2

Management indications are sent to the user-nominated management module to advise of events occurring within the MTP2 module such as changes of state, diagnostic traces, error conditions or protocol events.

The full list of management indications available to be sent from MTP2 includes:

MGT_MSG_EVENT_IND - Error Indication

MGT_MSG_TRACE_EV

-

Trace Event Indication

MGT_MSG_SS7_STATE - MTP2 Link State Indication

MGT_MSG_SS7_EVENT

-

MTP2 Q791 Event Indication

Management indications are sent from MTP2 to the per-link management module configured at link configuration time.

The user can select, using trace masks, which events to report and disable the remainder. The hdr->id field is always set either to the l2_llid or to zero as detailed in this section.

The receiving module is responsible for releasing the message using the relm( ) library function.

50

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.4.1

MGT_MSG_EVENT_IND – Error Indication

Synopsis

Message issued by MTP2 to advise management of errors or events occurring within the module.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

MGT_MSG_EVENT_IND (0x0008)

See table below

MTP2 module id

Management module id

0

0

ERROR CODE (see below)

Timestamp

0

Description

This message is issued by MTP2 the management module (as configured in the configuration message) to advise of errors occurring within MTP2. These indications are only issued if the ERROR bit of the management event mask is set.

The ERROR_CODE and id field are coded as shown in the following table:

0x37

0x38

0x39

0x3a

0x3b

0x3c

Value

0x31

0x33

0x34

0x35

0x36

Mnemonic

S7E_RESET_ERR

S7E_POOL_EMPTY

S7E_TX_FAIL

S7E_HDR_ERR

S7E_LEN_ERR

S7E_MSU_SEND

S7E_GARBAGE

S7E_BAD_PRIM

S7E_BAD_LLID

S7E_MEM_ERR

S7E_RTVL_ERR id

0 l2_llid l2_llid l2_llid l2_llid l2_llid l2_llid l2_llid l2_llid l2_llid

Description

MTP2 Failed to initialize.

No free buffers in MTP2 transmit pool.

Failed to send LSSU/FISU to driver.

No room to add MTP2 header, SU not transmitted.

Length Error, SU not transmitted.

Failed to send SU to lower layer, protocol should handle retransmission.

No longer used.

MTP2 unable to accept primitive.

Invalid l2_llid in HDR structure.

MTP2 memory allocation error.

MTP2 failure to perform retrieval.

51

Chapter 3 Message Reference

3.4.2

MGT_MSG_TRACE_EV – Trace Event Indication

Synopsis

Message issued by MTP2 to trace protocol event.

Message Format type id src dst rsp_req hclass status err_info len

6

8

12

16

18

2

4

0

1

Offset

Field Name

Size

2

2

1

1

4

2

2

4

0 to 280

Message Header

Meaning

MGT_MSG_TRACE_EV (0x0003)

0

MTP2 module_id

Management module_id

0

0

0

Timestamp

18 + length of traced data

Parameter Area

Name src - hdr->src from traced message.

dst - hdr->dst from traced message.

id - hdr->id from traced message.

type - hdr->type from traced message.

status - hdr->status from traced message.

time - timestamp (in system ticks).

par - pointer to hdr of message being traced.

data_length - number of bytes in data field.

data - Data taken from parameter area of traced message.

Description

The MTP2 module may be configured to report to management each primitive issued or received. This is useful for trace and debug purposes. The MTP2 event masks are used to enable and disable tracing on a per primitive basis for each link. The parameters from the traced primitive are encoded in the parameter area of the trace message.

52

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.4.3

MGT_MSG_SS7_STATE – MTP2 Link State Indication

Synopsis

Message issued by MTP2 to advise management of changes of state of the per-link Link State Control state machine.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

MGT_MSG_SS7_STATE (0x0201) l2_llid

MTP2 module id

Management module id

0

0

LINK STATE (see below)

Timestamp

0

Description

This primitive is used by MTP2 to advise management of changes of state within the Link State Control function. These indications are only given if the STATE bit of the management event mask is set.

This message is intended for diagnostic and maintenance purposes and does not form part of the protocol specified primitives.

The LINK STATE is coded as shown in the following table:

Value

3

4

1

2

5

6

Mnemonic

S7S_IN_SERVICE

S7S_OUT_SERVICE

S7S_INIT_ALIGN

S7S_ALIGN_NOT_RDY

S7S_ALIGN_READY

S7S_PROC_OUTAGE

Description

Entered IN SERVICE state

Entered OUT OF SERVICE state

Entered INITIAL ALIGNMENT state

Entered ALIGNED NOT READY state

Entered ALIGNED READY state

Entered PROCESSOR OUTAGE state

53

Chapter 3 Message Reference

3.4.4

MGT_MSG_SS7_EVENT – MTP2 Q791 Event Indication

Synopsis

Message issued by MTP2 to advise management of protocol events in accordance with Q.791.

Message Format type id src dst rsp_req hclass status err_info len

Field Name

Message Header

Meaning

MGT_MSG_SS7_EVENT (0x0202) l2_llid

MTP2 module id

Management module id

0

0

EVENT CODE (see below)

Timestamp

0

Description

This primitive is used by MTP2 to advise management of the occurence of protocol related events in accordance with Q.791. Currently these events either relate to the reason for a signaling link (that was in service) going out of service (events prefixed S7F_) or the occurrence of a congestion related event (prefixed

S7G_). These indications are only issued if the appropriate bit (either SL_FAIL or SL_CONG) in the management event mask is set.

The EVENT CODE is coded as shown in the following table:

Value

32

33

34

48

8

16

17

18

6

7

4

5

2

3

0

1

Mnemonic

S7F_STOP

S7F_FIBR_BSNR

S7F_EDA

S7F_SUERM

S7F_ECONG

S7F_SIO_RXD

S7F_SIN_RXD

S7F_SIE_RXD

S7F_SIOS_RXD

S7G_CONG

S7G_CONG_CLR

S7G_CONG_DIS

S7T_T1_EXP

S7T_T2_EXP

S7T_T3_EXP

S7P_AERM

Description

Stop request received

Abnormal FIBR/BSNR

Excessive delay of acknowledgement (T7 expiry)

Excessive error rate (SUERM)

Excessive congestion (T6 expiry)

Unexpected SIO received

Unexpected SIN received

Unexpected SIE received

SIOS received

Onset of signaling link congestion

Abatement of signaling link congestion

Congestion event caused MSU discard

Timer T1 Expiry

Timer T2 Expiry

Timer T3 Expiry

Failed proving attempt

54

SS7 Protocols MTP2 Programmer’s Manual Issue 12

3.5

Message Summary Table

Table 1 lists, by message type, all the messages defined in this manual.

Table 1. Message Summary Table

Message

Type

0x820b

0x820c

0x820d

0x8211

0x8212

0x8303

0x8304

0x8305

0x7203

0x7217

0x8204

0x8205

0x8207

0x8208

0x8209

0x820a

0x8306

0x8307

0x8309

0x8312

0x8313

0x8315

0x8316

0x8f01

0x8f08

0xc204

0x3200

0x3203

0x3217

0x5213

0x6111

0x6214

0x6215

0x7200

0x0003

0x0008

0x0201

0x0202

0x1213

0x2111

0x2214

0x2215

Mnemonic Description

MGT_MSG_TRACE_EV

Trace Event Indication

MGT_MSG_EVENT_IND Error

MGT_MSG_SS7_STATE

MGT_MSG_SS7_EVENT

MTP2 Link State Indication

MTP2 Q791 Event Indication

Confirmation of

SS7_MSG_TRACE_MASK

Confirmation of

GEN_MSG_MOD_IDENT

SS7_MSG_TRACE_MASK

GEN_MSG_MOD_IDENT

SS7_MSG_R_STATS

SS7_MSG_R_STATE

SS7_MSG_RESET

SS7_MSG_CONFIG

SS7_MSG_END_LINK

Confirmation of

SS7_MSG_R_STATS

Confirmation of

SS7_MSG_R_STATE

Confirmation of

SS7_MSG_RESET

Confirmation of

SS7_MSG_CONFIG

Confirmation of

SS7_MSG_END_LINK

MTP2 Trace Mask Set Request

Read Module Version request

MTP2 Read Link Statistics Request

MTP2 Read Link State Request

MTP2 Module Reset Request

MTP2 Link Configuration request

MTP2 End Link Request

Confirmation of

SS7_MSG_START

Confirmation of

SS7_MSG_STOP

Confirmation of

SS7_MSG_EMGCY

Confirmation of

SS7_MSG_EMGCY_CLRD

SS7_MSG_IN_SVC

SS7_MSG_OUT_SVC

SS7_MSG_REM_PR_OUT

SS7_MSG_REM_PR_OK

SS7_MSG_RXD_BSNT

SS7_MSG_RTVL_COMPL

MTP_MSG_LINK_CONG

MTP_MSG_LINK_UNCONG

SS7_MSG_RTVL_NOT_POS

MTP_MSG_FLUSH_ACK

API_MSG_RX_IND

API_MSG_RTVD_MSG

SS7_MSG_START

Confirmation of

SS7_MSG_RTV_BSNT

Confirmation of

SS7_MSG_RTVL_REQ

Confirmation of

SS7_MSG_LOC_PR_OUT

Confirmation of

SS7_MSG_LOC_PR_OK

Confirmation of

SS7_MSG_L3_FAIL

Confirmation of

SS7_MSG_CONTINUE

Confirmation of

SS7_MSG_FLUSH

MTP2 In Service Indication

MTP2 Out of Service Indication

MTP2 RPO Indication

MTP2 RPO Cleared Indication

MTP2 BSNT Indication

MTP2 Retrieval Complete Indication

MTP2 Link Congested Indication

MTP2 Congestion Cleared Indication

MTP2 Retrieval Failure Indication

MTP2 Flush Acknowledgement Indication

Received Message Indication

MTP2 Retrieved Message Indication

MTP2 Start Request

55

Chapter 3 Message Reference

Table 1. Message Summary Table (Continued)

Message

Type

0xc205

0xc207

0xc208

0xc209

0xc20a

0xc20b

0xc20c

0xc20d

0xc211

0xc212

0xcf00

Mnemonic

SS7_MSG_STOP

SS7_MSG_EMGCY

SS7_MSG_EMGCY_CLRD

SS7_MSG_RTV_BSNT

SS7_MSG_RTVL_REQ

SS7_MSG_LOC_PR_OUT

SS7_MSG_LOC_PR_OK

SS7_MSG_L3_FAIL

SS7_MSG_CONTINUE

SS7_MSG_FLUSH

API_MSG_TX_REQ

Description

MTP2 Stop Request

MTP2 Set Emergency Request

MTP2 Cancel Emergency Request

MTP2 BSNT Retrieval Request

MTP2 Retrieval Request

MTP2 LPO Request

MTP2 LPO Recovered Request

MTP2 Level 3 Failure Request

MTP2 Continue Request

MTP2 Flush Request

Message for Transmission Request

56

SS7 Protocols MTP2 Programmer’s Manual Issue 12

Chapter 4: Internal Interfaces

The MTP2 module on the DSI SS7 board interfaces to a driver that manages the interface to the physical layer containing the SS7 HDLC controllers. Detailed operation of this driver is not required to use the DSI

SS7 board, however, for completeness the messages and message types used on the internal interface between MTP2 and the driver are detailed in this section.

Primitives issued by the MTP2 module to layer 1 are given in the following table:

Message

Mnemonic

SS7_MSG_TX_REQ

RTP

SS7_MSG_SUERM_START

SS7_MSG_SUERM_STOP

SS7_MSG_SUERM_CHECK

SS7_MSG_AERM_START

SS7_MSG_AERM_STOP

SS7_MSG_REP_NEXT_SU

Message

Type

0xc000

0xc007

0xc10d

0xc10e

0xc111

0xc112

0xc110

Brief Description of Internal Use

To send a Signal Unit (SU) to the driver for transmission.

To return receive frame buffers to a per-link pool in the driver.

To activate the signal unit error rate monitor (SUERM).

To deactivate the SUERM.

To activate the alignment error rate monitor (used only on boards were the AERM is implemented in the driver).

To deactivate the AERM.

To reset FISU/LSSU filtering in the driver so that the next

SU is reported to MTP2.

Primitives received by the MTP2 module from layer 1 are given in the following table:

Message

Mnemonic

SS7_MSG_RX_IND

SS7_MSG_RX_ERR

SS7_BUSY_IND

SS7_MSG_DVR_RDY

SS7_MSG_SUERM_FAIL

SS7_MSG_AERM_FAIL

Message

Type

0x8001

0x8006

Brief Description of Internal Use

Indication of a received SU from driver to MTP2.

Indication of SU received in error (used only on boards where the AERM is implemented in MTP2 instead of the driver).

0x820e

Confirmation from driver to MTP2 that a SU has been passed to the hardware for transmission.

0x820f Indication of SUERM failure.

0x8210

Indication of AERM failure (used only on boards where

AERM is implemented in the driver).

Messages exchanged between MTP2 and timer services are given in the following table:

Message

Mnemonic

SS7_MSG_TM_EXP

SS7_MSG_FAST_TICK

TIM_MSG_KEEP_TIME

Message

Type

0xc002

0x0216

0x7006

Brief Description of Internal Use

Periodic 100 ms timer expiry indication sent to MTP3.

Periodic 25 ms timer expiry indication sent to MTP2 (not used on all boards).

Message sent by MTP2 to initialize timer services.

In addition, three internal messages are used as part of the on-board interface between MTP2 and MTP3 to convey message for transmission to MTP2, to convey received indications to MTP3 and to transfer retrieved messages from MTP2 to MTP3. These messages are not passed off-board so the user does not need to use these messages. These messages are listed here for completeness.

57

Chapter 4 Internal Interfaces

Messages exchanged between MTP2 and the upper on-board layer are given in the following table:

Message

Mnemonic

SS7_MSG_TX_REQ

SS7_MSG_RX_IND

SS7_MSG_RTVD_MSG

Message

Type

0xc000

0x8f01

0x8308

Brief Description of Internal Use

To send a Message Signal Unit (MSU) to MTP2 for transmission.

Indication of a received MSU from MTP2 to upper layer.

Message sent by MTP2 to return retrieved messages to the upper layer.

58

SS7 Protocols MTP2 Programmer’s Manual Issue 12

59

Chapter 5 Typical Configuration Values

Chapter 5: Typical Configuration Values

This section lists typical values to be used in the configuration messages for correct operation of MTP2 to quickly get the system up and running.

To ensure the appropriate values are being used for a specific installation, refer to the detailed message definitions in this manual.

Table 2. Typical Configuration Values

Typical Setting

Parameter

ca2 ca3 cd1 cd2 cd3 co1 co2 co3 ca1 options upper_id lower_id mgmt_id monitor_id max_SIF_len cong_onset cong_abate pcr_n1 pcr_n2 rtv_attempts t_suerm t_rtv cong_discard l3_link_id

ITU-T ANSI HSL 12-bit sequence numbers

2048 kbit/s 1544 kbit/s

0

0

4

10

0

272

50

40

0x0000 0x000a 0x1800 0x180a

0x22 (MTP3 module) 0x22 (MTP3 module) 0x22 (MTP3 module) 0x22 (MTP3 module)

0x00

0x8e (Management module)

0x00

0x8e (Management module)

0x00

0x8e (Management module)

0x00

0x8e (Management module)

0

272

50

40

0

0

4

10

0

272

320

160

0

0

4

10

0

272

320

160

0

0

4

10

50

70

45

65

85

40

60

80

30

1

130

Set to the MTP3 link_id

1

130

Set to the MTP3 link_id

40

60

80

30

50

70

45

65

85

1

4094

Set to the MTP3 link_id

240

400

560

120

320

500

300

480

720

1

4094

Set to the MTP3 link_id

240

400

560

120

320

500

300

480

720

60

SS7 Protocols MTP3 Programmer’s Manual Issue 12

Table 3. Default Timer Value

T4E

T5

T6

T7

T1

T2

T3

T4N

Q.703 /

T1.111.3 Timer

45 sec

30 sec

1.2 sec

8.2 sec

0.5 sec

0.1 sec

5.5 sec

1.5 sec

Default Value

ITU-T Mode

Default Value

ANSI Mode

56 kbit/s

13 sec

23 sec

11.5 sec

2.3 sec

0.6 sec

0.1 sec

5.5 sec

1.5 sec

Default Value

ANSI Mode

64 kbit/s

13 sec

23 sec

11.5 sec

2.0 sec

0.5 sec

0.1 sec

5.5 sec

1.5 sec

Default Value

HSL Mode

2048kbit/s

300 sec

30 sec

1.2 sec

30 sec

0.5 sec

0.1 sec

5.5 sec

1.5 sec

Default Value

HSL Mode

1544 kbit/s

300 sec

30 sec

1.2 sec

30 sec

0.5 sec

0.1 sec

5.5 sec

1.5 sec

61

MSU

Q.703

Q.791

RPO

SS7

SU

Chapter 6 Glossary

MTP1

MTP2

MTP3

Glossary

BSNT

CRC

FISU

HSL

LISU

MTP

Backward Sequence Number Transmitted

Cyclic Redundancy Check

Fill In Signal Unit. A signaling unit normally transmitted when no MSUs or LLSUs are being transmitted, allowing the SS7 network to receive immediate notification of signaling link failure.

High speed Signalin Link. A signalin link conforming to ITU-T recommendation Q.703

Annex A.

Link Status Signal Unit. A signaling unit that provides link status indications to the remote end of the signaling link.

Message Transfer Part. Layers 1 to 3 of the SS7 protocol stack broadly equivalent to the

Physical, Data Link and Network layers in the OSI protocol stack. See also MTP1, MTP2, and MTP3.

Message Transfer Part Level 1. An SS7 stack layer that defines the physical and electrical characteristics of the signaling links of the SS7 network. Signaling links use DS0 channels and carry raw signaling data at a rate of 48, 56 or 64 kbit/s.

Message Transfer Part Level 2. An SS7 stack layer that provides link-layer functionality.

Provides that two end points of a signaling link can reliably exchange signaling messages. It provides error checking, flow control and sequence checking.

Message Transfer Part Level 3. An SS7 stack layer that provides network-layer functionality. Provides that messages can be delivered between signaling points across the SS7 network regardless of whether the signaling points are directly connected. It provides node addressing, routing, alternate routing and congestion control.

Message Signal Unit. A data unit that carries signaling information for call control, transaction processing, network management and maintenance. Typically, the MSU is carried in the Signaling Information Field (SIF) of SS7 messages.

ITU-T Recommendation Q.703

ITU-T Recommendation Q.791

Remote Processor Outage

Signaling System Number 7

Signaling Unit

62

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents