Proceedings of the 2012 International Conference on Machine Learning and Cybernetics, Xian, 15-17 July, 2012

RESEARCH AND DEVELOPMENT OF LOCATION-BASED SYSTEM

PO-LUN CHANG., FEI-HU HSIEH2, I-TA TSAI3

12Department of Electrical Engineering, Lunghwa University of Science and Technology, Taiwan 3Telematics & Control System Division Vehicular Information Control Department,

Information & Communications Laboratories, Industrial Technology Research Institute Hsinchu, Taiwan, RO.C. E-MAIL: lwhc1223@ms7.hinet.net.2sfh@mail.lhu.edu.tw.3ITa.Tsai@itri.org.tw

Abstract: With wireless communication network and GPS

positioning technology, most of current existing systems using

IP protocol to provide various information services such as

traffic and navigation. In this paper, we propose a location­

based system with W A VEIDSRC present a low delay and high

mobility system architecture constructed on the road. It provides vehicles with more intelligent real time information

such as news and location-based contents. We also implement

the system, which shows location-based content in the service

area.

Keywords:

WA VEIDSRC; Location-based Service

1. Introduction

Accompanying with the rapid spread of various location­based services (LBS) applications, most of current existing systems were designed under IP protocol, which limited by time delay and bandwidth. Some of current existing systems are even limited by mobility.

Vehicle communication needs to meet requirements above such like high mobility and low delay. For these reasons, we need a protocol stack for transmitting messages for vehicle environment, which stacks of IEEE standard is under standardization [1], and consists of IEEE 802.lIp [2] for the WAVE PHY and MAC layer, IEEE 1609 [3-6] for the WAVE MAC. According to the data of Figure 1-2 [7] shown below, WA VEIDSRC meet our system communication requirement, which provide low delay and 3 Mbps throughput within 300 meters.

In this paper, we propose the new location-based system architecture to provide real time information around the road including location-based content by using W A VEIDSRC with wireless network constructed for the outside environment of the vehicle. The location-based system architecture is composed of three elements.

One is the content management server (CMS), which selects and sends location-based contents to road side units

978-1-4673-1487-9/12/$31.00 ©2012 IEEE

(RSUs) according to RSUs' GPS location data via wireless network. Another is the road side unit (RSU) , which processes, encodes, and broadcasts encoded locations-based contents to on board units via W A VEIDSRC. The other is the on board unit (OBU), which receives and decodes data sent by RSUs. Furthermore, our demonstration system will also be demonstrated in this paper.

6 I __ Broadcast I

5

/ _4 i -------�3

�

� � ... 2

------1

0 0 50 100 150 200 250 300 350

Distance (meter'

Figure 1. Performance comparison: latency versus distance

3.5 I __ Broadcast I 3

'"[ 2.5 .., :ii :; 2 Co fo 1.5 � 0 � 1

0.5

0 0 50 100 150 200 250 300 350 400

Dj'tancr (meter'

Figure 2. Performance comparison: throughput versus distance

1907

Proceedings of the 2012 International Conference on Machine Learning and Cybernetics, Xian, 15-17 July, 2012

2. Location-based System with W A VEIDSRC Design

A. Architecture

Our system integrates W A VEIDSRC and wireless networks to meet the dissemination of information, largely consists of two sub-systems. One is the CMS to RSU system, which selects and sends location-based contents to RSUs via WLAN. The other is the road to vehicle system, which processes, en/decodes, and broadcasts encoded locations­based contents via W A VEIDSRC. Figure 3 shows the system architecture of W A VEIDSRC-based intelligent telematics system.

The elements of the location-based system de script as follows:

1) eMS: content management server (CMS) manages a

location-based contents database, an RSU registry database.

When completed, a new RSU is set up, must be registered to

the CMS to record RSU location and device information.

CMS will send location-based contents base on RSU

location.

2) RSU: road side unit (RSU) receives, encode data

from the CMS, broadcasts encoded location-based data to

neighboring OBUs via WA VEIDSRC. To ensure that the

OBU can receive complete information from RSU, RSU

broadcasts encoded location-based contents using LDPe code [8].

3) OBU: on board unit (OBU) receives, decode data

from the RSU using WAVE short message protocol

