SS7 MTP Layer 3 Developer s Reference Manual
|
|
- Leslie McLaughlin
- 6 years ago
- Views:
Transcription
1 SS7 MTP Layer 3 Developer s Reference Manual P/N Crossing Boulevard, Framingham, MA USA
2 No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of NMS Communications Corporation NMS Communications Corporation. All Rights Reserved. Alliance Generation is a registered trademark of NMS Communications Corporation or its subsidiaries. NMS Communications, Natural MicroSystems, AG, CG, CX, QX, Convergence Generation, Natural Access, CT Access, Natural Call Control, Natural Media, NaturalFax, NaturalRecognition, NaturalText, Fusion, PacketMedia, Open Telecommunications, Natural Platforms, and HMIC are trademarks or service marks of NMS Communications Corporation or its subsidiaries. Multi-Vendor Integration Protocol (MVIP) is a registered trademark of GO-MVIP, Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. Windows NT, MS-DOS, MS Word, Windows 2000, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Clarent and Clarent ThroughPacket are trademarks of Clarent Corporation. Sun, Sun Microsystems, and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and/or other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and/or other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. All other marks referenced herein are trademarks or service marks of the respective owner(s) of such marks. Every effort has been made to ensure the accuracy of this manual. However, due to the ongoing improvements and revisions to our products, NMS Communications cannot guarantee the accuracy of the printed material after the date of publication, or accept responsibility for errors or omissions. Revised manuals and update sheets may be published when deemed necessary by NMS Communications. Revision History Revision Release Date Notes 1.1 Sept. 12, 1997 GJG 1.2 July, 1998 GJG 1.3 September, 1998 GJG 1.4 March, 1999 GJG 1.5 May, 1999 GJG 1.6 April, 2000 GJG; SS7 3.5 Beta release 1.7 November, 2000 GJG; SS August, 2001 GJG; SS7 3.8 Beta 1.9 February, 2002 MVH; SS7 3.8 GA This manual printed: February 6, 2002 Refer to the NMS web site ( for product updates and for information about NMS support policies, warranty information, and service offerings.
3 Table of Contents 1 Introduction Introduction SS7 System Architecture Programming Model Introduction Signaling Point Types MTP 3 Message Handling Inbound Messages Outbound Message Routing Routing Masks Contexts and Queues Signaling Network Management Changeover/Changeback Forced/Controlled Rerouting MTP Restart Signaling Link Management Signaling Link Test Signaling Route Management MTP Layer 3 Service Users Entity and Instance IDs API Primitives Initialization and Binding Data Transfer Status Indications Extended Status Indications Congestion Control Outbound Congestion Network Overload MTP API Congestion Inbound Congestion Application Flow Control NMS Communications 3
4 Table of Contents 3 Using the MTP 3 Service API Introduction Initializing the MTP 3 Service Under Natural Access Initializing the Natural Access Environment Creating Queues and Contexts Use of ctaopenservices Handling Redundancy Events MTP 3 Service Alphabetical Function Reference Introduction MTP3DeregXStaReg MTP3Flow MTP3GetApiStats MTP3RegXStaReq MTP3RetrieveMessage MTP3SendData Management API Functional Description Introduction MTP 3 Configuration MTP 3 Status Requests MTP 3 Control Requests MTP 3 Statistics Requests Alphabetical Management Function Reference Introduction Mtp3GenStats Mtp3GenStatus Mtp3GetGenCfg Mtp3GetLinkCfg Mtp3GetLinkSetCfg Mtp3GetNSapCfg Mtp3GetRouteCfg Mtp3InitGenCfg Mtp3InitLinkCfg Mtp3InitLinkSetCfg Mtp3InitNSapCfg Mtp3InitRouteCfg NMS Communications
5 Table of Contents Mtp3LinkSetStats Mtp3LinkSetStatus Mtp3LinkStats Mtp3LinkStatus Mtp3MgmtCtrl Mtp3MgmtInit Mtp3MgmtTerm Mtp3NSapStatus Mtp3RouteStats Mtp3RouteStatus Mtp3RouteTest Mtp3SetGenCfg Mtp3SetLinkCfg Mtp3SetLinkSetCfg Mtp3SetNSapCfg Mtp3SetRouteCfg NMS Communications 5
6 Table of Contents 6 NMS Communications
7 Chapter 1 Introduction 1.1 Introduction SS7 System Architecture 8 NMS Communications 7
8 Chapter 1 Introduction 1.1 Introduction The SS7 explains how to create applications that make use of SS7 MTP Layer 3. Subsequent sections of this document describe the general characteristics and operation of the MTP 3 APIs as well as a detailed specification of the messages and function calls that comprise the APIs. 1.2 SS7 System Architecture The TX SS7/MTP implementation (Figure 1) consists of the following: On the TX board: Æ The MTP task running on the TX board. This task implements the SS7 MTP 2 (data link) layer and the MTP 3 (network) layer. Æ The TX Alarms Manager task. This task collects unsolicited alarms (status changes) generated by the SS7 tasks and forwards them to the host for application-specific alarm processing. Æ The CPK/OS operating system. On the Host Processor: Æ The OS-independent TX device driver that provides low level access to the TX board from the host PC. Æ The SS7 MTP Layer 3 configuration file, a text file that describes the general configuration of the MTP Layer 3 process, the SS7 links and link sets available to it, and the routes to other SS7 signal points. Æ An MTP 3 configuration program that reads the SS7 MTP 3 configuration file and loads the configuration to the MTP task at system startup. 8 NMS Communications
9 SS7 System Architecture Æ Function-call based APIs that provide the application with a high-level interface to the MTP layer services, both data and management. Æ Sample applications for both the data and the management APIs. These samples are provided in source and object code formats. Æ A log process for capturing alarms from the board. The MTP 3 data and management APIs are comprised of a set of function calls to pass messages between the user data and/or management application and the MTP layer 3 task on the TX board in order to transfer data, control flow, control communications in the SS7 network, and to obtain status and statistical information. A set of C-language functions are provided to simplify data and management operations and perform the byte ordering translation, where necessary, between application processor (Intel, or "little endian") byte order and network (or "big endian") byte order. NMS Communications 9
10 Chapter 1 Introduction Host Txalarm utility Log file Application MTP Layers 2 & 3 API Config. utility MTP Layers 2 & 3 Mgmt. API Host TX driver SS7 TCAP task Alarms Manager task SS7 SCCP task SS7 ISUP/TUP task SS7 MTP Layers 2 & 3 Task TX communications processor SS7 Layer 1 driver Figure 1. SS7 System Architecture 10 NMS Communications
11 Chapter 2 Programming Model 2.1 Introduction Signaling Point Types MTP 3 Message Handling Inbound Messages Outbound Message Routing Routing Masks Contexts and Queues Signaling Network Management Changeover/Changeback Forced/Controlled Rerouting MTP Restart Signaling Link Management Signaling Link Test Signaling Route Management MTP Layer 3 Service Users Entity and Instance IDs API Primitives Initialization and Binding Data Transfer Status Indications Extended Status Indications Congestion Control Outbound Congestion Inbound Congestion Application Flow Control 37 NMS Communications 11
12 Chapter 2 Programming Model 2.1 Introduction The MTP 3 API is implemented as a Natural Access service. Natural Access is a development environment for telephony and signaling applications that provides a standard application programming interface for services, such as signaling protocol stacks, that is independent of the underlying hardware. Natural Access is described in detail in the Natural Access Developer s Reference Manual. Understanding of the basic Natural Access programming concepts - services, queues, contexts, and asynchronous events - is critical to developing applications which utilize the MTP 3 API service. The SS7 MTP layer 3 has two primary functions. Æ Message routing and distribution Æ Signaling network management Message routing and distribution includes both the routing of outgoing messages to their specified destinations and the distribution of incoming messages to the appropriate user part or application. The SS7 MTP implementation uses a flexible configuration capability to support a wide variety of network routing and addressing requirements. Signaling network management s job is to reconfigure the signaling network as needed to maintain signaling capability in the case of failures or congestion. This includes redirecting traffic away from failed links and/or signaling points (SPs), restoring traffic to restored links/sps, and exchanging route status with adjacent SPs. The MTP 3 layer supports all required ANSI and ITU-T network management procedures without intervention from the user parts/applications. It does, however, notify user parts and applications of significant network events that might impact their operation, such as changes in the accessibility status of destination signaling points, the onset and abatement of congestion, and signaling point restarts. The primary objects represented by MTP layer 3 are Network Service Access Points (NSAPs), signaling links, linksets, combined linksets, and routes. Network service access points (NSAPs) define the SS7 user parts, or applications, that are users of the MTP service. Each NSAP is associated with one user part or application (as identified by the service indicator field of a message) and one protocol variant (ITU-T or ANSI). Figure 2 illustrates the concept of NSAPs. 12 NMS Communications
13 Introduction ISUP SCCP TUP Bind NSAP 0 SIO x85 MTP 3 NSAP 1 SIO x83 NSAPs NSAP 2 SIO x84 Message Routing/Discrimination MTP 3 LAYER Link 0 MTP 3 Links Link 1 Link 0 MTP 2 Links Link 1 MTP 2 LAYER Figure 2. Network Service Access Points (NSAPs) If multiple protocol variants are configured on the same MTP 3 instance (same board) then two NSAPs are required for each user part: one for ANSI, one for ITU-T. In this case, a single user part/application may associate itself with both NSAPs for that service, or separate user part/applications may be used for each protocol variant. Links define physical signaling links between the TX board and the adjacent signaling points. One link configuration must be performed for each physical signaling link. The attributes of a link include the point code of the adjacent signaling point, protocol variant employed on the link (ITU-T or ANSI), point code length, maximum packet length, various timer values, membership in a linkset, and others. Linksets are groups of from one to 16 links that directly connect two signaling points. Although a linkset usually contains all parallel signaling links between two SPs, it is possible to define parallel linksets. Each signaling link defined is assigned membership in exactly one linkset. NMS Communications 13
14 Chapter 2 Programming Model A combined linkset is a group of all linksets that can be used to reach a particular destination or group of destinations (routes). Each linkset may be associated with up to 16 combined linksets. For each combined linkset that a linkset is a member of, it may be assigned a priority relative to other linksets belonging to that combined linkset. Routes specify the destination signaling points (or subnetworks - clusters - when route masks are employed) that are accessible from the target node. Each route is assigned a direction - up or down. One up route is required for the actual point code assigned to the signaling point being configured and for each point code that is to be emulated. Up routes are used to identify incoming messages that are to be routed up to the applications/user parts. One down route is required for each remote signaling point/network/cluster that is to be accessible from the SP being configured. Down routes are used to route outgoing messages to the appropriate signaling links. Each down route is assigned to one combined linkset, which in turn identifies all linksets which may be used to reach that destination. Each linkset within the route s associated combined linkset may have an optional priority assigned, such that MTP routing will choose the highest priority available linkset when routing an outgoing packet to a particular destination. Any number of routes may be assigned to a combined linkset. 14 NMS Communications
15 Introduction Figure 3 illustrates the relationship between links, linksets, combined linksets, and routes. Combined Linkset 3 [Linkset 1, Priority 0] [Linkset 2, Priority 1] SS7 STP MTP Link 0 Link 1 Link 2 Link Linkset 1, Combined Linkset 1 Linkset 2, Combined Linkset 2 Destination SP SS7 STP Destination SP Route 1, DPC Linkset 1 Route 3, DPC Combined Linkset 3, Route 2, DPC Linkset 2 Route4, DPC Combined Linkset Figure 3. Links, Linksets, and Routes NMS Communications 15
16 Chapter 2 Programming Model 2.2 Signaling Point Types The MTP 3 layer can be configured as either a signal transfer point (STP) or as a signaling endpoint, referred to simply as an SP. The primary difference between STP operation and SP operation is in the handling of messages received from signaling links by the MTP 3 layer but addressed to other destinations. When configured as an STP, MTP 3 searches for an outbound route to the message s destination and, if found, routes the message over an outbound link. When configured as an SP, the MTP 3 layer discards such messages. When configured as an STP, the MTP 3 layer also performs the additional signaling route management procedures required of an STP. These primarily involve notifying adjacent SPs when they must no longer route messages to a particular destination through that STP due to failures or congestion (transfer prohibited/restricted), and notifying them again when normal communication with the concerned destination is restored (transfer allowed). 2.3 MTP 3 Message Handling The following subsections describe how the MTP 3 layer handles inbound messages, outbound messages, and routing masks, as well as the congestion priorities supported. 16 NMS Communications
17 Inbound Messages Inbound Messages When an inbound message is received, the MTP 3 layer searches its routing tables for a route that matches the destination point code in the message. If a matching UP route is found for the message, it is distributed to the appropriate user part/application based on the service indicator value in the incoming message and the link type (protocol variant) attribute of the link that the message was received on. This is illustrated in Figure 4. Note: Only the link type of the incoming link and the service indicator portion of the SIO octet in the incoming message are used to choose the NSAP to receive the incoming message; the sub-service field of the SIO octet (national/international indicator and optional message priority) is not used. ISUP SCCP NSAP 0 SIO x85 ANSI MTP 3 NSAP 1 SIO x85 CCITT NSAPs NSAP 2 SIO x83 ANSI Message Routing/Discrimination Data SSF SIO SI Recv d Message Routing Label MTP 3 LAYER Link 0 ANSI MTP 3 Links Link 1 CCITT Figure 4. Inbound Message Distribution If a matching DOWN route is found for the message instead, the message is either routed as an outbound message (if the MTP 3 layer is configured as an STP) or the message is discarded. If no matching route is found, the message is always discarded. NMS Communications 17
18 Chapter 2 Programming Model Outbound Message Routing For outbound messages originated by local user parts/applications (or received messages being routed outbound when in STP mode), message routing is based on the destination point code and signaling link selection (SLS) field associated with the message. When an outbound message is ready for routing, the MTP 3 layer searches its routing tables for a route that matches the destination point code specified for the message. If a matching DOWN route is found for the message, message routing depends on the value specified for the SLS field, as follows: Æ If the MTP 3 layer has recently routed a message with the same combination of DPC and SLS value, the same linkset and link are chosen for transmission, to maintain the order of delivery for messages between the same user parts/applications in the same direction with the same SLS value. This combination of DPC/SLS value is called a route instance. A route instance remains in effect until a configurable amount of time elapses, with no new messages containing the same DPC/SLS values. Æ If no current route instance is in effect, the MTP 3 layer finds all active linksets belonging to the combined linkset associated with the target route and chooses the highest priority for transmission. If multiple linksets of the same priority are active, the linkset is chosen on a round-robin basis from all those at the same (highest) priority. Within the linkset, the actual link to transmit the message on is also chosen on a priority basis (again roundrobin when multiple links of the same priority are available). Note: The user part/application is responsible for assigning SLS values for outgoing messages such that related messages that must be delivered in order get the same SLS value, but for unrelated messages the SLS value is varied to achieve the desired degree of load sharing. For example, the ISDN User Part (ISUP) typically uses the least significant 4 bits of its circuit identification code (CIC) as the SLS value so that all messages related to a particular circuit use the same link/linkset, but that messages for different circuits are reasonably load shared across all available links/linksets Routing Masks The MTP 3 layer allows for the use of routing masks to help decrease the size of the routing tables that must be configured. Routing masks are bit masks that 18 NMS Communications
19 Routing Masks specify a subset of a destination point code to be matched against the routing table when searching for a route for either an inbound or outbound message. Routing masks may be used to implement network and cluster routing in ANSI networks. For example, consider the following network diagram (Figure 5). Rather than specifying explicit routes to each of the seven remote SPs, the following routing masks and routes can be used (note that all point codes and routing masks, regardless of point code length, are stored internally as 32-bit unsigned integers). Routing Mask 0xFFFFFFFF 0xFFFF00 0xFF0000 Comment Always specify exact match as first mask. Match on network ID + cluster ID next. Match on just network ID last. Routes Comment , UP Always specify an UP route to self , DOWN, Linkset 1 Explicit route to STP for network 1, cluster , DOWN, Linkset 1 Cluster route to network 1, cluster , DOWN, Linkset 2 Explicit route to STP for network 1, cluster , DOWN, Linkset 2 Cluster route to network 1, cluster , DOWN, Linkset 3 Explicit route to STP for network , DOWN, Linkset 3 Network route to network 2. Note: Routing masks are global to all links, linksets, and user parts, and are applied to both incoming and outgoing messages. Although the previous example is specific to ANSI networks, routing masks can be applied equally to other networks (ITU-T based networks with 14- or 24-bit point codes) to reduce the size of routing tables. NMS Communications 19
20 Chapter 2 Programming Model SS7 STP SP SP SP Network 1, Cluster 1 Link 0 MTP Link 1 Link 2 SS7 STP SP SP Network 1, Cluster 2 SS7 STP SP SP Network 2 Figure 5. Network/Cluster Routing 20 NMS Communications
21 Contexts and Queues 2.4 Contexts and Queues Natural Access organizes services and their associated resources around a processing object known as a context. Each instance of an application binding to an MTP 3 service SAP comprises a unique Natural Access context. Contexts are created with ctacreatecontext. All events and messages from the MTP 3 service are delivered to the application through a Natural Access queue object. Queues are created with ctacreatequeue. Each context is associated with a single queue through which all events and messages belonging to that context are distributed. More than one context can be assigned to the same queue. Different application programming models are possible depending on how many MTP 3 service SAPs (how many subsystems) are implemented by the application and how the application is organized. An application that uses a single MTP 3 SAP uses a single-context, single-queue model as shown in Figure 6. Application Natural Access Event Queue Service Manager MTP 3 Service Context SAP 0 SSN=7 SAP 1 SSN=8 SAP 2 SSN=254 MTP 3 SAPs Figure 6. Single-Context, Single-Queue Model NMS Communications 21
22 Chapter 2 Programming Model For a single-threaded application which uses multiple MTP 3 SAPs (implements multiple MTP 3 subsystems), a multiple-context single-queue model is recommended, as shown in Figure 7. In this case the application has a single event loop with events from all SAPs delivered via the same queue. The application determines which SAP a particular event is associated with from a service user ID (suid) value returned with each event. Application Natural Access Event Queue Service Manager MTP 3 Service Service Manager MTP 3 Service Service Manager MTP 3 Service Context Context Context SAP 0 SSN=7 SAP 1 SSN=8 SAP 2 SSN=254 MTP 3 SAPs Figure 7. Multiple-Context, Single-Queue Model 22 NMS Communications
23 Contexts and Queues For multi-threaded applications using multiple MTP 3 SAPs (one per thread), a multiple-context multiple-queue model (shown in Figure 8) is recommended. In this case each thread has its own independent event loop, receiving only the events associated with its MTP 3 SAP on its Natural Access queue. Note: For this programming model, each thread/event queue must be assigned its own entity ID, which must be unique among all applications on that host accessing any of the SS7 services. Application Thread Thread Thread Event Queue Natural Access Event Queue Event Queue Service Manager Service Manager Service Manager MTP 3 Service MTP 3 Service MTP 3 Service Context Context Context SAP 0 SSN=7 SAP 1 SSN=8 SAP 2 SSN=254 MTP 3 SAPs Figure 8. Multiple-Context, Multiple-Queue Model NMS Communications 23
24 Chapter 2 Programming Model 2.5 Signaling Network Management Signaling network management provides the functions necessary to maintain signaling service during failures and congestion and restore normal signaling service after recovery from these conditions. The MTP 3 layer supports all required ANSI and ITU-T network management procedures without intervention from the user parts/applications. It does, however, notify user parts and applications of significant network events that might impact their operation, such as changes in the accessibility status of remote signaling points, the onset and abatement of congestion, and signaling point restarts Changeover/Changeback The MTP 3 layer automatically initiates changeover procedures whenever a link fails, is deactivated, is remotely blocked, or is inhibited. No user part/application action is required nor is the user part/application notified when the changeover occurs. Likewise, when a signaling link is restored, unblocked, or uninhibited, the MTP 3 layer automatically performs the changeback function, again without interaction with the user parts/applications Forced/Controlled Rerouting The MTP 3 layer also handles forced and controlled rerouting upon receipt of the transfer prohibited and transfer allowed/transfer restricted messages. On receipt of a transfer prohibited message (TFP), the MTP 3 layer attempts to redirect all traffic for the prohibited destination to an alternate route. If no alternate routes are available, the destination is declared inaccessible and each user part/application is notified with a StatPaused status indication for the concerned destination. Note that destinations may also be declared inaccessible for other reasons, such as signaling link or signaling point failures, which result in similar StatPaused status indications to the user parts. Traffic routing over an unavailable or restricted route is automatically restored upon receipt of the transfer allowed (TFA) or transfer restricted (TFR) message for that route. If the TFA/TFR causes a previously inaccessible destination to become accessible, each user part is notified with a StatResumed status indication for that destination. 24 NMS Communications
25 MTP Restart MTP Restart The MTP 3 layer may be configured with or without the MTP restart capability. The MTP restart function allows a signaling point just becoming available (such as after a failure) to bring up sufficient links to handle the expected traffic load before receiving new traffic. If configured to do so, the MTP 3 layer will perform the restart function whenever the first signaling link becomes active (such as at system startup or after a total failure affecting all links), or on command from a management primitive. At the beginning of an MTP restart, each user part/application is notified with a StatRestart status indication. User parts should not generate new traffic requests during the restart. When the restart is complete and the MTP 3 layer is ready for traffic, each user part/application receives a StatRestartEnds status indication Signaling Link Management The MTP 3 layer provides the basic link management functions and, optionally, the signaling link management procedures based on automatic allocation of signaling terminals described in the ANSI and ITU-T MTP standards. Each link set has a minnmbactlnk attribute which determines the normal number of active links in the linkset. Typically this number will include all links in the linkset, but it is possible to configure extra alternate links that are activated only in the presence of failures of other links. Whenever a linkset is activated (such as at system startup time), the MTP 3 layer will attempt to activate the minnmbactlnk highest priority links in that linkset. If a link fails, or cannot be aligned successfully, the MTP layer will periodically attempt to restore the link until successful or until the link is manually disabled via a management primitive. If the current number of active links in a linkset drops below the minnmbactlnk threshold, the MTP 3 layer will attempt to activate the highest priority inactive link that is not currently inhibited, remotely blocked, or manually disabled. If no other links in the linkset meet this criteria, the MTP 3 layer will attempt to uninhibit the highest priority inhibited link in the linkset, if any. If the current number of active links in a linkset goes above the minnmbactlnk threshold due to a link restoration, the MTP 3 layer will attempt to deactivate the lowest priority active link to return the number of active links in the linkset to its normal condition. NMS Communications 25
26 Chapter 2 Programming Model This automatic activation/deactivation of links is normally performed without interaction with the user parts/applications, unless it results in one or more destinations becoming accessible/inaccessible, in which case the user parts are notified with a StatResumed or StatPaused status indication, as described earlier. If no automatic activation/deactivation of links is desired, then minnmbactlnk threshold can be set to the actual number of links in the linkset (or greater) Signaling Link Test The MTP 3 layer requires a successful signaling link test (SLTM generated and SLTA response expected) as part of link activation before considering a signaling link active. Thereafter the signaling link test is performed periodically on each active signaling link, at a configurable period (link timer T34 - corresponds to ANSI T /ITU-T Q.707 timer T2). Signaling link testing is performed with no user part/application interaction Signaling Route Management When configured as an STP, the MTP 3 layer implements the signaling route management procedures - transfer prohibited, transfer allowed, transfer restricted, signaling route set test, and signaling route set congestion test - described in the ANSI and ITU-T MTP standards. These procedures are performed without interaction with the user parts/applications. 2.6 MTP Layer 3 Service Users The MTP Layer 3 data application interface supports one or more user applications by way of Service Access Points, or SAPs. One SAP is defined for each application that may use the MTP layer 3 service. A user application binds to a particular SAP at initialization time, specifying the SAP ID that it wishes to bind to. Each SAP is associated with a Service Information Octet (SIO) value, which in turn identifies the upper layer protocol in use on that SAP (for example ISUP, TUP, SCCP). Therefore, there may be at most one application process handling incoming messages for a particular upper layer protocol (at most one process receiving incoming ISUP messages). 26 NMS Communications
27 Entity and Instance IDs The number of SAPs (MTP Layer 3 users - MAX_USERS) and the characteristics of each SAP are specified in the MTP 3 configuration file. See Mtp3InitNSapCfg and the Signaling System 7 (SS7) Installation and Configuration Manual for details. 2.7 Entity and Instance IDs Each user application must also have a unique entity and instance number, which is used to route messages among the various processes in the system. Entity IDs are single byte values in the range 0x00 to 0x3F, assigned as desired by the application developer. Entity IDs are allocated as follows: Range 0x00-0x1F 0x20-0x3F Usage Reserved for use by system utilities, configuration utilities, and management utilities. Available for use by applications. Instance IDs identify the processor on which the entity executes. The host is always processor 0 (zero), so for all host-resident MTP 3 user applications this value should be coded to zero. All tasks on TX board number one receive an instance ID of one, all tasks on TX board number two receive an instance ID of two, and so on. NMS Communications 27
28 Chapter 2 Programming Model 2.8 API Primitives The MTP Layer 3 data API consists of the following primitives: Primitive Direction Description Data Request Application -> MTP 3 Requests MTP 3 to transfer a data packet. Extended Status Request Application -> MTP 3 Registers/Deregisters the application to receive extended status indications. Data Indication MTP 3 -> Application Notifies the application of an incoming data packet. Status Indication MTP 3 -> Application Notifies the application of change in status of SS7 network. Extended Status Indication MTP 3 -> Application Notifies the application of a change in the status of MTP layer components. Flow Request Application -> MTP 3 Requests MTP 3 to start or stop flow control on a network SAP. 28 NMS Communications
29 Initialization and Binding 2.9 Initialization and Binding Before calling any MTP 3 API primitives, the application must first perform the following steps to set up the environment and bind itself to the desired MTP 3 SAPs: 1. Call ctainitialize (once per application) to initialize the Natural Access environment. 2. Create one or more Natural Access queues. 3. Create one Natural Access context per SAP and associate it with the appropriate queue. 4. Open the MTP 3 service, binding the user application to the specified MTP 3 SAP and associating that SAP with a Natural Access context and queue (done once for each context used by the application). Note: These steps are described in detail in Chapter Data Transfer MTP 3 is a connectionless protocol. Therefore, once an application has bound to the MTP 3 layer, it may begin sending data. This is accomplished with MTP3SendData. This call may succeed or fail immediately. If the call succeeds there may be a future status indication denoting that the message could not be delivered. Refer to Section 2.11, Status Indications, for more information. There is no future indication that the message was transferred successfully. Application MTP 3 Layer Remote SP MTP3SendData (dpc = x.y.z) MTP3SendData (dpc = x.y.z) MSU MSU Figure 9. Sending data NMS Communications 29
30 Chapter 2 Programming Model Asynchronous notification and polling are two methods for an application to receive incoming data and/or status indications. Status indications are covered in the next section but the following information applies to both data and status indications. Polling requires the application to continually check for incoming messages by periodically calling MTP3RetrieveMessage. The application must make sure to call this function regularly to avoid excessive queuing of messages in the TX driver or the MTP 3 layer task. MTP3RetrieveMessage will return MTP3_NO_MSG until a message is available. It will return MTP3_SUCCESS when a message is available. The following diagram shows the asynchronous notification method of receiving data: Application MTP 3 Layer Remote SP OS specific notification MSU MTP3RetrieveData Figure 10. Receiving Data (async notification) 30 NMS Communications
31 Status Indications 2.11 Status Indications Status indications may be received by an application through one of the receiving mechanisms described in the previous section. A status indication is sent to all applications when the corresponding network status changes. The possible status indications are described in the following table: Status Indication StatPaused StatResumed StatCongested StatCongestionEnds StatUsrUnavail StatRestart StatRestartEnds StatPrimary StatBackup StatStandAlone Description Indicates that delivery to the specified destination point code is not currently possible. It can mean that there is no route configured for the destination point code or that all routes to that point code are currently unavailable. The StatPaused indication does not specify which of the above was the case. Occurs after a StatPaused indication if one or more routes to a particular destination point code become available. Indicates that delivery to the destination SP failed due to network congestion at some point along the route. This implies that the user part/application should reduce traffic to that destination. Occurs after a StatCongested indication when network congestion has abated. Indicates that the message was delivered to the remote MTP 3 layer but that no application was registered to receive data with the service information octet (SIO) contained in the message. For example, data was sent with an SIO indicating an ISUP message, but there was no ISUP application running at the destination. The remote MTP 3 layer has discarded the message. Indicates that the local MTP 3 layer is going through a restart. This will be followed at some point by a StatRestartEnds. The application should not send any data messages after receiving this indication. Indicates that the local MTP 3 layer has completed its restart. The application may resume sending data messages. Indicates the local MTP 3 is the primary in a redundant configuration. Indicates the local MTP 3 is the backup in a redundant configuration. Indicates MTP is not in a redundant configuration. NMS Communications 31
32 Chapter 2 Programming Model 2.12 Extended Status Indications Extended status indications may be received by an application through one of the receiving mechanisms described in Section 2.10, Data Transfer. An extended status indication is sent to all applications registered to receive extended status indications when certain components of the MTP layer change state. Currently, MTP 2 links are the only components that support this feature. The possible extended status indications are described in the following table: Ext. Status Indication XStatLinkUp XStatLinkDown XStatLinkInh XStatLinkInhDen XStatLinkUninh XStatLinkUninhDen XStatLinkRemBlock XStatLinkRemUnblock XStatLinkLocBlock XStatLinkLocUnblock Description Indicates a link has finished aligning and is now available to the MTP 3 layer. This means traffic can now be carried over the available link. Indicates a link has gone out of service. The MTP 3 layer will now use other links, if available, to carry traffic. Indicates a link has become inhibited. Links become inhibited by management requests. The network (MTP layer) will never inhibit a link by itself, although it may uninhibit the link. An inhibited link is no longer used by the MTP 3 layer to carry traffic. Indicates an MTP 3 management entity attempted to inhibit a link, but the inhibition was denied. A possible cause would be that inhibiting the link would cause a destination to become inaccessible. Indicates that a link has become uninhibited and is now available to the MTP 3 layer for carrying traffic. Links may be uninhibited by MTP 3 management entities or by the MTP 3 layer automatically. Indicates the uninhibition of a link has been denied. This usually happens when the local MTP 3 layer is not able to negotiate the uninhibition of the link with the remote MTP layer. The link is still unavailable to the MTP 3 layer to carry traffic. Indicates a link has become remotely blocked. This is a result of a processor outage on the remote side of the link. The link is no longer available to carry traffic. Indicates the link is no longer remotely blocked. The link is now available to carry traffic unless inhibited or locally blocked. Indicates a link has become locally blocked. This is a result of a local processor outage. The link is no longer available to carry traffic. Indicates the link is no longer locally blocked. The link is now available to carry traffic unless inhibited or remotely blocked. 32 NMS Communications
33 Congestion Control 2.13 Congestion Control Understanding the MTP congestion control mechanisms and developing an effective application congestion control strategy is a critical step in developing a reliable system. MTP tracks and controls both inbound and outbound congestion. When outbound congestion occurs, upper layers that have bound to MTP are notified. This allows them to take some corrective action, such as reducing the traffic load that they generate, before the congestion becomes severe and impacts the operation of the service. In addition, MTP takes action on its own during both inbound and outbound congestion to assure that even a poorly behaved application or very high network traffic does not overwhelm normal operation. In most places, MTP uses a 4-level congestion control strategy, where level 0 indicates that the destination is not congested and level 3 indicates the most congested state. This matches the ANSI standards Outbound Congestion In MTP, there are two possible causes of outbound congestion: Æ The user application generates MTP traffic at a rate greater than the capacity of the SS7 links or downstream network, resulting in network overload. Æ The user application generates MTP requests faster than they can be processed by the MTP layer, resulting in the MTP API send queue building up beyond pre-determined thresholds. Network Overload Network overload occurs when the MTP layer s outbound queues build up beyond configured limits due to a traffic load which exceeds the capacity of the available signaling links, or due to receipt of a transfer controlled message (TFC) regarding a congested destination. NMS Communications 33
34 Chapter 2 Programming Model When outbound traffic is exceeding the total link capacity, transmission queues in the MTP 2 layer begin to build up. When the MTP 2 transmission queue for a link becomes full (layer 2 configuration parameter L2_TXQ_THRESH2), the MTP 3 layer ceases sending to the congested link. This causes MTP 3 queues to begin building up. There are four configurable levels at which congestion indications of that priority are generated. Defaults and the correct parameter names (in the LINK section in the MTP 3 configuration file) are displayed in the following table: Parameter Default P0QUE_LENGTH 16 P1QUE_LENGTH 32 P2QUE_LENGTH 64 P3QUE_LENGTH 128 Note: These are MTP 3 queue levels in addition to the L2_TXQ_THRESH2 messages queued at layer 2. Whether MTP 3 s transmit queues have built due to network overload or a transfer controlled (TFC) was received about a remote destination, the user application is notified by receipt of an MTP status indication. This manifests itself as a Natural Access event MTP3EVN_DATA with a message code of MTP3_STAT_IND and status of StatCongested. This indication contains the affected pointed code and the current congestion level (0 to 3). The application should then reduce its traffic load toward the affected destination until the congestion abates. In ANSI networks and in other national networks employing multiple congestion levels, the user application must not generate any new traffic towards the affected destination with a priority lower than the current destination congestion level, as it will be discarded at the MTP layer. For the international signaling network, and other ITU-based networks without multiple congestion priorities, it is especially important for the user application to reduce the traffic load toward the affected destination, as the MTP layer only discards outgoing packets in cases of excessive queuing of traffic to congested signaling links. Failure of the application to reduce its traffic load toward the congested destination may escalate the congestion condition. When the network overload condition ceases, the user application receives a Natural Access event MTP3EVT_DATA with a message code of MTP3_STAT_IND and status of StatCongestionEnds, indicating that the application may resume normal traffic towards the affected destination. 34 NMS Communications
35 Inbound Congestion MTP API Congestion MTP 3 API congestion occurs when an application generates traffic faster than it can be accepted by the MTP layer, resulting in the MTP 3 API transmission queue building beyond pre-determined thresholds. This only applies to applications that use the MTP 3 API to communicate with MTP directly. The application is notified of API congestion by receipt of an MTP3EVN_CONGEST Natural Access event which includes the current MTP 3 congestion level (0 to 3, where 0 indicates that congestion has ceased). As the MTP 3 congestion level increases, the application is expected to reduce its traffic load proportionately until the congestion ceases. By default, the MTP 3 API allocates a buffer pool for up to 256 requests to be queued to the MTP layer. If the application fails to reduce its traffic load enough to ease the congestion, eventually the MTP 3 API buffer pool will become depleted and the MTP 3 API send primitives will fail with a CTAERR_OUT_OF_MEMORY return code. The application can increase the number of buffers in the pool (allowing a larger burst of traffic to be absorbed without triggering congestion, at the cost of more host memory used) by setting service argument array element six to a number between 128 and 1024 when opening the MTP service (see Section 3.2.3). Congestion onset and abatement thresholds are always set to a fixed percentage of the buffers in use (queued to the MTP layer) regardless of the total size of the pool, as shown in the following table: Congestion Level Onset Threshold (to reach this level) Abatement Threshold (to next lower level) 1 Greater than 75% of pool in use. Less than 50% of pool in use. 2 Greater than 85% of pool in use. Less than 80% of pool in use. 3 Greater than 95% of pool in use. Less than 90% of pool in use Inbound Congestion MTP inbound congestion is caused by the MTP user application not reading incoming messages as fast as they are being generated by the network, resulting in build-up of the user SAP queue and/or a depletion of the layer 1 limited pools used to receive incoming messages on each link. Unlike outbound congestion, the MTP user application is not notified directly of inbound congestion level changes in order to prevent escalation of the congestion NMS Communications 35
36 Chapter 2 Programming Model condition. However, an alarm is always generated when a change in an MTP user SAP s inbound congestion level occurs. For inbound congestion, the MTP layer cannot rely on the user application to reduce its traffic load to ease the congestion, as the source of the traffic bursts is generally other network nodes. Instead, the MTP layer acts directly to control inbound congestion in two ways. First, as the NSAP queues to upper layers build up, configurable thresholds are crossed which set the NSAP s congestion priority. For national networks, MTP discards inbound messages having a priority lower than the current NSAP congestion level. This ensures that a slow or dead upper layer cannot starve out other upper layers. No such discarding is done for international networks which have no message priorities. The limited pools will ensure that all board memory is not used up in that case, but a slow or dead upper layer could starve out other upper layers. Second, once the level 1 limited pools reach a defined threshold of allocated buffers, MTP 2 will begin generating SIB s (Status Indication Busy) out that link. Enough buffers remain in the limited pool to handle an additional window of 127 messages after SIB s are started. These limited pools disallow a renegade link from using up all of MTP s memory. There are four configurable levels at which discarding of lower priority national messages occurs. Defaults and the correct parameter names (in the NSAP section in the MTP 3 configuration file) are displayed in the following table: Parameter Default P0QUE_LENGTH 0 P1QUE_LENGTH 512 P2QUE_LENGTH 798 P3QUE_LENGTH 896 For example, when there are 512 messages queued to an upper layer, the NSAP s congestion priority becomes 1 and thereafter national messages of priority 0 are discarded rather than being queued. Similarly, when the queue size reaches 798, messages of priority 0 and 1 are discarded. The number of inbound messages discarded due to NSAP congestion can be determined with Mtp3NSapStatus or through the mtpmgr utility with the command Mtp3NSapStatus x. 36 NMS Communications
NMS ISDN Supplementary Services Developer s Manual P/N
NMS ISDN Supplementary Services Developer s Manual P/N 9000-6502-21 NMS Communications Corporation 100 Crossing Boulevard Framingham, MA 01702 NMS ISDN Supplementary Services Developer s Manual No part
More informationInstalling NMS SS
Installing NMS SS7 4.3 9000-62436-13 100 Crossing Boulevard Framingham, MA 01702-5406 USA www.nmscommunications.com Installing NMS SS7 4.3 No part of this document may be reproduced or transmitted in any
More informationTB640 SS7 user's guide
Document number 9010-00030-20 September 2008 Copyright 2003-2008 by TelcoBridges inc. All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic
More informationAG ISDN Messaging API Developer s Reference Manual
Developer s Reference Manual P/N 6272-21 Natural MicroSystems Corporation 100 Crossing Blvd. Framingham, MA 01702 No part of this document may be reproduced or transmitted in any form or by any means without
More informationINTERNATIONAL TELECOMMUNICATION UNION 30%#)&)#!4)/.3 /& 3)'.!,,).' 3934%-.O
INTERNATIONAL TELECOMMUNICATION UNION )454 1 TELECOMMUNICATION (03/93) STANDARDIZATION SECTOR OF ITU 30%#)&)#!4)/.3 /& 3)'.!,,).' 3934%-.O &5.#4)/.!, $%3#2)04)/. /& 4(% -%33!'% 42!.3&%2 0!24-40 /& 3)'.!,,).'
More information3GPP TS V9.0.0 ( )
TS 29.016 V9.0.0 (2009-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); Serving GPRS Support
More information3GPP TS V3.1.0 ( )
TS 29.016 V3.1.0 (2000-09) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN)
More informationTS V6.0.1 ( )
Technical Specification Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface network
More informationINTERNATIONAL TELECOMMUNICATION UNION TELEPHONE NETWORK AND ISDN QUALITY OF SERVICE, NETWORK MANAGEMENT AND TRAFFIC ENGINEERING
INTERNATIONAL TELECOMMUNICATION UNION CCITT E.505 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE TELEPHONE NETWORK AND ISDN QUALITY OF SERVICE, NETWORK MANAGEMENT AND TRAFFIC ENGINEERING
More informationJP-3GA (R99) Serving GPRS Support Node SGSN - Visitors Location Register (VLR); Gs Interface Network Service Specification
JP-3GA-29.016(R99) Serving GPRS Support Node SGSN - Visitors Location Register (VLR); Gs Interface Network Service Specification Version 2 May 14, 2001 THE TELECOMMUNICATION TECHNOLOGY COMMITTEE JP-3GA-29.016(R99)
More informationITU-T Q.752 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU
INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.752 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (06/97) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System. 7 Signalling System. 7
More informationVideo Messaging Server Interface Developer's Reference Manual
Video Messaging Server Interface Developer's Reference Manual 9000-62479-18 100 Crossing Boulevard Framingham, MA 01702-5406 USA www.nmscommunications.com Video Messaging Server Interface Reference No
More information3GPP TS V8.0.1 ( )
TS 08.06 V8.0.1 (2002-05) Technical Specification 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Signalling transport mechanism specification for the Base
More informationSS7 MTP Layer 2 Developer s Reference Manual
SS7 MTP Layer 2 Developer s Reference Manual P/N 9000-6477-17 100 Crossing Boulevard, Framingham, MA 01702-5406 USA www.nmscommunications.com No part of this document may be reproduced or transmitted in
More information)454 1 ).42/$5#4)/. 4/ ##)44 3)'.!,,).' 3934%-.O 30%#)&)#!4)/.3 /& 3)'.!,,).' 3934%-.O. )454 Recommendation 1 INTERNATIONAL TELECOMMUNICATION UNION
INTERNATIONAL TELECOMMUNICATION UNION )454 1 TELECOMMUNICATION (03/93) STANDARDIZATION SECTOR OF ITU 30%#)&)#!4)/.3 /& 3)'.!,,).' 3934%-.O ).42/$5#4)/. 4/ ##)44 3)'.!,,).' 3934%-.O )454 Recommendation
More informationINTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Broadband ISDN Signalling network protocols
INTERNATIONAL TELECOMMUNICATION UNION )454 1 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (07/96) SERIES Q: SWITCHING AND SIGNALLING Broadband ISDN Signalling network protocols -ESSAGE TRANSFER PART
More informationGR-246-CORE Issue 10 Telcordia Technologies Specification of Signalling System Number 7. General Contents. Volume 1
SS7 GENERAL OVERVIEW: T110 Volume 1 MESSAGE TRANSFER PART (MTP): T1.111 T1.111.1 FUNCTIONAL DESCRIPTION OF THE MESSAGE TRANSFER PART 1. General 2. Signalling System Structure 3. Signalling Network 4. Message
More information3GPP TS V8.0.0 ( )
Technical Specification 3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio Access Network; Signalling transport mechanism specification for the Base Station System - Mobile-services
More informationSS7. Mercantec H2 2009
SS7 Mercantec H2 2009 Common Channel Signaling System No. 7 basic call setup, management, and tear down wireless services such as personal communications services (PCS), wireless roaming, and mobile subscriber
More informationSignaling Network Functions (MTP Level 3)
Signaling Network Functions (MTP Level 3) Level 3 in principle defines those transport functions and procedures that are common to and independent of the operation of individual signaling links. These
More information2000 Performance Technologies, Inc.
Table of Contents SS7 Tutorial...1 SS7 Tutorial...3 Overview...3 SS7 Protocol Stack...6 Message Transfer Part...7 ISDN User Part...13 Signaling Connection Control Part...20 Transaction Capabilities Application
More informationIntel NetStructure SS7 Protocols M3UA Programmer s Manual
Intel NetStructure SS7 Protocols M3UA Programmer s Manual Document Reference: U02STN M3UA Programmer s Manual Issue 2 Page 1 REVISION HISTORY ISSUE DATE BY CHANGES 1 28-Jun-02 IDP Initial Release 2 19-Jun-03
More informationETSI TS V4.1.0 ( )
Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Serving GPRS Support Node SGSN - Visitors Location Register (VLR); Gs Interface
More informationSS7 Tutorial. User Parts
SS7 Tutorial User Parts OSI Layers Application Presentation Session Transport Network Data Link Physical The Layered Model To understand the SS7 protocol, it is helpful to understand the concept of protocol
More informationFusion Installation Manual
Fusion Installation Manual P/N 6380-14 Natural MicroSystems Corporation 100 Crossing Blvd. Framingham, MA 01702 No part of this document may be reproduced or transmitted in any form or by any means without
More informationINTERNATIONAL TELECOMMUNICATION UNION
INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.711 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2001) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling connection
More informationNOTES 1 CCITT Recommendation Q.700 was published in Fascicle VI.7 of the Blue Book. This file is an extract from the Blue Book. While the presentation
INTERNATIONAL TELECOMMUNICATION UNION CCITT Q.700 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE (11/1988) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7
More informationOracle Communications Network Charging and Control. SIGTRAN m3ua_if Protocol Implementation Conformance Statement Release 6.0.1
Oracle Communications Network Charging and Control SIGTRAN m3ua_if Protocol Implementation Conformance Statement Release 6.0.1 April 2017 Copyright Copyright 2017, Oracle and/or its affiliates. All rights
More informationINTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling connection control part
INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.711 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (07/96) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling connection
More informationIntel NetStructure SS7 Protocols SCCP Programmer's Manual. Document Reference: U05SSS
Intel NetStructure SS7 Protocols SCCP Programmer's Manual Document Reference: U05SSS Disclaimer The product may contain design defects or errors known as errata, which may cause the product to deviate
More informationINTERNATIONAL TELECOMMUNICATION UNION. SPECIFICATIONS OF SIGNALLING SYSTEM No. 7
INTERNATIONAL TELECOMMUNICATION UNION Q.74 TELECOMMUNICATION (0/9) STANDARDIZATION SECTOR OF ITU SPECIFICATIONS OF SIGNALLING SYSTEM. 7 SIGNALLING SYSTEM. 7 SIGNALLING CONNECTION CONTROL PART PROCEDURES
More informationCourse 5 The SS7 signaling systems.
Course 5 The SS7 signaling systems. Zsolt Polgar Communications Department Faculty of Electronics and Telecommunications, Technical University of Cluj-Napoca General aspects; The SS7 architecture; Node
More informationSignaling traffic management in short peak signaling traffic loads
Signaling traffic management in short peak signaling traffic loads N Curic-Segaric, I Ljubic, K Delac Carrier Services Department Croatian Telecom, Inc Complete Address: Kupska 2, Zagreb, 10000, Croatia
More informationThe BANDIT can also concentrate and switch multiple sources of Frame Relay traffic simultaneously.
encor! enetworks TM Version A, March 2008 2013 Encore Networks, Inc. All rights reserved. Routing with Frame Relay This chapter discusses Frame Relay routing. 4.1 Frame Relay You can configure use of synchronous
More informationINTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Test specification
INTERNATIONAL TELECOMMUNICATION UNION )454 1 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (07/96) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Test specification -40
More informationTransport of (Legacy) Signaling over IP. Summary of course scope
Transport of (Legacy) Signaling over SIGTRAN architecture (http://www.ietf.org/html.charters/sigtran-charter.html) Raimo Kantola S- 2004 Signaling Protocols 15-1 Summary of course scope PABX H.323 or S
More informationConfiguring the SS7 Q.703 High Speed Port Adapter
CHAPTER 4 Configuring the SS7 Q.703 High Speed Port Adapter This chapter contains the following sections: Using the EXEC Command Interpreter, page 4-1 Configuring the Interfaces, page 4-2 Checking the
More informationSignaling System 7 (SS7) By : Ali Mustafa
Signaling System 7 (SS7) By : Ali Mustafa Contents Types of Signaling SS7 Signaling SS7 Protocol Architecture SS7 Network Architecture Basic Call Setup SS7 Applications SS7/IP Inter-working VoIP Network
More informationRouting in packet-switching networks
Routing in packet-switching networks Circuit switching vs. Packet switching Most of WANs based on circuit or packet switching Circuit switching designed for voice Resources dedicated to a particular call
More informationRequest for Comments: 3094 Category: Informational J. Keller Tekelec April 2001
Network Working Group Request for Comments: 3094 Category: Informational D. Sprague R. Benedyk D. Brendes J. Keller Tekelec April 2001 Status of this Memo Tekelec s Transport Adapter Layer Interface This
More informationDATA COMMUNICATIONS TECHNICAL REFERENCE TR AT&T INTELLIGENT CALL PROCESSING (ICP) SERVICE SIGNALING SYSTEM No. 7 NETWORK INTERFACE
DATA COMMUNICATIONS TECHNICAL REFERENCE TR 54022 AT&T INTELLIGENT CALL PROCESSING (ICP) SERVICE SIGNALING SYSTEM No. 7 NETWORK INTERFACE SPECIFICATION ISSUE 5 FEBRUARY, 1997 NOTICE This Technical Reference
More information3G-324M Interface Developer's Reference Manual P/N
3G-324M Interface Developer's Reference Manual P/N 9000-62471-13 100 Crossing Boulevard Framingham, MA 01702-5406 USA www.nmscommunications.com 3G-324M Interface Developer's Reference Manual No part of
More informationTraffic Link Redundancy
Traffic Link Redundancy 80% of the traffic saved if one link goes down 2 separated routes 3 separated routes eg 10E per link then: 80*(10+10)=16E 80*(10+10+10)/2=16E The redundancy factor becomes 1.6 and
More informationND1011:2002/10 PNO-ISC/SPEC/011 ATM
NICC Document ND1011:2002/10 ND1011:2002/10 PNO-ISC/SPEC/011 ATM Transport For Interconnect Network Interoperability Consultative Committee Oftel 50 Ludgate Hill London EC4M 7JJ UK http://www.oftel.gov.uk/ind_groups/nicc/
More informationEUROPEAN ETS TELECOMMUNICATION December 1991 STANDARD
EUROPEAN ETS 300 009 TELECOMMUNICATION December 1991 STANDARD Source: ETSI TC-SPS Reference: T/S 43-03 ICS: 33.020 Key words: ISDN, CCITT SS7 No 7. Integrated Services Digital Network (ISDN); CCITT Signalling
More informationSystemy sygnalizacji i zarządzania TI
Systemy sygnalizacji i zarządzania TI SS7: warstwa sieciowa Krzysztof Wajda Katedra Telekomunikacji AGH Listopad, 2016 Outline Network management Message handling processes Message routing Traffic management
More informationDialogic TX Series SS7 Boards
Dialogic TX Series SS7 Boards Loader Library Developer s Reference Manual July 2009 64-0457-01 www.dialogic.com Loader Library Developer's Reference Manual Copyright and legal notices Copyright 1998-2009
More informationEN V1.1.2 ( )
European Standard (Telecommunications series) Integrated Services Digital Network (ISDN); Signalling System No.7; Signalling Connection Control Part (SCCP); Interoperability test specification 2 Reference
More informationVideo Mail Application Demonstration Program Manual
Video Mail Application Demonstration Program Manual 9000-62480-18 100 Crossing Boulevard Framingham, MA 01702-5406 USA www.nmscommunications.com Video Mail Application Demonstration Program Manual No part
More informationWilliam Stallings Data and Computer Communications. Chapter 10 Packet Switching
William Stallings Data and Computer Communications Chapter 10 Packet Switching Principles Circuit switching designed for voice Resources dedicated to a particular call Much of the time a data connection
More informationDialogic DSI Protocol Stacks
Dialogic DSI Protocol Stacks M3UA Programmer's Manual March 2017 U02STN www.dialogic.com Copyright and Legal Notice Copyright 2002-2017 Dialogic Corporation. All Rights Reserved. You may not reproduce
More informationOrganizations have developed standard sets of protocols
Network Models Organizations have developed standard sets of protocols Some of these organizations are: The International Standards Organization (ISO) The Institute of Electrical and Electronic Engineers
More informationTELECOMMUNICATION SYSTEMS
TELECOMMUNICATION SYSTEMS By Syed Bakhtawar Shah Abid Lecturer in Computer Science 1 Signaling System 7 Architecture Signaling System 7 Protocol Stacks Overview Level 1: Physical Connection SS7 Level 2:
More information3G-324M Interface Developer's Reference Manual
3G-324M Interface Developer's Reference Manual 9000-62471-19 100 Crossing Boulevard Framingham, MA 01702-5406 USA www.nmscommunications.com 3G-324M Interface Developer's Reference Manual No part of this
More informationNATO UNCLASSIFIED STANAG 5066: PROFILE FOR HF DATA COMMUNICATION ANNEX B: V1.2. Annex B: Channel Access Sublayer (mandatory)
Annex B: Channel Access Sublayer (mandatory) The functions required of the channel access sublayer are quite limited in the HF subnetwork. B.1 Channel Access Sublayer Service Definition The Channel Access
More informationLoadsharing A key to the reliability for SS7-networks
Loadsharing A key to the reliability for SS7-networks Klaus D. Gradischnig Siemens AG Stefan Krämer Teles NetConsult GmbH Michael Tüxen Siemens AG Abstract This paper analyzes loadsharing principles and
More informationInterworking Switched Circuit and Voice-over IP Networks Tutorial
Interworking Switched Circuit and Voice-over IP Networks Tutorial Definition The term operations support systems (OSSs) generally refers to the systems that perform management, inventory, engineering,
More informationINTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Interworking of Signalling Systems Specifications of Signalling System No.
INTERNATIONAL TELECOMMUNICATION UNION CCITT Q.763 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE (11/1988) SERIES Q: SWITCHING AND SIGNALLING Interworking of Signalling Systems Specifications
More informationAccessing SGM Data from a Web Browser
CHAPTER 7 Accessing SGM Data from a Web Browser This chapter provides information about accessing SGM data from the SGM server home page, using a Web browser. This chapter includes the following sections:
More informationConfiguring Dial-on-Demand Routing
C H A P T E R 7 Configuring Dial-on-Demand Routing This chapter describes how to configure your communication server for dial-on-demand routing (DDR) and dial backup. For a complete description of the
More informationSections Describing Standard Software Features
30 CHAPTER This chapter describes how to configure quality of service (QoS) by using automatic-qos (auto-qos) commands or by using standard QoS commands. With QoS, you can give preferential treatment to
More informationManaging Costs in Growing Networks with SEGway STPs and Point Code Emulation
Managing Costs in Growing Networks with SEGway STPs and Point Code Emulation Deb Brunner-Walker, Performance Technologies Technology White Paper www.pt.com Introduction Voice networks are evolving from
More informationUSB Feature Specification: Shared Endpoints
USB Feature Specification: Shared Endpoints SYSTEMSOFT CORPORATION INTEL CORPORATION Revision 1.0 October 27, 1999 USB Feature Specification: Shared Endpoints Revision 1.0 Revision History Revision Issue
More informationDialogic DSI Protocol Stacks
Dialogic DSI Protocol Stacks User Guide: Running DSI User Parts Over Dialogic TX Series SS7 Boards February 2010 U03DPK02 www.dialogic.com Copyright and Legal Notice Copyright 2009-2010 Dialogic Corporation.
More informationCourse 4-5 Signaling techniques used in classical telephone networks. The SS7 signaling systems.
Course 4-5 Signaling techniques used in classical telephone networks. The SS7 signaling systems. Zsolt Polgar Communications Department Faculty of Electronics and Telecommunications, Technical University
More informationDialogic NaturalAccess MTP2 Layer Developer s Reference Manual
Dialogic NaturalAccess MTP2 Layer Developer s Reference Manual July 2009 64-0464-01 www.dialogic.com MTP2 Layer Developer's Reference Manual Copyright and legal notices Copyright 1998-2009 Dialogic Corporation.
More informationContents. Configuring LLDP 2
Contents Configuring LLDP 2 Overview 2 Basic concepts 2 Working mechanism 8 Protocols and standards 9 LLDP configuration task list 9 Performing basic LLDP configurations 10 Enabling LLDP 10 Configuring
More informationINTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling System No.
INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.750 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (06/97) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling System
More informationTelecommunication Services Engineering Lab
Logistics Instructor Office: EV006-227, Tel: 1-514-8482424 ext 5846, Email: Glitho@ciiseconcordiaca URL: http://wwwececoncordiaca/~glitho/ Office hours: Friday: 3 pm 5 pm Time: Friday, 17h45-20h15 Room
More informationINTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling connection control part
INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.714 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (07/96) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System. 7 Signalling connection
More informationNMS Board and Driver Errors Manual P/N
NMS Board and Driver Errors Manual P/N 9000-60005-15 100 Crossing Boulevard, Framingham, MA 01702-506 USA www.nmscommunications.com NMS Board and Driver Errors Manual No part of this document may be reproduced
More informationAccessing SGM Data from a Web Browser
CHAPTER 7 Accessing SGM Data from a Web Browser This chapter provides information about accessing SGM data from the SGM server home page, using a Web browser. This chapter includes the following sections:
More informationReplicator Disaster Recovery Best Practices
Replicator Disaster Recovery Best Practices VERSION 7.4.0 June 21, 2017 Scenario Guide Article 1120504-01 www.metalogix.com info@metalogix.com 202.609.9100 Copyright International GmbH, 2002-2017 All rights
More informationSections Describing Standard Software Features
27 CHAPTER This chapter describes how to configure quality of service (QoS) by using automatic-qos (auto-qos) commands or by using standard QoS commands. With QoS, you can give preferential treatment to
More information3GPP TS V4.3.0 ( )
TS 29.202 V4.3.0 (2002-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network; SS7 Signalling Transport in Core Network; Stage 3 (Release 4) The present
More informationNetworking technologies and applications
Networking technologies and applications Common Channel Signaling System 7 (SS7) Part 1 Gusztáv Adamis BME TMIT 2015 Networking technologies and applications 1 Channel Associated Signaling - CAS 2 Signaling:
More informationConfiguring Queuing and Flow Control
This chapter contains the following sections: Information About Queues, page 1 Information About Flow Control, page 4 Configuring Queuing, page 5 Configuring Flow Control, page 9 Verifying the Queue and
More informationOracle Communications Diameter Signaling Router Virtual Signaling Transfer Point User's Guide Release 8.1 E86290 Revision 01
Oracle Communications Diameter Signaling Router Virtual Signaling Transfer Point User's Guide Release 8.1 E86290 Revision 01 July 2017 Oracle Communications Diameter Signaling Router Virtual Signaling
More informationHP 5120 SI Switch Series
HP 5120 SI Switch Series Layer 2 - LAN Switching Configuration Guide Part number: 5998-1807 Software version: Release 1513 Document version: 6W100-20130830 Legal and notice information Copyright 2013 Hewlett-Packard
More informationLast Class: RPCs and RMI. Today: Communication Issues
Last Class: RPCs and RMI Case Study: Sun RPC Lightweight RPCs Remote Method Invocation (RMI) Design issues Lecture 9, page 1 Today: Communication Issues Message-oriented communication Persistence and synchronicity
More informationRequest for Comments: 851 Obsoletes RFC: 802. The ARPANET 1822L Host Access Protocol RFC 851. Andrew G. Malis ARPANET Mail:
Request for Comments: 851 Obsoletes RFC: 802 The ARPANET 1822L Host Access Protocol Andrew G. Malis ARPANET Mail: malis@bbn-unix Bolt Beranek and Newman Inc. 50 Moulton St. Cambridge, MA 02238 April 1983
More informationDialogic SS7 Protocols
Dialogic SS7 Protocols SUA Programmer's Manual www.dialogic.com Copyright 2007-2008 Dialogic Corporation. All Rights Reserved. You may not reproduce this document in whole or in part without permission
More informationSCCP Programmer s Manual Version 1.0.2
SCCP Programmer s Manual Version 1.0.2 Copyright C) 2011 Shabd Communications Pvt Ltd., India http://www.shabdcom.org, sales@shabdcom.org Table of Contents...1 1 INTRODUCTION...7 2 API RETURN VALUES &
More informationRouting Strategies. Fixed Routing. Fixed Flooding Random Adaptive
Routing Strategies Fixed Flooding Random Adaptive Fixed Routing Single permanent route for each source to destination pair Determine routes using a least cost algorithm Route fixed, at least until a change
More informationUnderstanding SROS Priority Queuing, Class-Based WFQ, and QoS Maps
Configuration Guide 5991-2121 May 2006 Understanding SROS Priority Queuing, Class-Based WFQ, and QoS Maps This Configuration Guide explains the concepts behind configuring your Secure Router Operating
More informationContents. Configuring LLDP 2
Contents Configuring LLDP 2 Overview 2 Basic concepts 2 Working mechanism 7 Protocols and standards 8 LLDP configuration task list 8 Performing basic LLDP configurations 9 Enabling LLDP 9 Setting the LLDP
More information) /24 /& 0!#+%4 -/$% 4%2-).!, %15)0-%.4 "9!. )3$. $!4!.%47/2+3!.$ /0%. 3934%- #/--5.)#!4)/.3 05",)# $!4!.%47/2+3 ).4%2&!
INTERNATIONAL TELECOMMUNICATION UNION )454 8 TELECOMMUNICATION (11/95) STANDARDIZATION SECTOR OF ITU $!4!.%47/2+3!.$ /0%. 3934%- #/--5.)#!4)/.3 05",)# $!4!.%47/2+3 ).4%2&!#%3 3500/24 /& 0!#+%4 -/$% 4%2-).!,
More informationTeldat Router. Frame Relay
Teldat Router Frame Relay Doc. DM503-I Rev. 8.40 September, 2000 INDEX Chapter 1 The Frame Relay interface... 1 1. Introduction...2 2. Frame Relay Overview...3 2.1. Frame Relay Network...3 2.2. Frame Relay
More informationNetwork Working Group. Category: Informational February 1997
Network Working Group K. Hamzeh Request for Comments: 2107 Ascend Communications Category: Informational February 1997 Status of this Memo Ascend Tunnel Management Protocol - ATMP This memo provides information
More informationQOS Section 6. Weighted Random Early Detection (WRED)
QOS Section 6 Weighted Random Early Detection (WRED) The previous section addressed queuing, which is a congestionmanagement QoS mechanism. However, this section focuses on congestion avoidance. Specifically,
More informationConfiguring Priority Flow Control
This chapter contains the following sections: Information About Priority Flow Control, page 1 Guidelines and Limitations, page 2 Default Settings for Priority Flow Control, page 3 Enabling Priority Flow
More informationContents. Configuring LLDP 2
Contents Configuring LLDP 2 Overview 2 Basic concepts 2 Working mechanism 7 Protocols and standards 8 LLDP configuration task list 8 Performing basic LLDP configurations 9 Enabling LLDP 9 Setting the LLDP
More informationConfiguring Interfaces and Circuits
CHAPTER 5 This chapter describes how to configure the CSS interfaces and circuits and how to bridge interfaces to Virtual LANs (VLANs). Information in this chapter applies to all CSS models, except where
More informationEnabling Dual Chassis Fault Tolerance with Intel NetStructure SS7 Boards
Enabling Dual Chassis Fault Tolerance with Intel NetStructure Boards Intel in Communications Enabling Dual Chassis Fault Tolerance with Intel NetStructure Boards Contents Abstract.......................................................
More informationApplication Note. Enabling Dual-Chassis Fault Tolerance with the Dialogic DSI SIGTRAN Stack
Enabling Dual-Chassis Fault Tolerance with the Dialogic DSI SIGTRAN Stack Executive Summary In seeking to achieve five-nines (99.999%) availability and a high degree of fault tolerance in a SIGTRAN signaling
More informationNovell. NetWare 6. FILTER CONFIGURATION
Novell NetWare 6 www.novell.com FILTER CONFIGURATION Legal Notices Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims
More informationWide Area Network Device Presence Protocol (WAN DPP)
[MS-GRVWDPP]: Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages,
More informationx25 remote-red x25 remote-red This command is no longer supported. Cisco IOS Wide-Area Networking Command Reference WR
x25 remote-red x25 remote-red This command is no longer supported. WR-553 x25 retry x25 retry To activate a secondary route while also retrying a failed primary route, use the x25 retry interface configuration
More informationINTERNATIONAL TELECOMMUNICATION UNION
INTERNATIONAL TELECOMMUNICATION UNION CCITT Q.713 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE (11/1988) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7
More informationCisco 1000 Series Connected Grid Routers QoS Software Configuration Guide
Cisco 1000 Series Connected Grid Routers QoS Software Configuration Guide January 17, 2012 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com
More information