OpenSS7

Brian F. G. Bidulock,

© Copyright 2000, Brian F. G. Bidulock, All Rights Reserved.

All OpenSS7 website, www.openss7.org resources have provided as a courtesy of the OpenSwitch Project and Herlein Engineering.


Frequently Asked Questions

  1. Q: What is OpenSS7?
  2. Q: What is the purpose of an open SS7 stack?
  3. Q: What isn't OpenSS7?
  4. Q: What does OpenSS7 hope to do?
  5. Q: Where does the OpenSS7 project stand?
  6. Q: What is available for download?
  7. Q: Where is the source?
  8. Q: Are pre-compiled binary packages available for download?
  9. Q: How, or what, can I contribute?
  10. Q: What hardware is supported?
  11. Q: What are the system requirements for OpenSS7?
  12. Q: Do I need a hardware card for OpenSS7?
  13. Q: Where can I find more information on SS7?
  14. Q: Where can I find more information on SIGTRAN?
  15. Q: What are the licensing terms for OpenSS7?
  16. Q: Where do I report bugs and fixes?
  17. Q: What test tools are available for/with OpenSS7?
  18. Q: What if my question is not on this list?

What is OpenSS7?

OpenSS7 is an open-source implementation of the Signalling System Number 7 protocol stack as specified by ITU-T, ETSI, ANSI, and other standards bodies. It derives primarily from an implementation of the ITU-T Q.700-Series Recommendations on Signalling System No. 7. For more information on Signalling System Number 7, see ``Where can I find more information on SS7?''

OpenSS7 was a project I developed starting in about 1996 and which has hit a high level of interest currently with the advent of VoIP platforms and SoftSwitches. Contributed as part of the OpenSwitch project, and web-hosted by Herlein Engineering, this is the current, and actively developed, version of the OpenSS7 stack.

OpenSS7 was developed for the Linux kernel. It currently supports the 2.2.x series kernels. OpenSS7 includes some driver implementations for some popular Linux WAN cards, and some driver implementations are supported separately by the card vendor. For more information on which cards are supported, see ``What hardware is supported?''

What is the purpose of an open SS7 stack?

SS7 stacks normally cost money (and lots of it). Typically there are up front costs as well as ongoing run-time royalties. This places doing SS7 out of the reach of most consulting companies, research projects, or hobbies. One of the purposes of an open SS7 stack is making one available for these uses and to fill this gap.

Another reason is because of the power of the open-source movement. SS7 stacks are difficult to build, verify and maintain in conformance to the SS7 specifications and standards. This is a task best addressed in the open-source community, where corrections, bug-fixes, and general experience and intellectual capital can focus to deliver the best SS7 implementation ever.

Another reason is that no-one really cares about SS7 (or wants to care). What they care about is the application parts and applications which ride upon SS7. By making an SS7 stack implementation open, and leveraging the open-source movement, it is possible for most (if not all) users of the OpenSS7 stack to not really care what is happening inside of the package. This is not only a reason, but a lofty objective.

OpenSS7 owes its home to the OpenSwitch project and is also sponsored by Herlein Engineering in the hope that the OpenSS7 project will add SS7 capabilities to OpenSwitch . Nevertheless, the OpenSS7 stack is a stand-along component which can be used separately from the OpenSwitch code base.

What isn't OpenSS7?

OpenSS7 isn't ISUP, it isn't TCAP, and it isn't an application. Consider it similar to an IP stack with TCP and UDP. You can open an MTP or SCCP socket and communicate to the outside world using SS7, but what you might want to do with that socket is a matter for the application. There are a number of open-source projects which are concerned with the application level using SS7. One of these is our sponsor, Herlein Engineering 's OpenSwitch project.

What does OpenSS7 hope to do?

OpenSS7 hopes to be the most readily available, most used, most robust UN*X implementation of the SS7 protocol stack at Levels 2 through 4.

Where does the OpenSS7 project stand?

