International Conference on Advances in Computing, Communication and Control (ICAC3’09)

Real-Time GPS via Jamdroid Server enhanced by TelegraphCQ & Augmented by RFID tag

Mohammed A Qadeer

Department of Computer Engineering

Zakir Husain College of Engineering And Technology

Aligarh Muslim University, Aligarh 202002, India

maqadeer}@zhcet.ac.in

Faraz Khan

Department of Computer Engineering

Zakir Husain College of Engineering And Technology

Aligarh Muslim University, Aligarh 202002, India

farazkhan @zhcet.ac.in

Nadeem Akhtar

Department of Computer Engineering

Zakir Husain College of Engineering And Technology

Aligarh Muslim University, Aligarh 202002, India

nadeemakhtar @zhcet.ac.in

ABSTRACT As of now, GPS is an almost ubiquitous technology. However, it is not completely real time & it only deals with highways, freeways, sometimes main streets in large cities. Jamdroid is a real time, collaborative road traffic information system that aims to remedy these shortcomings of GPS. Jamdroid is a new collaborative project that gathers road traffic reports from all its end-users, compiles the data and reports back to the navigation software of the users. It involves a data analysis algorithm running on the user device, and Internet servers that retrieve the data from the user, merge them, and send them back to the community. We know that it might not be possible to equip every vehicle with a GPS receiver. Hence to maximize available traffic data, we explore the option of introducing RFID tag for gathering GPS data. Such a system is meant to be accessed by a large number of users, and has to be fast & responsive enough to deal with all the requests; hence, provisions must be made for effective live stream handling. We will see how such a system can gain immensely by incorporating Data Stream Management System, using open-source TelegraphCQ, for data stream processing & querying.

Categories and Subject Descriptors H.3.5 [Online Information Services]: Web based services, H.5.3 [Group and Organization Interfaces]: Web-based interaction, Evaluation/methodology, collaborative computing

General Terms Measurement, Human factors, Design, Reliability

Keywords GPS, Jamdroid, Live Stream Processing, DSMS, RFIDs, TelegraphCQ;

1. INTRODUCTION For an average consumer, GPS navigation software basically allows: Not to get lost; say, find a path to an unknown address

To find the shortest - or fastest - path to an address. The first point is well covered by the commercial solutions currently available. As for the second one, current products are able to figure the quickest route to the address, although using statically 'pre-defined' speeds, depending of the road used (130 km/h on a highway, 50 km/h inside a city, etc.). Nevertheless, the information it provides is accurate only when there is little or no traffic. When the user is stuck into a traffic jam, the total time for his travel is tragically increased.

Some entities - mainly 'institutional', such as state road departments, etc. - provide traffic information to an operator that sends it to the user, generally against a subscription to its service. Though quite accurate, this information can never, in principle be real-time. Hence a user may get the information for a particular road over a period of time, but can never get what is the current traffic on the road. Jamdroid is a totally new concept that proposes to address the points mentioned above.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

ICAC3’09, January 23–24, 2009, Mumbai, Maharashtra, India.

Copyright 2009 ACM 978-1-60558-351-8…$5.00.

Figure 1: Jamdroid Working

192

International Conference on Advances in Computing, Communication and Control (ICAC3’09)

Jamdroid is an application developed for the Android platform. Its goal is to provide real-time accurate information about road traffic, virtually anywhere on the globe, based on the idea that anyone driving a car with a GPS receiver can have its device estimate the traffic he just went through. Jamdroid supposes that each user owns an Android-capable device, with a GPS receiver, which has a permanent connection to the Internet. The devices will connect to a main Internet server that receives their information, and sends other users report as a reply. In this paper we introduce Jamdroid concept & also discuss issues of replacing GPS receiver in each car with RFID tag for providing the users with a greater amount of real-time information, which might not be plausible in a developing nation like India where GPS is still a novel metropolis concept.