(WSMP) of W A VEIDSRC, provide a navigation platform

for user to view the decoded location-based contents.

B. Sequence diagram

We designed the Sequence diagram for the location­based system. Since RSU information register at the CMS, the CMS can push location-based content to RSU continuously. RSU broadcasts the last location-based content to OBD. Figure 4 shows how an OBU receives location-based contents from a RSU, how a RSU registration to the CMS and receives contents from the CMS. Following is operations during this processing:

The steps of sequence diagram as follows: 1) Registration: After the RSU get GPS information,

the RSU sends registration information to the CMS.

The data link between RSU and CMS is shown in Figure 3.

2) Send location-based iriformation: After the CMS

receives the RSU registration information, the CMS register

the RSU information and sends location-based information

to the RSU.

3) Broadcast location-based iriformation: The RSU

broadcasts all location-based contents by

W A VEIDSRC. The time interval between information

is one second in our system. When a vehicle

approaches the RSU, OBU can receive all of the

location-based information and display the traffic

information on the front screen of UMPC to passenger.

4) Broadcast location-based iriformation: The RSU

cycle broadcasts all location-based contents by

WAVEIDSRC.

5) Send location-based iriformation: The CMS update

RSU contents immediately when the CMS receives new

contents from the CMS administrator.

6) Broadcast location-based iriformation: The RSU

cycle broadcasts new location-based contents by

WAVEIDSRC.

C. Location-based content format

In our system, we call a set of location-based content as "an attraction". We define the format of an attraction information string in our system. The data format is defined as Figure 5.

�'--, / ,

RSU \ ,

eMS

Figure 3. W A VEIDSRC-based intelligent telematics system

1908

Proceedings of the 2012 International Conference on Machine Learning and Cybernetics, Xian, 15-17 July, 2012

ICMSllRsul IOBUI I I I I I I I I I 1) Registration : : It I I I I I I I I

� Send location-bas�d i : information IIi i I I I

i j) Broadcast locatio�-: : based informatioh I I I

i 4) Broadcast locatiort-i i based informatio� :b Send location-basbd i i information IIi i : 6� Broadcast locatioili-

: based informatio'jl I I

I I

I I

Figure 4. Data flow of location-based information processing

$POIINFOI<1>1<2>1<3>1<4>1<5>1<6>1<7>1<8>1<9>

$POIINFO: location-based content message header <1> POI Latitude <2> POI Longitude <3> POI Photo File Name (Optional) <4> POI Voice File Name (Optional) <5> POI ID <6> POI Name <7> POI Description <8> RSU Latitude <9> RSU Longitude

Figure 5. OBU software architecture

Figure 6. The algorithm ofOBU

The description of an attractions' information is stated below:

1) POI Latitatude: It indicates the latitude information

of the attraction. This is a type of float.

2) POI Longitude: It indicates the longitude

information of the attraction. This is a type of float.

3) POI Photo File Name: It indicates the photo file

name of the attraction. The RSU sends photos encoded by

LDPC code and the OBU recevice photos mapped

attraction with attraction photo file name. If there is no

photo for the attraction, this column value will be "NULL".

This is a type of string.

4) POI Voice File Name: It indicates the voice file

name of the attraction. The RSU also sends voice files

encoded by LDPC code and the OBU recevice voice files

mapped attraction with attraction voice file name. If there is

no voice for the attraction, this column value will be

"NULL". This is a type of string.

5) POIID: It indicates the location-based attraction ID.

This is a type of integer.

6) POI Name: It indicates the location-based attraction

name, displayed on the OBU. This is a type of string.

7) POI Description: It indicates the location-based

attraction description, displayed on the OBU. This is a type

of string.

8) RSU Latitude: It indicates the latitude information of

the RSU broadcasting the attraction. This is a type of float.

9) RSU Longitude: It indicates the longitude

information of the RSU broadcasting the attraction. T This

is a type of float.

D. Algorithms of OBU

In this section, we present how an OBU picks an attraction to display. We use the concept of the candidate area. An OBU owns its candidate area to collect the closest six attractions and select one of these attractions, which satisfied our algorithm. The algorithms' legend shows as figure 6.

1909

Proceedings of the 2012 International Conference on Machine Learning and Cybernetics, Xian, 15-17 July, 2012

