1. Introduction

The challenge with mobile, distributed computing is that it exploits the user’s dynamic environment with a new category of applications that are aware of the context in which they run. As context we define the combination of information relevant to the nearest environment of a user, such as the user location, the serving network, his terminal device, etc. Context-aware applications present information and services to a user, as well as automatically execute services and commands, sensing context and its changes. Changes of the contextual environment, are modelled as events, and are communicated to the application for real-time service re-adaptation.

A context-aware service takes into account the current context of the user and based on this information adapts its behaviour to the respective user needs including personal preferences and environmental capabilities[1][2]. The contextual information can be encoded in various related profiles such as, the user preferences profile and the terminal, ambient, network, and service profiles. The combination of all these profiles constitutes the User Profile [3][4].

The issue of adapting service provision and providing personalized services based on user preferences is what3GPP introduced in Virtual Home Environment (VHE)[5].

VHE is a concept for Personal Service Environment (PSE) portability across network boundaries and between terminals. Primary aim of VHE is to consistently present users with the same personalized features, User Interface customisation and services in whatever network and whatever terminal (within the capabilities of the terminal and the network), wherever the user may be located. VHE is enabled by user profiles since they encode parameters that are essential to the user, such as the users’ preferences for communication and service presentation on the terminal.

In particular, the User Preferences profile encodes desirable service provision features that are particular to an individual user. User preferences can be categorized into service-independent, which apply to all services that are accessed by the user and service-specific, which pertain to a particular application. The user preferences may include a broad range of attributes related to i) the perceived QoS requirements, like desired voice quality in phone calls, audio/video quality for streaming applications, or the degree of resolution for images, ii) the languages that the user prefers, iii) the content and media presentation characteristics (e.g., text vs. audio vs. video), iv) font sizes, v) tariffing/billing, vi) privacy and security, vii) favorite geographical zones, viii) user identity, including name, gender, profession, ix) user presence information, x) user history and calendar, etc..

Since profiling information is exchanged among different administrative boundaries, to assure interoperability the XML[6] and the other XML-like languages (e.g., WSDL[7], SMIL[8], OWL[9]) are the best candidates for describing profiles. Moreover, profiles should be laconic so they are efficiently transmitted. In situated–aware architectures user profiles must be dynamically composed since their constituting segments may be distributed. Contextual profiles influence greatly service deployment and execution, since context-aware services should adapt to context and related updates.

To enable third parties to develop context-aware services over PLMNs, various efforts have been undertaken by standardization working groups and fora towards the introduction of open, network-independent interfaces enabling context retrieval[10]-[13][36]. These interfaces provide applications with transparent access to network functionality (e.g., call control, location information, messaging, profiles retrieval), thus offering third party application developers the opportunity to create advanced, network-independent and context-full services with standard software engineering tools and general-purpose programming languages.

Let us now illustrate how all these technologies above should ideally work assuming a hypothetical, but realistic, service provision scenario. Let assume that a mobile user is receiving real-time video news from an application provider using a large-screen WLAN-enabled laptop while at home. As the mobile user is boarding a vehicle to his office and changes from the large-screen terminal to a portable 3G phone, a context information server in the service support centre notifies the application of the location and the terminal and radio access update. Application successfully recognizes, by the user’s profile or after interacting with the user, the user wish to change content (media) from video to text and a media converter executes content conversion.

The above is only one example of requirements for the flexible, customized, context-aware and ubiquitous multimedia service provision to mobile users that the evolution of mobile communication systems to beyond 3G networking introduces. Definitely, in a system that aims to provide flexible and context aware service provision and adaptation, the knowledge of the system status as well as the various entities’ states and events are significant factors. One must be able to know at any given time the network status, the user location, the profiles of the various entities (users, terminals, network equipment, services) involved and the policies that are employed within the system. Namely, the system must be able to cope with a large amount of context information.

However, in order for this scenario to be optimally and operationally deployed in real life, several technological requirements should be met by the involved infrastructures including:

• A sensing infrastructure effectively monitors the context of the user (location, terminal, Radio Access Technology (RAT)) and notifies the application whenever the applicable context changes.

• The preferences of the user with respect to the application provision should be, at least, location-dependant, so the application retrieves the applicable application customisation set whenever the context changes.

