Computer Networks 35 (2001) 565±578

www.elsevier.com/locate/comnet

Parlay-based service engineering in a converged

Internet±PSTN environment
Menelaos K. Perdikeas, Iakovos S. Venieris
Telecommunications Laboratory, Department of Electrical and Computer Engineering, National Technical University of Athens,
Heroon Polytechniou 9, 153 73 Zographou, Athens, Greece

Abstract
This paper examines current approaches to signalling and service interworking between Internet and public switched
telephone network (PSTN). It notes that until now convergence between the two networks has for the most part taken
place in the transport and signalling layers. Signalling interworking architectures cater for the speci®c class of tele-
phony-like services and although they can accommodate the extension of the intelligent network's (IN) realm of control
in the Internet, they do not provide a generic platform for service interworking. Through the adoption of the Parlay
APIs, a way is foreseen for (a) consolidation of telephone service over both Internet and PSTN through the imposition
of a uniform call control API while allowing the installed IN infrastructure to be used also for Internet telephony
services and (b) for service interworking between telephony-like services and open distributed services in the Internet.
The paper proposes a service architecture that can be used as a platform for Parlay-based service interworking while
o€setting some drawbacks that the Parlay approach incurs. Ó 2001 Elsevier Science B.V. All rights reserved.

Keywords: Intelligent network; Parlay; Mobile code; Signalling interworking; Internet telephony

1. Introduction trac with adequate quality of service in terms of

Convergence between the public switched±cir-
cuit networks (SCNs) and the packet-based In-
ternet is a much celebrated trend. However a more
careful examination will conclude that at present
this convergence has for the most part taken place
in the physical, data link and signalling layers. The
ubiquity of local loops connecting subscriber's
homes to a now digitised core network renders the
ideal avenue to also connect them with the Inter-
net. Advancements in quality of service mecha-
nisms in the Internet allow enterprises to use a
best-e€ort network to deliver their interoce voice
E-mail address: perdikea@telecom.ntua.gr (M.K. Perdikeas).
1389-1286/01/$ - see front matter Ó 2001 Elsevier Science B.V. All rights reserved.
PII: S 1 3 8 9 - 1 2 8 6 ( 0 0 ) 0 0 1 9 4 - 8
latency and jitter. In all these cases, one network's
service uses the physical infrastructure of another.
So, convergence at these levels can be viewed less
portentously as an instance of the encapsulating
ability of layered protocol architectures. Problems
at this level revolve around the nature of switching
that takes place and, in general, around quanti®-
able characteristics of the medium or of the in-
formation content. Given that lower layers are
usually generic, it is easier to achieve interworking
there than when trying to bridge the semantic gap
between di€erent service paradigms and applica-
tion-level concepts.
Two patterns of service provisioning can be
easily discerned. One that locates service logic at
the network's endpoints and treats the communi-
566 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
cations subnetwork as a generic ``get the bytes
across'' facility and a second one that assumes
impoverished terminals and locates service intelli-
gence inside the network. Using the SCN's
switching links to convey Internet trac is not
incompatible with the patterns of service provi-
sioning that apply in the Internet as Internet ser-
vices assume nothing of the intermediate nodes
save their ability to route packets correctly. Using
the Internet to o€er telephony services on the other
hand, is not so straightforward. For instance,
switch-based or intelligent network (IN)-based
telephony services rest on the existence of inter-
mediate nodes and their maintaining state infor-
mation for the duration of a call which is
something not granted for free in a connectionless
network.
Supplementary, switch-based services were the
®rst that exploited the fact that call state was
maintained by intermediary switches. The switch
thus became not only an instrument for steering
the modulated waveforms or, later, the digitised
frames but also the point of service provisioning. It
has to be noted at this point that the SCN concept
of signalling corresponds to a protocol pattern
which is not found in the Internet. Signalling is
terminated, examined and possibly operated upon
and ®nally reinstated at each intermediate node.
This allows partial, yet synchronised, images of a
call to be maintained by an array of network
switches. This is in sharp contrast with the Internet
where although the network protocol is indeed
terminated and reinstated at each router, it is at a
level of abstraction far below that of signalling and
has no service-related concepts built into it. Indeed
telephony signalling is modelled as an application
layer protocol in Internet applications. It is the
fact that an application-layer protocol is observed
by intermediate entities instead of ¯owing trans-
parently through them that has enabled the pro-
vision of switch-based and, later, IN-based services
and renders simple interworking schemes unable
to support a common service model for both In-
ternet and SCN-based telephony services.
Moreover, the Internet has given rise to services
that are incompatible with the model of telephony
services. The Web browsing and e-mail services are
just two examples and not among the most ex-
treme as even these services have some internal
degree of coherence as they share the concept of a
textual or audio-visual content that ¯ows from a
source to reach one or many destinations. Other
Internet service classes including, for instance,
object services that are made available through
distributed, programmatic interfaces are even
more divergent.
There are broad classes of problems that can be
de®ned in this context. The ®rst class is that of
service integration. It relates to the ability of the
same service to be o€ered by two networks using
the same service provisioning structure. Service
integration therefore seeks to integrate two origi-
nally distinct service models into a single one thus
facilitating seamless service provisioning across
di€erent networks. The second class of problems
relates to questions of service interworking.
The remainder of this paper is structured as
follows. Section 2 examines practices for service
integration for the particular class of telephony
services. Signalling interworking is shown to be
narrower in scope and a sort of preamble for the
support of a more thorough interworking at the
service level which is covered next. We then pro-
ceed to examine service interworking and describe
the Parlay approach which is the most compre-
hensive cross-network service framework stan-
dardised so far and we present an architecture that
utilises distributed object and mobile code tech-
nologies to compensate for certain drawbacks that
Parlay incurs.
2. Consolidation of the telephony service
The public switched telephone network (PSTN)
is geared towards the provision of the plain old
telephone service. When augmented with an ISDN
or ATM bearer capability, it can also be used
to deliver multimedia services like, for instance,
video-telephony or video-conferencing but even
these services can be viewed as enhanced versions
of telephony service as they share many concepts
with it. For the remainder of this paper when re-
ferring to telephony services, we will implicitly
include these services as well. It is this class of
services that characterises SCNs and whose
 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
