=Paper=
{{Paper
|id=Vol-61/paper-4
|storemode=property
|title=Combining Open APIS (Parlay/JAIN) & Software Agents for Next Generation Mobile Services
|pdfUrl=https://ceur-ws.org/Vol-61/paper4.pdf
|volume=Vol-61
|dblpUrl=https://dblp.org/rec/conf/mservices/RautelaMK02
}}
==Combining Open APIS (Parlay/JAIN) & Software Agents for Next Generation Mobile Services==
https://ceur-ws.org/Vol-61/paper4.pdf
Combining Open APIs(Parlay/JAIN) & Software Agents for Next
Generation Mobile Services
Deepak Rautela ¹, Gert Markwardt ², and Ahmed Kamel ¹
¹ North Dakota State University, Computer Science Department, IACC 258,
Fargo, ND 58105, USA
{ Deepak.Rautela, Ahmed.Kamel }@ndsu.nodak.edu
² SIEMENS AG, Information and Communication Mobile, Siemensdamm 50,
Berlin 13629, Germany
gert.markwardt@bln1.siemens.de
Abstract. The Telecom/Wireless world is rich in network capabilities and is trusted by the consumer
to provide reliable, stable services. The IT world is rich in applications and developers. The strengths
of these two domains could be combined and new services can be developed utilizing underlying
network capabilities. The Parlay Group defines a set of Open APIs that support applications external
to the secure network space. The Java APIs for Integrated Networks Community is defining a Java
version of the Parlay API. The above scenario will provide wireless application developers to
produce new and exciting applications for end users. Wireless networks have less bandwidth and
more latency compared to wired networks. In this regard Mobile Software Agents can provide better
support for wireless devices. In this paper we have researched the feasibility of the above architecture
where applications developed using Open APIs like Parlay/JAIN can utilize the advantages of
Software Agents.
1 Introduction
In this section we give a brief introduction about the paper which is divided into two parts. The first
part is a general description of Software Agents and Open APIs (Parlay/JAIN) for Next Generation
Networks. The second part is a brief description of the architecture that we propose in this paper.
1.1 Problem
The second-generation mobile communications technology in use today has been “voice centric”
offering the benefits of person-to-person speech communication anytime, anywhere. The voice centric
feature is offered by circuit switched technology using the “numbering” as an addressing and an
identification of end users. The global explosion in Internet popularity shows that the users anticipate
the discovery of multimedia communications and access to instant information both in their personal
and business lives. Thus the major source of revenue resides primarily in the revolution in the service
application domain. The introduction and usage of the huge numbers of new services imply the need
for a general mechanism for providing these services into the networks. Fast and easy development,
quick and cost effective deployment of these services will be essential to accelerate the business behind
these services. The major hurdle in the development of these services is that traditionally all the
services have been developed and hosted by the network operators themselves within their networks
using proprietary technologies. A service running in one operator’s domain may not essentially be
portable to another network.
1.2 Solution
Parlay & JAIN are two such industry initiatives which are technology and network independent APIs.
The Parlay/JAIN API are open and technology-independent, so that the widest possible range of market
players e.g. Independent Software Vendors (ISVs) may develop and offer advanced
telecommunication/wireless/IP services. The API is intended to be simple to use and extensible, so that
it can be applied to (and between) different types of networks and services. The Parlay/JAIN API offers
a safe and secure access of third party applications into an operator’s network as it acts similar to a
firewall. As the Parlay API has been adopted for the Open Service Access (OSA) specification of the
Third Generation partnership project (3GPP) UMTS specifications, it is expected that Parlay will be
1
used on a wide scale in the vast majority of 3G mobile networks. Third party application developers
can use these API’s to develop Telecom/ Wireless/ IP applications without having to worry about how
the network actually works. Parlay and JAIN APIs will bring lots of new applications for wireless,
wireline(PSTN) and IP industry. Software Agents is a new paradigm in present day computing and its
convergence with Parlay/JAIN will make Telecom applications significantly more smart, autonomous
and mobile.
2 Open APIs (Parlay/JAIN)
2.1 Introduction
In this section we discuss how Open APIs will play an important role in Next Generation Networks
(NGN). In today's networks, applications and services are part of the network operator's domain. This
network centric approach was excellent for simple mass-market applications. The Telco world can be
viewed as a layered structure in three planes:
Application
Plane Applications
Service Telco Business Domain
Plane Service Components
Core Networks & Networks
Network Control
Wireline Wireless IP
Figure 1 : Traditional Architecture
Traditionally, network services have been deployed within the network and network integrity,
performance and security where the main concern of the operator. . But with technology and market
advances and the emergence of mobility and IP a solution is needed that combines the benefits of the
network centric approach of scalability and reliability with the creativity and power of the IT industry.
This means it should be possible for the applications to be built, tested and operated by enterprises
outside network domain [1]. This is achieved with a programming interface which allows applications
to access the functions of the network in a secure way. A new business model has appeared in this
domain. “This model involves opening up networks to third party application developers. [2] In this
model the network provides services like call control, addressing, location, billing and notification.
Third party applications access these network services. The biggest hurdle in this approach is to allow
third party applications to access the network while protecting the network from harm. Two main
industry initiatives have emerged in this field: these are the Parlay consortium and the Java APIs for
Integrated Networks (JAIN). SUN has also released a JAVA technology version of Parlay 1.2 called
JAIN Parlay API specification.
Application Plane 3rd Party Application
Applications Developers
Parlay/JAIN Open Network API
Service Plane Service Components
Telco Business Domain
Core Networks & Networks
Network Control
Wireline Wireless IP
Figure 2 : New Architecture
2
2.2 Parlay
In March 1998 BT, Microsoft, Nortel, Siemens & Ulticom founded the Parlay Group
(http://www.parlay.org). The goal of the Parlay Group is to define a set of APIs that support
applications external to the secure network operator space so that the applications can have real-time
control of network resources. The Parlay concept originated from an open and technology independent
approach. It is designed to enable carriers, independent software vendors or third party service
providers to write applications providing services across the Internet, wireless, and wireline networks
[1]. The Parlay specification is a high level specification written in UML. The API defines object-
oriented interfaces on both the network and client application sides in the form of network interfaces
and client application callback interfaces. Callback interfaces allow the server to interact with the
client.
“The Parlay API defines a set of technology-independent interfaces that specify methods, events,
parameters, and their semantics to allow external (untrusted third parties) and internal (traditional
network operators) application creators the control over core network resources and capabilities”.[3]
Through the Third Generation Partnership Project 3GPP (http://www.3gpp.org ) and OSA Application
Programming Interface (API), the Parlay API has been introduced into UMTS, the next generation of
mobile networks.
2.3 Architecture
From the functional point of view the Parlay Gateway consists of two main parts
• Parlay Framework.
• Parlay Network Services.
Application
Parlay Client
Parlay API
Parlay Network Framework
Services Function
Parlay Gateway
Telecom Network
Figure 3 : Parlay Architecture
2.3.1 Parlay Framework Services
The Framework is the central part of Parlay Gateway. It provides functionality in the form of
framework interfaces which are related to different management aspects. e.g. gateway access, security,
network integrity and load management.
3
2.3.2 Parlay Network Services
The Parlay network services provide the intrinsic network related service functionality for the clients
(as opposed to the Parlay framework which provides the administrative part of the Parlay
functionality). The network services include1:
• Generic Call Control Service.
• User Interaction Service.
• Mobility management services
User Location
User Location Camel
User Location Emergency
User Status
2.4 JAIN: Java APIs for Integrated Networks
The purpose of JAIN technology is the integration of the Internet and the Intelligent Network, referred
to as Integrated networks(http://java.sun.com/products/jain). JAIN brings service portability,
convergence, and secure network access to telephony and Internet networks [1]. It will alter the current
business structure of these networks as follows
• Service Portability: It is difficult to develop, maintain and market new services because of
proprietary interfaces. With JAIN, proprietary interfaces are reshaped to uniform Java
interfaces to develop truly portable applications.
• Network Convergence: JAIN allows applications and services to run on PSTN, packet (e.g.
IP or ATM) and wireless networks.
• Secure Network Access: Applications residing outside the network can directly access
network resources and devices.
The JAIN initiative takes the telecommunications/Internet market from many proprietary closed
systems to single open environment able to host a large variety of services. Java and JAIN will allow
carriers to extend the services and make them more feature rich. The JAIN specification is divided
between two groups:
• Protocol Expert Group(PEG), defining JAVA APIs to TCAP, OA&M, ISUP, MAP, SIP,
MGCP, H.323, and INAP protocols.
• Application Expert Group (AEG), defining APIs to Call Control (JAIN Call Control) and
Service Logic Execution Environment (JAIN SLEE) and the JAIN Parlay, access to secure
networks[4].
2.5 JAIN Parlay API
The JAIN Parlay API specification is a JAVA technology version of the Parlay 1.2 specification as
defined by the Parlay Working Group. Parlay itself defines a technology independent API in the form
of Unified Modeling Language(UML) and the distribution technologies CORBA and DCOM. The
application developer is free to build programs using JAVA, C++, Visual C++ and Visual Basic. The
aim of JAIN Parlay is to define a Java language version of the Parlay API using the best principles of
Java technology while maintaining the integrity of the original Parlay API[1]. One of the benefits of
defining a JAIN version of Parlay is to exploit the benefits of Java technology such as service
portability, JVM reliability, ease of programmability and component framework such as Java Beans
and Enterprise Java Beans. By using Java, the job of building a Parlay Gateway can be made easier
through the use and reuse of other JAIN components such as JCC, JSLEE, and PEG protocols[5].
2.5.1 Architecture of the JAIN Parlay API specification
The JAIN Parlay API like its parent Parlay specification is object-oriented and consists of two
categories of interfaces:
• Service Interfaces: These offer applications access to a range of network capabilities.
1
Other services like Multiparty Call Control, DataSession & Terminal Capabilities are also available.
4
• Framework Interfaces: These provide ‘surround’ capabilities necessary for the Service
Interfaces to be open, secure, resilient and manageable.
The services are assumed to be co-located with the framework. They are also considered trusted, such
that once an application has been authorised to use particular services by the framework, then no
further authorisation is required when those services are used. In some scenarios, however, additional
authentication may be required for the application to use certain service features.
3 Software Agents
3.1 Introduction
Software agents comprise a new area of research and is being embedded in modern computing systems.
The term “agent” is difficult to define, software agents are programs that assist people and act on their
behalf and function by allowing people to delegate work to them [6]. Agents are often described as
entities with attributes considered useful in a particular domain. This is the case with intelligent agents,
where agents are seen as entities that emulate mental processes or simulate rational behavior; personal
assistant agents, where agents are entities that help users perform a task; mobile agents, where entities
that are able to roam networking environments to fulfill their goals; information agents, where agents
filter and coherently organize unrelated and scattered data; and autonomous agents, where agents are
able to accomplish unsupervised actions[7]. According to one of the most widely accepted definitions,
given by Wooldridge and Jennings in one of their influencing journal papers, an agent is a self-
contained problem solving system capable of autonomous reactive, pro-active, social-behavior.
Agents function by allowing people to delegate work to them and assist them by acting on their behalf.
An Agent is
i) Autonomous - acts without human intervention,
ii) social - collaborates with other agents via structured messages,
iii) reactive – responds to environmental changes,
iv) proactive – acts to achieve goals.
3.2 Parlay/JAIN applications using Software Agent capabilities
The following is a set of potential applications combining the use of software agent capabilities and
Parlay/JAIN:
• Shopping
A commercial transaction may require real-time access to remote resources, such as stock quotes
and perhaps even negotiation between involved parties. The user can give the shopping agent in its
wireless device all the specification (product information, price range) [8]. This agent moves to
Agent Server or WWW and there it negotiates with other agents to get the best deal for its creator.
• Personal Assistant
Mobile agents ability to execute on remote hosts makes them suitable as assistants performing
tasks in the network on behalf of their creators. Since Software Agents can operate independently
of their limited network connectivity, their creators can even turn off their wireless devices.
• Location specific services
Applications specific to User Location can be developed using Parlay/JAIN User Location Camel
Services and Software Agents can help the application to be much more autonomous (user
friendly) and get information which is real time and relevant.
• Information and Data Seekers
A user is looking for some information. He/she delegates that task to the client agent in the mobile
device. The client agent moves to the agent server where it meets other agents capable for
performing the required task and thus delegates the task of searching to them. The user can switch
off their mobile device and the next time he/she starts the device the agent would be waiting with
the required information.
5
• Personal Assistant
The use of software agents is limited not only to mobile agents; Agents can also act as 24*7
Technical support assistants ex. chatter bots. We can have a chatterbot like ALICE
(http://alicebot.org) on the server and user chatting (voice) with it explaining his/her problem and
the intelligent agent (programmed in Artificial Intelligence Markup Language “AIML”) further
delegating that task to other software agents and thus helping with most appropriate solution.
• Monitoring and Notification
An agent can monitor a given information source and it can be dispatched to wait for certain kinds
of information to become available. Information such as news, weather information, stock quotes
can be sent to wireless users as SMS.
4 Implementation
The second part of this paper is the implementation of a Travel Guide Service which was developed at
SIEMENS AG, ICM, Berlin, Germany.
4.1 Introduction
The SIEMENS Parlay/OSA Gateway (http://www.siemens.com/parlay )is a Service Capability Server
which enables Client Applications to make use of the core network’s functionality through open
standard interface. The Gateway’s main purpose is to provide interfaces towards external Client
Applications which facilitate the access to Service capabilities of the core networks. The Parlay/OSA
APIs enables network operators, service providers, and the general software developers to integrate
telecommunications/wireless capability into IT software, taking advantage of information that is
private to the end user. The Travel Guide Service is one such example of the above scenario which
demonstrates the usage of the Parlay/OSA by directly connecting to SIEMENS Parlay Gateway.
4.2 Travel Guide Service
The Travel Guide service is intended for all travellers who are interested in location-dependent
information about various topics like traffic jams, cultural events, restaurants, etc. Each user can
activate the guide by sending an SMS to the server thus registering for the service along the way. The
service will then continuously check the user’s location. Whenever there is information for the current
Cell ID stored in the Info database it is sent to the user via SMS. The user can also get information
regarding current news, weather, stock prices etc. The Travel Guide is based on the Parlay/OSA
Framework, User Location CAMEL, User Interaction & Content Based Charging services. The
Travel Guide Application was demonstrated at Parlay Group Open Member Meeting, Munich,
Germany (September 12 – 14, 2001). http://www.parlay.org
4.2.1 Typical Scenario
A user is starting his journey from Berlin to Munich. Before starting the journey he activates the Travel
Guide Service by sending SMS “1” to the Service Phone number. When the Client Application
receives SMS it checks the user’s location at regular intervals and when the Cell ID changes it checks
if there is some information in the Database for that particular Cell ID. If it finds some event info or
other information it sends it to the user as a SMS. Before sending the information it checks if the user is
a Member or a Subscriber. If the user is a member he is not charged for the service but if he is
subscriber he is charged automatically from SIEMENS Pay@once server using content based charging
service. The user can deactivate the service anytime by sending SMS “0” to the Service phone number.
If the user needs weather information for any particular city he can request the information by sending
the following SMS (W ) for ex. ‘W Berlin’. Similarly for stock information the user
needs to send SMS (S ) for ex. ‘S SI’ (SI : SIEMENS).
5 Architecture
The Travel Guide Service demonstrates the basic architecture for future Parlay/OSA services.
The Architecture consists of following modules:
6
Client Application:
• Travel Info Server
• Agent Framework
• Administrator
Middleware
• SIEMENS Parlay@vantage
• SIEMENS Pay@Once
5.1 Agent Framework
The agent framework is basically a 3 tier Agent Architecture. We have used Open Agent Architecture
(OAA http://www.ai.sri.com/~oaa/) for building the agent framework[9].
World Wide
PROVIDER Database Web
Stock
Weather Agent
Agent
MIDDLEWARE
FACILITATOR
Client Agent
REQUESTOR Parlay Client
Travel Guide Service
Figure 4 : Agent Framework
5.1.1 Three-Tier Agent Architecture
• The Requestor (of data or information): The information seeker, Parlay Client (Travel Guide
Service) in this case. Here, the software agents task is to find out exactly what the user is
looking for, what they want and if they have any preferences with regard to the information
needed.
• The Provider (of data or information). This consists of individual data sources like WWW or
dedicated information servers. Here, an agent’s task is to make an exact inventory of (the
kinds of) services and information that are being offered by its provider and to keep track of
newly added information.
• Middleware. This comprises the agent architecture, i.e. here agents mediate between agents
(of the other two layers), i.e. act as (information) intermediaries between (human or
electronic) Requestors and Providers.
7
5.1.2 Advantages of the Three-Tiered Agent Architecture
• Each of the three layers only has to concern itself with only doing what it is best at.
• The Architecture does not enforce a specific type of software or hardware. This means that
developers are is free to chose the underlying technique they prefer to use (such as agent
architecture or programming language) to create an agent. In this implementation we have
used OAA (Open agent Architecture) for our Middleware.
• It is easy to create new information structures or to modify existing ones without endangering
the flexible nature of the whole system.
Database WWW
Weather Agent Stock Agent
Travel Info Server Agent Server
HTTP
Parlay Client
Administrator OSA/Parlay API (CORBA)
SIEMENS Parlay @vantage
SIEMENS Pay@once
Content Based Charging
Parlay/OSA Prepaid/Postpaid
Framework Accounts for Non
User Interaction Members
User Location CAMEL
SMS activate/deactivate
Telco Network
SMS/ Call Send Info
Weather, Stock, Event
Info
Figure 5 : Implementation Architecture
5.2 Administrator
This is a remote administration tool for administering the Travel Guide Service. It can be accessed
using a Web Browser and the administrator can directly perform the following functions.
• Add/Delete Cell ID and information in Information Database.
• Observe the status of Users in Current User Database.
• Add/Delete Members in Member Database.
8
Figure 6 : Administrator Web Interface
5.3 Travel Info Server
5.3.1 Introduction
Travel Info Server acts as a server to the user and as a client to the Parlay Gateway. It uses the
Parlay/OSA Framework, User Location CAMEL, User Interaction & Content Based Charging
services.
Parlay/OSA Framework
It provides the Parlay/OSA functionality for Trust and Security, Integrity Management, and Service
Discovery and manages the Client access through Framework – Client interface.
User Interaction
The User Interaction (UI) Service provides the mechanism, which enables a client application to
send information and to receive information from the end users (SMS in Travel Guide Service).
User Location Camel
The User Location Camel (ULC) service provides an interface via which a client can request and
obtain network – related location information on fixed, mobile and IP based telephony users.
6 Conclusion
In this paper we presented an architecture which combines the capabilities of Open APIs(Parlay/
JAIN) and Software Agents to develop new and exciting M-Services. The current deficiency of this
architecture is the lack of generally agreed upon standards, such as one for the agent
communication language. Such standards are a major issue for the three-layer model, as they ensure
that agents in individual layers can easily interface with agents in the other ones. Another problem
is that many of the current agent systems are not compatible with other systems. This would lead to
a situation where an Internet service would have to possess software for every possible type of
agent that may be using the service which is an undesirable situation. Lastly if services available on
the Web are to be used in mobile services then we need to look at other formats other than HTML.
If we just want to display text, there's nothing wrong with HTML, but for automated Web
processing, enriching documents in a way that enables computer programs (like Web robots) to do
something with them, another solution, such as XML is necessary.
9
References
1. Anjum, F., et al., Java in Telecommunications, Solutions for Next Generation Networks.
Communications Networking & Distributed Systems, ed. T.C. Jespen. 2001: John Wiley &
Sons Ltd.
2. Bakker, L., Rapid Development and Delivery of Converged Services Using APIs. Lucent
Technologies, Bell Labs Technical Journal, July - September 2000.
3. Beddus, S., G. Bruce, and S. Davis. Opening up Networks with JAIN Parlay. in IEEE
Communications Magazine. April 2000.
4. Bhat, R. and G. R. JAIN Protocol APIs. in IEEE Communications Magazine. January 2000.
5. Tait, D., J.d. Keijzer, and R. Goedman. JAIN: A New Approach to Services in Communication
Networks. in IEEE Communications Magazine. January 2000.
6. Lange, D. and M. Oshima, Programming and Deploying Java Mobile Agents with Aglets.
1998: Addison-Wesley.
7. Wooldridge, M. and N.R. Jennings. Pifalls of Agent-Oriented Development. in Autonomous
Agents. 1998. Minneapolis/St. Paul, MN USA: ACM.
8. Maes, P., R.H. Guttmann, and A.G. Moukas, Agents That buy and Sell. Communications of
the ACM, 1999. 42(3).
9. Cheyer, A. and D. Martin, The Open Agent Architecture. Journal of Autonomous Agents and
Multi-Agent Systems, 2001. 4: p. 143-148.
10