All Jamdroid users are part of a community: everyone sends traffic information for the route he just went through, and receive information about the traffic in the area he is going toward. Jamdroid’s goal is to be complementary to existing traffic services such as that of Google Maps & Nokia Navigation to improve the user’s experience. Since Jamdroid is such a new concepts, it has some shortcomings. The traffic recognition algorithm, yet implemented, needs high-scale testing with various sets of data to improve the values of each parameter. Jamdroid needs to find partnerships with GPS navigation products - at least to define a stable API for them to integrate. However the problem that we intend to target in our paper is that pertaining to server robustness under heavy inflow of data streams. We will try to merge the high speed string processing capabilities of a Data Stream Management tool like TelegraphCQ with the ubiquitous demands & applications of Jamdroid. DSMSs can execute continuous queries over continuous data streams that enter and leave the system in real-time, i.e., data is only stored in main memory for processing. Such data streams could be sensor readings, stock market data, or network traffic [6].

2. EXISTING SOLUTION: REAL TIME GPS

SOFTWARE RECIEVER & ITS SHORTCOMINGS This work [25] was part of an effort to develop a receiver that solely depends upon software based processing. The Correlation operations are performed in software rather than using a hardware correlators. The receiver consists of RF front end and a SHARC DSP processor. The RF front end converts the L1 signal (1575.42 MHz) into a 2- bit digital data bit stream at 5.714 MHz. Only sign bit is read in to the SHARC processor through serial port. Data is

collected through chained DMA module so as to make real time processing of the collected data possible. This paper will discuss in detail about the GPS signal processing and various real time implementation issues involved. Since we are developing a receiver structure for Jamdroid, we focus our attention on Software GPS receiver structure.

2.1 Software GPS Receiver Structure

Fig. 2 shows the block diagram of Software GPS receiver. In this receiver, the satellite signal is received at 1575.42 MHz. This analog signal is sent through a RF down converter chip GP2010 [32]. This chip converts the frequency of the received signal from 1575.42 MHz to 4.292 MHz after three stages. This signal is then digitized at 5.714 MHz sampling frequency. Here, the sampling frequency is generated internally by the DSP and fed to GP2010 through serial port. This chip generates two bits, one for sign and one for data. For actual implementation, it was found that only sign bit is sufficient for signal acquisition and other signal processing algorithms. These digitized data bits are transferred from GP2010 to ADSP- 21060[3] processor using serial port. Various signal processing techniques are employed on this data stream to extract the navigation data bits. These navigation data bits are used to extract the user position.

The acquisition speed depends upon the number of samples and the amount of Doppler to be searched. The signal tracking approach presented here will work satisfactorily for a static scenario. But for dynamic applications the small acquisition time and higher order tracking loop are required.

3. WORKING PRINCIPLE & FEATURES OF

JAMDROID Jamdroid retrieves each location provided by the GPS (Location Provider). It reads its position, bearing, speed and time into a JDPoint. From the collection of JDPoints, it extracts 'segments' (JDTraffic), which consist of an array of consecutive points with the same bearing no longer than a customizable size - eg. 100 m in a city, 5 km on a highway considered 'homogeneous' in terms of traffic intensity.

Fig 3: JDPoint & JDTraffic

Figure 2: Block diagram of Software GPS structure [25]

193

International Conference on Advances in Computing, Communication and Control (ICAC3’09)

When a new JDTraffic is built, it is analyzed, to get an estimation of the traffic. Simply put, it runs a pattern recognition algorithm, that detects and removes 'normal' stops (traffic light) extracts the max speed on the segment, the average speed, and the 'jitter' (being the average of the differences between each JDPoint speed and the max speed) finds low-speed segments that are not due to 'normal stops' compare the max and average speeds to the type of the road, if available.

