Realizing Distributed Intelligent Networks Based on

Distributed Object and Mobile Agent Technologies

Menelaos K. Perdikeas1, Odysseas I. Pyrovolakis1, Andreas E. Papadakis1, and

Iakovos S. Venieris1
1
National Technical University of Athens – Dept. of Electrical & Computer Engineering
9 Heroon Polytechniou, 157 73 Athens, Greece
{perdikea,ody,apap}@telecom.ntua.gr ivenieri@cc.ece.ntua.gr

Abstract. An architecture enhancing the Intelligent Network to a Distributed

IN is described. To this end, Distributed Processing Environment and Mobile
Agent technologies have been employed. The added value, in the context of
flexibility and manageability of the exertion of the aforementioned
technologies, as well as the extent to which they can be utilized are discussed.
The configuration architecture is presented and an implementation – oriented,
detailed description of the Service Execution Node and its constituents is
provided.

1 Introduction

The Intelligent Network (IN) approach for providing advanced services to end users
aims primarily at minimizing changes in network nodes by locating all “service-
related” (and thus likely to change) functionality in dedicated “IN-servers”, named as
“Service Control Points” (SCPs) [1], [2]. These servers are in a sense “external” to the
core network which in this way needs to comprise only a more or less rudimentary
switching functionality and the ability to recognize IN call requests and route them to
the specialized SCPs. Since the time of its standardization by ITU-T [3], IN has
become the default way for telecom operators to enhance the ability of their core
network to provide value added services to their customers in a cost effective manner.
In this paper we are considering the use of distributed processing technologies such
as CORBA (Common Object Request Broker Architecture), DCOM (Distributed
Component Object Model) and RMI (Remote Method Invocation) along with mobile
code ones in order to enhance IN’s potential. We are mainly focusing on issues
concerning the design and implementation of an IN architecture that would be more
flexible, distributed and facilitating object oriented service creation and efficient
services life cycle management.
2 Applying New Software Technologies in Intelligent Network

Before going on into describing the actual architecture, a more abstract and general
discussion containing some of our experiences and issues emerging when applying
novel software technologies in the context of IN precede. Specifically, the impact of
the introduction of well known distributed object practices (such as CORBA [4]) and
more radical solutions (such as Mobile Code [5]) are discussed.

2.1 Enhancing IN with CORBA

Commercial IN implementation rely on traditional protocol stacks for dispatching

messages between elements of the architecture. These protocols rest on the
asynchronous exchange of messages and are thus termed “message-based” protocols.
Problems with such protocols and the relative merits of the more advanced and
generic remote method invocation paradigm have been recognized by many
researchers and are well documented.
CORBA is a standardized solution to provide distributed processing capabilities to
an environment and the closest to being a “de jure” one. Microsoft’s DCOM is a more
proprietary technology having as main advantage its tighter binding with the MS-
Windows operating systems. Given the diversification that characterizes
telecommunication systems, CORBA is more or less the only distributed object
technology that can seriously been contemplated in this context.
Distributed object technologies extend the notion of a memory or an object pointer
to include pointers to remote address spaces. Using CORBA’s terminology these are
termed “Interoperable Object References” (IORs). IORs are not only opaque handles
to the objects they represent but can also serve as a generic network addressing
scheme. An object doesn’t have to be aware of the IP address and the port number on
which its peer object “listens” – it is simply responsible for obtaining its “handle” and
passing it to the CORBA runtime layer (known as ORB – Object Request Broker)
whenever it wants to communicate with it. This allows the architecture to be
transport protocol independent. Irrespectively of whether the underlying transport
mechanism is TCP/IP or ATM or ISDN, as long as a CORBA layer can operate on
top of it, the communicating objects only have to perceive the semantics and the
notational conventions used by CORBA. The architecture can be reconfigured with
no changes to the hosted objects at all. Communicating objects can be thought of as
“plugging” on a generic method-invocation relaying layer (the ORB) and from that
point on being able to invoke arbitrary methods on other objects “plugged” onto it as
well. In contrast, reconfiguration of an architecture based on traditional “message-
based” protocols is much more difficult.

2.2 Mobile Code in Intelligent Networks

In the traditional IN architecture Service Logic Programs (SLPs) run in centralized

