Location Based Services
Mobile Computing - CNT 5517-5564
Dr. Sumi Helal
Professor
Computer & Information Science & Engineering Department
University of Florida, Gainesville, FL 32611
helal@cise.ufl.edu
Reading Materials
•
•
•
Paolo Bellavista, Axel Küpper and Sumi Helal “Location Based Services –
Back to the Future,” the Standards, Tools and Emerging Technologies
Department, IEEE Pervasive Computing Magazine, Sumi Helal, Editor,
Volume 7, Number 2, April-June 2008
Roxin, A., Dumez, C., Wack, M., and Gaber, J. 2008. Middleware models
for location-based services: a survey. In Proceedings of the 2nd
international Workshop on Agent-Oriented Software Engineering
Challenges For Ubiquitous and Pervasive Computing (Sorrento, Italy, July
06 - 06, 2008). AUPC '08. ACM, New York, NY, 35-40.
C. Lee, A. Helal and D. Nordstedt, "μJini Proxy Architecture for Impromptu
Mobile Service Access," Proceedings of the Workshop on Next Generation
Service Platforms for Future Mobile Systems (SPMS 2006). In conjunction
with the IEEE/IPSJ International Symposium on Applications and the
Internet (SAINT), Phoenix, Arizona, January 2006. (pdf)
2
Overview
•
•
•
•
•
•
•
•
•
What is LBS? What is impromptu LBS?
Examples
Why did LBS not take off for the past 10 years?
LBS Evolution
Today’s LBS classification
LBS Middleware
Mobile Service Discovery
Mobile Service Delivery
Ongoing research
3
Location Based Services
• A service whose rendering depends on the
location of the service requester, service
provider or both
• Mobile, networked Applications
– Input: geo references from Assisted GPS system
– Client/server interaction
– Output: Location relevant Information
• Example: weather, tourist information, ..
Elements of LBS
•
•
•
•
•
Querying
Advertisement
Discovery
Delivery
Localization Management
– No installs
– Lease / Release
• Location Privacy
5
Impromptu LBS
Impromptu LBS
Impromptu LBS
Why Difficult to Believe LBS
did not take off?
Great Phones/ Great B/W
2.5-3G Mobile Phones shown
GPRS, EDVO, UMTS, …
500-800 K speed
Who needs Hot Spots!
The WiMAX Possibility
• Wireless & Mobile Broadband at 10-30 miles range
• The Fat Pipe problem. Mobile TV: no thank you!
Commoditization Pressure
• The Skype Phenomena
• VoIP as a cheaper mobile phone
service
• Signs of commoditization of the
Telecom Industry?  pressure on
Telecom to explore new sources of
revenues (= New Services).
Early LBS (1)
 Content-Centric



Current LBSs are content-oriented and lack
the logic necessary for user interactivity (no
user models captured in the service)
Content could be boring! And has limited
impact as compared to interactions
Content-centricity was not by choice, it was
more of a constraint. Downloading content
was what is available, and was challenging
enough (e.g. WAP performance)
Early LBS (2)
 Precision of the Localization subsystem



Cellular triangulation useful for some
applications but inadequate for others.
On-board GPS (e.g., Assisted GPS) offers
better accuracy, but does not work indoor.
“Locate nearest Pizza place!” era of LBS


Does not need accuracy
Outdoor!
Early LBS (3)
 Telecom-centric