The results of these steps allow defining: • a traffic rate (percentage, 0% being 'fluid road') • a reliability of the accuracy of this rate (percentage, 0%

being 'highly doubtable). The reliability depends on how well the pattern was recognized in the JDTraffic. If other users went through the same segment 'recently', Jamdroid already has a JDTraffic (received from the server) describing this portion of the road.

The JDTraffic segment is then compared and merged with previous segments. It allows improving the reliability of the information, according to the following considerations. • The more users report information, the more reliable it is. • The more similar traffic rates are amongst all users, the more

reliable it is. • The more recent, the more reliable • 'Fluid traffic' is by essence more reliable than 'congested': a

car cannot go faster than the traffic, though it can go slower. • Motorbikes and scooters are not reliable: they can usually

run faster than cars in a traffic jam. So are bicycles, pedestrians, trucks, delivery vehicles. Those users can be flagged as 'unreliable'. Thus, they will receive traffic information, but the data they report will not be used by other users. Once processed, the JDTraffic is ready to be sent to the server, to get forwarded to the other users.

When a user receives a new - or updated - JDTraffic, it is displayed on its map as an Overlay. The system distinguishes between several levels of congestion:

• LOCKED (0-25%): One can hardly move its car. • JAMMED (25 - 50%): heavy congestion • CROWDED (50 - 75%): one runs slower than normal • FLUID (75-100%): no congestion problems.

For the current (Activity) application, the traffic is displayed as black, red, orange and green segments directly on the map, over the road/street.

0

20

40

60

80

100

Traffic Intensity

Locked

Jammed

Crowded

Fluid

Figure 4: JDTraffic Parameters

3.1 Technical details of the Web Service

When a user starts Jamdroid, it connects to the public Internet server. It then sends to the server a 'Subscription' request, specifying its current area, or any area it is likely to be interested in (for instance if he's planning a long trip). The server sorts all connected users, according to the area they have registered into. It also memorizes in a database all traffic data it has received from clients.

• When a user enters (registers) an area, all the traffic information known by the server about this area is sent to the Jamdroid client.

• When a user exits an area, it can 'Un-subscribe' for this area, and 'Subscribe' for another one (or several others).

• When a user runs through a street and process a JDTraffic information (a new one, or an update to an existing one), it sends this information to the server, that updates its traffic database. The JDTraffic is then sent to every user that has registered for the current area. Of course, Jamdroid will update the map of the client, if necessary.

After some time, traffic information is just not useful anymore, since its reliability decreases when the time since initial analysis increases. At some point - customizable, but around an hour, it can be just ignored. The server removes outdated data from its database.

As the amount of queries & updates that is to be handled by Jamdroid server reaches panoramic proportions, a mechanism needs to be devised to handle such heavy influx of data. It is for this purpose that we study feasibility of introducing TelegraphCQ within the Jamdroid Architecture.

4. TelegraphCQ working principles & design

[26,7] TelegraphCQ is characterized by its developers as “a system for continuous dataflow processing” that “aims at handling large streams of continuous queries over high-volume highly variable data streams” [19]. TelegraphCQ is a streaming query processor that filters, categorizes, and aggregates flow records according to one or more continuous queries, generating periodic reports. TelegraphCQ accepts continuous queries in the CQL query language [1]. TelegraphCQ’s query language features include windowed joins, grouped aggregation, subqueries, and top- K queries. TelegraphCQ is based on the open-source PostgreSQL database engine and supports PostgreSQL’s user defined types, user-defined aggregates, storage manager, and application APIs [4]. The work in this paper uses the latest development version of TelegraphCQ, which incorporates a new data ingress layer, additional query language support, and substantial performance improvements. TelegraphCQ is based on the code of the relational DBMS PostgreSQL and required major extensions to it to support continuous queries over data streams, like adaptive query processing operators, shared continuous queries, and data ingress operations. The format of a data stream is defined as any other PostgreSQL table in PostgreSQL‘s Data Definition Language (DDL) and created with the CREATE STREAM command before a continuous query can be launched and processed. The Wrapper Clearing House (WCH) is responsible for the acquisition of data from external sources, like the packet capturing tool TCPdump.

194

International Conference on Advances in Computing, Communication and Control (ICAC3’09)

The WCH loads the user-defined wrapper function for the source. The wrapper is reformatting the output of the source into the PostgreSQL data types according to the DDL definition of the particular stream. There is always a one-to-one relation between source and wrapper, and between wrapper and stream. The WCH can manage multiple wrappers. At the beginning of this project (August 2008), we identified TelegraphCQ as the only available public domain DSMS. The newly created tuples of each stream are placed by the WCH into the shared memory infrastructure to make them available to the rest of the system. The query processing is performed in the BackEnd and the results are placed in corresponding queues in the shared memory infrastructure. Finally, the FrontEnd continually de-queues the results and sends them to the client. In order to reuse results, it is necessary to start TelegraphCQ in such a way that the standard output is written to a file.[6]

Both the TelegraphCQ front-end (TFE) and the TelegraphCQ back-end (TBE) are PostgreSQL backends. There are multiple TFEs (one per client connection) and one TBE. As shown in Fig 5 Architecture diagram above, a separate PostgreSQL process (TFE) is forked for each client connection. This process runs all queries that do not involve streams using the normal PostgreSQL executor. When PostgreSQL receives a continuous query, the TFE parses and plans the query in shared memory. It uses the output of the PostgreSQL optimizer to construct a continuous query plan. Next, the TFE passes the plan to the TelegraphCQ backend executor (TBE) using a shared memory queue.

The TBE runs the TelegraphCQ eddy which merges all continuous query plans into one so that query processing may be shared amongst queries. The TBE receives the plan, and integrates it into the TelegraphCQ eddy. Finally, the Eddy returns results to the appropriate TFE via shared memory result queues, one per query. The TelegraphCQ executor is an eddy, a continuously

adaptive query processing mechanism. An eddy is a routing operator that contains a number of modules that perform work on behalf of queries, and a number of sources that provide input data. The eddy obtains data from sources, determines which modules a particular tuple must visit before all processing for the tuple is complete. After a tuple has visited all required modules, it is output to all relevant result queues by the eddy. [26]

5. PROPOSED ASSIMILATION OF TELEGRAPHCQ

WITH JAMDROID

It was discussed earlier in the paper that Jamdroid server has to handle tremendous amount of data coming from various vehicles with Jamdroid support. The maintenance & processing of such large streams of data cannot be done effectively on the conventional stream handling tools. It is in this respect that we propose a possible incorporation of DSMS tools within the Jamdroid server for stream handling. Since TelegraphCQ, a DSMS tool, is able to handle queries from various sources, therefore, it may be plausible for the data of all roads traffic within the city to be entered in the master database simultaneously. Hence in application like JDTraffic analysis (where the vehicular concentrations on certain busy highways may reach levels as high as a few million vehicles a day), this may be quite beneficial due to TelegraphCQ’s efficient high data stream processing ability. Also, it may not be possible in developing nation like India, to have the GPS support for every vehicle. We may RFID tag vehicle (much cheaper alternative) & use this tag to send information like speed of vehicle to the RFID receiver, which may then route this information to the Jamdroid server as shown in figure 6.

Figure 5: Nuts & bolts view of TelegraphCQ

architecture[26]

Fig 6: Assimilation of RFID concept with Jamdroid

195

International Conference on Advances in Computing, Communication and Control (ICAC3’09)

As shown in figure 7, we route the information sent by many car sources to TelegraphCQ which has the capability to process them all at once. This information is then passed on to the Jamdroid server as a single stream of data after Continuous Query processing by TelegraphCQ’s TCQ Wrapper Clearing House.

Hence the server is saved from the bombardment of data stream from many sources. This proposed system is extremely robust as TelegraphCQ has shown exemplary stream processing capabilities even at such high data rates as 2 MB per second without error. Such a high value is never going to be exceeded in practical traffic analysis problems.

Figure 7: Proposed Architecture of Jamdroid with TelegraphCQ & Data Flow

6. DATA MINING WITH THE PROPOSED SYSTEM

The system just discussed in V might have solved the problem of high volume stream management. However, through incorporating Data Mining by storing the traffic information sent by the vehicles about a particular road, we can predict the future possibilities that the road may be Locked over the next hour or so. Some of the Data Mining techniques for live streams of data are discussed below:

• Time machines: This system allowed us to conveniently “travel back in time”, & hence it was termed Time Machine. It buffers the stream data first in main memory & then carries over to hard disk, providing several days of nearly complete historic data and supporting timely access to troubleshoot. This system was tested at speeds as high as 2.1 MB/s & performed well until retention levels were reached. However in many Jamdroid applications, retention level may not be the reached as it happened when such high volumes of data were stored for days. In our case, we are storing data for a few hours only.[7, 10, 18]

• Bit Map Indexing: Bitmap indexing was first used in DSMSs when TelegraphCQ was coupled with FastBit embedded in an end-to-end system. FastBit implements a set of compressed bitmap indices using an efficient compression method called the Word Aligned Hybrid (WAH) code. The system was tested at speeds of 20000 records per second & performance was excellent. For further studies reader is referred to [22, 30,31]

• Very Fast Decision Tree learner: VFDT is a decision tree learning [5, 28] implementation for Data Mining & is built on top of Hoeffding Algorithm. It is extremely robust data mining technique & can handle say traffic-data to the tune of million hits per day. VFDT is I/O bound i.e. it takes lesser time to mine data in lesser time than it takes to input them from disk.[10].

7. CONCLUSIONS Jamdroid is an extremely exciting prospect for future GPS enhancement or possible takeover. The possibilities with such a system are endless especially in the ubiquitous applicability that it exhibit. The possible future enhancements of such a system may be implementing user properties like asking user if it want to send the state of traffic it just analyzed, implementing a reliability threshold, and sending such information as accident, street under construction, weather conditions, wonderful landscape, cheap gas station, & 'Jamdroid community meeting point' on a particular road. The system proposed by us heavily reduces the load on the Jamdroid server, a particular future enhancement that can even further reduce the load is implementation of direct Peer to Peer communication between users. It is still early days in Jamdroid technology & Jamdroid needs to find partnerships with GPS navigation products - at least to define a stable API for them to integrate. The potential strength of Jamdroid comes from the community that we will build around it: without a sufficient user basis in a particular area, it will not be useful to anyone! Indeed, Jamdroid proposes a new approach to GPS navigation: due to the lack of detailed traffic information in particular area, say, in city centers - people that use their car to go to a place they know don't feel that they need to use their GPS! With Jamdroid, anyone that takes its car to go to work will be informed in real-time of the traffic conditions, the time he can estimate to his destination, the best way to take, etc. By turning his GPS on, the user will benefit from other users information, and he will provide new - or updated, more accurate - traffic information to the community.

Of course, associating specific GPS locations at a particular time to identified reasons can lead to legitimate concerns about the users privacy. This will be addressed with the help of external instances which purpose is to verify such data recordings (CNIL, www.cnil.fr, France). The exchange communication protocol will also probably be released publicly, to be reviewed by anyone that wants to have an insight into it. By assimilating DSMS tools for data storage, the Jamdroid system may benefit immensely & reduce the delays that may be involved in processing information as well as lending efficiency to the Jamdroid Server.

7. REFERENCES [1] A. Arasu, S. Babu, and J.Widom. The CQL continuous query

language: Semantic foundations and query execution. Technical Report 2003-67, Stanford University, 2003.

[2] Abdulhai B, Look, H, "Safety benefits of dynamic route guidance: boon or boondoggle, Itntelligent Transportation Systems," 2002. In Proceedings. The IEEE 5th International Conference, pp. 544-548, 2002.

[3] ADSP-2106x SHARC DSP User’s Manual

[4] Babcock, B., Babu, S., Datar, M., Motwani, R., Widom, J.: Models and Issues in Data Stream Systems, ACM

Car with Jamdroid

Support/RFID tag

sends information

Jamdroid

Server

receives

information

TelegraphCQ

process

streams from various sources

JDTraffic

Analysis

Information

broadcasted to

cars in vicinity

196

International Conference on Advances in Computing, Communication and Control (ICAC3’09)

Symposium on Principles of Database Systems PODS 2002, Dallas, Texas, USA, May 2000

[5] Brieman, L., et al. “Classification & Regression Trees”, Wadsworth, CA,1984

[6] Carney, D., Cetintemel, U., Cherniack, M., Convey, C., Lee, S.,Seidman, G., Stonebraker, M., Tatbul, N., Zdonik, S.,:Monitiring Streams- A New Class of Data Management Applications

[7] Chandrasekaran,S.,TelegraphCQ: Continuous Dataflow Processing for an Uncertain World, In Proc of CIDR Conf, 2003

[8] Collins, Jonathan (2 February 2004). RFID Journal- Consumers Voice Opinions on RFID. [WWWdocument] URL http://www.rfidjournal.com/article/articleview/780/1/1

[9] Cranor, C., Johnson, T. Spatcheck, O., Shkapenyuk, V.: Gigascope: A Stream Database for Network Applications, ACM SIGMOD 2003, San Diego, California, USA, June 2003

[10] Domingos, M., Hulten, G. :”Mining high speed data streams”, KDD 2000, Boston, MA

[11] Eiichi T, Naoki A, "Probabilistic Vehicle Routing and Scheduling Based on Probe Vehicle Data", International Journal of ITS Research, Vol 2, No. 1. pp. 21-28, Oct. 2004.

[12] Golab, L., O¨ zsu,M.: . Issues in Data Stream Management. SIGMOD Record, 32(2), 2003.

[13] Graefe,G.. Goetz graefe. SIGMOD Record, 18(9):509–516, 2006.

[14] Haas, P., Hellerstein, M.:. Ripple joins for online aggregation. In A. Delis, C. Faloutsos, and S. Ghandeharizadeh, editors, SIGMOD, pages 287–298. ACM Press, 1999.

[15] Iannaccone,G.: CoMo: An Open Infrastructure for Network Monitoring – Research Agenda, 2005

[16] Jagadeesh, G.R., Srikanthan, Tand Quek, .H. "Heuristic techniques for accelerating hierarchical routing on road networks," Intelligent Transportation Systems, IEEE Transactions, V61 3, No. 4, pp. 301 - 309, Dec. 2002.

[17] Jamdroid Homepage: http://www.jamdroid.org

[18] Kornexl et al., “Building a Time Machine for Efficient Recording and Retrieval of High-Volume Network Traffic”, Internet Measurement Conference, 2005.

[19] Krishnamurthy, S., Chandrasekaran, S., Cooper, O., Deshpande, A., Franklin, M. J., Hellerstein, J. M., Hong, W., Madden, S., Reiss, F., Shah, M. A.: TelegraphCQ: An Architectural Status report, Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, March 2003.

[20] Li S., "Dynamic congestion pricing hased oo traffic guidance with Kalman filtering theory, " Control and Automation, 2002. ICCA The 2002 International Conference, pp. 239 - 239, Jun 2002.

[21] Li, Y., Mcdond M. "Link Travel Time Estimation Using Single GPS Equipped Probe Vehicle," The IEEE 5th Initernational Conference on Intelligent Transportation Systems, pp Sep. 2002.

[22] Reiss et al., “Enabling Real-Time Querying of Live and Historical Stream Data”, 19th International Conference on Scientific and Statistical Database Management, (SSDBM 2007)

[23] Rotem,D., Stockinger,K., Wu, K.:. Optimizing Candidate Check Costs for Bitmap Indices. In CIKM, 2005.

[24] Simon H, "Neural Networks A comprehensive Foundation Second Edition," Tsinghua Publishing House, Beijing, 2001.

[25] Sonoval, N., et al. Real Time GPS Software Receiver with New Fast Signal Tracking Method, RWS 2008.

[26] TelegraphCQ: http://telegraph.cs.berkeley.edu/, 2008.

[27] Tomio Ml, Takaaki S And Taka Mn, "Route Identification and Travel Time Prediction Using Proe-Car Data," International Journal of ITS Research, Vol 2, No. 1, pp. 21-28, Oct. 2004.

[28] Utgoff,P.: “An improved algorithm for incremental induction of decision trees”, Proceedings of International Conference on Machine Learning, pages 318-325, NJ, 1994

[29] Wang W, "Practical speed-flow relationship model of highway traffic-flow," Journal of Southeast University (Natural Science Edition), Vol.33, No.4, Jul.2003.

[30] Wu,K., Otoo,E., Shoshani,A.: “An Efficient Compression Scheme For Bitmap Indices”, ACM Transactions on Database Systems, 31:1–38, 2006.

[31] Wu,K., Otoo,E., Shoshani,A.: “On the Performance of Bitmap Indices for High Cardinality Attributes”, VLDB, 2004.

[32] Zarlink Semiconductor,GP2010 GPS downconverter chip Datasheet.

[33] Zhang Z, Nu J. "Dynamic Route Guidance Using GPS Equipped Taxi Data” The Seventh International Conference on Electronic Measurement and Instruments," P546-552, Aug.2005

197