1. Introduction

At the first hand, context awareness is defined complementary to location awareness. Originally, it was described context as location, identities of nearby people and objects, and changes to those objects[1]. Other authors define context as location, identities of the people around the user, the time of day, season, temperature, etc. Sometimes definitions add identity and user’s emotional state. One operational-oriented definition has been presented in[2]: where you are, who you are with, and what resources are nearby. It is close to the vision, presented in this article: location and network environment around.

There are many different approaches for getting location info for mobile subscribes. In general, it could be pretty standard nowadays (GPS, cell-id, assisted GPS[3]), but everything is getting more complicated as soon as we need indoor positioning. Due to the signal attenuation caused by construction materials, the Global Positioning System (GPS) loses significant accuracy indoors. Instead of satellites, an indoor positioning system (IPS) relies on nearby anchors (nodes with a known position), which either actively locate tags or provide environmental context for devices to sense. The localized nature of an IPS has resulted in design fragmentation, with systems making use of various optical, radio, or even acoustic technologies[3].

Nowadays, a great number of technologies are being used for indoor localization, such as Wi-Fi, RFID etc. However, all of them require the utilization of their own API with their own protocols. This can be a big challenge for developing heterogeneous scenarios where different localization systems have to be used for a location service. Heterogeneous scenarios where different localization systems have to be used for a location service.

One of the most used approaches for indoor location is Wi-Fi based positioning. A standard Wi-Fi based positioning system, such as the one offered by Cisco[3], is completely software-based and utilizes existing Wi-Fi access points installed in a facility and radio cards already present in the user devices. Companies could deploy also Wi-Fi based radio tags that use industry standard components that adhere to the 802.11 standards. This approach allows for the use of commercial off-the-shelf hardware and drivers to produce standards-based radio tag, which can communicate bi-directionally over the 802.11 network.

Thus, a standard Wi-Fi based positioning system can realize any type of location-aware application that involves PDAs, laptops, bar code scanners, voice-over-IP phones and other 802.11 enabled devices. For embedded solutions, there is no need for the client to include a specialized tag, transmitter, or receiver.

Because of the entire use of standards-based hardware, such as 802.11b, 802.11g, and 802.11a, a standard Wi-Fi based solution rides the installed based and economies of scale of the networks and end user devices that are proliferating today. Without the need for additional hardware, a company can install the system much faster and significantly reduce initial and long-term support costs. A common infrastructure supports both the data network and the positioning system, something companies strive for. The positioning system works wherever there is Wi-Fi coverage.

In addition to cost savings in hardware, a standards Wi-Fi based positioning system significantly reduces the potential for RF interference. The total Wi-Fi positioning system shares the same network along with other network clients, so there is no additional installation of a separate wireless networks (as RFID requires) that may cause RF interference with the existing wireless network[4]. The cited article shows that commodity 802.11 equipment could be surprisingly vulnerable to certain patterns of weak or narrow-band interference. This enables to disrupt a link with an interfering signal whose power is 1000 times weaker than the victim's 802.11 signals, or to shut down multiple access points, multiple channel managed network at a location with a single radio interferer. Wi-Fi location positioning is based on a grid of Wi-Fi hotspots providing, in general, 20–30 meters location accuracy. For more accuracy, there needs to be more access points with more Wi-Fi signals until a point of diminishing returns, i.e., you don't need 100% of access points to get the same accuracy with 75% of access points. In addition, better location accuracy can be achieved by knowing the actual (latitude, longitude) of the Access Point[5]. There are many articles devoted to Wi-Fi positioning. For example, we can combine a reference point-based approach with a trilateration-based one etc. Several layers of refinement are offered based on the knowledge of the topology and devices deployed. The more data are known, the better adapted to its area the positioning system can be[6].

Lets us mention also one more interesting approach: collaborative location (CL). And the most interesting approach for our future development is Collaborative Location-sensing. Cooperative Location-sensing system (CLS) is an adaptive location-sensing system that enables devices to estimate their position in a self-organizing manner without the need for an extensive infrastructure or training.

Simply saying, hosts cooperate and share positioning information. CLS uses a grid representation that allows an easy incorporation of external information to improve the accuracy of the position estimation.[7]

The motivation for CL and CLS is very transparent. In many situations, due to environmental, cost, maintenance, and other obstacles, the deployment of a dense infrastructure for location sensing is not feasible. It is exactly what we wrote about infrastructure-less system. In CLS, hosts estimate their distance from their neighboring peers. This can take place with any distance estimation method available (e.g., using signal strength). They can refine their estimations iteratively as they incorporate new positioning information.

And at this point we are ready to make the last proposition before switching to the SpotEx model. Of course, the acronym LBS (Location Based Systems) contains the word “location”. But do we really need the location for the most of the services? As seems to us the final goal (at least for the majority of services) is to get data related to the location, rather than location itself. Location in the classical form (latitude, longitude) here is just an intermediate result, that we can use as key in some requests for obtaining data (what is the final goal actually). So, why do not request data directly if we can estimate location?