Localization data owned by Telco; location
based information provided by telco; telco
partners with other content providers (such
as Verizon and Microsoft MSN – never took
off, even with a massive publicity campaign).
The centricity and encumbrance by telecom
proved to be non-scalable and actually an
impedance to the much-anticipated
proliferation of the elegant LBS concept
The First Fix:
From Content to Applications
• Redefining LBS to be a framework not an application.
– As an application, LBS, gets a location, passes it to
an authoritative server (@telco), and then delivers
back location relevant information to the target. This
is one application – very limiting.
– As a framework, LBS gets a location, passes it to
servers owned or provided by third party participants
(small, medium and large businesses, from a variety
of industries), and then delivers back location relevant
services (applications) to the target. This is unlimited
number of applications. This is very flexible and
much more exciting!
Requirement to the First Fix:
Impromptu (flash) Delivery of
Applications.
• Middleware and intelligent markup languages should
be developed to enable the development of compact
size code that takes a few second to download and
a couple of seconds to get interpreted and run on a
mobile target equipped with the middleware engine.
• Code not content: compact code gets interpreted to
native computations utilizing native resources.
• Net effect:
– A few seconds instead of 10’s of seconds or minutes in
delivery time
– No installation, de-installation or management.
– Applications appear & disappear.
The Second Fix:
Enable Indoor Localization
•
•
•
•
More investment in indoor localization technology.
Standardizations
Solve Privacy issues
Bluetooth Example: Through the creation of a new
“Legalized Snooping” profile
– Snoop protocol
– Pay customer to snoop
– Access to customer profile
– On the fly tailored applications
• Technologies: Wi-Fi, Ultra wideband, or licensed
frequencies.
The Third Fix
Alter LBS Business Model
• Telco to sell and profit from basic services only (data
pipe, SMS pipe, ..and perhaps application pipe in
the future). Telco no longer define LBS.
• Empower third party to transact LBS directly with
end users, using (and paying for) Telco basic
services. This is B2C with B2B embedding.
• Any business should be allowed to participate and
offer LBS. A business should be able to develop
“LBSlets” using simple LBS development kits.
• Businesses can host their own LBSs either directly
or through a web hosting service.
• User to own and sell his/her LBS user profile.
LBS Evolution
LBS
features
and
supporting
services
1996
FCC passed
E-911
mandate
Key
technologies
& activities
Introduction of
finder LBSs
•Restaurants
•Filling stations
•ATMs
•…
First Child
tracking
services
Google
launches
GoogleMaps
First
locationbased
Mobile
gaming
2000
Deadline
phase 1
of E-911
Integration
of location
data into
Merging of
social
outdoor
network
and indoor
services
LBS
Locationapplication
based
s
dating
First
Application
commercial -oriented
Proactive
LBSs
LBSs
2004
Emergence
First
commercial of RFID
WLAN
fingerprintin
g systems
Introduction
of 3G
networks
First
handset
Supporting
Java
Location
API
2008
2012
Mass
market
penetration
of GPScapable
mobiles
Deadline
phase 2
of E-911
Launch of
New
Galileo
middleware
features for
Introspam
duction of
avoidance
Android
and privacy
handset
preservatio
n
First GPS
GPS works
capable
indoors
iPhone
Emergence of
common
middleware
for proactive,
crossreferencing,
and multitarget LBSs
LBS Evolution
community
orientation
crossreferencing
multi-target
self-referencing
single-target
operator-centric
positioning
content-oriented
reactive
proactive
proactivity degree
device-centric
positioning
application-oriented
user centrality
Mobile Service Discovery
• Impromptu service discovery and delivery
–
–
–
–
Widespread use of diverse mobile devices
Wireless hotspots and broadband coverage
Location-based and other context-relevant services
Most importantly: the Business Opportunity
• Challenges of impromptu mobile services
–
–
–
–
–
User mobility
Service portability across a wide range of mobile devices
Relevance and suitability: avoiding the morass of the Web
User Manageability
Acceptable quality of service
• An effective infrastructure is a key to realize this
vision
– Context-aware service discovery
– Device-independent service delivery
Service Discovery Protocols
• Service discovery is relatively new (late
1990s).
– IETF SLP, Sun Jini, UPnP, and Salutation
– Announce-listen model (Soft state model)
• Ad-hoc Service Discovery
– IBM DEAPSpace
– Konark Service Gossip Protocol [LHD+03][HDV+03]
• Wide-area Service Discovery
– Wide-area extension to SLP (WASRV)
– Berkeley Secure Service Discovery Service (SSDS)
Sever Selection Mechanisms
• Selection of the best among replicated
services
– Availability, fault-tolerance, load-balance, and
scalability
• Server-side approach
– HTTP redirect
• Network-side approach
– DNS round-robin, DNS LOC RR, DNS GL RR
– IP Anycast, Cisco DistributedRouter
– IETF RSerPool (Reliable Server Pooling)
• Client-side approach
– SmartClient
Three-tier Mobile SDP
(Choonhwa Lee et al)
• Provide the most appropriate service to mobile
users by exploiting any meaningful context
information
• Service classification by coverage
Service class
Coverage
Primary selection
criteria
Example
Proximity service
Local area
Proximity
Nearby printer
Domain service
Domain
Global service
Proximity and service Area guide service
features
Global area Service quality, user
Media service,
memory, or
storage service
availability
Conceptual Model of the
Three-tier Discovery Architecture
Services
Contexts
Service
Profile
Device
Description
Other Context
Information
GSR
Proximity
Services
Domain
Services
Global
Services
BA
•Different selection criteria
•Guided selection
•User transparency
•Scalability (Performance)
Profile Server
at home
Domain Discovery Sub-system
• On-campus registry hierarchy example
campus
…
CSE Bld
Printer
serivce
MSL Bld
…
4th floor
3rd floor
…
E 451
E467
Printer?
Global Service Discovery
…
Domain hierarchy
GSR
BA
GSR-capable
registry
BA-capable registry
…
Domain-3
GSR
Domain-2
BA
service
BA
BA
Domain-1
Client
Service Delivery Technologies
• Over the Air Downloads (OTA)
– UI tailored to work on target device downloading the service
• Universal Interactions
– Device-Independent UI Languages
• W3C XForms, INCITS/V2 URC, XIML, UIML, CMU PUC
– UI Remoting Approaches
• UPnP Remote UI, Jini Proxy Architecture
• UI Authoring Styles (W3C DI)
– Single Authoring
• A single generic description (all-in-one approach)
– Multiple Authoring
• A UI for each type of client devices (Jini ServiceUI project)
– Flexible Authoring
• Customized UIs for popular platforms and automatically generated
interfaces for rare platforms
Java for Mobile Services
• Java technologies for service portability and
dynamic service discovery
• J2ME
– Java runtime environments optimized for mobile
devices
– Configurations: CLDC and CDC
– Profiles: MIDP, FP, PP, and other optional packages
• Jini
– Dynamic service discovery framework on top of Java
RMI
– Jini Surrogate Architecture for resource-poor devices
• Jini requires J2ME CDC/RMI Profile as the minimal runtime
environment
Jini Proxy Architecture
VTC-Based Service Delivery
Jini
Protocol
Mobile
Clients
Jini Proxy
(VTC Service Delivery)
Service
Providers
Enhanced
Jini Protocol
Context-aware
Jini
Lookup Service
Standard Jini Protocol
Context-Aware Service Discovery
Jini Proxy Architecture
• Jini Proxy
– functions as a proxy to a Jini network w.r.t. service
discovery
– serves client devices as VTC servers for service
delivery
• Three delivery mode to bring discovered
services to resource-constrained mobile devices
– Client executable mode
– VTC MIDlet emulation mode
– VTC J2SE emulation mode
• Capable of selecting the best adaptation
depending on the service context
Thin-Client Approach to Service
Delivery
• VTC (Virtual Thin Client)-based adaptation
– Three delivery modes: Client executable, MIDlet
service emulation, J2SE service emulation
• Built on top of Sun Jini and AT&T VNC
• Smart-phone client (J2ME capable phone)
• Four main components
–
–
–
–
Jini Protocol
Resident Client
VTC
Jini Proxy
Jini System Architecture
Jini Lookup Services
Client Device
Jini Proxy
Application Space
ResidentClient
Jini
Protocol
VTC
Client
Jini Protocol
MIDP
JAM
CLDC
KVM
Dispatcher
Verifier
Adapter
VTC Server
MIDlet Emulator
VNC Channel
PNG Support
VNC
Jini Services
34
MIDlet Emulator
(4) Display update
KVM
event
(3) KVM
event
(3) KVM
event
X11
input
event
(2) Jini
protocol
Jini
Proxy
MIDlet
runner
(1) VNC server
pool
VNC desktop pool
VTC non-MIDlet Emulation Mode
ZOOM
Performance Measurement
Comparison of Local Execution Startup
and VTC Startup
300
Seconds
250
200
Local Execution
150
VTC
100
50
0
iCoffee
~35kB Jar
File
Shopping
~23kB Jar
File
PhoneClient
~24kB Jar
File
MIDlet Name & Size
MapIt ~34kB
Jar File