AndroCon: An Android-Based Context-Aware Middleware Framework

Mobile devices have become major sources of context-aware data due to their ubiquity and sensing capabilities. However, deploying mobile devices as dynamic, unabridged context data provider either locally or remotely is challenging, due to their limited computing capabilities. Moreover, mobile sensors are limited to physical context data acquisition and there is a need to integrate physical data provided by these sensors with social context data provided by various mobile applications. Such data integration is necessary in order to have a robust data sources for various context-aware applications. In this paper, we present AndroCon, an Android-based, context-aware middleware framework that enables mobile devices to acquire, integrate, manage context data and to provision the data to applications both locally and remotely. AndroCon enables integration of both raw physical and social related context data. Instances of AndroCon have been achieved by interpreting and storing high-level context knowledge locally and utilizing web service technologies for data provisioning. We perform extensive experiments using AndroCon to collect, provision and manage both social and physical context data from di ﬀ erent sources. We have also analyzed AndroCon’s performances based on its power consumption and CPU utilization.


INTRODUCTION
Over the years, the computing and sensing capacity of mobile devices has been constantly improving to support smart environment and robust applications.They have embedded capabilities to sense and capture events in their physical environments, thus, making them a popular source of context information.Smart devices such as Android Smart phones now incorporate high-level mobile application interaction that provides enormous social related data.These innovations together with the proliferation of pervasive devices have encouraged the development of more and more mobile-based, context-aware systems.While the volume of context data provided through various mobile applications and sensors are on rapid increase, collecting these data from various platforms and integrating them for efficient context-awareness processing are challenging.Context acquisition, processing and efficient utilization of context resources have been the major bottlenecks in developing context-aware systems.However, mobile devices face even more complexity due to their resource limitation when compared to high performance servers.They require more power, bandwidth, memory and storage to function independently as context provider in a robust context-aware architecture [1].They rely on high-performance servers to function in such environment.Existing research approaches suggested offloading computational resources such as context data from mobile devices to cloud-based infrastructures [2].Although, such approach has been considered expensive, due to high-quality network connection required to facilitate data transfer to cloud resources, yet, mobile devices have not been considered as viable context provider even with the increasing improvement in their computational capabilities.Moreover, in order to have robust context database that captures all the required activities necessary to determine a particular context-aware process, there is a need to integrate context data across platforms.Most context-aware systems depend solely on context information made available by sensors or some applications, thereby limiting their capabilities.
In order to solve the discussed issues, we present in this paper AndroCon, an Android-based, context-aware middleware framework for acquiring, integrating, managing and provisioning both physical and social context data.The framework is designed to enables mobile devices serve as Web service provider independently.AndroCon solution is developed to support distributed context-aware applications locally and remotely, by provisioning composite data from both sensors and social platforms.The complexity of supporting context-aware applications makes middleware a crucial component of context-aware systems.Although, there are existing middleware solutions, they have limited features and cannot address the majority of pervasive computing application development issues due to diverse underlying challenges [4].In this work, we integrate AndroCon solution with a number of currently existing middleware frameworks to improve its functionalities.Specifically, AndroCon reuses AWARE [5] and SCIMS [6] context acquisition frameworks.While AWARE acquires raw physical data from mobile sensors, and expands it functionality by incorporating another existing context acquisition framework, SCIMS collects raw social data from multiple social media sources.AndroCon uses general context ontology network to represents contextual knowledge about user and environment.It also supports distributed context-aware applications by integrating data and services together and provides a cross platform interface to context dependent applications.AndroCon also reuses the mIO! context ontology network model [7] that enables context-related knowledge modelling and allows applications adaptation based on users context.The main contributions of our work are the following: 1. We present AndroCon, a mobile solution for acquiring, provisioning and integration of both social and physical context data.
2. We rely on Semantics properties of information to provide a mobile solution that encourages context data re-usability and enables efficient management of both social and physical context data.AndroCon framework also support context reasoning by restructuring entire ontology networks and reusing them.
3. AndroCon also proves the concept of deploying RDF triple store in mobile devices and making mobile devices web service providers.
The remainder of this paper is organized as follows: Section 2 describes the motivations and the challenges in our approach; Section 3 introduces AndroCon architecture and its features; Section 4 presents the implementation of AndroCon; Section 5 presents the evaluation of AdroCon; Section 6 discuss related work and Section 7 presents the conclusions and further improvement to the framework.

