IN is dead, long live SDN

The advent of computers saw the adoption of digital technology by telephone exchange manufacturers. In the UK the two dominant suppliers of digital exchanges for the PSTN were GEC’s Plessey (GPT) with the System X and Ericsson with the System Y, as it was known.

The last old-style electromechanical Strowger exchange was replaced in 1995, so this technology had had a good run, the first in the UK having been installed in Epsom, Surrey in 1912.

Consuming less power, the computerised switches were faster, more reliable and took up a lot less real estate. And because they exhibited all the characteristics of a computer system, they could offer more functionality and a portfolio of features was developed which could be controlled by a standard push-button DTMF telset.

These features, marketed as “Star Services” by BT, mimicked the kind of features that had found their way into private automatic branch exchanges (PABXs), such as GPT’s iSDX. By using combinations of the star key (*), and the hash or pound symbol (#) with dialled digits, users could divert calls for example.

The problem though for the user was that the user interface of the standard telset was truly appalling for these services. The problem for service providers was that the software that delivered these features had to be installed into every exchange, of which there were hundreds, which made Release Management and Capacity Management major issues.

It also made some services all but impossible, such as non-geographic numbering services, as every switch would need to contain the entire country’s number translation tables.

The obvious answer to this was to centralise the software that provide the functions and features of these applications and to to this, the concept of the Intelligent Network (IN) was created.

The Intelligent Network

The Intelligent Network (IN) principle components, Inbound Application.

The Intelligent Network (IN) principle components, Inbound Application.

At the time, the PSTN consisted of local exchanges and transit switches. If you were on local exchange 01628 and wanted to reach the phone 01628 123456, all you had to do was dial 123456. But if you wanted to reach the number 0118 123456 in Reading from number 01628 123456 in Maidenhead, you had to dial 0118 123456 and the PSTN would use the national numbering plan to switch your call through to Reading, via first the local exchange and then transit or backbone switches.

To provide access to companies by telephone, a new class of non-geographic number was created, along with changes to the billing process. A company anywhere in the country could purchase a non-geographic “0800” number – 0800 123456 for example. This meant users didn’t need to know the local area code for where the company was based, and the billing system was changed so that the bill went to the called party (the company), rather than the calling party (the user).

While this was great for the end user, it could prove very expensive for the company, so a variation on the theme was devised – Local Rate. By using a Local Rate prefix, the bill was split between the end user and the company, such that irrespective of where the user was calling from relative to the company, the most they would pay would be a local call equivalent fee.

How did IN work?

These kind of services are often referred to as “number translation services”, because that’s what they do. The number translation capability is contained in an application that sits on a centralised processing or control platform called a Service Control Point (SCP). The SCP connects to a unit on a transit exchange called a Service Switching Point (SSP) and the signalling between the two was a sub-set of INAP Intelligent Network Application Protocol), called Core-INAP.

The 0800 Freephone prefix dialled digits acted as a “trigger” to the network that this call was an "IN call” and would route the call to the SCP. The SCP performed a lookup to find the real geographic number associated with 0800 123456 and would then complete the call in the traditional way. And as I said previously, it would send the bill to the called party.

Trigger happy

The big three Number Translation applications that you had to have were:

  • Freephone
  • Local Rate
  • Premium Rate

However as Product Manager for the IN application portfolio for GPT, I felt that more could be done as almost any change of state on the network could be treated as an IN trigger, such as "off hook". So in 1996 my team and I created a bunch of other services such as:

  • Pre-call Advertising
  • Pre-payment for MSPs
  • eCommerce on-line grocery shopping
  • VCR remote programming

The last two involved the use of a desk-phone designed to slot in an Apple Newton, which you can read about in this blog entry.

Gaining by invention

Part of the value proposition we created was that service providers weren’t reliant on us to create applications for them – they could create their own applications using an SCE or Service Creation Environment that we designed. This was a GUI-based application development engine used to create the code for IN applications. Pretty much anyone could create applications using this tool called GAIN Inventor, as all you needed to to was to string icons together and set behaviour parameters in each icon. Gamma’s web and app-based Inbound service works in the same graphical way:

Gamma's Inbound management app

Gamma's Inbound management app

Plane speaking

What’s all this got to do with Software Defined Networks (SDN)?

The purpose of IN was to centralise features or applications for ease of management, differentiation by innovation, and cost reduction. The purpose of SDN is the same.

IN achieved this by separating the network into the Application Plane, the Control Plane and the Data Plane, as does SDN:

IN components aligned with SDN terminology

IN components aligned with SDN terminology

Software Defined Networks

SDN achieves the same thing, but in a packet-oriented network:

SDN in operation, showing Openflow "interrogation" of packet header

SDN in operation, showing Openflow "interrogation" of packet header

Applications still reside in the Application Plane. The Control Plane consists of the SDN Controller and the Data Plane consists of Network Forwarding Devices such as switches and routers. In the IN world these were the Central Office and Tandem switches and even PABXs and telsets.

A packet enters a Network Forwarding Device, and the packet header is examined by Openflow – the equivalent of Core INAP. The relevant Application is triggered and sets the next behaviour for that packet, which might be to exit on Port n. This is repeated in each Network Forwarding Device for that packet until the destination is reached. All following associated packets then follow the same path without needing this inspection – this is known as “Fast Path”.

Nothing’s new

As we’ve seen, there are a lot of similarities in concept at least between Intelligent Networks (IN) and SDN. With the addition of Network Function Virtualisation (NFV), which makes network resources elastic or plastic, flexible or “Liquid” Bandwidth, and proactive network automation, I’m surprised we’re not calling this Intelligent Software Defined Networks, or ISDN.