• This implies that the favourite geographical areas of the user should have, at first, been defined and then, for each of these areas the respective sets of user preferences for application customization within areas have been defined and corresponded to them.

• The application scenario is defined in a standardized document, which describes all the alternative provisioning and media adaptation aspects it can support.

Figure 1. Context awareness without (a) and with (b) mediation

All these requirements further burden service provisioning. So far, the most intelligent applications customize only once their content to the user preferences, taking into account only the starting context of the user, when he at first requests the provision of the application. As the user moves from one context to another, service provision remains unaware of context changes, unless user declares this. Even context aware services, which monitor periodically the updates at the user context, are not able to dynamically adapt content to current user preferences, since in the most existing frameworks for service provision the user preferences profiles are handled as static documents missing any relation to the updates of the user context [14]-[22]. Hence, the requirements two and three of the above application execution scenario are not fulfilled in current application provision models. Obviously, something should be added in the service provisioning chain to bridge the missing links.

On the other hand, taking into account that development and deployment for end-user applications should be kept as simple as it can, as well as that the additional intelligence required by these applications towards context awareness should be minimal, it is induced that the certain additional intelligence required should be transferred from applications to networks or middleware applications[2]. Furthermore, most of the requirements above concern some provisioning attributes and components common to most context aware applications. Hence, it would be beneficial, in terms of minimizing complexity and potential useless interactions, if some common services and components were offered to open access, so these can be reused and shared among interested parties or applications. For example, an infrastructure provided for context monitoring and events notification can be easily shared by several applications. The same states also for some user profiling issues, since the information related to the favourite geographical zones of a user or its generic preferences for services consumption could be shared among authorised applications of the specific user. The latter issues enhance our position for transferring the intelligence required for context awareness from applications to a middleware layer. This aspect is illustrated in Figure 1. Adopting amiddleware layer with open access to authorised applications and assigning to it the required intelligence for context awareness, it simplifies and facilitates adaptation to context as well as development, composition and deployment of context aware applications. Additionally, it minimizes redundant interactions between applications and underlying network infrastructure.

Our work attempts to complement existing works and standards so that requirements above can be met. Present paper focuses on location and context awareness in service provisioning and proposes an open and shared middleware framework that enables efficient management of location and context information. Furthermore, a more flexible and innovative model for user profiling is introduced that facilitates adaptation to context. The innovation is based on the enrichment of common user profiling architectures to include the location and other contextual attributes, so enhanced adaptability and personalization can be achieved. The generic model, the structure and the content of that location-sensitive User Profile, along with some related implementation issues, are discussed. In specific, section 2 introduces to the concept of context- sensitive user profiling and section 3 presents the proposed framework for context aware service provision. Section 4 illustrates itsfunctionality via a realistic implementation paradigm of service provision. Section 5 discusses our motivations and, finally, section 6 concludes the paper.

2. Towards Context-Sensitive User Profiling

The User Profile is a key means to provide subscribers with truly location aware and customised services. Additionally to the service deployment and execution mechanisms, which take the user location into consideration, the management of user profiles can be also location sensitive. Location awareness in User Profiling can be based on the concept of user-defined Home Zones. Each Home Zone comprises a geographical area into which a user wishes to experience personalized and customised service provisioning (e.g., the Home, the office, the car)[23]. Ideally a Home Zone should be as wide as the user wishes, so that truly customisation can be achieved. For example, a user may wish to experience differentiate service provision in each room of his house or office. In such a case each room should be considered as distinct Home Zone for that user. However, limitations in the location measurement accuracy induced currently by various positioning technologies, forbid Location Based Services (LBS) to distinguish among very narrow Home Zones. Due to this fact, certain distance among the defined Home Zones of a user, depending on the accuracy of the location measurements, should exist, so the position detection system can follow the moves of subscribers from one Home Zone to another. In the near future, when the location estimation technologies mature further, location based services shall provide users with more accurate positioning and Home Zone definition.