2. Spotex Model

What if we stop our traditional indoor positioning schema on the first stage: detection of Wi-Fi networks? This detection actually already provides some information about the location – just due to local nature of Wi-Fi network. And as the second step we add the ability to describe some rules (if-then operators, or productions) related to the Wi-Fi access points. Our rules will simply use the fact that the particularly Wi-Fi network is detected. And based on this conclusion we will open (read – make them visible) some user-defined messages to mobile terminals. Actually it is a typical example for the context aware computing. The visibility for user-defined text (content) depends on the network context.

The first time this service SpotEx (Spot Expert[8]) was described by Dmitry Namiot in article published in NGMAST-2011 proceedings[9].

Obviously, SpotEx model is based on the ideas of Wi-Fi proximity. Wi-Fi host spots work here as presence sensors. But we are not going to connect mobile users to the detected networks and our suggestion does not touch security issues. We need only SSID for networks and any other public information.

So, our service contains the following components:

- database (store) with productions (rules) associated with Wi-Fi networks

- rule editor. Web application (including mobile web) that lets users add (edit) rule-set, associated with some Wi-Fi network

- mobile applications, that can detect Wi-Fi networks, check the current conditions against the database and execute productions

How does it work? We can take any exiting Wi-Fi network (or networks especially created for this service – the most interesting case, see below) and add some rules (messages) to that network. Message here is just some text that should be delivered to the end-user’s mobile terminal as soon as the above-mentioned network is getting detected via our mobile application. The word “delivered” here is a synonym for “available for reading/downloading”[10]. The possible use cases, including commercial deployment are obvious. Some shop can deliver deals/discount/coupons right to mobile terminals as soon as the user is near some predefined point of sale. We can describe this feature as “automatic check-in” for example. Rather than directly (manually or via some API) set own presence at some place (e.g. similar to Foursquare, Facebook Places etc.) and get deals info, with SpotEx mobile subscriber can pickup deals automatically. Campus admin can deliver news and special announces as well as hyper local news in Smart City projects could be tight (linked) to the public available networks and delivered via that channel, etc.

Especially, we would like to point attention to the most interesting (by our opinion, of course) use case: Wi-Fi hot spot being opened right on the mobile phone (it is illustrated on Fig. 1). Most of the modern smart phones let you open Wi-Fi hot spots. We can associate our rules to such hot spot (hot spots) and so our messages (data snippets) become linked to the phones. Actually, we are getting dynamic LBS here: phone itself could be moved and so, the available data will be de-facto moved too.

Figure 1. Wi-Fi hot spot on Android

This use case is probably the most transparent demonstration of SpotEx model. We can open “base” network right on the mobile phone, attach (“stick”) rules for the content to that network and it is all do we need for creating a new information channel. There is no infrastructure except the smart phone and we do not need a grid of devices as per CLS models.

Note again, that this approach does not touch security and connectivity issues. You do not need to connect mobile subscribers to your hot spot. SpotEx is all about using hot spot attributes for triggers that can discover the content. The term Wi-Fi proximity is used sometimes in connection with Wi-Fi marketing and mean on practice just setting a special splash screen for hot spot that can show some advertising/branded messages for users during the connection to that hot-spot. Unlike this SpotEx threats Wi-Fi hot spots just as sensors.

How our productions data store (base of rules) looks like?

Each rule looks like a production (if-then operator). The conditional part includes the following objects:

Wi-Fi network SSID,

Signal strength (optionally),

Time of the day (optionally),

Client ID (see below).

History of visits

In other words (for proximity marketing) it is a set of operators like:IF network_SSID IS ‘FakeCafe’ AND time is 1pm – 2pm THEN { present the coupon for lunch }

Because our rules form the standard production rule based system, we can use old and well know algorithm like Rete[11] for the processing. A Rete-based expert system builds a network of nodes, where each node (except the root) corresponds to a pattern occurring in the left-hand-side (the condition part) of a rule. The path from the root node to a leaf node defines a complete rule left-hand-side. Each node has a memory of facts, which satisfy that pattern. This structure presents essentially a generalized tree. As new facts are asserted or modified, they propagate along the network, causing nodes to be annotated when that fact matches that pattern. When a fact or combination of facts causes all of the patterns for a given rule to be satisfied, a leaf node is reached, and the corresponding rule is triggered[12].

The current implementation for mobile client based on Android OS. This application uses WiFiManager from Android SDK - the primary API for managing all aspects of Wi-Fi connectivity. This API let us pickup the following information about nearby networks:

SSID - the network name.

BSSID - the address of the access point.

capabilities - describes the authentication, key management, and encryption schemes supported by the access point.