SCPs. This approach naturally renders the network vulnerable to “single point of
failure” types of problems as well as makes it susceptible to performance penalties
associated with the intrinsic bottlenecks that any centralized architecture has. When
utilizing mobile code, SLP distribution among the core network nodes, Service
Switching Points, (SSPs), can come very naturally if SLPs are implemented as mobile
code objects [6]. Once a mobile code platform is installed on each of these nodes,
SLPs can be downloaded on demand or in an off-line fashion for load-balancing
purposes, to respond to a failure in a node they were previously residing or to
preserve network resources. The fact that mobile code platforms are relatively generic
infrastructures hosting a large number of SLPs and being oblivious to their
functionality and operations, facilitates the introduction of new and withdrawal of old
services. Because of being generic, these components may never (or in any case very
infrequently) need to be modified. The ability of the SLPs to migrate to SSPs and
continue their operations from their new location, augments each SSP with SCF
functionality. Service provisioning can be offered directly by the switches’ physical
entities removing entirely the need for a centralized SCP. This should not be confused
as reverting to switch-based services implementation as now, services are not
statically bound to the switches but retain the flexibility of mobile code objects. As a
result, all advantages offered by IN with respect to speedier introduction of new
services are maintained. We refer to the resultant IN architecture as Distributed IN
(D-IN).
It is important to note that the use of mobile code in IN, is not separated from the
use of distributed technologies. In fact, distributed technologies and mobile code are
used in concert and are of equal importance to realizing the D-IN concept. First of all,
they are both IT-based paradigms and have predominant Object-Oriented
characteristics. Both technologies’ offerings have to a significant extent to do with
non-functional characteristics1, which are moreover complementary. Distributed
technologies are concerned with location transparency and increase programmer’s
productivity whereas mobile code aims at offering performance benefits by moving
client (or server) code closer to where it is actually executed, instead of engaging in
network spanning and bandwidth consuming remote dialogues. [7] CORBA’s
approach to “objectizing” even procedural pieces of code through wrapping them in
Interface Definition Language interfaces and plugging them to the ORB using an
object abstraction is well suited for the inherent autonomy and object-oriented
characteristics of mobile code. Location transparency and the use of generic network
addressing schemes (as are the opaque IOR handles) facilitates object mobility since
the actual location of the objects is not important. More importantly yet, and for a
variety of technical reasons, mobile code’s way to introduction in telecommunication
environments needs to be paved by the previous introduction of distributed object
technologies. Simply stated, CORBA’s, DCOM’s or RMI’s adoption will have the
potential of transforming the telecommunication world into a more “permissive
environment”, one in which mobile code will be more easily and naturally employed.

1
Implementation transparency however is a functional enhancement.
3 Realizing Distributed IN Systems

In our design of a Distributed IN system we considered as a starting point the well

defined IN conceptual model. We have aimed for an architecture that would allow a
coherent and smooth transition from the classical, SS7 (Common Channel Signaling
System 7) based, IN architectures towards open, CORBA based distributed ones.
Towards this direction, new correspondences between Functional Entities (FEs) and
Physical Entities (PEs) were defined, allowing the possibility to duplicate some FEs
in heterogeneous systems. In particular, the Service Control Function (SCF) is used in
both service control nodes and switching systems. In addition, the Specialized
Resource Function (SRF) is integrated and combined with the SCF. As a result,
advanced switching systems are introduced where SCP functions are added to the
ones of a SSP, as well as Service Nodes, derived from the integration of SCPs with
Intelligent Peripherals. An architecture implying a more loose mapping of functional
entities onto physical ones, affords us the ability to locate SLPs indifferently in the
switches systems or in the service nodes in a distributed manner.
Mobile code’s role is critical as it gives objects the opportunity to roam through
similar but remote FEs (as an example, a SCF located in a service control point and a
similar one located in a switching system). Following this approach, the binding of
objects to FEs contained in PEs is not static. Instead dynamic allocation can take
place according to an observed pattern of service requests or in response to congestion
or network failures.

3.1 Reference Architecture

Based on the considerations of the previous section, the physical entities of the
proposed architecture extend the traditional capabilities of the Service Control Points
and the Service Switching Points. They are both required to adopt the following
extensions:

• Introduction of a CORBA ORB in the software platform

• Capability to host mobile code downloaded from other network elements.

Within our reference configuration, these systems are named Service Execution
Nodes (SENs) and Broadband Service Switching and Control Points (B-SS&CPs)
respectively. Figure 1 presents the reference configuration [8], [9].
 SEN SCF SRF SMS Repository
CC Wrapper
Messaging Naming
Call Service Service
GW
AEE Control AEE

BEARER SIGNALING

CORBA BUS

TCAP

Traditional
SSF AM
SSP
AEE

