Integrated Profile and Policy Management for Mobile-oriented Internet Services

The CARE middleware architecture

A subproject of WEB-MINDS: Wide-scalE, Broadband, MIddleware for Network Distributed Services. FIRB project N.RBNE01WEJT_005, MIUR (Italian Ministry for University and Research). Nov. 2002 - Oct. 2006.

Project Scope

Internet services rely on profile data for delivering personalized content to users. Profiles provide a description of the user interacting with the service; ideally, a profile should include all attributes useful to improve the outcome of the personalization process.

Mobile users are typically described by more attributes than those needed by other categories of users. Besides personal preferences, a profile should include descriptions of the device, of the network infrastructure, of the user location, and of the socio-cultural context in which the user is involved. In practice, these attributes are managed by different entities - such as the service provider, the network operator, or the user itself. At present, service providers can provide limited personalization since they are unable to collect all attributes relevant for adapting their services.
Fig.1: Proper user and service provider policies can determine the resolution in a streaming video service.
Mobility also emphasizes the need for modeling the dynamics of some of the profile attributes. For example, changes in the supported bandwidth (due, e.g., to a switch to a different mobile device) should correspond to a change in the value of the attributes specifying the desired bitrate for streaming video services. The same need might also occur with attributes related to user preferences; for example, when the format of messages being received (say, text or voice) is specified depending on the mobile device being used. A natural approach to the modeling of this dynamics is augmenting the profile attributes with policies; that is, rules that set or change certain profile attributes based on the current values of other profile attributes (see Fig.1).

The CARE (Context Aggregation and REasoning) middleware architecture enables an integrated representation and handling of profile information, including user, device, network, and context descriptions as well as a mechanism to resolve conflicts in static and dynamic descriptions. In particular, our approach is focused on the representation and management of distributed profile data and on the representation and evaluation of policies to dynamically change these data. The distinctive features of our approach are:

  1. a notion of profile data that goes beyond the representation of user personal data and preferences by including information on the device, its current status, the network infrastructure, the current socio-cultural context and the content involved in the service request;
  2. a formalism to represent user and service provider policies describing the dynamics of profile data;
  3. a mechanism to retrieve and compose profile data and policies from different sources;
  4. an efficiently implementable strategy to resolve conflicts on policies and profile attributes;
  5. a trigger-based mechanism for the adaptation of continuous services.


The information in our extended profile is owned by various entities located in different logical and physical places. We identified three main entities involved in the task of building an integrated profile, namely: the user and his devices (called user), the network operator (called operator), and the service provider. Every entity is associated with a Profile Manager (called UPM, OPM, and SPPM respectively) devoted to manage profile data and policies.

Fig.2:Overview of the CARE middleware architecture

In particular: The UPM and SPPM are also in charge of managing local adaptation policies, and of interacting with ontology services.

A high-level description of the system behavior is more easily illustrated by mentioning the main steps involved in a typical service request (see Fig.2).

  1. A user, through his device and the connectivity offered by a network operator, issues a request to a service provider.
  2. The service provider asks the Context Provider module to obtain the context information needed to handle the request.
  3. The Context Provider module queries the profile managers to retrieve remote profiles and policies.
  4. The Merge module aggregates profile data resolving possible conflicts by means of priorities. Then, the Inference Engine (IE) evaluates service provider and user policies against the merged profile data, possibly resolving conflicts. The resulting profile attributes are then returned to the service provider. These attribute values are used by the application logic to properly select content and customize its presentation.
  5. Finally, the formatted content is sent to the user.

In Fig.2 a dashed line from an entity to a profile manager indicates that the entity has the ability to update the profile data and policies stored by that profile manager.

Profile Management and Aggregation

In order to aggregate profile information, data retrieved from the different entities must be represented using a well defined schema, providing a mean to understand the semantics of the data. As a language for representing context information we adopted the Composite Capabilities/Preference Profiles (CC/PP) structure and vocabularies, with possible references to OWL classes and relations.

Once the Context Provider has obtained profile data from the other profile managers, this information is passed to the Merge, which is in charge of profile integration. Conflicts can arise when different values are given for the same attribute. For example, the UPM could assign to the Coordinates attribute a certain value x (obtained through the GPS of the user's device), while the OPM could provide for the same attribute a different value y, obtained through triangulation. In order to resolve this type of conflict, the Service Provider has to specify resolution rules at the attribute level in the form of priorities among entities. Priorities are defined by profile resolution directives which associate to every attribute an ordered list of profile managers. This means that, for instance, a service provider willing to obtain the most accurate value for user's location can give preference to the value supplied by the UPM while keeping the value provided by the OPM just in case the value from the UPM is totally missing.

Adaptation Policies

Adaptation policies can be declared by both the service provider and the user. In particular, service providers can declare policies in order to dynamically personalize and adapt their services considering explicit profile data. For example, a service provider can choose the appropriate resolution for an image to be sent to the user, depending both on user preferences and on current available bandwidth. Similarly, users can declare policies in order to dynamically change their preferences regarding content and presentation depending on some parameters. For instance, a user may prefer to receive high resolution media when working on his palm device, while choosing low resolution media when using a WAP phone. Both service providers and users' policies determine new profile data by analyzing profile attribute values retrieved from the aggregated profile.

Since policies can dynamically change the value of an attribute that may have an explicit value in a profile, or that may be changed by some other policies, they introduce nontrivial conflicts. They can be determined by policies and/or by explicit attribute values given by the same entity or by different entities. For each class of possible conflicts, we have devised a proper conflict resolution strategy, which is implemented in our policy language. A direct evaluation algorithm for policies in our language has been developed, that is linear in the number of rules.

Adaptation of Continuous Services

In order to include in the adaptation process the dynamics of network- and user-side data which may change during the continuous media provision, the CARE middleware includes an asynchronous notification mechanism based on triggers. Triggers in this case are essentially conditions over changes in profile data (e.g., available bandwidth dropping below a certain threshold, or a generic change in the userís activity) which fire a notification when met. In particular, when a trigger fires, the corresponding profile manager sends the new values of the modified attributes to the Context Provider module, which should then re-evaluate the policies.

Fig.3:Trigger mechanism

Fig.3 shows an overview of the mechanism. To ensure that only useful update information is sent to the service provider, a deep knowledge of the service characteristics and requirements is needed. As a consequence, the conditions upon notifications are set by the service provider application logic, and communicated to the Context Provider, which appropriately forwards them to the profile managers. Moreover, since most of the events monitored by trigger settings sent to the UPM are generated by the user device, the UPM communicates the settings to a server module resident on the device. Devices are equipped with an application monitoring the state of the device against the received triggers (called Monitor in Fig.3). Each time a profile manager receives an update that fires a trigger, it forwards the update to the Context Provider. Finally, the integrated profile is re-computed, and possible changes in context data are communicated to the application logic, that can properly adapt the service.

Experiments with an Adaptive Multimedia Streamer

Video captures of the experiments reported in "Distributed Context Monitoring for the Adaptation of Continuous Services", World Wide Web Journal (WWWJ), Special issue on Multi-channel Adaptive Information Systems on the World Wide Web (to appear).

Results with no adaptation, and variable bandwidth: no-adaptation.mpg

Results with our adaptive streamer, and variable bandwidth: care-adaptation.mpg

Note: the VLC media player is needed to display the videos.


Book chapters:




International conferences:


International workshops:


Public Demonstrations