7 I �HSUPACategory 61 ,76 I __ WAVE/DSRC 6 �

5

� 4 QJ Co 11 3 .., :2: 2

"-'" 2.88

----- 1.92 1.44 1.15

o

2 3 4

User

Figure 7. Mbps per user vs. User

Our system creates the location table of attractions location information, records the last OBU GPS information and processes the algorithm every three seconds, which follows steps below.

1) Keep the selected attraction: Each process result

may not have a "selected attraction", so we have to keep the

last selected attraction to display.

2) Calculate the direction of OBU: We use the

Pythagorean theorem to calculate the approximate direction

by using the last GPS information and the current GPS

information.

5

3) Check each attraction: At first step, we use the

Pythagorean theorem to calculate the approximate direction

by using the current GPS information and attractions'

location information. The second step use the law of

cosines to calculate the angle <p between two directions we

got at step 2 and step 3 for each attractions. If <p is under

60 degrees, we pick it up and calculate the distance at the

next step. The last step, we also use results bellow to judge

the attraction on the OBU's right side or not for playing

different voice.

4) Choose attractions by distance: We use the

Haversine formula to calculate the distance between the

OBU and the am·action we picking from step 3.

5) Choose cadidate attractions: We collect the closest

attraction to cadidate area until six attractions in the area.

6) Select the attraction: If the closest attration distance

within 150 meters, we choose the attraction as the selected

attraction.

E. Message transmission

In this section, we compare W A VEIDSRC with HSUP A Category 6 [12], which has been one of most popular Third Generation cellular systems with maximum data rate of 5.76 Mbps using the IP protocol. Figure 7 shows the chart presenting the relationship between user numbers with data rate.

2 In this chart, even though the data rate of HSUP A is wider than W A VEIDSRC, the MbpslU ser of W A VEIDSRC is better than W A VEIDSRC.

Figure 8. Equipmeut ofRSU

RSU Manager

Registration I Network

Library Library I LDPC Code

Library

GPS I Wave I Camera IWLAN

Handler Handler Handler Handler

as

Figure 9. RSU software architecture

3. Attraction Demo System (ADS)

Based on the preceding section, we employ the attraction demo system using location-based system with WAVEIDSRC.

In our implementation, we use a WAVE-BOX as communication device, which is a device that can communicate with each other through W A VEIDSRC technology. RSU and OBU both need to send/receive information by W A VEIDSRC respectively. W A VEIDSRC­based intelligent telematics system uses the control channel (CCH) for sending encoded data, termed WSM (WAVE short message) in the WAVE standard.

1910

Proceedings of the 2012 International Conference on Machine Learning and Cybernetics, Xian, 15-17 July, 2012

F. RSU Implementation

Figure 8 shows the RSU equipments. RSU PC responsible for control of the WAVE-BOX, encoding message, which is connected to the WAVE-BOX by Ethernet. RSU PC needs a GPS receiver to measure latitude and longitude, and also needs a camera for streaming video if there has been a vehicle accident. When RSU needs to send information, the RSU PC sends it to WAVE-BOX in UDP format. Then WAVE-BOX converts it to WSMP format and radios it out. WAVE-BOX can also receive WSMP information and then convert it to UDP format for RSU Server receiving.

There are four types of information that should be handled by the RSU PC, which are WSM information sending to OBU, streaming real time video by the plug-in camera, current GPS information when registered to the CMS and WLAN registration and location-based contents message between RSU and CMS. In order to achieve these functions, we designed a software architecture on the RSU PC as Figure 9. We also imply three libraries for RSU manager, which contain registration library used for communication between RSU and CMS, network library used for W A VEIDSRC and WLAN communication handler, LDPC library used for encoding message.

IUMPC I+-----�L_ ____ � Ethernet -

WAVE BOX

tWSMP

Figure 10. Equipment of OBU

Navigation platform

Network Navigate LDPC Code Library Library Library

GPS Wave Handler Handler

as

Figure 11. OBU software architecture

G. OBU Implementation

Figure 10 shows the OBU equipments. UMPC responsible for control WAVE-BOX, decoding message, which is connected to the WAVE-BOX by Ethernet. When RSU needs to receive information, the UMPC listens it UDP port. While WAVE-BOX receives message from WSMP, WAVE-BOX will converts it to UDP format and sends to the UDP port.

