SS7 MTP Layer 3 Developer s Reference Manual

Size: px
Start display at page:

Download "SS7 MTP Layer 3 Developer s Reference Manual"

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 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 information

Installing NMS SS

Installing 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 information

TB640 SS7 user's guide

TB640 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 information

AG ISDN Messaging API Developer s Reference Manual

AG 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 information

INTERNATIONAL TELECOMMUNICATION UNION 30%#)&)#!4)/.3 /& 3)'.!,,).' 3934%-.O

INTERNATIONAL 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 information

3GPP TS V9.0.0 ( )

3GPP 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 information

3GPP TS V3.1.0 ( )

3GPP 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 information

TS V6.0.1 ( )

TS 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 information

INTERNATIONAL TELECOMMUNICATION UNION TELEPHONE NETWORK AND ISDN QUALITY OF SERVICE, NETWORK MANAGEMENT AND TRAFFIC ENGINEERING

INTERNATIONAL 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 information

JP-3GA (R99) Serving GPRS Support Node SGSN - Visitors Location Register (VLR); Gs Interface Network Service Specification

JP-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 information

ITU-T Q.752 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU

ITU-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 information

Video Messaging Server Interface Developer's Reference Manual

Video 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 information

3GPP TS V8.0.1 ( )

3GPP 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 information

SS7 MTP Layer 2 Developer s Reference Manual

SS7 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

)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 information

INTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Broadband ISDN Signalling network protocols

INTERNATIONAL 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 information

GR-246-CORE Issue 10 Telcordia Technologies Specification of Signalling System Number 7. General Contents. Volume 1

GR-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 information

3GPP TS V8.0.0 ( )

3GPP 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 information

SS7. Mercantec H2 2009

SS7. 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 information

Signaling Network Functions (MTP Level 3)

Signaling 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 information

2000 Performance Technologies, Inc.

2000 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 information

Intel NetStructure SS7 Protocols M3UA Programmer s Manual

Intel 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 information

ETSI TS V4.1.0 ( )

ETSI 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 information

SS7 Tutorial. User Parts

SS7 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 information

Fusion Installation Manual

Fusion 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 information

INTERNATIONAL TELECOMMUNICATION UNION

INTERNATIONAL 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 information

NOTES 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

NOTES 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 information

Oracle 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 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 information

INTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling connection control part

INTERNATIONAL 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 information

Intel NetStructure SS7 Protocols SCCP Programmer's Manual. Document Reference: U05SSS

Intel 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 information

INTERNATIONAL TELECOMMUNICATION UNION. SPECIFICATIONS OF SIGNALLING SYSTEM No. 7

INTERNATIONAL 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 information

Course 5 The SS7 signaling systems.

Course 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 information

Signaling traffic management in short peak signaling traffic loads

Signaling 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 information

The BANDIT can also concentrate and switch multiple sources of Frame Relay traffic simultaneously.

The 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 information

INTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Test specification

INTERNATIONAL 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 information

Transport of (Legacy) Signaling over IP. Summary of course scope

Transport 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 information

Configuring the SS7 Q.703 High Speed Port Adapter

Configuring 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 information

Signaling System 7 (SS7) By : Ali Mustafa

Signaling 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 information

Routing in packet-switching networks

Routing 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 information

Request for Comments: 3094 Category: Informational J. Keller Tekelec April 2001

Request 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 information

DATA COMMUNICATIONS TECHNICAL REFERENCE TR AT&T INTELLIGENT CALL PROCESSING (ICP) SERVICE SIGNALING SYSTEM No. 7 NETWORK INTERFACE

DATA 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 information

3G-324M Interface Developer's Reference Manual P/N

3G-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 information

Traffic Link Redundancy

Traffic 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 information

ND1011:2002/10 PNO-ISC/SPEC/011 ATM

ND1011: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 information

EUROPEAN ETS TELECOMMUNICATION December 1991 STANDARD

EUROPEAN 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 information

Systemy sygnalizacji i zarządzania TI

