M-LATS: a trigger-based system for location-based services

(1)

2006:172 CIV

M A S T E R ' S T H E S I S

M-LATS

A trigger-based system for location-based services

André Dahlqvist Gustav Eriksson

Luleå University of Technology MSc Programmes in Engineering Computer Science and Engineering

Department of Computer Science and Electrical Engineering

(2)

Abstract

Mobilaris develops and markets software platforms, applications and GIS engines for mobile Internet services, supporting location-based technology. The service management platform Pacific Ocean is their primary product. Location-based services have seen relatively slow uptake, despite their potential. Mobilaris believes that one of the reasons for this is the need for frequent interactions with the service. For instance, current location-aware friend finding services require that the user query the service in order to determine where his or her friends are located. The preferred situation is that the service should inform the user when his or her friends are nearby. That is, the service should in this case trigger when the distance between the user and a friend is below a certain value. A trigger-based system would not only improve current services, but also make new services possible.

The purpose of this thesis was to create a system supporting trigger-aware location-based services. In order for this to be possible, the system would have to receive very large amounts of information from the mobile network, process it and thereby determine if a previously registered condition has been fulfilled. The large amounts of data that would be received made scalability an important factor to consider during the work.

It was decided that support for triggering on three different conditions would be implemented, namely area conditions, distance conditions and tracking conditions. Area conditions are triggered by a mobile user entering or leaving a certain area. Distance conditions are triggered when two mobile users are shorter than or further away than a specified distance from each other. A tracking condition is a periodic trigger that reports the position of a mobile subscriber at a certain interval. The current protocol used between the application service providers and Mobilaris’ middleware Pacific Ocean is the Mobile Location Protocol (MLP). MLP has minimal support for trigger-based LBS, so the protocol had to be extended to support the required functionality.

A lot of focus was placed on making the system scalable, fault-tolerant and extensible. Given the large amounts of data that the system have to be able to handle it was important to make it possible to run the system on several servers. The extensibility requirement meant, for

instance, that adding new conditions to trigger on should require few changes to the system.

This thesis resulted in a working trigger system which can handle a large amount of mobile users as well as a large amount of registered conditions. The tests showed that the condition database is what needs to be optimized to further increase the number of conditions that can be checked.

Preface

This thesis was performed at Mobilaris in Luleå, between September 2005 and January 2006.

The authors would like to thank our supervisor Peter Rosell for helping us, despite his hectic schedule. We would also like to thank our examiner Josef Hallberg. Finally we would like to thank our co-workers at Mobilaris.

(3)

1 Introduction

The mobile phone has in recent years had a great impact on our daily lives, allowing us to be reachable from just about anywhere. As mobile phones, and the mobile networks they use, have improved technically, possibilities for new mobile services have appeared. The mobile phone has evolved greatly from being a device used just for voice communication. Nowadays people expect to be able to take photographs with their phone, send and receive video and connect to the Internet with it.

An interesting group of services which have appeared in recent years are the so called location-based services (LBS). These services use the location of mobile users to provide them with relevant information, based on their geographical positions [1]. The first

applications for location-based services were rather simple, providing information such as the user’s current location, what businesses are nearby etc.

Newer services are more advanced and can for instance relate the current location of the user with other moving objects. With this system, users can locate their friends by asking questions such as “where are my friends?” using their mobile phones. Such a system does not support notifying the user when his or her friends are nearby, which would be a convenient feature for a friend-finding service. Supporting this feature requires a system which can react to events, that is, a trigger-based system. With such a solution it is also possible to push information to users who enter a certain area [1]. This opens up the door for many important services, such as services related to public safety. For instance, when an accident occurs it would be very valuable to be able to inform the people in danger by pushing this information to their mobile phones. Building such a system poses a number of challenges. Information about the location of mobile users is, by definition, constantly changing. The large number of mobile users and the mobility of them put high demands on the performance of the facility used to store the information about the mobile users. Being able to rapidly update and query the location of users is of great importance.

The growing number of mobile users also makes scalability a challenge. If used in areas with a large group of mobile subscribers the trigger system needs to allow the use of several servers, working in parallel, in order to balance the load. Some of the data cannot be lost in the system, so redundant storage is another requirement. For instance, information about what events to trigger on for specific users, henceforth referred to as conditions, cannot be lost.

1.1 Purpose

The purpose of this thesis is to design a system that makes the described trigger-based

services possible. The system should support load balancing as well as keeping important data redundantly stored. Privacy issues will not be handled by the trigger system, since that is done by the middleware Pacific Ocean.

1.2 Previous research

A lot of research has been done concerning different aspects of location-based services in recent years. Much attention has been devoted to finding an optimal way of organizing the location data. Several papers have been written concerning this subject, for example [7], [12]

and [13]. Other papers discuss the possibilities of LBS and how it might be used in the future, for instance [14]. More comprehensive research about LBS platforms has assumed that the mobile device is capable of self-positioning. They also argue that much of the computational

(6)

platform where no work or positioning has to be performed by the mobile devices. No solutions have been published that take into account the full scope of a trigger-based LBS platform. Issues such as load balancing, redundancy and possible optimizations are yet to be considered, which is done this master thesis.

1.3 Requirements on the trigger system

The work presented in this thesis set out to develop a trigger-based system for location-based services. Application service providers (ASPs) should be able to register position-specific events, called conditions, for a specified mobile subscriber. When one of these events occurs, the ASP should be notified about which event has occurred, and for which subscriber. Valid conditions are:

• Within area. Occurs when a certain mobile subscriber enters a specified area. The area could be a circle or a polygon.