SSF SSF
Call
CUSF CCF CUSF CCF Control
SCF
Application

SS&CP User Terminal

Infrastructure Agents (SLM, SSF-AM) Service Logic Agents

Bottstrapping Agents Resource Logic Agents

Fig. 1. D-IN Reference Architecture

In every element of the core network an Agent Execution Environment (AEE) is

installed. This environment is composed of an ORB and the necessary components to
provide the runtime capabilities of hosting, monitoring, interacting with and executing
agents. The AEE is the key element that allows the distributed execution of the IN
based services. In the classical IN the allocation of service logic and data is static.
Within our approach, the adoption of distributed and mobile code technologies allows
a responsive network reconfiguration on the basis of real time needs. Such needs can
include those arising from situations of congestion or overloading in terms of
processing or signaling load in some areas or during certain periods of time or from
the characteristics of the services themselves.
Services with a low rate of invocations can be stored and executed in the SEN.
When a given threshold is overcome, the service logic and data can be downloaded in
the B-SS&CPs reducing processing load on the SEN or signaling load along the B-
SS&CP – SEN connection. This behavior is completely transparent to the end users
and to the call control software modules.
Mobile code technologies are also introduced at the service design and deployment
level. Using this approach, services are designed as Java-based Mobile Agents in
appropriate Service Creation Environments (SCEs) and then transferred to the Service
Execution Nodes utilizing the migration capabilities provided by mobile code
platforms. The basic IN Application Protocol (INAP) semantics governing
information flows between IN FEs are not affected however. Service providers can
thus benefit from a flexible service provisioning environment, which enables them to
adopt OO techniques for software design (minimizing the service development time)
and to make use of mobile code facilities in order to apply immediate and
sophisticated policies for service release distribution, update and maintenance.

3.2 The Service Execution Node

The Service Execution Node is derived from the integration of the B-SCP and the B-
IP [10]. Additionally CORBA and a Mobile Agent platform are introduced which
together play a key role in the service provision.
The SEN initially enables the switch to access the IN agent-based services and
provides an environment to locally execute the stationary or mobile agents that
compose the services in case this can result in performance gains.
It comprises the Service Control and Data (SCF/SDF), Mobility Service Control
and Data (SCF/SDF), Specialized Resources (SRF), and Call Control Agent (CCAF)
functions. The potential introduced by the introduction of distributed object and
mobile code technologies is best exemplified when considering migration operations.
The service logic programs are deployed as stationary or mobile agents and the
latter can be distributed and executed among different physical entities. The
architecture is open enough to allow for the use of SLPs implemented in a native
language if stringent performance requirements are to be met. In the latter case the
SLPs are stationary objects. An important property that is maintained with the
imposition of various access points within the architecture is that the SCF cannot tell
if it is interacted with a natively compiled SLP or a Java-based mobile code one. In
fact the SCF is oblivious to the actual location of the SLP with which it communicates
since the logic responsible for locating, accessing or downloading the SLPs is
orthogonal with respect to the core SCF functionality. Several B-SS&CPs, some of
which may generate a high number of service requests and consequently a high
processing and communication load, can concurrently access a service in a SEN. A
possible migration of the appropriate agents can improve network performance.
Agent migration is also employed to support mobility management procedures, for
example location registration/deregistration, user registration/deregistration, local
authentication processing and so on. In these cases the mobile agents are more passive
objects representing mobility management data and simply offer appropriate methods
for accessing or modifying these data.
Objects and Agents within SEN. The object model of the SEN considers three major
parts. The fist parts contain the objects for the interaction of SEN with the B-SS&CP.
The second part contains the core of the Service Logic and the third part contains the
objects responsible for the SEN to user interaction. Figure 2 reports a high level view
of the SEN architecture.

SLP

<<CORBA>>
<<CORBA>> <<CORBA>>

Service Logic Manager

<<CORBA>> <<CORBA>> RLP

<<CORBA>> <<Native>>
SSF Access Manager
SLM mobile part
<<Native>>
<<CORBA>>

INAP-CORBA Gateway Specialized Resource Manager User Interaction Manager

<<CORBA>>

<<INAP>>
CORBA-based SSF

INAP-based SSF

Fig. 2. High Level SEN’s object model

