Project mission  Operation concept  Scope of applicability  Resource, capacity and reliability aspects

Back to Contents

Project mission

The mission of the 7-Scales project is to establish a simple to use and easy to extend base for development, testing and executing of SS7 scenarios. It is conceived as a kind of pool of active knowledge in the area of telecommunication processes that can be modeled by such scenarios. To be able to serve effectively such a mission, this Project supports two modes of operation - simulation mode to develop and tests scenarios, and network mode to execute scenarios against the network.

For the time being this mission is partially achieved for TCAP operations. That means MAP, INAP and CAMEL. ISUP is not developed although is it the easiest of all. The reason is that it makes sense to develop ISUP if there is a media gateway to carry out the voice processing. Therefore, the Code should be enabled to control some media gateways, which requires MGC protocol and some MGW control to be implemented. The author has no resources to undertake such a big additional work. There is a way out of this situation; further information can be found in the Roadmap section of this document.

Operation concept

Operation concept is a very complex area and will be dealt with throughout this and the other documents, starting here with the high-level overview.

There are three main lines that constitute this subject:

- Developing scenario base - messages that will be used to play the scenario and, optionally, adjusting definitions to enable the system to process those Information Elements (I.E.) that need runtime modifications.

- Developing scenario code - how these messages will be modified/send/received

- Running scenarios against the network

The figure below presents an integral view of the subject.

As with the Bible, everything starts with the Idea. You decide which operations shall be used and what parameters they shall have, how they shall be grouped into messages and exchanged between the Code and network elements. Once this is done, the necessary messages and code have to be prepared. It is hard to construct messages manually but there are many SS7 protocol analyzers that export recorded messages as hex numbers in text files. Once having chosen a message that almost satisfies you in terms of operations and parameters it contains, you can export it to a text file and feed the software tool dmtcap.exe, which is available under Windows XP and Linux. This tool produces two objects, proudly named "Operations bundle" and "Long context". The former contains the information needed to use this message in a scenario during runtime, the later is for control.

The Operations bundle needs some manual edition before it is ready for use; details are provided in the document "Creation of Message Templates and Operations Definitions".

After all messages that will be used in the scenario are ready, you arrive at the code development stage. First you need to integrate your scenario into the numbering scheme and supply some useful information regarding the scenario that will be written in the log during execution. Then you use a number of functions to program the behavior of the scenario, using the document "Application Program Interface Specification". Generally you can modify I.E.s in messages, you can add to or remove I.E.s from messages, and you can send and receive messages using a simplified version of M2PA protocol. Message structures and scenarios codes are stored in header files. A mechanism, based on conditional compilation in C-language, is provided to compile only those headers that are necessary for the scenario. This saves quite much time and a lot of torn hear.

Note: In this document the notion ´structure´ is used in a broader sense than the C-language definition of a structure mandates. Sometimes an object, implemented as an array is classified as a structure, if there are interrelations between the elements of the array. Example of such interrelation is when an element of the array is an index to another element of the array.

The Code as a Scenario Development Environment has two modes of execution i.e. it runs one or two processes (or units), named "Scenario Test Unit" (STU) and "Network Simulation Unit" (NSU). The former plays the scenario and the latter simulates the network. In simulation mode (i.e. when both processes are running), you can play the scenario on a single machine and analyze the message flow with the Wireshark protocol analyzer. This is the mode the author is using to develop scenarios. You can modify your code, compile and run again and again and again. When all the details are tuned and code seems to behave correctly, it can be run in a single process mode, i.e. STU against the Network. The change of modes is done by a command line parameter (X or x) and STU process never understands if it works against the NSU or against the Network.

The Code contains two example scenarios (one of them comes in three versions); they are supplied with many comments and can be used as templates for the two main cases: STU-initiated and NSU-initiated scenarios. Details are available later in this document in the section describing Code architecture and in the document "Application Program Interface Specification".

Note that simulation mode supposes that you develop both units for the scenario - STU and NSU. If you are good enough to prepare a scenario at a turn and don´t need simulation, or if you can play the scenario in a testbed, you can develop only STU code and that would save you half of the work. As can be seen in the Roadmap, it is envisioned to develop a few stand-alone NSUs that simulate different aspect of the network; the prerequisites for this are already cast in the base structures of this Project.

