Agent-based Context-Aware Ad hoc Communication M. Khedr*, A. Karmouch*, R. Liscano**, T. Gray** *Multimedia and Mobile Agent Research Lab, School of Information Technology and Engineering, University of Ottawa 161 Louis Pasteur St. Ottawa, ON, K1N 6N5 Canada mkhedr,
[email protected] Mitel Networks, Kanata, Ontario
Abstract. This paper presents a technique for combining context information and agent technology to support spontaneous applications in an ad hoc network environment. The multiagent system uses the Ad hoc Context Aware Network (ACAN) infrastructure for context gathering, network setup and application management. Agents manage the process of creating, adapting, policing and terminating applications that rise spontaneously according to the situational context information of users, services, and resources. Typical spontaneous applications include locating services and users, invoking services in a non-predefined scenario (such as remote conferencing between distant places), facilitating a common communication mechanism between users, and adapting to changes in the environment and the users’ mobility. The paper examines the requirements of a spontaneous ad hoc communication, the ACAN infrastructure, and the context-based service discovery protocol (CBSDP). The Ontology Aware Service System (OASS) is described as a semantically rich way for a common communication language between the agents and for the process of building up services discovered by the CBSDP protocol. Simulation scenarios are provided and the implementation currently being tested is described.
1. Introduction Research in the telecommunication field suggests that future networks will be composed of sensors, wireless devices, personal digital assistants, networked appliances, and many different devices. This brings up issues such as unfamiliar users and service interfaces, the discovery of services to match the user’s needs and the management of a large number of network entities. This must all be accomplished in an automated way. A variety of protocols and services like SLP (Service Location Protocol), Jini, UPnP (Universal Plug and Play), and Salutation have developed to help resolve some of these research issues. In a service discovery environment, services advertise themselves, providing details about their characteristics and capabilities. Users can then find the information necessary to search and browse for services, choose the service with the desired characteristics, and use it. These current protocols have some common disadvantages. They do not access services spontaneously, they cannot provide initial configuration, they lack the ability to discover services semantically, they cannot rapidly adapt to service changes, and they cannot compose services.
Our work considers these drawbacks and tries to overcome them by using agent technology and context information to build smart networks capable of spontaneous ad hoc applications. Agents have the advantage of being able to assist users, to represent services, and to manage sessions in complex environments, including service selection, QoS specifications, and negotiation. Agents are also mobile and are able to deploy functions on the fly. This helps with fast and autonomous adaptation to service changes. Context is raw information that, when correctly interpreted, can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application [7]. Context awareness is the ability to use context information. A system is context-aware if it can extract, interpret and use context information and adapt its functionality to the context currently in use. Our system is context-aware and provides the capability required to make services detectable and accessible in an ad hoc environment. As part of our research, we needed to clarify the types of context required in spontaneous ad hoc communication. This led us to model the context information as shown below.
Context = f (ξ , t , x) f (m(ξ , x, t )) →
Signaltransmited fromdevices Agentsendinga contextmessage
(P, S, D, ρ ) ∈ ξ ,
ξ = Env. P = people S = services D = devices ρ = others
m(x, t ,ξ ) = (raw information about t,x,ξ ) t = time. x = distance.
The model shows that context is a function of time, distance and the environment. The environment is in turn a function of the users, services, resources and the other entities residing in it during the system’s lifetime. This kind of context is acquired either through some kind of signaling technique, or through the use of special messaging between the agents in the system. This paper is organized as follows. A brief overview of related work is presented in section 2. In section 3, we describe the main components of the ACAN Architecture. In section 4, we highlight our agent-based design, and describe the role of each agent. Section 5 introduces the Ontology Aware Service System (OASS) used in the agent communication model and in the creation of the directory of discovered services. In section 6, we discuss our simulation model and our results. In section 7, we present some considerations arising from the implementation of our work. We draw our conclusions in section 8.
2. Related work Service description protocols exist today either as standards or as research work. Several research projects in the area of location-based context awareness are also ongoing. This section reviews some of the related work in these two main areas. The Service Location Protocol (SLP) [2] is a service discovery protocol for IP networks providing predefined service attributes for software services and hardware devices. The architecture consists of three agents: the user agent representing the user who requests a service, the service agent representing the service, and a directory agent for maintaining the available services. SLP uses multicasting for announcement, registration and service requests. JINI [3] is a java-based service discovery where an object representing the requested service is downloaded from a lookup service to the user node. Salutation [4] is a platform-independent service discovery and session management protocol. Its main component is the salutation manager that acts as a service broker for the services in the network. Current commercial discovery protocols use a centralized information server that listens for broadcast or multicast packets on a well-known address. The server accepts registration requests for available services and answers queries about services. But an ad hoc group cannot use the centralized infrastructure to provide these functionalities. Nor are current protocols sufficient to enable network services in a spontaneous networking environment. Mechanisms are required to decide which nodes should host services, to determine the configuration of services and databases, and to ensure the availability of service and the consistency of databases in the event of partitions and failure. GIAOS infrastructure [5] is an operating system that manages the resources in an active space. But it does not deal with context as a parameter for managing resources, nor does it provide policies to monitor the behavior of the entities in the space. SCAP [6] is a project that proposes an approach to reveal the user’s context in a selforganized sensor network without a central point of control. It is based on passive packets, formatted as a document containing an execution plan that determines the type of sensor, a context hypothesis that accumulates the values retrieved from several sensors, and a packet trace. The packet trace uses two stacks. One stack contains the history of visited nodes and the other contains the route of the incoming nodes. SCAP is similar to OPENSIG architecture in that it deals with active networks within the network layer. Our work seeks to use agents to bring those functionalities to the application layer. It also seems that SCAP will face scalability issues in a highly dense sensor network [6]. Finally, the context toolkit [7] proposes architecture that hides the details of the context sensors, and adds context to applications without it. It has the advantage of reusability. But the context toolkit lacks the infrastructure that supports the transparent acquisition of context; it must already know the network configuration. It also lacks a method of dealing with component failure, a method which our architecture provides.
3. ACAN architecture The main characteristics of the ACAN architecture are flexibility, scalability and adaptability. Flexibility is provided by the layered architecture of the ACAN, allowing tasks and functionalities to be distributed on the different layers of the model. Each layer has certain functions to fulfill, and keeps the processing details in its own layer. Other layers receive only the results they need. Adaptability is achieved by the context awareness mechanism embedded in the system. The tasks performed by the ACAN are constant and specific. But the operations and functionalities that provide these tasks are dynamic and active, changing according to the context fed to the system by the sensors [1]. Protocols designed for the ACAN architecture are extensible, distributed and lightweight, the main requirements of scalability. ACAN can add or remove services dynamically. It can accepts new users, suspend or remove existing users, and provide network parameters in an efficient, dynamic way. The ACAN architecture consists of three layers: the mobility layer, the active ad hoc network layer and the ad hoc applications layer. The mobility layer is network independent. Physical sensors in this layer gather information about the current environment and users in the system. The active ad hoc network layer handles the connectivity and reachability of the nodes in the environment. According to the context provided from the sensors in the mobility layer, it is responsible for the autoconfiguration and management of the network, using tools such as an addressing scheme, a routing technique, QoS mechanisms, and mobility management. The ad hoc applications layer uses the context gathered from the mobility layer, and the connectivity established by the active ad hoc network layer, to deploy applications spontaneously [10], discover services and users in the environment, and adapt its requirements according to the current situation. See figure 1.
Context interpreter
Figure 1. ACAN Layer Architecture
Context information as display, location, processing power, services preferences
Context interpreter
as Location, Mobility, network parameters.
Required Bw,delay jitter,etc
Context information
Resource reservation admission control prioritization routing scheduling, shaping
QoS manager
4. The Multi-agent System The multi-agent system is composed of five main components: sensor agents, context agents, service agents, directory agents and user agents. The ACAN has sensors responsible for acquiring information about surrounding devices and services. This information is provided to a context agent that interprets it in order to extract specifications such as location, time, users, and values. Directory agents use the interpreted context to build a directory of available services and their attributes together with the service agent that represents each service. Service agents work as managers for the services they are in charge of: they communicate with the other entities to perform duties like monitoring the use and availability of service.
4.1 Sensor agent (SA) The environment where the spontaneous application occurs contains different forms of sensors (hardware and software). Each sensor delegates responsibilities to a sensor agent that performs the tasks of data checking, data aggregation, communication with other sensor agents, and communication with the associated context agent. The context agent interprets the raw sensor data into meaningful information. The directory agent builds the directories of available services using the interpreted information, allowing users to query, search and use these services. Each sensor has a unique identifier (SNSR-ID) that is used by the sensor agent and other agents to identify the sensor in the communication and data transportation protocol. Sensors are clustered into groups, each covering a certain area in the environment. Each group also has a unique identification (GSNSR-ID) used when addressing all sensors in the group. The sensors can be arranged in three communication modes: • Peer-Peer mode: where every sensor can communicate with any other sensor using the SNSR-ID. • Clustered mode: where groups communicate with each other using the GSNSRID. • Hybrid mode: a mix of the previous two modes. While the procedure is beyond the scope of this paper, the SNSR-ID and the GSNSRID are acquired during the network setup from the ACAN network layer so that unique value identifiers are guaranteed. Each cluster has a sensor representative agent (SRA) that communicates with the sensors in the cluster to ensure the correctness and consistency of the data acquired The sensor representative agent has the GSNSR-ID as its ID to ensure that it can be reached by every sensor agent. The sensor representative agent receives the acquired data from the cluster’s sensors, and processes it using the Ontology Aware Service System (OASS). The SRA ensures that the data received from different types of sensors are correctly interpreted, and reports any significant updates. Maintenance is resolved using a hybrid soft state. This means that the SRA uses the soft state for registering a sensor as long as the sensor sends information to it. Otherwise, it uses information from nearby sensors.
4.2 Context agent (CA) Each cluster is associated with a context agent. The CA is responsible for processing
the contextual information of the cluster and for providing this information to the cluster’s directory agent. To do so, the context agent performs three functions. The first function is the gathering of the context provided by the SRAs. The context falls into two main categories: context related to the application, and context related to the network. Application context awareness has subcategories such as service awareness, which includes discovery of services, looking up and joining services, and maintaining services once they are discovered. There is also policy awareness, a protocol that uses context to become aware of the types of organizations, the life time of the sessions, and the duties distributed among the users. Network context awareness is the ability to use context to provide information like mobility, the capabilities of the different resources in the environment, the auto-configuration of the ad hoc network and the provision of QoS. See figure 2. Types of Awareness
Application Context Awareness
Network Context Awareness
Mobility Aware
Network Aware
QoS Aware
Relative location Hand over, notification Addressing Configuration Topology Administration Admission Control Prioritization Scheduling
Application Aware
Service Aware
Policy Aware
Typ eCoherency Resources
Discovery Joi Look up n maintenance Organization Duties Distribution Life time Qo S
Figure 2. Types of Context The second function of the context agent is the interpretation of the context using the OASS. The third function is the provision of accumulated information to the directory agent so that services and users may later be retrieved. SAs and SRAs find their associated context agent by using the GSNSR-ID if the CA resides in the same host as the sensor representative agent, or by using CA-ID address provided by the network aware protocol. 4.3 Directory agent (DA) In each cluster, the directory agent receives the contextual information from the cluster’s context agent and is responsible for: 1. Defining the services available. 2. Defining the users in the system. 3. Building the directory lookup table. 4. Associating services to users. 5. Maintaining the directory lookup table.
6. Communicating with other DAs to exchange information and services. The first two of these requirements are accomplished by using the information provided to the DA by the CA through the OASS. The DA therefore contains a lookup table that stores information about services and users. This table is updated from the information sent by the context agent. The default association to discovered services is based on the user profile sent to the directory agent by the user agent and the services discovered. SAs, CAs and SRAs can find their associated directory agent in three ways. The directory agent can reside in: 1- The same host as the SRA agent, thus having the same address the GSNSR-ID. 2- The same host as the CA, thus having the same address the CA-ID. 3- A different host that will obtain its address (DA-ID) from the ACAN system.
4.4 Service agent. A service agent is associated to each service in the system that handles request messages from UAs or DAs. It also accesses the service for the requesting entity and monitors usage. In addition, the service agent acts as a mediator between the service and the users requesting it. The service agent becomes involved when the service is detected by the sensor agents in the environment. The SA is then registered with the directory agent enabling it to dynamically provide the directory agent with service updates. The complete model is illustrated in figure 3.
Figure 3 Agent Model
5. Ontology Aware Service As described in [8], the service ontology was designed using Protégé [9], developed at Stanford University. It is a hierarchy of classes that represents general services to be found in the environment, and subclasses representing the services. Each class contains slots that represent the attributes of the services. The ontology is extensible, allowing services or attributes to be easily added, thereby increasing the knowledge of the agents in the system. The ontology consists of eight main classes representing services such as audio, video, context, printing, quality of service and networking. Each of these classes is further subdivided to specific services such as speakers, projectors, physical and software sensors. For each service, a list of most common attributes is defined in an attribute value tuple. These classes are transferred to an RDF file and are used by the directory agents to build a common lookup table. They are also used as the root ontology in the OASS. This form of ontology cannot support the exchange of semantically rich data between agents and services because it is built on abstraction and generalization. It also faces problems such as dynamic changes in the service ontology, while the root ontology remains the same. To tackle these problems we modified the system to the OASS. The OASS provides a semantic meaning to the classes represented in the ontology proposed. It fits the classes in the root ontology to currently available services and adapts the attributes locally without affecting the general ontology. The OASS consists of an abstract ontology system, a categorizer, a meter, an adapter and a policy and conditioner coordinator.
5.1 The Categorizer The categorizer is responsible for producing a more specific ontology than the abstract root ontology. The specific ontology will be more related to the current situation and to the policies imposed by the different entities in the system. Policies are sets of rules reflecting the overall strategy or objective; they therefore affect the behavior of the system. A policy rule is a group of actions to be performed on the root ontology by the categorizer, meter or the adapter providing some conditions are defined. Detailed policy rules and actions are described in [11]. The categorizer selects the classes, subclasses and the associated attributes from the abstract root ontology to match specific rules from the policy-aware protocol [1], the environment, the types of service agents available, the number of sensor agents, and the availability of directory agents.
5.2 The Meter The meter processes the available service profiles representing the classes selected by the categorizer. It applies some system conditions to produce a temporal, servicespecific ontology that can be accessed by the service, modified and used without modifying the root ontology. The root ontology, however, can be used as a default for services with no profile. The service profile file is a cc/pp file that holds the capabilities and preferences of the
service when it is discovered and added to the system. The cc/pp file is integrated with the root ontology based on restrictions provided by the policies. This produces a specific service ontology that is richer in attributes and describes the service in more detail than the root ontology. The service ontology is dynamic, and describes the services currently available in the environment. Once the session is terminated, the service ontology is deleted and the root ontology once more becomes the default.
5.3 The Adapter The adapter completes the process of providing a more semantically rich ontology by adding user profiles and producing the final modified ontology adapted to both user profiles, and to the services in the system. The user profile is also a cc/pp file that is under development by the W3. By describing the user, the profile makes the system more aware of the user’s behavior and needs [12]. Figure 4 shows the OASS to be system-dependant, supporting the representation of services, the interaction between the agents, and a common access to services that can adapt according to user profiles and service context.
Figure 4. The Ontology Aware Service System
The OASS operation can be illustrated by the example of a conferencing room. The room’s normal use includes services like video, audio, printer and a power point. These options are provided in the categorizer block. In a given session, the policy states that only a laser printer may be used, video capabilities are only of MPEG1, and no cellular phones are allowed. Applying these rules, the categorizer presents a specific ontology that uses only parts of the root ontology as specified by the policy. The specific ontology contains classes allowing audio, video, printer and power point, but no cellular capabilities. During the meeting a user requires a printer. The system provides him with the laser printer. But the printer has extra attributes that are specific to its operation. At this point, the meter receives the service profile of the printer and also some conditions
that the room imposes on printer use, such as printing priority and cost. The meter modifies the specific ontology accordingly. The user who requested the printer requires different printing quality for certain pages, and wants the printing job alerts to be send to his PDA. This information is kept in the user profile in the adapter along with any other conditions such as the failure of a job. The final modified ontology for use by these particular entities is then produced.
6. Simulation Our simulated environment consists of three regions. Each region has one sensor agent, one context agent and several user and service agents. There are 5 types of services (printer, projector, email, phone and internet) distributed over the three regions with random arrival time. We conducted three types of simulation. The first type had a high rate of service requests with a request interval time close to the sensor acquisition time. We measured the average detection time and average waiting time. The second type had a medium rate of service requests with a request interval time above the sensor acquisition time. In the third type, we gradually increased the service use time. We then checked the performance of the system by recording the average utilization, average availability of the services and the percentage of successful service access. In the three types of simulation we used two scenarios: the first had location as the only context information and no region interaction; the second had region interaction and additional context information like the shortest busy service and the longest idle service.
Results and analysis The results in figure 5 show the performance of the system with high and medium rates of service requests. The top graphs show the average detection time, and give an idea of how quickly the sensor agents detected the service request and the context agents processed them. As the number of concurrent service requests increased, the average detection time increased at a rate that was higher than the sensor response time. For a total of 120 requests, it took an average of nearly 14 seconds to detect a request. Maximum wait was 45 seconds, a slow detection response to some service requests. With a medium request rate at a rate above the sensor response time, the 120 requests took an average detection time of 1.7 seconds with a maximum delay of 9 seconds only. The lower graphs show that average waiting time for service acquisition depends on two factors, the average service time, and the availability of the service. We conducted the experiment considering location as the only context. We repeated the experiment taking other context information into account, such as the current resources and context agent interaction. With an average completion time of 10 seconds, performance was found to be much better in the second simulation than the first. This is because more information than location is used for context. The second experiment examined the increase in the average time to complete a service while keeping the number of requests the same. We measured the average utilization, and the percentage of service available per user request. Again, we considered two cases:
first using location as the only context information and then adding other resource parameters such as shortest busy, longest idle, and context agent interaction. medium request rate(2.8s)
high request rate (