The SSF Access Manager is the SEN’s gateway object. All SSF-SCF interaction is
passing through this object. When the system is bootstrapped SSF needs only obtain a
CORBA reference at the SSF Access Manager. Technically it consists of two
CORBA servers one for the SCF side (supporting SCF-initiated information flows)
and one for the SSF side (for the SSF-initiated ones). The INAP information flows
have been mapped into equivalent method invocations so for instance the SCF side
interface contains such methods as “DropParty”, “RequestReportSSMChange” and
so on.
The Service Logic Manager (SLM) is the core SCF entity. It is responsible for
locating the SLPs for each particular service that is requested and for initiating
migration procedures either triggered by the management system or by the migration
criteria that are applied. The SLM is however not aware of any service-level details of
the SLPs it manages. All its volatile data are embodied in its mobile part, which is
created at the network management center and migrates on the SCF in order to attach
to the stationary part. Since the interaction between the stationary and the mobile part
is very intense, for performance reasons the interface between them is not based on
CORBA but on Java. So these two objects hold direct pointers to each other allowing
native method invocations between them. A similar approach has been adopted for all
other mobile-stationary part pairs.
 The SEN, as far as UNI signaling is concerned, is viewed as a terminal. The Call
Control Agent Function (CCAF), being the user side of the UNI signaling, provides
access to the network resources. It interfaces with the CCF, which resides in the
switch, and can either establish a new connection or accept an incoming one. The user
invokes an IN service and afterwards the Service Logic connects the user terminal to
the SEN, in order to elicit user input. Further service execution is significantly based
on this info.
The CCAF Wrapper, being a CORBA server, provides a CORBA interface to the
signaling stack wrapping the call control functionality. This functionality is
implemented in native code and can be viewed as a legacy component. This interface
can provide a flexible way to establish new connections, to modify existing ones, to
retrieve the total number or specific characteristics of each of the active ones. The
CCAF Wrapper basically resolves each active session, based on a unique sessionID,
to the connection. For this purpose the SessionId parameter is used to retrieve the
VPI/VCI values (in the case of an underlying ATM broadband network) associated to
a User-Plane connection. The SessionId is included in the Broadband High Layer
Information (BHLI) information element of the Q.2931 SETUP message sent from
the B-SS&CP (CCF) to the SEN (CCAF) [11].
The Specialised Resource Manager is a “hub” for containing volatile service and
user related info. It can be used to contain user subscription and authentication
information, information about available services, about service providers (e.g. video
servers for the Information Retrieval service) or about FTP servers that host content
raw data. The entire body of information contained in the Specialised Resource
Manager is populated in the form of mobile objects that are dispatched there by the
management center. An agent encapsulating content descriptive attributes (such as the
location of the content server or the category that this new content should appear to
user terminals) will be created at the management center. Then it will be instructed to
migrate to the Specialized Resource Manager premises where using the Region
Registry’s facilities he will attach natively to it (perhaps replacing in the process
obsolete information). After this attachment has taken place, new users connected to
the SRF and browsing through its catalogues for movies will find that movie available
for selection.
The User Interaction Manager (UIM) intermediates between the SLPs and the
basic functionality of the IP. Exactly like the Service Logic Manager and the SSF
Access Manager are the SLPs’ “connectivity” mediators to the SSF (and vice versa),
the UIM is the SLPs’ mediator to the SRF. The interface between the SLPs and the
User Interaction Manager is also based on CORBA. In this way all SLP references to
their environment as well as the environment’s references to the SLPs are distributed
allowing location transparent communication to take place. Belonging to the SCF, the
UIM models the way the user interacts with the system for service selection and
content preview/selection. It offers service-specific user interaction functionality. This
functionality is implemented by the Resource Logic Programs (RLP). The RLPs
contain the logic and processing capability to receive and send user information and
convert information received from users.
Each RLP is activated by the UIM after it has been invoked by the service logic
and when the connection between the terminal equipment and the IP has been
established. The RLP resumes the control of the service session for handling an user-
plane connection. While the RLP can actually use the established ATM connection,
only if it knows the corresponding VPI/VCI pair, the service logic is aware only of
the pertinent SessionId. This SessionID is sent to the CC signaling stack in the
SETUP message.
To provide service specific functionality, there should be one to one
correspondence between the RLPs and the available services. Taking as an example
the Interactive Multimedia Retrieval (IMR) service, the pertinent RLP is responsible
for verifying which sub-service interests the user (e.g. video on demand, music on
demand, news on demand) and enabling him to preview content from a variety of
service providers. When the user interaction ends, the SLP retrieves the result (i.e.
kind of sub-service, chosen service provider) and, after processing it (e.g. retrieving
the physical address of the SP), instructs the establishment of one or possibly more
physical connections between the user and the appropriate SP.
At last but not least, the user interaction is not restricted to service specific context.
The SRF can offer service-independent functionality, as well. This can include the
authentication and the authorization of a user, the registration and de-registration for
services and, in general, the interrogation and modification of the user profile. An
alternative way to perform these operations is via the Call Unrelated Signaling
Function (CUSF) implemented in the TE and interfacing with the CCF. However this
way presupposes that the TE supports additional signaling stacks (Q.2932 in the
broadband case) and that the corresponding information is encoded in “facility”
Information Elements (IE) of the signaling messages. These IE are afterwards
decoded by the service logic. Furthermore the updating/enhancement of the available
user interaction scenarios when they are implemented via the SRF seems to be more
flexible and user-friendly. In such case the Specialized Resources Manager is
populated not only by agents bearing SP specific information but also user-specific in
order to render more efficient the execution of the above mentioned operations. This
way checking and updating profile, registering, authentication, authorizing can be
provided locally in the IP.
The implementation of RLPs is static. Another approach could be the
implementation of the RLPs as a combination of static and mobile parts. The mobile
service-dependent parts could migrate to the IP from a management center. This way
the functionality of generic IPs, offering a service-neutral API, employed for playing
announcements and collecting user info, could be enhanced and be service specific.
Furthermore these mobile parts could migrate to the TE, however, the inevitable
necessary enhancements of the TE software platform may overpower the potential
added flexibility.

