Jan Audestad and Børge Jacobsen
This paper presents an object oriented (OO) approach to UPT architecture allowing UPT users to roam between networks of different type and ownership. The architecture is based on a recursive definition of objects, i.e. where objects can be attributes of objects. This allows services to be viewed at different levels of granularity and designs where the actual software is distributed in an arbitrary manner between the machines making up the physical architecture of the network.
It is convenient to distinguish between three types of mobility forming a bottom-up hierarchy as follows:
Terminal mobility is the type of mobility offered by land or satellite mobile systems and can be regarded as geographical distribution of the subscriber line. The benefit for the user is that the network can be accessed while moving and independently of fixed subscriber line access points.
Terminal portability means that a user terminal can be plugged in at an arbitrary access point which may be at a fixed installation or at a mobile station. The benefit for the user is that user specific capabilities of the terminal can be exploited at all network access points.
Personal mobility implies that the user can initiate and receive calls on the basis of a single personal number at any fixed, portable or mobile user terminal. The three levels of mobility and their relationships are illustrated in Figure 1.
Personal mobility thus makes use of all levels of mobility. Personal mobility is the core element of Universal Personal Telecommunications (UPT). UPT will become one of the basic service capabilities of future networks and will therefore require that all future network architectures support aspects of personal mobility (roaming, secure network access, uniform access procedures, etc.).
UPT will impose several requirements on future networks. Each UPT user should ideally have a single UPT number by which he or she can be reached at any network access point. On this number it should also be possible with different user roles, e.g. the user as a private person or as employee. The services available for the user may be different for different roles. As employee the services may not only be personal but also contain capabilities subscribed to by the company. This implies that service profiles can be distributed in the network depending on role. However, there may also be cases where it is more convenient with separate UPT numbers for each role. This should be subject to choice by the user and not be a restriction imposed by the network.
The network should be capable of providing the user with accustomed or user specific user-network access procedures at all locations. Examples of user specific procedures are customised alerting, customised announcements or text and abbreviated number/hot-line selection. It should be possible for the user to roam between networks owned by different network operators. This capability should include roaming between different LANs and VPNs.
The UPT service should not depend on network type, e.g. it should be possible to roam between ISDNs, dedicated data networks and B-ISDNs. This capability implies that a common service control should be defined for all network types. Note that if a shared numbering plan does not exist between these networks, then the user must have one UPT number for each network.
All of the above requirements have impact on the architecture. It is particularly evident that the architecture should not be optimised in respect to one network design only.
A clear distinction should be made between conceptual architecture and physical realisation. The conceptual architecture should be independent of physical realisation. The requirements listed in section 2 above showed that this will in particular be true for UPT.
A conceptual architecture (e.g. like the one defined formally in CCITT recommendation X.407) can be used to show aspects of the system from different angles and at different level of granularity. The different levels of granularity are obtained by refinement of less detailed views in a recursive manner. (1)
A general top level conceptual architecture of a telecommunications network is shown in Figure 2. It consists of three interacting domains each representing a distributed process.
Management domain responsible for service creation, service subscription management, service deployment and service execution management.
Service domain responsible for execution of the telecommunication service, including manipulation on the switching functions of the connection domain.
Connection domain representing transmission and switching functions.
A refinement of the general architecture valid for UPT call processing is shown in Figure 3. The service domain has been sub-divided into an A- party service and a B-party service. The connection domain has been refined as access points and switched path. Each of the new elements may represent a distributed process. The manipulation of the connection domain, i.e. the switched path, is performed by either the A-party service, the B-party service, or both.
This simple call processing architecture may be mapped onto its realisation architecture, or for that matter, another conceptual architecture (for IN it is not clear whether the current architecture is conceptual or reflects realisation). An example is shown in Figure 4 where the A-party side is mapped onto an IN and the B-party side is mapped onto the GSM system. There are two important points in this example. First, it is possible to define a mapping in each case and allocate the functions of the conceptual architecture to functional elements in each realisation. Second, each function of the conceptual architecture may map onto a single functional element or be distributed over several elements. It should also be noted that the functions may be realised in independent ways in IN and GSM. The only requirements is that the functions A/B-party service, access point, etc., behave according to a common UPT specification. The conceptual architecture thus meets the requirements of mappability referred to in section 2.
Object Orientation (OO) is a powerful method for specification and implementation of complex systems. Some important aspects of OO are: (2)
The UPT service will be complex. The distributed nature of the service adds additional complexity. It is important to find a suitable method for handling this.
Figure 5 shows a UPT call service modelled as interacting objects. The attributes of an object may be objects themselves, but this structure of the service object is hidden at the higher levels of abstraction. The objects shown in Figure 5 are in the service domain but since services generally imply manipulation of connections, some of these objects must manipulate the connection domain. At the given level of abstraction this is hidden within one or more of the objects.
Figure 5 shows the service execution. It does not consider physical distribution of the service but focuses on the service modelling.
The A-party service objects are invoked to initiate the UPT service. One of its attributes is the access handling object (A). The access handling objects may have other objects, e.g. identification objects, screening objects, as attributes. Object A invokes a security object (S), a charging object (Ch), a connection handling object (C) and a B-party service object (B) where C manipulates the switches and B handles the B-party services. The B object may be sub-divided further to reflect the constituents of the B-party service. This sub-division is not considered here.
Figure 4 showed a mapping of services onto an IN system and a GSM system. Figure 6 contains a corresponding mapping for the OO approach. In the example two connection objects (C1 and C2) are required in order to manipulate the switches. The objects C1 and C2 have inherited their general characteristics from a superclass C. The adaption to the actual networks is hidden inside the objects so that a separate connection object sub-class may be defined for each type of network. In the example, C1 and C2 may belong to different sub-classes. In this view we can regard the subscriber access lines to be contained in objects A and B, and the physical switches and transmission network to be contained in objects C1 and C2. Thus, peculiarities within each specific network are hidden from the other objects which constitute the service. The objects of type A or type B should not see any difference between objects of type C1 and type C2. The same operations are performed on both but their internal actions are performed on different types of networks. The type of object to be invoked must thus be chosen at the time of invocation. In object oriented design this is possible by dynamic binding. Communication between the objects will use available protocols in the networks. Though C1 and C2 look the same for A- or B-type objects, the protocols chosen for communication between them may not be the same. From the service point of view, only the logical information flow is important. The objects can be distributed on several different nodes in the networks which offer the service. In the short term this distribution may be done manually. In the long term the run-time system should optimise the actual distribution automatically. The encapsulation and modularity offered by OO will simplify the distribution task.
The object oriented approach yields an architecture which is easy to decompose into different levels of granularity. Figure 7 shows the decomposition of a service control object into gradually finer parts. The top level consists of the service control object only. This object is then decomposed into types A, B, C, S, and Ch. The next level of decomposition is only shown for object A which consists of an identification object (ID) and a security object (Sc).
In a physical realisation the objects may be distributed in such a way that the various attribute objects it may contain are instantiated at different machines. This is illustrated in Figure 8 for the decomposition in Figure 7. In this example the A-service objects are distributed on three machines and its contained access object (A) is again distributed on two of them.
This capability of distributing objects is particularly important for UPT since it allows objects to be moved and instantiated at different places as the user roams in the network. In this way optimum use of resources and the best possible service performance can be planned into the service.
The difference between model and implementation is very distinct in this architecture. The model contains classes and the implementation is the actual instantiation of these classes, i.e. the objects. In the current IN architecture (3) as used by ETSI and CCITT, the distinction may not be so clear.
The object oriented approach to the UPT architecture removes unnecessary and undesired bindings of the UPT service to physical realisation. The decomposition of the service into interacting objects is independent of network design, network ownership and network type. The decomposition depends only on the particular UPT service offered to each individual user. The mapping of this decomposition onto network resources can be done in an optimum way maintaining all service features independently of this mapping.
In this paper only a simple two-party call service has been analysed. The same approach will apply to more complex services and to other aspects of the UPT service such as registration and alteration of subscriber parameters.
1 CCITT X.407. Message handling systems: Abstract service definition connections: recommendations X.407. In: CCITT Blue Book, vol VIII, fascicle VIII. 7, 200-227.
2 Meyer, B. Object-oriented Software Construction. Englewood Cliffs, N-J., Prentice-Hall, 1988.
3 CCITT Q.1200-Series of Recommendations. Geneva, 1992. ÿ