INTEGRATING AGENT AND WIRELESS TECHNOLOGIES FOR ...

INTEGRATING AGENT AND WIRELESS TECHNOLOGIES FOR LOCATION-BASED SERVICES IN CULTURAL HERITAGE Maurizio MEGLIOLA1, Luca BARBIERI1 Abstract This paper covers the research and development of the “Progress Module” part of the iTACITUS sixth framework programme project, a multi-agent system which delivers location-based information on mobile devices, featuring intelligent user profiling, to Cultural Heritage sites visitors.

1. Introduction iTACITUS is a sixth framework programme project aiming to provide a bespoke cultural experience for the individual, based upon a dispersed repository of historical and cultural resources, enabling both location-based and location-independent services. The services developed will include audiovisual, VR and organizational components, and will be delivered in a flexible and timely fashion. iTACITUS will allow the creation of flexible travel plans that utilise public transport, cycling and pedestrian routes to guide visitors to attractions. The user will be able to plan a full day of sightseeing, with instructions given for the most appropriate mode of transport for each section of their journey. Once the tour has been created, based on the expressed interests and preferences, the tourist will be guided through the areas of interest whilst relevant information will be presented by iTACITUS on the user's mobile computer at the appropriate points. iTACITUS will also be able to modify and reschedule an itinerary, to compensate for delays or to allow the user to remain longer at a particular attraction. This paper covers the research and development of the Progress Module, which conceptually aims to assist the system in keeping the visit scheduled by the user at first, and improve the quality of the visit.

2. The system From the tourist point of view, the iTACITUS system consists of two integrated applications: • A City Guide, a web-based platform which consists of: • The Itinerary Manager (IM), to plan a journey itinerary and then dynamically handle it, • The Cultural Heritage Information Module (CHIM), to deliver services and information to the IM both during the itinerary planning and the visit. • An AR Viewer, providing a number of audio/video advanced contents available at iTACITUS enhanced sites.

1

TXT e-solutions, Via Frigia 27; 20126 Milano, Italy

The Itinerary Manager helps the users to plan the visit, suggesting venues and events following their profiles, as well as time (open and close hours, average length of the visit, etc.) and spatial (distance between two places, available transports etc) restrictions. During the visit instead its purpose is to monitor the users in order to verify that the visit is in time as initially scheduled, and adjust in case of lateness or anticipation. For example, the user may explicitly ask for modify the itinerary; the system may notify to the user a delay during the visit because of sudden weather or transport changes. To accomplish its tasks, the IM uses the services provided by the CHIM, which consists of: • POI Module, to extract information from the database and processes them in order to send the related data to the points of interest (POI), • RSS Module, to retrieve information about weather and transport from external sources, • Progress Module, to monitor the user position, to calculate a profile and to provide contextual information when necessary (computed depending on the profile and the current position). Finally, the AR Viewer extracts the information needed to present the multimedia contents from an additional database (visualization DB), and uses the powerful features of ultra-mobile pc (UMPC) to allow the users enjoy a rich and innovative experience.

3. Progress Module The aim of the Progress Module is to satisfy the following requirements: • Provide the current GPS coordinates of the user; all the iTACITUS modules rely on this service, as the knowledge of the user position: ‐ represents the first parameter for checking that the progress of the visit is in time (IM) ‐ is needed in order to decide when and how provide suitable contextual information (PM) ‐ is requested by the visualisation module (AR Viewer). • Provide information about the user profile; the features of the user may be split in two categories, depending on their objectivity (age, mobility, etc.) or subjectivity (then derivable through the profiling). • Provide contextual information; the PM establishes (depending on the current location) when to provide this service, and in case it elaborates what information is more relevant for the user and pushes it to the Itinerary Manager; the IM will notify this information to the user, who will choose to accept or not accept it. It autonomously watches the progress of the visit and checks both environmental (such as the weather and the location), and personal variables (such as the current profile and the personal history), in order to provide further information relating to cultural/historical venues. Because of these requirements we found it appropriate to model the Progress Module not as a unique monolithic entity that can exec all these tasks, but interpreting it by using an agent model [2]. In this way, a multi-agent system (MAS) can accomplish the tasks and functionalities of the Progress Module through separate agents, each handling a task and interacting with the other agents of the MAS. We implemented this multi-agent system following the FIPA conformed JADE [1] framework and defining the following agents: • Progress Agent (PA) • Location Agent (LA) • User Profile Agent (UA) • Gateway Agent (GA).