seamless provisioning over packet-based networks
is sought. Since IN [3] is used to implement the
more control rich services (e.g., video-conference)
and a lot of supplementary features of others (e.g.,
three-party calls) the litmus test for uniform pro-
vision of telephony services over the Internet and
the PSTN is the ability to use the same IN super-
structure over both the networks. This will impose
a uniform service provisioning model and allow
telephony services to be o€ered in a truly consol-
idated manner.
Voice over Internet protocol (VoIP) refers to
the transmission of digitised voice as the payload
of Internet protocol (IP) packets. Before the ac-
tual transmission channel can be established
however, signalling between the two involved
parties must take place. Signalling must also be
employed during the call (e.g., for call transfer or
to invite another party) and for gracefully ter-
minating the connection and releasing any
reserved resources. Internet telephony signalling
has the same objectives as PSTN signalling
di€ering only in that it is an application layer
protocol and not an intrinsic capability of the
network infrastructure. This gives it great poten-
tial for evolvement (being more software-based)
but also detaches it from common patterns of
service provisioning in PSTN that rested on the
availability of network maintained call state
information.
2.1. Signalling interworking
Telephony services have the greatest internal
degree of coherence and so before attempting to
pursue any further-reaching interworking models
between Internet and SCN services, it is rational
that we should ®rst seek to de®ne a comprehensive
framework for cross-network provision of the
telephony service. Once the telephony service is
consolidated under a single service provisioning
model, broader schemes can be advanced. Prob-
lems of interworking in a more general context
may be deferred until the simpler to tackle cases
have been dealt with.
Internet has de®ned its own standards for tele-
phony signalling including ITU-T's H.323 suite
[12], MEGACO [9] and the lightweight IETF-
567
speci®ed session initiation protocol (SIP) [11].
There are thus three main architectures for Inter-
net telephony: the H.323, the MEGACO and the
SIP one, not excluding the possibility for hybrid
architectures. These di€er mainly in the nomen-
clature they use for the Internet-resident telephony
entities they de®ne (generically referred to in this
paper as ``soft switches''), the roles they assign to
them and their scope.
The purpose of this paper is not to provide a
detailed discussion of the characteristics of the
various VoIP architectures. Our aim is mainly to
show how these Internet telephony standards
®t into an overall architecture for service inter-
working. So we will brie¯y describe the architec-
ture of an H.323 Internet telephony system and
will underline its commonalities with other VoIP
architectures particularly with regard to how they
function as parts of a broader service interworking
framework.
The H.323 is an umbrella speci®cation that de-
scribes terminals and other entities that provide
multimedia communications services over packet-
based networks which may not provide a guaran-
teed quality of service. In general, H.323 provides
the foundation for audio, video and data com-
munications across the Internet. The scope of the
standard however, does not include the network
interface or the transport protocol used on the
network and so H.323 can be used in other net-
works as well. H.323 is broad in scope as it
addresses codec standards, multicast support,
bandwidth management and call control aspects.
Fig. 1 depicts the H.323 architecture and the main
entities that participate.
The role of the H.323 gateway is to re¯ect the
properties of one network's endpoint to another.
So, the H.323 gateway terminates and reinstates all
signalling layers at both sides (and mediates be-
tween them) and is responsible for translating be-
tween media transmission formats as well.
Naturally, the gateway is optional in cases where
terminals of the same type are used. The gate-
keeper is another optional entity but nevertheless
an important one when it is present. It provides
address translation, call control services and
bandwidth management for terminals and gate-
ways in its zone.
568 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578

Fig. 1. H.323 architecture and the main entities participating.

