Jan A Audestad
Until recently telecommunications services in public networks were limited to basic calls, that is to establishment of connections between two users, with the addition of a few simple supplementary features. It is also recently that much of the electro-mechanical equipment were replaced by modern program controlled exchanges interconnected with Signalling System No. 7. The exploitation of the vast computing power of these exchanges and the capability of Signalling System No. 7 to pass service related information have led to the development of a large number of new basic services such as mobile services, enhanced freephone services, virtual private networks (VPN), universal personal telecommunications (UPT), CENTREX, etc. In addition, the number of supplementary services, i.e. services or features that can be combined with basic services to meet specific user needs, has grown from a handful to more than a fathomful. At the moment the overall picture of the capabilities the networks can offer is complex and it is difficult for users both to choose the right services and to use them in an efficient manner. One motivation for IN is to provide solutions to these problems. Another closely related motivation is to provide mechanisms for rapid and efficient adaptation to market demands for new services and features.
In order to offer the basic service capabilities mentioned above in an efficient manner the network needs to be enhanced with additional infrastructure. One objective of IN is to provide this infrastructure. The basic services are, in a broad sense, independent of the network that supports them, i.e. whether it is ISDN, broadband network or packet data network. The same applies to supplementary features.
This paper will look at various aspects of IN and explain them by help of examples. In this presentation the main focus will be on principles rather than on current standards and early implementations in order to illustrate the evolutionary potential of IN. Current standards and implementations are devoted to practical adaptation of the basic principles to existing network implementations and equipment design and do not take full advantage of the capabilities an IN may offer.
The exposition of this paper is based on some of the key elements in the definition of IN adopted by the CCITT and included in Recommendation Q.1201.
These are:
The term subscriber will be used to designate the person or entity having the contract with the service provider. The user designates any party accessing the network using own or other services.
In order to illustrate the versatility of IN to provide efficient network solutions, three quite different examples will be given: basic freephone service, traffic volume booking and televoting.
The main characteristic of the freephone service is that the calls are not paid by the calling user. The freephone number, i.e. the number dialled for accessing the network, is normally a number that alone does not identify the physical destination of the service. Reasons for this are:
Therefore, a translation from the freephone number to the physical destination number must take place in the network. As illustrated in Figure 1a) this number translation can be done by a special resource exchange without the need for IN. All calls to freephone destinations must then be routed physically via this exchange. However, by using IN, i.e. by introducing a routing database which can be interrogated by all exchanges in the network, a more efficient routing requiring fewer connection segments is obtained (see Figure 1b)).
For the simple freephone service the database can be viewed as a look-up table consisting of two columns, where one column consists of all freephone numbers and the other contains the corresponding physical destination numbers. When receiving a request for number translation containing the freephone number to be translated, the database will find the corresponding physical destination number and return it to the exchange for further call processing.
This example introduces one aspect of IN (which has more or less become the trademark of it), namely the use of databases and other equipment external to the exchanges. As we shall see later, this facet of IN leads us towards a better understanding of service execution and service based network architectures.
In the next and later sections we will return to the freephone example and show how IN allows the service to be enhanced in order to meet special subscriber needs.
The service of the second example can hardly be realised without some kind of centralised function which can supervise and take actions on the whole network. Figure 2 shows a case where customers (e.g. large computer installations) can request the network to provide capacity for transfer of huge volumes of data. The centralised function (management/IN database in the Figure) will monitor the available capacity of switches and transmission segments in order to decide when and on which route to offer information transfer.
The service resembles network traffic and routing management which is one of the capabilities of TMN (Telecommunications Management Network). It uses functions required for that purpose: determination of free capacity and available routes. The service is thus an example of using features required for administration and operation of networks as an element of a service offered to subscribers. It may also be taken as an indication that much commonality can be expected between TMN and IN.
The key feature of the service is efficient utilisation of the transmission capacity of the network. Variations of it could be:
The third example is televoting. Televoting can be used for elections, opinion polls, melody contests, quiz programmes, etc. Though quite different, all these applications share some common attributes that the network must support:
Televoting is, like freephone, a service which has been offered for a long time and without IN support. In non-IN implementations the calls representing voting events are routed towards special terminations in the network for registration, counting and processing. Since televoting often causes mass calling events with the risk of overloading the network, an IN solution like the one shown in Figure 3 is preferable. In this solution votes are counted in each local exchange and subsequently transferred to the management/IN database for further processing. This processing may consist of formatting the results in a way convenient to the service subscriber and delivered at times determined by him. The local exchange may also indicate to the voter that the vote has been registered or rejected, as the case may be. The indications to be provided may be specific to the type of televoting service used or in accordance with the wishes of the service subscriber.
Overloading of the network is avoided since calls exist only on user access lines and counts can be transferred from the local exchanges to the management/IN database at a rate that will neither overload signalling links nor processors in the database.
The example brings forward several points which are also key characteristics of IN even though they are not exploited in the first phase of implementations. The database contains information which has been determined (and also inserted) by the service subscriber. He can also alter some of the data sets associated with the service within given ranges. This point will be explored further in the next section.
The service is distributed in the sense that the central database and processing entity, though in control of the service, performs only part of the service execution: formatting and presentation of voting results and interactions with the service subscriber. The parts of the service related to registration of votes and interactions with the voters are decentralised to local exchanges.
The service subscriber interacts directly with the central database. The interaction between the service users (voters) and the service can, in a similar sense, be regarded as being direct. The televoting service may then be depicted as shown in Figure 4. In this view the service is seen as a single entity, although it is physically distributed. The service does not require connection segments for passing information between users since there is no such information to pass. As we shall see later, this is part of a more general distributed IN architecture where service control and the transmission and switching aspects of the network are separated.
The main target of this section was to show how IN can be exploited in order to make efficient use of network resources. However, by giving three simple examples of IN services where efficient use of resources has been a prime factor in developing them, several other key aspects of IN have been uncovered:
In the televoting example given above we saw that there are service attributes that the service subscriber may want to control. For a televoting service used for opinion poll such attributes could be:
The set of attributes required for a simple melody contest could be the start and stop time of the contest, all other aspects of the service being fixed by subscription.
This example illustrates several things:
The above brings forward another key issue of IN, namely customisation of the interaction between service subscribers and the network. As we shall see later, customisation is a wider aspect than this and enters into all facets of IN.
In order to give a more systematic approach to the issue of subscriber control of service attributes let us return to the freephone example and expand that in steps. In its simplest appearance this service consisted of
Note that it is specifically stated that the charges are levied against the service subscriber and not against the subscription associated with the physical access (or the called number). As will soon become apparent, these subscriptions may be independent from a service point of view. Our service subscriber wants to expand his business to three offices distributed over the country with the arrangement that
In order to support this service the network must be able to convert the freephone number to different destination numbers depending upon the origin of the call. Note that the simple conversion table has now become more complex since it is conditional by the origin of the call. The situation is illustrated in Figure 5a).
The service subscriber then wants to offer 24 hour service and service on holidays with the condition that only one office is open outside normal working hours. He also wants control of the attributes associated with time (time of day, weekdays, dates) and definition of geographic region. The new scenario is shown in Figure 5b) together with the algorithm for choosing the right destination.
The business has now expanded so much that there are several persons answering calls at each office. The service subscriber therefore wants line hunting in order to choose free positions and ensure equal loading of them. The line hunting feature requires that the service control function not only does number conversion but also that it keeps a continuous overview of which lines are free or busy within each hunt group (see Figure 5c)) and how incoming calls are distributed among them.
In the final step the line hunting feature and the conditional routing on time has been replaced by a centralised queue where the queuing function supervises which lines are free or busy and which offices are open or closed. The conditional number conversion arrangement of step b) still applies with the exception that if all lines are busy at one office, the call can be routed to another office even though that office is outside the region normally served by that office. The service subscriber has also changed the charging arrangement such that calls from a given group of customers to the business always have calls free of charge while other customers are charged if they call outside normal working hours. The service subscriber may also need customised announcements to be inserted at different call states. The announcements could be indication of how many calls are in the queue and expected waiting time, indication that the call will be charged to the customer, etc. He also requires that the network provides the announcements to the calling user in a convenient way (voice, text, picture) depending on the type of terminal used. The service subscriber wants detailed monthly statistics: number of calls, handling times, line loadings, queuing times, number of unsuccessful calls, etc. He also requires control of most of the attributes associated with his service and even asks for customised security mechanisms related to authentication, authorisation, rules for invocation of changes, status of attribute values, etc. What this example illustrates is a realistic evolution of a service after it has been installed in its first simple form. The real challenge for network operators and service providers is to be able to respond quickly to such demands for customisation of service. Customisation of services and rapid response to market demands require several prerequisits:
The evolution of the freephone service given in the previous example hints to a possible decomposition of services into reusable modules, where "reusable" means that each module can be used in different types of service. This is the key to service creation and efficient service execution.
In what follows we will refer to these service modules as objects in order to flag that they should obey all general aspects of object oriented modelling and design.
From the previous discussion we may identify several service constituents that may serve as reusable service objects:
By combining one or more of these objects a complete service can be built. Figure 6 lists which objects are required for each of the four evolutionary steps of the freephone example of the previous section. The list of objects is not enough to characterise the service. It is also necessary to specify exactly what each object is expected to do. This can be done by defining a set of attributes for each object as shown in Figure 7. Each attribute can again be defined in terms of which operations can be performed on it. The current queue length attribute of the queue object can be increased or reduced by 1 depending on whether a new call arrives or a queued call is being serviced.
The above description is not formally exact. It is intended only to give a first idea on how object orientation enters into service design. Accompanying papers provide further insight into the formal use of object orientation.
It may be convenient to let an attribute of one service object consist of other service objects. The call treatment attribute of the queue module in Figure 7 may thus contain conditional branching and announcement objects. Note also that the attributes required depend on the service: for the freephone example with routing on origin the conditional branching object only needs the origin attribute, while in order to provide routing conditioned on working hours it will require time of day, day of week and date attributes.
The attributes in one object are available for other objects in the service (or in other services interacting with it). Such interactions may involve reading attribute values, changing them, etc. Some attributes of an object may also be available for external run-time manipulation, for example by the service subscriber. In the example with the queue object it may be possible for the subscriber to change the value of the "number of server" attributes and to delete or insert new "identity of server" attributes. This may require that security objects are added to the service in order to avoid illegal manipulation on the attributes.
Our modular decomposition of services is so far incomplete since it has not included what is the basic element of most of them, namely the capability of providing and maintaining connections for information transfer between all parties involved in a call. This requires two important things:
The purpose of the first is to sort out and resolve things such as
Studies of these problems have just begun. They will require investigation into areas of advanced computer science such as concurrency, distributed processing, distributed operating systems, dynamic rule based execution, etc. This is one of the biggest challenges in defining the evolutionary path of IN.
However, the existence of service interaction leads us to one of the basic conclusions of this section, namely the separation of service and physical connections. Before going into details, we must also look at how to handle the interaction between the service objects and the connections.
The first requirement concerning this interaction is one which we have already recognised as one of the objectives of IN, namely that a service should be executed in the same way on all types of network, i.e. the service execution must not depend on whether the physical network is ISDN, B-ISDN or a public data network. The second requirement is that the model must provide the service with a simple but consistent view of the network for each call. The simplest approach is to let the call configuration in the network be represented by a service object referred to as a virtual switch. This was also the approach taken by ETSI NA6 in their first definition of a call model (this model has later been abandoned by the CCITT and replaced by a much more network dependent and less intuitive model). The virtual switch object is illustrated in Figure 8. The object contains two types of attributes: leg and connection point where several instances of each may be present (legs and connection points may also be modelled as objects with their own set of attributes). The operations that can be done on legs and connection points then represent the manipulations that the service can do on the physical network. Note, however, that it is also necessary to represent other features of the network by objects available for service manipulation: traffic filters, various types of specialised resources, terminal devices, etc. These are not important for our presentation.
The virtual switch thus provides the service with a "need to know view" of the underlying network. In the hidden parts of the object we may conceal the protocols required for interacting with the network and any network dependent information. By carefully defining attribute values related to legs and connection points, one can make the part of the virtual switch object which is visible to other service objects independent of the actual network. For service execution it does not matter whether the connection point lies within one exchange or is distributed over several exchanges, or what switching technique is used: circuit, ATM, packet, etc. This makes the virtual switch also a reusable object.
At this stage we have at our disposal several service feature related objects and the virtual switch object. From these, several services can be built, each service exploiting the objects in different ways. Hence, by our approach we have reached another of the objectives of IN: reusability of service components.
Our approach has also led us to a new network architecture. By combining the service feature related objects and the virtual switch object, we can view the whole service execution process independently of the underlying physical network. This enables us to define two interacting domains: service domain and switching domain as shown in Figure 9. The service domain contains all objects required for service execution while the switching domain represents connections and switches. As we saw for the televoting service, there are services where only the service domain is present.
In Figure 9 the signalling network (which already exists for signalling system No 7) has been included in order to clarify two points which have not been incorporated in present standards:
In the previous section we derived an architecture for IN from decomposing services into interacting objects. The decomposition was motivated by the reusability aspect of service software. However, this software must be run on machines.
The object oriented approach we have taken allows us more freedom in distributing the software. Figure 10 shows an example of a service consisting of four interacting objects distributed in two different ways. The resulting service is the same but the performance may be different: one distribution may be optimal with respect to processing delay, the other with respect to signalling network loading. From this it can be inferred that different strategies can be chosen for distributing the software and that the software may be distributed differently for different instances of a service or at different times, or when used on different types of networks.
Three prerequisits are required. First, the software must be portable, that is that it can be run on machines from different manufacturers. Second, there must be protocol support that can map arbitrary operations onto a general protocol stack. Third, all objects must be addressable within the signalling network. All of these represent challenges for future standardisation.
It is not only software that can be distributed (and utilised) in an efficient manner in INs. There is an increasing need for customised network support such as mailboxes and customer specific announcements. Service interworking, protocol conversion, speech recognition and speech generation also require special resources in the network. It is a service feature and hence an IN task
As for the virtual switch, these resources can be represented at the service level as objects and thus be included in a network independent manner.
Hence, IN opens for new ways of optimising the network. It should be noted that IN is likely to require large signalling resources. However, it will lead to better utilisation of other parts of the network.
We have already seen that there is a close relationship between IN and TMN: management can be offered as a service to customers by use of IN features. However, there are three other areas where the merging is complete: service creation, service deployment and service management.
Service creation consists of designing services from service objects, assigning attribute values to them and defining rules for how the component objects should perform and interact in order to provide the required service. Service creation is also closely related to subscription management.
Service deployment concerns how, when and where service objects are to be loaded down into network equipment. This area opens for much optimisation. We have already seen that it may be possible to distribute the service in different ways in order to optimise its performance in one way or another. It may also be possible to deploy the service or parts of it at invocation or even at run-time.
The third aspect concerns management of the service itself. This may imply that an object may at the same time be defined as a managed object for TMN and a service constituent for IN, but where the visibility for the two applications may be different. An object which may have two usages is the statistics object: it may be used to record statistics on behalf of the service subscriber and it may be used by TMN for general network management purposes. However, queue objects, announcement objects, filters, etc. may also serve two purposes. This is one reason why a common object definition should be developed for IN and TMN.
TMN has been developed assuming only one domain, i.e. a domain where service and switching are integrated in the same machine. In a separated IN architecture TMN must supervise two domains where each domain will contain only elements of a call. Another point that complicates the picture is that IN will offer various kinds of mobility. One type of mobility we have already encountered, i.e. where the same service may be executed on different machines at different times. Another form of mobility is related to the users where UPT (universal personal telecommunications) offers them the capability of making and receiving calls at arbitrary terminals. In such cases the service objects may be stationary while the access point varies. Of course, a combination of the two forms of mobility is also possible. In this respect IN represents a tremendous challenge to TMN.
Figure 11 shows an overall network architecture where all three types of domains have been included. In the figure it is indicated that several instances of the same domain may exist. For the switching domain this illustrates the existence of different types of network: ISDN, B-ISDN, packet data networks. For the service and management domains different development stages may coexist in the future.
Based on its definition this paper has investigated the evolutionary potential of IN. The paper has not attempted to describe IN as it is now implemented and appearing in standards.
IN started about ten years ago in the USA and was aimed at solving some urgent problems with services such as freephone. Its core element was then and still is that some or all features of a service are executed on equipment external to the exchanges. Looking at the current status of IN the following conclusions may be drawn:
It took five years of standardisation work to get where we are today. It will probably take another ten years before we have exploited all possibilities that the definition of IN promises.
This paper has presented some of these possibilities focusing on which service capabilities IN can offer. It has also pointed at a possible evolutionary path that the development of network independent services may follow. However, the main problems are unsolved: service creation, service deployment and efficient use of network resources, service execution in a distributed environment, service management and merging of IN and TMN.
In order to solve them, new methodologies and a better understanding of what services are need to be developed. Some of these issues are treated in accompanying papers.