The Magic of IN.
© Mercury Communications Ltd - February 1993
To some, the arrival of the Intelligent Network (IN) is seen as a technology breakthrough that will enable Telecommunication Operators (TOs) to rapidly develop and deploy a multitude of 'super-services' that will significantly increase profitability in an otherwise commodity environment. To others, IN is only the true advent of computerisation that occurred naturally a decade ago in non-monopolised industries.
Regardless of one's personal view, IN is upon us and it will have such a major impact on all aspects of our business it behoves us all, whether we specialise in strategy, development, marketing, sales, operations or support, to gain a better understanding of the facts and fallacies of IN.
Figure 1 - A Traditional IN-less Switch Network
For some reason IN, more than many other areas of telecommunications, is riddled with acronyms. Moreover, most of these acronyms, even when expanded, are far from self explanatory. A casual observer from the outside might be led to form the opinion that the prime aim of the IN standards committees was to obfuscate and create a closed environment where only the initiated could participate!
The Non-IN Network World
Before examining the characteristics of an IN based network, it may be worth spending a little time looking at what constitutes the bulk of public voice switching networks today i.e. networks that have not yet been updated to include IN systems. Figure 1 shows a typical network. Not surprisingly it consists of an array of switches connected by transmission 'pipes'. In Mercury's case this fundamentally consists of a mixture GEC Plessey Telecommunications (GPT) System-X and Northern Telecom (NT) DMS switches. These are linked together by a Plesiochronous Digital Hierarchy (PDH) based fibre optic transmission network. The original concept for this network was that it would be a fully meshed network whereby every switch would be interconnected to every other switch in the network. However financial and geographic limitations have prevented that from being implemented in reality. As a result, the full benefits that could have been derived from such a network have not been realised.
Not only are the switches connected to high data rate PDH transmission trunks but also to local 2Mbit/s access ports and a diverse number of overlay data networks for network control, managing billing consolidation, and alarm annunciation. Switches are also interconnected by signalling channels that utilise as many as fifteen different signalling protocols to set up and break down user calls.
Figure 2 - A Non-Intelligent Switching Network
A key issue with regard to IN is that a switch consists of two distinct sections. The first is the physical switching matrix based on solid-state switching elements. The second is the switch software control program. This may be executed on a processor physically located within the switch cabinet or it may be located on a physically separate computer or workstation. Either way, the protocols that allow these two elements to communicate are generally proprietary in nature. Thus only the switch vendor is able to write and maintain switch software and is the only one able to write the applications software that the introduction of new services is dependent upon.
A more generalised view of an idealised switched network can be seen in figure 2. Many TOs have already implemented such a structure whereby network-wide management is brought to bear on controlling and monitoring the network. It is also possible to completely separate the signalling network from the switching network to improve efficiency. A structure of the type shown in Figure 2 is much more common in private voice or data networks where the concept of network-wide management from a single point is well understood. However, even if a TO has implemented full software management network control this still does not constitute an Intelligent Network.
In the pre-IN switching network outlined above a user initiates a call by dialling the recipient's number. The call is routed through the network node-by-node using routing tables embedded in each switch on route. These routing tables need to be updated manually by computer download as and when necessary. With this 'simple' network it is not easy to support services such as Freephone or Virtual Private Network (VPN) that require the ability for the network to route the call to alternate destinations according to a set of complex rules. This requires what the telecommunications industry calls intelligence and what the computer industry calls a lookup table using a database. There are a pot pourri of motivations behind the deployment of IN facilities in a network that include strategic, technical and commercial issues:
The introduction of IN forms only a part of the upgrade path for the traditional network. Other significant components are Synchronous Digital Hierarchy (SDH) covered in TW #2, Signalling System 7 (SS-7), and holistic network management.
The Telecommunications Industry IN Conceptual Model.
Sources such as telecommunications media or industry seminars will usually describe IN systems in terms of a block diagram such as that shown in Figure 3. In this description a Pointrefers to a physical hardware or software entity that can be addressed from anywhere in the network (i.e. xxP). An alternative method of presenting an IN is through using Functions. This refers to the logical action the software is tasked with. Figure 3 uses the physical Point notation. The IN components of this network consist of the SSP, IP, STP, SCP, SCE and SMS. The function of each is described below.
Figure 3 - A Telecommunications Industry IN Conceptual Model
Service Switching Point
The Service Switching Point (SSP) consists of the hardware switch in combination with the basic call control software and the added functionality for the support of IN. This latter software provides the capability to separate basic calls from IN-based calls when they arrive at the switch. IN calls contain events and triggers and when one of these is detected the SSP temporarily suspends call processing and initiates a series of transactions with the Service Control Point (SCP) using SS7 signalling protocol to determine how it should process the call. In fully implemented IN networks these SSPSCP transactions could be handled by a Signal Transfer Point (STP). On early IN implementations, it is not necessary to use STPs to manage signalling. Mercury's recently deployed IN solution to handle Premium Rate Service (PRS) and FreeCall service is an example of this intermediate approach.
Signal Transfer Point
STP functions can be co-resident with a switch as well as being possibly implemented as a separate entity. In a switching network that contains a separate signalling network based on SS-7 the transactions between the SSP and SCP are achieved via the STP. The STP is a highly reliable packet switch that allows the concentration of signalling for a large number of trunks and handles the routing of signalling messages. Additionally, the STP can contain extra functionality such as the translation of a virtual to a physical destination and security screening. It should be remembered that the use of STPs is not essential for the implementation of an IN.
Service Control Point
The Service Control Point (SCP) is a real-time database that stores customer records. When accessed by an enquiry from the SSP, the SCP executes service logic that has been customised for a particular application. Following the execution of the code, the SCP sends instructions back to the SSP on how to process the call. The bulk of current IN transactions consists of translating the number dialled by the caller into another number depending on the needs of the service. This second number is then used by the STP and other switches to route the call using normal procedures. In some early IN implementations the function of SSP and SCP have been combined to form a Service Switching & Control Point (SSCP) as seen in Mercury's first IN deployment to support premium rate, FreeCall and LocalCall services. MCI call an SCP a Data Access Point or DAP.
An Adjunct Processor (AP) is a local SCP. It is tightly coupled to, and co-located with, a single switch. It can use a proprietary protocol for communication with the switch or it can use the CS-1 standard, Intelligent Network Application Protocol (INAP). Overall functionality is highly vendor dependent. It is often supplied as an intermediate solution prior to full IN deployment. For example, GPT has proposed an AP solution for Easy Access on System X. The reason for this is that for this service the use of a local AP is ideal.
Service Management System
The Service Management System (SMS), operates off-line from the voice call network and enables an operator to create, update, and validate, such items as number translation and call charge tables, and download these together with service logic code, into the SCP and AP. The SMS also provides functions for loading, administration, and maintenance of data and provides an interface to processing transaction information generated by the SCP. An SMS could be used to load AP data or even data fill an old style switch.
Service Creation Environment
The Service Creation Environment (SCE) is a high-level interface to the IN that allows TOs to interactively develop, debug, and provision new services using software engineering tools whose output is compatible with the IN systems. The software is likely to based on a 4GL application generator with the service being presented to the programmer in graphical form via a standard Graphical User Interface (GUI) such as Windows or MOTIF. The SCE also enables the TO simulate a newly defined service prior to deployment to enable off-line de-bugging of the code. SCEs are generally available as yet other than in prototype form.
An Intelligent Peripheral (IP) is a stand-alone processor that is tightly coupled to a switch to provide additional functionality to the SSP in the switch. Such additional functionality could include:
An IT Perspective.
Looking at Intelligent Networks from an Information Technology (IT) perspective can simplify the understanding of IN concepts. Telecommunications standards bodies such as CCITT and ETSI have created a lot of acronyms which can sometimes obfuscate what in reality is straightforward.
In the IT domain an intelligent network more usually refers to a highly resilient communications network managed by a centralised management function such as NetWare based on Simple Network Management Protocol (SNMP). Whereas in the TO domain, IN is a term that refers to an architecture in which a relatively 'dumb' switch refers to an external database in order to gain additional information necessary to complete a call. In a fully implemented IN structure the database may be controlled centrally and communicates with the switch using a standard protocol. In an early implementation, the database is more likely to be co-located with the switch in the form of an attached processor using a proprietary protocol. Figure 4 presents a simplified view of a generic IN network based on the CS-1 IN standard. Many extant IN systems do notuse standards because standards are only now being defined by ANSI, CCITT and ETSI. In this figure, there are four levels of hierarchy. The lowest one consists of the core switching and transmission structure. The IN component of the switch control software (SSP) co-resides on the switches or on an adjunct processor. The IN switch software looks for embedded IN triggers in subscriber calls and if it detects one sends a request to the remote database workstation for a number translation.
The second layer consists of a high-reliability computer(s) which could either be multiple systems on an Ethernet LAN using majority polling techniques or a centralised non-stop configuration such as a Tandem or Stratus box. The system executes multiple service or application programs. These application programs interface to a database, such as Oracle, which contains specific customer service information, number translation tables, tarriffing data, and other records as dictated by the defined services supported. The third and fourth layer are the off-line functions of service creation and management. Examples of possible number translations are:
Route an incoming number from a particular region to a number in that region. For example, if a 0500 FreeCall enquiry to British Rail is received, this could be forwarded to the nearest BR station. BR would be billed.
Route an incoming number to any one of N destinations according to a predefined pattern. A call to a particular customer's support department could be routed to a support office anywhere in the UK. If one is busy, it will be re-routed to one that is free on a rotational or 'who has been free longest' basis.
Route a call to a particular destination depending on the time of day. If an airline ticket booking office is closed when an enquiry is received, it could be forwarded to another office on another continent that is open.
Figure 4 - An IT View of an IN
Simply translate a number and generate a different tariff depending on the source of the call. A Virtual Private Network(VPN) may call for an internal code such as 7-60-3187 to be translated into a standard PSTN number or to another carriers' particular VPN number format. On non-IN based networks these VPN translation tables have to be loaded into every switch independently and manually. If another site is added to the VPN dial plan, then every table on every switch needs to be updated. Although this approach is satisfactory for getting a new service off the ground, an increase of VPN customers causes an explosion of support tasks.
The ANSI / Bellcore, CCITT and ETSI standard bodies are expending considerable energy in pulling together the first tranche of standards aimed at defining a general IN architecture. For ANSI this is under the banner of Advanced Intelligent Network (AIN) and for the CCITT & ETSI the efforts are pulled together under Capability Set 1 (CS-1 or Q.1201). Although the CS-1 and AIN architecture definitions and visions are complete, there is still considerable work that needs to be undertaken to fill in the details. The CS-1 standard reflects the structure as shown in Figure 3 and covers the protocol necessary for a switch to communicate to the database, but it does not as yet include the major tasks of service creation (SCE) and service management (SMS). These areas will remain in the proprietary domain for several years yet. As is common with many standards, the set of services and options as defined in CS-1 are wide-ranging and a need to get products to market in the near term have dictated that a common sub-set be produced. This is known as Core Intelligent Network Application Protocol or Core-INAP. The European Technical Standard for this subset is due for release in 3rd quarter 1993. The full list of services defined in CS-1 runs to 38, examples are:
This service allows customers to build a private network utilising public network resources. The IN database stores the customer's dial plan rather than holding them in each and every switch i.e. GVPN & IVPN
Strictly speaking, it should be noted that there is no such thing as an IN-service since a service may be implemented in an IN way or in some other way. VPN is a good example of this, where our existing network can and does provide this service.
Advanced IN Services that Rely on the Use of a Intelligent Peripheral
Capability Set 2 is aimed to be released in the 1993 to 1997 time frame and is aimed at addressing key issues such as Broadband-ISDN, mobility, and multi-media services. CS-2 will also produce standards to cover the service creation (SCE) and service management (SMS) functions.
A key issue for IN is the degree of openness of an IN infrastructure. Most implementations of IN to date are of a proprietary form which could inhibit the efficient deployment of IN based services. There are many possible interfaces within an intelligent network and which of these interfaces will be opened, if any, will involve considerable discussion and interplay between the technical, commercial, standards and regulatory bodies for many years to come. A major issue for TOs is the degree of openness between the physical switch hardware and the switch control software. This particular issue may dramatically affect the relationship between TOs and switch vendors. What will switch manufacturers look like at the end of the decade? Will they still be seen as hardware vendors or will they evolve into major players in network software markets? Also, the role of computer suppliers will be an interesting issue to watch.
IN should not be seen as a magical tool for developing advanced services, rather it is an evolution of the network and, from many perspectives, IN is the network. Many services, such as VPN, where number translation is a mandatory requirement can run, albeit inefficiently, on a non-IN network. However, the use of IN results in a tremendous step forward in efficiency, manageability, feature capability and flexibility. IN, like SDH, is an enabler; once deployed it brings the power of today's desktop 100MIP+ computers to bear on a network and many new services will be developed in the future with the combination of broadband, multimedia, and IN.