The MEGACO model is similar to that of H.323
although more modular and decomposed. SIP on
the other hand is a lightweight text-based protocol
for session initiation. Like H.323 it contains
primitives for call and connection control but of
reduced articulateness.
There are two conceptually di€erent approaches
to interwork between terminals of di€erent types
and/or located in di€erent networks which both
confusingly bear the name ``signalling interworking''.
When the same signalling standard is imposed but
di€erent network technologies are used, the upper
signalling layers are not terminated at the location
of a gateway but are instead conveyed transpar-
ently over di€erent lower layers (using layer ad-
aptation at a low level). On the other hand, when
two di€erent signalling architectures exist, signal-
ling mediation is necessary which means that the
gateway terminates all signalling layers and un-
dertakes a process of syntactic and semantic
translation between the forms and procedures used
in the one signalling protocol and those used in the
other (as the H.323 gateway does).
The ®rst approach is speci®ed by the SIGTRAN
working group of IETF and uses the Internet as a
trunk to convey the upper part of the signalling
system 7 (SS7) stack on top of it. It is depicted in
Fig. 2. The main concern here is SS7 connectivity

Fig. 2. Complete signalling encapsulation. Only the lowermost singling layers are terminated ± the others are conveyed transparently
as IP payloads. The same signalling protocol extends uninterrupted over both networks.
 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
and so this approach quali®es for a low layer
interworking scheme. Consequently, it is mostly
relevant to carriers who want to use a private IP
network to convey their SS7 trac. As an exam-
ple, there are at least two Internet drafts [10,14]
proposing to adapt the SS7 stack onto the Inter-
net. The ®rst provides an adaptation layer at
message transfer part 2 while the other at message
transfer part 3. This approach is also used in a
local scope between the MEGACO signalling
gateway and the MEGACO media gateway (which
is the actual signalling termination point). The
MEGACO signalling gateway does not mediate
between di€erent signalling protocols and only
takes care to convey Q.931 signalling transparently
over IP to the location of the media gateway which
is the real terminating point (and can be imple-
mented inside the terminals). Under this approach
(a terminal-implemented media gateway), we have
PSTN and Internet terminals using the same sig-
nalling standard.
While using the same signalling protocol over
both networks evades the more dicult problem
of signalling interworking at a higher layer, the
main problem with this approach is that on the
Internet side, PSTN signalling is completely en-
capsulated inside IP packets. Accordingly, on the
Internet side, all functionality and state informa-
tion are moved to the terminals. This is of course
consistent with the Internet approach but makes it
very dicult to deliver an integrated telephony
architecture particularly with respect to its ability
to exploit the IN infrastructure. For instance, if
one would try to use an existing IN infrastructure
Fig. 3. All signalling layers are terminated, the uppermost are converted to Internet telephony protocols.
569
with this architecture, while every public switch in
the PSTN would be able to support a service
switching function (SSF), similar capability would
not be found in the Internet side as all call state
information would be maintained in the end-user
terminals and not in network-resident entities. If
signalling information is observed only at the ter-
minal-located media gateway, then any e€ort to
extend IN's realm of control in the Internet is in-
validated. The other drawback of the previous
solution is that it ties Internet telephony with
PSTN signalling standards which is not appro-
priate as it fails to cater for the speci®c needs of
Internet telephony applications and forfeits their
evolutionary prospects due to their software
nature. Of course, these two drawbacks are not
intrinsic to the MEGACO architecture in general ±
they relate only to this particular deployment.
MEGACO is modular and can support con®gu-
rations which su€er from neither of these two
problems.
What the previous discussion achieved is to
make explicit that the target should be such that
each domain should get to keep its own standards
(thus not impeding evolution) and that Internet
telephony signalling should be observable at some
points. This brings us to the second approach, in
which PSTN signalling is terminated at the gate-
way and then converted to Internet telephony
protocols. This is re¯ected in Fig. 3 and adopted
by the H.323 gateway.
Under this approach, di€erent signalling stan-
dards are used in the two networks and explicit
interworking between them takes place. To satisfy
570 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
the second requirement (of some network-side
control of the exchanged signalling messages), it is
fortunate that all Internet signalling standards can
impose the requirement that at least call signalling
is routed through intermediate entities with the
sole intent that these entities maintain call state
information and allow a service logic to operate on
it according to the IN's listener±controller pattern.
Such modes of operation are commonly referred
to as ``gatekeeper routed signalling''. Once termi-
nals are instructed to have signalling routed
through network entities, maintenance of call state
by network entities is accommodated and appro-
priate entities that have access to enough runtime
signalling information can be allocated to perform
the SSF role according to the IN model. The IN
pattern of service provisioning and the role as-
sumed by the SSF are examined in Section 3.
2.2. IN-based service provisioning
The IN model of service provisioning utilises a
very common listener±controller pattern. IN ser-
vices are executed inside a service control function
(SCF). The SCF receives noti®cations from and
issues commands to the SSF using the intelligent
network application protocol (INAP) [13]. The
semantics of the messages exchanged over the
SCF±SSF interface reveal that an abstraction of
the underlying network resources is o€ered to the
SCF (and hence, to the services). This abstraction
takes the form of a basic call state model (BCSM)
which is implemented in the call control function
of the network switch. In IN capability set 2, there
is an even higher level abstraction o€ered on top of
the BCSM called the IN switch state model (IN-
SSM) but that does not alter the model of service
provisioning in any way. Commands issued by the
services towards the SSF are ultimately translated
into more ®ne-grained instructions used to mani-
pulate the BCSM and in the opposite direction
events originating from the BCSM are presented
to the service logic programs in the form of the
messages that are available at the SCF±SSF in-
terface [1]. It is the BCSM that detects basic call
and connection control events that can lead to the
invocation of IN service logic instances or should
be reported to active IN service logic instances and
it is also the BCSM that converts INAP instruc-
tions received from the SCF to call signalling
messages emitted from the switch.
In all the available Internet telephony signal-
ling standards, a call state model is either de®ned
explicitly or implicitly by the sequencing of mes-
sages and the response of the signalling endpoints
to them at di€erent times. So state models similar
to the BCSM can be identi®ed in the terminals
participating in an Internet telephony session. As
indicated in the previous section, by routing the
signalling through network-resident entities with
the sole purpose of allowing them to hold state
information, these state models can become sim-
ilar in functionality to the BCSM and become
IN's point of service provisioning for Internet tele-
phony services as well. What is needed is the
de®nition of the appropriate correspondence be-
tween these state models. As long as this corre-
spondence has been de®ned [8], H.323,
MEGACO and SIP soft switches can be viewed
for IN purposes as SSF entities and IN services
will simply observe underlying SSFs without be-
ing able to distinguish which of them are imple-
mented on top of ``real'' PSTN switches and
which on top of Internet soft switches. Note at
this point that H.323 or SIP call models can
support SSF emulation at either the BCSM or the
IN-SSM level. Call control signalling is routed
through these soft switches to allow state to be
maintained and operated upon by the SCF-lo-
cated service logic programs. Thus, in this man-
ner a single IN-based service provisioning
superstructure can be applied seamlessly to
underlying networks and the same service model
will be used to provide telephony services over
circuit- and packet-based networks. Fig. 4 depicts
this. A variety of interworking arrangements for
signalling may be present although not explicitly
indicated in order to avoid cluttering. The point
is that uniformity at the IN control level is not
inconsistent with a diverse set of signalling pro-
tocols employed underneath. Observe that the
SCF is common for both networks and that
SIGTRAN is used to transparently convey the
INAP ¯ows to the Internet-based soft switches
that support the SSF functionality.
 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