• Outside area. Triggers when the subscriber leaves a specified area.

• Shorter than distance. This event occurs when two mobile subscribers come within a specified distance from each other.

• Further than distance. Same as within distance but occurs when the two mobile subscriber are further away from each other than the specified distance.

• Tracking. The tracking condition will be triggered each time the subscriber moves, or as often as the specified minimum interval allows.

When triggers are registered, one should be able to specify a number of properties related to their functionality. The properties that we will support are:

• Time limited. Using this property means that you can limit the time that the condition will be active.

• Once/many. If “once” is set to true, the condition will be removed once it has triggered one time. If “once” is set to false, the trigger system will send an event until the time limit is exceeded, or the registered condition is removed.

• Minimum interval. This meaning of this property is that triggered events will not be sent with a shorter time interval than this.

The system will receive data about positions of mobile users from the mobile network. This data will contain information about what cell the user is connected to and, when available, an estimation on how far from that cell’s center the Mobile Subscriber (MS) is located. More details about how the positioning works can be found in section 2.2 Mobile positioning. An approximation of the user's location using this data has to be calculated, and a database containing information about the cells in the mobile network will have to be constructed.

The system must be able to handle very high load since position data from millions of mobile users might be received. Therefore the system should support running several parallel servers simultaneously. If one server crashes, the others should take over the crashed server’s tasks.

The system should also be able to handle servers being added or removed when necessary.

Critical data such as registered triggers must never be lost, even if a server crashes, or in case of a power loss. The design of the system should also allow new conditions to be added without having to make extensive changes. Since this system will be used by Mobilaris, it should work together with their middleware Pacific Ocean.

(7)

1.4 Outline

• Section 2 contains background information that will help the reader understand the rest of the report. First Mobilaris and their primary product Pacific Ocean are described. Then an overview of different mobile positioning techniques is given, followed by an introduction to location-based services.

• Section 3 summarizes some of the areas that were studied during the feasibility study in order to get a deeper understanding of some of the problems that would have to be solved. This includes some documentation on indexing a large group of moving objects and documentation on different types of database systems.

• Section 4 describes the design of the trigger system. The system is presented one module at a time, briefly describing what each of the module does. UML diagrams are used to illustrate how the classes in the modules interact. The XML protocol that was developed for use between the ASP and the trigger system is also described.

• Section 5 describes implementation decisions that were taken during the development of the trigger system. Important classes are described.

• Section 6 describes the tests that were conducted during the thesis work. In one of the tests a benchmark of different facilities used to store position data is described.

Another test describes the tests that were performed on the finished trigger system.

• Section 7 contains conclusions that the authors have reached and also information about future developments and discussions.

• Section 8 defines abbreviations used in this report.

• Section 9 contains references to literature that were used to write this thesis.

2 Background

2.1 Mobilaris and Pacific Ocean

Mobilaris develops and markets software platforms, applications and GIS engines for mobile Internet services, supporting location-based technology. The company was founded in 1999 and today employs 27 people. Mobilaris has two offices, one in Stockholm, Sweden, and one in Luleå, Sweden. The development and customer support staff work in the Luleå office, while the administrative staff and sales staff work in Stockholm. Mobilaris has customers all over the world, such as in Europe, the Middle East, Asia, Australia, South America, Northern Africa, and the United States. Mobilaris has been successful in attracting new customers recently, and was named “Best IT Company” of 2005 in Sweden.

The primary product that Mobilaris offer is the service management platform Pacific Ocean.

Pacific Ocean is used to simplify integration and management of mobile services in a mobile operator's internal infrastructure. This is achieved by securely, and through one single point, publishing an operator's relevant non-speech network resources to third-party service

providers. This enables third-party developers to create services for end-users, without having to know the details of the mobile network. The network resources that can be published through Pacific Ocean are, among others, Short Message Service Center (SMSC), Multimedia

(8)

Message Service Center (MMSC), GIS data and location information.

Mobilaris has also developed a portfolio of end-user LBS applications that are ready to be deployed on top of Pacific Ocean. For instance, Mobilaris' Find Your Buddy application is used by a mobile user to locate his or her friends through mobile positioning. Other examples are simple services like those offering yellow pages information and the Where Am I

application that shows the user a map of the present location. Mobilaris can also host mobile services on behalf of mobile operators.

2.2 Mobile positioning

Mobile positioning is the act of determining the position of a mobile device. There are a number of techniques available to perform this positioning, each having their strengths and weaknesses. These techniques can be divided into two groups: those that primarily use the mobile network to perform the positioning, and those who require that the mobile device itself performs most of the work to position itself. The first group of techniques is often referred to as being network-based and the second one as being terminal-based. These techniques will be described in sections 2.2.2 to 2.2.6, after some background information on mobile networks has been covered.

2.2.1 Base stations and cells

Base stations are radio transmitters/receivers that mobile devices communicate with in order to get the expected service. Base stations have a limited range, and in order to get coverage of a larger area than one base station can provide, the larger area is divided into smaller areas, called cells. A cell is the geographic coverage area that a base station provides.

2.2.2 Cell ID and Timing Advance

A simple technique to get an approximate position of a mobile device is to use the fact that the mobile network knows which base station is currently servicing a certain mobile device.

Thus the position of the device can be determined to be somewhere within a cell. This is a rather rough estimate, especially in areas where the base stations are far apart. In order to enhance the positioning, something called Timing Advance (TA) can be used. TA can be described as the delay between the mobile device and the serving base station. Knowing this delay, one can get the mobile device’s approximate distance from the base station. This is the method that Mobilaris use, and it is also the positioning technique that our trigger system will be based on.

