1. Agents, Mobility, Ubiquity & Virtuality Gregory O’Hare Department of Computer Science, University College Dublin Mobile Agents: Agile Agents for Ambient Intelligence COMP4019 Multi-Agent systems Lecture Materials 2007 Gregory O’Hare School of Computer Science & Informatics, University College Dublin (UCD)

2. Mobile Agents Enabling agents to migrate through a WSN brings with it all the advantages associated with Mobile Agents. What is a mobile agent?  An intelligent agent with the ability to navigate a network electronically. Mobile Agents have many identified advantages:  Reduction in network traffic and communication costs.  Asynchronous interaction, can run if disconnected from the network.  Excellent for remote searching and filtering.  Enhanced flexibility and longevity.  Suitable for distributed heterogeneous open environments.

3. Mobility Infrastructure Two key directories are required to be maintained:  White Pages: Which offers a map of the current contact point namely location of any given instance.  Yellow Pages: Which offers a map of those locations at which a given service can be obtained; A system agent function needs to be provided that interrogates these directories  Directory Facilitator: provides an environment where agents may register their services or query for the services that are offered by other agents; Typically supports register, deregister, modify and search functions;

4. Coordination, Cooperation & Negotiation Agents communicate in order that they may better achieve their individual and group goals. Communication can facilitate coordination.  Coordination: is a measure of the extent to which a system of agents can avoid unnecessary and wasteful activity. This will include avoiding resource contention, avoiding both livelock and deadlock,  Cooperation: is coordination amongst benevolant agents;  Negotiation: is cordination between conflicting agents or self-interested agents; To achieve effective coordination agents typically have to hold and maintain a partial model of fellow agents

5. Coordination Taxonomy Cooperation Distributed Planning Centralised Planning Coordination Competition Negotiation

6. Coherence & Planning  Coherence: agents generally want to achieve global coherence without the need for global control. It is necessary therefore that individual agents can determine shared goals, agree and determine who will perform common tasks, avoid conflicts and combine evidence and knowledge;  A key ingredient to achieving this is planning;  Two broad categories of planning exist nmamely Distributed Planning & Centralised Planning;

7. Mobile Agent Pitfalls  The utilisation of mobile agents introduces several potential pitfalls, including:  Security, interoperation, language translation, dynamic itinerary creation / management and heterogeneous device / agent system cooperation.  Much research has been conducted in order to tackle and address these identified pitfalls and a varying range of solutions have been presented.  However these solutions lack cohesion and each requires a significant amount of development to deploy.

8. Why Mobile Agents  Reduce Bandwidth Consumption and Network Loads  Allow dynamic deployment of application components tp encapsulate protocols  execute asynchronously and autonomously  can adapt by moving  run on heterogeneous platforms  most distributed applications fit naturally into the mobile agent model  intuitively suitable for mobile users and disconnected operations  Mobile agents combine the strengths of techniques such as RPC, java applets etc. into a single, convenient framework  Reduce network load  overcome network latency  encapsulate protocols to allow changes  asynchronous and autonomous execution

9. Why Mobile Agents II  adapt dynamically  heterogeneous  fault tolerant -- move from a down host  Efficiency - mobile agents consume fewer network resources since they move the computation to the data rather than the data to the computation  Reduction of network traffic  communication protocols involve several interactions, which causes a lot of network traffic. Mobile agents can package up a conversation and ship it to a destination host where the interactions can take place locally

10. Migration Types Two Broad types of migration exist.  Weak Migration: permits mobility of code and data state. After the movement, the agent is restarted and the values of its variables are restored, but its execution restarts from the beginning of a given procedure ( a method in case of objects).  Strong Migration: Mobility of code, data state and execution state. Restart the execution exactly from the point where it was stopped before movement. Within Strong Mobility: When moving a mobile agent carries: code + data state + execution Data State Data - global or instance variable; Execution State – local variables and threads On moving, execution can continue the point it stopped on previous host

11. Agent Life Cycle Models An agent life cycle can be defined as: “A series of stages through which an agent passes during its lifetime.” Life cycle models describe both the states of an agent, and the (allowed) transitions between states. Two Broad Classes of Model exist: §The persistent process life cycle model; e.g Telescript Agent TCL, §The task based life cycle model; e.g Aglets

