ProductsServicesApplicationsPrices
SpecificationsDocumentationContactHome Page
This page presents a functional overview of Jade's TNSM. The TNSM Input Reference Manual describes in detail all the input data sets for TNSM. The TNSM Output Reference Manual describes in detail the simulation data that is collected and the statistics that are reported.



TELECOM NETWORK SIMULATION MODEL
(TNSM)
FUNCTIONAL OVERVIEW


Jade's TNSM product accurately simulates the public switched telephone network (PSTN) and the associated SS7 signaling network. The Trunk Network Model (TNM) is a call-level simulation of the PSTN capable of modeling a large variety of network architectures, routing strategies, and traffic types. The SS7 Model is a message-level simulation of the SS7 protocol and network elements.

TNSM requires no software development in order to model networks. It is completely data-driven, allowing the engineer to work with well understood concepts such as network architectures, switch architectures, traffic, and routing. Figure 1 illustrates the data-driven representation of a network and the following sections describe model functionality. Further details related to the input and output data associated with the models can be found in the TNSM Input Reference Manual and Output Reference Manual.


Figure 1: Data-driven Network Representation

Figure 1: Data-driven Network Representation

1. SS7 Model Functionality

The SS7 Model design conforms to both the ANSI and ITU specifications, and has been enhanced with many of the Bellcore specification upgrades. The model is designed to be hardware vendor independent. A generic switch model is customized through an extensive set of protocol and performance parameters in order to model specific vendor switches. Because the design is modular and object oriented, the models are extensible.
The SS7 Model accurately simulates the SS7 protocol because it models all of the major layers of the protocol. Figure 2 illustrates the SS7 protocol layers and how they match the generic OSI protocol stack.


Figure 2 - SS7 Protocol Layers
Figure 2 - SS7 Protocol Layers

Functional components exist in the model for each of the layers. When connected together, these components represent signaling elements in the network. Figure 3 below illustrates the functional components of the SS7 Model.
Any signaling point element can be modeled by including the required functional components. Not only can the standard elements such as SSPs, STP, and SCPs be modeled, but any hybrid node (e.g., STP with SCP capabilities) can also be modeled. Figure 4 illustrates the functional components required to model the standard signaling elements.


Figure 3 - SS7 Model Functional Components
Figure 3 - SS7 Model Functional Components


Figure 4 - Standard SS7 Signaling Elements
Figure 4 - Standard SS7 Signaling Elements

Physical Link and Link Processor Layer Functionality

The physical link model simulates a bi-directional link with a fixed speed and propagation delay. These parameters are user controlled, allowing different link speeds to be modeled.

The link processor layer models both the Basic Error Correction (BEC), and Preventive Cyclic Re-transmission (PCR) protocols. This includes modeling of transmission and re-transmission buffers. Associated with buffer modeling, the link processor layer models congestion thresholds and indications. Onset, abatement, and discard thresholds for all 3 congestion levels are user controlled and can be defined using octet or MSU values.

Physical link and link processor failure and recovery can be modeled. Conditions of the failure, including failure detection delays, can be set differently at each end of the link, allowing various link failure conditions to be modeled. Bit error rates on a link can also be dynamically adjusted, allowing bursty link error conditions to be modeled.

The link model supports 5 and 8 bit SLS codes, including modified code rotation capabilities. 5 and 8 bit code support is defined on a per-node basis, which supports inter-mixing of SLS code sizes within a single network model. SLS code re-balancing in the face of link failures is modeled using either optimal routeset, or non-optimal linkset re-balancing.

Network Layer Functionality

The network layer models all of the MSU handling functionality as well as all of the network management procedures. MSU handling functions include: Routing table definition is user controlled, allowing for any standard or non-standard routing discipline to be modeled. Multiple routing levels are supported, allowing for primary, secondary, tertiary, and higher level routes.
All of the major traffic management functions are modeled, including: All of the route management functions are also modeled, including: All network layer management messages associated with these functions are modeled. Broadcast procedures support full broadcast gapping capabilities. MSU buffering and protocol timers associated with the various management functions are also modeled.