2.2.3 Time of arrival

This technique uses the time of arrival of data from the mobile device to at least three different base stations and compares these times in order to locate the device. The time difference of arrival defines a hyperbola on which the mobile device must be located. The intersection of two such lines reveals the location [3], [4].

2.2.4 Angle of arrival

In this method, the angles of the signals arriving to at least two base stations are calculated.

From this, two lines from the mobile device to the base station can be drawn, and their intersection will yield the location of the mobile device [2], [3].

(9)

2.2.5 Global Positioning System (GPS)

GPS is a satellite navigation system consisting of 24 satellites [5]. The distance from the mobile device to three satellites is calculated, and together with knowledge of where these satellites are located the mobile device can be positioned. In order for positioning with GPS to work, the mobile device needs to be equipped with a GPS receiver. Another disadvantage of using GSP for positioning is that it requires direct sight to at least three satellites in order to work, so it is not suitable for indoor usage [5].

2.2.6 Assisted GPS (A-GPS)

Assisted GPS is very similar to GPS, but using this technique the mobile device is assisted in performing the positioning. With A-GPS, the mobile network can assist both with informing the mobile device which satellites to communicate with, as well as helping with the location computations.

2.3 Location-based services

Location-based services (LBS) use the possibility to position mobile users to deliver location- dependent and context-sensitive data [7]. Early location-based services were based on a user- initiated, or pull-based, model. In this model, the user would request information specific to the user’s current location [6]. One example of such a service is mobile yellow pages. The user might for example request the location of the nearest gas station [6], or ask how the local weather will develop in the near future.

Another location-based service is friend finding, where a user wishes to be notified whenever one of a list of other users, called the users friends, appears in his or her vicinity [8]. For this application to work using the user-initiated model, the user would have to send periodical questions to the system asking whether or not some of the user’s friends are in his or her vicinity. The system would then have to somehow receive the locations of all the friends of the user, and then determine if some of the friends are in the user’s vicinity. Since the user is only told if any friends are in the vicinity right after a request, the user could have passed right by a friend, without getting a notification, between two requests.

The new approach to LBS is to have a more intelligent system, where the service can actively push location-dependent information to the user [6]. What information that should be pushed depends on the user’s predefined interests in the system [6]. This means that the user can receive information from the system that is relevant, based on his or her position, without having to request it each time. This push-based approach enables a variety of location-based services. Some of these were already available as pull-based LBS, but could be furthered developed with an intelligent push-based system. These are some possible services:

• Mobile gaming. Games where the player actually move in the real world to interact with the game.

• Friend finding (described above).

• Child tracking. Parents could receive a message saying, for example, that their child is at home or in school.

• Traffic information. For example, a person driving towards congestion will receive advice to take an alternative route.

• Location-based advertisement. For example shops could advertise products to

passersby who are in a certain age range. This would, however, require the possibility to filter out unwanted information.

(10)

• Fleet tracking. Fleet managers could pinpoint the location of all the vehicles in their fleet.

3 Theory

3.1 Tracking a large number of moving objects

The paper [17] argues that in order to support queries that locate the mobile users in a certain area one must keep an index on the positions of the mobile users. In the paper [12], a number of methods for performing spatial indexing are discussed. The authors describes that tracking a large group of moving objects put high demands on the performance of the system that indexes these objects based on their positions. Such an index is called a spatial index. A high number of updates and queries will result from tracking such a dynamic group. The paper suggests that for LBS it is wise not to store all location data on disk, since such storage mediums cannot handle the high number of updates that are required. The authors suggest storing the location data in main memory. Further they argue that loosing the data stored in memory is not a major concern for LBS applications, since data is continuously received from the objects being tracked. Their results indicate that the studied methods perform well in different areas. They conclude that the frequency of update versus queries is an important factor in the choice of indexing method.

3.2 Database management systems

Database management systems (DBMS) organize data and provide efficient access to data.

DBMS can be divided into two different groups; relational database systems and object database systems. In relational database systems, data is modeled as tables with rows and columns. Each row contains a set of attributes that are assigned distinct values. In an object database system, information is modeled as a set of objects. Each object contains a set of attributes that can either represent distinct values or references to other objects [11].

3.2.1 Main-memory database systems

Main-memory database systems keep its data in the main physical memory permanently instead of storing the data on disk as is normally done. The access time of memory is typically measured in nanoseconds, while the latency time of a disk is of the order of milliseconds. This means that there is a factor of a million in difference between the access time of memory and disk [11]. This does not mean that a database stored in main memory will run a million times faster than a database stored on disk. In practice, a main memory database will be 10-100 times faster than a disk-based system. [11]

3.2.2 Spatial database systems

There are a number of fields where geometric, geographic or spatial data, which means data related to space, needs to be managed. This can be either two-dimensional data, like some geographical space, or any three-dimensional data [10]. Spatial database systems use spatial indexing which makes retrieving data according to their spatial location fast [9]. A spatial index organizes data in such a way that only parts of the objects needs to be considered when making a query about which objects are within a specified location.

4 Design

The design of this system can be divided into the following five modules:

(11)

• Communication between trigger servers.

• Checking if conditions are fulfilled when a MS has moved.

• Keeping track of the location and covered area of all base stations.

• Condition management, removing and adding conditions.

When the design was finished, the relationship between the modules could be described with figure 1 below. The black box represents code that is related to Pacific Ocean. Although this code is used by the trigger system, it is not covered in this report. In addition to the classes which are covered in this chapter, the system also contains numerous helper classes and interfaces. More details about some of the classes in the design can be found in the implementation chapter.