frequency - the frequency in MHz of the channel over which the client is communicating with the access point.

level - the detected signal level in dBm.

So, actually all the above-mentioned elements could be used in our productions. And now we can prepare rules like this:

IF network_SSID IS ‘mycafe’ AND level > -60db AND time is 1pm – 2pm AND network_SSID ‘myStore’ is not visible THEN {present the deals for dinner}

Block {present the deals for dinner} is some data (information) snippet presented in the rule. Each snippet has got a title (text) and some HTML content (it could be simply a link to external site for example). Snippets are presenting coupons/discounts info for malls, news data for campuses etc.

Technically, any data snippet could be presented as a link to some external web site/mobile portal or as a mobile web page created automatically by the rule editor included into SpotEx. Rule editor works in both desktop and mobile web. So, once again just having ordinary smart phone is enough for creating (opening) information channel for delivering hyper-local news data. Figure 2 presents rule editor:

In case of presenting our data as links to some existing mobile sites (portals) SpotEx works as some universal discovery tool. De facto it lets mobile subscribers to be aware about context-relevant web resources. And owners for the resources can describe own sites via rules rather then present individual QR-codes or NFC-tags for example.

In case of describing some content right in the SpotEx the system works in this part as content management system. SpotEx rule editor creates mobile web page for the each provided data snippet and hosts that page on the own server. It means by the way, that for presenting our data we can use any resources that could be presented on HTML pages. In particularly, any multimedia content is also supported.

Figure 2. Rule editor

SpotEx mobile application, being executed, creates dynamic HTML page from titles (according to rules that are relevant in the given context) and presents that mobile web page to the user. It works just as a classical rule based expert system: matches exiting rules against the exiting context and makes the conclusions. Existing content here is a description for “Wi-Fi environment”: list of hot spots with attributes. And conclusion here is a list of titles that can be presented as a dynamically created mobile web page. On that page each discovered title could be presented as a hyperlink that points to the appropriate data snipped. Any click on the interested title opens the snippet (shows or discovers data to mobile user).

It is illustrated on Fig. 3:

So, for the mobile users the whole process looks like browsing, where their browser becomes aware about hyper-local content. At the first hand, we can note that it is the “pull model”, versus the “push model” that proposed by Bluetooth marketing for example. And it could be more convenient (more safe) for the users – there are no automatically downloaded files/messages etc. But in the same time nothing prevents us from updating that dynamic web page automatically (e.g., by the timer) and simulating “pull model” in the user-safety mode. At the second hand, we can note that because it is browsing, the whole process is anonymous. Indeed, there is no sign-in in the SpotEx. Of course, any data snippet may lead to some business web site/portal, where that site may ask about login etc., but the SpotEx itself is anonymous. Unlike social networks like Foursquare you do not need to disclose your identity just for looking mall’s deals for example. But in the same time we still can collect some meaningful statistics in SpotEx. Because the model requires Wi-Fi to be switched on, we have automatically unique ID for the each client. It is MAC-address. And it is actually global UUID. So, where we have not login info for our clients, we still can distinguish them. It let us detect for example, the same person, who did that already twice during the last week, opens that the particular data snipped. And because mobile users in SpotEx model actually work with web pages, we can use pretty standard methods for web server log analysis for discovering user’s activities. A statistical analysis of the server log may be used to examine traffic patterns by time of day, day of week etc. So, we can detect frequent visitors, usage patterns etc. And even more – we can use that information in our rules. E.g. some mall may offer special things for frequent visitors etc. Data from real time analytics for our info snippets could be used in conditional parts of our rules.

Figure 3. SpotEx rules

3. Browsing Model

The next stage of development targets the simplicity of preparing data for SpotEx model. What if instead of the separate database with rules (as it is described above) we add the ability to provide a special markup for existing HTML files?

So, rather than writing separate if-then rules we can describe our rules right in HTML code. Technically, we can add for example HTML div blocks with attributes that describe our rules (their conditions). Now, using some JavaScript code we can loop over such div blocks and simply hide non-relevant from them. For doing that we need to make sure that our JavaScript code is aware about the current context. We can achieve that via a special light implementation of local web server. This web server, being hosted right on the mobile phone (on the Android in our case) responds actually only to one type of requests. It returns the current context (Wi-Fi networks) in JSON (JSONP) format.

Why do we need a web server? It lets us stay in the web domain only. There is a simple and clear instruction for web masters:

- add SpotEx script to your page

- describe your info snippets as div blocks:

any HTML code

Our “old” rules could be presented via collection of attributes.

In this case JavaScript code loaded from local server will be able to proceed all the div blocks related to SpotEx, and set visibility attributes depending on the context.

