support collaborative applications in MANETs [2], [3],. [4], [5]. All solutions share the common design principle to consider user location as the key grouping ...
Enabling Context-Aware Group Collaboration in MANETs Dario Bottazzi, Antonio Corradi, Rebecca Montanari Dipartimento di Elettronica, Informatica e Sistemistica University of Bologna Viale Risorgimento 2, 40136 Bologna, Italy {dbottazzi, acorradi, rmontanari}@deis.unibo.it Abstract
for users to establish anytime and anywhere impromptu collaboration. Several novel MANET-enabled application scenarios, such as emergency rescue, e-care, are starting to emerge that require users located on the same network locality to arrange/dissolve groups on demand and to join/leave locally available groups of their interest in order to temporarily collaborate toward common interests and/or goals. However, the design, development, and deployment of collaborative services in MANET environments raise complex group management issues. Traditional group membership systems can hardly support group management operations in MANETs [1]. They typically assume fixed reliable networks with rare link failures and network partitions and with very limited changes in user location, access devices and environment operating conditions during group members interactions. The unreliable and asynchronous nature of MANET environments undermines several assumptions of traditional group management systems and requires to investigate novel solutions that follow different design guidelines. The topology of the network cannot be statically determined making it difficult a priori assumptions on the availability and status of the collaborating entities. Group members appear and disappear in an unpredictable manner and often change their location during the execution of group activities. Disconnection and network partitioning are common events that cause frequent changes in the set of available group members and transient group members interactions. In addition, group members in MANET scenarios typically operate from resourceconstrained devices that cannot tolerate the heavy-weight computational and network overhead typically introduced by traditional group management middleware solutions. Several research efforts are underway to construct the kind of group management infrastructures required to support collaborative applications in MANETs [2], [3], [4], [5]. All solutions share the common design principle to consider user location as the key grouping criteria: users can collaborate and are assumed to belong to the same group as long as they are co-located. The main underlying assumption is that users located in physical proximity are likely to collaborate together more often
Recent advances in Mobile Ad-Hoc Networks (MANET) technologies promote new opportunities for anytime and anywhere impromptu collaboration and leverage the provisioning of novel collaborative services, such as emergency rescue, e-care, and troop car management. However, the design and deployment of collaborative services in MANET environments raise new group management challenges. In particular, unpredictable users/devices mobility, frequent disconnection/reconnection of devices and continuous changes in network topology call for novel middleware solutions to handle properly the transient and dynamic formation of ad-hoc groups. The paper proposes a context-aware group membership middleware (AGAPE) that bases group management decisions depending on context information, such as user location, user attributes and preferences, and access device properties. User location determines the scope of group member visibility within a network locality, whereas user requirements and device properties govern the joining to a group and influence the played role of a user within a group. AGAPE provides a set of support services to arrange/dissolve and manage ad-hoc groups on demand and propagates the visibility of available group members and of their context up to the application level to allow applications to adapt collaborative decisions and actions accordingly. The paper also presents a MANET-enabled emergency rescue application scenario to show and to evaluate the functioning of AGAPE..
1. Introduction The increasing diffusion of portable devices with both fixed and wireless connectivity, the widespread availability of network accessibility in living, working and amusement environments, and the emergence of Mobile Ad-Hoc Networks (MANETs) create novel opportunities .
This investigation is supported by MIUR within the framework of the FIRB Project “WEB-MINDS” and by the CNR within the framework of the Strategic Project “IS-MANET”.
0-7803-8963-8/05/$20.00 ©2005 IEEE
310
than with users located in different physical network areas. This paper pushes even further this idea by proposing to consider not only user location, but also other context information, such as user preferences and device properties, as first-class design principles for organizing effective group management strategies. Novel group membership solutions should provide and propagate up to the application level the visibility of all co-located group members along with their user preferences and device properties (user/device profiles). The visibility of user profiles allows to create logical groups that assemble together users (and related devices) that are not only colocated, but also share common interests, preferences, activities and goals. In addition, in MANET environments where there is no predefined knowledge about group member identities that are likely to collaborate and where group member’s names are uninformative being impossible to guarantee name identity uniqueness, it seems more viable to exploit profile information, instead of name, to discover neighbour group members [6]. Novel group management solutions should also take into account the heterogeneity of access devices. The visibility of device profiles permits to customize group management services depending on the properties of user access devices to differentiate group management roles and activities among group members. The paper shows the implementation of these ideas within the AGAPE (Allocation and Group Aware Pervasive Environment) framework that provides a set of support services for the design and the deployment of collaborative applications in MANET environments. In particular, AGAPE allows close users with common interests to create and join ad-hoc groups and provides all the needed facilities to propagate up to the application level the visibility of context-dependent group member views, i.e., of co-located users along with their user/device profiles. In addition, the AGAPE framework takes into account differentiated computing capacity of access devices. In particular, in AGAPE only devices with rich resource capabilities support group membership management operations, such as group creation, group joining and context-dependent view creation/update distribution, whereas user devices with poor resource capabilities exploit the group management support provided by rich devices to affiliate to a group and to collaborate with co-located group members. The AGAPE framework described in this paper evolved out from our previous work on context-aware collaboration in pervasive environments and extends the middleware of [7] with the support specific to handle group management in MANETs. The rest of the paper is organized as it follows. Section 2 presents the AGAPE framework and Section 3 shows the middleware architecture. Section 4 provides some relevant AGAPE implementation details in several
network operating conditions, Section 5 shows the functioning and evaluation of the AGAPE middleware in the context of an emergency rescue application scenario and, finally, concluding remarks follow.
2. The AGAPE framework AGAPE is a context-aware group management framework that allows users to create, to join and to leave from a specific group and to receive views of co-located group members. The set of members that compose an AGAPE group is not a-priori determined, but dynamically changes due to the joining/leaving of members. User mobility and temporary user device disconnection cause changes only in the context-dependent views that each group member is provided with, but not in the group membership. When a user enters, leaves or disconnects from a network locality, AGAPE reports the context view change to all co-located group members. When a group member moves from one locality to another, AGAPE is in charge of providing the roaming group member with the group context-dependent view of the new locality. Contextdependent views have the main advantage of being rapidly and directly available even in the case of network partitions. If a network partition occurs, at least the neighbour users that are listed in the view and that belong to the same partition can continue to collaborate. A global view of group members can also be provided, when needed, via the merging of all local views obtained through the coordination of AGAPE middleware components in each locality. However, it is worth to outline that the AGAPE group model relaxes the need for global agreement on group members and for group views consistency. Frequent network partitions, user/device disconnection and change of location make inefficient and even unviable to ensure a global and consistent view of all group members. Each group is characterized by a group unique identifier (GID) and by a group profile that specifies interests, preferences, activities and goals that should be commonly agreed by all its members. Each group member has a personal identifier (PID), which is (statistically) unique within a group and by a profile that expresses user/device attributes and characteristics, along with group preferences in term of group activities, tasks and goals. As Figure 1 shows, the AGAPE group model recognizes two entity roles: the Managed Entity (ME) and the Locality Manager Entity (LME) role. MEs are group members that exploit the AGAPE group management support services to collaborate. LMEs are group members that not only collaborate, but also support group management operations on behalf of MEs: they promote the run-time creation of a new group, allow entities to join a group and maintain an updated list of co-located
311
ME 14
ME 11
LME 4 ME 13
ME 2
Lo ca lit y1
Lo ca lit y4
group members. At any time, LMEs and MEs can join/leave groups of their interest. However, at each time MEs can belong to at most one single group, but at different instant times they are allowed to switch their membership to other groups. This approach permits to limit the resource consumption, and in particular memory use, on resource-constrained devices. AGAPE groups are partitioned in different localities. Each LME supports group management operations for only the group members placed within its locality. The locality is defined as the set of all AGAPE entities whose devices are connected to the LME device by a route path of a maximum length of h hops. The LME represents the center of one locality identified by the LME PID and its geographical coordinates. The value h expresses the maximum radius of a locality measured in network hops. The value of h is chosen on the basis of the application scenario. Locality2 ME 4
LME 2
ME 1 LME 1
The Basic Service layer includes low-level functionality to allow devices to access the Mobile Ad-Hoc network, to support naming, active discovery of groups and group members, and to monitor member availability status. In particular, the Network Manager Service (NMS) provides the needed support to group members to exchange messages via the Mobile Ad-Hoc network. NMS implements both point-to-point and multipoint communication patterns. The NMS point-to-point communication support permits to send messages to a host identified by a known IP. The NMS multipoint communication support permits to broadcast the same message to several AGAPE entities. NMS multipoint communication support extends the probabilistic flooding gossiping protocol to limit message dissemination within a defined number of hops by introducing mechanism based on a TTL [8]. In particular, NMS marks messages with a TTL field that is decremented at each hop. Only messages with a nonzero TTL value may be re-broadcasted. Let us note that the probabilistic nature of gossip-based data dissemination provides a best effort approach to the delivery of the message to all neighbours. The NMS also provides local queuing of incoming and outcoming messages that are managed according to a FIFO policy. The Proximity Service (PS) permits AGAPE group members—both LMEs and MEs—to advertise their online availability in one locality. At regular times the service requires NMS to gossip a beacon message that includes the GID/PIDs of the entity, the played role by the entity within the groups, and the entity IP address. The time between two successive beacons can be set/adjusted according to both application-specific requirements and the mobility of nodes. In particular, the beacon transmission frequency should increase with the mobility of user/devices. Let us note that PS relies on NMS for beacon dissemination. There is only a probabilistic guarantee that all group members in one locality receive disseminated beacons. The probability of beacon reception depends on the network topology and on the probability of message re-transmission of the NMS probabilistic flooding protocol. The Proximity Enabled Naming Service (PENS) randomly generates statistically unique group identifiers (GIDs) and entities personal identifiers (PIDs) by exploiting a naming approach similar to the one proposed for P2P environments [9]. In addition, PENS senses incoming beacons from co-located LMEs/MEs and builds a table of currently available co-located LME/MEs. Each table entry contains the GID/PID of the associated AGAPE entity, its played role (LME or ME) and its IP address. In addition, each table entry is associated with a timestamp. If PENS does not receive beacons from a member entity within a defined threshold, the associated
Locality3 ME 10
ME 7
ME 8
LME 3 ME 5 ME 3
ME 12
3.1. Basic Service Layer
ME 6
ME 9
MANET
Figure 1. The AGAPE model (h = 2 hops). Figure 1 depicts different localities, with each locality containing LMEs and MEs. As the figure shows, different localities may also overlap due to physical proximity of different LMEs. MEs can roam freely and may belong to more than one locality at any time. In addition, it may happen that two LMEs define the same locality, e.g. in the case that two LMEs are allocated at 1 hop distance.
3. The AGAPE context-aware communication support AGAPE group membership management services are organized in two logical layers built on top of the Java Virtual Machine (see Figure 2). AGAPE
Application J/LMS PENS
VMS PS
CHDS BCKS
Group Management Layer
PENS
PS
CHDS NMS
Basic Service Layer
JVM HW – Network – OS
Figure 2. The AGAPE architecture.
312
entry is removed and the entity device is considered disconnected.
due to variations in user/profiles and/or used access devices. However, these changes typically occur rarely. When an entity, both ME and LME, changes its profile information, she delegates the VMS to update the context-dependent view accordingly. In particular, the entity provides VMS with the new profile to be included into the new view update. Let us note that VMS guarantees a probabilistic group view consistency. This is due to the fact that VMS relies on the probabilistic gossiping protocols for beacon dissemination to sense the availability of co-located group members and to build group views. The BaCKup Service (BCKS) allows LMEs to decide whether to distribute or not context-dependent views. BKCS helps to reduce un-necessary view propagation, for instance, when multiple LMEs belonging to the same group and defining the same locality attempt to disseminate all the same view to co-located group members. In particular, each time one LME attempts to disseminate its context-dependent view, it requires the permission to the BCKS. BCKS compares the entries of the group views received from co-located LMEs. If the received views do not include the same entries, BKCS allows all LMEs to disseminate their context-dependent views. If the received views are the same, BKCS allows only one LME to propagate the view. The LME that can send the view is the one that has in its view the battery level information higher than a pre-defined threshold. If all LMEs have the same battery levels, BKCS selects the one with the highest PID.
3.2. Group Management Layer The group management layer provides required services to discover, to create and to dissolve groups. In particular, the Join/Leave Manager Service (J/LMS) allows AGAPE entities (LMEs and MEs) to arrange, to discover, to join and to leave a group. LMEs exploit J/LMS to dynamically promote the formation of new groups. The promotion of a new group requires the specification of the group profile at the application level. The J/LMS to coordinates with the PENS in order to obtain the group GID and the group member PID, with the PS to advertise the new group availability and with the VMS to setup a new group view. Both LMEs and MEs can exploit the J/LMS to discover and join a group of interest. The group discovery phase requires the J/LMS to coordinate with PENS to obtain the list of available group LMEs. AGAPE non-member entities exploit J/LMS to attempt to join available groups of interest. In order to join a new group the entity must specify a desired group profile at the application level. If the specified profile matches with the available group profile, the entity is allowed into the group. Whenever a new member has joined the group the J/LMS returns it its GID/PID (by coordinating with the PENS), along with the full group profile. J/LMS also permits members, both LMEs and MEs, to leave a previously joined group by specifying the group GID. J/LMS coordinates with other AGAPE services, e.g., PS and VMS in order to stop PS from sending the leaving entityrelated beacons, and to delegate VMS to delete any information related to the group member, e.g., GID/PID, its user/device profiles. The View Manager Service (VMS) permits LMEs to create and disseminates group views to AGAPE group members at regular times. Each group member receives a view (context-dependent view) that contains the list of only the group members located within the scope of their responsible LME locality. In particular, each contextdependent view includes the PID/GID and the device battery level of the LME that has generated it and is composed of a list of entries that associate each group member reference (obtained from PENS) with user, device/group profile information (obtained from J/LMS). When group members connect or disconnect from the network or when they change access device and/or group profile, AGAPE reports the view changes to all group members into the locality by exploiting the broadcast facility implemented by the NMS. The VMS coordinates with PENS to obtain the notification of events, such as arrival, departure and disconnection of a group member entity. In particular, these events cause VMS to update the group view accordingly, by inserting/removing the new/old member entity. In addition, views can change
4. Implementation details We have developed two different AGAPE middleware prototypes. One release supports LME management operations and includes all AGAPE services. This release fits portable devices, such as lap-tops with rich computational resources (large amount of memory, file system, powerful cpu, and long-life batteries). The other available release supports ME operations and includes only a subset of AGAPE support services: J/LMS and VMS client side, along with the PS, PENS and NMS.
Figure 3. AGAPE at work in different conditions.
313
This section details the implementation and functioning of some AGAPE group management services that support the dynamic formation and the management of adhoc groups, i.e., J/LMS, VMS and BCKS. The principle that has driven AGAPE services implementation is resource optimisation to take into account the limitations of current portable devices. In particular, we here detail how AGAPE J/LMS, VMS and BCKS work in some important operating scenarios, such in the case of co-located LMEs belonging to the same group, and in the case of not co-located LMEs belonging to the same group that define partially overlapping localities, and in the case of partitioned localities. Let us note that these operating conditions are common in real scenarios, e.g. in dense MANETs in emergency rescue scenarios where a large number of close users operate via heterogeneous devices.
View Propagation. Both LME1 and LME2 maintain an updated group view of all currently available members in their localities. At regular time intervals, both VMSs instances on LME1 and in LME2 devices attempt to propagate group views to all members in Locality 1 and Locality 2. To propagate group views, each VMS has to ask for the permission to the locally available BCKS instance. In particular, before NME1 joins the group, LME2 is allowed to disseminate its group view to all members in Locality 2 whereas LME1 is prevented from doing it. The BCKS instance of LME1 recognises that the group view of LME1 is a subset of the one received from LME2. When NME1 joins the group (by contacting LME1), the leading LME for view propagation changes. When the VMS of LME1 includes the new member entity (NME1) in its group view the BCKS of LME1 recognises that NME1 is not contained into the group view received by LME2 and allows also LME1 to propagate its view to the members in Locality 1. A transient phase occurs: both LME1 and LME2 transmit their views to all members. In particular, LME2 receives the view from LME1. The VMS of LME2 scans the received view, recognises that a new member entity NME1 is not part of its locally maintained group view, and it verifies whether NME1 is placed in Locality 2 (by coordinating with the PENS). As depicted from Figure 3A, NME1 is placed in Locality 2 and, thus, LME2 includes NME1 into its group view. When LME2 disseminates its group view to all members in Locality 2, LME1 receives also the group view (being placed within the same locality). When the VMS of LME1 attempts to propagate its group view, it is prevented from doing it because the received group view from LME2 includes NME1. Similar consideration apply both in the case NME1 plays the role of ME and LME. At normal operating conditions all group members co-located within Locality 2 (including those belonging to Locality 1), receive context-dependent views from LME2. However, when NME1 joins the group, all members in Locality 1 experience a transient phase where they receive group views from both LME1 and LME2. During this phase the members in Locality 1 merge two incoming views from LME1 and LME2. This solution permits to save memory on resourceconstrained devices but leads to battery degradation due to required computation for merging incoming views. However, different solutions are also possible, e.g. to maintain two distinct table respectively associated to incoming views from LME1 and LME2. The choice depends on the required tradeoffs between memory, CPU and battery saving. Roaming. Let us consider now a member entity ME1 belonging to the same group of LME1 and LME2 (see Figure 3A) that enters in the Locality 2. The VMS instance of ME1 senses incoming context-dependent view
4.1. Nested Localities Figure 3A shows an operating situation where two LMEs (LME1 and LME2) belong to the same group, i.e. have the same GID, and define two nested localities, with Locality 1 contained within Locality 2. Let us note that LME devices run all AGAPE services whereas ME devices run only a sub-set of AGAPE support services (J/LMS and VMS client side, along with the PS, PENS and NMS). Joining. Let us consider the case of the non-member entity NME1 that enters in Locality 1 and is willing to join a group of its interest. The J/LMS instance on NME1 device obtains the list of all LMEs in Locality 1, i.e., LME1 and LME2, along with their GIDs, PIDs and IPs. The J/LMS of NME1 scans the obtained list and recognises that both LME1 and LME2 belong to the same group (because they have the same GID). The J/LMS randomly selects one of the two, e.g. LME1, to join the group. The J/LMS instance of NME1 sends a request to join message to LME1 that includes group preferences (in term of group goals and activities), along with NME1 user and device profiles. Upon message reception, the J/MS of LME1 checks whether requested group attributes match with the group preferences expressed by NME1. If LME1 belongs to a group of NME1 interest, LME1 allows the entity into the group and yields back to NME1 an acknowledge message that includes the new member GID/PID, obtained from PENS, along with the full group profile. In addition the J/LMS of LME1 coordinates with the VME to include NME1 profile into the group view. Let us note, that the joining protocol is designed to save ME resources (cpu, memory and battery). When possible, joining operations are delegated to LMEs, e.g., all the profile matching computation necessary for not member to join a group. Delegation plays an important role especially when one ME is willing to join a group of interest and a large number of LMEs are available.
314
updates from LME2 and recognizes that it is not included into the LME2 group view. To aggregate to the local group, the VMS instance of ME1 sends its full profile information (obtained from its J/LMS) to LME2. Upon reception of the profile LME2 includes ME1 into its context-dependent view. Similar considerations apply for LMEs roaming among different localities.
their context-dependent view. Similar consideration apply for the LMEs roaming among different localities. 4.3. Partitioned Localities Figure 3C shows an operating situation where two LMEs (LME1 and LME2) belong to the same group and define two nested localities, with Locality 1 contained within Locality 2. Due to device mobility, Locality 1 and Locality 2 partition. Joining. Let us consider the case of the non-member entity NME1 that enters in the locality defined by LME1 and is willing to join a group of its interest. The J/LMS instance on the NME1 device obtains the list of all available LMEs, i.e. only LME1. The J/LMS of NME1 attempts to join the group by requesting for the permission to LME1. Similar joining operations occur if the entity is placed within the locality defined by LME2. View Propagation. Figure 3C shows that following to the locality partitioning LME1 and LME2 are not colocated and define two distinct localities. In addition LME1 and LME2 cannot communicate their contextdependent views to each other. The BCKS of both LME1 and LME2 allows their VMSs to propagate the group views to the members of their localities. Roaming. Let us consider now a member entity ME1 belonging to the same group of LME1 and LME2 that moves from the locality of LME1 to the locality of LME2. On the one hand, LME1 stops sensing incoming beacons from ME1 and, as a consequence, it deletes the entry associated to ME1 from the view. On the other hand, the VMS instance installed on ME1 senses incoming context-dependent view updates from LME2 and recognizes that it is not included in the group view. To aggregate to the Locality 2, ME1 sends its full profile information to LME2. Upon reception of the profile LME2 includes ME1 in the context-dependent view. Similar considerations apply for the LMEs roaming among different localities.
4.2. Partially Overlapping Localities Figure 3B shows an operating situation where LME1 and LME2 belonging to the same group define two localities, respectively Locality 1 and Locality 2 that partially overlap. The members located into the intersection of the two localities are included both in the group view of LME1 and in the group view of LME2. Joining. Let us consider the case of the non-member entity NME1 that enters in the intersection between Locality 1 and Locality 2, and is willing to join a group of its interest. The J/LMS instance on the NME1 device obtains the list of all available LMEs, i.e. LME1 and LME2. The J/LMS of NME1 scans the obtained list, recognises that both LME1 and LME2 belong to the same group and randomly selects one of the two to join the group, e.g. LME1. Similar joining operations occur to the case depicted in section 5.1. View Propagation. Figure 3B shows that LME1 and LME2 are not co-located and, as a consequence they cannot communicate their context-dependent views to each other. The BCKS of both LME1 and LME2 allows their VMSs to propagate the group views to the members of Locality 1 and Locality 2. It is straightforward to notice that all members on the intersection between Locality 1 and Locality 2 receive views from both LME1 and LME2. These members merge the incoming views from both the localities into the same table on the basis of GID/PID field included into each view entry. Let us note that the new member entity NME1 is included only into the context-dependent of LME1 into Locality 1. When NME1 receives the view disseminated by LME2 it recognizes that it is not included into the view of LME2. It is up to NME1 to trigger LME2 view update. NME1 sends its full profile information (obtained from its J/LMS) to LME2. Upon reception of the profile, LME2 includes NME1 into context-dependent view of Locality 2. Roaming. Let us consider now a member entity ME3 belonging to the same group of LME1 and LME2 (see Figure 3B) that enters in the intersection of Locality 1 and Locality 2. The VMS instance of ME3 senses incoming context-dependent view updates from both LME1 and LME2 and recognizes that it is not included in their group view. To aggregate to the group ME3 sends its full profile information both to LME1 and to LME2. Upon reception of the profile the two LMEs includes ME1 in
5. Case study We have tested and evaluated AGAPE in the design and implementation of a simplified emergency rescue application prototype that enables the impromptu interoperation between co-located firemen. The application aggregates together firemen working within the same area, provides them with the visibility of the colleagues and allows them to communicate instructions or images, such as maps and building plans, via messages exchanges. Firemen typically must make important decisions in short time by relaying on incomplete information. The increased possibility to communicate with colocated colleagues can facilitate firemen decisionmaking. Firemen can promptly ask colleagues for all
315
details that are necessary to have a clear picture of the intervention scenario. Let us note that the possibility to exchange written messages is of paramount importance for disseminating instructions and warning in this scenario. In fact, firemen often operate in noisy environments and require the visibility of neighbour colleagues that operate in the same area [10]. The application prototype exploits CC/PP-compliant profiles to describe fireman, device and group properties. Firemen use a para-military organization with welldefined ranks, such as captain, lieutenant and engineer, that represent a set of responsibilities. The firemen profiles of the implemented prototype include only firemen’s name and rank. Device profiles represent the features of the used access device, whereas group profiles identify the goals of the fire brigade community. Firemen of high rank, such as captains and lieutenants, operate from lap-tops that run Linux, J2SE 1.4 and the AGAPE release for resource rich devices. All other entities operate from iPAQ PDAs running Linux Familiar, Personal Java and the AGAPE release for resourceconstrained devices. In the realised prototype test-bed firemen interoperate via a MANET dynamically constituted by portable devices equipped with IEEE 802.11b wireless cards. Application
J/LMS
VMS
BCKS
PENS
NMS
PS Generate GID/PID
Request of GID/PID
Promote a Group
VMS installed on the captain device cannot receive context-dependent views from other LMEs and it is the one that has to propagate a context-dependent view that includes only the captain GID/PID and profile. All PDAs connected to the MANET that are placed within the captain locality acquire the visibility the captain LME. The other firemen (lieutenant, engineers and so on) specify a required group profile, i.e. “Firemen”, the user profile, e.g. “Bob, Engineer” and attempt to join the group promoted by the captain’s device (see Figure 4B). The J/LMS service installed on firemen PDAs discover the LME by coordinating with the locally available PENS instance. Moreover, the firemen asks the LME to join the group. The J/LMS instance installed on the captain device allows the new member to enter the group. It also coordinates with the locally available PENS for obtaining a PID for new members and, finally, returns an acknowledge message. In addition, the J/LMS installed on the captain device coordinates with locally available VMS and provides it with the profile data of new members to be included it into the context-dependent view. In real scenarios, it is frequent for several high rank firemen, e.g. captains and lieutenants, to operate in the same locality. Let us now focus on a lieutenant operating via her lap-top who has joined the group and is colocated with the captain device. Upon joining, the VMS of the lieutenant device senses incoming views from the VMS running on the captain device. The VMS on the lieutenant device coordinates with the PENS to build its own group view by associating profile data (from the incoming views) with the currently on-line members in its locality. Being co-located, the VMS running on the captain device has a view equivalent to the one of the VMS running on lieutenant device. At regular intervals, the lieutenant VMS asks locally available BCKS for permission to propagate its view, but the BCKS does not allow the view dissemination. Let us suppose that the captain device moves away from the locality. The VMS on the lieutenant device stops receiving incoming views from the captain LME. The VMS on the lieutenant device requires its locally installed BCKS instance for permission to propagate the group view (Figure 4C). When the BCKS allows the lieutenant device to disseminate the group view and, as a consequence, its VMS starts propagating its locally maintained view.
Return GID/PID Send Beacon
Advertise Group Setup Group View
Send Beacon Send Beacon
Outcoming Message Outcoming Message
Outcoming Message
A A
Application
J/LMS
VMS
PENS
Receive Beacon
Request of the List of Co-Located LMEs Request to Join a Group
PS
NMS
VMS
Incoming Message
Outcoming Message
Receive Group Acknowledge
Incoming Message
Incoming Message
Incoming Message
Receive Context-Dependent View
Request of Permission
Receive Beacon
Incoming Message
Return Permission
Outcoming Message Receive Group View Incoming Message
Receive Beacon
Return the List of Co-Located Entities
Start Sending Beacons
Setup Group Views
NMS
PENS
Request of the List of Co-Located Entities
Return of the List of Co-Located LMEs Request to Join a Group
BCKS
Send Group View
Outcoming Message
B B
C C
Figure 4. Service interaction in AGAPE Let us show the functioning of AGAPE services in the case of a fire alert. Firemen receive a request for intervention and drive to the scene of fire. While approaching the fire scene the captain promotes the dynamic formation of the firemen group, on the field (see Figure 4A). The application client module of the captain device allows him to specify the group profile—in our example “Firemen”—along with the user profile attributes—for example “Tom, Captain”. His operator lap-top acts as a LME and exploits the locally installed PENS to generate the GID/PID, the VMS to initialise context-dependent views and the PS to advertise the on-line availability of the new group. Since no other LMEs are available, the
5.1. Experimental Results Evaluation AGAPE introduces different forms of overhead depending on the different AGAPE functions involved, from the joining of new members to profile dissemination to members roaming into new localities, from context-dependent view propagation to beacon dissemination.
316
During the testing of the emergency rescue prototype, we have carried out a number of measurements to evaluate the functioning of AGAPE and to quantify the AGAPE service overhead. In particular, we here focus on the tests that we have conducted to evaluate the consistency level of group views that we can obtain with our probabilistic group membership management. Let us note that emergency rescue scenarios typically require highly consistent group views. It is therefore important to evaluate whether the adoption of AGAPE view management approach can achieve the required consistency level. We also report the memory overhead to support beacon dissemination and view management. These tests allow to evaluate whether the AGAPE group support solution can be exploited in application scenarios that involve different and heterogeneous access devices, from resource-rich to resource-constrained devices. Our test-bed is constituted by a locality composed of 1 lap-top acting as LME and a variable number of iPaq PDAs playing the ME role. All devices are equipped with Cisco Aironet 802.11 wireless network cards. All our experimental measurements refer to stationary operating conditions, i.e. without device mobility, with a fixed interval time between two consecutive beacons (10 seconds) and between the dissemination of two consecutive views (40 seconds).
been obtained by varying the probability p for an entity to re-transmit a received beacon. In particular we have varied the value of p (by ranging its value from 0.5 to 1). We have also varied the threshold time tt within the LME should receive beacons from a member not to remove the member from the group view. In particular, we have tested tt values of 20, 30 and 40 seconds. For each value of p and tt we have measured the probability for ME4 to be removed from the group view. Table 1 presents the results of these tests.
tt p
20
30
40
0.5 0.6 0.7 0.8 0.9 1
0.01440 0.001728 0.00020736 0.0081 0.000729 0.00006561 0.0036 0.000216 0.00001296 0.0009 0.000027 0.00000081 0.0009 0.000027 0.00000081 0.00000000 0.00000000 0.00000000 Table 1. Measured results for the ordinary operating scenario. Worst Case Operating Scenario. In the worst case operating conditions only one routing path connects the different hosts. Figure 5B shows a locality composed of 5 members. ME1 is directly connected to LME1 and, consequently, it is always in visibility of LME1, while ME2, ME3 and ME4 are connected to LME1 through a multihop path and, as a consequence, their membership is managed with probabilistic guarantees. We have measured the probability for ME2, ME3 and ME4 to be excluded from the current view due to the AGAPE probabilistic group management. We varied the probability p for an entity to re-transmit a received beacon by ranging its value from 0.5 to 1. We have also varied the threshold time tt by testing values of 20, 30 and 40 seconds. For each value of p and tt we have measured the probability for ME2, ME3 and ME4 to be removed from the group view. Table 2 presents the results of these tests.
5.1.1. Group Membership Reliability. We have measured the probability of group management inconsistencies by logging the incoming beacons from all MEs received by LME1. All MEs disseminate beacons at regular time. By analyzing the log file it is possible to determine the number of missing beacons from a given ME along with the number of missing consecutive beacons. The basis of our measurements is constituted by tests with runs of 500 beacons.
Figure 5. Connectivity graph of the test-bed.
tt
Ordinary Operating Scenario. Figure 5A depicts a case of ordinary operating conditions where several routing paths connect the different hosts. Figure 5A shows a locality composed of 5 members belonging to the same group. ME1, ME2, and ME3 are directly connected to LME1 and, consequently, they are always in visibility of LME1 unless they disconnect. On the other hand, ME4 is connected to LME1 through 2-hops long routing paths and, as a consequence, its membership is managed by LME1 with probabilistic guarantees. We have measured the probability for ME4 to be excluded from the current view due to the AGAPE probabilistic group management. Our measurements have
p 0.5 0.6 0.7 0.8 0.9 1
20
30
40
0.210161 0.055163 0.015707 0.212450 0.049769 0.012958 0.136698 0.026234 0.005496 0.092515 0.017490 0.003686 0.045889 0.006632 0.001037 0.001241 0.000032 0.000001 Table 2. Measured results for the worst case scenario.
317
Discussion. Our results show that growing values of p and tt reduce the inconsistencies in group membership management. However, the network topology plays an important role into the evaluation of inconsistencies introduced by our probabilistic group management. Let us note that according to the application requirements it is possible to tune the group management behavior by properly setup p and tt parameters.
ration among previously unknown users by exploiting the visibility of group members context. We are currently validating our middleware in a wide variety of collaborative scenarios. The first experiences in the use of AGAPE have demonstrated its suitability in the implementation of collaborative services in Mobile Ad-Hoc environments. These early results are stimulating further research along different guidelines to improve the current prototype. In particular, we are currently working on the improvement of AGAPE protocols to adapt to frequently changing and heterogeneous network operating conditions. We are also investigating the security concerns raised by group management and starting to integrate initial security support services in AGAPE. Finally, we are also integrating in AGAPE a support to enable point-to-point and multipoint group communication.
5.1.2. Memory Requirements. We have measured the memory occupied for a ME to support beacon and view management in order to evaluate AGAPE suitability for resource constrained devices. With regard to beacon management, the main factor that impacts on memory occupation is the table that associates any available AGAPE entity with an entry containing its GID/PID, its role (ME or LME) and its IP address. Each table entry is 21 bytes in size. Context-dependent views can also require a high memory capacity. The memory occupation is determined by the list that stores the views. In particular, each entry in the list has an average size of 520 bytes. In particular, we have measured the memory required by one ME placed in a locality constituted by a variable number of group member entities (5, 10, 15 and 20 members). Similar considerations apply to LMEs. Table 3 shows the memory usage for beacon and view management Group Members
5
10
15
20
Beacon Management
105 B
210 B
315 B
420 B
View Management
2600 B
5200 B
7800 B 10400B
References [1] D. Powell (ed.), Group Communication, Special Issue on Group Communications, Communications of the ACM, ACM Press, Vol. 49, No.4, April, 1996. [2] R. Prakash, et al., “Architecture for Group Communication in Mobile Systems”, in Proc. of the 17th IEEE Symposium on Reliable Distributed Systems (SRDS 1998), IEEE Press, Indiana, October, 1998. [3] Q. Huang, et al., “Relying on Safe Distance to Ensure Consistent Group Membership in Ad-Hoc Networks”, Technical Report WUCS-01-31, Washington University, Department of Computer Science, Missouri, 2001. [4] R. Friedman, “Fuzzy Group Membership”, in Proc. of the International Workshop on Future Directions in Distributed Computing (FuDiCo 2002), Springer-Verlag LNCS 2584, June, 2002. [5] R. Meier, et al., “Towards Proximity Group Communication”, in Proc. of the Workshop on Middleware for Mobile Computing, ACM Press, Germany, November, 2001. [6] F. Cristian, “Reaching Agreement on Processor Group Membership in Synchronous Distributed Systems”, Distributed Computing, Vol. 4, No. 4, Springer-Verlag, April, 1991. [7] D. Bottazzi, et. al., “AGAPE: a Location-aware Group Membership Middleware for Pervasive Computing Environments”, in Proc. of the 8th IEEE International Symposium on Computers and Communication (ISCC 2003), IEEE Press, Turkey, July, 2003. [8] Z.J. Haas, et. al, “Gossip-based Ad-Hoc Routing”, in Proc. of the 21st Annual Joint Conference of the IEEE Computers and Communication Societies (Infocom 2002), IEEE Press, New York, June, 2002. [9] A. Rowstron, et. al, "Pastry: Scalable, Distributed Object Location and Routing for Large-scale Peer-to-Peer Systems", in Proc. of the 4th International Conference on Distributed Systems Platforms (Middleware) (IFIP/ACM), ACM Press, Germany, November, 2001. [10] X. Jiang, at. al., “Ubiquitous Computing for Firefighters: Field Studies and Prototypes of Large Displays for Incident Command”, in Proc. of the 23rd Conference on Human Factors in Computing Systems (CHI 2004), ACM Press, Austria, April, 2004.
Table 3. Memory occupation for beacon and view management. Discussion. The measurements show that the memory required both for beacon and view management linearly grows with the number of members into the locality. The above measurements show that AGAPE requires a limited amount of memory to properly work. Our measurements show that, AGAPE permits the management of localities constituted by a large number of member. Let us note that, according to our results, a locality of 100 members requires the availability of the memory of almost 512 KBytes on each member device.
6. Conclusions and ongoing work Group membership management in MANETs raises novel challenges that require the design and development of advanced support solutions. AGAPE is a novel group membership framework that enables impromptu collabo-
318