The main purpose of the Progress Module is to give a transparent support to the visit. We obtained this by using an "ad hoc" user profile in order to find the information that is more likely to be interesting for the user. The system creates a starting profile when the users register into it, by requesting them to fill a short questionnaire about their preferences in cultural heritage. When the user thereafter logs into the system, the Progress Agent will coordinate all the activities to assist the user. The PA creates the Location and User profile Agents and activates them only when the visit has started. During the visit, the UA is able to modify profile features in real-time, depending on the user current behaviour. The Gateway Agent handles the communication with the external world. 3.1. Location Agent The localization issue is of fundamental importance within the iTACITUS project, as it represents the basis for the added value given by dynamic itinerary adjustments and contextual information. An application like iTACITUS whose aim is to give advanced location-based services and information to the visitors of cultural sites, does not need RTLS (Real Time Locating Systems) systems using RFID (Radio Frequency Identification) sensors to monitor the position of an individual; this task is satisfied by using a GPS receiver, more economic and nowadays widely spread and often even integrated in mobile devices. The GPS (Global Positioning System) is founded a principle called trilateral, which allows to calculate the position of an object by knowing the distance from at least three known points (satellites, in this case). This is computed by measuring the time a radio signal takes to cover the satellite-receiver distance and the accuracy is about of 10-20 meters. Information is provided following the NMEA 0183 standard. The RS-232/USB/Bluetooth GPS receivers prepare and send strings of text which are called sentence, containing the information about localization and follow the 0183 National Marine Electronics Association (NMEA) standard. This standard establishes the format of the sentences that a receiver prepares and sends to a computer or another device able to receive them. From a technical point of view, sentences are textual strings such as: $GPGSV,2,1,08,01,40,083,46,02,17,308,41,12,07,344,39,14,22,228,45*75 $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A $GPGLL,4916.45,N,12311.12,W,225444,A,*31 $GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*33 $GPAAM,A,A,0.10,N,WPTNME*43 $GPAPB,A,A,0.10,R,N,V,V,011,M,DEST,011,M,011,M*82 Given that we had to potentially manage about thirty sentences, we had to beforehand classify them, in order to detect a minimal subset able to meet our requirements. The primary classification concerned the type of data: do they derive from a single scan or were they originated by an elaboration of subsequent scans results? For example: all the sentences containing positions or dates belong to the first category, instead all the sentences giving information about shifts, velocity or accelerations can be attributed to the second one. What basically distinguishes the two categories is the necessity of a continuous connection. We had to distinguish in order to get through a “technical” problem deriving from the use of mobile devices: the limited feed. Because of these data are requested by the UMP receiver, we thought it was necessary to keep a continuous connection, but to perform some every fixed time intervals. So we chose to focus on the RMC (recommended minimum data for GPS) and GGA (essential fix data which provide 3D location and accuracy data) sentences, as they contain the information needed by