Fig. 4. Application of the IN service model over the Internet with the use of soft switches-routed signalling.
3. Service interworking
Service interworking is di€erent in its perception
from service integration in that it does not view
services as self-contained bodies of functionality
that are provided to end-users but as open pieces
of code, composed of, or having access to more
rudimentary facilities they might wish to share
with other services or reciprocally to leverage on
facilities provided by others. The PINT standard
[16] for the click-on services is one of the few in-
stances of service interworking standardised so far.
It allows a cgi-bin program triggered in response
to a user clicking on a hyperlink on his browser to
request from the PSTN the setting up of a call.
PINT assumes a third-party initiated call capa-
bility and can be used in connection with a SIP
architecture but it provides a very limited and
basically ``request-only'' handling of functionality
in the PSTN. In short, PINT amounts to little
more than an ad hoc arrangement and falls short
of providing a comprehensive framework for ser-
vice interworking.
3.1. Open service provisioning
The IN model for a service is one of an opaque
body of code that manipulates call processing on a
set of subordinate switches using a powerful yet
571
semantically narrow interface. The scope of service
provisioning is local (i.e., it applies at the origi-
nating or the terminating exchange) and the ap-
erture of visibility provided to the services by the
switch is limited and requiring transactions to be
established through complex protocol stacks. An
SS7 network is used to convey the INAP protocol
¯ows that are established between the various IN
functional entities, the most important of which is
the SCF±SSF ¯ow.
IN is said to be closed in the sense that although
an event noti®cation and enforcement point is
made available at the SSF interface, that interface
cannot be exploited by other service providers.
Because of these restrictions, IN's full potential is
not reached and it itself comes close to being
simply a more ¯exible implementation alternative
compared to switch-based services.
In a world where a variety of terminals is
available, where service subscribers want unim-
peded personal and terminal mobility and where a
multitude of event sources and possible handles
for action are available, such ``con®ned'' service
models are no longer appropriate. The Internet
has brought with it a plethora of services with
vastly divergent characteristics compared with the
relative homogeneity that characterises PSTN
services. In any intended service interworking
scheme, how will appropriate metaphors be sought
572 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
to allow interaction between di€erent service par-
adigms?
Distributed object technologies and the re-
placement of message-based protocols with ap-
plication programming interfaces (APIs) o€er a
way out of many of the problems impeding ser-
vice interworking. Essentially the goal is to create
a uniform service space or layer where services
can be executed. Execution of a service entails the
availability of programmatic hooks underneath
and of noti®cation points so that a service can be
kept informed of events of interest and synchro-
nise its execution with their occurrences (see [4]
for a typical approach). Therefore the IN listen-
er±controller pattern where a physical entity (in
IN, a switch) exposes part of its functionality to
be controlled by a remotely located entity which
it also undertakes to inform of events for which
the latter has registered interest, can be extended
to arbitrary services. Given the diculty in ab-
stracting from the diverse set of services that can
be found (or can be introduced) in a converged
Internet±PSTN environment, this pattern is
powerful and possibly the most generic scheme
®tting all services. Essentially the application of
this pattern across services coming from di€erent
network technologies introduces a separation
between the controllable and controlling parts. In
a second step, the application of distributed ob-
ject technologies enables the spatial separation of
the two parts and it further allows this to happen
in a location-transparent manner. This could not
happen with SS7 as it does not display the
properties of a distributed processing environ-
ment (DPE).
A further bene®t accruing from the application
of distributed object technologies is that through
the introduction of a common object model, many
inconsistencies that would have otherwise ham-
pered such an interworking e€ort are removed.
Such inconsistencies could have been related to
di€erent wire formats (marshalling speci®cations
and procedures, data structure de®nitions), direc-
tory mechanisms and life cycle operations. Also, it
is much easier to guarantee compliance with an
API than it is with a protocol (in DPE imple-
mentations, this is simply an instance of runtime
type checking which is done for free).
An API-based approach has been adopted by
the Parlay group [15] in its speci®cation for the
various services it deals with. The goal in Parlay is
to de®ne open, object-oriented interfaces that will
expose network functionality to edge-of-network's
applications. While IN simply disentangled the
service switching from the service control function,
Parlay moves a step further by allowing them to be
undertaken by di€erent actors. By providing edge-
of-network application developers with the ap-
propriate interfaces with which to exert control
inside the network, the task of service creation
becomes no di€erent than that of application de-
velopment. Moreover, the same tools and meth-
odologies can be used in both cases as said
interfaces are based on distributed processing
technologies and can be readily mapped on the
more popular relative standards including the
common object request broker architecture
(CORBA), the distributed component object
model (DCOM) and Java's remote method invo-
cation (RMI). In this manner, a resource pool that
was yet untapped for network operators ± that of
application programmers ± can be utilised for the
purposes of network services development thus
furthering the convergence between the two in-
dustries in the aspects of the paradigms of soft-
ware development that are used and the tools,
processes and methodologies that are involved.
Alternatively, a network operator can outsource
the task of writing services for his network and
concentrate on his core competencies. Knowledge
of complex protocol stacks and esoteric features
and procedures used in telecommunications ceases
to be a prerequisite for writing services and an
understanding of the semantics of an API is all
that is required. The relative coarse granularity of
the Parlay APIs further contributes to both the
ease with which to build services using them and
the ability of the network to protect its own in-
tegrity (which might have been more easily com-
promised if lower level and more elaborate handles
were exported). As a matter of fact, establishing
that access by application vendors to the net-
work's functionality will not compromise its in-
tegrity is also the responsibility of appropriate
horizontal authentication and authorisation in-
terfaces.
 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