Such simple trick let us make any existing HTML page “Wi-Fi context aware”. Note that if our script is not available, the page will work as a “standard” HTML page. There is also a “side” effect for SpotEx application – WiFiChat service[13]. This mobile application uses the principles described in this article and offers communication tools (web chat and discussions groups) for mobile users nearby the same Wi-Fi access point. Think about it as “SpotEx with predefined content”. The typical use case – we have Wi-Fi network in the train and this application automatically provides the discussions forum for the passengers. Or, keeping in mind that the “base” Wi-Fi network for this service could be opened right on the phone, this application can present personal forum (classified for example) as well as web chat for phone owner. This Android application is actually a wrapper for web mashup, that combines HTML5 web chat engine and cloud based forums from Disqus.

4. The Future Development

Here we see several almost obvious steps. At the first hand it is open API. In the current implementation SpotEx front-end actually obtains data in JSON (JSONP) format from our server-side database.

As soon as API is going live, the next step is almost mandatory. It should the stuff that will simplify the development. The good candidates here are web intents[14]. Web Intents is a framework for client-side service discovery and inter-application communication. Services register their intention to be able to handle an action on the user's behalf. Applications request to start an action of a certain verb (for example share, edit, view, pick etc.) and the system will find the appropriate services for the user to use based on the user's preference. It is the basic.

Intents play the very important role in Android Architecture. Three of the four basic OS component types - activities, services, and broadcast receivers - are activated by an asynchronous message called as intent. Intents bind individual components to each other at runtime (you can think of them as the messengers that request an action from other components), whether the component belongs to your application or another. Created intent defines a message to activate either a specific component or a specific type of component - intent can be either explicit or implicit, respectively. For activities and services, intent defines the action to perform (for example, to "view" or "send" something) and may specify the URI of the data to act on (among other things that the component being started might need to know). For example, our intent might convey a request for an activity to show an image or to open a web page. In some cases, you can start an activity to receive a result, in which case, the activity also returns the result in an Intent (for example, we can issue an intent to let the user pick a list of nearby images and have it returned to us - the return intent includes data in some format)

Going to our context aware browsing it means that our mobile devices will be able to present local data without low-level programming. Web Intents puts the user in control of service integrations and makes the developers life simple.

Here is the modified example for web intents integration for the hypothetical web intents example:

1. Register some intent upon loading our HTML document

document.addEventListener("DOMContentLoaded", function() {

var regBtn = document.getElementById("register");

regBtn.addEventListener("click", function() {

window.navigator.register("http://webintents.org/spotex", undefined); }, false);

2. Start intent’s activity and pass it extra data (context info)

var startButton = document.getElementById("startActivity");

startButton.addEventListener("click", function() {

var intent = new Intent();

intent.action = "http://webintents.org/spotex";

intent.putExtra("WiFi_List", List_Of_Networks);

window.navigator.startActivity(intent);, false);

3. Get local info snippets (note – in JSON rather than XML) and display them in our application

window.navigator.onActivity = function(data) {

var output = document.getElementById("output");

output.textContent = JSON.stringify(data);};}, false);

Obviously, that it is much shorter than the long sequence of individual calls as per any Open API.

The key point here is on Activity call back that returns JSON formatted data. Additionally, web intents based approach is asynchronous by its nature, so, we don need to organize asynchronous calls by our own. Also it is planned to add Bluetooth measurements too. But by our vision we should avoid the typical Bluetooth usage cases and does not use push proxy as per classical Bluetooth marketing. We think that the end users do at least not welcome push approach and it is the source of problems with Bluetooth proximity. Vice versa, in SpotEx Bluetooth nodes will be used the same manner we are using Wi-Fi access points – as presence triggers. In other words, we will add ability to describe rules for Bluetooth nodes too. SpotEx approach could be extended also towards accumulating some ideas from the collaborative locations. We can add trilateration terms (conditions) to our rules, but present them in terms of fuzzy logic (close than, relatively close etc.) It could help incorporate grid data in case of many devices without any infrastructure preparation.

SpotEx approach could be used for discovering real behavior for indoor. It is possible to collect MAC-address info for users and create some like live heat-map: we know which hotspots accumulate most users, etc. It is the next interesting moment (similar to reality mining[15]), that will be covered in the upcoming releases.

5. Conclusions

This paper describes a new context-aware computing model for mobile users developed on the ideas of Wi-Fi proximity. Service can use existing as well as the especially created (described) Wi-Fi networks as presence triggers for discovering user-defined content right to mobile subscribers. This service has been implemented on practice for Android platform and available for downloading via Google Play (Android Market). Proposed approach is completely software based. And it is probably its biggest advantage. For using SpotEx you need nothing except the smart phone. So, there are no prior investments in the hardware. Also this approach supports ad-hoc solutions and does not require the upfront space preparations. This service could be used for delivering commercial information (deals, discounts, coupons – proximity marketing), hyper-local news data, personal news etc.