Home | AGAPE Framework | Documents | People Involved | Acknowledgements | Download

[Prev] [ToC] [Next]

The AGAPE Framework

AGAPE supports the design, development and deployment of context-aware collaborative applications in MANET environments. Collaboration in AGAPE is based on the metaphor of group: only entities that are member of the same group can interoperate. We here detail the AGAPE group membership management and group communication models.

The AGAPE Group Membership Management Model

The AGAPE group membership management model allows users to create, to join and to leave from a specific group and to receive the list of currently co-located group members along with their attributes and characteristics (context-dependent view). 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. 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.

Figure1. The AGAPE Model

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 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.

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. Figure 1 depicts that different localities may overlap due to the physical proximity of their LMEs.

The AGAPE Communication Model

AGAPE group members interoperate by exploiting the AGAPE context-aware group communication support. In particular, AGAPE enables group members to exploit the following two basic patterns:

  • context-based any-cast communication pattern that enables unreliable and asynchronous point-to-point communication between two interoperating group members. When one group member has to communicate, one and only one co-located member entity that matches a specified profile is selected;
  • context-based multi-cast communication pattern that enables unreliable and asynchronous point-tomultipoint communication among various interoperating group members. In particular, the pattern permits to deliver the same message to all the co-located entities matching a desired profile.

It is worth stressing that these communication patterns can serve as a basis either to obtain more specific patterns, such as traditional point-to-point and point-tomultipoint group communication patterns, or to build more complex patterns, e.g., tuple spaces, with reliability, atomicity and synchronicity properties.

[Prev] [ToC] [Next]

DEIS - Alma Mater Studiorum University of Bologna