3.2. The Parlay interfaces
The Parlay speci®cations (now in version 2.1)
de®ne APIs designed to enable network operators
and independent software vendors to provide ser-
vices across Internet, PSTN and wireless networks.
As such, the scope of the speci®cations is quite
broad. The general framework for the Parlay ser-
vices and the business model it implies can be
represented by the ternary relationship depicted in
Fig. 5(b).
As can be seen from that ®gure, the IN does not
modify the business model of a simple subscriber±
network provider relationship as the service provi-
sioning function remains within the realm of the
network operator. It is the externalisation of the
``C'' interface that succeeds in exporting this func-
tionality in an open competitive market of many
service providers. In doing so, it enables a subscriber
to independently modify his relationship with a
number of service providers while attached to the
same network operator. Clearly, this creates a more
¯uid market than the mere ability of a customer to
subscribe to the additional service features that his
carrier introduces from time to time.
There are two more reasons that attest to Par-
lay's superiority over more closed models of ser-
vice provisioning. The ®rst is that in contrast to
IN, Parlay's focus is not only on switching systems
but on a broader set of equipment that can be
described as ``network resident''. The relative
Fig. 5. The IN (I) and the Parlay (II) business models.
573
speci®cations include APIs for, among others, call
control, messaging, user interfacing (in the IN in-
telligent peripheral sense), connectivity manage-
ment and mobility management. A short
description of the most important of these APIs
follows.
The call control speci®cation de®nes a generic
call control service, an INAP-1 call control service,
an enhanced call control service and multimedia
and conferencing call control services. The generic
service provides the more rudimentary form of a
call control service. It is based around a third-
party model, which allows calls to be instantiated
from the network and routed through the network.
The intent is to support enough functionality to
allow call routing and call management for con-
temporaneous services. On top of this generic call
control service, the INAP-1 call control services
provides additional functionality resulting in a call
state model similar to that of IN capability set 1.
More sophisticated applications can thus be de-
veloped although full leg management is not sup-
ported. The enhanced call control service adds leg
management to the capabilities o€ered by the ge-
neric call control service. It also adds some load
control features. The multimedia, conferencing
and multimedia conferencing call control services
extend the enhanced call control service to allow
control over the media channels associated with
the legs in a multimedia call, creation of confer-
ences, moving of legs between sub-conferences,
574 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
Fig. 6. Parlay is broader in scope but uses the same listener±controller model as IN.
merging of subconferences and handling of mul-
timedia conference policies.
The implementation of these call control APIs
will naturally have to rely on concrete call control
technologies. However, the APIs themselves are
cross-network and technology independent mean-
ing that the scope of service provisioning extends
uninterrupted over both circuit-switched and
packet-based networks. Interworking mechanisms
such as those described in previous sections will
have to be used but this is a concern of the net-
work provider and not of the application devel-
oper that uses the Parlay interfaces. From the
point of view of the application, di€erences be-
tween underlying network technologies are not
perceived thus truly imposing an uni®ed call con-
trol model. Fig. 6(b) depicts in more detail the
available Parlay APIs on the network side and
their relationships.
Note that according to Parlay, edge-of-network
applications should also provide some interfaces of
their own which are used by the network-located
service components as callbacks for noti®cations,
event reports, etc. The applications interact with
the Parlay framework by providing it with the
pointers to those callback methods. This corre-
sponds to the well known listener±controller pat-
tern by which an object registers itself as a listener
to an event source so that it can receive noti®ca-
tions. The controller can then use the hooks pro-
vided by the event source to e€ect some behaviour.
The relationship between a Parlay application and
the Parlay service components is thus markedly
similar to the relationship between the service
switching and the service control functions in IN
only that here methods are used instead of pro-
tocols and the services have a much broader scope
of control. Since the APIs are provided over a
distributed infrastructure this also carries with it
the additional bene®ts of more ¯exible service de-
ployment and of a laxer binding between the ac-
tual physical systems.
4. A Parlay-based service architecture
The approach adopted by Parlay re¯ects the
understanding that services are ever moving out-
 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