The OpenSS7 project is in pre-release pre-alpha stage. What that really means is that we are still working on the code and it is really not suitable for public release. What we have done is made the source code available for those that are interested in following the pre-release development or in pushing the envelope on our development.

Load this code and mess with it at your own peril. Currently the code is likely to crash your machine and cause you to have to reboot. You may irreparably damage your header files and be unable to recompile your kernel. You may have to reload your system. There is no warranty.

We hope to have an alpha release of the stack which is suitable for public consumption around November 2000 (yes, that quickly). If you are interested in becoming a pre-alpha tester and help us stabilize the alpha release, please drop me a note at bidulock@openswitch.org and let me know your intentions.

What is available for download?

Check the downloads page. What is generally available for download is the ``original'' ACB56 character device driver and documentation, the SS7 Link Interface module, an ACB56 network driver, and the MTP and SCCP socket code and MTP state machines: all as loadable kernel modules for the Linux 2.2.x kernel. You can also view online or download a lot of the project and code documentation.

Where is the source?

Go to the downloads page. The source is there... ...really.

Are pre-compiled binary packages available for download?

Not yet. Sorry. Because most of our code is in pre-alpha release phase, we have not build pre-compiled binaries or RedHat RPMs yet. But we will. Just give us a little while to reach the first stable baseline on the code and we will release in binary package form. Check the downloads page for updates to what is going on with releases.

How, or what, can I contribute?

If you would like to contribute to OpenSS7, you can do so in a number of ways:

Participate on the mailing list.
Discussion, peer-review, and shared experiences and best practices are one of the best ways to contribute to the project.
Write driver(s).
It's really not that hard, and your experience with a specific hardware card could be valuable in the development of an OpenSS7 driver.
Give money.
If you have excess funds available and just want to throw a little money our way, you can contact me for my mailing address. (Just kidding.)
Test Code or SS7 Conformance.
We are always looking or people to test and verify proper operation of the SS7 state machines and the stack in general. You could do this testing if you have an understanding of conformance testing of SS7 implementations.
Equipment and resources.
If you are a vendor, you can always contribute boards and specifications and we will be interested in them for driver development. Test equipment is always appreciated.
Use the code and contribute improvements.
Improvements can be in the way of bug-fixes, enhancements, drivers, corrections, suggestions. Sometimes the only way to improve a design is to consider the applications which are using it. Please contribute your application success (an, err... failure) stories to the mailing list.
Join the developers.
If you like coding Linux kernel module code... let us know!

What hardware is supported?

Following are some links to card vendors and their cards. All of these vendors provide Linux or xxxBSD WAN drivers on some, if not all, of their cards. These cards are up for consideration for SS7 drivers. This list may not be updated too often, so contact the mailing list or check the downloads page for more information on card support. If you don't see your card here or are interested when a card will be supported, contact the list, or write it yourself! (It's not that hard.)

Table of Proposed Supported Hardware for OpenSS7 Project
Vendor Cards Bus I/F Ports OpenSS7
Comtrol Corporation Hostess i/S2 ISA V.35 2 -
Institute of Computer Science,
Masaryk University
COSA ISA8 V.35 2 -
Information Technology, Inc. LoCOMX ISA V.35 1 -
HiCOMX 2
SliceCOM PCI E1 31
LAN Media Corporation (LMC) LMC1000P PCI V.35 1 -
LMC1501/2/4 cPCI T1c 24/48/96
PMC
Sealevel Systems Incorporated ACB 56 ISA8 V.35 1 yes
ACB V ISA8 2 -
Route 56 ISA
PCI
Microgate Corporation SyncLink ISA V.35   -
PCI
Sangoma S5141 PCI V.35 1 -
S5142 2
S514/T1 T1c 24
Emerging Technologies, Inc. ET/5025 ISA8 V.35 1 -
ET/5025-16 ISA16 2
ET/5025PQ PCI 4
ET/PCISYNC
SBS Technologies, Inc. RISCom/N2 ISA V.35 2 -
ARIES 604 cPCI 4
ARIES 608 8
ARIES 654 T1/E1c 96/128
ARIES 658
ARIES 680 384
ARIES 521 V.35 1
ARIES 522 2
ARIES 524 4
ARIES 500 1
ARIES 505 2
WANic 400 PCI 1 or 2
WANic 500
WANic 520 1, 2 or 4
WANic 600 4 or 8

