Personal Communications in Integrated Personal Mobility Architecture B. Thai, R. Wan, A. Seneviratne School of Electrical Engineering and Telecommunications University of New South Wales, Sydney, Australia
[email protected],
[email protected],
[email protected] Abstract Integrated Personal Mobility Architecture (IPMoA) is a personal mobility framework that supports personal mobility in both the areas of personal communications and personalising operational environments [11]. In this paper, we describe in detail one aspect of IPMoA that is unique, namely the use of mobile agents to assist users in personal communications. In particular, we describe the functionality of the Personal Communication Assistant (PCA), and how it co-ordinates the setting up of a call: how it determines the location of the remote end point (location management), set-ups the call and how the session customised to the operating environment. It then illustrates the viability of the proposed scheme through a prototype implementation.
1. Introduction With telecommunication networks beginning to migrate towards Internet technology, users are starting to enjoy the integration of data and communication services. However, users are now demanding and expecting more services from such networks. The integration of data and communication services alone no longer satisfies the users. The expectation is that they will be able to access the Internet from anywhere and any time, using any device, and at the same time be reachable by other users. This makes the issue of user mobility an important aspect in the design and development of the next generation of mobile communications and computing systems. We believe for the foreseeable future users will use more than one device that are capable of gaining access to the Internet. With the integration of data and communication services, almost every “Internet ready” device will be a communicable device. These devices need not necessarily be mobile (eg. a desktop PC), but the user will always be. Thus it is necessary for the network to support personal mobility, as well as supporting terminal mobility. This motivation led us to design a framework for personal mobility, which we referred to as IPMoA (Integrated Personal Mobility Architecture), which is presented in [11].
In this paper, we present one particular aspect of IPMoA – personal communications. There are already a number of research projects which addresses the issue of personal mobility and interpersonal communications, such as ICEBERG [13] and Mobile People Architecture [8]. These research projects attempt to use a centralised architecture, in which an entity at a centralised location acts as a “universal inbox”. In contrast, IPMoA takes a different approach, and provides the necessary functionality using a mobile agent as a Personal Communication Assistant (PCA) [11]. This enables the exploitation of the special characteristics of mobile agents, namely them being autonomous and mobile, as described below. Furthermore, through the interactions between the PCA’s (for call set-ups and dynamic call session customisations) and the Location Manager (for determining the location), we can show that the use of mobile agents can provide a more flexible solution with more functionality than the traditional centralised approach. The rest of the paper is structured as follows: Section 2 presents an overview of the architecture of IPMoA. Section 3 describes the structure and functionality of the PCA’s in IPMoA. Section 4 presents our experimental testbed – the realisation of the framework. Section 5 presents a number of related works in this area. Finally Section 6 summarises and concludes the paper.
2. Review of IPMoA Within the area of personal mobility, there are two aspects which researchers have focused on [11]. Firstly, personal communications, the ability of a user with another regardless of his/her location and the device s/he is using. Secondly, the ability to personalise the user’s operating environment independently of the terminal type and/or network s/he is using. The personal mobility frameworks that have been proposed to date, such as ICEBERG [13], Mobile People Architecture [8], and NetChaser [1], address only one of the two aspects of personal mobility. IPMoA supports both aspects of personal mobility, which to our best of knowledge, has not been studied before.
The details of the IPMoA framework are explained in [11]. The architecture of IPMoA is schematically illustrated in Figure 1.
User's Applications
User's Personal Files
User's Current Location
Application Manager
File Manager
Location Manager
User's Preferences
Authentication Manager
Agents Execution Environment Adaptation Library
PAA
PFA
PCA
Network Boundary User
Figure 1: The Components of the IPMoA Framework. In Figure 1, the File and Application Managers provide the functionality required to manage the user’s files and applications respectively. The Location Manager keeps track of the location of the user, and the Authentication Manager provides the necessary security features and maintains the user’s preferences. One feature of the framework are the use of 3 personal assistants: Personal Application Assistant (PAA), Personal File Assistant (PFA) and Personal Communication Assistant (PCA). All 3 personal assistants are mobile agents, and perform various tasks on behalf of the user in terms of executing applications, synchronising personal files, and communicating with another user on the network as described below. They are executed in the Agent Execution Environment, which can be located either in the network, or at the user’s terminal. A set of adaptation libraries is also available for the PCA’s to facilitate session customisation where appropriate. Since this paper focuses on the personal communication aspects of IPMoA, the rest of the paper will only consider the functionality of the PCA.
3. Personal Communications in IPMoA The Personal Communication Assistant, as mentioned previously, handles the personal communication aspect of IPMoA. Its primary task is to set up calls for its users. The call set up procedure includes locating the callee, signalling the callee for initiating the session and installing the appropriate “plug-in” where necessary to
mitigate the incompatibilities of the applications and terminals involved in the session. In order to perform these tasks, it must be able to co-ordinate with different Location Managers and with other PCA’s on the IPMoA network.
3.1. Location Management As mentioned in [11], the issue of location management relates to user mobility in general, regardless of whether the system supports terminal and/or personal mobility. In IPMoA, location management is performed similarly to NetChaser [8]. In order for a user to obtain any IPMoA functionality, s/he must log onto the network. When logging on, the user authenticates his/herself via the Authentication Manager, either on his/her home network or a visiting network. As a PCA is launched from the home network and will migrate close to the user, the location update can be performed by the PCA as follows. After the PCA migrates to an Agents Execution Environment, it first opens a port to listen for call requests. The port number is obtained dynamically, therefore after a successful port opening procedure, it notifies its home Location Manager its location in terms of it’s the dynamically obtained IP address and the port number it’s listening on. This is illustrated in Figure 2. Application Manager
User's Preferences
Home Network
1. The user authenticates him/herself
File Manager Authentication Manager Adaptation Library
Location Manager
4. PCA notifies the Location Manager of its current location
Agents Execution Environment
2. Authentication manager creates a PCA for the user.
PCA
User
3. PCA opens a socket, ready to receive call requests.
Figure 2: The relationship between log on process and location update. IPMoA forbids a user to log onto two different networks simultaneously. If a user logs onto network A and then logs onto network B, without logging out of A, the system will assume the user has migrated to network B. As a result, it will perform the necessary logging out procedure for the user, such as synchronising the user’s files and destroying all the personal assistants. A new set of assistants suitable for network B are then created. Finally, the location of the user is updated on the
Location manager to reflect its current location in network B. When a user is logged on to a network, s/he can perform two location management functions: 1) log out of the IPMoA network and 2) migrate to another network. The difference between the two functions is that the PCA is not destroyed if the user migrates to another network. The PCA it migrates with the user and updates its location to the home network’s Location Manager.
3.2. PCA’s Call Set Up and Termination Procedure Location Manager and other PCA’s, need a signalling protocol to co-ordinate themselves. We believe that an existing protocol such as Session Initiation Protocol (SIP) [3] can also be used for this purpose. Its operation will be as follows. When a user wishes to contact another user on the IPMoA network, s/he notifies his/her PCA, specifying the callee’s address and indicating what application s/he wants to use. The caller’s PCA first locates the callee’s PCA by querying callee’s Location Manager. The address of the Location Manager is determined using DNS and the callee’s address. This querying process is illustrated in Figure 3. The PCA constructs a “Where is” message, with the callee’s address embedded in it, and sends it to the callee’s Location Manager. When the Location Manager receives this message, it looks up in its database to find the current location of the specified user’s PCA. If the specified user is in the database, it replies with an ACK along with the IP address of the PCA, as well as the port number the PCA is listening to. If the database lookup procedure failed, this implies the user is not on the IPMoA network. A NAK message is replied to the PCA.
Caller's PCA
Callee's PCA
Location Manager
PCA
Where is:
[email protected]
Database Look up ACK: IP add : port no. or NAK
Figure 3: The location query process. Once the callee’s PCA has been determined, the caller’s PCA begins a call set up procedure as shown in Figure 4. The caller’s PCA requests a call session by sending a Call Request message to the callee’s PCA. This message contains the caller’s address, along with the applications that s/he will be using for the session. Upon receiving this Call Request message, the callee’s PCA notifies the user a call request has arrived. The user can make a decision as to what to do with the call. If s/he chooses to reject the call, PCA replies with a Call Reject message, and the caller’s PCA notifies the user. If the user accepts the call request, the PCA loads the necessary “plug-in’s” from the adaptation library. The decision as to which “plug-in” to use is based on the application being used and the callee’s terminal capability (eg. applications available, network etc.). The PCA then replies the caller’s PCA with a Call Accept message. Once the caller’s PCA receive this message, it also loads the necessary “plug-in’s” and begins the user’s application. It then send a Call Begins message to the callee’s PCA. The callee’s PCA receives this message and it too starts its application, thus establishing the session. Caller's PCA User makes a call
Callee's PCA
Call Request Notifies User
Call Request
User Accepts
Notifies User
Call Accept User Rejects Call Reject Notifies User
PCA loads necessary "plug-in's" and launch application Notifies User
PCA loads necessary "plug-in's"
Call Beigns PCA launch application Notifies User
a. Callee rejects call request b. Callee accepts call request. Figure 4: The call setup procedure.
Caller's PCA User terminates call
Callee's PCA
Call Terminate
Termination ACK 1 PCA removes all "plugin's" and applcaion
PCA removes all "plug-in's" and application
MySQL Database
Tahiti User
Location Manager
Location Manager
PCA
PCA
UDP Reflector
UDP Reflector
MySQL Database Tahiti
IPMoATalk
IPMoATalk
User
Termination ACK 2 = Data Path
Figure 6: The IPMoA prototype. Figure 5: Call termination procedure between the PCA's.
As soon as either party wishes to terminate the call, both PCA goes through a call termination process using a 3-way handshake. The call termination initiated by the caller’s PCA is illustrated in Figure 5 for simplicity. The termination by the callee is identical. The caller’s PCA issues a Call Terminate message to the callee’s PCA. After the callee’s PCA receives such a message, it begins a garbage collection process by removing all the plug-in’s and user’s application. It then replies with a Termination ACK 1 message. The caller’s PCA also goes through a garbage collection process after it receives the Termination ACK 1 message. The call termination process is completed with the caller’s PCA issuing a Termination ACK 2 to the callee’s PCA.
4. Prototype Implementation To evaluate the framework’s feasibility, a prototype of IPMoA was build on the UNSW experimental network under Linux. Although La Porta et al. show in their experiments that mobile agents can be implemented using C++ [6], we believe that the architecture dependency resulting from such implementation is severe. Hence we chose to use a mobile agent platform that is Java based, so that IPMoA can operate in a heterogeneous environment. Specifically, we used IBM Aglets [4] as our mobile agent platform to realise our PCA’s, with the aglet context Tahiti, which is supplied with the IBM Aglets development kit, as our agent execution environment. Our Location Manager was also written using Java, with MySQL [9] as the database manager. We also developed a simple unicast voice conferencing application called “IPMoATalk”. Existing voice conferencing applications such as RAT and Microsoft Netmeeting were not considered for this initial implementation, as considerable effort would have been needed to develop the necessary plug-in’s for these applications.
For IPMoATalk, a plug-in called “UDP Reflector”, which is a UDP version of SLM [7], was developed. This plug-in enables the session to be maintained even if the user migrates to another network while s/he is in the middle of the call. The complete set up of the testbed is illustrated in Figure 6.
4.1. Observations and Findings Given the scenario illustrated in Figure 6, we went through the process of creating a PCA on each IPMoA network. As expected, the PCA successfully updated their location with their respective location manager after its creation. To test the interactions between the PCA’s and the Location Manager, a user initiated a call with the other user via his PCA, with IPMoATalk as the application. The result was encouraging, as the call session was successfully set up and terminated. During the development process, we discovered that the decision engine for choosing what type of plug-in’s to use is too complicated to be embedded into the PCA. Our mobile agents needed to be kept as small as possible to minimise the migration time. Having such complicated code inside the PCA made it “heavy” and as a result, the migration performance suffered. Currently we are looking for an alternative solution such as the concept of proxy repository from MARCH [2], so that the decision engine can be placed elsewhere and the PCA can interact with it to obtain the most suitable plug-in’s for each call session.
5. Related Work There are many frameworks that support personal mobility in the area of personal communications. Mobile People Architecture [8] provides users the ability to be contacted anywhere regardless of which network and what device s/he is currently using. The privacy of the user is maintained as the architecture provides a personal
proxy for each user, and users can only contact each other via these proxies. Protocol conversions and content adaptations are supported as each user’s home network contains a set of proxies. In terms of functionality, IPMoA provides the same functions as MPA; however, IPMoA has optimised the functions provided by MPA. For instance, in MPA, the content adaptation and protocol conversion proxies are located at the user’s home network. This implies that the all data must go through the user’s home network, perform the necessary functions on the data, then route it to the user. This can cause extra delay if the user is far away from his/her home network. On the other hand, the PCA’s in IPMoA are located close to the user, and they acquire the necessary plug-in’s for the data. This creates a more efficient data path, as data is not forced to route through the user’s home network. ICEBERG [13] is a project from U.C. Berkeley that aims at providing a framework that integrates the telephony and data services. Since ICEBERG is built on top of Ninja [12], each Iceberg Point of Presence (iPOP) has the ability to acquire necessary content adaptation and/or protocol conversion functions to customise each user’s session. IPMoA also has such ability; however, the loading of content adaptation and/or protocol conversion functions are performed by PCA, which is a mobile entity on the network. As long as there is an Agent Execution Environment, that particular node can be used for content adaptation and/or protocol conversion, which compared to ICEBERG is a more flexible approach, since and iPOP is a fixed entity on the network. Jung et al. proposed a Mobile Agent Network which is similar to IPMoA – they also use mobile agents to represent the user on the network. Two personal agents are used to assist the users to communicate with other – one stationary agent, which located in the user’s home network, and a mobile agent, which is located near the user. The stationary personal agent is used to maintain user’s information and the mobile personal agent is used to track the user’s location and perform various services for him/her. Although this framework, and its signalling protocols are similar to IPMoA, it lacks the capability of IPMoA as IPMoA’s PCA can load necessary plug-in’s to cater for its user’s capability and applications. Although La Porta et al.’s use of mobile agents is not in the area of personal mobility, they demonstrate mobile agents can be used in assisting the users in personal communications. In their work as described in [5], they used mobile agents to enhance to functionality of Personal Communication Services (PCS). Mobile agents in this case were used to maintain the state of the current user, such as the user’s device and its service profile. As such information is close to the end users, call connection latency can be reduced, since the network does not need to obtain the user’s information from some central server.
6. Conclusions and Future Work In this paper we have reviewed our IPMoA architecture, a personal mobility framework that supports personal mobility in personal communications and personalisation of operating environments. We presented one aspect of the IPMoA framework, namely the functionality that supports personal communications. In our framework, the Personal Communication Assistant (PCA), a mobile agent, is used to represent the user on the IPMoA network. Being mobile, the PCA can migrate itself as close to the user as possible. As the user is logged onto the network, the PCA interacts with its home network’s Location Manager and updates its current location. For a user to make a call to another user, the user’s PCA firstly interacts with the other user’s Location Manager to obtain location information, then with his/her PCA to set up a call session. In addition to signalling between PCA’s, the call set up phase also include the process of loading plug-in’s to customise the user’s session. We showed that such co-ordinations can successfully set up a call session between users, as we realised such concept with a prototype. Through this design, we also show that the features of mobile agents, that are being mobile and autonomous, can be exploited and assist users in locating a user on the network, and consequently setting up a call session with him/her. As this concept is still in its early stage, there are still a number of issues we need to address. The current prototype needs to be extended to further prove the concepts viability. However, we believe that this architecture can provide a more complete solution to the issue of personal mobility.
6.1. Future Work There are number of areas require further investigation before the viability of the proposed framework can be fully demonstrated: 1. Call setup protocol: The current call set up procedure uses a simple protocol. Can we utilise some existing protocols such as Session Initiation Protocol (SIP)? 2. Loading of plug-in’s: Since the decision engine is too “heavy” to be implemented as part of the PCA, Can we have this decision engine elsewhere on the network so the PCA can interact with it? 3. Mobility while in session: What is the most effective method perform a “handover” when the user migrates from one network to another while s/he is engaging in a personal communication session? Our current work is aiming to address these issues.
7. Acknowledgments The authors would like to acknowledge Ericsson Radio Systems AB, Sweden and Ericsson Australia for their financial support.
8. References [1]
[2]
[3] [4] [5]
[6]
[7]
[8]
[9] [10]
[11]
[12] [13]
Di Stefano A and Santoro C, “NetChaser: Agent Support for Personal Mobility”, IEEE Internet Computing, March-April 2000, p.74-79. Gunningberg P & Seneviratne A, “Services and architectures in the Next Generation Internet using dynamic proxies”, FTF99, Bejing, China, December 1999. Handley M et al., “SIP: Session Initiation Protocol”, RFC 2543, March 1999. IBM Aglets homepage, http://www.trl.ibm.com/aglets Jung E et al., “Mobile Agent Network for Supporting Personal Mobility”, Proceedings for International Conference on Information Network (ICOIN), 1998, p.131.136. La Porta T, Ramjee R, Woo T, Sabnani K, “Experiences with Network-based User Agents for Mobile Applications”, Mobile Networks and Applications 3 (1998), p.123-141 Landfeldt B et al., “SLM, A Framework for Session Layer Mobility Management”, International Conference on Computer Communications and Networks (ICCCN), 1999, p.452-456. Maniatis P et al., “The Mobile People Architecture”, Mobile Computing and Communications Review, July 1999. MySQL homepage, http://www.mysql.com Perkins C E, “Mobile Networking Through Mobile IP”, IEEE Internet Computing, Volume 2, Jan-Feb 1998, p.58-69. Thai B, Seneviratne A., “IPMoA: Integrated Personal Mobile Architecture”, Proceedings for International Symposium on Computers and Communications (ISCC), Hammamet, Tunisia, 2001. The Ninja Project, http://ninja.cs.berkeley.edu/ Wang H, et al., “ICEBERG: An Internet-core Network Architecture for Integrated Communications”, IEEE Personal Communications, August 2000.