12. FIPA Agent Management Specification The FIPA Agent Management Specification explicitly de- fines an agent life cycle with a state diagram. FIPA agents can be in one of the following states: initiated, active, transit, or suspended. After creation, the agent is said to be in the initiated state. After invoking the agent, it is active. The central state of a FIPA agent is the defacto active state. After moving into another state, agents always return to the active state before additional state transitions are possible.

13. Persistent Process Life cycle Model  All other life cycle models can be built on top of this model;  The mobile agent can exist in one of 4 states: a start state a frozen state a running state a death state  The life cycle starts in a start state and then it proceeds to a running state where a persistent process is executed and eventually enters a death state where the process is terminated;

14. Persistent Process Life Cycle Model II  When a mobile agent is transported from one node to another, the process in the running state is check-pointed and the agent enters the frozen state;  Next, its context is delivered to the destination node where the process is resumed and re-enters the running state at the point it left off;

15. Task Based Life Cycle Model Offers a flexible life cycle model however context information can be lost during transport. The mobile agent can exist in one of 3 states:  a start state  a death state  task states  The mobile agent starts in the start state. Depending on a set of conditions it proceeds through a network of task states - each task has its own state.  When the agent moves to a new node the context of the currently executing task is lost.  Before moving the agent must indicate the first task to be started when it re-materialises on the destination node

16. Aglets Within Aglets program code can be transported along with state information Aglets were created by IBM Japan Aglets (= agents + applets) are Java objects that can move from one host on the Internet to another When the aglet moves, it brings along its program code as well as its data An aglet that executes on one host can  halt execution  dispatch to a remote host and  resume execution there

17. Aglets II An Applet-like programming model for mobile agents. Implemented in Java (as many mobile agent toolkits are! ) Aglet = Agent + Applet Aglet’s API facilitates mobile technology Aglet: mobile java object that visits aglet enabled hosts in a computer network An Aglet = Instance of a Java class extending the Aglet Class An Aglet =Aglet state (values in variables) + Aglet code (class implementation) Autonomous – runs its own thread after arriving at a host Reactive – responds to incoming messages Offers Weak Mobility

18. Key Aglets Features A globally unique naming scheme for agents (navigation/security model) A travel schedule for specifying complex travel patterns with multiple destinations and automatic failure handling (navigation model) A white board mechanism allowing multiple agents to collaborate and share information asynchronously (communication model) An agent message-passing scheme that supports asynchronous and synchronous peer-to-peer communication between agents (communication model) A network agent class loader that allows an agents Java byte code and state information to travel across the network (navigation model) An execution context that provides agents with a uniform environment independent of the actual computer system on which they are executing (computational model) aglet

19. Aglet Operations  Operations on aglets:  creation – within a context. Assign id, initialise and execute;  Run;  cloning – identical copy in the same context. Different id and execution thread;  dispatching – move from one context to another where execution will re-start (i.e. threads do not migrate);  retraction – pull from current context and insert into the context from which retraction was requested;  activation & deactivation – temporary halt and store in secondary storage;  disposal – halt execution and remove from current context;  Event-based control via user-defined methods: onCreation, onDisposing, onCloning, onDispatching, onReverting, onArrival, onActivation, onDeactivating etc  Messaging between aglets: messaging via proxy, a message invokes a method

20. Why Java-based Applications use Weak Migration  Truly strong migration is not possible in Java because a Java application cannot gain access to the internal execution stack or program counter of the JVM. Within Java the internal implementation details of the JVM remain hidden. This facilitates platform independent development.  The consequences of this, however, are that a Java application is prevented from transferring a process midway through execution in a transparent manner.  For the majority of mobile applications though it is not necessary to transfer the internal stack of the JVM. It is usually sufficient to transfer the requisite code and the internal states of the objects within the system. This is the approach that has been adopted by the standard version of Agent Factory.

21. AFME Mobility Support I  Within AFME support is only provided for the transfer of the agent's mental state. Any classes required by the agent must already be present at the destination.  This is because CLDC does not contain an API for dynamically loading foreign objects.  The reason CLDC applications do not contain security managers or class loaders that would enable the dynamic execution of foreign code is that the JVM specification does not contain a class verifier. The verifier forms one of the most important security aspects of the original J2SE JVM architecture. It ensures the integrity of a sequence of byte codes by performing a data-flow analysis on them at run-time.