There are two types of information that should be handled by the UMPC, which are WSM information from RSU and current GPS information show on the navigation map. In order to achieve these functions, we designed software architecture on RSU PC as Figure 11. We also designed three libraries for the navigation platform, which contain navigate library used for display location-based contents or live streaming, network library used for WA VEIDSRC and WLAN communication handler, LDPC library used for decoding message.

H Taipei Attractions Demo System Demo scenario

We first demonstrated the Taipei attractions demo system in VTC 16-19 May, 2010. The demonstration environment of attractions demo system is shown in Figure 12.

In this demonstration, our direction is from Start to Finish marked with the blue line, has three RSU including RSU A, RSU B and RSU C, has five attractions including A, B, C, D and E. The RSU A broadcasts attraction A, B and C; the RSU B broadcasts all attractions; the RSU C broadcasts attraction D and E. Broadcasting overlay can make sure the way Start to Finish, even Finish to Start can receive all attractions.

Figure 12. Demonstration environment in VTC 2010

In figure 13, we present the user inter face of the Taipei attractions demo system, which shows the Martyrs' Shrine information, largely consists of four parts. The first is "Live map", which shows current map, points the Martyrs' Shrine by an arrow and the RSU A location. The second part is ''Nearby attractions", which shows the closest six attractions.

1911

Proceedings of the 2012 International Conference on Machine Learning and Cybernetics, Xian, 15-17 July, 2012

The third is "Attraction photo", which displays the Martyrs' Shrine picture. The last is "Attraction name, description", which shows the attraction name and description.

4. Conclusion

In this paper, we propose the location-based system with W A VEIDSRC to decrease delay time, mobility and provide the latest location-based information immediately. We believe that the W A VEIDSRC technology will be the next generation vehicle communication protocol. Our demonstration system has been successful implemented, demos in VTC 2010 and used for introduction of Taipei attractions.

Although we propose the algorithm to pick up attractions, the algorithm misjudges on ring roads. We will solve the problem in the near future.

Tai pei Attractions Demo System

name, description

Figure 13. Demo navigation system user interface

References

[1] IEEE 1609 Working Group, http://vii.path. berkeley.eduJl609 _ wavel

[2] IEEE 802.11pID5.0 Wireless LAN Medium Access Control (MAC) and Physical Layer (PRY) specifications, November 2008.

[3] IEEE PI609.1, Trial-Use Standard for WAVE­Resource Manager, October 2006.

[4] IEEE PI609.2, Trial-Use Standard for WAVE­Security Services for Applications and Management Messages, July 2006.

[5] IEEE P1609.3IDl.O, Draft Standard for WAVE­Networking Services, December 2008.

[6] IEEE P1609.4IDl.O, Draft Standard for WAVE-Multi­channel Operation, December 2008.

[7] K. Y. Ro, P. C. Kang, C. R. Rsu, and C. H. Lin, "Implementation of W A VEIDSRC Devices for Vehicular Communications," 3CA, 2010

[8] Cunche M. and Roca V., "Optimizing the Error Recovery Capabilities of LDPC-staircase Codes Featuring a Gaussian Elimination Decoding Scheme," 10th IEEE International Workshop on Signal Processing for Space Communications (SPSC'08), Rhodes Island, Greece, octobre 2008.

[9] B. Rao and L. Minakakis, "EVOLUTION of Mobile Location-based Services," Communications of The ACM, December 2003Nol. 46, No. 12, pp. 61-65.

[10] R. Jana, T. Johnson, S. Muthukrishnan and A. Vitaletti, "Location based services in a wireless WAN using cellular digital packet data (CDPD)," Proceedings of the 2nd ACM international workshop on Data engineering for wireless and mobile access, 2001 , pp. 74-80.

[11] C. Y. Chow, M. F. Mokbel and X. Liu, "A Peer-to­Peer Spatial Cloaking Algorithm for AnonymousLocation-based Services," Proceedings of the 14th annual ACM international symposium on Advances in geographic information systems, 2006, pp. 254.

[12] 3GPP specification: 25.321, http://www.3gpp.org/ftp/Specslhtml-info/25321.htm

1912