Note: Some of the information in the above table may be incorrect or inconsistent with the vendor's actual offerings. Please consult with the individual vendor before making any decisions. Also note that this table does not constitute an endorsement of anyone's product. The authors of the OpenSS7 project will not take responsibility in it.

What are the system requirements?

Well, at current you need a Linux system running a 2.2.13+ kernel and a C compiler (preferably gcc) capable of compiling the Linux kernel. You must have an appropriate set of kernel module tools available. What hardware do you need? Well, just about any hardware will do depending on which SS7 link interface cards you are running. If you are running the ACB56 or similar ISA card, you will be limited on the number of signalling links that you have on your box by the ISA IRQ and DMA restrictions. If you are not running an SS7 link interface card which supports full duplex DMA, the processor will be more heavily loaded and the number of links that you can support will be diminished. Normally, the cards which provide a large number of links also support the full duplex DMA or PCI DMA necessary to support their data rates quite nicely (SS7 uses slowwwww 56/64 kbps when many of these cards were designed for 1 Mbps+ operation).

If you want to take advantage of the reliability characteristics of the stack, you will need cPCI or similar cards which can be hot-swapped, or you need to be running multiple boxes.

Do I need a hardware card for OpenSS7?

Well, no. One of the objectives of providing the SIGTRAN and related protocols (see Where can I find more information on SIGTRAN? ) was to permit SS7 MTP and SCCP to be run on a Linux box which did not have any physical SS7 links attached to it. So, you do not need one of the SS7 link interface cards listed (see What hardware is supported?). All that you need is a Network Interface Card (NIC) capable of doing IP and you are in business: multiple SS7 nodes can be set up to communicate with each other using IP.

Where can I find more information on SS7?

Note: Some of the information concerning the reference sources and lists of books in this section may be incomplete, incorrect, out of date, or inconsistent with a publisher or document broker's actual offerings. Please consult with your book or document dealer before making any decisions. Also note that lists in this section do not constitute an endorsement of any document source, book, product, or service. The authors of OpenSS7, their sponsors, agents and representatives will not take responsibility in it.

Rather than working directly for the specifications documents (most of which one must pay money for a copy), there are a number of good books publishes which provide the details of the operation of the SS7 protocol:

(I personally do not own any of these books. Possibly because I could have written them. However, I have seen copies of the books and have coworkers and friends who swear by them.)

Many of the specifications are available only at a significant (significant to open-source developers) charge. For example, the last price I saw on ANSI T1.111 (MTP) was $364 USD; ANSI T1.112 (SCCP) was $287 USD. Perhaps we can convince someone to donate copies of these specifications for use by the project. For information on the specifications for variants of the ITU-T SS7 protocol, the following links may be helpful:

International Telecommunications Union - Telecommunications Sector

Specifications of the SS7 protocol are provided at the international level by the International Telecommunications Union - Telephony Sector (ITU-T) in their Q.700 series recommendations. Many of the implementors guides and documents are publicly available without charge off of the ITU website, however, the ITU does charge for most of the primary specifications documents in the Q.700 series, and, therefore, you will not find them available on the OpenSS7 website.

Table of ITU-T Q.700 Series Recommendations
Document
Number
Description
Rec. Q.700 Introduction to CCITT Signalling System No. 7
Rec. Q.701 Functional description of the message transfer part (MTP) of Signalling System No. 7
Rec. Q.702 Signalling data link
Rec. Q.703 Signalling link
Rec. Q.704 Signalling network functions and messages
Rec. Q.705 Signalling network structure
Rec. Q.706 Message transfer part signalling performance
Rec. Q.707 Testing and maintenance
Rec. Q.708 Assignment procedures for international signalling point codes
Rec. Q.709 Hypothetical signalling reference connection
Rec. Q.710 Simplified MTP for small systems
Rec. Q.711 Functional description of the Signalling Connection Control Part
Rec. Q.712 Definition and function of signalling connection control part messages
Rec. Q.713 Signalling connection control part formats and codes
Rec. Q.714 Signalling connection control part procedures
Rec. Q.715 Signalling connection control part user guide
Rec. Q.716 Signalling connection control part performance