4 Conclusions

The IN architecture represents an effective solution to the problem of providing

advanced services to end-users. New software technologies which are becoming
available allow to increase the efficiency of this architecture by enabling the
distribution of services in the network and reducing bottleneck problems deriving
from the use of a centralized architecture.
 In adopting distributed object technologies, the proposed architecture emphasizes
the notion of Functional Entities engaged in a location transparent exchange of
“Information Flows” between them (the concept on which the IN is based) and allows
increased programmer’s productivity in the introduction of new concepts and
services. Interoperability with traditional IN is also preserved by means of
IN/CORBA bridges.
Mobile code technology affords a greater flexibility in dynamically composing the
network or parts of it at runtime and in keeping the infrastructure as generic (and thus
as unlikely to need changes) as possible. Mobile code is also used to increase the
robustness of the system and even to seek out and exploit performance gain
opportunities in cases of intense remote interactions that could be made local. Overall,
the combined distributed object / mobile code layer provides significant advantages to
service design and management, allowing for high reutilization of components and for
simplified schemes for release deployment and handling.

References

1. Magedanz, T., Popescu-Zeletin, R.: Intelligent Networks - Basic Technology, Standards

and Evolution, Thomson Computer Press, ISBN:1-85032-293-7, London (1996)
2. Venieris, I.S., Hussmann, H. (eds): Intelligent Broadband Networks, John Wiley, ISBN: 0-
471-98094-3, Chichester (1998)
3. ITU-T Recommendations – Intelligent Network, Series Q.12xx, Geneva
4. OMG, CORBA/IIOP 2.3 Specification (1998), www.omg.org/docs/ptc/98-12-04.pdf.
5. Perdikeas, M., Chatzipapadopoulos, F., Venieris, I., Marino, G.: Mobile agent standards
and available platforms, Computer Networks and ISDN systems
6. Breugst, M., Magedanz, T.: On the Usage of Mobile Agent Platforms in
Telecommunication Environments, IS&N98, Antwerp (1998)
7. Perdikeas, M., Chatzipapadopoulos, F., Venieris, I.: An Evaluation Study of Mobile Agent
Technology: Standardization, Implementation and Evolution, ICMCS '99 Florence – Italy
8. Venieris, I., Zizza, F., Magadanz M. (eds): Object Oriented Software Technologies: From
Theory to Practice, J. Wiley & Sons, ISBN: 0-471-62379-2, Chichester (2000)
9. Chatzipapadopoulos, F., Perdikeas, M., Venieris, I.: Mobile Agent And CORBA
Technologies In The Broadband Intelligent Networks, IEEE Communications Magazine,
pp. 116-124, Vol.38, No. 6 (2000)
10. Prezerakos, G., Pyrovolakis, O., Venieris, I.: Service Node Architectures Incorporating
Mobile Agent Technology and CORBA in Broadband IN, IEEE MMNS’98, France (1998)
11. ITU-T Recommendation Q.2931, Digital subscriber signaling system No. 2 (DSS2) – User
Network interface (UNI) layer 3 specification for basic call/connection control (1995)