Systemy 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 information

Dialogic TX Series SS7 Boards

Dialogic 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 information

EN V1.1.2 ( )

EN 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 information

Video Mail Application Demonstration Program Manual

Video 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 information

William Stallings Data and Computer Communications. Chapter 10 Packet Switching

William 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 information

Dialogic DSI Protocol Stacks

Dialogic 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 information

Organizations have developed standard sets of protocols

Organizations 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 information

TELECOMMUNICATION SYSTEMS

TELECOMMUNICATION 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 information

3G-324M Interface Developer's Reference Manual

3G-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 information

NATO UNCLASSIFIED STANAG 5066: PROFILE FOR HF DATA COMMUNICATION ANNEX B: V1.2. Annex B: Channel Access Sublayer (mandatory)

NATO 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 information

Loadsharing A key to the reliability for SS7-networks

Loadsharing 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 information

Interworking Switched Circuit and Voice-over IP Networks Tutorial

Interworking 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 information

INTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Interworking of Signalling Systems Specifications of Signalling System No.

INTERNATIONAL 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 information

Accessing SGM Data from a Web Browser

Accessing 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 information

Configuring Dial-on-Demand Routing

Configuring 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 information

Sections Describing Standard Software Features

Sections 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 information

Managing Costs in Growing Networks with SEGway STPs and Point Code Emulation

Managing 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 information

USB Feature Specification: Shared Endpoints

USB 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 information

Dialogic DSI Protocol Stacks

Dialogic 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 information

Course 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. 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 information

Dialogic NaturalAccess MTP2 Layer Developer s Reference Manual

Dialogic 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 information

Contents. Configuring LLDP 2

Contents. 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 information

INTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling System No.

INTERNATIONAL 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 information

Telecommunication Services Engineering Lab

Telecommunication 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 information

INTERNATIONAL TELECOMMUNICATION UNION. SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 Signalling connection control part

INTERNATIONAL 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 information

NMS Board and Driver Errors Manual P/N

NMS 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 information

Accessing SGM Data from a Web Browser

Accessing 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 information

Replicator Disaster Recovery Best Practices

Replicator 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 information

Sections Describing Standard Software Features

Sections 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 information

3GPP TS V4.3.0 ( )

3GPP 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 information

Networking technologies and applications

Networking 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 information

Configuring Queuing and Flow Control

Configuring 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 information

Oracle 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 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 information

HP 5120 SI Switch Series

HP 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 information

Last Class: RPCs and RMI. Today: Communication Issues

Last 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 information

Request 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 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 information

Dialogic SS7 Protocols

Dialogic 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 information

SCCP Programmer s Manual Version 1.0.2

SCCP 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 information

Routing Strategies. Fixed Routing. Fixed Flooding Random Adaptive

Routing 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 information

Understanding SROS Priority Queuing, Class-Based WFQ, and QoS Maps

Understanding 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 information

Contents. Configuring LLDP 2

Contents. 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&!

) /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 information

Teldat Router. Frame Relay

Teldat 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 information

Network Working Group. Category: Informational February 1997

Network 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 information

QOS Section 6. Weighted Random Early Detection (WRED)

QOS 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 information

Configuring Priority Flow Control

Configuring 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 information

Contents. Configuring LLDP 2

Contents. 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

Configuring Interfaces and Circuits

Configuring 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 information

Enabling Dual Chassis Fault Tolerance with Intel NetStructure SS7 Boards

Enabling 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 information

Application Note. Enabling Dual-Chassis Fault Tolerance with the Dialogic DSI SIGTRAN Stack

Application 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 information

Novell. NetWare 6. FILTER CONFIGURATION

Novell. 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 information

Wide Area Network Device Presence Protocol (WAN DPP)

Wide 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 information

x25 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. 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 information

INTERNATIONAL TELECOMMUNICATION UNION

INTERNATIONAL 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 information

Cisco 1000 Series Connected Grid Routers QoS Software Configuration Guide

Cisco 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