In the proposed framework the location-sensitive user profiles are managed by the User Profile Manager (UPM) assisted by the available location and context sensors of the underlying infrastructure. Location sensor will be identified hereafter as the Location Manager. In this context, personalization and customisation during service provision is achieved by discriminating the user preferences according to the location (e.g., Home, work) of the user and by maintaining different User Preferences Profiles (or Service Customisation Sets) for each instance (e.g., Home-, work- dependent profiles). Other contextual parameters that can be also taken into account are the serving RAT, the type of the Mobile Equipment (ME), the time of the day, or the presence status[24] of the user (e.g., lazy- or work- or mood- specific). These attributes constitute the user context. For each context an associated User Preferences Profile is created and hence, service provision is adapted to the User Preferences Profile instance that better apply to the current user context.

Figure 2. Home Zone-sensitive user profiling

Figure 3. Context-Sensitive User Profiling

Figure 2 depicts the approach of Home Zone-sensitive user profiling. Each user is associated with a single User Profile that contains general information for the subscriber such as his general user preferences, the available terminal capabilities, the subscribed network capabilities, etc[3]-[4]. That User Profile consists of several, Home Zone-dependent, Profile instances that inherit from the User Profile and contain various, Home Zone-dependent, personal attributes such as the QoS values related to home use or traveling. A user may have one or more instances (or Service Customisation Sets) of a specific Home Zone profile; each individually customised by the user and associated, for example, with a specific time or period of the day or other context attributes. Each Service Customisation Set includes the applicable user preferences, with respect to the User Interface preferences, the Browser appearance, the preferred memory usage etc., and the service subscription Profiles, with the preferred settings for the subscribed services (e.g., for pricing) and associated privacy policies. The user experiences service offering according to the current active Service Customisation Set.

From that point of view a Home Zone-sensitive User Profile can be considered as a tree with the subscriber's identity (e.g., his IMSI, e-mail, SIP or IMS identity) at the root, the Home Zone and context attributes as nodes and the service customisation sets as leaves. Storing locally such a tree-like User Profile for each subscriber, finding his current Home Zone and context and crossing that tree from top to down, the UPM can retrieve the most up-to-date user profiling data each time it is required.

Although in Figure 2 only the Home Zone and time attributes are taken into account in the user preferences selection, additional contextual parameters could be used for better elaboration and specification. To this end, in Figure 3, apart from the “Home Zone” attribute, the “ME Type” and the “serving RAT type” context attributes are also used for further profile elaboration. Taking into account that within a single Home Zone a subscriber can switch from one type of mobile equipment to another (e.g., from a UMTS mobile handset to a PDA or laptop) and access different radio environments (e.g., from GPRS or UMTS networks to WLAN/WiFi or Bluetooth), further classification of user profiles within a Home Zone can be achieved. This is why we consider that the attributes of: current Home Zone, current ME and current serving RAT of a subscriber are the three key context attributes that uniquely identify the current context of a user. Hence, we define each triplet of type {current Home Zone, current ME, current RAT} as the user specific Context Zone that can be used for identifying the user status and customizing the service provisioning to him accordingly. Obviously, the concept of Home Zones is broader than Context Zones, since within a single Home Zone several distinct Context Zone might be defined.

In this context, each subscriber upon registration with the proposed platform specifies his applicable Home Zones describing each one of them with addresses or street names. It is then up to the Location Manager of the platform to map the Home Zones specified by the user to the appropriate geographical coordinates or network areas (e.g. cell Ids, Location or Routing Areas), making use of a data base with the appropriate spatial information. Thus, whenever a user enters the platform and accesses an application, the UPM retrieves the current location and the required context attributes of the user in order to identify the Context Zone he is currently situated in and to retrieve the user preferences that apply to this specific Home Zone and context. This has as result only the profile that better applies to the current Context Zone and status of the user to be taken into account, customizing the whole service provisioning accordingly. It is implicit that the user is always prompted to confirm the User Profile instance selection or alternatively to choose the one he desires.