Motivation and Challenges
This section contains two key subsections that describe the motivation for this work and the associated challenges.

Motivation
The proliferation of mobile devices, the advancements in its enabling technologies and the extensive use of these technologies like Internet, sensors, Radio frequency ID tags, smart and wearable devices, embedded processors and many more, have broadened the limits of pervasive service development and deployment.As the popularity of Internet of things progresses and the scope of pervasive computing becomes wider, research activities related to context-aware computing correspondingly increases.The quality and quantity of research works on context-aware system design and development are increasing daily, prompting more questions to be asked and exploration of unresolved issues.Moreover, the successful adoption of context-aware applications in different domains, such as health-care, fitness and tourism, has added momentum to mobile-based context-aware system research areas.Ambient assisted living systems development are on the increase to support the aging and vulnerable population.By using context-aware systems to detect human behaviours and assist daily activities, people are reminded to stay in a healthier lifestyle, hence prevent potential heavy expense on medical conditions [8].In addition, in order to efficiently utilize the growing technological capabilities of smart devices and mobile computing resources in context-aware computing, there is a need to make efficient provision through different methods related to the design and operation of context-aware systems.This research work is motivated by the above-mentioned technological, social and market factors.AndroCon project gained momentum by embracing the challenges and critical issues in this area.As for AndroCon, supporting and facilitating the development of a broad range of mobile context-aware applications its main goal.In addition, although there are publications that present the concept of mobile web services, only a few applications really adopt this idea due to the perceived limitations of mobile devices.

Challenges
Although the implementation of systems like Andro-Con appears very feasible due to the increase in number of smart and wearable devices and the advancement of mobile technology, however, the implementation and realization of such systems is expected to encounter some specific challenges, which are addressed in this paper.
1.The acquisition and integration of heterogeneous context data from variety of sources into either centralized or distributed repository.
2. Developing a flexible approach of reusing mobile application context data in other platforms to provide support to web services and applications.
3. The provisioning of context data locally and remotely to applications running on different platforms, such as mobile devices, PCs and servers.

AndroCon Context-Aware Middleware Framework
This section presents the overview and fundamentals of the AndroCon framework.We introduce the aggregate components that enable Android mobile devices function as Web service provider, and elaborate on context integration components of our framework.
We also present the procedures of managing both social and physical context data with semantic web technology.Firstly, we present the abstract architecture of AndroCon System as a layered architecture shown in Figure 1 below and we provide a general overview of our approach afterwards.AndroCon system comprises of four main components as shown in figure 1: the context acquisition as the bottom layer, which incorporates series of adapters from SCIMS acquisition component and AWARE client [5,6].The upper layer is the context integration layer.The integration layer passes data to the context storage layer, which is responsible for storing and retrieving context data.And above the storage layer is the context provision layer, which provides context data to applications through RESTful API.

Context Acquisition
AndroCon framework acquires both physical and social context data.While it leverages the AWARE framework to collect sensor data, its exploits SCIMS acquisition component for social context data acquisition.In order to provide accurate and robust knowledge base for external applications, AndroCon seamlessly integrates context data from these two sources.

Physical Context Acquisition .
The AWARE client is a mobile application that runs on Android mobile device and collect raw data from sensors.It supports a long list of mobile sensors such as barometer, gyro, temperature, accelerometer, proximity, compass, gesture, heart rate etc.In order to allow other Android applications to have access to context data retrieved by AWARE plugins and sensors, it stores the data in a local relational database and encapsulates it with Android's ContentP roviderAP I.For distributed computing purpose, it upload data to remote server but does not support local data integration.AWARE also supports ContentObserver approach, which allows messages to be sent only when context changes, to save mobile device power.Hence, AndroCon adopts ContentObserver approach to ensure that only modified context will be acquired and stored.Applications can also obtain data through passive ways, by simply subscribing to system broadcast by implementing a BroadcastReceiver object and listening to the broadcast.The functionality of the AWARE's core component is sensor data acquisition.At present, AndroCon framework does not include context interpretation, instead, it leverages the plugins currently included in AWARE.However, interpreters will be implemented by creating AWARE plugins in subsequent version of AndroCon solution.
Social Context Acquisition .SCIMS acquisition component retrieves raw social context via Online Social Network (OSN) APIs and has a preferred context interpreter.It runs on PCs and servers.Sources of social context include Facebook, Twitter, LinkedIn, etc.Therefore, it can be implemented to retrieve high-level social context data.However, SCIMS is a server-based framework only, which implies that social context data can only be collected via cross-platform approaches, such as RESTful API.This indicates that more network operations need to be invoked.In current version of AndroCon solution, an adapter is implemented to call SCIMS's RESTful API in order to acquire context data.