our application: latitude and longitude. Further, the absence of a “fix quality” control in the RMC signal led us to choose the GGA sentences. The next problem was how to send these data to the UMPC. This communication has been implemented by exploiting the Bluetooth technology, a standard industrial specific for Wireless Personal Area Network (WPAN) developed by Ericsson and subsequently formalized by Bluetooth Special Interest Group (SIG). Each Bluetooth device is able to simultaneously handle the communication with other seven devices but, given that it’s a master slave connection, only one at a time could communicate with the server. This problem, together with the security management of the accesses and communication among devices, has been one of the most carefully analyzed aspects: we needed to obtain a secure and unambiguous communication between the GPS receiver and the UMPC, avoiding possible collisions with other Bluetooth devices present in the same area. In our case, the data transfer between the GPS and the UMPC devices is a serial communication, so we chose the SPP (Serial Port Profile) which emulates RS232 communications on serial cable, by using the RFCOMM (Radio Frequency Communication) transport protocol. The JSR-82 specific defines the Java standard for accessing to the Bluetooth technology: it is important to highlight that this specific defines only the interfaces to follow in order to make a standard product. The advantage to follow this standard is essentially to have a stack-and-radio interface-independent source code, but of course this API allows a limited control over the hardware. JSR-82 has been designed in order to be supported by computers with limited resources such as J2ME (Java 2 Micro Edition) based machine. At the same time, it is compatible with the J2SE (Java 2 Standard Edition) platform, allowing Bluetooth to put into communication components developed with J2ME and J2SE environments. The Location Agent potentially can be queried different modules of the system, but basically the requests can belong to one of the following two categories: external to the MAS (that will so pass through the Gateway Agent) and internal to the MAS (that will so come from the Progress Agent). In JADE the activities that an agent can do are called “behaviors”; those designed for the Location Agent are two, and initially were so thought: 1. give coordinates (internally or externally to the MAS) 2. periodically communicate the user position to the Progress Agent, in an autonomous way. In order to optimize the management of the accesses to the GPS receiver, we chose to modify the second behavior typology: the Location Agent instead of directly communicate the coordinates, translates this activity in a request similar to those of behavior 1. In this way the LA must handle similar requests whose management turned out to be more efficient. As first activity, the LA prepares a reply message inserting sender, receiver and typology (if addressed to the PA) or indicating only the typology in case of direct answer. After the preparation of the “template” of the message, the task of the LA is to compute the coordinates. This task has performed by a sub module called Request2GPS, which also provides the final dispatching. The procedure to get a connection URL consists of two phases called Device Discovery and Service Discovery. As we could not keep a continuous connection, these activities would have repeated each attempt, the LA context, however, is that of a UMPC utilized for a cultural visit, so we got the assumption that it requires to always connect with the same GPS device (at least during the visit itinerary of a single user). With such a premise, we established a different strategy: the GPS features are stored in an XML file containing its friendly name and the Bluetooth address. Finally, Location Agent is provided with an “btspp://+bluetoothAddress+parameters” address, such as for example: btspp://000B0D85F496:1;authenticate=false;encrypt=false;master=false. This URL is stored by the Location Agent and used for any further request. The main issue represented by the impossibility to keep a continuous connection with the GPS device has so been

fixed by implementing periodical checks, establishing a connection with the receiver each time coordinates are needed and releasing the connection at the end of the task. In depicting the running of the Location Agent some parameters have been highlighted. These parameters are needed by the agent in order to operate; those parameters have been assigned experimental values, which will be refined and optimized as the trials will proceed. Especially two parameters are very important: the timetocheck value, indicating the time of “ordinary” scan, for our internal test fixed to 30000ms; the chance value, indicating how many attempts to perform before declaring that a GPS signal is not reliable (10 for now). 3.2. User Profile Agent In this phase of the project, the profiling has been handled by a Personal Rating technique without correlation with the other users i.e. by associating a table (keyword/rating) to each visitor, where “rating” is the probability that the user likes venues/activities about the “keyword” category. The profile will be constantly updated by refining the “rating” value as the visitor, both explicitly and implicitly, provides feedback about activities and venues; this feedback will be interpreted by the system and accorded different weights. Typical examples include: when the visitor plans or modifies an itinerary (implicit feedback); gives a score after completing an itinerary item (explicit feedback); accepts or refuses contextual information provided by the system (implicit feedback): in the latter case the value of the feedback will be greater if the user accepts information, because the user expressed an interest, whilst in case of refusal the UA must take into account that reasons behind a refusal may be different and often not strictly due to thematic interests, so the weight given to this feedback will be lower yet still taken into consideration. Implicit feedback is especially important as by following the user behaviors makes “background”-running systems able to dynamically and transparently update the profile. During the first prototype testing a significant set of profiles will be created in this way in order to provide data for a correlation study (to be carried out in the next phase of the project). The advantages offered by the profiling are enjoyable both in “pull” modality, as it let the users to access quickly and sharply desired information, and in “push” modality, as among all the possible information the system could provide, is able to select only those potentially more interesting. The “Personal Rating” term means, as stated before, the profiling process phase where starting by a user and a set of thematic keywords, a first profile has created; this first elaboration, although “raw” will be the basis of the further analyses. During a visit, the profile can be updated following two events: the end of an itinerary item and the reception of contextual information. From these events, there rise three types of modifies, depending on the type of evaluation (explicit or behavioral): • When an itinerary item ends: the user gives a feedback and this is very important as it is a direct expression from the user, so it’s no doubt founded. This is an evaluation that expresses an explicit opinion, and which is given a weight called “1”; the relevancy of this weight is not comparable with that called “A” and used previously, as although they are both explicit, they belong to different contexts: “A” is used to assign an absolute evaluation, whilst “1” to make refinements. • Each time the system provides contextual information: the user behavior is monitored, both the suggestion is accepted, and be refused. In the first case the importance of the feedback “2” is much greater (although lesser than the value of “1”), because the user expressed an implicit interest, whilst in the second case by assigning the weight “3” it is important to consider that the reasons for a refusal can be different and often not strictly connected to the real thematic contents, so the value given to this feedback will be lesser but yet considered.

