SS7 sounds a lot like history to many but it remains key to a host of services, particularly when it comes to inter-operator roaming. In fact, most operators continue to rely on it. So, validating and assuring SS7-based services, as well as those that call upon SS7 capabilities during their execution remains essential.

SS7 – a long history

SS7 – or Signalling System Number 7, to give it its full title – has been around for longer than most of us have been in the industry. Originally introduced back in the 1970s, SS7 remains in widespread use – although it has evolved significantly over the years.

Without going too much into the history, SS7 was introduced as an enhanced Common Channel Signalling (CCS) protocol for the (then new) digital exchanges and was key to the transition towards digital switching that took place in the 1980s. Why was it so important? Well, earlier forms of managing telephony connections had relied on what’s known as “in-band” (or, Channel Associated Signalling: CAS).

For any telephony session, there is both signalling information as well as the information to be conveyed between the endpoints that should be connected. Today, we understand this as control and user plane information, but before the advent of CCS systems, the two were combined and used the same channel (remember, we’re talking pre-IP here – pre-digital, even). So, with a CAS system, the user information (at the time, mostly voice) was sent via the same physical path as the information required to route it (the originating number, terminating number, and so on) and to charge for the call.

That’s pretty inefficient – particularly since the state of the terminating device cannot be known before an attempt to reach it is made. So, calls could be placed to numbers that were already engaged. As international and long-distance traffic grew, this became highly inefficient (and costly) as, say, a call might be placed from Stockholm to a number in New York, but you couldn’t know in advance whether that number was busy and occupied with another call, perhaps to a local number in New York.

Meanwhile, all that valuable transatlantic capacity was occupied – at cost to all carriers concerned. If you’ve ever wondered why people ask whether lines can be reserved for the President to talk to someone in films from the 1960s, that’s why – to avoid the possibility that another call could take up the required capacity.

Common channel signalling

CCS sought to change this by separating the information about the call from the contents (the first step towards our now-familiar control and user plane separation). This would allow a signalling request (to the number in New York) to be made to determine the state of the called party before the actual call was nailed down with an appropriate connection. So, if the called party was busy, the control systems could simply indicate this to the calling party, who would then hang up.

SS7 brought enhancements to this basic logic by enabling a single control channel to have responsibility for thousands of physical connectivity channels. So, a transatlantic route might have 4000 or so physical circuits and a couple of control channels (for redundancy). SS7 became the dominant carrier for international and long-distance calls, with devices connected to local exchanges.

We’ll stop with the history in just a moment, but this separation also enabled some other cool things, which contributed to the subsequent evolution of SS7 – and the reason why there’s so much of it still around today.

If you can do things before you actually tie down a connection, you can also make other kinds of requests. Not only can you check to see if a number is available, but you can also request other kinds of information, provided you can convey and transfer that information in a recognisable format that can be decoded by the switches and control entities in the network.

SS7 as the control plane interface

This recognition led SS7 to be expanded from a protocol that handled mostly telephone calls, to one that could also be used to translate one number to another (this number has been dialled; to what number in the geographical domain does it map?); send discrete packages of encoded text (AKA SMS message); request location information (in what network is this mobile phone and to which cell is it attached?); enable new charging models (like prepaid – remember what a game-changer that was); as well as to provide the foundation of a range of databases (storing numbers, identities, devices, etc) that could, in turn, be interrogated using specialised SS7 messages.

All of which was pretty good stuff – and so SS7 became key to the mobile revolution, as well as the foundation of fixed networks. The transition to IP didn’t really change this entirely, as, while SIP became the dominant IP-native control plane signalling method, SS7 also continued in these updated networks. That was achieved by replacing circuit-switched transport for IP, so the important layers of SS7 continued to do their thing, just over an IP-transport framework.

Today, SS7 protocol layers like TCAP, CAP (CAMEL), MAP, INAP and ISUP continue to be widely used. Perhaps ISUP is fading, as the move to all-IP IMS networks continues (a move in play for more than a decade, but let’s keep a sense of perspective here – the transition from analogue to digital also took decades), but today’s mobile networks still rely on SS7, particularly for handling roaming traffic, and specialised services based on CAP / INAP remain essential.

So, SS7 has a long history – and is set to be around, in one way or another for a while. Along the way, we’ve had many other innovations in the control plane – including the launch of Diameter a few years back. Diameter was seen by some as a replacement for SS7 and it’s true that it occupies similar ground, particularly in relation to database access and information retrieval, but it really came from as an evolution of earlier AAA protocols. Still, where there’s Diameter, there’s likely also SS7.

Assuring SS7 in a mixed protocol and interface landscape

Today’s 5G core uses HTTP as a means of exchanging information and requesting services from different SBA entities. As a result, most operators have a mix of legacy SS7, diameter and, if they have moved to 5G SA, there’ll probably be REST-based HTTP – added to which, there’s also likely to be SIP and possible ISUP for session control in some domains.

The upshot of this multi-protocol world is a complex mix at the control plane, let alone the user level. All operators – whether pure-play MNOs or mixed service providers must wrestle with this melange of legacy, current and NGN interfaces – which means testing and assuring services that may span multiple domains complex. Yes, you can focus on interfaces in isolation, but you can’t really model end-to-end behaviours unless you can connect to them all.

An IMS-based service may use Diameter for authentication, SIP for local session control, and then SS7 if a session needs to be established with a peer network for roaming. A simple service may thus span multiple generations of control plane technologies, as well as different entities, from the IMS core to the STP functions between networks, and the databases that register and record authorised users and their status – home subscriber or visitor, for example.

The thing is, though, many established solution providers have retired (or about to retire) support for control plane interfaces like SS7 – which you, as operators, are not planning to retire any time soon. You need solutions that will enable you to perform functional and performance testing for service validation and assurance across all of these interfaces – SS7, Diameter, HTTP, SIP and the rest.

That’s where we come in. At Emblasoft, we’re committed to supporting things like SS7 for as long as they remain in service. We offer a comprehensive range of solutions that enable comprehensive test and validation for:

• SS7 ISUP
• SS7 TCAP
• SS7 MAP / CAP / INAP
• Diameter
• HTTP2
• SIP

And more, allowing you to connect via SS7 to your STP, as well as HTPP2 to your SMF, or Diameter to your charging platforms, and SIP to the IMS. With support for both ANSI and ITU variants, as well the ability to scrip custom messages for complex transactions, we’ve got you covered.

So, if SS7 testing and assurance remains on your agenda (and it probably does), why not get in touch to find out how we can help you?