Then, each time the subscriber specifies a new user preferences set, it is associated with the current Context Zone of the subscriber or the Home Zone and context indicated by the subscriber. For each new Home Zone or context value (e.g., new ME, or new RAT) is defined, a new node in the tree is inserted. Equally, for each new customisation profile a new leave is added to the tree. Definitely, a user preferences customisation set can be associated with more than one Home Zones and contexts, if the user wishes. For each active subscriber the UPM stores locally a data structure that represents the tree of his location sensitive User Profile. The data itself is not included. Instead a reference to the repository that stores each profile is kept, along with a unique data reference generated upon data creation and storage. The Home Zone and the context attributes are used by UPM to identify the path to the active profile data. To this end, a pointer that crosses the User Profile tree and points to the active customisation profiles is created for each user. The pointer is updated each time a change on active Home Zone and context occurs. Figure 4 illustrates the specification of a new user preferences set for a user and its correlation with specific Home Zone and context attributes (defining the path to the associated profiling data in the User Profile tree). This data structure is inserted in the User Profile tree of the specific subscriber constituting a new leave in the User Profile structure. After insertion, this data structure will, also, be the result of search of UPM in this User Profile tree for the “General Preferences” profile of the subscriber that corresponds to the designated Home Zone and context. Retrieving this data, the UPM can, then, access the corresponding profile repository (specified by the referenced profile URI) to retrieve profile GP112x.

Figure 4. Specification of a new user preferences set

Figure 5. User Profile instance transition induced by change in Home Zones

Figure 6. Example semantic implementation of a Context sensitive User Profile

Hence, whenever a user accesses an application, the application requests by the UPM the applicable preferences set of the user. The UPM, then, retrieves the user location in order to identify the current Home Zone of the user, along with the context attributes required for profile identification (e.g., the ME type and the type of the serving RAT) to identify the current context zone and the applicable profile instance of the user and, finally, to retrieve by the corresponding repository the user preferences set that applies to the specific context. It is implicit that the user is always prompted to confirm the User Profile instance selection or alternatively to choose the one he desires. The UPM stores locally the current Context Zone of each user for later use and faster searching in the User Profile tree.

During service access, Location Manager and other context sensors track location and other context attributes of the user and upon entrance in or exit from a Context Zone an appropriate notification is sent to the UPM notifying it for the new Context Zone the user entered. The UPM, then, retrieves the applicable user preferences in the new Context Zone of the user in order to announce them to the executing applications by the user and enable them to tailor service provisioning to the user accordingly. Figure 5 illustrates a User Profile instance transition induced by some change in Home Zones. As the user moves from Home Zone 1 to Home Zone 3, it leads to a change of his current context from Context Zone 1 (Home Zone 1, Mobile Equipment 1, Radio Access 2) to Context Zone 2 (Home Zone 3, Mobile Equipment 1, Radio Access 2), which in turn leads to a different user preferences set (from User Preferences Set N to User Preferences Set 2). Such a change of the active User Profile instance triggers the UPM to generate and propagate an associated alert event, so that the applications and modules registered for receiving such alerts are properly informed.

Figure 6 illustrates an instance of an example semantic implementation of a Home Zone and context sensitive User Profile. In this implementation, the user preferences of the subscriber are discriminated according to the two Home Zones established for him (Home Zone 1, Home Zone 2), as well as his two different ME types (ME Type 1, ME type 2) and serving RAT Types (RAT Type 1, RAT Type 2). For each context zone (Home Zone, ME, RAT) a default option is created for allowing service provision whenever the user location and context attributes do not match the established options. Although in a real scenario it is not required, all possible combinations (or Context Zones) of the three context attributes have been enabled for better specification and elaboration. For each such Context Zone, the General Preferences profile and the User Preferences profiles for Applications XYZ and ZXY are defined. This basic implementation for user profiling considers the existence of various DEFAULT user preferences profiles (in terms of default general preferences and default applications profiles), upon which the subscriber can specify and customize later its own profiles. Upon initiating the user profile of a subscriber, the DEFAULT profiles are associated with all applicable Context Zones of the user, so that service provision is permanently enabled. In Figure 6 the profile GP000 represents the default general preferences profile and the profile XYZ000 the default user preferences profile for application XYZ. We remind here, that in a real scenario only the context zone instances with special meaning to the user in terms of its preferences should be included as paths in its user profile tree. A different, simpler, implementation of the same user profile tree can include only the context paths that conclude to preferences profiles different from the default ones. In such a case, all remaining context zone instances are considered that correspond to the default preferences profiles. In any case, to identify the applicable requested customisation set, the UPM compares the current Home Zone and context of the user (retrieved by the Location Manager and the context sensors of the framework) against the Home Zones and context attributes of the user that act as nodes in his User Profile tree. After finding the correct context path in the User Profile tree, the UPM searches among the available preferences profiles to identify the one requested by the requesting application. The tab is used to this end.