SCCP Layer Functionality

The SCCP layer supports all of the SCCP routing functions. Virtual pairs are supported at STPs for Global Title Translation (GTT), and at SCPs for database access. Virtual pair routing supports load sharing as well as primary/backup strategies. GTT is fully supported, including multiple translation points and Alias Point (AP) codes. All routing and point code status tracking is modeled to ensure consistency between SCCP and Network layer routing.

The full suite of SCCP subsystem management functions are also supported, including: All SCCP management messages, and protocol timers associated with these procedures are modeled.

Database Layer Functionality

Multiple physical database subsystems can be modeled at any signaling point. As described above, the SCCP layer maintains full status information related to the database subsystems. The physical database is modeled as a query/response mechanism supporting multiple query servers capable of handling multiple query types. Figure 5 illustrates the physical database model. Database failures and recoveries, as well as capacity reductions are supported in the model.


Figure 5 - Database Query Mechanism

Figure 5 - Database Query Mechanism

Traffic Generation

The SS7 Model supports 3 types of traffic generation as defined below:

1) User Part Traffic: This traffic is generated into the Network Layer or Message Transfer Part (MTP) of the protocol. Message class definition includes message sizes and priorities. Traffic is generated on a point-to-point basis using a negative exponential distribution.

2) TCAP Traffic: This traffic is generated in the SCCP layer as TCAP database queries, with automatic responses being generated by the database upon processing of the query. User defined database query/response classes include query and response sizes, priority, and return-on-error conditions. Traffic is generated on a point-to-DB basis, where the DB can be either a physical or virtual database. GTT points can also be defined for this traffic type. A negative exponential distribution is used for traffic generation.

3) TNM Traffic: This traffic is generated out of the TNM as part of call setup and tear-down. Both ISUP and TCAP traffic can be generated depending on the call class being modeled. See the next section for additional details on this traffic type.

2. TNM Functionality

The TNM is a logical model of the public switched telephone network. Components of the model include switches (both end-offices and tandems), trunk groups, and network processors for DCR style dynamic routing. The TNM is a call-by-call simulation where calls are modeled from setup, through the duration of the call, to tear-down. The TNM can run stand-alone or fully integrated with the SS7 Model, where ISUP and TCAP messages are used to perform call setup and tear-down. The TNM can also model Advanced Intelligent Network (AIN) type services. AIN capabilities are described in Section 3.

Switch Model

Like the SS7 Model, the TNM utilizes a modular component approach to providing model functionality. The various components of the TNM are illustrated in Figure 6.


Figure 6 - TNM Functional Components
Figure 6 - TNM Functional Components

The layers include:


The TNM does not model any specific vendor switch architecture, but simulates switch capacity using a generic multi-server model. Functional components of the TNM can be defined with multiple servers capable of processing calls. Processing times for various functions can also be defined (for example the RL has service times for call setup and call tear-down). The server model is similar to the one illustrated for database queries in Figure 5.

Traffic Generation

Call traffic in the TNM is defined on a point-to-point basis with multiple call classes. Each call class represents a different service type and has a set of parameters for characterizing the service. Given call volumes and holding times, the model randomly generates calls using a negative exponential distribution. A re-dial percentage can be defined for automatically re-dialing calls that block during the setup process.

Routing

Various levels of routing are supported in the model. At the RL, fixed, fixed alternate (fixed hierarchical), and dynamic routing are supported for intra-network routing. Routing tables are defined on a call class basis which supports different routing strategies for different services. The available routing strategies can be enabled or disabled on a per-switch basis. The TNM currently supports DCR style dynamic routing where a central NP monitors trunk group capacity and makes dynamic alternate routing recommendations to the switches on a periodic basis.

Inter-network routing through logical gateways is also supported. Switches can be grouped together to form virtual gateway nodes through which calls can be routed. User-defined hunt strategies can be defined on a call-class basis where multiple routing attempts through the gateway can be modeled.

The TNM also supports AIN routing which is discussed in Section 3.

Trunking