Context Integration
In order to provide a robust and rich context data source for context-aware processes, AndroCon framework integrates both physical and social context data acquire via AWARE and SCIMS frameworks respectively.Therefore, series of adapters are implemented in AndroCon System to obtain these context data.In this context, the data sources are classified into local and remote sources.For local sources, the adapters retrieve data through Android ContentP rovider or BroadcastReceiver; for remote sources, the adapters will call their respective APIs, for example, Google Calender API is used to track and retrieve events information, which may include date, name of event, name of event location etc. as context data.SCIMS currently functions as remote context data source, and it supports retrieving data through RESTful API.Therefore, the adapter for SCIMS needs to implement the functionality of consuming SCIMS's service.On the other hand, AWARE client functions as a local resource, the adapters are expected to call Android APIs to retrieve data.The following subsection explained the semantic approach used to represent both type of context data.We used ontological approach to integrate and manage both data sources.

AndroC on OntologyDevelopment
Most context-aware scenarios require utilizing both physical and social context to generate more meaningful knowledge.The integration of these forms of data requires a more comprehensive and flexible data model to represent the context information and provide support for more complex knowledge interpretation.While there is no existing model for such data composition, AndroCon adopts ontology based approaches to represent context data.AndroCon's Ontology development follows the guidance of the N eOn methodology [10].AndroCon adopts one of the authorsâĂŹ scenarios of reusing, merging and re-engineering ontological resources, to merge the acquired social and physical context data together.We reuse mIO! Ontology network as part of AndroCon's physical ontology.The mIO! ontology network, which consist of user's  Figure 2 shows the restructured AndroCon's physical context ontology.As shown in the figure, the ontology is divided into two distinct layer of physical things.The upper level captures the basic concepts of physical abstracted from the real-world use case scenarios.This includes classes such as Activity, Location, EnvironmentalCondition and P hysicalentities.The second layer comprises of the subclasses, which are related to the classes in upper layer.This hierarchical definition gives room for flexibility, as each sub-classes can be further extended or related to another physical entity.For example, Sport as a domain and subclass of activity can be further extended to form a type tie with sub-entities such as volleyball, Boxing and other sports.
The mIO! Ontology is re-engineered by removing some redundant classes and properties originally included, while merging SCIMS's social ontology to the network.On the other hand, since AndroCon's social context ontology design is compatible with the structure of SCIMS social ontology, the ontology is merged with the AndroCon's general ontology structure without being revised.The SCIMS social ontology is described in Figure 3.The entire network is reviewed and restructured over again after merging to ensure total elimination of redundancy.For example, both The resulting integrated ontology shown in Figure 4 is defined and stored as an .owlfile, which is used as the schema of the database.We use the super class concept of thing to tie other class to a common entity and discard redundant classes or entities that are common to the two ontologies.Unlike other frameworks that uses relational databases to store context data, AndroCon adopts a RDF triple store to save context data.