3. Middleware Framework for Context- Aware Service Provision

Figure 7 illustrates the proposed generic middleware framework for accommodating the required intelligence for context awareness and location-sensitive user profiling, which mediates between applications and consumersfacilitating adaptation to context and development, composition and deployment of mobile applications.

The framework comprises a component inherent to each context-aware application or service, namely theservice/application logic component that orchestrates the adaptability of applications to context. Whenever an authorised user requests access to a specific service, it takes as input updated contextual information for the user from the User Profile Manager (UPM), the Location Manager, and the other context sensors in forms of profiles (to name the user profile, the user location, the terminal capabilities, and the network profile) along with the presentation profile of the requested service (the service profile). In parallel, theService/Application logic registers itself to the UPM, Location Manager and context sensors for receiving event notifications concerning updates to the active user preferences profiles and the current context of the requesting user, respectively. Then, based on the encoded information included in the contextual profiles it filters the service profile document to generate a customized service presentation profile adapted to the current context. The generated presentation profile is propagated to the service execution engine that is responsible for compiling and executing the commands in the incoming profile. This task can include the retrieval of the appropriate multimedia content from the content repositories in the exact format that is indicated in the presentation profile, the interaction with the content adaptation services for transcoding or translating some media files, the composition of media files according to the indicated presentation format, the packaging and forwarding of the produced result to the requesting user[1]. In case that user location or some context parameter change while the user executes the service, or changes the applicable user preferences profile as an implication of the location or the context change, an associated notification reaches the service logic and the operation described above is repeated. Based on the updated context and preferences profile information a new service presentation profile is generated for the user and the service execution is adapted accordingly. For example, if the incoming event notification indicates that a user has exited his home to drive to his office, the service logic is advised by UPM of the new user preferences for service consumption in the new situation or geographical area of the user, modifies the service presentation profile accordingly and instructs the service execution component to perform the required adaptations (a video to text conversion for example).

It is worth noticing, here, that the proposed framework can also accommodate non context-sensitive applications. These applications simply register themselves with the UPM to receive notifications with the current user preferences of their subscribers. Taking, however, into account, that in our UPM the user preferences profiles are context sensitive, we conclude that our framework can enhance the context unaware applications with contextual characteristics.

The User Profile Manager (UPM) is responsible for managing the context-sensitive User Profiling data and providing user-specific information to the requesting applications/services.

The Location and Presence Manager constitutes anindependent module of the framework responsible for retrieving, managing, interpreting and exploiting the information related to the location, presence and mobility of the subscribers. Hence, it interacts with the location and presence information’s sources of the underlying network infrastructure to track the location and presence of subscribers[23]-[26].

The context sensing components are considered to be the service/application interface to the context sources. The context information (e.g., network performance metrics or Mobile Equipment (ME) and Radio Access Technology (RAT)-specific, or location- and presence- specific) can be equally retrieved through either a private sensor network, or the OSA/PARLAY Application Programming Interfaces (APIs)[11]-[12] that might be provided by the underlying network infrastructure to the authorised applications (applicable only to OSA/PARLAY-aware applications).

The context interpretation components translate the raw contextual information retrieved from the context sources to the high-level and user specific information required for personalized adaptation. For example, location interpretation can translate the geographical coordinates taken from a GPS device to a street address or the applicable favourite zone (Home Zone)[14] of the positioned user.

Figure 7. Proposed framework for context aware service provision