22. AFME Mobility Support II  Conversely, within CLDC the code must be pre-verified in order to execute. This improves the performance of the system in that the code does not have to be continuously checked while executing.  However it prevents the system from dynamically downloading and executing foreign objects because the system cannot verify that the objects' code is safe to use.  Malicious developers could simply alter the structure of a class, for example by changing the operand of a jump opcode such as goto, to crash the JVM and potentially the operating system of the mobile device. Thus no support for mobile code is provided.

23. Personalised Retail : EasiShop Mobile Agent based U-Commerce System Agent Factory Thinlets Midp Bluetooth EasiShop Client Side EasiShop Server Side

24. Mixed Reality Robotics

26. HIPS & Gulliver’s Genie Objectives  Provide an infrastructure which supports simultaneous user navigation of a physical space and it’s corresponding information space  Deliver contextualised information to roaming tourists  Provide seamless movement between the physical & virtual spaces

27. Localisation Technologies Satelite based Systems Global Positioning System (GPS); Differential GPS (DGPS); Galilleo - European GLONASS – Russian; Radio Based Systems Base Cell Identification; Base Cell Triangulation based on either Angle of Arrival (AOA) or Time of Arrival (TOA); Location Fingerprinting – each location has a unique signal pattern create database to record these and match; Hybrid Systems; Enhanced/Assisted GPS (EGPS) – Ericsson Mobile Positioning System (MPS).

28. HIPS : A Handheld Tourist Aid Tourist Content Delivered in a Proactive (Push) Tailored fashion. The key personalisation & Contextualisation parameters are: Location (Longitude, Latitude, Orientation) acquired from a Global Positioning System (GPS) device & electronic compass; User Preferences extracted from a user profile;

29. Administration Toolkit

30. Gulliver’s Genie

34. WAY GUI Zoomed InZoomed Out

35. EasiShop Mobile Agent based U-Commerce System Agent Factory Thinlets Midp Bluetooth EasiShop Client Side EasiShop Server Side

36. Agent Travel Metaphor

37.  To address this we propose the Agent Travel Metaphor, (ATM).  This metaphor draws from an analogy between agent migration and human travel. Using the similarities between these two process the metaphor describes a natural and easily configurable set of services and tools for mobile agents.  The accompanying Agent Travel Algorithm deploys these services and tools to mobile agents and to agent platforms in a modular nature.

38. Agent Travel Algorithm

39. Begin Select Destination Get Destination Description if( ! same language ){ Contract Translator } if( ! same behavior ){ Contract Teacher } Determine Packing Requirements if( packing necessary){ Pack Baggage } Obtain Necessary Travel Documents Submit Travel document to Port Authority Migrate once Authorized End

40. Agent Factory and the ATM

42. Agent Travel Metaphor  Pros  Allows for modular provision of solutions to common problems in mobile agent software design.  Allows for natural development of tools and services to aid mobile agents.  Allows administrators to design software to protect their networks.  Allows for flexibility between efficiency and security.  Allows for cooperation and interoperation between heterogeneous devices and multi agent systems.  Cons  There is an increased overhead involved in deploying these extra services and tools. (However this is the case without providing the metaphor).  An increase in complexity of agent migration leads to a decrease in performance and thus an increase in the time it takes to migrate an agent.

43. ACCESS: An Agent Architecture for Ubiquitous Service Delivery Agents Channelling ContExt Sensitive Services Cooperative InformationIAgents (CIA) System Inovation Award Winner 2003

44. ACCESS Objectives ACCESS seeks to provide:  an open extensible architecture for the rapid prototyping and deployment of context sensitive services  strong support for generic profiling  enable the intelligent prediction of user service needs  support for a scalable multi-user environment

45. ACCESS Architecture Agent Factory Run-Time Environment Agent Factory Development Environment ACCESS Management Agents ACCESS Toolbox Development Deployment

46. ACCESS Management Agents Agent Platform The ACCESS Client Agent Platform The ACCESS Gateway –Context Management –User Profiling –Content Delivery –Location Sensing –Map Generation –Service Brokerage

47. Hotel Finder: An ACCESS Service

49. The first open extensible architecture for the rapid prototyping and deployment of context sensitive services through the use of lightweight mobile intentional agents Why Choose ACCESS ?

50. Wearable/Ubiquitous Sensors  Motes in Wearable Sensor Networks. By linking pressure sensitive pads through a personal wireless network we are going to experiment with mechanisms to measure bodily functions such as breathing. This could allow us to detect hyper- ventilation and inform paramedics through a mobile phone.