PAPER CONTEXT-AWARE BROWSING FOR HYPER-LOCAL NEWS DATA (CABHLND) Context-Aware Browsing for Hyper-Local News Data (CABHLND) http://dx.doi.org/10.3991/ijim.v6i3.2053 Yousef Daradkeh1, Dmitry Namiot2, Manfred Schneps-Schneppe3 1 University of Jordan, Aqaba, Jordan 2 Lomonosov Moscow State University, Moscow, Russia 3 Ventspils University College, Ventspils, Latvia, Abstract—This paper describes a new model for delivering hyper-local data to mobile subscribers. Our model uses any exiting or especially created Wi-Fi hot spot as presence sensor that can open access for some user-generated con- tent. In our approach we can describe hyper local data as info snippets that are valid (relevant) for mobile subscribers being at this moment nearby some Wi-Fi access point. And an appropriate mobile service (customized browser) can discover that information to mobile users. Service builds on the fly dynamic web pages and lets mobile subscribers to browse hyper-local data only. As the possible use-cases we can mention for example delivering news and deals in malls, news feeds for office centers and campuses, Smart City projects, personal classifieds etc. Keywords—Wi-Fi, proximity, context-aware, indoor posi- tioning I. INTRODUCTION Per Wikipedia, context awareness is defined comple- mentary to location awareness. Whereas location may serve as a determinant for resident processes, context may be applied more flexibly with mobile computing with any moving entities, especially with bearers of smart commu- nicators. Context awareness originated as a term from ubiquitous computing or as so-called pervasive computing which sought to deal with linking changes in the environ- ment with computer systems, which are otherwise static. [4]. There are many different approaches for getting loca- tion info for mobile subscribes. In general it could be pretty standard nowadays (GPS, cell-id, assisted GPS [10]), but everything is getting more complicated as soon as we need indoor positioning. Due to the signal attenua- tion caused by construction materials, the Global Position- ing 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. One of the most used approaches to indoor location is Wi-Fi based positioning. A standard Wi-Fi based posi- tioning system, such as the one offered by Ekahau [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 compo- nents that adhere to the 802.11 standards. This approach allows for the use of commercial off-the-shelf hardware and drivers to produce a standards-based radio tag that 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 in- volves 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 spe- cialized 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 prolif- erating today. Without the need for additional hardware, a company can install the system much faster and signifi- cantly reduce initial and long-term support costs. A com- mon infrastructure supports both the data network and the positioning system, something companies strive for. The positioning system works wherever there is Wi-Fi cover- age. 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 [9]. The cited article shows show that commodity 802.11 equip- ment is 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 iJIM – Volume 6, Issue 3, July 2012 13 http://dx.doi.org/10.3991/ijim.v6i3.2053� PAPER CONTEXT-AWARE BROWSING FOR HYPER-LOCAL NEWS DATA (CABHLND) knowing the actual (latitude, longitude) of the Access Point. 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. [5] 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 infrastruc- ture 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 avail- able (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 proposi- tion 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 classi- cal form (latitude, longitude) here is just an intermediate result we can use as key for some requests for obtaining data (our final goal). So, why do not request data directly if we can estimate location? 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 the authors in article published in NGMAST- 2011 proceedings [1]. Obviously, our 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 net- work (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 de- tected via our mobile application. The word “delivered” here is a synonym for “available for read- ing/downloading”. The possible use cases, including commercial deploy- ment 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, Face- book Places etc.) and get deals info, with SpotEx mobile subscriber can pickup deals automatically. Campus admin can deliver news and special announces, 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 Wi-Fi hot spot being opened right on the mobile phone. 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.to the most interesting (by our opinion, of course) use case: Figure 1. Wi-Fi hot spot on Android 14 http://www.i-jim.org PAPER CONTEXT-AWARE BROWSING FOR HYPER-LOCAL NEWS DATA (CABHLND) This use case is probably the most transparent demon- stration 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 creat- ing 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. And note again that this approach does not touch secu- rity 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). In other words it is a set of operators like: IF network_SSID IS ‘mycafe’ 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 [2] for the processing. A Rete-based expert system builds a network of nodes, where each node (ex- cept 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 general- ized tree. As new facts are asserted or modified, they propagate along the network, causing nodes to be anno- tated 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 corre- sponding rule is triggered [7]. 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 follow- ing information about nearby networks: SSID - the network name. BSSID - the address of the access point. capabilities - describes the authentication, key man- agement, 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 (in- formation) 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 snipped could be resented 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. 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 exam- ple. 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. SpotEx mobile application, being executed, creates dy- namic 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 pre- sented 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). 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 dy- namic 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 anony- mous. Unlike social networks like Foursquare you do not need to disclose your identity just for looking mall’s deals for example. iJIM – Volume 6, Issue 3, July 2012 15 PAPER CONTEXT-AWARE BROWSING FOR HYPER-LOCAL NEWS DATA (CABHLND) But in the same time we still can collect some meaning- ful 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 activi- ties. 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. 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 de- scribe 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:
Your HTML code
Our “old” rules could be presented via collection of at- tributes. In this case JavaScript code loaded from local server will be able to proceed all the div blocks related to Spo- tEx, 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 avail- able, the page will work as a “standard” HTML page. There is also a “side” effect for SpotEx application – WiFiChat service [12]. This mobile application uses the principles described in this article and offers communica- tion 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 (classi- fied 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 II. 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 devel- opment. The good candidates here are web intents [11] Web Intents is a framework for client-side service discov- ery 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 Archi- tecture. 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 run- time (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 - an intent can be either explicit or implicit, respectively. For activities and services, an 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 integra- tions and makes the developers life simple. Here is the modified example for web intents integra- tion for the hypothetical web intents example: 16 http://www.i-jim.org PAPER CONTEXT-AWARE BROWSING FOR HYPER-LOCAL NEWS DATA (CABHLND) 1. Register some intent upon loading our HTML docu- ment 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 se- quence of individual calls as per any Open API. The key point here is onActivity callback 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 we are planning to add Bluetooth measurements too. But by our vision we should avoid the typical Blue- tooth 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 ac- cumulating 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 helps as incorporate grid data in case of many devices without any infrastructure prepara- tion. III. CONCLUSION 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 espe- cially created (described) Wi-Fi networks as presence triggers for discovering user-defined content right to mobile subscribers. 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), hyper-local news data, personal news etc. REFERENCES [1] About location-aware mobile messages Dmitry Namiot, Manfred Schneps-Schneppe NGMAST 2011 http://www.ngmast.com/ [2] About the Rete Algorithm: http://en.wikipedia.org/wiki/Rete_algorithm. [3] Comparison of Wireless Indoor Positioning Technologies http://www.productivet.com/docs-2/Wireless_Comparison.pdf [4] Context Awareness: http://en.wikipedia.org/wiki/Context_awareness [5] Charalampos Fretzagias , Maria Papadopouli, Cooperative Location-Sensing for Wireless Networks, Proceedings of the Sec- ond IEEE International Conference on Pervasive Computing and Communications (PerCom'04), p.121, March 14-17, 2004 [6] F. Lassabe, P. Canalda, P. Chatonnay and F. Spies “Indoor Wi-Fi positioning: techniques and systems” Annals of Telecommunica- tions Volume 64, Numbers 9-10, 651-664, DOI= 10.1007/s12243- 009-0122-1 [7] Charles L. Forgy, "RETE: A fast algorithm for the many pat- tern/many object pattern match problem", Artificial Intelligence 19(1):17-37, September 1982. http://dx.doi.org/10.1016/0004- 3702(82)90020-0 [8] SpotEx: http://spotex.linkstore.ru [9] Ramakrishna Gummadi, David Wetherall, Ben Greenstein, Srinivasan Seshan Understanding and mitigating the impact of RF interference on 802.11 networks. SIGCOMM '07 Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications ACM New York, NY, USA ©2007 ISBN: 978-1-59593-713-1 DOI=10.1145/1282380.1282424 [10] Rein Ahas, Siiri Silm, Olle Järv, Erki Saluveer & Margus Tiru Using Mobile Positioning Data to Model Locations Meaningful to Users of Mobile Phones; Journal of Urban Technology Volume 17, Issue 1, 2010 pp. 3-27. http://dx.doi.org/10.1080/106307 31003597306 [11] Web Intents: http://webintents.org/ [12] WiFi Chat service: http://wifichat.linkstore.ru AUTHORS Dr. Yousef Daradkeh is Lecture in the Department of Computer Information Systems at the faculty of Informa- tion Technology and Systems, the University of Jordan (JU), and has worked of the Intelligent Software Systems Laboratory in the University of Calgary (UC), Canada, in 2007-2009. He has worked as a Post-Doctoral Research Fellow in the Department of Electrical and Computer Engineering. Dr. Dmitry Namiot is Senior Researcher of open In- formation Systems laboratory at the faculty of Computa- tional Mathematics and Cybernetic, The Moscow State University (Lomonosov). Professor Dr. Manfred Schneps-Schneppe is Profes- sor at the Ventspils University College, Ventspils Interna- tional Radio Astronomy Centre, Latvia, Author of more than 200 articles. iJIM – Volume 6, Issue 3, July 2012 17 http://www.ngmast.com/� http://en.wikipedia.org/wiki/Rete_algorithm.� http://www.productivet.com/docs-2/Wireless_Comparison.pdf� http://en.wikipedia.org/wiki/Context_awareness� http://dx.doi.org/10.1016/0004-3702%2882%2990020-0� http://dx.doi.org/10.1016/0004-3702%2882%2990020-0� spotex: http://spotex.linkstore.ru� http://dx.doi.org/10.1080/106307�31003597306� http://dx.doi.org/10.1080/106307�31003597306� http://www.jadara.edu.jo/� http://www.iiasr.org/� http://www.iiasr.org/� http://www.ucalgary.ca/� CfPart_ICL2012.pdf