Context Provisioning
One of the major distinguishing features of AndroCon context-aware framework that separates it from other related frameworks is its capability that enables mobile devices function as web service provider.Although there is no development framework such as JAX-RS [10] or WCF [11] to facilitate rapid web service development in mobile devices, AndroCon adopts the simple and easily consumed RESTful protocol to replace the memory and computational intensive SOAP protocol, which improves the efficiency of data provisioning mechanism.This approach built on authors [12] research suggestions in a more comprehensive way.The following subsections discuss the architecture of AndroCon's Web Service provisioning.
Service Architecture.The architectural design of the AndroCon System Web Service consist of two layers: The web server layer and the database layer.In order to facilitate HTTP responses and requests to and from the Client, a web server must be deployed in the mobile device.Whenever the HTTP request reaches the server from the client, the server initiates a new session and stores the parameters in a buffer.A dedicated method in the server class takes the responsibility of a business logic handler.The method analyses the parameters and invokes corresponding method to serve the request and generate appropriate response.The web server upon receiving the request will analyze the URL of the request and find a RESTful resource that the client intend to access.Once this is achieved, the server immediately maps the resource to one of the classes within the androconontology package.Figure 5 shows the functional layers of web service architecture.The business logic handler will execute the next action.It generates different types triple store transactions, based on the type of HTTP method invoked.For example, if the request is a HTTP POST method, the handler will collect a JSON string from the request body and de-serialized it, then invoke the insert method of the AndroConAddress object.The handler then passes the de-serialized JSON objects to the method as parameter.The database layer is implemented as a RDF triple store, which consists of a SPARQL engine and an underlying TDB instance.The AndroConAddress class object query and insert methods will transfer RESTful requests to SPARQL statement and forward the statement to SPARQL engine.The engine then interacts with TDB and return the query results.When the AndroConAddress object receives the SPARQL query results, it serializes the results into a JSON string and then pass the resulting string to the web server.The web server prepares the HTTP response message and returns it to the client.
RESTful API Design .The design of AndroCon's API follows the four basic design principles of RESTful services.These APIs are expected to invoke the four HT T P methods, namely; GET , P OST , P U T and DELET E explicitly and in a consistent approach.In the AndroCon framework, P OST is invoked to create resources, GET to retrieve a resource, P U T to update a resources, and DELET E to remove a resource.In AndroCon, a resource can be a list of context, an instance of context classes or a context triple.AndroCon's API requests are stateless.All the requests will contain all of the parameters, context, and data needed by the server to generate a response within the HTTP headers and body.Therefore, no request is dependent on other requests and server does not need to maintain the state session.The stateless design helps to simplify the business logic handler and improve performance of the entire service system.Furthermore, AndroCon uses static URIs, which follows hierarchical structure to represent resources.This reflects the relationships between resources.The client can request In addition, AndroCon exploits JSON friendliness to user environment to transfer data context data.Data presented in JSON format are readily accessible without overhead [13].
Mapping RESTful Requests to SPARQL Queries .As shown in Figure 1, the AndroCon's acquisition adapters and the web service interfaces interact with the triple store using SPARQL language.A mapping component on the server side is provided to support the client applications that call RESTful requests to retrieve data.This converts RESTful request to their respective SPARQL commands.
Table 1 shows the four types of RESTful methods supported with their respective SPARQL commands.Although the concept of mapping used in AndroCon is similar to the one stated in [14], AndroCon does not use script to map its ontology classes with their respective properties.Instead, AndroCon uses Java classes to represent all elements of the ontology, including classes.Properties and individual attributes.Each Java class contains methods to conduct the four types of operation stated in The next section discusses the detail implementation of AndroCon functional components with specific use case.

Implementation
AndroCon middleware is built to enable mobile devices provision web service and to allow integration of multiple context data sources.In this section, we discuss the implementation of AndroCon's acquisition adapters, the context ontology OWL files, the context triple store, and the web service.The implemented functionalities will be described and each of the component will be verified.An experimental case study that show case how the solution is verified and the result is also presented.

ApplicationScenario
In order to verify and demonstrate how AndroCon tracks mobile user's location and activities by generating new context data and incorporating the data into other applications through RESTful API, we give in this section a location-based application scenario for University building premises.For example, if a mobile user user 1 is located in the University building tagged AU T − W T at 3pm on October11th2016.AndroCon will detect the user's location and assign related attributes, if there is an existing instance AU T − W T building in the triple store.If otherwise, AndroCon will generate an instance of AU T − W T with five datatype properties: addressCountry, adderessCity, addressStreet, addressN umber, and addressP ostalCode.On the instance AU T − W T , AndroCon will insert two triples to the triple store to represent the location knowledge -the first is androcon : user1 androcon : hasLocation androcon : AU T − W T , the other is androcon : AU T − W T androcon : timestamp, and.A sample of SPARQL query statement for obtaining a track of the location user 1 has been is displayed below: If U ser 1 wants to track the location context with a browser, the user will have access to the server via the resource address such as https : //localhost : 8756/locationcontext. AndroConHttpd will parse this request to the SPARQL query statements described above and to the AndroConDB.AndroConDB will query the triple store and return the result to AndroConHttpd, which then parse the results to JSON string and return to the browser.