Figure 1 - An overview of the modules of the system.

4.1 Data collection module

The data collection module is responsible for collection and storing the position data. It also contains the TriggerServer class which initiates and starts the system. When the position for a MS involved in at least on condition is changed, PO is called, which in turn calls the condition checking module.

(12)

Figure 2 - The data collection module.

4.1.1 Data from the mobile network

Mobilaris had decided that the task of capturing the data from the mobile network itself would be performed by another company. Special hardware will have to be installed in the mobile network to perform the capturing, and this data will then be sent to our trigger system. A proposal for what kind of data that should be captured and the format of this data, was made.

Each message that is sent to the trigger system is related to some sort of event that has

occurred in the mobile network. It is unclear exactly what kind of events that can be captured, but some possible events are the following:

• A mobile user has turned on or off his or her mobile device.

• A handover has occurred, which means that the user’s mobile device is now connected to a new cell.

• A mobile device has sent an “I’m alive” message. Mobile devices do this periodically, so even if the mobile user has his or her phone lying on the office desk all, the trigger system will receive data from it.

• A user has sent a text message.

The information in the event is initially to be used to position the MS, so events that can be used for this purpose are of primary interest. Each message from the data capturer to the trigger system should contain the following information about the event that has occurred:

• The MSISDN which identifies the subscriber that this message concerns.

• Information to be used in order to position the MS. Suitable data would be the ID of the cell that the MS is connected to, as well as the TA value when that is available.

(13)

This information is to be used in combination with knowledge of the location of the cells in the mobile network.

• An identifier that specifies the kind of event that generated the message. For instance, if the message is the result of a periodic ping from the mobile device, this should be indicated with this identifier. If the message is the result of the MS turning on or off the mobile device this identifier should be set accordingly. Another event of interest is if a MS switches from one cell to another. Identifiers should exist for all the events that can be captured from the mobile network.

• Possibly include the time that the event occurred. If it can be guaranteed that there will not be any noticeable delay between the time the event occurred and the time the message is received by the trigger server, then the time can be checked upon arrival of the message. This would help reduce the size of the message that has to be sent.

The data should be a byte array sent using the UDP/IP protocol. The UDP/IP protocol is preferable over TCP/IP because of its low overhead. Loosing messages is not a major concern, because new events will continuously be generated by the mobile device. Our proposed data format is as follows:

Byte number(s)

Contents Additional information

1 The type of event that has occurred.

2-9 The MSISDN. Sent as a number. Stored in a long.

10 TA value, if available. Send -1 if TA value is not available.

11-12 The identification number of the cell (Cell ID) the user is connected to.

The load balancing and redundancy must be taken into account. To eliminate the need of an extra load balancing system, the machines that send the data shall be able to perform load balancing. Load balancing based on the MSISDN will probably be a requirement. This means that if the trigger system is running on two servers, each server should receive events

concerning approximately half of all the MSISDNs.

4.1.2 Handling server crashes

In order to avoid having to use some expensive load balancing system it was decided that the company responsible for collecting and sending the mobile data to the trigger system should spread the data among the trigger servers. A certain part of all the MSISDNs should always be received by a specific server. This takes care of balancing the load between the trigger

servers, but it also means that if one server crashes all the data addressed to that server will be lost. In order to prevent this, our supervisor suggested the following setup: All the servers could be connected using a hub, which would send the received data to all servers. The servers would normally throw away data that was addressed to some other server. If one of the servers crashed, one or several of the other servers would have to assume responsibility for the data that should normally be handled by this server. The crash can easily be detected by our group communication facility, and information about the crashed server could be sent out to a predefined backup server, or to all other servers. When a server is informed that another server has crashed, it has to add that server’s IP address to its network interface.

(14)

Adding more than one IP address to a network interface can be accomplished by using IP aliasing.

As previously mentioned, information about a specific MSISDN should only be stored on one server. When a server crashes it will collect data concerning MSISDNs that should normally be handled by another server. To prevent data about a certain MSISDN being available on both servers after the crashed server is brought back up we decided that the server covering for a crashed server should log the MSISDNs that it does not normally receive information about. When the crashed server is later brought up it can request the data that was collected by the other server.

4.2 Server communication module

When a trigger server needs to communicate with the other trigger servers, the server communication module is used.

Figure 3 - Classes and interfaces in the server communication module.

4.2.1 Server communication requirements

When designing the trigger system it quickly became clear that some sort of facility to exchange data between different trigger servers would be required. While the trigger servers

(15)

can work independently most of the time, there are a number of situations in which they need to communicate with each other:

a) Given that the information about the mobile users can be spread among several servers, a server will at times need to ask the other servers in order to retrieve a person's position. For instance, this will be necessary if a server needs to evaluate if person A is closer to, or further away from, a person B than a certain distance, but this server does not know the location of person B. In this case it will need to query the other servers for this information. In addition to not having the person's position, the server does not know which server has this information, so it will need to broadcast the question to all servers. Since the server querying for the position cannot proceed until it receives a position response, the communication is synchronous.

b) If one server becomes unavailable, for instance because it crashes, the other servers needs to be made aware of this so that one of them can assume responsibility for receiving the data that the crashed server would normally receive.

c) An important optimization is that the system will stop processing a received position immediately if the position concerns a mobile user that is not involved in any conditions. In order to accomplish this up-to-date information about the number of conditions a person is involved with needs to be stored within the position database.