Development of a scenario may need to be accompanied by definitions of some operations if they are not already defined in the relevant header files of the Code. Leaving the details to the document "Creation of Message Templates and Operations Definitions", it is worth saying here that this activity is needed if you have to modify an I.E. in an Operation that is not yet defined. There are two software tools, Gentcl.exe and Gentco.exe that come to help. As with dmtcap.exe, they are also available under Linux and Windows. The final product of these tools is a ´static´ structure (also referred to as ´static context´) that describes a particular Operation. This representation is used to access an I.E. in the Operation with the purpose to modify or add or delete it. The static structure, therefore, is meant to be used in all scenarios and should include all I.E.s that Operation may have. In reality they are not that perfect; they are built from operations in messages taken from signaling records and expanded manually by the author based on Specs. Technically they are implemented as 2-dimentional integer arrays.

Note the difference between the output of dmtcap.exe and Gentcx.exe: the former produces structures that describe messages to be used in specific scenarios and may contain none, one or more operations, and the latter produces structures that always describe operations one by one, i.e. one structure for one operation, and are used in all scenarios. Message structures are stored in headers like mapv3_rne_op01.h or cs1pv0_ac0_op01.h (naming conventions are provided later in this document). Operations structures are stored in headers map_opdefs.h, cs1popdefs.h, cap_opdefs.h, etc. The figure below presents these relations in a graphical manner.

It should be noted also that message structures contain substructures that are partially compatible with the operation structures mentioned above, but dmtcap.exe and Gentcx.exe use different algorithms. They are named ´dynamic´ structures (also ´dynamic context´) and, as with the static structures, they are implemented technically as 2-dimentional integer arrays. Therefore, the structures produced in different ways can be compared and this provides a kind of validation of the data and algorithms being used. At the same time, dmtcap.exe uses the same algorithm that is used by the Code at runtime to decode incoming messages. This ensures that the messages at runtime are decoded correctly and have to be identical to the messages being prepared upfront (if no changes have been done at runtime). The overview of the self-controlling framework implemented in this Code is presented on the following figure figure.

Scope of applicability

The Code is designed with the horizon to operate all the SS7 Application Parts that step on TCAP. This exactly means MAP, INAP with the proprietary implementations of INAP, and CAMEL. From version 0.3.1 onwards, bases for MAP versions 1, 2 and 3, CAMEL Phases 1, 2, 3 and 4, and Ericsson INAP CS1+ are built in the Code. This means that the Application contexts, Operation codes and the relations between them are put into relevant headers, tcapbase.h, map_base.h, cap_base.h and cs1pbase.h respectively. For ITU-T INAP, if such species ever exists in the fields, nothing has been included in the design, except a named constant.

Very few operations and messages are supported so far (see the table below), the choice of which is driven by the author´s job obligations.

The Code is designed with the idea to support complicated trouble shooting cases, explore specific issues of SS7 implementation in the field that rise in service planning in the Core, for elaboration of knowledge, for some simple tasks in the network. The last, but quite ambitious implementation the author is planning to develop is to facilitate Voice quality evaluation in a specific, but quite sensitive business area.

Resource, capacity and reliability aspects

The minimum requirements for a scenario to be developed are as follows:

- A PC with Linux OS and user experience in Linux,

- Some C-language experience and an IDE,

- Wireshark protocol analyzer is a must,

- Solid base in SS7 Specs and their implementation in the particular network you are in.

The author uses CentOS 5.5 and Eclipse, and operates in Ericsson-dominated core network that descends from AXE mobile switching systems.

No tests have been made under other Linux OSs so far.

Additionally, if you intend to develop scenarios for proprietary IN protocols like Ericsson CS1+, you need a Protocol analyzer that is capable to decode them in full, as Wireshark does it partially. The author is completely content with his old K15 box from Tektronix.

For the execution of a scenario against the network, you need a Network Element that supports SCTP and M2PA towards the Code at one hand, and, say, narrow-band MTP3 towards the Network on the other. A Cisco ITP machine, for example, would do an excellent work. The Code is designed in a way that can be ported easily to M3UA; this is envisioned in the Roadmap. In fact everything in the Roadmap depends on whether this Project will attract any positive attention from the Telecom and IT society or not.

Apart from these tiresome conditions, some settings need to be done in the network to ensure that signaling messages will be transported at network layer (that is MPT3 and SCCP) to and from the right Network element(s) where the necessary functionality for the node that represent the Code is activated. Telecom people know well what to do in any particular case.

This Code is not designed for life services. No performance requirements have been pursued; moreover the v0.2 release skips some subtle but important actions that a System claming to be commercial should be able to do in the SS7 plane. By no means would these pitfalls deteriorate the performance of the Code in the scope of its applicability.

Apart from this, the Code runs well. It makes some limited use of the Heap and some simple rules should be observed to avoid crashing and hanging. Notes on the use of the Heap are provided in the API description; IT people know well what to do further on.