Of course, the ITU-T provides recommendations, specifications and standards for a large number of protocols including ISUP, TCAP, AIN, GSM, MAP, etc., which will be of interest to applications developer using OpenSS7, but only the MTP and SCCP portions of the specification directly impact the OpenSS7 stack and are the only recommendations listed above.

European Telecommunications Standards Institute (ETSI)

ETSI documents are individually downloadable, free of charge, however, free of charge does not mean that I can post copies here for you. You will have to go register with ETSI and get your own documents from the ETSI Publications Download Area. Most ETSI documents at this level are really just modifications of the ITU-T documents and only contain changes from the ITU-T documents, rather than the complete text of the specification. It is very difficult to work with these modification documents without the original ITU-T Q.700 series recommendations to which the modifications apply.

Table of ETSI Technical Specification Documents
Document
Number
Description
ETSI ETS 300 008-1 Signalling System No. 7;
Message Transfer Part (MTP) to support international interconnection;
Part 1: Protocol specification [ITU-T Recommendations Q.701, Q.702, Q.703, Q.704, Q.705, Q.706, Q.707 and Q.708 modified]
ETSI ETS 300 008-2 Signalling System No. 7;
Message Transfer Part (MTP) to support international interconnection;
Part 2: Protocol Implementation Conformance Statement (PICS) proforma specification
ETSI ETS 300 336 Signalling System No. 7;
Message Transfer Part (MTP);
Test specifications [ITU-T Recommendations Q.781 and Q.782 (1993), modified]
ETSI ETS 300 346 Signalling System No. 7;
Message Transfer Part (MTP) protocol Tester (MT)
ETSI ETS 300 009-1 Signalling System No. 7;
Signalling Connection Control Part (SCCP)
(connectionless and connection-oriented) to support international interconnection;
Part 1: Protocol specification [ITU-T Recommendations Q.711 to Q.716 (1996), modified]
ETSI ETS 300 009-2 Signalling System No. 7;
Signalling Connection Control Part (SCCP)
(connectionless and connection-oriented class 2) to support international interconnection;
Part 2: Protocol Implementation Conformance Statement (PICS) proforma specification
ETSI ETS 300 009-3 Signalling System No. 7;
Signalling Connection Control Part (SCCP)
(connectionless and connection-oriented class 2) to support international interconnection;
Part 3: Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification
ETSI ETS 301 008 Signalling System No. 7;
Signalling Connection Control Part (SCCP)
Interoperability test specification

ETSI has a great number of technical specifications and standards on their website available for download. Many of these specifications have to do with ISUP, TCAP, AIN, GSM, MAP, etc., and are of interest to the OpenSS7 application developer. Because they do not directly relate to SS7 MTP or SCCP, they are not listed here.

American Telecommunications Standards Institute (ANSI)

ANSI provides the standards specifications for the MTP and SCCP portions of the SS7 protocol for most of North America. Telcordia (formerly Bellcore) documents are based heavily on the ANSI documents. The ANSI documents themselves are based heavily upon the ITU-T documents. One source for ANSI documents is Global Engineering Documents . Some popular ANSI SS7 documents are as follows. Most of these documents carry a pretty hefty price tag (several hundred US dollars each). They are not made publicly available without charge.

Table of ANSI T1.11x Specifications
Document
Number
Description
ANSI T1.110

Signalling System Number 7 (SS7) -
General Information

ANSI T1.111

Signalling System Number 7 (SS7) -
Message Transfer Part (MTP)

ANSI T1.112

