CC BY
16
Geo Messages
Dmitry Namiot, Moscow State University, Moscow, Russia
dnamiot@gmail.com
Abstract - This paper describes a new approach for sharing location info in LBS: geo messages. Geo messages let you share location info data on the peer to peer basic as signatures to the standard messages (email, SMS). Rather than let some service constantly monitor your location (Google Latitude) or share your location info with some social circle (Fa-cebook Places, Foursquare check-in etc.) Geo Messages approach lets you share location data on the peer to peer basic. You can share (send) your location info as a signature to the standard messaging (email, SMS). And what is one of the most important parts of this approach - shared location data (map) does not contain (does not reveal) your identity.
Introduction
It is obvious, that the question "where are you" is one of the most often asked during the communications. 600 billion text messages per year in the US ask "where are you?" - as per Location Business Summit 2010 data. A huge amount of mobile services is actually being built around this question so their main feature is user's location exchange. In the most cases it is implemented as the ability for the mobile user (mobile phone owner) write down own location info in the some special place (special mobile application). But it means of course, that user must be registered in this service (download some special application). And even more important - everyone who needs this information must use the same service too.
Our idea of the signed geo messages service (geo mail, geo sms) based on the adding user's location info to the standard messages like SMS or email. Just as a signature. So with this service for telling somebody 'where I am' it would be just enough to send him/her a message. And your partner does not need to use any additional service in order to get information about your location. He/she will simply read SMS or email.
There are several implementations for this idea (see [1]). This article shortly presents them from the beginning.
Originally signed geo messages project presented a service for the mobile Internet and Smart Cards Web Server (SCWS). This service lets mobile users automatically add a special signature to the outgoing messages (email, SMS). And that special signature presents geo information for the current position of mobile terminal. So this service is probably the easiest way for sharing location information. It does not require any downloading or registration from the
potential users and provides a smooth extension for the existing communication services.
Project description
The main idea behind this project is how to deliver location info via the standard messaging (SMS and Email). We are using the same approach all SMS delivery services are in. Typically, when the mobile users get some service via SMS it means he/she is getting actually some link within the text message. This link leads to the downloading service for pictures, ringtones etc. And this approach uses the simple fact that all native SMS clients nowadays are smart enough to discover links (just http://something_is_here text chunks) within the text and allow one click internet access (opening that link). So for our location related stuff we are using the same approach.
The location info will be presented as a link, leads to the appropriate map. So if the sender will be able to automatically add such a link to the message, the receiver will be able with one click open the map showing sender's location (or open some mobile web page with the map - see below about the landing page).
Now we are ready to describe all the steps in our project.
100. The location info could be requested right from the sim-card (smart card) as Cell ID info. This information exists always and Java-card applet can read it (local info).
101. Cell ID information could be translated into "human"-readable form of (latitude, longitude) pair. There are several public services over the Net that let us do that. In our project we will use http://opencellid.org service. This service is free and provides a public HTTP based API.
102. Google static map. The Google Static Maps API lets you embed a Google Maps image on your webpage without requiring JavaScript or any dynamic page loading. The Google Static Map service creates your map based on URL parameters sent through a standard HTTP request and returns the map as an image you can display on your web page. In our case Google Static Maps API let us build a map (actually - an image for map) based on the latitude - longitude pair obtained through the step 2.
103.URL shortening service. In order to make sure our geo-related URL's comply with SMS restrictions (simply - they are no more than 140 symbols) we can deploy URL shortening service and make our signature smaller. In our application we will use bit.ly shortening service. This service is also free and provides a public API.
104. In order to add our location aware URL to the message (to SMS or to email) we will deploy URI Scheme for GSM Short Message Service and The mailto URL scheme. So our final step included dynamical generation of the mobile web page with links for messaging:
sms:?body=our_geo_aware_URL
and
mailto :?body=our_geo_aware_URL
So as soon as the mobile user will hit one of the link the native (it is very important!) messaging client (e.g. the native SMS client) will be launched with the text (body) field pre-populated with the given URL. So it is enough just to select the target phone (address) from the address book, add some text (optionally, of course) and send the message.
So all in all this service presents a mobile mashup (mobile web mashup) that passes user through the series of screens where the last one offers for the user customized messages sending links (or one link if we keep SMS sending only for example). And all the process is
a) completely automated
b) does not require any authorization in external services
c) very portable and will work on any mobile phone
Main features
Signed geo message service offers a mobile web mashup lets users add a link with geo information to messages (SMS, email). So our signature is a text. And this text simply contains a dynamically generated link that leads either directly to the mobile map or to some landing page where mobile map is a part of it. And that mobile map (visible area) shows the current position of the sender. It is where the name of service is coming from - signed geo messages or geo signatures.
This service is actually a web application from the start to end. Service starts from SCWS code that requests local info from SIM card and ends with dynamically generated web page for sending messages.
Service converts Cell ID info obtained from the smart card to geo coordinates via the public service. Actually there is more than one public alternative for doing this job.
Upon getting the coordinates (latitude, longitude) for user's location se r-vice creates a map as a visual form for the location info. For map generation service uses a public API from Google. It is important that service actually uses Google Static Map, where the map is actually presented as an image. So this map could be visible on any mobile phone (mobile browser), there are no JavaScript requirements etc.
For sending messages service deploys native clients from the mobile platform. It is actually a big plus because there is no need for users to study new application and all the existing address books will be available.
Usage scenario
Now let us see how our "geo signature" looks like.
105.Mobile user fires the browser and runs (opens) application web page. Web application for geo signature will be located on the SCWS, so it means just open some URL from http://localhost. As any URL it could be bookmarked in the mobile browser, so it is no more than just select some bookmark from the list
106. Opened web application requests smart card applet and gets local info (cell id at the first hand). Web application returns to the user a screen with information about the sharing locations (confirmation screen). This screen also contains a hyperlink points to the external web service. If user agreed to share contacts he/she hits the hyperlink and goes to the external mobile web site
107. Hyperlink contains an URL with parameters provided by the local info applet. So external web service gets a request with location parameters (cell is, mcc etc.)
108.Upon receiving the request external service creates own URL to the landing page, shortens this URL via public URL shortening service (e.g. http://bit.ly with public API) and responds with the "messaging" screen. This messaging screen contains in the general case just two links: for sending email and for sending SMS. Each link actually contains an appropriate URI scheme: mailto for email, and sms for SMS. In the both cases shortened URL is a parameter.
109. As soon as our user hits one of the messaging links the native client (for SMS or email) will be opened. And the body field will be pre-populated (pre-filled) with our short URL.
110.Now mobile user selects target address (phone) from the address book, probably adds more text and sends the message - everything is done in the native SMS client for example.
111. As soon as a message is received at the target party, the short URL in the text could be opened and our landing page (on the external service) gets a request. Landing service parses the parameters, request the OpenCellID service and gets the (latitude, longitude) pair. Service requests a map via static Google Map API (it is actually just an image) and dynamically composes the response. This response contains a map (just an image from the technical point of view) and (probably, optionally) an additional info. This additional info could be a geo-targeted advertising for example.
Such a response is actually a response the target party will get back after
opening the "signature".
Here are some illustrations (step by step - from start to end):
Figure 1. An initial screen
Figure 2. Confirmation screen
And now we can see a final result - how the opened link looks like for the target party:
Figure 3. Shared location
What kind of variations could be implemented (proposed):
112. We can avoid the requests to the external service on the step 3. And immediately return (right from SCWS Servlet) the "messaging" screen with the landing page in the URI's parameters. In this case URL shortening step will be skipped and our signature will have a true (long) link right to the landing page. But as a plus we will be able to serve signatures when the connection to the Internet is not available. The sender does not need the connection to the external web service. Only target party needs the connection for opening landing page
113. As an extension the previous option some kind of the emergency service could be created. We can send local info (cellID, mcc etc.) as a text (as is), leaving the interpretation of this info to the target party. If our target party is some application (application that will accept/proceed incoming SMS for example) the data could be easily extracted from the text and converted to the geo-friendly form. There is no landing page at all.
114. As an another extension to the "no Internet case" we can try to implement some kind of pseudo-shortening service right in SWCS Servlet (e.g. base 36 encoding) and shorten the URL to the landing page right on the mobile. So the landing page will be used in the short form.
115. If the browser on the phone supports Javascript we can skip the confirmation screen. SCWS Servlet will return Javascript code that redirects user directly to the "messaging" screen on the external server.
116. The messaging screen may have just one link (for SMS or email communications). E.g. in Russia the mobile email is not popular actually, so the SMS option is quite enough.
117.Many blog platforms (e.g. Posterous, Blogger, Friendfeed, Wordpress etc.) could be actually updated right from email - you have just to send email to some service address for posting new data. So this service could be pre-configured for posting data to some blogging platforms.
The technical implementation
The first step in the above described chain is SCWS Servlet that requests local info. We mean here proactive command Provide Local Information, with Command qualifier '00' (as per GSM 11.14 standard). This command lets us obtain Location Information (MCC, MNC, LAC and Cell Identity). So it is up to our servlet requests this info and use its data for the output.
The next step: SCWS Servlet returns an information screen:
You are about to share your location
Click here
in HTML it is some like that:
<p>You are about to share your location. <a href=" http://geosign.linkstore.ru?cellid=.. ,&mcc&.. .">Click here</a>
Link here points to the external service passing Cell ID as parameters:
http://geosign.linkstore.ru?cellid=.&mcc&.
In other words this link lets us pass the data obtained from proactive command Provide Local Information to the external site.
JSP page on http://geosign.linkstore.ru requests parameters from the query string and obtains latitude and longitude for them via OpenCellID.org API: http://opencellid. org/api
Actually JSP uses the following custom JSP tags from Coldtags suite (it just simplify the process): http://www.servletsuite.com/servlets/cellidtag.htm
Taglib performs the request to Open CellID API and parses the response. Technically it is a synchronous HTTP request from JSP code
Now, as soon as we get latitude and longitude we can compose the link to the map using Google Static Maps API. It is some like that:
http://maps.google.com/staticmap?center=lat,lng&size=300x300&maptyp e=satellite&zoom=16&key=DEVELOPER_KEY
where lat is our latitude, lng is longitude, DEVELOPER_KEY is a free key (ID) provided by Google and other parameters describe map's type (here we are using satellite image to simulate bird's eye view)
As soon as our URL is composed we can shorten it via http://bit.ly service. This service also provides a public HTTP based API. It is again just a synchronous HTTP request so we are performing it in the same cycle. This API is described here: http://code.google.com/pZbitly-api/wiki/ApiDocumentation
So our long Google Static Map URL will be converted into some like this (just an example of the short URL):
http://bit.ly/11ba14
And now our JSP code is ready to respond with the messaging screen. JSP file simply composes some like this HTML (we do not publish here headers for the mobile web page, just a body):
<a href="mailto :?body=http ://bit.ly/11ba14">Email</a> <br/>
<a href="sms :?body=http ://bit.ly/11ba14">SMS</a>
So here is just two links (or one if we need SMS only for example). And each link contains an appropriate message URI with our packed map URL. As soon as some hyperlink is clicked an appropriate native client (e.g. SMS client) will be fired. And text (body) field in our message will be pre-filled with our short URL. So we can select target phone (email address) from the address book and send the message.
This schema works absolutely similar when we drop URL shortening. URI for messages will simply use the real URL.
In case of the landing page (see above) the schema includes one step more. As soon as Google Maps URL is composed our JSP page writes a personal location information page for this request. Mashup just creates an unique public accessible file on our server and URL for this file is exactly the same URL we will use in messaging. We can make that URL shorten with bit.ly service or use as is, but anyway it will be used in our messaging URI.
Smartphones
Here we can use HTML5 capabilities. We can implement our messaging signatures as HTML5 mobile web mashups around the build-in email and SMS clients. We do not need Cell ID data in this case, HTML5 browser let us directly pickup location data via plain JavaScript. The following screenshot illustrates this approach. It is GeoMail application (Android):
you can type text and subject, select a type for the signature and hit send. Mashup creates a signature (short link to the map actually) and passes all data to the standard email client on mobile platform. All you need after that - just pickup an address from your address book and actually send message.
For some applications this email address could be predefined within the mashup. And Geo SMS works similarly (select a phone instead of email).
Signature type lets you select a type map. It could be a static map (as for legacy phones) or a whole Google Maps based mashup. In case of Google Maps target party will see a map with two markers: one for the saved (shared) location and the second one for his/her own location:
Also there is an implementation of Places service. This implementation lets you pickup some place (geo name) - via Foursquare public API and YQL and after that share its name using the above mentioned approach.
References
[1] http://www.servletsuite.com/geomessage - Geo Messages applications and related services. Collection of links and articles