Two types of connectivity can be modeled in the TNM. Conventional trunking is simulated using a logical trunk group model. Two and one-way trunk groups of any size can be defined between switches. When modeling trunking, the RL must seize trunks before a call can be setup. If trunks are not available, an alternate route must be tried, or the call must be blocked.

Where detailed trunk modeling is not required, Virtual Trunking (VT) can be utilized. VT involves defining TNM connectivity using a stochastic approach where the probability of routing a call between two adjacent nodes is defined. When attempting to route a call, the RL will perform a random draw to determine if the call can be setup. If it cannot, the call must take an alternate route, or be blocked. VT can also mimic dynamic routing by randomly selecting a dynamic alternate route from the set of available adjacent nodes that connect the origin to the destination.

Integration With SS7

The TNM is fully integrated with the SS7 Model. Call setup and tear-down is handled by the ISUP layer where detailed ISUP message sequencing is modeled. Figure 7 illustrates the set of ISUP messages associated with a normal call setup through a tandem. TNM can operate completely stand-alone (SS7 not used at all for call setup), full SS7 (SS7 used for call setup), or it can use a mixture of SS7 and non-SS7 switch models where interworking of SS7 and non-SS7 capable switches is simulated.

Figure 7 - ISUP Call Setup
Figure 7 - ISUP Call Setup

Events

The TNM supports a number of events that can be used to model abnormal conditions in the network. These include:

3. AIN Functionality

AIN modeling capabilities have been added to the TNM in order to model advanced services. The AIN capabilities in the model are generic in the sense that they do not model any particular subset of AIN services, but provide basic AIN functionality that can be used to model any IN or AIN service. Intelligent Peripheral (IP) network components are added to the model in order to support services that require interaction with IPs. The basic call class characteristics provided in the TNM are augmented with additional parameters that characterize call setup parameters for SCP and IP interactions.

Call Processing

A simplified point-in-call (PIC) processing model is used. This model, which is illustrated in Figure 8, includes the PICs discussed below.

Figure 8 - AIN PICs
Figure 8 - AIN PICs

1) Authorize (Origin): This PIC allows the SSP to interact with a SCP or Adjunct in order to authorize the particular service associated with the call.

2) Collect Information: This PIC allows the SSP to interact with a SCP or Adjunct and an IP to collect additional information required to proceed with the call.

3) Analyze Information: This PIC allows the SSP to analyze collected information and make a routing decision. If routing fails, this PIC can be revisited in order to make a new routing decision. The SSP may interact with a SCP or Adjunct each time it enters this PIC.

4) Route: This PIC allows the SSP to attempt to route the call. If the call is not routed successfully (e.g., block, busy, or unanswered), call processing may return to the Analyze Information PIC.

5) Authorize (Dest): This PIC allows the destination SSP to interact with a SCP or Adjunct to authorize the particular service associated with the call.

For complex services that require a more advanced call model, call class transitioning can be used to model a non-sequential flow through the PICs.

SCPs

AIN call processing allows SSPs to communicate with SCPs at any PIC. User-defined TCAP queries are sent using the same mechanism defined for generic SS7 TCAP traffic. Query types, and time-out values are defined for each PIC in the call that requires SCP interaction.

Call Routing

The AIN model augments existing TNM routing with two additional routing concepts. Via-point routing allows calls to be setup to a particular service point for AIN processing. This supports modeling of networks where only select switches have full AIN capabilities.

The AIN model also supports multiple call routing attempts for blocked, unanswered, and busy calls. This supports modeling of services such as "find-me" type services. Alternate call destinations can be defined for additional AIN routing attempts.

IPs

The AIN model fully supports IP interactions during call setup. IPs can communicate with SCPs either directly over dedicated links or through the connecting SSP and the SS7 network using FACILITY messages.

The IP model does not simulate any vendor specific IP architecture, but is a generic model that allows for the definition on any number of resources, and servers for processing setup requests. Figure 9 illustrates the generic IP model.

Figure 9 - IP Resource Model
Figure 9 - IP Resource Model

Events exist that support modeling of abnormal conditions at IPs. These include:




Products | Services | Applications | Prices | Specifications | Documentation | Contact | Home


Last update January 28, 1997