When a server registers or removes a condition, the other servers needs to be notified of this so that the condition involvement number is updated for the persons that these servers keep track of. This communication is asynchronous, since the notifying server just needs to broadcast this information and can then proceed with other tasks.

In some cases the server communication needs to be reliable, meaning that messages cannot be lost. Consider loosing a message notifying that a user has been added to a condition. Given the optimization (not checking the condition database if a user is not involved in any

conditions) it is possible that a server incorrectly believes that a user is not involved in any conditions. This will lead to the server not checking if the condition is fulfilled, and therefore possibly not triggering a fulfilled condition.

Cases a) and c) in the above list were the primary reasons to investigate group communication functionality. Initially it was thought that case b had to be handled separately by using some sort of software sending out periodic “I’m alive” messages, typically referred to as heartbeats.

In summary, the following communication needs to take place between the servers in the system:

• The system need need synchronous and asynchronous message-passing between the servers.

• A server must be able to send a message to all other servers.

• The delivery of messages needs to be reliable; i.e., the messages cannot get lost.

• The servers in the system need some way to determine if one of them has crashed.

At first, the reliability requirement that the case c) above ads was not considered. At this point, IP Multicast was considered. After realizing that reliability was a requirement, IP Multicast was no longer a candidate, since it is based on the unreliable UDP protocol. Using regular TCP was also discarded since its unicast nature would require having dedicated TCP connections between all servers. Handling server crashes with this setup also seemed complicated.

(16)

4.2.2 Evaluating JGroups

JGroups [16] was identified as a promising candidate for the communication between the trigger servers. JGroups is a toolkit for reliable multicast communication, supporting the notion of groups. Members form a group, and JGroups supports failure detection that can notify other servers when a server leaves the group (such as in the event of a crash). JGroups has both low-level communication classes, and more high-level classes, called building blocks. One of more interesting building blocks was MessageDispatcher, since it could be used to support synchronous and asynchronous message-passing, registering message listeners and registering listeners for group membership changes. Given that JGroups had all the features required, including the failure detection, it was further evaluated.

To evaluate JGroups, classes that tested the functionality of interest were written. After some initial problem with getting the message-passing to work, the functionality could be tested.

Having verified that the performance was more than adequate and that membership changes could be detected JGroups where chosen for the group communication needs.

4.3 Condition checking module

The condition checking module is where the conditions are checked for fulfillment.

Figure 4 - The condition checking module.

4.3.1 Area condition

An area condition’s fulfillment dependents on whether a mobile user is within a certain area or not. The condition can be true if the MS comes within the area, goes outside of the area, or

(17)

in any of these cases, depending on the type of the area condition. A threshold is needed to prevent the condition from triggering multiple times in case the MS moves parallel to the border of the area. Another thing to consider is that we only know an area that the MS is within, not an exact point. Even if some part of the mobile user’s area is within the condition area we can not be sure that the MS is actually within the condition area. Only if the whole mobile user’s area is within the condition area it can be established that the user must be within the condition area. To create a threshold and to prevent false triggering, all areas which are partially within the condition area are considered to be neither within nor outside of the area. Within area conditions should trigger if the user is within an area that is inside the condition area (the green area in Figure 5 below), outside area should trigger when the user is within an area that has no part within the condition area (the white area in Figure 5 below) and the both within or without area condition should trigger when the user is within any of these areas.

Figure 5 – The black border represents the border of an area condition.

4.3.2 Distance condition

The distance condition is fulfilled when the distance between two mobile users is smaller than, greater than, or either smaller or greater than a specified value. A threshold value is needed here as well, for the same reason as for the area condition. For this condition, a threshold can be achieved by only triggering for “distance shorter than X” when the

maximum distance between any points in the two areas is smaller than the specified distance.

Similarly, “distance longer than X” will only trigger if the minimum distance between any points in the areas specifying the location of the two mobile users is greater than the specified value. This also prevents any false triggering.

(18)

Figure 6 – The red and blue areas shows the location of two MS involved in a distance condition.

(19)

4.4 Cell Management module

The cell management module contains functionality related to the mobile base stations. It keeps tracks of the location of every base station as well as the areas they cover.

Figure 7 - The cell management module.

4.5 Condition management module

The condition management module contains classes that receive input from an application service provider (ASP). This can be a condition registration, a condition unregistration or an

“all MS within area” question. All communication with ASPs is done through XML documents. Receiving and sending XML documents was not something considered in this thesis, since this functionality was already implemented in Pacific Ocean. We did however design the XML documents used in the communication between the trigger system and the ASPs.

(20)

Figure 8 - The condition management module.

4.5.1 XML protocol for condition registration and reporting

In order to register a condition that should be triggered when the condition is fulfilled one should send a condition registration message. Below is an example of a registration message concerning a distance condition. The distance is given in meters. This condition will trigger when the two involved persons are at a distance shorter than 500 meters from each other.

<condition_reg>

<exp_time utc_off="+0200">20051109120000>

<distance_condition type="shorter">

</distance_condition>

</condition>

</condition_reg>

A registration concerning an area condition can include several MSISDNs at once. The area of interest can be specified either as a circle or as a polygon. The radius in the circle is given in meters. In the below message a registration is made concerning two persons, and the area is specified using a circle:

<condition_reg>

<exp_time utc_off="+0200">20051206120000>

<area_condition type="within">

<coord>

(21)

</coord>

</CircularArea>

</area_condition>

</condition>

</condition_reg>

Registering a tracking condition only requires specifying the MSISDN of the mobile subscriber to track and the shortest interval at which tracking updates should be sent.

<condition_reg>