Signalling System Number 7 (SS7) -
Signalling Connection Control Part (SCCP)

ANSI T1.113

Signalling System Number 7 (SS7) -
Integrated Services Digital Network (ISDN) User Part

ANSI T1.114

Signalling System Number 7 (SS7) -
Transaction Capability Application Part (TCAP)

ANSI T1.116

Signalling System Number 7 (SS7) -
Operations, Maintenance and Administration Part (OMAP)

Telcordia (formerly Bellcore)

Telcordia (formerly Bellcore, or Bell Communications Research) was the standization and engineering powerhouse of the RBOCs. Telcordia still fills much of their old role in providing standardization documentation and generic requirements documents for telecommunications carriers in the US. The Telcordia SS7 documentation at the MTP and SCCP level provide for both specification of the protocol as well as conformance tests. Telcordia documents on SS7 are not made freely available, they are publicly available at a fee. Telcordia documents are available from their website. Some of the documents and titles that you may be interested in are as follows:

Table of Telcordia Generic Requirements Documents
Document
Number
Description
GR-82-CORE Signaling Transfer Point (STP) Generic Requirements
GR-246-CORE Telcordia Technologies
Specification of Signaling System Number 7
GR-905-CORE Common Channel Signaling Network Interface Specification (CCSNIS)
Supporting Network Interconnection,
Message Transfer Part (MTP) and ISDN User Part (ISUP)
GR-1272-CORE Gateway Signaling Transfer Point (GSTP) Local Message
Screening Test Capability Generic Requirements
GR-1432-CORE Common Channel Signaling Network Interface Specification (CCSNIS)
Supporting SCCP and TCAP
GR-2878-CORE Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links (HSLS)
GR-3012-CORE Generic Requirements for Network Interconnection Signaling System No. 7 (SS7) Link Monitoring System (LMS) Automatic Message Accounting (AMA)
GR-3053-CORE Voice over Packet (VoP): Next Generation Network (NGN) Signaling Generic Requirements

Telcordia has other specifications relating to ISUP, TCAP, AIN, MAP, etc. which are at the application level and which are not of direct interest to the OpenSS7 project. OpenSS7 applications will be interested in some of these documents. Please see the Telcordia website for more information.

Where can I find more information on SIGTRAN?

SIGTRAN is a working group of the Internet Engineering Task Force (IETF). It provides protocols for the transport of signalling information over IP. In particular, the OpenSS7 project supports (or plans to support) the following SIGTRAN protocols:

