Get documents about "chap4 Middleware for Locationbased Services
Shared by: k3pv2RLb
-
Stats
- views:
- 0
- posted:
- 11/8/2012
- language:
- English
- pages:
- 38
Document Sample
Chapter 4.
Middleware for Location-Based Services
Hans-Arno Jacobsen, University of Toronto
Kim Min Jeong
cara2847@dreamwiz.com
http://mobide.korea.ac.kr
Mobile Data Engineering Lab.
Dept. of Computer Science and Engineering, Korea University
1
Contents
Introduction
Applications
LBS Characteristics
Requirements imposed on Middleware
System architecture
Middleware Models
Conclusion
2
Introduction
Location based service (LBS)
Information service is a network-accessible system to collect, filter,
transmit, process, disseminate data
The additional integration of position location information as a part of the
data processed by the information service
Provide and deliver information to users in a highly selective manner, by
taking users’ past, present or future location
LBS Applications
Route-planning applications, pushed-based targeted advertisement, friend
finder system, location-based games
Have different characteristics and impose a wide spectrum of
requirements on the underlying middleware platform
3
Introduction
Focus on
Location application services
The middleware technology required for supporting these services
Objective
Identify LBS application categories
Requirements imposing on underlying middleware platforms
Survey several middleware models
4
Applications
Classification and characterization of LBS applications
5
LBS Characteristics
Conceptual characterization of LBS
Pull vs. Push based In push based : infrastructure autonomously pushes information to mobile terminals
applications In pull based : requests are initiated by the mobile terminal (user)
Direct vs. indirect profile Profile information 1. may be gathered directly from the user or 2. may be obtained indirectly by
observing user’s interaction patterns or by obtaining from third parties
Availability of profile Profile information can be available at request time or be already available to the LBS
information
Interaction scenarios Correlation between interacting entities (service requester and service provider).
1. Both of them are stationary 2. Either is a mobile/stationary 3. Both of them are mobile
Source of location 1. Be provided voluntarily by the user : location information is part of the service request
information 2. Be made by the network infrastructure or by a third party
Accuracy of location The degree of accuracy of location information is various factors as kind of applications
information
Statefulness of If the LBS maintains state multiple service request, the interaction is stateful (ex. tracking
interaction application) and if no such state is maintained, the interaction is a stateless
Kind of information 1.Static information source : refer to databases about geographic environments (building)
sources 2.Dynamic information source : offer information about road, traffic, weather conditions
and the location of mobile terminals 6
LBS Characteristics
7
Requirements imposed on middleware
Recently, there are millions of mobile wireless telecommunication
service subscribers who may take advantage of LBS
All of these users could easily become clients to widely available
location-based services
To fully support LBS, requirements emerge for location-based
service middleware technology
8
Requirements imposed on middleware
LBS middleware platforms must do the following
Manage the mobility to all LBS applications by supporting disconnected operations
Manage changes in the network topology that occurs in dynamic settings,
such as ad-hoc location-based services
Manage millions of information consumers and information providers
Propagate notifications for thousands of information consumer simultaneously
Manage high volatility of users’ interests
Support heterogeneous notification channels (e.g. email, Internet protocols, fax, SMS..)
Perform security functions, subscriber and publisher authentication
Support different content formats (e.g. XML, HTML, WML…)
9
System Architecture
Middleware system
The set of services that facilitates the development and deployment of
distributed applications in heterogeneous environments
The objectives are to abstract the details of the underlying OS, network
substrate and protocols, mask failures, and mask the distribution of
interacting subsystems
LBS Middleware
Facilitate the development and deployment of LBS applications in
heterogeneous network environments
To offer one single location-based application portal, LBS middleware
connects customers on mobile terminals and Internet, ASP
Integrates with the network infrastructure, location servers, billing systems,
subscriber portal services
10
System Architecture
End-to-end system architecture
11
System Architecture
12
System Architecture
LBS Middleware
Differ in the kind of services offered to the subscriber, network
operator, the application provider
Subscriber : fine grained control over their profiles and location, context are
considered
Network operator or third-party ASP : supported with real-time billing,
subscriber information access
So, LBS Middleware are distinguished by the features they offer
their users (mobile user, network operator, application provider)
Many different architectures exist in the marketplace, without one
dominant player
13
Middleware Models
Survey different middleware models
The various models exhibit a wide spectrum of different
characteristics
Publish/Subscribe
Subject Spaces
Tuple Spaces
DBMS-Based Model
14
Middleware Models
Publish / Subscribe
Consumers (Subscriber)
Producers (Publisher)
Notification Service
S1
P1
Subscribe (p)
Publish (e)
B1
B2
S2
P2
Notify (e)
B3 … …
…
Event broker Bn
Sn
Pn
Manage subscriptions and forward event
to interested subscribers
Generate a message Subscribe the events
when it wants the external world to know that they are interested in
a certain event has occurred
15
Middleware Models
Development of many publish/subscribe middleware systems
The expressiveness of the data model
How subscriber express their interest for a certain notification
Topic-based model
Content-based model
Type-based model
The architecture of the event broker
Centralized architecture
Distributed architecture
16
Middleware Models
Publish / Subscribe
Topic-based model
Use a tree-like structure to categorize events
• Publishers : publish events to one of the nodes of the topic tree
• Subscribers : subscribe to topics that they are interested in
Topic
Topic
Example)
Subscription specification : Book/*/Canada
Notifications of events : Book/Travel/Canada
Book/History/Canada
By topic Hierarchy :
Event is published to the History topic,
All subscriptions subscribing to topics Book, History, Canada and England will be notified
17
Middleware Models
Publish / Subscribe
Content-based model
The subscription scheme is based on the actual content of events
Subscription is expressed as a conjunction of predicates
Example)
Topic-based subscription : news/Ontario/Toronto
Content-based subscription : (type=news)∧(Province=Ontario)∧(City=Toronto)
In content-based subscription,
subscription will not notify the event with value (type=news)∧(Province=Ontario)
18
Middleware Models
Publish / Subscribe
Type-based model
Use features of object oriented programming languages (Java) to model event
types and subscriptions
Messages (publications and subscriptions) => Objects
Event topics : collections of message objects of the same type
Using object oriented programming paradigms, sub-topics can be formed by
inheriting another topic object class
19
Middleware Models
Apply publish / subscribe for modeling LBS
L-ToPSS
The location–aware Toronto Publish/Subscribe System
Be presented for the processing of location information in addition to
publications and subscriptions
The system is periodically receiving location information about its users
as coordinates (latitude, longitude, altitude)
Main component : Publish / Subscribe Filtering engine
20
Middleware Models
Apply publish / subscribe for modeling LBS
L-ToPSS
Publications Subscriptions
Expressed as a list of attribute-value pairs Represented as conjunctions of simple predicates
{ (a1,val1), (a2,val2),…..(an,valn) } (attribute-name relational-operator value)
Ex) for the book example : Ex) for the book example :
{ (title, “middleware for LBS”), (author,”Jacobsen”) } (edition >2000)
Predicate (a rel-op val) is matched by an attribute-value pair (a’, val’)
if and only if (a=a’) and the (a rel-op val) boolean relation is true
21
Middleware Models
Apply publish / subscribe for modeling LBS
If either the publisher or the subscriber is stationary,
The stationary entity is associated with fixed location
location information : (latitude, longitude, altitude)
The mobile entity : Mobile Identification Number (MIN)
22
Middleware Models
Apply publish / subscribe for modeling LBS
Figure4.3 Publish/subscribe system model
to support location-based services
How to system works for
Stationary publisher-mobile subscriber
Mobile publisher-stationary subscriber
Mobile publisher-mobile subscriber
23
Middleware Models
Apply publish / subscribe for modeling LBS
1. Stationary publisher-mobile subscriber
publication subscription
Location Location
Publish/Subscribe Constraint Staging
Filter engine Location constraints Matching engine area
location update
If a subscription is matched by a publication …
•User location information
(user_MIN, current_latitude,
• Location Constraints : current_longitude, current_latutude)
MIN of the subscriber +
Notification
(latitude, longitude, altitude) coordinates of the publisher
24
Middleware Models
Apply publish / subscribe for modeling LBS
2. Mobile publisher-stationary subscriber
- Static location is associated with the subscription
- MIN is contained in the publication
Process same way as in the previous case
Stationary subscriber will be notified when the publisher comes nearby
25
Middleware Models
Apply publish / subscribe for modeling LBS
3. Mobile publisher-mobile subscriber
- Each entity has associated a MIN : MIN_pub and MIN_sub
- Location constraint : (MIN_pub , MIN_sub)
- For each MIN, system stores the last location update and the timestamp
- Location matching :
When location update (MIN1, latitude, longitude, altitude) enters the system, corresponding
location information and timestamp are updated.
For(MIN1, MIN2), system checks if the last location received for MIN2 is close to MIN1and
also if the timestamps are close in time.
The appropriate subscriber is notified about the publication associated with the location constraint
26
Middleware Models
Subject Space Model
The traditional publish / subscribe model is inherently stateless
Subject space model is designed for state-persistent publish /
subscribe systems
State of subscription
Whether the subscription is true or false to a given publication
The relationships of all publications and subscriptions form the state
of a publish/subscribe systems
27
Middleware Models
Subject Space Model
Subject space
Information is structured by subject spaces
Multidimensional spaces and, data form regions in the subject spaces
Subject Space : d = (name, type)
Set of dimension of subject space :
Set of values allowed in this space:
Ex) subject space ‘location’ : Dlocation = { (x, double), (y,double),(z, double) }
28
Middleware Models
Subject Spaces Model
Relationship between Subject Spaces
Define ⊏ as a relation on the set ∑ of subject spaces
Given two subject spaces σ1 and σ2,
1. σ1 fully contains σ2, σ1 ⊏1 σ2
2. σ1 partially contains σ2, σ1 ⊏p σ2
3. σ1 and σ2 are unrelated σ1 ⊏0 σ2
Ex) user profile subject space : σuser_profile
Duser_profile = {(name,string),(age,integer),(profession,string)}
Service providers provide about a coffee shop
supject space : σ product, σcoffee, σcake
Dproduct={(SKU,string),(price,double),(discount,percentage)}
Dcoffee={(flavor,string)} U Dproduct
Dcake={(type,string),(name,string)} U Dproduct
The relationship among four subject spaces :
σcoffee ⊏1 σ product ; σcake ⊏1 σ product ;
σuser_profile ⊏0 σproduct ; σcake ⊏p σuser_profile
29
Middleware Models
Subject Spaces Model
Region
Data exist in subject spaces in the form of regions
Region :
The set of constraints of r :
the set of values of region r :
Ex) Let the position of a mobile user be k :
Ck = {x=[30,100], y=[50,130]}
30
Middleware Models
Subject Spaces Model
Two types of regions
Object regions Interest regions
represent values a publisher provides represent the set of values within the subject spaces a
O denotes a set of object regions subscriber is interested in
o : a particular object region in O I denotes a set of interest regions
I : particular interest region in I
31
Middleware Models
Subject Spaces Model
Matching Relations between Regions
r3
r1 r2
The relations among regions :
r3 mc r2, r2 me r3, r1 mo r3
32
Middleware Models
Subject Spaces Model
Subscription and Publication
Subscription Publication
Is : set of interest regions Op : set of object regions
fs : expression that represents the sets of fp : expression that represents the sets of
object regions interest regions
33
Middleware Models
Subject Spaces Model
Matching Relations between Publications and Subscriptions
In order for publication to match a subscription,
some object regions of the publication must satisfy the subscription filter,
the reverse case is the same
34
Middleware Models
Tuple Spaces
Tuple space can coordinate many concurrent activities, including the
stateful interaction among multiple activities
Originated in the parallel programming community
Widely implemented (e.g., JavaSpaces, Tspaces)
Tuples : typed data elements
Tuple spaces : collections of tuples
Dynamically inserted, read and removed from the space
35
Middleware Models
Tuple Spaces
In a location based application, information producer and information
consumer interact via a tuple space by inserting and extracting tuples
The Tuple space decouples the communication between producer and
consumer
36
Middleware Models
DBMS-Based Models
DBMS-based models as an underlying middleware model do not refer
to database technology to store and manage data but to database
technology for enabling the core information service provided
Location information and request are passed on to a database to retrieve
the relevant information
Enables the interaction between one mobile terminal and database
37
Conclusion
The characterization of LBS applications
Discussion of middleware models that supports various
characterizations
Several fundamental differences
Some applications require coordination and interaction of multiple users
Based on the model of one mobile entity interacting with a service provider
A middleware system for LBS supports many other functionalities,
such as management of subscriber information and billing records, and
enforcement of privacy
Middleware architecture supports the integration of these
functionalities
To date, no stand middleware for LBS exists, but standard
organizations are defining location positioning protocols
38
Related docs
Other docs by k3pv2RLb
Remarks by MEC Mokomele Mothibi at the 2010 2011 Annual Report Session at Mafikeng Hotel School on February 3 2012
Views: 1 | Downloads: 0