The User Profile Agent has been designed to perform two basic tasks: 1. Give the profile or part of the user characteristics to the requesters, internal or external to MAS; 2. Modify the profile, also in a dynamic way. To fill the first task, the User Profile Agent behavior is slightly different from that of the Location Agent, especially because the tasks of the two agents have a different origin: the Location Agent has to provide the same information (the coordinates) to who requested for, the User Profile Agent can receive two different requests; the requests are: 1. give user characteristics (to the IM) 2. give the profile (for now, to the PA) To fill the first request is easy, as it consists in extracting from the database the so called “Characteristics” of the user previously depicted and giving in answer, always through the Gateway Agent, to the Itinerary Manager. But it’s from the analysis of the second request that we discovered the utility of this approach. As explained in the following chapter, the Progress Agent asks for the user profile to the User Profile Agent when precise situations that may have provoked modifies to the profile itself occur. This behavior has been studied in order to model when an external source modifies the characteristics of a user, and desires to notify this information to the Progress Agent which monitors him. In this way whatever profile computing request has addressed to the related Progress Agent, the only that theoretically has the right to receive it. The choice of “provide“ each user with an exclusive agent handling his profile derives from the design of the profiling system as depicted in the previous chapter, especially in view of the upcoming Collaborative Filtering phase. 3.3. Progress Agent The localization and the profiling elements are the basis of the Progress Module, also based upon two running contexts: • The first only includes the localization and is utilized by the POI Module in order to response at the requests concerning the Points of Interest, and by the RSS Module in order to provide information about weather and transports. • The second integrates both localization and the user profile in order to let the Progress Module the supply of contextual information. There are different cases where contextual information are required or provided: • The visitor during the itinerary is approaching a venue not present in the planned visit itinerary but with thematic characteristics very adherent to the preferences in his profile. In this case, the Progress Module provides the contextual information. • The user selects an icon to obtain further information about what interesting venues are in the closeness. A query about the Points of Interest has so performed to the POI Module. • The system could also provide other type of information, if available, as weather and road condition, which could make the visitor to re-plan the itinerary. This task is handled by the RSS Module. As far as the contextual information, the Progress Agent prepares and provides them to the Gateway Agent, which exposes them, through a web service, to the Itinerary Manager. One of the most relevant aspects is the dispatch timing of the contextual information. The adopted strategy is the result of two main conditions, which must be followed at the same time in order to proceed with the dispatching:

1. A certain time period has to be passed. 2. The user must have covered a certain distance. As far as the first aspect, the Location Agent periodically sends the user position to the Progress Agent, so the interval between the scans has been adapted. The concept of “optimal distance” covered (since the last sending), instead, requires some further consideration: at the moment T1 and position LP (Last Position) the user received the last notification; the contextual information have been provided by only considering those present in his Area of Interest, A1, the circle area centered in LP with ray Range1. All the information present in A1 have been “filtered” and the most relevant have been presented, so it would not be timely to take into consideration the information present in that area. The next search will occur at the instant T2, while the user will be located at the position CP (Current Position), and will concern an area A2 of the same ray (Range1). To allow A1 and A2 have empty intersection, the “optimal distance” covered by the user between LP e CP will have to be at least the double of the areas ray. Let Range2 be this distance. A1 - Area of interest centered in LP

LP

A2 - Area of interest centered in CP

RANGE1

RANGE1

A1

CP

A2

T1

T2 RANGE2

Fig. 1 – Computing of the optimal distance Range2

At T1 the Progress Agent provided contextual information to the user localized in LP; after the predecided period of time, at T2 the Location Agent sends the coordinates CP. The Progress Agent within the MAS has a twofold role: it is the agent which has to provide the contextual information, besides has the task of “coordinator” of the other agents. The major issue concerns the use of a mobile device, as it is much likely a visit could continuously use it for many hours. Although the modern UMPC be powerful, they still have very limited power resources, so it is clear that it is necessary to reduce at minimum the request for resources. Once started, the Progress Agent waits for messages and performs two types of different control as the possible incoming messages may be of two categories, each with a different management, depending on their origin: • From the Gateway Agent: the messages do not contain information or data, but only indicate “actions” to perform. The message can contain start, stop or contextinfo • From the other agents: messages contain information (profile or coordinates). After the Progress Agent did activate (or reactivate) the other agents, ideally starts his main task; it is important to remark that messages can also be categorized depending on the potential order of reception: • At the beginning, only the “start” message can arrive from the Gateway Agent (the other agents are inactive); afterwards the Progress Agent starts the User profile Agent (whom immediately ask the profile) and the Location Agent