<exp_time utc_off="+0200">20060409120000>

<tracking_condition>

<min_inverval>10</min_interval>

</tracking_condition>

</condition>

</condition_reg>

The answer to a successful registration only includes an ID for the condition. This ID will be included in the report that informs the ASP that a condition has triggered. The ID can be used by the ASP to look up properties for the registered condition that has triggered. Below is an example of a condition registration answer:

<condition_reg_answer>

<req_id>1234123434</req_id>

</condition_reg_answer>

When a condition has been fulfilled, a tlrep (triggered location report) message is sent. The type tlrep is a message that already exists in the MLP protocol, but we extended it for our needs. The following example shows a report that is sent as a result of a triggered distance condition:

<tlrep>

<req_id>1234123434</req_id>

<trl_pos trl_trigger="MS_PERIODIC">

<pd>

<shape>

<coord>

</coord>

</CircularArea>

</shape>

</pd>

</trl_pos>

<triggered_condition>

<triggered_distance_condition type="shorter">

</triggered_distance_condition>

</tlrep>

Specifying that the triggered condition is of type “shorter” may seam redundant, since the ASP could be expected to store whether the distance condition with the given condition ID is

(22)

of type “shorter” or “further”. However, it is necessary since the ASP can register a condition that triggers in both of these cases. Below is an example of a report that is sent as a result of a triggered area condition.

<tlrep>

<req_id>1233444146814</req_id>

<pd>

<shape>

<coord>

</coord>

</CircularArea>

</shape>

</pd>

</trl_pos>

<triggered_area_condition type=="within">

</triggered_area_condition>

</triggered_condition>

</tlrep>

Below is the XML message that is sent as a response to a triggered tracking condition.

<tlrep>

<req_id>1233343114773</req_id>

<pd>

<shape>

<coord>

</coord>

</CircularArea>

</shape>

</pd>

</trl_pos>

<triggered_tracking_condition>

</triggered_tracking_condition>

</triggered_condition>

</tlrep>

It is possible to query the trigger system to find all the mobile users that are located within a given area. The area of interest can be specified either as a polygon or as a circle. It is also possible to specify the maximum number of mobile users that should be returned for such a query.

<persons_within_area max_persons="500">

(23)

<coord>

</coord>

</CircularArea>

</persons_within_area>

A response to such a query can look like the following:

<persons_within_area_reply person_limit_reached=”none”>

<pd>

<shape>

<coord>

</coord>

</CircularArea>

</shape>

</pd>

</trl_pos>

<pd>

<shape>

<coord>

</coord>

</CircularArea>

</shape>

</pd>

</trl_pos>

</persons_within_area_reply>

4.6 Condition database

The requirement on the data structure storing registered conditions was that the conditions could never be lost, even if the server crashed. To meet this requirement a database

management system residing on disk was chosen for this database. Every type of condition has a number of properties that apply only to that condition type. These properties are stored in tables specific to each type of condition. There are also some properties that apply to all conditions. These properties are:

• Condition identifier. A number uniquely identifying the condition.

• Condition type. A number specifying the condition type.

• A flag specifying if this condition should be removed after triggering one time, or if it should be allowed to trigger more than once.

• Registration time. The date and time when the condition was registered.

• Expiration time. When the condition should be removed.

(24)

These general condition properties are stored in a table in the condition database called ConditionProperties. To easily check which conditions a mobile user is involved with, if any, there is a table mapping between the user’s MSISDN and the condition identification number.

The properties that apply to distance conditions are stored in a table called DistanceConditionProperties containing:

• The condition identifier, identifying this condition.

• A flag specifying if the distance condition is fulfilled when the distance between two mobile users is longer than the distance specified in this condition.

• A flag specifying if the distance condition is fulfilled when the distance between two mobile users is shorter than the distance specified in this condition.

• The distance that the distance between the two mobile users should be compared against.

• Two columns containing the MSISDNs of the two mobile users involved in this condition.

• A flag containing the previous state of this condition. If the condition becomes

fulfilled several times in a row, the system should still only trigger the condition once, until the condition becomes unfulfilled and then becomes fulfilled again. To achieve this, the state of the condition is stored here every time the condition is checked.

Information about area conditions is stored in five tables. One, called

AreaConditionProperties, contains the properties of the area condition and four tables are used to store the areas. The AreaConditionProperties table contains the following:

• The condition identifier.

• A flag specifying whether or not this condition should be fulfilled when the mobile user is within the specified area.

• A flag specifying whether or not this condition should be fulfilled when the mobile user is outside the specified area.

• A previous state flag.

• The MSISDN of the mobile user involved with this condition.

• A flag specifying if the shape of the registered area is a circle or a polygon.

The four other tables related to area conditions all describe registered areas. One is used to store polygon areas, another one to store information about circles. The last two tables contains information about which cells that are within a certain registered condition area, and cells lying on the border to a condition area.

The TrackingConditionProperties table, containing information about tracking conditions, consists of the following columns:

• The condition identifier.

• The minimum interval with which this condition should trigger.

• The earliest date and time at which this condition could be fulfilled again.

• The MSISDN of the mobile user involved with this condition.

To allow easy access to the condition database, we wrote a wrapper class with methods performing frequently performed tasks on the database. To active greater flexibility a Java interface that the database wrapper implements was created. To access the methods in the wrapper, the interface is used. If another storage system will be used in the future, the new

(25)

wrapper class has to implement the interface and no other changes have to be made elsewhere.

5 Implementation

This section describes in further detail the modules that were presented in the design chapter.

The chapter contains implementation details that are not of great importance for most readers.