The content adaptation services are responsible for adapting media content to the current content. They include various media processing technologies used to increase content accessibility and improve users’ experience within heterogeneous networking environments. They can transcode, compress, or convert media content according to the characteristics of the client display (e.g., screen size and color depth), current network parameters (e.g., the available bandwidth), and specific user preference (e.g., low resolution images and video or audio tracks instead of video.

With respect to the business placement of our framework we adopt the shared middleware aspect illustrated in Figure 1. Hence, all modules of Figure 7 constitute an open distributed middleware layer that is shared among registered applications. The module of service/application logic, in particular, is considered to be an application portal which hosts applications from various developers and/or third party providers. Applications registered with the portal can be discovered and executed by the portal subscribers. Although in Figure 7 all modules are depicted to belong to the same business authority, it is not necessary. Hence, the service/application logic is might administered by a third party Application/Service Provider (ASP) and the rest modules by a mobile network operator.

4. Adaptation to the Context – An Implementation Paradigm

In general, the service/application logic can host all applications of the client-server paradigm. Such a service will typically consist of code that runs in the end-user terminal (service client) and optionally a server (stationary) part[27]. The former includes the service user interface. It can be pre-installed in the terminal, or downloaded and executed on demand. The latter case is aligned with the dynamic nature of service provision desired for the systems beyond 3G. Service execution, normally, includes interaction with the server part. For example, a game could be a standalone application, while a streaming audio/video service and online gaming involve communication with remote servers. The Service/Application Execution module of Figure 7 can be physically located in the premises of the corresponding ASP (e.g., a web server). Multi-tier architectures will be also commonplace, where the server part comprises many interacting components. These components may be located in the administrative domains of entities other than the ASP, like content providers marketing access to their databases, or network operators providing interfaces to network functionality (e.g., OSA, Parlay, JAIN).

With the proposed framework, services will in general come in many versions (editions), so they are available for users accessing them with various types of terminals and having diverse preferences. In particular, different implementations of the service client part and the components it includes (e.g., different versions of an image for devices with different screen sizes), targeting different contexts, will be dynamically available. Essentially, in a service there is some core functionality, present in all versions/configurations and optional/adaptable part dynamically tailored to the contextual conditions. This generic model is depicted in Figure 8. The modularity of that architecture facilitates the adaptation tasks. Adding and removing components from the architecture can achieve different service compositions and physical distribution configurations.

Figure 8. Generic Service/Application architecture

With respect to the presentation profiles of applications, that is the service profile described in section 3, we believe that SMIL-based implementations[8] are really advantageous, offering many useful attributes towards adaptation and personalization. In fact, we have adopted the philosophy of work in[28] and[38] to this end. For example, a SMIL-based presentation profile can include all the alternative formats of each comprising multimedia element of an application, so that the corresponding application logic selects the multimedia format that fits its current execution context.

Figure 9. SMIL-encoded service presentation profile for application XYZ

In the following we attempt to present via a realistic service execution example how our framework filters the SMIL-encoded service presentation (SP) profile for the hypothetical and context unaware Application XYZ based on the Home Zone, RAT, ME and user preferences profiles. The framework orchestrates the provision of Application XYZ to the requesting user. Figure 9 illustrates the service presentation profile for Application XYZ.

Application XYZ includes various multimedia elements such as the audio/video stream of a presentation in English. The stream can be subtitled; there are subtitles available in three different languages. Moreover, Application XYZ includes a song and a related picture in various resolutions.

Figure 10. User preferences profile of a user in context zone (Home, Laptop, WLAN) for Application ΧΥΖ

At first, we consider that an authenticated user with the user preferences profile of Figure 10 requests the Application ΧΥΖ and that the service logic of Application XYZ accesses the UPM for profiling information. The UPM recognizes via the Location Server and the context sensors that the current context zone of the subscriber is (Home, Laptop, WLAN) and provides to the service logic of Application XYZ the corresponding user preferences profile along with the related ME (laptop) and RAT (WLAN) profiles. The service logic of Application XYZ, in turn, filters SP based on these profiles and produces SP*. Figure 11 depicts the filtered presentation profile SP*. Due to the user preference for provision of high resolution videos and images, as well as the enabling capabilities of serving RAT and its terminal equipment, the user is provided with the highest alternative of Application XYZ. Furthermore, the user watches the presentation subtitled in its preferred language that is Greek.

Figure 11. The SP profile for Application XYZ filtered for the user in context zone (Home, Laptop, WLAN)

In the meanwhile, the hypothetical user has to leave house to move to its work. Hence, he switches off the laptop and connects again to the Application XYZ via his UMTS mobile phone. Figure 12 depicts the corresponding terminal profile. We notice that the mobile cannot play back “mpeg” videos and “wav” audio files.

Figure 12. Terminal capabilities profile of an UMTS mobile phone

The context sensors of the framework announce to the UPM the change of the user’s ME and RAT. The UPM recognizes that the new context zone of the user is (Home, Mobile Phone, UMTS) and retrieves the corresponding user preferences profile. The new user preferences, terminal (UMTS) and RAT (UMTS) profiles are, also, announced to the service logic of Application XYZ. Figure 13 illustrates the user preferences profile for the context zone (Home, Mobile Phone, UMTS).

Figure 13. The user preferences profile for application XYZ for the context zone (Home, Mobile Phone, UMTS)

Figure 14. The SP profile for Application XYZ filtered for the user in context zone (Home, Mobile Phone, UMTS)

The service logic of Application XYZ filters again SP with the new profiling information and produces the new SP* profile. Figure 14 depicts the new filtered SP*. Due to the user preferences for provision of low resolution video and images and taking into account that UMTS enables multimedia provision, the provision of Application XYZ to the user is adapted accordingly. Moreover, the “mpeg” and “wav” video and audio streams are excluded from service provision.

As the user leaves his house to drive to his office, the Location server of our framework attempts to locate his new Home Zone. We assume now that the new location and speed of the user do not match any the defined Home Zones. Hence, the Location server concludes that the user is located outside Home Zones and properly informs the UPM. The UPM retrieves the new user preferences profile for the new context zone (Default Home Zone, Mobile Phone, UMTS). Figure 15 depicts the user preferences profile for this context zone.

The service logic of Application XYZ is announced the new preferences profile and it produces the new filtered presentation profile SP*. Figure 16 illustrates the produced SP*. The user preference not to receive video streams when outside Home Zones results in the cut of the associated video stream from the presentation element.

Figure 15. The user preferences profile for the context zones (Default, Mobile Phone, UMTS) and (Office, Mobile Phone, UMTS)

Figure 16. The SP profile of Application XYZ filtered for the user in context zones (Default, Mobile Phone, UMTS) and (Office, Mobile Phone, UMTS)

As the user reaches to his office, which corresponds to one of its defined Home Zones, the Location server informs properly the UPM. The UPM, in turn, attempts to retrieve the user preferences profile that corresponds to the new Context Zone (Office, Mobile Phone, UMTS). Figure 15 depicts this user preferences profile. The latter is identical to the user preferences profile of context zone (Default, Mobile Phone, UMTS) which has already been received by the service logic of Application XYZ during the last interaction. The UPM recognizes that the service logic of Application XYZ is aware of current user preferences profile and decides not to resubmit it. Hence, the filtered service presentation profile of Figure 16 remains valid in the new context zone and keeps dictating the execution of Application XYZ. This results in not submitting any video stream to the mobile phone of the user as soon as he is situated in his office.

This realistic scenario presents the dynamic nature of our middleware framework, which enables the monitoring of the context zones of its subscribers and, accordingly, the adaptation of the perceived service provision. Taking into account that all procedures above take place transparently to end users and applications, it is obvious that the proposed framework can simplify and accelerate the phases of design, development and deployment of context aware services. Furthermore, our framework enhances the context unaware applications, as the one of the scenario above, with contextual characteristics.

5. Related Work

Since 1999 that Salber, Dey and Abowd announced their work on “Context Toolkit”[29], several similar efforts have been published[30][31]. Common to these architectures is the deployment of a platform for providing the developers of context-aware applications with refined context information, retrieved via underlying sensor infrastructures,. The applications into consideration target local users that move within certain, restricted areas (e.g., within rooms, buildings or campuses, the most). Thus, mobile PLMN users, with large-scale mobility characteristics, fall out of their scope.

Additionally, bibliography is full of closed, “monolithic” context-aware frameworks for mobile users with almost identical building blocks, which differs only to the provided applications[16]-[22]. This is due to the fact that most frameworks are designed with specific applications in mind, making the accommodation of new applications a tough effort. In any case, the application developers have to design their applications exclusively for these platforms and their associated execution environments. Furthermore, user profiling in all these frameworks is context-unaware, which results in user preferences to be taken into account in application adaptation only once, upon initiating a session between user and application. Hence, as the user preferences might change due to the user moves from one context to another, the application provision to him remains the same.

Our approach could be fairly evaluated as a generic, open “context toolkit” for mobile PLMN users. We adopt from architectures above the attributes that contribute to our design (such as adaptation and personalization of applications, as well as context interpretation), but we attempt to enhance reusability and developer-friendliness. Hence, we attempt to collect under the same umbrella the common components of more context-aware frameworks (e.g. location and profiles manager, context interpreters) and enable access to their functionality via open APIs and standardized web services. To this end, we need to replace private sensor networks and infrastructures with the context information (location, network and user data, presence) that can be retrieved via OSA/PARLAY APIs and underlying PLMNs, wherever possible.

These APIs have been enriched with various valuable attributes that can greatly contribute to our design, such as event notification, policy management, messaging services, and location interpretation. In particular, the activities under PARLAY X services[11] and OSA ServiceBroker[12] are critical steps towards opening networks to third-party applications and making things simpler.

The middleware framework proposed here, mediates between OSA/PARLAY APIs and applications attempting to simplify development and deploying of context-aware applications. The context information retrieved by the APIs is interpreted and filtered so that it is returned to applications in a refined and friendly format or in the form of a context-aware user preferences profiles.

The UPM that is introduced here adopts the philosophy behind the specification of 3GPP GUP[3][4], with respect to the distribution, storage, access and management of user profiles. It is further enhanced, however, to manage, also, the context-aware user profiles introduced here and enable open profile access to third-party applications. We imagine UPM as a shared component between registered applications and network operators that filters and forwards profiling requests by applications to the appropriate profile repositories, dynamically notifying the requesting applications with updated profile information whenever the applicable user preferences change. Although it is not necessary, we ideally place UPM in the business domain of network operators or third-party Application/Service Providers (ASPs) for security and functional reasons (access to the underlying APIs and networking infrastructure)[14][15]. Thisplacement contradicts to most proposed profiling framework [17]-[22],[32]-[34] but, on the one hand, it minimizes redundancy (Figure 1), and on the other hand, it is in line with the current trend of autonomic networking that requires additional intelligence by networking infrastructure and network services[35].

Comparing the framework of location and context sensitive user profiles with the traditional, non-context sensitive, profiling architectures (e.g. the 3GPP GUP), someone can easily note that the former offers really challenging advantages to applications enabling their efficient self-adaptation to location and context, minimizing, in parallel, the additional intelligence required to this end. The price that is to be paid for these advantages is mainly in terms of additional delay, which is due to the additional interactions required between UPM and location and context sensors. However, these interactions take place only once upon initiating a session with an application. The UPM, thereafter, receives the required context information via the updates that the context sensors submit to it whenever a change occurs. Thus, in an execution scenario of a mobile application during the provision of which to a mobile subscriber the UPM is required to propagate multiple times to the requesting application the applicable user preferences, the value of UPM is precious. The latter conclusion shows that for applications with high mobile characteristics, where the location and the context of the subscribers change often, the UPM is the ideal solution for enabling self-adaptation to context. Similar, for applications targeting to static end-users, the contribution of the UPM solution is of minor importance.

As a whole, several similarities in general philosophy and design approach, have been noticed between our framework and the I-CENTRIC[32] and CARE[33] frameworks, as well as the works in[37] and[38]. Especially as it concerns context awareness of user profiles, platform reusability and design approach. However, our framework is mostly based on OSA/PARLAY APIs for retrieving the user context information, as well as it introduces the concept of Home Zones and Context Zones for differentiating user preferences and personalizing applications accordingly. Furthermore, the business model is different, since both frameworks above locate their profile manager in the business domain of ASPs.

6. Conclusions

Present paper focused on context awareness in service provisioning and proposed a framework that enables efficient management of contextual profiles. Furthermore, a flexible and innovative model for user profiling was introduced. Innovation is based on the enrichment of common user profiling architectures to include location and other contextual attributes, so that enhanced adaptability and personalization can be achieved. For each location and context instance an associated User Preferences instance is created and hence, service provisioning is adapted to the User Profile instance that better apply to the current location and context. The functionality of the proposed middleware framework was illustrated with a realistic scenario that concern service provision in the new communications era.

ACKNOWLEDGMENTS

Work presented in this paper has been partly performed in the context of author’s doctoral thesis. The author would like to acknowledge the contribution of his colleagues. The content of this paper expresses solely the opinion of the author.