Context Processor Implementation

Following, the implementation of the system is discussed. During the work for this chapter, the cloud server used for experimentation was located within University College Cork; the server has a 1.7Ghz CPU, and 2GB RAM.

4.4.1 Contexts Utilised

The implementation aim is to use as few contexts as possible to reduce the amount of data to be sent between the mobile device and cloud. Ideally, the Context Processor will use the minimal current context data stored for the user, and historical context, to infer new context. For example, if the mobile device sends the latitude and longitude of the mobile device location, reverse geocod-ing can take place at CAMCS, rather than at the mobile device. If the user’s location is known, CAMCS can determine the appropriate timezone and time of the day. Such data can be used in its work, such as when deciding to intelli-gently work at a specific time without an explicit request from the user.

As the primary mobile development platform for the CAMCS Client is An-droid, the contexts are provided by Google Play Services, namely, location,

and user activity recognition. Using Google Play Services is a choice that con-siders the user experience goal of the research. Google Play Services can adapt to the current power levels/settings of the device to determine what means it uses to collect context, and how accurate it should be (for example, if the bat-tery level is high, it may use the power-hungry GPS to determine location; if the battery is low, it may use cellular tower or Wi-Fi coordination).

4.4.2 Ontology Implementation

The context representation as ontologies in CAMCS is based on the SPICE mo-bile ontology [142]. This ontology has been used in several projects and is already well developed to model and represent many contexts associated with mobile devices and users.

For this work, a customised ontology was developed, which imports and ex-tends the SPICE ontology, specifically its existing classes and properties. A NamedIndividual is used to represent each user. A NamedIndividual can be thought of an instantiation of a class. An axiom is used to define that these NamedIndividuals are subclasses of the User class in the SPICE ontology. The NamedIndividuals use properties from the SPICE ontology, such as hasLoca-tion, to describe the location of the user. In this ontology, a custom Place class was created, which subclasses Location from the SPICE ontology, to represent a user location. The benefit of taking this subclass approach is that customised properties can be added to the data and the ontology as required, while using the existing ontology entities and axioms. For example, the Place class contains place name, latitude, longitude, and timestamp properties.

The customised ontology used here, extended from the SPICE ontology, is not a complete ontology solution comprising a complete web of semantic data rep-resenting a mobile user and his/her context, nor is it intended to be. The se-mantic challenge here is to represent the relationship that a mobile user has a given context, as an ontology. For this work, all that is required is to define the relationship between the two entities (the user object and the location object), as linked data, through a property. This relationship has to be parseable by the inference engine used by the Context Processor, while the mobile user is dis-connected; this capability is provided by the use of OWL, and the OWL API for Java.

4.4.3 Collecting Context with the CAMCS Client

The CAMCS Client running on the mobile device, as previously described, is used to communicate with the CPA of the user. For the work relating to contex-tual awareness support, it is responsible for collecting the context information using Google Play Services, which must be installed on the mobile device from the Google Play Store. The CAMCS Client currently features two Android ser-vices (one each for location and activity), which communicate to Google Play Services to collect the context, and send it to the CPA.

Services start up on the mobile device at boot-time if the user allows, and they register their interest for the context update with Google Play Services.

Google Play Services calls back to the CAMCS Client with the context updates, which are then placed into the Context Wrapper. The CAMCS Client uses the Spring Android framework [40], to send a HTTP PUT request to CAMCS. If the CAMCS Client authenticates successfully with CAMCS using the login creden-tials sent with the HTTP request, the context data is passed to the user’s CPA, which will then be stored in the Context Processor.

The user can specify how often the context updates should be sent to the server.

These values are used with Google Play Services to determine how often the CAMCS Client should receive the context update events.

4.4.4 Context Profiles

The implementation is based on the use of context profiles. The profiles corre-spond to the daily activities or status of the user. Profiles are provided by de-fault for home, work, and for the evaluation with cloud services in Section 4.6, a tourist and vehicle profile. The home, work, and vehicle profiles can auto-matically activate based on the time, day of the week, and activity. Depending on which context profile is activated, the CPA will provide related function-ality and services. During weekdays, in the morning, it can switch into work and vehicle profiles, and fetch traffic information for the best route to work.

During the weekend, this mode will not activate. See Figure 4.3 which shows how profiles can be set using the CAMCS Client.

The user manually activates the tourist profile using the CAMCS Client, which informs the CPA to switch on this profile. Based on the different cloud services that can be used with the CPA, the developer of a profile can specify tasks and

behaviours that can run while active. Required work that should take place for an active context profile occurs whenever the CPA receives a relevant context update.

Using context profiles can bring advances to CAMCS, and the CPAs of users, in terms of operation. Depending on the active profile(s), the CPA can operate differently, or choose different courses of action in executing a user task. The active profile can determine the choice and selection of cloud services that the CPA chooses from. For example, if the work profile is active, the CPA may only select from enterprise private cloud services that it knows about, when looking for a service to complete a task. If the home profile is active on a weekend morning, when the work profile would normally be active, the CPA would choose not to remind the user of their daily work schedule, or provide the business user with the latest stock market information gathered. If the current context is stale, and new context cannot be gathered, the context history for that user will be used instead to determine the course of action for the CPA for an active context profile. Multiple profiles can be active at the same time. For example, while on a business trip, a mobile user can activate both the work and tourist profile. It should be noted that profiles exist in isolation from each other, defining their own distinct behaviour, with no knowledge of additional active profiles. Conflicting behaviour may occur, so the user should note what behaviour a profile will enable at his/her CPA.

In this implementation, the user cannot override the default behaviour of the context profile, as these are created by developers. Either the user should choose another profile (for example, one that will provide stock market in-formation every day of the week, rather than weekdays only), or create an automatic task for this purpose, described in Chapter 5.

4.4.5 Context Results

The result of a task that utilises context, like any task, is sent back to the mo-bile device when requested by the user. CAMCS and the CAMCS Client use Google Cloud Messaging (GCM) for this purpose.

When a task is complete, the CPA sends a message to GCM, which pushes a notification to the mobile device, to inform the user that the task is complete.

The CAMCS Client then fetches the result of that task from the CPA. The CPA stores the task result as a HTML web page. This page is generated by the

CPA when a task is complete. More details about task results are presented in Chapter 5.

When the user contacts the CPA with a HTTP(S) GET request for the result, the HTML result for the task is sent back, encoded in JSON. The HTML is then displayed to the user in an Android WebView. The implementation of HTML pages to show task results was not as developed at this point in the research compared with that which will be presented in Chapter 5, with few options for result customisation and refinement by the developers.

Consideration was given to implementing a custom Push service to send the result back to the user. Rather than the user having to receive the Push notifi-cation, and then request the result, a Push service could simply push the whole result back to the user, when the mobile device was available. This cannot be implemented with GCM, as it has a message payload limit of 4KB. The task result pages often contain a lot of data, going over this limit. Google does not recommend implementing such a custom Push service, and for each developer to use GCM, as opening many sockets for this purpose would have a detrimen-tal impact on battery life, contradicting the integrated user experience aim of this research. Despite the need for the user to explicitly request to fetch the result of a task from the CPA, Google’s recommendation was adhered to for the purposes of conserving battery life.