5.1 Data collection module

The module that is used to collect the position data and do the initial processing is described in this section. A sequence diagram is also given that shows how the sequence of calls that are made when a position is received by the trigger system. Utility classes such as Person is also described.

5.1.1 The DataReceiver class

As described in the section 4.1.1 Data from the mobile network, data concerning mobile subscribers will be sent from a server that captures this data. The format of the data is also described in that section. The class DataReceiver is responsible for listening to and receiving this data. The work it performs is very limited; it receives the datagram and places it in a queue for later processing. It does not even parse the data. We decided to let DataReceiver perform as little work as possible, since the data flow into it will be so high. In case the amount of data received by DataReceiver is too large for the system to process, which could be determined by checking the length of the datagram queue, we can easily discard the data without having wasted any time parsing it.

5.1.2 The DataProcessor class

DataProcessor is the next step in the data processing chain, and its purpose is to parse the received data. It needs to determine if the received data concerns a MS which is already stored in the position database, or whether it needs to create a new entry in the position database. If the MS is already known to the system, the system needs to determine if the MS has moved since the last time a location was received for him or her. If the mobile subscriber has moved, the system proceeds by checking if the MS is involved in any conditions. Should that not be the case the processing can end here, which mean checking the condition database can be avoided. This is a major optimization, since the condition database is stored on disk. If the MS is not previously stored in the position database he or she is added to it, and in this case the condition database needs to be consulted to determine if the MS is involved in any conditions or not. If on the other hand the person is previously known to the system and the person is involved in at least one condition, then that condition is checked for fulfillment, by calling the method isFulfilled on the condition.

5.1.3 The PersonDatabase class

A choice was made to store the position data in a hashtable. To make it possible to change this to, for example, a database, an interface called PersonDatabase was designed. This interface is implemented by the class containing the hashtable, namely PersonHashtable. Everywhere where the position data needs to be accessed it should me done through this interface. The objects using the PersonHashtable do not know that its functionality is implemented in PersonHashtable. PersonHashtable can thus be replaced by some other class using another storage system. As long as it implements the PersonDatabase interface, objects that use this interface will not be affected.

(26)

5.1.4 The Person class

The person class represents a mobile subscriber. Apart from the mobile user’s MSISDN and position, it also stores the number of conditions the MS is involved in. This value is used when a MS has moved in order to know if there are any conditions to check for this MS. The obvious choice was to retrieve this information from the condition database. This would however require a massive amount of disk reads, since the conditions are stored using a disk- based database system. This fact, in addition to the large amount of position changes, makes this solution impossible.

5.1.5 The TriggerServer class

TriggerServer is the class that initiates the trigger system. It creates numerous objects, among others threads running the DataReceiver and DataProcessor classes, the database storing positions, the database storing cell information and a TriggerServerCommunication object, used when communicating with other trigger servers. TriggerServer is also the class that receives queries and requests from the other trigger servers. This is done by TriggerServer registering itself as receiver for different kinds of messages to TriggerServerCommunication.

Further information about how this works can be found in section 5.2.2. The messages that the TriggerServer receives are:

• Position queries. When a position query is received, the position database is queried for the position and the position is returned, if found.

• Condition involvement updates. When a condition has been added or removed from the system, all servers are notified. TriggerServer calls a method on its position database object that adds or subtracts the number of condition involvements for the mobile subscribers involved in the condition that was added or removed.

• Queries for all mobile subscribers connected to any of a list of cells. When this kind of query is received, the list is sent to the cell database object and the result from that call is returned to the sender of the original query.

• Take over- and return control requests. Further information about takeover when a server crashes can be found in section 4.1.2.

• Cleanup requests. These are sent in order to ask the other trigger servers if the sending server can start performing a cleanup of expired conditions from the condition

database.

5.1.6 Sequence diagrams for position reception

Below is a diagram of the sequence of calls that are made when a position update is received concerning a person who is involved in a distance condition, which happens to be fulfilled:

(27)

Figure 9 - Position reception leading to fulfilled condition.

Figure 10 describes the calls that are made when a position is received and the position is unchanged from the position previously stored for that person.

Figure 10 - Position reception of unchanged position.

(28)

5.2 Server communication module

This section describes the implementation of the classes used for communication between the servers in the trigger system. ReliableGroupCommunication contains general functionality for sending group messages that can be reused in other projects. TriggerServerCommunication is an easy to use class created for use specifically in the trigger system. The message class, GroupMessage, is also described.

5.2.1 The ReliableGroupCommunication class

A decision was made to hide the underlying complexity of JGroups by wrapping it in a class that exposed methods for performing group communication actions. Mobilaris also wanted to be able to reuse this component in other projects where servers needed to communicate with each other, so it was necessary to make it general enough to be useful for other projects apart from the trigger system.

The class ReliableGroupCommuncation uses a JChannel to connect to a group (which is identified by a group name, supplied to ReliableGroupCommunication) and on top of this channel the building block MessageDispatcher is used. The MessageDispatcher’s fuctionality is used to implement support for sending both synchronous and asynchronous messages to all group members using simple methods. These methods accept messages of type

GroupMessage, which is an abstract message class that was created. The class

ReliableGroupCommunication implements an interface in JGroups in order to be notified when messages are received. ReliableGroupCommunication only knows that the received messages are of type GroupMessage, but it does not know how to handle them. Its purpose is to receive the messages, and forward them to classes that have registered themselves as interested in these types of messages. It forwards the messages by calling methods on