wards. From switches to service control points and
now, to enterprise servers at the edge of the net-
work. There are, however, two issues related to
this locating of functionality at the network's edge.
One has to do with the possible performance
degradation as services reside at the network's
periphery connected with it through a best-e€ort
IP network (commercial DPEs run over IP). The
other relates with the support of personal mobility
and the ability of a user to register for a subscribed
service at any terminal in the network, provided
that the terminal has the required capabilities.
Personal mobility provides the user with a single
point of contact for the various modes of com-
munication and allows him to enjoy the same
portfolio of services regardless of the network in
which he is roaming. The separation imposed by
Parlay between the roles of the network and the
service provider makes functional aspects of per-
sonal mobility easier to support as the roaming of
a user a€ects the network provider he uses and can
be tackled independently from the issue of unin-
terrupted service provisioning over multiple net-
work providers. The localisation of services,
however, at the edge of the network makes it dif-
®cult to guarantee optimal access to services or to
integrate Parlay-type service provisioning with
hierarchical, tree-like, network-wide models of
service provisioning and deployment. The problem
is even more evident when considering the hand-
ling of mobility management data where such a
hierarchical distribution and replication is widely
practised. Enterprise-held data, although easily
accessible by edge-of network provided services, is
not easily integrated into such distribution chan-
nels. The need therefore arises to reconcile the
Parlay model with patterns of service provisioning
which view the services and their data as ubiqui-
tously available throughout the network.
One of the main successes of Parlay is that it
allows fully functional service provisioning while
making the coupling between service providers and
network operators very loose. This property must
be respected by any architecture aiming at non-
functional improvements. What is needed is the
ability to keep service creation at the edge of the
network and maintain the runtime provisioning of
services from inside the network without burden-
575
ing the operator±service provider relationship with
any additional semantics. Attaching protocols and
runtime associations (in addition to the already
de®ned APIs) to it will back®re on Parlay's main
goal. It should be intuitive that in order to tackle
this problem and still observe the aforementioned
requirement only generic, middleware-based en-
hancements ought to be sought. We hold that
mobile code technologies can be employed to that
end [2]. A mobile code infrastructure is generic in
purpose as it o€ers a mere ability to transfer
software objects. Being generic, the installation of
appropriate middleware between the service pro-
viders and the network operator will still maintain
the looseness of their coupling. A service provider
on the other hand will be granted the ability to
inject his services into the operator's core network.
The business model of this relationship is more
involved than that, of course, but conceptually it is
a lease model whereby the service provider pays
for the processing power and communication re-
sources his services use while executing in the
network operator's space.
The STARLITE project [5,18] aims at an ar-
chitecture that can deliver the full functional po-
tential of Parlay while also compensating for its
identi®ed drawbacks. The approach adopted in
STARLITE is to leverage on mobile code capa-
bilities as suggested above. Viewing services as
mobile code objects leads to an important di€er-
entiation with the Parlay model. The view that
Parlay takes of the application is that of an opaque
piece of code. This is why the speci®cation e€ort
focuses narrowly on the de®nition of a set of APIs
in order to grant enterprise-resident applications
access to network-centric functionality. Network
services in the STARLITE system are not, how-
ever, opaque pieces of code executed at the net-
work's periphery. Since STARLITE services are
mobile objects, a need arises for an underlying
architecture that can provide structured access,
deployment and container-related operations for
its services; more needs to be known about the
services that make the Parlay calls to the network
if management and lifecycle operations on them
are to be handled eciently. Note here that since
commercially available mobile code platforms are
Java based, services are also implemented in Java.
576 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
What is necessary is the de®nition of a component
object model for Parlay services. Once such model
is available, any supporting architecture will be
able to transparently take care of issues like rep-
lication, migration, activation and passivation.
Services will be then executed in specialised con-
tainer environments where they will enjoy the
services mentioned above plus access to the Parlay
interfaces exposed by an underlying network. The
described system essentially constitutes a three-tier
architecture with the STARLITE network being
the middle tier. Thus, the typical two-tier Parlay
architecture is augmented with an additional
mobile code-based tier that interposes itself be-
tween the network and the service providers
bringing with it the operational enhancements
identi®ed above. However, this tier is transparent
for both the network and the services themselves
who maintain the illusion that they are directly
Fig. 7. A Parlay-based architecture.
engaged in communication with each other when
in fact the interposed middleware mediates method
invocations between the two. Thus, the functional
association between the services and the network is
not burdened with additional relationships and the
service provider and network operator can still be
two independent actors. The STARLITE network
is responsible for brokeraging between the two.
This is depicted in Fig. 7. An added bene®t of the
use of the execution contexts or containers as de-
picted in Fig. 7 is that by supporting proxies for
the actual network-side Parlay objects, services can
be pure Java objects delegating the responsibility
of using the appropriate middleware technology
for communication with the Parlay components
(DCOM, CORBA or RMI) to the containers. A
common object model de®ned in Parlay is used for
all underlying equipment at the DPE middleware
level. Similarly, a common Java object model is
 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