Context Data Processing and RESTful Service
AndroCon adopts a location-based use case during experimentation, where physical context data were collected, as input to the system.The experimentation was done with AdroCon client application running on user's mobile device.The application tracks mobile user's locations and physical activities by generating new context data as their events or location changes.For example, when the AdronCon user visited a location with an existing instance in the triple store, it automatically detect the user location and relate it to other attributes.If the location is not an existing instance, AndroCon will generate an instance of the location with related properties.
The following resources were used to examine and verify the functionalities of AndroCon relative to the scenario discussed in section A. Androjena [15] is an Android porting version of Apache Jena project, was deployed as a supporting library for triple store.It consists of common rdf query libraries, a SPARQL engine (ARQ), and a graph store for triples (such as TDB).Andro-Con implemented TDB in the testing of devices.
N anoHttpd [16] is common light-weighted web server frequently used by Android developers as an HTTP server was also deployed in AndroCon system.
3. Tools Used: Different tools were used during the implementation of AndroCon.One of the key tools is P rotege [17].P rotege is a prevalent ontology design and development tool among academia.It was used to create, modify, combine and restructure AndroCons context ontologies.RAML [19] was used for RESTful API design and modelling.AndroCon application was developed using Java and its verifiable on multiple devices.Figure 6.Shows the three major functional classes implemented in AndroCon.Business processes relating to RESTful service were implemented within the web server.The class AndroConDB shown in figure 6 maintains the TDB triple store and supports CRUD operations through eight methods.The business process method in web server parses RESTful request from the clients to SPARQL queries.AndroConDB receives the queries and return results to the web server.In case where multiple adapters are needed to insert data into AndroConDB and single client querying AndroConDB with moderate workload, AndroConDB could efficiently contain and handle the request.Moreover, the AndroConHttpd class extends N anoHttpd and is responsible for request parsing, response generating, and service invocation.It is also in charge of business process.We envisaged that as more plugins are added, a dedicated class would be included for business process in subsequent versions.Location and activity context are currently supported by AndroConHttpd, which corresponds to locationContext and activitycontext in RESTful resources respectively.For verification purpose, HTTP forms were used as the client to initiate RESTful POST request and the context data were posted in JSON format [30].Whenever the server receives the JSON string, it will parse it into the SPARQL INSERT statements and then pass the statements to AndroConDB.This database then queries the triple store and return the results to AndroConHttpd.AndroConHttpd will then parse the results to JSON string and return to the browser.

Evaluation
In this section, we describe our experimental set up, metrics for evaluation and the performance of AndroCon based on impact on mobile device battery life and time taken to execute specific context-aware tasks.We also report the experimental results.

AndroC on' s Impacton Mobile device battery life
We evaluated AndroCon's impact on mobile device battery life to validate user experience and the performance in terms of power consumption.In order to study AndroCon's power consumption in real-time, we employed a diagnostic tool called Qualcomm's Trepn Profiler (QT P ) described by authors [5] as an efficient tool to evaluate Android mobile applications power consumption and measure device battery life, processor load of each high performance sensor.QT P was used to measure power consumption of mobile  device that has AndroCon installed on it.We measured the power consumption for both idle and running period of the application and the results with exiting context-aware applications power consumption, specifically AWARE application.After several iterations with ten different sample readings taken at CPU frequencies 5Hz and 10Hz respectively using Nexus 6.0 Android phone, the results are shown in Table 3, which contains records for time taken to execute the entire AndroCon processes, Battery Consumption in percentage% ,Battery power in milliWatt per hour, and CPU load in percentage%.

