1 chapter 4. middleware for location-based services hans-arno jacobsen, university of toronto kim...

1

Chapter 4. Middleware for Location-Based Services Hans-Arno Jacobsen, University of Toronto

Kim Min Jeong

cara2847@dreamwiz.comhttp://mobide.korea.ac.kr

Mobile Data Engineering Lab.Dept. of Computer Science and Engineering, Korea University

2

Contents

Introduction Applications LBS Characteristics Requirements imposed on Middleware System architecture Middleware Models Conclusion

3

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

4

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

5

Applications Classification and characterization of LBS applications

6

LBS Characteristics

Conceptual characterization of LBSPull vs. Push based applications

In push based : infrastructure autonomously pushes information to mobile terminalsIn 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 information

Profile information can be available at request time or be already available to the LBS

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 information

1. Be provided voluntarily by the user : location information is part of the service request

2. Be made by the network infrastructure or by a third party

Accuracy of location information

The degree of accuracy of location information is various factors as kind of applications

Statefulness of interaction If the LBS maintains state multiple service request, the interaction is stateful (ex. tracking application) and if no such state is maintained, the interaction is a stateless

Kind of information sources

1.Static information source : refer to databases about geographic environments (building)

2.Dynamic information source : offer information about road, traffic, weather conditions

and the location of mobile terminals

7

LBS Characteristics

8

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

9

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…)

10

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

11

System Architecture

End-to-end system architecture

12

System Architecture

13

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

14

Middleware Models

Survey different middleware models The various models exhibit a wide spectrum of different cha

racteristics Publish/Subscribe Subject Spaces Tuple Spaces DBMS-Based Model

15

Middleware Models

Publish / Subscribe

Generate a message when it wants the external world to know that

a certain event has occurred

P1

P2

Pn

…

Producers (Publisher)

S1

S2

Sn

…

Consumers (Subscriber)

Subscribe the events they are interested in

Publish (e)

Subscribe (p)

Notify (e)

Notification Service

Manage subscriptions and forward event to interested subscribers

B1B2

B3

Bn

…Event broker

16

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

17

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

Example)Subscription specification : Book/*/Canada

Notifications of events : Book/Travel/Canada Book/History/Canada

Topic

Topic

By topic Hierarchy :

Event is published to the History topic,

All subscriptions subscribing to topics Book, History, Canada and England will be notified

18

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

Content-based subscription : (type=news)∧(Province=Ontario)∧(City=Toronto)

Example)Topic-based subscription : news/Ontario/Toronto

In content-based subscription, subscription will not notify the event with value (type=news)∧(Province=Ontario)

19

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

20

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 pu

blications and subscriptions The system is periodically receiving location information about its users

as coordinates (latitude, longitude, altitude) Main component : Publish / Subscribe Filtering engine

21

Middleware Models

Apply publish / subscribe for modeling LBS L-ToPSS

Publications Subscriptions

Expressed as a list of attribute-value pairs { (a1,val1), (a2,val2),…..(an,valn) }

Ex) for the book example : { (title, “middleware for LBS”), (author,”Jacobsen”) }

Represented as conjunctions of simple predicates (attribute-name relational-operator value)

Ex) for the book example : (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

22

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)

23

Middleware Models

Apply publish / subscribe for modeling LBS

How to system works for Stationary publisher-mobile subscriber Mobile publisher-stationary subscriber Mobile publisher-mobile subscriber

Figure4.3 Publish/subscribe system model to support location-based services

24

Middleware Models

Apply publish / subscribe for modeling LBS1. Stationary publisher-mobile subscriber

Publish/SubscribeFilter engine

publication subscription

If a subscription is matched by a publication …

LocationConstraint

Matching engine Location constraints

• Location Constraints :

MIN of the subscriber +

(latitude, longitude, altitude) coordinates of the publisher

LocationStaging

arealocation update

•User location information (user_MIN, current_latitude, current_longitude, current_latutude)

Notification

25

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

26

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

27

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

28

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 :

Set of dimension of subject space :

Set of values allowed in this space:

d = (name, type)

Ex) subject space ‘location’ : Dlocation = { (x, double), (y,double),(z, double) }

29

Middleware Models

Subject Spaces Model Relationship between Subject Spaces

Define as a relation on the set ⊏ ∑ of subject spacesGiven 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

30

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]}

31

Middleware Models

Subject Spaces Model Two types of regions

Object regions Interest regions

represent values a publisher provides O denotes a set of object regions o : a particular object region in O

represent the set of values within the subject spaces a

subscriber is interested in I denotes a set of interest regions I : particular interest region in I

32

Middleware Models

Subject Spaces Model Matching Relations between Regions

r1

r3

r2

The relations among regions : r3 mc r2, r2 me r3, r1 mo r3

33

Middleware Models

Subject Spaces Model Subscription and Publication

Subscription Publication

Is : set of interest regions

fs : expression that represents the sets of

object regions

Op : set of object regionsfp : expression that represents the sets of

interest regions

34

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

35

Middleware Models

Tuple Spaces Tuple space can coordinate many concurrent activities, including the statef

ul 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

36

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

37

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

38

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