• •

Until the Location Agent do not provide a message containing valid coordinates, the Progress Agent cannot compute the contextual information, and so cannot satisfy such requests When a “stop” message from the Gateway Agent arrives, no more messages can be received until a “start” message arrives.

The Progress Agent uses the messages received from the Location Agent in order to understand if it is the right moment to provide contextual information to the user. At this point two important checks are performed: • Integrity: do the coordinates represent an effective GPS position? • Optimality: Was the optimal distance between Range2 covered? The check for optimality requires an external module, called Distance, implemented in order to compute the metric distance between two different GPS positions. Let s and f be the two GPS positions between which we want calculate the distance, and the respective latitudes and longitudes; by using the trigonometric properties: To obtain the Great-Circle distance formula we still miss a parameter: the law, whose final formula , requires the range of the “sphere“, that is the Earth. We chose the Quadratic Mean Radius is with the best approximation: 6.372,795477598 km. The check for optimality has so performed by passing the current coordinates and those contained in LastPosition; the return value is compared with the Range2 parameter and if results lesser, the Progress Agent establishes that it is too soon for send a contextual information. Otherwise, it means that the two checks have been ok and then the PA must search for useful information to give to the user.

Progress Agent

Distance calculate LastPosition

LAT

integrity

optimality

Find

LON

Location Agent …

…

CooOb

…

Range2

Fig. 2 – The messages coming from the LA must overcome the integrity and optimality checks

The search for contextual information uses a module called findCI, which returns a CIObj (Contextual Information Object) object, containing: • the XML description of the most relevant information • the distance from them • a method for convert the previous in the correct XML format. The findCI module is the most important PA sub-module as it contains the logic which detects and categorizes the relevant information for the user; indeed the Progress Agent exposes: • the position, so detecting the area of “interest”, where searching for information; • a profile, represented by a list of keywords ordered according to the user preferences.

This search module decides how to “filter” the information, following the idea that the keywords associated to the visitor are a lot and consider all of them make the search operation too heavy, and that according to the “n” keywords with the bigger score it is possible to make a selection much adherent to the real preferences of the user. At this point, the Itinerary Planner, through the Gateway Agent, is notified that information is available. The IP alerts the user and if this is interested, requests for them.

4. Conclusions In conclusion, while the trials are on going, we already obtained some technical outcomes, especially in what concerns the use of JADE multi-agent systems for auto-localization and dynamic profiling techniques. The main feature of the Progress Module is the application of an agent model for the development of location-based services and exploiting wireless technologies. The advantages of our solution are basically three: • The agent model allows a rational subdivision of the tasks amongst many autonomous and collaborative components. • Contextual information is provided not only depending on the geographical location, but also considering the interests and preferences of the user. • The Progress Module allows a dynamic management of the visit itinerary. The more relevant perspective of future development may be summarized in three points: • Distributed agents: an interesting property of the agents developed in JADE is the possibility to easily migrate between different running environments. A smart distribution of the agents can be obtained by exploiting the LEAP (Lightweight Extensible Agent Platform) libraries implementation of JADE, which provides the same API of the “traditional” system using a runtime environment modified in order to be utilized on device mobiles. • Continuous localization: in case of future UMPC enhancements, it will be possible use a system of continuous localization for the user, by exploiting the very important characteristics of GPS localization: the sentences generated by the receiver, in case of continuous communication, can provide other functionalities such as the current direction and the view angle, which would allow a further improvement of the quality of the information and services. In such a case, indeed, the “area of interest”, that currently is the circle one centered on the user current position, could be refined of about 75%, considering the shifts of the user and keeping into account the direction of origin. • Profiling: the further profiling phase, called Collaborative Filtering, will utilize the outcomes from the current Personal Rating phase and apply the concepts of similarity to extract the more relevant data in view of improve the current profiling.

5. References [1] F.BELLIFEMINE, G.Caire, D.Greenwood, Developing Multi-agent Systems with JADE, Wiley Series in Agent Technology - Wiley. 2007. [2] M.WOOLDRIDGE, N.R. Jennings. Intelligent agents: Theory and practise, The Knowledge Engineering Review 10, 2 p.115-152. 1995.