used at the proxy level for all network resources
that are represented facilitating cross-network
service creation.
The middle tier provides the appropriate execu-
tion environments into which services developed by
independent software vendors will execute. These
execution environments can be powerful enterprise
servers allowing further economies of scale to de-
velop as hundreds of services will be executed there.
Service providers will still have the option to keep
service execution within their premises as the Par-
lay APIs are implemented over a DPE making the
actual runtime location of the services insigni®cant.
For services, however, that impose rigorous stan-
dards of performance, use of the operator-provided
execution environments can be obtained. From the
point of view of the network provider on the other
hand, no additional risk is incurred due to the co-
location of externally developed services with crit-
ical network equipment as exactly the same remote
interfaces are used in both cases.
Once services are injected inside the network,
runtime mechanisms can decide transparently as to
their optimal location or to facilitate access to the
replicated data they may require. Possible move-
ment of services from one execution context to
another will be unobserved by the network oper-
ator as it will be taken care of by the mobile code
middleware. Mobile code middleware is the ideal
means to ensure that the network operator will
remain oblivious to performance-driven optimisa-
tions and that no additional functional associa-
tions are introduced between the network and the
service provider. Relative, commercially available
middleware (e.g., the Grasshopper platform [17])
transport both code and transient service state
information in a generic manner allowing unim-
peded service logic mobility without the need for
any service-speci®c provisions. Services can roam
between the network operator-provided execution
contexts or even between execution contexts pro-
vided by di€erent network operators (possible
following mobile users) without the latter per-
ceiving it. Code migrating operations may be
prompted either by the need to optimise load
balancing in the use of both processing and com-
munication resources [6] or in response to personal
mobility events [7].
577
Functionally, the architecture depicted in Fig. 7
preserves all of Parlay's bene®ts while annulling
some of its more awkward implementation charac-
teristics. For the middleware infrastructure in the
middle tier to be able to undertake the functions
necessary in the life cycle management of the mobile
code it hosts, and still support the ability of the
services (and of the network code on the other side)
to view only Parlay APIs, certain interfaces have to
be de®ned separating the views that the network
provider, the service provider and the infrastructure
have of the services. In our architecture, we have
de®ned appropriate interfaces in Java to allow this
separation of views to take e€ect. Services being
Java objects implement all the relative interfaces
and so polymorphically expose di€erent facets to
di€erent components in their environment. The
service distribution manager has access to migra-
tion-related methods while the execution contexts
are able to invoke serialisation and de-serialisation
methods on services in order to move inactive ser-
vices from memory into persistent storage and then
back into memory when an incoming request
arrives. Finally, Parlay components on the ®rst-tier
see only Parlay-de®ned methods corresponding to
the services' callback interfaces.
5. Conclusions
The real breakthrough in the Parlay approach is
that of allowing the handling of an asynchronous
telecommunications event to be carried out in an
execution context outside the con®nes of the net-
work, in an area outside the administrative or
management responsibility of the network opera-
tor. For the ®rst time this makes it possible for a
thread of control that was spawned inside a tele-
communications network to enter into processing
at the public Internet. This is the fundamental
achievement. Once this is allowed, all other bene-
®ts of Parlay (e.g., those related to cross-network
creation of services) accrue naturally and cost-free
simply by virtue of the fact that code now executes
on the Internet side and can swiftly take advantage
of APIs that are made available there and which
are typically less rigidly standardised and usually
destined to span a shorter life cycle.
578 M.K. Perdikeas, I.S. Venieris / Computer Networks 35 (2001) 565±578
The locating of services outside the network sits
oddly however with standardised approaches for
the location, replication and in general, handling
of mobility data or service instances across care-
fully de®ned hierarchies over wide geographical
areas. The prospect of vastly personalised services
(opened up by the much more diversi®ed envi-
ronment in which Parlay services operate) em-
phasises this shortcoming. Mobile code technology
can be used on a middleware basis to o€er a
platform for data or code mobility that is generic
and thus introduces no associations that could
back®re on the success of the primary goal pur-
sued by Parlay, namely that of separating the role
of the service provider from that of the network
administrator. The IST STARLITE project in
which the authors participate has undertaken the
design and implementation of such an architec-
ture.
Acknowledgements
This work has been partially funded by the EU
IST project STARLITE and the Greek GSRT
project 99E160.
References
[1] I. Venieris, H. Hussmann (Eds.), Intelligent Broadband
Networks, Wiley, New York, 1998.
[2] I. Venieris, F. Zizza, T. Magedanz (Eds.), Object Oriented
Software Technologies in Telecommunications, Wiley,
New York, 2000.
[3] T. Magedanz, R. Popescu-Zeletin, Intelligent Networks ±
Basic Technology Standards and Evolution, International
Thomson Computer Press, London, 1996.
[4] C. Gbaguidi et al., Integration of Internet and telecommu-
nications an architecture for hybrid services, IEEE Journal
on Selected Areas in Communications 17 (9) 1563±1579.
[5] F. Chatzipapadopoulos et al., Harmonised Internet and
PSTN service provisioning, in: Special Issue on Mobile
Agents for Telecommunication Applications, Computer
Communications Journal 23 (8) (2000) 731±739.
[6] F. Chatzipapadopoulos et al., Mobile agent and CORBA
technologies in the broadband intelligent network, IEEE
Communications Magazine 38 (6) (2000) 116±124.
[7] M. Breugst et al., Impacts of mobile agent technology on
mobile communications system evolution, IEEE Personal
Communication Magazine 5 (4) (1998).
[8] D. Ackermann, J. Chapron, Is the IN call model still valid
for new network technologies? in: Proceedings of the ICIN
2000, Sixth International Conference on Intelligence in
Networks, Bordaux, France, 2000.
[9] F. Cuervo et al., Megaco Protocol version 0.8, IETF RFC
2885.
[10] G. Sidebottom et al., SS7 MTP3-User Adaptation Layer
(M3UA), IETF draft.
[11] M. Handley et al., SIP: Session Initiation Protocol, IETF
draft.
[12] ITU-T Rec. H.323, Packet-based Multimedia Communi-
cations Systems.
[13] ITU-T Rec. Q.1224, Distributed Functional Plane for
Intelligent Network Capability Set 2.
[14] K. Morneault et al., SS7 MTP2-User Adaptation Layer,
IETF draft.
[15] Parlay APIs 2.1, Generic Call Control Service Interfaces,
available from www.parlay.org.
[16] S. Petrack et al., The PINT Service Protocol: Extensions to
SIP and SDP for IP Access to Telephone Call Services,
IETF RFC 2848.
[17] Grasshopper Agent Platform, http://www.ikv.de/products/
grasshopper.
[18] Services Technologies and Architectures Enabling Internet
and PSTN Integration, http://www.ist-starlite.net/.
Menelaos K. Perdikeas received the Dipl. -Ing. degree (magna
cum laude) from the Computer and Informatics Engineering
Department of the University of Patras, Greece, in 1997. He is
currently a Ph.D. candidate at the Telecommunications Labo-
ratory of the National Technical University of Athens, Greece.
His research interests include distributed and mobile object
technologies, Intelligent Networks and telecommunications
service engineering. Mr. Perdikeas is a member of the Technical
Chamber of Greece.
Iakovos S. Venieris was born in Naxos, Greece, on 3 March
1965. He received the Dipl. -Ing. degree from the University of
Patras, Patras, Greece in 1988, and the Ph.D. degree from the
National Technical University of Athens (NTUA), Athens,
Greece, in 1990, all in electrical and computer engineering. He is
currently an Associate Professor in the Electrical and Computer
Engineering Department of NTUA. His research interests are
in the ®elds of B-ISDN, intelligent networks, Internet, distrib-
uted processing, service and network control, and performance
evaluation. He has several publications in the above areas. Dr.
Venieris has received several national and international awards
for academic achievement. He has been exposed to standardi-
sation body work and has contributed to ETSI and ITU-T. He
has participated in several European Union and national pro-
jects. He is a member of IEEE and the Technical Chamber of
Greece.