registered listeners. For the message listener registration, ReliableGroupCommunication has a method, called registerMessageListener, which accepts a class to notify and the type of messages that it wants to be notified of.

As previously mentioned we decided to use JGroups to provide the functionality of notifying group members of server crashes. The building block MessageDispatcher offers the core functionality for this, by allowing a class to register itself as a membership listener. Since the details concerning this should be hided, ReliableGroupCommunication receives membership change notifications. Similarly to how message notifications are handled,

ReliableGroupCommunication receives the membership change, determines exactly which member has left or joined the group, and finally notifies interested parties of this change.

Classes which want such notifications register themselves as listeners using the method registerMembershipListener.

5.2.2 The TriggerServerCommunication class

A wrapper was constructed for ReliabeGroupCommunication, called

TriggerServerCommunication, to allow easy access to group communication functions from our trigger server’s classes. All objects in a trigger server share the same

TriggerServerCommunication object. TriggerServerCommunication can, for instance, be used to send a query about a mobile user’s position, by simply calling a method in

TriggerServerCommunication called sendPositionQuery. It takes the MSISDN of a mobile user and returns the position of that user if that user’s position was found on any of the other trigger servers. TriggerServerCommunication takes care of creating a message and calls a method in ReliabeGroupCommunication to send the message. TriggerServerCommunication

(29)

unregistered resulting in a mobile user being involved in one condition more or less than before.

The other functionality of TriggerServerCommunication is that objects can register

themselves to receive different messages that are relevant to our system from the other trigger servers. The kinds of messages that can be received by this class are position queries,

condition involvement changes, condition cleanup requests, connected people queries and information about other trigger servers leaving the group. To be able to send these kinds of messages to objects that are registered to receive them, TriggerServerCommunication register itself as a receiver for both messages and server information in ReliabeGroupCommunication.

Objects that want to receive a specific kind of message must implement an interface for that type. This interface forces that object to implement the receive method that will be called when a message of that kind arrives at the TriggerServerCommunication class.

5.2.3 The GroupMessage class

The messages that are received in TriggerServerCommunication are all of type

GroupMessage. GroupMessage is an abstract class that specific messages extend. One such specific message is PositionQuery, which represents a query about a mobile user’s current position. Another message extending GroupMessage is ConditionInvolvementChange, a notification about a change in the number of conditions a user is involved in.

5.3 Condition checking module 5.3.1 The condition related classes

All specific conditions, such as distance conditions and area conditions have a number of properties, as well as some functionality, in common. For instance, all conditions can be checked for fulfillment using the isFulfilled method. Every condition also has an expiration time, stating when the condition should be removed, so hasExpired is a method that needs to exist for all conditions. The properties that all conditions have in common are stored in the ConditionProperties class. In our code, all conditions extend the abstract class Condition, which has a number of abstract methods that the subclasses need to implement. For instance, the isFulfilled method needs to exist for all conditions, but the specific condition needs to supply the code to check if it is fulfilled.

When a mobile user has moved, and it has been determined that the user is involved in some registered condition, the ConditionChecker class in the condition checking module should be called, to initiate the fulfillment check of the condition. This is done from DataProcessor, which calls a class in PO, which in turn creates ConditionChecker. ConditionChecker uses the condition database to retrieve ConditionProperties objects for all the conditions that the MS is involved in. In order to retrieve the objects that can be used to check the user’s conditions, the ConditionFactory class is used. ConditionChecker will supply ConditionFactory with the basic condition properties, and using this information ConditionFactory creates objects describing the specific conditions that the user is involved in. Exactly what condition

ConditionFactory returns is transparent to ConditionChecker, since it only knows that it is of type Condition. ConditionChecker therefore uses the methods that all conditions implement, such as isFulfilled and hasExpired. If isFulfilled returns true the ASP should be notified that the condition has triggered, by sending the appropriate XML message.

M-LATS: a trigger-based system for location-based services

M A S T E R ' S T H E S I S

M-LATS

A trigger-based system for location-based services

André Dahlqvist Gustav Eriksson

Abstract

Preface

TABLE OF CONTENTS

1 Introduction

1.1 Purpose

1.2 Previous research

1.3 Requirements on the trigger system

1.4 Outline

2 Background

2.1 Mobilaris and Pacific Ocean

2.2 Mobile positioning

2.2.1 Base stations and cells

2.2.2 Cell ID and Timing Advance

2.2.3 Time of arrival

2.2.4 Angle of arrival

2.2.5 Global Positioning System (GPS)

2.2.6 Assisted GPS (A-GPS)

2.3 Location-based services

3 Theory

3.1 Tracking a large number of moving objects

3.2 Database management systems

3.2.1 Main-memory database systems

3.2.2 Spatial database systems

4 Design

4.1 Data collection module

4.1.1 Data from the mobile network

4.1.2 Handling server crashes

4.2 Server communication module

4.2.1 Server communication requirements

4.2.2 Evaluating JGroups

4.3 Condition checking module

4.3.1 Area condition

4.3.2 Distance condition

4.4 Cell Management module

4.5 Condition management module

4.5.1 XML protocol for condition registration and reporting

4.6 Condition database

5 Implementation

5.1 Data collection module

5.1.1 The DataReceiver class

5.1.2 The DataProcessor class

5.1.3 The PersonDatabase class

5.1.4 The Person class

5.1.5 The TriggerServer class

5.1.6 Sequence diagrams for position reception

5.2 Server communication module

5.2.1 The ReliableGroupCommunication class

5.2.2 The TriggerServerCommunication class

5.2.3 The GroupMessage class

5.3 Condition checking module 5.3.1 The condition related classes