Results and Analysis
The results derived from the experimental phase of our research were based on battery performance and CPU utilization of Android device running AndroCon application.As stated in the above subsection, we monitored and recorded the device battery usage, CPU loads and average power consumption when AndroCon is active and fully running.Table III and figure 7 shows the readings taken in real time and a graphical representation of the key resources involved in AndroCon contextaware processes execution.As expected, the power consumption of AndroCon increases from the acquisition stage of the context-aware processes to the provisioning.While some the stages consume a moderate amount of power, there is a huge surge in power consumption during acquisition stage, which precedes the start up stage.However, the ability of mobile device to withstand several iterations without losing up to 10% of its battery life justifies the sustainability of deploying mobile devices as Web services providers.In order to validate the ability of AndroCon to maintain certain level of power sustainability when running on mobile device, we compared our results with the AWARE performance results.Figure 8 shows the comparison between Andro-Con's energy consumption and AWARE framework.
Although AndroCon appears to consume more power compare to AWARE application, the increase is sustainable and justifiable with a worthwhile mobile-based Web service provisioning.Figure 9 shows AndroCon's CPU loads over 180minutes.The Normalized CPU load reports the usage of the application with respect to the    But during the whole testing period of 180 minutes, the CPU load is always below 6%.

Related Work and Discussion
In this section, we first discuss the related contextaware middleware frameworks in general, and then we analyze and compare four related and most comprehensive context-aware middleware frameworks with AndroCon, including the ones leveraged in the framework.
A number of context-aware middleware solutions have been proposed to address various challenges facing context-aware and pervasive computing.Since existing solutions have varied features, they only contributed partially, for context, data, or mobile service management related application development [25].There seems to be no single middleware solution that can address in entirety the challenges of context-aware computing due to diverse underlying complexities.An early approach is the Context Toolkit proposed by [26].Context toolkit is a context-aware middleware framework, with the definitions of key functionalities of context acquisition, context reasoning, context integration and context provisioning.It is a conceptual framework, which consist of three abstractionswidgets, aggregators, and interpreters.Widget collects context data and generates higher level of knowledge such as location and activity.The widget sends context data to aggregator through uniform interface.
The aggregator integrates the data on distributed platform, then provision context data to applications.The interpreter turns low-level context information such as raw sensor data into higher-level knowledge through rules and algorithms.CORTEX [27] is a framework designed for mobile devices.CORTEX framework proposes a context-aware middleware for mobile applications, leveraging the Sentient Object Model.CORTEX provides an abstractions layer for retrieving sensor data so that the applications do not need to directly interact with low-level sensor drivers.It provides a context reasoning mechanism based on a hierarchy of contexts.
In order to make CORTEX more suitable for mobile environment, context acquisition module was eventbased.This implies that only changes of the contextdata will be retrieved.CoCaMAAL [28], is another context-aware middleware for ambient assisted living.It is designed as a cloud-based model to address issues related to management of sensor data and derivation of contextual information as well as monitoring user's activities and service discovery.CoCaMAAL implemented a service-oriented architecture for unified context generation, which is achieved by aggregating raw sensor data and timely selection of appropriate service using context management system.Moreover, a larger number of context-aware middleware have their management systems running on PCs and servers including frameworks such as SOCAM [20], SCIMS, Aura [29] and Context Toolkit.SOCAM is a service oriented middleware project for building rapid prototypes of context-aware mobile services.Its core component, context interpreter acquire context data from distributed context providers and interprets the data into higherlevel context information, and provision for data to the applications.SOCAM uses ontology-based model and focuses on context reasoning.SCIMS is a social context information management system, which specializes in acquiring raw social data from multiple sources.SCIMS includes other functionalities such as an ontology-based model for classifying, inferring and storing social context information.SCIMS also includes a query interface for accessing and utilizing social context information.
In mobile computing, factors such as scalability support for distribution, interoperability, self-adaptivity, support for mobility, modularity, plug-ability, etc. are of particular interest [26].Next we compare SCIMS, Hydrogen, SOCAM, and the AWARE framework with AndroCon based on some of these criteria.This is done mainly to position AndroCon in the big picture of the context middleware frameworks, thus emphasis on the idea of AndroCon's contribution.
SCIMS is a context management system, which specializes in social context.It incorporate various functionalities such as the ability to acquire raw social data from multiple sources , an ontology based classification capability, inferring and storing social context information, especially social relationship and status.SCIMS also uses an ontology based policy model for authentication and authorization, in order to control access to the context data, it implements a query interface for accessing and utilizing social context information.SCIMS stores context data in RDF file and adopts derive SPARQL-DL query engine with description logic reasoners.It combines five different DL reasoners (Pellet, HermiT, TrOWL, Fact++ and RacePro) with the query engine.Unlike AndroCon, SCIMS is not mobile based and only runs on PCs and servers.
The Hydrogen context-framework [27] is implemented to run on mobile devices.Rather than designing a centralized context repository, it proposes a peer-topeer context sharing.It adopts a three-layer architecture, which are all located on the same mobile device.Hydrogen presents a context framework, which comprises of five types of context (time, location, device, user, and network), and it is designed to be extensible.It is implemented using the PersonalJava virtual machines Jeode and the J2ME J9 on iPAQs (3660 and 3870) with the PocketPC 2002 operating system.Unlike Andro-Con, it provisions context data via context-sharing technology and not through web services.This technology requires all the parties involved in context sharing to have a context server component.According to [27], context data is stored in a Java executable object tagged ContextServer.This indicates that there is no specific database used for storing context data.
SOCAM [12] is a service oriented context-aware middleware framework, which focuses on context reasoning and context modelling using ontological approach.SOCAM is an architecture for the rapid building and prototyping of context-aware mobile services.It uses a central server called context interpreter, which acquire context data through distributed context provider and provides logic reasoning services used to process context information.SOCAM has an Intel Celeron 600M CPU gateway, which runs on Linux 2.4.17AndroCon: An Android-Based Context-Aware Middleware Framework to support distributed context-ware systems.Table IV.compares AndroCon with other context-aware middleware.