SCTP
This is the common transport protocol which is used by many of the other adaptation layers for SS7. It is a multiple stream-based protocol similar to multiple streams of TCP and provide reliable transport of data ``chunks'' between two IP hosts. Although SCTP can run over UDP, it has been specified to run directly over IP. OpenSS7 does not provide its own implementation of SCTP, but relies upon other Linux kernel implementations of SCTP.
M2PEER
This is an SS7 MTP Level 2 peer-to-peer protocol for simulating an SS7 link using SCTP/IP. The specification for M2PEER is embodied in the Internet Draft draft-george-sigtran-m2peer-02.txt which is available from the IETF ftp site. OpenSS7 provides (or, intends to provide) a virtual device driver module for an M2PEER SS7 link which acts similar to a real hardware device driver.
M2UA
This is an SS7 MTP Level 2 protocol at the L2 SAPI for and ASP controlling SS7 links at a distance from a signalling gateway (SG) over SCTP/IP. The specification for M2UA is embodied in the Internet Draft draft-ietf-sigtran-m2ua-04.txt which is available from the IETF ftp site. OpenSS7 provides (or, intends to provide) a virtual device driver module for an M2UA SS7 link which acts similarly to a real hardware device driver with the OpenSS7 stack acting as an ASP (user) of the M2UA link. OpenSS7 provides (or, intends to provide) the ability to access SS7 links using the M2UA protocol indirectly through the use of the Linux PACKET_SOCKET to directly access the SS7 Link device driver.
M3PEER
This is an SS7 MTP Level 3 peer-to-peer protocol for simulating an SS7 signalling routeset using SCTP/IP. OpenSS7 provides a virtual routeset module for an M3PEER SS7 routeset which acts similarly to an internal routeset within the MTP L3 stack.
M3UA
This is an SS7 MTP Level 3 protocol at the L3 SAPI (MTP to MTP-User) for an ASP providing MTP-User applications at a distance from a signalling gateway (SG) over SCTP/IP. The specification for M3UA is embodied in the Internet Draft draft-ietf-sigtran-m3ua-03.txt which is available from the IETF ftp site. OpenSS7 provides (or, intends to provide) a virtual user part for an M3UA connection
SUA
This is an SS7 SCCP Level 4 protocol at the L4 (SCCP) SAPI (SSCP to SCCP-User) for an ASP providing SCCP-Subsystem applications at a distance from a signalling gateway (SG) over SCTP/IP. The specification for SUA is embodied in the Internet Draft draft-ietf-sigtran-sua-01.txt which is available from the IETF ftp site.
TALI
TALI provides either an MTP Level 3 protocol at the L3 SAPI (MTP to MTP-user) for a Level 4 protocol at the L4 (SCCP) SAPI (SCCP to SCCP-User) for an ASP providing MTP-User or SCCP-Subsystem applications at a distance from a signalling gateway (SG) over TCP/IP. The specification for TALI is embodied in the Internet Draft draft-benedyk-sigtran-tali-01.txt which is available from the IETF ftp site.
IPlink
IPlink provides MTP Level 2 over TCP/IP rather than a physical SS7 link interface. OpenSS7 supports an SS7 link virtual device which provides IPlink capabilities. The specification for IPlink is embodied in the Internet Draft draft-bressler-sigtran-ipss7l2-00.txt which is available from the IETF ftp site.

What are the licensing terms for OpenSS7?

The OpenSS7 stack is licensed under the terms of the GNU General Public License Version 2. However, the copyright holder (author) reserves all rights. This means that if you are interested in licensing terms which are different from the GPL Version 2 license, you are free to discuss this with the copyright holders on the original works. Modifications to the OpenSS7 stack are licensed under the GNU General Public License Version 2 by nature of the GPL licensing of the primary work. For other licensing terms on modifications to the OpenSS7 stack, please contact the respective copyright holders.

Nothing in the GPL Version 2 licensing of the OpenSS7 stack should be construed as a restriction on its use by commercial applications. Just because the OpenSS7 stack is GPL'ed does not mean that applications which use the OpenSS7 stack are necessarily open-source or freely available to the public.

Where do I report bugs and fixes?

Bugs and fixes can be reported to the OpenSS7 mailing list: openss7@openswitch.com or directly to me at bidulock@openswitch.org.

What test tools are available for/with OpenSS7?

OpenSS7 has no test tools of its own for testing SS7. Test tools for SS7 can be found from any of the popular SS7 protocol test companies such as the Inet SPECTRA. (A web search will help you out here.)

There are a number of tools built into the Linux NET4 code which will help you to test an OpenSS7 stack implementation. One of these is the PACKET_SOCKET which is also supported by the OpenSS7 stack. See `man 7 packet'. The procfs and sysctrl support of the OpenSS7 stack permits statistics to be used to assist in debugging the OpenSS7 stack and interfaces.

The popular Ethereal package can be used with M3UA, M2UA, M2PEER and custom extensions to debug non-physical SS7 link interface drivers and debug the OpenSS7 L2 and L3 state machine implementations without a real interface. Some tools will eventually be written to run Q.781 and Q.782 conformance tests against virtual SS7 links using the M3UA, M2PEER and M2UA protocols. Stay tuned.

What if my question is not on this list?

Hit the mailing list at openss7@openswitch.org or ask me ( bidulock@openswitch.org ).


OpenSS7

Brian F. G. Bidulock,

© Copyright 2000, Brian F. G. Bidulock, All Rights Reserved.

Last modified: $Date: 2000/10/04 03:52:24 $