Conclusion and Future Works
In this paper, we have presented AndroCon, a mobile-based context-aware middleware framework for acquiring, integrating, managing and provisioning both physical and social context.AndroCon differs from the previously noted approaches in that it is an android-based framework and leverages two key frameworks to acquire a more robust context data.It does not only uses sensor data but also reuses existing ontological networks and social context data.It also show case in its implementation how to provision data locally and remotely to applications running on different platforms, such as mobile devices, server or PCs. .The framework extended the AWARE framework by adding more efficient context acquisition module into it.AndroCon provides several advantages such as reusability, extensible, interoperability and standardization.It reuses the mIO!Context ontology network and incorporated social context ontology into it.AndroCon provides a richer context database by integrating physical context with a set of restructured social network ontology.In the implementation of AndroCon, we proved and demonstrated the concept of deploying RDF triple store in mobile devices and making mobile devices web service provider.Our next step work is to carry out case study and assess AndroCon's effectiveness in supporting the development and operation of context-aware mobile applications in the promising Internet of Things area.

Figure 9 .
Figure 9. AndroC on CPU Load (Normalized ) kernel.The context interpreter initiates this gateway to attached context data sources to the gateway.Context data sources such as vehicle sensors, computers and mobile devices are attached to this gateway via the Ethernet, WLAN, and Bluetooth and so on.The context aware mobile services are located on top of the architecture, thus, they make use of the different levels of context and adapt their behaviours according to the current context.AWARE is one of the frameworks exploited in AndroCon framework.It focuses on context acquisition, particularly through mobile sensors.Although, AWARE has is limitations, it takes mobile power consumption as an important evaluation metric.It only support context storage and provisioning through remote servers.Unlike Hydrogen and SOCAM, AWARE does not use ontology-based context modeling and only provides limited reasoning functionalities.AndroCon exploits AWARE and SCIMS framework to improve on the limitations of these context aware systems.All its architecture layers (context acquisition, context integration, context storage, context provisioning) resides on the same mobile device.It acquires both social and physical context data, and supports ontology-based context modeling both physical and social context data.AndroCon uses RDF triple store to manage context CRUD operations and uses SPARQL as the query language.A RESTful service, which provision context data to upper application is implemented 11 EAI Endorsed Transactions on Context-aware Systems and Applications 07 2017 -03 2018 | Volume 4 | Issue 13 | e1

Table 1
above.By that means, the RESTful